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

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

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

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

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

любой вклад очень признателен!

61
database database-design multi-tenant

10 ответов

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

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

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

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

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

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

45

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

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

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

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

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

13

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

11

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

9

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

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

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

9

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

7

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

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

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

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

3

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

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

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

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

2

Я просто добавляю этот ответ, чтобы включить слово multi-tenant здесь. Я искал это, используя "multitenant" в качестве запроса, и этот не появился.

2

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

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

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

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

0