ベクトル検索

このページでは、Cloud SQL for MySQL インスタンスでベクトル検索が実装される方法について説明します。Cloud SQL では、保存されている他のデータと組み合わせて、ベクトル エンベディングを保存し、ベクトル インデックスを作成し、ベクトル検索を実行できます。

ベクトル エンベディングの保存

ベクトル エンベディングは、アトミック性、整合性、独立性、永続性（ACID）の特性に準拠したテーブルに保存します。テーブル内の他のリレーショナル データと同様に、既存のトランザクション セマンティクスを使用してテーブル内のベクトル エンベディングにアクセスできます。

テーブルの行とベクトル表現とのマッピングを確立するには、ベクトル エンベディングを保存する列をテーブルに作成する必要があります。列には Cloud SQL VECTOR データ型を使用し、エンベディングに必要なディメンションの数を指定する必要があります。ベクトル エンベディング列には、列を定義するときに指定したディメンションとまったく同じディメンションを使用するベクトル エンベディングのみを保存できます。

テーブルに設定できるベクトル エンベディング列は 1 つのみです。テーブル内の行数に制限はありません。

ベクトル エンベディング列を他の列と区別するために、Cloud SQL は特別な COMMENT と CONSTRAINT を列に追加します。入力検証には制約が必要であり、ベクトル エンベディング列のアノテーションは COMMENT として表示されます。コメントや制約を変更または削除することはできません。

Cloud SQL インスタンスで十分なストレージとメモリが使用可能な場合は、独自のベクトル エンベディング列を持つ複数のテーブルを作成できます。

データ レプリケーションは、他の MySQL InnoDB 列の場合と同じように、ベクトル エンベディング列でも機能します。

ベクトル エンベディング テーブル、列、DML ステートメントの制限事項については、制限事項をご覧ください。

ベクトル インデックス

ベクトル エンベディングに対して ANN 類似性検索を実行するには、ベクトル インデックスを使用する必要があります。Cloud SQL は、スケーラブルな最近傍探索（ScANN）アルゴリズムを使用してベクトル インデックスを作成します。

ベクトル インデックスには次の要件があります。

  • 1 つのテーブルに作成できるベクトル インデックスは 1 つのみです。
  • インスタンスにベクトル エンベディングを含むテーブルが複数ある場合は、各テーブルにベクトル インデックスを作成できます。
  • ベクトル インデックスを作成する場合は、インデックス付きテーブルの主キーに制約を追加できません。

検索品質を高めるには、ベーステーブルにデータの大部分を読み込んだ後にのみベクトル インデックスを作成します。ベーステーブルにエンベディングが 1, 000 個未満の場合、インデックスの作成は失敗します。

ベクトル インデックスを作成するかどうかを判断する際、行数が少ない場合は、代わりに KNN 検索を実行できるかどうかを検討してください。KNN 検索と ANN 検索のどちらを使用するかは、ベクトル エンベディングの次元数によっても異なります。エンベディングの数が多い場合は、ベクトル インデックスが必要になることがあります。

ベクトル インデックスの制限事項については、制限事項をご覧ください。ベクトル インデックスの作成については、ベクトル インデックスの作成と管理をご覧ください。

ベクトル インデックスの更新

Cloud SQL はベクトル インデックスをリアルタイムで更新します。ベーステーブルに対してデータ操作言語（DML）オペレーションを実行するトランザクションは、関連するベクトル インデックスにも変更を反映します。ベクトル インデックスは、テーブルの他のセカンダリ インデックスと同じように動作します。ベクトル インデックスはトランザクションの整合性が完全に保たれ、ACID に準拠しています。トランザクションをロールバックすると、ベクトル インデックスでも対応するロールバック変更が行われます。

ベクトル インデックスのレプリケーション

Cloud SQL は、カスケード レプリケーション用など、すべてのリードレプリカにベクトル インデックスを複製します。ベクトル エンベディングがあるプライマリ インスタンスから新しいリードレプリカを作成すると、リードレプリカはプライマリ インスタンスからベクトル エンベディングの設定を継承します。既存のリードレプリカの場合は、各リードレプリカでベクトル エンベディングのサポートを有効にする必要があります。

ベクトル インデックスの作成と維持で、レプリケーション ラグへの影響は通常の MySQL インデックスと同様です。

永続性、シャットダウン、メンテナンスへの影響

ベクトル インデックスは、ベーステーブルと同じ方法で永続化され、完全な ACID がサポートされています。ベクトル インデックスはベーステーブルのデータと常に同期されており、同じ可視性、分離、クラッシュ セーフティを備えています。インスタンスがシャットダウンされたりメンテナンスを受けたりしても、ベクトル インデックスには影響しません。

インデックスのメンテナンス

ベーステーブルに対して大規模な DML オペレーションが実行された後、（インデックスの作成時に）初期データでトレーニングしたベクトル インデックスに新しい状態が反映されていない可能性があります。これにより、検索品質に影響する可能性があります。

このインデックスは 2 つの部分で構成されています。

  • インデックス ツリー。これは、既存のデータでトレーニングすることで構築されます。インデックスの存続期間中は変更されません。
  • インデックス リーフ。ここにデータのすべての行が含まれます。インデックス リーフは同期が解除されることはありません。

行がリーフから別のリーフに移動するため、多数の DML ステートメントを実行すると、インデックス ツリーの効率が低下する可能性があります。インデックス ツリーを更新するには、インデックスを再構築する必要があります。

