🥇 Go optimeerimised VictoriaMetricsis. Alexander Valjalkin

Tutvustan teile 2019. aasta lõpu raporti "Go optimizations in VictoriaMetrics" tõlgendust, mille autor on Aleksandr Valjalkin.

VictoriaMetrics — kiire ja skaleeritav andmebaasi haldusüsteem, mis on mõeldud ajarealiste andmete salvestamiseks ja töötlemiseks (salvestus moodustab aja ja vastavad sellele ajale väärtuste kogumi, näiteks anduritelt saadud perioodiliselt mõõdetud olekute või meetrite kogumise kaudu).

Siin on link selle raporti videole — https://youtu.be/MZ5P21j_HLE

Slaidid

Räägin natuke endast. Olen Aleksandr Valjalkin. Siin on minu GitHub konto. Mind huvitab Go ja jõudluse optimeerimine. Olen kirjutanud palju kasulikke ja vähem pruugi raamatukogusid. Need algavad kas fast, või quick eesliidelt.

Hetkel töötan VictoriaMetrics'i kallal. Mis see on ja mida ma seal teen? Räägin sellest presentatsioonis.

Raporti ülevaade on järgmine:

Alustuseks räägin, mis on VictoriaMetrics.
Seejärel selgitan, mis on ajaread.
K seejärel räägin, kuidas ajarealiste andmete andmebaas töötab.
Edasi räägin andmebaasi arhitektuurist: millest see koosneb.
Ja seejärel liigume edasi optimeerimistele, mis on olemas VictoriaMetrics'is. Need on pööratud indeksi optimeerimine ja bitset-realisatsiooni optimeerimine Go-s.

Kas keegi teab, mis on VictoriaMetrics? Oh, juba paljud inimesed teavad. See on hea uudis. Neile, kes ei tea – see on ajarealiste andmete andmebaas. See põhineb ClickHouse arhitektuuril, teatud ClickHouse'i rakenduse detailidel. Näiteks nagu: MergeTree, paralleelsed arvutused kõigil saadaval olevatel protsessorikasutajatel ja jõudluse optimeerimine töötamata andmeblokkide osas, mis paigutatakse protsessorikapslisse.

VictoriaMetrics pakub paremat andmete tihendamist võrreldes teiste ajarealiste andmete andmebaasidega.

See skaleerub vertikaalselt — st võite lisada rohkem protsessoreid, rohkem RAM-i ühte arvutisse. VictoriaMetrics suudab tõhusalt kasutada neid ressursse ja kasvatada lineaarselt jõudlust.

Samuti skaleerub VictoriaMetrics horisontaalselt — st võite lisada täiendavaid sõlmi VictoriaMetrics'i klastrisse ning selle jõudlus suureneb peaaegu lineaarselt.

Kuidas arvata võisite, VictoriaMetrics on kiire andmebaas, sest ma ei oska kirjutada muid. Ja see on kirjutatud Go-s, seetõttu räägin ma sellest kohtumisel.

Kes teab, mis on ajaread? Ka paljusid inimesi teab. Ajaread on paaride seeria (timestamp, väärtus), kus paarid on järjestatud aja järgi. Väärtus on ujuv-punktiga number – float64.

Iga ajareale tuvastatakse ainulaadne võti. Mis see võti sisaldab? See koosneb mitte-tühjast võtme-väärtuse paaride kogumist.

Siin on näide ajareast. Selle rea võtmena on paaride nimekiri: __name__="cpu_usage" – see on mõõdiku nimi, instance="my-server" — see on arvuti, kus see mõõdik on kogutud, datacenter="us-east" — see on andmekeskus, kus see arvuti asub.

Meil on ajareanimi, mis koosneb kolmest võtme-väärtuse paarist. Sellele võtmele vastab paaride nimekiri (timestamp, value). t1, t3, t3, ..., tN — need on ajamärgid, 10, 20, 12, ..., 15 — vastavad väärtused. See on cpu-kasutus antud ajahetkel selle rea jaoks.

Kus võivad ajaread olla kasulikud? Kas kellelgi on ideid?

DevOps-is saab mõõta CPU, RAM, võrgu, rps, vigade arvu jne koormust.
IoT – saame mõõta temperatuuri, rõhku, geo-kordinaate ja veel midagi.
Samuti rahanduses – saame jälgida aktsiate ja valuutade hindu.
Lisaks sellele võivad ajaread olla kasulikud töötlemisprotsesside jälgimiseks tehasetes. Meil on kasutajaid, kes kasutavad VictoriaMetrics tuulegeneraatorite ja robotite jälgimiseks.
Ajaread on ka kasulikud teatud seadmete andurite info kogumiseks. Näiteks mootori jaoks; rehvide rõhu mõõtmiseks; kiirus, kaugus; kütusekulu mõõtmiseks jne.
Ajaread võivad samuti olla kasulikud lennukite jälgimiseks. Igas lennukis on must kast, mis kogub ajareade erinevate lennuki tervise parameetrite kohta. Ajaread on samuti kasutusel lennundustööstuses.
Tervishoid – see on vererõhk, pulss jne.

Võib-olla on veel rakendusi, millest ma unustasin, kuid loodan, et te mõistate, et ajaread on kaasaegses maailmas aktiivselt kasutusel. Ja nende kasutamine suureneb iga aastaga.

