データベースとして、オープンソースとして、コミュニティとして ―石井達夫氏が語るPostgreSQLの強さと課題

クラウドコンピューティングの普及にともない、クラウドを支える技術の根幹であるデータベースにもまた、クラウドファースト／クラウドネイティブな時代のニーズにあわせた機能強化が求められるようになってから数年が経ちました。とくにスケールアウトへの要求は非常に強く、かつては「スケールしにくい技術」と常識のように言われていたリレーショナルデータベースであっても、高速なトランザクションとスケールアウトを両立させる方向へと進化しつつあります。

リレーショナルデータベースとして23年の歴史をもつPostgreSQLもまた、クラウドファースト/クラウドネイティブな"スケールするデータベース"としての道を着実に歩みつつあるようです。2018年10月には約1年ぶりのメジャーバージョンアップとなる「PostgreSQL 11」がリリースされましたが、2019年、そしてその先の未来に向けてこのデータベースはどう成長していくのでしょうか。PostgreSQLの誕生から開発に深く関わり、現在もコミッターとして世界中の開発者たちと日々議論を重ねているSRA OSS, Inc. 日本支社支社長の石井達夫氏に、PostgreSQLへの展望についてお話をうかがいました。

新しい機能を入れるといままで見えなかった課題が見えてくる

――リリースされてからすでに2ヵ月ほど経ちましたが、まずは10月にリリースされた「PostgreSQL 11.0」の特徴についてお話いただけるでしょうか。

石井：今回のバージョンアップではパーティショニングが非常に強化されました。個人的にはJITコンパイラによる高速化、そしてインデックスだけで問い合わせが完了する（テーブルアクセスを必要としない）カバリングインデックスによる問い合わせの高速化も、大きなポイントだと思っています。また、地味ですがパラレルクエリの高速化も重要なアップデートですね。

――ほかのデータベースと同様に、ここ数年のPostgreSQLもクラウドにフォーカスした機能強化が続いている印象を受けるのですが、今回のバージョンアップもやはりクラウドネイティブな方向に向かっていると見てよいでしょうか。

石井：もちろんそういう面もありますが、PostgreSQLは大容量、大量ユーザ、高速化という課題に対し、OLTPとOLAPという2つの側面からアプローチしています。そしてこれまでの経緯からいえばやはりトランザクション処理の改善が中心にあり、たとえばロックのオーバーヘッドを減らしたり、今回のパーティショニング強化などはそうした流れの延長線上にあります。一方、OLAPに関してはOLTPよりもやるべきことが多いというのが正直なところですね。先ほど触れたパラレルクエリの高速化はOLAPへの取り組みという面でも重要な機能強化だといえます。

クラウド指向な機能強化という流れでいえば、パーティショニングの大規模対応をより進めていくことが挙げられます。PostgreSQL 11ではパーティショニングの管理機能がかなり改善されましたが、まだパフォーマンス的に伸びる余地は大きいと見ています。先日、富士通の開発者の方が「パーティションの数を10くらいに増やしても性能の劣化はほとんど見られないが、100や1000など極端に増やすと途端に落ちてしまう」という話をされていましたが、現在、この課題を解決するためのパッチが出てきているところです。PostgreSQL 12、またはその先のPostgreSQL 13では、パーティショニングの大幅な改善が期待できるはずです。

――パーティショニングの強化を図ったらまた別の課題が見えてきたという感じでしょうか。

石井：PostgreSQLに限らず、これがオープンソース開発のおもしろいところだと思うのですが、新しい機能を入れるといままで見えてこなかった課題が可視化されてくるんですね。たとえば今回のアップデートの目玉であるJITコンパイラにしても、実装してみたら自律的に性能を出すというレベルまでにはいかなかったので、現状ではデフォルトでオフとなっています。しかしこうしたことは実際に入れてみなければわからないですし、試行錯誤の繰り返しがあってソフトウェアの開発は発展していくと思っています。

