深入探讨 Amazon Aurora 及其创新 (DAT441)

场次笔记

Aurora 概述

• Amazon Aurora 是一种云原生关系数据库
• 将高端商业数据库的速度和可用性与开源数据库的简洁性和成本效益相结合
• 完全托管，兼容 MySQL 和 PostgreSQL
• 包含与无服务器应用和机器学习应用集成的工具
• 使用 Aurora 无需更改应用
• 支持 PostgreSQL 扩展
• 最新新增：Aurora DSQL（分布式 SQL）
• Aurora 架构：
• 使用 3 个可用区
• 配备跨越全部 3 个可用区的 Aurora 存储
• 存储节点处理日志记录，并将其转换为数据库页面

Aurora 存储的主要功能

• 不存在检查点、全页写入、双写缓冲区或日志归档等传统数据库问题
• 数据以 6 个副本冗余存储在 3 个可用区的 6 个存储节点中
• 对损坏或遗漏的日志记录或发生故障的存储节点进行自动点对点修复
• 副本管理：
• 最多可添加 15 个只读副本，且不会产生一致性延迟
• 头节点之间进行异步失效和更新
• 副本可以采用不同的大小和实例类型（例如 Graviton、Intel）
• 存储空间可自动扩展至 256 TB
• 自动失效转移：
• 发生故障时，将副本提升为读写节点
• 通过基于 DNS 的端点变更对应用程序进行重新路由
• 提供高级快速驱动程序，可实现更快（最高快 66%）的失效转移
• 多区域功能：
• 跨区域异步复制存储（Global Database）
• 复制由 Aurora 处理，无需更改应用程序
• 通过在次要区域运行应用程序，可实现低延迟的区域本地读取
• 全局数据库设置最多可使用 10 个区域
• 技术说明：
• 头节点不参与复制过程
• 次要区域中的只读副本能够近乎即时地呈现数据，典型 RPO 延迟不到一秒

全局端点和失效转移

• 全局端点是指向当前写入器区域的 DNS 名称
• 如果主要区域出现问题，则发起失效转移操作
• 失效转移会将另一个区域中的副本提升为写入器节点
• 由于采用异步复制，可能会发生数据丢失
• 全局端点的 DNS 名称通过 Route 53 数据计划 API 更新 Global Database 切换：
• 当两个区域均处于正常状态时进行切换，并出于运营原因迁移写入器
• 最近的改进将切换时间从 5 分钟缩短至 30 秒
• 利用基于日志的架构实现零数据丢失（RPO 为 0）和 30 秒恢复时间（RTO 为 30 秒）
• 本地写入转发：
• 允许将来自次要可用区的写入转发到写入器节点
• 不会将系统转变为主动-主动配置
• 来自可用区 2 的写入会转发到可用区 1 中的写入器节点，在那里执行并返回结果
• 在不损害数据完整性或系统设计的情况下增强运营灵活性 Aurora 中的一致性模式：
• 提供三种不同的一致性模式/可见性模式
• 默认模式为会话可见性，该模式会等待更新得到确认后再继续读取
• 最终一致性模式不等待更新，可能导致读取结果无法反映最新写入
• 全局一致性模式会等待整个集群中的所有更新完成后再继续，确保读取反映所有写入
• 本地写入转发：
• 允许将来自次要可用区的写入转发到写入器节点
• 保持与本地操作相同的一致性模式和注意事项
• 跨区域延迟差异是全局写入转发中的一个影响因素 Aurora 存储节点操作：
• 每个存储节点都运行一个“存储守护进程”，用于促进引擎与存储之间的通信
• 日志记录写入传入队列，随后排入磁盘上的热日志，然后得到确认
• 遗漏的日志记录（例如由于传输延迟）可以通过点对点方式从其他存储节点获取
• 日志记录会合并为数据库页面，确保在对延迟影响最小的情况下处理读取请求
• 持续备份到 S3，支持还原到过去 35 天内的任意时间点

