共计 2488 个字符，预计需要花费 7 分钟才能阅读完成。
简述
CloudCanal 去年反对 OceanBase 数据迁徙同步能力后，随着应用用户增多以及问题反馈，近期对该能力进行了一轮较大规模的优化。
本篇文章简要介绍这些优化点，以及将来该能力的演进方向。
优化点
大幅晋升同步性能
CloudCanal 目前应用 OceanBase LogProxy 做增量数据订阅，应用形式绝对简单明了。
@Override
public 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) 刷出，晋升批量写入的粒度。
对端写入形式，依据不同数据源，咱们采纳了 batch、multisql、并行、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 COLUMN、AFTER/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 为源端数据迁徙同步，目前反对 MySQL、StarRocks、OceanBase、Kafka 对端，咱们心愿后续如 Redis、ElasticSearch、Doris、Hudi 等数据源也能退出到这个指标数据源中。
总结
本文次要介绍了 CloudCanal 在过来一段时间对 OceanBase 数据迁徙同步能力 的优化, 从而是这个能力具备 更强的性能 、 更好的兼容性 、 更加稳固的数据迁徙同步体现。
