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.

Evaluieren Sie die Nutzung Ihrer DynamoDB-Streams

In diesem Abschnitt erfahren Sie, wie Sie Ihre Nutzung von DynamoDB-Streams auswerten können. Gewisse Nutzungsmuster sind für DynamoDB nicht optimal und bieten sowohl mit Blick auf die Leistung als auch auf die Kosten Raum für Optimierungen.

Es gibt zwei native Streaming-Integrationen für streaming- und ereignisgesteuerte Anwendungsfälle:

Auf dieser Seite geht es um die Strategien zur Kostenoptimierung für diese Optionen. Wenn Sie mehr über die Auswahl zwischen den beiden Optionen erfahren möchten, beachten Sie den Abschnitt Streaming-Optionen für die Erfassung der Änderung von Daten.

Optimieren der Kosten für DynamoDB-Streams

Wie auf der Seite zu den Preisen für DynamoDB-Streams erwähnt, berechnet DynamoDB unabhängig vom Durchsatzkapazitätsmodus der Tabelle Gebühren für die Anzahl der Leseanforderungen, die an den DynamoDB-Stream der Tabelle gestellt werden. Es gibt Unterschiede zwischen Leseanforderungen an einen DynamoDB-Stream und Leseanforderungen an eine DynamoDB-Tabelle.

Jede Leseanforderung in Bezug auf den Stream hat die Form eines GetRecords API Aufrufs, der bis zu 1000 Datensätze oder Datensätze im Wert von 1 MB in der Antwort zurückgeben kann, je nachdem, was zuerst erreicht wird. Keiner der anderen DynamoDB Streams wird in Rechnung gestellt, und DynamoDB-Streams APIs werden nicht berechnet, wenn sie sich im Leerlauf befinden. Mit anderen Worten, wenn keine Leseanforderungen an einen DynamoDB-Stream gestellt werden, entstehen allein durch die Tatsache, dass ein DynamoDB-Stream für eine Tabelle aktiviert ist, keine Kosten.

Einige Konsumentenanwendungen für DynamoDB Streams:

Leseanfragen von AWS Lambda-basierten Benutzern von DynamoDB Streams sind kostenlos, wohingegen Anrufe von Verbrauchern anderer Art kostenpflichtig sind. Auch sind jeden Monat die ersten 2 500 000 Leseanforderungen von Nicht-Lambda-Konsumenten kostenlos. Dies gilt für alle Leseanfragen, die an DynamoDB Streams in einem AWS Konto für jede AWS Region gestellt werden.

Überwachen Ihrer Nutzung von DynamoDB-Streams

Die Gebühren für DynamoDB Streams auf der Abrechnungskonsole werden für alle DynamoDB Streams in der gesamten AWS Region in einem Konto zusammengefasst. AWS Zurzeit wird das Markieren von DynamoDB-Streams nicht unterstützt. Somit ist es nicht möglich, mithilfe von Kostenzuordnungs-Tags die detaillierten Kosten für DynamoDB-Streams zu ermitteln. Die Anzahl der GetRecords-Aufrufe kann auf DynamoDB-Stream-Ebene abgerufen werden, um die Gebühren pro Stream zu berechnen. Das Volumen wird durch die CloudWatch Metrik SuccessfulRequestLatency und die zugehörige SampleCount Statistik des DynamoDB-Streams dargestellt. Diese Metrik umfasst auch GetRecords Aufrufe von globalen Tabellen zur Durchführung einer laufenden Replikation sowie Aufrufe von AWS Lambda-Verbrauchern, für die beide keine Gebühren anfallen. Informationen zu anderen von DynamoDB Streams veröffentlichten CloudWatch Metriken finden Sie unter. DynamoDB-Metriken und -Dimensionen

AWS Lambda als Verbraucher verwenden

Prüfen Sie, ob die Verwendung von AWS Lambda-Funktionen als Verbraucher für DynamoDB Streams möglich ist, da dadurch die Kosten für das Lesen aus dem DynamoDB-Stream entfallen können. Auf der anderen Seite werden DynamoDB Streams Kinesis Adapter oder SDK basierte Verbraucheranwendungen nach der Anzahl der GetRecords Aufrufe berechnet, die sie mit dem DynamoDB-Stream tätigen.

