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

データ分散

テーブル作成時に適切なパーティション化とバケッティングを設定することで、均等なデータ分散を達成できます。均等なデータ分散とは、特定のルールに従ってデータをサブセットに分割し、異なるノードに均等に分散させることを意味します。これにより、スキャンされるデータ量を減らし、クラスターの並列処理能力を最大限に活用し、クエリパフォーマンスを向上させることができます。

注意

  • v3.1以降、テーブル作成時やパーティション追加時にDISTRIBUTED BY句でバケッティングキーを指定する必要はありません。StarRocksはランダムバケット法をサポートしており、データをすべてのバケットにランダムに分散させます。詳細は ランダムバケット法 を参照してください。
  • v2.5.7以降、テーブル作成時やパーティション追加時にバケット数を手動で設定しないことを選択できます。StarRocksは自動的にバケット数（BUCKETS）を設定します。ただし、StarRocksが自動的にバケット数を設定した後、パフォーマンスが期待に応えない場合で、バケッティングメカニズムに精通している場合は、バケット数を手動で設定 することもできます。

分散手法​

一般的な分散手法​

現代の分散データベースシステムは、一般に以下の基本的な分散手法を使用します: ラウンドロビン、レンジ、リスト、ハッシュ。

データ分散手法

  • ラウンドロビン: データを異なるノードに循環的に分散します。
  • レンジ: パーティション列の値の範囲に基づいてデータを異なるノードに分散します。図に示すように、範囲 [1-3] と [4-6] は異なるノードに対応しています。
  • リスト: パーティション列の離散値に基づいてデータを異なるノードに分散します。各離散値はノードにマッピングされ、複数の異なる値が同じノードにマッピングされることがあります。
  • ハッシュ: ハッシュ関数に基づいてデータを異なるノードに分散します。

より柔軟なデータパーティション化を達成するために、上記のデータ分散手法のいずれかを使用するだけでなく、特定のビジネス要件に基づいてこれらの手法を組み合わせることもできます。一般的な組み合わせには、ハッシュ+ハッシュ、レンジ+ハッシュ、ハッシュ+リストがあります。

StarRocksにおける分散手法​

StarRocksは、データ分散手法の個別使用と複合使用の両方をサポートしています。

注意

一般的な分散手法に加えて、StarRocksはバケッティング設定を簡素化するためにランダム分散もサポートしています。

また、StarRocksは二段階のパーティション化 + バケッティング手法を実装してデータを分散します。

  • 第一段階はパーティション化です: テーブル内のデータはパーティション化できます。サポートされているパーティション化の手法は、式に基づくパーティション化、レンジパーティション化、リストパーティション化です。また、パーティション化を使用しないことも選択できます（テーブル全体が1つのパーティションと見なされます）。
  • 第二段階はバケッティングです: パーティション内のデータはさらに小さなバケットに分散する必要があります。サポートされているバケッティング手法は、ハッシュとランダムバケット法です。
分散手法パーティション化とバケッティング手法説明
ランダム分散ランダムバケット法テーブル全体が1つのパーティションと見なされます。テーブル内のデータは異なるバケットにランダムに分散されます。これはデフォルトのデータ分散手法です。
ハッシュ分散ハッシュバケット法テーブル全体が1つのパーティションと見なされます。テーブル内のデータは、ハッシュ関数を使用してデータのバケッティングキーのハッシュ値に基づいて対応するバケットに分散されます。
レンジ+ランダム分散
  1. 式に基づくパーティション化またはレンジパーティション化
  2. ランダムバケット法
  1. テーブル内のデータは、パーティション列の値が属する範囲に基づいて対応するパーティションに分散されます。
  2. パーティション内のデータは異なるバケットにランダムに分散されます。
レンジ+ハッシュ分散
  1. 式に基づくパーティション化またはレンジパーティション化
  2. ハッシュバケット法
  1. テーブル内のデータは、パーティション列の値が属する範囲に基づいて対応するパーティションに分散されます。
  2. パーティション内のデータは、ハッシュ関数を使用してデータのバケッティングキーのハッシュ値に基づいて対応するバケットに分散されます。
リスト+ランダム分散
  1. 式に基づくパーティション化またはリストパーティション化
  2. ランダムバケット法
  1. テーブル内のデータは、パーティション列の値が属する範囲に基づいて対応するパーティションに分散されます。
  2. パーティション内のデータは異なるバケットにランダムに分散されます。
