多主数据库中基于分区的并发控制

刘文欣 蔡鹏

摘要：大数据时代，存储计算架构分离的单写多读场景已无法满足海量数据的高效读写需求;另一方面， 多个计算节点同时提供写服务还会引起计算节点间的缓存不一致.已有的研究采用全局有序的事务日志 来进行冲突检测，并通过广播和回放事务日志维护整个系统的数据一致性.但该类方案由于是在每个写节 点维护全局写日志，可扩展性较差.针对这些问题，提出了一个基于分区的并发控制方案：通过分区的方式 降低每个写节点需要维护的事务日志，以有效提升系统的扩展能力.基于此想法，在MySQL上实现了分区 多主插件，并通过实验验证了该解决方案对系统性能的影响.

关键词：多主数据库;分区;并发控制

中图分类号：TP392       文献标志码：A       DOI： 10.3969/j.issn.1000-5641.2021.05.008

Partition-based concurrency control in a multi-master database

LIU Wenxin， CAI Peng

（School of Data Science and Engineering， East China Normal University， Shanghai 200062， China）

Abstract： In the era of big data， the single-write multi-read process with separate storage and computing architectures can no longer meet the demands for efficient reading and writing of massive datasets. Multiple computing nodes providing write services concurrently can also cause cache inconsistencies. Some studies have proposed a global ordered transaction log to detect conflicts and maintain data consistency for the whole system using broadcast and playback of the transaction log. However， this scheme has poor scalability because it maintains the global write log at each write node. To solve this problem， this paper proposes a partition-based concurrency control scheme， which reduces the transaction log maintained by each write node by partitioning， and effectively improves the systems overall expansion ability.

Keywords： multi-master database; partition; concurrency control

0引 言

隨着云计算与大数据的发展，传统的关系型数据库已无法满足金融市场业务的需求，越来越多的 用户开始选择云数据库.计算存储分离架构是当下大多商业云数据库的解决方案.在此架构下，数据 库分为存储层和计算层两个部分：多个存储节点共同组成一个共享存储层为计算层提供可靠的持久 化存储服务;计算层则由多个计算节点组成，每个计算节点运行一个单独的数据库进程.计算节点缓 存一部分数据用于服务用户的读写请求，当缓存无法命中时，计算节点会遵循替换策略将需要的数据 从存储层读入缓存.大多云数据库的计算节点目前仅支持一写多读的架构，即计算层只存在一个计算节点拥有数据的读写权限，其余计算节点都仅拥有读权限.

为实现集群中写节点的扩展，数据库领域曾尝试利用锁机制实现同一时间仅有一个节点拥有数 据的写权限并通过网络传递数据页的方法实现多主之后提出基于日志的冲突检测或是确定性数 据库的解决方法.另一方面，为提高系统吞吐量，现存在部分系统选择将数据库进行分区，但因此引 入了跨分区事务这一·问题，导致需要在满足事务ACID （Atomicity， Consistency， Isolation， Durability） 特性与限制事务仅能够访问一个分区这两个条件中取舍.

对于存储计算分离的架构，实现多个写节点的一大难点在于各写节点缓存中数据的一致性维护. 如上所述，数据库读取数据会先从缓存读取，这样的机制便导致对于某个数据各写节点中缓存的版本 并不相同的情况出现.为解决这种情况，现有提出基于全局事务日志进行冲突检测的方法通过为每 个事务分配唯一的全局事务号，并以此事务号维护事务间的可串行化调度，在各个节点上根据事务调 度顺序回放与本地缓存数据相关的事务日志以更新各节点本地缓存.但在这样的解决方法下，随着写 节点数量的增加，事务数量增长导致日志规模急剧上升，在每个写节点上维护全局事务日志并依序检 查每条事务无疑会产生较多不必要的网络及计算存储资源的消耗.

综上所述，为了在计算存储分离架构的云数据库中实现写性能的扩展，本文基于MySQL设计并 实现多主分区事务插件.本文的主要贡献如下.