IO 优化配置

• 调整配置选项，为 IO 密集型应用程序提高吞吐量。
• 修改存储驱动程序以进行更积极的批处理，这对 IO 密集型应用程序有利。
• 利用现代引擎版本进行进一步优化。
• 将传入队列更改为持久队列，以减少延迟和抖动，从而提升性能。
• Aurora PostgreSQL 兼容性和更新：
• Aurora PostgreSQL 与 PostgreSQL 完全兼容。
• 定期集成上游 PostgreSQL 更新。
• 支持最高 PostgreSQL 17.6 版本。
• 兼容带本地磁盘的 RAG 实例类型。
• 包含来自上游的众多性能改进，包括相关子查询缓存、自适应联接等。
• 引入共享计划缓存以提高内存效率。
• 增强大型实例和副本的读取可用性。
• 实施 FIPS 140-3 安全加密。
• 更新各种扩展，尤其是 PG vector。
• 支持最高 256 TB 的卷。
• Aurora PostgreSQL 性能分析：
• 评估不同实例代系之间的吞吐量。
• 测试示例：
• R52.4Xlarge（较旧实例）与 R7i.48Xlarge（较新、较大实例）的 CPU 密集型性能对比显示，性能提升了 2.1 倍。
• 引入 R8G（下一代 Graviton 版本）后，相较基准提升了 2.7 倍，表明实现了超线性扩展。
• 超线性扩展意味着，随着资源（如数据大小或节点）增加，系统或流程的性能或效率获得不成比例的显著提升；这常见于对数增长或专用架构，与线性增长（输入翻倍时输出翻倍）或次线性扩展（收益递减、Amdahl 定律限制）形成对比，并应用于数据可视化、数据库性能和计算效率。

Aurora PostgreSQL 动态数据掩码

• Aurora 中用于保护敏感数据的新功能。
• 敏感数据包括账号、账户持有人姓名和个人身份信息 (PII)。
• Aurora PostgreSQL 中的动态数据掩码：
• 旨在通过提供经过取整或掩码处理的数据版本来保护敏感数据。
• 通过 Aurora 中新的 PG column mask 扩展实现。
• 允许为特定表和列定义掩码策略。
• 示例：
• 将客户 ID 掩码为 X，并对账户余额进行取整。
• 策略适用于指定角色（例如 'analyst'），并为冲突解决定义权重。
• 在查询重写层中实现，以获得高效性能且不影响索引。
• 动态数据掩码的实施详情：
• 掩码函数在查询重写阶段应用，而不是在获取数据之后应用。
• 确保良好性能并保持索引功能。
• 在查询描述输出中可以看到掩码函数应用于目标列。
• Aurora MySQL 更新：
• 最近发布了与 MySQL 8.0.43 兼容的 3.11 版本。
• 引入具有增强功能的 3.10.0 长期支持版本。
• 内存中中继日志缓存使日志复制吞吐量最高提升 40%。
• MySQL 的高级快速驱动程序支持 ODBC。 ODBC (Open Database Connectivity) 是一种 API，使应用程序能够使用标准语言 SQL 访问来自各种数据库管理系统的数据。它充当桥梁，使单个应用程序能够连接到 SQL Server、MySQL 或 Oracle 等不同数据库，而无需针对每种数据库重写。
• 卷支持容量提高至 256 TB。
• 全局数据库次要读取器可在发生全局性问题时提高读取可用性。

Aurora Serverless

