🥇Go optimizations in VictoriaMetrics. Aleksandr Valjalkin

Soovitan tutvuda 2019. aasta lõpudokumendi Aleksandr Valjalkini "Go optimeerimised VictoriaMetricsis" tõlgendusega.

VictoriaMetrics — kiire ja skaleeritav andmebaas ajaseeriaandmete salvestamiseks ja töötlemiseks (salvestus loob aja ja vastava ajaga seotud väärtuste kogumi, näiteks sensorite oleku perioodilise küsitluse või statistikate kogumise kaudu saadud väärtused).

Siin on link selle dokumendi video juurde — https://youtu.be/MZ5P21j_HLE

Esitlused

Räägin natuke endast. Mina olen Aleksandr Valjalkin. Siin on minu GitHubi konto. Mulle meeldib Go ja jõudluse optimeerimine. Olen kirjutanud palju erinevaid kasulikke ja vähem kasulikke teeke. Need algavad kas kiire, or with väga kiire eelvormiga.

Hetkel töötan VictoriaMetricsi kallal. Mis see on ja mida ma seal teen? Sellest räägin oma esitlusel.

Dokumendi plaan on järgmine:

Esmalt räägin teile, mis on VictoriaMetrics.
Siis räägin, mis on ajaseeriate andmed.
Seejärel räägin, kuidas ajaseeria andmebaas töötab.
Järgmisena räägin andmebaasi arhitektuurist: millest see koosneb.
Ja lõpuks räägin VictoriaMetricsi optimeerimisest. Need on optimeerimine pöördindeksile ja bitseti rakenduse optimeerimine Go-s.

Mis on VictoriaMetrics? Kas keegi publikust teab? Vau, juba palju inimesi teab. See on hea uudis. Neile, kes ei tea - see on ajasüsteemide andmebaas. See põhineb ClickHouse arhitektuuril ja mõningatel ClickHouse'i rakenduse detailidel. Näiteks sellistel nagu: MergeTree, paralleelse töötlemise kasutamine kõigil saadaval olevatel protsessorituumadel ja jõudluse optimeerimine andmeplokkide töötlemise kaudu, mis salvestatakse protsessori vahemälu.

VictoriaMetrics pakub andmete parimat tihendust võrreldes teiste ajasüsteemide andmebaasidega.

See skaleerub vertikaalselt - st saate lisada rohkem protsessoreid, rohkem mälu ühte arvutisse. VictoriaMetrics suudab neid ressursse tõhusalt kasutada ja parandada lineaarselt jõudlust.

Samuti skaleerub VictoriaMetrics horitontaalselt - st saate lisada VictoriaMetricsi klastrisse täiendavaid sõlmi ja selle jõudlus kasvab peaaegu lineaarselt.

Kuidas te arvate, VictoriaMetrics on kiire andmebaas, sest ma ei saa rääkida teistest. Ja see on kirjutatud Go keeles, seetõttu räägin sellest kohtumisel.

Kes teab, mis on ajavarras? Paljud inimesed teavad. Ajavarras on paaride seeria (timestamp, väärtus), kus need paarid on järjestatud aja järgi. Väärtus esindab end floating-point numbrit – float64.

Iga ajavarras identifitseeritakse ainulaadse võtmega. Mis sellest võtmetest koosneb? See koosneb mitte-tühjast paaride komplektist võtme-väärtuse.

Siin on ajavarra näide. Selle varda võti on paaride nimekiri: __name__="cpu_usage" – see on mõõtme nimi, instance="my-server" — see on arvuti, kus see mõõtmine on kogutud, datacenter="us-east" — see on andmekeskus, kus see arvuti asub.

Saime ajavarra nime, mis koosneb kolmest võtme-väärtuse paarist. Selle võtme juurde kuulub paaride nimekiri (timestamp, value). t1, t3, t3, ..., tN — need on ajatemperatuurid, 10, 20, 12, ..., 15 — vastavad väärtused. See on cpu kasutus praeguses ajahetkes selle vara jaoks.

Kus ajavarrasid saab kasutada? Kas kellegil on ideid?

DevOps'is saab mõõta CPU, RAM, võrgu, rps, vigade arvu jne koormust.
IoT – saame mõõta temperatuuri, rõhku, geo koorde ja muid näitajaid.
Samuti finantssektor – saame jälgida aktsiate ja valuutade hindu.
Lisaks sellele saab ajasirne jälgimiseks kasutada tootmisprotsesside jälgimiseks tehastes. Meil on kasutajaid, kes kasutavad VictoriaMetrics tuulegeneraatoreid jälgimiseks, ka robotite jälgimiseks.
Ajandirad on samuti kasulikud teabe kogumiseks erinevatelt seadmete sensoritelt. Näiteks mootorile; rehvirõhu mõõtmiseks; kiirus, kaugus; kütusekulu mõõtmiseks jne.
Ajandirad võivad sama moodi olla kasutusel lennukite jälgimiseks. Igas lennukis on must kast, mis kogub ajandiread erinevate lennuki tervise parameetrite kohta. Ajandirad on samuti kasutusel kosmosetööstuses.
Tervishoid – see hõlmab vererõhku, pulssi jne.

Võib-olla on veel rakendusi, millele ma ei ole mõelnud, kuid loodan, et te mõistate, et ajandirad on kaasaegses maailmas aktiivselt kasutusel. Ja nende kasutuse ulatus kasvab igal aastal.

Miks on ajareadade andmebaas vajalik? Miks ei saa tavapärast relatsioonilist andmebaasi ajareadade salvestamiseks kasutada?

