VictoriaMetrics'te optimizasyonlara gidin. Alexander Valyalkin

Alexander Valyalkin'in 2019 sonu raporunun metnini okumanızı öneririm "VictoriaMetrics'te optimizasyonlara gidin"

Victoria Metrikleri - verileri bir zaman serisi biçiminde depolamak ve işlemek için hızlı ve ölçeklenebilir bir DBMS (kayıt, zamanı ve bu zamana karşılık gelen bir dizi değeri oluşturur; örneğin, sensörlerin durumunun periyodik olarak yoklanması veya verilerin toplanması yoluyla elde edilir) metrikler).

İşte bu raporun videosunun bağlantısı - https://youtu.be/MZ5P21j_HLE

Slaytlar

Bize kendinden bahset. Ben Alexander Valyalkin'im. Burada GitHub hesabım. Go ve performans optimizasyonu konusunda tutkuluyum. Pek çok faydalı ve pek kullanışlı olmayan kütüphaneler yazdım. Her ikisiyle de başlarlar fastveya ile quick önek.

Şu anda VictoriaMetrics üzerinde çalışıyorum. Bu nedir ve orada ne işim var? Bu sunumda bundan bahsedeceğim.

Raporun ana hatları şu şekilde:

• Öncelikle size VictoriaMetrics'in ne olduğunu anlatacağım.
• Sonra size zaman serilerinin ne olduğunu anlatacağım.
• Daha sonra size zaman serisi veritabanının nasıl çalıştığını anlatacağım.
• Şimdi size veritabanı mimarisinden bahsedeceğim: nelerden oluşuyor.
• Daha sonra VictoriaMetrics'in sahip olduğu optimizasyonlara geçelim. Bu, ters çevrilmiş indeks için bir optimizasyon ve Go'daki bit seti uygulaması için bir optimizasyondur.

Dinleyiciler arasında VictoriaMetrics'in ne olduğunu bilen var mı? Vay, birçok insan zaten biliyor. Bu iyi bir haber. Bilmeyenler için bu bir zaman serisi veritabanıdır. ClickHouse mimarisine, ClickHouse uygulamasının bazı detaylarına dayanmaktadır. Örneğin, MergeTree, mevcut tüm işlemci çekirdeklerinde paralel hesaplama ve işlemci önbelleğine yerleştirilen veri blokları üzerinde çalışarak performans optimizasyonu.

VictoriaMetrics diğer zaman serisi veritabanlarına göre daha iyi veri sıkıştırma sağlar.

Dikey olarak ölçeklenir - yani bir bilgisayara daha fazla işlemci, daha fazla RAM ekleyebilirsiniz. VictoriaMetrics bu mevcut kaynakları başarıyla kullanacak ve doğrusal üretkenliği artıracaktır.

VictoriaMetrics ayrıca yatay olarak da ölçeklenir; yani VictoriaMetrics kümesine ek düğümler ekleyebilirsiniz ve performansı neredeyse doğrusal olarak artacaktır.

Tahmin ettiğiniz gibi VictoriaMetrics hızlı bir veritabanı çünkü diğerlerini yazamıyorum. Ve bu Go'da yazıldığı için bu buluşmada bunun hakkında konuşuyorum.

Zaman serisinin ne olduğunu kim bilebilir? Ayrıca birçok insanı tanıyor. Zaman serisi bir çiftler dizisidir (timestamp, значение), bu çiftlerin zamana göre sıralandığı yer. Değer kayan noktalı bir sayıdır – float64.

Her zaman serisi benzersiz bir anahtarla tanımlanır. Bu anahtar nelerden oluşuyor? Boş olmayan bir anahtar/değer çiftleri kümesinden oluşur.

İşte bir zaman serisi örneği. Bu serinin anahtarı çiftlerin listesidir: __name__="cpu_usage" metriğin adıdır, instance="my-server" - bu, bu metriğin toplandığı bilgisayardır, datacenter="us-east" - burası bu bilgisayarın bulunduğu veri merkezidir.

Üç anahtar/değer çiftinden oluşan bir zaman serisi adı elde ettik. Bu anahtar bir çift listesine karşılık gelir (timestamp, value). t1, t3, t3, ..., tN - bunlar zaman damgalarıdır, 10, 20, 12, ..., 15 — karşılık gelen değerler. Bu, belirli bir seri için belirli bir zamandaki işlemci kullanımıdır.

Zaman serileri nerede kullanılabilir? Kimsenin bir fikri var mı?

• DevOps'ta CPU, RAM, ağ, rps, hata sayısı vb.'yi ölçebilirsiniz.
• IoT - sıcaklığı, basıncı, coğrafi koordinatları ve başka şeyleri ölçebiliriz.
• Ayrıca finans – her türlü hisse senedi ve para biriminin fiyatlarını takip edebiliriz.
• Ayrıca fabrikalarda üretim süreçlerinin izlenmesinde zaman serileri kullanılabilmektedir. Robotlar için rüzgar türbinlerini izlemek amacıyla VictoriaMetrics'i kullanan kullanıcılarımız var.
• Zaman serileri aynı zamanda çeşitli cihazların sensörlerinden bilgi toplamak için de kullanışlıdır. Örneğin bir motor için; lastik basıncını ölçmek için; hız ve mesafeyi ölçmek için; benzin tüketimini vb. ölçmek için.
• Zaman serileri uçakları izlemek için de kullanılabilir. Her uçağın, uçağın sağlığına ilişkin çeşitli parametrelere ilişkin zaman serilerini toplayan bir kara kutusu vardır. Zaman serileri havacılık ve uzay endüstrisinde de kullanılmaktadır.
• Sağlık kan basıncı, nabız vb.'dir.

Unuttuğum daha çok uygulama olabilir ama modern dünyada zaman serilerinin aktif olarak kullanıldığını umarım anlamışsınızdır. Ve kullanımlarının hacmi her yıl artıyor.

Neden bir zaman serisi veritabanına ihtiyacınız var? Zaman serilerini depolamak için neden normal bir ilişkisel veritabanı kullanmıyorsunuz?