（1）设计分区算法.基于数据访问信息对事务进行分区，各分区内设计独立的验证器，并维护分区 独立的日志记录.

（2）设计事务序号的分配.通过事务序号实现可能有数据访问冲突的事务间的串行化，以事务序 号为验证基础的并发控制维护数据一致性.

（3）通过实验对比全局事务日志的解决方案，论证分区方法对多主数据库性能的影响.

本文后续内容：第1章介绍多主数据库相关工作;第2章介绍本文提出的基于分区的多主数据库 架构;第3章阐述分区算法的具体实现;第4章说明跨分区并发控制的设计;第5章通过实验验证本 文方案对系统性能的影响;第6章总结全文.

1相关工作

云数据库发展初期，大多实现方法仅是为传统的关系型数据库添加云存储，如今各大厂商逐渐推 出基于存储计算分离架构的云数据库.亚马逊率先推出计算存储分离的云数据库产品Aurora：6-'提出 “日志即数据库”的思想.其认为由于日志中已包含有数据的信息，故仅通过日志就可以恢复出数据， 可以仅向存储层传输Redo日志，减少网络I/O （Input/Output），并在存储层回放Redo日志生成数据 页供计算层读取;同时由写节点向读节点广播日志，读节点通过回放日志更新缓存，以此实现节点缓 存的一致.阿里云的PolarDB同样沿用存储计算分离的架构，通过写节点广播日志流帮助其余节点缓 存的更新，PolarDB的设计在计算层做的改动较少，其主要通过自研的分布式文件系统PolarFS[8]以 及存储引擎X-Engine[9]更好地利用高性能硬件的特性以实现存储层的优化.随后，微软推出的 Socrates[10]以及华为推出的Taurus[11]在计算层依旧沿用一写多读的设计，但存储层的设计各有特色.

迄今为止，大多数的商用云数据库只提供一写多讀的配置，即仅实现了读性能的扩展，而写性能 的扩展还没有很好的实践方案.目前已实现的多主解决方案，如Oracle RAC[1]和DB2 pureScale[2]，这 二者的设计思想都是利用锁机制和数据页的网络传输实现数据的一致性.不同的是，pureScale通过全 局锁管理器和全局缓存池实现，各个实例通过RDMA与二者通信;而Oracle RAC则是将锁管理器分 布在各个实例，并通过在实例间构建高速内联网络实现缓存融合.无论是集中式还是分布式的锁管理 方法，频繁的锁申请与数据页的传输都会限制整个系统的扩展性和吞吐量.

为消除锁的“瓶颈”，微软提出了一款日志结构的共享存储数据库模型Hyder[3]，其架构分为3 层——事务层、索引层、存储层.当本地事务执行完成后会将更新打包广播至存储层的日志末尾，所 有服务器都会依据此日志有序进行回放，包括一开始执行事务的服务器，并在回放日志的过程中进行 冲突检测（meld）.同时，Hyder认为冲突检测阶段是此系统的一大“瓶颈”.Bernstein等为此做了进一 步探究，提出了并行化meld加速冲突检测过程[12]，以及通过数据库分区将meld算法本身并行化[13]的 方法.

2系统架构

本文设计了如图1所示的多主数据库架构：沿用现有云数据库存储计算分离的架构，将数据库分 为存储层与计算层两个部分;每个计算节点上运行有独立的MySQL进程，这些计算节点会将日志和 数据页写到远程的共享存储上;通过分区算法将数据库划分至若干个分区，分区内的所有计算节点都 拥有本分区数据的读写权限;每个分区内有独立的事务日志以及验证器，故同一分区内的计算节点间 的缓存一致性可依靠分区内部有序的事务日志和验证机制实现.

