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

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

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

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

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

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

Ответов (10)

Решение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что касается проблем, связанных с одновременным обновлением 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

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

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

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

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

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