Amazon DynamoDB Transactions: Funktionsweise

Mit Amazon-DynamoDB-Transaktionen können Sie mehrere Aktionen gruppieren und als einzelne all-or-nothing TransactWriteItems - oder -TransactGetItemsOperation senden. Die folgenden Abschnitte beschreiben API-Produktionen, Kapazitätsverwaltung, bewährte Methoden und andere Details zur Verwendung von Transaktionsoperationen in DynamoDB.

TransactWriteItems API

TransactWriteItems ist ein synchroner und idempotenter Schreibvorgang, der bis zu 100 Schreibaktionen in einer einzigen all-or-nothing Operation gruppiert. Diese Aktionen können auf bis zu 100 unterschiedliche Elemente in einer oder mehreren DynamoDB-Tabellen innerhalb desselben AWS-Kontos und in derselben Region abzielen. Die aggregierte Größe der Elemente in der Transaktion darf 4 MB nicht übersteigen. Die Aktionen werden atomarisch ausgeführt, d. h. entweder sind alle von ihnen oder keine von ihnen erfolgreich.

Anmerkung

• Eine TransactWriteItems-Operation unterscheidet sich darin von einer BatchWriteItem-Operation, dass alle darin enthaltenen Aktionen erfolgreich ausgeführt werden müssen, damit irgendwelche Änderungen vorgenommen werden. Bei einer BatchWriteItem-Operation ist es dagegen möglich, dass nur einige der Aktionen im Stapel erfolgreich sind und andere fehlschlagen.

• Transaktionen können nicht mit Indizes ausgeführt werden.

Sie können nicht in derselben Transaktion mit mehreren Operationen auf das gleiche Element abzielen. Beispiel: In derselben Transaktion ist es nicht möglich eine ConditionCheck- sowie eine Update-Aktion für dasselbe Element auszuführen.

Sie können die folgenden Aktionstypen zu einer Transaktion hinzufügen:

• Put – Initiiert eine PutItem-Produktion, um bedingungsabhängig oder bedingungslos ein neues Element zu erstellen oder ein altes Element durch ein neues Element zu ersetzen.

• Update – Initiiert eine UpdateItem-Produktion, um die Attribute eines vorhandenen Elements zu bearbeiten oder ein neues Element zur Tabelle hinzuzufügen, sofern noch nicht vorhanden. Mit dieser Aktion können Sie Attribute für ein vorhandenes Element bedingungsabhängig oder bedingungslos hinzufügen, löschen oder aktualisieren.

• Delete – Initiiert eine DeleteItem-Produktion,, um ein einzelnes Element über seinen Primärschlüssel in einer Tabelle zu löschen.

• ConditionCheck – Überprüft, ob ein Element vorhanden ist, oder überprüft die Bedingung bestimmter Attribute des Elements.

Sobald eine Transaktion abgeschlossen ist, werden die damit vorgenommenen Änderungen an globale sekundäre Indizes (GSIs), Streams und Backups übertragen, nachdem die Translation erfolgreich durchgeführt wurde. Da die Verbreitung nicht sofort oder sofort erfolgt, kann sie einige, aber nicht alle Änderungen enthalten, die während einer kürzlichen Transaktion vorgenommen wurden, wenn eine Tabelle aus der Sicherung (RestoreTableFromBackup) wiederhergestellt oder zu einem bestimmten Zeitpunkt (ExportTableToPointInTime) exportiert wird.

Idempotenz

Sie können optional ein Client-Token einschließen, wenn Sie einen TransactWriteItems-Aufruf machen, um sicherzustellen, dass die Anforderung idempotent ist. Durch idempotente Transaktionen lassen sich Anwendungsfehler vermeiden, falls dieselbe Operation aufgrund einer Verbindungszeitüberschreitung oder sonstiger Konnektivitätsprobleme mehrmals übermittelt wird.

Wenn der ursprüngliche TransactWriteItems-Aufruf erfolgreich war, werden nachfolgende TransactWriteItems-Aufrufe mit demselben Client-Token als erfolgreich zurückgegeben, ohne Änderungen vorzunehmen. Wenn der Parameter ReturnConsumedCapacity eingestellt ist, gibt der erstmalige TransactWriteItems-Aufruf die Anzahl an Schreibkapazitätseinheiten zurück, die beim Vornehmen der Änderungen verbraucht wurden. Nachfolgende TransactWriteItems-Aufrufe mit demselben Client-Token geben die Anzahl der Lesekapazitätseinheiten zurück, die beim Lesen des Elements verbraucht wurden.

