Sémantique des transactions

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

Plusieurs transactions Iceberg peuvent être exécutées simultanément, et si deux transactions tentent de modifier la même table ou la même partition simultanément, 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 qui ont é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 transactions. La transaction échouera.

Voici quelques exemples. Le premier exemple montre qu'une requête à instruction unique est toujours validée automatiquement une fois la requête terminée. Dans ce scénario, vous créez un nouveau tableau des 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 en utilisant une notation en trois parties pour un compartiment de table S3. La transaction ne se valide pas automatiquement après la requête INSERT, mais valide et insère les données de la 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 ne se valide pas automatiquement après la requête INSERT, mais revient en arrière à 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 insertion des 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, voir DROP TABLE.