Architettura della base lacustre

Lakebase separa l'archiviazione dal calcolo. Il motore Postgres che gestisce le tue query è senza stato e i tuoi dati vivono in uno strato di archiviazione duratura che persiste indipendentemente. Questa separazione è ciò che rende possibile l'autoscaling, la scala a zero, i branch istantanei, le repliche di lettura e il failover rapido.

Per mostrare cosa cambia Lakebase, questa pagina inizia con il tradizionale design di database a macchina singola per contrasto, poi spiega come Lakebase separa lo stesso design in strati indipendenti e cosa fa ciascun pezzo.

Come viene costruito un database tradizionale

Prima di guardare a Lakebase, considera il modello che sostituisce. Un database convenzionale di Postgres è un monolite. Una singola macchina esegue il motore di query e scrive sia il write-ahead log (WAL) sia i file dati su un disco collegato in un punto di montaggio locale. Tradizionalmente questi dischi erano veramente locali, parte della stessa macchina, ma con l'evoluzione dell'infrastruttura sono spesso dispositivi di archiviazione collegati alla rete.

Il WAL e i file dati svolgono due ruoli complementari:

• Il WAL accelera le scritture. Postgres aggiunge ogni modifica al log in sequenza prima di confermare un commit, che è veloce e durabile su un singolo disco.
• I file dati accelerano le letture. Postgres materializza la versione corrente di ogni pagina in file dati, così una query può leggere una riga senza riprodurre il log.

Accedere a tutti i tuoi dati tramite una sola macchina presenta degli svantaggi:

• La durabilità è direttamente legata all'infrastruttura fisica di quella macchina. Devi anche pre-fornire lo storage e prevedere quanto crescerà il carico di lavoro, il che complica sia la gestione dei costi che la pianificazione della resilienza.
• L'alta disponibilità e molti tipi di scaling orizzontale richiedono cloni fisici dell'intero database.
• Se quella macchina si guasta, puoi perdere dati. Tecniche come lo storage RAID riducono questo rischio, ma la ridondanza aggiuntiva può aumentare significativamente il costo di gestione del sistema.

L'architettura di Lakebase

Lakebase mantiene le stesse responsabilità ma le divide in due livelli indipendenti:

• Un livello di calcolo che esegue Postgres standard e senza stato.
• Uno strato di archiviazione composto da safekeeper, pageserver e storage cloud oggetti.

I due ruoli del monolite si mappano direttamente sui nuovi componenti. Il WAL, che accelerava le scritture, diventa il custodio di sicurezza, che scala le scritture. I file dati, che acceleravano le letture, diventano i server di paging, che scalano le letture.

Poiché i dati vivono in archiviazione cloud degli oggetti piuttosto che su una singola macchina, Lakebase offre calcolo elastico e scalabile e scritture durature replicate tra le zone di disponibilità. Non c'è spazio di archiviazione da fornire: paghi solo per quello che consumi, e non devi pianificare intorno a modalità di guasto come esaurire il disco.

Questo modello migliora anche le prestazioni. Lakebase scrive ogni modifica direttamente in più località, così evita il sovraccarico della tradizionale protezione contro la scrittura strappata e dell'allineamento dei blocchi. Poiché ogni scrittura va già a più località, le prestazioni rimangono costanti indipendentemente dal fatto che l'alta disponibilità sia abilitata o meno.

La tabella seguente mappa ogni parte del monolite alla sua controparte di Lakebase.

Livello di calcolo

Il livello di calcolo esegue Postgres. Contiene solo uno stato transitorio: il Postgres condivide buffer in memoria e una cache di calcolo locale supportata da un disco locale veloce. Non possiede dati duraturi.

Poiché il calcolo non possiede uno stato durevole:

• Può essere sostituito, riavviato, scalato automaticamente o ridimensionato a zero senza spostare o perdere dati.
• Invece di scrivere su un filesystem locale, trasmette il WAL al livello di archiviazione.
• Più istanze di calcolo possono collegarsi allo stesso livello di storage, ed è come funzionano le repliche di lettura di Lakebase e il fallover rapido .

Livello di archiviazione

Il livello di archiviazione è resistente e funziona indipendentemente dal calcolo. Ha tre componenti.

Custodi di sicurezza

