3.3 典型的云原生数据库

3.3.1 AWS Aurora

Aurora ^[1][2] 是亚马逊云服务（Amazon Web Services，AWS）推出的云原生数据库服务，在MySQL的基础上实现了存储计算分离架构，主要面向联机事务处理（On-Line Transaction Processing，OLTP）场景，Aurora的整体架构如图3-2所示。Aurora基本设计理念是在云环境下，数据库的最大瓶颈不再是计算或者存储资源，而是网络，因此，Aurora基于一套存储计算分离架构，将日志处理下推到分布式存储层，通过架构上的优化来解决网络瓶颈。存储节点与数据库实例（计算节点）松耦合，并包含部分计算功能。Aurora体系下的数据库实例仍然包含了大部分核心功能，例如查询处理、事务、锁、缓存管理、访问接口和Undo日志管理等；但Redo日志相关的功能已经下推到存储层，包括日志处理、故障恢复和备份还原等。Aurora相对于传统数据库有三大优势，首先，底层数据库存储是一个分布式存储服务，可以轻松应对故障；其次，数据库实例在底层存储层只写Redo日志，因此数据库实例与存储节点之间的网络压力大大减小，这为提升数据库性能提供了保障；第三，将部分核心功能（故障恢复和备份还原）下推到存储层，这些任务可以在后台不间歇地异步执行，并且不影响前台用户任务。

1.传统数据库写放大问题

传统数据库存在严重的写放大问题，以单机MySQL为例，执行写操作会导致日志落盘，同时后台线程也会异步地将脏数据刷盘。另外，为了避免页断裂，进行刷脏页的过程还需要将数据页写入Double-Write区域。如果考虑生产环境中的主备复制，如图3-3所示，AZ（Availablity Zone）1和AZ 2分别部署一个MySQL实例做同步镜像复制，底层存储采用EBS（Amazon Elastic Block Store），并且每个EBS还有自己的一份镜像，另外部署S3（Amazon Simple Storage Service）进行Redo日志和Binlog日志归档，以支持基于时间点的恢复。从流程上来看，每个步骤都需要传递5种类型的元数据，包括Redo、Binlog、Data-Page、Double-Write和Frm。由于是基于镜像的同步复制，因此图中的步骤是①、③、⑤顺序执行的。这种模型的响应时间非常糟糕，因为要进行4次网络I/O，且其中3次是同步串行的。从存储角度来看，数据在EBS上存了4份，因此需要4份都写成功才能返回。所以在这种架构下，无论是I/O量还是串行化模型都会导致性能非常糟糕。

为了减少网络I/O，在Aurora中，所有的写类型只有一种，就是Redo日志，任何时候都不会写数据页。存储节点接收Redo日志，基于旧版本数据页回放日志，可以得到新版本的数据页。为了避免每次都从头开始回放数据页变更产生的Redo日志，存储节点会定期物化数据页版本。如图3-4所示，Aurora由跨AZ的一个主实例和多个副本实例组成，主实例与副本实例或存储节点间只传递Redo日志和元信息。主实例并发向6个存储节点和副本实例发送日志，当4/6的存储节点应答后，则认为日志已经持久化，对于副本实例，则不依赖其应答时间点。从Sysbench测试（100GB规模、只写场景、压力测试30分钟）的数据来看，Aurora是基于镜像的MySQL吞吐能力的35倍，每个事务的日志量比基于镜像的MySQL的日志量要少0.12%左右。在故障恢复速度方面，传统数据库宕机重启后，从最近的一个检查点开始恢复，读取检查点后的所有Redo日志并进行回放，确保已经提交的事务对应的数据页得到更新。在Aurora中，Redo日志相关的功能下推到存储层，回放日志的工作可以一直在后台做。对于任何一次磁盘I/O读操作，如果数据页不是最新版本，都会触发存储节点回放日志，得到新版本的数据页。因此类似于传统数据库的故障恢复操作实质在后台不断地进行，而真正进行故障恢复时，需要做的事情很少，所以故障恢复的速度非常快。

2.存储服务设计

