変更データキャプチャ

データベースにおいて、変更データ キャプチャ( CDC ) は、変更されたデータ (「デルタ」) を判別して追跡し、変更されたデータを使用してアクションを実行できるようにするために使用される一連のソフトウェア設計パターンです。その結果、デルタ駆動型データセットが生成されます。

CDC は、エンタープライズ データ ソースに加えられた変更の識別、キャプチャ、配信に基づいたデータ統合のアプローチです。たとえば、データ ロードの増分更新に使用できます。

CDC は、データ ウェアハウスのコア機能の 1 つである時間の経過に伴うデータの状態のキャプチャと保存のため、データ ウェアハウス環境で頻繁に発生しますが、CDC は任意のデータベースまたはデータ リポジトリ システムで利用できます。

システム開発者は、アプリケーション ロジックから物理ストレージに至るまで、さまざまな方法で、システム レイヤーの 1 つまたは組み合わせで CDC メカニズムを設定できます。

簡略化された CDC コンテキストでは、1 つのコンピュータ システムに、以前の時点から変更されたと考えられるデータがあり、2 つ目のコンピュータ システムでは、その変更されたデータに基づいてアクションを実行する必要があります。前者はソース、後者はターゲットです。ソースとターゲットが物理的に同じシステムである可能性もありますが、論理的には設計パターンは変わりません。1 つのシステムに複数の CDC ソリューションが存在する場合があります。

変更をキャプチャする必要があるテーブルには、最終変更時刻を表す列がある場合があります。LAST_UPDATE、LAST_MODIFIED などの名前が一般的です。その列のタイムスタンプが、データが最後にキャプチャされた時刻よりも新しいテーブル内の行は、変更されたと見なされます。

行のタイムスタンプはオープンロックにも頻繁に使用されるため、この列は頻繁に使用可能です。

データベース設計者は、変更をキャプチャする必要があるテーブルにバージョン番号を含む列を指定します。VERSION_NUMBER などの名前が一般的です。

1 つの手法は、変更された各行にバージョン番号を付けることです。テーブルまたはテーブル グループに対して現在のバージョンが維持されます。これは、参照テーブルなどのサポート構造に格納されます。変更キャプチャが発生すると、最新のバージョン番号を持つすべてのデータが変更済みとみなされます。変更キャプチャが完了すると、参照テーブルが新しいバージョン番号で更新されます。

(この手法を、楽観的ロックに使用される行レベルのバージョン管理と混同しないでください。楽観的ロックでは、各行に独立したバージョン番号 (通常は連続カウンタ) があります。これにより、プロセスは行をアトミックに更新し、別のプロセスがカウンタを増分していない場合にのみカウンタを増分できます。ただし、CDC は、各行の元の「開始」バージョンがわからない限り、行レベルのバージョンを使用してすべての変更を見つけることはできません。これは維持するのが非現実的です。)

この手法は、タイムスタンプとバージョン管理を補足または補完することができます。たとえば、行が変更されたことを示すステータス列がテーブル行に設定されている場合は、代替を構成できます (たとえば、true に設定されている場合は行が変更されたことを示すブール列)。それ以外の場合は、以前の方法を補完するものとして機能し、新しいバージョン番号または後の日付があるにもかかわらず、行をターゲットで更新してはならないことを示します (たとえば、データに人による検証が必要な場合があります)。

このアプローチは、これまでに説明した 3 つの方法を組み合わせたものです。前述のように、1 つのシステムで複数の CDC ソリューションが動作することは珍しくありませんが、時間、バージョン、ステータスの組み合わせは特に強力なメカニズムを提供するため、プログラマーは可能な場合はこれらを 3 つを組み合わせて使用​​する必要があります。3 つの要素は冗長でも不必要でもありません。これらを組み合わせて使用​​すると、「2005-06-01 00:00 から 2005-07-01 00:00 の間に変更されたバージョン 2.1 のすべてのデータをキャプチャし、ステータス コードが本番環境の準備が整っていることを示す」などのロジックが可能になります。

変更されたデータを複数のターゲットに伝達するための tern を含めることができます。このアプローチでは、トリガーはトランザクション テーブルで発生したイベントを別のキュー テーブルに記録し、後で「再生」することができます。たとえば、Accounts テーブルを想像してください。このテーブルに対してトランザクションが行われると、トリガーが起動し、イベントの履歴または差分が別のキュー テーブルに保存されます。キュー テーブルには、次のフィールドを含むスキーマがあります: Id、TableName、RowId、Timestamp、Operation。Account サンプルに挿入されるデータは、1、Accounts、76、2008-11-02 00:15、Update です。より複雑な設計では、変更された実際のデータが記録される可能性があります。その後、このキュー テーブルを「再生」して、ソース システムからターゲットにデータを複製することができます。

