2013/4/4

1. Transactional
Information Systems 入門
株式会社プリファードインフラストラクチャー
2013 年 4 月 4 日 久保田展行 (@nobu_k)

2. 自己紹介
 久保田展行 (@nobu_k)
 作っているもの
 Sedue 、 Bazil
 ( ソフト ) リアルタイム検索部分の改良
 興味のある分野
 分散システム : コンセンサス、レプリケーション
 DB: インデックス、ストレージ、トランザクション
 Red Bull 中毒解消、 2013 年はまだ 1 ブル
2

3. 経緯とか
3

4. トランザクション処理とは
 すごくおおざっぱに言うとデータの整合性を保つための技術
 銀行や ATM でのお金のやりとり

不整合で困る例 : お金を振り込んだけど残高が増えなかった
 EC サイトでの購買履歴・在庫管理

不整合で困る例 : お金払ったけど商品が届かなかった
 通常 DBMS に実装されたトランザクション処理機能が利用される
 いわゆる三層アーキテクチャみたいなやつ
4

5. トランザクション処理と DBMS
 トランザクション処理技術は DBMS でも重要な分野の一つ
 むしろこれがないと DBMS を使う価値がないレベル
 DBMS に限定された話ではないが
 学習難易度も実装の難易度も高め
 DBMS 全体を扱っている本に書かれた情報だけでは不十分
 トランザクションの専門書が求められる・・・！
 当然出ている

歴史が長い分野でよかった
5

6. トランザクションの本と言えば
 主にシステム・実装の話
 なぜこれでうまくいくのか、という部分が弱い
 ニッチなので高価、そして絶版・・・
6

7. Transactional Information Systems
 トランザクションの理論を解説した神書
 それでいて実践的な面もカバー
 厚い、重い、難しい、ニッチなので高価
 斉藤さん (@taroleo さん ) のブログで知る
 http://leoclock.blogspot.jp/2009/01/blog-post_07.html
 DBMS の内部にものすごく興味を持ち始めた時期

今の Sedue を実装中 @PFI アルバイト期間
 入社直後、西川さんと読んでみようということに
 西川さんがコピー機で 800 ページ手動スキャンしてて吹いた
 これがベンチャー社長のエネルギーか・・・！
7

8. 挫折
 3 章を超えられない・・・
 分からないとこを放置して 4 章に行っても全部理解できない
 半年に一回くらい読み直して見るも心が持たない
8 3 章より抜粋

9. TX 本読書会の機運
 2011 年夏、他の本 (Replication) の読書会をしてた
 やはり複数人で読むと心が折れづらい
 この本もみんなで読みたい・・・
 Twitter や勉強会で話を持ちかけてみる
 Hadoop 界隈というか主に @okachimachiorz さんから反応がｗ
 他にも興味を示す人がちらほら！意識高い
 2011/9 から開始 @ ノーチラス・テクノロジーズ
 以降 2 週に 1 回のペースで読書会を続けている
 今は毎回 4 〜 5 人
 複数人で議論しながら読むことで理解が深まり、誤り訂正も働く
 現在開始から 1 年半、残り 80 ページくらい！長かった
9

10. アジェンダ
 Transactional Information Systems の紹介
 3 、 4 章の壁を越えるための話・・・をしたかった
 どういう感じの本か雰囲気だけでも味わって貰えれば
 トランザクションとは何か
 理論的に考えるために必要な道具の準備
 「正しさ」の定義
 トランザクションの制御
 残りの話題
 本全体の紹介
10

11. トランザクションとは
11

12. トランザクションとは
 複数のデータに対して読み書きを行う命令の列
 トランザクション処理には次のような要件が求められる
 複数トランザクションの効率的な並行 ( 場合によっては並列 ) 実行
 耐障害性の保証
 さらに、 ACID という性質を満たすことが要求される
12
BEGIN TRANSACTION
A の口座から 1 万円引き落とし
B の口座へ 1 万円振り込み
COMMIT TRANSACTION
BEGIN TRANSACTION
A の口座から 1 万円引き落とし
1 万円なかった・・・！
ROLLBACK TRANSACTION

13. トランザクションに求められる性質 : ACID
 Atomicity ( 原子性 )
 Consistency preservation ( 一貫性 )
 Isolation ( 分離性 )
 Durability or Persistence ( 持続性 )
 ”日本語は トランザクション処理 ( 上 )” より
13

14. Atomicity
 All or nothing
 中途半端な状態が外部に見えないし、残らない
 途中で Rollback/Abort したら何も残らない
 ”プログラミングで言う、“強い例外安全 に求められる要件
 複数のレコードを一度に書き換えたいときに便利
 Single row transaction( 笑 )
 途中で障害が起きた場合の対処も ( 大抵は ) 考える必要無し
