メインコンテンツまでスキップ
に最終更新

Unity Catalogマネージドテーブルのセカンダリインデックス

備考

ベータ版

この機能はベータ版です。ワークスペース管理者は、 プレビュー ページからこの機能へのアクセスを制御できます。Databricksのプレビューを管理するを参照してください。

セカンダリインデックスを使用すると、管理対象のDelta LakeテーブルまたはIcebergテーブルの列に対する選択的な検索が高速化されます。Databricksのクエリエンジンは、セカンダリインデックスが有効であると判断した場合、自動的にそのインデックスを使用して、一致するデータを含まないファイルや行をスキップします。インデックスを使用することで、大規模なテーブルのスキャンデータ量を大幅に削減できる可能性があります。

セカンダリ インデックスは、データの物理レイアウトを整理する液体クラスタリングを補完します。 セカンダリインデックスを使用すると、テーブルの物理的なレイアウトを変更することなく、クエリの最適化をさらに進めることができます。これは、ワークロードにおいてクラスタリングキーに含まれていない列に対して選択的なルックアップが必要な場合に役立ちます。

重要

ベータ版で作成されたインデックスは、それ以降のリリースで作成されたインデックスとは互換性がありません。この機能がパブリックプレビュー段階に達したら、既存のインデックスを削除し、新しいインデックスを作成する必要があります。

要件​

セカンダリ インデックスには、コンピュート、ベース テーブルとスキーマのアクセス許可、およびベース テーブルの構成に関する要件があります。

コンピュート​

セカンダリインデックスはDatabricks Runtime 18.2以降でのみ利用可能であり、ワークスペース設定でこのベータ版機能を有効にする必要があります。Databricksのプレビューを管理するを参照してください。

権限​

セカンダリインデックスを作成するには：

  • インデックスで参照されているテーブルに対して、 MODIFY権限が必要です。
  • 親スキーマに対してCREATE TABLE権限が必要です。スキーマの所有者、またはMANAGE権限を持つユーザーは、あなたにスキーマに対するCREATE TABLE権限を付与できます。

テーブル構成​

セカンダリインデックスを作成する前に、ベーステーブルは以下のすべての条件を満たしている必要があります。

  • インデックスは、ベーステーブルと同じカタログおよびスキーマ内に作成する必要があります。
  • このテーブルは、管理対象のDelta Lakeテーブル、または管理対象のIcebergテーブルです。
  • 行追跡が有効になっています ( delta.enableRowTracking = true )。Databricks の行追跡を参照してください。
  • インデックスを作成する列は、サポートされているデータ型（数値型、 STRING 、 CHAR(n) 、 VARCHAR(n) 、またはTIMESTAMPである必要があります。
  • このテーブルは、 Delta Sharing 、シャロークローニング、属性ベースのアクセス制御、行レベルのセキュリティ、 および列マスクなど、制限事項のリストにある機能を使用していません。 制限事項を参照してください。

Delta LakeとIcebergテーブルの両方に適用されるテーブルプロトコルの要件については、 Delta Lake機能互換性とプロトコル」を参照してください。

セカンダリインデックスを作成する​

1つのテーブルに対して、それぞれ異なる列に最大4つのインデックスを作成できます。4つのインデックスという制限は、二次インデックスと全文検索インデックスの両方に共通しています。Unity Catalogマネージドテーブルの全文検索インデックスを参照してください。

単一の列にセカンダリ インデックスを作成するには、 CREATE INDEX使用します。たとえば、既存のテーブルeventsのuser_id列に作成します。

SQL
CREATE INDEX user_id_idx
ON events (user_id);

完全な構文は次のとおりです。

SQL
CREATE INDEX [IF NOT EXISTS] index_name
  ON table_name ( column_name )

index_name 親スキーマ内で一意である必要があり、既存のテーブル名と一致してはいけません。

警告

CREATE INDEXまたはREFRESH INDEX実行途中で失敗した場合は、 REFRESH INDEXを実行して部分的な失敗から回復します。

セカンダリインデックスを使用してデータをクエリする​

テーブルにセカンダリインデックスが存在する場合、Databricksクエリエンジンは自動的にそれを利用して、インデックス付き列に対する選択的述語を含むクエリを高速化します。

サポートされている述語タイプは次のとおりです。

  • 平等： =
  • メンバーシップを設定する: IN

例えば、列user_idにuser_id_idxセカンダリ インデックスがある場合、そのインデックスは特定のユーザーの検索を実行するクエリを高速化します。

SQL
SELECT * FROM events
WHERE user_id = '019982fe-002a-7621-8c20-b332eeb71f44';

インデックスの管理​

重要

ベーステーブルが変更されても、セカンダリインデックスは自動的に更新されません。インデックスの更新を参照してください。

Databricksは、インデックスの鮮度に関係なく、クエリの正確性を維持します。テーブルにインデックスのないデータが含まれている場合、クエリは既存のインデックスを使用してインデックス付きレコードへのアクセスを高速化し、インデックスのないレコードについてはテーブルスキャンを使用します。

セカンダリインデックスを管理するには、以下の操作を使用します。

索引の説明または表示​

インデックスに関する情報を表示するには：

SQL
DESCRIBE INDEX user_id_idx;

インデックスを更新する​

ベーステーブルが変更されても、セカンダリインデックスは自動的に更新されません。

インデックスを更新するには、新しい行のエントリを追加します。

SQL
REFRESH INDEX user_id_idx;

REFRESH INDEX これは、増分的な追記専用操作です。新しいデータはインデックス化されますが、削除された行のエントリは削除されません。

インデックスを更新するには、新しい行のエントリを追加し、削除された行のエントリを削除するために、 REFRESH INDEX ... FULL使用します。

SQL
REFRESH INDEX user_id_idx FULL;

完全な更新には、増分更新よりも多くのコンピュート リソースが必要です。 時間の経過とともに、増分更新によって古いエントリが蓄積され、インデックスのサイズが大きくなり、パフォーマンスに悪影響を及ぼします。

インデックスをドロップする​

インデックスを削除するには、次のコマンドを実行します。

SQL
DROP INDEX user_id_idx;

インデックスが見つからない場合のエラーを回避するには、以下を使用してください。

SQL
DROP INDEX IF EXISTS user_id_idx;
注記

ベーステーブルを削除すると、このコマンドはセカンダリインデックスも削除します。

制限事項​

二次索引には以下の制約があります。

  • ベーステーブルのインデックス付き列の名前を変更したり、データ型を変更したりすることはできません。その代わりに、インデックスを削除し、列を変更してから、インデックスを再作成する必要があります。
  • Delta Sharingを持つテーブルはサポートされていません。 インデックス作成後にベーステーブルをDelta Sharingソースまたはターゲットとして追加すると、 Databricksセカンダリインデックスを無視します。
  • 浅いクローンを持つテーブルはサポートされていません。インデックス作成後にベーステーブルをシャロークローンソースとして追加した場合、Databricksはセカンダリインデックスを無視します。
  • 属性ベースのアクセス制御、列マスク、または行レベルのセキュリティポリシーを持つテーブルはサポートされていません。これらのコントロールのいずれかをセカンダリインデックスを持つテーブルに追加すると、Databricks はセカンダリインデックスを無視します。属性ベースアクセス制御（ABAC）の基本概念を参照してください。
このページの見出し