スナップショット分離

データベースおよびトランザクション処理(トランザクション管理)において、スナップショット分離は、トランザクションで行われたすべての読み取りでデータベースの一貫したスナップショットが参照されること (実際には開始時に存在していた最後のコミットされた値が読み取られる) を保証します。また、トランザクション自体は、そのスナップショット以降に行われた同時更新と競合する更新がない場合にのみ、正常にコミットされます。

スナップショット分離は、 InterBase、Firebird、Oracle、MySQL、^[1] PostgreSQL、SQL Anywhere、MongoDB ^[2]、Microsoft SQL Server（2005以降）など、いくつかの主要なデータベース管理システムで採用されています。これが採用されている主な理由は、直列化可能性よりも優れたパフォーマンスを実現しながら、直列化可能性では回避できる並行性の異常のほとんど（すべてではない）を回避できるためです。実際には、スナップショット分離は、各データ項目（バージョン）の世代値が維持される多版型同時実行制御（MVCC）内で実装されています。MVCCは、オブジェクトが書き込まれるたびにデータベースオブジェクトの新しいバージョンを生成し、トランザクションによる（各オブジェクトの）いくつかの最新の関連バージョンの読み取り操作を許可することにより、並行性とパフォーマンスを向上させる一般的な方法です。スナップショット分離は、^{SQL標準が禁止している「異常」をまったく示さないにもかかわらず、シリアル化できない（ANSIで定義された異常のない分離レベル）ため、} ANSI SQL -92標準の分離レベルの定義を批判するために使用されてきました[3]。

シリアル化可能性とは異なるにもかかわらず、スナップショット分離はOracle によって シリアル化可能と呼ばれることがあります。

スナップショット分離で実行されるトランザクションは、トランザクションの開始時に取得されたデータベースの個人用スナップショットに対して操作を行うように見えます。トランザクションが終了すると、トランザクションによって更新された値がスナップショット取得以降に外部的に変更されていない場合にのみ、トランザクションは正常にコミットされます。このような書き込み-書き込み競合により、トランザクションは中止されます。

書き込みスキュー異常では、2 つのトランザクション (T1 と T2) が重複するデータ セット (値 V1 と V2 など) を同時に読み取り、同時に別々の更新 (T1 が V1 を更新し、T2 が V2 を更新) を行い、最後に同時にコミットしますが、どちらも他方が実行した更新を認識していません。システムがシリアル化可能であれば、T1 または T2 のいずれかが「最初に」発生し、他方から見える必要があるため、このような異常は不可能になります。対照的に、スナップショット分離では書き込みスキュー異常が許可されます。

具体的な例として、V1 と V2 が Phil という 1 人の人物によって保持されている 2 つの残高であるとします。銀行は、両方の合計がマイナスにならない限り (つまり、V1 + V2 ≥ 0)、V1 または V2 のいずれかが赤字になることを許可します。両方の残高は現在 100 ドルです。Phil は 2 つのトランザクションを同時に開始し、T1 は V1 から 200 ドルを引き出し、T2 は V2 から 200 ドルを引き出しました。

データベースがシリアル化可能なトランザクションを保証している場合、T1 をコーディングする最も簡単な方法は、V1 から $200 を差し引いてから、V1 + V2 ≥ 0 がまだ維持されていることを確認し、維持されていない場合は中止することです。T2 は同様に V2 から $200 を差し引いてから、V1 + V2 ≥ 0 を確認します。トランザクションはシリアル化する必要があるため、T1 が最初に発生して V1 = −$100、V2 = $100 となり、T2 が成功しないようにするか (V1 + (V2 − $200) が −$200 になるため)、T2 が最初に発生して同様に T1 がコミットしないようにします。

ただし、データベースがスナップショット分離 (MVCC) の下にある場合、T1 と T2 はデータベースのプライベート スナップショットに対して操作を行います。それぞれがアカウントから 200 ドルを差し引いてから、スナップショットが取得されたときに保持されていた他のアカウント値を使用して、新しい合計がゼロであることを確認します。どちらの更新も競合しないため、両方とも正常にコミットされ、V1 = V2 = −$100、V1 + V2 = −$200 になります。

マルチバージョン同時実行制御(MVCC)を使用して構築された一部のシステムでは、同時操作を気にすることなくトランザクションを続行できるように、また、さらに重要なことに、トランザクションが最終的にコミットされるときにすべての読み取り操作を再検証する必要がないように、スナップショット分離 (のみ) がサポートされる場合があります。これは、MVCC が一連の最近の履歴の一貫性のある状態を維持するため便利です。トランザクション中に格納する必要がある情報は、行われた更新のリストのみで、コミット前に競合を簡単にスキャンできます。ただし、MVCC システム (MarkLogic など) では、パフォーマンスの向上の一部を実現しながら、より強力な「シリアル化可能性」レベルの分離をサポートするために、MVCC とともにロックを使用して書き込みをシリアル化します。

