sql-server – 可以在一台SQL服务器上放置的数据库数量有限制吗

我正在建立一个SaaS系统,我们计划为每个客户提供他们自己的数据库.系统已经设置好,如果负载太大,我们可以轻松扩展到其他服务器;我们希望拥有数千甚至数万名客户.

问题

>对于一个SQL Server上可以/应该具有的微数据库的数量是否有任何实际限制？
>它会影响服务器的性能吗？
>拥有10,000个每个100 MB的数据库或一个1 TB的数据库会更好吗？

附加信息

当我说“微型数据库”时,我的意思并不是“微观”;我的意思是我们的目标是成千上万的客户,因此每个数据库只占总数据存储量的千分之一或更少.实际上,每个数据库的大小都在100MB左右,具体取决于它的使用量.

使用10,000个数据库的主要原因是可扩展性.事实上,系统的V1有一个数据库,当数据库在负载下紧张时,我们遇到了一些不舒服的时刻.

它使CPU,内存,I / O紧张 – 以上所有.即使我们解决了这些问题,他们也让我们意识到,即使拥有世界上最好的索引,如果我们的成功与我们希望的一样成功,我们根本无法将所有数据放在一个大的’数据库.所以对于V2我们是分片,所以我们可以在多个DB服务器之间分配负载.

去年我花了很多时间开发这种分片解决方案.这是每台服务器的一个许可证,但无论如何,由于我们在Azure上使用虚拟机,因此需要处理这些许可证.现在问题出现的原因是因为以前我们只向大型机构提供并自己设置每个机构.我们的下一个业务订单是自助服务模式,任何拥有浏览器的人都可以注册并创建自己的数据库.他们的数据库将比大型机构小得多,数量众多.

我们尝试了Azure SQL Database Elastic Pools.性能非常令人失望,因此我们切换回常规虚拟机.

解决方法

重新启动服务器可能需要一个小时或更长时间.考虑10,000个数据库的恢复过程.

您无法使用SQL Server Management Studio在对象资源管理器中可靠地找到数据库.

备份是一场噩梦,因为备份是值得的,您需要有一个可行的灾难恢复解决方案.希望您的团队能够很好地编写所有内容.

您开始使用数字命名数据库,例如M01022和T9945.试图确保您在正确的数据库中工作,例如M001022代替M01022,可能令人抓狂.

为许多数据库分配内存可能令人难以忍受; SQL Server最终会执行大量I / O操作,这可能会严重影响性能.考虑一个系统,记录10,000家公司的4个表中的碳使用细节.如果在一个数据库中执行此操作,则只需要4个表;如果你在10,000个数据库中这样做,突然间你需要40,000个内存表.在内存中处理该数量的表的开销并不是非实质性的.如果有10,000个数据库,那么您设计的任何将针对这些表运行的查询将需要计划缓存中至少10,000个计划.

上面的列表只是您在这种规模下运营时需要计划的一小部分问题.

您可能会遇到像SQL Server服务这样的事情需要很长时间才能启动,这可能会导致服务控制器错误.您可以自己增加服务启动时间,创建以下注册表项：

Subkey: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControl
Name:   ServicesPipeTimeout
Type:   REG_DWORD
Data:   The number of milliseconds before timeout occurs during service startup

例如,要在服务超时之前等待600秒(10分钟),请键入600000.

自写完答案以来,我意识到问题在于谈论Azure.也许在SQL数据库上这样做并不是那么成问题;也许它更成问题.就个人而言,我可能会设计一个使用单个数据库的系统,可能在多个服务器上垂直分片,但肯定不是每个客户一个数据库.

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!