Atomarität in Datenbanken: Das Rückgrat für verlässliche Transaktionen

Atomarität ist ein zentrales Konzept in Datenbanksystemen. Das bedeutet, dass eine Transaktion entweder vollständig gelingen oder gar nicht ausgeführt werden muss. Wenn irgendetwas auf halbem Weg scheitert, wird die ganze Sache rückgängig gemacht, als wäre sie nie passiert.

Warum ist das so wichtig, fragst du? Stell dir vor, du überweist Geld von einem Bankkonto auf ein anderes. Du drückst auf "Senden", die App wird eine Sekunde lang geladen und dann geht etwas schief. Das Geld verschwindet von deinem Konto, landet aber nie auf dem anderen. Jetzt ist es einfach... weg. Dieses Szenario ist genau das, was die Atomisierung verhindern soll.

Vielleicht hast du schon einmal von ACID gehört. Es handelt sich dabei um eine Reihe von vier Schlüsseleigenschaften, die Datenbanken nutzen, um sicherzustellen, dass die Dinge nicht auseinanderfallen. Atomarität steht auf dieser Liste an erster Stelle, und das aus gutem Grund: Ohne sie ist der Rest (Konsistenz, Isolation und Langlebigkeit) nicht viel wert.

In diesem Artikel erfahren wir, was Atomarität bedeutet, wie sie funktioniert und warum sie für alltägliche Systeme wie Banken und E-Commerce so wichtig ist. Wir schauen uns auch an, wie verschiedene Datenbanken dies umsetzen und wie du atomare Systeme entwerfen kannst, die gut damit umgehen können, wenn sie unvermeidlich schiefgehen.

Was ist Atomarität?

Atomarität bedeutet, dass eine Transaktion in einer Datenbank unteilbar ist. Entweder läuft er bis zum Ende, wobei jeder einzelne Schritt nach Plan verläuft, oder er läuft überhaupt nicht. Es gibt kein Dazwischen. Keine halbfertigen Updates, keine unvollständig gespeicherten Daten, kein seltsamer Schwebezustand, in dem einige Dinge gelungen sind und andere nicht.

Atomarität in DBMS. Quelle: Arpit Bhayani

Wenn ein Teil der Transaktion fehlschlägt, wird die gesamte Transaktion zurückgesetzt, als wäre nie etwas passiert. Das macht die Atomkraft zu einem so mächtigen Schutz. Ohne sie würdest du ständig Gefahr laufen, deine Daten in einem beschädigten oder inkonsistenten Zustand zu lassen, vor allem in Systemen, in denen mehrere Dinge nacheinander passieren müssen.

Schauen wir uns ein paar reale Szenarien an, in denen Atomarität das System ausmacht (oder zerstört):

Beispiel 1: Banküberweisung

Nehmen wir an, du überweist 100 Dollar von deinem Girokonto auf dein Sparkonto.

Die Transaktion besteht aus zwei Teilen:

1. $100 vom Girokonto abziehen
2. $100 zu den Ersparnissen hinzufügen

Ohne Atomarität ist es möglich, dass Schritt eins abgeschlossen wird und Schritt zwei fehlschlägt, z. B. aufgrund einer Netzwerkstörung oder eines Serverabsturzes. Glückwunsch, dein Geld ist gerade ins Nichts verschwunden. Atomarität stellt sicher, dass entweder beide Schritte erfolgreich sind oder keiner. Wenn etwas schief geht, bleiben die 100 Dollar genau dort, wo sie ursprünglich waren.

Beispiel 2: Inventur und Auftragsabwicklung

Du kaufst die letzte Vinyl-Schallplatte in limitierter Auflage online. Das System muss:

1. Reduziere den Bestand um eine
2. Bestätige deine Bestellung

Ohne Atomarität könnte es den Bestand reduzieren, aber abstürzen, bevor der Auftrag bestätigt wird. Jetzt denkt der Laden, dass sie nicht mehr vorrätig ist, aber niemand bekommt die Platte. 

Es ist erstaunlich, wie oft mir das passiert, wenn ich etwas online kaufe. Normalerweise schließe ich die Registerkarte und wünsche den Ingenieurinnen und Ingenieuren viel Glück, aber in Zukunft werde ich wahrscheinlich nicht mehr auf dieser Website einkaufen. Wer weiß, wie sie mit meinen persönlichen Daten umgehen werden, wenn sie nicht sicherstellen können, dass ihre Kernfunktionalität für den Einkauf zuverlässig ist?

Beispiel 3: Flugbuchungssystem

Einen Flug zu buchen bedeutet meist mehr als nur einen Sitzplatz auszuwählen. Das System muss:

1. Den Sitzplatz zuweisen
2. Sitzplatzverfügbarkeit aktualisieren
3. Deine Karte aufladen

