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

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

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

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

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

Любой вклад с благодарностью!

16.08.2008 20:39:26
Örjan Jämte 6.07.2011 06:32:56
10 ОТВЕТОВ
РЕШЕНИЕ

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

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

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

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

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

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

47
16.08.2008 20:48:00
С точки зрения сохранения «стены» между клиентами, это то, для чего нужны хранимые процедуры и триггеры (предупреждение: не рекомендуется для MySQL) - также легко (пере) перемещать данные клиентов на разные серверы, если кто-то создал схема правильно. «Простота» работает и по-другому. Если у меня есть одна база данных, я могу легко объединить свои соединения и упростить этот код. Если у меня заканчиваются соединения, я просто увеличиваю пул; Не нужно следить за каждым клиентом в отдельности.
BryanH 19.10.2009 17:48:25

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

10
16.08.2008 20:45:23
Все таблицы должны быть разделены по TenantID. Это дает вам возможность делать резервные копии / восстанавливать разделы только для одного клиента :)
dariol 20.05.2010 23:03:21
@ dario-g: Похоже, вы поддерживаете подход с общей базой данных. Пожалуйста, объясните, что вы подразумеваете под разделением по TenantID, так как это может быть неочевидно.
Gruber 21.09.2012 14:56:00
В Oracle вы можете разделить таблицу и переместить разделы в удаленные места, однако у вас все еще есть одна таблица.
givanse 6.02.2014 18:18:43

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

6
16.08.2008 20:48:35
Эй, вы все еще используете этот подход? Не могли бы вы поделиться некоторыми цифрами о том, сколько клиентов / дБ у вас сейчас?
JCM 12.07.2016 17:24:49

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

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

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

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

3
16.08.2008 21:11:27
вы, кажется, склоняетесь к общему подходу. я с вами.
Matt Kocaj 22.04.2009 10:33:09

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

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

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

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

0
16.08.2008 22:46:34
Нет, он имеет в виду базу данных. Вещи, которые создаются, когда вы выполняете оператор CREATE DATABASE.
BobbyShaftoe 15.12.2008 06:25:33

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

11
16.08.2008 22:52:52
Это не должно быть так. Если вы не можете использовать индексы для изоляции строк, либо база данных плохо спроектирована, либо вы пытаетесь запросить весь набор данных между клиентами, что будет сложнее сделать с отдельными базами данных для начала.
Nick 19.02.2019 16:51:17

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

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

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

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

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

13
16.08.2008 23:14:32

Что касается боли при одновременном обновлении 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
16.08.2008 23:18:55
Кто-нибудь знает инструмент, который автоматизирует обновление нескольких баз данных, скажем, MySQL? Если вы решите использовать изоляционный подход, вам необходимо убедиться, что 1000 баз данных обновлены, отражая схему назначенной главной базы данных.
Gruber 21.09.2012 14:50:48
@ Натан, ты все еще используешь один дБ на каждого арендатора?
JCM 17.10.2016 16:12:26
Нет, в итоге мы выбрали одну многопользовательскую базу данных и поместили конфиденциальность клиента в структуру приложения. Одна база данных на каждого арендатора была для нас слишком большой.
Nathan 24.10.2016 16:18:10

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

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

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

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

2
16.08.2008 23:31:29

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

4
28.08.2008 22:23:07
У меня не было достаточно репутации в то время, проверьте дату моего ответа.
Daniel Magliola 13.10.2009 21:38:18