Çünkü zaman serileri genellikle büyük miktarda bilgi içerir ve bunların geleneksel veritabanlarında saklanması ve işlenmesi zordur. Bu nedenle zaman serileri için özel veritabanları ortaya çıktı. Bu üsler noktaları etkili bir şekilde saklar (timestamp, value) verilen anahtarla. Depolanan verileri anahtara, tek bir anahtar/değer çiftine veya birden fazla anahtar/değer çiftine veya normal ifadeye göre okumak için bir API sağlarlar. Örneğin Amerika’daki bir veri merkezindeki tüm hizmetlerinizin CPU yükünü bulmak istiyorsanız bu sözde sorguyu kullanmanız gerekir.

Tipik olarak zaman serisi veritabanları özel sorgulama dilleri sağlar çünkü zaman serisi SQL'i pek uygun değildir. Her ne kadar SQL'i destekleyen veritabanları olsa da pek uygun değildir. Gibi sorgu dilleri PromQL, AkışQL, Akı, Q. Umarım birileri bu dillerden en az birini duymuştur. Muhtemelen birçok kişi PromQL'i duymuştur. Bu Prometheus sorgu dilidir.

Örnek olarak VictoriaMetrics'i kullanan modern bir zaman serisi veritabanı mimarisi böyle görünür.

İki bölümden oluşur. Bu, ters çevrilmiş indeks için depolama ve zaman serisi değerleri için depolamadır. Bu depolar ayrılmıştır.

Veritabanına yeni bir kayıt geldiğinde, belirli bir kümenin zaman serisi tanımlayıcısını bulmak için ilk önce ters çevrilmiş indekse erişiriz. label=value belirli bir metrik için. Bu tanımlayıcıyı buluyoruz ve değeri veri deposuna kaydediyoruz.

TSDB’den veri almak için istek geldiğinde öncelikle inverted index’e gidiyoruz. Hadi her şeyi alalım timeseries_ids bu kümeyle eşleşen kayıtlar label=value. Daha sonra veri ambarından gerekli tüm verileri indekslenmiş olarak alıyoruz. timeseries_ids.

Bir zaman serisi veritabanının gelen bir seçme sorgusunu nasıl işlediğine dair bir örneğe bakalım.

• Her şeyden önce her şeyi alır timeseries_ids verilen çiftleri içeren ters çevrilmiş bir indeksten label=valueveya belirli bir düzenli ifadeyi karşılayın.
• Daha sonra bulunanlar için belirli bir zaman aralığında tüm veri noktalarını veri deposundan alır. timeseries_ids.
• Bundan sonra veritabanı kullanıcının isteğine göre bu veri noktaları üzerinde bazı hesaplamalar yapar. Ve bundan sonra cevabı döndürür.

Bu sunumda size ilk bölümden bahsedeceğim. Bu bir arama timeseries_ids ters endekse göre. İkinci ve üçüncü bölümleri daha sonra izleyebilirsiniz VictoriaMetrics kaynakları, veya diğer raporları hazırlayana kadar bekleyin :)

Tersine çevrilmiş endekse geçelim. Birçoğu bunun basit olduğunu düşünebilir. Tersine çevrilmiş endeksin ne olduğunu ve nasıl çalıştığını kim bilebilir? Ah, artık pek fazla insan yok. Ne olduğunu anlamaya çalışalım.

Aslında çok basit. Bu sadece bir anahtarı bir değerle eşleştiren bir sözlüktür. Anahtar nedir? Bu çift label=valueNerede label и value - bunlar çizgiler. Ve değerler bir kümedir timeseries_idsverilen çifti içeren label=value.

Ters çevrilmiş dizin her şeyi hızlı bir şekilde bulmanızı sağlar timeseries_ids, vermiş olan label=value.

Ayrıca hızlı bir şekilde bulmanızı sağlar timeseries_ids birkaç çift için zaman serisi label=valueveya çiftler için label=regexp. Bu nasıl oluyor? Kümenin kesişimini bularak timeseries_ids her çift için label=value.

Tersine çevrilmiş endeksin çeşitli uygulamalarına bakalım. En basit saf uygulamayla başlayalım. Şuna benziyor.

Fonksiyon getMetricIDs dizelerin bir listesini alır. Her satır içerir label=value. Bu fonksiyon bir liste döndürür metricIDs.

Nasıl çalışır? Burada global bir değişkenimiz var: invertedIndex. Bu normal bir sözlüktür (map), bu da dizeyi dilim dilimlerine eşleyecektir. Satır şunları içerir: label=value.

İşlev uygulaması: get metricIDs İlk için label=value, sonra diğer her şeyin üzerinden geçiyoruz label=value, anladık metricIDs onlar için. Ve işlevi çağırın intersectIntsAşağıda tartışılacak olan. Ve bu fonksiyon bu listelerin kesişimini döndürür.

Gördüğünüz gibi ters çevrilmiş bir endeksin uygulanması çok karmaşık değil. Ancak bu naif bir uygulamadır. Ne gibi dezavantajları var? Saf uygulamanın ana dezavantajı, böyle bir ters çevrilmiş endeksin RAM'de saklanmasıdır. Uygulamayı yeniden başlattıktan sonra bu dizini kaybediyoruz. Bu dizinin diske kaydedilmesi yoktur. Böyle bir ters çevrilmiş endeksin bir veritabanı için uygun olması pek mümkün değildir.

İkinci dezavantaj da hafızayla ilgilidir. Ters çevrilmiş indeks RAM'e sığmalıdır. RAM boyutunu aşarsa, o zaman açıkçası yetersiz bellek hatasıyla karşılaşacağız. Ve program çalışmayacak.

Bu sorun, hazır çözümler kullanılarak çözülebilir. SeviyeDBVeya RocksDB.

Kısaca üç işlemi hızlı bir şekilde yapmamızı sağlayacak bir veritabanına ihtiyacımız var.

• İlk işlem kayıt oluyor ключ-значение bu veritabanına. Bunu çok hızlı bir şekilde yapıyor, burada ключ-значение keyfi dizelerdir.
• İkinci işlem, belirli bir anahtarı kullanarak bir değerin hızlı aranmasıdır.
• Ve üçüncü işlem, belirli bir öneke göre tüm değerlerin hızlı bir şekilde aranmasıdır.

