Pogledaćemo kako Zabbix radi sa TimescaleDB bazom podataka kao pozadinom. Pokazaćemo vam kako da počnete od nule i kako da migrirate sa PostgreSQL-a. Također ćemo pružiti uporedne testove performansi dvije konfiguracije.
HighLoad++ Sibir 2019. Tomsk Hall. 24. jun, 16:00. Teze i . Sljedeća HighLoad++ konferencija održat će se 6. i 7. aprila 2020. godine u Sankt Peterburgu. Detalji i ulaznice .
Andrey Gushchin (u daljem tekstu – AG): – Ja sam ZABBIX inženjer tehničke podrške (u daljem tekstu “Zabbix”), trener. Radim u tehničkoj podršci više od 6 godina i imao sam direktno iskustvo sa performansama. Danas ću govoriti o performansama koje TimescaleDB može da pruži u poređenju sa redovnim PostgreSQL 10. Takođe, neki uvodni deo o tome kako funkcioniše uopšte.
Najveći izazovi produktivnosti: od prikupljanja podataka do čišćenja podataka
Za početak, postoje određeni izazovi u pogledu performansi sa kojima se suočava svaki sistem praćenja. Prvi izazov produktivnosti je brzo prikupljanje i obrada podataka.
Dobar sistem za praćenje treba brzo, blagovremeno primiti sve podatke, obraditi ih prema trigger izrazima, odnosno obraditi ih prema nekim kriterijima (ovo je različito u različitim sistemima) i pohraniti ih u bazu podataka kako bi te podatke koristili u budućnost.
Drugi izazov performansi je skladištenje istorije. Često skladištite u bazi podataka i imajte brz i praktičan pristup ovim metrikama koje su prikupljene tokom određenog vremenskog perioda. Najvažnije je da je ove podatke zgodno dobiti, koristiti ih u izvještajima, grafikonima, okidačima, u nekim graničnim vrijednostima, za upozorenja itd.
Treći izazov performansi je čišćenje istorije, odnosno kada dođete do tačke u kojoj ne morate da pohranjujete detaljne metrike koje su prikupljane tokom 5 godina (čak i meseci ili dva meseca). Neki mrežni čvorovi su izbrisani, ili neki hostovi, metrika više nije potrebna jer su već zastarjela i više se ne prikupljaju. Sve ovo treba očistiti kako vaša baza podataka ne bi postala prevelika. Uopšteno govoreći, brisanje istorije je najčešće ozbiljan test za skladište - često ima veoma snažan uticaj na performanse.
Kako riješiti probleme s keširanjem?
Sada ću govoriti konkretno o Zabbixu. U Zabbixu, prvi i drugi poziv se rješavaju pomoću keširanja.
Prikupljanje i obrada podataka - Koristimo RAM za pohranjivanje svih ovih podataka. Ovi podaci će sada biti detaljnije razmotreni.
Također na strani baze podataka postoji keširanje za glavne odabire - za grafikone i druge stvari.
Keširanje na strani samog Zabbix servera: imamo ConfigurationCache, ValueCache, HistoryCache, TrendsCache. Šta je to?
ConfigurationCache je glavna predmemorija u kojoj pohranjujemo metrike, hostove, stavke podataka, okidače; sve što vam je potrebno za obradu predprocesiranja, prikupljanje podataka, sa kojih hostova prikupljati, s kojom frekvencijom. Sve se to pohranjuje u ConfigurationCache kako ne bi odlazili u bazu podataka i stvarali nepotrebne upite. Nakon što se server pokrene, ažuriramo ovu keš memoriju (kreiramo je) i povremeno je ažuriramo (u zavisnosti od postavki konfiguracije).
Keširanje u Zabbixu. Prikupljanje podataka
Ovdje je dijagram prilično velik:
Glavni u shemi su ovi kolektori:
To su sami procesi montaže, razni “polleri” koji su odgovorni za različite vrste sklopova. Oni prikupljaju podatke putem icmp, ipmi i raznih protokola i sve to prenose u pretprocesu.
Preprocessing HistoryCache
Takođe, ako imamo izračunate elemente podataka (znaju oni koji su upoznati sa Zabbixom), odnosno izračunate elemente podataka agregacije, preuzimamo ih direktno iz ValueCache-a. Kasnije ću vam reći kako se popunjava. Svi ovi sakupljači koriste ConfigurationCache za primanje svojih poslova, a zatim ih prosljeđuju u prethodnu obradu.
Prethodna obrada također koristi ConfigurationCache za dobivanje koraka predobrade i obrađuje ove podatke na različite načine. Počevši od verzije 4.2, premjestili smo ga na proxy. Ovo je vrlo zgodno, jer je sama predobrada prilično teška operacija. A ako imate vrlo veliki Zabbix, s velikim brojem elemenata podataka i velikom frekvencijom prikupljanja, onda to uvelike pojednostavljuje rad.
Shodno tome, nakon što smo ove podatke na neki način obrađivali koristeći prethodnu obradu, spremamo ih u HistoryCache kako bismo ih dalje obrađivali. Ovim je prikupljanje podataka završeno. Prelazimo na glavni proces.
Rad historije
Glavni proces u Zabbixu (pošto je monolitna arhitektura) je History syncer. Ovo je glavni proces koji se posebno bavi atomskom obradom svakog elementa podataka, odnosno svake vrijednosti:
- vrijednost dolazi (preuzima je iz HistoryCache-a);
- provjerava u Sinceru konfiguracije: da li postoje okidači za izračunavanje - izračunava ih;
ako postoji - kreira događaje, kreira eskalaciju radi kreiranja upozorenja, ako je potrebno prema konfiguraciji; - evidentira okidače za naknadnu obradu, agregaciju; ako agregirate tokom posljednjeg sata i tako dalje, ovu vrijednost pamti ValueCache kako ne bi išla u tabelu istorije; Dakle, ValueCache je ispunjen potrebnim podacima koji su neophodni za izračunavanje okidača, izračunatih elemenata, itd.;
- tada Sincer istorije upisuje sve podatke u bazu podataka;
- baza podataka ih zapisuje na disk - tu se proces obrade završava.
Baza podataka. Keširanje
Na strani baze podataka, kada želite da vidite grafikone ili neke izveštaje o događajima, postoje razne keš memorije. Ali u ovom izvještaju neću govoriti o njima.
Za MySQL postoji Innodb_buffer_pool i gomila različitih keš memorija koji se takođe mogu konfigurisati.
Ali ovo su glavne:
- shared_buffers;
- efektivna_cache_size;
- shared_pool.
Za sve baze podataka, rekao sam da postoje određene keš memorije koje vam omogućavaju da pohranite u RAM podatke koji su često potrebni za upite. Za to imaju svoje tehnologije.
O performansama baze podataka
Shodno tome, postoji konkurentsko okruženje, odnosno Zabbix server prikuplja podatke i bilježi ih. Kada se ponovo pokrene, takođe čita iz istorije da popuni ValueCache i tako dalje. Ovdje možete imati skripte i izvještaje koji koriste Zabbix API, koji je izgrađen na web interfejsu. Zabbix API ulazi u bazu podataka i prima potrebne podatke za dobijanje grafikona, izveštaja ili neke vrste liste događaja, nedavnih problema.
Također, vrlo popularno rješenje za vizualizaciju je Grafana, koju koriste naši korisnici. Može se direktno prijaviti i preko Zabbix API-ja i preko baze podataka. To takođe stvara određenu konkurenciju za dobijanje podataka: potrebno je finije, bolje podešavanje baze podataka da bi se uskladila sa brzim isporukom rezultata i testiranjem.
Brisanje istorije. Zabbix ima kućnu pomoćnicu
Treći poziv koji se koristi u Zabbixu je brisanje historije pomoću Housekeeper-a. Housekeeper prati sva podešavanja, odnosno naši elementi podataka pokazuju koliko dugo treba pohraniti (u danima), koliko dugo čuvati trendove i dinamiku promjena.
Nisam govorio o TrendCache-u koji izračunavamo u hodu: podaci stignu, agregiramo ih za jedan sat (uglavnom su to brojke za zadnji sat), količina je prosječna/minimalna i snimamo je jednom na sat u tabela dinamike promjena (“Trendovi”) . “Housekeeper” pokreće i briše podatke iz baze podataka koristeći uobičajene odabire, što nije uvijek efikasno.
Kako shvatiti da je neefikasan? Na grafovima performansi internih procesa možete vidjeti sljedeću sliku:
Vaš sinhronizator istorije je stalno zauzet (crveni grafikon). I „crveni“ grafikon koji ide na vrhu. Ovo je “Housekeeper” koji se pokreće i čeka da baza podataka izbriše sve redove koje je specificirala.
Uzmimo neki ID artikla: trebate izbrisati zadnjih 5 hiljada; naravno po indeksima. Ali obično je skup podataka prilično velik - baza podataka ga i dalje čita sa diska i stavlja u keš memoriju, a ovo je veoma skupa operacija za bazu podataka. Ovisno o njegovoj veličini, to može dovesti do određenih problema s performansama.
Domaćicu možete onemogućiti na jednostavan način - imamo poznato web sučelje. Postavke u općoj administraciji (postavke za „Housekeeper“) onemogućujemo interno održavanje za internu istoriju i trendove. U skladu s tim, Housekeeper više ne kontrolira ovo:
Šta možete učiniti sljedeće? Isključili ste ga, grafikoni su vam se izravnali... Kakvi bi problemi mogli nastati u ovom slučaju? Šta može pomoći?
Pregrađivanje (sekcioniranje)
Obično je ovo konfigurisano na drugačiji način u svakoj relacionoj bazi podataka koju sam naveo. MySQL ima sopstvenu tehnologiju. Ali sve u svemu, oni su vrlo slični kada su u pitanju PostgreSQL 10 i MySQL. Naravno, postoji mnogo internih razlika u tome kako se sve to implementira i kako sve to utiče na performanse. Ali općenito, stvaranje nove particije često također dovodi do određenih problema.
Ovisno o vašoj postavci (koliko podataka kreirate u jednom danu), obično postavljaju minimum - to je 1 dan / serija, a za "trendove", dinamiku promjena - 1 mjesec / nova serija. Ovo se može promijeniti ako imate vrlo veliko podešavanje.
Recimo odmah o veličini postavke: do 5 hiljada novih vrijednosti u sekundi (tzv. nvps) - ovo će se smatrati malim "postavkom". Prosjek – od 5 do 25 hiljada vrijednosti u sekundi. Sve što je gore navedeno su već velike i vrlo velike instalacije koje zahtijevaju vrlo pažljivu konfiguraciju baze podataka.
Na vrlo velikim instalacijama, 1 dan možda nije optimalan. Lično sam vidio particije na MySQL-u od 40 gigabajta dnevno (a možda ih ima i više). Ovo je vrlo velika količina podataka, što može dovesti do određenih problema. Treba ga smanjiti.
Zašto vam je potrebna particija?
Ono što Particioniranje pruža, mislim da svi znaju, je particioniranje tablice. Često su to zasebne datoteke na disku i zahtjevi za raspon. Optimalnije bira jednu particiju ako je dio normalnog particioniranja.
Za Zabbix se posebno koristi po opsegu, po opsegu, odnosno koristimo vremensku oznaku (regularni broj, vrijeme od početka epohe). Određujete početak dana/kraj dana, a ovo je particija. Shodno tome, ako tražite podatke koji su stari dva dana, sve se brže preuzima iz baze, jer je potrebno samo jedan fajl učitati u keš memoriju i vratiti ga (a ne veliku tabelu).
Mnoge baze podataka takođe ubrzavaju umetanje (umetanje u jednu podređenu tabelu). Za sada govorim apstraktno, ali i ovo je moguće. Podjela često pomaže.
Elasticsearch za NoSQL
Nedavno, u verziji 3.4, implementirali smo NoSQL rješenje. Dodata mogućnost pisanja u Elasticsearch. Možete pisati određene vrste: vi birate - ili pisati brojeve ili neke znakove; imamo string tekst, možete pisati dnevnike u Elasticsearch... Shodno tome, web interfejs će takođe pristupiti Elasticsearch-u. Ovo funkcionira odlično u nekim slučajevima, ali trenutno se može koristiti.
TimescaleDB. Hypertables
Za 4.4.2 obratili smo pažnju na jednu stvar kao što je TimescaleDB. Šta je to? Ovo je ekstenzija za PostgreSQL, odnosno ima izvorni PostgreSQL interfejs. Osim toga, ovo proširenje vam omogućava da radite mnogo efikasnije s podacima vremenskih serija i imate automatsko particioniranje. kako to izgleda:
Ovo je hipertabela - postoji takav koncept u Timescale-u. Ovo je hipertabela koju kreirate i sadrži delove. Komadići su particije, ovo su podređene tabele, ako se ne varam. Zaista je efikasan.
TimescaleDB i PostgreSQL
Kao što proizvođači TimescaleDB-a uvjeravaju, oni koriste ispravniji algoritam za obradu upita, posebno umetanja, što im omogućava da imaju približno konstantne performanse sa povećanjem veličine umetanja skupa podataka. Odnosno, nakon 200 miliona redova Postgresa, uobičajeni počinje jako da pada i gubi performanse bukvalno na nulu, dok Timescale omogućava da umetnete umetke što je moguće efikasnije sa bilo kojom količinom podataka.
Kako instalirati TimescaleDB? To je jednostavno!
U dokumentaciji je, opisano je - možete ga instalirati iz paketa za bilo koji... Zavisi od službenih Postgres paketa. Može se sastaviti ručno. Desilo se da sam morao kompajlirati za bazu podataka.
Na Zabbixu jednostavno aktiviramo Extention. Mislim da oni koji su koristili Extention u Postgresu... Jednostavno aktivirate Extention, kreirate ga za Zabbix bazu podataka koju koristite.
I poslednji korak...
TimescaleDB. Migracija istorijskih tabela
Morate kreirati hipertabelu. Za to postoji posebna funkcija – Kreiraj hipertabelu. U njemu je prvi parametar tabela koja je potrebna u ovoj bazi podataka (za koju trebate kreirati hipertabelu).
Polje po kojem se kreira, i chunk_time_interval (ovo je interval komada (particija koje treba koristiti). 86 je jedan dan.
Parametar Migrate_data: Ako umetnete na true, to će migrirati sve trenutne podatke u unaprijed kreirane komade.
I sam sam koristio migrate_data - potrebno je dosta vremena, ovisno o tome kolika je vaša baza podataka. Imao sam preko terabajta - bilo mi je potrebno više od sat vremena za stvaranje. U nekim slučajevima sam tokom testiranja obrisao istorijske podatke za tekst (history_text) i string (history_str) da ih ne bih prenio - nisu mi baš bili zanimljivi.
I vršimo posljednje ažuriranje u našem db_extention: instaliramo timescaledb tako da baza podataka i, posebno, naš Zabbix shvate da postoji db_extention. On ga aktivira i koristi ispravnu sintaksu i upite prema bazi podataka, koristeći one “karakteristike” koje su neophodne za TimescaleDB.
Konfiguracija servera
Koristio sam dva servera. Prvi server je prilično mala virtuelna mašina, 20 procesora, 16 gigabajta RAM-a. Na njemu sam konfigurisao Postgres 10.8:
Operativni sistem je bio Debian, a sistem datoteka je bio xfs. Napravio sam minimalne postavke za korištenje ove određene baze podataka, minus ono što će sam Zabbix koristiti. Na istoj mašini je bio Zabbix server, PostgreSQL i agenti za učitavanje.
Koristio sam 50 aktivnih agenata koji koriste LoadableModule za brzo generiranje različitih rezultata. Oni su ti koji su generirali nizove, brojeve i tako dalje. Popunio sam bazu podataka sa dosta podataka. U početku je konfiguracija sadržavala 5 hiljada elemenata podataka po hostu, a otprilike svaki element podataka je sadržavao okidač - da bi ovo bila prava postavka. Ponekad vam je čak potrebno više od jednog okidača za korištenje.
Regulirao sam interval ažuriranja i samo opterećenje ne samo korištenjem 50 agenata (dodavanjem više), već i korištenjem dinamičkih elemenata podataka i smanjivanjem intervala ažuriranja na 4 sekunde.
Test performansi. PostgreSQL: 36 hiljada NVP-a
Prvo lansiranje, prvo podešavanje koje sam imao bilo je na čistom PostreSQL 10 na ovom hardveru (35 hiljada vrijednosti u sekundi). Generalno, kao što možete vidjeti na ekranu, ubacivanje podataka traje djeliće sekunde - sve je dobro i brzo, SSD diskovi (200 gigabajta). Jedina stvar je da se 20 GB popuni prilično brzo.
U budućnosti će biti dosta ovakvih grafikona. Ovo je standardna kontrolna tabla performansi Zabbix servera.
Prvi grafikon je broj vrijednosti u sekundi (plavo, gore lijevo), u ovom slučaju 35 hiljada vrijednosti. Ovo (gore u sredini) je učitavanje procesa izgradnje, a ovo (gore desno) je učitavanje internih procesa: historijskih sincera i kućne pomoćnice, koji ovdje (donji centar) radi već neko vrijeme.
Ovaj grafikon (donji centar) prikazuje korištenje ValueCachea - koliko ValueCache pogodaka za okidače (nekoliko hiljada vrijednosti u sekundi). Još jedan važan grafikon je četvrti (dole lijevo), koji prikazuje upotrebu HistoryCache-a o kojem sam govorio, a koji je bafer prije umetanja u bazu podataka.
Test performansi. PostgreSQL: 50 hiljada NVP-a
Zatim sam povećao opterećenje na 50 hiljada vrijednosti u sekundi na istom hardveru. Prilikom učitavanja od strane Housekeeper-a, 10 hiljada vrijednosti je snimljeno za 2-3 sekunde sa proračunom. Šta je, u stvari, prikazano na sledećem snimku ekrana:
„Domaćer“ već počinje da ometa rad, ali generalno, opterećenje trapera za potapanje istorije i dalje je na nivou od 60% (treći grafikon, gore desno). HistoryCache se već počinje aktivno puniti dok je Housekeeper pokrenut (dolje lijevo). Bio je oko pola gigabajta, 20% pun.
Test performansi. PostgreSQL: 80 hiljada NVP-a
Zatim sam povećao na 80 hiljada vrijednosti u sekundi:
Bilo je oko 400 hiljada elemenata podataka, 280 hiljada okidača. Umetak je, kao što vidite, u smislu opterećenja historijskih potapača (bilo ih je 30) već bio prilično visok. Zatim sam povećao različite parametre: historijske sinkere, keš memoriju... Na ovom hardveru opterećenje historijskih sinkera počelo se povećavati do maksimuma, gotovo "na polici" - prema tome, HistoryCache je otišao u vrlo veliko opterećenje:
Sve ovo vrijeme pratio sam sve sistemske parametre (kako se koristi procesor, RAM) i otkrio da je iskorištenost diska maksimalna - postigao sam maksimalni kapacitet ovog diska na ovom hardveru, na ovoj virtuelnoj mašini. "Postgres" je počeo prilično aktivno da izbacuje podatke takvim intenzitetom, a disk više nije imao vremena za pisanje, čitanje...
Uzeo sam drugi server koji je već imao 48 procesora i 128 gigabajta RAM-a:
Takođe sam ga “naštimao” - instalirao History syncer (60 komada) i postigao prihvatljive performanse. Zapravo, nismo „na polici“, ali je to vjerovatno granica produktivnosti, gdje je već potrebno nešto poduzeti.
Test performansi. TimescaleDB: 80 hiljada NVP-a
Moj glavni zadatak je bio da koristim TimescaleDB. Svaki grafikon pokazuje pad:
Ovi propusti su upravo migracija podataka. Nakon toga, na Zabbix serveru, profil učitavanja historijskih sinkera se, kao što vidite, dosta promijenio. Omogućava vam da ubacite podatke skoro 3 puta brže i koristite manje HistoryCache – u skladu s tim, podaci će vam biti dostavljeni na vrijeme. Opet, 80 hiljada vrijednosti u sekundi je prilično visoka stopa (naravno, ne za Yandex). Sve u svemu, ovo je prilično velika postavka, sa jednim serverom.
PostgreSQL test performansi: 120 hiljada NVP-a
Zatim sam povećao vrijednost broja elemenata podataka na pola miliona i dobio izračunatu vrijednost od 125 hiljada u sekundi:
I dobio sam ove grafikone:
U principu, ovo je radna postavka, može raditi prilično dugo. Ali pošto sam imao samo disk od 1,5 terabajta, potrošio sam ga za nekoliko dana. Najvažnije je da su u isto vrijeme kreirane nove particije na TimescaleDB-u, a to je bilo potpuno neprimijećeno za performanse, što se ne može reći za MySQL.
Obično se particije kreiraju noću, jer to općenito blokira umetanje i rad sa tabelama i može dovesti do degradacije usluge. U ovom slučaju to nije slučaj! Glavni zadatak je bio testirati mogućnosti TimescaleDB-a. Rezultat je bio sljedeća brojka: 120 hiljada vrijednosti u sekundi.
Ima i primjera u zajednici:
Osoba je također uključila TimescaleDB i opterećenje pri korištenju io.weight je palo na procesor; i upotreba internih elemenata procesa je također smanjena zbog uključivanja TimescaleDB-a. Štoviše, ovo su obični palačinki diskovi, odnosno obična virtualna mašina na običnim diskovima (ne SSD-ovima)!
Za neke male postavke koje su ograničene performansama diska, TimescaleDB je, po mom mišljenju, vrlo dobro rješenje. To će vam omogućiti da nastavite s radom prije migracije na brži hardver za bazu podataka.
Pozivam vas sve na naše događaje: Konferencija u Moskvi, Samit u Rigi. Koristite naše kanale - Telegram, forum, IRC. Ako imate bilo kakvih pitanja, dođite do našeg stola, možemo razgovarati o svemu.
Pitanja publike
Pitanje iz publike (u daljem tekstu - A): - Ako je TimescaleDB tako jednostavan za konfiguraciju, a daje takvo povećanje performansi, onda bi to možda trebalo koristiti kao najbolju praksu za konfigurisanje Zabbixa sa Postgresom? I da li postoje neke zamke i nedostaci ovog rješenja, ili ipak, ako sam odlučio da napravim Zabbix za sebe, lako mogu uzeti Postgres, odmah instalirati Timescale tamo, koristiti ga i ne razmišljati o bilo kakvim problemima?
AG: – Da, rekao bih da je ovo dobra preporuka: odmah koristite Postgres sa ekstenzijom TimescaleDB. Kao što sam već rekao, dosta dobrih kritika, uprkos činjenici da je ova “karakteristika” eksperimentalna. Ali zapravo testovi pokazuju da je ovo odlično rješenje (sa TimescaleDB) i mislim da će se razvijati! Pratimo kako se ovo proširenje razvija i po potrebi ćemo izvršiti izmjene.
Čak i tokom razvoja, oslanjali smo se na jednu od njihovih dobro poznatih „karakteristiki“: bilo je moguće raditi sa komadima malo drugačije. Ali onda su to ukinuli u sljedećem izdanju i morali smo prestati da se oslanjamo na ovaj kod. Preporučio bih korištenje ovog rješenja na mnogim postavkama. Ako koristite MySQL... Za prosečna podešavanja, svako rešenje dobro funkcioniše.
O: – Na zadnjim grafovima iz zajednice bio je graf sa „domaćicom“:
Nastavio je sa radom. Šta Housekeeper radi sa TimescaleDB?
AG: – Sad ne mogu sa sigurnošću da kažem – pogledaću kod i reći ću vam detaljnije. Koristi TimescaleDB upite ne da izbriše komade, već da ih nekako agregira. Još nisam spreman da odgovorim na ovo tehničko pitanje. Više ćemo saznati na štandu danas ili sutra.
O: – Imam slično pitanje – o izvođenju operacije brisanja u Timescale-u.
O (odgovor iz publike): – Kada izbrišete podatke iz tabele, ako to radite preko delete, onda treba proći kroz tabelu – obrisati, očistiti, označiti sve za buduće usisavanje. U vremenskoj skali, pošto imate komade, možete ih ispustiti. Grubo govoreći, jednostavno kažete datoteci koja je u velikim podacima: „Izbriši!“
Timescale jednostavno razumije da takav komad više ne postoji. A pošto je integrisan u planer upita, koristi kuke da uhvati vaše uslove u selektivnim ili drugim operacijama i odmah shvata da ovaj deo više ne postoji - „Neću više ići tamo!“ (podaci nisu dostupni). To je sve! Odnosno, skeniranje tablice zamjenjuje se brisanjem binarne datoteke, tako da je brzo.
O: – Već smo se dotakli teme ne-SQL. Koliko sam shvatio, Zabbix zapravo ne treba mijenjati podatke, a sve je to nešto poput dnevnika. Da li je moguće koristiti specijalizovane baze podataka koje ne mogu da menjaju svoje podatke, ali u isto vreme mnogo brže spremaju, akumuliraju i distribuiraju - Clickhouse, na primer, nešto nalik Kafki?.. Kafka je takođe log! Da li ih je moguće nekako integrirati?
AG: - Može se izvršiti istovar. Od verzije 3.4 imamo određenu “karakteristiku”: možete pisati sve historijske datoteke, događaje, sve ostalo u datoteke; a zatim ga pošaljite u bilo koju drugu bazu podataka koristeći neki rukovalac. U stvari, mnogi ljudi prerađuju i pišu direktno u bazu podataka. U hodu, historijski sinkeri zapisuju sve ovo u fajlove, rotiraju ove fajlove i tako dalje, a vi to možete prenijeti u Clickhouse. Ne mogu reći o planovima, ali možda će se nastaviti dalja podrška za NoSQL rješenja (kao što je Clickhouse).
O: – Općenito, ispada da se postgresa možete potpuno riješiti?
AG: – Naravno, najteži dio u Zabbixu su istorijske tabele, koje stvaraju najviše problema i događaja. U ovom slučaju, ako ne pohranjujete događaje duže vrijeme i pohranjujete historiju sa trendovima u neko drugo brzo skladište, onda općenito, mislim, neće biti problema.
O: – Možete li procijeniti koliko će brže sve raditi ako pređete na Clickhouse, na primjer?
AG: – Nisam ga testirao. Mislim da se barem isti brojevi mogu postići sasvim jednostavno, s obzirom da Clickhouse ima svoj interfejs, ali ne mogu sa sigurnošću reći. Bolje je testirati. Sve zavisi od konfiguracije: koliko hostova imate i tako dalje. Umetanje je jedno, ali treba i ove podatke preuzeti - Grafana ili nešto drugo.
O: – Dakle, govorimo o ravnopravnoj borbi, a ne o velikoj prednosti ovih brzih baza podataka?
AG: – Mislim da će kada se integrišemo biti preciznijih testova.
O: – Gdje je nestao stari stari RRD? Šta vas je navelo da pređete na SQL baze podataka? U početku su se svi pokazatelji prikupljali na RRD-u.
AG: – Zabbix je imao RRD, možda u vrlo drevnoj verziji. Oduvijek su postojale SQL baze podataka – klasičan pristup. Klasični pristup je MySQL, PostgreSQL (postoje jako dugo). Gotovo nikada nismo koristili zajednički interfejs za SQL i RRD baze podataka.
Neke reklame 🙂
Hvala vam što ste ostali s nama. Da li vam se sviđaju naši članci? Želite li vidjeti još zanimljivih sadržaja? Podržite nas naručivanjem ili preporukom prijateljima, , jedinstveni analog servera početnog nivoa, koji smo mi izmislili za vas: (dostupno sa RAID1 i RAID10, do 24 jezgra i do 40GB DDR4).
Dell R730xd 2 puta jeftiniji u Equinix Tier IV data centru u Amsterdamu? Samo ovdje u Holandiji! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - od 99 USD! Pročitajte o
izvor: www.habr.com