Ne do të shqyrtojmë funksionimin e Zabbix me bazën e të dhënave TimescaleDB si backend. Do të tregojmë si të nisni nga zero dhe si të migroni nga PostgreSQL. Do të ofrojmë gjithashtu teste të krahasimit të performancës të dy konfigurimeve.
HighLoad++ Siberia 2019. Salla "Tomsk". 24 qershor, 16:00. Tezat dhe . Konferenca e ardhshme HighLoad++ do të mbahet më 6 dhe 7 prill 2020 në Shën Petersburg. Detajet dhe biletat .
Andrei Gushchin (mĂ« pas â AG): â UnĂ« jam inxhinier i mbĂ«shtetjes teknike tĂ« ZABBIX (mĂ« pas â "Zabbix"), trainer. Kam punuar mĂ« shumĂ« se 6 vjet nĂ« mbĂ«shtetje teknike dhe kam pasur eksperiencĂ« tĂ« drejtpĂ«rdrejtĂ« me performancĂ«n. Sot do tĂ« flas pĂ«r performancĂ«n qĂ« mund tĂ« ofrojĂ« TimescaleDB, nĂ« krahasim me PostgreSQL 10. Gjithashtu, disa informacione hyrĂ«se â se si funksionon nĂ« tĂ«rĂ«si.
Sfida kryesore e performancës: nga grumbullimi deri te pastrimi i të dhënave
Le të fillojmë me faktin se ka sfida të caktuara të performancës me të cilat përballet çdo sistem monitorimi. Sfida e parë e performancës është grumbullimi 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 në kohë, sipas shprehjeve të ndjeshmërisë, domethënë, të përpunojë sipas disa kritereve (në sisteme të ndryshme, ky proces ndodhet ndryshe) dhe të ruajë në bazën e të dhënave, në mënyrë që më vonë të përdoren këto të dhëna.
Sfida e dytë e performancës është ruajtja e historisë. Ruajtja e të dhënave në një bazë të dhënash është shpesh e nevojshme dhe duhet të ofrohet një akses i shpejtë dhe i lehtë në këto metrika që janë mbledhur për një periudhë të caktuar kohe. Më e rëndësishmja, që këto të dhëna të jenë të lehta për t'u marrë, t'i përdorësh ato në raporte, grafike, ndjeshmëri, në disa vlera pragore, për njoftime etj.
Sfida e tretĂ« e performancĂ«s Ă«shtĂ« pastrimi i historisĂ«, qĂ« do tĂ« thotĂ« kur vjen njĂ« ditĂ« kur nuk duhet tĂ« ruash disa metrika tĂ« detajuara qĂ« janĂ« mbledhur pĂ«r 5 vjet (edhe pĂ«r muaj ose dy muaj). Disa nyje tĂ« rrjetit janĂ« fshirĂ«, ose disa hoste, metrika tashmĂ« nuk janĂ« tĂ« nevojshme sepse ato janĂ« bĂ«rĂ« tĂ« vjetra dhe nuk po mbledhen mĂ«. Po, tĂ« gjitha kĂ«to duhet tĂ« pastrohen, nĂ« mĂ«nyrĂ« qĂ« baza e tĂ« dhĂ«nave tĂ« mos rritet nĂ« njĂ« madhĂ«si tĂ« madhe. Dhe nĂ« pĂ«rgjithĂ«si, pastrimi i historisĂ« shpesh Ă«shtĂ« njĂ« provĂ« serioze pĂ«r depot â zakonisht ndikon shumĂ« nĂ« performancĂ«.
Si të zgjidhni problemet e cache-it?
Dua të flas konkretisht për "Zabbix". Në "Zabbix", sfidat e para dhe të dyta zgjidhen përmes cache-it.
Grumbullimi dhe pĂ«rpunimi i tĂ« dhĂ«nave â ne pĂ«rdorim kujtesĂ«n operuese pĂ«r tĂ« ruajtur tĂ« gjitha kĂ«to tĂ« dhĂ«na. Tani do tĂ« flitet mĂ« shumĂ« pĂ«r kĂ«to tĂ« dhĂ«na.
Po ashtu, nga ana e bazĂ«s sĂ« tĂ« dhĂ«nave ka njĂ« cache tĂ« caktuar pĂ«r pĂ«rzgjedhjet kryesore â pĂ«r grafike, dhe gjĂ«ra tĂ« tjera.
Cache-i nĂ« anĂ«n e vetĂ« serverit Zabbix: ne kemi ConfigurationCache, ValueCache, HistoryCache, TrendsCache. ĂfarĂ« janĂ« kĂ«to?
ConfigurationCache është cache-i kryesor, në të cilin ne ruajmë metrikat, hostet, elementët e të dhënave, ndjeshmëritë; gjithçka që nevojitet për përpunimin e paraproçesit, grumbullimin e të dhënave, nga cilat hoste të grumbullojmë, me cilën frekuencë. Të gjitha këto ruhen në ConfigurationCache, për të mos e kaluar në bazën e të dhënave, për të mos krijuar kërkesa të tepërta. Pas nisjes së serverit, ne përditësojmë këtë cache (krijojmë) dhe e rifreskojmë herë pas here (në varësi të cilësimeve të konfigurimit).
Cache-i në Zabbix. Grumbullimi i të dhënave
Këtu skema është mjaft e madhe:
Elementet kryesore nĂ« skemĂ« â janĂ« kĂ«ta grumbullues:
Këto janë proceset e grumbullimit, "pollers", që përgjigjen për lloje të ndryshme grumbullimi. Ata mbledhin të dhëna për icmp, ipmi, për protokolle të ndryshme dhe e dërgojnë gjithçka në paraproçesim.
HistoriCache e PreProcessing
Po ashtu, nëse kemi elementë të dhënash të llogaritur (kush është i njohur me "Zabbix" e di), janë elementë të llogaritur, aggregative, ne i marrim ato direkt nga ValueCache. Do të flas më vonë se si ai mbushet. Të gjithë këta grumbullues përdorin ConfigurationCache për të marrë detyrat e tyre dhe më pas i dërgojnë për paraproçesim.
Paraproçesimi gjithashtu përdor ConfigurationCache për të marrë hapat e paraproçesimit, përpunon këto të dhëna në mënyra të ndryshme. Duke filluar nga versioni 4.2, ai është vendosur te proxy. Kjo është shumë e përshtatshme, sepse vetë paraproçesimi është një operacion mjaft i rëndë. Dhe nëse keni një "Zabbix" shumë të madh, me një numër të madh elementësh të të dhënave dhe një frekuencë të lartë grumbullimi, kjo lehtësisht lehtëson punën.
Përkatësisht, pasi përpunojmë këto të dhëna në ndonjë mënyrë duke përdorur paraproçesimin, i ruajmë ato në HistoryCache për t'i përpunuar më tej. Këtu përfundon grumbullimi i të dhënave. Kalojmë në procesin kryesor.
Puna e History syncer
Procesi kryesor nĂ« «Zabbix» (pĂ«r shkak se kjo Ă«shtĂ« njĂ« arkitekturĂ« monolitike) â History syncer. Ky Ă«shtĂ« procesi kryesor qĂ« merret me pĂ«rpunimin atomar tĂ« çdo elementi tĂ« dhĂ«nash, domethĂ«nĂ« çdo vlerĂ«:
- vjen një vlerë (e merr nga HistoryCache);
- kontrollon nĂ« Configuration syncer: a ka ndonjĂ« trigger pĂ«r llogaritje â i llogarit ato;
nĂ«se ka â krijon ngjarje, krijon eskalimin pĂ«r tĂ« krijuar njĂ« njoftim, nĂ«se Ă«shtĂ« e nevojshme sipas konfigurimit; - regjistron triggerat pĂ«r pĂ«rpunim tĂ« mĂ«vonshĂ«m, agregim; nĂ«se jeni duke agreguar pĂ«r orĂ«n e fundit dhe kĂ«shtu me radhĂ«, kjo vlerĂ« e ruan nĂ« ValueCache, pĂ«r ta shmangur aksesin nĂ« tabelĂ«n e historisĂ«; kĂ«shtu, ValueCache mbushet me tĂ« dhĂ«nat e nevojshme pĂ«r llogaritjen e triggerave, elementeve tĂ« llogaritura etj.;
- pastaj History syncer regjistron të gjitha të dhënat në bazën e të dhënave;
- baza e tĂ« dhĂ«nave i regjistron ato nĂ« disk â nĂ« kĂ«tĂ« pikĂ« procesi i pĂ«rpunimit pĂ«rfundohet.
Baza të dhënash. Keshimi
Në anën e DB-së, kur dëshironi të shihni grafiko ose ndonjë raport për ngjarjet, ka disa keshime të ndryshme. Por në kuadër të këtij raporti nuk do flas për to.
Për MySQL ka Innodb_buffer_pool, dhe shumë keshime të tjera të ndryshme që gjithashtu mund të konfigurohen.
Por këto janë kryesorët:
- shared_buffers;
- effective_cache_size;
- shared_pool.
Unë kam paraqitur për të gjitha bazat e të dhënave që ka disa keshime, që lejojnë mbajtjen në memorje për ato të dhëna që janë shpesh të nevojshme për kërkesat. Aty kanë teknologjitë e tyre për këtë.
Për performancën e bazës së të dhënave
Sipas kësaj, ka një ambient konkurrues, domethënë serveri «Zabbix» mbledh të dhënat dhe i regjistron ato. Gjatë rimarrjes ai gjithashtu lexon nga historia për të mbushur ValueCache dhe kështu me radhë. Po ashtu, mund të keni skriptet dhe raportet që përdorin «Zabbix»-API, i cili është ndërtuar mbi ndërfaqen web. «Zabbix»-API hyn në DB dhe merr të dhënat e nevojshme për të marrë grafiko, raporte ose ndonjë listë ngjarjesh, problemet e fundit.
Një zgjidhje shumë e njohur për vizualizimin është Grafana, që e përdorin përdoruesit tanë. Ajo di të hyjë direkt përmes «Zabbix»-API ose përmes DB. Ajo gjithashtu krijon një garë të caktuar për të marrë të dhënat: kërkohet një konfigurim më i hollë dhe i mirë i DB-së për të përmbushur shpërndarjen e shpejtë të rezultateve dhe testimin.
Pastrimi i historisë. Në Zabbix ka një Housekeeper
Thirrja e tretĂ«, qĂ« pĂ«rdoret nĂ« «Zabbix» â Ă«shtĂ« pastrimi i historisĂ« me anĂ« tĂ« Housekeeper. «Housekeeper» respekton tĂ« gjitha konfigurimet, domethĂ«nĂ« ne nĂ« elementĂ«t e dhĂ«nash kemi pĂ«rcaktuar se sa tĂ« mbajmĂ« (nĂ« ditĂ«), sa tĂ« mbajmĂ« trendet, dinamika e ndryshimeve.
Nuk kam folur për TrendCache, të cilat i llogarisim në flutur: të dhënat vijnë, ne i agregojmë për një orë (më së shumti janë numrat e orës së fundit), mesatarja / minimale dhe regjistrojmë këtë një herë në orë në tabelën e dinamikave të ndryshimeve («Trends»). «Housekeeper» niset dhe fshin të dhënat nga DB me seleksione normale, që nuk është gjithmonë efikase.
Si ta kuptoni që kjo nuk është efikase? Mund të shihni një pamje të tillë në grafiket e performancës së proceseve të brendshme:
Ju keni History syncer të angazhuar vazhdimisht (grafiku i kuq). Dhe grafiku "portokalli", që kalon në kresht këtë. Kjo është «Housekeeper», i cili niset dhe pret nga DB që të fshijë të gjitha rreshtat që ai cakton.
Merrni ndonjĂ« ID Artikulli: duhet tĂ« fshini 5 mijĂ« tĂ« fundit; sigurisht, sipas indekseve. Por zakonisht dataset Ă«shtĂ« mjaft i madh â baza e tĂ« dhĂ«nave gjithsesi e lexon atĂ« nga disku dhe e ngre atĂ« nĂ« cache, dhe kjo Ă«shtĂ« njĂ« operacion shumĂ« i kushtueshĂ«m pĂ«r DB. NĂ« varĂ«si tĂ« madhĂ«sive tĂ« saj, kjo mund tĂ« çojĂ« nĂ« disa probleme performancĂ«s.
PĂ«r tĂ« çaktivizuar «Housekeeper» mund tĂ« bĂ«ni njĂ« mĂ«nyrĂ« tĂ« thjeshtĂ« â ne kemi ndĂ«rfaqen web tĂ« njohur pĂ«r tĂ« gjithĂ«. Konfigurimi nĂ« Administration general (konfigurimet pĂ«r «Housekeeper») ne çaktivizojmĂ« housekeeping-un e brendshĂ«m pĂ«r historinĂ« dhe trendet e brendshme. Si rezultat, «Housekeeper» nuk menaxhon mĂ« kĂ«tĂ«:
ĂfarĂ« mund tĂ« bĂ«ni mĂ« tej? E keni çaktivizuar, grafiket tuaja janĂ« rregulluar... Cilat mund tĂ« jenĂ« problemet nĂ« kĂ«tĂ« rast? ĂfarĂ« mund tĂ« ndihmojĂ«?
Particionimi (sekcionimi)
Kjo zakonisht konfigurohet 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 të gjitha këto në performancë. Por në përgjithësi, krijimi i një partie të re shpesh çon gjithashtu në disa probleme të caktuara.
NĂ« varĂ«si tĂ« konfigurimit tuaj (sa shumĂ« tĂ« dhĂ«na krijohen nĂ« njĂ« ditĂ«), zakonisht pĂ«rjashtoni minimumin â kjo Ă«shtĂ« 1 ditĂ«/particion, ndĂ«rsa pĂ«r "trendet", dinamikĂ«n e ndryshimeve â 1 muaj / njĂ« partition tĂ« ri. Kjo mund tĂ« ndryshojĂ« nĂ«se keni njĂ« konfigurim shumĂ« tĂ« madh.
Dua tĂ« them menjĂ«herĂ« pĂ«r pĂ«rmasat e konfigurimit: deri nĂ« 5 mijĂ« vlera tĂ« reja çdo sekondĂ« (nvps, siç quhet) â kjo do tĂ« konsiderohet njĂ« "set up" i vogĂ«l. Mesatarja Ă«shtĂ« nga 5 deri nĂ« 25 mijĂ« vlera çdo sekondĂ«. Ădo gjĂ« mĂ« shumĂ« se kaq â Ă«shtĂ« instalime tĂ« mĂ«dha dhe shumĂ« tĂ« mĂ«dha, tĂ« cilat kĂ«rkojnĂ« konfigurim shumĂ« tĂ« kujdesshĂ«m tĂ« bazĂ«s sĂ« tĂ« dhĂ«nave.
NĂ« instalime shumĂ« tĂ« mĂ«dha 1 ditĂ« â kjo mund tĂ« mos jetĂ« optimale. UnĂ« vetĂ« kam parĂ« nĂ« MySQL partitione prej 40 gigabajt nĂ« ditĂ« (dhe mĂ« shumĂ« mund tĂ« jenĂ«). Ky Ă«shtĂ« njĂ« volum shumĂ« i madh tĂ« dhĂ«nash, i cili mund tĂ« shkaktojĂ« disa probleme. Duhet ta zvogĂ«loni.
Përse është e nevojshme partitizimi?
ĂfarĂ« pĂ«rfitimi ofron Partitioning, mendoj se tĂ« gjithĂ« e dinĂ« â kjo Ă«shtĂ« ndarja e tabelave. Zakonisht, kĂ«to janĂ« skedarĂ« tĂ« veçantĂ« nĂ« disk dhe kĂ«rkesa tĂ« spanuara. Ai zgjedh mĂ« optimal njĂ« partition, nĂ«se kjo pĂ«rfshihet nĂ« ndarjen normale.
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 përcaktoni fillimin e ditës / mbarimin e ditës, dhe kjo është një partition. Sipas kësaj, nëse ju referoheni të dhënave dy ditë më parë, gjithçka do të zgjedhë nga baza e të dhënave më shpejt, sepse duhet të ngarkoni vetëm një skedar në cache dhe ta jepni (e jo një tabelë të madhe).
Shumë DB gjithashtu përshpejtojnë insertimin (shtimi në një child-table). Deri tani po flas në mënyrë abstrakte, por kjo është gjithashtu e mundur. Partitizimi shpesh ndihmon.
Elasticsearch për NoSQL
SĂ« fundmi, nĂ« 3.4, ne kemi futur njĂ« zgjidhje pĂ«r NoSQL. Shtuam mundĂ«sinĂ« pĂ«r tĂ« shkruajtur nĂ« Elasticsearch. Ju mund tĂ« shkruani disa lloje tĂ« veçanta: zgjidhni â ose shkruani numra, ose ndonjĂ« shenjĂ«; ne kemi tekst-string, mund tĂ« shkruani log nĂ« Elasticsearch⊠PĂ«rkatĂ«sisht, ndĂ«rfaqja web do tĂ« drejtohet gjithashtu drejt Elasticsearch. Kjo funksionon mjaft mirĂ« nĂ« disa raste, por pĂ«r momentin mund tĂ« pĂ«rdoret.
TimescaleDB. Hipertable
PĂ«r 4.4.2 vĂ«mĂ« re njĂ« gjĂ«, siç Ă«shtĂ« TimescaleDB. ĂfarĂ« Ă«shtĂ« kjo? Kjo Ă«shtĂ« njĂ« zgjerim pĂ«r "Postgres", pra ka njĂ« ndĂ«rfaqe natyrore pĂ«r PostgreSQL. PĂ«rveç kĂ«saj, ky zgjerim lejon tĂ« punosh shumĂ« mĂ« efektivisht me tĂ« dhĂ«nat e kohĂ«s dhe tĂ« kesh partitizim automatik. Si duket:
Ky Ă«shtĂ« hipertable â ka njĂ« koncept tĂ« tillĂ« nĂ« Timescale. Kjo Ă«shtĂ« hipertabela qĂ« ju krijoni, dhe nĂ« tĂ« ka chunks (chunk). Chunks janĂ« partitione, kĂ«to janĂ« child-tables, nĂ«se nuk gaboj. Kjo Ă«shtĂ« vĂ«rtet efikase.
TimescaleDB dhe PostgreSQL
Siç garantohen prodhuesit e TimescaleDB, ata pĂ«rdorin njĂ« algoritĂ«m mĂ« tĂ« saktĂ« pĂ«r pĂ«rpunimin e kĂ«rkesave, sidomos insertâave, i cili lejon tĂ« kesh njĂ« performancĂ« pothuajse konstante me rritjen e madhĂ«sisĂ« sĂ« dataset-insertit. Pra, pas 200 milion rreshtash "Postgres" normal fillon tĂ« bjerĂ« shumĂ« dhe humbet performancĂ«n deri nĂ« zero, ndĂ«rsa "Timescale" lejon qĂ« insertet tĂ« realizohen sa mĂ« efikasht tĂ« jetĂ« e mundur me çdo sasi tĂ« dhĂ«nash.
Si tĂ« instaloni TimescaleDB? ĂshtĂ« shumĂ« e thjeshtĂ«!
Ka dokumentacion pĂ«r tĂ«, e pĂ«rshkruar â mund tĂ« instaloni nga paketat pĂ«r çdo... Ky varion nga paketat zyrtare tĂ« "Postgres". Mund tĂ« kompiloni manualisht. MĂ« ndodhi tĂ« kompiloj pĂ«r DB.
Në "Zabbix" ne thjesht aktivizojmë Extention. Mendoj se ata që kanë përdorur në "Postgres" Extention⊠Thjesht aktivizoni Extention, krijoni atë për DB "Zabbix" që po përdorni.
Dhe hapi i fundit...
TimescaleDB. Migrimi i tabelave të historisë
Ju duhet tĂ« krijoni hipertable. PĂ«r kĂ«tĂ« ka njĂ« funksion tĂ« veçantĂ« â Create hypertable. NĂ« tĂ«, parametri i parĂ« tregon tabelĂ«n qĂ« nevojitet nĂ« kĂ«tĂ« DB (pĂ«r tĂ« cilĂ«n duhet tĂ« krijoni hipertabelĂ«n).
Fusha, mbi tĂ« cilĂ«n duhen krijuar, dhe chunk_time_interval (kjo Ă«shtĂ« intervali i chunks (particioneve qĂ« duhet tĂ« pĂ«rdorin). 86 400 â kjo Ă«shtĂ« njĂ« ditĂ«.
Parametri migrate_data: nëse e vendosni në true, atëherë ky transferon të gjitha të dhënat aktuale në chunks të krijuara paraprakisht.
UnĂ« vetĂ« e kam pĂ«rdorur migrate_data â kjo merr njĂ« kohĂ« tĂ« konsiderueshme, nĂ« varĂ«si tĂ« pĂ«rmasave tĂ« DB-sĂ« tuaj. UnĂ« kisha mbi njĂ« terabajt â krijimi zgjati mĂ« shumĂ« se njĂ« orĂ«. NĂ« disa raste gjatĂ« testimit, kam hequr tĂ« dhĂ«nat historike pĂ«r tekst (history_text) dhe string (history_str), qĂ« tĂ« mos i transferoja â ato nĂ« tĂ« vĂ«rtetĂ« nuk mĂ« interesonin.
Dhe pĂ«rditĂ«simi i fundit qĂ« po bĂ«jmĂ« nĂ« db_extention tonĂ«: ne instalojmĂ« timescaledb, qĂ« edhe baza e tĂ« dhĂ«nave dhe, nĂ« veçanti, âZabbixâ tĂ« kuptojĂ« se ekziston db_extention. Ai e aktivizon atĂ« dhe pĂ«rdor sintaksĂ«n dhe kĂ«rkesat e duhura pĂ«r bazĂ«n e tĂ« dhĂ«nave, duke shfrytĂ«zuar âtiparetâ qĂ« kĂ«rkohen pĂ«r TimescaleDB.
Konfigurimi i serverit
Kam pĂ«rdorur dy serverĂ«. Serveri i parĂ« â Ă«shtĂ« njĂ« makinĂ« virtuale mjaft e vogĂ«l, me 20 procese, 16 gigabajt RAM. E kam konfiguruar me PostgreSQL 10.8:
Sistemi operativ ishte Debian, sistemi i skedarĂ«ve â xfs. Kam bĂ«rĂ« konfigurime minimale qĂ« tĂ« pĂ«rdor saktĂ«sisht kĂ«tĂ« bazĂ« tĂ« dhĂ«nash, pĂ«rveç asaj qĂ« do tĂ« pĂ«rdorte vetĂ« âZabbixâ. NĂ« tĂ« njĂ«jtĂ«n makinĂ« kishte serverin âZabbixâ, PostgreSQL dhe agjentĂ«t e ngarkesĂ«s.
Kam pĂ«rdorur 50 agjentĂ« aktivĂ«, qĂ« pĂ«rdorin LoadableModule, pĂ«r tĂ« gjeneruar shpejt rezultate tĂ« ndryshme. Ata gjeneruan rreshta, numra dhe kĂ«shtu me radhĂ«. E mbusha bazĂ«n e tĂ« dhĂ«nave me njĂ« sasi tĂ« madhe tĂ« dhĂ«nash. Fillimisht, konfigurimi pĂ«rmbante 5 mijĂ« elementĂ« tĂ« dhĂ«nash pĂ«r çdo host, dhe çdo element tĂ« dhĂ«nash kishte njĂ« trigger â nĂ« mĂ«nyrĂ« qĂ« tĂ« ishte njĂ« konfigurim real. NdonjĂ«herĂ« duhen mĂ« shumĂ« se njĂ« trigger pĂ«r pĂ«rdorim.
Intervali i përditësimit, ngarkesa e vetë, e regulloja duke përdorur jo vetëm 50 agjentë (shtoja edhe të tjerë), por gjithashtu me elemente dinamike të dhënash dhe e ulja intervalin e përditësimit në 4 sekonda.
Testi i performancës. PostgreSQL: 36 mijë NVPs
PĂ«r herĂ« tĂ« parĂ«, konfigurimi im ishte me PostgreSQL 10 tĂ« pastĂ«r nĂ« kĂ«tĂ« hardware (35 mijĂ« vlera nĂ« sekondĂ«). Siç duket nĂ« ekran, futja e tĂ« dhĂ«nave zgjat fraksione sekondash â gjithçka Ă«shtĂ« mirĂ« dhe e shpejtĂ«, SSD-tĂ« (200 gigabajt). E vetmja gjĂ« Ă«shtĂ« se 20 GB plotsish janĂ« plotĂ«sisht tĂ« shpejta.
Do tĂ« ketĂ« ende shumĂ« grafi tĂ« tilla. Kjo Ă«shtĂ« dashboards standarde e performancĂ«s sĂ« serverit âZabbixâ.
Grafiku i parĂ« â numri i vlerave nĂ« sekondĂ« (blu, sipĂ«r majtas), 35 mijĂ« vlera nĂ« kĂ«tĂ« rast. Ky (sipĂ«r nĂ« qendĂ«r) Ă«shtĂ« ngarkesa e proceseve tĂ« mbledhjes, ndĂ«rsa ky (sipĂ«r nĂ« tĂ« djathtĂ«) Ă«shtĂ« ngarkesa e proceseve tĂ« brendshme: history syncers dhe housekeeper, tĂ« cilĂ«t kĂ«tu (nĂ« fund nĂ« qendĂ«r) u ekzekutuan pĂ«r njĂ« kohĂ« tĂ« gjatĂ«.
Ky grafik (nĂ« fund nĂ« qendĂ«r) tregon pĂ«rdorimin e ValueCache â sa hit-e tĂ« ValueCache pĂ«r triggerat (disa mijĂ«ra vlera nĂ« sekondĂ«). NjĂ« grafik tjetĂ«r i rĂ«ndĂ«sishĂ«m â grafiku i katĂ«rt (nĂ« fund majtas) qĂ« tregon pĂ«rdorimin e HistoryCache, pĂ«r tĂ« cilin kam folur, i cili Ă«shtĂ« njĂ« buffer para futjes nĂ« bazĂ«n e tĂ« dhĂ«nave.
Testi i performancës. PostgreSQL: 50 mijë NVPs
MĂ« pas e rrita ngarkesĂ«n nĂ« 50 mijĂ« vlera nĂ« sekondĂ« nĂ« kĂ«tĂ« hardware. GjatĂ« ngarkesĂ«s nga âHousekeeperâ, 10 mijĂ« vlera u regjistruan brenda 2-3 sekondave me llogaritje. ĂfarĂ«, nĂ« fakt, Ă«shtĂ« treguar nĂ« screenshot-in e ardhshĂ«m:
âHousekeeperâ tashmĂ« po fillon tĂ« pengojĂ« funksionimin, por pĂ«rgjithĂ«sisht ngarkesa e triggerave tĂ« history-syncers akoma Ă«shtĂ« nĂ« nivelin 60 % (grafiku i tretĂ«, sipĂ«r nĂ« tĂ« djathtĂ«). HistoryCache gjatĂ« punĂ«s sĂ« âHousekeeperâ fillon tĂ« mbushet aktivisht (nĂ« fund majtas). Ai ishte rreth gjysmĂ« gigabait, duke u mbushur nĂ« 20%.
Testi i performancës. PostgreSQL: 80 mijë NVPs
Më pas e rita në 80 mijë vlera në sekondë:
Ishte rreth 400 mijĂ« elementĂ« tĂ« dhĂ«nash, 280 mijĂ« triggera. Futja, siç e shihni, me ngarkesĂ«n e history-syncers (tĂ« cilĂ«t ishin 30) ishte mjaft e lartĂ«. MĂ« pas e rita parametra tĂ« ndryshĂ«m: history-syncers, cache⊠NĂ« kĂ«tĂ« hardware ngarkesa e history-syncers filloi tĂ« rritej nĂ« maksimum, pothuajse ânĂ« raftâ â pĂ«rkatĂ«sisht, HistoryCache shkoi nĂ« njĂ« ngarkesĂ« shumĂ« tĂ« lartĂ«:
GjithĂ« kĂ«tĂ« kohĂ« kam mbajtur nĂ«n vĂ«shtrim tĂ« gjithĂ« parametrat e sistemit (si pĂ«rdoret procesori, memoria RAM) dhe kam zbuluar se shfrytĂ«zimi i disqeve ishte maksimal â arrita kapacitetin maksimal tĂ« kĂ«tij disku nĂ« kĂ«tĂ« hardware, nĂ« kĂ«tĂ« makinĂ« virtuale. âPostgreSQLâ filloi, me njĂ« intensitet tĂ« tillĂ«, tĂ« hiqte tĂ« dhĂ«na mjaft aktivisht, dhe disku nuk arrinte mĂ« pĂ«r tĂ« shkruar, lexuarâŠ
Mora një server tjetër, i cili tashmë kishte 48 procese dhe 128 gigabajt RAM:
Po ashtu e kam âoptimizuarâ â vendosa history syncer (60 copĂ«) dhe arrita njĂ« performancĂ« tĂ« pranueshme. NĂ« fakt, ne nuk jemi ânĂ« raftâ, por kĂ«tĂ« Ă«shtĂ«, mbase, kufiri i performancĂ«s, ku tashmĂ« duhet tĂ« ndĂ«rmarrim disa veprime.
Testi i performancës. TimescaleDB: 80 mijë NVPs
Ishte njĂ« nga detyrat e mia kryesore â tĂ« pĂ«rdor TimescaleDB. NĂ« çdo grafik shihet rĂ«nia:
KĂ«to dĂ«shtime janĂ« pikĂ«risht migrimi i tĂ« dhĂ«nave. Pas kĂ«saj, nĂ« serverin «Zabbix», profili i ngarkesĂ«s pĂ«r historinĂ« e sinkronizuesve ka ndryshuar ndjeshĂ«m. Ai lejon futjen e tĂ« dhĂ«nave pothuajse 3 herĂ« mĂ« shpejt dhe pĂ«rdor mĂ« pak HistoryCache â pĂ«r pasojĂ«, tĂ« dhĂ«nat do tĂ« dĂ«rgohen nĂ« kohĂ«. PĂ«rsĂ«ri, 80 mijĂ« vlera nĂ« sekondĂ« â Ă«shtĂ« njĂ« nivel mjaft i lartĂ« (sigurisht, jo pĂ«r «Yandex»). NĂ« pĂ«rgjithĂ«si, kjo Ă«shtĂ« njĂ« konfigurim mjaft i madh, me njĂ« server.
Testi i performancës PostgreSQL: 120 mijë NVPs
Për më tepër, e rrisja vlerën e numrit të elementeve të dhënave në gjysmë milioni dhe mora një vlerësim prej 125 mijë në sekondë:
Dhe mora këto grafika:
Në parim, kjo është një konfigurim funksional, ai mund të punojë për një kohë të gjatë. Por pasi kisha një disk prej vetëm 1.5 terabajtësh, e konsumova atë brenda disa ditësh. E rëndësishmja është se në të njëjtën kohë po krijoheshin partitë të reja në TimescaleDB, dhe kjo për performancën ndodhte krejtësisht pa u vënë re, ndryshe nga MySQL.
Zakonisht, partitë krijohen natën, sepse ato bllokojnë plotësisht futjen dhe punën me tabelat, duke mundësuar degradimin e shërbimit. Në këtë rast, nuk ka asnjë çështje! Qëllimi kryesor ishte të kontrollonim kapacitetet e TimescaleDB. Rezultati ishte kjo shifër: 120 mijë vlera në sekondë.
Ka gjithashtu shembuj në «komunitet»:
Një person gjithashtu aktivizoi TimescaleDB dhe ngarkesa për përdorimin e io.weight ra në procesor; dhe përdorimi i elementeve të proceseve të brendshme gjithashtu ra falë aktivizimit të TimescaleDB. Dhe kjo ndodhi edhe me disqet e zakonshme, pra një virtualizim normal në disqe të zakonshme (jo SSD)!
Për disa konfigurime të vogla, të cilat kufizohen nga performanca e disqit, TimescaleDB, mendoj se është një zgjidhje shumë e mirë. Ai do të lejojë që të vazhdojë të punojë deri sa të migrosh në një harduer më të shpejtë për bazën e të dhënave.
Ju ftoj tĂ« gjithĂ« nĂ« ngjarjet tona: Konferenca â nĂ« MoskĂ«, Samiti â nĂ« RigĂ«. PĂ«rdorni kanalet tona â «Telegram», forum, IRC. NĂ«se keni ndonjĂ« pyetje â ejani tek stenda jonĂ«, mund tĂ« flasim pĂ«r çdo gjĂ«.
Pyetje nga publiku
Pyetje nga publiku (mĂ« tej â A): â NĂ«se TimescaleDB Ă«shtĂ« kaq e lehtĂ« pĂ«r tu konfiguruar dhe ofron njĂ« rritje tĂ« tillĂ« tĂ« performancĂ«s, ndoshta do tĂ« ishte mĂ« mirĂ« ta pĂ«rdorim si njĂ« praktikĂ« tĂ« mirĂ« tĂ« konfigurimit tĂ« «Zabbix» me «PostgreSQL»? Dhe a ka ndonjĂ« pengesĂ« ose disavantazh tĂ« kĂ«saj zgjidhjeje, apo nĂ«se vendosa tĂ« bĂ«j «Zabbix», mund tĂ« marr «PostgreSQL», ta vendos aty «Timescale» menjĂ«herĂ«, ta pĂ«rdor dhe tĂ« mos mendoj pĂ«r ndonjĂ« problem?
AG: â Po, do tĂ« thoja se kjo Ă«shtĂ« njĂ« rekomandim i mirĂ«: tĂ« pĂ«rdorĂ«sh «PostgreSQL» menjĂ«herĂ« me zgjerimin TimescaleDB. Siç kam thĂ«nĂ«, ka shumĂ« komente pozitive, megjithĂ«se ky «feature» Ă«shtĂ« eksperimental. Por nĂ« tĂ« vĂ«rtetĂ«, testet tregojnĂ« se Ă«shtĂ« njĂ« zgjidhje e shkĂ«lqyer (me TimescaleDB), dhe mendoj se do tĂ« zhvillohet! Ne e ndjekim si zhvillohet ky zgjerim dhe do tĂ« rregullojmĂ« çkaf unĂ« nevojitet.
Madje, gjatë zhvillimit u mbështetëm te një nga karakteristikat e njohura të tij: aty mund të punoje me chunks pak ndryshe. Por më pas ata e hoqën atë në versionin e ardhshëm, dhe ne u detyruam të mos mbështeteshim më në këtë kod. Do t'i rekomandoja kësaj zgjidhjeje në shumë konfigurime. Nëse po përdorni MySQL... Për konfigurimet mesatare, çdo zgjidhje funksionon mjaft mirë.
A: â NĂ« grafikat e fundit, qĂ« janĂ« nga community, kishte njĂ« grafik me «Housekeeperin»:
Ai vazhdoi tĂ« punojĂ«. ĂfarĂ« bĂ«n «Housekeeper» nĂ« rastin e TimescaleDB?
AG: â Tani nuk mund tĂ« them saktĂ«sisht â do ta shoh kodin dhe do tĂ« them mĂ« nĂ« detaje. Ai pĂ«rdor kĂ«rkesat e TimescaleDB jo pĂ«r tĂ« fshirĂ« chunks, por siç duket, i agregon. Deri tani nuk jam i gatshĂ«m tĂ« pĂ«rgjigjem pĂ«r kĂ«tĂ« pyetje teknike. NĂ« stand sot ose nesĂ«r do ta sqarohem.
A: â Kam njĂ« pyetje tĂ« ngjashme â pĂ«r performancĂ«n e operacionit tĂ« fshirjes nĂ« «Timescale».
A (pĂ«rgjigje nga publiku): â 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, tĂ« pastroni, tĂ« gjitha tĂ« shĂ«nohen pĂ«r vakuumin nĂ« tĂ« ardhmen. NĂ« «Timescale», pĂ«r shkak se keni chunks, mund tĂ« hiqni direkt. Thjesht i thoni skedarit, i cili ndodhet nĂ« big data: «Fshij!»
«Timescale» thjesht e kupton se ai chunk nuk ekziston mĂ«. Dhe pasi ai integrohet nĂ« planifikuesin e kĂ«rkesave, ai kap kushtet tuaja nĂ« select ose nĂ« operacione tĂ« tjera dhe menjĂ«herĂ« kupton se ai chunk nuk ekziston mĂ« â «Nuk do tĂ« shkoj mĂ« atje!» (tĂ« dhĂ«nat mungojnĂ«). KĂ«shtu, skanimi i tabelĂ«s zĂ«vendĂ«sohet me fshirjen e skedarit binar, prandaj kjo Ă«shtĂ« e shpejtĂ«.
A: â Kemi trajtuar temĂ«n e jo-SQL. Sa kam kuptuar, «Zabbix» s'ka nevojĂ« tĂ« modifikojĂ« tĂ« dhĂ«nat shumĂ«, dhe gjithçka Ă«shtĂ« njĂ« lloj logu. A Ă«shtĂ« e mundur tĂ« pĂ«rdoren DB-specializuara, tĂ« cilat nuk mund tĂ« ndryshojnĂ« tĂ« dhĂ«nat e tyre, por nĂ« tĂ« njĂ«jtĂ«n kohĂ« tĂ« ruajnĂ«, akumullojnĂ« dhe ofrojnĂ« shumĂ« mĂ« shpejt â Clickhouse, pĂ«r shembull, diçka nĂ« mĂ«nyrĂ« kafkiane?.. Kafka gjithashtu Ă«shtĂ« njĂ« log! A Ă«shtĂ« e mundur tĂ« integrohen ndonjĂ«herĂ«?
AG: â Ekstraktimi mund tĂ« bĂ«het. Ne kemi njĂ« «feature» tĂ« caktuar qĂ« nga versioni 3.4: ju mund tĂ« shkruani nĂ« skedarĂ« tĂ« gjithĂ« skedarĂ«t historikĂ«, ngjarjet, gjithçka tjetĂ«r; dhe mĂ« pas me ndihmĂ«n e ndonjĂ« procesori dĂ«rgoni nĂ« çdo DB tjetĂ«r. NĂ« tĂ« vĂ«rtetĂ« shumĂ« njerĂ«z e ristrukturojnĂ« dhe shkruajnĂ« drejtpĂ«rdrejt nĂ« DB. HistorikĂ«-synkronizuesit e shkruajnĂ« gjithçka nĂ« skedarĂ«, rotullojnĂ« kĂ«ta skedarĂ« dhe kĂ«shtu me radhĂ«, dhe kĂ«tĂ« mund ta kaloni nĂ« «Clickhouse». Nuk mund tĂ« them asgjĂ« pĂ«r planet, por ndoshta mbĂ«shtetje e mĂ«tejshme pĂ«r zgjidhjet NoSQL (tĂ« tilla si «Clickhouse») do tĂ« vazhdojĂ«.
A: â Pra, a Ă«shtĂ« e mundur tĂ« shkurtohet plotĂ«sisht PostgreSQL?
AG: â Sigurisht, pjesa mĂ« e vĂ«shtirĂ« nĂ« «Zabbix» janĂ« tabelat historike, tĂ« cilat krijojnĂ« mĂ« shumĂ« probleme, dhe ngjarjet. NĂ« kĂ«tĂ« rast, nĂ«se nuk do tĂ« ruani ngjarjet pĂ«r njĂ« kohĂ« tĂ« gjatĂ« dhe do tĂ« mbani historinĂ« me trendet nĂ« ndonjĂ« depo mĂ« tĂ« shpejtĂ«, atĂ«herĂ« nĂ« pĂ«rgjithĂ«si nuk do tĂ« ketĂ« probleme, mendoj.
A: â A mund tĂ« vlerĂ«soni, sa mĂ« shpejt do tĂ« funksionojĂ« gjithçka, nĂ«se kalojmĂ« nĂ« «Clickhouse», pĂ«r shembull?
AG: â Nuk e kam testuar. Mendoj se tĂ« paktĂ«n numrat e njĂ«jtĂ« mund tĂ« arrihen mjaft lehtĂ«, duke marrĂ« parasysh qĂ« «Clickhouse» ka ndĂ«rfaqen e tij, por nuk mund tĂ« them me siguri. MĂ« mirĂ« tĂ« testoni. Gjithçka varet nga konfigurimi: sa host-e keni dhe kĂ«shtu me radhĂ«. Futja Ă«shtĂ« njĂ« gjĂ«, por duhet gjithashtu tĂ« merrni kĂ«to tĂ« dhĂ«na â me Grafana ose diçka tjetĂ«r.
A: â Pra, bĂ«het fjalĂ« pĂ«r njĂ« luftĂ« tĂ« barabartĂ«, jo njĂ« avantazh tĂ« madh tĂ« kĂ«tyre DB-ve tĂ« shpejta?
AG: â Mendoj se kur tĂ« integrojmĂ«, do tĂ« kemi teste mĂ« tĂ« sakta.
A: â Ku e la i vjetri RRD? ĂfarĂ« e detyroi kalimin nĂ« bazat e tĂ« dhĂ«nave SQL? Fillimisht, tĂ« gjitha metrikat janĂ« mbledhur nĂ« RRD.
AG: â NĂ« «Zabbix» RRD, ndoshta ka qenĂ« nĂ« njĂ« version shumĂ« tĂ« lashtĂ«. KanĂ« ekzistuar gjithmonĂ« bazat e tĂ« dhĂ«nave SQL â qasja klasike. Qasja klasike Ă«shtĂ« MySQL, PostgreSQL (janĂ« ekzistuar prej kohĂ«sh). Ne kemi njĂ« ndĂ«rfaqe tĂ« pĂ«rbashkĂ«t pĂ«r bazat e tĂ« dhĂ«nave SQL dhe RRD, qĂ« pothuajse kurrĂ« nuk e kemi pĂ«rdorur.
Pak reklamĂ« đ
Faleminderit që qëndroni me ne. Ju pëlqejnë artikujt tanë? Dëshironi të shihni më shumë materiale interesante? Na mbështetni duke bërë një porosi ose duke na rekomanduar njohurive tuaj, , një analog unik i serverëve entry-level, i ndërtuar për ju: (disponohen variante me RAID1 dhe RAID10, deri në 24 bërthama dhe deri në 40GB DDR4).
Dell R730xd dyfish mĂ« i lirĂ« nĂ« qendrĂ«n e tĂ« dhĂ«nave Equinix Tier IV nĂ« Amsterdam? VetĂ«m kĂ«tu nĂ« HolandĂ«! Dell R420 â 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB â nga $99! Lexoni rreth
Burimi: habr.com
