Stellen Sie sich vor, Sie versuchen, eine riesige, chaotische Bibliothek zu organisieren, in der Millionen von Menschen gleichzeitig Bücher ausleihen, lesen und umschreiben wollen. In der Welt der Informatik ist dies die Herausforderung von Datenbanken: Systemen, die Informationen speichern, damit Anwendungen diese sofort finden und ändern können. Jahrzehntelang war die große Frage, wie man diese Bibliotheken wachsen lassen kann, um das gesamte Internet zu bewältigen, ohne dass sie zusammenbrechen. Die alte Methode war wie ein einzelner Bibliothekar, der jedes einzelne Buch abstempeln musste, was eine lange Schlange erzeugte, die alle ausbremste. Der neuere „Eventual Consistency“-Weg war wie das Zulassen, dass Menschen raten, was in dem Buch steht, und Fehler später korrigieren – das ist schnell, aber riskant, wenn man genau in diesem Moment die Wahrheit wissen muss. Das Ziel moderner Datenbanktechnik ist es, ein System zu bauen, das so schnell wie die Ratemethode, aber so zuverlässig wie die Abstempelmethode ist – fähig dazu, Millionen von Transaktionen pro Sekunde zu verarbeiten, ohne dass jemals jemand die Regale manuell verwalten muss.

Dieses Paper stellt Aurora DSQL vor, eine neue Art von Datenbank, die von Amazon Web Services entwickelt wurde, um genau dieses Problem zu lösen. Stellen Sie sich das wie eine superintelligente, selbstfahrende Bibliothek vor, die sich sofort ausdehnen oder zusammenziehen kann, je nachdem, wie viele Besucher sie hat. Die Autoren haben ein System gebaut, das das „Denken“ (das Ausführen des SQL-Codes) von der „Speicherung“ (dem Aufbewahren der Bücher) und den „Regeln“ (dafür zu sorgen, dass nicht zwei Leute gleichzeitig dieselbe Seite ändern) trennt. Durch die Verwendung eines speziellen „Journals“, das wie ein permanentes, unveränderliches Tagebuch jeder vorgenommenen Änderung fungiert, ermöglicht DSQL es den verschiedenen Teilen des Systems, unabhängig voneinader zu arbeiten. Das Paper zeigt, dass dieses Design es der Datenbank ermöglicht, von null Nutzern bis hin zu Millionen von Transaktionen pro Sekunde zu skalieren, über verschiedene Kontinente hinweg zu funktionieren, ohne langsamer zu werden, und die Daten perfekt konsistent zu halten, sodass Sie sich nie Sorgen machen müssen, ein Buch zu lesen, das jemand anderes gerade umschreibt.

Die Magie der entkoppelten Bibliothek

Um zu verstehen, wie Aurora DSQL funktioniert, stellen Sie sich eine riesige Bibliothek vor, in der die Bibliothekare, die Bücherregale und die Regelhüter sich alle in verschiedenen Gebäuden befinden, die durch superschnelle Telegramme miteinander verbunden sind. In älteren Systemen waren diese Teile fest miteinander verklebt; wenn die Regale zu voll wurden, musste die gesamte Bibliothek anhalten und sich reorganisieren. DSQL bricht sie auseinander.

Zuerst gibt es die Query Processors. Das sind die Bibliothekare, die mit Ihnen kommunizieren. Wenn Sie nach einem Buch fragen, tragen sie die schweren Bücher nicht selbst. Stattdessen laufen sie innerhalb winziger, sicherer virtueller Räume, die Firecracker MicroVMs genannt werden. Diese Räume sind so effizient, dass sie im Handumdrehen erstellt oder zerstört werden können. Wenn Sie einen plötzlichen Besucheransturm haben, baut das System sofort mehr Räume. Wenn der Ansturm nachlässt, reißt es sie wieder ab, damit Sie nicht für leeren Raum bezahlen. Dies ist der „Serverless“-Aspekt: Sie verwalten die Bibliothekare nicht; sie tauchen einfach auf, wenn Sie sie brauchen.

