Lakebase-Architektur

Lakebase trennt den Speicher von der Berechnung. Die Postgres-Engine, die Ihre Abfragen ausführt, ist stateless, und Ihre Daten befinden sich in einer langlebigen Speicherschicht, die unabhängig davon gespeichert ist. Diese Trennung macht Autoscaling, Skalieren bis Null, sofortige Verzweigungen, Leserepliken und schnelles Failover möglich.

Um zu zeigen, was Lakebase ändert, beginnt diese Seite mit dem traditionellen Datenbankdesign mit einer einmaligen Maschine zum Kontrast und erklärt dann, wie Lakebase dieses Design in unabhängige Schichten aufteilt und was jeder Teil bewirkt.

Wie eine traditionelle Datenbank aufgebaut wird

Bevor Sie sich Lakebase ansehen, sollten Sie das Modell betrachten, das es ersetzt. Eine konventionelle Postgres-Datenbank ist ein Monolith. Eine einzelne Maschine führt die Abfrage-Engine aus und schreibt sowohl das Write-Ahead-Log (WAL) als auch die Datendateien auf eine an einem lokalen Mountpoint angeschlossene Festplatte. Traditionell waren diese Festplatten tatsächlich lokal und Teil derselben Maschine, aber mit der Weiterentwicklung der Infrastruktur sind sie oft netzwerkgebundene Speichergeräte.

Das WAL und die Datendateien spielen zwei komplementäre Rollen:

• Das WAL beschleunigt die Schreibvorgänge. Postgres fügt jede Änderung sequenziell dem Log an, bevor ein Commit bestätigt wird, das auf einer einzelnen Festplatte schnell und langlebig ist.
• Die Datendateien beschleunigen das Lesen. Postgres materialisiert die aktuelle Version jeder Seite in Datendateien, sodass eine Abfrage eine Zeile lesen kann, ohne das Log erneut abzuspielen.

Der Zugriff auf alle Ihre Daten über einen Rechner hat Nachteile:

• Die Haltbarkeit ist direkt an die physische Infrastruktur dieser Maschine gebunden. Außerdem müssen Sie Speicher vorab bereitstellen und vorhersagen, wie stark Ihre Arbeitslast wachsen wird, was sowohl das Kostenmanagement als auch die Resilienzplanung erschwert.
• Hohe Verfügbarkeit und viele Arten von horizontaler Skalierung erfordern physische Klone der gesamten Datenbank.
• Wenn diese Maschine ausfällt, kannst du Daten verlieren. Techniken wie RAID-Speicher verringern dieses Risiko, aber die zusätzliche Redundanz kann die Betriebskosten erheblich erhöhen.

Die Lakebase-Architektur

Lakebase behält die gleichen Aufgaben bei, teilt sie aber in zwei unabhängige Schichten auf:

• Eine Rechenschicht , die standardmäßige, zustandslose Postgres ausführt.
• Eine Speicherschicht , bestehend aus Safekeepern, Pageservern und Cloud-Objektspeicherung.

Die beiden Rollen des Monolithen werden direkt auf die neuen Komponenten abgebildet. Der WAL, der beschleunigte Schreibvorgänge beschleunigt, wird zum Safekeeper, der skaliert schreibt. Die Datendateien, die das Lesen beschleunigen, werden zu den Pageservern, die die Lesungen skalieren.

Da sich Daten in Cloud-Objektspeichern und nicht auf einer einzigen Maschine befinden, liefert Lakebase elastische, skalierbare Rechenleistungen und langlebige Schreibvorgänge, die über Verfügbarkeitszonen hinweg repliziert werden. Es gibt keinen Speicherplatz bereitzustellen: Du zahlst nur für den Speicher, den du verbrauchst, und musst nicht mit Ausfallmodi wie dem Ausgehen der Festplatte planen.

Dieses Modell verbessert zudem die Leistung. Lakebase schreibt jede Änderung direkt an mehrere Orte, wodurch der Aufwand des traditionellen Rip-Write-Schutzes und der Blockausrichtung vermieden wird. Da jeder Schreib bereits an mehrere Orte geht, bleibt die Leistung konstant, egal ob hohe Verfügbarkeit aktiviert ist oder nicht.

