<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=1267344923293614&amp;ev=PageView&amp;noscript=1">

Blog

InfluxDB vs ElasticSearch: cosa scegliere per la Time Series Analysis?

Davide Avella

Davide Avella, 30 aprile 2020 | Time Series Database InfluxDB

Ore 18.01. Squilla il telefono. Un problema sul cluster: un aumento vertiginoso del consumo della RAM. Ma all’help desk nessuno si scompone. Anzi ne erano già al corrente. Qualche minuto prima dello squillo il chatbot aveva già notificato il superamento della soglia di normale attività, mentre un’ora prima un nutrito gruppo di persone si era già riunito davanti allo schermo: era già da qualche minuto che la linea viola del consumo della RAM aveva superato il fatidico 90%, mentre le macchine virtuali erano passate da dieci a venti in pochi minuti. All’help desk non avevano dubbi. Qualcuno si era intrufolato nel cluster e istanziato un gran numero di macchine per testare algoritmi di reti neurali. A spese dell’azienda. Se fossero intervenuti anche con pochi minuti di ritardo, il danno sarebbe potuto essere molto più ingente.

Clicca qui per scaricare la guida ai Time Series Database!

Time Series: dati, analisi e database

Nella vita di tutti il tempo rappresenta una costante, ma nella situazione precedente diventa variabile decisiva. Pochi minuti possono fare la differenza. Sono proprio queste necessità ad aver portato alla diffusione delle cosiddette time series analysis, analisi che hanno nel tempo la dimensione principe: un punto segnato ad un determinato tempo si unisce ad un altro registrato al tempo successivo che, a sua volta, si collega al prossimo e così via.

Questi punti possono essere ad intervalli più o meni regolari: dipende dalla frequenza del campionamento. Un sensore, ad esempio, può campionare anche con regolarità al di sotto del secondo. Più è elevata la frequenza, più si può essere precisi nell’analizzare i dati e intervenire al momento giusto. Al contempo un campionamento più fitto può portare con sé molteplici problemi: una gran mole di dati da immagazzinare, una velocità di scrittura più elevata, un numero di richieste elevato da sostenere, la necessità di interrogare ed aggregare grandi quantità di dati velocemente, etc.

A questi tipi di problematiche hanno provato a dare una risposta due database molto usati nell’ambito delle time series: InfluxDB e ElasticSearch.

InfluxDB

InfluxDB è un database progettato e ottimizzato per archiviare serie temporali. Questo processo si basa sulla frammentazione dei dati in blocchi con algoritmi specifici a partire dalle esigenze di memorizzazione. Tutto questo, però, non appare agli occhi dell’utente finale, né ne intacca l’usabilità. Infatti le serie temporali possono essere organizzate logicamente in database come su qualsiasi relazionale e l’interrogazione dei dati è affidata ad una versione molto simile allo standard SQL. Inoltre InfluxDB mette a disposizione una serie di funzioni tipiche delle time series: derivata, somma cumulata, media mobile semplice, media mobile esponenziale, etc. Infine la scrittura dei dati può avvenire in due modi: l’interfaccia da riga di comando o API Rest. Entrambi consentono a qualsiasi linguaggio o applicativo di interagirci in lettura o scrittura.

ElasticSearch

Pubblicato la prima volta nel 2010, ElasticSearch ha guadagnato popolarità come motore di ricerca. Costruito intorno al più popolare dei sistemi di indicizzazione, Apache Lucene, si è affermato per la capacità di effettuare ricerche full-text e la grande capacità di scalare orizzontalmente.
Alla base del processo di indicizzazione di Elastic vi sono gli indici, che possono essere paragonati, almeno dal punto di vista logico, ai database nell’ambito relazionale. Gli indici sono divisi poi in frammenti, chiamati shard, distribuiti su tutte le macchine facenti parti del cluster. La grande capacità di distribuire gli shard e ottimizzarne lo spazio occupato, consente ad ElasticSearch di eccellere nel ridimensionamento orizzontale, nella distribuzione e parallelizzazione dei dati.

