PostgreSQL Conference Europe 2018 参加レポート

SRA OSS, Inc. 日本支社
OSS事業本部 技術部 PostgreSQL技術グループ チーフエンジニア
長田 悠吾

2018年10月24日から26日にかけてポルトガルのリスボンで開催された PGConf.EU 2018 に参加してきました。

本記事では、その様子をレポートします。

はじめに

PGConf.EU は、正確には PostgreSQL Conference Europe といい、ヨーロッパの PostgreSQL ユーザコミュニティ PostgreSQL Europe が主催する、ヨーロッパで最大の PostgreSQL カンファレンスです。
毎年秋にヨーロッパの各地の主要都市で開催されており、記念すべき１０回目の開催となる今回はポルトガルの首都リスボンが舞台となりました。
毎年ヨーロッパ内外から数多くの PostgreSQL 開発者やユーザが参加します。
今回の参加人数は 450 名と過去最大の規模となり、チケットは全て売り切れ、キャンセル待ちが発生するという人気ぶりでした。

私が PGConf.EU に参加するのは、これで２回目になります。
前回参加したのは 2012 年にチェコのプラハで開催された時で、その時は弊社支社長の石井が発表を行いました。
そして、今回の PGConf.EU 2018 では、私自身が発表者として参加することとなりました。

サン・ペドロ・デ・アルカンタラ展望台から望むリスボンの街並

リスボンは、きれいに敷き詰められた石畳の路上を路面電車が行き交う美しい街でした。
「７つの丘の街」と呼ばれるほどに坂が多い街で歩き回るのは少し疲れますが、ケーブルカーで坂を登った先にある展望台からは赤レンガの屋根の街並みとその向こうを流れるテージョ川が一望できます。

今回の会場となったのはそんな旧市街から地下鉄に乗って少し離れた所にある Lisbon Marriott Hotel の会議室です。
発表セッションは 大・中・小の３つの部屋で３トラック並行して行われました。
これらの発表の中から、いくつかピックアップしてご紹介します。

PostgreSQL で空間情報を解析する

オープニング後の基調講演は、PostGIS（PostgreSQL で地理情報を扱うための拡張モジュール）の開発者である Paul Ramsey によるセッション「Location – the universal foreign key. Past, present and future of spatial data in PostgreSQL」でした。
キーワードは「空間情報はユニバーサルな外部キー」。
明示的には関連付けられていないデータ間でも、そこに含まれている住所や地図座標などの「空間情報」で関連付けて地図上に視覚化することで、色々なことが見えてきます。

講演では、GIS（Geographic Information System: 地理情報システム）の簡単な歴史の紹介の後、PostgreSQL で地理情報を扱う方法が、地理情報の「入手」「可視化」「解析」の３段階に分けて説明されました。
この内「解析」の段階で PostGIS と SQL が多いに役立つわけですが、PostGIS で用意されている関数はなんと 300 個以上！発表では、この中のいくつかの使用例が紹介されました。
題材として取り上げられたのは、スターバックスコーヒーの店舗の位置情報データ。
このデータを使って、「最もたくさん店舗がある地域はどこか？」「１号店から最も遠い所にある店舗は？」「そこから近い店舗の上位５つは？」「特定の地域内の店舗分布とそこの住民の収入の関係は？」などの実例があげられました。
地図上に情報が可視化されていく様は見た目にも面白く、聞いている自分も PostGIS で何か地理情報の解析をしてみたくなるようなセッションでした。

PostgreSQL の新しい話・古い話

Magunus Hagander によるセッション「What’s new in PostgreSQL 11」では、この秋にリリースされたばかりの PostgreSQL 11 の新機能が「DBAおよび管理」「SQLおよび開発者向け」「バックアップとレプリケーション」「パフォーマンス」の４つのカテゴリに分けて紹介されました。

その内、「パフォーマンス」の中で取り上げられていた、パラレルクエリ、パーティショニングの改善、JIT（Just in Time: 実行時）コンパイル基盤の導入などは、PostgreSQL 11 の中で注目の新機能と言えるでしょう。
その他にも、ALTER TABLE .. ADD COLUMN の性能改善や、INCLUDE インデックス（インデックス内にキー値以外のカラム値を格納することで、インデックスオンリースキャンの使用可能性を高められる機能）、ストアドプロシージャのサポートや、ウィンドウ関数の機能拡張（フレーム句の SQL:2011 完全準拠）なんかも、比較的注目される新機能のように思われます。
少々地味なところとしては、pg_prewarm によるプリウォーム（アクセス高速化のため、予めテーブルデータをメモリにロードしておくこと）が PostgreSQL 起動時に自動的に行えるようになったことや、Web 検索エンジンにような書式で全文検索行うための websearch_to_tsquery 関数が追加されたことなども取り上げられていました。

