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

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

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

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

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

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

10 61
database database-design multi-tenant

10 ответов:

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

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

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

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

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

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

45

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

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

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

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

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

13

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

11

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

9

Что касается боли обновления 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

9

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

7

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

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

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

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

3

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

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

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

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

2

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

2

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

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

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

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

0