Architectuur van de meerbasis

Lakebase scheidt de opslag van de rekenkracht. De Postgres-engine die je quers uitvoert is stateless, en je data bevindt zich in een duurzame opslaglaag die onafhankelijk blijft bestaan. Deze scheiding maakt autoscaling, schaal-tot-nul, instant branches, read replicas en snelle failover mogelijk.

Om te laten zien wat Lakebase verandert, begint deze pagina met het traditionele, enkelvoudige databaseontwerp voor contrast, en legt vervolgens uit hoe Lakebase datzelfde ontwerp opsplitst in onafhankelijke lagen en wat elk onderdeel doet.

Hoe een traditionele database wordt opgebouwd

Voordat je naar Lakebase kijkt, overweeg het model dat het vervangt. Een conventionele Postgres-database is een monoliet. Een enkele machine voert de query-engine uit en schrijft zowel het write-ahead log (WAL) als de databestanden naar een schijf die is aangesloten op een lokaal mountpoint. Traditioneel waren deze schijven echt lokaal, onderdeel van dezelfde machine, maar naarmate de infrastructuur zich ontwikkelde, zijn ze vaak netwerk-aangesloten opslagapparaten.

De WAL- en databestanden vervullen twee complementaire rollen:

• De WAL versnelt het schrijven. Postgres voegt elke wijziging sequentieel toe aan het logboek voordat een commit wordt bevestigd, die snel en duurzaam is op één enkele schijf.
• De databestanden versnellen het lezen. Postgres materialiseert de huidige versie van elke pagina in databestanden, zodat een query een rij kan lezen zonder het logboek opnieuw af te spelen.

Toegang tot al je data via één machine heeft nadelen:

• Duurzaamheid is direct gekoppeld aan de fysieke infrastructuur van die machine. Je moet ook opslag vooraf inrichten en voorspellen hoeveel je werklast zal groeien, wat zowel kostenbeheer als veerkrachtplanning bemoeilijkt.
• Hoge beschikbaarheid en veel soorten horizontale schaalverdeling vereisen fysieke klonen van de hele database.
• Als die machine uitvalt, kun je data verliezen. Technieken zoals RAID-opslag verminderen dit risico, maar de extra redundantie kan de kosten van het beheren van het systeem aanzienlijk verhogen.

De architectuur van de Lakebase

Lakebase behoudt dezelfde verantwoordelijkheden, maar verdeelt deze in twee onafhankelijke lagen:

• Een rekenlaag die standaard, stateless Postgres draait.
• Een opslaglaag bestaande uit safekeepers, pageservers en cloudobjectopslag.

De twee rollen van de monoliet worden direct afgestemd op de nieuwe componenten. De WAL, die versnelde schrijfopdrachten heeft, wordt de safekeepers, die schaal schrijft. De databestanden, die het lezen versnelden, worden de paginaservers, die de leesacties opschalen.

Omdat data zich in cloudobjectopslag bevindt in plaats van op één enkele machine, levert Lakebase elastische, schaalbare rekenkrachten en duurzame schrijfopdrachten die over beschikbaarheidszones heen worden gerepliceerd. Er is geen opslag om te provisioneren: je betaalt alleen voor de opslag die je verbruikt, en je hoeft niet te plannen rond faalmodi zoals het opraken van een schijf.

Dit model verbetert ook de prestaties. Lakebase schrijft elke wijziging direct naar meerdere locaties, zodat het de overhead van traditionele rip-write-bescherming en blokuitlijning vermijdt. Omdat elke schrijf al naar meerdere locaties gaat, blijft de prestatie consistent, ongeacht of hoge beschikbaarheid is ingeschakeld of niet.

De volgende tabel brengt elk deel van de monoliet in kaart met zijn tegenhanger in Lakebase.

Traditionele monoliet	Lakebase	Role
Enkele machine	Stateloze berekening	Draait de Postgres-query-engine
Lokale WAL-schijf	Kluizenhouders	Duurzaam registreert elke gecommitteerd wijziging
Lokale databestanden	Paginaservers en objectopslag	Materialiseert en slaat paginaversies op

Rekenlaag

De rekenlaag draait Postgres. Het bevat alleen een tijdelijke toestand: de gedeelde Postgres-buffers in het geheugen en een lokale rekencache ondersteund door een snelle lokale schijf. Het bezit geen duurzame data.

Omdat compute geen duurzame toestand bezit:

• Het kan worden vervangen, opnieuw opgestart, automatisch geschaald of tot nul worden geschaald zonder data te verplaatsen of te verliezen.
• In plaats van naar een lokaal bestandssysteem te schrijven, streamt het de WAL naar de opslaglaag.
• Meerdere compute-instanties kunnen aan dezelfde opslaglaag worden gekoppeld, wat de manier is waarop Lakebase read-replica's en snelle failover werken.

Opslaglaag

De opslaglaag is duurzaam en werkt onafhankelijk van de rekenkracht. Het bestaat uit drie componenten.

Kluizenhouders

Safekeepers zijn de WAL, die uit de enkele machine worden gehaald en zeer beschikbaar worden gemaakt. Terwijl Postgres WAL-records produceert, streamt het deze naar een groep safekeepers die het logboek over een quorum repliceren met behulp van een op Paxos gebaseerd consensusprotocol.

Een transactie wordt gecommitteerd wanneer een quorum van safekeepers het WAL-record bevestigt, niet wanneer een enkele machine een lokale fsync. Duurzaamheid komt voort uit replicatie over nodes in plaats van vanaf één schijf.