LevelDB ve RocksDB - bu veritabanları Google ve Facebook tarafından geliştirildi. İlk önce LevelDB geldi. Sonra Facebook'taki adamlar LevelDB'yi alıp geliştirmeye başladılar, RocksDB'yi yaptılar. Artık RocksDB ve MySQL'e aktarılanlar da dahil olmak üzere neredeyse tüm dahili veritabanları Facebook içindeki RocksDB üzerinde çalışıyor. Ona adını verdiler MyRocks.

Tersine çevrilmiş bir dizin LevelDB kullanılarak uygulanabilir. Nasıl yapılır? Anahtar olarak kaydediyoruz label=value. Değer ise çiftin mevcut olduğu zaman serisinin tanımlayıcısıdır. label=value.

Belirli bir çifte sahip çok sayıda zaman serimiz varsa label=value, o zaman bu veritabanında aynı anahtara ve farklı olan birçok satır olacaktır. timeseries_ids. Hepsinin bir listesini almak için timeseries_ids, bununla başlayan label=prefix, bu veritabanının optimize edildiği bir aralık taraması yapıyoruz. Yani ile başlayan tüm satırları seçiyoruz label=prefix ve gerekli olanı alın timeseries_ids.

İşte Go'da nasıl görüneceğine dair örnek bir uygulama. Tersine çevrilmiş bir endeksimiz var. Bu LevelDB'dir.

İşlev, saf uygulamayla aynıdır. Naif uygulamayı neredeyse satır satır tekrarlıyor. Tek nokta şu ki, dönmek yerine map ters dizine erişiyoruz. İlk önce tüm değerleri alıyoruz label=value. Sonra kalan tüm çiftlerin üzerinden geçiyoruz label=value ve bunlara karşılık gelen metrik kimlik kümelerini alın. Daha sonra kesişimi buluyoruz.

Her şey yolunda gibi görünüyor ancak bu çözümün dezavantajları var. VictoriaMetrics başlangıçta LevelDB'ye dayalı ters bir endeks uyguladı. Ama sonunda vazgeçmek zorunda kaldım.

Neden? Çünkü LevelDB saf uygulamadan daha yavaştır. Naif bir uygulamada, belirli bir anahtar verildiğinde, dilimin tamamını anında alırız metricIDs. Bu çok hızlı bir işlemdir; dilimin tamamı kullanıma hazırdır.

LevelDB'de bir işlev her çağrıldığında GetValues ile başlayan tüm satırlardan geçmeniz gerekiyor label=value. Ve her satırın değerini alın timeseries_ids. Böyle bir timeseries_ids bunlardan bir dilim topla timeseries_ids. Açıkçası bu, normal bir haritaya anahtarla erişmekten çok daha yavaştır.

İkinci dezavantaj ise LevelDB'nin C dilinde yazılmış olmasıdır. Go'dan C işlevlerini çağırmak çok hızlı değildir. Yüzlerce nanosaniye sürer. Bu çok hızlı değil çünkü go'da yazılan ve 1-5 nanosaniye süren normal bir işlev çağrısıyla karşılaştırıldığında performans farkı onlarca kat daha fazladır. VictoriaMetrics için bu ölümcül bir kusurdu :)

Bu yüzden ters çevrilmiş indeksin kendi uygulamamı yazdım. Ve onu aradı birleştirme kümesi.

Mergeset, MergeTree veri yapısını temel alır. Bu veri yapısı ClickHouse'dan ödünç alınmıştır. Açıkçası, birleştirme kümesi hızlı arama için optimize edilmelidir timeseries_ids verilen anahtara göre. Mergeset tamamen Go'da yazılmıştır. Görebilirsin GitHub'daki VictoriaMetrics kaynakları. Mergeset'in uygulanması klasördedir /lib/mergeset. Orada neler olduğunu anlamaya çalışabilirsiniz.

Birleştirme kümesi API'si LevelDB ve RocksDB'ye çok benzer. Yani, yeni kayıtları oraya hızlı bir şekilde kaydetmenize ve belirli bir öneke göre kayıtları hızlı bir şekilde seçmenize olanak tanır.

Birleştirme setinin dezavantajlarından daha sonra bahsedeceğiz. Şimdi tersine çevrilmiş bir endeksi uygularken VictoriaMetrics'in üretimde hangi sorunların ortaya çıktığı hakkında konuşalım.

Neden ortaya çıktılar?

Birinci sebep, kayıp oranının yüksek olmasıdır. Rusçaya çevrildiğinde bu, zaman serilerinde sık sık yapılan bir değişikliktir. Bu, bir zaman serisinin bitip yeni bir serinin başladığı veya birçok yeni zaman serisinin başladığı zamandır. Ve bu sıklıkla olur.

İkinci sebep ise zaman serilerinin sayısının fazla olmasıdır. Başlangıçta, izleme popülerlik kazandığında zaman serilerinin sayısı azdı. Örneğin, her bilgisayar için CPU, bellek, ağ ve disk yükünü izlemeniz gerekir. Bilgisayar başına 4 zaman serisi. Diyelim ki 100 bilgisayarınız ve 400 zaman seriniz var. Bu çok az.

Zamanla insanlar daha ayrıntılı bilgileri ölçebileceklerini anladılar. Örneğin, tüm işlemcinin yükünü değil, her işlemci çekirdeğinin yükünü ayrı ayrı ölçün. 40 işlemci çekirdeğiniz varsa, işlemci yükünü ölçmek için 40 kat daha fazla zaman seriniz olur.

Ama hepsi bu değil. Her işlemci çekirdeği, boştayken boşta kalma gibi çeşitli durumlara sahip olabilir. Ayrıca kullanıcı alanında, çekirdek alanında ve diğer durumlarda çalışın. Ve bu tür durumların her biri ayrı bir zaman serisi olarak da ölçülebilir. Bu ayrıca satır sayısını 7-8 kat artırır.

Bir metrikten sadece bir bilgisayar için 40 x 8 = 320 metrik elde ettik. 100 ile çarparsak 32 yerine 000 elde ederiz.