これに続く Devrim Gündüz のセッションのタイトルは「What is old in PostgreSQL 11?」。
「PostgreSQL の新機能の話はよく聞くけれども、時代遅れの機能についての話はあまりない・・・」ということで、この講演では、古い PostgreSQL から変更され、互換性がなくなったり、時代遅れになった機能について語られました。

序盤では、max_fsm_pages, stats_start_collector など既に使用されなくなったパラメータなどを冗談交じりに紹介したあと、まだ記憶に新しい、昨年の PostgreSQL 10 での変更点について触れられました。
例えば、トランザクションログおよびコミットログを格納するディレクトリ名が、それぞれ pg_xlog / pg_clog から pg_wal / pg_xact に変更されたこと、pg_baseback コマンドの -x オプションが廃止されたこと、などです。最近リリースされたばかりの PostgreSQL 11 にも、CREATE FUNCTION の WITH 句の廃止など、互換性のない変更点があります。
そして「古い」と言えば PostgreSQL 9.3 が EOL（End of Life）を迎えたことも忘れてはいけません。

セッションの終盤では、「パーティションテーブルにインデックスやトリガを作成できない、というのはもう古い！」「テーブルにカラムを追加するのは遅い、というのはもう古い！」といった論調で PostgreSQL 11 の新機能を紹介。
そして、セッション後には聴衆からも「古い」ものを募集し、聴衆からは、テーブル行の OID（PostgreSQL 12 からはテーブルを WITH OIDS で作成できなくなる予定）や、tsearch3（古い全文検索モジュール）などが挙げられました。
最後まで、笑いの耐えない、とても盛り上がったセッションでした。

レセプションパーティはホテルの庭にて

PostgreSQL に新しいストレージ形式を

Amit Kapila によるセッション「zheap: An answer to PostgreSQL bloat woes」は、現在開発中で zheap と呼ばれる UNDO ログに基づくストレージ形式についての講演です。

UNDO ログはテーブルの更新を「元に戻す」ためのログで、Oracle など他のデータベースではトランザクションのロールバックに使用されます。
一方 PostgreSQL のテーブルデータの更新は、古い行を残したまま新しい行を挿入する「追記型」で行われるため UNDOログは存在しません。
そのかわり、不要領域が残ってテーブルサイズの肥大化する可能性があります。
これを回避するために要領域の回収するのが VACUUM の役割です。
しかし、zheap によって PostgreSQL で UNDO ログに基づくストレージが使用可能になれば、不要領域による肥大化が回避され、テーブルサイズが小さく抑えられるというメリットがあります。
もしかしたら、VACUUM が必要なくなる日も来るかもしれません。

この講演では、zheap で使用されるテーブルデータの形式や、更新時の処理などを説明した後、実際の計測結果が紹介されました。
それによると、従来の実装ではテーブルサイズが２倍に肥大化する状況下でも、zheap ではテーブルサイズに影響がなかったことが示されました。
さらに、テーブルサイズの肥大化を回避できることで、検索性能の向上も見られたとのことです。

zheap のような新しいストレージ形式を PostgreSQL で可能にする仕組みの紹介が、Andres Freund のセッション「Pluggable Storage in PostgreSQL」で紹介されました。
これは、PostgreSQL で使用可能なストレージシステムの選択肢を増やすための基盤です。
「CREATE TABLE tbl(…) USING heap;」のように、テーブル毎にストレージが選択できるようになるようです。
これを利用すると、UNDO ログに基づく zheap ストレージだけではなく、カラム指向ストレージや、インメモリストレージなど、他のストレージ形式が PostgreSQL で利用できるようになる可能性が出てきます。

「拡張性」は PostgreSQL の大きな特徴の１つで、これまでも新しいデータ型や関数、インデックスなどの作成によって様々な拡張が行われてきました。
今回の基調講演のテーマである PostGIS もその１つです。
その拡張可能な領域がついにストレージ形式にまで拡大することで、PostgreSQL の可能性がまた大きく広がりそうです。

石畳の路を行き交う路面電車

PostgreSQL をハックする

新機能の開発が着々と進む PostgreSQL ですが、そんな PostgreSQL の開発に参加したい人のためのセッションもいくつかありました。

Stephen Frost のセッション「Hacking PostgreSQL」は、PostgreSQL への機能追加の入門編といった内容で、PostgreSQL バックエンドサーバのソースコードの構成や、新しい機能の追加例が紹介されました。
具体例として、COPY 文に新しいオプションを追加する場合を取り上げ、パーサ（構文解析器）への新しい構文の追加や、機能の追加のために必要なコード修正について説明されていました。
また、メモリ管理や、エラーロギング、データ構造などの内部コンポーネントの説明や、コーディングスタイルのガイドライン、コミュニティへのパッチの投稿の仕方などにも触れられていました。
なお、投稿されたパッチをどのようにレビューするか、その過程について説明するセッションとしては Stephen Frost の「Review of Patch Reviewing」がありました。

