ベクトルインデックスのセグメント統合とは何か、クエリのパフォーマンスはいつ変わるのか

エヴァ・ウォン

IceWhale author

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

What Is Vector Index Segment Merging, and When Does It Change Query Performance? - Zima Store Online

セグメントマージは、不変のインデックス断片をより少数の大きな構造へ統合します。多くの場合、定常状態のクエリ性能は向上しますが、バックグラウンドの計算資源とストレージ帯域幅を大幅に消費します。

ホーム検索サーバーでの増分取り込みでは、ドキュメントごとにインデックス全体を書き換えるのではなく、新しいベクトルセグメントまたは字句セグメントが作成されます。クエリはそれらの断片全体に分散されて実行され、結果が統合されます。一方、削除はトゥームストーンとして残る場合があります。マージでは選択したセグメントを書き換え、古いレコードを削除し、置き換え用の世代を作成します。そのため、作業中は性能が悪化し、完了後に改善することがあります。

セグメントにより、インプレース変更なしで新しいインデックスデータを公開できる

セグメントは、フラッシュまたはバッチ構築によって生成される、自己完結型で不変の検索構造です。ライブインデックスは複数のセグメントを参照するため、書き込み側がメタデータの変更を通じて新しいデータを公開している間も、読み取り側は安定したファイルに対してクエリを続行できます。

Solrのリファレンスでは、Luceneのインデックスが一度だけ書き込まれるセグメントを使用し、断片化が際限なく進むのを防ぐために定期的に統合すると説明されています。不変性によって同時読み取りは簡素化されますが、更新コストは後のマージへ移されます。この違いは、後の家庭環境でのテストでも確認できます。

ベクトルエンジンによってグラフ、転置リスト、量子化の詳細は異なりますが、ライフサイクルは共通しています。小さく検索可能な単位を作成し、置き換えられたレコードに印を付け、ポリシーに従って統合します。自動化に進む前に、中間結果を検査できる状態にしておく必要があります。

マージはデータを書き換え、クエリの分散実行先を変える

マージではソースセグメントを読み取り、アクティブなレコードを新しい大きなセグメントへコピーし、その検索構造を再構築して、新しいマニフェストをコミットします。その後、参照されなくなったファイルが削除されます。切り替え後のクエリは、より少ない断片を検索し、回収対象のトゥームストーンをスキップします。

Luceneのエンジニアリング用ビジュアライゼーションでは、同時実行されるセグメントマージが示されており、マージ対象の入力が大きくなるほど時間がかかります。この処理では、フォアグラウンドのクエリを利用できる状態でも、I/O、CPU、一時容量、ページキャッシュが消費されます。この境界は、現実的な運用条件の下で個別に測定する必要があります。

セグメント数が少なくなるとセグメントごとのオーバーヘッドを削減できますが、より大きな構造ではキャッシュ局所性やグラフ特性が異なる場合があります。したがって、セグメント数だけではベクトルの再現率やレイテンシーを正確に予測できません。限られたコンテキストを複数のソースが奪い合うときに、実際の影響が現れます。

フォアグラウンドの競合とマージ後の形状は逆方向に作用する

マージ中は、シーケンシャルな読み書きが検索、モデルの読み込み、取り込みと競合します。新しいファイルによってホットなインデックスページが追い出される可能性があり、一時的な重複によって必要な空き容量とSSDの書き込み増幅も増加します。この依存関係は、最終的なインターフェースでも明示しておく必要があります。

マージとクエリの競合に関する研究では、インデックスのメンテナンスとクエリの間で発生するCPU、ディスク帯域幅、ページキャッシュの競合が特定されています。これは、マージ後のインデックスで必要な分散実行先が少なくなっても、p99レイテンシーが急上昇する可能性がある理由を説明しています。そのため、結果は元の証拠と照合して確認する必要があります。

障害が発生しやすい境界は、頻繁に変更されている、または空き容量に制約のあるインデックスに対して強制マージを積極的に実行することです。この操作によって、直ちに新しい小さなセグメントが作成されたり、一時ストレージが枯渇したり、わずかなクエリ改善と引き換えに数時間にわたってサービス品質が低下したりする可能性があります。

-15% OFF

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

Single board computer zimaboard2

同じマージについて、前・実行中・後の状態を測定する

セグメント数とサイズ、ライブベクトルと削除済みベクトル、一時バイト数、マージスループット、SSD書き込み量、CPU使用率、ページキャッシュミス、取り込み速度、再現率、p50およびp99クエリレイテンシーを記録します。この違いは、後の家庭環境でのテストでも確認できます。

セグメントマージ後のランキングと順位の変化を比較します。同一のクエリセットを、マージ前、メンテナンスがピークに達している間、切り替え直後、キャッシュが温まった後に再実行します。自動化に進む前に、中間結果を検査できる状態にしておく必要があります。

マージポリシーは、完全なタイムラインに基づいてのみ調整します。マージ後のクエリが改善しても、メンテナンスによってレイテンシー目標に違反する場合は、すべての断片を1つのセグメントへ強制的にまとめるのではなく、バックグラウンド処理を制限するか、スケジュール設定します。この境界は、現実的な運用条件の下で個別に測定する必要があります。