MySQL到ClickHouse数据同步方案对比

简介: ClickHouse在执行分析查询时的速度优势很好的弥补了MySQL的不足,但是对于很多开发者和DBA来说,如何将MySQL稳定、高效、简单的同步到ClickHouse却很困难。本文对比了NineData、MaterializeMySQL(ClickHouse自带)、Bifrost三款产品,看看他们在同步时的差异。

ClickHouse 在执行分析查询时的速度优势很好的弥补了 MySQL 的不足,但是对于很多开发者和DBA来说,如何将MySQL稳定、高效、简单的同步到 ClickHouse 却很困难。本文对比了 NineData、MaterializeMySQL(ClickHouse自带)、Bifrost 三款产品,看看他们在同步时的差异。

对比结果概述

整体上,NineData(官网:www.ninedata.cloud )的数据复制功能在功能、性能表现最突出。其次是Bifrost和ClickHouse自带的MaterializeMySQL。NineData在增量DDL的处理、字段映射的准确性、无主键表、以及功能丰富度上最强(数据校验、过滤、限流等),详细的对比如下图:

image.png

MySQL到ClickHouse数据同步产品对比结果概述

结构映射对比

在做了详细对比之后,对于基础类型,只有NineData考虑的更加完整,例如MySQL的datetime需要映射到ClickHouse的DateTime64,否则则可能出现数据丢失。如果使用Biforst或MaterializeMySQL等其他产品均映射到datetime可能会造成一定程度的数据精度丢失。

此外,在对比了MySQL全部数据类型之后,发现NineData支持更完整,例如对JSON类型、几何数据、地理信息仅NineData支持。此外,对于基础类型,也只有NineData考虑更加细致,使用Biforst或MaterializeMySQL等其他产品则可能导致精度丢失,从而造成数据丢失。

详细的对比如下图:

image.png

结构映射对比

无主键表支持

NineData对记录做了特殊的标记处理,所以很好的支持了无主键表的数据同步。而MaterializeMySQL、Biforst均不支持。

详细的对比如下图:

image.png

无主键表支持情况

增量DDL

对于数据增量同步,支持好各种类型的DDL是保障同步链路持续稳定的关键,NineData在无主键表DDL支持、字段删除、字段名修改等特殊操作均做了适配处理,可以很好的保障复制链路的问题。同时,NineData还提供了可视化的错误修复和跳过功能,可以最大限度的保障链路持续稳定。

详细的对比如下图:

image.png

增量DDL对比结果

限流、对比、过滤等

除了前面介绍的一般功能之外,为了提升数据质量、保障稳定,NineData还支持了包括数据对比、运行中的限流、数据过滤等功能。具体的说明如下:

image.png

增量DDL 限流、对比、过滤等对比结果

同步性能对比

这里使用 sysbench工具生成了5000万行记录进行全量性能对比,再生成约1800万次DML(约5GB Binlog)进行增量性能对比。

对比中,全量同步 NineData 性能为36.2W RPS(每秒同步记录数)为最高;增量同步则是 ClickHouse 自带的同步工具 MaterializeMySQL 最高,需要注意,MaterializeMySQL 在错误处理上比较简单,如果报错则需要全部重新同步。

详细的对比如下:

  • 全量同步

通过sysbench生成10张表,每张表500W记录(5000W行),数据文件大小约为12G:

image.png

同步性能对比

  • 增量同步

通过sysbench生成5G大小的BinLog日志(约1800W次DML),再进行增量同步:

image.png

增量同步

总结

NineDatahttps://www.ninedata.cloud/)在功能上领先其他同步工具,特别是字段类型的全面适配和增量复制期间DDL的支持度,并且在动态限流、数据对比、监控等能力上也支持的最完善。

所以,如果想把MySQL的数据实时同步到ClickHouse,推荐使用NineData,不仅使用简单(SaaS),并在满足功能和性能的前提下,实现了字段类型的无损转换和数据的实时复制,很好的解决MySQL 同步数据到ClickHouse的问题。

补充说明

