Immagina di cercare di organizzare una biblioteca enorme e caotica dove milioni di persone stanno cercando di prendere in prestito, leggere e riscrivere libri esattamente nello stesso momento. Nel mondo dell'informatica, questa è la sfida dei database: sistemi che memorizzano informazioni in modo che le applicazioni possano trovarle e modificarle istantaneamente. Per decenni, la grande domanda è stata come far crescere queste biblioteche per gestire l'intero internet senza farle crollare. Il vecchio metodo era come avere un singolo bibliotecario che doveva timbrare ogni singolo libro, creando una lunga fila che rallentava tutti. Il metodo più recente, della "consistenza eventuale", era come lasciare che le persone indovinassero cosa diceva il libro e correggere gli errori in seguito, il che è veloce ma rischioso se hai bisogno della verità proprio in questo momento. L'obiettivo dell'ingegneria moderna dei database è costruire un sistema che sia veloce come il metodo dell'indovino ma affidabile come il metodo del timbro, capace di gestire milioni di transazioni al secondo senza che nessuno debba mai gestire gli scaffali manualmente.

Questo articolo presenta Aurora DSQL, un nuovo tipo di database progettato da Amazon Web Services per risolvere esattamente questo problema. Pensa a esso come a una biblioteca super intelligente e a guida autonoma che può espandersi o rimpicciolirsi istantaneamente a seconda di quante persone la visitano. Gli autori hanno costruito un sistema che separa il "pensiero" (l'esecuzione del codice SQL) dallo "storage" (il mantenimento dei libri) e dalle "regole" (assicurarsi che non due persone cambino la stessa pagina contemporaneamente). Utilizzando un "Journal" speciale che funge da diario permanente e immutabile di ogni modifica apportata, DSQL consente alle diverse parti del sistema di lavorare indipendentamente. L'articolo dimostra che questo design permette al database di scalare da zero utenti a milioni di transazioni al secondo, funziona attraverso diversi continenti senza rallentare e mantiene i dati perfettamente coerenti, in modo da non dover mai preoccuparsi di leggere un libro che qualcun altro sta riscrivendo.

La magia della biblioteca disconnessa

Per capire come funziona Aurora DSQL, immagina una gigantesca biblioteca dove i bibliotecari, gli scaffali e i custodi delle regole si trovano tutti in edifici diversi, collegati da telegrafi super veloci. Nei sistemi più vecchi, queste parti erano incollate insieme; se gli scaffali si riempivano troppo, l'intera biblioteca doveva fermarsi e riorganizzarsi. DSQL le separa.

In primo luogo, ci sono i Query Processors. Questi sono i bibliotecari che parlano con te. Quando chiedi un libro, non trasportano loro stessi i libri pesanti. Invece, operano all'interno di piccole stanze virtuali sicure chiamate Firecracker MicroVMs. Queste stanze sono così efficienti che possono essere create o distrutte in un battito di ciglia. Se hai un improvviso afflusso di visitatori, il sistema costruisce istantaneamente più stanze. Se l'afflusso finisce, le demolisce in modo da non pagare per lo spazio vuoto. Questa è la parte "serverless": non gestisci tu i bibliotecari; essi appaiono semplicemente quando ne hai bisogno.

Successivamente, ci sono i Storage Nodes. Questi sono gli scaffali. Non contengono l'intera biblioteca; contengono solo sezioni specifiche di libri basate su una "chiave di partizione" (come ordinare i libri per la prima lettera del nome dell'autore). Poiché i bibliotecari e gli scaffali sono separati, i bibliotecari possono gestire la propria attività senza aspettare che gli scaffali si mettano in pari. Leggono dallo scaffale più vicino nel loro quartiere (Availability Zone), il che rende la lettura incredibilmente veloce.

Infine, ci sono gli Adjudicators e il Journal. Gli Adjudicators sono i custodi delle regole che decidono se una modifica è permessa. Il Journal è il diario maestro. Quando vuoi cambiare un libro (una "scrittura"), il bibliotecario scrive la modifica su un pezzo di carta ma non la mette ancora sullo scaffale. La invia al custode delle regole. Il custore delle regole controlla se qualcun altro sta cercando di cambiare lo stesso libro nello stesso momento. Se è tutto libero, il custore scrive la modifica nel Journal. Questo Journal è la parte più importante: è un elenco permanente e ordinato di ogni singa modifica che sia mai avvenuta. Una volta che qualcosa è nel Journal, è al sicuro per sempre, anche se gli scaffali o i bibliotecari scompaiono.

Il trucco della lettura "senza attesa"

Uno dei trucchi più interessanti di questo articolo è come gestisce la lettura. In molti database, se vuoi leggere un libro, devi aspettare che il bibliotecario si assicuri che nessuno ci stia scrivendo sopra in quel momento. Questo causa code e ritardi. DSQL usa un astuto trucco di viaggio nel tempo chiamato Multi-Version Concurrency Control (MVCC).

