ベクトルインデックスのトゥームストーン：コンパクションされるまで削除済みファイルが検索可能なままになる仕組み

エヴァ・ウォン

IceWhale author

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

Vector Index Tombstones: How Deleted Files Remain Searchable Until Compaction - Zima Store Online

インデックスが論理的な削除マーカーを記録していても、古いセグメント、レプリカ、キャッシュ、派生チャンクが検索結果を提供し続けると、削除済みファイルが発見可能な状態で残ることがあります。

ホームNASからPDFを削除しても、その埋め込み、サムネイルテキスト、OCR出力、キャッシュされた検索結果まで必ず削除されるとは限りません。多くのストレージエンジンは、まずレコードを削除済みとしてマークし、後からコンパクション中にそのデータを再利用可能にします。正しいクエリ経路は直ちにそのマーカーを尊重すべきですが、伝播が不完全だったりフィルターが回避されたりすると、古い証拠が表面化する可能性があります。

削除マーカーは論理削除と物理的な再利用を分離する

追記型ストレージでは、削除のたびに大きなセグメントを書き換えるのはコストが高くなります。削除マーカーは、識別子が現時点で有効ではないことを記録します。クエリはこの状態を参照し、バックグラウンドのコンパクションによって、対象のデータとそのマーカーが安全に削除できる段階でセグメントを統合し、両方を除去します。

データベースにおける論理的な削除マーカーについての解説では、コンパクションによって物理データが削除される前に、削除済みの行が返されるのを防ぐ仕組みとして説明されています。セグメントや削除マップの実装が異なる場合でも、同じ原則がベクトルシステムに当てはまります。

この違いにより、削除後もディスク使用量が減らない理由が説明できます。ただし、それだけでは検索結果が表示される理由にはなりません。現在の正しいクエリでは、データがディスク上に残っていても、削除マーカーが付いたベクトルを除外しなければなりません。

削除したファイルには複数の独立した派生データが残る可能性がある

1つのソースファイルから、チャンク、埋め込み、キーワードの転置リスト、要約、OCRテキスト、サムネイル、回答キャッシュのエントリなどが生成されることがあります。ベクトルIDだけを削除しても、ほかの検索経路は残ります。新しい識別子で再取り込みすると、元の削除リストでは対象にならない重複データが作成されることもあります。

コンパクションによるクリーンアップに関するデータベースの説明では、データを継続的に書き換えるのはコストが高いため、再利用可能な領域の回収はコンパクション中に行われるとされています。連携したクリーンアップが完了するまで、物理ストレージと論理的な可視性は別の状態として扱う必要があります。この違いによって、家庭内での判断も変わります。

そのため、信頼できる削除台帳では、ソースの識別情報をすべての派生データと名前空間に対応付けます。また、削除対象の世代も記録し、同じファイル名を持つ新しい置換ファイルを、遅れて到着した削除イベントによって誤って非表示にしないようにします。

古いレプリカとキャッシュが削除の意味を損なう場所

分散検索や複数プロセスによる検索では、伝播の遅延が発生します。あるワーカーは削除マーカーを尊重していても、別のワーカーが古いセグメントを提供することがあります。また、レスポンスキャッシュがインデックスにクエリを送らず、以前に生成された回答を返す場合もあります。保持ルールに削除済みの派生データが含まれていなければ、バックアップによって後から復元される可能性もあります。

DataStaxは、レプリカの削除マーカーを、最終的な削除が行われる前にレプリカ間で伝播されるマーカーとして説明しています。猶予期間は分散ストレージでのデータの復活を防ぎますが、早すぎるクリーンアップやレプリカ間の不整合には慎重な調整が必要であることも示しています。この境界は、後で証拠を確認する際にも明確になります。

問題となる境界は、使用中のバイト数ではなく、クエリから見えるかどうかです。約束した削除期間を過ぎても、対応している検索経路のいずれかが削除済みの証拠を返せるなら、ダッシュボードに成功と表示されていても、システムは削除を完了していません。

-15% OFF

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

Single board computer zimaboard2

すべての検索経路で削除を証明する

削除前に、ソースID、派生チャンクID、一意のフレーズ、キャッシュ済みの質問を1つ記録します。ファイルを削除したら、コンパクションの前後に、フレーズ、意味的な言い換え、メタデータフィルター、ソースID、キャッシュ済みの質問で検索します。

インクリメンタルインデックスの状態で説明されている、現在のファイルを基準に管理する方法と同じように、テストでは論理的な可視性、物理ストレージ、履歴保持を区別する必要があります。1回のクエリが成功したからといって信頼せず、設定されているすべてのレプリカやワーカーを調べてください。そのため、実際には依存関係を個別に測定する必要があります。

現在モードのどの経路からもソースやその派生データが返されず、キャッシュが無効化され、最終的にコンパクションによって想定したストレージ領域が回収された場合にのみ、合格とします。履歴からの復元を意図的に許可する場合は、別の認可の背後に分離し、通常のRAGクエリからは利用できないようにしてください。