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. Il assure une conformité totale à l'ACID grâce à l'isolation 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 l'évolutivité sont essentielles.
Conflits de transactions
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, OCC évalue les conflits au moment de la validation. Lorsque plusieurs transactions entrent en conflit lors de la mise à jour de la même ligne, Aurora DSQL gère les transactions comme suit :
-
La transaction dont l'heure de validation est la plus proche est traitée par Aurora DSQL.
-
Les transactions en conflit reçoivent une erreur de sérialisation PostgreSQL, indiquant la nécessité d'une nouvelle tentative.
Concevez vos applications de manière à implémenter une logique de nouvelle tentative afin de gérer les conflits. 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 contention élevés sur des touches uniques ou sur de petites plages de touches. 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 la contention sur les touches individuelles. Cette approche garantit des performances optimales même lorsque le volume des transactions augmente.
