Amazon DynamoDB Transactions: Funktionsweise - Amazon-DynamoDB
TransactWriteItemsTransactGetItemsIsolationsstufenHandhabung von TransaktionskonfliktenTransaktionen in DAXKapazitätsverwaltungBewährte MethodenVerwenden Sie transaktionale Tabellen APIs mit globalen TabellenTransaktionen im Vergleich mit Client Library

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.

Amazon DynamoDB Transactions: Funktionsweise

Mit Amazon DynamoDB-Transaktionen können Sie mehrere Aktionen gruppieren und sie als einzelne all-or-nothing TransactWriteItems oder TransactGetItems Operation einreichen. In den folgenden Abschnitten werden API Abläufe, Kapazitätsmanagement, bewährte Methoden und weitere Details zur Verwendung von Transaktionsoperationen in DynamoDB beschrieben.

TransactWriteItems API

TransactWriteItemsist ein synchroner und idempotenter Schreibvorgang, der bis zu 100 Schreibaktionen in einem einzigen Vorgang gruppiert. all-or-nothing Diese Aktionen können auf bis zu 100 verschiedene 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 innerhalb dieser Transaktion vorgenommenen Änderungen an globale sekundäre Indizes (GSIs), Streams und Backups weitergegeben. Da die Weitergabe nicht unmittelbar oder unmittelbar erfolgt, kann eine Tabelle, wenn sie aus Backup (RestoreTableFromBackup) wiederhergestellt oder zu einem Zeitpunkt (ExportTableToPointInTime) während der Propagierung exportiert wird, einige, aber nicht alle Änderungen enthalten, die während einer kürzlich durchgeführten Transaktion vorgenommen wurden.

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 ein lokaler sekundärer Index (LSI) zu groß wird oder aufgrund von Änderungen, die durch die Transaktion vorgenommen wurden, 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 verschiedene 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.

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

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 die serialisierbare Isolationsstufe für mehrere Anfragen verwendenTransactGetItems, wenn Sie eine serialisierbare Isolationsstufe bevorzugen. GetItem

Wenn mehrere Elemente, die während der Übertragung Teil derselben Transaktionsschreibanfrage waren, nicht transaktionell gelesen werden, 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 transaktionalen Schreibvorgang eingegangen ist.

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

NOTSerialisierbar *

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 Anfrage fehlschlägt, versuchen AWS SDKs Sie die Anfrage nicht erneut.

    Wenn Sie den verwenden AWS SDK for Java, enthält die Ausnahme die Liste der CancellationReasons, sortiert 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 Anfrage auf Elementebene inkrementiert.

Verwenden von Transactional APIs in DynamoDB Accelerator () DAX

TransactWriteItemsund TransactGetItems werden beide in DynamoDB Accelerator (DAX) mit den gleichen Isolationsstufen wie in DynamoDB unterstützt.

TransactWriteItemsschreibt durch. DAX DAXleitet einen TransactWriteItems Aufruf an DynamoDB weiter und gibt die Antwort zurück. Um den Cache nach dem Schreibvorgang aufzufüllen, werden TransactGetItems im DAX Hintergrund für jedes Element des TransactWriteItems Vorgangs aufgerufen, wodurch zusätzliche Lesekapazitätseinheiten verbraucht werden. (Weitere Informationen finden Sie unter Kapazitätsverwaltung für Transaktionen.) Diese Funktionalität ermöglicht es Ihnen, Ihre Anwendungslogik einfach zu halten und sie sowohl DAX für transaktionale als auch für nicht transaktionale Operationen zu verwenden.

TransactGetItemsAufrufe werden weitergeleitet, DAX ohne dass die Elemente lokal zwischengespeichert werden. Dies ist dasselbe Verhalten wie beim stark konsistenten EinlesenAPIs. 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 CloudWatch Amazon-Metriken sichtbar.

Planen Sie die zusätzlichen Lese- und Schreibvorgänge ein, die für Transaktionen erforderlich sind, APIs wenn Sie Kapazität für Ihre Tabellen bereitstellen. Angenommen, Ihre Anwendung führt eine Transaktion pro Sekunde aus und jede Transaktion schreibt drei 500-Byte-Elemente in Ihre Tabelle. Für jedes Element sind zwei Schreibkapazitätseinheiten (WCUs) erforderlich: eine für die Vorbereitung der Transaktion und eine für den Commit der Transaktion. Daher müssten Sie sechs für WCUs die Tabelle bereitstellen.

Wenn Sie im vorherigen Beispiel DynamoDB Accelerator (DAX) verwenden würden, würden Sie auch zwei Lesekapazitätseinheiten (RCUs) für jedes Element im TransactWriteItems Aufruf verwenden. Sie müssten also sechs weitere RCUs 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üssten Sie der Tabelle entsprechend sechs Lesekapazitätseinheiten (RCUs) bereitstellen. Zum Lesen jedes Elements sind zwei erforderlichRCUs: eine für die Vorbereitung der Transaktion und eine für die Ausführung der Transaktion.

Außerdem besteht SDK das Standardverhalten darin, Transaktionen im TransactionInProgressException Ausnahmefall erneut zu versuchen. Planen Sie die zusätzlichen Lesekapazitätseinheiten (RCUs) ein, die diese Wiederholungen verbrauchen. 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 AWS bereitgestelltes verwendenSDK, fügen Sie bei einem TransactWriteItems Aufruf ein ClientRequestToken Attribut hinzu, um sicherzustellen, dass die Anfrage 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 Sie transaktionale Tabellen APIs mit globalen Tabellen

Operationen, die in einer DynamoDB-Transaktion enthalten sind, sind nur in der Region garantiert, in der die Transaktion ursprünglich ausgeführt wurde. Die Transaktionalität wird nicht gewahrt, wenn innerhalb einer Transaktion vorgenommene Änderungen regionsübergreifend in globale Tabellenreplikate repliziert werden.

DynamoDB-Transaktionen im Vergleich zur AWSLabs Transactions-Clientbibliothek

DynamoDB-Transaktionen bieten einen kostengünstigeren, robusteren und leistungsfähigeren Ersatz für die AWSLabsTransactions-Clientbibliothek. Wir empfehlen Ihnen, Ihre Anwendungen so zu aktualisieren, dass sie die native, serverseitige Transaktion verwenden. APIs