图说论文《An Empirical Evaluation of In-Memory Multi-Version Concurrency Control》
本文从《 An Empirical Evaluation of In-Memory Multi-Version Concurrency Control》摘取部分图片,来介绍 MVCC。 该文从并发控制协议,版本存储模型,垃圾回收机制,索引机制四个方面阐述了 MVCC 的现状。
更多详细内容,请查看原文。
元数据
DBMS 一般会为每个数据版本维护一个用以协调并发事务的 Tuple 数据。 Tuple 版本的 Header 一般会包含以下四个元数据字段:
- txn-id: 该字段一般作为该版本 Tuple 版本的写锁。若 txn-id 字段为 Tid, 则表示 ID 为 Tid 的事务,获取了该 Tuple 版本的写锁;当写事务处理完成后, 该字段会被置为 0。
- begin-ts 和 end-ts:标识当前该 Tuple 版本的生命周期起止时间。当改 Tuple 版本被删除时, 它的 begin-ts 会被置为 INF。
- pointer:前置/后续邻居版本的地址。
并发控制协议
并发控制协议负责协调并发事务的执行。它确定是否允许某个事务访问或变更指定的 Tuple 版本,是否允许提交某个事务的变更。
MVTO(Timestamp Order)
- read-ts:Tuple 版本中新增 read-ts 字段作为读锁。当有事务发起读取操作时,会更新该字段为 m a x ( T i d max(T_{id} max(Tid, read-ts)。仅在 T i d T_{id} Tid 大于 read-ts 时,事务才能对该 Tuple 版本发起变更操作。
- READ: 当事务 T 发起对 Tuple A 的 READ 请求,DBMS 会查找
[begin-ts, end-ts]
区间包含 Tid 的物理 Tuple 版本执行 READ 操作。如 Fig 2(a) 中, 事务 T 的 READ A 能操作 Ax 的条件是 T i d ∈ [ 10 , 20 ] T_{id}\in[10, 20] Tid∈[10,20]。 - WRITE: Fig 2(a) 中,事务 T 获取了 B x B_{x} Bx 的写锁且 T i d T_{id} Tid 大于 B x B_{x} Bx 的 read-ts,因此该事务可以创建新的 Tuple 版本 B x + 1 B_{x+1} Bx+1。
MVOCC(Optimistic Concurrency Control)
MVOCC 假定事务的冲突的概率很小,因此在读写过程中不会对 Tuple 版本加锁。它将事务分成三个阶段。
- READ 阶段/Normal Processing 阶段:事务在本阶段正常执行读写操作,并且不会阻塞在当前阶段。
- VALIDATION 阶段/Preparation 阶段:事务在这个阶段会决定是否提交或终止。
- WRITE 阶段/Postprocessing阶段:如果事务提交成功,本阶段会将原 Tuple 版本( B x B_{x} Bx)的 end-ts 设为 T i d T_{id} Tid ,将新创建的Tuple版本( B x + 1 B_{x+1} Bx+1) 的 begin-ts 和 end-ts 分别设为 T i d T_{id} Tid 和 I N F INF INF.
MV2PL(Two-phase Locking)
Tuple 的写锁就是它的 txn-id 字段, 为了增加读锁功能,DBMS 需要为 Tuple 增加 read-cnt 字段作为读锁,该字段用于记录正在读取改 Tuple 的事务数。
- READ 操作: Fig 2© 中,对于 Tuple A 进行读操作, DBMS 会通过对比事务的 T i d T_{id} Tid 和元组的 begin-ts 字段来搜索一个可见的版本。如果它找到一个有效的版本且该 Tuple 的 txn-id 字段等于零(没有被其他事务持有写锁),DBMS就会增加该 Tuple 的 read-cnt 字段(持有读锁)。
- WRITE操作:Fig 2© 中,仅在 B x B_{x} Bx 的 read-cnt 和 txn-id 都为零(读写锁都未被其他事务持有)的情况下,才可以对其执行更新操作。当一个事务提交时,会被分配一个唯一时间戳( T c o m m i t T_{commit} Tcommit),用以更新该事务创建的 Tuple 版本的 begin-ts 字段。最后释放该事务的所有锁。
Serialization Certifier
通过维护一个序列化图来感知和处理可能存在事务冲突的场景。
版本存储模型
DBMS 的版本存储模型确定系统如何存储这些版本以及每个版本包含哪些信息。
Append-only Storage
在 Append-only Storage 模型下, 所有的 Tuple 版本都存储在相同存储空间。更新一个现有的 Tuple,DBMS 会先从表中获取一个空槽作为新的Tuple 版本。然后, 将当前版本的内容复制到新版本。最后,在新分配的版本槽中应用对 Tuple 的修改。
根据不同业务场景, Append-only Storage 一般有两种维护 Tuple 版本的方式:
- Oldest-to-Newest (O2N):如图 Fig 3(a), Tuple 链的 HEAD是最旧的 Tuple 版本。这么做的好处在于不必在每次 Tuple 更新时,同步更新索引指向 Tuple 链表的指针。但缺点在于每次查询操作都需要遍历整个链表读取链尾最新 Tuple 版本的数据。
- Newest-to-Oldest (N2O):如图 Fig 3(b), Tuple 链的 HEAD是最新的 Tuple 版本。在大部分读取最新 Tuple 版本的事务,DBMS 不必遍历整个 Tuple 链表。但缺点是每次 Tuple 更新操作,都需要同步更新索引(包括主键索引和非主键索引)指针指向新的 Tuple 版本。
Time-Travel Storage
如图 Fig 3( c)。 在 Time-Travel Storage 模型下, DBMS 只将 Tuple 的 master 版本保存在 main table 中,其他同 Tuple 的更多的版本则保存在独立的 time-travel table。(main table 中保存的 master 版本可以是 Newest 版本,也可以是 Oldest 版本)。
Delta Storage
如图 Fig3(d) 。在 Delta Storage 模型下, DBMS 只将 Tuple 的 master 版本保存在 main table 中,并在独立的 delta 存储中保存一些列的 delta 版本。
垃圾回收机制
GC 流程分为三步:
- 检测过期版本。DBMS 任务认为所有 active 事务不可见的版本和所有无效的版本(即由中止的事务创建的版本)是过期的版本。
- 从索引和相关的 Tuple 版本链上 unlink 过期版本。
- 回收存储空间。
如 Fig4,MVCC 有两种常见的 GC 方式: Tuple-level 的垃圾回收和 Transaction-level 的垃圾回收。
索引机制
- Logical Pointer: DBMS 增加一个中间层(indirection),将一个 Tuple 的标识符映射到其版本链的 HEAD。这就避免当一个 Tuple 被修改时,必须更新所有索引指向一个新的物理位置的问题(即使索引的属性没有被改变)。
- Physical Pointer:DBMS 在索引条目中存储了 Tuple 版本的物理地址。这种方法只适用于 append-only 存储(因为在这种方式下,DBMS 把版本存储在同一个表中,因此所有的索引都可以指向它们。)
图说论文《An Empirical Evaluation of In-Memory Multi-Version Concurrency Control》相关推荐
- 【深度学习论文阅读】TCN:An Empirical Evaluation of Generic Convolutional and Recurrent Networks for Sequence
2018年人工智能十佳论文之一:TCN 论文地址:An Empirical Evaluation of Generic Convolutional and Recurrent Networks for ...
- 【论文阅读】An Empirical Evaluation of Generic Convolutional and Recurrent Networks for Sequence Modeling
1.摘要 一般而言,序列模型与循环网络(recurrent networks)关系紧密(由于RNN的循环自回归结构能较好地表达出时间序列).而传统的卷积网络(convolutional network ...
- An Empirical Evaluation of Generic Convolutional and Recurrent Networks for Sequence Modeling
TCN:An Empirical Evaluation of Generic Convolutional and Recurrent Networks for Sequence Modeling 该论 ...
- Staring into the Abyss: An Evaluation of Concurrency Control with One Thousand Cores 论文阅读笔记
Staring into the Abyss: An Evaluation of Concurrency Control with One Thousand Cores 论文阅读笔记 Concurre ...
- An Empirical Evaluation of Generic Convolutional and Recurrent Networks(中文版+注释)(时序预测)(TCN时域卷积网络)
TCN (An Empirical Evaluation of Generic Convolutional and Recurrent Networks 中文版+注释)百度网盘链接一般卷积和递归网络的 ...
- 【论文分享】SMOKE: Scalable Path-Sensitive Memory Leak Detection for Millions of Lines of Code
论文名:SMOKE: Scalable Path-Sensitive Memory Leak Detection for Millions of Lines of Code 来源会议:ICSE 201 ...
- 【论文笔记】Multi-modal Knowledge-aware Event Memory Network forSocial Media Rumor Detection
论文标题:Multi-modal Knowledge-aware Event Memory Network forSocial Media Rumor Detection 论文链接:https://s ...
- 解决Out of memory error (version 1.2-rc4 ‘Carnac‘ (298900 ... by android-jack-team@google.com)).
Android 7.1编译到33%时出现JDK内存溢出的错误: Out of memory error (version 1.2-rc4 'Carnac' (298900 f95d7bdecfceb3 ...
- 分布式事务2PC论文翻译(Concurrency Control and Recovery in Database Systems )
作者:Philip A. Bernstein, Vassos Hadzilacos, Nathan Goodman. 1987 原文:Concurrency Control and Recovery ...
最新文章
- CSS之布局(盒子模型--外边距)
- 根据16S预测微生物群落功能最全攻略
- java hdfs 新建目录_如何用java在hdfs中创建一个新目录?
- python调用shell命令-「Python」6种python中执行shell命令方法
- iOS之富文本(二)
- 多线程:Immutable对象?如何创建Immutable对象?
- LOG4J 警告错误处理办法(转)
- JQuery的 serializeObject 序列化form表单
- 10月24日见!iQOO Neo 855版官宣:跑分不输骁龙855Plus
- QTP自动化测试从零基础到精通进阶(脚本测试、VBS语法、描述性编程、测试框架)...
- Linux特殊符号浅谈
- 各类w3school网站的区别小记
- 游戏文化VS文化游戏(第二篇)
- 中国石油大学远程教育《应急救援概论》第一阶段在线作业
- 微信小程序动态更改标题栏_微信小程序动态改变导航栏标题和背景颜色
- 软件测试面试题--银行面试
- python音频频谱分析软件_SpectrumView(音频频谱分析软件)
- IB书单推荐:没有所谓的“闲书”
- Q: 'BMap' is not defined?BMap初始化报错爆红
- LintCode——Chalkboard XOR Game(黑板游戏)