PGconf.EU 2018参加レポート

10/23～26にかけて、ポルトガル・リスボンで開催されたPGconf.EU2018へ参加してきました。
リスボンへはドイツ駐在中の2013年に一度旅行で訪れた事があり、個人的にも懐かしい、5年ぶりの訪問となります。

PGconf.EUとは、PostgreSQLの欧州ユーザコミュニティが主催するカンファレンスで、今回はちょうど10回目。450名分の参加チケットが売り切れるなどPostgreSQLの技術カンファレンスとしては最大のものです。海外は過去に2012（チェコ・プラハ）、2015（オーストリア・ウィーン）の2回に参加、発表しており、今回で3回目の参加となります。

リスボンまでは直行便がないため、成田～ヘルシンキ～リスボンと途中で乗り換えを挟み、片道１８時間のフライト（ヘルシンキでの接続４時間を含む）でした。成田～リスボンの中間地点に位置しているので、意外にルート的な無駄は少ない様子。*1

セッションピックアップ

参加したセッションの中から、いくつか感想を書いておくことにします。
発表資料に関しては、順次リンク先に追加されるはずですので確認してみてください。


Location - the universal foreign key. Past, present and future of spatial data in PostgreSQL (Paul Ramsey)

PostGISのオリジナル開発者によるセッション。
自分もGIS系ワークロードのGPU高速化について質問＆リクエストされる事が多々あり、興味深く聞いてみた。
いくつか分析の実例という事で、全世界のスターバックスの店舗位置を使った距離計算などのケースが紹介されていたが、実際、この手の地理データ分析というのはどの程度の件数を扱う事を前提にすればいいのだろうか？
おそらく、モバイルデバイスから出てくる座標（緯度・経度）を集計するようなものだと、データ件数は非常に大きなものになるので、SSD2GPUなどストレージ系の高速化技術と組み合わせる事が必要になってくる。
ただ、店舗情報などどれだけ大きくても"億"の単位に行かないようなデータサイズであれば、オーダーはGB以下になり、実際にはI/Oが問題となるような事はなくなる。逆に計算量が支配的になるため、Gstore_fdwのようにGPUメモリを使ったストレージに対して単純にGPUカーネルをキックしてやるという事になるだろう。
いずれにせよPL/CUDA以外の普通のSQLからきちんとGstore_fdwを使うための機能強化は検討中なので、その後GIS関数の対応を考えた方がよさげ。

PostgreSQL Serverside Programming in C (Heikki Linnakangas)

PostgreSQLのサーバサイドで動かすCの拡張モジュールを作るための基本的なインフラについて説明する教育的なセッション。
メモリコンテキストやらエラー・例外の使い方などが資料に網羅されているので、初心者が軽く目を通しておくには良い資料だと思う。

What's new in PostgreSQL 11 (Magnus Hagander)

PostgreSQL v11の新機能を紹介するセッション。
パーティション周りの機能強化やパラレルスキャンの強化など、リリースノートで周知されているものではあるが、PG-Strom的に少し注意が必要かなと思ったのは以下の二点。

  • ALTER TABLE ... ADD COLUMN defaultをテーブル書き換えなしで実行する
  • 実行ステージのPartition Pruning

前者は、古いテーブル定義に基づいてINSERTされたレコード（当然ADD COLUMNされた列は存在しない）を展開する時に、列番号 > nattrs の時にはnullとして扱うというのが既定の動作であったが、仮にADD COLUMN defaultされた値があれば、あたかもそのdefault値がそこにあるかのように振舞わねばならない。これはレコードを展開するコード（SQLから自動生成する）部分の機能強化が必要。
後者は、実行時に不要なパーティションを落とす事が有効になってはいるものの、PG-Stromが独自にJOINやGROUP BYをプッシュダウンして作成した実行計画の場合に正しく動くんだっけな？？という事が気になったので要確認。

zheap: An answer to PostgreSQL bloat woes (Amit Kapila)

