【入門編】スナップショット分離レベルの実装 – PostgreSQL

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

今日は、PostgreSQLの心臓部といっても過言ではない「スナップショット分離」という、ちょっと難しそうなテーマについてお話ししますね。

「分離レベル？スナップショット？なんか専門用語ばかりで頭が痛くなりそう……」なんて思いましたか？大丈夫です！難しい技術用語は一旦横に置いて、私たちの身の回りの「あるある」から紐解いていきましょう。

—

想像してみてください。あなたは今、ランチタイムに同僚数人と「今日のランチ、何にする？」と相談しています。

これは、「誰かが注文を確定した瞬間に、その情報が全員に共有される」という状態です。

あなたがメニューを見ている間に、隣の同僚が「私はハンバーグにする！」と言ったとします。すると、その瞬間からあなたの視界にも「ハンバーグは売り切れ（注文済み）」という情報が入ってきますよね。

PostgreSQLのRead Committedもこれと同じです。SQL文を実行するたびに、その瞬間に最新の「確定したデータ」を確認しに行きます。シンプルですが、同じトランザクションの中で何度も確認すると、途中で状況が変わってしまう可能性があるのが特徴です。

次に、「ランチの注文を始めたら、その時のメニュー表をずっと手元に置いておく」スタイルです。

注文の途中で隣の席の人が「やっぱりパスタに変える！」と言っても、あなたは最初に手渡されたメニュー表しか見ません。つまり、あなたが「注文を始めたその瞬間」に撮ったスナップショット（記憶）を最後まで使い続けるわけです。

これがRepeatable Readです。一貫性が欲しいときに非常に便利ですが、「後から変更があったことに気づけない」という側面もあります。

これはもっと厳格です。「全員がそれぞれ別の個室でランチを食べている」ような状態です。

他の人が何を注文しようが、誰が店を出ようが、あなたには一切影響がありません。もし、誰かの注文があなたの注文と競合しそうになったら、データベースが「ごめんなさい、ちょっと整理させて！」と介入して、どちらかをやり直させます。

Serializableは、もっとも安全ですが、その分データベースにはかなりの負荷がかかります。まさに「絶対に間違いが許されない」ときのための最終兵器ですね。

—

PostgreSQLがすごいのは、これらの仕組みを「物理的なロック（扉に鍵をかけること）」を最小限に抑えて実現している点です。

多くのデータベースは、データを読み書きする際に「他の人は触らないで！」と鍵をかけてしまいますが、PostgreSQLは「スナップショット（写真）」を撮ることで、鍵をかけずに「過去のデータ」を見せ続けているんです。

おかげで、誰かが重たいデータの集計をしていても、他の人はスイスイと自分の作業を続けられる。この「優しさ」こそが、PostgreSQLが長年愛され続けている理由なんですよ。

—

こうして見てみると、データベースがやっていることって、私たちの日常のコミュニケーションとよく似ていませんか？

どれが優れているというわけではなく、「何のためにそのデータを見るのか」によって使い分けるのがコツです。

最初はピンと来なくても大丈夫。こうして少しずつ、データの裏側に流れる「考え方」に触れていけば、いつの間にかデータベースと仲良くなれているはずですよ。

また何か気になることがあれば、いつでも聞きに来てくださいね。それでは、また次回の記事でお会いしましょう！