Sonra Kubernetes ortaya çıktı. Ve durum daha da kötüleşti çünkü Kubernetes birçok farklı hizmeti barındırabiliyor. Kubernetes'teki her hizmet birçok bölmeden oluşur. Ve tüm bunların izlenmesi gerekiyor. Ayrıca hizmetlerinizin yeni sürümlerini sürekli olarak dağıtıyoruz. Her yeni sürüm için yeni zaman serileri oluşturulmalıdır. Sonuç olarak zaman serisi sayısı katlanarak artıyor ve yüksek kardinalite olarak adlandırılan çok sayıda zaman serisi sorunuyla karşı karşıya kalıyoruz. VictoriaMetrics, diğer zaman serisi veritabanlarına kıyasla bu sorunla başarılı bir şekilde başa çıkıyor.

Gelin yüksek kayıp oranına daha yakından bakalım. Üretimde yüksek kayıp oranının nedeni nedir? Çünkü etiketlerin ve etiketlerin bazı anlamları sürekli değişmektedir.

Örneğin, şu konsepte sahip Kubernetes'i ele alalım: deployment, yani uygulamanızın yeni bir sürümü kullanıma sunulduğunda. Bazı nedenlerden dolayı Kubernetes geliştiricileri dağıtım kimliğini etikete eklemeye karar verdi.

Bu neye yol açtı? Üstelik her yeni dağıtımda tüm eski zaman serileri kesintiye uğrar ve onların yerine yeni etiket değeriyle yeni zaman serileri başlar. deployment_id. Bu tür yüzbinlerce, hatta milyonlarca satır olabilir.

Tüm bunlarla ilgili önemli olan, toplam zaman serisi sayısının artması, ancak halihazırda aktif olan ve veri alan zaman serisinin sayısının sabit kalmasıdır. Bu duruma yüksek kayıp oranı denir.

Yüksek kayıp oranının temel sorunu, belirli bir zaman aralığında belirli bir etiket seti için tüm zaman serileri için sabit bir arama hızı sağlamaktır. Genellikle bu, son saatin veya son günün zaman aralığıdır.

Bu sorun nasıl çözülür? İşte ilk seçenek. Bu, ters çevrilmiş endeksi zaman içinde bağımsız parçalara bölmek içindir. Yani bir süre geçer, mevcut ters endeksle çalışmayı bitiririz. Ve yeni bir ters çevrilmiş dizin oluşturun. Bir zaman aralığı daha geçiyor, bir tane daha, bir tane daha yaratıyoruz.

Ve bu ters çevrilmiş endekslerden örnekleme yaparken, belirli bir aralığa denk gelen bir dizi ters çevrilmiş endeks buluyoruz. Ve buna göre zaman serisinin id’sini oradan seçiyoruz.

Bu, kaynak tasarrufu sağlar çünkü verilen aralığa girmeyen parçalara bakmak zorunda değiliz. Yani genellikle son saatin verilerini seçersek önceki zaman aralıkları için istekleri atlarız.

Bu sorunu çözmek için başka bir seçenek daha var. Bu, her gün için o günde meydana gelen zaman serisinin kimliklerinin ayrı bir listesini depolamak içindir.

Bu çözümün önceki çözüme göre avantajı, zamanla kaybolmayan zaman serisi bilgilerini çoğaltmamamızdır. Sürekli olarak mevcutturlar ve değişmezler.

Dezavantajı ise böyle bir çözümün uygulanmasının daha zor olması ve hata ayıklamanın daha zor olmasıdır. Ve VictoriaMetrics bu çözümü seçti. Tarihsel olarak bu böyle oldu. Bu çözüm aynı zamanda öncekine göre iyi performans gösteriyor. Çünkü değişmeyen yani zamanla kaybolmayan zaman serileri için her bölümdeki verilerin çoğaltılması gerektiğinden bu çözüm uygulanmadı. VictoriaMetrics öncelikle disk alanı tüketimi için optimize edilmişti ve önceki uygulama, disk alanı tüketimini daha da kötüleştirdi. Ancak bu uygulama, disk alanı tüketimini en aza indirmek için daha uygundur, bu nedenle seçildi.

Onunla savaşmak zorundaydım. Buradaki zorluk, bu uygulamada hala çok daha büyük bir sayı seçmeniz gerektiğiydi. timeseries_ids veriler için, ters çevrilmiş endeksin zaman bölümlendirmesine göre daha fazladır.

Bu sorunu nasıl çözdük? Bunu orijinal bir şekilde çözdük; her ters çevrilmiş indeks girişine tek bir tanımlayıcı yerine birden fazla zaman serisi tanımlayıcısı depolayarak. Yani bir anahtarımız var label=value, her zaman serisinde meydana gelir. Ve şimdi birkaçını kurtarıyoruz timeseries_ids tek bir girişte.

İşte bir örnek. Daha önce N tane girdimiz vardı, ancak şimdi ön eki diğerleriyle aynı olan bir girdimiz var. Önceki giriş için değer tüm zaman serisi kimliklerini içerir.

Bu, böyle bir ters çevrilmiş endeksin tarama hızının 10 kata kadar arttırılmasını mümkün kıldı. Ve bu, önbellek için bellek tüketimini azaltmamıza olanak sağladı çünkü artık dizeyi saklıyoruz label=value önbellekte yalnızca bir kez birlikte N kez. Ve eğer etiketlerinizde ve etiketlerinizde Kubernetes'in oraya itmeyi sevdiği uzun çizgiler saklıyorsanız bu satır büyük olabilir.

Tersine çevrilmiş bir dizinde aramayı hızlandırmanın başka bir seçeneği de parçalamadır. Bir yerine birden fazla ters çevrilmiş dizin oluşturmak ve verileri bunlar arasında anahtarla parçalamak. Bu bir set key=value buhar. Yani, birkaç işlemcide paralel olarak sorgulayabileceğimiz birkaç bağımsız ters çevrilmiş indeks elde ederiz. Önceki uygulamalar yalnızca tek işlemci modunda çalışmaya, yani verilerin yalnızca tek bir çekirdekte taranmasına izin veriyordu. Bu çözüm, ClickHouse'un yapmayı sevdiği gibi, birden fazla çekirdekteki verileri aynı anda taramanıza olanak tanır. Uygulamayı planladığımız şey bu.

Şimdi koyunlarımıza, kesişim fonksiyonuna dönelim. timeseries_ids. Hangi uygulamaların olabileceğini düşünelim. Bu işlev bulmanızı sağlar timeseries_ids belirli bir set için label=value.

