Branching del database in Postgres: flussi di lavoro in stile Git con Databricks Lakebase

Il database è l'ultimo collo di bottiglia nel tuo flusso di lavoro di sviluppo

La gestione delle branch del database è la funzionalità mancante nei moderni flussi di lavoro di sviluppo. Ogni altra parte dello stack si è evoluta per supportare iterazioni rapide. Il codice ha Git. L'infrastruttura ha Terraform. Le distribuzioni hanno pipeline CI/CD che vengono eseguite in pochi minuti. Ma i database relazionali funzionano ancora come dieci anni fa.

La maggior parte dei team condivide un unico database di staging. Entro pochi giorni dalla configurazione, quel database non è più sincronizzato con la produzione. Gli schemi divergono man mano che gli sviluppatori applicano le migrazioni in ordini diversi. I valori delle sequenze non corrispondono più. I dati di test si accumulano e inquinano i risultati. Qualcuno alla fine riavvia tutto, e il ciclo ricomincia.

La configurazione di un nuovo ambiente è peggiore. L'approccio standard è eseguire pg_dump sulla produzione, attendere il completamento (da minuti a ore a seconda delle dimensioni del database), caricarlo in una nuova istanza, configurare l'accesso e sperare che il risultato rifletta effettivamente ciò che è in esecuzione in produzione. Per un database da 500 GB, ciò significa un'operazione di copia da 500 GB, più il calcolo e lo storage per mantenerlo in esecuzione.

Il risultato è prevedibile. I team evitano di creare nuovi ambienti perché sono troppo costosi e troppo lenti. Gli sviluppatori condividono un unico database di staging modificabile. Le migrazioni vengono testate su dati obsoleti, o non testate affatto. Le anteprime delle distribuzioni vengono eseguite su fixture vuote invece che su schemi realistici. I test CI condividono lo stato e producono risultati instabili.

Il database diventa la parte dello stack che gli sviluppatori hanno paura di toccare.

Databricks Lakebase Postgres cambia tutto questo con la gestione delle branch del database.

Cos'è effettivamente la gestione delle branch del database

Una branch del database non è una copia del database. Questa distinzione è importante perché cambia completamente l'economia degli ambienti isolati.

Quando copi un database, duplichi tutti i suoi dati e schemi in una nuova istanza indipendente. Il tempo e il costo scalano linearmente con le dimensioni del database. Ogni copia è un clone completo, e ogni clone inizia a diventare obsoleto dal momento in cui viene creato.

Una branch funziona in modo diverso. Quando crei una branch in Lakebase, ottieni un nuovo ambiente Postgres completamente isolato che:

• Inizia dallo schema e dai dati esatti del suo genitore in un punto specifico nel tempo
• Condivide lo stesso storage sottostante invece di duplicarlo
• Scrive nuovi dati solo quando effettivamente apporti modifiche

Questo si chiama copy-on-write. Finché due branch non divergono, fanno riferimento agli stessi dati memorizzati. Quando esegui una migrazione, inserisci righe o modifichi tabelle su una branch, solo queste modifiche vengono scritte separatamente. Tutto il resto viene condiviso con il genitore.

Copia del database vs. branch del database

In termini pratici, ciò significa:

• La creazione di branch richiede secondi, indipendentemente dalle dimensioni del database. Un database da 10 GB e uno da 2 TB vengono creati in branch nello stesso lasso di tempo.
• Il costo di archiviazione è proporzionale alle modifiche, non alla dimensione totale dei dati. Una branch che modifica 50 MB di dati in un database da 500 GB utilizza circa 50 MB di storage aggiuntivo.
• Ogni branch ottiene la propria stringa di connessione Postgres e endpoint di calcolo. Le branch sono completamente isolate l'una dall'altra e dal loro genitore.
• Le branch inattive scalano automaticamente il calcolo a zero. Paghi solo per il calcolo attivo quando una branch viene effettivamente utilizzata.

Le branch sono progettate per essere create, utilizzate e scartate liberamente. Da sviluppatori, da pipeline CI, da agenti AI, da automazione. Non sono ambienti preziosi che necessitano di essere mantenuti. Sono usa e getta, come le branch Git.

L'architettura che rende possibile la gestione delle branch del database

Il tradizionale Postgres gestito (RDS, Azure Database for PostgreSQL) lega insieme calcolo e storage. Il processo del database e i suoi dati risiedono sulla stessa istanza, e i dati sono memorizzati come un singolo filesystem modificabile. Ecco perché la copia è l'unica opzione per creare un secondo ambiente: devi duplicare il filesystem.

Ma un lakebase è costruito diversamente. Separa completamente calcolo e storage. Tutti i dati vengono scritti su un motore di storage distribuito e versionato che registra ogni modifica come una nuova versione invece di sovrascrivere i dati esistenti. Questa architettura log-struct è ciò che rende possibile la gestione delle branch del database come primitiva piuttosto che come funzionalità sovrapposta.

