`IMPORT FOREIGN SCHEMA` はただの「自動化ツール」か？――泥臭い現場で生き残るための外部スキーマ戦略
PostgreSQLを長年使い込んでいると、必ずと言っていいほど直面する問題がある。それは、「外部データベースとの同期」だ。
マイクロサービス化が進み、データのサイロ化が深刻化する中で、`postgres_fdw` を使って別のDBのテーブルをローカルにマッピングする手法は、今や定石中の定石だ。そんな時、皆さんはどうしているだろうか。一つずつ `CREATE FOREIGN TABLE` を手打ちしている、なんてことはないよね？
今日は、そんな反復作業からエンジニアを解放し、かつ「なぜそれが危険なのか」を理解するための `IMPORT FOREIGN SCHEMA` について、少し深掘りしてみたいと思う。
なぜ手動定義をやめるべきなのか
`IMPORT FOREIGN SCHEMA` は、外部サーバー上のスキーマ定義を一括でローカルに取り込むための強力なコマンドだ。
IMPORT FOREIGN SCHEMA public
FROM SERVER remote_server
INTO local_schema
EXCEPT (log_table, temp_data);
このコマンドの真の価値は、単に「楽ができる」ことではない。「スキーマドリフト（乖離）を最小化する」という運用上のメリットにある。
手動で `CREATE FOREIGN TABLE` を書くと、数ヶ月後、リモート側のテーブルにカラムが追加された瞬間に、ローカル側のクエリが `column not found` で爆発する。これを防ぐためにスキーマ同期を自動化・あるいはコマンド一発で再同期可能な状態にしておくことは、長期運用における「技術的負債」の利息を払うようなものだ。
内部で何が起きているのか：メタデータとの対話
このコマンドを実行した際、PostgreSQLの内部では何が起きているのか。
これは単なるDDLの実行ではない。`postgres_fdw` はリモート側の `information_schema` を検索し、型マッピングを動的に解決している。ここで注意すべきは、「型変換のオーバーヘッド」だ。
例えば、リモートがPostgreSQLで、ローカルもPostgreSQLであれば問題は少ない。だが、接続先がMySQLやOracleだった場合、型変換のルールは `postgres_fdw` の実装に依存する。自動インポートした結果、意図しない型（例えば `NUMERIC` が `TEXT` として解釈されるなど）に変換されてしまい、インデックスが効かなくなるという悲劇を何度見てきたことか。
「自動化」は甘美な言葉だが、インポートされた直後の `\d` で、型が期待通りかを確認する泥臭いステップを省略してはいけない。
パフォーマンストラブルの「隠れた巣窟」
`IMPORT FOREIGN SCHEMA` で取り込んだテーブルに対してクエリを投げた際、パフォーマンスが劇的に悪化することがある。これは多くの場合、以下の二つが原因だ。
1. 統計情報の欠如
`IMPORT FOREIGN SCHEMA` でテーブルを作った直後、そのテーブルは「空っぽの統計情報」しか持っていない。オプティマイザは行数を「0」あるいはデフォルトの「1000行」と想定して実行計画を立てる。これが複雑なJOINに絡むと、ネステッドループ地獄の始まりだ。インポート直後には必ず `ANALYZE` を忘れずに。
2. WHERE句のプッシュダウン失敗
外部テーブルのインデックス設計で最も重要なのは、フィルタ条件が「リモート側にどこまで押し込めるか（Pushdown）」だ。自動生成されたテーブル定義が、リモート側のインデックスと整合しているかを確認してほしい。定義が微妙に食い違っていると、PostgreSQLはリモートから全件データを引いてきて、ローカルでフィルタリングする。ネットワーク帯域をドブに捨てるような挙動だ。
プロとしての「落とし所」
私が推奨するのは、`IMPORT FOREIGN SCHEMA` を 「設計の初期段階のブートストラップ」 として使うことだ。
最初の一回はコマンドで構造を取り込む。しかし、本番環境で運用する際は、自動インポートを野放しにするのではなく、取り込まれたDDLを一度自分のコードベースにコミットし、型やオプションを精査した上で管理する。もしスキーマ変更があれば、再度インポートして差分を確認する。
「自動化＝運用放置」ではない。自動化によって「何を把握すべきか」というコストを下げ、本当に注意を払うべき「型変換の歪み」や「統計情報の精度」に時間を割く。それが、熟練したエンジニアの振る舞いというものだろう。
PostgreSQLは、隠蔽された裏側を知れば知るほど、こちらの意図を汲み取ってくれる素晴らしい相棒だ。皆さんのDBモデリングが、今日も健全であることを願っているよ。
コメント