İlk seçenek saf bir uygulamadır. İç içe geçmiş iki döngü. Burada fonksiyon girişini alıyoruz intersectInts iki dilim - a и b. Çıkışta bu dilimlerin kesişimini bize geri vermelidir.

Naif bir uygulama şöyle görünüyor. Dilimdeki tüm değerleri yineliyoruz a, bu döngünün içinde dilimin tüm değerlerinden geçiyoruz b. Ve bunları karşılaştırıyoruz. Eşleşirlerse bir kesişim bulduk demektir. Ve onu içine kaydet result.

Dezavantajları nelerdir? İkinci dereceden karmaşıklık ana dezavantajıdır. Örneğin, boyutlarınız dilim ise a и b Bir seferde bir milyon, o zaman bu işlev size hiçbir zaman yanıt vermeyecektir. Çünkü bir trilyon yineleme yapması gerekecek ki bu, modern bilgisayarlar için bile çok fazla bir rakam.

İkinci uygulama haritaya dayalıdır. Harita oluşturuyoruz. Dilimdeki tüm değerleri bu haritaya yerleştirdik a. Daha sonra ayrı bir döngüde dilimden geçiyoruz b. Ve bu değerin dilimden olup olmadığını kontrol ediyoruz b haritada. Varsa sonuca ekleyin.

Faydaları nelerdir? Avantajı yalnızca doğrusal karmaşıklığın olmasıdır. Yani fonksiyon daha büyük dilimler için çok daha hızlı çalışacaktır. Milyon boyutlu bir dilim için bu işlev, önceki işlevin trilyon yinelemesinin aksine, 2 milyon yinelemede yürütülecektir.

Dezavantajı ise bu fonksiyonun bu haritayı oluşturmak için daha fazla hafıza gerektirmesidir.

İkinci dezavantaj karma işleminin büyük masrafıdır. Bu dezavantaj çok belirgin değildir. Bizim açımızdan da çok açık değildi, dolayısıyla VictoriaMetrics'te ilk başta kavşak uygulaması bir harita aracılığıyla yapılıyordu. Ancak daha sonra profil oluşturma, ana işlemci zamanının haritaya yazmaya ve bu haritada bir değerin varlığını kontrol etmeye harcandığını gösterdi.

CPU zamanı neden bu yerlerde boşa harcanıyor? Çünkü Go bu satırlar üzerinde hashleme işlemi gerçekleştiriyor. Yani, HashMap'teki belirli bir dizinden ona erişmek için anahtarın karmasını hesaplar. Hash hesaplama işlemi onlarca nanosaniyede tamamlanır. Bu VictoriaMetrics için yavaştır.

Bu durum için özel olarak optimize edilmiş bir bit kümesi uygulamaya karar verdim. İki dilimin kesişimi artık böyle görünüyor. Burada bir bit kümesi oluşturuyoruz. İlk dilimden öğeler ekliyoruz. Daha sonra ikinci dilimde bu unsurların varlığını kontrol ediyoruz. Ve bunları sonuca ekleyin. Yani önceki örnekten neredeyse hiç farklı değil. Buradaki tek şey, haritaya erişimi özel işlevlerle değiştirmiş olmamızdır add и has.

İlk bakışta, daha önce standart bir harita kullanılmışsa ve daha sonra başka işlevler çağrılmışsa, bunun daha yavaş çalışması gerektiği anlaşılıyor, ancak profil oluşturma, VictoriaMetrics durumunda bu şeyin standart haritadan 10 kat daha hızlı çalıştığını gösteriyor.

Ayrıca harita uygulamasına göre çok daha az bellek kullanır. Çünkü burada sekiz baytlık değerler yerine bitleri saklıyoruz.

Bu uygulamanın dezavantajı o kadar bariz olmaması, önemsiz olmamasıdır.

Çoğu kişinin fark edemeyeceği bir diğer dezavantaj ise bu uygulamanın bazı durumlarda iyi çalışmayabileceğidir. Yani belirli bir durum için, yani VictoriaMetrics zaman serisi kimliklerinin kesiştiği bu durum için optimize edilmiştir. Bu her duruma uygun olduğu anlamına gelmez. Yanlış kullanıldığında performans artışı değil, yetersiz bellek hatası ve performansta yavaşlama elde ederiz.

Bu yapının uygulanmasını ele alalım. Bakmak isterseniz VictoriaMetrics kaynaklarında, klasörde bulunur. lib/uint64set. VictoriaMetrics durumu için özel olarak optimize edilmiştir; timeseries_id ilk 64 bitin temelde sabit olduğu ve yalnızca son 32 bitin değiştiği 32 bitlik bir değerdir.

Bu veri yapısı diskte saklanmaz, yalnızca bellekte çalışır.

İşte API'si. Çok karmaşık değil. API, VictoriaMetrics kullanımının belirli bir örneğine göre özel olarak tasarlanmıştır. Yani burada gereksiz işlevler yoktur. Burada VictoriaMetrics tarafından açıkça kullanılan işlevler yer almaktadır.

Fonksiyonlar var add, yeni değerler katan. Bir fonksiyon var has, yeni değerleri kontrol eder. Ve bir fonksiyon var del, değerleri kaldırır. Bir yardımcı fonksiyon var len, kümenin boyutunu döndürür. İşlev clone çok fazla klonlanıyor. Ve fonksiyon appendto bu seti dilime dönüştürür timeseries_ids.

Bu veri yapısının uygulanması böyle görünüyor. setin iki öğesi vardır:

• ItemsCount bir kümedeki öğelerin sayısını hızlı bir şekilde döndürmek için yardımcı bir alandır. Bu yardımcı alan olmadan da yapmak mümkün olabilirdi, ancak buraya eklenmesi gerekiyordu çünkü VictoriaMetrics, algoritmalarında bit kümesi uzunluğunu sıklıkla sorguluyor.

• İkinci alan ise buckets. Bu yapıdan bir kesit bucket32. Her yapı depolar hi alan. Bunlar üst 32 bittir. Ve iki dilim - b16his и buckets arasında bucket16 yapılar.