Sest ajareadades on tavaliselt suur andmemaht, mida on keeruline tavapärastes andmebaasides salvestada ja töödelda. Seetõttu on tekkinud spetsialiseeritud andmebaasid ajareadade jaoks. Need andmebaasid salvestavad tõhusalt punkte (timestamp, value) määratud võtme järgi. Need pakuvad API-d salvestatud andmete lugemiseks võtme järgi, kas ühe võtme-väärtuse paari põhjal, mitme paari põhjal või regexp järgi. Näiteks, kui soovite leida kõigi oma teenuste protsessori koormust Ameerika andmekeskuses, tuleks kasutada järgmist pseudoküsimust.

Tavaliselt esindavad ajareadade andmebaasid spetsialiseeritud päringute keeli, kuna SQL ei sobi ajareadade jaoks eriti hästi. Kuigi on ka andmebaase, mis toetavad SQL-i, ei ole see eriti sobiv. Paremini sobivad sellised päringute keeled nagu PromQL, InfluxQL, Flux, K. Loodan, et keegi on vähemalt ühe neist keeltest kuulnud. PromQL-i on ilmselt paljud kuulnud. See on Prometheuse päringute keel.

Nii näeb välja kaasaegse ajajoonedatabaasi arhitektuur VictoriaMetrics näitel.

See koosneb kahest osast. Üks on pööratud indeks ja teine ajajoonde väärtuste hoidmine. Need hoidlade on eraldatud.

Kui uus kirje tuleb andmebaasi, pöördume esmalt pööratud indeksi poole, et leida ajajoonde ID antud komplekti jaoks. label=value selle mõõtme jaoks. Leiame selle ID ja salvestame väärtuse andmehoidlasse.

Kui tuleb päring andmete toomiseks TSDB-st, uurime esmalt pööratud indeksi. Saame kõik timeseries_ids kirjed, mis vastavad antud komplektile. label=valueJa siis toome kõik vajalikud andmed andmehoidlast, mis on indekseeritud vastavalt. timeseries_ids.

Vaatame näidet, kuidas ajajoonde andmebaas töötleb sissetulevat select-päringut.

Esmalt toob ta kõik timeseries_ids pööratud indeksest, mis sisaldavad antud paare label=value, või vastavad antud regulaaravaldusele.
Seejärel toob ta kõik andmepunktid andmehoidlast antud ajavahemikus leitud tulemuste jaoks. timeseries_ids.
Pärast seda teostab andmebaas kasutaja päringu põhjal arvutusi nende andmepunktide üle. Ja seejärel tagastab vastuse.

Selles esituses räägin teile esimesest osast. See on otsing timeseries_ids pööratud indeksis. Teise ja kolmanda osa võite hiljem vaadata VictoriaMetrics'i lähtekoodid, või oodata, kuni ma valmistan ette teised ettekanded 🙂

Alustame pööratud indeksist. Paljudele võib tunduda, et see on lihtne. Kes teab, mis on pööratud indeks ja kuidas see töötab? Oh, inimesi ei olegi nii palju. Proovime aru saada, mis see on.

Tegelikult on kõik lihtne. See on lihtsalt sõnastik, mis seob võtmed väärtustega. Mis on võti? See paar label=value, kus silt ja value — need on stringid. Ja väärtused on hulk timeseries_ids, mis sisaldab määratud paari label=value.

Pööratud indeks võimaldab kiiresti leida kõik timeseries_ids, millel on antud label=value.

Ja see võimaldab kiiresti leida timeseries_ids aja rea jaoks mitme paari label=value, või paaride label=regexp. Kuidas see toimub? Kasutades hulgade lõike leidmist timeseries_ids iga paari jaoks label=value.

Vaatame erinevaid pöördindeksi rakendusi. Alustame kõige lihtsamast naiivsest rakendusest. See näeb välja umbes nii.

Function getMetricIDs saab ridade loendi. Iga rida sisaldab label=value. See funktsioon tagastab loendi metricIDs.

Kuidas see töötab? Siin on meil globaalne muutuja, mida nimetatakse invertedIndex. See on tavaline sõnastik (map), mis seob stringi slice int-idega. String sisaldab label=value.

Funktsiooni rakendus: saame kätte metricIDs esimese label=value, seejärel käime üle kõik teised label=value, saame nende jaoks kätte metricIDs . Ja kutsume välja funktsiooni intersectInts, millest räägitakse hiljem. Ja see funktsioon tagastab nende loendite ristumise.

Nagu näete, ei ole pöördindeksi rakendus eriti keeruline. Kuid see on naivne rakendus. Millised on selle puudused? Peamine puudus naivsest rakendusest on see, et selline pöördindeks hoitakse meie põh mälu. Pärast rakenduse taaskäivitamist kaotame selle indeksi. Selle indeksi salvestamist kettale ei toimu. Andmebaasi jaoks on selline pöördindeks tõenäoliselt sobimatu.

Teine puudus on samuti seotud mäluga. Inverteeritud indeks peab olema mahtunud töömällu. Kui see ületab töömälus arvutatud suurust, siis on ilmselge, et saame – out of memory error. Ja programm ei tööta.

Seda probleemi saab lahendada selliste valmis lahenduste abil nagu LevelDB, või RocksDB.

Kokkuvõttes on meil vaja andmebaasi, mis võimaldab kiiresti teostada kolme操作。

Esimene operatsioon – väärtuse kirjutamine võti-väärtus sellesse andmebaasi. Seda teeb ta väga kiiresti, kus võti-väärtus – need on suvalised stringid.
Teine operatsioon – see on kiire väärtuse otsimine antud võtme järgi.
Ja kolmas operatsioon – see on kiire kõikide väärtuste otsimine antud prefiksi järgi.

