新消息

Amazon Aurora 提升 PostgreSQL 的优化读取功能，查询延迟可改善最高达 8 倍

关键要点

Amazon Aurora 是一个兼容 MySQL 和 PostgreSQL 的云关系数据库。它结合了传统企业数据库的性能和可用性，以及开源数据库的简单性和经济性。我们很高兴宣布推出 Aurora PostgreSQL 的 优化读取 功能。此功能提供了高达 8 倍的查询延迟改善和最多 30 的成本节省，适用于数据集超出数据库实例内存限制的应用。这一新功能现已在支持非易失性内存快照NVMe存储的 AWS Graviton 构建的 dbr6gd 和 Intel 构建的 dbr6id 实例上可用。

Aurora 优化读取的两种能力支持：

在这篇文章中，我们将深入探讨优化读取功能、典型用例以及按引擎和存储配置提供的功能可用性。我们将在此讨论分层缓存能力及其如何提升延迟敏感工作负载的查询性能，同时提供监控选项的概述。

数据增长带来的查询性能挑战

各行业的客户依赖 Aurora 来运行他们最复杂的应用，从简单查询到处理海量数据集。速度对获取洞察和及时决策至关重要。然而，随着数据量的增长，将经常访问的数据即 工作数据集置于内存中变得愈加困难。一旦所需数据不在内存中，Aurora 将从 存储 中取回数据，这将增加数据库实例的 CPU 和网络利用率，进而导致查询延迟上升及 I/O 成本的上升。

随着 Aurora I/O 优化 配置选项的推出，您可以为 I/O 密集型应用获取可预测的定价。然而，为了降低从 Aurora 存储读取数据页面所涉及的网络 I/O 延迟，客户常常配置更大的实例，例如 dbr6i32xlarge，内存与商业 SLA 所需的工作数据集相匹配。仅仅为了内存而过度配置实例，尤其当 CPU 利用率较低时，可能不是最佳的成本效益。

Aurora 优化读取的好处

随着 Aurora 优化读取的推出，您现在可以利用 dbr6gd 和 dbr6id 实例上当地附加的 NVMe 固态硬盘SSD。优化读取的分层缓存通过将本地 NVMe 存储无缝集成到数据库缓冲池，增加了数据库实例的缓存容量。通过在 NVMe 存储上本地缓存数据，优化读取与 Aurora 网络存储相比，提供了更快的响应时间。总体而言，优化读取功能通过减少不必要的内存过度配置来提高价格性能。它还为您应用程序的工作数据集扩展提供了更多灵活性，超出即使是最大实例的内存，使您能够从数据中获得更多更快的洞察。

以下表格详细列出了按引擎、版本和存储配置提供的优化读取功能可用性，以便您进行规划。请注意，此功能仅对 Aurora 预配置实例可用。

介绍优化读取的分层缓存

Aurora 优化读取的分层缓存能力适用于具有数十万并发查询的小型行的高速度 OLTP 读取，这超出了数据库实例的可用内存。这些用例包括：

以下图示展示了启用优化读取特性的 Amazon Aurora PostgreSQL 兼容版 I/O 优化实例的高层次视图。在 Amazon Aurora PostgreSQL 中，数据页面在一个称为 缓冲池 的共享内存区域中缓存，该区域的大小由 sharedbuffers 参数控制默认约占实例内存的 75。如果工作数据集无法适配共享缓冲，则 Aurora 必须从其存储卷中提取数据页面每个页面的大小为 8 KB。利用优化读取，Aurora 定期识别即将被驱逐的页面，并将它们提前写入本地 NVMe 存储。这使得 Aurora 可以在不在内存中时，在分层缓存中搜索请求的页面，从而减少对 Aurora 存储的访问需求。此外，一旦页面在缓冲池中被修改，其副本如果有在分层缓存中也会自动失效，确保事务一致性。

同样，如果 Aurora 集群中有支持优化读取特性的读取实例，写入实例的页面更改会复制到读取实例的缓冲池中，并相应地应用到读取实例的 NVMe 存储。对于启用 集群缓存管理CCM 的 Aurora 集群，优化读取通过将写入者的分层缓存内容镜像到读取者处，扩展了缓存。这可以预热读取缓存，提升故障恢复后的查询性能。该分层缓存还可以在数据库进程故障或重启的情况下独立存活，这类似于 Aurora 的可以存活的缓冲缓存。有关更多信息，请参阅 Amazon Aurora 存储与可靠性。

在 Aur PostgreSQL I/O 优化实例中，若可用优化读取分层缓存，Aurora 为临时对象分配两倍于实例内存的空间，约占内部操作存储的 10，其余存储用于分层缓存。

启用 Aurora 优化读取的分层缓存

要使用优化读取的分层缓存能力，请根据支持的 dbr6gd 或 dbr6id 实例配置新的 Aurora PostgreSQL I/O 优化集群如下图所示。如果您有现有的 Aurora PostgreSQL I/O 优化集群，只需 修改写入者或读取者数据库实例请注意，此操作需要停机。无需额外配置选项或数据库参数更改来启用优化读取功能。

