Fonctionnement de transactions Amazon DynamoDB

Avec les transactions Amazon DynamoDB, vous pouvez regrouper plusieurs actions et les soumettre en une all-or-nothing TransactWriteItems seule opération. TransactGetItems Les sections suivantes décrivent les opérations d'API, la gestion de la capacité, les bonnes pratiques et d'autres détails concernant l'utilisation des opérations transactionnelles dans DynamoDB.

TransactWriteItems API

TransactWriteItemsest une opération d'écriture synchrone et idempotente qui regroupe jusqu'à 100 actions d'écriture en une seule opération. all-or-nothing Ces actions peuvent cibler jusqu'à 100 éléments distincts dans une ou plusieurs tables DynamoDB sur le même compte AWS et dans la même région. La taille d'agrégation des éléments dans la transaction ne peut pas dépasser 4 Mo. Les actions sont exécutées de manière atomique, de sorte qu'elles réussissent toutes ou aucune ne réussit.

Note

• Une opération TransactWriteItems diffère d'une opération BatchWriteItem en ceci que toutes les actions qui y sont contenues doivent réussir, faute de quoi aucune modification du tout n'est apportée. Avec une opération BatchWriteItem, il est possible que certaines actions du lot seulement réussissent, alors que d'autres échouent.

• Les transactions ne peuvent pas être effectuées au moyen d'index

Vous ne pouvez pas cibler le même élément avec plusieurs opérations contenues dans la même transaction. Par exemple, vous ne pouvez pas effectuer un ConditionCheck et une action Update sur le même élément de la même transaction.

Vous pouvez ajouter les types d'actions suivants à une transaction :

• Put – Lance une opération PutItem pour créer un élément ou remplacer un ancien élément par un nouveau, de manière conditionnelle ou sans spécifier de condition.

• Update – Lance une opération UpdateItem pour modifier les attributs d'un élément existant, ou ajouter un élément à la table s'il n'existe pas. Utilisez cette action pour ajouter, supprimer ou mettre à jour des attributs d'un élément existant, avec ou sans conditions.

• Delete – Lance une opération DeleteItem pour supprimer un élément unique d'une table identifiée par sa clé primaire.

• ConditionCheck – Vérifie l'existence d'un élément ou l'état d'attributs spécifiques de celui-ci.

Une fois qu'une transaction est terminée, les modifications effectuées avec la transaction sont propagées vers les index secondaires globaux (GSI), les flux et les sauvegardes. Comme la propagation n'est ni immédiate ni instantanée, si une table est restaurée à partir de backup (RestoreTableFromBackup) ou exportée à un point dans le temps (ExportTableToPointInTime) au milieu de la propagation, elle peut contenir certaines des modifications apportées lors d'une transaction récente, mais pas toutes.

Idempotence

En option, vous pouvez inclure un jeton client lorsque vous faites un appel TransactWriteItems afin de garantir l'idempotence de la demande. Des transactions idempotentes évitent des erreurs d'application si la même opération est soumise plusieurs fois suite à une expiration de la connexion ou à tout autre problème de connectivité.

Si l'appel initial de TransactWriteItems réussit, les appels suivants de TransactWriteItems avec le même jeton client aboutissent sans apporter aucune modification. Si le paramètre ReturnConsumedCapacity est défini, l'appel TransactWriteItems initial renvoie le nombre d'unités de capacité en écriture consommées par l'exécution de ces modifications. Les appels TransactWriteItems subséquents avec le même jeton client renvoient le nombre d'unités de capacité en lecture consommées par la lecture de l'élément.

Considérations importantes concernant l'idempotence

• Un jeton client est valide pendant 10 minutes après la fin de la demande qui l'utilise. Après 10 minutes, toute demande utilisant le même jeton client est traitée comme une nouvelle demande. Évitez donc ce réutiliser le même jeton client pour la même demande après 10 minutes.

• Si vous répétez une demande avec le même jeton client dans la fenêtre d'idempotence de 10 minutes, mais modifiez un autre paramètre de demande, DynamoDB renvoie une exception IdempotentParameterMismatch.

Gestion des erreurs d'écriture

Les transactions d'écriture échouent dans les conditions suivantes :

• Lorsqu'une condition d'une des expressions de condition n'est pas remplie.

• Lorsqu'une erreur de validation de la transaction se produit parce que plusieurs actions de la même opération TransactWriteItems ciblent le même élément.

