Lakebase Search：Postgres向けの最先端の全文検索とベクトル検索

従来のOLTPシステムは、AIエージェントの検索需要向けに構築されていません。すべてのデータにわたる低レイテンシで高精度な検索が必要であり、多くの場合、大規模な並列検索が実行されます。これまでは、この課題を解決するために、ETLパイプラインを使ってスタンドアロンの検索エンジンをプライマリデータベースに無理やり連結する必要がありました。

しかし、もしOLTPデータベースが検索ワークロードを効率的に実行できるとしたらどうでしょうか？

本日、私たちは2つの拡張機能、lakebase_vector（スケーラブルな近似近傍探索）とlakebase_text（BM25全文検索）を通じて、高速でスケーラブルな検索エンジンをLakebase Postgresに導入します。両方の拡張機能は、AWSおよびAzureで一般提供（GA）されています。

lakebase_vectorにより、Postgresはベクトル検索の最前線に立ちました。専用の検索エンジンの効率性とスケーラビリティを凌駕します。VectorDBBench 100Mベンチマークにおいて、次点に位置するシステムの2倍のスループットを達成し、pgvectorを使用するクラウドPostgresベンダーと比較して4倍低コストです。しかも、これはオートスケーリングによる追加のコスト削減を考慮する前の数値です。

このパフォーマンスは、精度を犠牲にすることなく維持されます。私たちのテストでは、lakebase_vectorは97%の再現率（97%の確率で真の最近傍を正しく取得）において、71ミリ秒のP99レイテンシを達成しました。

 

Lakebase Postgresは最先端の検索機能を備えるようになり、Conexiomのようなお客様は、従来のpgvector構成の半分のコンピューティングフットプリントで、1億行を超えるデータに対してBM25によるハイブリッド検索を実行しています。同社は現在、すべてのOLTPおよび検索ワークロードに対応し、完全にサーバーレスでニーズに合わせてスケールするデータベースを手に入れています。

Lakebase Searchは、pgvectorを遥かに凌駕するまったく新しい次元のスケーラビリティをもたらし、同じサーバーレスデータベース内でBM25を利用可能にします。私たちはLakebaseを使用して、データをエージェントに大規模に接続しています。 —Jordan Voves氏（Conexiom社 AI/MLアーキテクト）

大規模環境でpgvectorが限界に達する理由

ほとんどのPostgresユーザーにとって、検索はpgvectorから始まります。これにより、別のベクトルストアを使用する複雑さを回避し、Postgres内のデータに対してネイティブにHNSWやIVFFlatなどのインデックスアルゴリズムを介したベクトル類似性検索が可能になります。実際、pgvectorはLakebase Postgresで最もインストールされている拡張機能です。私たちは、pgvectorを大規模に運用しているお客様から、3つの共通するペインポイントを伺いました。

1. コストは使用量ではなく、データ量に応じてスケールする

pgvectorは高速化のためにインデックスをデータベースのメモリ上に保持します。HNSW検索はランダムアクセスのグラフ探索に依存しているため、すべてがRAMに完全に収まっている場合にのみ、クエリはミリ秒単位で実行されます。インデックスがディスクに溢れた瞬間、クエリはランダムリードの連鎖へと変わり、パフォーマンスは10分の1から50分の1に急落します。

768次元のfloat32ベクトルは、グラフのリンクとPostgresのオーバーヘッドを考慮すると、約3.3 KBのメモリを必要とします。1億行の場合、ミリ秒単位のクエリのためにインデックスを常駐させるには、約330 GB of RAMが必要です。「ワーキングセット」という概念はありません。インデックスのすべてをクエリするか、まったくクエリしないかにかかわらず、インデックス全体に対してプロビジョニングを行う必要があります。

2. インデックスのメンテナンスコストが高く、データベースをブロックする

HNSWグラフは継続的なランダムアクセスに依存しているため、pgvectorインデックスはメモリによって制限されます。ビルドがディスクに溢れると、数百万ものランダムI/O操作によってパフォーマンスが低下します。標準的なクラウドインスタンスでpgvectorインデックスを構築するのに、ほぼ50時間かかります。

