Amazon Redshift wird UDFs ab dem 1. November 2025 die Erstellung von neuem Python nicht mehr unterstützen. Wenn Sie Python verwenden möchten UDFs, erstellen Sie das UDFs vor diesem Datum liegende. Bestehendes Python UDFs wird weiterhin wie gewohnt funktionieren. Weitere Informationen finden Sie im Blog-Posting
Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Isolierungsstufen in Amazon Redshift
Gleichzeitige Schreiboperationen werden in Amazon Redshift auf geschützte Art unterstützt, indem Schreibsperren für Tabellen und der Grundsatz der serialisierbaren Isolierung angewendet werden. Die serialisierbare Isolierung bewahrt die Illusion, dass eine Transaktion, die für eine Tabelle ausgeführt wird, die einzige Transaktion ist, die für diese Tabelle ausgeführt wird.
Amazon-Redshift-Datenbanken unterstützen gleichzeitige Schreiboperationen, indem jede Operation die neueste übergebene Version bzw. den neuesten übergebenen Snapshot ihrer Daten zu Beginn der Transaktion verwendet. Innerhalb der Transaktion wird beim ersten Auftreten der meisten SELECT-Anweisungen, von DML-Befehlen wie COPY, DELETE, INSERT, UPDATE und TRUNCATE und der folgenden DDL-Befehle ein Datenbank-Snapshot erstellt:
ALTER TABLE (Hinzufügen oder Entfernen von Spalten)
CREATE TABLE
DROP TABLE
TRUNCATE TABLE
Keine andere Transaktion kann diesen Snapshot ändern. Das bedeutet, dass Transaktionen voneinander isoliert sind. Gleichzeitige Transaktionen können sich gegenseitig nicht sehen, d. h., sie können die Änderungen der jeweils anderen Transaktionen nicht erkennen.
Eine gleichzeitige Ausführung von Transaktionen muss zu denselben Ergebnissen führen wie die serielle Ausführung dieser Transaktionen. Wenn keine serielle Ausführung dieser Transaktionen dieselben Ergebnisse produziert, wird die Transaktion abgebrochen, die eine Anweisung ausführt, die die Serialisierbarkeit verhindern würde. Für diese Transaktion wird ein Rollback ausgeführt.
Angenommen, ein Benutzer versucht, zwei gleichzeitige Transaktionen auszuführen, T1 und T2. Die Ausführung von T1 und T2 muss zu denselben Ergebnissen führen wie in mindestens einem der folgenden Szenarien:
-
T1 und T2 werden seriell in dieser Reihenfolge ausgeführt.
-
T2 und T1 werden seriell in dieser Reihenfolge ausgeführt.
Isolierungsstufen in Amazon Redshift verhindern die folgenden Probleme:
Fehlerhafte Leseoperationen: Eine fehlerhafte Leseoperation tritt auf, wenn eine Transaktion Daten liest, die noch nicht übergeben wurden. Angenommen, Transaktion 1 aktualisiert eine Zeile. Transaktion 2 liest die aktualisierte Zeile, bevor T1 die Aktualisierung übergibt. Wenn T1 die Änderung rückgängig macht, hat T2 Daten in nicht übergebenen Zeilen gelesen, für die Amazon Redshift jetzt annimmt, dass sie nie existiert haben.
Nicht wiederholbare Leseoperationen: Eine nicht wiederholbare Leseoperation tritt auf, wenn eine einzelne Transaktion dieselbe Zeile zweimal liest, aber jedes Mal andere Daten erhält. Angenommen, Transaktion 1 liest eine Zeile. Transaktion 2 aktualisiert oder löscht diese Zeile und übergibt die Aktualisierung oder Löschung. Wenn T1 die Zeile erneut liest, ruft sie andere Zeilenwerte ab oder stellt fest, dass die Zeile gelöscht wurde.
Phantome: Ein Phantom ist eine Zeile, die den Suchkriterien entspricht, aber zunächst nicht sichtbar ist. Angenommen, Transaktion 1 liest eine Reihe von Zeilen, die ihren Suchkriterien entsprechen. Transaktion 2 generiert eine neue Zeile in einer UPDATE- oder INSERT-Anweisung, die den Suchkriterien für T1 entspricht. Wenn T1 ihre Suchanweisung erneut ausführt, erhält sie einen anderen Satz von Zeilen.
SNAPSHOT- und SERIALIZABLE-Isolierung
SNAPSHOT und SERIALIZABLE sind die beiden serialisierbaren Isolierungsstufen, die in Amazon Redshift verfügbar sind.
Die SNAPSHOT-Isolierung ist die Standard-Isolierungsstufe bei der Erstellung von bereitgestellten Clustern und Serverless-Arbeitsgruppen, sodass Sie größere Datenmengen als bei der SERIALIZABLE-Isolierung in kürzerer Zeit verarbeiten können.
Die SERIALIZABLE-Isolierung nimmt mehr Zeit in Anspruch, implementiert jedoch strengere Einschränkungen für gleichzeitige Transaktionen. Diese Isolierungsstufe verhindert Probleme wie Schreibverzerrungsanomalien, da nur jeweils eine Transaktion übergeben werden kann, während alle anderen gleichzeitigen Transaktionen mit einem Fehler wegen Verletzung der serialisierbaren Isolierung abgebrochen werden.
Im Folgenden finden Sie ein Timeline-Beispiel dafür, wie zwei gleichzeitige Schreiboperationen bei Verwendung der SNAPSHOT-Isolierung behandelt würden. Die UPDATE-Anweisung jedes Benutzers darf einen Commit ausführen, da es nicht zu Konflikten kommt, wenn versucht wird, dieselben Zeilen zu aktualisieren.
| Zeit | Aktion von Benutzer 1 | Aktion von Benutzer 2 |
|---|---|---|
| 1 | BEGIN; | |
| 2 | BEGIN; | |
| 3 | SELECT * FROM Numbers; digits ------ 0 1 |
|
| 4 | SELECT * FROM Numbers; digits ------ 0 1 |
|
| 5 | UPDATE Numbers SET digits=0 WHERE digits=1; | |
| 6 | SELECT * FROM Numbers; digits ------ 0 0 |
|
| 7 | COMMIT; | |
| 8 | Update Numbers SET digits=1 WHERE digits=0; | |
| 9 | SELECT * FROM Numbers; digits ------ 1 1 |
|
| 10 | COMMIT; | |
| 11 | SELECT * FROM Numbers; digits ------ 1 0 |
|
| 12 | SELECT * FROM Numbers; digits ------ 1 0 |
Wenn dasselbe Szenario mit serialisierbarer Isolation ausgeführt wird, beendet Amazon Redshift Benutzer 2 aufgrund einer serialisierbaren Verletzung und gibt den Fehler 1023 zurück. Weitere Informationen finden Sie unter Beheben von Fehlern für die serialisierbare Isolierung. In diesem Fall kann nur Benutzer 1 einen erfolgreichen Commit ausführen.
Überlegungen
Berücksichtigen Sie bei der Verwendung von Isolierungsstufen in Amazon Redshift Folgendes:
Fragen Sie die Katalogansicht STV_DB_ISOLATION_LEVEL ab, um zu sehen, welche Isolierungsstufe Ihre Datenbank verwendet. Weitere Informationen finden Sie unter STV_DB_ISOLATION_LEVEL.
Fragen Sie die Ansicht PG_DATABASE_INFO ab, um zu sehen, wie viele gleichzeitige Transaktionen für Ihre Datenbank unterstützt werden. Weitere Informationen finden Sie unter PG_DATABASE_INFO.
Systemkatalogtabellen (PG) und andere Amazon-Redshift-Systemtabellen sind in einer Transaktion nicht gesperrt. Daher sind Änderungen an Datenbankobjekten, die aufgrund von DDL- und TRUNCATE-Transaktionen entstanden sind, beim Commit für alle gleichzeitigen Transaktionen erkennbar.
Angenommen, Tabelle A ist in der Datenbank vorhanden, wenn zwei gleichzeitige Transaktionen, T1 und T2, gestartet werden. Angenommen, T2 gibt eine Liste von Tabellen zurück, indem Sie aus der Katalogtabelle PG_TABLES auswählen. Dann löscht T1 Tabelle A und Commits, und dann listet T2 die Tabellen erneut auf. Tabelle A ist jetzt nicht mehr aufgeführt. Wenn T2 versucht, eine Abfrage für die entfernte Tabelle auszuführen, gibt Amazon Redshift den Fehler „Beziehung nicht vorhanden“ zurück. Die Katalogabfrage, die die Liste von Tabellen an T2 zurückgibt oder überprüft, ob Tabelle A vorhanden ist, unterliegt nicht denselben Isolierungsregeln wie Operationen in Benutzertabellen.
Transaktionen für Aktualisierungen dieser Tabellen werden im Isolierungsmodus read committed ausgeführt.
PG-prefix-Katalogtabellen unterstützen die SNAPSHOT-Isolierung nicht.
