后写日志
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）后续的可见性判断比较复杂，文中没有详细说明
原文及参考
http://www.vldb.org/pvldb/vol10/p337-arulraj.pdf
http://mysql.taobao.org/monthly/2019/01/01/
https://github.com/cmu-db/peloton/wiki/Write-Ahead-Logging
