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 PostgreSQL mit Aurora-optimierten Lesevorgängen Mit Aurora-optimierten Lesevorgängen können Sie eine schnellere Abfrageverarbeitung mit Aurora PostgreSQL erreichen. Eine Aurora-PostgreSQL-DB-Instance, die Aurora-optimierte Lesevorgänge 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. **Topics** + [Übersicht über Aurora-optimierte Lesevorgänge in PostgreSQL](#AuroraPostgreSQL.optimized.reads.overview) + [Verwenden von Aurora-optimierten Lesevorgängen](#AuroraPostgreSQL.optimized.reads.using) + [Anwendungsfälle für Aurora-optimierte Lesevorgänge](#AuroraPostgreSQL.optimized.reads.usecases) + [Überwachen von DB-Instances, die Aurora-optimierte Lesevorgänge verwenden](#AuroraPostgreSQL.optimized.reads.monitoring) + [Bewährte Methoden für Aurora-optimierte Lesevorgänge](#AuroraPostgreSQL.optimized.reads.bestpractices) ## Übersicht über Aurora-optimierte Lesevorgänge in PostgreSQL Aurora Optimized Reads ist standardmäßig verfügbar, wenn Sie einen DB-Cluster erstellen, der R6gd-, Graviton-based R8gd- und Intel-based R6id-Instances mit NVMe-Speicher (Non-Volatile Memory Express) verwendet. Dies ist in den folgenden Versionen von PostgreSQL verfügbar: + 14.12 und höhere Versionen, 15.7 und höhere Versionen, 16.3 und höhere Versionen, 17.4 und höhere Versionen für R8gd-Instances + 14.9 und höhere Versionen, 15.4 und höhere Versionen, 16.1 und alle höheren Versionen für R6gd- und R6id-Instances Aurora-optimierte Lesevorgänge unterstützen zwei Funktionen: mehrstufigen Cache und temporäre Objekte. ** Reads-enabled Optimierter Tiered Cache — Mit Tiered Cache** 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 Standard-Parametergruppe normalerweise auf etwa 75 % des verfügbaren Speichers festgelegt. Für die Instance-Typen r8gd, r6gd und r6id reduziert Aurora den `shared_buffers` Speicherplatz jedoch um 4,5%, um die Metadaten für den Optimized Reads-Cache zu hosten. **Optimierte Reads-enabled temporäre Objekte** — Mithilfe temporärer Objekte können Sie eine schnellere Abfrageverarbeitung erreichen, indem Sie die von PostgreSQL generierten temporären Dateien im lokalen NVMe-Speicher platzieren. Dadurch wird der Datenverkehr zu Elastic Block Storage (EBS) über das Netzwerk reduziert. Dies bietet eine bis zu zweimal bessere Latenz und einen besseren Durchsatz für erweiterte Abfragen, bei denen große Datenmengen sortiert, verbunden oder zusammengeführt werden, die nicht in die auf einer DB-Instance verfügbare Speicherkapazität passen. Auf einem I/O-Optimized Aurora-Cluster verwendet Optimized Reads sowohl den mehrstufigen Cache als auch temporäre Objekte im NVMe-Speicher. Mit der optimierten Reads-enabled mehrstufigen Cache-Funktion weist Aurora den doppelten Instanzspeicher 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. Mit I/O-Optimized Aurora-Clustern können Sie die Größe des zugewiesenen Speicherplatzes für optimierte Reads-enabled temporäre Objekte mithilfe des dynamischen Parameters `aurora_temp_space_size` auf Instanzebene ändern. Diese Größenanpassungsfunktion ist in den folgenden PostgreSQL-Versionen verfügbar: + 16.8 und alle höheren Versionen + 15.12 und höhere 15-Versionen + 14.17 und höhere 14-Versionen Mit diesem Parameter können Sie die Kapazität vom Zweifachen des Instanzspeichers auf bis zu 90% der gesamten NVMe-Speicherkapazität der Instanz skalieren, ohne dass die Datenbank-Engine neu gestartet werden muss. Wenn Sie den Speicherplatz für temporäre Objekte erweitern, wird die Änderung sofort wirksam, unabhängig von gleichzeitigen Workloads. Wenn Sie den Speicherplatz reduzieren, wird die Anpassung jedoch erst abgeschlossen, wenn in den temporären Objekten genügend ungenutzter Speicherplatz für die neue Größenanforderung vorhanden ist. Nachdem Sie die Größe optimierter Reads-enabled temporärer Objekte geändert haben, passt sich der mehrstufige Cache automatisch an, sodass er den verfügbaren Speicherplatz belegt. - ** PostgreSQL-Compatible Aurora-Ausgabe** - **Cluster-Speicherkonfiguration:** Standard / **Optimierte temporäre Objekte Reads-enabled:** Ja / **Optimierter Reads-enabled mehrstufiger Cache:** Nein - **Cluster-Speicherkonfiguration:** I/O-Optimized / **Optimierte temporäre Objekte Reads-enabled:** Ja / **Optimierter Reads-enabled mehrstufiger Cache:** Ja - **Unterstützte Versionen:** [See the AWS documentation website for more details](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.optimized.reads.html) **Anmerkung** Ein Wechsel zwischen IO-Optimized und Standard-Clustern in einer NVMe-based DB-Instance-Klasse führt zu einem sofortigen Neustart der Datenbank-Engine. Verwenden Sie in Aurora PostgreSQL den `temp_tablespaces`-Parameter zur Konfiguration des Tabellenbereichs, 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) ``` Der `aurora_temp_tablespace` ist ein von Aurora konfigurierter Tabellenbereich, der auf den lokalen NVMe-Speicher verweist. Sie können diesen Parameter nicht ändern oder zum Amazon-EBS-Speicher zurückkehren. 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 PostgreSQL-DB-Instance mit einer der DB-Instances bereitstellen, verwendet die DB-Instance automatisch Aurora Optimized Reads. NVMe-based Führen Sie einen der folgenden Schritte aus, um Aurora-optimierte Lesevorgänge zu aktivieren: + Erstellen Sie einen Aurora PostgreSQL-DB-Cluster mithilfe einer der NVMe-based DB-Instance-Klassen. Weitere Informationen finden Sie unter [Erstellen eines Amazon Aurora-DB Clusters](Aurora.CreateInstance.md). + Ändern Sie einen vorhandenen Aurora PostgreSQL-DB-Cluster so, dass er eine der NVMe-based DB-Instance-Klassen verwendet. Weitere Informationen finden Sie unter [Ändern eines Amazon Aurora-DB-Clusters](Aurora.Modifying.md). Aurora Optimized Reads ist überall verfügbar AWS-Regionen , wo eine oder mehrere DB-Instance-Klassen mit lokalem NVMe-SSD-Speicher unterstützt werden. Weitere Informationen finden Sie unter [Amazon AuroraDB-Instance-Klassen](Concepts.DBInstanceClass.md). Um zu einer Aurora-Instance ohne optimierte Lesevorgänge zurückzukehren, ändern Sie die DB-Instance-Klasse Ihrer Aurora-Instance in eine ähnliche Instance-Klasse ohne flüchtigen NVMe-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](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.DBInstance.Modifying.html). ## Anwendungsfälle für Aurora-optimierte Lesevorgänge **Optimierter Reads-enabled mehrstufiger Cache** Im Folgenden sind einige Anwendungsfälle aufgeführt, für die optimierte Lesevorgänge mit gestuftem Cache von Vorteil sein können: + Internetanwendungen wie Zahlungsabwicklung, Rechnungsstellung und E-Commerce mit strengen Leistungs-SLAs. + Real-time Berichts-Dashboards, die Hunderte von Punktabfragen zur metrics/data Erfassung ausführen. + Generative KI-Anwendungen mit der Erweiterung pgvector zur Suche nach exakten oder nächstgelegenen Nachbarn in Millionen von Vektoreinbettungen. **Optimierte Reads-enabled temporäre Objekte** Im Folgenden sind einige Anwendungsfälle aufgeführt, für die optimierte Lesevorgänge von Vorteil sein können: + Analytische Abfragen mit Common Table Expressions (CTEs), abgeleiteten Tabellen und Gruppierungsoperationen. + Lesereplikate, die die nicht optimierten Abfragen für eine Anwendung verarbeiten. + On-demand oder dynamische Berichtsabfragen mit komplexen Vorgängen wie GROUP BY und ORDER BY, die nicht immer geeignete Indizes verwenden können. + `CREATE INDEX`- oder `REINDEX`-Operationen zum Sortieren + Andere Workloads, die interne temporäre Tabellen verwenden. ## Überwachen von DB-Instances, die Aurora-optimierte Lesevorgänge verwenden Sie können Ihre Abfragen, die den optimierten Reads-enabled mehrstufigen Cache verwenden, mit dem Befehl EXPLAIN ü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 ``` **Anmerkung** Die Felder `aurora_orcache_hit` und `aurora_storage_read` im `Buffers`-Abschnitt des Erklärungsplans werden nur angezeigt, wenn optimierte Lesevorgänge aktiviert und ihre Werte größer als Null sind. Das read-Feld ist die Summe der Felder `aurora_orcache_hit` und `aurora_storage_read`. Sie können DB-Instances, die Aurora Optimized Reads verwenden, anhand der folgenden CloudWatch Metriken überwachen: + `AuroraOptimizedReadsCacheHitRatio` + `FreeEphemeralStorage` + `ReadIOPSEphemeralStorage` + `ReadLatencyEphemeralStorage` + `ReadThroughputEphemeralStorage` + `WriteIOPSEphemeralStorage` + `WriteLatencyEphemeralStorage` + `WriteThroughputEphemeralStorage` Diese Metriken liefern Daten über den verfügbaren Instance-Speicher, die IOPS und den Durchsatz. Weitere Informationen zu diesen Metriken finden Sie unter [Instance-level Metriken für Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.instances). Sie können die `pg_proctab`-Erweiterung auch zum Überwachen des NVMe-Speichers 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: + Überwachen Sie den im Instance-Speicher verfügbaren Speicherplatz anhand der CloudWatch Metrik`FreeEphemeralStorage`. Wenn der Instance-Speicher aufgrund des Workloads der DB-Instance sein Limit erreicht, stellen Sie die Gleichzeitigkeit und die Abfragen ein, die intensiven Gebrauch von temporären Objekten machen, oder ändern Sie die Instance so, dass sie eine größere DB-Instance-Klasse verwendet. + Überwachen Sie die CloudWatch Metrik im Hinblick auf die Cache-Trefferquote für optimierte Lesevorgänge. Operationen wie VACUUM ändern sehr schnell eine große Anzahl von Blöcken. Dies kann zu einem vorübergehenden Rückgang der Trefferrate führen. Die `pg_prewarm`-Erweiterung kann verwendet werden, um Daten in den Puffer-Cache zu laden, so dass Aurora einige dieser Blöcke proaktiv in den Cache der optimierten Lesevorgänge schreiben kann. + Sie können das Cluster-Cache-Management (CCM) aktivieren, um den Puffer-Cache und den mehrstufigen Cache auf einem Tier-0-Reader aufzuwärmen, der als Failover-Ziel verwendet wird. Wenn CCM aktiviert ist, wird der Puffer-Cache regelmäßig gescannt, um Seiten, die bereinigt werden können, in den mehrstufigen Cache zu schreiben. Weitere Informationen zu CCM finden Sie unter [Schnelle Wiederherstellung nach Failover mit der Cluster-Cacheverwaltung für Aurora PostgreSQL](AuroraPostgreSQL.cluster-cache-mgmt.md).