Ciao, e benvenuto nella settima puntata della decima stagione. Nella scorsa puntata abbiamo visto il backend imparare a scalare affiancando tanti server. Ma c'era un pezzo che resisteva a questa logica, il più prezioso e il più difficile da moltiplicare: il database, il custode della verità di cui abbiamo parlato. Oggi raccontiamo la grande rivolta che scosse il mondo dei dati, quando il sacro database relazionale fu messo in discussione, e il dibattito appassionato, e a volte eccessivo, che ne seguì.
Ricordiamo perché il database è il punto più difficile da scalare, perché è il cuore del problema. I server senza memoria si moltiplicano facilmente, perché sono intercambiabili. Ma il database è unico: è il luogo dove sta la verità, e la verità deve essere una sola e coerente. Se moltiplichi il database in tante copie, sorge subito un problema angosciante: come tieni tutte le copie perfettamente d'accordo tra loro, in ogni istante? Se un utente scrive qualcosa su una copia, e un altro legge da una copia diversa un attimo dopo, vedrà il dato aggiornato o quello vecchio? Mantenere una verità unica e coerente su tante copie sparse è uno dei problemi più difficili dell'informatica.
I database relazionali, con le loro garanzie rigorose di cui abbiamo parlato, erano bravissimi a mantenere questa coerenza perfetta, ma pagavano un prezzo, e qui sta il nocciolo della rivolta. Quelle garanzie rigorose, quel pretendere che tutto fosse sempre perfettamente coerente in ogni istante, erano proprio ciò che rendeva difficile moltiplicare il database per reggere la scala estrema. La perfezione della coerenza e la capacità di crescere all'infinito tiravano in direzioni opposte. Per i colossi del Web, con quantità di dati e di utenti mai viste, quella coerenza perfetta cominciava a sembrare un lusso troppo costoso.
E così, verso la fine degli anni Duemila, nacque un movimento che proponeva un'eresia affascinante: e se, per certi usi, rinunciassimo a un po' di quella coerenza perfetta e rigorosa, in cambio di una capacità enorme di crescere e di reggere carichi immensi? Nacquero database di tipo nuovo, che abbandonavano alcune delle regole rigide di quelli relazionali per privilegiare la scala, la velocità e la flessibilità. Vennero chiamati, un po' per contrapposizione, database non relazionali. Non erano un'unica cosa, ma una famiglia varia di strumenti, ciascuno con la sua filosofia e il suo modo diverso di organizzare i dati.
Vale la pena capire lo spirito di questa varietà. Alcuni organizzavano i dati come semplici coppie di chiave e valore, come un enorme dizionario velocissimo. Altri li tenevano come documenti flessibili, senza pretendere che tutti avessero la stessa forma rigida. Altri ancora erano pensati per rappresentare reti di relazioni, come le connessioni in un social network. Ognuno rinunciava a qualcosa per eccellere in un compito specifico: non erano migliori in assoluto, erano diversi, adatti a problemi diversi.
Al cuore di questo dibattito c'è un principio profondo, che voglio raccontarti in modo semplice perché è una delle idee più importanti dei sistemi distribuiti. Quando i tuoi dati sono sparsi su tante macchine e qualcosa va storto nella comunicazione tra loro, sei costretto a una scelta dolorosa: o privilegi la coerenza, rifiutandoti di rispondere con dati forse non aggiornati, oppure privilegi la disponibilità, rispondendo comunque, ma col rischio di dare un dato leggermente vecchio. Non puoi avere entrambe le cose in modo perfetto quando le macchine faticano a parlarsi. Questa scelta obbligata tra coerenza e disponibilità è una delle verità fondamentali con cui ogni sistema di grande scala deve fare i conti.
Da qui nacque un'idea che suonava scandalosa: la coerenza col tempo. L'idea che va bene, per certi usi, se le copie dei dati non sono d'accordo all'istante, purché lo diventino di lì a poco. Pensa al conteggio dei mi piace: se per un secondo vedi un numero e il tuo amico ne vede un altro, non è un dramma, purché presto si allineino. Ma per il saldo di un conto bancario quella stessa rinuncia sarebbe inaccettabile. Il contesto decide tutto.
E qui arriva la lezione di equilibrio di questa puntata, perché la storia ebbe una parabola istruttiva. All'inizio ci fu un entusiasmo eccessivo: sembrava che i nuovi database dovessero soppiantare del tutto quelli relazionali, considerati ormai vecchi. Molti li adottarono anche dove non servivano, per moda, e si trovarono a soffrire per la mancanza proprio di quelle garanzie che avevano scartato. Poi, col tempo, arrivò la maturità e il buon senso: si capì che non c'era un vincitore assoluto, ma strumenti diversi per esigenze diverse. I database relazionali tornarono in auge, più forti di prima, e oggi convivono serenamente con quelli non relazionali. Riprendo la prima stagione: al di là delle mode, si sceglie lo strumento giusto per il problema.
Per oggi ci fermiamo qui. Il database è il pezzo più difficile da scalare, perché deve custodire una verità unica e coerente. Le garanzie rigorose dei database relazionali, perfette per la coerenza, ostacolavano la scala estrema, e da qui nacque la rivolta dei database non relazionali, che rinunciavano a un po' di coerenza in cambio di capacità di crescere. Al cuore c'è la scelta obbligata tra coerenza e disponibilità, e l'idea della coerenza col tempo. Dopo un entusiasmo eccessivo, arrivò la maturità: strumenti diversi per esigenze diverse. Nella prossima puntata torniamo all'architettura, per la grande frattura del monolite: i microservizi. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.