メインコンテンツまでスキップ
バージョン: 3.1

ビットマップインデックス

このトピックでは、ビットマップインデックスの作成と管理方法、および使用例について説明します。

はじめに​

ビットマップインデックスは、ビットマップ（ビットの配列）を使用する特別なデータベースインデックスです。ビットは常に2つの値のいずれか（0または1）を持ちます。ビットマップの各ビットはテーブル内の1行に対応しています。各ビットの値は、対応する行の値に依存します。

ビットマップインデックスは、特定の列のクエリパフォーマンスを向上させるのに役立ちます。クエリのフィルタ条件がプレフィックスインデックスに一致する場合、クエリの効率を大幅に向上させ、迅速に結果を返すことができます。ただし、テーブルには1つのプレフィックスインデックスしか持てません。クエリのフィルタ条件にプレフィックスインデックスのプレフィックスが含まれていない場合、その列に対してビットマップインデックスを作成してクエリの効率を向上させることができます。

クエリを高速化するためのビットマップインデックスの設計方法​

ビットマップインデックスを選択する際の主な考慮事項は、列の基数とクエリに対するビットマップインデックスのフィルタリング効果です。一般的な認識とは異なり、StarRocksのビットマップインデックスは、高基数の列に対するクエリや、複数の低基数列の組み合わせに対するクエリにより適しています。さらに、ビットマップインデックスはデータを効果的にフィルタリングし、少なくともデータの999/1000をフィルタリングすることで、読み込むページデータの量を減らすことができます。

単一の低基数列に対するクエリの場合、ビットマップインデックスのフィルタリング効果は低く、多くの行を読み込む必要があり、複数のページに分散されます。

備考

ビットマップインデックスがクエリに与えるフィルタリング効果を評価する際には、データロードのコストを考慮する必要があります。StarRocksでは、基礎データはページ（デフォルトサイズは64K）で整理され、ロードされます。データロードのコストには、ディスクからページをロードする時間、ページを解凍する時間、デコードする時間が含まれます。

ただし、基数が過度に高いと、ディスクスペースを多く占有するなどの問題が発生する可能性があります。また、ビットマップインデックスはデータロード中に構築する必要があるため、頻繁なデータロードはロードパフォーマンスに影響を与える可能性があります。

さらに、クエリ中のビットマップインデックスのロードオーバーヘッドも考慮する必要があります。クエリ中にビットマップインデックスは必要に応じてロードされ、クエリ条件に関与する列の値の数/基数 x ビットマップインデックスの値が大きいほど、クエリ中のビットマップインデックスのロードオーバーヘッドが大きくなります。

ビットマップインデックスに適した基数とクエリ条件を決定するには、このトピックのビットマップインデックスのパフォーマンステストを参照してパフォーマンステストを実施することをお勧めします。実際のビジネスデータとクエリを使用して、異なる基数の列にビットマップインデックスを作成し、クエリに対するビットマップインデックスのフィルタリング効果（少なくともデータの999/1000をフィルタリング）、ディスクスペースの使用量、ロードパフォーマンスへの影響、クエリ中のビットマップインデックスのロードオーバーヘッドを分析することができます。

StarRocksには、ビットマップインデックスの適応選択メカニズムが組み込まれています。ビットマップインデックスがクエリを加速できない場合、例えば、多くのページをフィルタリングできない場合や、クエリ中のビットマップインデックスのロードオーバーヘッドが高い場合、クエリ中に使用されないため、クエリパフォーマンスに大きな影響を与えることはありません。

ビットマップインデックスの適応選択​

StarRocksは、列の基数とクエリ条件に基づいてビットマップインデックスを使用するかどうかを適応的に選択できます。ビットマップインデックスが多くのページを効果的にフィルタリングできない場合や、クエリ中のビットマップインデックスのロードオーバーヘッドが高い場合、StarRocksはデフォルトでビットマップインデックスを使用しないため、クエリパフォーマンスの低下を避けることができます。

