Ogledali si bomo, kako Zabbix deluje z bazo podatkov TimescaleDB kot zaledjem. Pokazali vam bomo, kako začeti iz nič in kako se preseliti iz PostgreSQL. Zagotovili bomo tudi primerjalne teste delovanja obeh konfiguracij.
HighLoad++ Siberia 2019. Dvorana Tomsk. 24. junij, 16:00. Teze in . Naslednja konferenca HighLoad++ bo 6. in 7. aprila 2020 v St. Podrobnosti in vstopnice .
Andrej Guščin (v nadaljevanju – AG): – Sem inženir tehnične podpore ZABBIX (v nadaljevanju »Zabbix«), trener. V tehnični podpori delam že več kot 6 let in imam neposredne izkušnje z delovanjem. Danes bom govoril o zmogljivosti, ki jo lahko zagotovi TimescaleDB v primerjavi z običajnim PostgreSQL 10. Tudi nekaj uvodnega dela o tem, kako deluje na splošno.
Glavni izzivi produktivnosti: od zbiranja podatkov do čiščenja podatkov
Za začetek obstajajo določeni izzivi pri delovanju, s katerimi se sooča vsak nadzorni sistem. Prvi izziv produktivnosti je hitro zbiranje in obdelava podatkov.
Dober nadzorni sistem mora hitro, pravočasno prejeti vse podatke, jih obdelati po prožilnih izrazih, torej obdelati po nekem kriteriju (to je v različnih sistemih različno) in shraniti v podatkovno bazo, da bi te podatke uporabili v prihodnost.
Drugi izziv glede zmogljivosti je shranjevanje zgodovine. Pogosto shranjujte v bazi podatkov in imejte hiter in priročen dostop do teh meritev, ki so bile zbrane v določenem časovnem obdobju. Najpomembneje je, da je te podatke priročno pridobiti, uporabiti v poročilih, grafih, sprožilcih, v nekaterih mejnih vrednostih, za opozorila itd.
Tretji izziv glede učinkovitosti je čiščenje zgodovine, to je, ko pridete do točke, ko vam ni treba shranjevati podrobnih meritev, ki so bile zbrane v 5 letih (celo mesecih ali dveh mesecih). Nekatera omrežna vozlišča so bila izbrisana ali nekateri gostitelji, metrike niso več potrebne, ker so že zastarele in se ne zbirajo več. Vse to je treba počistiti, da se vaša zbirka podatkov ne poveča preveč. Na splošno je brisanje zgodovine najpogosteje resna preizkušnja za shranjevanje - pogosto zelo močno vpliva na zmogljivost.
Kako rešiti težave s predpomnjenjem?
Zdaj bom govoril posebej o Zabbixu. V Zabbixu sta prvi in drugi klic rešena s predpomnjenjem.
Zbiranje in obdelava podatkov – za shranjevanje vseh teh podatkov uporabljamo RAM. O teh podatkih bomo zdaj podrobneje razpravljali.
Tudi na strani baze podatkov obstaja nekaj predpomnjenja za glavne izbire - za grafe in druge stvari.
Predpomnjenje na strani samega strežnika Zabbix: imamo ConfigurationCache, ValueCache, HistoryCache, TrendsCache. Kaj je to?
ConfigurationCache je glavni predpomnilnik, v katerega shranjujemo metrike, gostitelje, podatkovne postavke, sprožilce; vse, kar potrebujete za obdelavo predprocesiranja, zbiranje podatkov, od katerih gostiteljev zbirati, s kakšno pogostostjo. Vse to je shranjeno v ConfigurationCache, da ne bi šli v bazo podatkov in ustvarjali nepotrebnih poizvedb. Po zagonu strežnika posodobimo ta predpomnilnik (ga ustvarimo) in ga občasno posodabljamo (odvisno od konfiguracijskih nastavitev).
Predpomnjenje v Zabbixu. Zbiranje podatkov
Tukaj je diagram precej velik:
Glavni v shemi so ti kolektorji:
To so sami procesi sestavljanja, različni »pollerji«, ki so odgovorni za različne vrste sestavov. Podatke zbirajo preko icmp, ipmi in raznih protokolov ter vse skupaj posredujejo v predobdelavo.
Predobdelava predpomnilnika zgodovine
Tudi če imamo izračunane podatkovne elemente (tisti, ki poznajo Zabbix vedo), torej izračunane, agregacijske podatkovne elemente, jih vzamemo direktno iz ValueCache. Pozneje vam bom povedal, kako se polni. Vsi ti zbiralniki uporabljajo ConfigurationCache za prejemanje svojih opravil in jih nato posredujejo v predprocesiranje.
Predhodna obdelava uporablja tudi ConfigurationCache za pridobitev korakov predhodne obdelave in obdelavo teh podatkov na različne načine. Od različice 4.2 smo ga premaknili v proxy. To je zelo priročno, saj je sama predprocesiranje precej težka operacija. In če imate zelo velik Zabbix, z velikim številom podatkovnih elementov in visoko frekvenco zbiranja, potem to močno poenostavi delo.
Skladno s tem, potem ko smo te podatke na nek način obdelali s predprocesiranjem, jih shranimo v predpomnilnik zgodovine, da jih lahko naprej obdelamo. S tem je zbiranje podatkov zaključeno. Prehajamo na glavni postopek.
Delo sinhronizatorja zgodovine
Glavni proces v Zabbixu (ker je monolitna arhitektura) je History syncer. To je glavni proces, ki se posebej ukvarja z atomsko obdelavo vsakega podatkovnega elementa, to je vsake vrednosti:
- vrednost pride (vzame jo iz HistoryCache);
- preveri v Configuration syncer: ali obstajajo sprožilci za izračun – izračuna jih;
če obstaja - ustvari dogodke, ustvari stopnjevanje, da ustvari opozorilo, če je potrebno glede na konfiguracijo; - beleži sprožilce za kasnejšo obdelavo, združevanje; če seštevate v zadnji uri in tako naprej, si to vrednost zapomni ValueCache, da ne gre v tabelo zgodovine; Tako je ValueCache napolnjen s potrebnimi podatki, ki so potrebni za izračun sprožilcev, izračunanih elementov itd.;
- nato History syncer zapiše vse podatke v bazo podatkov;
- podatkovna zbirka jih zapiše na disk - tu se postopek obdelave konča.
Baza podatkov. Predpomnjenje
Na strani baze podatkov, ko si želite ogledati grafe ali nekatera poročila o dogodkih, obstajajo različni predpomnilniki. Toda v tem poročilu ne bom govoril o njih.
Za MySQL obstaja Innodb_buffer_pool in kup različnih predpomnilnikov, ki jih je mogoče tudi konfigurirati.
Toda to so glavni:
- deljeni_medpomnilniki;
- efektivna_velikost_predpomnilnika;
- skupni_bazen.
Za vse zbirke podatkov sem rekel, da obstajajo določeni predpomnilniki, ki vam omogočajo shranjevanje podatkov, ki so pogosto potrebni za poizvedbe, v RAM. Za to imajo svoje tehnologije.
O zmogljivosti baze podatkov
V skladu s tem obstaja konkurenčno okolje, to pomeni, da strežnik Zabbix zbira podatke in jih beleži. Ko se znova zažene, bere tudi iz zgodovine, da zapolni ValueCache in tako naprej. Tukaj imate lahko skripte in poročila, ki uporabljajo Zabbix API, ki je zgrajen na spletnem vmesniku. Zabbix API vstopi v bazo podatkov in prejme potrebne podatke za pridobitev grafov, poročil ali neke vrste seznama dogodkov, nedavnih težav.
Zelo priljubljena rešitev za vizualizacijo je tudi Grafana, ki jo uporabljajo naši uporabniki. Možnost neposredne prijave prek API-ja Zabbix in baze podatkov. Prav tako ustvarja določeno konkurenco za pridobivanje podatkov: potrebna je natančnejša in boljša nastavitev podatkovne baze, da se zagotovi hitra dobava rezultatov in testiranje.
Brisanje zgodovine. Zabbix ima gospodinjo
Tretji klic, ki se uporablja v Zabbixu, je brisanje zgodovine z uporabo Housekeeperja. Housekeeper sledi vsem nastavitvam, torej naši podatkovni elementi kažejo, kako dolgo hraniti (v dnevih), kako dolgo hraniti trende in dinamiko sprememb.
Nisem govoril o TrendCache, ki ga računamo sproti: podatki pridejo, jih agregiramo eno uro (večinoma so to številke zadnje ure), količina je povprečna/minimalna in zabeležimo enkrat na uro v tabela dinamike sprememb (“Trendi”) . »Housekeeper« zažene in izbriše podatke iz baze z običajnimi izbirami, kar ni vedno učinkovito.
Kako razumeti, da je neučinkovit? Na grafih uspešnosti notranjih procesov lahko vidite naslednjo sliko:
Vaš sinhronizator zgodovine je nenehno zaseden (rdeč graf). In "rdeči" graf, ki je na vrhu. To je »Housekeeper«, ki se zažene in čaka, da zbirka podatkov izbriše vse vrstice, ki jih je določila.
Vzemimo ID artikla: izbrisati morate zadnjih 5 tisoč; seveda po indeksih. Toda običajno je nabor podatkov precej velik - zbirka podatkov ga še vedno prebere z diska in shrani v predpomnilnik, kar je za bazo podatkov zelo draga operacija. Odvisno od njegove velikosti lahko to povzroči določene težave pri delovanju.
Housekeeper lahko onemogočite na preprost način - imamo poznan spletni vmesnik. Nastavitve v General Administration (nastavitve za “Housekeeper”) onemogočimo notranje gospodinjstvo za interno zgodovino in trende. Skladno s tem Housekeeper tega ne nadzoruje več:
Kaj lahko storite naslednje? Izklopili ste ga, vaši grafi so se izravnali ... Kakšne težave bi lahko še nastale v tem primeru? Kaj lahko pomaga?
Pregrajevanje (razrezovanje)
Običajno je to konfigurirano na drugačen način za vsako relacijsko bazo podatkov, ki sem jo navedel. MySQL ima svojo tehnologijo. Toda na splošno sta si zelo podobna, ko gre za PostgreSQL 10 in MySQL. Seveda obstaja veliko notranjih razlik v tem, kako je vse to implementirano in kako vse to vpliva na zmogljivost. Toda na splošno ustvarjanje nove particije pogosto povzroči tudi določene težave.
Glede na vašo nastavitev (koliko podatkov ustvarite v enem dnevu) običajno določijo minimum - to je 1 dan / paket, za "trende" pa dinamiko sprememb - 1 mesec / nov paket. To se lahko spremeni, če imate zelo veliko nastavitev.
Takoj povejmo o velikosti nastavitve: do 5 tisoč novih vrednosti na sekundo (tako imenovani nvps) - to se bo štelo za majhno "nastavitev". Povprečje - od 5 do 25 tisoč vrednosti na sekundo. Vse, kar je zgoraj, so že velike in zelo velike instalacije, ki zahtevajo zelo skrbno konfiguracijo baze podatkov.
Pri zelo velikih namestitvah 1 dan morda ni optimalen. Osebno sem videl particije na MySQL 40 gigabajtov na dan (in morda jih je več). To je zelo velika količina podatkov, ki lahko privede do nekaterih težav. Treba ga je zmanjšati.
Zakaj potrebujete particioniranje?
Mislim, da vsi vedo, kar nudi particioniranje, je particioniranje tabel. Pogosto so to ločene datoteke na disku in zahteve po obsegu. Eno particijo izbere bolj optimalno, če je del običajne particije.
Predvsem za Zabbix se uporablja po razponu, po obsegu, torej uporabljamo časovni žig (redno število, čas od začetka epohe). Določite začetek dneva/konec dneva in to je particija. V skladu s tem, če zahtevate podatke, stare dva dni, se vse hitreje pridobi iz baze podatkov, ker morate v predpomnilnik naložiti samo eno datoteko in jo vrniti (namesto velike tabele).
Številne baze podatkov tudi pospešijo vstavljanje (vstavljanje v eno podrejeno tabelo). Zaenkrat govorim abstraktno, a tudi to je možno. Delitev pogosto pomaga.
Elasticsearch za NoSQL
Pred kratkim, v različici 3.4, smo implementirali rešitev NoSQL. Dodana možnost pisanja v Elasticsearch. Pišete lahko določene vrste: sami izberete - ali pišete številke ali nekaj znakov; imamo besedilo niza, lahko pišete dnevnike v Elasticsearch ... V skladu s tem bo spletni vmesnik tudi dostopal do Elasticsearch. To v nekaterih primerih deluje odlično, trenutno pa ga je mogoče uporabiti.
TimescaleDB. Hipertabele
Za 4.4.2 smo bili pozorni na eno stvar, kot je TimescaleDB. Kaj je to? To je razširitev za PostgreSQL, kar pomeni, da ima izvorni vmesnik PostgreSQL. Poleg tega vam ta razširitev omogoča veliko bolj učinkovito delo s podatki časovnih vrst in samodejno particioniranje. Kako je videti:
To je hipertabela - obstaja tak koncept v Timescale. To je hipertabela, ki jo ustvarite in vsebuje dele. Kosi so particije, to so podrejene tabele, če se ne motim. Res je učinkovito.
TimescaleDB in PostgreSQL
Kot zagotavljajo proizvajalci TimescaleDB, uporabljajo bolj pravilen algoritem za obdelavo poizvedb, zlasti vstavkov, ki omogoča približno konstantno zmogljivost z naraščajočo velikostjo vstavka podatkovnega niza. To pomeni, da po 200 milijonih vrstic Postgresa običajni začne zelo padati in izgubi zmogljivost dobesedno na nič, medtem ko vam Timescale omogoča čim bolj učinkovito vstavljanje vstavkov s poljubno količino podatkov.
Kako namestiti TimescaleDB? Enostavno je!
Je v dokumentaciji, je opisano - lahko ga namestite iz paketov za kateri koli ... Odvisno od uradnih paketov Postgres. Lahko se sestavi ročno. Tako se je zgodilo, da sem moral sestaviti za bazo podatkov.
Na Zabbixu preprosto aktiviramo razširitev. Mislim, da tisti, ki so uporabljali razširitev v Postgresu ... Preprosto aktivirate razširitev, jo ustvarite za bazo podatkov Zabbix, ki jo uporabljate.
In zadnji korak...
TimescaleDB. Selitev zgodovinskih tabel
Ustvariti morate hipertabelo. Za to obstaja posebna funkcija - Ustvari hipertabelo. V njej je prvi parameter tabela, ki je potrebna v tej bazi podatkov (za katero morate ustvariti hipertabelo).
Polje, po katerem želite ustvariti, in chunk_time_interval (to je interval kosov (particij, ki jih je treba uporabiti). 86 je en dan.
Parameter Migrate_data: če vstavite na true, bodo s tem vsi trenutni podatki preseljeni v vnaprej ustvarjene dele.
Sam sem uporabljal migrate_data - traja precej časa, odvisno od tega, kako velika je vaša zbirka podatkov. Imel sem več kot terabajt - ustvarjanje je trajalo več kot eno uro. V nekaterih primerih sem med testiranjem izbrisal zgodovinske podatke za besedilo (history_text) in niz (history_str), da jih ne bi prenesel - niso mi bili ravno zanimivi.
In naredimo zadnjo posodobitev v naši db_extention: namestimo timescaledb, tako da baza podatkov in zlasti naš Zabbix razume, da obstaja db_extention. Aktivira ga in uporablja pravilno sintakso in poizvedbe v zbirko podatkov z uporabo tistih »lastnosti«, ki so potrebne za TimescaleDB.
Konfiguracija strežnika
Uporabil sem dva strežnika. Prvi strežnik je dokaj majhen virtualni stroj, 20 procesorjev, 16 gigabajtov RAM-a. Na njem sem konfiguriral Postgres 10.8:
Operacijski sistem je bil Debian, datotečni sistem xfs. Naredil sem minimalne nastavitve za uporabo te posebne baze podatkov, brez tistega, kar bo uporabljal sam Zabbix. Na istem računalniku je bil strežnik Zabbix, PostgreSQL in agenti za nalaganje.
Uporabil sem 50 aktivnih agentov, ki uporabljajo LoadableModule za hitro ustvarjanje različnih rezultatov. Oni so tisti, ki so ustvarili nize, številke itd. Bazo sem napolnil z veliko podatki. Na začetku je konfiguracija vsebovala 5 tisoč podatkovnih elementov na gostitelja in približno vsak podatkovni element je vseboval sprožilec - da bi bila to prava nastavitev. Včasih potrebujete celo več kot en sprožilec.
Interval posodabljanja in samo nalaganje sem reguliral tako, da sem poleg uporabe 50 agentov (dodal še več), uporabil tudi dinamične podatkovne elemente in zmanjšal interval posodabljanja na 4 sekunde.
Test delovanja. PostgreSQL: 36 tisoč NVP
Prvi zagon, prva nastavitev, ki sem jo imel, je bila na čistem PostreSQL 10 na tej strojni opremi (35 tisoč vrednosti na sekundo). Na splošno, kot lahko vidite na zaslonu, vstavljanje podatkov traja delček sekunde - vse je dobro in hitro, SSD diski (200 gigabajtov). Edino 20 GB se kar hitro napolni.
Takih grafov bo v prihodnosti še kar veliko. To je standardna nadzorna plošča zmogljivosti strežnika Zabbix.
Prvi graf je število vrednosti na sekundo (modra, zgoraj levo), v tem primeru 35 tisoč vrednosti. To (zgoraj na sredini) je nalaganje gradbenih procesov, to (zgoraj desno) pa nalaganje notranjih procesov: sinhronizatorjev zgodovine in gospodinjstvo, ki tukaj (spodaj na sredini) teče že kar nekaj časa.
Ta graf (spodaj na sredini) prikazuje uporabo ValueCache – koliko zadetkov ValueCache za sprožilce (več tisoč vrednosti na sekundo). Drug pomemben graf je četrti (spodaj levo), ki prikazuje uporabo predpomnilnika HistoryCache, o katerem sem govoril, ki je medpomnilnik pred vstavljanjem v bazo podatkov.
Test delovanja. PostgreSQL: 50 tisoč NVP
Nato sem povečal obremenitev na 50 tisoč vrednosti na sekundo na isti strojni opremi. Ko je Housekeeper naložil, je bilo v 10-2 sekundah z izračunom zabeleženih 3 tisoč vrednosti. Kaj je pravzaprav prikazano na naslednjem posnetku zaslona:
»Gospodinja« se že začenja vmešavati v delo, vendar je na splošno obremenitev zgodovinskih lovcev še vedno na ravni 60% (tretji graf zgoraj desno). HistoryCache se že začne aktivno polniti, ko se izvaja Housekeeper (spodaj levo). Imel je približno pol gigabajta, 20 % polnega.
Test delovanja. PostgreSQL: 80 tisoč NVP
Nato sem ga povečal na 80 tisoč vrednosti na sekundo:
Šlo je za približno 400 tisoč podatkovnih elementov, 280 tisoč sprožilcev. Vložek je bil, kot vidite, glede na obremenitev zgodovinskih potopov (bilo jih je 30) že precej visok. Nato sem povečal različne parametre: grezila zgodovine, predpomnilnik ... Na tej strojni opremi se je obremenitev grezil zgodovine začela povečevati do maksimuma, skoraj "na polici" - zato je HistoryCache prešel v zelo visoko obremenitev:
Ves ta čas sem spremljal vse sistemske parametre (kako se uporablja procesor, RAM) in ugotovil, da je izkoriščenost diska maksimalna - dosegel sem maksimalno kapaciteto tega diska na tej strojni opremi, na tem virtualnem stroju. "Postgres" je začel precej aktivno odlagati podatke s tako intenzivnostjo in disk ni imel več časa za pisanje, branje ...
Vzel sem drug strežnik, ki je že imel 48 procesorjev in 128 gigabajtov RAM-a:
Prav tako sem ga "uglasil" - namestil History syncer (60 kosov) in dosegel sprejemljivo zmogljivost. Pravzaprav nismo »na polici«, ampak verjetno je to meja produktivnosti, kjer je že treba nekaj narediti.
Test delovanja. TimescaleDB: 80 tisoč NVP
Moja glavna naloga je bila uporaba TimescaleDB. Vsak graf prikazuje padec:
Te napake so ravno migracija podatkov. Po tem se je v strežniku Zabbix profil nalaganja zgodovinskih greznikov, kot lahko vidite, zelo spremenil. Omogoča vam skoraj 3-krat hitrejše vstavljanje podatkov in uporabo manj predpomnilnika HistoryCache – v skladu s tem boste imeli podatke dostavljene pravočasno. Še enkrat, 80 tisoč vrednosti na sekundo je dokaj visoka stopnja (seveda ne za Yandex). Na splošno je to dokaj velika postavitev z enim strežnikom.
Test zmogljivosti PostgreSQL: 120 tisoč NVP
Nato sem povečal vrednost števila podatkovnih elementov na pol milijona in dobil izračunano vrednost 125 tisoč na sekundo:
In dobil sem te grafe:
Načeloma je to delujoča nastavitev, lahko deluje precej dolgo. Ker pa sem imel samo 1,5 terabajtni disk, sem ga porabil v parih dneh. Najpomembneje je, da so bile hkrati ustvarjene nove particije na TimescaleDB, kar je bilo popolnoma neopaženo za zmogljivost, česar pa ne moremo reči za MySQL.
Običajno se particije ustvarijo ponoči, ker to na splošno blokira vstavljanje in delo s tabelami ter lahko povzroči poslabšanje storitve. V tem primeru temu ni tako! Glavna naloga je bila preizkusiti zmogljivosti TimescaleDB. Rezultat je bila naslednja številka: 120 tisoč vrednosti na sekundo.
Obstajajo tudi primeri v skupnosti:
Oseba je vklopila tudi TimescaleDB in obremenitev pri uporabi io.weight je padla na procesor; zaradi vključitve TimescaleDB pa se je zmanjšala tudi uporaba notranjih procesnih elementov. Poleg tega so to navadne palačinke, torej navaden virtualni stroj na navadnih diskih (ne SSD)!
Za nekatere majhne nastavitve, ki so omejene z zmogljivostjo diska, je TimescaleDB po mojem mnenju zelo dobra rešitev. Omogočil vam bo nadaljevanje dela pred prehodom na hitrejšo strojno opremo za bazo podatkov.
Vse vas vabim na naše dogodke: konferenco v Moskvi, vrh v Rigi. Uporabite naše kanale - Telegram, forum, IRC. Če imate kakršna koli vprašanja, se oglasite pri nas, lahko se pogovorimo o vsem.
Vprašanja občinstva
Vprašanje iz občinstva (v nadaljevanju - A): - Če je TimescaleDB tako enostavno konfigurirati in omogoča tako povečanje zmogljivosti, potem bi morda to morali uporabiti kot najboljšo prakso za konfiguracijo Zabbixa s Postgresom? In ali obstajajo kakšne pasti in slabosti te rešitve, ali navsezadnje, če sem se odločil narediti Zabbix zase, lahko enostavno vzamem Postgres, tja takoj namestim Timescale, ga uporabljam in ne razmišljam o nobenih težavah?
AG: – Da, rekel bi, da je to dobro priporočilo: takoj uporabite Postgres z razširitvijo TimescaleDB. Kot sem že rekel, veliko dobrih ocen, kljub dejstvu, da je ta »funkcija« eksperimentalna. Toda dejansko testi kažejo, da je to odlična rešitev (s TimescaleDB) in mislim, da se bo razvijala! Spremljamo razvoj te razširitve in bomo po potrebi uvedli spremembe.
Tudi med razvojem smo se zanašali na eno od njihovih dobro znanih »lastnosti«: s kosi je bilo mogoče delati malo drugače. Toda potem so ga v naslednji izdaji izključili in morali smo se nehati zanašati na to kodo. Priporočam uporabo te rešitve pri številnih nastavitvah. Če uporabljate MySQL ... Za povprečne nastavitve deluje katera koli rešitev.
A: – Na zadnjih grafih iz skupnosti je bil graf z »Housekeeper«:
Nadaljeval je z delom. Kaj počne Housekeeper s TimescaleDB?
AG: – Zdaj ne morem reči zagotovo – pogledal bom kodo in vam povedal podrobneje. Ne uporablja poizvedb TimescaleDB za brisanje kosov, ampak za njihovo nekako združevanje. Nisem še pripravljen odgovoriti na to tehnično vprašanje. Več bomo izvedeli na stojnici danes ali jutri.
A: – Imam podobno vprašanje – o uspešnosti operacije brisanja v Timescale.
A (odgovor iz občinstva): – Ko brišeš podatke iz tabele, če to počneš preko brisanja, potem moraš iti skozi tabelo - brisati, čistiti, vse označiti za prihodnji vakuum. V Timescale, ker imate koščke, lahko spustite. Grobo rečeno, datoteki, ki je v velikih podatkih, preprosto rečete: "Izbriši!"
Timescale preprosto razume, da tak kos ne obstaja več. In ker je integriran v načrtovalnik poizvedb, uporablja kljuke, da ujame vaše pogoje pri izbiranju ali drugih operacijah in takoj razume, da ta kos ne obstaja več - "Ne bom več šel tja!" (podatki niso na voljo). To je vse! To pomeni, da se skeniranje tabele nadomesti z brisanjem binarne datoteke, zato je hitro.
A: – Dotaknili smo se že teme ne-SQL. Kolikor razumem, Zabbixu dejansko ni treba spreminjati podatkov in vse to je nekaj podobnega dnevniku. Ali je mogoče uporabiti specializirane baze podatkov, ki ne morejo spreminjati svojih podatkov, hkrati pa veliko hitreje shranjujejo, kopičijo in distribuirajo - Clickhouse, na primer, nekaj kafkovskega?.. Kafka je tudi klada! Ali jih je mogoče nekako integrirati?
AG: - Razkladanje je možno. Od različice 3.4 dalje imamo določeno »funkcijo«: vse zgodovinske datoteke, dogodke, vse ostalo lahko zapišete v datoteke; in ga nato pošljete v katero koli drugo bazo podatkov z uporabo nekega obdelovalca. Pravzaprav veliko ljudi predeluje in piše neposredno v bazo podatkov. Sproti pogrezilci zgodovine vse to zapišejo v datoteke, te datoteke rotirajo itd., in to lahko prenesete v Clickhouse. Ne morem reči o načrtih, a morda se bo nadaljevala nadaljnja podpora za rešitve NoSQL (kot je Clickhouse).
A: – Na splošno se izkaže, da se lahko popolnoma znebite postgresa?
AG: – Seveda so najtežji del v Zabbixu zgodovinske tabele, ki povzročajo največ težav in dogodkov. V tem primeru, če dogodkov ne shranjujete dlje časa in shranjujete zgodovino s trendi v drugem hitrem pomnilniku, potem na splošno mislim, da ne bo težav.
A: – Ali lahko ocenite, koliko hitreje bo vse delovalo, če na primer preklopite na Clickhouse?
AG: – Nisem testiral. Mislim, da je vsaj enake številke mogoče doseči povsem preprosto, glede na to, da ima Clickhouse svoj vmesnik, vendar ne morem reči zagotovo. Bolje je testirati. Vse je odvisno od konfiguracije: koliko gostiteljev imate itd. Vstavljanje je eno, ampak te podatke je treba tudi priklicat - Grafana ali kaj drugega.
A: – Torej govorimo o enakovrednem boju in ne o veliki prednosti teh hitrih podatkovnih baz?
AG: – Mislim, da bodo, ko se bomo integrirali, bolj natančni testi.
A: – Kam je izginil stari dobri RRD? Zakaj ste prešli na baze podatkov SQL? Sprva so bile vse metrike zbrane na RRD.
AG: – Zabbix je imel RRD, morda v zelo starodavni različici. Vedno so obstajale baze podatkov SQL – klasičen pristop. Klasičen pristop je MySQL, PostgreSQL (obstajata že zelo dolgo). Skoraj nikoli nismo uporabljali skupnega vmesnika za baze podatkov SQL in RRD.
Nekaj oglasov 🙂
Hvala, ker ste ostali z nami. So vam všeč naši članki? Želite videti več zanimivih vsebin? Podprite nas tako, da oddate naročilo ali priporočite prijateljem, , edinstven analog začetnih strežnikov, ki smo ga izumili za vas: (na voljo z RAID1 in RAID10, do 24 jeder in do 40 GB DDR4).
Dell R730xd dvakrat cenejši v podatkovnem centru Equinix Tier IV v Amsterdamu? Samo tukaj na Nizozemskem! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128 GB DDR3 2x960 GB SSD 1 Gbps 100 TB - od 99 $! Preberite o
Vir: www.habr.com