# 使用 Aurora 优化型读取功能提高 Aurora PostgreSQL 的查询性能
<a name="AuroraPostgreSQL.optimized.reads"></a>

使用 Aurora 优化型读取功能，您可以实现更快的 Aurora PostgreSQL 查询处理。使用 Aurora 优化型读取功能的 Aurora PostgreSQL 数据库实例可将查询延迟缩短多达 8 倍，对于具有超出数据库实例内存容量的大型数据集的应用程序，最多可节省 30% 的成本。

**Topics**
+ [

## PostgreSQL 中的 Aurora 优化型读取功能概述
](#AuroraPostgreSQL.optimized.reads.overview)
+ [

## 使用 Aurora 优化型读取
](#AuroraPostgreSQL.optimized.reads.using)
+ [

## Aurora 优化型读取的使用案例
](#AuroraPostgreSQL.optimized.reads.usecases)
+ [

## 监控使用 Aurora 优化读取的数据库实例
](#AuroraPostgreSQL.optimized.reads.monitoring)
+ [

## Aurora 优化型读取的最佳实践
](#AuroraPostgreSQL.optimized.reads.bestpractices)

## PostgreSQL 中的 Aurora 优化型读取功能概述
<a name="AuroraPostgreSQL.optimized.reads.overview"></a>

创建使用基于 Graviton 的 R6gd、R8gd 和基于英特尔的 R6id 实例以及非易失性存储规范（NVMe）存储的数据库集群时，默认可以使用 Aurora 优化型读取功能。可在以下 PostgreSQL 版本中可使用此功能：
+ 对于 R8gd 实例，为 14.12 及更高版本、15.7 及更高版本、16.3 及更高版本、17.4 及更高版本
+ 对于 R6gd 和 R6id 实例，为 14.9 及更高版本、15.4 及更高版本、16.1 及所有更高版本

Aurora 优化型读取支持两种功能：分层缓存和临时对象。

**启用优化型读取的分层缓存** - 使用分层缓存，您可以将数据库实例缓存容量最多扩展至实例内存的 5 倍。这样可以自动维护缓存以包含最新的、事务一致的数据，从而使应用程序免除管理基于外部结果集的缓存解决方案数据货币的开销。对于之前从 Aurora 存储中获取数据的查询，查询延迟可缩短高达 8 倍。

在 Aurora 中，默认参数组中 `shared_buffers` 的值通常设置为可用内存的 75% 左右。但是，对于 r8gd、r6gd 和 r6id 实例类型，Aurora 将减少 4.5% 的 `shared_buffers` 空间，用于托管优化型读取缓存的元数据。

**启用优化型读取的临时对象** - 使用临时对象，您可以通过将 PostgreSQL 生成的临时文件放置在本地 NVMe 存储上来实现更快的查询处理。这将减少通过网络流向 Elastic Block Storage（EBS）的流量。对于排序、联接或合并大量数据而不符合数据库实例上可用内存容量范围的高级查询，延迟可缩短高达 2 倍，吞吐量可提升高达 2 倍。

在 Aurora I/O 优化版集群上，优化型读取同时在 NVMe 存储上利用分层缓存和临时对象。借助启用了优化型读取的分层缓存功能，Aurora 为临时对象分配 2 倍的实例内存，为内部操作分配大约 10% 的存储，剩余的存储作为分层缓存。在 Aurora 标准集群上，优化型读取仅使用临时对象。

Aurora I/O 优化型集群可让您在实例级别使用动态参数 `aurora_temp_space_size`，来调整已启用优化型读取功能的临时对象的分配空间大小。可以在以下 PostgreSQL 版本中使用此调整大小功能：
+ 16.8 及所有更高版本
+ 15.12 及更高的 15 版本
+ 14.17 及更高的 14 版本

使用此参数，无需重新启动数据库引擎，即可调整实例内存的容量（范围从 2 倍到最多 6 倍）。当您扩展临时对象空间时，无论并发工作负载如何，更改都会立即生效。但是，当您缩小空间时，只有当临时对象中有足够的未使用空间来容纳新的大小请求之后，调整才会完成。调整启用了优化型读取功能的临时对象的大小后，分层缓存会自动调整以使用任何可用空间。

[\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.optimized.reads.html)

**注意**  
在基于 NVMe 的数据库实例类上，在 IO 优化型集群和标准集群之间切换会导致数据库引擎立即重启。

在 Aurora PostgreSQL 中，使用 `temp_tablespaces` 参数配置存储临时对象的表空间。

要检查是否配置了临时对象，请使用以下命令：

```
postgres=> show temp_tablespaces;
temp_tablespaces
---------------------
aurora_temp_tablespace
(1 row)
```

`aurora_temp_tablespace` 是由 Aurora 配置的指向 NVMe 本地存储的表空间。您无法修改此参数或切换回 Amazon EBS 存储。

要检查优化型读取缓存是否已开启，请使用以下命令：

```
postgres=> show shared_preload_libraries;
                 shared_preload_libraries
--------------------------------------------------------
rdsutils,pg_stat_statements,aurora_optimized_reads_cache
```

## 使用 Aurora 优化型读取
<a name="AuroraPostgreSQL.optimized.reads.using"></a>

当使用其中一个基于 NVMe 的数据库实例预调配 Aurora PostgreSQL 数据库实例时，该数据库实例会自动使用 Aurora 优化型读取功能。

要启用 Aurora 优化读取，请执行以下操作之一：
+ 使用其中一个基于 NVMe 的数据库实例类创建 Aurora PostgreSQL 数据库集群。有关更多信息，请参阅 [创建 Amazon Aurora 数据库集群](Aurora.CreateInstance.md)。
+ 修改现有 Aurora PostgreSQL 数据库集群，以使用其中一个基于 NVMe 的数据库实例类。有关更多信息，请参阅 [修改 Amazon Aurora 数据库集群](Aurora.Modifying.md)。

在支持其中一个或多个数据库实例类（具有本地 NVMe SSD 存储）的所有 Amazon Web Services 区域中，均可使用 Aurora 优化型读取功能。有关更多信息，请参阅 [Amazon Aurora数据库实例类](Concepts.DBInstanceClass.md)。

要切换回未优化读取功能的 Aurora 实例，请将 Aurora 实例的数据库实例类修改为类似的实例类，该实例类对于数据库工作负载没有 NVMe 临时存储。例如，如果当前数据库实例类是 db.r6gd.4xlarge，请选择 db.r6g.4xlarge 以切换回该实例类。有关更多信息，请参阅[修改 Aurora 数据库实例](https://docs.amazonaws.cn/AmazonRDS/latest/UserGuide/Overview.DBInstance.Modifying.html)。

## Aurora 优化型读取的使用案例
<a name="AuroraPostgreSQL.optimized.reads.usecases"></a>

**启用优化型读取的分层缓存**

以下是一些可从优化型读取分层缓存中受益的使用案例：
+ Internet 规模的应用程序，例如支付处理、计费、电子商务（具有严格的性能 SLA）。
+ 实时报告仪表板，可对指标/数据收集运行数百次单点查询。
+ 带有 pgvector 扩展的生成式人工智能应用程序，可在数百万个向量嵌入中搜索精确或最近的邻居。

**启用优化型读取的临时对象**

以下是一些可从优化型读取临时对象中受益的使用案例：
+ 包含公用表表达式（CTE）、派生表和分组操作的分析查询。
+ 用于处理应用程序的未优化型查询的只读副本。
+ 具有复杂操作（如 GROUP BY 和 ORDER BY）的按需或动态报告查询，这些操作无法始终使用适当的索引。
+ 用于排序的 `CREATE INDEX` 或 `REINDEX` 操作。
+ 使用内部临时表的其他工作负载。

## 监控使用 Aurora 优化读取的数据库实例
<a name="AuroraPostgreSQL.optimized.reads.monitoring"></a>

您可以使用 EXPLAIN 命令监控使用启用了优化型读取的分层缓存的查询，如以下示例所示：

```
Postgres=> EXPLAIN (ANALYZE, BUFFERS) SELECT c FROM sbtest15 WHERE id=100000000                   

QUERY PLAN
--------------------------------------------------------------------------------------
 Index Scan using sbtest15_pkey on sbtest15  (cost=0.57..8.59 rows=1 width=121) (actual time=0.287..0.288 rows=1 loops=1)
   Index Cond: (id = 100000000)
   Buffers: shared hit=3 read=2 aurora_orcache_hit=2
   I/O Timings: shared/local read=0.264
 Planning:
   Buffers: shared hit=33 read=6 aurora_orcache_hit=6
   I/O Timings: shared/local read=0.607
 Planning Time: 0.929 ms
 Execution Time: 0.303 ms
(9 rows)
Time: 2.028 ms
```

**注意**  
只有在优化型读取功能处于开启状态，并且解释计划的 `Buffers` 部分中 `aurora_orcache_hit` 和 `aurora_storage_read` 字段的值大于零时，才会显示这些字段。读取字段是 `aurora_orcache_hit` 和 `aurora_storage_read` 字段的总和。

您可以通过以下 CloudWatch 指标监控使用 Aurora 优化型读取功能的数据库实例：
+ `AuroraOptimizedReadsCacheHitRatio`
+ `FreeEphemeralStorage`
+ `ReadIOPSEphemeralStorage`
+ `ReadLatencyEphemeralStorage`
+ `ReadThroughputEphemeralStorage`
+ `WriteIOPSEphemeralStorage`
+ `WriteLatencyEphemeralStorage`
+ `WriteThroughputEphemeralStorage`

这些指标提供有关可用实例存储的存储空间、IOPS 和吞吐量的数据。有关这些指标的更多信息，请参阅。[Amazon Aurora 的实例级指标](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.instances)

您还可以使用此 `pg_proctab` 扩展来监控 NVMe 存储。

```
postgres=>select * from pg_diskusage();

major | minor |       devname       | reads_completed | reads_merged | sectors_read | readtime | writes_completed | writes_merged | sectors_written | writetime | current_io | iotime  | totaliotime
------+-------+---------------------+-----------------+--------------+--------------+----------+------------------+---------------+-----------------+-----------+------------+---------+-------------
      |       | rdstemp             |           23264 |            0 |       191450 |    11670 |          1750892 |             0 |        24540576 |    819350 |          0 | 3847580 |      831020
      |       | rdsephemeralstorage |           23271 |            0 |       193098 |     2620 |           114961 |             0 |        13845120 |    130770 |          0 |  215010 |      133410
(2 rows)
```

## Aurora 优化型读取的最佳实践
<a name="AuroraPostgreSQL.optimized.reads.bestpractices"></a>

对于 Aurora 优化型读取使用以下最佳实践：
+ 使用 CloudWatch 指标 `FreeEphemeralStorage` 监控实例存储上的可用存储空间。如果由于数据库实例上的工作负载导致实例存储达到其限制，请调整并发性和大量使用临时对象的查询，或者将其修改为使用更大的数据库实例类。
+ 监控 CloudWatch 指标的优化型读取缓存命中率。诸如 VACUUM 之类的操作可以非常快速地修改大量块。这可能会导致命中率暂时下降。`pg_prewarm` 扩展可用于将数据加载到缓冲区缓存中，从而允许 Aurora 主动将其中一些块写入优化型读取缓存。
+ 您可以启用集群缓存管理（CCM），在将用作故障转移目标的 Tier-0 读取器上预热缓冲区缓存和分层缓存。启用 CCM 后，会定期扫描缓冲区缓存，以便在分层缓存中写入符合驱逐条件的页面。有关 CCM 的更多信息，请参阅 [通过 Aurora PostgreSQL 的集群缓存管理提供故障转移后的快速恢复](AuroraPostgreSQL.cluster-cache-mgmt.md)。