主に論文 "Weak Consistency: A Generalized Theory and Optimistic Implementations for Distributed Transactions" の紹介。 https://pmg.csail.mit.edu/pubs/adya99__weak_consis-abstract.html

1. Isolation Level について
星野 喬
1

2. 概要
• 用語整理
• Serializability, Isolation, Consistency…
• ＳＱＬ標準の Isolation Level
• Adya の整理
2

3. Serializabilty
• 日本語では「直列化可能性」
• トランザクション達を直列に実行したのと等価と見做せること
• View 等価 (意味論 Herbrand semantics でも等価)
• Conflict 等価 (扱いやすくするため View 等価より制約が強い)
• Linearizability (線形化可能性) とは異なる概念なので注意
• Linearizability は新しいデータを読める性質(トランザクション抽象ナシ)
• Operation 1 個しか含まないトランザクションの集合という仮定の元で、
Linearizable = Strict serializable
3

4. Consistency という言葉の混乱
• (1) ACID の C(consistency)
• DBMS がアプリケーションに提供するデータベース状態制約機能
• (2) 並列分散界隈の Consistency
• 新しいデータを読めるか(or 一貫性のあるデータを読めるか)
• (3) Adya1999 の Consistency
• Isolation とあまり区別してないが Realtime 性の話が若干入ってそう
• 広い意味では Isolation も含め Consistency と呼びたい(by 星野)
• アプリケーションがデータとその振る舞いに求める不変条件を満たすことが
ゴール
• しばしば暗黙的 (例: Sequential consistency でないとバグるアルゴリズム)
4

5. Isolation Level とは
• Serializability が欲しいけど、性能とのトレードオフがある
• みんな大好き Snapshot Isolation、Read Committed、Repeatable Read…
• Serializability の保証がなくても足りることもある
• アプリケーション側が DBMS に歩み寄る必要もしばしばある
(Select に For update をつけるとか、排他用の Record を用意するなど)
• Level (段階) 感がある
• SQL標準規格では本当に Level として規定されている
• 当時は Level とか Degree などの言葉で表現されていた by Adya
5

6. SQL標準規格
• ANSI X3.135-1992, American National Standard for
Information Systems – Database Language – SQL, 1992
• いわゆる SQL92
• 最新は SQL:2019 (たぶん)
• Isolation 周りは変わってないと思われる
• 「現象」(or 振舞い)を元にした Informal な定義 by Adya
• 2 通りの解釈: Anomaly 解釈と Preventative 解釈
6

7. SQL標準における「現象」の分類
• Anomaly 解釈は問題があるので Preventative 解釈が前提 by Adya
• P0: 𝑡1 と 𝑡2 が 𝑥 を Concurrent に Write (どちらの結果を残すか不明)
• P1: 𝑡1 の書いた 𝑥 を 𝑡1 commit 前に read し、𝑡1 が abort する (𝑡2 は commit 不可能)
• P2: 𝑡1 が読んだ 𝑥 を 𝑡1 が commit する前に上書きする (𝑡1 は 𝑡2 の書いたものを読むべき)
• P3: 𝑡1 が predicate read して 𝑡1 が commit する前に predicate read の結果が変わるような書
き込みをする (𝑡1 は 𝑡2 の変更を反映した predicate read 結果を観測すべき)
7

8. SQL 標準の Isolation Level
• SQL 標準は Lock による CC (Concurrency control) 設計にべったり
• SQL 標準の Serializable を(ここでは) ANSI-Serializable と呼ぶ
8

9. Bere1995
• A Critique of ANSI SQL Isolation Levels
• H. Berenson, et al., 1995, SIGMOD Conference
• ANSI-Serializable は Serializable じゃないよ
• Snapshot isolation (SI) は ANSI-Serializable だけど Serializable じゃないよ
• SI では Write skew anomaly が発生するよ
• (後の論文で、SI では read-only transaction anomaly もあると判明)
• (Anomaly 解釈は正しくない、と言ったのもこの論文 by Adya)
9

10. Adya1999
• Weak Consistency: A Generalized Theory and Optimistic
Implementations for Distributed Transactions
• Atul Adya, 1999, Doctor Thesis
• モチベーション
• SQL標準の Isolation Level 勘弁してくれ
• 貢献
• より良い Isolation 分類(のためのモデル)の提案
• 注意点
• Adya は MVCC や OCC を統一的に扱うため Version order を基準にして
Conflict を定義するが、ここでは素直に (Write) operation order を用いる
10

