Semântica de transação

As consultas de gravação do Redshift Iceberg comportam ACID e isolamento de snapshot. As transações de gravação têm atomicidade garantida e não produzem atualizações parciais quando uma consulta falha inesperadamente.

Várias transações do Iceberg podem ser executadas simultaneamente e, se duas transações tentarem modificar a mesma tabela ou partição simultaneamente, a confirmação da transação falhará. Isso garante a integridade dos dados. Quando isso acontece, você deve resolver os conflitos manualmente e executar novamente as consultas com falha. O Amazon Redshift não tenta resolver automaticamente os conflitos novamente.

Uma única consulta de gravação do Iceberg é sempre tratada como uma única transação de confirmação automática. Quando uma consulta de gravação do Iceberg, como a consulta CREATE ou INSERT, é incluída em um bloco de transação explícito, nenhuma outra consulta pode ser executada no mesmo bloco de transação. A transação falhará.

Veja a seguir alguns exemplos: O primeiro exemplo demonstra que uma única consulta de instrução sempre é confirmada automaticamente após o término da consulta. Neste cenário, você está criando uma tabela de pedidos de venda:

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 exemplo é um bloco de transação explícito para inserir um pedido de cliente usando a notação em três partes para um bucket de tabelas do S3. A transação não é confirmada automaticamente após a consulta INSERT, mas confirma e insere os dados do pedido com o comando COMMIT:

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

Este exemplo é um cenário explícito de reversão do bloco de transações em que você está testando a inserção de um pedido, mas decide cancelá-la. A transação não é confirmada automaticamente após a consulta INSERT, mas é revertida com o comando ROLLBACK sem inserir o pedido de teste.

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

Este exemplo final demonstra como, quando você tenta executar outra instrução dentro do mesmo bloco de transação da consulta INSERT, a transação falha sem inserir os dados do pedido. Neste cenário, você está tentando inserir um pedido e consultar imediatamente a tabela:

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

A única exceção a isso é a instrução DROP TABLE, que sempre se comporta como uma instrução de confirmação automática e não pode ser executada em um bloco de transação explícito. O objetivo disso é manter o mesmo comportamento que DROP TABLE em uma tabela externa. Consulte mais informações em DROP TABLE.