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

胡梓锐 等: 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       端的存储引擎需要自动将日志或数据同步给
   372   373   374   375   376   377   378   379   380   381   382