リスト+ハッシュ分散
  1. 式に基づくパーティション化またはリストパーティション化
  2. ハッシュバケット法
  1. テーブル内のデータは、パーティション列の値が属する値リストに基づいてパーティション化されます。
  2. パーティション内のデータは、ハッシュ関数を使用してデータのバケッティングキーのハッシュ値に基づいて対応するバケットに分散されます。

  • ランダム分散

    テーブル作成時にパーティション化とバケッティング手法を設定しない場合、デフォルトでランダム分散が使用されます。この分散手法は現在、重複キーテーブルの作成にのみ使用できます。

    CREATE TABLE site_access1 (
        event_day DATE,
        site_id INT DEFAULT '10', 
        pv BIGINT DEFAULT '0' ,
        city_code VARCHAR(100),
        user_name VARCHAR(32) DEFAULT ''
    )
    DUPLICATE KEY (event_day,site_id,pv);
    -- パーティション化とバケッティング手法が設定されていないため、デフォルトでランダム分散が使用されます。

  • ハッシュ分散

    CREATE TABLE site_access2 (
        event_day DATE,
        site_id INT DEFAULT '10',
        city_code SMALLINT,
        user_name VARCHAR(32) DEFAULT '',
        pv BIGINT SUM DEFAULT '0'
    )
    AGGREGATE KEY (event_day, site_id, city_code, user_name)
    -- ハッシュバケット法をバケッティング手法として使用し、バケッティングキーを指定する必要があります。
    DISTRIBUTED BY HASH(event_day,site_id);

  • レンジ+ランダム分散（この分散手法は現在、重複キーテーブルの作成にのみ使用できます。）

    CREATE TABLE site_access3 (
        event_day DATE,
        site_id INT DEFAULT '10', 
        pv BIGINT DEFAULT '0' ,
        city_code VARCHAR(100),
        user_name VARCHAR(32) DEFAULT ''
    )
    DUPLICATE KEY(event_day,site_id,pv)
    -- 式に基づくパーティション化をパーティション化手法として使用し、時間関数式を設定します。
    -- レンジパーティション化も使用できます。
    PARTITION BY date_trunc('day', event_day);
    -- バケッティング手法が設定されていないため、デフォルトでランダムバケット法が使用されます。

  • レンジ+ハッシュ分散

    CREATE TABLE site_access4 (
        event_day DATE,
        site_id INT DEFAULT '10',
        city_code VARCHAR(100),
        user_name VARCHAR(32) DEFAULT '',
        pv BIGINT SUM DEFAULT '0'
    )
    AGGREGATE KEY(event_day, site_id, city_code, user_name)
    -- 式に基づくパーティション化をパーティション化手法として使用し、時間関数式を設定します。
    -- レンジパーティション化も使用できます。
    PARTITION BY date_trunc('day', event_day)
    -- ハッシュバケット法をバケッティング手法として使用し、バケッティングキーを指定する必要があります。
    DISTRIBUTED BY HASH(event_day, site_id);

  • リスト+ランダム分散（この分散手法は現在、重複キーテーブルの作成にのみ使用できます。）

    CREATE TABLE t_recharge_detail1 (
        id bigint,
        user_id bigint,
        recharge_money decimal(32,2), 
        city varchar(20) not null,
        dt date not null
    )
    DUPLICATE KEY(id)
    -- 式に基づくパーティション化をパーティション化手法として使用し、パーティション列を指定します。
    -- リストパーティション化も使用できます。
    PARTITION BY (city);
    -- バケッティング手法が設定されていないため、デフォルトでランダムバケット法が使用されます。

  • リスト+ハッシュ分散

    CREATE TABLE t_recharge_detail2 (
        id bigint,
        user_id bigint,
        recharge_money decimal(32,2), 
        city varchar(20) not null,
        dt date not null
    )
    DUPLICATE KEY(id)
    -- 式に基づくパーティション化をパーティション化手法として使用し、パーティション列を指定します。
    -- リストパーティション化も使用できます。
    PARTITION BY (city)
    -- ハッシュバケット法をバケッティング手法として使用し、バケッティングキーを指定する必要があります。
    DISTRIBUTED BY HASH(city,id);

パーティション化​