Aurora存储服务设计的一个关键原则是减少前台用户写的响应时间，因此将尽可能多的操作移到后台异步执行，并且存储节点会根据前台的请求压力，自适应分配资源做不同的工作。例如，当前台请求很繁忙时，存储节点会减缓对旧版本数据页的回收。在传统数据库中，后台线程需要不断地推进检查点，避免故障恢复时间消耗的时间过长，因此会影响前台用户的请求处理能力；对于Aurora而言，分离的存储服务层使得后台线程推进检查点动作完全不影响数据库实例，并且推进得越快，越有利于前台的磁盘I/O读操作（减少了回放日志过程）。

为了保证数据库的可用性和正确性，Aurora存储层的复制基于Quorum协议。假设复制拓扑中有 V 个节点，每个节点有一个投票权，读或写必须拿到 V _r 或 V _w 个投票才能返回。为了满足一致性，需要满足两个条件，首先 V _r + V _w ＞ V ，这保证了每次读操作都能读到拥有最新数据的节点；第二， V _w ＞ V /2，每次写操作都要保证能获取到上次写的最新数据，避免写冲突。例如 V =3，那么为了满足上述两个条件， V _r =2， V _w =2。为了保证各种异常情况下的系统高可用，Aurora的数据库实例部署在3个不同的AZ上，每个AZ包含了2个副本，总共6个副本。每个AZ相当于一间机房，是一个独立的容错单元，包含独立的电源系统、网络和软件部署等。结合Quorum模型以及前面提到的两条规则， V =6， V _w =4， V _r =3，Aurora可以容忍任何一个AZ出现故障，不会影响写服务；任何一个AZ出现故障，或另外一个AZ中的一个节点出现故障，都不会影响读服务且不会丢失数据。

通过Quorum协议，Aurora可以保证只要AZ级别的故障（火灾、洪水和网络故障）和节点故障（磁盘故障、掉电和机器损坏）不同时发生，就不会破坏协议本身，数据库的可用性和正确性就能得到保证。如果想要数据库“永久可用”，则问题变成如何降低两类故障同时发生的概率。由于特定故障发生的频率（Mean Time To Fail，MTTF）是一定的，为了减少故障同时发生的概率，可以想办法提高故障的修复时间（Mean Time To Repair，MTTR）。Aurora将存储分片管理，每个分片10GB，6个10GB副本构成一个PGs（Protection Groups）。Aurora存储由若干PGs构成，这些PGs实际上是由EC2（Amazon Elastic Compute Cloud）服务器+本地SSD磁盘组成的存储节点构成的，目前Aurora最多支持64TB的存储空间。分片后，每个分片作为一个故障单位，在10Gb/s网络下，一个10GB的分片可以在10s内恢复。因此，当且仅当10s内2个以上分片同时出现故障时，才会影响数据库服务的可用性，实际上这种情况基本不会出现。通过分片管理，巧妙地提高了数据库服务的可用性。

Aurora写基于Quorum模型，存储分片后，按片达到多数派即可返回，由于分布足够离散，少数的磁盘I/O压力大也不会影响整体的写性能。如图3-5所示，图中详细介绍了主要的写流程：①存储节点接收数据库实例的日志，并追加到内存队列；②将日志在本地持久化成功后，给实例应答；③按分片归类日志，并确认丢失了哪些日志；④与其他存储节点交互，填充丢失的日志；⑤回放日志生成新的数据页；⑥周期性地备份数据页和日志到S3系统；⑦周期性地回收过期的数据页版本；⑧周期性地对数据页进行CRC校验。上述所有写相关的操作，只有第①和第②步是串行同步的，会直接影响前台请求的响应时间，其他操作都是异步的。

3.一致性原理

目前市面上几乎所有的数据库都采用预写日志（Write Ahead Logging，WAL）模型，任何数据页的变更，都需要先写修改数据页对应的Redo日志，Aurora基于MySQL改造当然也不例外。在实现中，每条Redo日志拥有一个全局唯一的日志序列号（Log Sequence Number，LSN）。为了保证多节点数据的一致性，Aurora并没有采用2PC协议，因为2PC对错误的容忍度太低，取而代之的是，基于Quorum协议来保证存储节点的一致性。由于在生产环境中，各个节点可能会缺少部分日志，各个存储节点利用Gossip协议补全本地的Redo日志。在正常情况下，数据库实例处于一致性状态，读取磁盘I/O时，只需要访问Redo日志全的存储节点即可；但在故障恢复过程中，需要基于Quorum协议进行读操作，重建数据库运行时的一致状态。在数据库实例中活跃着很多事务，事务的开始顺序与提交顺序也不尽相同。当数据库异常宕机重启时，数据库实例需要确定每个事务最终要提交还是回滚。为了保证数据的一致性，在Aurora中对存储服务层Redo日志定义了如下几个概念：