Wenn Schritt zwei fehlschlägt und Schritt drei durchgeht, hast du für einen Platz bezahlt, den es nicht gibt. Nicht ideal.

Beispiel 4: Datenbank und Suchindex synchronisieren

Nehmen wir an, deine App aktualisiert die Beschreibung eines Produkts in der Hauptdatenbank. Gleichzeitig sollte sie den Suchindex aktualisieren, damit die Nutzer das Produkt mit der neuen Beschreibung finden können.

Wenn die Datenbankaktualisierung erfolgreich ist, aber die Indexaktualisierung fehlschlägt, sehen die Nutzer/innen veraltete Ergebnisse oder können das Produkt gar nicht finden.

Warum Atomarität wichtig ist

Warum ist Atomismus so eine große Sache? 

Es gibt so viele Gründe, warum eine Transaktion unterbrochen werden kann. Es könnte ein Stromausfall, ein Serverabsturz oder eine Netzwerkzeitüberschreitung auf halbem Weg sein. Wenn die Atomarität nicht erzwungen wird, kann die Transaktion nur teilweise abgeschlossen werden. Jetzt befindet sich deine Datenbank in einem unangenehmen Zustand: Einige Änderungen wurden durchgeführt, andere nicht, und du hast keine einfache Möglichkeit, das Chaos rückgängig zu machen.

Hier werden Datenfehler wirklich heimtückisch. Die Nutzerinnen und Nutzer bemerken anfangs vielleicht nichts, aber mit der Zeit summieren sich die Dinge. Deine Analysen sehen komisch aus, Bestellungen verschwinden, Konten werden nicht ausgeglichen oder die Zahl der Support-Tickets steigt, weil die Leute nicht finden können, was sie gerade gespeichert haben.

Atomicity verhindert all das, indem es sicherstellt, dass:

• Eine Transaktion findet entweder vollständig oder gar nicht statt
• Das System kann sich sauber erholen, selbst wenn etwas auf halbem Weg scheitert
• Deine Daten bleiben konsistent, selbst bei Systemabstürzen oder gleichzeitigem Zugriff

Sie steht auch in engem Zusammenhang mit den anderen ACID-Eigenschaften. Ohne Atomarität ist die Konsistenz nicht mehr gegeben, da du keine Regeln durchsetzen kannst, wenn die Hälfte der Daten fehlt, und die Isolation wird unterbrochen, da andere Nutzer möglicherweise nur Teile der Daten einer unvollständigen Transaktion sehen.

Das ist besonders wichtig, wenn du mit einem Problem zu tun hast:

• Mehrstufige Transaktionen, bei denen eine Aktion von einer anderen abhängt.
• Aktualisierungen mit mehreren Zeilen oder Tabellen, bei denen zusammenhängende Daten synchron gehalten werden müssen.
• Verteilte Systeme, bei denen Teile der Transaktion auf verschiedenen Rechnern oder Datenbanken stattfinden.

Wie Atomizität in der Praxis funktioniert

Hinter der Einfachheit des "Alles oder Nichts" verbirgt sich ein überraschend kompliziertes System. Wenn eine Datenbank eine Transaktion ausführt, verfolgt sie aktiv jeden Schritt, bereitet ihn vor und schützt ihn.

Hier ist ein Überblick darüber, was vor sich geht:

Der Lebenszyklus einer Transaktion

1. Beginne die Transaktion: Das System markiert den Beginn einer Transaktion und isoliert die anstehenden Änderungen vom Rest der Datenbank.
2. Führe den Vorgang aus: Dazu gehören alle Einfüge-, Aktualisierungs- und Löschvorgänge sowie alle SQL-Zaubereien, die du durchführst.
3. Commit oder Rollback: Wenn jede Operation erfolgreich ist, wird die Transaktion bestätigt und die Änderungen werden dauerhaft. Wenn etwas fehlschlägt, wird die gesamte Transaktion zurückgenommen.

Logging und Journaling

Um Atomarität zu gewährleisten, schreiben Datenbanken Protokolle darüber, was passieren wird, bevor es tatsächlich passiert. Diese Logs werden separat gespeichert und dienen als Backup-Plan.

Wenn das System mitten in einer Transaktion abstürzt, kann es auf das Protokoll zurückgreifen und unvollständige Änderungen rückgängig machen, abgeschlossene Änderungen sicher wieder anwenden und die Datenbank in einem sauberen, konsistenten Zustand wiederherstellen.

Dieser Ansatz wird manchmal als Write-Ahead Logging (WAL) oder Journaling bezeichnet und ist ein wichtiger Bestandteil der Wiederherstellung nach einem Absturz.

Rollbacks und Wiederherstellung

