Планирование базы данных - несколько схем против нескольких баз данных против одной большой базы данных против разделов

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

Брент Озар затронул именно эту проблему в недавнем сообщении в блоге - определенно стоит прочитать, поскольку он очень хорош: http://www.brentozar.com/archive/2011/06/how-design-multiclient-databases/

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

Однако в дополнение к схеме для каждого клиента я бы рекомендовал вам также создать файловую группу для каждого клиента, а затем поместить все объекты базы данных для каждого клиента в эту файловую группу. У этого есть несколько преимуществ:

1. Лучшая доступность базы данных. Если есть повреждение в файле данных, принадлежащем одному клиенту, остальную часть базы данных по-прежнему можно перевести в оперативный режим. После этого поврежденный файл данных можно восстановить из резервной копии даже во время выполнения других транзакций.
2. (Потенциально) лучшая производительность. По мере роста системы вы можете размещать файловые группы на разных устройствах хранения и распределять операции ввода-вывода (конечно, вы можете сделать что-то подобное с одной файловой группой и несколькими файлами, но это позволит вам разделить операции ввода-вывода по клиентам).
3. Легкость резервного копирования. Резервное копирование базы данных может происходить на уровне файловой группы, что дает вам больше гибкости при выборе времени резервного копирования таблиц для каждого клиента.
4. Лучше восстановить детализацию. Как и в случае №1, при восстановлении базы данных с нуля, когда первичная файловая группа подключена к сети, вы можете начать восстанавливать файловые группы индивидуально, начиная с вашего самого важного клиента. Поскольку последующее восстановление не повлияет на уже восстановленные файловые группы, вы можете выводить свою базу данных в оперативный режим по частям, а не одним махом. Это называется частичное восстановление онлайн и является функцией только корпоративной версии (хотя в стандартной версии можно сделать что-то подобное, но для этого требуется, чтобы база данных была отключена).

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

Для получения дополнительной информации я рекомендую книгу в Интернете, статья 'Файлы и архитектура файловых групп'и технический документ SQLCAT о частичной доступности базы данных: http://sqlcat.com/sqlcat/b/whitepapers/archive/2007/11/21/partial-database-availability.aspx

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

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

Я предполагаю, что ваша основная таблица - это таблица "списки", которая имеет примерно 150 * 1000 живых строк (предположительно + исторические записи).

Это не слишком большой объем данных, и машина с разумными характеристиками не должна иметь проблем.

Я бы позаботился о том, чтобы исторические записи перемещались в их собственные таблицы. В запросе на чтение я бы добавил "прочитать незафиксированный снимок"

В обновлениях есть несколько возможных исправлений для этого: 1. Используйте слияние, а не несколько операторов обновления 2. Используйте курсор, чтобы предотвратить эскуляцию блокировки 3. Добавьте новые записи для обновленных списков и просто обновите бит «является текущим» флаг на старых

Учитывая, что это было 2 года назад, каково было окончательное решение?

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

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

[https://msdn.microsoft.com/en-us/library/aa479086.aspx visible[1]