バケット法
StarRocks におけるハッシュバケット法とランダムバケット法の選択に関する簡潔なガイドで、それぞれの仕組み、トレードオフ、および推奨される使用ケースを含みます。
クイックルック比較
| 項目 | ハッシュバケット法 | ランダムバケット法 |
|---|---|---|
| 例 | DISTRIBUTED BY HASH(id) BUCKETS 16 | DISTRIBUTED BY RANDOM |
| キー宣言 | 必須 HASH(col1, …) | なし – 行はラウンドロビンで割り当て |
| 省略時の初期バケット数 | CREATE 時に自動選択、その後固定 | CREATE 時に自動選択; bucket_size 設定で増加可能 |
| タブレットの分割/縮小 | 手動 ALTER … BUCKETS | 自動分割 ⇢ 増加のみ (≥ v3.2) |
| スキュー耐性 | キーのカーディナリティに依存 | 高 – 設計上均一 |
| バケットプルーニング | ✅ (フィルター、ジョイン) | 🚫 (フルタブレットスキャン) |
| コロケートジョイン | ✅ | 🚫 |
| ローカル集約/バケットシャッフルジョイン | ✅ | 🚫 |
| サポートされるテーブルタイプ | 全て | 重複キーテーブルのみ |
ハッシュバケット法
仕組み
行は1つ以上の列をハッシュすることでタブレットに割り当てられます。タブレット数は作成後に固定され、手動で変更しない限り変わりません。
要件
- 安定して均一で高カーディナリティのキーを事前に選ぶ必要があります。カーディナリティは通常、ハッシュバケット間のデータスキューを防ぐために BE ノード数の1000倍以上であるべきです。
- 初期バケットサイズを適切に選択し、理想的には1〜10 GBの範囲にします。
強み
- クエリの局所性 – 選択的なフィルターとジョインが少ないタブレットに触れる。
- コロケートジョイン – ファクト/ディムテーブルが高速ジョインのためにハッシュキーを共有できる。
- 予測可能なレイアウト – 同じキーを持つ行は常に一緒に配置される。
- ローカル集約とバケットシャッフルジョイン – パーティション間で同一のハッシュレイアウトがローカル集約を可能にし、大規模ジョインのデータシャッフルコストを削減。
弱み
- データ分布が偏るとホットタブレットに脆弱。
- タブレット数は静的で、スケーリングにはメンテナンス DDL が必要。
- タブレットが不十分だとデータ取り込み、データコンパクション、クエリ実行の並行性に悪影響を及ぼす可能性がある。
- タブレットを過剰に使用するとメタデータのフットプリントが拡大する。
例: ディメンション-ファクトジョインとタブレットプルーニング
-- ファクトテーブルは (customer_id) でパーティション化され、ハッシュバケット化される
CREATE TABLE sales (
sale_id bigint,
customer_id int,
sale_date date,
amount decimal(10,2)
) ENGINE = OLAP
DISTRIBUTED BY HASH(customer_id) BUCKETS 48
PARTITION BY date_trunc('DAY', sale_date)
PROPERTIES ("colocate_with" = "group1");
-- ディメンションテーブルは同じキーとバケット数でハッシュバケット化され、sales テーブルとコロケートされる
CREATE TABLE customers (
customer_id int,
region varchar(32),
status tinyint
) ENGINE = OLAP
DISTRIBUTED BY HASH(customer_id) BUCKETS 48
PROPERTIES ("colocate_with" = "group1");
-- StarRocks はタブレットプルーニングを行うことができる
SELECT sum(amount)
FROM sales
WHERE customer_id = 123
-- StarRocks はローカル集約を行うことができる
SELECT customer_id, sum(amount) AS total_amount
FROM sales
GROUP BY customer_id
ORDER BY total_amount DESC LIMIT 100;
-- StarRocks はコロケートジョインを行うことができる
SELECT c.region, sum(s.amount)
FROM sales s JOIN customers c USING (customer_id)
WHERE s.sale_date BETWEEN '2025-01-01' AND '2025-01-31'
GROUP BY c.region;
この例から得られるものは？
- タブレットプルーニング: customer_id の述語
WHERE customer_id = 123によりバケットプルーニングが可能になり、クエリは単一のタブレットにのみアクセスし、特にポイントルックアップでレイテンシーと CPU サイクルを削減します。 - ローカル集約: ハッシュ分布キーが集約キーのサブセットである場合、StarRocks はシャッフル集約フェーズをバイパスでき、全体のコストを削減します。
- コロケートジョイン: 両方のテーブルがバケット数とキーを共有しているため、各 BE はネットワークシャッフルなしでローカルのタブレットペアをジョインできます。
使用するタイミング
- よく知られた分布フィルター/ジョインキーを持つ安定したスキーマ。
- バケットプルーニングの恩恵を受けるデータウェアハウジングワークロード。
- コロケートジョイン/バケットシャッフルジョイン/ローカル集約のような特定の最適化が必要な場合。
- Aggregate/Primary Key テーブルを使用している場合。
ランダムバケット法
仕組み
行はラウンドロビンで割り当てられ、キーは指定されません。PROPERTIES ("bucket_size"="<bytes>") を使用すると、StarRocks はパーティションが成長するにつれてタブレットを動的に分割します (v3.2+)。
強み
- ゼロ設計負債–キーもバケット計算も不要。
- スキュー耐性のある書き込み–ディスクと BEs に均一な負荷。
- 弾力的な成長–タブレット分割がデータやクラスターの成長に伴い取り込みを高速化。
弱み
- バケットプルーニングなし–すべてのクエリがパーティション内のすべてのタブレットをスキャン。
- コロケートジョインなし–キーなしレイアウトが局所性を防ぐ。
- 現在は 重複キーテーブル のみに制限。
使用するタイミング
- キーが変わるかスキューするログ/イベントやマルチテナント SaaS テーブル。
- 均一な取り込みスループットが重要な書き込み負荷の高いパイプライン。
運用ガイドライン
- ランダムバケット法には自動分割を可能にするためにバケットサイズ (例: 1 GiB) を選択します。
- ハッシュバケット法の場合、タブレットサイズを監視し、タブレットが5〜10 GiBを超える前に再シャードします。