Kung mogamit ka ug time series database (timeseries db, ) isip nag-unang pagtipig alang sa usa ka site nga adunay mga estadistika, unya imbis nga masulbad ang problema, mahimo nimong makuha ang daghang mga labad sa ulo. Nagtrabaho ko sa usa ka proyekto nga naggamit sa ingon nga database, ug usahay ang InfluxDB, nga pagahisgutan, gipresentar sa kasagaran wala damha nga mga sorpresa.
DisclaimerHinumdomi: Ang mga isyu nga gipakita kay para sa InfluxDB 1.7.4.
Ngano nga time series?
Ang proyekto mao ang pagsubay sa mga transaksyon sa lain-laing mga blockchain ug pagpakita sa estadistika. Sa partikular, atong gitan-aw ang emission ug pagsunog sa mga stable nga sensilyo (). Base sa kini nga mga transaksyon, kinahanglan nimo nga maghimo mga graph ug ipakita ang mga pivot table.
Kung nag-analisar sa mga transaksyon, usa ka ideya ang mitungha: ang paggamit sa database sa serye sa panahon sa InfluxDB isip panguna nga pagtipig. Ang mga transaksyon mao ang mga punto sa oras ug kini haum kaayo sa modelo sa serye sa panahon.
Ang aggregation function usab tan-awon kaayo nga kombenyente - kini maayo alang sa pagproseso sa mga tsart nga adunay taas nga panahon. Ang user nagkinahanglan ug tsart sulod sa usa ka tuig, ug ang database adunay sulod nga data set nga adunay timeframe nga lima ka minuto. Wala’y kapuslanan nga ipadala kaniya ang tanan usa ka gatos ka libo nga puntos - gawas sa usa ka taas nga pagproseso, dili sila mohaum sa screen. Mahimo nimong isulat ang imong kaugalingon nga pagpatuman sa pagdugang sa timeframe, o gamita ang mga function sa aggregation nga gitukod sa Influx. Sa ilang tabang, mahimo nimong grupo ang datos sa adlaw ug ipadala ang gusto nga 365 puntos.
Kini usa ka gamay nga makauulaw nga ang ingon nga mga database kasagarang gigamit sa pagkolekta sa mga sukatan. Pag-monitor sa mga server, iot device, tanan nga gikan diin milyon-milyon nga mga punto sa porma nga "pag-agos": [<oras> - <metric value>]. Apan kung maayo ang pagtrabaho sa database sa usa ka dako nga stream sa datos, nan ngano nga ang gamay nga gidaghanon magpahinabog mga problema? Uban niini nga hunahuna, gikuha nila ang InfluxDB aron magtrabaho.
Unsa pa ang kombenyente sa InfluxDB
Gawas pa sa gihisgutan nga mga gimbuhaton sa aggregation, adunay lain nga maayo nga butang - padayon nga mga pangutana (). Kini usa ka scheduler nga gitukod sa database nga makaproseso sa datos sa usa ka iskedyul. Pananglitan, mahimo nimong igrupo ang tanan nga mga rekord alang sa adlaw matag 24 oras, kuwentahon ang kasagaran ug isulat ang usa ka bag-ong punto sa lain nga lamesa nga wala magsulat sa imong kaugalingon nga mga bisikleta.
Ingon usab mga palisiya sa pagpabilin () - setting para sa pagtangtang sa datos human sa usa ka panahon. Mapuslanon kung, pananglitan, kinahanglan nimo nga tipigan ang load sa CPU sulod sa usa ka semana nga adunay mga pagsukod kausa matag segundo, apan sa gilay-on nga duha ka bulan, ang ingon nga katukma dili kinahanglan. Sa ingon nga sitwasyon, mahimo nimo kini:
- paghimo og usa ka padayon nga pangutana sa pagtipon sa datos ngadto sa laing lamesa;
- para sa unang talaan, ipasabot ang usa ka polisiya sa pagtangtang sa mga sukdanan nga mas karaan pa sa samang semana.
Ug ang Influx makapakunhod sa gidak-on sa datos ug magwagtang sa wala kinahanglana nga datos sa iyang kaugalingon.
Mahitungod sa gitipigan nga datos
Dili daghan nga datos ang gitipigan: mga 70 ka libo nga mga transaksyon ug laing milyon nga mga punto nga adunay impormasyon sa merkado. Pagdugang bag-ong mga entry - dili molapas sa 3000 puntos matag adlaw. Adunay usab mga sukatan alang sa site, apan adunay gamay nga datos didto ug, sumala sa palisiya sa pagpadayon, kini gitipigan nga dili molapas sa usa ka bulan.
Mga problema
Atol sa pag-uswag ug sunod nga pagsulay sa serbisyo, nagkadaghan ang mga kritikal nga problema nga mitumaw sa operasyon sa InfluxDB.
1. Pagtangtang sa datos
Adunay usa ka serye sa mga datos nga adunay mga transaksyon:
SELECT time, amount, block, symbol FROM transactions WHERE symbol='USDT'Resulta:
Nagpadala ako usa ka mando aron mapapas ang datos:
DELETE FROM transactions WHERE symbol=’USDT’Dugang pa, ako nangayo alang sa pagkuha sa natangtang na nga datos. Ug ang Influx, imbis nga walay sulod nga tubag, nagbalik sa usa ka piraso sa datos nga kinahanglan tangtangon.
Gisulayan nako nga papason ang tibuuk nga lamesa:
DROP MEASUREMENT transactionsGisusi nako ang pagtangtang sa lamesa:
SHOW MEASUREMENTSWala nako makita ang lamesa sa lista, apan ang bag-ong pangutana sa datos nagbalik gihapon sa parehas nga hugpong sa mga transaksyon.
Ang problema mitungha alang kanako kausa ra, tungod kay ang kaso sa pagtangtang usa ka nahilit nga kaso. Apan kini nga kinaiya sa database klaro nga dili mohaum sa gambalay sa "husto" nga trabaho. Sa ulahi sa github nakit-an nga bukas hapit usa ka tuig ang edad sa kini nga hilisgutan.
Ingon usa ka sangputanan, ang pagtangtang ug ang sunod nga pagpahiuli sa tibuuk nga database nakatabang.
2. Mga numero sa floating point
Ang mga kalkulasyon sa matematika gamit ang mga built-in nga function sa InfluxDB naghatag ug tukma nga mga sayup. Dili nga kini usa ka butang nga talagsaon, apan dili maayo.
Sa akong kaso, ang datos adunay bahin sa pinansyal ug gusto nako nga iproseso kini nga adunay taas nga katukma. Tungod niini, nagplano kami nga biyaan ang padayon nga mga pangutana.
3. Ang padayon nga mga pangutana dili mahimong ipahiangay sa lain-laing mga time zone
Ang serbisyo adunay usa ka lamesa nga adunay mga istatistika sa adlaw-adlaw nga transaksyon. Alang sa matag adlaw, kinahanglan nimo nga igrupo ang tanan nga mga transaksyon alang nianang adlawa. Apan ang adlaw alang sa matag tiggamit magsugod sa lainlaing oras, busa, lahi ang set sa mga transaksyon. Ang UTC mao mga pagbag-o nga gusto nimong i-aggregate ang datos.
Sa InfluxDB, kung naggrupo sa oras, mahimo nimong ipiho ang usa ka pagbalhin, pananglitan, alang sa oras sa Moscow (UTC + 3):
SELECT MEAN("supply") FROM transactions GROUP BY symbol, time(1d, 3h) fill(previous)Apan ang resulta sa pangutana mahimong dili husto. Sa pila ka rason, ang datos nga gigrupo sa adlaw magsugod sa 1677 (Opisyal nga gisuportahan sa InfluxDB ang gidugayon sa panahon gikan karong tuiga):
Aron malikayan kini nga problema, ang serbisyo temporaryo nga gibalhin sa UTC + 0.
4. Pagpasundayag
Adunay daghang mga benchmark sa Internet nga adunay mga pagtandi sa InfluxDB ug uban pang mga database. Sa una nga pagtan-aw, sila morag mga materyales sa pagpamaligya, apan karon sa akong hunahuna adunay pipila ka kamatuoran niini.
Tugoti ako sa pagsulti kanimo sa akong kaso.
Ang serbisyo naghatag usa ka pamaagi sa API nga nagbalik sa mga istatistika sa miaging XNUMX ka oras. Atol sa mga kalkulasyon, ang pamaagi mangutana sa database sa tulo ka beses uban sa mosunod nga mga pangutana:
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 DESCKatin-awan:
- Sa una nga hangyo, makuha namon ang pinakabag-o nga mga punto alang sa matag sensilyo nga adunay datos sa merkado. Walo ka tuldok para sa walo ka sensilyo sa akong kaso.
- Ang ikaduhang hangyo makakuha og usa ka pinakabag-o nga punto.
- Ang ikatulo nangayo og lista sa mga transaksyon sulod sa katapusang XNUMX oras, mahimong adunay pipila ka gatos niini.
Patin-aw nako nga sa InfluxDB, ang usa ka indeks awtomatik nga gihimo sa mga tag ug sa oras, nga nagpadali sa mga pangutana. Sa unang hangyo simbolo usa ka tag.
Naghimo ako usa ka pagsulay sa stress alang sa kini nga pamaagi sa API. Alang sa 25 RPS, ang server nagpakita sa usa ka bug-os nga load sa unom ka mga CPU:
Sa parehas nga oras, ang proseso sa NodeJs wala maghatag bisan unsang load.
Ang katulin sa pagpatuman nadaot na sa 7-10 RPS: kung ang usa ka kliyente makadawat usa ka tubag sa 200 ms, nan ang 10 nga mga kliyente kinahanglan maghulat usa ka segundo. 25 RPS - ang utlanan diin ang kalig-on nag-antus, 500 nga mga sayup ang gibalik sa mga kliyente.
Sa ingon nga pasundayag, imposible nga magamit ang Influx sa among proyekto. Dugang pa, sa usa ka proyekto diin ang pagmonitor kinahanglan nga ipakita sa daghang mga kliyente, ang susamang mga problema mahimong makita ug ang metrics server ma-overload.
konklusyon
Ang labing hinungdanon nga konklusyon gikan sa kasinatian nga nakuha mao nga dili nimo mahimo ang usa ka wala mailhi nga teknolohiya sa usa ka proyekto nga wala’y igong pagtuki. Ang usa ka yano nga pag-screen sa bukas nga mga tiket sa github mahimong maghatag kasayuran nga dili makuha ang InfluxDB ingon ang panguna nga tindahan sa datos.
Ang InfluxDB angay unta nga mohaum sa mga buluhaton sa akong proyekto, apan sama sa gipakita sa praktis, kini nga database dili makatubag sa mga panginahanglan ug makadaut sa daghan.
Mahimo nimong makit-an ang bersyon 2.0.0-beta sa repository sa proyekto, nagpabilin nga gilauman nga adunay daghang mga pag-uswag sa ikaduha nga bersyon. Sa kasamtangan, magtuon ako sa dokumentasyon sa TimescaleDB.
Source: www.habr.com