Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

トランザクションの並行実行制御 rev.2

4,062 views

Published on

筑波大学 集中講義でのスライド

Published in: Technology
  • Follow the link, new dating source: ♥♥♥ http://bit.ly/2F7hN3u ♥♥♥
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Dating direct: ❶❶❶ http://bit.ly/2F7hN3u ❶❶❶
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

トランザクションの並行実行制御 rev.2

  1. 1. トランザクションの 並行処理制御 星野 喬@サイボウズ・ラボ 情報システム特別講義D 2017-01-20 1
  2. 2. 自己紹介 • 星野 喬 • サイボウズ・ラボ • 今の仕事 • WalB の開発(ストレージバックアップ) http://walb-linux.github.io/ • などなど • 今の興味 • トランザクションシステム 2
  3. 3. サイボウズ の紹介 • チームあるところにサイボウズあり • 多様性/公明正大/理想への共感/自立と議論の文化 • 製品、サービス • Office/Garoon: カレンダー、ワークフローなど • kintone: LowCode Developing (WebDB+α) • メールワイズ: チームでメール対応 (サポートetc) • Live: 無料、少人数/一時的なチーム向け • 特徴 • 「場」+データ+コミュニケーション • アクセス権などしっかり(エンタープライズも安心) 3
  4. 4. • 「次世代の製品・サービスの基盤となる技術を 中長期視点で研究開発しています」 • サイボウズの100%子会社 • サイボウズ東京オフィスに開発本部と同居 • 採用募集もしています 4
  5. 5. 採用/インターン/ラボユース • 本社エンジニア採用 • インフラ周りでコード書ける人: SRE チームへ! • Web/App コード書ける人: 開発本部へ! • その他も含めて新卒/中途問わず募集中 • https://cybozu.co.jp/company/job/recruitment/ • 開発インターン • 新卒向けの就業体験です (夏休み 1〜2週間) • ラボユース • 学業の合間に好きなOSSコード書いて給料出ます • ラボメンバーがメンターとして付きます • http://labs.cybozu.co.jp/youth.html 5
  6. 6. 今日の話 • トランザクション • Serializability+α • Concurrency Control 手法/研究の紹介 6
  7. 7. トランザクション • それ以上分割できない処理単位 • ACID 特性を満たす • Atomicity • Consistency • Isolation • Durability 7
  8. 8. Isolation • 分離性、独立性 • Tx が混ざるのを避けたい: • 他の Tx の実行中状態を見たくない • どちらがどちらに依存しているか分からない • etc. • 何を満足すれば良いか? • Serializability 8
  9. 9. Concurrency Control の目的 • 出来るだけ並行に処理したい • システムの並列性を生かして性能を出したい • Serializable に実行したい • 性能のために妥協することはあるかも 9
  10. 10. トランザクション実行の流れ 10 multiple read/write commit proc reply abort proc client client lock による排他 old version の read deadlock prevension read/write set 管理 etc. log を書いて 永続化 データベース本体は 後でゆっくり永続化 Concurrency Control の主な仕事 何をするかは方式によって異なる (pre-commit) lock による排他 read verify (OCC) deadlock detection etc.
  11. 11. トランザクションシステム 三大要素 • Data Structure • インデクス構造、key から value に到達する手段 • WAL (Write-Ahead Logging) • 永続化制御のための仕組み • Cocurrency Control • 性能を出すため良い性質を保ったまま並行実行 • これにデータ処理(filter, sort, join など)、SQLパーサや オプティマイザなどを載せると Relational DBMS の出 来上がり! 11
  12. 12. Serializability+α 12
  13. 13. 用語 • Transaction (Tx) operations • 複数の data item に対する read/write と、最後に commit か abort で終了する operation 列 • 例: 𝑟1 𝑥 𝑟1 𝑦 𝑤1 𝑧 𝑐1 • History/schedule • 有限個 Tx の operations からなる集合 • 同一 data item へのアクセスは順序を持つ • 例: 𝑟1 𝑥 𝑟2 𝑦 𝑤1 𝑦 𝑟2 𝑥 𝑐1 𝑎2 • Serial history • 全 Tx が直列化された history • 例: 𝑟1 𝑥 𝑤1 𝑦 𝑐1 𝑟2 𝑦 𝑟2 𝑥 𝑎2 13
  14. 14. Serializability • 簡単に言うと、 Serial history と同等の history 集合 • 「同等の」って何? • 最終結果が同じ? (FSR) • どの時点でも中間状態が同じ? (VSR) • 部分的に比較しても同じ?(Monotonicity) • 競合の仕方が同じ? (CSR) • 皆、良い性質を持っている CSR を使う 14
  15. 15. CSR: Conflict Serializability • Conflict(競合) • 同じ data item に対する w-w, w-r, r-w のいずれか の関係を持つ 2 つの異なる Tx の関係 • 例: 𝑤1 𝑥 𝑟2 𝑥 𝑐1 𝑐2 は 𝑇1 と 𝑇2 が w-r 競合 • CSR: 競合関係が同じ serial history が存在する • Conflict Graph • Tx をノード、conflict をエッジとしたグラフ • Conflict graph が acyclic ⇔ CSR 15
  16. 16. History 例(1) 𝑠: 𝑟1 𝑥 𝑟2 𝑥 𝑟1 𝑧 𝑤1 𝑥 𝑤2 𝑦 𝑟3 𝑧 𝑤3 𝑦 𝑐1 𝑐2 𝑤3 𝑧 𝑐3 16 𝑇1 𝑇2 𝑇3 x: r-w z: r-w y: w-w 𝑠′: 𝑇2 𝑇1 𝑇3 s ∈ CSR
  17. 17. History 例(2) 𝑠: 𝑟2 𝑦 𝑤1 𝑦 𝑤1 𝑥 𝑐1 𝑤2 𝑥 𝑐2 17 𝑇1𝑇2 y: r-w z: w-w s ∉ CSR
  18. 18. 2PL • Two-phase locking protocol • Growing phase と Shrinking phase に分かれる • 2PL で作られた history は CSR 18 Locks of a transaction time
  19. 19. Recoverability • CSR だけだとクラッシュリカバリーできない • Recoverability (RC) • Tx1 が write している data item を read しようと する Tx2 は Tx1 が commit/abort するまでそれを 待つ必要がある • 𝑠: 𝑟1 𝑥 𝑤1 𝑦 𝑟2 𝑦 𝑤2 𝑧 𝑐2 𝑎1 • これは CSR だけど RC ではない • Tx2 が commit した後に Tx1 が abort してしまうと、 Tx2 が依存していた書き込みがなかったことになっ てしまう: dirty read したことになる 19
  20. 20. Strictness • Recoverability だけだと不便 • abort するときに他の Tx を巻き込みたくない (cascading aborts 含む) • Strictness (ST) • Tx1 が write している data item を read/write しよ うとする Tx2 は Tx1 が commit/abort するまでそ れを待つ必要がある • Abort するときは自分の変更をundoするだけで良い • Recoverability よりも強い制約 20
  21. 21. S2PL • Strict 2PL • S2PL は 2PL に含まれる • write lock は Tx 終了時に一気に開放する • S2PL によって作られる history は CSR ∩ ST 21 Locks of a transaction time
  22. 22. 2PL と S2PL の違い • 𝑠: 𝑟1 𝑥 𝑤1 𝑦 𝑟2 𝑦 𝑤2 𝑧 𝑎1 𝑐2? • 2PL だが S2PL ではない • T1 の abort したら T2 は rollback の必要あり • 𝑠: 𝑟1 𝑥 𝑤1 𝑦 𝑎1 𝑟2 𝑦 𝑤2 𝑧 𝑐2 • これは S2PL • 他 Tx の abort に影響されない/しない 22
  23. 23. Rigorousness • Rigorousness (RG) • Tx1 が read/write している data item を read/write しようとする Tx2 は Tx1 が commit/abort するま でそれを待つ必要がある • Strictness よりも強い制約 • 比較 • Strictness (ST): Tx1 が write している data item を read/write しようとする Tx2 は Tx1 が commit/abort するまでそれを待つ必要がある • Recoverability (RG): Tx1 が write している data item を read しようとする Tx2 は Tx1 が commit/abort するまでそれを待つ必要がある 23
  24. 24. SS2PL • Strong S2PL • SS2PL は S2PL に含まれる • 全ての lock を Tx 終了時に一気に開放する • SS2PL によって作られる history は Rigorous 24 Locks of a transaction time
  25. 25. S2PL と SS2PL の違い • 𝑠: 𝑟1 𝑥 𝑟2 𝑧 𝑤1 𝑦 𝑤2 𝑥 𝑐2 𝑐1 • S2PL だが SS2PL ではない • 𝑠: 𝑟1 𝑥 𝑟2 𝑧 𝑤1 𝑦 𝑐1 𝑤2 𝑥 𝑐2 • これなら SS2PL • S2PL: serialized order != commit order • r-w 関係だけは commit order が入れ替わり得る • SS2PL: serialized order = commit order • SS2PL でないと困るケースは??? 25
  26. 26. History 制約の関係図 • RG ⊂ ST ⊂ RC • RG ⊂ CSR • gen(2PL) ⊂ CSR • gen(S2PL) ⊆ CSR ∩ ST • gen(SS2PL) = RG 26 Transactional Information System. Figure 11.1 を参照 CSR RC ST RG
  27. 27. 詳細はこの本を参照のこと • Transactional Information Systems: Theory, Algorithms, and the Practice of Concurrency Control and Recovery • Gerhard Weikum, Gottfried Vossen • 2001 27
  28. 28. Concurrency Control 手法/研究の紹介 28
  29. 29. Concurrency Control の歴史 29 Silo (FOEDUS) MOCC Leis 2PL SI SSN TicToc (Dreadlock) 1980 2015201020001990 SSI wait-die OCC wound-wait T/O Pessimistic Locking (Deadlock Avoidance) 大まかな分類 Timestamp Ordering Snapshot Isolation Optimistic CC (ERMIA (Orthrus)
  30. 30. Deadlock • wait-for graph が cycle を持つと deadlock • 素の 2PL や S2PL はアプリケーション側で気を つけないと簡単に deadlock する 30 𝑤2(𝑦) 𝑤1(𝑦)𝑤1(𝑥) 𝑤2(𝑥) 𝑇1 𝑇2 𝑥 𝑦 𝑇1 𝑇2
  31. 31. Deadlock Resolution • Naive • Lock-wait timeout に任せる • Deadlock detection • Wait-for graph (WFG) の cycle を発見、切断 • Deadlock prevention • Cycle が発生する可能性を排除するプロトコル 31
  32. 32. Deadlock Prevention • No-wait (Bernstein, et al. 1981?) • lock-wait せず、trylock 失敗したら即 abort (retry) • Wait-die (Rosenkranz, et al. 1978) • 優先順位が高い Tx は wait、それ以外は abort • 実装簡単、最近の論文でもよく比較対象になる • Wound-wait (Rosenkranz, et al. 1978) • 優先順位が高い Tx が低い Tx の lock を奪う、 それ以外は wait • Google Spanner で使われているらしい • Leis lock (Leiserson 2015) • Relock することで無理矢理 lock order を揃える 32
  33. 33. Wait-die (Rosenkranz, et al. 1978) • 競合した場合、優先順位が高い Tx は lock wait できる が、優先順位が低い Tx は即 abort • Starvation (永遠に abort/retry) のリスクがある 33 0 1 2 3 0 1 2 3 T1 locks 1, T2 locks 2 and 3 0 1 2 3 0 1 2 3 Time T1 waits 3 T2 cannot wait 1 locked by T1, and aborts T1 locks 3 Priority: T1 > T20 1 2 3
  34. 34. Wound-wait (Rosenkranz, et al. 1978) • 競合した場合、優先順位が高い Tx が 低い Tx を wound (傷つける) することで deadlock 防止 • 先着の Tx に高い優先度を与えて starvation 防止可能 • どうやって wound するの? 34 0 1 2 3 0 1 2 3 T1 locks 1, T2 locks 2 and 3 0 1 2 3 Time T2 waits 1, T1 wounds T2 to lock 3 T2 aborts to retry, T1 locks 3 Priority: T1 > T20 1 2 3
  35. 35. Leis Lock (Leiserson, 2015) • Progress 保証はある • Long Tx になればなるほど retry が増え非効率 • アクセスレコード数 𝑛 に対して lock 回数 𝑂(𝑛2) 35 0 1 2 3 4 0 1 2 3 4 Lock 1 0 1 2 3 4 Try lock 3  failed  remember and unlock all  retry 0 1 2 3 4 0 1 2 3 4 Time Lock 4 Lock 1, 3, 4 in order at the beginning
  36. 36. Serializability の緩和 • Read committed • read は読み込むときのみ lock する (2PL を破る) • write は S2PL に従う • lost-update anomalies 𝑟1 𝑥 𝑟2 𝑥 𝑤2 𝑥 𝑐2 𝑤1 𝑥 𝑐1 • Repeatable read • 複数回読まれた data item は常に同じ値となる • Phantom problem 対策をしない • その他諸々 • 実装によって微妙に定義が異なると思う 36
  37. 37. Phantom Problem • Data item が insert される、かつ、range query が存在する系 • データ構造に存在していない data item は lock できないので、他 Tx によって insert された item を range query で読んでしまう • 対応策 • table lock • predicate lock • gap lock • node verify (OCC) 37 0 1 3 0 1 32 0 1 32 Inserted [0, 1, 3] [0, 1, 2, 3] Range query
  38. 38. Snapshot Isolation (SI) • Multiversion が前提 • Tx 開始時点での最新 committed version を read • write set は Tx 毎に分割(disjoint) • Serializable ではない • write-skew anormalies • read-only anormalies 38
  39. 39. SI を serializable に • SSI (Serializable snapshot isolation, 2008) • TDG cycle に繋がる dangerous structure を排除 • SSN (Serial safety net, 2015) • SSI より効率的に cycle の可能性を排除 39
  40. 40. OCC • Optimistic Concucrrency Control • 1981 に最初の論文 • Silo (2013) で many-core 向けに refine • 何が楽観的か? • Lock せずに read して、後で verify する • Invisible read が可能 40
  41. 41. Silo-OCC (Tu, et al. 2013) • Scalable な record version (=TxID) 決定機構 • (Optional) old record version のメンテナンスにより read-only snapshot transactions をサポート • Snapshot Isolation より緩い 41 multiple read/write commit proc reply client client pre-commit optimistic read read/write/node set 管理 write lock (sorted) read verify write set の反映 unlock
  42. 42. Silo-OCC 性能 42 Global TxID だとスケールしない Partition store よりも locality が小さいときに優位
  43. 43. TicToc (Yu, et al. 2016) • Timestamp ordering (T/O, 197X) ベース • if 𝑝𝑖 𝑥 and 𝑞 𝑗 𝑥 , 𝑖 ≠ 𝑗, are operations in conflict, 𝑝𝑖 𝑥 is executed before 𝑞 𝑗 𝑥 iff 𝑡𝑠 𝑡𝑖 < 𝑡𝑠(𝑡𝑗) • T/O の生成する history は CSR • 特徴 • 結果的に version (timestamp) が決まるので、 commit 時の順序と Tx 依存関係 (version) が前後 • Optimistic read するが version 更新のため必ずしも invisible read ではない 43
  44. 44. TicToc 性能 44
  45. 45. OCC の Pros/Cons • Pros • CSR (+ST) • invisible read によりキャッシュを汚さない • TicToc は汚す • deadlock-free • Cons • 競合が激しい data item で abort 率が高くなる • long Tx は難しい 45
  46. 46. MOCC (Wang, et al. 2017) • 温度管理により pessimistic locking と optimistic read を適応的に選択 • Deadlock prevention 装備 • Lock order を強引に揃える (release --> relock) • Leis2015 と類似 • Central data structure ナシ (スケールする) • Snapshot transaction もある • 最強に見える • Write を含む long Tx を考えなければ 46
  47. 47. MOCC 性能 47 TPC-C でスループットはスケール High-conflicts で性能が落ちない
  48. 48. まとめ • Serializability • CSR, RC/ST/RG • 2PL, S2PL, SS2PL • Concurrency Control の手法紹介 • Deadlock Resolution • Snapshot Isolation • OCC • などなど 48
  49. 49. 参考文献 (1) • Transactional Information Systems (2001) • Gerhard Weikum, Gottfried Vossen • Deadlock avoidance • System level concurency control for distributed database systems (Rose1978, wait-die/wound-wait) • Concurency Control in Distributed Database Systems (Bern1981, no-wait) • A Simple Deterministic Algorithm for Guaranteeing the Forward Progress of Transactions (Leis2015) 49
  50. 50. 参考文献 (2) • OCC • Speedy Tranasction in Multicore In-Memory Databases (Tu2013, Silo) • TicToc: Time Traveling Optimistic Concurency Control (Yu2016) • Mostly-Optimistic Concurrency Control for Highly Contended Dynamic Workloads on a Thousand Cores (Wang2017, MOCC) • SI • Making Snapshot Isolation Serializable (Feke2005) • The Serial Safety Net: Efficient Concurrency Control on Modern Hardware (Wang2015) 50

×