Sjöbasarkitektur

Lakebase separerar lagring från beräkning. Postgres-motorn som kör dina frågor är tillståndslös, och dina data finns i ett robust lagringslager som består oberoende. Denna separation är det som gör autoskalning, skalning till noll, omedelbara grenar, läsrepliker och snabb failover möjlig.

För att visa vad Lakebase ändrar börjar denna sida med den traditionella databasdesignen med en enda maskin för kontrast, och förklarar sedan hur Lakebase delar upp samma design i oberoende lager och vad varje del gör.

Hur en traditionell databas byggs

Innan du tittar på Lakebase, fundera på vilken modell det ersätter. En konventionell Postgres-databas är en monolit. En enda maskin kör frågemotorn och skriver både write-ahead loggen (WAL) och datafilerna till en disk ansluten vid en lokal monteringspunkt. Traditionellt var dessa diskar verkligen lokala, en del av samma maskin, men när infrastrukturen utvecklades är de ofta nätverksanslutna lagringsenheter istället.

WAL- och datafilerna spelar två kompletterande roller:

• WAL snabbar upp skrivningar. Postgres lägger till varje ändring i loggen sekventiellt innan en commit bekräftas, vilket är snabbt och hållbart på en enda disk.
• Datafilerna snabbar upp läsningarna. Postgres materialiserar den aktuella versionen av varje sida i datafiler, så att en fråga kan läsa en rad utan att spela upp loggen igen.

Att komma åt all din data via en maskin har nackdelar:

• Hållbarhet är direkt kopplad till maskinens fysiska infrastruktur. Du måste också försäkra lagring och förutsäga hur mycket din arbetsbelastning kommer att växa, vilket komplicerar både kostnadshantering och resiliensplanering.
• Hög tillgänglighet och många typer av horisontell skalning kräver fysiska kloner av hela databasen.
• Om den maskinen går sönder kan du förlora data. Tekniker som RAID-lagring minskar denna risk, men den ökade redundansen kan avsevärt öka kostnaden för att driva systemet.

Lakebase-arkitekturen

Lakebase behåller samma ansvar men delar upp dem i två oberoende lager:

• Ett beräkningslager som kör standard, tillståndslös Postgres.
• Ett lagringslager bestående av safekeepers, sidservrar och molnbaserad objektlagring.

De två rollerna från monoliten avbildas direkt till de nya komponenterna. WAL, som snabbare skriver, blir safekeepers, som skalar skriver. Datafilerna, som snabbar upp läsningarna, blir sidservrar, som skalar läsningar.

Eftersom data finns i molnobjektlagring istället för på en enda maskin, levererar Lakebase elastisk, skalbar beräkning och hållbara skrivningar som replikeras över tillgänglighetszoner. Det finns inget lagringsutrymme att provisionera: du betalar bara för det lagringsutrymme du förbrukar, och du behöver inte planera kring fel-lägen som att disken tar slut.

Denna modell förbättrar också prestandan. Lakebase skriver varje ändring direkt till flera platser, så det undviker överhuvudet med traditionellt torn-write-skydd och blockjustering. Eftersom varje skrivning redan går till flera platser förblir prestandan konsekvent oavsett om hög tillgänglighet är aktiverad eller inte.

Följande tabell avbildar varje del av monoliten till dess motsvarighet i Lakebase.

Beräkningslager

Beräkningslagret kör Postgres. Den har endast tillfälligt tillstånd: Postgres delade buffertar i minnet och en lokal beräkningscache som backas upp av snabb lokal disk. Den äger inga hållbara data.

Eftersom beräkning inte äger något varaktigt tillstånd:

• Den kan ersättas, startas om, autoskalas eller skalas till noll utan att flytta eller förlora data.
• Istället för att skriva till ett lokalt filsystem strömmar den WAL till lagringslagret.
• Flera beräkningsinstanser kan ansluta till samma lagringslager, vilket är hur Lakebase läsrepliker och snabb failover fungerar.

Lagringsskikt

Lagringslagret är hållbart och fungerar oberoende av beräkning. Den har tre komponenter.

Kassaskåpsvakter