ベクトル インデックスを含むテーブルに対するサポートされていない DDL オペレーション

  • コピー アルゴリズムを必要とするテーブル オペレーションを変更します。
  • テーブルの再作成が必要なテーブル変更オペレーション。
  • 主キーを削除または変更する。
  • テーブルを一般的なテーブルスペースに移動します。

ベクトル検索

Cloud SQL には、インスタンスで近似最近傍探索（ANN）と K 最近傍探索（KNN）のベクトル類似性検索を行うために使用するベクトル距離関数があります。クエリを実行すると、クエリベクトルがデータセット内のベクトルと比較されます。距離関数は、コサインなどの類似度指標を使用してベクトル間の距離を計算します。距離が最も近いベクトルが最も類似しており、検索結果に返されます。

Cloud SQL は、ANN ベクトル検索と KNN ベクトル検索を実行するときに、ベクトル検索でベクトル間の距離を測定するために次の関数を使用します。

  • コサイン: 2 つのベクトル間の角度のコサインを測定します。値が小さいほど、ベクトル間の類似度が高くなります。
  • ドット積: 角度のコサインに、対応するベクトルの大きさを掛けます。
  • L2 二乗距離: 各ディメンションの二乗距離を加算して、2 つのベクトル間のユークリッド距離を測定します。

正確な結果が必要な場合や、選択的なフィルタを追加する場合は、KNN ベクトル検索が推奨される検索方法です。KNN 検索では、データセット内のすべてのエンベディングとクエリベクトルの距離計算を実行して、最近傍を見つけます。Cloud SQL の KNN 検索では、100% の再現率が得られます。KNN 検索ではベクトル インデックスを使用しないため、小規模なデータセットを扱う場合に適しています。

KNN 検索を実行するには、vector_distance 関数を使用します。この関数は、クエリベクトル（検索対象）とデータセットの候補ベクトルの 2 つのベクトルを入力として受け取ります。この 2 つのベクトルの距離を計算します。vector_distance は SELECT ステートメントで使用します。詳細については、K 最近傍（KNN）を検索するをご覧ください。

KNN のパフォーマンスが低い場合は、後でベクトル インデックスを構築し、アプリケーションで ANN 検索に approx_distance を引き続き使用できます。

クエリの効率性が懸念される場合は、ANN ベクトル検索が推奨される検索タイプです。クエリベクトルとデータセット内のベクトルの一部の距離のみを計算することで、類似性検索を高速化します。これを行うために、Cloud SQL はデータをクラスタまたはパーティションに編成し、クエリに最も近いクラスタに検索を絞り込みます。ANN 検索にはベクトル インデックスが必要です。これらのインデックスでは、完全な再現率よりも検索速度が優先されます。Cloud SQL では、ANN 検索に TREE_SQ インデックス タイプが使用されます。

ANN 検索を実行するには、距離測定オプションを指定して approx_distance 関数を使用します。approx_distance は ORDER BY リストまたは SELECT リストで使用し、LIMIT 句を使用して検索結果を制限できます。WHERE 句を追加して、検索結果のフィルタリング後処理を行うこともできます。詳細については、近似最近傍（ANN）を検索するをご覧ください。

ANN 検索が KNN 検索にフォールバックする場合があります。詳細については、ANN 検索のフォールバック ステータスを確認するをご覧ください。

要件

Cloud SQL では、ベクトル エンベディングを追加する前に、cloudsql_vector フラグを使用してインスタンスでベクトル エンベディングを有効にする必要があります。詳細については、インスタンスでベクトル エンベディングを有効または無効にするをご覧ください。

制限事項

ベクトル エンベディング列を含むテーブルには次の制限があります。

  • 1 つのテーブルには、ベクトル エンベディング列を 1 つのみ指定できます。
  • 1 つのテーブルには、ベクトル インデックスを 1 つのみ作成できます。
  • ベクトル エンベディングは 16,000 個のディメンションに制限されています。
  • ベクトル エンベディング列は、生成列にすることはできません。
  • ベクトル エンベディング列を含むテーブルのテーブルレベルのパーティショニングはサポートされていません。
  • BIT、BINARY、VARBINARY、JSON、BLOB、TEXT のデータ型または空間データを使用する主キーは、ベクトル インデックスではサポートされていません。複合主キーにも、これらの型を含めることはできません。
  • ベクトル インデックスがある場合、ベーステーブルの主キーに制約を追加することはできません。
  • テーブルにベクトル インデックスが存在する場合、実行できない DDL オペレーションがいくつかあります。詳細については、ベクトル インデックスを含むテーブルに対するサポートされていない DDL オペレーションをご覧ください。

ベクトル検索クエリには次の制限があります。

  • approx_distance 関数は、ORDER BY リストまたは SELECT リストでのみ使用できます。
  • ベーステーブルを含む述語は、ORDER BY リストまたは SELECT リストの approx_distance 式と組み合わせて WHERE 条件で使用できます。WHERE 条件述語は、approx_distance ベクトル関数が評価された後に評価されます。

ベクトル インデックスの使用に関するベスト プラクティス

このセクションでは、ベクトル インデックスの操作に関するベスト プラクティスについて説明します。ワークロードはそれぞれ異なるため、必要に応じて調整する必要があります。

  • 大規模な DML オペレーションの後で、インデックスを再構築することをおすすめします。
  • 一般に、使用するリーフ数を Cloud SQL に計算させても問題ありません。リーフ数を指定するユースケースがある場合は、最高の再現率を得るために、リーフごとに少なくとも 100 個のベクトルを用意することをおすすめします。

次のステップ