VictoriaMetrics-də optimallaşdırmalara keçin. Aleksandr Valyalkin

Alexander Valyalkinin 2019-cu ilin sonu hesabatının transkriptini oxumağı təklif edirəm "VictoriaMetrics-də optimallaşdırmalara keçin"

VictoriaMetrics - məlumatların vaxt seriyası şəklində saxlanması və emalı üçün sürətli və genişlənə bilən DBMS (bir qeyd, bu vaxta uyğun gələn bir vaxt və dəyərlər toplusunu təşkil edir, məsələn, sensorların və ya sensorların vəziyyətinin dövri sorğusu nəticəsində əldə edilir. ölçülər toplusu).

Bu hesabatın videosuna keçid - https://youtu.be/MZ5P21j_HLE

Slaydlar

Özünüz haqqında bizə məlumat verin. Mən Aleksandr Valyalkinəm. Budur mənim github hesabım. Mən Go və performans optimallaşdırması ilə maraqlanıram. Çox sayda faydalı və çox olmayan kitabxanalar yazdı. Ya ilə başlayırlar fast, və ya ilə quick prefiks.

Hazırda VictoriaMetrics üzərində işləyirəm. Bu nədir və mənim orada nə işim var? Bu təqdimatda bu haqda danışacağam.

Hesabatın konturu belədir:

• Əvvəlcə sizə VictoriaMetrics-in nə olduğunu söyləyəcəyəm.
• Onda sizə zaman seriyalarının nə olduğunu söyləyəcəyəm.
• Sonra zaman seriyası verilənlər bazasının necə işlədiyini sizə xəbər verəcəyəm.
• Sonra verilənlər bazasının arxitekturası haqqında danışacağam: nədən ibarətdir.
• Və sonra VictoriaMetrics-də olan optimallaşdırmalara keçək. Bunlar ters çevrilmiş indeks üçün optimallaşdırma və Go bitset tətbiqi üçün optimallaşdırmadır.

Tamaşaçılardan hər kəs VictoriaMetrics nədir? Vay, çoxları artıq bilir. Bu yaxşı xəbərdir. Bilməyənlər üçün bu, zaman seriyaları üçün verilənlər bazasıdır. O, ClickHouse arxitekturasına, bəzi ClickHouse tətbiqi təfərrüatlarına əsaslanır. Məsələn, MergeTree, bütün mövcud prosessor nüvələrində paralel hesablamalar və prosessor keşində yerləşdirilən məlumat blokları üzərində işləməklə performansın optimallaşdırılması.

VictoriaMetrics digər zaman seriyası verilənlər bazaları ilə müqayisədə məlumatların ən yaxşı sıxılmasını təmin edir.

O, şaquli olaraq miqyaslanır - yəni bir kompüterə daha çox prosessor, daha çox RAM əlavə edə bilərsiniz. VictoriaMetrics bu mövcud resurslardan uğurla istifadə edəcək və xətti performansı yaxşılaşdıracaq.

Həmçinin, VictoriaMetrics üfüqi tərəzi - yəni VictoriaMetrics klasterinə əlavə qovşaqlar əlavə edə bilərsiniz və onun performansı demək olar ki, xətti artacaq.

Təxmin etdiyiniz kimi VictoriaMetrics sürətli verilənlər bazasıdır, çünki başqalarını yaza bilmirəm. Və bu Go-da yazılmışdır, ona görə də bu görüşdə bu barədə danışıram.

Zaman seriyasının nə olduğunu kim bilir? O da çox adam tanıyır. Zaman seriyası cütlər seriyasıdır (timestamp, значение)bu cütlərin zamana görə çeşidləndiyi yer. Dəyər üzən nöqtəli nömrədir - float64.

Hər bir zaman seriyası bir açarla unikal şəkildə müəyyən edilir. Bu açar nədir? O, boş olmayan açar-dəyər cütlərindən ibarətdir.

Burada bir zaman seriyasına bir nümunə var. Bu seriyanın açarı cütlərin siyahısıdır: __name__="cpu_usage" metrikanın adıdır, instance="my-server" bu metrikanın toplandığı kompüterdir, datacenter="us-east" - bu, bu kompüterin yerləşdiyi məlumat mərkəzidir.

Üç açar-dəyər cütündən ibarət vaxt seriyasının adını aldıq. Bu açar cütlərin siyahısına uyğundur (timestamp, value). t1, t3, t3, ..., tN vaxt nişanlarıdır, 10, 20, 12, ..., 15 uyğun dəyərlərdir. Bu, verilmiş sıra üçün cari cpu-istifadəsidir.

Zaman sıralarından harada istifadə etmək olar? Kiminsə fikri varmı?

• DevOps-da siz CPU, RAM, şəbəkə, rps, səhvlər və s. ölçə bilərsiniz.
• IoT - biz temperaturu, təzyiqi, coğrafi koordinatları və başqa bir şeyi ölçə bilərik.
• Həmçinin maliyyə - biz bütün növ səhmlərin və valyutaların qiymətlərinə nəzarət edə bilərik.
• Bundan əlavə, fabriklərdə istehsal proseslərinin monitorinqində zaman sıralarından istifadə edilə bilər. Robotlar üçün külək turbinlərinə nəzarət etmək üçün VictoriaMetrics istifadə edən istifadəçilərimiz var.
• Həmçinin, zaman sıraları müxtəlif cihazların sensorlarından məlumat toplamaq üçün faydalıdır. Məsələn, mühərrik üçün; təkər təzyiqini ölçmək üçün; sürəti, məsafəni ölçmək; benzin sərfiyyatının ölçülməsi üçün və s.
• Həmçinin, zaman seriyası təyyarələri izləmək üçün istifadə edilə bilər. Hər bir təyyarədə müxtəlif təyyarə sağlamlıq parametrləri üçün zaman sıralarını toplayan qara qutu var. Zaman sıraları aerokosmik sənayedə də istifadə olunur.
• Sağlamlıq qan təzyiqi, nəbz və s.

Ola bilsin ki, hələ də unutduğum proqramlar var, amma ümid edirəm ki, müasir dünyada zaman sıralarının aktiv şəkildə istifadə olunduğunu başa düşürsünüz. Və onların istifadəsi ildən-ilə artır.

Zaman seriyası verilənlər bazası nə üçündür? Niyə vaxt seriyalarını saxlamaq üçün müntəzəm əlaqəli verilənlər bazasından istifadə edə bilmirsiniz?

