パーティショニング
StarRocks での高速分析は、クエリパターンに合ったテーブルレイアウトから始まります。このガイドは、実践的な経験を明確なルールに凝縮し、パーティショニングを支援します。これにより、以下のことが可能になります。
- データのスキャンを減らす：積極的なパーティションプルーニングを通じて
- ライフサイクルタスクを管理する（TTL、GDPR 削除、階層化）: メタデータのみの操作で
- スムーズにスケールする：テナント数、データ量、または保持期間が増加するにつれて
- 制御された書き込み増幅：新しいデータは「ホット」パーティションに着地し、Compaction は履歴パーティションで行われます
新しいテーブルをモデル化する際や古いテーブルをリファクタリングする際には、このアドバイスを参考にしてください。各セクションでは、目的に基づいた基準、設計のヒューリスティクス、および運用上のガードレールを提供し、コストのかかる再パーティショニングを回避します。
パーティショニングとバケッティングの違い
パフォーマンスの高い StarRocks テーブルを設計する際には、パーティショニングとバケッティングの違いを理解することが重要です。どちらも大規模なデータセットを管理するのに役立ちますが、異なる目的を持っています。
- パーティショニングは、クエリ時にパーティションプルーニングを使用して StarRocks がデータのブロック全体をスキップできるようにし、古いデータやテナント固有のデータを削除するなどのメタデータのみのライフサイクル操作を可能にします。
- バケッティングは、データを tablets に分散させてクエリ実行を並列化し、特にハッシュ関数と組み合わせた場合に負荷を均等にします。
| 側面 | パーティショニング | バケッティング (ハッシュ/ランダム) |
|---|---|---|
| 主な目的 | 粗粒度のデータプルーニングとライフサイクル管理 (TTL、アーカイブ)。 | 各パーティション内での細粒度の並行性とデータのローカル性。 |
| プランナーの可視性 | パーティションは catalog オブジェクトであり、FE は述語を使用してそれらをスキップできます。 | 等価述語のみがバケットプルーニングをサポートします。 |
| ライフサイクル操作 | DROP PARTITION はメタデータのみで、GDPR 削除や月次ロールオフに最適です。 | バケットは削除できません; ALTER TABLE … MODIFY DISTRIBUTED BY でのみ変更されます。 |
| 典型的な数 | テーブルごとに 10^2–10^4（日、週、テナント）。 | パーティションごとに 10–120; StarRocks BUCKETS AUTO がこれを調整します。 |
| スキュー処理 | パーティションをマージまたは分割します。複合/ハイブリッドスキームを検討します。 | バケット数を増やし、複合キーでハッシュし、「クジラ」を分離するか、ランダムバケット法を使用します。 |
| 注意点 | >100 k パーティションは FE に大きなメモリフットプリントをもたらす可能性があります。 | >200 k tablets per BE; 10 GB を超える tablets は Compaction の問題に直面する可能性があります。 |
いつパーティショニングすべきか？
| テーブルタイプ | パーティションを使用するか？ | 典型的なキー |
|---|---|---|
| ファクト / イベントストリーム | はい | date_trunc('day', event_time) |
| 巨大なディメンション（数十億行） | 場合による | 時間またはビジネスキーの変更日 |
| 小さなディメンション / ルックアップ | いいえ | ハッシュ分散に依存 |
パーティションキーの選択
- 時間優先のデフォルト–クエリの 80% に時間フィルターが含まれる場合、
date_trunc('day', dt)を先頭にします。 - テナントの分離–テナント単位でデータを管理する必要がある場合、
tenant_idをキーに追加します。 - 保持の整合性–削除予定の列をキーに含めます。
- 複合キー:
PARTITION BY (tenant_id, date_trunc('day', dt))は完全にプルーニングしますが、#tenants × #daysのパーティションを作成します。合計約 100 k 以下に抑えないと、FE メモリと BE Compaction に影響します。
粒度の選択
PARTITION BY date_trunc('day', dt) の粒度は、ユースケースに基づいて調整する必要があります。「時間」、「日」、「月」などを使用できます。date_trunc を参照してください。
| 粒度 | 使用する場合 | 利点 | 欠点 |
|---|---|---|---|
| 日次（デフォルト） | ほとんどの BI & レポート | パーティションが少ない（365/年）; シンプルな TTL | 「直近 3 時間」のクエリには精度が低い |
| 時間単位 | > 2 × tablet per day; IoT バースト | ホットスポットの分離; 1 日 24 パーティション | 年間 8 700 パーティション |
| 週次 / 月次 | 履歴アーカイブ | メタデータが小さい; マージが容易 | 粗いプルーニング |
- 経験則: 各パーティションを ≤ 100 GB および ≤ 20 k tablets/partition across replicas に保ちます。
- 混合粒度: バージョン 3.4 から、StarRocks は履歴パーティションを粗い粒度にマージすることで混合粒度をサポートします。
例のレシピ
クリックストリームファクト（シングルテナント）
CREATE TABLE click_stream (
user_id BIGINT,
event_time DATETIME,
url STRING,
...
)
DUPLICATE KEY(user_id, event_time)
PARTITION BY (date_trunc('day', event_time))
DISTRIBUTED BY HASH(user_id) BUCKETS AUTO;
SaaS メトリクス（マルチテナント、パターン A）
ほとんどの SaaS ワークロードに推奨されます。時間でプルーニングし、テナント行を同じ場所に保ちます。
CREATE TABLE metrics (
tenant_id INT,
dt DATETIME,
metric_name STRING,
v DOUBLE
)
PRIMARY KEY(tenant_id, dt, metric_name)
PARTITION BY date_trunc('DAY', dt)
DISTRIBUTED BY HASH(tenant_id) BUCKETS AUTO;
クジラテナントの複合（パターン B）
テナント固有の DML/DDL が必要な場合や大規模なテナントが存在する場合、パーティションの爆発に注意してください。
CREATE TABLE activity (
tenant_id INT,
dt DATETIME,
id BIGINT,
....
)
DUPLICATE KEY(dt, id)
PARTITION BY (tenant_id, date_trunc('MONTH', dt))
DISTRIBUTED BY HASH(id) BUCKETS AUTO;