• Lorsqu'une demande TransactWriteItems est en conflit avec une opération TransactWriteItems en cours sur un ou plusieurs éléments dans la demande TransactWriteItems. Dans ce cas, la demande échoue avec une exception TransactionCanceledException.

• Lorsque la capacité allouée est insuffisante pour achever la transaction.

• Lorsqu'un élément devient trop volumineux (plus de 400 ko), qu'un index secondaire local (LSI) devient trop volumineux ou qu'une erreur de validation similaire se produit en raison de modifications effectuées par la transaction.

• En cas d'erreur de la part de l'utilisateur, par exemple un format de données incorrect.

Pour obtenir plus de détails sur la gestion des conflits avec les opérations TransactWriteItems, consultez Gestion des conflits de transactions dans DynamoDB.

TransactGetItems API

TransactGetItems est une opération de lecture synchrone qui regroupe jusqu'à 100 actions Get. Ces actions peuvent cibler jusqu'à 100 éléments distincts dans une ou plusieurs tables DynamoDB au sein du même compte AWS et de la même région. La taille d'agrégation des éléments dans la transaction ne peut pas dépasser 4 Mo.

Les actions Get sont exécutées de manière atomique, de sorte qu'elles réussissent toutes ou échouent toutes.

• Get – Lance une opération GetItem afin d'extraire un ensemble d'attributs pour l'élément avec la clé primaire donnée. Si aucun élément correspondant n'est trouvé, Get ne renvoie pas de données.

Gestion des erreurs de lecture

Les transactions de lecture échouent dans les conditions suivantes :

• Lorsqu'une demande TransactGetItems est en conflit avec une opération TransactWriteItems en cours sur un ou plusieurs éléments dans la demande TransactGetItems. Dans ce cas, la demande échoue avec une exception TransactionCanceledException.

• Lorsque la capacité allouée est insuffisante pour achever la transaction.

• En cas d'erreur de la part de l'utilisateur, par exemple un format de données incorrect.

Pour obtenir plus de détails sur la gestion des conflits avec les opérations TransactGetItems, consultez Gestion des conflits de transactions dans DynamoDB.

Niveaux d'isolement pour les transactions DynamoDB

Les niveaux d'isolement des opérations transactionnelles (TransactWriteItems ou TransactGetItems) et autres opérations sont les suivants.

SERIALIZABLE

Un isolement sérialisable assure que les résultats de plusieurs opérations concourantes sont les mêmes que si aucune opération ne commençait avant que la précédente soit terminée.

Il y a un isolement sérialisable entre les types d'opérations suivants :

• Entre toute opération transactionnelle et toute opération d'écriture standard (PutItem, UpdateItem ou DeleteItem).

• Entre toute opération transactionnelle et toute opération de lecture standard (GetItem).

• Entre une opération TransactWriteItems et une opération TransactGetItems.

Bien qu'il existe une isolation sérialisable entre les opérations transactionnelles et chaque écriture standard individuelle dans une BatchWriteItem opération, il n'existe aucune isolation sérialisable entre la transaction et l'BatchWriteItemopération en tant qu'unité.

De même, le niveau d'isolation entre une opération transactionnelle et un GetItems dans une opération BatchGetItem est sérialisable. Mais le niveau d'isolation entre la transaction et l'opération BatchGetItem en tant qu'unité est read-committed.

Un demande GetItem unique est sérialisable par rapport à une demande TransactWriteItems de deux façons, avant ou après la demande TransactWriteItems. Plusieurs demandes GetItem par rapport à des clés dans une demande TransactWriteItems simultanée peuvent s'exécuter dans n'importe quel ordre. C'est pourquoi les résultats sont validés en lecture.

Par exemple, si des demandes GetItem pour des éléments A et B sont exécutées en même temps qu'une demande TransactWriteItems qui modifie les éléments A et B, il y a quatre possibilités :

• Les deux demandes GetItem sont exécutées avant la demande TransactWriteItems.

• Les deux demandes GetItem sont exécutées après la demande TransactWriteItems.

• La demande GetItem pour l'élément A est exécutée avant la demande TransactWriteItems. Pour l'élément B, la demande GetItem est exécutée après la demande TransactWriteItems.

• La demande GetItem pour l'élément B est exécutée avant la demande TransactWriteItems. Pour l'élément A, la demande GetItem est exécutée après la demande TransactWriteItems.

