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数据库上这样做并不是那么成题目;大概它更成题目.就小我私人而言,我也许会计一律个行使单个数据库的体系,也许在多个处事器上垂直分片,但必定不是每个客户一个数据库.

（编辑：湖南网）

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