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 au contrôle de 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. Ce processus d'évaluation des conflits de temps d'engagement est également appelé adjudication. Lorsqu'Aurora DSQL détecte un conflit, il renvoie un échec de sérialisation 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 réponse OC000 :
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é sur la version actuelle, la transaction reçoit la réponse OC001 :
ERROR: schema has been updated by another transaction (OC001) (SQLSTATE 40001)Toute opération modifiant le catalogue de schémas peut provoquer une réponse OC001, y compris des instructions DDL telles que
CREATE TABLEetALTER TABLE, ainsiGRANTque des instructions et.REVOKEPour de plus amples informations, veuillez consulter Transactions DDL et distribuées dans Aurora DSQL.
Concevez vos applications de manière à implémenter une logique de nouvelle tentative pour 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.
Types de conflits de données
Grâce au mécanisme de contrôle de simultanéité d'Aurora DSQL, les SELECT ... FOR KEY SHARE clauses SELECT ... FOR
UPDATE and produisent des résultats grâce à une détection des conflits optimiste au moment de la validation plutôt qu'au verrouillage. Dans Aurora DSQL, lorsqu'une transaction écrit une ligne et qu'une autre la lit avec l'une des clauses précédentes, un conflit peut apparaître au moment de la validation en fonction des colonnes utilisées par les transactions. Les clauses suivantes déterminent la manière dont Aurora DSQL détecte ces conflits.
Définition de la colonne clé
Les colonnes clés sont des colonnes qui font partie d'un index unique, non partiel et sans expression. Toutes les autres colonnes ne sont pas des colonnes clés.
SELECT ... FOR UPDATE-
Déclare qu'Aurora DSQL évalue les lignes sélectionnées comme si la transaction y écrivait. Si une autre transaction est
UPDATEexécutéeDELETESELECT ... FOR UPDATE, ouSELECT ... FOR KEY SHAREsur la même ligne et qu'elle est validée en premier, la transaction exécutéeSELECT ... FOR UPDATEéchoue avec uneOC000réponse. Cette clause entre en conflit avec toute écriture simultanée sur la ligne et avec lesFOR KEY SHARElecturesFOR UPDATEsimultanées. SELECT ... FOR KEY SHARE-
Déclare que la transaction dépend des colonnes clés des lignes sélectionnées. Si une autre transaction supprime la ligne, modifie ses colonnes clés ou est exécutée
SELECT ... FOR UPDATEet validée en premier, la transaction exécutéeSELECT ... FOR KEY SHAREéchoue avec uneOC000réponse. Une colonneUPDATEconcurrente avec une colonne non clé n'entre pas en conflit.
Aurora DSQL ne prend pas en charge les FOR SHARE clauses NO KEY UPDATE or. Cependant, DML utilise implicitement ce mécanisme. NO KEY UPDATE Le tableau suivant récapitule les situations dans lesquelles deux transactions simultanées qui accèdent à la même ligne entrent en conflit. An X indique que les deux opérations sont en conflit : la dernière transaction validée échoue avec une OC000 réponse. Une cellule vide indique que les deux transactions peuvent être validées.
| Opération | INSERT,DELETE, UPDATE (colonnes clés), ou SELECT ... FOR UPDATE |
UPDATE(colonnes non clés uniquement) |
SELECT ... FOR KEY SHARE |
|---|---|---|---|
INSERT,DELETE, UPDATE (colonnes clés), ou SELECT ... FOR UPDATE |
X | X | X |
UPDATE(colonnes non clés uniquement) |
X | X | |
SELECT ... FOR KEY SHARE |
X |
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.
