【列存引擎内核】配置陷阱与容量规划

ClickHouse 默认 settings 面向 中等 batch 的通用 OLAP——直接接 Kafka 小消息或 ORM 逐行 insert 时，默认 parts_to_throw_insert 与 merge 池大小 并不「自动适配业务」。本文梳理 MergeTree 与服务器级 易踩配置、SSD/HDD 差异、内存与磁盘容量估算方法，交叉 故障模式（第 15 篇） 与 监控（第 14 篇）。

不给虚构 TPS/磁盘数字——给出公式与检查清单，数值在目标环境代入。

版本锚定：ClickHouse 24.x LTS。

一、配置层级

表级 MergeTree settings 优先级高——适合 per-table 调 parts 阈值。

二、parts_to_throw_insert / parts_to_delay_insert

2.1 语义

• parts_to_delay_insert：单分区 active parts 超阈值 → insert sleep 降速；
• parts_to_throw_insert：更高阈值 → 拒绝 insert。

（默认值查 24.x 文档——版本间可能调整。）

2.2 陷阱

2.3 规划方法

1. 估算峰值 insert RPS × 每 insert part 数；
2. 估算 merge 吞吐（parts/hour）—— 须实测 system.events MergedRows；
3. 稳态 parts ≈ ingest / merge_rate × 安全系数；
4. 设置 delay < throw，留 margin。

监控：system.parts count 趋势（第 14 篇）。

三、merge 线程池与并发

3.1 相关 settings

池过小 → merge lag；过大 → IO/CPU 争抢。

3.2 SSD vs HDD

HDD 上 小 part 随机读 也伤害查询——不只 merge 问题（读路径 第 05 篇）。

3.3 max_bytes_to_merge_at_max_space_in_pool

限制单次 merge 选中 part 总大小——防 merge 内存/磁盘峰值。过大 part 无法合并时 level 停滞：

SELECT max(bytes_on_disk) FROM system.parts WHERE active AND table = 't';

若接近该 setting，需 OPTIMIZE 或调高（权衡内存）。

四、merge_max_block_size

控制 merge 输出 block 行数上界——影响 merged part 粒度与后续 merge 频率。

• 过大：单次 merge 耗时长、内存高；
• 过小：part 仍碎、metadata 多。

与 max_insert_block_size 协调——insert block 与 merge block 同一量级常更稳。

五、内存预算

5.1 三层 limit

单查询 max_memory_usage
    ↓
用户 max_memory_usage_for_user
    ↓
进程 max_server_memory_usage (或 ratio)

5.2 merge/mutation 内存

Merge 占用常接近 合并 part 解压和——规划 RAM：

\[ M_{\text{server}} \geq M_{\text{queries}} + M_{\text{merge}} + M_{\text{os cache}} \]

\(M_{\text{merge}}\) 粗估：并发 merge 数 × 单 merge max_bytes_to_merge 解压系数——解压后常 2–10× 压缩比，依 编码（第 03 篇） 而定，须抽样测。

5.3 external group by / sort

max_bytes_before_external_group_by、max_bytes_before_external_sort 触发磁盘 spill——SSD 路径必配 tmp_path 空间。

六、磁盘容量

6.1 组成

• 数据 part（压缩）；
• 合并临时空间（峰值可达 同时存在输入 part + 输出 part）；
• mutation 重写；
• system / log；
• detached_parts 泄漏。

6.2 安全系数

规划可用磁盘：

\[ D_{\text{need}} = D_{\text{data}} \times (1 + f_{\text{merge}} + f_{\text{mutation}} + f_{\text{headroom}}) \]

\(f_{\text{headroom}}\) 工程上常 0.2–0.3，视 compaction 策略实测——不写死 1.3。

6.3 TTL 与 S3

TTL ... TO DISK 'cold' / TO VOLUME —— 热层 SSD 容量单独规划；冷层延迟接受。

七、insert 路径 settings

Kafka：kafka_max_block_size、stream_flush_interval_ms（名以文档为准）。

八、查询与并发

只读副本 + max_threads 限制给 BI，保护 ingest 节点。

九、分布式配置

集群容量 = shard 数 × 单 shard 规划——非线性（协调节点、Keeper）。

