Fakturierung für Amazon Redshift Serverless

Sie können On-Demand-Kapazität erwerben – Wenn Sie sich für eine On-Demand-Rechenkapazität entscheiden, zahlen Sie nutzungsbasiert für Ressourcen. Dies ist die beste Option, wenn Sie gerade erst anfangen, Amazon Redshift Serverless zu verwenden, oder wenn Sie noch kein gutes Verständnis Ihrer konstanten Nutzungsmuster haben. On-Demand-Rechenkapazitäten bieten die größte Flexibilität. Weitere Informationen finden Sie unter Fakturierung für On-Demand-Rechenkapazität.

Sie können Reservierungen kaufen – Eine Reservierung bietet einen Rabatt, wenn Sie eine feste Menge an Rechenressourcen für einen bestimmten Zeitraum kaufen, z. B. für ein Jahr. Es ist eine gute Idee, wenn Sie wissen, dass Sie konstant eine bestimmte Kapazität nutzen werden. Wenn Sie einen Teil Ihres Kapazitätsbedarfs prognostizieren können, ist dies hilfreich, um Kosten zu sparen. Weitere Informationen finden Sie unter Fakturierung für Serverless-Reservierungen.

Nutzungsaufzeichnung – Eine Abfrage oder Transaktion wird erst gemessen und aufgezeichnet, nachdem die Transaktion abgeschlossen ist, zurückgesetzt oder gestoppt wurde. Wenn eine Transaktion beispielsweise zwei Tage lang ausgeführt wird, wird die RPU-Nutzung nach Abschluss aufgezeichnet. Sie können die laufende Nutzung in Echtzeit überwachen, indem Sie abfragen sys_serverless_usage. Die Transaktionsaufzeichnung kann sich als Variation der RPU-Nutzung widerspiegeln und auf die Kosten für bestimmte Stunden und die tägliche Nutzung auswirken.

Schreiben von expliziten Transaktionen – Dies ist eine wichtige bewährte Methode zum Beenden von Transaktionen. Wenn Sie eine offene Transaktion nicht beenden oder zurücksetzen, verwendet Amazon Redshift Serverless weiterhin RPUs. Wenn Sie beispielsweise eine explizite BEGIN TRAN-Anweisung schreiben, ist es wichtig, auch entsprechende COMMIT- und ROLLBACK-Anweisungen anzugeben.

Abgebrochene Abfragen – Wenn Sie eine Abfrage ausführen und abbrechen, bevor sie abgeschlossen ist, wird Ihnen die Zeit, während der die Abfrage ausgeführt wurde, dennoch in Rechnung gestellt.

Skalierung – Die Amazon-Redshift-Serverless-Instance kann zur Bewältigung von Zeiträumen mit höherer Belastung Skalierungen einleiten, um eine konsistente Leistung aufrechtzuerhalten. Die Fakturierung für Amazon Redshift Serverless umfasst sowohl Basis-Rechenkapazität als auch skalierte Kapazität zum gleichen RPU-Tarif.

Herunterskalieren – Amazon Redshift Serverless skaliert von seiner Basis-RPU-Kapazität hoch, um Zeiträume mit höherer Belastung zu bewältigen. In einigen Fällen bleibt die RPU-Kapazität für einen gewissen Zeitraum nach dem Rückgang der Abfragelast möglicherweise auf einer höheren Stufe. Wir empfehlen Ihnen, maximale RPU-Stunden in der Konsole so einzustellen, dass Sie vor unerwarteten Kosten geschützt sind.

Systemtabellen – Wenn Sie eine Systemtabelle abfragen, wird die Abfragezeit in Rechnung gestellt.

Redshift Spectrum – Wenn Sie Amazon Redshift Serverless nutzen und Abfragen ausführen, fällt für Data-Lake-Abfragen keine separate Gebühr an. Bei Abfragen zu Daten, die in Amazon S3 gespeichert sind, entspricht die Gebühr nach Transaktionszeit der für Abfragen von lokalen Daten.

Verbundabfragen – Verbundabfragen werden nach den in einem bestimmten Zeitintervall genutzten RPUs berechnet, genau wie Abfragen im Data Warehouse oder Data Lake.

Speicher – Der Speicher wird separat nach GB/Monat in Rechnung gestellt.

Mindestgebühr – Die Mindestgebühr gilt für 60 Sekunden Ressourcennutzung, gemessen auf Sekundenbasis.

