Storie dalla Sala Macchine


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


One Size...

Siamo di nuovo a parlare delle peripezie webbistiche di J. La web-programmatrice di cui avevo gia' detto qui, qui e per finire (speravo io) qui.

Questa volta la volpe (o la gatta?) si e' cimentata in una fetecchia di web-applicazione che dovrebbe presentare una serie di informazioni relative ai dati di vendita di una serie di negozi per scopi statistici.

Tutto bello, se non che:

  1. Ha selezionato un ben noto database con la scusa che "e' semplice da usare"
  2. Ha deciso che le informazioni nel database arrivano da un "export" dei dati usati da una applicazione contabile.
  3. Ha deciso che la sua applicazione deve essere "database-independent"

E qui gia' abbiamo una serie di problemi. In primo luogo, il famoso database sara' anche facile da usare ma quando gli scarichi sopra un paio di milioni di records entra in coma.

In secondo luogo, le informazioni che lei dovrebbe presentare sono totalmente diverse da quelle che si trovano nel database di origine.

Per ovviare al secondo problema ha deciso che la cosa migliore e' di mettere tutta la logica di ri-analisi dei dati nel front-end.

Arriviamo quindi al succo del problema: la famosa applicazione e' stata consegnata ed il cliente (che guardacaso e' anche cliente nostro) e' rimasto traumatizzato dalla lentezza abominevole della cosa. Dato che J non sa che pesci pigliare (non fate battute sui "pesci") siamo stati chiamati in causa noialtri.

Io ho dato un'occhiata alla cosa ed ho notato che:

  1. la procedura di importazione dei dati ci impiega 3 ore per svolgere il suo lavoro e funziona nottetempo, quando i negozi sono chiusi
  2. i dati di origine sono tanti, nell'ordine di milioni di records al giorno.
  3. quando il front-end e' chiamato in causa il carico della macchina schizza a 70
  4. il tempo medio di elaborazione e' di circa 8 minuti

Una volta visto cio', ho riportato le mie impressioni, che si possono riassumere in: dato che il problema e' la lentezza del front-end, facciamo fare la pre- elaborazione dei dati durante l'importazione (nottetempo) e togliamo la logica dal front-end. Anche se ci mette 8 ore lo fa di notte ed i dati sono pronti per essere presentati a richiesta.

Ovviamente la cosa non e' garbata molto, e ne e' scaturita la seguente discussione.

J - Se cambiamo la funzione di importazione l'applicativo diventa legato al database!
IO - E chi se ne frega? Tanto e' un applicativo fatto appositamente per uno scopo specifico.
J - Ma la regola e' di tenersi indipendenti dal database!
IO - Se ti interessa portare l'applicazione su una piattaforma diversa si'. Ma in questo caso a nessuno interessa fare una roba simile.
J - E se un domani decidessero di cambiare il database?
IO - In tal caso ci sara' probabilmente da rifare l'applicazione o adattare la funzione di importazione. Ma dovrai farlo comunque dato che l'applicazione attuale e' scritta per una struttura di database specifica.
J - Ma la logica dell'applicazione dovrebbe essere nell'applicazione e non nel database!
IO - Guarda, la logica puoi metterla in vari posti, dato che nell'utente non ci entra (purtroppo), la puoi mettere nell'applicazione o la puoi mettere nel database. Al momento e' nell'applicazione ed i risultati sono pessimi. Che ne dici di metterla nel database e vedere che succede?
J - Ma quando ho fatto le prove sul mio laptop funzionava tutto perfettamente, ci metteva un niente a visualizzare i dati.
IO - Con quanti dati hai fatto le prove?
J - Tanti.
IO - Tanti quanti?
J - Un paio di centinaia...

Ecco la differenza tra il fare delle prove e fare delle prove con dati reali o quantomeno realistici.

IO - Ottimo, e adesso che abbiamo un paio di milioni di records nel database ci rendiamo conto che con un volume di dati "normali" il sistema non regge. Quindi perche' non pensi a rielaborare quei dati in modo diverso?

Come al solito, quando si cerca di fare le cose con il principio di "one size fit all", si finisce con lo scoprire che "one size fit one". E qualche cosa mi dice che J non seguira' il mio consiglio.

Davide
01/03/2010 08:00

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.