Poiché lo storage è versionato, più branch possono fare riferimento agli stessi dati sottostanti senza rischio di conflitti. Poiché il calcolo è indipendente, ogni branch esegue il proprio processo Postgres e scala autonomamente. Le branch non di produzione che rimangono inattive scalano a zero automaticamente e si riavviano in millisecondi quando arriva una connessione.

Non tutte le implementazioni di branch del database sono uguali. Alcune piattaforme creano copie complete dell'istanza e le chiamano branch. Altre creano branch solo dello schema, senza dati. Le branch Lakebase includono sia schema che dati, utilizzano copy-on-write a livello di storage per evitare duplicazioni e forniscono calcolo indipendente e autoscalabile per ogni branch. Questo è ciò che rende pratico creare branch liberamente e su larga scala, senza provisioning di infrastrutture aggiuntive.

Questa architettura abilita anche il time travel. Poiché ogni versione dei dati viene conservata all'interno di una finestra di ripristino configurabile, è possibile creare una branch da qualsiasi punto del passato, non solo dallo stato corrente. Questo è ciò che alimenta il ripristino istantaneo point-in-time: invece di riprodurre i log WAL o ripristinare un backup, crei una branch al timestamp desiderato e leggi direttamente da essa.

Cosa sblocca la gestione delle branch del database per il tuo team

Una volta che la gestione delle branch del database diventa una primitiva veloce ed economica invece di un'operazione di copia costosa, nuovi flussi di lavoro diventano pratici. Ecco un riepilogo dei modelli più comuni. (Copriremo ciascuno di questi in dettaglio nel prossimo post di questa serie.)

Una branch per sviluppatore. Ogni ingegnere ottiene il proprio ambiente isolato con dati simili alla produzione. Niente più calpestamenti delle modifiche reciproche in un database di sviluppo condiviso. Quando una branch diverge troppo dalla produzione, reimpostala con un comando per recuperare lo schema e i dati più recenti. Poiché le branch scalano a zero quando sono inattive, questo modello rimane conveniente anche per team numerosi.

Una branch per pull request. Automatizza la creazione della branch quando una PR viene aperta e la sua eliminazione quando viene unita o chiusa. Le anteprime delle distribuzioni su Vercel o Netlify ottengono ciascuna la propria branch del database, quindi la tua anteprima frontend è supportata da dati realistici e isolati. Le migrazioni vengono eseguite su forme e vincoli di dati reali, non su fixture di test vuote. Questo è il flusso di lavoro che i team adottano per primi, ed è quello che tende a convincerli ad adottare la gestione delle branch del database a tutto tondo.

Una branch per ogni esecuzione di test. Le pipeline CI ottengono un database fresco e isolato per ogni esecuzione. Nessuno stato residuo dai test precedenti. Nessuna attesa che un'immagine container vuota si avvii e poi venga popolata con dati fittizi. Nessun risultato instabile causato da dati condivisi o dipendenze dall'ordine dei test. Ogni esecuzione inizia dalla stessa baseline. Per i test che richiedono dati deterministici, è possibile creare branch da un punto fisso nel tempo o da un numero di sequenza di log (LSN) specifico.

Ripristino istantaneo. Crea un branch da qualsiasi punto nel tempo all'interno della tua finestra di ripristino. Ispeziona tabelle eliminate, esegui il debug di migrazioni fallite o controlla dati storici, il tutto senza toccare la produzione. Usa il confronto degli schemi per confrontare lo stato prima e dopo una modifica. Esporta ciò di cui hai bisogno dal branch di ripristino ed eliminalo. L'intero processo richiede secondi, non le ore o i giorni richiesti dal tradizionale PITR.

Ambienti effimeri per agenti AI. Gli agenti AI possono eseguire il provisioning dei database programmaticamente tramite l'API Lakebase, utilizzarli per la durata di un'attività e chiuderli al termine. Le piattaforme possono creare versioning sopra gli snapshot: ogni azione dell'agente crea un checkpoint e gli utenti possono passare istantaneamente tra le versioni. Se un agente esegue una migrazione errata o corrompe i dati, il rollback è una singola chiamata API.

Iniziare

Il branching del database in Databricks Lakebase trasforma il tuo database Postgres dalla parte più lenta del tuo flusso di lavoro di sviluppo alla più veloce.

Puoi creare il tuo primo branch in meno di un minuto utilizzando la console, la CLI o l'API. Ecco come appare dalla CLI:

Fatto. Ora hai un ambiente Postgres isolato con lo schema completo e i dati dalla produzione, pronto per l'uso.

Se stai sviluppando su Postgres e sei stanco dell'overhead che deriva dalla gestione degli ambienti di database, inizia con un singolo branch di sviluppo. Quindi provane uno per PR. La maggior parte dei team che iniziano con un flusso di lavoro di branching del database ne adotta rapidamente gli altri.

Databricks Lakebase è un Postgres serverless costruito per agenti e app. Ulteriori informazioni su databricks.com/product/lakebase.

(Questo post sul blog è stato tradotto utilizzando strumenti basati sull'intelligenza artificiale) Post originale