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 tatsächlich nutzen, ohne Vorabkosten. In diesem Abschnitt wird erklärt, wie Aurora DSQL Ihre Datenbankaktivitäten misst und diese in Gebühren auf Ihrer AWS Rechnung umrechnet. Aktuelle Preise nach Regionen finden Sie auf der [Aurora DSQL-Preisseite.](https://aws.amazon.com/rds/aurora/dsql/pricing/) **Topics** + [Wie funktioniert die Messung](#billing-how-metering-works) + [Die Messung der DPU-Komponenten erklärt](#billing-dpu-components) + [Abrechnung über mehrere Regionen](#billing-multiregion-write-dpu) + [Überwachung der DPU-Nutzung mit CloudWatch](#billing-cloudwatch-monitoring) + [Nutzen Sie EXPLAIN ANALYZE VERBOSE für ein besseres Kostenbewusstsein](#billing-explain-analyze) + [Bewährte Methoden zur Kostenschätzung](#billing-best-practices) ## Wie funktioniert die Messung Im Gegensatz zu herkömmlichen Datenbanken, die die bereitgestellte Kapazität in Rechnung stellen, berechnet Aurora DSQL nur die tatsächlich geleistete Arbeit. Aurora DSQL misst zwei Hauptkomponenten: Datenbankaktivität, gemessen in Distributed Processing Units (DPUs), und Speicher, gemessen in GiB-Monat. DPUs messen, wie viel Arbeit das System für die Ausführung Ihrer SQL-Arbeitslast leistet. Bei Clustern mit nur einer Region bestehen sie aus drei Komponenten: Compute DPUs, Read DPUs und Write. DPUs Bei Clustern mit mehreren Regionen fällt eine zusätzliche MultiRegion Write-DPU-Komponente an. [Einzelheiten finden Sie unter Abrechnung für mehrere Regionen.](#billing-multiregion-write-dpu) In der folgenden Tabelle sind die Komponenten zusammengefasst, 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, also die Summe der einzelnen Komponenten. | 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 | | Speicher | Tabellenspeicher | GiB-Monat | ## Die Messung der DPU-Komponenten erklärt Für jede Transaktion berechnet Aurora DSQL die gesamte DPU als Summe der drei Komponenten: DPU berechnen, DPU lesen und DPU schreiben. In den folgenden Abschnitten wird erklärt, wie Aurora DSQL die einzelnen Komponenten misst. ``` Total DPU = ComputeDPU + ReadDPU + WriteDPU ``` ### Berechnete CPU Die Rechenleistung DPUs wird 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 Wanduhr der Abfrage. Die folgende Formel fasst zusammen, wie Compute berechnet wird: DPUs ``` ComputeDPU = Total Compute time (in seconds) ``` ### CPU schreiben Bei jeder Transaktion misst Aurora DSQL den Schreibvorgang DPUs anhand der Gesamtzahl der in den Speicher geschriebenen Byte. Write DPUs umfasst die Gesamtzahl der in Ihre Basistabelle geschriebenen Daten sowie alle sekundären Indizes. Aurora DSQL berechnet jede Zeile, die in Ihre Basistabelle geschrieben wird, und sekundäre Indizes, die kleiner als 128 Byte sind, als ob sie 128 Byte wären. Aurora DSQL berechnet eine Schreibtransaktion, die weniger als 1.024 Byte schreibt, als ob sie 1.024 Byte geschrieben hätte. **Anmerkung** Bei Schreibvorgängen fallen auch ReadDPU-Gebühren an, da Aurora DSQL vor dem Schreiben den Primärschlüsselindex liest, um die Eindeutigkeit zu überprüfen. Die folgenden Formeln zeigen die Schritte zur Berechnung von Write: DPUs **Schritt 1: Berechnet die geschriebenen Bytes** ``` Bytes Written = Sum of max(size of each row, 128 bytes) for all rows written ``` **Schritt 2: Berechne die geschriebene CPU** ``` WriteDPU = max(Bytes Written, 1024) × 0.00004883 ``` ### DPU lesen Für jede Transaktion misst Aurora DSQL Read DPUs anhand der Gesamtzahl der aus dem Speicher gelesenen Byte. Read DPUs schließt Daten ein, die aus Ihrer Basistabelle gelesen wurden, sowie alle Sekundärindizes. **Minimum pro Partition:** Aurora DSQL misst gelesene 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 aus 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, was zu einer Gesamtsumme von 200 \+ 128 \+ 128 \+ 128 = 584 Byte in Rechnung gestellt wird. **Mindesttransaktion:** Aurora DSQL berechnet eine Lesetransaktion, die insgesamt weniger als 2.048 Byte liest, als ob sie 2.048 Byte gelesen hätte. Die folgenden Formeln zeigen die Schritte zur Berechnung von Read: DPUs **Schritt 1: Berechne die gelesenen Byte** ``` 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 gilt. Wenn all Ihre Zeilengrößen über 128 Byte liegen, können Sie einfach die Anzahl der gelesenen Zeilen mit der Größe jeder Zeile multiplizieren. **Schritt 2: ReadDPU berechnen** ``` ReadDPU = max(Bytes Read, 2048) × 0.00000183105 ``` ### Abrechnungsbeispiel Die folgenden Beispiele zeigen, wie Aurora DSQL DPUs für allgemeine Operationen berechnet. Die Kostenwerte in diesen Beispielen verwenden den Preis für die Region us-east-1. Preise in anderen Regionen finden Sie auf der [Aurora DSQL-Preisseite.](https://aws.amazon.com/rds/aurora/dsql/pricing/) #### Beispiel: Einfache Punktsuche (gelesen) Dieses Beispiel zeigt eine ReadDPU-Berechnung für die Punktabfrage, 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:** Angenommen, die Ausführungszeit der Abfrage beträgt 3 ms (0,003 Sekunden): ``` ComputeDPU: 0.003 ReadDPU: 0.00375 WriteDPU: 0.0 ------------------- Total DPU: 0.00675 ``` #### Beispiel: Scan eines gefilterten Bereichs (gelesen) **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 scannt 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-Rechnungen für alle 100 gescannten Zeilen. 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:** Angenommen, die Ausführungszeit der Abfrage beträgt 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, sollten Sie Abfragen und Indizes so entwerfen, 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 scannt. #### Beispiel: Einzelnes Einfügen (Lesen und Schreiben) **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. **CPU-Berechnung schreiben:** *Schritt 1 — Geschriebene Byte berechnen:* ``` 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 seit 128 < 1.024. **readDPU (Primärschlüsselprüfung):** Aurora DSQL liest den Primärschlüsselindex, um die Eindeutigkeit vor dem Schreiben zu überprüfen. Dadurch fällt die Mindestgebühr für das Lesen der Transaktion an. ``` ReadDPU = 0.00375 (transaction minimum) ``` **Gesamtkosten der Transaktion:** Angenommen, die Ausführungszeit der Abfrage beträgt 8 ms (0,008 Sekunden): ``` ComputeDPU: 0.008 ReadDPU: 0.00375 WriteDPU: 0.05 ------------------- Total DPU: 0.06175 ``` #### Beispiel: Masseneinfügung (lesen und schreiben) **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. **CPU-Berechnung schreiben:** *Schritt 1 — Geschriebene Byte berechnen:* ``` 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:** Angenommen, die Ausführungszeit der Abfrage beträgt 80 ms (0,08 Sekunden): ``` ComputeDPU: 0.08 ReadDPU: 0.00375 WriteDPU: 0.625 ------------------- Total DPU: 0.70875 ``` ## Abrechnung über mehrere Regionen Bei Clustern mit mehreren Regionen fällt zusätzlich zu den standardmäßigen Compute-, Read- und Write-Funktionen eine zusätzliche MultiRegion DPU-Schreibkomponente an. DPUs Dieser Abschnitt gilt nur für Cluster mit mehreren Regionen. Für Cluster mit einer Region fällt diese Gebühr nicht an. MultiRegion Beim Schreiben wird die Gesamtzahl der Byte DPUs gemessen, die in die Peering-Region geschrieben wurden. Da Aurora DSQL die Daten, die Sie schreiben, synchron in die Peering-Region repliziert, entspricht der Write-DPU-Wert dem MultiRegion Write-DPU. Aurora DSQL berechnet diese DPU in der Region, aus der der Schreibvorgang stammt, und nicht in der Peering-Region. ``` MultiRegionWriteDPU = WriteDPU ``` ## Überwachung der DPU-Nutzung mit CloudWatch Aurora DSQL veröffentlicht Nutzungsmetriken auf Amazon CloudWatch, sodass Sie den Verbrauch nahezu in Echtzeit überwachen können. ### Verfügbare DPU-Metriken **DPU-Metriken** | CloudWatch Metrik | Description | Dimension | | --- | --- | --- | | WriteDPU | Nutzungskomponente schreiben | ClusterId | | ReadDPU | Nutzungskomponente lesen | ClusterId | | ComputeDPU | Komponente zur Verarbeitung von Abfragen | ClusterId | | MultiRegionWriteDPU | Replikation mit mehreren Regionen (nur Cluster mit mehreren Regionen) | ClusterId | | TotalDPU | Summe aller DPU-Komponenten | ClusterId | ### DPU-Metriken anzeigen **Um DPU-Metriken anzuzeigen in CloudWatch** 1. Öffnen Sie die [CloudWatch-Konsole](https://console.aws.amazon.com/cloudwatch). 1. Navigieren Sie zu **Metriken**, dann zu **AuroradSQL** und dann zu. **ClusterId** 1. 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 Zeitraum zu sehen. Fügen Sie das **LAST-Label** hinzu, um den neuesten Wert zu sehen. ### 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](monitoring-overview.md). **Beobachtbarkeitsmetriken** | Metrik | Description | | --- | --- | | ClusterStorageSize | Aktuelle Speichergröße in Byte | | TotalTransactions | Gesamtzahl der ausgeführten Transaktionen | | ReadOnlyTransactions | Schreibgeschützte Transaktionen wurden ausgeführt | | 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 | ## Nutzen Sie EXPLAIN ANALYZE VERBOSE für ein besseres Kostenbewusstsein Aurora DSQL wird erweitert `EXPLAIN ANALYZE VERBOSE` und enthält am Ende der Ausgabe eine Schätzung der DPU-Nutzung auf Anweisungsebene. Dies bietet einen sofortigen Einblick in die Abfragekosten und hilft Ihnen, Workload-Kostentreiber zu identifizieren, die Abfrageleistung zu optimieren und die Ressourcennutzung besser zu prognostizieren. **Anmerkung** Sie müssen `EXPLAIN ANALYZE VERBOSE` (mit VERBOSE) verwenden, um die DPU-Schätzungen zu sehen. 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 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 kein 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 in Klammern neben Lesen und Schreiben angezeigt werden. DPUs 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 eine Kostenprognose verwenden `EXPLAIN ANALYZE VERBOSE` und dies die einzige Aussage in der Transaktion ist, verwenden Sie die Mindestwerte für die Transaktion und nicht die unformatierten Schätzungen für die Abrechnung. Wenn die Transaktion mehrere Kontoauszüge enthält, gelten die Mindestwerte für die Summe 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 den Kennzahlen oder 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: Finden** Sie heraus, 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 VERBOSE` Kontoauszugsebene gemeldet werden, während die Aktivitäten auf Transaktionsebene aggregiert werden. CloudWatch CloudWatch umfasst auch Hintergrundoperationen (wie asynchrone ANALYZE oder Komprimierungen) und Transaktionsaufwand (/), der bewusst ausgeschlossen wurde. `BEGIN` `COMMIT` `EXPLAIN ANALYZE VERBOSE` + **Testen Sie anhand repräsentativer Daten für Machbarkeitsnachweise: Stellen Sie bei der** Durchführung eines Machbarkeitsnachweises zur Kostenbewertung sicher, dass Ihre Tabellen Datenmengen und -verteilungen enthalten, die Ihrer erwarteten Produktionsauslastung entsprechen. DPU-Schätzungen — unabhängig davon, ob es sich um `EXPLAIN ANALYZE VERBOSE` Daten oder CloudWatch Kennzahlen handelt —, die auf leeren oder spärlich gefüllten Tabellen basieren, spiegeln nicht die realen Kosten wider. + Die **DPU-Variabilität zwischen den Läufen ist in verteilten Systemen normal** und weist nicht auf Fehler hin. Faktoren wie Zwischenspeicherung, Ä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, diese 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-minütige Transaktions-Timeout begrenzt sind). Dadurch amortisieren sich die Mindesttransaktionen bei mehr Arbeit und es ergeben sich aussagekräftigere Kostenschätzungen. + **Wird für die Feinabstimmung verwendet, nicht für die Fakturierung:** Die `EXPLAIN ANALYZE VERBOSE` eingehenden DPU-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. ## Bewährte Methoden zur Kostenschätzung + **Überwachen Sie vor der Optimierung:** Verwenden Sie CloudWatch Metriken, um Ihr aktuelles Nutzungsmuster zu verstehen, bevor Sie Optimierungsentscheidungen treffen. Details hierzu finden Sie unter [Überwachung der DPU-Nutzung mit CloudWatch](#billing-cloudwatch-monitoring). + **Konzentrieren Sie sich auf die Transaktionseffizienz:** Da Mindestbeträge auf Transaktionsebene gelten, können Sie alle Vorgänge stapelweise zusammenfassen, um die Mindestgebühren amortisieren zu können. + **Verwenden Sie EXPLAIN ANALYZE VERBOSE während der Entwicklung:** Führen Sie während `EXPLAIN ANALYZE VERBOSE` der Entwicklung kritische Abfragen aus, um deren Kosteneigenschaften zu verstehen. Testen Sie bei der Durchführung eines Machbarkeitsnachweises zur Bewertung der Kosten anhand von Tabellen mit repräsentativen Datenmengen und -verteilungen — Schätzungen, die auf leeren oder spärlich gefüllten Tabellen basieren, spiegeln nicht die Produktionskosten wider. Details hierzu finden Sie unter [Nutzen Sie EXPLAIN ANALYZE VERBOSE für ein besseres Kostenbewusstsein](#billing-explain-analyze). + ** CloudWatch Alarme einrichten:** Erstellen Sie Alarme für DPU-Metriken, um über unerwartete Nutzungsspitzen informiert zu werden.