パーティション化手法はテーブルを複数のパーティションに分割します。パーティション化は主に、パーティションキーに基づいてテーブルを異なる管理単位（パーティション）に分割するために使用されます。各パーティションに対して、バケット数、ホットデータとコールドデータの保存戦略、記憶媒体の種類、レプリカの数を含むストレージ戦略を設定できます。StarRocksは、クラスター内で異なる種類の記憶媒体を使用することを許可しています。たとえば、最新のデータをソリッドステートドライブ（SSD）に保存してクエリパフォーマンスを向上させ、履歴データをSATAハードドライブに保存してストレージコストを削減することができます。

パーティション化手法シナリオパーティションを作成する方法
式に基づくパーティション化（推奨）以前は自動パーティション化として知られていました。このパーティション化手法はより柔軟で使いやすく、連続した日付範囲や列挙値に基づいてデータをクエリおよび管理するほとんどのシナリオに適しています。データロード中に自動的に作成されます
レンジパーティション化典型的なシナリオは、連続した日付/数値範囲に基づいて頻繁にクエリおよび管理される、シンプルで順序付けられたデータを保存することです。たとえば、特定のケースでは、履歴データを月ごとにパーティション化し、最近のデータを日ごとにパーティション化する必要があります。手動、動的、またはバッチで作成されます
リストパーティション化典型的なシナリオは、列挙値に基づいてデータをクエリおよび管理し、各パーティション列の異なる値を含むデータをパーティションに含める必要がある場合です。たとえば、国や都市に基づいて頻繁にデータをクエリおよび管理する場合、この手法を使用し、cityをパーティション列として選択できます。この場合、1つのパーティションは同じ国に属する複数の都市のデータを保存できます。手動で作成されます
パーティション列と粒度の選択方法​
  • 適切なパーティション列を選択することで、クエリ中にスキャンされるデータ量を効果的に減らすことができます。ほとんどのビジネスシステムでは、期限切れデータの削除によって引き起こされる特定の問題を解決し、ホットデータとコールドデータの階層型ストレージの管理を容易にするために、時間に基づいたパーティション化が一般的に採用されています。この場合、式に基づくパーティション化またはレンジパーティション化を使用し、時間列をパーティション列として指定できます。さらに、データが列挙値に基づいて頻繁にクエリおよび管理される場合、式に基づくパーティション化またはリストパーティション化を使用し、これらの値を含む列をパーティション列として指定できます。
  • パーティションの粒度を選択する際には、データ量、クエリパターン、データ管理の粒度を考慮する必要があります。
    • 例1: テーブルの月間データ量が少ない場合、日ごとにパーティション化するよりも月ごとにパーティション化することでメタデータの量を減らし、メタデータ管理とスケジューリングのリソース消費を削減できます。
    • 例2: テーブルの月間データ量が多く、クエリが特定の日のデータを主に要求する場合、日ごとにパーティション化することでクエリ中にスキャンされるデータ量を効果的に減らすことができます。
    • 例3: データが日単位で期限切れになる必要がある場合、日ごとにパーティション化することをお勧めします。

バケッティング​

バケッティング手法は、パーティションを複数のバケットに分割します。バケット内のデータはタブレットと呼ばれます。

サポートされているバケッティング手法は、ランダムバケット法（v3.1以降）とハッシュバケット法です。

  • ランダムバケット法: テーブル作成時やパーティション追加時にバケッティングキーを設定する必要はありません。パーティション内のデータは異なるバケットにランダムに分散されます。

  • ハッシュバケット法: テーブル作成時やパーティション追加時にバケッティングキーを指定する必要があります。同じパーティション内のデータは、バケッティングキーの値に基づいてバケットに分割され、バケッティングキーの同じ値を持つ行は対応する一意のバケットに分散されます。

バケット数: デフォルトでは、StarRocksは自動的にバケット数を設定します（v2.5.7以降）。また、バケット数を手動で設定することもできます。詳細については、バケット数の決定を参照してください。

パーティションの作成と管理​

パーティションの作成​

式に基づくパーティション化（推奨）​

注意

v3.1以降、StarRocksの共有データモードは時間関数式をサポートし、列式はサポートしていません。

v3.0以降、StarRocksは式に基づくパーティション化（以前は自動パーティション化として知られていました）をサポートしており、より柔軟で使いやすくなっています。このパーティション化手法は、連続した日付範囲やENUM値に基づいてデータをクエリおよび管理するほとんどのシナリオに適しています。

