pgvector の強化: AlloyDB で HNSW ベクトル検索が 4 倍高速化

※この投稿は米国時間 2026 年 7 月 22 日に、Google Cloud blog に投稿されたものの抄訳です。

AlloyDB は、特に要求の厳しいエンタープライズ ワークロード向けに構築された PostgreSQL 互換のフルマネージド データベース サービスです。オープンソースの PostgreSQL の優れた機能と Google の高度なテクノロジーを組み合わせることで、大規模なスケーラビリティ、高可用性、ネイティブ AI 機能を提供します。高性能なリレーショナル ストア、ベクトル検索と全文検索の統合バックエンド、標準の PostgreSQL より最大 100 倍高速な分析エンジンとして機能します。

ベクトル検索は、最新の AI アプリケーションと検索拡張生成（RAG）アプリケーションの基盤です。AlloyDB やその他の PostgreSQL データベースを使用する開発者にとって、pgvector はベクトル エンベディングの保存、インデックス作成、クエリに広く採用されている拡張機能であり、HNSW（Hierarchical Navigable Small World）は、多層構造にわたる近似最近傍探索用に設計された、非常に効率的なグラフベースのアルゴリズムです。AlloyDB のカラム型エンジンで高速化された HNSW（現在プレビュー版）を使用すると、標準の PostgreSQL HNSW と比較して、ベクトル検索の秒間クエリ数（QPS）を最大 4 倍に向上させることができます。

エンタープライズ AI アプリケーションは、常にスピードと精度のトレードオフに直面しています。数百万または数十億のベクトルを検索する場合、検索品質（再現率）を損なうことなく秒間クエリ数（QPS）を最大化することは、本番環境ワークロードをスケールするうえで非常に重要です。PostgreSQL の pgvector 拡張機能は、近似最近傍（ANN）検索を高速化できるインデックスの一つとして HNSW を提供します。AlloyDB が速度と精度のトレードオフをどのように解決するのかを詳しく見ていきましょう。

注: この投稿では HNSW のパフォーマンスに焦点を当てていますが、HNSW は AlloyDB の高度なベクトル ツールキットの一部にすぎません。AlloyDB には、14 年以上にわたる Google Research の成果に裏打ちされた最先端のインデックスである ScaNN も搭載されており、ワークロードに最適なインデックスを柔軟に選択できます。さらに、絶対的な精度が求められるユースケースでは、標準の k 近傍法（KNN）検索をいつでも利用して 100% の再現率を確保できます。各インデックスの比較については、ベクトル インデックスの選択ガイドをご覧ください。

まず、AlloyDB カラム型エンジンとは？

AlloyDB カラム型エンジンは組み込みのインメモリ キャッシュで、頻繁にクエリされるデータを、スキャンに最適化された特殊なカラム型形式で自動的に保存します。これにより、AlloyDB は標準の PostgreSQL よりも最大 100 倍高速に大量の分析クエリを処理できます。さらに、インデックスをメモリに保存し、高速な走査のためにベクトル化されたメモリ レイアウトを使用し、標準の PostgreSQL バッファ マネージャーのオーバーヘッドをバイパスすることで、ANN 検索を高速化します。

パフォーマンスの可視化

カラム型エンジンで高速化された HNSW の実際のパフォーマンス特性を把握するために、100 件の制限で 100 万件以上のレコードを検索して、GloVe 100 Angular データセットの標準 QPS と再現率の曲線を作成しました。

このベンチマーク スクリプトを実行すると、次のようなグラフが得られます。

このデータから、2 つの変革的なメリットが明らかになりました。

1. パフォーマンス スループットが大幅に向上: 任意の目標再現率（0.95 など）に対して、QPS が約 4.2～4.9 倍に増加します。これにより、同じハードウェアで同時に処理できるベクトル検索の数が大幅に増加します。

2. 再現率（精度）が大幅に向上: 逆に、QPS レベルが一定の場合、カラム型エンジンで高速化された HNSW は再現率を大幅に向上させます。たとえば、上述のグラフでは、約 350 QPS の時点で、カラム型エンジンを有効にすると、再現率が約 0.78 から 0.94 超へと向上し、0.163 の再現率の向上が見られました。つまり、AI アプリケーションはレイテンシの影響を受けることなく、より正確な結果を得られます。

