Galit, bargaining at depression kapag nagtatrabaho sa InfluxDB

Kung gumagamit ka ng database ng serye ng oras (timeseries db, wiki) bilang pangunahing imbakan para sa isang site na may mga istatistika, pagkatapos ay sa halip na lutasin ang problema maaari kang makakuha ng maraming pananakit ng ulo. Nagtatrabaho ako sa isang proyekto na gumagamit ng ganoong database, at kung minsan ang InfluxDB, na tatalakayin, ay nagpapakita ng ganap na hindi inaasahang mga sorpresa.

Pagtanggi sa pananagutan: Ang mga isyung nakalista ay nalalapat sa bersyon 1.7.4 ng InfluxDB.

Bakit time series?

Ang proyekto ay upang subaybayan ang mga transaksyon sa iba't ibang mga blockchain at ipakita ang mga istatistika. Sa partikular, tinitingnan namin ang paglabas at pagsunog ng mga matatag na barya (wiki). Batay sa mga transaksyong ito, kailangan mong bumuo ng mga graph at magpakita ng mga talahanayan ng buod.

Habang sinusuri ang mga transaksyon, may nabuong ideya: gamitin ang InfluxDB time series database bilang pangunahing storage. Ang mga transaksyon ay mga punto sa oras at akma ang mga ito sa modelo ng serye ng oras.

Ang mga function ng pagsasama-sama ay mukhang napaka-maginhawa - perpekto para sa pagproseso ng mga chart na may mahabang panahon. Ang gumagamit ay nangangailangan ng isang tsart para sa isang taon, at ang database ay naglalaman ng isang set ng data na may time frame na limang minuto. Walang kabuluhan na ipadala sa kanya ang lahat ng isang daang libong tuldok - bukod sa mahabang pagproseso, hindi sila magkasya sa screen. Maaari kang sumulat ng sarili mong pagpapatupad ng pagpapataas ng timeframe, o gamitin ang mga function ng pagsasama-sama na binuo sa Influx. Sa tulong nila, maaari kang magpangkat ng data sa araw at ipadala ang kinakailangang 365 puntos.

Medyo nakakalito na ang mga naturang database ay karaniwang ginagamit para sa layunin ng pagkolekta ng mga sukatan. Pagsubaybay sa mga server, iot device, lahat ng bagay kung saan milyun-milyong punto ang anyong “daloy”: [ - ]. Ngunit kung ang database ay gumagana nang maayos sa isang malaking daloy ng data, kung gayon bakit dapat magdulot ng mga problema ang isang maliit na dami? Sa pag-iisip na ito, kinuha namin ang InfluxDB upang gumana.

Ano pa ang maginhawa sa InfluxDB

Bukod sa nabanggit na mga pag-andar ng pagsasama-sama, may isa pang magandang bagay - tuloy-tuloy na mga tanong (doc). Ito ay isang scheduler na binuo sa database na maaaring magproseso ng data sa isang iskedyul. Halimbawa, bawat 24 na oras maaari mong pangkatin ang lahat ng mga tala para sa araw, kalkulahin ang average at itala ang isang bagong punto sa isa pang talahanayan nang hindi sumusulat ng iyong sariling mga bisikleta.

Mayroon din mga patakaran sa pagpapanatili (doc)—pagse-set up ng pagtanggal ng data pagkatapos ng isang tiyak na panahon. Ito ay kapaki-pakinabang kapag, halimbawa, kailangan mong iimbak ang pag-load ng CPU sa loob ng isang linggo na may mga sukat isang beses bawat segundo, ngunit sa loob ng ilang buwan ang katumpakan ay hindi kinakailangan. Sa ganitong sitwasyon, magagawa mo ito:

1. lumikha ng tuluy-tuloy na query upang pagsama-samahin ang data sa isa pang talahanayan;
2. para sa unang talahanayan, tumukoy ng patakaran para sa pagtanggal ng mga sukatan na mas luma kaysa sa parehong linggong iyon.

At ang Influx ay nakapag-iisa na bawasan ang laki ng data at tatanggalin ang mga hindi kinakailangang bagay.

Tungkol sa nakaimbak na data

Walang gaanong data ang nakaimbak: humigit-kumulang 70 libong mga transaksyon at isa pang milyong puntos na may impormasyon sa merkado. Pagdaragdag ng mga bagong entry - hindi hihigit sa 3000 puntos bawat araw. Mayroon ding mga sukatan para sa site, ngunit may kaunting data doon at, ayon sa patakaran sa pagpapanatili, naka-imbak ang mga ito nang hindi hihigit sa isang buwan.

Mga Problema

Sa panahon ng pagbuo at kasunod na pagsubok ng serbisyo, parami nang parami ang mga kritikal na problema na lumitaw sa pagpapatakbo ng InfluxDB.

1. Pagtanggal ng data

Mayroong isang serye ng data na may mga transaksyon:

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

Resulta:

Nagpapadala ako ng command para tanggalin ang data:

DELETE FROM transactions WHERE symbol=’USDT’

Susunod, humiling ako upang matanggap ang natanggal na data. At sa halip na walang laman na tugon, ibinabalik ng Influx ang bahagi ng data na dapat tanggalin.

Sinusubukan kong tanggalin ang buong talahanayan:

DROP MEASUREMENT transactions

Sinusuri ko ang pagtanggal ng talahanayan:

SHOW MEASUREMENTS

