ベクトル検索

このページでは、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 検索では、高い再現率が得られます。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 個のベクトルを用意することをおすすめします。

次のステップ