简述

CloudCanal 去年反对 OceanBase 数据迁徙同步能力后,随着应用用户增多以及问题反馈,近期对该能力进行了一轮较大规模的优化。

本篇文章简要介绍这些优化点,以及将来该能力的演进方向。

优化点

大幅晋升同步性能

CloudCanal 目前应用 OceanBase LogProxy 做增量数据订阅,应用形式绝对简单明了。

@Overridepublic void notify(LogMessage message) {    try {        ParsedEntry entry = msgConvertor.convertMsgToEntry(message);        if (entry == null) {            return;        }        instance.getEventStore().put(entry);    } catch (Exception e) {        String msg = "parse ob msg failed.msg:" + ExceptionUtils.getRootCauseMessage(e);        log.error(msg, e);        throw new LogProxyClientException(ErrorCode.E_PARSE, msg);    }}

音讯解析对性能影响绝对小,攒批对端写入形式 影响更大。

攒批方面,咱们将变更事件写入内存队列后,依照 个数/容量阈值(increBatchSize)超时工夫(fetchFromBrokerTimeoutMs) 刷出,晋升批量写入的粒度。

对端写入形式,依据不同数据源,咱们采纳了 batchmultisql并行upsert 等技术晋升写入效率。

对立各类表全量扫描形式

全量数据扫描 是 CloudCanal 全量数据迁徙(或数据初始化)重要组成部分,需满足 性能优良(2KB/record,>= 100k records 扫描速率)、可断点续传可预测进度表兼容性好 的要求。

其中前三者是业务要求,最初一种是尽可能满足前三者的前提下,做到更多表的兼容。

CloudCanal 碰到的"表"蕴含以下类型

  • 关系型数据库

    • 无/单/多主键
    • 各种类型主键(整型/浮点/日期/二进制等)
    • 差别值主键(有/无符号,null值/空值,超长值)
    • 各种类型分区
    • 差别数据量(1万,100万,1000万,1亿,10亿,100亿)
    • 实体表/视图/长期表
  • 消息中间件

    • 各种命名标准
    • 无/有分区
    • 程序/非程序
  • 文档数据库

    • 标准/非标准(schemaless)
    • 无/有行业标准格局(ObjectId)
  • 缓存数据库
  • 搜索引擎

CloudCanal 全量数据扫描次要面向关系型数据库,性能要求断点续传能力进度预测能力都基于主键开展。

此次优化,咱们做了如下几方面工作,对立了扫描逻辑,并且让无/单/多主键、各种类型主键、分区表都可断点续传

  • 主键分区作为断点续传位点
  • 扫描语句退出分区指定(如有)元组比拟(单/多主键)按元组排序指定分页数等局部
  • 比照位点最大值扫描行数形式断定扫描是否完结

此外,各个数据源可依据本身差异性,可扩大扫描语句最大最小位点值获取逻辑链接自定义(设置超时等)执行语句上下文自定义(设置fetchSize等)

反对全局索引表

全局二级索引(GLOBAL)对分布式数据库有着十分重要的作用,它让本来 多分区数据检索 操作 弱化成单分区检索,减速不同维度点查响应,晋升 QPS。

对于 OceanBase 对端写入,CloudCanal 默认采纳关系型数据库 INSERT IGNORE/ON DUPLICATE KEY UPDATE 躲避主键/惟一键抵触

然而对于带有 GLOBAL 索引的表,OceanBase 不反对 INSERT IGNORE 操作,所以此次优化,咱们写入 OceanBase 的 INSERT 操作默认改为 ON DUPLICATE KEY UPDATE (REPLACE)。

异构 DDL 同步转换优化

从异构数据库同步 DDL 到 OceanBase,咱们优化成白名单模式

如 MySQL 到 OceanBase DDL 同步,默认反对

  • ALTER TABLE xxx ADD/DROP/MODIFY COLUMN
  • CREATE INDEX
  • RENAME TABLE

优化同时去除了 ALTER TABLE xxx CHANGE COLUMNAFTER/BEFORE 等 OceanBase 现阶段不反对的语句。

此项能力随着 OceanBase 产品能力的进化而不断丰富。

解决工夫戳自更新问题

对于相似 gmt_create datetime/timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP 工夫字段定义,当源端该字段值变动区间小于工夫精度(被程序断定未变动),并且写入对端并非采纳 upsert 形式(准确字段更新),那么该字段数据将不统一。

CloudCanal 在准确字段更新模式下,默认将工夫字段置为更新状态,确保将源端值带到对端,解决不统一的问题。

演进方向

OceanBase 商业级增量组件兼容

OceanBase 商业版 OMS 的数据订阅能力有别于目前社区版的 LogProxy,如 OceanBase 官网逐渐扩充其应用面,CloudCanal 将第一工夫跟进兼容。

更快的数据校验和勘误能力

分布式数据库绝对单机数据库,单表数据量大幅度减少(亿级表相当常见),数据校验和勘误性能相比数据初始化,更加依赖数据扫描的性能,为此,CloudCanal 将凋谢 单表分片/分区并行扫描 的能力。

更强的构造迁徙和 DDL 同步能力

大表 通用/特殊化分区 是常见操作,目前 CloudCanal 对表分区的构造迁徙并未无效反对,这种分区的构造迁徙,对于同构数据库相当必要。后续,咱们将提供 分区信息的构造迁徙

更多的数据源生态反对

以 OceanBase 为源端数据迁徙同步,目前反对 MySQLStarRocksOceanBaseKafka 对端,咱们心愿后续如 RedisElasticSearchDorisHudi 等数据源也能退出到这个指标数据源中。

总结

本文次要介绍了 CloudCanal 在过来一段时间对 OceanBase 数据迁徙同步能力的优化,从而是这个能力具备更强的性能更好的兼容性更加稳固的数据迁徙同步体现