Semantik von Transaktionen

Redshift Iceberg-Schreibabfragen unterstützen ACID und Snapshot-Isolation. Schreibtransaktionen haben garantierte Atomarität und führen nicht zu teilweisen Aktualisierungen, wenn eine Abfrage unerwartet fehlschlägt.

Es können mehrere Iceberg-Transaktionen gleichzeitig ausgeführt werden. Wenn zwei Transaktionen versuchen, dieselbe Tabelle oder Partition gleichzeitig zu ändern, schlägt der Transaktions-Commit fehl. Dadurch wird die Datenintegrität gewährleistet. In diesem Fall müssen Sie die Konflikte manuell lösen und die fehlgeschlagenen Abfragen erneut ausführen. Amazon Redshift versucht nicht automatisch erneut, die Konflikte zu lösen.

Eine einzelne Iceberg-Schreibabfrage wird immer als eine einzelne Auto-Commit-Transaktion behandelt. Wenn eine Iceberg-Schreibabfrage, wie z. B. eine CREATE- oder INSERT-Abfrage, in einem expliziten Transaktionsblock enthalten ist, können keine anderen Abfragen innerhalb desselben Transaktionsblocks ausgeführt werden. Die Transaktion wird fehlschlagen.

Im Folgenden sind einige Beispiele aufgeführt. Das erste Beispiel zeigt, dass eine Abfrage mit einer einzelnen Anweisung immer automatisch festgeschrieben wird, nachdem die Abfrage beendet wurde. In diesem Szenario erstellen Sie eine neue Tabelle mit Verkaufsaufträgen:

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

Dieses Beispiel ist ein expliziter Transaktionsblock zum Einfügen einer Kundenbestellung in dreiteiliger Notation für einen S3-Tabellen-Bucket. Die Transaktion führt nach der INSERT-Abfrage kein automatisches Commit durch, sondern schreibt die Bestelldaten mit dem COMMIT-Befehl fest und fügt sie ein:

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

Dieses Beispiel ist ein explizites Rollback-Szenario für Transaktionsblöcke, in dem Sie eine Auftragserteilung testen, diese aber stornieren möchten. Die Transaktion wird nach der INSERT-Abfrage nicht automatisch festgeschrieben, sondern stattdessen mit dem ROLLBACK-Befehl zurückgesetzt, ohne die Testreihenfolge einzufügen.

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

Dieses letzte Beispiel zeigt, dass, wenn Sie versuchen, eine weitere Anweisung innerhalb desselben Transaktionsblocks wie die INSERT-Abfrage auszuführen, die Transaktion fehlschlägt, ohne dass die Bestelldaten eingefügt werden. In diesem Szenario versuchen Sie, eine Bestellung einzufügen und sofort die Tabelle abzufragen:

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

Die einzige Ausnahme ist die DROP TABLE Anweisung, die sich immer wie eine Auto-Commit-Anweisung verhält und nicht innerhalb eines expliziten Transaktionsblocks ausgeführt werden kann. Damit soll das gleiche Verhalten wie bei einer externen Tabelle DROP TABLE beibehalten werden. Weitere Informationen finden Sie unter DROP TABLE.