Rabbia, contrattazione e depressione quando si lavora con InfluxDB

Se utilizzi un database di serie temporali (timeseries db, wiki) come memoria principale per un sito con statistiche, invece di risolvere il problema potresti avere un sacco di grattacapi. Sto lavorando a un progetto che utilizza un database di questo tipo e talvolta InfluxDB, di cui parleremo, ha presentato sorprese del tutto inaspettate.

Negazione di responsabilità: I problemi elencati si applicano a InfluxDB versione 1.7.4.

Perché le serie temporali?

Il progetto consiste nel tracciare le transazioni su varie blockchain e visualizzare le statistiche. Nello specifico, esaminiamo l'emissione e la combustione di stable coin (wiki). Sulla base di queste transazioni, è necessario costruire grafici e mostrare tabelle riassuntive.

Durante l'analisi delle transazioni, è venuta fuori un'idea: utilizzare il database delle serie temporali InfluxDB come archivio principale. Le transazioni sono punti nel tempo e si adattano bene al modello delle serie temporali.

Anche le funzioni di aggregazione sembravano molto convenienti, ideali per l'elaborazione di grafici con un lungo periodo. L'utente ha bisogno di un grafico per un anno e il database contiene un set di dati con un intervallo di tempo di cinque minuti. È inutile mandargli tutti i centomila punti: a parte una lunga elaborazione, non entreranno nemmeno nello schermo. Puoi scrivere la tua implementazione per aumentare l'intervallo di tempo o utilizzare le funzioni di aggregazione integrate in Influx. Con il loro aiuto puoi raggruppare i dati per giorno e inviare i 365 punti richiesti.

Creava un po’ di confusione il fatto che tali database venissero solitamente utilizzati allo scopo di raccogliere parametri. Monitoraggio di server, dispositivi iot, tutto ciò da cui “sgorgano” milioni di punti della forma: [<tempo> - <valore metrico>]. Ma se il database funziona bene con un grande flusso di dati, perché un volume piccolo dovrebbe causare problemi? Con questo in mente, abbiamo utilizzato InfluxDB.

Cos'altro è conveniente in InfluxDB

Oltre alle funzioni di aggregazione menzionate, c'è un'altra cosa fantastica: continue interrogazioni (doc). Si tratta di uno scheduler integrato nel database in grado di elaborare i dati secondo una pianificazione. Ad esempio, ogni 24 ore puoi raggruppare tutti i record della giornata, calcolare la media e registrare un nuovo punto in un'altra tabella senza scrivere le tue biciclette.

c'è anche un politiche di conservazione (doc)—impostazione della cancellazione dei dati dopo un certo periodo. È utile quando, ad esempio, è necessario memorizzare il carico della CPU per una settimana con misurazioni una volta al secondo, ma a distanza di un paio di mesi tale precisione non è necessaria. In una situazione del genere, puoi fare questo:

1. creare una query continua per aggregare i dati in un'altra tabella;
2. per la prima tabella, definire una policy per l'eliminazione delle metriche precedenti a quella stessa settimana.

E Influx ridurrà in modo indipendente la dimensione dei dati ed eliminerà le cose non necessarie.

Informazioni sui dati memorizzati

I dati archiviati sono pochi: circa 70mila transazioni e un altro milione di punti con informazioni di mercato. Aggiunta di nuove voci: non più di 3000 punti al giorno. Esistono anche metriche per il sito, ma i dati sono pochi e, secondo la politica di conservazione, vengono archiviati per non più di un mese.

Problematica

Durante lo sviluppo e il successivo test del servizio sono emersi problemi sempre più critici nel funzionamento di InfluxDB.

1. Eliminazione dei dati

C'è una serie di dati con le transazioni:

SELECT time, amount, block, symbol FROM transactions WHERE symbol='USDT'

Il risultato:

Sto inviando un comando per eliminare i dati:

DELETE FROM transactions WHERE symbol=’USDT’

Successivamente faccio una richiesta per ricevere i dati già cancellati. E invece di una risposta vuota, Influx restituisce parte dei dati che dovrebbero essere cancellati.

Sto cercando di eliminare l'intera tabella:

DROP MEASUREMENT transactions

Controllo la cancellazione della tabella:

SHOW MEASUREMENTS

Non vedo la tabella nell'elenco, ma una nuova query di dati restituisce comunque lo stesso insieme di transazioni.

