ベクトル検索を本番環境で使うには、検索速度に加え、データが増えたときの拡張性や運用コストも考える必要があります。数百万件では快適に動いていたシステムでも、数億件になると、応答の遅延やメモリ不足への対応が課題になります。

OceanBaseは、日々の業務を支えるトランザクション処理と、意味や類似度に基づくベクトル検索を一つのデータベースで扱えます。データを複数のサーバーに分散する仕組みと、独自開発のベクトル検索ライブラリ「VSAG」を組み合わせ、データの増加に対応しながら、検索性能とコストの両立を図ります。

その基盤となるのは、業務処理や分析処理の性能を測るTPCベンチマークで世界記録を達成した分散データベースエンジンです。ベクトル検索でも、約10億件規模のデータを扱う本番環境で運用されています。本記事では、こうした性能を支える仕組みと、構成を選ぶ際のポイントを紹介します。

データが増えても、同じ基盤で検索を続ける

業務用データベースとは別にベクトルデータベースを導入すると、管理するシステムも増えます。業務用データベースのSQLやメモリ設定に加え、ベクトル検索のインデックスやメモリ使用量も、それぞれの製品に合わせて調整する必要があります。

さらに、単一ノードで扱える容量を超えた場合、構成によってはアプリケーション側でデータの分割先を管理し、複数のノードへ検索を振り分けなければなりません。検索結果を返す際にも、各ノードが見つけた候補をまとめ、全体で類似度の高い順に並べ直す処理が必要です。

OceanBaseでは、ベクトルデータとインデックスも、通常のテーブルと同じ仕組みで分散管理します。ベクトル検索とトランザクション処理は実行エンジンを共有し、SQLオプティマイザが処理を最適化します。PoCから本番運用へ移行し、データ規模が拡大しても、同じ基盤のまま運用を継続できます。データ規模や必要な検索精度に合わせてインデックスを選ぶことで、メモリ使用量の増加も抑えられます。

ネイティブな分散設計によるスケールアウト

OceanBaseと多くの専用ベクトルデータベースの違いは、まずアーキテクチャにあります。

ベクトルデータベースによっては、アプリケーション側で検索リクエストを各シャードに振り分けて、分散処理を行います。この方式では、運用開始後のシャーディング方針の変更が難しく、シャードをまたぐ検索結果の集約や、各インスタンスの個別管理も必要です。

OceanBaseは、分散処理を前提に設計されたデータベースです。ベクトルデータとインデックスは、パーティションごとにクラスタ内のノードに自動配置されます。検索時には各パーティションでANN（近似最近傍）検索を並列実行し、それぞれのTop-K候補を集約して全体の順位を決定します。これらの処理はOceanBaseが行うため、アプリケーション側で制御する必要はありません。

ノードやパーティションを追加することで、システム全体の検索スループットを向上させられます。アプリケーションのコード変更やサービス停止は不要です。ただし、実際のQPSはパーティション数、パーティションプルーニングの有効性、フィルタ条件による絞り込みの度合いなどに左右されます。検索対象が多くのパーティションにまたがる場合は、結果の集約に追加のコストがかかります。そのため、想定する検索条件で応答時間とQPSが要件を満たすかを、パーティションキーの設計とあわせて確認する必要があります。

密ベクトルのインデックスは、主にHNSWとIVFから選べます。HNSWはメモリ上で高速に検索し、低レイテンシと高い処理性能を重視する用途に適しています。IVFはディスクを活用し、すべてのベクトルをメモリに保持せずに、より大規模なデータを扱えます。

構成を検討する際は、公式ドキュメントのベクトルインデックスのベストプラクティスを参照してください。必要なメモリ容量の見積もりには、INDEX_VECTOR_MEMORY_ADVISOR関数を利用できます。インデックスやパーティション構成については、OceanBaseのテクニカルサポートにもご相談いただけます。

VSAG：ベクトル検索を高速化する

データの分散によって大規模な検索を支えるのがOceanBaseのアーキテクチャなら、各ノードでの検索を高速化するのがVSAGです。

VSAGは、オープンソースのベクトル検索ライブラリです。HNSWとIVFに対応し、用途に応じてFlat、SQ8、PQ、BQなどと組み合わせて利用できます。高い再現率を重視する場合はHNSW、大規模データでメモリ使用量を抑える場合はIVF_PQが選択肢になります。

検索に使う距離・類似度の指標には、マンハッタン距離（L1）、ユークリッド距離（L2）、内積、コサイン類似度を利用できます。また、密ベクトルと疎ベクトルの両方に対応しています。

検索精度を保ちながら、処理件数を増やす

