Azure SQL 缩放功能如何改变架构设计?

问题描述

换句话说,Azure sql 中的架构设计与 VM 或硬件上的 sql 的架构设计有何不同?在为 Azure sql 数据库和托管实例设计架构时,DBA 还应考虑哪些其他因素?

为了缩小问题范围,您可以将答案限制在OLTP 主键和集群键选择和设计。

对于我公认的广泛问题的某些上下文,我没有找到有关 Azure sql PaaS 缩放功能上下文中架构设计指南的明确资源。在使用 Azure sql 设计数据库架构时,哪些设计选择将最大限度地提高实用性并简化扩展功能的未来实施,包括分片sql 数据同步阅读横向扩展超大规模

很可能'取决于'是正确答案(虽然没有绿色复选标记。)

即便如此,我认为这是一个重要的问题,并希望在这里开始对话并在一个地方获得最有用的答案。

最正确的答案将是小规模实用,并且还与 Azure sql 缩放功能兼容无需重大重构

其他类似问题的答案已经过时,并且在许多这些功能推出之前就已发布:

Architecture requirements to scale SQL Azure Tables/Schemas

Primary key in an Azure SQL database

解决方法

主要区别在于多租户解决方案更倾向于每个租户的数据库,因为分布在多个弹性池或托管实例上的大量数据库比在虚拟机或本地上简单得多。

此外,Azure SQL 数据库的 HA/DR 解决方案对日志速率施加了限制,因此您将对 OLAP 和混合工作负载中的大型表使用列存储和批量加载。