Aufrufe von Lambda-Funktionen werden unter Berücksichtigung der Lambda-Standardpreise berechnet, für DynamoDB-Streams fallen jedoch keine Gebühren an. Lambda fragt Shards in Ihrem DynamoDB-Stream mit einer Basisrate von viermal pro Sekunde nach Datensätzen ab. Sind Datensätze verfügbar, ruft Lambda Ihre Funktion auf und wartet auf das Ergebnis. Ist die Verarbeitung erfolgreich, setzt Lambda die Abrufe fort, bis es weitere Datensätze erhält.

Optimieren von DynamoDB-Streams-Kinesis-Adapter-basierten Konsumentenanwendungen

Da Leseanforderungen von nicht-Lambda-basierten Konsumenten für DynamoDB-Streams in Rechnung gestellt werden, ist es wichtig, ein Gleichgewicht zu finden zwischen der Anforderung einer Verarbeitung nahezu in Echtzeit und der Häufigkeit, mit der die Konsumentenanwendung den DynamoDB-Stream abfragen muss.

Die Häufigkeit der Abfrage von DynamoDB-Streams mithilfe einer DynamoDB-Streams-Kinesis-Adapter-basierten Anwendung wird durch den konfigurierten idleTimeBetweenReadsInMillis-Wert bestimmt. Dieser Parameter legt fest, wie viele Millisekunden der Konsument warten sollte, bevor er einen Shard verarbeitet, falls der vorherige GetRecords-Aufruf an denselben Shard keine Datensätze zurückgegeben hat. Der Standardwert für diesen Parameter sind 1 000 ms. Wenn keine echtzeitnahe Verarbeitung notwendig ist, kann der Wert für diesen Parameter erhöht werden, damit die Konsumentenanwendung weniger GetRecords-Aufrufe tätigt und die DynamoDB-Streams-Aufrufe optimiert werden.

Optimieren der Kosten für Kinesis Data Streams

Wenn ein Kinesis Data Stream als Ziel für die Bereitstellung von Änderungsdatenerfassungsereignissen für eine DynamoDB-Tabelle festgelegt ist, muss die Dimensionierung des Kinesis Data Streams möglicherweise separat erfolgen. Dies wirkt sich auf die Gesamtkosten aus. DynamoDB berechnet Gebühren in Form von Change Data Capture Units (CDUs), wobei jede Einheit aus einer DynamoDB-Elementgröße von bis zu 1 KB besteht, die der DynamoDB-Dienst versucht, den Ziel-Kinesis Data Stream zu erreichen.

Zusätzlich zu den Gebühren des DynamoDB-Service fallen die Kinesis-Data-Stream-Standardgebühren an. Wie auf der Seite zu den Preisen erwähnt, unterscheiden sich die Servicepreise je nach Kapazitätsmodus – Modus bereitgestellter Kapazität und On-Demand-Modus. Diese Kapazitätsmodi unterscheiden sich von den Kapazitätsmodi für DynamoDB-Tabellen und sind benutzerdefiniert. Allgemein berechnet Kinesis Data Streams einen Stundensatz, der auf dem Kapazitätsmodus sowie auf den Daten basiert, die von dem DynamoDB-Service in den Strom aufgenommen werden. Je nach Benutzerkonfiguration für den Kinesis Data Stream können zusätzliche Gebühren, beispielsweise für den Datenabruf (beim On-Demand-Modus), für eine verlängerte Datenaufbewahrung (über die standardmäßigen 24 Stunden hinaus) und für erweiterte Fan-Out-Konsumentenabrufe anfallen.

Überwachen Ihrer Nutzung von Kinesis Data Streams

Kinesis Data Streams for DynamoDB veröffentlicht zusätzlich zu den standardmäßigen Kinesis Data Stream-Metriken auch Metriken von DynamoDB. CloudWatch Es ist möglich, dass ein Put Versuch des DynamoDB-Dienstes vom Kinesis-Dienst aufgrund unzureichender Kinesis Data Streams-Kapazität gedrosselt wird, oder durch abhängige Komponenten wie einen AWS KMS Dienst, der so konfiguriert sein kann, dass er die inaktiven Kinesis Data Stream-Daten verschlüsselt.