• 推荐的实例类型，可简化机群管理。
• 根据工作负载需求自动调整 CPU 和内存。
• 随着 V1 生命周期结束，Aurora Serverless V2 已重命名为 Aurora Serverless。
• 提供弹性实例类型，实现灵活的资源分配。
• Aurora Serverless 的功能和优势：
• 无需重启引擎即可自动扩展内存、CPU 和网络。
• 每秒进行扩展，以 Aurora Capacity Units (ACUs) 为度量单位，每个 ACU 代表 2 GB RAM 及相关资源。
• 响应 Lambda 函数或分析作业进行扩展，根据需求调整 ACU。
• 按秒计费，用户只需为实际使用的资源付费。
• Aurora Serverless 中的扩展机制：
• 使用扩展桶运行，该桶会定期填充额度，从而允许扩展到设定的最大 ACU 限制。
• 需要扩展时会消耗额度，扩展桶会随时间推移重新填充。
• 最近的增强包括更快的触发响应（不到 1 秒）、更大的初始桶容量和更快的补充速率。
• 平台版本 3 的性能改进：
• 无需进行任何选择或额外配置，即可将性能提高多达 30%。
• 适用于所有新集群，可通过从备份还原、克隆或创建新集群来使用。
• 性能示例：
• 对平台版本 2 启用和不启用快速扩展的测试表明，启用快速扩展后的峰值性能持续时间延长了 3.6 倍，使用的 ACU 小时数减少了 9%。
• 对平台版本 3（结合快速扩展）的测试表明，与平台版本 2 相比，运行时间和使用的 ACU 小时数均减少了 20%，从而使账单费用降低 20%。
• 更快的扩展和平台版本 3 都会自动应用于新集群，无需用户付出额外精力即可获得更高的性能和成本效益。

使用快速配置创建

• 在几秒内快速创建数据库集群。
• 面向频繁创建集群的用户，例如 CI/CD 管道或智能体 AI 应用程序的用户。
• 支持为每次交互创建新数据库，从而提高敏捷性和速度。
• 使用快速配置创建的功能：
• 提供灵活且可编辑的配置，初始为 16 ACUs (Aurora Capacity Units)。
• 允许在创建后修改大多数设置，包括更改 ACU 和其他配置。
• 默认启用加密和 IAM (Identity and Access Management)，确保安全。
• 支持几乎所有 Aurora 功能，包括全局数据库和零 ETL。
• 无需 VPC：
• 引入 Aurora Internet Access Gateway，这是一个无需 VPC (Virtual Private Cloud) 即可访问数据库集群的新组件。
• Internet Access Gateway 是兼容 PostgreSQL 线路协议的高可用端点，可最大限度地减少延迟。
• 允许从任何位置访问数据库集群，减少对 VPN 的需求并简化开发人员的操作流程。
• 与 Amazon IAM 和 AWS Shield 集成，提供欺诈防护和数据保护等增强的安全功能。
• AWS Shield 是一项托管服务，用于保护在 Amazon Web Services (AWS) 上运行的应用程序免受分布式拒绝服务 (DDoS) 攻击。它提供两个层级：免费的 AWS Shield Standard，可自动缓解常见的网络层攻击；以及付费的 AWS Shield Advanced，可针对更复杂的攻击提供防护、高级功能和专家支持。

Aurora 与智能体 AI 的集成

• Aurora 可以充当智能体 AI 系统的内存，这对智能体 AI 循环的运行至关重要。
• 使用“Letter”框架的示例：使用快速配置创建数据库集群，为向量嵌入启用 PG vector 扩展，并将 Letter 框架指向 PostgreSQL 端点。
• Aurora PostgreSQL 可用于 LangChain 等各种框架中的遗传式 AI 内存。
• AWS 开源的 MCP (Model Context Protocol) 服务器支持理解 Aurora 数据库架构的自然语言查询，并将其转换为 SQL 查询。这对探索数据库的新用户和追求效率的高级用户都有帮助。
• Aurora 中的修补和升级：
• Aurora 为集群修补和升级提供托管体验，可在控制台中查看待处理的维护操作。
• 操作系统补丁以滚动方式应用于集群中的多个节点，从而增强可用性。
• 用户可以为更新设置维护时段，并接收维护操作通知。
• 维护操作自动化是可选的，允许用户通过 Terraform 等自己的系统控制升级。
• 对于集群机群，按顺序升级开发、QA 和生产环境至关重要。
• Aurora 集群的顺序升级：
• 按顺序升级不同环境（开发、QA、生产）非常重要，以便留出测试和响应时间。
• 随机发布维护公告可能导致 QA 环境先于开发环境升级，这与期望的顺序相悖，是一项挑战。