Çünki zaman sıraları adətən adi verilənlər bazalarında saxlanması və işlənməsi çətin olan böyük həcmdə informasiyanı ehtiva edir. Beləliklə, zaman seriyaları üçün xüsusi verilənlər bazaları meydana çıxdı. Bu bazalar xalları effektiv şəkildə saxlayır (timestamp, value) verilmiş açarla. Onlar saxlanılan məlumatları açar, bir açar-dəyər cütü və ya bir neçə belə cüt və ya regexp ilə oxumaq üçün API təmin edir. Məsələn, siz Amerikadakı məlumat mərkəzində bütün xidmətlərinizin CPU yükünü tapmaq istəyirsiniz, onda bu psevdosorğudan istifadə etməlisiniz.

Tipik olaraq, zaman seriyası verilənlər bazaları ixtisaslaşdırılmış sorğu dilləridir, çünki zaman seriyası üçün SQL yaxşı uyğun deyil. SQL-i dəstəkləyən verilənlər bazası olsa da, bu, çox yaxşı uyğun deyil. kimi daha yaxşı uyğun sorğu dilləri PromQL, InfluxQL, Flux, Q. Ümid edirəm kimsə bu dillərdən heç olmasa birini eşitmişdir. Yəqin ki, bir çoxunuz PromQL haqqında eşitmisiniz. Bu Prometey sorğu dilidir.

VictoriaMetrics-dən nümunə kimi istifadə etməklə, zaman seriyası üçün müasir verilənlər bazasının arxitekturasının necə göründüyü budur.

İki hissədən ibarətdir. Bu, ters çevrilmiş indeks və zaman seriyası dəyərləri üçün mağazadır. Bu depolar ayrıdır.

Verilənlər bazasına yeni bir qeyd daxil olduqda, verilmiş dəst üçün zaman seriyası identifikatorunu tapmaq üçün əvvəlcə tərs indeksə daxil oluruq. label=value bu metrik üçün. Biz bu identifikatoru tapırıq və dəyəri məlumat anbarında saxlayırıq.

TSDB-dən məlumat almaq üçün bəzi sorğu daxil olduqda, biz ilk növbədə tərs indeksə qalxırıq. Hər şeyi alırıq timeseries_ids verilmiş dəstlə uyğun gələn qeydlər label=value. Və sonra bütün lazımi məlumatları indeksləşdirilmiş məlumat anbarından alırıq timeseries_ids.

Zaman seriyası verilənlər bazasının daxil olan seçmə sorğusunu necə idarə etdiyinə dair bir nümunəyə baxaq.

• Hər şeydən əvvəl o, hər şeyi alır timeseries_ids verilmiş cütləri ehtiva edən tərs indeksdən label=value, və ya verilmiş müntəzəm ifadəni təmin edin.
• Sonra tapılan üçün müəyyən bir vaxt intervalında məlumat anbarından bütün məlumat nöqtələrini alır timeseries_ids.
• Bundan sonra verilənlər bazası istifadəçinin istəyinə uyğun olaraq bu məlumat nöqtələri üzərində bəzi hesablamalar aparır. Və bundan sonra cavabı qaytarır.

Bu təqdimatda sizə birinci hissə haqqında məlumat verəcəyəm. Bu axtarışdır timeseries_ids ters çevrilmiş indekslə. İkinci hissə və üçüncü hissə haqqında daha sonra baxa bilərsiniz VictoriaMetrics mənbələri, ya da başqa hesabatlar hazırlayana qədər gözləyin 🙂

Ters çevrilmiş indekslə başlayaq. Çoxlarına bu sadə görünə bilər. Ters çevrilmiş indeksin nə olduğunu və necə işlədiyini kim bilir? Oh, daha çox insan deyil. Bunun nə olduğunu anlamağa çalışaq.

Əslində hər şey sadədir. Bu, sadəcə olaraq, açarı dəyərlə əlaqələndirən lüğətdir. Açar nədir? Bu cütlük label=valueHara label и value xətlərdir. Və dəyərlər bir sıradır timeseries_ids, verilmiş cüt daxildir label=value.

Ters çevrilmiş indeks hər şeyi tez tapmağa imkan verir timeseries_ids, vermişlər label=value.

O, həm də tez tapmağa imkan verir timeseries_ids çox cüt üçün zaman seriyası label=value, və ya cütlər üçün label=regexp. Bu necə baş verir? Çoxluğun kəsişməsini tapmaqla timeseries_ids hər cüt üçün label=value.

Ters çevrilmiş indeksin müxtəlif tətbiqlərini nəzərdən keçirin. Ən sadə sadəlövh tətbiqdən başlayaq. O, belə görünür.

Function getMetricIDs sətirlərin siyahısını alır. Hər bir xətt ehtiva edir label=value. Bu funksiya siyahı qaytarır metricIDs.

Bu necə işləyir? Burada qlobal dəyişən var invertedIndex. Bu normal lüğətdirmap) intləri dilimləmək üçün sətri xəritələndirəcək. Xətt ehtiva edir label=value.

Funksiyanın həyata keçirilməsi: almaq metricIDs birinci üçün label=value, sonra bütün qalanları keçin label=value, alırıq metricIDs onlar üçün. Və funksiyanı çağırın intersectInts, aşağıda müzakirə olunacaq. Və bu funksiya bu siyahıların kəsişməsini qaytarır.

Gördüyünüz kimi, ters çevrilmiş indeksin həyata keçirilməsi çox mürəkkəb deyil. Ancaq bu sadəlövh bir tətbiqdir. Onun çatışmazlıqları nələrdir? Sadəlövh tətbiqin əsas çatışmazlığı ondan ibarətdir ki, biz belə bir tərs indeksi RAM-da saxlayırıq. Tətbiqi yenidən başlatdıqdan sonra bu indeksi itiririk. Bu indeksi diskdə saxlamaq mümkün deyil. Verilənlər bazası üçün belə bir ters çevrilmiş indeks çətin uyğun gəlir.

İkinci çatışmazlıq da yaddaşla bağlıdır. Ters çevrilmiş indeks RAM-a uyğun olmalıdır. Əgər o, RAM-ın ölçüsünü keçərsə, o zaman aydındır ki, yaddaşdan kənar xəta alacağıq. Və proqram işləməyəcək.

kimi hazır həllərdən istifadə etməklə bu problemi həll etmək olar Səviyyə DBVə ya RocksDB.

Bir sözlə, bizə üç şeyi tez bir zamanda etməyə imkan verən verilənlər bazası lazımdır.

• İlk əməliyyat yazmaqdır ключ-значение bu bazaya. O, bunu çox tez edir. ключ-значение ixtiyari sətirlərdir.
• İkinci əməliyyat verilmiş açarla dəyərin sürətli axtarışıdır.
• Üçüncü əməliyyat isə verilmiş prefikslə bütün dəyərlərin sürətli axtarışıdır.