由于每两个分区间的数据并不存在冲突，故两个分区间的事务可以并发执行.但在实际应用环境 中无法实现所有事务都仅访问一个分区，仍然会存在部分事务访问多个分区的情况.为避免复杂的分 区并发控制，本文设计了一个逻辑分区，用来处理所有的跨分区事务，即将单分区事务路由到该事务 所访问的分区执行，而访问多个分区的事务则会路由至逻辑分区执行.此设计下，两个单分区之间 依旧不存在数据冲突，因此可以并发执行;冲突只会存在于单分区与逻辑分区之间，故通过逻辑分区 与各单分区之间的并发控制便可以维护数据的一致性.

3分区算法

3.1动态分区

将数据库分区是提高系统吞吐量的有效方法之一.但常用的静态分区方法在时变负载下并不能 发挥很好的作用.为应对动态负载变化，本文提出了结合以页为单位的数据访问并查集运行分区算法

来实现动态分区.

本文提出的多主场景下的分区意味着以页为单位，将经常需要同时访问的数据页放置在同一个 分区内，同时各个分区内部署有若干拥有该分区数据读写权限的计算节点.除实际物理划分出的分区 外，本文设计了一个逻辑分区，用来处理访问多个分区的跨分区事务.分区内计算节点间通过其共同 维护的分区事务日志实现数据一致性，分区间跨分区事务与其相关单分区事务间的并发控制则由跨 分区并发控制维护.具体的并发控制方法将在第4章中详细介绍.

集群初始化时，将所有数据页划分至同一个单分区;运行过程中由计算节点异步地将记录的数据 访问信息发送至分区统筹节点;分区统筹节点收集一批次内的事务访问信息后，运行分区算法重新划 分分区，并将分区结果返回至各节点实现分区的重组.由于动态调整分区后会触发分区的拆分与合并， 可能造成部分计算节点需要同步新增数据之前的日志记录.这无疑是一个会影响系统性能的变动，故 分区的调整不应太过频繁.这一限制通过在分区统筹节点处设置定时机制触发分区算法来实现.同时， 当一个分区负载较大时，事务数量会增多，可能会导致该分区吞吐量有所下降.但因负载均衡问题不 是本文的论述重点，此分区算法保证不会加剧负载不均衡现象，不构成系统“瓶颈”，故本文不再过多 讨论负载均衡问题.

3.2分区算法

本文提出的基于数据访问信息的分区算法见算法1. “输入”中，Origin_partition是当前数据库的 分区情况，每个分区包含若干数据页;txn_set是分区与事务间的映射，表示某个分区下的事务集合; data_access_info是所有事务的数据访问信息集合.算法1中集群的产生利用了并查集这一数据结构， 属于同一集合中的数据页被归为同一个分区.算法1将事务分区划分为两大步骤：①对原分区进行拆 分;②将拆分后的分区合并.算法1代码部分，collections表示数据集合，若干数据页共同构成一个集 合;single—trx[p]表示分区p下的单分区事务集.

算法1分区算法

输人：当前数据库分区情况origm_partition;事务与其所访问分区的映射txn_set;事务的数据访问信息集合

输出：分区重新划分结果new_partition

//分区拆分阶段 1： For k* origin_partition do 2：   For single_trx[p] do

3：      随机选取p分区下的单分区事务T

4：      If T访问的数据不存在于其他集合then

5：      将T所访问的数据合并至同一集合collection

6：      将集合 collection 加人新分区 new_partition

7：      End if

8：      End  for

9：      For   T = single_trx[p]       do

10：   If T访问的数据集合数=0 then

11：   将T所访问的数据合并至同一集合collection

12：   将集合 collection   加人新分区     new_partition

Else if T访问的数据集合数=1 then

14：   将T所访问的数据合并至该集合

15：   End if

16：   End for

17： End for

//分区合并阶段

18： For all data_access_info do

19：统计集合两两之间的共同访问次数至count数组

20： End for

21： Repeat

22：以共同访问次数升序与降序交替的规律合并集合

23： Until跨分区事务的比例低于《

3.2.1分区拆分阶段

根据输入的数据访问信息data_access_info构建并查集，每个数据页最开始仅属于单独的一个集 合.拆分步骤以分区为单位进行，仅处理各分区内的单分区事务，故可以在各个分区间并行执行.

