SlideShare a Scribd company logo
1 of 81
Download to read offline
Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
Proprietary & ConfidentialNAUTILUS
大規模分散OLTP
次世代DB / 分散OLTP(MVCC系)を可能な限り
全力で解説
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も最後の人間が寝てたら意味がない
自己紹介
Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 3Proprietary & Confidential
背景:ムーアの法則の終焉とメニーコア化の進展
 ムーアの法則の終焉によりプロセス微細化は限界にあたりつつある。
– クロック周波数の向上は頭打ちになっている
 この結果として半導体業界はCPUのメニーコア化を進めつつある。
Thousand –core machineの登場
Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 4Proprietary & Confidential
背景:メモリーデバイスの進化
– メモリーの高機能化と高密度化
– 不揮発性メモリーの発展が進んでおり、NVM/SCM NVDIMM等の高速
の不揮発性メモリーも登場し、市場に投入されつつある。
– 同時にメモリーの高密度化も進みつつあり、サーバあたりのメモリー
容量もTByteクラスまで伸張しつつある。
出典:2017/7/28Intel press release
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の統合
Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 6Proprietary & Confidential
 アーキテクチャ的な限界~既存の環境の変化
 DBをめぐる環境の変化
 CPUアーキテクチャの変化と対応
– メニーコア化の進展
– 同時に多数のコアを利用することが必要になっている。
– 従来のDBは少数のコアの利用を前提している。この仕組みをスケールアウ
トさせることは困難であり、設計思想の最初からメニーコアの仕組みを前
提にしたアーキテクチャが必要になっている。
 サーバ・アーキテクチャの変遷
– 超高速インターコネクトの利用
– コア・ローカルメモリーとソケットを越えたリモート・メモリーまた、
ノードを越えた他ノードのメモリーを管理する必要がある。
– Non-Uniformなメモリー上でのデータのロケーション管理が必要になり、
ソフトウェアレベルでのデータのConsistencyの管理が必要になる。
 ハードがなんとかするとか思うのは間違い
 既存DBはNUMA前提ではない→つまりだめ
DBの現状課題
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の現状課題
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系の実装を、厳格な業務システムに適
用することには限界がある。
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
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
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:大穴
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
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空間
Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 14Proprietary & Confidential
 Serializableは前提
– その上でどのレベルのserializableなのか、というserializableの中での戦い
今後のためのserializableのレクチャー
MVSR
Serializable空間
MCSR
VSR
CSR
既存RDBのSerializable空間
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空間(理論)
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空間(実際)
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さん
提供の意思書き込み
取得の意思書き込み
取得の意思書き込み
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の弱点
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の弱点
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
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の弱点
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の弱点
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の弱点
Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 24Proprietary & Confidential
 ここから本題
まずそこまでの
デメリットが
あってもMVCC
がよいのか?
本日の話題
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
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
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について
Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 28Proprietary & Confidential
と思うじゃん?
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の防止+リカバリーの保証になる。
証明行きます(割とストロングスタイル)
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~準備完了
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が非循環であることを示す
証明開始
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からスタート
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であることを示す
– 次からは同値の証明
第一段階終了:多段ロケット方式
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である(同値)ことの証明
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であることの証明
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であることの証明
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であることの証明
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
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
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は取らない。
工夫したところを順番に
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
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の工夫
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
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の構造
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サーチ
Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 46Proprietary & Confidential
各txはtx.tsを持っていて、
version listを最新のもの
から遡ってスキャンして、
使う対象versionにアクセス
する?
遅くね?
ここでポイント
いや、普通にL2L3のキャッ
シュに乗ってるだろうという
軟弱ないいわけでは、
結局パフォーマンスは
でないわけですよ。
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化
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のブロックについて
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のブロックについて
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は実はこのスタイル
– なので、結構有効ではないかと思われる
要するに
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ところは流す
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はデッドロックがないので、この制限
がない
加速装置(その一)の解説
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がコミットされるよ
うな状態ではこのステップは両方とも
オミットされる。
加速装置(その二)の解説
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からはじめて問題ない。
加速装置(その三)の解説
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で直書きし
て低レイテンシーで行う。
書き込みのあたり
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
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
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
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
から改良
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
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
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が場所を取りすぎる。
もとに戻って続き
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
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
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
Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 67Proprietary & Confidential
 Cicadaの実装プロトコルは本当にMVTOなのか?
– 証明の検証
– 「まじめに使おうと思うなら必ずやるべき」
– 例:SQLServer2014:Hekaton
 論文が出ているので、ちゃんと内容を確認して、どのレベルの実装なのかは
確認するのが、DBAとしてのあるべき姿。
– ちなみにHekatonは論文が3階層になっていて、しかも一部語弊があるので、ト
ラップが多い。間違った論文を引用してたりする。
 DBAとしてSQLServerを使うのであればちゃんと理解しておくべき
