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.
Meilleures pratiques pour gérer les mises à jour simultanées dans DynamoDB
Dans les systèmes distribués, plusieurs processus ou utilisateurs peuvent tenter de modifier les mêmes données en même temps. Sans contrôle de la simultanéité, ces écritures simultanées peuvent entraîner des pertes de mises à jour, des données incohérentes ou des conditions de course. DynamoDB propose plusieurs mécanismes pour vous aider à gérer les accès simultanés et à préserver l'intégrité des données.
Note
Les opérations d'écriture individuelles, telles que UpdateItem les opérations atomiques, fonctionnent toujours sur la version la plus récente de l'élément, quelle que soit la simultanéité. Des stratégies de verrouillage sont nécessaires lorsque votre application doit lire un élément puis le réécrire en fonction de la valeur lue (un read-modify-write cycle), car un autre processus pourrait modifier l'élément entre la lecture et l'écriture.
Il existe deux stratégies principales pour gérer les mises à jour simultanées :
-
Verrouillage optimiste : suppose que les conflits sont rares. Il permet un accès simultané et détecte les conflits au moment de l'écriture à l'aide d'écritures conditionnelles. Si un conflit est détecté, l'écriture échoue et l'application peut réessayer.
-
Verrouillage pessimiste : suppose que des conflits sont probables. Il empêche l'accès simultané en acquérant un accès exclusif à une ressource avant de la modifier. Les autres processus doivent attendre que le verrou soit déverrouillé.
Le tableau suivant récapitule les approches disponibles dans DynamoDB :
| Approche | Mécanisme | Idéal pour |
|---|---|---|
| Verrouillage optimiste | Attribut de version + écritures conditionnelles | Faible contention, nouvelles tentatives peu coûteuses |
| Verrouillage pessimiste (transactions) | TransactWriteItems |
Atomicité multi-objets, contention modérée |
| Verrouillage pessimiste (client de verrouillage) | Table verrouillée dédiée avec durée et battement de cœur | Flux de travail de longue durée, coordination distribuée |
Choisir une stratégie de contrôle de la simultanéité
Suivez les directives suivantes pour choisir l'approche adaptée à votre charge de travail :
- Utilisez le verrouillage optimiste lorsque :
-
Les conflits sont rares.
Réessayer une écriture qui a échoué est peu coûteux.
Vous mettez à jour un seul élément à la fois.
- Utilisez des transactions lorsque :
-
Vous devez mettre à jour plusieurs éléments de manière atomique.
Vous avez besoin d'une all-or-nothing sémantique entre les éléments ou les tables.
Vous devez combiner les vérifications d'état avec les écritures en une seule opération.
- Utilisez le client de verrouillage lorsque :
-
Vous devez coordonner l'accès aux ressources externes dans le cadre des processus distribués.
La section critique est longue et il est coûteux de réessayer de résoudre un conflit.
Vous avez besoin d'une expiration automatique du verrouillage pour gérer les défaillances du processus.
Note
Si vous utilisez des tables globales DynamoDB, sachez que les tables globales utilisent une stratégie de réconciliation selon laquelle « le dernier rédacteur gagne » pour les mises à jour simultanées. Le verrouillage optimiste avec des numéros de version ne fonctionne pas comme prévu dans toutes les régions, car une écriture dans une région peut remplacer une écriture simultanée dans une autre région sans vérification de version. Concevez votre application de manière à gérer les conflits au niveau de l'application lorsque vous utilisez des tables globales.
