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

2962                                                       软件学报  2024  年第  35  卷第  6  期


                 (log-structured merge-tree) 以优化  AP  查询性能, 再通过一个行存副本保证高可用. 当     TP  端执行更新数据版本的请
                 求时, MemSQL  先将数据转换为内存中的行存副本, 等修改完成再快速更新到存储. 因此, 数据库在执行写后, 同
                 步地将数据复制到高可用副本中, 再异步地进行读写副本间的同步, 而                      AP  端在进行查询时需要等待数据库完成
                 异步的副本同步, 这一过程会产生一定的延迟. 但是由于行存和列存副本存储在同一节点上, 同步代价较小, 额外
                 延迟不高.
                    TiDB [12] 是一款分布式  HTAP  数据库系统, 将数据依据主键值划分为多个连续的块                (Region), 并以  Region  为单
                 位分散副本到多个节点中, 形成          Raft 组. 各个组内部基于    Raft 一致性协议   [42] 进行同步, 支持多节点读写. 在每个组
                 内, TiKV  节点采用行存处理     TP  负载, 作为  Raft 组中的  Master/Follower 节点进行即时同步, 同时   TiDB  维护了一
                 个额外的列存     TiFlash  节点处理  AP  负载, 它作为  Raft 组中的  Learner 节点  (需保证内部状态与其余节点相同, 但
                 不参与   Raft 组的选举和投票    [43] ) 接收数据的同步, 但并不要求      TiKV  产生的数据即时更新到       TiFlash  节点. TiDB
                 为了维护准确的版本顺序, 虽然支持多个节点同时进行读写操作, 但在各节点的数据不完全独立的情况下, 全局范
                 围内必须只有唯一的节点用于分配             TSO. 在执行  TP  负载产生新数据版本时, TiKV       节点会申请    TSO  确定新版本
                 的事务号, 然后采用基于       Raft 协议的同步机制异步地更新日志到其他节点, 接收日志的节点回放日志操作以更新
                 间点下读取的数据保持一致, 存在一定的时延, 并不保证强实时性.
                 数据版本, 实现数据同步. 异步更新降低了同步更新导致的                 TP  吞吐下降. 在  TiFlash  节点接收到  AP  读请求并开始
                 执行时, TiFlash  会为该读请求申请     TSO, 并等待   TiKV  将这一  TSO  对应的最新已提交版本同步到自身节点再读
                 取这一版本的数据, 这会导致一定的延迟.
                    Spanner [44] 与  TiDB  架构类似, 拥有多个节点组, 各个副本基于    Paxos 一致性协议   [45] 进行同步. 但  Spanner 的数据
                 中心在全球范围内分布, 若采用单节点管理             TSO  带来的通信代价难以忍受, 因此在不同的数据中心内均采用不同的
                 多个持有物理时钟的节点进行时间戳分配, 并借助这些节点间的通信将误差控制在一定范围内, 即                             Spanner 在维护全
                 局时间戳的同时采用多个物理时钟进行时间戳分配. Spanner 在               TP  事务提交时申请时间戳, 以这一时间戳作为基准,
                 基于  Paxos 协议进行版本日志同步. AP      端在执行读操作时也会申请          TSO, 并等待该   TSO  所对应的最新版本同步到
                 节点中再读取. 同样由于同步本身的耗时, 读请求在读取最新数据时需要等待日志同步完成, 导致一定的延迟.
                    综上所述, 支持线性一致性的数据库系统要求读请求返回最新的版本. 单机数据库可以通过共用一份数据以
                 满足要求, 但这种数据存储和使用方式无法同时优化                 TP/AP  负载的执行性能, 因此, 采用存储格式不同的增量/主
                 (delta/main) 分块组织数据是主流的解决方案. 而分布式数据库需要快速地全量日志同步以保证读取新鲜的数据版
                 本, 但这会抢占大量      TP  端的资源, 影响  TP  负载的性能. 为此, 大部分数据库选择将相同数据的              TP/AP  副本保存在
                 同一物理节点上以避免大量的日志同步. 即便对于副本保存于多节点的情况, 数据库也会采用异步更新的方式以
                 降低即时同步对      TP  的影响.
                  2.3.2    支持顺序一致性的数据库系统
                    F1 Lightning [13] 本质是一种类  ETL  的  HTAP  系统, 以在线即时的  CDC (change data capture) 的方式, 即实时提
                 取并记录源数据库的操作以供下游服务消费, 取缔了离线的                    ETL  操作, 支持混合负载处理. 该系统在逻辑上保持
                 TP  端与  AP  端的强分离. TP  端发起的事务由全局       TSO  分配序列号, 当有新的数据版本产生时, 它通过调用               CDC
                 接口, 异步进行事务日志的重构和回放, 以不阻塞               TP  写入的方式将新数据组织到        AP  端以列存形式存储备份. 同
                 时, 由于分布式场景下事务日志回放时间的不确定性, F1 Lightning             支持  AP  端快照一致的读取, 即与       TP  端某个时

                         [46]
                    IDAA   是一款   IBM  研发的  HTAP  数据库系统, 部署了事务处理能力较强的            Db2z 作为  TP  端, 部署列式存储
                 的  DB2 Warehouse 作为  AP  端, 并在  DB2 Warehouse 之上扩展了一个服务模块, 该模块包括数据变更的监视与应
                 用执行组件    InSync 和更新控制组件. 数据的标识号由事务的操作顺序确定. 当发生版本更新时, TP                     端以适合列存
                 使用的日志形式将版本同步到           AP  端, AP  端通过更新控制组件决定数据同步的粒度大小, 即选择                InSync 使用粗
                 粒度的表级/分区级的批量更新或是细粒度的增量修改完成同步. 对于读请求, 由                        InSync 判定读请求的版本是否已
                 同步到   AP  端, 若未完成同步则等待至最大等待时间, 再选择直接读取                TP  端中的对应版本或是直接终止查询. AP
                 端的  InSync 比  IBM  的  CDC  更轻量、更通用地维护阶段性的版本加载位点. 当完成连续两个版本加载位点之间
   381   382   383   384   385   386   387   388   389   390   391