Miks on ajareadeks vajalik andmebaas? Miks ei saa ajareadeks kasutada tavalist relatsioonilist andmebaasi?

Kuna ajajoonetes on tavaliselt suur hulk teavet, mille säilitamine ja töötlemine tavapärastes andmebaasides on keeruline. Seetõttu on välja töötatud spetsialiseeritud ajajoonte andmebaasid. Need andmebaasid säilitavad punkte tõhusalt, (timestamp, value) antud võtme põhjal. Nad pakuvad API-d salvestatud andmete lugemiseks võtme järgi, kas ühe võtme-väärtuse paari, mitme sellise paari või regexp järgi. Näiteks, kui soovite leida kõigi oma teenuste CPU koormuse andmed Ameerika andmekeskuses, peate kasutama sellist pseudo-päringut.

Tavaliselt esindavad ajajoonte andmebaasid spetsialiseeritud päringute keeli, kuna SQL ei sobi ajajoonte jaoks väga hästi. Kuigi on andmebaase, mis toetavad SQL-i, ei ole see siiski eriti sobiv. Rohkem sobivad sellised päringu keeled nagu PromQL, InfluxQL, Flux, Q. Loodan, et keegi on neist keeltest vähemalt midagi kuulnud. O PromQL on ilmselt paljud kuulnud. See on Prometheuse päringu keel.

Nii näeb välja kaasaegse ajajoonte andmebaasi arhitektuur VictoriaMetrics'i näitel.

See koosneb kahest osast. Need on pöördindeksi salvestus ja ajajoonte väärtuste salvestus. Need salvestused on eraldatud.

Kui andmebaasi tuleb uus kirje, pöördume kõigepealt pöördindeksi poole, et leida ajajoonte identifikaator antud määratud kogumi label=value selle mõõtiku jaoks. Leiame selle identifikaatori ja salvestame väärtuse andmesalvestusse.

Kui tuleb päring andmete valimiseks TSDB-st, vaatame kõigepealt pöördindeksi. Saame kõik timeseries_ids kirjed, mis vastavad antud määratud kogule. label=valueJa seejärel saame kõik vajalikud andmed andmesalvestusest, mille on indekseeritud timeseries_ids.

Vaadakem näidet, kuidas ajajoonte andmebaas töötleb sisenevat select-päringut.

Esimese asjana saab ta kõik timeseries_ids pöördindeksist, mis sisaldavad määratud paare label=value, või vastavad määratud regulaaravaldisele.
Seejärel saadab ta kõik andmepunktid andmesalvestusest antud ajavahemikus leidudest timeseries_ids.
Pärast seda teeb andmebaas kasutaja päringu järgi nende andmepunktide põhjal arvutusi. Ja seejärel tagastab vastuse.

Selles esitluses räägin ma teile esimesest osast. See on otsimine timeseries_ids pööratud indeksis. Teise ja kolmanda osa võite hiljem vaadata VictoriaMetricsi lähtekoodid, või oodata, kuni ma valmistan ette teisi ettekandeid 🙂

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, kes teavad, ei olegi nii palju. Proovime mõista, mis see on.

Tegelikult on kõik lihtne. See on lihtsalt sõnastik, mis seob võtme väärtusega. Mis on võti? See paar label=value, kus label ja value on stringid. Ja väärtused – on kogum timeseries_ids, kuhu kuulub antud paar label=value.

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

Samuti võimaldab see kiiresti leida timeseries_ids aja rea jaoks mitme paari label=value, või paaride jaoks label=regexp. Kuidas see toimub? Tõmbamise kaudu hulkade ühisosa timeseries_ids iga paari jaoks label=value.

Vaadakem erinevaid pööratud indeksi teostusi. Alustame kõige lihtsama naiivse teostusega. See näeb välja selline.

Funktsioon getMetricIDs saab loendi stringidest. Iga string sisaldab label=value. See funktsioon tagastab loendi metricIDs.

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

Funktsiooni teostamine: saame metricIDs esimese jaoks label=value, seejärel käime üle kõikide teiste label=value, saame metricIDs nende jaoks. Ja kutsume välja funktsiooni intersectInts, millest räägitakse järgmises osas. See funktsioon tagastab nende loendite ühisosa.

Kuidas näete, pööratud indeksi teostamine ei ole väga keeruline. Kuid see on naivne teostus. Millised on selle puudused? Peamine puudus naiivses teostuses on see, et selline pööratud indeks hoitakse meie mälus. Pärast rakenduse taaskäivitamist kaotame selle indeksi. Ei ole indeksi salvestamist kettale. Andmebaasi jaoks ei sobi selline pööratud indeks tõenäoliselt.

Teine puudus on samuti seotud mäluga. Pööratud indeks peab mahtuma operatiivmälu. Kui see ületab operatiivmälu suuruse, siis on ilmne, et saame – out of memory error. Ja programm ei tööta.

Seda probleemi saab lahendada valmis lahendustega, nagu LevelDB, või RocksDB.

Lühidalt öeldes, vajame andmebaasi, mis võimaldab kiiresti teha kolme toimingut.

Esimene toiming on salvestamine võtme-väärtuse paar sellesse andmebaasi. Seda teeb ta väga kiiresti, kus võtme-väärtuse paar - need on võivad olla suvalised stringid.
Teine toiming on kiire väärtuse otsimine antud võtme alusel.
Ja kolmas toiming on kiire kõigi väärtuste leidmine antud prefiksi alusel.

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

