Zabbix - bu monitoring tizimi. Boshqa har qanday tizim singari, u barcha monitoring tizimlarining uchta asosiy muammosiga duch keladi: ma'lumotlarni yig'ish va qayta ishlash, tarixni saqlash va tozalash.
Ma'lumotlarni qabul qilish, qayta ishlash va yozib olish bosqichlari vaqt talab etadi. Ko'p emas, lekin katta tizim uchun bu katta kechikishlarga olib kelishi mumkin. Saqlash muammosi ma'lumotlarga kirish muammosidir. Ular hisobotlar, tekshiruvlar va triggerlar uchun ishlatiladi. Ma'lumotlarga kirishdagi kechikishlar ham ishlashga ta'sir qiladi. Ma'lumotlar bazalari ko'payganda, ahamiyatsiz ma'lumotlarni o'chirish kerak. Olib tashlash qiyin operatsiya bo'lib, u ham ba'zi resurslarni iste'mol qiladi.
Zabbix-da yig'ish va saqlash vaqtida kechikishlar bilan bog'liq muammolar keshlash yo'li bilan hal qilinadi: bir necha turdagi keshlar, ma'lumotlar bazasida keshlash. Uchinchi muammoni hal qilish uchun keshlash mos emas, shuning uchun Zabbix TimescaleDB dan foydalangan. U sizga bu haqda aytib beradi Andrey Gushchin - texnik yordam muhandisi . Andrey Zabbixni 6 yildan ortiq vaqt davomida qo'llab-quvvatlab keladi va ishlash bo'yicha bevosita tajribaga ega.
TimescaleDB qanday ishlaydi, u oddiy PostgreSQL bilan solishtirganda qanday samaradorlikni berishi mumkin? Zabbix TimescaleDB ma'lumotlar bazasi uchun qanday rol o'ynaydi? Qanday qilib noldan boshlash kerak va PostgreSQL-dan qanday o'tish kerak va qaysi konfiguratsiya yaxshiroq ishlashga ega? Bularning barchasi haqida kesma ostida.
Hosildorlik muammolari
Har bir monitoring tizimi muayyan ishlash muammolariga duch keladi. Men ulardan uchtasi haqida gapiraman: ma'lumotlarni yig'ish va qayta ishlash, saqlash va tarixni tozalash.
Tez ma'lumotlarni yig'ish va qayta ishlash. Yaxshi monitoring tizimi barcha ma'lumotlarni tezda qabul qilishi va uni trigger ifodalari bo'yicha - uning mezonlariga muvofiq qayta ishlashi kerak. Qayta ishlashdan so'ng tizim ushbu ma'lumotlarni keyinchalik foydalanish uchun tezda ma'lumotlar bazasida saqlashi kerak.
Tarixni saqlash. Yaxshi monitoring tizimi tarixni ma'lumotlar bazasida saqlashi va ko'rsatkichlarga oson kirishni ta'minlashi kerak. Hisobotlar, grafiklar, triggerlar, chegaralar va hisoblangan ogohlantirish ma'lumotlari elementlarida tarixdan foydalanish kerak.
Tarixni tozalash. Ba'zan shunday kun keladiki, siz ko'rsatkichlarni saqlashingiz shart emas. Nima uchun sizga 5 yil, bir yoki ikki oy oldin to'plangan ma'lumotlar kerak: ba'zi tugunlar o'chirildi, ba'zi xostlar yoki ko'rsatkichlar endi kerak emas, chunki ular eskirgan va endi yig'ilmaydi. Yaxshi monitoring tizimi ma'lumotlar bazasi o'smasligi uchun tarixiy ma'lumotlarni saqlashi va vaqti-vaqti bilan o'chirib tashlashi kerak.
Eskirgan ma'lumotlarni tozalash ma'lumotlar bazasi ishlashiga katta ta'sir ko'rsatadigan muhim muammodir.
Zabbix-da keshlash
Zabbix-da birinchi va ikkinchi qo'ng'iroqlar keshlash yordamida hal qilinadi. RAM ma'lumotlarni yig'ish va qayta ishlash uchun ishlatiladi. Saqlash uchun - triggerlar, grafiklar va hisoblangan ma'lumotlar elementlaridagi tarix. Ma'lumotlar bazasi tomonida asosiy tanlovlar, masalan, grafiklar uchun ba'zi keshlar mavjud.
Zabbix serverining yon tomonidagi keshlash:
- ConfigurationCache;
- ValueCache;
- HistoryCache;
- TrendsCache.
Ularni batafsilroq ko'rib chiqing.
ConfigurationCache
Bu biz o'lchovlarni, xostlarni, ma'lumotlar elementlarini, triggerlarni - Oldindan ishlov berish va ma'lumotlarni yig'ish uchun kerak bo'lgan barcha narsalarni saqlaydigan asosiy keshdir.
Bularning barchasi ma'lumotlar bazasida keraksiz so'rovlarni yaratmaslik uchun ConfigurationCache-da saqlanadi. Server ishga tushirilgandan so'ng, biz ushbu keshni yangilaymiz, konfiguratsiyalarni yaratamiz va vaqti-vaqti bilan yangilaymiz.
Ma'lumotlar yig'ish
Diagramma juda katta, ammo undagi asosiy narsa terimchilar. Bular turli xil "pollerlar" - yig'ish jarayonlari. Ular yig'ishning har xil turlari uchun javobgardir: ular SNMP, IPMI orqali ma'lumotlarni to'playdi va barchasini PreProcessingga o'tkazadi.
Kollektorlar to'q sariq rangda tasvirlangan.
Zabbix cheklarni jamlash uchun zarur bo'lgan yig'ish elementlarini hisoblab chiqdi. Agar ular bizda bo'lsa, biz ular uchun ma'lumotlarni to'g'ridan-to'g'ri ValueCache'dan olamiz.
Oldindan ishlov berish tarixi keshi
Barcha kollektorlar ishlarni qabul qilish uchun ConfigurationCache-dan foydalanadilar. Keyin ularni PreProcessing-ga o'tkazadilar.
PreProcessing PreProcessing bosqichlarini olish uchun ConfigurationCache-dan foydalanadi. Bu ma'lumotlarni turli yo'llar bilan qayta ishlaydi.
PreProcessing yordamida ma'lumotlarni qayta ishlagandan so'ng, biz uni qayta ishlash uchun HistoryCache-ga saqlaymiz. Bu ma'lumotlar to'plashni tugatadi va biz Zabbix-dagi asosiy jarayonga o'tamiz - tarix sinxronlashtiruvchisi, chunki u monolit arxitektura.
Eslatma: Oldindan ishlov berish juda qiyin operatsiya. v 4.2 bilan u proksi-serverga ko'chirildi. Agar sizda ko'p sonli ma'lumotlar elementlari va yig'ish chastotasi bo'lgan juda katta Zabbix bo'lsa, bu ishni ancha osonlashtiradi.
ValueCache, tarix va tendentsiyalar keshi
History syncer - bu har bir ma'lumot elementini, ya'ni har bir qiymatni atomik tarzda qayta ishlaydigan asosiy jarayon.
Tarix sinxronlashtiruvchisi HistoryCache-dan qiymatlarni oladi va hisob-kitoblar uchun triggerlar mavjudligi uchun Konfiguratsiyani tekshiradi. Agar ular mavjud bo'lsa, u hisoblab chiqadi.
Tarix sinxronlashtiruvchisi hodisani, konfiguratsiya talab qilsa, ogohlantirishlarni yaratish uchun eskalatsiyani va yozuvlarni yaratadi. Agar keyingi ishlov berish uchun triggerlar mavjud bo'lsa, u tarix jadvaliga kirmaslik uchun ushbu qiymatni ValueCache-da saqlaydi. ValueCache triggerlar va hisoblangan elementlarni hisoblash uchun zarur bo'lgan ma'lumotlar bilan to'ldiriladi.
Tarix sinxronlashtiruvchisi barcha ma'lumotlarni ma'lumotlar bazasiga yozadi va u diskka yozadi. Qayta ishlash jarayoni shu erda tugaydi.
Ma'lumotlar bazasida keshlash
Ma'lumotlar bazasi tomonida siz hodisalar bo'yicha grafiklar yoki hisobotlarni ko'rishni xohlaganingizda turli xil keshlar mavjud:
Innodb_buffer_poolMySQL tomonida;shared_buffersPostgreSQL tomonida;effective_cache_sizeOracle tomonida;shared_poolDB2 tomonida.
Boshqa ko'plab keshlar mavjud, ammo bu barcha ma'lumotlar bazalari uchun asosiylari. Ular tez-tez so'rovlar uchun zarur bo'lgan ma'lumotlarni RAMda saqlashga imkon beradi. Buning uchun ularning o'z texnologiyalari mavjud.
Ma'lumotlar bazasining ishlashi juda muhim
Zabbix serveri doimiy ravishda ma'lumotlarni to'playdi va yozadi. Qayta ishga tushirilganda, u ValueCache-ni to'ldirish uchun tarixdan ham o'qiydi. Skriptlar va hisobotlardan foydalanadi Zabbix API, bu veb-interfeysda qurilgan. Zabbix API ma'lumotlar bazasiga kiradi va grafiklar, hisobotlar, voqealar ro'yxati va so'nggi muammolar uchun kerakli ma'lumotlarni oladi.
Vizualizatsiya uchun - grafana. Bu bizning foydalanuvchilarimiz orasida mashhur yechim. U Zabbix API va ma'lumotlar bazasi orqali so'rovlarni to'g'ridan-to'g'ri yuborishi mumkin va ma'lumotlarni qabul qilish uchun ma'lum bir raqobat yaratadi. Shuning uchun, natijalar va testlarni tez yetkazib berish uchun ma'lumotlar bazasini yanada nozik va yaxshiroq sozlash kerak.
Uy xo'jayini
Zabbix-dagi uchinchi ishlash muammosi - bu Housekeeper yordamida tarixni tozalash. U barcha sozlamalarga amal qiladi - ma'lumotlar elementlari kunlardagi o'zgarishlar (trendlar) dinamikasini qancha vaqt saqlash kerakligini ko'rsatadi.
Biz TrendsCache-ni tezda hisoblaymiz. Ma'lumotlar kelganda, biz uni bir soat davomida jamlaymiz va trend o'zgarishlar dinamikasi uchun jadvallarga yozamiz.
Uy bekasi odatdagi "tanlash" dan foydalangan holda ma'lumotlarni ma'lumotlar bazasidan boshlaydi va o'chiradi. Bu ichki jarayonlarning ishlash grafiklaridan ko'rinib turganidek, har doim ham samarali emas.
Qizil grafik Tarix sinxronlashtiruvchisi doimo band ekanligini ko'rsatadi. Yuqoridagi to'q sariq rangli grafik doimiy ravishda ishlaydigan Housekeeper. U ma'lumotlar bazasi o'zi ko'rsatgan barcha qatorlarni o'chirishni kutadi.
Housekeeperni qachon o'chirib qo'yish kerak? Masalan, "Item ID" mavjud va siz ma'lum vaqt ichida oxirgi 5 ming qatorni o'chirishingiz kerak. Albatta, bu indeks bo'yicha sodir bo'ladi. Ammo odatda ma'lumotlar to'plami juda katta va ma'lumotlar bazasi hali ham diskdan o'qiydi va uni keshga joylashtiradi. Bu har doim ma'lumotlar bazasi uchun juda qimmat operatsiya bo'lib, ma'lumotlar bazasi hajmiga qarab, ishlash muammolariga olib kelishi mumkin.
Uy xizmatchisini o'chirib qo'yish oson. Veb-interfeysda uy bekasi uchun "Umumiy ma'muriyat" sozlamasi mavjud. Biz ichki trend tarixi uchun ichki maishiy xizmatni o‘chirib qo‘yamiz va u endi uni boshqara olmaydi.
Uy bekasi o'chirildi, grafiklar tekislandi - bu holatda qanday muammolar bo'lishi mumkin va uchinchi ishlash muammosini hal qilishga nima yordam beradi?
Bo'lish - bo'lish yoki bo'lish
Odatda, bo'limlar men sanab o'tgan har bir relyatsion ma'lumotlar bazasida boshqacha tarzda tuzilgan. Har birining o'z texnologiyasi bor, lekin ular umuman olganda o'xshash. Yangi bo'limni yaratish ko'pincha muayyan muammolarga olib keladi.
Odatda, bo'limlar "sozlash" ga qarab sozlanadi - bir kunda yaratilgan ma'lumotlar miqdori. Qoida tariqasida, bo'linish bir kunda chiqariladi, bu minimaldir. Yangi partiyaning tendentsiyalari uchun - 1 oy.
Agar "o'rnatish" juda katta bo'lsa, qiymatlar o'zgarishi mumkin. Agar kichik "sozlash" 5 000 nvps (soniyada yangi qiymatlar) gacha bo'lsa, o'rtacha 5 000 dan 25 000 gacha bo'lsa, kattasi 25 000 nvps dan yuqori. Bu ma'lumotlar bazasini ehtiyotkorlik bilan sozlashni talab qiladigan katta va juda katta o'rnatishlar.
Juda katta o'rnatishlarda bir kunlik muddat optimal bo'lmasligi mumkin. Men kuniga 40 GB yoki undan ko'p MySQL bo'limlarini ko'rdim. Bu muammolarga olib kelishi mumkin bo'lgan va kamaytirilishi kerak bo'lgan juda katta hajmdagi ma'lumotlar.
Bo'linish nima beradi?
Bo'lim jadvallari. Ko'pincha bu diskdagi alohida fayllar. So'rovlar rejasi bitta bo'limni optimalroq tanlaydi. Odatda bo'linish diapazon bo'yicha qo'llaniladi - bu Zabbix uchun ham amal qiladi. Biz u erda "vaqt tamg'asi" dan foydalanamiz - davr boshidan beri. Bular biz uchun oddiy raqamlar. Siz kunning boshi va oxirini belgilaysiz - bu bo'lim.
Tez olib tashlash - DELETE. Oʻchirish uchun qatorlar tanlovi oʻrniga bitta fayl/pastki jadval tanlanadi.
Ma'lumotlarni qidirishni sezilarli darajada tezlashtiradi SELECT - butun jadvalni emas, balki bir yoki bir nechta bo'limlarni ishlatadi. Agar siz ikki kunlik ma'lumotlarga kirsangiz, u ma'lumotlar bazasidan tezroq olinadi, chunki siz faqat bitta faylni keshga yuklashingiz va katta jadvalni emas, balki uni qaytarishingiz kerak.
Ko'pincha ko'plab ma'lumotlar bazalari ham tezlashtirilgan INSERT - bolalar jadvaliga qo'shimchalar.
Vaqt shkalasi JB
v 4.2 uchun e'tiborimizni TimescaleDB ga qaratdik. Bu PostgreSQL uchun mahalliy interfeysga ega kengaytma. Kengaytma relyatsion ma'lumotlar bazalarining afzalliklarini yo'qotmasdan, vaqt seriyalari ma'lumotlari bilan samarali ishlaydi. TimescaleDB ham avtomatik ravishda qismlarga bo'linadi.
TimescaleDB kontseptsiyasiga ega gipertable (gipertable) siz yaratgan. U o'z ichiga oladi bo'laklar - bo'limlar. Bo'laklar avtomatik ravishda boshqariladigan gipertable fragmentlari bo'lib, boshqa fragmentlarga ta'sir qilmaydi. Har bir bo'lak o'z vaqt oralig'iga ega.
TimescaleDB va PostgreSQL
TimescaleDB haqiqatan ham samarali ishlaydi. Kengaytma ishlab chiqaruvchilari so'rovlarni qayta ishlashning yanada to'g'ri algoritmidan, xususan, inserts foydalanishlarini da'vo qilmoqdalar. Ma'lumotlar to'plamining qo'shimcha hajmi oshgani sayin, algoritm doimiy ishlashni saqlaydi.
200 million qatordan so'ng PostgreSQL odatda sezilarli darajada pasaya boshlaydi va unumdorligini 0 ga yo'qotadi. TimescaleDB istalgan hajmdagi ma'lumotlar uchun "qo'shimchalar" ni samarali kiritish imkonini beradi.
sozlama
TimescaleDB-ni o'rnatish har qanday paket uchun juda oson. IN hamma narsa batafsil tavsiflangan - bu rasmiy PostgreSQL paketlariga bog'liq. TimescaleDB qo'lda ham tuzilishi va kompilyatsiya qilinishi mumkin.
Zabbix ma'lumotlar bazasi uchun biz shunchaki kengaytmani faollashtiramiz:
echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix
Siz faollashtirasiz extension va uni Zabbix ma'lumotlar bazasi uchun yarating. Oxirgi qadam gipertable yaratishdir.
Tarix jadvallarini TimescaleDB ga ko'chirish
Buning uchun maxsus funktsiya mavjud create_hypertable:
SELECT create_hypertable(‘history’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_log’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_text’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_str’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
UPDATE config SET db_extension=’timescaledb’, hk_history_global=1, hk_trends_global=1
Funktsiya uchta parametrga ega. Birinchi - ma'lumotlar bazasidagi jadval, buning uchun siz giperjadval yaratishingiz kerak. Ikkinchi - maydonda, unga ko'ra siz yaratishingiz kerak chunk_time_interval — foydalaniladigan bo'linish bo'laklari oralig'i. Mening vaziyatimda interval bir kun - 86 400.
Uchinchi parametr - migrate_data. Agar siz o'rnatsangiz true, keyin barcha joriy ma'lumotlar oldindan yaratilgan bo'laklarga o'tkaziladi. Men o'zim ishlatganman migrate_data. Menda taxminan 1 TB bor edi, bu bir soatdan ko'proq vaqtni oldi. Hatto ba'zi hollarda, sinov paytida men ularni o'tkazmaslik uchun saqlash uchun talab qilinmaydigan belgilar turlarining tarixiy ma'lumotlarini o'chirib tashladim.
Oxirgi qadam - UPDATE: ichida db_extension qo'yish timescaledbShunday qilib, ma'lumotlar bazasi ushbu kengaytma mavjudligini tushunadi. Zabbix uni faollashtiradi va ma'lumotlar bazasiga sintaksis va so'rovlardan to'g'ri foydalanadi - TimescaleDB uchun zarur bo'lgan xususiyatlar.
Uskuna konfiguratsiyasi
Men ikkita serverdan foydalandim. Birinchi - VMware mashinasi. Bu juda kichik: 20 ta Intel® Xeon® CPU E5-2630 v 4 @ 2.20 gigagertsli protsessor, 16 GB operativ xotira va 200 GB SSD.
Men PostgreSQL 10.8 ni Debian 10.8-1.pgdg90+1 OS va xfs fayl tizimi bilan oʻrnatdim. Men ushbu ma'lumotlar bazasidan foydalanish uchun hamma narsani minimal darajada sozladim, minus Zabbix o'zi foydalanadigan narsa.
Xuddi shu mashinada Zabbix serveri, PostgreSQL va mavjud edi yuk agentlari. Menda 50 ta faol agentlar bor edi LoadableModulejuda tez turli xil natijalarni yaratish uchun: raqamlar, satrlar. Men ma'lumotlar bazasini juda ko'p ma'lumotlar bilan to'ldirdim.
Dastlab konfiguratsiya mavjud edi 5 000 element har bir xost uchun ma'lumotlar. Deyarli har bir elementda uni haqiqiy o'rnatishlarga o'xshash qilish uchun tetik mavjud. Ba'zi hollarda bir nechta tetik bor edi. Bitta tarmoq tugunlari uchun mavjud edi 3-000 tetiklar.
Ma'lumotlar elementini yangilash oralig'i - 4-7 soniya. Men nafaqat 50 ta agentdan foydalangan holda, balki ko'proq qo'shib yukni o'zi tartibga soldim. Bundan tashqari, ma'lumotlar elementlaridan foydalangan holda, men yukni dinamik ravishda sozladim va yangilanish oralig'ini 4 soniyagacha qisqartirdim.
PostgreSQL. 35 000 nvps
Mening ushbu uskunadagi birinchi ishim sof PostgreSQL-da bo'ldi - soniyada 35 ming qiymat. Ko'rib turganingizdek, ma'lumotlarni kiritish soniyalarning bir qismini oladi - hamma narsa yaxshi va tez. Bitta narsa shundaki, 200 GB SSD disk tezda to'ldiriladi.
Bu standart Zabbix server ishlashi boshqaruv paneli.
Birinchi ko'k grafik - soniyada qiymatlar soni. O'ngdagi ikkinchi grafik - qurilish jarayonlarining yuklanishi. Uchinchisi, ichki qurish jarayonlarini yuklash: tarix sinxronlashtiruvchilari va bu erda ancha vaqtdan beri ishlayotgan Housekeeper.
To'rtinchi grafik HistoryCache foydalanishni ko'rsatadi. Bu ma'lumotlar bazasiga kiritishdan oldin buferning bir turi. Yashil beshinchi grafik ValueCache-dan foydalanishni ko'rsatadi, ya'ni triggerlar uchun qancha ValueCache urilishi - bu soniyada bir necha ming qiymat.
PostgreSQL. 50 000 nvps
Keyin men xuddi shu uskunada yukni soniyasiga 50 ming qiymatga oshirdim.
Housekeeper-dan yuklashda 10 ming qiymatni kiritish 2-3 soniya davom etdi.
Uy bekasi allaqachon ishga aralasha boshlagan.
Uchinchi grafik shuni ko'rsatadiki, umuman olganda, trapperlar va tarix sinxronlashtiruvchilariga yuk hali ham 60% da. To'rtinchi grafikda HistoryCache allaqachon Housekeeper ishlashi paytida faol ravishda to'ldirila boshladi. U 20% to'lgan, bu taxminan 0,5 GB.
PostgreSQL. 80 000 nvps
Keyin men yukni soniyasiga 80 ming qiymatga oshirdim. Bu taxminan 400 ming ma'lumot elementi va 280 ming trigger.
O'ttizta tarix sinxronlagichini yuklash narxi allaqachon ancha yuqori.
Shuningdek, men turli parametrlarni oshirdim: tarix sinxronlashlari, keshlar.
Mening apparatimda tarix sinxronlashtiruvchilarining yuklanishi maksimal darajaga ko'tarildi. HistoryCache tezda ma'lumotlar bilan to'ldi - ishlov berish uchun ma'lumotlar buferda to'plangan.
Shu vaqt ichida men protsessor, operativ xotira va boshqa tizim parametrlaridan qanday foydalanilganini kuzatdim va diskdan foydalanish maksimal darajada ekanligini aniqladim.
Men foydalanishga erishdim maksimal disk imkoniyatlari ushbu uskunada va ushbu virtual mashinada. Bunday intensivlik bilan PostgreSQL ma'lumotlarni faol ravishda tozalashni boshladi va diskda endi yozish va o'qish uchun vaqt yo'q edi.
Ikkinchi server
Men allaqachon 48 protsessor va 128 GB operativ xotiraga ega bo'lgan boshqa serverni oldim. Men uni sozladim - uni 60 tarixiy sinxronlashtiruvchiga o'rnatdim va maqbul ishlashga erishdim.
Aslida, bu allaqachon biror narsa qilish kerak bo'lgan mahsuldorlikning chegarasi.
TimescaleDB. 80 000 nvps
Mening asosiy vazifam TimescaleDB imkoniyatlarini Zabbix yukiga qarshi sinab ko'rishdir. Bir soniyada 80 ming qiymat - bu juda ko'p, o'lchovlarni yig'ish chastotasi (albatta, Yandex-dan tashqari) va juda katta "sozlash".
Har bir grafikda pasayish mavjud - bu aniq ma'lumotlar migratsiyasi. Zabbix serveridagi nosozliklardan so'ng, tarix sinxronlashining yuklash profili juda o'zgardi - u uch marta kamaydi.
TimescaleDB sizga ma'lumotlarni deyarli 3 barobar tezroq kiritish va HistoryCache-dan kamroq foydalanish imkonini beradi.
Shunga ko'ra, siz ma'lumotlarni o'z vaqtida olasiz.
TimescaleDB. 120 000 nvps
Keyin ma'lumotlar elementlari sonini 500 mingga oshirdim asosiy vazifa TimescaleDB imkoniyatlarini sinab ko'rish edi - men soniyada 125 ming qiymatni oldim.
Bu uzoq vaqt davomida ishlashi mumkin bo'lgan ishlaydigan "sozlash". Ammo mening diskim atigi 1,5 TB bo'lganligi sababli, men uni bir necha kun ichida to'ldirdim.
Eng muhimi, bir vaqtning o'zida yangi TimescaleDB bo'limlari yaratildi.
Bu ishlash uchun mutlaqo sezilmaydi. Masalan, MySQL-da bo'limlar yaratilganda, hamma narsa boshqacha. Bu odatda tunda sodir bo'ladi, chunki u umumiy kiritishni bloklaydi, jadvallar bilan ishlaydi va xizmatning yomonlashishiga olib kelishi mumkin. TimescaleDB bilan bunday emas.
Misol tariqasida, men jamiyatdagi ko'pchilikning bitta grafikini ko'rsataman. Rasmda TimescaleDB yoqilgan, buning natijasida protsessorda io.weight-dan foydalanish yuki kamaydi. Ichki jarayon elementlaridan foydalanish ham kamaydi. Bundan tashqari, bu SSD emas, balki oddiy pancake disklaridagi oddiy virtual mashina.
topilmalar
TimescaleDB kichik "sozlash" uchun yaxshi yechimdir, bu diskning ishlashiga ta'sir qiladi. Bu sizga ma'lumotlar bazasi imkon qadar tezroq apparatga o'tkazilgunga qadar yaxshi ishlashni davom ettirish imkonini beradi.
TimescaleDB ni sozlash oson, unumdorlikni oshiradi, Zabbix va bilan yaxshi ishlaydi PostgreSQL ga nisbatan afzalliklarga ega.
Agar siz PostgreSQL-dan foydalansangiz va uni o'zgartirishni rejalashtirmasangiz, tavsiya qilaman Zabbix bilan birgalikda TimescaleDB kengaytmasi bilan PostgreSQL-dan foydalaning. Ushbu yechim o'rtacha "o'rnatish" ga qadar samarali ishlaydi.
"Yuqori ishlash" deganda biz tushunamiz . Xizmatlar millionlab foydalanuvchilarga xizmat ko‘rsatish imkonini beruvchi texnologiyalar va amaliyotlar bilan tanishish uchun ko‘p kutishingizga to‘g‘ri kelmaydi. Roʻyxat 7 va 8 noyabr kunlari biz allaqachon tuzganmiz, lekin bu erda ko'proq taklif qilish mumkin.
Bizning obuna bo'ling и , unda biz bo'lajak konferentsiyaning xususiyatlarini ochib beramiz va undan qanday qilib maksimal darajada foydalanishni bilib olamiz.
Manba: www.habr.com