テーブル作成時にパーティション式（時間関数式または列式）を設定するだけで、StarRocksはデータロード中に自動的にパーティションを作成します。事前に多数のパーティションを手動で作成する必要はなく、動的パーティションプロパティを設定する必要もありません。

レンジパーティション化​

レンジパーティション化は、シンプルで連続したデータ、例えば時系列データや連続した数値データを保存するのに適しています。レンジパーティション化は、連続した日付/数値範囲に基づいて頻繁にクエリされるデータに適しています。さらに、特定のケースでは、履歴データを月ごとにパーティション化し、最近のデータを日ごとにパーティション化する必要があります。

StarRocksは、各パーティションの明示的に定義された範囲の明示的なマッピングに基づいて、対応するパーティションにデータを保存します。

動的パーティション化​

動的パーティション化に関連するプロパティは、テーブル作成時に設定されます。StarRocksは、データの新鮮さを確保するために、新しいパーティションを事前に自動的に作成し、期限切れのパーティションを削除します。これにより、パーティションのタイム・トゥ・リブ（TTL）管理が実現されます。

式に基づくパーティション化によって提供される自動パーティション作成機能とは異なり、動的パーティション化はプロパティに基づいて定期的に新しいパーティションを作成することしかできません。新しいデータがこれらのパーティションに属していない場合、ロードジョブに対してエラーが返されます。ただし、式に基づくパーティション化によって提供される自動パーティション作成機能は、ロードされたデータに基づいて常に対応する新しいパーティションを作成できます。

手動でパーティションを作成する​

適切なパーティションキーを使用することで、クエリ中にスキャンされるデータ量を効果的に減らすことができます。現在、日付または整数型の列のみがパーティション列として選択され、パーティションキーを構成することができます。ビジネスシナリオでは、パーティションキーは通常、データ管理の観点から選択されます。一般的なパーティション列には、日付や場所を表す列が含まれます。

CREATE TABLE site_access(
    event_day DATE,
    site_id INT DEFAULT '10',
    city_code VARCHAR(100),
    user_name VARCHAR(32) DEFAULT '',
    pv BIGINT SUM DEFAULT '0'
)
AGGREGATE KEY(event_day, site_id, city_code, user_name)
PARTITION BY RANGE(event_day)(
    PARTITION p1 VALUES LESS THAN ("2020-01-31"),
    PARTITION p2 VALUES LESS THAN ("2020-02-29"),
    PARTITION p3 VALUES LESS THAN ("2020-03-31")
)
DISTRIBUTED BY HASH(site_id);
バッチで複数のパーティションを作成する​

