Einführung in Transaktionsisolationsebenen

Stell dir vor, du arbeitest in einem Café, wo ein Kellner den Kuchenbestand in der Küche prüft und ein anderer gerade eine Kuchenbestellung von einem neuen Gast aufnimmt. In einer idealen Welt sollten beide mit denselben Daten über die Anzahl der Kuchen arbeiten, damit Fehler wie "doppelte Reservierung" vermieden werden. Aber in der echten Welt können Probleme durch parallele Ausführung von Operationen auftreten.

Hier sind drei Hauptprobleme, die passieren können:

1. Dirty Read (Schmutziges Lesen): Eine Abfrage sieht Änderungen, die von einer anderen gemacht wurden, aber noch nicht bestätigt sind. Wenn diese Änderungen zurückgerollt werden, steht die erste Abfrage so naiv da wie ein Student beim ersten Vorstellungsgespräch.

2. Non-Repeatable Read (Nicht wiederholbares Lesen): Eine Abfrage liest dieselben Daten zweimal, aber dazwischen hat jemand anderes sie geändert. Das ist wie am Bahnhof das Zugfahrplan anschauen, eine Minute später zurückkommen – und feststellen, dass der Zug gestrichen wurde. Oder dein Ticket wurde verkauft, während du nach dem Geld gesucht hast :)

3. Phantom Read (Phantomlesen): Eine Abfrage sieht eine Teilmenge von Zeilen, aber zwischen zwei Ausführungen fügt jemand neue Zeilen hinzu, die das Ergebnis beeinflussen. Das ist, als ob deine Firma eine Ausschreibung verliert und dann alle Bewerbungen außer deiner und der Bewerbung der Bürgermeistergattin storniert werden.

Transaktionsisolationsebenen

Jetzt, wo wir die Probleme kennen, schauen wir uns das Werkzeug an, das PostgreSQL zur Lösung bietet – Transaktionsisolationsebenen. Das ist wie das Festlegen von Regeln für das Zusammenspiel paralleler Transaktionen. Je höher die Isolationsebene, desto mehr Garantien, dass Transaktionen sich nicht gegenseitig stören. Dafür zahlt man aber mit weniger "Bedienungsgeschwindigkeit", sprich Performance.

Isolationsebenen in PostgreSQL

1. Read Uncommitted (Lesen nicht bestätigter Daten):

   • Erlaubt das Lesen von Änderungen, die noch nicht bestätigt wurden (ja, das ist Dirty Read in Reinform).
   • In PostgreSQL ist dieses Level eigentlich als Read Committed implementiert, also wird es nicht wirklich unterstützt. PostgreSQL weigert sich, es zu implementieren, weil dieser Ansatz zu unsicher ist.

2. Read Committed (Lesen bestätigter Änderungen):

   • Verhindert Dirty Read.
   • Eine Transaktion sieht nur die Daten, die zum Zeitpunkt der Ausführung ihres Befehls bestätigt wurden.
   • Allerdings sind Non-Repeatable Read und Phantom Read möglich.

3. Repeatable Read (Wiederholbares Lesen):

   • Garantiert, dass die gelesenen Daten während der Transaktion unverändert bleiben.
   • Verhindert Dirty Read und Non-Repeatable Read.
   • Phantomzeilen sind aber immer noch möglich.

4. Serializable (Serialisierbar):

   • Garantiert, dass Transaktionen so ausgeführt werden, als ob sie nacheinander, eine nach der anderen, laufen würden.
   • Verhindert alle drei Probleme: Dirty Read, Non-Repeatable Read und Phantomzeilen.
   • Das strengste – und langsamste – Isolationslevel.

Warum ist Transaktionsisolation wichtig?

Stell dir jetzt eine Datenbank eines Online-Shops vor, in dem tausend Nutzer:innen gleichzeitig eine Bestellung aufgeben wollen. Ohne richtig eingestelltes Isolationslevel kann es zu massiven Konflikten kommen: von "verschwundenen" Produkten bis zu doppelten Bestellungen.

Die Wahl des richtigen Isolationslevels hilft, mit konkurrierenden Transaktionen klarzukommen und das Gleichgewicht zwischen Performance und Datenintegrität zu halten. Zum Beispiel:

• In Analysesystemen wählt man oft minimale Isolationsebenen (z.B. Read Committed), weil die Genauigkeit der Daten nicht immer kritisch ist.
• In Finanzsystemen ist Serializable bevorzugt, um Fehler bei Berechnungen oder doppelte Buchungen zu vermeiden.

Anwendungsbeispiele für Isolationsebenen

1. Read Committed

Dieses Level stellt sicher, dass du niemals Daten liest, die zurückgerollt werden könnten.

SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
BEGIN;

-- Kontodaten lesen.
SELECT balance FROM accounts WHERE account_id = 1;

-- Wenn eine andere Transaktion das Guthaben aktualisiert, werden diese Daten sofort aktualisiert.
UPDATE accounts SET balance = balance - 100 WHERE account_id = 1;

COMMIT;

2. Repeatable Read

Dieses Level garantiert, dass wenn du Daten liest, sie für dich während der gesamten Transaktion unverändert bleiben.

SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;
BEGIN;

-- Kontodaten lesen.
SELECT balance FROM accounts WHERE account_id = 1;

-- Selbst wenn eine andere Transaktion dieses Guthaben aktualisiert, siehst du die Änderung nicht.
UPDATE accounts SET balance = balance - 100 WHERE account_id = 1;

COMMIT;

3. Serializable

Auf diesem Level arbeitet die Transaktion so, als wäre sie die einzige im System.

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
BEGIN;

-- Kontodaten lesen.
SELECT balance FROM accounts WHERE account_id = 1;

-- Jede andere Transaktion, die versucht, diese Daten zu ändern, wird blockiert, bis deine Transaktion abgeschlossen ist.
UPDATE accounts SET balance = balance - 100 WHERE account_id = 1;

COMMIT;

Wie wählt man das Isolationslevel?

Die Wahl des Isolationslevels hängt von deinen Anforderungen ab:

• Wenn Geschwindigkeit wichtiger als Genauigkeit ist und du mit Phantomzeilen leben kannst – nimm Read Committed.
• Wenn Genauigkeit wichtig ist, aber du trotzdem hohe Performance willst – nutze Repeatable Read.
• Wenn du 100% Korrektheit der Daten brauchst, auch wenn es langsamer wird – dann passt Serializable.

Sei vorsichtig! Strenge Isolationsebenen können zu Sperren und Performance-Einbußen führen. Eine kluge Entscheidung ist ein Kompromiss zwischen Performance und Datenkonsistenz.

2

Aufgabe

SQL SELF, Level 39, Lektion 4

Gesperrt

Setze das Isolationslevel für eine Transaktion

Setze das Isolationslevel für eine Transaktion

Öffnen

1

Umfrage/Quiz

Einführung in Transaktionen, Level 39, Lektion 4

Nicht verfügbar

Einführung in Transaktionen

Einführung in Transaktionen

Öffnen