Pööratud indeksi saab rakendada LevelDB abil. Kuidas seda teha? Me salvestame võtmena label=value. Ja väärtusena – ajaseeria identifikaatori, kus see paar esineb. label=value.

Kui meil on palju ajaseeriaid selle paariga label=value, siis on sellel andmebaasis palju ridu sama võtme ja erinevatega. timeseries_idsSelleks, et saada nimekiri kõigist timeseries_ids, mis algavad antud label=prefix, teeme ulatusliku skaneerimise, mille jaoks antud andmebaas on optimeeritud. Ehk valime kõik read, mis algavad label=prefix ja saame vajalikud timeseries_ids.

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

Funktsioon on sama, mis naiivses teostuses. See kordab peaaegu rida-realt naiivset teostust. Ainus moment on see, et tavalise map asemel pöördume pööratud indeksisse. Saame kõik väärtused esimese jaoks label=value. Siis käime läbi kõik ülejäänud paarid label=value ja saame nende jaoks vastavad metricID-d. Seejärel leiame ristumise.

Tundub, et kõik on hästi, kuid selles lahenduses on puudusi. VictoriaMetrics rakendas alguses pööratud indeksi LevelDB-l põhinevalt. Kuid lõpuks tuli sellest loobuda.

Miks? Sest LevelDB on aeglasem kui naivne teostus. Naivses teostuses saame antud võtme alusel kohe kogu viilu metricIDs. See on väga kiire toiming — kogu viilu saab kasutada.

Kuid LevelDB-s tuleb iga kord, kui kutsume välja funktsiooni GetValues läbida kõik read, mis algavad label=value. Ja iga read tuleb välja võtta väärtus timeseries_ids. Sellest timeseries_ids koostatakse nende timeseries_ids. Ilmselgelt on see palju aeglasem kui lihtsalt pöördumine tavalise kaardi poole võtme alusel.

Teine puudus on see, et LevelDB on kirjutatud C-s. C-funktsioonide väljakutsumine Go-st ei ole väga kiire. See võtab sadu nanosekundeid. See pole väga kiire, sest võrreldes tavapärase funktsiooni väljakutsumisega, mis on kirjutatud Go-s ja mis kestab 1-5 nanosekundit, on jõudluse erinevus kümneid kordi. VictoriaMetrics'i jaoks oli see saatuslik puudus 🙂

Seetõttu kirjutasin ma omaenda inversiooni indeksi rakenduse. Ja nimetasime selle mergeset.

Mergeset põhineb MergeTree andmestruktuuril. See andmestruktuur on laenatud ClickHouse'ist. Selgelt peab mergeset olema optimeeritud kiireks otsimiseks timeseries_ids antud võtme järgi. Mergeset on täielikult kirjutatud Go-s. Saate vaadata VictoriaMetrics'i lähtekoodi GitHubis. Mergeseti rakendus asub kaustas /lib/mergeset. Võite proovida aru saada, mis seal toimub.

Mergeseti API on väga sarnane LevelDB ja RocksDB-ga. See tähendab, et see võimaldab kiiresti salvestada uusi kirjeid ja kiiresti valida kirjeid antud prefiksi järgi.

Mergeseti puudustest räägime hiljem. Praegu räägime probleemidest, mis tekkisid VictoriaMetrics'il tootmises inversiooni indeksi rakendamise käigus.

Kuidas need tekkisid?

Esimene põhjus on suur churn rate. Tõlkes eesti keelde - see on ajaliselt rikka sagedane vahetus. See on juhul, kui ajakava lõpeb ja algab uus, või algavad palju uusi ajakavasid. Seda juhtub sageli.

Teine põhjus on suur hulk ajakavasid. Alguses, kui jälgimine hakkas populaarsust koguma, oli ajakavasid vähe. Näiteks, iga arvuti jaoks tuleb jälgida protsessori, mäluse, võrgu ja ketta kasutamist. 4 ajakava iga arvuti kohta. Oletame, et teil on 100 arvutit, see teeb kokku 400 ajakava. See on väga vähe.

Aja jooksul mõistsid inimesed, et on võimalik mõõta üksikasjalikumat teavet. Näiteks mõõta mitte ainult kogu protsessori, vaid ka iga protsessorituuma koormust eraldi. Kui teil on 40 protsessorituuma, siis vastavalt sellele teil on 40 korda rohkem ajakavasid protsessori koormuse mõõtmiseks.

Kuid see pole veel kõik. Iga protsessorituuma puhul võivad olla mitmed olekud, nagu idle, kui see ei tee midagi. Lisaks on olemas töö user space'is, töö kernel space'is ja muid olekuid. Iga sellist olekut on samuti võimalik mõõta eraldi ajajoonena. See suurendab ridade arvu 7-8 korda.

Meie uurimisest saime ühe mõõdiku põhjal 40 x 8 = 320 mõõdikut ainult ühe arvuti kohta. Kui korrutame selle 100-ga, saame 32 000 asemel 400.

