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.
Verständnis DPUs in EXPLAIN ANALYZE
Aurora DSQL bietet Informationen zur Distributed Processing Unit (DPU) auf Anweisungsebene in der EXPLAIN ANALYZE VERBOSE Planausgabe, sodass Sie während der Entwicklung einen besseren Einblick in die Abfragekosten erhalten. In diesem Abschnitt wird erklärt, was das DPUs sind und wie sie in der Ausgabe zu interpretieren sind. EXPLAIN ANALYZE VERBOSE
Was ist eine DPU?
Eine Distributed Processing Unit (DPU) ist das normalisierte Maß für die von Aurora DSQL geleistete Arbeit. Sie besteht aus:
computedPU — Zeit, die für die Ausführung von SQL-Abfragen aufgewendet wurde
ReadDPU — Ressourcen, die zum Lesen von Daten aus dem Speicher verwendet werden
WriteDPU — Ressourcen, die zum Schreiben von Daten in den Speicher verwendet werden
MultiRegionWriteDPU — Ressourcen, die zur Replikation von Schreibvorgängen auf Peer-Cluster in Konfigurationen mit mehreren Regionen verwendet werden.
Verwendung von DPU in EXPLAIN ANALYZE VERBOSE
Aurora DSQL erweitert sich EXPLAIN ANALYZE VERBOSE um eine Schätzung der DPU-Nutzung auf Anweisungsebene bis zum Ende der Ausgabe. Dies bietet einen sofortigen Einblick in die Abfragekosten und hilft Ihnen, Workload-Kostentreiber zu identifizieren, die Abfrageleistung zu optimieren und die Ressourcennutzung besser vorherzusagen.
Die folgenden Beispiele zeigen, wie die in der EXPLAIN ANALYZE VERBOSE-Ausgabe enthaltenen DPU-Schätzungen auf Anweisungsebene interpretiert werden können.
Beispiel 1: SELECT-Abfrage
EXPLAIN ANALYZE VERBOSE SELECT * FROM test_table;
QUERY PLAN
----------------------------------------------------
Index Only Scan using test_table_pkey on public.test_table (cost=125100.05..171100.05 rows=1000000 width=36) (actual time=2.973..4.482 rows=120 loops=1)
Output: id, context
-> Storage Scan on test_table_pkey (cost=125100.05..171100.05 rows=1000000 width=36) (actual rows=120 loops=1)
Projections: id, context
-> B-Tree Scan on test_table_pkey (cost=125100.05..171100.05 rows=1000000 width=36) (actual rows=120 loops=1)
Query Identifier: qymgw1m77maoe
Planning Time: 11.415 ms
Execution Time: 4.528 ms
Statement DPU Estimate:
Compute: 0.01607 DPU
Read: 0.04312 DPU
Write: 0.00000 DPU
Total: 0.05919 DPU
In diesem Beispiel führt die SELECT-Anweisung einen reinen Index-Scan durch, sodass der Großteil der Kosten auf Read DPU (0,04312) entfällt, was die aus dem Speicher abgerufenen Daten darstellt, und Compute-DPU (0,01607), was die Rechenressourcen widerspiegelt, die für die Verarbeitung und Rückgabe der Ergebnisse verwendet werden. Es gibt keine Write-DPU, da die Abfrage keine Daten ändert. Die gesamte DPU (0,05919) ist die Summe aus Compute+Read+Write.
Beispiel 2: INSERT-Abfrage
EXPLAIN ANALYZE VERBOSE INSERT INTO test_table VALUES (1, 'name1'), (2, 'name2'), (3, 'name3');
QUERY PLAN
----------------------------------------------------
Insert on public.test_table (cost=0.00..0.04 rows=0 width=0) (actual time=0.055..0.056 rows=0 loops=1)
-> Values Scan on "*VALUES*" (cost=0.00..0.04 rows=3 width=122) (actual time=0.003..0.008 rows=3 loops=1)
Output: "*VALUES*".column1, "*VALUES*".column2
Query Identifier: jtkjkexhjotbo
Planning Time: 0.068 ms
Execution Time: 0.543 ms
Statement DPU Estimate:
Compute: 0.01550 DPU
Read: 0.00307 DPU (Transaction minimum: 0.00375)
Write: 0.01875 DPU (Transaction minimum: 0.05000)
Total: 0.03732 DPU
Diese Anweisung führt hauptsächlich Schreibvorgänge durch, sodass der Großteil der Kosten mit Write DPU verbunden ist. Die Rechen-DPU (0,01550) steht für die Arbeit, die für die Verarbeitung und das Einfügen der Werte aufgewendet wurde. Der Read DPU (0,00307) spiegelt kleinere Systemlesevorgänge wider (für Katalogsuchen oder Indexprüfungen).
Beachten Sie die Transaktions-Mindestwerte, die neben Lesen und Schreiben angezeigt werden. DPUs Diese geben die Basiskosten pro Transaktion an, die nur anfallen, wenn der Vorgang Lese- oder Schreibvorgänge umfasst. Sie bedeuten nicht, dass für jede Transaktion automatisch eine Gebühr von 0,00375 DPU beim Lesen oder 0,05 beim Schreiben anfällt. Stattdessen werden diese Mindestwerte bei der Kostenaggregation auf Transaktionsebene und nur dann angewendet, wenn Lese- oder Schreibvorgänge innerhalb dieser Transaktion erfolgen. Aufgrund dieses unterschiedlichen Umfangs stimmen Schätzungen auf Kontoauszugsebene EXPLAIN ANALYZE VERBOSE möglicherweise nicht exakt mit den in den Daten angegebenen Kennzahlen auf Transaktionsebene oder den Abrechnungsdaten überein. CloudWatch
Verwendung von DPU-Informationen zur Optimierung
DPU-Schätzungen pro Anweisung bieten Ihnen eine leistungsstarke Möglichkeit, Abfragen über die reine Ausführungszeit hinaus zu optimieren. Häufige Anwendungsfälle umfassen:
Kostenbewusstsein: Verstehen Sie, wie teuer eine Abfrage im Vergleich zu anderen ist.
Schemaoptimierung: Vergleichen Sie die Auswirkungen von Indizes oder Schemaänderungen auf Leistung und Ressourceneffizienz.
Budgetplanung: Schätzen Sie die Workload-Kosten auf der Grundlage der beobachteten DPU-Auslastung.
Abfragevergleich: Bewerten Sie alternative Abfrageansätze anhand ihres relativen DPU-Verbrauchs.
DPU-Informationen interpretieren
Beachten Sie die folgenden bewährten Methoden bei der Verwendung von DPU-Daten von: EXPLAIN ANALYZE VERBOSE
Direkter Einsatz: Verwenden Sie die gemeldete DPU als Möglichkeit, die relativen Kosten einer Abfrage zu verstehen, und nicht als exakte Übereinstimmung mit CloudWatch Kennzahlen oder Abrechnungsdaten. Abweichungen sind zu erwarten, da die Kosten auf
EXPLAIN ANALYZE VERBOSEKontoauszugsebene gemeldet werden, während die Aktivitäten auf Transaktionsebene aggregiert werden. CloudWatch CloudWatch umfasst auch Hintergrundoperationen (wie ANALYZE oder Verdichtungen) und Transaktionsaufwand (/), der bewusst ausgeschlossen wurde.BEGINCOMMITEXPLAIN ANALYZE VERBOSEDie DPU-Variabilität zwischen den Ausführungen ist in verteilten Systemen normal und weist nicht auf Fehler hin. Faktoren wie Zwischenspeicherung, Änderungen des Ausführungsplans, Parallelität oder Verschiebungen in der Datenverteilung können alle dazu führen, dass dieselbe Abfrage von einem Lauf zum nächsten unterschiedliche Ressourcen verbraucht.
Kleine Operationen stapeln: Wenn Ihr Workload viele kleine Anweisungen ausgibt, sollten Sie erwägen, diese in größeren Vorgängen zu bündeln (nicht mehr als 10 MB). Dies reduziert den Rundungsaufwand und führt zu aussagekräftigeren Kostenschätzungen.
Wird für die Feinabstimmung verwendet, nicht für die Fakturierung: Die eingehenden
EXPLAIN ANALYZE VERBOSEDPU-Daten dienen dem Kostenbewusstsein, der Abfrageoptimierung und der Optimierung. Es handelt sich nicht um eine Abrechnungskennzahl. Verlassen Sie sich immer auf CloudWatch Kennzahlen oder monatliche Abrechnungsberichte, um verlässliche Kosten- und Nutzungsdaten zu erhalten.