この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
PostgreSQLのヨーロッパにおける年次イベント「PostgreSQL Conference Europe(以下PGConf.EU)」が2022年10月25日から10月28日に渡ってドイツ・ベルリンで開催されました。
地元民の地の利を活かして参加してきましたので、カンファレンスの印象やセッションについてレポートします。
PGConf.EU について
PGConf.EUはヨーロッパ最大の年次のPostgreSQLカンファレンスです。
2009年に第1回がフランス・パリで開催され、毎年異なる都市で開催されています。
直近では、2018年がポルトガル・リスボン、2019年がイタリア・ミラノで開催されたあと、2020年はドイツ・ベルリンの予定でしたが、パンデミックのために2回延期され、2022年に1106日ぶりにカンファレンスが開催されました。
カンファレンスは1日目のワークショップと2〜4日目のセッションの2部構成です。
PGConf.EUでは4名の日本人が参加し、3名(内1名はスピーカー)は日本から、私は市内からの参加(オフィスから徒歩15分)です。
なお、セッションは録画されておらず、セッションの概要とスライドのみ公開されています。
オンサイト開催
PGConf.EU 2022 は100％オンサイト会議です。
録音セッションは一つもなく、スピーカーは聴衆の反応を伺いながら話し、聴衆もセッション中に活発に質問をするため、各セッションは双方向に進みます。
参加者ともふれあえるため、対面カンファレンスのメリットを再認識できました。
なお、会場のBerlin Marriott Hotelの直ぐ側には、DB(ドイツ鉄道)の本社ビルがあります。
キーノート:Efficient Graph Analysis with SQL/PGQ
カンファレンスはPeter Bonczによるについてのキーノートで始まります。
Peter BonczはこれまでにMonetDB、Tableauに買収されたHyPer、VectorWise、DuckDBなど、アカデミックサイドから分析系データベースのアーキテクトとして活躍してきました。 最近では、グラフデータベース向けのクエリー言語の標準化(SQL/PGQ(Property Graph Query))にも携わっています。
キーノート前半は、カラムナーストア、圧縮、クエリーのベクトル化など、大規模な分析データベースで重要なアイデアが触れられました。RedshiftのようなDWHに慣れた人には親しみやすいトピックです。
後半は打って変わってグラフデータのクエリー言語です。
近年は、グラフ操作の需要が高まっており、SQLでは記述が複雑なこと、クエリー言語はグラフデータベースごとに異なることから、標準化する動きがあります。
そのような背景でISOワーキンググループが標準化に取り組んでいるのが、次の2プロジェクトです
- SQL/PGQ (Property Graph Queries)
- GQL (Graph Query Language)
SQL/PGQはSQLを拡張したものであり、リレーショナルモデルで動作し、SQL:2023 に取り込まれる予定です。
キーノートでは SQL/PGQ を中心に
- プロパティ・グラフ・モデルとは
- SQLと SQL/PGQ の記述違い
- RDBMSへの機能追加(特に、スピーカーが携わるDuckDBへの実装方法)
について語られました。
趣の異なる2つのトピックが1キーノートに圧縮され、特に、後半のグラフデータベースは疎いこともあり、カンファレンス1つ目のセッションから、頭がついていくのに苦労しました。
Trigger: How it Works in PostgreSQL Internals
スピーカーはIncremental View Maintenance (IVM)の実装でもおなじみ、SRAのYugo Ngataさんです。
トリガーのユースケース、作り方、インターナルを解説したあと、外部キーが内部的にはトリガーが使われていることや、より複雑なケース、INSERT ON CONFLICT、MERGE、パーティションテーブルにトリガーを使った場合などが解説される、テクニカルなセッションでした。
Q&Aでも、トランザクションでエラーが起きた時の挙動など、込み入った質問が多かったです。
PostgreSQL at GitLab.com
GitLab.comの Database Reliability チームによる事例紹介です。
GitLabはGoogle Cloud上でPostgreSQLを動かしています(96 vCPUS, 624 GB RAMのVM)。
ピーク時は、プライマリノードのRead/Wwriteは 60K TPS、スダンドバイノードのReadは300K TPS、WALは 65MB/s を誇ります。 今後もスケールし、機能拡張しやすいよう、メインシステムとCIという性質の異なるワークロードでクラスターを分割するプロジェクトについての発表でした。
以下の流れでクラスターを2分割します。
- (済)CI のReadを別クラスターに分ける
- (済)メインとCIでWriteエンドポイントを分ける。書き込み先はメインクラスターのまま
- (済)CIのWriteエンドポイントの書き込み先をCI用クラスターに向ける
- (進行形)スケールダウン(今後台数を減らしたい)
本プロジェクトは、GitLabのブログで詳細にまとまっています。
- Decomposing the GitLab backend database, Part 1: Designing and planning | GitLab
- Decomposing the GitLab backend database, Part 2: Final migration and results | GitLab
- Decomposing the GitLab backend database, Part 3: Challenges and surprises | GitLab
クラスターを2分割したため、プロジェクト・レコードはメインクラスターにもCIクラスターにも存在します。 プロジェクト削除時にはメインクラスターだけでなく、CIクラスターのレコードも削除する必要があります。
GitLabはLoose foreign keysという仕組みで解決しました。具体的には、削除にトリガーを仕込み、非同期に結果整合性でCIクラスターのレコードも削除します。具体的な仕組みは、次のドキュメントを参照下さい。
Distributed Postgres: How to build a multi-tenant SaaS app with Citus
マイクロソフト Azure Cosmos DB for PostgreSQL の Principal Group Product Manager である Charles Feddersen によるセッションです
Citus DataはPostgreSQLを分散データベース化したもので、2019年にMicrosoftに買収されました。
RDBMS、NoSQL、分散データベースという最近のデータベースの流れをさらい、分散データベースが正しくスケールする・しないパターン、例えば、シャーディングをdeterministicにすること、データのローカリティが大事で、ノードをまたぐ処理、例えば、ノードをまたいだID採番やトランザクションなどは苦手であること、などが解説されました。 ノード単体で処理できるように設計すべきであり、 コーディネーターはSPOFでしかありません。
「分散データベースは大規模データのためにあるというのは誤解だ」というなかなか刺激的な発言も飛び出しました。
MVCC Unmasked
EDBのBruce Momjian による多版同時実行制御(MultiVersion Concurrency Control;MVCC)の解説です。
MVCCはトランザクションの隔離性を活かし、同時実行性を向上させる仕組みであり、多くのデータベースで実装されています。 MVCCのおかげで、読み込みは書き込みをブロックせず、書き込みは読み込みをブロックしません。
レコード操作・トランザクション・ロックなどによって、タプルがどのように更新され、スナップショットとしてどのように見えるのか、などについて解説します。
スピーカーのBruceは10年前から同じテーマで発表しています。 過去には、ローラーコースターに乗っている様と表現されたからか、今回は、聴衆の理解を待つために少し長めに間を取ったり、随時飛んでくる質問にも丁寧に答えるなど、工夫が伺えました。
YouTube で過去のトークを確認できるため、興味のある方は、参照ください。
Collations in PostgreSQL: The good, the bad and the ugly.
Swiss Academy of Sciences (SCNAT)のTobias Bussmann(ドイツ語話者)によるPostgreSQLの照合順序(collation)についてのセッションです。
collationは文字・シンボルをソートする仕組みであり、日本語圏のMySQL界隈では寿司とビールの絵文字を同一視してしまう件でも有名です。
ヨーロッパ開催のカンファレンスのため、ヨーロッパの言語を例にしたものが多く、チェコ語のアルファベットは"a, b, c, ..., h, ch, i, ..." という並びのため、チェコ語でインデックス化したときのソートの悲劇などは、日本では知る機会はないでしょう。
ロケール、プロバイダー(libc/icu)とそのバージョンによって挙動が異なるため、スピーカーのおすすめは
- ロケール : C
- プロバイダー : icu でバージョンをピン留め
だそうです。
Building a perf-like tool for PostgreSQL
Aiven の Ronan Dunklau による PostgreSQL 向けの eBPF ベースのトレースツール「pgtracer」についての紹介です。
PostgreSQLサーバープロセスにアタッチして、実行中のSQLや使用リソースなどをダイナミックに取得できます。
デバッグビルドしたPostgreSQLに対して、DWARFを使ってオフセットを考慮しながらプロセスのメモリにアクセスしているなどが語られました。
現在はまだPoC段階にあり、機能もミニマリスティックです。
前日にはRedHatのDmitrii Dolgovが同様のテーマで発表しています(未参加)
Party tricks for PostgreSQL: perf, ftrace and bpftrace
DBへのdynamic instrumentationは今後どんどん開拓が進みそうです。
Exploring Linux Memory Usage and IO Performance for PostgreSQL
YugabyteDBのFrits HooglandによるLinuxのメモリとディスクのパフォーマンスに関するセッションです。
PostgreSQL互換の分散データベースであるYugabyteDBについては触れることなく、Buffered I/Oやページ・キャッシュについて延々と語ります。スライドにあるAmazon EC2とfioを使ったストレージのベンチマークは、一度ワークショップ的に動かすと、理解が深まると思います。
識者によると、Buffered I/O を使っている PostgreSQL を Direct I/O 対応させる動きが定期的にあるものの、実現への目処はまだのようです。
関連 : PostgreSQLは20年間どのようにfsyncを間違って使っていたか - 聴講メモ -
Fritsは FOSDEM 2022 や Devoxx France 2022 でも同じテーマで話しています。
興味のある方は、参照ください。
ライトニングトーク
最終日はクロージングの前にLT大会が行われました。
トップバッターは、20年以上にわたりPostgreSQLにコントリビュートしてきた Simon Riggs のコントリビューターからの引退宣言です。 参加者全員がスタンディング・オーベーションで迎えます
以降は10人ほどLTが続き、やってみた系、製品紹介からお笑いまで幅広いトピックが扱われました。
発表したいひとは、事前に掲示板に記入します。
クロージング
最後に、PGConf.EU のクロージングです。
3年ぶりの開催で参加者は過去最大の約600人です。
開催国のドイツからの参加が最大なのは当然として、2位のオランダと3位のアメリカはほぼ同数です。
最終日はRe:invent 2019時に利用した派手なクラスメソッド・ジャケットを羽織って参加していたのですが、「そのジャケット良いね」と声をかけてくる人は皆アメリカ人という知見を得ることができました。
いつもは、クロージングの最後に次回の開催国・地の発表があるのですが、今回はお預けでした。
後日の発表を待ちましょう。
終わりに
セッションは3日間、参加者は約600名と程よいサイズです。 ロー・キーでリラックスした技術系カンファレンスが好きな人は、参加してみてはいかがでしょうか。
いつもはデータベースやミドルウェアについて対面で話す機会がなかなか無いので、非常に楽しいひと時を過ごすことができました。
会場で絡んでくれた皆様、ありがとうございました。
1
