跳转至

Aurora:如何设计云原生关系数据库

关系数据库已经存在很长时间了,关系模型是 E.F. Codd 在 70 年代提出。支撑当今主要关系数据库管理系统的核心技术是在 1980-1990 年代开发的。关系数据库的基础,包括数据关系、事务 ACID 和 SQL 查询语言,经受住了时间的考验。这些基本特性使关系数据库在世界各地的用户中非常受欢迎。它们仍然是许多公司 IT 基础架构的基石。

当然,这并不是说系统管理员必然会喜欢处理关系数据库。几十年来,管理关系数据库一直是一项高技能、劳动密集型的任务。这是一项需要专门系统和数据库管理员全神贯注完成的任务。在保证容错性、性能和故障影响范围的同时,扩展 关系数据库一直是管理员面临的一个挑战。

同时,现代互联网工作负载的要求也越来越高,需要基础设施具有几个基本特性: 1. 用户希望从较小的规模开始,然后在不受基础设施限制的情况下能够大规模扩展。 2. 在大型系统中,故障是一种常态,而非例外。客户工作负载必须与组件故障或系统故障隔离。 3. 影响范围小。没有人希望单个系统故障对他们的业务产生很大影响。

这些都是很困难的问题,解决这些问题需要摆脱老式的关系数据库体系结构。当 Amazon 面临像 Oracle 这样的老式关系数据库的局限性时,我们创建了一个现代的关系数据库服务Amazon Aurora。

Aurora 的设计保留了关系数据库的核心事务一致性优势。它在存储层进行创新,创建一个为云构建的数据库,该数据库可以支持现代工作负载,而不会牺牲性能。客户喜欢这一点,因为 Aurora 以十分之一的成本提供商业级数据库的性能和可用性。自 Aurora 最初发布以来,它一直是 AWS 上增长最快的服务。

在这篇文章中,我想让你看看我们是如何构建 Aurora 的。我还将讨论为什么客户采用它的速度比 AWS 上任何其他服务都快。

数据库的重新构想

老式关系数据库体系结构: database architecture

在过去的30-40年中,这种单一的关系数据库栈没有发生太大的变化。尽管存在用于扩展数据库的不同传统方法(例如,分片、无共享或共享磁盘),但所有这些方法都共享相同的基本数据库体系结构。它们都不能解决大规模的性能、弹性和故障范围的问题,因为紧密耦合的单体基本约束仍然存在。

为了解决关系数据库的局限性,我们通过将系统分解为基本的构建块来重新定义栈。我们认识到对 缓存和日志记录层 创新时机已经成熟。我们可以将这些层移动到专门构建的、可扩展、可自我修复、多租户,以及对数据库专门优化的存储服务中。当我们开始构建分布式存储系统时,Amazon Aurora 诞生了。

卸载REDO日志:日志即数据库

传统的关系数据库在页面中组织数据,当页面被修改时,它们必须定期刷新到磁盘。为了在故障时维护 ACID 语义,页面修改也记录在 REDO 日志记录中,REDO 日志记录以连续流的形式写入磁盘。虽然这种体系结构提供了支持关系数据库管理系统所需的基本功能,但它存在效率低下的问题。例如,一个逻辑写入会变成多个(最多五个)物理磁盘写入,从而导致性能问题。

数据库管理员试图通过减少页面刷新频率来解决写放大问题。这反过来又恶化了崩溃恢复持续时间的问题。刷新间隔越长,意味着用于重建正确页面从磁盘读取的 REDO 日志记录越多。这会导致恢复较慢。

在 Amazon Aurora 中,日志即数据库。数据库实例将 REDO 日志记录写入分布式存储层,存储层根据需要从日志记录构建页面。数据库实例从不需要刷脏页,因为存储层总是知道页面内容。这提高了数据库的性能和可靠性。由于消除了写放大,并且使用了可扩展的存储集群,写性能大大提高。

例如,与运行在类似硬件上的 Amazon RDS for MySQL 相比,Amazon Aurora MySQL 兼容版在 sysbench 基准测试中显示了5倍的写入 IOPS。数据库崩溃恢复时间大大缩短,因为数据库实例不再需要执行 REDO 日志回放。存储层负责 REDO 日志在读取时的页面生成,从而使新的存储服务不受传统数据库体系结构的约束,因此可以进一步进行创新。

基于单元的架构

正如我之前所说,一切都会出现故障。在大型系统中,组件会发生故障,并且经常发生故障,整个实例出现故障,网络故障可以隔离大量基础设施。更不常见的是,由于自然灾害,整个数据中心可能会变得孤立或瘫痪。在 AWS,我们处理故障,并且在问题发生之前依靠基于单元的体系结构来解决问题。

AWS 有多个地理区域(20个),在每个区域内,我们有多个可用区。利用多个区和区域,设计良好的服务可以在不影响服务可用性的情况下,在组件故障和更大的灾难中生存下来。Amazon Aurora 将所有写操作复制到三个区域,以提供更好的数据持久性和可用性。事实上,Aurora 可以在放弃数据可用性的情况下容忍整个区域的失败,并且可以从较大的故障中快速恢复。

cell-based architecture

然而,众所周知,复制是资源密集型的,那么,是什么使得 Aurora 能够在提供高性能的同时提供强大的数据复制呢?答案在于仲裁。

仲裁之美

一切都会出现故障。系统越大,出现故障的可能性就越大:网络链路、SSD、整个实例或软件组件。即使软件组件没有bug,它仍然需要定期重启进行升级。

