Page 376 - 《软件学报》2024年第6期
P. 376
2952 软件学报 2024 年第 35 卷第 6 期
sequential consistency, and session consistency, according to the differences between TP generated versions and AP query versions. After
that, it takes a deep dive into the whole process of data-sharing models from three core issues, i.e., data-version number distribution, data
version synchronization, and data version tracking, and provides the implementation methods of different consistency models. Furthermore,
this study takes a dozen of classic and popular HTAP database systems as examples for an in-depth interpretation of the implementation
methods. Finally, it summarizes and analyzes the optimization strategies of version synchronization, tracking, and recycling modules
involved in the data-sharing process and predicts the optimization directions of the data-sharing models. It is concluded that the self-
adaptability of the data synchronization scope, self-tuning of the data synchronization cycle, and freshness-bound constraint control under
sequential consistency are the possible means for better performance of HTAP database systems and higher freshness.
Key words: HTAP database system; consistency model; data management; hybrid workload; performance optimization
1 引 言
1.1 HTAP 数据库系统
Gartner 于 2014 年给出了 HTAP 数据库系统的定义 [1,2] , 即支持在同一套数据库系统中同时进行事务处理
业务性能要求情况下, 实现
OLTP 和实时分析混合负载 (OLAP) 的数据库系统称为 HTAP 数据库系统. HTAP 数据库系统旨在实时分析事务
最新更新的数据. 在面对业务需要同时支持混合负载处理的场景下, 与原先的事务处理 (TP) 和分析处理 (AP) 系
统独立的解决方案相比, HTAP 数据库系统具有以下的优势.
• 兼备事务处理和分析查询的处理支持能力.
• 数据同步速度快, 支持实时分析.
• 部署和维护成本低.
[3]
[4]
在 HTAP 这一概念提出前 Hyrise 、SAP HANA 和 HyPer [5,6] 等单机数据库在 2010 年左右便已经开始探索
基于多种存储结构来同时支持事务处理和分析查询. 到了 2015 年, HTAP 概念的提出之际, Oracle 和 [7] SQL Server [8]
等传统数据库厂商便通过在原有的架构设计上进行扩展以支持 HTAP 业务. 同时随着分布式系统理论的不断延
[9]
拓, 又涌现出诸如 Greenplum 、SingleStore [10] 、FoundationDB [11] 等一批在分布式环境下支持高效的混合负载处
[12]
理能力的分布式数据库系统. 近年来, HTAP 概念的再度强化也使得越来越多的数据库厂商, 如 PingCAP 的 TiDB ,
Google 的 F1 Lightning [13] , 阿里巴巴的 PolarDB [14] 和 Amazon 的 Aurora [15] 等都开始以支持 HTAP 业务作为其产品
的重要标签, 在学术界也涌现出了诸多面向 HTAP 数据库系统的架构设计以及优化方案 [16–18] .
针对不同的应用场景, HTAP 数据库系统具有不同的应用目标, 相应地出现了不同架构的 HTAP 数据库系统.
比如, 面向银行等金融场景的实时监控业务, AP 任务对数据的实时性要求高, 希望 AP 端尽可能获取 TP 端写入的
最新数据, 进而保证分析的有效性; 在电商等互联网业务的秒杀和促销等场景上, AP 端则可以容忍一定的实时性
缺陷换取 TP 端更好的吞吐和业务扩展性. 因此, 与传统数据库相比, HTAP 数据库系统更关注处理性能与数据新
鲜度之间的权衡问题 [19] . 但无论 HTAP 数据库系统如何权衡两者, 需要保证基本的事务处理性能要求, 如若缺乏
对 TP 端吞吐的基本保证 (数据生成端), 用户的业务 SLA (service level agreement) 就无法保证 [20,21] . 也就是说, 在
保证基本 TP 能力的情况下, 可以通过损失一方的高性能, 提升另一方的性能. 所以 HTAP 数据库系统的目标通常
可以归纳为在保证基本的 TP AP 业务对新鲜数据的访问以及高吞吐分析处理能力, 即
支持实时分析 [22,23] .
1.2 资源隔离与数据共享
HTAP 数据库系统与传统的 OLTP/OLAP 数据库系统的最大区别就在于其在同一套系统里实现高效的混合
负载处理能力, 即在提供稳定、高效 TP 处理能力的同时, 实现快速、及时的 AP 分析处理能力. 对于追求一体化、
整体化的 HTAP 数据库系统来说, 其架构设计上存在两个核心难点问题.
• 资源隔离: 如何调度或者隔离 TP 负载和 AP 负载对资源的抢占, 如 CPU、缓存、磁盘 IO 等.
• 数据共享 [24] : AP 负载如何访问 TP 负载生产出的新鲜数据版本, 如基于同一套单副本存储、多副本间数据