LevelDB və RocksDB - Bu verilənlər bazaları Google və Facebook tərəfindən hazırlanmışdır. İlk olaraq LevelDB gəldi. Sonra Facebook-dan olan uşaqlar LevelDB-ni götürdülər və onu təkmilləşdirməyə başladılar, RocksDB-ni yaratdılar. İndi demək olar ki, bütün daxili verilənlər bazaları Facebook daxilində RocksDB-də işləyir, o cümlədən RocksDB və MySQL-ə köçürülür. Adını qoydular myrocks.

Ters çevrilmiş indeks LevelDB istifadə edərək həyata keçirilə bilər. Bunu necə etmək olar? Biz açar kimi saxlayırıq label=value. Və bir dəyər olaraq - bir cütün olduğu zaman seriyasının identifikatoru label=value.

Bu cütlə çoxlu zaman seriyalarımız varsa label=value, onda bu verilənlər bazasında eyni açar və fərqli olan çoxlu sıralar olacaq timeseries_ids. Hamısının siyahısını əldə etmək üçün timeseries_idsbununla başlayır label=prefix, biz bu verilənlər bazasının optimallaşdırıldığı diapazonu skan edirik. Yəni, ilə başlayan bütün sətirləri seçirik label=prefix və lazım olanı əldə edin timeseries_ids.

Bu, Go-da necə görünəcəyinin bir nümunəsidir. Bizdə ters çevrilmiş indeks var. Bu LevelDB-dir.

Funksiya sadəlövh icra ilə eynidir. Demək olar ki, sətir-sətir sadəlövh tətbiqi təkrarlayır. Yeganə məqam odur ki, istinad etmək yerinə map ters çevrilmiş indeksə müraciət edirik. Birincisi üçün bütün dəyərləri alırıq label=value. Sonra bütün qalan cütlərdən keçirik label=value və onlar üçün müvafiq metricID dəstlərini əldə edin. Sonra kəsişməni tapırıq.

Hər şey yaxşı görünür, lakin bu həllin çatışmazlıqları var. VictoriaMetrics əvvəlcə LevelDB-yə əsaslanan ters çevrilmiş indeks tətbiq etdi. Amma sonda ondan imtina etməli oldum.

Niyə? Çünki LevelDB sadəlövh tətbiqdən daha yavaşdır. Sadə bir tətbiqdə, verilmiş bir açar üçün dərhal bütün dilimi alırıq metricIDs. Bu, çox sürətli bir əməliyyatdır - bütün dilim istifadəyə hazırdır.

LevelDB-də, hər bir funksiya çağırışında GetValues ilə başlayan bütün sətirləri keçmək lazımdır label=value. Və hər bir xətt üçün dəyəri alın timeseries_ids. Belələrindən timeseries_ids bunlardan bir dilim yığın timeseries_ids. Aydındır ki, bu, adi xəritəyə açarla daxil olmaqdan daha yavaşdır.

İkinci çatışmazlıq LevelDB-nin C-də yazılmasıdır. Go-dan C funksiyalarına daxil olmaq çox sürətli deyil. Bunun üçün yüzlərlə nanosaniyə vaxt lazımdır. Bu o qədər də sürətli deyil, çünki 1-5 nanosaniyə alan go-da yazılan adi funksiya çağırışı ilə müqayisədə performans fərqi onlarla dəfədir. VictoriaMetrics üçün bu, ölümcül bir qüsur idi 🙂

Beləliklə, ters çevrilmiş indeksin öz tətbiqini yazdım. Və ona zəng etdi birləşdirin.

Mergeset MergeTree məlumat strukturuna əsaslanır. Bu məlumat strukturu ClickHouse-dan götürülmüşdür. Aydındır ki, birləşmə dəsti sürətli axtarış üçün optimallaşdırılmalıdır timeseries_ids verilmiş açarla. Mergeset tamamilə Go-da yazılmışdır. Sən görə bilərsən GitHub-da VictoriaMetrics mənbələri. Birləşmənin tətbiqi qovluqdadır /lib/mergeset. Orada nə baş verdiyini anlamağa cəhd edə bilərsiniz.

Mergeset API LevelDB və RocksDB ilə çox oxşardır. Yəni, orada yeni qeydləri tez saxlamağa və verilən prefikslə qeydləri tez seçməyə imkan verir.

Birləşmənin mənfi cəhətləri haqqında daha sonra danışacağıq. İndi inverted indeksi həyata keçirərkən istehsalda VictoriaMetrics ilə bağlı problemlər haqqında danışaq.

Niyə yarandılar?

Birinci səbəb yüksək boşluq dərəcəsidir. Rus dilinə tərcümə edildikdə, bu, zaman sıralarında tez-tez dəyişiklikdir. Bu zaman seriyasının bitdiyi və yeni seriyanın başladığı və ya bir çox yeni zaman seriyasının başladığı zamandır. Və bu tez-tez olur.

İkinci səbəb vaxt seriyalarının çoxluğudur. Əvvəlcə monitorinq populyarlıq qazananda zaman seriyalarının sayı az idi. Məsələn, hər bir kompüterdə prosessorun, yaddaşın, şəbəkənin və diskin yükünü izləmək lazımdır. Hər kompüter üçün 4 zaman seriyası. Tutaq ki, sizdə 100 kompüter və 400 zaman seriyası var. Bu çox azdır.

Zaman keçdikcə insanlar daha təfərrüatlı məlumatların ölçülə biləcəyi fikrini ortaya atdılar. Məsələn, bütün prosessorun deyil, hər bir prosessor nüvəsinin yükünü ayrıca ölçmək. Əgər 40 prosessor nüvəniz varsa, deməli, prosessor yükünü ölçmək üçün 40 dəfə çox vaxt seriyanız var.

Ancaq bu hamısı deyil. Hər bir prosessor nüvəsi bir neçə vəziyyətə malik ola bilər, məsələn, boş olduqda boşdur. İstifadəçi məkanında işləməklə yanaşı, nüvə məkanında və digər dövlətlərdə də işləyin. Və hər bir belə vəziyyət ayrıca zaman seriyası kimi də ölçülə bilər. Bu, əlavə olaraq sıraların sayını 7-8 dəfə artırır.

Bir metrikdən yalnız bir kompüter üçün 40 x 8 = 320 ölçü əldə etdik. 100-ə vururuq, 32 əvəzinə 000 alırıq.