– SAPなんかも同じです
 たくさん検証論文・資料が出てます
– 確認にすべきポイント
 各自自分で検証のスタイルを確立すべき
 なぜなら各論文は「所詮serializationの証明どまり」なので、自分で解読す
るしかない
Cicada:最後の証明
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を入れる
 「この例の手持ちが多ければ多いほどよい」
どうやって判断すべきか
Copyright © 2017-2018 Nautilus Technologies, Inc. All rights reserved.
NAUTILUS 69Proprietary & Confidential
 結局、DBは実際のアプリケーションで使ってなんぼ
– パフォーマンスはTPC-Cとか非現実的なケースがほとんど
– 要は公称はあてにならない
 それで競争しないと公平性がないので、それはそれでわかる
– ところが実際のワークロードに当てはめてどうなるか?がある程度わかっ
ていないと「やってみないとわかりません」になる
 これでは出来の悪いSI屋の典型ではありませんか!
– 理論上、ここはこうなるはずだ、というのはわかっていないとまずい
 原理的な上界を超えることはITでは無理
– 人工知能で人間越えるとか
– ビットコインで合意できるとか
– 結局どのレベルのserializationかわからないとオレオレ2PLしか手がない。
 自分で処理をserial化するようなもの、自分の無知を棚にあげて、このDB遅いん
で、とかやってるようなもの。
 挙句にdeadlockする
 しかも再現しない
 しかも「もう俺担当じゃねーし」とか
 36億回死んだほうがいい
なにが言いたいのか?
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.
んじゃー実際にやってみますか
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。んじゃー行きます。
慌てずに考える
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
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
 ここまで二つ
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になる。
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を通すことになる。
 そうなると・・・
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が通らない ->成立しない
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は満たす。
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と同等である。
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)
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で無意味に
はねてない?
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はブロック
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) で普通に通るはず。
検証してみる

More Related Content

What's hot

並行実行制御の最適化手法
並行実行制御の最適化手法並行実行制御の最適化手法
並行実行制御の最適化手法Sho Nakazono
 
PostgreSQLレプリケーション10周年!徹底紹介!(PostgreSQL Conference Japan 2019講演資料)
PostgreSQLレプリケーション10周年!徹底紹介!(PostgreSQL Conference Japan 2019講演資料)PostgreSQLレプリケーション10周年!徹底紹介!(PostgreSQL Conference Japan 2019講演資料)
PostgreSQLレプリケーション10周年!徹底紹介!(PostgreSQL Conference Japan 2019講演資料)NTT DATA Technology & Innovation
 
アーキテクチャから理解するPostgreSQLのレプリケーション
アーキテクチャから理解するPostgreSQLのレプリケーションアーキテクチャから理解するPostgreSQLのレプリケーション
アーキテクチャから理解するPostgreSQLのレプリケーションMasahiko Sawada
 
