ベクトルインデックスのトゥームストーンとは何か、ファイル削除後に重要なのはなぜか？

エヴァ・ウォン

IceWhale author

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

What Is a Vector Index Tombstone, and Why Does It Matter After File Deletion? - Zima Store Online

ベクトルインデックスのトゥームストーンとは、基盤となる検索構造が物理的に再利用される前に、削除されたレコードを非表示にする論理的な削除マーカーです。

ローカルRAGインデックスでは、PDFや写真を削除すると、ベクトルグラフ、セグメントファイル、ストレージページが書き換えられるよりもずっと前に、そのチャンクが通常の検索結果から消えることがあります。トゥームストーンを使うことで、後からメンテナンスを行う間も、データベースはインデックスの整合性を維持できます。この中間状態は、ストレージ容量の見積もり、インデックスの健全性、更新による変動、そして論理削除が即時の物理消去と同じだという前提に関わります。

トゥームストーンは物理クリーンアップより先にレコードを削除済みにする

近似インデックスからレコードを削除する際、すべての物理的な参照を1回の低コストな操作で取り除けるとは限りません。代わりに、システムは項目を削除済みとしてマークし、表示される検索結果から除外したうえで、構造的なクリーンアップを後のメンテナンス処理に委ねることができます。

HNSWインデックスでは、トゥームストーンが削除済みオブジェクトをマークし、クリーンアップ処理によって削除されるまでグラフ内に残ることがあります。

家庭用ナレッジベースでは、これは元のファイルが消え、クエリ層がそのチャンクを正しく非表示にできていても、内部のインデックス状態には、それらのノードがかつて存在していたことが記録されている可能性があるという意味です。

インデックスに状態が残っていても、検索では削除済みベクトルを非表示にできる

論理削除と物理的な再利用は、それぞれ異なる問いに答えます。前者はレコードが検索結果に表示される対象かどうかを問い、後者はそのバイトデータとインデックス上の関係がストレージやメモリ構造から削除されたかどうかを問います。

セグメントベースのインデックスでは、すべての削除のたびにセグメントを即座に書き換えるのではなく、削除済みレコードをマージまで残すことがあります。

この分離があるため、ディスク使用量が減る前にコレクションの件数が減少することがあります。また、大量の削除や更新が発生するワークロードでは、古いレコードを通常の検索結果に戻すことなく、メンテナンスの負債が蓄積する理由も説明できます。

そのため、監視ダッシュボードでは、稼働中のレコード数、削除保留状態、セグメント数、実際のディスク使用量を区別して表示する必要があります。1つの指標だけを見てクリーンアップが完了したと判断すべきではありません。

ファイルの変更や置き換えを繰り返すとトゥームストーンが蓄積する

プライベートインデックスでは、ユーザーがファイルを完全に削除した場合だけでなく、通常の更新処理でも削除マーカーが生成されます。1つのドキュメントを新しいバージョンに置き換えると、古いチャンクが削除されて新しいチャンクが挿入されることがあります。また、フォルダーを整理すると、以前の識別子に紐づくレコードが不要になる場合もあります。

可変ベクトルコレクションでは、セグメントの最適化によって変更が非同期に統合されるまで、更新や削除が蓄積します。

家庭用ナレッジベースでドキュメントを頻繁に再埋め込みする場合、現在検索可能なファイル数よりも、トゥームストーンの増加量のほうが更新の多さを示す優れた指標になることがあります。クリーンアップの頻度は、更新率と利用可能なI/Oの余力に応じて設定する必要があります。

-15% OFF

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

Single board computer zimaboard2

トゥームストーンは安全な消去ではない

論理マーカーは、インデックスの正確性を維持するためのものであり、フォレンジックな削除を目的としたものではありません。セグメントファイル、スナップショット、レプリカ、バックアップ、ファイルシステムの空き領域、その他の派生ストアには、別のライフサイクル処理によって削除されるまで古いデータが残っている可能性があります。

後続の削除後のコンパクション段階は、トゥームストーン自体とは異なる仕組みです。これは、不要になったセグメント状態を書き換え、容量を再利用できる処理です。

機密性の高い削除は、元ファイル、ベクトルストア、メタデータ、キャッシュ、スナップショット、バックアップを含む、エンドツーエンドの保持期間管理の問題として扱ってください。トゥームストーンは、その大きなライフサイクルの中にある、整合性を維持するための中間的な仕組みの1つです。

この境界を理解しておくと、誤解を招くストレージ上の期待も防げます。数千個のチャンクを削除すると検索上はすぐに正しい状態になっても、スケジュールされたクリーンアップが完了するまで、空き容量のグラフには変化が現れないことがあるのです。