Hiljem ilmus Kubernetes. Ja see halvenes veelgi, kuna Kuberneteses võidakse hostida palju erinevaid teenuseid. Iga teenus Kuberneteses koosneb paljusid pod'idest. Kõike seda tuleb jälgida. Lisaks on meil pidev uute versioonide juurutamine teie teenuste jaoks. Iga uue versiooni jaoks tuleb luua uued ajajooned. Lõppkokkuvõttes kasvab ajajoonte arv eksponentsiaalselt ja seisame silmitsi suure hulga ajajoonte probleemiga, mida nimetatakse high-cardinality. VictoriaMetrics suudab selle probleemiga tõhusalt toime tulla võrreldes teiste ajajoonte andmebaasidega.

Vaatame lähemalt high churn rate'i. Mis põhjustab high churn rate'i tootmises? Sest mõned sildid ja tähised muutuvad pidevalt.

Näiteks võtame Kubernetes, kus on mõisted deployment, st kui teie rakenduse uus versioon rakendatakse. Kubernetes'e arendajad otsustasid mingil põhjusel lisada deployment'i id sildi.

Kuhu see viis? See tähendab, et iga uue deployment'i puhul katkestatakse kõik vanad ajajooned ja nende asemel algavad uued ajajooned uue sildi väärtusega deployment_id. Selliseid ridasid võib olla sadu tuhandeid ja isegi miljoneid.

Kogu selle asja oluline eripära on see, et ajajoonte koguarv kasvab, kuid ajajoonte arv, mis praegu on aktiivsed, kuhu andmed voolavad, jääb konstantseks. Seda olekut nimetatakse – high churn rate.

High churn rate'i peamine probleem on tagada pidev otsingukiirus kõigi ajajoonte seas, mis vastavad määratud siltide kogumile teatud ajavahemiku jooksul. Tüüpiliselt on see ajavahemik viimase tunni või viimase päeva jooksul.

Kuidas seda probleemi lahendada? Siin on esimene variant. See on pöördindeksi jagamine sõltumatuteks osadeks ajaperioodi kaupa. T. e. kui on möödunud mingi ajavahemik, lõpetame käesoleva pöördindeksiga töötamise ja loome uue pöördindeksi. Möödub veel üks ajavahemik, loome veel ühe ja veel ühe.

Ja nende pöördindeksite valimisel leiame need pöördindeksid, mis jäävad antud ajavahemikku. Ja seega valime sealt ajaliste järjestuste ID-d.

See võimaldab ressursse säästa, kuna me ei pea vaatama osi, mis ei mahu antud ajavahemikku. T. e. tavaliselt, kui me valime andmed viimase tunni jooksul, siis eelnevate ajavahemike jaoks jätame päringud vahele.

On olemas veel üks lahendus sellele probleemile. See on iga päeva jaoks eraldi ajajärjestuste ID-de nimekirja hoidmine, mis sellel päeval esinesid.

Selle lahenduse eelis võrreldes eelneva lahendusega on selles, et me ei dubleeri teavet ajajärjestuste kohta, mis ei kao aja jooksul. Need on pidevalt olemas ja ei muutu.

Puuduseks on see, et selline lahendus on keerulisem rakendada ja debugeerida. Ja VictoriaMetrics valis selle lahenduse. See on ajalooliselt nii kujunenud. See lahendus näitab end samuti üsna hästi, võrreldes eelneva lahendusega, kuna see lahendus ei olnud ellu viidud seetõttu, et tuli dubleerida andmed igas jagunemises ajajärjestuste jaoks, mis ei muutu, t. e. mis ei kao aja jooksul. VictoriaMetrics oli esmajoones optimeeritud diskiruumi tarbimise osas ja eelmine rakendus halvendas diskiruumi tarbimist. Kuid see rakendus sobib paremini diskiruumi tarbimise minimeerimiseks, seega see valiti.

Pidime selle vastu võitlema. Võitlus seisnes selles, et antud rakenduses tuleb siiski valida palju suurem hulk timeseries_ids andmete jaoks, kui siis, kui pöördindeks on jagatud ajaperioodi kaupa.

Kuidas me selle probleemi lahendasime? Me lahendasime selle originaalsel viisil – salvestades iga pöördindeksi kirje sisse mitmeid ajajärjestuste identifikaatoreid ühe identifikaatori asemel. T. e. meil on võti label=value, mis esineb igas ajareas. 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 kirjutis, mille prefiks on sama kui kõigil teistel. Eelmise kirje väärtus sisaldab kõiki ajareade id-sid.

See võimaldas suurendada sellise pöördindeksi skaneerimise kiirus kuni 10 korda. Ja vähendada mälu tarbimist vahemäes, kuna nüüd salvestame rea label=value ainult üks kord vahemäesse koos N korraga. Ja see rida võib olla suur, kui teie siltides ja märgendites on pikad read, mille paneb sinna Kubernetes.

Veel üks võimalus pöördindeksi otsimise kiirusel kiirendamiseks on sharding. Luues mitu pöördindeksit ühe asemel ja jagades andmed nende vahel võtme järgi. See on komplekt key=value paare. St. meil on mitu sõltumatut pöördindeksit, mida saame küsida paralleelselt mitmel protsessoril. Eelivad rakendused võimaldasid töötada ainult ühe protsessori režiimis, st skaneerida andmeid ainult ühel tuumal. See lahendus võimaldab skaneerida andmeid kohe mitmel tuumal, nagu ClickHouse seda armastab teha. Seda plaanime rakendada.

Ja nüüd naaseme meie seadmete juurde – lõikamise funktsioonile timeseries_ids. Vaatame, millised võivad olla rakendused. See funktsioon võimaldab leida timeseries_ids antud komplekti jaoks label=value.

