More Related Content
Similar to Dbts 分散olt pv2
Similar to Dbts 分散olt pv2 (20)
Dbts 分散olt pv2
- 1. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
Proprietary & ConfidentialNAUTILUS
大規模分散OLTP
次世代DB / 分散OLTP(MVCC系)を可能な限り
全力で解説
- 2. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 2Proprietary & Confidential
神林飛志
– (株)ノーチラステクノロジーズ 代表取締役会長
– Asakusa
OSS
業務系のバッチ処理を分散処理させる仕組み(開発・実行環境)
実行基盤はHadoop / Spark /M3BP(メニーコア・C++でのDAG実行)
金融・テレコム・証券・社会インフラ・流通で利用
なぜ松葉杖なのか
– 趣味のフリークライミングで落下:地面に激突して右足首骨折
15m
プロテクションは2Pでヌンチャク・ロープ共に問題なし
割と楽勝のところで油断して落ちた
ビレイヤーも油断してよそ見してた
システム的には「SPoFは回避していたが、運用担当者が超油断して寝てた」
感じ。
教訓1:クライミングは楽しいけど、落ちると死ぬのでrisk loverな人以外に
はお勧めしない
教訓2:どんな完璧なSPoFも最後の人間が寝てたら意味がない
自己紹介
- 3. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 3Proprietary & Confidential
背景:ムーアの法則の終焉とメニーコア化の進展
ムーアの法則の終焉によりプロセス微細化は限界にあたりつつある。
– クロック周波数の向上は頭打ちになっている
この結果として半導体業界はCPUのメニーコア化を進めつつある。
Thousand –core machineの登場
- 4. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 4Proprietary & Confidential
背景:メモリーデバイスの進化
– メモリーの高機能化と高密度化
– 不揮発性メモリーの発展が進んでおり、NVM/SCM NVDIMM等の高速
の不揮発性メモリーも登場し、市場に投入されつつある。
– 同時にメモリーの高密度化も進みつつあり、サーバあたりのメモリー
容量もTByteクラスまで伸張しつつある。
出典:2017/7/28Intel press release
- 5. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 5Proprietary & Confidential
OLAPとOLTPの統合
– ビックデータ・IoT・AIの伸長は特にOLAPの需要を大幅に伸ばした
OLAPマーケットも大幅に伸長し、プロダクトも成長しつつある
– 他方、現状のOLAPでは、サニタイズして正規化するためにOLTP系で
メンテナンスされているデータとのETL処理を行う必要がある
→やってらんねー
– 現状ではOLTP系の処理とOLAP系の処理系は分離しており、その統合
が急務である
– これらの統合は、OLTP系またはOLAP系から個別に進化させていくに
は、その最適化ゆえに根本のアーキテクチャ変更を行う必要があり、
現実的ではなく、新たに新しいアーキテクチャの登場が待望されてい
る。
– ユースケースとして、「読んでるだけDB」はちょっともういいかな的
な感じ
背景:OLAPとOLTPの統合
- 6. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 6Proprietary & Confidential
アーキテクチャ的な限界~既存の環境の変化
DBをめぐる環境の変化
CPUアーキテクチャの変化と対応
– メニーコア化の進展
– 同時に多数のコアを利用することが必要になっている。
– 従来のDBは少数のコアの利用を前提している。この仕組みをスケールアウ
トさせることは困難であり、設計思想の最初からメニーコアの仕組みを前
提にしたアーキテクチャが必要になっている。
サーバ・アーキテクチャの変遷
– 超高速インターコネクトの利用
– コア・ローカルメモリーとソケットを越えたリモート・メモリーまた、
ノードを越えた他ノードのメモリーを管理する必要がある。
– Non-Uniformなメモリー上でのデータのロケーション管理が必要になり、
ソフトウェアレベルでのデータのConsistencyの管理が必要になる。
ハードがなんとかするとか思うのは間違い
既存DBはNUMA前提ではない→つまりだめ
DBの現状課題
- 7. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 7Proprietary & Confidential
不揮発性メモリー
– メモリーの大容量化と不揮発性メモリーの利用により、Redo logのみによ
るDBのリカバリーが可能になった。Undo logのdiskへの書き込みは不要と
なり、ARIESの実装が事実上、必要なくなった
そもそもちゃんとARIESをだな・・・おっと既存DBのdisはそこまでだ。
メモリー単価の下落
– メモリー単価の下落は、メモリーモジュールの大容量化・サーバあたりの
メモリーの大容量化に進んでいる。利用できるメモリー量が著しく増加し
ており、DB上でも様々な仕組みを利用できるようになっている。
– 従来のようなsingle-versionまたは 2-versionのモデルではなく、Multi-
versionの仕組みも利用することが可能になり、serializabilityの確保可能性
が向上している。
– replicationを効果的に利用することが可能になり、DBのパフォーマンスや
可用性を大幅に向上させることが可能になってきている。
バスの高速化
– interconnectの高速化・バンド幅の大幅な向上が行われつつある。コア
ローカルのメモリー間・ソケット間でのメモリー間転送・ノード間の通信
といったデータの転送・参照・コピーをそれぞれのレイテンシー・スルー
プットに対応させ、最適なパフォーマンスを引き出す必要がある。
DBの現状課題
- 8. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 8Proprietary & Confidential
現在のDBの性能・機能限界
RDBMSの性能の問題
– 従来のRDBMSは、ハードウェアはコア数は少なく、メモリー容
量は制限的という前提を敷いており、現在に至るまで基本アーキ
テクチャの思想は変わっていない。
– In placeまたは2-versionまでのページモデルを前提とし、リカ
バリーはARIESをベースにしている。結果として、ハードウェア
の性能が高進しても、それを生かし切れずスケールアップに限界
がきている。
NoSQLの機能の問題
– 圧倒的なハードウェアの豊富さ・容量を生かすスケールアウトを
目的としているNoSQL系の実装は、スケールアウト確保のトレー
ドオフとして一貫性の担保を放棄している。すなわちトランザク
ション機能を実装していない。
– しかし、ユーザレベルから見ると、一貫性担保は必要な機能であ
り、結果、ユーザはアプリケーションの下位レイヤーに必要な一
貫性担保の仕組みを実装している。
RAMPSに見るように、これらの実装は汎用性に欠ける。
ACIDRain (http://www.bailis.org/papers/acidrain-
sigmod2017.pdf)
– また、結果としてアプリケーション構築負荷を上昇させている。
このような現状ではNoSQL系の実装を、厳格な業務システムに適
用することには限界がある。
- 9. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 9Proprietary & Confidential
Recap
– 今後のOLTP、というか要するに「RDBMS」に、必要な要件は以下
メニーコア前提
– 少なくともhundreds coreはデフォルト、できればthousand
In memory前提
– 処理すべきデータは全てメモリーに持つ
NUMA
– メニーコア・複数ソケット
自分のローカル・ソケット内でリモート・ソケット外でリモート
SSD/NVM
– 不揮発性メモリーのDIMM化
パフォーマンス
– 1ノードで10Mtpsレベル(秒間1000万Tx)が目標
大規模OLTP
- 10. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 10Proprietary & Confidential
開発競争の現状
SAP/Oracle/MS
– 現在3巨頭体制でしのぎを削っている
– MS:Hekaton→残念ながら、もう時代遅れっぽい。次は?
– SAP:HANA→技術的には相当進んでいる。実用一歩手前か?
– Oracle:なんのかんのでNo1か
クラウド系:スケールアウト戦略
– 基本的に「MySQL・Postgres互換」狙い
木に竹を接いで遺伝子いじった魔改造なので、そこまでして旧世代に拘る理由がわからん。COBOL互換でも謳
いたいのか?
OSS:後塵を拝する
– 残念ながら一番遅れてる。
– 関係者多過ぎでどうしても遅れる。
– 俺が言ってるんじゃんないよ。中の人が言ってる。
製品・プロトが次々に出ていて、ほぼ毎年パフォーマンスレコードが更新されている始末
– ノードコア数はこのままだと増える一方なので、1ノードでBillion TPSの時代が来るかもしれない
– 意味がわからない
H-store / VoltDB世代 5年前
SILO世代 3-4前
MVCOO世代 2年前
新型MVCC世代 今年
– 去年ここで解説したSILOがちょっと古く見えるぐらい
大規模OLTP
- 11. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 11Proprietary & Confidential
Tx処理の二方式の争い
– OCC :Optimistic Concurrency Control
– MVCC :Multi-Version Concurrency Control
OCC
– Single version
– シンプル・イズ・ベスト
SILOべース
Conflictを力技で乗り切る=abort前提
エンジニアリング勝負
クライミングでいうと正対(正統派)
MVCC
– Multi version
MVTOベース
Conflictをそもそも減らす=abortは避ける
理論先行だったがエンジニアリングが追随開始
クライミングでいうとカウンターバランス(見た目が派手)
これにSSN(Serial Safty Net)が参戦中
依存関係を論理的に処理してはじく
面白い試み
クライミングでいうとヒールフックとキョンの連打(なぜ拘るのか的な)
OCC vs MVCC
現時点のオッズ
OCC:本命
MVCC:対抗
SSN:大穴
- 12. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 12Proprietary & Confidential
基本的な仕組み
– 3Phaseアプローチ
Read phase
– 共有からローカルに引っ張る
– 特にmany-core/in memoryでは、uncommittedではあってもlocalに値がcacheされるので、
cache missが減る。
Validation phase
– Consistency check
– serializableかどうかを確認する。できなければabort
Write phase
– コミットを行って書き込む
(*)Global phase
– Snapshotting
– Single version
In-place
1-version-in-placeはオーバーヘッドが少ないので、特に競合がない状態では高いパ
フォーマンスを出す
極めて軽い。GCが楽
Read用にはSnapshotを準備
– SILO2PL
Lockフリー
OCC
- 13. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 13Proprietary & Confidential
SILO-2PL
– 基本CSR空間の内部
2PL方式だが、read-lockはとらない
Writeロックをとる
言うまでもないがserializable
– 注意:今後のDBはisolation levelはすべてserializableがデフォ。
– Read lock free
Optimistic処理
とりあえず読ませる
コミット時点で更新の有無を確認
– 確認はTimestampを見る
– 変わっていれば、誰が更新したので、要はlock失敗と同じ。よってabort
Writeは普通にlock処理
– Validation phaseで多少時間をとるが、基本的にreadはwriteにブロッ
クされない。
当然concurrencyも上がる。
OCCのserialzation空間
- 14. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 14Proprietary & Confidential
Serializableは前提
– その上でどのレベルのserializableなのか、というserializableの中での戦い
今後のためのserializableのレクチャー
MVSR
Serializable空間
MCSR
VSR
CSR
既存RDBのSerializable空間
- 15. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 15Proprietary & Confidential
「広ければ広いほどよい」
– Abort率が減る
決定的にこの差はデカい
MVSR
– Multiversion view serializability
理論的に最強
– FSRはinconsistency readが起きるので、枠としてはMVSR以上の枠は存在しない
– 一般解はNP完全
MCSR
– Multiversion conflict serializability
MVSRの次に最強
– MVSRからverison orderに制約をつけて、解決案を簡単にした
» それでも一般解はNP完全
» 実装はこれに近づける(MVTO)
VSR
– View serializability
monoversionでの最強
NP完全
CSR
– Conflict serializability
Monoversionでの通常のserializability
普通のRDBが言ってる空間
この四天王のなかで最弱
Serialization空間(理論)
- 16. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 16Proprietary & Confidential
実際は理論上の空間とは別になることが多い
– 実装上のプロコトルでのSerialization空間
MVSRやMCSRがNP完全なので、どうしても実装するにはある程度制約を設
けてやらないと事実上使い物にならない
例)MVTO(mulitiversion time ordering)
– Multiversionでの実装プロトコル(あとで解説)
– MCSRに準じるがそこまで行っていない
– CSR<MVTO<MCSR
– なにが面倒かというと・・・
大抵の論文・実装は
– 「serializabilityの証明」をやるだけ
» これはこれで面倒
– どの程度のserialization空間か?自分で判断する必要がある
やってらんねー
– しかも実装プロトコルをほぼ完全に理解して、その上での制約を判断して、どのレ
ベルか考慮する必要がある
– そうでないと実際の利用ケースで「なにがabortされるのかわからない」
– なので Cicada-MVTO とかHekaton-OCCとかぞれぞれ独自の空間をもつ
Serialization空間(実際)
- 17. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 17Proprietary & Confidential
問題
– 例えば、あなたがSEで心臓移植のドナーと患者つなぐシステムのDBAでした。
いわゆるXXネットワー(ry
– 仮に、以下の取引があったときに誰がその心臓をゲットするか答えよ
Isolation levelは当然serializable
まちがった場合は(ry
あなたが間違った場合はたぶん一生(ry
そんなにserializationは大事か?
Tx2:患者A
心臓移植先
Tx1:ドナー
心臓提供
Tx3:患者B
心臓移植先
r(x) w(x) c
r(x) w(x)
r(x) w(x)
c
c
– Tx orderはtx2→tx3:先に取引を始めたのはAさん
– Commit orderはtx3→tx2:先に最終意思決定したのはBさん
– リードはtx2→tx3:先に見つけたのはAさん
– ライトはtx3→tx2:先にとりあえず手を上げたのはBさん
提供の意思書き込み
取得の意思書き込み
取得の意思書き込み
- 18. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 18Proprietary & Confidential
Abortが多い
– 現在のMVCC/OCCだとスループットが1Mtpsぐらいでるので、abort
のペナルティが大きい
cacheが汚れる
– 1-versionなので、conflictが加速度的に増える
Abort→リトライが輻輳してくるとますます詰まる
そもそもオーバーヘッドが少ないのでどんどんリトライできることが裏目
– 一部 read-only snapshotで軽減する部分もあるが、抜本的な解決には
ならない
Extra read
– ロックがないので、read時点にガンガンwriteが走る
– 何にもしてないとパーシャルライトを拾ったりとか、repeat readとか
で爆死とかいろいろ面倒になる
– なので、一回ローカルにコピーする
リードセットがデカイとかなりコスト高め
OCCの弱点
- 19. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 19Proprietary & Confidential
Indexの競合
– 普通はwrite時点でindexは更新して、コミット時点まで他には見せな
い
キー制約の維持
Abort時点でいろいろ面倒になる
– 一応、いろいろ工夫しているOCCも多い
いずれにしろabortが多いということは不利になる要素を抱え込む
基本的にOCCの弱点は1-versionであること
– ただし、これはコインの裏表
軽く・素早くがベース
そのためabort→retryが詰まり始めると窒息する
– abort軽減は1-versionではどうひっくりかえっても上限はある
OCCの弱点
- 20. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 20Proprietary & Confidential
Multiversion~基本的な仕組み
– 複数のversionを利用してコンフリクトを回避する。
s = r1(x)w1(x)r2(x)w2(y)r1(y)w1(z)c1c2:single-version
s = r1(x0)w1(x1)r2(x1)w2(y2)r1(y2)w1(z0)c1c2:multi-version
– 仮に更新があったとしても、前のversionを利用したtxが可能。
原理的にw-w競合はおきない
w1(x1)w2(x2):x1,x2は別
w1(x)w2(x):single versionでは競合
– version の管理はtimestamp(以下ts)を利用して行う。
tsのアサインはtxの開始時点で行われる。
– tsを利用してvisibleな利用可能なversionを特定する。
w1(x1)w2(x2)c2w3(x3)r4(x?)c3c1c4
– versionのtsはtxの開始時点のものか、またはcommit時点のものか、どち
らかを利用する。
– 上記はほぼすべてのMVCCで共通
MVCC
- 21. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 21Proprietary & Confidential
総論
MVCCは、車言えば最強時代のGTR
「MVCCの弱点、そりゃーズバリMV処理の重さだろ。複数
version管理からくるオーバーヘッドがMVCCの弱点だ、足回りの
チューニングやキャッシュテクでごまかしても基本性能は変わら
ない・・ハードなワークロードを続ければ必ずversionトラバース
とGCがタレてくる・・たとえチューニングしたエンジンでも
だ。」
基本的にMVのオーバーヘッドですね。これが重い
– 歴史的にはMVの理論的優位性は1980年代から証明されていたが、テ
クノロジーがそれを捌くだけのパフォーマンスが出せなかった
昔の(特に不勉強な)おっさんがMVCCはだめだ、と却下するのはそういう
理由
– この数年でハードが追いついてきた。ちょっと想像を超えるぐらい。
MVCCの弱点
- 22. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 22Proprietary & Confidential
サーチとストレージのオーバーヘッド
– 特にIn memoryな高スループットな環境では、version searchとstore
のコストはCPUを食う。
– storeの空間コストも大きい。
– 大抵のMVCCではlistや配列の中のversionのsearchに間接参照利用す
る。これはキャッシュミスやワーキングセットがCPUキャッシュに乗
らない場合は特にハイコストになる。
– 最近のMVCCでは最後のversionでは間接参照を利用せずにin placeで
の処理を行う方式もあるが、これは1-VCCと同じくextra readの問題
を引き起こす。
MVCCの弱点
- 23. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 23Proprietary & Confidential
Footprintがデカくなる
– multiversionなのでfootprintが大きくなる。
– ワーキングセットが大きければキャッシュヒット率は下がるし、処理
のパフォーマンスも落ちる。
– 頻繁にGCすることでfootprintを小さくすることもできるが、効率よく
やる必要がある。
Writes to the shared memory
– 大抵のMVCCでは共有メモリーに書き込むが、これはメニーコア環境で
は悪手。
Timestamp allocation のボトルネック
– tsの発行に、centralizedな方式で、atomicにshared counterを増やす
形をとるとワークロードの競合状態に関係なくパフォーマンスに制約
を発生させる。
– 1-VCCよりも桁違いに悪くなる。今後のメニーコア環境ではますます
悪化する。
MVCCの弱点
- 24. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 24Proprietary & Confidential
ここから本題
まずそこまでの
デメリットが
あってもMVCC
がよいのか?
本日の話題
- 25. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 25Proprietary & Confidential
MVCC(Cicada)の圧倒的なパフォーマンス
今時、これだけワンサイドゲームはあんまりない。多分対抗できているのはMOCC/Foedusだけ
出典:
Cicada: Dependably Fast Multi-Core In-Memory Transactions
Hyeontaek Lim Carnegie Mellon University hl@cs.cmu.edu
Michael Kaminsky Intel Labs michael.e.kaminsky@intel.com
David G. Andersen Carnegie Mellon University dga@cs.cmu.edu
- 26. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 26Proprietary & Confidential
YCSB~やっぱり強い 出典:
Cicada: Dependably Fast Multi-Core In-Memory Transactions
Hyeontaek Lim Carnegie Mellon University hl@cs.cmu.edu
Michael Kaminsky Intel Labs michael.e.kaminsky@intel.com
David G. Andersen Carnegie Mellon University dga@cs.cmu.edu
- 27. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 27Proprietary & Confidential
そもそもMVCCでのコンフリクトはどう減らしているのか
– 基本実装プロトコルはMVTOのほぼ一択
というか、そのVariationがほとんど
MCSRに一番近い
割と結果だけ見ると簡単
要するに「readするときは必ず最新のversionを読んでいる」という
こと「だけ」が保証されていれば良い。
– たったこれだけでfull-serializableである。
書く方は「readするときは必ず最新のversionを読んでいる」と言う
不変条件を満たさないときはabortし、それ以外には何も考えずに書
き込める。
– なにも考えずにどんどん書ける
ただし、実装によっては制約がでる
超簡単
MVCCのserialization空間というか MVTOについて
- 28. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 28Proprietary & Confidential
と思うじゃん?
- 29. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 29Proprietary & Confidential
まず、MVTOを軽く書き下す
1.read step (ri(x))は自身ts以前(含む)でかつ、最大のtsをもつ
versionを読む。
– すなわち ri(x)→ri(xj)でts(tj)<=ts(ti):j=Max version number of x
2.write step (wi(x))は以下の順で処理
– 2-1そのwriteが生成するtsよりも後のtsをもつreadが、そのwriteが生
成するversionよりも前のversion(そのwriteのtsよりも前のtsをもつ
txで生成されたversion)を読むことになりそうな場合は、abortする。
すなわち、rj(xk):ts(tk)<ts(ti)<ts(tj)が存在する場合は、wi(x)はabort
– 2-2 でなければ普通にwi(x)を実行する
3.readのコミットはそのreadが読んでいるversionを生成する
writeを含むtxのコミットが終了するまで遅延させる。
– これはdirty readの防止+リカバリーの保証になる。
証明行きます(割とストロングスタイル)
- 30. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 30Proprietary & Confidential
The following properties describe the essential characteristics of every
MVTO history H over (T0, . . . Tn).
Property1.For each Ti, there is a unique timestamp ts(Ti); That is,
ts(Ti)= ts(Tj)iff i = j.
– TSの定義。注意すべきは別段startimeにはしていない。順序があれば良い。
Property2.For every rk(xj)∈H, wj(xj)<rk(xj) and ts(Tj)<=ts(Tk).
– 読むべきものは書かれていること。ここは普通はcommitであるが、別段installでも
良い。
Property3.For every rk(xj) and wi(xi)∈H, i!=j,
either (a)ts(Ti)<ts(Tj) or (b)ts(Tk)<ts(Ti) or (c) i=k and rk[xj]<wi(xi).
– version orderの属性。(a)はvisibilityの属性(kは判断されない) (b)はvalidationの
基準(kとiが交差するとき)
Property4.If rj(xi)∈H, i!=j, and cj∈H, then ci<cj.
– 読む場合は必ずコミット順がある。
Formalization~準備完了
- 31. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 31Proprietary & Confidential
Theorem:Every history H produced by MVTO is 1SR.
– ターゲット
– 1SRはone-copy-serializableのこと、少なくとも一つのmonoversion
でserialなスケジュールと同一のsemanticsが保てるということ。
– 注意:MVTO->1SRの証明で、同値の証明ではない
Proof:
– Define a version order as follows: xi << xj iff ts(Ti) < ts(Tj).
– まずversion orderの定義
– We now prove that MVSG(H, <<) is acyclic by showing that for
every edge
MVSG : Muliti Version Serialization Graph
– Hは対象history <<はversion order:引数が“二つ”
– Ti->Tj in MVSG(H,<<), ts(Ti)<ts(Tj).
– まずMVSGが非循環であることを示す
証明開始
- 32. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 32Proprietary & Confidential
Suppose Ti->Tj is an edge of SG(H).
– 依存グラフのエッジ=dependency
This edge corresponds to a reads from relationship.
– この段階でのdependencyはRF
That is, for some x, Tj reads x from Ti.
– Readはどれを読むか?の関係グラフ
By Property2, ts(Ti)<=ts(Tj).
– 半順序
By Property1, ts(Ti)!=ts(Tj). So,ts(Ti)<ts(Tj) as desired.
– 全順序
これはほぼ前提の展開
– まずはmultiversionの前に普通のグラフを引数Hで作る
Serialization Graphからスタート
- 33. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 33Proprietary & Confidential
Let rk(xj) and wi(xi) be in H where i,j,and k are distinct, and consider the version order
edge that they generate.
– あるxについて読み書きがぞれぞれ別にあるケースは以下になる
There are two cases:
– (1)xi << xj, which implies Ti->Tj is in MVSG(H, <<);
– and (2) xj << xi, which implies Tk -> Ti is in MVSG(H, <<)
– 全順序なのでversion orderが形成できて、その場合はどちらが先になるので、それぞれのケース
でMVSGのエッジが形成される。
In case (1), by definition of <<, ts(Ti)<ts(Tj)
– xi->xjの場合
In case (2), by Property3, either ts(Ti)<ts(Tj) or ts(Tk)<ts(Ti)
– The first option is impossible, because xj << xi implies ts(Tj)<ts(Ti). So, ts(Tk)<ts( Ti) as
desired.
– xj->xiの場合の場合は, tkとtiで依存がでることもある
Since all edges in MVSG(H, <<) are in timestamp order, MVSG(H, <<) is acyclic.
最初のケースは前提(Property2,1)からありえないので、(2)のケースのみ成立。よってトポロ
ジカルソート可能。というか MVSGは非循環
つぎに、MVSGが非循環だと1SRであることを示す
– 次からは同値の証明
第一段階終了:多段ロケット方式
- 34. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 34Proprietary & Confidential
Theorem An MV history H is 1SR iff there exists a version order
<<such that MVSG(H, <<) is acyclic.
– dependency(conflict)が循環しないようなserial graphにおいてversion
orderが存在すれば、それはserializableで、かつその時に限る。
前提:
– Proposition A : Two MV histories over a set of transactions are
equivalent iff the histories have the same operations.
Proof:
(If) Let Hs be a serial MV history Ti, Ti1..Tin, where
Ti1,Ti2,..Tin is a topological sort of MVSG(H, <<).
Since C(H) is an MV history, it follows that Hs, is as well.
Since Hs has the same operations as C(H), by Proposition A, Hs
== C(H).
– 注意:C(H)はcommitted projection
It remains to prove that Hs is 1-serial.
– ここに還元する
MVSGが非循環だと1SRである(同値)ことの証明
- 35. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 35Proprietary & Confidential
Consider any reads-from relationship in Hs, say Tk reads x
from Tj, k!=i.
Let wi(xi) (i!=j and i!=k) be any other Write on x.
If xi << xj, then MVSG(H, <<) includes the version order
edge Ti -> Tj, which forces Tj to follow Ti in Hs.
If xj << xi, then MVSG(H, <<) includes the version order
edge Tk -> Ti, which forces Tk to precede Tj in Hs.
Therefore, no transaction that writes x falls in between Tj
and Tk in Hs. Thus, Hs is 1-serial.
– 読み・書きのTx以外の「任意の書き込みがあったとき」のケース
かならず1-serialになる
MVSGが非循環だと1SRであることの証明
- 36. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 36Proprietary & Confidential
(Only if) Given H and <<,
let MV(H, <<) be the graph containing only version order
edges.
Version order edges depend only on the operations in H and
<< ;
they do not depend on the order of operations in H.
Thus, if H and H’are MV histories with the same operations,
then MV(H, <<)=MV(H’,<<) for all version orders <<,
– 注意:version orderが所与でoperationが同一ならgraphは一致。一瞬
うっ ってなるけど冷静に。
Let Hs be a 1-serial MV history equivalent to C(H).
All edges in SG(Hs) go“left-to-right;” that is, if Ti ->Tj then
Ti precedes Tj in Hs.
– 1-serialなMV historyがあるとするとそのSGは「左から右に一直線」
MVSGが非循環だと1SRであることの証明
- 37. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 37Proprietary & Confidential
Define << as follows:
xi << xj only if Ti precedes Tj in Hs.
All edges in MV(Hs,<<) are also left-to-right.
Therefore all edges in MVSG(Hs, <<) = SG(Hs)∪MV(Hs,<<) are left-
to-right.
This implies MVSG(Hs, <<) is acyclic.
By Proposition A, C(H) and Hs, have the same operations.
Hence MV(C(H), <<) = MV(Hs, <<).
Proposition B: Let H and H’ be MV histories. If H== H’, then SG(H) =
SG(H’).
By Proposition A and B
SG(C(H)) = SG(Hs). Therefore MVSG(C(H), <<) = MVSG(Hs, <<).
Since MVSG(Hs, << ) is acyclic, so is MVSG(C(H), <<), which is
identical to MVSG(H, <<).
MVSGが非循環だと1SRであることの証明
- 38. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 38Proprietary & Confidential
今までおさらい
– MVCC
パフォーマンスが出てます
Serializableで有ることは問題ない
では具体的にどうやっているか?
– Cicadaを例にとって解説してみる
– Cicada: Dependably Fast Multi-Core In-Memory Transactions
https://www.cs.cmu.edu/~hl/papers/cicada-sigmod2017.pdf
– SIGMOD2017で発表されている。(4ヶ月前くらい)
– 現状の分散OLTPのアーキテクチャをうまくまとめて、欠点をうまくカ
バーアップし、言って見れば次世代MVCCの一つの形を提示している
– その上で、現在世界最高のパフォーマンスを叩き出している。
Cicada
- 39. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 39Proprietary & Confidential
Read
– Timestampのアサイン
– Version search
Validation
– Early conflict detect
– Consistency check
Write
– Logging
– Commit
その他
– 要はGC
全体の処理フロー
出典:
Cicada: Dependably Fast Multi-Core In-Memory Transactions
Hyeontaek Lim Carnegie Mellon University hl@cs.cmu.edu
Michael Kaminsky Intel Labs michael.e.kaminsky@intel.com
David G. Andersen Carnegie Mellon University dga@cs.cmu.edu
- 40. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 40Proprietary & Confidential
まず全体的に効くところ
当然Timestamp(ts)の発行
– これはメニーコアや分散処理でも鉄板のチュー
ニングポイント
メニーコア環境下でのハードウェアでの時刻同
期は高コストになりやすい。
Multi-Clock Timestamp Allocation
– 前提:tx開始時点にtsを決定する。tsはどの
versionが使われるかの決定に利用し、
serialization orderの確定に利用される。
– tsはsoftware clockで発行される。
– tsのアサインはボトルネックになりやすいので
それを排除する。
– 各ワーカースレッドがローカル・クロックを持
ちts発行前に時刻をインクリメントする。
– 実装はTime Stamp Counter(Intel謹製)を利用
し、各ローカルでのインクリメント幅(最大・
最小)のみを保証している。
– もっとも早い時刻への同期をone-sideでできる
ようにしてスレッド間のbarrierは取らない。
工夫したところを順番に
- 41. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 41Proprietary & Confidential
tsの発行は以下の3要素による
– ローカルの現在時刻
– クロックのブースト(abort時点でのスレッドあたりのクロックのブースト量)
– スレッドID(タイ・ブレーカー)
– ローカル時刻にブーストを加えて、64bitのtsを作成し、下位56bit をとってスレッドIDの8bitを加
える。
各スレッドは二種類のts(wtsとrts)をもつ。
wtsは上記の発行時刻利用する。
rtsは全てのスレッドのwtsの最小値(min_wts)から1を引いたもので、これをリーダー(leader)
スレッドが定期的に更新する。
– なお、同様にmin_rtsも計算され、これはGCに使われる。
read-writeのtxはthread.wtsをtsとして利用し、read onlyのtxはthread.rtsを利用する。
先行または同時に走るread-writeのtxのtsがmin-wtsとローカルのthread.rtsの間にあるように
して(see no earlier than min_wts and later than thread.rts)整合性を保つ。
Cicadaでは時刻同期は多少甘くても許容する。tsの物理時間での順序保証は想定しない、ユ
ニーク+単調増加であればよく、加えてスレッドID suffixと時刻の単調増加を持っていれば良
い。
とはいえ、問題もあって、早すぎるtsは、競合writeのabort率があがる=スレッド間でtsの乖
離が大きくなると同時刻のスパンがひろがりすぎる。だから競合になりやすい。
– なので、時刻異常訂正にlong-lastingとshort-livedの仕組み、早い奴はそのまま生かして、遅い奴
を一方的に修正する手法を利用
Timestamp
- 42. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 42Proprietary & Confidential
One-sided synchronization
– 各スレッドがround-robinで他のスレッドの時刻を見て自身の時刻より
も早ければ、そちらに時刻を合わせる。
– プロトコルはcache coherencyなものを利用する。
– タイミングは100μsごと。
– これは遅いものを早いものに合わせるので、早すぎるものは修正でき
ない。全部のスレッドで行うのでそれなりに有効。
Temporary clock boosting
– abort発生時に、クロックブーストを行なって他に遅れている時間分+
アルファで時刻を進める。
あと、時刻は基本的にwrap-roundなので一回りすると元に戻る。
その時は意図的に新しいversionを挿入して時刻をリセットして
セットし直す。
– だいたい10日に一回。
– このwrap-roundの回数をeraとして記憶しておく。(全順序確保)
TSの工夫
- 43. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 43Proprietary & Confidential
Cicadaはスレッド間を超えたexternal consistencyは保証しない
– OCSRではない。serializableではある
あるスレッドのコミット後に、別スレッドでのコミットが前の時刻で来るこ
とはありうる。
ただ、これは滅多に問題にならない。
dependencyがある場合は、厳密にorderingされる。external consistency
についてはmin_wtsがコミット済みのtsよりも大きくならないとアプリ側に
コミット成功を通知しないことで対応している。
– コミットされているものが先のtsを持つことを保証する。
– てか、これ事実上external consistency保証しているようなもの
– これは100 μsぐらい遅れるけど、その程度を遅らせる処理は他にもあるので許容す
る。
Tsの工夫
Tx1
Tx2
Tx3
コミット済みTS
Min_wts
- 44. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 44Proprietary & Confidential
データレイアウトは拡張可能な
配列で二層構造のページになっ
ていて、各レコードは配列のイ
ンデックス(レコードID)でアク
セスする。
各レコードのversionは単方向リ
ストの構造でheadノードから始
まりversionノードが続いている。
各versionの構成は以下
– 1. wts : versionを作成したwrite
txのts
– 2. rts : コミットした(またはす
る予定)のread txのtsの最大のも
の
– 3. レコード本体
– 4. コミットステータス
(validationの結果)
– 5. NUMAのnodeIDとかversionサ
イズとかのアロケート情報
– この単方向リストはheadから順に
wtsでソート済み
Versionの構造
- 45. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 45Proprietary & Confidential
Versionサーチの基本的な仕組み
versionがreachableになるのは、
validation phaseで version listに追加
(install)された時点から。
– フィールドはrtsとstatus以外はimmutable
– rtsはリードにより更新される。
– statusは最初はPENDINGでwrite phaseに
入ってCOMMITTEDか ABORTになる。
– 削除はゼロ・レングスのversionにしてdelete
のコミット時にDELETEDになりGC対象になる。
各txはtx.tsを持っていて、version listを最
新のものから遡ってスキャンして、使う対
象versionにアクセスする。
自分より新しいtsのversionは無視する
– v.wts>tx.tsでハネて、もっとも最新のものを
みつけてそれからstatusを確認
– PENDINGならspin-wait
– ABORTであれば一つ前のversionで確定
– COMMITEDならそのversionで確定
– これが要するにそのtxからのvisibleな
versionになる。
– ということはcommit済みのものだけでなく
dirtyだが possibly committedなものを読んで
いるということ。
Versionサーチ
- 46. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 46Proprietary & Confidential
各txはtx.tsを持っていて、
version listを最新のもの
から遡ってスキャンして、
使う対象versionにアクセス
する?
遅くね?
ここでポイント
いや、普通にL2L3のキャッ
シュに乗ってるだろうという
軟弱ないいわけでは、
結局パフォーマンスは
でないわけですよ。
- 47. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 47Proprietary & Confidential
Best-Effort Inlining
– 若干やり過ぎ感もあるが、DBのチューンとはこういうもののようだ。
best-effort inliningでオーバーヘッドと競合のコスト抑えている。
– head nodeが単純にarrayに順に配置されている=inlined
– txはまずheadのinlined version用に事前にアロケートされた場所を利用しようとする。
inlineを利用するかどうかはレコードへのwriteが行われるときに決定される。
まず最初にUNUSED ならCASでPENDINGにして、成功したらinlined versionを作成す
る。失敗したら non-inlineのversion作成。
inlineは小さなデータ(216byte)のみで利用する。大きなデータだとメリットが薄くなる。
可能な限りInline化する。条件は
– read txがinlineでないversionをvisibleとして読む
– そのversionは十分早い。v.wts<min_rts
– かつinline化されてない
– その場合はread txだけどRMWして同じレコードだけどinlne化する
inline化の競合を避けるために、inline化は滅多にまたは全く変わらないread-
intensiveなレコードに限定する。
もしwriteが多ければむしろオーバーヘッドが高いのでメリットが薄いし、そ
もそもreadされないのであればパフォーマンス向上に意味がない。
Inline化
- 48. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 48Proprietary & Confidential
Cicadaというか、MVCCを理解するポイント
– 普通はBlockingは悪手
– Cicada
– PENDINGがblockになるけど、まぁ時間がvalidationの時間だけで短い
し、そもそもearly consistency checkを通っているので、
COMMITTEDの可能性が高いので、投機的に無視するのはちょっとリ
スクがある
– もちろんabortされることはあるがこれで投機的に実行すると
Cascading abortになる。なので、他のMVCCと違って、投機実行はせ
ずにspin-waitsする。
Pendingのブロックについて
- 49. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 49Proprietary & Confidential
PENDINGは普通にabortの可能性がある
– validationに時間がかかっているのはそういうこと
– なので、投機的にabortとしてretryの方がスループットが出ると言う
のが他の実装の話で、
– Cicada的にはこれはどうよ?と言う問題提起。
– 後段になるがCicadaでは事前にpre-validationするので、この段階での
abort率は低い。
後述するが、Cicadaはversionサーチの間に、パフォーマンス上げ
るために、いかにもabortされるだろってtxをearly abortさせる
– writeでvisible version vについてv.rts<= tx.tsのチェックをする。そ
うでなければabortする。
– v.wts<tx.ts<v.rtsでabort
Cicada最大の特徴の一つ
Pendingのブロックについて
- 50. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 50Proprietary & Confidential
Read-Val-Writeの3Phaseではない
– Read-PreVal-Val-Writeの4phase
version installの前にはじく
– 最大のメリットは「書いちまってからのabort」が減る
version install後のabortはペナルティが高い
– いわゆるFail Firstをやっている
abortするやつは「可能限り前倒し」ではじけ
– これ多分今後のトレンド
OCCでもやるやつは出てくる
– が、これだとデータ構造とかいろいろ工夫が必要で悪手か?
– 悩ましい
SSNは実はこのスタイル
– なので、結構有効ではないかと思われる
要するに
- 51. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 51Proprietary & Confidential
Pending version installation
– まず先にPending versionとしてwrite
をinstall
– wtsでソート
Read timestamp update
– 必要であればreadされているすべての
versionのrtsの更新
– v.rts>=tx.tsの保証
Version consistency check
– (a) readされるレコードセットの、今
まで見えていたversionが現在でも見
えているversionで
– かつ、(b)writeされるレコードセット
の今見えているversion vが
v.rts<=tx.ts (追い越し禁止)を満た
す、ことを確認。
– MVTOプロトコルそのもの
まず普通にValidationところは流す
- 52. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 52Proprietary & Confidential
Sorting the write set by contention
validationの前にやってabortの負担の減ら
す手段。
valdiationでは、最新(listの最初の)の
versionのwtsを見る。これが大きい(新し
い)ほど競合の可能性が高い。
よってこれを降順にpartial sortしておく。
この場合Top-kは総数nの場合は、n log kで
終わる。このソートにより多数のpending
versionをinstallしたり、相当のメモリーに
アクセスする前にconflictを検出することが
できる(contention-aware validation)
これはOCCではできないか、またはやって
もコストが高くつく。
SILO/TicToc/Foedus/MOCCでは
validation phaseのロックでデッドロック
を避けるためにすべてのwrite setでグロー
バルでのソートが必要になる。
– これでは柔軟なロックの順序(flexible locking
order)を許容することができず、全ソートにn
log nかかってしまう。
– Cicadaはデッドロックがないので、この制限
がない
加速装置(その一)の解説
- 53. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 53Proprietary & Confidential
Early version consistency check
write setのソートの後に実行され
る
これはvalidation checkの version
consistency checkと同じで、GC
にかかるようなversionがinstallさ
れる前に大抵のabortを検出する。
注意
– WriteSet pre-sortとこの
EarlyCheckの二つの最適化は、低競
合状態では別段パフォーマンス向上
につながる訳ではなく、不必要な
オーバーヘッドでしかない。
なので、直近のtxがコミットされるよ
うな状態ではこのステップは両方とも
オミットされる。
加速装置(その二)の解説
- 54. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 54Proprietary & Confidential
Incremental version search
– version searchのコストを下げる。
– pending version installにしても version
consistency checkにしても version listを
トラバースする必要があり、これはread
phaseでも同じことをやるので重複してい
る。
– こういうversion searchはローカルのCPU
キャッシュにない新規に挿入されたversion
を渡り歩かないといけないため高コストに
なる。
このsearchの繰り返しのコストを低減す
るため、read phaseでの最初のversion
searchの時点でtx.tsの直後のwtsを持つ
later_versionを記憶しておく。
– このlater_versionは新しいversionが次の
version searchでヒットした時に更新され
る。
– version listがwtsの降順でソートされてい
るので、現在のtxをabortできるような新し
いversionはversion listの中では
later_versionの次に現れることが保証され
る。
– なので少なくともversion searchの繰り返
しはlater_versionからはじめて問題ない。
加速装置(その三)の解説
- 55. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 55Proprietary & Confidential
Durability
使っているのは、並列log書き込みと CheckPoint(CP)。
CPはtransaction-consistent checkpointingが使える
といいなというレベル。
– Low-overhead asynchronous checkpointing in main-
memory database systems.
基本的なデザインは以下参考
– Fast databases with fast durability and recovery
through multicore parallelism.
ということでCALC(Checkpointing Asynchronously
using Logical Consistency)がよいのでは、という提
案になっているけど、個人的にはWBLの方が全然よさ
げなんで、ここでは省略。
– CALCはconsistent snapshotを特定のコミットのタイミン
グをトリガーにしてとる感じの手法。
基本的にNUMAノード単位の複数スレッド単位で
loggerスレッドがredo logを作る。
validationが終わったら、loggerにlog
record(write/insertのnew version のwtsとdate)を
送る。
loggerはlog fileにappend(スレッド単位に存在)する。
それからversionのstatusをCOMMITTEDにマークし
直す。
普通のブロックデバイスならgroup commitで
amortizeするが、NVMならbyte addressで直書きし
て低レイテンシーで行う。
書き込みのあたり
- 56. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 56Proprietary & Confidential
checkpointについては別スレッドで動く。
各テーブルをpartitioningしてその単位で、スレッドごとのcheck point
fileに最新のcommitted versionを保存する。
この処理はロック無しで非同期に行われる。
安全なメモリーアクセスを確保するために、checkpointerはmin_rtsの
メンテナンスに参加し、min_rtsの更新がわかるようにthread.rtsの更
新する。これにより、min_rts以前のものを触る
recoveryは最新のcheckpointとredo logから行い、メモリー上にレ
コードの最新versionがinstallされているようにする。
– 削除については全部の復旧が終わった後に最新のtsでdeletedレコードを作り
直す。
– このあたりはわりといろいろやれることがまだまだ有るように見える。NVM
が前提であるので、WBLあたりがかなり有効だと思う。
Space management
– redo logはchunk化されている。checkpointの生成単位でmin_wtsよりも古
いckeckpointと古いlogが破棄される。
CheckPoint
- 57. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 57Proprietary & Confidential
Write Behind Log
– Cicadaには未搭載だが、ほぼ同時期に発表されたもの
– WriteBehindLogging
https://www.cs.cmu.edu/~jarulraj/papers/2017.wbl.vldb.pdf
– いままではWAL
Write-Ahead-Log
ここで新型の話
要するにlogをだらだら書いて適当にCPして、戻すときはCP+logでやる
出典:WriteBehindLogging
Joy Arulraj Matthew Perron Andrew Pavlo
Carnegie Mellon University
jarulraj@cs.cmu.edu mperron@cmu.edu pavlo@cs.cmu.edu
- 58. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 58Proprietary & Confidential
WBL
2番と3番の順番が「逆」
先にHeapを書いて、それからLog
はい?
出典:WriteBehindLogging
Joy Arulraj Matthew Perron Andrew Pavlo
Carnegie Mellon University
jarulraj@cs.cmu.edu mperron@cmu.edu pavlo@cs.cmu.edu
- 59. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 60Proprietary & Confidential
WAL LOG
LSN TXN TYPE
1 NA BEGIN CHECKPOINT
2 NA END CHECKPOINT
3 1 INSERT TUPLE100 (NEW X)
4 2 UPDATE TUPLE2 (NEW Y)
: : :
22 20 DELETE TUPLE 20
23 NA COMMIT TXN1,3, .. 20
24 2 UPDATE TUPLE100 (NEW X1)
25 21 UPDATE TUPLE21 (NEW Z1)
: : :
50 55 UPDATE TUPLE2 (NEW Y1)
: : :
84 80 DELETE TUPLE 80
85 NA COMMIT TXN2,21, .. 54,56, .. 79
86 81 UPDATE TUPLE100 (X2)
SYSTEM FAILED
Logの対比:WAL vs WBL:めっちゃ軽くなる
WBL
LSN LONG TX CP CD
1BEGIN CHECKPOINT
2END CHECKPOINT
3 1 100
4 2 21 120
5 55,80 81 180
SYSTEM FAILED
出典:WriteBehindLogging
Joy Arulraj Matthew Perron Andrew Pavlo
Carnegie Mellon University
jarulraj@cs.cmu.edu mperron@cmu.edu
pavlo@cs.cmu.edu
から改良
- 60. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 61Proprietary & Confidential
WALとのパフォーマンス比較
レイテンシーはあんまり変わらないね
スループットもあんま変わんないね
– どちらかというとWALと同じパフォーマンスは出ている
出典:WriteBehindLogging
Joy Arulraj Matthew Perron Andrew Pavlo
Carnegie Mellon University
jarulraj@cs.cmu.edu mperron@cmu.edu pavlo@cs.cmu.edu
- 61. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 62Proprietary & Confidential
リカバリータイムが話にならないぐらい違う
– 1000倍ぐらい違う
– 当たりまえだ。そのままversionが不揮発性メモリーの残ってる。
ほぼ瞬間リカバリー
どこまで有効か(commit)だけわかればいい
Footprintもかなり減る
– これも当たり前だ
何がいいのか?
出典:WriteBehindLogging
Joy Arulraj Matthew Perron Andrew Pavlo
Carnegie Mellon University
jarulraj@cs.cmu.edu mperron@cmu.edu pavlo@cs.cmu.edu
- 62. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 63Proprietary & Confidential
Rapid Garbage Collection
– GCはフットプリントを小さく保つために、
割と回数多めでconcurrentに行う
– Frequent garbage collection
通常のDBでは 数十msで行うが、それで
はMVCCではworking setがでかくなりす
ぎる。
– 例)80ms (Siloは40ms [EBR : Epoch
Based Reclaimation] )でGCとして、
YCSBのwrite-intesiveなケースでtxあたり
800byteの書き込みを想定する。
– TPSで3.5Mのパフォーマンスで、txあたり
1KBのstale recordができる。
– これでworking setは 80ms x 1KB x
3.5M/s だと凡そ280MB。これではCPUの
キャッシュサイズに乗らない。stale
recordが場所を取りすぎる。
もとに戻って続き
- 63. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 64Proprietary & Confidential
よってCicadaではEBRとQSBRの派生手法を利用する。回収対象のversionを
coarse-grainedではなく fine-grainedで行う。
最初のステップで各スレッドは最後のtxでコミットされた新しいversionの
metadataを記録する。
– visibleではなくなったversionはゴミになる。
各スレッドは各versionへのポインターとv.wtsのコピーをまとめてキューに放り込
む
それから各スレッドがquiescent stateに入りフラグをセットする。(10 μsごと)
リーダースレッドがフラグが立つを見るたびに全てのフラッグをリセットして
min_wtsとmin_rtsを単調増加させる。その値がグローバルなthread.wtsと
thread.rtsの最小値として各スレッドに保存される。
quiescent終了後、各スレッドはローカルのGCキューを見て、キューの最初のアイ
テムが v.wts<min_rtsかどうか判断する。もしそうなら全部、回収可能。現在・
将来のtxはv以降のversionを使うから。
チェックに失敗すれば、それ以降のキューは見る必要がないv.wtsはキューの中で
は単調増加なので。
Quiescent State Based Reclamation
- 64. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 65Proprietary & Confidential
Concurrent garbage collection
複数スレッドで異なったレコードのversionの回収が可能。
レコード単位で、GCロックとminimum write
timestamp(record.min_wts)(注:レコードlistの終端)を持つ小
さなデータ構造を本体とは別に持っていて、GC対象になるときに
フェッチされる。
– GCロックに成功 -> 失敗した場合はGCで競合しているのでfailで良い
– (v.wts) > (record.min_wts) -> vについてのdanglingはないので、
version listの残りをvからデタッチして、record.min_wtsを更新、GC
ロックを行って、GC対象にする。
最後に、デタッチされたversion listのversionローカルメモリーに
返却
並列GC
- 65. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 66Proprietary & Confidential
単純に失敗したtxをsleepしてリトラ
イする。
– そもそもbackoffの時間はワークロー
ド・システムによって最適解が様々。
– Cicadaはグローバルなコーディネート
によるmaximum back-off timeを利
用するrandomized backoffを使って
る。
リーダースレッドは5msごとに各ス
レッドのコミットされたtxの数を総
計しスループットを算出する。
直近の期間とその前の期間でのス
ループットの変化(スループットの
変化を、変化させたmaximum
back-off timeで割って勾配を見る)
を見て、正(負)なら0.5 μsの固定
量を増やす(減らす)。
ゼロまたはUndefinedの場合は方向
はランダムに決定。
Back-Off
- 66. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 67Proprietary & Confidential
Cicadaの実装プロトコルは本当にMVTOなのか?
– 証明の検証
– 「まじめに使おうと思うなら必ずやるべき」
– 例:SQLServer2014:Hekaton
論文が出ているので、ちゃんと内容を確認して、どのレベルの実装なのかは
確認するのが、DBAとしてのあるべき姿。
– ちなみにHekatonは論文が3階層になっていて、しかも一部語弊があるので、ト
ラップが多い。間違った論文を引用してたりする。
DBAとしてSQLServerを使うのであればちゃんと理解しておくべき
– SAPなんかも同じです
たくさん検証論文・資料が出てます
– 確認にすべきポイント
各自自分で検証のスタイルを確立すべき
なぜなら各論文は「所詮serializationの証明どまり」なので、自分で解読す
るしかない
Cicada:最後の証明
- 67. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 68Proprietary & Confidential
これは各自自分のスタイルを決めるべき
自分の場合
– 1.プロトコルを追っかける
Read=何を根拠に何を読んでいるか?
Validation=手法は何か?→これが重要
– 2.対象となるvalidation手法を理論と比較する
例:どうやらMVTOらしい→MVTOのPropertyを比較
同等かまたは制限的か?
– 3.空間がある程度わかったら、反証historyを放り込んで検証する
例1:MCSR<MVSRになるhistoryを入れる
例2:W-Wの競合を入れる
例3:CSR<MCSRになるhistoryを入れる
「この例の手持ちが多ければ多いほどよい」
どうやって判断すべきか
- 68. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 69Proprietary & Confidential
結局、DBは実際のアプリケーションで使ってなんぼ
– パフォーマンスはTPC-Cとか非現実的なケースがほとんど
– 要は公称はあてにならない
それで競争しないと公平性がないので、それはそれでわかる
– ところが実際のワークロードに当てはめてどうなるか?がある程度わかっ
ていないと「やってみないとわかりません」になる
これでは出来の悪いSI屋の典型ではありませんか!
– 理論上、ここはこうなるはずだ、というのはわかっていないとまずい
原理的な上界を超えることはITでは無理
– 人工知能で人間越えるとか
– ビットコインで合意できるとか
– 結局どのレベルのserializationかわからないとオレオレ2PLしか手がない。
自分で処理をserial化するようなもの、自分の無知を棚にあげて、このDB遅いん
で、とかやってるようなもの。
挙句にdeadlockする
しかも再現しない
しかも「もう俺担当じゃねーし」とか
36億回死んだほうがいい
なにが言いたいのか?
- 69. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 70Proprietary & Confidential
Cicadaの証明
A. PROOF OF SERIALIZABILITY
We prove the serializability of Cicada’s protocol. For brevity, we assume no timestamp wraparounds by using extended timestamps (§3.1); using either
timestamp format makes no difference to the schedule of transactions in Cicada. We consider read-write transactions and omit proofs regarding record inserts
and deletes.
Definition 1. The visible version of a record for a transaction is a version whose write timestamp is the latest (highest) among all committed versions of the
record and is earlier (smaller) than the transaction’s timestamp.
LEMMA 1. All transactions have a unique timestamp.
PROOF. Each thread monotonically increases its local clock and never reuses the same clock for timestamp allocation. Timestamps have the thread ID as a
unique suffix, which guarantees that all timestamps are unique.
LEMMA 2. A version of a record that is read by a committed transaction is the visible version of the record in the serial schedule.
PROOF. Let a committed transaction be tx, and the committed version of a record read by tx be v. Assume that there exists a committed transaction tx0 that
commits v0 such that (v.wts) < (v0.wts) < (tx.ts). v0 instead of v would become the visible version to tx. If tx0 has installed v0 before tx passes the version
consistency step, tx is blocked in the version consistency check step while v0 is PENDING. If v0 becomes COMMITTED, tx sees v0 as the currently visible
version and is aborted, which is impossible because tx is committed. If v0 becomes ABORTED, it is a contradiction to the assumption that tx0 is committed.
Thus, tx0 must install v0 after tx passes the version consistency check step. Recall the order of validation steps. tx performs the read timestamp update step
before the version consistency check step. The read timestamp update step for tx ensures (tx.rts) (v.rts). Tx0 performs the version consistency check step
after installing v0.
(Case 1) Suppose tx0 reads v. tx0 observes (tx0.ts) = (v0.wts) < (v.rts). Thus, tx0 is aborted by failing the version consistency check step, which is a
contradiction to the assumption that tx0 is committed.
(Case 2) Suppose tx0 reads a committed version v00 that is earlier than v. tx already passed the version consistency step by observing v, so tx0 also observes
v, which makes tx0 fail the version consistency check step because v, not v00, is the current visible version. This again makes a contraction to the assumption
that tx0 is committed.
(Case 3) Suppose tx0 reads a committed version v00 that is later than v. We substitute tx and tx0 with tx0 and tx00. Reapplying this lemma reaches Case 1
or Case 2 in finite steps, precluding the existence of v00 if tx0 is committed. Consequently, this makes a contradiction to the assumption that tx0 is committed.
Therefore, no such tx0 exists. v is the visible version to tx.
THEOREM 1. Any schedule for committed transactions in Cicada is equivalent to the serial schedule that executes the committed transactions in their
timestamp order.
PROOF. A committed transaction creates at most one version for a record. By Lemma 1, each version’s write timestamp following the transaction’s timestamp
is unique within a record. With Lemma 2, every committed transaction reads the uniquely determined visible version of the record as it would in the serial
schedule. Therefore, any schedule of committed transactions in Cicada is equivalent to the serial schedule.
んじゃー実際にやってみますか
- 70. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 71Proprietary & Confidential
どう見ても追い越し禁止のtsでやってるっぽい
多分MVTOだろう
MVTOのPropertyは・・・復習
– Property1.For each Ti, there is a unique timestamp ts(Ti); That is, ts(Ti)=
ts(Tj)iff i = j.
TSの定義。注意すべきは別段startimeにはしていない。順序があれば良い。
– Property2.For every rk(xj)∈H, wj(xj)<rk(xj) and ts(Tj)<=ts(Tk).
読むべきものは書かれていること。ここは普通はcommitであるが、別段installでも良い。
– Property3.For every rk(xj) and wi(xi)∈H, i!=j,
– either (a)ts(Ti)<ts(Tj) or (b)ts(Tk)<ts(Ti) or (c) i=k and rk[xj]<wi(xi).
version orderの属性。(a)はvisibilityの属性(kは判断されない) (b)はvalidationの基準
(kとiが交差するとき)
– Property4.If rj(xi)∈H, i!=j, and cj∈H, then ci<cj.
読む場合は必ずコミット順がある。
– OK。んじゃー行きます。
慌てずに考える
- 71. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 72Proprietary & Confidential
Definition 1. The visible version of a record for a transaction
is a version whose write timestamp is the latest (highest)
among all committed versions of the record and is earlier
(smaller) than the transaction’s timestamp.
・visible versionの定義
あるtransation(k) についてvisible version(xj)とすれば rk(xj)に
おいて wj(xj)<rk(xj) かつ ts(Tj)<=ts(Tk) visible versionの定
義より Property2は満たす。
OK
- 72. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 73Proprietary & Confidential
LEMMA 1. All transactions have a unique timestamp.
PROOF. Each thread monotonically increases its local clock
and never reuses the same clock for timestamp allocation.
Timestamps have the thread ID as a unique suffix, which
guarantees that all timestamps are unique.
・よってProperty1.For each Ti, there is a unique timestamp
ts(Ti)は満たす。
OK
ここまで二つ
- 73. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 74Proprietary & Confidential
LEMMA 2. A version of a record that is read by a committed transaction is
the visible version of the record in the serial schedule.
PROOF. Let a committed transaction be tx, and the committed version of a
record read by tx be v.
Assume that there exists a committed transaction tx′ that commits v′ such
that (v.wts) < (v′.wts) < (tx.ts).
v′ instead of v would become the visible version to tx.
If tx′ has installed v′ before tx passes the version consistency step, tx is
blocked in the version consistency check step while v′ is PENDING.
If v′ becomes COMMITTED, tx sees v′ as the currently visible version and is
aborted, which is impossible because tx is committed.
If v′ becomes ABORTED, it is a contradiction to the assumption that tx′ is
committed.
Thus, tx′ must install v′ after tx passes the version consistency check step.
・version consistency checkをパスしたtxがあるとする。んで、そのtxの読んで
いるversionに上書きする(tx’がv’を書く)のであれば、その(v’の)installはtxが
version consistency checkした後になる。前だと矛盾かabortになる。
- 74. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 75Proprietary & Confidential
Recall the order of validation steps.
tx performs the read timestamp update step before the
version consistency check step.
The read timestamp update step for tx ensures (tx.rts) ≤
(v.rts).
・まず、txはversion consistency checkの前にrtsを更新している。
よって、(tx.rts) ≤ (v.rts)
tx′ performs the version consistency check step after
installing v′.
・ここで仮にtx’があるとすると、v’をinstallしたあとでversion
consistency checkを通すことになる。
そうなると・・・
- 75. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 76Proprietary & Confidential
(Case 1) Suppose tx′ reads v.
– tx′ observes ( tx′.ts ) = ( v′.wts ) < ( v.rts )
– Thus, tx′ is aborted by failing the version consistency check step,
which is a contradiction to the assumption that tx′ is committed.
その場合、仮にtx’がvを読むとすると・・・(v′.wts) < (tx.ts)が定義
で、( tx′.ts ) = ( v′.wts ) だから( tx′.ts ) = ( v′.wts ) < ( v.rts )
( tx′.ts ) < ( v.rts ) でvalidationが通らない。->成立しない。
(Case 2) Suppose tx′ reads a committed version v′′ that is
earlier than v.
– tx already passed the version consistency step by observing v, so tx′
also observes v, which makes tx′ fail the version consistency check
step because v, not v′′, is the current visible version.
– This again makes a contraction to the assumption that tx′ is
committed.
では、仮にtx’がvよりもっと前のv’’を読むとすると・・・txがvを読ん
でいるので、tx’もvを読む。vがvisible versionなので、tx’が
validationが通らない ->成立しない
- 76. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 77Proprietary & Confidential
(Case 3) Suppose tx′ reads a committed version v′′ that is later
than v.
– We substitute tx and tx′ with tx′ and tx′′. Reapplying this lemma
reaches Case 1 or Case 2 in finite steps, precluding the existence of
v′′ if tx′ is committed.
最後にtx’がvより遅いv’’を読むとすると、txとtx’をtx’とtx”に置き換
えていくと結局前の二つのケースになり、
– tx’がコミットするとv”が存在ことができない
Consequently, this makes a contradiction to the assumption
that tx′ is committed.
– Therefore, no such tx′ exists. v is the visible version to tx.
– 従って、そう言うtx’は存在しない。
上記より、tk(rj)について読んでいないxiのversionがあったとして
(j.wts) < (i′.wts) < (k.ts)のi’が存在しないため
ts(Ti) < ts(Tj) or (b) ts(Tk) < ts(Ti) となりProperty3は満たす。
- 77. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 78Proprietary & Confidential
Property4については
– Property4. If rj(xi) ∈ H, i != j, and cj ∈ H, then ci < cj.
– これはCicadaはci < tj_start_timestamp <cjなので成立する
よってCicadaはMVTOのPropertyはすべて満たす。
したがって、Cicadaが上記のProperty以外の制約を課さないので
あれば、スケジューリングパワーはMVTOと同等である。
- 78. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 79Proprietary & Confidential
ConcurrentでのWrite同士の処理
– The pending version installation step blocks concurrent
transactions that share the same visible version and have a
higher timestamp than (tx.ts).
– If a concurrent transaction using the same visible version has a
lower timestamp than (tx.ts), it may proceed to install its own
pending version, aborting either this transaction itself or that
concurrent transaction. Similar to early aborts, this step aborts
the current transaction if the current visible version v fails to
satisfy (v.rts) <= (tx.ts)
追加的な検証の例
w0(x0)
ri(x0)
rj(x0)
wi(xi)
wj(xj)
- 79. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 80Proprietary & Confidential
ConcurrentでのWrite同士の処理
こんな感じ
w0(x0)
ri(x0)
rj(x0)
wi(xi):install
wj(xj):block
Tiのvalidationで
Ts(wi)<Ts(wj)
だと、wiはinstallして
wjはブロック
w0(x0)
ri(x0)
rj(x0)
wi(xi):install→maybe abort
wj(xj):already installed
→maybe abort
Tiのvalidationで
Ts(wj)<Ts(wi)
だと、wiはinstallして
wjはブロック
下の例を見ると、なんとなく
怪しい。もしかしてw-wで無意味に
はねてない?
- 80. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 81Proprietary & Confidential
本来はw—wは競合ではない。
rk(xi)wk(xk)とrj(xi)wj(xj)で 自身がtkとして競合がtj
1: ts(tk)<ts(tj)の場合
– rj(xi)rk(xi)wk(xk)wj(xj) or rk(xi)rj(xi)wk(xk)wj(xj)
– version orderがk->jになる。結果実行順序はrk(xi)wk(xk)wj(xj)。ま
ず自分はinstall:wk(xk)。競合はblock->よってwj(xj)の判断。ここま
でが論文の記述。
– 1-a 仮にwj(xj)のversion fetchがリードだった場合:rj(xi)はスケ
ジュールされる。r-w r-wの順序が発生するので、どちらのrも同時に
成立はしない
– 1-b 仮wj(xj)がblind writeだった場合: rj(xi)は評価されない
rk(xi)wk(xk)wj(xj) 問題なくパス。
検証してみる
w0(x0)
ri(x0)
rj(x0)
wi(xi):
install
wj(xj):
block
Tiのvalidationで
Ts(wi)<Ts(wj)
だと、wiは
installして
wjはブロック
- 81. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 82Proprietary & Confidential
2: ts(tj)<ts(tk)の場合
rj(xi)rk(xi)wj(xj)wk(xk) or rk(xi)rj(xi)wj(xj)wk(xk)
version orderがj->kになる。Cicadaではwk(xk)をinstallして、
wj(xj)かまたは自分をabortする
2-a 自分をabort CPはrj(xi)wj(xj)
2-b 相手をabort CPはrk(xi)wk(xk)
– 負けパターン
– これが本来serializableかどうか検討。原理的に1の対称なので、OKの可能
性があるはず
j->kなので、rk(xi)wk(xk)の段階で rk(xi)wj(xj)wk(xk)が確定。さ
もないとxiが読めなくなる。ここで
2-c rj(xi)があるとすると、すなわち相手はblind writeではないとす
ると
– 1と同じくr-w r-wが成立しない
2-c 相手がblind writeだとすると、rj(xi)はスケジュールされないの
で
– rk(xi)wj(xj)wk(xk) で普通に通るはず。
検証してみる