StarRocks でのデータモデルとインデックスの使用法

1. StarRocks データモデル

StarRocks詳細モデル ( Duplicate Key Model)、集計モデル ( Aggregate Key Model)、更新モデル ( Unique Key Model)、および主キーモデル ( Primary Key Model) の 4 つのデータモデルがサポートされています。

1.1 詳細モデル

詳細モデルは、デフォルトのテーブル作成モデルです。テーブルの作成時にモデルが指定されていない場合は、デフォルトで詳細タイプのテーブルが作成されます。列の並べ替えではスパースインデックスを使用するため、データを高速にフィルタリングできます。詳細モデルはすべての履歴データを保存するために使用され、ユーザーはフィルタ条件で頻繁に使用されるディメンション列をソートキーとして考慮できます。たとえば、ユーザーは特定の時刻を表示する必要があることが多く、イベント時間とイベントタイプをソートキーとして使用できます。

例: テーブルを作成するときにモデルとソートキーを指定します。

CREATE TABLE IF NOT EXISTS detail (
   event_time DATETIME NOT NULL COMMENT "datetime of event",
   event_type INT NOT NULL COMMENT "type of event",
   user_id INT COMMENT "id of user",
   device_code INT COMMENT "device of ",
   channel INT COMMENT ""
) DUPLICATE KEY(event_time, event_type)
DISTRIBUTED BY HASH(user_id)  BUCKETS 8 ;

1.2 集約モデル

データ分析では、多くのシナリオで詳細なデータに基づく統計と要約が必要ですが、この時点で集計モデルを使用できます。例:appアクセストラフィックの統計、ユーザーアクセス期間、ユーザーアクセス時間、合計表示、消費統計、その他のシナリオ。

例えば：

CREATE TABLE IF NOT EXISTS aggregate_tbl (
    site_id LARGEINT NOT NULL COMMENT "id of site",
    DATE DATE NOT NULL COMMENT "time of event",
    city_code VARCHAR(20) COMMENT "city_code of user",
    pv BIGINT SUM DEFAULT "0" COMMENT "total page views",
    mt BIGINT MAX
)
DISTRIBUTED BY HASH(site_id) BUCKETS 8;

1.3 モデルの更新

一部の分析シナリオでは、ジッパーテーブルなどのデータを更新する必要があり、StarRocksこの需要を満たすために更新モデルが使用されます。たとえば、電子商取引シナリオでは、注文のステータスが頻繁に変更され、毎日の注文更新量が数億件を超える場合があります。このようなビジネスシナリオでは、詳細モデルを経由する方法だけではdelete+insert頻繁な更新要件に対応できないため、更新モデルを使用して分析要件を満たすことができます。ただし、ユーザーがよりリアルタイム/頻繁な更新操作を必要とする場合は、主キーモデルを使用することをお勧めします。

例えば：

CREATE TABLE IF NOT EXISTS update_detail (
    create_time DATE NOT NULL COMMENT "create time of an order",
    order_id BIGINT NOT NULL COMMENT "id of an order",
    order_state INT COMMENT "state of an order",
    total_price BIGINT COMMENT "price of an order"
)
UNIQUE KEY(create_time, order_id)
DISTRIBUTED BY HASH(order_id) BUCKETS 8

1.4 主キーモデル

更新モデルと比較して、主キーモデルはリアルタイム/頻繁な更新機能をより適切にサポートできます。更新モデルでもリアルタイムでデータを更新できますが、Merge on Read更新モデルで読み取り時マージ戦略を使用するとクエリ機能が大幅に制限され、行レベルの更新操作は主キーモデルでより適切に解決されます。リアルタイム同期Flink-connector-starrocksを完了できるソリューションと連携します。Mysql CDC

ストレージエンジンは主キーのインデックスを作成し、データのインポート時にインデックスがメモリに読み込まれるため、主キーモデルの方がメモリ要件が高く、主キーモデルに適さないシナリオが依然として多くあることに注意してください。
現在、主キーモデルの使用に適したシナリオが 2 つあります。

