変更データキャプチャはローカルのナレッジインデックスをどのように更新するのか？

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

How Does Change Data Capture Update a Local Knowledge Index? - Zima Store Online

変更データキャプチャ（CDC）は、確定したソースの変更を下流のインデックス作業ワーカーが段階的に処理できるイベントへ変換することで、ローカルのナレッジインデックスを更新します。

これは、ホームナレッジベースが単なるフォルダー監視ではなく、構造化されたアプリケーションデータベースに支えられている場合に重要です。ノート、在庫レコード、メディアメタデータ、ブックマーク、ホームオートメーションの履歴、ドキュメントカタログの行などは、継続的に変更される可能性があります。1件の編集レコードを見つけるためにデータベース全体を再読み込みすると、I/Oを浪費し、最新状態になるまでの遅延も大きくなります。CDCは代わりにデータベース自身の変更ストリームを追跡し、インデクサーに具体的な変更操作のシーケンスを提供します。

CDCはすべての行を再スキャンするのではなく、ソースの変更ストリームを読み取る

多くのデータベースは、トランザクションログ、レプリケーションストリーム、または同等の順序付き変更レコードに、確定済みの変更操作をすでに記録しています。CDCシステムはそのストリームを購読し、低レベルのログ情報を、利用可能な挿入・更新・削除イベントへ変換します。

ログベースのCDCは、ソースの変更ストリームから行レベルのデータベース変更を直接取得します。そのため、少数の変更を見つけるだけの目的でテーブル全体を繰り返しポーリングする必要がありません。

これはファイルシステムウォッチャーとは異なります。ウォッチャーはOSのパス単位のイベントを監視しますが、CDCはデータベース内部の論理的なソース変更を監視し、トランザクションの順序とレコードの識別情報を保持できます。

ナレッジインデックスが受け取る作業キューは、はるかに小さくなります。「レコード184が変更された」に対応するほうが、「90万行をスキャンしてすべてを再比較する」よりも低コストです。

各イベントには、派生インデックスレコードを見つけるために必要な識別情報が含まれる

更新イベントが役立つのは、インデクサーが変更されたソース行を、そこから以前に生成されたチャンク、テキストフィールド、メタデータレコード、またはベクトルに関連付けられる場合だけです。

レプリカ識別情報は、レプリケーションされた更新や削除で利用できる行識別情報を決定します。これにより、下流のコンシューマーは派生インデックスレコードを安定して対象にできます。

ローカルのインデックス作成パイプラインでも、すべての派生レコードに同様の安定したソースキーを保持すべきです。そうすれば、`UPDATE`では影響を受けたドキュメントファミリーだけを取得して再構築でき、`DELETE`では無効にすべきすべてのベクトルを特定できます。安定した識別情報がなければ、イベントストリームが何かの変更を知らせても、どのインデックス成果物がそのソースに属するのかを見つけるために、高コストな検索が必要になります。

インデクサーはデータベースの変更操作を検索レイヤーのアクションへ変換する

CDCイベントには埋め込みベクトルが含まれておらず、チャンク分割の方針も認識していません。これは権威あるソースレイヤーからの通知であり、そのまま使えるベクトル操作ではありません。

構造化された変更イベントレコードは、ソースの変更と下流のインデックス作成ロジックを分離します。これによりコンシューマーは、挿入、更新、削除のどれに対して解析、埋め込み生成、または廃止処理が必要かを判断できます。

インデックス作成ワーカーは、挿入を解析して追加、更新を比較して再構築、削除をソースキーから派生したすべての検索レコードのトゥームストーン化または削除へマッピングできます。

コンテンツハッシュは、この更新処理の中に組み込めます。CDCはどのソースレコードが変更されたかを示し、その後ハッシュの検査によって、埋め込みモデルへの入力テキスト自体が変更されたかどうかを判断できます。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

オフセットとチェックポイントにより、再起動後もコンシューマーは処理を再開できる

ホームサーバーは再起動し、コンテナはアップグレードされ、インデックス作成ワーカーも時折停止します。コンシューマーが自分の位置を失うと、変更を取りこぼすか、大量の処理を再実行することになります。

永続化されたソースオフセットにより、キャプチャ処理は再起動後、最初からやり直したり変更を黙ってスキップしたりせず、既知の位置から再開できます。

ナレッジインデックスのコンシューマーは、関連するインデックス変更が永続的な状態になった後にのみ、自身のチェックポイントをコミットすべきです。そうしなければ、ベクトルやメタデータが実際には書き込まれていない段階でイベントが確認済みになる可能性があります。イベントの再実行も安全であるべきです。安定したIDをキーにしたアップサート、バージョンチェック、冪等性のある削除処理により、重複配信によって重複チャンクが作成されるのを防げます。

CDCは最新状態になるまでの遅延を短縮するが、リコンシリエーションの代わりにはならない

ログベースのストリーミングは、順序付けられたデータベース変更の処理に強みがあります。しかし、設定ミス、保持期間の制限、コネクターの停止、スキーマ変更、コンシューマーのバグによって、ソースとインデックスの間に欠落が生じる可能性はあります。

変更イベントの取りこぼしのリスクは、高速な増分ストリームであっても、権威あるソース状態との低速なリコンシリエーションで補完すべき理由を示しています。

定期的なリコンシリエーションでは、ソースの行数、バージョン、コンテンツハッシュ、削除マーカー、インデックス済みIDを比較し、ライブストリームが取りこぼしたものを修復できます。

これにより、システムは2つの時間軸を持てます。CDCは通常の変更を数秒から数分以内に最新化し、リコンシリエーションはより遅いながらも完全性を保証します。

更新頻度が高いと、ソースとインデックスの間にバックプレッシャーが生じる

データベースは、OCR、チャンク分割、埋め込み生成、またはベクトルインデックスのメンテナンスが処理できる速度を上回る速さで変更を確定できます。その場合、CDCキューはソースの活動と検索の最新状態との間のバッファになります。

データ変更イベントのバイナリログが永続化されていれば、一時的な停止後に、下流の低速なインデクサーが順序付き履歴を消費できます。ただし、これはソースシステムの保持期間に左右されます。

同じソースIDへの近接した更新をまとめ、削除や権限変更を優先し、キューの長さだけでなく遅延も監視します。1,000件のイベントが、1,000件の独立したドキュメントを表す場合もあれば、1つのレコードへの繰り返し編集を表す場合もあります。インデックスが最新になるのは、コンシューマーが既知のソース位置までイベントを適用し、それらのレコードに必要な下流の埋め込み生成や圧縮処理も完了した時点です。