Suosittelen, että luet Alexander Valyalkinin loppuvuoden 2019 raportin "Go optimizations in VictoriaMetrics"
— nopea ja skaalautuva DBMS datan tallentamiseen ja käsittelyyn aikasarjan muodossa (tietue muodostaa ajan ja tätä aikaa vastaavat arvot, jotka saadaan esimerkiksi antureiden tilan säännöllisellä kyselyllä tai keräämällä mittarit).
Tässä on linkki tämän raportin videoon -
Kerro meille itsestäsi. Olen Alexander Valyalkin. Tässä . Olen intohimoinen Go:sta ja suorituskyvyn optimoinnista. Kirjoitin paljon hyödyllisiä ja ei kovin hyödyllisiä kirjastoja. Ne alkavat jommallakummalla fasttai quick etuliite.
Työskentelen tällä hetkellä VictoriaMetricsin parissa. Mikä se on ja mitä minä teen siellä? Puhun tästä tässä esityksessä.
Raportin pääpiirteet ovat seuraavat:
- Ensin kerron sinulle, mikä VictoriaMetrics on.
- Sitten kerron teille, mitä aikasarjat ovat.
- Sitten kerron kuinka aikasarjatietokanta toimii.
- Seuraavaksi kerron tietokanta-arkkitehtuurista: mistä se koostuu.
- Ja sitten siirrytään VictoriaMetricsin optimointiin. Tämä on optimointi käänteiselle indeksille ja optimointi Go:n bittijoukon toteutukselle.
Tietääkö kukaan yleisöstä mikä VictoriaMetrics on? Vau, monet ihmiset jo tietävät. Se on hyvä uutinen. Niille, jotka eivät tiedä, tämä on aikasarjatietokanta. Se perustuu ClickHouse-arkkitehtuuriin, joihinkin ClickHouse-toteutuksen yksityiskohtiin. Esimerkiksi: MergeTree, rinnakkaislaskenta kaikilla käytettävissä olevilla prosessoriytimillä ja suorituskyvyn optimointi käsittelemällä tietolohkoja, jotka on sijoitettu prosessorin välimuistiin.
VictoriaMetrics tarjoaa paremman tiedon pakkaamisen kuin muut aikasarjatietokannat.
Se skaalautuu pystysuunnassa - eli voit lisätä enemmän prosessoreita, enemmän RAM-muistia yhteen tietokoneeseen. VictoriaMetrics hyödyntää näitä käytettävissä olevia resursseja menestyksekkäästi ja parantaa lineaarista tuottavuutta.
VictoriaMetrics skaalautuu myös vaakasuoraan - eli voit lisätä VictoriaMetrics-klusteriin lisäsolmuja, ja sen suorituskyky kasvaa lähes lineaarisesti.
Kuten arvasit, VictoriaMetrics on nopea tietokanta, koska en voi kirjoittaa muita. Ja se on kirjoitettu Go-kielellä, joten puhun siitä tässä tapaamisessa.
Kuka tietää, mikä aikasarja on? Hän tuntee myös monia ihmisiä. Aikasarja on sarja pareja (timestamp, значение), jossa nämä parit on lajiteltu ajan mukaan. Arvo on liukuluku - float64.
Jokainen aikasarja tunnistetaan yksilöllisesti avaimella. Mistä tämä avain koostuu? Se koostuu ei-tyhjistä avainarvo-parien joukosta.
Tässä on esimerkki aikasarjasta. Tämän sarjan avain on luettelo pareista: __name__="cpu_usage" on mittarin nimi, instance="my-server" - tämä on tietokone, jolle tämä mittari kerätään, datacenter="us-east" - tämä on tietokeskus, jossa tämä tietokone sijaitsee.
Päädyimme aikasarjan nimeen, joka koostuu kolmesta avainarvoparista. Tämä avain vastaa pariluetteloa (timestamp, value). t1, t3, t3, ..., tN - nämä ovat aikaleimoja, 10, 20, 12, ..., 15 — vastaavat arvot. Tämä on suorittimen käyttö tietyllä rivillä tietyllä hetkellä.
Missä aikasarjoja voidaan käyttää? Onko kenelläkään mitään käsitystä?
- DevOpsissa voit mitata suorittimen, RAM-muistin, verkon, rps:n, virheiden määrän jne.
- IoT - voimme mitata lämpötilaa, painetta, geokoordinaatteja ja jotain muuta.
- Myös rahoitus – voimme seurata kaikenlaisten osakkeiden ja valuuttojen hintoja.
- Lisäksi aikasarjoja voidaan käyttää tuotantoprosessien seurannassa tehtaissa. Meillä on käyttäjiä, jotka käyttävät VictoriaMetricsiä robottien tuuliturbiinien valvontaan.
- Aikasarjat ovat hyödyllisiä myös tiedon keräämiseen eri laitteiden antureilta. Esimerkiksi moottorille; rengaspaineen mittaamiseen; nopeuden, etäisyyden mittaamiseen; bensankulutuksen mittaamiseen jne.
- Aikasarjoja voidaan käyttää myös lentokoneiden seurantaan. Jokaisessa lentokoneessa on musta laatikko, joka kerää aikasarjoja lentokoneen terveydentilasta. Aikasarjoja käytetään myös ilmailuteollisuudessa.
- Terveydenhuolto on verenpainetta, pulssia jne.
Saattaa olla enemmän sovelluksia, jotka unohdin, mutta toivon, että ymmärrät, että aikasarjoja käytetään aktiivisesti nykymaailmassa. Ja niiden käyttömäärä kasvaa joka vuosi.
Miksi tarvitset aikasarjatietokantaa? Miksi et voi käyttää tavallista relaatiotietokantaa aikasarjojen tallentamiseen?
Koska aikasarjat sisältävät yleensä suuren määrän tietoa, jota on vaikea tallentaa ja käsitellä perinteisissä tietokantoissa. Siksi aikasarjoille ilmestyi erikoistuneita tietokantoja. Nämä pohjat tallentavat pisteitä tehokkaasti (timestamp, value) annetulla avaimella. Ne tarjoavat API:n tallennettujen tietojen lukemiseen avaimella, yhdellä avainarvoparilla tai useilla avainarvoparilla tai säännöllisellä lausekkeella. Jos esimerkiksi haluat löytää kaikkien palveluidesi suorittimen kuormituksen palvelinkeskuksessa Amerikassa, sinun on käytettävä tätä pseudokyselyä.
Tyypillisesti aikasarjatietokannat tarjoavat erikoistuneita kyselykieliä, koska aikasarja-SQL ei sovellu kovin hyvin. Vaikka on olemassa tietokantoja, jotka tukevat SQL:ää, se ei ole kovin sopiva. Kyselykielet, kuten , , , . Toivon, että joku on kuullut ainakin yhden näistä kielistä. Monet ihmiset ovat luultavasti kuulleet PromQL:stä. Tämä on Prometheus-kyselykieli.
Tältä näyttää nykyaikainen aikasarjatietokanta-arkkitehtuuri käyttäen VictoriaMetricsiä esimerkkinä.
Se koostuu kahdesta osasta. Tämä on käänteisen indeksin tallennus ja aikasarjaarvojen tallennus. Nämä arkistot on erotettu toisistaan.
Kun uusi tietue saapuu tietokantaan, käytämme ensin käänteistä indeksiä löytääksemme tietyn joukon aikasarjatunnisteen label=value tietylle mittarille. Löydämme tämän tunnisteen ja tallennamme arvon tietovarastoon.
Kun tulee pyyntö tietojen noutamisesta TSDB:stä, siirrymme ensin käänteiseen indeksiin. Otetaan kaikki timeseries_ids tätä sarjaa vastaavat tietueet label=value. Ja sitten saamme kaikki tarvittavat tiedot tietovarastosta indeksoimana timeseries_ids.
Katsotaanpa esimerkkiä siitä, kuinka aikasarjatietokanta käsittelee saapuvan valintakyselyn.
- Ensinnäkin hän saa kaiken
timeseries_idskäänteisestä indeksistä, joka sisältää annetut paritlabel=value, tai täyttää tietyn säännöllisen lausekkeen. - Sitten se hakee kaikki datapisteet tietovarastosta tietyllä aikavälillä löydetyille
timeseries_ids. - Tämän jälkeen tietokanta suorittaa joitakin laskelmia näille datapisteille käyttäjän pyynnöstä. Ja sen jälkeen se palauttaa vastauksen.
Tässä esityksessä kerron teille ensimmäisestä osasta. Tämä on haku timeseries_ids käänteisellä indeksillä. Voit katsoa toisen ja kolmannen osan myöhemmin tai odota, kunnes teen muita raportteja :)
Siirrytään käänteiseen indeksiin. Monien mielestä tämä on yksinkertaista. Kuka tietää, mikä käänteinen indeksi on ja miten se toimii? Voi, ei enää niin paljon ihmisiä. Yritetään ymmärtää mikä se on.
Se on itse asiassa yksinkertaista. Se on yksinkertaisesti sanakirja, joka kartoittaa avaimen arvoon. Mikä on avain? Tämä pariskunta label=valueMissä label и value - Nämä ovat linjoja. Ja arvot ovat sarja timeseries_ids, joka sisältää annetun parin label=value.
Käänteinen indeksi antaa sinun löytää nopeasti kaiken timeseries_ids, jotka ovat antaneet label=value.
Sen avulla voit myös löytää nopeasti timeseries_ids aikasarjat useille pareille label=valuetai pariskunnille label=regexp. Miten tämä tapahtuu? Löytämällä joukon leikkauspisteen timeseries_ids jokaiselle parille label=value.
Katsotaanpa erilaisia käänteisen indeksin toteutusmuotoja. Aloitetaan yksinkertaisimmasta naiivista toteutuksesta. Hän näyttää tältä.
Toiminto getMetricIDs saa listan merkkijonoista. Jokainen rivi sisältää label=value. Tämä funktio palauttaa luettelon metricIDs.
Kuinka se toimii? Tässä meillä on globaali muuttuja nimeltä invertedIndex. Tämä on tavallinen sanakirja (map), joka yhdistää merkkijonon slice ints. Rivi sisältää label=value.
Toiminnon toteutus: hanki metricIDs ensimmäisen label=value, sitten käymme läpi kaiken muun label=value, me tajuamme sen metricIDs heille. Ja kutsu toiminto intersectInts, josta keskustellaan alla. Ja tämä funktio palauttaa näiden luetteloiden leikkauspisteen.
Kuten näette, käänteisen indeksin toteuttaminen ei ole kovin monimutkaista. Mutta tämä on naiivi toteutus. Mitä haittoja sillä on? Naiivin toteutuksen suurin haittapuoli on, että tällainen käänteinen indeksi on tallennettu RAM:iin. Kun sovellus on käynnistetty uudelleen, menetämme tämän indeksin. Tätä hakemistoa ei ole tallennettu levylle. Tällainen käänteinen indeksi ei todennäköisesti sovellu tietokantaan.
Toinen haittapuoli liittyy myös muistiin. Käänteisen indeksin tulee mahtua RAM-muistiin. Jos se ylittää RAM-muistin koon, ilmeisesti saamme - muistivirheen. Ja ohjelma ei toimi.
Tämä ongelma voidaan ratkaista käyttämällä valmiita ratkaisuja, kuten Tai .
Lyhyesti sanottuna tarvitsemme tietokannan, jonka avulla voimme tehdä kolme toimintoa nopeasti.
- Ensimmäinen toimenpide on tallennus
ключ-значениеtähän tietokantaan. Hän tekee tämän hyvin nopeasti, missäключ-значениеovat mielivaltaisia merkkijonoja. - Toinen operaatio on arvon nopea haku tietyllä avaimella.
- Ja kolmas operaatio on kaikkien arvojen nopea haku tietyllä etuliitteellä.
LevelDB ja RocksDB - nämä tietokannat ovat Googlen ja Facebookin kehittämiä. Ensin tuli LevelDB. Sitten Facebookin kaverit ottivat LevelDB:n ja alkoivat parantaa sitä, he tekivät RocksDB:n. Nyt melkein kaikki sisäiset tietokannat toimivat RocksDB:ssä Facebookin sisällä, mukaan lukien ne, jotka on siirretty RocksDB:hen ja MySQL:ään. He antoivat hänelle nimen .
Käänteinen indeksi voidaan toteuttaa käyttämällä LevelDB:tä. Kuinka tehdä se? Tallennamme avaimeksi label=value. Ja arvo on sen aikasarjan tunniste, jossa pari on läsnä label=value.
Jos meillä on useita aikasarjoja tietyllä parilla label=value, niin tässä tietokannassa on useita rivejä samalla avaimella ja eri timeseries_ids. Saadaksesi luettelon kaikista timeseries_ids, jotka alkavat tällä label=prefix, teemme alueskannauksen, jota varten tämä tietokanta on optimoitu. Eli valitsemme kaikki rivit, jotka alkavat label=prefix ja hanki tarvittava timeseries_ids.
Tässä on esimerkkitoteutus siitä, miltä se näyttäisi Gossa. Meillä on käänteinen indeksi. Tämä on LevelDB.
Toiminto on sama kuin naiivissa toteutuksessa. Se toistaa naiivia toteutusta lähes rivi riviltä. Ainoa pointti on, että sen sijaan, että kääntyisi map pääsemme käänteiseen indeksiin. Saamme kaikki arvot ensimmäiseksi label=value. Sitten käymme läpi kaikki jäljellä olevat parit label=value ja hanki niille vastaavat metritunnusjoukot. Sitten löydämme risteyksen.
Kaikki näyttää olevan kunnossa, mutta tällä ratkaisulla on haittoja. VictoriaMetrics otti alun perin käyttöön käänteisen indeksin, joka perustui LevelDB:hen. Mutta lopulta minun oli luovuttava siitä.
Miksi? Koska LevelDB on hitaampi kuin naiivi toteutus. Naiivissa toteutuksessa, kun annetaan annettu avain, haemme välittömästi koko viipaleen metricIDs. Tämä on erittäin nopea toimenpide - koko siivu on valmis käytettäväksi.
LevelDB:ssä aina kun funktiota kutsutaan GetValues sinun täytyy käydä läpi kaikki rivit, jotka alkavat label=value. Ja hanki arvo jokaiselle riville timeseries_ids. Sellaisesta timeseries_ids kerätä siivu näistä timeseries_ids. Ilmeisesti tämä on paljon hitaampaa kuin pelkkä tavallisen kartan avaaminen avaimella.
Toinen haittapuoli on, että LevelDB on kirjoitettu C-kielellä. C-funktioiden kutsuminen Gosta ei ole kovin nopeaa. Se vie satoja nanosekunteja. Tämä ei ole kovin nopeaa, koska verrattuna tavalliseen go:lla kirjoitettuun funktiokutsuun, joka kestää 1-5 nanosekuntia, ero suorituskyvyssä on kymmenkertainen. VictoriaMetricsille tämä oli kohtalokas virhe :)
Joten kirjoitin oman toteutukseni käänteiselle indeksille. Ja hän soitti hänelle .
Mergeset perustuu MergeTree-tietorakenteeseen. Tämä tietorakenne on lainattu ClickHouselta. Ilmeisesti mergeset tulisi optimoida nopeaa hakua varten timeseries_ids annetun avaimen mukaan. Mergeset on kirjoitettu kokonaan Go-kielellä. Sinä pystyt näkemään . Mergesetin toteutus on kansiossa . Voit yrittää selvittää, mitä siellä tapahtuu.
Mergeset API on hyvin samanlainen kuin LevelDB ja RocksDB. Eli sen avulla voit nopeasti tallentaa uusia tietueita sinne ja valita nopeasti tietueita tietyllä etuliitteellä.
Puhumme mergesetin haitoista myöhemmin. Nyt puhutaan siitä, mitä ongelmia VictoriaMetricsin kanssa ilmeni tuotannossa, kun käänteistä indeksiä toteutettiin.
Miksi ne syntyivät?
Ensimmäinen syy on korkea vaihtuvuus. Venäjäksi käännettynä tämä on usein aikasarjojen muutos. Tällöin aikasarja päättyy ja uusi sarja alkaa tai monet uudet aikasarjat alkavat. Ja tätä tapahtuu usein.
Toinen syy on aikasarjojen suuri määrä. Alussa, kun seuranta yleistyi, aikasarjojen määrä oli pieni. Esimerkiksi jokaisen tietokoneen kohdalla sinun on valvottava suorittimen, muistin, verkon ja levyn kuormitusta. 4 aikasarjaa per tietokone. Oletetaan, että sinulla on 100 tietokonetta ja 400 aikasarjaa. Tämä on hyvin vähän.
Ajan myötä ihmiset tajusivat, että he pystyivät mittaamaan yksityiskohtaisempaa tietoa. Esimerkiksi, älä mittaa koko prosessorin kuormitusta, vaan kunkin prosessorin ytimen kuormitusta erikseen. Jos sinulla on 40 prosessoriydintä, sinulla on 40 kertaa enemmän aikasarjoja prosessorin kuormituksen mittaamiseen.
Mutta siinä ei vielä kaikki. Jokaisella prosessorin ytimellä voi olla useita tiloja, kuten tyhjäkäynti, kun se on käyttämättömänä. Ja myös työskennellä käyttäjätilassa, työskennellä ydintilassa ja muissa tiloissa. Ja jokainen tällainen tila voidaan myös mitata erillisenä aikasarjana. Tämä lisää lisäksi rivien määrää 7-8 kertaa.
Yhdestä mittarista saimme 40 x 8 = 320 mittaria vain yhdelle tietokoneelle. Kerrotaan 100:lla, niin saadaan 32 000 400:n sijaan.
Sitten Kubernetes tuli mukaan. Ja se paheni, koska Kubernetes voi isännöidä monia erilaisia palveluita. Kubernetesin jokainen palvelu koostuu useista koteloista. Ja kaikkea tätä on seurattava. Lisäksi meillä on jatkuvasti uusia versioita palveluistasi. Jokaiselle uudelle versiolle on luotava uudet aikasarjat. Tämän seurauksena aikasarjojen määrä kasvaa eksponentiaalisesti ja kohtaamme suuren aikasarjojen ongelman, jota kutsutaan korkeaksi kardinaaliseksi. VictoriaMetrics selviää siitä menestyksekkäästi verrattuna muihin aikasarjatietokantoihin.
Katsotaanpa tarkemmin korkeaa vaihtuvuusprosenttia. Mikä aiheuttaa korkean tuotannon vaihtuvuusasteen? Koska jotkin tarrojen ja tunnisteiden merkitykset muuttuvat jatkuvasti.
Otetaan esimerkiksi Kubernetes, jolla on konsepti deployment, eli kun sovelluksesi uusi versio julkaistaan. Jostain syystä Kubernetes-kehittäjät päättivät lisätä käyttöönottotunnuksen tarraan.
Mihin tämä johti? Lisäksi jokaisen uuden käyttöönoton yhteydessä kaikki vanhat aikasarjat katkeavat, ja niiden sijaan uudet aikasarjat alkavat uudella tunnistearvolla deployment_id. Tällaisia rivejä voi olla satoja tuhansia ja jopa miljoonia.
Tärkeää tässä kaikessa on, että aikasarjojen kokonaismäärä kasvaa, mutta tällä hetkellä aktiivisten ja dataa vastaanottavien aikasarjojen määrä pysyy vakiona. Tätä tilaa kutsutaan korkeaksi vaihtuvuussuhteeksi.
Suuren vaihtuvuusnopeuden pääongelma on varmistaa tasainen hakunopeus kaikille aikasarjoille tietylle tarrajoukolle tietyllä aikavälillä. Yleensä tämä on viimeisen tunnin tai viimeisen päivän aikaväli.
Kuinka ratkaista tämä ongelma? Tässä on ensimmäinen vaihtoehto. Tämä on jakaa käänteinen indeksi itsenäisiin osiin ajan myötä. Toisin sanoen, kun aikaväli kuluu, lopetamme työskentelyn nykyisen käänteisen indeksin kanssa. Ja luo uusi käänteinen indeksi. Toinen aikaväli kuluu, luomme toisen ja toisen.
Ja kun otamme näytteitä näistä käänteisistä indekseistä, löydämme joukon käänteisiä indeksejä, jotka kuuluvat annetulle intervallille. Ja vastaavasti valitsemme aikasarjan id:n sieltä.
Tämä säästää resursseja, koska meidän ei tarvitse tarkastella osia, jotka eivät ole annetulla aikavälillä. Eli yleensä, jos valitsemme tiedot viimeiseltä tunnilta, ohitamme pyynnöt edellisten aikaväleiden osalta.
Tämän ongelman ratkaisemiseksi on toinenkin vaihtoehto. Tämä tallentaa jokaiselle päivälle erillisen luettelon kyseisenä päivänä esiintyneiden aikasarjojen tunnuksista.
Tämän ratkaisun etuna edelliseen ratkaisuun verrattuna on, että emme kopioi aikasarjatietoja, jotka eivät katoa ajan myötä. Ne ovat jatkuvasti läsnä eivätkä muutu.
Haittapuolena on, että tällainen ratkaisu on vaikeampi toteuttaa ja vaikeampi jäljittää. Ja VictoriaMetrics valitsi tämän ratkaisun. Näin kävi historiallisesti. Tämä ratkaisu toimii myös hyvin edelliseen verrattuna. Koska tätä ratkaisua ei toteutettu, koska kussakin osiossa on tarpeen kopioida dataa aikasarjoille, jotka eivät muutu, eli jotka eivät katoa ajan myötä. VictoriaMetrics oli ensisijaisesti optimoitu levytilan kulutukseen, ja edellinen toteutus pahensi levytilan kulutusta. Mutta tämä toteutus soveltuu paremmin levytilan kulutuksen minimoimiseen, joten se valittiin.
Minun täytyi taistella häntä vastaan. Taistelu oli, että tässä toteutuksessa sinun on silti valittava paljon suurempi numero timeseries_ids datalle kuin silloin, kun käänteinen indeksi on aikaosioitu.
Miten ratkaisimme tämän ongelman? Ratkaisimme sen alkuperäisellä tavalla - tallentamalla jokaiseen käänteiseen indeksimerkintään useita aikasarjatunnisteita yhden tunnisteen sijaan. Eli meillä on avain label=value, joka esiintyy jokaisessa aikasarjassa. Ja nyt säästämme useita timeseries_ids yhdessä merkinnässä.
Tässä on esimerkki. Aiemmin meillä oli N merkintää, mutta nyt meillä on yksi merkintä, jonka etuliite on sama kuin kaikilla muilla. Edellisen merkinnän arvo sisältää kaikki aikasarjan tunnukset.
Tämä mahdollisti tällaisen käänteisen indeksin skannausnopeuden lisäämisen jopa 10 kertaa. Ja sen avulla pystyimme vähentämään välimuistin muistin kulutusta, koska nyt tallennamme merkkijonon label=value vain kerran välimuistissa yhdessä N kertaa. Ja tämä rivi voi olla suuri, jos tallennat tunnisteihisi ja tarroihisi pitkiä rivejä, joita Kubernetes haluaa työntää sinne.
Toinen vaihtoehto käänteisen hakemiston hakua nopeuttaa on sharding. Useiden käänteisten indeksien luominen yhden sijasta ja tietojen jakaminen niiden välillä avaimella. Tämä on setti key=value höyryä. Eli saamme useita itsenäisiä käänteisiä indeksejä, joita voimme kysyä rinnakkain useilla prosessoreilla. Aiemmat toteutukset sallivat toiminnan vain yhden prosessorin tilassa, eli vain yhden ytimen tietojen skannauksen. Tämän ratkaisun avulla voit skannata tietoja useista ytimistä kerralla, kuten ClickHouse haluaa tehdä. Tämän aiomme toteuttaa.
Palataan nyt lampaihimme - risteystoimintoon timeseries_ids. Mietitään, millaisia toteutuksia voi olla. Tämän toiminnon avulla voit etsiä timeseries_ids tietylle sarjalle label=value.
Ensimmäinen vaihtoehto on naiivi toteutus. Kaksi sisäkkäistä silmukkaa. Täältä saamme funktion syötteen intersectInts kaksi viipaletta - a и b. Lähdössä sen pitäisi palauttaa meille näiden siivujen leikkauspiste.
Naiivi toteutus näyttää tältä. Toistamme kaikki slice-arvot a, tämän silmukan sisällä käymme läpi kaikki viipaleen arvot b. Ja vertaamme niitä. Jos ne täsmäävät, olemme löytäneet risteyksen. Ja tallenna se sisään result.
Mitkä ovat haitat? Kvadraattinen monimutkaisuus on sen suurin haittapuoli. Jos mittasi ovat esimerkiksi slice a и b miljoona kerrallaan, tämä toiminto ei koskaan palauta sinulle vastausta. Koska se tarvitsee biljoona iteraatiota, mikä on paljon jopa nykyaikaisille tietokoneille.
Toinen toteutus perustuu karttaan. Luomme karttaa. Laitamme kaikki slice-arvot tähän karttaan a. Sitten käymme siivujen läpi erillisessä silmukassa b. Ja tarkistamme, onko tämä arvo sliceistä b kartalla. Jos se on olemassa, lisää se tulokseen.
Mitä hyötyä siitä on? Etuna on vain lineaarinen monimutkaisuus. Toisin sanoen toiminto suoritetaan paljon nopeammin suuremmilla siivuilla. Miljoonan koon kohdalla tämä toiminto suoritetaan 2 miljoonassa iteraatiossa, toisin kuin edellisen funktion biljoona iteraatiota.
Huono puoli on, että tämä toiminto vaatii enemmän muistia tämän kartan luomiseen.
Toinen haittapuoli on suuret hajautuskustannukset. Tämä haittapuoli ei ole kovin ilmeinen. Ja meille se ei myöskään ollut kovin ilmeistä, joten VictoriaMetricsissä risteyksen toteutus tapahtui aluksi kartan kautta. Mutta sitten profilointi osoitti, että pääprosessorin aika kuluu karttaan kirjoittamiseen ja arvon tarkistamiseen tässä kartassa.
Miksi CPU-aikaa tuhlataan näissä paikoissa? Koska Go suorittaa hajautustoiminnon näille riveille. Toisin sanoen se laskee avaimen tiivisteen päästäkseen siihen sitten HashMapin annetussa indeksissä. Hajautuslaskenta suoritetaan kymmenissä nanosekunnissa. Tämä on hidasta VictoriaMetricsille.
Päätin ottaa käyttöön bittijoukon, joka on optimoitu erityisesti tätä tapausta varten. Tältä kahden viipaleen leikkauspiste näyttää nyt. Tässä luomme bittijoukon. Lisäämme siihen elementtejä ensimmäisestä viipaleesta. Sitten tarkistamme näiden elementtien läsnäolon toisessa siivussa. Ja lisää ne tulokseen. Eli se ei juuri eroa edellisestä esimerkistä. Ainoa asia tässä on, että korvasimme pääsyn karttaan mukautetuilla toiminnoilla add и has.
Ensi silmäyksellä näyttää siltä, että tämän pitäisi toimia hitaammin, jos siellä on aiemmin käytetty standardikarttaa ja sitten kutsutaan joitain muita toimintoja, mutta profilointi osoittaa, että tämä asia toimii 10 kertaa nopeammin kuin vakiokartta VictoriaMetricsin tapauksessa.
Lisäksi se käyttää paljon vähemmän muistia karttatoteutukseen verrattuna. Koska tallennamme tähän bittejä kahdeksantavuisten arvojen sijaan.
Tämän toteutuksen haittana on, että se ei ole niin ilmeinen, ei triviaali.
Toinen haittapuoli, jota monet eivät ehkä huomaa, on, että tämä toteutus ei välttämättä toimi hyvin joissakin tapauksissa. Toisin sanoen se on optimoitu tiettyä tapausta varten, tässä VictoriaMetricsin aikasarjatunnusten leikkaustapauksessa. Tämä ei tarkoita, että se sopisi kaikkiin tapauksiin. Jos sitä käytetään väärin, emme saa suorituskyvyn kasvua, vaan muistin loppumisesta ja suorituskyvyn hidastumisesta.
Tarkastellaanpa tämän rakenteen toteutusta. Jos haluat katsoa, se sijaitsee VictoriaMetrics-lähteissä kansiossa . Se on optimoitu erityisesti VictoriaMetrics-koteloon, jossa timeseries_id on 64-bittinen arvo, jossa ensimmäiset 32 bittiä ovat periaatteessa vakioita ja vain viimeiset 32 bittiä muuttuvat.
Tätä tietorakennetta ei tallenneta levylle, se toimii vain muistissa.
Tässä on sen API. Se ei ole kovin monimutkaista. API on räätälöity erityisesti tiettyyn VictoriaMetricsin käyttöesimerkkiin. Eli tässä ei ole tarpeettomia toimintoja. Tässä ovat funktiot, joita VictoriaMetrics nimenomaan käyttää.
Toimintoja on add, joka lisää uusia arvoja. Siinä on toiminto has, joka tarkistaa uudet arvot. Ja siinä on toiminto del, joka poistaa arvot. Siellä on aputoiminto len, joka palauttaa sarjan koon. Toiminto clone kloonaa paljon. Ja toimivuus appendto muuntaa tämän joukon viipaleeksi timeseries_ids.
Tältä tämän tietorakenteen toteutus näyttää. sarjassa on kaksi elementtiä:
-
ItemsCounton apukenttä, joka palauttaa nopeasti joukon elementtien määrän. Ilmankin tätä apukenttää olisi mahdollista tehdä, mutta se piti lisätä tähän, koska VictoriaMetrics kyselee usein bitsetin pituutta algoritmeissaan. -
Toinen kenttä on
buckets. Tämä on siivu rakenteestabucket32. Jokainen rakenne varastoihiala. Nämä ovat ylempiä 32 bittiä. Ja kaksi siivua -b16hisиbucketsjabucket16rakenteet.
16-bittisen rakenteen toisen osan 64 ylintä bittiä on tallennettu tähän. Ja tässä bittijoukot tallennetaan kunkin tavun alemmille 16 bitille.
Bucket64 koostuu taulukosta uint64. Pituus lasketaan näiden vakioiden avulla. Yhdessä bucket16 enintään voidaan tallentaa 2^16=65536 bitti. Jos jaat tämän kahdeksalla, se on 8 kilotavua. Jos jaat uudelleen kahdeksalla, se on 8 uint64 merkitys. Tuo on Bucket16 – Tämä on 8 kilotavun rakenteemme.
Katsotaanpa, kuinka yksi tämän rakenteen menetelmistä uuden arvon lisäämiseksi on toteutettu.
Kaikki alkaa siitä uint64 merkityksiä. Laskemme ylemmät 32 bittiä, laskemme alemmat 32 bittiä. Käydään kaikki läpi buckets. Vertaamme kunkin segmentin 32 parasta bittiä lisättävään arvoon. Ja jos ne täsmäävät, kutsumme funktiota add rakenteessa b32 buckets. Ja lisää alemmat 32 bittiä sinne. Ja jos palaisi true, tämä tarkoittaa, että lisäsimme tällaisen arvon, mutta meillä ei ollut sellaista arvoa. Jos se palaa false, silloin sellainen merkitys oli jo olemassa. Sitten lisäämme elementtien määrää rakenteessa.
Jos emme ole löytäneet tarvitsemaasi bucket vaaditulla hi-arvolla, kutsumme funktiota addAlloc, joka tuottaa uuden bucket, lisäämällä sen kauhan rakenteeseen.
Tämä on toiminnon toteutus b32.add. Se on samanlainen kuin edellinen toteutus. Laskemme merkittävimmät 16 bittiä, vähiten merkitsevät 16 bittiä.
Sitten käymme läpi kaikki ylemmät 16 bittiä. Löydämme otteluita. Ja jos osuma löytyy, kutsumme lisäysmenetelmää, jota tarkastelemme seuraavalla sivulla bucket16.
Ja tässä on alin taso, joka tulisi optimoida niin paljon kuin mahdollista. Me laskemme uint64 id-arvo slice-bitissä ja myös bitmask. Tämä on maski tietylle 64-bittiselle arvolle, jonka avulla voidaan tarkistaa tämän bitin olemassaolo tai asettaa se. Tarkistamme, onko tämä bitti asetettu, asetamme sen ja palautamme läsnäolon. Tämä on toteutuksemme, jonka avulla pystyimme nopeuttamaan aikasarjojen leikkaavien tunnusten toimintaa 10 kertaa perinteisiin karttoihin verrattuna.
Tämän optimoinnin lisäksi VictoriaMetricsillä on monia muita optimointeja. Suurin osa näistä optimoinneista lisättiin syystä, mutta koodin profiloinnin jälkeen tuotannossa.
Tämä on optimoinnin pääsääntö - älä lisää optimointia olettaen, että tässä on pullonkaula, koska voi käydä ilmi, että siellä ei ole pullonkaulaa. Optimointi yleensä huonontaa koodin laatua. Siksi optimointi kannattaa vasta profiloinnin jälkeen ja mieluiten tuotannossa, jotta tämä on todellista dataa. Jos joku on kiinnostunut, voit katsoa VictoriaMetrics-lähdekoodia ja tutkia muita siellä olevia optimointeja.
Minulla on kysymys bitsetistä. Hyvin samanlainen kuin C++-vektorin bool-toteutus, optimoitu bittijoukko. Otitko toteutuksen sieltä?
Ei, ei sieltä. Tätä bittijoukkoa toteutettaessa minua ohjasi tietämys näiden VictoriaMetricsissä käytettyjen ids-aikasarjojen rakenteesta. Ja niiden rakenne on sellainen, että ylemmät 32 bittiä ovat periaatteessa vakioita. Alempi 32 bittiä voidaan muuttaa. Mitä pienempi bitti, sitä useammin se voi muuttua. Siksi tämä toteutus on erityisesti optimoitu tätä tietorakennetta varten. C++-toteutus on tietääkseni optimoitu yleistä tapausta varten. Jos optimoit yleistä tapausta varten, tämä tarkoittaa, että se ei ole optimaalinen tietylle tapaukselle.
Suosittelen myös katsomaan Aleksei Milovidin raportin. Noin kuukausi sitten hän puhui ClickHousen optimoinnista tiettyjä erikoisaloja varten. Hän vain sanoo, että yleensä C++-toteutus tai jokin muu toteutus on räätälöity toimimaan keskimäärin hyvin sairaalassa. Se voi toimia huonommin kuin meidän kaltainen tietokohtainen toteutus, jossa tiedämme, että 32 parasta bittiä ovat enimmäkseen vakioita.
Minulla on toinen kysymys. Mikä on perustavanlaatuinen ero InfluxDB:hen?
Perusteellisia eroja on monia. Suorituskyvyn ja muistinkulutuksen suhteen InfluxDB näyttää testeissä 10 kertaa enemmän muistin kulutusta korkean kardinaalisuuden aikasarjoille, kun niitä on paljon, esimerkiksi miljoonia. Esimerkiksi VictoriaMetrics kuluttaa 1 Gt miljoonaa aktiivista riviä kohden, kun taas InfluxDB 10 Gt. Ja se on iso ero.
Toinen perustavanlaatuinen ero on, että InfluxDB:llä on outoja kyselykieliä - Flux ja InfluxQL. Ne eivät ole kovin käteviä aikasarjojen kanssa työskentelyyn verrattuna , jota VictoriaMetrics tukee. PromQL on Prometheuksen kyselykieli.
Ja vielä yksi ero on se, että InfluxDB:llä on hieman outo tietomalli, jossa jokaiselle riville voidaan tallentaa useita kenttiä eri tageilla. Nämä rivit on edelleen jaettu erilaisiin taulukoihin. Nämä lisäongelmat vaikeuttavat myöhempää työtä tämän tietokannan kanssa. Sitä on vaikea tukea ja ymmärtää.
VictoriaMetricsissä kaikki on paljon yksinkertaisempaa. Siellä jokainen aikasarja on avainarvo. Arvo on joukko pisteitä - (timestamp, value), ja avain on sarja label=value. Kenttien ja mittausten välillä ei ole eroa. Sen avulla voit valita mitä tahansa dataa ja sitten yhdistää, lisätä, vähentää, kertoa, jakaa, toisin kuin InfluxDB, jossa eri rivien välisiä laskelmia ei tietääkseni vieläkään toteuteta. Vaikka ne toteutetaan, se on vaikeaa, sinun on kirjoitettava paljon koodia.
Minulla on selventävä kysymys. Ymmärsinkö oikein, että kyseessä oli jonkinlainen ongelma, josta puhuit, että tämä käänteinen indeksi ei mahdu muistiin, joten siellä on osiointi?
Ensin näytin käänteisen indeksin naiivin toteutuksen tavallisella Go-kartalla. Tämä toteutus ei sovellu tietokantoihin, koska tätä käänteistä hakemistoa ei tallenneta levylle, ja tietokannan on tallennettava levylle, jotta nämä tiedot ovat käytettävissä uudelleenkäynnistyksen yhteydessä. Tässä toteutuksessa, kun käynnistät sovelluksen uudelleen, käänteinen indeksi katoaa. Ja menetät pääsyn kaikkiin tietoihin, koska et löydä niitä.
Hei! Kiitos raportista! Nimeni on Pavel. Olen kotoisin Wildberrystä. Minulla on sinulle muutama kysymys. Kysymys yksi. Luuletko, että jos olisit valinnut toisen periaatteen sovelluksesi arkkitehtuuria rakentaessasi ja osioittanut tiedot ajan myötä, olisit ehkä voinut leikata dataa etsiessäsi vain sen perusteella, että yksi osio sisältää tietoja yhdelle aikajaksolla, eli yhdessä aikavälissä, eikä sinun tarvitsisi huolehtia siitä, että kappaleesi ovat hajallaan eri tavalla? Kysymys numero 2 - koska olet toteuttamassa samanlaista algoritmia bitsetillä ja kaikella muulla, niin ehkä kokeilit käyttää prosessorin ohjeita? Ehkä olet kokeillut tällaisia optimointeja?
Vastaan heti toiseen. Emme ole vielä päässeet siihen pisteeseen. Mutta tarvittaessa päästään perille. Ja ensimmäinen, mikä oli kysymys?
Keskustelitte kahdesta skenaariosta. Ja he sanoivat, että he valitsivat toisen monimutkaisemmalla toteutuksella. Eivätkä he suosineet ensimmäistä, jossa tiedot on jaettu ajan mukaan.
Joo. Ensimmäisessä tapauksessa indeksin kokonaismäärä olisi suurempi, koska jokaiseen osioon meidän olisi tallennettava päällekkäisiä tietoja niille aikasarjoille, jotka jatkuvat kaikkien näiden osioiden läpi. Ja jos aikasarjasi vaihtuvuusaste on pieni, eli samoja sarjoja käytetään jatkuvasti, niin ensimmäisessä tapauksessa menetämme paljon enemmän varatun levytilan määrään verrattuna toiseen tapaukseen.
Ja niin - kyllä, aikaosio on hyvä vaihtoehto. Prometheus käyttää sitä. Mutta Prometheuksella on toinenkin haittapuoli. Kun näitä tietoja yhdistetään, sen on säilytettävä muistissa metatiedot kaikista tarroista ja aikasarjoista. Siksi, jos sen yhdistämät tiedot ovat suuria, muistin kulutus kasvaa erittäin paljon yhdistämisen aikana, toisin kuin VictoriaMetrics. Yhdistettäessä VictoriaMetrics ei kuluta muistia ollenkaan, vain pari kilotavua, riippumatta yhdistettyjen tietopalojen koosta.
Käyttämäsi algoritmi käyttää muistia. Se merkitsee arvoja sisältävät aikasarjatunnisteet. Ja tällä tavalla voit tarkistaa parillisen läsnäolon yhdessä datataulukossa ja toisessa. Ja ymmärrät, tapahtuiko leikkaus vai ei. Tyypillisesti tietokannat toteuttavat kohdistimia ja iteraattoreita, jotka tallentavat nykyisen sisällön ja käyvät läpi lajitellut tiedot näiden toimintojen yksinkertaisen monimutkaisuuden vuoksi.
Miksi emme käytä kohdistimia tietojen läpikulkuun?
Kyllä.
Tallennamme lajitellut rivit LevelDB:hen tai yhdistämissarjaan. Voimme siirtää kohdistinta ja löytää risteyksen. Miksi emme käytä sitä? Koska se on hidasta. Koska kursorit tarkoittavat, että sinun on kutsuttava funktio jokaiselle riville. Funktiokutsu on 5 nanosekuntia. Ja jos sinulla on 100 000 000 riviä, käy ilmi, että käytämme puoli sekuntia vain funktion kutsumiseen.
Sellainen on olemassa, kyllä. Ja viimeinen kysymykseni. Kysymys saattaa kuulostaa hieman oudolta. Miksi kaikkia tarvittavia aggregaatteja ei voida lukea tiedon saapuessa ja tallentaa niitä vaaditussa muodossa? Miksi säästää valtavia määriä joissakin järjestelmissä, kuten VictoriaMetrics, ClickHouse jne., ja käyttää sitten paljon aikaa niihin?
Annan esimerkin selventääkseni asiaa. Sanotaanpa kuinka pieni lelunopeusmittari toimii? Se tallentaa kuljetun matkan lisäämällä sen koko ajan yhteen arvoon ja toisen ajan. Ja jakaa. Ja saa keskinopeuden. Voit tehdä suunnilleen saman asian. Lisää kaikki tarvittavat tosiasiat lennossa.
Okei, ymmärrän kysymyksen. Esimerkilläsi on paikkansa. Jos tiedät, mitä aggregaatteja tarvitset, tämä on paras toteutus. Mutta ongelmana on, että ihmiset tallentavat nämä mittarit, joitain tietoja ClickHousessa, eivätkä he vielä tiedä, kuinka he kokoavat ja suodattavat ne tulevaisuudessa, joten heidän on tallennettava kaikki raakadata. Mutta jos tiedät, että sinun on laskettava jotain keskimäärin, niin miksi et laske sitä sen sijaan, että tallennat sinne joukon raaka-arvoja? Mutta tämä on vain, jos tiedät tarkalleen mitä tarvitset.
Muuten, aikasarjojen tallentamiseen tarkoitetut tietokannat tukevat aggregaattien laskemista. Esimerkiksi Prometheus tukee . Eli tämä voidaan tehdä, jos tiedät, mitä yksiköitä tarvitset. VictoriaMetricsillä ei tätä vielä ole, mutta sitä edeltää yleensä Prometheus, jossa tämä voidaan tehdä uudelleenkoodaussäännöissä.
Esimerkiksi edellisessä työssäni piti laskea tapahtumien määrä liukuvassa ikkunassa viimeisen tunnin aikana. Ongelmana on, että minun piti tehdä mukautettu toteutus Go:ssa, eli palvelu tämän asian laskemiseen. Tämä palvelu oli lopulta ei-triviaali, koska sitä on vaikea laskea. Toteutus voi olla yksinkertaista, jos joudut laskemaan joitain aggregaatteja tietyin aikavälein. Jos haluat laskea tapahtumia liukuvassa ikkunassa, se ei ole niin yksinkertaista kuin miltä näyttää. Mielestäni tätä ei ole vielä toteutettu ClickHousessa tai aikasarjatietokantoissa, koska se on vaikea toteuttaa.
Ja vielä yksi kysymys. Puhuimme vain keskiarvon laskemisesta, ja muistin, että kerran oli sellainen asia kuin Graphite with Carbon-taustajärjestelmä. Ja hän osasi ohentaa vanhaa dataa eli jättää yhden pisteen minuutissa, pisteen per tunti jne. Periaatteessa tämä on varsin kätevää, jos tarvitsemme raakadataa suhteellisesti kuukaudeksi, ja kaikki muu voi olla ohentunut. Mutta Prometheus ja VictoriaMetrics eivät tue tätä toimintoa. Onko sitä tarkoitus tukea? Jos ei, miksi ei?
Kiitos kysymyksestä. Käyttäjämme kysyvät tämän kysymyksen ajoittain. He kysyvät, milloin lisäämme tuen alasnäytteenottoon. Tässä on useita ongelmia. Ensinnäkin jokainen käyttäjä ymmärtää downsampling jotain erilaista: joku haluaa saada minkä tahansa mielivaltaisen pisteen tietyltä aikaväliltä, joku haluaa maksimi-, minimi- ja keskiarvot. Jos monet järjestelmät kirjoittavat tietoja tietokantaan, et voi niputtaa kaikkea yhteen. Saattaa olla, että jokainen järjestelmä vaatii erilaista ohennusta. Ja tämä on vaikea toteuttaa.
Ja toinen asia on, että VictoriaMetrics, kuten ClickHouse, on optimoitu käsittelemään suuria määriä raakadataa, joten se voi lapioida miljardi riviä alle sekunnissa, jos järjestelmässäsi on useita ytimiä. Aikasarjapisteiden skannaus VictoriaMetricsissä – 50 000 000 pistettä sekunnissa ydintä kohden. Ja tämä suorituskyky skaalautuu olemassa oleviin ytimiin. Eli jos sinulla on esimerkiksi 20 ydintä, skannaat miljardi pistettä sekunnissa. Ja tämä VictoriaMetricsin ja ClickHousen ominaisuus vähentää alasnäytteenoton tarvetta.
Toinen ominaisuus on, että VictoriaMetrics pakkaa nämä tiedot tehokkaasti. Keskimääräinen pakkaus on tuotannossa 0,4 - 0,8 tavua pistettä kohti. Jokainen piste on aikaleima + arvo. Ja se on pakattu keskimäärin alle yhteen tavuun.
Sergei. Minulla on kysymys. Mikä on minimitallennusajan kvantti?
Yksi millisekunti. Kävimme äskettäin keskustelun muiden aikasarjatietokantakehittäjien kanssa. Niiden minimiaika on yksi sekunti. Ja esimerkiksi grafiitissa se on myös yksi sekunti. OpenTSDB:ssä se on myös yksi sekunti. InfluxDB:n tarkkuus on nanosekuntia. VictoriaMetricsissä se on yksi millisekunti, koska Prometheuksessa se on yksi millisekunti. VictoriaMetrics kehitettiin alun perin Prometheuksen etätallennustilaksi. Mutta nyt se voi tallentaa tietoja muista järjestelmistä.
Henkilö, jonka kanssa puhuin, sanoo, että heillä on sekunnista sekuntiin tarkkuus - se riittää heille, koska se riippuu aikasarjatietokantaan tallennettujen tietojen tyypistä. Jos tämä on DevOps-dataa tai dataa infrastruktuurista, jossa keräät niitä 30 sekunnin välein, minuutissa, niin sekunnin tarkkuus riittää, et tarvitse mitään vähempää. Ja jos keräät nämä tiedot korkeataajuisista kaupankäyntijärjestelmistä, tarvitset nanosekunnin tarkkuuden.
VictoriaMetricsin millisekunnin tarkkuus sopii myös DevOps-tapaukseen ja voi sopia useimpiin raportin alussa mainitsemiini tapauksiin. Ainoa asia, johon se ei ehkä sovellu, ovat korkean taajuuden kaupankäyntijärjestelmät.
Kiitos! Ja toinen kysymys. Mikä on PromQL:n yhteensopivuus?
Täysi yhteensopivuus taaksepäin. VictoriaMetrics tukee täysin PromQL:ää. Lisäksi se lisää lisätoimintoja PromQL:iin, jota kutsutaan . YouTubessa puhutaan tästä laajennetusta toiminnallisuudesta. Puhuin Monitoring Meetupissa keväällä Pietarissa.
Telegramkanava .
Vain rekisteröityneet käyttäjät voivat osallistua kyselyyn. , ole kiltti.
Mikä estää sinua vaihtamasta VictoriaMetricsiin Prometheuksen pitkäaikaiseen varastointiin? (Kirjoita kommentteihin, lisään sen kyselyyn))
-
71,4%En käytä Prometheus5:tä
-
28,6%En tiennyt VictoriaMetrics2:sta
7 käyttäjää äänesti. 12 käyttäjää pidättyi äänestämästä.
Lähde: will.com