【実務・中級編】宣言的パーティショニングの設計 – PostgreSQL

やあ。最近、PostgreSQLの運用で「テーブルが巨大すぎてVACUUMが追いつかない」「検索クエリが重くてインデックスが効かない」なんて悩みに直面してない？

もし君が数億行規模のデータを抱えて頭を抱えているなら、そろそろ「宣言的パーティショニング」を真剣に検討するタイミングだ。教科書的なマニュアルは公式ドキュメントに任せるとして、今日は「現場でどう選んで、どう設計するか」という、泥臭い話をしようか。

—

なぜパーティショニングが必要なのか？

まず前提を共有しておこう。パーティショニングは単なる「データ分割」じゃない。「管理の単位を小さくし、クエリの検索範囲を物理的に絞り込むための戦略」だ。

インデックスが巨大すぎてメモリに乗らなくなると、PostgreSQLのパフォーマンスは劇的に落ちる。パーティショニングを使えば、必要なパーティションだけをスキャンする「パーティション・プルーニング（Partition Pruning）」が効くようになる。これこそが、巨大データを扱う時の生命線なんだ。

—

3つのパーティショニング、どう使い分ける？

PostgreSQLには主に3つの戦略がある。それぞれの「選び方」にはコツがあるんだ。

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

「期間」で分けるやつだ。ログデータや注文履歴など、時間が経つにつれて増え続けるデータにはこれ一択。

使いどころ: `created_at` のように、常に新しいデータが入るテーブル。
現場の知恵: 「古いパーティションの切り離し（DETACH）」が楽なんだ。`DROP TABLE` するより圧倒的に速いし、ログのローテーションが自動化できる。

2. LISTパーティショニング（特定カテゴリの分離）

特定の値を基準に分ける。「地域別」や「サービスID別」など、明確な境界がある場合に使う。

使いどころ: 「関東」「関西」といったエリア分けや、顧客が保有するテナントID別など。
現場の知恵: これをやると、特定の顧客IDだけデータ量が多い「ホットパーティション」が生まれやすい。その場合は、そのパーティションだけ性能の良いディスクに逃がすといった運用も検討しよう。

3. HASHパーティショニング（負荷分散の切り札）

データを均等にばらけさせる。特定のキーに対するクエリが多いけど、値が偏っている場合に有効だ。

使いどころ: ユーザーIDが大量にあって、特定のIDにアクセスが集中しそうな時。
現場の知恵: これを使うと「範囲指定検索」がほぼ死ぬ。あくまで特定のキーを指定した単発の検索がメインの時に選ぶべきだね。

—

実践：パーティションキーの設計で失敗しないために

設計で一番やってはいけないのは、「パーティションキーをWHERE句に含められない設計」だ。

例えば、`user_id`でパーティションを分けたのに、クエリが `created_at` で絞り込まれていたら？ PostgreSQLはすべてのパーティションを全スキャン（フルスキャン）せざるを得ない。パーティショニングは「宝の持ち腐れ」になるわけだ。

— 良い例：範囲検索が主なら、期間をキーにする
CREATE TABLE orders (
order_id bigint,
created_at timestamptz NOT NULL,
user_id bigint,
…
) PARTITION BY RANGE (created_at);

— 月次で分割する設計
CREATE TABLE orders_2023_10 PARTITION OF orders
FOR VALUES FROM (‘2023-10-01’) TO (‘2023-11-01’);

—

サブパーティショニングの「罠」

「期間で分けて、さらにユーザーIDで分ければ最強じゃないか？」と思うかもしれない。いわゆるマルチレベル・パーティショニングだ。

確かに理論上は美しい。でも、やりすぎると管理コストで死ぬ。

パーティションの数が数千個を超えると、クエリの計画作成（プランニング）だけでCPUを食い始める。「あれ、クエリを投げてから実行されるまでやけに時間がかかるな？」と思ったら、それが原因だ。

僕からのアドバイス:
サブパーティショニングは「どうしても必要な理由（例：テラバイト級のデータを期間と地域で厳密に分けたい）」がある時だけにしよう。まずは1階層で限界まで頑張る。それがプロの判断だ。

—

最後に：運用の心得

パーティショニングを導入したなら、「パーティション管理の自動化」を忘れないでほしい。

`pg_partman` という拡張機能を知っているかな？これを使わずに手動で `CREATE TABLE` を繰り返すのは、現代のエンジニアとしてあまりに非効率だ。自動的に未来のパーティションを作成し、古いものを削除（またはアーカイブ）してくれる。この運用自動化までセットで設計するのが、真のデータベースエンジニアの仕事だよ。

最初は複雑に見えるかもしれないけれど、一度慣れてしまえば、巨大データを扱う時の視界がグッと開けるはずだ。

次はどんな課題で躓いているか、また聞かせてくれ。応援してるよ。