AWS Organizations 的升级推出策略

• 引入该策略是为了解决顺序问题，允许将升级分为多个波次（第 1 波、第 2 波、最后一波）。
• 该流程包括通知用户、等待第一波的维护时段、升级这些实例、进行烘焙（测试期），然后推进到下一波。
• 为用户提供充足时间，以便在出现问题时作出响应或选择退出。
• 无论在一周中的哪一天发布更新，升级都会按顺序进行。
• 升级推出策略的实施：
• 需要启用 AWS Organizations，并将账户置于组织内。
• 常规设置包括启用自动次要版本升级并设置维护时段。
• 通过将标签与资源关联来设置策略；例如，为资源添加 "env=prod" 标签，使其归入最后一波。
• 没有可识别标签的资源默认归入指定波次（例如第二波）。
• 用户可以选择不使用标签并接受默认设置，以便对所有资源进行一次性升级。
• 应用升级推出策略：
• 创建策略后，可以将其附加到整个组织（根）或单个账户，以实现选择性应用。
• 在升级期间，用户将在待处理维护操作和 AWS Health 中看到通知，指明升级将在哪个波次进行。

用于主要版本升级的蓝绿部署

• 对于与当前版本不兼容、就地执行会需要停机的主要版本升级，蓝绿部署至关重要。
• 该过程包括创建生产环境的完整副本（“绿”环境），使用逻辑复制同步数据，并在蓝绿部署运行期间持续保持同步。
• 支持在切换前对升级后的环境进行全面测试。
• 通过 CLI 或控制台完成的切换会重命名 AWS 资源，并将端点切换到绿环境，从而确保无数据丢失且停机时间最短（通常不到一分钟）。
• 如果切换超时，则提供回退选项，自动恢复到原始（蓝）环境。
• 不仅适用于版本升级，也适用于架构更改、静态参数更改，以及被认为就地更改风险过高的维护更新。
• 全局数据库的蓝绿部署：
• 最近新增的全局数据库支持允许使用蓝绿部署跨区域执行主要版本升级。
• 该过程与单区域部署相同，通过逻辑复制确保数据同步和最短停机时间（切换约需 1 分钟）。
• 支持对整个全局集群进行主要版本升级，实现零数据丢失（RPO 为 0），恢复时间目标 (RTO) 约为 1 分钟。

Aurora 的零 ETL 功能

• 无需管理 ETL 管道，即可将数据从 Aurora PostgreSQL 低延迟传输到 Redshift。
• 通过一条 CLI 命令在 Aurora 与 Redshift 集群之间创建管道来实现。
• 复制延迟为 5 到 12 秒，确保数据可快速在 Redshift 中使用。
• 管理数据植入、维护和变更数据捕获 (CDC) 流式传输，使用户无需处理这些复杂事项。
• 支持将多个 Aurora 集群（包括 MySQL 和 PostgreSQL）集成到单个 Redshift 集群或数据湖中。
• 还支持使用相同技术将数据从 Aurora MySQL 传输到 SageMaker。
• 零 ETL 的底层技术：
• 在存储层利用并行直接导出，将数据快速植入 Redshift 而不影响性能。
• 使用嵌入存储中的增强型 bin logs（用于 MySQL）或 PostgreSQL 的等效机制来捕获逻辑复制日志。
• CDC 流式传输服务器直接从存储读取日志，应用筛选和修改后再将数据推送到 Redshift，确保不会对头节点产生性能影响。
• Aurora 存储类型：
• Aurora Standard：提供基本性能和成本特征的默认存储类型。