LevelDB ja RocksDB – need andmebaasid on välja töötatud Google'is ja Facebookis. Esmalt ilmus LevelDB. Siis Facebooki inimesed võtsid LevelDB ja hakkasid seda arendama, tehes RocksDB. Praegu töötab Facebookis peaaegu kõikides sisemistes andmebaasides RocksDB-l, sealhulgas nad on üle viinud RocksDB-le ka MySQL-i. Nad nimetasid seda MyRocks.

Inverteeritud indeksit saab realiseerida LevelDB abil. Kuidas seda teha? Me salvestame võtmena label=value. Ja väärtusena – ajaread, kus paar on olemas. label=value.

Kui meil on selle paari kohta palju ajaseeriaid label=value, siis on selle andmebaasi puhul palju ridu sama võtmega ja erinevatega timeseries_ids. Et saada loend kõigist timeseries_ids, mis algavad antud label=prefix, teeme vahemikus skaneerimise, mille jaoks see andmebaas on optimeeritud. St valime kõik read, mis algavad label=prefix ja saame vajalikud timeseries_ids.

Siin on ligikaudne rakendus, kuidas see Go-s välja näeks. Meil on pööratud indeks. See on LevelDB.

Funktsioon on sama, mis naiivses rakenduses. See kordab enam-vähem rida reaga naiivset rakendust. Ainus asi on see, et asemel, et pöörduda map pöördume pööratud indeksi poole. Saame kõik väärtused esimese jaoks label=value. Siis läheme läbi kõikidest ülejäänud paaridest label=value ja saame nende jaoks vastavad metricID komplektid. Siis leiame ristumise.

Kõik tundub hea, kuid selles lahenduses on puudusi. VictoriaMetrics rakendas alguses pööratud indeksit LevelDB põhjal. Kuid lõpuks tuli sellest loobuda.

Miks? Sest LevelDB on aeglasem kui naivne rakendus. Naivses rakenduses saame antud võtme järgi kohe terve viilu metricIDs. See on väga kiire tegevus – kogu slice on valmis kasutamiseks.

LevelDB-s tuleb igal funktsiooni kutsumisel GetValues läbida kõik read, mis algavad label=value. Ja iga rea jaoks tuleb leida väärtus timeseries_ids. Sellest tuleb timeseries_ids kokku panna slice neid timeseries_ids. Selgelt on see palju aeglasem kui tavalisest map’ist päringute tegemine võtme järgi.

Teine puudus on see, et LevelDB on kirjutatud C-s. C-funktsioonide kutsumine Go-st ei ole väga kiire. Selleks kulub sadu nanosekundi. See ei ole just kiire, kuna tavalise Go-s kirjutatud funktsiooni kutse võtab 1-5 nanosekundit, mis tähendab, et jõudluse erinevus on kümneid kordi. VictoriaMetricsi jaoks oli see surmav puudus 🙂

Seetõttu kirjutasin omaenda pööratud indeksi seadistuse. Nimetasin selle mergeset.

Mergeset põhineb MergeTree andmestruktuuril. See andmestruktuur on laenatud ClickHouse'ist. Selgelt peaks mergeset olema optimeeritud kiire otsingu jaoks timeseries_ids antud võtme põhjal. Mergeset on kirjutatud täielikult Go-s. Saate vaadata VictoriaMetricsi lähtekood GitHubis. Mergeseti implementatsioon asub kaustas /lib/mergeset. Võite proovida aru saada, mis seal toimub.

API mergeset on väga sarnane LevelDB ja RocksDB-ga. S.t. see võimaldab kiiresti salvestada uusi kirjeid ja kiiresti leida kirjeid antud prefiksi järgi.

Mergeseti puudustest räägime hiljem. Praegu räägime probleemidest, mis tekkisid VictoriaMetrics'i kasutamisel tootmises pöördindeksi rakendamisel.

Kust need probleemid tulenesid?

Esimene põhjus on kõrge churn rate. Ehk siis sagedane ajajoonte vahetus. See tähendab, et ajajoon lõppeb ja algab uus või algab palju uusi ajajooni. Ja see juhtub sageli.

Teine põhjus on suur ajajoonte arv. Alguses, kui jälgimine hakkas populaarsust koguma, oli ajajoonte arv väike. Näiteks, iga arvuti puhul tuleb jälgida protsessori, mälu, võrgu ja ketta koormust. 4 ajajoont iga arvuti kohta. Kui teil on näiteks 100 arvutit, on see 400 ajajoonte. See on väga vähe.

Aja jooksul on inimesed välja mõelnud, et on võimalik mõõta detailsemat teavet. Näiteks mõõta mitte ainult kogu protsessori koormust, vaid ka iga protsessorituuma eraldi. Kui teil on 40 protsessorituuma, siis on teil vastavalt 40 korda rohkem ajaseeriaid protsessori koormuse mõõtmiseks.

Aga see ei ole veel kõik. Igal protsessorituumal võivad olla mitu olekut, nagu idle, kui see ootab. Samuti töö kasutaja ruumis, töö kernel ruumis ja teised olekud. Iga sellist olekut saab samuti mõõta eraldi ajaseeria kui üksik ajaseeria. See suurendab ridade arvu veel 7-8 korda.

Meie ühest mõõtmest saime 40 x 8 = 320 mõõdet ainult ühe arvuti jaoks. Korrutame 100-ga, saame 32 000 asemel 400.

