基于 go-zero 构建的 CDS 数据同步与 ClickHouse 的建表方案紧密相关,下面介绍了两种建表方案。
实时表
起初 ClickHouse 并未考虑数据更新的问题,在官网中有介绍 ClickHouse 诞生的历史。
https://clickhouse.tech/docs/en/introduction/history/
从中可以看出两点:
用于日志分析
使用非汇总数据在线计算
也就是说数据导入后不考虑变更,而且想要直接分析源数据。
但是现实中我们有很多有价值的数据在事务型数据库中存储,或者我们需要用到的数据在事务型数据库中。而事务型数据库中存储的是状态型数据 (可以发生变化),对于 ClickHouse 而言,数据更新是一个非常困难的操作。
因为上面提到的需求,更新这个功能在随后还是以 mutation 的形式加入了。这种 mutation 形式在官网中:
https://clickhouse.tech/docs/en/sql-reference/statements/alter/update/
有这样的描述 “this is a heavy operation not designed for frequent use.” 而且不支持更新用于计算主键或分区键的列。
可以看出,直接对数据执行更新操作对 ClickHouse 来说是一件非常糟糕的事。
这种情况在其他用于大数据处理的数据库中也存在,比如以 HDFS 为支撑的数据仓库,它同样更多的要求数据是不可变的。
即便提供了更新操作,性能都不佳。解决这个需求一般的方法是用程序定期的对过往的数据进行合并,形成一份最新的数据。这种方法的缺点是不能做到实时更新数
本文探讨了基于Go-zero构建的CDS数据同步项目中,如何使用ClickHouse的实时表和历史版本表引擎。实时表利用ReplacingMergeTree引擎处理实时更新,通过删除标志列处理删除操作。历史版本则采用普通MergeTree表配合时间戳和分区实现数据还原。两种方案各有优缺点,适用于不同场景。
最低0.47元/天 解锁文章

被折叠的 条评论
为什么被折叠?