Sonra Kubernetes gəldi. Və bu, yenə də vəziyyəti daha da pisləşdirdi, çünki Kubernetes-də bir çox müxtəlif xidmətlər yerləşdirilə bilər. Kubernetesdəki hər bir xidmət çoxlu podlardan ibarətdir. Və bütün bunlara nəzarət etmək lazımdır. Bundan əlavə, xidmətlərinizin yeni versiyalarının daimi yerləşdirilməsimiz var. Hər yeni versiya üçün yeni zaman seriyası yaratmalısınız. Nəticədə, zaman sıralarının sayı eksponent olaraq artır və biz yüksək kardinallıq adlanan çoxlu sayda zaman seriyası problemi ilə qarşılaşırıq. VictoriaMetrics bunu digər zaman seriyası verilənlər bazaları ilə müqayisədə yaxşı edir.

Gəlin yüksək axsama dərəcəsinə daha yaxından nəzər salaq. İstehsalda yüksək itkiyə səbəb nədir? Çünki etiketlərin və etiketlərin bəzi mənaları daim dəyişir.

Məsələn, konsepsiyası olan Kubernetes-i götürək deployment, yəni tətbiqinizin yeni versiyası təqdim edildikdə. Nədənsə, Kubernetes tərtibatçıları etiketə yerləşdirmə identifikatorunu əlavə etmək qərarına gəldilər.

Nəyə gətirib çıxardı? Hər yeni yerləşdirmə ilə bütün köhnə vaxt seriyalarının kəsildiyi və onların əvəzinə yeni zaman seriyalarının yeni etiket dəyəri ilə başlayacağına deployment_id. Belə sıralar yüz minlərlə, hətta milyonlarla ola bilər.

Bütün bunların mühüm xüsusiyyəti ondan ibarətdir ki, zaman seriyalarının ümumi sayı artır, lakin hazırda aktiv olan, üzərində məlumat gələn zaman seriyalarının sayı sabit qalır. Bu vəziyyət yüksək tükənmə dərəcəsi adlanır.

Yüksək axsama dərəcəsinin əsas problemi müəyyən vaxt intervalı üçün verilmiş etiketlər dəsti üçün bütün zaman seriyaları üçün sabit axtarış sürətini təmin etməkdir. Bu adətən son saat və ya son gün üçün vaxt intervalıdır.

Bu problemi necə həll etmək olar? Birinci variant budur. Bu, ters çevrilmiş indeksi müstəqil zaman hissələrinə bölmək üçündür. Yəni müəyyən vaxt intervalı keçir, biz ters çevrilmiş cari indekslə işi bitiririk. Və biz yeni tərs indeks yaradırıq. Başqa bir zaman intervalı keçir, biz başqa birini və birini yaradırıq.

Və bu ters çevrilmiş indekslərdən seçmə zamanı biz verilmiş intervala düşən ters çevrilmiş indekslər toplusunu tapırıq. Və buna uyğun olaraq, oradan zaman seriyasının id-sini seçirik.

Bu, resurslara qənaət edir, çünki verilmiş intervala düşməyən hissələrə baxmaq məcburiyyətində deyilik. Yəni, adətən, son bir saat üçün məlumatları seçsək, əvvəlki vaxt intervalları üçün sorğuları atlayırıq.

Bu problemin başqa bir həlli var. Bu, hər gün üçün həmin gün baş vermiş zaman seriyasının id-lərinin ayrıca siyahısını saxlamaq üçündür.

Bu həllin əvvəlki həlldən üstünlüyü ondan ibarətdir ki, biz zamanla yox olmayan zaman seriyası məlumatlarını təkrarlamırıq. Onlar daimidir və dəyişmir.

Dezavantaj ondan ibarətdir ki, belə bir həllin həyata keçirilməsi daha çətindir və düzəlişlər daha çətindir. Və VictoriaMetrics bu həlli seçdi. Tarixən belə olub. Bu həll də əvvəlki ilə müqayisədə özünü yaxşı göstərir. Çünki dəyişməyən, yəni zamanla yox olmayan zaman sıraları üçün hər bölmədə verilənləri dublikat etməli olduğunuz üçün bu həll həyata keçirilmədi. VictoriaMetrics ilk növbədə disk sahəsinin istehlakı üçün optimallaşdırılmışdır və əvvəlki tətbiq disk sahəsi istehlakını pisləşdirdi. Lakin bu tətbiq disk sahəsinin istehlakını minimuma endirmək üçün daha uyğundur, ona görə də seçilmişdir.

Mən onunla döyüşməli idim. Mübarizə ondan ibarət idi ki, bu tətbiqdə siz hələ də daha çox sayda seçməlisiniz timeseries_ids ters çevrilmiş indeks zamana bölündükdən daha çox məlumat üçün.

Bu problemi necə həll etdik? Biz bunu orijinal şəkildə həll etdik - bir identifikator əvəzinə inversiya edilmiş indeksin hər bir qeydində bir neçə zaman seriyası identifikatorunu saxlamaqla. yəni açar bizdədir label=value, hər zaman silsiləsində baş verir. İndi bir neçəsini saxlayırıq timeseries_ids bir girişdə.

Budur bir nümunə. Əvvəllər N girişimiz var idi, indi isə bütün digərləri ilə eyni prefiksə malik bir girişimiz var. Əvvəlki giriş üçün dəyər zaman seriyasının bütün id-lərini ehtiva edir.

Bu, belə tərs indeksin skan sürətini 10 dəfəyə qədər artırmağa imkan verdi. Və cache üçün yaddaş istehlakını azaltmağa icazə verildi, çünki indi simli saxlayırıq label=value yalnız bir dəfə cache birlikdə N dəfə. Kubernetesin oraya itələməyi xoşladığı teqlərdə və etiketlərdə saxlanan uzun xətləriniz varsa, bu xətt böyük ola bilər.

Ters çevrilmiş indeksin axtarışını sürətləndirmək üçün başqa bir seçim parçalanmadır. Bir əvəzinə bir neçə ters çevrilmiş indeks yaratmaq və açarla onlar arasında məlumatların bölünməsi. Bu dəstdir key=value buxar. Yəni, bir neçə prosessorda paralel olaraq sorğu verə biləcəyimiz bir neçə müstəqil tərs indeks alırıq. Əvvəlki tətbiqlər yalnız tək prosessor rejiminə, yəni məlumatların yalnız bir nüvədə skan edilməsinə icazə verirdi. Bu həll, ClickHouse-un bəyəndiyi kimi, eyni anda bir neçə nüvədə məlumatları skan etməyə imkan verir. Həyata keçirməyi planlaşdırdığımız budur.

İndi qayıdıb qoçlarımıza - kəsişmə funksiyasına timeseries_ids. Tətbiqlərin nə ola biləcəyini nəzərdən keçirək. Bu funksiya tapmaq imkanı verir timeseries_ids müəyyən bir dəst üçün label=value.

Birinci seçim sadəlövh bir tətbiqdir. İki yuvalanmış döngə. Burada funksiyanın girişinə çatırıq intersectInts iki dilim - a и b. Çıxışda, bu dilimlərin kəsişməsini bizə qaytarmalıdır.