首先在分区内随机选择任一单分区事务，将其所访问的数据合并至同一集合，并将此集合添加至 new_partition作为新分区之一;若该事务所访问的数据中已有部分数据存在于其他新分区中，则跳 过这个事务不做任何操作，直至遍历视个此分区单事务.由于事务选择的随机性，访问次数较多的数 据大概率将会被分散至不同集合，这样的方式下有效避免了频繁访问的数据汇聚在同一集合的现象 出现.一次遍历以后，每个原单分区已包含有若干新分区，但仍存在有部分离散数据不属于任何新分区.

接下来开始第二次遍历，此次遍历依旧只访问单分区事务，获取事务的数据访问集，若是该事务 访问的新分区数目不超过1个，则将剩余数据合并至该新分区，否则不做任何操作.可以发现，在此步 驟中仅涉及独立的数据与新分区之间的合并，并不存在新分区之间的合并，此步骤结束后将原有的单 分区拆分成为若干个新分区.

3.2.2 分区合并阶段

上述步骤完成了对原有单分区的拆分，接下来通过一次遍历所有事务完善记录现有新分区间的 共同访问次数.为避免分区合并后导致大量负载集中在同一分区内，合并时按照访问次数升序和降序 交替的顺序合并分区，若次数相同，则优先合并组合中有新分区内仅存在单独数据或是原本属于同一 个分区的两个新分区，合并步骤持续至事务遍历完毕或是跨分区事务比例达到预设阈值《.

3.3逻辑分区

逻辑分区作为架构中较为特殊的一部分，需要处理跨分区事务，并维护全局事务日志，事务执行 开销较单分区事务而言更大，因此逻辑分区内事务执行时延将是系统整体吞吐量的一大影响因素，故 减小跨分区事务执行时延是系统设计时必须考虑的问题.

算法1中提到，分区算法控制跨分区事务比例不高于a （a的取值视网络情况和集群规模等因素 设置）.因此集群中大部分事务被划分至各单分区并发执行，同时各分区将事务日志异步发送至逻辑 分区，以至于逻辑分区能够不断更新，维护较为完整的全局事务日志，保证在执行跨分区事务时不会 因等待日志空洞而产生大量延时.

为保证冲突事务间的有序，跨分区事务的执行需要同其他分区沟通最新事务序号.为了减少网络 传输，本文设计将序号沟通控制在一次网络交互中，由逻辑分区发起，其他物理单分区在收到逻辑分 区的序号更新信息后返回本分区最新事务序号.同时逻辑分区需要维护每条跨分区事务对应单分区 的最新事务序号以保证串行化，这类信息的维护对逻辑分区而言也存在一定的资源占用，但由于跨分 区事务的比例较低，且此信息以较为简单的映射关系存在，事务完成后便可以删除此事务相关信息.

4并发控制

本文沿用事务日志的思想由于分配有全局唯一且递增的事务序号的事务形成的事务日志包含 了所有事务的提交顺序和数据修改操作，故通过扫描事务日志就可以检测出跨节点事务之间的冲突， 并通过日志的回放实现缓存的更新.不同于上述设计，由于维护全局事务日志带来的资源开销随节点 数量的线性增长，本文提出不再维护全局事务日志，而是选择在每个分区内设计独立的分区事务日志 和验证器.

属于同一分区的写节点通过分区事务日志即可以实现分区内的数据一致性，由于分区规模的限 制，分区事务日志较全局事务日志而言轻量很多.由于数据的不相交性，两个访问不同单分区的事务 可以在不破坏数据一致性的前提下并发执行，而访问多个分区的事务将会被路由至逻辑分区执行，因 此逻辑分区与其余单分区之间可能存在数据冲突，即存在一条事务日志出现在多个分区独立日志中 的情况，故需要在逻辑分区与各单分区之间引入跨分区并发控制，保证可能存在冲突的两个事务间的 相对顺序在任一分区日志内都是一致的.

4.1事务序号

