Azure SQL Hyperscale 0个辅助副本配置可行性及性能问询

1. 0辅助副本配置合理性与性能对比 #

• 0辅助副本属于官方支持的合法配置，不属于不合理使用：Hyperscale架构的存储层本身默认保留3个数据副本，辅助副本的作用是提供只读扩展、高可用故障转移能力，和存储层冗余是完全独立的两个设计。哪怕配置0副本，存储层的多副本冗余能力不受影响，仅计算层发生故障时的恢复时间会比有辅助副本的配置稍长（最长30s左右RTO，无数据丢失），如果你的业务可以接受这个故障恢复时长，0副本配置完全符合使用规范。
• 相同vCore配置下主读写节点无额外性能损耗：Hyperscale计算节点和通用用途层的vCore硬件规格完全一致，仅存储访问路径做了优化，针对你每日全量读取历史数据运行冷启动模型的场景，Hyperscale的分层存储（内存缓存+高性能SSD+大容量归档层）反而会提升冷数据批量读取的性能，不会比现有通用用途层性能差。
• 同配置下主读写节点性能与非Hyperscale通用用途层节点偏差在5%以内，批量读取、OLAP类场景性能普遍优于通用用途层。

2. Hyperscale不可回退的风险规避方案 #

• 提前规划离线备份策略：每周固定执行一次全量bacpac备份导出到对象存储，每日同步增量事务日志备份，即使后续需要回迁到其他服务层级，可通过全量备份+事务日志回放的方式实现RPO<24h的迁移，不需要全程双实例并行写入。
• 迁移后保留原实例7天以上只读状态：迁移到Hyperscale后，原有通用用途层实例不要立即删除，开启CDC（变更数据捕获）同步Hyperscale的增量写入，连续验证7天无异常后再销毁原实例，期间如果出现问题可直接切回原实例，几乎无业务影响。
• 做数据访问层抽象：在你的Python数据读写模块中封装数据库连接配置，不要硬编码实例地址，后续如果需要切换存储实例仅需修改配置项即可，不需要调整业务逻辑代码。

3. 无基准测试场景下的注意事项 #

• 优先开启自动缓存预热功能：针对你每日全量读取历史数据的固定场景，开启自动缓存预热后，系统会自动将高频访问的时序数据预加载到计算节点缓存，大幅降低批量读取的延迟。
• 按需调整存储冗余策略：如果你的业务可以接受区域级故障的恢复时间稍长，可以将默认的区域冗余存储调整为本地冗余存储，进一步降低存储成本。
• 提前配置核心指标告警：针对CPU使用率、IOPS、存储延迟三个核心指标配置阈值告警，出现性能异常时可即时触发通知，12 vCore配置下Hyperscale默认提供20000+基线IOPS，完全可以覆盖时序数据批量读取的需求。
• 预留存储冗余：不要用到存储容量的90%以上，避免后台存储平衡操作带来的性能波动。

内容的提问来源于stack exchange，提问作者iffak