変更データ・キャプチャーとは

変更データ・キャプチャー（CDC）は、データベース内のデータ変更を特定・記録する手法です。CDCはこれらの変更をリアルタイムでさまざまなターゲット・システムに届け、データベースの変更発生直後に組織内のデータ同期を可能にします。

変更データ・キャプチャーは、組織内でサイロ化または不整合が生じている可能性のあるデータを統合・調和させる役割を果たす、リアルタイム・データ統合の手法です。その他の手法には、ストリーム・データ統合、データ・バーチャライゼーション、アプリケーション統合があります。

CDCがシステムをリアルタイム（かつ低遅延）で最新の状態に保つ能力は、リアルタイム・データ分析、クラウド移行、さらにはAIモデルの成功に不可欠です。小売、金融、ヘルスケアなど多様な業界で幅広く活用されており、不正検知、サプライチェーン管理、規制遵守の支援に役立っています。

変更データ・キャプチャーには複数のアプローチがあり、ログベースCDC、タイムスタンプベースCDC、トリガーベースCDCが最も一般的です。企業は、データベース・ネイティブ・ツール、オープンソース・プラットフォーム、サードパーティ製ソリューションを活用して変更データ・キャプチャーを導入できます。

現代のデータ管理において、変更データ・キャプチャーは重要なデータ・エンジニアリングの仕組みとして登場しています。現在、企業を取り巻くデータ環境はますます大規模かつ複雑になっています。これらには、モノのインターネット（IoT）デバイス、分散データベース、アプリケーション、その他多様なソースからのデータが含まれている可能性があります。拡大するデータ・エコシステム全体で一貫した高品質データを維持することは継続的な課題です。

同時に、ビジネスはリアルタイムの意思決定に活用できる、正確で最新の情報を求めています。変更データ・キャプチャーは、組織がこの要求に応えるための複数の手法の一つです。

変更データ・キャプチャーは、他のデータ統合手法よりも効率的でリソース消費の少ない形で新鮮なデータを提供する低遅延データ・パイプラインを可能にします。例えば、データ複製は、データセット全体をコピーすることを指します。これに対し、CDCは変更されたデータのみを送信するため、ソース・システムの負荷やネットワーク・トラフィック、計算リソースの要求を削減します。

これにより、最新かつ最も正確な情報に迅速かつ効率的にアクセスできるようになり、以下を含む複数のメリットが得られます。

リアルタイムのデータ変更ストリームは、リアルタイム・データ分析やビジネス・インテリジェンスを可能にします。これらの機能により、企業は今日の時間に敏感で24時間365日のビジネス環境の要求に対応できます。

クラウド移行の際、CDCはオンプレミスで発生したデータ変更を迅速に関連するクラウド・ベースのデータ・テーブルに届け、両環境間の整合性を確保します。この機能により、移行中のシステムのダウンタイムも最小限に抑えられます。

ETL（抽出、変換、ロード）データ・パイプラインは、データ分析および機械学習のワークストリームに不可欠です。しかし、バッチ処理に依存するETLの実行は、処理速度が遅く、システム・リソースに負荷をかける傾向があります。CDCをETLに組み込むことで、リソースの使用を最適化し、データ移動を加速できます。

変更データ・キャプチャーを実装することで、モデルのソース・データを最新の状態に保ち、大規模言語モデル（LLM）が正確でタイムリーな出力を提供できるようになります。例えば、検索拡張生成（RAG）のユースケースでは、AIモデルが外部のナレッジ・ベースと連携して、より適切な応答を実現します。

変更データ・キャプチャーは、さまざまなデータ・ソースで発生する変更イベントを特定し記録します。これらのソースには、Oracle、PostgreSQL、MySQL、MicrosoftのAzure SQL、MicrosoftのSQL Serverなどのリレーショナル・データベースや、Apache CassandraやMongoDBなどの非リレーショナル（NoSQL）データベースが含まれます。

変更が特定された後、それらはソース・データベースからリアルタイムまたは準リアルタイムでターゲット・システムに転送されます。データ・レイクやデータ・ウェアハウスなどのデータ・ストア、Apache KafkaやApache Sparkなどのリアルタイム分析およびストリーミング・データ・プラットフォーム、さらにETL（抽出、変換、ロード）およびELT（抽出、ロード、変換）ソリューションは、すべてターゲット・システムの例です。

変更データ・キャプチャーは、ターゲット・システムによって開始される「プッシュ」方式か、ソース・システムによって開始される「プル」方式のいずれかで実行されます。前者では、ソース・システムが変更を「プッシュ」してターゲット・システムに送信します。後者では、ターゲット・システムが定期的にソース・システムをポーリングし、変更が見つかった場合に「プル」します。

変更データ・キャプチャーを実行する方法はいくつかあります。一般的なCDCの種類には、次のものがあります。

• ログベースのCDC
• タイムスタンプベースのCDC
• トリガーベースのCDC

データベース・トランザクション・ログはデータベースの標準機能であり、すべてのデータベース・トランザクションを記録するために使用されます。（トランザクション・ログ・ファイルは、システム障害時にデータベースを復旧するために使用されます。）

ログベースのCDCでは、CDCアプリケーションがログに記録されたデータベースの変更を処理し、更新情報を他のシステムと共有します。ログベースCDCは、ソース・システムのパフォーマンスを低下させる可能性のあるクエリではなくログに依存しているため、人気が高まっています。しかし、トランザクション・ログの形式の違いは、異なるデータベース間でのログベースCDCの実行を複雑にする可能性があります。

タイムスタンプベースの変更データ・キャプチャー（クエリベースCDCとも呼ばれる）は、データベース・テーブルのスキーマに、レコード変更の日付と時刻を示すタイムスタンプ列などのカラムがあることを前提としています。CDCツールは、ソース・テーブルのタイムスタンプ列を使って変更されたレコードを特定し、その後ターゲット・システムに更新情報を届けることができます。

タイムスタンプベースCDCは導入が比較的容易ですが、タイムスタンプ・データのポーリングが頻繁に行われると、システムに追加の負荷がかかる可能性があります。タイムスタンプベースCDCは、行全体とともにタイムスタンプが削除された場合、削除操作を検知できないこともあります。

トリガーベースの変更データ・キャプチャーでは、データベース内で挿入、削除、更新などの特定の変更が発生すると、データベース・トリガーと呼ばれるストアド・プロシージャーや関数が実行されます。変更されたデータは、一般にチェンジ・テーブルまたはシャドウ・テーブルと呼ばれる場所に保存されます。

タイムスタンプベースCDCと同様に、トリガーベースCDCも実装が比較的容易です。しかし、トリガーはソース・テーブルでトランザクションが発生するたびに「発動」するため、ソース・システムに負荷がかかる可能性があります。

変更データ・キャプチャーを実行するツールには、AWS Database Migration Serviceのように特定の環境やデータベース・システムにネイティブなものもあれば、より広範に導入されるものもあります。ネイティブでない変更データ・キャプチャーのソフトウェア・ソリューションには、Debeziumなどのオープンソース・プラットフォームや、IBM StreamsetsやOracle GoldenGateなどの商用プラットフォームがあります。

企業がどのソリューションを選択するか検討する際には、価格、ソース・システムおよびターゲット・システムへのコネクター、システム統合のためのアプリケーション・プログラミング・インターフェース（API）などの要素を考慮する場合があります。

企業はさまざまな用途で変更データ・キャプチャーをデプロイできます。