ベクトル検索の性能を比較する際は、検索速度と再現率をあわせて見る必要があります。

VSAGは、ベクトル検索のベンチマーク「ANN-Benchmarks」のgist-960データセットで、再現率96.7%を維持しながら、当時トップの性能を示していたGlassを90%上回るQPSを記録しました。この条件では、当時の最先端水準にある検索性能を示しました。つまり、同じハードウェアで検索精度を保ちながら、より多くのリクエストを処理できます。同じQPSを目標にする場合には、計算リソースをおよそ半分に抑えられる可能性もあります。

この結果は、特定の公開データセットで測定したものです。本番環境の性能は、ベクトルの次元数やデータ分布、インデックスの設定によって変わるため、実際のデータと検索条件で確認する必要があります。

VSAGでは、ARM対応に加え、IVFインデックスやBQ量子化の単一ノードでの性能改善も進めています。x86とARMのいずれの環境でも高い性能を発揮できるよう、最適化を進めています。

SQLとベクトル検索をまとめて最適化する

VSAGは、OceanBaseの内部でSQLエンジンと同じメモリプールとスレッドプールを使います。ベクトル検索のために別のプロセスを呼び出す必要がなく、メモリやCPUの割り当てもデータベース内で一括管理できます。これにより、プロセス間の通信や、別々の仕組みでリソースを確保することによる競合を抑えられます。

オプティマイザは、ベクトル検索、通常の列の値による絞り込み、テーブルの結合（JOIN）を一連の処理として扱います。それぞれにかかる処理コストを見積もり、どの順序で実行するかを決めます。たとえば、条件で候補を減らしてからベクトル検索を行う方が効率的なら、その順序を選べます。

このように、SQLとベクトル検索を同じエンジンで実行することで、クエリ全体を最適化できます。業務用データベースと外部のベクトルデータベースを組み合わせる場合は、両者の処理順序やデータの受け渡しをアプリケーション側で調整する必要があります。

条件による絞り込みとベクトル検索を組み合わせる

実際のサービスでは、単に「似ているもの」を探すだけでは足りません。たとえば商品検索なら、「指定した店舗で扱う、特定のカテゴリの商品」の中から、ユーザーの入力内容に意味が近いものを探したい場合があります。このような検索では、通常の列の値による絞り込みと、ベクトルによる類似度の検索を組み合わせます。

OceanBaseのオプティマイザは、処理コストを見積もったうえで、次の二つの方式を使い分けます。

• pre_filter：先に条件で対象を絞り、その中でベクトル検索を行います。
• post_filter：先にベクトル検索で候補を見つけ、その候補に条件を適用します。

条件によって対象を大幅に減らせる場合は、先に絞り込むことで不要なベクトル計算を省けます。あまり減らせない場合は、ベクトル検索を先に行う方法も含めて、再現率とレイテンシを考慮した実行方法を選びます。VECTOR_INDEXヒントを使い、明示的に指定することもできます。

全文検索とベクトル検索の結果を組み合わせるハイブリッド検索には、HYBRID_SEARCH SQLインターフェースを利用できます。単一のクエリで複数の検索結果を統合でき、密ベクトルと疎ベクトルのいずれも利用できます。

量子化でメモリ・ストレージコストを抑える

データが増えたときのコストを左右するのが、ベクトル1件あたりに必要なメモリとストレージです。量子化は、ベクトルをより少ないビット数で表現して、データサイズを小さくする技術です。必要な検索精度とのバランスを取りながら、使用するリソースを抑えます。

• HNSW_BQ：高い圧縮率を実現する量子化方式です。768次元の標準データセットでは、最大で約99%の再現率を達成できます。実際の再現率は、ef_searchやrefine_kなどのパラメータに依存します。
• HNSW_SQ / IVF_PQ：数億～数十億件規模で、再現率とコストのバランスを調整できます。1,000万件・768次元の構成では、HNSW_SQの推奨テナントメモリは約48 GBで、HNSWの約160 GBから大幅に削減できます。

配送サービスのLalamove（ララムーブ）は、本番環境でHNSWの量子化による圧縮を採用しています。単一のパーティションで業務要件を満たし、アプリケーション側でデータベースやテーブルを分割する必要はありませんでした。データ量の増加に備え、今後は量子化を利用したIVF系インデックスに移行し、メモリ使用量をさらに抑える計画です。同社の事例では、インデックスの再構築にかかる時間は約25分とされています。

TPCの世界記録と、本番運用を支える可用性

ベクトル検索を支えるOceanBaseの分散データベースエンジンは、業務処理と分析処理の両方で実績を持っています。その一つが、データベースの性能を測るTPCベンチマークです。

