【実務・中級編】 FDWを用いたパーティショニング – PostgreSQL

やあ。また会ったね。今日は少しニッチだけど、大規模データを扱う現場なら一度は夢見る「PostgreSQLの外部パーティション」について話をしようか。

「巨大なテーブルを分割して高速化したい。でも、古いデータはストレージを圧迫するし、いっそ別のサーバーや安価なストレージに移せないか？」

そう思ったことはないかな。PostgreSQLには `postgres_fdw` という強力な武器がある。これを使えば、あたかもローカルにあるかのように、遠隔地のサーバーにあるテーブルをパーティションとして組み込めるんだ。これが「外部パーティション」の魔法だね。

—

普通、パーティショニングは単一のインスタンス内で完結させるものだよね。でも、データがテラバイト級になると、バックアップ時間やインデックスの再構築が無視できないコストになってくる。

そこで、「ホットなデータは高速なSSDを積んだメイン機に、アーカイブデータは安価なサーバーの外部テーブルに」という構成が活きてくるわけさ。運用負荷を分散できるのは、エンジニアにとって大きなメリットだ。

まずは、外部サーバーの接続設定からだ。これ自体は難しくない。

— 拡張機能を有効化
CREATE EXTENSION IF NOT EXISTS postgres_fdw;

— 外部サーバーの定義
CREATE SERVER foreign_server
FOREIGN DATA WRAPPER postgres_fdw
OPTIONS (host ‘archive-db.example.com’, dbname ‘archive_db’);

— ユーザーマッピング
CREATE USER MAPPING FOR current_user
SERVER foreign_server OPTIONS (user ‘db_user’, password ‘password’);

ここからが本題だ。メインのテーブルを宣言し、外部テーブルをパーティションとしてぶら下げる。

— 親テーブル
CREATE TABLE logs (
id bigint,
created_at timestamp,
data text
) PARTITION BY RANGE (created_at);

— 外部パーティションの作成
CREATE FOREIGN TABLE logs_2023_archive
PARTITION OF logs
FOR VALUES FROM (‘2023-01-01’) TO (‘2024-01-01’)
SERVER foreign_server;

これだけで、`SELECT FROM logs WHERE created_at = ‘2023-05-01’` と叩けば、内部的に外部サーバーへクエリが飛ぶようになる。便利だろ？

—

さて、ここからが現場の知恵だ。「外部テーブルに対するインデックスはどうすべきか？」

結論から言うと、「ローカルのインデックスは外部テーブルには効かない」。これ、うっかり忘れがちなんだけど超重要なんだ。

外部テーブルのインデックスは、あくまで「その外部サーバー」に張る必要がある。親テーブルでクエリを投げると、外部サーバー側でインデックスが効いた状態で検索が行われるんだ。つまり、外部サーバー側のインデックス設計がクエリの生死を分ける。

PostgreSQLのFDWは優秀で、`WHERE` 句の条件を外部サーバーに転送（プッシュダウン）してくれる。でも、複雑な結合や関数を使ったフィルタリングは転送されないことがある。そうなると、全データを一度ネットワーク経由で引き抜いてからフィルタすることになり、一気にパフォーマンスが死ぬ。

`EXPLAIN` を叩いて、ちゃんと条件が外部に伝わっているか確認する癖をつけよう。

EXPLAIN SELECT FROM logs WHERE created_at = ‘2023-05-01’;
— 実行計画に “Remote SQL” が見えれば成功。
— 全件スキャン（Seq Scan）してたり、フィルタがローカル側で動いていたら赤信号だ。

最後に、先輩からのアドバイスを2つ。

ネットワークのレイテンシを侮るな: 外部パーティションへのアクセスは、常にネットワークの壁がある。頻繁にアクセスするデータには向かない。あくまで「たまに参照されるアーカイブ用」と割り切るのが吉だ。
型の一致に神経質になれ: ローカルと外部でデータ型が微妙に違うと、インデックスのプッシュダウンが効かなくなることがある。テーブル定義のコピー＆ペーストは慎重にやろう。

外部パーティションは、正しく使えば巨大なデータを手なずける強力な武器になる。けれど、魔法の杖じゃない。ちゃんとネットワークの向こう側を想像し、インデックスが効いているかを確認する。その「泥臭い確認」を厭わないエンジニアだけが、この設計を使いこなせるんだ。

もし君のプロジェクトで「データが大きすぎて辛い」という声が上がったら、ぜひこの構成を検討してみてほしい。きっと、アーキテクトとしての引き出しが一つ増えるはずだよ。

また何か詰まったら、いつでも聞きに来てくれ。頑張れよ！