资源预估

托管 ClickStack 部署的资源预估指南

以下内容提供了一个模型，用于根据您预期的摄取量估算 ClickStack 部署所需的计算和存储资源。得出的数值仅为估算值，应作为初始基线参考——并非固定不变的标准答案。实际需求取决于查询复杂度、并发度、保留策略以及摄取吞吐量的波动情况。请始终监控资源使用情况，并根据需要进行扩缩容。

所有数值均基于未压缩的原始摄取数据

本页中的所有数字——吞吐量 (MB/s、TB/月) 、CPU 规模和存储——都以未压缩的原始摄取量表示，也就是应用程序生成并发送到 OpenTelemetry collector、在应用任何压缩之前的数据大小。

您应根据现有的日志、链路追踪和指标管道来估算这一数值。下表中的存储数值已经按该原始数据量套用了假设的 10x 压缩率。

部署 ClickStack 时，需要为两类相互独立的工作负载预配计算资源：摄取 和 查询。

Workload	Estimated 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/s	TB/month	Ingest CPUs	Query CPUs	Total CPUs	Total Storage (per month) (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 个，因此调整后的总需求为 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 随着可观测性数据的增长独立扩展。

对于更大规模的部署或需要自定义规格建议的场景，请联系支持团队，以获得更准确的容量评估。