まとめ読み！ PostgreSQL最近のアップデート：もう一度始めたい人のPostgreSQL（1）

　最近、データベース界隈ではNoSQLが徐々に注目を集めていますが、現状では依然としてRDBがシステムの中核を握っているといえるでしょう。

　「PostgreSQL」は代表的なオープンソースRDBMSの1つです。強大な影響力を持つ単一企業ではなく、有志の開発者とユーザーが集まるオープンなコミュニティによって活発に開発が続けられています。

　1年に1回、機能追加を伴うメジャーバージョンアップを行うという安定したペースで10年以上開発が続けられているほか、年に数回、バグ修正を中心としたマイナーバージョンアップも行われています。商用DBと比較しても機能・性能面で遜色なくなってきており、商用DBからの移行先としてPostgreSQLの人気は高くなっています。

PostgreSQLのオフィシャルサイト

　本連載ではPostgreSQLについて、近年追加された主要な機能を紹介していきます。連載第1回目では、諸機能の紹介に先立って、PostgreSQL 9.0から執筆時点の最新バージョンである9.2までに追加された主な機能を眺めてみることにします。

レプリケーションに対応したPostgreSQL 9.0

　PostgreSQL 9.0では、それまでの8.x系と比べて多くの新機能が登場しました。

　最も特徴的な点は、PostgreSQLが単体でレプリケーション機能に対応したという点でしょう。8.x系以前のPostgreSQLでは、レプリケーション機能を用いた負荷分散や障害対応を目的としたマスタースレーブ構成を構築するには、pgpool-IIやSlony-Iなどのミドルウェアに頼るしかありませんでした。

　9.0で追加されたPostgreSQL組み込みのレプリケーション機能は、ホットスタンバイとストリーミングレプリケーションという2つの機能によって実現されています。ホットスタンバイとは、待機系サーバに対し、参照問い合わせを可能とする機能です。また、ストリーミングレプリケーションとは、稼働系サーバの変更情報を待機系サーバに転送する機能です。

　そのほかにも、PostgreSQLのメジャーアップグレード作業を簡略化するpg_upgradeコマンドが提供されました。

　PostgreSQLでは、メジャーバージョンアップが行われるとデータベースの内部構造が変更されるため、前バージョンで作成したデータベースとの互換性が失われてしまいます。そのため、これまでメジャーアップグレードを行う場合は、pg_dumpallコマンドによる論理バックアップとpg_restoreコマンドによるリストア作業が必須でしたが、バックアップとリストアは、データベースサイズの増加にともない時間もかかる、コストの高い作業です。

　9.0以降では、pg_dumpall／pg_restoreコマンドの代わりにpg_upgradeコマンドで簡単に短時間でメジャーアップグレードができるようになりました。なお、pg_upgrade は8.2以前のPostgreSQLからのメジャーアップグレードには対応していない点に注意が必要です。

　また、64ビット版Windowsに対応したのも、バージョン9.0からです。これまでのPostgreSQLは、64ビット版Windowsでは32ビットモードで動作していましたが、9.0からは64ビットモードで動作できるようになり、Windowsでも大きなサイズの共有メモリを扱えるようになりました。

レプリケーション面の機能強化を図ったPostgreSQL 9.1

　PostgreSQL 9.1では、主にレプリケーション面の機能が強化されました。

　具体的にはまず、ストリーミングレプリケーションが同期モードに対応した点が挙げられます。

　実は、9.0で追加されたストリーミングレプリケーションは、非同期モードにしか対応していませんでした。非同期モードのストリーミングレプリケーションでは、稼働系サーバは待機系サーバの反映状況を考慮することなくトランザクションを完了してしまいます。従って、稼働系サーバが故障すると待機系サーバの変更反映が間に合わず、データを損失する可能性がありました。