Hindi ko nakikita ang talahanayan sa listahan, ngunit ang isang bagong query sa data ay nagbabalik pa rin ng parehong hanay ng mga transaksyon.

Isang beses lang nangyari sa akin ang problema, dahil ang kaso ng pagtanggal ay isang nakahiwalay na kaso. Ngunit ang pag-uugali na ito ng database ay malinaw na hindi umaangkop sa balangkas ng "tama" na operasyon. Nang maglaon ay nakita kong nakabukas ito sa github tiket halos isang taon na ang nakalipas sa paksang ito.

Bilang resulta, nakatulong ang pagtanggal at pagpapanumbalik ng buong database.

2. Mga numero ng floating point

May mga error sa katumpakan ang mga kalkulasyon sa matematika kapag gumagamit ng mga built-in na function sa InfluxDB. Hindi na ito ay anumang bagay na hindi karaniwan, ngunit ito ay hindi kasiya-siya.

Sa aking kaso, ang data ay may bahaging pinansyal at gusto kong iproseso ito nang may mataas na katumpakan. Dahil dito, pinaplano naming iwanan ang patuloy na mga query.

3. Ang mga patuloy na query ay hindi maaaring iakma sa iba't ibang time zone

Ang serbisyo ay may talahanayan na may pang-araw-araw na istatistika ng transaksyon. Para sa bawat araw, kailangan mong pangkatin ang lahat ng transaksyon para sa araw na iyon. Ngunit magsisimula ang araw ng bawat user sa iba't ibang oras, at samakatuwid ay mag-iiba ang hanay ng mga transaksyon. Sa pamamagitan ng UTC oo 37 mga pagkakaiba-iba mga shift kung saan kailangan mong pagsama-samahin ang data.

Sa InfluxDB, kapag nagpapangkat ayon sa oras, maaari kang magdagdag ng shift, halimbawa para sa oras ng Moscow (UTC+3):

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

Ngunit ang resulta ng query ay magiging mali. Para sa ilang kadahilanan, ang data na nakagrupo ayon sa araw ay magsisimula hanggang sa 1677 (opisyal na sinusuportahan ng InfluxDB ang tagal ng panahon mula sa taong ito):

Upang malutas ang problemang ito, pansamantala naming inilipat ang serbisyo sa UTC+0.

4. Pagganap

Maraming mga benchmark sa Internet na naghahambing sa InfluxDB at iba pang mga database. Sa unang tingin, sila ay mukhang mga materyales sa marketing, ngunit ngayon sa tingin ko ay may ilang katotohanan sa kanila.

Sasabihin ko sa iyo ang aking kaso.

Nagbibigay ang serbisyo ng paraan ng API na nagbabalik ng mga istatistika para sa huling araw. Kapag nagsasagawa ng mga kalkulasyon, ang pamamaraan ay nagtatanong sa database ng tatlong beses gamit ang mga sumusunod na 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

Paliwanag:

1. Sa unang kahilingan, nakukuha namin ang mga huling puntos para sa bawat coin na may data ng market. Walong puntos para sa walong barya sa aking kaso.
2. Ang pangalawang kahilingan ay makakakuha ng isa sa mga pinakabagong puntos.
3. Ang pangatlo ay humihiling ng isang listahan ng mga transaksyon para sa huling XNUMX na oras; maaaring mayroong ilang daang mga ito.

Hayaan akong linawin na ang InfluxDB ay awtomatikong bumubuo ng isang index batay sa mga tag at oras, na nagpapabilis ng mga query. Sa unang kahilingan simbolo ay isang tag.

Nagpatakbo ako ng stress test sa paraang ito ng API. Para sa 25 RPS, nagpakita ang server ng buong pagkarga ng anim na CPU:

Kasabay nito, ang proseso ng NodeJs ay hindi nagbigay ng anumang load.

Ang bilis ng pagpapatupad ay bumaba na ng 7-10 RPS: kung ang isang kliyente ay makakatanggap ng tugon sa loob ng 200 ms, 10 mga kliyente ang kailangang maghintay ng isang segundo. Ang 25 RPS ay ang limitasyon kung saan naranasan ang katatagan; 500 mga error ang ibinalik sa mga kliyente.

Sa ganoong pagganap, imposibleng gamitin ang Influx sa aming proyekto. Higit pa rito: sa isang proyekto kung saan kailangang ipakita ang pagsubaybay sa maraming kliyente, maaaring lumitaw ang mga katulad na problema at ma-overload ang server ng sukatan.

Pagbubuhos

Ang pinakamahalagang konklusyon mula sa karanasang natamo ay hindi ka maaaring kumuha ng hindi kilalang teknolohiya sa isang proyekto nang walang sapat na pagsusuri. Ang isang simpleng screening ng mga bukas na isyu sa github ay maaaring magbigay ng impormasyon upang maiwasan ang pagpili sa InfluxDB bilang pangunahing data store.

Ang InfluxDB ay dapat na angkop para sa mga gawain ng aking proyekto, ngunit tulad ng ipinakita ng kasanayan, ang database na ito ay hindi nakakatugon sa mga pangangailangan at may maraming mga bug.

Makakakita ka na ng bersyon 2.0.0-beta sa repositoryo ng proyekto; maaari lamang kaming umasa na magkakaroon ng makabuluhang pagpapabuti ang pangalawang bersyon. Pansamantala, pag-aaralan ko ang dokumentasyon ng TimescaleDB.

Pinagmulan: www.habr.com