Sémantique des transactions

Les requêtes d'écriture Redshift Iceberg prennent en charge l'isolation ACID et les instantanés. Les transactions d'écriture garantissent l'atomicité et ne produisent pas de mises à jour partielles en cas d'échec inattendu d'une requête.

Plusieurs transactions Iceberg peuvent s'exécuter simultanément, et si deux transactions tentent de modifier simultanément la même table ou partition, la validation de la transaction échoue. Cela garantit l'intégrité des données. Dans ce cas, vous devez résoudre les conflits manuellement et réexécuter les requêtes ayant échoué. Amazon Redshift ne réessaie pas automatiquement de résoudre les conflits.

Une seule requête d'écriture Iceberg est toujours traitée comme une seule transaction de validation automatique. Lorsqu'une requête d'écriture Iceberg, telle qu'une requête CREATE ou INSERT, est incluse dans un bloc de transaction explicite, aucune autre requête ne peut être exécutée dans le même bloc de transaction. La transaction échouera.

Voici quelques exemples. Le premier exemple montre qu'une seule requête d'instruction est toujours validée automatiquement une fois la requête terminée. Dans ce scénario, vous créez une nouvelle table de commandes client :

CREATE TABLE sales_schema.orders (
    order_id int, 
    customer_id int, 
    order_date date, 
    total_amount decimal(10,2)
) USING ICEBERG LOCATION 's3://my-data-lake/sales/orders/';

Cet exemple est un bloc de transaction explicite permettant d'insérer une commande client à l'aide d'une notation en trois parties pour un compartiment de table S3. La transaction n'est pas validée automatiquement après la requête INSERT, mais valide et insère les données de commande à l'aide de la commande COMMIT :

BEGIN;
INSERT INTO "analytics_bucket@s3tablescatalog".sales_db.orders VALUES (12345, 9876, '2024-10-30', 299.99);
COMMIT; 

Cet exemple est un scénario explicite d'annulation d'un bloc de transactions dans lequel vous testez l'insertion d'une commande mais décidez de l'annuler. La transaction n'est pas validée automatiquement après la requête INSERT, mais est annulée à l'aide de la commande ROLLBACK sans insérer l'ordre de test.

BEGIN;
INSERT INTO sales_schema.orders VALUES (12346, 5432, '2024-10-30', 150.75);
ROLLBACK; 

Ce dernier exemple montre comment, lorsque vous essayez d'exécuter une autre instruction dans le même bloc de transaction que la requête INSERT, la transaction échoue sans insérer les données de commande. Dans ce scénario, vous essayez d'insérer une commande et d'interroger immédiatement la table :

BEGIN;
INSERT INTO sales_schema.orders VALUES (12347, 7890, '2024-10-30', 425.50);
SELECT * FROM sales_schema.orders WHERE order_id = 12347;

La seule exception à cette règle est l'DROP TABLEinstruction, qui se comporte toujours comme une instruction de validation automatique et ne peut pas être exécutée dans un bloc de transaction explicite. Cela permet de conserver le même comportement que DROP TABLE sur une table externe. Pour plus d'informations, consultez DROP TABLE.