在配置并连接到数据库实例后，您可以通过运行以下 SQL 命令来验证优化读取功能是否已启用：

sqlshow sharedpreloadlibraries sharedpreloadlibraries

rdsutilspgstatstatementsauroraoptimizedreadscachewriteforward

根据您的用例和性能需求，您可以为写入者、读取者或两者都使用优化读取功能。例如，您可以将写入者实例配置为 dbr6gd4xlarge启用优化读取，而将读取者实例配置为 dbr6g4xlarge禁用优化读取。

要切换回不支持优化读取的 Aurora 实例，您需要修改数据库实例类别并选择非 NVMe 的实例类型。有关更多信息，请参阅 在 DB 集群中修改数据库实例。

优化读取分层缓存的性能优势

对于从 Aurora 存储中进行的小型读取的 OLTP 查询，分层缓存功能提供了最佳的收益，例如通过索引访问每个表几行的 SELECT 查询。这类查询受到 Aurora 存储与数据库实例之间网络传输时间的影响最大，因此从分层缓存中获益最多。

我们使用 sysbench 基准测试工具详见 GitHub 的使用说明来评估 OLTP 工作负载的分层缓存优势。测试环境包含两个仅有写入实例的 Aurora PostgreSQL 154 集群一个为 dbr6g8xlarge32 vCPU，256 GiB 内存，另一个为 dbr6gd8xlarge32 vCPU，256 GiB 内存，1900 GB NVMe SSD。我们运行了 oltpreadwrite 基准测试，创建了一个 1 TB 大小的数据库，包含 16 个表，每个表 25 亿行。然后，我们以固定速率的统一分布加载缓冲池，比较了启用与禁用优化读取分层缓存的性能。我们的基准测试使用了以下选项：

sqlsysbench tables=16 tablesize=250000000 reportinterval=60 randtype=uniform histogram= on threads= 512 rate=1200 warmuptime=300 time=3200 oltpreadwritelua run

如以下图表所示，sysbench 结果显示在相同工作负载下，启用优化读取的延迟改善约为 52 倍，dbr6gd8xlarge 的每秒事务平均延迟为 115 毫秒，而 dbr6g8xlarge 则为 60 毫秒值越低越好。每个 sysbench 事务运行 18 个 SQL 语句涉及 SELECT 和 DML 查询。

接下来，我们分析服务器端的 sysbench 查询延迟特征。Amazon RDS 性能洞察 提供了对数据库负载、等待事件和 Aurora 实例上的顶级 SQL 的更深入的可视化。以下图形展示了 dbr6g8xlarge 和 dbr6gd8xlarge 的基准测试运行的性能洞察仪表盘。截图中的 Top SQL 部分显示了在 Aurora 数据库实例上测量的单个 SQL 语句的平均延迟，不包括客户端与数据库实例间的网络延迟。从仪表盘中，我们可以看到对于点选查询 (SELECT c FROM sbtest15 WHERE id=1)，平均延迟从 184 毫秒减少到 020 毫秒值越低越好，改善幅度为 9 倍。

以下截图展示了没有优化读取的 dbr6g8xlarge 上的性能测量。

以下截图展示了启用了优化读取的 dbr6gd8xlarge 上的性能。

以下图表显示了在使用优化读取的 sysbench 运行中，测量的数据库端 点查询延迟 高达 9 倍改善。

接下来，我们比较两个测试运行的负载特征和等待事件。根据仪表盘，我们可以看到，整体数据库负载明显下降，从平均活跃会话数 649 降至 96。同时，最高等待事件从 IODataFileRead 切换为 IOAuroraOptimizedReadsCacheRead，表明 I/O 发生在本地 NVMe 存储，而非 Aurora 存储。这些因素也可能促成了启用优化读取的测试运行的优化 CPU 使用。在以下截图中，我们发现 Amazon CloudWatch 平均 CPUUtilization 指标显示启用优化读取时为 30，而禁用时为 45。

使用相同的基准测试环境，我们还进行了一个不指定固定速度的 sysbench 吞吐量测试，发现峰值吞吐量从 1732 TPS 增加至 4594 TPS值越高越好。

无论是延迟还是吞吐量的 sysbench 测试表明，读密集型查询在需要更大实例之前能够更高效地扩展，从而提升了 OLTP 工作负载的价格性能。

监控优化读取

本节提供了监控选项的简要概述，以了解分层缓存的使用情况。

数据库级别监控

在启用优化读取功能的实例上，您可以运行 explain 命令检查查询是否受益于分层缓存，如以下代码所示。我们在解释计划的 Buffers 部分引入了 auroraorcachehit 和 aurorastorageread 字段。这些列仅在命中大于零时出现。read 字段显示 auroraorcachehit 和 aurorastorageread 的总和。

sqlEXPLAIN (ANALYZE BUFFERS) SELECT c FROM sbtest15 WHERE id=100000000QUERY PLAN

Index Scan using sbtest15pkey on sbtest15 (cost=057859 rows=1 width=121) (actual time=02870288 rows=1 loops=1) Index Cond (id = 100000000) Buffers shared hit=3 read=2 auroraorcachehit=2 I/O Timings shared/local read=0264 Planning Buffers shared