16 bitlik yapının ikinci bölümünün ilk 64 biti burada saklanır. Ve burada bit kümeleri her baytın alt 16 biti için saklanır.

Bucket64 bir diziden oluşur uint64. Uzunluk bu sabitler kullanılarak hesaplanır. Birinde bucket16 maksimum saklanabilir 2^16=65536 biraz. Bunu 8'e bölerseniz 8 kilobayt olur. Tekrar 8'e bölerseniz 1000 olur uint64 Anlam. Yani Bucket16 – bu bizim 8 kilobaytlık yapımız.

Bu yapının yeni değer katma yöntemlerinden birinin nasıl uygulandığına bakalım.

Her şey şununla başlıyor: uint64 anlamlar. Üst 32 biti hesaplıyoruz, alt 32 biti hesaplıyoruz. Hadi her şeyin üzerinden geçelim buckets. Her bir gruptaki en üstteki 32 biti eklenen değerle karşılaştırırız. Eşleşirlerse işlevi çağırırız add b32 yapısında buckets. Ve alt 32 biti buraya ekleyin. Ve eğer geri dönerse truedemek ki oraya böyle bir değer kattık ama böyle bir değere sahip olmadık. Eğer geri dönerse false, o zaman böyle bir anlam zaten vardı. Daha sonra yapıdaki eleman sayısını arttırıyoruz.

İhtiyacınız olanı bulamadıysak bucket gerekli hi-değeri ile işlevi çağırırız addAllocyenisini üretecek olan bucket, bunu kova yapısına ekleyin.

Bu fonksiyonun uygulanmasıdır b32.add. Önceki uygulamaya benzer. En anlamlı 16 biti, en az anlamlı 16 biti hesaplıyoruz.

Daha sonra üstteki 16 bitin tamamını geçiyoruz. Eşleşmeleri buluyoruz. Ve eğer bir eşleşme varsa, bir sonraki sayfada ele alacağımız add yöntemini çağırıyoruz. bucket16.

Ve işte mümkün olduğunca optimize edilmesi gereken en düşük seviye. için hesaplıyoruz uint64 dilim bitindeki kimlik değeri ve ayrıca bitmask. Bu, belirli bir 64 bitlik değer için, bu bitin varlığını kontrol etmek veya ayarlamak için kullanılabilen bir maskedir. Bu bitin ayarlanıp ayarlanmadığını kontrol edip ayarlıyoruz ve varlığı geri döndürüyoruz. Bu, zaman serilerinin kesişen kimliklerinin çalışmasını geleneksel haritalara kıyasla 10 kat hızlandırmamızı sağlayan uygulamamızdır.

Bu optimizasyona ek olarak VictoriaMetrics'in birçok başka optimizasyonu da vardır. Bu optimizasyonların çoğu bir nedenden ötürü eklenmiştir, ancak üretim sırasında kodun profili çıkarıldıktan sonra eklenmiştir.

Bu, optimizasyonun ana kuralıdır; burada bir darboğaz olacağını varsayarak optimizasyon eklemeyin, çünkü orada bir darboğaz olmayacağı ortaya çıkabilir. Optimizasyon genellikle kodun kalitesini düşürür. Bu nedenle, yalnızca profil oluşturma sonrasında ve tercihen üretim aşamasında optimizasyona değer, böylece bunlar gerçek veriler olur. İlgilenen varsa VictoriaMetrics kaynak koduna bakabilir ve mevcut diğer optimizasyonları keşfedebilirsiniz.

Bitset ile ilgili bir sorum var. C++ vektör bool uygulamasına çok benzer, optimize edilmiş bit seti. Uygulamayı oradan mı aldınız?

Hayır, oradan değil. Bu bit kümesini uygularken, VictoriaMetrics'te kullanılan bu kimlik zaman serilerinin yapısına ilişkin bilgiler bana rehberlik etti. Ve yapıları öyledir ki, üstteki 32 bit temelde sabittir. Alt 32 bit değişebilir. Bit ne kadar düşük olursa o kadar sık ​​değişebilir. Bu nedenle bu uygulama özellikle bu veri yapısı için optimize edilmiştir. Bildiğim kadarıyla C++ uygulaması genel durum için optimize edilmiştir. Genel durum için optimizasyon yaparsanız bu, belirli bir durum için en uygun durumun olmayacağı anlamına gelir.

Ayrıca Alexey Milovid'in raporunu izlemenizi tavsiye ederim. Yaklaşık bir ay önce ClickHouse'da belirli uzmanlıklara yönelik optimizasyondan bahsetti. Sadece genel durumda bir C++ uygulamasının veya başka bir uygulamanın bir hastanede ortalama olarak iyi çalışacak şekilde tasarlandığını söylüyor. En üstteki 32 bitin çoğunlukla sabit olduğunu bildiğimiz, bizimki gibi bilgiye özgü bir uygulamadan daha kötü performans gösterebilir.

İkinci bir sorum var. InfluxDB'den temel fark nedir?

Birçok temel farklılık var. Performans ve bellek tüketimi açısından InfluxDB, testlerde çok sayıda (örneğin milyonlarca) yüksek kardinaliteli zaman serileri için 10 kat daha fazla bellek tüketimi gösteriyor. Örneğin, VictoriaMetrics milyon aktif satır başına 1 GB tüketirken InfluxDB 10 GB tüketir. Ve bu büyük bir fark.

İkinci temel fark, InfluxDB'nin garip sorgulama dillerine sahip olmasıdır - Flux ve InfluxQL. Zaman serileriyle çalışmaya pek uygun değiller. PromQLVictoriaMetrics tarafından desteklenmektedir. PromQL, Prometheus'un bir sorgulama dilidir.

Ve bir fark daha, InfluxDB'nin biraz garip bir veri modeline sahip olmasıdır; burada her satır, farklı etiket setine sahip birkaç alanı depolayabilir. Bu satırlar ayrıca çeşitli tablolara bölünmüştür. Bu ek komplikasyonlar, bu veritabanıyla daha sonraki çalışmaları zorlaştırmaktadır. Desteklemek ve anlamak zordur.

