我的应用程序以独立的“工作空间”为中心。出于许多非常好的原因(从管理到安全的所有方面),我们始终采用每个工作区一个数据库的架构。每个数据库都有相同的模式、存储过程、触发器等。有一个“数据库的数据库”来协调所有这些。效果很好。
问题是:可扩展性。最近有人提出,客户可能希望拥有 100,000 个工作空间。显然,这对于一个 SQL 实例来说是行不通的。另外,每个工作空间可能相当小,但尺寸分布也非常宽 - 最大的工作空间可能是中值尺寸的 100 倍。前 1% 的工作空间可以轻松构成所有工作空间中 90% 以上的行。
我正在寻找重新构建事物的选项以支持这种情况,以下是我考虑过的一些事情以及我在每个事情上看到的问题。
保留多数据库架构,但分布在多个 SQL 实例中。问题是成本(管理和基础设施)。如果我们坚持每个实例上 1,000 个数据库的限制,那仍然是 100 个实例,分布在谁知道有多少实际虚拟机上。但由于许多工作空间都很小(比我们目前的平均水平小得多),因此收入几乎不会相应增加。所以我认为这可能是不可能的,我现在专注于单数据库架构。
每个工作区共享相同的表,并按工作区 ID 进行索引。因此,每个表都需要一个新的工作区 ID 列,并且每个查询都需要在 WHERE 子句中添加工作区条件(或者更可能的是,每个实际表都包含在采用 WorkspaceID 的内联表值函数中;无论如何......)每个表的主键也必须重新定义以包含工作区 ID,因为现在并非每个 PK 都是全局唯一的。从编程角度来看,这一切都很好,但即使有正确的索引和完美的查询设计(不,并非我们所有的查询都是完美的 - 可怕的行扫描仍然偶尔发生)是否有任何可以想象的方式这也可以作为单独的数据库执行 - 对于每个人?更具体地说,我们能否保证小项目不会因为大项目的存在而受到影响,因为大项目占用的行数可能比小项目多 100 倍?需要采取哪些具体步骤,无论是要使用的索引类型,还是如何编写查询来保证优化器在执行任何其他操作之前始终通过工作区 ID 缩小范围?
分区 - 根据我的阅读,这对查询性能没有帮助,并且 MS 似乎建议将表或索引限制为 1000 个分区,因此这也无济于事。
创建相同的一组表,但为每个工作区使用新架构。我之所以想到这一点,是因为除了总体 2G 对象限制之外,数据库可以拥有的表数量没有限制。但我还没有深入探讨过这个想法。我想知道 100,000 个模式和数百万个表、视图、存储过程等是否会存在性能问题。
尽管如此,这里有一个具体问题 - SQL Server 的哪些具体功能和/或一般策略(包括但不限于我考虑过的事情)对于维护大量自包含数据集最有用单个巨型数据库中的相同模式?重申一下,保持性能尽可能接近多数据库架构是重中之重。
不用说,如果我上述评估的任何部分看起来不正确或被误导,我很高兴得到纠正。非常感谢。
这不是全有或全无。您可以保留多数据库架构,同时允许多个项目共享数据库。然后,您只需将多个工作空间存储在数据库中即可用于较小的工作空间。
正常的索引方法是将 WorkspaceID 添加为所有主键的前导列,这将在物理上将特定工作区的行放在同一位置。
您需要一个过程来从数据库中删除工作区。然后,要拆分数据库,只需恢复它的新副本,并从每个数据库中删除工作区。
考虑到当前的架构,这是扩展它的明显方法。您需要找到某种方法来平衡负载。也许您在某些服务器上最多可以有 25,000 个小型工作区数据库,但在其他服务器上最多可以有 20 个大型工作区数据库。这会产生管理成本,但基础设施成本应该大致相同,因为 SQL Server 按核心进行许可,并且即使分布在多个服务器上,核心数量以及内存和存储也应该大致相同。
任何其他解决方案都会减少数据的隔离,这可能会成为问题。