97 Dinge, die jeder Dateningenieur wissen sollte

Kapitel 1. Ein (Buch-)Plädoyer für letztendliche Konsistenz

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

Denise Koessler Gosnell, PhD

Stell dir vor, du besitzt eine Buchhandlung.¹ Irgendwann wirst du ein System einrichten wollen, das einen Überblick über alle Bücher in deinem Laden gibt.

In den Anfängen des Ladens hast du ein System ausgewählt, das für etwa 1.000 Bücher an einem Standort ausgelegt war. Dieses System aktualisiert den Datensatz eines Buches, wenn ein Kunde zur Kasse geht. Wenn ein Kunde an die Kasse kommt, um ein Buch zu kaufen, macht dein Bestandssystem Folgendes:

1. Überprüft deine Hauptbücher auf Inventurdaten

2. Zeichnet den neuen Kauf auf

3. Aktualisiert alle Datensätze

4. Gibt dem Kunden eine Quittung zurück

Der Bon bestätigt sowohl den Kauf des Kunden als auch die Aktualität deines Bestandssystems. Diese Art von Inventarsystem setzt voraus, dass alle deine Transaktionen eine hohe Konsistenz aufweisen. In diesem Sinne bedeutet starke Konsistenz, dass alle Zugriffe auf das Inventar des Ladens nacheinander verarbeitet und aus demselben Zustand im Inventarsystem deines Ladens gelesen werden.

Nun, gute Nachrichten, Ladenbesitzer! Das Buchgeschäft boomt, und du eröffnest mehrere Läden, um deinen wachsenden Kundenstamm zu bedienen. Wie pflegst du in dieser Welt den Bestand deines Unternehmens in mehreren Läden?

Vielleicht überlegst du, dein aktuelles System neu zu gestalten. Du entscheidest dich für eine Hauptkasse in deinem ersten Markt. Dann werden alle anderen Filialen eine neue Kasse haben, die mit der Hauptkasse verbunden ist.

Dieses neue System funktioniert großartig... bis du den Strom zu deiner Hauptkasse verlierst. Jetzt sind alle Kunden in all deinen Filialen daran gehindert, einen einzigen Einkauf zu tätigen. Deine Schlangen sind lang und stagnieren.

Willst du deine Kunden frustriert gehen lassen, wenn deine Warteschlange zu lange braucht, um bearbeitet zu werden? Um dieses Problem zu lösen, solltest du vielleicht entscheiden, dass die Validierung und Aktualisierung des Bestands deines Ladens auf eine andere Weise erfolgen kann.

Vielleicht ziehst du diesmal in Betracht, deine Bücher täglich zu aktualisieren. In diesem neuen System aktualisierst du bei Ladenschluss den Bestand deiner Bücher, indem du alle Bücher in jedem Laden zählst und prüfst, ob jeder Titel, den du erwartest, in deinen Regalen steht. Jeden Abend werden die Regale in deinen Läden geprüft und du kannst beruhigt nach Hause gehen, weil deine Bücher ausgeglichen sind.

Diese zweite Art des Inventarsystems sieht vor, dass alle deine Transaktionen letztendlich konsistent sind. Jeder Zugriff auf den Bestand deines Ladens wird parallel verarbeitet und protokolliert eine Aktualisierung im Bestandssystem deines Buches. Letztendlich geben alle Zugriffe auf ein bestimmtes Buch den zuletzt aktualisierten Wert zurück.

Und was passiert, wenn ein Kunde nach einem Titel sucht, der nicht in deinen Regalen steht? Nun, dann kannst du ihn ansprechen.

Die Behebung von Inkonsistenzen, wenn sie gefunden werden, ist wie eine Lesereparatur in einem verteilten System. Nur wenn du eine Unstimmigkeit findest, setzt du den schwereren Prozess in Gang, um den Status in allen deinen Ledgern zu aktualisieren. Während dieses Prozesses kannst du deine Verkaufsprotokolle überprüfen, um zu sehen, ob die Aufzeichnungen aktuell sind. Durch diese mehrfache Überprüfung des Status wird sichergestellt, dass deine Aufzeichnungen aktuell und konsistent sind.

Ist dieser Prozess gut genug für dich? Für Systeme, die hohe Verarbeitungsvolumen für die Konsistenz des Zustands eintauschen müssen, ja.

Die Umstellung auf ein konsistentes System mit Lesereparatur zur Behebung von Unstimmigkeiten bewahrt deine Kunden vor der Gefahr langer Schlangen an der Kasse. Und deine Architekten haben weniger Stress, wenn es darum geht, die Verfügbarkeit der Datenbank deiner Hauptkasse zu schützen.

Die beiden Ansätze für die Inventarisierung deines Ladens stellen grob gesagt zwei Denkschulen dar. Sie beschreiben zwei unterschiedliche Architekturen: eine, die stark konsistent ist (und die Skalierung mit Client/Server-Architekturen angeht), und eine andere, die schließlich konsistent ist (die Transaktionen mit hohem Volumen handhabt und zustandsbezogene Inkonsistenzen auflöst, wenn sie gefunden werden).

Nach welcher Denkweise willst du das System, das du entwirfst, planen?

¹ Denise Gosnell möchte sich bei David Bechberger für seine Beiträge zu diesem Kapitel bedanken.