Amazon Redshift ne prendra plus en charge la création de nouveaux Python UDFs à compter du 1er novembre 2025. Si vous souhaitez utiliser Python UDFs, créez la version UDFs antérieure à cette date. Le Python existant UDFs continuera à fonctionner normalement. Pour plus d’informations, consultez le billet de blog
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.
Niveaux d’isolement dans Amazon Redshift
Les opérations d’écriture simultanées sont prises en charge dans Amazon Redshift de manière protective, à l’aide de verrous d’écriture sur les tables et du principe d’isolement sérialisable. L’isolement sérialisable préserve l’illusion qu’une transaction s’exécutant sur une table est la seule transaction qui soit en cours d’exécution sur cette table.
Les bases de données Amazon Redshift prennent en charge les opérations d’écriture simultanées en faisant en sorte que chaque opération utilise la dernière version validée, ou instantané, de ses données au début de la transaction. Un instantané de base de données est créé au sein d’une transaction sur la première occurrence de la plupart des instructions SELECT, des commandes DML telles que COPY, DELETE, INSERT, UPDATE et TRUNCATE, et des commandes DDL suivantes :
ALTER TABLE (pour ajouter ou supprimer des colonnes)
CREATE TABLE
DROP TABLE
TRUNCATE TABLE
Aucune autre transaction ne peut modifier cet instantané, ce qui signifie que les transactions sont isolées les unes des autres. Les transactions simultanées sont donc invisibles les unes aux autres ; elles ne peuvent pas détecter les modifications de chacune d’elles.
Toute exécution simultanée de transactions doit produire les mêmes résultats que l’exécution en série de ces transactions. Si aucune exécution en série de ces transactions ne peut produire les mêmes résultats, la transaction qui exécute une instruction qui pourrait interrompre la mise en série est arrêtée et annulée.
Supposons, par exemple, qu’un utilisateur tente d’exécuter deux transactions simultanées, T1 et T2. L’exécution de T1 et de T2 doit produire les mêmes résultats comme dans l’un des scénarios suivants :
-
T1 et T2 sont exécutées en série dans cet ordre.
-
T2 et T1 sont exécutées en série dans cet ordre.
Les niveaux d’isolement d’Amazon Redshift permettent d’éviter les problèmes suivants :
Lectures corrompues : une lecture corrompue se produit lorsqu’une transaction lit des données qui n’ont pas encore été validées. Supposons, par exemple, que la transaction 1 mette à jour une ligne. La transaction 2 lit la ligne mise à jour avant que T1 ne valide la mise à jour. Si T1 annule la modification, T2 aura lu des données dans des lignes non validées qu’Amazon Redshift considère désormais comme n’ayant jamais existé.
Lectures non répétables : une lecture non répétable se produit lorsqu’une seule transaction lit deux fois la même ligne mais obtient des données différentes à chaque fois. Supposons, par exemple, que la transaction 1 lise une ligne. La transaction 2 met à jour ou supprime cette ligne et valide la mise à jour ou la suppression. Si T1 relit la ligne, il récupère différentes valeurs de ligne ou découvre que la ligne a été supprimée.
Fantômes : un fantôme est une ligne qui correspond aux critères de recherche mais qui n’est pas initialement visible. Supposons, par exemple, que la transaction 1 lise un ensemble de lignes répondant à ses critères de recherche. La transaction 2 génère une nouvelle ligne dans une instruction UPDATE ou INSERT qui correspond aux critères de recherche de T1. Si T1 réexécute son instruction de recherche, elle obtient un ensemble de lignes différent.
Isolement SNAPSHOT et SERIALIZABLE
Dans les bases de données Amazon Redshift, l’isolement SERIALIZABLE et SNAPSHOT sont des types de niveau d’isolement sérialisable.
L’isolement SNAPSHOT est le niveau d’isolement par défaut lors de la création de clusters alloués et de groupes de travail sans serveur, ce qui vous permet de traiter des volumes de données plus importants que l’isolement SERIALIZABLE en moins de temps.
L’isolement SERIALIZABLE prend plus de temps, mais implémente des contraintes plus strictes sur les transactions simultanées. Ce niveau d’isolement permet d’éviter les problèmes tels que les anomalies de distorsion d’écriture en autorisant la validation d’une seule transaction, tout en annulant toutes les autres transactions simultanées présentant une erreur de violation d’isolement sérialisable.
Voici un exemple chronologique de la façon dont deux opérations d’écriture simultanées seraient gérées lors de l’utilisation de l’isolement SNAPSHOT. L’instruction UPDATE de chaque utilisateur est autorisée à être validée car elle n’entre pas en conflit en tentant de mettre à jour les mêmes lignes.
| Heure | Action utilisateur 1 | Action utilisateur 2 |
|---|---|---|
| 1 | BEGIN; | |
| 2 | BEGIN; | |
| 3 | SELECT * FROM Numbers; digits ------ 0 1 |
|
| 4 | SELECT * FROM Numbers; digits ------ 0 1 |
|
| 5 | UPDATE Numbers SET digits=0 WHERE digits=1; | |
| 6 | SELECT * FROM Numbers; digits ------ 0 0 |
|
| 7 | COMMIT; | |
| 8 | Update Numbers SET digits=1 WHERE digits=0; | |
| 9 | SELECT * FROM Numbers; digits ------ 1 1 |
|
| 10 | COMMIT; | |
| 11 | SELECT * FROM Numbers; digits ------ 1 0 |
|
| 12 | SELECT * FROM Numbers; digits ------ 1 0 |
Si le même scénario est exécuté à l’aide d’une isolation sérialisable, Amazon Redshift met fin à l’utilisateur 2 en raison d’une violation sérialisable et renvoie une erreur 1023. Pour plus d’informations, consultez Résolution des problèmes d’isolation sérialisable. Dans ce cas, seul l’utilisateur 1 peut s’engager avec succès.
Considérations
Lorsque vous utilisez les niveaux d’isolement dans Amazon Redshift, prenez en considération les éléments suivants :
Interrogez la vue du catalogue STV_DB_ISOLATION_LEVEL pour afficher le niveau d’isolement utilisé par votre base de données. Pour plus d’informations, consultez STV_DB_ISOLATION_LEVEL.
Interrogez la vue PG_DATABASE_INFO pour savoir combien de transactions simultanées sont prises en charge pour votre base de données. Pour plus d’informations, consultez PG_DATABASE_INFO.
Les tables catalogue système (PG) et autres tables système Amazon Redshift ne sont pas verrouillées dans une transaction. Par conséquent, les modifications apportées aux objets de base de données qui proviennent d’opérations DDL et TRUNCATE sont visibles lors de la validation de transactions simultanées.
Par exemple, supposons que cette table A existe dans la base de données lorsque deux transactions simultanées, T1 et T2, démarrent. Supposons que T2 renvoie une liste de tables en les sélectionnant dans la table de catalogue PG_TABLES. Ensuite, T1 supprime la table A et valide la suppression, puis T2 affiche les tables à nouveau. La table A n’apparaît plus dans la liste. Si T2 essaie d’interroger la table supprimée, Amazon Redshift renvoie une erreur indiquant que la relation n’existe pas. La requête de catalogue qui renvoie la liste des tables à T2 ou vérifie que la table A existe n’est pas soumise aux mêmes règles d’isolement que les opérations réalisées sur les tables de l’utilisateur.
Les transactions pour les mises à jour de ces tables s’exécutent dans un mode d’isolement validé en lecture.
Les tables de catalogue préfixées par PG ne prennent pas en charge l’isolement SNAPSHOT.