StarRocksは、クエリ条件に関与する値の数と列の基数の比率に基づいてビットマップインデックスを使用するかどうかを判断します。一般に、この比率が小さいほど、ビットマップインデックスのフィルタリング効果が良好です。したがって、StarRocksはbitmap_max_filter_ratio/1000をしきい値として使用します。フィルタ条件の値の数/列の基数がbitmap_max_filter_ratio/1000未満の場合、ビットマップインデックスが使用されます。bitmap_max_filter_ratioのデフォルト値は1です。

単一の列に基づくクエリの例を挙げると、SELECT * FROM employees WHERE gender = 'male';のようなものがあります。employeesテーブルのgender列にはmaleとfemaleの値があるため、基数は2（2つの異なる値）です。クエリ条件には1つの値が含まれているため、比率は1/2であり、1/1000より大きいです。したがって、このクエリではビットマップインデックスは使用されません。

複数の列の組み合わせに基づくクエリの例を挙げると、SELECT * FROM employees WHERE gender = 'male' AND city IN ('Beijing', 'Shanghai');のようなものがあります。city列の基数は10,000であり、クエリ条件には2つの値が含まれているため、比率は(1*2)/(2*10000)として計算され、1/1000未満です。したがって、このクエリではビットマップインデックスが使用されます。

備考

bitmap_max_filter_ratioの値の範囲は1-1000です。bitmap_max_filter_ratioが1000に設定されている場合、ビットマップインデックスを持つ列に対するクエリは強制的にビットマップインデックスを使用します。

利点​

  • ビットマップインデックスは、クエリされた列の値の行番号を迅速に特定でき、ポイントクエリや小範囲のクエリに適しています。
  • ビットマップインデックスは、ユニオンおよびインターセクション操作（ORおよびAND操作）を含む多次元クエリを最適化できます。

考慮事項​

最適化できるクエリ​

ビットマップインデックスは、等価=クエリ、[NOT] IN範囲クエリ、>, >=, <, <=クエリ、およびIS NULLクエリを最適化するのに適しています。!=および[NOT] LIKEクエリの最適化には適していません。

サポートされている列とデータ型​

ビットマップインデックスは、プライマリキーテーブルおよび重複キーテーブルのすべての列、および集計テーブルおよびユニークキーテーブルのキー列に作成できます。ビットマップインデックスは、次のデータ型の列に作成できます。

  • 日付型: DATE, DATETIME.
  • 数値型: TINYINT, SMALLINT, INT, BIGINT, LARGEINT, DECIMAL, BOOLEAN.
  • 文字列型: CHAR, STRING, VARCHAR.
  • その他の型: HLL.

基本操作​

インデックスの作成​

  • テーブル作成時にビットマップインデックスを作成します。

    CREATE TABLE `lineorder_partial` (
      `lo_orderkey` int(11) NOT NULL COMMENT "",
      `lo_orderdate` int(11) NOT NULL COMMENT "",
      `lo_orderpriority` varchar(16) NOT NULL COMMENT "",
      `lo_quantity` int(11) NOT NULL COMMENT "",
      `lo_revenue` int(11) NOT NULL COMMENT "",
       INDEX lo_orderdate_index (lo_orderdate) USING BITMAP
    ) ENGINE=OLAP 
    DUPLICATE KEY(`lo_orderkey`)
    DISTRIBUTED BY HASH(`lo_orderkey`) BUCKETS 1;

    この例では、lo_orderdate列にlo_orderdate_indexという名前のビットマップインデックスが作成されています。ビットマップインデックスの命名要件については、システム制限を参照してください。同一のビットマップインデックスを同じテーブル内で作成することはできません。

    複数の列に対して複数のビットマップインデックスを作成することができ、カンマ（,）で区切られます。

    注記

    テーブル作成の詳細なパラメータについては、CREATE TABLEを参照してください。

  • テーブル作成後にビットマップインデックスを作成するには、CREATE INDEXを使用します。詳細なパラメータの説明と例については、CREATE INDEXを参照してください。

    CREATE INDEX lo_quantity_index ON lineorder_partial (lo_quantity) USING BITMAP;

インデックス作成の進捗​

ビットマップインデックスの作成は非同期プロセスです。インデックス作成ステートメントを実行した後、SHOW ALTER TABLEコマンドを使用してインデックス作成の進捗を確認できます。返された値のStateフィールドがFINISHEDを示している場合、インデックスは正常に作成されています。