Safekeepers är WAL, hämtade ur den enda maskinen och gjort mycket tillgängliga. När Postgres producerar WAL-poster strömmar de dem till en grupp safekeepers som replikerar loggen över ett quorum med hjälp av ett Paxos-baserat konsensusprotokoll.

En transaktion genomförs när ett antal safekeepers bekräftar WAL-posten, inte när en enskild maskin avslutar en lokal fsync. Hållbarhet kommer från replikation över noder snarare än från en enda disk.

Sidservrar

Pageservers är datafilerna som tas ut och byggs upp igen från WAL. En sidserver konsumerar WAL-strömmen från safekeepers och materialiserar sidversioner på begäran. När beräkningen begär en sida med ett specifikt loggsekvensnummer (LSN), rekonstruerar sidservern och returnerar den.

Sidservrar fungerar som en write-through-cache ovanför objektlagring. De lagrar asynkront materialiserade sidor till molnobjektlagring, och sidrekonstruktion blockerar inte en transaktionscommit.

Lagring av molnobjekt

Molnlagring av objekt är hållbarhetsgrunden för hela lagringslagret. Den lagrar siddata som sidservrar lagrar.

På Azure persists Lakebase data to Azure Blob Storage.

Objektlagring håller sig utanför den snabba frågevägen. Endast sidservrar läser från den. För detaljer om hur lagringsredundans fungerar och varför den är oberoende av inställningen för hög tillgänglighet till beräkning, se Lagringsarkitektur.

Hur en skrivare fungerar

En skrivning flödar från beräkning genom lagringslagret:

1. Postgres modifierar de drabbade sidorna i minnet och producerar WAL-poster.
2. Compute strömmar WAL-registren till kassaskåpsförvararna.
3. När ett antal safekeepers bekräftar handlingarna genomförs transaktionen och klienten får framgång.
4. Sidservrar applicerar WAL asynkront och behåller de uppdaterade sidorna i objektlagringen.

En transaktion är hållbar så snart ett antal safekeepers har WAL-posten, eftersom loggen ensam räcker för att rekonstruera datan. Pageservers bygger om och lagrar datasidorna efteråt, utanför commit-vägen, så att skrivningarna förblir snabba utan att riskera någon bestämd ändring.

Hur en läsning fungerar

Läsningar kontrollerar en hierarki av cacher, från snabbast till långsammast, och stannar vid det första lagret som har sidan:

1. Buffertpool (minne): Postgres delade buffertar i beräknings-RAM.
2. Lokal beräkningscache: En diskbackad cache på beräkningsnoden, storlek i förhållande till beräkningens minne.
3. Sidserver: Vid en cachemiss begär compute sidan från en sidserver, som rekonstruerar den vid det begärda LSN.
4. Objektlagring: Sidservern läser internt från objektlagring vid behov. Förfrågningar når inte objektlagring direkt.

Vad denna arkitektur möjliggör

Att skilja tillståndslös beräkning från hållbar lagring är det som gör flera Lakebase-funktioner möjliga:

Hur denna arkitektur stödjer LTAP

Eftersom Lakebase varaktigt lagrar varje engagerad ändring i molnobjektlagring kan samma data hantera analytiska arbetsbelastningar tillsammans med transaktioner utan en separat replikeringspipeline. Detta är grunden för Lake Transactional and Analytical Processing (LTAP), där en enda kopia av din data stödjer både transaktionella och analytiska motorer. För att lära dig hur LTAP bygger vidare på denna arkitektur, se LTAP-arkitekturen.

Nästa steg

• Lagringsarkitektur: Lär dig hur lagringsredundans fungerar och varför den är oberoende av inställningen för hög tillgång till beräkning. Se Lagringsarkitektur.
• Databasgrenar: Se hur grenar använder copy-on-write-lagring för att skapa omedelbara, isolerade miljöer. Se Brancher.
• Läs kopior: Lägg till skrivskyddade beräkningsinstanser som delar samma lagringslager. Se Läs repliker.
• Kärnkoncept: Gå igenom hela uppsättningen av koncept som gör Lakebase unik. Se Kärnkoncept.