――PostgreSQL 12以降で、石井さんが個人的に解決したいと思っている課題はなにかありますか？: 石井：私は最近はそれほど新機能の開発に深くコミットしていないのですが、SRA OSS全体で取り組んでいる課題としてマテリアライズドビューがあります。OracleからPostgreSQLへの移行における阻害要因のひとつとされているのがマテリアライズドビューの問題で、PostgreSQLの場合、定期的にリフレッシュ（更新）するのですが、差分でのリフレッシュができません。したがって差分リフレッシュに比べて大幅に時間がかかってしまいます。マテリアライズドビューの改善に関しては以前からニーズはあったのですが、一時期トーンダウンしてしまい、あまり話題に上らなくなってしまいました。ですがポルトガルで行われた「PGConf.EU 2018」で当社の若手エンジニアがマテリアライズドビューの改善に関する発表を行い、ニーズがまだ存在することを確認できたので、長い目で見ながらじっくりと取り組んでいきたいと考えています。

“フェアでフラットな開発コミュニティ”を作るために

――PCConf.EUなど、石井さんは以前からグローバルのカンファレンスやコミュニティ活動にも積極的に参加されていますが、最近のPostgreSQLコミュニティに関してはどうご覧になっていますか。

石井：コミュニティの活動内容そのものは今も昔もそんなに変わりはないですが、新しい人や若い人をコミュニティに引きつけることはやっぱり難しくなってきていると感じます。とくに日本はただでさえIT系の人材が不足しているのに、その中でデータベースやオープンソースの開発に興味をもつ人を見つけることは非常に大変なのではないかと。ただ、PostgreSQLは非常にオープンなプロジェクトであり、そのオープン性に魅力を感じる人は少なくないと思うので、個人的にはそれほど悲観していません。技術的に良い提案であれば、若い人でも開発の中心にコミットすることができる、それは開発者として非常に魅力的なことだと思います。また、PostgreSQLの開発コミュニティ自体、いろいろな方が集まっているので、組織運営に関するノウハウも学ぶ場所としてもおもしろいのではないでしょうか。

コミュニティの運営に関しては2018年に大きな動きがひとつありまして、8月にCode of Conduct（CoC）が公開されました。個人的にはこれをPostgreSQLにとって非常に重要なマイルストーンだと捉えていて、人種や性別などによる差別を許さない、フェアでフラットな開発コミュニティを作っていこうとする姿勢は非常に評価できます。少なくとも5年前に比べるとずいぶん若い人や女性をカンファレンスで見るようになりましたから。

実はこの話は続きがありまして、私はPostgreSQLエンタープライズコンソーシアムのコミュニケーションリレーションシップの部会長を務めているのですが、そこの方々にCoCの話をしたところ「ぜひ日本語に翻訳して公開しましょう」という流れになりまして、コンソーシアムの方で翻訳にお金を出し、日本語での公開が実現しています。こうしたトレンドは世界共通かもしれませんが、国内外を問わず、PostgreSQLコミュニティ全体が良い流れに乗っているという感じはすごくありますね。現在、グローバルでもPostgreSQLのシェアが増えているのですが、コミュニティに良い空気が流れているということも影響しているのかもしれません。

“開発の主体”をもたないのがPostgreSQLコミュニティの強み

――2018年はIBMによるRed Hatの買収、HadoopベンダのClouderaとHortonworksの合併などオープンソースビジネスにおける大きな動きがあった1年でした。また、MongoDBやRedis、Elasticsearch、そして最近ではKafkaの開発を行っているConfluentなどオープンソースをビジネスのコアにしてきた企業が軒並み商用ライセンスの変更を実施しています。たとえばConfluentの場合、Apache Kafkaなどはこれまで通りオープンソースとして提供するものの、KSQLなどいくつかの重要なエコシステムのライセンスを変更し、SaaSとして提供することに制限を加えました。こうした動きはAWSなど巨大クラウドベンダがフリーライダー的にオープンソースプロダクトを使うことへの対抗策だと見ているのですが、PostgreSQLもAWSやMicrosoft Azureがマネージドサービス（RDS）として提供を行っています。オープンソースとクラウドベンダの関係について、石井さんはどう見ていらっしゃるでしょうか。

