Chapter 3 Introducing Change Data Capture †
要約 †
詳細で。
詳細 †
第2章で説明したように、データベースにデータがある場合は、他の場所でもデータのコピーが必要になる可能性があります。
おそらくフルテキストインデックス（キーワード検索用）、Hadoopやデータウェアハウス（ビジネスアナリティクスや推薦システムなどのオフライン処理用）で、
おそらく、さまざまな他のキャッシュやインデックスで（読み込みを高速化し、データベースから負荷を取り除くために）ログは、このデータ統合を実装する優れた方法です。
また、データソースが既存のデータベースの場合は、データベースからそのログを抽出するだけです。
このアイデアは、図3-1に示す変更データキャプチャ（CDC）と呼ばれます。
図3-1。データベースに書き込まれたすべてのデータ変更を追跡し、ログにエクスポートします。
図2-30では、アプリケーションがログに直接イベントを追加したのに対し、
図3-1のWebアプリケーションはデータベースを読み書きするために使用します。
リレーショナルデータベースの場合、アプリケーションはいつものように任意に行を挿入、更新、削除できます。
問題は、Webアプリケーションの動作を強制的に変更せずに、データベースのデータをログに取り込む方法です。
まず、これを観察してください：ほとんどのデータベースは、データベースの内容全体の一貫したスナップショットをエクスポートする機能を備えています（バックアップなど）。
たとえば、MySQLにはmysqldumpがあり、PostgreSQLにはpg_dumpがあります。
検索インデックスにデータベースのコピーが必要な場合は、そのようなスナップショットを取得して検索サーバーにインポートすることができます。
しかし、ほとんどのデータベースは決して立ち往生しません。常に誰かが書いています。
これは、データのコピーが完了する前にスナップショットが既に古くなっていることを意味します。
しかし、おそらくあなたは少し古いデータに対処することができます。
その場合、定期的に（たとえば、1日に1回）スナップショットを作成し、新しいスナップショットごとに
検索インデックスを更新することができます。
検索インデックスに最新の情報を表示するには、より頻繁にスナップショットを作成し、
大規模なデータベースでは、データベース全体のコピーを作成して再インデックスするには数時間かかることがあります。
通常、スナップショットと次のスナップショットの間でデータベースの小さな部分だけが変更されます。
最後のスナップショット以降にデータベースで変更された内容の「差分」のみを処理できる場合はどうなりますか？
これはデータの量も少なくなるため、このような差分をより頻繁に取ることができます。
もしあなたが1分ごとにこのような "差分"を取ることができたら？一秒ごと？ 100回/秒？
担当者のつぶやき †
みんなの突っ込み †