Aurora 存储成本和性能详解

• 读取操作：如果数据已缓存，则成本极低（仅需几毫秒的实例运行时间）。如果缓存未命中，则从存储中读取数据；根据数据库引擎，每个 8K 或 16K 数据库页面的成本为几美分的一小部分。
• 写入操作：最多 4 KB 的写入成本为几美分的一小部分。较大的写入可批处理为最多 4 次 I/O；根据每个批次的大小，其成本为几美分的一小部分。
• Aurora I/O Optimized 存储：
• 提供更可预测的定价，并可能带来更好的性能。
• 这是集群级配置，可以在创建集群时选择，也可以在线切换。
• 会同时改变系统性能和架构，包括存储端的更改。
• 建议 Aurora 账单中 I/O 占比超过 25% 的用户使用，因为它很可能可以节省成本并提升性能。
• 适用于过去 18 个月内发布的所有现代引擎版本，并兼容数据库节省计划。
• I/O Optimized 存储的成本模型：
• 用户为计算和存储支付略高的费用，但 I/O 成本为零，使计费更简单且更可预测。
• 非常适合有大量 I/O 操作的工作负载，因为计算和存储的溢价成本会被省去的 I/O 成本抵消。
• I/O Optimized 带来的性能提升：
• 在 16X large 实例上进行的测试表明，在运行版本 14 的 R6I 16X large 实例上启用 I/O optimized 后，吞吐量提升了 1.9 倍。
• 升级到使用 PostgreSQL 版本 16 的 R7I 实例后，观察到进一步提升（额外 10%）。

I/O Optimized 带来的延迟和吞吐量改进

• 延迟测试：在运行 PostgreSQL 版本 17 的 R8G 48X large 实例上使用 I/O optimized 时，延迟得到显著改善，低端提升 3 倍，高端提升 6.4 倍。
• 吞吐量测试：在相同条件下，吞吐量提升 5 倍，凸显 I/O optimized 在延迟和吞吐量方面的双重优势。
• 临时对象和本地 NVMe 存储：
• 本地 NVMe 存储是指服务器或云实例中速度极快、物理连接的固态硬盘 (SSD)，可提供极低延迟和高吞吐量，非常适合需要临时高性能暂存空间的高要求应用程序（AI/ML、数据库）。
• 速度：使用 PCIe 总线，绕过网络/控制器瓶颈，实现亚毫秒级延迟和海量 IOPS。
• 直接连接：物理安装在服务器/实例机箱内部（例如 AWS EC2 或 Azure VM）。
• 临时性：数据是临时的；实例终止、发生故障，甚至有时重启/维护后，数据都不会保留。
• 在 PostgreSQL 中使用临时对象执行索引重建或大型排序等操作，这些操作可能超出内存容量并需要磁盘存储。
• 在普通系统中，该磁盘是 EBS 磁盘，因此会引入性能方面的考量。
• 对于 RAGD 等 D 实例，则改用本地 NVMe 实例存储，允许为溢写分配最多相当于内存大小 6 倍的空间，从而显著降低使用这些临时对象的工作负载的延迟并提升性能。
• I/O Optimized 对临时对象存储的影响：
• I/O optimized 将临时对象的分配空间从内存的 6 倍减少到 2 倍，在使用较少存储空间的同时仍能提升性能。
• 节省的存储空间用于一项名为分层缓存的功能，该功能旨在通过提供额外缓存层来进一步提升性能。

分层缓存

