发布于: Aug 8, 2022
云关系数据库方兴未艾。关系数据模型可以追溯至 1970 年代 E.F.Codd 的探索。支撑当今主要关系数据库管理系统的核心技术是在 1980-1990 年代开发的。关系数据库的基本要素包括数据关系、ACID（原子性、一致性、独立性和持久性）事务、SQL 查询语言等，都经受住了时间的考验。凭借这些基本特点，关系数据库赢得了全世界用户的钟爱。它们依然是许多公司 IT 基础设施的基石之一。
但这并不是说系统管理员一定很喜欢处理关系数据库。数十年来，管理关系数据库一直都是一件对技能要求非常高的劳动密集型工作。它要求有专门的系统和数据库管理员全神贯注。对关系数据库进行扩展并同时保持容错能力、性能和爆炸半径大小（发生故障的影响），一直是管理员们面临的一个持久挑战。
此外，现代互联网工作负载的要求变得越来越高，需要基础设施具备多个关键的特性：
- 用户希望先从小规模起步，然后再大规模增长，基础设施不应限制他们的发展速度。
- 在大型系统中，故障属于常态，而非异常。发生组件故障或系统故障时，客户工作负载必须隔离。
- 爆炸半径要小。没有人希望单一的系统故障对他们的业务产生巨大影响。
这些问题很难处理，需要突破传统关系数据库架构才能解决。当亚马逊公司面临 Oracle 等传统关系数据库的局限性时，我们创建了一种先进的关系数据库服务 Amazon Aurora。
Aurora 的设计保留了关系数据库的核心事务一致性优势。它在存储层进行了创新，构建了一个面向云的数据库，可以在不牺牲性能的前提下支持现代工作负载。客户非常喜欢这一点，因为 Aurora 提供了商业级数据库的性能和可用性，但成本只有后者的十分之一。从 Aurora 最初发布以来，它一直是 Amazon Web Services 历史上增长最为快速的服务。
关系数据库的重新构想
想想传统关系数据库的架构：
过去 30-40 年来，这种整体式的关系数据库堆栈没有太大改变。虽然在数据库扩展方面存在不同的常规方法（例如，分区、无共享或共享磁盘等），但这些方法都基于同样的基本数据库架构。这些方法无法解决大规模性能、弹性和爆炸半径问题，因为严密耦合型整体式堆栈的基本局限性依然存在。
为开始解决关系数据库的局限性，我们重新构想了堆栈的概念，将系统分解为基本的组成要素。我们认识到缓存和日志记录层非常适合创新。我们可以将这些层变为一种针对性、可扩展、可自我恢复、多租户、数据库优化的存储服务。在我们开始构建这个分布式的存储系统时，Amazon Aurora 应运而生。
我们对关系数据库中缓存和日志记录的传统理念提出挑战，重新构想了数据库 I/O 层，收获了极大的可扩展性和弹性优势。Amazon Aurora 采用了卸载恢复操作日志记录、基于元组的架构、仲裁以及快速数据库修复等理念，具有极佳的可扩展性和弹性。
卸载恢复日志记录：日志就是数据库
传统关系数据库以页面的方式来组织组织，因此在页面修改后，必须定期刷新到磁盘。为确保在发生故障时的弹性以及维护 ACID 语法的需要，页面修改也将在记录在恢复日志记录中，这些日志记录将以连续统的方式写入磁盘。虽然这种架构提供了支持关系数据库管理系统所需的基本功能，但却存在效率低下的弊端。例如，单个逻辑数据库写入会变为多个（不超过五个）物理磁盘写入，从而引发性能问题。
数据库管理员会尝试通过降低页面刷新的频率来消除写入放大的问题。但这反过来又会加剧崩溃恢复持续时间的问题。刷新间隔时间越久，意味着为了重建正确的页面映像，需要从磁盘读取并应用的恢复日志记录越多。这会导致恢复速度下降。
在 Amazon Aurora，日志就是数据库。数据库实例将恢复日志记录写入分布式的存储层，由存储负责按需利用日志记录构建页面映像。数据库实例无需帅新脏页面，因为存储层始终知道页面的具体内容。这从多个方面提高了数据库的性能和可靠性。由于消除了写入放大，并且使用了扩展存储队列，写入性能得到极大的提高。
例如，按照 SysBench 基准，Amazon Aurora MySQL 兼容版的 IOPS 写入速度 是在类似硬件上运行的 Amazon RDS for MySQL 的 5 倍。由于数据库实例不再需要执行恢复日志流重放，数据库崩溃恢复时间显著降低。存储层负责在页面读取上执行恢复日志，从而形成一个不受传统数据库架构限制的新存储服务，让您可以更进一步创新。
相关文章