データ分散
テーブル作成時に適切なパーティション化とバケッティングを設定することで、均等なデータ分散を実現できます。均等なデータ分散とは、特定のルールに基づいてデータをサブセットに分割し、異なるノードに均等に分散することを意味します。これにより、スキャンするデータ量を減らし、クラスターの並列処理能力を最大限に活用することで、クエリパフォーマンスを向上させることができます。
注意
- テーブル作成時にデータ分散が指定され、ビジネスシナリオにおけるクエリパターンやデータ特性が進化した場合、v3.2以降のStarRocksでは、テーブル作成後に特定のデータ分散関連プロパティを変更して、最新のビジネスシナリオにおけるクエリパフォーマンスの要件を満たすことができます。
- v3.1以降、テーブル作成時やパーティション追加時にDISTRIBUTED BY句でバケッティングキーを指定する必要はありません。StarRocksはランダムバケット法をサポートしており、データをすべてのバケットにランダムに分散します。詳細はランダムバケット法を参照してください。
- v2.5.7以降、テーブル作成時やパーティション追加時にバケット数を手動で設定しないことを選択できます。StarRocksは自動的にバケット数 (BUCKETS) を設定します。ただし、StarRocksが自動的にバケット数を設定した後にパフォーマンスが期待に応えない場合で、バケッティングメカニズムに精通している場合は、バケット数を手動で設定することもできます。
概要
一般的な分散方法
現代の分散データベースシステムは、一般的に次の基本的な分散方法を使用し ます: ラウンドロビン、レンジ、リスト、ハッシュ。
- ラウンドロビン: データを異なるノードに循環的に分散します。
- レンジ: パーティション列の値の範囲に基づいてデータを異なるノードに分散します。図に示すように、範囲 [1-3] と [4-6] は異なるノードに対応しています。
- リスト: パーティション列の離散値に基づいてデータを異なるノードに分散します。たとえば、性別や州などの離散値が各ノードにマッピングされ、複数の異なる値が同じノードにマッピングされることがあります。
- ハッシュ: ハッシュ関数に基づいてデータを異なるノードに分散します。
より柔軟なデータパーティション化を実現するために、上記のデータ分散方法のいずれかを使用するだけでなく、特定のビジネス要件に基づいてこれらの方法を組み合わせることもできます。一般的な組み合わせには、ハッシュ+ハッシュ、レンジ+ハッシュ、ハッシュ+リストがあります。
StarRocksにおける分散方法
StarRocksは、データ分散方法の個別使用と複合使用の両方をサポートしています。
注意
一般的な分散方法に加えて、StarRocksはバケッティング設定を簡素化 するためにランダム分散もサポートしています。
また、StarRocksは2レベルのパーティション化 + バケッティング方法を実装してデータを分散します。
- 第1レベルはパーティション化です: テーブル内のデータはパーティション化できます。サポートされているパーティション化の手法は、式に基づくパーティション化、レンジパーティション化、リストパーティション化です。また、パーティション化を使用しないことも選択できます(テーブル全体が1つのパーティションと見なされます)。
- 第2レベルはバケッティングです: パーティション内のデータはさらに小さなバケットに分配する必要があります。サポートされているバケッティング方法は、ハッシュとランダムバケット法です。
分散方法 | パーティション化とバケッティング方法 | 説明 |
---|---|---|
ランダム分散 | ランダムバケット法 | テーブル全体が1つのパーティションと見なされます。テーブル内のデータは異なるバケットにランダムに分配されます。これはデフォルトのデータ分散方法です。 |
ハッシュ分散 | ハッシュバケット法 | テーブル全体が1つのパーティションと見なされます。テーブル内のデータは、ハッシュ関数を使用してデータのバケッティングキーのハッシュ値に基づいて対応するバケットに分配されます。 |
レンジ+ランダム分散 |
|
|
レンジ+ハッシュ分散 |
|
|
リスト+ランダム分散 |
|
|
リスト+ハッシュ分散 |
|
|
ランダム分散
テーブル作成時にパーティション化と バケッティング方法を設定しない場合、デフォルトでランダム分散が使用されます。この分散方法は現在、重複キーテーブルの作成にのみ使用できます。
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つ以上のパーティション列で構成されます。適切なパーティション列を選択することで、クエリ時にスキャンするデータ量を効果的に減らすことができます。ほとんどのビジネスシステムでは、時間に基づくパーティション化が一般的に採用されており、期限切れデータの削除による特定の問題を解決し、ホットデータとコールドデータの階層型ストレージの管理を容易にします。この場合、式に基づくパーティション化またはレンジパーティション化を使用し、時間列をパーティション列として指定できます。さらに、データが頻繁にENUM値に基づいてクエリおよび管理される場合、式に基づくパーティション化またはリストパーティション化を使用し、これらの値を含む列をパーティション列として指定できます。
- パーティション粒度を選択する際には、データ量、クエリパターン、データ管理の粒度を考慮する必要があります。
- 例1: テーブル内の月間データ量が少ない場合、日ごとにパーティション化するよりも月ごとにパーティション化することでメタデータの量を減らし、メタデータ管理とスケジューリングのリソース消費を削減できます。
- 例2: テーブル内の月間データ量が多く、クエリが特定の日のデータを主に要求する場合、日ごとにパーティション化することでクエリ時にスキャンするデータ量を効果的に減らすことができます。
- 例3: データが日ごとに期限切れになる必要がある場合、日ごとにパーティション化することをお勧めします。
バケッティング
バケッティングの手法は、パーティションを複数のバケットに分割します。バケット内のデータはtabletと呼ばれます。
サポートされているバケッティング方法は、ランダムバケット法 (v3.1以降) と ハッシュバケット法 です。
-
ランダムバケット法: テーブル作成時またはパーティション追加時にバケッティングキーを設定する必要はありません。パーティション内のデータは異なるバケットにランダムに分配されます。
-
ハッシュバケット法: テーブル作成時またはパーティション追加時にバケッティングキーを指定する必要があります。同じパーティション内のデータはバケッティングキーの値に基づいてバケットに分割され、バケッティングキーの同じ値を持つ行は対応するユニークなバケットに分配されます。
バケット数: デフォルトでは、StarRocksは自動的にバケット数を設定します (v2.5.7以降)。バケット数を手動で設定することもできます。詳細については、バケット数の決定を参照してください。
パーティションの作成と管理
パーティションの作成
式に基づくパーティション化 (推奨)
注意
StarRocksの共有データモードは、v3.1.0から時間関数式を、v3.1.1から列式をサポートしています。
v3.0以降、StarRocksは式に基づくパーティション化をサポートしており、以前は自動パーティション化として知られていました。このパーティション化の手法は、連続した日付範囲やENUM値に基 づいてデータをクエリおよび管理するほとんどのシナリオに適しています。
テーブル作成時にパーティション式を設定するだけで、StarRocksはデータロード中に自動的にパーティションを作成します。事前に多数のパーティションを手動で作成する必要はなく、動的パーティションプロパティを設定する必要もありません。
v3.4以降、式に基づくパーティション化はさらに最適化され、すべてのパーティション戦略を統一し、より複雑なソリューションをサポートします。ほとんどの場合に推奨されており、将来のリリースで他のパーティション戦略を置き換える予定です。
例1: DATETIME列を使用したシンプルな時間関数式。
CREATE TABLE site_access(
event_day DATETIME NOT NULL,
site_id INT DEFAULT '10',
city_code VARCHAR(100),
user_name VARCHAR(32) DEFAULT '',
pv BIGINT DEFAULT '0'
)
DUPLICATE KEY(event_day, site_id, city_code, user_name)
PARTITION BY time_slice(event_day, INTERVAL 7 day)
DISTRIBUTED BY HASH(event_day, site_id)
例2: 複数の列を使用した列式。
CREATE TABLE t_recharge_detail1 (
id bigint,
user_id bigint,
recharge_money decimal(32,2),
city varchar(20) not null,
dt varchar(20) not null
)
DUPLICATE KEY(id)
PARTITION BY dt,city
DISTRIBUTED BY HASH(`id`);
例3: Unixタイムスタンプ列を使用した複雑な時間関数式。
CREATE TABLE orders (
ts BIGINT NOT NULL,
id BIGINT NOT NULL,
city STRING NOT NULL
)
PARTITION BY from_unixtime(ts,'%Y%m%d');
例4: 時間関数式と列式の混合式。
CREATE TABLE orders (
ts BIGINT NOT NULL,
id BIGINT NOT NULL,
city STRING NOT NULL
)
PARTITION BY from_unixtime(ts,'%Y%m%d'), city;
レンジパーティション化
レンジパーティション化は、時系列データや連続した数値データなどのシンプルな連続データを保存するのに適しています。
パーティションを手動で作成
各パーティションとパーティション列の値の範囲とのマッピング関係を定義します。