Una nuova era dei database: Lakebase

Per decenni, i database sono stati la spina dorsale del software: alimentando silenziosamente ogni cosa, dai flussi di checkout dell'e-commerce alla pianificazione delle risorse aziendali. Ogni pezzo di software al mondo, ogni applicazione, ogni flusso di lavoro, ogni riga di codice generata dall'intelligenza artificiale dipende in ultima analisi da un database sottostante. Lungo il percorso, abbiamo completamente reinventato il modo in cui vengono create le applicazioni, ma i database sottostanti sono cambiati molto poco dagli anni '80. Si basano in gran parte su architetture precedenti al cloud moderno e soffrono di quanto segue:

• Operazioni fragili e costose: i database tradizionali sono considerati uno dei pezzi di infrastruttura più delicati e il loro funzionamento affidabile richiede in genere un esercito di specialisti per "camminare sui gusci d'uovo". Raggruppano calcolo e archiviazione in un'unità rigida e monolitica. Questo costringe i team a effettuare il provisioning per la capacità di picco, portando a costose risorse inattive. Quando il carico supera la capacità di cui è stato effettuato il provisioning, i database possono diventare non reattivi. Peggio ancora, semplici attività di manutenzione come l'istantanea di un database o l'esecuzione di una query di pulizia GDPR possono potenzialmente mandare in crash l'intero database.
• Esperienza di sviluppo goffa: i database tradizionali si scontrano con i moderni flussi di lavoro di sviluppo agile. Per il codice, ci vuole meno di un secondo per creare un branch git per lo sviluppo che sia un clone completamente isolato della codebase. Per i database, ci vogliono molti minuti, se non ore, per eseguirne il provisioning e l'acquisizione di un clone ad alta fedeltà del database di produzione è molto costosa e rischia di mandare in crash il database di produzione. L'ascesa dello sviluppo guidato dall'intelligenza artificiale non ha fatto altro che intensificare questa pressione. Gli agenti di intelligenza artificiale devono avviare istantaneamente ambienti temporanei e isolati per la sperimentazione.
• Estremo vendor lock-in: le migrazioni di database sono uno dei progetti tecnici più spaventosi in qualsiasi organizzazione. L'architettura monolitica significa che l'unico modo per far entrare o uscire i dati è attraverso lo stesso motore di database. Ciò impone un significativo vendor lock-in, rendendo le organizzazioni profondamente dipendenti dallo specifico fornitore.

È ora che i database si evolvano.

Cos'è un Lakebase?

Stanno iniziando a emergere nuovi sistemi che affrontano i limiti dei database tradizionali. Un Lakebase è una nuova architettura aperta che combina i migliori elementi dei database transazionali con la flessibilità e l'economicità del data lake. I Lakebase sono abilitati da un design fondamentalmente nuovo: separare il calcolo dall'archiviazione e posizionare i dati del database direttamente nell'archiviazione cloud a basso costo ("lake") in formati aperti, consentendo al contempo l'esecuzione indipendente del livello di calcolo transazionale in cima.

Questa separazione è la svolta fondamentale. I database tradizionali raggruppano CPU e archiviazione in un unico sistema monolitico che deve essere sottoposto a provisioning, gestito e pagato come un'unica grande macchina. Lakebase separa questi livelli. I dati vivono apertamente nel lake, mentre il motore di database diventa un livello di calcolo serverless completamente gestito (ad esempio, Postgres) che può scalare istantaneamente. Questa architettura elimina gran parte dei costi, della complessità e del lock-in che hanno definito i database per decenni ed è particolarmente potente per i moderni carichi di lavoro basati su intelligenza artificiale e agenti, in cui gli sviluppatori desiderano avviare molte istanze, sperimentare liberamente e pagare solo per ciò che utilizzano.

Un Lakebase ha le seguenti caratteristiche principali:

L'archiviazione è separata dal calcolo: i dati vengono archiviati a basso costo negli archivi di oggetti cloud ("lake"), mentre il calcolo viene eseguito in modo indipendente ed elastico. Ciò consente una scalabilità massiccia, un'elevata concorrenza e la possibilità di scalare fino a zero in meno di un secondo (cosa non possibile nei sistemi di database legacy), eliminando la necessità di mantenere inattive costose macchine di database.

Archiviazione illimitata, a basso costo e durevole: con i dati che risiedono nel lake, l'archiviazione diventa essenzialmente infinita e notevolmente più economica rispetto ai tradizionali sistemi di database che richiedono un'infrastruttura a capacità fissa. E la sua archiviazione è supportata dalla durata dell'archiviazione di oggetti cloud (ad esempio, S3), offrendo per impostazione predefinita una durata del 99,999999999%. Questo è di gran lunga superiore alla tradizionale configurazione del database con repliche per la ridondanza dell'archiviazione (il più delle volte aggiornate in modo asincrono, il che significa che esiste la possibilità di perdita di dati in molte configurazioni in caso di doppi guasti).

Calcolo Postgres elastico e serverless: Lakebase fornisce Postgres completamente gestito e serverless che aumenta istantaneamente con la domanda e diminuisce quando è inattivo. I costi si allineano direttamente all'utilizzo, rendendolo ideale per carichi di lavoro bursty, ambienti di sviluppo e agenti di intelligenza artificiale che avviano istanze temporanee.