L’indice invertito, invece, è proprio delle ricerche full-text, altra peculiarità del database. Per indice invertito si intende una mappa: da un lato ci sono tutti i termini immagazzinati, dall’altra i documenti in cui questi si trovano. Questo consente all’interrogazione di essere di gran lunga più performante. E’ la logica alla base di tutti i motori di ricerca, anche di Google. Come per InfluxDB, anche ElasticSearch fornisce un API REST per l’interrogazione e la manipolazione dei dati
Sulla base di queste prime considerazioni ElasticSearch non sembrerebbe adatto a immagazzinare time series. Ma grazie alla sua velocità di memorizzazione, la scalabilità e la resilienza si è guadagnato spazio per i progetti in cui il real - time è diventato un must.

Il confronto e oltre

Quindi da un lato un database ottimizzato per le serie temporali, dall’altro un motore di ricerca costruito per immagazzinare grandi quantità di dati e scalabile di default. Fare una scelta non è facile. Entrambi gli strumenti presentano pro e contro sulla base dello scenario che ci si trova di fronte.

Un sensore può avere, come si è detto, anche una capacità di campionamento nell’ordine di grandezza del millisecondo. In tal caso ci si troverebbe a gestire in poco tempo una grande quantità di dati: un dato ogni 10 millisecondi equivale in un minuto a 6000 dati, 360000 in un ora, 8640000 in un solo giorno. Si scrive dato ma si legge numero: si parla di watt oppure metri oppure click, etc.
In una situazione del genere InfluxDB è lo strumento ideale: si riesce a gestire un gran numero di scritture, lo spazio disco occupato è ottimizzato a fronte della mole di dati e il tempo delle interrogazioni è ridotto all’osso. E tutto questo senza configurazioni specifiche. Inoltre la veste simil SQL semplifica la vita a qualsiasi analista: query semplici da strutturare e facili da articolare di fronte a necessità anche particolarmente complesse.

Al contrario ElasticSearch renderebbe le cose più complicate: il processo di indicizzazione è, per sua natura, più lento e richiederebbe un processo di tuning iniziale per ottimizzare le query su tutti quei dati numerici. Certo si disporrebbe di un cluster che consente di scalare a secondo delle necessità, cosa che con InfluxDB è disponibile solo sotto licenza enterprise, query di gran lunga più lente e più complesse da compilare fanno pendere l’ago della bilancia dalla parte di InfluxDB.

Con quanta frequenza è aggiornato un file di log? Spesso non ci si fa caso ma applicativi complessi possono scrivere righe di log al ritmo di pochi secondi. Le scritture sono decisamente complesse, con un gran numero di informazioni: cosa è successo, quando, dove e soprattutto perché. I file di log contengono una grande quantità di dati molto utili soprattutto in fase di troubleshooting: è successo qualcosa e si deve capire come e perchè. Si scrive dati ma si legge testo perchè di dati testuali, non strutturati, che si sta parlando. In un contesto simile ElasticSearh è il partner migliore. La sua natura di motore di ricerca consente la memorizzazione di tutte le informazioni senza dover effettuare una cernita in ingresso, mentre le query full-text permettono di individuare termini specifici tenendo conto del contesto.

La scalabilità garantisce resilienza e il framework di aggregazione dà la possibilità agli analisti di navigare le serie temporale a proprio piacimento, individuando anche correlazioni inaspettate. InfluxDB, al contrario, non riuscirebbe a gestire da solo un caso d’uso come questo. L’ottimizzazione è limitata ai dati numerici, tralasciando i dati testuali. Pertanto si dovrebbe ricorrere ad un altro strumento in parallelo con tutte le difficoltà di sincronizzazione fra i due sistemi che ne conseguono.

Leggi anche: Time Series Database per grandi volumi di dati: intervista con InfluxDB

Conclusioni

I due esempi riportati descrivono come la scelta migliore in sé non è la risposta alla domanda iniziale: cosa scegliere per la Time Series Analysis. Le serie temporali sono tipologie di dati che si riscontrano in tantissimi contesti e costituiscono un modello interpretativo anche a circostanze che, all’apparenza, sembrano avere poco a che fare con analisi temporali. Basta contrarre o dilatare l’asse temporale e ci si ritrova in un altro ambito, completamente diverso. Alle ore 18.05 sulla scrivania è già pronto il report: nell’ultimo trimestre questo è il terzo attacco hacker, di cui due nelle ultime due settimane, sempre nel medesimo orario. Il capo dovrà prendere delle decisioni in merito.

Quello dei Time Series Database è un mondo nuovo quanto complesso, approfondisci subito l'argomento: clicca sul pulsante qui sotto!

Extra Red Time Series Database

Lascia un commento