云数据库AWS Aurora最详解读！

《云数据库AWS Aurora最详解读！》要点：
本文介绍了云数据库AWS Aurora最详解读！，希望对您有用。如果有疑问，可以联系我们。

作者介绍

朱阅岸,中国人民大学博士,现供职于腾讯云数据库团队.研究方向主要为数据库系统理论与实现、新硬件平台下的数据库系统以及TP+AP型混合系统.

Aurora作为AWS云上的关系数据库,完美契合了企业级数据库系统对高可用性、性能和扩展性、云服务托管的需求.在本月中旬刚刚结束的AWS re:Invent 2017大会与数据库顶级会议SIGMOD上,Amazon首度公开了Aurora的技术细节,本文系作者结合自身理解写作而成,权当抛砖引玉.

Aurora是Amazon为云计算而专门定制的一款关系型数据库.其目标主要是最小化网络IO,提升系统的可扩展性与可用性.Aurora的设计哲学是log?is?database,对数据的更改只写日志,也即write-once.Aurora系统设计人员认为传统的数据库不论如何扩展都在复制整个系统栈,在不同的层面做耦合；为了更好地适应云计算,他们认为应该将数据库系统这个“盒子”打开,在不同的层面进行扩展.Aurora将恢复子系统委托给底层可靠的存储系统,依赖这个来保障系统服务层级(Service?Level?Agreement,?SLA).

针对Amazon云生态环境做了相应优化以后,在某些工作负载下,Aurora的性能可以比MySQL5.7高出10倍以上.下面我们从不同方面深入解读Aurora的设计理念.

一、前言

关系数据库系统中,处理事务的过程通常被视为一种分层的行为.系统在顶层对SQL语句进行解析,然后将得到的语法树传递给查询优化器层.查询优化器利用启发式规则和统计信息为每个关系操作符选取最优的策略.这个阶段产生的物理执行计划与逻辑存储层交互,完成相应的操作.

在本文中,将事务处理引擎简化为两层模型：查询解析、查询执行以及查询优化视为查询处理引擎(Process Engine,PE)；逻辑层存储和物理层存储统称存储引擎(Storage Engine,SE).这对应MySQL可插拔存储的两层架构.

定义数据库服务器集群的架构决策的关键点在于集群共享发生的程度,它定义协调动作发生在什么层以及哪个层(PE和SE)将被复制或者共享.这不仅确定了系统在可扩展性和灵活性上的权衡,而且关系到每一种架构在现成的数据库服务器上的适用性.以下是四个具有代表性的架构：

图1. 不同的数据库系统架构

• Shared Disk Failover (SDF)?

集群管理软件确保DBMS服务器只在连接到共享磁盘上的一个节点上运行,节点之间通常使用存储区域网络(SAN)互联.如果当前活动节点崩溃,强制卸载该服务,并在不同的节点上启动服务器.标准日志恢复过程可确保在磁盘上的数据的一致性,因此SDF适用任何DBMS.这种方法的一个变体可以在没有物理共享磁盘的情况下通过使用诸如DRBD的卷复制器达到相同效果.否则,磁盘冗余由RAID配置提供.

这种架构专门为解决服务器崩溃问题而设计,它通常部署在一个简单的两服务器配置.如在图1(b)所示,协调仅发生在DBMS外部,确保仅有一个服务器加载共享卷.如果文件安装在多个节点上,它甚至不能分发只读负载到备用节点,因为缓存一致性的问题会出现.由于复制是在裸盘上执行,在面对更新的时候,无论是PE或SE都不需要被复制,该架构在系统崩溃的时候会导致短暂的不可用情况发生.

• Shared Disk Parallel (SDP)

允许多个节点同时访问共享存储需要保证缓存一致.具体地说,每个数据块的所有权随着时间的变化而不同,特别是当集群应用触发一个写操作.分布式并发控制机制负责将页面所有权移交到对应实例.在这过程中,即使页面变脏,也无需进行I/O操作.读操作是共享操作,每当应用发送读请求,数据页的所有者复制该页面.任何时候数据块的写回操作仅由一个副本进行.

如在图1(c)所示,协调动作在存储引擎层内进行.这种体系结构的一个例子是Oracle的RAC,这是基于Oracle并行服务器(OPS)和Cache Fusion技术.

这种架构主要是针对服务器可用的CPU和内存带宽上进行扩展.它提供与SDF等同的容错能力,因为大多数服务堆栈在面对更新事务的时候仍然没有被复制.

• Shared Nothing Active(SNA)

通过完全隔离后端服务器,中间件层拦截所有客户机请求并将其转发到独立副本.因为只读请求在可用节点之间得到平衡从而达到系统可扩展.因此,只有更新事务需要积极地在所有副本进行复制.控制器扮演包装器的角色.对于请求者而言,它充当服务器,提供相同的客户端接口.对于原始的服务器而言,该中间层作为客户端.群集节点之间没有直接的沟通,因为协调发生在服务器之外,如图1(d)所示.一个流行的实现是由Sequoia提供的,之前叫做C-JDBC,可以移植到多种后端服务器.

可扩展性上的主要缺点就是更新语句必须是完全确定的,并且需要小心调度以避免冲突从而导致非确定的执行结果和数据库不一致. 实际上,这通常意味着不允许并发执行更新事务.这个架构的目标主要还是增强服务器在面对大多以读为主的工作负载能力.通过完全隔离后端服务器,在处理更新事务的时候,它在所有数据库系统的软件层重复执行,从而容许PE和SE的故障情况.事实上,可移植的实现,例如Sequoia,甚至支持多样的DBMS.它甚至可以在崩溃的状态上进行投票,以掩盖错误的备份.

• Shared Nothing Certification-Based (SNCB)

在无共享集群,可以使用基于认证协议避免主动复制更新事务.每个事务直接在副本上执行,而没有任何先验协调.因此,事务仅需要根据本地的并发控制协议在本地进行同步.仅在提交之前,协调的过程才开始.这个时候,发起协调的副本采用全序组通信原语广播更新.这将导致所有节点采用完全相同的更新序列,然后通过测试可能的冲突获取认证.PostgreSQL-R,Group Replication,Garela等属于这类架构的范畴.由于协调发生在PE与SE之间如图1(e),它能够随着更新密集型工作负载的扩展而执行更细粒度的同步.这方法能够接受存储引擎和磁盘层的物理损坏.

Aurora给人眼前一亮的是它的架构.其体系架构更类似SDP,但是它将更新局限在一个DB服务器上,避免了分布式并发控制协议.Aurora设计者们认为,传统的数据库实现可扩展不管是做Sharding、还是分布式、或者共享存储(Oracle RAC),本质上都是在数据库的不同层面耦合(SNA在应用层,分布式是在SQL层,SDP是在缓存层),扩展后的每个实例的程序栈仍然是原来的多层结构.Aurora认为从成本、部署灵活性及可用性等因素考虑,应该考虑把数据库的各层打开,然后在每个层单独做扩展.传统的数据库系统,例如MySQL、PostgreSQL以及Oracle,将所有的功能模块封装成一个整体,而Aurora则是将数据库的缓冲区管理、恢复子系统从这个整体剥离出来,单独定制扩展.

Amazon声称Aurora完全兼容MySQL,具备商业数据库的性能与稳定以及开源项目的低成本和易用性.下面详细介绍Aurora的设计理念.

二、Aurora系统设计

相比传统的数据库系统架构,Aurora具有以下三个明显的优点.

（编辑：ASP站长网）