Планирование базы данных - Несколько Схем по сравнению с Несколькими Базами данных по сравнению с Единственной большой базой данных по сравнению с Разделами
К сожалению, перезагрузка сервера решила проблему, таким образом, я все еще не знаю, почему это происходило, но это больше не.
Лично я предпочитаю несколько баз данных, так как это позволяет вам видеть, какие базы данных используют больше всего операций ввода-вывода и ОЗУ, с различными DMV - и позволяет легко переносить самые большие базы данных в другом месте по линии. Кроме того, существует разделение безопасности, которое всегда успокаивает клиентов.
Брент Озар затронул именно эту проблему в недавнем сообщении в блоге - определенно стоит прочитать, поскольку он очень хорош: http://www.brentozar.com/archive/2011/06/how-design-multiclient-databases/
Although I'd probably recommend going for a database per customer, if you want to stick to one database then it looks like schemas will be suitable given your requirements.
However, in addition to a schema per customer I would recommend that you also create a filegroup per customer, then place all the database objects for each customer into that filegroup. There are several advantages to this:
- Better database availability. If there is corruption in a data file belonging to one customer, it is still possible to bring the rest of the database online. The corrupt data file can then be restored from a backup even whilst other transactions are taking place.
- (Potentially) better performance. As the system grows, you could place filegroups onto different storage devices and spread out your I/O (of course you can do something similar with one filegroup and multiple files, but this will let you split IO by customer).
- Ease of backups. Database backups can occur at the filegroup level, giving you more flexibility on when to back up the tables for each customer.
- Better restore granularity. Similar to #1, when restoring the database from scratch, once the primary filegroup is online you can begin to restore the filegroups individually, starting with your most important customer. As subsequent restores will not have any impact on already restored filegroups, you can bring your database online piece by piece rather than in one foul swoop. This is called an online piecemeal restore and is an enterprise edition only feature (although it is possible to do something similar in standard edition, but it requires the database to be offline).
I believe the maximum number of filegroups you can have is 32,000-ish so this strategy should last until you really do need to think about splitting into different databases.
For more information I recommend the books online article 'Files and Filegroups Architecture' and the SQLCAT whitepaper on partial database availability: http://sqlcat.com/sqlcat/b/whitepapers/archive/2007/11/21/partial-database-availability.aspx
Похоже, вас больше интересует хранение всего в одной базе данных любой ценой (хотя вы это подняли), поскольку основная идея Питера для разбиения на отдельные базы данных была связана с производительностью и возможность масштабирования в долгосрочной перспективе. В этом случае вам нужно либо разделить таблицы на разные схемы для клиентов, либо переключиться на лицензию Enterprise Edition, чтобы вы могли использовать разделение таблиц и разделять общие таблицы на основе номера клиента.
Если все клиенты используют одну и ту же базу данных, и все веб-сайты используют один и тот же шаблон, это больше похоже на многопользовательскую CMS, и поэтому наличие единой базы данных здесь действительно имеет смысл.
Я бы не стал рассматривать проблему в том, что обновления одного клиента влияют на всех остальных, а скорее в низком уровне просто медленных обновлений и запросов в целом. Предполагая, что оборудование и нагрузка не меняются, 150 баз данных, вероятно, будут работать так же, как решение для одной базы данных (возможно, медленнее при определенных обстоятельствах)
. Я предполагаю, что ваша основная таблица - это таблица «листингов», которая имеет примерно 150 * 1000 живых строк (предположительно + исторические записи).
Это не слишком большой объем данных, и машина с разумными характеристиками не должна иметь проблем.
Я ' В запросе на чтение я бы добавил «читать незафиксированный снимок»
В обновлениях есть несколько возможных исправлений для этого 1. Используйте слияние, а не несколько операторов обновления. 2. Используйте курсор, чтобы предотвратить отмену блокировки. 3. Добавьте новые записи для обновленных списков и просто обновите битовый флаг «является текущим» на старых
Учитывая, что это было 2 года назад, каково было окончательное решение?
Я задавал себе тот же вопрос, когда планировал реструктурировать инфраструктуру базы данных. Эта статья мне очень помогла.
[ https://msdn.microsoft.com/en-us/library/aa479086.aspx] [1]