Ciao, e benvenuto nella seconda puntata della settantaseiesima stagione. La volta scorsa abbiamo trovato i due nemici: il magazzino lento e il guasto improvviso, e una regola, fare meno viaggi possibile. Oggi la prima conseguenza concreta: come viene conservato davvero un fatto, e perché un database non lavora mai una riga per volta. Il titolo lo dice: la pagina, non la riga.
Partiamo dall'idea sbagliata che abbiamo quasi tutti. Pensiamo a una tabella come a un elenco di righe, ognuna seduta da qualche parte, e immaginiamo che, quando ne vogliamo una, si vada a prendere proprio quella. Non funziona così. Il database non conserva le righe una per una: le impacchetta dentro scatole di dimensione fissa, che si chiamano pagine. Tutto, le letture, le scritture, la memoria, avviene una pagina intera alla volta.
Il perché è il primo nemico. Un viaggio al magazzino costa quasi uguale sia che tu riporti un foglio solo, sia che tu riporti un'intera scatola: la fatica è la camminata, non il peso. Tanto vale riportare sempre la scatola piena. La pagina è l'unità del viaggio: leggere una riga vuol dire leggere tutta la scatola in cui vive, perché non esiste riportare indietro mezza scatola.
Vediamo cosa c'è dentro una scatola. Una pagina ha dimensione fissa, diciamo pochi kilobyte. Dentro, le righe sono stipate, ma hanno lunghezze diverse, perché un nome può essere corto o lungo. Allora la pagina tiene una piccola rubrica in testa: una casella per ogni riga, che dice dove quella riga comincia. Questa rubrica permette a una riga di spostarsi dentro la pagina, quando si allunga, senza cambiare il suo indirizzo visto da fuori: da fuori una riga è pagina dodici, casella tre, e la casella punta al posto dove la riga sta davvero in quel momento. È il trucco per cui le righe possono avere lunghezze diverse senza mandare tutto in confusione.
Adesso le conseguenze che senti con mano. Una riga minuscola e una riga enorme costano lo stesso identico viaggio: una pagina. Ma in una scatola ci stanno tante righe strette e poche righe larghe. Quindi righe strette vuol dire più righe per viaggio, meno viaggi, scansioni più veloci; righe larghe, piene di colonne e testi lunghi, sprecano il viaggio. Ecco perché chiedere solo le colonne che ti servono, e non infilare un romanzo in ogni riga, non sono regolette di stile: cambiano quanti fatti tornano a casa dentro ogni scatola.
E c'è un secondo effetto. Quando una riga cresce oltre lo spazio libero della sua pagina, deve spostarsi. Se non può restare dov'era, il database lascia un biglietto, questa riga adesso sta a pagina quaranta, e una lettura futura dovrà seguire il rimando: un secondo viaggio. Gli aggiornamenti che ingrassano le righe si pagano dopo, in silenzio, sulle letture.
Facciamo un passo che apre un bivio importante. Finora abbiamo impacchettato righe intere: tutti i campi di un utente, uno accanto all'altro. Questo si chiama tenere i dati per righe, ed è perfetto quando vuoi il record intero, mostrami tutto di questo utente. Ma certi lavori non chiedono mai la riga intera: chiedono una sola colonna su milioni di righe, la media dell'età di tutti gli utenti. Per quelli puoi riempire la scatola con i valori di una colonna sola, presi da tante righe: tenere i dati per colonne. Stessa idea della pagina, impacchettamento diverso. Ognuno è velocissimo per la domanda opposta all'altro, ed ecco il ritornello già qui: puoi essere rapido sul record intero o rapido sulla colonna percorsa per intero, non su entrambi gratis.
E qui arriva la pietra angolare della stagione, quindi lascia che la dica per intero. Un database non ragiona in fatti: ragiona in scatole, perché il nemico è il viaggio lento. Tutto il resto, gli indici, la memoria, il registro, perfino le transazioni, è costruito sopra questo fatto bruto: i dati vivono in pagine di dimensione fissa, e la pagina, non la riga, è l'atomo che la macchina sposta, tiene in memoria e protegge. Se ti ricordi che l'unità è la pagina, metà dei comportamenti strani di un database si spiega da sé.
È la macchina sotto la magia. La magia ti lasciava pensare a una riga, da qualche parte; la macchina risponde che non ci sono righe sparse, ci sono solo scatole, e ogni scatola è un viaggio. L'arte del database comincia qui: impacchetta bene le scatole, e hai già risparmiato viaggi prima ancora che esista un solo indice.
Voglio lasciarti con la nuova unità di misura. Smetti di contare le righe e comincia a contare le pagine, cioè i viaggi al magazzino. Quando ti chiedi se una ricerca è cara, la domanda vera è: quante scatole deve riportare indietro? Tieni le righe strette, chiedi solo le colonne che ti servono, e non lasciare che le righe si gonfino: così fai scendere l'unico numero che conta davvero, i viaggi. La pagina è l'unità del costo: impara a contare in pagine.
Per oggi ci fermiamo qui. Abbiamo visto che il database non conserva righe sfuse ma pagine di dimensione fissa, che la pagina è l'unità di ogni viaggio, e che dentro una scatola una piccola rubrica tiene l'ordine anche con righe di lunghezza diversa. Abbiamo toccato il bivio tra righe e colonne, e posato la pietra angolare: la macchina ragiona in scatole, non in fatti. Nella prossima puntata: il tavolo di lettura. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.