Gisugyot ko nga basahon nimo ang transcript sa ulahing 2019 nga taho ni Alexander Valyalkin "Go optimizations in VictoriaMetrics"
β usa ka paspas ug scalable nga DBMS alang sa pagtipig ug pagproseso sa mga datos sa porma sa usa ka serye sa oras (ang rekord nagporma sa oras ug usa ka hugpong sa mga kantidad nga katumbas sa kini nga oras, pananglitan, nakuha pinaagi sa periodic polling sa kahimtang sa mga sensor o koleksyon sa metrics).
Ania ang usa ka link sa video niini nga taho -
Sultihi kami bahin sa imong kaugalingon. Ako si Alexander Valyalkin. Dinhi . Ganahan ko sa Go ug pag-optimize sa performance. Nagsulat ako og daghang mapuslanon ug dili kaayo mapuslanon nga mga librarya. Nagsugod sila sa bisan asa fast, o uban sa quick prefix.
Nagtrabaho ko karon sa VictoriaMetrics. Unsa kini ug unsa ang akong gibuhat didto? Akong hisgutan kini sa kini nga presentasyon.
Ang outline sa report mao ang mosunod:
- Una, isulti ko kanimo kung unsa ang VictoriaMetrics.
- Unya isulti ko kanimo kung unsa ang mga serye sa oras.
- Unya isulti ko kanimo kung giunsa ang usa ka database sa serye sa oras nga nagtrabaho.
- Sunod, isulti ko kanimo ang bahin sa arkitektura sa database: kung unsa ang gilangkuban niini.
- Ug unya magpadayon kita sa mga pag-optimize nga naa sa VictoriaMetrics. Kini usa ka pag-optimize alang sa balit-ad nga indeks ug usa ka pag-optimize alang sa pagpatuman sa bitset sa Go.
Aduna bay nahibal-an sa mamiminaw kung unsa ang VictoriaMetrics? Wow, daghan na ang nakahibalo. Kini usa ka maayong balita. Alang niadtong wala mahibalo, kini usa ka database sa serye sa panahon. Gibase kini sa arkitektura sa ClickHouse, sa pipila ka mga detalye sa pagpatuman sa ClickHouse. Pananglitan, sa sama sa: MergeTree, parallel kalkulasyon sa tanan nga anaa processor cores ug performance optimization pinaagi sa pagtrabaho sa data blocks nga gibutang sa processor cache.
Ang VictoriaMetrics naghatag ug mas maayong data compression kay sa ubang mga time series nga database.
Kini nga timbangan nga patayo - nga mao, mahimo nimong idugang ang daghang mga processor, daghang RAM sa usa ka kompyuter. Malampuson nga magamit sa VictoriaMetrics kining mga magamit nga kapanguhaan ug mapauswag ang linear nga produktibidad.
Ang VictoriaMetrics nag-scale usab nga pinahigda - sa ato pa, mahimo nimong idugang ang dugang nga mga node sa cluster sa VictoriaMetrics, ug ang pasundayag niini motaas halos sa linya.
Sama sa imong natag-an, ang VictoriaMetrics usa ka paspas nga database, tungod kay dili ako makasulat sa uban. Ug kini nahisulat sa Go, mao nga ako naghisgot bahin niini sa niini nga meetup.
Kinsa ang nahibal-an kung unsa ang usa ka serye sa oras? Daghan sab siyag kaila. Ang usa ka serye sa oras usa ka serye sa mga pares (timestamp, Π·Π½Π°ΡΠ΅Π½ΠΈΠ΅), diin kini nga mga pares gisunod sa oras. Ang bili kay usa ka floating point number - float64.
Ang matag serye sa panahon talagsaon nga giila pinaagi sa usa ka yawe. Unsa ang naglangkob niini nga yawe? Naglangkob kini sa usa ka walaβy sulod nga hugpong sa mga pares nga hinungdanon nga kantidad.
Ania ang usa ka pananglitan sa usa ka serye sa panahon. Ang yawe niini nga serye mao ang listahan sa mga pares: __name__="cpu_usage" mao ang ngalan sa metric, instance="my-server" - kini ang kompyuter diin kini nga sukatan gikolekta, datacenter="us-east" - kini ang sentro sa datos diin nahimutang kini nga kompyuter.
Natapos namon ang usa ka ngalan sa serye sa oras nga gilangkuban sa tulo nga mga pares nga hinungdanon nga kantidad. Kini nga yawe katumbas sa usa ka lista sa mga pares (timestamp, value). t1, t3, t3, ..., tN - kini ang mga timestamp, 10, 20, 12, ..., 15 - ang katugbang nga mga kantidad. Kini mao ang cpu-paggamit sa usa ka gihatag nga panahon alang sa usa ka gihatag nga serye.
Asa magamit ang time series? Kinsay naay idea?
- Sa DevOps, mahimo nimong sukdon ang CPU, RAM, network, rps, gidaghanon sa mga sayup, ug uban pa.
- IoT - masukod nato ang temperatura, presyur, geo coordinates ug uban pa.
- Usab sa pinansya - mahimo natong bantayan ang mga presyo alang sa tanang matang sa mga stock ug mga kwarta.
- Dugang pa, ang mga serye sa oras mahimong magamit sa pag-monitor sa mga proseso sa produksiyon sa mga pabrika. Kami adunay mga tiggamit nga naggamit sa VictoriaMetrics sa pag-monitor sa mga wind turbine, alang sa mga robot.
- Ang mga serye sa oras mapuslanon usab sa pagkolekta sa impormasyon gikan sa mga sensor sa lainlaing mga himan. Pananglitan, alang sa usa ka makina; alang sa pagsukod sa presyur sa ligid; alang sa pagsukod sa katulin, gilay-on; alang sa pagsukod sa konsumo sa gasolina, ug uban pa.
- Ang mga serye sa oras mahimo usab nga gamiton sa pagmonitor sa ayroplano. Ang matag ayroplano adunay itom nga kahon nga nagkolekta sa serye sa oras alang sa lainlaing mga parameter sa kahimsog sa ayroplano. Ang mga serye sa oras gigamit usab sa industriya sa aerospace.
- Ang pag-atiman sa panglawas mao ang presyon sa dugo, pulso, ug uban pa.
Tingali adunay daghang mga aplikasyon nga akong nakalimtan, apan nanghinaut ko nga masabtan nimo nga ang mga serye sa oras aktibo nga gigamit sa modernong kalibutan. Ug ang gidaghanon sa ilang paggamit nagkadako matag tuig.
Ngano nga kinahanglan nimo ang database sa serye sa oras? Ngano nga dili nimo magamit ang usa ka regular nga relational database sa pagtipig sa serye sa oras?
Tungod kay ang mga serye sa oras kasagaran adunay daghang kasayuran, nga lisud tipigan ug iproseso sa naandan nga mga database. Busa, mitungha ang mga espesyal nga database alang sa mga serye sa panahon. Kini nga mga base epektibo nga nagtipig sa mga punto (timestamp, value) uban sa gihatag nga yawe. Naghatag sila og API alang sa pagbasa sa gitipigan nga datos pinaagi sa yawe, pinaagi sa usa ka pares nga key-value, o sa daghang pares nga key-value, o pinaagi sa regexp. Pananglitan, gusto nimo pangitaon ang CPU load sa tanan nimong serbisyo sa usa ka data center sa America, unya kinahanglan nimo nga gamiton kini nga pseudo-query.
Kasagaran ang mga database sa serye sa oras naghatag espesyal nga mga pinulongan sa pangutana tungod kay ang mga serye sa oras nga SQL dili kaayo haum. Bisan kung adunay mga database nga nagsuporta sa SQL, kini dili kaayo angay. Pangutana nga mga pinulongan sama sa , , , . Nanghinaut ko nga adunay nakadungog bisan usa niini nga mga pinulongan. Daghang mga tawo tingali nakadungog bahin sa PromQL. Kini ang Prometheus nga pangutana nga pinulongan.
Mao kini ang hitsura sa modernong arkitektura sa database sa serye sa panahon gamit ang VictoriaMetrics isip pananglitan.
Kini naglangkob sa duha ka bahin. Kini ang pagtipig alang sa balit-ad nga indeks ug pagtipig alang sa mga kantidad sa serye sa oras. Kini nga mga repositoryo gibulag.
Kung ang usa ka bag-ong rekord moabut sa database, una namon nga ma-access ang balit-ad nga indeks aron makit-an ang time series identifier alang sa gihatag nga set label=value alang sa gihatag nga metric. Atong makit-an kini nga identifier ug i-save ang kantidad sa data store.
Kung moabut ang usa ka hangyo aron makuha ang datos gikan sa TSDB, moadto una kami sa balit-ad nga indeks. Atong makuha ang tanan timeseries_ids mga rekord nga motakdo niini nga set label=value. Ug dayon makuha namon ang tanan nga kinahanglan nga datos gikan sa bodega sa datos, nga gi-index ni timeseries_ids.
Atong tan-awon ang usa ka pananglitan kung giunsa ang usa ka time series nga database nagproseso sa umaabot nga pinili nga pangutana.
- Una sa tanan makuha niya ang tanan
timeseries_idsgikan sa usa ka balit-ad nga indeks nga naglangkob sa gihatag nga mga pareslabel=value, o pagtagbaw sa gihatag nga regular nga ekspresyon. - Dayon makuha niini ang tanang mga punto sa datos gikan sa pagtipig sa datos sa gihatag nga agwat sa panahon alang sa mga nakit-an
timeseries_ids. - Pagkahuman niini, ang database naghimo sa pipila ka mga kalkulasyon sa kini nga mga punto sa datos, sumala sa hangyo sa tiggamit. Ug pagkahuman niana gibalik ang tubag.
Niini nga presentasyon isulti ko kanimo ang bahin sa una nga bahin. Kini usa ka pagpangita timeseries_ids pinaagi sa inverted index. Mahimo nimong tan-awon ang bahin sa ikaduha nga bahin ug ang ikatulo nga bahin sa ulahi , o maghulat hangtod nga ako mag-andam sa ubang mga taho :)
Mopadayon kita sa balit-ad nga indeks. Daghan tingali maghunahuna nga kini yano. Kinsa ang nahibal-an kung unsa ang inverted index ug kung giunsa kini molihok? Oh, dili na kaayo daghang tawo. Atong sulayan nga masabtan kung unsa kini.
Sa pagkatinuod kini yano. Kini usa lamang ka diksyonaryo nga nag-mapa sa usa ka yawe sa usa ka bili. Unsa ang yawe? Kini nga magtiayon label=valuediin label ΠΈ value - kini mga linya. Ug ang mga kantidad usa ka set timeseries_ids, nga naglakip sa gihatag nga pares label=value.
Ang inverted index nagtugot kanimo nga dali nga makit-an ang tanan timeseries_ids, nga naghatag label=value.
Kini usab nagtugot kaninyo sa dali nga pagpangita timeseries_ids serye sa panahon alang sa daghang mga pares label=value, o para sa mga magtiayon label=regexp. Sa unsang paagi kini mahitabo? Pinaagi sa pagpangita sa intersection sa set timeseries_ids alang sa matag pares label=value.
Atong tan-awon ang lain-laing mga pagpatuman sa inverted index. Magsugod ta sa pinakasimple nga walay pulos nga pagpatuman. Ingon ani siya.
function getMetricIDs nakakuha ug lista sa mga kuwerdas. Ang matag linya naglangkob label=value. Kini nga function nagbalik sa usa ka lista metricIDs.
Giunsa kini paglihok? Dinhi kita adunay usa ka global variable nga gitawag invertedIndex. Kini usa ka regular nga diksyonaryo (map), nga mag-mapa sa hilo sa paghiwa sa mga int. Ang linya naglangkob label=value.
Implementasyon sa function: get metricIDs para sa una label=value, unya atong tun-an ang tanan label=value, nakuha namo kini metricIDs alang kanila. Ug tawagan ang function intersectInts, nga hisgotan sa ubos. Ug kini nga function nagbalik sa intersection sa kini nga mga lista.
Sama sa imong nakita, ang pagpatuman sa usa ka balit-ad nga indeks dili kaayo komplikado. Apan kini usa ka walay pulos nga pagpatuman. Unsa ang mga disbentaha niini? Ang nag-unang disbentaha sa walay pulos nga pagpatuman mao nga ang ingon nga balit-ad nga indeks gitipigan sa RAM. Human ma-restart ang aplikasyon mawala kini nga indeks. Walay pagtipig niini nga indeks sa disk. Ang ingon nga usa ka balit-ad nga indeks dili tingali angay alang sa usa ka database.
Ang ikaduha nga disbentaha nalangkit usab sa memorya. Ang inverted index kinahanglan nga mohaum sa RAM. Kung kini molapas sa gidak-on sa RAM, nan klaro nga makuha namon - gikan sa sayup sa memorya. Ug ang programa dili molihok.
Kini nga problema mahimong masulbad gamit ang mga andam nga solusyon sama sa , o .
Sa laktod, nanginahanglan kami usa ka database nga nagtugot kanamo sa paghimo sa tulo nga mga operasyon sa madali.
- Ang unang operasyon mao ang pagrekord
ΠΊΠ»ΡΡ-Π·Π½Π°ΡΠ΅Π½ΠΈΠ΅niini nga database. Gibuhat niya kini nga dali kaayo, diinΠΊΠ»ΡΡ-Π·Π½Π°ΡΠ΅Π½ΠΈΠ΅kay arbitraryong mga kuwerdas. - Ang ikaduha nga operasyon usa ka dali nga pagpangita alang sa usa ka kantidad gamit ang gihatag nga yawe.
- Ug ang ikatulo nga operasyon usa ka dali nga pagpangita alang sa tanan nga mga kantidad pinaagi sa usa ka gihatag nga prefix.
LevelDB ug RocksDB - kini nga mga database gimugna sa Google ug Facebook. Una niabot ang LevelDB. Dayon ang mga lalaki gikan sa Facebook mikuha sa LevelDB ug nagsugod sa pagpalambo niini, naghimo sila og RocksDB. Karon hapit tanan nga mga internal nga database nagtrabaho sa RocksDB sa sulod sa Facebook, lakip ang mga gibalhin sa RocksDB ug MySQL. Ginganlan nila siya .
Ang usa ka balit-ad nga indeks mahimong ipatuman gamit ang LevelDB. Unsaon pagbuhat niini? Nagtipig kami ingon usa ka yawe label=value. Ug ang kantidad mao ang identifier sa serye sa oras kung diin naa ang pares label=value.
Kung kami adunay daghang mga serye sa oras nga adunay gihatag nga pares label=value, unya adunay daghang mga laray niini nga database nga adunay parehas nga yawe ug lahi timeseries_ids. Para makakuha ug lista sa tanan timeseries_ids, nga nagsugod niini label=prefix, naghimo kami usa ka range scan kung diin kini nga database gi-optimize. Kana mao, gipili namo ang tanang linya nga nagsugod label=prefix ug kuhaa ang gikinahanglan timeseries_ids.
Ania ang usa ka sample nga pagpatuman kung unsa ang hitsura niini sa Go. Kami adunay usa ka balit-ad nga indeks. Kini ang LevelDB.
Ang function mao ang sama sa alang sa walay pulos nga pagpatuman. Gisubli niini ang walay pulos nga pagpatuman halos linya sa linya. Ang bugtong punto mao nga imbes nga mobalik sa map atong gi-access ang balit-ad nga indeks. Nakuha namon ang tanan nga mga kantidad alang sa una label=value. Dayon atong tun-an ang tanang nahibilin nga mga pares label=value ug kuhaa ang katugbang nga mga set sa metricIDs alang kanila. Dayon atong makita ang intersection.
Ang tanan ingon og maayo, apan adunay mga kakulangan sa kini nga solusyon. Una nga gipatuman sa VictoriaMetrics ang usa ka balit-ad nga indeks base sa LevelDB. Apan sa katapusan kinahanglan nako nga itugyan kini.
Ngano man? Tungod kay ang LevelDB mas hinay kaysa sa walay pulos nga pagpatuman. Sa usa ka walay pulos nga pagpatuman, nga gihatag sa usa ka gihatag nga yawe, kita diha-diha dayon sa pagkuha sa tibuok slice metricIDs. Kini usa ka paspas kaayo nga operasyon - ang tibuuk nga slice andam na gamiton.
Sa LevelDB, matag higayon nga ang usa ka function gitawag GetValues kinahanglan ka nga moagi sa tanan nga mga linya nga nagsugod sa label=value. Ug kuhaa ang kantidad sa matag linya timeseries_ids. Sa ingon timeseries_ids pagkolekta ug usa ka tipik niini timeseries_ids. Dayag, kini mas hinay kay sa pag-access sa usa ka regular nga mapa pinaagi sa yawe.
Ang ikaduha nga disbentaha mao nga ang LevelDB gisulat sa C. Ang pagtawag sa C function gikan sa Go dili kaayo paspas. Nagkinahanglan kini og gatusan ka nanoseconds. Kini dili kaayo paspas, tungod kay kon itandi sa usa ka regular nga function tawag nga gisulat sa go, nga nagkinahanglan 1-5 nanoseconds, ang kalainan sa performance mao ang napulo ka mga higayon. Alang sa VictoriaMetrics kini usa ka makamatay nga sayup :)
Mao nga gisulat nako ang akong kaugalingon nga pagpatuman sa inverted index. Ug iyang gitawag siya .
Ang Mergeset gibase sa istruktura sa datos sa MergeTree. Kini nga istruktura sa datos gihulam gikan sa ClickHouse. Dayag nga, ang mergeset kinahanglan nga ma-optimize alang sa paspas nga pagpangita timeseries_ids sumala sa gihatag nga yawe. Ang Mergeset kay bug-os nga gisulat sa Go. Makita nimo . Ang pagpatuman sa mergeset naa sa folder . Mahimo nimong sulayan nga mahibal-an kung unsa ang nahitabo didto.
Ang mergeset API susama kaayo sa LevelDB ug RocksDB. Kana mao, gitugotan ka nga dali nga makatipig bag-ong mga rekord didto ug dali nga makapili sa mga rekord pinaagi sa gihatag nga prefix.
Maghisgot kita bahin sa mga disbentaha sa mergeset sa ulahi. Karon atong hisgutan kung unsa nga mga problema ang mitungha sa VictoriaMetrics sa produksiyon kung nagpatuman sa usa ka balit-ad nga indeks.
Nganong mitungha sila?
Ang nag-unang rason mao ang taas nga churn rate. Gihubad sa Russian, kini usa ka kanunay nga pagbag-o sa mga serye sa oras. Kini kung ang usa ka serye sa oras matapos ug usa ka bag-ong serye ang nagsugod, o daghang mga bag-ong serye sa panahon nagsugod. Ug kini mahitabo kanunay.
Ang ikaduha nga hinungdan mao ang daghang gidaghanon sa mga serye sa oras. Sa sinugdanan, sa dihang ang pagmonitor nagkapopular, ang gidaghanon sa mga serye sa panahon gamay ra. Pananglitan, alang sa matag kompyuter kinahanglan nimo nga monitoron ang CPU, memorya, network ug disk load. 4 ka serye sa panahon matag kompyuter. Ingnon ta nga aduna kay 100 ka kompyuter ug 400 ka serye sa panahon. Kini gamay ra kaayo.
Sa paglabay sa panahon, nahibal-an sa mga tawo nga mahimo nilang sukdon ang labi ka detalyado nga kasayuran. Pananglitan, sukda ang load dili sa tibuok processor, apan gilain sa matag processor core. Kung ikaw adunay 40 ka mga core sa processor, nan ikaw adunay 40 ka beses nga mas daghang serye sa oras aron masukod ang load sa processor.
Apan dili lang kana. Ang matag core sa processor mahimong adunay daghang mga estado, sama sa idle, kung kini idle. Ug nagtrabaho usab sa wanang sa tiggamit, nagtrabaho sa wanang sa kernel ug uban pang mga estado. Ug ang matag ingon nga kahimtang mahimo usab nga masukod ingon usa ka lahi nga serye sa oras. Kini dugang nga nagdugang sa gidaghanon sa mga laray sa 7-8 ka beses.
Gikan sa usa ka metric nakakuha kami og 40 x 8 = 320 metrics para sa usa lang ka computer. I-multiply sa 100, makuha nato ang 32 imbes 000.
Unya miabot ang Kubernetes. Ug kini misamot tungod kay ang Kubernetes mahimong mag-host sa daghang lainlaing mga serbisyo. Ang matag serbisyo sa Kubernetes naglangkob sa daghang mga pod. Ug kining tanan kinahanglan nga bantayan. Dugang pa, kami adunay kanunay nga pag-deploy sa mga bag-ong bersyon sa imong mga serbisyo. Alang sa matag bag-ong bersyon, ang bag-ong serye sa oras kinahanglan himuon. Ingon usa ka sangputanan, ang gidaghanon sa mga serye sa oras nga nagdako ug nag-atubang kami sa problema sa daghang mga serye sa oras, nga gitawag nga high-cardinality. Ang VictoriaMetrics malampuson nga nakasagubang niini kon itandi sa ubang mga database sa serye sa panahon.
Atong tan-awon pag-ayo ang taas nga churn rate. Unsay hinungdan sa taas nga churn rate sa produksiyon? Tungod kay ang pipila ka mga kahulugan sa mga label ug mga tag kanunay nga nagbag-o.
Pananglitan, kuhaa ang Kubernetes, nga adunay konsepto deployment, i.e. kung ang usa ka bag-ong bersyon sa imong aplikasyon gilukot. Sa pila ka rason, ang mga developer sa Kubernetes nakahukom nga idugang ang deployment id sa label.
Unsa ang mitultol niini? Dugang pa, sa matag bag-ong pag-deploy, ang tanan nga daan nga serye sa panahon nabalda, ug imbes kanila, ang bag-ong serye sa oras nagsugod sa usa ka bag-ong kantidad sa label deployment_id. Mahimong adunay gatusan ka libo ug bisan milyon-milyon sa ingon nga mga linya.
Ang importante nga butang mahitungod niining tanan mao nga ang kinatibuk-ang gidaghanon sa mga serye sa panahon motubo, apan ang gidaghanon sa mga serye sa panahon nga sa pagkakaron aktibo ug ang pagdawat sa datos nagpabilin nga makanunayon. Kini nga estado gitawag nga high churn rate.
Ang nag-unang problema sa taas nga rate sa churn mao ang pagsiguro sa usa ka makanunayon nga katulin sa pagpangita alang sa tanan nga serye sa oras alang sa usa ka gihatag nga set sa mga label sa usa ka piho nga agwat sa oras. Kasagaran kini ang agwat sa oras sa katapusang oras o katapusang adlaw.
Unsaon pagsulbad kini nga problema? Ania ang unang kapilian. Kini mao ang pagbahin sa inverted index ngadto sa independente nga mga bahin sa paglabay sa panahon. Kana mao, ang pipila ka oras nga agwat sa paglabay, nahuman namon ang pagtrabaho sa karon nga balit-ad nga indeks. Ug paghimo og bag-ong inverted index. Ang laing agwat sa panahon milabay, naghimo kami og lain ug lain.
Ug kung mag-sample gikan niining mga balit-ad nga mga indeks, atong makita ang usa ka hugpong sa mga balit-ad nga mga indeks nga nahulog sulod sa gihatag nga interval. Ug, sumala niana, gipili namon ang id sa serye sa oras gikan didto.
Kini makadaginot sa mga kahinguhaan tungod kay dili na nato kinahanglan pang tan-awon ang mga bahin nga dili masulod sa gihatag nga interval. Kana mao, kasagaran, kon kita mopili sa data alang sa katapusan nga oras, unya alang sa miaging mga agwat sa panahon atong laktawan ang mga pangutana.
Adunay laing kapilian sa pagsulbad niini nga problema. Kini mao ang pagtipig alang sa matag adlaw usa ka bulag nga lista sa mga id sa serye sa oras nga nahitabo nianang adlawa.
Ang bentaha sa kini nga solusyon sa miaging solusyon mao nga dili kami magdoble sa kasayuran sa serye sa oras nga dili mawala sa paglabay sa panahon. Kanunay silang anaa ug dili mausab.
Ang disbentaha mao nga ang ingon nga solusyon mas lisud nga ipatuman ug mas lisud nga i-debug. Ug gipili sa VictoriaMetrics kini nga solusyon. Ingon niini ang nahitabo sa kasaysayan. Kini nga solusyon maayo usab nga nahimo kung itandi sa miaging usa. Tungod kay kini nga solusyon wala gipatuman tungod sa kamatuoran nga gikinahanglan ang pagdoble sa datos sa matag partisyon alang sa mga serye sa panahon nga dili mausab, i.e. nga dili mawala sa paglabay sa panahon. Ang VictoriaMetrics nag-una nga na-optimize alang sa pagkonsumo sa wanang sa disk, ug ang miaging pagpatuman nagpasamot sa pagkonsumo sa wanang sa disk. Apan kini nga pagpatuman mas haum sa pagpamenos sa konsumo sa wanang sa disk, mao nga gipili kini.
Kinahanglan nakong awayon siya. Ang pakigbisog mao nga sa kini nga pagpatuman kinahanglan nimo nga mopili usa ka labi ka daghan nga numero timeseries_ids alang sa data kay sa diha nga ang balit-ad nga index mao ang panahon partitioned.
Giunsa namo pagsulbad kini nga problema? Gisulbad namo kini sa orihinal nga paagi - pinaagi sa pagtago ug daghang time series identifier sa matag balit-ad nga index entry imbes sa usa ka identifier. Sa ato pa, naa tay yawe label=value, nga mahitabo sa matag serye sa panahon. Ug karon nagtipig kami og daghan timeseries_ids sa usa ka entry.
Ania ang usa ka pananglitan. Kaniadto kami adunay N entries, apan karon kami adunay usa ka entry kansang prefix parehas sa tanan. Alang sa miaging entry, ang bili naglangkob sa tanang time series id.
Naghimo kini nga posible nga madugangan ang katulin sa pag-scan sa ingon nga balit nga indeks hangtod sa 10 ka beses. Ug kini nagtugot kanamo sa pagpakunhod sa konsumo sa panumduman alang sa cache, tungod kay karon among gitipigan ang pisi label=value kausa ra sa cache nga magkauban N ka beses. Ug kini nga linya mahimong dako kung magtipig ka ug tag-as nga mga linya sa imong mga tag ug label, nga gusto sa mga Kubernetes nga ibutang didto.
Ang laing kapilian sa pagpadali sa pagpangita sa inverted index mao ang sharding. Paghimo og daghang mga inverted index imbes sa usa ug sharding data tali kanila pinaagi sa yawe. Kini usa ka set key=value alisngaw. Sa ato pa, nakakuha kami daghang mga independente nga inverted index, nga mahimo namon nga pangutana nga managsama sa daghang mga processor. Gitugotan lang sa mga nangaging pagpatuman ang operasyon sa single-processor mode, i.e., pag-scan sa datos sa usa lang ka core. Kini nga solusyon nagtugot kanimo sa pag-scan sa datos sa daghang mga cores sa usa ka higayon, sama sa ClickHouse ganahan nga buhaton. Kini ang among giplano nga ipatuman.
Karon mobalik kita sa atong mga karnero - sa intersection function timeseries_ids. Atong tagdon kung unsa nga mga implementasyon ang mahimo. Kini nga function nagtugot kanimo sa pagpangita timeseries_ids alang sa gihatag nga set label=value.
Ang unang kapilian mao ang usa ka walay pulos nga pagpatuman. Duha ka nested loops. Dinhi atong makuha ang function input intersectInts duha ka hiwa- a ΠΈ b. Sa output, kini kinahanglan nga mobalik kanato sa intersection niini nga mga hiwa.
Ang usa ka walay pulos nga pagpatuman ingon niini. Gisubli namon ang tanan nga mga kantidad gikan sa slice a, sa sulod niini nga loop atong gisusi ang tanan nga mga kantidad sa slice b. Ug atong itandi sila. Kung magkatugma sila, nan nakit-an namon ang usa ka intersection. Ug i-save kini result.
Unsa ang mga disbentaha? Ang quadratic complexity mao ang nag-unang disbentaha niini. Pananglitan, kung ang imong mga sukat usa ka slice a ΠΈ b usa ka milyon sa usa ka higayon, nan kini nga function dili na magbalik ug tubag kanimo. Tungod kay kinahanglan kini maghimo usa ka trilyon nga mga pag-uli, nga labi ka daghan bisan alang sa mga modernong kompyuter.
Ang ikaduhang pagpatuman gibase sa mapa. Naghimo kami og mapa. Gibutang namon ang tanan nga mga kantidad gikan sa slice sa kini nga mapa a. Unya kita moagi sa slice sa usa ka bulag nga loop b. Ug among susihon kung kini nga kantidad gikan sa slice b sa mapa. Kon kini anaa, unya idugang kini sa resulta.
Unsa ang mga kaayohan? Ang bentaha mao nga adunay lamang linear nga pagkakomplikado. Kana mao, ang function mopatuman sa mas paspas alang sa dagkong mga hiwa. Alang sa usa ka milyon nga gidak-on nga slice, kini nga function ipatuman sa 2 milyon nga mga pag-uli, sukwahi sa trilyon nga mga pag-usab sa miaging function.
Ang downside mao nga kini nga function nanginahanglan dugang nga memorya sa paghimo niini nga mapa.
Ang ikaduha nga disbentaha mao ang dako nga overhead alang sa hashing. Kini nga disbentaha dili kaayo klaro. Ug alang kanamo dili usab kini klaro, mao nga sa una sa VictoriaMetrics ang pagpatuman sa intersection pinaagi sa usa ka mapa. Apan ang profiling nagpakita nga ang nag-unang oras sa processor gigugol sa pagsulat sa mapa ug pagsusi sa presensya sa usa ka bili niini nga mapa.
Ngano nga ang oras sa CPU nausik sa kini nga mga lugar? Tungod kay si Go nagpahigayon og hashing nga operasyon niini nga mga linya. Sa ato pa, gikalkula niini ang hash sa yawe aron ma-access kini sa gihatag nga indeks sa HashMap. Ang operasyon sa pagkalkula sa hash nahuman sa napulo ka nanoseconds. Kini hinay alang sa VictoriaMetrics.
Nakahukom ko nga ipatuman ang usa ka bitset nga na-optimize para sa kini nga kaso. Mao kini ang hitsura karon sa intersection sa duha ka hiwa. Dinhi naghimo kami usa ka bitset. Gidugang namon ang mga elemento gikan sa una nga hiwa niini. Dayon atong susihon ang presensya niini nga mga elemento sa ikaduhang hiwa. Ug idugang sila sa resulta. Sa ato pa, halos walay kalainan sa miaging pananglitan. Ang bugtong butang dinhi mao nga gipulihan namon ang pag-access sa mapa gamit ang naandan nga mga gimbuhaton add ΠΈ has.
Sa una nga pagtan-aw, kini daw kinahanglan nga molihok nga mas hinay, kung kaniadto usa ka standard nga mapa ang gigamit didto, ug unya ang uban nga mga function gitawag, apan ang profiling nagpakita nga kini nga butang molihok 10 ka beses nga mas paspas kaysa sa standard nga mapa sa kaso sa VictoriaMetrics.
Dugang pa, gigamit niini ang labi ka gamay nga memorya kung itandi sa pagpatuman sa mapa. Tungod kay nagtipig kami og mga piraso dinhi imbes nga walo ka byte nga mga kantidad.
Ang disbentaha sa kini nga pagpatuman mao nga kini dili kaayo dayag, dili gamay.
Ang laing disbentaha nga dili mamatikdan sa kadaghanan mao nga kini nga pagpatuman mahimong dili maayo sa pipila ka mga kaso. Kana mao, kini gi-optimize alang sa usa ka piho nga kaso, alang niini nga kaso sa intersection sa VictoriaMetrics time series id. Wala kini magpasabut nga kini angay alang sa tanan nga mga kaso. Kung kini gigamit nga dili husto, dili kita makakuha og pagtaas sa performance, apan usa ka out of memory error ug usa ka paghinay sa performance.
Atong tagdon ang pagpatuman niini nga istruktura. Kung gusto nimo tan-awon, kini nahimutang sa mga tinubdan sa VictoriaMetrics, sa folder . Gi-optimize kini ilabi na alang sa kaso sa VictoriaMetrics, diin timeseries_id mao ang usa ka 64-bit nga bili, diin ang unang 32 ka bits mao ang batakan nga makanunayon ug ang katapusan nga 32 bits lamang ang mausab.
Kini nga istruktura sa datos wala gitipigan sa disk, naglihok lamang kini sa memorya.
Ania ang API niini. Dili kaayo komplikado. Ang API espesipikong gipahaum sa usa ka piho nga pananglitan sa paggamit sa VictoriaMetrics. Sa ato pa, walaβy wala kinahanglana nga mga gimbuhaton dinhi. Ania ang mga gimbuhaton nga klaro nga gigamit sa VictoriaMetrics.
Adunay mga gimbuhaton add, nga nagdugang bag-ong mga kantidad. Adunay usa ka function has, nga nagsusi sa bag-ong mga bili. Ug adunay usa ka function del, nga nagtangtang sa mga kantidad. Adunay usa ka function sa katabang len, nga nagbalik sa gidak-on sa set. Kalihokan clone daghan clones. Ug function appendto nag-convert niini nga set ngadto sa slice timeseries_ids.
Mao kini ang hitsura sa pagpatuman niini nga istruktura sa datos. Ang set adunay duha ka elemento:
-
ItemsCountusa ka field sa katabang aron dali nga ibalik ang gidaghanon sa mga elemento sa usa ka set. Posible nga buhaton kung wala kini nga auxiliary field, apan kinahanglan kini idugang dinhi tungod kay ang VictoriaMetrics kanunay nga nagpangutana sa gitas-on sa bitset sa mga algorithm niini. -
Ang ikaduhang field mao ang
buckets. Kini usa ka hiwa gikan sa istrukturabucket32. Ang matag istruktura nagtipighikapatagan. Kini ang taas nga 32 bits. Ug duha ka hiwa -b16hisΠΈbucketsgikan sabucket16mga istruktura.
Ang top 16 bits sa ikaduhang bahin sa 64-bit structure gitipigan dinhi. Ug dinhi ang mga bitset gitipigan alang sa ubos nga 16 ka bit sa matag byte.
Bucket64 naglangkob sa usa ka array uint64. Ang gitas-on gikalkulo gamit kini nga mga kanunay. Sa usa bucket16 maximum mahimong tipigan 2^16=65536 gamay. Kung imong bahinon kini sa 8, nan kini 8 kilobytes. Kung bahinon nimo sa 8 pag-usab, kini 1000 uint64 kahulogan. Kana mao Bucket16 β kini ang among 8-kilobyte nga istruktura.
Atong tan-awon kung giunsa ang usa sa mga pamaagi sa kini nga istruktura alang sa pagdugang usa ka bag-ong kantidad gipatuman.
Nagsugod ang tanan sa uint64 mga kahulugan. Gikalkula namon ang taas nga 32 bits, gikalkula namon ang ubos nga 32 bits. Atong agian ang tanan buckets. Atong itandi ang top 32 bits sa matag balde uban sa bili nga gidugang. Ug kung sila magkatugma, unya gitawag namon ang function add sa istruktura b32 buckets. Ug idugang ang ubos nga 32 bits didto. Ug kung nibalik true, nan kini nagpasabot nga kami midugang sa ingon nga bili didto ug kami walay ingon nga bili. Kung mubalik false, unya naglungtad na ang maong kahulogan. Dayon atong dugangan ang gidaghanon sa mga elemento sa istruktura.
Kung wala namo nakit-an ang imong gikinahanglan bucket uban ang gikinahanglan nga hi-value, unya gitawag nato ang function addAlloc, nga magpatunghag bag-o bucket, idugang kini sa istruktura sa balde.
Kini ang pagpatuman sa function b32.add. Kini susama sa miaging pagpatuman. Gikalkulo namo ang labing mahinungdanon nga 16 ka bit, ang pinakagamay nga 16 ka bit.
Unya kita moagi sa tanan nga mga ibabaw nga 16 bits. Nangita mig mga posporo. Ug kung adunay usa ka panagsama, gitawag namon ang pamaagi sa pagdugang, nga among hisgotan sa sunod nga panid bucket16.
Ug ania ang labing ubos nga lebel, nga kinahanglan nga ma-optimize kutob sa mahimo. Among kuwentahon para uint64 id nga kantidad sa slice bit ug usab bitmask. Kini usa ka maskara alang sa gihatag nga 64-bit nga kantidad, nga magamit aron masusi ang presensya niini nga bit, o itakda kini. Among susihon aron makita kung kini nga bit gitakda ug gitakda kini, ug ibalik ang presensya. Kini ang among pagpatuman, nga nagtugot kanamo nga mapadali ang operasyon sa mga intersecting id sa serye sa oras sa 10 ka beses kung itandi sa naandan nga mga mapa.
Dugang sa kini nga pag-optimize, ang VictoriaMetrics adunay daghang uban pang mga pag-optimize. Kadaghanan sa kini nga mga pag-optimize gidugang alang sa usa ka hinungdan, apan pagkahuman sa pag-profile sa code sa produksiyon.
Kini ang panguna nga lagda sa pag-optimize - ayaw pagdugang pag-optimize kung adunay usa ka bottleneck dinhi, tungod kay mahimoβg walaβy bottleneck didto. Ang pag-optimize kasagarang makapaubos sa kalidad sa code. Busa, kini angay nga pag-optimize lamang human sa pag-profile ug mas maayo sa produksyon, aron kini tinuod nga datos. Kung adunay interesado, mahimo nimong tan-awon ang source code sa VictoriaMetrics ug susihon ang ubang mga pag-optimize nga naa didto.
Naa koy pangutana bahin sa bitset. Susama kaayo sa pagpatuman sa C++ vector bool, na-optimize nga bitset. Gikuha ba nimo ang pagpatuman gikan didto?
Dili, dili gikan didto. Kung gipatuman kini nga bitset, gigiyahan ako sa kahibalo sa istruktura sa kini nga mga timeseries sa mga id, nga gigamit sa VictoriaMetrics. Ug ang ilang gambalay mao nga ang ibabaw nga 32 bits batakan kanunay. Ang ubos nga 32 bits mahimong usbon. Kon mas ubos ang gamay, mas kanunay kini mausab. Busa, kini nga pagpatuman espesipikong na-optimize alang niini nga istruktura sa datos. Ang pagpatuman sa C ++, sa akong nahibal-an, gi-optimize alang sa kinatibuk-ang kaso. Kung mag-optimize ka alang sa kinatibuk-ang kaso, kini nagpasabut nga dili kini ang labing kamalaumon alang sa usa ka piho nga kaso.
Gitambagan ko usab ikaw nga tan-awon ang taho ni Alexey Milovid. Mga usa ka bulan ang milabay, naghisgot siya bahin sa pag-optimize sa ClickHouse alang sa piho nga mga espesyalista. Giingon lang niya nga sa kinatibuk-ang kaso, ang usa ka pagpatuman sa C ++ o uban pa nga pagpatuman gipahaum aron molihok nga maayo sa kasagaran sa usa ka ospital. Mahimong mas grabe pa kini kaysa usa ka pagpatuman nga piho sa kahibalo sama sa amon, diin nahibal-an namon nga ang labing taas nga 32 bits kasagaran kanunay.
Naa koy ikaduhang pangutana. Unsa ang sukaranan nga kalainan gikan sa InfluxDB?
Adunay daghang sukaranan nga mga kalainan. Sa mga termino sa pasundayag ug pagkonsumo sa panumduman, ang InfluxDB sa mga pagsulay nagpakita sa 10 ka beses nga labi ka konsumo sa memorya alang sa taas nga serye sa oras sa kardinal, kung daghan ka niini, pananglitan, milyon-milyon. Pananglitan, ang VictoriaMetrics naggamit sa 1 GB matag milyon nga aktibo nga mga laray, samtang ang InfluxDB naggamit sa 10 GB. Ug kana usa ka dako nga kalainan.
Ang ikaduha nga sukaranan nga kalainan mao nga ang InfluxDB adunay katingad-an nga mga sinultian nga pangutana - Flux ug InfluxQL. Dili kaayo sila kombenyente alang sa pagtrabaho kauban ang mga serye sa oras kung itandi sa , nga gisuportahan sa VictoriaMetrics. Ang PromQL usa ka pangutana nga lengguwahe gikan sa Prometheus.
Ug ang usa pa nga kalainan mao nga ang InfluxDB adunay usa ka gamay nga katingad-an nga modelo sa datos, diin ang matag linya makatipig daghang mga natad nga adunay lainlaing hugpong sa mga tag. Kini nga mga linya gibahin pa sa lainlaing mga lamesa. Kining dugang nga mga komplikasyon nagpakomplikado sa sunod nga trabaho niini nga database. Lisod suportahan ug sabton.
Sa VictoriaMetrics ang tanan mas simple. Didto, ang matag serye sa oras usa ka hinungdanon nga kantidad. Ang bili usa ka hugpong sa mga punto - (timestamp, value), ug ang yawe mao ang set label=value. Walay panagbulag tali sa mga natad ug mga sukod. Gitugotan ka niini sa pagpili sa bisan unsang datos ug dayon paghiusa, pagdugang, pag-ubos, pagpadaghan, pagbahin, dili sama sa InfluxDB diin ang mga kalkulasyon tali sa lainlaing mga linya wala gihapon gipatuman sa akong nahibal-an. Bisan kung kini gipatuman, lisud, kinahanglan nimo nga isulat ang daghang code.
Naa koy pangutana nga makapatin-aw. Nakasabot ba ko sa husto nga adunay usa ka matang sa problema nga imong gihisgutan, nga kini nga balit-ad nga indeks dili mohaum sa panumduman, mao nga adunay partitioning didto?
Una, gipakita nako ang usa ka walay pulos nga pagpatuman sa usa ka balit-ad nga indeks sa usa ka standard nga mapa sa Go. Kini nga pagpatuman dili angay alang sa mga database tungod kay kini nga balit-ad nga index wala ma-save sa disk, ug ang database kinahanglan nga i-save sa disk aron kini nga datos magpabilin nga magamit sa pagsugod pag-usab. Niini nga pagpatuman, kung imong i-restart ang aplikasyon, ang imong balit-ad nga indeks mawala. Ug mawad-an ka og access sa tanan nga datos tungod kay dili nimo kini makit-an.
Hello! Salamat sa report! Ako diay si Pavel. Gikan ko sa Wildberries. Naa koy pipila ka pangutana para nimo. Pangutana uno. Naghunahuna ka ba nga kung gipili nimo ang usa ka lahi nga prinsipyo sa pagtukod sa arkitektura sa imong aplikasyon ug gibahin ang datos sa paglabay sa panahon, nan tingali nakahimo ka sa pag-intersect sa datos sa pagpangita, base lamang sa kamatuoran nga ang usa ka partisyon naglangkob sa datos alang sa usa yugto sa panahon, nga mao, sa usa ka agwat sa oras ug dili ka kinahanglan mabalaka bahin sa kamatuoran nga ang imong mga piraso nagkatag sa lahi nga paagi? Pangutana numero 2 - tungod kay nagpatuman ka usa ka parehas nga algorithm nga adunay bitset ug tanan pa, nan tingali gisulayan nimo ang paggamit sa mga panudlo sa processor? Tingali nasulayan na nimo ang ingon nga mga pag-optimize?
Tubagon ko dayon ang ikaduha. Wala pa ta niabot ana nga point. Apan kung gikinahanglan, makaabot kami didto. Ug ang una, unsa ang pangutana?
Duha ka senaryo ang imong gihisgutan. Ug giingon nila nga gipili nila ang ikaduha nga adunay labi ka komplikado nga pagpatuman. Ug dili nila gusto ang una, diin ang datos gibahin sa oras.
Oo. Sa una nga kaso, ang kinatibuk-ang gidaghanon sa indeks mahimong mas dako, tungod kay sa matag partisyon kinahanglan namon nga tipigan ang doble nga datos alang sa mga serye sa oras nga nagpadayon sa tanan nga mga partisyon. Ug kung ang imong time series churn rate gamay ra, i.e. ang parehas nga serye kanunay nga gigamit, nan sa una nga kaso mas mawad-an kami sa gidaghanon sa disk space nga giokupar kumpara sa ikaduha nga kaso.
Ug busa - oo, ang pagbahin sa oras usa ka maayong kapilian. Gigamit kini ni Prometheus. Apan ang Prometheus adunay laing kakulian. Kung gihiusa kini nga mga piraso sa datos, kinahanglan nga ibutang sa memorya ang meta nga impormasyon alang sa tanan nga mga label ug mga serye sa panahon. Busa, kung ang mga piraso sa datos nga gihiusa niini dako, nan ang pagkonsumo sa panumduman modaghan pag-ayo sa panahon sa paghiusa, dili sama sa VictoriaMetrics. Kung maghiusa, ang VictoriaMetrics dili gyud mogamit sa memorya; duha ra ka kilobytes ang nahurot, bisan unsa pa ang gidak-on sa gisagol nga mga piraso sa datos.
Ang algorithm nga imong gigamit naggamit sa memorya. Kini nagtimaan sa mga timeseries tag nga adunay mga kantidad. Ug niining paagiha imong susihon ang gipares nga presensya sa usa ka laray sa datos ug sa lain. Ug nasabtan nimo kung ang intersect nahitabo o wala. Kasagaran, ang mga database nag-implementar sa mga cursor ug mga iterator nga nagtipig sa ilang kasamtangan nga sulud ug nagdagan pinaagi sa gisunud nga datos tungod sa yano nga pagkakomplikado niini nga mga operasyon.
Ngano nga dili kami mogamit mga cursor sa pagtabok sa datos?
Oo.
Gitipigan namo ang mga han-ay nga mga laray sa LevelDB o mergeset. Mahimo natong ibalhin ang cursor ug pangitaon ang intersection. Nganong dili nato kini gamiton? Kay hinay. Tungod kay ang mga cursor nagpasabut nga kinahanglan nimo nga tawagan ang usa ka function alang sa matag linya. Ang usa ka function nga tawag mao ang 5 nanoseconds. Ug kung ikaw adunay 100 nga mga linya, nan kini mogawas nga kami mogugol ug tunga sa segundo sa pagtawag sa function.
Adunay ingon niana, oo. Ug ang akong katapusang pangutana. Ang pangutana tingali medyo katingad-an. Ngano nga dili posible nga basahon ang tanan nga gikinahanglan nga mga aggregate sa higayon nga ang data moabut ug i-save kini sa gikinahanglan nga porma? Ngano nga magtipig ug daghang mga volume sa pipila nga mga sistema sama sa VictoriaMetrics, ClickHouse, ug uban pa, ug dayon mogahin og daghang oras sa kanila?
Maghatag ako usa ka pananglitan aron mas klaro. Ingnon ta kung giunsa ang usa ka gamay nga dulaan nga speedometer? Kini nagrekord sa gilay-on nga imong nabiyahe, sa tanang panahon nga idugang kini sa usa ka bili, ug ang ikaduha nga higayon. Ug nagbahin. Ug nakakuha sa kasagaran nga tulin. Mahimo nimong buhaton ang parehas nga butang. Idugang ang tanan nga gikinahanglan nga mga kamatuoran sa langaw.
Okay, nakasabot ko sa pangutana. Ang imong ehemplo adunay iyang lugar. Kung nahibal-an nimo kung unsang mga aggregate ang imong kinahanglan, nan kini ang labing kaayo nga pagpatuman. Apan ang problema mao nga ang mga tawo nagluwas niini nga mga sukdanan, ang pipila ka mga datos sa ClickHouse ug wala pa sila mahibal-an kung giunsa nila pag-aggregate ug pagsala kini sa umaabot, mao nga kinahanglan nila nga i-save ang tanan nga hilaw nga datos. Apan kung nahibal-an nimo nga kinahanglan nimo nga kalkulahon ang usa ka butang sa aberids, nan nganong dili nimo kini kuwentahon imbes nga magtago sa usa ka hugpong sa mga hilaw nga kantidad didto? Apan kini mao lamang kung nahibal-an nimo kung unsa ang imong kinahanglan.
Pinaagi sa dalan, ang mga database alang sa pagtipig sa mga serye sa oras nagsuporta sa pag-ihap sa mga aggregate. Pananglitan, gisuportahan ni Prometheus . Sa ato pa, mahimo kini kung nahibal-an nimo kung unsang mga yunit ang kinahanglan nimo. Ang VictoriaMetrics wala pa niini, apan kasagaran kini giunhan sa Prometheus, diin mahimo kini sa mga lagda sa pag-recode.
Pananglitan, sa akong miaging trabaho kinahanglan nako nga ihap ang gidaghanon sa mga panghitabo sa usa ka sliding window sa miaging oras. Ang problema mao nga kinahanglan kong maghimo usa ka naandan nga pagpatuman sa Go, i.e. usa ka serbisyo alang sa pag-ihap niini nga butang. Kini nga serbisyo sa katapusan dili hinungdanon, tungod kay lisud ang pagkalkulo. Mahimong yano ang pagpatuman kung kinahanglan nimo nga mag-ihap sa pipila nga mga aggregate sa gitakda nga mga agwat sa oras. Kung gusto nimo mag-ihap sa mga panghitabo sa usa ka sliding window, nan kini dili ingon kasayon ββββsa ingon. Sa akong hunahuna wala pa kini gipatuman sa ClickHouse o sa mga database sa timeseries, tungod kay lisud kini ipatuman.
Ug usa pa ka pangutana. Naghisgot lang kami bahin sa pag-average, ug nahinumdom ko nga kaniadto adunay usa ka butang sama sa Graphite nga adunay backend sa Carbon. Ug nahibal-an niya kung unsaon pag-manipis ang daan nga datos, nga mao, pagbilin usa ka punto matag minuto, usa ka punto matag oras, ug uban pa. magpanipis. Apan wala gisuportahan sa Prometheus ug VictoriaMetrics kini nga pagpaandar. Giplano ba kini nga suportahan kini? Kung dili, nganong dili?
Salamat sa pangutana. Gipangutana kini sa among mga tiggamit matag karon ug unya. Nangutana sila kung kanus-a kami magdugang suporta alang sa pag-downsampling. Adunay daghang mga problema dinhi. Una, nasabtan sa matag tiggamit downsampling usa ka butang nga lahi: adunay gusto nga makakuha bisan unsang arbitraryong punto sa usa ka gilay-on, adunay gusto nga labing taas, minimum, kasagaran nga mga kantidad. Kung daghang mga sistema ang nagsulat sa datos sa imong database, nan dili nimo kini mahiusa. Mahimo nga ang matag sistema nanginahanglan lainlaing pagnipis. Ug lisod kining ipatuman.
Ug ang ikaduha nga butang mao nga ang VictoriaMetrics, sama sa ClickHouse, gi-optimize alang sa pagtrabaho sa daghang mga hilaw nga datos, aron mahimo kini nga pala sa usa ka bilyon nga linya sa walaβy usa ka segundo kung adunay ka daghang mga core sa imong sistema. Pag-scan sa mga punto sa serye sa oras sa VictoriaMetrics - 50 puntos matag segundo matag core. Ug kini nga pasundayag nga mga timbangan sa kasamtangan nga mga cores. Kana mao, kung ikaw adunay 000 ka mga core, pananglitan, mag-scan ka usa ka bilyon nga puntos matag segundo. Ug kini nga kabtangan sa VictoriaMetrics ug ClickHouse nagpamenos sa panginahanglan alang sa downsamling.
Ang laing bahin mao nga ang VictoriaMetrics epektibo nga nag-compress niini nga datos. Ang compression sa kasagaran sa produksiyon gikan sa 0,4 hangtod 0,8 bytes matag punto. Ang matag punto kay timestamp + value. Ug kini gi-compress ngadto sa ubos sa usa ka byte sa kasagaran.
Sergey. Naa ko'y pangutana. Unsa ang minimum nga oras sa pagrekord nga quantum?
Usa ka millisecond. Bag-ohay lang nga nakigsulti kami sa ubang mga developer sa database sa serye sa oras. Ang ilang minimum nga time slice usa ka segundo. Ug sa Graphite, pananglitan, usa usab kini ka segundo. Sa OpenTSDB usa usab kini ka segundo. Ang InfluxDB adunay nanosecond nga katukma. Sa VictoriaMetrics kini usa ka millisecond, tungod kay sa Prometheus usa kini ka millisecond. Ug ang VictoriaMetrics orihinal nga naugmad ingon hilit nga pagtipig alang sa Prometheus. Apan karon kini makaluwas sa datos gikan sa ubang mga sistema.
Ang tawo nga akong nakigsulti nag-ingon nga sila adunay ikaduha-sa-ikaduha nga katukma - kana igo na alang kanila tungod kay kini nagdepende sa tipo sa datos nga gitipigan sa database sa serye sa oras. Kung kini ang datos sa DevOps o datos gikan sa imprastraktura, diin imong kolektahon kini sa mga agwat sa 30 segundos, matag minuto, unya igo na ang ikaduha nga katukma, dili nimo kinahanglan ang bisan unsa nga gamay. Ug kung imong kolektahon kini nga datos gikan sa mga high frequency trading system, nan kinahanglan nimo ang nanosecond accuracy.
Ang katukma sa Millisecond sa VictoriaMetrics angay usab alang sa kaso sa DevOps, ug mahimong angay alang sa kadaghanan sa mga kaso nga akong gihisgutan sa sinugdanan sa taho. Ang bugtong butang nga dili kini angay mao ang taas nga frequency nga mga sistema sa pamatigayon.
Salamat! Ug laing pangutana. Unsa ang pagkaangay sa PromQL?
Bug-os nga backward compatibility. Ang VictoriaMetrics hingpit nga nagsuporta sa PromQL. Dugang pa, nagdugang kini og dugang nga advanced functionality sa PromQL, nga gitawag . Adunay usa ka pakigpulong sa YouTube bahin niining gipalapdan nga pagpaandar. Namulong ko sa Monitoring Meetup sa tingpamulak sa St. Petersburg.
Channel sa Telegram .
Ang mga rehistradong tiggamit lamang ang makaapil sa survey. , walay sapayan.
Unsa ang nakapugong kanimo sa pagbalhin sa VictoriaMetrics ingon imong dugay nga pagtipig alang sa Prometheus? (Isulat sa mga komento, idugang ko kini sa poll))
-
71,4%Dili nako gamiton ang Prometheus5
-
28,6%Wala kahibalo bahin sa VictoriaMetrics2
7 ka tiggamit ang nagboto. 12 ka tiggamit ang nag-abstain.
Source: www.habr.com