特筆すべきは、ベースライン（青い線）は、インデックスが PostgreSQL の共有バッファ キャッシュに完全に保存されている状態をすでに示しているという点です。ここで示されているパフォーマンスの向上は、単にデータをディスクから RAM に移動した結果ではなく、より効率的なメモリ アーキテクチャを採用した結果です。

仕組み: カラム型エンジンで高速化された HNSW

標準的な PostgreSQL アーキテクチャでは、インデックス オペレーションで共有バッファ キャッシュが使用されます。データが完全にメモリ内にある場合でも、データベースはバッファ マネージャーから大きなオーバーヘッドを発生させます。バッファ マネージャーは、ページの固定と固定解除、ロックの取得、バッファ テーブルのルックアップ、LRU（Least Recently Used）管理などのオペレーションを処理する必要があります。

AlloyDB のカラム型エンジンは、スキャン用に最適化された特殊な形式でデータを保存する、組み込みのインメモリ キャッシュです。

このリリースにより、AlloyDB はカラム型エンジンで高速化された HNSW を使用して、以下の処理を行うことができます。

• インデックスの固定: pgvector HNSW インデックスは、カラム型エンジンのメモリに直接固定（高速アクセスを確保するためにメモリ内に永続的に保持）されます。

• ベクトル化されたアクセス: HNSW グラフに必要な、同時実行性が高くポインタを多用する走査向けに特別に設計されたメモリ レイアウトを利用します。

• バッファのオーバーヘッド回避: AlloyDB は、専用のメモリ空間でグラフをナビゲートすることで、標準のバッファ マネージャーのボトルネックを回避します。このアーキテクチャの移行により、完全にキャッシュされた標準インデックスと比較した場合でも、上述のような QPS と再現率の大幅な改善が可能になります。

これが重要である理由

エンタープライズ規模のアプリケーションの場合、これは単にデータベースが高速になるだけでなく、費用と品質にも影響します。

• インフラストラクチャ費用の削減: コンピューティング リソースを大幅に削減しながら、同じパフォーマンスを実現できます。

• AI の精度向上: 以前は「ドラフト」（高速、低精度の結果）品質の検索でしか実現できなかった速度で、より高い再現率と品質を実現できます。

• アプリケーションの変更は不要: これは AlloyDB に組み込まれているため、同じ標準の pgvector SQL 構文を使用してこれらのメリットを得られます。

カラム型エンジンはメモリを使用しますが、高度に圧縮され、緻密に管理されています。エンジンはベクトルデータを効率的なカラム形式で保存するため、メモリ使用量はパフォーマンスの大幅な向上に比べて最小限に抑えられます。これは、エンタープライズ ワークロードにとって非常に有利なトレードオフです。

クイック スタートガイド

AlloyDB でカラム型エンジンで高速化された HNSW を試すには、次の手順を行います。

1. インデックス キャッシュとカラム型エンジンを有効にする

AlloyDB インスタンスで google_columnar_engine.enabled フラグと google_columnar_engine.enable_index_caching フラグの両方が on に設定されていることを確認します。

2. HNSW インデックスをカラム型エンジンに追加する

pgvector を使用して HNSW インデックスを作成したら、次の SQL コマンドを実行してカラム型エンジンにキャッシュ保存します。

3. 参考情報

• AlloyDB をまだご利用でない場合は、30 日間の無料トライアルで AlloyDB をお試しください。

• Google Colab ノートブック: GloVe データセットの取り込み、インデックスの作成、再現率と QPS の曲線のプロットを行うエンドツーエンドの Python スクリプト。

• HNSW は貴社のユースケースに最適なベクトル インデックスでしょうか？「AlloyDB AI でベクトル インデックスを選択する」ガイドをご覧ください。

- シニア ソフトウェア エンジニア、Vinay Sharma

- グループ プロダクト マネージャー、Darshana Sivakumar