もう少し詳しく PostgreSQL のコードの中身を紹介するものとして、Heikki Linnakangas のセッション「PostgreSQL Serverside Programming in C」がありました。
この講演では、C言語で PostgreSQL の拡張モジュールを書きたい人や、PostgreSQL のサーバそのものをハックしたい人を対象に、メモリ管理、エラー処理、データ構造など実装インフラの使い方が紹介されていました。

実行計画の自動チューニング

将来的な PostgreSQL の改良に向けた、より実験的な試みについて発表するセッションもありました。

その１つである Tatsuro Yamada によるセッション「AUTO PLAN TUNING USING FEEDBACK LOOP」では、PostgreSQL のプランナ（実行計画を生成するモジュール）の自動チューニングを行うアイデアが語られました。
PostgreSQL のプランナの問題点として、クエリが複雑になると取得される行数の推定の誤りが生じ、これが原因で適切なプランを選べずにクエリ実行に時間がかかってしまう場合があります。
この講演では、プランナが推定した行数と実際に取得された行数の誤差をプランナに「フィードバック」することでプランナの行数推定を補正し、徐々にプランナを最適化していくことでこの問題を解決する手法を提案しています。

そして、これを実現するために開発された pg_plan_advsr という拡張モジュールが紹介されました。
pg_plan_advsr の実装はまだ PoC（Proof of Concept, 概念実証: アイデアの実現可能性を評価するための試作）の段階とのことですが、このツールを使ってチューニングを行うことで、あるクエリの性能を約２倍も改善することが出来たとのことです。

セッションは、自動チューニングを利用した自律型データベースのアイデアの紹介で締めくくられました。
最近話題になっているシステムの自律化については私自身も関心が有ることもあり、とても興味深く刺激的な発表でした。

マテリアライズドビューの差分更新

実験的な試みのもう１つとして、最後に、私自身（Yugo Nagata）によるセッション「Implementing Incremental View Maintenance on PostgreSQL」をご紹介します。

長田による Implementing Incremental View Maintenance on PostgreSQL の発表

マテリアライズドビューでは通常のビューと異なり、問い合わせの結果が予めデータとして保存されています。
これにより、ビューへの問い合わせが発生した時には保存されている結果を使用することで高速な応答が可能となります。
ただし、ビューの定義に含まれるテーブルが更新された場合には、マテリアライズドビューに保存されている内容も最新の状態に更新する必要が出てきます。
このために REFRESH MATERIALIZED VIEW というコマンドがあるのですが、これはマテリアライズドビューに含まれる「全ての行」を再計算する必要があります。

これに対し、Incremental View Maintenance (IVM) は、全ての行ではなく「差分」のみを計算する方法です。
この機能は今の PostgreSQL には実装されていません。
この講演では我々が行った IVM の PoC 実装について紹介しました。
この実装では、マテリアライズドビューの中で更新すべき行の計算するために、テーブルの行 OID を使用しています。
これは、一緒に共同研究をしているお茶の水女子大学名誉教授の増永良文先生のアイデアが元となっています。
PoC 実装ということで、対応しているビュー定義などの制限はあるのですが、ある状況下に置いては通常の REFRESH コマンドに比べて数十倍の速さでマテリアライズドビューを更新できることが示されました。

セッション終了後には質問も多数いただき、マテリアライズドビューの差分更新という課題に対する関心の高さが伺えました。
しかしながら、現在の PoC の実装にはいくつか問題があります。
既に廃止が決まっているテーブルの行 OIDを使用していることもその１つです。
今後は、PoC 実装で得た知見をベースに、より実用的な IVM 実装を PostgreSQL で実現していくことを計画しています。

おわりに

今回の PGConf.EU 2018 も、PostgreSQL に情熱を傾ける多くの人たちに発表に触れて、大いに刺激を受けるものでした。
このレポートで紹介した発表の他にも、PostgreSQL の素晴らしさを伝えようとする発表が多くありました。
私自身も PostgreSQL の開発を通して、PostgreSQL の進化とコミュニティの発展に貢献していきたいと思います。

少し気が早い話ですが、来年の PGConf.EU 2019 はイタリアのミラノでの開催に決まったようです。
日本からヨーロッパは遠いですが、もし機会がありましたら、是非 PGConf.EU に参加することをおすすめします。
私もまた参加できることを願っています。

PGConf.EU 2018 で配られたTシャツとノベリティ。