トランザクションの並行処理制御

星野喬＠サイボウズ・ラボ

情報システム特別講義D

2017-01-20

1

自己紹介

•星野 喬• サイボウズ・ラボ

•今の仕事• WalB の開発(ストレージバックアップ)

http://walb-linux.github.io/

• などなど

•今の興味• トランザクションシステム

2

サイボウズの紹介

•チームあるところにサイボウズあり• 多様性/公明正大/理想への共感/自立と議論の文化

•製品、サービス• Office/Garoon: カレンダー、ワークフローなど

• kintone: LowCode Developing (WebDB＋α)

• メールワイズ: チームでメール対応 (サポートetc)

• Live: 無料、少人数/一時的なチーム向け

•特徴• 「場」+データ＋コミュニケーション

• アクセス権などしっかり(エンタープライズも安心)

3

•「次世代の製品・サービスの基盤となる技術を中長期視点で研究開発しています」

•サイボウズの100%子会社

•サイボウズ東京オフィスに開発本部と同居

•採用募集もしています

4

採用/インターン/ラボユース

•本社エンジニア採用• インフラ周りでコード書ける人: SRE チームへ！

• Web/App コード書ける人: 開発本部へ！

• その他も含めて新卒/中途問わず募集中• https://cybozu.co.jp/company/job/recruitment/

•開発インターン• 新卒向けの就業体験です (夏休み 1〜2週間)

•ラボユース• 学業の合間に好きなOSSコード書いて給料出ます

• ラボメンバーがメンターとして付きます• http://labs.cybozu.co.jp/youth.html

5

今日の話

•トランザクション

• Serializability＋α

• Concurrency Control 手法/研究の紹介

6

トランザクション

•それ以上分割できない処理単位

• ACID 特性を満たす• Atomicity

• Consistency

• Isolation

• Durability

7

Isolation

•分離性、独立性

• Tx が混ざるのを避けたい:• 他の Tx の実行中状態を見たくない

• どちらがどちらに依存しているか分からない

• etc.

•何を満足すれば良いか？• Serializability

8

Concurrency Control の目的

•出来るだけ並行に処理したい• システムの並列性を生かして性能を出したい

• Serializable に実行したい• 性能のために妥協することはあるかも

9

トランザクション実行の流れ

10

multiple read/write commit proc reply

abort proc

client client

lock による排他old version の read

deadlock prevensionread/write set 管理

etc.

log を書いて永続化

データベース本体は後でゆっくり永続化

Concurrency Control の主な仕事何をするかは方式によって異なる

(pre-commit)

lock による排他

read verify (OCC)deadlock detectionetc.

トランザクションシステム三大要素

• Data Structure• インデクス構造、key から value に到達する手段

• WAL (Write-Ahead Logging)• 永続化制御のための仕組み

• Cocurrency Control• 性能を出すため良い性質を保ったまま並行実行

• これにデータ処理(filter, sort, join など)、SQLパーサやオプティマイザなどを載せると Relational DBMS の出来上がり！

11

Serializability＋α

12

用語

• 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

Serializability

•簡単に言うと、Serial history と同等の history 集合

•「同等の」って何？• 最終結果が同じ？ (FSR)

• どの時点でも中間状態が同じ？ (VSR)

• 部分的に比較しても同じ？(Monotonicity)

• 競合の仕方が同じ？ (CSR)

•皆、良い性質を持っている CSR を使う

14

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

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

History 例(2)

𝑠: 𝑟2 𝑦 𝑤1 𝑦 𝑤1 𝑥 𝑐1𝑤2 𝑥 𝑐2

17

𝑇1𝑇2

y: r-w

z: w-w

s ∉ CSR

2PL

• Two-phase locking protocol

• Growing phase と Shrinking phase に分かれる

• 2PL で作られた history は CSR

18

Locks of a transaction

time

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

Strictness

• Recoverability だけだと不便• abort するときに他の Tx を巻き込みたくない

(cascading aborts 含む)

• Strictness (ST)• Tx1 が write している data item を read/write しようとする Tx2 は Tx1 が commit/abort するまでそれを待つ必要がある

• Abort するときは自分の変更をundoするだけで良い

• Recoverability よりも強い制約

20

S2PL

• Strict 2PL

• S2PL は 2PL に含まれる

• write lock は Tx 終了時に一気に開放する

• S2PL によって作られる history は CSR ∩ ST

