CDC 與批次處理的資料庫同步有什麼差異？
資料庫同步機制的選擇與取捨
同步資料庫是一件極其常見的工作，尤其當系統規模或複雜性到一定程度，就會藉由資料庫系統的同步機制，將關鍵資料或是狀態複製到各個系統上，來達成訊息交換、事件通知或資料快取等目的。
對於微服務架構的實踐者來說，有些時候我們是為了將資料庫的異動，轉換成事件，實現事件驅動架構（EDA, Event-driven Architecture）、CQRS Pattern 或是 Data Mesh 的需求。
無論是使用什麼工具做資料庫同步，方法主要有兩種形式「CDC」和「批次處理（Batch）」。但近年來數位業務增加、微服務架構的興起之下，資料庫系統的壓力已不可同日而語，因次我們不再單純只考慮能否達成同步的需求，而是同步帶來的額外負擔或是效率。
到底兩者在實務上的表現和工作效率有何不同，本文將簡單進行一些探討和分析。
什麼是 CDC？
CDC 全名為 Change Data Capture，顧名思義就是去擷取變更資料，當資料庫系統在新增或修改資料時（例如：Insert、Update 或 Delete），擷取這個變更行為的事件細節。以此方法實現資料庫同步時，就是參照這個變更行為的細節，在另一個資料庫上重現。
CDC 的事件通常由資料庫系統自發性產生，或是透過分析資料庫的 binlog 來得到變更事件。因此，如果要採用 CDC，必須資料庫系統能原生支援相關機制，或是部署第三方解決方案在資料庫系統的機器上，進行 binlog 解析。
在實務上，不同的資料庫系統有不同程度的資源，設定方法也不盡相同，比較現代的資料庫系統，無論是 SQL 還是 NoSQL 類型的資料庫，多半都有原生的支援。
批次處理的資料庫同步方法
批次處理（Batch）是定期去查詢資料庫，取得最新的資料然後進行同步工作，是較為直觀、容易實現的做法 ，無須對資料庫進行系統級的設定或工具部署。通常這種方法，在 Table 的設計上必須準備額外的時間欄位，然後使用觸發器（Trigger）或是由應用程式來更新資料變更的時間。對於應用程式開發人員來說，這定期批次處理的做法，可以自己實現的同步方法。
值得注意的是，批次處理主要是利用標準的「查詢（Query）」去取得資料庫的資料，因此會造成資料庫的讀取壓力。若是查詢間隔時間太長，導致累積的待同步資料量高，可能會造成資料庫嚴重的效能衝擊。另外，如果有即時性的需求，可以藉由縮短時間間距，達成一定程度的即時性，只不過密集查詢的結果，也可能會帶來資料庫的壓力。
批次處理的同步方法，在一般情況下無法實現「刪除（Delete）」的同步。若要實現刪除資料的同步，只能實現軟刪除（Soft Delete）。
兩者的吞吐量差異為何？
在過去客戶的場景下，我們曾經做過相關測試，比較資料庫本身吞吐極限與用兩種同步方式的吞吐量能力比較。當時，我們在 Kubernetes 上簡單部署了 Oracle 11g，沒有特別進行調校優化，然後使用了我們產品 Gravity 的 Native Oracle Adapter(NOA) 來測試 。
由於 NOA 同時支援 CDC 和批次兩種模式，我們直接切換不同模式，進行後續的比較。在這個測試裡，Oralce 的 CDC 採用內建的 LogMiner 來實現。
資料庫本身的吞吐量能力：
然後我們進行了 CDC 和批次方法的第一次同步（Initial Load）十萬筆資料測試，時間量測從資料庫將資料取出到落地至 Kafka 結束：
第一次同步機制啟動時，會將既有資料庫內的資料完全讀出，無論是哪一種模式，都是以「查詢」的方法將所有資料取出，然後將資料推送至 Kafka，因此兩種模式在 Initial Load 的效能相差無幾，基本上效能表現相同。
備註：相較於只是將資料從資料庫讀出，NOA 多做了其他同步工作，所以有大概 15% 左右的吞吐量衰減。
即時的吞吐量和同步延遲程度比較
對於資料庫同步機制來說，即時的吞吐量和同步延遲程度才是比較重要的參考標準。在實務上，資料寫入資料庫開始，到資料成功被複製出來，其中所花的時間，以及複製成功的數量才是我們所關心的議題。
同樣，我們測試寫入十萬筆，然後測量完全寫入所花的時間，以及從寫入第一筆開始到最後一筆同步至 Kafka 的總時間，然後計算每秒能完成同步的資料筆數。另外，也同時計算每一筆寫入到資料庫及抵達 Kafka 的時間，來測得延遲程度。
以下是測試結果：
從測試結果得知，CDC 模式相當即時（延遲程度最低），平均 457ms 可以同步成功；批次模式在同步時間間隔設為 1 秒時，平均大約在 987ms，整體延遲程度比較大、較為不即時。而批次模式的時間間隔設為更長時，延遲程度自然更長許多。
總體來說，無論是 CDC 或是批次模式，最佳表現都與資料庫寫入極限相當（不到 3% 的衰減），這代表資料在寫入資料庫後，幾乎是即時的情況下可以同步出來。
理論上，即時同步的吞吐量，不會超過寫入的資料量。
CDC 和批次處理的差異？
理論上，如果瞬間的資料量足夠大，CDC 這類串流（Streaming）形式的資料處理模式，其吞吐量會遠不及批次處理。但實務上，因為資料庫寫入速度遠比查詢速度低，因此兩個模式實際效能表現上沒有太大差異，反而主要差別在資料延遲程度，以及造成的資料庫壓力的不同。
兩者的差異大致如下表所示：
對資料庫同步、CQRS 或數據中台有興趣嗎？本文相關資料和素材，出自 Brobridge Gravity 數據中台解決方案，此產品用於解決企業跨系統資料交換、微服務架構資料供應和 AIoT 數據平台，協助 IT 人員、開發者實現最佳化的資料交換架構，滿足各類數位轉型的需求。如果您也有相關問題或需求，可以與我們寬橋（Brobridge）聯絡。
