PostgreSQLエンタープライズ・コンソーシアムが発足から1年の活動成果を発表するセミナーを開催した。2つのワーキンググループが実施した、「大規模DBを見据えたPostgreSQLの性能」と「異種DBMSからPostgreSQLへの移行」の検証結果について報告した。

 企業情報システムへのPostgreSQLの普及を推進する団体「PostgreSQLエンタープライズ・コンソーシアム」(PGECons)は2013年4月22日、発足から1年の活動成果を発表するセミナーを開催した。PGEConsには共同発起人であるSRA OSS 日本支社、NEC、NTT、日立製作所、日本ヒューレット・パッカード、富士通をはじめとする、約40のITベンダーが参加している。セミナーでは、こうしたベンダーのエンジニアが共同で実施した、2つのワーキンググループによる検証、具体的には「大規模DBを見据えたPostgreSQLの性能」と「異種DBMSからPostgreSQLへの移行」の成果について報告した。成果に関する詳しいドキュメントをPGEConsのWebサイトからダウンロードできる。

80コアのサーバーで拡張性を確認

 まず、スケールアップとスケールアウトの検証結果を説明した。

 スケールアップでは、PostgreSQLに付属するベンチマークツール(pgbench)を用いて計測した、80コアのサーバーにおける参照性能を紹介した(図1)。クライアント数を増やしていくと、コア数と同じ80まで参照性能が向上した。特に64クライアントまでは、ほぼ線形に性能が高まっており、拡張性に優れていることが分かる。またJDBC接続のデータベース負荷ツール(JdbcRunner)を利用したオンライントランザクション系の検証結果についても説明があった。データサイズが大きくなると、予想通り単位時間当たりの処理量(tps)が減少したという。

図1 80コアサーバーにおけるPostgreSQLの参照性能
図1 80コアサーバーにおけるPostgreSQLの参照性能
pgbenchでカスタムスクリプトを利用した。ハイパースレッドはオフにした。
[画像のクリックで拡大表示]

 スケールアウトの検証では、非同期の3階層カスケードレプリケーションにおいて、ノード数が増えてもマスターDBの更新性能が劣化しなかった。また、同期レプリケーションなどの機能を持つミドルウエア(プロキシーとして動作)のpgpool-IIと組み合わせると、参照処理ではノード数に応じて性能が向上する半面、更新処理についてはノード数が増えると性能が劣化した。

ツールで変更箇所を抽出して移行

 PostgreSQLへの移行では、主にOracleからの移行に焦点を当てて検証した。例えば、異種DBMS間の連携やスキーマ移行、SQL文移行、ストアドプロシージャー移行、組み込み関数、データ、アプリケーションについて調査を実施した。特に、データおよびアプリケーションの移行については、サンプルを使って実際に移行する検証も行った。

 スキーマやSQL文の移行では、両DBMSの互換性を調査し、互換性がない場合にどのように書き換えればよいかの方針を示した。また、ストアドプロシージャーについては、アーキテクチャーにかかわる部分にまで踏み込んで、移行方針をドキュメント化した。例えば、OracleのPL/SQLではトランザクションを記述できるものの、PostgreSQLのPL/pgSQLでは記述できないので、場合によってはアプリケーションとして書き変えた方がよいパターンもあるとした。

 移行検証は、データ移行はJdbcRunnerに同こんの「TinyTPC-C」で作成したデータ、アプリケーション移行はJavaで実装されたオープンソースの「Commander4J」(バーコードラベル作成ツール)をサンプルに用いて実施した。アプリケーション移行では、SQL文に変更が必要になる箇所の抽出にツール(db_syntax_diff)を利用したことから、コードの変更自体は大きな手間が掛からなかった。結果的に、工数の約90%をテスト工程(修正作業を含む)が占めた。ツールで変更箇所がすべて抽出されるわけではなく、テスト工程で各種問題が見つかったからだという。