書き込みスキューの異常から生じる潜在的な不整合の問題は、直列化可能性を強制するためにトランザクションに（そうでなければ不必要な）更新を追加することで修正できます。^{[4] [5] [6] [7]}

対立を具体化する

直接的な書き込み-書き込み競合を作成するために、両方のトランザクションが更新する特別な競合テーブルを追加します。

プロモーション

直接的な書き込み-書き込み競合を作成するために、1 つのトランザクションで読み取り専用の場所を「更新」 (値を同じ値に置き換える) します (または、同等のプロモーション (Oracle の SELECT FOR UPDATE など) を使用します)。

上記の例では、新しいテーブルを追加して、隠れた制約を明示的にし、各人をその合計残高にマッピングすることで、競合を具体化できます。フィルは合計残高 200 ドルから開始し、各トランザクションはここから 200 ドルを減算しようとします。これにより、書き込みと書き込みの競合が発生し、2 つが同時に成功できなくなります。ただし、このアプローチは正規形 に違反しています。

あるいは、トランザクションの読み取りの 1 つを書き込みに昇格させることもできます。たとえば、T2 は V1 = V1 を設定すると、T1 との人工的な書き込み-書き込み競合が発生し、再び 2 つの同時実行が妨げられます。この解決策は常に可能であるとは限りません。

したがって、一般的に、スナップショット分離では、重要な制約を維持するという問題の一部がユーザーに課せられますが、ユーザーは潜在的な落とし穴や可能な解決策を理解していない可能性があります。この移行の利点は、パフォーマンスが向上することです。

スナップショット分離は、Oracle ^{[8] [9] [10]}およびPostgreSQLバージョン9.1より前のバージョン^{[11] [12] [13]}では「シリアライズ可能」モードと呼ばれており、「実際のシリアライズ可能性」モードと混同される可能性があります。この決定には賛否両論がありますが、明らかなのは、データベースシステムロジックで望ましくない異常な動作が発生するのを避けるために、ユーザーはその違いを認識しておく必要があるということです。

スナップショット分離は、データベースの複数のバージョンが同時に維持され、読み取り側が書き込み側と衝突することなく実行できるようにする、マルチバージョン同時実行制御データベースの研究から生まれました。このようなシステムでは、そのような分離レベルの自然な定義と実装が可能です。 ^[3]後に Borlandが所有したInterBase は、バージョン 4 で完全なシリアル化ではなく SI を提供することが認められており、^[3] 1985 年の最初のリリース以来、書き込みスキューの異常を許容していた可能性があります。^[14]

残念ながら、ANSI SQL-92標準はロックベースのデータベースを念頭に置いて書かれたため、MVCC システムに適用するとかなり曖昧になります。Berensonらは1995 年に SQL 標準を批判する論文^{[3]を書き、ANSI SQL-92 標準で説明されている標準的な異常を示さない分離レベルの例としてスナップショット分離を挙げましたが、}シリアル化可能なトランザクションと比較すると、依然として異常な動作がありました。

2008 年、Cahillらは、同時トランザクションの「危険な」トリプレットを検出して中止することで、書き込みスキューの異常を防止できることを示しました。^{[15]この直列化可能性の実装は、}マルチバージョン同時実行制御データベース に適しており、PostgreSQL 9.1 で採用されています。^{[12] [13] [16]} では、直列化可能スナップショット分離 (SSI) と呼ばれています。これを一貫して使用すると、上記の回避策は不要になります。スナップショット分離の欠点は、中止されたトランザクションが増えることです。これは、ワークロードに応じて、上記の回避策を使用したスナップショット分離よりもパフォーマンスが良くなったり悪くなったりする可能性があります。

• Bettina Kemme、Gustavo Alonso、「Eager データベース レプリケーション プロトコルの開発と実装に対する新しいアプローチ」、ACM Transactions on Database Systems (TODS)、v.25 n.3、p. 333-379、2000 年 9 月。
• ゲルハルト・ヴァイクム、ゴットフリート・フォッセン、「トランザクション情報システム：同時実行制御と回復の理論、アルゴリズム、実践」、モーガン・カウフマン、2002年、ISBN 1-55860-508-8 
• Yi Lin、Bettina Kemme、Marta Patiño-Martínez、Ricardo Jiménez-Peris。スナップショット分離を提供するミドルウェア ベースのデータ レプリケーション。2005 ACM SIGMOD 国際会議の議事録、2005 年。
• Marta Patiño-Martinez、Ricardo Jiménez-Peris、Bettina Kemme、Gustavo Alonso。MIDDLE-R: ミドルウェア レベルでの一貫性のあるデータベース レプリケーション。ACM Transactions on Computer Systems (TOCS)。第 23 巻第 4 号。375 ～ 423 ページ。
• Khuzaima Daudjee、Kenneth Salem、「スナップショット分離による遅延データベースレプリケーション」、VLDB 2006: 715-726 ページ