Branching, clonazione e ripristino istantanei: i database possono essere ramificati e clonati come gli sviluppatori ramificano il codice. Anche i database su scala petabyte possono essere copiati in pochi secondi, consentendo una rapida sperimentazione, rollback sicuri e ripristino istantaneo senza overhead operativo.

Carichi di lavoro transazionali e analitici unificati: Lakebase si integra perfettamente con Lakehouse, condividendo lo stesso livello di archiviazione tra OLTP e OLAP. Ciò consente di eseguire analisi in tempo reale, machine learning e ottimizzazione basata sull'intelligenza artificiale direttamente sui dati transazionali senza spostarli o duplicarli.

Aperto e multicloud per progettazione: i dati archiviati in formati aperti evitano il vendor lock-in proprietario e consentono una vera portabilità tra AWS, Azure e oltre. La flessibilità multicloud integrata supporta il ripristino di emergenza, la libertà a lungo termine e una maggiore economia nel tempo.

Questi sono gli attributi chiave di Lakebase. I sistemi transazionali di livello enterprise richiedono funzionalità aggiuntive come sicurezza, governance, auditing e alta disponibilità, ma con un Lakebase, queste funzionalità devono essere implementate e gestite solo una volta, su un'unica base aperta. Lakebase rappresenta la prossima evoluzione dei database: sistemi transazionali ricostruiti per il cloud, per gli sviluppatori e per l'era dell'intelligenza artificiale.

Evoluzione dell'architettura del database

Per capire perché è necessaria una nuova era, è utile esaminare come l'architettura del database si è evoluta negli ultimi cinquant'anni. Consideriamo questa evoluzione in tre generazioni distinte:

Generazione 1: Monolite

Esempi: MySQL, Postgres, Oracle classico

I sistemi di database sono nati come monoliti assoluti. Nell'era pre-cloud, la rete era la parte più lenta di qualsiasi sistema. L'unico modo per progettare un database ad alte prestazioni era collegare strettamente il calcolo (CPU/RAM) e l'archiviazione (disco) all'interno di una singola macchina fisica. Sebbene ciò avesse senso per le limitazioni hardware degli anni '80, ha creato una gabbia rigida in cui i dati erano intrappolati in formati proprietari e il ridimensionamento significava acquistare una scatola più grande.

Generazione 2: Accoppiamento allentato proprietario dell'archiviazione

Esempi: Aurora, Oracle Exadata

Con il miglioramento dell'infrastruttura cloud, i fornitori hanno separato fisicamente l'archiviazione dal calcolo, spostando l'archiviazione in livelli di backend proprietari. Questi sistemi erano meraviglie ingegneristiche che spingevano i limiti della velocità effettiva. Tuttavia,non sono andati abbastanza lontano. La separazione era puramente un'ottimizzazione interna. Poiché i dati rimangono bloccati all'interno di un formato proprietario accessibile solo da un singolo motore, i sistemi di seconda generazione soffrono di vicoli ciechi strutturali:

• Stretta del singolo motore: i dati sono accessibilisolo tramite il motore di database primario, che diventa il collo di bottiglia. È difficile per gli agenti di intelligenza artificiale o i motori analitici accedere ai dati su larga scala.
• Attrito analitico: poiché non è possibile che motori OLAP separati accedano direttamente ai file di database su larga scala, l'esecuzione di query analitiche rimane difficile e in genere richiede un ETL complesso per spostare i dati.
• Cloud lock-in: il livello di archiviazione è spesso strettamente accoppiato all'infrastruttura proprietaria dello specifico provider cloud. Ciò rende difficile l'interoperabilità multi-cloud e rende impossibile la vera alta disponibilità e il ripristino di emergenza (HADR) cross-cloud. Se la regione del fornitore fallisce, i tuoi dati sono bloccati.

Riteniamo che questi sistemi siano in uno stato di transizione verso la terza generazione finale.

Generazione 3: Lakebase - Archiviazione aperta sul Lake

Un Lakebase porta l'architettura disaccoppiata alla sua conclusione logica finale. Come la seconda generazione, separa il calcolo dall'archiviazione, ma con una differenza fondamentale:sia l'infrastruttura di archiviazione che i formati dei dati sono completamente aperti.

Basandosi su questa architettura, può risolvere le 3 sfide di cui sopra:

• Maggiore affidabilità e costi inferiori grazie a operazioni più semplici: le operazioni comuni come il provisioning, l'aumento, la riduzione, il branching, l'istantanea, il ripristino possono essere completate in pochi secondi. Le query costose possono essere eseguite su diverse istanze di calcolo elastiche senza influire sul traffico di produzione.
• Esperienza di sviluppo simile a Git: diventa più veloce sperimentare e sviluppare applicazioni, basate su un branch ad alta fedeltà dei database di produzione. Per gli sviluppatori e gli agenti di intelligenza artificiale, ciò significa che il database si muove velocemente quanto il loro codice.
• Risolve l'estremo vendor lock-in: con i dati in formati aperti archiviati negli archivi di oggetti cloud, sei molto meno bloccato. Sei proprietario dei tuoi dati, indipendentemente dal motore.

In molti modi, un Lakebase è ciò che creeresti se dovessi riprogettare i database OLTP oggi, ora che sono disponibili archiviazione di oggetti economica e affidabile ed elasticità del cloud. Man mano che le organizzazioni si muovono più velocemente adottando il cloud e l'intelligenza artificiale, prevediamo che questo modello diventerà una base standard per la creazione di sistemi transazionali.

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