Normale o DeNormale
I databases hanno fatto la storia dell'umanita'.
No, seriamente. E' opinione comune tra molti storici che la scrittura sia stata inventata non per lasciare ai posteri le memorie di questo o quell'eroe dell'antichita', ma molto piu' prosaicamente, per tenere conto di chi aveva quali e quante sementi nel villaggio, in modo da essere "coperti" per la prossima stagione della semina.
Gli egiziani, non contenti di tenere conto delle sementi, tenevano conto di tutto. In effetti si suppone che siano stati loro ad inventare le tasse (grazie eh!).
Dal 6000 BC in poi, cioe' da quando abbiamo delle tracce scritte, quello che si trova piu' spesso sono tabulati di informazioni relative a chi possiede cosa. Databases in pratica.
Ed oggi, che abbiamo computers che possono processare un baziliardo di informazioni al nanosecondo, reti che possono trasferire un baziliardo di informazioni e dischi che possono contenerli, riusciamo categoricamente a mandare l'intero sistema nel pallone.
Nella maggioranza dei casi, non e' un problema di volumi, ma di uso ed abuso.
Tanto tempo fa, quando mi occupavo ancora di programmazione ed i database erano, piu' o meno, il mio pane quotidiano, ricordo che uno dei miei tomi preferiti era "Database Designs for mere mortals" a parte il titolo che e' gia' tutto un programma, quel libro specifica bene che una cosa e' la struttura LOGICA del database ed una cosa molto, ma molto diversa e' quello che accidenti ci vuoi fare.
La teoria, che e' bella e figa e tutto quello che vuoi, ma rimane teoria, dice che un database deve essere normalizzato, cioe' la struttura deve obbedire a delle regole ben precise. Ma la pratica, che e' brutta, zozza e rozza, ma e' quella che paga lo stipendio, specifica chiaramente che non conta un cazzo se il database non e' perfetto, conta che funzioni e faccia quello che ti interessa che faccia nel miglior modo possibile. Ed e' in questa distinzione che il mondo si incrocchia.
Ed ecco arrivare $noiidatabasecelimangiamoacolazione, una societa' che si occupa di distrubuzione di varie cose.
Questa gente, gestendo sia cose che persone e quindi luoghi, fa ampio e diversificato uso di databases. Per scopi che ancora mi sfuggono, hanno dato il loro sistema in gestione ad una societa' esterna che si occupa di fare data analisys e fornire dei bei report colorati e pieni di frecce che questa gente poi usa per... non lo so di sicuro, credo li appendano al muro per poi giocarci a freccette.
Comunque sia, per poter fare quello che dovevano fare, questa societa' esterna dovette installare e configurare un database ovviamente, che doveva essere hostato da noi sul sistema di $noicelimangiamo.
Chiaramente, perche' $noicelimangiamo parlava tanto bene ma poi mettere i soldi dove era la bocca..., questa gente non aveva la piu' pallida idea del volume di dati che avrebbero dovuto gestire, quindi partirono con una soluzione "media".
Ovviamente nel giro di una settimana, dopo che avevano fatto un po' di import di dati, il sistema era pronto ad esplodere.
Non solo per la mole di dati caricati a piu' mandate, ma perche' ogni 10 minuti nei giorni normali e 5 nei giorni festivi, uno qualunque dei CL di $noicelimangiamo si inventava questa o quella belliissima query da eseguire sul database che ne provocava la fusione.
Dopo un po' di riunioni e diversi "round" del gioco preferito degli olandesi (puntare il dito contro qualcun altro), il semplice fatto che il sistema e' stato dimensionato assumendo un certo volume di dati che si e' rivelato molto inferiore alla realta' risulta evidente. Ed evidente e' anche la soluzione. O meglio la soluzione appariva ovvia a me: ridimensionare l'intero arnese in modo che fosse adatto alla reale mole di dati. Ma "ridimensionare" significa in primo luogo pagare un prezzo molto piu' alto e poi rifare tutto il lavoro di importazione dei dati, che significa (di nuovo) pagare di nuovo per l'attivita'.
La "soluzione" che era richiesta da $noicelimangiamo invece era "fare uso delle moderne tecnologie per bypassare il problema della nostra incompetenza". Quando domandammo di quali "moderne tecnologie" stavano parlando, quelli fecero sfoggio delle ultime buzzword (blockchain per esempio), dimostrando che non avevano ben chiaro ne' di cosa stessero parlando ne' di cosa fosse il problema.
La faccenda ando' avanti per un po' finche' non si decisero che no, dovevano per forza aprire il portafogli. Dopo una belle iniezione di hardware e storage, l'intero arnese prese a funzionare un pelo meglio. Dico "un pelo", perche' a questo punto iniziarono gli "altri" problemi. Che tradotto significa: l'intero arnese era di una lentezza abominevole.
Ovviamente sia $noicelimangiamo che i loro "dataprocessor" erano alla ricerca di capri espiatori, e decisero che, dato che noi eravamo l'hosting provider, niente di meglio che scaricare il problema su di noi.
Ed e' a questo punto che entro in scena io, che sembro essere l'unico che ha una pallida idea di cosa cazzo e' un database e come effettivamente funziona "sotto al coperchio". Dopo essermi impadronito di una di questa dannate query che impiegavano giorni ad essere eseguite, mi sono messo a fare un po' di debugging scoprendo l'ovvio: il database e' normalizzato. Il che significa che e' una schifezza per eseguire le query che $noicelimangiamo vorrebbe eseguire.
Qui dobbiamo aprire una piccola parentesi e spiegare che cosa si intende con "database normalizzati".
La Teoria dei Database e' una roba piuttosto lunga e complessa, ma si puo' ridurre a poche linee guida essenziali che specificano come un database dovrebbe essere per rispondere ai minimi termini. In particolare queste linee guida specificano che a) ogni tabella dovrebbe avere solo dati che sono specifici di quella particolare tabella, b) non dovrebbero esserci dati che siano desumibili da un'altra tabella e c) che non vi siano dati duplicati o desumibili da nessuna parte.
Questo e' tutto bello e giusto, ma chiunque abbia lavorato nel mondo reale per un po', sa che la Teoria e la Pratica non si incontrano quasi mai. In particolare, un database normalizzato e' bello in teoria, ma in pratica uno non-normalizzato si comporta in modo assai piu' performante. E quasi tutti i testi che si orientano piu' alla pratica reale che agli esami teorici convengono che si', si normalizza per ridurre le castronerie e poi si vede come il database dovrebbe essere utilizzato e si de-normalizza quello che si deve per ottenere le funzionalita'.
Applicando questo alla vita reale, la query che stavo osservando sull'ambiente di $noicelimangiamo e che richiedeva un'ora e mezza era del tipo "select count( distinct id ), sum(val1), sum(val2) from table where (some_date_group) group by id"
Che a vederla cosi' non sembra tanto male, se non si osserva che la tabella in questione contiene circe 320 MILIONI di records e che "distinct id" produce una tabella temporanea ogni volta (creando una copia di milioni e milioni di records).
Quando domandai che senso aveva una count (distinct id) mi venne risposto che quella tabella era in realta' un "dettaglio" di una tabella "madre" e che l'id non era unico.
Questo e' un classico caso in cui e' bene de-normalizzare, aggiungendo i campi di totalizzazione alla tabella madre, cosi' che UN SOLO RECORD deve essere ritornato invece di selezionarne milioni e poi buttarli via per ottenere lo stesso risultato.
Il problema di questo tipo di cose e' che la soluzione e' semplice: ridisegnare la struttura dati per tenere conto dell'uso e non della teoria e rifare le procedure che riempiono i dati. Che e' "semplice", ma e' molto, molto difficile, perche' la prima cosa da fare e' ammettere che si e' fatta una cazzata nella progettazione del database.
E dato che "abbiamo fatto una cazzata nella progettazione" significa anche "dovete sistemarla senza paga", e' ovvio che i volponi dei "dataprocessor" fossero alla ricerca di qualunque scappatoia, legale o illegale. In questo i signori furono aiutati da un alleato inatteso: Oracle.
Si' perche' il famigerato database era Oracle. Ed oracle applica licenze per processore fisico. Il che significa che il database server di $noicelimangiamo non poteva essere esteso o potenziato all'infinito senza dover richiedere il pagamento di ulteriori licenze. Ed ovviamente il rifare le procedure e denormalizzare richiedeva l'estensione dello stesso.
Alla fine, venne deciso che la cosa "migliore" da fare era di schedulare uno script che facesse una copia e data-reduction dal database in un secondo database (SQL Server per di piu) nella rete di $noicelimangiamo. Quindi da una soluzione "semplice" ad una molto, ma molto complicata...
Davide
07/08/2018 16:24