See ilmus Kubernetes. Ja see halvenes veelgi, sest Kubernetesis saab hostida palju erinevaid teenuseid. Iga teenus Kuberneteses koosneb paljusid podidest. Ja seda tuleb pidevalt jälgida. Lisaks on meil pidev uute versioonide juurutamine teie teenustes. Iga uue versiooni puhul tuleb luua uusi ajakavasid. Lõppkokkuvõttes kasvab ajakava hulk eksponentsiaalselt ja seisame silmitsi suure ajakava hulgaga, mida nimetatakse high-cardinality. VictoriaMetrics suudab sellega edukalt toime tulla võrreldes teiste ajakavade andmebaasidega.

Uurime lähemalt high churn rate'i. Miks tekib productionis high churn rate? Sest mõned labeling ja tagging väärtused muutuvad pidevalt.

Näiteks võetakse Kubernetes, kus on kontseptsioon deployment, st kui teie rakenduse uus versioon käivitatakse. Kubernetes arendajad otsustasid mingil põhjusel lisada deployment'i id label'isse.

Millele see viis? Sellele, et iga uue deployment'i korral katkestatakse kõik vanad ajakavad ja nende asemel algavad uued ajakavad uue label'i väärtusega deployment_id. Selliseid ajakavale võib olla sadu tuhandeid ja isegi miljoneid.

Oluline omadus on see, et ajakava koguhulk kasvab, kuid aktiivsete ajakavade arv, kuhu andmed voolavad, jääb konstantseks. Seda olukorda nimetatakse high churn rate'iks.

Peamine probleem high churn rate'i korral on tagada pidev kõigi ajakavade otsingu kiirus määratud sildihulga jooksul teatud ajavahemikus. Kui tavaliselt on see ajavahemik viimase tunni või viimase päeva jooksul.

Kuidas seda probleemi lahendada? Siin on esimene variant: jagada pöördindeks sõltumatuteks osadeks ajas. St. möödub teatud ajavahemik, lõpetame töö pöördindeksi praegusega ja loome uue pöördindeksi. Möödub veel üks ajavahemik, loome veel ühe ja veel ühe.

Ja nende pöördindeksite valimisel leiame pöördindeksite hulga, mis langeb määratud ajavahemikku. Seega valime sealt ajakava id-d.

See aitab ressursse säästa, kuna me ei pea vaatama osi, mis ei jää määratud vahemikku. St, et tavaliselt, kui valime andmed viimasest tunnist, siis eelnevaid ajavahemikke jätame päringud vahele.

On veel üks võimalus selle probleemi lahendamiseks. See on hoida iga päeva jaoks eraldi nimekiri ajaseerude id-dest, mis esinesid sellel päeval.

Selle lahenduse eelis varasema lahenduse ees on see, et me ei dubleeri teavet ajaseerude kohta, mis ajaga ei kao. Need on pidevalt olemas ja ei muutu.

Puuduseks on see, et selline lahendus on keerulisem rakendada ja keerulisem debugida. Ja VictoriaMetrics valis selle lahenduse. See on kõigepealt ajalooliselt nii kujunenud. Selline lahendus töötab ka üsna hästi võrreldes varasemaga. Seda seetõttu, et seda lahendust ei olnud rakendatud, kuna andmete kopeerimine on vajalik igas partition’is ajaseriate jaoks, mis ei muutu, st mis ajas ei kao. VictoriaMetrics on peamiselt optimeeritud kettaruumi tarbimise jaoks ja eelmine rakendus halvendab kettaruumi tarbimist. See aga sobib paremini kettaruumi tarbimise minimiseerimiseks, seetõttu see valiti.

Pidime sellega võitlema. Võitlus seisnes selles, et antud rakenduses tuleb ikkagi valida palju suurem hulk timeseries_ids andmete jaoks, kui siis, kui pöördindeks on jagatud ajas.

Kuidas me selle probleemi lahendasime? Me lahendasime selle originaalsel viisil – salvestades igas pöördindeksi kirjas mitu ajaseeriade identifikaatorit, mitte ühte. St meil on võtme label=value, mis on iga ajareal olemas. Ja nüüd salvestame mõned timeseries_ids ühes kirjes.

Siin on näide. Varem oli meil N kirjet, aga nüüd on meil üks kiri, mille prefiks on sama mis kõigil teistel. Eelneva kirje väärtus sisaldab kõiki ajaread id'sid.

See on võimaldanud suurendada sellise pöördindeksi skaneerimise kiirus kuni 10 korda. Ja on vähendanud mälutarbimist puhverdamise jaoks, kuna nüüd salvestame rea label=value ainult kord puhverdamiseks koos N korda. Ja see rida võib olla suur, kui sul on sisendites ja etiketides pikki ridu, mida Kubernetes sinna meeldib toppida.

Veel üks võimalus pöördindeksi otsimise kiirusel kiirus - see on shardimine. Mitme pöördindeksi loomine ühe asemel ja andmete shardimine nende vahel võti järgi. See on komplekt key=value See, meil on mitu sõltumatut pööratud indeksit, mida saame samaaegselt küsida mitmel protsessoril. Varasemad teostused lubasid töötada ainult ühes protsessorirežiimis, st skaneerida andmeid vaid ühel tuumal. See lahendus võimaldab skaneerida andmeid kohe mitmel tuumal, nagu ClickHouse armastab teha. Just seda me plaanime rakendada.

Ja nüüd naaseme meie teemade juurde – ristsõidufunktsiooni juurde. timeseries_ids. Uurime, millised teostused võivad olla võimalikud. See funktsioon võimaldab leida timeseries_ids antud komplekti jaoks. label=value.

Esimene variant on naiivne teostus. Kaks sisemist tsüklit. Saame funktsiooni sisendiks intersectInts kaks slices — a ja b. Väljundina peab see meile tagastama nende slices'i ristumise.