Wichtige Punkte bezüglich Idempotenz

• Ein Client-Token ist weitere 10 Minuten lang gültig, nachdem die Anforderung, die davon Gebrauch gemacht hat, beendet wurde. Nach 10 Minuten werden alle Anforderungen, die dasselbe Client-Token nutzen, als neue Anforderung angesehen. Deshalb sollten Sie dasselbe Client-Token nach 10 Minuten nicht erneut für dieselbe Anwendung verwenden.

• Wenn Sie eine Anforderung mit demselben Client-Token innerhalb des 10-minütigen Idempotenzfenster wiederholen, aber einen anderen Anforderungsparameter ändern, gibt DynamoDB die Ausnahme IdempotentParameterMismatch zurück.

Fehlerbehandlung beim Schreiben

Schreibtransaktionen schlagen unter den folgenden Umständen fehl:

• Wenn eine Bedingung in einem der Bedingungsausdrücke nicht erfüllt wird.

• Wenn ein Transaktionsvalidierungsfehler auftritt, da mehr als eine Aktion in derselben TransactWriteItems-Operation auf dasselbe Element abzielt.

• Wenn eine TransactWriteItems-Anforderung mit einer andauernden TransactWriteItems-Operation an mindestens einem Element in der TransactWriteItems-Anforderung in Konflikt steht. In diesem Fall schlägt die Anfrage mit der Ausnahme TransactionCanceledException fehl.

• Wenn für die durchzuführende Transaktion nicht genügend Kapazität bereitgestellt wird.

• Wenn ein Element zu groß wird (größer als 400 KB) oder wenn ein lokaler sekundärer Index (LSI) zu groß wird oder wenn aufgrund der durch die Transaktion vorgenommenen Änderungen ein ähnlicher Validierungsfehler auftritt.

• Wenn ein Benutzerfehler, wie z. B. ein ungültiges Datenformat, auftritt.

Weitere Informationen zum Umgang mit Konflikten mit TransactWriteItems-Operationen finden Sie unter Handhabung von Transaktionskonflikten in DynamoDB.

TransactGetItems API

TransactGetItems ist ein synchroner Lesevorgang, der bis zu 100 Get-Aktionen zusammengruppiert. Diese Aktionen können auf bis zu 100 unterschiedliche Elemente in einer oder mehreren DynamoDB-Tabellen innerhalb desselben AWS-Kontos und derselben Region abzielen. Die aggregierte Größe der Elemente in der Transaktion darf 4 MB nicht überschreiten.

Die Get-Aktionen werden atomarisch durchgeführt, d. h. entweder sind alle von ihnen oder keine von ihnen erfolgreich:

• Get – Initiiert eine GetItem-Operation, um einen Satz von Attributen für das Elemente mit dem angegebenen Primärschlüssel abzurufen. Wenn kein passendes Element gefunden wird, gibt Get keine Daten zurück.

Fehlerbehandlung beim Lesen

Lesetransaktionen schlagen unter den folgenden Umständen fehl:

• Wenn eine TransactGetItems-Anforderung mit einer andauernden TransactWriteItems-Operation an mindestens einem Element in der TransactGetItems-Anforderung in Konflikt steht. In diesem Fall schlägt die Anfrage mit der Ausnahme TransactionCanceledException fehl.

• Wenn für die durchzuführende Transaktion nicht genügend Kapazität bereitgestellt wird.

• Wenn ein Benutzerfehler, wie z. B. ein ungültiges Datenformat, auftritt.

Weitere Informationen zum Umgang mit Konflikten mit TransactGetItems-Operationen finden Sie unter Handhabung von Transaktionskonflikten in DynamoDB.

Isolationsstufen für DynamoDB-Transaktionen

Die Isolationsstufen von Transaktionsoperationen (TransactWriteItems oder TransactGetItems) und anderen Operationen sind folgende:

SERIALIZABLE

Durch die Isolationsstufe serializable wird sichergestellt, dass die Ergebnisse mehrerer gleichzeitiger Operationen die gleichen sind, als würde eine Operation erst beginnen, nachdem die vorherige Operation beendet wurde.

Die serialisierbare Isolation findet zwischen den folgenden Arten von Operationen statt:

