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 型について検証結果をご紹介しました。

盛況となりましたセミナーの模様について、前半部分のオレグ・バルトノフ氏の講演内容を中心にご紹介します。

■ SRA OSS, Inc. 日本支社 取締役支社長 石井 達夫 挨拶

石井：

SRA OSS, Inc. 石井でございます。
本日は、さまざまな改良が現在進行形で進んでいる PostgreSQL 9.4 の最新情報を、開発の中心メンバーであるオレグ・バルトノフさんから直接お話を伺えるという、またとない機会になりました。私もとても楽しみにしております。

このところ、PostgreSQL は再度の脚光を浴びていまして、国内外でさまざまな動きが出ているところです。
もともと PostgreSQL が強いと言われている日本では普及率も高いのですが、とくに最近の国内の動きとしましては、エンタープライズ領域での利用が増えています。
そして、もうひとつ注目すべき点は、海外での勢いです。
たとえば 2014 年 4 月には、イギリス気象庁で使われていたシステムが Oracle から PostgreSQL へ移行することが決まり、現在、鋭意、開発が進められていると聞いています。イギリス気象庁が、Oracle ではなく、PostgreSQL のほうが、業務をまかせるに足る最適なデータベースである、と選択したわけです。

このような背景を踏まえ、現在 PostgreSQL 9.4、β２の開発が進んでいます。今日の講演でも取り上げられる、GIN インデックスの高速化、インデックスサイズの圧縮、それからもちろん JSONB、そして WAL の圧縮など、次々と目を見張るような開発が行われている最中です。

このようなタイミングで、バルトノフさんをロシアからお招きできたことは、非常にうれしい限りです。
今日一日、長い時間になりますが、ぜひお付き合いください。改めましてご来場ありがとうございます。

■ モスクワ大学シュテルンベルク天文研究所所属/PostgreSQL 開発者 Oleg Bartunov（オレグ・バルトノフ）氏の基調講演

バルトノフ：

皆さま、こんにちは。オレグ・バルトノフと申します。現在私は、モスクワ国立大学のシュテルンベルク天文研究所に勤めており、PostgreSQL の開発を行っています。日本に来たのは初めてで、こうして呼んで頂いたことをとても嬉しく思っております。

PostgreSQL 9.4 の β 版は現在、鋭意、開発中です。今日は「スキーマレス PostgreSQL」と題しまして、PostgreSQL の現状と将来に向けてお話をさせていただきたいと思います。

今回リリースされる PostgreSQL 9.4 は、一言でいえば、NoSQL のいいところすべてを搭載している、と言えます。
具体的には、PostgreSQL 9.4 の目玉と呼ばれている JSONB を中心に、以下のアジェンダで話をすすめてまいります。

• 現在抱えている問題点
• HStore
• JSONB 導入
• JSONB クエリ言語
• JS クエリサポートと JSONB
• VODKA アクセスメソッド

現在進行形の課題としていちばん注目しているのは、データ、あるいはアプリケーション/ Web アプリケーションを取り巻く環境です。「ビッグデータ」という言い方でひとくくりにまとめられていますが、これは量であり、速度であり、種類でもあります。
こうした状況で必要とされているのが、いかに負荷を軽くするか、という点です。また、アプリケーション自体のリリースも、非常にスピードを求められるようになってきています。
ビッグデータ時代に対応する新しいデータベースとしては NoSQL が注目されています。NoSQL、つまり「Not only SQL」は、RDB（リレーショナルデータベース）以外のデータベースの利用・発展を促進させるという意味合いで、大量のデータを扱う場合の旗印のように言われています。NoSQL は、固定されたスキーマにしばられることなく水平スケーラビリティが確保しやすく、同時実行性も高く、なおかつ堅牢であり、といったような特徴があり、どのようなデータでも懐広く受け入れられる仕様になっています。

もともと「NoSQL」はキーバリューデータベースというシンプルなものからスタートしましたが、そこにキーバリューストアや、あるいはレンジサポートというものが加わりました。そしてカラムファミリーであるとか、ドキュメントデータベース、グラフデータベースというものが追加されることによって、非常に複雑な SQL が出来上がりました。こちらをご覧頂くと、「NoSQL」がいかに短期間で進歩してきたかがおわかりいただけるかと思います。

