PostgreSQLの主要な開発者のひとりに Robert Haas 氏がいます。Robert Haas 氏は EnterpriseDB社で働いていますが、今、PostgreSQL開発コミュニティの中で、もっともアグレッシブに開発している一人であり、開発コミュニティの中でも非常に大きな影響力と信頼を勝ち得ている一人であると言えるでしょう。
また、Robert Haas 氏は、2012年には日本のPostgreSQLカンファレンスで基調講演を行ったこともあります。
- 待望のPostgreSQL 9.2は大幅性能アップするのか？（1/2） － ＠IT
http://www.atmarkit.co.jp/fdb/rensai/dbwatch2012/dbwatch201203_01.html
- Robert Haas: PostgreSQL Past, Present, and Future: Moving The Goalposts
http://rhaas.blogspot.jp/2016/01/postgresql-past-present-and-future.html
PostgreSQLの主要な開発者が今何を考えているのだろうか。PostgreSQLの今後をどう考えているのだろうか。開発者の頭の中をちょっと覗いてみよう、といった趣で、PostgreSQLの今後を考える参考にしていただければと思います。
文中のリンクは原文のままになっています。
それではどうぞ。
■PostgreSQLの過去、現在、未来: ゴールポストを動かし続けて（Robert Haas）
Tuesday, January 12, 2016 ついに、PostgreSQL 9.5がリリースされるのを現実に目にすることができました！ 既に多くのブログ記事がありますし、言うまでもなく、InfoWorld、V3など、その 他 の メディアにも記事があります。多くの記事が出ていますが、私が気に入っているのは、Shaun Thomas による PostgreSQL が過去5年間でどれだけ遠くまで来たのかを振り返った記事です。Shaun が書いたように、PostgreSQL のスケーラビリティと機能の拡充は、過去の5年間で目を見張るような向上を見せてきました。一つのリリースを見るだけでは気付かないこと、あるいは（私がしているように）個々のコミットを見ていたとしても気付かないかもしれませんが、私たちが今いる場所は、5年前当時のそれと比べてまったく新しい世界となっています。
2010年に、私は Big Ideas というエントリと、それに続いて、私の最初のアイディアと、それに対する他の人から聞いた反応をまとめた Lots and Lots of PostgreSQL Feature Requests という記事を書きました。その5年後、そのリストにあった多くの項目は既に実現されました。PostgreSQL 9.5は、MERGEを待ち望んでいた多くの人たちのユースケースに答える INSERT .. ON CONFLICT を実現し、行レベルセキュリティも実現しました。インデックスオンリースキャン、より小さい粒度の collation サポート、SE-Linux統合、LATERAL、更新可能ビュー、およびマテリアライズドビューといった機能は、すでに多くのPostgreSQLユーザが「新機能」と感じないくらいになりました。これまでのリリースでは、同様に新しいデータタイプ、具体的にはJSONBが追加され、JSONデータを容易に扱えるようになり、それはPostgreSQL 9.5で SP-GISTのような新しいインデックスタイプとともにさらに拡張されました。PostgreSQL 9.5では、BRINインデックスが追加され、増大し続けるPostgreSQLの大規模ワークロードを実現する一部となっています。
そのリストにあって本当に重要な機能でまだリリースされていないものも、現在進行中となっています。例えば、PostgreSQLコアに含まれるマルチマスタレプリケーションはまだですが、PostgreSQL 9.4 のロジカルデコーディングに含まれる多くの拡張によって進展を見せています。そして、PostgreSQL 9.6では、まず間違いなく、ロジカルレプリケーションにさらなる 進展が見られるでしょう。非常にシンプルなパラレルクエリは、既にPostgreSQL 9.6にコミットされましたし、さらなる拡張も進行中です。パーティショニングのための文法も進行中です。
そろそろ将来を見るべき時期でしょう。5年前と比較して、現在のPostgreSQLに存在する大きなギャップは何でしょうか？ 具体的には、ひとたび、双子の節穴（the twin knotholes）であるパラレルクエリとロジカルレプリケーションを通り抜けたとすれば、長いこと懸案事項であり私たちがなかなか進捗させられなかったこれらのプロジェクトは、単に離陸させるのが技術的に難しかった結果だったと言えます。次は何でしょうか？ あなたの考えをコメント欄に書いてください。
この点について、自分自身のいくつかの考えについて、 pgconf.us 2015 と pgconf.eu 2015 において The Elephants in the Room というプレゼンテーションでアウトラインを示しました。ビデオもスライドもオンラインで参照可能です。このプレゼンテーションでは、もちろんパラレルクエリおよびロジカルデコーディングについて言及していますし、加えていいくつか他の項目についても触れています:
1. 水平スケーラビリティ。
PostgreQL 9.5は、大規模なサーバでこれまでのどのリリースよりもうまくスケールします（そして将来のどのリリースよりも性能は良くないでしょう！ 常に進化させ続けてますからね！）が、あなたのワークロードのために1サーバを超えるサーバが必要だった場合はどうでしょうか？ あまり大きく取り上げられる機能ではありませんが、PostgreSQL 9.5には外部テーブルを継承テーブルに参加させる機能があります。これは「シャーディング」に至る長い道のりですが、本当に決定的な機能（killer features）にするためのクエリプランナおよびエグゼキュータの機能はまだありません。さらに一般的に言えば、どうやってそれを実現するにせよ、1台のサーバでの処理の効率性をレバレッジ（拡大させる）させることは良いことですが、複数台のサーバをレバレッジさせることはより良いことです。
2. ディスク上のファイルフォーマット。
過去の2回のPGCon（専門家向けのTIP: あなたも行くべきですよ）で、PostgreSQLのテーブルストレージをプラガブルにするには、というディスカッションがありました。インデックスの機構が何年も前からそうなっているように。この機能は、いくつかの改善点とともに、そしてそのことによって後方互換性を壊すことなく、PostgreSQLのストレージフォーマットを完全に置き換えることに道を開くでしょう。おそらくは特定のアプリケーションにより適した特殊なストレージフォーマットが導入されることになるでしょう。より容量が小さく、ディスクからより少ない物理I/Oで、同じだけのデータを読み込むことができるストレージフォーマットは、とくに重要だと思われます。
3. 組み込みのコネクションプーリング。
どれくらいの人が外部のコネクションプーリングを使っており、それを取り除きたいと考えているか、私には定かではありませんが、ある程度の人はいるのではないかと考えています。
プレゼンテーションでは、ダイレクトI/Oについても話していますが、ユーザの観点からの本質的な機能ではないと感じています。もし、誰かが実装し、それが役に立つものになるのであれば、パフォーマンスが改善されるでしょう。もちろん、ソースがどうなったとしても、誰にとっても十分なパフォーマンスを得られることは決してないわけですが。
最後にもう一度。PostgreSQLへのニーズについて、他の項目も大歓迎です。他にあなたが必要だと思うものがあればコメントに書き込んでください。Thanks.
どうだったでしょうか。PostgreSQLの開発者の頭の中、今後の方向性が、少し垣間見えたのではないでしょうか。
上記文中で Robert Haas 氏が「コメント募集」と書いている部分へのフィードバックは、本人のブログのコメント欄へ英語でお願いいたします。Robert Haas氏も喜ぶと思います。
- Robert Haas: PostgreSQL Past, Present, and Future: Moving The Goalposts
http://rhaas.blogspot.jp/2016/01/postgresql-past-present-and-future.html
では。
0 件のコメント:
コメントを投稿