Awgrymaf ichi ddarllen trawsgrifiad adroddiad hwyr 2019 gan Alexander Valyalkin “Go optimizations in VictoriaMetrics”
- DBMS cyflym a graddadwy ar gyfer storio a phrosesu data ar ffurf cyfres amser (mae'r cofnod yn ffurfio amser a set o werthoedd sy'n cyfateb i'r amser hwn, er enghraifft, a geir trwy arolygon cyfnodol o statws synwyryddion neu gasglu metrigau).
Dyma ddolen i’r fideo o’r adroddiad hwn -
Dywedwch wrthym amdanoch chi'ch hun. Alexander Valyalkin ydw i. Yma . Rwy'n angerddol am Go ac optimeiddio perfformiad. Ysgrifennais lawer o lyfrgelloedd defnyddiol a ddim yn ddefnyddiol iawn. Maen nhw'n dechrau gyda'r naill neu'r llall fast, neu gyda quick rhagddodiad.
Ar hyn o bryd rwy'n gweithio ar VictoriaMetrics. Beth ydyw a beth ydw i'n ei wneud yno? Byddaf yn siarad am hyn yn y cyflwyniad hwn.
Mae amlinelliad yr adroddiad fel a ganlyn:
- Yn gyntaf, dywedaf wrthych beth yw VictoriaMetrics.
- Yna byddaf yn dweud wrthych beth yw cyfresi amser.
- Yna byddaf yn dweud wrthych sut mae cronfa ddata cyfres amser yn gweithio.
- Nesaf, dywedaf wrthych am bensaernïaeth y gronfa ddata: yr hyn y mae'n ei gynnwys.
- Ac yna gadewch i ni symud ymlaen at yr optimeiddiadau sydd gan VictoriaMetrics. Mae hwn yn optimeiddio ar gyfer y mynegai gwrthdro ac yn optimeiddio ar gyfer gweithredu bitset yn Go.
Oes rhywun yn y gynulleidfa yn gwybod beth yw VictoriaMetrics? Waw, mae llawer o bobl yn gwybod yn barod. Mae'n newyddion da. I'r rhai nad ydyn nhw'n gwybod, cronfa ddata cyfres amser yw hon. Mae'n seiliedig ar bensaernïaeth ClickHouse, ar rai manylion am weithrediad ClickHouse. Er enghraifft, ar megis: MergeTree, cyfrifiad cyfochrog ar yr holl greiddiau prosesydd sydd ar gael ac optimeiddio perfformiad trwy weithio ar flociau data sy'n cael eu gosod yn storfa'r prosesydd.
Mae VictoriaMetrics yn darparu gwell cywasgu data na chronfeydd data cyfresi amser eraill.
Mae'n graddio'n fertigol - hynny yw, gallwch chi ychwanegu mwy o broseswyr, mwy o RAM ar un cyfrifiadur. Bydd VictoriaMetrics yn defnyddio'r adnoddau hyn sydd ar gael yn llwyddiannus ac yn gwella cynhyrchiant llinol.
Mae VictoriaMetrics hefyd yn graddio'n llorweddol - hynny yw, gallwch ychwanegu nodau ychwanegol at y clwstwr VictoriaMetrics, a bydd ei berfformiad yn cynyddu bron yn llinol.
Fel y gwnaethoch ddyfalu, mae VictoriaMetrics yn gronfa ddata gyflym, oherwydd ni allaf ysgrifennu rhai eraill. Ac mae wedi'i ysgrifennu yn Go, felly rwy'n siarad amdano yn y cyfarfod hwn.
Pwy a wyr beth yw cyfres amser? Mae hefyd yn adnabod llawer o bobl. Cyfres o barau yw cyfres amser (timestamp, значение), lle mae'r parau hyn yn cael eu didoli yn ôl amser. Mae'r gwerth yn rhif pwynt arnawf - arnofio64.
Mae pob cyfres tro yn cael ei nodi'n unigryw gan allwedd. Beth mae'r allwedd hon yn ei gynnwys? Mae'n cynnwys set nad yw'n wag o barau gwerth allweddol.
Dyma enghraifft o gyfres amser. Allwedd y gyfres hon yw rhestr o barau: __name__="cpu_usage" yw enw'r metrig, instance="my-server" - dyma'r cyfrifiadur y mae'r metrig hwn yn cael ei gasglu arno, datacenter="us-east" - dyma'r ganolfan ddata lle mae'r cyfrifiadur hwn wedi'i leoli.
Yn y diwedd, cawsom enw cyfres amser yn cynnwys tri phâr o werth allweddol. Mae'r allwedd hon yn cyfateb i restr o barau (timestamp, value). t1, t3, t3, ..., tN - stampiau amser yw'r rhain, 10, 20, 12, ..., 15 — y gwerthoedd cyfatebol. Dyma'r defnydd cpu ar amser penodol ar gyfer rhes benodol.
Ble gellir defnyddio cyfresi amser? Oes gan unrhyw un syniad?
- Yn DevOps, gallwch fesur CPU, RAM, rhwydwaith, rps, nifer y gwallau, ac ati.
- IoT - gallwn fesur tymheredd, pwysedd, cyfesurynnau geo a rhywbeth arall.
- Hefyd cyllid – gallwn fonitro prisiau ar gyfer pob math o stociau ac arian cyfred.
- Yn ogystal, gellir defnyddio cyfresi amser wrth fonitro prosesau cynhyrchu mewn ffatrïoedd. Mae gennym ddefnyddwyr sy'n defnyddio VictoriaMetrics i fonitro tyrbinau gwynt, ar gyfer robotiaid.
- Mae cyfresi amser hefyd yn ddefnyddiol ar gyfer casglu gwybodaeth o synwyryddion dyfeisiau amrywiol. Er enghraifft, ar gyfer injan; ar gyfer mesur pwysedd teiars; ar gyfer mesur cyflymder, pellter; ar gyfer mesur defnydd gasoline, ac ati.
- Gellir defnyddio cyfresi amser hefyd i fonitro awyrennau. Mae gan bob awyren flwch du sy'n casglu cyfresi amser ar gyfer paramedrau amrywiol iechyd yr awyren. Defnyddir cyfresi amser hefyd yn y diwydiant awyrofod.
- Gofal iechyd yw pwysedd gwaed, pwls, ac ati.
Efallai bod mwy o gymwysiadau yr anghofiais amdanynt, ond gobeithio eich bod yn deall bod cyfresi amser yn cael eu defnyddio'n weithredol yn y byd modern. Ac mae maint eu defnydd yn tyfu bob blwyddyn.
Pam mae angen cronfa ddata cyfres amser arnoch chi? Pam na allwch chi ddefnyddio cronfa ddata berthynol reolaidd i storio cyfresi amser?
Oherwydd bod cyfresi amser fel arfer yn cynnwys llawer iawn o wybodaeth, sy'n anodd ei storio a'i phrosesu mewn cronfeydd data confensiynol. Felly, ymddangosodd cronfeydd data arbenigol ar gyfer cyfresi amser. Mae'r seiliau hyn yn storio pwyntiau yn effeithiol (timestamp, value) gyda'r allwedd a roddwyd. Maent yn darparu API ar gyfer darllen data sydd wedi'i storio fesul allwedd, gan bâr gwerth bysell sengl, neu gan barau gwerth allwedd lluosog, neu drwy regexp. Er enghraifft, rydych chi am ddod o hyd i lwyth CPU eich holl wasanaethau mewn canolfan ddata yn America, yna mae angen i chi ddefnyddio'r ffug-ymholiad hwn.
Yn nodweddiadol mae cronfeydd data cyfres amser yn darparu ieithoedd ymholiad arbenigol oherwydd nid yw cyfresi amser SQL yn addas iawn. Er bod cronfeydd data sy'n cefnogi SQL, nid yw'n addas iawn. Ymholwch ieithoedd fel , , , . Gobeithio bod rhywun wedi clywed o leiaf un o’r ieithoedd hyn. Mae'n debyg bod llawer o bobl wedi clywed am PromQL. Dyma iaith ymholiad Prometheus.
Dyma sut olwg sydd ar bensaernïaeth cronfa ddata cyfres amser modern gan ddefnyddio VictoriaMetrics fel enghraifft.
Mae'n cynnwys dwy ran. Mae hyn yn storfa ar gyfer y mynegai gwrthdro a storio ar gyfer gwerthoedd cyfres amser. Mae'r cadwrfeydd hyn wedi'u gwahanu.
Pan fydd cofnod newydd yn cyrraedd y gronfa ddata, rydym yn gyntaf yn cyrchu'r mynegai gwrthdro i ddod o hyd i'r dynodwr cyfres amser ar gyfer set benodol label=value ar gyfer metrig penodol. Rydym yn dod o hyd i'r dynodwr hwn ac yn arbed y gwerth yn y storfa ddata.
Pan ddaw cais i adalw data o TSDB, awn yn gyntaf i'r mynegai gwrthdro. Gadewch i ni gael popeth timeseries_ids cofnodion sy'n cyd-fynd â'r set hon label=value. Ac yna rydym yn cael yr holl ddata angenrheidiol o'r warws data, wedi'i fynegeio gan timeseries_ids.
Gadewch i ni edrych ar enghraifft o sut mae cronfa ddata cyfres amser yn prosesu ymholiad dethol sy'n dod i mewn.
- Yn gyntaf mae hi'n cael popeth
timeseries_idso fynegai gwrthdro sy'n cynnwys y parau a roddwydlabel=value, neu fodloni mynegiant rheolaidd penodol. - Yna mae'n adfer yr holl bwyntiau data o'r storfa ddata ar gyfnod amser penodol ar gyfer y rhai a ddarganfuwyd
timeseries_ids. - Ar ôl hyn, mae'r gronfa ddata yn gwneud rhai cyfrifiadau ar y pwyntiau data hyn, yn unol â chais y defnyddiwr. Ac ar ôl hynny mae'n dychwelyd yr ateb.
Yn y cyflwyniad hwn byddaf yn dweud wrthych am y rhan gyntaf. Chwiliad yw hwn timeseries_ids trwy fynegai gwrthdro. Gallwch wylio am yr ail ran a'r drydedd ran yn ddiweddarach , neu aros nes i mi baratoi adroddiadau eraill :)
Gadewch i ni symud ymlaen i'r mynegai gwrthdro. Efallai y bydd llawer yn meddwl bod hyn yn syml. Pwy a ŵyr beth yw mynegai gwrthdro a sut mae'n gweithio? O, dim cymaint o bobl bellach. Gadewch i ni geisio deall beth ydyw.
Mae'n syml mewn gwirionedd. Yn syml, geiriadur ydyw sy'n mapio allwedd i werth. Beth yw allwedd? Y cwpl hwn label=valuelle label и value - llinellau yw'r rhain. Ac mae'r gwerthoedd yn set timeseries_ids, sy'n cynnwys y pâr a roddir label=value.
Mae mynegai gwrthdro yn caniatáu ichi ddod o hyd i bopeth yn gyflym timeseries_ids, sydd wedi rhoi label=value.
Mae hefyd yn caniatáu ichi ddod o hyd yn gyflym timeseries_ids cyfres amser ar gyfer sawl pâr label=value, neu ar gyfer cyplau label=regexp. Sut mae hyn yn digwydd? Trwy ganfod croestoriad y set timeseries_ids ar gyfer pob pâr label=value.
Edrychwn ar wahanol weithrediadau'r mynegai gwrthdro. Gadewch i ni ddechrau gyda'r gweithredu naïf symlaf. Mae hi'n edrych fel hyn.
Swyddogaeth getMetricIDs yn cael rhestr o dannau. Mae pob llinell yn cynnwys label=value. Mae'r swyddogaeth hon yn dychwelyd rhestr metricIDs.
Sut mae'n gweithio? Yma mae gennym newidyn byd-eang o'r enw invertedIndex. Mae hwn yn eiriadur rheolaidd (map), a fydd yn mapio'r llinyn i dorri ints. Mae'r llinell yn cynnwys label=value.
Gweithredu swyddogaeth: cael metricIDs am y cyntaf label=value, yna rydyn ni'n mynd trwy bopeth arall label=value, rydym yn ei gael metricIDs i nhw. A ffoniwch y swyddogaeth intersectInts, a drafodir isod. Ac mae'r swyddogaeth hon yn dychwelyd croestoriad y rhestrau hyn.
Fel y gallwch weld, nid yw gweithredu mynegai gwrthdro yn gymhleth iawn. Ond gweithrediad naïf yw hwn. Pa anfanteision sydd ganddo? Prif anfantais y gweithrediad naïf yw bod mynegai gwrthdro o'r fath yn cael ei storio yn RAM. Ar ôl ailgychwyn y cais rydym yn colli'r mynegai hwn. Nid oes unrhyw arbediad o'r mynegai hwn i ddisg. Mae mynegai gwrthdro o'r fath yn annhebygol o fod yn addas ar gyfer cronfa ddata.
Mae'r ail anfantais hefyd yn gysylltiedig â'r cof. Rhaid i'r mynegai gwrthdro ffitio i mewn i RAM. Os yw'n fwy na maint RAM, yna yn amlwg fe gawn ni - gwall cof. Ac ni fydd y rhaglen yn gweithio.
Gellir datrys y broblem hon gan ddefnyddio atebion parod megis Neu .
Yn fyr, mae angen cronfa ddata arnom sy'n ein galluogi i wneud tri gweithrediad yn gyflym.
- Y llawdriniaeth gyntaf yw recordio
ключ-значениеi'r gronfa ddata hon. Mae hi'n gwneud hyn yn gyflym iawn, bleключ-значениеyn llinynnau mympwyol. - Mae'r ail weithrediad yn chwiliad cyflym am werth gan ddefnyddio allwedd benodol.
- Ac mae'r trydydd gweithrediad yn chwiliad cyflym am yr holl werthoedd trwy ragddodiad penodol.
LevelDB a RocksDB - datblygwyd y cronfeydd data hyn gan Google a Facebook. Daeth LevelDB yn gyntaf. Yna cymerodd y dynion o Facebook LevelDB a dechrau ei wella, fe wnaethant RocksDB. Nawr mae bron pob cronfa ddata fewnol yn gweithio ar RocksDB y tu mewn i Facebook, gan gynnwys y rhai sydd wedi'u trosglwyddo i RocksDB a MySQL. Dyma nhw'n ei enwi .
Gellir gweithredu mynegai gwrthdro gan ddefnyddio LevelDB. Sut i'w wneud? Rydym yn arbed fel allwedd label=value. A'r gwerth yw dynodwr y gyfres amser lle mae'r pâr yn bresennol label=value.
Os oes gennym lawer o gyfresi amser gyda phâr penodol label=value, yna bydd llawer o resi yn y gronfa ddata hon gyda'r un allwedd a gwahanol timeseries_ids. I gael rhestr o'r cyfan timeseries_ids, sy'n dechrau gyda hyn label=prefix, rydym yn gwneud sgan amrediad y mae'r gronfa ddata hon wedi'i optimeiddio ar ei gyfer. Hynny yw, rydym yn dewis pob llinell sy'n dechrau label=prefix a chael yr angenrheidiol timeseries_ids.
Dyma weithrediad sampl o sut olwg fyddai arno yn Go. Mae gennym fynegai gwrthdro. LefelDB yw hwn.
Mae'r swyddogaeth yr un fath ag ar gyfer y gweithrediad naïf. Mae'n ailadrodd y gweithredu naïf bron fesul llinell. Yr unig bwynt yw bod yn lle troi at map rydym yn cyrchu'r mynegai gwrthdro. Cawn yr holl werthoedd ar gyfer y cyntaf label=value. Yna rydyn ni'n mynd trwy'r holl barau sy'n weddill label=value a chael y setiau cyfatebol o metricIDs ar eu cyfer. Yna rydym yn dod o hyd i'r groesffordd.
Mae'n ymddangos bod popeth yn iawn, ond mae anfanteision i'r ateb hwn. I ddechrau, gweithredodd VictoriaMetrics fynegai gwrthdro yn seiliedig ar LevelDB. Ond yn y diwedd roedd yn rhaid i mi roi'r gorau iddi.
Pam? Oherwydd bod LevelDB yn arafach na'r gweithredu naïf. Mewn gweithrediad naïf, o ystyried allwedd benodol, rydym yn adfer y darn cyfan ar unwaith metricIDs. Mae hwn yn weithrediad cyflym iawn - mae'r darn cyfan yn barod i'w ddefnyddio.
Yn LevelDB, bob tro y gelwir swyddogaeth GetValues mae angen i chi fynd trwy'r holl linellau sy'n dechrau label=value. A chael y gwerth ar gyfer pob llinell timeseries_ids. O'r cyfryw timeseries_ids casglwch dafell o'r rhain timeseries_ids. Yn amlwg, mae hyn yn llawer arafach na dim ond cyrchu map rheolaidd trwy allwedd.
Yr ail anfantais yw bod LevelDB wedi'i ysgrifennu yn C. Nid yw galw swyddogaethau C o Go yn gyflym iawn. Mae'n cymryd cannoedd o nanoeiliadau. Nid yw hyn yn gyflym iawn, oherwydd o'i gymharu â galwad swyddogaeth reolaidd a ysgrifennwyd wrth fynd, sy'n cymryd 1-5 nanoseconds, mae'r gwahaniaeth mewn perfformiad yn ddegau o weithiau. I VictoriaMetrics roedd hyn yn ddiffyg angheuol :)
Felly ysgrifennais fy ngweithrediad fy hun o'r mynegai gwrthdro. Ac efe a'i galwodd hi .
Mae Mergeset yn seiliedig ar strwythur data MergeTree. Mae'r strwythur data hwn yn cael ei fenthyg gan ClickHouse. Yn amlwg, dylid optimeiddio mergeset ar gyfer chwilio cyflym timeseries_ids yn ôl yr allwedd a roddwyd. Mae Mergeset wedi'i ysgrifennu'n gyfan gwbl yn Go. Gallwch weld . Mae gweithredu mergeset yn y ffolder . Gallwch geisio darganfod beth sy'n digwydd yno.
Mae'r API mergeset yn debyg iawn i LevelDB a RocksDB. Hynny yw, mae'n caniatáu ichi arbed cofnodion newydd yn gyflym yno a dewis cofnodion yn gyflym trwy ragddodiad penodol.
Byddwn yn siarad am anfanteision mergeset yn ddiweddarach. Nawr, gadewch i ni siarad am ba broblemau a gododd gyda VictoriaMetrics wrth gynhyrchu wrth weithredu mynegai gwrthdro.
Pam y codasant?
Y rheswm cyntaf yw'r gyfradd gorddi uchel. Wedi'i gyfieithu i Rwsieg, mae hwn yn newid aml mewn cyfresi amser. Dyma pryd mae cyfres amser yn dod i ben a chyfres newydd yn dechrau, neu lawer o gyfresi amser newydd yn dechrau. Ac mae hyn yn digwydd yn aml.
Yr ail reswm yw'r nifer fawr o gyfresi amser. Yn y dechrau, pan oedd monitro yn ennill poblogrwydd, roedd nifer y cyfresi amser yn fach. Er enghraifft, ar gyfer pob cyfrifiadur mae angen i chi fonitro CPU, cof, rhwydwaith a llwyth disg. 4 cyfres amser fesul cyfrifiadur. Gadewch i ni ddweud bod gennych chi 100 o gyfrifiaduron a 400 o gyfresi amser. Ychydig iawn yw hyn.
Dros amser, daeth pobl i wybod y gallent fesur mwy o wybodaeth gronynnog. Er enghraifft, mesurwch y llwyth nid y prosesydd cyfan, ond ar wahân i graidd pob prosesydd. Os oes gennych 40 craidd prosesydd, yna mae gennych 40 gwaith yn fwy o gyfresi amser i fesur llwyth prosesydd.
Ond nid dyna'r cyfan. Gall pob craidd prosesydd gael sawl cyflwr, megis segur, pan fydd yn segur. A hefyd yn gweithio mewn gofod defnyddwyr, yn gweithio yn y gofod cnewyllyn a gwladwriaethau eraill. A gellir mesur pob cyflwr o'r fath hefyd fel cyfres amser ar wahân. Mae hyn hefyd yn cynyddu nifer y rhesi 7-8 gwaith.
O un metrig cawsom fetrigau 40 x 8 = 320 ar gyfer un cyfrifiadur yn unig. Lluoswch â 100, rydym yn cael 32 yn lle 000.
Yna daeth Kubernetes draw. Ac fe waethygodd oherwydd gall Kubernetes gynnal llawer o wahanol wasanaethau. Mae pob gwasanaeth yn Kubernetes yn cynnwys llawer o godennau. Ac mae angen monitro hyn i gyd. Yn ogystal, rydym yn defnyddio fersiynau newydd o'ch gwasanaethau yn gyson. Ar gyfer pob fersiwn newydd, rhaid creu cyfresi amser newydd. O ganlyniad, mae nifer y cyfresi amser yn tyfu'n esbonyddol ac rydym yn wynebu problem nifer fawr o gyfresi amser, a elwir yn uchel-gardinoldeb. Mae VictoriaMetrics yn ymdopi ag ef yn llwyddiannus o'i gymharu â chronfeydd data cyfresi amser eraill.
Gadewch i ni edrych yn agosach ar gyfradd corddi uchel. Beth sy'n achosi cyfradd gorddi uchel mewn cynhyrchiant? Oherwydd bod rhai ystyron o labeli a thagiau yn newid yn gyson.
Er enghraifft, cymerwch Kubernetes, sydd â'r cysyniad deployment, h.y. pan fydd fersiwn newydd o’ch cais yn cael ei chyflwyno. Am ryw reswm, penderfynodd datblygwyr Kubernetes ychwanegu'r id lleoli at y label.
Beth arweiniodd hyn? Ar ben hynny, gyda phob defnydd newydd, amharir ar yr holl hen gyfresi amser, ac yn eu lle, mae cyfresi amser newydd yn dechrau gyda gwerth label newydd deployment_id. Gall fod cannoedd o filoedd a hyd yn oed miliynau o resi o'r fath.
Y peth pwysig am hyn i gyd yw bod cyfanswm nifer y cyfresi amser yn tyfu, ond mae nifer y cyfresi amser sy'n weithredol ar hyn o bryd ac yn derbyn data yn parhau'n gyson. Gelwir y cyflwr hwn yn gyfradd corddi uchel.
Prif broblem cyfradd corddi uchel yw sicrhau cyflymder chwilio cyson ar gyfer pob cyfres amser ar gyfer set benodol o labeli dros gyfnod penodol o amser. Yn nodweddiadol dyma'r cyfnod amser ar gyfer yr awr olaf neu'r diwrnod olaf.
Sut i ddatrys y broblem hon? Dyma'r opsiwn cyntaf. Mae hyn er mwyn rhannu'r mynegai gwrthdro yn rhannau annibynnol dros amser. Hynny yw, rhai cyfnodau amser yn mynd heibio, rydym yn gorffen gweithio gyda'r mynegai gwrthdro cyfredol. A chreu mynegai gwrthdro newydd. Mae cyfwng amser arall yn mynd heibio, rydyn ni'n creu un arall ac un arall.
Ac wrth samplu o'r mynegeion gwrthdro hyn, rydym yn dod o hyd i set o fynegeion gwrthdro sy'n dod o fewn y cyfwng a roddwyd. Ac, yn unol â hynny, rydym yn dewis id y gyfres amser oddi yno.
Mae hyn yn arbed adnoddau oherwydd nid oes yn rhaid i ni edrych ar rannau nad ydynt yn dod o fewn y cyfnod penodol. Hynny yw, fel arfer, os byddwn yn dewis data ar gyfer yr awr olaf, yna ar gyfer cyfnodau amser blaenorol rydym yn hepgor ceisiadau.
Mae opsiwn arall i ddatrys y broblem hon. Mae hyn er mwyn storio rhestr ar wahân o enwau cyfresi amser a ddigwyddodd ar y diwrnod hwnnw ar gyfer pob diwrnod.
Mantais yr ateb hwn dros yr ateb blaenorol yw nad ydym yn dyblygu gwybodaeth cyfres amser nad yw'n diflannu dros amser. Maent yn bresennol yn gyson ac nid ydynt yn newid.
Yr anfantais yw bod datrysiad o'r fath yn anoddach i'w weithredu ac yn anos ei ddadfygio. A dewisodd VictoriaMetrics yr ateb hwn. Fel hyn y digwyddodd yn hanesyddol. Mae'r datrysiad hwn hefyd yn perfformio'n dda o'i gymharu â'r un blaenorol. Oherwydd na weithredwyd y datrysiad hwn oherwydd bod angen dyblygu data ym mhob rhaniad ar gyfer cyfresi amser nad ydynt yn newid, h.y. nad ydynt yn diflannu dros amser. Cafodd VictoriaMetrics ei optimeiddio'n bennaf ar gyfer y defnydd o ofod disg, a gwnaeth y gweithrediad blaenorol y defnydd o ofod disg yn waeth. Ond mae'r gweithrediad hwn yn fwy addas ar gyfer lleihau'r defnydd o ofod disg, felly fe'i dewiswyd.
Roedd yn rhaid i mi ymladd â hi. Y frwydr oedd bod angen i chi ddewis nifer llawer mwy yn y gweithrediad hwn timeseries_ids ar gyfer data na phan fydd y mynegai gwrthdro yn rhaniad amser.
Sut wnaethon ni ddatrys y broblem hon? Fe wnaethon ni ei ddatrys mewn ffordd wreiddiol - trwy storio sawl dynodwr cyfres amser ym mhob cofnod mynegai gwrthdro yn lle un dynodwr. Hynny yw, mae gennym allwedd label=value, sy'n digwydd ym mhob cyfres amser. Ac yn awr rydym yn arbed sawl un timeseries_ids mewn un cofnod.
Dyma enghraifft. Yn flaenorol roedd gennym N cofnodion, ond yn awr mae gennym un cofnod y mae ei rhagddodiad yr un fath â'r lleill i gyd. Ar gyfer y cofnod blaenorol, mae'r gwerth yn cynnwys yr holl enwau cyfresi amser.
Roedd hyn yn ei gwneud hi'n bosibl cynyddu cyflymder sganio mynegai gwrthdro o'r fath hyd at 10 gwaith. Ac fe wnaeth ein galluogi i leihau'r defnydd o gof ar gyfer y storfa, oherwydd nawr rydyn ni'n storio'r llinyn label=value dim ond unwaith yn y storfa gyda'i gilydd N gwaith. A gall y llinell hon fod yn fawr os ydych chi'n storio llinellau hir yn eich tagiau a'ch labeli, y mae Kubernetes yn hoffi eu gwthio yno.
Opsiwn arall ar gyfer cyflymu'r chwilio ar fynegai gwrthdro yw darnio. Creu sawl mynegai gwrthdro yn lle un a rhannu data rhyngddynt yn ôl allwedd. Dyma set key=value ager. Hynny yw, rydym yn cael sawl mynegai gwrthdro annibynnol, y gallwn eu holi ochr yn ochr â sawl prosesydd. Roedd gweithrediadau blaenorol yn caniatáu gweithredu yn y modd prosesydd sengl yn unig, h.y., sganio data ar un craidd yn unig. Mae'r datrysiad hwn yn caniatáu ichi sganio data ar sawl craidd ar unwaith, fel y mae ClickHouse yn hoffi ei wneud. Dyma’r hyn yr ydym yn bwriadu ei roi ar waith.
Nawr, gadewch i ni ddychwelyd at ein defaid - i'r swyddogaeth croestoriad timeseries_ids. Gadewch i ni ystyried pa weithrediadau a all fod. Mae'r swyddogaeth hon yn eich galluogi i ddod o hyd timeseries_ids am set benodol label=value.
Yr opsiwn cyntaf yw gweithrediad naïf. Dwy ddolen nythog. Yma rydym yn cael y mewnbwn swyddogaeth intersectInts dwy dafell - a и b. Ar yr allbwn, dylai ddychwelyd i ni groesffordd y tafelli hyn.
Mae gweithrediad naïf yn edrych fel hyn. Rydym yn ailadrodd dros yr holl werthoedd o sleisen a, y tu mewn i'r ddolen hon rydym yn mynd trwy'r holl werthoedd o sleisen b. Ac rydym yn eu cymharu. Os ydynt yn cyfateb, yna rydym wedi dod o hyd i groesffordd. Ac arbed yn result.
Beth yw'r anfanteision? Cymhlethdod cwadratig yw ei brif anfantais. Er enghraifft, os yw eich dimensiynau yn sleisen a и b miliwn ar y tro, yna ni fydd y swyddogaeth hon byth yn dychwelyd ateb i chi. Oherwydd bydd angen iddo wneud un triliwn o iteriadau, sy'n llawer hyd yn oed ar gyfer cyfrifiaduron modern.
Mae'r ail weithrediad yn seiliedig ar fap. Rydyn ni'n creu map. Rydyn ni'n rhoi'r holl werthoedd o sleisen i'r map hwn a. Yna rydym yn mynd trwy sleisen mewn dolen ar wahân b. Ac rydym yn gwirio a yw'r gwerth hwn yn dod o sleisen b yn map. Os yw'n bodoli, yna ychwanegwch ef at y canlyniad.
Beth yw'r manteision? Y fantais yw mai dim ond cymhlethdod llinellol sydd. Hynny yw, bydd y swyddogaeth yn gweithredu'n llawer cyflymach ar gyfer sleisys mwy. Am dafell maint miliwn, bydd y swyddogaeth hon yn gweithredu mewn 2 filiwn o iteriadau, yn hytrach na thriliwn iteriadau o'r swyddogaeth flaenorol.
Yr anfantais yw bod angen mwy o gof ar y swyddogaeth hon i greu'r map hwn.
Yr ail anfantais yw'r gorben mawr ar gyfer stwnsio. Nid yw'r anfantais hon yn amlwg iawn. Ac i ni nid oedd yn amlwg iawn ychwaith, felly ar y dechrau yn VictoriaMetrics roedd gweithredu croestoriad trwy fap. Ond yna dangosodd proffilio fod y prif brosesydd yn treulio amser yn ysgrifennu at y map ac yn gwirio presenoldeb gwerth yn y map hwn.
Pam mae amser CPU yn cael ei wastraffu yn y mannau hyn? Oherwydd bod Go yn perfformio llawdriniaeth stwnsio ar y llinellau hyn. Hynny yw, mae'n cyfrifo hash yr allwedd er mwyn ei gyrchu mewn mynegai penodol yn yr HashMap. Cwblheir y gweithrediad cyfrifo hash mewn degau o nanoseconds. Mae hyn yn araf i VictoriaMetrics.
Penderfynais weithredu bitset wedi'i optimeiddio'n benodol ar gyfer yr achos hwn. Dyma sut olwg sydd ar groesffordd dwy dafell nawr. Yma rydym yn creu bitset. Rydyn ni'n ychwanegu elfennau o'r darn cyntaf ato. Yna rydym yn gwirio presenoldeb yr elfennau hyn yn yr ail dafell. A'u hychwanegu at y canlyniad. Hynny yw, nid yw bron yn wahanol i'r enghraifft flaenorol. Yr unig beth yma yw ein bod wedi disodli mynediad i fap gyda swyddogaethau arferiad add и has.
Ar yr olwg gyntaf, mae'n ymddangos y dylai hyn weithio'n arafach, os defnyddiwyd map safonol yno o'r blaen, ac yna gelwir rhai swyddogaethau eraill, ond mae proffilio yn dangos bod y peth hwn yn gweithio 10 gwaith yn gyflymach na'r map safonol yn achos VictoriaMetrics.
Yn ogystal, mae'n defnyddio llawer llai o gof o'i gymharu â gweithredu'r map. Oherwydd rydyn ni'n storio darnau yma yn lle gwerthoedd wyth beit.
Anfantais y gweithredu hwn yw nad yw mor amlwg, nid dibwys.
Anfantais arall efallai na fydd llawer yn sylwi arno yw efallai na fydd y gweithredu hwn yn gweithio'n dda mewn rhai achosion. Hynny yw, mae wedi'i optimeiddio ar gyfer achos penodol, ar gyfer yr achos hwn o groesffordd ids cyfres amser VictoriaMetrics. Nid yw hyn yn golygu ei fod yn addas ar gyfer pob achos. Os caiff ei ddefnyddio'n anghywir, ni fyddwn yn cael cynnydd mewn perfformiad, ond gwall y tu allan i'r cof ac arafu mewn perfformiad.
Gadewch i ni ystyried gweithrediad y strwythur hwn. Os ydych chi am edrych, mae wedi'i leoli yn y ffynonellau VictoriaMetrics, yn y ffolder . Mae wedi'i optimeiddio'n benodol ar gyfer achos VictoriaMetrics, lle timeseries_id yw gwerth 64-did, lle mae'r 32 did cyntaf yn gyson yn y bôn a dim ond y 32 did olaf sy'n newid.
Nid yw'r strwythur data hwn yn cael ei storio ar ddisg, dim ond yn y cof y mae'n gweithredu.
Dyma ei API. Nid yw'n gymhleth iawn. Mae'r API wedi'i deilwra'n benodol i enghraifft benodol o ddefnyddio VictoriaMetrics. Hynny yw, nid oes unrhyw swyddogaethau diangen yma. Dyma'r swyddogaethau a ddefnyddir yn benodol gan VictoriaMetrics.
Mae yna swyddogaethau add, sy'n ychwanegu gwerthoedd newydd. Mae yna swyddogaeth has, sy'n gwirio am werthoedd newydd. Ac mae yna swyddogaeth del, sy'n dileu gwerthoedd. Mae swyddogaeth cynorthwy-ydd len, sy'n dychwelyd maint y set. Swyddogaeth clone clonau llawer. A swyddogaeth appendto yn trosi'r set hon i dafell timeseries_ids.
Dyma sut olwg sydd ar weithredu'r strwythur data hwn. Mae gan y set ddwy elfen:
-
ItemsCountyn faes helpwr i ddychwelyd nifer yr elfennau mewn set yn gyflym. Byddai'n bosibl gwneud heb y maes ategol hwn, ond roedd yn rhaid ei ychwanegu yma oherwydd mae VictoriaMetrics yn aml yn cwestiynu hyd bitset yn ei algorithmau. -
Yr ail faes yw
buckets. Dyma dafell o'r strwythurbucket32. Mae pob strwythur yn storiohimaes. Dyma'r 32 did uchaf. A dwy dafell -b16hisиbucketsobucket16strwythurau.
Mae'r 16 did uchaf o ail ran y strwythur 64-did yn cael eu storio yma. Ac yma mae setiau didau yn cael eu storio ar gyfer yr 16 did isaf o bob beit.
Bucket64 yn cynnwys arae uint64. Mae'r hyd yn cael ei gyfrifo gan ddefnyddio'r cysonion hyn. Mewn un bucket16 gellir storio uchafswm 2^16=65536 bit. Os rhannwch hwn ag 8, yna 8 kilobytes ydyw. Os rhannwch ag 8 eto, mae'n 1000 uint64 ystyr. Hynny yw Bucket16 – dyma ein strwythur 8-cilobeit.
Gadewch i ni edrych ar sut mae un o ddulliau'r strwythur hwn ar gyfer ychwanegu gwerth newydd yn cael ei weithredu.
Mae'r cyfan yn dechrau gyda uint64 ystyron. Rydyn ni'n cyfrifo'r 32 did uchaf, rydyn ni'n cyfrifo'r 32 did isaf. Gadewch i ni fynd trwy bopeth buckets. Rydyn ni'n cymharu'r 32 did uchaf ym mhob bwced â'r gwerth sy'n cael ei ychwanegu. Ac os ydynt yn cyfateb, yna rydym yn galw'r swyddogaeth add mewn strwythur b32 buckets. Ac ychwanegwch y darnau 32 isaf yno. Ac os dychwelodd true, yna mae hyn yn golygu ein bod wedi ychwanegu gwerth o'r fath yno ac nid oedd gennym y fath werth. Os bydd yn dychwelyd false, yna yr oedd y fath ystyr eisoes yn bod. Yna rydym yn cynyddu nifer yr elfennau yn y strwythur.
Os nad ydym wedi dod o hyd i'r un sydd ei angen arnoch bucket gyda'r uwch-werth gofynnol, yna rydym yn galw'r swyddogaeth addAlloc, a fydd yn cynhyrchu un newydd bucket, gan ei ychwanegu at y strwythur bwced.
Dyma weithrediad y swyddogaeth b32.add. Mae'n debyg i'r gweithredu blaenorol. Rydyn ni'n cyfrifo'r 16 did mwyaf arwyddocaol, a'r 16 did lleiaf arwyddocaol.
Yna rydyn ni'n mynd trwy'r 16 did uchaf i gyd. Rydym yn dod o hyd i gemau. Ac os oes cyfatebiaeth, rydym yn galw'r dull ychwanegu, y byddwn yn ei ystyried ar y dudalen nesaf ar ei gyfer bucket16.
A dyma'r lefel isaf, y dylid ei optimeiddio cymaint â phosib. Rydym yn cyfrifo ar gyfer uint64 gwerth id mewn tafell did a hefyd bitmask. Mwgwd yw hwn ar gyfer gwerth 64-did penodol, y gellir ei ddefnyddio i wirio presenoldeb y darn hwn, neu ei osod. Rydym yn gwirio i weld a yw'r darn hwn wedi'i osod a'i osod, a dychwelyd presenoldeb. Dyma ein gweithrediad, a ganiataodd i ni gyflymu gweithrediad ids croestoriadol cyfresi amser 10 gwaith o gymharu â mapiau confensiynol.
Yn ogystal â'r optimeiddio hwn, mae gan VictoriaMetrics lawer o optimeiddiadau eraill. Ychwanegwyd y rhan fwyaf o'r optimizations hyn am reswm, ond ar ôl proffilio'r cod wrth gynhyrchu.
Dyma brif reol optimeiddio - peidiwch ag ychwanegu optimeiddio gan dybio y bydd yna dagfa yma, oherwydd efallai y bydd yn troi allan na fydd tagfa yno. Mae optimeiddio fel arfer yn diraddio ansawdd y cod. Felly, mae'n werth optimeiddio dim ond ar ôl proffilio ac yn ddelfrydol wrth gynhyrchu, fel bod hwn yn ddata go iawn. Os oes gan unrhyw un ddiddordeb, gallwch edrych ar god ffynhonnell VictoriaMetrics ac archwilio optimeiddiadau eraill sydd yno.
Mae gen i gwestiwn am bitset. Yn debyg iawn i weithrediad bool fector C++, set bit wedi'i optimeiddio. A wnaethoch chi gymryd y gweithredu oddi yno?
Na, nid oddi yno. Wrth weithredu'r bitset hwn, cefais fy arwain gan wybodaeth am strwythur y cyfresi amser ids hyn, a ddefnyddir yn VictoriaMetrics. Ac mae eu strwythur yn golygu bod y 32 did uchaf yn gyson yn y bôn. Gall y 32 did isaf newid. Po isaf yw'r darn, y mwyaf aml y gall newid. Felly, mae'r gweithrediad hwn wedi'i optimeiddio'n benodol ar gyfer y strwythur data hwn. Mae gweithrediad C++, hyd y gwn, wedi'i optimeiddio ar gyfer yr achos cyffredinol. Os ydych chi'n optimeiddio ar gyfer yr achos cyffredinol, mae hyn yn golygu na fydd y mwyaf optimaidd ar gyfer achos penodol.
Rwyf hefyd yn eich cynghori i wylio adroddiad Alexey Milovid. Tua mis yn ôl, siaradodd am optimeiddio yn ClickHouse ar gyfer arbenigeddau penodol. Mae'n dweud, yn yr achos cyffredinol, bod gweithrediad C++ neu ryw weithrediad arall wedi'i deilwra i weithio'n dda ar gyfartaledd mewn ysbyty. Gall berfformio'n waeth na gweithrediad gwybodaeth-benodol fel ein un ni, lle gwyddom fod y 32 did uchaf yn gyson ar y cyfan.
Mae gennyf ail gwestiwn. Beth yw'r gwahaniaeth sylfaenol o InfluxDB?
Mae yna lawer o wahaniaethau sylfaenol. O ran perfformiad a defnydd cof, mae InfluxDB mewn profion yn dangos 10 gwaith yn fwy o ddefnydd cof ar gyfer cyfres amser cardinality uchel, pan fydd gennych lawer ohonynt, er enghraifft, miliynau. Er enghraifft, mae VictoriaMetrics yn defnyddio 1 GB fesul miliwn o resi gweithredol, tra bod InfluxDB yn defnyddio 10 GB. Ac mae hynny'n wahaniaeth mawr.
Yr ail wahaniaeth sylfaenol yw bod gan InfluxDB ieithoedd ymholiad rhyfedd - Flux ac InfluxQL. Nid ydynt yn gyfleus iawn ar gyfer gweithio gyda chyfresi amser o gymharu â , a gefnogir gan VictoriaMetrics. Mae PromQL yn iaith ymholiad gan Prometheus.
Ac un gwahaniaeth arall yw bod gan InfluxDB fodel data ychydig yn rhyfedd, lle gall pob llinell storio sawl maes gyda set wahanol o dagiau. Rhennir y llinellau hyn ymhellach yn amrywiol dablau. Mae'r cymhlethdodau ychwanegol hyn yn cymhlethu gwaith dilynol gyda'r gronfa ddata hon. Mae'n anodd ei gefnogi a'i ddeall.
Yn VictoriaMetrics mae popeth yn llawer symlach. Yno, mae pob cyfres amser yn werth allweddol. Mae'r gwerth yn set o bwyntiau - (timestamp, value), a'r allwedd yw'r set label=value. Nid oes unrhyw wahaniad rhwng meysydd a mesuriadau. Mae'n caniatáu ichi ddewis unrhyw ddata ac yna cyfuno, adio, tynnu, lluosi, rhannu, yn wahanol i InfluxDB lle nad yw cyfrifiadau rhwng gwahanol resi yn cael eu gweithredu hyd y gwn i. Hyd yn oed os cânt eu gweithredu, mae'n anodd, mae'n rhaid i chi ysgrifennu llawer o god.
Mae gennyf gwestiwn eglurhaol. A ddeallais yn iawn fod rhyw fath o broblem y soniasoch amdani, nad yw’r mynegai gwrthdro hwn yn ffitio i’r cof, felly mae rhaniad yno?
Yn gyntaf, dangosais weithrediad naïf o fynegai gwrthdro ar fap Go safonol. Nid yw'r gweithrediad hwn yn addas ar gyfer cronfeydd data oherwydd nid yw'r mynegai gwrthdro hwn wedi'i gadw ar ddisg, a rhaid i'r gronfa ddata gadw ar ddisg fel bod y data hwn yn parhau i fod ar gael wrth ailgychwyn. Yn y gweithrediad hwn, pan fyddwch yn ailgychwyn y cais, bydd eich mynegai gwrthdro yn diflannu. A byddwch yn colli mynediad i'r holl ddata oherwydd ni fyddwch yn gallu dod o hyd iddo.
Helo! Diolch am yr adroddiad! Fy enw i yw Pavel. Rwy'n dod o Wildberries. Mae gennyf ychydig o gwestiynau i chi. Cwestiwn un. Ydych chi'n meddwl pe baech wedi dewis egwyddor wahanol wrth adeiladu saernïaeth eich cais ac wedi rhannu'r data dros amser, yna efallai y byddech wedi gallu croestorri data wrth chwilio, yn seiliedig yn unig ar y ffaith bod un rhaniad yn cynnwys data ar gyfer un cyfnod o amser, hynny yw, mewn un egwyl amser ac ni fyddai'n rhaid i chi boeni am y ffaith bod eich darnau wedi'u gwasgaru'n wahanol? Cwestiwn rhif 2 - gan eich bod yn gweithredu algorithm tebyg gyda bitset a phopeth arall, yna efallai eich bod wedi ceisio defnyddio cyfarwyddiadau prosesydd? Efallai eich bod wedi rhoi cynnig ar optimeiddiadau o'r fath?
Atebaf yr ail ar unwaith. Nid ydym wedi cyrraedd y pwynt hwnnw eto. Ond os bydd angen, byddwn yn cyrraedd yno. A'r un cyntaf, beth oedd y cwestiwn?
Bu ichi drafod dwy senario. A dywedasant eu bod wedi dewis yr ail un gyda gweithrediad mwy cymhleth. Ac nid oedd yn well ganddynt yr un cyntaf, lle mae'r data'n cael ei rannu gan amser.
Oes. Yn yr achos cyntaf, byddai cyfanswm cyfaint y mynegai yn fwy, oherwydd ym mhob rhaniad byddai'n rhaid i ni storio data dyblyg ar gyfer y cyfresi amser hynny sy'n parhau trwy'r holl raniadau hyn. Ac os yw eich cyfradd corddi cyfres amser yn fach, h.y. mae'r un gyfres yn cael ei defnyddio'n gyson, yna yn yr achos cyntaf byddem yn colli llawer mwy yn y gofod disg a ddefnyddir o gymharu â'r ail achos.
Ac felly - ydy, mae rhaniad amser yn opsiwn da. Mae Prometheus yn ei ddefnyddio. Ond mae gan Prometheus anfantais arall. Wrth uno'r darnau hyn o ddata, mae angen iddo gadw gwybodaeth meta cof ar gyfer pob label a chyfres amser. Felly, os yw'r darnau o ddata y mae'n eu huno yn fawr, yna mae'r defnydd o gof yn cynyddu'n fawr iawn yn ystod yr uno, yn wahanol i VictoriaMetrics. Wrth uno, nid yw VictoriaMetrics yn defnyddio cof o gwbl; dim ond cwpl o kilobytes sy'n cael eu bwyta, waeth beth fo maint y darnau o ddata cyfun.
Mae'r algorithm rydych chi'n ei ddefnyddio yn defnyddio cof. Mae'n nodi tagiau cyfresi amser sy'n cynnwys gwerthoedd. Ac fel hyn rydych chi'n gwirio am bresenoldeb pâr mewn un casgliad data ac mewn un arall. Ac rydych chi'n deall a ddigwyddodd croestoriad ai peidio. Yn nodweddiadol, mae cronfeydd data yn gweithredu cyrchyddion ac iteryddion sy'n storio eu cynnwys cyfredol ac yn rhedeg trwy'r data wedi'i ddidoli oherwydd cymhlethdod syml y gweithrediadau hyn.
Pam nad ydym yn defnyddio cyrchyddion i groesi data?
Ydw.
Rydym yn storio rhesi wedi'u didoli yn LevelDB neu mergeset. Gallwn symud y cyrchwr a dod o hyd i'r groesffordd. Pam nad ydym yn ei ddefnyddio? Achos mae'n araf. Oherwydd bod cyrchyddion yn golygu bod angen i chi alw swyddogaeth ar gyfer pob llinell. Mae galwad swyddogaeth yn 5 nanoseconds. Ac os oes gennych 100 o linellau, yna mae'n troi allan ein bod yn treulio hanner eiliad yn galw'r swyddogaeth yn unig.
Mae y fath beth, oes. A fy nghwestiwn olaf. Efallai bod y cwestiwn yn swnio ychydig yn rhyfedd. Pam nad yw’n bosibl darllen yr holl agregau angenrheidiol ar hyn o bryd mae’r data’n cyrraedd a’u cadw yn y ffurf ofynnol? Pam arbed cyfeintiau enfawr mewn rhai systemau fel VictoriaMetrics, ClickHouse, ac ati, ac yna treulio llawer o amser arnynt?
Rhoddaf enghraifft i'w gwneud yn gliriach. Gadewch i ni ddweud sut mae cyflymdra tegan bach yn gweithio? Mae'n cofnodi'r pellter rydych chi wedi'i deithio, trwy'r amser yn ei ychwanegu at un gwerth, a'r ail - amser. Ac yn rhannu. Ac yn cael cyflymder cyfartalog. Gallwch chi wneud tua'r un peth. Adiwch yr holl ffeithiau angenrheidiol ar y hedfan.
Iawn, rwy'n deall y cwestiwn. Mae gan eich enghraifft ei lle. Os ydych chi'n gwybod pa agregau sydd eu hangen arnoch chi, yna dyma'r gweithrediad gorau. Ond y broblem yw bod pobl yn arbed y metrigau hyn, rhywfaint o ddata yn ClickHouse ac nid ydynt yn gwybod eto sut y byddant yn eu hagregu a'u hidlo yn y dyfodol, felly mae'n rhaid iddynt arbed yr holl ddata crai. Ond os ydych chi'n gwybod bod angen i chi gyfrifo rhywbeth ar gyfartaledd, yna beth am ei gyfrifo yn lle storio criw o werthoedd crai yno? Ond dim ond os ydych chi'n gwybod yn union beth sydd ei angen arnoch chi y mae hyn.
Gyda llaw, mae cronfeydd data ar gyfer storio cyfresi amser yn cefnogi cyfrif agregau. Er enghraifft, mae Prometheus yn cefnogi . Hynny yw, gellir gwneud hyn os ydych chi'n gwybod pa unedau y bydd eu hangen arnoch chi. Nid oes gan VictoriaMetrics hwn eto, ond fe'i rhagflaenir fel arfer gan Prometheus, lle gellir gwneud hyn yn y rheolau cofnodi.
Er enghraifft, yn fy swydd flaenorol roedd angen i mi gyfrif nifer y digwyddiadau mewn ffenestr lithro dros yr awr ddiwethaf. Y broblem yw bod yn rhaid i mi wneud gweithrediad arferol yn Go, h.y. gwasanaeth ar gyfer cyfrif y peth hwn. Nid oedd y gwasanaeth hwn yn ddibwys yn y pen draw, oherwydd mae'n anodd ei gyfrifo. Gall y gweithredu fod yn syml os oes angen i chi gyfrif rhai agregau ar gyfnodau amser penodol. Os ydych chi am gyfrif digwyddiadau mewn ffenestr llithro, yna nid yw mor syml ag y mae'n ymddangos. Rwy'n credu nad yw hyn wedi'i weithredu eto yn ClickHouse nac mewn cronfeydd data cyfresi amser, oherwydd mae'n anodd ei weithredu.
Ac un cwestiwn arall. Roeddem yn siarad am gyfartaleddu, a chofiais fod y fath beth ar un adeg â Graffit gyda chefndir Carbon. Ac roedd yn gwybod sut i deneuo hen ddata, hynny yw, gadael un pwynt y funud, un pwynt yr awr, ac ati Mewn egwyddor, mae hyn yn eithaf cyfleus os oes angen data crai, yn gymharol siarad, am fis, a gall popeth arall cael ei deneuo. Ond nid yw Prometheus a VictoriaMetrics yn cefnogi'r swyddogaeth hon. A oes bwriad i'w gefnogi? Os na, pam lai?
Diolch am y cwestiwn. Mae ein defnyddwyr yn gofyn y cwestiwn hwn o bryd i'w gilydd. Maent yn gofyn pryd y byddwn yn ychwanegu cefnogaeth ar gyfer is-samplu. Mae yna sawl problem yma. Yn gyntaf, mae pob defnyddiwr yn deall downsampling rhywbeth gwahanol: mae rhywun eisiau cael unrhyw bwynt mympwyol ar gyfwng penodol, mae rhywun eisiau uchafswm, isafswm, gwerthoedd cyfartalog. Os yw llawer o systemau'n ysgrifennu data i'ch cronfa ddata, yna ni allwch ei gyfannu gyda'i gilydd. Efallai bod angen teneuo gwahanol ar bob system. Ac mae hyn yn anodd ei weithredu.
A'r ail beth yw bod VictoriaMetrics, fel ClickHouse, wedi'i optimeiddio ar gyfer gweithio gyda llawer iawn o ddata crai, felly gall rhawio biliwn o linellau mewn llai nag eiliad os oes gennych lawer o greiddiau yn eich system. Sganio pwyntiau cyfres amser yn VictoriaMetrics - 50 pwynt yr eiliad y craidd. Ac mae'r perfformiad hwn yn cyd-fynd â'r creiddiau presennol. Hynny yw, os oes gennych 000 craidd, er enghraifft, byddwch yn sganio biliwn o bwyntiau yr eiliad. Ac mae'r eiddo hwn o VictoriaMetrics a ClickHouse yn lleihau'r angen am is-samplu.
Nodwedd arall yw bod VictoriaMetrics yn cywasgu'r data hwn yn effeithiol. Mae cywasgu ar gyfartaledd mewn cynhyrchiad rhwng 0,4 a 0,8 bytes y pwynt. Mae pob pwynt yn stamp amser + gwerth. Ac mae'n cael ei gywasgu i lai nag un beit ar gyfartaledd.
Sergey. Mae gen i cwestiwn. Beth yw'r isafswm amser cofnodi cwantwm?
Un milieiliad. Yn ddiweddar cawsom sgwrs gyda datblygwyr cronfeydd data cyfresi amser eraill. Un eiliad yw eu lleiafswm amser. Ac mewn Graffit, er enghraifft, mae hefyd yn eiliad. Yn OpenTSDB mae hefyd yn eiliad. Mae gan InfluxDB drachywiredd nanosecond. Yn VictoriaMetrics mae'n un milieiliad, oherwydd yn Prometheus mae'n un milieiliad. A datblygwyd VictoriaMetrics yn wreiddiol fel storfa bell ar gyfer Prometheus. Ond nawr gall arbed data o systemau eraill.
Mae'r person y siaradais i ag ef yn dweud bod ganddyn nhw gywirdeb eiliad-i-eiliad - mae hynny'n ddigon iddyn nhw oherwydd mae'n dibynnu ar y math o ddata sy'n cael ei storio yn y gronfa ddata cyfres amser. Os mai data DevOps neu ddata o seilwaith yw hwn, lle rydych chi'n ei gasglu ar gyfnodau o 30 eiliad, y funud, yna mae ail gywirdeb yn ddigon, nid oes angen dim llai arnoch chi. Ac os ydych chi'n casglu'r data hwn o systemau masnachu amledd uchel, yna mae angen cywirdeb nanosecond arnoch chi.
Mae cywirdeb millisecond yn VictoriaMetrics hefyd yn addas ar gyfer achos DevOps, a gall fod yn addas ar gyfer y rhan fwyaf o'r achosion y soniais amdanynt ar ddechrau'r adroddiad. Yr unig beth efallai nad yw'n addas ar ei gyfer yw systemau masnachu amledd uchel.
Diolch! A chwestiwn arall. Beth yw cydnawsedd yn PromQL?
Cydweddoldeb llawn tuag yn ôl. Mae VictoriaMetrics yn cefnogi PromQL yn llawn. Yn ogystal, mae'n ychwanegu ymarferoldeb uwch ychwanegol yn PromQL, a elwir . Mae sgwrs ar YouTube am y swyddogaeth estynedig hon. Siaradais yn y Monitoring Meetup yn y gwanwyn yn St Petersburg.
Sianel telegram .
Dim ond defnyddwyr cofrestredig all gymryd rhan yn yr arolwg. os gwelwch yn dda.
Beth sy'n eich atal rhag newid i VictoriaMetrics fel eich storfa hirdymor ar gyfer Prometheus? (Ysgrifennwch yn y sylwadau, byddaf yn ei ychwanegu at yr arolwg barn))
-
71,4%Dydw i ddim yn defnyddio Prometheus5
-
28,6%Ddim yn gwybod am VictoriaMetrics2
Pleidleisiodd 7 o ddefnyddwyr. Ataliodd 12 o ddefnyddwyr.
Ffynhonnell: hab.com