Page 392 - 《软件学报》2024年第6期

2968 软件学报 2024 年第 35 卷第 6 期

3.3 版本回收优化
SAP HANA、Hyrise、HyPer 等数据库通过对 MVCC 的优化, 提高了混合负载下版本追踪的效率. 但如何有
效地回收旧版本, 避免长事务带来性能下降依然是个需要解决的难题.
垃圾回收的关键问题是如何确定垃圾数据版本. 传统的做法是维护一个全局活跃事务最小时间戳 T min , 若版
T min , 则版本被继续保留, 也因而很容易被某个启动较早但执行较长的事务阻碍垃圾回收进程. Lee 等人 [66]
本戳大于
提出一种基于间隔 (interval) 的回收机制, 使用一个间隔区间 [s, e) 标识某个数据项 v 在不同快照版本下可被观测
到的时间戳范围. 比如 v 1 版本时, v 2 为 4, 则 v 1 对于启动时间戳在 [1, 4) 的事务可见. 与此同时, 如果在当前全局活
v 1 的版本可以被回收. 这样就可以解除对全局最小
跃的事务集合中, 并没有落在该戳间隔内的事务, 则该区间内
时间戳的依赖, 也缓解了长事务造成中间版本不能回收的问题.
Bottcher 等人 [28] 也取缔了维护全局活跃事务集合的方法, 让不同的线程独立维护不相交的活跃事务子集, 以
O(#threads) 的时间复杂度确定全局最小时间戳, 一定程度上减小了全局共享互斥锁的竞争, 提高可扩展性; 另一方
v current , 遍历 v visible v current ]
面通过在版本链中确定发起查询时当前可见的版本戳 v visible 以及正在写入的最新版本戳 [ ,
区间内每个时间点下的数据版本是否在 v visible 之后有修改. 如果没有修改, 则其不会被任何事务访问删除. 论文也
p
指出对于垃圾回收机制来说, 清理的粒度、执行的频率、精度等方面也会对性能产生较大的影响, 需要审慎考量.
Kim 等人 [67] 提出可以将最近可能会被访问的一个旧版本与数据元组共同存储在一起 (in-row), 剩余多个版本
则存储在额外的存储空间内 (off-row). 同时, 他们面对 off-row 中旧版本回收问题, 也提出了与文献 [66] 类似的理
念, 即比较版本生命周期和事务启动时间戳范围来确定版本是否可回收, 从而避免了长事务挂起的版本清理阻塞.
同时, 该工作在上述 in-row 和 off-row 中间引入了额外的版本缓冲空间 (buffer), 在 buffer 内提前对数据版本进行
分类和预清理, 基于一定的阈值和事务执行时间判断该版本属于热版本、冷版本还是长事务持有的版本, 进而对
其进行不同粒度的剪裁和清理, 降低长事务对整体性能的影响.
4 研究展望与未来方向

不同的一致性模型对应不同的数据共享方式, 反映为 TP 写更新版本和 AP 版本读版本之间的版本标识号差
异程度, 即最新更新版本和当前读版本的版本标识号差距 p, 以及同一时刻多个读版本的版本标识号差距 q, 如
表 4 所示. p 和 q 的不同取值决定了数据库系统对性能和新鲜度指标的权衡. 本文从数据生命周期中最为重要的
3 个子问题出发, 对性能和新鲜度这两个指标的权衡进行了总结.
在数据的产生阶段, 即 TP 端的写事务生产新数据版本阶段, 一致性模型主要影响标识号的分配. 在线性一致
性模型下, TP 和 AP 端的标识号同步分发, 从而保证高新鲜度, 即共享模型中 p=0 且 q=0, 这也同时要求实现快速
的版本同步, 会对数据库的性能造成一定的影响; 在顺序一致性和会话一致性中, AP 端在回放产生数据版本时推
进对应的标识号, 因此 AP 端的标识号与 TP 端相比可以存在一定的时延, 即 p=n, 导致了一定的新鲜度损失, 但也
同时减轻了同步的压力, 有利于稳定数据库性能. 不同的标识号分配机制对应了数据新鲜度和数据库性能之间不
同的权衡策略. 总而言之, 模型对一致性的要求越高, AP 端的标识号推进速度越快, 对数据库性能的影响越大. 因
此, 根据应用场景对数据新鲜度和数据库性能的不同要求, 需要选择不同的数据库一致性模型.

表 4 不同一致性模型下数据共享模型的约束

一致性级别 q
线性一致性 0 0
带新鲜度阈值约束的一致性 ϵ 0
顺序一致性 n 0
会话一致性 n n

在数据的同步阶段, 即写副本同步到读副本或备份副本的过程中, 主要的同步方式分为日志同步和数据同步
两种. 其中多数数据库日志同步采用将写节点的日志持久化后同步到其他节点上, 随后在对应节点回放日志的方