Esimene variant – see on naive rakendus. Kaks sisemist tsüklit. Saame funktsioonile sisendi intersectInts kaks slice'i — a ja b. Väljundina peaks see meile tagastama nende slice'ide lõike.

Naive rakendus näeb välja nii. Läbime kõik väärtused slice'ist a, selle tsükli sees kontrollime kõiki väärtusi slice'ist b. Ja võrdleme neid. Kui nad klapivad, siis oleme leidnud lõike. Ja salvestame selle result.

Millised on puudused? Kvadratiivne keerukus – see on tema peamine puudus. Näiteks, kui teie slice'i suurused a ja b on miljon, siis see funktsioon ei naudi kunagi vastust. Sest tal tuleb teha üks triljon iteratsiooni, mis on isegi tänapäevastele arvutitele väga palju.

Teine rakendus põhineb kaardil. Loome kaardi. Paneme sellesse kaardisse kõik väärtused slice'ist a. Siis liigume eraldi tsükliga slice'i b. Ja kontrollime – kas see väärtus on slice'ist b map. Kui see on olemas, lisame selle tulemustesse.

Millised on eelised? Eelis seisneb selles, et siin on ainult lineaarne keerukus. See tähendab, et funktsioon täidab ülesande palju kiiremini suurte slices'i suuruste korral. Miljoni suuruse slice'i jaoks täidab see funktsioon 2 miljonit iteratsiooni, erinevalt triljonist iteratsioonist, nagu eelnevas funktsioonis.

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

Teine puudus – see on suur overhead hash'i tegemisel. See puudus ei ole sugugi ilmselge. Ka meie jaoks ei olnud see alguses väga ilmne, seetõttu oli VictoriaMetrics'i rakendamine intersection'i kaudu map. Kuid seejärel profilib profili jälgimise käigus näitas, et peamine protsessori aeg kulub map'i kirjutamisele ja selle map'is oleva väärtuse kontrollimisele.

Miks kulub protsessorite aeg just nendes kohtades? Sest nendes ridades teostab Go hash’imise toimingut. See tähendab, et see arvutab võtme hash’i, et seejärel pöörduda antud indeksi poole HashMap'is. Hash’i arvutamise operatsioon kestab kümneid nanosekundeid. See on VictoriaMetrics'i jaoks aeglane.

Otsustasin rakendada bitset'i, mis on spetsiaalselt selle juhtumi jaoks optimeeritud. Nii näeb nüüd kahte slices'i ristumist. Siin loome bitset'i. Lisame sellesse esimesest slices'ist elemendid. Seejärel kontrollime nende elementide olemasolu teises slices'is. Ja lisame need tulemustesse. Peaaegu ei erine eelmisest näitest. Ainus, et oleme siin asendanud juurdepääsu map'ile kohandatud funktsioonidega. add ja has.

Esmapilgul näib, et see peaks töötama aeglasemalt, kui varem kasutati standardset map'i, nüüd kutsutakse välja mõned funktsioonid, kuid profileerimine näitab, et see asi töötab 10 korda kiiremini kui standardne map VictoriaMetrics'i jaoks.

Lisaks kasutab see võrreldes map'i rakendusega märgatavalt vähem mälu. Sest me salvestame siin bitid 8-baidiste väärtuste asemel.

Selle rakendamise puudus on see, et see ei ole nii ilmne, mitte triviaalne.

Veel inimesed ei pruugi märkida, et sellel lahendusel on üks puudus: see võib mõnes olukorras halvasti töötada. See tähendab, et see on optimeeritud konkreetse juhtumi, VictoriaMetrics'i ajavoo id-de ristumiste jaoks. See ei tähenda, et see sobib kõigile juhtumitele. Kui seda vale kasutada, siis saame mitte jõudluse suurenemise, vaid mälu ületäitumise vea ja jõudluse vähenemise.

Vaadakem selle struktuuri rakendust. Kui soovite vaadata, siis see asub VictoriaMetrics'i lähtekoodis kaustas lib/uint64set. See on optimeeritud just VictoriaMetrics'i jaoks, kus timeseries_id on 64-bitine väärtus, kus esimesed 32 bitti on peaaegu pidevad ja ainult viimased 32 bitti muutuvad.

See andmestruktuur ei salvestata kettale, see töötab ainult mälu sees.

Siin on selle API. See ei ole väga keeruline. API on kohandatud just VictoriaMetrics'i konkreetse kasutusnäite järgi. See tähendab, et siin ei ole üleliigseid funktsioone. Siin on funktsioonid, mida VictoriaMetrics selgelt kasutab.

On funktsioon add, mis lisab uusi väärtusi. On funktsioon has, mis kontrollib uusi väärtusi. Ja on funktsioon del, mis eemaldab väärtuseid. On abifunktsioon len, mis tagastab hulga suuruse. Funktsioon clone kloneerib hulga. Ja funktsioon appendto muudab selle komplekti viiluks. timeseries_ids.

Nii näeb see andmestruktuuri rakendus välja. Set'is on kaks elementi:

