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上的实现方式
