Contenu connexe
Similaire à 地理分散DBについて (20)
Plus de Kumazaki Hiroki (15)
地理分散DBについて
- 3. 並行制御アルゴリズム
• 2 Phase Lock・タイムスタン
プ・グラフ・楽観的制御と
様々な亜種が考案されて
きた
– その系統を樹形図で表し
たのが右図
– 2PLは有名だがその位置づ
けは数ある手法の一角に
過ぎない
Transactional Information Systems 176ページから抜粋
- 4. 2 Phase Lock おさらい
A「ロックを取って行った操作は論理的にはいつ実行され
た事にして良いか?」
Q「ロックが保持されていた期間の中ならどこでも良い」
処理が実行されたと見なせる論理的な時間軸上の瞬間
を「Linearization Point」と呼ぶ
処理A 処理B
Linearization Point
- 5. 2 Phase Lock おさらい
Q「2つ以上のオブジェクトのロックを握って行った
操作は論理的にはいつ実行された事にして良い
か?」
A「全部のロックが確保された中の一瞬に全ての
操作が行えた事にしてよい」
処理A
3つのLinearization Pointが重なっている
- 6. 2 Phase Lock おさらい
• 複数のロックを握りっぱなしで行った操作は、複数の
オブジェクトを一瞬で操作した事にしてよい
• ACI(D)特性を実現する基盤となる考え方
• 他の並行制御アルゴリズムも2PLをベースに拡張した
ものが多い
• とはいえRead Onlyなクエリでもロックを取ってしまうの
で実用上は性能が出にくく、現在の製品ではまず使わ
れていない
– 製品ではMVCCが使われる事が多い
- 7. Multi-Version Concurrency Control
• 商用DBで広く使われている並
行制御手法
• 内部は細かく分かれている
– MV2PLの事だけをMVCCだと思い
込んでる人が多い
Concurrency control protocols
Single-version Concurrency control protocolsMulti-version Concurrency control protocols
An Empirical Evaluation of
In-Memory Multi-Version Concurrency Control
から引用
OptimisticPessimistic
Nonlocking Locking Locking
MV2PLMVTO MVOCC
- 8. Multi Version 2 Phase Lock おさらい
• 基本は2 Phase Lockだが、書き込みは常にその値の新し
いバージョンをタイムスタンプと共に生成する
– Read Onlyトランザクションは古いバージョンを読み出す事が
できる
– 古いバージョンは消えないのでRead Onlyトランザクションが
絶対成功する
処理A
新しいバージョンが生成される
- 12. Phase 2
2 Phase Commit
• 分散合意プロトコルの金字塔
– 誰が最初の発明者かも明白でないほど古い
– 故障時の挙動に大量の亜種がある
prepare
ok
commit
ok
coordinator
worker
worker
Phase 1
- 13. 2 Phase Commit
• prepare完了前にworkerが故障したらabort
– これはいい
prepare
ok
abort
ok
coordinator
worker
worker
- 14. 2 Phase Commit
• Commit前にcoordinatorが故障したら
prepare
ok
coordinator
worker
worker
Phase 1
- 15. Phase 2
2 Phase Commit
• Commit前にcoordinatorが故障したら、それを検知した
リカバリノードがabortを依頼してロールバック
– 1つもcommitが成功していない事を調べる
prepare
ok
recovery
coordinator
worker
worker
Phase 1
check abort
- 16. Phase 2
2 Phase Commit
• 死んだと思っていたcoordinatorが生きていたら?
– 食い違って死ぬ
– 2 Phase Commitは基本的に死ぬ
prepare
ok
coordinator
worker
worker
Phase 1
abort
commit
committed
aborted
check
- 17. Phase 2
2 Phase Commit
• commit途中でcoordinatorが落ちたら
prepare
ok
commit
ok
coordinator
worker
worker
Phase 1
- 18. Phase 2
2 Phase Commit
• commit途中でcoordinatorが落ちたら回復ノードが表
れて一つでもcommitしていたら全部をcommitさせる
prepare
ok
commit
coordinator
worker
worker
Phase 1
commitcheck
ok
- 19. Phase 2
2 Phase Commit
• commit途中でcoordinatorが落ちたら一つでもcommit
しているときリカバリノードが全部をcommitさせる
– その途中で一部のworkerが落ちて後で復活したら?→死
prepare
ok
commit
coordinator
worker
worker
Phase 1
abortcheck
ok
committed
aborted
- 20. 2 Phase Commit
• 2 Phase Commitは故障したり復活したりするとすぐ
壊れる
• 回復中に壊れるパターンや回復ノードが壊れるパ
ターンまで挙げだすと壊せるシナリオは山ほど出
てくる
• 弱点を補強したという触れ込みの3 Phase Commit
なんてものもあるけどやはり壊れている
• GoogleのChubbyの開発者Mike Burrows「合意プロ
トコルは一つしかない。Paxosだ」(≒他の合意プロト
コルは全て合意不能)
覚えていただきたい事実:2 Phase Commitはそのまま
では使えない
- 27. ここまでのまとめ
• 2 Phase Commitは基本的に壊れている
• 任意の通信遅延(つまりノードの復活)を含む分
散環境で合意するにはPaxosのような強固なプ
ロトコルが必要
- 29. Spanner
• 巨大なDBでACIDかつ地理分散したい
– テーブルをタブレットへ水平分割
ID 名前 住所ID スコア
1 佐藤 3 123
2 田中 2 3243
3 鈴木 3 54
4 山田 5 2
5 磐田 6 332
6 吉井 3 232
7 山下 5 332
8 熊谷 3 12
ID 名前 住所ID スコア
1 佐藤 3 123
2 田中 2 3243
ID 名前 住所ID スコア
3 鈴木 3 54
4 山田 5 2
5 磐田 6 332
ID 名前 住所ID スコア
7 山下 5 332
8 熊谷 3 12
ID 名前 住所ID スコア
1 佐藤 3 123
2 田中 2 3243
数
万
行
約
千
行
- 30. Paxos
Spanner
• 障害に備えたい
– 1タブレットを1 Paxos単位として地理分散 日本DC
フランスDC
西海岸DC
ID 名前 住所ID スコア
1 佐藤 3 123
2 田中 2 3243
ID 名前 住所ID スコア
1 佐藤 3 123
2 田中 2 3243
ID 名前 住所ID スコア
1 佐藤 3 123
2 田中 2 3243
- 32. タブレット with Paxos
• 1つのタブレットの操作はPaxosで調停する
– Paxosは1つの値についてしか合意できないので、それを並
べて命令列を作り、合意できた命令から順に適用していく
– 同じ命令列を同じ順序で実行したのだから同じ状態になる
• Replicated State Machineという複製アプローチ
x=10
x=10
x=10
1
y=3
y=3
y=3
2
z=2
z=2
z=2
3
a=8
a=8
a=8
4
b=5
5
c=9
6
未実行命令
実行済命令
Paxosの合意
1回分
- 35. Spannerでの参照
• 2 Phase Lockを使って更新しているのでトランザ
クションとしてはこの上なく正しい
• だがRead Onlyな操作であっても毎回2 Phase
Lockを使うのはコストが高すぎる
• よし、全部の値にタイムスタンプを振って追記す
る形を取れば、過去の任意の時間の値に遡っ
て一貫性のあるRead-Onlyトランザクションがで
きるぞ!
– いわゆるMV2PL
– (そのままでは)分散環境ではまともに動かない
- 39. True Time API
• 正しい時刻がどの範囲にあるかわかるAPI
– GPSでも原子時計でも一応ズレるので、その誤差範
囲を制限できる機能がある
• システムに参加している全マシンの時刻の誤差
範囲を予測可能にする事が目的
– この範囲を超えて時間が狂うマシンはシステムから
除外される(地味に重要)
- 40. Spannerのcontribution: Commit Wait
• True Time APIを用いて
– トランザクションで書く値にタイムスタンプを振る
– タイムスタンプで振った時刻が「確実に過ぎた」と断言で
きるまで、ロックを意図的に握ったままにする
read(x), read(y) x=10, y=10
write(x,10) write(y,10)
Commit Wait
Commit Wait
- 41. Commit Waitの証明
• External Consistencyを満たす証明は論文に書
いてあって複雑に見えるが実は簡単
– T1が振ったタイムスタンプが過ぎてからアンロック
• s1 < T1(完了)
– アンロックが済んだ後のデータをT2が読む
• T1(完了) < T2(開始)
– T2に振られる時刻はT2の開始より後(当然)
• T2(開始) < s2
– よって s1 < s2 → External Consistencyは守られた
- 42. 細かい議論
• Read Onlyトランザクションもタイムスタンプを振られ
る
– そのタイムスタンプより前の値しか読みだすことができ
ない
– そのタイムスタンプの値を読み出せたと断言するために
はそのタイムスタンプの時刻が過ぎた後でないといけな
い
– なお、Tabletを跨らないRead Onlyは普通にMV2PLの範
疇で値を読んでかまわないから少し速い
• googleのシステムでは時刻ズレは1桁ミリ秒の範囲
で収まっている様子。これによって比較的高速なト
ランザクションができる
– 単純に遅延が小さいことより、ジッタが少ない事が脅威
- 47. Replicated Commitアプローチ
• 2PCのログ結果を共有するのではなくコミット可能か否かを共
有する
• Paxos on 2PCにすれば地理間通信が減るね
2PC
2PC
prepareprepare(n)
ok(n,v)
commitpropose(n,v)
ok(n,v)
• この方式なら2往復で済む
– 2PCの進行に掛かるログをPaxosで複製する(Log Replication)のではなく、コミット可能
か否かという情報をPaxosで複製する(Commit Replication)
Hatem Mahmoud et al. Low-Latency Multi-Datacenter Databases using Replicated Commit(VLDB2013)
- 49. Spanner vs Calvin
• 要旨:ほとんどのケースでCalvinはSpannerより優れている
– DC間通信をしている間に値をロックし続ける必要が無いという点で速度
的に優位
• 試したい人はFaunaDBを使ってみてね
https://fauna.com/blog/spanner-vs-calvin-distributed-consistency-at-scale