ItemsCount – see on abiväli, et kiiresti tagastada elementide arvu set'is. Ilma selle abiväljata oleks saanud hakkama, kuid see tuli siia lisada, sest VictoriaMetrics küsib oma algoritmides sageli bitset'i pikkust.
Teine väli on buckets. See on viil struktureeritud bucket32. Igas struktuuris on salvestatud hi väli. See on ülemised 32 bitti. Ja kaks viilu — b16his ja buckets API-s bucket16 struktuurid.

Siin on salvestatud teise osa 64-bitise struktuuri ülemised 16 bitti. Ja siin on salvestatud bitset'id iga byte'i madalamate 16 bitti jaoks.

Bucket64 koosneb massiivist uint64. Pikkus arvutatakse nende muutujate abil. Ühes bucket16 võib maksimaalselt hoida 2^16=65536 bitti. Kui jagada see 8-ga, siis on see 8 kilobaiti. Kui jagada veel 8-ga, siis on see 1000 uint64 väärtuses. See tähendab, et Bucket16 – see on 8-kilobaitine struktuur.

Vaadakem, kuidas on rakendatud üks selle struktuuri meetod uut väärtust lisada.

Kõik algab uint64 väärtused. Arvutame ülemised 32 bitti, arvutame alumised 32 bitti. Läbime kõik buckets. Võrdleme iga bucket'i ülemisi 32 bitti lisatavaga. Ja kui need kattuvad, kutsume välja funktsiooni add struktuuris b32 buckets. Ja lisame sinna alumised 32 bitti. Ja kui see tagastas true, siis tähendab, et oleme sellise väärtuse sinna lisanud ja meil ei olnud sellist väärtust. Kui see tagastab false, siis selline väärtus oli juba olemas. Siis suurendame struktuuri elementide arvu.

Kui me ei leidnud vajalikku bucket'i vajaliku hi-väärtusega, siis kutsume välja funktsiooni addAlloc, mis eraldab uue bucket'i, lisades selle bucket-struktuuri.

See on funktsiooni b32.add. See sarnaneb eelneva teostusega. Arvutame vanemad 16 bitti, nooremad 16 bitti.

Siis käime läbi kõik ülemised 16 bitti. Leiame kattuvused. Ja kattumise korral kutsume välja meetodi add, mida käsitleme järgmisel lehel bucket16.

Ja see on kõige madalam tase, mis peaks olema maksimaalselt optimeeritud. Arvutame uint64 id väärtuse slice bit, samuti bitmask. See on mask selle 64-bitise väärtuse jaoks, millega saab kontrollida selle bitti olemasolu või selle seadmist. Kontrollime, kas see bitt on seatud ja seadistame selle, ning tagastame olemasolu. Selline on meie teostus, mis võimaldas kiirendada ids ajaseeriate ristumiste operatsiooni 10 korda võrreldes tavapäraste maps'idega.

VictoriaMetrics'is on peale selle optimeerimise palju teisi optimeerimisi. Enamik neist optimeerimistest ei ole lisatud lihtsalt niisama, vaid pärast koodi profiliseerimist tootmises.

See on optimeerimise peamine reegel - ära lisa optimeerimist, oletades, et siin on kitsaskoht, sest võib juhtuda, et seal ei olegi kitsaskohta. Optimeerimine halvendab tavaliselt koodi kvaliteeti. Seetõttu on mõistlik optimeerida ainult pärast profiliseerimist ja eelistatult tootmises, et need oleksid reaalsed andmed. Kui interese, siis võite vaadata VictoriaMetrics'i allikaid ja uurida teisi seal olevaid optimeerimisi.

Mul on küsimus bitset'i kohta. Väga sarnane C++ vector bool'i teostusele, optimeeritud bitset. Kas te võtsite sealt teostuse?

Ei, mitte sealt. Selle bitset'i elluviimisel tuginesin nende ids timeseries struktuuri teadmistele, mida kasutatakse VictoriaMetrics'is. Nende struktuur on selline, et ülemised 32 bitti on enamasti püsivad. Alumised 32 bitti võivad muutuda. Mida madalam on bitt, seda tihedamini võib see muutuda. Seetõttu on see elluviimine optimeeritud just selle andmestruktuuri jaoks. C++ elluviimine, niipalju kui ma tean, on optimeeritud üldise juhtumi jaoks. Kui teha optimeerimist üldise juhtumi jaoks, siis see tähendab, et see ei ole konkreetse juhtumi jaoks kõige optimaalsem.

Soovitan teil veel vaadata Alexei Milovid'i ettekannet. Ta rääkis kuskil kuu aega tagasi ClickHouse optimeerimisest konkreetsete spetsialiseerumiste jaoks. Ta räägib, et üldjuhul on C++ elluviimine või mõni muu elluviimine suunatud hea töö tagamisele keskmiselt. See võib töötada halvemini kui spetsialiseeritud elluviimine konkreetsete teadmiste jaoks, nagu meil, kui me teame, et ülemised 32 bitti on enamasti püsivad.

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

Kardinaalseid erinevusi on palju. Kui rääkida jõudlusest ja mälu tarbimisest, siis InfluxDB näitab testides 10 korda suuremat mälu tarbimist kõrge kardinaalsusega ajarealistes, kui neid on palju, näiteks miljonites. Näiteks VictoriaMetrics tarbib 1 GB miljoni aktiivse rea kohta, samas kui InfluxDB tarbib 10 Gb. Ja see on suur erinevus.