　しかし、9.1で追加された同期モードであれば、稼働系サーバは待機系サーバに変更情報が反映されたことを確認してからトランザクションを完了するので、稼働系サーバのデータは待機系サーバに確実に複製されていることが保証されます。ただし同期モードでは、待機系サーバが故障した場合、稼働系サーバは待機系サーバの応答を待ち続け、トランザクションが完了しなくなる点に注意が必要です。

　レプリケーションの運用を手助けする機能も追加されています。その例の1つが、ベースバックアップの取得を簡略化するpg_basebackupコマンドです。9.0以前では、ベースバックアップを取得する場合は、

1. データベースに接続してpg_start_backup()を実行
2. データベースクラスタの物理コピーを取得
3. データベースに接続してpg_stop_backup()を実行

という、やや面倒な手順を踏まなければいけませんでした。9.1以降であれば、pg_basebackupコマンドを実行するだけでベースバックアップの取得は完了します。

　なお、pg_basebackupコマンドはレプリケーション機能を利用して実現しているので、実行するデータベースユーザーの権限とアクセス権限に注意が必要です。また、PostgreSQLの設定パラメータで、待機系サーバの数を指定するmax_wal_sendersに、pg_basebackupコマンド用のセッションを1つ以上追加しておく必要もあります。

　そのほかにも、待機系サーバを簡単に昇格するpg_ctl promoteコマンドや、レプリケーションの状態を確認できるpg_stat_replicationビュー、待機系サーバの採集更新日時を取得するpg_last_xact_replay_timestamp()などが追加されています。

性能改善を図ったPostgreSQL 9.2

　PostgreSQL 9.2では、性能改善と実用度の高い機能が追加されました。

　性能改善面では、何といってもIndex only scanの登場でしょう。PostgreSQLは受け取ったクエリを実行する際に、いくつかの方略に基づいてデータを検索しようとします。9.1以前では代表的な方略として「index scan」がありました。これは、テーブルのカラムに貼られたインデックスを利用して、インデックスとテーブルに交互にアクセスして必要なデータを読み取っていく方式です。

　これに対しIndex only scanではテーブルデータにアクセスすることなく、インデックスだけにアクセスして検索結果を返します。これにより、参照系の処理速度が劇的に向上しました。

　そのほか、レプリケーション機能がカスケードレプリケーションに対応しました。9.1以前のレプリケーション機能では、待機系サーバの変更情報の取得元は必ず稼働サーバである必要がありましたが、9.2では待機系サーバから更新情報を受け取る新たな待機系サーバを作成可能となりました。また、サーバの処理が少ない時間帯はCPU電力消費を抑えるように内部実装が改善されています。

　機能追加の面では、新たなデータ型として、日付時刻や値の範囲を格納できるRANGE型、JSONデータとしての書式チェックや配列データとの相互互換が可能なJSON型が追加されています。特にJSON型は、手続き言語のPL/V8やPL/Coffeeを用いることで、「NoSQL」のような利用方法も実現可能となります。また、ALTER文などのいくつかのDDL命令文が改善されており、データベースサーバ稼働中の変更を行いやすくなっています。

来るPostgreSQL 9.3は？

　PostgreSQLのこれまでのリリース日は、9.0が2010年9月20日、9.1が2011年9月20日、9.2が2012年9月10日となっており、おおよそ1年ペースでメジャーバージョンアップが行われています。このままのペースを維持すると想定すれば、PostgreSQL 9.3のリリースは2013年の初秋であると言えそうです。

　次バージョンではどのような機能が追加されるのでしょうか。

　　2013年5月13日、本家サイトではPostgreSQL 9.3 beta1が公開されました。beta1では、外部のPostgreSQLサーバのデータを簡単に参照可能とするcontribモジュールのpostgres_fdw、pg_dumpを高速に行えるパラレルpg_dump、更新可能ビューやマテリアライズドビューなどの機能が盛り込まれています。

　以上、PostgreSQL 9.xの主な機能の概観をお送りしました。第2回以降では、最新版のPostgreSQLをLinuxマシンにインストールして、新機能の具体的な動作について操作方法も含め、紹介していく予定です。