SlideShare a Scribd company logo
論文紹介:	An	Empirical	Evaluation	of
In-Memory	Multi-Version	Concurrency	Control
@nikezono
2Yingjun Wu, Joy Arulraj, Jiexi Lin, Ran Xian, and Andrew Pavlo. 2017. An empirical evaluation of in-memory multi-version concurrency control. Proc. VLDB Endow. 10, 7 (March 2017), 781-792.
トランザクション:	
◦ 不可分な一連の操作 ==	n回のread/write操作(0<n)
トランザクション処理の目標:
◦ Atomicity:	n回のread/write操作を1回のレジスタ操作と同様に扱えること
◦ Consistency:	一貫性を守ること.	A,I,Dに加えてDBの制約条件を常に満たすこと
◦ Isolation:	トランザクションが他の並行するTxの影響を受けないこと
◦ Durability:	コミット済みのトランザクションは必ず永続化されていること
トランザクション処理の構成要素:
◦ ログ管理機構(Log	manager)
◦ 並行実行制御(Concurrency	Control)
◦ データ構造,	インデックス(Data	Structure)
トランザクションと並行実行制御
3Yingjun Wu, Joy Arulraj, Jiexi Lin, Ran Xian, and Andrew Pavlo. 2017. An empirical evaluation of in-memory multi-version concurrency control. Proc. VLDB Endow. 10, 7 (March 2017), 781-792.
MVCC(Multiversion Concurrency	Control)
◦ データベースが複数のバージョンを管理すること
◦ 論理的なObject(x)が物理的にMVで表現されているということ
◦ Not-In-place	update.
◦ 対義語は1VCC.
◦ In-place	update.
◦ 1VCCはアカデミアでは優勢だが、industrialではMVCCだらけ…なぜか?
MVCC	101
4Yingjun Wu, Joy Arulraj, Jiexi Lin, Ran Xian, and Andrew Pavlo. 2017. An empirical evaluation of in-memory multi-version concurrency control. Proc. VLDB Endow. 10, 7 (March 2017), 781-792.
MVCC	Advantage
5Yingjun Wu, Joy Arulraj, Jiexi Lin, Ran Xian, and Andrew Pavlo. 2017. An empirical evaluation of in-memory multi-version concurrency control. Proc. VLDB Endow. 10, 7 (March 2017), 781-792.
直列実行との等価性にはいくつか細分類がある.
「Serializable」という場合,このどれかのクラスに当てはまる処理結果であること(または,そのような
処理結果を生成するアルゴリズムであること)を指す
並行実行制御とスケジュール空間
最終状態が等価なスケジュール(FSR)
マルチバージョン等価なスケジュール(MVSR)
ビュー等価なスケジュール(VSR)
競合等価なスケジュール(CSR)
1V系(2PL/OCC/TO)アルゴリズム
理論的に広くかつ計算量も現実的. MVCCを(まともにやれば)実装できる
直列実行
NP完全(提案なし)
現在有用だと考えられていないclass
6Yingjun Wu, Joy Arulraj, Jiexi Lin, Ran Xian, and Andrew Pavlo. 2017. An empirical evaluation of in-memory multi-version concurrency control. Proc. VLDB Endow. 10, 7 (March 2017), 781-792.
There	is	no	standard	implementation
◦ 同じMVCCでも、実装のDesign	Decisionによって性能が変わる
◦ Versionは線形リストで持つか?
◦ 線形リストはASC/DESCどちらにするか?
◦ 無限のストレージは無いので,線形リストにはGC(Compaction)が要る.
◦ いつ/誰がやるか?
◦ Indexのleafには何を書くか?
◦ TupleのPhysical	Pointerにするか、間接参照するか?
◦ このようなDesign	Decisionは今までアカデミアで議論されてこなかった	
◦ MVCC?はいはい,MVCCね.という感じで,細かい実装の違いは無視されてきた
MVCC	Design	Choices
7Yingjun Wu, Joy Arulraj, Jiexi Lin, Ran Xian, and Andrew Pavlo. 2017. An empirical evaluation of in-memory multi-version concurrency control. Proc. VLDB Endow. 10, 7 (March 2017), 781-792.
Empirical	Evaluation	for	Design	Decision
1. Concurrency	control
2. Version	storage
3. Garbage	Collection
4. Index	Management
Peloton(https://github.com/cmu-db/peloton)上に実装
◦ CMU	Andy	Pavloらが主導するOSS	RDBMS
◦ このリポジトリから論文が多く出ている
◦ Tile-based	Architecture(ICMD’16)
◦ Self-Driving	Database(CIDR’17)
◦ Relaxed	Operator	Fusion(VLDB’17)
◦ Write-Behind	Logging(VLDB’16)
学生の授業課題がこのリポジトリへのcontribution.
Contribution
8Yingjun Wu, Joy Arulraj, Jiexi Lin, Ran Xian, and Andrew Pavlo. 2017. An empirical evaluation of in-memory multi-version concurrency control. Proc. VLDB Endow. 10, 7 (March 2017), 781-792.
◦ Evaluationの前に,Tuple	Format(線形リストのノード構造体)を紹介する.	
◦ これ以後の全ての実験でこのFormatを用いる.
◦ Txn-idは書いたトランザクションのid.
◦ Idはunique	and	monotonically	 increasing.
◦ begin-tsとend-tsはuint64_t.
◦ Begin-ts <	自分のTS	<	end_ts なら読める,という風に使う
◦ これをCASすることでロックに使う
◦ 例:
1. begin-tsをINFにして自分のwriteを反映させた新しいversion	tupleを作る.
2. リスト末尾のTupleのend-tsを0にCASする(と,誰も読めなくなるので,lockに等しい)
3. pointerを自分が作ったタプルにつなぐ
4. End-tsを自分のTidにする(unlockに等しい)
Tuple	Format
9Yingjun Wu, Joy Arulraj, Jiexi Lin, Ran Xian, and Andrew Pavlo. 2017. An empirical evaluation of in-memory multi-version concurrency control. Proc. VLDB Endow. 10, 7 (March 2017), 781-792.
MVTO(Multiversion Timestamp	Ordering)
◦ 商用DBに実装無し
◦ 通称Tx本(weikum)/CC本(bernstein)という本では紹介されている
◦ まずTimestampをallocateし、それに従ってRead/Write
◦ 例:自分がT2だとする
◦ Ti(i<2)のwriteを読む
◦ Tj(2<j)が既にreadしている場合は自分のwriteが遅すぎた。アボート
◦ MVSRになる(うまく実装すれば)
◦ MVSRにしようとすると,線形リストが	V1	->	V5	->	V3…と順不同になるので,実装するのにやや工夫がいる	
◦ そのへんの理由で実装が無いのだと思われる(私の主観)
Concurrency	Control:	MVTO
T1
T2
TS	Alloc
TS	Alloc
Write(x1)Read(x0)
Linearization Point
Write(y2)
Linearization Point
Read(y0) Read(x1)
Commit
Commit
10Yingjun Wu, Joy Arulraj, Jiexi Lin, Ran Xian, and Andrew Pavlo. 2017. An empirical evaluation of in-memory multi-version concurrency control. Proc. VLDB Endow. 10, 7 (March 2017), 781-792.
Concurrency	Control:	MVOCC
T1
T2
TS	Alloc
TS	Alloc
Write(x1)Read(x0)
Linearization Point
Write(y2)Read(x0)
Validation(x) Commit
Validation(x) Abort
11Yingjun Wu, Joy Arulraj, Jiexi Lin, Ran Xian, and Andrew Pavlo. 2017. An empirical evaluation of in-memory multi-version concurrency control. Proc. VLDB Endow. 10, 7 (March 2017), 781-792.
•MV2PL(Multiversion Two	Phase	Locking)
• よく知られている2PLをMVCCに拡張したもの
• read	the	most	recent	version(∈uncommitted)
• write	after	all	concurrent	writer	has	committed
• commit	after	all	concurrent	reader/writer	has	committed
• readがblockしないだけで、事実上ほぼ2PL?
• 1Vで使っていた2PLのアルゴリズムをそのままMVに引っ張ってきただけに読める
Concurrency	Control:	MV2PL
T1
T2
TS	Alloc
TS	Alloc
Write(x1)Read(x0)
Read(x1)
Commit
Commit
rlock
commit wait
12Yingjun Wu, Joy Arulraj, Jiexi Lin, Ran Xian, and Andrew Pavlo. 2017. An empirical evaluation of in-memory multi-version concurrency control. Proc. VLDB Endow. 10, 7 (March 2017), 781-792.
Comparison(SSI,SSNは省略…)
13Yingjun Wu, Joy Arulraj, Jiexi Lin, Ran Xian, and Andrew Pavlo. 2017. An empirical evaluation of in-memory multi-version concurrency control. Proc. VLDB Endow. 10, 7 (March 2017), 781-792.
YCSB	Benchmark:	ReadOnly
14Yingjun Wu, Joy Arulraj, Jiexi Lin, Ran Xian, and Andrew Pavlo. 2017. An empirical evaluation of in-memory multi-version concurrency control. Proc. VLDB Endow. 10, 7 (March 2017), 781-792.
YCSB	Benchmark:	ReadWrite	Mixed
15Yingjun Wu, Joy Arulraj, Jiexi Lin, Ran Xian, and Andrew Pavlo. 2017. An empirical evaluation of in-memory multi-version concurrency control. Proc. VLDB Endow. 10, 7 (March 2017), 781-792.
YCSB	Benchmark: Contention
16Yingjun Wu, Joy Arulraj, Jiexi Lin, Ran Xian, and Andrew Pavlo. 2017. An empirical evaluation of in-memory multi-version concurrency control. Proc. VLDB Endow. 10, 7 (March 2017), 781-792.
Oldest-to-Newest(O2N)
◦ 線形リストの末尾にデータを追加していく
◦ ReadでもWriteでも,たいていの場合リスト末尾までのVersion	traverseが必要になる
◦ GCが遅れるとリストが伸びて不要なランダムI/Oが……
Newest-to-Oldest(N2)
◦ 線形リストの先頭(HEAD)にデータを追加していく
◦ O(1)で(latest)read/writeできる
◦ HEADを更新する ==	インデックスも更新する
◦ Secondary	indexがある場合,その更新も同時,というかatomicである必要がある
◦ 間接参照を挟めばatomicに出来るが、これは不要なランダムアクセスか?
Version	Storage:	Append-only
17Yingjun Wu, Joy Arulraj, Jiexi Lin, Ran Xian, and Andrew Pavlo. 2017. An empirical evaluation of in-memory multi-version concurrency control. Proc. VLDB Endow. 10, 7 (March 2017), 781-792.
Time-travel
◦ SAP	HANAの実装.
◦ Main	TableにはLatest	Versionのみ置く.
◦ 古いVersionはTime-travel	Storageという別の領域に置く.この領域はN2O
◦ Write時に毎回Main to	Timetravelのcopyが発生する	
◦ 歴史的経緯で複数のストレージが合体して生まれたSAP	HANAならではのデザインか?
Delta
◦ MySQL	and	Oracle	uses	this
◦ タプルの全内容ではなく更新の差分をN2Oでリストにする
◦ Partial	updateに強い.リストの各ノードにコピーするデータ量が大幅に減る
◦ ただしSELECT	*	FROM…とかされると,リストを辿ってレコードの欠片を拾い集めないといけないので辛い
Version	Storage: Timetravel	&	Delta
18Yingjun Wu, Joy Arulraj, Jiexi Lin, Ran Xian, and Andrew Pavlo. 2017. An empirical evaluation of in-memory multi-version concurrency control. Proc. VLDB Endow. 10, 7 (March 2017), 781-792.
YCSB	Benchmark:	Footprint
19Yingjun Wu, Joy Arulraj, Jiexi Lin, Ran Xian, and Andrew Pavlo. 2017. An empirical evaluation of in-memory multi-version concurrency control. Proc. VLDB Endow. 10, 7 (March 2017), 781-792.
YCSB	Benchmark:	Memory	Allocation
Memory spaces: mallocできるareaの数.(多分)
Deltaはfootprintが⼩さくなるのであまり影響を受けない.
20Yingjun Wu, Joy Arulraj, Jiexi Lin, Ran Xian, and Andrew Pavlo. 2017. An empirical evaluation of in-memory multi-version concurrency control. Proc. VLDB Endow. 10, 7 (March 2017), 781-792.
YCSB	Benchmark:	Contention
21Yingjun Wu, Joy Arulraj, Jiexi Lin, Ran Xian, and Andrew Pavlo. 2017. An empirical evaluation of in-memory multi-version concurrency control. Proc. VLDB Endow. 10, 7 (March 2017), 781-792.
Garbage	Collection:	Tuple-Level
◦ 前提:	RCU-based	memory	reclamation(QSBR)	
◦ 各TxnにはTxn-idがある.これは単調増加する	
◦ m	=	min({Tid	|	all	runnning	transactions})	を計算する	
◦ end_ts	<	m	のタプルはもう誰も読めるものが居ない.	
◦ すなわちGCできる	
	
◦ Background	Vacuuming(VACUUM)	
◦ PostgreSQL,Oracle,	MySQL	
◦ ワーカスレッドとは別にGC専用スレッドを立て,定期的に各テーブル/レコードをGCしていく	
	
◦ Cooperative	Cleaning(COOP)	
◦ Microsoft	SQL	Server(Hekaton)	
◦ トランザクションを実行するワーカスレッドがGCする	
◦ 開始時にmを計算して,m以下のノードをGCしながら走っていく	
◦ 古いデータを見つけ次第即時GCされていくので,無駄なリストのtraverseを最小化できる	
◦ が,誰にも読まれず書き込みだけが連続する場合,リストが伸び続ける問題がある
22Yingjun Wu, Joy Arulraj, Jiexi Lin, Ran Xian, and Andrew Pavlo. 2017. An empirical evaluation of in-memory multi-version concurrency control. Proc. VLDB Endow. 10, 7 (March 2017), 781-792.
Garbage	Collection:	Transaction-Level
23Yingjun Wu, Joy Arulraj, Jiexi Lin, Ran Xian, and Andrew Pavlo. 2017. An empirical evaluation of in-memory multi-version concurrency control. Proc. VLDB Endow. 10, 7 (March 2017), 781-792.
YCSB	Benchmark: Tuple-Level
24Yingjun Wu, Joy Arulraj, Jiexi Lin, Ran Xian, and Andrew Pavlo. 2017. An empirical evaluation of in-memory multi-version concurrency control. Proc. VLDB Endow. 10, 7 (March 2017), 781-792.
YCSB	Benchmark: Tuple	vs	Transaction
25Yingjun Wu, Joy Arulraj, Jiexi Lin, Ran Xian, and Andrew Pavlo. 2017. An empirical evaluation of in-memory multi-version concurrency control. Proc. VLDB Endow. 10, 7 (March 2017), 781-792.
YCSB	Benchmark: Tuple	vs	Transaction
26Yingjun Wu, Joy Arulraj, Jiexi Lin, Ran Xian, and Andrew Pavlo. 2017. An empirical evaluation of in-memory multi-version concurrency control. Proc. VLDB Endow. 10, 7 (March 2017), 781-792.
•Logical	Pointer
• 間接参照を用いて,各Indexは間接参照を指すようにする
• セカンダリインデックスがあるN2Oでも,Atomicに更新できる
• 間接参照先を何にするかで流派がある
• Primary	Key:	セカンダリインデックスに触った場合,Primary	Indexを再Traverseさせることになる
• Tuple	ID:	線形リストのheadに直接つなぐ.
•Physical	Pointer
• Indexに(B-treeならLeafに)Version	Chainをそのまま置く
• セカンダリインデックスをアトミックに更新したいならLockする
Index	Management
27Yingjun Wu, Joy Arulraj, Jiexi Lin, Ran Xian, and Andrew Pavlo. 2017. An empirical evaluation of in-memory multi-version concurrency control. Proc. VLDB Endow. 10, 7 (March 2017), 781-792.
YCSB	Benchmark: Tuple-Level
28Yingjun Wu, Joy Arulraj, Jiexi Lin, Ran Xian, and Andrew Pavlo. 2017. An empirical evaluation of in-memory multi-version concurrency control. Proc. VLDB Endow. 10, 7 (March 2017), 781-792.
これまで「MVCC」と言われてきたDBMSを同じワークロードで評価.	
これだけ性能が変わる理由はこれまで述べてきたDesign	Decisionで説明できる……
(と論文では言っている)
おまけ:	Configuration	Comparison
29Yingjun Wu, Joy Arulraj, Jiexi Lin, Ran Xian, and Andrew Pavlo. 2017. An empirical evaluation of in-memory multi-version concurrency control. Proc. VLDB Endow. 10, 7 (March 2017), 781-792.
• https://twitter.com/andy_pavlo/status/902863242774634496
• 論文タイトルで三回rejectされている	
•	タイトルが全部強気で面白い
余談

More Related Content

What's hot

PGOを用いたPostgreSQL on Kubernetes入門(PostgreSQL Conference Japan 2022 発表資料)
PGOを用いたPostgreSQL on Kubernetes入門(PostgreSQL Conference Japan 2022 発表資料)PGOを用いたPostgreSQL on Kubernetes入門(PostgreSQL Conference Japan 2022 発表資料)
PGOを用いたPostgreSQL on Kubernetes入門(PostgreSQL Conference Japan 2022 発表資料)
NTT DATA Technology & Innovation
 
LineairDB: Fast and Embedded Transactional Key-Value Storage
LineairDB: Fast and Embedded Transactional Key-Value StorageLineairDB: Fast and Embedded Transactional Key-Value Storage
LineairDB: Fast and Embedded Transactional Key-Value Storage
Sho Nakazono
 
トランザクションの並行実行制御 rev.2
トランザクションの並行実行制御 rev.2トランザクションの並行実行制御 rev.2
トランザクションの並行実行制御 rev.2
Takashi Hoshino
 
地理分散DBについて
地理分散DBについて地理分散DBについて
地理分散DBについて
Kumazaki Hiroki
 
LineairDBの紹介
LineairDBの紹介LineairDBの紹介
LineairDBの紹介
Sho Nakazono
 
詳説データベース輪読会: 分散合意その2
詳説データベース輪読会: 分散合意その2詳説データベース輪読会: 分散合意その2
詳説データベース輪読会: 分散合意その2
Sho Nakazono
 
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
 
本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話
Kumazaki Hiroki
 
トランザクションの設計と進化
トランザクションの設計と進化トランザクションの設計と進化
トランザクションの設計と進化
Kumazaki Hiroki
 
スケールアウトするPostgreSQLを目指して!その第一歩!(NTTデータ テクノロジーカンファレンス 2020 発表資料)
スケールアウトするPostgreSQLを目指して!その第一歩!(NTTデータ テクノロジーカンファレンス 2020 発表資料)スケールアウトするPostgreSQLを目指して!その第一歩!(NTTデータ テクノロジーカンファレンス 2020 発表資料)
スケールアウトするPostgreSQLを目指して!その第一歩!(NTTデータ テクノロジーカンファレンス 2020 発表資料)
NTT DATA Technology & Innovation
 
PFNのML/DL基盤を支えるKubernetesにおける自動化 / DevOpsDays Tokyo 2021
PFNのML/DL基盤を支えるKubernetesにおける自動化 / DevOpsDays Tokyo 2021PFNのML/DL基盤を支えるKubernetesにおける自動化 / DevOpsDays Tokyo 2021
PFNのML/DL基盤を支えるKubernetesにおける自動化 / DevOpsDays Tokyo 2021
Preferred Networks
 
分散システムについて語らせてくれ
分散システムについて語らせてくれ分散システムについて語らせてくれ
分散システムについて語らせてくれ
Kumazaki Hiroki
 
PostgreSQLのバグとの付き合い方 ~バグの調査からコミュニティへの報告、修正パッチ投稿まで~(PostgreSQL Conference Japa...
PostgreSQLのバグとの付き合い方 ~バグの調査からコミュニティへの報告、修正パッチ投稿まで~(PostgreSQL Conference Japa...PostgreSQLのバグとの付き合い方 ~バグの調査からコミュニティへの報告、修正パッチ投稿まで~(PostgreSQL Conference Japa...
PostgreSQLのバグとの付き合い方 ~バグの調査からコミュニティへの報告、修正パッチ投稿まで~(PostgreSQL Conference Japa...
NTT DATA Technology & Innovation
 
PostgreSQL開発コミュニティに参加しよう!(PostgreSQL Conference Japan 2021 発表資料)
PostgreSQL開発コミュニティに参加しよう!(PostgreSQL Conference Japan 2021 発表資料)PostgreSQL開発コミュニティに参加しよう!(PostgreSQL Conference Japan 2021 発表資料)
PostgreSQL開発コミュニティに参加しよう!(PostgreSQL Conference Japan 2021 発表資料)
NTT DATA Technology & Innovation
 
PostgreSQLモニタリングの基本とNTTデータが追加したモニタリング新機能(Open Source Conference 2021 Online F...
PostgreSQLモニタリングの基本とNTTデータが追加したモニタリング新機能(Open Source Conference 2021 Online F...PostgreSQLモニタリングの基本とNTTデータが追加したモニタリング新機能(Open Source Conference 2021 Online F...
PostgreSQLモニタリングの基本とNTTデータが追加したモニタリング新機能(Open Source Conference 2021 Online F...
NTT DATA Technology & Innovation
 
Apache Spark on Kubernetes入門(Open Source Conference 2021 Online Hiroshima 発表資料)
Apache Spark on Kubernetes入門(Open Source Conference 2021 Online Hiroshima 発表資料)Apache Spark on Kubernetes入門(Open Source Conference 2021 Online Hiroshima 発表資料)
Apache Spark on Kubernetes入門(Open Source Conference 2021 Online Hiroshima 発表資料)
NTT DATA Technology & Innovation
 
なかったらINSERTしたいし、あるならロック取りたいやん?
なかったらINSERTしたいし、あるならロック取りたいやん?なかったらINSERTしたいし、あるならロック取りたいやん?
なかったらINSERTしたいし、あるならロック取りたいやん?
ichirin2501
 
ログ解析基盤におけるストリーム処理パイプラインについて
ログ解析基盤におけるストリーム処理パイプラインについてログ解析基盤におけるストリーム処理パイプラインについて
ログ解析基盤におけるストリーム処理パイプラインについて
cyberagent
 

What's hot (20)

PGOを用いたPostgreSQL on Kubernetes入門(PostgreSQL Conference Japan 2022 発表資料)
PGOを用いたPostgreSQL on Kubernetes入門(PostgreSQL Conference Japan 2022 発表資料)PGOを用いたPostgreSQL on Kubernetes入門(PostgreSQL Conference Japan 2022 発表資料)
PGOを用いたPostgreSQL on Kubernetes入門(PostgreSQL Conference Japan 2022 発表資料)
 
LineairDB: Fast and Embedded Transactional Key-Value Storage
LineairDB: Fast and Embedded Transactional Key-Value StorageLineairDB: Fast and Embedded Transactional Key-Value Storage
LineairDB: Fast and Embedded Transactional Key-Value Storage
 
トランザクションの並行実行制御 rev.2
トランザクションの並行実行制御 rev.2トランザクションの並行実行制御 rev.2
トランザクションの並行実行制御 rev.2
 
地理分散DBについて
地理分散DBについて地理分散DBについて
地理分散DBについて
 
LineairDBの紹介
LineairDBの紹介LineairDBの紹介
LineairDBの紹介
 
詳説データベース輪読会: 分散合意その2
詳説データベース輪読会: 分散合意その2詳説データベース輪読会: 分散合意その2
詳説データベース輪読会: 分散合意その2
 
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 発表資料)
 
本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話
 
トランザクションの設計と進化
トランザクションの設計と進化トランザクションの設計と進化
トランザクションの設計と進化
 
スケールアウトするPostgreSQLを目指して!その第一歩!(NTTデータ テクノロジーカンファレンス 2020 発表資料)
スケールアウトするPostgreSQLを目指して!その第一歩!(NTTデータ テクノロジーカンファレンス 2020 発表資料)スケールアウトするPostgreSQLを目指して!その第一歩!(NTTデータ テクノロジーカンファレンス 2020 発表資料)
スケールアウトするPostgreSQLを目指して!その第一歩!(NTTデータ テクノロジーカンファレンス 2020 発表資料)
 
Paxos
PaxosPaxos
Paxos
 
PFNのML/DL基盤を支えるKubernetesにおける自動化 / DevOpsDays Tokyo 2021
PFNのML/DL基盤を支えるKubernetesにおける自動化 / DevOpsDays Tokyo 2021PFNのML/DL基盤を支えるKubernetesにおける自動化 / DevOpsDays Tokyo 2021
PFNのML/DL基盤を支えるKubernetesにおける自動化 / DevOpsDays Tokyo 2021
 
分散システムについて語らせてくれ
分散システムについて語らせてくれ分散システムについて語らせてくれ
分散システムについて語らせてくれ
 
PostgreSQLのバグとの付き合い方 ~バグの調査からコミュニティへの報告、修正パッチ投稿まで~(PostgreSQL Conference Japa...
PostgreSQLのバグとの付き合い方 ~バグの調査からコミュニティへの報告、修正パッチ投稿まで~(PostgreSQL Conference Japa...PostgreSQLのバグとの付き合い方 ~バグの調査からコミュニティへの報告、修正パッチ投稿まで~(PostgreSQL Conference Japa...
PostgreSQLのバグとの付き合い方 ~バグの調査からコミュニティへの報告、修正パッチ投稿まで~(PostgreSQL Conference Japa...
 
PostgreSQL開発コミュニティに参加しよう!(PostgreSQL Conference Japan 2021 発表資料)
PostgreSQL開発コミュニティに参加しよう!(PostgreSQL Conference Japan 2021 発表資料)PostgreSQL開発コミュニティに参加しよう!(PostgreSQL Conference Japan 2021 発表資料)
PostgreSQL開発コミュニティに参加しよう!(PostgreSQL Conference Japan 2021 発表資料)
 
PostgreSQLモニタリングの基本とNTTデータが追加したモニタリング新機能(Open Source Conference 2021 Online F...
PostgreSQLモニタリングの基本とNTTデータが追加したモニタリング新機能(Open Source Conference 2021 Online F...PostgreSQLモニタリングの基本とNTTデータが追加したモニタリング新機能(Open Source Conference 2021 Online F...
PostgreSQLモニタリングの基本とNTTデータが追加したモニタリング新機能(Open Source Conference 2021 Online F...
 
Apache Spark on Kubernetes入門(Open Source Conference 2021 Online Hiroshima 発表資料)
Apache Spark on Kubernetes入門(Open Source Conference 2021 Online Hiroshima 発表資料)Apache Spark on Kubernetes入門(Open Source Conference 2021 Online Hiroshima 発表資料)
Apache Spark on Kubernetes入門(Open Source Conference 2021 Online Hiroshima 発表資料)
 
なかったらINSERTしたいし、あるならロック取りたいやん?
なかったらINSERTしたいし、あるならロック取りたいやん?なかったらINSERTしたいし、あるならロック取りたいやん?
なかったらINSERTしたいし、あるならロック取りたいやん?
 
ログ解析基盤におけるストリーム処理パイプラインについて
ログ解析基盤におけるストリーム処理パイプラインについてログ解析基盤におけるストリーム処理パイプラインについて
ログ解析基盤におけるストリーム処理パイプラインについて
 
B-link-tree
B-link-treeB-link-tree
B-link-tree
 

Similar to 論文紹介: An empirical evaluation of in-memory multi-version concurrency control

輪読資料: Staring into the abyss an evaluation of concurrency control with one t...
輪読資料: Staring into the abyss  an evaluation of concurrency control with one t...輪読資料: Staring into the abyss  an evaluation of concurrency control with one t...
輪読資料: Staring into the abyss an evaluation of concurrency control with one t...
Sho Nakazono
 
Programming camp 2008, Codereading
Programming camp 2008, CodereadingProgramming camp 2008, Codereading
Programming camp 2008, Codereading
Hiro Yoshioka
 
Bi-Directional Block Self-Attention for Fast and Memory-Efficient Sequence Mo...
Bi-Directional Block Self-Attention for Fast and Memory-Efficient Sequence Mo...Bi-Directional Block Self-Attention for Fast and Memory-Efficient Sequence Mo...
Bi-Directional Block Self-Attention for Fast and Memory-Efficient Sequence Mo...
Satoru Katsumata
 
ななめ45°から見たJavaOne
ななめ45°から見たJavaOneななめ45°から見たJavaOne
ななめ45°から見たJavaOneAdvancedTechNight
 
遺伝研 Rina Aizawa ユーザミーティング
遺伝研 Rina Aizawa ユーザミーティング遺伝研 Rina Aizawa ユーザミーティング
遺伝研 Rina Aizawa ユーザミーティング
Tazro Ohta
 
CouchDB JP & BigCouch
CouchDB JP & BigCouchCouchDB JP & BigCouch
CouchDB JP & BigCouch
Yohei Sasaki
 
Cassandraのトランザクションサポート化 & web2pyによるcms用プラグイン開発
Cassandraのトランザクションサポート化 & web2pyによるcms用プラグイン開発Cassandraのトランザクションサポート化 & web2pyによるcms用プラグイン開発
Cassandraのトランザクションサポート化 & web2pyによるcms用プラグイン開発
kishimotosc
 
ACL Reading @NAIST: Fast and Robust Neural Network Joint Model for Statistica...
ACL Reading @NAIST: Fast and Robust Neural Network Joint Model for Statistica...ACL Reading @NAIST: Fast and Robust Neural Network Joint Model for Statistica...
ACL Reading @NAIST: Fast and Robust Neural Network Joint Model for Statistica...
Yusuke Oda
 
生物データベース論(並列分散計算フレームワーク)
生物データベース論(並列分散計算フレームワーク)生物データベース論(並列分散計算フレームワーク)
生物データベース論(並列分散計算フレームワーク)
Masahiro Kasahara
 
NSDI '16 Reading: Flexible Networks Session
NSDI '16 Reading: Flexible Networks SessionNSDI '16 Reading: Flexible Networks Session
NSDI '16 Reading: Flexible Networks Session
Daisuke Kotani
 
Windows Azure の中でも動いている InfiniBand って何?
Windows Azure の中でも動いている InfiniBand って何?Windows Azure の中でも動いている InfiniBand って何?
Windows Azure の中でも動いている InfiniBand って何?
Sunao Tomita
 
Extract and edit
Extract and editExtract and edit
Extract and edit
禎晃 山崎
 
201207 ssmjp
201207 ssmjp201207 ssmjp
201207 ssmjp
th0x0472
 
Persistence on Azure - Microsoft Azure の永続化
Persistence on Azure - Microsoft Azure の永続化Persistence on Azure - Microsoft Azure の永続化
Persistence on Azure - Microsoft Azure の永続化
Takekazu Omi
 

Similar to 論文紹介: An empirical evaluation of in-memory multi-version concurrency control (16)

輪読資料: Staring into the abyss an evaluation of concurrency control with one t...
輪読資料: Staring into the abyss  an evaluation of concurrency control with one t...輪読資料: Staring into the abyss  an evaluation of concurrency control with one t...
輪読資料: Staring into the abyss an evaluation of concurrency control with one t...
 
Programming camp 2008, Codereading
Programming camp 2008, CodereadingProgramming camp 2008, Codereading
Programming camp 2008, Codereading
 
Bi-Directional Block Self-Attention for Fast and Memory-Efficient Sequence Mo...
Bi-Directional Block Self-Attention for Fast and Memory-Efficient Sequence Mo...Bi-Directional Block Self-Attention for Fast and Memory-Efficient Sequence Mo...
Bi-Directional Block Self-Attention for Fast and Memory-Efficient Sequence Mo...
 
ななめ45°から見たJavaOne
ななめ45°から見たJavaOneななめ45°から見たJavaOne
ななめ45°から見たJavaOne
 
遺伝研 Rina Aizawa ユーザミーティング
遺伝研 Rina Aizawa ユーザミーティング遺伝研 Rina Aizawa ユーザミーティング
遺伝研 Rina Aizawa ユーザミーティング
 
CouchDB JP & BigCouch
CouchDB JP & BigCouchCouchDB JP & BigCouch
CouchDB JP & BigCouch
 
Cassandraのトランザクションサポート化 & web2pyによるcms用プラグイン開発
Cassandraのトランザクションサポート化 & web2pyによるcms用プラグイン開発Cassandraのトランザクションサポート化 & web2pyによるcms用プラグイン開発
Cassandraのトランザクションサポート化 & web2pyによるcms用プラグイン開発
 
ACL Reading @NAIST: Fast and Robust Neural Network Joint Model for Statistica...
ACL Reading @NAIST: Fast and Robust Neural Network Joint Model for Statistica...ACL Reading @NAIST: Fast and Robust Neural Network Joint Model for Statistica...
ACL Reading @NAIST: Fast and Robust Neural Network Joint Model for Statistica...
 
生物データベース論(並列分散計算フレームワーク)
生物データベース論(並列分散計算フレームワーク)生物データベース論(並列分散計算フレームワーク)
生物データベース論(並列分散計算フレームワーク)
 
NSDI '16 Reading: Flexible Networks Session
NSDI '16 Reading: Flexible Networks SessionNSDI '16 Reading: Flexible Networks Session
NSDI '16 Reading: Flexible Networks Session
 
Consistency level
Consistency levelConsistency level
Consistency level
 
Windows Azure の中でも動いている InfiniBand って何?
Windows Azure の中でも動いている InfiniBand って何?Windows Azure の中でも動いている InfiniBand って何?
Windows Azure の中でも動いている InfiniBand って何?
 
MlnagoyaRx
MlnagoyaRxMlnagoyaRx
MlnagoyaRx
 
Extract and edit
Extract and editExtract and edit
Extract and edit
 
201207 ssmjp
201207 ssmjp201207 ssmjp
201207 ssmjp
 
Persistence on Azure - Microsoft Azure の永続化
Persistence on Azure - Microsoft Azure の永続化Persistence on Azure - Microsoft Azure の永続化
Persistence on Azure - Microsoft Azure の永続化
 

More from Sho Nakazono

述語ロックの歴史 r2
述語ロックの歴史 r2述語ロックの歴史 r2
述語ロックの歴史 r2
Sho Nakazono
 
Checkpointing Algorithms on In-memory DBMS
Checkpointing Algorithms on In-memory DBMSCheckpointing Algorithms on In-memory DBMS
Checkpointing Algorithms on In-memory DBMS
Sho Nakazono
 
LineairDBの紹介 MySQL編
LineairDBの紹介 MySQL編LineairDBの紹介 MySQL編
LineairDBの紹介 MySQL編
Sho Nakazono
 
ファントム異常を排除する高速なトランザクション処理向けインデックス
ファントム異常を排除する高速なトランザクション処理向けインデックスファントム異常を排除する高速なトランザクション処理向けインデックス
ファントム異常を排除する高速なトランザクション処理向けインデックス
Sho Nakazono
 
論文紹介: Cuckoo filter: practically better than bloom
論文紹介: Cuckoo filter: practically better than bloom論文紹介: Cuckoo filter: practically better than bloom
論文紹介: Cuckoo filter: practically better than bloom
Sho Nakazono
 
[xSIG 2018]InvisibleWriteRule: Extended write protocol for 1VCC
[xSIG 2018]InvisibleWriteRule: Extended write protocol for 1VCC[xSIG 2018]InvisibleWriteRule: Extended write protocol for 1VCC
[xSIG 2018]InvisibleWriteRule: Extended write protocol for 1VCC
Sho Nakazono
 

More from Sho Nakazono (6)

述語ロックの歴史 r2
述語ロックの歴史 r2述語ロックの歴史 r2
述語ロックの歴史 r2
 
Checkpointing Algorithms on In-memory DBMS
Checkpointing Algorithms on In-memory DBMSCheckpointing Algorithms on In-memory DBMS
Checkpointing Algorithms on In-memory DBMS
 
LineairDBの紹介 MySQL編
LineairDBの紹介 MySQL編LineairDBの紹介 MySQL編
LineairDBの紹介 MySQL編
 
ファントム異常を排除する高速なトランザクション処理向けインデックス
ファントム異常を排除する高速なトランザクション処理向けインデックスファントム異常を排除する高速なトランザクション処理向けインデックス
ファントム異常を排除する高速なトランザクション処理向けインデックス
 
論文紹介: Cuckoo filter: practically better than bloom
論文紹介: Cuckoo filter: practically better than bloom論文紹介: Cuckoo filter: practically better than bloom
論文紹介: Cuckoo filter: practically better than bloom
 
[xSIG 2018]InvisibleWriteRule: Extended write protocol for 1VCC
[xSIG 2018]InvisibleWriteRule: Extended write protocol for 1VCC[xSIG 2018]InvisibleWriteRule: Extended write protocol for 1VCC
[xSIG 2018]InvisibleWriteRule: Extended write protocol for 1VCC
 

Recently uploaded

エンジニアのセルフブランディングと技術情報発信の重要性 テクニカルライターになろう 講演資料
エンジニアのセルフブランディングと技術情報発信の重要性 テクニカルライターになろう 講演資料エンジニアのセルフブランディングと技術情報発信の重要性 テクニカルライターになろう 講演資料
エンジニアのセルフブランディングと技術情報発信の重要性 テクニカルライターになろう 講演資料
Toru Miyahara
 
ビジュアルプログラミングIotLT17-オープンソース化されたビジュアルプログラミング環境Noodlの紹介
ビジュアルプログラミングIotLT17-オープンソース化されたビジュアルプログラミング環境Noodlの紹介ビジュアルプログラミングIotLT17-オープンソース化されたビジュアルプログラミング環境Noodlの紹介
ビジュアルプログラミングIotLT17-オープンソース化されたビジュアルプログラミング環境Noodlの紹介
miyp
 
本の感想共有会「データモデリングでドメインを駆動する」本が突きつける我々の課題について
本の感想共有会「データモデリングでドメインを駆動する」本が突きつける我々の課題について本の感想共有会「データモデリングでドメインを駆動する」本が突きつける我々の課題について
本の感想共有会「データモデリングでドメインを駆動する」本が突きつける我々の課題について
Masatsugu Matsushita
 
Compute Units/Budget最適化 - Solana Developer Hub Online 6 #SolDevHub
Compute Units/Budget最適化 - Solana Developer Hub Online 6 #SolDevHubCompute Units/Budget最適化 - Solana Developer Hub Online 6 #SolDevHub
Compute Units/Budget最適化 - Solana Developer Hub Online 6 #SolDevHub
K Kinzal
 
「VRC海のおはなし会_深海探査とロボットのお話」発表資料
「VRC海のおはなし会_深海探査とロボットのお話」発表資料「VRC海のおはなし会_深海探査とロボットのお話」発表資料
「VRC海のおはなし会_深海探査とロボットのお話」発表資料
Yuuitirou528 default
 
今さら聞けない人のためのDevOps超入門 OSC2024名古屋 セミナー資料
今さら聞けない人のためのDevOps超入門 OSC2024名古屋  セミナー資料今さら聞けない人のためのDevOps超入門 OSC2024名古屋  セミナー資料
今さら聞けない人のためのDevOps超入門 OSC2024名古屋 セミナー資料
Toru Miyahara
 
Linuxサーバー構築 学習のポイントと環境構築 OSC2024名古屋 セミナー資料
Linuxサーバー構築 学習のポイントと環境構築 OSC2024名古屋 セミナー資料Linuxサーバー構築 学習のポイントと環境構築 OSC2024名古屋 セミナー資料
Linuxサーバー構築 学習のポイントと環境構築 OSC2024名古屋 セミナー資料
Toru Miyahara
 

Recently uploaded (7)

エンジニアのセルフブランディングと技術情報発信の重要性 テクニカルライターになろう 講演資料
エンジニアのセルフブランディングと技術情報発信の重要性 テクニカルライターになろう 講演資料エンジニアのセルフブランディングと技術情報発信の重要性 テクニカルライターになろう 講演資料
エンジニアのセルフブランディングと技術情報発信の重要性 テクニカルライターになろう 講演資料
 
ビジュアルプログラミングIotLT17-オープンソース化されたビジュアルプログラミング環境Noodlの紹介
ビジュアルプログラミングIotLT17-オープンソース化されたビジュアルプログラミング環境Noodlの紹介ビジュアルプログラミングIotLT17-オープンソース化されたビジュアルプログラミング環境Noodlの紹介
ビジュアルプログラミングIotLT17-オープンソース化されたビジュアルプログラミング環境Noodlの紹介
 
本の感想共有会「データモデリングでドメインを駆動する」本が突きつける我々の課題について
本の感想共有会「データモデリングでドメインを駆動する」本が突きつける我々の課題について本の感想共有会「データモデリングでドメインを駆動する」本が突きつける我々の課題について
本の感想共有会「データモデリングでドメインを駆動する」本が突きつける我々の課題について
 
Compute Units/Budget最適化 - Solana Developer Hub Online 6 #SolDevHub
Compute Units/Budget最適化 - Solana Developer Hub Online 6 #SolDevHubCompute Units/Budget最適化 - Solana Developer Hub Online 6 #SolDevHub
Compute Units/Budget最適化 - Solana Developer Hub Online 6 #SolDevHub
 
「VRC海のおはなし会_深海探査とロボットのお話」発表資料
「VRC海のおはなし会_深海探査とロボットのお話」発表資料「VRC海のおはなし会_深海探査とロボットのお話」発表資料
「VRC海のおはなし会_深海探査とロボットのお話」発表資料
 
今さら聞けない人のためのDevOps超入門 OSC2024名古屋 セミナー資料
今さら聞けない人のためのDevOps超入門 OSC2024名古屋  セミナー資料今さら聞けない人のためのDevOps超入門 OSC2024名古屋  セミナー資料
今さら聞けない人のためのDevOps超入門 OSC2024名古屋 セミナー資料
 
Linuxサーバー構築 学習のポイントと環境構築 OSC2024名古屋 セミナー資料
Linuxサーバー構築 学習のポイントと環境構築 OSC2024名古屋 セミナー資料Linuxサーバー構築 学習のポイントと環境構築 OSC2024名古屋 セミナー資料
Linuxサーバー構築 学習のポイントと環境構築 OSC2024名古屋 セミナー資料
 

論文紹介: An empirical evaluation of in-memory multi-version concurrency control

  • 2. 2Yingjun Wu, Joy Arulraj, Jiexi Lin, Ran Xian, and Andrew Pavlo. 2017. An empirical evaluation of in-memory multi-version concurrency control. Proc. VLDB Endow. 10, 7 (March 2017), 781-792. トランザクション: ◦ 不可分な一連の操作 == n回のread/write操作(0<n) トランザクション処理の目標: ◦ Atomicity: n回のread/write操作を1回のレジスタ操作と同様に扱えること ◦ Consistency: 一貫性を守ること. A,I,Dに加えてDBの制約条件を常に満たすこと ◦ Isolation: トランザクションが他の並行するTxの影響を受けないこと ◦ Durability: コミット済みのトランザクションは必ず永続化されていること トランザクション処理の構成要素: ◦ ログ管理機構(Log manager) ◦ 並行実行制御(Concurrency Control) ◦ データ構造, インデックス(Data Structure) トランザクションと並行実行制御
  • 3. 3Yingjun Wu, Joy Arulraj, Jiexi Lin, Ran Xian, and Andrew Pavlo. 2017. An empirical evaluation of in-memory multi-version concurrency control. Proc. VLDB Endow. 10, 7 (March 2017), 781-792. MVCC(Multiversion Concurrency Control) ◦ データベースが複数のバージョンを管理すること ◦ 論理的なObject(x)が物理的にMVで表現されているということ ◦ Not-In-place update. ◦ 対義語は1VCC. ◦ In-place update. ◦ 1VCCはアカデミアでは優勢だが、industrialではMVCCだらけ…なぜか? MVCC 101
  • 4. 4Yingjun Wu, Joy Arulraj, Jiexi Lin, Ran Xian, and Andrew Pavlo. 2017. An empirical evaluation of in-memory multi-version concurrency control. Proc. VLDB Endow. 10, 7 (March 2017), 781-792. MVCC Advantage
  • 5. 5Yingjun Wu, Joy Arulraj, Jiexi Lin, Ran Xian, and Andrew Pavlo. 2017. An empirical evaluation of in-memory multi-version concurrency control. Proc. VLDB Endow. 10, 7 (March 2017), 781-792. 直列実行との等価性にはいくつか細分類がある. 「Serializable」という場合,このどれかのクラスに当てはまる処理結果であること(または,そのような 処理結果を生成するアルゴリズムであること)を指す 並行実行制御とスケジュール空間 最終状態が等価なスケジュール(FSR) マルチバージョン等価なスケジュール(MVSR) ビュー等価なスケジュール(VSR) 競合等価なスケジュール(CSR) 1V系(2PL/OCC/TO)アルゴリズム 理論的に広くかつ計算量も現実的. MVCCを(まともにやれば)実装できる 直列実行 NP完全(提案なし) 現在有用だと考えられていないclass
  • 6. 6Yingjun Wu, Joy Arulraj, Jiexi Lin, Ran Xian, and Andrew Pavlo. 2017. An empirical evaluation of in-memory multi-version concurrency control. Proc. VLDB Endow. 10, 7 (March 2017), 781-792. There is no standard implementation ◦ 同じMVCCでも、実装のDesign Decisionによって性能が変わる ◦ Versionは線形リストで持つか? ◦ 線形リストはASC/DESCどちらにするか? ◦ 無限のストレージは無いので,線形リストにはGC(Compaction)が要る. ◦ いつ/誰がやるか? ◦ Indexのleafには何を書くか? ◦ TupleのPhysical Pointerにするか、間接参照するか? ◦ このようなDesign Decisionは今までアカデミアで議論されてこなかった ◦ MVCC?はいはい,MVCCね.という感じで,細かい実装の違いは無視されてきた MVCC Design Choices
  • 7. 7Yingjun Wu, Joy Arulraj, Jiexi Lin, Ran Xian, and Andrew Pavlo. 2017. An empirical evaluation of in-memory multi-version concurrency control. Proc. VLDB Endow. 10, 7 (March 2017), 781-792. Empirical Evaluation for Design Decision 1. Concurrency control 2. Version storage 3. Garbage Collection 4. Index Management Peloton(https://github.com/cmu-db/peloton)上に実装 ◦ CMU Andy Pavloらが主導するOSS RDBMS ◦ このリポジトリから論文が多く出ている ◦ Tile-based Architecture(ICMD’16) ◦ Self-Driving Database(CIDR’17) ◦ Relaxed Operator Fusion(VLDB’17) ◦ Write-Behind Logging(VLDB’16) 学生の授業課題がこのリポジトリへのcontribution. Contribution
  • 8. 8Yingjun Wu, Joy Arulraj, Jiexi Lin, Ran Xian, and Andrew Pavlo. 2017. An empirical evaluation of in-memory multi-version concurrency control. Proc. VLDB Endow. 10, 7 (March 2017), 781-792. ◦ Evaluationの前に,Tuple Format(線形リストのノード構造体)を紹介する. ◦ これ以後の全ての実験でこのFormatを用いる. ◦ Txn-idは書いたトランザクションのid. ◦ Idはunique and monotonically increasing. ◦ begin-tsとend-tsはuint64_t. ◦ Begin-ts < 自分のTS < end_ts なら読める,という風に使う ◦ これをCASすることでロックに使う ◦ 例: 1. begin-tsをINFにして自分のwriteを反映させた新しいversion tupleを作る. 2. リスト末尾のTupleのend-tsを0にCASする(と,誰も読めなくなるので,lockに等しい) 3. pointerを自分が作ったタプルにつなぐ 4. End-tsを自分のTidにする(unlockに等しい) Tuple Format
  • 9. 9Yingjun Wu, Joy Arulraj, Jiexi Lin, Ran Xian, and Andrew Pavlo. 2017. An empirical evaluation of in-memory multi-version concurrency control. Proc. VLDB Endow. 10, 7 (March 2017), 781-792. MVTO(Multiversion Timestamp Ordering) ◦ 商用DBに実装無し ◦ 通称Tx本(weikum)/CC本(bernstein)という本では紹介されている ◦ まずTimestampをallocateし、それに従ってRead/Write ◦ 例:自分がT2だとする ◦ Ti(i<2)のwriteを読む ◦ Tj(2<j)が既にreadしている場合は自分のwriteが遅すぎた。アボート ◦ MVSRになる(うまく実装すれば) ◦ MVSRにしようとすると,線形リストが V1 -> V5 -> V3…と順不同になるので,実装するのにやや工夫がいる ◦ そのへんの理由で実装が無いのだと思われる(私の主観) Concurrency Control: MVTO T1 T2 TS Alloc TS Alloc Write(x1)Read(x0) Linearization Point Write(y2) Linearization Point Read(y0) Read(x1) Commit Commit
  • 10. 10Yingjun Wu, Joy Arulraj, Jiexi Lin, Ran Xian, and Andrew Pavlo. 2017. An empirical evaluation of in-memory multi-version concurrency control. Proc. VLDB Endow. 10, 7 (March 2017), 781-792. Concurrency Control: MVOCC T1 T2 TS Alloc TS Alloc Write(x1)Read(x0) Linearization Point Write(y2)Read(x0) Validation(x) Commit Validation(x) Abort
  • 11. 11Yingjun Wu, Joy Arulraj, Jiexi Lin, Ran Xian, and Andrew Pavlo. 2017. An empirical evaluation of in-memory multi-version concurrency control. Proc. VLDB Endow. 10, 7 (March 2017), 781-792. •MV2PL(Multiversion Two Phase Locking) • よく知られている2PLをMVCCに拡張したもの • read the most recent version(∈uncommitted) • write after all concurrent writer has committed • commit after all concurrent reader/writer has committed • readがblockしないだけで、事実上ほぼ2PL? • 1Vで使っていた2PLのアルゴリズムをそのままMVに引っ張ってきただけに読める Concurrency Control: MV2PL T1 T2 TS Alloc TS Alloc Write(x1)Read(x0) Read(x1) Commit Commit rlock commit wait
  • 12. 12Yingjun Wu, Joy Arulraj, Jiexi Lin, Ran Xian, and Andrew Pavlo. 2017. An empirical evaluation of in-memory multi-version concurrency control. Proc. VLDB Endow. 10, 7 (March 2017), 781-792. Comparison(SSI,SSNは省略…)
  • 13. 13Yingjun Wu, Joy Arulraj, Jiexi Lin, Ran Xian, and Andrew Pavlo. 2017. An empirical evaluation of in-memory multi-version concurrency control. Proc. VLDB Endow. 10, 7 (March 2017), 781-792. YCSB Benchmark: ReadOnly
  • 14. 14Yingjun Wu, Joy Arulraj, Jiexi Lin, Ran Xian, and Andrew Pavlo. 2017. An empirical evaluation of in-memory multi-version concurrency control. Proc. VLDB Endow. 10, 7 (March 2017), 781-792. YCSB Benchmark: ReadWrite Mixed
  • 15. 15Yingjun Wu, Joy Arulraj, Jiexi Lin, Ran Xian, and Andrew Pavlo. 2017. An empirical evaluation of in-memory multi-version concurrency control. Proc. VLDB Endow. 10, 7 (March 2017), 781-792. YCSB Benchmark: Contention
  • 16. 16Yingjun Wu, Joy Arulraj, Jiexi Lin, Ran Xian, and Andrew Pavlo. 2017. An empirical evaluation of in-memory multi-version concurrency control. Proc. VLDB Endow. 10, 7 (March 2017), 781-792. Oldest-to-Newest(O2N) ◦ 線形リストの末尾にデータを追加していく ◦ ReadでもWriteでも,たいていの場合リスト末尾までのVersion traverseが必要になる ◦ GCが遅れるとリストが伸びて不要なランダムI/Oが…… Newest-to-Oldest(N2) ◦ 線形リストの先頭(HEAD)にデータを追加していく ◦ O(1)で(latest)read/writeできる ◦ HEADを更新する == インデックスも更新する ◦ Secondary indexがある場合,その更新も同時,というかatomicである必要がある ◦ 間接参照を挟めばatomicに出来るが、これは不要なランダムアクセスか? Version Storage: Append-only
  • 17. 17Yingjun Wu, Joy Arulraj, Jiexi Lin, Ran Xian, and Andrew Pavlo. 2017. An empirical evaluation of in-memory multi-version concurrency control. Proc. VLDB Endow. 10, 7 (March 2017), 781-792. Time-travel ◦ SAP HANAの実装. ◦ Main TableにはLatest Versionのみ置く. ◦ 古いVersionはTime-travel Storageという別の領域に置く.この領域はN2O ◦ Write時に毎回Main to Timetravelのcopyが発生する ◦ 歴史的経緯で複数のストレージが合体して生まれたSAP HANAならではのデザインか? Delta ◦ MySQL and Oracle uses this ◦ タプルの全内容ではなく更新の差分をN2Oでリストにする ◦ Partial updateに強い.リストの各ノードにコピーするデータ量が大幅に減る ◦ ただしSELECT * FROM…とかされると,リストを辿ってレコードの欠片を拾い集めないといけないので辛い Version Storage: Timetravel & Delta
  • 18. 18Yingjun Wu, Joy Arulraj, Jiexi Lin, Ran Xian, and Andrew Pavlo. 2017. An empirical evaluation of in-memory multi-version concurrency control. Proc. VLDB Endow. 10, 7 (March 2017), 781-792. YCSB Benchmark: Footprint
  • 19. 19Yingjun Wu, Joy Arulraj, Jiexi Lin, Ran Xian, and Andrew Pavlo. 2017. An empirical evaluation of in-memory multi-version concurrency control. Proc. VLDB Endow. 10, 7 (March 2017), 781-792. YCSB Benchmark: Memory Allocation Memory spaces: mallocできるareaの数.(多分) Deltaはfootprintが⼩さくなるのであまり影響を受けない.
  • 20. 20Yingjun Wu, Joy Arulraj, Jiexi Lin, Ran Xian, and Andrew Pavlo. 2017. An empirical evaluation of in-memory multi-version concurrency control. Proc. VLDB Endow. 10, 7 (March 2017), 781-792. YCSB Benchmark: Contention
  • 21. 21Yingjun Wu, Joy Arulraj, Jiexi Lin, Ran Xian, and Andrew Pavlo. 2017. An empirical evaluation of in-memory multi-version concurrency control. Proc. VLDB Endow. 10, 7 (March 2017), 781-792. Garbage Collection: Tuple-Level ◦ 前提: RCU-based memory reclamation(QSBR) ◦ 各TxnにはTxn-idがある.これは単調増加する ◦ m = min({Tid | all runnning transactions}) を計算する ◦ end_ts < m のタプルはもう誰も読めるものが居ない. ◦ すなわちGCできる ◦ Background Vacuuming(VACUUM) ◦ PostgreSQL,Oracle, MySQL ◦ ワーカスレッドとは別にGC専用スレッドを立て,定期的に各テーブル/レコードをGCしていく ◦ Cooperative Cleaning(COOP) ◦ Microsoft SQL Server(Hekaton) ◦ トランザクションを実行するワーカスレッドがGCする ◦ 開始時にmを計算して,m以下のノードをGCしながら走っていく ◦ 古いデータを見つけ次第即時GCされていくので,無駄なリストのtraverseを最小化できる ◦ が,誰にも読まれず書き込みだけが連続する場合,リストが伸び続ける問題がある
  • 22. 22Yingjun Wu, Joy Arulraj, Jiexi Lin, Ran Xian, and Andrew Pavlo. 2017. An empirical evaluation of in-memory multi-version concurrency control. Proc. VLDB Endow. 10, 7 (March 2017), 781-792. Garbage Collection: Transaction-Level
  • 23. 23Yingjun Wu, Joy Arulraj, Jiexi Lin, Ran Xian, and Andrew Pavlo. 2017. An empirical evaluation of in-memory multi-version concurrency control. Proc. VLDB Endow. 10, 7 (March 2017), 781-792. YCSB Benchmark: Tuple-Level
  • 24. 24Yingjun Wu, Joy Arulraj, Jiexi Lin, Ran Xian, and Andrew Pavlo. 2017. An empirical evaluation of in-memory multi-version concurrency control. Proc. VLDB Endow. 10, 7 (March 2017), 781-792. YCSB Benchmark: Tuple vs Transaction
  • 25. 25Yingjun Wu, Joy Arulraj, Jiexi Lin, Ran Xian, and Andrew Pavlo. 2017. An empirical evaluation of in-memory multi-version concurrency control. Proc. VLDB Endow. 10, 7 (March 2017), 781-792. YCSB Benchmark: Tuple vs Transaction
  • 26. 26Yingjun Wu, Joy Arulraj, Jiexi Lin, Ran Xian, and Andrew Pavlo. 2017. An empirical evaluation of in-memory multi-version concurrency control. Proc. VLDB Endow. 10, 7 (March 2017), 781-792. •Logical Pointer • 間接参照を用いて,各Indexは間接参照を指すようにする • セカンダリインデックスがあるN2Oでも,Atomicに更新できる • 間接参照先を何にするかで流派がある • Primary Key: セカンダリインデックスに触った場合,Primary Indexを再Traverseさせることになる • Tuple ID: 線形リストのheadに直接つなぐ. •Physical Pointer • Indexに(B-treeならLeafに)Version Chainをそのまま置く • セカンダリインデックスをアトミックに更新したいならLockする Index Management
  • 27. 27Yingjun Wu, Joy Arulraj, Jiexi Lin, Ran Xian, and Andrew Pavlo. 2017. An empirical evaluation of in-memory multi-version concurrency control. Proc. VLDB Endow. 10, 7 (March 2017), 781-792. YCSB Benchmark: Tuple-Level
  • 28. 28Yingjun Wu, Joy Arulraj, Jiexi Lin, Ran Xian, and Andrew Pavlo. 2017. An empirical evaluation of in-memory multi-version concurrency control. Proc. VLDB Endow. 10, 7 (March 2017), 781-792. これまで「MVCC」と言われてきたDBMSを同じワークロードで評価. これだけ性能が変わる理由はこれまで述べてきたDesign Decisionで説明できる…… (と論文では言っている) おまけ: Configuration Comparison
  • 29. 29Yingjun Wu, Joy Arulraj, Jiexi Lin, Ran Xian, and Andrew Pavlo. 2017. An empirical evaluation of in-memory multi-version concurrency control. Proc. VLDB Endow. 10, 7 (March 2017), 781-792. • https://twitter.com/andy_pavlo/status/902863242774634496 • 論文タイトルで三回rejectされている • タイトルが全部強気で面白い 余談