データベース論 トランザクション・分散データベース編
DESCRIPTION
データベース論 トランザクション・分散データベース編. 森下 真一 平成14年度 夏学期. トランザクション管理. 参考文献 Jeffrey D. Ullman: Principles of Database and Knowledge-base Systems Volume I, Computer Science Press, 1988. ISBN 0-7167-8158-1 Chapter 9 Transaction Management. トランザクション データの読み出しや書き込みからなる処理の単位 並列に実行される. トランザクション管理の重要性. - PowerPoint PPT PresentationTRANSCRIPT
Transaction Management / Distributed Database Management
データベース論
トランザクション・分散データベース編
森下 真一
平成14年度 夏学期
Transaction Management / Distributed Database Management
トランザクション管理
参考文献
Jeffrey D. Ullman: Principles of Database and Knowledge-base SystemsVolume I, Computer Science Press, 1988. ISBN 0-7167-8158-1
Chapter 9 Transaction Management
Transaction Management / Distributed Database Management
トランザクション管理の重要性
更新が必要なデータベース座席予約システムダブルブッキングの回避高速な処理時間よりもデータ更新の安全性を確保したい
読み出すことが中心のデータベース統計データベースWWW データベース並列な読み出し要求を数多く処理したい
トランザクション
データの読み出しや書き込みからなる処理の単位並列に実行される
Transaction Management / Distributed Database Management
例題 普通預金口座 A
T2: 1000 円を引き出すトランザクション
READ A;A := A - 1000;WRITE A;
T1: 1000 円を振り込むトランザクション
READ A;A := A + 1000;WRITE A;
A4000
T1: READ AT2: READ AT1: WRITE A 5000T2: WRITE A 3000
スケジュール: 時間軸に沿ってステートメントを並べた列
A4000
T1: READ AT1: WRITE A 5000T2: READ AT2: WRITE A 4000
順番に実行するスケジュール
Transaction Management / Distributed Database Management
例題普通預金口座 A, B
T2: B から A へ5000円送金
READ A;A := A + 5000;WRITE A;
READ B;IF B >= 5000 B := B - 5000;WRITE B;
T1: A から B へ2000円送金
READ A;IF A >= 2000 A := A - 2000;WRITE A;
READ B;B := B + 2000;WRITE B;
A B4000 4000
T1 2000T1 6000T2 7000T2 1000
A B4000 4000
T2 9000T1 7000T1 6000T2 1000
A B4000 4000
T2 9000T1 7000T2 abort
T2 の影響を元に戻す必要あり
実行スケジュール例
Transaction Management / Distributed Database Management
トランザクションの原子性( Atomicity )の保証
整列スケジュールでは各トランザクションを原子のような塊として実行する。
原子性を保証するとは、各トランザクションを並列に実行するとき、最終結果が、ある整列スケジュールの結果と一致することを保証すること。
A B4000 4000
T2 9000T1 7000T2 abortT2 復帰 7000-5000
=2000T1 6000
例A B4000 4000
T1 2000T1 6000
整列スケジュール
Transaction Management / Distributed Database Management
Lock
Transaction Management / Distributed Database Management
データベースの更新単位をアイテム、アイテムの大きさを粒度( granularity )と呼ぶ
アイテムへのアクセスはロックにより管理排他的なロックのかかっているアイテムには他のトランザクションのアクセスを禁止
アイテムの粒度が大きい場合、ロック管理システムの負担は軽くなるが、同時に実行できるトランザクション数は減る
粒度の選択は典型的トランザクションを考えてきめる預金口座のように小さい単位でトランザクションが実行される場合は粒度は小さくする
Transaction Management / Distributed Database Management
ロックは様々な種類があるが当面は一種類とし、アイテム A に対するロックを LOCK A と記述
• A がロックされている間は他のトランザクションは A にアクセスできない
トランザクション T
アイテム A
ロックマネージャー
• トランザクション T はアイテム A に READ/WRITE する前に LOCK A をロックマネージャーに要求
LOCK A要求
• ロックマネージャーはアイテム A にロックがかかっていない場合に T が LOCK A することを許可
許可
• T は A に対する処理を終了したら、ロックマネージャーに UNLOCK A を要求し、ロックマネージャーはアイテム A に対するロックを解除
UNLOCK A
Transaction Management / Distributed Database Management例題 普通預金口座 A
T2: 1000 円を引き出すトランザクション
LOCK A;READ A;A := A - 1000;WRITE A;UNLOCK A;
T1: 1000 円を振り込むトランザクション
LOCK A;READ A;A := A + 1000;WRITE A;UNLOCK A;
A4000
T1: LOCK AT1: READ AT2: READ A
A4000
T1: LOCK AT1: READ AT1: WRITE A 5000T1: UNLOCK A
T2: LOCK AT2: READ AT2: WRITE A 4000T2: UNLOCK A
A4000
T2: LOCK AT2: READ AT2: WRITE A 3000T2: UNLOCK A
T1: LOCK AT1: READ AT1: WRITE A 4000T1: UNLOCK A
Transaction Management / Distributed Database Management
各トランザクションは一つのアイテムに高々一回だけ LOCK をかける
TLOCK A;A := A+1;UNLOCK A;LOCK B;LOCK A;B := B+A;UNLOCK A;UNLOCK B;
TLOCK A;A := A+1;LOCK B;B := B+A;UNLOCK A;UNLOCK B;
Transaction Management / Distributed Database Management
Livelock
トランザクション Ti
LOCK A;READ A;A := A + i ;WRITE A;UNLOCK A;
T1 が最初に A をロック
T2, T3 が LOCK A を要求
T1 が UNLOCK A
ロックマネージャーがT3にロックを許可
T4 が LOCK A を要求
T3が UNLOCK A
ロックマネージャーがT4 にロックを許可T2 に順番が回らない Livelock
簡単な回避方法 (First-come-first-served strategy)LOCK A を要求するトランザクションに要求順にロックを許可
Transaction Management / Distributed Database Management
Deadlock
T2: B から A へ5000円送金
LOCK B;LOCK A;
READ A;A := A + 5000;WRITE B;READ B;IF B >= 5000 B := B - 5000;WRITE B;
UNLOCK B;UNLOCK A;
T1: A から B へ2000円送金
LOCK A;LOCK B;
READ A;IF A >= 2000 A := A - 2000;WRITE A;READ B;B := B + 2000;WRITE B;
UNLOCK A;UNLOCK B;
T1: LOCK A; 許可T2: LOCK B; 許可
T1: LOCK B; 不許可T2: LOCK A; 不許可
T1 と T2 は永遠に待ちつづける
Transaction Management / Distributed Database Management
プロトコルを工夫して Deadlock を起こさない手法1
各トランザクションは同時にすべてのロック要求を出すロックマネージャーは、この全要求を許可するか、全てを不許可
T2: B から A へ5000円送金
LOCK B;LOCK A;READ A;A := A + 5000;WRITE B;READ B;IF B >= 5000 B := B - 5000;WRITE B;UNLOCK B;UNLOCK A;
T1: A から B へ2000円送金
LOCK A;LOCK B;READ A;IF A >= 2000 A := A - 2000;WRITE A;READ B;B := B + 2000;WRITE B;UNLOCK A;UNLOCK B;
T1: LOCK A 許可T1: LOCK B 許可
T1: UNLOCK AT1: UNLOCK B
T2: LOCK B 許可T2: LOCK A 許可
Transaction Management / Distributed Database Management
• アイテムに順序を導入
• 各トランザクションは 順序の大きい順に アイテムをロック
T2: B から A へ5000円送金
LOCK B;LOCK A;:
T1: A から B へ2000円送金
LOCK A;LOCK B;:
A > B
T2: B から A へ5000円送金
LOCK A;LOCK B;:
T1 の実行後に T2 が処理される
プロトコルを工夫して Deadlock を起こさない手法2
Transaction Management / Distributed Database Management
アイテムに順序を入れる方法が Deadlock を起こさない理由
観察: 各トランザクション Ti は他のトランザクション Ti+1 がロックしているアイテム Ai の開放を待っている
前処理: アイテムをロックしていないトランザクションを除いても、集合は依然として Deadlock 状態
Ti Ti+1Ai
注意Ti は Ai より順序の大きいアイテムをロック
背理法: Deadlock 状態のトランザクション集合があると仮定
Ti
LOCK Ai
Ti+1
LOCK Ai
LOCK Ai+1
Ti+2
LOCK Ai+1
LOCK Ai+2Ai > Ai+1 Ai+1 > Ai+2
Transaction Management / Distributed Database Management
ある T1 を選択して、鎖を構成
T1 T2A1
T3A2
A1 > A2 Tn は , いつか An-1 をUNLOCK. アイテムをロックしていない Tn が必ず存在し、矛盾
ループしない有限の下降鎖
TnAn-1
>…… . > An-1
Ti
LOCK Ai
Ti+1
LOCK Ai
LOCK Ai+1
Ti+2
LOCK Ai+1
LOCK Ai+2Ai > Ai+1 Ai+1 > Ai+2
Transaction Management / Distributed Database Management
スケジューラーが Deadlock を検知して abort 等で対処する方法
Waits-for Graph T2: B から A へ5000円送金
LOCK B;LOCK A;:UNLOCK B;UNLOCK A;
T1: A から B へ2000円送金
LOCK A;LOCK B;:UNLOCK A;UNLOCK B;
T1: LOCK A; 許可T2: LOCK B; 許可
トランザクションがノード
T1 T2A
B
T1 がロックしているアイテム Aの UNLOCK を T2 が待っているとき、「 T1 の次は T2」を表現するため T1 から T2 へ有向辺を引きA をラベルとしてつける
閉路の存在は Deadlockを意味する
Transaction Management / Distributed Database Management
整列化可能性(Serializability)
Transaction Management / Distributed Database Management
トランザクションの集合をある順序で整列化した列をT1 T2 …… Tk
i=1,2,…,k の順番で Ti のステートメントを実行するスケジュールを整列スケジュール (serial schedule) と呼ぶ
トランザクションをプログラムしたときのユーザの心境は各トランザクションの実行を他のトランザクションが邪魔しないことを仮定している
つまりトランザクション全体がある整列スケジュールとして実行されることを思ってプログラムする
Transaction Management / Distributed Database Management
しかしシステムは効率を重視してトランザクションの順番を入れ替えて実行するかもしれない
入れ替えをしても、その実行結果はある整列スケジュールの実行結果と一致してほしい
スケジュールが整列化可能とは、実行結果がある整列スケジュールの実行結果と一致することと定義する
この概念をどのように定式化するか?
Transaction Management / Distributed Database Management
T2: B の x 倍をA へ振り込む
LOCK B;READ B;UNLOCK B;LOCK A;READ A;A := A+B* x;WRITE A; UNLOCK A;
T1: A の x 倍をB へ振り込む
LOCK A;LOCK B;READ A;READ B;B := B+A* x;WRITE B; UNLOCK A;UNLOCK B;
T2: LOCK B;T2: READ B;T2: UNLOCK B;
T1: LOCK A; LOCK B;T1: READ A; READ B;T1: B := B+A * x; WRITE B; T1: UNLOCK A; UNLOCK B;
T2: LOCK A;T2: READ A;T2: A := A+B * x;T2: WRITE A; T2: UNLOCK A;
T1 B:=B+A*xT2 A:=A+B*x
T2 A:=A+B*xT1 B:=B+A*x
整列スケジュール
A=B=1000 x=2
T2: B=1000
T2: A=3000T1: B=3000
T1: B=3000T2: A=7000
T2: A=3000T1: B=7000
A=0B=1000 x=2
T1: B=1000T2: A=2000
T2: A=2000T1: B=5000
T2: B=1000
T2: A=2000T1: B=1000
整列化不可能
整列化可能?
Transaction Management / Distributed Database Management
スケジュール S1 が整列化可能とは、ある整列スケジュール S2 が存在して任意の初期状態に対して、S1 と S2 の 実行結果が一致することと定義した場合:
初期状態の候補は無限にあり、有限ステップでチェックできるか?
帰納的関数がある場合、2つの帰納的関数の等価性は一般に決定不能
スケジュール S1 が整列化可能とは、ある整列スケジュール S2 が存在して任意の初期状態に対して、LOCK と UNLOCK以外は任意をステートメントを許す場合にS1 と S2 の 実行結果が一致することと定義する
Transaction Management / Distributed Database Management
T2: B の x 倍をA へ振り込む
LOCK B;READ B;UNLOCK B;LOCK A;READ A;A := A+B* x;WRITE A; UNLOCK A;
T1: A の x 倍をB へ振り込む
LOCK A;LOCK B;READ A;READ B;B := B+A* x;WRITE B; UNLOCK A;UNLOCK B;
f1(A, B)g1(A, B) f2(A, B)
g2(B)
LOCK A と UNLOCK A のペアに対して新しい関数 f を割当てる
f の引数は UNLOCK A の前にトランザクション中でロックされる全てのアイテムの値
T2: LOCK B;T2: UNLOCK B; g2(B)
T1: LOCK A; T1: LOCK B;T1: UNLOCK A; f1(A,B)T1: UNLOCK B; g1(A,B)
T2: LOCK A;T2: UNLOCK A; f2(A,B)
A B
f2(f1(a,g2(b)), g1(f1(a, g2(b)), g2(b)))
g1(f1(a, g2(b)), g2(b))f1(a, g2(b))
g2(b)a b
Transaction Management / Distributed Database Management
T2: B の x 倍をA へ振り込む
LOCK B;READ B;UNLOCK B;LOCK A;READ A;A := A+B* x;WRITE A; UNLOCK A;
T1: A の x 倍をB へ振り込む
LOCK A;LOCK B;READ A;READ B;B := B+A* x;WRITE B; UNLOCK A;UNLOCK B;
f1(A, B)g1(A, B) f2(A, B)
g2(B)
T1: LOCK A;T1: LOCK B;T1: UNLOCK A;T1: UNLOCK B;T2: LOCK B;T2: UNLOCK B;T2: LOCK A;T2: UNLOCK A;
A Ba b
f1(a,b)g1(f1(a,b), b)
g2(g1(f1(a,b), b))
f2(f1(a,b), g2(g1(f1(a,b), b)))
整列スケジュール1
Transaction Management / Distributed Database Management
T2: B の x 倍をA へ振り込む
LOCK B;READ B;UNLOCK B;LOCK A;READ A;A := A+B* x;WRITE A; UNLOCK A;
T1: A の x 倍をB へ振り込む
LOCK A;LOCK B;READ A;READ B;B := B+A* x;WRITE B; UNLOCK A;UNLOCK B;
f1(A, B)g1(A, B) f2(A, B)
g2(B)
T2: LOCK B;T2: UNLOCK B;T2: LOCK A;T2: UNLOCK A;T1: LOCK A;T1: LOCK B;T1: UNLOCK A;T1: UNLOCK B;
A Ba b
g2(b)
f2(a, g2(b))
f1(f2(a,g2(b)), g2(b))g1( f1(f2(a,g2(b))), g2(b))
整列スケジュール2
Transaction Management / Distributed Database Management
3つのスケジュールの最終結果
A B
f2(f1(a,g2(b)), g1(f1(a, g2(b)), g2(b)) g1(f1(a, g2(b)), g2(b)))
整列スケジュール1 f2(f1(a,b), g2(g1(f1(a,b), b)) g2(g1(f1(a,b), b)))
整列スケジュール2 f1(f2(a,g2(b)), g2(b)) g1( f1(f2(a,g2(b))), g2(b))
記号列として異なる場合、最終結果が異なるように初期状態とステートメントをつくれる
記号列は UNLOCK の実行履歴を表現している
Transaction Management / Distributed Database Management
整列化可能性を判定するアルゴリズム
Transaction Management / Distributed Database Management
スケジュールの整列化可能性を判定するアルゴリズム
スケジュールは T: LOCK A または T: UNLOCK Aの形をしたステートメントの列 a1, a2, …, an とする
整列化可能性判定グラフの構成各 a i =T p: UNLOCK Am について aj = Tq: LOCK Am (p≠q) となる j > i が存在する場合、最小の j を選択し有向辺を張る
整列化可能な場合に対応する整列スケジュール中で T p は T q の前にある
定理 グラフに閉路がなければ整列化可能、あれば不可能
T p T q
Am
T p を始点とし Am をラベルにもつ有向辺は高々1つ
Transaction Management / Distributed Database Management
T2: LOCK AT2: UNLOCK A
T3: LOCK AT3: UNLOCK A
T1: LOCK BT1: UNLOCK B
T2: LOCK BT2: UNLOCK B
T3: LOCK BT3: UNLOCK B
T1
T2 T3
整列化可能性判定グラフ閉路がない場合
A
B
B
この関係は考慮しない
B
引かない
任意の始点から出る有向辺で同一ラベルをもつ辺は高々一つ
Transaction Management / Distributed Database Management
整列化可能性判定グラフ閉路がない場合
閉路のないグラフでは、同一アイテムをラベルにもつ有向辺は、連続した列をつくる
T3
T4
T5
T2
AT1T1: LOCK A
T1: UNLOCK A :T2: LOCK AT2: UNLOCK A
:T3: LOCK AT3: UNLOCK A :T4: LOCK AT4: UNLOCK A
:T5: LOCK AT5: UNLOCK A
与えられたスケジュール
Transaction Management / Distributed Database Management
一般には複数のアイテムに対する列が交差する
Transaction Management / Distributed Database Management
整列化可能性判定グラフ G の位相ソート
閉路がない場合にはGにはいかなる有向辺の終点でないノード v が存在する
存在しないと仮定すれば、あるノードから有向辺を逆に辿る列をつくると、ノード数が有限なので、いつかは自分に戻る閉路ができる
このステップを繰返し、除かれたノード(トランザクション)列T1 T2 …… Tk を位相ソート列と呼ぶ
v と v を始点とする有向辺を G から除く
位相ソート列を使って整列スケジュールを作る
Transaction Management / Distributed Database Management
位相ソート列 T1, T2, T3
T1: LOCK BT1: UNLOCK B
T2: LOCK AT2: UNLOCK AT2: LOCK BT2: UNLOCK B
T3: LOCK AT3: UNLOCK AT3: LOCK BT3: UNLOCK B
T2: LOCK AT2: UNLOCK A
T3: LOCK AT3: UNLOCK A
T1: LOCK BT1: UNLOCK B
T2: LOCK BT2: UNLOCK B
T3: LOCK BT3: UNLOCK B
与えられたスケジュール
T1
T2 T3
A
B
B
整列化可能性判定グラフ 整列スケジュール
Transaction Management / Distributed Database Management
整列化可能性判定グラフ閉路がない場合
T3
T4
T5
T2
AT1T1: LOCK A
T1: UNLOCK A :T2: LOCK AT2: UNLOCK A
:T3: LOCK AT3: UNLOCK A :T4: LOCK AT4: UNLOCK A
:T5: LOCK AT5: UNLOCK A
与えられたスケジュール
位相ソートから得られる整列スケジュール内でアイテム A に対するロックはT1, T2, T3, T4, T5の順序で起こる
Transaction Management / Distributed Database Management
定理前半 スケジュール S の整列化可能性判定グラフ G が閉路を含まない場合、位相ソートでつくった整列スケジュール R は S と等価
ノード N の深さ d(N)
N を終点とする有向辺の始点を N の隣接点
N M1
Mk
:
d(N) = 0 N に隣接点がない = max{ d(M) | M は隣接点 }+1
0 0 0
1 1
2 2 1
準備
Transaction Management / Distributed Database Management
スケジュール S と R で、同じトランザクションは同一のアイテムに関して同じ値を読むことを証明
深さに関する帰納法
深さ0のとき、各アイテムの値は初期状態だから、 OK
T 深さk
S, R で T がアイテム A をLOCK する直前に A を UNLOCKするトランザクションを T’とする
深さk未満
A
T’
帰納法の仮定で S と R は T’ で A に同一の値を読み込む
S と R は T でも A に同一の値を読み込む
Transaction Management / Distributed Database Management
T2: LOCK B;T2: UNLOCK B;
T1: LOCK A; T1: LOCK B;T1: UNLOCK A;T1: UNLOCK B;
T3: LOCK A;T3: UNLOCK A;
T2: LOCK AT2: UNLOCK A
T2
T1
整列化可能性判定グラフ閉路がある場合
B
T3
A
A
Transaction Management / Distributed Database Management
T1
T2
Tp-1
Tp
Tk
定理後半 スケジュール S の整列化可能性判定グラフが閉路を含む場合、 S は整列化不可能
Ti (i=1,…k)の中で Tp が R に最初に現れるとする
Tp-1: UNLOCK A g(…)
Tp: LOCK A:
Tp: UNLOCK A f(…)
仮に等価な整列スケジュール R があるとする
R では f(…) に g(…) は出現しない . S では出現 .
R と S は等価でないので矛盾
S
Tp: LOCK A:
Tp: UNLOCK A f(…)
R
Transaction Management / Distributed Database Management
T1
T2
Tp-1
Tp
Tk
Tp: LOCK A
Tp-1: LOCK BTp-1: UNLOCK B g(B)
Tp: LOCK B:
Tp: UNLOCK A f(A,B)
R では f(…) に g(…) は出現しない . S では出現 .
R と S は等価でないので矛盾
S
Tp: LOCK ATp: LOCK B
:Tp: UNLOCK A f(A,B)
R
もう一つ例
Transaction Management / Distributed Database Management
整列化可能性判定グラフ
T2: LOCK B;T2: UNLOCK B;
T1: LOCK A; T1: LOCK B;T1: UNLOCK A; g(…)T1: UNLOCK B;
T3: LOCK A; T3: UNLOCK A; f(…)
T2: LOCK AT2: UNLOCK A
T2
T1B
T3
A
A
整列スケジュール
T3: LOCK AT3: UNLOCK A f(…)
:
Transaction Management / Distributed Database Management
2相ロックプロトコル(Two-phase Locking Protocol)
Transaction Management / Distributed Database Management
2相ロックプロトコル
各トランザクションにおいて、すべての LOCK 文は、すべての UNLOCK 文の前に実行する
定理2相ロックプロトコルに従ってできたスケジュール S は、必ず整列化可能
Transaction Management / Distributed Database Management
2相ロックの正当性の証明
背理法
整列化不可能な場合、整列化可能性判定グラフには閉路あり
T1
T2
T3
T4
T1 の UNLOCK 後に T2 の LOCK
T2 の UNLOCK 後に T3 の LOCK
Tk の UNLOCK 後に T1 の LOCKT5
Tk:
T1 は UNLOCK後に LOCK しており2相ロックプロトコルに従うことに矛盾
Transaction Management / Distributed Database Management
2相ロックプロトコルの最適性条件は少しでも緩めると整列化可能性は失われる
T1 は2相ロックプロトコルに従わないとする
T1LOCK A :UNLOCK A :LOCK B :UNLOCK B :
T2LOCK ALOCK BUNLOCK AUNLOCK B
T1: LOCK A:
T1: UNLOCK A
T2: LOCK AT2: LOCK BT2: UNLOCK AT2: UNLOCK B
T1: LOCK B:
T1: UNLOCK B
T1
T2
A B
Transaction Management / Distributed Database Management
注意 2相ロックプロトコルでDeadlock を回避できるわけではない
T2: B から A へ5000円送金
LOCK B;LOCK A;
READ A;A := A + 5000;WRITE B;READ B;IF B >= 5000 B := B - 5000;WRITE B;
UNLOCK B;UNLOCK A;
T1: A から B へ2000円送金
LOCK A;LOCK B;
READ A;IF A >= 2000 A := A - 2000;WRITE A;READ B;B := B + 2000;WRITE B;
UNLOCK A;UNLOCK B;
T1: LOCK A; 許可T2: LOCK B; 許可
T1: LOCK B; 不許可T2: LOCK A; 不許可
T1 と T2 は永遠に待ちつづける
Transaction Management / Distributed Database Management
ここまでの まとめ
• 整列化可能性の概念を定義
• 整列化可能であることと 整列化可能性判定グラフが閉路を含まないことは同値
• 2相ロックプロトコルは整列化可能の十分条件
課題
• いろいろなLOCKに対して整列化可能性判定グラフの 技法をどこまで拡張して適用できるのか?
• 2相ロックプロトコルはどこまで有効か?
Transaction Management / Distributed Database Management
Read Only Lock / Write Lock を使うモデル
Transaction Management / Distributed Database Management
Read Lock (RLOCK と記述 )
• 読み込むだけのデータにかける鍵• 他のトランザクションが Write Lock してないデータにかけられる
Write Lock (WLOCK)
• 読み書きするデータにかける鍵• 他のトランザクションが Read Lockも Write Lock もしていないデータにかけられる
Read LockがかかっているデータにRead Lockは可能だが、 Write Lock は不可能
Write LockがかかっているデータにRead Lockも Write Lock も不可能
Transaction Management / Distributed Database Management
対応する整列スケジュールスケジュール
スケジュールの整列化可能性
T1 T2RLOCK A : RLOCK AUNLOCK A :
UNLOCK A
T1 T2RLOCK A :UNLOCK A
RLOCK A :UNLOCK A
T1 T2RLOCK A :UNLOCK A
RLOCK A :UNLOCK A
RLOCK 間の関係からトランザクションに順序を定義しなくても構わない点が違うだけ。他の場合は以前と同様。
Transaction Management / Distributed Database Management
RLOCK / WLOCK の場合の整列化可能性判定グラフ の構成
RLOCK A (or WLOCK A)
:UNLOCK A
Ti Tm
WLOCK A
Ti : UNLOCK A と Tm : WLOCK A の間で WLOCK A は出現しない
ケース1 Ti Tm
Transaction Management / Distributed Database Management
RLOCK A :
UNLOCK A
Ti
WLOCK A
Tm
RLOCK A :
UNLOCK A
Tj
WLOCK A :
UNLOCK A
Tk
Tm
Ti Tj Tk
Transaction Management / Distributed Database Management
Ti Tm
ケース2
RLOCK A
Tm
WLOCK A :UNLOCK A
Ti
Ti: UNLOCK A と各 RLOCK A の間で WLOCK A は出現しない
Tn
RLOCK A
Tn
Transaction Management / Distributed Database Management
WLOCK A を中心に考えるとわかりやすい
Tm: WLOCK A Tm
・・
複数の RLOCK A単一の WLOCK A
・・
複数の RLOCK A単一の WLOCK A
Transaction Management / Distributed Database Management
T1 T2 T3 T4
WLOCK ARLOCK B
UNLOCK ARLOCK A
UNLOCK BWLOCK B
RLOCK AUNLOCK B
WLOCK BUNLOCK A
UNLOCK AWLOCK A
UNLOCK BRLOCK B
UNLOCK AUNLOCK B
T3
T2T1
T4
Transaction Management / Distributed Database Management
T1 T2 T3 T4
WLOCK ARLOCK B
UNLOCK ARLOCK A
UNLOCK BWLOCK B
RLOCK AUNLOCK B
WLOCK BUNLOCK A
UNLOCK AWLOCK A
UNLOCK BRLOCK B
UNLOCK AUNLOCK B
T3
T2T1
T4
Transaction Management / Distributed Database Management
T1 T2 T3 T4
WLOCK ARLOCK B
UNLOCK ARLOCK A
UNLOCK BWLOCK B
RLOCK AUNLOCK B
WLOCK BUNLOCK A
UNLOCK AWLOCK A
UNLOCK BRLOCK B
UNLOCK AUNLOCK B
T3
T2T1
T4
Transaction Management / Distributed Database Management
T1 T2 T3 T4
WLOCK ARLOCK B
UNLOCK ARLOCK A
UNLOCK BWLOCK B
RLOCK AUNLOCK B
WLOCK BUNLOCK A
UNLOCK AWLOCK A
UNLOCK BRLOCK B
UNLOCK AUNLOCK B
T3
T2T1
T4 T3
T2T1
T4
Transaction Management / Distributed Database Management
T1 T2 T3 T4
WLOCK ARLOCK B
UNLOCK ARLOCK A
UNLOCK BWLOCK B
RLOCK AUNLOCK B
WLOCK BUNLOCK A
UNLOCK AWLOCK A
UNLOCK BRLOCK B
UNLOCK AUNLOCK B
T3
T2T1
T4 T3
T2T1
T4
Transaction Management / Distributed Database Management
定理
整列化可能性判定グラフが閉路をもてば、スケジュールは整列化不可能
閉路がないグラフであれば、位相ソートを使ってトランザクションを整列化し、等価な整列スケジュールを生成できる
証明は LOCK- UNLOCK の場合の考え方と同様
Transaction Management / Distributed Database Management
2相ロックプロトコル
トランザクションは、RLOCK と WLOCK 要求を全て実行した後に UNLOCK を行う
定理2相ロックプロトコルを使う場合、整列化可能性は保証される
証明は LOCK- UNLOCK の場合の考え方と同様
Transaction Management / Distributed Database Management
木構造をしたデータ・アイテムを
扱うプロトコル
Transaction Management / Distributed Database Management
木構造をしたデータ構造
• HTML, XML
• B-tree
• データベース 全体→各関係→ファイル→レコード
Transaction Management / Distributed Database Management
木プロコトル (tree protocol)
各トランザクションは以下の規則に
従ってアイテムをロックをかける .
1. アイテムをロックできるのは、
親アイテムをロックしているとき。
最初にロックするアイテムはこの条件を満たさなくてよい。また最初にロックするアイテムは根ノードである必要がなく、任意のアイテムを選択できる。
2. 1つのアイテムを複数回ロックしない。
A
B C
D E
F G
Transaction Management / Distributed Database Management
T1 T2 T3LOCK ALOCK BLOCK DUNLOCK B
LOCK BLOCK C
LOCK EUNLOCK D
LOCK FUNLOCK A
LOCK GUNLOCK C
UNLOCK ELOCK E
UNLOCK FUNLOCK B
UNLOCK GUNLOCK E
A
B C
D E
F G
Transaction Management / Distributed Database Management
T1 T2 T3LOCK ALOCK BLOCK DUNLOCK B
LOCK BLOCK C
LOCK EUNLOCK D
LOCK FUNLOCK A
LOCK GUNLOCK C
UNLOCK ELOCK E
UNLOCK FUNLOCK B
UNLOCK GUNLOCK E
A
B C
D E
F G
Transaction Management / Distributed Database Management
T1 T2 T3LOCK ALOCK BLOCK DUNLOCK B
LOCK BLOCK C
LOCK EUNLOCK D
LOCK FUNLOCK A
LOCK GUNLOCK C
UNLOCK ELOCK E
UNLOCK FUNLOCK B
UNLOCK GUNLOCK E
A
B C
D E
F G
Transaction Management / Distributed Database Management
T1 T2 T3LOCK ALOCK BLOCK DUNLOCK B
LOCK BLOCK C
LOCK EUNLOCK D
LOCK FUNLOCK A
LOCK GUNLOCK C
UNLOCK ELOCK E
UNLOCK FUNLOCK B
UNLOCK GUNLOCK E
A
B C
D E
F G
Transaction Management / Distributed Database Management
T1 T2 T3LOCK ALOCK BLOCK DUNLOCK B
LOCK BLOCK C
LOCK EUNLOCK D
LOCK FUNLOCK A
LOCK GUNLOCK C
UNLOCK ELOCK E
UNLOCK FUNLOCK B
UNLOCK GUNLOCK E
A
B C
D E
F G
Transaction Management / Distributed Database Management
T1 T2 T3LOCK ALOCK BLOCK DUNLOCK B
LOCK BLOCK C
LOCK EUNLOCK D
LOCK FUNLOCK A
LOCK GUNLOCK C
UNLOCK ELOCK E
UNLOCK FUNLOCK B
UNLOCK GUNLOCK E
A
B C
D E
F G
Transaction Management / Distributed Database Management
A
B C
D E
F G
A
B C
D E
F G
A
B C
D E
F G
A
B C
D E
F G
A
B C
D E
F G
A
B C
D E
F G
Transaction Management / Distributed Database Management
木プロトコルは2相ロックプロトコルではない
T1 T2LOCK ALOCK BLOCK DUNLOCK B
LOCK BLOCK C
しかし木プロトコルに従うスケジュールは整列化可能である
Abraham Silberschatz and Zvi Kedem: “Consistency in Hierachical Database Systems.” Journal of the ACM, Vol.27, No.1, Jan. 1980, pp.72-80.
Transaction Management / Distributed Database Management
証明の概略
トランザクション T が最初にロックするアイテムを FIRST(T)
2つのトランザクション Ta , Tb についてFIRST(Ta) FIRST(Tb) が先祖と子孫の関係にない場合:
Ta と Tb が共通のアイテムをロックすることはない
FIRST(Ta) FIRST(Tb )
Transaction Management / Distributed Database Management
補題 Ta と Tb が少なくとも 1つの共通するアイテムをロック。
共通するすべてのアイテムを先に Ta もしくは Tb がロック。
FIRST(Ta) FIRST(Tb) が先祖と子孫の関係にある場合
共通してロックするアイテムは木構造を成す
最も根ノードに近いノードを X とする
X を Ta が先にロックすると仮定
Transaction Management / Distributed Database Management
X
P
背理法: Tb が Ta より先にロックするアイテム Y が存在すると仮定
Z
Y
Ta が先
Tb が先
矛盾
• Ta はいつか Y をロック
• Tb もいつか X をロック
• ある Z と親ノード P で矛盾
Transaction Management / Distributed Database Management
(1) 根ノードをロックするトランザクションは整列化可能
(2) 各部分木のアイテムだけロックするトランザクションは整列化可能
(3) 補題より (1)の整列に (2) の整列を各々独立に融合することが可能
木プロトコルに従うスケジュールは整列化可能である
深さに関する帰納法 根ノードだけの場合
一般の場合
Transaction Management / Distributed Database Management
トランザクションの abort
COMMITMENT
Cascading Rollback
Transaction Management / Distributed Database Management
いままではトランザクションが必ず完了するケースを扱ってきた
• 個々のトランザクションが自ら abort するユーザの割り込み、0による割り算、権限のないアクセス
• スケジューラが deadlockを検知し ,abort で deadlock 回避
• 整列性を保証するためにトランザクションの abort を強制するプロトコルを使う場合
しかし現実には完了しないまま abort するケースが多い
• システムダウン
Transaction Management / Distributed Database Management
T1
LOCK AREAD AA := A-1WRITE ALOCK BUNLOCK AREAD BB := B/AWRITE BUNLOCK B
T2
LOCK AREAD AA := A+2WRITE AUNLOCK A
トランザクションの2つの計算状態
• 計算実行中 (active)• 計算完了 (completed) あとはアイテムに結果を書くだけ
計算実行中
計算完了
計算実行中
計算完了
Transaction Management / Distributed Database Management
計算の完了を宣言する文 COMMIT
T1
LOCK AREAD AA := A-1WRITE ALOCK BUNLOCK AREAD BB := B/A
COMMIT
WRITE BUNLOCK B
T2
LOCK AREAD AA := A+2
COMMIT
WRITE AUNLOCK A
Transaction Management / Distributed Database Management
T1 T2 A=1, B=1LOCK AREAD AA := A-1 A := 0WRITE ALOCK BUNLOCK A
LOCK AREAD AA := A+ 2 A := 2
READ BCOMMITWRITE AUNLOCK A
B := B/A B := 1/0COMMITWRITE BUNLOCK B
この時点で T1 のabort が発生
Cascading rollback(なだれ的な巻き戻し)
T1 が abort したので、 A の値を T1 の実行以前の状態に戻す必要がある
すると、ここでの更新も戻す必要がある
Transaction Management / Distributed Database Management
T1 T2 A=1, B=1LOCK AREAD AA := A-1 A:=0WRITE ALOCK BUNLOCK A
LOCK AREAD AA := A+ 2 A:=2
READ BCOMMITWRITE AUNLOCK A
B := B/A B := 1/0COMMITWRITE BUNLOCK B
Dirty Read
T2: READ A は T1 の計算が完了する以前( T1:COMMIT の前)に T1: WRITE A が書き出した値を読んでいる
T1 はその後 abort し、
T2 が読んだ A の値は無効になり cascading rollbackを生む
Transaction Management / Distributed Database Management
2つの課題
• Dirty Read の回避
• Cascading rollback の回避
COMMIT, WRITE の位置を工夫して解決
Transaction Management / Distributed Database Management
Dirty Read の回避 T1
LOCK AREAD AA := A-1WRITE ALOCK BUNLOCK AREAD BB := B/A
COMMIT
WRITE BUNLOCK B
COMMIT つまり計算の完了を宣言してからWRITE を実行する
T1
LOCK AREAD AA := A-1
LOCK B
READ BB := B/A
COMMIT
WRITE AUNLOCK AWRITE BUNLOCK B
Transaction Management / Distributed Database Management
T1LOCK AREAD AA := A-1LOCK BREAD BB := B/ACOMMITWRITE AUNLOCK A
LOCK AREAD AA := A+2COMMITWRITE AUNLOCK A
WRITE BUNLOCK B
T2
• T2:READ A は もはやDirty Read ではない(計算が完了 COMMIT したあとの WRITE A の値を読んでる)
• しかし、 T1: WRITE Bで abort すれば、Cascading Rollback が発生
Transaction Management / Distributed Database Management
T1 T2LOCK AREAD AA := A-1LOCK BREAD BB := B/ACOMMITWRITE AWRITE BUNLOCK AUNLOCK B
LOCK AREAD AA := A+2COMMITWRITE AUNLOCK A
Cascading Rollback の回避
すべての WRITE が完了するまで UNLOCK を実行しない
あるアイテムの値を読むとき、その値を書き出したトランザクションが abort することはない
Transaction Management / Distributed Database Management
強2相ロックプロトコル(strict two-phase locking protocol)
• WRITE の実行は COMMIT の後
• すべての WRITE が完了するまで UNLOCK を実行しない
Transaction Management / Distributed Database Management
障害発生時のデータベース修復
Transaction Management / Distributed Database Management
記憶媒体の信頼性
主記憶 揮発性記憶装置
電源障害時にデータが消えるsystem failure
二次ディスク 永続的記憶装置テープ
ヘッドクラッシュなど深刻な障害(media failure) の時以外はデータが残る
Transaction Management / Distributed Database Management
System failure 発生時のデータベース修復
修復に備えデータベース更新履歴をとるログ (log) ジャーナル (journal)
• トランザクション T の起動(T, begin)
• T がアイテム A の値が w のとき、値 v を書き込む(T, A, w, v)
• T がコミットしたとき(T, commit)
• T がアボートしたとき(T, abort)
Transaction Management / Distributed Database Management
再実行プロトコル (Redo Protocol)
ログを生成する強2相ロックプロトコル
トランザクション T が COMMIT 文に達したとき、以下の処理を実行
• トランザクション T が、値が w のアイテム A に値 v を書き出すとき、 T 内の順番に従って
(T, A, w, v)をログに書き込む。 ただし、 COMMIT 以前に A に対して w は計算された値であること。
• (T, commit) をログに書き込む
ログは新たな書き込みが起こるたびに二次記憶装置に書き込む
w
A
T
v
Transaction Management / Distributed Database Management
トランザクション T ログの内容A=10, B=20 のとき
LOCK A (T, begin)LOCK B
A := A+1 (T, A, 10, 11) B := B+1 (T, B, 20, 21)
COMMIT (T, commit)
WRITE AWRITE B
UNLOCK AUNLOCK B
ログにまず書きこむ
続いてデータベースに書きこむ
Transaction Management / Distributed Database Management
ログを使ったデータベース修復の手順
• 障害発生時に各トランザクションが握るロックは開放させる
• 各トランザクション に対して 最新の (T, commit) を見つける(T, begin)(T, A1, w1, v1)
: この順番で書き込みを再実行(T, An, wn, vn)(T, commit)
• トランザクション T について、 (T, commit) がない場合、強2相ロックプロトコルなので、 T の WRITE 文は実行されない
• (T, abort) がある場合、 T の更新履歴はすべて破棄する
Transaction Management / Distributed Database Management
トランザクション T ログの内容A=10, B=20
LOCK A (T, begin)LOCK B
A := A+1 (T, A, 10, 11) B := B+1 (T, B, 20, 21)
COMMIT (T, commit)
WRITE AWRITE B
UNLOCK AUNLOCK B
System Failure の際に値を戻す手順
計算も未完了でアイテムの値をWRITEしていないのでなにもしない
COMMIT直後以降は計算が完了しているので、A に 11 、 B に 21 を書き出す
既に正しい値である場合でも書く
Transaction Management / Distributed Database Management
トランザクション T ログの内容A=10, B=20
LOCK A (T, begin)LOCK B
A := A+1 (T, A, 10, 11) B := B+1 (T, B, 20, 21)
COMMIT (T, commit)
WRITE AWRITE BUNLOCK AUNLOCK B
Abort の場合、トランザクション実行前の状態に戻す
A=11 B=21
A=10 B=20
Transaction Management / Distributed Database Management
チェックポイント処理 (checkpointing)
主記憶にあるデータ更新の履歴を二次記憶装置へ書き込む操作
abort や system failure が発生してもチェックポイント実行前の状態に戻さない
そこで各トランザクションの COMMIT 以降の状態を保存する
• すべてのトランザクションの実行要求を禁止する• 実行中のトランザクションが abort するか、 もしくは 終了するまで待つ• 二次記憶への書き出しが済んでいない主記憶中のブロックを書き出す• ログの最後に checkpoint が済んだことを書きこむ
Transaction Management / Distributed Database Management
Media failure への対処
• system failure への対処方法は二次記憶の信頼性に完全に依存している
• ディスクヘッドが故障したり、子供が磁石でディスクをなでたり、天変地異がおこったりなど、 media failure に完全には対応できない
• 基本的には、定期的にバックアップをとる
• 更新の頻度は、夜間に一回から連続的まで様々
Transaction Management / Distributed Database Management
タイムスタンプ方式の並列実行制御
Transaction Management / Distributed Database Management
整列化可能性 (serializability) を LOCK により実現してきた
他に現実システムで使われている手法 : タイムスタンプ方式
• 各トランザクションは実行を開始するときスケジューラを呼ぶ
• スケジューラは実行開始時間をタイムスタンプとして与える
• 複数のトランザクションはタイムスタンプの順番で整列化する
• タイムスタンプ方式は積極的プロトコルの例で、不具合が生じた時点で abort 等により不整合を修復
• ロックを使ったスケジュールから導かれる整列化した順序とは必ずしも一致しない
Transaction Management / Distributed Database Management
T1 T2READ B
READ AWRITE C
WRITE C
タイムスタンプ方式
2 1T1 T2
READ BREAD AWRITE C
WRITE C
T2 → T1
ロック方式
WLOCK が読み書き両方のロックの場合
T1 T2 :
:WLOCK CWRITE CUNLOCK C
WLOCK CWRITE CUNLOCK C
T1 → T2
Transaction Management / Distributed Database Management
タイムスタンプの発行
• トランザクションの数をカウントし、次の番号をタイムスタンプとして与える
• 時計の時間を与える
Transaction Management / Distributed Database Management
タイムスタンプを使ったトランザクションの整列化
各アイテムごとに、 read time と write time を管理
• Read Time (RT) 現在をふくめ現在に最も近い時刻に アイテムを読み出したトランザクションのタイムスタンプ
• Write Time (WT) 現在をふくめ現在に最も近い時刻に アイテムを書き出したトランザクションのタイムスタンプ
Transaction Management / Distributed Database Management
T1 T2 A
タイムスタンプ 150 160 RT=0WT=0
READ A RT=150READ A RT=160
A:=A+1A:=A+1WRITE A WT=160
WRITE A WT=150 ??
対応する整列スケジュール T1 → T2
Transaction Management / Distributed Database Management
各アイテムに対する読み書き時間による整列化可能性チェック
• 未来に書き込まれるアイテムの値を、現在は読めない
t1 < t2 をタイムスタンプとするとき、 t2 のトランザクションが書いたアイテム (WT=t2) を t1 のトランザクションは読めない
• 未来に読み込まれるアイテムの値を、現在上書きできない
t1 < t2 をタイムスタンプとするとき、 RT=t2 のアイテムに t1 のトランザクションは書きこめない
どちらの場合も、 t1 のトランザクションを abort し、新しいタイムスタンプで再実行
Transaction Management / Distributed Database Management
T1 T2 A
タイムスタンプ 150 160 RT=0WT=0
READ A RT=150READ A RT=160
A:=A+1A:=A+1WRITE A WT=160
WRITE A WT=150
RT=160 > 150 なので T1 は abort
Transaction Management / Distributed Database Management
READ-READ の場合
T1 T2 A
タイムスタンプ t1 t2 RT=0(t1 < t2)
READ A RT=t2READ A RT=t2
RT=t2 > t1 でも読み込んで不具合が生じないRT=t2 はそのまま (RT=t1 としない)
Transaction Management / Distributed Database Management
T1 T2 A
タイムスタンプ t1 t2 WT=0(t1 < t2)
WRITE A WT=t2WRITE A WT=t2
WT=t2 > t1 のとき、 A に何も書き出さない未来に書き出される値に過去の値を上書きできない
整列スケジュールでは T1 のあと T2 を実行し、T1 の WRITE A の値を T2 が上書き
WT=t2 はそのまま (WT=t1 としない)
WRITE-WRITE の場合
Transaction Management / Distributed Database Management
T1 T2 T3 A B C
200 150 175 RT=0 RT=0 RT=0WT=0 WT=0 WT=0
READ B RT=200READ A RT=150
READ C RT=175WRITE B WT=200WRITE A WT=200
WRITE C WT=150abort
WRITE A WT=175書き出さない
Transaction Management / Distributed Database Management
タイムスタンプを使った整列化可能性チェックのまとめ
アイテム A (RT = rt, WT = wt) にタイムスタンプ t のトランザクションが 操作 X (= READ or WRITE) を行うとき
• X=READ かつ t < wt ならば abort
• X=WRITE かつ t < rt ならば abort
• X=WRITE かつ t≧rt かつ t<wt ならば書き出さない
• X=READ かつ t≧wt ならば実行し RT:=t
• X=WRITE かつ t≧rt かつ t≧wt ならば実行し WT:=t
正常な場合
Transaction Management / Distributed Database Management
タイムスタンプ方式は積極的プロトコルの例
• 同一アイテムの読み書きが競合する可能性のない場合に有効
• 不具合が生じたところでトランザクションを abort して対処
Transaction Management / Distributed Database Management
タイムスタンプの管理
• ロックで管理する場合はロックしているアイテムだけを表に登録すればよい
• タイムスタンプの場合、各アイテムごとに RT, WT を管理
• アイテム数が多い場合、管理表が大きくなる
Transaction Management / Distributed Database Management
解決案
• 実行中のトランザクションのタイムスタンプの最小値を M
M は生きている最も古いトランザクションのタイムスタンプ
• M より小さいタイムスタンプは全て -∞ にしても 整列化可能性のチェックは同様に実行できる
新しく実行されるトランザクションのタイムスタンプは 必ず M より大きいから
• RT=WT= -∞ となるトランザクションは管理表から外す
Transaction Management / Distributed Database Management
タイムスタンプ方式での障害発生時の
データベース修復
Transaction Management / Distributed Database Management
Abort および障害発生時の対応
• タイムスタンプ方式での同時実行制御は積極的プロトコル
• abort 時や障害発生時のデータベース修復に手間
• Dirty Read と Cascading Rollback に弱い
• ログの管理による対処
• COMMIT の利用
Transaction Management / Distributed Database Management
T1 T2 T3 A B C
200 150 175 RT=0 RT=0 RT=0WT=0 WT=0 WT=0
READ B RT=200READ A RT=150WRITE A WT=150
READ C RT=175READ A RT=200WRITE B WT=200WRITE A WT=200
WRITE C WT=150abort
abort
Cascading Rollback の例
Transaction Management / Distributed Database Management
タイムスタンプ方式での COMMIT の利用
• すべての計算を完了した時点で COMMIT を宣言
• すべての更新したアイテムの値を書き出す
注意点
• トランザクション T のタイムスタンプを t
• T が WRITE するアイテムの RT を rt
• t < rt ならば abort
• t < rt の確認を commit 以前に行えば、データベースに影響を与えずにトランザクションを abort できる
Dirty Read の回避
T A(timestamp=t)
:
COMMIT RT=rt
WRITE A
Transaction Management / Distributed Database Management
例
• T のタイムスタンプを 100
• T は最後に WRITE A と WT:=100 を実行
• A の RT < 100 であることを確認して T は計算を開始
• A の値をタイムスタンプ 110 のトランザクション T’ が読み、RT := 110 とする
• T は commit 直前に A の RT を読み、 RT=110 であることを知り abort
ロックをつかった abort 回避
RT をチェック後、 WT:=100 を実行し A をロックする
T’ が A の値を読み出すことを禁止
WRITE A を実行RT のチェックは既に行っているので不要
T (timestamp=100) :
COMMITWRITE A
Transaction Management / Distributed Database Management
ロックを使い abort を回避する方法1
• WRITE A をするトランザクション T (タイムスタンプ t) は、
- 計算開始時に A に対して WT=t として、 A をロック- 計算途中で abort した場合、 A のロックを開放し、 A の WT を元に戻す
• commit に到達したら、ログに T の計算した値を書き出す
• (T, commit) をログに追加
• データベースに T の計算した値を書き出す
• アイテムのロックを開放
• 長時間アイテムをロックする傾向にあるが、前ページのabort は回避できる
Transaction Management / Distributed Database Management
T T’ A100 110(実行開始) RT=90 : :
READ A RT=110COMMIT 100 < RT=110 abortWRITE A
T T’ A100 110(実行開始) RT=90WLOCK A WT=100 : :COMMITWRITE AUNLOCK A
RLOCK AREAD A RT=100
Transaction Management / Distributed Database Management
ロックを使い abort を回避する方法 2楽観的方法 (Optimistic Method)
• T が commit する直前に、 T が読み書きするすべてのアイテムをロックし、タイムスタンプの整合性をチェックし、abort か commit を判断
- abort の場合、 A のロックを開放し、 A の WT を元に戻す
• commit の場合、ログに T の計算した値を書き出す• (T, commit) をログに追加• データベースに T の計算した値を書き出す• アイテムのロックを開放
• 最初のステップでは、トランザクション実行中に RT が更新されるアイテムがないと 楽観的に考えている
Transaction Management / Distributed Database Management
T T’ A100 110(実行開始) RT=90 : :
READ A RT=110WLOCK A 100 < RT=110 abortUNLOCK ACOMMITWRITE A
T T’ A100 110(実行開始) RT=90 : :WLOCK A RT=90 < 100 no problemUNLOCK ACOMMITWRITE A WT=100
READ A RT=110
Transaction Management / Distributed Database Management
複数バーション法
• トランザクション T がアイテム A に書くとき A の新バーション Ai をつくり、 WT を T のタイムスタンプとする (例外を後述 )
• タイムスタンプ t のトランザクション T の READ A は、t 以下で t に最も近い WT のバーション Aj の値を読む
T1 T2 A0 A1 B0 B1
100 200 RT=0 RT=0WT=0 WT=0
READ A RT=100READ A RT=200WRITE B WT=200
READ B RT=100
T1: READ B は バーション B0 の値を読む
Transaction Management / Distributed Database Management
T1 T2 A B
100 200 RT=0 RT=0WT=0 WT=0
READ A RT=100READ A RT=200WRITE B WT=200
READ B RT=100abort
複数バーションをもたない場合
複数バーションをもち、すこし古い値にアクセスを許すことで、上のような abort を回避できる
しかしバーション管理は余分な記憶スペースを必要とする
Transaction Management / Distributed Database Management
新バーションを生成できずに abort する場合
• タイムスタンプ t のトランザクション T がアイテム A に書くとき、 WT < t < RT となる A のバージョンが存在する
T1 T2 A0 A1
150 160 RT=0WT=0
READ A RT=150READ A RT=160
A:=A+1A:=A+1WRITE A WT=160
WRITE Aabort
A0 は時刻 0 から少なくとも 160 までは生きているT1: WRITE A は時刻 150 で A の値を変更するので abort
Transaction Management / Distributed Database Management
• 何もしない素朴な方法問題が起こったら abort で対処
• ロックを使って abort を回避ロックする時間が長くなる
• COMMIT 前に瞬間的にロックまた abort の危険性がでる
• 複数バージョン法素朴な方法に比べ abort する頻度は減るバージョン管理にスペースを食う
Transaction Management / Distributed Database Management
難しい場合: 対立するトランザクションによる abort の繰返し
T1 T2 T1 T2 A B
100 110 120 130 RT=0 RT=0WT=0 WT=0
WRITE B WT=100 WRITE A WT=110
READ A RT=100abort
WRITE B WT=120 READ B RT=110 abort
WRITE A WT=130READ A RT=120abort
再実行
再実行
abort の繰返しを回避する効果的な方法はあまりない再実行のタイミングをランダムにずらすことで対立を多少緩和
Transaction Management / Distributed Database Management
分散データベース管理
参考文献
Jeffrey D. Ullman: Principles of Database and Knowledge-base SystemsVolume I, Computer Science Press, 1988. ISBN 0-7167-8158-1
Chapter 10 Distributed Database Management
Transaction Management / Distributed Database Management
• 前回までは単一計算機に格納されたデータベースへのトランザクション処理を解説
• 複数計算機上に分散して存在するデータベースへのトランザクション処理は多少複雑化
- 2相ロックプロトコル
- 分散 deadlock 検知と回避
- 分散コミットメント 2相コミットプロトコル
Transaction Management / Distributed Database Management
ノード(サイト)CPU + Disk
ノード(サイト)CPU + Disk
ノード(サイト)CPU + Disk
リンク
LAN専用電話回線
etc.
ネットワーク
Transaction Management / Distributed Database Management
ネットワークの故障・障害
• ノードの故障、リンクの故障
分散データベースの resiliency (弾力性 )
• 複数のアクセスパスをもつネットワークの形態で補強
リング メッシュ ハイパーキューブ
• データの複製により補強
アイテムの値のコピーを、必要なノードに配布
Transaction Management / Distributed Database Management
データの複製をもつ場合の注意点
• アイテム A の値を変更するとき、 A の全コピーの値を変更
• 一つのまとまった原子的な操作に見せかける
障害発生時
• A のコピーをもつノード N が停止
• A の値を知りたいトランザクションは N 以外のノードから値を入手
• N が復活したとき、 A に最新の値をセット
Transaction Management / Distributed Database Management
N1コピー A
N2コピー A
N3コピー A
N4コピー B
N5コピー B
グローバル トランザクション T
口座 A から 10000 円を引き落とし口座 B へ 10000 円振込み
• 各ノードごとにコピーAから 10000 円減額する 「ローカル サブトランザクション」 を実行
• 全コピーの更新をするか否か
• あるノードでトランザクションが abort したら全更新を無効にする
Transaction Management / Distributed Database Management
各ノードにおけるロックマネージャーの動作
トランザクション
ロックマネージャー
アイテム WLOCK ?A YB NC Y: :
アイテムに複数のコピーがある場合
複数のコピーのロックを同時に取る
WLOCK A 要求
許可または拒否
Transaction Management / Distributed Database Management
Write-Locks-All Read-Locks-One
• WLOCK A (書きこみ専用ロック ) を実行するにはA のすべてのコピーを WLOCK A すればよい
• RLOCK A (読取り専用ロック ) を実行するにはA の一つのコピーを RLOCK A すればよい
• A のコピーをもつ各ノードでは
- WLOCK がかかっていなければ RLOCK を許可 (複数の RLOCK を許可)
- RLOCK と WLOCK いずれも かかってなければ WLOCK を許可
Transaction Management / Distributed Database Management
アイテム A にロックをかけようとする任意のトランザクションを T1, T2
• T1, T2 は同時に A に WLOCK をかけられない
• T1 は WLOCK 、 T2 は RLOCK を同時にかけられない
• 唯一可能なのは T1 と T2 が同時に RLOCK すること
T1: WLOCK A T2:RLOCK A
Transaction Management / Distributed Database Management
Write-Locks-All のメッセージ数
N0A
N1A
NnA
WLOCK A
承認
更新データ
A のコピーは n 個
1回の WLOCK A
2n 個の制御メッセージ(WLOCK A 、承認 )
n 個の更新データ
NiA… …
Transaction Management / Distributed Database Management
Read-Locks-One のメッセージ数
• A のコピーを持つあるノード N に RLOCK A を要求
• N が RLOCK A を許さない場合、他のノードに要求すべきか?
• RLOCK A の許可が下りないのは WLOCK A が実行されている場合
• 他のサイトも RLOCK A は拒否するので、少し待って RLOCK A
Transaction Management / Distributed Database Management
過半数ロック戦略
• WLOCK A (書きこみ専用ロック ) を実行するにはA のコピーの過半数を WLOCK A すればよい
• RLOCK A (読取り専用ロック ) を実行するにはA のコピーの過半数を RLOCK A すればよい
• A のコピーをもつ各ノードでは
- WLOCK がかかっていなければ RLOCK を許可
- RLOCK と WLOCK いずれも かかってなければ WLOCK を許可
Transaction Management / Distributed Database Management
アイテム A にロックをかけようとする任意のトランザクションを T1, T2
• T1, T2 は同時に A に WLOCK をかけられない• T1 は RLOCK 、 T2 は WLOCK を同時にかけられない• 唯一可能なのは T1 と T2 が同時に RLOCK すること
T1 T2
Transaction Management / Distributed Database Management
過半数ロック戦略のメッセージ数
• アイテム A のコピーが n 個ある場合
• (n+1)/2 以上のノードに WLOCK (or RLOCK) A を要求
• ロックと承認あわせて n+1 個以上のメッセージを送信
Transaction Management / Distributed Database Management
制御メッセージ数
WLOCK RLOCK
Write-Locks-All 2n 2
過半数ロック戦略 n+1 以上 n+1 以上
トランザクションが2つの場合Write-Locks-All deadlock する可能性大過半数ロック戦略 どちらかは WLOCK を取れる
トランザクションが3つ以上の場合過半数ロック戦略でも deadlock する可能性あり
Transaction Management / Distributed Database Management
過半数ロック戦略の一般化 k-of-n 戦略 (n/2 < k ≦ n)
• WLOCK A (書きこみ専用ロック ) を実行するにはA の k 個のコピー を WLOCK A すればよい
• RLOCK A (読取り専用ロック ) を実行するにはA の (n-k)+1 個のコピーを RLOCK A すればよい
T1: WLOCK A T2: RLOCK A
k 個 (n-k)+1 個
Write-Locks-All n-of-n 戦略過半数ロック戦略 (n+1)/2-of-n 戦略
Transaction Management / Distributed Database Management
分散2相ロック
Transaction Management / Distributed Database Management
TT1 T2WLOCK A1 WLOCK A2UNLOCK A1 UNLOCK A2
UU1 U2WLOCK A1 WLOCK A2UNLOCK A1 UNLOCK A2
T1 U1 T2 U2
WLOCK A1UNLOCK A1 WLOCK A2
UNLOCK A2WLOCK A1UNLOCK A1 WLOCK A2
UNLOCK A2
Write-locks-all で各コピーをロック(同時にコピーを更新できない例)
アイテム A のサイト S1, S2 でのコピーを A1, A2
T1 → U1 U2 → T2
S1 S2
Transaction Management / Distributed Database Management
サブ トランザクション (例えば T1, T2) の同期が必要
• サブ トランザクション全体での2相ロックプロトコルを考える必要がある
• すべてのサブ トランザクションが必要なアイテムを LOCK した後に、 UNLOCK を開始するように制御したい
• 分散合意問題 (distributed agreement problem)
• COMMIT を使った強2相ロックプロトコル方式による解法
Transaction Management / Distributed Database Management
T
T1 T2
WLOCK A1 WLOCK A2COMMIT COMMITUNLOCK A1 UNLOCK A2
U
U1 U2
WLOCK A1 WLOCK A2COMMIT COMMITUNLOCK A1 UNLOCK A2
COMIMIT を使った強2相ロックプロトコル方式による解法
• すべてのサブトランザクションが COMMIT に達した時点で、トランザクション全体がコミットしたと考える
• 分散コミットメント(後に説明)により全サブトランザクションの合意を確認
Transaction Management / Distributed Database Management
強2相ロックプロトコル方式での deadlock 問題
(アイテム A, B はコピー持たないものの deadlock が起こる)
TT1 T2WLOCK A WLOCK BCOMMIT COMMITUNLOCK A UNLOCK B
UU1 U2WLOCK A WLOCK BCOMMIT COMMITUNLOCK A UNLOCK B
T1 U1 T2 U2
WLOCK A WLOCK BCOMMIT COMMIT
UNLOCK A WLOCK A WLOCK B UNLOCK BCOMMIT COMMIT UNLOCK A UNLOCK B
deadlock状態
Transaction Management / Distributed Database Management
分散データベース環境での deadlock 回避
アイテムへの全順序の導入
• アイテムに全順序を入れる
• トランザクションは、すべてのサブトランザクションが全順序に従ってアイテムにロックをかけるように調整
Transaction Management / Distributed Database Management
TT1 T2WLOCK A
WLOCK BCOMMIT COMMITUNLOCK A UNLOCK B
UU1 U2WLOCK A
WLOCK BCOMMIT COMMITUNLOCK A UNLOCK B
T1 U1 T2 U2
WLOCK AWLOCK B
COMMIT COMMIT UNLOCK A UNLOCK B
WLOCK AWLOCK B
COMMIT COMMITUNLOCK A UNLOCK B
Transaction Management / Distributed Database Management
時間切れ方式
• 待ち時間に上限値を設け、時間切れしたトランザクションは abort
• 待ち時間の上限値の調節
- deadlock 状態にあるトランザクションが不必要に アイテムをロックし続けない程度に短くする
- deadlock 状態にないトランザクションを不必要に
abort させない程度に長くする
• 制御メッセージの通信を伴わない
分散データベース環境での deadlock 回避
Transaction Management / Distributed Database Management
T1 U1 T2 U2
WLOCK A WLOCK BCOMMIT COMMIT
UNLOCK A WLOCK A WLOCK B UNLOCK BCOMMIT COMMIT UNLOCK A UNLOCK B
Waits-for-Graphs
deadlock状態
T U T U
T U
分散データベース環境での deadlock 回避
Transaction Management / Distributed Database Management
分散コミットメント
Transaction Management / Distributed Database Management
分散データベースでのトランザクション
分散した計算機上で動作する複数の部分トランザクションにより実行される
部分トランザクションの中から 調整役 (coordinator)を選ぶ
その他を 参加者 (participants) と呼ぶ
Transaction Management / Distributed Database Management
調整役
参加者 i
全参加者がコミットを表明する場合、全体としてもコミット
ある参加者がアボートを表明する場合、全体としてもアボート
参加者は
• vote-commit ( コミットの表明 )
または
• vote-abort (アボートの表明 )
を調整役に送信
投票
調整役は
• 全参加者がvote-commit の場合は全参加者に commit を送信し、全体としてコミットすることを伝える
• ある参加者がvote-abort の場合は全参加者に abort を送信し、全体としてアボートすることを伝える
決定
投票の後に決定を下す2つの相からなるので2相コミット (two-phase commit) とよぶ
Transaction Management / Distributed Database Management
初期状態
コミット終了
コミット宣言中
アボート終了
初期状態
コミット終了
コミット処理中
アボート処理中
アボート終了
vote-commit 送信
vote-abort 送信またはabort 受信
abort 受信
commit 受信
すべての参加者からvote-commit を受信
ある参加者からvote-abort を受信
commit 送信
abort 送信
参加者
調整役
Transaction Management / Distributed Database Management
初期状態
コミット終了
コミット宣言中
アボート終了
vote-commit 送信
vote-abort 送信またはabort 受信
abort 受信
commit 受信
参加者
ブロック状態
参加者 T がコミット宣言中に調整役から commit, abort いずれのメッセージも受信しない状態。 通信路の信頼性に対する不安
勝手に先に進むと問題が発生。
Transaction Management / Distributed Database Management
参加者 T がブロック状態で勝手に先に進むと微妙な問題が発生
勝手にコミット終了へ進むとき
• T はコミット後に、アイテム A の値を更新• T が更新した A の値を、ある参加者 T’ が読む• 他の参加者がアボートを宣言し、全体がアボート• T’ はアイテム A を Dirty Read したことになる
初期状態
コミット終了
コミット宣言中
アボート終了
vote-commit 送信
vote-abort 送信またはabort 受信
T以外はabort 受信
Tは勝手に進む
T が A へ書きこみT’ が Dirty Read
Transaction Management / Distributed Database Management
• 調整役が全参加者から vote_commit の受信を確認後に、T と調整役の通信が切断されたと仮定• 調整役からの commit は T 以外の参加者には送信され、これらの参加者は A のローカルコピー値を更新• しかし T だけは commit の知らせが入らず、勝手にアボートするので、 A を更新しない• T とその他の参加者で A のローカルコピー値が同一でなくなる
勝手にアボート終了に進むとき
初期状態
コミット終了
コミット宣言中
アボート終了
vote-commit 送信
vote-abort 送信またはabort 受信
T は勝手に進む
T 以外はcommit 受信
Transaction Management / Distributed Database Management
調整役ではなく、他の参加者に助けを求める (help-me 送信 )
• コミット終了状態の参加者は、全体がコミットしたことを知るT に commit を送信
• アボート終了状態の参加者は、全体がアボートしたことを知るT に abort を送信
• 初期状態にある参加者は、アボートすることで、全体を アボートさせ、ブロック状態から抜け出る状況をつくれる
調整役には vote-abort を送信T には abort を送信
• コミット宣言状態の参加者は、同じブロック状態にあり、 状況を変えられない
コミット宣言中の参加者 T がブロック状態から抜け出るには
Transaction Management / Distributed Database Management
初期状態
コミット宣言中
コミット終了
ブロック状態
アボート終了
救助を待つ
abort 受信
commit 受信
時間切れ
help-me 送信
commit 受信
abort 受信
vote-abort 送信またはabort 受信
vote-commit 送信
参加者
Transaction Management / Distributed Database Management
• 調整役が最終的に abort を送信する場合、commit を受信しない
仮に commit を受信すれば、全体がコミットしたことを知る参加者から受信するので矛盾
• 調整役が最終的に commit を送信する場合、abort を受信しない
仮に abort を受信すれば、全体のアボートを知る参加者からの受信か、初期状態の参加者 T’ が abort を決断した場合。後者の場合、調整役は初期状態ののち、 T’ から abort を受信し、最終的に abort を送信。矛盾。
• commit と abort を同時に受信しない
help-me を送信した参加者は矛盾した情報を受信しない
Transaction Management / Distributed Database Management
• help-me を使う場合、各参加者が助けを求める参加者リストを知る必要がある
•初期状態の前に参加者リストを知らせる begin-vote
メッセージを全参加者に送信
その他の修正
待ち状態
コミット終了
コミット処理中
アボート処理中
アボート終了
すべての参加者からvote-commit を受信
時間切れまたはある参加者からvote-abort を受信
commit 送信
abort 送信
初期状態
begin-vote 送信
調整役
Transaction Management / Distributed Database Management
• 2相コミット開始時に、参加者と調整役との通信が確立しない場合はアボートする
• 参加者の場合 begin-vote の受信が時間切れになるとアボートする• 調整役の場合、参加者から vote の受信が時間切れになるとアボートする
その他の修正
初期状態
考察中 コミット宣言中
コミット終了
ブロック状態
アボート終了
救助を待つ
vote-commit 送信
vote-abort 送信またはabort 受信
abort 受信
commit 受信
Begin-vote 受信
時間切れ
時間切れ
help-me 送信
commit 受信abort 受信参加者
Transaction Management / Distributed Database Management
初期状態
考察中 コミット宣言中
コミット終了
ブロック状態
アボート終了
救助を待つ
vote-commit 送信
vote-abort 送信またはabort 受信
abort 受信
commit 受信
Begin-vote 受信
時間切れ
時間切れ
help-me 送信
commit 受信abort 受信参加者
ここでブロック状態に陥るケース
Transaction Management / Distributed Database Management
調整役
vote-commit を送信
調整役
直後に回線が切断
commit 送信 commit を受信しない .help-me を出してもブロック状態から抜けないこの参加者は
commit の先に進み、データベースを更新してよいのか?
一部の参加者だけが commit を知る状況
Transaction Management / Distributed Database Management
• 2相コミットはデータベース製品で普及しているが、ブロック状態に陥る可能性が残っている
• 2相コミットは、全参加者が vote-commit した後は、commit するプロトコル
• 3相コミットは、全参加者が vote-commit した後に、全参加者が「全参加者が vote-commit したこと」を知ったのち commit するプロトコル
• メッセージ通信コストが高く、現実には殆ど使われていない
3相コミット