Naiivne teostus näeb välja nii. Käime kõik väärtused läbi slice'st a, selle tsükli sees käime kõik läbi slice'st b. Ja võrdleme neid. Kui need kattuvad, siis oleme leidnud ristumise. Ja salvestame selle tulemus.

Millised on puudused? Ruudukompleksus – see on selle peamine puudus. Näiteks, kui teie slice 'id on suured. a ja b kui ühe miljoni, siis see funktsioon ei naas tuttavat vastust. Kuna tal on vaja teha ühe triljoni iteratsiooni, mis on väga palju isegi tänapäevaste arvutite jaoks.

Teine rakendus põhineb map'il. Loome map'i. Paneme sellesse map'i kõik väärtused slice'ist. a. Seejärel käime slice'i kaudu eraldi tsükliga. b. Ja kontrollime – kas see väärtus on slice'is. b map'is. Kui see on olemas, lisame selle tulemustesse.

Millised on eelised? Eelis on see, et siin on ainult lineaarsed kulud. St. funktsioon töötab palju kiiremini suurte slice'ide suuruste korral. Miljoni suuruse slice'i puhul töötab see funktsioon 2 miljoni iteratsiooni jooksul, erinevalt triljonist iteratsioonist, nagu eelnevas funktsioonis.

Ja puuduseks on see, et see funktsioon vajab rohkem mälu selle map'i loomiseks.

Teine puudus – see on suur overhead hashimisele. See puudus ei ole väga ilmne. Ja meie jaoks polnud see samuti väga ilmne, mistõttu alguses VictoriaMetrics'is oli intersection'i rakendus läbi map'i. Aga hiljem näitas profileerimine, et peamine protsessori aeg kulub map'i kirjutamiseks ja väärtuse olemasolu kontrollimiseks selles map'is.

Miks kulub CPU aeg nendes kohtades? Sest Go teostab seal hashimisoperatsiooni. See tähendab, et ta arvutab võtme hash'i, et pääseda seejärel antud indeksi kaudu HashMap'ile. Hash'i arvutamise operatsioon toimub mõne kümnendiku nanosekundiga. See on VictoriaMetricsi jaoks aeglane.

Otsustasin rakendada bitset'i, mis on spetsiaalselt selle juhtumi jaoks optimeeritud. Nii näeb nüüd kahe slice'i ühisosa välja. Siin loome bitset'i. Lisame sinna esimesest slice'ist elemendid. Siis kontrollime nende elementide olemasolu teises slice'is. Ja lisame need tulemusse. See tähendab, et see ei erine peaaegu eelmise näite puhul. Ainsad asjad, mida oleme siin teinud, on kaardile juurdepääsu asendamine kohandatud funktsioonidega. add ja has.

Esmapilgul tundub, et see peaks töötama aeglasemalt, kui varem kasutati tavalist kaarti ja nüüd kutsutakse veel mingid funktsioonid välja, kuid profilleerimine näitab, et see asi töötab 10 korda kiiremini kui tavaline kaart VictoriaMetricsi jaoks.

Lisaks sellele kasutab see võrreldes kaardi rakendusega oluliselt vähem mälu. Sest me hoiame siin bitte, mitte kaheksabaidiseid väärtusi.

Sellise rakenduse puuduseks on see, et see ei ole nii ilmne, mitte triviaalne.

Veel üks puudus, mida paljud ei pruugi märgata, on see, et see rakendus võib teatud olukordades halvasti töötada. See tähendab, et see on optimeeritud konkreetse juhtumi jaoks, nimelt VictoriaMetrics ajasarjade id-de ülekandmise jaoks. See ei tähenda, et see sobib igas olukorras. Kui seda valesti kasutada, siis saavutame mitte ainult jõudluse kasvu, vaid ka out of memory error ja jõudluse vähenemise.

Vaatame selle andmestruktuuri rakendust. Kui soovite, siis see asub VictoriaMetricsi allikates, kaustas lib/uint64set. See on optimeeritud just VictoriaMetricsi juhtumi jaoks, kus timeseries_id esindab 64-bitist väärtust, kus esimesed 32 bitti on peaaegu konstantsetena ja muutuvad ainult viimased 32 bitti.

See andmestruktuur ei salvestata kettale, vaid töötab ainult mälus.

Siin on selle API. See ei ole väga keeruline. API on kohandatud just VictoriaMetricsi konkreetse kasutusnäite jaoks. Siin ei ole üleliigseid funktsioone. Siin on funktsioonid, mida VictoriaMetrics selgelt kasutab.

On funktsioon add, mis lisab uusi väärtusi. On olemas funktsioon has, mis kontrollib uusi väärtusi. Ja on funktsioon del, mis eemaldab väärtused. On abifunktsioon len, mis tagastab kogumi suuruse. Funktsioon clone kloneerib kogumi. Ja funktsioon appendto töötluses täiendatakse see lõikesse timeseries_ids.

Nii näeb selle andmestruktuuri rakendus välja. Kogumil on kaks elementi:

ItemsCount – see on abiväli, et kiiresti tagastada kogumi elementide arv. Selle abivälja oleks võinud ära jätta, kuid see tuli siia lisada, kuna VictoriaMetrics küsitleb sageli oma algoritmides bitseti pikkust.
Teine väli on buckets. See on lõik struktuurist bucket32. Igas struktuuris on salvestatud hi väli. Need on kõige kõrgemad 32 bitti. Ja kaks lõiku — b16his ja buckets kohast bucket16 struktuurid.

Siin hoitakse 64-bitise struktuuri teise osa ülemisi 16 bitti. Ja siin hoitakse bitsets'i iga bait jääb 16 bitiga.

