Экстремальный осколок: одна база данных SQLite на пользователя

Я работаю над веб-приложением, которое находится где-то между почтовой службой и социальной сетью. Я чувствую, что у него есть потенциал для роста в будущем, поэтому я обеспокоен масштабируемостью.

Вместо того, чтобы использовать одну централизованную базу данных MySQL/InnoDB и затем разбивать ее на время, я решил создать отдельную базу данных SQLite для каждого активного пользователя: один активный пользователь на "осколок".

Таким образом, резервная копия базы данных будет такой же простой, как копирование каждого пользователя небольшого файла базы данных в удаленное местоположение один раз в день.

Масштабирование будет таким же простым, как добавление дополнительных жестких дисков для хранения новых файлов.

Когда приложение растет за пределы одного сервера, я могу связать серверы на уровне файловой системы с помощью GlusterFS и запустить приложение без изменений или создать простую прокси-систему SQLite, которая позволит каждому серверу манипулировать SQL файлами на соседних серверах.

Concurrency проблемы будут минимальными, потому что каждый HTTP-запрос будет касаться только одного или двух файлов базы данных за раз, из тысяч, а SQLite только блокирует при чтении в любом случае.

Я уверен, что этот подход позволит моему приложению грациозно масштабироваться и поддерживать множество интересных и уникальных функций. Я пари неправильно? Я что-то пропустил?

ОБНОВЛЕНИЕ Я решил пойти с менее экстремальным решением, которое пока работает нормально. Я использую фиксированное количество осколков - 256 баз данных sqlite, если быть точным. Каждый пользователь назначается и привязывается к случайному осколку простой хэш-функцией.

Большинство функций моего приложения требуют доступа только к одному или двум осколкам для каждого запроса, но есть, в частности, тот, который требует выполнения простого запроса от 10 до 100 различных осколков из 256, в зависимости от пользователя. Тесты показывают, что это займет около 0,02 секунды или меньше, если все данные будут кэшироваться в ОЗУ. Я думаю, что смогу жить с этим!

UPDATE 2.0. Я портировал приложение в MySQL/InnoDB и смог получить одинаковую производительность для регулярных запросов, но для этого запроса, требующего осколочной ходьбы, innodb в 4-5 раз быстрее, По этой причине и по другой причине я отбрасываю эту архитектуру, но надеюсь, что кто-то найдет для нее пользу... спасибо.

Ответ 1

Место, где это произойдет, - это то, что вам нужно сделать, что называется "shard walking" - это поиск всех данных через группу разных пользователей. Этот особый "запрос" должен быть сделан программным путем, каждый раз спрашивая каждую из баз данных SQLite и, скорее всего, будет самым медленным аспектом вашего сайта. Это обычная проблема в любой системе, где данные были "отложены" в отдельные базы данных.

Если все данные являются автономными для пользователя, то это должно масштабироваться очень хорошо - ключ к тому, чтобы сделать это эффективным проектом, - это знать, как данные, вероятно, будут использоваться, и если данные от одного человека будет взаимодействовать с данными другого (в вашем контексте).

Вам также может потребоваться следить за ресурсами файловой системы - SQLite - отличный, отличный, быстрый и т.д., но вы получаете некоторые преимущества кэширования и записи при использовании "стандартной базы данных" (то есть MySQL, PostgreSQL и т.д.), потому что о том, как они разработаны. В предлагаемом дизайне вам будет не хватать некоторых из них.

Ответ 2

Звучит для меня как кошмар для обслуживания. Что происходит, когда схема изменяется на всех этих БД?

Ответ 3

Одна из возможных проблем заключается в том, что наличие одной базы данных для каждого пользователя будет использовать дисковое пространство и оперативную память очень неэффективно, и по мере того, как пользовательская база будет пользоваться преимуществами легкого и быстрого движка базы данных, будет полностью потеряна.

Возможным решением этой проблемы является создание " minishards", состоящее из 1024 баз данных SQLite, вмещающих до 100 пользователей в каждом. Это будет более эффективно, чем подход БД для каждого пользователя, поскольку данные упаковываются более эффективно. И легче, чем подход к базе данных базы данных Innodb, потому что мы используем Sqlite.

Concurrency также будет довольно хорошим, но запросы будут менее элегантными (shard_id yuckiness). Как вы думаете?

Ответ 4

http://freshmeat.net/projects/sphivedb

SPHiveDB - это сервер для базы данных sqlite. Он использует JSON-RPC через HTTP, чтобы открыть сетевой интерфейс для использования базы данных SQLite. Он поддерживает объединение нескольких баз данных SQLite в один файл. Он также поддерживает использование нескольких файлов. Он разработан для схемы экстремальной осколки - одной базы данных SQLite для каждого пользователя.

Ответ 5

Если вы создаете отдельную базу данных для каждого пользователя, похоже, что вы не настраиваете отношения... так зачем вообще использовать реляционную базу данных?

Ответ 6

Я рассматриваю ту же архитектуру, что и я, в основном, хотел использовать базы данных SQLLIte на стороне сервера в качестве резервной копии и синхронизации копии для клиентов. Моя идея для запроса по всем данным - использовать Sphinx для полнотекстового поиска и запускать задания Hadoop из плоских дампов всех данных в Scribe, а затем выставлять результаты в виде веб-сервисов. Однако этот пост дает мне некоторую паузу для размышлений, поэтому я надеюсь, что люди будут продолжать отвечать своим мнением.

Ответ 7

Если ваши данные легко обмануть, почему бы просто не использовать стандартный механизм базы данных, и если вы масштабируете достаточно большое, чтобы БД стало узким местом, осколочно базы данных с разными пользователями в разных случаях? Эффект тот же, но вы не используете множество крошечных баз данных.

В действительности у вас, вероятно, есть, по крайней мере, некоторые общие данные, которые не принадлежат ни одному пользователю, и вам, вероятно, часто приходится обращаться к данным более чем для одного пользователя. Однако это вызовет проблемы с любой системой.

Ответ 8

Наличие одной базы данных на одного пользователя действительно упростит восстановление отдельных данных пользователей, но, как сказал @John, изменения схемы потребуют некоторой работы.

Не достаточно, чтобы сделать это трудно, но достаточно, чтобы сделать его нетривиальным.