• TPC-C：受発注などのトランザクション処理を評価するベンチマークです。OceanBaseは2020年に7.07億tpmCを記録し、当時の世界記録を更新しました。
• TPC-H：大量のデータを集計・分析する処理を評価します。OceanBaseは2021年に1,526万QphH@30000GBを記録し、世界記録を達成しました。

これらはベクトル検索自体の測定結果ではありませんが、検索を支えるエンジンが、トランザクション処理と大規模な分析処理の双方に対応できることを示しています。

可用性については、3つの地域に5つのデータセンターを配置する構成で、RPO = 0、RTO < 8秒を実現します。RPOはデータをどの時点まで復旧させるか、RTOはどれだけの時間で復旧させるかを示す目標です。この構成では、データ損失をゼロに抑え、8秒未満での復旧を実現します。ベクトルデータと業務データの両方を、同じ仕組みで保護できます。

2025年8月時点では、OceanBaseはDB-Enginesのベクトルデータベースランキングで8位に入り、Multi-modelに分類されています。これは当時の順位です。製品を選ぶ際は、最新の公開ベンチマークやPoCの結果もあわせて確認してください。

本番環境での導入事例

Trip.comグループ：約10億件の画像ベクトルを安定運用

旅行予約サービスを展開するTrip.comグループでは、Ctripがホテル画像のベクトル約10億件をOceanBaseに移行しました。従来のElasticsearchとFaissを組み合わせた構成を置き換え、事例の報告時点で、稼働開始から約1年間、障害なく運用しています。

IVFインデックスとコサイン距離を採用し、384次元のベクトルをlocationフィールドで3,000のパーティションに分割しています。条件による絞り込みを組み合わせた検索に対応し、インデックスの構築速度は従来の約4倍に向上しました。毎日数百万件の差分更新も処理しています。

OceanBaseへの統合によって、ElasticsearchとFaissをそれぞれ運用し、容量や負荷に応じて個別に拡張する手間がなくなりました。可用性の確保とSQLによる開発も、一つのデータベースで対応できます。

Lalamove：二つのデータベースを統合し、アクセス増加にも対応

Lalamoveは以前、ベクトル検索にWeaviate、業務データにリレーショナルデータベースを使っていました。同時アクセスが増えると障害が頻発し、障害時に処理を正常なノードへ自動で切り替えることも難しい状況でした。

OceanBaseへの統合後は、高負荷でも安定して稼働しています。ベクトル検索と大規模言語モデルは、障害や損失につながるおそれのあるコードを検出する仕組みや、データウェアハウスに関する質問にAIが回答する仕組みに活用されています。

障害時は、複数のノード間でデータの整合性を保つPaxosを基盤に、自動復旧を行います。バックアップとリストアの機能も利用し、障害への対応力を高めています。今後は、Milvusなど、ほかのベクトルデータベースも段階的にOceanBaseへ移行する計画です。

Weaviateクラスタを個別に管理する負担がなくなったことに加え、HNSWの量子化による圧縮で、同じ規模のデータをより少ないメモリで扱えるようになりました。

OceanBaseを検討したいケース

OceanBaseの強みは、データ量に応じて拡張できること、SQLとベクトル検索をまとめて最適化できること、そしてインデックスの選択によってメモリとストレージのコストを調整できることです。ベクトル検索にも業務データと共通の可用性の仕組みを使えるため、次のような要件がある場合に適しています。

• ベクトルデータが数百万件から数億件、将来的には数百億件へ増える見込みがある
• 条件による絞り込みや全文検索とベクトル検索を組み合わせ、低レイテンシで応答したい
• 金融、取引、リスク管理、ECの基幹システムなど、整合性と高可用性に明確な要件がある
• ベクトル検索とSQLのチューニングを、共通の基盤で進めたい

比較検証には、ベクトルデータベースの性能を測るツール「VectorDBBench」も利用できます。OceanBaseが公開しているテスト手順では、100万件・768次元、50万件・1,536次元などのデータを使い、ベクトル検索のみのケースと、条件による絞り込みを伴うケース（フィルタ率1%・99%）を比較しています。自社の検索条件に近いケースを選ぶ際の参考になります。詳しくは、公式サイトのVectorDBBenchに関するテスト手順をご覧ください。

社内PoCや数百件程度のベクトルを使った検証であれば、幅広い製品を利用できます。将来的に数千万件以上を扱い、ベクトルデータと業務データを長期にわたって運用するなら、検索速度だけでなく、拡張時の作業や日々の運用、必要なメモリ容量まで含めて比較することが重要です。そうした観点を重視するなら、OceanBaseは検討に値する選択肢といえます。