Biz Zabbixning TimescaleDB ma'lumotlar bazasi bilan backend sifatida qanday ishlashini ko'rib chiqamiz. Biz sizga noldan qanday boshlashni va PostgreSQL-dan qanday o'tishni ko'rsatamiz. Shuningdek, biz ikkita konfiguratsiyaning qiyosiy ishlash testlarini taqdim etamiz.
HighLoad++ Sibir 2019. Tomsk zali. 24-iyun, soat 16:00. Tezislar va . Keyingi HighLoad++ konferensiyasi 6 yilning 7 va 2020 aprel kunlari Sankt-Peterburgda bo‘lib o‘tadi. Tafsilotlar va chiptalar .
Andrey Gushchin (keyingi o'rinlarda - AG): – Men ZABBIX texnik yordam muhandisi (keyingi o‘rinlarda “Zabbix” deb yuritiladi), trenerman. Men texnik qo'llab-quvvatlash sohasida 6 yildan ortiq ishlayapman va ishlash bo'yicha bevosita tajribaga egaman. Bugun men TimescaleDB oddiy PostgreSQL 10 bilan solishtirganda taqdim eta oladigan samaradorlik haqida gapiraman. Shuningdek, uning qanday ishlashi haqida bir necha kirish qismi.
Yuqori mahsuldorlik muammolari: ma'lumotlarni yig'ishdan tortib ma'lumotlarni tozalashgacha
Boshlash uchun, har bir monitoring tizimi duch keladigan muayyan ishlash muammolari mavjud. Hosildorlikning birinchi muammosi ma'lumotlarni tez yig'ish va qayta ishlashdir.
Yaxshi monitoring tizimi barcha ma'lumotlarni tez, o'z vaqtida qabul qilishi, uni trigger ifodalari bo'yicha qayta ishlashi, ya'ni uni qandaydir mezonlar bo'yicha qayta ishlashi (turli tizimlarda bu boshqacha) va ushbu ma'lumotlardan foydalanish uchun ma'lumotlar bazasida saqlashi kerak. kelajak.
Ikkinchi ishlash muammosi - tarixni saqlash. Tez-tez ma'lumotlar bazasida saqlang va ma'lum vaqt davomida to'plangan ushbu ko'rsatkichlarga tez va qulay kirish imkoniyatiga ega bo'ling. Eng muhimi shundaki, ushbu ma'lumotlarni olish, uni hisobotlarda, grafiklarda, triggerlarda, ba'zi chegara qiymatlarida, ogohlantirishlar uchun va hokazolarda ishlatish qulay.
Uchinchi vazifa - bu tarixni tozalash, ya'ni siz 5 yil davomida (hatto oy yoki ikki oy) to'plangan har qanday batafsil ko'rsatkichlarni saqlashingiz shart bo'lmaydigan nuqtaga kelganingizda. Ba'zi tarmoq tugunlari o'chirildi yoki ba'zi xostlar, ko'rsatkichlar endi kerak emas, chunki ular allaqachon eskirgan va endi yig'ilmaydi. Ma'lumotlar bazasi juda katta bo'lmasligi uchun bularning barchasi tozalanishi kerak. Umuman olganda, tarixni tozalash ko'pincha saqlash uchun jiddiy sinovdir - bu ko'pincha ishlashga juda kuchli ta'sir qiladi.
Keshlash muammolarini qanday hal qilish mumkin?
Endi men Zabbix haqida alohida gaplashaman. Zabbix-da birinchi va ikkinchi qo'ng'iroqlar keshlash yordamida hal qilinadi.
Ma'lumotlarni yig'ish va qayta ishlash - Biz ushbu ma'lumotlarni saqlash uchun RAMdan foydalanamiz. Endi bu ma'lumotlar batafsilroq muhokama qilinadi.
Shuningdek, ma'lumotlar bazasi tomonida asosiy tanlovlar uchun ba'zi keshlar mavjud - grafiklar va boshqa narsalar uchun.
Zabbix serverining o'zi tomonida keshlash: bizda ConfigurationCache, ValueCache, HistoryCache, TrendsCache mavjud. Bu nima?
ConfigurationCache - bu biz ko'rsatkichlar, xostlar, ma'lumotlar elementlari, triggerlarni saqlaydigan asosiy kesh; oldindan ishlov berish, ma'lumotlarni to'plash, qaysi xostlardan, qaysi chastotada to'plash uchun kerak bo'lgan hamma narsa. Bularning barchasi ma'lumotlar bazasiga kirmaslik va keraksiz so'rovlarni yaratmaslik uchun ConfigurationCache-da saqlanadi. Server ishga tushirilgandan so'ng, biz ushbu keshni yangilaymiz (uni yaratamiz) va vaqti-vaqti bilan yangilaymiz (konfiguratsiya sozlamalariga qarab).
Zabbix-da keshlash. Ma'lumotlar yig'ish
Bu erda diagramma juda katta:
Sxemadagi asosiylari bu kollektorlar:
Bu yig'ish jarayonlarining o'zlari, har xil turdagi yig'ilishlar uchun mas'ul bo'lgan turli xil "pollerlar". Ular icmp, ipmi va turli protokollar orqali ma'lumotlarni to'playdi va barchasini oldindan qayta ishlashga o'tkazadi.
Oldindan ishlov berish tarixi keshi
Bundan tashqari, agar bizda hisoblangan ma'lumotlar elementlari bo'lsa (Zabbix bilan tanish bo'lganlar bilishadi), ya'ni hisoblangan, yig'ish ma'lumotlar elementlari, biz ularni to'g'ridan-to'g'ri ValueCache'dan olamiz. Qanday qilib to'ldirilganligini keyinroq aytib beraman. Ushbu kollektorlarning barchasi ConfigurationCache-dan o'z ishlarini olish uchun foydalanadi va keyin ularni oldindan qayta ishlashga o'tkazadi.
Oldindan ishlov berish, shuningdek, oldindan ishlov berish bosqichlarini olish va bu ma'lumotlarni turli yo'llar bilan qayta ishlash uchun ConfigurationCache-dan foydalanadi. 4.2 versiyasidan boshlab biz uni proksi-serverga o'tkazdik. Bu juda qulay, chunki oldindan ishlov berishning o'zi juda qiyin operatsiya. Va agar sizda ko'p sonli ma'lumotlar elementlari va yuqori yig'ish chastotasi bo'lgan juda katta Zabbix bo'lsa, bu ishni sezilarli darajada osonlashtiradi.
Shunga ko'ra, biz ushbu ma'lumotlarni oldindan qayta ishlash yordamida qandaydir tarzda qayta ishlaganimizdan so'ng, biz uni keyingi qayta ishlash uchun HistoryCache-da saqlaymiz. Bu ma'lumotlar yig'ishni yakunlaydi. Biz asosiy jarayonga o'tamiz.
Tarix sinxronlashtiruvchisi ishi
Zabbix-dagi asosiy jarayon (chunki u monolit arxitektura bo'lgani uchun) tarixni sinxronlashtiruvchidir. Bu har bir ma'lumot elementini, ya'ni har bir qiymatni atomik qayta ishlash bilan shug'ullanadigan asosiy jarayon:
- qiymat keladi (uni HistoryCache'dan oladi);
- Konfiguratsiya sinxronlagichida tekshiradi: hisoblash uchun triggerlar mavjudmi - ularni hisoblaydi;
agar mavjud bo'lsa - hodisalarni yaratadi, konfiguratsiyaga muvofiq, agar kerak bo'lsa, ogohlantirish yaratish uchun eskalatsiyani yaratadi; - keyingi qayta ishlash, yig'ish uchun triggerlarni qayd qiladi; agar siz oxirgi soat va hokazolarni jamlasangiz, tarix jadvaliga o'tmaslik uchun bu qiymat ValueCache tomonidan eslab qolinadi; Shunday qilib, ValueCache triggerlarni, hisoblangan elementlarni va hokazolarni hisoblash uchun zarur bo'lgan kerakli ma'lumotlar bilan to'ldiriladi;
- keyin History syncer barcha ma'lumotlarni ma'lumotlar bazasiga yozadi;
- ma'lumotlar bazasi ularni diskka yozadi - bu erda ishlov berish jarayoni tugaydi.
Ma'lumotlar bazasi. Keshlash
Ma'lumotlar bazasi tomonida, grafiklarni yoki voqealar haqidagi ba'zi hisobotlarni ko'rishni xohlaganingizda, turli xil keshlar mavjud. Ammo bu hisobotda men ular haqida gapirmayman.
MySQL uchun Innodb_buffer_pool va turli xil keshlar mavjud, ularni ham sozlash mumkin.
Ammo bular asosiylari:
- umumiy_buferlar;
- samarali_kesh_hajmi;
- umumiy_hovuz.
Barcha ma'lumotlar bazalari uchun men tez-tez so'rovlar uchun zarur bo'lgan ma'lumotlarni RAMda saqlashga imkon beruvchi ma'lum keshlar mavjudligini aytdim. Buning uchun ularning o'z texnologiyalari mavjud.
Ma'lumotlar bazasi ishlashi haqida
Shunga ko'ra, raqobat muhiti mavjud, ya'ni Zabbix serveri ma'lumotlarni to'playdi va yozib oladi. Qayta ishga tushirilganda, u ValueCache-ni to'ldirish uchun tarixdan ham o'qiydi va hokazo. Bu yerda siz veb-interfeysda qurilgan Zabbix API-dan foydalanadigan skriptlar va hisobotlarga ega bo'lishingiz mumkin. Zabbix API ma'lumotlar bazasiga kiradi va grafiklar, hisobotlar yoki voqealar ro'yxati, so'nggi muammolarni olish uchun kerakli ma'lumotlarni oladi.
Bundan tashqari, bizning foydalanuvchilarimiz foydalanadigan Grafana juda mashhur vizual echimdir. Zabbix API va ma'lumotlar bazasi orqali to'g'ridan-to'g'ri tizimga kirish imkoniyati. Shuningdek, u ma'lumotlarni olish uchun ma'lum bir raqobatni keltirib chiqaradi: natijalar va testlarni tezkor etkazib berishga moslashish uchun ma'lumotlar bazasini yanada nozik, yaxshiroq sozlash kerak.
Tarixni tozalash. Zabbixning uy bekasi bor
Zabbix-da ishlatiladigan uchinchi qo'ng'iroq - bu Housekeeper yordamida tarixni tozalash. Housekeeper barcha sozlamalarni kuzatib boradi, ya'ni bizning ma'lumotlar elementlari qancha vaqt saqlashni (kunlarda), tendentsiyalarni qancha vaqt saqlashni va o'zgarishlar dinamikasini ko'rsatadi.
Men TrendCache haqida gapirmadim, biz tezda hisoblaymiz: ma'lumotlar keladi, biz uni bir soat davomida yig'amiz (asosan bu oxirgi soatdagi raqamlar), miqdor o'rtacha/minimal va biz uni soatiga bir marta qayd qilamiz. o'zgarishlar dinamikasi jadvali ("Trendlar"). "Housekeeper" muntazam tanlovlar yordamida ma'lumotlar bazasidan ma'lumotlarni ishga tushiradi va o'chiradi, bu har doim ham samarali emas.
Bu samarasiz ekanligini qanday tushunish mumkin? Ichki jarayonlarning ishlash grafiklarida quyidagi rasmni ko'rishingiz mumkin:
Tarix sinxronizatoringiz doimo band (qizil grafik). Va tepada joylashgan "qizil" grafik. Bu ma'lumotlar bazasi o'zi ko'rsatgan barcha qatorlarni o'chirishni boshlaydigan va kutadigan "Uy bekasi".
Keling, bir nechta element identifikatorini olaylik: oxirgi 5 mingni o'chirishingiz kerak; Albatta, indekslar bo'yicha. Ammo odatda ma'lumotlar to'plami juda katta - ma'lumotlar bazasi hali ham uni diskdan o'qiydi va keshga joylashtiradi va bu ma'lumotlar bazasi uchun juda qimmat operatsiya. Uning o'lchamiga qarab, bu muayyan ishlash muammolariga olib kelishi mumkin.
Siz Housekeeper-ni oddiy usulda o'chirib qo'yishingiz mumkin - bizda tanish veb-interfeys mavjud. Umumiy ma'muriyat sozlamalari ("Uy xo'jayini" uchun sozlamalar) biz ichki tarix va tendentsiyalar uchun ichki uy ishlarini o'chirib qo'yamiz. Shunga ko'ra, uy bekasi endi buni nazorat qilmaydi:
Keyin nima qila olasiz? Siz uni o'chirib qo'ydingiz, grafiklaringiz tekislandi ... Bu holatda yana qanday muammolar paydo bo'lishi mumkin? Nima yordam berishi mumkin?
Bo'limlar (bo'limlar)
Odatda bu men sanab o'tgan har bir relyatsion ma'lumotlar bazasida boshqacha tarzda tuzilgan. MySQL-ning o'ziga xos texnologiyasi mavjud. Ammo PostgreSQL 10 va MySQL haqida gap ketganda, umuman olganda, ular juda o'xshash. Albatta, bularning barchasi qanday amalga oshirilganligi va barchasi ishlashga qanday ta'sir qilishida juda ko'p ichki farqlar mavjud. Ammo umuman olganda, yangi bo'limni yaratish ko'pincha muayyan muammolarga olib keladi.
O'rnatishingizga qarab (bir kunda qancha ma'lumot yaratasiz), ular odatda minimal miqdorni o'rnatadilar - bu 1 kun / to'plam, "trendlar" uchun esa o'zgarishlar dinamikasi - 1 oy / yangi partiya. Agar sizda juda katta sozlamalar mavjud bo'lsa, bu o'zgarishi mumkin.
Darhol o'rnatish hajmi haqida aytaylik: soniyada 5 mingtagacha yangi qiymatlar (nvps deb ataladi) - bu kichik "o'rnatish" deb hisoblanadi. O'rtacha - soniyada 5 dan 25 ming qiymatgacha. Yuqorida aytilganlarning barchasi allaqachon katta va juda katta o'rnatishlar bo'lib, ular ma'lumotlar bazasini juda ehtiyotkorlik bilan sozlashni talab qiladi.
Juda katta o'rnatishlarda 1 kun optimal bo'lmasligi mumkin. Men shaxsan MySQL-da kuniga 40 gigabaytlik bo'limlarni ko'rdim (va ko'proq bo'lishi mumkin). Bu juda katta hajmdagi ma'lumotlar, bu ba'zi muammolarga olib kelishi mumkin. Uni kamaytirish kerak.
Nima uchun sizga bo'linish kerak?
Bo'limni taqdim etadigan narsa, menimcha, hamma biladi, bu jadvalni bo'lishdir. Ko'pincha bu diskdagi alohida fayllar va so'rovlar oralig'i. Oddiy bo'limning bir qismi bo'lsa, u bitta bo'limni yanada maqbulroq tanlaydi.
Zabbix uchun, xususan, diapazon bo'yicha, diapazon bo'yicha ishlatiladi, ya'ni biz vaqt tamg'asidan foydalanamiz (muntazam raqam, davr boshidan beri vaqt). Siz kunning boshlanishini/kun oxirini belgilaysiz va bu bo'lim. Shunga ko'ra, agar siz ikki kunlik ma'lumotni so'rasangiz, hamma narsa ma'lumotlar bazasidan tezroq olinadi, chunki siz faqat bitta faylni keshga yuklashingiz va uni qaytarishingiz kerak (katta jadval o'rniga).
Ko'pgina ma'lumotlar bazalari qo'shishni tezlashtiradi (bitta bolalar jadvaliga kiritish). Men hozircha mavhum gapiryapman, lekin bu ham mumkin. Ko'pincha qismlarga ajratish yordam beradi.
NoSQL uchun Elasticsearch
Yaqinda 3.4 da biz NoSQL yechimini joriy qildik. Elasticsearch-da yozish qobiliyati qo'shildi. Siz ma'lum turlarni yozishingiz mumkin: siz tanlaysiz - yoki raqamlarni yoki ba'zi belgilarni yozing; bizda string matn bor, siz Elasticsearch-ga jurnallar yozishingiz mumkin... Shunga ko'ra, veb-interfeys Elasticsearch-ga ham kirishadi. Bu ba'zi hollarda juda yaxshi ishlaydi, lekin hozirda undan foydalanish mumkin.
TimescaleDB. Gipertablelar
4.4.2 uchun biz TimescaleDB kabi bir narsaga e'tibor qaratdik. Bu nima? Bu PostgreSQL uchun kengaytma, ya'ni u PostgreSQL-ning mahalliy interfeysiga ega. Bundan tashqari, ushbu kengaytma sizga vaqt seriyasidagi ma'lumotlar bilan ancha samarali ishlash va avtomatik qismlarga ajratish imkonini beradi. U qanday ko'rinishga ega:
Bu gipertable - Timescale-da shunday tushuncha mavjud. Bu siz yaratadigan giperjadval bo'lib, unda bo'laklar mavjud. Bo'laklar bo'limlar, bular bolalar jadvallari, agar adashmasam. Bu haqiqatan ham samarali.
TimescaleDB va PostgreSQL
TimescaleDB ishlab chiqaruvchilari ta'kidlaganidek, ular so'rovlarni, xususan, qo'shimchalarni qayta ishlash uchun yanada to'g'ri algoritmdan foydalanadilar, bu esa ma'lumotlar to'plami qo'shimchasining kattalashishi bilan taxminan doimiy ishlashga imkon beradi. Ya'ni, Postgres-ning 200 million qatoridan so'ng, odatdagisi juda pasayishni boshlaydi va unumdorligini tom ma'noda nolga tushiradi, Timescale esa har qanday miqdordagi ma'lumotlar bilan qo'shimchalarni iloji boricha samarali kiritish imkonini beradi.
TimescaleDB qanday o'rnatiladi? Hammasi oddiy!
Bu hujjatlarda, u tasvirlangan - uni har qanday paketlardan o'rnatishingiz mumkin... Bu rasmiy Postgres paketlariga bog'liq. Qo'lda kompilyatsiya qilish mumkin. Shunday qilib, ma'lumotlar bazasi uchun kompilyatsiya qilishim kerak edi.
Zabbix-da biz shunchaki kengaytmani faollashtiramiz. Menimcha, Postgres-da Kengaytmadan foydalanganlar... Siz shunchaki Kengaytmani faollashtirasiz, uni o'zingiz foydalanayotgan Zabbix ma'lumotlar bazasi uchun yaratasiz.
Va oxirgi qadam ...
TimescaleDB. Tarix jadvallarini ko'chirish
Giperjadval yaratishingiz kerak. Buning uchun maxsus funksiya mavjud - Gipertable yaratish. Unda birinchi parametr - bu ma'lumotlar bazasida zarur bo'lgan jadval (buning uchun siz giperjadval yaratishingiz kerak).
Yaratiladigan maydon va chunk_time_interval (bu qismlar oralig'i (ishlatilishi kerak bo'lgan bo'limlar). 86 - bir kun.
Migrate_data parametri: Agar siz rostga kiritsangiz, bu barcha joriy maʼlumotlarni oldindan yaratilgan boʻlaklarga koʻchiradi.
Men o'zim migrate_data dan foydalandim - bu sizning ma'lumotlar bazasi qanchalik kattaligiga qarab, etarli vaqtni oladi. Menda terabaytdan ortiq vaqt bor edi - yaratish uchun bir soatdan ko'proq vaqt ketdi. Ba'zi hollarda, test paytida men matn (history_text) va string (history_str) uchun tarixiy ma'lumotlarni ularni o'tkazmaslik uchun o'chirib tashladim - ular men uchun unchalik qiziq emas edi.
Va biz db_extention-da so'nggi yangilanishni amalga oshiramiz: biz timescaledb-ni ma'lumotlar bazasi va xususan, bizning Zabbix db_extension mavjudligini tushunishi uchun o'rnatamiz. U uni faollashtiradi va TimescaleDB uchun zarur bo'lgan "xususiyatlardan" foydalangan holda ma'lumotlar bazasiga to'g'ri sintaksis va so'rovlardan foydalanadi.
Server konfiguratsiyasi
Men ikkita serverdan foydalandim. Birinchi server - bu juda kichik virtual mashina, 20 protsessor, 16 gigabayt operativ xotira. Men unga Postgres 10.8 ni sozladim:
Operatsion tizim Debian, fayl tizimi xfs edi. Men ushbu ma'lumotlar bazasidan foydalanish uchun minimal sozlamalarni o'rnatdim, minus Zabbix o'zi foydalanadigan narsa. Xuddi shu mashinada Zabbix serveri, PostgreSQL va yuk agentlari mavjud edi.
Turli natijalarni tezda yaratish uchun LoadableModule-dan foydalanadigan 50 ta faol agentdan foydalandim. Ular satrlarni, raqamlarni va hokazolarni yaratganlar. Men ma'lumotlar bazasini juda ko'p ma'lumotlar bilan to'ldirdim. Dastlab, konfiguratsiya har bir xost uchun 5 ming ma'lumot elementini o'z ichiga olgan va taxminan har bir ma'lumot elementida trigger mavjud edi - bu haqiqiy sozlash bo'lishi uchun. Ba'zan foydalanish uchun bir nechta tetik kerak bo'ladi.
Men yangilanish oralig'ini va yukning o'zini nafaqat 50 ta agentdan (ko'proq qo'shish), balki dinamik ma'lumotlar elementlaridan foydalangan holda va yangilash oralig'ini 4 soniyagacha qisqartirish orqali tartibga soldim.
Ishlash testi. PostgreSQL: 36 ming NVP
Birinchi ishga tushirish, men qilgan birinchi sozlash ushbu uskunada sof PostreSQL 10-da bo'lgan (sekundiga 35 ming qiymat). Umuman olganda, ekranda ko'rib turganingizdek, ma'lumotlarni kiritish soniyaning bir qismini oladi - hamma narsa yaxshi va tez, SSD disklari (200 gigabayt). Bitta narsa shundaki, 20 GB juda tez to'ldiriladi.
Kelajakda bunday grafikalar juda ko'p bo'ladi. Bu standart Zabbix server ishlashi boshqaruv paneli.
Birinchi grafik soniyada qiymatlar soni (ko'k, chap yuqori), bu holda 35 ming qiymat. Bu (yuqori markaz) qurish jarayonlarini yuklash va bu (yuqori o'ngda) ichki jarayonlarni yuklash: bu erda (pastki markazda) ancha vaqtdan beri ishlayotgan tarix sinxronlashtiruvchilari va uy bekasi.
Ushbu grafik (pastki markaz) ValueCache-dan foydalanishni ko'rsatadi - triggerlar uchun qancha ValueCache urishi (soniyada bir necha ming qiymat). Yana bir muhim grafik - to'rtinchisi (pastki chap), bu men aytib o'tgan HistoryCache-dan foydalanishni ko'rsatadi, bu ma'lumotlar bazasiga kiritishdan oldin buferdir.
Ishlash testi. PostgreSQL: 50 ming NVP
Keyinchalik, xuddi shu uskunada yukni soniyasiga 50 ming qiymatgacha oshirdim. Housekeeper tomonidan yuklanganida, hisoblash bilan 10-2 soniyada 3 ming qiymat qayd etilgan. Aslida, quyidagi skrinshotda nima ko'rsatilgan:
"Uy bekasi" allaqachon ishga xalaqit bera boshladi, ammo umuman olganda, tarixiy tuzoqchilarga yuk hali ham 60% darajasida (uchinchi grafik, o'ng tomonda). Housekeeper ishlayotgan vaqtda HistoryCache allaqachon faol ravishda to'ldirishni boshlaydi (pastki chap). Taxminan yarim gigabayt, 20% to'lgan.
Ishlash testi. PostgreSQL: 80 ming NVP
Keyin men uni soniyasiga 80 ming qiymatga oshirdim:
Bu taxminan 400 ming ma'lumot elementi, 280 ming trigger edi. Ko'rib turganingizdek, tarixiy cho'tkalarning yuki (ularning 30 tasi bor edi) jihatidan ancha yuqori edi. Keyin men turli xil parametrlarni oshirdim: tarix sinkerlari, kesh... Ushbu uskunada tarix sinkerlaridagi yuk maksimal darajada, deyarli "javonda" ko'tarila boshladi - shunga ko'ra, HistoryCache juda katta yukga tushdi:
Shu vaqt ichida men barcha tizim parametrlarini (protsessor qanday ishlatilishini, RAM) kuzatdim va diskdan maksimal darajada foydalanishni aniqladim - men ushbu uskunada, ushbu virtual mashinada ushbu diskning maksimal hajmiga erishdim. "Postgres" bunday intensivlikda ma'lumotlarni juda faol tashlab yubora boshladi va diskda endi yozish, o'qish uchun vaqt yo'q edi ...
Men 48 protsessor va 128 gigabayt operativ xotiraga ega bo'lgan boshqa serverni oldim:
Men ham uni "sozladim" - History syncer (60 dona) o'rnatdim va maqbul ishlashga erishdim. Aslida, biz "javonda" emasmiz, lekin bu, ehtimol, unumdorlikning chegarasi bo'lib, u erda allaqachon biror narsa qilish kerak.
Ishlash testi. TimescaleDB: 80 ming NVP
Mening asosiy vazifam TimescaleDB dan foydalanish edi. Har bir grafik pasayishni ko'rsatadi:
Ushbu nosozliklar aniq ma'lumotlar ko'chishidir. Shundan so'ng, Zabbix serverida, ko'rib turganingizdek, tarix sinkerlarining yuklash profili juda o'zgardi. Bu sizga ma'lumotlarni deyarli 3 baravar tezroq kiritish va HistoryCache-dan kamroq foydalanish imkonini beradi - shunga ko'ra, ma'lumotlar o'z vaqtida yetkazib beriladi. Shunga qaramay, soniyada 80 ming qiymat - bu juda yuqori ko'rsatkich (albatta, Yandex uchun emas). Umuman olganda, bu bitta serverga ega bo'lgan juda katta o'rnatish.
PostgreSQL ishlash testi: 120 ming NVP
Keyinchalik, men ma'lumotlar elementlari sonining qiymatini yarim millionga oshirdim va soniyasiga 125 ming hisoblangan qiymatni oldim:
Va men bu grafiklarni oldim:
Asosan, bu ishlaydigan o'rnatish, u juda uzoq vaqt ishlashi mumkin. Ammo menda atigi 1,5 terabayt diskim borligi sababli, men uni bir necha kun ichida ishlatdim. Eng muhimi shundaki, bir vaqtning o'zida TimescaleDB-da yangi bo'limlar yaratildi va bu MySQL haqida gapirish mumkin bo'lmagan ishlash uchun mutlaqo sezilmadi.
Odatda, bo'limlar tunda yaratiladi, chunki bu odatda jadvallarni kiritish va ishlashni bloklaydi va xizmatning yomonlashishiga olib kelishi mumkin. Bunday holda, bunday emas! Asosiy vazifa TimescaleDB imkoniyatlarini sinab ko'rish edi. Natijada quyidagi ko'rsatkich paydo bo'ldi: soniyada 120 ming qiymat.
Jamiyatda ham misollar mavjud:
Inson shuningdek TimescaleDB-ni yoqdi va io.weight-dan foydalanish yuki protsessorga tushdi; TimescaleDB qo'shilishi tufayli ichki jarayon elementlaridan foydalanish ham kamaydi. Bundan tashqari, bu oddiy krep disklari, ya'ni oddiy disklardagi oddiy virtual mashina (SSD emas)!
Disk ishlashi bilan cheklangan ba'zi kichik sozlamalar uchun TimescaleDB, mening fikrimcha, juda yaxshi yechim. Bu sizga ma'lumotlar bazasi uchun tezroq uskunaga o'tishdan oldin ishlashni davom ettirish imkonini beradi.
Barchangizni tadbirlarimizga taklif qilaman: Moskvadagi konferentsiya, Rigadagi sammit. Bizning kanallarimizdan foydalaning - Telegram, forum, IRC. Agar sizda biron bir savol bo'lsa, bizning stolimizga keling, biz hamma narsani gaplashamiz.
Tomoshabinlar uchun savollar
Tomoshabinlar savoli (keyingi o'rinlarda - A): - Agar TimescaleDB ni sozlash juda oson bo'lsa va u shunday ishlashni kuchaytirsa, bu Zabbix-ni Postgres bilan sozlash uchun eng yaxshi amaliyot sifatida ishlatilishi kerakmi? Va bu yechimning kamchiliklari va kamchiliklari bormi yoki agar men o'zim uchun Zabbix qilishga qaror qilsam, Postgres-ni osongina olishim mumkin, Timescale-ni darhol o'rnataman, undan foydalaning va hech qanday muammo haqida o'ylamayman?
AG: – Ha, men buni yaxshi tavsiya deb aytardim: Postgres-dan darhol TimescaleDB kengaytmasi bilan foydalaning. Yuqorida aytib o'tganimdek, bu "xususiyat" eksperimental bo'lishiga qaramay, juda ko'p yaxshi sharhlar. Lekin aslida testlar shuni ko'rsatadiki, bu ajoyib yechim (TimescaleDB bilan) va menimcha, u rivojlanadi! Biz ushbu kengaytma qanday rivojlanishini kuzatib boramiz va kerak bo'lganda o'zgartirishlar kiritamiz.
Rivojlanish paytida ham biz ularning taniqli "xususiyatlaridan" biriga tayandik: bo'laklar bilan biroz boshqacha ishlash mumkin edi. Ammo keyin ular keyingi nashrda uni kesib tashlashdi va biz ushbu kodga tayanishni to'xtatishimiz kerak edi. Men ushbu yechimni ko'plab sozlamalarda ishlatishni tavsiya qilaman. Agar siz MySQL-dan foydalansangiz... O'rtacha o'rnatish uchun har qanday yechim yaxshi ishlaydi.
A: - Jamiyatning so'nggi grafiklarida "Uy bekasi" bilan grafik bor edi:
U ishlashda davom etdi. Housekeeper TimescaleDB bilan nima qiladi?
AG: - Endi men aniq ayta olmayman - kodni ko'rib chiqaman va sizga batafsilroq aytib beraman. U TimescaleDB so'rovlarini bo'laklarni o'chirish uchun emas, balki ularni qandaydir tarzda jamlash uchun ishlatadi. Men bu texnik savolga javob berishga hali tayyor emasman. Batafsil ma’lumotni bugun yoki ertaga stendda bilib olamiz.
A: - Menda shunga o'xshash savol bor - Timescale-da o'chirish operatsiyasining ishlashi haqida.
A (tomoshabinlar javobi): – Jadvaldagi ma’lumotlarni o‘chirib tashlaganingizda, agar buni o‘chirish orqali qilsangiz, jadvaldan o‘tishingiz kerak – o‘chiring, tozalang, kelajakdagi vakuum uchun hamma narsani belgilang. Vaqt shkalasida, sizda bo'laklar borligi sababli, siz tushirishingiz mumkin. Taxminan aytganda, siz katta hajmdagi faylga shunchaki aytasiz: "O'chirish!"
Vaqt shkalasi bunday bo'lak endi yo'qligini tushunadi. Va u so'rovlarni rejalashtiruvchiga kiritilganligi sababli, u tanlov yoki boshqa operatsiyalarda sizning shartlaringizni ushlab turish uchun ilgaklardan foydalanadi va bu bo'lak endi yo'qligini darhol tushunadi - "Men endi u erga bormayman!" (ma'lumotlar mavjud emas). Ana xolos! Ya'ni, jadvalni skanerlash ikkilik faylni o'chirish bilan almashtiriladi, shuning uchun u tezdir.
A: - Biz allaqachon SQL bo'lmagan mavzuga to'xtalib o'tdik. Men tushunganimdek, Zabbix haqiqatan ham ma'lumotlarni o'zgartirishga hojat yo'q va bularning barchasi jurnalga o'xshaydi. O'z ma'lumotlarini o'zgartira olmaydigan, lekin shu bilan birga tezroq saqlaydigan, to'playdigan va tarqatadigan maxsus ma'lumotlar bazalaridan foydalanish mumkinmi - Clickhouse, masalan, Kafkaga o'xshash narsa?.. Kafka ham jurnal! Ularni qandaydir tarzda birlashtirish mumkinmi?
AG: - Yukni tushirish mumkin. 3.4 versiyasidan boshlab bizda ma'lum bir "xususiyat" mavjud: siz barcha tarixiy fayllarni, voqealarni, qolgan narsalarni fayllarga yozishingiz mumkin; va keyin uni boshqa ma'lumotlar bazasiga biron bir ishlov beruvchi yordamida yuboring. Aslida, ko'p odamlar qayta ishlaydilar va to'g'ridan-to'g'ri ma'lumotlar bazasiga yozadilar. Tezda, tarix sinkerlari bularning barchasini fayllarga yozadilar, bu fayllarni aylantiradilar va hokazo, va siz buni Clickhouse-ga o'tkazishingiz mumkin. Rejalar haqida gapira olmayman, lekin NoSQL yechimlarini (masalan, Clickhouse) qo'llab-quvvatlash davom etishi mumkin.
A: - Umuman olganda, siz postgresdan butunlay xalos bo'lishingiz mumkinmi?
AG: - Albatta, Zabbix-ning eng qiyin qismi bu eng ko'p muammolar va voqealarni yaratadigan tarixiy jadvallar. Bunday holda, agar siz voqealarni uzoq vaqt saqlamasangiz va tarixni boshqa tezkor saqlashda tendentsiyalar bilan saqlasangiz, umuman olganda, menimcha, hech qanday muammo bo'lmaydi.
A: - Masalan, Clickhouse-ga o'tsangiz, hamma narsa qanchalik tez ishlashini taxmin qila olasizmi?
AG: - Men buni sinab ko'rmadim. Menimcha, hech bo'lmaganda bir xil raqamlarga oddiygina erishish mumkin, chunki Clickhouse o'z interfeysiga ega, ammo men aniq ayta olmayman. Sinov qilish yaxshiroqdir. Hammasi konfiguratsiyaga bog'liq: sizda qancha xostlar bor va hokazo. Qo'shish bir narsa, lekin siz ushbu ma'lumotlarni ham olishingiz kerak - Grafana yoki boshqa narsa.
A: - Shunday qilib, biz bu tezkor ma'lumotlar bazalarining katta afzalligi haqida emas, balki teng kurash haqida gapiramiz?
AG: - O'ylaymanki, biz integratsiyalashganimizda aniqroq sinovlar bo'ladi.
A: - Yaxshi eski RRD qayerga ketdi? SQL ma'lumotlar bazalariga o'tishingizga nima sabab bo'ldi? Dastlab, barcha ko'rsatkichlar RRDda to'plangan.
AG: - Zabbixda RRD bor edi, ehtimol juda qadimiy versiyada. Har doim SQL ma'lumotlar bazalari mavjud bo'lgan - klassik yondashuv. Klassik yondashuv MySQL, PostgreSQL (ular juda uzoq vaqtdan beri mavjud). Biz deyarli hech qachon SQL va RRD ma'lumotlar bazalari uchun umumiy interfeysdan foydalanmaganmiz.
Ba'zi reklamalar 🙂
Biz bilan qolganingiz uchun tashakkur. Bizning maqolalarimiz sizga yoqdimi? Ko'proq qiziqarli tarkibni ko'rishni xohlaysizmi? Buyurtma berish yoki do'stlaringizga tavsiya qilish orqali bizni qo'llab-quvvatlang, , Siz uchun biz tomonidan ixtiro qilingan boshlang'ich darajadagi serverlarning noyob analogi: (RAID1 va RAID10, 24 tagacha yadro va 40 Gb gacha DDR4 bilan mavjud).
Amsterdamdagi Equinix Tier IV ma'lumotlar markazida Dell R730xd 2 baravar arzonmi? Faqat shu yerda Gollandiyada! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 dollardan! Haqida o'qing
Manba: www.habr.com