{"id":80733,"date":"2020-05-08T13:42:31","date_gmt":"2020-05-08T11:42:31","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/go-optimizations-in-victoriametrics-aleksandr-valyalkin"},"modified":"2020-05-08T13:42:31","modified_gmt":"2020-05-08T11:42:31","slug":"go-optimizations-in-victoriametrics-aleksandr-valyalkin","status":"publish","type":"post","link":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/go-optimizations-in-victoriametrics-aleksandr-valyalkin","title":{"rendered":"Go optimeerimised VictoriaMetricsis. Aleksandr Valjalkin","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><strong>\u041f\u0440\u0435\u0434\u043b\u0430\u0433\u0430\u044e \u043e\u0437\u043d\u0430\u043a\u043e\u043c\u0438\u0442\u044c\u0441\u044f \u0441 \u0440\u0430\u0441\u0448\u0438\u0444\u0440\u043e\u0432\u043a\u043e\u0439 \u0434\u043e\u043a\u043b\u0430\u0434\u0430 \u043a\u043e\u043d\u0446\u0430 2019 \u0433\u043e\u0434\u0430 \u0410\u043b\u0435\u043a\u0441\u0430\u043d\u0434\u0440\u0430 \u0412\u0430\u043b\u044f\u043b\u043a\u0438\u043d\u0430 &quot;Go optimizations in VictoriaMetrics&quot;<\/strong><\/p>\n<p><\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/victoriametrics.com\/\">VictoriaMetrics<\/a><\/noindex> \u2014 kiire ja skaleeritav andmebaas ajaseeriaandmete salvestamiseks ja t\u00f6\u00f6tlemiseks (salvestus loob aja ja vastava ajaga seotud v\u00e4\u00e4rtuste kogumi, n\u00e4iteks sensorite oleku perioodilise k\u00fcsitluse v\u00f5i statistikate kogumise kaudu saadud v\u00e4\u00e4rtused).<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Go optimeerimised VictoriaMetricsis. Aleksandr Valjalkin\" src=\"\/wp-content\/uploads\/2020\/05\/dd13ec10594aeb138be29ce439cc476a.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>Siin on link selle dokumendi video juurde \u2014 <noindex><a rel=\"nofollow\" href=\"https:\/\/youtu.be\/MZ5P21j_HLE\">https:\/\/youtu.be\/MZ5P21j_HLE<\/a><\/noindex><\/p>\n<p><\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/docs.google.com\/presentation\/d\/1k7OjHvxTHA7669MFwsNTCx8hII-a8lNvpmQetLxmrEU\/edit?usp=sharing\">Esitlused<\/a><\/noindex><\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Go optimeerimised VictoriaMetricsis. Aleksandr Valjalkin\" src=\"\/wp-content\/uploads\/2020\/05\/0073390d6dbcc6ab3e5305907ac6a229.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>R\u00e4\u00e4gin natuke endast. Mina olen Aleksandr Valjalkin. Siin on <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/valyala\">minu GitHubi konto<\/a><\/noindex>. Mulle meeldib Go ja j\u00f5udluse optimeerimine. Olen kirjutanud palju erinevaid kasulikke ja v\u00e4hem kasulikke teeke. Need algavad kas <code>kiire<\/code>, or with <code>v\u00e4ga kiire<\/code> eelvormiga. <\/p>\n<p><\/p>\n<p>Hetkel t\u00f6\u00f6tan VictoriaMetricsi kallal. Mis see on ja mida ma seal teen? Sellest r\u00e4\u00e4gin oma esitlusel. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Go optimeerimised VictoriaMetricsis. Aleksandr Valjalkin\" src=\"\/wp-content\/uploads\/2020\/05\/c9194bc3fee1f615d838979bec12f7d0.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Dokumendi plaan on j\u00e4rgmine:<\/p>\n<p><\/p>\n<ul>\n<li>Esmalt r\u00e4\u00e4gin teile, mis on VictoriaMetrics. <\/li>\n<li>Siis r\u00e4\u00e4gin, mis on ajaseeriate andmed. <\/li>\n<li>Seej\u00e4rel r\u00e4\u00e4gin, kuidas ajaseeria andmebaas t\u00f6\u00f6tab.<\/li>\n<li>J\u00e4rgmisena r\u00e4\u00e4gin andmebaasi arhitektuurist: millest see koosneb.<\/li>\n<li>Ja l\u00f5puks r\u00e4\u00e4gin VictoriaMetricsi optimeerimisest. Need on optimeerimine p\u00f6\u00f6rdindeksile ja bitseti rakenduse optimeerimine Go-s.<\/li>\n<\/ul>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Go optimeerimised VictoriaMetricsis. Aleksandr Valjalkin\" src=\"\/wp-content\/uploads\/2020\/05\/3e0244b6b6fe952f660e4a094778921a.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Mis on VictoriaMetrics? Kas keegi publikust teab? Vau, juba palju inimesi teab. See on hea uudis. Neile, kes ei tea - see on ajas\u00fcsteemide andmebaas. See p\u00f5hineb ClickHouse arhitektuuril ja m\u00f5ningatel ClickHouse'i rakenduse detailidel. N\u00e4iteks sellistel nagu: MergeTree, paralleelse t\u00f6\u00f6tlemise kasutamine k\u00f5igil saadaval olevatel protsessorituumadel ja j\u00f5udluse optimeerimine andmeplokkide t\u00f6\u00f6tlemise kaudu, mis salvestatakse protsessori vahem\u00e4lu. <\/p>\n<p><\/p>\n<p>VictoriaMetrics pakub andmete parimat tihendust v\u00f5rreldes teiste ajas\u00fcsteemide andmebaasidega. <\/p>\n<p><\/p>\n<p>See skaleerub vertikaalselt - st saate lisada rohkem protsessoreid, rohkem m\u00e4lu \u00fchte arvutisse. VictoriaMetrics suudab neid ressursse t\u00f5husalt kasutada ja parandada lineaarselt j\u00f5udlust.<\/p>\n<p><\/p>\n<p>Samuti skaleerub VictoriaMetrics horitontaalselt - st saate lisada VictoriaMetricsi klastrisse t\u00e4iendavaid s\u00f5lmi ja selle j\u00f5udlus kasvab peaaegu lineaarselt.<\/p>\n<p><\/p>\n<p>Kuidas te arvate, VictoriaMetrics on kiire andmebaas, sest ma ei saa r\u00e4\u00e4kida teistest. Ja see on kirjutatud Go keeles, seet\u00f5ttu r\u00e4\u00e4gin sellest kohtumisel.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Go optimeerimised VictoriaMetricsis. Aleksandr Valjalkin\" src=\"\/wp-content\/uploads\/2020\/05\/0121c9baead722eb1fe22fb6f900d4ad.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Kes teab, mis on ajavarras? Paljud inimesed teavad. Ajavarras on paaride seeria <code>(timestamp, v\u00e4\u00e4rtus)<\/code>, kus need paarid on j\u00e4rjestatud aja j\u00e4rgi. V\u00e4\u00e4rtus esindab end floating-point numbrit \u2013 float64.<\/p>\n<p><\/p>\n<p>Iga ajavarras identifitseeritakse ainulaadse v\u00f5tmega. Mis sellest v\u00f5tmetest koosneb? See koosneb mitte-t\u00fchjast paaride komplektist v\u00f5tme-v\u00e4\u00e4rtuse. <\/p>\n<p><\/p>\n<p>Siin on ajavarra n\u00e4ide. Selle varda v\u00f5ti on paaride nimekiri: <code>__name__=&quot;cpu_usage&quot;<\/code> \u2013 see on m\u00f5\u00f5tme nimi, <code>instance=&quot;my-server&quot;<\/code> \u2014 see on arvuti, kus see m\u00f5\u00f5tmine on kogutud, <code>datacenter=&quot;us-east&quot;<\/code> \u2014 see on andmekeskus, kus see arvuti asub.<\/p>\n<p><\/p>\n<p>Saime ajavarra nime, mis koosneb kolmest v\u00f5tme-v\u00e4\u00e4rtuse paarist. Selle v\u00f5tme juurde kuulub paaride nimekiri <code>(timestamp, value)<\/code>. <code>t1, t3, t3, ..., tN<\/code> \u2014 need on ajatemperatuurid, <code>10, 20, 12, ..., 15<\/code> \u2014 vastavad v\u00e4\u00e4rtused. See on cpu kasutus praeguses ajahetkes selle vara jaoks.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Go optimeerimised VictoriaMetricsis. Aleksandr Valjalkin\" src=\"\/wp-content\/uploads\/2020\/05\/76cab9db0263318d355ac607ceb7e0f6.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Kus ajavarrasid saab kasutada? Kas kellegil on ideid? <\/p>\n<p><\/p>\n<ul>\n<li>DevOps'is saab m\u00f5\u00f5ta CPU, RAM, v\u00f5rgu, rps, vigade arvu jne koormust. <\/li>\n<li>IoT \u2013 saame m\u00f5\u00f5ta temperatuuri, r\u00f5hku, geo koorde ja muid n\u00e4itajaid.<\/li>\n<li>Samuti finantssektor \u2013 saame j\u00e4lgida aktsiate ja valuutade hindu. <\/li>\n<li>Lisaks sellele saab ajasirne j\u00e4lgimiseks kasutada tootmisprotsesside j\u00e4lgimiseks tehastes. Meil on kasutajaid, kes kasutavad VictoriaMetrics tuulegeneraatoreid j\u00e4lgimiseks, ka robotite j\u00e4lgimiseks.<\/li>\n<li>Ajandirad on samuti kasulikud teabe kogumiseks erinevatelt seadmete sensoritelt. N\u00e4iteks mootorile; rehvir\u00f5hu m\u00f5\u00f5tmiseks; kiirus, kaugus; k\u00fctusekulu m\u00f5\u00f5tmiseks jne.<\/li>\n<li>Ajandirad v\u00f5ivad sama moodi olla kasutusel lennukite j\u00e4lgimiseks. Igas lennukis on must kast, mis kogub ajandiread erinevate lennuki tervise parameetrite kohta. Ajandirad on samuti kasutusel kosmoset\u00f6\u00f6stuses. <\/li>\n<li>Tervishoid \u2013 see h\u00f5lmab verer\u00f5hku, pulssi jne.<\/li>\n<\/ul>\n<p><\/p>\n<p>V\u00f5ib-olla on veel rakendusi, millele ma ei ole m\u00f5elnud, kuid loodan, et te m\u00f5istate, et ajandirad on kaasaegses maailmas aktiivselt kasutusel. Ja nende kasutuse ulatus kasvab igal aastal.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Go optimeerimised VictoriaMetricsis. Aleksandr Valjalkin\" src=\"\/wp-content\/uploads\/2020\/05\/f1da29d372163751268b6a8f86836d04.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Miks on ajareadade andmebaas vajalik? Miks ei saa tavap\u00e4rast relatsioonilist andmebaasi ajareadade salvestamiseks kasutada?<\/p>\n<p><\/p>\n<p>Sest ajareadades on tavaliselt suur andmemaht, mida on keeruline tavap\u00e4rastes andmebaasides salvestada ja t\u00f6\u00f6delda. Seet\u00f5ttu on tekkinud spetsialiseeritud andmebaasid ajareadade jaoks. Need andmebaasid salvestavad t\u00f5husalt punkte <code>(timestamp, value)<\/code> m\u00e4\u00e4ratud v\u00f5tme j\u00e4rgi. Need pakuvad API-d salvestatud andmete lugemiseks v\u00f5tme j\u00e4rgi, kas \u00fche v\u00f5tme-v\u00e4\u00e4rtuse paari p\u00f5hjal, mitme paari p\u00f5hjal v\u00f5i regexp j\u00e4rgi. N\u00e4iteks, kui soovite leida k\u00f5igi oma teenuste protsessori koormust Ameerika andmekeskuses, tuleks kasutada j\u00e4rgmist pseudok\u00fcsimust.<\/p>\n<p><\/p>\n<p>Tavaliselt esindavad ajareadade andmebaasid spetsialiseeritud p\u00e4ringute keeli, kuna SQL ei sobi ajareadade jaoks eriti h\u00e4sti. Kuigi on ka andmebaase, mis toetavad SQL-i, ei ole see eriti sobiv. Paremini sobivad sellised p\u00e4ringute keeled nagu <noindex><a rel=\"nofollow\" href=\"https:\/\/medium.com\/@valyala\/promql-tutorial-for-beginners-9ab455142085\">PromQL<\/a><\/noindex>, <noindex><a rel=\"nofollow\" href=\"https:\/\/docs.influxdata.com\/influxdb\/v1.8\/query_language\/spec\/\">InfluxQL<\/a><\/noindex>, <noindex><a rel=\"nofollow\" href=\"https:\/\/www.influxdata.com\/products\/flux\/\">Flux<\/a><\/noindex>, <noindex><a rel=\"nofollow\" href=\"https:\/\/code.kx.com\/q\/\">K<\/a><\/noindex>. Loodan, et keegi on v\u00e4hemalt \u00fche neist keeltest kuulnud. PromQL-i on ilmselt paljud kuulnud. See on Prometheuse p\u00e4ringute keel.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Go optimeerimised VictoriaMetricsis. Aleksandr Valjalkin\" src=\"\/wp-content\/uploads\/2020\/05\/59e5b6d82a2f7861077bc5fe34519ee4.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Nii n\u00e4eb v\u00e4lja kaasaegse ajajoonedatabaasi arhitektuur VictoriaMetrics n\u00e4itel.<\/p>\n<p><\/p>\n<p>See koosneb kahest osast. \u00dcks on p\u00f6\u00f6ratud indeks ja teine ajajoonde v\u00e4\u00e4rtuste hoidmine. Need hoidlade on eraldatud. <\/p>\n<p><\/p>\n<p>Kui uus kirje tuleb andmebaasi, p\u00f6\u00f6rdume esmalt p\u00f6\u00f6ratud indeksi poole, et leida ajajoonde ID antud komplekti jaoks. <code>label=value<\/code> selle m\u00f5\u00f5tme jaoks. Leiame selle ID ja salvestame v\u00e4\u00e4rtuse andmehoidlasse.<\/p>\n<p><\/p>\n<p>Kui tuleb p\u00e4ring andmete toomiseks TSDB-st, uurime esmalt p\u00f6\u00f6ratud indeksi. Saame k\u00f5ik <code>timeseries_ids<\/code> kirjed, mis vastavad antud komplektile. <code>label=value<\/code>Ja siis toome k\u00f5ik vajalikud andmed andmehoidlast, mis on indekseeritud vastavalt. <code>timeseries_ids<\/code>.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Go optimeerimised VictoriaMetricsis. Aleksandr Valjalkin\" src=\"\/wp-content\/uploads\/2020\/05\/eb9b36fa3c6de2188b97b56ad3839b2c.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Vaatame n\u00e4idet, kuidas ajajoonde andmebaas t\u00f6\u00f6tleb sissetulevat select-p\u00e4ringut.<\/p>\n<p><\/p>\n<ul>\n<li>Esmalt toob ta k\u00f5ik <code>timeseries_ids<\/code> p\u00f6\u00f6ratud indeksest, mis sisaldavad antud paare <code>label=value<\/code>, v\u00f5i vastavad antud regulaaravaldusele.<\/li>\n<li>Seej\u00e4rel toob ta k\u00f5ik andmepunktid andmehoidlast antud ajavahemikus leitud tulemuste jaoks. <code>timeseries_ids<\/code>.<\/li>\n<li>P\u00e4rast seda teostab andmebaas kasutaja p\u00e4ringu p\u00f5hjal arvutusi nende andmepunktide \u00fcle. Ja seej\u00e4rel tagastab vastuse.<\/li>\n<\/ul>\n<p><\/p>\n<p>Selles esituses r\u00e4\u00e4gin teile esimesest osast. See on otsing <code>timeseries_ids<\/code> p\u00f6\u00f6ratud indeksis. Teise ja kolmanda osa v\u00f5ite hiljem vaadata <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/VictoriaMetrics\/VictoriaMetrics\">VictoriaMetrics'i l\u00e4htekoodid<\/a><\/noindex>, v\u00f5i oodata, kuni ma valmistan ette teised ettekanded \ud83d\ude42<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Go optimeerimised VictoriaMetricsis. Aleksandr Valjalkin\" src=\"\/wp-content\/uploads\/2020\/05\/3a7dab707dd1defb9bc674a342052a03.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Alustame p\u00f6\u00f6ratud indeksist. Paljudele v\u00f5ib tunduda, et see on lihtne. Kes teab, mis on p\u00f6\u00f6ratud indeks ja kuidas see t\u00f6\u00f6tab? Oh, inimesi ei olegi nii palju. Proovime aru saada, mis see on. <\/p>\n<p><\/p>\n<p>Tegelikult on k\u00f5ik lihtne. See on lihtsalt s\u00f5nastik, mis seob v\u00f5tmed v\u00e4\u00e4rtustega. Mis on v\u00f5ti? See paar <code>label=value<\/code>, kus <code>silt<\/code> ja <code>value<\/code> \u2014 need on stringid. Ja v\u00e4\u00e4rtused on hulk <code>timeseries_ids<\/code>, mis sisaldab m\u00e4\u00e4ratud paari <code>label=value<\/code>.<\/p>\n<p><\/p>\n<p>P\u00f6\u00f6ratud indeks v\u00f5imaldab kiiresti leida k\u00f5ik <code>timeseries_ids<\/code>, millel on antud <code>label=value<\/code>.<\/p>\n<p><\/p>\n<p>Ja see v\u00f5imaldab kiiresti leida <code>timeseries_ids<\/code> aja rea jaoks mitme paari <code>label=value<\/code>, v\u00f5i paaride <code>label=regexp<\/code>. Kuidas see toimub? Kasutades hulgade l\u00f5ike leidmist <code>timeseries_ids<\/code> iga paari jaoks <code>label=value<\/code>.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Go optimeerimised VictoriaMetricsis. Aleksandr Valjalkin\" src=\"\/wp-content\/uploads\/2020\/05\/837a15a078e8c9422c721f3f072c0c09.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Vaatame erinevaid p\u00f6\u00f6rdindeksi rakendusi. Alustame k\u00f5ige lihtsamast naiivsest rakendusest. See n\u00e4eb v\u00e4lja umbes nii. <\/p>\n<p><\/p>\n<p>Function <code>getMetricIDs<\/code> saab ridade loendi. Iga rida sisaldab <code>label=value<\/code>. See funktsioon tagastab loendi <code>metricIDs<\/code>.<\/p>\n<p><\/p>\n<p>Kuidas see t\u00f6\u00f6tab? Siin on meil globaalne muutuja, mida nimetatakse <code>invertedIndex<\/code>. See on tavaline s\u00f5nastik (<code>map<\/code>), mis seob stringi slice int-idega. String sisaldab <code>label=value<\/code>.<\/p>\n<p><\/p>\n<p>Funktsiooni rakendus: saame k\u00e4tte <code>metricIDs<\/code> esimese <code>label=value<\/code>, seej\u00e4rel k\u00e4ime \u00fcle k\u00f5ik teised <code>label=value<\/code>, saame nende jaoks k\u00e4tte <code>metricIDs<\/code> . Ja kutsume v\u00e4lja funktsiooni <code>intersectInts<\/code>, millest r\u00e4\u00e4gitakse hiljem. Ja see funktsioon tagastab nende loendite ristumise.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Go optimeerimised VictoriaMetricsis. Aleksandr Valjalkin\" src=\"\/wp-content\/uploads\/2020\/05\/709beca79884a9693098781974c26f4d.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Nagu n\u00e4ete, ei ole p\u00f6\u00f6rdindeksi rakendus eriti keeruline. Kuid see on naivne rakendus. Millised on selle puudused? Peamine puudus naivsest rakendusest on see, et selline p\u00f6\u00f6rdindeks hoitakse meie p\u00f5h m\u00e4lu. P\u00e4rast rakenduse taask\u00e4ivitamist kaotame selle indeksi. Selle indeksi salvestamist kettale ei toimu. Andmebaasi jaoks on selline p\u00f6\u00f6rdindeks t\u00f5en\u00e4oliselt sobimatu.<\/p>\n<p><\/p>\n<p>Teine puudus on samuti seotud m\u00e4luga. Inverteeritud indeks peab olema mahtunud t\u00f6\u00f6m\u00e4llu. Kui see \u00fcletab t\u00f6\u00f6m\u00e4lus arvutatud suurust, siis on ilmselge, et saame \u2013 out of memory error. Ja programm ei t\u00f6\u00f6ta.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Go optimeerimised VictoriaMetricsis. Aleksandr Valjalkin\" src=\"\/wp-content\/uploads\/2020\/05\/495394168ac03aa8cbcf56ccad1cb2b8.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Seda probleemi saab lahendada selliste valmis lahenduste abil nagu <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/google\/leveldb\">LevelDB<\/a><\/noindex>, v\u00f5i <noindex><a rel=\"nofollow\" href=\"https:\/\/rocksdb.org\/\">RocksDB<\/a><\/noindex>.<\/p>\n<p><\/p>\n<p>Kokkuv\u00f5ttes on meil vaja andmebaasi, mis v\u00f5imaldab kiiresti teostada kolme\u64cd\u4f5c\u3002 <\/p>\n<p><\/p>\n<ul>\n<li>Esimene operatsioon \u2013 v\u00e4\u00e4rtuse kirjutamine <code>v\u00f5ti-v\u00e4\u00e4rtus<\/code> sellesse andmebaasi. Seda teeb ta v\u00e4ga kiiresti, kus <code>v\u00f5ti-v\u00e4\u00e4rtus<\/code> \u2013 need on suvalised stringid. <\/li>\n<li>Teine operatsioon \u2013 see on kiire v\u00e4\u00e4rtuse otsimine antud v\u00f5tme j\u00e4rgi.<\/li>\n<li>Ja kolmas operatsioon \u2013 see on kiire k\u00f5ikide v\u00e4\u00e4rtuste otsimine antud prefiksi j\u00e4rgi. <\/li>\n<\/ul>\n<p><\/p>\n<p>LevelDB ja RocksDB \u2013 need andmebaasid on v\u00e4lja t\u00f6\u00f6tatud Google'is ja Facebookis. Esmalt ilmus LevelDB. Siis Facebooki inimesed v\u00f5tsid LevelDB ja hakkasid seda arendama, tehes RocksDB. Praegu t\u00f6\u00f6tab Facebookis peaaegu k\u00f5ikides sisemistes andmebaasides RocksDB-l, sealhulgas nad on \u00fcle viinud RocksDB-le ka MySQL-i. Nad nimetasid seda <noindex><a rel=\"nofollow\" href=\"http:\/\/myrocks.io\/\">MyRocks<\/a><\/noindex>.<\/p>\n<p><\/p>\n<p>Inverteeritud indeksit saab realiseerida LevelDB abil. Kuidas seda teha? Me salvestame v\u00f5tmena <code>label=value<\/code>. Ja v\u00e4\u00e4rtusena \u2013 ajaread, kus paar on olemas. <code>label=value<\/code>.<\/p>\n<p><\/p>\n<p>Kui meil on selle paari kohta palju ajaseeriaid <code>label=value<\/code>, siis on selle andmebaasi puhul palju ridu sama v\u00f5tmega ja erinevatega <code>timeseries_ids<\/code>. Et saada loend k\u00f5igist <code>timeseries_ids<\/code>, mis algavad antud <code>label=prefix<\/code>, teeme vahemikus skaneerimise, mille jaoks see andmebaas on optimeeritud. St valime k\u00f5ik read, mis algavad <code>label=prefix<\/code> ja saame vajalikud <code>timeseries_ids<\/code>.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Go optimeerimised VictoriaMetricsis. Aleksandr Valjalkin\" src=\"\/wp-content\/uploads\/2020\/05\/a40877ecb758ac3bc1979bcd568d7e83.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Siin on ligikaudne rakendus, kuidas see Go-s v\u00e4lja n\u00e4eks. Meil on p\u00f6\u00f6ratud indeks. See on LevelDB.<\/p>\n<p><\/p>\n<p>Funktsioon on sama, mis naiivses rakenduses. See kordab enam-v\u00e4hem rida reaga naiivset rakendust. Ainus asi on see, et asemel, et p\u00f6\u00f6rduda <code>map<\/code> p\u00f6\u00f6rdume p\u00f6\u00f6ratud indeksi poole. Saame k\u00f5ik v\u00e4\u00e4rtused esimese jaoks <code>label=value<\/code>. Siis l\u00e4heme l\u00e4bi k\u00f5ikidest \u00fclej\u00e4\u00e4nud paaridest <code>label=value<\/code> ja saame nende jaoks vastavad metricID komplektid. Siis leiame ristumise. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Go optimeerimised VictoriaMetricsis. Aleksandr Valjalkin\" src=\"\/wp-content\/uploads\/2020\/05\/de11b15286816ada04b22727ff78e43d.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>K\u00f5ik tundub hea, kuid selles lahenduses on puudusi. VictoriaMetrics rakendas alguses p\u00f6\u00f6ratud indeksit LevelDB p\u00f5hjal. Kuid l\u00f5puks tuli sellest loobuda.<\/p>\n<p><\/p>\n<p>Miks? Sest LevelDB on aeglasem kui naivne rakendus. Naivses rakenduses saame antud v\u00f5tme j\u00e4rgi kohe terve viilu <code>metricIDs<\/code>. See on v\u00e4ga kiire tegevus \u2013 kogu slice on valmis kasutamiseks.<\/p>\n<p><\/p>\n<p>LevelDB-s tuleb igal funktsiooni kutsumisel <code>GetValues<\/code> l\u00e4bida k\u00f5ik read, mis algavad <code>label=value<\/code>. Ja iga rea jaoks tuleb leida v\u00e4\u00e4rtus <code>timeseries_ids<\/code>. Sellest tuleb <code>timeseries_ids<\/code> kokku panna slice neid <code>timeseries_ids<\/code>. \u041e\u0447\u0435\u0432\u0438\u0434\u043d\u043e, \u0447\u0442\u043e \u044d\u0442\u043e \u043d\u0430\u043c\u043d\u043e\u0433\u043e \u043c\u0435\u0434\u043b\u0435\u043d\u043d\u0435\u0439, \u0447\u0435\u043c \u043f\u0440\u043e\u0441\u0442\u043e \u043e\u0431\u0440\u0430\u0449\u0435\u043d\u0438\u0435 \u043a \u043e\u0431\u044b\u0447\u043d\u043e\u043c\u0443 map&#8217;\u0443 \u043f\u043e \u043a\u043b\u044e\u0447\u0443.<\/p>\n<p><\/p>\n<p>Teine puudus on see, et LevelDB on kirjutatud C-s. C-funktsioonide kutsumine Go-st ei ole v\u00e4ga kiire. Selleks kulub sadu nanosekundi. See ei ole just kiire, kuna tavalise Go-s kirjutatud funktsiooni kutse v\u00f5tab 1-5 nanosekundit, mis t\u00e4hendab, et j\u00f5udluse erinevus on k\u00fcmneid kordi. VictoriaMetricsi jaoks oli see surmav puudus \ud83d\ude42<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Go optimeerimised VictoriaMetricsis. Aleksandr Valjalkin\" src=\"\/wp-content\/uploads\/2020\/05\/47cace825807b7b062064c2e790dc9d3.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Seet\u00f5ttu kirjutasin omaenda p\u00f6\u00f6ratud indeksi seadistuse. Nimetasin selle <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/VictoriaMetrics\/VictoriaMetrics\/tree\/master\/lib\/mergeset\">mergeset<\/a><\/noindex>.<\/p>\n<p><\/p>\n<p>Mergeset p\u00f5hineb MergeTree andmestruktuuril. See andmestruktuur on laenatud ClickHouse'ist. Selgelt peaks mergeset olema optimeeritud kiire otsingu jaoks <code>timeseries_ids<\/code> antud v\u00f5tme p\u00f5hjal. Mergeset on kirjutatud t\u00e4ielikult Go-s. Saate vaadata <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/VictoriaMetrics\/VictoriaMetrics\">VictoriaMetricsi l\u00e4htekood GitHubis<\/a><\/noindex>. Mergeseti implementatsioon asub kaustas <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/VictoriaMetrics\/VictoriaMetrics\/tree\/master\/lib\/mergeset\">\/lib\/mergeset<\/a><\/noindex>. V\u00f5ite proovida aru saada, mis seal toimub.<\/p>\n<p><\/p>\n<p>API mergeset on v\u00e4ga sarnane LevelDB ja RocksDB-ga. S.t. see v\u00f5imaldab kiiresti salvestada uusi kirjeid ja kiiresti leida kirjeid antud prefiksi j\u00e4rgi.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Go optimeerimised VictoriaMetricsis. Aleksandr Valjalkin\" src=\"\/wp-content\/uploads\/2020\/05\/845704ed36f70beb468907d22701af59.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Mergeseti puudustest r\u00e4\u00e4gime hiljem. Praegu r\u00e4\u00e4gime probleemidest, mis tekkisid VictoriaMetrics'i kasutamisel tootmises p\u00f6\u00f6rdindeksi rakendamisel.<\/p>\n<p><\/p>\n<p>Kust need probleemid tulenesid?<\/p>\n<p><\/p>\n<p>Esimene p\u00f5hjus on k\u00f5rge churn rate. Ehk siis sagedane ajajoonte vahetus. See t\u00e4hendab, et ajajoon l\u00f5ppeb ja algab uus v\u00f5i algab palju uusi ajajooni. Ja see juhtub sageli.<\/p>\n<p><\/p>\n<p>Teine p\u00f5hjus on suur ajajoonte arv. Alguses, kui j\u00e4lgimine hakkas populaarsust koguma, oli ajajoonte arv v\u00e4ike. N\u00e4iteks, iga arvuti puhul tuleb j\u00e4lgida protsessori, m\u00e4lu, v\u00f5rgu ja ketta koormust. 4 ajajoont iga arvuti kohta. Kui teil on n\u00e4iteks 100 arvutit, on see 400 ajajoonte. See on v\u00e4ga v\u00e4he. <\/p>\n<p><\/p>\n<p>Aja jooksul on inimesed v\u00e4lja m\u00f5elnud, et on v\u00f5imalik m\u00f5\u00f5ta detailsemat teavet. N\u00e4iteks m\u00f5\u00f5ta 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\u00f5\u00f5tmiseks. <\/p>\n<p><\/p>\n<p>Aga see ei ole veel k\u00f5ik. Igal protsessorituumal v\u00f5ivad olla mitu olekut, nagu idle, kui see ootab. Samuti t\u00f6\u00f6 kasutaja ruumis, t\u00f6\u00f6 kernel ruumis ja teised olekud. Iga sellist olekut saab samuti m\u00f5\u00f5ta eraldi ajaseeria kui \u00fcksik ajaseeria. See suurendab ridade arvu veel 7-8 korda.<\/p>\n<p><\/p>\n<p>Meie \u00fchest m\u00f5\u00f5tmest saime 40 x 8 = 320 m\u00f5\u00f5det ainult \u00fche arvuti jaoks. Korrutame 100-ga, saame 32 000 asemel 400. <\/p>\n<p><\/p>\n<p>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\u00e4lgida. Lisaks on meil pidev uute versioonide juurutamine teie teenustes. Iga uue versiooni puhul tuleb luua uusi ajakavasid. L\u00f5ppkokkuv\u00f5ttes kasvab ajakava hulk eksponentsiaalselt ja seisame silmitsi suure ajakava hulgaga, mida nimetatakse high-cardinality. VictoriaMetrics suudab sellega edukalt toime tulla v\u00f5rreldes teiste ajakavade andmebaasidega. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Go optimeerimised VictoriaMetricsis. Aleksandr Valjalkin\" src=\"\/wp-content\/uploads\/2020\/05\/c11b7ce6d3294ae420243f72636af4b9.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Uurime l\u00e4hemalt high churn rate'i. Miks tekib productionis high churn rate? Sest m\u00f5ned labeling ja tagging v\u00e4\u00e4rtused muutuvad pidevalt.<\/p>\n<p><\/p>\n<p>N\u00e4iteks v\u00f5etakse Kubernetes, kus on kontseptsioon <code>deployment<\/code>, \u0442. \u0435. \u043a\u043e\u0433\u0434\u0430 \u0432\u044b\u043a\u0430\u0442\u044b\u0432\u0430\u0435\u0442\u0441\u044f \u043d\u043e\u0432\u0430\u044f \u0432\u0435\u0440\u0441\u0438\u044f \u0432\u0430\u0448\u0435\u0433\u043e \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f. \u0420\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u0438 Kubernetes \u043f\u043e\u0447\u0435\u043c\u0443-\u0442\u043e \u0440\u0435\u0448\u0438\u043b\u0438 \u0434\u043e\u0431\u0430\u0432\u0438\u0442\u044c id\u2019\u0448\u043a\u0443 deployment&#8217;\u0430 \u0432 label.<\/p>\n<p><\/p>\n<p>\u041a \u0447\u0435\u043c\u0443 \u044d\u0442\u043e \u043f\u0440\u0438\u0432\u0435\u043b\u043e? \u041a \u0442\u043e\u043c\u0443, \u0447\u0442\u043e \u043f\u0440\u0438 \u043a\u0430\u0436\u0434\u043e\u043c \u043d\u043e\u0432\u043e\u043c deployment&#8217;\u0435 \u0443 \u043d\u0430\u0441 \u0432\u0441\u0435 \u0441\u0442\u0430\u0440\u044b\u0435 \u0432\u0440\u0435\u043c\u0435\u043d\u043d\u044b\u0435 \u0440\u044f\u0434\u044b \u043f\u0440\u0435\u0440\u044b\u0432\u0430\u044e\u0442\u0441\u044f, \u0430 \u0432\u043c\u0435\u0441\u0442\u043e \u043d\u0438\u0445 \u043d\u0430\u0447\u0438\u043d\u0430\u044e\u0442\u0441\u044f \u043d\u043e\u0432\u044b\u0435 \u0432\u0440\u0435\u043c\u0435\u043d\u043d\u044b\u0435 \u0440\u044f\u0434\u044b \u0441 \u043d\u043e\u0432\u044b\u043c \u0437\u043d\u0430\u0447\u0435\u043d\u0438\u0435\u043c \u043b\u0435\u0439\u0431\u043b\u0430 <code>deployment_id<\/code>. Selliseid ajakavale v\u00f5ib olla sadu tuhandeid ja isegi miljoneid.<\/p>\n<p><\/p>\n<p>Oluline omadus on see, et ajakava koguhulk kasvab, kuid aktiivsete ajakavade arv, kuhu andmed voolavad, j\u00e4\u00e4b konstantseks. Seda olukorda nimetatakse high churn rate'iks.<\/p>\n<p><\/p>\n<p>Peamine probleem high churn rate'i korral on tagada pidev k\u00f5igi ajakavade otsingu kiirus m\u00e4\u00e4ratud sildihulga jooksul teatud ajavahemikus. Kui tavaliselt on see ajavahemik viimase tunni v\u00f5i viimase p\u00e4eva jooksul. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Go optimeerimised VictoriaMetricsis. Aleksandr Valjalkin\" src=\"\/wp-content\/uploads\/2020\/05\/ac18482b87cc37624d163b30c68cf7be.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Kuidas seda probleemi lahendada? Siin on esimene variant: jagada p\u00f6\u00f6rdindeks s\u00f5ltumatuteks osadeks ajas. St. m\u00f6\u00f6dub teatud ajavahemik, l\u00f5petame t\u00f6\u00f6 p\u00f6\u00f6rdindeksi praegusega ja loome uue p\u00f6\u00f6rdindeksi. M\u00f6\u00f6dub veel \u00fcks ajavahemik, loome veel \u00fche ja veel \u00fche. <\/p>\n<p><\/p>\n<p>Ja nende p\u00f6\u00f6rdindeksite valimisel leiame p\u00f6\u00f6rdindeksite hulga, mis langeb m\u00e4\u00e4ratud ajavahemikku. Seega valime sealt ajakava id-d. <\/p>\n<p><\/p>\n<p>See aitab ressursse s\u00e4\u00e4sta, kuna me ei pea vaatama osi, mis ei j\u00e4\u00e4 m\u00e4\u00e4ratud vahemikku. St, et tavaliselt, kui valime andmed viimasest tunnist, siis eelnevaid ajavahemikke j\u00e4tame p\u00e4ringud vahele. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Go optimeerimised VictoriaMetricsis. Aleksandr Valjalkin\" src=\"\/wp-content\/uploads\/2020\/05\/1afa3a88caa7423941ae3494b9cec706.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>On veel \u00fcks v\u00f5imalus selle probleemi lahendamiseks. See on hoida iga p\u00e4eva jaoks eraldi nimekiri ajaseerude id-dest, mis esinesid sellel p\u00e4eval.<\/p>\n<p><\/p>\n<p>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. <\/p>\n<p><\/p>\n<p>Puuduseks on see, et selline lahendus on keerulisem rakendada ja keerulisem debugida. Ja VictoriaMetrics valis selle lahenduse. See on k\u00f5igepealt ajalooliselt nii kujunenud. Selline lahendus t\u00f6\u00f6tab ka \u00fcsna h\u00e4sti v\u00f5rreldes varasemaga. Seda seet\u00f5ttu, et seda lahendust ei olnud rakendatud, kuna andmete kopeerimine on vajalik igas partition\u2019is 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\u00f5ttu see valiti. <\/p>\n<p><\/p>\n<p>Pidime sellega v\u00f5itlema. V\u00f5itlus seisnes selles, et antud rakenduses tuleb ikkagi valida palju suurem hulk <code>timeseries_ids<\/code> andmete jaoks, kui siis, kui p\u00f6\u00f6rdindeks on jagatud ajas.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Go optimeerimised VictoriaMetricsis. Aleksandr Valjalkin\" src=\"\/wp-content\/uploads\/2020\/05\/5b10e61aaa803428ed3bfe31815f09d3.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Kuidas me selle probleemi lahendasime? Me lahendasime selle originaalsel viisil \u2013 salvestades igas p\u00f6\u00f6rdindeksi kirjas mitu ajaseeriade identifikaatorit, mitte \u00fchte. St meil on v\u00f5tme <code>label=value<\/code>, mis on iga ajareal olemas. Ja n\u00fc\u00fcd salvestame m\u00f5ned <code>timeseries_ids<\/code> \u00fches kirjes.<\/p>\n<p><\/p>\n<p>Siin on n\u00e4ide. Varem oli meil N kirjet, aga n\u00fc\u00fcd on meil \u00fcks kiri, mille prefiks on sama mis k\u00f5igil teistel. Eelneva kirje v\u00e4\u00e4rtus sisaldab k\u00f5iki ajaread id'sid. <\/p>\n<p><\/p>\n<p>See on v\u00f5imaldanud suurendada sellise p\u00f6\u00f6rdindeksi skaneerimise kiirus kuni 10 korda. Ja on v\u00e4hendanud m\u00e4lutarbimist puhverdamise jaoks, kuna n\u00fc\u00fcd salvestame rea <code>label=value<\/code> ainult kord puhverdamiseks koos N korda. Ja see rida v\u00f5ib olla suur, kui sul on sisendites ja etiketides pikki ridu, mida Kubernetes sinna meeldib toppida.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Go optimeerimised VictoriaMetricsis. Aleksandr Valjalkin\" src=\"\/wp-content\/uploads\/2020\/05\/ae4f38a440203bad2d03cf2abd1faafe.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Veel \u00fcks v\u00f5imalus p\u00f6\u00f6rdindeksi otsimise kiirusel kiirus - see on shardimine. Mitme p\u00f6\u00f6rdindeksi loomine \u00fche asemel ja andmete shardimine nende vahel v\u00f5ti j\u00e4rgi. See on komplekt <code>key=value<\/code> See, meil on mitu s\u00f5ltumatut p\u00f6\u00f6ratud indeksit, mida saame samaaegselt k\u00fcsida mitmel protsessoril. Varasemad teostused lubasid t\u00f6\u00f6tada ainult \u00fches protsessorire\u017eiimis, st skaneerida andmeid vaid \u00fchel tuumal. See lahendus v\u00f5imaldab skaneerida andmeid kohe mitmel tuumal, nagu ClickHouse armastab teha. Just seda me plaanime rakendada.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Go optimeerimised VictoriaMetricsis. Aleksandr Valjalkin\" src=\"\/wp-content\/uploads\/2020\/05\/5ced6446efbf8ded8d7fb91694a999b0.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Ja n\u00fc\u00fcd naaseme meie teemade juurde \u2013 rists\u00f5idufunktsiooni juurde. <code>timeseries_ids<\/code>. Uurime, millised teostused v\u00f5ivad olla v\u00f5imalikud. See funktsioon v\u00f5imaldab leida <code>timeseries_ids<\/code> antud komplekti jaoks. <code>label=value<\/code>.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Go optimeerimised VictoriaMetricsis. Aleksandr Valjalkin\" src=\"\/wp-content\/uploads\/2020\/05\/073a155018a91120c6996c324772f9af.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Esimene variant on naiivne teostus. Kaks sisemist ts\u00fcklit. Saame funktsiooni sisendiks <code>intersectInts<\/code> kaks slices \u2014 <code>a<\/code> ja <code>b<\/code>. V\u00e4ljundina peab see meile tagastama nende slices'i ristumise.<\/p>\n<p><\/p>\n<p>Naiivne teostus n\u00e4eb v\u00e4lja nii. K\u00e4ime k\u00f5ik v\u00e4\u00e4rtused l\u00e4bi slice'st <code>a<\/code>, selle ts\u00fckli sees k\u00e4ime k\u00f5ik l\u00e4bi slice'st <code>b<\/code>. Ja v\u00f5rdleme neid. Kui need kattuvad, siis oleme leidnud ristumise. Ja salvestame selle <code>tulemus<\/code>.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Go optimeerimised VictoriaMetricsis. Aleksandr Valjalkin\" src=\"\/wp-content\/uploads\/2020\/05\/b89dcbb4f6d73377f9cf4f50169d6dd7.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Millised on puudused? Ruudukompleksus \u2013 see on selle peamine puudus. N\u00e4iteks, kui teie slice 'id on suured. <code>a<\/code> ja <code>b<\/code> kui \u00fche miljoni, siis see funktsioon ei naas tuttavat vastust. Kuna tal on vaja teha \u00fche triljoni iteratsiooni, mis on v\u00e4ga palju isegi t\u00e4nap\u00e4evaste arvutite jaoks.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Go optimeerimised VictoriaMetricsis. Aleksandr Valjalkin\" src=\"\/wp-content\/uploads\/2020\/05\/bad26b0092a2fd7fc813bcb79a9138ce.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Teine rakendus p\u00f5hineb map'il. Loome map'i. Paneme sellesse map'i k\u00f5ik v\u00e4\u00e4rtused slice'ist. <code>a<\/code>. Seej\u00e4rel k\u00e4ime slice'i kaudu eraldi ts\u00fckliga. <code>b<\/code>. Ja kontrollime \u2013 kas see v\u00e4\u00e4rtus on slice'is. <code>b<\/code> map'is. Kui see on olemas, lisame selle tulemustesse. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Go optimeerimised VictoriaMetricsis. Aleksandr Valjalkin\" src=\"\/wp-content\/uploads\/2020\/05\/1e610acf641a9cfe4c80aac1fe26044c.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Millised on eelised? Eelis on see, et siin on ainult lineaarsed kulud. St. funktsioon t\u00f6\u00f6tab palju kiiremini suurte slice'ide suuruste korral. Miljoni suuruse slice'i puhul t\u00f6\u00f6tab see funktsioon 2 miljoni iteratsiooni jooksul, erinevalt triljonist iteratsioonist, nagu eelnevas funktsioonis.<\/p>\n<p><\/p>\n<p>Ja puuduseks on see, et see funktsioon vajab rohkem m\u00e4lu selle map'i loomiseks.<\/p>\n<p><\/p>\n<p>Teine puudus \u2013 see on suur overhead hashimisele. See puudus ei ole v\u00e4ga ilmne. Ja meie jaoks polnud see samuti v\u00e4ga ilmne, mist\u00f5ttu alguses VictoriaMetrics'is oli intersection'i rakendus l\u00e4bi map'i. Aga hiljem n\u00e4itas profileerimine, et peamine protsessori aeg kulub map'i kirjutamiseks ja v\u00e4\u00e4rtuse olemasolu kontrollimiseks selles map'is.<\/p>\n<p><\/p>\n<p>Miks kulub CPU aeg nendes kohtades? Sest Go teostab seal hashimisoperatsiooni. See t\u00e4hendab, et ta arvutab v\u00f5tme hash'i, et p\u00e4\u00e4seda seej\u00e4rel antud indeksi kaudu HashMap'ile. Hash'i arvutamise operatsioon toimub m\u00f5ne k\u00fcmnendiku nanosekundiga. See on VictoriaMetricsi jaoks aeglane.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Go optimeerimised VictoriaMetricsis. Aleksandr Valjalkin\" src=\"\/wp-content\/uploads\/2020\/05\/969f10d875d88998e958894ca28b1181.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Otsustasin rakendada bitset'i, mis on spetsiaalselt selle juhtumi jaoks optimeeritud. Nii n\u00e4eb n\u00fc\u00fcd kahe slice'i \u00fchisosa v\u00e4lja. Siin loome bitset'i. Lisame sinna esimesest slice'ist elemendid. Siis kontrollime nende elementide olemasolu teises slice'is. Ja lisame need tulemusse. See t\u00e4hendab, et see ei erine peaaegu eelmise n\u00e4ite puhul. Ainsad asjad, mida oleme siin teinud, on kaardile juurdep\u00e4\u00e4su asendamine kohandatud funktsioonidega. <code>add<\/code> ja <code>has<\/code>.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Go optimeerimised VictoriaMetricsis. Aleksandr Valjalkin\" src=\"\/wp-content\/uploads\/2020\/05\/b4ec0753d30d9684868a031f605632c0.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Esmapilgul tundub, et see peaks t\u00f6\u00f6tama aeglasemalt, kui varem kasutati tavalist kaarti ja n\u00fc\u00fcd kutsutakse veel mingid funktsioonid v\u00e4lja, kuid profilleerimine n\u00e4itab, et see asi t\u00f6\u00f6tab 10 korda kiiremini kui tavaline kaart VictoriaMetricsi jaoks.<\/p>\n<p><\/p>\n<p>Lisaks sellele kasutab see v\u00f5rreldes kaardi rakendusega oluliselt v\u00e4hem m\u00e4lu. Sest me hoiame siin bitte, mitte kaheksabaidiseid v\u00e4\u00e4rtusi.<\/p>\n<p><\/p>\n<p>Sellise rakenduse puuduseks on see, et see ei ole nii ilmne, mitte triviaalne. <\/p>\n<p><\/p>\n<p>Veel \u00fcks puudus, mida paljud ei pruugi m\u00e4rgata, on see, et see rakendus v\u00f5ib teatud olukordades halvasti t\u00f6\u00f6tada. See t\u00e4hendab, et see on optimeeritud konkreetse juhtumi jaoks, nimelt VictoriaMetrics ajasarjade id-de \u00fclekandmise jaoks. See ei t\u00e4henda, et see sobib igas olukorras. Kui seda valesti kasutada, siis saavutame mitte ainult j\u00f5udluse kasvu, vaid ka out of memory error ja j\u00f5udluse v\u00e4henemise. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Go optimeerimised VictoriaMetricsis. Aleksandr Valjalkin\" src=\"\/wp-content\/uploads\/2020\/05\/94bd174afe43e67b3cf279dc7a1be17c.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Vaatame selle andmestruktuuri rakendust. Kui soovite, siis see asub VictoriaMetricsi allikates, kaustas <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/VictoriaMetrics\/VictoriaMetrics\/tree\/master\/lib\/uint64set\">lib\/uint64set<\/a><\/noindex>. See on optimeeritud just VictoriaMetricsi juhtumi jaoks, kus <code>timeseries_id<\/code> esindab 64-bitist v\u00e4\u00e4rtust, kus esimesed 32 bitti on peaaegu konstantsetena ja muutuvad ainult viimased 32 bitti.<\/p>\n<p><\/p>\n<p>See andmestruktuur ei salvestata kettale, vaid t\u00f6\u00f6tab ainult m\u00e4lus. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Go optimeerimised VictoriaMetricsis. Aleksandr Valjalkin\" src=\"\/wp-content\/uploads\/2020\/05\/e24ca65f860e2b04037e073f7acae0c1.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Siin on selle API. See ei ole v\u00e4ga keeruline. API on kohandatud just VictoriaMetricsi konkreetse kasutusn\u00e4ite jaoks. Siin ei ole \u00fcleliigseid funktsioone. Siin on funktsioonid, mida VictoriaMetrics selgelt kasutab.<\/p>\n<p><\/p>\n<p>On funktsioon <code>add<\/code>, mis lisab uusi v\u00e4\u00e4rtusi. On olemas funktsioon <code>has<\/code>, mis kontrollib uusi v\u00e4\u00e4rtusi. Ja on funktsioon <code>del<\/code>, mis eemaldab v\u00e4\u00e4rtused. On abifunktsioon <code>len<\/code>, mis tagastab kogumi suuruse. Funktsioon <code>clone<\/code> kloneerib kogumi. Ja funktsioon <code>appendto<\/code> t\u00f6\u00f6tluses t\u00e4iendatakse see l\u00f5ikesse <code>timeseries_ids<\/code>.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Go optimeerimised VictoriaMetricsis. Aleksandr Valjalkin\" src=\"\/wp-content\/uploads\/2020\/05\/874b04042d13f342d39f8f393e7fb78c.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Nii n\u00e4eb selle andmestruktuuri rakendus v\u00e4lja. Kogumil on kaks elementi:<\/p>\n<p><\/p>\n<ul>\n<li>\n<p><code>ItemsCount<\/code> \u2013 see on abiv\u00e4li, et kiiresti tagastada kogumi elementide arv. Selle abiv\u00e4lja oleks v\u00f5inud \u00e4ra j\u00e4tta, kuid see tuli siia lisada, kuna VictoriaMetrics k\u00fcsitleb sageli oma algoritmides bitseti pikkust.<\/p>\n<p>\n<\/li>\n<li>\n<p>Teine v\u00e4li on <code>buckets<\/code>. See on l\u00f5ik struktuurist <code>bucket32<\/code>. Igas struktuuris on salvestatud <code>hi<\/code> v\u00e4li. Need on k\u00f5ige k\u00f5rgemad 32 bitti. Ja kaks l\u00f5iku \u2014 <code>b16his<\/code> ja <code>buckets<\/code> kohast <code>bucket16<\/code> struktuurid. <\/p>\n<p>\n<\/li>\n<\/ul>\n<p><\/p>\n<p>Siin hoitakse 64-bitise struktuuri teise osa \u00fclemisi 16 bitti. Ja siin hoitakse bitsets'i iga bait j\u00e4\u00e4b 16 bitiga. <\/p>\n<p><\/p>\n<p><code>Bucket64<\/code> koosneb massiivist <code>uint64<\/code>. Pikkus arvutatakse nende constatsioonide abil. \u00dches <code>bucket16<\/code> max v\u00f5ib hoida <code>2^16=65536<\/code> bititi. Kui see jagada 8-ga, siis on see 8 kilobaiti. Kui jagada veel kord 8-ga, siis on see 1000 <code>uint64<\/code> v\u00e4\u00e4rtuses. St. <code>Bucket16<\/code> \u2013 see on meil 8-kilobaitine struktuur. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Go optimeerimised VictoriaMetricsis. Aleksandr Valjalkin\" src=\"\/wp-content\/uploads\/2020\/05\/1cca4e6bfafa3408a3c95e0118e26d80.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Vaatame, kuidas on rakendatud \u00fcks meetod uut v\u00e4\u00e4rtust lisava struktuuri. <\/p>\n<p><\/p>\n<p>K\u00f5ik algab <code>uint64<\/code> v\u00e4\u00e4rtusest. Arvutame \u00fclemised 32 bitti, arvutame alumised 32 bitti. L\u00e4bime k\u00f5ik <code>buckets<\/code>. V\u00f5rdleme \u00fclemisi 32 bitti igas baketis lisatava v\u00e4\u00e4rtusega. Ja kui need kattuvad, siis kutsume \u00fcles funktsiooni <code>add<\/code> b32 struktuuris <code>buckets<\/code>. Ja lisame sinna alumised 32 bitti. Ja kui see tagastab <code>true<\/code>, siis t\u00e4hendab, et me lisasime sellise v\u00e4\u00e4rtuse sinna ja meil polnud sellist v\u00e4\u00e4rtust. Kui see tagastab <code>false<\/code>, siis selline v\u00e4\u00e4rtus oli juba olemas. Siis suurendame struktuuri elementide arvu. <\/p>\n<p><\/p>\n<p>Kui me ei leidnud vajalikku <code>baketi<\/code> vajaliku hi-v\u00e4\u00e4rtusega, siis kutsume \u00fcles funktsiooni <code>addAlloc<\/code>, mis eraldab uue <code>baketi<\/code>, lisades selle baketi struktuuri.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Go optimeerimised VictoriaMetricsis. Aleksandr Valjalkin\" src=\"\/wp-content\/uploads\/2020\/05\/c5d1e5de767f47c7c40e01e12b6d0617.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>See on funktsiooni rakendus <code>b32.add<\/code>. See on sarnane eelmise rakendusega. Me arvutame vanemad 16 bitti, nooremad 16 bitti.<\/p>\n<p><\/p>\n<p>Siis l\u00e4bime k\u00f5ik \u00fclemised 16 bitti. Leiame kattuvused. Ja kattumise korral kutsume \u00fcles meetodi add, mida uurime j\u00e4rgmises lehes <code>bucket16<\/code>.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Go optimeerimised VictoriaMetricsis. Aleksandr Valjalkin\" src=\"\/wp-content\/uploads\/2020\/05\/e98c4ef316f3a894fd7019c3c85696f7.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Ja siin on k\u00f5ige madalam tase, mis peab olema maksimaalselt optimeeritud. Me arvutame <code>uint64<\/code> id v\u00e4\u00e4rtuse slice bit, samuti <code>bitmask<\/code>. See on mask selle 64-bitise v\u00e4\u00e4rtuse jaoks, mille j\u00e4rgi saab kontrollida selle bit'i olemasolu v\u00f5i seada selle. Kontrollime, kas see bit on seatud, ja seame selle, ning tagastame, kas see on olemas. Selline rakendus v\u00f5imaldas meil kiirendada aegrea id-de ristumist 10 korda v\u00f5rreldes tavap\u00e4raste map'idega.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Go optimeerimised VictoriaMetricsis. Aleksandr Valjalkin\" src=\"\/wp-content\/uploads\/2020\/05\/4dfa5a6142829a3551be22d6c9c3ab92.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>VictoriaMetrics'is on lisaks sellele optimeerimisele palju teisi optimeerimisi. Enamik neist optimeerimistest on lisatud mitte niisama, vaid p\u00e4rast koodi profileerimist tootmises.<\/p>\n<p><\/p>\n<p>See on optimeerimise peamine reegel \u2013 mitte lisada optimeerimist, oletades, et siin on kitsaskoht, kuna see v\u00f5ib osutuda vale oletuseks. Optimeerimine halvendab tavaliselt koodi kvaliteeti. Seet\u00f5ttu tasub optimeerida ainult p\u00e4rast profileerimist ja soovitatavalt tootmises, et need oleksid tegelikud andmed. Kellele huvi pakub, v\u00f5ite vaadata VictoriaMetrics'i l\u00e4htekoodi ja \u00f5ppida tundma teisi optimeerimisi, mis seal on.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Go optimeerimised VictoriaMetricsis. Aleksandr Valjalkin\" src=\"\/wp-content\/uploads\/2020\/05\/7585c4dc782627bac5b649e6a55e2ffb.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p><em>Mul on k\u00fcsimus bitset'i kohta. See sarnaneb v\u00e4ga C++ vector bool'i rakenduse, optimeeritud bitset'iga. Kas te v\u00f5tsite selle rakenduse sealt?<\/em><\/p>\n<p><\/p>\n<p>Ei, see ei ole se. Selle bitseti rakendamisel p\u00f5hinesin ma teadmistele nende id-aegrea struktuurist, mida kasutatakse VictoriaMetrics'is. Nende struktuuri kohaselt on \u00fclemised 32 bitti enamasti p\u00fcsivad. Alumised 32 bitti v\u00f5ivad muutuda. Mida madalam on bitt, seda sagedamini v\u00f5ib see muutuda. Seega on see rakendus optimeeritud just selle andmestruktuuri jaoks. C++ rakendus, kui ma \u00f5igesti tean, on optimeeritud \u00fcldiste juhtumite jaoks. Kui optimeerida \u00fcldiste juhtumite j\u00e4rgi, t\u00e4hendab see, et see ei ole konkreetses juhtumis k\u00f5ige optimaalsem.<\/p>\n<p><\/p>\n<p>Soovitan teil vaadata ka Alexei Milovidi ettekannet. Ta r\u00e4\u00e4kis kuskil kuu aega tagasi ClickHouse'i optimeerimisest konkreetsete erialade jaoks. Ta r\u00e4\u00e4gib nimelt, et C++ rakendus v\u00f5i m\u00f5ni muu rakendus on tavaliselt kohandatud keskmiselt hea t\u00f6\u00f6 jaoks. See v\u00f5ib t\u00f6\u00f6tada halvemini kui spetsialiseeritud rakendus konkreetsete teadlike teadmiste jaoks, nagu meil on, kui me teame, et \u00fclemised 32 bitti on enamasti p\u00fcsivad.<\/p>\n<p><\/p>\n<p><em>Mul on teine k\u00fcsimus. Mis on radikaalne erinevus InfluxDB-st?<\/em><\/p>\n<p><\/p>\n<p>Olulisi erinevusi on palju. Kui r\u00e4\u00e4kida seadistustest ja m\u00e4lutarbimisest, siis InfluxDB n\u00e4itab testides 10 korda suuremat m\u00e4lutarbimist k\u00f5rge kardinaalsusega ajajoonte jaoks, kui neid on palju, n\u00e4iteks miljoneid. N\u00e4iteks VictoriaMetrics tarbib 1 GB miljoni aktiivse joone kohta, samas kui InfluxDB tarbib 10 GB. Ja see on suur erinevus. <\/p>\n<p><\/p>\n<p>Teine oluline erinevus on see, et InfluxDB-s on kummalised p\u00e4ringu keeled \u2013 Flux ja InfluxQL. Need ei ole ajajoontes t\u00f6\u00f6tamiseks eriti mugavad v\u00f5rreldes <noindex><a rel=\"nofollow\" href=\"https:\/\/medium.com\/@valyala\/promql-tutorial-for-beginners-9ab455142085\">PromQL<\/a><\/noindex>, mida VictoriaMetrics toetab. PromQL on p\u00e4ringute keel, mis p\u00e4rineb Prometheusest.<\/p>\n<p><\/p>\n<p>Ja veel \u00fcks erinevus on see, et InfluxDB-l on veidi kummaline andmemudel, kus igas reas v\u00f5ib olla mitu fields erinevate m\u00e4rgendite kogudega. Need read jagunevad veel igasugusteks tabeliteks. Need t\u00e4iendavad keerukused muudavad selle andmebaasi hilisema t\u00f6\u00f6 keeruliseks. Seda on raske toetada ja m\u00f5ista.<\/p>\n<p><\/p>\n<p>VictoriaMetricsis on k\u00f5ik palju lihtsam. Iga ajajoon on v\u00f5tme-v\u00e4\u00e4rtuse paar. V\u00e4\u00e4rtus on kogum punkte \u2013 <code>(timestamp, value)<\/code>, samas kui v\u00f5ti on kogum <code>label=value<\/code>. Puudub lahknevus fields'i ja measurements'i vahel. See v\u00f5imaldab valida \u00fcksk\u00f5ik milliseid andmeid ning seej\u00e4rel neid kombineerida, liita, lahutada, korrutada, jagada, erinevalt InfluxDB-st, kus arvutused erinevate ridade vahel ei ole endiselt rakendatud, kui ma \u00f5igesti tean. Kui need on isegi rakendatud, on see keeruline, tuleb kirjutada palju koodi. <\/p>\n<p><\/p>\n<p><em>Mul on t\u00e4psustav k\u00fcsimus. Kas ma sain \u00f5igesti aru, et oli mingi probleem, millest te r\u00e4\u00e4kisite, et see p\u00f6\u00f6ratud indeks ei mahu m\u00e4lu, mist\u00f5ttu seal toimub partitsioneerimine?<\/em><\/p>\n<p><\/p>\n<p>\u0412\u043d\u0430\u0447\u0430\u043b\u0435 \u044f \u043f\u043e\u043a\u0430\u0437\u0430\u043b \u043d\u0430\u0438\u0432\u043d\u0443\u044e \u0440\u0435\u0430\u043b\u0438\u0437\u0430\u0446\u0438\u044e \u0438\u043d\u0432\u0435\u0440\u0442\u0438\u0440\u043e\u0432\u0430\u043d\u043d\u043e\u0433\u043e \u0438\u043d\u0434\u0435\u043a\u0441\u0430 \u043d\u0430 \u0441\u0442\u0430\u043d\u0434\u0430\u0440\u0442\u043d\u043e\u0439 Go&#8217;\u0448\u043d\u043e\u0439 map&#8217;\u0435. \u0422\u0430\u043a\u0430\u044f \u0440\u0435\u0430\u043b\u0438\u0437\u0430\u0446\u0438\u044f \u043d\u0435 \u043f\u043e\u0434\u0445\u043e\u0434\u0438\u0442 \u0434\u043b\u044f \u0431\u0430\u0437 \u0434\u0430\u043d\u043d\u044b\u0445, \u043f\u043e\u0442\u043e\u043c\u0443 \u0447\u0442\u043e \u044d\u0442\u043e\u0442 \u0438\u043d\u0432\u0435\u0440\u0442\u0438\u0440\u043e\u0432\u0430\u043d\u043d\u044b\u0439 \u0438\u043d\u0434\u0435\u043a\u0441 \u043d\u0435 \u0441\u043e\u0445\u0440\u0430\u043d\u044f\u0435\u0442\u0441\u044f \u043d\u0430 \u0434\u0438\u0441\u043a\u0435, \u0430 \u0431\u0430\u0437\u0430 \u0434\u0430\u043d\u043d\u044b\u0445 \u0434\u043e\u043b\u0436\u043d\u0430 \u0441\u043e\u0445\u0440\u0430\u043d\u044f\u0442\u044c \u043d\u0430 \u0434\u0438\u0441\u043a, \u0447\u0442\u043e\u0431\u044b \u043f\u0440\u0438 \u0440\u0435\u0441\u0442\u0430\u0440\u0442\u0435 \u044d\u0442\u0438 \u0434\u0430\u043d\u043d\u044b\u0435 \u043e\u0441\u0442\u0430\u0432\u0430\u043b\u0438\u0441\u044c \u0434\u043e\u0441\u0442\u0443\u043f\u043d\u044b\u043c\u0438. \u0412 \u0434\u0430\u043d\u043d\u043e\u0439 \u0440\u0435\u0430\u043b\u0438\u0437\u0430\u0446\u0438\u0438 \u043f\u0440\u0438 \u0440\u0435\u0441\u0442\u0430\u0440\u0442\u0435 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f \u0443 \u0432\u0430\u0441 \u0438\u043d\u0432\u0435\u0440\u0442\u0438\u0440\u043e\u0432\u0430\u043d\u043d\u044b\u0439 \u0438\u043d\u0434\u0435\u043a\u0441 \u043f\u0440\u043e\u043f\u0430\u0434\u0435\u0442. \u0418 \u0432\u044b \u043f\u043e\u0442\u0435\u0440\u044f\u0435\u0442\u0435 \u0434\u043e\u0441\u0442\u0443\u043f \u043a\u043e \u0432\u0441\u0435\u043c \u0434\u0430\u043d\u043d\u044b\u043c, \u043f\u043e\u0442\u043e\u043c\u0443 \u0447\u0442\u043e \u043d\u0435 \u0441\u043c\u043e\u0436\u0435\u0442\u0435 \u043d\u0430\u0439\u0442\u0438 \u0438\u0445. <\/p>\n<p><\/p>\n<p><em>Tere! Ait\u00e4h ettekande eest! Minu nimi on Pavel. Olen ettev\u00f5ttest Wildberries. Mul on paar k\u00fcsimust teie jaoks. Esimene k\u00fcsimus. Kuidas te arvate, kui valiksite oma rakenduse arhitektuuri \u00fclesehitamisel teise p\u00f5him\u00f5tte ja jaotaksite andmed ajaliselt, kas siis saaksite andmete otsimise ajal ristuda, tuginedes ainult sellele, et \u00fches jaotuses on andmed \u00fche ajavahemiku kohta, st \u00fches ajavahemikus, ja ei peaks muretsema, et teie t\u00fckid on eri kohtades laiali? Teine k\u00fcsimus \u2014 kuna te rakendate sarnast algoritmi bitsetide ja muu juurde, kas olete ehk proovinud kasutada protsessori juhiseid? V\u00f5ib-olla olete katsetanud selliseid optimeerimisi?<\/em><\/p>\n<p><\/p>\n<p>Teisele k\u00fcsimusele vastan kohe. Me ei ole sinna veel j\u00f5udnud. Kuid kui see vajalik on, siis me j\u00f5uame. Aga esimene, mis k\u00fcsimus oligi?<\/p>\n<p><\/p>\n<p><em>Te arutasite kahte stsenaariumit. Ja \u00fctlesite, et valisite teise, millel on keerulisem rakendus. Ja ei eelistanud esimest, kus andmed on ajaliselt jaotatud.<\/em> <\/p>\n<p><\/p>\n<p>Jah. Esimesel juhul oleks indeksi kogumaht suurem, kuna peame igas partitsioonis hoidma andmete koopiaid ajaseeriate jaoks, mis ulatuvad \u00fcle k\u00f5ik need partitsioonid. Ja kui teil on ajaseeriate churn rate madal, st pidevalt kasutatakse samu seeriaid, siis esimesel juhul kaotaksime diskiruumi kasutuses palju rohkem v\u00f5rreldes teise variandiga.<\/p>\n<p><\/p>\n<p>Nii et jah, ajakohane partitsioonimine on hea lahendus. Seda kasutab Prometheus. Kuid Prometheusel on teine puudus. Andmeosade \u00fchendamisel peab ta hoidma m\u00e4lu k\u00f5igi label'ite ja ajaseeriate metaandmete jaoks. Seet\u00f5ttu, kui \u00fchendatavad andmeosad on suured, suureneb m\u00e4lu tarbimine oluliselt, erinevalt VictoriaMetricsist. VictoriaMetrics ei tarbi \u00fchendamisel \u00fcldse m\u00e4lu, seal tarbitakse paari kilobaiti s\u00f5ltumata \u00fchendatavate andmeosade suurusest.<\/p>\n<p><\/p>\n<p><em>Teie kasutatav algoritm kasutab m\u00e4lu. Selles registreeritakse ajats\u00fcklite m\u00e4rgid, millel on v\u00e4\u00e4rtused. Nii kontrollite paari olemasolu \u00fches andmehulgas ja teises. Ja saate aru, kas toimus \u00fchisosa v\u00f5i mitte. T\u00fc\u00fcpiliselt rakendavad andmebaasid kursoreid, iteraatoreid, mis hoiavad oma praegust olekut ja liikuvad sorteeritud andmete kaudu, mist\u00f5ttu on teil need operatsioonid lihtsamad.<\/em> <\/p>\n<p><\/p>\n<p>Miks me ei kasuta kursoreid andmete ristumisteks?<\/p>\n<p><\/p>\n<p><em>Jah.<\/em> <\/p>\n<p><\/p>\n<p>Meil on LevelDB-s v\u00f5i mergeset-s just sorteeritud read. Saame kursori abil l\u00e4bi 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\u00f5tab aega 5 nanosekundit. Ja kui teil on 100 000 000 rida, siis kulutame poole sekundi ainult funktsiooni v\u00e4lja kutsumiseks.<\/p>\n<p><\/p>\n<p><em>Jah, see on olemas. Ja viimase k\u00fcsimus, millel on v\u00f5ib-olla veidi kummaline k\u00f5la. Miks ei saa andmete laekumise hetkel arvutada k\u00f5iki vajalikke aggregaatide ja salvestada neid vajalikul viisil? Miks hoida suuri andmemahte s\u00fcsteemides nagu VictoriaMetrics, ClickHouse jne, et siis kulutada nende k\u00e4sitlemiseks v\u00e4ga palju aega?<\/em><\/p>\n<p><\/p>\n<p><em>Toon n\u00e4ite, et oleks arusaadavam. Oletame, kuidas t\u00f6\u00f6tab v\u00e4ike m\u00e4nguasi spidomeeter? See salvestab vahemaa, mille olete l\u00e4binud, pidevalt lisades selle \u00fchte suurusesse, teise - aja. Ja jagab. Ja saab keskmise kiirus. Saame teha enam-v\u00e4hem sama. Koguda jooksvalt k\u00f5ik vajalikud faktid.<\/em><\/p>\n<p><\/p>\n<p>H\u00e4sti, olen k\u00fcsimusest aru saanud. Teie n\u00e4ide on eluj\u00f5uline. Kui te teate, milliseid agregaatfunktsioone vajate, siis on see parim lahendus. Probleem on aga selles, et inimesed s\u00e4ilitavad need m\u00f5\u00f5dikud, mingid andmed ClickHouse'is ja nad ei tea veel, kuidas nad neid tulevikus agregoorida v\u00f5i filtreerida, mist\u00f5ttu peavad nad s\u00e4ilitama k\u00f5ik toored andmed. Aga kui te teate, et peate midagi keskmist arvutama, siis miks mitte arvutada seda, selle asemel et hoida seal hunnikut tooreid v\u00e4\u00e4rtusi? Kuid see ainult siis, kui te t\u00e4pselt teate, mida vajate.<\/p>\n<p><\/p>\n<p>Muide, ajaliselt j\u00e4rjestatud andmebaasid toetavad agregaatide arvestamist. N\u00e4iteks toetab Prometheus <noindex><a rel=\"nofollow\" href=\"https:\/\/prometheus.io\/docs\/prometheus\/latest\/configuration\/recording_rules\/\">salvestusreegleid<\/a><\/noindex>. See t\u00e4hendab, et seda on v\u00f5imalik teha, kui te teate, milliseid agregaatfunktsioone vajate. VictoriaMetrics'il seda veel ei ole, kuid tavaliselt paigaldatakse sellele ette Prometheus, kus seda saab teha salvestusreeglites.<\/p>\n<p><\/p>\n<p>N\u00e4iteks eelmisel t\u00f6\u00f6kohal tuli kasutada liugakna abil viimase tunni jooksul toimunud s\u00fcndmuste arvu arvestamist. Probleemiks oli, et tuli teha kohandatud implementatsioon Go keeles, st teenus selle arvestamiseks. See teenus osutus l\u00f5puks keeruliseks, kuna selle arvestamine on keeruline. Implementatsioon v\u00f5ib olla lihtne, kui peate arvestama m\u00f5ningaid koguseid fikseeritud ajavahemike jooksul. Kui aga soovite arvestada s\u00fcndmusi liugaknas, pole see nii lihtne, kui see tundub. Arvan, et ClickHouse'is v\u00f5i ajaseeria andmebaasides pole see ikka veel rakendatud, kuna rakendamine on keeruline.<\/p>\n<p><\/p>\n<p><em>Ja veel \u00fcks k\u00fcsimus. R\u00e4\u00e4kisime praegu keskmistest v\u00e4\u00e4rtustest ja mulle tuli meelde, et kunagi oli selline asi nagu Graphite, millel oli Carboni taust. See suutis vanu andmeid k\u00e4rpida, st j\u00e4ttis iga minuti, iga tunni jne jaoks \u00fche punkti. \u00dcldiselt on see \u00fcsna mugav, kui me vajame toorandmeid, \u00fctleme, kuu kohta, samas kui k\u00f5ik muu saab k\u00e4rpida. Kuid Prometheus ja VictoriaMetrics ei toeta seda funktsionaalsust. Kas selle toetamine on plaanis? Kui ei, siis miks mitte?<\/em><\/p>\n<p><\/p>\n<p>Ait\u00e4h k\u00fcsimuse eest. Meie kasutajad k\u00fcsivad seda perioodiliselt. K\u00fcsitakse, millal me lisame toetalvise (downsampling) toe. Siin on mitu probleemi. Esiteks, iga kasutaja m\u00f5istab selle all <code>downsampling<\/code> midagi erinevat: m\u00f5ned soovivad saada mingit suvalist punkti m\u00e4\u00e4ratud intervallis, m\u00f5ned soovivad maksimaalseid, minimaalseid v\u00f5i keskmisi v\u00e4\u00e4rtusi. Kui teie andmebaasi kirjutavad andmeid mitmed s\u00fcsteemid, siis ei saa neid \u00fchtsalt kokku korjata. V\u00f5ib juhtuda, et iga s\u00fcsteemi jaoks on vajalik kasutada erinevat downsampling'i. Ja see on keeruline ellu viia.<\/p>\n<p><\/p>\n<p>Teiseks, VictoriaMetrics, nagu ka ClickHouse, on optimeeritud t\u00f6\u00f6tama suurte tooredate andmete kogustega, seet\u00f5ttu suudab ta t\u00f6\u00f6delda miljardit rida v\u00e4hem kui sekundiga, kui teie s\u00fcsteemis on palju tuuma. Aja rea punkte skaneerimine VictoriaMetrics'is on 50 000 000 punkti sekundis \u00fche tuuma kohta. Ja see j\u00f5udlus skaleerub olemasolevate tuumadega. St. kui teil on n\u00e4iteks 20 tuuma, siis saab skaneerida miljardi punkti sekundis. Ja see omadus VictoriaMetrics'is ja ClickHouse'is v\u00e4hendab vajadust downsampling'i j\u00e4rele.<\/p>\n<p><\/p>\n<p>Teine omadus on see, et VictoriaMetrics kompresseerib need andmed t\u00f5husalt. Keskmine tihedus productionis on 0,4 kuni 0,8 bitti punktide kohta. Iga punkt on ajatempleid + v\u00e4\u00e4rtused. Ja keskmiselt kompressitakse see alla \u00fche bitti. <\/p>\n<p><\/p>\n<p><em>Sergei. Mul on k\u00fcsimus. Mis on minimaalne salvestamise aeg?<\/em><\/p>\n<p><\/p>\n<p>\u00dcks millisekund. Hiljuti arutasime teiste ajarealiste andmebaaside arendajatega. Nende minimaalne ajakvant on \u00fcks sekund. N\u00e4iteks Graphites on ka \u00fcks sekund. OpenTSDB-s samuti \u00fcks sekund. InfluxDB-l on nanosekundi t\u00e4psus. VictoriaMetrics-il on \u00fcks millisekund, kuna Prometheuses on \u00fcks millisekund. VictoriaMetrics loodi algselt Prometheuse kaugandmete salvestuseks. Kuid n\u00fc\u00fcd suudab see salvestada andmeid ka teistest s\u00fcsteemidest. <\/p>\n<p><\/p>\n<p>Inimene, kellega ma r\u00e4\u00e4kisin, \u00fctles, et nende t\u00e4psus on sekundiline \u2014 see on piisav, kuna see s\u00f5ltub andmete t\u00fc\u00fcbist, mida ajajoonte andmebaasi salvestatakse. Kui need on DevOps-andmed v\u00f5i andmed infrastruktuurist, kus te kogute neid 30 sekundi v\u00f5i minuti intervalliga, siis piisab sekundilisest t\u00e4psusest, v\u00e4hem ei ole enam vajalik. Kuid kui te kogute neid suure sagedusega kauplemise s\u00fcsteemidest, siis vajate nanoskeedi t\u00e4psust.<\/p>\n<p><\/p>\n<p>Millisekundiline t\u00e4psus 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\u00f5rgsageduslikud kauplemiss\u00fcsteemid.<\/p>\n<p><\/p>\n<p><em>Ait\u00e4h! Ja veel \u00fcks k\u00fcsimus. Milline on \u00fchilduvus PromQL-iga?<\/em><\/p>\n<p><\/p>\n<p>T\u00e4ielik tagurpidi \u00fchilduvus. VictoriaMetrics toetab t\u00e4ielikult PromQL-i. Lisaks sellele lisab see veel t\u00e4iustatud funktsionaalsust PromQL-i, mis nimetatakse <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/VictoriaMetrics\/VictoriaMetrics\/wiki\/MetricsQL\">MetricsQL<\/a><\/noindex>. Selle t\u00e4iustatud funktsionaalsuse kohta on YouTube'is ettekande. R\u00e4\u00e4kisin Monitoring Meetup'il sel kevadel Peterburis.<\/p>\n<p><\/p>\n<p>Telegrami kanali <noindex><a rel=\"nofollow\" href=\"https:\/\/t.me\/VictoriaMetrics_ru1\">VictoriaMetrics<\/a><\/noindex>.<\/p>\n<p class=\"for_users_only_msg\">Ainult registreeritud kasutajad saavad k\u00fcsitluses osaleda. <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/auth\/login\/\">Logige sisse<\/a><\/noindex>, palun.<\/p>\n<h2 class=\"default-block__polling-title\">Mis takistab teid \u00fcleminekule VictoriaMetricsile kui pikaajalisele salvestuslahendusele Prometheusele? (Kirjutage kommentaaridesse, lisan k\u00fcsitlusse))<\/h2>\n<ul class=\"poll-result\">\n<li class=\"poll-result__item\">\n<p>                <strong class=\"poll-result__data-percent  poll-result__data-percent_winner\">71,4%<\/strong>Ei kasuta Prometheus5<\/p>\n<\/li>\n<li class=\"poll-result__item\">\n<p>                <strong class=\"poll-result__data-percent\">28,6%<\/strong>Ei teadnud VictoriaMetrics2-st<\/p>\n<\/li>\n<\/ul>\n<p>    H\u00e4\u00e4letas 7 kasutajat. 12 kasutajat olid erapooletud.<br \/>\n<br \/>Allikas: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/500844\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u0440\u0435\u0434\u043b\u0430\u0433\u0430\u044e \u043e\u0437\u043d\u0430\u043a\u043e\u043c\u0438\u0442\u044c\u0441\u044f \u0441 \u0440\u0430\u0441\u0448\u0438\u0444\u0440\u043e\u0432\u043a\u043e\u0439 \u0434\u043e\u043a\u043b\u0430\u0434\u0430 \u043a\u043e\u043d\u0446\u0430 2019 \u0433\u043e\u0434\u0430 \u0410\u043b\u0435\u043a\u0441\u0430\u043d\u0434\u0440\u0430 \u0412\u0430\u043b\u044f\u043b\u043a\u0438\u043d\u0430 &quot;Go optimizations in VictoriaMetrics&quot; VictoriaMetrics \u2014 \u0431\u044b\u0441\u0442\u0440\u0430\u044f \u0438 \u043c\u0430\u0441\u0448\u0442\u0430\u0431\u0438\u0440\u0443\u0435\u043c\u0430\u044f \u0421\u0423\u0411\u0414 \u0434\u043b\u044f \u0445\u0440\u0430\u043d\u0435\u043d\u0438\u044f \u0438 \u043e\u0431\u0440\u0430\u0431\u043e\u0442\u043a\u0438 \u0434\u0430\u043d\u043d\u044b\u0445 \u0432 \u0444\u043e\u0440\u043c\u0435 \u0432\u0440\u0435\u043c\u0435\u043d\u043d\u043e\u0433\u043e \u0440\u044f\u0434\u0430 (\u0437\u0430\u043f\u0438\u0441\u044c \u043e\u0431\u0440\u0430\u0437\u0443\u0435\u0442 \u0432\u0440\u0435\u043c\u044f \u0438 \u043d\u0430\u0431\u043e\u0440 \u0441\u043e\u043e\u0442\u0432\u0435\u0442\u0441\u0442\u0432\u0443\u044e\u0449\u0438\u0445 \u044d\u0442\u043e\u043c\u0443 \u0432\u0440\u0435\u043c\u0435\u043d\u0438 \u0437\u043d\u0430\u0447\u0435\u043d\u0438\u0439, \u043d\u0430\u043f\u0440\u0438\u043c\u0435\u0440, \u043f\u043e\u043b\u0443\u0447\u0435\u043d\u043d\u044b\u0445 \u0447\u0435\u0440\u0435\u0437 \u043f\u0435\u0440\u0438\u043e\u0434\u0438\u0447\u0435\u0441\u043a\u0438\u0439 \u043e\u043f\u0440\u043e\u0441 \u0441\u043e\u0441\u0442\u043e\u044f\u043d\u0438\u044f \u0434\u0430\u0442\u0447\u0438\u043a\u043e\u0432 \u0438\u043b\u0438 \u0441\u0431\u043e\u0440 \u043c\u0435\u0442\u0440\u0438\u043a). \u0412\u043e\u0442 \u0441\u0441\u044b\u043b\u043a\u0430 \u043d\u0430 \u0432\u0438\u0434\u0435\u043e \u044d\u0442\u043e\u0433\u043e \u0434\u043e\u043a\u043b\u0430\u0434\u0430 \u2014 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":80734,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-80733","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 4.9.10 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041f\u0440\u0435\u0434\u043b\u0430\u0433\u0430\u044e \u043e\u0437\u043d\u0430\u043a\u043e\u043c\u0438\u0442\u044c\u0441\u044f \u0441 \u0440\u0430\u0441\u0448\u0438\u0444\u0440\u043e\u0432\u043a\u043e\u0439 \u0434\u043e\u043a\u043b\u0430\u0434\u0430 \u043a\u043e\u043d\u0446\u0430 2019 \u0433\u043e\u0434\u0430 \u0410\u043b\u0435\u043a\u0441\u0430\u043d\u0434\u0440\u0430 \u0412\u0430\u043b\u044f\u043b\u043a\u0438\u043d\u0430 &quot;Go optimizations in VictoriaMetrics&quot; VictoriaMetrics \u2014 \u0431\u044b\u0441\u0442\u0440\u0430\u044f \u0438 \u043c\u0430\u0441\u0448\u0442\u0430\u0431\u0438\u0440\u0443\u0435\u043c\u0430\u044f \u0421\u0423\u0411\u0414 \u0434\u043b\u044f \u0445\u0440\u0430\u043d\u0435\u043d\u0438\u044f \u0438 \u043e\u0431\u0440\u0430\u0431\u043e\u0442\u043a\u0438 \u0434\u0430\u043d\u043d\u044b\u0445 \u0432 \u0444\u043e\u0440\u043c\u0435 \u0432\u0440\u0435\u043c\u0435\u043d\u043d\u043e\u0433\u043e \u0440\u044f\u0434\u0430 (\u0437\u0430\u043f\u0438\u0441\u044c \u043e\u0431\u0440\u0430\u0437\u0443\u0435\u0442 \u0432\u0440\u0435\u043c\u044f \u0438 \u043d\u0430\u0431\u043e\u0440 \u0441\u043e\u043e\u0442\u0432\u0435\u0442\u0441\u0442\u0432\u0443\u044e\u0449\u0438\u0445 \u044d\u0442\u043e\u043c\u0443 \u0432\u0440\u0435\u043c\u0435\u043d\u0438 \u0437\u043d\u0430\u0447\u0435\u043d\u0438\u0439, \u043d\u0430\u043f\u0440\u0438\u043c\u0435\u0440, \u043f\u043e\u043b\u0443\u0447\u0435\u043d\u043d\u044b\u0445 \u0447\u0435\u0440\u0435\u0437 \u043f\u0435\u0440\u0438\u043e\u0434\u0438\u0447\u0435\u0441\u043a\u0438\u0439 \u043e\u043f\u0440\u043e\u0441 \u0441\u043e\u0441\u0442\u043e\u044f\u043d\u0438\u044f \u0434\u0430\u0442\u0447\u0438\u043a\u043e\u0432 \u0438\u043b\u0438 \u0441\u0431\u043e\u0440 \u043c\u0435\u0442\u0440\u0438\u043a). \u0412\u043e\u0442 \u0441\u0441\u044b\u043b\u043a\u0430 \u043d\u0430 \u0432\u0438\u0434\u0435\u043e \u044d\u0442\u043e\u0433\u043e \u0434\u043e\u043a\u043b\u0430\u0434\u0430 \u2014\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/go-optimizations-in-victoriametrics-aleksandr-valyalkin\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 4.9.10\" \/>\n\t\t<meta property=\"og:locale\" content=\"et_EE\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47Go optimizations in VictoriaMetrics. \u0410\u043b\u0435\u043a\u0441\u0430\u043d\u0434\u0440 \u0412\u0430\u043b\u044f\u043b\u043a\u0438\u043d | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041f\u0440\u0435\u0434\u043b\u0430\u0433\u0430\u044e \u043e\u0437\u043d\u0430\u043a\u043e\u043c\u0438\u0442\u044c\u0441\u044f \u0441 \u0440\u0430\u0441\u0448\u0438\u0444\u0440\u043e\u0432\u043a\u043e\u0439 \u0434\u043e\u043a\u043b\u0430\u0434\u0430 \u043a\u043e\u043d\u0446\u0430 2019 \u0433\u043e\u0434\u0430 \u0410\u043b\u0435\u043a\u0441\u0430\u043d\u0434\u0440\u0430 \u0412\u0430\u043b\u044f\u043b\u043a\u0438\u043d\u0430 &quot;Go optimizations in VictoriaMetrics&quot; VictoriaMetrics \u2014 \u0431\u044b\u0441\u0442\u0440\u0430\u044f \u0438 \u043c\u0430\u0441\u0448\u0442\u0430\u0431\u0438\u0440\u0443\u0435\u043c\u0430\u044f \u0421\u0423\u0411\u0414 \u0434\u043b\u044f \u0445\u0440\u0430\u043d\u0435\u043d\u0438\u044f \u0438 \u043e\u0431\u0440\u0430\u0431\u043e\u0442\u043a\u0438 \u0434\u0430\u043d\u043d\u044b\u0445 \u0432 \u0444\u043e\u0440\u043c\u0435 \u0432\u0440\u0435\u043c\u0435\u043d\u043d\u043e\u0433\u043e \u0440\u044f\u0434\u0430 (\u0437\u0430\u043f\u0438\u0441\u044c \u043e\u0431\u0440\u0430\u0437\u0443\u0435\u0442 \u0432\u0440\u0435\u043c\u044f \u0438 \u043d\u0430\u0431\u043e\u0440 \u0441\u043e\u043e\u0442\u0432\u0435\u0442\u0441\u0442\u0432\u0443\u044e\u0449\u0438\u0445 \u044d\u0442\u043e\u043c\u0443 \u0432\u0440\u0435\u043c\u0435\u043d\u0438 \u0437\u043d\u0430\u0447\u0435\u043d\u0438\u0439, \u043d\u0430\u043f\u0440\u0438\u043c\u0435\u0440, \u043f\u043e\u043b\u0443\u0447\u0435\u043d\u043d\u044b\u0445 \u0447\u0435\u0440\u0435\u0437 \u043f\u0435\u0440\u0438\u043e\u0434\u0438\u0447\u0435\u0441\u043a\u0438\u0439 \u043e\u043f\u0440\u043e\u0441 \u0441\u043e\u0441\u0442\u043e\u044f\u043d\u0438\u044f \u0434\u0430\u0442\u0447\u0438\u043a\u043e\u0432 \u0438\u043b\u0438 \u0441\u0431\u043e\u0440 \u043c\u0435\u0442\u0440\u0438\u043a). \u0412\u043e\u0442 \u0441\u0441\u044b\u043b\u043a\u0430 \u043d\u0430 \u0432\u0438\u0434\u0435\u043e \u044d\u0442\u043e\u0433\u043e \u0434\u043e\u043a\u043b\u0430\u0434\u0430 \u2014\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/go-optimizations-in-victoriametrics-aleksandr-valyalkin\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-05-08T11:42:31+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-05-08T11:42:31+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Go optimizations in VictoriaMetrics. Aleksandr Valjalkin | ProHoster","description":"Soovitan tutvuda 2019. aasta l\u00f5pus Aleksandr Valjalkini ettekande \"Go optimizations in VictoriaMetrics\" sisukokkuv\u00f5ttega. VictoriaMetrics on kiire ja skaleeritav andmebaas ajastute andmete salvestamiseks ja t\u00f6\u00f6tlemiseks (andmed koosnevad ajast ja sellele ajale vastavatest v\u00e4\u00e4rtustest, n\u00e4iteks andurite seisundi perioodilise k\u00fcsitluse v\u00f5i m\u00f5\u00f5dikute kogumise kaudu saadud). Siin on link selle ettekande videole \u2014","canonical_url":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/go-optimizations-in-victoriametrics-aleksandr-valyalkin","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"et_EE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47Go optimizations in VictoriaMetrics. \u0410\u043b\u0435\u043a\u0441\u0430\u043d\u0434\u0440 \u0412\u0430\u043b\u044f\u043b\u043a\u0438\u043d | ProHoster","og:description":"\u041f\u0440\u0435\u0434\u043b\u0430\u0433\u0430\u044e \u043e\u0437\u043d\u0430\u043a\u043e\u043c\u0438\u0442\u044c\u0441\u044f \u0441 \u0440\u0430\u0441\u0448\u0438\u0444\u0440\u043e\u0432\u043a\u043e\u0439 \u0434\u043e\u043a\u043b\u0430\u0434\u0430 \u043a\u043e\u043d\u0446\u0430 2019 \u0433\u043e\u0434\u0430 \u0410\u043b\u0435\u043a\u0441\u0430\u043d\u0434\u0440\u0430 \u0412\u0430\u043b\u044f\u043b\u043a\u0438\u043d\u0430 &quot;Go optimizations in VictoriaMetrics&quot; VictoriaMetrics \u2014 \u0431\u044b\u0441\u0442\u0440\u0430\u044f \u0438 \u043c\u0430\u0441\u0448\u0442\u0430\u0431\u0438\u0440\u0443\u0435\u043c\u0430\u044f \u0421\u0423\u0411\u0414 \u0434\u043b\u044f \u0445\u0440\u0430\u043d\u0435\u043d\u0438\u044f \u0438 \u043e\u0431\u0440\u0430\u0431\u043e\u0442\u043a\u0438 \u0434\u0430\u043d\u043d\u044b\u0445 \u0432 \u0444\u043e\u0440\u043c\u0435 \u0432\u0440\u0435\u043c\u0435\u043d\u043d\u043e\u0433\u043e \u0440\u044f\u0434\u0430 (\u0437\u0430\u043f\u0438\u0441\u044c \u043e\u0431\u0440\u0430\u0437\u0443\u0435\u0442 \u0432\u0440\u0435\u043c\u044f \u0438 \u043d\u0430\u0431\u043e\u0440 \u0441\u043e\u043e\u0442\u0432\u0435\u0442\u0441\u0442\u0432\u0443\u044e\u0449\u0438\u0445 \u044d\u0442\u043e\u043c\u0443 \u0432\u0440\u0435\u043c\u0435\u043d\u0438 \u0437\u043d\u0430\u0447\u0435\u043d\u0438\u0439, \u043d\u0430\u043f\u0440\u0438\u043c\u0435\u0440, \u043f\u043e\u043b\u0443\u0447\u0435\u043d\u043d\u044b\u0445 \u0447\u0435\u0440\u0435\u0437 \u043f\u0435\u0440\u0438\u043e\u0434\u0438\u0447\u0435\u0441\u043a\u0438\u0439 \u043e\u043f\u0440\u043e\u0441 \u0441\u043e\u0441\u0442\u043e\u044f\u043d\u0438\u044f \u0434\u0430\u0442\u0447\u0438\u043a\u043e\u0432 \u0438\u043b\u0438 \u0441\u0431\u043e\u0440 \u043c\u0435\u0442\u0440\u0438\u043a). \u0412\u043e\u0442 \u0441\u0441\u044b\u043b\u043a\u0430 \u043d\u0430 \u0432\u0438\u0434\u0435\u043e \u044d\u0442\u043e\u0433\u043e \u0434\u043e\u043a\u043b\u0430\u0434\u0430 \u2014","og:url":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/go-optimizations-in-victoriametrics-aleksandr-valyalkin","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-05-08T11:42:31+00:00","article:modified_time":"2020-05-08T11:42:31+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"80733","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 16:12:22","updated":"2022-09-29 05:16:51"},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/80733","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/comments?post=80733"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/80733\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media\/80734"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media?parent=80733"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/categories?post=80733"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/tags?post=80733"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}