PostgreSQL拡張: 外部データラッパー(FDW)の概要(翻訳)

こんにちは、hachi8833です。Craig Kerstiens氏のPostgreSQL記事の翻訳をお送りいたします。4年前の記事でPostgreSQLのバージョンも9.3ですが、現在および今後のPostgreSQL 10でも有用な内容だと思います。PostgreSQLへの移行に役立つツールについては、pgloader 3.41でMySQLからPostgreSQLへスマートに移行しよう(翻訳)をどうぞ。

概要

PostgreSQL拡張: 外部データラッパー(FDW)の概要(翻訳)

快進撃を続けるPostgreSQLには、特に私を惹きつけてやまない機能が2つあります。ここ数年のPostgreSQLの進歩は目覚ましいものがあり、この2つの機能によってPostgreSQLがさらに勢いづくのではないかと思っています。

その1つがPostgreSQL 拡張(extension)です。PostgreSQL拡張は今やそれだけで一分野を築いています。かのDimitri FontaineはPostgreSQL拡張だけでも多くの記事を書いていますので、私が書かずに済めばよいのにと思ったりもします。

しかし多くのPostgreSQL拡張の中でも、ぜひ別格として扱いたいものがあります。それが外部データラッパー(FDW)と呼ばれる拡張です。外部データラッパーを使うことで、PostgreSQL内で外部のデータソースに接続できるようになります。そこから外部データソースにSQLでクエリを送信することも、異なるデータセットをJOINすることもできます。

ちょうど最近、postgres_fdwを使うよい機会に恵まれました。Redis FDWについては以前にもブログに書いたことがありましたが、PostgreSQLのFDWは特に素晴らしいと思います。というのも、PostgreSQL 9.3ではpostgres_fdwがcontrib moduleとしてリリースに含まれているので、PostgreSQLのインストーラにも必ず入っているはずだからです。後はpostgres_fdwを有効にするだけで即使えます。

postgres_fdwを動かしてみる

それではpostgres_fdwを使ってみることにしましょう。このときはPostgreSQL 9.3が手元になかったので、HerokuのPostgreSQLからプロビジョニングすることにしました。

$ heroku addons:add heroku-postgresql:crane --version 9.3

PostgreSQLが使える状態になったら、後は拡張を有効にするだけです。

$ heroku pg:psql BLACK -acraig
# CREATE EXTENSION postgres_fdw;

これで準備OKです。早速動かしてみましょう。FDWで何か試すのであれば、基本的に次の4つの操作になると思います。

  1. リモートサーバーの作成
  2. リモートサーバー用のユーザーマッピングの作成
  3. 外部テーブルの作成
  4. 何かクエリを送信する

設定

以下をサーバーで1度ずつ実行するだけで、user テーブルと外部テーブルをすべて設定でき、クエリを送信できるようになります。セッションの設定専用であるdb_linkと比べるとこの点が優れています。

ひとつ残念だったのは、PostgreSQLの接続文字列の一部が使えない点です。もし使えれば、設定はもっと簡単だったでしょう。それではサーバーを設定しましょう。

# CREATE SERVER app_db 
  FOREIGN DATA WRAPPER postgres_fdw 
  OPTIONS (dbname 'db名', host 'host名');

次は、実際にuserのマッピングを作成します。この場合、リモートのユーザー名とパスワードを指定し、既に接続している現在のuserにマップします。

# CREATE USER MAPPING for user_current 
  SERVER app_db 
  OPTIONS (user 'リモートユーザー名', password 'リモートパスワード');

最後にテーブルを設定します。このときはCREATE TABLEをきれいに生成する完全な方法がなかったので、ここは少々がまんです。このテーブルはもちろんpg_dumpできますが、全体としてはややぎこちない感じでした。

# CREATE FOREIGN TABLE users
  (
    id integer,
    email text,
      created_at timestamp,
      first_name text,
      last_name text
  )
  SERVER app_db OPTIONS (table_name 'users')

これで、リモートデータもローカルデータと同じように取れました。以前だったらRubyやPythonで書かれた2つのデータベースに対してクエリを実行し、別のクエリを組み立ててから実行していたような作業を、データベースで直接実行できるようになります。これからは、新しいテーブルでSELECT * FROM users LIMIT 5;を実行するだけでおしまいです。

しかしFDWの本当の実力はPostgreSQL間のマッピングにとどまりません。あるシステムから別のシステムへ変換する定義済みのcontractがあれば、データの扱いを根底から変革できます。これは、テラバイト級のデータからETLで取り出すと途方もない時間がかかる巨大データセットについて特に当てはまります。

記事執筆時点では、productionでの使用に耐えるFDWがもっと出現してくれるのを待ち望んでいる状況ではありますが、PostgreSQL FDWは初めての方にはうってつけだと思います(Redis FDWから始める手もありますが)。ありがたいことにPostgreSQL FDWはPostgreSQLに標準でインストールされるので、今後より進んだ使いこなし方法がさらに出現することでしょう。

最後にもうひとつうれしい情報を。PostgreSQLデータベースのバージョンは9.3で統一する必要はありません。データベースの1つが9.3であれば、そこから他のデータベースに接続できます。皆さまもお試しになってはどうでしょう。

関連記事(PostgreSQL)

Ruby on RailsによるWEBシステム開発、Android/iPhoneアプリ開発、電子書籍配信のことならお任せください この記事を書いた人と働こう! Ruby on Rails の開発なら実績豊富なBPS

この記事の著者

hachi8833

Twitter: @hachi8833、GitHub: @hachi8833 コボラー、ITコンサル、ローカライズ業界、Rails開発を経てTechRachoの編集・記事作成を担当。 これまでにRuby on Rails チュートリアル第2版の半分ほど、Railsガイドの初期翻訳ではほぼすべてを翻訳。その後も折に触れてそれぞれ一部を翻訳。 かと思うと、正規表現の粋を尽くした日本語エラーチェックサービス enno.jpを運営。 実は最近Go言語が好き。 仕事に関係ないすっとこブログ「あけてくれ」は2000年頃から多少の中断をはさんで継続、現在はnote.muに移転。

hachi8833の書いた記事

週刊Railsウォッチ

インフラ

BigBinary記事より

ActiveSupport探訪シリーズ