SHOW ALTER TABLE COLUMN;
備考

各テーブルには、同時に1つの進行中のスキーマ変更タスクしか持てません。現在のビットマップインデックスが作成されるまで、新しいビットマップインデックスを作成することはできません。

インデックスの表示​

指定されたテーブルのすべてのビットマップインデックスを表示します。詳細なパラメータと返される結果については、SHOW INDEXを参照してください。

SHOW INDEXES FROM lineorder_partial;
注記

ビットマップインデックスの作成は非同期プロセスです。上記のステートメントを使用して、正常に作成されたインデックスのみを表示できます。

インデックスの削除​

指定されたテーブルのビットマップインデックスを削除します。詳細なパラメータと例については、DROP INDEXを参照してください。

DROP INDEX lo_orderdate_index ON lineorder_partial;

ビットマップインデックスがクエリを高速化するかどうかを確認する​

クエリプロファイルのBitmapIndexFilterRowsフィールドを確認します。プロファイルの表示方法については、クエリ分析を参照してください。

ビットマップインデックスのパフォーマンステスト​

テストの目的​

異なる基数のクエリに対するビットマップインデックスのフィルタリング効果やディスク使用量などの影響を分析するために：

このセクションでは、ビットマップインデックスを常に使用する場合と、ビットマップインデックスを適応的に使用する場合のパフォーマンスを比較し、StarRocksのビットマップインデックスの適応選択の有効性を検証します。

テーブルとビットマップインデックスの作成​

警告

ページデータのキャッシュがクエリパフォーマンスに影響を与えないようにするため、BE構成項目disable_storageがtrueに設定されていることを確認してください。

このセクションでは、lineorder（SSB 20G）テーブルを例にとります。

  • 参照用のオリジナルテーブル（ビットマップインデックスなし）

    CREATE TABLE `lineorder_without_index` (
    `lo_orderkey` int(11) NOT NULL COMMENT "",
    `lo_linenumber` int(11) NOT NULL COMMENT "",
    `lo_custkey` int(11) NOT NULL COMMENT "",
    `lo_partkey` int(11) NOT NULL COMMENT "",
    `lo_suppkey` int(11) NOT NULL COMMENT "",
    `lo_orderdate` int(11) NOT NULL COMMENT "",
    `lo_orderpriority` varchar(16) NOT NULL COMMENT "",
    `lo_shippriority` int(11) NOT NULL COMMENT "",
    `lo_quantity` int(11) NOT NULL COMMENT "",
    `lo_extendedprice` int(11) NOT NULL COMMENT "",
    `lo_ordtotalprice` int(11) NOT NULL COMMENT "",
    `lo_discount` int(11) NOT NULL COMMENT "",
    `lo_revenue` int(11) NOT NULL COMMENT "",
    `lo_supplycost` int(11) NOT NULL COMMENT "",
    `lo_tax` int(11) NOT NULL COMMENT "",
    `lo_commitdate` int(11) NOT NULL COMMENT "",
    `lo_shipmode` varchar(11) NOT NULL COMMENT ""
    ) ENGINE=OLAP 
    DUPLICATE KEY(`lo_orderkey`)
    DISTRIBUTED BY HASH(`lo_orderkey`) BUCKETS 1;

  • ビットマップインデックスを持つテーブル: lo_shipmode, lo_quantity, lo_discount, lo_orderdate, lo_tax, lo_partkeyに基づいてビットマップインデックスを作成。

    CREATE TABLE `lineorder_with_index` (
      `lo_orderkey` int(11) NOT NULL COMMENT "",
      `lo_linenumber` int(11) NOT NULL COMMENT "",
      `lo_custkey` int(11) NOT NULL COMMENT "",
      `lo_partkey` int(11) NOT NULL COMMENT "",
      `lo_suppkey` int(11) NOT NULL COMMENT "",
      `lo_orderdate` int(11) NOT NULL COMMENT "",
      `lo_orderpriority` varchar(16) NOT NULL COMMENT "",
      `lo_shippriority` int(11) NOT NULL COMMENT "",
      `lo_quantity` int(11) NOT NULL COMMENT "",
      `lo_extendedprice` int(11) NOT NULL COMMENT "",
      `lo_ordtotalprice` int(11) NOT NULL COMMENT "",
      `lo_discount` int(11) NOT NULL COMMENT "",
      `lo_revenue` int(11) NOT NULL COMMENT "",
      `lo_supplycost` int(11) NOT NULL COMMENT "",
      `lo_tax` int(11) NOT NULL COMMENT "",
      `lo_commitdate` int(11) NOT NULL COMMENT "",
      `lo_shipmode` varchar(11) NOT NULL COMMENT "",
      INDEX i_shipmode (`lo_shipmode`) USING BITMAP,
      INDEX i_quantity (`lo_quantity`) USING BITMAP,
      INDEX i_discount (`lo_discount`) USING BITMAP,
      INDEX i_orderdate (`lo_orderdate`) USING BITMAP,
      INDEX i_tax (`lo_tax`) USING BITMAP,
      INDEX i_partkey (`lo_partkey`) USING BITMAP
    ) ENGINE=OLAP 
    DUPLICATE KEY(`lo_orderkey`)
    DISTRIBUTED BY HASH(`lo_orderkey`) BUCKETS 1;