14
BEGIN TRANSACTION
A の口座から 1 万円引き落とし
--- ここで障害発生 ---
B の口座へ 1 万円振り込み
COMMIT TRANSACTION
--- 再起動 ---
A の口座は元の金額に
BEGIN TRANSACTION
A の口座から 1 万円引き落とし
B の口座へ 1 万円振り込み
COMMIT TRANSACTION
--- ここで障害発生 ---
再起動後、結果はすべて残る

15. Consistency preservation
 制約を守りながらデータを変更する手段を提供
 トランザクション中は一時的にデータに矛盾が起こる
 A さんの口座から B さんの口座にデータを移動
 一時的にどっちかの口座の金額だけ変化した状態になる
 Commit したときに制約が守られていれば良い
 制約を守れなかったら Abort しても、 Atomicity のおかげで問題な
し
 制約を DBMS に記述することで、データの変更と検証を atomic に
 これにより、 consistent な状態を維持できる
15

16. Isolation
 並行実行中のトランザクション間で状態が共有されない
 同時実行しても不整合が起こらない
 未コミットの状態を参照できない
 送金中に銀行全体の預金残高を集計しても合計値に矛盾が起きない
 アプリケーションでは、並行性を考えずに処理を記述できる
16

17. Durability/Persistence
 コミット済みのトランザクションの結果を永続化
 さらに障害が起きても、コミット済みの結果は維持される
 障害発生時点での未コミット分は Atomicity により無かったことに
 アプリケーションに対して障害を隠蔽する
17

18. 安全なトランザクションをどうやって実現するか
 ACID の性質を満たしながら、効率的なトランザクション処理
を・・
 ACID を前提にできると、アプリケーションの記述が簡単に
 まずは議論するための道具が必要
 トランザクションをどうモデル化するのか
 そもそも「正しいトランザクション」とは何か
 あるトランザクションが正しいことをどう判断するのか
 トランザクションが正しくなるようにどう制御するのか
18

19. ( 豪快な ) 準備
19

20. 最初に必要な道具
 データ操作の表記
 データをどのように定義するか
 データの読み書きをどのように記述するか
 トランザクションの表記とセマンティクス
 トランザクション ( 操作の集合 ) をどう記述するか
 命令の列をどう解釈するか
 複数のトランザクションを寄せ集めての表記
 並行実行されているトランザクションをどう書くか
 本当は厳密に書いてあるが、時間の関係で豪快に説明
20

21. Page Model
 DBMS のデータ操作はストレージ ( 主に HDD) への Read/Write
 読み書きの単位はページ ( セクタ )
 必要な情報はページの一部でも、ページが操作の最小単位
 データ : D = {x, y, z, …}
 小文字で表記する
 操作
 読み込み : r(x)

x からデータを読み込み
 書き込み : w(x)

x にデータを書き込み
21

22. トランザクションの表記とセマンティクス
 R/W の列で記述
 例 : t = r(x)r(y)w(x)w(y)c
 トランザクション内での R/W の解釈
 r_i(x): v_i := x

ローカル変数のようなものを用意し、そこに x の値を読み込む
 w_i(x): x := f(v_j1, v_j2, …, v_jk)

今までに読んだすべての値を使って書き込む値を計算

文脈の情報に依存せず、できる限り一般的に記述
 操作の順序づけ
 1 つのトランザクション内での操作には全順序が付いているとする
 本当は半順序で考えると良いが、話が複雑になるため

r/r や依存関係のない r/w は前後で順序を入れ替えても問題ない
22

23. ヒストリー・スケジュール
 複数のトランザクションをインターリーブしたもの
 t1 = r1(x)r1(y)w1(x)c1
 t2 = r2(y)w2(x)c2
 H = r1(x)r1(y)r2(y)w2(x)c2w1(x)c1
 本当はもうちょっと細かい条件が付く
 1 つのトランザクションは a(abort) か c のどちらか一方が含まれる
 a/c は各トランザクションの末尾のみに入る
 あとは順序の話など・・・
 スケジュールは、ヒストリーの接頭辞 (prefix)
 未完了のトランザクションが含まれる
23

24. 正しさの定義
24

25. 問題が起こるスケジュール ( ヒストリー )
 まずは、正しくないトランザクションが抱える問題を知る
 Lost-update
 Inconsistent-read
 Dirty-read
 他にも
 Nonrepeatable read
 Phantom read
 Read/write-skew
