数据持久化存取层(DataNode)关键技术方案
Datanode节点主要负责数据的持久化和快速写入、读取。数据持久化采用物理日志wal，事务提交wal刷盘， 对外提供逻辑日志功能，反解析物理日志为SQL逻辑日志。
图1 datanode数据持久化
Astore：存储格式为追加写优化设计，其多版本元组采用新、老版本混合存储方式。当一个更新操作将老版本元组更新为新版本元组之后，如果老版本元组所在页面仍然有空闲空间，则直接在该页面内插入更新后的新版本元组，并在老版本元组中记录指向新版本元组地址的指针。在这个过程中，新版本元组以追加写的方式和被更新的老版本元组混合存放，这样可以减少更新操作的IO开销。然而，需要指出的是，由于新、老版本元组是混合存放的，因此在清理老版本元组时需要从混杂的数据中挑出垃圾数据，清理开销会比较大。同时，由于新版本元组位置相对老版本元组位置发生了变化，而索引中只记录了老版本元组的位置，因此容易导致索引膨胀。为了缓解索引膨胀这个问题，对于同一个页面内的更新，采用了HOT技术，将同一个记录的多个版本按从老至新的更新顺序给串连起来，但是这种从老至新的更新链顺序，对于并发的OLTP类短查询是效率是比较低，需要遍历的版本个数较多。
Ustore：与astore相比，ustore的最大特点在于新、老版本记录的分离存储。当一个更新操作将老版本元组更新为新版本元组之后，直接在老版本元组的位置覆写新版本元组内容，同时，将老版本元组移到统一管理历史版本的undo区域。在这个过程中，既需要修改数据页面，也需要修改undo页面，更新操作开销较astore的追加更新稍大。但是，就如同垃圾分类回收一样，这样带来的好处也是显而易见的，在清理老版本元组时，不再需要遍历扫描主表数据，直接按需回收undo区域即可，垃圾清理开销较astore不仅大幅降低，而且稳定可控。同时，由于新版本元组复用老版本元组的物理位置，因此索引无需更新，索引膨胀得到有效控制。另外，在ustore中，多个版本的更新链按从新至老的顺序串连，对于并发查询更友好。总而言之，ustore更适合更新频繁的业务场景。