ビットマップインデックスのディスクスペース使用量​

  • lo_shipmode: 文字列型、基数7、130Mを占有
  • lo_quantity: 整数型、基数50、291Mを占有
  • lo_discount: 整数型、基数11、198Mを占有
  • lo_orderdate: 整数型、基数2406、191Mを占有
  • lo_tax: 整数型、基数9、160Mを占有
  • lo_partkey: 整数型、基数600,000、601Mを占有

クエリ1: 低基数の単一列に対するクエリ​

ビットマップインデックスなしのテーブルに対するクエリ​

クエリ:

SELECT count(1) FROM lineorder_without_index WHERE lo_shipmode="MAIL";

クエリパフォーマンス分析: クエリされたテーブルにはビットマップインデックスがないため、lo_shipmode列のデータを含むすべてのページを読み込み、述語フィルタリングを適用する必要があります。

総時間: 約0.91ミリ秒、データロードに0.47ミリ秒、低基数最適化のための辞書デコードに0.31ミリ秒、述語フィルタリングに0.23ミリ秒。

PullRowNum: 20.566M (20566493) // 結果セットの行数。
CompressedBytesRead: 55.283 MB // 読み込まれたデータの総量。
RawRowsRead: 143.999M (143999468) // 読み込まれた行数。ビットマップインデックスがないため、この列のすべてのデータが読み込まれます。
ReadPagesNum: 8.795K (8795) // 読み込まれたページ数。ビットマップインデックスがないため、この列のデータを含むすべてのページが読み込まれます。
IOTaskExecTime: 914ms // データスキャンの総時間。
    BlockFetch: 469ms // データロードの時間。
    DictDecode: 311.612ms // 低基数最適化のための辞書デコードの時間。
    PredFilter: 23.182ms // 述語フィルタリングの時間。
    PredFilterRows: 123.433M (123432975) // フィルタリングされた行数。

ビットマップインデックスを持つテーブルに対するクエリ​

ビットマップインデックスを強制的に使用​
備考

StarRocksの設定に従ってビットマップインデックスを強制的に使用するには、各BEノードのbe.confファイルでbitmap_max_filter_ratio=1000を設定し、BEノードを再起動する必要があります。

クエリ:

SELECT count(1) FROM lineorder_with_index WHERE lo_shipmode="MAIL";

クエリパフォーマンス分析: クエリされた列は低基数であるため、ビットマップインデックスはデータを効率的にフィルタリングできません。ビットマップインデックスは実際のデータの行番号を迅速に特定できますが、多くの行を読み込む必要があり、複数のページに分散されます。その結果、読み込む必要のあるページを効果的にフィルタリングできません。さらに、ビットマップインデックスのロードとデータフィルタリングのための追加のオーバーヘッドが発生し、総時間が長くなります。

総時間: 2.7秒、データとビットマップインデックスのロードに0.93秒、低基数最適化のための辞書デコードに0.33秒、ビットマップインデックスによるデータフィルタリングに0.42秒、ZoneMapインデックスによるデータフィルタリングに0.17秒。