· 卷完整点（Volume Complete LSN，VCL）。表示存储服务拥有VCL之前的所有完整的日志。在故障恢复时，所有LSN大于VCL的日志都要被截断。

· 一致性点（Consistency Point LSNs，CPLs）。对于MySQL（InnoDB）而言，每个事务在物理上由多个Mini-Transaction组成，而每个Mini-Transaction是最小原子操作单位，例如B树分裂可能涉及多个数据页的修改，那么这些页修改对应的一组日志就是原子的，当重做日志时，也需要以Mini-Transaction为单位。CPL表示一组日志中最后一条日志的LSN，一个事务由多个CPL组成，所以称之为CPLs。

· 卷持久点（Volume Durable LSN，VDL）。表示所有CPLs中已持久化的最大LSN，VDL≤VCL，为了保证不破坏Mini-Transaction原子性，所有大于VDL的日志都需要被截断。例如，VCL是1007，假设CPLs是900、1000、1100，则VDL是1000，那么需要截断1000以后的日志。VDL表示了数据库处于一致状态的最新位点，在故障恢复时，数据库实例以PG为单位确认VDL，截断所有大于VDL的日志。

4.故障恢复

大多数数据库基于经典的ARIES协议处理故障恢复，通过WAL机制确保发生故障时已经提交的事务持久化，并回滚未提交的事务。这类系统通常会周期性地设置检查点，并将检查点信息计入日志。当发生故障时，数据页中可能同时包含了提交和未提交的数据，因此，在故障恢复时，系统首先需要从上一个检查点开始回放日志，将数据页恢复到发生故障时的状态，然后根据Undo日志回滚未提交事务。从故障恢复的过程来看，故障恢复是一个比较耗时的操作，并且与检查点操作频率强相关。通过提高检查点频率，可以减少故障恢复时间，但是这会直接影响系统处理前台请求，所以需要在检查点频率和故障恢复时间之间做一个权衡，而在Aurora中不需要做这种权衡。

在传统数据库中，故障恢复过程通过回放日志推进数据库状态，重做日志时整个数据库处于离线状态。Aurora也采用类似的方法，区别在于将回放日志逻辑下推到存储节点，并且在数据库在线提供服务时在后台常态运行。因此，当出现故障重启时，存储服务能快速恢复，即使在10万TPS的压力下，也能在10s内恢复。数据库实例宕机重启后，需要故障恢复来获得运行时的一致状态，实例与 V _r 个存储节点通信，这样能确保读到最新的数据，并重新计算新的VDL，超过VDL部分的日志都可以被截断丢弃。在Aurora中，对新分配的LSN范围做了限制，LSN与VDL差值的范围不能超过10000000，这主要是为了避免数据库实例上堆积过多的未提交事务；因为数据库回放完Redo日志后还需要做Undo恢复，将未提交的事务进行回滚。在Aurora中，收集完所有活跃事务后即可提供服务，整个Undo恢复过程可以在数据库Online后再进行。

3.3.2 PolarDB

PolarDB ^[3，4] 是阿里云自研的云原生数据库，完全兼容MySQL，采用计算存储分离架构，使用高性能网络远程直接数据存取（Remote Direct Memory Access，RDMA）构建分布式共享存储PolarStore，整体架构如图3-6所示。PolarDB采用了存储与计算分离的设计理念，满足公有云计算环境下用户业务弹性扩展的刚性需求。数据库计算节点和存储节点之间采用高速网络互联，并通过RDMA协议进行数据传输，使得I/O性能不再成为瓶颈。数据库节点采用和MySQL完全兼容的设计。主节点和只读节点之间采用Active-Active的失效转移（Failover）方式，提供数据库的高可用服务。数据库的数据文件、Redo日志等通过用户空间（User-Space）用户态文件系统，经过块设备数据管理路由，依靠高速网络和RDMA协议传输到远端的Chunk Server。同时数据库实例之间仅需同步Redo日志相关的元数据信息。Chunk Server的数据采用多副本确保数据的可靠性，并通过Parallel-Raft协议保证数据的一致性。

1.物理复制

