Каковы преимущества использования единой базы данных для КАЖДОГО клиента?

Question

В приложении, ориентированном на базу данных, которое предназначено для нескольких клиентов, я всегда думал, что "лучше" использовать единую базу данных для ВСЕХ клиентов, связывая записи с соответствующими индексами и ключами.Слушая подкаст Stack Overflow, я услышал, как Джоэл упомянул, что FogBugz использует одну базу данных на каждого клиента (так что, если бы было 1000 клиентов, было бы 1000 баз данных).Каковы преимущества использования этой архитектуры?

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

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

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

Любой вклад будет высоко оценен!

Answer 1

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

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

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

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

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

Думаю, я могу вспомнить еще несколько десятков.Но в целом ключевым понятием является "простота".Продукт управляет одним клиентом и, следовательно, одной базой данных.Никогда не возникает никаких сложностей из-за вопроса "Но база данных также содержит другие клиенты".Это соответствует ментальной модели пользователя, в которой он существует один.Преимущества, такие как возможность легко создавать отчеты по всем клиентам одновременно, минимальны - как часто вам нужен отчет по всему миру, а не только по одному клиенту?

Answer 2

Вот один из подходов, который я видел раньше:

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

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

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

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

Answer 3

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

Answer 4

Ну, а что, если один из ваших клиентов попросит вас восстановить более раннюю версию своих данных из-за какой-нибудь неудачной операции импорта или чего-то подобного?Представьте, что почувствовали бы ваши клиенты, если бы вы сказали им: "вы не можете этого сделать, поскольку ваши данные являются общими для всех наших клиентов" или "Извините, но ваши изменения были утеряны, потому что клиент X потребовал восстановления базы данных".

Answer 5

Что касается сложности одновременного обновления 1000 серверов баз данных, об этом должна позаботиться довольно простая автоматизация.Пока каждая база данных поддерживает идентичную схему, на самом деле это не будет проблемой.Мы также используем подход "база данных для каждого клиента", и у нас это хорошо работает.

Вот статья именно на эту тему (да, это MSDN, но это статья, независимая от технологии): http://msdn.microsoft.com/en-us/library/aa479086.aspx.

Еще одно обсуждение многопользовательской аренды, связанное с вашей моделью данных, приведено здесь: http://www.ayende.com/Blog/archive/2008/08/07/Multi-Tenancy--The-Physical-Data-Model.aspx

Answer 6

Масштабируемость.Безопасность.Наша компания также использует подход 1 DB для каждого клиента.Это также немного упрощает обслуживание кода.

Answer 7

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

Answer 8

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

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

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

Следует учитывать масштабируемость - вы правы в том, что легко взять одну изолированную базу данных и переместить ее на другой физический сервер;однако становится все проще объединять серверы в кластеры - и даже без кластеризации кажется, что было бы небольшим изменением указать каждому клиенту на СЕРВЕР базы данных, на котором размещена универсальная база данных (например, у вас могло бы быть два или три сервера баз данных, на каждом из которых размещена только одна база данных).Такой подход ограничивает процесс обновления только тремя базами данных.

Answer 9

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

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

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

Мне было бы интересно услышать от вас немного больше контекста по этому поводу, потому что кластеризация - непростая тема, и ее дорого реализовать в мире СУБД.Существует много разговоров / бравады о кластеризации в нереляционном мире Google Bigtable и т.д.но они решают другой набор проблем и теряют некоторые полезные функции СУБД.

Answer 10

Существует несколько значений термина "база данных".

• коробка с оборудованием
• запущенное программное обеспечение (например,"оракул")
• конкретный набор файлов данных
• конкретный логин или схема

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

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