パフォーマンステストと解析

この文書では、Doris ANN IndexのクエリとIngestionのパフォーマンスを紹介します。すべてのベンチマークはVectorDBBenchを使用して実行されています。

単一ノードおよび分散構成での大規模な結果（10M/100Mレベルのデータセット）については、Large-scale Performance Benchmarkを参照してください。

テスト環境

テストで使用されたすべてのマシンは16 CPUコアと64 GBメモリを搭載し、CPUはIntel(R) Xeon(R) Platinum 8369B CPU @ 2.70GHzモデルです。FEとBEは単一の16C64GBマシン上に併設されています（注：これは推奨される本番デプロイメントではありません。本番環境では、FEとBEは別々にデプロイする必要があります）。テストされたバージョンはApache Doris 4.0.2です。使用されたデータセットはVectorDBBench Performance768D1Mで、768次元の100万ベクトルを含んでいます。

結果

performance

分析

                    ┌──────────────────────┐
                    │        Recall        │
                    │  (Higher is Better)  │
                    └──────────▲───────────┘
                               / \
                              /   \
                             /     \
                            /       \
                           /         \
                          /           \
             ┌───────────┘             └───────────┐
             │                                     │
             │                                     │
             ▼                                     ▼
 ┌──────────────────────┐                 ┌────────────────────────┐
 │        Query QPS     │                 │    Indexing Throughput │
 │   (Latency / QPS)    │                 │    (Higher is Better)  │
 │ (Lower Latency Better)│                │                         │
 └──────────────────────┘                 └────────────────────────┘

ベクター検索において、本番環境対応のベクターデータベースは通常、すべての次元で同時に最大化することが困難なパフォーマンスの「三角形」に直面します：クエリパフォーマンス（QPS/レイテンシ）、再現率、およびインデックス処理スループット。システム設計では、これら3つの間でトレードオフが必要になることが多くあります。

最も広く使用されているベクターインデックスであるHNSW（Hierarchical Navigable Small World）を例に取ります。これは検索を最適化するためにグラフ構造に依存しています。HNSWには3つの主要な調整可能なハイパーパラメータがあります：

max_degree：グラフ内の各ノードの最大出次数で、グラフの密度と接続性を決定します。
ef_construction：インデックス構築時に使用される候補セットサイズ。一般的に、より大きな値はより高品質なグラフを生成します。
hnsw_ef_search：クエリ時の探索ウィンドウサイズで、再現率とレイテンシに直接影響します。

原理的には、インデックス構築時にmax_degreeとef_constructionを増加させることで、グラフの接続性とナビゲート可能性を大幅に改善でき、より高い再現率をもたらします。より高品質なグラフは、クエリ時により小さなhnsw_ef_searchを可能にし、検索コストを削減してクエリパフォーマンスを向上させます。しかし、これらのインデックス構築パラメータの増加にはトレードオフが伴います：インデックス構築により多くの計算とメモリリソースが必要になり、取り込みパフォーマンスの低下につながります。これがベクターデータベース設計における典型的な三すくみです。

Apache Dorisはベクター検索のためのよりバランスの取れたパフォーマンス三角形の構築を目指しています。実行エンジンの最適化、ストレージ形式の改善、およびHNSW構築のエンジニアリングレベルでの並列高速化を通じて、Dorisはインデックス品質や高い再現率を犠牲にすることなく、全体的なインデックス処理スループットを大幅に改善します。

Performance768D1Mデータセットでは、同等のインデックス品質の下で、Apache Dorisが他のシステムと比較して著しく優れた取り込みパフォーマンスを示すことが結果に表れています。さらに重要なことに、Dorisは取り込み速度を得るためにグラフ品質を妥協しません。我々のテストでは、Apache Dorisは97%以上の再現率を維持しながら989.1のQPSを達成し、パフォーマンス三角形のすべての3つの次元にわたって強力なバランスを実現しています。

再現

NUM_PER_BATCH=500000 vectordbbench doris --host 127.0.0.1 --port 9030 --http-port 8030 --case-type Performance768D1M --db-name vdb --num-concurrency 80 --stream-load-rows-per-batch 500000 --index-prop max_degree=128,ef_construction=256 --session-var hnsw_ef_search=100

テスト環境​

結果​

分析​

再現​

テスト環境

結果

分析

再現