Unity Catalog マネージドテーブル向けベクトル最適化
ベータ版
この機能はベータ版です。
ベクトル最適化は、Unity Catalog マネージドテーブル内のベクトル列に対する類似検索を高速化します。APPROX NEAREST BY でベクトル検索クエリーをランする場合、Databricks はベクトル最適化を使用して、最も近い一致を含む可能性が高いデータに検索を絞り込むことができます。これにより、特に大規模なテーブルでスキャンされるデータの量が削減されます。
ベクトル最適化を使用するには、列にベクトルインデックスを作成し、コサイン類似度、内積、またはL2距離のスコアリングメトリクスを指定します。予測的最適化は、データが変更されるとインデックスを自動的に更新します。インデックス付き列と一致する比較関数を使用する対象クエリーでは最適化が使用されますが、その他のクエリーではブルートフォース検索が使用されます。クエリーの構文と例については、NEAREST BY句を参照してください。
要件
テーブルにベクトルインデックスを作成するには:
- Databricks Runtime 19以上を使用してください。
- テーブルに対して
SELECTおよびMODIFY権限、そのカタログに対してUSE CATALOG権限、およびそのスキーマに対してUSE SCHEMA権限を持っている必要があります。 - テーブルは、Unity Catalog 管理の Delta Lake または Iceberg テーブルである必要があります。
- テーブルと同じカタログおよびスキーマにインデックスを作成します。
- インデックスを自動的に更新するには、テーブルで 予測的最適化 を有効にする必要があります。
- インデックスを作成する前に、行トラッキングを有効にする必要があります。Databricks の行追跡を参照してください。
- インデックスを作成する場合、テーブルにはデータが含まれている必要があります。
- ベクトル列のデータ型は
ARRAY<FLOAT>である必要があり、すべてのベクトルの要素数は同じである必要があります。
APPROX NEAREST BY結合でベクトル最適化を使用するには、ベクトルインデックスを持つテーブルを右側に配置し、インデックスのスコアリングメトリクスに一致する比較関数を使用します。左側のクエリーベクトルテーブルでも行の追跡を有効にする必要があります。
ベクトルインデックスを作成する
CREATE VECTOR INDEXを使用して、列とスコアリングメトリクスのインデックスを作成します。例えば、次のステートメントは、embedding列のコサイン類似度でインデックスを作成します:
CREATE VECTOR INDEX main.analytics.documents_embedding_cosine_idx
ON main.analytics.documents (embedding)
OPTIONS (scoring_metric = 'cosine_similarity');
同じ列に複数のベクトルインデックスを作成して、さまざまなスコアリングメトリクスをサポートできます。
それぞれのスコアリングメトリクスは、クエリー関数に対応しています。
スコアリングメトリクス | クエリー関数 |
|---|---|
|
|
|
|
|
|
APPROX NEAREST BY クエリーで、インデックスのスコアリングメトリクスと一致するクエリー関数を使用します。一致するインデックスが存在しない場合、クエリーはベクトル最適化なしでランします。
ベクトル最適化を使用したデータのクエリー
ベクトルインデックスを持つテーブルを APPROX NEAREST BY JOIN の右側に配置します。左側のクエリーベクトル テーブルをフィルタリングしながら、ベクトル最適化を使用することもできます。次のバッチ結合は、クエリー ベクトルごとに最大 10 個のドキュメントを返します。
SELECT
q.query_id,
d.document_id
FROM main.analytics.query_vectors AS q
INNER JOIN main.analytics.documents AS d
APPROX NEAREST 10 BY SIMILARITY
vector_cosine_similarity(q.embedding, d.embedding);
インデックスのメンテナンスとステータス
ベクトルインデックスを作成した後、予測的最適化はテーブルの変更に応じて自動的にインデックスを更新します。クエリーには、それらの行がインデックス化される前であっても、新しく追加された行が即座に含まれます。
テーブルに関連付けられたインデックスを検索するには、DESCRIBE EXTENDEDをランします:
DESCRIBE EXTENDED main.analytics.documents;
出力の # Indexes セクションには、各インデックスの名前と完全修飾名が表示されます。例えば:
# Indexes
documents_embedding_cosine_idx main.analytics.documents_embedding_cosine_idx
インデックスを調査するには、完全修飾名を使用します。
DESCRIBE INDEX main.analytics.documents_embedding_cosine_idx;
出力には、インデックス付き列とスコアリングメトリクスに関する情報が含まれています。例えば:
属性 | Value |
|---|---|
名前 |
|
列 |
|
スコアリングメトリクス |
|
予測的最適化はインデックスを更新しますが、インデックスを自動的に再トレーニングすることはありません。テーブル内のベクトルの分散が大幅に変化した場合、再トレーニングによって検索品質を維持することができます。
インデックスを再トレーニングするには、同じ列とスコアリングメトリクスを使用してインデックスを削除し、再作成します。例えば:
DROP INDEX main.analytics.documents_embedding_cosine_idx;
CREATE VECTOR INDEX main.analytics.documents_embedding_cosine_idx
ON main.analytics.documents (embedding)
OPTIONS (scoring_metric = 'cosine_similarity');
ベクトルインデックスを削除する
ベクトルインデックスを削除するには DROP INDEX を使用します。
DROP INDEX main.analytics.documents_embedding_cosine_idx;
インデックスを削除すると、そのインデックスに依存していたクエリーは、インデックスの高速化なしで実行されます。
インデックス付きカラムの名前変更、削除、または型変更を行う前に、そのカラム上のすべてのベクターインデックスを削除してください。
制限
-
インデックスを作成する場合、テーブルは最大 10 億行を持つことができ、ベクトルは最大 4,096 要素を含むことができます。
-
次のケースでは、クエリーはベクトル最適化の代わりに総当たり検索を使用します。
- クエリーはインデックス付きテーブルに対してタイムトラベルを使用します。
- このテーブルには、行フィルタ、列マスク、または属性ベースのアクセス制御 (ABAC) ポリシーがあります。
- テーブルはOpenSharingのソースまたはターゲットです。
これは、インデックスを作成した後にこれらのポリシーを追加したり、テーブルの共有を起動したりした場合にも適用されます。