Wenn eine Transaktion fehlschlägt, gibt die Datenbank nicht einfach auf, sondern macht die Änderungen sorgfältig rückgängig. Geänderte Zeilen werden in ihrem ursprünglichen Zustand wiederhergestellt, alle von der Transaktion gehaltenen Sperren werden freigegeben und die Protokolle werden verwendet, um partielle Aktualisierungen rückgängig zu machen.

Im Falle eines Absturzes treten die Wiederherstellungsroutinen beim Neustart in Kraft. Sie spielen Protokolle ab, lösen nicht abgeschlossene Transaktionen auf und stellen sicher, dass die Datenbank genau dort weitermacht, wo sie aufgehört hat, ohne seltsame Halbzustände.

Leistung vs. Atomarität

Es überrascht nicht, dass dies alles seinen Preis hat. Atomicity stellt vor:

• Sperren: Um zu verhindern, dass andere dieselben Daten während einer Transaktion ändern können
• Overhead: Von Logging- und Rollback-Mechanismen
• Deadlocks: Wenn mehrere Transaktionen aufeinander warten, um Ressourcen freizugeben

Aus diesem Grund musst du große Transaktionen sorgfältig planen. Wenn du zu viel auf einmal machst, kann das dein ganzes System verlangsamen oder du bekommst Probleme mit der Gleichzeitigkeit.

Atomarität in gängigen Datenbanksystemen

Atomarität ist ein Kernkonzept aller großen Datenbanken, aber die Art und Weise, wie es umgesetzt wird, kann je nach zugrunde liegender Speicher-Engine und Design-Philosophie leicht variieren. Schauen wir uns an, wie PostgreSQL und MySQL (InnoDB) dafür sorgen, dass Transaktionen richtig funktionieren.

PostgreSQL

Bevor Daten dauerhaft geschrieben werden, erstellt PostgreSQL ein Write-Ahead-Log (WAL), die Aufzeichnung jeder beabsichtigten Änderung, über die wir bereits gesprochen haben. Dieses Protokoll wird sicher gespeichert und als Wiederherstellungsplan verwendet, falls bei der Transaktion etwas schief geht.

Wenn eine Transaktion festgeschrieben wird, prüft PostgreSQL die WAL, bestätigt, dass alle Änderungen vollständig und gültig sind, und schließt dann die Aktualisierungen ab. Wenn etwas auf halbem Weg abstürzt, verwendet die Datenbank dieses Protokoll, um unvollständige Arbeit zurückzunehmen.

Das Tolle ist, dass das alles automatisch hinter den Kulissen passiert. Aus der Sicht eines Entwicklers ist es nahtlos: Du schreibst eine Transaktion, und PostgreSQL garantiert Atomarität, ohne dass du dich um die Komplexität kümmern musst.

Die Änderungen sind für andere Benutzer nicht sichtbar, bis die Transaktion vollständig bestätigt wurde. Das hält die Dinge konsistent und verhindert, dass in Multi-User-Umgebungen "halb gerettet" wird.

PostgreSQL WAL. Quelle: AlgoMaster

Wenn du selbst Hand anlegen und deine eigenen Datenbanken erstellen möchtest, um Transaktionen zu testen, schau dir unseren PostgreSQL-Kurs an.

MySQL (InnoDB)

Die InnoDB-Speicher-Engine von MySQL unterstützt ebenfalls atomare Transaktionen und ist sowohl auf Zuverlässigkeit als auch auf Leistung ausgelegt.

Wie PostgreSQL verwendet auch InnoDB ein Transaktionsprotokoll, um die Änderungen vor dem Commit zu speichern. Wenn etwas fehlschlägt, wird das Protokoll verwendet, um alles auf den Zustand vor der Transaktion zurückzusetzen. So wird sichergestellt, dass sich keine Teilaktualisierungen einschleichen.

Eine Sache, die InnoDB besonders gut kann, ist das Zusammenfassen von Schreibvorgängen. Dies hilft, die Festplatten-E/A zu reduzieren und die Leistung zu verbessern, während die Atomizität erhalten bleibt. Außerdem werden Undo-Logs verwendet, um Änderungen bei einem Rollback rückgängig zu machen, und Redo-Logs für die Wiederherstellung nach einem Absturz.

Genau wie bei PostgreSQL kannst du dich darauf verlassen, dass die Datenbank diese Mechanismen für dich übernimmt. Du musst keinen eigenen Rollback-Code schreiben.

Die wichtigsten Erkenntnisse für Ingenieure und Datenarchitekten