第 09 篇。

十、ReplicatedMergeTree 与 Keeper

• Keeper 节点数 3/5 odd；
• 磁盘低延迟 SSD；
• session_timeout_ms 与网络抖动；
• 勿与 heavy log 盘混用。

副本数 × 数据 = 总存储——HA 成本线性增。

第 08 篇。

十一、表 DDL 容量相关

第 07 篇 索引。

十二、DuckDB 容量对照

无 parts_to_throw——但 单文件过大 checkpoint 慢；Parquet 外链不增 DB 文件。

第 11 篇。

十三、容量规划工作流

flowchart TD
  A[业务: 保留期 × 行宽 × QPS] --> B[估算压缩后数据量]
  B --> C[选 PARTITION/ORDER BY]
  C --> D[测 insert batch + parts 增长率]
  D --> E[测 merge 吞吐]
  E --> F[定 parts 阈值 + merge 池]
  F --> G[定 RAM: query + merge]
  G --> H[定磁盘: 数据 + merge 峰值]
  H --> I[监控告警上线]

1. 用 representational 负载灌测试集群；
2. 跑 24–72h 观察 system.parts、merges；
3. 调 settings 后重复；
4. 文档化 团队 insert 规范（batch 大小）。

十四、配置审查 checklist

• 每表 MergeTree parts_to_* 是否与 ingest 匹配
• merge 池与 CPU/磁盘匹配
• max_server_memory_usage 是否留 OS cache
• 磁盘告警 70%/85%
• TTL 是否控制保留期
• 分布式 internal_replication 正确
• mutation 策略（避免大 UPDATE）
• query_log 保留与磁盘

十五、学术谱系：容量规划 · 云盘 IOPS · 论文单机 SSD

C-Store / X100 实验多在 本地高速盘、独占机器；生产容量规划要乘上 副本、Distributed 分片、云盘 IOPS 配额与 merge 并发。

15.1 开放问题

1. 对象存储作主盘时，merge 并发上限如何定？ 可检验：降 max_replicated_merges_in_queue 后 ingest 与查询延迟（入口：第 02/03 篇云盘开放问题；CH storage policy）。
2. 默认 config 是否应强制最小 insert batch？ 工程争议；与第 15 篇 too many parts 直接相关。

十六、小结

容量规划 = insert 模式 + merge 能力 + 内存/磁盘三角；默认 config 不会替业务做 batch。SSD 与 HDD 策略差异在 merge 并发与 insert 粒度；Replicated 与 Distributed 乘法存储。

附录 A、storage_policy 多卷示例结构

<!-- 合成示例，部署前验证 -->
<storage_configuration>
  <disks>
    <hot><path>/mnt/nvme/clickhouse/</path></hot>
    <cold><path>/mnt/hdd/clickhouse/</path></cold>
  </disks>
  <policies>
    <tiered>
      <volumes>
        <hot><disk>hot</disk></hot>
        <cold><disk>cold</disk></cold>
      </volumes>
    </tiered>
  </policies>
</storage_configuration>

表 SETTINGS storage_policy='tiered' + TTL MOVE。

附录 B、mark_cache / uncompressed_cache

Mark cache 减少 .mrk 随机读；uncompressed cache 缓存热点解压块——RAM 充足时可调高 比例，须测 hit rate（system.metrics 相关项视版本）。

附录 C、users.xml 配额

<profiles>
  <readonly>
    <readonly>1</readonly>
    <max_execution_time>300</max_execution_time>
  </readonly>
</profiles>

BI 只读 profile 限制 max_memory_usage 防拖垮集群。

附录 D、网络带宽

Distributed scatter-gather 与 replication 复制争用带宽——跨 DC 复制需限速 settings（max_replicated_fetches_network_bandwidth 等，查文档）。

上一篇：经典故障

下一篇：系列索引

参考资料

核心论文 / 坐标

1. C-Store / X100 单机实验假设 vs 本篇云盘/副本乘法——工程间隙见正文 §十五。

规范 / 源码 / 文档

2. ClickHouse Documentation, MergeTree settings、Server settings、Storage policies、TTL（24.x；A 级）。
3. 本系列 第 14、15 篇。