跳转到主要内容
以下内容提供了一个模型，用于根据您预期的摄取量估算 ClickStack 部署所需的计算和存储资源。得出的数值仅为估算值，应作为初始基线参考——并非固定不变的标准答案。实际需求取决于查询复杂度、并发度、保留策略以及摄取吞吐量的波动情况。请始终监控资源使用情况，并根据需要进行扩缩容。
所有数值均基于未压缩的原始摄取数据本页中的所有数字——吞吐量 (MB/s、TB/月) 、CPU 规模和存储——都以未压缩的原始摄取量表示，也就是应用程序生成并发送到 OpenTelemetry collector、在应用任何压缩之前的数据大小。您应根据现有的日志、链路追踪和指标管道来估算这一数值。下表中的存储数值已经按该原始数据量套用了假设的 10x 压缩率。
部署 ClickStack 时，需要为两类相互独立的工作负载预配计算资源：摄取 和 查询。
WorkloadEstimated resources
Ingest持续摄取吞吐量每 10 MB/s 需要 1 vCPU
Query每 1 QPS 以及每 10 MB/s 的持续摄取吞吐量需要 1 vCPU
查询与摄取的隔离在大多数自管理部署中，摄取和查询共享同一组节点。在这种情况下，请将 Total CPUs 作为基线。隔离扩缩容——即分别为摄取和查询独立预配计算资源——在 ClickHouse Cloud 中可通过独立计算池 (也称为 Warehouses) 实现。
  • 存储采用 10x 压缩率——对于日志和链路追踪来说，这通常是一个较为保守的估计。
  • 查询 SLA 假设为 P50 1.5 秒、P99 5 秒。
  • 我们假设大多数查询都针对近期数据，遵循一种在约 1 小时处达到峰值、并延伸至约 6 小时的对数正态分布。对于较旧数据的查询，用户可能希望预配专用计算资源。在 ClickHouse Cloud 中，这部分计算资源在不使用时可以处于闲置状态 (因此不会产生费用) 。
  • 虽然查询计算资源可以独立于摄取计算资源进行扩缩容，但它在本质上仍与摄取量相关。我们假设随着摄取量增加，数据密度也会提高，从而导致查询时扫描的数据量更大，因此需要更多查询计算资源。
下表给出了示例规格，基于以每秒 MB 为单位递增的摄取吞吐量，以及对应的每月 TB 数据量。这里假设 ClickStack 在所有查询类型 (搜索、仪表盘、告警) 上的持续平均值为 1 QPS。
MB/sTB/monthIngest CPUsQuery CPUsTotal CPUsTotal Storage (per month) (GB)
1025.921342,592
2051.842685,184
50129.65152012,960
100259.210304025,920
200518.420608051,840
5001,29650150200129,600
10002,592100300400259,200

​
针对您的环境细化容量估算假设

该模型假设来自 ClickStack 的持续平均查询速率为 1 QPS，涵盖所有查询类型，包括搜索、仪表盘和告警。 对于更高的查询量，可按目标 QPS 线性增加 CPU 需求，即将 CPU 需求乘以目标 QPS。例如，一个以 100 MB/s 速率摄取数据且目标为 9 QPS 的部署，将需要 90 个查询 CPU (10 × 9) ，而不是基线的 10 个，因此调整后的总需求为 100 个 CPU (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 随着可观测性数据的增长独立扩展。 对于更大规模的部署或需要自定义规格建议的场景，请联系支持团队，以获得更准确的容量评估。
最后修改于 2026年6月10日