Paginaservers

Pageservers zijn de databestanden die uit de WAL worden gehaald en opnieuw opgebouwd. Een pageserver verbruikt de WAL-stroom van de safekeepers en materialiseert paginaversies op aanvraag. Wanneer compute een pagina aanvraagt met een specifiek logvolgordenummer (LSN), reconstrueert de pageserver deze en retourneert deze.

Pageservers fungeren als een write-through cache boven objectopslag. Ze blijven asynchroon gematerialiseerde pagina's naar cloudobjectopslag, en paginareconstructie blokkeert geen transactiecommit.

Cloudopslag van objecten

Cloud-objectopslag is de duurzaamheidsbasis voor de hele opslaglaag. Het bevat de paginagegevens die pageservers behouden.

Op Azure persists Lakebase data to Azure Blob Storage.

Objectopslag blijft buiten het hot query-pad. Alleen pageservers lezen eruit. Voor details over hoe opslagredundantie werkt en waarom het onafhankelijk is van de instelling voor hoge beschikbaarheid van rekenkracht, zie Opslagarchitectuur.

Hoe een schrijver werkt

Een schrijf stroomt van de compute via de opslaglaag:

1. Postgres wijzigt de getroffen pagina's in het geheugen en produceert WAL-records.
2. Compute streamt de WAL-records naar de safekeepers.
3. Wanneer een quorum van safekeepers de gegevens bevestigt, wordt de transactie gecommunt en behaalt de cliënt succes.
4. Pageservers passen de WAL asynchroon toe en behouden de bijgewerkte pagina's in objectopslag.

Een transactie is duurzaam zodra een quorum van safekeepers het WAL-record heeft, omdat alleen het logboek voldoende is om de data te reconstrueren. Pageservers bouwen de datapagina's daarna opnieuw op en slaan ze op, buiten het commitpad, zodat schrijfacties snel blijven zonder enige gecommitteede wijziging in gevaar te brengen.

Hoe een leeswerk werkt

Reads controleren een hiërarchie van caches, van snelst naar langzaamst, en stoppen bij de eerste laag waarop de pagina staat:

1. Bufferpool (geheugen): De Postgres deelde buffers in compute-RAM.
2. Lokale rekencache: Een schijf-gebackde cache op de compute-node, van grootte ten opzichte van het geheugen van de compute.
3. Pageserver: Bij een cachemiss vraagt compute de pagina op bij een pageserver, die deze reconstrueert op het gevraagde LSN.
4. Objectopslag: De pageserver leest intern uit objectopslag wanneer dat nodig is. Queries bereiken niet direct de objectopslag.

Wat deze architectuur mogelijk maakt

Het scheiden van stateless compute van duurzame opslag is wat verschillende Lakebase-functies mogelijk maakt:

Feature	Wat het mogelijk maakt
Automatisch schalen	Omdat rekenkracht stateloos is, schaalt Lakebase de rekengrootte op of verkleinen als reactie op de werklast zonder data te verplaatsen.
Schaal naar nul	Compute kan volledig pauzeren terwijl de opslag blijft bestaan, en data is direct beschikbaar wanneer de compute wordt hervat.
Directe takken	Maak binnen enkele seconden een geïsoleerde, beschrijfbare kopie van je database. Omdat branching een copy-on-write metadata-operatie is tegen gedeelde opslag, dupliceert het geen data.
Leesreplica's	Meerdere compute-instanties worden gelezen vanaf dezelfde opslaglaag, dus replica's hebben geen datakopieën nodig en starten binnen enkele seconden.
Point-in-time queries	Omdat de opslaglaag geschiedenis behoudt, kan compute koppelen aan een vorig tijdstip en de database lezen zoals die toen bestond, zonder data terug te kopiëren.
Snelle failover	Failover bevordert een secundaire compute-instantie die aan de bestaande opslag wordt gekoppeld, zonder data om te verplaatsen.
RPO = 0 (geen gecommitteerd dataverlies)	Lakebase registreert elke toegewijde transactie duurzaam voordat deze wordt bevestigd, zodat je geen gecommitteerde data verliest wanneer de berekening faalt, opnieuw opstart of schaalt naar nul.

Hoe deze architectuur LTAP ondersteunt

Omdat Lakebase elke toegewijde wijziging in cloudobjectopslag duurzaam opslaat, kan dezelfde data analytische workloads naast transacties bedienen zonder een aparte replicatiepijplijn. Dit vormt de basis voor Lake Transactional and Analytical Processing (LTAP), waarbij één enkele kopie van uw data zowel transactionele als analytische engines ondersteunt. Om te leren hoe LTAP op deze architectuur voortbouwt, zie LTAP-architectuur.

Volgende stappen 

• Opslagarchitectuur: Leer hoe opslagredundantie werkt en waarom deze onafhankelijk is van de instelling voor hoge beschikbaarheid van rekenkracht. Zie opslagarchitectuur.
• Databasetakken: Bekijk hoe branches copy-on-write-opslag gebruiken om directe, geïsoleerde omgevingen te creëren. Zie Branches.
• Lees replica's: Voeg alleen-lezen compute-instanties toe die dezelfde opslaglaag delen. Zie Leesreplica's.
• Kernconcepten: Bekijk de volledige set concepten die Lakebase uniek maken. Zie Kernconcepten.