Vous devez l'utiliser TransactGetItems si vous préférez un niveau d'isolation sérialisable pour plusieurs GetItem demandes.

Si une lecture non transactionnelle est effectuée sur plusieurs éléments faisant partie de la même demande d'écriture de transaction en cours de vol, il est possible que vous puissiez lire le nouvel état de certains éléments et l'ancien état des autres éléments. Vous ne pourrez lire le nouvel état de tous les éléments inclus dans la demande d'écriture de transaction que lorsqu'une réponse satisfaisante sera reçue pour l'écriture transactionnelle.

READ-COMMITTED

L'isolement validé en lecture garantit que les opérations de lecture renvoient toujours des valeurs validées pour un élément. La lecture ne présentera jamais une vue de l'élément représentant un état issu d'une écriture transactionnelle qui n'a pas abouti. Un isolement validé en lecture n'empêche pas des modifications de l'élément juste après la lecture.

Le niveau d'isolement est validé en lecture entre toute opération transactionnelle et toute opération de lecture impliquant plusieurs lectures standard (BatchGetItem, Query ou Scan). Si une écriture transactionnelle met à jour un élément au milieu d'une opération BatchGetItem, Query ou Scan, la partie suivante de l'opération de lecture renvoie la valeur nouvellement validée (avec ConsistentRead) ou éventuellement une valeur déjà validée (lectures éventuellement cohérentes).

Résumé des opérations

Pour résumer, le tableau qui suit montre les niveaux d'isolement entre une opération transactionnelle (TransactWriteItems ou TransactGetItems) et d'autres opérations :

Opération	Niveau d'isolement
DeleteItem	Sérialisable
PutItem	Sérialisable
UpdateItem	Sérialisable
GetItem	Sérialisable
BatchGetItem	Validé en lecture*
BatchWriteItem	NON sérialisable*
Query	Validé en lecture
Scan	Validé en lecture
Autre opération transactionnelle	Sérialisable

Les niveaux marqués d'un astérisque (*) s'appliquent à l'opération dans son ensemble. Toutefois, les actions individuelles au sein de ces opérations ont un niveau d'isolement sérialisable.

Gestion des conflits de transactions dans DynamoDB

Un conflit transactionnel peut se produire lors de demandes simultanées au niveau de l'élément sur un élément au sein d'une transaction. Les conflits de transaction peuvent se produire dans les scénarios suivants :

• Une requête PutItem, UpdateItem ou DeleteItem pour un élément est en conflit avec une requête TransactWriteItems en cours qui inclut le même élément.

• Un élément au sein d'une requête TransactWriteItems fait partie d'une autre requête TransactWriteItems en cours.

• Un élément au sein d'une requête TransactGetItems fait partie d'une autre requête TransactWriteItems, BatchWriteItem, PutItem, UpdateItem ou DeleteItem en cours.

Note

• Quand une requête PutItem, UpdateItem ou DeleteItem est rejetée, la requête échoue avec un code TransactionConflictException.

• Si toute requête au niveau de l'élément au sein de TransactWriteItems ou TransactGetItems est rejetée, la requête échoue avec un code TransactionCanceledException. Si cette demande échoue, les kits SDL AWS ne relancent pas la demande.

  Si vous utilisez leAWS SDK for Java, l'exception contient la liste de CancellationReasons, ordonnée en fonction de la liste des éléments du paramètre de TransactItems demande. Pour d'autres langues, une représentation sous forme de chaîne de la liste est incluse dans le message d'erreur de l'exception.

• Si une opération TransactWriteItems en cours ou une opération TransactGetItems est en conflit avec une demande GetItem concourante, les deux opérations peuvent réussir.

La TransactionConflict CloudWatch métrique est incrémentée pour chaque demande échouée au niveau de l'élément.

Utilisation d'API transactionnelles dans DynamoDB Accelerator (DAX)

Les demandes TransactWriteItems et TransactGetItems sont toutes deux prises en charge dans DynamoDB Accelerator (DAX) avec les mêmes niveaux d'isolement que dans DynamoDB.

La demande TransactWriteItems écrit via DAX. DAX transmet un appel TransactWriteItems à DynamoDB et renvoie la réponse. Pour remplir le cache après l'écriture, DAX appelle TransactGetItems en arrière-plan pour chaque élément dans l'opération TransactWriteItems, qui consomme des unités de capacité de lecture supplémentaires. (Pour plus d’informations, consultez Gestion de capacité pour les transactions.) Cette fonctionnalité vous permet de simplifier la logique de votre application et d'utiliser DAX pour les opérations transactionnelles et non transactionnelles.

