Ciao, e benvenuto nella quinta puntata della cinquantaquattresima stagione. Oggi parliamo della capacità che, più di ogni altra, ha reso MySQL famoso e amato per scalare i siti giganteschi del primo web: il modo in cui un database può clonarsi in molte copie sincronizzate. Oggi capiamo la replica, e il registro dei cambiamenti.
Partiamo dal problema, perché è quello del successo. Immagina che il tuo sito diventi popolarissimo. Milioni di persone vogliono leggere le tue pagine, i tuoi articoli, i tuoi prodotti. Una sola macchina, per quanto potente, a un certo punto non ce la fa: troppe richieste di lettura tutte insieme. E qui c'è una fortuna: la maggior parte dei siti legge moltissimo e scrive pochissimo. Per ogni persona che scrive un commento, migliaia lo leggono soltanto. Se solo potessi avere tante copie della base di dati, tutte aggiornate, e spargere su di esse la marea di letture.
Voglio darti la soluzione di MySQL, perché è stata rivoluzionaria. La soluzione è la replica, e MySQL l'ha resa famosa perché era semplice da attivare quando quasi nessun altro la offriva così alla mano. Funziona così: c'è una macchina principale, quella che riceve tutte le scritture, l'unica autorizzata a cambiare i dati. E poi ci sono delle copie, delle repliche, che ricevono di continuo gli aggiornamenti dalla principale e restano allineate. Le scritture vanno tutte alla principale; le letture, invece, si spargono su tutte le repliche. Così puoi servire una folla immensa di lettori aggiungendo semplicemente altre copie.
Voglio dirti il meccanismo, perché è un vecchio amico. Ma come fanno le repliche a restare aggiornate? Con un'idea che questo podcast ha già incontrato più volte. La macchina principale tiene un registro, un diario in cui annota, in ordine, ogni singolo cambiamento che avviene sui dati. Ogni modifica, appena fatta, viene scritta in questo registro. Le repliche non fanno altro che leggere quel diario e rifare, una per una, le stesse modifiche, nello stesso ordine. Il diario dei cambiamenti è il filo che tiene sincronizzate tutte le copie: la principale lo scrive, le repliche lo rileggono e lo ripetono.
Voglio farti notare un collegamento bellissimo, perché unisce il corso. Questo diario ordinato di cose accadute, a cui si aggiunge sempre in fondo, ti suona familiare? Lo abbiamo visto in Postgres, come registro per sopravvivere ai crash. Lo abbiamo visto parlando di una piattaforma di flussi di eventi, come cuore per far dialogare i sistemi. E ora lo ritroviamo in MySQL, come strumento per clonare una base di dati. Tre usi diversissimi, la stessa idea profonda: invece di guardare solo lo stato finale, tieni un elenco ordinato di tutto ciò che è cambiato. Da quell'elenco puoi ricostruire, sincronizzare, replicare. È forse l'idea più feconda dell'informatica dei dati.
Voglio darti l'immagine che rende chiara questa idea, perché è concreta. Pensa alla sede centrale di un'azienda e alle sue filiali. La sede centrale è l'unica che decide i cambiamenti veri: nuovi prezzi, nuovi prodotti. Ma ogni volta che decide qualcosa, invia a tutte le filiali una copia esatta dell'ordine, nello stesso ordine cronologico. Le filiali applicano quegli ordini e restano perfettamente allineate alla centrale. Un cliente può entrare in qualsiasi filiale e ricevere le stesse informazioni, senza dover disturbare la sede centrale. Le filiali sono le repliche; gli ordini spediti sono il registro dei cambiamenti.
Voglio essere onesto sul limite, perché è inevitabile. C'è un prezzo, ed è la fisica. Tra il momento in cui la principale registra un cambiamento e il momento in cui una replica lo ha applicato, passa un istante, a volte piccolissimo, a volte meno. Si chiama ritardo di replica. Vuol dire che, per una frazione di tempo, una replica può mostrare dati leggermente vecchi. Per la maggior parte delle cose non importa: se vedi un commento un secondo dopo, chi se ne accorge. Ma per le cose in cui devi vedere subito l'ultimissima verità, magari il tuo stesso saldo appena modificato, quella lettura va chiesta alla principale, non a una replica in ritardo. Conoscere questo limite è ciò che ti evita bug misteriosi.
Per oggi ci fermiamo qui. Abbiamo visto la replica. Quando i lettori diventano una marea, una macchina sola non basta, ma per fortuna quasi tutti i siti leggono molto e scrivono poco. La soluzione: una macchina principale riceve tutte le scritture, e tante repliche, sempre aggiornate, si spartiscono le letture. Restano allineate grazie a un registro, un diario in cui la principale annota in ordine ogni cambiamento, che le repliche rileggono e ripetono. È la stessa idea del registro vista in Postgres e nei flussi di eventi: un elenco ordinato di ciò che è cambiato. Come una sede centrale che spedisce copie degli ordini alle filiali. Con un limite onesto: il ritardo di replica, per cui una copia può essere un attimo indietro. Nella prossima puntata: trovare in fretta, gli indici. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.