データの取り込み（インジェスチョン）も同様のボトルネックに悩まされます。書き込みのたびに、pgvectorはランダムアクセスルックアップを使用してグラフの複数のレイヤーを探索および変更する必要があるため、新しいベクトルの挿入は遅く、コストがかかります。

第二に、HNSWは継続的なランダムアクセスのグラフナビゲーションに依存しているため、取り込みが遅く、コストが高くなります。また、グラフの各レイヤーを変更する必要もあります。そのため、HNSWインデックスは

継続的なメンテナンスがこの問題をさらに悪化させます。HNSWにはグローバルな再バランシング機能がないため、検索品質を回復するには完全なREINDEXが必要になり、これによりテーブルがロックされ、本番環境の書き込みがブロックされます。

3. 検索品質とパフォーマンスのトレードオフが発生する

各pgvectorクエリは単一のPostgresバックエンドプロセスで実行されるため、HNSWインデックススキャンが並列化されることはありません。

より高い再現率を得るには、エンジンがより多くのグラフノードを探索する必要があり、その結果、ランダムなメモリ読み取りと距離比較が増加します。これによりレイテンシが増大し、QPSが低下します。単一の検索をコア間で並列化することはできないため、スループットを向上させるための唯一の選択肢は、接続数またはリードレプリカを増やすことです。

lakebase_vectorがPostgresにスケーラブルなベクトル検索をもたらす

pgvectorの主なボトルネックは、高速化のためにインデックス全体を単一マシンのRAMに収める必要がある点です。もしその必要がなかったらどうでしょうか？

Lakebase Postgresは、ストレージとコンピューティングを分離しているため、優れた出発点を提供します。高耐久性データは安価なクラウドオブジェクトストレージに保存され、RAMとローカルNVMeは、データのワーキングセットを高速に読み取るためのエフェメラルキャッシュとして機能します。このアーキテクチャでは、HNSWキャッシュは一連のランダムなオブジェクトストア読み取りを意味します。

RAMにキャッシュされているときも、オブジェクトストレージ上でコールドな状態のときも高速なインデックスが必要です。私たちは2つのアイデアを活用しています。

• 階層型IVFクラスタリング。ベクトルは連続したブロックとして保存されるクラスターにグループ化されます。クエリはメモリ内のクラスターのセントロイド（重心）をスコアリングし、有望な少数のブロックのみを読み取ります。これにより、何百回ものランダムホップが、数回の大きなシーケンシャルリードに変換されます。
• バイナリ量子化（RaBitQ）。各ベクトルは1次元あたり約1ビットに圧縮され、float32よりも約32倍小さくなります。クエリはコンパクトなコードをスキャンして候補を絞り込み、その限定された候補リストをフル精度のベクトルに対して再ランク付け（リランク）します。

キャッシュされている場合、検索は量子化されたベクトルを使用して非常に小さなフットプリントで動作します。コールドな状態の場合、クエリは必要なブロックのみを取得し、インデックス全体をクロールする必要はありません。lakebase_vectorは以下を提供します。

使用した分だけ支払い、ゼロにスケール

ストレージとコンピューティングを分離することで、lakebase_vectorは完全にステートレスになります。ノードは必要に応じてホットデータをキャッシュし、アイドル時にはゼロにサスペンド（一時停止）し、次のクエリで再開します。

• 静止状態（アットレスト）ではストレージ料金のみが発生するため、Lakebaseでベクトルをインデックス化して保持するための基本コストを低く抑えることができます。
• コールドスタートは安価です。量子化されたコードと、クエリがアクセスする特定のブロックのみがハイドレート（有効化）されるためです。ゼロスケール後の最初のクエリに対して測定されたP90レイテンシは、わずか1.13秒（1億行 × 768次元）です。
• わずか1つのLakebase Compute Unit（CU）で1億個のベクトルを提供することさえ可能です。アクティブなワーキングデータセットのみをコンピューティングノードにキャッシュすればよいため、実際の使用状況やクエリのアクティビティを忠実に反映した料金モデルが実現します。

高速でオフロードされたインデックス構築

