多个数据库与具有逻辑分区数据的单个数据库

Question

我在思考数据库设计问题.任何帮助将受到高度赞赏.

我们正在设计一个具有20个表的应用程序(在新功能开发期间可能会增加到最多30个表)

技术堆栈

MVC4,.NET 4.X,实体框架5,SQL Server 2012,ASP.NET成员资格框架

没有用户

我们打算迎合大约1000名平均有20名用户的客户.

问题

我们是否应该以对逻辑分区的方式设计数据库和应用程序,即所有客户端使用具有分区guid的相同表来分隔数据.

要么

在新功能启动和错误修复期间,可以使用多个数据库.但是可能允许缩放？

注意事项:其中一个表有一个存储文件的二进制列(每个记录最多5MB)

除此之外,我们还需要考虑Membership框架表,我们将扩展到另一个自定义表,并将用户逻辑映射到分区guid.

Answer 1

您希望您使用过单独的数据库:

• 如果您想要将数据库本身的权限授予客户端或超级用户.
• 如果您只想恢复一个客户端的数据库而不影响其他客户端的数据.
• 如果存在管理您的数据和数据泄露的监管问题,并且您姗姗来迟地发现这些法规只能通过拥有单独的数据库来满足.
• 如果您希望轻松地将客户数据移动到多个数据库服务器或以其他方式扩展,或将更大/更重要的客户移动到不同的硬件.在世界的另一个角落.
• 如果您希望轻松归档和停用旧客户数据.
• 如果您的客户关心他们的数据被孤立,他们发现您没有这样做.
• 如果您的数据已被传唤,您必须生成整个数据库,而不仅仅是一个客户端的数据.
• 当你忘记保持警惕时,只有一个查询没有包括在内AND CustomerID = @CustomerID.提示:使用脚本化权限工具或模式,或使用包含WHERE CustomerID = SomeUserReturningFunction()这些视图或其某些组合的视图包装所有表.
• 当您在应用程序级别获得权限错误并且客户数据暴露给错误的客户时.
• 当您希望为不同的客户端提供不同级别的备份和恢复保护.
• 一旦你意识到构建一个基础设施来创建,配置,配置,部署和以其他方式启动/关闭新数据库是值得的投资,因为它迫使你擅长它.
• 如果您不允许某类人员需要访问多个客户的数据,并且您需要一层抽象,Customer因为WHERE CustomerID = @CustomerID现在不会削减它.
• 当黑客瞄准您的站点或系统时,您只需在一个数据库中获取管理员凭据后,就可以轻松获得所有数据.
• 当您的数据库备份运行5个小时然后失败时.
• 当你必须让你的DBMS的企业版这样就可以使压缩备份,以便复制在网络上备份文件需要不到5个小时以上.
• 当您必须每天将整个数据库还原到需要5个小时的测试服务器时,并运行需要2个小时才能完成的验证脚本.
• 当只有少数客户需要复制时,您必须将其应用于所有客户,而不仅仅是那些客户.
• 当您想要接管政府客户并发现他们需要您使用单独的服务器和数据库时,您的生态系统是围绕单个服务器和数据库构建的,而且它太难或需要很长时间才能更改.

你会很高兴你使用单独的数据库:

• 当一个客户的试点推出完全爆炸,而其他999个客户完全不受影响.您可以从备份还原以解决问题.
• 当您的某个数据库备份失败并且您可以在25分钟内修复该数据库备份而不是再次启动整个10小时的过程.

您希望您使用过单个数据库:

• 当您发现影响所有1000个客户端的错误并将修复程序部署到1000个数据库时很难.
• 当您在数据库级别获得权限错误并且客户数据暴露给错误的客户时.
• 当您不允许某类人员需要访问所有数据库的子集(可能是两个客户合并)时.
• 当你不认为合并两个不同的数据库有多难.
• 当您合并两个不同的数据数据库并意识到其中一个是错误的数据库时,您并没有计划从这种情况中恢复.
• 当您尝试在单个服务器上超过32,767个客户/数据库时,发现这是SQL Server 2012中的最大值.
• 当你意识到管理1000多个数据库是一个比你想象的更大的噩梦.
• 当您意识到只是通过在表中添加一些数据就无法登上新客户时,您必须运行一堆可怕且复杂的脚本来创建,填充和设置新数据库的权限.
• 当您每天必须运行1000个数据库备份时,请确保它们都成功,通过网络复制它们,将它们全部还原到测试数据库,并在每个备份上运行验证脚本,以保证的方式报告任何故障可以看到,并且可以轻松快速地进行操作.然后其中150个在各个地方都失败了,必须一次修复一个.
• 当您发现必须为1000个数据库设置复制时.

仅仅因为我列出的原因更多并不意味着它更好.

一些读者可能会从这篇MSDN文章中获得价值:多租户数据架构

Answer 2

如果你是闯民宅的2009建筑"多租户",微软有一个很好的文章,是值得阅读这里.它显示了"isolated" (multiple db)和之间的一些比较"shared" (single db).通常,当租户(客户)的数量很大时共享获胜,但是当每个租户的规模很大时,建议采用孤立的方法.

然而,这些考虑只能由有经验的开发人员计算.

仍然如果你设法使用isolated (multiple db)架构,当它们仍然在同一个实例上运行时,你仍然不会在性能上获得直接的好处.如果您使用shared (single db)架构,请考虑使用int而不是guid,或者sequential guid如果您仍然需要使用它.