テーブル作成時および作成後に、バッチで複数のパーティションを作成できます。START()とEND()でバッチで作成されるすべてのパーティションの開始時間と終了時間を指定し、EVERY()でパーティションの増分値を指定できます。ただし、パーティションの範囲は右半開であり、開始時間を含み、終了時間を含まないことに注意してください。パーティションの命名ルールは動的パーティション化と同じです。

  • テーブル作成時に日付型列（DATEおよびDATETIME）でテーブルをパーティション化する

    パーティション列が日付型の場合、テーブル作成時にSTART()とEND()を使用してバッチで作成されるすべてのパーティションの開始日と終了日を指定し、EVERY(INTERVAL xxx)で2つのパーティション間の増分間隔を指定できます。現在、間隔の粒度はHOUR（v3.0以降）、DAY、WEEK、MONTH、YEARをサポートしています。

    次の例では、バッチで作成されるすべてのパーティションの日付範囲は2021-01-01から始まり、2021-01-04で終わり、増分間隔は1日です。

    CREATE TABLE site_access (
      datekey DATE,
      site_id INT,
      city_code SMALLINT,
      user_name VARCHAR(32),
      pv BIGINT DEFAULT '0'
    )
    ENGINE=olap
    DUPLICATE KEY(datekey, site_id, city_code, user_name)
    PARTITION BY RANGE (datekey) (
      START ("2021-01-01") END ("2021-01-04") EVERY (INTERVAL 1 DAY)
    )
    DISTRIBUTED BY HASH(site_id)
    PROPERTIES ("replication_num" = "3" );

    これは、CREATE TABLE文で次のPARTITION BY句を使用することと同等です。

    PARTITION BY RANGE (datekey) (
    PARTITION p20210101 VALUES [('2021-01-01'), ('2021-01-02')),
    PARTITION p20210102 VALUES [('2021-01-02'), ('2021-01-03')),
    PARTITION p20210103 VALUES [('2021-01-03'), ('2021-01-04'))
    )

  • テーブル作成時に異なる日付間隔で日付型列（DATEおよびDATETIME）でテーブルをパーティション化する

    各バッチのパーティションに対して異なる増分間隔をEVERYで指定することにより、異なる増分間隔で日付パーティションのバッチを作成できます（異なるバッチ間でパーティション範囲が重ならないようにしてください）。各バッチのパーティションは、START (xxx) END (xxx) EVERY (xxx)句に従って作成されます。例：

    CREATE TABLE site_access(
      datekey DATE,
      site_id INT,
      city_code SMALLINT,
      user_name VARCHAR(32),
      pv BIGINT DEFAULT '0'
    )
    ENGINE=olap
    DUPLICATE KEY(datekey, site_id, city_code, user_name)
    PARTITION BY RANGE (datekey) 
    (
      START ("2019-01-01") END ("2021-01-01") EVERY (INTERVAL 1 YEAR),
      START ("2021-01-01") END ("2021-05-01") EVERY (INTERVAL 1 MONTH),
      START ("2021-05-01") END ("2021-05-04") EVERY (INTERVAL 1 DAY)
    )
    DISTRIBUTED BY HASH(site_id)
    PROPERTIES(
      "replication_num" = "3"
    );

    これは、CREATE TABLE文で次のPARTITION BY句を使用することと同等です。

    PARTITION BY RANGE (datekey) (
    PARTITION p2019 VALUES [('2019-01-01'), ('2020-01-01')),
    PARTITION p2020 VALUES [('2020-01-01'), ('2021-01-01')),
    PARTITION p202101 VALUES [('2021-01-01'), ('2021-02-01')),
    PARTITION p202102 VALUES [('2021-02-01'), ('2021-03-01')),
    PARTITION p202103 VALUES [('2021-03-01'), ('2021-04-01')),
    PARTITION p202104 VALUES [('2021-04-01'), ('2021-05-01')),
    PARTITION p20210501 VALUES [('2021-05-01'), ('2021-05-02')),
    PARTITION p20210502 VALUES [('2021-05-02'), ('2021-05-03')),
    PARTITION p20210503 VALUES [('2021-05-03'), ('2021-05-04'))
    )

  • テーブル作成時に整数型列でテーブルをパーティション化する

    パーティション列のデータ型がINTの場合、STARTとENDでパーティションの範囲を指定し、EVERYで増分値を定義します。例：

    注意

    **START()とEND()**のパーティション列の値はダブルクォーテーションで囲む必要がありますが、**EVERY()**の増分値はダブルクォーテーションで囲む必要はありません。

    次の例では、すべてのパーティションの範囲は1から始まり、5で終わり、パーティションの増分は1です。

    CREATE TABLE site_access (
      datekey INT,
      site_id INT,
      city_code SMALLINT,
      user_name VARCHAR(32),
      pv BIGINT DEFAULT '0'
    )
    ENGINE=olap
    DUPLICATE KEY(datekey, site_id, city_code, user_name)
    PARTITION BY RANGE (datekey) (START ("1") END ("5") EVERY (1)
    )
    DISTRIBUTED BY HASH(site_id)
    PROPERTIES ("replication_num" = "3");

    これは、CREATE TABLE文で次のPARTITION BY句を使用することと同等です。

    PARTITION BY RANGE (datekey) (
    PARTITION p2019 VALUES [('2019-01-01'), ('2020-01-01')),
    PARTITION p2020 VALUES [('2020-01-01'), ('2021-01-01')),
    PARTITION p202101 VALUES [('2021-01-01'), ('2021-02-01')),
    PARTITION p202102 VALUES [('2021-02-01'), ('2021-03-01')),
    PARTITION p202103 VALUES [('2021-03-01'), ('2021-04-01')),
    PARTITION p202104 VALUES [('2021-04-01'), ('2021-05-01')),
    PARTITION p20210501 VALUES [('2021-05-01'), ('2021-05-02')),
    PARTITION p20210502 VALUES [('2021-05-02'), ('2021-05-03')),
    PARTITION p20210503 VALUES [('2021-05-03'), ('2021-05-04'))
    )
