Я работаю над веб-приложением, которое находится где-то между почтовой службой и социальной сетью. Я чувствую, что в будущем у него есть потенциал, чтобы стать действительно большим, поэтому меня беспокоит масштабируемость.
Вместо использования одной централизованной базы данных MySQL / InnoDB и последующего ее разделения, когда придет время, я решил создать отдельную базу данных SQLite для каждого активного пользователя: по одному активному пользователю на «сегмент».
Таким образом, резервное копирование базы данных будет таким же простым, как копирование небольшого файла базы данных каждого пользователя в удаленное место один раз в день.
Увеличить масштаб будет так же просто, как добавить дополнительные жесткие диски для хранения новых файлов.
Когда приложение выходит за рамки одного сервера, я могу связать серверы вместе на уровне файловой системы с помощью GlusterFS и запускать приложение без изменений или настроить простую прокси-систему SQLite, которая позволит каждому серверу управлять файлами sqlite на соседних серверах.
Проблемы с параллелизмом будут минимальными, потому что каждый HTTP-запрос будет касаться только одного или двух файлов базы данных за раз из тысяч, а SQLite в любом случае блокирует только чтение.
Я уверен, что такой подход позволит моему приложению изящно масштабироваться и поддерживать множество интересных и уникальных функций. Я сделал неправильную ставку? Я что-нибудь упускаю?
ОБНОВЛЕНИЕ. Я решил использовать менее экстремальное решение, которое пока работает нормально. Я использую фиксированное количество шардов - 256 баз данных sqlite, если быть точным. Каждого пользователя назначают и привязывают к случайному осколку с помощью простой хеш-функции.
Для большинства функций моего приложения требуется доступ только к одному или двум шардам на запрос, но есть один, который, в частности, требует выполнения простого запроса по 10–100 различным шардам из 256, в зависимости от пользователя. Тесты показывают, что это займет около 0,02 секунды или меньше, если все данные кэшируются в ОЗУ. Думаю, я смогу с этим жить!
ОБНОВЛЕНИЕ 2.0. Я перенес приложение на MySQL / InnoDB и смог получить примерно такую же производительность для обычных запросов, но для того одного запроса, который требует обхода сегментов, innodb работает в 4-5 раз быстрее. По этой и другим причинам я отказываюсь от этой архитектуры, но надеюсь, что кто-то где-нибудь найдет ей применение ... спасибо.
