Change Data Capture（CDC）とは？CDC の基本から仕組み、各種手法を完全解説

こんにちは、CData Software Japan プロダクトチームの宮本です！ この記事では、データベースの変更を効率的に追跡・同期するための重要な技術である「Change Data Capture（CDC）」について、基礎から実装方法まで詳しく解説していきます。

近年、データ連携の需要が高まる中で、特に「DB to DB のジョブを組む際のトランザクションログを利用したCDC での差分連携」についての問い合わせが国内外で増加しています。この記事では、CDC の基本概念から各実装方式の特徴、さらには2024年最新のツールまで、実践的な知識をご紹介します。

データパイプラインプロダクトとしてCData Sync を提供して数年が経ちましたが、よく「DB to DB のジョブを組みたいんだけどトランザクションログを利用したCDC での差分連携できる？」というような声をユーザー様から頂いておりました。

実は日本国内問わずグローバルでもリクエストが多々あったようで、今年主要なRDB 系データソースに対して順々に対応していきました（特にここ1年、２年くらいでDB to DB の問い合わせは増えている気が）。

今回はこのCDC とは？というところから、各CDC の方式について、最後はCData Sync を使用したCDC 機能の使い方についてご紹介したいと思います！

CDC の前に・・・差分更新のおさらい

差分更新とは・・・

• データソース側：前回以後に更新されたデータだけを取得 → 同期先に連携（マージ）すること
• 差分更新有無はデータパイプラインツールの採用基準で重要な項目

もう少し具体的にみていくと・・・

• SaaS から DB へのレプリケーション構成で、SaaS のデータを前回更新分からの差分で抽出できるかを指すことが多い
• API 側で更新日付によるフィルタリング処理が行わる場合に可能

例としては、Salesforce の取引先情報（Account オブジェクト）のレプリケーションをした場合、初回は全件が対象となりますが、2回目以降は前回取り込んだ最終レコードの更新日時以降に更新された取引先情報だけしか取得しないようになります。

結果として抽出件数が減り同期先に送るデータ量も減るので、ジョブ完了までのパフォーマンスを向上できます。

Change Data Capture（変更データキャプチャ、CDC）とは？

さて、ここまで見てきたように、差分更新は「SaaS から DB へのレプリケーション構成で、SaaS のデータを前回更新分からの差分で抽出」することです。一方、DB 側で差分レコードを抽出する方式をChange Data Capture (変更データキャプチャ、CDC) と呼びます。データベース内のデータ変更を継続的に監視・追跡し、その変更を他のシステムにリアルタイムまたは定期的に反映させる技術です。主に以下のような変更を追跡します。

• データの挿入（INSERT）
• データの更新（UPDATE）
• データの削除（DELETE）

CDC が重要な理由

CDC はETL ツール採用の選定基準で重要と書きましたが、主に以下の理由で重要視されています。同期速度の向上やコスト削減、リアルタイムのデータ同期が求められる場面など、さまざまな恩恵がありますね。

• リアルタイムデータ連携：変更をリアルタイムで検知し、即座に他システムへ反映
• システム負荷の軽減：全件同期と比較して、必要最小限のデータのみを転送
• データの整合性確保：複数システム間でのデータの一貫性を維持
• コスト削減：ネットワーク帯域やストレージの使用量を最適化

DB 系データソースの差分データ抽出：Change Data Capture の仕組み

さて、DB 側で差分レコードを抽出する方式をCDC と呼びますが、代表的な実装手法としてはクエリベース、トリガーベース、ログベースの3種類があります（2つのテーブルを比較して差分を抽出する方法など、他の方法もあるようです）。

それでは各方式についてみていきましょう。

クエリベースCDC

クエリベースは、対象テーブルに更新日付を条件にクエリして差分レコードを抽出する方式になります。
例えば下記のようなクエリです。

Select * from Account Where updated_at> 'yyyy-MM-dd(最終更新日時)'

クエリが書けるツールならすぐ実行できますのでかなりお手軽ではありますが、テーブル側のデータ量によってはデータベース自体に負荷を掛けてしまったり、テーブルに更新日時項目を必ず持つ必要があります。また、テーブルを直接クエリすることから削除レコードを検知できないというのもあり、少しツライところです。

• ポジ要素
  • DB 側の設定不要ですぐ実行可
    
    
• ネガ要素
  • データ量によってデータベース全体に負荷が掛かる
  • 更新日時項目を持つ必要がある
  • 削除レコードは検知できない

トリガーベースCDC

トリガーベースでは、変更が行われたタイミングで別テーブル（シャドウテーブル）に「Insert、Update、Delete」の変更情報を連携するトリガーを作成するといった方式となります。すべての変更情報を保持することからクエリベースで実現できなかった削除レコードも取得できるようになります。

とは言え、別テーブルを用意することで元テーブルのスキーマ変更時に手動対応が必要になるのと、トリガー処理が元のステートメントに加えられるので実行時間が増えるという部分があります。

• ポジ要素
  • 削除も含めて全変更情報を取得可
    
    
