【入門編】トランザクション分離レベル – PostgreSQL

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

PostgreSQLを触り始めると必ずぶつかる壁の一つに「トランザクション分離レベル」というものがあります。名前からして難しそうですよね。初めてこれを見たとき、僕も「これ、一体何の役に立つの？」と頭を抱えた記憶があります。

でも、安心してください。実はこれ、「カフェでの注文と、店員さんのメモ」に例えると、ものすごくスッキリ理解できるんです。一緒に紐解いていきましょう。

—

データベースにおけるトランザクションとは、一言でいえば「一連のまとまった仕事」のことです。

例えば、あなたが銀行のアプリで友達に1,000円送金するとします。「あなたの残高を1,000円減らす」ことと「友達の残高を1,000円増やす」という2つの処理がセットで完了しないと困りますよね？片方だけ成功してもう片方が失敗したら、お金がどこかに消えてしまいます。

この「セットで完璧にやり遂げる」ことを保証するのがトランザクションです。

—

さて、ここからが本題です。もし、あなたと別の誰かが同時に同じデータにアクセスしようとしたらどうなるでしょう？

データベースは「効率」を取るか「正確さ」を取るかで、常にバランスを調整しています。その調整加減を決めるのが「分離レベル」です。これを間違えると、カフェで例えるならこんなトラブルが起きます。

「一番人気の、ごく普通のカフェスタイル」

これはPostgreSQLのデフォルト設定です。
店員さんが注文を取る際、「今、確定しているメニューだけを読み取る」というルールです。

防げる現象：ダーティリード（未確定データの読み取り）
隣の席の人が「やっぱりこれキャンセルで！」と言いかけている途中の注文を、店員さんが「あ、新メニューかな？」と勘違いしてメモすることはありません。「確定した注文だけ」を信じるので安心です。

「自分専用の注文表をキープするスタイル」

これを選ぶと、店員さんは「あなたが座った瞬間のメニュー表」をずっとあなた専用としてキープしてくれます。

防げる現象：非再現読み取り（同じものを二度読み直すと結果が変わる現象）
普通のカフェだと、途中でメニューが書き換わると「あ、さっきのパンケーキ売り切れました！」と言われるかもしれません。でも、このレベルなら「座ったときにあったメニュー」が保証されるので、二度見しても結果が変わらず、心が乱されることがありません。

「貸切個室で、完全に一人だけの世界」

これが最も厳格な設定です。データベース全体を一人ずつ順番に処理しているかのように振る舞います。

防げる現象：ファントムリード（幻影の読み取り）
例えば、「今の注文一覧を数えて」と頼んだとき、他の人が横から新しい注文を追加しても、あなたの計算には一切影響しません。「私が見たとき、注文は5つでした！」という結果が完全に守られます。
ただし、全員が厳格すぎるルールを守ると、お店の回転率が極端に落ちます。データベースも同じで、このモードは非常に安全ですが、同時にたくさんの処理をすると少し動きが重くなるのが弱点です。

—

初心者の方へ僕からのアドバイスは、「まずはデフォルトの『Read Committed』で十分！」ということです。

ほとんどのWebサービスは、PostgreSQLの標準設定である「Read Committed」で問題なく動くように作られています。「もっと厳密にデータを守りたい！」という特定の場面が出てきたとき、初めて「Repeatable Read」や「Serializable」を検討すれば大丈夫ですよ。

最初は名前の響きに圧倒されるかもしれませんが、要は「データベースというお店の、接客ルールの違い」だと捉えてみてください。

もし、実際にコードを書いていて「あれ？今このデータ、どう見えているんだろう？」と迷ったら、いつでもこの記事を読み返してくださいね。データベースとの付き合い、一緒に楽しんでいきましょう！