このページでは、 MongoDB ベクトル検索の主要なパフォーマンス最適化戦略と、それを使用してベンチマークを作成した方法について説明します。このガイドを解釈する方法については、 「このベンチマークの使用方法」 を参照してください。
For our benchmark, we used the Amazon Reviews 2023 dataset, a massive e-commerce dataset containing 571.54M reviews across 33 product categories, representing interactions from May 1996 to September 2023. With approximately 48.2 million unique items covered by these reviews, it provides rich multimodal data including user reviews (ratings, text, helpfulness votes), item metadata (descriptions, price, images), and user-item interaction graphs. We looked at subsets of the item dataset (5.5M and 15.3M) that contain titles and descriptions, and used Voyage AI's voyage-3-large model to embed them using the following logic:
source = "Item: Title: " + record["title"] + " Description: " + record["description"] source_embedding = vo.embed(source, model="voyage-3-large", input_type="document", output_dimension=2048)
フィルターの結果の品質は、同じテキスト入力と要求されたベクトルの数に対する ANN クエリの結果と対応する 浮動小数点数 の正確な結果を使用して、Jaccard 類似性（intersection / expected number of results）を計算することによって決定されます。再現率は、 ｅコマースデータセットに要求される可能性のある 50サンプルクエリの平均共通部分を見つけることで計算されます。
注意
ベンチマークに使用されるソースコードと、ソースデータセットを埋め込むために使用されるコードを確認するには、Performance Testingリポジトリを参照してください
パフォーマンスに影響を与える要因
このセクションでは、 MongoDB ベクトル検索 のパフォーマンスに影響いくつかの要因と、それらをテストするためにベンチマークをどのように構成したかについて説明します。
量子化
量子化はベクトル埋め込みの精度を低下させてメモリ使用量を削減し、検索速度を向上させますが、検索精度が低下します。
スカラー量化
スカラー量子化は32ビットの浮動小数点ベクトルを8ビットの整数に変換し、メモリ使用量を4倍削減します。整数ベクトル比較は、浮動小数点ベクトルと比べて計算時間が短く、必要なリソースも少なくなりますが、検索精度のパフォーマンスが低下する可能性があります。
バイナリ量子化
バイナリ量子化はベクトルを1ビット表現に変換し、メモリ使用量を32倍削減します。バイナリベクトル比較はハミング距離の計算を含み、intベクトルと比べて計算時間がさらに短く、リソースも少なくて済みます。しかし、浮動小数点ベクトルからバイナリベクトルに移行すると、検索精度が非常に低下するため、これを考慮して、レイテンシを増加させる再スコアリングステップを追加します。クエリ時に、検索中に蓄積された上位のnumCandidatesは、上位のlimit結果を得る前に、ディスク上の完全な忠実度ベクトルによって順序付けられます。
ベクトル次元
Voyage AIのvoyage-3-largeモデルを使用して中規模（5.5M）と大規模（15.3M）のベクトルデータセットを埋め込みました。この埋め込みモデルを選んだのは、多くのIRベンチマークでの優れた性能と、マトリョーシカ表現学習および量子化を考慮してトレーニングされているためです。したがって、量子化を有効にすると、ベクトルの量が多い場合でも低次元で良好なパフォーマンスを発揮します。
ビューのインデックスの作成を活用し、ソース2048次元ベクトルの最初のN次元をスライスする追加のフィールドを生成して、1024、512、256次元ベクトルを生成しソースフィールドと同様にインデックスを作成しました。
注意
ビューにベクトル検索インデックスを作成するには、MongoDB バージョン 8.1 以降を使用しなければなりません。
db.createView( "all_dims_amazon_dataset", "2048d_amazon_dataset", [ { $addFields: { "1024_embedding": { $slice: ["$embedding", 1024] }, "512_embedding": { $slice: ["$embedding", 512] }, "256_embedding": { $slice: ["$embedding", 256] } } } ] )
db.all_dims_amazon_dataset.createSearchIndex( "all_dims_vector_index", "vectorSearch", { "fields": [ { "numDimensions": 2048, "path": "embedding", // original 2048d embedding produced by voyage-3-large "quantization": "scalar", // adjust to binary when needed "similarity": "dotProduct", "type": "vector" }, { "numDimensions": 1024, "path": "1024_embedding", "quantization": "scalar", "similarity": "cosine", // sliced embeddings aren't normalized, so must use cosine "type": "vector" }, { "numDimensions": 512, "path": "512_embedding", "quantization": "scalar", "similarity": "cosine", "type": "vector" }, { "numDimensions": 256, "path": "256_embedding", "quantization": "scalar", "similarity": "cosine", "type": "vector" } ] } )
各位置で異なる表現と同様に、異なる次元は各ベクトルの表現能力（キャパシティー）に影響を与えます。その結果、特に2048d浮動小数点厳密最近傍探索ベースラインと比較して測定する場合、256dベクトルよりも2048dベクトルでより高い精密度を達成できます。
より多くのストレージとメモリを必要とするだけでなく、高次元ベクトルは低次元ベクトルに比べてクエリが若干遅くなりますが、 MongoDB ベクトル検索 がベクトル比較を実行するときに SIMD を活用するため、これは大幅に軽減されます。
フィルタリング
また、すべての15.3Mアイテムを含むコレクションに対して、個別のインデックス定義を作成しました。これにはこのデータセットに対して事前にフィルタリングされたクエリを有効にするために2つのフィールドのフィルターが含まれています。
db.large_amazon_dataset.createSearchIndex( "vectorSearch", "large_vector_index", { "fields": [ { "numDimensions": 2048, "path": "embedding", "quantization": "scalar", // adjust to binary when needed "similarity": "dotProduct", "type": "vector" }, { "path": "category", "type": "filter" }, { "path": "price", "type": "filter" } ] } )
大規模のインデックス化されたデータセットに対して、フィルターなしおよびフィルター済みの検索クエリを実行しました。
# unfiltered query query = [ { "$vectorSearch": { "index": "large_vector_index", "path": "embedding", "queryVector": embedding.tolist(), "limit": k, "numCandidates": candidates, } }, { "$project": {"embedding": 0} } ]
# filtered query query = [ { "$vectorSearch": { "index": "large_vector_index", "path": "embedding", "queryVector": embedding.tolist(), "limit": k, "numCandidates": candidates, "filter": {"$and": [{'price': {'$lte': 1000}}, {'category': {'$eq': "Pet Supplies"}}]} } }, { "$project": {"embedding": 0} } ]
注意
Both query patterns exclude the embedding fields in the output by using $project stage. This is always recommended to reduce latency unless you need embeddings in your results.
検索ノード構成
MongoDB ベクトル検索 のパフォーマンスは 専用の検索ノードでスケーリングされます。このノードはプライマリデータベースのワークワークロードとは別にベクトル計算を処理し、専用のハードウェアインスタンスを効率的に使用します。すべてのテストは M20 ベースクラスターを使用して実行されましたが、テストのタイプに応じて、テストケースよりも優れた検索ノードを再構成しました。すべてのテストはAWS us-east-1 の検索ノードを使用して実行され、us-east-1 においても EC2インスタンスがリクエストを行っています。 AWSでプロビジョニングできる検索ノードは 3 種類あり、使用可能なディスク、 RAM、 vCPU の量が異なります。
ノード タイプ | リソースプロファイル | 推奨使用量 |
|---|---|---|
低 CPU | メモリ比率 (~6:1)、低vCPUに対して低ディスク | 量子化を活用しない多くのベクトルワークロードに適した開始点 |
高 CPU | メモリ比率（~25:1）、高vCPUに対して高ディスク | 高QPSワークロードまたは量子化を活用するワークロード向けのパフォーマンス選択 |
ストレージ最適化 | メモリ比率（～25:1）、低vCPUに対して高ディスク | 量子化を活用するワークロードに対するコスト効率の良い選択 |
Amazonデータセットのサイズ設定
768 次元の浮動小数ベクトルは、ディスク上の ～3KB の領域を占有し、このリソース要件は、ベクトルの数と各ベクトルの次元数に応じて直線的にスケーリングします。1M 768d ベクトルは ～3 GBを占有し、 1M 1536d は ～6 GBを占有します。
量子化を使用して、ディスクに保存されている完全忠実度ベクトルからメモリに保持される表現ベクトルを生成します。これにより、スカラー量子化では必要なメモリ量が3.75倍、バイナリ量子化では24倍に減少しますが、量子化されていないベクトルと量子化されたベクトルを保存するために必要なディスク容量は増加します。
1スカラー量子化768d次元ベクトルには、0.8kbのメモリ（3/3.75）と~3.8kbのディスク（3 + 3/3.75）が必要です。これらのハードウェアオプションと量子化のリソース要件を考慮し、さまざまなテストケースに対して次の検索ノード階層を選定しました。
テストケース | 必要なリソース（RAM、ストレージ） | Search Node Tier RAM, disk, vCPUs | 2xノードの料金 |
|---|---|---|---|
中規模データセット（5.5Mベクトル、すべての次元）、スカラー量子化 | 22, 104.5 GB | S50-ストレージ-最適化 32GB、843GB、4 vCPU | $1.04/hr |
中規模データセット（5.5Mベクトル、すべての次元）、バイナリ量子化 | 3.43, 104.5 GB | S30-高CPU 8GB 213GB 4vCPU | $0.24/hr |
大規模なデータセット（15.3Mベクトル、2048d)、スカラー量子化 | 32.64, 155.04 GB | S50-ストレージ-最適化 32GB、843GB、4 vCPU | $1.04/hr |
大規模なデータセット（15.3Mベクトル、2048次元)、バイナリ量子化 | 5.1, 155.04 GB | S30-高CPU 8GB 213GB 4vCPU | $0.24/hr |
binData ベクトル圧縮
大規模なデータセットには、ソースコレクションの各ベクトルのフットプリントを約60%削減するベクトル圧縮という追加機能を活用しました。これにより、ソースコレクションでIDがハイドレートされると、クエリ内のステップが加速されます。これはすべての大規模なワークロードに推奨されるステップです。
同時実行性
シリアルクエリレイテンシだけでなく、10と100のリクエストが同時に発行された場合の合計スループット/QPSも評価しました。
注意
より高度のスループットを処理するための推奨メカニズムは、検索ノードの数を水平に拡大することですが、これらのテストでは測定しませんでした。