インデックスの紹介
インデックスはデータベースのクエリ高速化における重要な機能です。ユーザーの多様なクエリニーズを十分に満たし、データベースの性能全体を向上させるために、読み取り専用分析エンジンは列ストレージベースのセカンダリインデックス機能を完全にサポートしています。現在、読み取り専用分析エンジンがサポートするインデックスの種類は3つあります:Zonemap Index、Bloom Filter Index、Bitmap Indexです。
通常、高カーディナリティ列かつ低選択率の述語クエリに対してインデックスを構築することで、処理データ量を大幅に削減でき、クエリ速度を著しく最適化できます。
注意:
現在、バージョン2.2410.4.0以降でのみインデックス作成ステートメント機能をサポートしています。また、インデックスの作成にはユーザーがINDEX権限を所有している必要があります。この機能を使用するには、まずアカウントにこの権限を追加してください。
列指向セカンダリインデックス機能は「読み取り専用分析エンジン」でのみ有効です。分析クラスターではこの機能はサポートされていません。
Zonemap Index
Zonemap Indexはシステム組み込みのインデックスに属し、ユーザーが特に意識する必要はありません。各列の統計情報を自動でメンテナンスし、各データブロックについて最大値、最小値、NULLの有無などの情報を記録します。
等値クエリ、範囲クエリ、IS NULLといったシナリオでは、最大値や最小値などの情報を活用して、データファイルやデータブロックが条件を満たすデータを含むかどうかを判断できます。含まれない場合は、対応するファイルやデータブロックをスキップして読み取らずに済みます。この方法により、不要なI/O操作を削減でき、クエリプロセスを効果的に高速化できます。
Bloom Filter Index
Bloom Filter Indexは、Bloom Filterに基づくスキップインデックスの一種です。その原理は、Bloom Filterを活用して等値クエリの指定条件を満たさないデータブロックをスキップし、I/Oを削減してクエリを高速化することです。
ブルームフィルタは、1970年にBloomによって提案された複数のハッシュ関数を用いた高速検索アルゴリズムです。通常、ある要素が集合に属するかどうかを迅速に判断する必要があるが、100%正確であることが厳密に要求されないシナリオに適用されます。ブルームフィルタには以下の特徴があります:
空間効率に優れた確率的データ構造であり、ある要素が集合に属しているかどうかを確認するために使用されます。
ブルームフィルタは、ある要素の存在確認クエリに対して、「存在する可能性がある」または「絶対に存在しない」のいずれかの結果を返します。
適用シーン
Bloom Filter Indexは等値クエリ(= および IN を含む)を高速化でき、高カーディナリティのフィールドに対して効果が比較的良好です。
制限条件
ブルームフィルタインデックスは、= および IN 以外のクエリ(例:!=、NOT IN、>、< など)には効果がありません。
Bloom Filter Indexは、最大長256のINT型、String型、最大長256のDecimal型、Time、Date、DateTimeフィールド型のみサポートします。
式に対するインデックスの作成も、複数列の複合インデックスもサポートしていません。
単一の主キー列、または複数フィールドの複合主キーの最初の列は、Bloom Filter Indexの作成をサポートしていません。
インデックスを使用する
SQL実行時に、where条件内の等値述語またはIN述語のフィールドにBloom Filter Indexが作成されている場合、クエリ時に自動的にインデックスを適用して検索を高速化します。
関連コマンド
インデックス作成ステートメント
CREATE INDEX IF NOT EXISTS インデックス名 USING BLOOM_FILTER ON テーブル名(列名);
インデックス削除ステートメント
DROP INDEX インデックス名 ON テーブル名;
インデックスクエリステートメント
Bitmap Index
ビットマップインデックスはビットマップで表現されるインデックスであり、列の各キー値に対してビットマップを構築します。他のインデックスと比較して、ビットマップインデックスの利点は占有ストレージスペースが非常に小さく、作成と使用が非常に高速であることです。欠点は更新操作のロック粒度が大きく、更新頻度の高いシナリオには適さないことです。
適用シーン
重複度の高い列に設定するのが適しており、100~100000の範囲が推奨されます(例:職業、県レベル市など)。重複度が高すぎると他のタイプのインデックスと比べて明確な優位性がなく、重複度が低すぎると空間効率とパフォーマンスが大幅に低下します。
特定のタイプのクエリ、例えばcount、or、andなどの論理操作は、ビット演算のみで実行されます。例えば:複数の条件を組み合わせたクエリ、select count(*) from table where city = '南京市' and job = '医師' and Type = 'iphone' and gender ='男性'。このようなシナリオでは、各クエリ条件列にBitmap Indexが構築されている場合、データベースは効率的なビット演算を実行でき、必要なデータを正確に特定し、ディスクI/Oを削減できます。また、結果セットが小さいほど、Bitmap Indexの優位性がより顕著になります。
アドホッククエリや多次元分析などの分析シナリオに適しています。あるテーブルに100列あり、ユーザーがそのうちの20列をクエリ条件として使用する場合(この20列の任意のN列を使用)、これらの列に20個のBitmap Indexを作成すると、すべてのクエリでインデックスを適用できます。
非対応シナリオ
重複度が低い列、例えば:身分証番号、携帯電話番号など。
重複度が高い列(例:性別)にはBitmap Indexを構築できますが、単独のクエリ条件として使用することは推奨されず、他の条件と共同でフィルタリングすることをお勧めします。
頻繁に更新や変更が必要なカラム。
制限条件
ビットマップインデックスは、=、!=、>、<、>=、<=、in、is null、is not null などの式をサポートしますが、複数の述語間はand接続のみ可能です。
ビットマップインデックスは、最大長256のINT型、String型、最大長256のDecimal型、Time、Date、DateTimeフィールドタイプのみサポートします。
式に対するインデックスの作成も、複数列の複合インデックスもサポートしていません。
単一の主キー列、または複数フィールドの複合主キーの最初の列は、Bitmap Indexの作成をサポートしていません。
関連コマンド
インデックス作成ステートメント
CREATE INDEX IF NOT EXISTS インデックス名 USING BITMAP ON テーブル名(列名);
インデックス削除ステートメント
DROP INDEX インデックス名 ON テーブル名;
インデックスクエリステートメント