純粋な LIST パーティショニングは、2 つの状況で機能しなくなります。1 つは、テーブル作成時にパーティションキーの値のセットがオープンエンドであるか不明な場合、もう 1 つは、ロングテールディストリビューションにより、すべての少量キーに独自のパーティションを割り当てることが非現実的になる場合です。LIST DEFAULT HASH パーティショニングは、大量キー用の専用 LIST パーティションと、その他すべてを自動的に吸収するハッシュサブパーティションを組み合わせることで、これらの問題を両方とも解決します。
ユースケース
次のいずれかの条件に当てはまる場合は、LIST DEFAULT HASH パーティショニングを使用します。
パーティションキーの値を完全に列挙できない — テーブル作成時に、取りうる値がオープンエンドであるか不明な場合。
キーのロングテールディストリビューション — 少数の大量キーがデータの大部分を保持し、多数の少量キーが残りを共有している場合。一般的な兆候は 80/20 パターンです。つまり、パーティションキーの値の 20% がデータの 80% を保持し、値の 80% が残りの 20% を保持します。
どちらの場合も、すべての少量キーを名前付き LIST パーティションに強制的に割り当てると、パーティションが無駄になり、メンテナンスオーバーヘッドが増加します。LIST DEFAULT HASH パーティショニングを使用すると、大量キーに専用の LIST パーティションを割り当て、その他すべてを、ロードを均等に分散するハッシュサブパーティションのセットにルーティングできます。
マルチテナントの例
少数の主要アカウントがデータの大部分を生成するマルチテナントの注文システムが典型的な例です。次の表に、代表的なディストリビューションを示します。
| テナント | データボリューム | パーティション |
|---|---|---|
| 主要アカウント 1 | 3,000 万行 | p1 |
| 主要アカウント 2 | 2,600 万行 | p2 |
| 主要アカウント 3 | 2,400 万行 | p3 |
| 主要アカウント 4 | 2,000 万行 | p4 |
| 中小規模の顧客 | 3,000 万行 (合計) | p_others |
4 つの主要アカウントはそれぞれ、高速で分離されたアクセスのために専用の LIST パーティションを取得します。残りのすべての顧客は p_others にルーティングされます。これは、3 つのハッシュサブパーティション (DEFAULT PARTITIONS 3) によってサポートされており、結合されたロードを均等に分散します。
CREATE TABLE cust_orders
(
customer_id VARCHAR(36),
year VARCHAR(60),
order_id INT,
order_content TEXT
) PARTITION BY LIST COLUMNS(customer_id)
(
PARTITION p1 VALUES IN ('Key account 1'),
PARTITION p2 VALUES IN ('Key account 2'),
PARTITION p3 VALUES IN ('Key account 3'),
PARTITION p4 VALUES IN ('Key account 4'),
PARTITION p_others DEFAULT PARTITIONS 3 -- 他のすべての customer_id 値をキャッチし、3 つのハッシュサブパーティションに分割します
);