パフォーマンスFAQ

IVFインデックスのnlist 、nprobe の設定方法を教えてください。

nlist の設定はシナリオによって異なります。経験則として、nlist の推奨値は4 × sqrt(n) で、n はセグメント内のエンティティの総数です。

各セグメントのサイズはdatacoord.segment.maxSize パラメータによって決定され、デフォルトでは 512 MB に設定されている。セグメント内のエンティティの総数 n は、datacoord.segment.maxSize を各エンティティのサイズで割ることで推定できる。

nprobe の設定は、データセットとシナリオに固有であり、精度とクエリパフォーマンスのトレードオフを伴います。実験を繰り返して理想的な値を見つけることをお勧めします。

以下のグラフは、sift50mデータセットとIVF_SQ8インデックスで実行したテストの結果です。nlist/nprobe の異なるペアのリコールとクエリのパフォーマンスを比較しています。

精度テスト パフォーマンステスト

なぜ小さいデータセットではクエリに時間がかかるのか？

クエリ操作はセグメントに対して行われます。インデックスを使うことで、セグメントへのクエリにかかる時間が短縮されます。セグメントがインデックス化されていない場合、Milvus は生データの総当り検索に頼ることになり、クエリ時間が大幅に増加する。

そのため、インデックスが作成されていない小さなデータセット（コレクション）に対するクエリには通常時間がかかる。これはセグメントのサイズがrootCoord.minSegmentSizeToEnableindex で設定されたインデックス構築のしきい値に達していないためである。create_index() を呼び出すことで、Milvusに閾値に達しているがまだ自動的にインデックスが作成されていないセグメントに強制的にインデックスを作成させ、クエリパフォーマンスを大幅に向上させることができます。

CPU使用率に影響を与える要因は何ですか？

Milvusがインデックスを構築したり、クエリを実行したりするとCPU使用率が増加します。一般的に、インデックス構築はシングルスレッドで実行されるAnnoyを使用する場合を除き、CPUを集中的に使用します。

クエリを実行する場合、CPU使用率はnq とnprobe の影響を受けます。nq とnprobe が小さい場合、同時実行性は低く、CPU使用率は低く保たれる。

データの挿入と検索を同時に行うと、クエリのパフォーマンスに影響しますか？

挿入操作に CPU が集中することはありません。しかし、新しいセグメントがインデックス構築の閾値に達していない可能性があるため、Milvusは総当たり検索に頼り、クエリ性能に大きな影響を与えます。

rootcoord.minSegmentSizeToEnableIndex パラメータはセグメントのインデックス構築しきい値を決定し、デフォルトでは1024行に設定されています。詳細はシステム構成を参照してください。

Milvusでデータを削除した後、ストレージ容量はすぐに解放されますか？

いいえ、Milvusでデータを削除してもストレージ領域はすぐに解放されません。データを削除するとエンティティは「論理的に削除された」ことになりますが、実際の容量はすぐに解放されない場合があります。その理由は以下の通りです：

• コンパクション：Milvusはバックグラウンドで自動的にデータを圧縮します。このプロセスは、より小さなデータセグメントをより大きなデータセグメントに統合し、論理的に削除されたデータ（削除マークが付けられたエンティティ）またはTTL（Time-To-Live）を超えたデータを削除します。ただし、コンパクションは新しいセグメントを作成する一方で、古いセグメントには "Dropped "というマークを付ける。
• ガベージコレクション：ガベージコレクション (GC) と呼ばれる別プロセスが、定期的に "Dropped" セグメントを削除する。これにより、ストレージの効率的な使用が保証されますが、削除とスペースの再利用の間に若干の遅延が生じることがあります。

挿入、削除、またはアップサートされたデータを、フラッシュを待たずに操作直後に見ることはできますか？

はい、Milvusでは、ストレージとコンピュートを分離したアーキテクチャのため、データの可視性はフラッシュ操作に直接関係しません。一貫性レベルを使用してデータの可読性を管理することができます。

一貫性レベルを選択する際には、一貫性とパフォーマンスのトレードオフを考慮してください。即時の可視性が必要な操作には、"Strong "一貫性レベルを使用する。書き込みを高速に行うには、一貫性を弱くすることを優先する（データはすぐには見えないかもしれない）。詳細は一貫性を参照してください。

VARCHARフィールドにインデックスを付けると削除速度が向上しますか?

VARCHARフィールドにインデックスを付けることで、"Delete By Expression "操作を高速化できますが、特定の条件下でのみ可能です：

• INVERTEDインデックス：INVERTED インデックス：このインデックスは、プライマリ・キーでない VARCHAR フィールドのIN または== 式に役立ちます。
• トライ・インデックス：このインデックスは、主キーでないVARCHARフィールドに対する接頭辞クエリ（例えば、LIKE prefix% ）に役立ちます。

しかし、VARCHARフィールドにインデックスを付けてもスピードは上がりません：

• IDによる削除：VARCHARフィールドが主キーの場合。
• 関連性のない式：VARCHARフィールドが削除式の一部でない場合。

まだ質問がありますか?

できます：

• GitHub でMilvus をチェックしてください。気軽に質問したり、アイデアを共有したり、他の人を助けたりしてください。
• Slackチャンネルに参加して、オープンソースコミュニティに参加してください。