Recommended
More Related Content
What's hot
What's hot (20)
Similar to トランザクションの並行処理制御
Similar to トランザクションの並行処理制御 (20)
More from Takashi Hoshino
More from Takashi Hoshino (19)
トランザクションの並行処理制御
- 1. トランザクションの 並行処理制御 星野 喬＠サイボウズ・ラボ Database Lounge Tokyo #3 2016-11-29 1 rev.1
- 2. 自己紹介 • 星野 喬 • サイボウズ・ラボ • 今の仕事 • WalB の開発(ストレージバックアップ) http://walb-linux.github.io/ • 今の興味 • Concurrency control • Write-ahead Logging 2
- 3. 今日の話 • トランザクションと serializability • Concurrency Control Algorithms 3
- 4. トランザクション • それ以上分割できない処理単位 • 複数の data item に対する read/write 操作の列 • ACID 特性を満たす • Atomicity • Consistency • Isolation • Durability • 平行処理制御 (Concurrency Control, CC) が 関係するのは主に isolation 4
- 5. トランザクション実行の流れ 5 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.
- 6. Isolation • 分離性、独立性 • Tx が混ざるのを避けたい: • 他の Tx の実行中状態を見たくない • どちらがどちらに依存しているか分からない • etc. • 何を満足すれば良いか？ • Serializability 6
- 7. 用語 • Transaction (Tx) operations • 複数の data item に対する read/write と、最後に commit か abort で終了する operation 列 • 例: 𝑟1 𝑥 𝑟1 𝑦 𝑤1 𝑧 𝑐1 • History • 有限個 Tx の operations からなる集合 • 同一 data item へのアクセスは順序を持つ • 例: 𝑟1 𝑥 𝑟2 𝑦 𝑤1 𝑦 𝑟2 𝑥 𝑐1 𝑎2 • Serial history • 全 Tx が直列化された history 7
- 8. Serializability • 簡単に言うと、 Serial history と同等(equivalent)の history 集合 • 「同等の」って何？ • 最終結果が同じ？ • どの時点でも中間状態が同じ？ • 部分的に比較しても同じ？ • 厳密に議論しようとすると大変 • FSR, VSR, CSR, MVSR, MCSR, etc. • 以後、一番重要と考えられる CSR のみを議論 8
- 9. 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 が存在する、 history 集合 • Conflict Graph • Tx をノード、conflict をエッジとしたグラフ • Conflict graph が acyclic ⇔ CSR 9
- 10. History 例(1) 𝑠: 𝑟1 𝑥 𝑟2 𝑥 𝑟1 𝑧 𝑤1 𝑥 𝑤2 𝑦 𝑟3 𝑧 𝑤3 𝑦 𝑐1 𝑐2 𝑤3 𝑧 𝑐3 10 𝑇1 𝑇2 𝑇3 x: r-w z: r-w y: w-w 𝑠′: 𝑇2 𝑇1 𝑇3 s ∈ CSR
- 11. History 例(2) 𝑠: 𝑟2 𝑦 𝑤1 𝑦 𝑤1 𝑥 𝑐1 𝑤2 𝑥 𝑐2 11 𝑇1𝑇2 y: r-w z: w-w s ∉ CSR
- 12. Concurrency Control の 歴史 12 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)
- 13. Concurrency Control の目的 • 出来るだけ平行に処理したい • スループットを出したい • Serializable に実行したい • 性能のために妥協することはあるかも 13
- 14. 2PL • Two-phase locking protocol • Growing phase と Shrinking phase に分かれる • 2PL で作られた history は CSR 14 Locks of a transaction time
- 15. Recoverability • Scheduler は crash recovery も考える必要 • crash recovery できる • abort するときに他の Tx を巻き込みたくない (cascading aborts 含む) • ST (Strictness) • Tx1 が write した data item を read or write する Tx は、Tx1 が commit/abort した後に操作する • abort するときは自 Tx の変更を undo するだけで 良い 15
- 16. S2PL • Strict 2PL • S2PL は 2PL に含まれる • write lock は Tx 終了時に一気に開放する • S2PL によって作られる history は CSR かつ ST 16 Locks of a transaction time
- 17. Deadlock • wait-for graph が cycle を持つと deadlock • 素の 2PL や S2PL はアプリケーション側で気を つけないと簡単に deadlock する 17 𝑤2(𝑦) 𝑤1(𝑦)𝑤1(𝑥) 𝑤2(𝑥) 𝑇1 𝑇2 𝑥 𝑦 𝑇1 𝑇2
- 18. Deadlock Avoidance • 3 つの解決方針 • Naive • Lock-wait timeout に任せる • Deadlock detection • wait-for graph (WFG) の cycle を発見、切断 • Deadlock prevention • cycle が発生する可能性を無にするプロトコル 18
- 19. Deadlock Prevension • no-wait (Bern1981?) • lock-wait せず、trylock 失敗したら即 abort (retry) • wait-die (Rose1978) • 優先順位が高い Tx は wait、それ以外は abort • wound-wait (Rose1978) • 優先順位が高い Tx が低い Tx の lock を奪う、 それ以外は wait • Leis2015 • relock することで無理矢理 lock order を揃える 19 最近の論文で比較対象として no-wait を出しているものが多いが、 優先順位 (TID) を naive に発行しているのでアンフェアと感じる
- 20. Serializability の緩和 • Read committed • read は読み込むときのみ lock する • write は S2PL に従う • lost-update anomalies 𝑟1 𝑥 𝑟2 𝑥 𝑤2 𝑥 𝑐2 𝑤1 𝑥 𝑐1 • Repeatable read • 複数回読まれた item は常に同じ値となる • Phantom problem 対策をしない • その他諸々 20 InnoDB などでは定義が異なると思う
- 21. Phantom problem • Data item が insert される、かつ、range query が存在する系 • データ構造に存在していない data item は lock できないので、他 Tx によって insert された item を range query で読んでしまう • 対応策 • table lock • predicate lock • gap lock • node verify (OCC) 21
- 22. Snapshot Isolation (SI) • Multiversion が前提 • Tx 開始時点での最新 committed version を read • write set は Tx 毎に分割(disjoint) • Serializable ではない • write-skew anormalies • read-only anormalies 22
- 23. SI を serializable に • SSI (Serializable snapshot isolation, 2008) • TDG cycle に繋がる dangerous structure を排除 • SSN (Serial safety net, 2015) • SSI より効率的に cycle の可能性を排除 23
- 24. OCC • Optimistic Concucrrency Control • 1981 に最初の論文 • Silo (2013) で many-core 向けに refine • 何が楽観的か？ • lock せずに read して、後で verify する • invisible read が可能 24
- 25. Silo-OCC (2013) • Scalable な version (TID) 決定機構 • (Optional) old record version のメンテナンスにより read-only snapshot transactions をサポート • SI ではない 25 multiple read/write commit proc reply client client pre-commit optimistic read read/write/node set 管理 write lock (sorted) read verify write set の反映 unlock
- 26. Silo-OCC 性能 26 Global TID だとスケールしない Partition store よりも locality が小さいときに優位
- 27. TicToc (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 ではない 27
- 28. TicToc 性能 28
- 29. OCC の Pros/Cons • Pros • CSR • invisible read によりキャッシュを汚さない • TicToc は汚す • deadlock-free • Cons • 競合が激しい data item で abort 率が高くなる • long Tx は難しい 29
- 30. MOCC (2017) • 効率的な温度管理により pessimistic locking と optimistic read を adaptive に選択 • Deadlock prevension 装備 • lock order を強引に揃える (release --> relock する) • Leis2015 と類似 • Central data structure ナシ (スケールする) • Snapshot transaction もある • 最強に見える (long Tx を考えなければ) 30
- 31. MOCC 性能 31
- 32. まとめ • CSR と S2PL • その他諸々 • Deadlock avoidance • Snapshot Isolation • Timestamp Ordering • Optimistic CC • 最近の動向 • optimistic + pessimistic 良いところ取り • central data structure ナシ • (read-only を除いて) long Tx は諦め 32
- 33. 参考文献 (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) 33
- 34. 参考文献 (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) 34