判断: どのパーティショニング戦略か?

パーティショニングは、大きなテーブルを単一の論理名の下で複数の物理的な断片に分割し、古いデータの削除を容易にし、クエリが該当する断片のみを参照できるようにする (パーティションプルーニング)。ただし、小さなテーブルでは複雑さが増すだけ。このツリーは、まずパーティショニングが本当に必要かを問い、その上でアクセスと分布のパターンに基づいて Range、List、Hash、Composite の中から選択を導く。

テーブルは本当にパーティショニングが必要なほど大きいか?

パーティショニングはパフォーマンスの魔法ではなく、スケールとメンテナンス (ライフサイクル) のためのツール。テーブルが十分に大きくない場合や、クエリがすでにインデックスで十分なパフォーマンスを発揮している場合、パーティショニングは実行計画の複雑さと管理のオーバーヘッドをもたらすだけ。テーブルは数千万行以上/数百 GB に達しているか、それともまだ小/中規模か?

• はい、非常に大きい、または古いデータを一括で削除/アーカイブする必要がある
• いいえ、小/中規模のテーブル、または確信がない

データにどのようにアクセスし、どのように分割すべきか?

パーティションキーは、大多数のクエリがフィルタに使う列にすべきであり、そうして初めてプルーニングが機能する。主なアクセスパターンは何か? 日付/連続した範囲 (直近 30 日) か、特定のカテゴリ/リージョンの値か、それとも明確なフィルタがなく負荷を均等に分散したいのか?

• 日付/シーケンス番号などの連続した範囲 (直近 X 日、月単位)
• カテゴリ/リージョン/テナントなどの離散的な値の集合
• 明確な範囲/カテゴリがない。目的は負荷の均等な分散
• 日付と大量データの両方。2 つの次元で分割する必要がある

推奨: (まだ) パーティショニングしない

小/中規模のテーブルではパーティショニングの利点はない。適切に選んだインデックスと通常のメンテナンスで十分。時期尚早なパーティショニングは実行計画を複雑にし、誤ったキーではプルーニングが効かず、運用のオーバーヘッドが増える。

推奨: Range パーティショニング

Range パーティショニングは、列の連続した範囲 (例: 日付範囲: 月/四半期ごとに 1 パーティション) で行を分割する。時系列や継続的に増加するテーブルにとって最も一般的かつ強力な戦略。

推奨: List パーティショニング

List パーティショニングは、列の離散的で既知の値 (例: region = 'TR','EU','US' やテナント ID) で行をグループ化する。自然で有限のカテゴリが存在する場合、アクセスと管理が明確になる。

推奨: Hash パーティショニング (均等な分散)

Hash パーティショニングは、キー列のハッシュに基づき、あらかじめ定めた数のパーティションに行を比較的均等に分散する。自然な範囲/カテゴリがない場合に、ホットスポットを回避し負荷を分散するために使用する。

推奨: Composite (多階層) パーティショニング

Composite パーティショニングは 2 つの戦略を組み合わせる: まず上位レベルで分割し、次に各パーティションをサブパーティションに分割する (例: Range-by-Hash や Range-by-List)。時間ベースのライフサイクルと、均等な分散/カテゴリの分離の両方が同時に必要な場合に使用する。