Download as PDF, PPTX
![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](https://image.slidesharecdn.com/hoshino-cc-20170120a-170120064123/75/rev-2-37-2048.jpg)
More Related Content
トランザクションの並行実行制御 rev.2
- 1.
- 2. 自己紹介 • 星野 喬 •サイボウズ・ラボ • 今の仕事 • WalB の開発(ストレージバックアップ) http://walb-linux.github.io/ • などなど • 今の興味 • トランザクションシステム 2
- 3. サイボウズ の紹介 • チームあるところにサイボウズあり •多様性/公明正大/理想への共感/自立と議論の文化 • 製品、サービス • Office/Garoon: カレンダー、ワークフローなど • kintone: LowCode Developing (WebDB＋α) • メールワイズ: チームでメール対応 (サポートetc) • Live: 無料、少人数/一時的なチーム向け • 特徴 • 「場」+データ＋コミュニケーション • アクセス権などしっかり(エンタープライズも安心) 3
- 4. • 「次世代の製品・サービスの基盤となる技術を 中長期視点で研究開発しています」 • サイボウズの100%子会社 •サイボウズ東京オフィスに開発本部と同居 • 採用募集もしています 4
- 5. 採用/インターン/ラボユース • 本社エンジニア採用 • インフラ周りでコード書ける人:SRE チームへ！ • Web/App コード書ける人: 開発本部へ！ • その他も含めて新卒/中途問わず募集中 • https://cybozu.co.jp/company/job/recruitment/ • 開発インターン • 新卒向けの就業体験です (夏休み 1〜2週間) • ラボユース • 学業の合間に好きなOSSコード書いて給料出ます • ラボメンバーがメンターとして付きます • http://labs.cybozu.co.jp/youth.html 5
- 6. 今日の話 • トランザクション • Serializability＋α •Concurrency Control 手法/研究の紹介 6
- 7. トランザクション • それ以上分割できない処理単位 • ACID特性を満たす • Atomicity • Consistency • Isolation • Durability 7
- 8. Isolation • 分離性、独立性 • Txが混ざるのを避けたい: • 他の Tx の実行中状態を見たくない • どちらがどちらに依存しているか分からない • etc. • 何を満足すれば良いか？ • Serializability 8
- 9. Concurrency Control の目的 •出来るだけ並行に処理したい • システムの並列性を生かして性能を出したい • Serializable に実行したい • 性能のために妥協することはあるかも 9
- 10. トランザクション実行の流れ 10 multiple read/write commitproc 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. トランザクションシステム 三大要素 • Data Structure •インデクス構造、key から value に到達する手段 • WAL (Write-Ahead Logging) • 永続化制御のための仕組み • Cocurrency Control • 性能を出すため良い性質を保ったまま並行実行 • これにデータ処理(filter, sort, join など)、SQLパーサや オプティマイザなどを載せると Relational DBMS の出 来上がり！ 11
- 12.
- 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. Serializability • 簡単に言うと、 Serial historyと同等の history 集合 • 「同等の」って何？ • 最終結果が同じ？ (FSR) • どの時点でも中間状態が同じ？ (VSR) • 部分的に比較しても同じ？(Monotonicity) • 競合の仕方が同じ？ (CSR) • 皆、良い性質を持っている CSR を使う 14
- 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. 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. History 例(2) 𝑠: 𝑟2𝑦 𝑤1 𝑦 𝑤1 𝑥 𝑐1 𝑤2 𝑥 𝑐2 17 𝑇1𝑇2 y: r-w z: w-w s ∉ CSR
- 18. 2PL • Two-phase lockingprotocol • Growing phase と Shrinking phase に分かれる • 2PL で作られた history は CSR 18 Locks of a transaction time
- 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. Strictness • Recoverability だけだと不便 •abort するときに他の Tx を巻き込みたくない (cascading aborts 含む) • Strictness (ST) • Tx1 が write している data item を read/write しよ うとする Tx2 は Tx1 が commit/abort するまでそ れを待つ必要がある • Abort するときは自分の変更をundoするだけで良い • Recoverability よりも強い制約 20
- 21. S2PL • Strict 2PL •S2PL は 2PL に含まれる • write lock は Tx 終了時に一気に開放する • S2PL によって作られる history は CSR ∩ ST 21 Locks of a transaction time
- 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. 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. SS2PL • Strong S2PL •SS2PL は S2PL に含まれる • 全ての lock を Tx 終了時に一気に開放する • SS2PL によって作られる history は Rigorous 24 Locks of a transaction time
- 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. 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. 詳細はこの本を参照のこと • Transactional Information Systems: Theory,Algorithms, and the Practice of Concurrency Control and Recovery • Gerhard Weikum, Gottfried Vossen • 2001 27
- 28.
- 29. Concurrency Control の歴史 29 Silo (FOEDUS) MOCC Leis 2PL SISSN 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. Deadlock • wait-for graphが cycle を持つと deadlock • 素の 2PL や S2PL はアプリケーション側で気を つけないと簡単に deadlock する 30 𝑤2(𝑦) 𝑤1(𝑦)𝑤1(𝑥) 𝑤2(𝑥) 𝑇1 𝑇2 𝑥 𝑦 𝑇1 𝑇2
- 31. Deadlock Resolution • Naive •Lock-wait timeout に任せる • Deadlock detection • Wait-for graph (WFG) の cycle を発見、切断 • Deadlock prevention • Cycle が発生する可能性を排除するプロトコル 31
- 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. Wait-die (Rosenkranz, etal. 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. Wound-wait (Rosenkranz, etal. 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. 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. Serializability の緩和 • Readcommitted • read は読み込むときのみ lock する (2PL を破る) • write は S2PL に従う • lost-update anomalies 𝑟1 𝑥 𝑟2 𝑥 𝑤2 𝑥 𝑐2 𝑤1 𝑥 𝑐1 • Repeatable read • 複数回読まれた data item は常に同じ値となる • Phantom problem 対策をしない • その他諸々 • 実装によって微妙に定義が異なると思う 36
- 37. Phantom Problem • Dataitem が 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. Snapshot Isolation (SI) •Multiversion が前提 • Tx 開始時点での最新 committed version を read • write set は Tx 毎に分割(disjoint) • Serializable ではない • write-skew anormalies • read-only anormalies 38
- 39. SI を serializableに • SSI (Serializable snapshot isolation, 2008) • TDG cycle に繋がる dangerous structure を排除 • SSN (Serial safety net, 2015) • SSI より効率的に cycle の可能性を排除 39
- 40. OCC • Optimistic ConcucrrencyControl • 1981 に最初の論文 • Silo (2013) で many-core 向けに refine • 何が楽観的か？ • Lock せずに read して、後で verify する • Invisible read が可能 40
- 41. Silo-OCC (Tu, etal. 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. Silo-OCC 性能 42 Global TxIDだとスケールしない Partition store よりも locality が小さいときに優位
- 43. TicToc (Yu, etal. 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.
- 45. OCC の Pros/Cons •Pros • CSR (+ST) • invisible read によりキャッシュを汚さない • TicToc は汚す • deadlock-free • Cons • 競合が激しい data item で abort 率が高くなる • long Tx は難しい 45
- 46. MOCC (Wang, etal. 2017) • 温度管理により pessimistic locking と optimistic read を適応的に選択 • Deadlock prevention 装備 • Lock order を強引に揃える (release --> relock) • Leis2015 と類似 • Central data structure ナシ (スケールする) • Snapshot transaction もある • 最強に見える • Write を含む long Tx を考えなければ 46
- 47.
- 48. まとめ • Serializability • CSR,RC/ST/RG • 2PL, S2PL, SS2PL • Concurrency Control の手法紹介 • Deadlock Resolution • Snapshot Isolation • OCC • などなど 48
- 49. 参考文献 (1) • TransactionalInformation 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. 参考文献 (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