21

Locks of a transaction

time

2PL と S2PL の違い

• 𝑠: 𝑟1 𝑥 𝑤1 𝑦 𝑟2 𝑦 𝑤2 𝑧 𝑎1𝑐2?• 2PL だが S2PL ではない

• T1 の abort したら T2 は rollback の必要あり

• 𝑠: 𝑟1 𝑥 𝑤1 𝑦 𝑎1𝑟2 𝑦 𝑤2 𝑧 𝑐2• これは S2PL

• 他 Tx の abort に影響されない/しない

22

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

SS2PL

• Strong S2PL

• SS2PL は S2PL に含まれる

•全ての lock を Tx 終了時に一気に開放する

• SS2PL によって作られる history は Rigorous

24

Locks of a transaction

time

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

History 制約の関係図

• RG ⊂ ST ⊂ RC

• RG ⊂ CSR

• gen(2PL) ⊂ CSR

• gen(S2PL) ⊆ CSR ∩ ST

• gen(SS2PL) = RG

26Transactional Information System. Figure 11.1 を参照

CSR

RC ST RG

詳細はこの本を参照のこと

• Transactional Information Systems: Theory, Algorithms, and the Practice of Concurrency Control and Recovery

• Gerhard Weikum,Gottfried Vossen

• 2001

27

Concurrency Control 手法/研究の紹介

28

Concurrency Control の歴史

29

Silo

(FOEDUS)

MOCC

Leis2PL

SI SSN

TicToc

(Dreadlock)

1980 2015201020001990

SSI

wait-die

OCC

wound-wait

T/O

PessimisticLocking

(DeadlockAvoidance)

大まかな分類

TimestampOrdering

SnapshotIsolation

OptimisticCC

(ERMIA)

(Orthrus)

Deadlock

• wait-for graph が cycle を持つと deadlock

•素の 2PL や S2PL はアプリケーション側で気をつけないと簡単に deadlock する

30

𝑤2(𝑦)

𝑤1(𝑦)𝑤1(𝑥)

𝑤2(𝑥)

𝑇1

𝑇2

𝑥

𝑦

𝑇1 𝑇2

Deadlock Resolution

• Naive• Lock-wait timeout に任せる

• Deadlock detection• Wait-for graph (WFG) の cycle を発見、切断

• Deadlock prevention• Cycle が発生する可能性を排除するプロトコル

31

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

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

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

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

Serializability の緩和

• Read committed• read は読み込むときのみ lock する (2PL を破る)

• write は S2PL に従う

• lost-update anomalies 𝑟1 𝑥 𝑟2 𝑥 𝑤2 𝑥 𝑐2𝑤1 𝑥 𝑐1

• Repeatable read• 複数回読まれた data item は常に同じ値となる

• Phantom problem 対策をしない

•その他諸々

•実装によって微妙に定義が異なると思う

36

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

Snapshot Isolation (SI)

• Multiversion が前提

• Tx 開始時点での最新 committed version をread

• write set は Tx 毎に分割(disjoint)

• Serializable ではない• write-skew anormalies

• read-only anormalies

38

SI を serializable に

• SSI (Serializable snapshot isolation, 2008)• TDG cycle に繋がる dangerous structure を排除

• SSN (Serial safety net, 2015)• SSI より効率的に cycle の可能性を排除

39

OCC

• Optimistic Concucrrency Control

• 1981 に最初の論文

• Silo (2013) で many-core 向けに refine

•何が楽観的か？• Lock せずに read して、後で verify する

• Invisible read が可能

40

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 readread/write/node set 管理

write lock (sorted)read verifywrite set の反映

unlock

Silo-OCC 性能

42

Global TxID だとスケールしない Partition store よりもlocality が小さいときに優位

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

TicToc 性能

44

OCC の Pros/Cons

• Pros• CSR (+ST)• invisible read によりキャッシュを汚さない

• TicToc は汚す

• deadlock-free

• Cons• 競合が激しい data item で abort 率が高くなる

• long Tx は難しい

45

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

MOCC 性能

47

TPC-C でスループットはスケール

High-conflicts で性能が落ちない

まとめ

• Serializability• CSR, RC/ST/RG

• 2PL, S2PL, SS2PL

• Concurrency Control の手法紹介• Deadlock Resolution

• Snapshot Isolation

• OCC• などなど

48

参考文献 (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

参考文献 (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