Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Verbesserung der Abfrageleistung für Aurora Postgre SQL mit Aurora Optimized Reads

Mit Aurora Optimized Reads können Sie eine schnellere Abfrageverarbeitung für Aurora Postgre SQL erreichen. Eine Aurora SQL Postgre-DB-Instance, die Aurora Optimized Reads verwendet, bietet eine bis zu achtmal verbesserte Abfragelatenz und bis zu 30% Kosteneinsparungen für Anwendungen mit großen Datensätzen, die die Speicherkapazität einer DB-Instance überschreiten.

Überblick über Aurora Optimized Reads in Postgre SQL

Aurora Optimized Reads ist standardmäßig verfügbar, wenn Sie einen DB-Cluster erstellen, der Graviton-basierte R6GD- und Intel-basierte R6ID-Instances mit nichtflüchtigem Memory-Express () -Speicher verwendet. NVMe Es ist in den folgenden Postgre-Versionen verfügbar: SQL

Aurora-optimierte Lesevorgänge unterstützen zwei Funktionen: mehrstufigen Cache und temporäre Objekte.

Mehrstufiger Cache mit optimierten Lesevorgängen – Mithilfe eines mehrstufigen Caches können Sie die Caching-Kapazität Ihrer DB-Instance um das bis zu Fünffache des Instance-Speichers erweitern. Dadurch wird der Cache automatisch so verwaltet, dass er die aktuellsten, transaktionskonsistenten Daten enthält. Dadurch entfällt für Anwendungen der Aufwand, die Datenaktualität externer, auf Ergebnismengen basierender Caching-Lösungen zu verwalten. Dies bietet eine bis zu achtmal bessere Latenz für Abfragen, bei denen zuvor Daten aus dem Aurora-Speicher abgerufen wurden.

In Aurora ist der Wert für shared_buffers in der Standardparametergruppe normalerweise auf etwa 75% des verfügbaren Speichers festgelegt. Für die Instance-Typen r6gd und r6id reduziert Aurora den shared_buffers Speicherplatz jedoch um 4,5%, um die Metadaten für den Optimized Reads-Cache zu hosten.

Für optimierte Lesevorgänge aktivierte temporäre Objekte — Mithilfe temporärer Objekte können Sie eine schnellere Abfrageverarbeitung erreichen, indem Sie die von Postgre generierten temporären Dateien im lokalen Speicher ablegen. SQL NVMe Dadurch wird der Datenverkehr zu Elastic Block Storage (EBS) über das Netzwerk reduziert. Es bietet eine bis zu zweimal bessere Latenz und einen besseren Durchsatz für erweiterte Abfragen, bei denen große Datenmengen sortiert, zusammengeführt oder zusammengeführt werden, die nicht in die auf einer DB-Instance verfügbare Speicherkapazität passen.

In einem I/O-optimierten Aurora-Cluster verwendet Optimized Reads sowohl den mehrstufigen Cache als auch temporäre Objekte im Speicher. NVMe Mit der für optimierte Lesevorgänge aktivierten mehrstufigen Cache-Funktion weist Aurora den doppelten Instance-Speicher für temporäre Objekte zu, etwa 10 % des Speichers für interne Operationen und den verbleibenden Speicher als mehrstufigen Cache. In einem Aurora-Standard-Cluster verwenden optimierte Lesevorgänge nur temporäre Objekte.

Verwenden Sie in Aurora Postgre den temp_tablespaces ParameterSQL, um den Tablespace zu konfigurieren, in dem die temporären Objekte gespeichert werden.

Verwenden Sie den folgenden Befehl, um zu überprüfen, ob die temporären Objekte konfiguriert sind:

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

Das aurora_temp_tablespace ist ein von Aurora konfigurierter Tablespace, der auf den NVMe lokalen Speicher verweist. Sie können diesen Parameter nicht ändern oder zurück zum EBS Amazon-Speicher wechseln.

Verwenden Sie den folgenden Befehl, um zu überprüfen, ob der Cache der optimierten Lesevorgänge aktiviert ist:

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

Verwenden von Aurora-optimierten Lesevorgängen

Wenn Sie eine Aurora SQL Postgre-DB-Instance mit einer der NVMe basierten DB-Instances bereitstellen, verwendet die DB-Instance automatisch Aurora Optimized Reads.

Führen Sie einen der folgenden Schritte aus, um Aurora-optimierte Lesevorgänge zu aktivieren:

Aurora Optimized Reads ist in allen verfügbar AWS-Regionen wo eine oder mehrere der DB-Instance-Klassen mit lokalem NVMe SSD Speicher unterstützt werden. Weitere Informationen finden Sie unter Amazon Aurora Aurora-DB-Instance-Klassen.

Um zurück zu einer Aurora-Instance mit nicht optimierten Lesevorgängen zu wechseln, ändern Sie die DB-Instance-Klasse Ihrer Aurora-Instance auf eine ähnliche Instance-Klasse ohne NVMe kurzlebigen Speicher für Ihre Datenbank-Workloads. Wenn die aktuelle DB-Instance-Klasse beispielsweise db.r6gd.4xlarge ist, wählen Sie db.r6g.4xlarge aus, um zurückzuwechseln. Weitere Informationen finden Sie unter Ändern einer Amazon-DB-Instance.

Anwendungsfälle für Aurora-optimierte Lesevorgänge

Optimierter mehrstufiger Cache mit optimierten Lesevorgängen

Im Folgenden sind einige Anwendungsfälle aufgeführt, für die optimierte Lesevorgänge mit gestuftem Cache von Vorteil sein können:

Temporäre Objekte mit optimierten Lesevorgängen

Im Folgenden sind einige Anwendungsfälle aufgeführt, für die optimierte Lesevorgänge von Vorteil sein können:

Überwachen von DB-Instances, die Aurora-optimierte Lesevorgänge verwenden

Sie können Ihre Abfragen, die den mehrstufigen Cache mit aktiviertem Optimized Reads verwenden, mit dem EXPLAIN Befehl überwachen, wie im folgenden Beispiel gezeigt:

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
            
        

Sie können DB-Instances, die Aurora Optimized Reads verwenden, anhand der folgenden CloudWatch Metriken überwachen:

Diese Metriken liefern Daten über verfügbaren Instance-SpeicherIOPS, Speicherplatz und Durchsatz. Weitere Informationen zu diesen Metriken finden Sie unter Metriken auf Instance-Ebene für Amazon Aurora.

Sie können die pg_proctab Erweiterung auch zur NVMe Speicherüberwachung verwenden.

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)    

Bewährte Methoden für Aurora-optimierte Lesevorgänge

Nutzen Sie die folgenden bewährten Methoden für Aurora-optimierte Lesevorgänge: