He3DB论文解读：Amazon Aurora_ Design Considerations for High Throughput Cloud-Native Relational Database_aurora log database

He3DB 是由移动云数据库团队研发的一款计算/存储分离的云原生数据库，He3DB通过计算/存储分离、数据冷热分层和压缩、智能中间件等技术，来保证高性能和低成本完美兼得，在获得高性能的同时，最大化的帮助客户节省数据库使用成本。
Amazon Aurora是由亚马逊网络服务（AWS）提供的一种关系型数据库管理系统（RDBMS）。通过优化的存储和复制体系结构提供高性能、高可用性和可扩展性。它是一个云原生数据库，专为云环境而设计，并在可用性、性能和容量方面比传统数据库更具弹性。毫不夸张的说，当前云原生数据库圈的繁荣离不开Amazon在2017届SIGMOD 会议上发表的Amazon Aurora系统解密论文《Amazon Aurora: Design Considerations for High Throughput Cloud-Native Relational Database》，下面我们一起来揭开云原生数据库的神秘面纱！

架构概览

Amazon Aurora对传统关系数据库架构进行了重塑与解耦，以一次IO为例，Amazon Aurora将传统的IO同步路径，分解成8个异步路径，并且只有step1和step2在前端的响应延迟路径上，这种架构极大提升了性能，Amazon Aurora（MySQL版本）相较于MySQL有5倍的性能提升，Amazon Aurora（PostgreSQL版本）相较于PostgreSQL有3倍的性能提升。
IO流解读

1. 主实例提交日志到存储节点的内存队列
2. 进行日志持久化，并且进行客户端确认操作（至此对客户端而言写入结束）
3. 对日志进行排序，并标记出日志中的空洞
4. 存储节点间进行Gossip协议通信，将日志中的空洞数据进行补充
5. 对日志进行回返，合并到新的数据块版本中
6. 周期性的将日志和新版本数据块同步到S3
7. 周期性的对旧版本数据页进行垃圾回收
8. 周期性的进行数据页CRC校验

下面我们来深入解析一下Aurora核心组件和技术设计

the log is the database

“the log is the database” 是 Aurora的一种独特的数据库设计理念，它强调了事务日志（redo log）在数据库系统中的关键作用。在传统数据库系统中，事务日志主要用于记录对数据库的写操作，以便在发生崩溃或故障时进行数据恢复。然而，在Aurora中，这一理念被进一步扩展和优化，将事务日志的作用提升到了更高的层次。

在Aurora中只有主节点可以接收写请求，执行数据写入动作，并同步日志到备节点。相较于传统数据库，Aurora主节点只会向存储层写入redo日志数据，不会向存储层写入数据块，主备之间的日志同步不再是完整的redo日志数据，只是redo日志元数据，能够满足备节点根据这些元数据构建出完整的数据块-redo日志间的链表关系即可，由于存储引擎是共享的，所以备节点在需要的时候可以根据数据块-redo日志间的链表关系从存储引擎中读取对应的完整日志数据。
通过以上两点的改变，计算引擎的写入性能得到了极大的提升，主备之间的延迟得到了极大的降低。

多副本

计算存储解耦之后，存储节点和磁盘也可能会发生故障。因此，必须通过某种方式将其进行复制以提供故障恢复能力。Aurora使用基于 Quorum 的投票协议是复制系统中应对故障的一种方法。如果V个数据副本中每个副本一票，那么一次读操作或是一次写操作必须分别获得Vr​票（读 Quorum）或Vw​票（写 Quorum ）。为了满足一致性，Quorum 必须遵守两个规则：
1）每次读操作必须感知到最近的写入，公式表示为Vr​+Vw​>V。这个规则确保用于读取的节点集合和用于写入的节点集合相交，并且Vr​中至少存在一个具有最新版本的节点。
2）每次写操作必须感知到最近的写入，以避免写冲突，公式表示为Vw > V/2。

在 Aurora 中，考虑了多AZ的需求对存储引擎进行了如下设计：
(a) 允许整个 AZ 和一个附加节点（AZ+1）发生故障而不丢失数据
(b) 允许整个 AZ 故障不影响写数据。
通过将每份数据拷贝 6 份，放在 3 个可用区中，每个可用区保存 2 份拷贝，从而实现了上述目标。使用的 Quorum 模型为V=6，Vw​=4（写 Quorum）， Vr​=3（读 Quorum）。
通过该模型，可以实现在损失一个 AZ 和一个附加节点（总计 3 个故障节点）而不失去读可用性，并且在失去任意两个节点或者一整个 AZ 还能保持写可用性。

日志处理服务

在Aurora中数据块版本推进是由日志处理服务负责完成的，主实例只需要将WAL数据流写入存储引擎就可以了，数据文件的变更是完全依靠日志文件回放来实现。这个过程是独立且异步的。除了通过回放日志来推进数据块版本之外，日志处理服务还会周期性的将日志和新版本数据块同步到S3、对旧版本数据页进行垃圾回收、进行数据页CRC校验工作。

读一致性

在Aurora中会全局维护一个致性位点read-point，代表着redo日志的最新落盘位置。数据库实例向存储节点传递redo日志，达成多数派后将事务标记为提交状态，然后推进read-point。由于备机只能保证做到构建数据块-redo日志间的链表关系的实时性，难以保证回放数据页的实时性。并且日志处理服务推进数据页版本也会有一定的延迟，所以如果想要读到read-point版本的数据页就需要使用session日志延迟回放技术。session日志延迟回放技术是指在seesion中根据数据块-redo日志间的链表关系向存储引擎读取对呀的老版本数据块和对应的增量redo日志，然后在seesion中进行回放操作，并将回放结果进行客户端返回或者进行进一步处理。

以上就是Amazon Aurora的主要技术特征，相较于传统数据库架构，Aurora的架构创新性非常强，"the log is the database"的理念非常新颖，并且也给出了详细的技术实现。