• Zwischen Transaktionsoperationen und Standardschreibvorgängen (PutItem, UpdateItem oder DeleteItem).

• Zwischen Transaktionsoperationen und Standardlesevorgängen (GetItem).

• Zwischen einer TransactWriteItems-Operation und einer TransactGetItems-Operation.

Obwohl es eine serialisierbare Isolierung zwischen Transaktionsoperationen und jedem einzelnen Standardschreibvorgang in einer BatchWriteItem Operation gibt, gibt es keine serialisierbare Isolierung zwischen der Transaktion und der BatchWriteItem Operation als Einheit.

Dementsprechend ist die Isolationsstufe zwischen einer Transaktionsoperation und einzelnen GetItems in einer BatchGetItem-Operation serialisierbar. Die Isoloationsstufe zwischen der Transaktion und der BatchGetItem-Operation als Einheit ist aber read-committed.

Eine einzelne GetItem-Anforderung kann in Bezug auf eine TransactWriteItems-Anforderung auf eine von zwei Arten serialisiert werden, entweder vor oder nach der TransactWriteItems-Anforderung. Mehrere GetItem-Anforderungen, gegen Schlüssel in einem gleichzeitigen TransactWriteItems-Anfragen können in beliebiger Reihenfolge ausgeführt werden, und daher sind die Ergebnisse read-committed.

Wenn beispielsweise GetItem-Anforderungen für Element A und Element B gleichzeitig mit einer TransactWriteItems-Anforderung ausgeführt werden, die sowohl Element A als auch Element B ändert, gibt es vier Möglichkeiten:

• Beide GetItem-Anforderungen werden vor der TransactWriteItems-Anforderung ausgeführt.

• Beide GetItem-Anforderungen werden nach der TransactWriteItems-Anforderung ausgeführt.

• GetItem-Anforderung für Element A wird vor der TransactWriteItems-Anforderung ausgeführt. Für Element B wird die GetItem nach TransactWriteItems ausgeführt.

• GetItem-Anforderung für Element B wird vor der TransactWriteItems-Anforderung ausgeführt. Für Element A wird die GetItem nach TransactWriteItems ausgeführt.

Sie sollten verwendenTransactGetItems, wenn Sie die serialisierbare Isolationsstufe für mehrere GetItem Anforderungen bevorzugen.

Wenn ein nicht-transaktionaler Lesevorgang für mehrere Elemente durchgeführt wird, die Teil derselben Transaktionsschreibanforderung waren, ist es möglich, dass Sie den neuen Status einiger Elemente und den alten Status der anderen Elemente lesen können. Sie können den neuen Status aller Elemente, die Teil der Transaktionsschreibanforderung waren, nur lesen, wenn eine erfolgreiche Antwort für den Transaktionsschreibvorgang empfangen wurde.

READ-COMMITTED

Durch die Isolation Read-committed wird sichergestellt, dass Lesevorgänge immer festgeschriebene Werte für ein Element zurückgeben – der Lesevorgang wird niemals eine Sicht auf das Element präsentieren, die einen Zustand aus einem letztlich nicht erfolgreichen transaktionalen Schreibvorgang darstellt. Die Isolation "Read-committed" verhindert keine Änderungen am Element direkt nach dem Lesevorgang.

Die Isolationsstufe ist read-committed zwischen allen Transaktionsoperationen und allen Lesevorgängen, die mehrere Standard-Lesevorgänge (BatchGetItem, Query oder Scan) umfassen. Wenn bei einem transaktionalen Schreibvorgang ein Element mitten in einer BatchGetItem-, Query- oder Scan-Operation aktualisiert wird, gibt der nachfolgende Teil des Lesevorgangs den neu festgeschriebenen Wert zurück (mit ConsistentRead) oder möglicherweise einem zuvor festgeschriebenem Wert (letztendlich konsistente Lesevorgänge).

Operationsübersicht

Die folgende Tabelle gibt einen Überblick über die Isolationsstufen zwischen einer Transaktionsoperation (TransactWriteItems oder TransactGetItems) und anderen Operationen.

Operation	Isolationsstufe
DeleteItem	Serializable
PutItem	Serializable
UpdateItem	Serializable
GetItem	Serializable
BatchGetItem	Read-committed*
BatchWriteItem	NICHT Serializable*
Query	Read-committed
Scan	Read-committed
Andere Transaktionsoperationen	Serializable

