Pagine

3 febbraio 2012

Torna online l'applicazione della contaminazione alimentare, ma...

Chi ci segue più da vicino ed è un utilizzatore della nostra applicazione web per monitorare i risultati della contaminazione alimentare in Giappone, si sarà accorto che da alcuni giorni, anziché l'applicazione compare un cartello di lavoro in corso. Questa temporanea sospensione del servizio si è resa necessaria a causa di un problema che abbiamo riscontrato con Fusion Tables (il servizio di database di Google) e che forse abbiamo capito come risolvere.

Il problema

Il problema è che abbiamo raggiunto il limite. Fusion Tables permette ai suoi utenti di caricare tabelle purché non superino i 250 mega byte totali di spazio utilizzato. I dati inseriti fino ad adesso, cento e rotti mila alimenti, occupano all'incirca 20 megabyte, quindi nelle nostre previsioni i 250 mega disponibili ci sono sembrati sufficienti per imbarcarci nell'impresa.

Questo limite dei 250 mega è messo ben in evidenza sulle pagine di FT, ce se ne sono anche altri, non così evidenti e non altrettanto semplici da interpretare. C'è il limite dei 500 punti per ogni riquadro della mappa. Quando visualizzate una mappa di Google, questa è composta da tanti riquadri (in inglese tile) e quando lo zoom è basso (caso estremo sto guardando tutto il mondo) allora l'area geografica coperta da un riquadro potrebbe essere molto vasta. Al contrario quando lo zoom è molto alto (sto guardando solo un quartiere) allora ogni tile copre pochi chilometri quadrati di superficie. Su ciascun riquadro il numero massimo di punti visualizzabili è, appunto, 500. Questo significa che ingrandendo l'immagine vedremo un numero maggiore di punti proprio a causa di questo limite. Una volta che sai di questo limite, la cosa resta accettabile perché tanto più di 500 punti sono difficili da visualizzare e viene spontaneo fare uno zoom per meglio capire e vedere.

C´è un altro limite, quello dei 100mila. Quando uno tabella supera le 100 mila righe, allora non verranno utilizzate per la rappresentazione grafica nessun record oltre il centomillesimo. Noi aggiungiamo dati ogni giorno e abbiamo superato il limite dei 100mila proprio lo scorso 27 gennaio con il risultato che nessun punto dopo tale data veniva visualizzato sulla mappa. Per ovviare al limite dei 100mila, si può richiedere  una licenza professional che a differenza di quella che utilizziamo noi al momento si paga. Siamo andati a vedere i prezzi e siamo rimasti stupiti nel vedere che il prezzo base è 10mila dollari all'anno. Ci perdoneranno i nostri lettori se non affrontiamo questo investimento.

Le alternative

Ovviamente non siamo stati con le mani in mano e abbiamo valutato un certo numero di soluzioni alternative a quelle di aprire un mutuo per avere una licenza professionale. Ve le elenchiamo di seguito a mo' di proposte anche per chiedere un vostro consiglio su quale preferite.


  1. Reset annuale. Questa è la soluzione temporanea che abbiamo adottato al momento. Abbiamo semplicemente importato in un'altra tabella FT i dati dall'inizio dell'anno ad oggi e abbiamo modificato l'applicazione in modo che non si possano chiedere dati prima di tale data. E' la cosidetta soluzione del poveretto, perché al momento funziona, ma certo non può essere considerata definitiva. 
  2. Una tavola per ogni 100mila records. Questa è la normale evoluzione della soluzione numero 1. Visto che la tabella del 2011 è ancora online e ci guardiamo bene dal toglierla! Allora possiamo immaginare che quando l'utente vuole esplorare dati vecchi, l'applicazione in modo trasparente si faccia carico di interrogare la tabella giusta - o le tabelle giuste se l'indagine riguarda periodi di tempo su più anni - e di mostrare i risultati su layer differenti (massimo 4!) sopra la mappa. Richiede una piccola rivoluzione al nostro codice, specialmente per quanto riguarda la parte dei grafici, ma è possibile.
  3. La finestra mobile. Un'alternativa potrebbe essere quella di mantenere nella tavola associata alla webapp sempre un numero di record inferiore a 100mila. In pratica ogni giorno aggiungiamo un nuovo rapporto e togliamo dall'inizio della tabella un numero di record equivalenti. In questo modo l'applicazione sarebbe sempre in grado di esplorare almeno i sei mesi antecedenti la data odierna. Ovviamente tutti i dati rimossi dalla tavola con finestra mobile sarebbero backuppati, in modo che nessun dato venga perso. E' un buon compromesso tra la soluzione 1 e la 2, richiede una grossa modifica del codice dell'applicazione, non tanto nel front-end (ovvero quello che vedete voi), ma nel back-end ovvero nel modo in cui aggiungiamo i nuovi dati. Temiamo che il nostro servizio di hosting gratuito su 000webhost che funziona alla grande per le cose in piccolo, possa essere troppo limitato in questa situazione.
  4. Abbandonare Fusion Tables. Il grosso vantaggio di FT rispetto ad un nostro database tipo MySQL è che si integra automaticamente con Google Maps per avere i puntini sulla mappa e anche con Google Chart Tools per avere i grafici. Possiamo metterci e riscrivere tutto da noi, non sarebbe un problema irrisolvibile, ma temiamo di non avere le risorse necessarie. Anziché inviare le query alla FT, dovremmo processarle noi sul nostro DB e generare un output KML da inviare alle mappe. Per i grafici dovremmo codificare una Datasource custom. Potrebbe essere una buona occasione per provare le Applicazioni Google su appspot però è decisamente una soluzione a lunghissimo termine. Non avremmo più i limiti di FT, ma verosimilmente ne avremo di altri che al momento sono un po' difficili da valutare. 
