如何解决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 和混合工作负载中的大型表使用列存储和批量加载。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
