Empfohlen
Weitere ähnliche Inhalte
Kürzlich hochgeladen
Kürzlich hochgeladen (8)
Empfohlen
Empfohlen (20)
トランザクション入門
- 4. Atomic Objectの実装：単一オブジェクトの場合 Lockされた期間中の一瞬で処理が行われたと想像すれば理解しやすい その（想像上の）一瞬で処理が行われた瞬間の事をLinearization Pointと呼ぶ T1 T2 Object T1の処理A T2の処理X T1の処理B 処理A 処理X 処理B 青線は論理的な時間軸
- 7. 2 Phase Lock(2PL) LockのComposabilityを活用して行けば、いくつのオブジェクトであってもLinearization Pointが作れる期間が得られるはず。 そのために、ロック確保は「獲得を続ける成長相」と「解放を続ける縮退相」の2つだけか らなるようしようというプロトコルが 2 Phase Lock T1 Object1 Object1&2&3,,,nに対する操作 Object2 Object1&2,,,n この範囲内ならどこでもいい Object3 Objectn 成長相 縮退相
- 10. トランザクションへの応用 2PLを使えばトランザクションにおける並行制御の問題は（論理的には）解決できる 全部のロックを取った状態でディスクにログを書き出せば最低限のACIDは満たせる だが遅い
- 12. トランザクションへの応用 ANSI「2PLを最強として、そこから緩めていく方向でIsolationを諦めて行けば性能と実用 性のバランスが取れるんじゃない？」 と、本気で言ったかは知らないが ANSIの提唱する4つの分離レベルからはロックの使い方が透けて見え る ● SERIALIZABLE: 2PLとGap Lock(レコードの隙間に対するロック)を使う ● REPEATABLE READ: 2PLを使う ● READ COMMITTED: Read Lockを取らない ● READ UNCOMMITTED: Write Lockすら取らない もちろんANSI自体は実装の詳細を指定していないのでこれらの記述は仕様ではない OracleなどはSERIALIZABLEでありながら高速化を追求する果てにSNAPSHOT ISOLATIONを実装
- 13. ちょっと脱線： SNAPSHOT ISOLATION 「全てのトランザクションは、開始した瞬間の一貫したスナップショットをトランザクション 中ずっと観測する。書き込み同士が衝突した場合はAbortする」 裏ではMulti Versioning Concurrency Control(MVCC)とTimestampで頑張っている。 ❖ 値を書き込む際は別のバージョンを作成して脇に置く事で古いデータを読む事にな る他のトランザクションの邪魔をしない ❖ Read Lockを取る必要が無いので読み出しが大半を占めるワークロードで多大な 高速化を実現 ❖ 特定の値を読んで良いかどうかはトランザクション開始時に獲得したタイムスタンプ で判断するのでPhantom Readは抑制できる
- 14. ちょっと脱線： SNAPSHOT ISOLATION 2つのAnomaly(Serialize不可能なHistory生成)が起きる Oracle社のSERIALIZABLE設定はこの問題が起きる事で有名 参考: https://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:3233191441609 Oracle「Phantom Readが起きなきゃSERIALIZABLEってANSIが言ってるし、うちの実装 はPhantom Read起きないじゃん？」 x=y+1したい y=x+1したい y x 0 0 y←1 y=0 x=0 x←1 1 1 Write Skew Anomaly x+y==0ならy-=10 x+=10 y x 0 x←10 0 x=0 x=0 y←-10 10 -10 Read Only Anomaly x+yが知りたい y=0 y=0 x=10 T1 T2 T1 T2 T3 T1, T2どっちが先に終わったか不 明 結果で見ればT2が最初に終わっている がT3はT1の方が早かったと主張して矛 盾
- 15. ここまでのまとめ 2 Phase Lockでトランザクションは実装可能だが現実的な速度は出ない SNAPSHOT ISOLATIONのような「ACIDを一部諦めた」モデルが 一般に広く使われている OracleのSERIALIZABLEはSNAPSHOT ISOLATION
- 16. Atomic Snapshot 問題「ランダムなタイミングで増加する2つのカウンターのどこか一瞬の状態を獲得せ よ。ただし、一度に読めるカウンターは1つである」 ● 1つ読んで、2つめを読むタイミングで1つめの値が変わってる可能性がある ● 2つを2回読んで、値が一致していればその期間ずっとその値だったと言える A B 0 0 1 1 3 4 4 5 2 2 この範囲内ならずっと A=2, B=3と断言できる 3 T1 B=3A=2 B=3 A=2
- 17. Optimistic Concurrency Control(OCC) コミット時までロックを取らずに進行し、Commit時にValidationを行う戦略 コミット時にロックを取る→Readをやり直す という順序で操作を行う事によって、Read側 のSnapshotの瞬間とWrite側の2PLのLinearization pointを重ねるのがポイント ReadされるデータのSnapshotが取れるように、全てのオブジェクトに単調増加するバー ジョン番号を取り付ける必要がある T1 Object1 Object2 Object1&2,,n Object3 Objectn この範囲内でトランザクションの全操作が起きた事にできる
- 18. マルチコアの時代到来 コア数が増える程にコヒーレンスが重くなる(Universal Scalability Law) 縦軸：性能 横軸：システム負荷(≒使用プロセッサ数 ) N: プロセッサ数 α: 衝突コスト係数 β: コヒーレントコスト係数 平たく言うと、N倍の資源を用意すれば N倍速にな るかと思いきや、衝突のせいでそう速くならない し、コヒーレントのコストが 2乗で効いてくるので 返って遅くなる事すらある http://www.perfdynamics.com/Manifesto/USLscalability.html
- 19. 最近のDB研究での動向 メインメモリに全データが入るという前提が許されるなら、ページの書き戻し自体が必要 ないのでWAL(ページの書き戻しより先にUndo-Logを書く)という制約が要らなくなる マルチコアを活かしてトランザクションを高速化させる場合、キャッシュコヒーレントに足 を引っ張られにくいOCCが注目を集めている。(Snapshot Readはキャッシュを一切汚さ ない場合すらある) In-Memory + マルチコア + 楽観的並行制御 の組み合わせがスイートスポット
- 20. Group Commit 個々のトランザクションごとにCommit Logを書くのでは無く、複数のトランザクションから出てきたログを1つにまとめて書き込む技法 ● 各トランザクションは自分のCommit Logがまとめて書き込まれるのを見届けるまでクライアントに完了を報告しないので、ク ライアントから見た振る舞いは一緒 ● ディスク書き込みはシーケンシャルアクセスの方が高速なので、少ないIO数の中に大量のコミット情報を投入することは大き な高速化に寄与する ● SSDであっても結構意義があると手元のベンチマークは言ってる 最初にこれを実装したのはIBMのIMS FastPath。大抵の人気DBは実装してるはず。 enqueue enqueue enqueue Finish! Unlockcommit Disk Write Unlockcommit Disk Write Logger
- 21. Early Lock Release Group Commit等で、何をCommitするかという内容を決めてディスクに書き出す順序まで確定 (pre-commit)した 後なら、ロックを手放してしまってもトランザクションの性質は変わらないよという提案 ● 仮に手放したロックを握った別のトランザクションがやってきても、手放した側のトランザクションを追い抜く事はない（ディスク に書き出す順序は既に確定したので） ● ディスク動作を待つ間にデータのロックを手放して良いので、より多くのトランザクションがロックを握って進行できるようになる ● 詳細な証明は結構ゴツいので論文参照 実地でどの程度使われてるかは未調査。 PostgreSQLは未実装らしい。 enqueue enqueue enqueue Finish! Unlockcommit Disk Write enqueue enqueue enqueue Finish! Unlockcommit Disk Write
- 22. Silo マルチコアの為に更に OCCを突き詰めて並列度を高めるコミットプロトコル 1. Epochという40ミリ秒ごとに増える数字を全トランザクションに与えて IDの上位ビットにする 2. 各トランザクションは自分が観測した値の全バージョンより 1大きいIDをコミット時に算出する 3. メモリ更新と同時にUnlockして構わなくなった 4. 同一Epochなログが全て揃わないとユーザに完了を報告しない 5. リカバリの際は同一Epochのトランザクションが全て揃っていない限り無効なログとして棄却する Epoch単位でログ集合を緩く共有するので、ログの細かい順序も入れ替わっても問題なくなり並列化もできる enqueue enqueue enqueue Finish! Unlockcommit Disk Write enqueue enqueue Finish! Unlockcommit Disk Write enqueue Finish!
- 24. TicToc コミットするとき、読んだデータに対してRead-Timestampを振っていってコミット時に無 矛盾なCommit-Timestampを決めれば偽陽性を減らす事ができる x+y==0ならy-=10 x+=10 y x 0 x←10 0 x=0 x=0 y←-10 10 -10 y=0T1 T2 Commit成功 Commit成功 Rt:3 Wt:2 Rt:4 Wt:4 Rt:2 Wt:2 Rt:1 Wt:1 ts:2でOK Rt:3 Wt:2 コミットのタイムスタンプは「 ReadSet内で最大のWTS」か「WriteSetの最大の RTS+1」のうち大きい方を採用する。 T1は「max(2, 1)」と「max(1)+1」で比較して 2を採用する。これでより多くのパターンで Commitを許す事ができる。 …ただしログの順序については Future Workとして詳細は書いてない。 Rt:1 Wt:1 ts:4でOK ReadWriteSetReadSet
- 25. TicToc Siloを超える性能が出ているらしい Silo TicToc 出典: Xiangyao Yuら TicToc: Time Traveling Optimistic Concurrency Control
- 26. TicTocの問題点 ReadするだけのデータであってもReadTimeStampを更新しないといけない。 …キャッシュを汚さないのがOCCの利点じゃなかったっけ？ Read-Onlyなワークロードだと負けてるじゃないですか！ 出典: Xiangyao Yuら TicToc: Time Traveling Optimistic Concurrency Control
- 27. Mostly-Optimistic Concurrency Control(MOCC) 最近読んでる論文（まだ読みかけ） ● 基本的にはOCC ● Validation失敗でAbortするときに「ここの値は良く更新される」という情報を Temperatureとして書き込む ● 閾値よりTemperatureが高い値をReadする際はLockを取りながらトランザクション を続行する ● 自分がさっき触ったのにValidationが合わなかったデータもLockを取る ● そのまま走らせるとデッドロックしかねないのでロック順序を壊しそうなタイミングで アンロックして順に再獲得する
- 28. Mostly-Optimistic Concurrency Control(MOCC) OCCが苦手なWriteメインのワークロードでも性能が出ている。 出典： Tianzheng Wangら Mostly-Optimistic Concurrency Control for Highly Contended Dynamic Workloads on a Thousand Cores