VictoriaMetrics'te her şey çok daha basittir. Burada her zaman serisi bir anahtar/değerdir. Değer bir nokta kümesidir - (timestamp, value)ve anahtar kümedir label=value. Alanlar ve ölçümler arasında hiçbir ayrım yoktur. Bildiğim kadarıyla farklı satırlar arasındaki hesaplamaların hala uygulanmadığı InfluxDB'nin aksine, herhangi bir veriyi seçmenize ve ardından birleştirmenize, eklemenize, çıkarmanıza, çarpmanıza, bölmenize olanak tanır. Uygulansalar bile zordur, çok fazla kod yazmanız gerekir.

Açıklayıcı bir sorum var. Bahsettiğiniz bir sorun olduğunu, bu ters indeksin belleğe sığmadığını yani orada bölümleme olduğunu doğru mu anladım?

İlk olarak, ters çevrilmiş bir endeksin standart bir Go haritası üzerinde saf bir uygulamasını gösterdim. Bu uygulama, veritabanları için uygun değildir çünkü bu ters çevrilmiş dizin diske kaydedilmez ve bu verilerin yeniden başlatıldığında kullanılabilir kalması için veritabanının diske kaydedilmesi gerekir. Bu uygulamada uygulamayı yeniden başlattığınızda ters çevrilmiş indeksiniz kaybolacaktır. Ve bulamayacağınız için tüm verilere erişiminizi kaybedeceksiniz.

Merhaba! Rapor için teşekkürler! Benim adım Pavel. Ben Wildberries'liyim. Senin için birkaç sorum var. Birinci soru. Uygulamanızın mimarisini oluştururken farklı bir prensip seçmiş olsaydınız ve verileri zaman içinde bölümlendirseydiniz, o zaman belki de yalnızca bir bölümün bir bölüm için veri içerdiği gerçeğine dayanarak arama yaparken verileri kesiştirebileceğinizi düşünüyor musunuz? yani tek bir zaman aralığında ve parçalarınızın farklı şekilde dağılmasından endişe etmenize gerek kalmaz mı? Soru numarası 2 - bit seti ve diğer her şeyle benzer bir algoritma uyguladığınıza göre, belki işlemci talimatlarını kullanmayı denediniz? Belki bu tür optimizasyonları denediniz mi?

İkinciye hemen cevap vereceğim. Henüz o noktaya gelmedik. Ama gerekirse oraya da gideceğiz. Ve ilki, soru neydi?

İki senaryoyu tartıştınız. Daha karmaşık bir uygulama olan ikincisini seçtiklerini söylediler. Ve verilerin zamana göre bölümlendiği ilkini tercih etmediler.

Evet. İlk durumda, endeksin toplam hacmi daha büyük olacaktır çünkü her bölümde, tüm bu bölümler boyunca devam eden zaman serileri için yinelenen verileri depolamak zorunda kalacağız. Ve eğer zaman serisi kayıp oranınız küçükse, yani sürekli olarak aynı seriler kullanılıyorsa, o zaman ilk durumda, ikinci duruma kıyasla kaplanan disk alanı miktarında çok daha fazla kayıp yaşarız.

Ve böylece - evet, zaman bölümlendirmesi iyi bir seçenektir. Prometheus bunu kullanıyor. Ancak Prometheus'un başka bir dezavantajı daha var. Bu veri parçalarını birleştirirken tüm etiketler ve zaman serileri için meta bilgileri hafızada tutması gerekir. Bu nedenle, birleştirdiği veri parçaları büyükse VictoriaMetrics'in aksine birleştirme sırasında bellek tüketimi çok artar. Birleştirme sırasında VictoriaMetrics belleği hiç tüketmez; birleştirilen veri parçalarının boyutundan bağımsız olarak yalnızca birkaç kilobayt tüketilir.

Kullandığınız algoritma hafızayı kullanır. Değerleri içeren zaman serisi etiketlerini işaretler. Ve bu şekilde bir veri dizisinde ve diğerinde eşleştirilmiş varlığı kontrol edersiniz. Ve kesişmenin gerçekleşip gerçekleşmediğini anlıyorsunuz. Tipik olarak veritabanları, mevcut içeriklerini saklayan ve bu işlemlerin basit karmaşıklığı nedeniyle sıralanan veriler üzerinde çalışan imleçleri ve yineleyicileri uygular.

Verilerde geçiş yapmak için neden imleçleri kullanmıyoruz?

Evet.

Sıralanmış satırları LevelDB veya mergeset'te saklıyoruz. İmleci hareket ettirip kesişimi bulabiliriz. Neden kullanmıyoruz? Çünkü yavaş. Çünkü imleçler her satır için bir fonksiyon çağırmanız gerektiği anlamına gelir. Bir işlev çağrısı 5 nanosaniyedir. Ve eğer 100 satırınız varsa, o zaman sadece fonksiyonu çağırmak için yarım saniye harcadığımız ortaya çıkıyor.

Böyle bir şey var evet. Ve son sorum. Soru biraz tuhaf gelebilir. Veriler geldiği anda gerekli tüm agregaların okunup istenilen biçimde kaydedilmesi neden mümkün olmuyor? Neden VictoriaMetrics, ClickHouse vb. gibi bazı sistemlerde büyük miktarlarda tasarruf edip sonra bunlara çok zaman harcayasınız ki?

Daha açık hale getirmek için bir örnek vereceğim. Diyelim ki küçük bir oyuncak hız göstergesi nasıl çalışıyor? Kat ettiğiniz mesafeyi her zaman bir değere ve ikinci kez ekleyerek kaydeder. Ve böler. Ve ortalama hız alıyor. Hemen hemen aynı şeyi yapabilirsiniz. Gerekli tüm gerçekleri anında toplayın.

Tamam soruyu anladım. Örneğinizin yeri var. Hangi agregalara ihtiyacınız olduğunu biliyorsanız, bu en iyi uygulamadır. Ancak sorun şu ki, insanlar bu metrikleri ve bazı verileri ClickHouse'a kaydediyor ve bunları gelecekte nasıl toplayacaklarını ve filtreleyeceklerini henüz bilmiyorlar, bu nedenle tüm ham verileri kaydetmeleri gerekiyor. Ancak ortalama bir şeyi hesaplamanız gerektiğini biliyorsanız, o zaman neden bir sürü ham değeri orada depolamak yerine onu hesaplamayasınız? Ancak bu yalnızca tam olarak neye ihtiyacınız olduğunu biliyorsanız mümkündür.