Sadəlövh tətbiqi belə görünür. Dilimdən bütün dəyərləri təkrarlayırıq a, bu döngənin içərisində dilimin bütün dəyərlərindən keçirik b. Və onları müqayisə edirik. Əgər onlar uyğun gəlirsə, deməli, kəsişmə tapmışıq. Və saxla result.

Mənfi cəhətləri nələrdir? Kvadrat mürəkkəblik onun əsas çatışmazlığıdır. Məsələn, dilim ölçüləriniz varsa a и b hər biri bir milyon, onda bu funksiya heç vaxt sizə cavab qaytarmayacaq. Çünki bir trilyon iterasiya etməli olacaq ki, bu, hətta müasir kompüterlər üçün də çoxdur.

İkinci tətbiq xəritəyə əsaslanır. Xəritə yaradırıq. Dilimdən bütün dəyərləri bu xəritəyə qoyuruq a. Sonra dilimdən ayrı bir döngə keçirik b. Və bu dəyərin dilimdən olub olmadığını yoxlayın b xəritədə. Əgər varsa, onu nəticəyə əlavə edin.

Faydaları nələrdir? Üstünlük yalnız xətti mürəkkəbliyin olmasıdır. Yəni, funksiya böyük dilimlər üçün daha sürətli yerinə yetiriləcək. Milyonuncu dilim üçün bu funksiya əvvəlki funksiyada olduğu kimi trilyon iterasiyadan fərqli olaraq 2 milyon iterasiyada işləyəcək.

Dezavantaj isə odur ki, bu funksiya bu xəritəni yaratmaq üçün daha çox yaddaş tələb edir.

İkinci çatışmazlıq hashing üçün böyük bir yükdür. Bu çatışmazlıq çox açıq deyil. Və bizim üçün bu da çox açıq deyildi, ona görə də əvvəlcə VictoriaMetrics-də kəsişmənin həyata keçirilməsi xəritə vasitəsilə idi. Lakin sonra profilləşdirmə göstərdi ki, əsas prosessor vaxtı xəritəyə yazmaq və bu xəritədə dəyərin olub-olmadığını yoxlamağa sərf olunur.

Niyə bu yerlər CPU vaxtını itirir? Çünki bu sətirlərdə Go hashing əməliyyatı həyata keçirir. Yəni daha sonra HashMap-da verilmiş indeksə daxil olmaq üçün açardan hash hesablayır. Hash hesablama əməliyyatı onlarla nanosaniyə çəkir. Bu VictoriaMetrics üçün yavaşdır.

Bu iş üçün xüsusi olaraq optimallaşdırılmış bitset tətbiq etmək qərarına gəldim. İki dilimin kəsişməsi indi belə görünür. Burada bitset yaradırıq. Ona birinci dilimdən elementlər əlavə edirik. Sonra ikinci dilimdə bu elementlərin varlığını yoxlayırıq. Və onları nəticəyə əlavə edin. Yəni əvvəlki nümunədən demək olar ki, fərqlənmir. Yeganə odur ki, biz xəritəyə çağırışı burada xüsusi funksiyalarla əvəz etdik add и has.

İlk baxışdan belə görünür ki, əgər əvvəllər orada standart xəritə istifadə olunubsa, bu daha yavaş işləməlidir və sonra bəzi digər funksiyalar çağırılır, lakin profilləşdirmə bu şeyin VictoriaMetrics işi üçün standart xəritədən 10 dəfə sürətli olduğunu göstərir.

Bundan əlavə, xəritə tətbiqi ilə müqayisədə daha az yaddaş istifadə edir. Çünki biz burada səkkiz baytlıq dəyərlər əvəzinə bitləri saxlayırıq.

Belə bir həyata keçirilməsinin dezavantajı o qədər də açıq deyil, əhəmiyyətsiz deyil.

Çoxlarının fərqinə varmadığı başqa bir çatışmazlıq, bu tətbiqin bəzi hallarda yaxşı nəticə verməməsidir. Yəni, VictoriaMetrics zaman seriyasının id-lərinin kəsişməsi halı üçün konkret hal üçün optimallaşdırılmışdır. Bu o demək deyil ki, bütün hallar üçün uyğundur. Yanlış istifadə olunarsa, performans artımı deyil, yaddaş çatışmazlığı xətası və performansın yavaşlaması alacağıq.

Bu strukturun həyata keçirilməsini nəzərdən keçirin. Onu görmək istəyirsinizsə, o, VictoriaMetrics mənbələrində, qovluqdadır lib/uint64set. O, xüsusi olaraq VictoriaMetrics işi üçün optimallaşdırılıb timeseries_id 64 bitlik dəyərdir, burada ilk 32 bit əsasən sabitdir və yalnız sonuncu 32 bit dəyişir.

Bu məlumat strukturu diskdə saxlanmır, yalnız yaddaşda işləyir.

Budur onun API. Çox mürəkkəb deyil. API xüsusi olaraq VictoriaMetrics-in xüsusi istifadə vəziyyətinə uyğunlaşdırılmışdır. Yəni əlavə funksiyalar yoxdur. VictoriaMetrics tərəfindən açıq şəkildə istifadə olunan funksiyalar bunlardır.

Funksiyaları var add, yeni dəyərlər əlavə edir. Bir funksiyası var has, yeni dəyərləri yoxlayan. Və bir funksiyası var del, dəyərləri silən. Köməkçi funksiyası var len, dəstin ölçüsünü qaytarır. Funksiya clone dəsti klonlayır. Və funksiya appendto bu dəsti dilimə çevirir timeseries_ids.

Bu məlumat strukturunun tətbiqi necə görünür. Set iki elementdən ibarətdir:

• ItemsCount dəstdəki elementlərin sayını tez qaytarmaq üçün köməkçi sahədir. Biz bu köməkçi sahə olmadan edə bilərdik, lakin onu bura əlavə etməli olduq, çünki VictoriaMetrics tez-tez alqoritmlərində bitsetin uzunluğunu sorğulayır.

• İkinci sahədir buckets. Bu bir quruluşdan bir dilimdir bucket32. Hər bir struktur ehtiva edir hi sahə. Bunlar ən yaxşı 32 bitdir. Və iki dilim - b16his и buckets haqqında bucket16 strukturlar.

16 bitlik strukturun ikinci hissəsinin yuxarı 64 biti burada saxlanılır. Və bitsetlər burada hər baytın aşağı 16 biti üçün saxlanılır.

