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

Question

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

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

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

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

Любой вклад приветствуется!

Answer 1

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

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

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

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

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

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

Answer 2

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

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

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

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

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

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 БД для каждого клиента. Это также облегчает поддержку кода.

Answer 7

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

Answer 8

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

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

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

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

Answer 9

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

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

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

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

Answer 10

Есть несколько значений «базы данных»

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

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

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