Bucket64 koosneb massiivist uint64. Pikkus arvutatakse nende constatsioonide abil. Ühes bucket16 max võib hoida 2^16=65536 bititi. Kui see jagada 8-ga, siis on see 8 kilobaiti. Kui jagada veel kord 8-ga, siis on see 1000 uint64 väärtuses. St. Bucket16 – see on meil 8-kilobaitine struktuur.

Vaatame, kuidas on rakendatud üks meetod uut väärtust lisava struktuuri.

Kõik algab uint64 väärtusest. Arvutame ülemised 32 bitti, arvutame alumised 32 bitti. Läbime kõik buckets. Võrdleme ülemisi 32 bitti igas baketis lisatava väärtusega. Ja kui need kattuvad, siis kutsume üles funktsiooni add b32 struktuuris buckets. Ja lisame sinna alumised 32 bitti. Ja kui see tagastab true, siis tähendab, et me lisasime sellise väärtuse sinna ja meil polnud sellist väärtust. Kui see tagastab false, siis selline väärtus oli juba olemas. Siis suurendame struktuuri elementide arvu.

Kui me ei leidnud vajalikku baketi vajaliku hi-väärtusega, siis kutsume üles funktsiooni addAlloc, mis eraldab uue baketi, lisades selle baketi struktuuri.

See on funktsiooni rakendus b32.add. See on sarnane eelmise rakendusega. Me arvutame vanemad 16 bitti, nooremad 16 bitti.

Siis läbime kõik ülemised 16 bitti. Leiame kattuvused. Ja kattumise korral kutsume üles meetodi add, mida uurime järgmises lehes bucket16.

Ja siin on kõige madalam tase, mis peab olema maksimaalselt optimeeritud. Me arvutame uint64 id väärtuse slice bit, samuti bitmask. See on mask selle 64-bitise väärtuse jaoks, mille järgi saab kontrollida selle bit'i olemasolu või seada selle. Kontrollime, kas see bit on seatud, ja seame selle, ning tagastame, kas see on olemas. Selline rakendus võimaldas meil kiirendada aegrea id-de ristumist 10 korda võrreldes tavapäraste map'idega.

VictoriaMetrics'is on lisaks sellele optimeerimisele palju teisi optimeerimisi. Enamik neist optimeerimistest on lisatud mitte niisama, vaid pärast koodi profileerimist tootmises.

See on optimeerimise peamine reegel – mitte lisada optimeerimist, oletades, et siin on kitsaskoht, kuna see võib osutuda vale oletuseks. Optimeerimine halvendab tavaliselt koodi kvaliteeti. Seetõttu tasub optimeerida ainult pärast profileerimist ja soovitatavalt tootmises, et need oleksid tegelikud andmed. Kellele huvi pakub, võite vaadata VictoriaMetrics'i lähtekoodi ja õppida tundma teisi optimeerimisi, mis seal on.

Mul on küsimus bitset'i kohta. See sarnaneb väga C++ vector bool'i rakenduse, optimeeritud bitset'iga. Kas te võtsite selle rakenduse sealt?

Ei, see ei ole se. Selle bitseti rakendamisel põhinesin ma teadmistele nende id-aegrea struktuurist, mida kasutatakse VictoriaMetrics'is. Nende struktuuri kohaselt on ülemised 32 bitti enamasti püsivad. Alumised 32 bitti võivad muutuda. Mida madalam on bitt, seda sagedamini võib see muutuda. Seega on see rakendus optimeeritud just selle andmestruktuuri jaoks. C++ rakendus, kui ma õigesti tean, on optimeeritud üldiste juhtumite jaoks. Kui optimeerida üldiste juhtumite järgi, tähendab see, et see ei ole konkreetses juhtumis kõige optimaalsem.

Soovitan teil vaadata ka Alexei Milovidi ettekannet. Ta rääkis kuskil kuu aega tagasi ClickHouse'i optimeerimisest konkreetsete erialade jaoks. Ta räägib nimelt, et C++ rakendus või mõni muu rakendus on tavaliselt kohandatud keskmiselt hea töö jaoks. See võib töötada halvemini kui spetsialiseeritud rakendus konkreetsete teadlike teadmiste jaoks, nagu meil on, kui me teame, et ülemised 32 bitti on enamasti püsivad.

Mul on teine küsimus. Mis on radikaalne erinevus InfluxDB-st?

Olulisi erinevusi on palju. Kui rääkida seadistustest ja mälutarbimisest, siis InfluxDB näitab testides 10 korda suuremat mälutarbimist kõrge kardinaalsusega ajajoonte jaoks, kui neid on palju, näiteks miljoneid. Näiteks VictoriaMetrics tarbib 1 GB miljoni aktiivse joone kohta, samas kui InfluxDB tarbib 10 GB. Ja see on suur erinevus.

Teine oluline erinevus on see, et InfluxDB-s on kummalised päringu keeled – Flux ja InfluxQL. Need ei ole ajajoontes töötamiseks eriti mugavad võrreldes PromQL, mida VictoriaMetrics toetab. PromQL on päringute keel, mis pärineb Prometheusest.

Ja veel üks erinevus on see, et InfluxDB-l on veidi kummaline andmemudel, kus igas reas võib olla mitu fields erinevate märgendite kogudega. Need read jagunevad veel igasugusteks tabeliteks. Need täiendavad keerukused muudavad selle andmebaasi hilisema töö keeruliseks. Seda on raske toetada ja mõista.

