「テーブルが重い…」と悩む前に。PostgreSQLの宣言的パーティショニングで、データ管理を一生モノのスキルにしよう。
やあ、最近どうだい？ 開発現場で「データ量が増えてきて、クエリが遅くなってきたな…」なんて悩み、一度は直面するよね。
PostgreSQLを長く触っていると、数千万、数億レコードのテーブルを前にして、「これ、どうやって運用すればいいんだ？」と冷や汗をかく瞬間がある。そんな時、とりあえずインデックスを貼って誤魔化すのも一つの手だけど、根本的な解決策として覚えておいてほしいのが「宣言的パーティショニング（Declarative Partitioning）」だ。
今回は、現場の先輩として、この機能の「勘所」を解説するよ。教科書的な説明は公式ドキュメントに任せて、ここでは「実務でどう使うか」に焦点を絞るね。
—
なぜパーティショニングが必要なのか？
まず前提として、パーティショニングは「魔法の杖」じゃない。でも、正しく使えばデータのライフサイクル管理が劇的に楽になるんだ。
特に効くのは、ログや時系列データのような「ある程度古くなったら不要になる（あるいはアーカイブする）」データだね。テーブル全体を `DELETE` するなんて、重い処理を本番環境で走らせたら目も当てられない。パーティショニングを使えば、古いパーティションを切り離す（デタッチする）だけでデータ削除が完了する。これ、運用負荷が段違いだよ。
—
3つの基本パターンを使いこなす
PostgreSQLでは主に3つの分割方法がある。
1. 範囲（Range）パーティショニング：日付やIDなど、連続した値で区切る。ログ管理ならこれ一択。
2. リスト（List）パーティショニング：地域やステータスなど、離散的な値で区切る。
3. ハッシュ（Hash）パーティショニング：値をハッシュ化して分散させる。特定のパーティションへの負荷集中を避けたい時に使う。
—
実践：月次ログテーブルの設計
一番よくある「月次でデータが溜まるログテーブル」を例にしてみよう。
— 親テーブルを作る
CREATE TABLE app_logs (
log_id BIGINT NOT NULL,
log_time TIMESTAMP NOT NULL,
message TEXT
) PARTITION BY RANGE (log_time);
— 2023年10月分のパーティションを作成
CREATE TABLE app_logs_2023_10 PARTITION OF app_logs
FOR VALUES FROM (‘2023-10-01’) TO (‘2023-11-01’);
ここで重要なのが「プルーニング（Partition Pruning）」という概念だ。クエリが走った時、PostgreSQLが「ああ、この日付のデータなら、このパーティションだけ見ればいいんだな」と自動的に判断して、不要なテーブルへのアクセスをカットしてくれる。これが爆速の理由だね。
—
実務で「これだけは守れ」という鉄則
後輩の君に、現場でハマらないためのアドバイスを3つだけ伝えておくよ。
- パーティションキーをWHERE句に含める意識を持つ
パーティションキーを無視したクエリを書くと、結局全部のパーティションをスキャンすることになる。せっかく分割した意味がなくなるから、コードを書く時は常に「どのパーティションにアクセスしているか」を意識しよう。
- 「デフォルトパーティション」を作っておく
想定外の値が入ってきた時、エラーを避けるために `DEFAULT` パーティションを作成しておくのは賢い運用だ。
- インデックスは親テーブルに貼る
親テーブルにインデックスを貼れば、自動的に子パーティションにも伝搬される。個別に貼る必要はないから、管理も楽だよ。
—
最後に：パーティショニングを検討するタイミング
最後に一つ。「早すぎる最適化」は悪だ。
数千、数万レコードのテーブルに対してパーティショニングを導入するのはオーバーエンジニアリングだよ。僕の基準としては、「テーブルサイズがインデックスを含めてメモリに乗り切らなくなった時」や「データ削除のメンテナンスが現実的な時間で終わらなくなった時」に検討を始める。
データモデリングは、システムの寿命を決める重要な仕事だ。ぜひ、この機能を「道具箱」に入れて、ここぞという時に使いこなしてほしい。
もし実装で悩んだら、いつでも聞きに来てくれ。また現場で会おう。
コメント