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

胡梓锐 等: HTAP 数据库系统数据共享模型和优化策略 2969

式推进多副本的版本. 这一阶段的优化主要是降低日志持久化和回放的耗时. 数据同步则是通过直接拷贝新数据
版本快照的方式更新版本, 通过控制拷贝快照粒度减少拷贝的代价, 从而提高同步的效率.
在数据的消费阶段, 即分析查询访问数据阶段, 优化主要针对版本的组织方式. 版本组织需要解决 HTAP 场景
下快速产生大量版本增加分析查询的版本扫描负担, 以及长分析查询导致的大量版本无法及时回收等问题. 学术
界提出了多种新颖的数据结构以优化版本扫描效率的算法. 对于 LSM-Tree 的优化主要解决如何加速从树的多层
结构里高效追踪某个数据版本的问题. 而索引扫描方面则重点在于结合版本和索引的信息加速 AP 的读取, 但当
前的数据库产品大多采用简单的链式存储方案, 存在一定的优化空间. 对于版本回收的问题, 也有研究致力于准确
识别和删除无效版本, 从而提高版本回收的效率.
总的来说, 目前 HTAP 数据库系统的优化主要集中于降低版本同步开销和多版本查询的代价. 前者关注一致
性模型中标识号推进以及版本同步的流程; 后者关注在混合负载上支持高效的写入和查询. 针对 HTAP 场景的特
征以及现有技术总结, 本文提出 3 个值得进一步关注的优化方向, 即数据同步范围自适应, 数据同步周期自调优以
及顺序一致性下的新鲜度阈值约束控制.
端执行分析查询, 导致
4.1 数据同步范围自适应
主流的分离式 HTAP 数据库系统大都会直接将 TP 最新写入的修改批量同步到 AP 端进行数据重组和更新.
这一同步策略应用的前提是 TP/AP 端对数据的需求重合度较高, 且该批数据具有较高应用价值. 但实际上, TP/AP
端读写的热点数据未必保持一致, 即耗费大量资源进行数据同步可能并不能达到最大收益. 因此, 结合 TP/AP 端
负载的特征和数据的状态, 设计自适应的数据同步策略, 按需进行数据的快速同步是 HTAP 数据库系统在性能优
化时值得关注的问题.
4.2 数据同步周期自调优

HTAP 数据库系统通过日志在进行数据同步时, 往往需要设置一个同步周期间隔以实现对 TP 更新的批量传
输, 如 Vegito [16] 提出在设置相对较小的 Epoch 间隔时, 会由于频繁的小批量同步对 TP 端带来较大的性能影响, 反
之较大的 Epoch 间隔则会带来较低的数据新鲜度. 所以同步周期的划分粒度同样需要在性能和新鲜度之间做出有
效的权衡. 而近年来, 深度学习在系统自调优上已经有了非常广泛的应用 [69–71] , 通过负载预测和系统性能监测等方
式可以实现系统自主调优, 以维持一个稳定的性能状态. 此类方法同样可以尝试应用在 HTAP 数据库系统同步周
期的选取上, 通过实时监测系统性能水平, 数据新鲜度, 底层数据状态, 负载特征等信息对数据同步周期进行自调

优, 以实现较好的同步效果.
4.3 顺序一致性的新鲜度阈值约束控制

不同一致性模型对读取版本的要求综合考虑了系统性能和数据新鲜度的需求, 同时具有不同的数据共享约
束. 对于大部分的实际业务而言, 并不要求极高的数据新鲜度, 只需要保证数据新鲜度能满足业务场景的需要即
可. 目前大部分 HTAP 数据库系统受一致性模型的约束, 完美的数据新鲜度和高吞吐往往不能同时保证. 线性一致
性模型适用于对数据新鲜度高要求的场景, 但对数据库的吞吐和延迟有较大影响; 顺序一致性模型中无法严格保
证新鲜度, 容易变为对 OLAP 数据库的简单加强, 无法实现实时分析的目标. OceanBase 提出的有界旧一致性读模
型 [72] 和 IBM 的 IDAA [46] 都对这一问题进行了探索. 在该一致性模型下, 若 AP 端同步速度过慢, 导致数据新鲜度低
于某一阈值时, 数据库选择直接从 TP 端读取最新的数据, 在牺牲分析性能的同时保证数据新鲜度稳定在阈值之
上. 但可能会遇到需要长期在 TP TP 端性能降低以及对 AP 端资源的浪费. MongoDB 提出
的 Decongestant [73] 采用了类似的思路, 支持在主副本所在节点压力过大时读取其他节点中较不新鲜的副本, 但同
样要求当其他节点新鲜度过低时只能在主副本读取. 因此, 结合 TP/AP 负载对吞吐和数据新鲜度的需求, 在特定
的一致性机制下对数据新鲜度的阈值进行动态选择, 使 AP 端读取的版本与 TP 端最新版本的差距 p 在某个既定
ϵ (0 ⩽ ϵ ⩽ n) 之内 (如表 4 所示), 从而在提高性能的同时满足应用对数据新鲜度的需求是 HTAP 数据库系统
阈值
在设计和实现一致性机制时值得关注的问题.