MVSR Schedulerを作るための指針

Copyright©2017 NTT corp. All Rights Reserved.
MVSR Schedulerを作るための指針
NTT
ソフトウェアイノベーションセンタ
中園翔

2Copyright©2017 NTT corp. All Rights Reserved.
• 自己紹介
• NTT ソフトウェアイノベーションセンタ所属
• NTT研究所のソフトウェア部門
• データベース担当部署で，トランザクション処理を研究
• Concurrency Controlが(一応)専門
• 熊崎氏(第一回で講演)は元・指導者
• 本PJにおける立ち位置
• 現在，MVSR Schedulerを実装し，論文執筆中
• OSS化に向けて検討中
• 本PJのOSSにうまくContributionしていきたい
• Concurrency Control部分の差し替え/最適化のコミットなど
自己紹介/立ち位置

• 理論的に最大の空間を持つScheduler
• i.e., 最も多くのスケジュールをSerializableとみなせる
• 実装の幅も，性能面での特性も，最も柔軟
• 既存手法はほぼ全てCSR Scheduler
MVSR Scheduler
MVSR
VSR
CSR
Serial

• 定義が文献によってまちまち
• Concurrency Controlを司るものだが……
• だれが/いつ/どうやって/なにをするのか,ばらばら
• 混乱の例:
• readするversionはschedulerが決める?
• scheduleを生成するもの？scheduleをverifyするもの？
• Lock waitしているstepは，scheduleにいつ追加される?
• 理論と実装が乖離している(とくにMVSR)
• CSRは，実装から生まれた理論なので，わかりやすい
• それ以外は，机上でしかまともに取り扱われていない(と思う)
• MVSR Schedulerの定義/実装の指針を話します
そもそもSchedulerとは？

Page model notationのおさらい
• Transaction:
• 全順序集合．以下の要素(step)からなる:
Read/Write:
Commit/Abort:
• History / Schedule
• T: a finite set of transactions 𝑇 = {𝑇1, … , 𝑇𝑛}
• S: schedule. Tの全要素についての全順序関係(< 𝑠)
• H: history. Commit-projection of S
• ※厳密な定義はWeikum本を参照のこと
𝒓 𝟏 𝒙 𝟎 𝒘 𝟏(𝒙 𝟏)
𝒄 𝟏 𝒂 𝟐

• Serializable:「直列実行等価」
• 「等価」関数がいろいろある
• スケジュール𝑺を入力とするbool関数𝒄𝒐𝒓𝒓𝒆𝒄𝒕(𝑺)と定義される
• E.g. 𝑀𝑉𝑆𝑅(𝑆), 𝐶𝑆𝑅(𝑆), 𝑆𝑒𝑟𝑖𝑎𝑙(𝑆)
• 例:
• 𝑆 = 𝑟1 𝑥0 𝑤1 𝑥1 𝑤2 𝑥2 𝑐1 𝑐2
• 𝑀𝑉𝑆𝑅(𝑆) = 𝑡𝑟𝑢𝑒
• 𝐶𝑆𝑅(𝑆) = 𝑡𝑟𝑢𝑒
• 𝑆𝑒𝑟𝑖𝑎𝑙(𝑆) = 𝑓𝑎𝑙𝑠𝑒
Serializableとは?

• 𝑀𝑉𝑆𝑅(𝑆)の定義をもっと深堀すると:
• View Equivalent……?
• 「すべてのread stepが，同じversionを読んだ」ということ．
• 実は「同じstepから構成される」も微妙に曲者
• 最も曲者なのは「if there exists」．つまり探索問題になっている
• NのトランザクションだとSerial Historyの順列はN!になるわけだが……
MVSRとは？
Let 𝑚 be a Multiversion history. Then 𝑚 is called multiversion view
serializable if there exists a serial monoversion history 𝑚’ for the same set
of transactions such that 𝑚 ≈ 𝑣 𝑚’.
Transactional Information Systems. P192. Definition 5.6. Multiversion View Serializability
i.e., 「同じstepから構成される，View EquivalentなSerial HistoryがあればMVSR」

• Multiversion Serialization Graph:
• Version Order(≪):
• データベースの各Data itemのバージョンの全順序の和集合
• 例:
•≪: 𝑥0 < 𝑣 𝑥1 < 𝑣 𝑥2 < 𝑣 𝑥3, 𝑦0 < 𝑣 𝑦3 < 𝑣 𝑦2
• 𝑥2 < 𝑣 𝑥3 で 𝑦3 < 𝑣 𝑦2もOK
• 添字の制約なしで，ただグラフを非循環にできればいい
MVSG: MVSRと同値の有用な定理
𝑚 ∈ 𝑀𝑉𝑆𝑅 iff there exists a version order ≪ such that 𝑀𝑉𝑆𝐺(𝑚, ≪) is acyclic.
Transactional Information Systems. P196. Theorem 5.4. Multiversion Serialization Graph
i.e., 「グラフが非循環になるような≪が存在すればMVSR」