石井：これは以前から強調していることなのですが、PostgreSQLがほかのオープンソースプロジェクトと大きく異なるのは、スーパークリエイターや開発の主体となる企業がいない、完全合議制の組織という点です。いま挙げられたオープンソースのほとんどはその開発企業と深く結びついており、その企業の経営状態がコミュニティに大きな影響を及ぼします。しかしPostgreSQLは違います。もちろん当社やEnterpriseDBなどはPostgreSQLの開発にコミットしていますが、我々はコミュニティのいちメンバーでしかありません。したがって誰かひとり、または特定の1社の意向に左右されないので、「⁠タダ働きでもいいから開発に参加させてほしい」という開発者や企業が数多く存在します。

――開発の主体企業の判断ひとつでライセンスが変更されるような事態はPostgreSQLでは起こりえないということですね。

石井：そうです。もうひとつ、PostgreSQLがクラウドベンダからマネージドサービスとして提供されることについての影響ですが、ビジネス的に何の影響もないということはもちろんありません。RDSならオープンソースをメンテナンスする手間もコストも大幅に省けるので、我々の提供するサービスから乗り換えるという選択をするユーザもいます。しかし、RDSがマネージドできるサービスには限界があり、さらに技術に関していえば、クラウドベンダよりもPostgreSQLの主要開発者（とその所属企業）のほうがずっと高い。そしてこうした問題は最終的には技術力によって決まると思っています。差別化要因となるコアの技術力、さらにそれを維持/発展させていくシステムをもっているかどうかが重要なのではないでしょうか。PostgreSQLで言うならPgpool-IIなどはまさにそれに当たる存在で、もともとは私が書いたコードがベースになっていますが、その後の成長はまさにコミュニティの力によるものです。

――クラウドベンダの提供するRDSはPostgreSQLコミュニティにとって大きな脅威にはならないと。

石井：正直に言えば（AWSなどは）もう少しプロジェクトに還元してくたらいいのに…と思わないわけではありません。しかし、やはり世の中の流れはクラウドや自動化に傾いており、それを止めることはできません。オンプレミスではできないことをクラウドでやる。データベースにおいてもそういう時代になっています。最近ではよく「AIが人間の仕事を奪う」ということが言われますが、だからといってAIの普及や発展を止めることはできないでしょう。時代の流れを正しく見極め、近い将来のニーズを予測しながら開発を続けていくことが技術者の役割のような気がします。

また、RDSなどのマネージドサービスは必ずしも競合するわけではなく、個人的には当社のような企業にとってもビジネスを拡大するきっかけにもなると思っています。PostgreSQLの普及という面でもAWSなどの影響は大きいですし、クラウドのRDSを使いながら、当社のサービスも併用するというユーザも増えています。

――ほかのオープンソースプロジェクトでもPostgreSQLのようなスタイルのところが増えるといいのかもしれませんね。: 石井：私はいつもそう言っているんですが（笑⁠）⁠ ただPostgreSQLの場合、ラッキーな面があったことも事実で、最初のリリースのころは開発メンバーのほぼ全員が過去の資産を引きずっている状態でした。これらをなんとかしたいという思いから、全員で議論を重ね、改良を重ね、いまのコミュニティの原型ができ上がったわけで、最初から合議制でいくしか選択肢がなかったんですね。結局はそれが良いかたちで続くことになったのですが。

いままでの技術の延長でできることを理解し、正しいと思われる選択を繰り返していく

――「時代の流れを見極め、将来のニーズを予測する」ということでしたが、PostgreSQLは2019年以降、どう進化していくのでしょうか。

石井：バージョン12に関しては、先ほども若干触れましたが、現時点（2018年12月）ではまだ機能は確定していません。パーティショニングの改良は含まれますが、詳細は未定です。しかし方向性はある程度固まっています。