本文设计为每条事务分配全局唯一的事务序号，依赖事务序号的顺序性进行冲突检测确定事务 提交与否.事务序号由3部分组成：事务所属分区P;事务所属分区序号S-TSN，表示事务在分区内部 的顺序位置;跨分区事务序号M-TSN，表示此事务对应的跨分区事务序号.

事务序号的比较规则：先比较M-TSN;再比较S-TSN.分区序号P用来区分事务所属分区，不同 分区下的单分区事务由于可并发，因此其序号不具有可比性.同一分区内的单分区事务拥有递增的S- TSN，而单分区事务的M-TSN的变化依赖于分区间交流，即逻辑分区下有跨分区事务执行时就会通 知其他单分区置其M-TSN+1;逻辑分区尸。下的事务S-TSN统一置为0，其通过递增的M-TSN表示 事务顺序.例如，事务序号TSN（J＼） = [0， 0， 3] < TSN（jy = [1， 5， 3]，代表在串行化序列中，事务 先于事务^提交;而TSN（J＼） = [0， 0， 3] > TSN（rO） = [1， 4， 2]代表事务晚于事务rO提交.

为防止长事务以及申请序号时的信息传递导致的时延影响，事务在开始执行时就会发起序号请 求，分配的序号不会直接分配给发起请求的事务，而是分配给计算节点本身，待此节点上有事务完成 后直接从节点的序号列表中获取序号，同时设置定时机制，及时将等待过长时间的序号置为无效序号. 4.2跨分区并发控制

由于需要通过事务日志实现冲突检测，故冲突检测的必要条件在于事务日志的传输，事务日志生 成后将会传输至所有与之相关的分区日志，即对应单分区与逻辑分区下的日志记录，并通过事务序号 的比较在日志中维护串行化顺序.事务的冲突检测同时依赖于事务日志的完整性，故对于日志中存在 的空洞部分设计补全机制向相关节点请求日志传输.

分区验证器通过事务日志中的串行化顺序与事务序号提供的信息，对比事务读写数据与冲突域 中各事务的修改数据之间的交集确定事务是否因存在数据访问冲突需要回滚.例如，TSN（T） = [2， 3， 1]表示在事务r之前存在2条单分区事务和1条跨分区事务，故事务r在冲突检测阶段便需要对比 冲突域中的所有事务写集合确定事务是否可以提交.

4.3基于时间顺序的事务执行示例

接下来通过图2示例说明具体的并发控制过程.图2中左侧表示事务时间线以及各事务访问的分区，右侧表示各分区上的事务执行情况以及每个事务的事务序号.按照时间线依次处理各事务有如下 过程.

由于事务 T1和事务 T2都是单分区事务，故二者被分配到相应分区八及怂上执行.本地乐观执 行完成后获取事务序号，以乃序号[2， 1， 0]为例，在此事务之前有0个本分区事务和0个跨分区事务， 没有日志空洞需要等待，可以直接提交;^同上所述，事务执行完成后将事务日志发送到及分区内 其他服务器回放.

事务巧为访问Pi和户3的跨分区事务，因此巧被分配到逻辑分区户0上执行，事务序号为[0， 0， 1]，表示其是第一个跨分区事务，逻辑分区通知相关单分区置M-TSN为1，同时单分区以本分区最新 事务序号为返回信息，即在一次消息传递后二^者都获得对方最新事务序号信息.r3本地乐观执行完成 后进入验证阶段，根据其他单分区传回的信息可知户1上最新事务序号为[0， 0， 0]，怂上最新事務序号 为[3， 1，0]，故需要等待事务序号为[3， 1，0]的事务日志到来后空洞被补全.在此空洞补全的过程中， 可并行检测在此事务冲突域是否存在数据访问冲突，若发现冲突可直接回滚而不需要等待空洞补全 结果;若冲突检测后发现乃与^冲突则需要回滚乃，并将事务无效标记转发至其他分区，无效标记 即代表此事务空洞不需要被回放.