MySQL Binlog记录了元组（Tuple）行级别的数据变更，而在InnoDB引擎层，为了支持事务ACID，也保留了一份Redo日志，存储基于文件物理页面的修改。

这样MySQL的一个事务处理默认至少需要调用两次Fsync()进行日志的持久化操作，这对事务处理的系统响应时间和吞吐性能造成了直接的影响。尽管MySQL采用了Group Commit的机制提升高并发下的吞吐量，但并不能完全消除I/O瓶颈。此外，由于单个数据库实例的计算和网络带宽有限，一种典型的做法是通过搭建多个只读实例分担读负载来实现水平扩展。PolarDB通过将数据库文件以及Redo日志等存放在共享存储设备上，非常讨巧地解决了只读节点和主节点的数据复制问题。由于数据共享，只读节点的增加无须再进行数据的完全复制，通过共用一份全量数据和Redo日志，只需要同步元数据信息，并支持基本的多版本并发控制（Multi-Version Concurrency Control，MVCC），从而保证数据读取的一致性即可。这使得系统在主节点发生故障进行故障转移（Failover）时，切换到只读节点的故障恢复时间能缩短到30s以内，系统的高可用能力得到进一步增强。而且只读节点和主节点之间的数据延迟也可以降低到毫秒级别。从并发的角度来看，目前使用Binlog复制只能按照表级别并行复制，而物理复制按照数据页维度进行复制，粒度更细，并行效率更高。通常，在不需要Binlog作为逻辑上的容灾备份或数据迁移的情况下，Binlog可以关闭。系统使用Redo日志来实现复制，以此减少对性能的影响。总之，在I/O路径中，通常越往底层，越容易和上层的业务逻辑以及状态解耦而降低系统复杂度。而且这种WRL大文件读写的I/O方式也非常适用于分布式文件系统的并发机制，为PolarDB带来并发读性能的提高。

2.高速网络下的RDMA协议

RDMA是在高性能计算（High Performance Computing，HPC）领域使用多年的技术手段，现在则被使用到云计算领域。RDMA通常需要支持高速网络连接的网络设备，如交换机、网络接口控制器（Network Interface Controller，NIC）等，通过特定的编程接口，和NIC Driver通信。并且通常以Zero-Copy的技术来达到数据在NIC和远端应用内存之间高效率低延迟的传递，而不用通过中断CPU的方式将数据从内核态拷贝到应用态，从而极大地降低了性能的抖动，提高了整体系统的处理能力。PolarDB中计算节点和存储节点之间采用高速网络互联，并通过RDMA协议传输数据，使得I/O性能不再成为瓶颈。

3.基于快照的物理备份

快照（Snapshot）是一种流行的基于存储块设备的备份方案，其本质是采用Copy-On-Write的机制，通过记录块设备的元数据变化，对于发生写操作的块设备进行写复制，将写操作内容改动到新复制出的块设备上，来实现恢复数据到快照时间点的目的。Snapshot是一个典型的基于时间以及写负载模型的后置处理机制。也就是说，在创建Snapshot时，并没有备份数据，而是把备份数据的负载均分到创建Snapshot之后实际写数据发生的时间窗口，以此实现备份、恢复的快速响应。PolarDB提供基于Snapshot以及Redo日志的机制，在按时间点恢复用户数据的功能上，比传统的全量数据结合Binlog增量数据的恢复方式更加高效。

4.用户态文件系统

谈到文件系统，就不得不提到IEEE发明的POSIX语义（POSIX.1已经被ISO所接受），就像说到数据库要谈到SQL标准。通用分布式文件系统实现的最大挑战是在完全兼容POSIX标准的基础上提供强劲的并发文件读写性能。可是POSIX的兼容势必会牺牲一部分性能来获得对标准的完全支持，同时系统实现的复杂度也极大地增加。这既是通用设计和专有设计的取舍和区别，也是易用性和性能之间的平衡。

分布式文件系统是IT行业经久不衰的技术，从HPC时代、云计算时代、互联网时代到大数据时代，一直在推陈出新，严格来说应该是针对不同应用I/O场景涌现出很多定制化的实现。

不过当只服务于专门的I/O场景时，不适用POSIX也不是什么问题。这一点，和从SQL到NoSQL的发展如出一辙。支持POSIX的文件系统，需要实现兼容标准文件读写操作的系统调用接口，这样对于用户而言，就无须修改POSIX接口以实现文件操作应用程序。这样一来就要求通过Linux VFS层铆接具体的文件系统内核实现。这也是导致文件系统工程实现难度加大的原因之一。

