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.
So funktioniert die Abrechnung in Aurora DSQL
Mit Amazon Aurora DSQL zahlen Sie nur für das, was Sie nutzen, ohne Vorabkosten. In diesem Abschnitt wird erklärt, wie Aurora DSQL Ihre Datenbankaktivitäten misst und diese in Gebühren auf Ihrer Rechnung umrechnet. AWS Aktuelle Preise nach Regionen finden Sie auf der Aurora DSQL-Preisseite.
Topics
So funktioniert die Messung
Im Gegensatz zu herkömmlichen Datenbanken, bei denen die bereitgestellte Kapazität in Rechnung gestellt wird, berechnet Aurora DSQL nur Gebühren für die tatsächlich geleistete Arbeit. Aurora DSQL misst zwei Hauptkomponenten: Datenbankaktivität, gemessen in Distributed Processing Units (DPUs), und Speicher, gemessen in. GiB-month
DPUs messen, wie viel Arbeit das System zur Ausführung Ihrer SQL-Arbeitslast leistet. Bei Clustern mit einer Region bestehen sie aus drei Komponenten: Compute-DPUs, Read-DPUs und Write-DPUs. Multi-Region Cluster enthalten eine zusätzliche Write-DPU-Komponente. MultiRegion Weitere Informationen zur Abrechnung finden Sie unter Multi-Region Multi-Region Abrechnung. Bei Clustern, bei denen Change Data Capture (CDC) aktiviert ist, ist eine zusätzliche Stream-DPU-Komponente erforderlich. Weitere Informationen zur CDC-Abrechnung finden Sie unter Stream DPU. Streamen Sie DPU
Die folgende Tabelle fasst die Komponenten zusammen, die Aurora DSQL zur Messung Ihrer Datenbankaktivität verwendet. Auf Ihrer Rechnung sehen Sie nur zwei Einzelposten: einen für Speicher und einen für DPU, was der Summe der einzelnen Komponenten entspricht.
| Messeinheit | Aktivitätstyp | Messung |
|---|---|---|
| DPU berechnen | Verarbeitung von Abfragen | CPU-Zeit |
| DPU lesen | Lesen Sie Daten aus Ihrer Datenbank | Aus dem Speicher gelesene Bytes |
| DPU schreiben | Schreiben Sie Daten in Ihre Datenbank | In den Speicher geschriebene Bytes |
| DPU streamen | CDC-Streaming (wenn aktiviert) | Gestreamte Byte |
| Speicher | Speicherung von Tabellen | GiB-month |
DPU-Komponentenmessung erklärt
Für jede Transaktion berechnet Aurora DSQL die gesamte DPU als Summe der drei Komponenten: Compute DPU, Read DPU und Write DPU. In den folgenden Abschnitten wird erklärt, wie Aurora DSQL jede Komponente misst.
Total DPU = ComputeDPU + ReadDPU + WriteDPU
Berechnete PU
Rechen-DPUs werden anhand der gesamten Verarbeitungszeit gemessen, die für die Ausführung Ihrer Abfrage aufgewendet wurde, einschließlich Verknüpfungen, Funktionen, Aggregationen, Sortierung und Abfrageplanung. Da Teile Ihrer Abfrage parallel verarbeitet werden können, spiegelt die Compute-DPU die Summe der gesamten Verarbeitungszeit wider — nicht die Wanduhrzeit der Abfrage.
Die folgende Formel fasst zusammen, wie Compute-DPUs berechnet werden:
ComputeDPU = Total Compute time (in seconds)
Schreiben Sie DPU
Für jede Transaktion misst Aurora DSQL die Write-DPUs anhand der Gesamtzahl der in den Speicher geschriebenen Byte. Write-DPUs enthalten die Gesamtdaten, die in Ihre Basistabelle geschrieben wurden, sowie alle sekundären Indizes. Aurora DSQL rechnet jede Zeile, die in Ihre Basistabelle geschrieben wird, und sekundäre Indizes, die kleiner als 128 Byte sind, so ab, als ob sie 128 Byte wären. Aurora DSQL stellt eine Schreibtransaktion, die weniger als 1.024 Byte schreibt, in Rechnung, als ob 1.024 Byte geschrieben würden.
Anmerkung
Bei Schreibvorgängen fallen auch ReadDPU-Gebühren an, da Aurora DSQL den Primärschlüsselindex liest, um die Eindeutigkeit vor dem Schreiben zu überprüfen.
Die folgenden Formeln zeigen die Schritte zur Berechnung von Write-DPUs:
Schritt 1: Berechne die geschriebenen Bytes
Bytes Written = Sum of max(size of each row, 128 bytes) for all rows written
Schritt 2: WritedPU berechnen
WriteDPU = max(Bytes Written, 1024) × 0.00004883
Lesen Sie DPU
Für jede Transaktion misst Aurora DSQL Read DPUs anhand der Gesamtzahl der aus dem Speicher gelesenen Byte. Lese-DPUs enthalten Daten, die aus Ihrer Basistabelle gelesen wurden, sowie alle sekundären Indizes.
Per-partition Minimum: Aurora DSQL misst die gelesenen Byte pro Speicherpartition, nicht pro Zeile. Wenn eine Leseanforderung an eine Speicherpartition weniger als 128 Byte zurückgibt, rundet Aurora DSQL sie auf 128 Byte auf. Wenn Ihre Abfrage beispielsweise von 4 Partitionen liest — 200 Byte von einer Partition und 50 Byte von jeder der anderen drei —, werden die drei 50-Byte-Lesevorgänge jeweils auf 128 Byte aufgerundet, sodass insgesamt 200 + 128 + 128 + 128 = 584 Byte in Rechnung gestellt werden.
Mindestanzahl an Transaktionen: Aurora DSQL berechnet eine Lesetransaktion, die insgesamt weniger als 2.048 Byte liest, als ob 2.048 Byte gelesen würden.
Die folgenden Formeln zeigen die Schritte zur Berechnung von Read-DPUs:
Schritt 1: Gelesene Bytes berechnen
Bytes Read = # of rows read × size of each row
Anmerkung
Die tatsächlich gelesenen Byte hängen davon ab, wie Ihre Daten auf die Speicherpartitionen verteilt sind, da das Minimum von 128 Byte pro Partition pro Partition pro Partition angewendet wird. Wenn alle Ihre Zeilengrößen über 128 Byte liegen, können Sie die Anzahl der gelesenen Zeilen einfach mit der Größe jeder Zeile multiplizieren.
Schritt 2: ReadDPU berechnen
ReadDPU = max(Bytes Read, 2048) × 0.00000183105
Streamen Sie DPU
Stream-DPUs gelten nur, wenn Sie Change Data Capture (CDC) in Ihrem Cluster aktivieren. Aurora DSQL misst Stream-DPUs anhand der Gesamtzahl der Byte, die zu Ihrem Amazon Kinesis Data Streams-Zielstream gestreamt werden. Wenn keine Änderungen am Stream vorgenommen werden, fallen für Sie keine Stream-DPU-Gebühren an.
Die folgende Formel zeigt, wie Stream-DPUs berechnet werden:
StreamDPU = Bytes Streamed × 0.0000023283
Aurora DSQL rechnet Stream-DPUs mit der gleichen Rate ab wie alle anderen DPU-Komponenten. Weitere Informationen zu CDC-Streams finden Sie unter. Datenerfassungsstreams ändern
Abrechnungsbeispiel
Die folgenden Beispiele zeigen, wie Aurora DSQL DPUs für gängige Operationen berechnet. Die Kostenwerte in diesen Beispielen verwenden den Preis der Region US-East-1. Preise in anderen Regionen finden Sie auf der Aurora DSQL-Preisseite.
Dieses Beispiel zeigt eine ReadDPU-Berechnung für die Punktsuche, bei der das Transaktionsminimum gilt.
Schema:
CREATE TABLE orders ( id UUID PRIMARY KEY DEFAULT gen_random_uuid(), customer_id VARCHAR(50) NOT NULL, order_date TIMESTAMP DEFAULT CURRENT_TIMESTAMP, total_amount DECIMAL(10,2), status VARCHAR(20) ); -- Average row size: ~100 bytes
Abfrage:
SELECT * FROM orders WHERE customer_id = 'cust-12345';
Szenario: Die Abfrage gibt 5 Zeilen mit jeweils etwa 100 Byte zurück. Unter der Annahme, dass sich alle Zeilen in einer Speicherpartition befinden, beträgt die Gesamtzahl der gelesenen Byte 5 × 100 = 500 Byte. Da 500 Byte das Minimum von 128 Byte pro Partition überschreiten, gilt kein Minimum pro Partition.
ReadDpu berechnen:
ReadDPU = max(500, 2048) × 0.00000183105 = 2048 × 0.00000183105 = 0.00375
Das Transaktionsminimum von 2.048 Byte gilt seit 500 < 2.048.
Gesamtkosten der Transaktion:
Unter der Annahme einer Abfrageausführungszeit von 3 ms (0,003 Sekunden):
ComputeDPU: 0.003 ReadDPU: 0.00375 WriteDPU: 0.0 ------------------- Total DPU: 0.00675
Schema:
CREATE TABLE orders ( id UUID PRIMARY KEY DEFAULT gen_random_uuid(), customer_id VARCHAR(50) NOT NULL, order_date TIMESTAMP DEFAULT CURRENT_TIMESTAMP, total_amount DECIMAL(10,2), status VARCHAR(20) ); -- Average row size: ~100 bytes -- Table contains 100 orders for customer 'cust-12345'
Abfrage:
SELECT * FROM orders WHERE customer_id = 'cust-12345' AND total_amount > 500.00;
Szenario: Die Abfrage durchsucht 100 Zeilen nach dem Kunden 'cust-12345', aber der total_amount > 500.00 Filter reduziert das Ergebnis auf nur 10 zurückgegebene Zeilen. Aurora DSQL stellt alle 100 gescannten Zeilen in Rechnung. Unter der Annahme, dass sich alle Zeilen in einer Speicherpartition befinden, beträgt die Gesamtzahl der gelesenen Byte 100 × 100 = 10.000 Byte.
ReadDPU berechnen:
ReadDPU = max(10000, 2048) × 0.00000183105 = 10000 × 0.00000183105 = 0.01831
Da 10.000 Byte das Transaktionsminimum von 2.048 Byte überschreiten, werden die tatsächlich gelesenen Byte verwendet.
Gesamtkosten der Transaktion:
Unter der Annahme einer Abfrageausführungszeit von 8 ms (0,008 Sekunden):
ComputeDPU: 0.008 ReadDPU: 0.01831 WriteDPU: 0.0 ------------------- Total DPU: 0.02631
Wichtig
Um die ReadDPU-Kosten zu minimieren, entwerfen Sie Abfragen und Indizes so, dass nur die Zeilen gescannt werden, die Sie benötigen. In diesem Beispiel (customer_id, total_amount) könnte das Hinzufügen eines Indexes dazu führen, dass die Abfrage weniger Zeilen durchsucht.
Schema:
CREATE TABLE orders ( id UUID PRIMARY KEY DEFAULT gen_random_uuid(), customer_id VARCHAR(50) NOT NULL, order_date TIMESTAMP DEFAULT CURRENT_TIMESTAMP, total_amount DECIMAL(10,2), status VARCHAR(20) ); -- Average row size: ~100 bytes
Abfrage:
INSERT INTO orders (customer_id, total_amount, status) VALUES ('cust-67890', 150.00, 'pending');
Szenario: Fügen Sie eine Zeile ein, ungefähr 100 Byte.
WritedPU-Berechnung:
Schritt 1 — Berechne die geschriebenen Bytes:
1 row × max(100 bytes, 128 bytes) = 1 × 128 = 128 bytes
Schritt 2 — WritedPU berechnen:
WriteDPU = max(128, 1024) × 0.00004883 = 1024 × 0.00004883 = 0.05
Das Transaktionsminimum von 1.024 Byte gilt, da 128 < 1.024 Byte sind.
ReadDPU (Überprüfung des Primärschlüssels):
Aurora DSQL liest den Primärschlüsselindex, um die Eindeutigkeit vor dem Schreiben zu überprüfen. Dadurch fällt die Mindestlesegebühr für die Transaktion an.
ReadDPU = 0.00375 (transaction minimum)
Gesamtkosten der Transaktion:
Unter der Annahme einer Abfrageausführungszeit von 8 ms (0,008 Sekunden):
ComputeDPU: 0.008 ReadDPU: 0.00375 WriteDPU: 0.05 ------------------- Total DPU: 0.06175
Schema:
CREATE TABLE orders ( id UUID PRIMARY KEY DEFAULT gen_random_uuid(), customer_id VARCHAR(50) NOT NULL, order_date TIMESTAMP DEFAULT CURRENT_TIMESTAMP, total_amount DECIMAL(10,2), status VARCHAR(20) ); -- Average row size: ~100 bytes
Abfrage:
INSERT INTO orders (customer_id, total_amount, status) VALUES ('cust-001', 100.00, 'pending'), ('cust-002', 150.00, 'pending'), ... -- 100 rows total ('cust-100', 200.00, 'pending');
Szenario: Fügen Sie 100 Zeilen mit jeweils etwa 100 Byte ein.
WritedPU-Berechnung:
Schritt 1 — Berechne die geschriebenen Bytes:
100 rows × max(100 bytes, 128 bytes) = 100 × 128 = 12,800 bytes
Schritt 2 — WritedPU berechnen:
WriteDPU = max(12800, 1024) × 0.00004883 = 12800 × 0.00004883 = 0.625
ReadDPU (Primärschlüsselprüfungen):
Aurora DSQL liest den Primärschlüsselindex für jede Zeile, um die Eindeutigkeit zu überprüfen. Unter der Annahme, dass sich alle 100 Schlüsselsuchvorgänge in einer Speicherpartition befinden, beträgt die Gesamtzahl der gelesenen Byte 100 × 16 Byte (UUID) = 1.600 Byte:
ReadDPU = max(1600, 2048) × 0.00000183105 = 2048 × 0.00000183105 = 0.00375
Das Transaktionsminimum von 2.048 Byte gilt, da 1.600 < 2.048 Byte sind.
Gesamtkosten der Transaktion:
Unter der Annahme einer Abfrageausführungszeit von 80 ms (0,08 Sekunden):
ComputeDPU: 0.08 ReadDPU: 0.00375 WriteDPU: 0.625 ------------------- Total DPU: 0.70875
Multi-Region Abrechnung
Multi-Region Für Cluster ist zusätzlich zu den standardmäßigen Compute-, Read- und MultiRegion Write-DPUs eine zusätzliche Write-DPU-Komponente erforderlich. Dieser Abschnitt gilt nur für Cluster mit mehreren Regionen. Single-Region Für Cluster fällt diese Gebühr nicht an.
Multi-Region Schreib-DPUs messen die Gesamtzahl der Byte, die in die Peering-Region geschrieben wurden. Aurora DSQL berechnet diese DPU in der Region, aus der der Schreibvorgang stammt, nicht in der Peering-Region. In einer Konfiguration mit zwei aktiven Regionen und Witness-Peering berechnet Aurora DSQL beispielsweise für jede aktive Peering-Region den Schreib-DPU der ursprünglichen Transaktion bei der Berechnung des. MultiRegionWriteDPU Das bedeutet, dass für eine Transaktion, für die 8 anfallen, weitere 8 für diese Konfiguration WriteDPU anfallen. MultiRegionWriteDPU Das sind 8 für die ursprüngliche Region, 8 für die Peer-Region, und für die Zeugen-Region fallen keine Gebühren an. Aurora DSQL stellt alle Gebühren der Region in Rechnung, von der die Transaktion ausgegangen ist.
Für alle Cluster in der Konfiguration mit mehreren Regionen fallen Gebühren für die Speichergröße an. Da Aurora DSQL die Daten, die Sie schreiben, synchron in die Peering-Region repliziert, gilt die Gebühr für die Speichergröße für alle Cluster in der Konfiguration mit mehreren Regionen einzeln. Dies gilt auch für Cluster im Status Ausstehender Löschvorgang. Weitere Informationen zum Status Pending Delete finden Sie auf der Aurora DSQL-Cluster-Lifecycle-Seite.
MultiRegionWriteDPU = WriteDPU
Überwachung der DPU-Nutzung mit CloudWatch
Aurora DSQL veröffentlicht Nutzungsmetriken bei Amazon CloudWatch, sodass Sie den Verbrauch nahezu in Echtzeit überwachen können.
Verfügbare DPU-Metriken
| CloudWatch Metrik | Description | Dimension |
|---|---|---|
WriteDPU |
Nutzungskomponente schreiben | ClusterId |
ReadDPU |
Nutzungskomponente lesen | ClusterId |
ComputeDPU |
Komponente zur Verarbeitung von Abfragen | ClusterId |
MultiRegionWriteDPU |
Multi-Region Replikation (nur Cluster mit mehreren Regionen) | ClusterId |
StreamDPU |
CDC-Streaming (nur Cluster mit aktiviertem CDC) | ClusterId, StreamId |
TotalDPU |
Summe aller DPU-Komponenten | ClusterId |
DPU-Metriken anzeigen
Um DPU-Metriken anzuzeigen in CloudWatch
-
Öffnen Sie die CloudWatch-Konsole
. -
Navigieren Sie zu Metrics, dann zu AuroradSQL und dann. ClusterId
-
Wählen Sie Ihren Cluster und die DPU-Metriken aus, die Sie überwachen möchten.
Tipp
Verwenden Sie die Summenstatistik für DPU-Metriken, um die Gesamtnutzung über einen bestimmten Zeitraum zu ermitteln. Fügen Sie das LAST-Etikett hinzu, um den neuesten Wert anzuzeigen.
Zusätzliche Messwerte zur Beobachtbarkeit
Eine vollständige Liste der Aurora DSQL-Metriken und Überwachungsfunktionen finden Sie unter. Überwachung und Protokollierung für Aurora DSQL
| Metrik | Description |
|---|---|
ClusterStorageSize |
Aktuelle Speichergröße in Byte |
TotalTransactions |
Gesamtzahl der ausgeführten Transaktionen |
ReadOnlyTransactions |
Read-only ausgeführte Transaktionen |
QueryTimeouts |
Abfragen, die das Zeitlimit überschritten haben |
OccConflicts |
Transaktionen wurden aufgrund von OCC-Konflikten abgebrochen |
BytesWritten |
In den Speicher geschriebene Rohbytes |
BytesRead |
Aus dem Speicher gelesene Rohbytes |
Verwenden Sie EXPLAIN ANALYZE VERBOSE zur Kostenwahrnehmung
Aurora DSQL wird EXPLAIN ANALYZE VERBOSE um eine Schätzung der DPU-Nutzung auf Anweisungsebene am Ende der Ausgabe erweitert. Dies bietet einen sofortigen Überblick über die Abfragekosten und hilft Ihnen dabei, die Kostentreiber der Arbeitslast zu identifizieren, die Abfrageleistung zu optimieren und die Ressourcennutzung besser vorherzusagen.
Anmerkung
Sie müssen EXPLAIN ANALYZE VERBOSE (mit VERBOSE) verwenden, um DPU-Schätzungen anzuzeigen. Ein Plain EXPLAIN ANALYZE ohne VERBOSE zeigt keine DPU-Informationen an.
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 die meisten Kosten auf Read DPU (0,04312) entfallen, 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 wurden. 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
Mit dieser Anweisung werden hauptsächlich Schreibvorgänge ausgeführt, sodass der Großteil der Kosten auf Write DPU entfällt. Die Compute DPU (0,01550) steht für die Arbeit, die zum Verarbeiten und Einfügen der Werte geleistet wurde. Die Read DPU (0,00307) spiegelt kleinere Systemlesevorgänge wider (für Katalogsuchen oder Indexprüfungen).
Beachten Sie die Mindestwerte für Transaktionen, die in Klammern neben Read and Write DPUs angezeigt werden. Diese Mindestwerte gelten auf Transaktionsebene, was bedeutet, dass die gesamte DPU für Lese- oder Schreibvorgänge für eine gesamte Transaktion niemals unter diesen Werten liegt. Wenn Sie EXPLAIN ANALYZE VERBOSE zur Kostenprognose verwenden und dies die einzige Aussage in der Transaktion ist, verwenden Sie die Mindestwerte der Transaktion und nicht die unformatierten Schätzungen der Kontoauszüge. Wenn die Transaktion mehrere Kontoauszüge enthält, gelten die Mindestwerte für das Aggregat aller Kontoauszüge. Da Schätzungen auf EXPLAIN ANALYZE VERBOSE Kontoauszugsebene gemeldet werden, während für die Abrechnung Mindestwerte auf Transaktionsebene gelten, stimmen die Werte möglicherweise nicht exakt mit Kennzahlen oder Abrechnungsdaten überein. CloudWatch
Verwendung von DPU-Informationen zur Optimierung
Per-statement DPU-Schätzungen 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 Abfragen ist.
-
Schemaoptimierung: Vergleichen Sie die Auswirkungen von Indizes oder Schemaänderungen auf die Leistung und die Ressourceneffizienz.
-
Budgetplanung: Schätzen Sie die Workload-Kosten auf der Grundlage der beobachteten DPU-Nutzung.
-
Abfragevergleich: Bewerten Sie alternative Abfrageansätze anhand ihres relativen DPU-Verbrauchs.
Interpretation von DPU-Informationen
Beachten Sie die folgenden bewährten Methoden, wenn Sie DPU-Daten von verwenden: EXPLAIN ANALYZE
VERBOSE
-
Verwenden Sie es zielgerichtet: Behandeln Sie den gemeldeten DPU als eine Möglichkeit, die relativen Kosten einer Abfrage zu verstehen, und nicht als eine exakte Übereinstimmung mit CloudWatch Kennzahlen oder Abrechnungsdaten. Unterschiede 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 asynchrone ANALYZE oder Komprimierungen) und Transaktions-Overhead (/), der bewusst ausgeschlossen wird.BEGINCOMMITEXPLAIN ANALYZE VERBOSE -
Testen Sie mit repräsentativen Daten als Machbarkeitsnachweis: Wenn Sie einen Machbarkeitsnachweis zur Kostenbewertung durchführen, stellen Sie sicher, dass Ihre Tabellen Datenmengen und Verteilungen enthalten, die Ihrer erwarteten Produktionslast entsprechen. DPU-Schätzungen — unabhängig davon, ob es sich um CloudWatch Daten
EXPLAIN ANALYZE VERBOSEoder Kennzahlen handelt —, die auf leeren oder dünn aufgefüllten Tabellen basieren, spiegeln nicht die tatsächlichen Kosten wider. -
Die DPU-Variabilität zwischen Durchläufen ist in verteilten Systemen normal und weist nicht auf Fehler hin. Faktoren wie Caching, Änderungen des Ausführungsplans, Parallelität, Hintergrundoperationen wie asynchrone ANALYZE 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, sie innerhalb einer einzigen Transaktion zu größeren Schreibvorgängen zusammenzufassen (Änderungen dürfen 10 MB pro Transaktion nicht überschreiten, obwohl Lesevorgänge nur durch das 5-Minuten-Transaktions-Timeout begrenzt sind). Dadurch amortisiert sich die Mindestanzahl an Transaktionen, wenn mehr Arbeit erforderlich ist, und es ergeben sich aussagekräftigere Kostenschätzungen.
-
Verwendung für die Optimierung, nicht für die Abrechnung: Die DPU-Dateneingabe
EXPLAIN ANALYZE VERBOSEdient der Kostenwahrnehmung, der Optimierung von Abfragen und der Optimierung. Es handelt sich nicht um eine Kennzahl für Abrechnungen. Verlassen Sie sich für aussagekräftige Kosten- und Nutzungsdaten immer auf CloudWatch Kennzahlen oder monatliche Abrechnungsberichte.
Bewährte Methoden zur Kostenschätzung
-
Überwachen Sie vor der Optimierung: Verwenden Sie CloudWatch Kennzahlen, um Ihr aktuelles Nutzungsmuster zu verstehen, bevor Sie Optimierungsentscheidungen treffen. Details hierzu finden Sie unter Überwachung der DPU-Nutzung mit CloudWatch.
-
Konzentrieren Sie sich auf die Transaktionseffizienz: Da auf Transaktionsebene Mindestanforderungen gelten, sollten Sie alle miteinander verbundenen Vorgänge zusammenfassen, um die Mindestgebühren zu amortisieren.
-
Verwenden Sie EXPLAIN ANALYZE VERBOSE während der Entwicklung: Führen Sie während
EXPLAIN ANALYZE VERBOSEder Entwicklung wichtige Abfragen durch, um deren Kostenmerkmale zu verstehen. Wenn Sie einen Machbarkeitsnachweis zur Bewertung der Kosten durchführen, sollten Sie die Tests anhand von Tabellen mit repräsentativen Datenmengen und Verteilungen durchführen. Schätzungen, die auf leeren oder dünn gefüllten Tabellen basieren, spiegeln nicht die Produktionskosten wider. Details hierzu finden Sie unter Verwenden Sie EXPLAIN ANALYZE VERBOSE zur Kostenwahrnehmung. -
CloudWatch Alarme einrichten: Erstellen Sie Alarme für DPU-Metriken, um über unerwartete Nutzungsspitzen informiert zu werden.