Лучший способ структурировать базу данных для масштабирования - PullRequest
1 голос
/ 25 октября 2011

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

1) Создайте совершенно другую базу данных для каждого пользователя, чтобы его данные были полностью отделены от всех остальных

2) Предоставить общий доступ к данным в той же базе данных и разделить их на уровне запроса, используя поле user_id.

Схема всегда будет одинаковой для каждого пользователя.

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

Мне интересно услышать от любого, кто имел дело с подобной ситуацией в прошлом, и какие подводные камни могут быть в любом из вариантов.

Ответы [ 3 ]

2 голосов
/ 25 октября 2011

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

Другие операционные проблемы:

  • Безопасность - использование поля user_id в вашем коде основано на отсутствии ошибок или недостатков, которые позволяют пользователю видеть / манипулировать другим пользователемdata.

  • Обновления - выполняются в обоих направлениях, но вы либо обновляете всех сразу (одну БД), либо путем разделения - позволяете обновлять различные группы пользователей в разное время.

  • Резервное копирование / восстановление - в зависимости от требований к восстановлению и соглашений об уровне обслуживания вы можете обнаружить, что наличие всех в одной базе данных создает слишком много проблем, когда речь идет о резервном копировании / восстановлении.Если один клиент хочет восстановить свои данные, эксплуатационные издержки, когда он объединяется со всеми данными другого клиента, не являются тривиальными.Точно так же наличие большого количества баз данных = много отдельных резервных копий.

  • Масштабируемость - возможность размещать базы данных разных пользователей на отдельных серверах может помочь в масштабировании, вместо того, чтобы требовать большой железный сервер БД.Но опять же, это накладные расходы на управление.

Многопользовательское приложение и его источник данных - непростой вопрос / ответ - понимание того, сколько пользователей «велико» вэтот случай может быть совмещен с эксплуатационными проблемами и даст вам руководство.

1 голос
/ 25 октября 2011

Вариант 2 должен быть вашим лучшим выбором.Базы данных обычно предназначены для работы с миллионами и миллионами строк и большим количеством данных.Таким образом, пока вы правильно проектируете свою схему и имеете правильные индексы, коэффициенты заполнения и т. Д., Вариант 2 приведет вас к требуемому масштабированию.Как сказал DarthVader, узнайте больше о дизайне базы данных.

1 голос
/ 25 октября 2011

Не создавать отдельную базу данных для каждого пользователя. Это не хорошо.

Что если у вас будет миллион пользователей?

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...