自転車とプログラミング

元自転車メーカーのマーケター、今は自社開発企業に勤めるエンジニアが主にプログラミングの話を書きます。

PostgreSQL Conference Japan 2024 に参加しました(+データベースを学ぶモチベーション)

12/6に開催されたPostgreSQLのカンファレンスに会社の同僚と行ってきましたので、「なんでDBなんだ」てところも含めたレポートです。

この記事はフィヨルドブートキャンプ Part 2 Advent Calendar 2024の15日目の記事です。

当初はエンジニアになったので普段を振り返ってあれやこれや書こうかとも思いましたが、ネタ被り著しいので直近の話題ということでPostgreSQLに触れていきたいと思います。

まず自己紹介

2023年12月にFJORD BOOT CAMPフィヨルドブートキャンプ)を卒業後、Railsを使った自社開発企業に就職しました。

エンジニアになってからはプロダクトを触ったり、他部署のヘルプに行ったり、LT会を開催したり、インフラやDevOps周りを見たりして、今は簡単な機能追加をさせてもらったりしています。FBCで鍛えてもらったのでなんとかやっていけてます。

経費で受けさせてもらった基本情報や業務を通じて視野が広がったので、インフラや低レイヤよりなことに興味を持っています。

なぜデータベースなのか

アプリにはどうやってもデータベースがついてくるのですが、フィヨルドブートキャンプではER図を書いて正規化は学習して、標準SQLはなんとなく書ける状態だけれども実務に足るデータベースの知識もSQLの知識もなくて、自分の中でブラックボックス化していたことに危機感が湧きました。

Railsでもモデルを書けば大体ActiveRecord経由でデータベースにデータを永続化させるわけで、データベースはだいたい使うんですよね。

ただ、抽象化されて気にしなくて良い風になっているだけ。アプリケーションの一部としてデータベースが存在するのでこれは知らなきゃいかんな、となりました。

Rails 8.0のSolidもモチベーションに

ついで程度ですが、Rails8.0でデータベースを使った機能が追加されたこともモチベーションになりました。

Solidってやつですね。データベースをインメモリDBのように使用することでアプリが依存するミドルウェアを減らして実装をシンプルにしてくれます。

TechRachoさんの記事にリポジトリの和訳が掲載されてますので、ご存じない方はぜひこの機会にどうぞ。

techracho.bpsinc.jp

私がSolidを知ったときに「Solidの嬉しいポイント」というのがいまいちピンと来なかったんですよ。で、結構調べてようやく掴めてくるという。そういうのはあまり良くないなと思ったのも学ぶきっかけでした。

データベースの学習って難しい

SQLを学んで、ER図とか正規化がつかめるようになるのがフィヨルドブートキャンプのカリキュラムでした。あとはさらっとPostgreSQLにふれるプラクティスがあったくらいかな。

いまならFBCがこのプラクティスにしていた理由もわかる気がするんですが、データベースって奥が深い。さっきカリキュラムとして挙がっていたSQLやER図だけでなくて論理設計や物理設計みたいな話も分野としてあるし、PaaSを使っちゃえば実装をそんな知らなくても抽象化されたインターフェース越しにデータベースをいじることができる。

学ぶことが多くて、未経験者には沼、RDBMS自体に種類があって教材が分散してしまっているので学習するのは難しい領域だと思います。

私も職場で相談したときには「まずは標準SQLから入ってみては」とアドバイスもらって、それ系の技術書を何冊か読んだ段階でカンファレンスを迎えました。

PostgreSQL Conference Japan 2024

ようやくカンファレンスの話に入ります。先に書いてしまいますが、SQLから学習初めてPostgreSQLのキャッチアップができていなかったので話は1/3もわからなかったのが正直なところ。とはいえ、なんとかまとめてみます。

午前中はキーノートとしてAWSに所属されているコミッタの方が講演されていました。AWSの話は控えめ。 お二方とも業務としてPostgreSQLにコミットされてるとのことでした。

ちなみに、キーノートは動画で公開されてます。

www.youtube.com

【K1】PostgreSQL 17とPostgreSQL開発最前線

キーノート第一弾はコミッターの澤田さんによるものでした。

PostgreSQL17での機能追加とちょっとだけPostgreSQL18にかかわる話がありました。

  • vacuumが性能向上してアップデート
  • 増分バックアップに対応。増分したバックアップファイルをあとから結合可能。
  • PostgreSQLコミュニティの取り組み

どこかで説明があったのですがVacuumはRubyでいうところのGCみたいなものということでイメージがつきました。

特にDBのパフォーマンスにあたってはメモリをどう活用するか、の話になる部分が大きいと思うのでこの性能向上はすごいな、と。DBの違いとか発展は全然知らなかったのでPostgreSQLの進歩すげーて感心してました。

【K2】AWS and the PostgreSQL community

澤田さんと同じく AWSPostgreSQL Commiter のミカエルさんの発表でした。

  • PostgreSQLのコミュニティ紹介の際にカンファレンスを開催したJapanメンバーに拍手するよう促していたのが印象的。PostgreSQLコミュニティの雰囲気を表していたと思った
  • PostgreSQLのコードベースが現在110万行ぐらい。年間3〜4万行増えているらしい。でかい。

どこかでPostgreSQLの機能追加はすべてコミッターのチェックの上で行われると聞いたことがあります。100万行のオーバーだと影響を考慮する範囲も広いし、大変ですね。

【T1】Explain EXPLAIN:EXPLAIN を使ったPostgreSQLのクエリ最適化の基本と実践

PostgreSQLのクエリ実行計画を読み取って最適化しよう、そのやり方を解説いただきました。 スライドはすでに公開中です。

speakerdeck.com

PostgreSQLがクエリを受け取って結果を返すまでの内部処理の解説があったんですが、別の講演でも同箇所の解説が出てきたのでかなり重要なポイントだと伝わりました。

EXPLAINで表示されるのがクエリの実行計画と呼ばれるやつで、この中にクエリがどのように実行するのか書いてある(インデックスをスキャンするのか、テーブルを丸ごとスキャンするのかなど)。なので、これを読み解くことでクエリ改善の糸口がわかる、ということになる。

プランナーが作成する実行計画は、インデックスの有無、統計情報の内容から、大体は効率を考慮して複数の実行計画から絞り込みが行われる。いい感じのインデックスと最新の統計情報を与えてあげてプランナーが最適な実行計画を立てるのを支援するのがいいんだと理解しました。

【T3】PostgreSQL でインデックスはどう使われるのか

検索を高速化させるインデックスの使い方を学びました。

  • 演算子族、演算子クラスの概念をここで知りました。演算子クラスがマッチしていることがインデックスが使われるかどうかの判定に使われています。
  • こちらの講演でもクエリのリクエストからクエリ結果をレスポンスするまでの内部処理が解説されてました。

【T4】基礎から学ぶ PostgreSQL のバックアップ ―基本機能と運用設計

ちょうどバックアップに限って若干調べたことがあったので非常に楽しみにしてました。

Theチュートリアルって感じに初心者フレンドリーな内容でとっても勉強になりました。 配布された冊子と講演に使われたスライドの内容がだいぶ違っていたので、スライドの公開を心から待っているところです。

その他

会場でPostgreSQLの参考書(電子書籍)買いました。影響受けやすいタイプです。