11 messaggi this document does not accept new posts

Fearandil

Niente pesci.... Di Fearandil postato il 01/03/2010 08:30

Ok, niente doppi sensi sui pesci, ma sul 'Guarda, la logica puoi metterla in vari posti' si può fare facile ironia? -- Fearandil

Anonymous coward

Jack Di Anonymous coward postato il 01/03/2010 09:21

L'applicazione su cui sto lavorando io in una azienda di retail, ha quasi gli stessi problemi. A detta del programmatore è velocissimo... peccato che le prove siano state fatte con un negozio e 2 utenti, in realtà deve girare per 200 negozi e 100 utenti! Semplicemente Fantastico!
Ciao! -- Anonymous coward

Fame

The real world Di Fame postato il 01/03/2010 09:59

A me è capitato di scrivere una query per correggere una tabella del DB (23mila): sul mio laptop fetecchia girava in 40s ma quando l'ho fatta girare sul server di $comune_veneto_leghista ha impiegato circa 8 ore. E io le prove le avevo fatte sugli stessi identici dati.
Morale: sai bene che J. chiederà (e otterrà) un macchina più grossa per l'applicazione.
...e poi ci dicono che le dimensioni non contano! :-\) -- --

Anonymous coward

@ Fame Di Anonymous coward postato il 01/03/2010 23:31

Un altro classico errore è di provare l'applicazione con un (1) utente e vedere che è una scheggia. Poi quando va in produzione con un numero di utenti > 1 accorgersi che le cose non sono poi così rosee, fra problemi di concorrenza, scalabilità, ecc. ecc. -- Anonymous coward

Mikycol

Ma... Di Mikycol postato il 01/03/2010 10:40

L'azienda per cui faccio il consulente ogni tanto, ha scritto una fantomatica webapplication, per la gestione frontend e backend per i corsi regionali di una simpatica regione, e hanno fatto i test con ben 16 utenti online, non vi dico cosa è successo quando l'hanno messa online.... -- Mikycol

Zaku

Un paio di perplessità... Di Zaku postato il 01/03/2010 11:20

Non capisco benissimo una cosa... faceva delle query sull'applicativo per presentare i dati in un certo modo? Bisognava fare della Business Intelligence su dati realazionali? Perché continuava a dire che l'applicativo doveva essere indipendente dal db? Se i dati l'avesse lavorati la procedura che li importava, se combiava il db al massimo cambiava la procedura di importazione, non l'applicativo.
Non era meglio orientarsi su OLAP a quel punto? Ci sono anche delle soluzioni free.

Salutoni! -- Zaku

Davide Bianchi

@ Zaku Di Davide Bianchi postato il 01/03/2010 11:25

> Non capisco benissimo una cosa... faceva delle query sull'applicativo per presentare i dati in un certo modo? Bisognava fare della Business Intelligence su dati realazionali? Perché continuava a dire che l'applicativo doveva essere indipendente dal db?

Si, si, perche' e' scema.
-- Davide Bianchi

Claiudio claiudio@libero.it

Avrà capito la lezione precedente ? Di Claiudio claiudio@libero.it postato il 01/03/2010 15:21

Nelle precedenti storie, la programmatrice in questione alla fine aveva capito che non doveva usare javascript per la verifica dei dati ?
Chiedo questo per intuire se in questa occasione ha prontamente cambiato idee sulla gestione del database oppure no. -- Claiudio claiudio@libero.it

Davide Bianchi

@ Claiudio claiudio@libero.it Di Davide Bianchi postato il 01/03/2010 15:23

> Nelle precedenti storie, la programmatrice in questione alla fine aveva capito che non doveva usare javascript per la verifica dei dati ?

...secondo te?
-- Davide Bianchi

Nicola

davvero...no non è possibile Di Nicola postato il 01/03/2010 17:48

Mi auguro che...non abbia usato il Javascript pure ora.... -- "Le opinioni, si sà, sono come i coglioni... Ognuno ha i suoi" (Giorgio Gaber)

Alex

Beh... Di Alex postato il 18/03/2010 10:05

Ma anche voi... far fare delle operazioni di ETL e OLAP su quantità di dati non indifferenti ad un(a) web-developer. E' un po' come cercarsela.
-- Alex

11 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