Bu arada, zaman serilerini depolamaya yönelik veritabanları toplamların sayılmasını destekler. Örneğin Prometheus destekliyor kayıt kuralları. Yani hangi birimlere ihtiyacınız olacağını biliyorsanız bu yapılabilir. VictoriaMetrics'te henüz bu yok ancak genellikle öncesinde Prometheus yer alıyor ve bu da yeniden kodlama kurallarında yapılabiliyor.

Örneğin önceki bir işte, kayan bir pencerede son bir saat içindeki olayların sayısını saymak gerekiyordu. Sorun şu ki, Go'da özel bir uygulama, yani bu şeyi saymak için bir hizmet oluşturmak zorunda kaldım. Bu hizmet sonuçta önemsiz değildi çünkü hesaplanması zor. Bazı toplamları sabit zaman aralıklarında saymanız gerekiyorsa uygulama basit olabilir. Kayan bir pencerede olayları saymak istiyorsanız, bu göründüğü kadar basit değildir. Bunun henüz ClickHouse'da veya zaman serisi veritabanlarında uygulanmadığını düşünüyorum çünkü uygulanması zor.

Ve bir soru daha. Tam ortalamadan bahsediyorduk ve bir zamanlar Karbon arka uçlu Grafit diye bir şeyin olduğunu hatırladım. Ve eski verileri nasıl incelteceğini, yani dakikada bir nokta, saatte bir nokta vb. bırakacağını biliyordu. Prensip olarak, nispeten konuşursak, bir ay boyunca ham verilere ihtiyacımız varsa ve diğer her şey yapabilirse bu oldukça kullanışlıdır. inceltilmek. Ancak Prometheus ve VictoriaMetrics bu işlevselliği desteklememektedir. Desteklenmesi planlanıyor mu? Değilse neden olmasın?

Soru için teşekkürler. Kullanıcılarımız bu soruyu periyodik olarak soruyor. Altörnekleme desteğini ne zaman ekleyeceğimizi soruyorlar. Burada çeşitli sorunlar var. Öncelikle her kullanıcı şunu anlar: downsampling farklı bir şey: Birisi belirli bir aralıkta herhangi bir rastgele noktayı elde etmek istiyor, birisi maksimum, minimum, ortalama değerleri istiyor. Veritabanınıza birçok sistem veri yazıyorsa hepsini bir araya toplayamazsınız. Her sistem farklı inceltme gerektirebilir. Ve bunun uygulanması zordur.

İkinci olarak, VictoriaMetrics, ClickHouse gibi, büyük miktarda ham veri üzerinde çalışmak üzere optimize edilmiştir; bu nedenle, sisteminizde çok sayıda çekirdek varsa, bir saniyeden daha kısa sürede bir milyar satırı kürekleyebilir. VictoriaMetrics'te zaman serisi noktalarının taranması – çekirdek başına saniyede 50 puan. Ve bu performans mevcut çekirdeklere göre ölçeklenir. Yani örneğin 000 çekirdeğiniz varsa saniyede bir milyar nokta tarayacaksınız. Ve VictoriaMetrics ve ClickHouse'un bu özelliği, altörnekleme ihtiyacını azaltır.

Diğer bir özellik ise VictoriaMetrics'in bu verileri etkili bir şekilde sıkıştırmasıdır. Üretimde ortalama sıkıştırma nokta başına 0,4 ila 0,8 bayt arasındadır. Her nokta bir zaman damgası + değerdir. Ve ortalama olarak bir bayttan daha az bir boyuta sıkıştırılır.

Sergey. Bir sorum var. Minimum kayıt süresi kuantumu nedir?

Bir milisaniye. Yakın zamanda diğer zaman serisi veritabanı geliştiricileriyle bir görüşme yaptık. Minimum zaman dilimleri bir saniyedir. Ve örneğin Grafit'te bu da bir saniyedir. OpenTSDB'de de bir saniyedir. InfluxDB nanosaniye hassasiyetine sahiptir. VictoriaMetrics'te bu bir milisaniyedir, çünkü Prometheus'ta bir milisaniyedir. Ve VictoriaMetrics başlangıçta Prometheus için uzak depolama alanı olarak geliştirildi. Ancak artık diğer sistemlerden veri kaydedebiliyor.

Konuştuğum kişi, saniyeden saniyeye doğruluğa sahip olduklarını söylüyor; bu onlar için yeterli çünkü bu, zaman serisi veritabanında depolanan veri türüne bağlı. Bu, DevOps verileri veya dakikada 30 saniyelik aralıklarla topladığınız altyapı verileriyse, o zaman ikinci doğruluk yeterlidir, daha azına ihtiyacınız yoktur. Ve bu verileri yüksek frekanslı ticaret sistemlerinden topluyorsanız nanosaniyelik bir doğruluğa ihtiyacınız vardır.

VictoriaMetrics'teki milisaniyelik doğruluk DevOps durumu için de uygundur ve raporun başında bahsettiğim durumların çoğu için de uygun olabilir. Uygun olmayabileceği tek şey yüksek frekanslı ticaret sistemleridir.

Teşekkür ederim! Ve başka bir soru. PromQL'de uyumluluk nedir?

Tam geriye dönük uyumluluk. VictoriaMetrics, PromQL'i tam olarak destekler. Buna ek olarak, PromQL'e, adı verilen ek gelişmiş işlevsellik ekler. MetriklerQL. YouTube'da bu genişletilmiş işlevsellik hakkında bir konuşma var. İlkbaharda St. Petersburg'da düzenlenen İzleme Buluşması'nda konuştum.

Telgraf kanalı Victoria Metrikleri.

Ankete sadece kayıtlı kullanıcılar katılabilir. Giriş yapLütfen.

Prometheus için uzun vadeli depolama alanınız olarak VictoriaMetrics'e geçmenizi engelleyen şey nedir? (Yorumlara yazın, ankete ekleyeceğim)

• %71,4Prometheus5 kullanmıyorum

• %28,6VictoriaMetrics2'yi bilmiyordum

7 kullanıcı oy kullandı. 12 kişi çekimser kaldı.

Kaynak: habr.com