データのホットとコールドの特性 (過去数日間のデータは変更する必要があるが、古いコールドデータはほとんど変更する必要がない) (注文データなど)、古い注文は完了後に更新されず、パーティションは日ごとにパーティション化されており、データのインポート時に履歴パーティションのデータの主キーはロードされず、メモリは占有されません。メモリには過去数日間のインデックスのみがロードされます。
大きくて幅の広いテーブル (数百、数千の列) の場合、主キーはデータ全体のごく一部のみを占め、メモリのオーバーヘッドは比較的低くなります。たとえば、ユーザーステータス/ポートレートテーブルでは、列は多くありますが、ユーザーの総数はそれほど大きくなく (数千万から数十億)、主キーインデックスのメモリ使用量は比較的制御可能です。

Merge原則:更新モデルで採用されているポリシーにより、述語をプッシュダウンできず、インデックスを使用できないため、
クエリのパフォーマンスに重大な影響を与えます。したがって、主キーモデルでは、主キー制約を通じて同じ主キーに対してデータレコードが 1 つだけ存在することが保証され、Merge操作が回避されます。

StarRocksレコードに対する更新操作を受け取ると、主キーインデックスを通じてデータの場所を検索し、削除済みとしてマークしてから、データの一部を挿入します。これは、次のように書き換えることと同じですupdate。delete+insert

例えば：

CREATE TABLE users (
    user_id BIGINT NOT NULL,
    NAME STRING NOT NULL,
    email STRING NULL,
    address STRING NULL,
    age TINYINT NULL,
    sex TINYINT NULL
) PRIMARY KEY (user_id)
DISTRIBUTED BY HASH(user_id) BUCKETS 4

2. ソートキーとプレフィックスインデックス

テーブルを作成するとき、1 つ以上の列を指定してソートキー ( Sort Key) を形成できます。テーブル内の行は、ディスクストレージに格納される前に、ソートキーに従ってソートされます。データをクエリするときに、並べ替え列を使用してフィルター条件を指定すると、StarRocksテーブル全体をスキャンすることなく、処理する必要のあるデータをすばやく見つけることができるため、検索の複雑さが軽減され、クエリが高速化されます。

同時に、メモリのオーバーヘッドを削減するために、StarRocksソートキーに基づいてプレフィックスインデックス () が導入されますPrefix Index。プレフィックスインデックスは、スパースインデックスの一種です。テーブル内のデータの各行は、1024論理データブロック ( Data Block) を構成します。各論理データブロックには、プレフィックスインデックステーブルにインデックス項目が格納されます。インデックス項目の長さはバイトを超えず、その36内容は、データブロック内のデータの最初の行のソート列で構成されるプレフィックスです。プレフィックスインデックステーブルを検索する場合、データ行が配置されている論理データブロックの開始行番号を判断するのに役立ちます。プレフィックスインデックスのサイズはデータ量の 1 分の 1 である1024ため、完全にメモリにキャッシュされ、実際の検索プロセス中のクエリを効果的に高速化できます。

詳細モデルでは、DUPLICATE KEYキーワードで指定された列がソート列となります。

集計モデルでは、ソート列はAGGREGATE KEYキーワードで指定された列です。

更新モデルでは、ソート列はUNIQUE KEYキーワードで指定された列です。

このバージョンから3.0、主キーモデルでは主キーカラムとソートカラムが分離され、ソートカラムはORDER BYキーワードで指定され、主キーカラムはPRIMARY KEYキーワードで指定されます。

詳細モデル、集計モデル、更新モデルでソート列を定義する場合は、次の点に注意する必要があります。

列の並べ替えは、定義された最初の列から開始し、連続している必要があります。
各列を定義するときは、ソート列となる予定の列を他の通常の列よりも前に定義する必要があります。
ソート列の順序は、テーブル定義の列の順序と一致する必要があります。

たとえば、主キーモデルの下にソートキーを追加します。

CREATE TABLE site_access_primary
(
    site_id INT DEFAULT '10',
    city_code SMALLINT,
    user_id INT,
    pv BIGINT DEFAULT '0'
)
PRIMARY KEY(site_id)
DISTRIBUTED BY HASH(site_id) BUCKETS 10
ORDER BY(site_id,city_code);

3. 索引

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

ここに画像の説明を挿入

Bitmapインデックスは、bitmapを使用する特別なデータベースインデックスです。bitmapつまり、bit配列 a にはまたはというbit2 つの値があります。それぞれはデータテーブルの行に対応し、の値は行の値に従って決定されます。01bitbit01

