同步有性能问题

[liyanginchina]

我是从 mysql-clickhouse-replication看到mysql2ch的，如果是小规模业务使用，勉强够用。
为什么这么说呢，因为clickhouse的优势是批量写入和OLAP，在数据的修复和删除方面，性能非常的差，在这个项目中，只是从功能上满足的同步的需求，但性能方面有较大的问题。
基于MergeTree引擎来做，如何做到大数据量下的数据实时同步，通过实践来看，MergeTree家族中VersionedCollapsingMergeTree是一个更适合同步场景的方案。官方链接：https://clickhouse.tech/docs/zh/engines/table-engines/mergetree-family/versionedcollapsingmergetree/#versionedcollapsingmergetree

版本折叠合并树
这个引擎:

允许快速写入不断变化的对象状态。
删除后台中的旧对象状态。 这显着降低了存储体积。
请参阅部分 崩溃 有关详细信息。

引擎继承自 MergeTree 并将折叠行的逻辑添加到合并数据部分的算法中。 VersionedCollapsingMergeTree 用于相同的目的 折叠树 但使用不同的折叠算法，允许以多个线程的任何顺序插入数据。 特别是， Version 列有助于正确折叠行，即使它们以错误的顺序插入。

非常适合数据库同步，特别是mysql数据在不断变化的同步，因此基于这个引擎实现了我们内部有mysql--->clickhouse同步方案。
此方案是将DML全部转换成insert语句，依靠clickhouse的批量写入优势，再结合VersionedCollapsingMergeTree引擎的特点，基于version进行数据版本控制，最终形成升级的方案。

从原理上来看，实现思路是一致的，如：
1、kafka、redis支持；
2、多线程支持；
3、数据库、数据表的自定义配置；
4、基于binlog；
5、ETL外部动态加载方法；
6、高实时，TPS相较于此方案，有数量级的提升，特别是数据库高并发场景下；

缺点：查询会稍微麻烦一点，需要进行查询的聚合，官方给出的sql如下：
SELECT
UserID,
sum(PageViews * Sign) AS PageViews,
sum(Duration * Sign) AS Duration,
Version
FROM UAct
GROUP BY UserID, Version
HAVING sum(Sign) > 0

目前此方案应用于地铁领域的实施数据交易处理，用于大数据报表，主要处理金融业务，目前使用良好，欢迎交流！

[long2ice]

就是说每张表加入一个version和sign字段，然后查询的时候只选择version最新的那一条，sign标记是否删除。
其实这个项目的性能问题最初实现的时候已经考虑过，目前的方案肯定是性能较低的，不过我也没有测过具体的性能，并且当前的业务场景够用，就暂时没有考虑。
而下一步的开发计划主要在于实现postgres->clickhouse。
不过性能问题肯定也是需要考虑的，如果VersionedCollapsingMergeTree能够做到对外部透明就好了。

[long2ice]

可以进QQ群一起交流讨论，二维码在README里面

[piaohailin]

群号还在吗？没有找到