使用 Aurora Optimized Reads 改善 Aurora PostgreSQL 的查詢效能 - Amazon Aurora
PostgreSQL 中 Aurora Optimized Reads 的概觀使用使用案例監控最佳實務

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

使用 Aurora Optimized Reads 改善 Aurora PostgreSQL 的查詢效能

您可以使用 Aurora Optimized Reads，為 Aurora PostgreSQL 實現更快的查詢處理。使用 Aurora Optimized Reads 的 Aurora PostgreSQL 資料庫執行個體可為具有大型資料集 (超過資料庫執行個體記憶體容量) 的應用程式提供高達 8 倍的查詢延遲改進，以及高達 30% 的成本節省。

PostgreSQL 中 Aurora Optimized Reads 的概觀

當您建立使用 Graviton 型 R6gd 和 Intel 型 R6id 執行個體搭配非揮發性記憶體快速 (NVMe) 儲存體的資料庫叢集時，Aurora Optimized Reads 預設為可用。它可從以下 PostgreSQL 版本取得：

  • 16.1 及所有更高版本

  • 15.4 和更新版本

  • 14.9 和更新版本

Aurora Optimized Reads 支援兩種功能：階層式快取和暫存物件。

啟用 Optimized Reads 的階層式快取 - 使用階層式快取，您可以將資料庫執行個體快取容量擴充至執行個體記憶體的 5 倍。這會自動維護快取以包含最新的交易一致性資料，讓應用程式免於管理外部結果集型快取解決方案之資料貨幣的額外負荷。它為先前從 Aurora 儲存獲取資料的查詢提供了高達 8 倍的延遲。

在 Aurora 中，預設參數群組shared_buffers中的值通常設定為大約 75% 的可用記憶體。不過，對於 r6gd 和 r6id 執行個體類型，Aurora 會將shared_buffers空間減少 4.5%，以裝載最佳化讀取快取的中繼資料。

已啟用 Optimized Reads 的暫存物件 - 使用暫存物件，您可將 PostgreSQL 產生的暫時檔案放置在本機 NVMe 儲存體上，實現更快的查詢處理。如此可減少透過網路傳送至彈性區塊儲存 (EBS) 的流量。針對不符合資料庫執行個體可用記憶體容量的大量資料進行排序、聯結或合併的進階查詢，提供高達 2 倍的延遲和輸送量。

在 Aurora I/O 最佳化叢集上，Optimized Reads 會在 NVMe 儲存裝置上同時使用階層式快取和暫存物件。透過啟用 Optimized Reads 的階層式快取功能，Aurora 會為暫存物件分配 2 倍的執行個體記憶體、約 10% 的儲存用於內部作業，而剩餘的儲存裝置則分配為階層式快取。在 Aurora 標準叢集上，Optimized Reads 僅會使用暫存物件。

引擎 叢集儲存組態 啟用 Optimized Reads 的暫存物件 啟用 Optimized Reads 的階層式快取 支援的版本
Amazon PostgreSQL-Compatible Edition 標準 是 否 Aurora PostgreSQL 所有更高版本 15.4 及更高版本，14.9 及更高版本
I/O最佳化 是 是
注意

在 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 Optimized Reads

當您使用其中一個 NVMe 型資料庫執行個體佈建 Aurora PostgreSQL 資料庫執行個體時，資料庫執行個體會自動使用 Aurora 最佳化讀取。

若要開啟 Aurora Optimized Reads，請執行下列其中一項：

所有 AWS 區域 支援具有本機 NVMe SSD 儲存的資料庫執行個體類別或多個資料庫執行個體類別均可使用 Aurora 最佳化讀取。如需詳細資訊，請參閱 Aurora 資料庫執行個體類別。

若要切換回未最佳化讀取 Aurora 執行個體，請將 Aurora 執行個體的資料庫執行個體類別修改為類似的執行個體類別，而不需要用於資料庫工作負載的 NVMe 暫時儲存。例如，如果目前的資料庫執行個體類別是 db.r6gd.4xlarge，請選擇 db.r6g.4xlarge 以切換回來。如需詳細資訊，請參閱修改 Aurora 資料庫執行個體。

Aurora Optimized Reads 的使用案例

啟用 Optimized Reads 的階層式快取

下列是一些可從 Optimized Reads 搭配階層式快取受益的使用案例：

  • 具有嚴格效能 SLA 的網際網路規模的應用程式，例如支付處理、計費、電子商務。

  • 執行數百個點查詢以便收集指標/資料的即時報告儀表板。

  • 具有 pgvector 擴充功能的生成式 AI 應用程式可以在數百萬個向量嵌入中搜尋精確或最近的鄰居。

啟用 Optimized Reads 的暫存物件

下列是一些可從 Optimized Reads 搭配暫存物件受益的使用案例：

  • 分析查詢，包括一般資料表表達式 (CTE)、衍生資料表和群組操作。

  • 處理應用程式未最佳化查詢的僅供讀取複本。

  • 具有複雜操作的隨需或動態報告查詢 (例如 GROUP BY 和 ORDER BY)，無法始終使用適當的索引。

  • CREATE INDEX或用於排序的REINDEX操作。

  • 使用內部暫存資料表的其他工作負載

監控使用 Aurora Optimized Reads 的資料庫執行個體

您可以使用 EXPLAIN 命令監控使用啟用 Optimized Reads 之階層式快取的查詢，如以下範例所示：

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
注意

aurora_orcache_hit和說明計畫Buffers區aurora_storage_read段中的欄位只有在開啟「最佳化讀取」且其值大於零時才會顯示。讀取欄位是aurora_orcache_hit和aurora_storage_read欄位的總計。

您可以使用下列 CloudWatch指標監視使用 Aurora 最佳化讀取的資料庫執行個體：

  • AuroraOptimizedReadsCacheHitRatio

  • FreeEphemeralStorage

  • ReadIOPSEphemeralStorage

  • ReadLatencyEphemeralStorage

  • ReadThroughputEphemeralStorage

  • WriteIOPSEphemeralStorage

  • WriteLatencyEphemeralStorage

  • WriteThroughputEphemeralStorage

這些指標提供可用執行個體儲存體、IOPS 和輸送量的相關資料。如需這些指標的詳細資訊，請參閱 Amazon Aurora 的執行個體層級指標。

您也可以使用 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 Optimized Reads 的最佳實務

請使用 Aurora Optimized Reads 的下列最佳實務：

  • 使用 CloudWatch 指標監視執行個體存放區上的可用儲存空間FreeEphemeralStorage。如果執行個體存放區因為資料庫執行個體上的工作負載而達到限制，請調整大量使用暫存物件的並行和查詢，或修改它以使用較大的資料庫執行個體類別。

  • 監 CloudWatch 視「最佳化讀取」快取命中率的測量結果。像 VACUUM 這樣的操作可以非常快速地修改大量區塊。這可能會造成命中率暫時下降。pg_prewarm 擴充功能可用來將資料載入緩衝區快取，讓 Aurora 主動將其中一些區塊寫入 Optimized Reads 快取。

  • 您可以啟用叢集快取管理 (CCM)，預熱第 0 層讀取器上的緩衝區快取和階層式快取，這將用作容錯移轉目標。啟用 CCM 時，會定期掃描緩衝區快取，以便在階層式快取中寫入符合移出資格的頁面。如需 CCM 的詳細資訊，請參閱 Aurora PostgreSQL 的容錯移轉後使用叢集快取管理快速復原。