Ne do ta shikojmë funksionimin e Zabbix me bazën e të dhënave TimescaleDB si backend. Do të tregojmë se si të startoni nga e para dhe si të migroni nga PostgreSQL. Gjithashtu, do të japim teste krahasuese të performancës së dy konfiguracioneve.
HighLoad++ Siberia 2019. Salla "Tomsk". 24 qershor, 16:00. Tezat dhe . Konferenca e ardhshme HighLoad++ do të zhvillohet më 6 dhe 7 prill 2020 në Shën Petersburg. Detajet dhe biletat .
Andrej Gushin (mĂ« pas â A.G.): â UnĂ« jam inxhinier nĂ« mbĂ«shtetje teknike tĂ« ZABBIX (mĂ« pas â "Zabbix"), trajner. Kam mbi 6 vjet pĂ«rvojĂ« nĂ« mbĂ«shtetje teknike dhe kam pĂ«rballur drejtpĂ«rdrejt me performancĂ«n. Sot do tĂ« flas pĂ«r performancĂ«n qĂ« mund tĂ« ofrojĂ« TimescaleDB, nĂ« krahasim me PostgreSQL 10. Gjithashtu, do tĂ« jap disa informata hyrĂ«se â pĂ«r mĂ«nyrĂ«n se si funksionon.
Sfidat kryesore të performancës: nga grumbullimi në pastrimin e të dhënave
Le të fillojmë me sfidat e caktuara të performancës, me të cilat përballen çdo sistem monitorimi. Sfidë e parë e performancës është mbledhja dhe përpunimi i shpejtë i të dhënave.
Një sistem monitorimi i mirë duhet të marrë dhe përpunojë të gjitha të dhënat me shpejtësi dhe në kohë, duke i përpunuar ato sipas shprehjeve provokuese, domethënë, duke i përpunuar sipas disa kritereve (në sisteme të ndryshme kjo është ndryshe) dhe të ruajë në bazën e të dhënave, në mënyrë që këto të dhëna të përdoren më vonë.
Sfidë e dytë e performancës është ruajtja e historisë. Të ruhen në bazën e të dhënave shpesh dhe të kenë qasje të shpejtë dhe të lehtë në këto metrika që janë mbledhur për një periudhë të caktuar kohe. E rëndësishme është që këto të dhëna të jenë të lehta për t'u marrë, t'i përdorni ato në raporte, grafikë, në shprehje provokuese, në disa vlera pragore, për njoftime etj.
SfidĂ« e tretĂ« e performancĂ«s Ă«shtĂ« pastrimi i historisĂ«, domethĂ«nĂ« kur arrin njĂ« ditĂ« kur nuk Ă«shtĂ« e nevojshme tĂ« ruash disa metrika tĂ« detajuara qĂ« janĂ« mbledhur pĂ«r 5 vjet (sikur edhe pĂ«r muaj ose dy muaj). Disa nyje tĂ« rrjetit janĂ« fshirĂ«, ose disa hosta, metrikat nuk janĂ« mĂ« tĂ« nevojshme sepse janĂ« bĂ«rĂ« tĂ« vjetra dhe kanĂ« ndaluar sĂ« mbledhuri. KĂ«to duhet tĂ« pastrohen, nĂ« mĂ«nyrĂ« qĂ« baza e tĂ« dhĂ«nave tĂ« mos shndĂ«rrohet nĂ« njĂ« madhĂ«si tĂ« madhe. NĂ« tĂ« vĂ«rtetĂ«, pastrimi i historisĂ« shpesh Ă«shtĂ« njĂ« provim serioz pĂ«r magazinimin â zakonisht ndikon shumĂ« te performanca.
Si të zgjidhni problemet e caching-ut?
Tani do të flasë konkretisht për «Zabbix». Në «Zabbix», thirrjet e para dhe të dyta zgjidhen përmes memorie të arkivimit.
Grumbullimi dhe pĂ«rpunimi i tĂ« dhĂ«nave â ne pĂ«rdorim memorien operative pĂ«r tĂ« ruajtur tĂ« gjitha kĂ«to tĂ« dhĂ«na. Tani do tĂ« flasĂ« mĂ« nĂ« detaje rreth kĂ«tyre tĂ« dhĂ«nave.
Po ashtu, nĂ« anĂ«n e bazĂ«s sĂ« tĂ« dhĂ«nave ka njĂ« arkivim tĂ« caktuar pĂ«r zgjedhjet kryesore â pĂ«r grafiket, gjĂ«rat e tjera.
Arkivimi nĂ« anĂ«n e vetĂ« serverit Zabbix: ne kemi ConfigurationCache, ValueCache, HistoryCache, TrendsCache. ĂfarĂ« janĂ« kĂ«to?
ConfigurationCache â Ă«shtĂ« arkivi kryesor ku ruajmĂ« metrikat, hostet, elementet e tĂ« dhĂ«nave, trigjerat; gjithçka qĂ« nevojitet pĂ«r pĂ«rpunimin paraprak, grumbullimin e tĂ« dhĂ«nave, se nga cilat hoste tĂ« grumbullojmĂ« dhe me çfarĂ« frekuencash. TĂ« gjitha kĂ«to ruhen nĂ« ConfigurationCache, qĂ« tĂ« mos shkojmĂ« nĂ« bazĂ«n e tĂ« dhĂ«nave, tĂ« mos krijojmĂ« kĂ«rkesa tĂ« panevojshme. Pas fillimit tĂ« serverit, ne pĂ«rditĂ«sojmĂ« kĂ«tĂ« arkiv (e krijojmĂ«) dhe e pĂ«rditĂ«sojmĂ« periodikisht (nĂ« varĂ«si tĂ« konfigurimit).
Arkivimi në Zabbix. Grumbullimi i të dhënave
Këtu schema është mjaft e madhe:
KryesorĂ«t nĂ« schema â janĂ« kĂ«ta grumbullues:
KĂ«ta janĂ« proceset e grumbullimit, âpollerâ-at e ndryshĂ«m, qĂ« janĂ« pĂ«rgjegjĂ«s pĂ«r lloje tĂ« ndryshme grumbullimesh. Ata grumbullojnĂ« tĂ« dhĂ«na pĂ«r icmp, ipmi, pĂ«r protokolle tĂ« ndryshme dhe e kalojnĂ« tĂ« gjitha kĂ«to pĂ«r pĂ«rpunim paraprak.
PreProcessing HistoryCache
Po ashtu, nĂ«se kemi elemente tĂ« dhĂ«nash tĂ« llogaritura (ata qĂ« janĂ« njohur me «Zabbix» e dinĂ«), ka elemente tĂ« dhĂ«nash tĂ« llogaritura, agregative â ne i marrim ato direkt nga ValueCache. Si mbushet ai, do e tregoj mĂ« vonĂ«. TĂ« gjithĂ« kĂ«ta grumbullues pĂ«rdorin ConfigurationCache pĂ«r tĂ« marrĂ« detyrat e tyre dhe pastaj i kalojnĂ« pĂ«r pĂ«rpunim paraprak.
PĂ«rpunimi paraprak po ashtu pĂ«rdor ConfigurationCache pĂ«r tĂ« marrĂ« hapat e pĂ«rpunimit paraprak, e pĂ«rpunon kĂ«to tĂ« dhĂ«na nĂ« mĂ«nyra tĂ« ndryshme. Duke filluar nga versioni 4.2, ai Ă«shtĂ« transferuar nĂ« proxy. Kjo Ă«shtĂ« shumĂ« e dobishme, sepse vetĂ« pĂ«rpunimi paraprak Ă«shtĂ« njĂ« operacion mjaft i rĂ«ndĂ«. Dhe nĂ«se keni njĂ« âZabbixâ shumĂ« tĂ« madh, me shumĂ« elemente tĂ« dhĂ«nash dhe njĂ« frekuencĂ« tĂ« lartĂ« grumbullimi, atĂ«herĂ« kjo e lehtĂ«son ndjeshĂ«m punĂ«n.
Pas përpunimit të këtyre të dhënave në ndonjë mënyrë përmes përpunimit paraprak, i ruajmë ato në HistoryCache për t'i përpunuar më tej. Këtu përfundon grumbullimi i të dhënave. Ne kalojmë në procesin kryesor.
Puna e History syncer
Procesi kryesor në «Zabbix» (që është një arkitekturë monolitike) është History syncer. Ky është procesi kryesor që merret me përpunimin atomar të çdo elementi të të dhënave, pra të çdo vlerësimi:
- vjen një vlerë (e merr nga HistoryCache);
- kontrollon nĂ« Configuration syncer: a ka ndonjĂ« trigger pĂ«r kalkulim â i llogarit ato;
nĂ«se ka â krijon ngjarje, krijon eskalim pĂ«r tĂ« krijuar njĂ« njoftim, nĂ«se Ă«shtĂ« e nevojshme sipas konfigurimit; - regjistron trigger pĂ«r pĂ«rpunim tĂ« mĂ«tejshĂ«m, agregim; nĂ«se e agregoni pĂ«r orĂ«n e fundit e kĂ«shtu me radhĂ«, kjo vlerĂ« ruhet nĂ« ValueCache, pĂ«r tĂ« mos u kthyer nĂ« tabelĂ«n e historisĂ«; kĂ«shtu, ValueCache plotĂ«sohet me tĂ« dhĂ«nat e nevojshme pĂ«r tĂ« llogaritur trigger, elemente tĂ« llogaritura etj.;
- pastaj History syncer ruan të gjitha të dhënat në bazën e të dhënave;
- baza e tĂ« dhĂ«nave i shkruan ato nĂ« disk â kĂ«tu procesi i pĂ«rpunimit pĂ«rfundon.
Baza e të dhënave. Keshimi
Në anën e DB, kur dëshironi të shikoni grafikët ose ndonjë raporte për ngjarjet, ka disa caches. Por në kuadër të kësaj prezentimi nuk do të flas për to.
Për MySQL ka Innodb_buffer_pool, gjithashtu shumë caches të ndryshme që gjithashtu mund të konfigurohen.
Por kĂ«to janĂ« â kryesoret:
- shared_buffers;
- effective_cache_size;
- shared_pool.
Për të gjitha bazat e të dhënave e kam treguar se ka caching të caktuar që lejon mbajtjen në memorie ato të dhëna që janë shpesh të nevojshme për kërkesa. Aty kanë teknologjitë e tyre për këtë.
Për performancën e bazës së të dhënave
Përkatësisht, ka një ambient konkurrues, pra serveri «Zabbix» mbledh të dhëna dhe i shkruan ato. Kur rindez, ai gjithashtu lexon nga historia për të mbushur ValueCache dhe kështu me radhë. Këtu mund të keni skenarë dhe raporte që përdorin «Zabbix»-API, i cili është ndërtuar në bazë të ndërfaqes së uebit. «Zabbix»-API hyn në DB dhe merr të dhënat e nevojshme për të marrë grafikët, raportet ose një listë ngjarjesh, problemet më të fundit.
Një zgjidhje shumë e njohur për vizualizim është Grafana, që e përdorin përdoruesit tanë. Ajo mund të hyjë drejtpërdrejt si përmes «Zabbix»-API, ashtu edhe përmes DB. Ajo gjithashtu krijon një konkurrencë të caktuar për marrjen e të dhënave: nevojitet një konfigurim më i hollësishëm dhe i mirë i DB për të përmbushur shpërndarjen e shpejtë të rezultateve dhe testimeve.
Pastrimi i Historisë. Në Zabbix ka Housekeeper
Thirrja e tretë që përdoret në «Zabbix» është pastrimi i historisë me ndihmën e Housekeeper. «Housekeeper» respekton të gjitha cilësimet, pra kemi në elementët e të dhënave sa të ruajmë (në ditë), sa të ruajmë trendet, dinamikën e ndryshimeve.
Nuk e tregova për TrendCache, të cilin e llogarisim në kohë reale: të dhënat arrijnë, ne i agregojmë për një orë (kryesisht kjo është numri për orën e fundit), numri mesatar / minimal dhe i regjistrojmë këtë një herë në orë në tabelën e dinamikës së ndryshimeve («Trendet»). «Housekeeper» aktivizohet dhe fshin të dhënat nga DB me ndihmën e selektonëve të zakonshëm, çka nuk është gjithmonë efikase.
Si të kuptoni se kjo nuk është efikase? Mund të shihni një pamje të tillë në grafiket e performancës së proceseve të brendshme:
Historia juaj e sinkronizimit është vazhdimisht e angazhuar (grafiku i kuq). Dhe grafiku «portokalli», që shkon lart. Ky është «Housekeeper», i cili aktivizohet dhe pret nga DB që të fshijë të gjitha rreshtat që ai ka caktuar.
Merrni njĂ« ID tĂ« ndonjĂ« Artikulli: duhet tĂ« fshini 5 mijĂ« tĂ« fundit; sigurisht, sipas indekseve. Por zakonisht dataset-i Ă«shtĂ« mjaft i madh â baza e tĂ« dhĂ«nave megjithatĂ« e lexon kĂ«tĂ« nga disku dhe e ngre nĂ« cache, dhe kjo Ă«shtĂ« njĂ« operacion shumĂ« i shtrenjtĂ« pĂ«r DB. NĂ« varĂ«si tĂ« madhĂ«sive tĂ« saj, kjo mund tĂ« sjellĂ« disa probleme tĂ« performancĂ«s.
Mund ta çaktivizoni «Housekeeper» nĂ« njĂ« mĂ«nyrĂ« tĂ« thjeshtĂ« â kemi ndĂ«rfaqen e njohur tĂ« uebit. CilĂ«simi nĂ« Administration general (cilĂ«simet pĂ«r «Housekeeper») ne çaktivizojmĂ« housekeeping-un e brendshĂ«m pĂ«r historinĂ« dhe trendet e brendshme. PĂ«r rrjedhojĂ«, «Housekeeper» nuk menaxhon mĂ« kĂ«tĂ«:
ĂfarĂ« mund tĂ« bĂ«ni mĂ« tej? E keni çaktivizuar, grafiket tuaj janĂ« rregulluar... ĂfarĂ« probleme mund tĂ« dalin mĂ« pas nĂ« kĂ«tĂ« rast? ĂfarĂ« mund tĂ« ndihmojĂ«?
Particionimi (sekcionimi)
Zakonisht kjo inkorporohet në çdo bazë të dhënash relacionale, të cilat i përmenda, në mënyra të ndryshme. Në MySQL ka teknologjinë e saj. Por në përgjithësi ato janë shumë të ngjashme, nëse flasim për PostgreSQL 10 dhe MySQL. Sigurisht, ka shumë ndryshime të brendshme, si është realizuar gjithçka dhe si ndikon gjithçka në performancë. Por në përgjithësi, krijimi i një partie të re shpesh të çon gjithashtu në disa probleme të caktuara.
NĂ« varĂ«si tĂ« setup-it tuaj (sa shumĂ« tĂ« dhĂ«na krijohen pĂ«r njĂ« ditĂ«), zakonisht vendoset minimumi â 1 ditĂ«/pjesĂ«, dhe pĂ«r "trendet", dinamika e ndryshimeve â 1 muaj/pjesĂ« e re. Kjo mund tĂ« ndryshojĂ«, nĂ«se keni njĂ« setup shumĂ« tĂ« madh.
MĂ« lejoni t'ju them pĂ«rmasat e setup-it: deri nĂ« 5 mijĂ« vlera tĂ« reja pĂ«r sekondĂ« (nvps e ashtuquajtura) â kjo do tĂ« konsiderohet njĂ« "setup" i vogĂ«l. I mesĂ«m â nga 5 deri nĂ« 25 mijĂ« vlera nĂ« sekondĂ«. Gjithçka qĂ« kalon â Ă«shtĂ« njĂ« instalim i madh dhe shumĂ« i madh, qĂ« kĂ«rkon njĂ« konfigurim shumĂ« tĂ« kujdesshĂ«m tĂ« bazĂ«s sĂ« tĂ« dhĂ«nave.
NĂ« instalimet shumĂ« tĂ« mĂ«dha, 1 ditĂ« â mund tĂ« mos jetĂ« optimale. UnĂ« kam parĂ« personalisht nĂ« MySQL pjesĂ« deri nĂ« 40 gigabajt pĂ«r ditĂ« (dhe mund tĂ« jenĂ« mĂ« shumĂ«). Ky Ă«shtĂ« njĂ« volum shumĂ« i madh tĂ« dhĂ«nash, qĂ« mund tĂ« çojĂ« nĂ« disa probleme. Duhet ta zvogĂ«loni.
Përse është e nevojshme pjesëtimi?
ĂfarĂ« ofron PjesĂ«timi, mendoj se tĂ« gjithĂ« e dinĂ« â kjo Ă«shtĂ« ndarja e tabelave. Shpesh, kĂ«to janĂ« skedarĂ« tĂ« veçantĂ« nĂ« disk dhe kĂ«rkesa tĂ« shpejta. Ai pĂ«rzgjedh mĂ« optimalisht njĂ« pjesĂ«, nĂ«se Ă«shtĂ« pjesĂ« e zakonshme e ndarjes.
Për "Zabbix", në veçanti, përdoret sipas rangut, sipas intervalit, pra ne përdorim timestamp (numri normal, koha që nga fillimi i epokës). Ju caktoni fillimin e ditës/fundin e ditës, dhe kjo është një pjesë. Për rrjedhojë, nëse kërkoni të dhëna të dy ditëve më parë, gjithçka merret nga baza e të dhënave më shpejt, sepse duhet të ngarkohet vetëm një skedar në cache dhe të jepet (dhe jo një tabelë e madhe).
Shumë baze të dhënash gjithashtu përshpejtojnë insertin (shtimin në një tabelë të fëmijës). Ndërsa po flas në mënyrë abstrakte, por kjo është gjithashtu e mundur. Pjesëtimi shpesh ndihmon.
Elasticsearch për NoSQL
SĂ« fundmi, nĂ« 3.4, ne implementuam njĂ« zgjidhje pĂ«r NoSQL. Shtuam mundĂ«sinĂ« pĂ«r tĂ« shkruar nĂ« Elasticsearch. Ju mund tĂ« shkruani disa lloje tĂ« veçanta: zgjidhni â ose shkruani numra, ose disa simbole; ne kemi tekst tĂ« vargut, mund tĂ« shkruani logje nĂ« Elasticsearch... PĂ«r rrjedhojĂ«, ndĂ«rfaqja e uebit do tĂ« lidhet gjithashtu me Elasticsearch. Kjo funksionon shkĂ«lqyer nĂ« disa raste, por nĂ« momentin e tanishĂ«m mund tĂ« pĂ«rdoret.
TimescaleDB. Hyper-tabela
PĂ«r 4.4.2 ne kemi vĂ«nĂ« re njĂ« gjĂ«, siç Ă«shtĂ« TimescaleDB. ĂfarĂ« Ă«shtĂ« kjo? Kjo Ă«shtĂ« njĂ« shtesĂ« pĂ«r PostgreSQL, qĂ« do tĂ« thotĂ« se ka njĂ« ndĂ«rfaqe native pĂ«r PostgreSQL. PĂ«rveç kĂ«saj, kjo shtesĂ« lejon qĂ« tĂ« punoni shumĂ« mĂ« efektivisht me tĂ« dhĂ«nat e caktuara me kohĂ« dhe gjithashtu ka ndarje automatike. Si duket kjo:
Kjo Ă«shtĂ« hypertable â ka njĂ« koncept tĂ« tillĂ« nĂ« Timescale. Kjo Ă«shtĂ« njĂ« hipertabelĂ« qĂ« krijoni, dhe nĂ« tĂ« gjenden chunks. Chunks janĂ« ndarje, janĂ« tabelat fĂ«mijĂ«t, nĂ«se nuk gaboj. Kjo Ă«shtĂ« me tĂ« vĂ«rtetĂ« efektive.
TimescaleDB dhe PostgreSQL
Sipas prodhuesve të TimescaleDB, ata përdorin një algoritëm më të saktë për përpunimin e kërkesave, sidomos për insertimet, i cili lejon të ketë një performancë afërsisht të vazhdueshme me rritjen e madhësisë së dataset-inserimit. Do të thotë, pas 200 milion rreshtash, PostgreSQL fillon të humbasë shumë në performancë, duke rënë literally në zero, ndërsa 'Timescale' lejon që të inseroni sa më efektivisht të jetë e mundur me çdo sasi të të dhënash.
Si të instaloni TimescaleDB? E gjithë kjo është e thjeshtë!
Ka nĂ« dokumentacionin e tij, pĂ«rshkruar â mund tĂ« instalohet nga paketat pĂ«r çdo... Ajo varet nga paketat zyrtare tĂ« 'PostgreSQL'. Mund tĂ« kompiloni manualisht. KĂ«shtu ndodhi qĂ« mĂ« duhej tĂ« kompiloj pĂ«r DB.
Në 'Zabbix' ne thjesht aktivizojmë Shtesën. Mendoj se ata që kanë përdorur Shtesën në 'PostgreSQL'... Thjesht e aktivizoni Shtesën, e krijoni për DB 'Zabbix' që përdorni.
Dhe hapi i fundit...
TimescaleDB. Migrimi i tabelave të historisë
Ju nevojitet tĂ« krijoni hypertable. PĂ«r kĂ«tĂ« ka njĂ« funksion tĂ« veçantĂ« â Krijoni hypertable. NĂ« tĂ«, si parametrin e parĂ« duhet tĂ« tregoni tabelĂ«n qĂ« Ă«shtĂ« e nevojshme nĂ« kĂ«tĂ« DB (pĂ«r tĂ« cilĂ«n duhet tĂ« krijoni hipertabelĂ«n).
Fusha mbi tĂ« cilĂ«n duhet tĂ« krijoni, dhe chunk_time_interval (kjo Ă«shtĂ« intervali i chunks (ndarjeve, qĂ« duhet tĂ« pĂ«rdoren). 86,400 â kjo Ă«shtĂ« njĂ« ditĂ«.
Parametri migrate_data: nëse e vendosni në true, atëherë kjo transferon të gjitha të dhënat aktuale në chunks e krijuara më parë.
UnĂ« vetĂ« kam pĂ«rdorur migrate_data â kjo merr njĂ« kohĂ« tĂ« konsiderueshme, nĂ« varĂ«si tĂ« madhĂ«sisĂ« sĂ« DB tuaj. Kam pasur mĂ« shumĂ« se njĂ« terabajt â krijimi zgjati mĂ« shumĂ« se njĂ« orĂ«. NĂ« disa raste, gjatĂ« testimit, kam fshirĂ« tĂ« dhĂ«nat historike pĂ«r tekstin (history_text) dhe stringun (history_str), qĂ« tĂ« mos i transferoja â ato nĂ« tĂ« vĂ«rtetĂ« nuk mĂ« interesonin.
Dhe përditësimi përfundimtar e bëjmë në db_extention tonë: vendosim timescaledb, në mënyrë që DB dhe, veçanërisht, "Zabbix" të kuptoj se ekziston db_extention. Ai e aktivizon dhe përdor sintaksën e duhur dhe kërkesat ndaj DB, duke përdorur tashmë ato "karakteristika" që janë të nevojshme për TimescaleDB.
Konfigurimi i serverit
Kam përdorur dy serverë. Serveri i parë është një makinë virtuale mjaft e vogël, 20 procesorë, 16 gigabajt ram. E konfigurova me "Postgres" 10.8:
Sistemi operativ ishte Debian, sistemi i skedarĂ«ve â xfs. BĂ«ra konfigurime minimale, pĂ«r tĂ« pĂ«rdorur pikĂ«risht kĂ«tĂ« bazĂ« tĂ« dhĂ«nash, duke pĂ«rjashtuar atĂ« qĂ« do tĂ« pĂ«rdorte vetĂ« "Zabbix". NĂ« kĂ«tĂ« makinĂ« kishte "Zabbix"-server, PostgreSQL dhe agjentĂ« ngarkese.
Kam pĂ«rdorur 50 agjentĂ« aktivĂ«, tĂ« cilĂ«t pĂ«rdorin LoadableModule, pĂ«r tĂ« gjeneruar shpejt rezultate tĂ« ndryshme. Atyre iu gjeneruan rreshta, numra dhe kĂ«shtu me radhĂ«. E mbushja DB me njĂ« sasi tĂ« madhe tĂ« dhĂ«nash. Fillimisht, konfigurimi pĂ«rmbante 5 mijĂ« elementĂ« tĂ« dhĂ«nash pĂ«r çdo host, dhe rreth çdo element tĂ« dhĂ«nash pĂ«rmbante njĂ« trigger â nĂ« mĂ«nyrĂ« qĂ« tĂ« ishte njĂ« konfigurim real. NdonjĂ«herĂ«, pĂ«r pĂ«rdorim kĂ«rkohet edhe mĂ« shumĂ« se njĂ« trigger.
Intervali i përditësimit, ngarkesa e vetë e rregullova duke përdorur jo vetëm 50 agjentë (shtova edhe), por dhe me ndihmën e elementeve dinamike të dhënash dhe e uli intervalin e përditësimit në 4 sekonda.
Test i performancës. PostgreSQL: 36 mijë NVPs
Aktivizimi i parĂ«, konfigurimi i parĂ« ishte nĂ« PostgreSQL tĂ« pastĂ«r 10 nĂ« kĂ«tĂ« hardware (35 mijĂ« vlera nĂ« sekondĂ«). NĂ« pĂ«rgjithĂ«si, siç duket nĂ« ekran, futja e tĂ« dhĂ«nave merr fraksione sekondash â gjithçka Ă«shtĂ« mirĂ« dhe e shpejtĂ«, SSD-tĂ« (200 gigabajt). E vetmja gjĂ« Ă«shtĂ« se 20 GB mbushen mjaft shpejt.
Do të ketë shumë prej këtyre grafikëve. Kjo është një dashboard standard i performancës së "Zabbix"-serverit.
Grafiku i parĂ« â numri i vlerave nĂ« sekondĂ« (blu, nĂ« majtas lart), 35 mijĂ« vlera nĂ« kĂ«tĂ« rast. Kjo (nĂ« qendĂ«r lart) Ă«shtĂ« ngarkesa e proceseve tĂ« mbledhjes, dhe kjo (nĂ« majtas djathtas) Ă«shtĂ« ngarkesa e proceseve tĂ« brendshme: history syncers dhe housekeeper, tĂ« cilĂ«t kĂ«tu (nĂ« qendĂ«r poshtĂ«) u kryen pĂ«r njĂ« kohĂ« tĂ« gjatĂ«.
Ky kyç nĂ« qendĂ«r tregon pĂ«rdorimin e ValueCache â sa goditje ValueCache pĂ«r gjeneruesit (disa mijĂ«ra vlera nĂ« sekondĂ«). NjĂ« tjetĂ«r grafik i rĂ«ndĂ«sishĂ«m Ă«shtĂ« ai i katĂ«rt (nĂ« fund tĂ« majtĂ«), i cili tregon pĂ«rdorimin e HistoryCache, pĂ«r tĂ« cilin kam folur, qĂ« Ă«shtĂ« njĂ« tampon para se tĂ« futet nĂ« DB.
Testi i performancës. PostgreSQL: 50 mijë NVPs
Pastaj e rita ngarkesën në 50 mijë vlera në sekondë në këtë hardware. Gjatë ngarkimit nga 'Housekeeper', 10 mijë vlera u regjistruan në 2-3 sekonda me llogaritjen. Kjo, në fakt, është e dukshme në ekranin pasues:
'Housekeeper' tashmë fillon të pengojë funksionimin, por në përgjithësi ngarkesa e sinkronizuesve të historisë është ende në nivelin 60 % (grafiku i tretë, në të djathtë lart). HistoryCache tashmë gjatë funksionimit të 'Housekeeper' fillon të mbushet aktivisht (në fund të majtë). Ai ishte rreth gjysmë gigabajt, mbushej me 20%.
Testi i performancës. PostgreSQL: 80 mijë NVPs
Pastaj e rita në 80 mijë vlera në sekondë:
Ishte rreth 400 mijĂ« elemente tĂ« dhĂ«nash, 280 mijĂ« gjenerues. Regjistrimi, siç e shihni, nga ngarkesa e sinkronizuesve tĂ« historisĂ« (tĂ« cilĂ«t ishin 30) ishte tashmĂ« mjaft i lartĂ«. Pastaj fillova tĂ« rita parametrat e ndryshĂ«m: sinkronizuesit e historisĂ«, cache⊠NĂ« kĂ«tĂ« hardware, ngarkesa e sinkronizuesve tĂ« historisĂ« filloi tĂ« rritej nĂ« maksimum, praktikisht 'nĂ« raft' â pĂ«r rrjedhojĂ«, HistoryCache shkoi nĂ« njĂ« ngarkesĂ« shumĂ« tĂ« lartĂ«:
GjatĂ« gjithĂ« kĂ«saj kohe kam vĂ«zhguar tĂ« gjithĂ« parametrat e sistemit (si pĂ«rdoret procesori, memoria e rastit) dhe zbulova se shfrytĂ«zimi i disqeve ishte maksimal â arrita mundĂ«sinĂ« maksimale tĂ« kĂ«tij disku nĂ« kĂ«tĂ« hardware, nĂ« kĂ«tĂ« makinĂ« virtuale. 'Postgres' filloi tĂ« heqĂ« tĂ« dhĂ«nat mjaft aktivisht me kĂ«tĂ« intensitet, dhe disku nuk po arrinte mĂ« tĂ« regjistronte, lexonteâŠ
Mora një server tjetër, i cili tashmë kishte 48 procesorë dhe 128 gigabajt memorie të rastit:
Gjithashtu e 'modifikoja' â vendosa History syncer (60 copĂ«) dhe arrita njĂ« performancĂ« tĂ« kĂ«naqshme. NĂ« fakt, ne nuk jemi 'nĂ« raft', por ndoshta kjo Ă«shtĂ« tashmĂ« kufiri i performancĂ«s, ku Ă«shtĂ« e nevojshme tĂ« merret diçka nĂ« konsideratĂ«.
Testi i performancës. TimescaleDB: 80 mijë NVPs
Ishte qĂ«llimi im kryesor â tĂ« pĂ«rdorja TimescaleDB. NĂ« çdo grafik Ă«shtĂ« e dukshme njĂ« rĂ«nie:
KĂ«to dĂ«shtime janĂ« pikĂ«risht migrimi i tĂ« dhĂ«nave. Pas kĂ«saj, nĂ« serverin "Zabbix", profili i ngarkesĂ«s sĂ« historianĂ«ve Ă«shtĂ« ndryshuar ndjeshĂ«m, siç e shihni, ai lejon tĂ« futen tĂ« dhĂ«nat gati 3 herĂ« mĂ« shpejt dhe pĂ«rdor mĂ« pak HistoryCache â pĂ«rgjithĂ«sisht, tĂ« dhĂ«nat do tĂ« dĂ«rgohen nĂ« kohĂ«. Edhe njĂ« herĂ«, 80 mijĂ« vlera nĂ« sekondĂ« â Ă«shtĂ« njĂ« ritĂ«m mjaft i lartĂ« (sigurisht, jo pĂ«r "Yandex"). NĂ« tĂ«rĂ«si, Ă«shtĂ« njĂ« setup mjaft i madh, me njĂ« server.
Testi i performancës PostgreSQL: 120 mijë NVPs
Më pas e rita vlerën e numrit të elementeve të dhënash deri në gjysmë milioni dhe arrita një vlerë të kalkuluar prej 125 mijë në sekondë:
Dhe mora këto grafika:
Praktikisht, ky është një setup funksional, ai mund të punojë për një kohë të gjatë. Por pasi kisha një disk prej vetëm 1.5 terabajtësh, e shpenzova atë për disa ditë. Më e rëndësishmja, në të njëjtën kohë, u krijuan partitë e reja në TimescaleDB, dhe kjo për performancën kaloi krejtësisht pa u vënë re, gjë që nuk mund të thuhet për MySQL.
Zakonisht partitë krijohen natën, sepse kjo ndalon gjithçka sa i përket futjes dhe punës me tabelat, dhe mund të çojë në degradimin e shërbimit. Në këtë rast, kjo nuk ndodhi! Detyra kryesore ishte të provonim mundësitë e TimescaleDB. U arrit një numër i tillë: 120 mijë vlera në sekondë.
Gjithashtu ka në komunitet shembuj:
Një person gjithashtu aktivizoi TimescaleDB dhe ngarkesa në përdorimin e io.weight ra në procesor; dhe përdorimi i elementeve të proceseve të brendshme gjithashtu ra falë aktivizimit të TimescaleDB. Dhe blloqet janë blloqe të zakonshme, pra një virtualizues i zakonshëm në blloqet e zakonshme (jo SSD)!
Për ndonjë setup të vogël, që hasin në performancën e disku, TimescaleDB, siç mendoj, është një zgjidhje shumë e mirë. Ai do të lejojë të vazhdoj punën deri sa të migroj në pajisje më të shpejta për databazën.
Ftoj të gjithëve në ngjarjet tona: Konferenca - në Moskë, Samiti - në Rigë. Përdorni kanalet tona - "Telegram", forum, IRC. Nëse keni ndonjë pyetje - vini të flasim me ne në stendë, mund të diskutojmë për gjithçka.
Pyetjet e publikut
Pyetja e publikut (mĂ« vonĂ« â P): â NĂ«se TimescaleDB Ă«shtĂ« kaq e lehtĂ« pĂ«r t'u konfiguruar dhe ofron njĂ« rritje tĂ« tillĂ« tĂ« performancĂ«s, ndoshta duhet ta pĂ«rdorim si njĂ« praktikĂ« tĂ« mirĂ« pĂ«r konfigurimin e «Zabbix» me «PostgreSQL»? A ka ndonjĂ« pengesĂ« ose disavantazh nĂ« kĂ«tĂ« zgjidhje, apo vallĂ«, nĂ«se vendosa tĂ« pĂ«rdor «Zabbix», mund tĂ« marr «PostgreSQL», ta instaloj «Timescale» menjĂ«herĂ« dhe ta shfrytĂ«zoj pa u shqetĂ«suar pĂ«r ndonjĂ« problem?
AG: â Po, do tĂ« thosha se kjo Ă«shtĂ« njĂ« rekomandim i mirĂ«: tĂ« pĂ«rdorni «PostgreSQL» menjĂ«herĂ« me zgjerimin TimescaleDB. Siç kam thĂ«nĂ«, ka shumĂ« komente tĂ« mira, ndonĂ«se kjo «veçori» Ă«shtĂ« eksperimentale. Por nĂ« tĂ« vĂ«rtetĂ«, testet tregojnĂ« se kjo Ă«shtĂ« njĂ« zgjidhje e shkĂ«lqyer (me TimescaleDB), dhe mendoj se do tĂ« zhvillohet! Ne po ndjekim se si po zhvillohet kjo zgjerim dhe do tĂ« rregullojmĂ« atĂ« qĂ« nevojitet.
Gjatë zhvillimit ne u mbështetëm në një nga «veçoritë» e tyre të njohura: atje mund të punonit pak ndryshe me çunkat. Por pastaj ata e hoqën atë në versionin e ardhshëm dhe na duhej të mos mbështeteshim në atë kod. Do të rekomandoja ta përdornit këtë zgjidhje në shumë sete. Nëse po përdorni MySQL... Për sete të mesme çdo zgjidhje funksionon mirë.
P: â NĂ« graphĂ«t e fundit nga komuniteti, kishte njĂ« grafik me «Housekeeperin»:
Ai vazhdoi tĂ« punonte. ĂfarĂ« bĂ«n «Housekeeperi» nĂ« rastin e TimescaleDB?
AG: â Tani nuk mund tĂ« them saktĂ«sisht â do ta shikoj kodin dhe do tĂ« them mĂ« nĂ« detaje. Ai pĂ«rdor kĂ«rkesat e TimescaleDB jo pĂ«r tĂ« fshirĂ« çunkat, por siç duket agregon. Deri tani nuk jam i gatshĂ«m tĂ« pĂ«rgjigjem pĂ«r kĂ«tĂ« pyetje teknike. NĂ« stendĂ« sot ose nesĂ«r do tĂ« sqarojmĂ«.
P: â Kam njĂ« pyetje tĂ« ngjashme â pĂ«r performancĂ«n e operacionit tĂ« fshirjes nĂ« «Timescale».
P (pĂ«rgjigja e publikut): â Kur fshini tĂ« dhĂ«na nga tabela, nĂ«se e bĂ«ni kĂ«tĂ« pĂ«rmes fshirjes, duhet tĂ« kaloni pĂ«rmes tabelĂ«s â tĂ« fshini, pastroni, tĂ« shĂ«noni gjithçka pĂ«r vakuumin e ardhshĂ«m. NĂ« «Timescale», pasi keni çunka, mund tĂ« hiqni. NĂ« thelb, thjesht i thoni skedarit qĂ« ndodhet nĂ« big data: «Fshi!»
«TimeScale» simply understands that this chunk no longer exists. Since it integrates into the query planner, it captures your conditions in the select or other operations and immediately realizes that this chunk is gone â «I will not go there anymore!» (data unavailable). That's it! This means that scanning the table is replaced by deleting the binary file, so it's fast.
P: â We've touched on the non-SQL topic already. As far as I understand, «Zabbix» doesnât really need to modify data, and all this is more like a log. Can we use specialized databases that can't change their data but can save, accumulate, and retrieve much faster â something like ClickHouse or something Kafka-like?.. Kafka is also a log! Can we somehow integrate them?
AG: â You can perform an export. We have a specific feature since version 3.4: you can write all historical files, events, and everything else to files; and then send them to any other database with some handler. In fact, many people redo and write directly to the database. Historical syncers write all this to files on the fly, rotate these files, etc., and you can transfer them into «ClickHouse». I can't comment on future plans, but perhaps further support for NoSQL solutions (like «ClickHouse») will continue.
P: â So, is it possible to completely eliminate Postgres?
AG: â Of course, the most challenging part in «Zabbix» is the historical tables, which create the most problems, along with the events. In this case, if you donât keep events for a long time and store history with trends in some other fast storage, then overall there shouldnât be any issues, I believe.
P: â Can you estimate how much faster everything will work if we switch to «ClickHouse», for example?
AG: â I haven't tested it. I think, at the very least, similar numbers can be achieved quite easily, considering that «ClickHouse» has its own interface, but I can't say for sure. It's better to test. Everything depends on the configuration: how many hosts you have, and so on. Insertion is one thing, but you also need to retrieve this data â with Grafana or something else.
P: â So, it's about an equal competition, not a significant advantage for these fast databases?
AG: â I think when we integrate, we will have more accurate tests.
P: â Po shkuan ato RRD-tĂ« e vjetra tĂ« mira? ĂfarĂ« e detyroi kalimin nĂ« bazat e tĂ« dhĂ«nave SQL? Fillimisht, tĂ« gjitha metrikat mblidheshin nĂ« RRD.
AG: â NĂ« 'Zabbix', RRD mund tĂ« ketĂ« qenĂ« nĂ« njĂ« version shumĂ« tĂ« vjetĂ«r. GjithmonĂ« kanĂ« qenĂ« bazat e tĂ« dhĂ«nave SQL â njĂ« qasje klasike. Qasja klasike Ă«shtĂ« MySQL, PostgreSQL (janĂ« ekzistuar shumĂ« kohĂ« mĂ« parĂ«). Ne ndoshta kurrĂ« nuk e kemi pĂ«rdorur njĂ« ndĂ«rfaqe tĂ« pĂ«rbashkĂ«t pĂ«r bazat e tĂ« dhĂ«nave SQL dhe RRD.
Pak reklamĂ« đ
Faleminderit që po qëndroni me ne. Ju pëlqen artikujt tanë? Doni të shihni më shumë materiale interesante? Na mbështesni duke bërë një porosi ose duke rekomanduar tek miqtë tuaj, , një analog unik i serverëve entry-level që e kemi shpikur për Ju: (opcionet me RAID1 dhe RAID10, deri në 24 bërthama dhe deri në 40GB DDR4 janë të disponueshme).
Dell R730xd dyfish mĂ« i lirĂ« nĂ« qendĂ«r tĂ« tĂ« dhĂ«nave Equinix Tier IV nĂ« Amsterdam? VetĂ«m te ne nĂ« HolandĂ«! Dell R420 â 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB â nga $99! Lexoni rreth
Burimi: habr.com
