PolarDB for MySQL の AISearch 機能は、ベクトル類似検索機能をデータベースカーネルに統合します。これにより、テキスト、画像、音声などの非構造化データから生成されたベクトルに対して非常に効率的な類似検索を実行すると同時に、構造化されたビジネスデータを保存および処理できます。セマンティック検索、Artificial Intelligence Recommendation、画像による検索などの強力な AI ネイティブアプリケーションを、別のベクトルデータベースや複雑なデータ同期パイプラインを構築および維持することなく、PolarDB クラスター内に構築できます。PolarDB は、さまざまな技術スタックやビジネスシナリオに合わせて、ベクトル検索用に 2 つの異なるプロトコルを提供します。完全に互換性のある MySQL プロトコルと、主流の検索エコシステムと互換性のある OpenSearch プロトコル (PolarSearch) です。
コアコンセプト
ベクトル埋め込み: 事前トレーニング済みの埋め込みモデルを使用して、テキストや画像などの非構造化データを数値配列 (ベクトル) に変換する技術です。これらのベクトルはデータの深い意味情報を捉え、マシンがその類似性を理解し比較することを可能にします。
類似検索 (k-NN): k-最近傍探索とも呼ばれ、その主な目標は、大規模なデータセット内で特定のクエリベクトルに「最も近い」k 個のベクトルを見つけることです。この文脈での「距離」は、さまざまな数式を使用して計算され、データの意味的な類似性を表します。
ベクトルインデックス: 効率的なクエリのために最適化されたデータ構造です。ベクトルの分布に基づいて検索範囲を迅速に絞り込むことで、大規模なデータセットでの完全な一対一の比較を回避するために使用されます。これにより、高い取得率を確保しながら、検索レイテンシーを秒単位からミリ秒単位に短縮します。
ベクトルインデックスアルゴリズムの比較: PolarDB は、複数の主流のベクトルインデックスアルゴリズムをサポートしています。HNSW と IVF が最も一般的な 2 つです。これらは、パフォーマンス、リソース消費、および適用可能なシナリオの点で異なる強みを持っています。
HNSW (Hierarchical Navigable Small World): 高いパフォーマンスと高い取得率を提供するグラフベースのインデックスです。ただし、メモリのオーバーヘッドが大きいです。非常に低いクエリレイテンシー、高い精度を必要とし、データセットのサイズが利用可能なメモリ内に収まるシナリオに適しています。
IVF (Inverted File): クラスタリングベースの転置インデックスです。メモリ使用量が少なく、限られたメモリで非常に大規模なデータセットを処理する必要があるシナリオに適しています。ただし、その検索精度は通常、HNSW よりもわずかに低くなります。
主な利点
PolarDB ベクトルエンジンは、リレーショナルデータベースの使いやすさと専用のベクトルデータベースの高性能を兼ね備えています。他の技術オプションに比べて大きな利点を提供します。
機能 | 従来のリレーショナルデータベース | 専用ベクトルデータベース | PolarDB ベクトルエンジン |
SQL サポート | サポート | サポートされていません | サポート |
ベクトル検索 | パフォーマンスが低い | 高性能 | 高性能 |
学習曲線 | 低い | 高い | 低い |
エコシステムの互換性 | 豊富 | 限定的 | デュアルエコシステム |
スケーラビリティ | 限定的 | 良い | 優れている |
O&M の複雑さ | シンプル | 複雑 | シンプル |
また、以下のコアな利点もあります。
オールインワンソリューション: 別のベクトルデータベースを使用する必要はありません。PolarDB でビジネスデータとベクトルデータの両方を処理できます。これにより、システムアーキテクチャーが簡素化され、O&M コストが削減されます。
エンタープライズグレードの信頼性: データ整合性を確保するために、原子性、一貫性、隔離、耐久性 (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 読み取り専用ノードに自動的に表示されます。 | 同期は不要です。データがプライマリデータベースに書き込まれると、検索ノードに自動的に表示されます。 |
ユースケース 1: AI チャットとカスタマーサービスボット
課題: 従来のキーワードマッチングでは、ユーザーの質問の真の意図を理解できず、不正確な回答につながります。
ソリューション: ナレッジベースの「質問と回答」のペアをベクトルに変換して保存します。ユーザーが質問をすると、その質問もベクトルに変換されます。その後、類似検索を使用して最も関連性の高いナレッジポイントを見つけ、より正確な回答を提供できます。
推奨プロトコル:
MySQL プロトコル: 基本的なセマンティックマッチングを実装するだけで、既存の MySQL アプリケーションに迅速に統合したい場合は、このソリューションがより便利です。
OpenSearch プロトコル: キーワード、カテゴリラベル、またはその他の基準で複雑なフィルタリングを実行するには、そのハイブリッド検索機能を使用できます。
ユースケース 2: パーソナライズされたレコメンデーションシステム
課題: ユーザーの過去の行動 (閲覧、クリック、購入) に基づいて、ユーザーが興味を持つ可能性のある製品やコンテンツをどのように推奨するか。
ソリューション: ユーザーとアイテム (製品、記事、ビデオ) の両方をベクトルとして表現します。ユーザーベクトルとアイテムベクトルの類似性を計算することで、ユーザーが興味を持つ可能性のあるアイテムの候補セットを取得できます。その後、他の戦略を使用して詳細なランキングを行います。
推奨プロトコル:
OpenSearch プロトコル: レコメンデーションシステムの取得レイヤーは通常、大量のデータを持ち、パフォーマンスとコストに敏感です。OpenSearch プロトコルが提供する IVF インデックスとプロダクト量子化 (PQ) 技術は、大量のデータを処理し、メモリコストを制御するのに適しています。
ユースケース 3: 画像による検索とマルチモーダル検索
課題: 画像をアップロードして類似の画像を見つける方法、またはテキスト記述を使用して画像を見つける方法。
ソリューション: 画像とテキストの両方をベクトルに変換し、PolarDB に保存します。入力が画像であれテキストであれ、それをクエリベクトルに変換し、データベースで類似検索を実行します。
推奨プロトコル:
MySQL プロトコル: 製品 ID や価格などのビジネスデータと画像特徴ベクトルの強力な整合性管理を必要とするシナリオでは、MySQL プロトコルのトランザクション機能が不可欠です。