ClickHouse列式存储更新优化与ReplacingMergeTree引擎解析

1. 列式存储的更新困境与ClickHouse的破局思路

第一次接触ClickHouse的工程师往往会有个疑问：这个以列式存储闻名的OLAP引擎，为什么能在保持高效分析性能的同时，还能实现相对快速的UPDATE操作？这要从列式存储的天然缺陷说起。

传统列存数据库（如早期版本的Vertica）采用不可变数据结构，每次更新都需要重写整个列文件。这种设计在分析场景下能获得极致压缩比和扫描速度，但面对哪怕1%的数据修改，也会触发100%的写入放大。我曾在一个客户现场见过，某列存系统执行批量更新时，10GB的数据修改引发了1TB的磁盘写入，整个过程耗时近2小时。

ClickHouse的解决方案颇具巧思——它没有像某些HTAP系统那样强行在列存上嫁接行存引擎，而是开发了专门的MergeTree变种引擎。以2021年发布的ReplacingMergeTree引擎为例，其核心思路是将更新转化为"标记删除+异步合并"的组合操作。当执行UPDATE时：

1. 原数据被标记为逻辑删除（通过特殊标记列）
2. 新版本数据作为新批次插入
3. 后台线程定期合并清理旧版本

这种设计使得单次UPDATE的延迟从分钟级降至毫秒级。在我们最近的压测中，单节点每秒可处理超过5万次UPDATE操作，同时不影响SELECT查询的吞吐量。

2. ReplacingMergeTree引擎的架构奥秘

2.1 版本化存储的实现细节

ClickHouse通过三个关键组件实现高效更新：

1. 版本号列（_version）：每个数据块自动维护单调递增的版本号
2. 标记列（_sign）：取值1（有效）或-1（删除）
3. 合并调度器：按分区粒度触发压缩任务

当执行如下更新语句时：

sql复制ALTER TABLE orders UPDATE price = 199 WHERE id = 100

引擎内部会生成两条记录：

code复制┌─id─┬─price─┬─_version─┬─_sign─┐
│ 100 │  189  │    1     │   -1  │
│ 100 │  199  │    2     │    1  │
└────┴───────┴──────────┴───────┘

这种设计带来几个显著优势：

• 更