Da quasi un anno ho lavorato in forma personale ad un progetto riguardante la condivisione delle biciclette (Bike Sharing) in particolare nel mio comune di residenza: Udine.
Il progetto ha tracciato (e continua a tracciare) le stazioni delle bici, il conteggio delle bici presenti e gli spazi disponibili.
Il bot Telegram
Oltre a ciò, un bot Telegram @UdineBikeBot accompagna l’utente nella scoperta del Bike-sharing:
- Sessioni di bici tra le stazioni
- Scelta della stazione più vicina in base al GPS
- Consiglio sulla disponibilità della partenza (bici disponibili) e dell’arrivo (posti liberi disponibili)
- Statistiche delle sessioni, velocità, distanza, tempi.
E il gestionale, ovviamente.
Dietro a tutto questo, ho costruito un gestionale per poter veicolare e gestire correttamente tutti i dati. Il gestionale si occupa principalmente di immagazzinare lo storico abbastanza fornito di tutte e 24 le stazioni a Udine.
L’unica pecca è che lo storico l’ho salvato in una modalità abbastanza inefficiente per l’accesso rapido siccome viene archiviato in un formato speciale di Symfony-Doctrine chiamato “array” (link per i più curiosi).
Inefficienza e conversione dei dati verso InfluxDB
L’errore, scoperto dopo mesi e dopo aver iniziato a esaminare tali dati si traduce nella seguente complicazione:
L’idea di salvare lo storico ogni 10 minuti sotto forma di un array (formato da tutte le stazioni e le misurazioni) era ben pensato per Symfony ma non per usi “terzi”. Infatti sarebbe una pazzia pensare di poter demandare il duro lavoro di analisi a MySQL con tutte le stupende schematizzazioni da 30L in Base Dati all’Università. Tali ottimizzazioni avrebbero rallentato l’accesso e le scritture.
Inoltre il contenuto di ogni array conteneva un numero di informazioni imbarazzante di ridondanza tale da portare il peso della tabella a ~1,2 GB.
Quindi MySQL non è la soluzione e men che meno l'”array” di Doctrine.
Mi sono affidato a InfluxData e il suo prodotto InfluxDB (https://www.influxdata.com/products/influxdb-overview/). Si tratta di software di database pensato per dati storici influenzati da alte richieste di lettura e scrittura.
Dopo aver implementato tramite Command su Symfony, il trasferimento si è dimostrato indolore e piuttosto rapido se dobbiamo mettere in conto che ho convertito e trasferito le informazioni di tutte le stazioni ogni 10 minuti per la durata di quasi un anno.
Integrazione con Grafana
L’esperimento con InfluxDB ha funzionato e ho deciso di costruirmi alcune dashboard con Grafana.
In seguito ho notato la necessità di costruire grafici in modo che potessi osservare le bici disponibili in una frazione temporale in contemporanea con la disponibilità massima della stazione interessata. Tale confronto mi è utile in quanto capita alle volte che la stazione subisca malfunzionamenti e quindi la diminuzione delle bici non deve essere calcolata come un utilizzo da parte di un utente.
Nell’immagine è possibile notare in verde le bici effettivamente disponibili e in giallo la disponibilità massima che la stazione ha in quel preciso istante.
È possibile quindi dedurre che le righe verticali gialle (che raggiungono y=0) significano un completo malfunzionamento della stazione.
Ad esempio, nell’immagine sopra Caccia ha subìto 4 malfunzionamenti totali mentre Ospedale è in perfette condizioni.
Per quanto riguarda il verde, Stazione ha un alto utilizzo nella settimana Lun-Ven e il fine settimana è statico. Magrini e Diacono sembra rimangono quasi costantamente a secco di bici disponibili.
Statistiche delle ultime 24 ore
Se vi è piaciuto l’esperimento e volete saperne di più, nella pagina Bike Sharing 24h trovate le statistiche delle bici a Udine nelle ultime 24 ore. Clicca qui per vedere.