Als Nächstes kommen die Storage Nodes. Das sind die Bücherregale. Sie halten nicht die gesamte Bibliothek; sie halten nur bestimmte Abschnitte von Büchern basierend auf einem „Shard Key“ (wie das Sortieren von Büchern nach dem ersten Buchstaben des Autors). Da die Bibliothekare und die Regale getrennt sind, können die Bibliothekare ihr eigenes Ding machen, ohne darauf warten zu müssen, dass die Regale aufholen. Sie lesen aus dem nächstgelegenen Regal in ihrer eigenen Nachbarschaft (Availability Zone), was das Lesen unglaublich schnell macht.

Schließlich gibt es die Adjudicators und das Journal. Die Adjudicators sind die Regelhüter, die entscheiden, ob eine Änderung erlaubt ist. Das Journal ist das meisterhafte Tagebuch. Wenn Sie ein Buch ändern wollen (einen „Write“), schreibt der Bibliothekar die Änderung auf ein Stück Papier, legt sie aber noch nicht ins Regal. Er schickt sie an den Regelhüter. Der Regelhüter prüft, ob gerade jemand anderes versucht, dasselbe Buch gleichzeitig zu ändern. Wenn alles klar ist, schreibt der Regelhüter die Änderung in das Journal. Dieses Journal ist der wichtigste Teil: es ist eine permanente, geordnete Liste jeder einzelnen Änderung, die jemals stattgefunden hat. Sobald etwas im Journal steht, ist es für immer sicher, selbst wenn die Regale oder die Bibliothekare verschwinden.

Der „No-Wait“-Lesetrick

Einer der coolsten Tricks in diesem Paper ist die Art und Weise, wie es das Lesen handhabt. In vielen Datenbanken müssen Sie darauf warten, dass der Bibliothekar sicherstellt, dass gerade niemand in das Buch schreibt, wenn Sie ein Buch lesen wollen. Das verursacht Warteschlangen und Verzögerungen. DSQL nutzt einen cleveren Zeitreise-Trick namens Multi-Version Concurrency Control (MVCC).

Stellen Sie sich vor, dass die Bibliothek bei jeder Änderung an einem Buch nicht die alte Version löscht. Stattdessen erstellt sie eine neue Kopie mit einem Zeitstempel. Wenn Sie nach einem Buch fragen, fragen Sie nicht nach „dem Buch“; Sie fragen nach „dem Buch, wie es um 14:00 Uhr war“. Das System findet dann die Version, die um 14:00 Uhr gültig war. Da das System über extrem präzise Uhren verfügt (genau bis auf Mikrosekunden), weiß es exakt, welche Version es Ihnen zeigen muss. Das bedeutet, Sie können ein Buch lesen, während jemand anderes ein neues schreibt, und Sie werden dessen unordentliche, halbfertige Änderungen nicht sehen. Sie sehen einen perfekten, eingefrorenen Schnappschuss der Vergangenheit. Dies ermöglicht es Millionen von Menschen, gleichzeitig zu lesen, ohne sich gegenseitig zu blockieren.

Die Multi-Region-Superkraft

Das Paper befasst sich auch mit dem Problem der Distanz. Normalerweise dauert es Zeit, eine Bibliothek in New York und eine in London synchron zu halten, da die Kommunikation der Lichtgeschwindigkeit unterliegt. Wenn Sie versuchen, ein Buch an beiden Orten gleichzeitig zu aktualisieren, müssen Sie warten, bis eine Nachricht den Ozean überquert hat, was alles verlangsamt.

DSQL löst dies dadurch, dass es active-active arbeitet. Das bedeutet, Sie können eine Bibliothek in New York und eine in London haben, und beide sind gleichzeitig voll einsatzbereit. Wenn Sie eine Änderung in New York vornehmen, schreibt das System diese in das Journal. Das Journal sendet dann eine Kop копия nach London. Die Magie daran ist, dass dies nur ein einziges Mal geschieht, nämlich in dem Moment, in dem Sie auf „Commit“ (Transaktion abschließen) klicken. Das System hindert Sie nicht daran, zu lesen oder zu schreiben, während die Nachricht reist. Es verwendet ein „Quorum“-System, was bedeutet, dass es nur die Bestätigung der Änderung in zwei von drei Regionen benötigt, um sie als sicher zu betrachten.

