Se utilizate una basa di dati di serie temporale (timeseries db, ) cum'è l'almacenamiento principalu per un situ cù statistiche, allora invece di risolve u prublema, pudete piglià assai mal di testa. Sò travagliatu nantu à un prughjettu chì usa una tale basa di dati, è qualchì volta InfluxDB, chì serà discutitu, presentava sorprese in generale inespettate.
LégalesNota: I prublemi mostrati sò per InfluxDB 1.7.4.
Perchè a serie di tempu?
U prughjettu hè di seguità e transazzione in diverse blockchains è di vede statistiche. In particulare, guardemu à l'emissione è a brucia di muniti stabile (). Basatu nantu à queste transazzione, avete bisognu di custruisce grafici è mostranu e tabelle pivot.
Quandu analizà e transazzione, hè ghjunta una idea: aduprà a basa di dati di serie di tempu InfluxDB cum'è u almacenamentu principale. E transazzione sò punti in u tempu è si adattanu bè à u mudellu di serie di tempu.
E funzioni di aggregazione parevanu ancu assai convenienti - sò ideali per processà carte cù un longu periodu. L'utilizatore hà bisognu di un graficu per un annu, è a basa di dati cuntene un settore di dati cù un tempu di cinque minuti. Hè inutile di mandà tutti i centu mila punti à ellu - fora di un prucessu longu, ùn si mette micca nantu à u screnu. Pudete scrive a vostra propria implementazione di aumentà u timeframe, o utilizate e funzioni di aggregazione integrate in Influx. Cù u so aiutu, pudete aggrupà i dati per ghjornu è mandà i punti 365 necessarii.
Era un pocu imbarazzante chì tali basa di dati sò generalmente usati per cullà metriche. Surveglianza di i servitori, iot devices, tuttu da quale milioni di punti di a forma "flussu": [<tempu> - <valore metricu>]. Ma se a basa di dati funziona bè cù un grande flussu di dati, allora perchè un picculu voluminu deve causà prublemi? Cù stu pensamentu, anu pigliatu InfluxDB à travaglià.
Chì altru hè cunvene in InfluxDB
In più di e funzioni di aggregazione citate, ci hè un'altra grande cosa - dumande cuntinue (). Questu hè un pianificatore integratu in a basa di dati chì pò processà e dati nantu à un schedariu. Per esempiu, pudete raggruppà tutti i registri per u ghjornu ogni 24 ore, calculà a media è scrivite un novu puntu à un altru tavulu senza scrive e vostre biciclette.
Avè ancu pulitiche di ritenzione () - impostazione per sguassà dati dopu un certu periodu. Hè utile quandu, per esempiu, avete bisognu di almacenà a carica nantu à u CPU per una settimana cù misurazioni una volta per seconda, ma una tale precisione ùn hè micca necessariu à una distanza di un paru di mesi. In una tale situazione, pudete fà questu:
- creà una dumanda cuntinuu per aggregate dati in un altru tavulu;
- per a prima tavola, definisce una pulitica per sguassà e metriche chì sò più vechje di quella stessa settimana.
È Influx riducerà a dimensione di e dati è sguassate i dati inutili per sè stessu.
À propositu di dati almacenati
Ùn sò micca assai dati guardati: circa 70 mila transazzione è un altru millioni di punti cù l'infurmazioni di u mercatu. Aghjunghjendu novi entrate - micca più di 3000 punti per ghjornu. Ci sò ancu metriche per u situ, ma ci sò pocu dati è, secondu a pulitica di retenzioni, sò stati guardati per micca più di un mesi.
Problemi
Durante u sviluppu è a prova sussegwente di u serviziu, più è più prublemi critichi sò ghjunti in l'operazione di InfluxDB.
1. Sguassà dati
Ci hè una serie di dati cù transacciones:
SELECT time, amount, block, symbol FROM transactions WHERE symbol='USDT'Risultatu:
Mandu un cumandamentu per sguassà dati:
DELETE FROM transactions WHERE symbol=’USDT’In più, aghju dumandatu l'ottenimentu di dati digià eliminati. È Influx, invece di una risposta viota, torna un pezzu di dati chì deve esse eliminatu.
Aghju pruvatu à sguassà tutta a tavola:
DROP MEASUREMENT transactionsAghju verificatu l'eliminazione di a tavola:
SHOW MEASUREMENTSÙn vecu micca a tavula in a lista, ma a nova dumanda di dati torna sempre u listessu settore di transazzione.
U prublema hè stata per mè solu una volta, postu chì u casu di eliminazione hè un casu isolatu. Ma stu cumpurtamentu di a basa di dati chjaramente ùn si mette micca in u quadru di u travagliu "correttu". Più tardi github trovu apertu quasi un annu nantu à questu tema.
In u risultatu, l'eliminazione è a risturazione sussegwente di tutta a basa di dati aiutau.
2. Numeri in virgule flottante
I calculi matematichi chì utilizanu e funzioni integrate di InfluxDB dannu errori di precisione. Micca chì era qualcosa di inusual, ma dispiacevule.
In u mo casu, i dati anu un cumpunente finanziariu è mi piacerebbe processà cù alta precisione. Per quessa, pensamu à abbandunà e dumande cuntinue.
3. E dumande cuntinue ùn ponu micca adattate à e diverse fusi orari
U serviziu hà una tavula cù statistiche di transazzione di ogni ghjornu. Per ogni ghjornu, avete bisognu di raggruppà tutte e transazzione per quellu ghjornu. Ma u ghjornu per ogni utilizatore hà da principià à un tempu diversu, per quessa, u settore di transazzione hè diversu. UTC hè turni per quale vulete aggregate dati.
In InfluxDB, quandu si raggruppa per u tempu, pudete ancu specificà un cambiamentu, per esempiu, per l'ora di Mosca (UTC + 3):
SELECT MEAN("supply") FROM transactions GROUP BY symbol, time(1d, 3h) fill(previous)Ma u risultatu di a quistione serà sbagliatu. Per una certa ragione, i dati raggruppati per ghjornu cumincianu à u 1677 (InfluxDB supporta ufficialmente un intervallu di tempu da questu annu):
Per evità stu prublema, u serviziu hè statu trasferitu temporaneamente à UTC + 0.
4. Prestazione
Ci hè parechje benchmarks in Internet cù paraguni di InfluxDB è altre basa di dati. À u primu sguardu, parevanu materiali di marketing, ma avà pensu chì ci hè una certa verità in elli.
Lasciami dì u mo casu.
U serviziu furnisce un metudu API chì torna statistiche per l'ultime XNUMX ore. Durante i calculi, u metudu interroga a basa di dati trè volte cù e seguenti dumande:
SELECT * FROM coins_info WHERE time <= NOW() GROUP BY symbol ORDER BY time DESC LIMIT 1SELECT * FROM dominance_info ORDER BY time DESC LIMIT 1SELECT * FROM transactions WHERE time >= NOW() - 24h ORDER BY time DESCSpiegazione:
- In a prima dumanda, avemu l'ultimi punti per ogni munita cù dati di u mercatu. Ottu punti per ottu muniti in u mo casu.
- A seconda dumanda riceve un puntu più novu.
- U terzu dumanda una lista di transazzione per l'ultime XNUMX ore, pò esse parechji centu di elli.
Permettemu di chjarificà chì in InfluxDB, un indexu hè custruitu automaticamente da tag è da u tempu, chì accelera e dumande. In a prima dumanda Simbulu hè un tag.
Aghju fattu una prova di stress per stu metudu API. Per 25 RPS, u servitore hà dimustratu una carica completa di sei CPU:
À u listessu tempu, u prucessu NodeJs ùn hà micca datu alcuna carica.
A velocità di esecuzione hè degradata digià da 7-10 RPS: se un cliente puderia riceve una risposta in 200 ms, allora i clienti 10 anu da aspittà per un secondu. 25 RPS - a fruntiera da quale a stabilità hà patitu, 500 errori sò stati restituiti à i clienti.
Cù tali prestazioni, hè impussibile di utilizà Influx in u nostru prughjettu. Inoltre, in un prughjettu induve u monitoraghju deve esse dimustratu à parechji clienti, i prublemi simili ponu appare è u servitore di metrica serà sovraccaricatu.
cunchiusioni
A cunclusione più impurtante da l'esperienza acquistata hè chì ùn pudete micca piglià una tecnulugia scunnisciuta in un prughjettu senza analisi suffirenziu. Un screening simplice di i biglietti aperti nantu à github puderia furnisce infurmazioni per ùn piglià InfluxDB cum'è u magazzinu di dati principale.
InfluxDB era suppostu per adattà à i travaglii di u mo prughjettu bè, ma cum'è a pratica hà dimustratu, sta basa di dati ùn risponde micca i bisogni è messe assai.
Pudete digià truvà a versione 2.0.0-beta in u repository di u prughjettu, resta à sperà chì ci saranu miglioramenti significativi in a seconda versione. Intantu, andaraghju à studià a documentazione TimescaleDB.
Source: www.habr.com