Weitere Informationen zu den vom DynamoDB-Dienst für den Kinesis Data Stream veröffentlichten CloudWatch Metriken finden Sie unter. Änderung der Datenerfassung für Kinesis Data Streams überwachen Um zusätzliche Kosten für Servicewiederholungen aufgrund von Drosselungen zu vermeiden, ist die richtige Dimensionierung des Kinesis Data Streams im Modus bereitgestellter Kapazität wichtig.

Wählen des richtigen Kapazitätsmodus für Kinesis Data Streams

Kinesis Data Streams werden in zwei Kapazitätsmodi unterstützt: im Modus bereitgestellter Kapazität und im On-Demand-Modus.

Eine bewährte Methode zur Kostenoptimierung besteht darin, zu prüfen, ob die dem Kinesis Data Stream zugeordnete DynamoDB-Tabelle ein vorhersehbares Datenverkehrsmuster aufweist, sodass der Modus bereitgestellter Kapazität von Kinesis Data Streams genutzt werden kann. Wenn es sich um einen neuen Workload handelt, können Sie in den ersten Wochen den On-Demand-Modus für die Kinesis Data Streams verwenden, die CloudWatch Metriken überprüfen, um die Verkehrsmuster zu verstehen, und dann denselben Stream je nach Art der Arbeitslast in den Bereitstellungsmodus umschalten. Im Modus bereitgestellter Kapazität kann die Anzahl der Shards unter Berücksichtigung der Überlegungen zur Shard-Verwaltung für Kinesis Data Streams geschätzt werden.

Auswerten Ihrer Konsumentenanwendungen unter Verwendung von Kinesis Data Streams for DynamoDB

Da Kinesis Data Streams nicht wie DynamoDB-Streams nach der Anzahl der GetRecords-Aufrufe abgerechnet werden, könnten Konsumentenanwendungen so viele Aufrufe wie möglich tätigen, sofern die Frequenz unter den Drosselungsgrenzen für GetRecords liegt. Beim On-Demand-Modus für Kinesis Data Streams werden Datenlesevorgänge pro GB berechnet. Beim Modus bereitgestellter Kapazität für Kinesis Data Streams werden Lesevorgänge nicht berechnet, wenn die Daten weniger als 7 Tage alt sind. Wenn es sich bei den Kinesis-Data-Streams-Konsumenten um Lambda-Funktionen handelt, fragt Lambda jeden Shard in Ihrem Kinesis-Stream mit einer Basisrate von einmal pro Sekunde nach Datensätzen ab.

Strategien zur Kostenoptimierung für beide Arten der Nutzung von Streams

Ereignisfilterung für AWS Lambda-Verbraucher

Mit der Lambda-Ereignisfilterung können Sie Ereignisse auf der Grundlage eines Filterkriteriums aus dem Stapel der Lambda-Funktionsaufrufe ausschließen. Dadurch werden die Lambda-Kosten für die Verarbeitung oder das Verwerfen unerwünschter Datenstrom-Datensätze innerhalb der Konsumenten-Funktionslogik optimiert. Weitere Informationen zum Konfigurieren der Ereignisfilterung und zum Schreiben von Filterkriterien finden Sie unter Lambda-Ereignisfilterung.

AWS Lambda-Verbraucher einstellen

Durch eine bessere Einstellung der Lambda-Konfigurationsparameter, beispielsweise die Erhöhung von BatchSize, um pro Aufruf mehr verarbeiten zu können, die Aktivierung von BisectBatchOnFunctionError, um die Verarbeitung von Duplikaten zu verhindern (die zusätzliche Kosten verursacht) und die Einstellung von MaximumRetryAttempts, um zu viele Wiederholungen zu vermeiden, können die Kosten weiter optimiert werden. Standardmäßig werden fehlgeschlagene Lambda-Konsumentenaufrufe unendlich oft wiederholt, bis der Datensatz im Datenstrom abläuft, was bei DynamoDB-Streams nach etwa 24 Stunden der Fall ist und bei Kinesis Data Streams zwischen 24 Stunden bis zu einem Jahr konfigurierbar ist. Weitere verfügbare Lambda-Konfigurationsoptionen, einschließlich der oben für DynamoDB-Stream-Konsumenten genannten Optionen, finden Sie im AWS -Lambda-Entwicklerhandbuch.