Taas nga pasundayag ug lumad nga partisyon: Zabbix nga adunay suporta sa TimescaleDB

Ang Zabbix usa ka sistema sa pagmonitor. Sama sa ubang sistema, nag-atubang kini og tulo ka nag-unang problema sa tanang sistema sa pagmonitor: pagkolekta ug pagproseso sa datos, pagtipig sa kasaysayan, ug paglimpyo niini.

Ang mga yugto sa pagdawat, pagproseso ug pagrekord sa datos nagkinahanglan og panahon. Dili kaayo, apan alang sa usa ka dako nga sistema kini mahimong moresulta sa daghang mga paglangan. Ang problema sa pagtipig usa ka isyu sa pag-access sa datos. Gigamit kini alang sa mga taho, pagsusi ug pag-trigger. Ang mga latency sa pag-access sa datos makaapekto usab sa performance. Kung ang mga database motubo, ang wala’y kalabotan nga datos kinahanglan nga tangtangon. Ang pagtangtang usa ka lisud nga operasyon nga mokaon usab sa pipila ka mga kapanguhaan.

Ang mga problema sa mga paglangan sa panahon sa pagkolekta ug pagtipig sa Zabbix masulbad pinaagi sa pag-cache: daghang mga tipo sa mga cache, pag-cache sa database. Aron masulbad ang ikatulo nga problema, ang caching dili angay, mao nga gigamit ni Zabbix ang TimescaleDB. Sultihan ka niya bahin niini Andrey Gushchin - teknikal nga suporta engineer Zabbix SIA. Si Andrey nagsuporta sa Zabbix sa sobra sa 6 ka tuig ug adunay direktang kasinatian sa pasundayag.

Giunsa pagtrabaho ang TimescaleDB, unsa nga pasundayag ang mahimo niini kung itandi sa regular nga PostgreSQL? Unsang papel ang gidula ni Zabbix alang sa database sa TimescaleDB? Giunsa pagsugod gikan sa wala ug kung giunsa ang paglalin gikan sa PostgreSQL ug unsang pagsulud ang adunay labi ka maayo nga pasundayag? Mahitungod niining tanan ubos sa pagputol.

Mga Hagit sa Pagkaproduktibo

Ang matag sistema sa pagmonitor nag-atubang sa piho nga mga hagit sa performance. Maghisgot ako bahin sa tulo niini: pagkolekta ug pagproseso sa datos, pagtipig, ug paglimpyo sa kasaysayan.

Paspas nga pagkolekta ug pagproseso sa datos. Ang usa ka maayo nga sistema sa pag-monitor kinahanglan nga dali nga makadawat sa tanan nga datos ug iproseso kini sumala sa mga ekspresyon sa pag-trigger - sumala sa mga pamatasan niini. Pagkahuman sa pagproseso, ang sistema kinahanglan usab nga dali nga i-save kini nga datos sa database aron magamit sa ulahi.

Pagtipig sa kasaysayan. Ang usa ka maayo nga sistema sa pag-monitor kinahanglan magtipig sa kasaysayan sa usa ka database ug maghatag dali nga pag-access sa mga sukatan. Ang kasaysayan gikinahanglan aron magamit sa mga report, mga graph, mga trigger, mga threshold, ug mga kalkulado nga alert data item.

Paglimpyo sa kasaysayan. Usahay moabut ang usa ka adlaw nga dili nimo kinahanglan nga magtipig mga sukatan. Ngano nga kinahanglan nimo ang datos nga nakolekta 5 ka tuig na ang milabay, usa o duha ka bulan: pipila ka mga node ang natangtang, ang ubang mga host o sukatan dili na kinahanglan tungod kay kini karaan na ug wala na makolekta. Ang usa ka maayo nga sistema sa pagmonitor kinahanglan nga magtipig sa makasaysayan nga datos ug tangtangon kini matag karon ug unya aron ang database dili motubo.