Les appels TransactGetItems sont transmis via DAX sans les éléments mis en cache localement. Ce comportement est le même que pour les API de lecture fortement cohérentes dans DAX.

Gestion de capacité pour les transactions

L'activation des transactions pour vos tables DynamoDB n'occasionne pas de frais supplémentaires . Vous ne payez que pour les lectures ou écritures qui font partie de votre transaction. DynamoDB effectue deux lectures ou écritures sous-jacentes de chaque élément faisant partie de la transaction : l'une pour préparer la transaction, l'autre pour la valider. Les deux opérations de lecture/écriture sous-jacentes sont visibles dans vos statistiques Amazon CloudWatch .

Lors de l'allocation de capacité à vos tables, prévoyez les lectures et écritures supplémentaires qu'exigent les API transactionnelles. Par exemple, supposons que votre application exécute une transaction par seconde et que chaque transaction écrit trois éléments de 500 octets dans votre table. Chaque élément exige deux unités de capacité en écriture (WCU) : une pour préparer la transaction et une pour la valider. Par conséquent, vous devez allouer six WCU à la table.

Si vous avez utilisé DynamoDB Accelerator (DAX) dans l'exemple précédent, vous devez également utiliser deux unités de capacité de lecture pour chaque élément dans l'appel TransactWriteItems. Par conséquent, vous devez allouer six unités de capacité en lecture à la table.

De même, si votre application exécute une transaction de lecture par seconde et que chaque transaction lit trois éléments de 500 octets dans votre table, vous devez allouer six unités de capacité de lecture à la table. La lecture de chaque élément exige deux RCU : une pour préparer la transaction et une pour la valider.

En outre, le comportement par défaut du SDK est de ressayer les transactions en cas d'exception TransactionInProgressException. Prévoyez les unités supplémentaires de capacité en lecture (RCU) que ces nouvelles tentatives consommeront. Il en va de même si vous ressayez des transactions dans votre propre code à l'aide d'un ClientRequestToken.

Bonnes pratiques en matière de transactions

Lorsque vous utilisez des transactions DynamoDB, prenez en compte les bonnes pratiques recommandées suivantes.

• Activez la scalabilité automatique sur vos tables ou veillez à allouer suffisamment de capacité de débit pour effectuer les deux opérations de lecture et écriture pour chaque élément de votre transaction.

• Si vous n'utilisez pas un kit SDK fourni par AWS, ajoutez un attribut ClientRequestToken lorsque vous faites un appel TransactWriteItems afin de garantir l'idempotence de la demande.

• Ne regroupez pas d'opérations en une transaction si ce n'est pas nécessaire. Par exemple, si une transaction unique avec 10 opérations peut être subdivisée en plusieurs transactions sans compromettre l'exactitude de l'application, nous recommandons de scinder la transaction. Des transactions plus simples améliorent le débit et sont plus susceptibles de réussir.

• Si plusieurs transactions mettent à jour simultanément les mêmes éléments, il peut y avoir des conflits qui annulent ces transactions. Nous recommandons de suivre les bonnes pratiques DynamoDB en matière de modélisation des données pour minimiser de tels conflits.

• Si un ensemble d'attributs est souvent mis à jour sur plusieurs éléments dans le cadre d'une seule et même transaction, envisagez de regrouper les attributs dans un seul élément afin de réduire la portée de la transaction.

• Évitez d'utiliser des transactions pour ingérer des données en masse. Pour les écritures en masse, il est préférable d'utiliser BatchWriteItem.

Utilisation des API transactionnelles avec des tables globales

Les opérations contenues dans une transaction DynamoDB ne sont garanties comme transactionnelles que dans la région où la transaction a été initialement exécutée. La transactionnalité n'est pas préservée lorsque les modifications appliquées au sein d'une transaction sont répliquées entre les régions sur des répliques de tables globales.

Transactions DynamoDB par rapport à la bibliothèque cliente de transactions AWSLabs

Les transactions DynamoDB constituent un remplacement plus rentable, plus robuste et plus performant de AWSLabsla bibliothèque cliente de transactions. Nous suggérons de mettre à jour vos applications pour utiliser les API natives de transactions côté serveur.