• MVSRかどうか? == Version Orderの探索問題
• 全探索は計算量的に不可能
• 偽陽性は避けられない
• いいVersion Orderを作ることが大事
• CSRは(ヒューリスティックだが)良いVersion Orderを作っている
• 以上を踏まえて，Schedulerを定義する
• Scheduler == Version Orderを生成するプロトコルとする
• あるScheduleと，トランザクションを入力とする
• いくつかVersion Orderを生成して，グラフを描いてみる
• または，グラフの循環判定と同値の処理を行う
• 非循環のグラフが見つかれば，コミットする
• 見つからなければ，アボートする
Schedulerを定義する指針

• Scheduler:
Schedulerを定義する
スケジュール𝑆と，トランザクション𝑇𝑗 ∈ 𝑆 𝑎𝑛𝑑 (𝑐𝑗 𝑜𝑟 𝑎𝑗 ∉ 𝑆) を入力とし，
スケジュール𝑆’ ∋ 𝑐𝑗 𝑜𝑟 𝑎𝑗とVersion Order ≪ を出力する関数．
𝑓: 𝑆, 𝑇𝑗 ↦ (𝑆’, ≪)
𝐻 𝑇𝑗
𝑆
𝑇𝑘, 𝑇𝑙, …
𝐻′
∋ 𝑐𝑗 𝑇𝑘
𝑆’
, 𝑇𝑙, …
ＭＶＳＧ(𝐻′, ≪) is acyclic
ＭＶＳＧ(𝐻′, ≪) is cyclic
Ｓｃｈｅｄｕｌｅｒ
𝑆, 𝑇𝑗 ↦ (𝑆’, ≪)
𝐻′ 𝑇𝑘
𝑆’ ∋ 𝑎𝑗
, 𝑇𝑙, …

1. どのようなVersion Orderを生成するか
• Scheduleの順序< 𝑆と一致させる: CSR
• なんらかのunique timestampと一致させる: MVTO
• それ以外は？
2. いくつVersion Orderを生成するか
• 例えばCSRとMVTOの二つの≪を評価してもいい
• CSRは一つしかグラフを描けないので，明に差分になる
• やりすぎるとオーバヘッドにしかならない
3. どのようなトランザクションから評価していくか
• Schedulerの入力とするrunning transactionの選定は重要
• 「読ませたいwrite stepを含むやつを先に評価する」とか
• Decentralizedに実装するのは困難か
Scheduler設計の指針

• ここまで，入力とする𝑆についての議論を避けてきた．
• 𝑆は誰が/どうやって/いつ出力するのだろうか?
• 少なくともここまで定義したSchedulerの責務ではない
• 実際にどういうプロトコルでSを作るのか，という議論が要る
• これは理論的に詰められていない
• 抽象度を欠く実装レベルの議論が多い
• 例:
• T1: read(x) write(x)
• T2: write(x)
• つくりうる𝑆は?
• 𝑆1 = 𝑟1 𝑥0 𝑤1 𝑥1 𝑤2 𝑥2
• 𝑆2 = 𝑤2 𝑥2 𝑟1 𝑥2 𝑤1 𝑥1
• 𝑆3 = 𝑤2 𝑥2 𝑟1 𝑥0 𝑤1 𝑥1
• まだまだあるが……どれになるかはプロトコルによる．
• では，「プロトコル」とは？
Version Function

• Version Function:
Read Protocol/Version Function
Let 𝑠 be a history with initialization transaction 𝑡0 and final transaction 𝑡_∞.
A version function for 𝑠 is a function ℎ, which associates with each read step
of 𝑠 a previous write step on the same data item, and which is the identity
on write steps.
Transactional Information Systems. P192. Definition 5.1. Version Function
i.e., 「Version Function ℎというもので，各read stepはどのversionを読むか決める．制
約は『前に実行された』ことだけ」
𝑇1. 𝑟𝑒𝑎𝑑(𝑥)
𝑇4. 𝑟𝑒𝑎𝑑(𝑦)
𝑇4. 𝑟𝑒𝑎𝑑(𝑧)
𝑇3. 𝑤𝑟𝑖𝑡𝑒(𝑦)
𝑇3. 𝑤𝑟𝑖𝑡𝑒(𝑧)𝑇1. 𝑤𝑟𝑖𝑡𝑒(𝑧)𝑇1. 𝑤𝑟𝑖𝑡𝑒(𝑥)
𝑇5. 𝑤𝑟𝑖𝑡𝑒(𝑥)
Version Function𝑆 = 𝑟1 𝑥0 𝑤2 𝑥2 𝑤3 𝑥3 … . ,

