Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Dbts 分散olt pv2

6,256 views

Published on

DBtechshowでの資料

Published in: Technology
  • Hello! Get Your Professional Job-Winning Resume Here - Check our website! https://vk.cc/818RFv
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Dbts 分散olt pv2

  1. 1. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved. Proprietary & ConfidentialNAUTILUS 大規模分散OLTP 次世代DB / 分散OLTP(MVCC系)を可能な限り 全力で解説
  2. 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. 3. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved. NAUTILUS 3Proprietary & Confidential 背景:ムーアの法則の終焉とメニーコア化の進展  ムーアの法則の終焉によりプロセス微細化は限界にあたりつつある。 – クロック周波数の向上は頭打ちになっている  この結果として半導体業界はCPUのメニーコア化を進めつつある。 Thousand –core machineの登場
  4. 4. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved. NAUTILUS 4Proprietary & Confidential 背景:メモリーデバイスの進化 – メモリーの高機能化と高密度化 – 不揮発性メモリーの発展が進んでおり、NVM/SCM NVDIMM等の高速 の不揮発性メモリーも登場し、市場に投入されつつある。 – 同時にメモリーの高密度化も進みつつあり、サーバあたりのメモリー 容量もTByteクラスまで伸張しつつある。 出典:2017/7/28Intel press release
  5. 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. 6. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved. NAUTILUS 6Proprietary & Confidential  アーキテクチャ的な限界~既存の環境の変化  DBをめぐる環境の変化  CPUアーキテクチャの変化と対応 – メニーコア化の進展 – 同時に多数のコアを利用することが必要になっている。 – 従来のDBは少数のコアの利用を前提している。この仕組みをスケールアウ トさせることは困難であり、設計思想の最初からメニーコアの仕組みを前 提にしたアーキテクチャが必要になっている。  サーバ・アーキテクチャの変遷 – 超高速インターコネクトの利用 – コア・ローカルメモリーとソケットを越えたリモート・メモリーまた、 ノードを越えた他ノードのメモリーを管理する必要がある。 – Non-Uniformなメモリー上でのデータのロケーション管理が必要になり、 ソフトウェアレベルでのデータのConsistencyの管理が必要になる。  ハードがなんとかするとか思うのは間違い  既存DBはNUMA前提ではない→つまりだめ DBの現状課題
  7. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 24. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved. NAUTILUS 24Proprietary & Confidential  ここから本題 まずそこまでの デメリットが あってもMVCC がよいのか? 本日の話題
  25. 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. 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. 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. 28. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved. NAUTILUS 28Proprietary & Confidential と思うじゃん?
  29. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 46. Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved. NAUTILUS 46Proprietary & Confidential 各txはtx.tsを持っていて、 version listを最新のもの から遡ってスキャンして、 使う対象versionにアクセス する? 遅くね? ここでポイント いや、普通にL2L3のキャッ シュに乗ってるだろうという 軟弱ないいわけでは、 結局パフォーマンスは でないわけですよ。
  47. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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) で普通に通るはず。 検証してみる

×