Ang paglimpyo sa mga stale data usa ka kritikal nga isyu nga nakaapekto kaayo sa performance sa database.

Pag-cache sa Zabbix

Sa Zabbix, ang una ug ikaduha nga tawag masulbad gamit ang caching. Ang RAM gigamit sa pagkolekta ug pagproseso sa datos. Alang sa pagtipig - kasaysayan sa mga trigger, mga graph ug kalkulado nga mga elemento sa datos. Sa kilid sa database adunay pipila ka caching alang sa mga batakang pagpili, pananglitan, mga graph.

Ang pag-cache sa kilid sa Zabbix server mismo mao ang:

• ConfigurationCache;
• ValueCache;
• HistoryCache;
• TrendsCache.

Atong hisgotan kini nga mas detalyado.

ConfigurationCache

Kini ang nag-unang cache diin kami nagtipig sa mga sukatan, mga host, mga butang sa datos, mga hinungdan - tanan nga among gikinahanglan alang sa PreProcessing ug alang sa pagkolekta sa datos.

Kining tanan gitipigan sa ConfigurationCache aron dili makamugna ug wala kinahanglana nga mga pangutana sa database. Human magsugod ang server, gi-update namo kini nga cache, paghimo ug pag-update matag karon ug unya sa mga configuration.

Pagkolekta sa datos

Ang diagram dako kaayo, apan ang nag-unang butang niini mao mga tigpili. Kini ang lainlaing "mga poller" - mga proseso sa pag-assemble. Sila ang responsable sa lain-laing mga matang sa asembliya: sila mangolekta og datos pinaagi sa SNMP, IPMI, ug ibalhin kining tanan ngadto sa PreProcessing.

Ang mga kolektor gilatid sa orange.

Gikalkulo ni Zabbix ang mga aggregation nga mga butang nga gikinahanglan sa aggregate checks. Kung aduna kami kanila, among gikuha ang datos alang kanila direkta gikan sa ValueCache.

PreProcessing HistoryCache

Ang tanan nga mga kolektor naggamit sa ConfigurationCache aron makadawat mga trabaho. Dayon ibalhin nila kini sa PreProcessing.

Ang PreProcessing naggamit sa ConfigurationCache aron makadawat sa mga lakang sa PreProcessing. Giproseso niini kini nga datos sa lainlaing mga paagi.

Human sa pagproseso sa datos gamit ang PreProcessing, among gitipigan kini sa HistoryCache para sa pagproseso. Gitapos niini ang pagkolekta sa datos ug nagpadayon kami sa panguna nga proseso sa Zabbix - tig-sync sa kasaysayan, tungod kay kini usa ka monolitikong arkitektura.

Hinumdomi: Ang PreProcessing usa ka lisud nga operasyon. Uban sa v 4.2 kini gibalhin sa proxy. Kung ikaw adunay dako kaayo nga Zabbix nga adunay daghang gidaghanon sa mga elemento sa datos ug frequency sa pagkolekta, nan kini naghimo sa trabaho nga mas sayon.

ValueCache, kasaysayan ug mga uso cache

Ang history syncer mao ang nag-unang proseso nga atomiko nga nagproseso sa matag elemento sa datos, nga mao, ang matag bili.

Ang history syncer nagkuha og mga value gikan sa HistoryCache ug gisusi ang Configuration para sa presensya sa mga trigger para sa mga kalkulasyon. Kung anaa sila, kini nagkalkula.

Ang history syncer nagmugna og usa ka panghitabo, pag-uswag sa paghimo og mga alerto kung gikinahanglan pinaagi sa configuration, ug mga rekord. Kung adunay mga hinungdan alang sa sunod nga pagproseso, nan kini nagtipig niini nga kantidad sa ValueCache aron dili ma-access ang lamesa sa kasaysayan. Mao kini ang paagi nga ang ValueCache napuno sa datos nga gikinahanglan aron makalkulo ang mga trigger ug kalkulado nga mga elemento.