Bucket64 massivdən ibarətdir uint64. Uzunluq bu sabitlərdən istifadə etməklə hesablanır. Birində bucket16 maksimum saxlanıla bilər 2^16=65536 az. Bu 8-ə bölünsə, bu, 8 kilobaytdır. Yenə 8-ə bölün, 1000-dir uint64 məna. yəni. Bucket16 - bu bizim 8 kilobaytlıq quruluşumuzdur.

Yeni dəyər əlavə etmək üçün bu strukturun üsullarından birinin necə həyata keçirildiyini nəzərdən keçirək.

Hər şey ilə başlayır uint64 dəyərlər. Üst 32 biti hesablayırıq, alt 32 biti hesablayırıq. Hamısından keçirik buckets. Hər vedrədəki ilk 32 biti əlavə olunan dəyərlə müqayisə edin. Əgər onlar uyğun gəlirsə, onda biz funksiyanı çağırırıq add b32 strukturunda buckets. Və orada aşağı 32 bit əlavə edin. Və əgər qayıtsa true, onda bu o deməkdir ki, biz oraya belə bir dəyər əlavə etdik və bizdə belə bir dəyər yox idi. Qaytarsa false, onda belə bir dəyər artıq mövcud idi. Sonra strukturdakı elementlərin sayını artırırıq.

Düzgününü tapmasaydıq bucket istədiyiniz yüksək dəyərlə, sonra funksiyanı çağırırıq addAlloc, yeni edəcək bucket, onu vedrə quruluşuna əlavə edir.

Bu funksiyanın həyata keçirilməsidir b32.add. Əvvəlki icraya bənzəyir. Yüksək 16 bit, aşağı 16 bit hesablayırıq.

Sonra bütün ilk 16 bitdən keçirik. Uyğunluqlar tapırıq. Əgər uyğunluq varsa, növbəti səhifədə nəzərdən keçirəcəyimiz əlavə metodunu çağırırıq bucket16.

Və burada mümkün qədər optimallaşdırılmalı olan ən aşağı səviyyədir. üçün hesablayırıq uint64 dilim bitində də id dəyəri bitmask. Bu, bu bitin mövcudluğunu yoxlaya və ya təyin edə biləcəyiniz bu 64-bit dəyər üçün maskadır. Bu bitin təyin edilib-edilmədiyini yoxlayırıq və onu təyin edirik və mövcudluğu qaytarırıq. Budur, adi xəritələrlə müqayisədə zaman seriyalarının id-lərinin kəsişməsi əməliyyatını 10 dəfə sürətləndirməyə imkan verən tətbiqimiz.

Bu optimallaşdırmaya əlavə olaraq, VictoriaMetrics bir çox başqa optimallaşdırmalara malikdir. Bu optimallaşdırmaların əksəriyyəti bir səbəbdən əlavə edildi, lakin kodu istehsalda profilləşdirdikdən sonra.

Optimallaşdırmanın əsas qaydası budur - darboğaz olacağını düşünərək optimallaşdırma əlavə etməyin, çünki darboğazın olmayacağı ortaya çıxa bilər. Optimallaşdırma adətən kodun keyfiyyətini aşağı salır. Buna görə də, yalnız profilləşdirmədən sonra və tercihen istehsalda optimallaşdırmağa dəyər ki, bu real məlumatdır. Maraqlananlar üçün VictoriaMetrics mənbə koduna baxa və orada olan digər optimallaşdırmaları araşdıra bilərsiniz.

Bitset haqqında sualım var. C++ vektor bool tətbiqinə çox oxşardır, bitset optimallaşdırılmışdır. Tətbiqi oradan götürmüsünüz?

Xeyr, oradan deyil. Bu bit dəsti həyata keçirərkən mən VictoriaMetrics-də istifadə olunan bu id-lərin vaxt seriyalarının strukturu haqqında bilikləri rəhbər tutdum. Və onların strukturu elədir ki, ilk 32 bit əsasən sabitdir. Aşağıdakı 32 bit dəyişdirilə bilər. Bit nə qədər aşağı olsa, bir o qədər tez-tez dəyişə bilər. Buna görə də, bu tətbiq bu məlumat strukturu üçün optimallaşdırılmışdır. C++ tətbiqi, bildiyim qədər, ümumi vəziyyət üçün optimallaşdırılıb. Ümumi iş üçün optimallaşdırma etsəniz, bu, konkret bir iş üçün ən optimal olmayacaq deməkdir.

Aleksey Milovidin hesabatına baxmağı məsləhət görürəm. Təxminən bir ay əvvəl o, xüsusi ixtisaslar üçün ClickHouse-da optimallaşdırmalar haqqında danışdı. Sadəcə deyir ki, ümumi halda C++ tətbiqi və ya başqa bir tətbiq xəstəxanada orta hesabla yaxşı iş üçün uyğunlaşdırılıb. Üst 32 bitin əsasən sabit olduğunu bildiyimiz zaman, bizimki kimi xüsusi biliklər üçün xüsusi tətbiqdən daha pis çıxış edə bilər.

İkinci sualım var. InfluxDB-dən əsas fərq nədir?

Bir çox kardinal fərqlər var. Performans və yaddaş istehlakı baxımından, testlərdə InfluxDB yüksək kardinallıq zaman seriyası üçün 10 dəfə daha çox yaddaş istehlakı göstərir, məsələn, milyonlarla. Məsələn, VictoriaMetrics hər milyon aktiv sıra üçün 1 GB, InfluxDB isə 10 GB istehlak edir. Və bu, böyük fərqdir.

İkinci əsas fərq, InfluxDB-nin qəribə sorğu dillərinə sahib olmasıdır - Flux və InfluxQL. Onlarla müqayisədə zaman seriyaları ilə işləmək üçün çox əlverişli deyil PromQL, VictoriaMetrics tərəfindən dəstəklənir. PromQL Prometheus-un sorğu dilidir.

Başqa bir fərq, InfluxDB-nin bir az qəribə məlumat modelinə sahib olmasıdır, burada hər bir xətt fərqli etiketlər dəsti ilə bir neçə sahəni saxlaya bilər. Bu xətlər daha sonra bütün növ cədvəllərə bölünür. Bu əlavə fəsadlar bu baza ilə sonrakı işi çətinləşdirir. Onu saxlamaq və başa düşmək çətindir.

VictoriaMetrics-də hər şey daha sadədir. Orada hər bir zaman seriyası açar-dəyərdir. Dəyər - nöqtələr toplusudur (timestamp, value), və əsas dəstdir label=value. Sahələr və ölçülər arasında heç bir fərq yoxdur. Bu, hər hansı bir məlumatı seçməyə və sonra onu birləşdirməyə, əlavə etməyə, çıxmağa, vurmağa, bölməyə imkan verir, InfluxDB-dən fərqli olaraq, burada bildiyim qədər müxtəlif cərgələr arasında hesablamalar hələ də həyata keçirilmir. Həyata keçirilsə belə, çətindir, bir dəstə kod yazmalısan.