もっとも重要なアップデートとしては、EnterpriseDBが率先して開発している「zHeap」の実装が挙げられます。PostgreSQLはアーキテクチャとして追記型のストレージを採用していますが、これを捨て、ほかのデータベースのようにUNDOログをもつようにしたい。現状では不要な領域が溜まりやすく、テーブルサイズの肥大化からパフォーマンスの低下が生じてしまい、高トランザクションに追いつかず、以前から大きな問題として捉えられていました。これを解決するためにzHeapによるUNDOログを取り入れることで大きな改善が期待されます。

――zHeapはPostrgeSQL 12で取り入れられる予定なのでしょうか。

石井：いえ、おそらくPostgreSQL 12では入りません。しかしzHeapへの準備として従来のストレージと共存させる"プラガブルストレージ"が機能として入ると思います。プラガブルがおもしろいのはカラムやインメモリなど、これまでのPostgreSQLとはまったく関係のなかったアーキテクチャもサポートできる点ですね。

――準備段階の機能を入れるという点もおもしろいですね。

石井：PostgreSQLに限らず、現在のソフトウェアのアップデートにおいては、モノリシックで大きな機能を1回で入れるというアプローチは時代に合わなくなっています。また、PostgreSQLでは開発ポリシーとして「不安定な機能は入れない」ことを掲げています。開発の期限を区切って、その期限内に固まったものを入れる、そうすることで安定性を高めるようにしています。Linuxカーネルの開発と同じような感じでしょうか。

安定性を高めるという意味では、各機能のパッチが日々出ているのですが、現状の課題として、レビュアーが不足しているということが挙げられます。ソフトウェア開発ではパッチを作るだけでなく、レビューすることも非常に重要なのですが、今後はそうした体制を整えることにも取り組む必要があるかもしれません。

――データベースの進化はハードウェアの進化とも密接に関わっていますが、PostgreSQLはハードウェアにどう対応していくのでしょうか。

石井：ストレージやCPUなど、進化の速いハードウェアに完全に対応したアーキテクチャにすることはいまのデータベースにはむずかしいですし、また、がっつりとハードウェア本体に入り込んだアーキテクチャは逆に時代遅れになってしまうおそれがあります。ハードウェアの進化にも対応しつつ、データベースとしても進化しやすいアーキテクチャを両立させるなら、プラグインが妥当な落としどころだと思います。

昔はデータベースにとっての大きな課題はディスクI/Oでした。しかし現在はCPUにボトルネックが移っていて、計算量をいかに減らすかが重要になっています。JITコンパイラもそれに対応するために取り入れられました。先ほども話しましたが、時代が流れていることを意識しながら、次の時代に必要とされる技術を見極めていかないと、時代遅れな代物となってしまいかねません。ただPostgreSQLがまったく現在のハードウェアを考えていないわけではなく、マルチコアやメモリバリアなど低レイヤな部分はかなり意識して開発を進めていますよ。

――PostgreSQLはつねに現在とすこし先の未来のニーズを見ながら進化を続けてきたように思えます。

石井：現在はたしかに技術の転換点にあって、見極めがむずかしいというのは確かかもしれません。AIが普及し、自動運転車が走る時代になり、既存のデータベースでは取り扱えないデータ量は確実に増えています。現状ではリレーショナルデータベースとNoSQLを組み合わせ、1日に1テラバイト以上扱えるようになっていますが、"大容量"は間違いなくいまの時代に求められているニーズであり、これを満たせないデータベースは多くのユーザを失ってしまうでしょう。

その一方で、もう少し先のニーズを考えると、ダウンタイムなしでライブマイグレーションが本気で必要になると見ています。現状のPostgreSQLは過去のバージョンとの互換性がなく、pg_upgradeで対応していますが、今後はより取り組みを強化していく必要があります。

――技術の転換点にいるからこそ、開発者にとってその見極めがより必要になるわけですね。

石井：そうですね。ニーズの見極めとともに、いままでの技術の延長でできることとできないことをしっかり理解しながら、正しいと思われる選択を繰り返していく ―PostgreSQLはこれからもそうやって進化を続けていくと思っています。