私たちは PostgreSQL 9.2 で、JSON（JavaScript Object Notation）を導入しました。今回私たちは、JSON のフォーマットをより進化させ、PostgreSQL 9.4 に JSONB を導入したわけですが、ここにいたるまでは長い道のりであり、大きな挑戦でもありました。

その説明に入る前に、改めて RDB の問題点を考えてみましょう。
まず、皆さんがお使いになるアプリケーションには、ACID トランザクションが必要です。ACID トランザクションに加えて、NoSQL の柔軟性を求められた場合、どのように対応すればよいのでしょうか？また、たとえばテーブルを変更する、配列を変えるなどのオンライン上での変更が求められる場合、どう解決したらいいでしょうか？
アプリケーションの側は、こういったスキーマの変更を待たなければならないため、その分リリースが遅れるわけです。迅速なスピードが求められるビックデータ時代、リリースが遅れは致命的な問題につながる可能性があるわけです。

このような課題を見つめることで PostgreSQL で JSON フォーマットを使うという発想が生まれたわけですが、その前段階として HStore というモジュールがありました。

PostgreSQL は、実は、すでに 2003 年から実質的にスキーマレスになっています。HStore というモジュールが、PostgreSQL をスキーマレスにしたからです。
HStore はキーバリューのペアを格納しやすい形になっており、非常に迅速な検索を可能にします。また、インデックスサポートも兼ね備えています。 システムに変更が生じた場合も、スキーマを変更する必要はなく、HStore の中だけを変えればいいということになるわけです。HStore によってアプリケーションも非常に迅速にリリースできますし、スキーマのアップグレードにも対応できます。

HStore の誕生は、開発途中での問題が新しい気付きとなり開発に繋がっています。その歴史を振り返ると、2003 年に初めてのバージョンが誕生した HStore は、2006 年の 12 月に PostgreSQL 8.2 の一部として導入され、さらに 2007 年の PostgreSQL 8.3 では GIN インデックス for HStoreが導入されました。

GIN インデックスは、PostgreSQL 9.4 で大きく改善された機能のひとつです。GIN インデックスの「GIN」とは、「Generalized Inverted Index（汎用転置インデックス）」の略で、文字通り幅広い用途で非常にパワフルに検索できるインデックスです。テキスト全文検索からオブジェクト検索まで、ひとつの値の中に複数の要素を持つようなデータ型に活用できます。

GIN インデックスの今回の改善点はふたつあります。インデックスサイズの圧縮と検索性能の向上です。
まず、インデックスサイズの圧縮ですが、たとえば PostgreSQL 9.3 で 90 バイトのポスティング・リスト（GIN インデックスの構造の一部）があったとすると、9.4 では 21 バイトにまで圧縮されるようになりました。およそ 4 倍強の圧縮がかかっていることになります。
また、検索性能も改善されました。たとえば、PostgreSQL のなかで「ブラウン」と「PostgreSQL」、この二つの言葉をサーチしてみましょう。PostgreSQL 9.3 ではあくまでも「PostgreSQL」という言葉を先に検索します。よく出てくる言語の方に時間が比例する仕組みで、結果が表示されるまでに非常に時間がかかりました。対して 9.4 では、「ブラウン」というめったに出てこない言語を先にサーチしていきますので、非常に時間を短縮できるようになったのです。

ここまでお話したように、HStore は非常にシンプルなバイナリで、すばらしいエクステンションなのです。ただし問題点は、シンプルすぎるということでした。ネスティング（Nested）、あるいはツリー構造との関係のなかで HStore をどう扱うべきか、いろいろと模索がありました。
2012 年頃には、ここまで HStore が優れているのだから、いっそのこと「Nested HStore」を作ろう、というプロジェクトが立ち上がりました。しかし、紆余曲折の末、2014 年の 3 月に Nested HStore から、JSONB と呼ばれる新しいデータ型へ移行することを決めました。開発を進めるなかで、HStore の互換性に問題があることがわかってきたからです。

JSONB は、PostgreSQL 9.2 から導入している JSON (JavaScript Object Notation)という XML などと同様のテキストベースのフォーマットに、バイナリデータとしてデータを格納したものです。JSONB の「B」は「バイナリ（binary）」の「B」です。

JSON は構造化されたデータを簡潔に記述できるため、人間が理解しやすいデータフォーマットとして、いまやさまざまな環境やツールで使われています。PostgreSQL の JSON 型は、基本的には文字列データ型で、値を格納するときに JSON としての構文チェックが行われ、JSON 処理関数や演算子も用意されています。