• 利用在 I/O optimized 下减少临时对象存储分配所节省的空间。
• 旨在通过添加额外的缓存层来提升性能，但摘录中未提供分层缓存具体工作方式的详细信息。
• 常规读取流程：
• 首先检查共享缓冲区；如果找到数据，则读回数据，无需进一步操作。
• 如果共享缓冲区中没有数据，则从存储将其读入共享缓冲区，然后提供给引擎。
• 使用 D 实例进行优化读取：
• 在磁盘上分配相当于内存 4 倍的空间作为分层缓存，其使用方式与共享缓冲区类似。
• 使用元数据确定请求的数据是否在磁盘缓存中。
• 从存储读取的数据会放入共享缓冲区；缓冲区已满时，数据会被逐出至分层缓存，并由元数据进行跟踪。
• 使用分层缓存处理更新：
• 更新通过翻转元数据位使分层缓存中的数据失效，从而避免频繁写入分层缓存。
• 弹性动态分层缓存：
• 能够根据工作负载需求调整分层缓存与临时对象的大小。
• 对大量磁盘溢写的工作负载增加临时空间，并在工作负载结束后减少该空间，以扩大分层缓存。

R8GD 实例性能

• 新实例类型，价格与 R6GD 相同，但性能提升 165%。
• 建议分层缓存用户以及正在考虑使用分层缓存的用户采用。
• 分层缓存带来的性能提升：
• 降低读取操作的延迟，尤其是对于超出内存容量的数据。
• 在 340 GB 测试中，与内存相比，分层缓存的延迟增加了 1.5%；而没有分层缓存时延迟增加 8 倍，相比之下存在 3 倍差距。
• Pareto 随机分布测试显示出更佳性能，大型测试中的延迟仅降低 1.4 倍。
• 实际使用案例：
• PG vector 基准测试显示，使用优化读取（R7GD 与 R8G 对比）时，每秒查询数提升超过 3.5 倍。
• R6GD 与 8GD（价格相同）相比，向量性能提升 1.6 倍。
• R：表示内存优化型实例系列。
• 7：表示当前代系（第 7 代）。
• g：表示该实例使用 AWS Graviton 处理器（Arm 架构）。
• d：表示包含基于本地 NVMe 的 SSD 存储。
• Amazon EC2 R8g 实例由 AWS Graviton 4 处理器提供支持，代表 AWS 最新一代内存优化型实例，适用于大型数据库、实时分析等要求严苛的内存工作负载。
• Aurora PostgreSQL 与 Aurora MySQL 概述：
• Aurora PostgreSQL：与 PostgreSQL 完全兼容，使用单写入器架构，通过隐式或显式锁定实现并发写入。
• Aurora MySQL：利用主动-主动查询处理器执行多次写入，并使用乐观并发控制来管理冲突。
• Aurora PostgreSQL 中的横向扩展涉及添加采用异步复制的副本，这会带来一致性问题，并利用缓存提升性能。
• 主要区别：
• 并发处理：PostgreSQL 使用锁定；MySQL 使用乐观并发控制。
• 写入架构：PostgreSQL 使用单个写入器；MySQL 支持多个活跃写入器。
• 扩展机制：PostgreSQL 通过副本扩展；MySQL 通过额外的查询处理器扩展。

Aurora PostgreSQL 与 Aurora MySQL 详细对比

• Aurora PostgreSQL：使用具有单个写入器的主动-被动架构，并使用显式锁定实现并发。支持通过添加副本进行扩展，并使用异步复制。
• Aurora MySQL (DSQL)：采用具有多个写入查询处理器的主动-主动架构，并使用乐观并发控制。通过分布式块存储独立扩展读取。
• Aurora 中的读取和写入流程：
• 读取：由选定的查询处理器从跨可用区 (AZ) 的存储服务器中获取数据。
• 写入：查询处理器会累积写入操作，直至事务提交。提交时，写入先发送到裁决器（用于解决冲突），然后发送到日志节点（用于跨 AZ 存储日志），后者会更新受影响的存储分片。
• 多区域运行：
• Aurora PostgreSQL：对跨区域数据使用异步复制，因此提交延迟仅限区域内。
• Aurora MySQL：提交会跨区域同步复制，因此跨区域提交延迟成为一项根本差异。