> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-mintlify-8c05c8a2.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# 资源预估

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

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

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

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

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

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

| Workload   | Estimated resources                   |
| ---------- | ------------------------------------- |
| **Ingest** | 持续摄取吞吐量每 10 MB/s 需要 1 vCPU            |
| **Query**  | 每 1 QPS 以及每 10 MB/s 的持续摄取吞吐量需要 1 vCPU |

<Info>
  **查询与摄取的隔离**

  在大多数自管理部署中，摄取和查询共享同一组节点。在这种情况下，请将 **Total CPUs** 作为基线。隔离扩缩容——即分别为摄取和查询独立预配计算资源——在 ClickHouse Cloud 中可通过[独立计算池 (也称为 Warehouses) ](/zh/products/cloud/features/infrastructure/warehouses)实现。
</Info>

<Accordion title="假设">
  * 存储采用 **10x 压缩率**——对于日志和链路追踪来说，这通常是一个较为保守的估计。
  * 查询 SLA 假设为 P50 1.5 秒、P99 5 秒。
  * 我们假设大多数查询都针对近期数据，遵循一种在约 1 小时处达到峰值、并延伸至约 6 小时的对数正态分布。对于较旧数据的查询，用户可能希望预配专用计算资源。在 ClickHouse Cloud 中，这部分计算资源在不使用时可以处于闲置状态 (因此不会产生费用) 。
  * 虽然查询计算资源可以独立于摄取计算资源进行扩缩容，但它在本质上仍与摄取量相关。我们假设随着摄取量增加，数据密度也会提高，从而导致查询时扫描的数据量更大，因此需要更多查询计算资源。
</Accordion>

下表给出了示例规格，基于以每秒 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 |

<div id="refining-sizing-assumptions">
  ## 针对您的环境细化容量估算假设
</div>

该模型假设来自 ClickStack 的持续平均查询速率为 1 QPS，涵盖所有查询类型，包括搜索、仪表盘和告警。

对于更高的查询量，可按目标 QPS 线性增加 CPU 需求，即将 CPU 需求乘以目标 QPS。例如，一个以 100 MB/s 速率摄取数据且目标为 9 QPS 的部署，将需要 90 个查询 CPU (10 × 9) ，而不是基线的 10 个，因此调整后的总需求为 100 个 CPU (10 个用于摄取 + 90 个用于查询) 。

存储估算采用保守的 10 倍压缩率。实际情况下，日志、链路追踪和指标通常能达到更高的压缩率。我们建议先基于一部分样本数据进行测试，在进入生产环境前提前确定压缩率和存储需求。若需计算更长保留期所需的存储容量，可将每月存储量乘以所需保留的月数。

以上假设查询分布相对均衡。若工作负载更偏向较重的历史查询或归档查询，则所需计算资源可能会有显著差异，应通过负载测试进行验证。我们计划推出一个更灵活的容量规划模型，以便根据不同的查询分布模式推算查询所需的计算资源。

<div id="worked-example">
  ### 示例计算
</div>

**需求：** 每月摄取 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     |

<div id="isolating-workloads">
  ## 隔离可观测性工作负载
</div>

如果你要将 ClickStack 添加到一个**现有的 ClickHouse Cloud 服务**中，而该服务已经承载了其他工作负载 (例如实时应用分析) ，则强烈建议将可观测性流量隔离开来。

使用 [**托管仓库**](/zh/products/cloud/features/infrastructure/warehouses) 创建一个专用于 ClickStack 的**子服务**。这样可以：

* 将摄取和查询负载与现有应用隔离
* 独立扩展可观测性工作负载
* 避免可观测性查询影响生产环境分析
* 在需要时跨服务共享相同的底层数据

这种方式既能确保现有工作负载不受影响，又能让 ClickStack 随着可观测性数据的增长独立扩展。

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