A long time ago in a far far away galaxy...
Nel lontano 2000, quando imberbe, giovane e stolto mi avvicinai al mondo dell'IT ebbi una prima esperienza da Database Administrator o almeno cosi' credevo.
All'epoca ero un developer, programmavo in ASP su Windows NT 4.0 (gran sistema, davvero) e mi interfacciavo con il simpatico MS-SQL Server 7, bleeding edge dell'epoca.
Nella solita logica italica, della quale ero ancora all'oscuro, il mio ruolo era di tipo multitasking.
Uno stipendio per 4/5 mansioni tutte diverse e tutte allo stesso livello di priorita', una delle quali era proprio amministrare il database di cui sopra.
Saltuariamente arrivava roba in access che doveva essere importata e li ci mettevo le mani io, principalmente in vbscrip.
Ricordo ancora quando un giorno arrivo' un catalogo in access dalle dimensioni importanti per l'epoca, 590 MB, un intero cdrom occupato da un file mostruoso.
Tale file era si' grande per due caratteristiche, le stesse che oggi vengono spacciate come LA SOLUZIONE ai problemi di dati.
- normalizzache'? il database era composto da una sola stramaledetta tabella, probabilmente frutto di un iniziale copia/incolla da excel e messa su access a causa del limite di righe imposto da tale software
- manutenche'? il file di access non era mai stato compattato. ora access e' simile a postgres in termini di update. si tiene dentro le versioni precedenti ogni volta che si aggiorna una riga. E se non si fa una manutenzione periodica, compattando il file, questi diventa enorme.
Fatto sta che dopo la compattazione il file risultante era di soli 300kb (!!!!!!!!).
The big (bubble) data
Lo confesso, ogni volta che sento le parole big data un brivido mi parte giu' dal collo e scende verso il culo.
Ancora ho i segni della bolla di internet e la nuova buzzword big data mi ricorda per certi aspetti la bolla del 2002/2003.
Le ragioni che mi fanno pensare ad una seconda bolla sono varie, cerchero' di elencarle in maniera ragionata.
- se ne parla troppo
ormai e' quasi impossibile trovare discussioni tecniche che non parlino di questo fantomatico big data. La quando scrive o quando parla butta le parole da qualche parte, contestualizzate o meno e subito la audience diventa piu' attenta, si aprono i cordoni della borsa, i manager sono interessati in quanto si sta parlando di roba bleeding edge e trending. Come nel 2000, quando bastava dire internet per avere la limousine con autista e attendente al pezzo sul sedile posteriore. - molti non sanno cosa big data voglia dire
Cosa vuol dire big data, spiegatemelo possibilmente senza riferimenti a wikipedia. perche' se quello e' il significato allora questa buzzword e' sinonimo di un vecchio termine, magari meno altisonante e piu' criptica ma molto piu' sensata e concreta. Very Large Databases (VLDB).
Come nel 2000 dove tutti si riempivano la bocca della parola internet senza capire niente, a parte andare a ravanare sui siti porno e scaricare musica a scrocco su napster. - design defective
nel mio attuale lavoro mi occupo di database grossi, svariati TB, niente in confronto al mio record di qualche decina di TB, ma di questo ne parlero' successivamente. Ora al vero ambiente relazonale si e' agganciato un ambiente NOSQL, il quale e' il database access di cui sopra, intortato di paroloni come HA, durable storage e altre buzzwords, il cui scopo sarebbe quello di velocizzare e ottimizzare l'accesso ai dati planet sized.
Questo punto mi ricorda molto i tempi della corsa alle alte velocita' dei processori pentium e k6. Dove invece di puntare sull'architettura si spremevano i chip ad andare con clock sempre piu' veloci, finche' non si e' sbattuti la faccia sul limite fisico.
L'approccio moderno, quello NOSQL e' identico. La differenza sta nello storage che viene sacrificato in nome di una efficienza di accesso che onestamente fatico a vedere e che alla lunga portera' di nuovo a sbattere la faccia sul muro del limite fisico ed economico se volete.
Il che ci porta alla parte della denormarmalizzazione.
The oracle way
Aridaje con oracle direte voi.
Beh io ho iniziato a occuparmi seriamente di dati quando ho iniziato a lavorare con oracle. E quello e' e sara' sempre il mio modello di riferimento, per professionalita' e cura dell'architettura.
Anyway, un trend derivato da dall'approccio BIGDATA/NOSQL e' quello che ormai si tende a denormalizzare tutto, privando il termine RDBMS (Relational Database Management System) della R.
Ora per carita' i dati possono assumere varie forme e spesso denormalizzare/aggregare e' la via piu' veloce per tirare via dati coerenti dal database. Ma qui si sta esagerando, portando all'estremo la situazione e ottenendo il risultato di cui sopra, defective design che viene tamponato con hardware sempre piu' potente e performante senza guardare minimamente alle prestazioni sul fronte architetturale.
Faccio un esempio pratico. Sono vari anni che lavoro su PostgreSQL, ho maturato una notevole esperienza su sistemi enterprise di vario genere e ho cambiato varie aziende nel frattempo.
Il comun denominatore di codeste aziende e' sempre stato quello di avere un modello dati variabile tra il discreto e l'osceno, con necessita' di scalare tale modello e con delle scelte, di programmazione e di implementazione, a dir poco discutibili.
Ora PostgreSQL ha un difetto rispetto ad Oracle IMHO. Non dice mai basta, anche quando un programmatore/designer fa delle scelte sbagliate sotto tutti i punti di vista, lui lavora, magari rallenta, ma non si ferma mai.
Ecco Oracle no. Oracle con un banale ORA-600 o con il piu' classico dei classici ORA-1555 ti sputa in faccia e ti dice DEFICIENTE, SCRIVI ROBA DECENTE PRIMA DI AZZARDARTI A TOCCARMI.
Ecco quindi che in genere le scelte sbagliate vengono stroncate sul nascere.
Ora uno delle nuove features implementate da PostgreSQL e' questa sequenza di moduli schemaless tipo HSTORE, JSON e compagnia bella.
Tali oggetti ha, da un lato, aperto il prodotto al mercato NOSQL avendo in maniera nativa oggetti di tale tipo e da un altro ha fatto credere ai programmatori che questa fosse la soluzione.
Ma, c'e' un ma.
Se da un lato un tipo key -> value come hstore apre la possibilita' di non toccare piu' lo schema, dall'altro lato previene la possibilita' di indicizzare con indici BTREE tali dati e gli indici supportati, i GIN non hanno gli operatori di eguaglianza, essendo disegnati per operare su vettori testuali e dati geografici. Tale limitazione rende impossibile ottimizzare le query che contengono filtri su tali dati.
Inoltre i dati sono memorizzati in forma binaria, ovvero ottetti di stringhe binarie, cosi' come sono e poi sono manipolati in memoria dalla libreria esterna.
Tralasciando l'overhead indotto dall'uso di librerie dinamiche, cio significa che anche solo memorizzare un numero intero di 4 bytes originali spreca il nome della chiave, il blocco operatore di chiave e il numero piu' le quotes. Se se per assurdo stessimo inserendo una chiave di un solo carattere, lo storage adoperato da un hstore/json costa ben 10 bytes contro i 4 di un integer.
I fan di questo tipo di approccio diranno che il vantaggio di tale dato e' quello di poter operare sullo schema senza dover alterare la tabella. Balle.
Con Oracle abbiamo tabelle convenzionali di dimensioni mostruose da almeno dieci anni e cio' non ha mai impedito le modifiche allo schema.
Certo le cose vanno fatte in un certo modo, ma da qui a sprecare memoria, tra l'altro molto costosa, per ogni singola riga solo per poter mettere liberamente in qualsiasi tipo di campo in un metacampo e' follia pura.
Ecco quindi che mi ritorna in mente il vecchio motto dei tempi andati
"economico", "funzionante","veloce". scegline due.
Non e' cambiato niente da allora.
Personalmente credo che con questo rozzo e incoerente approccio nell'ambito dei database si sia fatto un salto indietro di almeno 10 anni, forse anche di piu'.
Perche' 10 anni fa quel database access denormalizzato e gonfiato suscito' l'ilarita' di tutto l'ufficio.
Oggi la stessa merda suscita attenzione e meraviglia.
Qualcosa e' andato fottutamente storto.
Beh io ho iniziato a occuparmi seriamente di dati quando ho iniziato a lavorare con oracle. E quello e' e sara' sempre il mio modello di riferimento, per professionalita' e cura dell'architettura.
Anyway, un trend derivato da dall'approccio BIGDATA/NOSQL e' quello che ormai si tende a denormalizzare tutto, privando il termine RDBMS (Relational Database Management System) della R.
Ora per carita' i dati possono assumere varie forme e spesso denormalizzare/aggregare e' la via piu' veloce per tirare via dati coerenti dal database. Ma qui si sta esagerando, portando all'estremo la situazione e ottenendo il risultato di cui sopra, defective design che viene tamponato con hardware sempre piu' potente e performante senza guardare minimamente alle prestazioni sul fronte architetturale.
Faccio un esempio pratico. Sono vari anni che lavoro su PostgreSQL, ho maturato una notevole esperienza su sistemi enterprise di vario genere e ho cambiato varie aziende nel frattempo.
Il comun denominatore di codeste aziende e' sempre stato quello di avere un modello dati variabile tra il discreto e l'osceno, con necessita' di scalare tale modello e con delle scelte, di programmazione e di implementazione, a dir poco discutibili.
Ora PostgreSQL ha un difetto rispetto ad Oracle IMHO. Non dice mai basta, anche quando un programmatore/designer fa delle scelte sbagliate sotto tutti i punti di vista, lui lavora, magari rallenta, ma non si ferma mai.
Ecco Oracle no. Oracle con un banale ORA-600 o con il piu' classico dei classici ORA-1555 ti sputa in faccia e ti dice DEFICIENTE, SCRIVI ROBA DECENTE PRIMA DI AZZARDARTI A TOCCARMI.
Ecco quindi che in genere le scelte sbagliate vengono stroncate sul nascere.
Ora uno delle nuove features implementate da PostgreSQL e' questa sequenza di moduli schemaless tipo HSTORE, JSON e compagnia bella.
Tali oggetti ha, da un lato, aperto il prodotto al mercato NOSQL avendo in maniera nativa oggetti di tale tipo e da un altro ha fatto credere ai programmatori che questa fosse la soluzione.
Ma, c'e' un ma.
Se da un lato un tipo key -> value come hstore apre la possibilita' di non toccare piu' lo schema, dall'altro lato previene la possibilita' di indicizzare con indici BTREE tali dati e gli indici supportati, i GIN non hanno gli operatori di eguaglianza, essendo disegnati per operare su vettori testuali e dati geografici. Tale limitazione rende impossibile ottimizzare le query che contengono filtri su tali dati.
Inoltre i dati sono memorizzati in forma binaria, ovvero ottetti di stringhe binarie, cosi' come sono e poi sono manipolati in memoria dalla libreria esterna.
Tralasciando l'overhead indotto dall'uso di librerie dinamiche, cio significa che anche solo memorizzare un numero intero di 4 bytes originali spreca il nome della chiave, il blocco operatore di chiave e il numero piu' le quotes. Se se per assurdo stessimo inserendo una chiave di un solo carattere, lo storage adoperato da un hstore/json costa ben 10 bytes contro i 4 di un integer.
I fan di questo tipo di approccio diranno che il vantaggio di tale dato e' quello di poter operare sullo schema senza dover alterare la tabella. Balle.
Con Oracle abbiamo tabelle convenzionali di dimensioni mostruose da almeno dieci anni e cio' non ha mai impedito le modifiche allo schema.
Certo le cose vanno fatte in un certo modo, ma da qui a sprecare memoria, tra l'altro molto costosa, per ogni singola riga solo per poter mettere liberamente in qualsiasi tipo di campo in un metacampo e' follia pura.
Ecco quindi che mi ritorna in mente il vecchio motto dei tempi andati
"economico", "funzionante","veloce". scegline due.
Non e' cambiato niente da allora.
Personalmente credo che con questo rozzo e incoerente approccio nell'ambito dei database si sia fatto un salto indietro di almeno 10 anni, forse anche di piu'.
Perche' 10 anni fa quel database access denormalizzato e gonfiato suscito' l'ilarita' di tutto l'ufficio.
Oggi la stessa merda suscita attenzione e meraviglia.
Qualcosa e' andato fottutamente storto.
