ベクトルデータベースのベンチマーク、ビルド時間と同時実行性で大きな差が判明

Perconaは、6つのデータベースエンジンにおけるベクトル検索パフォーマンスを比較する厳格なベンチマークを発表し、インデックス作成速度、メモリ使用量、および同時実行処理能力における顕著な差異を浮き彫りにしました。この研究では、MariaDB、AliSQL、pgvector付きPostgreSQL、Valkey、そしてMongoDB用Percona Searchを、990,000件のOpenAI埋め込みデータコーパスを用いて評価しました。結果は、あるエンジンが迅速なインデックス構築に優れる一方で、他のエンジンが優れたストレージ効率や高並行スループットを提供することを示しており、検索拡張生成（RAG）システムを設計するエンジニアにとって重要なデータとなっています。

何が起きたか

ベンチマークでは、各エンジンに1,536次元のベクトル990,000件を読み込み、HNSWインデックスを構築した後、以下の5つの主要指標を測定しました：クエリ可能なインデックス作成までの時間、ストレージおよびメモリのフットプリント、再現率対スループット、同時クライアント下でのパフォーマンス、およびデータ変更時の挙動です。すべてのテストは、Intel Xeon Gold 6230サーバー（80論理CPU、187.5 GB RAM）という同一ハードウェア上で実行され、公平な比較を保証しました。オーケストレーターは、42.3 GBのInnoDBバッファプールやグラフキャッシュ用の特定のメモリ割り当てなど、一貫したリソース制限を適用し、設定によるバイアスを防ぎました。

結果には、基本的な操作における予期せぬ変動が見られました。クエリ可能なインデックスの構築時間は、Percona Searchのわずか1.9分から、AliSQLの6.7時間まで幅がありました。ストレージ効率も大きく異なり、MariaDBは最小の3.9 GiBのインデックスを生成した一方、Percona Searchは15.1 GiBを必要としました。注目すべきは、最も小さいインデックスを持つエンジンが、それを構築するのに最も長い時間を要したことで、これは圧縮と構築速度の間にある一般的なトレードオフを示しています。これらの発見は、ベクトルデータベースの選択には、再インデックス頻度などの即時の運用ニーズと、長期的なストレージコストとのバランスが必要であることを示唆しています。

同時実行性のテストでは、さらなる違いが明らかになりました。32人の同時クライアントによる負荷下で、pgvector付きPostgreSQLのスループットは単一クライアントのパフォーマンスと比較して21.7倍にスケールしました。対照的に、3つのInnoDBベースのエンジン（MariaDB 11.8、MariaDB 12.3、AliSQL）はほとんどスケールせず、約1倍のスループットを維持しました。しかし、ベンチマークチームは、テストハーネスの制限を発見した後、これら3つのエンジンの具体的な同時実行効率の数値を撤回しました。MariaDB Connector/Cはソケット待機中にPythonインタープリターロックを保持していたため、一部のクライアントはデータベースではなくロックを待っていたことになり、「サービス中」メトリクスが歪んでいました。

仕組み

ベンチマークでは、dbpedia-openai-1000k-angularデータセットを使用し、これは990,000個のfloat32ベクトルで構成されています。各エンジンは、グラフ構造の接続性を制御する標準パラメータであるM=16でHNSWインデックスを構築しました。クエリパフォーマンスは、検索中に探索される候補数を決定する異なるef_search値を使用して測定されました。再現率は、ann-benchmarksからの距離閾値定義を用いて計算され、既存の文献との比較可能性を確保しました。フィルタ付きクエリの場合、正解データは述語を満たす行のみに対して総当たり法で再計算され、一致しない項目を正しく除外したためにエンジンがペナルティを受けることを防ぎました。

