Ciao, e benvenuto nella sesta puntata della cinquantacinquesima stagione. Oggi passiamo al secondo pilastro di Mongo, quello che, agli inizi, fu una delle sue promesse più rumorose: la capacità di crescere non comprando una macchina più grande, ma aggiungendone tante piccole. Oggi capiamo come si distribuisce il carico, con le repliche e la scalabilità orizzontale.
Partiamo dai due modi di crescere, perché è la scelta di fondo. Quando una base di dati non ce la fa più, hai due strade. La prima è crescere in verticale: prendere la macchina che hai e renderla più potente, più memoria, processori migliori. Semplice, ma ha un tetto: esiste una macchina più grande possibile, e costa cara. La seconda strada è crescere in orizzontale: invece di una macchina gigante, tante macchine normali che lavorano insieme. Non c'è tetto: se serve più potenza, aggiungi un'altra macchina, e un'altra ancora. Mongo è nato con questa seconda strada nel sangue.
Voglio darti il primo meccanismo, perché serve prima di tutto per la sicurezza. Il primo mattone sono le repliche. Mongo tiene più copie degli stessi dati su macchine diverse: una principale, che riceve le scritture, e altre copie che le seguono, restando allineate. A cosa serve? A due cose. Alla sicurezza: se la macchina principale si guasta, non perdi i dati, perché ne esistono copie. E alla continuità: se la principale cade, il sistema, da solo, elegge una delle copie come nuova principale, e va avanti senza che nessuno debba correre nella notte. Questo passaggio di consegne automatico è una delle comodità che hanno reso Mongo amato da chi gestisce i sistemi.
Voglio darti il secondo meccanismo, perché è quello per la scala vera. Le repliche danno sicurezza, ma sono tutte copie intere: ognuna contiene tutti i dati. E se i dati diventano così tanti da non entrare in una sola macchina? Qui entra il secondo meccanismo, lo spezzettamento. L'idea è dividere i dati stessi su più macchine: una porzione qui, un'altra là, un'altra ancora più in là. Nessuna macchina contiene tutto; ognuna tiene una fetta. Un coordinatore sa quale fetta sta dove, così quando arriva una richiesta la manda alla macchina giusta. In questo modo puoi ospitare quantità di dati che nessuna singola macchina potrebbe mai reggere.
Voglio darti l'immagine che rende chiara questa idea, perché è concreta. Pensa a una biblioteca enorme, troppo grande per un solo edificio. La soluzione dello spezzettamento è distribuire i libri su più edifici: nel primo i titoli dalla A alla F, nel secondo dalla G alla M, e così via. All'ingresso c'è un registro che, per ogni titolo, ti dice in quale edificio andare. Nessun edificio contiene tutta la biblioteca, ma insieme la contengono, e possono crescere all'infinito aggiungendone di nuovi. Le repliche, invece, sarebbero come avere lo stesso identico edificio duplicato in tre copie, per sicurezza. Due idee diverse: copiare tutto, o dividere il tutto.
Voglio essere onesto sulla complessità, perché è tanta. Ma attenzione: spezzare i dati su più macchine è potente e insidioso insieme. La decisione più importante è con quale criterio dividere, cioè in base a quale campo decidi in quale macchina va ogni dato. Sbaglia quel criterio, e crei squilibri: una macchina si riempie e lavora tantissimo mentre le altre oziano, e hai speso in complessità senza guadagnare in scala. È la stessa lezione, ricordi, della chiave primaria in MySQL: una scelta apparentemente tecnica che decide se tutto vola o tutto arranca. Lo spezzettamento non è gratis: aggiunge parti mobili, e va abbracciato solo quando ti serve davvero.
Voglio collegarlo a un vecchio amico, perché ricorre. Come fanno le repliche a restare allineate alla principale? Con la stessa idea che abbiamo incontrato per MySQL, e prima ancora per Postgres, e prima ancora per i flussi di eventi: un registro ordinato dei cambiamenti. La principale annota in ordine ogni modifica, e le copie rileggono quel registro e ripetono le stesse modifiche. Ancora una volta, sotto tecnologie diverse, ritroviamo lo stesso motore profondo: tieni un elenco ordinato di ciò che è cambiato, e potrai copiarlo, sincronizzarlo, ricostruirlo. Poche idee, in questo mestiere, sono feconde quanto quella del registro.
Per oggi ci fermiamo qui. Abbiamo visto il secondo pilastro, la scala. Si cresce in due modi: in verticale, una macchina più potente, con un tetto; o in orizzontale, tante macchine insieme, senza tetto, la strada di Mongo. Primo mattone, le repliche: più copie intere dei dati, per la sicurezza e per il passaggio di consegne automatico se la principale cade. Secondo mattone, lo spezzettamento: dividere i dati su più macchine, ognuna una fetta, come una biblioteca sparsa su più edifici con un registro all'ingresso. Con un'onestà: il criterio di divisione è delicato come la chiave primaria di MySQL, e aggiunge complessità. E le copie si allineano con il solito registro dei cambiamenti. Nella prossima puntata: quanto vuoi essere sicuro. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.