Unity Catalogマネージドテーブルの全文検索インデックス
ベータ版
この機能はベータ版です。使用するには、ワークスペース管理者が [プレビュー] ページから [SQL: Unity Catalog マネージドテーブルのフルテキスト検索インデックス] を有効にする必要があります。Databricksのプレビューの管理を参照してください。
ログメッセージ内のエラーコードのように、特定の単語や部分文字列を含む行を見つけるには、膨大な量のテキストをスキャンする必要がある場合があります。全文検索インデックスは、マネージド Delta Lake または Iceberg テーブルの 1 つ以上のテキスト列の検索を高速化します。インデックスは、部分文字列マッチングと単語マッチングをサポートしています。searchまたはisearch関数を使用してテーブルをクエリーする場合、Databricksはインデックスを使用して、一致する行が含まれる可能性のないファイルをスキップします。これにより、特に選択的なルックアップにおいて、スキャンされるデータ量が大幅に削減されます。
ベータ版リリース中に作成されたインデックスは、後のリリースとの互換性が保証されません。この機能がパブリックプレビュー段階に達したら、既存のインデックスを削除し、新しいインデックスを作成する必要があります。
全文検索インデックスを使用する場合
次の場合に全文検索インデックスを作成します：
- 大規模なマネージドテーブルの1つ以上のテキスト列で、単語や部分文字列を定期的に検索します。
- 検索パターンは、テーブルのファイルの一部にのみ表示されます。インデックスは、これらの選択的ルックアップを最も高速化します。
search関数またはisearch関数を使用してクエリーを記述できます。searchとisearchを使用してデータをクエリーするを参照してください。
制限事項にリストされている機能（行レベルのセキュリティや列マスクなど）を使用するテーブルにインデックスを作成しないでください。Databricks は、これらのテーブルのインデックスを無視します。
要件
全文検索インデックスには、コンピュート、ベース テーブルとスキーマのアクセス許可、およびベース テーブルの構成に関する要件があります。
コンピュート
全文検索インデックスは、Databricks Runtime 18.3以降でのみ利用可能であり、ワークスペース設定でこのベータ版機能を有効にする必要があります。Databricks プレビューの管理を参照してください。
権限
検索インデックスを作成するには：
- 検索インデックスで参照されているテーブルに対して、
MODIFY権限を持っている必要があります。 - 親スキーマに対して
CREATE TABLE権限が必要です。スキーマの所有者、またはMANAGE権限を持つユーザーは、あなたにスキーマに対するCREATE TABLE権限を付与できます。
テーブル構成
全文検索インデックスを作成するには、ベーステーブルが次のすべての要件を満たしている必要があります。
- インデックスは、ベーステーブルと同じカタログおよびスキーマ内に作成する必要があります。
- このテーブルは、管理対象のDelta Lakeテーブル、または管理対象のIcebergテーブルです。
- 行追跡が有効になっています (
delta.enableRowTracking = true)。Databricks の行追跡を参照してください。 - 予測的最適化が有効になっています。予測的最適化を有効にするを参照してください。
- インデックス付き列は、
STRING、VARIANT、STRUCT、またはARRAYのタイプです。STRING列はUTF8_BINARY照合順序を使用します。 STRUCT列には、任意のネスト深度に少なくとも1つのSTRING、VARIANT、またはARRAYリーフフィールドが含まれています。その他のリーフフィールドは無視されます。- このテーブルは、OpenSharing、シャロークローニング、属性ベースのアクセス制御、行レベルのセキュリティポリシー、および列マスクなど、制限事項のリストにある機能を使用していません。制限事項を参照してください。
Delta LakeとIcebergテーブルの両方に適用されるテーブルプロトコルの要件については、 Delta Lake機能互換性とプロトコルを参照してください。
全文検索インデックスを作成する
1つのテーブルに対して、それぞれ異なる列に最大4つのインデックスを作成できます。
CREATE SEARCH INDEX使用すると、1 つ以上のテキスト列に対してインデックスを作成できます。次の例は、既存のログテーブルの2つのテキスト列にインデックスを作成する例です。
CREATE SEARCH INDEX log_idx
ON logs (message, error_detail);
完全な構文は次のとおりです。
CREATE SEARCH INDEX [IF NOT EXISTS] index_name
ON table_name ( column_name [, column_name ...] )
[OPTIONS ( option_key = option_value [, ... ] )]
index_name スキーマ内で一意である必要があり、既存のテーブル名と一致してはいけません。
テキストのトークン化方法を制御するには、 「オプション」を参照してください。
CREATE SEARCH INDEX が失敗した場合は、再実行してください。
オプション
OPTIONS句は次のキーを受け入れます。
キー | 値 | デフォルト | 説明 |
|---|---|---|---|
|
|
| インデックス作成のためにテキストがどのようにトークン化されるか。ご使用の用途に合ったトークナイザーを選択してください。 |
| 整数 |
| 生成されたn-グラムの長さ。 |
| 整数 |
| 保持するトークンの最小長。これより短いトークンはインデックス作成時に削除されます。 |
無効なオプションエラーに関する詳細情報については、 SEARCH_INDEX_INVALID_PARAMETERS エラー条件を参照してください。
用途に合ったトークナイザーを選択してください
検索インデックスには、使用状況に応じて2つのトークナイザーオプションが用意されています。
トークナイザー | ユースケース | 説明 |
|---|---|---|
| 部分文字列の照合。 | テキストを長さ |
| 単語全体包含チェック。 | テキストを単語トークンに分割します。「勝手」は、Unicode 文字 ( |
n-gramサイズが4のn-gramインデックスを作成するには：
CREATE SEARCH INDEX log_ngram_idx
ON logs (message)
OPTIONS (tokenizer = 'ngram', ngram_size = 4);
最小トークン長が2のsplitインデックスを作成するには：
CREATE SEARCH INDEX log_word_idx
ON logs (message)
OPTIONS (tokenizer = 'split', min_token_length = 2);
searchを使用してデータをクエリし、 isearch
Databricksには、検索パターンが1つ以上のテキストターゲットに存在するかどうかをテストするための2つのSQL関数があります。
search： 大文字と小文字を区別。isearch大文字と小文字は区別されません。
大文字小文字の区別に関する要件に基づいて、 searchまたはisearchを選択してください。インデックス付けされた列が全文検索インデックスでカバーされている場合、Databricks はそのインデックスを使用して、一致する行が含まれていないことが確実なファイルをスキップします。検索インデックスは検索結果に影響を与えません。
インデックスは、検索パターンがテーブルのファイルのごく一部にしか出現しない場合に、クエリの速度を最も向上させます。
search( target [, target ... ] , 'pattern' [, mode => 'substring' | 'word' ] )
isearch( target [, target ... ] , 'pattern' [, mode => 'substring' | 'word' ] )
引数
search および isearch は、次の引数を受け入れます。
target型はSTRING、VARIANT、STRUCT、またはARRAYでなければなりません。これらはインデックス付けで許可されている型と同じです。ターゲットは重複排除されます。patternnull以外の文字列リテラルである必要があります。modepattern各targetにどのように一致するかを指定します。substring（デフォルト）：patternは各target内の部分文字列として一致します。word:patternはsplitトークナイザーと同じルールを使用して単語トークンに分割されます。この関数は、pattern内のすべての単語が、順序に関係なく、少なくとも 1 つのターゲットに含まれている場合に true を返します。ご使用の用途に合ったトークナイザーを選択してください。
戻り値
search そして、 isearch 3値ロジックでBOOLEAN値を返します。
true少なくとも1つのnull以外のターゲットが一致する場合。null非ヌルターゲットが一致しないが、少なくとも1つのターゲットがnullである場合。falseすべてのターゲットがnullではなく、かつ一致するターゲットがない場合。
例
これらの例は、一般的なsearchクエリーとisearchクエリーを示しています。
-- Case-insensitive substring search across one column.
SELECT * FROM logs
WHERE isearch(message, 'connection refused');
-- Case-sensitive substring search across multiple columns.
SELECT * FROM logs
WHERE search(message, error_detail, '550e8400-e29b-41d4-a716-446655440000');
-- Word search: matches rows containing all three words, in any order.
SELECT * FROM audit_logs
WHERE search(message, 'user admin login', mode => 'word');
自動インデックス更新
ベーステーブルが変更されると、予測的最適化によって全文検索インデックスが最新の状態に保たれます。新しい行のエントリを追加し、削除された行のエントリを削除します。更新はバックグラウンドで実行されるため、最近書き込まれたデータがインデックスに登録されるまで時間がかかることがあります。
REFRESH INDEXを手動でランすることはできません。
ベーステーブルで予測的最適化をオフにすると、インデックスの更新が停止します。クエリーは正しいままですが、インデックスでカバーされていないデータをスキャンするため、テーブルの変更に伴って速度が低下します。更新を再開するには、予測的最適化をオンに戻します。
インデックス更新は、Serverlessコンピュート上の予測的最適化操作として実行され、アカウントに請求されます。コンピュートと課金を参照してください。
インデックスの更新を追跡するには、予測的最適化システムテーブルで REFRESH_INDEX 操作タイプをクエリーします。これらの行には、table_nameとtable_idのインデックス名とIDが含まれています。予測的最適化システムテーブルリファレンスを参照してください。
インデックスの管理
Databricksは、インデックスの鮮度に関係なく、クエリの正確性を維持します。テーブルにインデックスのないデータが含まれている場合、クエリは既存のインデックスを使用してインデックス付きレコードへのアクセスを高速化し、インデックスのないレコードについてはテーブルスキャンを使用します。
これらの操作を使用して、全文検索インデックスを管理します：
索引の説明または表示
インデックスに関する情報を表示するには：
DESCRIBE INDEX log_idx;
インデックスを削除する
インデックスを削除するには、次を実行します：
DROP INDEX log_idx;
インデックスが見つからない場合のエラーを回避するには、以下を使用してください。
DROP INDEX IF EXISTS log_idx;
ベーステーブルを削除すると、このコマンドは全文検索インデックスも削除します。
制限事項
全文検索インデックスには、次の制限があります。
- ベーステーブルのインデックス付き列の名前変更、またはデータ型の変更はサポートされていません。
- オープン共有のテーブルはサポートされていません。インデックス作成後にベーステーブルをOpenSharingのソースまたはターゲットとして追加すると、Databricksは検索インデックスを無視します。
- 浅いクローンを持つテーブルはサポートされていません。インデックスの作成後にベース テーブルをシャローク ローン ソースとして追加すると、 Databricks検索インデックスを無視します。
- 属性ベースのアクセス制御、列マスク、または行レベルのセキュリティポリシーを持つテーブルはサポートされていません。検索インデックスを持つテーブルにこれらのコントロールを追加すると、Databricks は検索インデックスを無視します。属性ベースアクセス制御（ABAC）の基本概念を参照してください。