Ang history syncer nagsulat sa tanang datos sa database, ug kini nagsulat sa disk. Ang proseso sa pagproseso natapos dinhi.

Pag-cache sa database

Sa kilid sa database adunay lainlaing mga cache kung gusto nimo tan-awon ang mga graph o mga taho sa mga panghitabo:

• Innodb_buffer_pool sa bahin sa MySQL;
• shared_buffers sa bahin sa PostgreSQL;
• effective_cache_size sa kilid sa Oracle;
• shared_pool sa DB2 nga bahin.

Adunay daghang uban pang mga cache, apan kini ang nag-una alang sa tanan nga mga database. Gitugotan ka nila sa pagtipig sa datos sa RAM nga kanunay gikinahanglan alang sa mga pangutana. Sila adunay ilang kaugalingon nga mga teknolohiya alang niini.

Ang pasundayag sa database kritikal

Ang server sa Zabbix kanunay nga nagkolekta sa datos ug gisulat kini. Kung gi-restart, nagbasa usab kini gikan sa kasaysayan aron pun-on ang ValueCache. Gigamit ang mga script ug mga taho Zabbix API, nga gitukod sa usa ka Web interface. Ang Zabbix API nag-access sa database ug nagkuha sa gikinahanglan nga datos alang sa mga graph, report, lista sa panghitabo ug pinakabag-o nga mga isyu.

Para sa visualization - grafana. Kini usa ka popular nga solusyon sa among mga tiggamit. Mahimo kini nga direkta nga magpadala mga hangyo pinaagi sa Zabbix API ug sa database, ug maghimo usa ka piho nga kompetisyon alang sa pagdawat data. Busa, ang mas maayo ug mas maayo nga pag-tune sa database gikinahanglan aron sa pagpares sa paspas nga paghatod sa mga resulta ug pagsulay.

housekeeper

Ang ikatulo nga hagit sa pasundayag sa Zabbix mao ang paglimpyo sa kasaysayan gamit ang Housekeeper. Gisundan niini ang tanan nga mga setting - ang mga elemento sa datos nagpakita kung unsa ka dugay ang pagtipig sa mga dinamika sa mga pagbag-o (mga uso) sa mga adlaw.

Among kuwentahon ang TrendsCache sa langaw. Sa diha nga ang data moabut, kita aggregate niini alang sa usa ka oras ug irekord kini sa mga lamesa alang sa dynamics sa uso kausaban.

Gisugdan ug gitangtang sa housekeeper ang kasayuran gikan sa database gamit ang naandan nga "pagpili". Dili kini kanunay nga epektibo, ingon nga makita gikan sa mga graph sa pasundayag sa mga internal nga proseso.

Ang pula nga graph nagpakita nga ang History syncer kanunay nga busy. Ang orange nga graph sa ibabaw mao ang Housekeeper, nga kanunay nga nagdagan. Naghulat siya sa database nga mapapas ang tanan nga mga laray nga iyang gipiho.

Kanus-a nimo kinahanglan i-disable ang Housekeeper? Pananglitan, adunay usa ka "Item ID" ug kinahanglan nimo nga tangtangon ang katapusang 5 ka libo nga mga laray sa usa ka piho nga oras. Siyempre, kini mahitabo pinaagi sa index. Apan kasagaran ang dataset dako kaayo, ug ang database nagbasa gihapon gikan sa disk ug gibutang kini sa cache. Kanunay kini nga mahal kaayo nga operasyon alang sa database ug, depende sa gidak-on sa database, mahimong mosangpot sa mga problema sa performance.

Ang housekeeper dali nga ma-disable. Sa Web interface adunay usa ka setting sa "Administration general" alang sa Housekeeper. Gi-disable namon ang internal nga Housekeeping alang sa internal nga kasaysayan sa uso ug wala na kini nagdumala niini.

Gipalong ang housekeeper, gi-level out ang mga graph - unsa nga mga problema ang mahimo niini nga kaso ug unsa ang makatabang sa pagsulbad sa ikatulo nga hagit sa pasundayag?