对于分布式文件系统而言，内核模块还必须和用户态的Daemon进行数据交换，以达到数据分片以及通过Daemon进程传送到其他机器上的目的。而User-Space文件系统提供用户使用的专用应用程序接口（Application Programming Interface，API），不用完全兼容POSIX标准，也无须在操作系统内核进行系统调用的1:1映射对接，直接在用户态实现文件系统的元数据管理和数据读写访问支持即可，实现难度大大降低，并且更加有利于分布式系统的进程间通信。

3.3.3 Microsoft Socrates

Socrates ^[5] 是一种数据库即服务（DataBase-as-a-Service，DBaaS）模式的新型云上OLTP数据库，已用于微软SQL Server中。Socrates同样采用了存储计算分离的思想，并且将日志的存储从整体存储层（日志+数据页）分离出来，单独作为一级的存储模块。传统数据库通常是维护数据的多个副本，将持久性和高可用耦合在一起，而两者依赖的必要条件并不完全重合。对于持久化来讲，日志需要写入固定副本数事务才可以提交，而数据页快速复制和恢复使系统能够在故障出现时提供良好的服务质量，从而保证系统较高的可用性。Socrates将日志和数据页分开存储意味着将数据库的持久性实现（由日志实现）和可用性（由数据页和计算层实现）进行解耦，解耦后有利于数据库使用最合适的机制处理任务。从整体上来看，Socrates的架构如图3-7所示，由四层组成：分别为计算层、XLOG日志服务层、Page Server存储层和XStore存储层。

1.计算层

与PolarDB类似，Socrates目前是一写多读的架构，在计算层只有一个节点能够处理所有的读写事务，但允许多个只读节点处理只读事务。在主节点出现故障时，可以随时从只读节点列表中选择一个节点作为主节点（支持读写）。Socrates中主节点无须知道其他节点以及日志的存储位置，只需处理读写事务以及生成日志记录。由于主节点只将较热的那部分数据放入内存和SSD（RBPEX）中，因此需要通过GetPage＠LSN机制检索没有被缓存到本地的数据页。GetPage＠LSN机制是一个远程过程调用（Remote Procedure Call，RPC）机制，向Page Server发送GetPage（pageId，LSN）请求，其中pageId唯一地标识主节点需要读取的页，LSN标识一个Page的日志序列号，值与页面的最大LSN相同。同样地，只读节点也使用GetPage＠LSN机制来获取没有被缓存到本地的数据页。特别的是，Socrates中主节点与只读节点之间没有交互，所有的日志由主节点发送给XLog Service后，再由XLog Service通过广播的形式分发给各个只读节点，每个只读节点收到日志后进行回放。由于只读节点并没有保存数据库完整的备份，可能会处理到不在它自己Buffer中的与Page相关联的日志记录（不在Memory和SSD中）。针对这种场景，目前有两种不同的处理策略：一种是从Page Server中获取Page并且回放日志，在这种方式下，只读节点和主节点之间的缓存数据大致保持一致，当主节点出现故障后，只读节点能够平滑地切换成主节点，性能更加稳定；另外一种策略是忽略涉及未缓存页面的日志记录。Socrates当前采用的正是第二种策略。

2.XLOG日志服务层

图3-8展示了XLOG Service的内部结构。日志块从主节点同步写入LZ（Landing Zone）。当前版本的Socrates使用Azure的高级存储服务（XIO）作为LZ的存储载体，为了保证持久性，XIO保留所有数据的三个副本。主节点还将日志异步地传送到XLOG Process，此进程进一步将日志发送到只读节点和Page Servers。在将日志块并行地发送到LZ和XLOG Process时，数据有可能在LZ持久化之前就到达只读节点，从而在发生故障时产生数据不一致或丢失的现象。为了避免这种情况，XLOG只传播已经在LZ中持久化的日志。XLog Process首先将日志存放在Pending Blocks中，同时主节点会通知哪些日志块已经被持久化，XLog Process会将已经持久化的日志块从Pending Blocks移动到LogBroker用于向只读节点和Page Serves广播分发。在XLOG Process内部还有一个Destaging进程，该进程会将已经持久化的日志块复制到固定大小的本地SSD缓存以实现快速访问，并且还会复制一份到XStore进行长期归档保留，Socrates将日志块的这种长期存档称为Long-Term Achieve（LT）。在Socrates中，LZ和LT保留了所有的日志数据，从而达到了数据库持久性的要求。LZ是一种低延迟、昂贵的服务，有利于快速提交事务，通常只保留30天的日志记录，用于指定时间点的恢复。XStore（LT）采用廉价存储，价格便宜、耐用，但速度慢，适用于存储海量数据，这种分层存储结构满足了性能的需要和成本的要求。

