VDBBench 1.0 発表：実際の本番ワークロードによるオープンソースの VectorDB ベンチマーキング
ほとんどのベクトルデータベースのベンチマークは、静的データと事前構築済みインデックスでテストします。しかし、本番システムはそのようには動作しません—ユーザーがクエリを実行している間もデータは継続的に流れ込み、フィルターによってインデックスは断片化し、読み書きが同時に発生する負荷の下ではパフォーマンス特性が劇的に変化します。
本日、私たちは VDBBench 1.0 をリリースします。これは、ストリーミングデータ取り込み、選択率の異なるメタデータフィルタリング、そして実際のシステムボトルネックを明らかにする同時実行ワークロードなど、現実的な本番条件下でベクトルデータベースをテストするためにゼロから設計されたオープンソースのベンチマークです。
VDBBench 1.0 をダウンロード → | リーダーボードを見る →
現在のベンチマークが誤解を招く理由
率直に言いましょう—私たちの業界には奇妙な現象があります。誰もが「ベンチマークを都合よく操作しない」と語りますが、多くの人がまさにその行動に参加しています。2023年にベクトルデータベース市場が急拡大して以来、「ベンチマークでは美しく見える」が本番では「惨憺たる失敗」をするシステムの例を数多く見てきました。その結果、エンジニアリング時間が浪費され、プロジェクトの信頼性が損なわれています。
私たちはこの乖離を firsthand に目の当たりにしてきました。たとえば、Elasticsearch はミリ秒レベルのクエリ速度を誇りますが、その裏では、インデックスを最適化するだけで20時間以上かかることがあります。どの本番システムがそのようなダウンタイムに耐えられるでしょうか？
この問題は、3つの根本的な欠陥に起因しています：
時代遅れのデータセット: 多くのベンチマークはいまだに SIFT（128次元）のようなレガシーデータセットに依存していますが、現代の埋め込みは768〜3,072次元に及びます。128D ベクトルと 1024D+ ベクトルを扱うシステムのパフォーマンス特性は根本的に異なります—メモリアクセスパターン、インデックス効率、計算複雑性のすべてが劇的に変化します。
見栄え重視の指標: ベンチマークは平均レイテンシやピーク QPS に焦点を当て、歪んだ像を作り出します。平均レイテンシが10msでも P99 レイテンシが2秒のシステムは、ひどいユーザー体験を生みます。30秒間で測定されたピークスループットは、持続的なパフォーマンスについて何も教えてくれません。
過度に単純化されたシナリオ: ほとんどのベンチマークは、基本的な「データを書き込む、インデックスを構築する、クエリする」ワークフローをテストします—本質的には「Hello World」レベルのテストです。実際の本番環境では、クエリを処理しながら継続的にデータを取り込み、インデックスを断片化させる複雑なメタデータフィルタリングがあり、読み書きの同時操作がリソースを奪い合います。
VDBBench 1.0 の新機能
VDBBench は、時代遅れのベンチマーク思想を単に反復するものではありません—「ベンチマークは実際の本番挙動を予測できて初めて価値がある」という1つの信念に基づき、概念そのものを第一原理から再構築しています。
私たちは VDBBench を、データの真正性、ワークロードパターン、パフォーマンス測定方法論 という3つの重要な次元にわたって現実世界の条件を忠実に再現するように設計しました。
どのような新機能が提供されるのか、詳しく見ていきましょう。
🚀 本番環境に関連する可視化を備えた再設計されたダッシュボード
ほとんどのベンチマークは生のデータ出力のみに注目しますが、重要なのはエンジニアがその結果をどのように解釈し、行動に移すかです。私たちは UI を再設計し、明瞭性とインタラクティブ性を優先しました—システム間のパフォーマンスギャップを見つけ、迅速にインフラ判断を下せるようにするためです。
新しいダッシュボードは、パフォーマンス数値だけでなく、それらの関係性も可視化します：異なるフィルター選択率レベルで QPS がどのように低下するか、ストリーミング取り込み中に recall がどのように変動するか、そしてレイテンシ分布がシステムの安定性特性をどのように明らかにするかです。
VDBbench dashboard
最新の構成と推奨設定を用いて、Milvus、Zilliz Cloud、Elastic Cloud、Qdrant Cloud、Pinecone、OpenSearchを含む主要なベクトルデータベースプラットフォームを再テストし、すべてのベンチマークデータが現在の能力を反映していることを確認しました。すべてのテスト結果は VDBBench Leaderboardで確認できます。
🏷️ タグフィルタリング：隠れたパフォーマンスキラー
実世界のクエリが単独で発生することはほとんどありません。アプリケーションはベクトル類似度とメタデータフィルタリング（「この写真のように見えるが100ドル未満の靴を見つける」）を組み合わせます。このフィルタ付きベクトル検索は、ほとんどのベンチマークが完全に無視している独自の課題を生み出します。
フィルタ付き検索は、2つの重要な領域で複雑さをもたらします。
フィルタの複雑さ：スカラー項目の増加や複雑な論理条件は計算負荷を高め、リコール不足やグラフインデックスの断片化を引き起こす可能性があります。
フィルタの選択性：これは、本番環境で繰り返し確認してきた「隠れたパフォーマンスキラー」です。フィルタ条件が非常に選択的になる（データの99%以上を除外する）と、クエリ速度は桁違いに変動する可能性があり、インデックス構造が疎な結果セットに苦戦することでリコールが不安定になることがあります。
VDBBenchは、さまざまなフィルタ選択性レベル（50%から99.9%まで）を体系的にテストし、この重要な本番パターンにおける包括的なパフォーマンスプロファイルを提供します。その結果は、従来のベンチマークでは決して現れないような劇的なパフォーマンスの崖をしばしば明らかにします。
例：Cohere 1Mテストでは、Milvusはすべてのフィルタ選択性レベルで一貫して高いリコールを維持した一方、OpenSearchはフィルタ条件の違いによってリコールが大きく変動する不安定なパフォーマンスを示し、多くの場合でリコールが0.8を下回りました。これはほとんどの本番環境では許容できません。
図：異なるフィルタ選択性レベルにおけるMilvusとOpenSearchのQPSおよびリコール（Cohere 1Mテスト）。
🌊 ストリーミング読み書き：静的インデックステストを超えて
本番システムが静的データという贅沢を享受できることはほとんどありません。検索が実行される一方で、新しい情報が継続的に流入します。これは、検索パフォーマンスを維持しながら継続的な書き込みを処理するという二重の圧力の下で、一見優れた多くのデータベースが崩壊するシナリオです。
VDBBenchのストリーミングシナリオは実際の並列操作をシミュレートし、開発者が高並行環境におけるシステムの安定性、特にデータ書き込みがクエリパフォーマンスに与える影響や、データ量の増加に伴うパフォーマンスの推移を理解できるようにします。
異なるシステム間で公正な比較を確保するために、VDBBenchは構造化されたアプローチを使用します。
目標とする本番ワークロードを反映した、制御された書き込みレートを設定する（例：5つの並列プロセスに分散した500行/秒）
データ取り込みが10%進むごとに検索操作をトリガーし、シリアルモードと並行モードを交互に実行する
包括的なメトリクスを記録する：レイテンシ分布（P99を含む）、持続QPS、リコール精度
データ量とシステム負荷が増加するにつれて、時間経過に伴うパフォーマンスの推移を追跡する
この制御された段階的な負荷テストにより、継続的な取り込み下でシステムがどれだけ安定性と精度を維持できるかが明らかになります。これは従来のベンチマークではほとんど捉えられないものです。
例：Cohere 10Mストリーミングテストでは、PineconeはElasticsearchと比較して、書き込みサイクル全体を通じてより高いQPSとリコールを維持しました。特に、Pineconeのパフォーマンスは取り込み完了後に大幅に向上し、持続的な負荷下での高い安定性を示しました。一方、Elasticsearchはアクティブな取り込み段階でより不規則な挙動を示しました。
図：Cohere 10Mストリーミングテスト（取り込みレート500行/秒）におけるPineconeとElasticsearchのQPSおよびリコール。
VDBBenchは、オプションの最適化ステップをサポートすることでさらに一歩進み、ユーザーがインデックス最適化の前後でストリーミング検索性能を比較できるようにします。また、各段階に実際に費やされた時間を追跡して報告し、本番環境に近い条件下でのシステム効率と挙動について、より深い洞察を提供します。
図：最適化後のCohere 10MストリーミングテストにおけるPineconeとElasticsearchのQPSおよびRecall（取り込みレート500行/秒）
私たちのテストで示されたように、Elasticsearchはインデックス最適化後にQPSでPineconeを上回りました。しかし、x軸が実際の経過時間を表している場合、Elasticsearchがその性能に到達するまでに大幅に長い時間を要したことは明らかです。本番環境では、その遅延は重要です。この比較は、ピークスループットと提供開始までの時間という重要なトレードオフを明らかにしています。
🔬 現在のAIワークロードを反映する最新データセット
ベクトルデータベースベンチマーキングに使用するデータセットを全面的に刷新しました。SIFTやGloVeのような従来のテストセットではなく、VDBBenchは、今日のAIアプリケーションを支えるOpenAIやCohereなどの最先端の埋め込みモデルから生成されたベクトルを使用します。
特にRetrieval-Augmented Generation（RAG）のようなユースケースでの関連性を確保するため、実世界のエンタープライズおよびドメイン固有のシナリオを反映するコーパスを選択しました。
| コーパス | 埋め込みモデル | 次元数 | サイズ | ユースケース |
|---|---|---|---|---|
| Wikipedia | Cohere V2 | 768 | 1M / 10M | 一般知識ベース |
| BioASQ | Cohere V3 | 1024 | 1M / 10M | ドメイン固有（バイオメディカル） |
| C4 | OpenAI | 1536 | 500K / 5M | Webスケールのテキスト処理 |
| MSMarco V2 | udever-bloom-1b1 | 1536 | 1M / 10M / 138M | 大規模検索 |
これらのデータセットは、今日の大容量・高次元のベクトルデータをより適切にシミュレートし、最新のAIワークロードに合致する条件下で、ストレージ効率、クエリ性能、検索精度の現実的なテストを可能にします。
⚙️ 業界固有のテストに対応するカスタムデータセットサポート
すべてのビジネスは固有です。金融業界ではトランザクション埋め込みに重点を置いたテストが必要かもしれませんし、ソーシャルプラットフォームではユーザー行動ベクトルがより重要になるかもしれません。VDBBenchを使用すると、特定のワークロード向けに特定の埋め込みモデルから生成した独自データでベンチマークを実行できます。
カスタマイズできる項目：
ベクトル次元とデータ型
メタデータスキーマとフィルタリングパターン
データ量と取り込みパターン
本番トラフィックに一致するクエリ分布
結局のところ、自社の本番データほど優れた物語を語るデータセットはありません。
VDBBenchが本番環境で本当に重要なものを測定する方法
本番環境重視のメトリクス設計
VDBBenchは、単なるラボ結果ではなく、実世界の性能を反映するメトリクスを優先します。本番環境で実際に重要なもの、つまり負荷下での信頼性、テールレイテンシ特性、持続的スループット、精度の維持を中心にベンチマーキングを再設計しました。
実際のユーザー体験のためのP95/P99レイテンシ：平均/中央値レイテンシは、実際のユーザーを苛立たせ、潜在的なシステム不安定性を示す可能性がある外れ値を隠してしまいます。VDBBenchはP95/P99のようなテールレイテンシに焦点を当て、クエリの95%または99%が実際に達成する性能を明らかにします。これは、SLA計画と最悪ケースのユーザー体験を理解するうえで極めて重要です。
負荷下での持続可能なスループット：5秒間だけうまく動作するシステムは、本番環境では通用しません。VDBBenchは同時実行数を段階的に増やし、短時間の理想的な条件下でのピーク値ではなく、データベースの最大持続可能クエリ毎秒（
max_qps）を見つけます。この方法論により、システムが時間の経過とともにどれだけ持ちこたえるかが明らかになり、現実的なキャパシティプランニングに役立ちます。リコールと性能のバランス: 精度のない速度には意味がありません。VDBBench のすべての性能数値はリコール測定と対になっているため、スループットのためにどれだけ関連性を犠牲にしているのかを正確に把握できます。これにより、内部のトレードオフが大きく異なるシステム間でも、公平で同一条件の比較が可能になります。
現実を反映したテスト方法論
VDBBench の設計における重要な革新は、シリアルテストと同時実行テストを分離している点です。これにより、システムが異なる種類の負荷下でどのように動作するかを捉え、ユースケースごとに重要となる性能特性を明らかにできます。
レイテンシ測定の分離:
serial_latency_p99は、最小負荷下でのシステム性能を測定します。この場合、一度に処理されるリクエストは 1 つだけです。これはレイテンシのベストケースシナリオを表し、システムのベースライン能力を特定するのに役立ちます。conc_latency_p99は、複数のリクエストが同時に到着し、システムリソースを奪い合う、現実的な高同時実行条件下でのシステム動作を捉えます。
2 段階のベンチマーク構造:
シリアルテスト: 1,000 件のクエリを単一プロセスで実行し、ベースライン性能と精度を確立して、
serial_latency_p99とリコールの両方を報告します。このフェーズは、理論上の性能上限を特定するのに役立ちます。同時実行テスト: 継続的な負荷下の本番環境をシミュレートし、いくつかの重要な革新を備えています:
現実的なクライアントシミュレーション: 各テストプロセスは、独自の接続とクエリセットを持って独立して動作し、結果を歪める可能性のある共有状態の干渉を回避します
同期された開始: すべてのプロセスが同時に開始されるため、測定された QPS が、主張される同時実行レベルを正確に反映します
独立したクエリセット: 本番クエリの多様性を反映しない、非現実的なキャッシュヒット率を防ぎます
これらの慎重に構成された手法により、VDBBench が報告する max_qps と conc_latency_p99 の値は、正確であると同時に本番環境に関連性の高いものとなり、本番環境のキャパシティプランニングやシステム設計に有意義な洞察を提供します。
VDBBench 1.0 を始める
VDBBench 1.0 は、本番環境に関連性のあるベンチマーキングへの根本的な転換を表しています。継続的なデータ書き込み、選択性の異なるメタデータフィルタリング、同時アクセスパターン下でのストリーミング負荷をカバーすることで、現在利用可能な中で実際の本番環境に最も近い近似を提供します。
ベンチマーク結果と実世界の性能のギャップは、推測に頼るべきものではありません。本番環境にベクトルデータベースをデプロイする予定があるなら、理想化されたラボテストを超えて、どのように機能するかを理解する価値があります。VDBBench はオープンソースで透明性があり、有意義で同一条件の比較を支援するように設計されています。
本番価値につながらない見栄えのよい数値に惑わされないでください。VDBBench 1.0 を使用して、あなたのビジネスにとって重要なシナリオを、あなたのデータで、実際のワークロードを反映した条件下でテストしてください。 ベクトルデータベース評価における誤解を招くベンチマークの時代は終わりつつあります。本番環境に関連性のあるデータに基づいて意思決定を行う時です。
自分のワークロードで VDBBench を試す: https://github.com/zilliztech/VectorDBBench
主要なベクトルデータベースのテスト結果を見る: VDBBench Leaderboard
質問がある、または結果を共有したいですか？ GitHub で会話に参加するか、 Discord で私たちのコミュニティとつながってください。
読み続けて
Introducing Customer-Managed Encryption Keys (CMEK) on Zilliz Cloud
We're announcing the general availability of Customer-Managed Encryption Keys (CMEK) on Zilliz Cloud.
Vector Databases vs. Object-Relational Databases
Use a vector database for AI-powered similarity search; use an object-relational database for complex data modeling with both relational integrity and object-oriented features.
How to Use Anthropic MCP Server with Milvus
MCP + Milvus: Streamline AI agent development with standardized data access, eliminating integration hassles while enhancing context and flexibility.