标签：head T2 写写 A0 version Systems MVCC CMU
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上的实现方式
标签：head,T2,写写,A0,version,Systems,MVCC,CMU 来源： https://www.cnblogs.com/fxjwind/p/11246855.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。