ドキュメント削除後、ベクトルデータベースのコンパクションはどのように空き容量を再利用するのか？

ベクトルデータベースのコンパクションは、現行レコードをクリーンなセグメントに書き換え、削除済みベクトルを含む古いセグメントファイルを廃棄することで、削除済み領域を再利用します。

ローカルRAGライブラリから家庭用ドキュメントを削除すると、検索結果からはすぐに消える一方で、ディスク使用量はほとんど変わらないことがあります。これは必ずしも削除に失敗したという意味ではありません。多くのベクトルデータベースでは、フォアグラウンドの書き込みを高速に保ち、読み取り処理が不変セグメントや追記指向のセグメントを使い続けられるように、論理的な可視性と物理ストレージのクリーンアップを分離しています。コンパクションは後続のメンテナンス処理であり、論理的な削除をより小さな物理表現に変換します。

削除では通常、保存済みバイトを書き換える前に可視性が変わる

削除のたびに大きなインデックスファイルを物理的に編集すると、高コストなランダム書き込みや複雑な並行処理が発生します。そのため多くのエンジンでは、検索時にベクトルを無視するよう指示する削除マーカー、トゥームストーン、または削除ログを記録します。

HNSWのトゥームストーンを使用すると、バックグラウンドメンテナンスによってインデックス状態が物理的に完全削除される前に、削除済みオブジェクトをグラフ検索の対象外にできます。

したがって、ユーザーから見える結果とディスクレベルの結果は異なるタイミングで発生します。レコードは最近傍検索の結果に表示されなくなっても、古いバイトは既存のセグメント内に残っている可能性があります。

この分離により、データベースは履歴ストレージ構造を破棄する前に、同時実行クエリ、レプリカ、スナップショット、保持ルールを調整する余地も確保できます。

削除済みレコードは、クリーンアップのしきい値に達するまでセグメント内に蓄積される

1つのセグメントには、現行のベクトルと、検索対象外になったレコードの両方が含まれることがあります。更新や削除が蓄積すると、有用なデータに対する不要なデータの割合が高まります。

削除済みベクトルのしきい値により、セグメントを書き換える価値が出るほど不要なポイントが蓄積されるまで、高コストなクリーンアップを遅らせることができます。

しきい値を待つことで、メンテナンス作業を効率よく分散できます。削除済みレコードが1件だけのセグメントを書き換えると、節約できる容量よりも多くのI/Oコストがかかります。頻繁に再インデックスを行うホームサーバーでは、オプティマイザーがクリーンアップに価値があると判断するまで、古い物理ストレージの使用量がしばらく増え続けることがあります。

コンパクションでは、現行データを新しいセグメントまたは統合セグメントにコピーする

メンテナンスが始まると、データベースは対象となるソースセグメントを読み取り、論理的に削除されたレコードを除外して、残ったベクトルとペイロードを新しいコンパクトな表現に書き込みます。

セグメントの統合と削除クリーンアップとしてのコンパクションでは、すでに論理的に削除または期限切れになったレコードを省き、残ったデータをよりクリーンなセグメントに書き換えます。

同時に小さなセグメントを統合することもできるため、検索で参照する必要のある個別の構造数を減らせます。新しいセグメントは、過去のすべての変更を引き継ぐのではなく、現行の状態を表します。

置き換えが検証されて有効化されるまで、古いセグメントと新しいセグメントが共存する可能性があるため、この書き換えには一時的に追加の空き容量が必要になることがあります。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

インデックスは残ったベクトル集合を基準に再構築される

ベクトルのペイロードバイトを削除することは、クリーンアップの一部にすぎません。グラフのリンク、量子化構造、フィルター、セグメントメタデータが、現行セグメントに属さなくなったレコードを参照している可能性があります。

最適化中にインデックスを再構築するコンパクション処理により、グラフや補助的な検索構造が、削除されたポイントへの参照を保持するのではなく、残ったベクトル集合に対応するようになります。

HNSWでは、残ったベクトル自体が変わらなくても、グラフのトポロジーが変化することがあります。そのため、論理的なデータセットを維持しながら、コンパクションが近似最近傍探索の経路に影響を与えることがあります。この記事で扱う仕組みはストレージのライフサイクルです。不要なレコードは書き換え後のインデックスから除外されるため、最終的に物理的な占有領域が消滅します。

ストレージを解放するには、古いセグメントを廃棄する必要がある

コンパクションされたセグメントが有効な表現になると、古いセグメントは不要または削除済みとしてマークされます。ただし、実際のディスクブロックが解放されるまで、基盤ファイルがガベージコレクションや保持期間の終了を待つ場合があります。

コンパクション後にガベージコレクションが実行される場合、コンパクションされた置き換え先が有効になった後も、削除済みセグメントファイルが一時的に残ることがあります。そのため、ファイルシステムの空き容量が解放されるのは、検索結果から見えなくなるより後になる場合があります。

古いセグメント世代を保持するシステムでは、スナップショット、バックアップ保持、レプリケーション、または参照を保持している読み取り処理によって、この遅延が長くなることがあります。

したがって、ディスク監視では、論理エンティティ数、アクティブなセグメントサイズ、コンパクション用の一時領域、削除済みセグメント、ファイルシステムの空き容量を区別する必要があります。

コンパクションは、固有のリソースコストを伴うバックグラウンドメンテナンスである

古いセグメントの読み取り、新しいセグメントの書き込み、インデックスの再構築、不要なファイルの削除には、CPU、ディスク帯域幅、メモリ、場合によっては一時的な重複ストレージが必要です。

トゥームストーンのクリーンアップメトリクスにより、削除処理の修復を、独自のサイクル、所要時間、リソース消費を伴うメンテナンス負荷として可視化できます。

ファイル更新後に古いインデックスレコードを残さないことは、上流側の要件です。コンパクションで不要な表現を再利用するには、まずソースの削除がベクトルデータベースに反映されなければなりません。