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

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

拷贝/传输等. 这一概念抽象地构建了 TP 数据生产至 AP 数据消费的全流程.
1.2.1 资源隔离
TP 负载通常具有在短时间内频繁读写小规模数据的特征, 对缓存的命中率和磁盘/网络 IO 的时延要求较高;
AP 负载往往需要执行大规模数据连接、聚合等计算密集型操作, 对 CPU/内存/磁盘等资源消耗较大. 因此由于
TP/AP 负载特性的不同, 并发执行两种负载时, 往往会对系统资源产生争用, 从而对性能造成较大的影响 [23,25] . 为
了避免两者的资源竞争, 实现稳定的服务保障, HTAP 数据库系统需要对 TP/AP 业务进行资源上的隔离. 目前, 资
源隔离主要有 3 种实现模式, 具体如图 1 所示.

1 一体式架构 (逻辑隔离) 2 分离式架构 (缓存隔离) 3 分离式架构 (存储隔离)
TP AP TP AP
TP/AP

共享存储

HTAP 数据库系统 行存 列存 TP/AP 端独立存储资源 数据同步

图 1 基于资源隔离的 HTAP 数据库系统分类

(1) 逻辑隔离 (unified storage): 在一体式架构下, 通过逻辑隔离基于同一套资源同时服务 AP 负载和 TP 负载,
如 HyPer [5,6] 、MemSQL [10] .
(2) 缓存隔离 (share storage): 分离式架构下基于缓存层隔离, 即 TP/AP 端共享一套底层存储资源, 而在缓存层
上进行资源隔离, 如 PolarDB [14] 、Aurora [15] .
(3) 存储隔离 (share nothing): 分离式架构下基于存储层隔离, 即 TP/AP 端的物理资源不再共享, 各自拥有独立
的存储引擎和计算引擎, 如 TiDB [12] .
1.2.2 数据共享 处理性能
无论使用何种资源隔离方式, 为了 AP 访问新鲜数据, 系统皆需要支持高效的数据共享, 即 TP 端生成的数据
能通过某种方式被 AP 端快速访问到, 如基于同一套单副本存储 [5] 、多副本间数据拷贝 [3,4] /传输 [12,13] 等. 然而对于
HTAP 数据库系统来说, 资源隔离程度越高, 数据共享的难度越大, 所以如何在资源隔离的情况下高效地实现数据
共享是 HTAP 数据库系统需要解决的核心问题之一. 具体地, 以上 3 种资源隔离方案会面临不同的数据共享挑战.
逻辑隔离 (unified storage): 在一体式架构下, 数据库可以通过类似租户或虚拟化等方法实现 TP 任务和 AP 任
务在单系统上的逻辑隔离. 通过共享单个存储引擎实现混合负载的数据共享, 即在事务层上使用多版本并发控制
机制 (MVCC) [26] 共享最新的快照给 AP 任务, 或是通过写时复制 (copy-on-write, COW) 为 AP 任务创建最新的物理
快照 [27] . 其中, MVCC 通过维护数据的多个物理版本, 允许数据旧版本读, 而不阻塞 TP 并发写入, 该设计理念受
到 HTAP 数据库系统的青睐 [28] . 但 TP 端的高吞吐, 可能造成短时间内系统积累大量的版本, 以版本链的方式组织
数据对 TP 的点读操作较友好, 但会严重影响 AP 大范围扫描性能. 同时, 运行时间较长的 AP 事务也会阻塞过期
版本回收, 从而影响 AP 的扫描性能和 TP [29] . 另外, 采用 COW 方式进行数据共享, 若 AP 并行度大, 会
占用大量内存, 易对 TP 的性能造成负面影响. 故而, 如何根据 TP/AP 负载访问模式的差异设计一体式的版本组织
方式是逻辑隔离下数据共享面临的主要挑战.
缓存隔离 (share storage): 缓存资源隔离架构可以避免缓存层及以上的资源冲突. 混合负载共享一套存储引擎,
通过 AP 端独立维护缓存快照的方式将数据共享给 AP 任务, 并允许多个 AP 端维护不同快照的数据版本, 具有较
高的读取效率. 但该方法会导致缓存层与存储层数据不一致, 故而如何从数据不一致的缓存层和存储层中追踪全
局一致的快照版本是该隔离方式面临的主要挑战.
存储隔离 (share nothing): 存储隔离架构为了实现数据共享, TP 端的存储引擎需要自动将日志或数据同步给