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

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

该模型假设来自 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
汇总

​
隔离可观测性工作负载

如果你要将 ClickStack 添加到一个现有的 ClickHouse Cloud 服务中，而该服务已经承载了其他工作负载 (例如实时应用分析) ，则强烈建议将可观测性流量隔离开来。 使用 托管仓库 创建一个专用于 ClickStack 的子服务。这样可以：
  • 将摄取和查询负载与现有应用隔离
  • 独立扩展可观测性工作负载
  • 避免可观测性查询影响生产环境分析
  • 在需要时跨服务共享相同的底层数据
这种方式既能确保现有工作负载不受影响，又能让 ClickStack 随着可观测性数据的增长独立扩展。 同样的功能也可用于将上文估算的摄取计算资源与查询计算资源分别部署为独立服务，从而各自独立扩展。请参阅我们的指南隔离读写工作负载。 对于更大规模的部署或需要自定义规格建议的场景，请联系支持团队，以获得更准确的容量评估。
最后修改于 2026年9月26日