PullRowNum: 20.566M (20566493) // 結果セットの行数。
CompressedBytesRead: 72.472 MB // 読み込まれたデータの総量。この列のビットマップインデックスのサイズは130MBで、7つのユニークな値があります。各値のビットマップインデックスのサイズは18MBです。ページのデータサイズは55MB = 73MBです。
RawRowsRead: 20.566M (20566493) // 読み込まれた行数。実際には2000万行が読み込まれます。
ReadPagesNum: 8.802K (8802) // 読み込まれたページ数。ビットマップインデックスによってフィルタリングされた2000万行は異なるページにランダムに分散されているため、すべてのページが読み込まれます。ページは最小のデータ読み込み単位です。したがって、ビットマップインデックスはページをフィルタリングしません。
IOTaskExecTime: 2s77ms // データスキャンの総時間。ビットマップインデックスなしよりも長い。
    BlockFetch: 931.144ms // データとビットマップインデックスのロード時間。前のクエリと比較して、ビットマップインデックス（18MB）のロードに400ms追加で費やされました。
    DictDecode: 329.696ms // 低基数最適化のための辞書デコードの時間は、出力行数が同じであるため、似ています。
    BitmapIndexFilter: 419.308ms // ビットマップインデックスによるデータフィルタリングの時間。
    BitmapIndexFilterRows: 123.433M (123432975) // ビットマップインデックスによってフィルタリングされた行数。
    ZoneMapIndexFiter: 171.580ms // ZoneMapインデックスによるデータフィルタリングの時間。
StarRocksのデフォルト設定に基づいてビットマップインデックスを使用するかどうかを判断​

クエリ:

SELECT count(1) FROM lineorder_with_index WHERE lo_shipmode="MAIL";

クエリパフォーマンス分析: StarRocksのデフォルト設定によれば、フィルタ条件列のユニークな値の数/列の基数 < bitmap_max_filter_ratio/1000（デフォルトは1/1000）の場合にビットマップインデックスが使用されます。この場合、値は1/1000より大きいため、ビットマップインデックスは使用されず、ビットマップインデックスなしのテーブルをクエリする場合と同様のパフォーマンスになります。

PullRowNum: 20.566M (20566493) // 結果セットの行数。
CompressedBytesRead: 55.283 MB // 読み込まれたデータの総量。
RawRowsRead: 143.999M (143999468) // 読み込まれた行数。ビットマップインデックスが使用されていないため、この列のすべてのデータが読み込まれます。
ReadPagesNum: 8.800K (8800) // 読み込まれたページ数。ビットマップインデックスが使用されていないため、この列のデータを含むすべてのページが読み込まれます。
IOTaskExecTime: 914.279ms // データスキャンの総時間。
    BlockFetch: 475.890ms // データロードの時間。
    DictDecode: 312.019ms // 低基数最適化のための辞書デコードの時間。
    PredFilterRows: 123.433M (123432975) // 述語によってフィルタリングされた行数。

クエリ2: 低基数の複数列の組み合わせに対するクエリ​

ビットマップインデックスなしのテーブルに対するクエリ​

クエリ:

SELECT count(1) 
FROM lineorder_without_index 
WHERE lo_shipmode = "MAIL" 
  AND lo_quantity = 10 
  AND lo_discount = 9 
  AND lo_tax = 8;

クエリパフォーマンス分析: クエリされたテーブルにはビットマップインデックスがないため、lo_shipmode、lo_quantity、lo_discount、lo_tax列のデータを含むすべてのページを読み込み、述語フィルタリングを適用する必要があります。

総時間: 1.76秒、データロードに1.6秒（4列）、述語フィルタリングに0.1秒。

PullRowNum: 4.092K (4092) // 結果セットの行数。
CompressedBytesRead: 305.346 MB // 読み込まれたデータの総量。4列のデータが読み込まれ、合計305MB。
RawRowsRead: 143.999M (143999468) // 読み込まれた行数。ビットマップインデックスがないため、これら4列のすべてのデータが読み込まれます。
ReadPagesNum: 35.168K (35168) // 読み込まれたページ数。ビットマップインデックスがないため、これら4列のデータを含むすべてのページが読み込まれます。
IOTaskExecTime: 1s761ms // データスキャンの総時間。
    BlockFetch: 1s639ms // データロードの時間。
    PredFilter: 96.533ms // 4つのフィルタ条件を持つ述語フィルタリングの時間。
    PredFilterRows: 143.995M (143995376) // 述語によってフィルタリングされた行数。

