Downloaded 109 times
![トランザクションの基本
• トランザクションとは：CommitかAbortで終わる
複数の手続きの塊
– 例 [Read(x) Read(y) Write(y) Commit]
• トランザクションマネージャとは：トランザクショ
ンを複数並行して流し込んでも、何らかの順序
で一つずつ直列に流し込んだかのような結果を
生み出すシステム
– トランザクションマネージャの中では主に並行制御
アルゴリズムが使われる](https://image.slidesharecdn.com/db-170428160930/75/DB-2-2048.jpg)
Uploaded byKumazaki Hiroki
地理分散DBについて
Database Lounge Tokyo #4 https://database-lounge-tokyo.connpass.com/event/54855/ で話した資料。 動画はこっち https://www.youtube.com/watch?time_continue=1&v=VTEAJHJHIpY
More Related Content
地理分散DBについて
- 1. 地理分散DBについて 2017年4月28日 Database Lounge Tokyo ハッシュタグ#dbltokyo 発表者 熊崎宏樹 @kumagi
- 2. トランザクションの基本 • トランザクションとは：CommitかAbortで終わる 複数の手続きの塊 – 例[Read(x) Read(y) Write(y) Commit] • トランザクションマネージャとは：トランザクショ ンを複数並行して流し込んでも、何らかの順序 で一つずつ直列に流し込んだかのような結果を 生み出すシステム – トランザクションマネージャの中では主に並行制御 アルゴリズムが使われる
- 3. 並行制御アルゴリズム • 2 PhaseLock・タイムスタン プ・グラフ・楽観的制御と 様々な亜種が考案されて きた – その系統を樹形図で表し たのが右図 – 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 2Phase Lock おさらい • 基本は2 Phase Lockだが、書き込みは常にその値の新し いバージョンをタイムスタンプと共に生成する – Read Onlyトランザクションは古いバージョンを読み出す事が できる – 古いバージョンは消えないのでRead Onlyトランザクションが 絶対成功する 処理A 新しいバージョンが生成される
- 9.
- 10.
- 11.
- 12. Phase 2 2 PhaseCommit • 分散合意プロトコルの金字塔 – 誰が最初の発明者かも明白でないほど古い – 故障時の挙動に大量の亜種がある 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 PhaseCommit • Commit前にcoordinatorが故障したら、それを検知した リカバリノードがabortを依頼してロールバック – 1つもcommitが成功していない事を調べる prepare ok recovery coordinator worker worker Phase 1 check abort
- 16. Phase 2 2 PhaseCommit • 死んだと思っていたcoordinatorが生きていたら？ – 食い違って死ぬ – 2 Phase Commitは基本的に死ぬ prepare ok coordinator worker worker Phase 1 abort commit committed aborted check
- 17. Phase 2 2 PhaseCommit • commit途中でcoordinatorが落ちたら prepare ok commit ok coordinator worker worker Phase 1
- 18. Phase 2 2 PhaseCommit • commit途中でcoordinatorが落ちたら回復ノードが表 れて一つでもcommitしていたら全部をcommitさせる prepare ok commit coordinator worker worker Phase 1 commitcheck ok
- 19. Phase 2 2 PhaseCommit • 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はそのまま では使えない
- 21. Paxos • Lamport先生が「参加者の故障や復活がある場 合絶対に合意には至れない」ということを証明 しようとして逆に生み出してしまった合意プロト コル – 実は故障に耐える合意プロトコルは他にも viewstampedreplicationとかstake replicationとかい ろいろあるが、きっちり証明されたのはPaxosが初だ から有名らしい 出典:http://lamport.azurewebsites.net/pubs/pubs.html#lamport-paxos
- 22. Paxos • 複雑さに定評がある(とよく言われる) – 正常時の挙動やメッセージ数は2PCと同じ –prepare, proposeがバージョン番号を持つ prepare(n) ok(n, v) propose(n, v) accept(n) coordinator worker worker
- 23. Paxos • Coordinator – prepare(n)に対して過半数からok(n,v)が貰えたらそ の中で最大のnに対するvを全workerに投げる •このvがnullなら自分自身のvを使う • nullでないならvは生死不明な他のCoordinatorのvである • Worker – 過去に見たprepare(n)のうち最大のnであればそれ にok(n,v)を返す。そうでなければng(n') • vは過去に一度も合意してない場合nullかも知れない 25行で説明するPaxos: http://nil.csail.mit.edu/6.824/2015/notes/paxos-code.html
- 24. Paxos • 2PCだと死んだシナリオ – 蘇るcoordinator •間に入った別のcoordinatorがバージョン番号を変えるので 間違った合意に至らなくなる prepare(n) ok(n,v) coordinator worker worker propose(n',v) propose(n) prepare(n') ng(n',v) ng(n',v)
- 25. Paxos • 過半数にproposeが届いた時点でクラスタは合意した事になる – workerが復活してもok –不完全な複製は後続のcoordinatorが複製し直してくれる prepare(n) ok(n, v) propose(n, v1) coordinator1 worker worker coordinator2 prepare(x) ok(x, v1) propose(x, v1)
- 26. Paxos • あらゆる故障パターンを網羅して描いても良い けれどスライドに書くには手狭&退屈 • エッセンスだけ掻い摘むと –バージョン番号のお陰で古いcoordinatorやworker が場を乱そうとしても適切に無視される – 複数のcoordinatorがある意味リカバリノードを兼ね ている（合意した値が既に一部のworkerにあれば それを再度全体へ周知する） – 過半数が合意すればプロトコルが進行するように設 計されているためシンプル
- 27. ここまでのまとめ • 2 PhaseCommitは基本的に壊れている • 任意の通信遅延(つまりノードの復活)を含む分 散環境で合意するにはPaxosのような強固なプ ロトコルが必要
- 28. Spanner • Googleが開発してOSDI 2012で発表した地理分 散データベース –登場時は原子時計やGPSを使っている事ばかりが 話題にされたが実はそこは枝葉末節 • その実態はMV2PLと2Phase Lockと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タブレットを1Paxos単位として地理分散 日本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
- 31.
- 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回分
- 33. Spannerでの更新 • トランザクションの操作が1つのtabletの中で収 まるなら、TabletのPaxosを行うリーダーに命令 の実行を依頼する – tablet内は2phase lockで並行制御 • 複数のtabletに跨るトランザクションは、複数の tabletの間で2 Phase Commitを行う – 2 Phase Commitは故障に弱いのでは？→Paxosが 参加者なので故障しないと仮定してよい – tabletを跨っても2 phase lockで並行制御
- 34. Spannerでの更新 • paxosグループが参加者となって2phase commitを行う –paxos – 2PC paxos paxos prepare prepare ok commit ok
- 35. Spannerでの参照 • 2 PhaseLockを使って更新しているのでトランザ クションとしてはこの上なく正しい • だがRead Onlyな操作であっても毎回2 Phase Lockを使うのはコストが高すぎる • よし、全部の値にタイムスタンプを振って追記す る形を取れば、過去の任意の時間の値に遡っ て一貫性のあるRead-Onlyトランザクションがで きるぞ！ – いわゆるMV2PL – (そのままでは)分散環境ではまともに動かない
- 36. SpannerでのRead-Onlyトランザクション • まともに動かない理由：各サーバの時刻がズレて いるから write(x,10) write(y,10) read(x),read(y) x=10, y=10 期待する挙動
- 37. SpannerでのRead-Onlyトランザクション • まともに動かない理由：各サーバの時刻がズレて いるから read(x), read(y)x=0, y=10 発生する挙動 write(x,10) write(y,10)
- 38. Spannerが満たしたい一貫性 • External Consistency –あるトランザクションT1が終わった後に始まったトラ ンザクションT2のタイムスタンプは絶対にT1より後 – これを分散MV2PL環境下で実現したのがSpannerの Contribution • どうやって？ – やっと原子時計・GPSの出番
- 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の証明 • ExternalConsistencyを満たす証明は論文に書 いてあって複雑に見えるが実は簡単 – T1が振ったタイムスタンプが過ぎてからアンロック • s1 < T1(完了) – アンロックが済んだ後のデータをT2が読む • T1(完了) < T2(開始) – T2に振られる時刻はT2の開始より後(当然) • T2(開始) < s2 – よって s1 < s2 → External Consistencyは守られた
- 42. 細かい議論 • Read Onlyトランザクションもタイムスタンプを振られ る –そのタイムスタンプより前の値しか読みだすことができ ない – そのタイムスタンプの値を読み出せたと断言するために はそのタイムスタンプの時刻が過ぎた後でないといけな い – なお、Tabletを跨らないRead Onlyは普通にMV2PLの範 疇で値を読んでかまわないから少し速い • googleのシステムでは時刻ズレは1桁ミリ秒の範囲 で収まっている様子。これによって比較的高速なト ランザクションができる – 単純に遅延が小さいことより、ジッタが少ない事が脅威
- 43. ベンチマーク • Quizletというサービスが使い込んだベンチを公 開している • ノード数を増やすごとにスループットの限界が伸びている •台数当たりの性能ではやはりMySQLに軍配 • アルゴリズムの割にレイテンシが引く程低い
- 44. Spannerのまとめ • 基本的にMV2PLを分散環境に拡張しただけ • CommitWaitがcontributionだが愚直にやると 性能が残念になる • そこでTrue Time APIでCommit Waitを短縮した
- 45.
- 46. Spannerでの遅延 • paxosの通信は常に地理的に跨っている – 地理間通信に片道10ms掛かると仮定すると…？ paxos paxos prepare prepareok commit ok 40ms • tabletを跨る2PCは最低でも160msかかる – 実際はもっと細かい高速化ができるが割愛
- 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)
- 48. Calvin • トランザクションリクエストそのものを複製すれば良いよね – 同じリクエストを同じ順序で実行したら同じDB状態になるし –各DBはクエリを実行する順序だけ合意して、あとはFIFOに処理していくだけ – いわゆる並行処理制御でいうDeterministicアプローチ 2PC 2PC prepare(n) propose(n,v) ok(n,v)
- 49. Spanner vs Calvin •要旨：ほとんどのケースでCalvinはSpannerより優れている – DC間通信をしている間に値をロックし続ける必要が無いという点で速度 的に優位 • 試したい人はFaunaDBを使ってみてね https://fauna.com/blog/spanner-vs-calvin-distributed-consistency-at-scale
- 50. まとめと所感 • 分散DBと違って地理分散DBはDC間の遅延が支配項に なりがちなので新しいプロトコルが考案される素地があ る • トランザクションの実行順序だけ合意するというアプロー チは良さそうに見えるがDBを大規模に水平分割する前 提で考えるとShared-Everything的になってスケーラビリ ティに限界が出るのでは？ –どのクエリがどの値に触るかを断定すればShared-Nothing になるがその断定に掛かるコストが今度は高くつきそう