Geçtiğimiz birkaç yılda, zaman serisi veritabanları tuhaf bir şeyden (açık izleme sistemlerinde (ve belirli çözümlere bağlı olarak) veya Büyük Veri projelerinde kullanılan son derece uzmanlaşmış) bir "tüketici ürününe" dönüştü. Rusya Federasyonu topraklarında bunun için Yandex ve ClickHouse'a özel teşekkür borçluyuz. Bu noktaya kadar, büyük miktarda zaman serisi verisini depolamanız gerekiyorsa, ya devasa bir Hadoop yığını oluşturma ve bunu sürdürme ihtiyacını kabul etmeniz ya da her sistem için ayrı ayrı protokollerle iletişim kurmanız gerekiyordu.
Görünüşe göre 2019'da TSDB'nin kullanılmaya değer olduğu bir makale yalnızca tek bir cümleden oluşacak: "sadece ClickHouse'u kullanın." Ama... nüanslar var.
Gerçekten de ClickHouse aktif olarak gelişiyor, kullanıcı tabanı büyüyor ve destek çok aktif, ancak diğer, belki de daha etkili/güvenilir çözümleri gölgede bırakan ClickHouse'un kamusal başarısının rehinesi mi olduk?
Geçen yılın başında kendi izleme sistemimizi elden geçirmeye başladık ve bu sırada veri depolamak için uygun bir veritabanı seçme sorunu ortaya çıktı. Burada bu seçimin tarihçesinden bahsetmek istiyorum.
Sorunun formüle edilmesi
Her şeyden önce gerekli bir önsöz. Neden kendi izleme sistemimize ihtiyacımız var ve bu nasıl tasarlandı?
2008 yılında destek hizmetleri vermeye başladık ve 2010 yılına gelindiğinde müşteri altyapısında meydana gelen süreçlerle ilgili verileri o dönemde var olan çözümlerle (Allah affetsin, Cacti, Zabbix'ten bahsediyoruz) toplamanın zorlaştığı ortaya çıktı. ve ortaya çıkan Grafit).
Temel gereksinimlerimiz şunlardı:
- tek bir sistemdeki istemcileri (o zamanlar - düzinelerce ve gelecekte - yüzlerce) desteklemek ve aynı zamanda merkezi bir uyarı yönetim sisteminin varlığı;
- uyarı sisteminin yönetilmesinde esneklik (görevli memurlar arasında uyarıların iletilmesi, planlama, bilgi tabanı);
- grafikleri derinlemesine detaylandırma yeteneği (o zamanlar Zabbix, grafikleri resim biçiminde oluşturuyordu);
- büyük miktarda verinin uzun süreli depolanması (bir yıl veya daha fazla) ve hızlı bir şekilde geri alma yeteneği.
Bu yazıda son noktayla ilgileniyoruz.
Depolamadan bahsetmişken gereksinimler aşağıdaki gibiydi:
- sistem hızlı çalışmalıdır;
- sistemin bir SQL arayüzüne sahip olması arzu edilir;
- sistem istikrarlı olmalı ve aktif bir kullanıcı tabanına ve desteğe sahip olmalıdır (artık geliştirilmeyen MemcacheDB veya hata izleyicisi Çince olarak tutulan MooseFS dağıtılmış depolama gibi sistemleri destekleme ihtiyacıyla karşı karşıya kaldığımızda: projemiz istemediği için bu hikayeyi tekrarlıyoruz);
- CAP teoremine uygunluk: Tutarlılık (gerekli) - veriler güncel olmalıdır, uyarı yönetim sisteminin yeni veriler almamasını ve tüm projeler için verilerin ulaşmaması konusunda uyarılar vermesini istemiyoruz; Bölüm Toleransı (gerekli) - Bölünmüş Beyin sistemine sahip olmak istemiyoruz; Kullanılabilirlik (etkin bir kopya varsa kritik değil) - bir kaza durumunda kod kullanarak yedekleme sistemine kendimiz geçiş yapabiliriz.
İşin garibi, o zamanlar MySQL'in bizim için ideal çözüm olduğu ortaya çıktı. Veri yapımız son derece basitti: sunucu kimliği, sayaç kimliği, zaman damgası ve değer; Geniş tampon havuzu ile sıcak verinin hızlı örneklenmesi, SSD ile geçmiş verinin örneklenmesi sağlandı.
Böylece, veriler tamamen işlenmeden önce ikinci 200 ms'ye kadar ayrıntıya sahip, iki haftalık taze veri örneğini elde ettik ve uzun süre bu sistemde yaşadık.
Bu arada zaman geçti ve veri miktarı arttı. 2016 yılına gelindiğinde veri hacimleri onlarca terabayta ulaştı ve bu, kiralanan SSD depolama bağlamında önemli bir masraftı.
Bu zamana kadar, sütunlu veritabanları aktif olarak yaygınlaştı ve biz de bunu aktif olarak düşünmeye başladık: sütunlu veritabanlarında veriler, anlayabileceğiniz gibi, sütunlarda depolanır ve verilerimize bakarsanız, büyük bir şeyi görmek kolaydır. Sütunlu bir veritabanı kullanıyorsanız, onu sıkıştırma kullanarak sıkıştırabilecek kopyaların sayısı.
Ancak şirketin ana sistemi istikrarlı bir şekilde çalışmaya devam etti ve ben başka bir şeye geçmeyi denemek istemedim.
2017 yılında San Jose'deki Percona Live konferansında Clickhouse geliştiricileri muhtemelen ilk kez kendilerini duyurdular. İlk bakışta sistem üretime hazırdı (Yandex.Metrica zorlu bir üretim sistemiydi), destek hızlı ve basitti ve en önemlisi operasyon basitti. 2018 yılından itibaren geçiş sürecini başlattık. Ancak o zamana kadar çok sayıda "yetişkin" ve zaman açısından test edilmiş TSDB sistemi vardı ve gereksinimlerimize göre Clickhouse'a alternatif çözüm olmadığından emin olmak için önemli ölçüde zaman ayırmaya ve alternatifleri karşılaştırmaya karar verdik.
Önceden belirtilen depolama gereksinimlerine ek olarak yenileri de ortaya çıktı:
- yeni sistem, aynı donanım miktarında en azından MySQL ile aynı performansı sağlamalıdır;
- yeni sistemin depolanması önemli ölçüde daha az yer kaplamalıdır;
- DBMS'nin yönetimi yine de kolay olmalıdır;
- DBMS'yi değiştirirken uygulamayı minimum düzeyde değiştirmek istedim.
Hangi sistemleri dikkate almaya başladık?
Apache Hive/Apache Impala
Eski, savaşta test edilmiş bir Hadoop yığını. Temel olarak, verileri HDFS'de yerel formatlarda depolamak üzerine kurulmuş bir SQL arayüzüdür.
Artıları.
- Kararlı çalışmayla verileri ölçeklendirmek çok kolaydır.
- Veri depolama (daha az alan) için sütun çözümleri mevcuttur.
- Kaynaklar mevcut olduğunda paralel görevlerin çok hızlı yürütülmesi.
Eksileri.
- Bu Hadoop ve kullanımı zor. Bulutta hazır bir çözüm almaya hazır değilsek (ve maliyet açısından da hazır değilsek), tüm yığının yöneticiler tarafından bir araya getirilmesi ve desteklenmesi gerekecek ve bunu gerçekten istemiyoruz. Bu.
- Veriler toplandı .
Ancak:
Hız, bilgi işlem sunucularının sayısını ölçeklendirerek elde edilir. Basitçe ifade etmek gerekirse, eğer analitikle ilgilenen büyük bir şirketsek ve işletme için bilgileri olabildiğince hızlı bir şekilde toplamak (büyük miktarda bilgi işlem kaynağı kullanma pahasına olsa bile) kritik öneme sahipse, bu bizim tercihimiz olabilir. Ancak görevleri hızlandırmak için donanım filosunu çoğaltmaya hazır değildik.
Druid/Pinot
Özellikle TSDB hakkında çok daha fazlası var, ancak yine Hadoop yığını.
Var .
Birkaç kelimeyle ifade edersek: Druid/Pinot aşağıdaki durumlarda Clickhouse'dan daha iyi görünür:
- Heterojen bir veri yapısına sahipsiniz (bizim durumumuzda, yalnızca sunucu ölçümlerinin zaman serilerini kaydediyoruz ve aslında bu bir tablodur. Ancak başka durumlar da olabilir: ekipman zaman serileri, ekonomik zaman serileri vb. - her biri toplanması ve işlenmesi gereken kendi yapısı).
- Üstelik bu verilerden çok var.
- Zaman serilerini içeren tablolar ve veriler görünüyor ve kayboluyor (yani, bazı veriler geldi, analiz edildi ve silindi).
- Verilerin bölümlenebileceği net bir kriter yoktur.
Tersi durumlarda ClickHouse daha iyi performans gösterir ve bizim durumumuz da budur.
Tıklama Evi
- SQL benzeri
- Yönetimi kolaydır.
- İnsanlar işe yaradığını söylüyor.
Test için kısa listeye alınır.
AkışDB
ClickHouse'a yabancı bir alternatif. Eksileri: Yüksek Kullanılabilirlik yalnızca ticari versiyonda mevcuttur, ancak karşılaştırılması gerekir.
Test için kısa listeye alınır.
Kötü olayları önceden haber veren kimse
Bir yandan, örneğin aşağıdaki gibi izleme sistemleri tarafından metrik zaman serilerini depolamak için kullanıldığını biliyoruz: veya OkMeter. Ancak ayrıntılar var.
Cassandra geleneksel anlamda sütunlu bir veritabanı değildir. Daha çok satır görünümüne benziyor ancak her satır farklı sayıda sütuna sahip olabilir, bu da sütunlu görünümü düzenlemeyi kolaylaştırır. Bu anlamda 2 milyar sütun sınırı ile bazı verileri sütunlarda (ve aynı zaman serisinde) saklamanın mümkün olduğu açıktır. Örneğin, MySQL'de 4096 sütun sınırı vardır ve aynısını yapmaya çalışırsanız 1117 koduyla ilgili bir hatayla karşılaşmanız kolaydır.
Cassandra motoru, büyük miktarlarda veriyi bir ana birim olmadan dağıtılmış bir sistemde depolamaya odaklanmıştır ve yukarıda bahsedilen Cassandra CAP teoremi daha çok AP ile, yani veri kullanılabilirliği ve bölümlenmeye karşı dirençle ilgilidir. Bu nedenle, yalnızca bu veritabanına yazmanız ve nadiren okumanız gerekiyorsa bu araç harika olabilir. Ve burada Cassandra'yı "soğuk" bir depo olarak kullanmak mantıklıdır. Yani, nadiren ihtiyaç duyulan ancak gerektiğinde geri alınabilen büyük miktardaki geçmiş verileri depolamak için uzun vadeli, güvenilir bir yer olarak. Bununla birlikte, bütünlüğü sağlamak adına onu da test edeceğiz. Ancak, daha önce de söylediğim gibi, seçilen veritabanı çözümü için kodu aktif olarak yeniden yazma arzusu yok, bu nedenle veritabanı yapısını Cassandra'nın özelliklerine uyarlamadan onu biraz sınırlı olarak test edeceğiz.
Prometheus
Meraktan dolayı Prometheus depolama performansını test etmeye karar verdik - mevcut çözümlerden daha hızlı mı yoksa daha yavaş mı olduğumuzu ve ne kadar hızlı olduğumuzu anlamak için.
Test metodolojisi ve sonuçları
Bu nedenle, 5 veritabanını aşağıdaki 6 konfigürasyonda test ettik: ClickHouse (1 düğüm), ClickHouse (3 düğüm için dağıtılmış tablo), InfluxDB, Mysql 8, Cassandra (3 düğüm) ve Prometheus. Test planı aşağıdaki gibidir:
- bir hafta boyunca geçmiş verileri yükleyin (günde 840 milyon değer; 208 bin metrik);
- bir kayıt yükü oluşturuyoruz (6 yükleme modu dikkate alındı, aşağıya bakın);
- Kayda paralel olarak, grafiklerle çalışan bir kullanıcının isteklerini taklit ederek periyodik olarak seçimler yapıyoruz. İşleri çok fazla karmaşıklaştırmamak için bir hafta boyunca 10 metrik (CPU grafiğinde tam olarak bu sayıda var) için veri seçtik.
Her metriğe 15 saniyede bir değer gönderen izleme aracımızın davranışını taklit ederek yükleme yapıyoruz. Aynı zamanda, aşağıdakileri çeşitlendirmekle de ilgileniyoruz:
- verilerin yazıldığı toplam metrik sayısı;
- değerleri bir metriğe gönderme aralığı;
- Parti boyutu.
Toplu iş boyutu hakkında. Deneysel veritabanlarımızın neredeyse tamamının tekli insert ile yüklenmesi önerilmediğinden, gelen metrikleri toplayıp gruplara ayırıp toplu insert olarak veritabanına yazan bir röleye ihtiyacımız olacaktır.
Ayrıca, alınan verilerin nasıl yorumlanacağını daha iyi anlamak için, yalnızca bir grup metrik göndermediğimizi, metriklerin sunucular halinde (sunucu başına 125 metrik) organize edildiğini hayal edelim. Burada sunucu yalnızca sanal bir varlıktır; örneğin 10000 ölçümün yaklaşık 80 sunucuya karşılık geldiğini anlamak için.
Ve burada tüm bunları hesaba katarak 6 veritabanı yazma yükleme modumuz var:
Burada iki nokta var. Birincisi, Cassandra için bu parti boyutlarının çok büyük olduğu ortaya çıktı, orada 50 veya 100 değerlerini kullandık. İkincisi, Prometheus kesinlikle çekme modunda çalıştığı için, yani. kendisi gider ve metrik kaynaklarından veri toplar (ve ismine rağmen pushgateway bile durumu temelden değiştirmez), karşılık gelen yükler, statik yapılandırmaların bir kombinasyonu kullanılarak uygulandı.
Test sonuçları aşağıdaki gibidir:
Kayda değer olan nedir: Prometheus'tan olağanüstü hızlı örnekler, Cassandra'dan son derece yavaş örnekler, InfluxDB'den kabul edilemeyecek kadar yavaş örnekler; Kayıt hızı açısından ClickHouse herkesi kazandı ve Prometheus yarışmaya katılmıyor çünkü ekleri kendisi yapıyor ve biz hiçbir şeyi ölçmüyoruz.
Bunun bir sonucu olarak,: ClickHouse ve InfluxDB kendilerini en iyileri olarak gösterdiler, ancak Influx'tan bir küme yalnızca Enterprise sürümü temelinde oluşturulabilir, bu da paraya mal olur, ClickHouse ise hiçbir maliyete sahip değildir ve Rusya'da yapılır. ABD'de seçimin muhtemelen inInfluxDB lehine olması, ülkemizde ise ClickHouse lehine olması mantıklıdır.
Kaynak: habr.com