Snapshot-Fakturierung – Die Snapshot-Fakturierung ändert sich nicht. Die Fakturierung erfolgt je nach Speicher in GB/Monat. Sie können Ihr Data Warehouse kostenlos auf bestimmte Punkte in den letzten 24 Stunden zurücksetzen, mit einer Granularität von 30 Minuten. Weitere Informationen finden Sie unter Amazon Redshift – Preise.

Stellen Sie sicher, dass Sie jede Transaktion beenden. Wenn Sie eine Aktion mit BEGIN starten, müssen Sie sie auch mit END beenden.

Verwenden Sie die bewährten Methoden zur Fehlerbehebung, um ordnungsgemäß auf Fehler zu reagieren und jede Transaktion zu beenden. Die Minimierung offener Transaktionen hilft, unnötige RPU-Nutzung zu vermeiden.

SESSION TIMEOUT hilft durch Beendigung offener Transaktionen und inaktiver Sitzungen. Es führt bei Sitzungen, die länger als 3 600 Sekunden (1 Stunde) inaktiv sind, zu einem Timeout. Es führt bei Transaktionen, die länger als 21 600 Sekunden (6 Stunden) offen und inaktiv sind, zu einem Timeout. Diese Zeitüberschreitungseinstellung kann explizit für einen bestimmten Benutzer geändert werden, z. B. wenn Sie eine Sitzung für eine lang laufende Abfrage geöffnet lassen möchten. Das Thema CREATE USER zeigt, wie SESSION TIMEOUT für einen Benutzer eingestellt wird.

Passen Sie die Häufigkeit von Zustandsprüfungen an, indem Sie die Häufigkeit von Zustandsprüfungen oder Keep-Alive-Abfragen in Ihrer Verbindungspooling-Konfiguration überprüfen und optimieren.

Optimieren Sie die Leerlaufeinstellungen des Systems, indem Sie das Verbindungspooling so konfigurieren, dass unnötige Verbindungen oder Hintergrundabfragen während der Leerlaufzeiten des Systems minimiert werden.

Implementieren Sie Pooling auf Anwendungsebene oder eine verbesserte Verwaltung des Verbindungslebenszyklus, wenn dies den Overhead reduzieren kann.

Deaktivieren Sie Heartbeat- oder Validierungsabfragen, wenn die Konfiguration des Verbindungspoolings dies zulässt. Überprüfen Sie die spezifischen Verbindungszeichenfolgenparameter oder Konfigurationsdateien, um diese Einstellungen anzupassen.

Optimieren Sie die TCP-Keepalive-Einstellungen: Wenn Sie die internen Heartbeat-Mechanismen des Treibers nicht deaktivieren können, passen Sie die TCP-Keepalive-Einstellungen auf Betriebssystem- oder Anwendungsebene an, um Probleme mit Verbindungstimeouts zu beheben. Details hierzu finden Sie in der Dokumentation für Betriebssystem, JDBC/ODBC-Treiber oder Verbindungspool.

Optimieren Sie das Datenbankverbindungspooling: Konfigurieren Sie Ihren Verbindungspool (HikariCP, Apache Database Connection Pool), um Verbindungen zu verwalten und den Verbindungsaufwand zu minimieren. Konzentrieren Sie sich auf Parameter wie maximale Zahl der Verbindungen, Leerlauf-Timeout und Validierungsabfragen (wenn notwendig). Diese Optimierung hilft, die Rechennutzung in Amazon Redshift Serverless an den tatsächlichen Workload-Bedarf anzupassen und so potenziell die Kosten zu senken.

Verwenden Sie die niedrigere RPU-Basiskapazität von 8 RPU, wenn sie für Workloads verfügbar ist.

Konfigurieren Sie das REFRESH_INTERVAL Ihrer Redshift-Ziel-Instance, um Aktualität und Kosten in Einklang zu bringen. Kürzere Intervalle sorgen für Updates fast in Echtzeit, treiben jedoch die Rechenkosten in die Höhe. Längere Intervalle (5 Minuten oder länger) reduzieren die Kosten für Workloads, für die eine sofortige Aktualisierung nicht kritisch ist, z. B. Berichte oder historische Analysen. Informationen zum Bearbeiten des Redshift-Ziels REFRESH_INTERVAL finden Sie in der Aktualisierungsintervallklausel in der Beschreibung ALTER DATABASE.

Maximieren Sie die Nutzung Ihrer Umgebung in Amazon Redshift Serverless, indem Sie Analytik-Workloads ausführen, während Zero-ETL-Daten erfasst werden. Dies stellt sicher, dass die Rechenkapazität aktiv mehreren Geschäftszwecken dient.