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!