• よくあるもの
• Read the most recent write(CSR)
• 直近のWrite stepによって生成されたversionを割り当てる
• タイムスタンプベース(MVTO)
• トランザクションに一意なタイムスタンプを割り当てる
• コミット済みの最新のバージョンを読む
• Recoverabilityがちょっと楽
Version Functionの例

Concurrency Controlの全体像
𝑇3. 𝑤𝑟𝑖𝑡𝑒(𝑧)𝑇1. 𝑤𝑟𝑖𝑡𝑒(𝑧)𝑇1. 𝑤𝑟𝑖𝑡𝑒(𝑥)
𝑇5. 𝑤𝑟𝑖𝑡𝑒(𝑥)
𝐻 𝑇𝑗
𝑆
𝑇𝑘, 𝑇𝑙, …
𝐻′
∋ 𝑐𝑗 𝑇𝑘
𝑆’
, 𝑇𝑙, …
ＭＶＳＧ(𝐻′, ≪) is acyclic
ＭＶＳＧ(𝐻′, ≪) is cyclic
Ｓｃｈｅｄｕｌｅｒ
𝑆, 𝑇𝑗 ↦ (𝑆’, ≪)
𝐻′ 𝑇𝑘
𝑆’ ∋ 𝑎𝑗
, 𝑇𝑙, …
Version Function𝑆 = 𝑟1 𝑥0 𝑤2 𝑥2 𝑤3 𝑥3 … . ,

• Version FunctionとVersion Orderは別々に考える
• 二つを混ぜてプロトコルを考え始めると必ず破綻する
• あれを読んだからこれを書けないとか
• これを書くとあれを読めないとか
• あるVersion Functionに，複数の≪，は問題ない
• Version Functionは一意に決めないといけない
• 最適解はワークロード依存?
• Version Orderを汎用的に作る/更新しやすくする
• 各タプルにVersion Orderのmappingを持たせるのが一般的
• E.g. Silo, TicToc, MVTO,…
• 複数のVersion Orderを検証/採用しやすくする仕組みが重要
• Version Order Tableの間接参照をCASしていくとか?
全体的な指針

• Schedulerの ≪ 探索の指針はVersion Function
• (当たり前だが)MVSRな≪があるかどうかは𝑆次第
• こういう≪の生成法がMVSG非循環を得られやすい，という特
性も，𝑆の生成法によって決まる
• Version Functionの実装方針はVersion Order
• このバージョンを読ませるとAbortするかも…というのは，ど
のような≪ で検証するかを知らないと，判断できない
ベストな組み合わせを探す

• CSRはなんだかんだ良い組み合わせ?
• 常に最新を読む/常に最新を書く
• (理論的な裏打ちは全くできないが)だいたいよさそうに見える
• 他の組み合わせは？
1. 古いものも読む/古いものも書く(MVTO)
• 理論上強い……が，実装上のオーバヘッドが多い
• タイムスタンプ生成/バージョン管理/GC/リトライ時の挙動など
2. 古いものも読む/最新を書く(Snapshot Isolation)
• ナイーブにやるとMVSG非循環がよく起こることで有名
• SSI/SSNなどのCertifierで正確にグラフを描けるが……重い
3. 最新を読む/古いものも書く
• 私の提案手法(長かった)
ベストな組み合わせを探す.2

• Concept of InvisibleWrite(IW)
• Write optimization in 1VCC
• Similar to TWR[Thomas 83], but TWR is the subset of IW
• TWR can only apply on Timestamp Ordering algorithm
• Concept of InvisibleWriteRule(IWR)
• Sufficient Condition for applying InvisibleWrite
• Implementation of IWR especially in OCC
• Evaluation
• With the state-of-the-art algorithms
• IWR makes transaction processing scalable when under High
Contention
Contribution

• Sufficient Condition for scheduler generating InvisibleWrite
• Evaluation
Contention
Contribution

History generated by InvisibleWrite
r3(x1)
w1(x1)
H = 𝑤1 𝑥1 𝑤2 𝑥2 𝑟3 𝑥1
w2(x2)
≪
𝑇3𝑇1𝑇2
≪: {𝑥2< 𝑣 𝑥1}

History generated by InvisibleWrite
r3(x1)
w1(x1)
H = 𝑤1 𝑥1 𝑤2 𝑥2 𝑟3 𝑥2
w2(x2)
≪
𝑇3𝑇1𝑇2
In 1V Storage,
𝑤2(𝑥2) is guaranteed
“will be never read”.
≪: {𝑥2< 𝑣 𝑥1}

