【入門編】ロックマネージャのアーキテクチャ – PostgreSQL

こんにちは！データベースの世界へようこそ。

PostgreSQLを触っていると、「ロック」という言葉を耳にする機会が増えますよね。「誰かがデータを使っているときは、他の人は待っててね」という、いわば順番待ちのルールです。

でも、このロック、裏側では一体どんな仕組みで動いているのでしょうか？今日は、PostgreSQLの「ロックマネージャ」という、いわば「図書館の受付カウンター」のような仕組みについて、一緒に覗いてみましょう。

—

例えば、皆さんが大勢で一つのExcelファイルを編集しているところを想像してみてください。Aさんが名前を書き換えている途中で、Bさんが同じセルを別の名前に書き換えたら……もう大変ですよね。データがめちゃくちゃになってしまいます。

PostgreSQLも同じです。「今、私がこのデータをいじってるから、終わるまで誰も触らないで！」と宣言して、他の人が手を出さないようにする。これがロックの役割です。

PostgreSQLのメモリの中には、「ロックテーブル」という巨大な掲示板のような場所があります。

誰かがデータにアクセスしようとすると、まずはこの掲示板に「今、テーブルAのこの行を借りてます！」と名前を書きます。他の人が来たら、受付係（ロックマネージャ）がこの掲示板を見て、「あ、今Aさんが使ってるから、ちょっと待っててね」と判断するわけです。

この掲示板は、PostgreSQLのプロセス全員が見られる「共有メモリ」という場所に置かれています。みんなが同じ掲示板を見ているからこそ、秩序が保たれているんですね。

さて、ここからが面白いところです。PostgreSQLのロックには、大きく分けて2つのタイプがあるんです。役割分担が絶妙なんですよ。

これは、「メモリの中のデータを読み書きする際の、ほんの一瞬のガード」です。
例えば、掲示板に名前を書いているそのコンマ数秒の間、他の人に覗かれたり書き換えられたりしたら困りますよね。その「一瞬だけ鍵をかける」のがLWLockです。

例えるなら： 公衆トイレの「使用中」の札。中に入ってカチッと鍵をかける、あの動作です。ほんの一瞬で終わるし、誰が使っているかという細かい管理はあまりしません。とにかく「今、中は触らないで！」という合図です。

こちらは、ユーザーがSQLを実行している間ずっと維持されるような、少し重ためのロックです。

例えるなら： 図書館の貸し出し手続き。カウンターで名前を書き、カードをもらい、自分が返却するまでその本は自分専用になる。そんな風に、データの整合性をしっかり守るための、管理コストが少し高いロックです。

—

もし、すべてを「重量級ロック」で管理したらどうなるでしょう。
「ちょっとデータを確認するだけ」なのに、いちいち図書館のカードを作らなきゃいけないようなもので、データベースは一瞬で激重になってしまいます。

逆に、すべてが「LWLock」だったら、誰がどのデータをどれくらい使っているのか分からなくなり、データの整合性が崩れてしまいます。

だからこそ、「一瞬の操作は素早く済ませる（LWLock）」ことと、「業務全体の整合性はしっかり守る（重量級ロック）」という、この2段構えの仕組みが、PostgreSQLの速さと信頼性を支えているんです。

—

ロックと聞くと「邪魔をするもの」「ボトルネックになるもの」という悪いイメージを持たれがちかもしれません。でも、実はロックこそが、「私たちの大切なデータを壊さないように守ってくれる、データベースの優しさ」なんですよ。

次にPostgreSQLが少し待たされたときは、「ああ、今ロックマネージャが一生懸命、データの整合性を守ってくれているんだな」と、少しだけ温かい目で見てあげてくださいね。

皆さんのデータベースライフが、今日も快適でありますように！