25

26. Lost-update
26
P.62 より

27. Inconsistent-read
27
sum = 190 x = 90
y = 110
x = y = 100
P.63 より

28. Dirty-read
28
4 で未コミットの値を読んでいるため、 rollback で問題発生。
3 章では abort/rollback を扱わないので、対処方法は Part 3 までお預け。
P.64 より

29. 問題が起こらないスケジュール : Serial schedule
 トランザクション同士が混ざり合わないスケジュール
 t1 = r1(x)w1(x)c
 t2 = r2(x)w2(x)c
 t3 = r3(x)w3(x)c
 s = t1t2t3 = r1(x)w1(x)c1r2(x)w2(x)c2r3(x)w3(x)c3

他にも t1t3t2, t2t1t3, t2t3t1, t3t1t2, t3t2t1
 このようなスケジュールをシリアルスケジュールと呼ぶ
 トランザクションを個別実行すれば、相互に悪影響を及ぼさない
 しかし、シリアルスケジュールにはパフォーマンスの問題がある
 並行に実行できる部分は実行したい！
29

30. Serializability
 TX をシリアルに実行したときと等価な結果が得られるか
 数あるシリアルスケジュールのうち最低 1 つと等価である
 なにを持って等価とするか
 いくつかクラスを定義
 ” ”判定されるトランザクションの 広さ
 クラスの包含関係
30

31. Final State Serializability
 最終状態がどのように生成されたか
 最後の値がどう書かれたか、だけでは不十分
 最後の値が算出された経路をたどる必要がある
 Reads-From relation
 依存関係を表すグラフ

オペレーションが頂点

write と依存する read の間に辺が貼られる
– ただし、最終結果に反映されていないパスは取り除かれる
 このグラフが、シリアルスケジュールのものと同じか
 クラス FSR
 Final State Serializable なヒストリーが属するクラス
31

32. Reads-From relation
32
P.78 より

33. Lost-update と FSR
 s = r1(x)r2(x)w1(x)w2(x)c1c2
 w1(x) の結果は消える
 シリアル
 s’ = r1(x)w1(x)r2(x)w2(x)c1c2
 s’’ = r2(x)w2(x)r1(x)w1(x)c2c1

こちらは露骨に違う
33
s: w0(x)
r1(x)
r2(x)
w1(x)
w2(x)
r∞(x)
s’: w0(x) r1(x) w1(x) r2(x) w2(x) r∞(x)

34. FSR の問題点
 スケジュールが FSR かどうか判定するには総当たりが必要
 write 結果しか見ていないので inconsistent read を検出できない
 s = r2(x)w2(x)r1(x)r1(y)r2(y)w2(y)c1c2

t1 が t2 が書き込む前の値を参照している
 s’ = t2t1c1c2
 読み込みに関しても何らかの基準を設けないとダメ
34

35. View Serializability: VSR
 FSR で作ったグラフの、消していたパスも残したものを比較
 消していたパス→最終状態に反映されていない r/w
 VSR FSR⊂
 VSR FSR⊆ は定義より自明

比較対象のグラフに辺 ( 条件 ) が増えたので、対象が狭まる
– 広くなることはない
 VSR != FSR

w1(x)r2(x)r2(y)w1(y)c1c2

少なくとも Inconsistent-read 分が減ってる
35

36. VSR の問題点
 あるスケジュールが VSR に含まれるかの判定は NP 完全！
 もっと効率よく判定できるものは無いのか
36

37. Conflict Serializability: CSR
 ( たぶん ) 実質最強のクラス CSR
 シンプルなのに便利な性質を沢山持っている
 Conflict relation
 異なるオペレーション pi と qj(i!=j) が conflict しているとは
1. pi, qj が同じデータにアクセスしている
2. かつ、どちらかのオペレーションが write

ri(x), wj(x)

wi(x), rj(x)

wi(x), wj(x)
 conf(s) = {(p, q)|p と q が conflict している AND p < q}

p, q はオペレーション

p < q は p がスケジュール s の中で先行しているということ
37

38. Conflict equivalence と conflict graph
 Conflict equivalence とはスケジュール s, s’ に関して
 個々の TX に含まれるオペレーションと TX 内での順序関係が等しい
 conflict relation が等しい
 Conflict graph: G(s)
 トランザクションが頂点、衝突が辺の有向グラフ
 Conflict relation を元に構築

辺の方向は (p, q) なら pq
 Conflict equivalent なら conflict graph も等しい
 シリアルスケジュールには閉路ができない
38

39. クラス CSR
 シリアルスケジュールと conflict equivalent なスケジュール
 s CSR iff G(s) is acyclic∈
 G(s) は conflict graph