八为访问^的单分区事务，获取事务序号[1，1，1]，M-TSN为1是由于跨分区事务乃的执行. 八本地乐观执行完成后需要等待跨分区事务[0， 0， 1]的日志或无效标记到来.r5分配至执行，同 上，验证阶段需等待事务序号为[2， 1，0]及[3， 1，0]事务日志到来.此时，虽然八还未执行完成，但是 由于访问数据不冲突，所以巧不需要等待八的事务日志到来.随后3个单分区事务r6、r7、巧分 配到各自分区执行，本地乐观执行完成后进入空洞补全和冲突检测阶段.

r9访问分区^和分区八，申请事务序号一次消息传递后，获得A及八分区上最新的事务序号， 分别为[1，1，1]和[2， 2， 2]. r9在本地乐观执行完毕后，检查空洞，发现事务r7的日志仍未到来，所以 需要继续等待空洞补全完成冲突检测.

5实 验

5.1实验环境

本文实验基于15台Linux服务器组成的集群环境，每台Linux服务器有相同的软件和硬件配置： Intel（R） Xeon（R） Silver 4110 CPU @ 2.10 GHz; 128 GB 内存;10 GB/s 以太网;CentOS Linux release 7.8.2003操作系统.为便于控制数据访问冲突率，实验选用短事务负载，每条事务仅包含1条更新 语句.

5.2系统吞吐量分析

第一组实验，集群中节点数量由单节点扩展至15个节点，由多个计算节点执行短事务负载，测试 本文分区方案对系统吞吐量的影响.实验分区算法处理后，将数据划分至3个分区，并通过短事务更 新语句控制事务访问的分区数量，对比在有跨分区事务负载与无跨分区事务负载下全局事务日志与 分区方案的扩展性.由于单节点情况下事务仅在单个计算节点执行，其中也并不涉及事务日志的传递， 故分区算法下节点数量从3个节点开始实验.全局事务日志方案下，单节点系统吞吐量可做线性扩展 的参考值.

5.2.1無跨分区事务负载

图3是不存在事务访问多个分区的情况下，即无跨分区事务负载下，全局事务日志与分区方案的 系统总吞吐量对比.图3中，横坐标表示集群中的节点数量;纵坐标表示系统总的吞吐量，用每秒传输 的事务数量（Transactions Per Second， TPS）表示（后续图4亦如此）.

从图3可以看出，集群节点数量不超过5个计算节点时，系统吞吐量在两种解决方案下并无太大 差异.但随着节点数量的增长，全局事务日志的解决方案下系统的吞吐量增长明显减缓，可以预见，随 着节点数量的进一步增长，系统吞吐量可能会到达“瓶颈而分区策略下，系统吞吐量随节点数量的 增长基本保持线性增长，随着节点数量的增长，二者差距越发明显.

5.2.2有跨分区事务负载

图4是存在少量事务访问多个分区的情况下，即有跨分区事务负载下，全局事务日志与分区方案 的系统总吞吐量对比.

从图4可以看出，集群数量不超过5个节点的情况下，两种解决方案下系统的吞吐量仍并无太大 差异.随着节点数量的增长，全局事务日志的解决方案下吞吐量增长依旧处于减缓趋势，分区算法下 系统的吞吐量表现较无跨分区事务而言，同全局事务日志方案的差距有所减小，但还是保持增长趋势.

5.3日志等待时延分析

从第一组实验可以看出，全局事务日志的方案在节点较多时系统性能有很大折损.第二组实验的 目的是探究产生这一现象的原因.

图5以全局事务日志与分区方案下无跨分区事务产生的场景做对比，从图中可以看出，随着节点 数量的增多，全局事务日志的方法下等待事务空洞补全的时延越来越大.究其原因，是因为全局事务 日志的解决方案下，每条事务的提交需要等待本地维护的全局事务日志空洞补全后才可能提交，而随 着节点数量增加，产生的全局日志规模急剧增长，事务需要等待的空洞规模也越来越大，故等待日志 传递的时延也在线性增长.而在分区场景下，每个分区维护有独立的日志记录和验证器，随着节点数 量的增多，虽然全局日志的规模也在急剧增长，但由于分区仅维护了部分仅属于此分区的事务日志， 所以其分区内事务日志空洞的规模增长并不随节点数量线性增长，故日志等待时延较全局事务日志 而言增长更为缓慢.