Die folgende Tabelle ordnet jeden Teil des Monolithen seinem Lakebase-Gegenstück zu.

Traditioneller Monolith	Lakebase	Rolle
Einzelner Computer	Zustandslose Berechnung	Führt die Postgres-Abfrage-Engine aus
Lokale WAL-Diskette	Safekeeper	Dauerhaft dokumentiert jede verabschiedete Änderung
Lokale Datendateien	Pageserver und Objektspeicherung	Materialisiert und speichert Seitenversionen

Rechenebene

Die Rechenschicht führt Postgres aus. Es hält nur einen vorübergehenden Zustand: die Postgres-Puffer im Speicher und einen lokalen Rechencache, der von einer schnellen lokalen Festplatte unterstützt wird. Es besitzt keine dauerhaften Daten.

Weil Compute keinen dauerhaften Zustand besitzt:

• Es kann ersetzt, neu gestartet, automatisch skaliert oder auf null skaliert werden, ohne Daten zu verschieben oder zu verlieren.
• Anstatt in ein lokales Dateisystem zu schreiben, streamt es das WAL auf die Speicherschicht.
• Mehrere Compute-Instanzen können an dieselbe Speicherschicht angeschlossen werden, was die Art und Weise ist, wie Lakebase Read-Replicas und schnelles Failover funktionieren.

Speicherebene

Die Speicherschicht ist langlebig und arbeitet unabhängig von der Rechenleistung. Es besteht aus drei Komponenten.

Safekeeper

Safekeepers sind die WAL, die aus der einzelnen Maschine herausgezogen und hoch verfügbar gemacht werden. Wenn Postgres WAL-Datensätze erstellt, wird diese an eine Gruppe von Safekeepern weitergeleitet, die das Protokoll über ein Quorum hinweg mit einem Paxos-basierten Konsensprotokoll replizieren.

Eine Transaktion wird vergeben, wenn ein Quorum von Safekeepern den WAL-Datensatz bestätigt, nicht wenn eine einzelne Maschine einen lokalen fsyncAuftrag abschließt. Die Haltbarkeit entsteht durch die Replikation über Knoten hinweg und nicht von einer einzigen Festplatte.

Pageserver

Pageserver sind die Datendateien, die aus dem WAL herausgezogen und neu aufgebaut werden. Ein Pageserver verbraucht den WAL-Strom der Safekeeper und materialisiert auf Abruf Seitenversionen. Wenn Compute eine Seite mit einer bestimmten Log-Sequenznummer (LSN) anfordert, rekonstruiert der Pageserver sie und gibt sie zurück.

Pageserver fungieren als Write-Through-Cache über dem Objektspeicher. Sie speichern asynchron materialisierte Seiten in Cloud-Objektspeicher, und die Seitenrekonstruktion blockiert keinen Transaktionscommit.

Cloudobjektspeicher

Cloud-Objektspeicherung ist die Haltbarkeitsgrundlage für die gesamte Speicherschicht. Es speichert die Seitendaten, die Pageserver speichern.

Auf Azure speichert Lakebase Daten in Azure Blob Storage.

Die Objektspeicherung bleibt außerhalb des Hot-Query-Pfads. Nur Pageserver lesen daraus ab. Für Details darüber, wie Speicherredundanz funktioniert und warum sie unabhängig von der Einstellung für hohe Rechenverfügbarkeit ist, siehe Speicherarchitektur.

Wie ein Schreiben funktioniert

Ein Schreiben fließt von der Berechnung durch die Speicherschicht:

1. Postgres modifiziert die betroffenen Seiten im Speicher und erstellt WAL-Datensätze.
2. Compute streamt die WAL-Datensätze an die Safekeeper.
3. Wenn ein Quorum von Safekeepern die Unterlagen bestätigt, wird die Transaktion durchgeführt und der Kunde erhält Erfolg.
4. Pageserver wenden das WAL asynchron an und speichern die aktualisierten Seiten im Objektspeicher.