VictoriaMetricsis on kõik palju lihtsam. Iga ajajoon on võtme-väärtuse paar. Väärtus on kogum punkte – (timestamp, value), samas kui võti on kogum label=value. Puudub lahknevus fields'i ja measurements'i vahel. See võimaldab valida ükskõik milliseid andmeid ning seejärel neid kombineerida, liita, lahutada, korrutada, jagada, erinevalt InfluxDB-st, kus arvutused erinevate ridade vahel ei ole endiselt rakendatud, kui ma õigesti tean. Kui need on isegi rakendatud, on see keeruline, tuleb kirjutada palju koodi.

Mul on täpsustav küsimus. Kas ma sain õigesti aru, et oli mingi probleem, millest te rääkisite, et see pööratud indeks ei mahu mälu, mistõttu seal toimub partitsioneerimine?

Alguses näitasin ma pööratud indeksi naiivset rakendust tavapärasel Go kaardil. Selline rakendus ei sobi andmebaaside jaoks, sest see pööratud indeks ei salvestu kettale, kuid andmebaas peab salvestama kettale, et peale taaskäivitamist oleksid need andmed endiselt kättesaadavad. Antud rakenduses kaob pööratud indeks, kui rakendus taaskäivitada. Ja te kaotate ligipääsu kõikidele andmetele, sest te ei suuda neid enam leida.

Tere! Aitäh ettekande eest! Minu nimi on Pavel. Olen ettevõttest Wildberries. Mul on paar küsimust teie jaoks. Esimene küsimus. Kuidas te arvate, kui valiksite oma rakenduse arhitektuuri ülesehitamisel teise põhimõtte ja jaotaksite andmed ajaliselt, kas siis saaksite andmete otsimise ajal ristuda, tuginedes ainult sellele, et ühes jaotuses on andmed ühe ajavahemiku kohta, st ühes ajavahemikus, ja ei peaks muretsema, et teie tükid on eri kohtades laiali? Teine küsimus — kuna te rakendate sarnast algoritmi bitsetide ja muu juurde, kas olete ehk proovinud kasutada protsessori juhiseid? Võib-olla olete katsetanud selliseid optimeerimisi?

Teisele küsimusele vastan kohe. Me ei ole sinna veel jõudnud. Kuid kui see vajalik on, siis me jõuame. Aga esimene, mis küsimus oligi?

Te arutasite kahte stsenaariumit. Ja ütlesite, et valisite teise, millel on keerulisem rakendus. Ja ei eelistanud esimest, kus andmed on ajaliselt jaotatud.

Jah. Esimesel juhul oleks indeksi kogumaht suurem, kuna peame igas partitsioonis hoidma andmete koopiaid ajaseeriate jaoks, mis ulatuvad üle kõik need partitsioonid. Ja kui teil on ajaseeriate churn rate madal, st pidevalt kasutatakse samu seeriaid, siis esimesel juhul kaotaksime diskiruumi kasutuses palju rohkem võrreldes teise variandiga.

Nii et jah, ajakohane partitsioonimine on hea lahendus. Seda kasutab Prometheus. Kuid Prometheusel on teine puudus. Andmeosade ühendamisel peab ta hoidma mälu kõigi label'ite ja ajaseeriate metaandmete jaoks. Seetõttu, kui ühendatavad andmeosad on suured, suureneb mälu tarbimine oluliselt, erinevalt VictoriaMetricsist. VictoriaMetrics ei tarbi ühendamisel üldse mälu, seal tarbitakse paari kilobaiti sõltumata ühendatavate andmeosade suurusest.

Teie kasutatav algoritm kasutab mälu. Selles registreeritakse ajatsüklite märgid, millel on väärtused. Nii kontrollite paari olemasolu ühes andmehulgas ja teises. Ja saate aru, kas toimus ühisosa või mitte. Tüüpiliselt rakendavad andmebaasid kursoreid, iteraatoreid, mis hoiavad oma praegust olekut ja liikuvad sorteeritud andmete kaudu, mistõttu on teil need operatsioonid lihtsamad.

Miks me ei kasuta kursoreid andmete ristumisteks?

Jah.

Meil on LevelDB-s või mergeset-s just sorteeritud read. Saame kursori abil läbi minna ja leida ristumise. Aga miks me ei kasuta? Sest see on aeglane. Sest kursorid eeldavad, et iga rea jaoks tuleb funktsiooni kutsuda. Funktsiooni kutsumine võtab aega 5 nanosekundit. Ja kui teil on 100 000 000 rida, siis kulutame poole sekundi ainult funktsiooni välja kutsumiseks.

Jah, see on olemas. Ja viimase küsimus, millel on võib-olla veidi kummaline kõla. Miks ei saa andmete laekumise hetkel arvutada kõiki vajalikke aggregaatide ja salvestada neid vajalikul viisil? Miks hoida suuri andmemahte süsteemides nagu VictoriaMetrics, ClickHouse jne, et siis kulutada nende käsitlemiseks väga palju aega?

Toon näite, et oleks arusaadavam. Oletame, kuidas töötab väike mänguasi spidomeeter? See salvestab vahemaa, mille olete läbinud, pidevalt lisades selle ühte suurusesse, teise - aja. Ja jagab. Ja saab keskmise kiirus. Saame teha enam-vähem sama. Koguda jooksvalt kõik vajalikud faktid.

Hästi, olen küsimusest aru saanud. Teie näide on elujõuline. Kui te teate, milliseid agregaatfunktsioone vajate, siis on see parim lahendus. Probleem on aga selles, et inimesed säilitavad need mõõdikud, mingid andmed ClickHouse'is ja nad ei tea veel, kuidas nad neid tulevikus agregoorida või filtreerida, mistõttu peavad nad säilitama kõik toored andmed. Aga kui te teate, et peate midagi keskmist arvutama, siis miks mitte arvutada seda, selle asemel et hoida seal hunnikut tooreid väärtusi? Kuid see ainult siis, kui te täpselt teate, mida vajate.

