ベクトルDB検索速度

計算式と考え方

索引のメモリは「件数 × 次元数 × 4バイト × 方式の係数」で求めます。1,000万件・1,536次元では生データが61.44GB、HNSWはグラフ構造の分を1.5倍として92.2GBです。応答時間は件数の対数に比例し、探索パラメータと次元数で増えます。2シャードに分けた1シャードあたり500万件では中央値が約8.7ms、テールを2.6倍としてP99は約22.6msになります。1ノードあたりの処理能力は約460クエリ/秒です。1シャードあたり46.08GBに対しメモリ64GBの75%を使えるとすると1台で収まり、2シャード×レプリカ2で4台という構成になります。探索パラメータ128での再現率は約98.4%です。

索引方式の特徴

ベクトルDB検索速度の詳しい解説

ベクトル検索の応答時間は、件数そのものより索引の方式で決まります。グラフ型の索引は、近いベクトル同士をつないだ多層のグラフをたどって候補を絞るため、件数が増えても探索の手数は対数的にしか増えません。1,000万件でも1億件でも、応答時間の差は数倍にとどまります。一方、総当たりの方式は全件との距離を計算するため、件数に比例して時間がかかります。数万件までなら総当たりでも実用的な速度が出ますが、数百万件を超えると対話的な用途には使えません。メモリの消費量は、方式による差がさらに大きくなります。1,536次元のベクトルを4バイトの浮動小数点で持つと、1件あたり6KB強になります。1,000万件では生データだけで60GBを超え、グラフ型の索引ではさらに5割程度が上乗せされます。量子化を使う方式では、ベクトルを圧縮して保持するためメモリを10分の1以下に減らせますが、圧縮によって距離の計算に誤差が生じ、再現率が下がります。メモリのコストと再現率のどちらを優先するかは、用途によって判断が分かれます。検索結果を人が確認する用途では多少の取りこぼしが許容されますが、判断の根拠として使う場合は再現率を優先することになります。探索パラメータの調整は、実務で最も頻繁に触れる部分です。この値を大きくすると、探索の際に保持する候補の数が増えて再現率が上がりますが、その分だけ計算量が増えて応答時間が伸びます。両者は連続的なつり合いの関係にあり、どこで折り合うかは要件次第です。実際の運用では、自分のデータで再現率を測定してから決めるのが確実です。公表されている性能値は標準的なデータセットで測られたもので、次元数やベクトルの分布が違えば結果も変わります。特に、埋め込みモデルによってベクトルの分布の性質が異なり、同じ設定でも再現率に差が出ます。分散の設計にも考え方の分岐があります。シャードに分割すると1シャードあたりの件数が減って探索が速くなりますが、全シャードに問い合わせて結果を統合する必要があるため、統合の処理と、最も遅いシャードを待つ時間が加わります。シャード数を増やしすぎると、この待ち時間が支配的になって速くならなくなります。レプリカは処理能力と可用性のために増やしますが、メモリの消費量はレプリカ数に比例するため、コストが直線的に増えます。P99という指標を見る理由は、平均値では利用者の体感を捉えられないためです。100回に1回の遅い応答が、実際には最も印象に残ります。テールが伸びる原因は、ガベージコレクション、メモリのページング、シャード間の待ち合わせ、隣接するプロセスとの資源の競合など複数あり、平均値の改善とは別の対処が必要になります。

業界・現場での使い方

よくある間違い・注意点

• 公表された性能値をそのまま前提にする — 次元数やベクトルの分布で結果が変わります。自分のデータで測定してから設定を決めてください。
• 平均の応答時間だけを見る — 体感を左右するのはテールです。P99が要件に収まっているかで判断する必要があります。
• 索引の更新による劣化を見込まない — 削除と更新が積み重なると再現率と速度が落ちます。定期的な再構築を計画に入れてください。

関連する規格・法規

• ML業界標準
• 各種論文

※本ツールは公的基準に基づく参考計算です。実際の設計・施工・法令適用は最新の告示・規格および所轄官庁の判断に従ってください。

よくある質問（FAQ）

関連計算ツール