Eine Transaktion ist dauerhaft, sobald ein Quorum von Safekeepern den WAL-Datensatz hat, weil allein das Protokoll ausreicht, um die Daten zu rekonstruieren. Pageserver bauen die Datenseiten danach wieder auf und speichern sie abseits des Commit-Pfads, sodass die Schreibvorgänge schnell bleiben, ohne eine festgelegte Änderung zu gefährden.

Wie eine Lektüre funktioniert

Reads prüfen eine Hierarchie von Caches, von schnellsten bis langsamsten, und stoppen auf der ersten Schicht, die die Seite enthält:

1. Pufferpool (Speicher): Die Postgres teilten sich Puffer im Rechen-RAM.
2. Lokaler Rechencache: Ein festplattengestützter Cache auf dem Rechenknoten, der relativ zum Speicher des Rechens dimensioniert ist.
3. Seitenbediener: Bei einem Cache-Miss fordert Compute die Seite von einem Pageserver an, der sie am angeforderten LSN rekonstruiert.
4. Objektspeicherung: Der Pageserver liest bei Bedarf intern aus dem Objektspeicher. Abfragen erreichen nicht direkt den Objektspeicher.

Was diese Architektur ermöglicht

Die Trennung zustandsloser Berechnung von dauerhaftem Speicher macht mehrere Lakebase-Funktionen möglich:

Funktion	Was dies ermöglicht
Automatische Skalierung	Da Rechenleistung stateless ist, skaliert Lakebase die Rechengröße entsprechend der Arbeitsbelastung, ohne Daten zu verschieben.
Auf-Null-Skalierung	Die Berechnung kann vollständig pausieren, während der Speicher vorhanden ist, und die Daten sind sofort verfügbar, wenn die Rechenleistung wieder aufgenommen wird.
Sofortzweige	Erstellen Sie innerhalb von Sekunden eine isolierte, beschreibbare Kopie Ihrer Datenbank. Da Verzweigung eine Copy-on-Write-Metadaten-Operation gegen den gemeinsamen Speicher ist, dupliziert es keine Daten.
Lesen von Replikaten	Mehrere Recheninstanzen lesen aus derselben Speicherschicht, daher benötigen Replikate keine Datenkopien und starten innerhalb von Sekunden.
Zeitpunkt-Abfragen	Da die Speicherschicht den Verlauf speichert, kann Compute an einen vergangenen Zeitpunkt anhängen und die Datenbank so lesen, wie sie damals existierte, ohne Daten zurückzukopieren.
Schnelles Failover	Failover bewirbt eine sekundäre Compute-Instanz, die an den bestehenden Speicher angeschlossen wird, ohne Daten zu verschieben.
RPO = 0 (kein verpflichteter Datenverlust)	Lakebase zeichnet jede zugesagte Transaktion dauerhaft auf, bevor sie bestätigt wird, sodass du keine verpflichteten Daten verlierst, wenn die Berechnung ausfällt, neu startet oder auf null skaliert.

Wie diese Architektur LTAP unterstützt

Da Lakebase jede festgelegte Änderung in der Cloud-Objektspeicherung dauerhaft speichert, können dieselben Daten analytische Workloads neben Transaktionen bedienen, ohne eine separate Replikationspipeline. Dies bildet die Grundlage für Lake Transactional and Analytical Processing (LTAP), bei dem eine einzige Kopie Ihrer Daten sowohl transaktionale als auch analytische Engines unterstützt. Um zu erfahren, wie LTAP auf dieser Architektur aufbaut, siehe LTAP-Architektur.

Nächste Schritte

• Speicherarchitektur: Erfahren Sie, wie Speicherredundanz funktioniert und warum sie unabhängig von der Einstellung für hohe Rechenverfügbarkeit ist. Siehe Speicherarchitektur.
• Datenbankzweige: Sehen Sie, wie Branche Copy-on-Write-Speicher nutzen, um sofortige, isolierte Umgebungen zu schaffen. Siehe Verzweigungen.
• Lesen Sie Repliken: Fügen Sie schreibgeschützte Compute-Instanzen hinzu, die dieselbe Speicherschicht teilen. Siehe Lesen von Replikaten.
• Kernkonzepte: Überprüfen Sie das gesamte Set an Konzepten, die Lakebase einzigartig machen. Siehe Kernkonzepte.