Muide, ajaliselt järjestatud andmebaasid toetavad agregaatide arvestamist. Näiteks toetab Prometheus salvestusreegleid. See tähendab, et seda on võimalik teha, kui te teate, milliseid agregaatfunktsioone vajate. VictoriaMetrics'il seda veel ei ole, kuid tavaliselt paigaldatakse sellele ette Prometheus, kus seda saab teha salvestusreeglites.

Näiteks eelmisel töökohal tuli kasutada liugakna abil viimase tunni jooksul toimunud sündmuste arvu arvestamist. Probleemiks oli, et tuli teha kohandatud implementatsioon Go keeles, st teenus selle arvestamiseks. See teenus osutus lõpuks keeruliseks, kuna selle arvestamine on keeruline. Implementatsioon võib olla lihtne, kui peate arvestama mõningaid koguseid fikseeritud ajavahemike jooksul. Kui aga soovite arvestada sündmusi liugaknas, pole see nii lihtne, kui see tundub. Arvan, et ClickHouse'is või ajaseeria andmebaasides pole see ikka veel rakendatud, kuna rakendamine on keeruline.

Ja veel üks küsimus. Rääkisime praegu keskmistest väärtustest ja mulle tuli meelde, et kunagi oli selline asi nagu Graphite, millel oli Carboni taust. See suutis vanu andmeid kärpida, st jättis iga minuti, iga tunni jne jaoks ühe punkti. Üldiselt on see üsna mugav, kui me vajame toorandmeid, ütleme, kuu kohta, samas kui kõik muu saab kärpida. Kuid Prometheus ja VictoriaMetrics ei toeta seda funktsionaalsust. Kas selle toetamine on plaanis? Kui ei, siis miks mitte?

Aitäh küsimuse eest. Meie kasutajad küsivad seda perioodiliselt. Küsitakse, millal me lisame toetalvise (downsampling) toe. Siin on mitu probleemi. Esiteks, iga kasutaja mõistab selle all downsampling midagi erinevat: mõned soovivad saada mingit suvalist punkti määratud intervallis, mõned soovivad maksimaalseid, minimaalseid või keskmisi väärtusi. Kui teie andmebaasi kirjutavad andmeid mitmed süsteemid, siis ei saa neid ühtsalt kokku korjata. Võib juhtuda, et iga süsteemi jaoks on vajalik kasutada erinevat downsampling'i. Ja see on keeruline ellu viia.

Teiseks, VictoriaMetrics, nagu ka ClickHouse, on optimeeritud töötama suurte tooredate andmete kogustega, seetõttu suudab ta töödelda miljardit rida vähem kui sekundiga, kui teie süsteemis on palju tuuma. Aja rea punkte skaneerimine VictoriaMetrics'is on 50 000 000 punkti sekundis ühe tuuma kohta. Ja see jõudlus skaleerub olemasolevate tuumadega. St. kui teil on näiteks 20 tuuma, siis saab skaneerida miljardi punkti sekundis. Ja see omadus VictoriaMetrics'is ja ClickHouse'is vähendab vajadust downsampling'i järele.

Teine omadus on see, et VictoriaMetrics kompresseerib need andmed tõhusalt. Keskmine tihedus productionis on 0,4 kuni 0,8 bitti punktide kohta. Iga punkt on ajatempleid + väärtused. Ja keskmiselt kompressitakse see alla ühe bitti.

Sergei. Mul on küsimus. Mis on minimaalne salvestamise aeg?

Üks millisekund. Hiljuti arutasime teiste ajarealiste andmebaaside arendajatega. Nende minimaalne ajakvant on üks sekund. Näiteks Graphites on ka üks sekund. OpenTSDB-s samuti üks sekund. InfluxDB-l on nanosekundi täpsus. VictoriaMetrics-il on üks millisekund, kuna Prometheuses on üks millisekund. VictoriaMetrics loodi algselt Prometheuse kaugandmete salvestuseks. Kuid nüüd suudab see salvestada andmeid ka teistest süsteemidest.

Inimene, kellega ma rääkisin, ütles, et nende täpsus on sekundiline — see on piisav, kuna see sõltub andmete tüübist, mida ajajoonte andmebaasi salvestatakse. Kui need on DevOps-andmed või andmed infrastruktuurist, kus te kogute neid 30 sekundi või minuti intervalliga, siis piisab sekundilisest täpsusest, vähem ei ole enam vajalik. Kuid kui te kogute neid suure sagedusega kauplemise süsteemidest, siis vajate nanoskeedi täpsust.

Millisekundiline täpsus VictoriaMetricsis sobib nii DevOps-i juhtumi jaoks kui ka enamikeks juhtudeks, mida ma oma ettekande alguses mainisin. Ainus, mille jaoks see ei pruugi sobida, on kõrgsageduslikud kauplemissüsteemid.

Aitäh! Ja veel üks küsimus. Milline on ühilduvus PromQL-iga?

Täielik tagurpidi ühilduvus. VictoriaMetrics toetab täielikult PromQL-i. Lisaks sellele lisab see veel täiustatud funktsionaalsust PromQL-i, mis nimetatakse MetricsQL. Selle täiustatud funktsionaalsuse kohta on YouTube'is ettekande. Rääkisin Monitoring Meetup'il sel kevadel Peterburis.

Telegrami kanali VictoriaMetrics.

Ainult registreeritud kasutajad saavad küsitluses osaleda. Logige sisse, palun.