オンライン物理バックアップの排他モードと非排他モードについて ~PostgreSQLバージョン15対応版~(第34回PostgreSQLアンカンファレンス...
オンライン物理バックアップの排他モードと非排他モードについて ~PostgreSQLバージョン15対応版~(第34回PostgreSQLアンカンファレンス...オンライン物理バックアップの排他モードと非排他モードについて ~PostgreSQLバージョン15対応版~(第34回PostgreSQLアンカンファレンス...
オンライン物理バックアップの排他モードと非排他モードについて ~PostgreSQLバージョン15対応版~(第34回PostgreSQLアンカンファレンス...NTT DATA Technology & Innovation
 
Apache Kafkaって本当に大丈夫?~故障検証のオーバービューと興味深い挙動の紹介~
Apache Kafkaって本当に大丈夫?~故障検証のオーバービューと興味深い挙動の紹介~Apache Kafkaって本当に大丈夫?~故障検証のオーバービューと興味深い挙動の紹介~
Apache Kafkaって本当に大丈夫?~故障検証のオーバービューと興味深い挙動の紹介~NTT DATA OSS Professional Services
 
トランザクションの並行実行制御 rev.2
トランザクションの並行実行制御 rev.2トランザクションの並行実行制御 rev.2
トランザクションの並行実行制御 rev.2Takashi Hoshino
 
分散システムの限界について知ろう
分散システムの限界について知ろう分散システムの限界について知ろう
分散システムの限界について知ろうShingo Omura
 
そんなトランザクションマネージャで大丈夫か?
そんなトランザクションマネージャで大丈夫か?そんなトランザクションマネージャで大丈夫か?
そんなトランザクションマネージャで大丈夫か?takezoe
 
オンライン物理バックアップの排他モードと非排他モードについて(第15回PostgreSQLアンカンファレンス@オンライン 発表資料)
オンライン物理バックアップの排他モードと非排他モードについて(第15回PostgreSQLアンカンファレンス@オンライン 発表資料)オンライン物理バックアップの排他モードと非排他モードについて(第15回PostgreSQLアンカンファレンス@オンライン 発表資料)
オンライン物理バックアップの排他モードと非排他モードについて(第15回PostgreSQLアンカンファレンス@オンライン 発表資料)NTT DATA Technology & Innovation
 
PostgreSQLでスケールアウト
PostgreSQLでスケールアウトPostgreSQLでスケールアウト
PostgreSQLでスケールアウトMasahiko Sawada
 
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)NTT DATA Technology & Innovation
 
PostgreSQLのリカバリ超入門(もしくはWAL、CHECKPOINT、オンラインバックアップの仕組み)
PostgreSQLのリカバリ超入門(もしくはWAL、CHECKPOINT、オンラインバックアップの仕組み)PostgreSQLのリカバリ超入門(もしくはWAL、CHECKPOINT、オンラインバックアップの仕組み)
PostgreSQLのリカバリ超入門(もしくはWAL、CHECKPOINT、オンラインバックアップの仕組み)Hironobu Suzuki
 
MySQLアーキテクチャ図解講座
MySQLアーキテクチャ図解講座MySQLアーキテクチャ図解講座
MySQLアーキテクチャ図解講座Mikiya Okuno
 
Isolation Level について
Isolation Level についてIsolation Level について
Isolation Level についてTakashi Hoshino
 

What's hot (20)

並行実行制御の最適化手法
並行実行制御の最適化手法並行実行制御の最適化手法
並行実行制御の最適化手法
 
PostgreSQLレプリケーション10周年!徹底紹介!(PostgreSQL Conference Japan 2019講演資料)
PostgreSQLレプリケーション10周年!徹底紹介!(PostgreSQL Conference Japan 2019講演資料)PostgreSQLレプリケーション10周年!徹底紹介!(PostgreSQL Conference Japan 2019講演資料)
PostgreSQLレプリケーション10周年!徹底紹介!(PostgreSQL Conference Japan 2019講演資料)
 
アーキテクチャから理解するPostgreSQLのレプリケーション
アーキテクチャから理解するPostgreSQLのレプリケーションアーキテクチャから理解するPostgreSQLのレプリケーション
アーキテクチャから理解するPostgreSQLのレプリケーション
 
オンライン物理バックアップの排他モードと非排他モードについて ~PostgreSQLバージョン15対応版~(第34回PostgreSQLアンカンファレンス...
オンライン物理バックアップの排他モードと非排他モードについて ~PostgreSQLバージョン15対応版~(第34回PostgreSQLアンカンファレンス...オンライン物理バックアップの排他モードと非排他モードについて ~PostgreSQLバージョン15対応版~(第34回PostgreSQLアンカンファレンス...
オンライン物理バックアップの排他モードと非排他モードについて ~PostgreSQLバージョン15対応版~(第34回PostgreSQLアンカンファレンス...
 
PostgreSQLコミュニティに飛び込もう
PostgreSQLコミュニティに飛び込もうPostgreSQLコミュニティに飛び込もう
PostgreSQLコミュニティに飛び込もう
 
Apache Kafkaって本当に大丈夫?~故障検証のオーバービューと興味深い挙動の紹介~
Apache Kafkaって本当に大丈夫?~故障検証のオーバービューと興味深い挙動の紹介~Apache Kafkaって本当に大丈夫?~故障検証のオーバービューと興味深い挙動の紹介~
Apache Kafkaって本当に大丈夫?~故障検証のオーバービューと興味深い挙動の紹介~
 
Raft
RaftRaft
Raft
 
トランザクションの並行実行制御 rev.2
トランザクションの並行実行制御 rev.2トランザクションの並行実行制御 rev.2
トランザクションの並行実行制御 rev.2
 
分散システムの限界について知ろう
分散システムの限界について知ろう分散システムの限界について知ろう
分散システムの限界について知ろう
 
そんなトランザクションマネージャで大丈夫か?
そんなトランザクションマネージャで大丈夫か?そんなトランザクションマネージャで大丈夫か?
そんなトランザクションマネージャで大丈夫か?
 
オンライン物理バックアップの排他モードと非排他モードについて(第15回PostgreSQLアンカンファレンス@オンライン 発表資料)
オンライン物理バックアップの排他モードと非排他モードについて(第15回PostgreSQLアンカンファレンス@オンライン 発表資料)オンライン物理バックアップの排他モードと非排他モードについて(第15回PostgreSQLアンカンファレンス@オンライン 発表資料)
オンライン物理バックアップの排他モードと非排他モードについて(第15回PostgreSQLアンカンファレンス@オンライン 発表資料)
 
Paxos
PaxosPaxos
Paxos
 
PostgreSQLでスケールアウト
PostgreSQLでスケールアウトPostgreSQLでスケールアウト
PostgreSQLでスケールアウト
 
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
PostgreSQLをKubernetes上で活用するためのOperator紹介!(Cloud Native Database Meetup #3 発表資料)
 
噛み砕いてKafka Streams #kafkajp
噛み砕いてKafka Streams #kafkajp噛み砕いてKafka Streams #kafkajp
噛み砕いてKafka Streams #kafkajp
 
PostgreSQLのリカバリ超入門(もしくはWAL、CHECKPOINT、オンラインバックアップの仕組み)
PostgreSQLのリカバリ超入門(もしくはWAL、CHECKPOINT、オンラインバックアップの仕組み)PostgreSQLのリカバリ超入門(もしくはWAL、CHECKPOINT、オンラインバックアップの仕組み)
PostgreSQLのリカバリ超入門(もしくはWAL、CHECKPOINT、オンラインバックアップの仕組み)
 
MySQLアーキテクチャ図解講座
MySQLアーキテクチャ図解講座MySQLアーキテクチャ図解講座
MySQLアーキテクチャ図解講座
 
Vacuum徹底解説
Vacuum徹底解説Vacuum徹底解説
Vacuum徹底解説
 
PostgreSQL: XID周回問題に潜む別の問題
PostgreSQL: XID周回問題に潜む別の問題PostgreSQL: XID周回問題に潜む別の問題
PostgreSQL: XID周回問題に潜む別の問題
 
Isolation Level について
Isolation Level についてIsolation Level について
Isolation Level について
 

Similar to Dbts 分散olt pv2

Oracle RACの弱点を克服する infinibandを使ったクラスターテクノロジー
Oracle RACの弱点を克服する infinibandを使ったクラスターテクノロジーOracle RACの弱点を克服する infinibandを使ったクラスターテクノロジー
Oracle RACの弱点を克服する infinibandを使ったクラスターテクノロジーInsight Technology, Inc.
 
[INSIGHT OUT 2011] c25 Super RACへの道 infinibandを使ったクラスターテクノロジー紹介
[INSIGHT OUT 2011] c25 Super RACへの道 infinibandを使ったクラスターテクノロジー紹介[INSIGHT OUT 2011] c25 Super RACへの道 infinibandを使ったクラスターテクノロジー紹介
[INSIGHT OUT 2011] c25 Super RACへの道 infinibandを使ったクラスターテクノロジー紹介Insight Technology, Inc.
 
スマートフォン×Cassandraによるハイパフォーマンス基盤の構築事例
スマートフォン×Cassandraによるハイパフォーマンス基盤の構築事例スマートフォン×Cassandraによるハイパフォーマンス基盤の構築事例
スマートフォン×Cassandraによるハイパフォーマンス基盤の構築事例terurou
 
VIOPS09: 圧倒的なコストパフォーマンスを実現するクラウドアーキテクチャの秘密
VIOPS09: 圧倒的なコストパフォーマンスを実現するクラウドアーキテクチャの秘密VIOPS09: 圧倒的なコストパフォーマンスを実現するクラウドアーキテクチャの秘密
VIOPS09: 圧倒的なコストパフォーマンスを実現するクラウドアーキテクチャの秘密VIOPS Virtualized Infrastructure Operators group ARCHIVES
 
[db tech showcase Sapporo 2015] A22:HP NonStop SQLはなぜグローバルに分散DBを構築できるのか、 データの...
[db tech showcase Sapporo 2015] A22:HP NonStop SQLはなぜグローバルに分散DBを構築できるのか、 データの...[db tech showcase Sapporo 2015] A22:HP NonStop SQLはなぜグローバルに分散DBを構築できるのか、 データの...
[db tech showcase Sapporo 2015] A22:HP NonStop SQLはなぜグローバルに分散DBを構築できるのか、 データの...Insight Technology, Inc.
 
[INSIGHT OUT 2011] B32 open hardwareの夜明け pci express 3・infiniband fdrの登場(yama...
[INSIGHT OUT 2011] B32 open hardwareの夜明け pci express 3・infiniband fdrの登場(yama...[INSIGHT OUT 2011] B32 open hardwareの夜明け pci express 3・infiniband fdrの登場(yama...
[INSIGHT OUT 2011] B32 open hardwareの夜明け pci express 3・infiniband fdrの登場(yama...Insight Technology, Inc.
 
Linux/DB Tuning (DevSumi2010, Japanese)
Linux/DB Tuning (DevSumi2010, Japanese)Linux/DB Tuning (DevSumi2010, Japanese)
Linux/DB Tuning (DevSumi2010, Japanese)Yoshinori Matsunobu
 
[INSIGHT OUT 2011] A12 ひとつのデータベース技術では生き残れない part1 カラムナーデータベース(Shinkubo)
[INSIGHT OUT 2011] A12 ひとつのデータベース技術では生き残れない part1 カラムナーデータベース(Shinkubo)[INSIGHT OUT 2011] A12 ひとつのデータベース技術では生き残れない part1 カラムナーデータベース(Shinkubo)
[INSIGHT OUT 2011] A12 ひとつのデータベース技術では生き残れない part1 カラムナーデータベース(Shinkubo)Insight Technology, Inc.
 
Gmo media.inc 第9回西日本ossの普及を考える会
Gmo media.inc 第9回西日本ossの普及を考える会Gmo media.inc 第9回西日本ossの普及を考える会
Gmo media.inc 第9回西日本ossの普及を考える会Dai Utsui
 
[db tech showcase Tokyo 2016] E33: こんな方法あり!? 何でもありです! インフラストラクチャレベルインメモリコンピュー...
[db tech showcase Tokyo 2016] E33: こんな方法あり!? 何でもありです! インフラストラクチャレベルインメモリコンピュー...[db tech showcase Tokyo 2016] E33: こんな方法あり!? 何でもありです! インフラストラクチャレベルインメモリコンピュー...
[db tech showcase Tokyo 2016] E33: こんな方法あり!? 何でもありです! インフラストラクチャレベルインメモリコンピュー...Insight Technology, Inc.
 
次世代の高速メモリストレージ利用に向けたソフトウェアのモダナイゼーション
次世代の高速メモリストレージ利用に向けたソフトウェアのモダナイゼーション次世代の高速メモリストレージ利用に向けたソフトウェアのモダナイゼーション
次世代の高速メモリストレージ利用に向けたソフトウェアのモダナイゼーションNTT Software Innovation Center
 
分散型台帳技術Orb DLTの紹介
分散型台帳技術Orb DLTの紹介分散型台帳技術Orb DLTの紹介
分散型台帳技術Orb DLTの紹介Orb, Inc.
 
NW-DIY で開拓したい社会
NW-DIY で開拓したい社会NW-DIY で開拓したい社会
NW-DIY で開拓したい社会啓章 加嶋
 
Share pointを支えるsql server2014最新情報 tokyo_公開用
Share pointを支えるsql server2014最新情報 tokyo_公開用Share pointを支えるsql server2014最新情報 tokyo_公開用
Share pointを支えるsql server2014最新情報 tokyo_公開用Yukio Kumazawa
 
20101029 open cloudcampus-1
20101029 open cloudcampus-120101029 open cloudcampus-1
20101029 open cloudcampus-1Masanori Itoh
 
[db tech showcase Tokyo 2016] A25: ACIDトランザクションをサポートするエンタープライズ向けNoSQL Databas...
[db tech showcase Tokyo 2016] A25: ACIDトランザクションをサポートするエンタープライズ向けNoSQL Databas...[db tech showcase Tokyo 2016] A25: ACIDトランザクションをサポートするエンタープライズ向けNoSQL Databas...
[db tech showcase Tokyo 2016] A25: ACIDトランザクションをサポートするエンタープライズ向けNoSQL Databas...Insight Technology, Inc.
 
20170804 IOS/IOS-XE運用管理機能アップデート
20170804 IOS/IOS-XE運用管理機能アップデート20170804 IOS/IOS-XE運用管理機能アップデート
20170804 IOS/IOS-XE運用管理機能アップデートKazumasa Ikuta
 

Similar to Dbts 分散olt pv2 (20)

Oracle RACの弱点を克服する infinibandを使ったクラスターテクノロジー
Oracle RACの弱点を克服する infinibandを使ったクラスターテクノロジーOracle RACの弱点を克服する infinibandを使ったクラスターテクノロジー
Oracle RACの弱点を克服する infinibandを使ったクラスターテクノロジー
 
[INSIGHT OUT 2011] c25 Super RACへの道 infinibandを使ったクラスターテクノロジー紹介
[INSIGHT OUT 2011] c25 Super RACへの道 infinibandを使ったクラスターテクノロジー紹介[INSIGHT OUT 2011] c25 Super RACへの道 infinibandを使ったクラスターテクノロジー紹介
[INSIGHT OUT 2011] c25 Super RACへの道 infinibandを使ったクラスターテクノロジー紹介
 
スマートフォン×Cassandraによるハイパフォーマンス基盤の構築事例
スマートフォン×Cassandraによるハイパフォーマンス基盤の構築事例スマートフォン×Cassandraによるハイパフォーマンス基盤の構築事例
スマートフォン×Cassandraによるハイパフォーマンス基盤の構築事例
 
VIOPS09: 圧倒的なコストパフォーマンスを実現するクラウドアーキテクチャの秘密
VIOPS09: 圧倒的なコストパフォーマンスを実現するクラウドアーキテクチャの秘密VIOPS09: 圧倒的なコストパフォーマンスを実現するクラウドアーキテクチャの秘密
VIOPS09: 圧倒的なコストパフォーマンスを実現するクラウドアーキテクチャの秘密
 
[db tech showcase Sapporo 2015] A22:HP NonStop SQLはなぜグローバルに分散DBを構築できるのか、 データの...
[db tech showcase Sapporo 2015] A22:HP NonStop SQLはなぜグローバルに分散DBを構築できるのか、 データの...[db tech showcase Sapporo 2015] A22:HP NonStop SQLはなぜグローバルに分散DBを構築できるのか、 データの...
[db tech showcase Sapporo 2015] A22:HP NonStop SQLはなぜグローバルに分散DBを構築できるのか、 データの...
 
OpsからみたOpenStack Summit
OpsからみたOpenStack SummitOpsからみたOpenStack Summit
OpsからみたOpenStack Summit
 
[INSIGHT OUT 2011] B32 open hardwareの夜明け pci express 3・infiniband fdrの登場(yama...
[INSIGHT OUT 2011] B32 open hardwareの夜明け pci express 3・infiniband fdrの登場(yama...[INSIGHT OUT 2011] B32 open hardwareの夜明け pci express 3・infiniband fdrの登場(yama...
[INSIGHT OUT 2011] B32 open hardwareの夜明け pci express 3・infiniband fdrの登場(yama...
 
Linux/DB Tuning (DevSumi2010, Japanese)
Linux/DB Tuning (DevSumi2010, Japanese)Linux/DB Tuning (DevSumi2010, Japanese)
Linux/DB Tuning (DevSumi2010, Japanese)
 
[INSIGHT OUT 2011] A12 ひとつのデータベース技術では生き残れない part1 カラムナーデータベース(Shinkubo)
[INSIGHT OUT 2011] A12 ひとつのデータベース技術では生き残れない part1 カラムナーデータベース(Shinkubo)[INSIGHT OUT 2011] A12 ひとつのデータベース技術では生き残れない part1 カラムナーデータベース(Shinkubo)
[INSIGHT OUT 2011] A12 ひとつのデータベース技術では生き残れない part1 カラムナーデータベース(Shinkubo)
 
Gmo media.inc 第9回西日本ossの普及を考える会
Gmo media.inc 第9回西日本ossの普及を考える会Gmo media.inc 第9回西日本ossの普及を考える会
Gmo media.inc 第9回西日本ossの普及を考える会
 
[db tech showcase Tokyo 2016] E33: こんな方法あり!? 何でもありです! インフラストラクチャレベルインメモリコンピュー...
[db tech showcase Tokyo 2016] E33: こんな方法あり!? 何でもありです! インフラストラクチャレベルインメモリコンピュー...[db tech showcase Tokyo 2016] E33: こんな方法あり!? 何でもありです! インフラストラクチャレベルインメモリコンピュー...
[db tech showcase Tokyo 2016] E33: こんな方法あり!? 何でもありです! インフラストラクチャレベルインメモリコンピュー...
 
次世代の高速メモリストレージ利用に向けたソフトウェアのモダナイゼーション
次世代の高速メモリストレージ利用に向けたソフトウェアのモダナイゼーション次世代の高速メモリストレージ利用に向けたソフトウェアのモダナイゼーション
次世代の高速メモリストレージ利用に向けたソフトウェアのモダナイゼーション
 
分散型台帳技術Orb DLTの紹介
分散型台帳技術Orb DLTの紹介分散型台帳技術Orb DLTの紹介
分散型台帳技術Orb DLTの紹介
 
Orb oracle
Orb oracleOrb oracle
Orb oracle
 
NW-DIY で開拓したい社会
NW-DIY で開拓したい社会NW-DIY で開拓したい社会
NW-DIY で開拓したい社会
 
Share pointを支えるsql server2014最新情報 tokyo_公開用
Share pointを支えるsql server2014最新情報 tokyo_公開用Share pointを支えるsql server2014最新情報 tokyo_公開用
Share pointを支えるsql server2014最新情報 tokyo_公開用
 
20101029 open cloudcampus-1
20101029 open cloudcampus-120101029 open cloudcampus-1
20101029 open cloudcampus-1
 
[db tech showcase Tokyo 2016] A25: ACIDトランザクションをサポートするエンタープライズ向けNoSQL Databas...
[db tech showcase Tokyo 2016] A25: ACIDトランザクションをサポートするエンタープライズ向けNoSQL Databas...[db tech showcase Tokyo 2016] A25: ACIDトランザクションをサポートするエンタープライズ向けNoSQL Databas...
[db tech showcase Tokyo 2016] A25: ACIDトランザクションをサポートするエンタープライズ向けNoSQL Databas...
 
20170804 IOS/IOS-XE運用管理機能アップデート
20170804 IOS/IOS-XE運用管理機能アップデート20170804 IOS/IOS-XE運用管理機能アップデート
20170804 IOS/IOS-XE運用管理機能アップデート
 
IOS/IOS-XE 運用管理機能アップデート
IOS/IOS-XE 運用管理機能アップデートIOS/IOS-XE 運用管理機能アップデート
IOS/IOS-XE 運用管理機能アップデート
 

Recently uploaded

SIG-AUDIO 2024 Vol.02 オンラインセミナー 「必殺使音人(ひっさつしおとにん)カットシーンを成敗せよ」
SIG-AUDIO 2024 Vol.02 オンラインセミナー 「必殺使音人(ひっさつしおとにん)カットシーンを成敗せよ」SIG-AUDIO 2024 Vol.02 オンラインセミナー 「必殺使音人(ひっさつしおとにん)カットシーンを成敗せよ」
SIG-AUDIO 2024 Vol.02 オンラインセミナー 「必殺使音人(ひっさつしおとにん)カットシーンを成敗せよ」IGDA Japan SIG-Audio
 
AWS_Bedrock入門 このスライドは2024/03/08の勉強会で発表されたものです。
AWS_Bedrock入門 このスライドは2024/03/08の勉強会で発表されたものです。AWS_Bedrock入門 このスライドは2024/03/08の勉強会で発表されたものです。
AWS_Bedrock入門 このスライドは2024/03/08の勉強会で発表されたものです。iPride Co., Ltd.
 
The 86th National Convention of IPSJ (Student Encouragement Award))
The 86th National Convention of IPSJ (Student Encouragement Award))The 86th National Convention of IPSJ (Student Encouragement Award))
The 86th National Convention of IPSJ (Student Encouragement Award))yoshidakids7
 
JAWS DAYS 2024 E-3 ランチにまつわるちょっといい話 〜給食がない町の小中学生に温かい昼食を〜
JAWS DAYS 2024 E-3 ランチにまつわるちょっといい話 〜給食がない町の小中学生に温かい昼食を〜JAWS DAYS 2024 E-3 ランチにまつわるちょっといい話 〜給食がない町の小中学生に温かい昼食を〜
JAWS DAYS 2024 E-3 ランチにまつわるちょっといい話 〜給食がない町の小中学生に温かい昼食を〜Naomi Yamasaki
 
チームで開発するための環境を整える
チームで開発するための環境を整えるチームで開発するための環境を整える
チームで開発するための環境を整えるonozaty
 
これからはじめるAnsible - Ansible Night Tokyo 2024
これからはじめるAnsible - Ansible Night Tokyo 2024これからはじめるAnsible - Ansible Night Tokyo 2024
これからはじめるAnsible - Ansible Night Tokyo 2024Hideki Saito
 
AWS Lambdaと AWS API Gatewayを使ったREST API作り
AWS Lambdaと AWS API Gatewayを使ったREST API作りAWS Lambdaと AWS API Gatewayを使ったREST API作り
AWS Lambdaと AWS API Gatewayを使ったREST API作りiPride Co., Ltd.
 
バイオリンの運弓動作計測による初心者と経験者の差異分析
バイオリンの運弓動作計測による初心者と経験者の差異分析バイオリンの運弓動作計測による初心者と経験者の差異分析
バイオリンの運弓動作計測による初心者と経験者の差異分析sugiuralab
 
キンドリル_ネットワーク自動化成熟度診断サービス ご紹介資料 2024年3月版
キンドリル_ネットワーク自動化成熟度診断サービス ご紹介資料 2024年3月版キンドリル_ネットワーク自動化成熟度診断サービス ご紹介資料 2024年3月版
キンドリル_ネットワーク自動化成熟度診断サービス ご紹介資料 2024年3月版Takayuki Nakayama
 
IGDA Japan SIG Audio #22 オンラインセミナー VRの知る.pdf
IGDA Japan SIG Audio #22 オンラインセミナー VRの知る.pdfIGDA Japan SIG Audio #22 オンラインセミナー VRの知る.pdf
IGDA Japan SIG Audio #22 オンラインセミナー VRの知る.pdfIGDA Japan SIG-Audio
 
キャラで動かすGPT ~GPTsでどんな感じに作っているとか考えていることとか~
キャラで動かすGPT ~GPTsでどんな感じに作っているとか考えていることとか~キャラで動かすGPT ~GPTsでどんな感じに作っているとか考えていることとか~
キャラで動かすGPT ~GPTsでどんな感じに作っているとか考えていることとか~honeshabri
 
00001_test_automation_portfolio_20240313
00001_test_automation_portfolio_2024031300001_test_automation_portfolio_20240313
00001_test_automation_portfolio_20240313ssuserf8ea02
 

Recently uploaded (12)

SIG-AUDIO 2024 Vol.02 オンラインセミナー 「必殺使音人(ひっさつしおとにん)カットシーンを成敗せよ」
SIG-AUDIO 2024 Vol.02 オンラインセミナー 「必殺使音人(ひっさつしおとにん)カットシーンを成敗せよ」SIG-AUDIO 2024 Vol.02 オンラインセミナー 「必殺使音人(ひっさつしおとにん)カットシーンを成敗せよ」
SIG-AUDIO 2024 Vol.02 オンラインセミナー 「必殺使音人(ひっさつしおとにん)カットシーンを成敗せよ」
 
AWS_Bedrock入門 このスライドは2024/03/08の勉強会で発表されたものです。
AWS_Bedrock入門 このスライドは2024/03/08の勉強会で発表されたものです。AWS_Bedrock入門 このスライドは2024/03/08の勉強会で発表されたものです。
AWS_Bedrock入門 このスライドは2024/03/08の勉強会で発表されたものです。
 
The 86th National Convention of IPSJ (Student Encouragement Award))
The 86th National Convention of IPSJ (Student Encouragement Award))The 86th National Convention of IPSJ (Student Encouragement Award))
The 86th National Convention of IPSJ (Student Encouragement Award))
 
JAWS DAYS 2024 E-3 ランチにまつわるちょっといい話 〜給食がない町の小中学生に温かい昼食を〜
JAWS DAYS 2024 E-3 ランチにまつわるちょっといい話 〜給食がない町の小中学生に温かい昼食を〜JAWS DAYS 2024 E-3 ランチにまつわるちょっといい話 〜給食がない町の小中学生に温かい昼食を〜
JAWS DAYS 2024 E-3 ランチにまつわるちょっといい話 〜給食がない町の小中学生に温かい昼食を〜
 
チームで開発するための環境を整える
チームで開発するための環境を整えるチームで開発するための環境を整える
チームで開発するための環境を整える
 
これからはじめるAnsible - Ansible Night Tokyo 2024
これからはじめるAnsible - Ansible Night Tokyo 2024これからはじめるAnsible - Ansible Night Tokyo 2024
これからはじめるAnsible - Ansible Night Tokyo 2024
 
AWS Lambdaと AWS API Gatewayを使ったREST API作り
AWS Lambdaと AWS API Gatewayを使ったREST API作りAWS Lambdaと AWS API Gatewayを使ったREST API作り
AWS Lambdaと AWS API Gatewayを使ったREST API作り
 
バイオリンの運弓動作計測による初心者と経験者の差異分析
バイオリンの運弓動作計測による初心者と経験者の差異分析バイオリンの運弓動作計測による初心者と経験者の差異分析
バイオリンの運弓動作計測による初心者と経験者の差異分析
 
キンドリル_ネットワーク自動化成熟度診断サービス ご紹介資料 2024年3月版
キンドリル_ネットワーク自動化成熟度診断サービス ご紹介資料 2024年3月版キンドリル_ネットワーク自動化成熟度診断サービス ご紹介資料 2024年3月版
キンドリル_ネットワーク自動化成熟度診断サービス ご紹介資料 2024年3月版
 
IGDA Japan SIG Audio #22 オンラインセミナー VRの知る.pdf
IGDA Japan SIG Audio #22 オンラインセミナー VRの知る.pdfIGDA Japan SIG Audio #22 オンラインセミナー VRの知る.pdf
IGDA Japan SIG Audio #22 オンラインセミナー VRの知る.pdf
 
キャラで動かすGPT ~GPTsでどんな感じに作っているとか考えていることとか~
キャラで動かすGPT ~GPTsでどんな感じに作っているとか考えていることとか~キャラで動かすGPT ~GPTsでどんな感じに作っているとか考えていることとか~
キャラで動かすGPT ~GPTsでどんな感じに作っているとか考えていることとか~
 
00001_test_automation_portfolio_20240313
00001_test_automation_portfolio_2024031300001_test_automation_portfolio_20240313
00001_test_automation_portfolio_20240313
 

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) で普通に通るはず。 検証してみる