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

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


                  2.3   数据共享模型案例分析
                    除了各个一致性模型下所满足的一致性特征之外, 还有一些在数据生命周期影响数据库性能的实现手段值得
                 关注. TP  端数据自诞生伊始直至被         AP  端读取消费, 其存在如上所述的完整共享过程和生命周期; 但在具体实现
                 上, 也存在部分    HTAP  数据库系统或是学术研究尝试从并发控制机制本身, 如对                  MVCC  进行优化实现对混合负载
                 的处理, 则此时    TP/AP  间不存在严格意义上的数据同步.
                    数据版本标识号分发阶段, HTAP         数据库系统在不同的一致性模型下具有不同的版本标识号实现和管理方法.
                 对于采用   MVCC  机制的数据库系统       [4,8] , 标识号通过版本戳实现; 对于通过日志落盘确定版本的数据库系统, 标识
                 号通过   LSN  实现  [13,15] ; 对于采用  COW  等机制的数据库系统  [5] , 标识号不表现为具体的版本戳/日志号数值, 而是
                 通过创建一个旧版本数据快照进行版本的粗粒度标识, 以体现数据新旧程度. 更进一步, 在版本标识号分发时, 线
                 性一致性下会使用单机        TSO (timestamp oracle) [39] 、全局  TSO  和原子钟等分配  MVCC  的版本戳, 在顺序一致性下
                 会使用已同步的日志号或已同步的最小              Epoch  日志号来返回读请求的版本         [16] , 在会话一致性下则会使用缓存中
                 已同步的日志号      [14,15] .
                    在数据版本同步阶段, 一般而言, 现代            HTAP  数据库系统往往都会通过内存/网络数据拷贝                [3,4] 或是日志同
                    HyPer 是基于内存的单机数据库, 其最新的版本采用了
                 步  [12] 的方式进行  TP/AP  端数据的共享, 且一般需要补充一些额外的功能以支持数据的同步与回放, 如                         TP  端
                 针对发送日志的控制手段以及            AP  端从行存到列存格式的转换等. 同时同步的内容和范围也会对                     TP  和  AP  的
                 性能产生影响. 大部分数据库会采用写操作结束后异步更新的方式, 但也有部分数据库支持同步备份以满足
                 高可用等需要, 同步更新延缓了事务的提交, 进而影响吞吐. 目前                     HTAP  系统普遍以日志作为同步内容, 并通
                 过回放日志等方式将数据更新到对应的副本中, 直接针对数据进行同步的方式并不多见. 由于需要同步大量
                 数据版本, 基于回放日志的方式更新版本会带来较大的磁盘                     IO  开销, 甚至包括格式转换时对存储和计算资源
                 的消耗. 与之相对的同步方式是直接拷贝数据, 这避免了格式转换的计算资源消耗, 但会带来较大的                                  IO  传输
                 开销. 另一方面, 在同步数据范围上, 大部分数据库同步全量的修改, 少数数据库只需要在每个周期结束时同
                 步当前周期所产生的最终版本. 但周期设置得过短时, 频繁地同步会一直对性能造成影响, 而周期设置得过长
                 会导致延迟过大. 也正因为同步方式的不同, 对于需要读取最新版本的接收端而言, 等待最新版本同步的延迟
                 也有所不同.
                    在数据版本追踪阶段, AP       端进行分析查询的性能很大程度取决于数据版本的组织方式和全局一致性快照的
                 确认机制. 在多副本的情况下, 不同副本间可能采用不同的版本组织方式: 多版本副本大多采用链式数据结构进行
                 存储, 可能会根据链上版本产生的时间组织成从新到老                   (newest-to-oldest, N2O) 或从老到新 (oldest-to-newest,
                 O2N) 的形式, 通常采用遍历版本链的方式检索合适的版本; 优化分析查询的副本也可能只保存单副本, 从而减少
                 检索版本的开销. 对于不同的数据库, 追踪全局一致快照的方式有所不同. 当选取当前时间戳对应版本作为读取版
                 本时, 可能需要等待      TP  端完成相应数据的同步; 当选取某个较旧版本时, 又会损失一定的新鲜度.
                    综上所述, 在版本生命周期的         3  个环节中, 存在各种因素需要权衡, 因此不同数据库会选择不同的实现方式以
                 适用于不同的应用场景. 在表         2  中, 根据前文一致性模型的定义对主流          HTAP  数据库进行分类, 并依据分类和具体
                 的实现手段对各个系统进行了总结.
                  2.3.1    支持线性一致性的数据库系统
                         [6]
                                                                MVCC  机制以支持    HTAP  业务, 其中  TP 就地更新数
                 据并将旧版本镜像增量存储在每个事务独立的缓冲区中. 所有进入系统的新事务都与                           3 个变量相关联: 即    startTime、
                 事务号和   commitTime. startTime 和事务号在事务产生时自动分配, commitTime 在事务提交时直接从本地单机获
                 取, 查询只能看到时间戳先于         startTime 的数据版本, TP 在就地更新的过程中, 会将新版本的时间戳暂时更新为事
                                                                      63
                 务号, 由于事务号一定远远大于时间戳            (时间戳从    0  开始, 事务号从  2 开始), 这样就保证了还未提交的数据只能
                 由自身看到. 就地更新和旧版本数据镜像增量存储不仅保证了                     AP  高效的扫描, 还使    HyPer 具备轻量且细粒度的
                 可串行化验证机制, 从而简化了         TP  事务的隔离逻辑.
   378   379   380   381   382   383   384   385   386   387   388