テーブル作成後にバッチで複数のパーティションを作成する​

テーブル作成後、ALTER TABLE文を使用してパーティションを追加できます。構文は、テーブル作成時にバッチで複数のパーティションを作成する場合と似ています。ADD PARTITIONS句でSTART、END、EVERYを設定する必要があります。

ALTER TABLE site_access 
ADD PARTITIONS START ("2021-01-04") END ("2021-01-06") EVERY (INTERVAL 1 DAY);

リストパーティション化（v3.1以降）​

リストパーティション化は、列挙値に基づいてデータを効率的に管理し、クエリを加速するのに適しています。特に、パーティション列に異なる値を持つデータを含める必要があるシナリオで有用です。たとえば、国や都市に基づいて頻繁にデータをクエリおよび管理する場合、このパーティション化手法を使用し、city列をパーティション列として選択できます。この場合、1つのパーティションは1つの国に属するさまざまな都市のデータを含むことができます。

StarRocksは、各パーティションの事前定義された値リストの明示的なマッピングに基づいて、対応するパーティションにデータを保存します。

パーティションの管理​

パーティションの追加​

レンジパーティション化およびリストパーティション化では、新しいデータを保存するために新しいパーティションを手動で追加できます。ただし、式に基づくパーティション化では、データロード中にパーティションが自動的に作成されるため、その必要はありません。

次の文は、新しい月のデータを保存するためにテーブルsite_accessに新しいパーティションを追加します。

ALTER TABLE site_access
ADD PARTITION p4 VALUES LESS THAN ("2020-04-30")
DISTRIBUTED BY HASH(site_id);

パーティションの削除​

次の文は、テーブルsite_accessからパーティションp1を削除します。

注意

この操作は、パーティション内のデータを即座に削除するわけではありません。データは一定期間（デフォルトで1日）ゴミ箱に保持されます。パーティションを誤って削除した場合、RECOVERコマンドを使用してパーティションとそのデータを復元できます。

ALTER TABLE site_access
DROP PARTITION p1;

パーティションの復元​

次の文は、テーブルsite_accessにパーティションp1とそのデータを復元します。

RECOVER PARTITION p1 FROM site_access;

パーティションの表示​

次の文は、テーブルsite_access内のすべてのパーティションの詳細を返します。

SHOW PARTITIONS FROM site_access;

バケッティングの設定​

ランダムバケット法（v3.1以降）​

StarRocksは、パーティション内のデータをすべてのバケットにランダムに分散させます。これは、データサイズが小さく、クエリパフォーマンスの要件が比較的低いシナリオに適しています。バケッティング手法を設定しない場合、StarRocksはデフォルトでランダムバケット法を使用し、バケット数を自動的に設定します。

ただし、大量のデータをクエリし、特定の列をフィルタ条件として頻繁に使用する場合、ランダムバケット法が提供するクエリパフォーマンスは最適ではない可能性があります。このようなシナリオでは、ハッシュバケット法を使用することをお勧めします。これらの列がクエリのフィルタ条件として使用される場合、クエリがヒットする少数のバケットのデータのみをスキャンおよび計算する必要があり、クエリパフォーマンスを大幅に向上させることができます。

制限事項​

  • ランダムバケット法は、重複キーテーブルの作成にのみ使用できます。
  • ランダムにバケットされたテーブルをColocation Groupに属させることはできません。
  • Spark Loadを使用してランダムにバケットされたテーブルにデータをロードすることはできません。

次のCREATE TABLEの例では、DISTRIBUTED BY xxx文が使用されていないため、StarRocksはデフォルトでランダムバケット法を使用し、バケット数を自動的に設定します。

CREATE TABLE site_access1(
    event_day DATE,
    site_id INT DEFAULT '10', 
    pv BIGINT DEFAULT '0' ,
    city_code VARCHAR(100),
    user_name VARCHAR(32) DEFAULT ''
)
DUPLICATE KEY(event_day,site_id,pv);

ただし、StarRocksのバケッティングメカニズムに精通している場合、ランダムバケット法でテーブルを作成する際にバケット数を手動で設定することもできます。

CREATE TABLE site_access2(
    event_day DATE,
    site_id INT DEFAULT '10', 
    pv BIGINT DEFAULT '0' ,
    city_code VARCHAR(100),
    user_name VARCHAR(32) DEFAULT ''
)
DUPLICATE KEY(event_day,site_id,pv)
DISTRIBUTED BY RANDOM BUCKETS 8; -- バケット数を8に手動で設定

