トランザクションセマンティクス

Redshift Iceberg 書き込みクエリは、ACID とスナップショットの分離をサポートします。書き込みトランザクションはアトミック性が保証されており、クエリが予期せず失敗しても部分的な更新は生成されません。

複数の Iceberg トランザクションを同時に実行でき、2 つのトランザクションが同じテーブルまたはパーティションを同時に変更しようとすると、トランザクションコミットは失敗します。これにより、データの整合性が確保されます。この場合、競合を手動で解決し、失敗したクエリを再実行する必要があります。Amazon Redshift は、競合を自動的に再試行して解決しません。

単一の Iceberg 書き込みクエリは常に単一の自動コミットトランザクションとして扱われます。CREATE クエリや INSERT クエリなどの Iceberg 書き込みクエリが明示的なトランザクションブロックに含まれている場合、同じトランザクションブロック内で他のクエリを実行することはできません。トランザクションは失敗します。

次に例をいくつか示します。最初の例は、単一のステートメントクエリがクエリの完了後に常に自動コミットすることを示しています。このシナリオでは、新しい受注テーブルを作成します。

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

この例は、S3 テーブルバケットの 3 つの部分からなる表記を使用して顧客注文を挿入するための明示的なトランザクションブロックです。トランザクションは INSERT クエリの後に自動コミットしませんが、代わりに COMMIT コマンドを使用して注文データをコミットして挿入します。

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

この例は、明示的なトランザクションブロックのロールバックシナリオで、注文挿入をテストしているが、キャンセルすることを決定しています。トランザクションは INSERT クエリの後に自動コミットしませんが、代わりにテスト注文を挿入せずに ROLLBACK コマンドでロールバックします。

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

この最後の例は、INSERT クエリと同じトランザクションブロック内で別のステートメントを実行しようとすると、注文データを挿入せずにトランザクションが失敗する様子を示しています。このシナリオでは、注文を挿入し、すぐにテーブルにクエリを実行しようとしています。

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

この唯一の例外は DROP TABLE ステートメントです。これは常に自動コミットステートメントとして動作し、明示的なトランザクションブロック内で実行することはできません。これは、外部テーブルの DROP TABLE と同じ動作を維持するためです。詳細については、「DROP TABLE」を参照してください。