Azure SQL 缩放功能如何改变架构设计？ [关闭]

Question

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

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

对于我公认的宽泛问题的某些上下文，我没有找到有关 Azure SQL PaaS 扩展功能上下文中架构设计指导的权威资源。在设计带有 Azure SQL 的数据库架构时，哪些设计选择将最大化实用程序并简化扩展功能的未来实施，包括 Sharding、SQL 数据同步、阅读横向扩展和超大规模？

很有可能“取决于”是正确答案（虽然没有绿色复选标记。）

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

最正确的答案将是在小规模上实用，并且还将与 Azure SQL 缩放功能兼容无需进行重大重构。

其他类似问题的答案已过时，并在其中许多功能推出之前发布：

Architecture requirements to scale SQL Azure Tables/Schemas

Primary key in an Azure SQL database

Answer 1

主要区别在于多租户解决方案优先使用每个租户的数据库，因为分布在多个弹性池或托管实例中的大量数据库比虚拟机或本地简单得多。

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