ビットマップインデックスを持つテーブルに対するクエリ​

ビットマップインデックスを強制的に使用​
備考

StarRocksの設定に従ってビットマップインデックスを強制的に使用するには、各BEノードのbe.confファイルでbitmap_max_filter_ratio=1000を設定し、BEノードを再起動する必要があります。

クエリ:

SELECT count(1) FROM lineorder_with_index WHERE lo_shipmode="MAIL" AND lo_quantity=10 AND lo_discount=9 AND lo_tax=8;

クエリパフォーマンス分析: これは複数の低基数列に基づく組み合わせクエリであるため、ビットマップインデックスは効果的であり、ページの一部をフィルタリングし、データ読み取り時間を大幅に短縮します。

総時間: 0.68秒、データとビットマップインデックスのロードに0.54秒、ビットマップインデックスによるデータフィルタリングに0.14秒。

PullRowNum: 4.092K (4092) // 結果セットの行数。
CompressedBytesRead: 156.340 MB // 読み込まれたデータの総量。ビットマップインデックスはデータの2/3を効果的にフィルタリングします。この156MBのうち、60MBはインデックスデータで、90MBは実際のデータです。
ReadPagesNum: 11.325K (11325) // 読み込まれたページ数。ビットマップインデックスはページの2/3を効果的にフィルタリングします。
IOTaskExecTime: 683.471ms // データスキャンの総時間。ビットマップインデックスなしよりも大幅に短い。
    BlockFetch: 537.421ms // データとビットマップインデックスのロード時間。ビットマップインデックスのロードに追加の時間がかかりますが、データロード時間を大幅に短縮します。
    BitmapIndexFilter: 139.024ms // ビットマップインデックスによるデータフィルタリングの時間。
    BitmapIndexFilterRows: 143.995M (143995376) // ビットマップインデックスによってフィルタリングされた行数。
StarRocksのデフォルト設定に基づいてビットマップインデックスを使用するかどうかを判断​

クエリ:

SELECT count(1) FROM lineorder_with_index WHERE lo_shipmode="MAIL" AND lo_quantity=10 AND lo_discount=9 AND lo_tax=8;

クエリパフォーマンス分析: StarRocksのデフォルト設定によれば、フィルタ条件列のユニークな値の数/列の基数 < bitmap_max_filter_ratio/1000（デフォルトは1/1000）の場合にビットマップインデックスが使用されます。この場合、値は1/1000未満であるため、ビットマップインデックスが使用され、ビットマップインデックスを強制的に使用する場合と同様のパフォーマンスになります。

総時間: 0.67秒、データとビットマップインデックスのロードに0.54秒、ビットマップインデックスによるデータフィルタリングに0.13秒。

PullRowNum: 4.092K (4092) // 結果セットの行数。
CompressedBytesRead: 154.430 MB // 読み込まれたデータの総量。
ReadPagesNum: 11.209K (11209) // 読み込まれたページ数。
IOTaskExecTime: 672.029ms // データスキャンの総時間。ビットマップインデックスなしよりも大幅に短い。
    BlockFetch: 535.823ms // データとビットマップインデックスのロード時間。ビットマップインデックスのロードに少し時間がかかりますが、データロード時間を大幅に短縮します。
    BitmapIndexFilter: 128.403ms // ビットマップインデックスによるデータフィルタリングの時間。
    BitmapIndexFilterRows: 143.995M (143995376) // ビットマップインデックスによってフィルタリングされた行数。

クエリ3: 高基数の単一列に対するクエリ​

ビットマップインデックスなしのテーブルに対するクエリ​

クエリ:

select count(1) from lineorder_without_index where lo_partkey=10000;

クエリパフォーマンス分析: クエリされたテーブルにはビットマップインデックスがないため、lo_partkey列のデータを含むページを読み込み、述語フィルタリングを適用する必要があります。

総時間: 約0.43秒、データロードに0.39秒、述語フィルタリングに0.02秒。

