ファイルシステムのスナップショットはベクトルデータベースのコンパクションにどのような影響を与えるか？

ファイルシステムのスナップショットによって、ベクトルのコンパクションで古いブロックと書き換え後のブロックの両方が保持され、領域の再利用が遅れ、マージ中のコピーオンライトの負荷が増大することがあります。

ベクトルデータベースでは、トゥームストーンの削除、小さなファイルのマージ、クエリの局所性の向上を目的にセグメントをコンパクションし、安全な置換処理の後に古いファイルを削除することがあります。マージ前に取得したファイルシステムのスナップショットは、それらの古いブロックを引き続き参照するため、プールはそれらを保持したまま、コンパクション後の出力用領域も割り当てます。スナップショットによって復旧可能性は維持されますが、スナップショットを使用していないファイルシステムとは空き容量とレイテンシの挙動が異なります。

コンパクションは論理レコードを新しいファイルに書き換える

多くのベクトルストアでは、不変のセグメントやログ構造化コンポーネントを使用します。更新や削除では新しい状態を追記し、その後、バックグラウンドのコンパクションが有効なレコードを読み取り、統合したファイルを書き込み、マニフェストを更新し、安全なコミット後に置き換えられたセグメントを削除します。この処理の影響は、想定するホームサーバーのワークロード下で測定可能な状態にしておく必要があります。

基礎となる LSMコンパクションでは、ログ構造化マージツリーを、書き込みをまとめて処理し、時間の経過とともにコンポーネントをマージする階層として説明しています。この書き換えパターンにより、コンパクション中に入力データと出力データの両方が一時的に必要になる理由がわかります。同じストレージとメモリの予算を複数のパイプライン段階で共有する場合、この違いは重要です。

ベクトル固有の構造には、グラフリンク、転置リスト、ペイロードインデックス、量子化ファイルなどが追加されるため、コンパクション後のバイト数が削除されたバイト数と一致するとは限りません。データベースレベルのクリーンアップとファイルシステムレベルのブロック再利用は、別々のイベントです。この境界は、推測ではなく、代表的な家庭内データを使ってテストする必要があります。

スナップショットはコンパクション前のブロックを参照可能な状態に保つ

コピーオンライト方式のスナップショットは、ある時点のブロックグラフを記録します。コンパクションによって新しいファイルが書き込まれると、アクティブなファイルシステムは新しいブロックを参照する一方、スナップショットは古いセグメントを参照し続けます。そのため、ライブビューからファイル名を削除しても、スナップショットが必要とするブロックは解放できません。

OpenZFSのスナップショットによるブロック保持では、スナップショットを、特定の時点におけるファイルシステムまたはボリュームの読み取り専用バージョンと定義しています。ライブデータとの相違が大きくなるほどスナップショットの使用領域は増加します。これは、大規模で書き換えの多いコンパクションによってまさに発生する現象です。

そのため、高速なスナップショットコマンドの後に、後続の書き込みによって大幅な空き容量の減少が起こることがあります。コストはスナップショットの作成時ではなく、その後の書き込みで現れる場合があり、参照しているすべてのスナップショットが削除されるまで継続します。この処理の影響は、想定するホームサーバーのワークロード下で測定可能な状態にしておく必要があります。

空き容量が少ないと、保持がレイテンシに変わる

コンパクションには一時的な余裕が必要であり、コピーオンライトによる割り当てには空きブロックが必要です。スナップショットによって古いセグメントが保持されると、プールが断片化したり容量上限に近づいたりして、書き込みが遅くなり、コンパクションが長引くことがあります。コンパクションが長引くと、セグメント数とクエリ処理量も増加します。

Milvusのベクトルコンパクションでは、ストレージとクエリの動作を改善するために、小さなセグメントをマージし、削除済みデータをクリーンアップする処理としてコンパクションを説明しています。この仕組みにより、論理的な変更が削除の集合であっても、ベクトルデータベースが大規模なファイルを書き換えることがある理由がわかります。

問題となるのは、作成時に報告されたスナップショットサイズから最終的なコストを予測できると考えることです。保持されるバイト数とテールレイテンシは、コンパクション量、更新の頻度、圧縮、削除されたベクトル、プールの空き容量、スナップショットの保持期間によって決まります。同じストレージとメモリの予算を複数のパイプライン段階で共有する場合、この違いは重要です。

Featured

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

ZimaCube2

$799.00 - $2,499.00

Buy Now

スナップショットとベクトルコンパクションに関するFAQ

コンパクション中はスナップショットを無効にすべきですか？

必ずしもそうではありません。スナップショットは復旧ポイントを保護しますが、大規模なコンパクションをスナップショットの取得期間外にスケジュールすると、保持される差分を減らせる場合があります。どのような変更を行う場合も、テスト済みのバックアップとデータベース整合性の計画を維持する必要があります。この境界は、推測ではなく、代表的な家庭内データを使ってテストする必要があります。

削除したベクトルをコンパクションした後も、なぜデータベースサイズが大きいままなのですか？

ライブデータベースが不要なセグメントを削除した後でも、古いブロックがスナップショット、クローン、またはバックアップから参照され続けていることがあります。データベースファイルのサイズと、ファイルシステムで参照されている領域は分けて確認してください。この処理の影響は、想定するホームサーバーのワークロード下で測定可能な状態にしておく必要があります。

スナップショットで整合性のないベクトルインデックスが取得されることはありますか？

データベースファイル、先行書き込みログ、マニフェスト、関連メタデータが停止状態になっていない、またはアトミックに取得されていない場合は、あり得ます。必要に応じて、ファイルシステムのスナップショットを取得する前に、データベースのチェックポイントまたはフラッシュ機能を使用してください。同じストレージとメモリの予算を複数のパイプライン段階で共有する場合、この違いは重要です。

制御されたマージ中のスナップショットによる差分を測定する

代表的なインデックスをクローンし、論理サイズと物理サイズを記録してからスナップショットを取得し、削除とコンパクションのサイクルを測定しながら実行します。コンパクションのデータ量、一時的な最大使用領域、スナップショットが参照するバイト数、プールの空き容量、書き込みレイテンシ、クエリのテールレイテンシ、スナップショット削除後に領域を再利用できるまでの時間を追跡します。

スナップショットによる停止メカニズムの説明と結果を比較します。データベースのバージョン、インデックス、データ、圧縮、プール設定、バックグラウンド負荷を一定に保ちながら、スナップショットなしの場合と、異なる保持期間の場合で繰り返します。この境界は、推測ではなく、代表的な家庭内データを使ってテストする必要があります。

スナップショットとコンパクションは、都合ではなく、測定した余裕に基づいてスケジュールします。データベースと整合性のある復元ポイントを維持し、古いセグメントと新しいセグメントの両方に備えて領域を確保します。また、容量計画の誤りを隠すために保護を削除するのではなく、定めた保持ポリシーに従ってのみスナップショットを期限切れにします。