Aydınlaşdırıcı sualım var. Düzgün başa düşdüm ki, danışdığınız bir növ problem var, bu ters çevrilmiş indeks yaddaşa uyğun gəlmir, deməli, orada bölmələr gedir?

Birincisi, standart Go xəritəsində ters çevrilmiş indeksin sadəlövh tətbiqini göstərdim. Bu tətbiq verilənlər bazası üçün uyğun deyil, çünki bu ters çevrilmiş indeks diskdə saxlanmır və verilənlər bazası diskdə saxlamalıdır ki, bu məlumatlar yenidən başladıqdan sonra əlçatan olsun. Bu tətbiqetmədə tətbiqi yenidən başlatdığınız zaman ters çevrilmiş indeksiniz yox olacaq. Və siz bütün məlumatlara girişi itirəcəksiniz, çünki onu tapa bilməyəcəksiniz.

Salam! Hesabat üçün təşəkkür edirik! Mənim adım Paveldir. Mən Wildberriesdənəm. Sizə bir neçə sualım var. Sual bir. Sizcə, əgər siz tətbiqinizin arxitekturasını qurarkən və verilənlərin zamana görə bölünməsi zamanı fərqli bir prinsip seçmiş olsanız, o zaman axtarış zamanı məlumatların kəsişməsini yalnız bir bölmənin bir dövr üçün məlumat ehtiva etməsinə əsaslanaraq edə bilərdinizmi? vaxt , yəni bir vaxt intervalında və parçaların fərqli şəkildə səpələnməsindən narahat olmayacaqsınız? 2 nömrəli sual - bitset və hər şeylə oxşar alqoritm tətbiq etdiyiniz üçün, bəlkə prosessor təlimatlarından istifadə etməyə çalışdınız? Bəlkə belə optimallaşdırmaları sınamısınız?

İkincisinə cavab verəcəm. Biz hələ ora çatmamışıq. Amma ehtiyac olarsa, edəcəyik. İlk sual nə idi?

Siz iki ssenarini müzakirə etdiniz. Və daha mürəkkəb icrası olan ikincini seçdiklərini söylədilər. Və məlumatların zamana görə bölündüyü birinciyə üstünlük vermədilər.

Bəli. Birinci halda, indeksin ümumi həcmi daha böyük olardı, çünki hər bölmədə bütün bu bölmələr vasitəsilə davam edən zaman seriyaları üçün dublikat məlumatları saxlamalı olacaqdıq. Əgər zaman seriyaları üçün kiçik bir boşluq nisbətiniz varsa, yəni eyni seriyalar daim istifadə olunursa, birinci halda ikinci halla müqayisədə işğal edilmiş disk sahəsi baxımından daha çox itirəcəyik.

Və beləliklə - bəli, vaxta görə bölmə yaxşı seçimdir. Prometey bundan istifadə edir. Lakin Prometeyin başqa bir çatışmazlığı var. Bu məlumat hissələrini birləşdirərkən, bütün etiketlər və vaxt seriyaları üçün yaddaşda meta-məlumat saxlamalıdır. Buna görə də, əgər verilənlərin birləşdiyi böyükdürsə, VictoriaMetrics-dən fərqli olaraq birləşdirildikdə yaddaş istehlakı çox artır. Birləşmə zamanı VictoriaMetrics ümumiyyətlə yaddaş istehlak etmir, birləşdirilən məlumatların ölçüsündən asılı olmayaraq orada bir neçə kilobayt sərf olunur.

Sahib olduğunuz alqoritm yaddaşdan istifadə edir. Dəyərləri olan zaman seriyası işarələrini qeyd edir. Və bu yolla siz bir məlumat massivində və digərində qoşalaşmış mövcudluğu yoxlayırsınız. Və kəsişmənin olub-olmadığını başa düşürsən. Tipik olaraq, verilənlər bazaları bu əməliyyatların sadə mürəkkəbliyi səbəbindən cari dəyərini saxlayan və çeşidlənmiş məlumatlardan keçən kursorları, iteratorları həyata keçirir.

Nəyə görə biz verilənləri keçmək üçün kursorlardan istifadə etmirik?

Bəli.

Bizim LevelDB-də və ya birləşmədə, sadəcə çeşidlənmiş xətlər saxlanılır. Kursorla gəzə və kəsişməni tapa bilərik. Niyə istifadə etmirik? Çünki yavaşdır. Çünki kursorlar hər bir sətir üçün funksiya çağırmaq lazım olduğunu bildirir. Funksiya çağırışı 5 nanosaniyədir. Əgər 100 xəttiniz varsa, onda belə çıxır ki, biz yalnız bir funksiya çağırışına yarım saniyə sərf edirik.

Belə bir şey var, bəli. Və son sualım. Sual bir az qəribə səslənə bilər. Nə üçün məlumatların gəlişi zamanı bütün lazımi aqreqatları saymaq və lazımi formada saxlamaq mümkün deyil? VictoriaMetrics, ClickHouse və s. kimi bəzi sistemlərə daha sonra çox vaxt sərf etmək üçün nə üçün böyük həcmləri saxlamaq lazımdır?

Daha aydın olması üçün bir misal verəcəm. Deyək ki, kiçik bir oyuncaq sürətölçən necə işləyir? Bu, səyahət etdiyiniz məsafəni qeyd edir, onu hər zaman bir dəyərə, ikinci dəfəyə əlavə edir. Və bölür. Və orta sürət əldə edir. Siz təxminən eyni şeyi edə bilərsiniz. Tez bütün lazımi faktları əlavə edin.

Yaxşı, sualı başa düşdüm. Sizin nümunənizin yaşamaq üçün yeri var. Hansı aqreqatlara ehtiyacınız olduğunu bilirsinizsə, bu, ən yaxşı tətbiqdir. Ancaq problem ondadır ki, insanlar bu ölçüləri, bəzi məlumatları ClickHouse-da saxlayırlar və onlar hələ də gələcəkdə onları necə birləşdirəcəklərini və süzgəcdən keçirəcəklərini bilmirlər, ona görə də bütün xam məlumatları yadda saxlamalısınız. Ancaq bir şey hesablamalı olduğunuzu bilirsinizsə, onda bir dəstə xam dəyəri saxlamaq əvəzinə niyə hesablamayasınız? Ancaq bu, yalnız sizə lazım olanı dəqiq bildiyiniz halda olur.