Il problema mi è venuto in mente solo una volta, poiché il caso di cancellazione era un caso isolato. Ma questo comportamento del database chiaramente non rientra nel quadro del funzionamento “corretto”. Più tardi l'ho trovato aperto su github biglietto quasi un anno fa su questo argomento.

Di conseguenza, l'eliminazione e il ripristino dell'intero database hanno aiutato.

2. Numeri in virgola mobile

I calcoli matematici quando si utilizzano funzioni integrate in InfluxDB presentano errori di precisione. Non che questo sia qualcosa di insolito, ma è spiacevole.

Nel mio caso, i dati hanno una componente finanziaria e vorrei elaborarli con elevata precisione. Per questo motivo prevediamo di abbandonare le query continue.

3. Le query continue non possono essere adattate a diversi fusi orari

Il servizio ha una tabella con le statistiche delle transazioni giornaliere. Per ogni giorno è necessario raggruppare tutte le transazioni per quel giorno. Ma la giornata di ciascun utente inizierà in un momento diverso e quindi l’insieme delle transazioni sarà diverso. Entro UTC sì 37 varianti turni per i quali è necessario aggregare i dati.

In InfluxDB, quando si raggruppa per ora, è possibile inoltre specificare uno spostamento, ad esempio per l'ora di Mosca (UTC+3):

SELECT MEAN("supply") FROM transactions GROUP BY symbol, time(1d, 3h) fill(previous)

Ma il risultato della query non sarà corretto. Per qualche motivo, i dati raggruppati per giorno inizieranno a risalire al 1677 (InfluxDB supporta ufficialmente un intervallo di tempo a partire da quest'anno):

Per risolvere questo problema, abbiamo temporaneamente impostato il servizio su UTC+0.

4. Prestazioni

Esistono molti benchmark su Internet che confrontano InfluxDB e altri database. A prima vista sembravano materiali di marketing, ma ora penso che ci sia del vero in essi.

Ti racconto il mio caso.

Il servizio fornisce un metodo API che restituisce le statistiche dell'ultimo giorno. Durante l'esecuzione dei calcoli, il metodo interroga il database tre volte con le seguenti query:

SELECT * FROM coins_info WHERE time <= NOW() GROUP BY symbol ORDER BY time DESC LIMIT 1

SELECT * FROM dominance_info ORDER BY time DESC LIMIT 1

SELECT * FROM transactions WHERE time >= NOW() - 24h ORDER BY time DESC

Spiegazione:

1. Nella prima richiesta otteniamo gli ultimi punti per ogni moneta con i dati di mercato. Otto punti per otto monete nel mio caso.
2. La seconda richiesta ottiene uno dei punti più recenti.
3. Il terzo richiede un elenco delle transazioni delle ultime XNUMX ore; potrebbero essercene diverse centinaia.

Vorrei chiarire che InfluxDB crea automaticamente un indice basato su tag e tempo, il che accelera le query. Nella prima richiesta simbolo è un'etichetta.

Ho eseguito uno stress test su questo metodo API. Per 25 RPS, il server ha dimostrato un carico completo di sei CPU:

Allo stesso tempo, il processo NodeJs non ha fornito alcun carico.

La velocità di esecuzione è già diminuita di 7-10 RPS: se un client poteva ricevere una risposta in 200 ms, 10 client dovevano attendere un secondo. 25 RPS è il limite al quale ha sofferto la stabilità; 500 errori sono stati restituiti ai client.

Con tali prestazioni è impossibile utilizzare Influx nel nostro progetto. Inoltre: in un progetto in cui il monitoraggio deve essere dimostrato a molti clienti, potrebbero verificarsi problemi simili e il server delle metriche sarà sovraccarico.

conclusione

La conclusione più importante dell'esperienza acquisita è che non è possibile inserire una tecnologia sconosciuta in un progetto senza un'analisi sufficiente. Un semplice screening delle questioni aperte su github potrebbe fornire informazioni per evitare di scegliere InfluxDB come archivio dati principale.

InfluxDB avrebbe dovuto essere adatto ai compiti del mio progetto, ma come ha dimostrato la pratica, questo database non soddisfa le esigenze e presenta molti bug.

Puoi già trovare la versione 2.0.0-beta nel repository del progetto; possiamo solo sperare che la seconda versione abbia miglioramenti significativi. Nel frattempo andrò a studiare la documentazione di TimescaleDB.

Fonte: habr.com