PullRowNum: 255 // 結果セットの行数。
CompressedBytesRead: 344.532 MB // 読み込まれたデータの総量。
RawRowsRead: 143.999M (143,999,468) // 読み込まれた行数。ビットマップインデックスがないため、この列のすべてのデータが読み込まれます。
ReadPagesNum: 8.791K (8,791) // 読み込まれたページ数。ビットマップインデックスがないため、この列のすべてのデータが読み込まれます。
IOTaskExecTime: 428.258ms // データスキャンの総時間。
    BlockFetch: 392.434ms // データロードの時間。
    PredFilter: 20.807ms // 述語フィルタリングの時間。
    PredFilterRows: 143.999M (143,999,213) // 述語によってフィルタリングされた行数。

ビットマップインデックスを持つテーブルに対するクエリ​

ビットマップインデックスを強制的に使用​
備考

StarRocksの設定に従ってビットマップインデックスを強制的に使用するには、各BEノードのbe.confファイルでbitmap_max_filter_ratio=1000を設定し、BEノードを再起動する必要があります。

クエリ:

SELECT count(1) FROM lineorder_with_index WHERE lo_partkey=10000;

クエリパフォーマンス分析: クエリされた列は高基数であるため、ビットマップインデックスは効果的であり、ページの一部をフィルタリングし、データ読み取り時間を大幅に短縮します。

総時間: 0.015秒、データとビットマップインデックスのロードに0.009秒、ビットマップインデックスによるフィルタリングに0.003秒。

PullRowNum: 255 // 結果セットの行数。
CompressedBytesRead: 13.600 MB // 読み込まれたデータの総量。ビットマップインデックスのフィルタリングが効果的で、大量のデータをフィルタリングします。
RawRowsRead: 255 // 読み込まれた行数。
ReadPagesNum: 225 // 読み込まれたページ数。ビットマップインデックスはデータを効果的にフィルタリングし、多くのページをフィルタリングします。
IOTaskExecTime: 15.354ms // データスキャンの総時間。ビットマップインデックスなしよりも大幅に短い。
    BlockFetch: 9.530ms // データとビットマップインデックスのロード時間。ビットマップインデックスのロードに追加の時間がかかりますが、データロード時間を大幅に短縮します。
    BitmapIndexFilter: 3.450ms // ビットマップインデックスによるデータフィルタリングの時間。
    BitmapIndexFilterRows: 143.999M (143,999,213) // ビットマップインデックスによってフィルタリングされた行数。
StarRocksのデフォルト設定に基づいてビットマップインデックスを使用するかどうかを判断​

クエリ:

SELECT count(1) FROM lineorder_with_index WHERE lo_partkey=10000;

クエリパフォーマンス分析: StarRocksのデフォルト設定によれば、フィルタ条件の値の数/列の基数 < bitmap_max_filter_ratio/1000（デフォルトは1/1000）の場合にビットマップインデックスが使用されます。この条件が満たされているため、クエリはビットマップインデックスを使用し、ビットマップインデックスを強制的に使用する場合と同様のパフォーマンスになります。

総時間: 0.014秒、データとビットマップインデックスのロードに0.008秒、ビットマップインデックスによるフィルタリングに0.003秒。

PullRowNum: 255 // 結果セットの行数。
CompressedBytesRead: 13.600 MB // 読み込まれたデータの総量。ビットマップインデックスはデータを効果的にフィルタリングし、多くのデータをフィルタリングします。
RawRowsRead: 255 // 読み込まれた行数。
ReadPagesNum: 225 // 読み込まれたページ数。ビットマップインデックスはデータを効果的にフィルタリングし、多くのページをフィルタリングします。
IOTaskExecTime: 14.387ms // データスキャンの総時間。ビットマップインデックスなしよりも大幅に短い。
    BitmapIndexFilter: 2.979ms // ビットマップインデックスによるデータフィルタリングの時間。
    BitmapIndexFilterRows: 143.999M (143,999,213) // ビットマップインデックスによってフィルタリングされた行数。
    BlockFetch: 8.988ms // データとビットマップインデックスのロード時間。ビットマップインデックスのロードに追加の時間がかかりますが、データロード時間を大幅に短縮します。