如何实现mysql实时同步到clickhouse

实时同步，可以用canal来监听mysql，再写逻辑同步到ck，不过日志增量特别大的时候，mysql insert也很费劲吧，更别说update，瓶颈还是在mysql，所以还是把日志数据迁移到ck，业务直接操作ck更好

1. ck不适合做业务，同步日志是可以的，日志不会有update 和 delete，日志同步ck可以用kafka,数据推到kafka，ck有自带功能，从kafka写到自己的表里
2. 订单表上千万，按理不应该啊，如果真的这样，可以分表分库，按时间切分纵向切分，按业务横向切分。

mongodb不考虑吗？

新增和更新全部改成新增到 clickhouse, clickhouse 引擎选择 ReplacingMegeTree, 查数据的时候加 final 关键字

不可以历史数据插入clickhouse 实时可能会变更的数据还是存mysql吗

之前写过一个go项目将mysql同步到clickhouse，存量用golang操作mysqldump然后解析数据，增量监听mysql-binlog 数量量数十几亿的样子、去重用leveldb 跑起来很快

Clickhouse 不适合做数据更新，千万级别的数据更新一条记录可能就得几十秒甚至更多，订单这种频繁的状态更新的数据会直接压垮 Clickhouse

ClickHouse 主要面向的是海量数据的批量写入和查询场景，不适合单条数据频繁操作，主要原因如下：

1. 列式存储架构的更新操作需要定位并更改每一列中的数据，成本较高；
2. 列式存储的批量压缩和分区存储机制使得单行更新或删除数据需要重新组织、合并底层数据文件，这会导致性能瓶颈；
3. ClickHouse 最常用的存储引擎是 MergeTree，它采用分区和排序键的方式存储数据。虽然 ClickHouse 支持 ALTER DELETE 和 ALTER UPDATE 操作，但这些操作实际上并不是即时生效的。它们会标记要删除或更新的数据行，并在后续的后台合并（merge）任务中将其实际处理；

最终表现在实际体验上就是，频繁的行操作，会导致 Clickhouse 占用资源非常高（甚至是服务不可用），总之如果数据不是像日志、指标类的不可变数据，最好不要用 Clickhouse，虽然也有一些方案可以避免更新操作，但是依然无法避免单条数据的插入和删除操作，例如：使用 ReplacingMergeTree 引擎的，然后通过附加版本字段，来过滤掉相同 ID 的历史版本数据行（这也就是 CloudCanal 为什么为产生 _version 字段的原因，这是行业的最佳实践）。

日志类的 可以考虑 parquet 格式, 有个flow-php 的库 ，据说压缩140倍 查询几百毫秒 可以一个目录下多个文件的查询，open-observe 背后就是这个日志文件来寸log的。

ClickHouse 压根不适合你的场景

clickhouse有mysql引擎，直接在clickhouse里面查询mysql数据。如果频繁删除和更新的数据，不要用clickhouse，不适合它。数据同步的话，用canal自己开发一个多对多的同步工具吧

Apache Doris + Apache Seatunnel， Seatunnel 使用Mysql-CDC source connector。

订单表能不能冷热数据分开，才千万，我们之前2亿的表，照样很快，定时把不需要的数据备份，这样的话你们的业务表能够大概率能够保持动态增长。

自建考虑postgres、StarRocks等，云产品考虑hologres 通过flink-cdc实时同步mysql的binlog

ClickHouse 的引擎不适合你现在的这个场景，可以考虑一下用字节的ByteHouse。 至于如何同步数据的话，考虑一下监听mysql的biglog方案？