ClickHouse的数据一致性（七）

目录

• 数据一致性的方案
• 1 手动使用OPTIMIZE（强烈不建议生产上使用）
• 2 通过 Group by 去重
• 3 通过 FINAL 查询

数据一致性的方案

查询 CK 手册发现，即便对数据一致性支持最好的 Mergetree，也只是保证最终一致性:

• 1手动使用OPTIMIZE
• 2 通过 Group by 去重
• 3 通过 FINAL 查询

我们在使用 ReplacingMergeTree、SummingMergeTree 这类表引擎的时候，会出现短暂 数据不一致的情况。在某些对一致性非常敏感的场景，通常有以下几种解决方案。

1 手动使用OPTIMIZE（强烈不建议生产上使用）

在写入数据后，立刻执行 OPTIMIZE 强制触发新写入分区的合并动作。

OPTIMIZE TABLE table_name FINAL;语法:OPTIMIZE TABLE [db.]name [ON CLUSTER cluster] [PARTITION partition | PARTITION ID 'partition_id'] [FINAL] [DEDUPLICATE [BY expression]]

2 通过 Group by 去重

此方法通常需要在创建表时，添加删除标识字段：比如is_deleted，默认为0，0代表未删除，1代表已删除；并且需要以时间为索引进行order by排序。

(1)执行去重的查询

SELECT    user_id ,  argMax(score, create_time) AS score,  argMax(is_deleted, create_time) AS deleted,  max(create_time) AS ctimeFROM test_aGROUP BY user_idHAVING deleted = 0;

函数说明:

argMax(field1，field2):按照 field2 的最大值取 field1 的值。当我们更新数据时，会写入一行新的数据，例如上面语句中，通过查询最大的create_time 得到修改后的 score 字段值。

注意：ClickHouse并不能很好的支持事务型数据的删除，但是可以通过其他策略支持删除，比如is_deleted字段来支持数据，如果将某user_id删除，即将某user_id对应的is_deleted置为1。

然而，这行数据并没有被真正的删除，而是被过滤掉了。在一些合适的场景下，也可以结合表级别的TTL 最终将物理数据删除。

3 通过 FINAL 查询

在查询语句后增加 FINAL 修饰符，这样在查询的过程中将会执行 Merge 的特殊逻辑(例 如数据去重，预聚合等)。

但是这种方法在早期版本基本没有人使用，因为在增加 FINAL 之后，我们的查询将会变 成一个单线程的执行过程，查询速度非常慢。

在 v20.5.2.7-stable 版本中，FINAL 查询支持多线程执行，并且可以通过 max_final_threads 参数控制单个查询的线程数。但是目前读取 part 部分的动作依然是串行的。

FINAL 查询最终的性能和很多因素相关，列字段的大小、分区的数量等等都会影响到最 终的查询时间，所以还要结合实际场景取舍。

参考链接：https://github.com/ClickHouse/ClickHouse/pull/10463