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

インデックスの最適化：プレフィックスインデックスと転置インデックスの活用方法

概要​

Doris のインデックスは、クエリのフィルタリングを高速化するためのデータ構造です。インデックスを適切に使用すると、クエリ性能を大幅に向上できます。

Doris は現在、次の二つのカテゴリのインデックスをサポートしています。

インデックスの分類含まれる種類特徴
組み込みインデックスプレフィックスインデックス、ZoneMap インデックステーブル作成時に自動生成され、追加のメンテナンスは不要
セカンダリインデックス転置インデックス、Bloomfilter インデックス、N-Gram Bloomfilter インデックス、Bitmap インデックス必要に応じてユーザーが作成でき、個別に管理可能

業務に応じてインデックスを効果的に活用すると、クエリと分析の性能を大きく改善できます。インデックスの活用は、性能チューニングの重要な手法の一つです。

各インデックスの詳細については、テーブルインデックスの章を参照してください。この記事では、実際の事例をもとに、典型的なシナリオでのインデックスの使用方法と最適化の推奨事項を紹介します。

読み進める前のチェックリスト​

  • 現在のテーブルで定義されている Key カラムとその順序を理解している
  • 業務で頻繁にフィルタ条件に使用するカラムを特定している
  • テーブルを再構築できるか、セカンダリインデックスの追加しかできないかを確認している
  • 各インデックスの適用場面を把握している

ケース 1：Key カラムの順序を調整し、プレフィックスインデックスでクエリを高速化する​

テーブルスキーマ設計の最適化では、適切なカラムを Key カラムとして選び、Doris の Key カラムのソート機能を使ってクエリを高速化する方法を紹介しました。このケースでは、そのシナリオをさらに詳しく見ていきます。

背景​

Doris にはプレフィックスインデックスが組み込まれています。テーブル作成時に、テーブルの Key の先頭 36 バイトが自動的にプレフィックスインデックスとして使用されます。クエリ条件がプレフィックスインデックスの先頭部分に一致すると、クエリ速度を大幅に向上できます。

問題：Key カラムの順序がクエリパターンと一致しない​

元の CREATE TABLE 文は次のとおりです。

CREATE TABLE `t1` (
  `c1` VARCHAR(10) NULL,
  `c2` VARCHAR(10) NULL
) ENGINE=OLAP
DUPLICATE KEY(`c1`)
DISTRIBUTED BY HASH(`c2`) BUCKETS 10
PROPERTIES (
"replication_allocation" = "tag.location.default: 1"
);

対応する業務 SQL のパターンは次のとおりです。

select * from t1 where t1.c2 = '1';
select * from t1 where t1.c2 in ('1', '2', '3');

上記のスキーマでは c1 が先で c2 が後ですが、クエリは c2 カラムでフィルタリングしています。この場合、プレフィックスインデックスを高速化に活用できません。

最適化：カラムの順序を調整する​

c2 カラムを先頭に配置し、プレフィックスインデックスが業務で使用するフィルタ条件をカバーするようにします。

CREATE TABLE `t1` (
  `c2` VARCHAR(10) NULL,
  `c1` VARCHAR(10) NULL
) ENGINE=OLAP
DUPLICATE KEY(`c2`)
DISTRIBUTED BY HASH(`c1`) BUCKETS 10
PROPERTIES (
"replication_allocation" = "tag.location.default: 1"
);
最適化のヒント

スキーマのカラム順序を定義するときは、業務クエリのフィルタ条件で使用頻度や優先度の高いカラムを考慮し、Doris のプレフィックスインデックスによる高速化を十分に活用してください。

ケース 2：転置インデックスでクエリを高速化する​

適用場面​

Doris はセカンダリインデックスとして転置インデックスをサポートしており、次の業務シナリオの高速化に使用できます。

  • テキスト型カラムの全文検索
  • 文字列型、数値型、日時型カラムの等価クエリ
  • 文字列型、数値型、日時型カラムの範囲クエリ

利点​

転置インデックスは独立して作成・管理できます。元のテーブルスキーマに影響を与えたり、テーブルデータを再インポートしたりせずに、業務クエリの性能を改善できます。

典型的な使用例、構文、サンプルについては、転置インデックスを参照してください。ここでは繰り返しません。

最適化の推奨事項

元のテーブル構造や Key の定義を変更しにくい場合、またはデータの再インポートに大きなコストがかかる場合、転置インデックスは業務クエリの実行性能を改善する柔軟な手段になります。

インデックス選択の比較​

インデックスの種類適用できるクエリテーブルの再構築が必要かデータの再インポートが必要か典型的なカラムの種類
プレフィックスインデックス等価、範囲、プレフィックス一致はい（Key の調整）はい先頭に配置された Key カラム
ZoneMap インデックス範囲フィルタリングいいえ（自動生成）いいえすべてのカラム
転置インデックス全文検索、等価、範囲いいえいいえ文字列型、数値型、日時型
Bloomfilter インデックスカーディナリティの高いカラムでの等価フィルタリングいいえいいえ（段階的に有効になる）文字列型、数値型
N-Gram BloomfilterLIKE によるあいまい検索いいえいいえ（段階的に有効になる）文字列型
Bitmap インデックスカーディナリティの低いカラムでの等価フィルタリングいいえいいえ（段階的に有効になる）列挙値のカラム

FAQ とよくある問題​

Q1：インデックスを作成してもクエリが遅いのはなぜですか？​

考えられる理由は次のとおりです。

  • クエリ条件がインデックス対象のカラムに一致していない
  • Key カラムの順序がフィルタ条件と一致せず、プレフィックスインデックスが機能していない
  • データ量が少なく、インデックスによる効果が目立たない
  • 過去のデータに対してインデックスがまだ有効になっていない（一部のセカンダリインデックスは、新しく書き込まれるデータに対してのみ直ちに有効になります）

Q2：プレフィックスインデックスは手動で作成する必要がありますか？​

いいえ。Doris はテーブル作成時に、Key カラムの先頭 36 バイトを自動的にプレフィックスインデックスとして使用します。プレフィックスインデックスを有効に活用するには、業務で頻繁にフィルタ条件に使用するカラムを Key カラムの先頭に配置してください。

Q3：転置インデックスと Bloomfilter インデックスはどう選びますか？​

  • 全文検索、あいまい検索、範囲クエリには、転置インデックスを優先します
  • カーディナリティの高いカラムでの完全一致クエリには、オーバーヘッドの小さい Bloomfilter インデックスを選びます

Q4：Key カラムの順序を調整するには、テーブルの再構築が必要ですか？​

はい。Key カラムの順序はテーブルスキーマの定義の一部です。順序を調整した後は、テーブルを再構築してデータを再インポートする必要があります。

まとめ​

スキーマのチューニングでは、インデックスの最適化はテーブルレベルのスキーマ最適化と同じくらい重要です。Doris には複数の種類のインデックスがあります。

  • 組み込みインデックス：プレフィックスインデックス、ZoneMap インデックス
  • セカンダリインデックス：転置インデックス、Bloomfilter、N-Gram Bloomfilter、Bitmap

これらのインデックスを適切に使用すると、さまざまなシナリオで業務クエリと分析の速度を大幅に向上できます。まず業務で頻繁に使用するフィルタカラムを確認し、テーブルを再構築できるか、データ量はどの程度かといった要素をもとに、適切なインデックスを選ぶことを推奨します。

Report issue
On This Page