Siūlau perskaityti 2019 m. pabaigos Aleksandro Valyalkino ataskaitos „Optimizuokite VictoriaMetrics“ nuorašą.
— greita ir keičiamo dydžio DBVS, skirta duomenims saugoti ir apdoroti laiko eilučių pavidalu (įrašas sudaro laiką ir reikšmių rinkinį, atitinkantį šį laiką, pavyzdžiui, gaunamas periodiškai apklausiant jutiklių būseną arba renkant duomenis). metrikai).
Čia yra nuoroda į šio pranešimo vaizdo įrašą -
Papasakokite apie save. Aš esu Aleksandras Valyalkinas. Čia . Mane aistringai mėgstu „Go“ ir našumo optimizavimu. Parašiau daug naudingų ir nelabai naudingų bibliotekų. Jie prasideda nuo bet kurio fast, arba su quick priešdėlis.
Šiuo metu dirbu su VictoriaMetrics. Kas tai yra ir ką aš ten veikiu? Apie tai kalbėsiu šiame pristatyme.
Ataskaitos metmenys yra tokie:
- Pirmiausia aš jums pasakysiu, kas yra „VictoriaMetrics“.
- Tada aš jums pasakysiu, kas yra laiko eilutės.
- Tada papasakosiu, kaip veikia laiko eilučių duomenų bazė.
- Toliau papasakosiu apie duomenų bazės architektūrą: iš ko ji susideda.
- Tada pereikime prie „VictoriaMetrics“ optimizavimo. Tai yra apversto indekso optimizavimas ir bitų rinkinio diegimo optimizavimas Go.
Ar kas nors iš auditorijos žino, kas yra „VictoriaMetrics“? Oho, daug kas jau žino. Tai gera žinia. Tiems, kurie nežino, tai yra laiko eilučių duomenų bazė. Jis pagrįstas ClickHouse architektūra, kai kuriomis ClickHouse diegimo detalėmis. Pavyzdžiui, tokiuose kaip: MergeTree, lygiagretus visų turimų procesoriaus branduolių skaičiavimas ir našumo optimizavimas dirbant su duomenų blokais, patalpintais į procesoriaus talpyklą.
„VictoriaMetrics“ užtikrina geresnį duomenų glaudinimą nei kitos laiko eilučių duomenų bazės.
Jis keičiasi vertikaliai – tai yra, viename kompiuteryje galite pridėti daugiau procesorių, daugiau RAM. „VictoriaMetrics“ sėkmingai panaudos šiuos turimus išteklius ir pagerins linijinį našumą.
„VictoriaMetrics“ mastelį taip pat keičia horizontaliai – tai yra, galite pridėti papildomų mazgų prie „VictoriaMetrics“ klasterio, o jo našumas padidės beveik tiesiškai.
Kaip atspėjote, VictoriaMetrics yra greita duomenų bazė, nes aš negaliu rašyti kitų. Ir tai parašyta „Go“, todėl apie tai kalbu šiame susitikime.
Kas žino, kas yra laiko eilutė? Jis taip pat pažįsta daug žmonių. Laiko eilutė yra porų serija (timestamp, значение), kur šios poros surūšiuotos pagal laiką. Reikšmė yra slankiojo kablelio skaičius – float64.
Kiekviena laiko eilutė yra unikaliai identifikuojama pagal raktą. Iš ko susideda šis raktas? Jį sudaro netuščias raktų ir reikšmių porų rinkinys.
Čia yra laiko eilutės pavyzdys. Šios serijos raktas yra porų sąrašas: __name__="cpu_usage" yra metrikos pavadinimas, instance="my-server" – tai kompiuteris, kuriame renkama ši metrika, datacenter="us-east" – tai duomenų centras, kuriame yra šis kompiuteris.
Gavome laiko eilutės pavadinimą, sudarytą iš trijų raktų ir reikšmių porų. Šis raktas atitinka porų sąrašą (timestamp, value). t1, t3, t3, ..., tN – tai laiko žymos, 10, 20, 12, ..., 15 — atitinkamos vertės. Tai yra tam tikros serijos procesoriaus naudojimas tam tikru metu.
Kur galima naudoti laiko eilutes? Ar kas nors turi kokių nors idėjų?
- „DevOps“ galite išmatuoti procesorių, RAM, tinklą, rps, klaidų skaičių ir kt.
- IoT – galime matuoti temperatūrą, slėgį, geografines koordinates ir dar ką nors.
- Taip pat finansai – galime stebėti visų rūšių akcijų ir valiutų kainas.
- Be to, laiko eilutės gali būti naudojamos stebint gamybos procesus gamyklose. Turime vartotojų, kurie naudoja „VictoriaMetrics“ vėjo turbinoms stebėti robotams.
- Laiko eilutės taip pat naudingos renkant informaciją iš įvairių įrenginių jutiklių. Pavyzdžiui, varikliui; padangų slėgiui matuoti; greičiui, atstumui matuoti; benzino sąnaudoms matuoti ir kt.
- Laiko eilutės taip pat gali būti naudojamos orlaiviams stebėti. Kiekvienas orlaivis turi juodąją dėžę, kurioje renkamos įvairių orlaivio sveikatos parametrų laiko eilutės. Laiko eilutės taip pat naudojamos aviacijos ir kosmoso pramonėje.
- Sveikatos priežiūra yra kraujospūdis, pulsas ir kt.
Gali būti ir daugiau programų, apie kurias pamiršau, bet tikiuosi, kad supratote, kad laiko eilutės yra aktyviai naudojamos šiuolaikiniame pasaulyje. O jų panaudojimo apimtys kasmet auga.
Kodėl jums reikia laiko eilučių duomenų bazės? Kodėl laiko eilutėms saugoti negalima naudoti įprastos reliacinės duomenų bazės?
Kadangi laiko eilutėse paprastai yra daug informacijos, kurią sunku saugoti ir apdoroti įprastose duomenų bazėse. Todėl atsirado specializuotos duomenų bazės laiko eilutėms. Šios bazės efektyviai kaupia taškus (timestamp, value) su duotu raktu. Jie suteikia API, leidžiančią nuskaityti saugomus duomenis pagal raktą, pagal vieną rakto ir reikšmių porą, kelias rakto ir verčių poras arba pagal reguliarųjį sakinį. Pavyzdžiui, jei norite rasti visų savo paslaugų procesoriaus apkrovą duomenų centre Amerikoje, tuomet turite naudoti šią pseudoužklausą.
Paprastai laiko eilučių duomenų bazėse pateikiamos specializuotos užklausų kalbos, nes laiko eilučių SQL nėra labai tinkama. Nors yra duomenų bazių, palaikančių SQL, ji nelabai tinka. Užklausų kalbos, pvz , , , . Tikiuosi, kad kas nors yra girdėjęs bent vieną iš šių kalbų. Daugelis žmonių tikriausiai girdėjo apie PromQL. Tai yra „Prometheus“ užklausų kalba.
Štai kaip atrodo šiuolaikinė laiko eilučių duomenų bazės architektūra, naudojant VictoriaMetrics kaip pavyzdį.
Jis susideda iš dviejų dalių. Tai yra atvirkštinio indekso ir laiko eilučių verčių saugykla. Šios saugyklos yra atskirtos.
Kai į duomenų bazę patenka naujas įrašas, pirmiausia pasiekiame apverstą indeksą, kad surastume tam tikro rinkinio laiko eilutės identifikatorių label=value už nurodytą metriką. Surandame šį identifikatorių ir išsaugome vertę duomenų saugykloje.
Kai ateina užklausa gauti duomenis iš TSDB, pirmiausia pereiname prie apversto indekso. Paimkime viską timeseries_ids įrašai, atitinkantys šį rinkinį label=value. Ir tada mes gauname visus reikiamus duomenis iš duomenų saugyklos, indeksuotus timeseries_ids.
Pažvelkime į pavyzdį, kaip laiko eilučių duomenų bazė apdoroja gaunamą pasirinkimo užklausą.
- Pirmiausia ji gauna viską
timeseries_idsiš apversto indekso, kuriame yra nurodytos poroslabel=value, arba tenkina pateiktą reguliariąją išraišką. - Tada jis nuskaito visus duomenų taškus iš duomenų saugyklos tam tikru laiko intervalu rastiesiems
timeseries_ids. - Po to duomenų bazė atlieka tam tikrus šių duomenų taškų skaičiavimus pagal vartotojo prašymą. Ir po to grąžina atsakymą.
Šiame pristatyme papasakosiu apie pirmąją dalį. Tai yra paieška timeseries_ids pagal apverstą indeksą. Apie antrąją ir trečiąją dalį galėsite pažiūrėti vėliau , arba palaukite, kol paruošiu kitas ataskaitas :)
Pereikime prie atvirkštinio indekso. Daugelis gali manyti, kad tai paprasta. Kas žino, kas yra apverstas indeksas ir kaip jis veikia? Oi, žmonių nebėra tiek daug. Pabandykime suprasti, kas tai yra.
Iš tikrųjų tai paprasta. Tai tiesiog žodynas, kuriame nurodomas reikšmės raktas. Kas yra raktas? Ši pora label=valueKur label и value - tai linijos. Ir vertybės yra rinkinys timeseries_ids, kuri apima nurodytą porą label=value.
Apverstas indeksas leidžia greitai viską rasti timeseries_ids, kurios davė label=value.
Tai taip pat leidžia greitai rasti timeseries_ids laiko eilutes kelioms poroms label=value, arba poroms label=regexp. Kaip tai atsitinka? Suradę aibės sankirtą timeseries_ids kiekvienai porai label=value.
Pažvelkime į įvairius atvirkštinio indekso įgyvendinimus. Pradėkime nuo paprasčiausio naivaus įgyvendinimo. Ji atrodo taip.
Funkcija getMetricIDs gauna eilučių sąrašą. Kiekvienoje eilutėje yra label=value. Ši funkcija grąžina sąrašą metricIDs.
Kaip tai veikia? Čia turime visuotinį kintamąjį, vadinamą invertedIndex. Tai įprastas žodynas (map), kuri suskirstys eilutę į dalis. Linijoje yra label=value.
Funkcijos įgyvendinimas: gauti metricIDs pirmajam label=value, tada pereiname per visa kita label=value, mes tai suprantame metricIDs jiems. Ir iškvieskite funkciją intersectInts, kuris bus aptartas toliau. Ir ši funkcija grąžina šių sąrašų sankirtą.
Kaip matote, apversto indekso įdiegimas nėra labai sudėtingas. Bet tai naivus įgyvendinimas. Kokių trūkumų jis turi? Pagrindinis naivaus įgyvendinimo trūkumas yra tas, kad toks apverstas indeksas yra saugomas RAM. Iš naujo paleidę programą prarandame šį indeksą. Šis indeksas diske neišsaugomas. Toks apverstas indeksas vargu ar tiks duomenų bazei.
Antrasis trūkumas taip pat susijęs su atmintimi. Apverstas indeksas turi tilpti į RAM. Jei jis viršys RAM dydį, akivaizdu, kad gausime - iš atminties klaidos. Ir programa neveiks.
Šią problemą galima išspręsti naudojant paruoštus sprendimus, tokius kaip Arba .
Trumpai tariant, mums reikia duomenų bazės, kuri leistų greitai atlikti tris operacijas.
- Pirmoji operacija yra įrašymas
ключ-значениеį šią duomenų bazę. Ji tai daro labai greitai, kurключ-значениеyra savavališkos eilutės. - Antroji operacija yra greita reikšmės paieška naudojant nurodytą klavišą.
- Ir trečioji operacija yra greita visų verčių paieška pagal nurodytą priešdėlį.
LevelDB ir RocksDB – šias duomenų bazes sukūrė Google ir Facebook. Pirmiausia atsirado LevelDB. Tada vaikinai iš Facebook paėmė LevelDB ir pradėjo jį tobulinti, sukūrė RocksDB. Dabar beveik visos vidinės duomenų bazės veikia RocksDB Facebook viduje, įskaitant tas, kurios buvo perkeltos į RocksDB ir MySQL. Jie jį pavadino .
Apverstas indeksas gali būti įgyvendintas naudojant LevelDB. Kaip tai padaryti? Išsaugome kaip raktą label=value. O vertė yra laiko eilutės, kurioje yra pora, identifikatorius label=value.
Jei turime daug laiko eilučių su tam tikra pora label=value, tada šioje duomenų bazėje bus daug eilučių su tuo pačiu raktu ir skirtingu timeseries_ids. Norėdami gauti visų sąrašą timeseries_ids, kurie prasideda šiuo label=prefix, atliekame diapazono nuskaitymą, kuriam optimizuota ši duomenų bazė. Tai yra, mes pasirenkame visas eilutes, kurios prasideda label=prefix ir gauti reikiamą timeseries_ids.
Štai pavyzdys, kaip jis atrodytų „Go“. Turime apverstą indeksą. Tai LevelDB.
Funkcija yra tokia pati kaip ir naivaus įgyvendinimo. Ji beveik eilutė po eilutės kartoja naivų įgyvendinimą. Vienintelis dalykas yra tai, kad užuot kreipęsi į map pasiekiame apverstą indeksą. Pirmiausia gauname visas vertes label=value. Tada einame per visas likusias poras label=value ir gauti atitinkamus metrikos ID rinkinius. Tada randame sankryžą.
Atrodo, kad viskas gerai, tačiau šis sprendimas turi trūkumų. „VictoriaMetrics“ iš pradžių įdiegė apverstą indeksą, pagrįstą „LevelDB“. Bet galų gale turėjau jo atsisakyti.
Kodėl? Kadangi LevelDB yra lėtesnis nei naivus įgyvendinimas. Naiviai įgyvendinant, duotą raktą, iš karto gauname visą pjūvį metricIDs. Tai labai greita operacija – visa gabalėlis paruoštas naudojimui.
LevelDB kiekvieną kartą, kai iškviečiama funkcija GetValues reikia pereiti visas eilutes, kurios prasideda label=value. Ir gaukite kiekvienos eilutės vertę timeseries_ids. Tokio timeseries_ids surinkite jų gabalėlį timeseries_ids. Akivaizdu, kad tai yra daug lėčiau, nei tiesiog pasiekti įprastą žemėlapį raktu.
Antras trūkumas yra tas, kad LevelDB parašyta C kalba. C funkcijų iškvietimas iš Go nėra labai greitas. Tai užtrunka šimtus nanosekundžių. Tai nėra labai greita, nes lyginant su įprastu funkcijos iškvietimu, parašytu go, kuris trunka 1-5 nanosekundes, našumo skirtumas yra dešimtis kartų. „VictoriaMetrics“ tai buvo lemtinga klaida :)
Taigi aš parašiau savo apversto indekso įgyvendinimą. Ir jis jai paskambino .
Mergeset yra pagrįsta MergeTree duomenų struktūra. Ši duomenų struktūra pasiskolinta iš „ClickHouse“. Akivaizdu, kad „mergeset“ turėtų būti optimizuotas norint greitai ieškoti timeseries_ids pagal duotą raktą. Mergeset yra visiškai parašyta Go. Jūs galite pamatyti . Mergeset įgyvendinimas yra aplanke . Galite pabandyti išsiaiškinti, kas ten vyksta.
„Mergeset“ API yra labai panaši į „LevelDB“ ir „RocksDB“. Tai reiškia, kad tai leidžia greitai išsaugoti naujus įrašus ir greitai pasirinkti įrašus pagal nurodytą priešdėlį.
Apie mergeset trūkumus kalbėsime vėliau. Dabar pakalbėkime apie tai, kokios problemos kilo su „VictoriaMetrics“ gamyboje diegiant apverstą indeksą.
Kodėl jie atsirado?
Pirmoji priežastis – aukštas nešvarumų skaičius. Išvertus į rusų kalbą, tai dažnas laiko eilučių pasikeitimas. Tai yra tada, kai baigiasi laiko eilutė ir prasideda nauja serija arba prasideda daug naujų laiko eilučių. Ir tai atsitinka dažnai.
Antroji priežastis – didelis laiko eilučių skaičius. Pradžioje, kai monitoringas populiarėjo, laiko eilučių skaičius buvo mažas. Pavyzdžiui, kiekvienam kompiuteriui reikia stebėti procesoriaus, atminties, tinklo ir disko apkrovą. 4 laiko eilutės vienam kompiuteriui. Tarkime, kad turite 100 kompiuterių ir 400 laiko eilučių. Tai labai mažai.
Laikui bėgant žmonės suprato, kad gali išmatuoti išsamesnę informaciją. Pavyzdžiui, matuokite ne viso procesoriaus, o kiekvieno procesoriaus branduolio apkrovą atskirai. Jei turite 40 procesoriaus branduolių, procesoriaus apkrovai matuoti turite 40 kartų daugiau laiko eilučių.
Bet tai dar ne viskas. Kiekvienas procesoriaus branduolys gali turėti keletą būsenų, pvz., neaktyvus, kai jis yra neaktyvus. Taip pat dirbti vartotojo erdvėje, dirbti branduolio erdvėje ir kitose būsenose. Ir kiekviena tokia būsena taip pat gali būti matuojama kaip atskira laiko eilutė. Tai papildomai padidina eilučių skaičių 7-8 kartus.
Iš vienos metrikos gavome 40 x 8 = 320 metrikų tik vienam kompiuteriui. Padauginus iš 100, vietoj 32 gausime 000 400.
Tada atėjo Kubernetes. Ir tai pablogėjo, nes „Kubernetes“ gali priimti daugybę skirtingų paslaugų. Kiekviena „Kubernetes“ paslauga susideda iš daugybės paketų. Ir visa tai reikia stebėti. Be to, mes nuolat diegiame naujas jūsų paslaugų versijas. Kiekvienai naujai versijai turi būti sukurtos naujos laiko eilutės. Dėl to laiko eilučių skaičius auga eksponentiškai ir susiduriame su didelio skaičiaus laiko eilučių problema, kuri vadinama didelio kardinalumo. „VictoriaMetrics“ su juo sėkmingai susidoroja, palyginti su kitomis laiko eilučių duomenų bazėmis.
Pažvelkime atidžiau į aukštą dingimo dažnį. Kas lemia didelį gamybos nutraukimą? Nes kai kurios etikečių ir žymų reikšmės nuolat kinta.
Pavyzdžiui, paimkite Kubernetes, kuri turi koncepciją deployment, t. y. kai išleidžiama nauja programos versija. Dėl tam tikrų priežasčių „Kubernetes“ kūrėjai nusprendė pridėti diegimo ID prie etiketės.
Prie ko tai privedė? Be to, su kiekvienu nauju diegimu, visos senos laiko eilutės yra nutraukiamos, o vietoj jų pradedamos naujos laiko eilutės su nauja etiketės reikšme. deployment_id. Tokių eilučių gali būti šimtai tūkstančių ir net milijonai.
Visa tai svarbu tai, kad bendras laiko eilučių skaičius auga, tačiau laiko eilučių, kurios šiuo metu yra aktyvios ir gauna duomenis, skaičius išlieka pastovus. Ši būsena vadinama dideliu churn rate.
Pagrindinė problema dėl didelio kreipimosi greičio yra užtikrinti pastovų visų laiko eilučių paieškos greitį tam tikram etikečių rinkiniui per tam tikrą laiko intervalą. Paprastai tai yra paskutinės valandos arba paskutinės dienos laiko intervalas.
Kaip išspręsti šią problemą? Štai pirmas variantas. Taip apverstą indeksą reikia padalyti į nepriklausomas dalis laikui bėgant. Tai yra, praeina tam tikras laiko intervalas, baigiame dirbti su dabartiniu apverstu indeksu. Ir sukurkite naują apverstą indeksą. Praeina kitas laiko intervalas, kuriame kitą ir kitą.
Ir imdami iš šių apverstų indeksų, randame apverstų indeksų rinkinį, kuris patenka į nurodytą intervalą. Ir atitinkamai iš ten pasirenkame laiko eilutės ID.
Taip taupomi ištekliai, nes nereikia žiūrėti į dalių, kurios nepatenka į nurodytą intervalą. Tai yra, paprastai, jei pasirenkame paskutinės valandos duomenis, ankstesniais laiko intervalais praleidžiame užklausas.
Yra dar vienas šios problemos sprendimo variantas. Tai skirta kiekvienai dienai išsaugoti atskirą tą dieną įvykusių laiko eilučių ID sąrašą.
Šio sprendimo pranašumas, palyginti su ankstesniu sprendimu, yra tas, kad mes nedubliuojame laiko eilučių informacijos, kuri laikui bėgant neišnyksta. Jie nuolat yra ir nesikeičia.
Trūkumas yra tas, kad tokį sprendimą sunkiau įgyvendinti ir sunkiau derinti. Ir VictoriaMetrics pasirinko šį sprendimą. Taip atsitiko istoriškai. Šis sprendimas taip pat gerai veikia, palyginti su ankstesniu. Kadangi šis sprendimas nebuvo įgyvendintas dėl to, kad kiekviename skirsnyje reikia dubliuoti duomenis laiko eilutėms, kurios nesikeičia, t.y. kurios laikui bėgant neišnyksta. „VictoriaMetrics“ pirmiausia buvo optimizuota vietos diske sunaudojimui, o ankstesnis diegimas sumažino vietos diske suvartojimą. Tačiau šis diegimas labiau tinka norint sumažinti disko vietos suvartojimą, todėl buvo pasirinktas jis.
Turėjau su ja kovoti. Kova buvo ta, kad šiame įgyvendinime vis tiek reikia pasirinkti daug didesnį skaičių timeseries_ids duomenims nei tada, kai apverstas indeksas yra padalintas į laiką.
Kaip mes išsprendėme šią problemą? Ją išsprendėme originaliai – kiekviename apverstame indekso įraše vietoj vieno identifikatoriaus išsaugojome kelis laiko eilučių identifikatorius. Tai yra, mes turime raktą label=value, kuris pasitaiko kiekvienoje laiko eilutėje. O dabar išsaugome keletą timeseries_ids viename įraše.
Štai pavyzdys. Anksčiau turėjome N įrašų, bet dabar turime vieną įrašą, kurio priešdėlis yra toks pat kaip ir visų kitų. Ankstesnio įrašo vertėje yra visi laiko eilučių ID.
Tai leido padidinti tokio apversto indekso nuskaitymo greitį iki 10 kartų. Ir tai leido mums sumažinti talpyklos atminties suvartojimą, nes dabar saugome eilutę label=value tik vieną kartą talpykloje kartu N kartų. Ir ši eilutė gali būti didelė, jei žymose ir etiketėse laikote ilgas eilutes, kurias Kubernetes mėgsta ten įstumti.
Kitas būdas paspartinti paiešką apverstame indekse yra skilimas. Sukurti kelis apverstus indeksus vietoj vieno ir dalyti duomenis tarp jų pagal raktą. Tai rinkinys key=value garai. Tai reiškia, kad gauname keletą nepriklausomų apverstų indeksų, kurių užklausą galime atlikti lygiagrečiai keliuose procesoriuose. Ankstesni diegimai leido veikti tik vieno procesoriaus režimu, t. y. nuskaityti duomenis tik viename branduolyje. Šis sprendimas leidžia nuskaityti duomenis keliuose branduoliuose vienu metu, kaip mėgsta ClickHouse. Tai ir planuojame įgyvendinti.
Dabar grįžkime prie savo avelių – prie sankryžos funkcijos timeseries_ids. Pasvarstykime, kokie gali būti įgyvendinimai. Ši funkcija leidžia rasti timeseries_ids tam tikram rinkiniui label=value.
Pirmasis variantas yra naivus įgyvendinimas. Dvi įdėtos kilpos. Čia gauname funkcijos įvestį intersectInts dvi skiltelės - a и b. Išvestyje ji turėtų grąžinti mums šių griežinėlių sankirtą.
Naivus įgyvendinimas atrodo taip. Mes kartojame visas skilties vertes a, šios kilpos viduje pereiname per visas pjūvio reikšmes b. Ir mes juos lyginame. Jeigu jie sutampa, vadinasi, radome sankryžą. Ir išsaugokite jį result.
Kokie trūkumai? Pagrindinis jo trūkumas yra kvadratinis sudėtingumas. Pavyzdžiui, jei jūsų matmenys yra gabalas a и b po milijoną vienu metu, tada ši funkcija niekada jums neatsakys. Nes reikės atlikti trilijoną iteracijų, o tai yra daug net šiuolaikiniams kompiuteriams.
Antrasis įgyvendinimas pagrįstas žemėlapiu. Kuriame žemėlapį. Į šį žemėlapį įtraukėme visas skilties vertes a. Tada mes einame per pjūvį atskira kilpa b. Ir mes patikriname, ar ši vertė yra iš pjūvio b žemėlapyje. Jei jis egzistuoja, pridėkite jį prie rezultato.
Kokia nauda? Privalumas yra tas, kad yra tik linijinis sudėtingumas. Tai reiškia, kad didesnių gabalų funkcija bus vykdoma daug greičiau. Milijono dydžio skiltyje ši funkcija bus vykdoma 2 milijonais iteracijų, priešingai nei trilijonai ankstesnės funkcijos iteracijų.
Neigiama yra tai, kad norint sukurti šią funkciją, reikia daugiau atminties.
Antrasis trūkumas yra didelės maišos pridėtinės išlaidos. Šis trūkumas nėra labai akivaizdus. Ir mums tai taip pat nebuvo labai akivaizdu, todėl iš pradžių VictoriaMetrics sankryžos įgyvendinimas buvo per žemėlapį. Bet tada profiliavimas parodė, kad pagrindinis procesoriaus laikas sugaišta rašant į žemėlapį ir tikrinant, ar šiame žemėlapyje yra reikšmės.
Kodėl šiose vietose švaistomas procesoriaus laikas? Kadangi Go šiose eilutėse atlieka maišos operaciją. Tai reiškia, kad jis apskaičiuoja rakto maišą, kad vėliau jį pasiektų tam tikrame indekse HashMap. Maišos skaičiavimo operacija baigiama per keliasdešimt nanosekundžių. „VictoriaMetrics“ tai vyksta lėtai.
Nusprendžiau įdiegti specialiai šiam atvejui optimizuotą bitų rinkinį. Taip dabar atrodo dviejų pjūvių susikirtimas. Čia sukuriame bitų rinkinį. Į jį pridedame elementus iš pirmos pjūvio. Tada patikriname šių elementų buvimą antrajame pjūvyje. Ir pridėkite juos prie rezultato. Tai yra, jis beveik nesiskiria nuo ankstesnio pavyzdžio. Vienintelis dalykas yra tai, kad prieigą prie žemėlapio pakeitėme pasirinktinėmis funkcijomis add и has.
Iš pirmo žvilgsnio atrodo, kad tai turėtų veikti lėčiau, jei anksčiau ten buvo naudojamas standartinis žemėlapis, o tada iškviečiamos kokios nors kitos funkcijos, tačiau profiliavimas rodo, kad VictoriaMetrics atveju šis dalykas veikia 10 kartų greičiau nei standartinis žemėlapis.
Be to, jis naudoja daug mažiau atminties, palyginti su žemėlapio įgyvendinimu. Nes čia saugome bitus, o ne aštuonių baitų reikšmes.
Šio įgyvendinimo trūkumas yra tas, kad jis nėra toks akivaizdus, nebanalus.
Kitas trūkumas, kurio daugelis gali nepastebėti, yra tas, kad kai kuriais atvejais šis diegimas gali neveikti gerai. Tai yra, jis optimizuotas konkrečiam atvejui, šiam VictoriaMetrics laiko eilučių ID susikirtimo atvejui. Tai nereiškia, kad jis tinka visais atvejais. Jei jis naudojamas neteisingai, sulauksime ne našumo padidėjimo, o atminties trūkumo klaidos ir našumo sulėtėjimo.
Panagrinėkime šios struktūros įgyvendinimą. Jei norite ieškoti, jis yra „VictoriaMetrics“ šaltiniuose, aplanke . Jis optimizuotas specialiai VictoriaMetrics dėklui, kur timeseries_id yra 64 bitų reikšmė, kur pirmieji 32 bitai iš esmės yra pastovūs ir keičiasi tik paskutiniai 32 bitai.
Ši duomenų struktūra nėra saugoma diske, ji veikia tik atmintyje.
Čia yra jo API. Tai nėra labai sudėtinga. API yra specialiai pritaikyta konkrečiam VictoriaMetrics naudojimo pavyzdžiui. Tai yra, čia nėra nereikalingų funkcijų. Štai funkcijos, kurias aiškiai naudoja VictoriaMetrics.
Yra funkcijos add, kuri prideda naujų reikšmių. Yra funkcija has, kuri tikrina, ar nėra naujų verčių. Ir yra funkcija del, kuris pašalina vertybes. Yra pagalbinė funkcija len, kuris grąžina rinkinio dydį. Funkcija clone klonuoja daug. Ir funkcija appendto paverčia šį rinkinį į skiltį timeseries_ids.
Taip atrodo šios duomenų struktūros įgyvendinimas. rinkinį sudaro du elementai:
-
ItemsCountyra pagalbinis laukas, leidžiantis greitai grąžinti rinkinio elementų skaičių. Galima būtų apsieiti ir be šio pagalbinio lauko, bet jį čia reikėjo pridėti, nes „VictoriaMetrics“ savo algoritmuose dažnai klausia bitų rinkinio ilgio. -
Antrasis laukas yra
buckets. Tai yra struktūros dalisbucket32. Kiekviena struktūra saugohilauke. Tai yra viršutiniai 32 bitai. Ir dvi skiltelės -b16hisиbucketsišbucket16struktūros.
Čia saugomi 16 geriausių antrosios 64 bitų struktūros dalies bitų. Ir čia saugomi kiekvieno baito apatiniai 16 bitų bitų rinkiniai.
Bucket64 susideda iš masyvo uint64. Ilgis apskaičiuojamas naudojant šias konstantas. Viename bucket16 galima saugoti daugiausiai 2^16=65536 šiek tiek. Jei padalysite tai iš 8, tai bus 8 kilobaitai. Jei dar kartą padalinsite iš 8, tai bus 1000 uint64 prasmė. Tai yra Bucket16 – tai mūsų 8 kilobaitų struktūra.
Pažiūrėkime, kaip įgyvendinamas vienas iš šios struktūros būdų pridėti naują vertę.
Viskas prasideda nuo uint64 reikšmės. Apskaičiuojame viršutinius 32 bitus, skaičiuojame apatinius 32 bitus. Pergyvenkime viską buckets. Mes lyginame 32 geriausius kiekvieno segmento bitus su pridedama verte. Ir jei jie sutampa, tada vadiname funkciją add struktūroje b32 buckets. Ir ten pridėkite apatinius 32 bitus. O jei grįžtų true, tai reiškia, kad mes ten pridėjome tokią vertę, o tokios vertės neturėjome. Jei grįš false, tada tokia reikšmė jau egzistavo. Tada padidiname elementų skaičių struktūroje.
Jei neradome jums reikalingo bucket su reikiama hi-reikšme, tada iškviečiame funkciją addAlloc, kuri gamins naują bucket, pridedant jį prie kibiro struktūros.
Tai yra funkcijos įgyvendinimas b32.add. Tai panašu į ankstesnį įgyvendinimą. Skaičiuojame reikšmingiausius 16 bitų, mažiausiai reikšmingus 16 bitų.
Tada pereiname visus viršutinius 16 bitų. Surandame atitikmenis. Ir jei yra atitiktis, vadiname pridėjimo metodą, kurį apsvarstysime kitame puslapyje bucket16.
O čia – žemiausias lygis, kurį reikėtų kiek įmanoma optimizuoti. Skaičiuojame už uint64 id reikšmė slice bite ir taip pat bitmask. Tai yra tam tikros 64 bitų reikšmės kaukė, kurią galima naudoti norint patikrinti šio bito buvimą arba jį nustatyti. Mes patikriname, ar šis bitas nustatytas, nustatome jį ir grąžiname buvimą. Tai yra mūsų įgyvendinimas, kuris leido mums 10 kartų pagreitinti susikertančių laiko eilučių ID, palyginti su įprastais žemėlapiais.
Be šio optimizavimo, VictoriaMetrics turi daug kitų optimizacijų. Dauguma šių optimizacijų buvo pridėtos dėl priežasties, tačiau po kodo profiliavimo gamyboje.
Tai yra pagrindinė optimizavimo taisyklė – nepridėkite optimizavimo darant prielaidą, kad čia bus kliūtis, nes gali pasirodyti, kad kliūties ten nebus. Optimizavimas paprastai pablogina kodo kokybę. Todėl optimizuoti verta tik po profiliavimo ir geriausia gamyboje, kad tai būtų tikri duomenys. Jei kas nors domisi, galite peržiūrėti „VictoriaMetrics“ šaltinio kodą ir ištirti kitus ten esančius optimizavimo būdus.
Turiu klausimą dėl bitset. Labai panašus į C++ vektorinio bool įgyvendinimą, optimizuotas bitų rinkinys. Ar įgyvendinimą perėmėte iš ten?
Ne, ne iš ten. Diegiant šį bitų rinkinį vadovavausi žiniomis apie šių ids laiko eilučių, naudojamų „VictoriaMetrics“, struktūrą. O jų struktūra tokia, kad viršutiniai 32 bitai iš esmės yra pastovūs. Apatiniai 32 bitai gali keistis. Kuo žemesnis antgalis, tuo dažniau jis gali keistis. Todėl šis diegimas yra specialiai optimizuotas šiai duomenų struktūrai. C++ diegimas, kiek žinau, yra optimizuotas bendram atvejui. Jei optimizuosite bendram atvejui, tai reiškia, kad konkrečiam atvejui jis nebus pats optimaliausias.
Taip pat patariu pažiūrėti Aleksejaus Milovido reportažą. Maždaug prieš mėnesį jis kalbėjo apie „ClickHouse“ optimizavimą konkrečioms specializacijoms. Jis tik sako, kad paprastai C++ diegimas ar koks kitas diegimas yra pritaikytas taip, kad vidutiniškai gerai veiktų ligoninėje. Jis gali veikti blogiau nei specifinis žinių diegimas, kaip mūsų, kai žinome, kad 32 didžiausi bitai dažniausiai yra pastovūs.
Turiu antrą klausimą. Kuo esminis skirtumas nuo „InfluxDB“?
Yra daug esminių skirtumų. Kalbant apie našumą ir atminties suvartojimą, InfluxDB testuose rodo 10 kartų daugiau atminties suvartojimo didelio kardinalumo laiko eilutėms, kai jų turite daug, pavyzdžiui, milijonus. Pavyzdžiui, „VictoriaMetrics“ sunaudoja 1 GB vienam milijonui aktyvių eilučių, o „InfluxDB“ – 10 GB. Ir tai yra didelis skirtumas.
Antras esminis skirtumas yra tas, kad InfluxDB turi keistas užklausų kalbas – Flux ir InfluxQL. Jie nėra labai patogūs dirbti su laiko eilutėmis, palyginti su , kurią palaiko VictoriaMetrics. PromQL yra užklausų kalba iš Prometheus.
Ir dar vienas skirtumas yra tas, kad InfluxDB turi šiek tiek keistą duomenų modelį, kai kiekvienoje eilutėje galima saugoti kelis laukus su skirtingu žymų rinkiniu. Šios eilutės dar skirstomos į įvairias lenteles. Šios papildomos komplikacijos apsunkina tolesnį darbą su šia duomenų baze. Sunku palaikyti ir suprasti.
„VictoriaMetrics“ viskas yra daug paprasčiau. Ten kiekviena laiko eilutė yra pagrindinė reikšmė. Vertė yra taškų rinkinys - (timestamp, value), o raktas yra rinkinys label=value. Nėra skirtumo tarp laukų ir matavimų. Tai leidžia pasirinkti bet kokius duomenis ir tada sujungti, sudėti, atimti, dauginti, padalyti, skirtingai nei InfluxDB, kur skaičiavimai tarp skirtingų eilučių, kiek aš žinau, vis dar nėra įgyvendinami. Net jei jie įgyvendinami, sunku, reikia parašyti daug kodo.
Turiu patikslinantį klausimą. Ar teisingai supratau, kad yra kažkokia problema, apie kurią kalbėjote, kad šis apverstas indeksas netelpa į atmintį, todėl ten yra skaidymas?
Pirma, aš parodžiau naivų apverstos indekso įgyvendinimą standartiniame „Go“ žemėlapyje. Šis diegimas netinka duomenų bazėms, nes šis apverstas indeksas nėra išsaugomas diske, o duomenų bazė turi būti išsaugota diske, kad šie duomenys liktų pasiekiami paleidus iš naujo. Šiuo atveju, kai iš naujo paleisite programą, apverstas indeksas išnyks. Ir jūs prarasite prieigą prie visų duomenų, nes negalėsite jų rasti.
Sveiki! Ačiū už pranešimą! Mano vardas Pavelas. Aš esu iš Wildberry. Turiu jums keletą klausimų. Klausimas vienas. Ar manote, kad jei kurdami savo programos architektūrą būtumėte pasirinkę kitą principą ir laikui bėgant suskirstę duomenis į skaidinius, galbūt ieškodami būtumėte galėję susikirsti duomenis, remdamiesi tik tuo, kad viename skaidinyje yra duomenys vienam laiko tarpą , tai yra per vieną laiko intervalą ir jums nereikėtų jaudintis dėl to, kad jūsų kūriniai yra išsibarstę skirtingai? Klausimas numeris 2 - kadangi jūs įgyvendinate panašų algoritmą su bitų rinkiniu ir visa kita, tai galbūt bandėte naudoti procesoriaus instrukcijas? Gal kas bandėte tokius optimizavimus?
Iš karto atsakysiu į antrą. Mes dar nepasiekėme to taško. Bet jei reikės, mes ten pateksime. Ir pirmas, koks buvo klausimas?
Aptarėte du scenarijus. Ir jie sakė, kad pasirinko antrąjį su sudėtingesniu įgyvendinimu. Ir jie nemėgo pirmojo, kur duomenys skirstomi pagal laiką.
Taip. Pirmuoju atveju bendra indekso apimtis būtų didesnė, nes kiekviename skaidinyje turėtume saugoti pasikartojančius duomenis tų laiko eilučių, kurios tęsiasi per visus šiuos skaidinius. Ir jei jūsų laiko eilučių churn rate yra mažas, t.y. nuolat naudojamos tos pačios eilutės, tai pirmuoju atveju prarastume daug daugiau užimamos vietos diske, palyginti su antruoju atveju.
Taigi – taip, laiko skirstymas yra geras pasirinkimas. Prometėjas tuo naudojasi. Tačiau Prometėjas turi dar vieną trūkumą. Sujungiant šias duomenų dalis, atmintyje turi būti išsaugota visų etikečių ir laiko eilučių metainformacija. Todėl, jei sujungiami duomenys yra dideli, suliejimo metu atminties suvartojimas labai padidėja, skirtingai nei VictoriaMetrics. Sujungdama „VictoriaMetrics“ visiškai nenaudoja atminties, sunaudojama tik pora kilobaitų, neatsižvelgiant į sujungtų duomenų vienetų dydį.
Naudojamas algoritmas naudoja atmintį. Jis žymi laiko serijos žymas, kuriose yra verčių. Ir tokiu būdu jūs patikrinate, ar nėra suporuoto buvimo viename duomenų masyve ir kitame. Ir jūs suprantate, ar susikirtimas įvyko, ar ne. Paprastai duomenų bazėse įdiegiami žymekliai ir iteratoriai, kurie saugo jų dabartinį turinį ir paleidžia surūšiuotus duomenis dėl paprasto šių operacijų sudėtingumo.
Kodėl mes nenaudojame žymeklio duomenims naršyti?
Taip.
Surūšiuotas eilutes saugome LevelDB arba mergeset. Galime perkelti žymeklį ir rasti sankryžą. Kodėl mes jo nenaudojame? Nes tai lėta. Kadangi žymekliai reiškia, kad kiekvienai eilutei reikia iškviesti funkciją. Funkcijos iškvietimas yra 5 nanosekundės. O jei turite 100 000 000 eilučių, tada išeina, kad tik funkcijai iškviesti praleidžiame pusę sekundės.
Yra toks dalykas, taip. Ir paskutinis mano klausimas. Klausimas gali skambėti šiek tiek keistai. Kodėl tuo metu, kai gaunami duomenys, neįmanoma nuskaityti visų reikalingų suvestinių ir išsaugoti juos reikiama forma? Kodėl kai kuriose sistemose, pvz., „VictoriaMetrics“, „ClickHouse“ ir kt., reikia sutaupyti didžiulius kiekius, o paskui praleisti joms daug laiko?
Pateiksiu pavyzdį, kad būtų aiškiau. Tarkime, kaip veikia mažas žaislinis spidometras? Jis fiksuoja jūsų nuvažiuotą atstumą, visą laiką pridedant jį prie vienos reikšmės, o antrą – laiką. Ir dalijasi. Ir gauna vidutinį greitį. Jūs galite padaryti maždaug tą patį. Sudėkite visus reikalingus faktus.
Gerai, supratau klausimą. Jūsų pavyzdys turi savo vietą. Jei žinote, kokių agregatų jums reikia, tai yra geriausias įgyvendinimas. Tačiau problema yra ta, kad žmonės išsaugo šias metrikas, kai kuriuos duomenis „ClickHouse“ ir dar nežino, kaip juos kaups ir filtruos ateityje, todėl jie turi išsaugoti visus neapdorotus duomenis. Bet jei žinote, kad reikia ką nors apskaičiuoti vidutiniškai, kodėl gi to neapskaičiuojus, o ne ten saugojus krūvą neapdorotų verčių? Bet tai tik tuo atveju, jei tiksliai žinote, ko jums reikia.
Beje, duomenų bazės, skirtos laiko eilutėms saugoti, palaiko suvestinių rodiklių skaičiavimą. Pavyzdžiui, Prometėjas palaiko . Tai yra, tai galima padaryti, jei žinote, kokių vienetų jums reikės. „VictoriaMetrics“ to dar neturi, tačiau dažniausiai prieš jį yra „Prometheus“, kuriame tai galima padaryti perkodavimo taisyklėse.
Pavyzdžiui, ankstesniame darbe reikėjo suskaičiuoti įvykių skaičių stumdomame lange per paskutinę valandą. Problema ta, kad turėjau sukurti pasirinktinį diegimą „Go“, t. y. paslaugą, skirtą šio dalyko skaičiavimui. Ši paslauga galiausiai buvo nebanali, nes ją sunku apskaičiuoti. Diegimas gali būti paprastas, jei reikia skaičiuoti kai kuriuos suvestinius duomenis nustatytais laiko intervalais. Jei norite skaičiuoti įvykius stumdomame lange, tai nėra taip paprasta, kaip atrodo. Manau, kad tai dar neįdiegta nei ClickHouse, nei timeseries duomenų bazėse, nes tai sunkiai įgyvendinama.
Ir dar vienas klausimas. Mes tik kalbėjome apie vidurkį, ir aš prisiminiau, kad kažkada buvo toks dalykas kaip grafitas su anglies pagrindu. Ir jis mokėjo išretinti senus duomenis, tai yra palikti vieną tašką per minutę, vieną tašką per valandą ir pan. Iš esmės tai yra gana patogu, jei mums reikia neapdorotų duomenų, santykinai kalbant, mėnesiui, o visa kita gali būti išretintas. Tačiau „Prometheus“ ir „VictoriaMetrics“ nepalaiko šios funkcijos. Ar planuojama jį paremti? Jei ne, kodėl gi ne?
Ačiū už klausimą. Mūsų vartotojai periodiškai užduoda šį klausimą. Jie klausia, kada pridėsime palaikymą mažinant atranką. Čia yra keletas problemų. Pirma, kiekvienas vartotojas supranta downsampling kažkas kitokio: kažkas nori gauti bet kokį savavališką tašką tam tikrame intervale, kažkas nori maksimalių, minimalių, vidutinių verčių. Jei daugelis sistemų įrašo duomenis į jūsų duomenų bazę, negalite jų sujungti. Gali būti, kad kiekvienai sistemai reikalingas skirtingas retinimas. Ir tai sunku įgyvendinti.
Ir antras dalykas yra tai, kad „VictoriaMetrics“, kaip ir „ClickHouse“, yra optimizuotas darbui su dideliais neapdorotų duomenų kiekiais, todėl gali per mažiau nei sekundę nustumti milijardą eilučių, jei jūsų sistemoje yra daug branduolių. „VictoriaMetrics“ laiko eilutės taškų nuskaitymas – 50 000 000 taškų per sekundę vienam branduoliui. Ir šis našumas pritaikomas esamiems branduoliams. Tai yra, jei, pavyzdžiui, turite 20 branduolių, nuskaitysite milijardą taškų per sekundę. Ir ši „VictoriaMetrics“ ir „ClickHouse“ savybė sumažina atrankos poreikį.
Kita ypatybė yra ta, kad „VictoriaMetrics“ efektyviai suspaudžia šiuos duomenis. Vidutinis glaudinimas gamyboje yra nuo 0,4 iki 0,8 baito vienam taškui. Kiekvienas taškas yra laiko žyma + reikšmė. Ir jis vidutiniškai suglaudinamas į mažiau nei vieną baitą.
Sergejus. Aš turiu klausimą. Koks yra minimalus įrašymo laiko kvantas?
Viena milisekundė. Neseniai kalbėjomės su kitais laiko eilučių duomenų bazių kūrėjais. Minimali jų laiko dalis yra viena sekundė. Ir, pavyzdžiui, grafite tai taip pat viena sekundė. OpenTSDB tai taip pat yra viena sekundė. InfluxDB turi nanosekundžių tikslumą. „VictoriaMetrics“ tai yra viena milisekundė, o „Prometheus“ – viena milisekundė. Ir „VictoriaMetrics“ iš pradžių buvo sukurta kaip nuotolinė „Prometheus“ saugykla. Tačiau dabar ji gali išsaugoti duomenis iš kitų sistemų.
Asmuo, su kuriuo kalbėjausi, sako, kad jų tikslumas yra nuo sekundės iki sekundės – jiems to pakanka, nes tai priklauso nuo duomenų, kurie saugomi laiko eilučių duomenų bazėje, tipo. Jei tai DevOps duomenys arba duomenys iš infrastruktūros, kur juos renkate kas 30 sekundžių, per minutę, tada užtenka sekundės tikslumo, nereikia nieko mažiau. Ir jei renkate šiuos duomenis iš aukšto dažnio prekybos sistemų, jums reikia nanosekundžių tikslumo.
Milisekundžių tikslumas „VictoriaMetrics“ taip pat tinka „DevOps“ atvejui ir gali būti tinkamas daugeliui atvejų, kuriuos minėjau ataskaitos pradžioje. Vienintelis dalykas, kuriam jis gali netikti, yra aukšto dažnio prekybos sistemos.
Ačiū! Ir kitas klausimas. Kas yra PromQL suderinamumas?
Visiškas atgalinis suderinamumas. „VictoriaMetrics“ visiškai palaiko „PromQL“. Be to, jis prideda papildomų išplėstinių funkcijų PromQL, kuri vadinama . „YouTube“ kalbama apie šią išplėstinę funkciją. Aš kalbėjau Monitoring Meetup pavasarį Sankt Peterburge.
Telegramos kanalas .
Apklausoje gali dalyvauti tik registruoti vartotojai. , Prašau.
Kas trukdo jums pereiti prie „VictoriaMetrics“ kaip ilgalaikės „Prometheus“ saugyklos? (Rašykite komentaruose, įtrauksiu į apklausą))
-
71,4%Nenaudoju Prometheus5
-
28,6%Nežinojau apie VictoriaMetrics2
Balsavo 7 vartotojų. 12 vartotojai susilaikė.
Šaltinis: www.habr.com