ClickHouse 更新操作

clickhouse 更多应用在 查询select  和写入insert  上。 提供部分更新操作，但相比其他各大数据库的更新操作来说，效果已经很好了，下面来详细介绍一下 更新这一块。

更新：

1.

update 及 delete 可以借用 alter table  进行单机表少量数据操作，（提示：truncate table  大量数据会造成卡顿，若在未完全清理情况下 ctrl+c 强行退出，则会造成表数据残缺，严重可致server 挂掉。），

2.

也可借用Mutations  进行多行更新删除操作。(根据where条件获取需要修改的分区，通过构建新分区替代老分区实现更新操作 ，但对于大分区，默认150G的数据更新可能会消耗大量资源)  此操作不受server重启影响，会执行至操作成功，可system.mutations 追踪，KILL MUTATION停止进程。

以上是针对单机表的更新操作，

3.

针对集群表可适用ReplacingMergeTree 进行后台更新处理，搭配主键使用。存在相同主键数据时 取 distributed(version) 中 version 更大的版本数据。默认为空即最后写入的数据，但实际实时数仓业务场景可能存在先到后到的问题，造成旧数据替换新数据的情况。因此version尽量选择 原始数据的初始时间，避免更新错误（若时间精度达到毫秒级，则取clickhouse最后写入的数据为最终结果）。若少量数据更新，也可使用optimize table  触发更新修复操作，更快查询更新结果。同时还有 select *from  final  的查询方法。此方法只为查询合并后的数据，但实际数据并没有merge更新。仅为结构查询使用。可能会影响查询性能。有待使用者自行测试。

提示：1.集群表分发策略要将指定数据分发至相同单机，最好不要rand()分发。2.更新方法有很多，业务不同，需要自测并找到最合适自己的。

此引擎默认后台更新，但官方提示，不要过于依赖此引擎。即后台更新存在异步性，不完整性。可能会造成一些误差和延迟。我这里每批数据大约会有极少量merge合并失败，即相同数据存储多条的情况，个人理解异步merge跟数据量有一定关系。当数据达到了指定大小时 会触发相同层tree data 会进行merge合并。叶子节点的数据层层向上合，至一定量停止。单批次写入数据量越多，触发merge几率也越大。但不能开多个线程，单条单条频繁查询，这样不仅不会触发频繁merge 且会占用server资源。造成卡顿。少批次大批量更适合clickhouse。

实际应用中，各自业务需求不同，用户需根据实际业务场景选择更合适的更新方法。

但总体上，clickhouse 因为存储上，批量数据直接写入存储文件的原因，主要核心是查询 ，而不是修改，尽量减少数据更改的操作。