こんにちは、CData Software Japan プロダクトチームの宮本です！ この記事はQiita CData Software Advent Calendar 2022 4日目の記事になります。
https://qiita.com/advent-calendar/2022/cdatasoftware
データパイプラインプロダクトとしてCData Sync を提供して数年が経ちましたが、よく「DB to DB のジョブを組みたいんだけどトランザクションログを利用したCDC での差分連携できる？」というような声をユーザー様から頂いておりました。実は日本国内問わずグローバルでもリクエストが多々あったようで、今年主要なRDB 系データソースに対して順々に対応していきました。（特にここ1年、２年くらいでDB to DB の問い合わせは増えている気が）
今回はこのCDC とは？というところから、各CDC の方式について、最後はCData Sync を使用したCDC 機能の使い方についてご紹介したいと思います！
CDC の前に・・・差分更新のおさらい
差分更新とは・・・
- （データソース側）前回から更新されたデータだけを取得 → 同期先に連携（マージ）することを指す
- 差分更新有無はデータパイプラインツールを採用基準で重要な項目
もう少しだけ具体的にみていくと・・・
- SaaS から DB へのレプリケーション構成で、SaaS データを前回からの差分で抽出できるかを指すことが多い
- API側で更新日付によるフィルタリング処理が行わる場合に可能
例としては、Salesforce の取引先情報（Account オブジェクト）のレプリケーションをした場合、初回は全件が対象となりますが、2回目以降は前回取り込んだ最終レコードの更新日時以降に更新された取引先情報だけしか取得しないようになり、結果として抽出件数が減り同期先に送るデータ量も減るのでジョブ完了までのパフォーマンスが向上されるようになります。
DB系ソースの差分データ抽出=Change Data Capture
DB側で差分レコードを抽出する方式をChange Data Capture (CDC) と指していて、中身としてはクエリベース、トリガーベース、ログベースの3種類があります。（実際は2つのテーブルを比較して差分を抽出する方法など他の方法もあるようです）
それでは各方式についてみていきましょう。
クエリベース
クエリベースは、対象テーブルに更新日付を条件にクエリして差分レコードを抽出する方式になります。
例えば下記のようなクエリです。
Select * from Account Where updated_at> ‘yyyy-MM-dd(最終更新日時)’
クエリが書けるツールならすぐ実行できますのでかなりお手軽ではありますが、テーブル側のデータ量によってはデータベース自体に負荷を掛けてしまったり、テーブルに更新日時項目を必ず持つ必要があります。また、テーブルを直接クエリすることから削除レコードを検知できないというのもあり、少しツライところです。
- ポジ要素
- DB 側の設定不要ですぐ実行可
- ネガ要素
- データ量によってデータベース全体に負荷が掛かる
- 更新日時項目を持つ必要がある
- 削除レコードは検知できない
トリガーベース
トリガーベースでは、変更が行われたタイミングで別テーブルに「Insert、Update、Delete」の変更情報を連携するトリガーを作成するといった方式となります。すべての変更情報を保持することからクエリベースで実現できなかった削除レコードも取得できるようになります。
とは言え、別テーブルを用意することで元テーブルのスキーマ変更時に手動対応が必要になるのと、トリガー処理が元のステートメントに加えられるので実行時間が増えるという部分があります。
- ポジ要素
- 削除も含めて全変更情報を取得可
- ネガ要素
- 別テーブルの管理で運用が複雑化
- トリガー処理がプラスされる＝元のステートメントの実行時間が増える
- テーブルのスキーマ変更時は手動対応する必要がある
ログベース
ログベースはトランザクションログを利用した差分データ抽出の方式で、変更情報はトランザクションログに書き込まれることから結果として差分データを抽出することができます。
ログを直接参照していくのでDB 側に負荷を掛けないのに加え、スキーマ変更等も気にする必要がなく、ツール側がログベースのCDC に対応している場合はほとんど管理するものがないので利用しやすいです。（連携先テーブルでは対応必要ですが）
ただ、古いバージョンのDBを利用しているとこの方式が使用できなかったり、DBを参照するツール側がこのトランザクションログを読み取ることをサポートしていない場合は利用できないといったところがあります。
- ポジ要素
- ログを直接参照でDBへのパフォーマンスに影響与えない
- スキーマ変更も気にせず、管理が容易
- ネガ要素
- 古いバージョンのDBでは未対応であることが多い
CDC まとめ
CDC の各方式を比較してみると、トランザクションログからデータを読み取れる環境下ならログベースを選択する方が良さそうですね。
CDC 専用のSaaS
最近はDB データをCDC で取得することに特化したサービスも増えてきています。
→例えば debezium とkafka などのストリーミング系ソフトウェアやサービスを組み合わせるケースも見かけますね。
https://www.moderndatastack.xyz/companies/change-data-capture
CData Sync のCDC 機能について
データパイプラインツールのCData Sync では、このCDC のログベースを用いた差分連携ができるようになっています。
今時点で対応しているデータソースとしては、SQL Server、 Oracle、 MySQL、 PostgreSQL の4つになります。
CData Sync のダウンロードは↓↓からできます。（30 日間の無償トライアルが可能です！）
CData Sync | ノーコードデータレプリケーション / ETL ツール
CDataSync の特徴でもあるセルフホスティング型を利用し、オンプレミスにあるDBと同じネットワーク内に CData Sync をホスティングし、基幹側DBをクラウドDWHに定期的に差分連携するといったケースにも対応できます。
ちなみに使い方はめちゃくちゃ簡単です。（特にMySQL！）
CDC 対応済みのデータソースを使用してジョブを作成する際に、下記のような画面が表示されるので「変更データキャプチャ」を選択するだけです。
とは言え、DB側の設定がいくつか必要なものもありますので、その設定方法等は各DBごとのCDC 記事があるので下記のリンクよりご参照下さい。
ちなみに、MySQL の場合はバージョン8.0 以降だとデフォルトでトランザクションログのbinlog が有効となっているので、特段設定不要ですぐに実行できます！！
SQLServer のCDC 設定方法について
変更データキャプチャ（CDC）を使ったデータレプリケーションを SQL Server → Redshift でやってみた：CData Sync | CData Software Blog
MySQL のCDC 設定方法について
MySQL コネクタでもChange Data Capture (CDC) でのレプリケーションに対応しました！CData Sync | CData Software Blog
PostgreSQL のCDC 設定方法について
ログベースによる変更データキャプチャ（CDC）で PostgreSQL → BigQuery のレプリケーションをやってみた：CData Sync | CData Software Blog
おわりに
いかがでしたでしょうか。実際にはCDC にはいくつか方式があり、中には既に使っているケースなどもあったのではないでしょうか。最近は DB（オンプレのDB） to DB（クラウドDWH） を実現したいというケースも増えていますが、毎回全量を送っていてはかなり大変かと思います。そういった構成の際は、ぜひCData Sync のCDC 機能を使ってお試しいただければと思います。
ちなみにCData Sync は30 日間無償トライアルが可能です！ぜひさくっとお試しください！
CData Sync | ノーコードデータレプリケーション / ETL ツール
関連コンテンツ
