Snapshot isolation

Snapshot isolation の下で実行されるトランザクションは、そのトランザクションの開始時に撮ったスナップショットの上で動作しているように見える。トランザクションが終了すると、そのトランザクションによって行われた更新が、スナップショットを撮った後で発生した他のトランザクションによる更新と衝突しない場合に限って、コミットが成功する。ライト対ライト (write vs write) の衝突が発生すると、トランザクションはアボートする。

ライトスキュー異常 (write skew anomaly) は、2つのトランザクション (T1 と T2) が同時並行的に重複したデータ集合 (V1 と V2 の両方) を読み、それぞれが異なる更新を行い (T1 が V1 を更新し、T2 が V2 を更新)、最後にコミットを行った時に発生する。その際、T1とT2は互いの更新を知ることはないまま、snapshot isolation のシステムではコミットは成功してしまう。しかし serializable isolation のシステムにおいては、T1 と T2 のどちらかが先に実行されたとみなすことができなければならない (一方の更新は他方から見えなければならない) ので、これらはゆるされない。

例えば、V1とV2はある一人の銀行顧客の2つの預金口座の残高であったとする。銀行はこの顧客の預金残高が合計して負にならなければ、一方の残高が負になることを許しているとする (すなわち ${\displaystyle V1+V2\geq 0}$)。 始め、両方の残高はともに10,000円であったとする。T1 が V1 から 20,000円引き出し、T2 が V2 から 20,000円引き出したらどうなるだろう。

もし、データベースが serializable isolation で動作しているとすると、T1 と T2 をその順序(または逆の順序で)実行するのと等価な結果になるので、T1 は V1 から 20,000円の引き出しに成功し(その時点では ${\displaystyle V1+V2\geq 0}$が成り立つから)、次に T2 が V2 から 20,000円引き出そうとするが、今度は ${\displaystyle V1+V2\geq 0}$ が成り立たず、T2 は失敗する。

しかし snapshot isolation においては、T1 と T2 はそれぞれ独自のスナップショットの上で動作するので、両方共がそれぞれ 20,000円を引き出し、合計残高 (${\displaystyle V1+V2}$) が 0円であることを確認し、両者は衝突することなく共に成功してしまう。その結果 ${\displaystyle V1=V2=-10,000}$円、合計残高 ${\displaystyle V1+V2=-20,000}$円 となる。

Snapshot isolation が MVCC を用いて実装された場合、トランザクションは並行して行われている操作を心配することなく処理を進めることができ、コミットする際にリード操作を再検証する必要ない。トランザクション実行中に保持しなければならない情報は、更新のリストだけであり、コミット時にはそれを用いて衝突の有無を簡単に確認することができる (衝突が発生していた場合はトランザクションをアボートさせる)。

• Serializability
• MVCC
• 時刻印ロック
• リード・コピー・アップデート

1. ↑ Oracle Database Concepts 10g Release 1 (10.1) Chapter 13 : Data Concurrency and Consistency — Oracle Isolation Levels
2. ↑ Ask Tom : On Transaction Isolation Levels
3. ↑ Ask Tom : "Serializable Transaction"
4. ↑ PostgreSQL 9.0 Documentation: 13.2.2.1. Serializable Isolation versus True Serializability
5. ↑ PostgreSQL 9.1 press release
6. ↑ PostgreSQL 9.1.14 Documentation: 13.2.3. Serializable Isolation Level