11. Adya1999 が指摘する SQL 標準の問題点
• 定義が曖昧である
• (Anomaly 解釈は間違っているので Preventative 解釈を使うべき
by Bare1995)
• Lock 前提の枠組みなので、汎用的ではない
• (Preventative 解釈だと) 制限的すぎて、最近の CC protocol (OCC とか MVCC)
が同等の Isolation level において通すスケジュールが規格では違反扱いとなっ
てしまう
• CC 設計や実装依存だけでなく、永続化に関する余計な性質が混ざっている
(要確認)
11

12. Isolation 関係図 by Adya
• PL-1
• PL-2
• PL-2.99 (Repeatable Read)
• PL-3 (Full Serializability)
• PL-2+ (Consistent View)
• PL-SI (Snapshot Isolation)
• 他
12
Figure 4.1 A partial order to relate various isolation levels.

13. Adya1999 の分類 (一部)
• モデルを用いて明確に、G0, G1, G2 他の禁止する現象を定義
13

14. Adya1999 のモデル
• 従来の Page model (for mono-version)
• 複数のオペレーション (Op) から成るトランザクション (Tx) が複数
• Op は主に read/write
• Op order が与えられる
(Tx の Concurrent 実行を Op order における Interleaving で表現)
• Standard version function (Op order における直前の値を読む) が前提
• Adya は従来の Page model を拡張
• Conflict-based アプローチ
• いわゆる w-r、w-w、r-w 関係でグラフ構造を作って Acyclic かどうか
• Op order の代わりに Multi-version 向けの Version order を使用
• だから従来の Conflict serializability での定義とは若干異なる
• Phantom も扱うため Predicate read/write が Op として入ってる
14

15. Conflict of Adya1999
• Directly read-dependency
• reads-from 関係のこと (直前の write と read の関係、狭義の w-r)
• Directly write-dependency
• 連続する write と write の関係 (狭義の w-w)
• Directly anti-dependency
• read と、それを直接上書きする write の関係 (狭義の r-w)
• Directly conflict := Directly read/write/anti dependency
• Dependency := Transitive read/write dependency
• Conflict := Transitive conflict
• Predicate 絡みのものも含まれるが複雑なので省略
• Adya1999 では Version order の「直前」だが、簡単のため Op order を使用
15

16. DSG (Direct Serialization Graph)
• Direct conflict 関係から構築した Graph 構造
• DSG = (V, E) where
• V: Transactions
• (t1, t2) in E: t2 directly depends on t1
• (Transitive) conflict は Path
16

17. Condition G0
• G0: Write Cycles
• Write dependency のみで構成される DSG の Cycles
• PL-1: G0 を禁止
• 所感
• Mono-version 前提なら分かる
• Multi-version だとそもそも Version order だけで Order になってないとい
う状況に対応するのでモデルに含める意味を感じない
17

18. Condition G1
• G1a: Aborted Reads
• 𝑤1 𝑥 𝑟2 𝑥 … 𝑎1𝑐2
• G1b: Intermediate Reads
• 𝑤1 𝑥1𝑎 𝑟2 𝑥1𝑎 𝑤1 𝑥1𝑏 … 𝑐2
• G1c: Circular Information Flow
• Dependency のみで構成された DSG の Cycles (G0 を含む)
• PL-2: G1 (= G1a+G1b+G1c) を禁止
• 所感
• G1a は永続化要件だと思う(から CC は関係ない派)
• G1b は two-step model では発生しないから CC 設計の詳細に見える
18

19. Condition G2
• G2: Anti-dependency Cycles
• ひとつ以上の Anti-dependency を含む Cycles
• PL-2.99: G1 と G2-item (predicate 除く) 禁止
• PL-3: G1 と G2 禁止
19

20. まとめと感想
• SQL標準の Isolation Level には種々の問題があった
• Adya1999 は明確なモデルでそれを整理
• 当時実用されていた Snapshot Isolation をちゃんと含めたことは大きい
• (この資料では説明してないけど)
• 2022年から見て
• Predicate を組込むのは筋悪だと感じるし、Adya の整理は分かりにくい
(層を分けても良いのでは)
• もう Mono-version のモデルから議論を始めるのをやめましょうよ
20