Teine kardinaalne erinevus on see, et InfluxDB-l on kummalised päringukeeled – Flux ja InfluxQL. Need ei ole ajarealistega töötamiseks eriti mugavad võrreldes PromQL, mida toetatakse VictoriaMetrics'is. PromQL on päringukeel Prometheuses.

Ja veel üks erinevus – InfluxDB-l on veidi kummaline andmemudel, kus igas real võib olla mitu field'i erineva sildistuse kogumiga. Need read jagunevad veel erinevateks tabeliteks. Need lisakompleksused raskendavad sellele andmebaasile järgnevate toimingute tegemist. Seda on keeruline hallata ja mõista.

VictoriaMetrics'is on kõik kindlasti lihtsam. Seal esindab iga ajareaal võtme-väärtuse paari. Väärtus on punktide komplekt – (timestamp, value), võtme aga on kogum label=value. Ei ole mingit eraldatust fields ja measurements vahel. See võimaldab teil valida ükskõik milliseid andmeid ja seejärel neid kombineerida, liita, lahutada, korrutada ja jagada, erinevalt InfluxDB-st, kus erinevate ridade vahelisi arvutusi pole seni niipalju teadaolevalt rakendatud. Isegi kui nad on rakendatud, on see keeruline ja selleks tuleb kirjutada palju koodi.

Mul on täiendav küsimus. Kas mõistsin õigesti, et oli mingi probleem, millest rääkisite, et see pööratud indeks ei mahu mällu, seetõttu toimub seal partitsioneerimine?

Alguses näitasin ma naiivset rakendust pööratud indeksist standardse Go map’iga. Selline rakendus ei sobi andmebaaside jaoks, sest see pööratud indeks ei salvestata kettale, aga andmebaasid peavad andmeid salvestama, et need oleks taas käivitatuna kergesti kättesaadavad. Antud rakenduses kaob teie pööratud indeks rakenduse taaskäivitamisel. Ja kaotate juurdepääsu kõikidele andmetele, kuna te ei suuda neid leida.

Tere! Aitäh ettekande eest! Minu nimi on Pavel. Olen ettevõttest Wildberries. Mul on teile mõned küsimused. Esimene küsimus. Kuidas arvate, et kui valiksite oma rakenduse arhitektuuri ehitamisel teise printsiibi ja partitsioneeriksite andmed ajas, siis võiks-olla suudaksite te andmete ristumisi otsingul teha, tuginedes ainult sellele, et ühes partitsioonis on andmed ühe ajavahemiku kohta, st ühe aja vahe kohta ja te ei peaks muretsema selle üle, et teil on tükid erinevalt laiali jaotatud? Teine küsimus — kuna te rakendate sarnast algoritmi bitsetiga ja kõigega muuga, kas olete proovinud kasutada protsessori käske? Võib-olla olete proovinud selliseid optimeerimisi?

Teisele küsimusele vastan kohe. Me ei ole sinna veel jõudnud. Aga kui on vaja, siis jõuame. Aga esimese, mis oli küsimus?

Te arutasite kahte stsenaariumi. Ja ütlesite, et valisite teise keerukama rakenduse. Ja ei eelistanud esimest, kus andmed on ajas partitsioneeritud.

Jah. Esimeses variandis oleks indeksi kogumaht suurem, kuna igas partitsioonis peaksime hoidma andmete koopiaid nende ajaseeriate jaoks, mis kestavad läbi kõikide nende partitsioonide. Ja kui teie ajaseeriate churn rate on madal, st pidevalt kasutatakse samu seeriaid, siis esimese variandi puhul kaotaksime oluliselt rohkem kettaruumi võrreldes teise variandiga.

Aga jah, ajapõhine partitsioneerimine on hea variant. Seda kasutab ka Prometheus. Kuid Prometheusel on teine puudus. Kui need andmeosad ühendatakse, peab ta hoidma mälus kõiki label’i ja ajaseeriate metaandmeid. Seetõttu, kui andmeosad, mida ta ühendab, on suured, kasvab mällu minev tarbimine oluliselt, erinevalt VictoriaMetricsist. VictoriaMetrics ei tarbi ühendamisel üldse mälu, seal tarbitakse vaid paar kilobaiti, sõltumata ühendatud andmeosade suurusest.

Teie kasutatav algoritm tarbib mälu. Seal tähistatakse ajaseeriate silti, millel on väärtused. Nii kontrollite, kas ühes andme massiivis on paariline olemas ja teisest. Ja saate aru – kas toimus ristumine või mitte. Tüüpiliselt rakendavad andmebaasid kursoreid, iteraatoreid, mis hoiavad oma praegust olekut ja liiguvad järjestatud andmete kaudu, tagades, et nende toimingute keerukus on lihtne.

Miks me ei kasuta andmete ristumise jaoks kursoreid?

Jah.

Meie LevelDB-s või mergeset'is ongi just järjekorras olevad read. Me saame kursori abil läbida ja leida ristumise. Aga miks ei kasuta? Sest – see on aeglane. Sest kursorid eeldavad, et igale reale tuleb funktsioon kutsuda. Funktsiooni kutsumine on 5 nanosekundit. Ja kui teil on 100 000 000 rida, siis kulutame pelgalt funktsiooni kutsumise peale pool sekundit.