Pluggable Storageと併せて開発が進められているzHeapについてのセッション。これはPostgreSQLにUNDOログに基づくストレージ形式を持ち込もうという話で、従来のHeapと比べ、トランザクション負荷が高い時のテーブルサイズ増加（主に被更新行の占有するディスク領域によるもの）が緩やかであるという特徴を持つ。
トランザクション系の方はあまり興味はないのだけども、zHeapのメカニズムが入る事によって最終的にvacuum不要となり、それによってvisibility mapが無くなってしまうと困ったことになる。
visibility mapによって、データブロックを読む前に、当該ブロックがMVCC可視性チェックを必要とするかどうかを判断できるので、GPUではコミットログを参照できない以上、all-visibleなブロックだけをSSD-to-GPUダイレクトSQLの対象とする事ができる。
ただ本質的には、コミットログを参照できないだけで、HintBitによりレコードの可視性を判断できればall-visibleなページに限定する必要はない。なので、こちらは代用品としてのvisibility-mapを使うのではなく『all-visibleまたは全てのレコードにHintBitがセットされている』状態を担保できるよう、ブロックの状態が変化した時にExtensionが捕捉できるようフックが必要という事ではありそうだ。

CREATE STATISTICS - what is it for? (Tomas Vondra)

WHERE cond AND condやGROUP BY col1, col2のように複数の条件が絡む場合、それぞれの条件が全く独立事象である場合は単純にP(cond1) * P(cond2)で行数が推定できるが、実際には互いに相関関係があるため、過剰・過少に行推定をしてしまう。これにより、例えばNested Loopのような実行計画は行数が増加すると極端に実行効率が下がるため、性能インパクトが大きい。（数行を迅速に取り出すという用途ならいいんですが）
こういった問題を避けるため、CREATE STATISTICS構文によってDBAが明示的に変数間の相関関係を教えてやることができるようになる。

た・だ・し、いくら行推定を頑張ったとして、JOINの段数が増えていったり、条件句に使う関数のselectivityが現実を反映していなかったりすると、推定行数はどんどん実態と乖離していく。例えば条件なしSeqScanの推定行はテーブルサイズからほぼ正確に導出する事ができるが、特に何も考えなしにselectivity=0.5の条件でスキャンしたものを別のテーブルとJOINした結果などはほぼ根拠レスと言ってよい。
こういった値であっても、PostgreSQLは同様に「行数の推定値」として扱ってしまうため、時には事故が起こる事もある。

これは自分の持論であるが、行推定は行推定で頑張るとして、それがどれくらい信用できるのかという reliability は別のファクターとして実行計画作成に組み込むべきではなかろうか。
例えば nrows = 10, reliability = 0.99 ならIndexつきNested Loopは（たぶん）問題ない選択肢だろうが、nrows=10, reliability = 0.10 ならもしかすると、過剰に上振れした場合には安全側に倒して Hash Join を選択しておく方がベターかもしれない。


着ぐるみの中の人でもあります。なんかワシがスナイパーに狙撃されたような写真になってますが。

Pluggable Storage in PostgreSQL (Andres Freund)

PostgreSQL v12あたりで？入ってくるのだろうか、Pluggable Storageの最新の開発状況の紹介。
現状zHeapがターゲットではあるが、可能性としてはColumnarストレージを実装する事も可能。
CREATE TABLE xxx (...) USING heap;のような使い方をする。

WALの方は変わらないので、あくまでもストレージフォーマットの話で、基本はrow-by-row。
なのでAndreasの意見に100%同意なんだけど、scan_getnextslot()みたいに「全ての列を」「一行ずつ」取り出すためのインターフェースでは列指向ストレージを要求するような高いスループットのSQL処理には全く追いつかないので、列指向ストレージ用のCustomScanを定義して、場合によってはJOINやGROUP BYも含めたベクトル化は必要になるだろう。

あと、拡張モジュール的視点では、TupleTableSlotがコールバックを持つようになり、これが個々のストレージ形式とHeapTuple形式の間を仲介するようになる。今後、基本的にレコードの受け渡しにはHeapTupleではなくTupleTableSlotを使うようになるので、例えばCで書かれたトリガ関数などは影響を受ける可能性がある。

発表（その１）ライトニングトーク

自分の発表その１は２日目夕方のライトニングトーク。
2年前のPL/CUDAの発表ネタから、関数の引数が巨大（数百MB～）になるときの呼出しオーバーヘッド問題の解決のためにGPUメモリストアであるGstore_fdwの開発と、そこからの応用としてCUDA APIのプロセス間通信（IPC）機能を用いてPythonスクリプトとデータ連携を行うところまでを駆け足で紹介した。さすがに5分で30ページはチャレンジングであったが、だいたい収まった。

LT発表資料（5分なのに30pもある・・・。）

www.slideshare.net

発表（その２）本番

自分の発表その２は、最終日のセッション発表。
概ね70%くらいの席の埋まり具合で40名弱というところ。テーマ自体は面白いと思ってもらえる自信があるが、聞いてもらえなければ仕方ない。ちょいと残念。

