PostgreSQLのMVCCスナップショット、知ってる？これ、データベースの「時間旅行」を可能にする魔法なんだぜ！
やあ、みんな！今日は PostgreSQL のちょっと奥深い、でも知っておくと「なるほど！」って膝を打つような話をしようと思う。テーマは MVCCスナップショット だ。
「MVCC…？」って思った君、大丈夫。最初はみんなそうだから。でも、これ、君たちが普段使ってる PostgreSQL の裏側で、めちゃくちゃ重要な役割を果たしてるんだ。例えるなら、データベースが「あの時の状態」を覚えててくれる、タイムマシンのようなものなんだぜ。
そもそもMVCCって何だっけ？
まず、MVCC（Multi-Version Concurrency Control）って言葉から少しだけ触れておこう。これは PostgreSQL が複数のユーザーからの同時アクセスを、お互いの邪魔をせずにスムーズに処理するための仕組みなんだ。
君たちが `SELECT` 文を投げると、同時に他の誰かが `UPDATE` や `DELETE` をしてるかもしれない。普通なら、「おっと、今データが書き換わってるから待って！」ってなるはずだろ？ でも MVCC があると、君の `SELECT` は、君がクエリを実行した「その時点」のデータを見ることができる。書き換わってる最中のデータに邪魔されることなくね。
じゃあ、どうやってそれを実現してるのか？ ここで登場するのが、今日の主役、MVCCスナップショット の出番ってわけだ。
MVCCスナップショット：データベースの「時間」を固定する
MVCCスナップショット、簡単に言うと、「あるトランザクションが開始された瞬間の、データベース全体の「見え方」を記録したもの」 だ。
イメージしてみてくれ。君が「よし、このデータを使って集計するぞ！」ってトランザクションを開始したとする。その瞬間、PostgreSQL は君のトランザクションのために「スナップショット」を作るんだ。このスナップショットには、「このトランザクションからは、どのデータが見えて、どれが見えないか」という情報が詰まってる。
つまり、君のトランザクションが実行されている間、たとえ他の誰かがデータを更新したり削除したりしても、君のトランザクションには関係ない。君は常に、トランザクション開始時点での「静止画」を見ていることになるんだ。これが、データの一貫性を保ちつつ、高い同時実行性を実現する MVCC の心臓部ってわけさ。
なんでこれが実務で大事なの？
「ふーん、裏側でそんなことやってるんだ」で終わらせるのはもったいない！ この MVCC スナップショットの仕組みを理解していると、実務で遭遇する色々な問題の根本原因が見えてくるんだ。
- なぜ `VACUUM` が必要なのか？
君たちが `UPDATE` や `DELETE` を実行すると、PostgreSQL はすぐにデータを物理的に削除するわけじゃない。古いバージョンのデータ（「ゴースト」と呼ばれる）を残しておくんだ。これは、他のトランザクションがその古いデータを参照しているかもしれないから。
MVCC スナップショットは、どのバージョンのデータが「まだ有効」で、どのバージョンのデータが「もう不要」なのかを判断するのに使われる。
`VACUUM` は、こうした不要になった古いデータ（ゴースト）を物理的に削除して、テーブルやインデックスをクリーンアップする作業なんだ。これがちゃんと行われないと、ディスク容量を圧迫したり、クエリのパフォーマンスが落ちたりする原因になる。スナップショットの仕組みを知っていると、なぜ `VACUUM` が「メンテナンス」として重要なのかが、より深く理解できるだろ？
- トランザクションの分離レベルと挙動
PostgreSQL には、トランザクションが他のトランザクションの変更をどれだけ「見る」か、という「分離レベル」を設定できる。例えば `READ COMMITTED` や `REPEATABLE READ` といったやつだ。
これらの分離レベルの挙動は、まさに MVCC スナップショットの振る舞いによって決まる。
- `READ COMMITTED` では、各ステートメントごとに新しいスナップショットが取られる。だから、同じトランザクション内でも、ステートメントごとに見えるデータが変わることがある。
- `REPEATABLE READ` では、トランザクション開始時に一度だけスナップショットが取られ、トランザクション中は常にそのスナップショットが見える。だから、同じトランザクション内では、何度 `SELECT` しても同じ結果が返ってくる。
- デッドロックの理解
MVCC のおかげで、読み取りと書き込みでデッドロックが発生することは稀なんだけど、それでも書き込み同士でデッドロックは起こりうる。その原因を追うときも、トランザクションがどのスナップショットを見ているのか、という視点が役立つことがある。
具体的な例を見てみよう
ちょっと具体的なシナリオで考えてみよう。
テーブル: `products`
データ:
| id | name | price |
| :– | :—— | :—- |
| 1 | Apple | 100 |
| 2 | Banana | 200 |
シナリオ:
1. トランザクション A が開始される。この時、PostgreSQL はスナップショット S_A を作成する。
2. トランザクション B が開始される。この時、PostgreSQL はスナップショット S_B を作成する。
3. トランザクション B が `UPDATE` を実行する。
BEGIN;
UPDATE products SET price = 250 WHERE id = 2;
— ここでトランザクションBはコミットしたとする
COMMIT;
この `UPDATE` により、`id = 2` の Banana の price が 200 から 250 に変更される。ただし、古いバージョン（price 200）も、他のトランザクションのために残される。
4. トランザクション A が `SELECT` を実行する。
SELECT FROM products WHERE id = 2;
結果はどうなる？
トランザクション A は、スナップショット S_A を参照する。S_A は、トランザクション A が開始された時点のデータベースの状態を反映している。この時点では、Banana の price は 200 だった。
だから、トランザクション A の `SELECT` 文は、`id = 2, name = Banana, price = 200` という結果を返すんだ！
トランザクション B が行なった `UPDATE` は、トランザクション A のスナップショット S_A には「見えない」んだ。まるで、トランザクション B がまだ `UPDATE` を実行していないかのように見える。これが MVCC の力さ。
コードで見る「見え方」の違い（概念的な説明）
実際の PostgreSQL の内部構造はもっと複雑だけど、概念的に、各行（Row）がどのような「バージョン」を持っているか、そしてスナップショットがそれをどう参照するかをイメージしてみよう。
ある行が、更新されるたびに新しいバージョンが作られ、それぞれに `xmin` (生成したトランザクションID) と `xmax` (削除したトランザクションID、もしあれば) といった情報が付与される。
— 実際にはこんな風には見えないけど、イメージだよ！
— product ID = 2 の行のバージョン履歴（例）
— バージョン 1 (初期状態)
{ id: 2, name: ‘Banana’, price: 200, xmin: 0, xmax: 0 } — xmin=0 は初期ロードとか
— バージョン 2 (トランザクションBがUPDATEした結果)
{ id: 2, name: ‘Banana’, price: 250, xmin: [ID of Tx B], xmax: 0 }
— バージョン 3 (もしTx BがDELETEしたら…)
— { id: 2, name: ‘Banana’, price: 250, xmin: [ID of Tx B], xmax: [ID of Tx B] }
トランザクション A が開始したとき、PostgreSQL はそのトランザクションの `xmin` (ここでは仮に `TxA_ID` とする) と、現在アクティブな他のトランザクションの `xmax` を考慮して、どのバージョンの行が見えるかを判断する。
可視性判定のルール（超簡略化）:
あるトランザクション `T` (スナップショット snapshot_T) が、ある行のバージョン `V` を見れるのは、以下の条件を満たす場合。
1. `V.xmin` が `T` より前のトランザクションによって生成されていること。
2. `V.xmax` が `0` であるか、または `V.xmax` が `T` より後のトランザクションによって生成されていること。
（つまり、そのバージョンが `T` よりも前に生成され、かつ `T` よりも後に削除されていないこと）
トランザクション A (snapshot_A) の目には、バージョン 1 の `product` (Banana) が「見える」ことになる。なぜなら、バージョン 2 はトランザクション B によって生成され、トランザクション B の `xmin` は snapshot_A には「見えない」（まだコミットしていないか、あるいは snapshot_A より後で開始したトランザクションだから）。
まとめ： MVCCスナップショットは PostgreSQL の「賢さ」の源泉
MVCC スナップショットは、PostgreSQL が「読み取り」と「書き込み」を同時に、しかもデータの一貫性を保ちながら処理できる秘密なんだ。
- トランザクション開始時の DB の状態を固定する。
- 各トランザクションは、自分専用の「静止画」を見ている。
- 他のトランザクションの変更に邪魔されない。
- `VACUUM` の必要性や、トランザクション分離レベルの挙動を理解する上で不可欠な概念。
この MVCC スナップショットの仕組みを理解することで、君たちが普段使っている PostgreSQL が、いかに賢く、そしてパワフルに動いているのか、その一端を垣間見ることができるはずだ。
もし、パフォーマンスチューニングで悩んだり、謎のロック待機に遭遇したりしたときは、この MVCC スナップショットの存在を思い出してみてほしい。きっと、問題解決の糸口が見つかるはずだから。
また、実践的な話で、君たちの役に立つ情報を発信していくぜ！何か質問があれば、いつでも気軽に聞いてくれよな！
コメント