Snapshot isolation
出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2025/04/16 06:08 UTC 版)
Snapshot isolation（SI、スナップショット アイソレーション）は、データベース管理システムのトランザクション処理において並行動作時のデータの一貫性を保証するためのトランザクションの分離レベルの一種で、次の性質を持つ。
- トランザクションは一貫性のあるデータベースのスナップショット(トランザクション開始時に存在していた最後にコミットされた値)を読む。
- トランザクションの更新がスナップショット以降に他のトランザクションがコミットした更新と競合しない場合に限りトランザクションが成功する。
Snapshot isolation はSQL Anywhere, InterBase, Firebird, Oracle, PostgreSQL, MongoDB, Microsoft SQL Server (2005以降) などの主なデータベース管理システムで採用されている。それはこの分離レベルがSerializable isolationよりも良い性能が実現でき、かつ多くの並列性からくる異常 (anomalies) を回避することができるためである (すべてが回避できるわけではない)。実際にはsnapshot isolationはデータの世代を管理するMultiVersion Concurrency Control (MVCC) の一種として実装される。MVCC は、データベース中のオブジェクトが更新されるたびに新しいバージョンを作成し、並行して実行されているトランザクションのリード操作が他の操作をブロックしないようにすることで、並列性と性能をともに向上させるよく知られた方法である。Snapshot isolation は ANSI SQL-92標準が規定する分離レベルを批判する論文で使用された (snapshot isolation は SQL-92標準が規定する "異常" を一切持たないにもかかわらず、serializable ではない)。
Oracle は snapshot isolation のことを "serializable" と呼んでいる[1][2][3]。
PostgreSQL は以前は snapshot isolation のことを "serializable" と呼んでいたが、version 9.1 から "repeatable read" と呼ぶよう変更した[4][5][6]。
どちらの判断が正しいかは議論があるが、いずれにせよユーザは両者の違いをよく理解してデータ一貫性を失わないように注意する必要がある。
動作
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つの預金口座の残高であったとする。銀行はこの顧客の預金残高が合計して負にならなければ、一方の残高が負になることを許しているとする (すなわち 
- Snapshot isolationのページへのリンク