データ キャプチャでは、トランザクション ログの構造、内容、使用方法がデータベース管理システムに固有であるという点で課題があります。データ アクセスとは異なり、トランザクション ログには標準がありません。ほとんどのデータベース管理システムでは、トランザクション ログの内部形式が文書化されていませんが、トランザクション ログへのプログラム インターフェイスを提供するシステムもあります (例: Oracle、DB2、SQL/MP、SQL/MX、SQL Server 2008)。

変更データ キャプチャにトランザクション ログを使用する場合のその他の課題は次のとおりです。

• トランザクション ログの読み取りとログ ファイルのアーカイブを調整します (データベース管理ソフトウェアは通常、ログ ファイルを定期的にオフラインでアーカイブします)。
• トランザクション ログに記録される物理ストレージ形式と、データベース ユーザーが通常期待する論理形式との間の変換 (たとえば、一部のトランザクション ログでは、変更コンシューマーに直接役立たない最小限のバッファーの違いのみが保存されます)。
• データベース管理システムのバージョン間でのトランザクション ログの形式の変更に対処します。
• データベースがトランザクション ログに書き込んで後でロールバックした、コミットされていない変更を削除します。
• データベース内のテーブルのメタデータの変更を処理します。

トランザクション ログ ファイルに基づく CDC ソリューションには、次のような明確な利点があります。

• データベースへの影響は最小限です (ログ シッピングを使用して専用ホストでログを処理する場合はさらに影響が小さくなります)。
• データベースを使用するアプリケーションにプログラム的な変更を加える必要はありません。
• 変更を取得する際の遅延が小さい。
• トランザクションの整合性: ログ スキャンにより、元のトランザクションをコミットされた順序で再生する変更ストリームを生成できます。このような変更ストリームには、キャプチャされたトランザクションに参加しているすべてのテーブルに加えられた変更が含まれます。
• データベーススキーマを変更する必要はありません

複雑な分野ではよくあることですが、CDC の問題に対する最終的な解決策では、多くの競合する懸念事項のバランスを取る必要がある場合があります。

データ自体が変更されていないときにソース システムがメタデータの変更を保存する場合、変更データ キャプチャの複雑さが増し、価値が低下します。たとえば、一部のデータ モデルでは、データと同じ構造で最後にデータを参照したが変更しなかったユーザーを追跡します。これにより、変更データ キャプチャにノイズが発生します。

実際に変更を追跡するかどうかは、データ ソースによって異なります。データが最新のデータベースに保存されている場合、変更データ キャプチャは権限の問題にすぎません。一般的に使用されている手法は 2 つあります。

• データベーストリガーを使用した変更の追跡
• トランザクション ログが書き込まれた直後、または書き込まれた直後にそれを読み取ります。

データが最新のデータベースにない場合、CDC はプログラミング上の課題になります。

• プッシュ: ソース プロセスは、独自のプロセス内で変更のスナップショットを作成し、行を下流に配信します。下流プロセスはスナップショットを使用して独自のサブセットを作成し、次のプロセスに配信します。
• プル: ソースのすぐ下流にあるターゲットが、ソースからのデータの要求を準備します。下流のターゲットは、プッシュ モデルと同様に、スナップショットを次のターゲットに配信します。

時々、ゆっくり変化するディメンションが代替方法として使用されます。^[1] CDCとSCDは、両方の方法でデータセットの変更を検出できるという点で似ています。SCDの最も一般的な形式は、タイプ1（上書き）、タイプ2（履歴を維持）、またはタイプ3（以前の値と現在の値のみ）です。SCD 2は、ターゲットシステムで履歴が必要な場合に役立ちます。CDCはターゲットシステムで上書きし（SCD1に類似）、変更されたデータのみをターゲットに到着させる必要がある場合、つまりデルタ駆動データセットに最適です。

• 参照整合性
• ゆっくりと変化する次元

• Ankorion、Itamar Ankorion 2005.「リアルタイム BI 向けの変更データ キャプチャの効率的な ETL」Information Management、15(1)。

• Oracle データ インテグレータ