Storie dalla Sala Macchine


Home Page | Commenti | Articoli | Faq | Documenti | Ricerca | Archivio | Storie dalla Sala Macchine | Contribuire | Imposta lingua:en it | Login/Register


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

Precedente Successivo

I commenti sono aggiunti quando e soprattutto se ho il tempo di guardarli e dopo aver eliminato le cagate, spam, tentativi di phishing et similia. Quindi non trattenete il respiro.

6 messaggi this document does not accept new posts

Arroz conPollo

Di Arroz conPollo postato il 27/08/2018 09:48

"del gioco preferito degli olandesi (puntare il dito contro qualcun altro)": tutto il mondo è paese, eh? Gli olandesi l'hanno copiato dagli italiani, ecché, proprio come hanno anche importato l'Ufficio Complicazione Affari Semplici.

-- Arroz conPollo

Davide Busato

Di Davide Busato postato il 28/08/2018 20:25

@theBoss (Davide per gli amici), grazie per il suggerimento sul libro, sto cercando di imparare un po'come funzionano i database ma non essendo il mio mestiere cerco qualcosa di "umano" e non troppo legato a un software specifico.

-- Davide Busato

emi_ska

Di emi_ska postato il 29/08/2018 09:07

Quello che mi sembra allucinante e' che l'id non fosse univoco... Che senso ha???

Ciao BigD, e' sempre un piacere leggerti!!

Emiliano

-- emi_ska

Anonymous coward

@ emi_ska Di Anonymous coward postato il 30/08/2018 11:34

 

Quello che mi sembra allucinante e' che l'id non fosse univoco... Che senso ha???

Ciao BigD, e' sempre un piacere leggerti!!

Emiliano

 

Probabilmente in questo caso l'id era una foreign key in una relazione 1 a molti.

-- Anonymous coward

Messer Franz

Di Messer Franz postato il 30/08/2018 18:17

Vogliamo parlare di quando  due ditte si fondono e vogliono unire i db interni che hanno tabelle con nomi praticamente uguali ma con campi che nessuno si ricorda a che cavolo servono e con query scritte in lingua di mordor (e tu non hai più il ring per decodificarle)?

Sono stato in una ditta dove avevano un sito con - cica - 15/20 "argomenti", cose da metter nel db (tipo: utenti, articoli, ditte...) e il db era di (non scherzo) 542 tabelle (o 546, cambia poco)  e ci lavoravano cira in 7-10 da 5 anni, mentre io l'avrei fatto da solo in 6 mesi...ma va detto che erano ingegneri e che lavoravano in c#...e ho detto tutto...

-- Messer Franz

Anonymous coward

Di Anonymous coward postato il 10/09/2018 15:51

> Questo e' un classico caso in cui e' bene de-normalizzare

 

mah a volte basta una procedura con un for e un accumulatore per tirarsi fuori dai guai

-- Anonymous coward

6 messaggi this document does not accept new posts

Precedente Successivo


Il presente sito e' frutto del sudore della mia fronte (e delle mie dita), se siete interessati a ripubblicare uno degli articoli, documenti o qualunque altra cosa presente in questo sito per cortesia datemene comunicazione (o all'autore dell'articolo se non sono io), cosi' il giorno che faccio delle aggiunte potro' avvisarvi e magari mandarvi il testo aggiornato.


Questo sito era composto con VIM, ora e' composto con VIM ed il famosissimo CMS FdT.

Questo sito non e' ottimizzato per la visione con nessun browser particolare, ne' richiede l'uso di font particolari o risoluzioni speciali. Siete liberi di vederlo come vi pare e piace, o come disse qualcuno: "Finalmente uno dei POCHI siti che ancora funzionano con IE5 dentro Windows 3.1".

Web Interoperability Pleadge Support This Project
Powered By Gojira