Cosa è InfluxDB #
InfluxDB, in breve, è un DBMS non relazionale ottimizzato per gestire time-series, ovvero gruppi di dati strettamente dipendenti dal tempo (come potrebbero esserlo, ad esempio, lo storico delle misure acquisite da un sensore nel corso di una giornata).
Cosa sono le Retention Policies #
Il problema principale delle time-series è che, con il passare del tempo, i dati acquisiti tendono ad accumularsi in volumi enormi. Proprio per contenere questo problema, gli sviluppatori di InfluxDB, hanno implementato diversi meccanismi che permettono di ridurre il numero di dati da mantenere.
Uno dei metodi che InfluxDB implementa per la gestione dei dati è proprio quello delle Retention Policy.
Una Retention Policy è una struttura dati di InfluxDB che definisce per quanto tempo i dati devono essere mantenuti all'interno del database. Di fatto è come se ad ogni dato memorizzato venisse applicata un'etichetta con riportata la data di scadenza. Internamente InfluxDB si occupa di eliminare i dati la cui data di scadenza è passata senza che lo sviluppatore debba occuparsene in prima persona. L'azione di eliminazione dei dati scaduti dal database è chiamata retention policy enforcement.
Ad ogni retention policy possono essere associati uno o più Shard Groups. Al fine di ottimizzare le prestazioni, InfluxDB frammenta i dati delle varie time-series in più file chiamati Shard. Gli shard sono a loro volta organizzati all'interno di uno Shard Group.
Nel momento in cui viene definita una retention policy è necessario definire anche la shard group duration. Questo valore (espresso in giorni) indica la quantità di dati che devono essere contenuti all'interno di ogni shard. Ad esempio, la durata di default degli shard è di 7 giorni. Di conseguenza verrà creato un nuovo shard con i dati raccolti in ogni settimana.
InfluxDB crea automaticamente alla creazione del database una retention policy chiamata autogen. Questa policy ha una shard group duration di 7 giorni e non definisce una scadenza per i dati.
Per vedere le policies create all'interno del database puoi utilizzare il seguente comando all'interno della influx-cli:
SHOW RETENTION POLICIES
Il mio problema delle query lente #
A cosa è servito tutta questo sproloquio sul funzionamento interno di InfluxDB? Il problema della retention policy predefinita è che produce circa 52 shards per ogni anno di dati. E, poiché all'aumentare del numero di shards aumenta il numero di file che devono essere analizzati, quando vengono eseguite query su lunghi intervalli temporali il tempo necessario ad eseguire la ricerca aumenta considerevolmente.
Una soluzione a questo problema è creare una nuova retention policy in modo da impostare una shard group duration tale che il numero di shard creati sia minore. In questo esempio andrò a creare una nuova retention policy con una durata di 2 mesi. Per creare una nuova retention policy chiamata two_months è sufficiente digitare nella CLI:
CREATE RETENTION POLICY two\_months ON db DURATION 8w REPLICATION 1
A questo punto è possibile assegnare la policy appena creata ad una nuova measurement tramite il seguente comando:
INSERT INTO two_months sensors,type=temperature value=24
Come fare la migrazione dei dati esistenti #
Tramite InfluxDB è possibile creare o modificare una retention policy in ogni momento ma i cambiamenti verranno applicati solo ai dati inseriti successivamente alla modifica.
Nel caso in cui si voglia spostare dei dati già esistenti da una retention policy ad un'altra non è prevista una tecnica ufficiale di migrazione. Tuttavia è possibile aggirare il problema sfruttando un database temporaneo su cui creare la nuova policy per poi copiarci i dati esistenti.
Il primo passo che devi fare è quindi creare il database temporaneo tramite il comando della CLI:
CREATE DATABASE temp_dbAll'interno di questo database temporaneo dovrai creare la retention policy che vuoi utilizzare per i dati. Ad esempio tramite il comando:
CREATE RETENTION POLICY two_months ON temp_db DURATION 8w REPLICATION 1
A questo punto devi copiare tutti i dati dalla measurement esistente nel vecchio database (chiamato old_db) al nuovo database, specificando l'utilizzo della nuova policy:
SELECT * INTO "temp_db"."two_months"."sensors" FROM "old_db"."autogen"."sensors" GROUP BY \*;
Quando il comando avrà finito di copiare i dati, questi saranno organizzati secondo le regole definite nella nuova retention policy.
A questo punto, se necessario, puoi importare i dati di nuovo all'interno del vecchio database. Per prima cosa devi cancellare la measurement esistente, creare la nuova policy all'interno del database ed infine ti basta effettuare la copia dei dati a partire dal database temporaneo modificando sorgente e destinazione del comando riportato sopra.
Conclusioni #
Visto che InfluxDB è un progetto ancora giovane la mancanza di un meccanismo per la migrazione dei dati integrato all'interno del DBMS può essere perdonata. Se però anche a te è capitato di iniziare a lavorare con il database sfruttando la retention policy predefinita per poi accorgerti delle limitazioni spero che questo breve tutorial ti sia di aiuto. Come hai potuto leggere si tratta di pochi semplici passi che però non sono riportati all'interno della documentazione ufficiale del progetto.
Se questo post ti è stato utile puoi farmelo sapere scrivendomi direttamente su Telegram. Inoltre ti invito ad iscriverti al mio canale Telegram e a seguirmi su Twitter per non perderti nemmeno un post del mio blog. A presto!