Il problema
La fonte pubblica i risultati per evento, per giornata, per regione. Non c’è modo di chiedere “come è andato questo atleta nelle ultime tre stagioni?”. La piattaforma risponde a questa domanda interrogando ogni evento, normalizzando nomi e società e indicizzando tutto per persona.
È partita su SQLite, la scelta giusta per una prima versione. Quando i dati hanno superato il milione di righe e il traffico è cresciuto durante la stagione agonistica, i limiti sono venuti fuori: un solo processo in scrittura alla volta, query di aggregazione lente e nessun modo pulito di far girare l’ingestione e il sito su macchine separate.
Cosa abbiamo fatto
Abbiamo pianificato il passaggio come una migrazione con una via di ritorno. Abbiamo portato il livello dati su PostgreSQL dietro un sottile strato di astrazione, fatto girare i due database in parallelo e confrontato i risultati delle query pagina per pagina prima di fare lo switch. Al cutover tutte le 1.258.217 righe sono state copiate e verificate con checksum. Il vecchio database è rimasto intatto per due settimane come via di rollback, con i passaggi messi per iscritto.
Abbiamo sistemato quello che il cutover ha fatto emergere. Nelle prime ore sono comparsi due bug operativi: uno script di cron che si rompeva su un valore senza virgolette e uno strumento di backup indietro di una major version rispetto al server. Li abbiamo corretti entrambi in mattinata, e il primo backup PostgreSQL è stato ripristinato e verificato prima di considerare il lavoro chiuso.
L’abbiamo resa veloce dove gli utenti se ne accorgono. La pagina di confronto tra atleti impiegava 13 secondi perché aggregava l’intera tabella dei risultati a ogni richiesta. Limitando la query alle sole gare dell’atleta è scesa a 0,2 secondi, con un output identico byte per byte. Le classifiche della home sono state spostate dalle richieste degli utenti a un job in background, portando un caricamento a freddo da circa 2,7 secondi a meno di 0,2.
Cosa dimostra
Ingestione, modellazione dei dati, migrazione del database, ottimizzazione delle prestazioni e operations, fatte dalle stesse persone. Chi lavorava sui dati sapeva quali numeri dovevano tornare. Chi lavorava sulla piattaforma sapeva come spostarli in sicurezza.