ベンチマーク結果の乖離を解明する：Milvus対Qdrant
GenAIの人気上昇に伴い、市場に参入するベクターデータベースの数が増加している。昨年初め、私たちはVectorDB Benchを導入し、新たなベクターデータベース技術の性能に関する洞察を提供しました。
最近、この分野に深く投資している開発者たちが、Qdrantのベンチマーク結果とVectorDB Benchで得られた知見との間に大きな相違があることを理解したいと、Zillizに接触してきました。特に、Qdrantのベンチマーク結果におけるMilvusのプール性能について明確にする必要があるとのことでした。このような問い合わせを受け、Zillizのエンジニアリングチームは、これらの不一致の根本原因を明らかにするために包括的な調査を開始しました。
このブログ記事では、Milvusの性能の違いに特に注目し、ベンチマークの違いを技術的に詳細に分析します。さっそく、この調査の詳細を掘り下げてみよう。
理由その1：古いMilvusのバージョン
ベンチマーク結果の相違は、主にテストに使用されたMilvusのバージョンが異なることに起因しています。2022年8月10日に発表されたMilvus v2.1に基づくQdrantベンチマークレポートは、それ以降のバージョンで行われた大幅な進化を完全には捉えていません。このレポートの生データをご覧ください。それ以来、Milvusはかなりの機能強化を受けている。
Milvusv2.2.1では、ベクトルエンジン(Knowhereとしても知られる)をアップグレードし、並列化戦略を見直しました。その後のv2.2.3の更新により、検索性能はさらに向上しました。我々のホワイトペーパーでは、Milvus 2.2.3がクエリ性能(レイテンシとスループット)とスケーラビリティ(10億スケールのコレクションとマルチレプリカ)においてMilvus 2.0の_4倍速い*ことを実証し、これらの進歩を強調しています。
これに続き、v2.2.9ではフィルタリング検索のパフォーマンスが改善された。v2.2.12](https://milvus.io/docs/v2.2.x/release_notes.md#2212)では、大きなtop-K値に対するオーバーヘッドを最小限に抑えた検索効率の向上、パーティションキー有効またはマルチパーティションシナリオでの書き込み性能の向上、大規模マシンでのCPU使用率の最適化を導入した。さらに、v2.3.2では、ロード中のデータコピーを最小化し、一括挿入を改善することで、大幅な性能向上を実現した。
このような継続的な機能強化により、Milvusの機能は大幅に変化した。その結果、Milvus 2.1に基づくベンチマークは、もはやこの技術の現在の性能を正確に反映していない。Milvusの最新機能をより良く理解するために、開発者はテストにMilvus 2.3を採用したVectorDB Benchを参照することを推奨します。
理由その2: Milvusの不適切な使用
Milvusの性能に関するQdrantのベンチマークは、Growing Segmentsのみを使用したことに一部起因しています。その名前が示すように、Milvusは2つのsegmentタイプで最適化します：Growing SegmentsとSealed Segmentsである。Growing Segmentsは、あらかじめ定義された閾値に達するまでデータを受信し続ける。これらのセグメントは高速なデータ入力を優先し、ブルートフォースサーチ戦略を利用するため、クエリのパフォーマンスが低下します。
一方、Sealing Segmentsはデータを受信しなくなるため、インデックスを持ち、パフォーマンスが大幅に向上する。Milvusは、事前に定義された閾値に達すると、グローイングセグメントを自動的に封印するため、このデータもインデックスと一緒に使用することでパフォーマンスが向上します。
Qdrantベンチマークでは、グローイングセグメントの使用のみに焦点をあてていたため、当然のことながらパフォーマンスの低下が報告されました。Growing Segmentsだけに集中することは、Milvusが実際のアプリケーションでどのように使用されているかとは異なり、Milvusに含まれるセグメント戦略の目的を失うことになる。
さらに、データの鮮度と検索効率のバランスを取るために、Milvus v2.3ではグローイングインデックスに対するIVF-FLATインデックスのサポートが導入された。 さらに、Milvus v2.3.4では、グローイングセグメント用のBinlogインデックスが導入されました。この更新により、これらのセグメントでIVFやFast Scanのような高度なインデックスを使用できるようになり、検索性能が最大10倍向上する可能性があります。その結果、この機能改善により、以前のQdrantベンチマークの結果はさらに意味をなさなくなりました。
理由その3：Qdrantのベンチマーク主導の最適化
Qdrantの他ベンダーに対する卓越したベンチマーク性能は、ベンチマークにsuper-large segmentsを使用していることに起因しています。この戦略はベンチマークでは注目すべき結果をもたらしましたが、実世界での適用性には疑問が残ります。ベクトルデータベースでは、セグメントのサイズが非常に重要です。Qdrantは大きなセグメントに重点を置くことで、ベンチマークのスコアを向上させたが、日常的な使用においては運用の柔軟性を損なう可能性がある。
効果的なベクターデータベースは、多様なワークロードと進化するデータ要件に対応しなければならない。超大規模セグメントは、ベンチマークでは効果的ですが、実世界で典型的な多様なクエリに対応するのに苦労するかもしれません。また、管理に複雑さをもたらし、リソースの需要を増大させる可能性がある。
Qdrantのベンチマークに基づく最適化は、超大容量セグメントと同様、素晴らしいパフォーマンスを示す一方で、ダイナミックな実環境での実用性には懸念があります。これは、実際のベクトルデータベースの展開において、このようなベンチマーク結果の全体的な妥当性に疑問を投げかけるものです。
終わりに：公平で十分な情報に基づいた意思決定への道
ベクターデータベースに関しては、信頼できる包括的なベンチマークが不可欠です。Zillizによって構築されたVectorDB Benchは、開発者のために実世界のパフォーマンスデータを提供しています。ベンチマークにおいて絶対的な公平性を達成することの難しさを認識しつつ、私たちはこの領域における集合的な知識を豊かにするために私たちの洞察を共有します。
ANN Benchmark](https://ann-benchmarks.com/)は、公平な評価を求める人々にとって貴重なツールであり、ベクトル・データベースの標準化された評価を提供する。この分野の技術が進歩するにつれて、我々は明確で透明性が高く、協力的なベンチマークの取り組みの必要性を強調する。開発者はベクターデータベースを選択する際、十分な情報に基づいた決定を下すために、真実で正確なベンチマークにアクセスするか、自分のデータに対して独自のテストを行う必要があります。
読み続けて
Introducing Functions and Model Inference on Zilliz Cloud: Automatic Embedding and Reranking with Hosted Models
Zilliz Cloud Functions auto-generate embeddings via OpenAI, Voyage AI, Cohere, or Zilliz Hosted Models. Built-in reranking — just insert text and search.
3 Easiest Ways to Use Claude Code on Your Mobile Phone
Run Claude Code from your phone with Remote Control, Happy Coder, or SSH + Tailscale. Comparison table, setup steps, and tools for typing, memory, and parallel tasks.
Smarter Autoscaling in Zilliz Cloud: Always Optimized for Every Workload
With the latest upgrade, Zilliz Cloud introduces smarter autoscaling—a fully automated, more streamlined, elastic resource management system.