CloudCanal x OceanBase 資料遷移同步優化-有解無憂

簡述

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 對表磁區的結構遷移并未有效支持，這種磁區的結構遷移，對于同構資料庫相當必要，后續，我們將提供 磁區資訊的結構遷移，

總結

本文主要介紹了 CloudCanal 在過去一段時間對 OceanBase 資料遷移同步能力的優化,從而是這個能力具備更強的性能、更好的兼容性、更加穩定的資料遷移同步表現，

轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/551396.html

標籤：其它

上一篇：[20230425]CBO cost與行遷移關系.txt

下一篇：返回列表

CloudCanal x OceanBase 資料遷移同步優化

簡述

優化點