Ciao, e benvenuto nella terza puntata della settantaseiesima stagione. Abbiamo detto che l'unità è la pagina, la scatola, e che ogni lettura è un viaggio al magazzino. Oggi vediamo come il database evita il viaggio: tenendo le scatole sul tavolo. Il titolo è: il tavolo di lettura.
Richiamiamo i due posti. Il tavolo è la memoria: piccolo, immediato, ma dimentica tutto appena manca la corrente. Il magazzino è il disco: enorme e affidabile, ma lontano e lento. Il database tiene sul tavolo un gruppetto di scatole, quelle che servono in questo momento. Quando chiedi una pagina, guarda prima sul tavolo. Se la scatola è già lì, è un colpo a segno: niente viaggio, risposta immediata. Se non c'è, cammina fino al magazzino, riporta la scatola, la posa sul tavolo e poi ti serve. Tutto il gioco delle prestazioni è alzare la quota di colpi a segno: servire dal tavolo, non dal magazzino.
Se ti suona familiare, è perché è una cache, proprio quella di cui abbiamo parlato in una vecchia stagione. Il tavolo di lettura è una cache delle pagine del disco, tenuta in memoria, e ha le stesse due domande difficili di ogni cache: cosa tenere, e cosa buttare fuori quando il tavolo è pieno.
Partiamo dal buttare fuori. Il tavolo è minuscolo. Quando arriva una scatola nuova e non c'è posto, una deve tornare in magazzino. Quale? Vuoi mandare indietro la scatola che hai meno probabilità di dover riprendere a breve. La scommessa classica: quella che nessuno tocca da più tempo. Se un dato non lo guardi da un'ora, probabilmente non ti servirà tra un secondo. I database veri non tengono il conto esatto, costerebbe troppo: usano approssimazioni furbe e a buon mercato, tipo fare un giro mettendo un segno su ogni scatola usata, e alla passata dopo mandare indietro la prima che non ha il segno. Il punto da portare a casa: decidere chi esce è una scommessa sul futuro, fatta a basso costo.
Adesso il lato delle scritture, e qui rientra il secondo nemico. Quando cambi un dato, cambi la scatola sul tavolo, non quella sullo scaffale. Quella scatola adesso è sporca: la copia sul tavolo è diversa dalla copia in magazzino. È velocissimo, perché la modifica non ha fatto il viaggio. Ma è pericoloso: se la corrente va via adesso, la modifica vive solo sul tavolo, e il tavolo dimentica. Le scatole sporche sono un debito rimandato verso il magazzino. Il database le riporta indietro più tardi, in blocco, per spalmare i viaggi su tante modifiche insieme. Ecco perché le scritture sembrano immediate, ma la vera storia della sicurezza è più sottile: è esattamente il problema che il registro, fra due puntate, esiste per rendere sicuro.
E qui torna il ritornello, in forma di manopole. Un tavolo grande vuol dire più colpi a segno, meno viaggi: ma la memoria è poca e costa, non puoi fare il tavolo grande come il magazzino. Più memoria compra velocità, e la paghi in denaro. Tenere le scatole sporche più a lungo spalma meglio le scritture, ed è veloce, ma rischia di perdere più lavoro se la corrente va via. Ogni manopola è lo stesso baratto di sempre.
Viene la tentazione di dire: e allora mettiamo tutto il database in memoria, e via i viaggi. La memoria aiuta tantissimo, è vero, ma ha due difetti che non spariscono: dimentica appena manca la corrente, ed è limitata. Il tavolo non può mai diventare il magazzino, perché è il magazzino il posto dove vive la durata. Anche un database tenuto tutto in memoria ha comunque bisogno del magazzino per l'unica cosa che la memoria non sa fare: sopravvivere al buio. Il tavolo ti fa veloce, il magazzino ti fa sicuro: ti servono sempre tutti e due.
Un'ultima mossa elegante. Quando il database si accorge che stai percorrendo gli scaffali in ordine, una grande scansione, va a prendere le scatole successive prima ancora che tu le chieda. Mentre leggi la scatola di adesso, le prossime stanno già arrivando sul tavolo. L'ordine sul disco diventa velocità: ed è un primo indizio del perché avere i dati ordinati, e avere gli indici, conta tanto. Ma questa è la prossima puntata.
Voglio lasciarti con la domanda che un database si fa a ogni lettura: questa scatola è già sul tavolo? Le prestazioni non dipendono soprattutto da quanto è veloce il disco, ma da quanto spesso eviti di toccarlo. Tieni i tuoi dati caldi abbastanza piccoli da stare sul tavolo, e il magazzino quasi sparisce; lascia che i dati di lavoro crescano oltre la memoria, e ogni ricerca ricomincia a camminare. Non si accelera un database rendendo i viaggi più veloci: si accelera facendone di meno.
Per oggi ci fermiamo qui. Abbiamo visto il tavolo di lettura come cache delle pagine: i colpi a segno che evitano il viaggio, la scelta di chi mandare indietro quando è pieno, le scatole sporche che rimandano il debito verso il magazzino, e il motivo per cui la memoria, da sola, non basta mai. Sotto a tutto, sempre lo stesso baratto tra veloce e sicuro, tra tavolo e magazzino. Nella prossima puntata: lo schedario. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.