👱

データベースをデータの箱としか思っていなかった私の『内部構造から学ぶPostgreSQL』を読んだ感想

2024/06/25に公開

自己紹介

MICINでエンジニアインターンをしています、永井です。社内ではMiROHAというプロダクトのチームにお世話になっています。
今回、社内の勉強会で内部構造から学ぶPostgreSQLを読みましたので、感想をまとめて参ります。

MICIN社員のsugaiさんとまじまっちょさんの振り返り記事もあるので、あわせてお読みいただきたいです。

本書を読む前

データベースについては、データを入れる箱という認識と、トランザクション分離レベルの用語を少しだけ知っている状態でした。

読書会の進め方について

私たちの読書会では、事前に1週間ごとに決められた章を読み、その内容についてわかったこと、わからなかったこと、感想をメモにまとめました。
当日はメモを元にひとりひとり感想を述べ、ディスカッションをしました。

読む上で意識をしたこと

本書に書かれている機能とクラウドサービスの機能を照らし合わせつつ、感想を述べることです。

低レイヤーに詳しくない私にとっては、本書の内容はレベルが高く、読むだけでは十分な感想が出てこないことがありました。

そのため、とあるユースケースにおいて内部ではどのような動作になるかを理解しなければ、必要な場面で本書で学んだ内容を生かすことができないと思います。

上記のことを踏まえて、どの機能がどのようなユースケースで活用されているかを踏まえて感想を述べるように注力しました。

以下は、12章の感想を述べる回で私が記述したものを一部抜粋したものです。

わかったこと

特に興味を持ったポイント

長時間のトランザクションのデメリットが多いと感じた

本書を読むまでは、長時間トランザクションはレスポンスを遅滞させてユーザー体験が悪くなるだけだと思っていました。
加えて以下の様な弊害があり

  • VACUUMの対象外である
  • 論理レプリケーション時にはメモリが溢れるおそれがある(PostgreSQL13まで)
  • I/O処理の量が増加する

など新たな気づきでした。

データベースの監視項目について

さまざまな統計データを取得できます。コミットやデッドロックの回数などは想像していましたが、インデックススキャンやシーケンシャルスキャンの回数まで取得できることは初耳でした。
同時に、自分で監視項目を設定しようと思った際に、どのようなメトリクスが必要なのか疑問が湧きました。
Datadogに推奨のメトリクスがあったので、こちらを参照することで必要な監視項目がわかりました。

どのようなアプリケーションと相性が良いか

更新や削除の処理が多いアプリケーションには不向きだと思います。なぜなら、アーキテクチャが追記型だからです。UPDATEや削除を行うと、物理的なデータの更新や削除をするのではなく、代わりにxidと削除フラグが付与されます。使用されなくなったデータを持続することにより、ディスク使用量が増加します。使用されなくなったデータを破棄するためにVACUUMという処理が走りますが、上記の処理が頻繁に実行されると、常にI/O処理の負荷が高い状態になります。そのため、更新や削除などが起こらないようなイミュータブルなデータベース設計においては、相性が良いと考えます。

感想

本書を読んで

改めてですが、PostgreSQLは奥が深いと感じました。パフォーマンスやCPUの使用率の改善のため、VACUUMやVisibility Mapといった私たちの見えないところで動いている仕組みがあることを認識しました。

Amazon RDSなどのクラウドサービスの固有の機能との区別ができるようになりました。また、クラウドサービスが幅広く手の届かない部分(論理レプリケーションやバージョンアップの実行手順の簡素化)を提供していることを理解できました。

読書会の感想

私が質問をした際には、言葉足らずの部分を補ってくれる方もいて、発言がしやすい環境だと感じました。そのおかげで、自分の疑問点や感想などを述べやすかったです。

各チームの雰囲気やプロダクトの理解にもつながりました。MICINでは、複数のプロダクトでPostgreSQLが採用されています。そのため、各チームでの課題や活用事例などを聞くことができ、参画しはじめて日が浅い私にとって、会社の理解につながるよい機会でした。

GitHubで編集を提案
株式会社MICIN

Discussion