Profiling

パフォーマンスの最適化

テーブルタイプの選択

StarRocksは、4つのテーブルタイプ（Duplicate Keyテーブル、Aggregateテーブル、Unique Keyテーブル、Primary Keyテーブル）をサポートしています。すべてのテーブルはKEYでソートされています。

AGGREGATE KEY: StarRocksに同じAGGREGATE KEYを持つレコードがロードされると、古いレコードと新しいレコードが集計されます。現在、Aggregateテーブルは次の集計関数をサポートしています：SUM、MIN、MAX、REPLACE。Aggregateテーブルはデータを事前に集約することをサポートしており、ビジネスステートメントや多次元分析を容易にします。
DUPLICATE KEY: DUPLICATE KEYテーブルでは、ソートキーのみを指定する必要があります。同じDUPLICATE KEYを持つレコードは同時に存在します。事前のデータ集約を必要としない分析に適しています。
UNIQUE KEY: StarRocksに同じUNIQUE KEYを持つレコードがロードされると、新しいレコードが古いレコードを上書きします。UNIQUE KEYテーブルは、REPLACE関数を持つアグリゲートテーブルと似ています。どちらも定期的な更新を必要とする分析に適しています。
PRIMARY KEY: Primary Keyテーブルはレコードの一意性を保証し、リアルタイムな更新を行うことができます。

CREATE TABLE site_visit
(
    siteid      INT,
    city        SMALLINT,
    username    VARCHAR(32),
    pv BIGINT   SUM DEFAULT '0'
)
AGGREGATE KEY(siteid, city, username)
DISTRIBUTED BY HASH(siteid);


CREATE TABLE session_data
(
    visitorid   SMALLINT,
    sessionid   BIGINT,
    visittime   DATETIME,
    city        CHAR(20),
    province    CHAR(20),
    ip          varchar(32),
    brower      CHAR(20),
    url         VARCHAR(1024)
)
DUPLICATE KEY(visitorid, sessionid)
DISTRIBUTED BY HASH(sessionid, visitorid);

CREATE TABLE sales_order
(
    orderid     BIGINT,
    status      TINYINT,
    username    VARCHAR(32),
    amount      BIGINT DEFAULT '0'
)
UNIQUE KEY(orderid)
DISTRIBUTED BY HASH(orderid);

CREATE TABLE sales_order
(
    orderid     BIGINT,
    status      TINYINT,
    username    VARCHAR(32),
    amount      BIGINT DEFAULT '0'
)
PRIMARY KEY(orderid)
DISTRIBUTED BY HASH(orderid);

共有配置テーブル

同じ分布を持つテーブルは、共通のバケット化カラムを使用してクエリのスピードを向上させることができます。この場合、データはクラスタ間で転送されずにローカルで結合されます。

CREATE TABLE colocate_table
(
    visitorid   SMALLINT,
    sessionid   BIGINT,
    visittime   DATETIME,
    city        CHAR(20),
    province    CHAR(20),
    ip          varchar(32),
    brower      CHAR(20),
    url         VARCHAR(1024)
)
DUPLICATE KEY(visitorid, sessionid)
DISTRIBUTED BY HASH(sessionid, visitorid)
PROPERTIES(
    "colocate_with" = "group1"
);

共有結合とレプリカ管理の詳細については、共有結合を参照してください。

フラットテーブルとスタースキーマ

StarRocksはスタースキーマをサポートしており、フラットテーブルよりもモデリングの柔軟性があります。モデリング中はビューを作成してフラットテーブルを置換し、複数のテーブルからデータをクエリすることでクエリを高速化することができます。

フラットテーブルには次のような欠点があります：

フラットテーブルは通常、膨大な数のディメンションを含んでいるため、ディメンションの更新はコストがかかります。ディメンションが更新されるたびに、テーブル全体を更新する必要があります。更新頻度が高くなるにつれて、状況は悪化します。
フラットテーブルは追加の開発負荷、ストレージスペース、データバックフィリング操作を必要とするため、メンテナンスコストが高くなります。
フラットテーブルは多くのフィールドを持ち、アグリゲートテーブルにはさらに多くのキーフィールドが含まれる可能性があるため、データ読み込み時にはより多くのフィールドがソートされるため、データの読み込みにコストがかかります。

クエリの同時実行や低レイテンシの要件がある場合は、フラットテーブルを使用することができます。

パーティションとバケット

StarRocksは、2つのレベルのパーティショニング（第1レベルは範囲パーティション、第2レベルはハッシュバケット）をサポートしています。

