Semantica delle transazioni

Le query di scrittura di Redshift Iceberg supportano l'isolamento ACID e snapshot. Le transazioni di scrittura hanno un'atomicità garantita e non producono aggiornamenti parziali quando una query fallisce in modo imprevisto.

È possibile eseguire più transazioni Iceberg contemporaneamente e se due transazioni tentano di modificare la stessa tabella o partizione contemporaneamente, il commit della transazione fallisce. Ciò garantisce l'integrità dei dati. Quando ciò accade, è necessario risolvere i conflitti manualmente ed eseguire nuovamente le query non riuscite. Amazon Redshift non riprova e risolve automaticamente i conflitti.

Una singola query di scrittura Iceberg viene sempre trattata come una singola transazione di commit automatico. Quando una query di scrittura Iceberg, come la query CREATE o INSERT, è inclusa in un blocco di transazione esplicito, nessun'altra query può essere eseguita all'interno dello stesso blocco di transazione. La transazione fallirà.

Di seguito vengono riportati alcuni esempi. Il primo esempio dimostra che una query con una singola istruzione esegue sempre il commit automatico al termine della query. In questo scenario, stai creando una nuova tabella degli ordini di vendita:

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

Questo esempio è un blocco di transazione esplicito per l'inserimento di un ordine del cliente utilizzando una notazione in tre parti per un bucket di tabella S3. La transazione non esegue il commit automatico dopo la query INSERT, ma esegue invece il commit e inserisce i dati dell'ordine con il comando COMMIT:

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

Questo esempio è uno scenario esplicito di rollback del blocco delle transazioni in cui stai testando l'inserimento di un ordine ma decidi di annullarlo. La transazione non esegue il commit automatico dopo la query INSERT, ma viene invece ripristinata con il comando ROLLBACK senza inserire l'ordine di test.

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

Questo ultimo esempio dimostra come, quando si tenta di eseguire un'altra istruzione all'interno dello stesso blocco di transazione della query INSERT, la transazione fallisce senza inserire i dati dell'ordine. In questo scenario, state tentando di inserire un ordine e interrogare immediatamente la tabella:

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

L'unica eccezione è l'DROP TABLEistruzione, che si comporta sempre come un'istruzione di commit automatico e non può essere eseguita all'interno di un blocco di transazione esplicito. Questo serve a mantenere lo stesso comportamento di una tabella DROP TABLE esterna. Per ulteriori informazioni, consulta DROP TABLE.