Selline asi on, jah. Ja mul on viimane küsimus. Küsimus, mis võib-olla tunduda veidi imelik. Miks ei saa andmete sisestamise hetkel kõiki vajalikke agregaatide arvestusi teha ja neid vajalikus formaadis salvestada? Miks hoida tohutul hulgal andmeid süsteemidesse nagu VictoriaMetrics, ClickHouse jne, et hiljem neile väga palju aega kulutada?

To clarify, let me give an example. How does a small toy speedometer work? It records the distance you have traveled, continuously adding it to one variable, while in another it tracks time. Then it divides to get the average speed. You can do something similar by collecting all necessary facts on the fly.

Alright, I understand the question. Your example has its merits. If you know which aggregates you need, it’s the best implementation. The problem is that people save these metrics, some data in ClickHouse, and they don’t yet know how they’ll aggregate and filter them in the future, so they end up saving all the raw data. But if you know you need to calculate something average, why not calculate it instead of storing a bunch of raw values? This is only if you know exactly what you need.

By the way, databases for storing time series support aggregate counting. For instance, Prometheus supports recording rules. This can be done if you know what aggregates you will need. This feature is not available in VictoriaMetrics yet, but Prometheus is usually placed in front of it, where this can be done with recording rules.

For example, at my previous job, we needed to count the number of events in a sliding window over the last hour. The problem was that we had to create a custom implementation in Go, a service for counting this. Ultimately, this service was non-trivial because it's challenging to calculate. The implementation can be simple if you need to count aggregates at fixed time intervals. However, if you want to count events in a sliding window, it's not as easy as it seems. I believe this hasn't been implemented in ClickHouse or time series databases yet because it's complex to do.

And one more question. We were just discussing averaging, and I remembered that there used to be a tool called Graphite with a Carbon backend. It could prune old data, retaining one point per minute, one point per hour, and so on. It's quite convenient if we need raw data, say for a month, while everything else can be pruned. But Prometheus and VictoriaMetrics do not support this functionality. Will it be supported in the future? If not, why?

Aitäh küsimuse eest. Meie kasutajad esitavad seda aeg-ajalt. Nad küsivad, millal me lisame downsampling'i toe. Siin on mitu probleemi. Esiteks, iga kasutaja mõistab seda erinevalt. allapoole näitamine Keegi soovib saada suvalist punkti määratud intervallis, keegi soovib maksimaalseid, minimaalseid, keskmisi väärtuseid. Kui teie andmebaasi salvestavad andmeid paljud süsteemid, siis ei saa neid ühte patta panna. Võib juhtuda, et iga süsteemi jaoks tuleb kasutada erinevat downsampling'ut. Ja see on keeruline ellu viia.

Teiseks on see, et VictoriaMetrics, nagu ka ClickHouse, on optimeeritud töötama suurte tooredate kogustega, seetõttu suudab see töödelda miljardit rida vähem kui sekundiga, kui teil on palju tuumasid teie süsteemis. Aja rea punkte skaneerimine VictoriaMetrics'is – 50 000 000 punkti sekundis ühes tuumas. Ja see jõudlus skaleerub olemasolevatele tuumadele. Ehk siis kui teil on näiteks 20 tuuma, siis saate miljard punkti sekundis skaneerida. Ja see omadus vähendab VictoriaMetrics'i ja ClickHouse'i vajadust downsampling'i järele.

Veel üks omadus on see, et VictoriaMetrics tihendab andmeid tõhusalt. Tihendamine keskmiselt production'is on 0,4 kuni 0,8 baiti punkti kohta. Iga punkt – see on ajatemperatuur + väärtus. Ja see tihendatakse keskmiselt vähem kui ühe baidi alla.

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

Üks millisekund. Hiljuti oli meil vestlus teiste ajareadade andmebaaside arendajatega. Nende minimaalne ajavahemik on üks sekund. Näiteks Graphites on see ka üks sekund. OpenTSDB-s on samuti üks sekund. InfluxDB-s on nanosekundiline täpsus. VictoriaMetrics'is on see üks millisekund, kuna Prometheus'el on üks millisekund. Ja VictoriaMetrics loodi algselt Prometheuse kaugandmete salvestamiseks. Kuid nüüd suudab see salvestada andmeid ka muudest süsteemidest.

Inimene, kellega ma rääkisin, ütleb, et neil on sekundiline täpsus — sellest piisab, kuna see sõltub andmete tüübist, mida ajareadadesse salvestatakse. Kui need on DevOps andmed või andmed infrastruktuurist, kus te kogute neid 30 sekundi, minuti kaupa, siis seal piisab sekundilisest täpsusest, vähem ei ole vajalik. Kuid kui te kogute andmeid kõrge sagedusega kauplemissüsteemidest, siis on vajalik nanosekundiline täpsus.

Millisekundi täpsus VictoriaMetrics sobib nii DevOps juhtumitele, kui ka enamikule juhtumitest, millest ma aruandesse alguses rääkisin. Ainus, mille jaoks see ei pruugi sobida, on kõrge sagedusega kaubandussüsteemid.

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

Täielik tagasikäidatav ühilduvus. VictoriaMetrics toetab täielikult PromQL-i. Peale selle lisab see ka täiendavaid funktsioone PromQL-ile, mida nimetatakse MetricsQL. Selle täiendava funktsiooni kohta on YouTube'is ettekandeid. Olen sellest rääkinud Monitoring Meetup'il kevadel Peterburis.

Telegrami kanal VictoriaMetrics.

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