3.Pages Servers存储层

Page Servers主要负责三方面内容：①响应来自计算节点的GetPage请求；②通过回放日志维护数据库分区数据；③记录检查点并向XStore备份。每个Page Server只存储了数据库的数据页面，在回放日志时，Page Server只需要关心对应分区相关的日志块。为此，主节点为每个日志块增加充分的注释信息，标明日志块中的日志记录需要应用到哪些分区中，XLOG利用这些过滤信息将相关的日志块分发到对应的Page Server中。在Socrates中可以使用两种方法添加Page Server的个数来提高系统的可用性。一种是使用更加细粒度的Sharding策略，这样由于每个Page Server对应的分区较小，因此分区平均恢复时间也较小，可用性得到提高。根据现今的网络和硬件参数，Socrates计算出Page Server较好的分区大小为128GB。另一种方式是为现有的Page Server添加一个备份的Page Server。当Page Server出现故障时，备份的Page Server能够立即提供服务，可用性得到提高。

4.XStore存储层

XStore是一个基于硬盘、跨可用性区域的高度复制的存储系统，数据很少丢失，保证了数据持久性。在Socrates架构中，XStore扮演了传统数据中磁盘存储一样的角色，而计算节点和Page Server的内存和SSD缓存（Resilient Buffer Pool Extension，RBPEX）承担了传统数据库主存储的角色。Page Server会定期地将修改的数据页发送到XStore中，Socrates利用XStore的快照特性能够通过简单地记录一个时间戳创建备份。当用户请求某个时间点还原操作（Point-In-Time Recovery，PITR）时，Socrates需要从XSTore中获取在PITR之前的完整快照，以及这组快照从其还原时间到请求的时间所需的日志范围。

Socrates将整个数据库分成多个服务层，每个服务层都有自己的生命周期，并且在通信上尽可能异步。与其他云原生数据库不同的是它将持久性和可用性分开，其中XLog和XStore保证了系统的持久性，计算层和Page Servers保证了系统的可用性。在Socrates中，计算层和Page Servers是无状态的，这意味着即使它们的节点出现故障，也不会影响数据的完整性，任何Page Server的数据都可以由XStore/XLog上的快照版本和日志恢复到最新状态。这种分层存储架构能够提供更灵活和更细粒度的控制，让系统能够在可用性、成本和性能等方面做出更多的权衡。

参考文献

[1]VERBITSKI A, GUPTA A, SAHA D, et al. Amazon Aurora: Design Considerations for High Throughput Cloud-Native Relational Databases.In Proceedings of the 2017 ACM International Conference on Management of Data (SIGMOD'17), 2017: 1041–1052.https: //doi.org/10.1145/3035918.3056101.

[2]VERBITSKI A, GUPTA A, SAHA D, et al. Amazon Aurora: On Avoiding Distributed Consensus for I/Os, Commits, and Membership Changes.In Proceedings of the 2018 ACM International Conference on Management of Data (SIGMOD'18), 2018: 8.pages.https: //doi.org/10.1145/3183713.3196937.

[3]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.In Proceedings of the VLDB Endow, 2018: 1849–1862.https: //doi.org/10.14778/3229863.3229872.

[4]LI F F.Cloud-Native Database Systems at Alibaba:Opportunities and Challenges.PVLDB, 2019, 12(12):2263–2272.https://doi.org/10.14778/3352063.3352141.

[5]ANTONOPOULOS P, BUDOVSKI A, DIACONU C, et al. Socrates: The New SQL Server in the Cloud.In Proceedings of the 2019 ACM International Conference on Management of Data (SIGMOD'19), 2019: 14.https: //doi.org/10.1145/3299869.3314047. dfWJ/LVjo54Jw7VVgfqIdSRSnMHJuBz6CSLa+2Q4gWRJ0pS2hWX54LfRIqk7whSy