39
＿人人人人人人人人人人人人人人人人＿
＞ s CSR iff G(s) is acyclic∈ ＜
￣ Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ￣

40. 証明 ( の雰囲気 )
 s CSR∈  G(s) is acyclic
 s と等価なシリアルスケジュール s’ が存在する
 conf(s) = conf(s’)
 G(s’) には閉路が存在しない
 s CSR∈  G(s) is acyclic
 G(s) は acyclic 、つまりトポロジカルソート ( 全順序付け ) 可能
 G(s) に基づいて全順序付けしたシリアルスケジュールを s’ とする
 conf(s) = conf(s’) を示す
 (pi, qj) conf(s)∈ なら、 (ti, tj) E (E∈ は G(s) の辺の集合 )

順序を変えても conflict は解消されないので、 conf(s) conf(s’)⊆
 (pi’, qj’) conf(s’)∈ でも同様に (pi, qj) conf(s)∈ と分かる
 ＼ (^o^) ／
40

41. CSR VSR FSR⊂ ⊂
 続きは本で！
 すいません力尽きました
 もちろんえげつない証明付きです
41

42. トランザクションの制御
42

43. トランザクションマネージャ
 複数トランザクションを並行制御
 正しい 1 本のスケジュールを生成
 処理結果から正しさを
判定するのではない
 処理結果が正しくなる
スケジュールを生成する
 CSR なスケジュールを
生成できれば勝ち！
43
P.127 より

44. Two Phase Locking (2PL)
 ロックの取り方の話
 アクセスするすべてのページに対して ( 段階的に ) ロックを取る
 ただし、アンロックし始めてから新たにロックを取得しない
 ロックするフェーズと、アンロックするフェーズに分かれる
 2PL を利用したスケジューラから生成されるスケジュールは CSR
 ただしデッドロックするので適切な対処が必要
 こちらも続きは本で・・・！
44

45. 残りの話題
45

46. TX 本の残り
 3 ・ 4 章における残りの話題
 CSR の拡張

OCSR 、 COCSR

障害への対応やリカバリで重要になる
 楽観的並行性制御
 今日の範囲は約 180 ページ ( 全体の 1/4 弱 )
 のさらに一部
 ここだけでも死にそうなのに、残り 600 ページで何が語られるのか
 最後に本の全体像を紹介
46

47. 本の構成
 Part One: Background
 Part Two: Concurrency Control
 ここまでは Abort(Rollback) や障害を取り扱わない
 Part Three: Recovery
 Part Four: Distributed Transactions
 Part Five: Applications and Future Perspectives
47

48. Part Two: Concurrency Control
 Object model での concurrency control
 よりリッチな操作、制御を可能にするモデル
 ページ単位ではなく、操作 (method) 単位での制御が可能に
 Multiversion Concurrency Control(MVCC)
 本 : Concurrency Control and Recovery in Database Systems
 Concurrency Control on Relational Databases
 Isolation レベルを理論的に見てみる
 Snapshot isolation の話も少し
 B+ 木とロックの話、 TM の実装の話、 etc
48

49. Part Three: Recovery
 トランザクションに Abort が入ったらどうなるのか
 Abort しても大丈夫なクラスの定義
 それに基づいた Abort 可能なスケジュールの生成
 Part Two( 主に 3 、 4 章 ) の伏線が回収され感動の展開に
 ロギングの話
 データが復旧できることの保証
 フラッシュの順序、タイミングの制御
 プロトコルの構築
 実装可能なレベルの話が、理論的に構築されていく
 MVCC&Recovery の話はあまりない
49

50. Part Four: Distributed Transaction
 分散トランザクションの制御とリカバリの話
 2 Phase Commit の話だけではない
 ローカルトランザクション
 1 つのサーバで完結するトランザクション
 グローバルトランザクション
 サーバをまたいで実行されるトランザクション
 両者が入り交じった状態で serializable なスケジュールを生成する
50

51. Part Five
 20 ページちょっと
 読書会はお祭りモードになりそうな予感
 まだ読んでないよ！
51

52. まとめ
52

53. まとめ
 Transactional Information Systems の紹介
 ( いろんな意味で ) 全米が泣ける技術書
 美しい
 とりあえず CSR
 読書会のすすめ
 理解を深めるため、やる気を維持するため
 正直一人では読み切れなかった
 ピー FI の小会議室は割と読書会向き

使いたい人がいれば是非！
53

54. Copyright © 2006-2013
Preferred Infrastructure All Right Reserved.
ご静聴ありがとうございました