数据库规划 - 多模式 vs 多数据库 vs 单个大型数据库 vs 分区

Question

我们为房地产公司设计网站。网站仅用于显示信息，所有网站共享一个通用模板。我们有大约 150 个网站供不同的客户使用。一些第三方数据提供商每小时向我们提供有关网站上每个列表的所有更新。每个客户的更新发生在不同的时间。平均而言，我们每个网站有 1000 个列表。并且每小时更新 80% 的数据都会发生变化或更新。

现在我们在 Sql server 2008 中有一个数据库，适用于所有客户（最初设计用于满足 10-20 个网站）。数据库中的表是所有人共享的。问题是每当更新发生时，它也会减慢其他与更新完全无关的客户网站。同时删除客户数据，减慢所有站点。

我计划通过为每个客户创建一个单独的模式来改造数据库，但我不确定这是否是处理我们问题的最佳方式。拥有一个单独的数据库会产生许多维护问题（备份、镜像等）。谁能建议我更好的方法来处理这个问题。如果我为每个客户创建单独的架构并将他们的表与其他表隔离，我不确定它如何影响性能。或者有什么更好的解决办法？

Answer 1

我个人更喜欢多个数据库，因为它允许您查看哪些数据库使用最多的 IO 和 RAM，以及各种 DMV - 并且它允许您轻松地将最大的数据库迁移到其他地方。此外，还有一个安全隔离，总是让客户放心。

Brent Ozar 在最近的一篇博客文章中谈到了这个问题——绝对值得一读，因为他非常好：http ://www.brentozar.com/archive/2011/06/how-design-multiclient-databases/

Answer 2

虽然我可能会建议为每个客户使用一个数据库，但如果您想坚持使用一个数据库，那么根据您的要求，看起来模式将是合适的。

但是，除了每个客户的架构之外，我建议您还为每个客户创建一个文件组，然后将每个客户的所有数据库对象放入该文件组中。这样做有几个优点：

1. 更好的数据库可用性。如果属于某个客户的数据文件损坏，仍然可以使数据库的其余部分联机。即使在其他事务正在发生时，损坏的数据文件也可以从备份中恢复。
2. （潜在）更好的性能。随着系统的增长，您可以将文件组放在不同的存储设备上并分散您的 I/O（当然，您可以对一个文件组和多个文件执行类似的操作，但这会让您按客户拆分 IO）。
3. 易于备份。数据库备份可以在文件组级别进行，让您在何时为每个客户备份表方面具有更大的灵活性。
4. 更好的还原粒度。与#1 类似，从头开始恢复数据库时，一旦主文件组联机，您就可以开始单独恢复文件组，从最重要的客户开始。由于后续还原不会对已还原的文件组产生任何影响，因此您可以将数据库逐个联机，而不是一举两得。这称为在线零碎恢复，是企业版独有的功能（虽然在标准版中可以做类似的事情，但它需要数据库脱机）。

我相信您可以拥有的最大文件组数是 32,000 左右，因此该策略应该持续到您确实需要考虑拆分到不同的数据库时为止。

有关更多信息，我推荐在线书籍文章“文件和文件组体系结构”和关于部分数据库可用性的 SQLCAT 白皮书：http ://sqlcat.com/sqlcat/b/whitepapers/archive/2007/11/21/partial-database-可用性.aspx