 ｜ ReplicatedReplacingMergeTr)
文章目录
- ClickHouse 大数据量场景下执行 ALTER TABLE UPDATE问题
- 问题描述
- 官方文档
- ClickHouse 修改数据的最佳实践（大数据量/生产）
- 只进不出，只增不改
- ReplacingMergeTree：同一主键多版本，取最新
- CollapsingMergeTree：用正负记录“抵消”
- ReplicatedReplacingMergeTree 和ReplicatedMergeTree 区别
- ReplicatedMergeTree 业务重复：同一事件被上游多次投递
ClickHouse 大数据量场景下执行 ALTER TABLE UPDATE问题
问题描述
在 ClickHouse 大数据量场景下执行 ALTER TABLE UPDATE 需要谨慎：
风险点
- 资源消耗大
ALTER TABLE UPDATE 会触发 mutation，本质是重写所有相关的数据 part
大表可能导致：磁盘 I/O 飙升、CPU 占用高、内存压力大。
Mutation 会对命中的数据 以 part 为单位重写（更准确说：对包含被影响行的 parts 生成新的变体并替换），因此会带来显著的 磁盘读写、CPU（解压/重压缩）、后台 merge 压力。命中范围越大、压缩算法越重、列越多，成本越高。 - 执行时间长
mutation 是异步后台执行，大表可能需要几小时甚至更久。
期间会持续消耗集群资源。 - 可能影响查询性能
mutation 执行期间，读写性能可能下降
如果是生产环境，可能影响业务 - 无法回滚
ClickHouse 的 mutation 不支持回滚。你可以 KILL MUTATION 来停止尚未完成的 mutation，但：已经生成并替换的 parts 不会“自动回到旧版本”
一旦执行，只能等待完成或手动 kill
官方文档
官方文档：
)
)
