资源估算
以下内容基于您预期的摄取量，提供了一个用于估算 ClickStack 部署所需计算和存储资源的模型。得出的数值仅为估算值，应作为初始基线使用，而非固定结论。实际需求取决于查询复杂度、并发度、保留策略以及摄取处理量的波动。请始终监控资源使用情况，并按需扩缩容。
本页面中的所有数值——处理量 (MB/s、TB/月) 、CPU 配置规模和存储——均以未压缩的原始摄取量表示，也就是您的应用生成并发送到 OpenTelemetry collector、在应用任何压缩之前的数据大小。
这就是您应根据现有日志、链路追踪和指标管道来估算的数值。下表中的存储数值已在该原始数据量基础上应用了假定的 10x 压缩率。
部署 ClickStack 时，请为两类相互独立的工作负载预配计算资源：摄取 和 查询。
| 工作负载 | 预估资源 |
|---|---|
| 摄取 | 每 10 MB/s 的持续摄取处理量需要 1 个 vCPU |
| 查询 | 每 1 QPS 以及每 10 MB/s 的持续摄取处理量需要 1 个 vCPU |
在大多数自管理部署中，摄取和查询共享同一组节点。在这种情况下，请将 总 CPU 数 作为基线。隔离扩缩容——即分别为摄取和查询独立预配计算资源——可在 ClickHouse Cloud 中通过独立计算池 (也称为仓库) 实现。
假设
- 存储采用 10x 压缩率——对于日志和链路追踪，这通常是一个偏保守的估计。
- 查询 SLA 假设为 P50 1.5 秒、P99 5 秒。
- 我们假设大多数查询都发生在近期数据上，并遵循以大约 1 小时为峰值、尾部延伸到大约 6 小时的对数正态分布。用户可能希望为查询较旧数据单独预配计算资源。在 ClickHouse Cloud 中，这些资源在未使用时可以处于空闲状态 (因此不会产生费用) 。
- 虽然查询计算资源可以独立于摄取计算资源进行扩缩容，但它本质上仍与摄取量相关。我们假设随着摄取量增加，数据密度也会增长，从而导致查询时的扫描量变大，进而需要更多查询计算资源。
下表基于逐步增加的每秒摄取处理量 (单位为 MB) 给出了示例配置，同时列出了对应的每月数据量 (单位为 TB) 。这假设 ClickStack 在所有查询类型 (搜索、仪表板、告警) 上的持续平均负载为 1 QPS。
| MB/s | TB/月 | 摄取 CPU | 查询 CPU | 总 CPU | 总存储 (每月) (GB) |
|---|---|---|---|---|---|
| 10 | 25.92 | 1 | 3 | 4 | 2,592 |
| 20 | 51.84 | 2 | 6 | 8 | 5,184 |
| 50 | 129.6 | 5 | 15 | 20 | 12,960 |
| 100 | 259.2 | 10 | 30 | 40 | 25,920 |
| 200 | 518.4 | 20 | 60 | 80 | 51,840 |
| 500 | 1,296 | 50 | 150 | 200 | 129,600 |
| 1000 | 2,592 | 100 | 300 | 400 | 259,200 |
根据您的环境细化容量估算假设
该模型假设来自 ClickStack 的持续平均查询量为 1 QPS，涵盖搜索、仪表板和告警等所有查询类型。
对于更高的查询量，可按目标 QPS 线性增加 CPU 需求，即用 CPU 需求乘以目标 QPS。例如，一个以 100 MB/s 速率摄取数据且目标为 9 QPS 的部署，需要 90 个查询 CPU (10 × 9) ，而不是基准的 10 个，因此修正后的总 CPU 数为 100 个 (10 个用于摄取 + 90 个用于查询) 。
存储估算采用保守的 10 倍压缩率。实际情况下，日志、链路追踪和指标通常能达到更高的压缩率。我们建议先用一部分样本数据进行测试，在投入生产前确定压缩率和存储需求。要计算更长保留期所需的存储量，请将每月存储量乘以需要保留的月数。
这假设查询分布相对均衡。若工作负载偏向更重的历史查询或归档查询，计算需求可能会显著不同，应通过负载测试进行验证。我们计划引入更灵活的容量估算模型，以便根据不同的查询分布模式推算查询侧的计算需求。
计算示例
**要求：**每月摄取 1.5 PB，5 QPS，保留 3 个月。
转换为 MB/s
容量规划模型以 MB/s 表示。将每月 1.5 PB (1,500 TB) 换算为持续处理量：
- 1,500 TB = 1,500,000,000 MB
- 每月秒数 (30 天) ：30 × 24 × 60 × 60 = 2,592,000
- MB/s = 1,500,000,000 ÷ 2,592,000 ≈ 579 MB/s
摄取计算资源
按每 10 MB/s 的持续摄取需要 1 个 vCPU 计算：
579 ÷ 10 = 摄取需要 约 58 个 vCPU
查询计算资源
查询计算资源会随摄取处理量和 QPS 同步增长。在 5 QPS 下：
(579 ÷ 10) × 5 = 58 × 5 = 查询需要 290 个 vCPU
存储
按 30 天持续 579 MB/s 计算，原始摄取量等于每月 1,500 TB。应用假设的 10 倍压缩率后：
- 每月压缩后：1,500 TB ÷ 10 = 150 TB/月
- 保留 3 个月：150 TB × 3 = 共 450 TB
总结
| 资源 | 数值 |
|---|---|
| 摄取计算资源 | 58 个 vCPU |
| 查询计算资源 | 290 个 vCPU |
| 总计算资源 | 348 个 vCPU |
| 每月存储 (压缩后) | 150 TB |
| 3 个月保留期所需存储 | 450 TB |
隔离可观测性工作负载
如果您要将 ClickStack 添加到一个现有的 ClickHouse Cloud 服务中，而该服务已承载其他工作负载 (例如实时应用分析) ，则强烈建议隔离可观测性流量。
使用 托管仓库 创建一个专用于 ClickStack 的子服务。这可以让您：
- 将摄取和查询负载与现有应用隔离
- 独立扩展可观测性工作负载
- 防止可观测性查询影响生产分析
- 在需要时跨服务共享相同的底层数据集
这种方法可确保现有工作负载不受影响，同时让 ClickStack 能够随着可观测性数据的增长独立扩展。
对于更大规模的部署或自定义容量规划建议，请联系 Support 以获取更准确的评估。