当前各个云厂商虽然都提供ClickHouse托管服务,但是另一方面云厂商又都在发展自己的数仓产品,在同步功能支持上通常仅对自家的数仓产品支持比较好,而对ClickHouse同步支持都很薄弱。此外,开源工具Canal也因为不能很好的支持结构同步,使用和维护起来并不方便。

目录
相关文章
|
10月前
|
存储 消息中间件 监控
MySQL 到 ClickHouse 明细分析链路改造:数据校验、补偿与延迟治理
蒋星熠Jaxonic,数据领域技术深耕者。擅长MySQL到ClickHouse链路改造,精通实时同步、数据校验与延迟治理,致力于构建高性能、高一致性的数据架构体系。
MySQL 到 ClickHouse 明细分析链路改造:数据校验、补偿与延迟治理
|
11月前
|
运维 监控 关系型数据库
MySQL高可用方案:MHA与Galera Cluster对比
本文深入对比了MySQL高可用方案MHA与Galera Cluster的架构原理及适用场景。MHA适用于读写分离、集中写入的场景,具备高效写性能与简单运维优势;而Galera Cluster提供强一致性与多主写入能力,适合对数据一致性要求严格的业务。通过架构对比、性能分析及运维复杂度评估,帮助读者根据自身业务需求选择最合适的高可用方案。
|
12月前
|
存储 关系型数据库 MySQL
修复.net Framework4.x连接MYSQL时遇到utf8mb3字符集不支持错误方案。
通过上述步骤大多数情况下能够解决由于UTF-encoding相关错误所带来影响,在实施过程当中要注意备份重要信息以防止意外发生造成无法挽回损失,并且逐一排查确认具体原因以采取针对性措施解除障碍。
730 12
|
SQL 关系型数据库 MySQL
解决MySQL "ONLY_FULL_GROUP_BY" 错误的方案
在实际操作中,应优先考虑修正查询,使之符合 `ONLY_FULL_GROUP_BY`模式的要求,从而既保持了查询的准确性,也避免了潜在的不一致和难以预测的结果。只有在完全理解查询的业务逻辑及其后果,并且需要临时解决问题的情况下,才选择修改SQL模式或使用 `ANY_VALUE()`等方法作为短期解决方案。
1158 8
|
12月前
|
监控 NoSQL 关系型数据库
保障Redis与MySQL数据一致性的强化方案
在设计时,需要充分考虑到业务场景和系统复杂度,避免为了追求一致性而过度牺牲系统性能。保持简洁但有效的策略往往比采取过于复杂的方案更加实际。同时,各种方案都需要在实际业务场景中经过慎重评估和充分测试才可以投入生产环境。
572 0
|
关系型数据库 MySQL 定位技术
MySQL与Clickhouse数据库:探讨日期和时间的加法运算。
这一次的冒险就到这儿,期待你的再次加入,我们一起在数据库的世界中找寻下一个宝藏。
496 9
|
关系型数据库 MySQL Java
MySQL 分库分表 + 平滑扩容方案 (秒懂+史上最全)
MySQL 分库分表 + 平滑扩容方案 (秒懂+史上最全)
|
消息中间件 缓存 NoSQL
缓存与数据库的一致性方案,Redis与Mysql一致性方案,大厂P8的终极方案(图解+秒懂+史上最全)
缓存与数据库的一致性方案,Redis与Mysql一致性方案,大厂P8的终极方案(图解+秒懂+史上最全)
|
SQL 关系型数据库 MySQL
基于SQL Server / MySQL进行百万条数据过滤优化方案
对百万级别数据进行高效过滤查询,需要综合使用索引、查询优化、表分区、统计信息和视图等技术手段。通过合理的数据库设计和查询优化,可以显著提升查询性能,确保系统的高效稳定运行。
949 9
|
监控 关系型数据库 MySQL
Aurora MySQL负载突增应对策略与优化方案
通过以上策略,企业可以有效应对 Aurora MySQL 的负载突增,确保数据库在高负载情况下依然保持高性能和稳定性。这些优化方案涵盖了从架构设计到具体配置和监控的各个方面,能够全面提升数据库的响应速度和处理能力。在实际应用中,应根据具体的业务需求和负载特征,灵活调整和应用这些优化策略。
354 22

推荐镜像

更多