ハッシュバケット法​

StarRocksは、バケッティングキーとバケット数に基づいて、パーティション内のデータをバケットに細分化するためにハッシュバケット法を使用できます。ハッシュバケット法では、ハッシュ関数がデータのバケッティングキーの値を入力として取り、ハッシュ値を計算します。データは、ハッシュ値とバケットの間のマッピングに基づいて対応するバケットに保存されます。

利点​

  • クエリパフォーマンスの向上: 同じバケッティングキーの値を持つ行は同じバケットに保存され、クエリ中にスキャンされるデータ量を減らします。

  • 均等なデータ分散: 高いカーディナリティ（ユニークな値の数が多い）を持つ列をバケッティングキーとして選択することで、データをバケット全体により均等に分散させることができます。

バケッティング列の選び方​

次の2つの要件を満たす列をバケッティング列として選択することをお勧めします。

  • 高いカーディナリティを持つ列（例: ID）
  • クエリのフィルタとして頻繁に使用される列

ただし、どちらの要件も満たす列がない場合、クエリの複雑さに応じてバケッティング列を決定する必要があります。

  • クエリが複雑な場合、データをバケット全体にできるだけ均等に分散させ、クラスターリソースの利用率を向上させるために、高いカーディナリティを持つ列をバケッティング列として選択することをお勧めします。
  • クエリが比較的単純な場合、クエリで頻繁にフィルタ条件として使用される列をバケッティング列として選択し、クエリ効率を向上させることをお勧めします。

パーティションデータが1つのバケッティング列を使用してバケット全体に均等に分散できない場合、複数のバケッティング列を選択することができます。ただし、3列を超えないことをお勧めします。

注意事項​

  • テーブル作成時にバケッティング列を指定する必要があります。
  • バケッティング列のデータ型は、INTEGER、DECIMAL、DATE/DATETIME、またはCHAR/VARCHAR/STRINGである必要があります。
  • バケッティング列は指定後に変更できません。

例​

次の例では、site_accessテーブルがsite_idをバケッティング列として使用して作成されます。さらに、site_accessテーブルのデータがクエリされるとき、データはしばしばサイトでフィルタされます。site_idをバケッティングキーとして使用することで、クエリ中に関連性のないバケットの多くを削除できます。

CREATE TABLE site_access(
    event_day DATE,
    site_id INT DEFAULT '10',
    city_code VARCHAR(100),
    user_name VARCHAR(32) DEFAULT '',
    pv BIGINT SUM DEFAULT '0'
)
AGGREGATE KEY(event_day, site_id, city_code, user_name)
PARTITION BY RANGE(event_day)
(
    PARTITION p1 VALUES LESS THAN ("2020-01-31"),
    PARTITION p2 VALUES LESS THAN ("2020-02-29"),
    PARTITION p3 VALUES LESS THAN ("2020-03-31")
)
DISTRIBUTED BY HASH(site_id);

テーブルsite_accessの各パーティションに10個のバケットがあると仮定します。次のクエリでは、10個のバケットのうち9個が削除されるため、StarRocksはsite_accessテーブルのデータの1/10のみをスキャンする必要があります。

select sum(pv)
from site_access
where site_id = 54321;

ただし、site_idが不均等に分散され、多くのクエリが少数のサイトのデータのみを要求する場合、1つのバケッティング列のみを使用すると、深刻なデータスキューが発生し、システムのパフォーマンスボトルネックを引き起こす可能性があります。この場合、バケッティング列の組み合わせを使用できます。たとえば、次の文では、site_idとcity_codeをバケッティング列として使用しています。

CREATE TABLE site_access
(
    site_id INT DEFAULT '10',
    city_code SMALLINT,
    user_name VARCHAR(32) DEFAULT '',
    pv BIGINT SUM DEFAULT '0'
)
AGGREGATE KEY(site_id, city_code, user_name)
DISTRIBUTED BY HASH(site_id,city_code);

実際には、ビジネスの特性に基づいて1つまたは2つのバケッティング列を使用できます。1つのバケッティング列site_idを使用することは、短いクエリに非常に有益です。これは、ノード間のデータ交換を減らし、クラスター全体のパフォーマンスを向上させるためです。一方、2つのバケッティング列site_idとcity_codeを採用することは、長いクエリに有利です。これは、分散クラスターの全体的な並列性を活用してパフォーマンスを大幅に向上させることができるためです。