Die Autoren haben dies gemessen und festgestellt, dass das System selbst bei der Distanz zwischen Virginia und Oregon (etwa 62 Millisekunden Round-Trip) diese „Distanzsteuer“ nur einmal pro Transaktion zahlt. Für das Lesen ist es sogar schneller, weil Sie aus der lokalen Bibliothek lesen. Die Autoren zeigen, dass dieses Design es der Datenbank ermöglicht, schnell und konsistent zu bleiben, selbst wenn eine ganze Region (wie eine ganze Stadt) aufgrund einer Katastrophe offline geht.

Die Regeln des Spiels

Die Autoren waren sehr sorgfältig bei dem, was sie versprochen haben. Sie entschieden sich für Snapshot Isolation, einen spezifischen Satz von Regeln, wie Transaktionen ablaufen. Es ist so, als würde man sagen: „Sie können das Buch so lesen, wie es war, als Sie mit dem Lesen begannen, und Sie können es ändern, wenn Sie fertig sind, aber wenn jemand anderes in der Zwischenzeit etwas geändert hat, müssen Sie es erneut versuchen.“ Dies unterscheidet sich von strengeren Regeln, die Sie zwingen würden, auf eine Sperre (Lock) zu warten, was die Dinge verlangsamt.

Das Paper schließt explizit die Idee aus, dass man einen einzelnen „Leader“ benötigt, um alles zu verwalten. In vielen Systemen ist ein Computer der Chef, und wenn dieser ausfällt, stoppt alles. DSQL hat keinen einzelnen Chef. Jeder Teil kann hoch- oder herunterskalieren, und wenn ein Teil ausfällt, machen die anderen einfach weiter. Das Paper schließt auch die Idee aus, dass Sie die Hardware selbst verwalten müssen. Das System regelt die „Hitze“ (welche Teile zu beschäftigt sind) automatisch. Wenn ein Abschnitt der Bibliothek zu voll wird, teilt der Control Plane (der Bibliotheksmanager) diesen automatisch in zwei kleinere Abschnitte auf und bewegt einige Bücher auf ein neues Regal, alles ohne Ihr Zutun.

Die Theorie testen

Die Autoren haben nicht nur geraten, dass dies funktionieren wird; sie haben es intensiv getestet. Sie nutzten eine Methode namens deterministische Simulation, bei der sie das System in einem Computerprogramm ausführten, das in einem Bruchteil einer Sekunde Millionen von Fehlern, Netzwerkverzögerungen und Abstürzen simulieren konnte. Sie fanden heraus, dass das System diese Fehler bewältigen kann, ohne Daten zu verlieren oder verwirrt zu werden.

Sie führten auch Tests im realen Stil durch (wie den TPC-C Benchmark, der einen geschäftigen Laden simuliert). Die Ergebnisse zeigten, dass DSQL in der Lage ist, von einem Kaltstart (wo es sehr wenige Ressourcen hat) bis hin zur Verarbeitung von Millionen von Operationen pro Minute zu skalieren. Es dauerte etwa 25 Minuten, um aus einem völlig leeren Zustand die volle Geschwindigkeit zu erreichen, aber sobald es „warm“ war, war es unglaublich schnell. Das Paper merkt an, dass sie zwar sehr zuversichtlich in Bezug auf diese Ergebnisse sind, aber immer noch daran arbeiten, weitere Funktionen wie Foreign Keys (die Tabellen miteinander verknüpfen) und gespeicherte Prozeduren (Stored Procedures) hinzuzufügen.

Das Fazit

Aurora DSQL ist ein Beweis dafür, dass man das Beste aus beiden Welten haben kann: eine Datenbank, die so einfach zu bedienen ist wie ein einfacher Service (bei dem man nichts selbst verwalten muss), und gleichzeitig so leistungsstark wie ein massives, globales System. Durch die Trennung von Denken, Speicherung und Regeln und durch die Verwendung eines permanenten Journals zur Zeitverfolgung ermöglicht es Anwendungen, von Null auf Millionen von Transaktionen zu wachsen, ohne ins Schwitzen zu geraten. Es ist ein System, das für eine Welt konzipiert wurde, in der sich Dinge schnell ändern, Katastrophen passieren und in der man wissen muss, dass die Information, die man liest, die absolute Wahrheit ist – genau jetzt.