Fonctionnement de transactions Amazon DynamoDB - Amazon DynamoDB
TransactWriteItemsTransactGetItemsNiveaux d'isolementGestion des conflits de transactionsTransactions dans DAXGestion de capacitéBonnes pratiquesUtilisation du mode transactionnel APIs avec des tables globalesComparaison entre les transactions et la Client Library

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Fonctionnement de transactions Amazon DynamoDB

Avec les transactions Amazon DynamoDB, vous pouvez regrouper plusieurs actions et les soumettre sous forme d'une all-or-nothing TransactWriteItems seule opération. TransactGetItems Les sections suivantes décrivent les API opérations, la gestion des capacités, les meilleures pratiques et d'autres informations sur 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 au sein du AWS même compte 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 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 apportées dans le cadre de cette transaction sont propagées aux index secondaires globaux (GSIs), aux flux et aux 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.

  • Lorsque la taille d'un article devient trop importante (supérieure à 400 Ko), qu'un index secondaire local (LSI) devient trop grand ou qu'une erreur de validation similaire se produit en raison de modifications apporté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 d'un même compte et d'une AWS 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

NOTSé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, AWS SDKs ne réessayez pas.

    Si vous utilisez le AWS 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 du mode transactionnel APIs dans DynamoDB Accelerator () DAX

TransactWriteItemset TransactGetItems sont tous deux pris en charge dans DynamoDB Accelerator DAX () avec les mêmes niveaux d'isolation que dans DynamoDB.

TransactWriteItemsécrit à traversDAX. DAXpasse un TransactWriteItems appel à DynamoDB et renvoie la réponse. Pour remplir le cache après l'écriture, DAX appelez TransactGetItems en arrière-plan chaque élément de l'TransactWriteItemsopération, ce 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 conserver la logique de votre application simple et de l'utiliser à la fois DAX pour les opérations transactionnelles et non transactionnelles.

TransactGetItemsles appels sont transmis DAX sans que les éléments soient mis en cache localement. Il s'agit du même comportement que pour une lecture APIs très cohérenteDAX.

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 .

Planifiez les lectures et écritures supplémentaires requises par le protocole transactionnel APIs lorsque vous allouez de la capacité à vos tables. 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 article nécessite deux unités de capacité d'écriture (WCUs) : une pour préparer la transaction et une pour valider la transaction. Par conséquent, vous devez en fournir six WCUs à la table.

Si vous utilisiez DynamoDB Accelerator DAX () dans l'exemple précédent, vous utiliseriez également deux unités de capacité de lecture RCUs () pour chaque élément de l'appel. TransactWriteItems Vous devrez donc en prévoir six supplémentaires RCUs à 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 fournir six unités de capacité de lecture (RCUs) à la table. La lecture de chaque élément en nécessite deux RCUs : un pour préparer la transaction et un pour valider la transaction.

En outre, SDK le comportement par défaut consiste à réessayer les transactions en cas d'TransactionInProgressExceptionexception. Prévoyez les unités de capacité de lecture supplémentaires (RCUs) consommées par ces nouvelles tentatives. 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 attribut AWS fourniSDK, incluez un ClientRequestToken attribut lorsque vous effectuez un TransactWriteItems appel pour vous assurer que la demande est idempotente.

  • 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 du mode transactionnel APIs 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 vous suggérons de mettre à jour vos applications pour utiliser la transaction native côté serveur. APIs