WBL论文：针对NVM设计日志记录及恢复协议

后写日志

Write behind logging

基本思想

NVM的优点是可字节寻址、接近内存的高性能、顺序访问和随机访问差距不大。2016年VLDB会议上《write behind logging》论文专门针对NVM设计了一种新的日志记录及恢复协议。主要思想是去掉了传统的append only的redo和undo日志，但仍然需要保留undo信息用来回滚未提交事务。事务提交前需要将该事务的所有修改强制刷盘，之后在log中记录commit标记，即这里所说的WBL。恢复过程中，通过分析commit标记将未提交的事务通过undo信息回滚掉。

而这篇论文在这个思想基础上又进行了一系列优化，下面介绍其机制。首先吐槽一下，这篇论文写得不是很清晰，理解起来比较困难。下面是深入理解后的机制，有不当地方还望指正。

机制

1、几个概念

DTT表中元组结构：事务ID＋表ID＋更改位置

数据页中的元组结构：

tuple id＋trx id＋begin commit时间戳＋ end commit时间戳＋上个版本号的tuple ID ＋data

Cp：该时间戳之后的提交的事务其数据不保证已经持久化到磁盘

2、一个事务操作过程

Begin；

执行操作，修改DRAM中的数据页

添加一个元祖到DTT表中，该元祖不包括插入后的值

Commit：

1）记录下各个该事务的提交时间戳t1

2）扫描DTT表得到该事务相关元组

3）计算cp和cd值

4）将DTT表中元组持久化到磁盘，此时元组中加上了提交时间戳t1

5）将cp和cd构成的WBL持久化到NVM

6）通知完成组提交，释放DTT

Rollback：

   1）通过DTT中信息进行回滚。

3、一个事务操作过程图示

若在trx6 commit的时间点，系统故障，那么重启时从WBL日志文件中遍历得到最后一个WBL即｛4，（5，100）｝，得到活跃的事务为4，大于5的事务都未提交。分析到这里恢复就完成，即可接受新事务。

但是磁盘上的脏数据怎么处理？会启用一个单独的回收线程，扫描表中记录，若记录的时间戳大于5，比如事务6的记录，他是不可见的，即将它回收掉；对于1，3，2，5都是可见的，不做处理，对于4，他在组提交未提交的事务链表里，也将它回收掉。

4、缺点及疑惑

1）文中没有详细说明记录是如何回收的，是后续事务访问到进行判断处理，还是说只是另外回收线程全部扫描进行判断。数据量如果特别大的话，扫描的代价岂不是很大？全部扫描完后，才将不用的WBL回收掉？

2）如果在高可用场景下，无法满足要求，仍然需要相应的WAL进行复制

3）后续的可见性判断比较复杂，文中没有详细说明