Yeri gəlmişkən, zaman sıralarının saxlanması üçün verilənlər bazaları hesablama aqreqatlarını dəstəkləyir. Məsələn, Prometey dəstəkləyir qeyd qaydaları. Yəni hansı vahidlərə ehtiyacınız olduğunu bilsəniz edilə bilər. Bu hələ VictoriaMetrics-də mövcud deyil, lakin adətən Prometheus-dan əvvəl olur, burada bunu təkrar kodlaşdırma qaydalarında edə bilərsiniz.

Məsələn, əvvəlki işdə, son saatda sürüşmə pəncərəsində hadisələrin sayını saymalı idiniz. Problem ondadır ki, mən Go-da xüsusi bir tətbiq etməli oldum, yəni bu şeyi hesablamaq üçün bir xidmət. Bu xidmət son nəticədə qeyri-ciddi idi, çünki onu saymaq çətindir. Sabit vaxt intervallarında bəzi aqreqatları saymaq lazımdırsa, həyata keçirmək sadə ola bilər. Sürüşən pəncərədə hadisələri saymaq istəyirsinizsə, bu, göründüyü qədər asan deyil. Düşünürəm ki, bu hələ ClickHouse-da və ya timeseries verilənlər bazalarında həyata keçirilməyib, çünki həyata keçirmək çətindir.

Və daha bir sual. Biz sadəcə orta hesablama haqqında danışırdıq və xatırladım ki, bir vaxtlar Karbon arxa planı olan Qrafit kimi bir şey var idi. Və o, köhnə məlumatları necə incəltməyi bilirdi, yəni dəqiqədə bir nöqtə, saatda bir nöqtə və s. buraxın. Prinsipcə, bir ay ərzində xam məlumatlara ehtiyacımız varsa, bu olduqca rahatdır və qalan hər şeyi incələmək olar. həyata. Lakin Prometheus, VictoriaMetrics bu funksiyanı dəstəkləmir. Dəstəklənməsi planlaşdırılırmı? Əgər yoxsa, niyə də olmasın?

Sual üçün təşəkkürlər. İstifadəçilərimiz vaxtaşırı bunu soruşurlar. İncəlmə (aşağı seçmə) üçün dəstəyi nə vaxt əlavə edəcəyimizi soruşurlar. Burada bir sıra problemlər var. Birincisi, hər bir istifadəçi başa düşür downsampling özünəməxsus bir şey: kimsə verilmiş intervalda istənilən ixtiyari nöqtəni əldə etmək istəyir, kimsə maksimum, minimum, orta dəyərləri istəyir. Əgər bir çox sistem verilənlər bazanıza məlumat yazırsa, siz onları hamıya uyğun bir ölçüdə sıralaya bilməzsiniz. Hər bir sistem üçün fərqli decimation istifadə etməli olduğunuzu görə bilərsiniz. Və həyata keçirmək çətindir.

İkincisi odur ki, VictoriaMetrics, ClickHouse kimi, böyük miqdarda xam məlumatla işləmək üçün optimallaşdırılıb, ona görə də sisteminizdə çoxlu nüvələr varsa, bir saniyədən az müddətdə milyard cərgə keçə bilər. VictoriaMetrics-də vaxt seriyası nöqtələrinin skan edilməsi - hər nüvə üçün saniyədə 50 bal. Və bu performans mövcud nüvələrə qədər ölçülür. Yəni, məsələn, 000 nüvəniz varsa, saniyədə bir milyard nöqtəni skan edəcəksiniz. VictoriaMetrics və ClickHouse-un bu xüsusiyyəti aşağı nümunələrə ehtiyacı azaldır.

Digər bir üstünlük, VictoriaMetrics-in bu məlumatları səmərəli şəkildə sıxışdırmasıdır. İstehsal üçün orta hesabla sıxılma nöqtə başına 0,4 ilə 0,8 bayt arasındadır. Hər bir nöqtə zaman damğası + dəyərdir. Və orta hesabla bir baytdan az sıxışdırır.

Sergey. Sualım var. Minimum qeyd müddəti nə qədərdir?

Bir millisaniyə. Bu yaxınlarda digər zaman seriyası verilənlər bazası tərtibatçıları ilə söhbətimiz oldu. Onların minimum vaxt kvantı bir saniyədir. Məsələn, Graphite-də bu da bir saniyədir. OpenTSDB-nin də bir saniyəsi var. InfluxDB-də nanosaniyəlik dəqiqlik. VictoriaMetrics-in bir millisaniyəsi var, çünki Prometeydə bir millisaniyə var. Və VictoriaMetrics əvvəlcə Prometey üçün uzaqdan saxlama kimi hazırlanmışdır. Amma indi o, digər sistemlərdən də məlumatları saxlaya bilir.

Söhbət etdiyim şəxs deyir ki, onların ikinci dəqiqliyi var - bu, onlar üçün kifayətdir, çünki bu, zaman seriyası verilənlər bazasında saxlanılan məlumatların növündən asılıdır. Əgər bu DevOps məlumatları və ya onu dəqiqədə 30 saniyəlik intervallarla topladığınız infrastrukturdan verilənlərdirsə, ikinci dəqiqlik kifayət qədərdir, daha azına ehtiyacınız yoxdur. Və bu məlumatları yüksək tezlikli ticarət sistemlərindən toplasanız, nanosaniyəlik dəqiqliyə ehtiyacınız var.

VictoriaMetrics-də millisaniyəlik dəqiqlik DevOps işi üçün də uyğundur və hesabatın əvvəlində qeyd etdiyim əksər hallar üçün uyğun ola bilər. Bunun üçün uyğun olmayan yeganə şey yüksək tezlikli ticarət sistemləridir.

Çox sağ ol! Və başqa bir sual. PromQL-də uyğunluq nədir?

Tam geriyə uyğunluq. VictoriaMetrics PromQL-i tam dəstəkləyir. Bundan əlavə, PromQL-ə başqa bir inkişaf etmiş funksionallıq əlavə edir ki, bu da adlanır MetricsQL. YouTube-da bu genişləndirilmiş funksionallıq haqqında danışılır. Yazda Sankt-Peterburqda Monitorinq Görüşündə çıxış etdim.

Telegram kanalı VictoriaMetrics.

Sorğuda yalnız qeydiyyatdan keçmiş istifadəçilər iştirak edə bilər. Daxil olunxahiş edirəm.

Prometey üçün uzunmüddətli yaddaş kimi VictoriaMetrics-ə keçməyinizə nə mane olur? (Şərhlərdə yazın, sorğuya əlavə edəcəm))

• 71,4%Prometheus5 istifadə etmir

• 28,6%VictoriaMetrics2 haqqında məlumatım yox idi

7 istifadəçi səs verib. 12 istifadəçi bitərəf qalıb.

Mənbə: www.habr.com