PostgreSQL Conference Japan 2024に行ってきた
始まる前の気持ち
去年は WAL も VACUUM も知らない中での参加でしたが、DB ないし PostgreSQL の奥深さを身に染みて感じられたカンファレンスでした。そして今年は DB の勉強をたくさんしてもっと深く理解できると思いとても楽しみにしていました。
去年と比べてスーツじゃない人が多くてコミュニティの層が広がってきてるのかもしれないと思いました。
午前
午前はキーノート 2 本でどちらも AWS の Senior＆PostgreSQL の Committer（世界に 30 人しかいない）方々の発表でした。
どちらも AWS の方だったのにも関わらず、自社製品の紹介などはほとんどなく、コミュニティ活動にどう貢献しているか、PostgreSQL はどのように進化していくかという話でコミュニティへの貢献の姿勢が非常に印象深かったです。
また、会場にコントリビューターもコミッターもいるので内部実装の質問、コメントがバンバン出てきます。
キーノート 1：PostgreSQL 17 と PostgreSQL 開発最前線
VACUUM のパフォーマンス改善のコントリビュートをされている澤田さんのキーノートでした。
コミッター自ら説明してくれるという豪華体験…！
Vacuum が大幅アップデート
本人はアピールされないですが、澤田さんが開発された機能です。
爆速＆省メモリ＆省 WAL になるとのこと。
PostgreSQL 16 までの TID の格納方法は長い配列 1 つでした。バイナリサーチ O(Log N)で検索効率も格納効率も悪いです。
今回の PostgreSQL 17 では Adaptive Radix Tree（ART）を実装し、その上に TidStore という PostgreSQL の構造を作成されたそうです。
TID のオフセットを 100 個格納しても 28bytes(16 以前は 600 bytes)で検索は常に O(k)となり、固定で確保されていたメモリも必要に応じて段階的に確保するようになりました。
論理レプリケーションの改善
物理レプリケーションと論理レプリケーションをしているときに、フェイルオーバーでプライマリ入れ替わっても物理レプリケーションを論理レプリケーションが追い越さなくなって事故らなくなりました。ただし、フェイルオーバー Ready かどうかはドキュメントを要確認、そのためのコマンドは今（17）はありません。
さらにさらに
pg_basebackup に増分バックアップ オプションが入った。増分バックアップをリストアするときは pg_combinebackup でフルバックアップとその後の増分バックアップを指定します。
最新データの変更がなくとも、VACCUM も増分バックアップに影響します。
キーノート 2: AWS and the PostgreSQL community
同じく AWS の PostgreSQL Commiter のミカエルさんの発表でした。内容は簡単に下記です。
- AWS とコミュニティの両方にコミット、貢献していくことは結構難しい。企業と異なり、コミュニティは短期では成果を出すことができない人間を育てる必要があるから
- クラウドベンダーとして PostgreSQL の改善が事業に貢献することになる。拡張としては AWS のメンバーが多く開発しているが、pg_hint_plan などは特に重要
- PostgreSQL 本体を改善することでビジネス的な価値を生み出している。PostgreSQL 内蔵の libc、ICU より早い文字列比較を書いてしまった
午後
MySQL 8.0 から PostgreSQL 16 への移行と RLS 導入までの道のりと学び
私もまさか両方で登壇される方がいらっしゃるとは思いませんでした。ひたすら尊敬 🙏
「RLS 使いたいんだけど弊社は MySQL なんだが？」案件のお話でした。
その中でも、
- RLS 設定もれチェックを SQL で行う方法
- Aurora Serverlessv2 によるスロークエリ解消
- MySQL→PostgreSQL でバグ 0 件を達成した方法
が印象的でした。
ロジカルレプリケーションを使った DB 統合
Wantedly さんで行われたロジカルレプリケーションを使った DB 統合についての事例紹介でした。
DB 統合を作業時間 1 時間で達成された方法の紹介と
実際やって苦労された点が紹介されていました。
実際にロジカルレプリケーションをするときに非常に参考になる内容でした。
PostgreSQL におけるパーティショニング性能向上
NTT OSS センタの方で PostgreSQL のパーティショニングのプランニングの性能向上の改善を PostgreSQL 18 に乗せようとしているというお話でした。
高度でしたが、非常に興味深い内容です。まとめると以下のような内容です。
- 大量のデータがあり、大量のパーティションがあるときに結合のクエリが性能劣化する
- 結合演算の等価性の評価がプランニングで行われており、それがボトルネックになっている
- 改善後は二次関数的だったのが線形増加になっている
- 結合するテーブルの数が増えるほどパーティション数の影響が大きく、改善の効果も大きい
Tsurugi と PostgreSQL
Tsurugi という国産 DB の現在地点のお話でした。
- Seriarizable でインメモリー
- バッチが速い
- ロックフリー（特に特徴）
- 分散システム指向
という最先端の DB が本番環境に投入されたというお話と、DDL のロックフリートランザクションをどう考えるかというアカデミアレベルの課題に立ち向かわれているというお話で、異世界転生の感すら得られた素晴らしいセッションでした。
全体の感想
アプリケーションエンジニアを仕事でしている中であまり中身を気にする機会は少ないかもしれませんが、PostgreSQL はものすごい数の優秀なエンジニアがたくさんの時間をかけて今なお爆速で進化していることを改めて感じることができました。
DB の知識はアプリケーションが使われて、進化していくにつれて、重要度が高まるので、いざ必要になったときに、こうした最新の状況に触れられていることがきっとプロダクトを救ってくれることにつながるような予感がしています。
去年はほとんど内容がわからなかったカンファレンスですが、今年は基調講演の内容も 6 割以上は理解できた気がします。
それは内部構造から学ぶ PostgreSQL ―設計・運用計画の鉄則を読んで勉強会に参加したことが大きかったと思います。
ずっとこのカンファレンスに参加してるといつかは PostgreSQL のソースコードが理解できるくらいになれる日が来るのかもしれない...？
Discussion