CDCとは？

CDC（変更データキャプチャ）とはソースデータの変更を検知して下流のアプリケーションに伝えることをいいます。

CDCがなぜ必要か？

近年のデータプラットフォームには次の性質が求められるのですが、これを従来のcronでやると大変だからです。

• 高可用性

• 一貫性

• 低レンテンシ

2つの戦略とは？

CDCのやり方は２通りあります。

プッシュ戦略

データソース側がデータの変更を通知する方式です。
データ更新から通知までの遅延がなくなる一方、データソース側にCDCを行うための処理負荷がかかってしまいます。

プル戦略

下流のアプリ側がデータソースの更新を確認する方式です。
プッシュ戦略とは逆のメリデメが存在します。

どちらの戦略が優れているということはなく、プロダクトごとに適した方を選びましょう。

何を持って変更とみなすか？

タイムスタンプ

データが作成された日時を表す列を用意しておき、前回検知したときより新しい日時の行が存在すれば下流に伝えます。
以下の問題があります。

1. 複数回同じ列が更新されても1回しか検知できない

2. 行が削除された場合にどう後続に伝えるかを考えなければならない

3. 行が削除された場合にどの行が削除されたのかが把握できない

テーブル差分

検知する毎にスナップショットを保存しておき、前回のスナップショットと今回のテーブルの内容の差分を確認する方法です。
最大のデメリットは毎回全列を取得して比較することによるコスト高です。
なので特定の列だけを比較する方法もあります。

データベーストリガー

INSERT、UPDATE、DELETEなどの操作時に下流に通知する方式です。
リアルタイムで検知できコストも全然かかりませんが、DBMSがトリガー機能を備えていないとCDCを行えないというデメリットがあります。
幸いにしてPostgreSQL、SQLServerなど多くのDBMSが対応しています。

ログベース

DBMSはロールバックや他データセンターへのデータ移行に備えて、データを操作するとログを落とすようになっています。
このログをトリガーにCDCを行うのがログベースです。
この方式はリアルタイムで検知できるのですが、それがデメリットになり得ます。
例えばデータベースがロールバックしたときにもトリガーされますが、後続のアプリケーションがすぐさま追従するのは本当によいことでしょうか？

CDCのユースケースは？

簡単なバックアップ

多くのDBMSはビルトインでCDC機能を備えているため、簡単なバックアップ用途として使えます。

マイクロサービス

データソースの変更に応じて後続のマイクロサービスを動かさないと行けない場合にCDCが有効です。

まとめ

CDCはデータベースを管理する者たちにとって有用な機能です。
やり方は様々あるので、各々適した方法を選んでビジネスを効率化させましょう！

参考

https://medium.com/@kiennguyn/change-data-capture-you-need-to-know-78f4892b9b97