• ネガ要素
  • 別テーブルの管理で運用が複雑化
  • トリガー処理がプラスされる＝元のステートメントの実行時間が増える
  • テーブルのスキーマ変更時は手動対応する必要がある

ログベースCDC

ログベースはトランザクションログを利用した差分データ抽出の方式で、変更情報はトランザクションログに書き込まれることから結果として差分データを抽出することができます。

ログを直接参照していくのでDB 側に負荷を掛けないのに加え、スキーマ変更等も気にする必要がなく、ツール側がログベースのCDC に対応している場合はほとんど管理するものがないので利用しやすいです（連携先テーブルでは対応が必要ですが）。

ただ、古いバージョンのDBを利用しているとこの方式が使用できなかったり、DBを参照するツール側がこのトランザクションログを読み取ることをサポートしていない場合は利用できないといったところがあります。

• ポジ要素
  • ログを直接参照でDB へのパフォーマンスに影響与えない
  • スキーマ変更も気にせず、管理が容易
    
    
• ネガ要素
  • 古いバージョンのDB では未対応であることが多い
  • データがどのようにログとして記録され、保管されるかの標準などが存在しない
  • データベースのリカバリ用のログはCDC に必要な要件を満たさず、主キーカラムに関するログを保存する補助的な仕組みをとり入れる必要がある

CDC まとめ

CDC の各方式を比較してみると、トランザクションログからデータを読み取れる環境下ならログベースを選択する方が良さそうですね。

CDC 専用のSaaS

最近はDB データをCDC で取得することに特化したサービスも増えてきています。例えば、debezium やApache Kafka などのストリーミング系ソフトウェアやサービスを組み合わせるケースも見かけますね。

CData Sync のCDC 機能について

データパイプラインツールのCData Sync では、このCDC のログベースを用いた差分連携ができるようになっています。
今時点で対応しているデータソースとしては、SQL Server、 Oracle、 MySQL、 PostgreSQL の4つになります。
CData Sync のダウンロードは↓↓からできます。（30 日間の無償トライアルが可能です！）

CData Sync | ノーコードデータレプリケーション / ETL ツール

CData Sync の特徴でもあるセルフホスティング型を利用し、オンプレミスにあるDBと同じネットワーク内にCData Sync をホスティングし、基幹側DB をクラウドDWH に定期的に差分連携するといったケースにも対応できます。

使い方はめちゃくちゃ簡単です。（特にMySQL！）CDC 対応済みのデータソースを使用してジョブを作成する際に、下記のような画面が表示されるので「変更データキャプチャ」を選択するだけです。

とは言え、DB 側の設定がいくつか必要なものもありますので、その設定方法等は各DBごとのCDC 記事があるので下記のリンクよりご参照下さい。

ちなみに、MySQL の場合はバージョン8.0 以降だとデフォルトでトランザクションログのbinlog が有効となっているので、特段設定不要ですぐに実行できます！！

SQL Server のCDC 設定方法について

変更データキャプチャ（CDC）を使ったデータレプリケーションを SQL Server → Redshift でやってみた

MySQL のCDC 設定方法について

MySQL コネクタでもChange Data Capture (CDC) でのレプリケーションに対応しました！

PostgreSQL のCDC 設定方法について

ログベースによる変更データキャプチャ（CDC）で PostgreSQL → BigQuery のレプリケーションをやってみた

Oracle のCDC 設定方法について

LogMiner を利用したCDC 設定方法

Oracle Database のLogMiner 機能を使ってRedshift にCDC（変更データキャプチャ）レプリケーション

CDB（コンテナ・データベース）を利用したCDC 設定方法

CData Sync のCDC レプリケーションが Oracle Database のCDB 構成をサポート

CData Sync の拡張型CDC でリアルタイムデータストリーミングを実現

さらに、CData Sync は2024年に「拡張型CDC」機能を搭載し、リアルタイムのCDC をサポートしました。

この機能を使うことで、従来のバッチ型に代わり、トランザクションログをリアルタイムで監視し、即座に変更データをキャプチャするリアルタイムデータストリーミングを実現できるようになります。

また、同期先DB への連携も任意のタイミングで設定できるため、リアルタイム連携のほか１時間ごとのスケジュール実行など、柔軟な運用を実現することができます。

こちらの記事で、PostgreSQL を例に拡張型CDC がどういう機能なのか、どのように設定できるのか詳しく説明していますので、ぜひご確認ください！また、こちらの記事では拡張型CDC によるパフォーマンス向上を実際に計測・比較しています。こちらも参考になればうれしいです。

おわりに

いかがでしたでしょうか。実際にはCDC にはいくつか方式があり、中には既に使っているケースなどもあったのではないでしょうか。最近は DB（オンプレのDB） to DB（クラウドDWH） を実現したいというケースも増えていますが、毎回全量を送っていてはかなり大変かと思います。そういった構成の際は、ぜひCData Sync のCDC 機能を使ってお試しいただければと思います。

ちなみにCData Sync は30 日間無償トライアルが可能です！ぜひさくっとお試しください！

CData Sync | ノーコードデータレプリケーション / ETL ツール

参考記事

Four Methods of Change Data Capture - DATAVERSITY

関連コンテンツ