Mit einem Sternchen (*) markierte Stufen gelten für die Operation als Einheit. Einzelne Aktionen innerhalb dieser Operationen besitzen jedoch die Isolationsstufe serializable.

Handhabung von Transaktionskonflikten in DynamoDB

Bei Anforderungen auf Elementebene kann für ein Element in einer Transaktion ein Transaktionskonflikt auftreten. Transaktionskonflikte können in den folgenden Szenarien auftreten:

• Eine PutItem-, UpdateItem- oder DeleteItem-Anforderung für ein Element konfligiert mit einer laufenden TransactWriteItems-Anforderung, die dasselbe Element enthält.

• Ein Element in einer TransactWriteItems-Anforderung ist Teil einer anderen laufenden TransactWriteItems-Anforderung.

• Ein Element in einer TransactGetItems-Anforderung ist Teil einer laufenden TransactWriteItems-, BatchWriteItem-, PutItem-, UpdateItem- oder DeleteItem-Anforderung.

Anmerkung

• Wenn eine PutItem-, UpdateItem- oder DeleteItem-Anforderung abgelehnt wird, schlägt die Anforderung mit einer TransactionConflictException fehl.

• Wenn irgendeine Anforderung auf Elementebene in TransactWriteItems oder TransactGetItems abgelehnt wird, schlägt die Anforderung mit einer TransactionCanceledException fehl. Wenn diese Anforderung fehlschlägt, sendet AWS SDK keine neue Anforderung.

  Wenn Sie die verwendenAWS SDK for Java, enthält die Ausnahme die Liste von CancellationReasons, geordnet nach der Liste der Elemente im TransactItems Anforderungsparameter. Bei anderen Sprachen ist in der Fehlermeldung der Ausnahme eine Zeichenfolgendarstellung der Liste enthalten.

• Wenn eine laufende TransactWriteItems- oder TransactGetItems-Operation mit einer gleichzeitigen GetItem-Anforderung im Konflikt steht, können beide Operationen erfolgreich durchgeführt werden.

Die TransactionConflict CloudWatch Metrik wird für jede fehlgeschlagene Anforderung auf Elementebene erhöht.

Verwenden von Transaktions-APIs in DynamoDB Accelerator (DAX)

TransactWriteItems und TransactGetItems werden in DynamoDB Accelerator (DAX) mit den gleichen Isolierungsstufen wie in DynamoDB unterstützt.

TransactWriteItems schreibt über DAX. DAX übergibt eineN TransactWriteItems-Aufruf an DynamoDB und gibt die Antwort zurück. Um den Cache nach dem Schreiben aufzufüllen, ruft DAX TransactGetItems im Hintergrund für jedes Element im TransactWriteItems-Vorgang auf, wodurch zusätzliche Lesekapazitätseinheiten verbraucht werden. (Weitere Informationen finden Sie unter Kapazitätsverwaltung für Transaktionen.) Diese Funktion ermöglicht es, dass Ihre Anwendungslogik einfach bleibt. Außerdem können Sie so DAX für Transaktionsoperationen sowie für nicht transaktionale Operationen verwenden.

TransactGetItems-Aufrufe werden über DAX übergeben, ohne dass Elemente lokal zwischengespeichert werden. Dies ist das gleiche Verhalten wie bei Strongly-Consistent-Lese-APIs in DAX.

Kapazitätsverwaltung für Transaktionen

Es fallen keine zusätzlichen Kosten für das Aktivieren von Transaktionen für Ihre DynamoDB-Tabellen an. Sie zahlen nur für Lese- oder Schreibvorgänge, die Teil Ihrer Transaktion sind. DynamoDB führt zwei zugrunde liegende Lese- oder Schreibvorgänge für jedes Element in der Transaktion aus: einen zum Vorbereiten der Transaktion und einen zum Festschreiben der Transaktion. Die beiden zugrunde liegenden Lese-/Schreibvorgänge sind in Ihren Amazon- CloudWatch Metriken sichtbar.

Wenn Sie Kapazität für Ihre Tabellen bereitstellen, planen Sie zusätzliche Lese- und Schreibvorgänge ein, die für transaktionale APIs erforderlich sind. Angenommen, Ihre Anwendung führt eine Transaktion pro Sekunde aus und jede Transaktion schreibt drei 500-Byte-Elemente in Ihre Tabelle. Jedes Element erfordert zwei Schreibkapazitätseinheiten (Write Capacity Units, WCUs): eine zur Vorbereitung der Transaktion und eine zum Speichern der Transaktion mit Commit. In diesem Fall müssten Sie daher sechs WCUs für die Tabelle bereitstellen.