Pagbahin - pagbahin o pagbahin

Kasagaran, ang partitioning gi-configure sa lahi nga paagi sa matag relational database nga akong gilista. Ang matag usa adunay kaugalingon nga teknolohiya, apan parehas sila sa kinatibuk-an. Ang paghimo sa usa ka bag-ong partisyon kanunay nga hinungdan sa pipila nga mga problema.

Kasagaran, ang mga partisyon gi-configure depende sa "setup" - ang kantidad sa datos nga gihimo sa usa ka adlaw. Ingon sa usa ka lagda, ang Partitioning gi-isyu sa usa ka adlaw, kini ang minimum. Alang sa mga uso sa usa ka bag-ong batch - 1 ka bulan.

Ang mga kantidad mahimong mausab kung ang "setup" dako kaayo. Kung ang usa ka gamay nga "setup" hangtod sa 5 nvps (bag-ong mga kantidad matag segundo), ang usa ka medium gikan sa 000 hangtod 5, unya ang usa ka dako nga labaw sa 000 nvps. Dagko ug dako kaayo kini nga mga instalasyon nga nanginahanglan og mabinantayon nga pag-configure sa database.

Sa dako kaayo nga mga instalasyon, ang usa ka yugto sa usa ka adlaw mahimong dili maayo. Nakita nako ang mga partisyon sa MySQL nga 40 GB o labaw pa kada adlaw. Kini usa ka dako kaayo nga kantidad sa datos nga mahimong hinungdan sa mga problema ug kinahanglan nga pagkunhod.

Unsa ang gihatag sa Partitioning?

Pagbahin sa mga lamesa. Kasagaran kini lahi nga mga file sa disk. Ang plano sa pangutana nagpili usa ka partisyon nga labi ka maayo. Kasagaran ang partitioning gigamit sa range - tinuod usab kini alang sa Zabbix. Gigamit namo ang "timestamp" didto - panahon sukad sa sinugdanan sa panahon. Kini mga ordinaryo nga mga numero alang kanamo. Gitakda nimo ang sinugdanan ug katapusan sa adlaw - kini usa ka partisyon.

Dali nga pagtangtang - DELETE. Usa ka file/subtable ang gipili, kay sa usa ka pagpili sa mga laray nga tangtangon.

Mahinungdanon nga nagpadali sa pagkuha sa datos SELECT - naggamit sa usa o daghang partisyon, kaysa sa tibuok lamesa. Kung nag-access ka sa datos nga duha ka adlaw ang edad, kini makuha gikan sa database nga mas paspas tungod kay kinahanglan nimo nga i-load ang usa ka file sa cache ug ibalik kini, dili usa ka dako nga lamesa.

Kasagaran daghang mga database ang gipadali usab INSERT - mga pagsal-ot sa lamesa sa bata.

TimescaleDB

Alang sa v 4.2, among gipunting ang among atensyon sa TimescaleDB. Kini usa ka extension alang sa PostgreSQL nga adunay lumad nga interface. Epektibo nga nagtrabaho ang extension sa datos sa serye sa oras, nga wala mawala ang mga benepisyo sa mga relational database. Ang TimescaleDB usab awtomatikong nagbahinbahin.

Ang TimescaleDB adunay usa ka konsepto hypertable (hypertable) nga imong gibuhat. Naglangkob kini mga tipak - mga partisyon. Ang mga tipak awtomatik nga gidumala sa hypertable nga mga tipik nga dili makaapekto sa ubang mga tipik. Ang matag tipak adunay kaugalingon nga gilay-on sa oras.

TimescaleDB batok sa PostgreSQL

Ang TimescaleDB epektibo kaayo. Ang mga tiggama sa extension nag-ingon nga sila naggamit sa usa ka mas husto nga algorithm sa pagproseso sa pangutana, ilabi na inserts . Samtang nagkadako ang gidak-on sa pagsal-ot sa dataset, ang algorithm nagpadayon sa kanunay nga pasundayag.