传统的方法是阻塞 I/O,直到故障转移,并且在出现故障组件时以“降级模式”运行,这种方法在规模较大时存在问题。应用程序通常不能很好地容忍 I/O 中断。通过中等复杂的数学计算,可以证明,在大型系统中,随着系统规模的增大,降级模式下运行的概率接近1。然后,有一个真正令人讨厌的“灰色故障”问题,当组件没有完全失效,而是变慢时,就会出现这种问题。如果系统设计没有预见到这种降级,慢的组件会拖累整个系统的性能。

Amazon Aurora 使用仲裁来解决组件故障和性能下降的问题。写仲裁的基本思想很简单:写入尽可能多的副本,以确保仲裁读取总是找到最新的数据。最基本的仲裁示例是“三取二”:

V_w+V_r > V
V_w > V / 2
V=3
V_w=V_r=2

例如,您可能要执行三次物理写入,写入仲裁为2。在逻辑写入操作成功之前,您不必等待所有三个操作都完成。如果一次写入失败或速度慢,这是正常的,因为总体操作结果和延迟不会受到异常值的影响。这很重要:即使有什么东西坏了,写入也能成功而且速度很快。

简单的⅔仲裁允许您容忍整个可用性区域的故障。不过,这还不够好。虽然一个区域的故障是一个罕见的事件,但它不会降低其他区域中组件故障的可能性。使用 Aurora,我们的目标是可用性区域+1:我们希望能够容忍一个区域的丢失,再加上一个故障,而不会造成任何数据持久性丢失,并且对数据可用性的影响最小。我们使用 4/6 的仲裁来实现这一目标:

V_w+V_r > V
V_w > V / 2
V=6
V_w=4
V_r=3

对于每个逻辑日志写入,我们发出六个物理副本写入,并考虑当其中四个写入完成时写入操作成功。在每个区域有两个副本的情况下,如果整个可用性区域发生故障,则写入仍将完成。如果某个区域出现故障,并且发生其他故障,仍然可以达到读取仲裁,然后通过快速修复恢复写入能力。

快速修复和追赶

数据复制有不同的方法。在传统存储系统中,数据镜像或擦除编码发生在整个物理存储单元的级别上,几个单元组合在一个 RAID 阵列中。这种方法使修复速度变慢。RAID 阵列重建性能受到阵列中少数设备功能的限制。随着存储设备越来越大,在重建过程中复制的数据量也会越来越大。

Amazon Aurora 使用了一种完全不同的复制方法,基于分片和扩展架构。Aurora 数据库卷逻辑上分为 10GB 逻辑单元(保护组),每个保护组以六副本复制到物理单元(段)。单个存储段分布在一个大型分布式存储中。当发生故障并取出一个段时,修复单个保护组只需要移动大约 10GB 的数据,这在几秒钟内完成。

此外,当必须修复多个保护组时,整个存储组都会参与修复过程。这提供了很高的带宽来快速完成整个修复。因此,如果区域故障后又出现另一个组件故障,对于给定的保护组,Aurora 可能会在几秒钟内失去写入仲裁。然而,一个自动启动的修复能够恢复高速可写性。换言之,Aurora 的储存会很快自我修复。

读取怎么样?仲裁读取代价很高,最好避免。客户端 Aurora 存储驱动程序跟踪哪些段的写入成功。它不需要在常规的页面读取上执行仲裁读取,因为它总是知道从何处获取页面的最新副本。此外,驱动程序跟踪读取延迟,并始终尝试从延迟最低的存储副本读取。唯一需要仲裁读取的情况是在数据库实例重新启动时进行恢复。初始的 LSN 标记必须通过询问存储节点来重建。

创新的基础

许多引人注目的新 Aurora 功能都直接由分布式自愈存储体系结构实现。举几个例子:

  • 读可伸缩性:除了主数据库实例外,在 Aurora 的多个区域中最多可以提供15个读副本,以实现读可伸缩性和更高的可用性。读取副本使用与主机相同的共享存储。
  • 连续备份和时间点恢复:Aurora 存储层连续透明地将 REDO 日志流备份到 Amazon S3。您可以执行时间点还原到配置的备份窗口中的任何时间戳。不需要计划快照创建,并且当最接近感兴趣时间的快照距离较远时,不会丢失任何事务。
  • 快速克隆:Aurora 存储层可以快速创建卷的物理副本,而无需复制所有页面。页面最初在父卷和子卷之间共享,在修改页面时完成写入时的复制。克隆卷时没有重复成本。
  • Backtrack:将数据库回退到特定时间点的快速方法,无需从备份中进行完全恢复。误丢了一张表?你可以用 Aurora Backtrack 来回退。

在 Aurora 存储引擎的基础上建立了更多的关系数据库创新。我们进入了关系数据库的新时代,而 Aurora 只是一个开始。客户的声音是最好的回应。Capital One、Dow Jones、Netflix 和 Verizon 等各行业的领导者都在将关系数据库工作负载迁移到 Aurora,包括 MySQL 和 PostgreSQL 兼容版本。

想进一步了解 Amazon Aurora 设计吗?

Amazon Aurora: Design Considerations for High Throughput Cloud-Native Relational Databases. In SIGMOD 2017

Amazon Aurora: On Avoiding Distributed Consensus for I/Os, Commits, and Membership Changes. In SIGMOD 2018

根据英文原文翻译而来。

History:

2020-12-30 修订