Immagina che ogni volta che un libro viene cambiato, la biblioteca non cancelli la vecchia versione. Inveve, crea una nuova copia con un timestamp. Quando chiedi un libro, non chiedi "il libro"; chiedi "il libro com'era alle 14:00". Il sistema trova quindi la versione che era valida alle 14:00. Poiché il sistema utilizza orologi super precisi (accurati al microsecondo), sa esattamente quale versione mostrarti. Questo significa che puoi leggere un libro mentre qualcun altro ne sta scrivendo uno nuovo, e non vedrai le sue modifiche disordinate e a metà. Vedrai un'istantanea perfetta e congelata del passato. Ciò consente a milioni di persone di leggere contemporaneamente senza mai bloccarsi a vicenda.

Il superpotere multi-regione

L'articolo affronta anche il problema della distanza. Di solito, se hai una biblioteca a New York e una a Londra, mantenerle sincronizzate richiede tempo a causa della velocità della luce. Se provi ad aggiornare un libro in entrambi i posti contemporaneamente, devi aspettare che un messaggio attraversi l'oceano, il che rallenta tutto.

DSQL risolve questo problema essendo active-active. Ciò significa che puoi avere una biblioteca a New York e una a Londra, e entrambe sono completamente aperte per il business nello stesso momento. Quando effettui una modifica a New York, il sistema la scrive nel Journal. Il Journal invia poi una copia a Londra. La magia è che questo accade solo una volta, proprio nel momento in cui premi "commit" (concludi la transazione). Il sistema non ti impedisce di leggere o scrivere mentre il messaggio viaggia. Utilizza un sistema a "quorum", il che significa che ha solo bisogno di confermare la modifica in due regioni su tre per considerarla sicura.

L'articolo ha misurato questo aspetto e ha scoperto che, anche con la distanza tra Virginia e Oregon (circa 6 millisecondi di andata e ritorno), il sistema paga quella "tassa sulla distanza" solo una volta per transazione. Per la lettura, è ancora più veloce perché leggi dalla biblioteca locale. Gli autori mostrano che questo design permette al database di rimanere veloce e coerente anche se un'intera regione (come un'intera città) dovesse andare offline a causa di un disastro.

Le regole del gioco

Gli autori sono stati molto attenti a ciò che promettevano. Hanno scelto lo Snapshot Isolation, un insieme specifico di regole su come si comportano le transazioni. È come dire: "Puoi leggere il libro com'era quando hai iniziato a leggere, e puoi cambiarlo quando hai finito, ma se qualcun altro lo ha cambiato nel frattempo, devi riprovare". Questo è diverso dalle regole più rigide che ti costringerebbero ad aspettare un blocco (lock), il che rallenta le cose.

L'articolo esclude esplicitamente l'idea che sia necessario un singolo "leader" per gestire tutto. In molti sistemi, un computer è il capo, e se si rompe, tutto si ferma. DSQL non ha un unico capo. Ogni parte può scalare verso l'alto o verso il basso, e se una parte fallisce, le altre continuano semplicemente a funzionare. L'articolo esclude anche l'idea che tu debba gestire l'hardware personalmente. Il sistema gestisce il "calore" (quali parti stanno diventando troppo trafficate) automaticamente. Se una sezione della biblioteca diventa troppo affollata, il piano di controllo (il gestore della biblioteca) la divide automaticamente in due sezioni più piccole e sposta alcuni libri su un nuovo scaffale, tutto senza che tu faccia nulla.

Testare la teoria

Gli autori non si sono limitati a ipotizzare che questo funzionasse; lo hanno testato intensamente. Hanno utilizzato un metodo chiamato simulazione deterministica, in cui hanno eseguito il sistema in un programma per computer che poteva simulare milioni di errori, ritardi di rete e crash in una frazione di secondo. Hanno scoperto che il sistema poteva gestire questi errori senza perdere dati o confondersi.

Hanno anche eseguito test in stile reale (come il benchmark TPC-C, che simula un negozio molto attivo). I risultati hanno mostrato che DSQL poteva scalare da un avvio a freddo (dove ha pochissime risorse) a gestire milioni di operazioni al minuto. Ha impiegato circa 25 minuti per raggiungere la piena velocità da uno stato completamente vuoto, ma una volta "caldo", era incredibilmente veloce. L'articolo nota che, sebbene siano molto fiduciosi in questi risultati, stanno ancora lavorando per aggiungere altre funzionalità come le chiavi esterne (che collegano le tabelle tra loro) e le procedure memorizzate.

Il punto fondamentale

Aurora DSQL è la prova che si può avere il meglio di entrambi i mondi: un database che è facile da usare come un semplice servizio (dove non gestisci nulla) e potente come un sistema globale massiccio. Separando il pensiero, lo storage e le regole, e utilizzando un journal permanente per tenere traccia del tempo, permette alle applicazioni di crescere da zero a milioni di transazioni senza battere ciglio. È un sistema progettato per un mondo in cui le cose cambiano velocemente, dove i disastri accadono e dove hai bisogno di sapere che l'informazione che stai leggendo è la verità assoluta, proprio ora.