このページでは、 MongoDB ベクトル検索クエリのパフォーマンスを向上させるための追加の推奨事項を示します。
十分なメモリを確保する
Hierarchical Navigable Small Worlds works efficiently when vector data is held in memory. You must ensure that the data nodes have sufficient RAM to hold the vector data and indexes. We recommend deploying separate Search Nodes for workload isolation without data isolation, which enables more efficient usage of memory for vector search use cases.
埋め込みモデル | ベクトル次元 | スペース要件 |
|---|---|---|
Voyage AI | 2048 | 8kb（ |
OpenAI | 1536 | 6kb |
Google | 768 | 3kb |
Cohere | 1024 | 4kb（ |
BinData 量子化ベクトル。詳しくは、「量子化されたベクトルの取り込み」をご覧ください。
MongoDB ベクトル検索 が消費する CPU、メモリ、ディスク リソースの量は、インデックスサイズやクエリ条件など、いくつかの要因によって異なります。ベクトル検索の健全性とパフォーマンスを理解し、十分なインフラストラクチャのキャパシティーを確認して、異常を特定するために環境をモニターすることが重要です。
次のメトリクスを使用して、MongoDB ベクトル検索の検索インデックスとクエリのパフォーマンスを観察して改善します。
システムメモリを検索する
MongoDB ベクトル検索検索インデックスによって使用されるRAMの合計量をモニターします。ディスクに送信されるクエリのパフォーマンスが大幅に低下するため、十分なRAMがMongoDBベクトル検索クエリのパフォーマンスにとって重要です。インデックス全体がメモリに収まることを確認します。
Ensure that available System Memory is always greater than used System Memory. If the index is not frequently queried, not all of the index might be in memory. Therefore, leverage the System Memory metric in conjunction with the Index Size metric to optimize provisioning.
ベクトルインデックスのサイズが 3 GBを超える場合は、インデックス全体ではなくインデックスの 4% のみをメモリに保存するベクトル量子化を推奨します。
インデックスのサイズを検索
ディスク上のすべてのインデックスの合計サイズをバイト単位でモニターします。これは、RAM要件のサイズを正確に設定するために必要です。
Verify the search Index Size on disk metric to see what the full index size would be if 100% of the vector is stored in memory, and ensure that it is less than the system memory available.
検索ページのフォールト
選択したサンプル期間における、1秒あたりのプロセスのページフォールトの平均レートをモニターします。Page Faults メトリクスは、検索クエリがディスクにアクセスする頻度を示します。これは、完全なインデックスがメモリに収まらないことを示します。
このメトリクスは、可能な限り 0 に近くなる必要があります。ページフォールトが一貫して発生する場合は、十分なRAMをプロビジョニングするためにクラスター階層を拡大することを検討してください。
ファイルシステム キャッシュをウォームアップする
When you perform vector search without using dedicated Search Nodes, your queries initially perform random seeks on disk as you traverse the Hierarchical Navigable Small Worlds graph and the vector values are read into memory. When using Search Nodes, this cache warming typically only occurs in the event of an index rebuild, usually during scheduled maintenance windows.
CPU ボトルネックのモニター
Vector embeddings consume computational resources during indexing. ENN queries on large datasets consume CPU resources. As a result, indexing and querying at the same time may cause resource bottlenecks. To prevent CPU bottlenecks, avoid indexing vectors when queries are running. When performing an initial sync, ensure that your Search Node CPU usage returns close to 0%, indicating segments have been merged and flushed to disk, before issuing test queries.
インデックス操作中に Search Normalized Process CPU メトリクスを監視してください。頻繁にインデックスを作成すると CPU 使用率が上昇します。このメトリクスは、使用可能な CPU コアの数に対して正規化されたパーセンテージとして CPU 使用率を表示します。これにより、クラスターのキャパシティーに対するリソースの飽和を評価できます。ベクトル埋め込みがインデックス化された後、セグメントのマージとフラッシュが完了すると、CPU 使用率が 0% に近くなるまで待ちます。