2014 年 9 月 11 日に、 東京中央区にて SRA OSS, Inc. 日本支社主催「PostgreSQL 9.4 最新情報 〜 新しいJSONデータ型開発者の Oleg Bartunov 氏を迎えて 〜」セミナーが開催されました。

本セミナーでは、ロシアから来日した PostgreSQL 開発の中心メンバーである Oleg Bartunov（オレグ・バルトノフ）氏より、現在開発中の 9.4 の最新動向をお話いただきました。とくに氏は、PostgreSQL 9.4 のなかでも JSONB 型の改良に関わっているところから「スキーマレス PostgreSQL」というテーマでの講演となりました。

またセミナー後半では、SRA OSS が実際に NoSQL との性能比較を交えて行った PostgreSQL 9.4 の JSON 型について検証結果をご紹介しました。

盛況となりましたセミナーの模様について、後半の PostgreSQL 9.4 検証結果報告をご紹介します。

高塚：

はじめまして。SRA OSS, Inc. 日本支社の高塚と申します。 現在は弊社 PostgreSQL 技術グループにてクラスタ構築支援、マイグレーション技術支援をはじめとした各種サポート業務を行っています。

本日は、PostgreSQL 9.4 の検証結果をご報告させていただきます。新しいバージョンでは、JSONB や GIN インデックスがメインとなりますが、時間の許す限り、それ以外の機能もご紹介できればと思っております。前半は性能アップしましたというポイントから、後半は新しく追加された機能についてご紹介します。

では早速、PostgreSQL 9.4 の性能検証についてお話させていだたきます。
バルトノフさんからもたくさんお話がございました GIN インデックスをテストしました。基礎的な性能改善度合いを確認するために、同じマシンで、PostgreSQL 9.3 と 9.4 を比較しました。使ったデータは 50 万件で、次の局面で優劣を比較しました。

• インデックスの物理サイズ
• 既にデータがある状態からのインデックス作成性能
• インデックスが作成されている状態からのデータ挿入性能
• インデックスを使った検索性能

図表をご覧いただくとひと目でわかるのですが、それぞれ、性能アップが数値に現れています。

私はこのテストを作るにあたっては、早くなった理由を知らずに行っているのですが、すべての局面において性能アップが証明されているところが、素晴らしいと感じました。

次に WAL （ログ先行書き込み）の性能改善について検証しました。9.4 では、データ圧縮により WAL の出力量が低減したということが言われています。
pgbench という負荷ツールで、更新トランザクションを 5 万回実行したところ、pgbench 標準シナリオで流すと WAL サイズが 6％ 少なくなっています。さらにカスタムシナリオも実行し、アップデートだけのより単純な更新内容にしたところ、15％ 低減しました。

もうひとつ WAL の性能改善としまして、同時実行性が向上したと言われています。2012 年に PostgreSQL が 9.1 から 9.2 にバージョンアップした時も、同時実効性の改善があり、効率が上がったという話がありました。今回もその時と同じように、同時実行の競合を減らすような修正が入っております。その結果はどうかというと、5％ 程度の向上がありました。とくに同時実行を増やしていくと性能が上がっていく、ことがわかりました。

ここからは、JSON と JSONB の比較になります。結論としましては、さきほどバルトノフさんからお話のあった結果とほとんど同じです。
10万件のログ情報を投入しますと、インサート時間は JSON より JSONB の方が若干遅いですが、投入するときに、JSONB は変換処理をしなければいけませんので、これはしかたないと考えています。
また、インデックス付きのインサート時間は一つの GIN インデックスが、Btree の関数インデックス ４ 箇所分と同じくらいです。4 か所以上インデックス検索したい JSON 上の項目があるなら、GIN インデックスの方が得です。

次に、JSON 型と JSONB 型を GIN インデックスを利用しないフィールド検索で比較しました。
JSONB の検索は、JSON の所要時間に比べてほぼ半分になっています。これはバイナリで格納されているという効果です。つまり、GIN インデックスを使わなくても JSONB の検索では速いということがおわかりいただけたかと思います。

最後に、他のドキュメント型データベース Couchbase Server と比較しました。
Couchbase Server は、速さを追求していまして、Web サイトでも他製品より速いことをアピールしています。
まずインサートです。10 万件データを挿入しますと、これはやはり Couchbase Server が速いです。しかしアンログ(Unlogged)にすると、そんなに差はありません。

続いて、並列ランダム更新、条件読み出しというタスクで比較しますと、並列ランダム更新では、PostgreSQL はおよそ 2 倍の時間がかかっています。条件読み出しでは GIN インデックスが使えるので、PostgreSQL の方が速い結果となっています。
とはいえ、もともと違う形態のソフトウェアですので、比較の仕方によって結果も変わってきます。本結果の値は参考程度と考えてください。

それでは、PostgreSQL 9.4 から追加された機能の話に移りたいと思います。
まずレプリケーションスロットという機能を紹介します。なかなか説明が難しいですが、一言で言うと、「プライマリーとスタンバイをつなぐ絆」というような機能です。
これまでは、特定スタンバイに対してレプリケーション状態、付帯データというものを保持管理する場所がなかったのですが、その枠組みが出来たということです。それがスロットと呼ばれるものになります。

PostgreSQL 9.4 では、フィジカルレプリケーションスロットとロジカルレプリケーションが用意されています。

そのほかの新機能としては、更新ビューのチェックオプションが入りました。更新ビューは、一つ前のバージョン 9.3 から、ビューを定義したときにそのビューをアップデートしたりインサートしたりできるようになりました。この動作をより厳密にすることができるようになりました。

続きまして、ALTER SYSTEM という新しいコマンドが追加されました。SQL コマンドで PostgreSQL の設定を変更することができます。
また、テーブルスペースの変更をまとめて行うコマンドが追加されました。

最後に、REFRESH MATERIALIZED VIEW コマンドに Concurrently オプションというものが登場しました。もともとの Materialized ビューは、普通のビューと違ってテーブルに対してビューを定義したら、問い合わせた結果を覚えておいてくれるものでした。
次に問い合わせたときには、もとのテーブルにはアクセスせずに、覚えていた結果を出してくれます。この覚えていた結果を、元のテーブルをもう一回セットしなおして更新するときには、REFRESH MATERIALIZED VIEW コマンドを実行します。

ただしバージョン 9.3 までの REFRESH MATERIALIZED VIEW は、かなりロックレベルが強かったのです。REFRESH MATERIALIZED VIEW を実行中は、Materialized ビューに対するセレクトがブロックされてしまうわけです。ですので、今回の 9.4 では Concurrently オプションをつけることで、セレクトがブロックされることはなくなったというわけです。