Amazon Aurora: Design for HighThroughput Cloud-Native Relational Databases.
输入“/”快速插入
Amazon Aurora: Design for HighThroughput Cloud-Native Relational Databases.
1.
Abstract
Aurora 是一个为OLTP场景服务的关系型数据库，
Aurora团队在这篇技术报告中主要介绍了 Aurora的架构以及设计这种架构的初衷；作者团队认为目前大数据处理的瓶颈已经从计算、存储转移到了网络，High-Level Idea of Aurora是它将重试的逻辑放到了可以横向扩展的 Multi-Tenant 层，不但减少了网络开销，而且有利于快速的故障恢复。
除了高可用外，本文还介绍了Aurora是如何基于Async 同步机制达成集群内的共识的，使用异步同步的方式能避免繁琐的通信开销和Recover机制。
🎹
Aurora 是一种Shared-Storage 架构，它的存储层挂载的是一个分布式文件系统，有自己独享的CPU 和 Memory；与此对应的是以Spanner为代表的Shard-Nothing架构，Spanner的 每一个节点都能够独立的存储数据，独占自己的 Disk / CPU / Memory。
在云原生的架构中，得益于：计算和存储分离的数据库架构，DiskIO不会再成为性能的瓶颈，因为现在DiskIO是可以在多个节点上并行的。但是数据库的写并行之后，就会造成带宽的增加，所以在云原生的架构中，带宽替代diskIO成为了数据库性能的瓶颈。
计算和存储分离：
计算部分包括：Query Processor, Transactions, Locking, Buffer Cache, Access Methods 以及 Undo Management。
存储部分包括：Redo Logging, Durable Storage, Crash Recovery, BackUp.
计算 / 存储分离带来的好处是：
•
存储层独立作为一个跨机房自适应的容错系统，能够有效地防止自然灾害和机器的宕机造成服务不可用。
•
通过把Redo Log作为数据发送到存储层，极大减少了Page File在网络链路上的开销。事务，锁，Undo Management都在计算层解决。
•
把一些计算密集型的操作，比如备份和故障恢复，从DB Engine （计算层）下沉到了存储层，解放引擎的能力，使其负责更加核心的解析工作。
2.
Durability at Scale
2.1 Replication and Correlated Failures
Instance 和 Storage 解耦带来的好处是，它们可以独立的工作，独立的扩展；比如：与用户交互的Instance 宕机了，用户可以直接切换一个Instance继续与数据库保持通信 (Instance 是 Stateless的)；又比如如果Storage Service 宕机了，Instance通过服务发现能迅速找到一个BackUP保持存储服务可用。
Quorum：Aurora的分布式共识算法建立在Dynamo的基础之上，使用RW Quorum的形式来完成分布式节点的数据库同步。
AZ (Availability Zone)：表示一个 Sub Region，一个AZ中的节点通信延迟极小，AZ之间的资源相互隔离，是一种异地容灾的结构。
如果使用 2/3 Quorum 模型，每一个Node部署在一个AZ中，如果有AZ C因为自然灾害损毁，此时AZ B中的一台机器failover，就会造成整个DB系统的不可用。因此：2/3 Quorum没有完全地做到资源的隔离。
在Aurora中，每一个AZ中都会有两台节点，使用的是 (N=6, W=4, R=3) 的Quorum模型。这种模型带来的可用性提升表现为：系统能够容忍 (a) 一个AZ failover + 任意一台机器同时 failover的时候保证读可用 (AZ + 1)；(b) 一个AZ failover 或者 两台任意机器failover的时候保证写可用。
有点像 Redis 的Alchemy 架构。
2.2 Segment Storage
数据分片：Partition
为了保证高可用，Aurora 提出的目标是让修复的时间尽可能短于发生故障的时间频率。一种做法是将数据以PG的方式进行存储，也就是进行数据分片，一个PG内包含6个10GB的数据。PG是分散到三个不同的AZ上的，所以出现故障以及修复都是以PG为单位，观测显示：10GB的Segments能在10Gbps的网络上，使用小于10s的时间被修复。
PG Protection Group：把整个数据集分为若干个固定大小的Segment，每一个存储单元上保存若干个Segment；物理上使用 EC2 (Elastic Compute Cloud)来存储 （大量挂在虚拟机上的存储节点）。
2.3 Operational Advantages of Resilience
PG存在的意义是保证：故障之后能够快速的恢复。有了对于AZ 和 Node的容错性之后，可以用来做一些对于提升系统 Maintainability 有帮助的事情：
•
Heat Management: 当一个Node被检测为 HotSpot之后，可以手动将其标记为 Bad Node，即手动failover，让它上面的Segment分散到其他的Cold节点上。
•
SoftWare Upgrade：在软件系统升级的时候，可以每次升级一台 Node 或者 一个AZ，确保不会有超过一个PG同时在进行升级。
3.
The Log is the DataBase
3.1 The burden of Amplified Write (写增强的代价)
Amazon 认为如果直接把数据分片的操作应用到MySQL这样的传统数据库中是无法减少 Network IO的。首先 MySQL在写数据的时候会先写 WAL Log 然后写 Page File， 除此之外还需要：元信息，Binlog和 Double Write Data（存放在Buffer中用来防止 Torn Page的数据）。
在主从架构模式中，1,3,5 三个步骤是串行的，Replica 会导致卡主的问题，并且整个网络链路上需要传输大量的数据。