Wenn Sie im vorherigen Beispiel DynamoDB Accelerator (DAX) verwendet haben, nutzen Sie für jedes Element im TransactWriteItems-Aufruf auch zwei Lesekapazitätseinheiten (RCUs). In diesem Fall müssen Sie sechs zusätzliche WCUs für die Tabelle bereitstellen.

Wenn Ihre Anwendung eine Lesetransaktion pro Sekunde ausführt und jede Transaktion drei 500-Byte-Elemente in Ihrer Tabelle liest, müssen Sie der Tabelle sechs Lesekapazitätseinheiten (Read Capacity Units, RCUs) bereitstellen. Zum Lesen jedes Elements werden zwei RCUs benötigt: eine zur Vorbereitung der Transaktion und eine zum Ausführen der Transaktion.

Außerdem ist das SDK-Standardverhalten, Transaktionen im Falle der Ausnahme TransactionInProgressException wiederholt zu versuchen. Planen Sie zusätzliche Lesekapazitätseinheiten (RCUs) ein, die von diesen Wiederholversuchen verbraucht werden. Dies gilt auch, wenn Sie Transaktionen in Ihrem eigenen Code mit einem ClientRequestToken wiederholt versuchen.

Bewährte Methoden für Transaktionen

Erwägen Sie bei der Verwendung von DynamoDB-Transaktionen die folgenden empfohlenen Methoden.

• Aktivieren Sie für Ihre Tabellen das Auto Scaling oder stellen Sie sicher, dass Sie die von Ihnen bereitgestellte Durchsatzkapazität zum Ausführen der beiden Lese- oder Schreibvorgänge für jedes Element in der Transaktion ausreicht.

• Wenn Sie kein von AWS bereitgestelltes SDK verwenden, schließen Sie ein ClientRequestToken-Attribut ein, wenn Sie einen TransactWriteItems-Aufruf machen, um sicherzustellen, dass die Anforderung idempotent ist.

• Gruppieren Sie Operationen nur dann als eine Transaktion zusammen, wenn dies wirklich erforderlich ist. Beispiel: Wenn eine einzelne Transaktion mit 10 Operationen in mehrere Transaktionen aufgeteilt werden kann, ohne die korrekte Funktionsweise der Anwendung zu gefährden, wird zur Aufteilung der Transaktion geraten. Weniger komplexe Transaktionen verbessern den Durchsatz und sind mit größerer Wahrscheinlichkeit erfolgreich.

• Wenn mehrere Transaktionen dieselben Elemente gleichzeitig aktualisieren, können Konflikte entstehen, die zum Abbruch der Transaktionen führen. Wir empfehlen die folgenden bewährten DynamoDB-Methoden für die Datenmodellierung, um solche Konflikte zu minimieren.

• Wenn ein Satz von Attributen häufig im Rahmen einer einzelnen Transaktion über mehrere Elemente hinweg aktualisiert wird, empfiehlt es sich, die Attribute in einem einzigen Element zusammenzugruppieren, um den Umfang der Transaktion zu reduzieren.

• Vermeiden Sie es, Transaktionen zur massenweisen Aufnahme von Daten zu verwenden. BatchWriteItem eignet sich besser für Massenschreibvorgänge.

Verwenden von Transaktions-APIs mit globalen Tabellen

Vorgänge, die in einer DynamoDB-Transaktion enthalten sind, sind nur garantierte Transaktionen in der Region, in der die Transaktion ursprünglich ausgeführt wurde. Die Transaktionsalität wird nicht beibehalten, wenn Änderungen, die innerhalb einer Transaktion angewendet werden, regionsübergreifend auf Replikate globaler Tabellen repliziert werden.

DynamoDB-Transaktionen im Vergleich zur AWSLabs Transaktionsclientbibliothek

DynamoDB-Transaktionen bieten einen kostengünstigeren, robusteren und leistungsfähigeren Ersatz für die AWSLabs Transaktionsclientbibliothek. Wir empfehlen, Ihre Anwendungen für die Nutzung der nativen, serverseitigen Transaktions-APIs zu aktualisieren.