異なるエンジンは、フィルタ付き検索に対して独自の戦略を採用しています。pgvector付きPostgreSQLは、グラフから候補を集めた後、述語を満たさないものを破棄するポストフィルタ方式を使用します。あまりにも多くの候補が破棄された場合、早期に停止し、要求された数よりも少ない結果を返す可能性があります。Percona Searchはプレフィルタ戦略を使用しており、フィルタが厳密になるにつれてより高いスループットを維持できますが、再現率を犠牲にする場合があります。MariaDBとAliSQLもポストフィルタを行いますが、検索を継続するため、再現率は保たれますが、フィルタの選択性が低下するとレイテンシが大幅に増加する可能性があります。これらのアーキテクチャ上の選択は、メタデータフィルタを含む複雑な実世界のクエリを各エンジンがどの程度うまく処理できるかに直接影響を与えます。

主要な詳細

• インデックス構築時間: Percona Searchが1.9分で最速、AliSQLが6.7時間で最遅でした。
• ストレージ効率: MariaDB 11.8および12.3は3.9 GiBの最小インデックスを生成し、Percona Searchの15.1 GiBと比較されました。
• 単一クライアントスループット: 再現率0.99において、MariaDB 12.3が277 QPSでリードし、Valkeyが264 QPS、PostgreSQLが210 QPSで続きました。
• 同時実行スケーリング: PostgreSQLのスループットは32クライアントで21.7倍増加しましたが、InnoDBベースのエンジンはサーバー側のキューイングにより最小限のスケールしか見せませんでした。
• フィルタ付き検索: PostgreSQLのデフォルトのポストフィルタ方式は、非一致候補を破棄した後に早期停止するため、選択性1%で再現率が0.1034まで低下しました。
• データ変更: MHNSWおよびVIDXは挿入ごとにグラフを更新するため、ロード時間はインデックス構築時間と同等になります。これはコピーと構築を分離するpgvectorとは異なります。

なぜ重要なのか

AIアプリケーションを開発するソフトウェアエンジニアにとって、これらのベンチマークは、どの単一のエンジンもすべてのカテゴリーで支配的ではないことを強調しています。アプリケーションが頻繁な再インデックスやモデル更新を必要とする場合、PostgreSQLの40分の構築時間とAliSQLの6.7時間のウィンドウの違いは、運用上重大です。逆に、ストレージコストが主な制約である場合、MariaDBのコンパクトな3.9 GiBインデックスは、構築プロセスが遅いにもかかわらず、他のオプションと比較して大幅な節約を提供します。これらのトレードオフを理解することは、書き込み速度、読み取りスループット、またはストレージ密度のいずれを優先するかに関わらず、特定のワークロードパターンに一致するインフラストラクチャを選択するのに役立ちます。

同時実行の結果は、トラフィックの多いサービスにとって特に重要です。PostgreSQLとValkeyがクライアント数に応じて線形にスループットをスケールさせる能力は、多数の同時ユーザーがいる環境により適していることを示唆しています。同時負荷下でのInnoDBベースのエンジンの平坦なパフォーマンスは、現在のベクトル実装またはコネクタライブラリにおける潜在的なボトルネックを示しています。エンジニアは、システムアーキテクチャを設計する際にこれらのスケーリング特性を考慮する必要があり、ネイティブにうまくスケールしないエンジンに対しては、追加の負荷分散やコネクションプーリング戦略が必要になる可能性があります。

あなたができること

• 再インデックス頻度を評価してください。埋め込みを頻繁に更新する場合、PostgreSQLやValkeyのような構築時間が速いエンジンを優先してください。
• 特定のメタデータ分布でフィルタ付き検索のパフォーマンスをテストしてください。デフォルトの設定では、再現率が低くなったり、レイテンシが高くなったりする可能性があります。
• ストレージコストと構築時間を比較検討してください。ディスクスペースが高価な場合、MariaDBの小さいインデックスは、長い構築ウィンドウを正当化するかもしれません。
• 予想されるユーザー負荷に対する同時実行性をベンチマークしてください。一部のエンジンは、並列クエリを効果的に処理するためにインスタンスを増やす必要があるかもしれないことに注意してください。
• 言語固有クライアントのコネクタライブラリを確認してください。本研究のハーネス制限は、ドライバーレベルのボトルネックがデータベースパフォーマンスを隠蔽する可能性があることを示唆しています。
• インデックス構築中のメモリ使用量を監視してください。ピークRSSは14.3 GBから48.8 GBまで変動し、インフラプロビジョニング要件に影響を与えるためです。