Human sa 200 ka milyon nga mga laray, ang PostgreSQL kasagaran magsugod sa pag-us-os pag-ayo ug mawad-an sa performance ngadto sa 0. Ang TimescaleDB nagtugot kanimo sa episyenteng pagsal-ot sa "mga pagsal-ot" alang sa bisan unsang gidaghanon sa datos.

Pag-instalar

Ang pag-instalar sa TimescaleDB sayon ​​​​ra alang sa bisan unsang pakete. SA dokumentasyon ang tanan gihulagway sa detalye - nagdepende kini sa opisyal nga mga pakete sa PostgreSQL. Ang TimescaleDB mahimo usab nga matukod ug ma-compile nga mano-mano.

Alang sa database sa Zabbix gi-aktibo ra namon ang extension:

echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix

Aktibo ka extension ug paghimo niini alang sa Zabbix database. Ang katapusang lakang mao ang paghimo og hypertable.

Pagbalhin sa mga talaan sa kasaysayan ngadto sa TimescaleDB

Adunay usa ka espesyal nga function alang niini create_hypertable:

SELECT create_hypertable(‘history’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_log’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_text’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_str’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
UPDATE config SET db_extension=’timescaledb’, hk_history_global=1, hk_trends_global=1

Ang function adunay tulo ka mga parameter. Una- lamesa sa database, diin kinahanglan nimo nga maghimo usa ka hypertable. Ikaduha - uma, sumala sa diin kinahanglan nimo nga buhaton chunk_time_interval - interval sa partition chunks nga gamiton. Sa akong kaso, ang interval usa ka adlaw - 86.

Ikatulo nga parametro - migrate_data. Kung imong gitakda true, unya ang tanan nga kasamtangang datos ibalhin ngadto sa nabuhat nang daan nga mga tipak. Gigamit nako kini sa akong kaugalingon migrate_data. Duna koy mga 1 TB, nga milungtad og kapin sa usa ka oras. Bisan sa pipila ka mga kaso, sa panahon sa pagsulay, akong gitangtang ang makasaysayan nga datos sa mga tipo sa karakter nga wala kinahanglana alang sa pagtipig, aron dili kini mabalhin.

Katapusan nga lakang - UPDATE: sa db_extension ibutang timescaledbaron ang database makasabut nga kini nga extension anaa. Gi-aktibo kini sa Zabbix ug husto nga gigamit ang syntax ug mga pangutana sa database - kadtong mga bahin nga gikinahanglan alang sa TimescaleDB.

Pag-configure sa hardware

Duha ka server ang akong gigamit. Una- VMware nga makina. Gamay ra kini: 20 Intel® Xeon® CPU E5-2630 v 4 @ 2.20GHz nga mga processor, 16 GB sa RAM ug usa ka 200 GB SSD.

Gi-install nako ang PostgreSQL 10.8 niini gamit ang Debian 10.8-1.pgdg90+1 OS ug xfs file system. Gi-configure nako ang tanan nga gamay aron magamit kini nga partikular nga database, kung unsa ang gamiton mismo ni Zabbix.

Sa parehas nga makina adunay usa ka server sa Zabbix, PostgreSQL ug load ahente. Ako adunay 50 ka aktibo nga ahente nga gigamit LoadableModulearon dali kaayo nga makamugna og lain-laing mga resulta: mga numero, mga kuwerdas. Gipuno nako ang database sa daghang datos.

Sa sinugdan ang configuration anaa 5 ka elemento data kada host. Hapit matag elemento adunay usa ka gatilyo aron mahimo kini nga susama sa tinuod nga mga instalasyon. Sa pipila ka mga kaso adunay labaw pa sa usa ka hinungdan. Alang sa usa ka network node adunay 3-000 ka trigger.

Interbal sa Pag-update sa Item sa Data − 4-7 segundo. Gi-regulate nako ang load mismo pinaagi sa paggamit dili lamang sa 50 ka ahente, apan nagdugang pa. Usab, gamit ang mga elemento sa datos, dinamikong akong gi-adjust ang load ug gipakunhod ang update interval ngadto sa 4 s.

PostgreSQL. 35 nvps

Ang akong una nga pagdagan sa kini nga hardware mao ang puro nga PostgreSQL - 35 ka libo nga kantidad matag segundo. Sama sa imong makita, ang pagsal-ot sa datos nagkinahanglan og mga tipik sa usa ka segundo - ang tanan maayo ug paspas. Ang bugtong butang mao nga ang usa ka 200 GB SSD disk mapuno dayon.

Kini usa ka sumbanan nga dashboard sa pasundayag sa server sa Zabbix.

Ang una nga asul nga graph mao ang gidaghanon sa mga kantidad matag segundo. Ang ikaduhang graph sa tuo mao ang pagkarga sa mga proseso sa pagtukod. Ang ikatulo mao ang pagkarga sa internal nga mga proseso sa pagtukod: history syncers ug Housekeeper, nga dugay nang nagdagan dinhi.

Ang ikaupat nga graph nagpakita sa paggamit sa HistoryCache. Kini usa ka matang sa buffer sa dili pa isulod sa database. Ang berde nga ikalima nga graph nagpakita sa paggamit sa ValueCache, nga mao, kung pila ang mga hit sa ValueCache alang sa mga nag-trigger - kini pila ka libo nga mga kantidad matag segundo.

PostgreSQL. 50 nvps

Dayon akong gidugangan ang load ngadto sa 50 ka libo nga kantidad kada segundo sa samang hardware.

Kung nag-load gikan sa Housekeeper, ang pagsulud sa 10 ka libo nga kantidad gikuha 2-3 segundos.

Ang housekeeper nagsugod na sa pagpanghilabot sa trabaho.

Ang ikatulo nga graph nagpakita nga, sa kinatibuk-an, ang load sa mga trappers ug history synchers anaa pa sa 60%. Sa ikaupat nga graph, ang HistoryCache nagsugod na sa pagpuno nga aktibo sa panahon sa operasyon sa Housekeeper. Kini mao ang 20% ​​puno, nga mao ang mahitungod sa 0,5 GB.

PostgreSQL. 80 nvps

Dayon akong gidugangan ang load ngadto sa 80 ka libo nga kantidad kada segundo. Kini mao ang gibana-bana nga 400 ka libo nga mga elemento sa datos ug 280 ka libo nga mga nag-trigger.

Ang gasto sa pagkarga sa katloan ka history synchers taas na kaayo.

Gidugangan usab nako ang lainlaing mga parameter: mga pag-sync sa kasaysayan, mga cache.

Sa akong hardware, ang loading sa history syncers misaka ngadto sa maximum. Ang HistoryCache dali nga napuno sa datos - ang datos alang sa pagproseso natipon sa buffer.

Sa tanan niini nga panahon akong naobserbahan kung giunsa ang processor, RAM ug uban pang mga parameter sa sistema gigamit, ug nakit-an nga ang paggamit sa disk anaa sa labing taas.

Nakab-ot nako ang paggamit maximum nga kapabilidad sa disk sa niini nga hardware ug sa niini nga virtual nga makina. Sa ingon nga kakusog, ang PostgreSQL nagsugod sa pag-flush sa datos nga aktibo, ug ang disk wala nay panahon sa pagsulat ug pagbasa.

Ikaduha nga server

Mikuha ko og laing server, nga aduna nay 48 ka mga processor ug 128 GB sa RAM. Gitun-an ko kini - gibutang kini sa 60 nga history syncer, ug nakab-ot ang madawat nga pasundayag.

Sa tinuud, kini na ang limitasyon sa pagka-produktibo kung diin kinahanglan buhaton ang usa ka butang.

TimescaleDB. 80 nvps

Ang akong panguna nga tahas mao ang pagsulay sa mga kapabilidad sa TimescaleDB batok sa load sa Zabbix. Ang 80 ka libo nga mga kantidad matag segundo daghan, ang kasubsob sa pagkolekta sa mga sukatan (gawas sa Yandex, siyempre) ug usa ka medyo dako nga "setup".

Adunay usa ka paglusot sa matag graph - kini mao ang tukma nga data migration. Pagkahuman sa mga kapakyasan sa server sa Zabbix, ang loading profile sa history syncer nausab pag-ayo - kini nahulog sa tulo ka beses.

Gitugotan ka sa TimescaleDB nga isulod ang datos hapit 3 ka beses nga mas paspas ug gamay ra ang paggamit sa HistoryCache.

Tungod niini, makadawat ka ug datos sa tukma nga panahon.

TimescaleDB. 120 nvps

Dayon akong gidugangan ang gidaghanon sa mga elemento sa datos ngadto sa 500 ka libo. Ang nag-unang tahas mao ang pagsulay sa mga kapabilidad sa TimescaleDB - Nakadawat ako og kalkulado nga kantidad nga 125 ka libo nga mga kantidad matag segundo.

Kini usa ka nagtrabaho nga "setup" nga mahimong molihok sa dugay nga panahon. Apan tungod kay ang akong disk 1,5 TB ra, gipuno nako kini sa pila ka adlaw.

Ang labing hinungdanon nga butang mao nga sa samang higayon ang bag-ong mga partisyon sa TimescaleDB gihimo.

Kini hingpit nga dili mamatikdan alang sa pasundayag. Kung ang mga partisyon gihimo sa MySQL, pananglitan, lahi ang tanan. Kasagaran kini mahitabo sa gabii tungod kay gibabagan niini ang kinatibuk-ang pagsulud, pagtrabaho sa mga lamesa ug mahimo’g makamugna ang pagkadaot sa serbisyo. Dili kini ang kaso sa TimescaleDB.

Isip usa ka pananglitan, ipakita nako ang usa ka graph gikan sa kadaghanan sa komunidad. Sa hulagway, ang TimescaleDB gipalihok, salamat nga ang load sa paggamit sa io.weight sa processor nahulog. Ang paggamit sa internal nga mga elemento sa proseso usab mikunhod. Dugang pa, kini usa ka ordinaryo nga virtual machine sa ordinaryo nga mga pancake disk, dili usa ka SSD.

kaplag

Ang TimescaleDB usa ka maayong solusyon alang sa gamay nga "setup", nga makaapekto sa performance sa disk. Magtugot kini kanimo nga magpadayon sa pagtrabaho og maayo hangtod ang database mabalhin sa hardware sa labing madali nga panahon.

Ang TimescaleDB dali nga ma-configure, naghatag usa ka pagpauswag sa pasundayag, maayo nga nagtrabaho sa Zabbix ug adunay mga bentaha sa PostgreSQL.

Kung mogamit ka sa PostgreSQL ug wala magplano nga usbon kini, girekomenda ko gamita ang PostgreSQL sa extension sa TimescaleDB inubanan sa Zabbix. Kini nga solusyon epektibo nga nagtrabaho hangtod sa usa ka medium nga "setup".

Kung muingon ta nga "high performance" atong gipasabot Taas nga Load++. Dili ka magdugay nga maghulat aron mahibal-an ang bahin sa mga teknolohiya ug mga gawi nga makapaarang sa mga serbisyo sa pagserbisyo sa milyon-milyon nga mga tiggamit. Listahan mga taho para sa November 7 ug 8 gicompile na namo, pero diri mga panagkita daghan pa ang masugyot.

Mag-subscribe sa among newsletter и telegram, diin among gipadayag ang mga bahin sa umaabot nga komperensya, ug mahibal-an kung giunsa kini makuha ang labing kaayo.

Source: www.habr.com