Semántica de transacciones

Las consultas de escritura de Redshift Iceberg admiten ACID y el aislamiento de instantáneas. Las transacciones de escritura tienen una atomicidad garantizada y no producen actualizaciones parciales cuando una consulta produce un error de forma inesperada.

Se pueden ejecutar varias transacciones de Iceberg al mismo tiempo y, si dos transacciones intentan modificar la misma tabla o partición al mismo tiempo, se produce un error en la confirmación de la transacción. Esto garantiza la integridad de los datos. Cuando esto ocurre, debe resolver los conflictos manualmente y volver a ejecutar las consultas erróneas. Amazon Redshift no vuelve a intentar resolver los conflictos automáticamente.

Una sola consulta de escritura de Iceberg siempre se trata como una única transacción de confirmación automática. Cuando una consulta de escritura de Iceberg, como una consulta CREATE o INSERT, se incluye en un bloque de transacciones explícito, no se pueden ejecutar otras consultas dentro del mismo bloque de transacciones. La transacción producirá un error.

A continuación, se muestran algunos ejemplos: El primer ejemplo demuestra que la consulta de una sola instrucción siempre se confirma automáticamente una vez finalizada la consulta. En este escenario, crea una nueva tabla de pedidos de ventas:

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/';

Este ejemplo es un bloque de transacciones explícito para insertar un pedido de un cliente mediante notación de tres partes para un bucket de tabla de S3. La transacción no se confirma automáticamente después de la consulta INSERT, sino que confirma e inserta los datos del pedido con el comando COMMIT:

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

Este ejemplo es un escenario de reversión explícita de un bloque de transacciones en el que está probando la inserción de un pedido pero decide cancelarlo. La transacción no se confirma automáticamente después de la consulta INSERT, sino que se revierte con el comando ROLLBACK sin insertar la orden de prueba.

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

Este último ejemplo demuestra cómo, cuando se intenta ejecutar otra instrucción dentro del mismo bloque de transacciones que la consulta INSERT, la transacción produce un error sin insertar los datos del pedido. En este escenario, está intentando insertar un pedido e inmediatamente consultar la tabla:

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

La única excepción a esto es la instrucción DROP TABLE, que siempre se comporta como una instrucción de confirmación automática y no se puede ejecutar dentro de un bloque de transacciones explícito. Esto es para mantener el mismo comportamiento que DROP TABLE en una tabla externa. Para obtener más información, consulte DROP TABLE.