clickhouse 生产集群部署之坑坑洼洼（四）

业务场景：存在实时数据，需要更新

当前情况：单机表可以实现 增删改查操作。但是集群表不行，特此引入ReplacingMergeTree引擎，实施ch后台自动去重操作

特别提示：该引擎不能完全依赖去做去重，可能因为merge合并及诸多原因，存在极少量去重失败情况

实际部署：

本地表：

ReplacingMergeTree(【ver】) PARTITION BY day PRIMARY KEY MsgId ORDER BY (MsgId, updateTime) 

集群表：

Distributed(cluster_name, database, table, toUnixTimestamp(updateTime))

提示：

集群表按toUnixTimestamp(updateTime)  分发，以便于当遇到重复数据时，数据能准确分发到指定的那个单机ch中，而不是相同数据rand()随机分发，致前后位置不一，无法去重。

本地表以MsgId 做唯一主键，默认，MsgId, updateTime 排序。而按【ver】字段判断数据版本。该字段可以是INT或datatime类型。我用的实时插入的now()。当ch_server在进行merge时，查到相同主键的数据 ，会去自动判别ver版本，取最新的版本数据做保留。本质上来讲，该引擎原本是为了减少存储空间，过滤垃圾数据而做的。恰巧可以借此做去重。可能会因数据源写入超时等原因，产生少量merge失败的情况，无法解决去重问题。

 

merge数据存储合并问题：

MergeTree  引擎数据存储结构为上图，其中：

20200421代表 分区id

31014 代表 最小block数

31223 代表最大 block数

3 代表 tree的深度。即合并层级

数据会以上图形式，进行相应合并。由此看出，MergeTree  引擎 的异步去重机制，与数据量写入频率，数据量大小也有一定关系。

异步去重机制，一般要几分钟之后才会自动去重，可以做测试等待一段时间。且连续写入数据。

OPTIMIZE TABLE 本地表。可以快速刷新数据，即时查看去重效果。但性能影响较大，不建议实时刷新