后退
我开发了一个用于不同目的的预测引擎(时间序列)。处理、建模和预测模块是用Python编写的，数据目前存储在Azure SQL数据库中。目前，数据库是通用(基于vCore)服务层、预置计算层和Gen5(12 vCore)硬件配置。我已经接近最大存储容量的极限(约3 TB)，但由于我每天几乎都会读取整个数据库(仅限冷启动型号)，除了增加存储容量外，我看不到其他选择。截断部分历史数据是不可能的。
问题
在12个vCore的情况下，最大存储容量约为3 TB，从美元的角度来看，增加vCore以实现约4 TB的最大存储大小是不可行的(尤其是因为瓶颈是存储，而不是计算)。我读了一些关于Azure平台上的替代服务/层的文章，发现Hyperscale可能会解决我的问题：我可以保持vCores不变，并拥有高达100 TB的存储空间。具有零个辅助副本(其他条件相同)的配置最终将处于与以前相同的$-范围内(请参阅"Backdrop")。我的印象是，辅助副本(只读节点)是Hyperscale体系结构的核心，所以我不确定这种零辅助副本的概述设置是否是滥用/误用。例如，它会提供相同的性能吗？或者我会期待性能提升吗(即使使用相同的vCore配置)？主读/写节点是否基本上类似于非超尺度节点？我应该考虑的其他方面？添加一个(或多个)辅助副本在未来可能是相关的(例如，与不断减少的vCore相结合)，但这不是atm的选项。
微软表示；不支持从Hyperscale改变到另一服务层的能力"；(真的吗？)，所以我想澄清一下这一点，以避免进行半手动的数据迁移(和增量迁移)，并在shait遇到问题时将两个实例并排使用。考虑到这种重新配置的范围和整个预测系统，我觉得提前进行小规模/全规模测试以获得有代表性的基准是不可行的。如果还有什么我应该考虑的(相关或半相关)，请随时为我指明正确的方向。
由于Hyperscale服务层是Azure SQL数据库中新添加的服务层，因此很难为您的问题找到确切的答案。
的确，它提供了高达100 TB的数据库大小，但美妙之处在于，它只会对您使用的容量收费。
Hyperscale服务层消除了许多实际限制传统上出现在云数据库中。大多数其他数据库所在的位置受单个节点中可用资源的限制超大规模服务层没有这样的限制。凭借其灵活的存储空间体系结构，存储根据需要增长。事实上，超大型数据库不是用定义的最大大小创建的。Hyperscale数据库随着所需的容量，并且您仅根据您使用的容量计费。对于读取密集型工作负载，Hyperscale服务层提供快速通过根据需要调配额外的复制副本来扩展负载读取工作负载。
您可以在Hyperscale服务层中拥有主副本和辅助副本。
- 主复制副本提供读写操作
- 辅助复制副本提供了读取扩展、高可用性和地理复制
辅助副本始终是只读的，可以有三种不同的类型：
- 高可用性复制副本(推荐)
- 命名复制副本(在预览中，没有保证的SLA)
- 地理复制副本(预览版，没有保证的SLA)
您应该考虑Hyperscale服务层，因为：
- 您需要大于4 TB的大小
- 需要快速的垂直和水平计算扩展、高性能、即时备份和快速数据库恢复
注意：用户可以根据需要将高可用性副本的总数从0-4个调整为0个。
您可以在此处查看Hyperscale定价模型。
考虑到以上几点，Hyperscale即使不是最好的，也是满足您需求的好解决方案。
这两个环节肯定会帮助你做出决定。超大规模服务层、超大规模辅助副本
我是Azure SQL DB团队的PM之一。我看到UtkarshPal MT已经给了你广泛的答案，所以我正在努力完成这张照片。Azure SQL DB Hyperscale提供不同类型的辅助副本。可以帮助获得更高SLA的复制副本称为高可用性复制副本。您可以毫无问题地使用0个复制副本。将会发生的情况是，如果主复制副本由于任何原因不可用，我们需要从头开始启动一个新的(计算)复制副本(因为没有可用的HA复制副本)，这可能需要一些时间(通常为几分钟)，这意味着您的服务将无法提供那么长的时间。拥有HA复制副本，可以大大减少数据库不可用的时间。
您可以在这里阅读所有详细信息：
https://learn.microsoft.com/en-us/azure/azure-sql/database/service-tier-hyperscale-replicas?tabs=tsql
SLA定义如下：
https://www.azure.cn/en-us/support/sla/sql-data/
关于性能：除非您专门使用辅助副本来卸载只读工作负载，否则没有HA副本不会影响性能