扩缩容建议

数据库资源的自动扩缩容需要谨慎权衡：扩容过慢可能带来性能下降风险，而缩容过于激进则可能引发持续震荡。

ClickHouse Cloud 通过将双窗口推荐框架与目标跟踪型 CPU 推荐系统相结合，在保持生产环境数据库所需稳定性的同时，实现了更快的缩容、尽量减少扩缩容震荡，并显著降低了可变工作负载的基础设施成本。

CPU 扩缩容基于目标跟踪，它会精确计算将利用率维持在目标水平所需的 CPU 配额。只有当当前 CPU 利用率超出设定区间时，才会触发扩缩容操作：

推荐器会根据历史使用情况评估 CPU 利用率，并使用以下公式确定建议的 CPU 大小：

recommended_cpu = max_cpu_usage / target_utilization

如果 CPU 利用率处于已分配容量的 37.5%–75% 之间，则不会执行任何扩缩容操作。超出该区间时，推荐器会计算出将利用率恢复到 53% 所需的精确容量，并据此对服务进行扩缩容。

一个分配了 4 vCPU 的服务，使用量突增至 3.8 vCPU (利用率约为 95%) ，超过了 75% 的高水位阈值。 推荐器会计算：3.8 / 0.53 ≈ 7.2 vCPU，并向上取整到下一个可用规格 (8 vCPU) 。当负载回落、使用量降至 37.5% (1.5 vCPU) 以下时，推荐器会按比例缩容。

ClickHouse Cloud 会根据您的服务实际使用情况自动推荐内存大小。 推荐器会分析回溯窗口内的使用情况，并预留额外余量，以应对突发峰值并防止内存不足 (OOM) 错误。

推荐器会考察三个信号：

• 查询内存：查询执行期间的峰值内存占用
• 常驻内存：进程整体的峰值内存占用
• OOM 事件：查询或副本最近是否出现过内存不足

对于查询内存和常驻内存，增加多少余量取决于你的使用情况有多可预测：

• 使用稳定 (波动较小) ：1.25 倍系数——余量更高，因为使用情况较为稳定，不太可能突然飙升
• 使用波动较大 (变化明显) ：1.1 倍系数——余量较低，以避免对本就波动较大的工作负载过度预配

如果检测到 OOM 事件，推荐器会采用更激进的 1.5 倍系数，以确保服务有足够的内存恢复运行。

系统会取所有信号中的最高值：

desired_memory = max(
  query_memory × skew_multiplier,
  resident_memory × skew_multiplier,
  resident_memory × 1.5,   // 如果检测到查询 OOM
  rss_at_crash × 1.5       // 如果检测到 pod（容器组）OOM
)

ClickHouse Cloud 不使用单一窗口，而是采用两个时间范围不同的回溯窗口：

• 小窗口 (3 小时)：捕捉近期使用模式，支持更快缩容
• 大窗口 (30 小时)：确保我们能够根据较长回溯窗口内观察到的最大使用量，一步完成扩容，而不是经过多次逐步扩容。这一点至关重要，因为扩缩容需要时间，而且会使本地缓存失效；因此，一步扩容更安全。

每个窗口都会基于内存和 CPU 分析独立生成一个推荐结果。 然后，系统会根据每个窗口给出的扩缩容方向合并这些推荐结果，如下图所示：

如需深入了解该推荐器的设计决策，请参阅 “ClickHouse 的更智能自动扩缩容：双窗口方法 ”