【テクニカル・上級編】宣言的パーティショニングの設計 – PostgreSQL

宣言的パーティショニング：その「境界線」をどこに引くか

PostgreSQLで大規模データを扱う際、避けては通れないのがパーティショニングだ。かつての継承（Inheritance）ベースのトリガー地獄を知る古参エンジニアからすれば、PostgreSQL 10で導入された宣言的パーティショニングは、まさに夜明けだったと言っていい。

だが、設計を誤れば、それは「スケーラビリティの救世主」ではなく「パフォーマンスを食いつぶす負債」へと一瞬で変貌する。今回は、現場で数多のクエリ計画を追いかけてきた経験から、この「境界線」の設計哲学について少し深く語ってみたい。

—

1. 選択基準：どの戦略を選ぶべきか

パーティショニングの設計において最も重要なのは、「クエリがパーティションキーをどう解釈するか」だ。

RANGEパーティショニング（時系列の鉄板）

`created_at` のようなタイムスタンプで区切るのが定石だ。ログやトランザクション履歴など、データが時間軸で流れていくならこれ一択。ただし、古いパーティションをデタッチして捨てる（あるいはアーカイブする）運用フローまで設計に組み込めているかが鍵になる。

LISTパーティショニング（分類の境界）

地域別（`region_id`）やステータス別など、離散的な値で分ける場合だ。クエリが常に特定のリージョンにアクセスするようなマルチテナント構成なら、非常に高いキャッシュ効率が得られる。

HASHパーティショニング（ホットスポットの分散）

意外と見落とされがちだが、特定のキーにアクセスが集中する際の「書き込みの分散」には有効だ。ただし、範囲指定クエリ（`WHERE id > 100 AND id < 200`）が走った瞬間、全パーティションをスキャンするコストを支払うことになる。この「トレードオフ」をクライアントに説明できるかが、エンジニアとしての腕の見せ所だ。

2. キー設計の罠：見えないオーバーヘッド

パーティションキーを選ぶ際、つい「検索条件になりやすいカラム」を選んでしまう。それは正しい。だが、「パーティションキーは、主キー（Primary Key）の一部であるべき」というPostgreSQLの制約を忘れてはならない。

もしパーティションキーが主キーに含まれていない場合、ユニーク制約を維持するために、PostgreSQLはすべてのパーティションを跨いだグローバルなチェックが必要になる。これは大規模な環境では致命的なパフォーマンス低下を招く。

設計の極意は「論理的なビジネス境界」と「物理的な主キーの境界」を合致させることだ。ここがズレていると、`INSERT`のたびにインデックスの肥大化と戦う羽目になる。

3. サブパーティショニング：多階層の「深淵」

「とりあえず細かく分けよう」と、無計画にサブパーティションを掘りまくるのは悪手だ。

階層を深くすると、`Constraint Exclusion`（制約除外）の判断コストが増大する。クエリプランナが「どのパーティションを見ればいいか」を判断する際、計算量だけでなく、システムカタログ（`pg_class`や`pg_partitioned_table`）へのアクセスも増える。

私の経験則だが、「2階層で十分」だ。それ以上が必要なら、それはデータモデリングそのものを見直すべきフェーズかもしれない。例えば、時系列データであれば「月次パーティション＞週次パーティション」程度に留め、それ以上の細分化はアプリケーション側のキャッシュ戦略で吸収するのが、運用コストとパフォーマンスのバランスが最も良い。

4. トラブルシューティング：プランナを味方につける

パーティショニングを使っていて一番悲しいのは、「設計したはずなのに全パーティションをスキャンしている」ときだ。

これを検知するには、`EXPLAIN (ANALYZE, BUFFERS)` の出力を眺めるのが一番の近道だ。`Subplans Removed` の項目を確認してほしい。もしここが期待通りでないなら、以下の原因を疑うべきだ。

型変換の発生: パーティションキーが `integer` なのに、クエリで `string` を渡していないか？（暗黙の型キャストは、プランナを盲目にする）
関数呼び出し: `WHERE created_at > NOW() – INTERVAL ‘1 day’` のような動的なクエリは、プラン作成時に定数として評価されない場合がある。あえて定数値を埋め込んだクエリを投げるか、プランキャッシュの挙動を再確認する必要がある。

最後に：エンジニアとしての矜持

パーティショニングは「銀の弾丸」ではない。あくまで、巨大なデータを効率よく制御するための「地図」に過ぎない。

大切なのは、データがどう増え、どうアクセスされるかを想像することだ。データベースエンジニアは、単にテーブルを定義するだけでなく、その先にある「数年後のデータ量」と「クエリの呼吸」を設計しなければならない。

次にあなたが `CREATE TABLE PARTITION BY…` を打つとき、その境界線がどのような未来を見据えているか、一瞬だけ考えてみてほしい。そこにはきっと、美しいクエリ計画が待っているはずだ。