日本の皆さんには既にお馴染みの内容だとは思うが、PCIeバス上のP2P DMA（SSD-to-GPUダイレクトSQL）を用いてストレージ上のPostgreSQLデータブロックを直接GPUに転送し、データを減らしてからホストシステムに書き戻す。
加えて、現行のXeonプロセッサだと7.1～8.5GB/sといった辺りで性能がサチってしまう問題を紹介し、それを回避するために、PCIeスイッチを搭載したハードウェア（HPCサーバやI/O拡張ボックス）を用いてストレージに近いところでSQLを処理、CPUの制御するPCIeバスの負荷を軽減するという手法を説明した。
これらの改良を加える事で、I/O中心ワークロードのスループットを改善し、3台のI/Oボックスで13.5GB/s*2、スペック上可能な8台構成では30GB/s程度まで狙えるのでは？という所で話を締めくくった。

面白かったのが、スライド p.19 の絵を見せてSSD-to-GPUダイレクトSQLの説明をした瞬間、発表している側からはっきり分かるレベルで参加者の顔色が『マジかこいつ！？』みたいに変わったところ。
そりゃそうだろう。PostgreSQLコミッターレベルの人と話をしても、基本的には『GPU = 計算のアクセラレータ』という先入観でみんな話をしている所に、普通のNVME-SSDストレージを、ExadataやNetezzaがやっているようなインテリジェントなストレージに変身させるための素材としてGPUを使いましょうという提案なんだから。

発表資料：

www.slideshare.net

質疑応答に関しては覚えているものだけでこんな感じ

  • ファイルシステムは経由するのか？そこがボトルネックになるが。
  • Nvmeにはパフォーマンスの問題がｺﾞﾆｮｺﾞﾆｮｺﾞﾆｮ
    • 申し訳ないが、今のところNVMEドライバでパフォーマンス問題にぶち当たった事はない。
    • （後で思ったが）PCIe NVMEでリクエストの多重度が上がった時にdma_alloc_pool()がクッソ遅くなる事を言ってたのだろうか？そこは自前で持つようにして性能問題は解決している。
  • レイテンシはどうなのか？
    • いや、このワークロードはレイテンシではなくスループットが問題。

PivotalのTシャツを着た人がやたら怖い顔をして質問を突っ込んできた。善きかな善きかな。

あと、学生さんみたいだけどこんなコメントも。素直に嬉しい。


所感

昨年のPGconf.EUでは（GPU１個の）SSD-to-GPUダイレクトSQLをテーマにプロポーザルを出したものの Rejected になってしまったので、ようやくグローバルのコミュニティ向けに SSD-to-GPUダイレクトSQL について発表する機会を得られたという事で、宿願叶ったりという事になる。

ただ、450人が登録しているカンファレンスで3セッションが並列で進行。その中で自分のセッションへの参加者が40名弱というのはちょっと問題。
PeterやAmitなど一部の主要開発者にはレセプション等の機会を使って、現在のPG-StromはI/Oの高速化を追求するアーキテクチャになっている事などを説明したが、まだ『GPU = 計算アクセラレータでしょ』という認識をひっくり返せたとは言い難い気はする。

この辺、英語の問題でセッションを避けられてるのか、"GPU"のキーワードが自分ごとではないように感じさせてるのか、コミュニティへの露出が最近下がってるので「あんた誰？」になってるのか、ちょっと分析は必要かもしれない。やはり欧州/米国でのカンファレンスとなると、費用と時間はそれなりにかかる訳だから、発表するだけで満足することなく、自分たちの技術的成果やその価値を広く認識してもらう作戦も必要だろう。

最後に、ほぼ一週間家を空けていた間、娘と息子の世話を一人でやってくれた嫁さんに感謝である。

観光

航空券の価格の都合により、一日滞在を伸ばしたとしても（土曜日ではなく）日曜日にリスボンを発つフライトの方が安上がりだったので、出張経費削減のため止むなくリスボン周辺を１日観光する事に。
ユネスコ世界遺産の「シントラの文化的景観」、ユーラシア大陸最西端「ロカ岬」を回ってきました。こちら、長くなったので写真をFacebookに上げておきました。
www.facebook.com

*1:ただ、次は直行便で行ける都市がいいなぁ…。

*2:1.05TBのテーブル全件スキャンを含むクエリが80s弱で完了する