CMU Database Systems - MVCC

 

MVCC是一种用空间来换取更高的并发度的技术

对同一个对象不去update，而且记录下每一次的不同版本的值

存在不会消失，新值并不能抹杀原先的存在

所以update操作并不是对世界的真实反映，这是一种便于应用的简化实现

MVCC的历史可以追溯到70年代，数据库的主流技术大部分都停滞在那个年代

MVCC，可以解决2PC的频繁读写冲突；使用MVCC只有写写才会存在冲突，大大降低了冲突的概率

而且MVCC还能进行time-travel

 

例子，DB中有Begin，End表示该version生效的时间周期，write的时候会产生新的version，同时修改上一个version的end

右图，仍然读的是A0，因为t1的ts=1，在A0的范围中

 

例子，

T2的R读到的是A0，因为T1还没有commit(取决于隔离程度) ；并且T2执行W的时候会锁等，因为写写发生冲突

 

当T1 commit后，T2的锁释放，开始写入

这时候的行为取决于隔离程度，如果serializable的，那么T2会失败，因为T2读的是A0，而这时看T2应该读的是A1，所以存在不一致 

 

下面的图表明MVCC被大量的数据库所使用，

 

 MVCC在发生写写冲突时，仍然是需要并发控制协议，主要是之前学习的2PC或OCC

 

 多版本的存储方式，主要有如下的方式，

Append Only，比较直接的方式，HBase，PG都是采用这种方式

为了快速找到同一个对象的多个版本，可以用链表来组织，那么旧的放前面，还是新的放见面，完全是看场景

新的放前面比较直觉，因为一般都是需要读最新的数据，但是这样每次新增都需要更新head指针

Time travel就是把最新的table和历史table分离

Delta只记录差值

 

 

 垃圾回收，纯粹是工程实践，

定期过期活跃thread已经不用时间段的数据，这里有个设计是，加上Bitmap来表示这个page是否有更新，这样Vacumm不用去检查每个page，没更新的就不用检查

 Worker thread在遍历的时候，随便找到过期的

 

如果用MVCC，那么index就需要指向chain head

可以看到对于secondary index，如果有很多，每次head变化都要更新很多，非常低效

所以有两种方式，

思路都是，通过逻辑id，间接的指向Physical address，这样只需要改一个地方 

 

这里列出所有数据库在MVCC上的实现方式