注意

  • 短いクエリは、少量のデータをスキャンし、単一のノードで完了できます。
  • 長いクエリは、大量のデータをスキャンし、分散クラスター内の複数のノードでの並列スキャンによってパフォーマンスを大幅に向上させることができます。

バケット数の決定​

バケットは、StarRocksでデータファイルが実際にどのように組織されているかを反映しています。

  • テーブル作成時にバケット数を設定する方法

    • 方法1: バケット数を自動的に設定する

      v2.5.7以降、StarRocksはマシンリソースとデータ量に基づいてパーティションのバケット数を自動的に設定できます。

      例:

      CREATE TABLE site_access(
        site_id INT DEFAULT '10',
        city_code SMALLINT,
        user_name VARCHAR(32) DEFAULT '',
        pv BIGINT SUM DEFAULT '0'
      )
      AGGREGATE KEY(site_id, city_code, user_name)
      DISTRIBUTED BY HASH(site_id,city_code); -- バケット数を設定する必要はありません

      この機能を有効にするには、FE動的パラメータenable_auto_tablet_distributionがTRUEに設定されていることを確認してください。テーブルが作成された後、StarRocksによって自動的に設定されたバケット数を表示するには、SHOW CREATE TABLEを実行できます。

      注意

      パーティションの生データサイズが100 GBを超える場合、方法2を使用してバケット数を手動で設定することをお勧めします。

    • 方法2: バケット数を手動で設定する

      v2.4.0以降、StarRocksはクエリ中にタブレットを並列にスキャンするために複数のスレッドを使用することをサポートしており、スキャンパフォーマンスのタブレット数への依存を減らします。各タブレットに約10 GBの生データを含めることをお勧めします。バケット数を手動で設定する場合、テーブルの各パーティションのデータ量を見積もり、その後タブレット数を決定できます。

      タブレットでの並列スキャンを有効にするには、enable_tablet_internal_parallelパラメータがシステム全体でTRUEに設定されていることを確認してください（SET GLOBAL enable_tablet_internal_parallel = true;）。

      CREATE TABLE site_access (
          site_id INT DEFAULT '10',
          city_code SMALLINT,
          user_name VARCHAR(32) DEFAULT '',
          pv BIGINT SUM DEFAULT '0')
      AGGREGATE KEY(site_id, city_code, user_name)
      -- パーティションにロードしたい生データの量が300 GBであると仮定します。
      -- 各タブレットに10 GBの生データを含めることをお勧めするため、バケット数は30に設定できます。
      DISTRIBUTED BY HASH(site_id,city_code) BUCKETS 30;

  • 新しいパーティションを追加する際のバケット数の設定方法

    注意

    既存のパーティションのバケット数を変更することはできません。

    • 方法1: バケット数を自動的に設定する（推奨）

      v2.5.7以降、StarRocksはマシンリソースとデータ量に基づいてパーティションのバケット数を自動的に設定することをサポートしています。この機能を有効にするには、FE動的パラメータenable_auto_tablet_distributionがデフォルト値TRUEを保持していることを確認してください。

      この機能を無効にするには、ADMIN SET FRONTEND CONFIG ('enable_auto_tablet_distribution' = 'false');文を実行します。そして、新しいパーティションを追加する際にバケット数を指定しない場合、新しいパーティションはテーブル作成時に設定されたバケット数を継承します。新しいパーティションが正常に追加された後、StarRocksによって新しいパーティションに自動的に設定されたバケット数を表示するには、SHOW PARTITIONSを実行できます。

    • 方法2: バケット数を手動で設定する

      新しいパーティションを追加する際に、バケット数を手動で指定することもできます。新しいパーティションのバケット数を計算するには、上記のテーブル作成時にバケット数を手動で設定する際に使用したアプローチを参照できます。

      -- 手動でパーティションを作成
      ALTER TABLE <table_name> 
      ADD PARTITION <partition_name>
          [DISTRIBUTED BY HASH (k1[,k2 ...]) [BUCKETS num]];
          
      -- 動的パーティション化
      ALTER TABLE <table_name> 
      SET ("dynamic_partition.buckets"="xxx");