I custodi di sicurezza sono il WAL, estratto dalla singola macchina e reso altamente disponibile. Man mano che Postgres produce i record WAL, li trasmette in streaming a un gruppo di custodi di sicurezza che replicano il log attraverso un quorum utilizzando un protocollo di consenso basato su Paxos.

Una transazione si impegna quando un quorum di custodi di sicurezza riconosce il record WAL, non quando una singola macchina completa un record locale fsync. La durabilità deriva dalla replicazione tra i nodi piuttosto che da un singolo disco.

Pageserver

I server di paging sono i file dati, estratti e ricostruiti dal WAL. Un pageserver consuma lo stream WAL dai safekeeper e materializza le versioni delle pagine su richiesta. Quando il calcolo richiede una pagina a un numero di sequenza di log (LSN) specifico, il pageserver la ricostruisce e la restituisce.

I pageserver agiscono come una cache write-through sopra lo storage degli oggetti. Persistono asincronamente le pagine materializzate verso l'archiviazione cloud degli oggetti, e la ricostruzione delle pagine non blocca il commit di una transazione.

Archiviazione di oggetti cloud

L'archiviazione degli oggetti nel cloud è la base di durabilità per l'intero livello di archiviazione. Contiene i dati di pagina che i pageserver persistono.

Su Azure, Lakebase persiste i dati su Archiviazione BLOB di Azure.

Lo storage degli oggetti rimane fuori dal percorso delle query calde. Solo i server di paging leggono da esso. Per dettagli su come funziona la ridondanza dello storage e perché sia indipendente dall'impostazione di alta disponibilità di calcolo, vedi Architettura dello storage.

Come funziona una scrittura

Una scrittura fluisce dal calcolo attraverso il livello di storage:

1. Postgres modifica le pagine interessate in memoria e produce record WALL.
2. Compute trasmette i record WAL ai custodi di sicurezza.
3. Quando un quorum di custodi riconosce i registri, la transazione si impegna e il cliente ottiene successo.
4. I server di paging applicano il WAL in modo asincrono e persistono le pagine aggiornate nello storage degli oggetti.

Una transazione è duratura non appena un quorum di custodi di sicurezza possiede il record WALL, perché il solo registro è sufficiente per ricostruire i dati. I pageserver ricostruiscono e memorizzano le pagine dati dopo, fuori dal percorso di commit, così le scritture restano veloci senza mettere a rischio alcun cambiamento commesso.

Come funziona una lettura

Le letture controllano una gerarchia di cache, dal più veloce al più lento, e si fermano al primo livello che contiene la pagina:

1. Pool di buffer (memoria): Il Postgres condivideva buffer nella RAM di calcolo.
2. Cache di calcolo locale: Una cache supportata su disco sul nodo di calcolo, dimensionata rispetto alla memoria del calcolo.
3. Pageserver: In caso di cache miss, il calcolo richiede la pagina da un pageserver, che la ricostruisce al LSN richiesto.
4. Archiviazione oggetti: Il pageserver legge internamente dall'object storage quando necessario. Le query non raggiungono direttamente l'archiviazione degli oggetti.

Cosa consente questa architettura

Separare il calcolo senza stato dallo storage duraturo è ciò che rende possibili diverse funzionalità di Lakebase:

Come questa architettura supporta LTAP

Poiché Lakebase memorizza in modo duraturo ogni modifica commessa nell'archiviazione cloud degli oggetti, gli stessi dati possono servire carichi di lavoro analitici insieme alle transazioni senza una pipeline di replica separata. Questa è la base per Lake Transactional and Analytical Processing (LTAP), dove una singola copia dei tuoi dati supporta sia motori transazionali che analitici. Per capire come LTAP si basa su questa architettura, vedi architettura LTAP.

Passaggi successivi

• Architettura dello storage: Scopri come funziona la ridondanza dello storage e perché è indipendente dall'impostazione di alta disponibilità di calcolo. Vedere Architettura di archiviazione.
• Rami del database: Scopri come i branch utilizzano lo storage copy-on-write per creare ambienti istantanei e isolati. Vedi Branches.
• Leggi repliche: Aggiungi istanze di calcolo in sola lettura che condividono lo stesso livello di archiviazione. Consultare Repliche in lettura.
• Concetti fondamentali: Rivedi l'intero insieme di concetti che rendono Lakebase unico. Vedi Concetti fondamentali.