Es gibt ein paar Dinge, die du beachten solltest, wenn du in deinen eigenen Projekten mit atomaren Transaktionen arbeitest. Die übergreifende Idee ist, Atomarität als Standard zu behandeln, nicht als Luxus. Wenn du Systeme baust, die Daten an mehr als einer Stelle gleichzeitig ändern (und das sind im Grunde alle), sparst du Zeit, Nerven und möglicherweise eine Benachrichtigung über einen Zwischenfall um 3 Uhr morgens, wenn du die Atomisierung im Blick hast. 

Wähle die richtige Datenbank für die Aufgabe

Nicht alle Datenbanken handhaben Atomarität auf die gleiche Weise, und nicht alle Speicher-Engines sind gleich. Wenn Atomarität für deinen Anwendungsfall entscheidend ist (z. B. Finanzen, Logistik, Verwaltung des Benutzerstatus), solltest du sicherstellen, dass deine Datenbank vollständige ACID-Transaktionen unterstützt. Das ist besonders wichtig, wenn du MySQL verwendest, da die Wahl der Speicher-Engine wichtig ist.

Design for failure

Gehe davon aus, dass die Dinge schief gehen werden, denn das werden sie. Wickle mehrstufige Vorgänge in Transaktionen ein und behandle Fehler richtig. Sei explizit mit deinen BEGIN,COMMIT und ROLLBACK Anweisungen, oder verwende Frameworks, die diese sicher unter der Haube behandeln.

Die meisten modernen ORMs und Datenzugriffsschichten bieten integrierte Transaktionsunterstützung. Zum Beispiel:

• In Node.js kannst du mit Bibliotheken wie Prisma und TypeORM Logik in einen Aufruf verpacken transaction() Aufruf verpacken, der im Hintergrund die Übergabe und das Rollback übernimmt.

• In Python bietet SQLAlchemy Kontextmanager (mit session.begin():), die sichere Commits und Rollbacks gewährleisten.

• In Java ermöglichen Frameworks wie Spring das Annotieren von Methoden mit @Transactionalannotieren, sodass die Datenbank alles atomar verarbeitet, auch über mehrere Funktionsaufrufe hinweg.

Diese Werkzeuge machen es viel einfacher, standardmäßig sicher zu bauen. Sie verringern das Risiko, einen Rollback zu vergessen oder die Commit-Logik falsch zu handhaben, besonders wenn deine App komplexer wird.

Gleichgewicht zwischen Leistung und Zuverlässigkeit

Atomarität ist mit einem gewissen Overhead verbunden, vor allem bei großen Transaktionen. Unterteile umfangreiche Operationen so weit wie möglich, vermeide das Sperren ganzer Tabellen und halte Transaktionen kurz und konzentriert. Lang laufende Transaktionen erhöhen das Risiko von Konflikten, Deadlocks und unzufriedenen Benutzern.

Verstehen von Abhängigkeiten und Isolation

Wie wir bereits gesehen haben, existiert Atomarität nicht in einem Vakuum, sondern zusammen mit Konsistenz und Isolation. Achte darauf, dass zusammenhängende Änderungen gemeinsam durchgeführt werden, und überlege, wie gleichzeitige Transaktionen zusammenwirken können. Verwende Isolationsstufen, die zu deinem Arbeitsaufkommen passen, ohne die Dinge zu kompliziert zu machen.

ACID-Eigenschaften in DBMS. Quelle: DataCamp

Test mit realistischen Fehlerszenarien

Teste nicht nur deine glücklichen Wege. Simuliere, was passiert, wenn deine App mitten in einer Transaktion abstürzt oder wenn eine Abfrage eine Zeitüberschreitung verursacht. Du kannst Failpoints oder Mock-DB-Ausfälle verwenden, um zu sehen, wie sich dein System unter Druck verhält.

Fazit

Wenn du Systeme baust, bei denen mehrere Dinge zusammen passieren müssen, ist Atomarität nicht optional, sondern unerlässlich. Ganz gleich, ob du Geld zwischen Konten verschiebst, Bestände aktualisierst oder Systeme synchronisierst, Atomicity sorgt dafür, dass deine Daten nicht in einem kaputten oder halbfertigen Zustand enden.

Wenn du tiefer einsteigen willst, dann besuche doch unseren Kurs Datenbankdesign. Du lernst, wie man Datenbanken in SQL entwirft, um Daten effizienter zu verarbeiten, zu speichern und zu organisieren.

Und wenn du dich für weitere praktische Artikel und Tutorials zum Thema Datenbankdesign interessierst, schau dir unsere Serie zur Datenbanknormalisierung an:

• Normalisierung in SQL (1NF - 5NF): Eine Anleitung für Anfänger tutorial
• Was ist die Erste Normalform (1NF)? tutorial
• Was ist die Zweite Normalform (2NF)? tutorial
• Was ist die dritte Normalform (3NF)? Tutorial
• Was ist transitive Abhängigkeit? Tutorial