ただ、HStore と JSON を比較すると、やはり JSON は遅いわけです。両者の特性を活かすとしたら、新しい HStore でドキュメントベースモデルをサポートしていく必要がある、と考えました。また JSON に対しては、バイナリの表現ができないか、ということを考えました。
それなら「バイナリの JSON」という発想に切り替えようじゃないか。ということで生まれたのが、JSONB だったのです。そしてこの JSONB が、PostgreSQL 9.4 の目玉と言えます。

MongoDB と比較をしてみました。データのローディングでは、MongoDB の方が非常に遅いという結果です。JSONB 43 秒、そして MongoDB 13 分という結果になります。
シーケンシャルスキャンによる検索は、ほぼ同じ。そしてインデックススキャンについては、JSONB がかなり速いという結果です。

こちらが最終的に PostgreSQL と MongoDB を比較したものになりますが、JSONB の速さが際立っています。
テーブルサイズは、やはり MongoDB の方が大きいことがわかります。PostgreSQL の方が 1.3 Gb、MongoDB の方が 1.8 Gb となります。
入力の性能は、MongoDB の方がより良いです。インデックスのサイズについては MongoDB が非常に大きいという結果です。

こちらが、NoSQL がいかに進化してきたか、というスライドになります。
PostgreSQL が登場したころ、２つが最終的に出会う場所というゴールが、今、まさにやってきたわけです。PostgreSQL であり、オープンソースであり、そして RDB という形での提供、そして現代、今ということです。
やっと JSON の非常に強力なサポートというものが実現しました。古いところから新しいもの、古いところからも、またかつ新しいものからも学んでいくというのが、この PostgreSQL のあり方であり、非常に柔軟性に富んだコミュニティからの開発が行われています。
従って、現在 JSON が使える、サポートが得られているということであれば、MongoDB を使う意味は見いだせないような気がします。

今回リリースされる PostgreSQL 9.4 の特徴を一言でいうならば、「NoSQL のいいところすべてを搭載している」と言えるでしょう。すなわち、オープンソースであり、OS を選ばず、JSON サポートのあるデータベースの提供ということです。

他のデータベース管理システムと比較をしてみますと、Microsoft SQL Server と Oracle は、まだ JSON のサポートがありません。MySQL は、JSON の機能をある程度サポートしていますが、インデックスサポートがありません。

最後に、PostgreSQL の将来について、お話しましょう。

現状、 BTree については試行錯誤しているところでして、たとえば全文検索に対応できるようなものに変えていくことを考えています。そのようななかで、新しいインデックスへのアクセス方法として、VODKA というものを作っています。
現在、PGCon でこの結果を少しずつ発表させていただいています。将来的には、PostgreSQL 9.5、あるいは 9.6、あたりに向けて開発をすすめています。
ということで、VODKA は、決して飲み物ではないということがおわかりいただけたかと思います(笑)。もちろん GIN も飲み物ではありません(笑)。ちなみに、このネーミングは、そもそもアラビアンナイトに出てくる魔法使いのジーニーからとっています。

いずれにしても、私たちの開発は、決して止まることはありません。常に変化を起こしていくことが好きですし、これからもよりよいインデックスを探していく、あるいはそのインデックスに対してのアクセスの方法というものを、皆様に提供したいと考えています。

現在、私たちのプロジェクトは非常に多くのタスクが待ち構えています。皆さんのなかで、ぜひチームに入って一緒に開発をやりたいという方がいらっしゃいましたら、大歓迎でお迎えします。

本日は、ありがとうございました。

質問者：

PostgreSQL では Hint 句は使わないという方針だったと思いますが？

バルトノフ：

ご指摘のとおり、私たちのなかでも反対意見というものはでています。将来的に何か素晴らしいプロジェクトがあって、JSONB に対する統計がとれて分析結果が出てきたときに、Hint 句自体は必要なくなってくるという風に我々も考えています。
ただし、現段階で JSONB をお使いになりたいという場合、複雑なものに対応するには Hint 句というエクステンションが必要になってくるという場合もあると考えています。Hint 句はあくまでも拡張機能ですので、使いたい方が使っていただければというスタンスになっています。

質問者：

JSONB と JSONB のインデックスは、トランザクションに対応していますか？

バルトノフ：

はい。PostgreSQL は RDB ですし、JSONB の方はスタンダードのデータタイプということになりますので、もちろんトランザクションに対応しています。安心してお使いいただけます。