Zabbix'in arka uç olarak TimescaleDB veritabanıyla nasıl çalıştığına bakacağız. Size sıfırdan nasıl başlayacağınızı ve PostgreSQL'den nasıl geçiş yapacağınızı göstereceğiz. Ayrıca iki konfigürasyonun karşılaştırmalı performans testlerini de sunacağız.
HighLoad++ Sibirya 2019. Tomsk Salonu. 24 Haziran 16:00. Tezler ve . Bir sonraki HighLoad++ konferansı 6 ve 7 Nisan 2020'de St. Petersburg'da gerçekleştirilecek. Ayrıntılar ve biletler .
Andrey Gushchin (bundan sonra – AG): – Ben bir ZABBIX teknik destek mühendisiyim (bundan böyle “Zabbix” olarak anılacaktır), bir eğitmenim. 6 yılı aşkın süredir teknik destek bölümünde çalışıyorum ve performans konusunda doğrudan deneyimim var. Bugün TimescaleDB'nin normal PostgreSQL 10 ile karşılaştırıldığında sağlayabileceği performanstan bahsedeceğim. Ayrıca genel olarak nasıl çalıştığına dair bir giriş kısmı da olacak.
En önemli üretkenlik zorlukları: veri toplamadan veri temizlemeye kadar
Başlangıç olarak, her izleme sisteminin karşılaştığı belirli performans zorlukları vardır. Üretkenliğin ilk zorluğu, verileri hızlı bir şekilde toplamak ve işlemektir.
İyi bir izleme sistemi, tüm verileri hızlı ve zamanında almalı, tetikleyici ifadelere göre işlemeli, yani bazı kriterlere göre (bu farklı sistemlerde farklıdır) işlemeli ve bu verileri veri tabanında kullanabilmek için bir veri tabanına kaydetmelidir. gelecek.
İkinci performans sorunu geçmiş depolamadır. Sık sık bir veritabanında saklayın ve belirli bir süre boyunca toplanan bu ölçümlere hızlı ve kolay erişim sağlayın. En önemlisi bu verinin elde edilmesi, raporlarda, grafiklerde, tetikleyicilerde, bazı eşik değerlerinde, uyarılarda vb. kullanıma uygun olmasıdır.
Üçüncü performans zorluğu geçmişi temizlemedir; yani 5 yıl (hatta aylar veya iki ay) boyunca toplanan herhangi bir ayrıntılı ölçümü saklamanıza gerek kalmadığı noktaya geldiğiniz zamandır. Bazı ağ düğümleri silindi veya bazı ana bilgisayarlar, zaten güncelliğini yitirdiğinden ve artık toplanmadığından metriklere artık ihtiyaç duyulmuyor. Veritabanınızın çok fazla büyümemesi için tüm bunların temizlenmesi gerekiyor. Genel olarak geçmişi temizlemek, depolama için çoğunlukla ciddi bir testtir; genellikle performans üzerinde çok güçlü bir etkiye sahiptir.
Önbellekleme sorunları nasıl çözülür?
Şimdi özellikle Zabbix’ten bahsedeceğim. Zabbix'te birinci ve ikinci çağrılar önbellekleme kullanılarak çözülür.
Veri toplama ve işleme - Tüm bu verileri depolamak için RAM kullanıyoruz. Bu veriler şimdi daha ayrıntılı olarak tartışılacaktır.
Ayrıca veritabanı tarafında, grafikler ve diğer şeyler için ana seçimler için bir miktar önbellekleme vardır.
Zabbix sunucusunun kendi tarafında önbelleğe alma: ConfigurationCache, ValueCache, HistoryCache, TrendsCache'e sahibiz. Ne olduğunu?
ConfigurationCache, metrikleri, ana bilgisayarları, veri öğelerini, tetikleyicileri sakladığımız ana önbellektir; Ön işlemeyi işlemek, veri toplamak, hangi ana bilgisayarlardan, hangi sıklıkta toplanacağınız için ihtiyacınız olan her şey. Veritabanına gitmemek ve gereksiz sorgular oluşturmamak için tüm bunlar ConfigurationCache'de saklanır. Sunucu başladıktan sonra bu önbelleği güncelleriz (oluştururuz) ve periyodik olarak (yapılandırma ayarlarına bağlı olarak) güncelleriz.
Zabbix'te önbelleğe alma. Veri toplama
Burada diyagram oldukça büyük:
Plandaki ana koleksiyoncular şu koleksiyonculardır:
Bunlar montaj süreçlerinin kendisidir, farklı montaj türlerinden sorumlu olan çeşitli “anketçiler”dir. Icmp, ipmi ve çeşitli protokoller aracılığıyla veri toplar ve hepsini ön işlemeye aktarırlar.
Geçmiş Önbelleğini Ön İşleme
Ayrıca hesaplanmış veri elemanlarımız varsa (Zabix'e aşina olanlar bilir), yani hesaplanmış, toplama veri elemanlarımız varsa, bunları doğrudan ValueCache'den alırız. Nasıl doldurulduğunu daha sonra anlatacağım. Tüm bu toplayıcılar, işlerini almak ve ardından ön işlemeye aktarmak için ConfigurationCache'i kullanır.
Ön işleme ayrıca ön işleme adımlarını elde etmek için ConfigurationCache'i kullanır ve bu verileri çeşitli şekillerde işler. 4.2 sürümünden itibaren onu bir proxy'ye taşıdık. Bu çok kullanışlıdır çünkü ön işlemenin kendisi oldukça zor bir işlemdir. Ve çok sayıda veri öğesine ve yüksek toplama sıklığına sahip çok büyük bir Zabbix'iniz varsa, bu, işi büyük ölçüde basitleştirir.
Buna göre bu verileri ön işlemeyi kullanarak bir şekilde işledikten sonra daha fazla işlenmek üzere HistoryCache'e kaydediyoruz. Bu, veri toplama işlemini tamamlar. Ana sürece geçiyoruz.
Geçmiş senkronize edicinin çalışması
Zabbix'teki ana süreç (yekpare bir mimari olduğundan) Tarih senkronizasyonudur. Bu, her veri öğesinin, yani her değerin atomik işlenmesiyle özel olarak ilgilenen ana süreçtir:
- değer gelir (bunu HistoryCache'den alır);
- Yapılandırma eşitleyicide kontrol edilir: hesaplama için herhangi bir tetikleyici olup olmadığı - bunları hesaplar;
varsa - yapılandırmaya göre gerekirse bir uyarı oluşturmak için olaylar oluşturur, yükseltme oluşturur; - sonraki işleme ve toplama için tetikleyicileri kaydeder; son bir saat içinde toplama yaparsanız, bu değer geçmiş tablosuna gitmemek için ValueCache tarafından hatırlanır; Böylece ValueCache, tetikleyicileri, hesaplanan öğeleri vb. hesaplamak için gerekli verilerle doldurulur;
- daha sonra Geçmiş eşitleyici tüm verileri veritabanına yazar;
- veritabanı bunları diske yazar; işlem sürecinin bittiği yer burasıdır.
Veri tabanı. Önbelleğe almak
Veritabanı tarafında olaylara ilişkin grafikleri veya bazı raporları görüntülemek istediğinizde çeşitli önbellekler bulunur. Ancak bu raporda bunlardan bahsetmeyeceğim.
MySQL için Innodb_buffer_pool ve ayrıca yapılandırılabilen bir dizi farklı önbellek vardır.
Ama başlıcaları bunlar:
- paylaşılan_bufferlar;
- etkili_önbellek_boyutu;
- ortak Havuz.
Tüm veritabanları için, sorgular için sıklıkla ihtiyaç duyulan verileri RAM'de saklamanıza olanak tanıyan belirli önbelleklerin bulunduğunu söyledim. Bunun için kendi teknolojileri var.
Veritabanı Performansı Hakkında
Buna göre rekabet ortamı oluşuyor yani Zabbix sunucusu verileri topluyor ve kaydediyor. Yeniden başlatıldığında ValueCache'i doldurmak için geçmişten de okur. Burada, bir web arayüzü üzerine kurulu olan Zabbix API'sini kullanan komut dosyalarına ve raporlara sahip olabilirsiniz. Zabbix API veritabanına girer ve grafikler, raporlar veya bir tür olay listesi, son sorunlar elde etmek için gerekli verileri alır.
Ayrıca çok popüler bir görselleştirme çözümü de kullanıcılarımızın kullandığı Grafana'dır. Hem Zabbix API'si hem de veritabanı üzerinden doğrudan giriş yapılabilir. Aynı zamanda veri elde etme konusunda da belirli bir rekabet yaratır: Sonuçların ve testlerin hızlı bir şekilde sunulmasına uyum sağlamak için veritabanının daha hassas ve daha iyi ayarlanması gerekir.
Geçmişi temizleme. Zabbix'in Temizlikçisi var
Zabbix'te kullanılan üçüncü çağrı, Housekeeper'ı kullanarak geçmişi temizlemektir. Housekeeper tüm ayarları takip eder, yani veri öğelerimiz ne kadar süre saklanacağını (gün olarak), trendlerin ne kadar süreyle saklanacağını ve değişim dinamiklerini gösterir.
Anında hesapladığımız TrendCache hakkında konuşmadım: veriler geliyor, bir saat boyunca topluyoruz (çoğunlukla bunlar son saatin rakamlarıdır), miktar ortalama/minimum ve saatte bir kayıt ediyoruz. değişim dinamikleri tablosu (“Eğilimler”) . “Housekeeper” düzenli seçimleri kullanarak veritabanındaki verileri başlatır ve siler; bu her zaman etkili değildir.
Etkisiz olduğu nasıl anlaşılır? İç süreçlerin performans grafiklerinde aşağıdaki resmi görebilirsiniz:
Geçmiş eşitleyiciniz sürekli meşgul (kırmızı grafik). Ve en üstteki “kırmızı” grafik. Bu, veritabanının belirttiği tüm satırları silmesini başlatan ve bekleyen bir "Kahya"dır.
Biraz Öğe Kimliği alalım: son 5 bini silmeniz gerekiyor; elbette indekslere göre. Ancak genellikle veri kümesi oldukça büyüktür - veritabanı onu hala diskten okur ve önbelleğe koyar ve bu, veritabanı için çok pahalı bir işlemdir. Boyutuna bağlı olarak bu, belirli performans sorunlarına yol açabilir.
Housekeeper'ı basit bir şekilde devre dışı bırakabilirsiniz; tanıdık bir web arayüzümüz var. Yönetim genelindeki ayarlar ("Temizlikçi" ayarları) dahili geçmiş ve trendler için dahili düzenlemeyi devre dışı bırakırız. Buna göre Housekeeper artık şunu kontrol etmiyor:
Bundan sonra ne yapabilirsiniz? Kapattınız, grafikleriniz düzeldi... Bu durumda başka ne gibi sorunlar ortaya çıkabilir? Ne yardımcı olabilir?
Bölümleme (bölümleme)
Genellikle bu, listelediğim her ilişkisel veritabanında farklı bir şekilde yapılandırılır. MySQL'in kendine ait bir teknolojisi vardır. Ancak genel olarak PostgreSQL 10 ve MySQL söz konusu olduğunda çok benzerler. Elbette bunların nasıl uygulandığı ve performansı nasıl etkilediği konusunda pek çok içsel farklılık var. Ancak genel olarak yeni bir bölümün oluşturulması çoğu zaman belirli sorunlara da yol açar.
Kurulumunuza bağlı olarak (bir günde ne kadar veri oluşturduğunuz), genellikle minimum değeri belirlerler - bu 1 gün / gruptur ve "trendler" için değişiklik dinamikleri - 1 ay / yeni gruptur. Çok büyük bir kurulumunuz varsa bu durum değişebilir.
Hemen kurulumun boyutunu söyleyelim: saniyede 5 bine kadar yeni değer (nvps olarak adlandırılır) - bu küçük bir "kurulum" olarak kabul edilecektir. Ortalama – saniyede 5 ila 25 bin değer. Yukarıda anlatılanların tümü, veritabanının çok dikkatli yapılandırılmasını gerektiren zaten büyük ve çok büyük kurulumlardır.
Çok büyük kurulumlarda 1 gün ideal olmayabilir. Ben şahsen MySQL'de günde 40 gigabaytlık bölümler gördüm (ve daha fazlası da olabilir). Bu, bazı sorunlara yol açabilecek çok büyük miktarda veridir. Azaltılması gerekiyor.
Neden bölümlemeye ihtiyacınız var?
Bölümlemenin sağladığı şey, sanırım herkesin bildiği gibi, tablo bölümlemedir. Genellikle bunlar diskteki ve yayılma isteklerindeki ayrı dosyalardır. Normal bölümlemenin parçasıysa bir bölümü daha iyi seçer.
Özellikle Zabbix için aralığa göre kullanılır, yani bir zaman damgası kullanırız (normal bir sayı, çağın başlangıcından bu yana geçen süre). Günün başlangıcını/günün sonunu belirtirsiniz ve bu bölümdür. Buna göre, iki günlük bir veri istiyorsanız, veritabanından her şey daha hızlı alınır, çünkü önbelleğe yalnızca bir dosya yükleyip onu geri döndürmeniz gerekir (büyük bir tablo yerine).
Birçok veritabanı aynı zamanda eklemeyi (bir alt tabloya ekleme) hızlandırır. Şimdilik soyut olarak konuşuyorum ama bu da mümkün. Parçalama çoğu zaman yardımcı olur.
NoSQL için Elasticsearch
Yakın zamanda 3.4'te bir NoSQL çözümü uyguladık. Elasticsearch'e yazma yeteneği eklendi. Belirli türleri yazabilirsiniz: siz seçersiniz - sayıları veya bazı işaretleri yazın; string text'imiz var, Elasticsearch'e log yazabilirsiniz... Buna göre web arayüzü de Elasticsearch'e erişecektir. Bu, bazı durumlarda harika çalışıyor, ancak şu anda kullanılabilir.
Zaman ÖlçeğiDB. Hipertablolar
4.4.2 için TimescaleDB gibi bir şeye dikkat ettik. Ne olduğunu? Bu PostgreSQL'in bir uzantısıdır, yani yerel bir PostgreSQL arayüzüne sahiptir. Ayrıca bu uzantı, zaman serisi verileriyle çok daha verimli çalışmanıza ve otomatik bölümlendirmeye sahip olmanıza olanak tanır. Ne gibi görünüyor:
Bu hipertable - Timescale'de böyle bir kavram var. Bu, sizin oluşturduğunuz bir hipertablodur ve parçalar içerir. Parçalar bölümlerdir, yanılmıyorsam bunlar alt tablolardır. Gerçekten etkili.
TimescaleDB ve PostgreSQL
TimescaleDB üreticilerinin temin ettiği gibi, sorguları, özellikle de eklemeleri işlemek için daha doğru bir algoritma kullanıyorlar, bu da onların veri kümesi ekleme boyutunun artmasıyla yaklaşık olarak sabit bir performansa sahip olmalarına olanak tanıyor. Yani, 200 milyon Postgres satırından sonra, olağan olan çok fazla sarkmaya başlar ve performansı tam anlamıyla sıfıra kadar kaybederken, Zaman Ölçeği, herhangi bir miktarda veriyle eklemeleri mümkün olduğunca verimli bir şekilde eklemenize olanak tanır.
TimescaleDB nasıl kurulur? Basit!
Belgelerde açıklanmıştır, herhangi bir paketten yükleyebilirsiniz... Resmi Postgres paketlerine bağlıdır. Manuel olarak derlenebilir. Öyle oldu ki veritabanı için derlemem gerekti.
Zabbix'te Uzantıyı etkinleştirmemiz yeterlidir. Postgres'te Extention'ı kullananlar sanırım... Extention'ı aktif hale getirip kullandığınız Zabbix veritabanı için oluşturmanız yeterli.
Ve son adım...
Zaman ÖlçeğiDB. Geçmiş tablolarının taşınması
Bir hiper tablo oluşturmanız gerekiyor. Bunun için özel bir fonksiyon var – Hipertablo oluştur. İçinde ilk parametre, bu veritabanında gerekli olan tablodur (bunun için bir hiper tablo oluşturmanız gerekir).
Oluşturulacak alan ve chunk_time_interval (bu, parçaların (kullanılması gereken bölümlerin) aralığıdır. 86 bir gündür.
Migrate_data parametresi: true değerini eklerseniz, bu, mevcut tüm verileri önceden oluşturulmuş parçalara taşıyacaktır.
Ben migrat_data'yı kullandım; veritabanınızın büyüklüğüne bağlı olarak oldukça zaman alıyor. Bir terabayttan fazla param vardı; oluşturulması bir saatten fazla sürdü. Bazı durumlarda, test sırasında metin (history_text) ve dize (history_str) için geçmiş verileri aktarmamak için sildim - bunlar benim için pek ilgi çekici değildi.
Ve db_extention'ımızda son güncellemeyi yapıyoruz: timescaledb'yi kuruyoruz, böylece veritabanı ve özellikle Zabbix'imiz db_extention'un olduğunu anlıyor. Onu etkinleştirir ve TimescaleDB için gerekli olan "özellikleri" kullanarak veritabanına yönelik doğru sözdizimini ve sorguları kullanır.
Sunucu yapılandırması
İki sunucu kullandım. İlk sunucu oldukça küçük bir sanal makine, 20 işlemci, 16 gigabayt RAM'dir. Üzerinde Postgres 10.8'i yapılandırdım:
İşletim sistemi Debian, dosya sistemi xfs'di. Bu özel veritabanını kullanmak için Zabbix'in kullanacağı ayarlar hariç minimum ayarlar yaptım. Aynı makinede bir Zabbix sunucusu, PostgreSQL ve yükleme aracıları vardı.
Hızlı bir şekilde farklı sonuçlar üretmek için LoadableModule kullanan 50 aktif aracı kullandım. Dizeleri, sayıları vb. üretenler onlardır. Veritabanını birçok veriyle doldurdum. Başlangıçta yapılandırma, ana bilgisayar başına 5 bin veri öğesi içeriyordu ve bunun gerçek bir kurulum olabilmesi için yaklaşık olarak her veri öğesi bir tetikleyici içeriyordu. Bazen kullanmak için birden fazla tetikleyiciye bile ihtiyacınız olur.
Güncelleme aralığını ve yükü yalnızca 50 aracı kullanarak (daha fazlasını ekleyerek) değil, aynı zamanda dinamik veri öğelerini kullanarak ve güncelleme aralığını 4 saniyeye düşürerek düzenledim.
Performans testi. PostgreSQL: 36 bin NVP
İlk lansmanım, ilk kurulumum bu donanım üzerinde saf PostreSQL 10 üzerindeydi (saniyede 35 bin değer). Genel olarak, ekranda görebileceğiniz gibi, veri eklemek bir saniyenin kesirleri kadar zaman alır - her şey iyi ve hızlıdır, SSD sürücüler (200 gigabayt). Tek şey, 20 GB'ın oldukça hızlı dolması.
Gelecekte bu tür grafikler oldukça fazla olacak. Bu standart bir Zabbix sunucu performansı kontrol panelidir.
İlk grafik saniyedeki değer sayısıdır (mavi, sol üst), bu durumda 35 bin değerdir. Bu (üst ortada) derleme süreçlerinin yüklenmesidir ve bu (sağ üstte) dahili süreçlerin yüklenmesidir: burada (alt ortada) oldukça uzun bir süredir çalışan geçmiş senkronizasyon cihazları ve temizlikçi.
Bu grafik (altta ortada) ValueCache kullanımını, yani tetikleyiciler için kaç ValueCache isabetinin olduğunu (saniyede birkaç bin değer) gösterir. Bir diğer önemli grafik ise veritabanına eklenmeden önce tampon görevi gören, bahsettiğim HistoryCache'in kullanımını gösteren dördüncü grafik (sol altta).
Performans testi. PostgreSQL: 50 bin NVP
Daha sonra aynı donanım üzerinde yükü saniyede 50 bin değere çıkardım. Housekeeper tarafından yüklendiğinde hesaplama ile 10-2 saniyede 3 bin değer kaydedildi. Aslında aşağıdaki ekran görüntüsünde gösterilen şey:
“Kahya” zaten işe karışmaya başlıyor, ancak genel olarak tarihe batan tuzakçıların üzerindeki yük hala% 60 seviyesinde (üçüncü grafik, sağ üst). HistoryCache, Housekeeper çalışırken aktif olarak dolmaya başlıyor (sol altta). Yaklaşık yarım gigabayttı, %20'si doluydu.
Performans testi. PostgreSQL: 80 bin NVP
Daha sonra saniyede 80 bin değere çıkardım:
Yaklaşık 400 bin veri elemanı, 280 bin tetikleyiciydi. Gördüğünüz gibi, geçmiş platinlerin yükü açısından ek (bunlardan 30 tane vardı) zaten oldukça yüksekti. Sonra çeşitli parametreleri artırdım: geçmiş platinleri, önbellek... Bu donanımda, geçmiş platinlerin üzerindeki yük neredeyse "rafta" maksimuma çıkmaya başladı - buna göre HistoryCache çok yüksek bir yüke girdi:
Bunca zaman boyunca tüm sistem parametrelerini (işlemcinin nasıl kullanıldığı, RAM) izledim ve disk kullanımının maksimum olduğunu keşfettim - bu diskin maksimum kapasitesini bu donanımda, bu sanal makinede elde ettim. "Postgres" bu yoğunlukta verileri oldukça aktif bir şekilde boşaltmaya başladı ve diskin artık yazmaya, okumaya zamanı yoktu...
Zaten 48 işlemciye ve 128 gigabayt RAM'e sahip başka bir sunucuyu aldım:
Ayrıca onu "ayarladım" - History senkronize ediciyi (60 parça) kurdum ve kabul edilebilir bir performans elde ettim. Aslında "rafta" değiliz, ancak bu muhtemelen üretkenliğin sınırıdır ve bu konuda zaten bir şeyler yapılmasının gerekli olduğu yerdir.
Performans testi. TimescaleDB: 80 bin NVP
Asıl görevim TimescaleDB'yi kullanmaktı. Her grafik bir düşüşü gösterir:
Bu hatalar tam olarak veri geçişidir. Bundan sonra Zabbix sunucusunda geçmiş platinlerin yükleme profili gördüğünüz gibi çok değişti. Verileri neredeyse 3 kat daha hızlı eklemenize ve HistoryCache'i daha az kullanmanıza olanak tanır; dolayısıyla veriler zamanında teslim edilir. Yine saniyede 80 bin değer oldukça yüksek bir oran (elbette Yandex için değil). Genel olarak bu, tek sunuculu oldukça büyük bir kurulumdur.
PostgreSQL performans testi: 120 bin NVP
Daha sonra veri elemanı sayısının değerini yarım milyona çıkardım ve saniyede 125 bin hesaplanan değeri aldım:
Ve şu grafikleri aldım:
Prensip olarak bu çalışan bir kurulumdur, oldukça uzun süre çalışabilir. Ancak elimde sadece 1,5 terabaytlık bir diskim olduğu için onu birkaç gün içinde tükettim. En önemlisi, aynı zamanda TimescaleDB'de yeni bölümlerin oluşturulması ve bunun performans açısından tamamen fark edilmemesidir ki MySQL için söylenemez.
Bölümler genellikle geceleri oluşturulur, çünkü bu genellikle tabloların eklenmesini ve tablolarla çalışmayı engeller ve hizmetin bozulmasına yol açabilir. Bu durumda durum böyle değil! Ana görev TimescaleDB'nin yeteneklerini test etmekti. Sonuç şu rakam oldu: Saniyede 120 bin değer.
Toplumda da örnekler var:
Kişi ayrıca TimescaleDB'yi de açtı ve io.weight kullanımının yükü işlemcinin üzerine düştü; TimescaleDB'nin dahil edilmesi nedeniyle dahili süreç öğelerinin kullanımı da azaldı. Üstelik bunlar sıradan gözleme diskleridir, yani sıradan diskler (SSD'ler değil) üzerindeki sıradan bir sanal makine!
Disk performansıyla sınırlı bazı küçük kurulumlar için TimescaleDB bence çok iyi bir çözüm. Veritabanı için daha hızlı donanıma geçmeden önce çalışmaya devam etmenize olanak tanır.
Hepinizi etkinliklerimize davet ediyorum: Moskova'da konferans, Riga'da zirve. Kanallarımızı kullanın - Telegram, forum, IRC. Sorularınız varsa masamıza gelin, her şeyi konuşabiliriz.
İzleyici Soruları
Dinleyicilerden gelen soru (bundan sonra - A): - TimescaleDB'nin yapılandırılması bu kadar kolaysa ve böyle bir performans artışı sağlıyorsa, o zaman belki de bu, Zabbix'i Postgres ile yapılandırmak için en iyi uygulama olarak kullanılmalıdır? Peki bu çözümün herhangi bir dezavantajı ve dezavantajı var mı, yoksa sonuçta Zabbix'i kendim yapmaya karar versem Postgres'i rahatlıkla alıp Timescale'i hemen oraya kurabilir, kullanabilir ve herhangi bir sorun düşünmez miyim?
AG: – Evet, bunun iyi bir öneri olduğunu söyleyebilirim: Postgres’i TimescaleDB uzantısıyla hemen kullanın. Daha önce de söylediğim gibi, bu "özelliğin" deneysel olmasına rağmen pek çok iyi inceleme var. Ancak aslında testler bunun harika bir çözüm olduğunu gösteriyor (TimescaleDB ile) ve gelişeceğini düşünüyorum! Bu uzantının nasıl geliştiğini izliyoruz ve gerektiğinde değişiklikler yapacağız.
Geliştirme sırasında bile onların iyi bilinen "özelliklerine" güvendik: parçalarla biraz farklı çalışmak mümkündü. Ama sonra bir sonraki sürümde bunu kaldırdılar ve biz de bu koda güvenmeyi bırakmak zorunda kaldık. Bu çözümü birçok kurulumda kullanmanızı tavsiye ederim. MySQL kullanıyorsanız... Ortalama kurulumlarda her çözüm işe yarar.
ve: – Topluluktan gelen son grafiklerde “Housekeeper” yazan bir grafik vardı:
Çalışmaya devam etti. Housekeeper TimescaleDB ile ne yapar?
AG: – Şimdi kesin bir şey söyleyemem – koda bakıp daha detaylı anlatacağım. TimescaleDB sorgularını parçaları silmek için değil, onları bir şekilde toplamak için kullanır. Bu teknik soruyu yanıtlamaya henüz hazır değilim. Daha fazlasını bugün veya yarın stantta öğreneceğiz.
ve: – Timescale'deki silme işleminin performansı hakkında da benzer bir sorum var.
C (dinleyicilerden gelen cevap): – Bir tablodan veri sildiğinizde, bunu silme yoluyla yapıyorsanız, o zaman tablonun üzerinden geçmeniz gerekir - gelecekteki boşluk için her şeyi silin, temizleyin, işaretleyin. Timescale'de parçalarınız olduğundan düşebilirsiniz. Kabaca söylemek gerekirse, büyük verinin içindeki dosyaya “Sil!” demeniz yeterli.
Timescale, böyle bir yığının artık var olmadığını anlıyor. Sorgu planlayıcıya entegre olduğundan, seçim veya diğer işlemlerdeki koşullarınızı yakalamak için kancalar kullanır ve bu yığının artık var olmadığını hemen anlar - "Artık oraya gitmeyeceğim!" (veri mevcut değil). Bu kadar! Yani, tablo taramasının yerini ikili dosya silme alır, dolayısıyla hızlıdır.
ve: – SQL dışı konusuna daha önce değinmiştik. Anladığım kadarıyla Zabbix'in verileri değiştirmesine gerçekten gerek yok ve bunların hepsi bir günlük gibi bir şey. Verilerini değiştiremeyen ama aynı zamanda çok daha hızlı kaydeden, biriktiren ve dağıtan özel veritabanları kullanmak mümkün mü? - Clickhouse, örneğin Kafka'ya benzer bir şey mi?.. Kafka da bir günlük! Bunları bir şekilde entegre etmek mümkün mü?
AG: - Boşaltma yapılabilir. Sürüm 3.4'ten bu yana belirli bir "özelliğimiz" var: tüm geçmiş dosyaları, olayları ve diğer her şeyi dosyalara yazabilirsiniz; ve sonra bunu bir işleyici kullanarak başka bir veritabanına gönderin. Aslında birçok kişi yeniden işliyor ve doğrudan veritabanına yazıyor. Geçmiş platinleri anında tüm bunları dosyalara yazar, bu dosyaları döndürür vb. ve siz de bunu Clickhouse'a aktarabilirsiniz. Planlar hakkında bir şey söyleyemem ama belki NoSQL çözümlerine (Clickhouse gibi) daha fazla destek devam edecektir.
ve: – Genel olarak postgreslerden tamamen kurtulabileceğiniz ortaya çıktı?
AG: – Elbette Zabbix'te en zor kısım, en çok sorun ve olay yaratan tarihi tablolardır. Bu durumda olayları uzun süre saklamazsanız ve trendleri içeren geçmişi başka bir hızlı depolamada saklarsanız genel olarak sorun olmayacağını düşünüyorum.
ve: – Örneğin Clickhouse'a geçerseniz her şeyin ne kadar hızlı çalışacağını tahmin edebilir misiniz?
AG: – Test etmedim. Clickhouse'un kendi arayüzüne sahip olduğu göz önüne alındığında, en azından aynı rakamların oldukça basit bir şekilde elde edilebileceğini düşünüyorum, ancak kesin olarak söyleyemem. Test etmek daha iyidir. Her şey yapılandırmaya bağlıdır: kaç tane ana makineniz var vb. Eklemek bir şeydir, ancak bu verileri de almanız gerekir - Grafana veya başka bir şey.
ve: – Yani bu hızlı veritabanlarının büyük avantajından değil de, eşit bir mücadeleden bahsediyoruz?
AG: – Entegrasyon yaptığımızda daha doğru testler olacağını düşünüyorum.
ve: – Eski güzel RRD nereye gitti? SQL veritabanlarına geçmenize ne sebep oldu? Başlangıçta tüm ölçümler RRD'de toplandı.
AG: – Zabbix'te muhtemelen çok eski bir versiyonda RRD vardı. Her zaman SQL veritabanları vardı; klasik bir yaklaşım. Klasik yaklaşım MySQL, PostgreSQL'dir (çok uzun zamandır varlar). SQL ve RRD veritabanları için neredeyse hiçbir zaman ortak bir arayüz kullanmadık.
Bazı reklamlar 🙂
Bizimle kaldığın için teşekkürler. Yazılarımızı beğeniyor musunuz? Daha ilginç içerik görmek ister misiniz? Sipariş vererek veya arkadaşlarınıza tavsiye ederek bize destek olun, , sizin için bizim tarafımızdan icat edilen benzersiz bir giriş seviyesi sunucu analoğu: (RAID1 ve RAID10, 24 adede kadar çekirdek ve 40 GB'a kadar DDR4 ile mevcuttur).
Amsterdam'daki Equinix Tier IV veri merkezinde Dell R730xd 2 kat daha mı ucuz? Sadece burada Hollanda'da! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99$'dan! Hakkında oku
Kaynak: habr.com