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.
Contrôle de simultanéité dans Aurora DSQL
La simultanéité permet à plusieurs sessions d’accéder aux données et de les modifier simultanément sans compromettre l’intégrité et la cohérence des données. Aurora DSQL assure la compatibilité avec PostgreSQL tout en mettant en œuvre un mécanisme de contrôle de simultanéité moderne et sans verrou. Aurora DSQL assure une conformité totale à ACID grâce à l’isolement des instantanés, garantissant ainsi la cohérence et la fiabilité des données.
L’un des principaux avantages d’Aurora DSQL est son architecture sans verrou, qui élimine les problèmes courants liés aux performances des bases de données. Aurora DSQL empêche les transactions lentes de bloquer d’autres opérations et élimine le risque de blocages. Cette approche rend Aurora DSQL particulièrement utile pour les applications à haut débit où les performances et la capacité de mise à l’échelle sont essentielles.
Réponses de contrôle de la simultanéité
Aurora DSQL utilise un contrôle de simultanéité optimiste (OCC), qui fonctionne différemment des systèmes traditionnels basés sur des verrous. Au lieu d’utiliser des verrous, l’OCC évalue les conflits au moment de la validation. Lorsqu'Aurora DSQL détecte un conflit, il renvoie un échec de sérialisation de PostgreSQL avec le code SQLSTATE. 40001 Le message de réponse inclut un code OCC qui identifie le type de conflit :
- OC000 — Conflit de données
-
Deux transactions ont tenté de modifier la même ligne. La transaction dont l'heure de validation est la plus proche aboutit et la transaction en conflit reçoit la OC000 réponse suivante :
ERROR: change conflicts with another transaction (OC000) (SQLSTATE 40001) - OC001 — Conflit de schéma
-
Le catalogue de schémas mis en cache de la session est obsolète. Lorsqu'Aurora DSQL détecte que la version du catalogue a changé depuis que la session a chargé son cache et que la transaction ne peut pas être rebasée en toute sécurité vers la version actuelle, la transaction reçoit la OC001 réponse :
ERROR: schema has been updated by another transaction (OC001) (SQLSTATE 40001)Toute opération modifiant le catalogue de schémas peut provoquer une OC001 réponse, y compris les instructions DDL telles que les instructions
CREATE TABLEetALTER TABLE, ainsi que les instructionsGRANTetREVOKE. Pour de plus amples informations, veuillez consulter Transactions DDL et distribuées dans Aurora DSQL.
Concevez vos applications pour implémenter une logique de nouvelle tentative afin de gérer ces réponses. Le modèle de conception idéal est idempotent, permettant une nouvelle tentative de transaction comme premier recours dans la mesure du possible. La logique recommandée est similaire à la logique d’abandon et de nouvelle tentative dans une situation de blocage ou de temporisation standard de PostgreSQL. Cependant, l’OCC exige que vos applications appliquent cette logique plus fréquemment.
Directives pour optimiser les performances des transactions
Pour optimiser les performances, réduisez les risques de conflits sur des clés uniques ou sur de petites plages de clés. Pour atteindre cet objectif, concevez votre schéma de manière à répartir les mises à jour sur l’ensemble de votre plage de clés de cluster en suivant les directives suivantes :
-
Choisissez une clé primaire aléatoire pour vos tables.
-
Évitez les modèles qui accroissent le risque de conflit sur les clés individuelles. Cette approche garantit des performances optimales même lorsque le volume des transactions augmente.