lakebase_vectorは、より並列化された方法でインデックスを構築します。小さなランダムサンプルに対してセントロイドを1回トレーニングします。これがデータセット全体を参照する唯一のステップです。その後、各ベクトルは独立して最も近いセントロイドに割り当てられ、量子化され、そのクラスターのブロックに書き込まれます。このプロセスは、利用可能なすべてのコアに分散させることができ、コンピュートに応じてスケールします。 

さらに、プライマリデータベースからインデックス構築を完全にオフロードすることで、これを一歩進めています。データをオープンフォーマットで保存することで、LTAPアーキテクチャはインデックス構築とメンテナンスをSparkなどの分散エンジンに委任できるようになり、並列コンピュートによって構築時間を数分に短縮します。今後のアップデートにご期待ください。

高速で高精度な検索

lakebase_vectorは、コンパクトな1ビットコードを使用して候補検索を低コストで広げ、絞り込まれたショートリストのみを完全な精度で再ランク付けします。インデックスブロックが独立しているため、単一のクエリがCPUコア間で並列化され、高い再現率と低レイテンシを同時に実現します。

フィルタリングは、lakebase_vectorがクラスターブロックをスキャンする際に直接実行されます。述語をインラインで適用することで、候補の過剰取得を防ぎ、フィルタリングされたクエリの再現率を高く維持します。

lakebase_text：PostgresにおけるネイティブなBM25検索

標準的なPostgresのテキスト検索（tsvector）には、コーパス全体の関連性コンテキストが欠けています。lakebase_textは、グローバルな逆文書頻度（IDF）で用語をスコアリングすることにより、ネイティブなBM25をPostgresにもたらします。これにより、一般的なフィラーワードをペナルティの対象としつつ、希少で意図の高い用語に大きな重みを置きます。

また、従来のtsvector + GINインデックスよりも高速です。探索中にスコアの上限を評価することで、エンジンはtop-Kの結果に到達できないポスティングブロック全体をスキップします。

lakebase_textとlakebase_vectorを組み合わせることで、Postgres内でのネイティブなハイブリッド検索が可能になります。単一のクエリで、セマンティックベクトル検索とBM25キーワード関連性を融合し、標準的なSQLフィルター述語を適用し、稼働中の運用テーブルと直接結合できます。

Lakebase Postgresはエージェント時代のために構築されています

エージェントは、従来の検索エンジンを限界以上に押し上げました。ベクトル検索をデータスタックのコア要件とし、単一のワークフローが数秒で数千の同時検索リクエストをトリガーするような、極端なバースト性をもたらしました。

私たちは、この新たな現実に特化してLakebase Searchを設計しました。Lakebase Postgresは、手動での再プロビジョニングやインフラ管理を行うことなく、1行から10億ベクトル、1 QPSから数千 QPSまでシームレスにスケールするサーバーレスアーキテクチャに支えられ、すべての運用および検索ワークロードを処理できるようになりました。

何百ものベータ版のお客様からのフィードバックをもとにLakebase Searchを構築しました。その成果は一目瞭然です。

1. データベース支出を3分の1に削減：Conexiomは、pgvectorと比較して5倍高いスループットを達成しながら、インフラコストを3分の1に削減しました。
2. エージェント向けの1つのSQLツール呼び出し：開発者は、複雑なマルチシステム検索パイプラインを、標準的なデータベースルールによって管理されるネイティブなハイブリッド検索用の単一のSQL呼び出しに置き換えることができます。
3. OLTPと検索の統合：チームは、稼働中の運用テーブルと専用の検索クラスターを、1つの従量課金制バックエンドに統合できます。

Lakebase Searchは、本日よりAWSおよびAzureで一般提供が開始されます。すでにLakebase上でアプリやエージェントを構築している場合は、拡張機能を有効にするだけです。まだLakebaseをお試しでない場合は、今すぐ始めましょう。

▎ 📝 注：Databricks AI Searchは、すぐに高品質な検索を利用できるマネージド検索エンジンです。手動でのチューニングなしで優れた結果を得たい場合に最適です。すべての運用データと検索データを1つのデータベースにまとめたい場合は、Lakebase Searchが適しています。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事