Tales from the Machine Room |
Home Page | Comments | Articles | Faq | Documents | Search | Archive | Tales from the Machine Room | Contribute | Set language to:en it | Login/Register
Long, long time ago... there was pen & paper. In fact "pen and paper" have been there for a very long time. Maybe it wasn't exactly "paper" or "pen" in the way we intend them today, but still stuff that allowed signs to be written (or traced, or carved) onto it was.
And the things that were "written" onto it were mostly... lists. Lists of stuff to be precise. Products that were stored in warehouses, products that were exchanged for other products, oroducts that needed to be transported, taken, given and so on. Stuff that we, today, would call "databases".
I've already said that databases are one of the oldest invention of the world, and have been used, in some form, for millennia. And there is nothing wrong with that. But... A Database is a very specific and peculiar tool and it is used to do a very specific and peculiar task and has to be used just for that task. As said before, if you try to use a tool for the wrong task, it doesn't work very well.
And as usual, some people knows a tool very well and he try to use it for everything, even when the tool is completly wrong for the situation at hand.
Now, if you are of the "old school", the term "database" is probably evoking images of monsters that eats tons of data and spit out some sort of SQL (one of the many forms), if you are a bit younger, you are still thinking to similar stuff but maybe less monstruos and a lot cheaper (in money).
All these tools are based on a very simple but precise set of rules that distinguish and define "databases" from other stuff that maybe can "look" as databases to the untrained eye (and don't get me started about Excel), but databases those things are definitively not.
All this long and convoluted introduction to explain (once more) that there is no such thing as a "silver bullet" to solve all your problems and for every situation you have to look for the best solution that fit. And if your "beloved" tool doesn't look like fitting, maybe is better to be left in the toolbox.
And now let's talk about $tripped, a company that did... several things, one of which was to run some sort of application that stored different data and then was presenting the same in tidy and neat tables.
The source data were collected in different ways, most of the time through automated procedure that read files or such (on and off line) and all this stuff was chucked into a database that was then analyzed to build the resulting tables. They weren't using cellular network otherwise I'd say that all this was very reminescent of $wemeasurestuff of which I've already talked about.
In fact, their problems were almost the same, except that in this case the problem wasn't the application structure, but the fact that they decided, long time ago, to use a well known SQL database as data collection point... without doing anything that required SQL then.
I'll try to explain.
A SQL database usually has some sort of "optimizier" to turn the queries that are provided by the meatbag into a series of "filters" that are then applied to the data in a way to minimize the amount of data the database itself has to look at before being able to present its information. In order for this optimizer to work ...her... optimally, there should be a precise and clear distinction between the TYPE of data stored and the way they are stored. This in turn require a very careful construction of the tables and indexes used to maximize the use of indexes and minimize the amount of tablescan required to do... everything basically.
The more the database uses the indexes to access the information and the fast and accurate is the information retrival.
So... What happens when we have to maintain a considerable mass of data that are basically all similar and devoided of a precise structure and where the data actually don't have very much a "type" distintion?
Well, it happens that the structure we get doesn't really work in a "classic" structure and try to fit this into that gives a system that is very, very inefficient.
And "inefficient" is a bit an understatement for this. Besides waiting time that would've tried Job's patience, beyond some level a lot of "unexpected errors" began to present themselves. At least, the errors were "unexpected" for $tripped's developers and the various UL/SL, for me, after looking at the whole contraption, I was actually expecting that the timeouts were unavoidable when the system was trying to process millions of rows to extract maybe an handful of them and then process another few millions in order to match the few found before and turn out with a table that maybe contained 3 rows.
Obiously, $tripped began to complain with us about the "unaccpetable slowness" of the whole infrastructure. As expected, the slowness was "unacceptable" but this didn't meant they were going to bring their stuff to some other provider, even the ones that ($tripped said) "was going to guarantee performances that wer 3 to 4 times better", my reading of the whole thing was that maybe the other provider were say so, but after payment of a very large sum of money that $tripped really didn't wanted to pay.
And as usual, since the world is still a ball, somebody was "volounteered" to "optimize" the whole stuf. And as usual, all the geniuses that are super-expert of every single thing under the sun, as long as it is a matter of talking at the coffee machine and throwing buzzwords around in meetings, but when it is a matter of DOING things practically, everybody is super-busy and all their projects are "very urgent and quite late", but not so "urgent" and not so "late" that you're thinking of getting in the office on time isn't it?
So I ended up in a meeting trying to explain, for the millionth time, to a developer (CL) that has no clue what he is doing and to his boss (UL) that has even less clue, that the idea to use a relational database to store information that relational are truly not, is not a very good one.
Me - ...hence, your data structure is completely wrong for this type of things.
CL - The data structure wasn't designed by me, it was already like this.
Me - And that's ok. But the fact that is wrong for this kind of things is still a fact. And that's the main reason your system is so slow.
UL - (that doesn't know a thing of databases, doesn't understand a thing of computers, has no idea about the application's structure and is unclear what he is doing in this meeting, besides annoying me) But if we try to optimize the database structure which improvement of the performance could we get?
Me - There is nothing to optimize. Is like to try to race a Formula One Grand Prix with a tractor.
CL - What has a tractor to do with it now?
Me - It has power in quantity but is designed to be slow. And that's your problem. You database has power in quantity but is built to do something completely different.
UL - But if it has power in quantity why can't it go faster?
Me - Which part of "designed to be slow" wasn't clear?
CL - And how can we change it to make it go faster?
Me - Replacing it with something completely different. Given the use you want to do of it, I think that something like Mongo or Redis should be more in tune with it.
CL - Monwhat?
Me - No What, Go. Mon-Go. Never heard of non-relational databases?
CL - Non-relational? How can you have a non-relational database? If it's non-relationa ain't a database!
Me - Well ok, referring to it as "database" is maybe a bit of a stretch on the term, but since we don't have a better word for it...
UL - And why your database doesn't support this mongothing here?
Me - It's YOUR database, not ours, we provide the platform, you decide what to run on it.
CL - But let say we need to run a query that make a join...
Me - No, you don't make joins, what you do is to fetch all the data and then you look up matches with other parts, if you want to do it.
CL - But we have all the queries that...
Me - ..don't work. And that's the problem. With your data structure and the way you want to manage the data you can't make "queries". You have to think in a different way.
CL - Impossible! Change the approach would require a complete redesign of the backend!
Me - Indeed.
UL - (still hasn't figured out what we were talking about) And if we put the mongothing on top of our current database?
Me - No, it doesn't work like this.
CL - Redesign the whole backend? It can take months!
UL - $otherprovider has guaranteed us that their structure will provide 4 times the performance of yours!
Me - Then I suggest you go to them, and I'm not going to tell you to actually TEST those performances and get them in writing in the contract because I assume they aren't stupid and won't be in any measurable way.
UL - (understanding that I'd like to see them going somewhere else, as opposed to what MarketingMan would like) ...but if we instead focus on the optimization of the database? Like, if we add more ram to it?
...No, they never learn or understand.
Davide
23/09/2019 10:38
Comments are added when and more important if I have the time to review them and after removing Spam, Crap, Phishing and the like. So don't hold your breath. And if your comment doesn't appear, is probably becuase it wasn't worth it.
By Anonymous coward posted 14/10/2019 12:03
uff, la solita storia dei clienti imbecilli: cambiano le teste che lo indossano, ma il cappello dice sempre "idiota".
E come già detto, qui lo ripeto: dagli-quello-che-vogliono-purchè-paghino
Piu ram? ok, costa X.
Altre cpu? perfetto, costano Y.
Un load balancer nuovo? costa Z.
Ovviamente devono FIRMARE che lo hanno voluto loro e che tu hai detto che non avrebbe fatto la differenza.
Cosi' soldi in piu' per te (cioe', per DB) e di certo soddisfazone per te: che e' danaro ma che spessissimo vale PIU' dei soldi.
Perche non fai dei prestampati con commento fisso "tanto non funziona, io vi ho avvisato, ma se volete così, che così sia basta che poi non ve ne lamentiate con me" e con spazio libero per $costo, $risorsahadwaredacambiare, $nomecliente, $firmacliente?
Tanto vogliono sempre la stessa cosa: tentare di "salvare" con hardware cioò che è stato mal concepito in software.
-- Anonymous coward
@ Anonymous coward By Guido posted 15/10/2019 08:33
Cosi' soldi in piu' per te (cioe', per DB) e di certo soddisfazone per te: che e' danaro ma che spessissimo vale PIU' dei soldi.
La soddisfazione ce l'hai pero' il problema rimane. E indovina un po' poi a chi tocca? Magari dopo mesi (o anni) e quindi peggiorato dalla furia (se non da altri problemi sopraggiunti nel frattempo)?
-- who uses Debian learns Debian but who uses Slackware learns Linux
By Anonymous coward posted 14/10/2019 14:03
CL - RIPROGETTARE TUTTO IL BACKEND?? Ci vorrebbero dei mesi!
Che è il motivo per cui da me abbiamo ancora applicazioni di 20 anni fa, con i sistemi castrati per far funzionare quelle porcherie...
-- Anonymous coward
@ Anonymous coward By Guido posted 15/10/2019 08:37
Che è il motivo per cui da me abbiamo ancora applicazioni di 20 anni fa, con i sistemi castrati per far funzionare quelle porcherie...
Poi quando la libreria X o la versione Y del linguaggio che stai usando non e' piu' supportata da nessuno ti ritrovi con un sistema di botto non funzionante - e piu' aspetti ad aggiornarti e piu' il passo diventa grosso... Chiedi a $ENTE dove lavoro. Sono anni che gli dicevo che la Java 1.6 (su jsf1 + jboss5) non era il caso di tenerla. Passare alla 1.8 comportava una riscrittura totale dell'applicativo (che in effetti avevo messo quasi clandestinamente in cantiere) perche' cambia tutta l'architettura di wildfly & co. Aruba ha aggiornato i certificati TLS a 1.2 e java 1.6 e 1.7 sono automaticamente tagliate fuori. La pec non funziona piu' - adesso hanno furia e il progetto clandestino e' diventato ufficiale. M'avessero dato retta 3 anni fa non si sarebbe a questi punti.
-- who uses Debian learns Debian but who uses Slackware learns Linux
@ Guido By Anonymous coward posted 16/10/2019 11:36
Che è il motivo per cui da me abbiamo ancora applicazioni di 20 anni fa, con i sistemi castrati per far funzionare quelle porcherie...
Poi quando la libreria X o la versione Y del linguaggio che stai usando non e' piu' supportata da nessuno ti ritrovi con un sistema di botto non funzionante - e piu' aspetti ad aggiornarti e piu' il passo diventa grosso... Chiedi a $ENTE dove lavoro. Sono anni che gli dicevo che la Java 1.6 (su jsf1 + jboss5) non era il caso di tenerla. Passare alla 1.8 comportava una riscrittura totale dell'applicativo (che in effetti avevo messo quasi clandestinamente in cantiere) perche' cambia tutta l'architettura di wildfly & co. Aruba ha aggiornato i certificati TLS a 1.2 e java 1.6 e 1.7 sono automaticamente tagliate fuori. La pec non funziona piu' - adesso hanno furia e il progetto clandestino e' diventato ufficiale. M'avessero dato retta 3 anni fa non si sarebbe a questi punti.
--------------------------------------------------------
dove lavoravo io la procedura sarebbe stata:
A. chiusura immediata del tuo progetto "semi clandestino" avente come conseguenza:
caso uno. SE VA BENE: megacazziatone nei tuoi confronti per aver avviato un progetto NON autorizzato, comportante drenaggio di risorse che avrebbero potuito essere profiquamente impiegati per attività "lecite", additamento della tua persona a tutta l'azienda quale "testa calda", "inaffinabile", "anarchico", "indisciplinato", ecc ecc
caso due. SE VA MALE: caso 1 + lettera di richiamo ufficiale che "peserà" su tuo futuro aziendale (bonus, promozioni, ecc)
B. avvio di un progetto UFFICIALE che è concettualmente identico al tuo, ma:
1. costa il triplo
2. verrà implementato in tempi 5 volte superiori
3. sarà tecnologicamente arretrato e (quindi nascerà "vecchio") oppure talmente avanzato da essere instabile e incompatibile col resto del mondo.
-- Anonymous coward
@ Anonymous coward By Guido posted 21/10/2019 11:16
I cazziatoni ci sono stati. Mi ha salvato $PROVIDER che ha aggiornato a TLS 1.2 e quindi ha tagliato tutto cio' che era inferiore a java 1.8 (che e' un requisito MINIMO quindi si nasce gia' vecchio...)
Che è il motivo per cui da me abbiamo ancora applicazioni di 20 anni fa, con i sistemi castrati per far funzionare quelle porcherie...
Poi quando la libreria X o la versione Y del linguaggio che stai usando non e' piu' supportata da nessuno ti ritrovi con un sistema di botto non funzionante - e piu' aspetti ad aggiornarti e piu' il passo diventa grosso... Chiedi a $ENTE dove lavoro. Sono anni che gli dicevo che la Java 1.6 (su jsf1 + jboss5) non era il caso di tenerla. Passare alla 1.8 comportava una riscrittura totale dell'applicativo (che in effetti avevo messo quasi clandestinamente in cantiere) perche' cambia tutta l'architettura di wildfly & co. Aruba ha aggiornato i certificati TLS a 1.2 e java 1.6 e 1.7 sono automaticamente tagliate fuori. La pec non funziona piu' - adesso hanno furia e il progetto clandestino e' diventato ufficiale. M'avessero dato retta 3 anni fa non si sarebbe a questi punti.
-- who uses Debian learns Debian but who uses Slackware learns Linux
@ Guido By Davide Bianchi posted 22/10/2019 08:30
Che è il motivo per cui da me abbiamo ancora applicazioni di 20 anni fa, con i sistemi castrati per far funzionare quelle porcherie...
Poi quando la libreria X o la versione Y del linguaggio che stai usando non e' piu' supportata da nessuno
Si', e poi succede come successe da $formaggini, di cui ho parlato in casino di tempo fa:
https://www.soft-land.org/storie/09/story51
-- Davide Bianchi
@ Davide Bianchi By Guido posted 23/10/2019 08:04
Qui su $ENTE adesso piangono perche' non funziona piu' la pec (aruba rispondendo ad un requisiti agid ha aggiornato TLS a 1.2 tagliando fuori tutto cio' che non lo usa aka tutte le versioni di java precedenti alla 1.8). Purtroppo c'e' stato un problema di fondo: nessuno si e' mai preso la briga di tenere il sw aggiornato, per cui passare dalla 1.6 alla 1.7 (e da jboss 5 a 6) e dalla 1.7 alla 1.8 (e a wildfly) sarebbero stati tutti piccoli passi perfettamente fattibili. Solo che nessuno aveva voglia di rompersi i cosiddetti (e nessuno aveva voglia di far presente al cliente che 'ste robe sarebbero state necessarie). Per cui piu' il tempo passava piu' il passo diventava grosso e nessuno aveva voglia di farlo. Poi e' diventato talmente grosso da essere sostanzialmente una riscrittura e ovviamente il cliente non ne ha capito la necessita' finche' non ci ha battuto il muso di brutto. Oltretutto che piu' ancora aspetti e piu' il problema continua a crescere.
Senza considerare l'aspetto sicurezza. Java 1.6 ha delle falle clamorose ed entrambi (lei e jboss 1.5) sono EOL per cui niente piu' aggiornamenti o patch - sei sostanzialmente a rischio...
PS la storia di formaggini la lessi illibus temporibus
Che è il motivo per cui da me abbiamo ancora applicazioni di 20 anni fa, con i sistemi castrati per far funzionare quelle porcherie...
Poi quando la libreria X o la versione Y del linguaggio che stai usando non e' piu' supportata da nessuno
Si', e poi succede come successe da $formaggini, di cui ho parlato in casino di tempo fa:
https://www.soft-land.org/storie/09/story51
-- who uses Debian learns Debian but who uses Slackware learns Linux
By Anonymous coward posted 14/10/2019 15:43
Vedi Davide, il lavoro degli UL non è produrre risultati ottimali, e tantomeno ottimizzati, al contrario.
Lo scopo degli UL è proprio quello di usare più risorse possibile in modo da "pesare" il più possibile in azienda, e una volta che questa stira le zampe (anche grazie alla loro inettitudine) migrare ad altri lidi scrivendo nel CV di avere "gestito" progetti con n uomini e del valore di x euri, dove più sono alti n e x tanto meglio figurano nel CV.
I risultati, quelli, comunque ben pochi SL arebbero in grado di valutarli e comunque non sempre sono applicabili ad altri contesti - parlo dell'UL medio che un giorno "vende" cravatte e l'anno dopo "progetta" bulloni.
Quindi nel momento in cui gli riveli che vanno incontro a molta spesa per poca resa, in realtà gli stai indicando che in effetti è proprio ciò che serve al loro modello bacato di fare carriera.
-- Anonymous coward
@ Anonymous coward By Anonymous coward posted 28/10/2019 20:56
"Lo scopo degli UL è proprio quello di usare più risorse possibile in modo da "pesare" il più possibile in azienda, e una volta che questa stira le zampe (anche grazie alla loro inettitudine) migrare ad altri lidi scrivendo nel CV di avere "gestito" progetti con n uomini e del valore di x euri, dove più sono alti n e x tanto meglio figurano nel CV."
Medhi Ali, il UBER LUSER DEGLI UBER LUSER - e chi mastiC=a come me sa di cosa parlo...
-- Anonymous coward
@ Anonymous coward By Brott posted 31/10/2019 14:55
Medhi Ali, il UBER LUSER DEGLI UBER LUSER - e chi mastiC=a come me sa di cosa parlo...
Uscito Tramiel dai giochi, per C= iniziò il declino... La mela morsicata sta per fare la stessa fine, dopo l'abbandono per cause di forza maggiore (ahem!) del suo fondatore.
-- Brott
By Antonio Pennino posted 14/10/2019 19:07
Questa storia puo' essere facilmente ambientata nella mitica sala riunioni di $brancodipaguri. Purtroppo sonio tutti uguali, vogliono la soluzione senza cambiare nulla, senza spendere nulla, soprattutto senza pensare.
-- Antonio Pennino
By Messer Franz posted 14/10/2019 19:25
>RIPROGETTARE IL BACKEND? Ci vorrebbero dei mesi!
Ah beh, con la qualità dei loro programmatori forse anche anni...
Comunque io avrei un'idea: gli lasciarei l loro db, ma dividerei le tabelle in più server, così il lavoro viene distribuito e le prestazioni migliorano!
Direte voi: ma se legge una tabella, poi un'altra, poi un'altra ecc, che le legga da un server o più non cambia un ciufolo, la suddivisione dà vantaggi in altri casi...
Giusto, dico io: ma
A)Gli avete lasciato il loro db che ci tengono tanto
B)Gli avete affittato più server, e il MarketingMan sarà contento
C)Tempo che i loro programmatori preparino il programma per leggere da più server ci vorrà parecchio tempo, e tu avevi accennato che te ne volevi andare da là, quindi con un po' di fortuna quando si testa la cosa tu sei già volato via
D)E' un piano facilmente comprensibile da un UL (anche se non funziona, anzi, forse proprio per questo) e quindi gli piacerebbe
E,F,G->Z)La riunione finisce, si tolgono dalle pelotas per un po' e tu rifiati!
-- Messer Franz
By Guido posted 15/10/2019 08:32
Ma se invece ci concentrassimo sull'ottimizzare le prestazioni del database? Per esempio, se aggiungessimo della ram?
Odio profondo ed incommensurabile quando odo questa frase (e si a lavoro la sento fin troppo spesso). Soluzione alla M$ non migliorare le prestazioni aumenta il sistema...
(Nel nostro caso cercavamo di fare capire che avere files su db e' male - la risposta da parte dei capoccia e' stata "Se ci sono problemi aumenteremo la ram")
Sigh
-- who uses Debian learns Debian but who uses Slackware learns Linux
By Messer Franz posted 15/10/2019 08:45
Ditemi che non sono solo io che invece di $sgambetti continua a leggere $gamberetti... che so di avere problemi, ma così gravi non pensavo...
-- Messer Franz
@ Messer Franz By Anonymous coward posted 16/10/2019 11:29
Ditemi che non sono solo io che invece di $sgambetti continua a leggere $gamberetti... che so di avere problemi, ma così gravi non pensavo...
No no, anch'io
@ Messer Franz By Bennt posted 17/10/2019 13:42
Ditemi che non sono solo io che invece di $sgambetti continua a leggere $gamberetti... che so di avere problemi, ma così gravi non pensavo...
Quazzzzpita! Anch'io avevo letto $gamberetti! Sono andato a rileggere il post e ho correttamente letto $gambetti. È proprio vero che non leggiamo mai tutte le parole, ma solo l'inizio e la fine e deduciamo il resto (in questo caso male).
-- Bennt
@ Messer Franz By Marco posted 19/10/2019 22:53
Ditemi che non sono solo io che invece di $sgambetti continua a leggere $gamberetti... che so di avere problemi, ma così gravi non pensavo...
Immagina che io leggevo gambetti, e non ci arrivavo a capire cosa potessero centrare gli scacchi con questa storia
-- Marco
By Piripakken posted 15/10/2019 09:39
La tua immagine di presentazione è azzeccata: ci vuole un martello.
Da dare sulla crapa di UL, ovviamente.
Poi, vogliono migrare ad $altroprovider? Ma prego; a nemico che fugge, ponti d'oro...
By Darathorn posted 22/10/2019 12:19
programmatore del gestionale (accrocchio in vb6 con db mssql):
vedi il problema ? le query vanno in errore perchè ha pochi processori e ram.
io:
8 core e 40 GB mi sembrano tutt'altro che pochi, comunque l'applicazione è in vb6 a 32 bit , più di un processore non usa
programmatore:
no no aumenta i processori e vedrai che non andranno più in timeout e non genereranno code
io:
semmai ci arriveranno prima, c'è qualcosa di sbagliato a livello di accesso ai dati
programmatore: aumenta i processori
io: e anche le query secondo me non sono ottimizzate
programmatore: aumenta i processori
una ora dopo, dopo aver spento la macchina , aumentato da 8 a 16 i core e riavviato
programmatore: adesso lanciamo 2-3 elaborazioni di quelle pesanti e vedrai che passano
io ed il DG: vediamo
programmatore: lanciato
5 minuti dopo: errore timeout/deadlock
io: ok che facciamo
DG: mumble
programmatore: ehm
@ Darathorn By Anonymous coward posted 23/10/2019 14:27
io: ok che facciamo
programmatore: ehm
------------
e poi lo hai legato per terra e gli hai cagato in faccia, vero? Dimmi che e' cosi!
-- Anonymous coward
@ Anonymous coward By Anonymous coward posted 28/10/2019 20:59
>io: ok che facciamo
>
>programmatore: ehm
>
>------------
>e poi lo hai legato per terra e gli hai cagato in faccia, vero? Dimmi che e' cosi!
Ma dai, RICOMPENSARLO anche?
-- Anonymous coward
This site is made by me with blood, sweat and gunpowder, if you want to republish or redistribute any part of it, please drop me (or the author of the article if is not me) a mail.
This site was composed with VIM, now is composed with VIM and the (in)famous CMS FdT.
This site isn't optimized for vision with any specific browser, nor
it requires special fonts or resolution.
You're free to see it as you wish.