6结 语

在大数据时代，存储计算架构分离的单写多读场景已无法满足海量数据的高效读写需求.另一方 面，多个计算节点同时提供写服务会引起计算节点间的缓存不一致问题.针对全局事务日志回放的方 法，本文给出了基于数据访问图的分区方法，通过收集一批次的事务信息对数据进行动态分区，引入 逻辑分区处理跨分区事务，并在逻辑分区与物理单分区之间设计跨分区并发控制方法以维护数据一 致性.通过实验证明，较全局事务日志的方法，随着计算节点数量的增长，分区方法下的系统扩展性表 现更优.

[参考文献]

[1]HAYAT Z， SOOMRO T R. Implementation of oracle real application cluster [J]. Review of Computer Engineering Studies， 2016， 3（4）： 81-85.

[2]CHONG R F， LIU C. DB2 Essentials： Understanding DB2 in a Big Data World [M]. [S.l]： IBM Press， 2013.

[3]BERNSTEIN P A， REID C W， DAS S. Hyder - A transactional record manager for shared flash [C]// CIDR 2011， 5th Biennial Conference

on Innovative Data Systems Research. CIDR， 2011： 9-20.

[4]THOMSON A， DIAMOND T， WENG S C， et al. Calvin： Fast distributed transactions for partitioned database systems [C]// Proceedings of the 2012 ACM SIGMOD International Conference on Management of Data. ACM， 2012： 1-12.

[5]卫孝贤，刘文欣，蔡鹏.多主云数据库的全局事务日志[J].华东师范大学学报（自然科学版），2020（5）： 10-20.

[6 ] VERBITSKI A， GUPTA A， SAHA D， et al. Amazon aurora： Design considerations for high throughput cloud-native relational databases [C]// Proceedings of the 2017 ACM International Conference on Management of Data. ACM， 2017： 1041-1052.

[7 ] VERBITSKI A， GUPTA A， SAHA D， et al. Amazon aurora： On avoiding distributed consensus for I/Os， commits， and membership changes [C]// Proceedings of the 2018 International Conference on Management of Data. ACM， 2018： 789-796.

[8 ] CAO W， LIU Z J， WANG P， et al. PolarFS： An ultra-low latency and failure resilient distributed file system for shared storage cloud database [J]. Proceedings of the VLDB Endowment， 2018， 11（1（2）： 1849-1862.

[9 ] HUANG G， CHENG X T， WANG J Y， et al. X-engine： An optimized storage engine for large-scale E-commerce transaction Processing[C] // Proceedings of the 2019 International Conference on Management of Data. ACM， 2019： 651-665.

[10]ANTONOPOULOS P， BUDOVSKI A， DIACONU C， et al. Socrates： The new SQL server in the cloud [C]// Proceedings of the 2019 International Conference on Management of Data. ACM， 2019： 1743-1756.

[11]DEPOUTOVITCH A， CHEN C， CHEN J， et al. Taurus database： How to be fast， available， and frugal in the cloud [C]// Proceedings of the 2020 ACM SIGMOD International Conference on Management of Data. ACM， 2020： 1463-1478.

[12]BERNSTEIN P A， DAS S， DING B L， et al. Optimizing optimistic concurrency control for tree-structured， log-structured databases [C]// Proceedings of the 2015 ACM SIGMOD International Conference on Management of Data. ACM， 2015： 1295-1309.

[13]BERNSTEIN P A， DAS S. Scaling optimistic concurrency control by approximately partitioning the certifier and log [J]. IEEE Data Eng Bull， 2015， 38： 32-49.

（責任编辑：李艺）