Bitmapインデックスを使用すると、指定した列のクエリ効率を向上させることができます。クエリ条件がプレフィックスインデックス列にヒットした場合は、StarRocksプレフィックスインデックスを使用してクエリの効率を向上させ、クエリ結果を迅速に返すことができます。ただし、プレフィックスインデックスの長さは制限されているため、プレフィックスインデックス以外の列のクエリ効率を向上させたい場合は、Bitmapこの列のインデックスを作成できます。

アドバンテージ

カーディナリティが低く、反復値が多数ある列 (ENUM型の列など) では、Bitmapインデックスを使用するとクエリの応答時間を短縮できます。
Bitmapインデックスが占有する記憶領域は通常、インデックスデータのごく一部に過ぎないため、他のインデックス作成テクノロジと比較して記憶領域が節約されます。
複数列のビットマップインデックスの作成をサポートし、複数列クエリの効率を向上させます。詳細については、「複数列クエリ」を参照してください。

使用:

Bitmapインデックスは、等価条件 ( =) または range [ NOT]を使用してINクエリできる列に適用されます。
Bitmapインデックスは、主キーモデルと詳細モデルのすべての列に対して作成できます。集計モデルと更新モデルでは、ディメンション列 (つまり、Key列) のみがビットマップインデックスの作成をサポートします。
インデックスは、タイプFLOAT、DOUBLE、BOOLEANおよびの列ではサポートされていません。DECIMALBitmap
クエリがBitmapインデックスにヒットするかどうかを確認するには、クエリのProfileのフィールドを調べますBitmapIndexFilterRows。

インデックスを作成します。

CREATE TABLE test
(
    k1 TINYINT,
    k2 DECIMAL(10, 2) DEFAULT "10.5",
    v1 CHAR(10) REPLACE,
    v2 INT SUM,
    INDEX index_name (v1) USING BITMAP COMMENT 'index_name '
)
ENGINE = olap
AGGREGATE KEY(k1, k2)
DISTRIBUTED BY HASH(k1) BUCKETS 10
PROPERTIES ("storage_type" = "column");

または：

CREATE INDEX index_name ON test(v1) USING BITMAP COMMENT 'index_name ';

作成の進行状況を表示します。

SHOW ALTER TABLE v1 FROM test;

ビューインデックス:

SHOW INDEX FROM test;

インデックスを削除します。

DROP INDEX index_name ON test;

3.2 ブルームフィルターインデックス

ここに画像の説明を挿入

Bloom filterインデックスは、テーブルのデータファイルにクエリ対象のデータが含まれているかどうかを迅速に判断し、含まれていない場合はスキップすることができるため、スキャンされるデータの量が削減されます。Bloom filterインデックスはスペース効率が高く、ID列などのカーディナリティの高い列に適しています。クエリ条件がプレフィックスインデックス列にヒットした場合、StarRocksプレフィックスインデックスを使用してクエリ結果がすぐに返されます。Bloom filterただし、接頭辞インデックスの長さは制限されているため、非接頭辞インデックス列を迅速にクエリする必要があり、その列のカーディナリティが高い場合は、この列のインデックスを作成できます。

説明:

Bloom filter主キーモデルと詳細モデルではすべての列に対してインデックスを作成できますが、集計モデルと更新モデルでは、ディメンション列 (つまりKey列)のみがBloom filterインデックスの作成をサポートします。
インデックスは、タイプTINYINT、FLOAT、DOUBLEおよびの列ではサポートされていません。DECIMALBloom filter
Bloom filterinインデックスは、フィルター条件を含むクエリの効率のみを向上させます=。
クエリがBloom filterインデックスにヒットするかどうかを確認するには、クエリのProfileのフィールドを調べますBloomFilterFilterRows。

インデックスを作成します。

CREATE TABLE table1
(
    k1 BIGINT,
    k2 LARGEINT,
    v1 VARCHAR(2048) REPLACE,
    v2 SMALLINT DEFAULT "10"
)
ENGINE = olap
PRIMARY KEY(k1, k2)
DISTRIBUTED BY HASH (k1, k2) BUCKETS 10
PROPERTIES("bloom_filter_columns" = "k1,k2");

または：

ALTER TABLE table1 SET ("bloom_filter_columns" = "k1,k2,v1");

ビューインデックス:

SHOW CREATE TABLE table1;

インデックスを削除します。

ALTER TABLE table1 SET ("bloom_filter_columns" = "");