Definition:
i.e.,
1. Schedulerが生成したVersion Order上で最新ではなく
2. Schedule上で誰にも読まれていない
Write stepを，InvisibleWrite stepとする．
これは，「最新の値を読む」Version Functionにおいては，
実行しないでそのまま進行しても問題ない．
Formalization of InvisibleWrite
A write operation 𝑤𝑖(𝑥𝑖) in schedule 𝑚 with version order ≪ is InvisibleWrite,
if the following holds:
1. 𝑤𝑖 𝑥𝑖 < 𝑚 𝑤𝑗 𝑥𝑗 ∧ 𝑥𝑗 < 𝑣 𝑥𝑖 𝑤ℎ𝑒𝑟𝑒 < 𝑣∈≪
2. ∀𝑇𝑖∀𝑟𝑖 𝑥𝑗 {𝑇𝑖 ∉ 𝑡𝑟𝑎𝑛𝑠 𝐶𝑃 𝑆 ∨ 𝑟𝑖 𝑥𝑗 ∉ 𝑜𝑝 𝑇𝑖 }

• Evaluation
Contention
Contribution

InvisibleWriteRule(IWR)
InvisibleWriteRule:
Schedulerの十分条件.(詳細は話せません)
この条件を満たすSchedulerは，以下を満たす
1. Ability to InvisibleWrite
• i.e., InvisibleWriteを含むVersionOrderを生成する．
2. MVSR
• i.e., InvisibleWriteがあっても，MVSGを正確に検証できる
3. Recoverability
4. Linearizability
• 「古いバージョンを書く」ことによって，重要になる概念．
• 最新のバージョンを書くDBでは，常に満たされていた

Linearizability
commit
Write(x)
Write(x)
commit
Ｔｉｍｅ
𝑇2 can’t do InvisibleWrite because 𝑇1 and 𝑇2 is not in concurrent.
How can the proposed method detect this concurrency?

Epoch based group commit
precommit
Epoch(e.g. 40ms)
Write(x)
CommitPoint
Write(x)
precommit
𝑇1 and 𝑇2 are in concurrent because they are in the same epoch…
All transactions in the same epoch does commit in the same time.
Our method uses Epoch based Group Commit for detecting concurrency.

• Evaluation
Contention
Contribution

Experiments
• Environments
• Intel(R) Xeon(R) CPU E7-8870 v3(32 cores * 4 sockets)
• 1.5TB Memory, 1TB NVMe SSD for Logging
• Algorithms
• S2PL, OCC, Timestamp Ordering+Thomas Write Rule
• Silo(SoSP’13), Hekaton(VLDB ’11), TicToc(SIGMOD’16)
• Silo+IWR
• Siloベースの実装．
• Version FunctionはSilo．SchedulerはSiloとIWR，二つを検証する
• IWRのVersion Orderでコミットできるなら，優先して書き込みを捨てていく
• Workloads
• Yahoo! Cloud Serving Benchmark(YCSB)
• A: Write-Heavy (50% read, 50% blind write)
• B: Read-Mostly (95% read, 5% blind write)
• Microbenchmark: Variable Epoch Size

YCSB ‘A’: Write-Heavy(High Contention)
• Silo+IWR is scalable
• Other algorithms are painful for lock contention under NUMA environments

YCSB ‘A’: Write-Heavy(Low Contention)
• Silo+IWR is still useful and optimizes the performance of Silo

YCSB ‘B’: Read-Mostly(High Contention)

Microbenchmark: Variable Epoch Size
• The larger size of epoch makes the more IWR be applied

Summary
• Shorter Critical Section
• Using Multiversion Serializability(MVSR) in 1VCC
• Write do process with Multiversion but Read doesn’t
• Write with the older version can be Invisible
• Elastic for Implementation
• IWR requires only two additional component into 1VCC
• Concurrency Detector(e.g. EBR[Tu13], Multiclock[Lim16], Timestamp)
• Dependency Detector(e.g. Bloom Filter, Hash Table)
• Low overhead with OCC-1V
• Silo+IWR adds only 64-bit bloom filter into each tuple
• Additional validation costs are very small

What type of workload is suitable?
• Update-Heavy
• Not INSERT. Workload must contains UPDATE
• E.g. Database for Sensor Network
• But read modify write can also be InvisibleWrite
when Blind Write has interleaved(like TWR)
• Contended
• Distribution must be biased
• Under uniform distribution, IWR can‘t be applied
and management of BF would be unnecessary
overhead

YCSB ‘B’: Read-Mostly(Low Contention)
• TicToc beats OCC, Silo, Silo+IWR and others
• Reducing False Positive in CSR is more important, in such workload

MVSR Schedulerを作るための指針

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to MVSR Schedulerを作るための指針

Similar to MVSR Schedulerを作るための指針 (20)

More from NTT Software Innovation Center

More from NTT Software Innovation Center (20)

Recently uploaded

Recently uploaded (7)

MVSR Schedulerを作るための指針