Si SQL, No SQL...
Tanto tempo fa... Esistevano la carta e la penna. In effetti, carta e penna sono esistiti per parecchio tempo. Magari non era proprio "carta" o "penna" nel modo che lo intendiamo noi, ma sempre di roba sui cui si scriveva (o si tracciavano, in qualche modo, dei segni ben precisi) si trattava.
E le cose che venivano scritte piu' di che altro erano... elenchi. Elenchi di roba per la precisione. Liste di prodotti conservati in magazzini, prodotti che venivano scambiati per altri prodotti, prodotti che dovevano essere presi, dati, ritornati e roba cosi'. Quello che oggi noi chiameremmo un "database".
Ho gia' detto che i database sono una delle invenzioni piu' vecchie del mondo e sono stati usati, in una forma o nell'altra, per millenni. E non e' che ci sia qualche cosa di sbagliato. Solo che... Un database e' uno strumento particolare, pensato per uno scopo particolare e che deve essere utilizzato per quello scopo particolare. Se lo strumento non si adatta allo scopo, non bisognerebbe usare lo strumento.
Come al solito, c'e' gente che conosce uno strumento e cerca di usarlo in qualunque situazione, anche quando tale situazione e' completamente inadatta allo strumento.
I database per esempio... Se anche voi siete della 'vecchia sQuola', sarete abituati a "mostri" che macinano un sacco di dati e blaterano SQL (uno dei tanti dialetti), se siete un pelo piu' giovani magari state pensando ad altri cosi, sempre "SQL" ma meno mostruosi.
Tutti questi arnesi si basano su una serie di semplici ma precise regole che distinguono un "database" da altre cose, che possono "sembrare" database all'occhio non allenato, ma che database proprio non sono (e non fatemi parlare di Excel per la carita').
Tutto questo panegirico per specificare che non esiste (in genere) un "proiettile d'argento" che risolve tutti i problemi, e che per ogni problema bisogna cercare la soluzione che meglio si adatta. E se il nostro "strumento del cuore" non sembra adattarsi tanto bene, magari e' il caso di non usarlo.
E con questo, passiamo a parlare di $sgambetti, una societa' che si occupava di varie cose, una delle quali era una specie di applicazione che memorizzava roba e poi la presentava in ordinate tabelle molto elaborate.
I dati venivano recuperati in diversi modi, in genere mediante delle procedure automatiche che leggevano files o altre sorgenti (on-line o off-line) e tutta sta roba veniva infilata in un database che poi veniva analizzato per produrre queste tabelle. Se non fosse che non usavano sorgenti di dati via rete cellulare, direi che la struttura di base l'avevano copiata da $noimisuriamoroba, dei quali ho parlato precedentemente.
In effetti i problemi di questa gente erano QUASI identici a quelli di $noimisuriamo, salvo il fatto che il problema non era tanto nella struttura dell'applicazione, ma nel fatto che questa genta aveva deciso di usare come base dati un database SQL... Senza poi fare niente che richiedeva SQL in effetti.
Mi spiego meglio. Un "database" SQL in genere utilizza un "ottimizzatore" per trasformare la query che viene fornita in una serie di "filtri" che sono poi applicati ai dati presenti nei vari indici in modo da estrarre i dati richiesti nel modo piu' efficiente possibile. Perche' questo ottimizzatore funzioni in modo.. hemmm... ottimale, ci deve essere una precisa distinzione di TIPO nei dati che sono memorizzati. Questo perche' gli indici vengono costruiti in modo piu' efficiente e si utilizza un "filtro" diverso a seconda del tipo di dato. Percui e' necessario che le tabelle che sono costuite siano costruite in modo da massimizzare l'uso degli indici e minimizzare la "dispersione" delle informazioni.
Piu' il database utilizza i suoi indici per accedere alle informazioni piu' rapido e preciso e' il reperimento delle informazioni.
Quindi... cosa succede se ci ritroviamo a dover gestire una massa di dati abbastanza amorfa e priva di una struttura ben precisa, in cui la suddivisione delle informazioni ha poca (o nessuna) relazione tra i vari "tipi"?
Succede che quello che otteniamo si adatta molto male ad un database di tipo "classico" e cercare di gestire questa roba come tale risulta in un sistema che e' molto, ma molto, inefficiente.
Ed inefficiente era un modo molto "blando" per definire l'intero accrocchio. Oltre ad attese che avrebbero messo a dura prova la pazienza di Giobbe, oltre un certo livello cominciano a presentarsi "errori" inattesi nell'intera faccenda. Cioe' gli errori erano "inattesi" per i programmatroti ed i vari UL/SL di $sgambetti, personalmente, dopo aver dato un'occhiata alla sruttura della cosa, avevo dato per scontato che una serie di "timeout" erano inevitabili quando le varie procedure cercavano di macinare milioni di righe di dati per estrarne una manciata, creare una tabella temporanea e poi macinare di nuovo per estrarre un'altra manciata di informazioni da presentare al contorno e dopo tutto quello, il risultato finale era magari una tabellina con 3 righe.
E come possiamo aspettarci, $sgambetti comincio' a lamentarsi con noi della "inaccettabile lentezza" dell'infrastruttura. Ovviamente, la lentezza era "inaccettabile" ma questo non vuole dire che $sgambetti progettava di andarsene a portare la loro robaccia da altri providers che (secondo $sgambetti) "promettevano prestazioni superiori di svariate grandezze", la mia lettura della cosa e' che magari gli altri provider promettevano, ma dietro pagamento di sostanziali somme di denaro che $sgambetti manco si sognava di pagare.
Ed ovviamente, dato che il mondo gira sempre nello stesso modo. Qualcuno venne "scelto come volontario" per "ottimizzare" la faccenda. E come potete immaginare, tutti quanti sono dei geni indiscussi di tutto lo scibile umano, finche' si tratta di parlare a vanvera e blaterare buzzword in meeting, ma quando si tratta di tirarsi su le maniche ed applicare in pratica tutta quella incredibile "conoscenza", tutti quanti decidono che "i loro progetti sono tutti urgenti ed in ritardo" ma non e' che sono abbastanza urgenti ed in ritardo che decidi di arrivare in ufficio all'ora a cui dovresti arrivare eh?
Onde per cui cio', io mi ritrovo a dover spiegare per la millionesima volta ad un programmatroto (CL) che non ha la piu' pallida idea di cosa sta facendo, che l'idea di usare un database relazionale per immagazzinare informazioni che relazionali non sono e' veramente una pessima idea.
IO - ...quindi la vostra struttura dati e' definitivamente sbagliata per questo tipo di cose.
CL - La struttura dati non l'ho progettata io, era gia' esistente.
IO - E mi sta bene, ma rimane il fatto che sia inadatta allo scopo. E questo e' il motivo per cui l'intero sistema e' cosi' lento.
UL - (che non sa un tubo di database, non capisce un tubo di computers, non conosce la struttura dell'applicazione e non e' chiaro che cosa ci faccia in questa riunione, a parte rompere i marroni) Ma se noi la ottimizzassimo? Quale miglioramento di prestazioni si potrebbe ottenere?
IO - Qui non c'e' niente da ottimizzare, e' come cercare di correre un gran premio di formula uno con un trattore.
CL - Che c'entrano i trattori adesso?
IO - Hanno potenza da vendere ma sono progettati per andare piano. E questo e' il vostro problema. Il vostro database ha potenza da vendere ma e' progettato per fare un lavoro completamente diverso.
UL - Ma se ha potenza da vendere perche' non produce risultati piu' in fretta?
IO - Quale parte di "progettato per andare piano" non era chiara?
CL - E come si potrebbe modificare per farlo andare piu' veloce?
IO - Sostituendolo in toto con qualche cosa d'altro. Dato l'uso che volete fare di questa roba ritengo che qualche cosa come Mongo o Redis sarebbe piu' indicato.
CL - Monche?
IO - No che, go. Mon-go. Mai sentito parlare di database non relazionali?
CL - Non relazionali? Come diavolo fai ad avere un database non relazionale?
IO - Bhe ok, parlare di 'database' e' magari un uso erroneo del termine, ma in assenza di un termine migliore...
UL - E perche' il vostro database non supporta questa "mongocosa"?
IO - Perche' e' il VOSTRO database, non il NOSTRO, noi forniamo la piattaforma, quello che ci fate funzionare sopra sono affari piu' che altro vostri.
CL - Ma mettiamo che noi dobbiamo fare una query che fa una join...
IO - No, non fai una join, quello che fai e' estrarre tutti i dati e poi cercare le corrispondenze da altre parti se vuoi farlo in quel modo.
CL - Ma noi abbiamo tutte le query che...
IO - Non funzionano. Ed il punto e' proprio quello. Con i dati che avete e come volete gestirli non potete fare 'query'. Bisogna cambiare l'approccio.
CL - IMPROPONIBILE! Cambiare l'approccio richiederebbe la riprogettazione di tutto il backend!
IO - Infatti.
UL - E se noi mettessimo il mongo sopra al nostro database?
IO - No, non funziona cosi'.
CL - RIPROGETTARE TUTTO IL BACKEND?? Ci vorrebbero dei mesi!
UL - $altroprovider ci ha assicurato che il loro sistema fornisce prestazioni almeno 4 volte superiori.
IO - Ed allora consiglio che usiate loro, e non vi diro' di fare una prova o avere queste "prestazioni" scritte nel contratto perche' sono sicuro che non sono dei deficienti e quindi nel contratto non ci sara' nessuna misura verificabile.
UL - (intuendo che io preferirei vederli migrare verso alri lidi - al contrario di quello che MarketingMan preferirebbe) ... Ma se invece ci concentrassimo sull'ottimizzare le prestazioni del database? Per esempio, se aggiungessimo della ram?
...No, non imparano o capiscono mai.
Davide
23/09/2019 10:38
