Zabbix-ek TimescaleDB datu-basearekin backend gisa nola funtzionatzen duen aztertuko dugu. Hutsetik nola hasi eta PostgreSQL-tik nola migratu erakutsiko dizugu. Bi konfigurazioen errendimendu proba konparatiboak ere emango ditugu.
HighLoad++ Siberia 2019. Tomsk aretoa. Ekainak 24, 16:00. Tesiak eta . Hurrengo HighLoad++ konferentzia 6ko apirilaren 7an eta 2020an ospatuko da San Petersburgon. Xehetasunak eta sarrerak .
Andrey Gushchin (aurrerantzean - AG): – ZABBIX laguntza teknikoko ingeniaria naiz (aurrerantzean “Zabbix” deitzen dena), prestatzailea. 6 urte baino gehiago daramatzat laguntza teknikoan lanean eta esperientzia zuzena izan dut errendimenduarekin. Gaur, TimescaleDB-k PostgreSQL 10 arruntarekin alderatuta eman dezakeen errendimenduari buruz hitz egingo dut. Gainera, orokorrean nola funtzionatzen duen buruzko sarrerako zati bat.
Produktibitate-erronka nagusiak: datuak biltzetik datuak garbitzera
Hasteko, jarraipen-sistema guztiek dituzten errendimendu-erronka batzuk daude. Produktibitatearen lehen erronka datuak azkar biltzea eta prozesatzea da.
Jarraipen-sistema on batek datu guztiak azkar eta puntual jaso beharko lituzke, abiarazle-adierazpenen arabera prozesatu, hau da, irizpide batzuen arabera prozesatu (hau desberdina da sistema desberdinetan) eta datu-base batean gorde behar ditu datu horiek erabiltzeko. etorkizuna.
Bigarren errendimendu erronka historia biltegiratzea da. Gorde maiz datu-base batean eta izan denbora tarte batean bildutako neurri horietara sarbide azkar eta erosoa. Garrantzitsuena da datu hauek lortzeko erosoa dela, txostenetan, grafikoetan, abiarazleetan, atalase-balio batzuetan, alertak egiteko, etab.
Hirugarren errendimenduaren erronka historia garbitzea da, hau da, 5 urtetan (hilabeteak edo bi hilabeteak ere) bildutako neurri zehatzik gorde behar ez duzun puntura iristen zarenean. Sare-nodo batzuk ezabatu ziren, edo ostalari batzuk, neurketak ez dira beharrezkoak jada zaharkituta daudelako eta jada ez direlako bildu. Hori guztia garbitu behar da zure datu-basea handiegia izan ez dadin. Orokorrean, historia garbitzea biltegiratzeko proba larria da gehienetan - askotan eragin handia du errendimenduan.
Nola konpondu cachean arazoak?
Zabbix-i buruz zehazki hitz egingo dut orain. Zabbixen, lehenengo eta bigarren deiak cachea erabiliz ebazten dira.
Datuen bilketa eta tratamendua - Datu horiek guztiak gordetzeko RAM erabiltzen dugu. Datu hauek zehatzago eztabaidatuko dira orain.
Datu-basearen aldean ere hautapen nagusietarako caching batzuk daude, grafikoetarako eta beste gauza batzuetarako.
Cachea Zabbix zerbitzariaren beraren aldean: ConfigurationCache, ValueCache, HistoryCache, TrendsCache ditugu. Zer da hau?
ConfigurationCache metrikak, ostalariak, datu-elementuak eta abiarazleak gordetzen ditugun cache nagusia da; aurreprozesaketa prozesatzeko behar duzun guztia, datuak biltzeko, zein ostalaritatik bildu, zein maiztasunarekin. Hori guztia ConfigurationCache-n gordetzen da datu-basera joan eta beharrezkoak ez diren kontsultak sortzeko. Zerbitzaria hasi ondoren, cache hau eguneratzen dugu (sortu) eta aldian-aldian eguneratzen dugu (konfigurazio-ezarpenen arabera).
Zabbixen cachean gordetzea. Datu bilketa
Hemen diagrama nahiko handia da:
Eskemako nagusiak bildumagile hauek dira:
Hauek dira muntaketa-prozesuak beraiek, hainbat motatako muntaketaz arduratzen diren hainbat “poller”. Datuak icmp, ipmi eta hainbat protokoloren bidez biltzen dituzte eta dena aurreprozesaketara transferitzen dute.
Aurreprozesatzen historiaren cachea
Gainera, datu-elementuak kalkulatuak baditugu (Zabbix ezagutzen dutenek badakite), hau da, kalkulatutako datu-elementuak agregazio-elementuak, ValueCachetik zuzenean hartzen ditugu. Geroxeago esango dizut nola betetzen den. Biltzaile hauek guztiek ConfigurationCache erabiltzen dute beren lanak jasotzeko eta, ondoren, aurreprozesaketara pasatzeko.
Aurreprozesatzeak ere ConfigurationCache erabiltzen du aurreprozesatzeko urratsak lortzeko eta datu horiek hainbat modutan prozesatzen ditu. 4.2 bertsiotik hasita, proxy batera eraman dugu. Hau oso erosoa da, aurreprozesatzea bera eragiketa zaila delako. Eta Zabbix oso handia baduzu, datu-elementu ugari eta bilketa maiztasun handikoa bada, horrek asko errazten du lana.
Horren arabera, datu hauek nolabait aurreprozesatzea erabiliz prozesatu ondoren, HistoryCache-n gordetzen ditugu gehiago prozesatzeko. Honek datu bilketari amaiera ematen dio. Prozesu nagusira pasatzen gara.
History Syncer-en lana
Zabbixen prozesu nagusia (arkitektura monolitikoa denez) History syncer da. Hau da datu-elementu bakoitzaren prozesamendu atomikoaz bereziki lantzen duen prozesu nagusia, hau da, balio bakoitza:
- balioa dator ( HistoryCachetik hartzen du);
- konfigurazio sinkronizatzailean egiaztatzen du: kalkulurako abiarazlerik dagoen ala ez - kalkulatzen ditu;
bada - gertaerak sortzen ditu, eskalada sortzen du alerta bat sortzeko, beharrezkoa bada konfigurazioaren arabera; - erregistroak abiarazleak ondorengo prozesatzeko, agregaziorako; azken ordua eta abar agregatzen badituzu, balio hau ValueCache-k gogoratzen du historiako taulara ez joateko; Horrela, ValueCache-a abiarazleak, kalkulatutako elementuak, etab. kalkulatzeko beharrezkoak diren datuekin betetzen da;
- ondoren, History Syncerrek datu guztiak idazten ditu datu-basean;
- datu-baseak diskoan idazten ditu - hemen amaitzen da prozesatzeko prozesua.
Datu-basea. Cachean gordetzea
Datu-basearen aldetik, grafikoak edo gertaeren txosten batzuk ikusi nahi dituzunean, hainbat cache daude. Baina erreportaje honetan ez dut horietaz hitz egingo.
MySQL-rako Innodb_buffer_pool dago, eta konfiguratu daitezkeen cache ezberdin mordoa.
Baina hauek dira nagusiak:
- shared_buffers;
- cache_tamaina eraginkorra;
- partekatutako_igerilekua.
Datu-base guztietarako esan dut badirela zenbait cache, kontsultetarako sarritan beharrezkoak diren datuak RAMan gordetzeko aukera ematen dutenak. Horretarako teknologia propioak dituzte.
Datu-basearen errendimenduari buruz
Horren arabera, ingurune lehiakorra dago, hau da, Zabbix zerbitzariak datuak bildu eta erregistratzen ditu. Berrabiarazitakoan, historiatik irakurtzen du ValueCache-a betetzeko eta abar. Hemen web interfaze batean eraikitako Zabbix APIa erabiltzen duten script eta txostenak izan ditzakezu. Zabbix API datu-basean sartzen da eta grafikoak, txostenak edo gertaeren zerrenda, azken arazoak lortzeko beharrezko datuak jasotzen ditu.
Era berean, oso ezaguna den bisualizazio irtenbide bat Grafana da, gure erabiltzaileek erabiltzen dutena. Zabbix APIaren eta datu-basearen bidez zuzenean saioa hasteko gai da. Datuak lortzeko nolabaiteko lehia ere sortzen du: datu-basearen sintonizazio finagoa eta hobea behar da emaitzak eta proben bidalketa azkarrak betetzeko.
Historia garbitzea. Zabbix Etxezaina du
Zabbix-en erabiltzen den hirugarren deia historia garbitzea da Housekeeper erabiliz. Housekeeper-ek ezarpen guztiak jarraitzen ditu, hau da, gure datu-elementuek zenbat denbora gorde behar duten (egunetan), zenbat denbora gorde behar diren joerak eta aldaketen dinamika adierazten dute.
Ez nuen TrendCache-ri buruz hitz egin, hegan kalkulatzen duguna: datuak iristen dira, ordubetez batzen ditugu (gehienetan azken orduko zenbakiak dira), zenbatekoa batez bestekoa/gutxienekoa da eta orduan behin erregistratzen dugu. Aldaketen dinamikaren taula (“Joerak”) . "Housekeeper" datu-baseko datuak abiarazten eta ezabatzen ditu ohiko aukerak erabiliz, eta hori ez da beti eraginkorra.
Nola ulertu eraginkorra ez dela? Barne prozesuen errendimendu grafikoetan hurrengo irudia ikus dezakezu:
Zure Historia-sinkronizatzailea etengabe lanpetuta dago (grafiko gorria). Eta gainean doan grafiko “gorria”. Hau "Etxezaina" da, abiarazi eta datu-baseak zehaztu dituen errenkada guztiak ezabatzeko zain dagoena.
Har dezagun Item ID batzuk: azken 5 mila ezabatu behar dituzu; noski, indizeen arabera. Baina normalean datu-multzoa nahiko handia da - datu-baseak oraindik diskotik irakurtzen du eta cachean sartzen du, eta datu-basearentzat oso eragiketa garestia da. Bere tamainaren arabera, horrek errendimendu-arazo batzuk sor ditzake.
Housekeeper modu erraz batean desgai dezakezu: web interfaze ezaguna dugu. Administrazio orokorreko ezarpenak ("Etxezainaren ezarpenak") barne-etxegintza desgaitzen dugu barne historiarako eta joeretarako. Horrenbestez, Housekeeper-ek ez du hau kontrolatzen:
Zer egin dezakezu jarraian? Desaktibatu duzu, zure grafikoak berdindu dira... Zein arazo gehiago sor litezke kasu honetan? Zer lagun dezake?
Banaketa (sekzioa)
Normalean, hori modu ezberdin batean konfiguratzen da zerrendatu dudan datu-base erlazional bakoitzean. MySQL-k bere teknologia du. Baina, oro har, oso antzekoak dira PostgreSQL 10 eta MySQL-ri dagokionez. Jakina, barne-desberdintasun asko daude nola gauzatzen den eta nola eragiten duen errendimenduan. Baina, oro har, partizio berri bat sortzeak arazo batzuk ere ekartzen ditu askotan.
Zure konfigurazioaren arabera (egun batean zenbat datu sortzen dituzun), normalean gutxienekoa ezartzen dute - egun 1 / lote da, eta "joerak" aldaketen dinamika - hilabete 1 / lote berria. Hau alda daiteke konfigurazio oso handia baduzu.
Esan dezagun berehala konfigurazioaren tamainari buruz: segundoko 5 mila balio berri arte (nvps deiturikoak) - "konfigurazio" txikitzat hartuko da. Batez bestekoa - 5 eta 25 mila balio segundoko. Goian dagoen guztia dagoeneko datu-basearen konfigurazio oso zaindua eskatzen duten instalazio handiak eta oso handiak dira.
Instalazio oso handietan, baliteke egun bat ez izatea optimoa. Pertsonalki MySQL-n eguneko 1 gigabyteko partizioak ikusi ditut (eta gehiago egon daitezke). Datu kopuru oso handia da eta horrek arazo batzuk sor ditzake. Murriztu egin behar da.
Zergatik behar duzu partizioa?
Partizioak ematen duena, denek dakitela uste dut, taularen zatiketa da. Askotan, fitxategiak bereiziak dira diskoan eta span eskaerak. Partizio bat hobeto hautatzen du partizio arruntaren parte bada.
Zabbixentzat, bereziki, barrutiaren arabera erabiltzen da, barrutiaren arabera, hau da, denbora-zigilua erabiltzen dugu (zenbaki arrunta, garaiaren hasieratik denbora). Egunaren hasiera/egunaren amaiera zehazten duzu, eta hau da partizioa. Horren arabera, bi egun dituzten datuak eskatzen ari bazara, dena datu-basetik azkarrago berreskuratzen da, fitxategi bat bakarrik kargatu behar duzulako cachean eta itzuli (taula handi bat baino).
Datu-base askok txertatzea ere bizkortzen dute (taula ume batean txertatzea). Momentuz abstraktuki hitz egiten ari naiz, baina hori ere posible da. Partizioak askotan laguntzen du.
Elasticsearch NoSQL-rako
Duela gutxi, 3.4-n, NoSQL irtenbide bat inplementatu dugu. Elasticsearch-en idazteko gaitasuna gehitu da. Mota batzuk idatz ditzakezu: zuk aukeratzen duzu - idatzi zenbakiak edo zeinu batzuk; kate testua dugu, Elasticsearch-en erregistroak idatz ditzakezu... Horren arabera, web interfazea ere sartuko da Elasticsearch-en. Honek oso ondo funtzionatzen du kasu batzuetan, baina momentuz erabil daiteke.
Denbora-eskalaDB. Hipertaulak
4.4.2rako TimescaleDB bezalako gauza bati erreparatu genion. Zer da hau? PostgreSQLren luzapena da hau, hau da, PostgreSQL interfaze natiboa du. Gainera, luzapen honek denbora-serieko datuekin askoz modu eraginkorragoan lan egiteko eta partizio automatikoa izateko aukera ematen du. Nolakoa den:
Hau hipertaula da; halako kontzeptu bat dago Timescale-n. Zuk sortzen duzun hipertaula da eta zatiak ditu. Chunkak partizioak dira, hauek umeen taulak dira, oker ez banago. Benetan eraginkorra da.
TimescaleDB eta PostgreSQL
TimescaleDB fabrikatzaileek ziurtatzen dutenez, algoritmo zuzenagoa erabiltzen dute kontsultak prozesatzeko, txertaketak bereziki, eta horri esker, gutxi gorabehera etengabeko errendimendua dute datu-multzoaren txertaketaren tamaina handituz. Hau da, Postgres-en 200 milioi errenkadaren ondoren, ohikoa asko jaisten hasten da eta errendimendua literalki zerora galtzen du, eta Timescale-k, berriz, txertaketak ahalik eta modu eraginkorrenean txertatzeko aukera ematen dizu edozein daturekin.
Nola instalatu TimescaleDB? Sinplea da!
Dokumentazioan dago, deskribatuta dago - edozein paketetatik instala dezakezu... Postgres pakete ofizialen araberakoa da. Eskuz konpila daiteke. Gertatu zen datu-baserako konpilatu behar izan nuela.
Zabbixen luzapena aktibatzen dugu. Uste dut Postgres-en Extention erabiltzen zutenek... Extention aktibatzea besterik ez duzu, erabiltzen ari zaren Zabbix datu-baserako sortu.
Eta azken urratsa...
Denbora-eskalaDB. Historia-taulen migrazioa
Hipertaula bat sortu behar duzu. Funtzio berezi bat dago horretarako - Sortu hipertaula. Bertan, lehen parametroa datu-base honetan behar den taula da (horretarako hipertaula bat sortu behar duzu).
Sortu behar den eremua eta chunk_time_interval (hau zatien tartea da (erabili behar diren partizioak). 86 egun batekoa da.
Migrate_data parametroa: True gisa txertatzen baduzu, honek uneko datu guztiak aurrez sortutako zatietara migratuko ditu.
Nik neuk erabili dut migrate_data - denbora dezente behar da, zure datu-basearen tamainaren arabera. Terabyte bat baino gehiago nuen: ordubete baino gehiago behar izan nuen sortzeko. Zenbait kasutan, proban zehar, testuaren (history_text) eta katearen (history_str) datu historikoak ezabatu nituen, ez transferitzeko - ez ziren benetan interesgarriak niretzat.
Eta gure db_extention-en egiten dugu azken eguneraketa: timescaledb instalatzen dugu datu-baseak eta, bereziki, gure Zabbix-ek db_extention dagoela uler dezan. Aktibatzen du eta datu-baserako sintaxi eta kontsulta egokiak erabiltzen ditu, TimescaleDB-rako beharrezkoak diren "ezaugarri" horiek erabiliz.
Zerbitzariaren konfigurazioa
Bi zerbitzari erabili ditut. Lehenengo zerbitzaria makina birtual txiki samarra da, 20 prozesadore, 16 gigabyte RAM. Postgres 10.8 konfiguratu dut bertan:
Sistema eragilea Debian zen, fitxategi sistema xfs. Datu-base jakin hau erabiltzeko gutxieneko ezarpenak egin nituen, Zabbixek berak erabiliko duena kenduta. Makina berean Zabbix zerbitzari bat, PostgreSQL eta karga-agenteak zeuden.
LoadableModule erabiltzen duten 50 agente aktibo erabili ditut emaitza desberdinak azkar sortzeko. Haiek dira kateak, zenbakiak eta abar sortu zituztenak. Datu-basea datu askorekin bete nuen. Hasieran, konfigurazioak 5 mila datu-elementu zituen ostalari bakoitzeko, eta gutxi gorabehera datu-elementu bakoitzak abiarazle bat zuen - hau benetako konfigurazio bat izan zedin. Batzuetan, abiarazle bat baino gehiago ere behar dituzu erabiltzeko.
Eguneratze-tartea eta karga bera arautu ditut 50 agente erabiliz (gehiago gehituz), baizik eta datu-elementu dinamikoak erabiliz eta eguneratze-tartea 4 segundora murriztuz.
Errendimendu proba. PostgreSQL: 36 mila NVP
Lehenengo abiarazpena, izan nuen lehen konfigurazioa PostreSQL 10 hutsean izan zen hardware honetan (35 mila balio segundoko). Oro har, pantailan ikus dezakezun bezala, datuak txertatzeko segundo baten zatiak behar dira - dena ona eta azkarra da, SSD unitateak (200 gigabyte). Gauza bakarra da 20 GB nahiko azkar betetzen direla.
Etorkizunean horrelako grafiko asko egongo dira. Hau Zabbix zerbitzariaren errendimendu-panel estandarra da.
Lehenengo grafikoa segundoko balio kopurua da (urdina, goiko ezkerrean), 35 mila balio kasu honetan. Hau (goiko erdian) eraikitze-prozesuen karga da, eta hau (goian eskuinekoa) barne-prozesuen karga da: historia-sinkronizatzaileak eta etxeko arduraduna, hemen (beheko erdian) denbora dezente exekutatzen ari dena.
Grafiko honek (beheko erdian) ValueCache-ren erabilera erakusten du: abiarazleentzako ValueCache-ren zenbat hits (segundoko milaka balio). Beste grafiko garrantzitsu bat laugarrena da (behean ezkerrean), eta bertan azaltzen da HistoryCache-ren erabilera, hitz egin dudana, datu-basean sartu aurretik buffer bat dena.
Errendimendu proba. PostgreSQL: 50 mila NVP
Ondoren, karga segundoko 50 mila balioetara igo nuen hardware berean. Housekeeper-ek kargatutakoan, 10 mila balio 2-3 segundotan erregistratu ziren kalkuluarekin. Izan ere, hurrengo pantaila-argazkian erakusten dena:
"Etxezaina" dagoeneko lanean oztopatzen hasi da, baina, oro har, historia-hondakinen karga %60ko mailan dago oraindik (hirugarren grafikoa, goiko eskuinekoa). HistoryCache dagoeneko aktiboki betetzen hasten da Housekeeper martxan dagoen bitartean (behean ezkerrean). Gigabyte erdi inguru zen, %20 beteta.
Errendimendu proba. PostgreSQL: 80 mila NVP
Ondoren, segundoko 80 mila balioetara igo nuen:
Gutxi gorabehera 400 mila datu-elementu ziren, 280 mila abiarazle. Txertaketa, ikus dezakezun bezala, historiako hondoren zamari dagokionez (30 ziren) nahiko altua zen jada. Ondoren, hainbat parametro areagotu nituen: historia-sunkerak, cache-a... Hardware honetan, historia-sinker-en karga gehienez ere handitzen hasi zen, ia "apalategian" - horren arabera, HistoryCache-k oso karga handian sartu zuen:
Denbora honetan guztian sistemaren parametro guztiak kontrolatu nituen (prozesadorea nola erabiltzen den, RAM) eta diskoaren erabilera maximoa zela deskubritu nuen - hardware honetan, makina birtual honetan, disko honen ahalmen maximoa lortu nuen. "Postgres" datuak nahiko aktiboki isurtzen hasi zen halako intentsitatearekin, eta diskoak ez zuen jada denborarik izan idazteko, irakurtzeko...
Lehendik 48 prozesadore eta 128 gigabyte RAM zituen beste zerbitzari bat hartu nuen:
Gainera, "sintonizatu" nuen - History syncer instalatu nuen (60 pieza) eta errendimendu onargarria lortu nuen. Izan ere, ez gaude "apalategian", baina ziurrenik hori da produktibitatearen muga, non dagoeneko beharrezkoa den horri buruz zerbait egitea.
Errendimendu proba. TimecaleDB: 80 mila NVP
Nire zeregin nagusia TimescaleDB erabiltzea zen. Grafiko bakoitzak beherapen bat erakusten du:
Porrot hauek datuen migrazioa dira hain zuzen. Horren ostean, Zabbix zerbitzarian, historiako sinker-en kargatze-profila, ikus dezakezun bezala, asko aldatu zen. Datuak ia 3 aldiz azkarrago txertatzeko eta HistoryCache gutxiago erabiltzeko aukera ematen dizu; horren arabera, datuak garaiz entregatuko dituzu. Berriz ere, segundoko 80 mila balio tasa nahiko altua da (noski, ez Yandex-entzat). Orokorrean nahiko konfigurazio handia da, zerbitzari bakarra duena.
PostgreSQL errendimendu-proba: 120 mila NVP
Ondoren, datu-elementuen kopurua milioi erdira igo nuen eta segundoko 125 milako balio kalkulatua jaso nuen:
Eta grafiko hauek lortu ditut:
Printzipioz, funtzionatzen duen konfigurazioa da, denbora luzez funtziona dezake. Baina 1,5 terabyteko diskoa baino ez nuenez, egun pare batean erabili nuen. Garrantzitsuena da aldi berean TimescaleDB-n partizio berriak sortu zirela, eta hori errendimendurako guztiz oharkabean geratu zela, MySQL-ri buruz ezin dena esan.
Normalean, partizioak gauez sortzen dira, horrek orokorrean txertatzea eta taulekin lan egitea blokeatzen duelako eta zerbitzuaren degradazioa ekar dezakeelako. Kasu honetan ez da horrela! Zeregin nagusia TimescaleDB-ren gaitasunak probatzea zen. Emaitza honako zifra hau izan zen: 120 mila balio segundoko.
Komunitatean ere badira adibideak:
Pertsonak TimescaleDB ere aktibatu zuen eta io.weight erabiltzearen karga prozesadorean erori zen; eta barne prozesuko elementuen erabilera ere gutxitu egin da TimescaleDB sartzea dela eta. Gainera, hauek pancake disko arruntak dira, hau da, makina birtual arrunt bat disko arruntetan (ez SSDetan)!
Diskoaren errendimenduak mugatzen dituen konfigurazio txiki batzuetarako, TimescaleDB, nire ustez, oso irtenbide ona da. Datu-baserako hardware azkarrago batera migratu aurretik lanean jarraitzeko aukera emango dizu.
Guztiak gonbidatzen zaituztet gure ekitaldietara: Moskuko Konferentzia, Rigako Gailurrera. Erabili gure kanalak - Telegram, foroa, IRC. Galderarik baduzu, etorri gure mahaira, denetaz hitz egin dezakegu.
Ikusleen galderak
Entzuleen galdera (aurrerantzean - A): - TimescaleDB konfiguratzeko hain erraza bada eta errendimenduaren bultzada ematen badu, agian hau Zabbix-ekin Postgres-ekin konfiguratzeko praktika egoki gisa erabili beharko litzateke? Eta konponbide honen oztoporik eta desabantailarik ba al dago, edo azken finean, Zabbix neure kabuz egitea erabakitzen badut, erraz hartu dezaket Postgres, Timescale bertan instalatu berehala, erabili eta ez dut arazorik pentsatu?
AG: – Bai, gomendio ona dela esango nuke: erabili Postgres berehala TimescaleDB luzapenarekin. Esan dudan bezala, kritika on asko, "ezaugarri" hau esperimentala izan arren. Baina egia esan probek erakusten dute irtenbide bikaina dela (TimescaleDB-rekin) eta eboluzionatuko duela uste dut! Luzapen hau nola garatzen den kontrolatzen ari gara eta behar izanez gero aldaketak egingo ditugu.
Garapen garaian ere, haien "ezaugarri" ezagunetako batean oinarritzen ginen: zatiekin modu ezberdinean lan egitea posible zen. Baina hurrengo bertsioan moztu zuten, eta kode honetan fidatzeari utzi behar izan genion. Soluzio hau konfigurazio askotan erabiltzea gomendatuko nuke. MySQL erabiltzen baduzu... Batez besteko konfigurazioetarako, edozein soluzio ondo funtzionatzen du.
eta: – Komunitatearen azken grafikoetan, “Etxezaina” zuen grafiko bat zegoen:
Lanean jarraitu zuen. Zer egiten du Housekeeper-ek TimescaleDB-rekin?
AG: – Orain ezin dut ziur esan – kodea aztertu eta zehatzago esango dizut. TimescaleDB kontsultak erabiltzen ditu ez zatiak ezabatzeko, baina nolabait gehitzeko. Oraindik ez nago galdera tekniko honi erantzuteko prest. Gehiago jakingo dugu standean gaur edo bihar.
eta: – Antzeko galdera bat daukat – Timescale-n ezabatzeko eragiketaren errendimenduari buruz.
A (ikusleen erantzuna): – Taula bateko datuak ezabatzen dituzunean, ezabatu bidez egiten baduzu, orduan taulatik pasatu behar duzu - ezabatu, garbitu, markatu dena etorkizuneko hutsunerako. Timescale-n, zatiak dituzunez, jaregin dezakezu. Gutxi gorabehera, datu handietan dagoen fitxategiari esan besterik ez duzu: "Ezabatu!"
Timescale-k besterik ez du ulertzen horrelako zati bat jada ez dagoela. Eta kontsulta-planifikatzailean integratuta dagoenez, kakoak erabiltzen ditu zure baldintzak hautapenetan edo beste eragiketetan harrapatzeko eta berehala ulertzen du zati hori jada ez dagoela - "Ez naiz gehiago hara joango!" (datuak ez daude eskuragarri). Hori da dena! Hau da, taula eskaneatzea fitxategi bitar ezabatuz ordezkatzen da, beraz, azkarra da.
eta: – Dagoeneko SQL ez den gaia ukitu dugu. Ulertzen dudanez, Zabbix-ek ez ditu datuak aldatu behar, eta hau guztia erregistro baten antzeko zerbait da. Posible al da datu-base espezializatuak erabiltzea beren datuak aldatu ezin dituztenak, baina aldi berean askoz azkarrago gorde, metatu eta banatu - Clickhouse, adibidez, Kafkaren antzeko zerbait?... Kafka ere erregistro bat da! Posible al da nolabait integratzea?
AG: - Deskarga egin daiteke. 3.4 bertsiotik hona "ezaugarri" jakin bat dugu: fitxategi historiko guztiak, gertaerak, beste guztia fitxategietan idatz ditzakezu; eta gero bidali beste edozein datu-base batera kudeatzaileren bat erabiliz. Izan ere, jende askok birlantzen eta zuzenean idazten du datu-basean. Hegan, historiako sinkerek hori guztia fitxategietan idazten dute, fitxategi hauek biratzen dituzte, eta abar, eta hau Clickhousera transferi dezakezu. Ezin dut planei buruz esan, baina agian NoSQL soluzioetarako laguntza gehiago (adibidez, Clickhouse) jarraituko du.
eta: – Orokorrean, guztiz ken ditzakezu postgresak?
AG: – Jakina, Zabbixen zatirik zailena taula historikoak dira, arazo eta gertakari gehien sortzen dituztenak. Kasu honetan, gertaerak denbora luzez gordetzen ez badituzu eta historia joerak beste biltegiratze azkar batean gordetzen badituzu, oro har, uste dut ez dela arazorik izango.
eta: – Kalkula al dezakezu zenbat azkarrago funtzionatuko duen guztia Clickhousera aldatzen bazara, adibidez?
AG: - Ez dut probatu. Uste dut gutxienez kopuru berdinak lor daitezkeela nahiko sinpleki, Clickhouse-k bere interfazea duela kontuan hartuta, baina ezin dut ziur esan. Hobe da proba egitea. Konfigurazioaren araberakoa da guztia: zenbat ostalari dituzun, eta abar. Txertatzea gauza bat da, baina datu hauek ere berreskuratu behar dituzu - Grafana edo beste zerbait.
eta: – Beraz, borroka parekideaz ari gara, eta ez datu-base azkar hauen abantaila handiaz?
AG: – Uste dut integratzen dugunean proba zehatzagoak egongo direla.
eta: – Nora joan zen RRD zahar ona? Zerk bultzatu zintuen SQL datu-baseetara? Hasieran, metrika guztiak RRDn bildu ziren.
AG: – Zabbixek RRD zuen, agian oso antzinako bertsioan. Beti egon dira SQL datu-baseak - ikuspegi klasikoa. Planteamendu klasikoa MySQL da, PostgreSQL (aspalditik existitzen dira). Ia inoiz ez dugu erabili SQL eta RRD datu-baseetarako interfaze komun bat.
Iragarki batzuk 🙂
Eskerrik asko gurekin geratzeagatik. Gustuko dituzu gure artikuluak? Eduki interesgarri gehiago ikusi nahi? Lagun iezaguzu eskaera bat eginez edo lagunei gomendatuz, , sarrera-mailako zerbitzarien analogo paregabea, guk zuretzat asmatu duguna: (RAID1 eta RAID10-ekin erabilgarri, 24 nukleoraino eta 40 GB DDR4 arte).
Dell R730xd 2 aldiz merkeagoa Amsterdameko Equinix Tier IV datu-zentroan? Hemen bakarrik Herbehereetan! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 $-tik aurrera! Irakurri buruz
Iturria: www.habr.com