PolarDB for MySQL の AISearch 機能は、ベクター類似検索をデータベースカーネルに統合します。構造化データを格納および処理しながら、テキスト、画像、音声などの非構造化データから生成されたベクターに対して効率的な類似検索を実行することもできます。これにより、個別のベクターデータベースや複雑なデータ同期パイプラインを構築・維持することなく、ご利用の PolarDB クラスター内でセマンティック検索、インテリジェントなレコメンデーション、画像検索などの AI アプリケーションを構築できます。PolarDB は、さまざまな技術スタックやビジネスシナリオに対応するため、完全に MySQL 互換のプロトコルと、主流の検索エコシステムと互換性のある OpenSearch プロトコル (PolarSearch) という 2 つのベクター検索プロトコルを提供します。
基本概念
ベクター埋め込み：テキストや画像などの非構造化データを、事前学習済みの埋め込みモデルを使用して数値配列 (ベクター) に変換する技術です。これらのベクターはデータの深い意味情報を捉え、機械がその類似性を理解し比較することを可能にします。
類似検索 (k-NN)：k近傍法 (k-nearest neighbor) 検索とも呼ばれます。その主な目的は、大規模なデータセットの中から、特定のクエリベクターに対して「最も近い」k個のベクターを見つけ出すことです。この文脈における「距離」はさまざまな数式で計算され、データポイント間の意味的な類似性を表します。
ベクターインデックス：大規模なデータセットのフルスキャンを避けるために、ベクターインデックスが作成されます。インデックスは、効率的なクエリのために最適化されたデータ構造です。ベクターの分布に基づいて検索範囲を絞り込み、高い取得率を確保しながら検索レイテンシーを数秒からミリ秒単位に短縮します。
ベクターインデックスアルゴリズムの比較：PolarDB は、複数の主流なベクターインデックスアルゴリズムをサポートしています。最も一般的な 2 つは HNSW と IVF で、それぞれパフォーマンス、リソース消費、適用シナリオにおいてトレードオフがあります。
HNSW (Hierarchical Navigable Small World)：グラフベースのインデックスで、高いパフォーマンスと高い取得率を提供しますが、メモリのオーバーヘッドが大きくなります。極めて低いクエリレイテンシーと高い精度が要求され、データセットが使用可能なメモリに収まるシナリオに最適です。
IVF (Inverted File)：クラスターベースの転置インデックスで、メモリ消費量が少ないため、メモリに制約のあるシナリオでの非常に大規模なデータセットに適しています。ただし、その検索精度は通常、HNSW よりもわずかに低くなります。
主な利点
PolarDB のベクトルエンジンは、リレーショナルデータベースのシンプルさと専用のベクトルデータベースの高性能を兼ね備え、他の技術オプションに比べて大きな利点を提供します。
特徴 | 従来のリレーショナルデータベース | 専用のベクトルデータベース | PolarDB ベクトルエンジン |
SQL サポート | サポート | 非サポート | サポート |
ベクトル検索 | パフォーマンスが低い | 高性能 | 高性能 |
学習曲線 | 低い | 高い | 低い |
エコシステムの互換性 | 豊富 | 限定的 | デュアルエコシステム |
スケーラビリティ | 限定的 | 良好 | 優秀 |
運用上の複雑さ | シンプル | 複雑 | シンプル |
さらに、以下のコアな利点を提供します：
オールインワンソリューション：ビジネスデータとベクトルデータの両方を、別のベクトルデータベースなしで PolarDB 内で処理します。これにより、システムアーキテクチャーが簡素化され、運用コストが削減されます。
エンタープライズグレードの信頼性：ACID トランザクションを完全にサポートし、データ整合性を保証します。その分散アーキテクチャは、高可用性と自動切り替えを提供し、業務継続性を確保します。
LLM との緊密な統合：Qwen 大規模言語モデル (LLM) の組み込み推論機能により、AI アプリケーションの開発パイプラインが簡素化されます。
コア機能とパフォーマンスメトリクス
検索パフォーマンス
レイテンシー：P99 (99% のリクエスト) < 10 ms、P95 (95% のリクエスト) < 5 ms。
スループット：ノードあたり > 10,000 QPS。
精度：取得率 > 99%。
スケーラビリティ
データ規模：ペタバイト規模のベクトルデータと、数十億のベクターにわたる類似検索をサポートします。
同時実行性：数万の同時クエリを処理します。
クラスター規模：インテリジェントなデータシャーディング戦略により、数百のノードへの動的なスケールアウトをサポートします。
リソース効率
ストレージ圧縮：ベクトルデータ圧縮率 > 50%。
メモリ使用量：階層型キャッシング技術により、テラバイト規模のグラフインデックスを効果的にサポートします。
CPU 使用率：マルチコア並列計算の最適化により、CPU 使用率 > 80%。
利用シーン
PolarDB はデュアルプロトコル設計を提供します。チームの技術スタック、ビジネス要件、パフォーマンスへの期待に最も適したプロトコルを選択できます。
比較 | MySQL プロトコル | OpenSearch プロトコル |
アクセス方法 | 標準 SQL | RESTful API (Elasticsearch/OpenSearch と互換) |
主な利点 | ビジネスデータと統合し、既存のテーブルへのベクター列の追加をサポートし、ACID トランザクションをサポートし、学習曲線が低い。 | ベクター、全文、スカラーデータを組み合わせたクエリをサポートするハイブリッド検索機能を提供し、成熟したエコシステムを持つ。 |
基盤となる依存関係 | インメモリ列指向インデックス (IMCI) に依存します。ベクター検索は、分析ワークロードとトランザクションワークロードを分離するために、IMCI 読み取り専用ノードで実行されます。 | 専用の検索ノード (PolarSearch) 上で実行され、検索エンジンのようなサービスを提供します。 |
データ同期 | 不要です。プライマリノードに書き込まれたデータは、自動的に IMCI 読み取り専用ノードから可視になります。 | 不要です。プライマリノードに書き込まれたデータは、自動的に検索ノードから可視になります。 |
インテリジェント Q&A とカスタマーサービスボット
ビジネス上の課題：従来のキーワード一致では、ユーザーの意図を理解できず、不正確な回答につながることがよくあります。
ソリューション：自社のナレッジベースにある質問と回答のペアをベクターに変換して保存します。ユーザーが質問をすると、それをクエリベクターに変換し、類似検索を使用して最も関連性の高いナレッジポイントを見つけ、より正確な回答を提供します。
プロトコルの推奨：
MySQL プロトコル：基本的なセマンティックマッチングのみが必要で、既存の MySQL アプリケーションに迅速に統合したい場合、このプロトコルは便利な選択肢です。
OpenSearch プロトコル：キーワード、カテゴリラベル、またはその他の基準を組み合わせて複雑なフィルタリングを行う必要がある場合、このプロトコルのハイブリッド検索機能が理想的です。
パーソナライズされたレコメンデーションシステム
ビジネス上の課題：閲覧、クリック、購入などのユーザーの履歴動作に基づいて、関連する製品やコンテンツを推奨すること。
ソリューション：ユーザーとアイテム (製品、記事、ビデオなど) の両方をベクターとして表現します。ユーザーとアイテムのベクター間の類似性を計算することで、ユーザーが興味を持つ可能性のあるアイテムのサンプル候補セットを取得できます。このセットは、他のランキング戦略を使用してさらに絞り込むことができます。
プロトコルの推奨：
OpenSearch プロトコル：レコメンデーションシステムの検索層では、膨大なデータを扱うため、パフォーマンスとコストが重要視されます。OpenSearch プロトコルが提供する IVF インデックスと Product Quantization (PQ) 技術は、メモリコストを抑制しながら大規模なデータセットを処理するのに適しています。
画像検索とマルチモーダル検索
ビジネス上の課題：サンプル画像をアップロードして類似の画像を見つけたり、テキスト記述を使用して画像を検索したりすること。
ソリューション：画像とテキストの両方をベクターに変換し、PolarDB に保存します。入力が画像であれテキストであれ、クエリベクターに変換され、データベース内で類似検索が実行されます。
プロトコルの推奨：
MySQL プロトコル：画像の特徴ベクトルと、製品 ID や価格などのビジネスデータとの間で強力な整合性が要求されるシナリオでは、MySQL プロトコルのトランザクション機能が不可欠な保護策となります。