Le vostre opinioni

Al momento trovate on line la soluzione numero 1 e speriamo di riuscire presto a fare l'upgrade alla numero 2. Nel frattempo però restiamo in attesa delle vostre opinioni, ci sono molti tecnici / informatici che ci seguono, quindi siamo apertissimi ai vostri suggerimenti e non solo su come uscire da questo impasse, ma anche su come migliorare e rendere più fruibile l'intera applicazione. Visto che dobbiamo fare qualche modifica conviene farla per il meglio!  



Chiunque può lasciare commenti su questo blog, ammesso che vengano rispettate due regole fondamentali: la buona educazione e il rispetto per gli altri.

Per commentare potete utilizzare diversi modi di autenticazione, da Google a Facebook e Twitter se non volete farvi un account su Disqus che resta sempre la nostra scelta consigliata.

Potete utilizzare tag HTML <b>, <i> e <a> per mettere in grassetto, in corsivo il testo ed inserire link ipertestuali come spiegato in questo tutorial. Per aggiungere un'immagine potete trascinarla dal vostro pc sopra lo spazio commenti.

A questo indirizzo trovate indicazioni su come ricevere notifiche via email sui nuovi commenti pubblicati.

9 commenti:

  1. Mi prometto di rileggere con calma il tutto, perchè da una prima lettura mi puo' essere sfuggito qualcosa.

    Va inoltre detto che non sapendo esattamente come funziona il software, e non avendolo mai neppure usato, non ho capito proprio tutto...

    Procedo comunque a sparare tutto cio' che mi passa per la mente, nella speranza che vi possa quando meno accedere una lampadina a voi, che avete un quadro piu' preciso del tutto.

    In ogni caso, il limite principale, che attualmente vi sta mettendo in crisi pare essere quello dei 100.000 record massimi per tabella esatto?

    La soluzione principale puo' essere quella da voi adottata first in first out FIFO (http://it.wikipedia.org/wiki/FIFO)


    In alternativa, su due piedi mi verrebbe  da consigliarvi la suddivisione della tabella per area geografica....

    fate X tabelle, una per ogni zona...

    Se tanto a livello nazionale, non si possono visualizzare tutti i punti, tanto vale non mostrarli a livello nazionale, ma solo a livello locale...

    A livello nazionale, si potrebbero mostrare dei conteggi statistici,  calcolati sulle varie tabelle delle singole regioni.

    RispondiElimina
  2. A parte la suddivisione della tabella grande in tante tabelle piccole, e l'adozione di tabelle di "statistiche" contenenti conteggi già fatti, non mi viene altro in mente.

    Per quanto riguarda la creazione di un sito da zero, non è così complessa come cosa... il KML non va generato, si possono posizionare direttamente i punti su mappa.

    Il probelma è l'hosting... lo spazio in mysql costa, le capacità di calcolo pure... 

    Su aruba tanto per fare un esempio, mi pare che costi 7 € ogni 100 MB... Non ci sono limiti al numero di record, pero' va considerato che su un hosting di questo tipo le capacità di calcolo sono ridotte. 

    Determinate query possono essere pesanti da eseguire (lente...), soprattutto se eseguite su tabelle con centinaia di migliaia di record. Dipende anche molto dal tipo di query. Es. Cercare i 100 punti nel raggio di 10 KM dal punto indicato su una tebella con 200.000 record inizia ad essere anche lato computazione abbastanza impegnativo per questi hosting condivisi. Se invece la ricerca non è per coordinata, ma è per testo, o meglio ancora numero, se il campo è indicizzato non ci sono grandi problemi.

    Il punto cruciale è sempre il solito... IL BUDGET. A budget 0, state già usando credo, cio' che di meglio è disponibile....


    Non vorrei che le risorse di computazione necessarie per le vostre elaborazioni (che non conosco), possano richiedervi un investimento economico che va al di la' del vostro budget.

    RispondiElimina
  3. L'idea di ripartire per prefetture è un'alternativa interessante... che ne dici toto ? Temo solo che per alcune prefetture raggiungeremo comunque il limite, anche se Fukushima, Ibaraki e Miyagi viaggiano per ora intorno ai 10 000 record.
    Nota che la FIFO coincide praticamente con la soluzione 3 ;-)

    RispondiElimina
  4. Ci siamo sovrapposti con la risposta. La suddivisione geografica potrebbe funzionare, ma come ho scritto sopra possiamo sovrapporre solo 5 (in pratica 4) layer. E' da valutare...

    RispondiElimina
  5. la suddivisione geografica la puoi fare senza sovrapporre...

    Se l'utente seleziona la nazione, gli mostri un determinato tipo di contenuto. Per i dettagli si deve per forza indicare una prefettura...


    Con la API di google puoi fare georeferenziare il punto al client, senza alcun limite. E' ovvio che se hai già la coordinata la piazzi. Ma se non l'avessi, puoi mettre l'indirizzo ed ogni client se lo fa georeferenziare da google.


    Se comunque le query non sono per coordinata, quindi senza calcoli trigonometrici, la cosa risulta molto piu' leggera lato server. Non dovresti avere grossi problemi di calcolo.


    Ti ripeto, posso ancora parlare a vanvera, perchè non sono dentro la sitauzione... sto cercando di lanciare delle idee che vi accendano qualche lampadina... poi magari sono idee inutili...

    RispondiElimina
  6. Infatti è come l'avevo capita io!

    RispondiElimina
  7. Ottimo, tu butta idee... anche da quelle a "vanvera" si può sempre capire qualcosa.

    Ah bello, questa modalità di suddivisione geografica mi era sfuggita. In pratica a livello nazionale metto quella con i retini e basta, niente punti. Quando uno seleziona la prefettura allora metto il viewport giusto e vado a fare la query sulla tavola giusta. Se Fukushima è adesso a 10mila records allora potremmo arrivare a 100mila in qualche anno... Fattibile. 
    Sarebbero un po' più complessi i grafici che nel caso del nazionale devo fare il merge dei risultati. Ma possibile. 

    Il geocoding preferisco farlo io e fissare le coordinate nel db. Non tanto per il limite che p´è a livello client, ma per gli errori di geocoding. I primi tempi facevamo fare il geocoding all'applicazione e ci ritrovavamo punti in Cina e alle Filippine. E poi ci sono le località miste. Ci sono tanti alimenti la cui provenienza è indicata come da molte località, tipo Como, Varese e Milano. Se chiedo a Google di farmi il geocoding di Como, Varese, Milano - Italia quello che ritorna è sicuramente sbagliato e non per colpa sua. Per questo mi sono scritto un geocoder a mano che in tal caso mi fa il baricentro dei singoli luoghi e mi da le coordinate di quel punto. 

    RispondiElimina
  8. Scusa il ritardo nella risposta.
    Per i grafici ti posso sufggerire questo:

    anzichè conteggiare tutte le volte i dati, potresti fare delle tabelle in cui sono già stati contati i dati.

    Cioè, ti faccio un esempio.

    Per calcolare il fatturato annuale, potrei andare tutte le volte a contare la somma di tutti i totali delle fatture.

    Così facendo pero' con 10.000 fatture il calcolo diventa pesante.

    Visto che il fatturato fino a ieri ormai è consolidato, posso archiviare il una tabella i totali per giorno...

    In questo modo anzichè sommare i totali di 10.000 fatture sommo al massimo i totali di  365 giorni...

    In pratica consolidi una parte di dati in una tabella "statistica" che ti semplifichi il lavoro...

    RispondiElimina
  9. E' una buona idea... per come è strutturata adesso l'applicazione uno potrebbe volere vedere il fatturato da un giorno qualunque ad un altro giorno qualunque. Il consolodamento del db lo fa google e in genere non è particolarmente lento nel rispondere. Però posso tenere a mente per l'evoluzione... in cui i dati vecchi sono già consolidamenti, mentre quelli nuovi sono liberi!

    Bravo, grazie.

    RispondiElimina

Chiunque può lasciare commenti su questo blog, ammesso che vengano rispettate due regole fondamentali: la buona educazione e il rispetto per gli altri.

Per commentare potete utilizzare diversi modi di autenticazione, da Google a Facebook e Twitter se non volete farvi un account su Disqus che resta sempre la nostra scelta consigliata.

Potete utilizzare tag HTML <b>, <i> e <a> per mettere in grassetto, in corsivo il testo ed inserire link ipertestuali come spiegato in questo tutorial. Per aggiungere un'immagine potete trascinarla dal vostro pc sopra lo spazio commenti.

A questo indirizzo trovate indicazioni su come ricevere notifiche via email sui nuovi commenti pubblicati.