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

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

两个目标的权衡最终体现在数据版本的确定、同步、追踪处理的各个环节. 所以数据共享模型需要解决的问题可
以归纳为保证 TP 端维持稳定吞吐的前提下, 如何控制 AP 端读到 TP 端实时生产数据的延时以及读取数据的一致性.
一致性模型的强弱决定了 TP 所修改的数据被 AP 可见的速度, 具体反映为数据共享模型中 TP 和 AP 数据版本
之间的差异. 下文将从一致性模型的角度进一步分类 HTAP 数据库系统, 探讨其内部数据共享模型的具体实现机制.

数据生产 数据共享 数据消费
事务处理引擎 查询处理引擎

数据版本标识号的分配 数据版本的同步 数据版本的追踪

图 3 数据生命周期不同阶段的子问题

2.2.1 线性一致性
持
线性一致性模型要求读请求返回执行时刻对应的最新数据版本, 为此 HTAP 数据库系统需要为 TP 端和 AP
端使用同一套版本标识号管理器, 以保证两者有相同的标识基准. 在线性一致性模型中, 标识号的分配一般是以事
务为单位, 即基于事务提交时间生成数据版本标识号.
由于在线性一致性模型下, 读操作始终读取最新的数据, 其对数据版本的同步速度要求严格, 容易导致资源竞
争. 对于单机数据库系统, 影响主要体现在多副本合并存储所带来的资源竞争; 对于分布式数据库系统, 线性一致
性约束要求各节点完成数据同步后才能读取, 因此若各节点间数据独立则可以一定程度上避免这一问题, 但这一
数据划分方式无法支持负载均衡并造成主节点在事务管理上的瓶颈问题. 所以, 在单机情况下, 快速同步所带来的
资源竞争会导致 TP 端的吞吐下降, 而多机不同副本间的同步等待时间过长会增大读请求的延迟, 因而对分析性
能产生负面影响.
在线性一致性中, 对于单机数据库系统, AP 查询主要基于并发控制协议追踪最新的数据版本. 而对于分布式
数据库系统来说, AP 端需要确认查询发起前的最新版本已完成同步, 才能追踪到最新的数据版本. 确认机制一般
有两种, 一种是读节点主动问询主节点的最新版本标识号; 另一种是主节点定期推送最新版本标识号给只读节点,
使只读节点获知这段时间内数据的修改状态.
综上所述, 线性一致性模型适合对一致性要求高, 需要强一致性读的场景; 与此同时, 高一致性通常是以数据
库整体性能下降为代价实现的.
2.2.2 顺序一致性
顺序一致性模型要求同一时刻的版本读取返回相同前缀序列对应的数据版本, 且不晚于上一时刻返回的版
本. TP 和 AP 端可以使用不同的标识号管理器进行相对独立的数据读取, 但 AP 端需要共用同一套标识号管理器
以确保 AP 端读取版本的一致性. 需要注意的是, AP 端的标识号管理器通过回放的版本确定标识号, 而不是重新
申请分发.
由于顺序一致性不要求读取 TP 端最新的数据版本, 所以数据库系统可以适当降低同步频率, 如可以基于
Epoch 进行阶段性同步, 只同步同一阶段的最终版本, 减少同步数据量, 减轻繁重的同步任务对资源的抢占, 对保
TP 负载高吞吐有积极的影响.
顺序一致性适当放松数据新鲜度的要求, 一般只读取当前同步到的版本, 避免了 AP 负载的同步等待. 在追踪
已同步到的版本快照时, 根据同步的分区数量有不同的追踪方法. 同步队列为单个队列时, 数据库可以利用已同步
的标识号作为全局标识号进行读取. 同步队列为多分区并行同步时, 需要以当前所有分区已同步的最小标识号作
为读请求的版本.
综上所述, 由于数据库允许在顺序一致性下适当降低同步速率、放松数据新鲜度的要求, 所以更适合处理写
密集的负载, 很好地避免了批量读取数据造成的长时间同步延迟. 但在顺序一致性模型下, 减轻同步压力是以降低