範囲パーティション：範囲パーティションはデータを異なる範囲に分割するために使用されます（元のテーブルを複数のサブテーブルに分割すると考えることができます）。多くのユーザーは、パーティションを時間で設定することを選択します。これには以下の利点があります：
- ホットデータとコールドデータの区別が容易です。
- StarRocksティアラベリングストレージ（SSD + SATA）を活用できます。
- パーティションごとにデータを削除するのが高速です。
ハッシュバケット：ハッシュ値に従ってデータを異なるバケットに分割します。
- データの歪みを避けるために、高い差別度を持つ列をバケット化することをお勧めします。
- データの復旧を容易にするために、各バケットの圧縮データのサイズを100 MBから1 GBの間に保つことをお勧めします。テーブルまたはパーティションを作成する際に適切な数のバケットを設定することをお勧めします。
- ランダムバケット化は推奨されません。テーブルを作成する際に明示的にハッシュバケット化の列を指定する必要があります。

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

StarRocksはデータを順序付けて格納し、スパースインデックスを1024行の単位で構築します。

StarRocksは、スキーマ内の固定長のプレフィックス（現在は36バイト）をスパースインデックスとして選択します。

テーブルを作成する際には、フィルタリングによく使用されるフィールドをスキーマ宣言の先頭に配置することを推奨します。差別度が最も高く、クエリ頻度が高いフィールドは最初に配置する必要があります。

VARCHARフィールドはスパースインデックスの末尾に配置する必要があります。VARCHARフィールドが最初に表示される場合、インデックスは36バイト未満になる可能性があります。

上記のsite_visitテーブルを例にとると、テーブルには4つの列（siteid、city、username、pv）があります。ソートキーにはsiteid、city、usernameの3つの列が含まれており、それぞれ4、2、32バイトを占有しています。したがって、プレフィックスインデックス（スパースインデックス）はsiteid + city + usernameの最初の30バイトです。

スパースインデックスに加えて、StarRocksはブルームフィルタインデックスも提供しており、差別度が高い列のフィルタリングに効果的です。他のフィールドよりも前にVARCHARフィールドを配置したい場合は、ブルームフィルタインデックスを作成できます。

反転インデックス

StarRocksはBitmap Indexing技術を採用し、Duplicate KeyテーブルとAggregateテーブルおよびUnique Keyテーブルのキーカラムのすべての列に対して反転インデックスをサポートしています。ビットマップインデックスは、性別、都市、州などの値範囲が小さい列に適しています。範囲が拡大すると、ビットマップインデックスも並行して拡大します。

マテリアライズドビュー（ロールアップ）

ロールアップは、元のテーブル（ベーステーブル）のマテリアライズドインデックスです。ロールアップを作成する際には、ベーステーブルの一部の列のみを選択してスキーマを作成し、フィールドの順序をベーステーブルと異なる場合があります。以下は、ロールアップの使用例です。

ベーステーブルでのデータ集約が高くない場合は、ベーステーブルに高い差別化を持つフィールドがあるため、いくつかの列を選択してロールアップを作成することを検討する必要があります。上記のsite_visitテーブルを例にとります：
```
site_visit(siteid, city, username, pv)
```
siteidはデータ集約が不十分な場合があります。都市ごとに頻繁にPVを計算する必要がある場合は、cityとpvのみを含むロールアップを作成できます。
```
ALTER TABLE site_visit ADD ROLLUP rollup_city(city, pv);
```
ベーステーブルのプレフィックスインデックスがヒットしない場合は、ベーステーブルのビルド方法ではすべてのクエリパターンをカバーできない場合があります。この場合、ロールアップを作成して列の順序を調整することを検討する必要があります。上記のsession_dataテーブルを例にとります：
```
session_data(visitorid, sessionid, visittime, city, province, ip, brower, url)
```
visitoridに加えて、browserとprovinceでの訪問分析が必要な場合は、別のロールアップを作成できます：
```
ALTER TABLE session_data
ADD ROLLUP rollup_brower(brower,province,ip,url)
DUPLICATE KEY(brower,province);
```

スキーマ変更

StarRocksでは、ソートされたスキーマ変更、直接のスキーマ変更、リンクされたスキーマ変更の3つの方法でスキーマを変更することができます。

ソートされたスキーマ変更：列の並べ替えとデータの再配置を行います。例えば、ソートされたスキーマの列を削除すると、データが再配置されます。ALTER TABLE site_visit DROP COLUMN city;
直接のスキーマ変更：データを再配置するのではなく、変換します。例えば、列の型を変更したり、スパースインデックスに列を追加したりします。ALTER TABLE site_visit MODIFY COLUMN username varchar(64);
リンクされたスキーマ変更：データを変換せずに変更を完了します。例えば、列の追加です。ALTER TABLE site_visit ADD COLUMN click bigint SUM default '0';スキーマを作成する際に適切なスキーマを選択することをお勧めします。スキーマの変更を加速するためです。

パフォーマンスの最適化

テーブルタイプの選択​

共有配置テーブル​

フラットテーブルとスタースキーマ​

パーティションとバケット​

スパースインデックスとブルームフィルタインデックス​

反転インデックス​

マテリアライズドビュー（ロールアップ）​

スキーマ変更​