Atong tan-awon kung giunsa ang Zabbix nagtrabaho kauban ang database sa TimescaleDB ingon backend. Ipakita namon kanimo kung giunsa pagsugod gikan sa wala ug kung giunsa ang paglalin gikan sa PostgreSQL. Maghatag usab kami og mga comparative performance nga mga pagsulay sa duha ka mga configuration.
HighLoad++ Siberia 2019. Tomsk Hall. Hunyo 24, 16:00. Theses ug . Ang sunod nga HighLoad++ nga komperensya ipahigayon sa Abril 6 ug 7, 2020 sa St. Petersburg. Mga detalye ug mga tiket .
Andrey Gushchin (pagkahuman niini - AG): – Usa ko ka ZABBIX technical support engineer (gitawag dinhi nga “Zabbix”), usa ka trainer. Nagtrabaho ako sa teknikal nga suporta sa sobra sa 6 ka tuig ug adunay direktang kasinatian sa pasundayag. Karon maghisgot ako bahin sa pasundayag nga mahatag sa TimescaleDB kung itandi sa regular nga PostgreSQL 10. Usab, pipila ka pasiuna nga bahin kung giunsa kini molihok sa kinatibuk-an.
Panguna nga mga hagit sa pagka-produktibo: gikan sa pagkolekta sa datos hangtod sa paglimpyo sa datos
Sa pagsugod, adunay piho nga mga hagit sa pasundayag nga giatubang sa matag sistema sa pag-monitor. Ang una nga hagit sa pagka-produktibo mao ang pagkolekta ug pagproseso sa datos nga dali.
Ang usa ka maayo nga sistema sa pag-monitor kinahanglan nga dali, tukma sa panahon nga makadawat sa tanan nga datos, iproseso kini sumala sa mga ekspresyon sa pag-trigger, nga mao, iproseso kini sumala sa pipila nga mga pamatasan (kini lahi sa lainlaing mga sistema) ug i-save kini sa usa ka database aron magamit kini nga datos sa sa umaabot.
Ang ikaduha nga hagit sa pasundayag mao ang pagtipig sa kasaysayan. Pagtipig kanunay sa usa ka database ug adunay dali ug dali nga pag-access sa kini nga mga sukatan nga nakolekta sa usa ka yugto sa panahon. Ang labing hinungdanon nga butang mao nga kini nga datos sayon nga makuha, gamiton kini sa mga taho, mga graph, mga pag-trigger, sa pipila nga mga kantidad sa threshold, alang sa mga alerto, ug uban pa.
Ang ikatulo nga hagit sa pasundayag mao ang paglimpyo sa kasaysayan, sa ato pa, kung moabot ka sa punto nga dili na nimo kinahanglan nga tipigan ang bisan unsang detalyado nga sukatan nga nakolekta sa 5 ka tuig (bisan mga bulan o duha ka bulan). Ang ubang mga node sa network gitangtang, o ang uban nga mga host, ang mga sukdanan dili na kinahanglan tungod kay kini karaan na ug wala na makolekta. Kining tanan kinahanglang limpyohan aron dili modako ang imong database. Sa kinatibuk-an, ang paglimpyo sa kasaysayan kasagaran usa ka seryoso nga pagsulay alang sa pagtipig - kini kasagaran adunay kusog kaayo nga epekto sa performance.
Giunsa pagsulbad ang mga problema sa caching?
Espesipikong hisgutan ko karon ang bahin sa Zabbix. Sa Zabbix, ang una ug ikaduha nga tawag masulbad gamit ang caching.
Pagkolekta ug pagproseso sa datos - Gigamit namo ang RAM aron tipigan kining tanan nga datos. Kini nga mga datos pagahisgutan karon sa mas detalyado.
Usab sa database nga bahin adunay pipila ka caching alang sa mga nag-unang mga pagpili - alang sa mga graph ug uban pang mga butang.
Pag-cache sa kilid sa Zabbix server mismo: naa mi ConfigurationCache, ValueCache, HistoryCache, TrendsCache. Unsa ni?
Ang ConfigurationCache mao ang nag-unang cache diin among gitipigan ang metrics, hosts, data items, triggers; ang tanan nga imong gikinahanglan sa pagproseso sa preprocessing, pagkolekta data, gikan sa nga panon sa pagkolekta, uban sa unsa nga frequency. Tanan kini gitipigan sa ConfigurationCache aron dili moadto sa database ug maghimo dili kinahanglan nga mga pangutana. Pagkahuman sa pagsugod sa server, among gi-update kini nga cache (himoa kini) ug gi-update kini matag karon ug unya (depende sa mga setting sa pag-configure).
Pag-cache sa Zabbix. Pagkolekta sa datos
Dinhi ang diagram dako kaayo:
Ang mga nag-una sa laraw mao kini nga mga kolektor:
Kini ang mga proseso sa asembliya mismo, lainlaing mga "poller" nga responsable sa lainlaing mga klase sa asembliya. Gikolekta nila ang datos pinaagi sa icmp, ipmi, ug lainlaing mga protocol ug gibalhin kini tanan sa preprocessing.
PreProcessing HistoryCache
Usab, kung nakalkulo namo ang mga elemento sa datos (kadtong pamilyar sa Zabbix nahibal-an), sa ato pa, kalkulado, mga elemento sa aggregation data, gikuha namo kini direkta gikan sa ValueCache. Isulti ko kanimo kung giunsa kini napuno sa ulahi. Ang tanan niini nga mga kolektor naggamit sa ConfigurationCache aron makadawat sa ilang mga trabaho ug dayon ipasa kini sa preprocessing.
Gigamit usab sa preprocessing ang ConfigurationCache aron makuha ang mga lakang sa preprocessing ug iproseso kini nga datos sa lainlaing mga paagi. Sugod sa bersyon 4.2, gibalhin namo kini sa usa ka proxy. Kini sayon kaayo, tungod kay ang preprocessing mismo usa ka lisud nga operasyon. Ug kung ikaw adunay usa ka dako kaayo nga Zabbix, nga adunay daghang gidaghanon sa mga elemento sa datos ug usa ka taas nga frequency sa pagkolekta, nan kini labi nga nagpasimple sa trabaho.
Tungod niini, human namo maproseso kini nga datos sa usa ka paagi gamit ang preprocessing, among gitipigan kini sa HistoryCache aron maproseso pa kini. Kini nagtapos sa pagkolekta sa datos. Nagpadayon kami sa panguna nga proseso.
Buhat sa history syncr
Ang nag-unang proseso sa Zabbix (tungod kay kini usa ka monolithic nga arkitektura) mao ang History syncer. Kini ang nag-unang proseso nga espesipikong naghisgot sa atomic nga pagproseso sa matag elemento sa datos, nga mao, matag bili:
- ang bili moabut (kini gikuha gikan sa HistoryCache);
- mga pagsusi sa Configuration syncer: kung adunay bisan unsang mga hinungdan sa pagkalkula - kalkulado kini;
kung adunay - nagmugna og mga panghitabo, nagmugna og escalation aron makahimo og alerto, kung gikinahanglan sumala sa configuration; - mga rekord nga nag-aghat alang sa sunod nga pagproseso, pagtipon; kung mag-aggregate ka sa katapusang oras ug uban pa, kini nga kantidad mahinumduman sa ValueCache aron dili moadto sa talaan sa kasaysayan; Sa ingon, ang ValueCache napuno sa gikinahanglan nga datos nga gikinahanglan aron makalkulo ang mga trigger, kalkulado nga mga elemento, ug uban pa;
- unya ang History syncer nagsulat sa tanang datos sa database;
- gisulat sila sa database sa disk - dinhi natapos ang proseso sa pagproseso.
Database. Pag-cache
Sa bahin sa database, kung gusto nimo tan-awon ang mga graph o pipila nga mga taho sa mga panghitabo, adunay lainlaing mga cache. Apan niini nga taho dili ko maghisgot mahitungod kanila.
Alang sa MySQL adunay Innodb_buffer_pool, ug usa ka hugpong sa lainlaing mga cache nga mahimo usab nga ma-configure.
Apan kini mao ang mga nag-unang mga:
- shared_buffers;
- epektibo nga_cache_size;
- shared_pool.
Alang sa tanan nga mga database, giingon nako nga adunay pipila nga mga cache nga nagtugot kanimo sa pagtipig sa RAM sa mga datos nga kanunay nga gikinahanglan alang sa mga pangutana. Sila adunay ilang kaugalingon nga mga teknolohiya alang niini.
Mahitungod sa Pagganap sa Database
Tungod niini, adunay usa ka kompetisyon nga palibot, nga mao, ang server sa Zabbix nagkolekta sa datos ug nagrekord niini. Kung gi-restart, nagbasa usab kini gikan sa kasaysayan aron pun-on ang ValueCache ug uban pa. Dinhi mahimo kang adunay mga script ug mga taho nga naggamit sa Zabbix API, nga gitukod sa usa ka web interface. Ang Zabbix API misulod sa database ug nakadawat sa gikinahanglan nga datos aron makakuha og mga graph, mga taho, o usa ka matang sa listahan sa mga panghitabo, bag-ong mga problema.
Usa usab ka sikat nga solusyon sa visualization mao ang Grafana, nga gigamit sa among mga tiggamit. Makahimo sa direkta nga pag-log in pareho pinaagi sa Zabbix API ug pinaagi sa database. Naghimo usab kini og usa ka piho nga kompetisyon alang sa pagkuha sa datos: ang usa ka mas maayo, mas maayo nga pag-tune sa database gikinahanglan aron masunod ang paspas nga paghatod sa mga resulta ug pagsulay.
Paglimpyo sa kasaysayan. Si Zabbix adunay Housekeeper
Ang ikatulo nga tawag nga gigamit sa Zabbix mao ang paglimpyo sa kasaysayan gamit ang Housekeeper. Gisunod sa Housekeeper ang tanan nga mga setting, nga mao, ang among mga elemento sa datos nagpakita kung unsa ka dugay ang pagtipig (sa mga adlaw), kung unsa kadugay ang pagtipig sa mga uso, ug ang dinamika sa mga pagbag-o.
Wala ko maghisgot bahin sa TrendCache, nga among kalkulado sa langaw: ang data moabot, among gi-aggregate kini sulod sa usa ka oras (kadaghanan kini mga numero sa kataposang oras), ang kantidad maoy aberids/minimum ug among girekord kini kausa sa usa ka oras sa talaan sa dynamics sa mga kausaban (“Trends”) . Ang "Housekeeper" nagsugod ug nagtangtang sa datos gikan sa database gamit ang regular nga mga pagpili, nga dili kanunay epektibo.
Unsaon pagsabot nga kini dili epektibo? Imong makita ang mosunod nga hulagway sa performance graphs sa internal nga mga proseso:
Ang imong History syncer kanunay nga busy (pula nga graph). Ug ang "pula" nga graph nga naa sa ibabaw. Kini usa ka "Housekeeper" nga nagsugod ug naghulat sa database nga mapapas ang tanan nga mga linya nga gitakda niini.
Atong kuhaon ang pipila ka Item ID: kinahanglan nimong papason ang katapusang 5 ka libo; siyempre, pinaagi sa mga indeks. Apan kasagaran ang dataset dako kaayo - ang database nagbasa gihapon niini gikan sa disk ug gibutang kini sa cache, ug kini usa ka mahal kaayo nga operasyon alang sa database. Depende sa gidak-on niini, kini mahimong mosangpot sa pipila ka mga problema sa performance.
Mahimo nimong ma-disable ang Housekeeper sa yano nga paagi - kami adunay pamilyar nga web interface. Ang mga setting sa Administration general (setting para sa "Housekeeper") gi-disable namo ang internal housekeeping alang sa internal nga kasaysayan ug mga uso. Tungod niini, ang Housekeeper wala na magkontrol niini:
Unsay sunod nimong buhaton? Imong gipalong, ang imong mga graph mi-level out na... Unsa pa nga mga problema ang mahimong motumaw niini nga kaso? Unsay makatabang?
Pagbahin (sectioning)
Kasagaran kini gi-configure sa lahi nga paagi sa matag relational database nga akong gilista. Ang MySQL adunay kaugalingon nga teknolohiya. Apan sa kinatibuk-an sila parehas kaayo kung bahin sa PostgreSQL 10 ug MySQL. Siyempre, adunay daghang mga internal nga kalainan kung giunsa kini tanan gipatuman ug kung giunsa ang tanan makaapekto sa pasundayag. Apan sa kinatibuk-an, ang paghimo sa usa ka bag-ong partisyon kanunay nga nagdala sa pipila nga mga problema.
Depende sa imong setup (unsa kadaghan nga datos ang imong gihimo sa usa ka adlaw), kasagaran nila nga gitakda ang minimum - kini 1 ka adlaw / batch, ug alang sa "mga uso", dinamika sa mga pagbag-o - 1 ka bulan / bag-ong batch. Mahimong mabag-o kini kung adunay ka dako kaayo nga setup.
Isulti dayon ang bahin sa gidak-on sa pag-setup: hangtod sa 5 ka libo nga bag-ong mga kantidad matag segundo (gitawag nga nvps) - kini isipon nga gamay nga "setup". Average - gikan sa 5 hangtod 25 ka libo nga kantidad matag segundo. Ang tanan nga naa sa taas dako na ug dako kaayo nga mga instalasyon nga nanginahanglan og maayo nga pag-configure sa database.
Sa dako kaayo nga mga instalasyon, ang 1 ka adlaw mahimong dili maayo. Ako personal nga nakakita sa mga partisyon sa MySQL nga 40 gigabytes kada adlaw (ug mahimong daghan pa). Kini usa ka dako kaayo nga gidaghanon sa datos, nga mahimong mosangpot sa pipila ka mga problema. Kinahanglang maminusan.
Nganong kinahanglan nimo ang partitioning?
Ang gihatag sa Partitioning, sa akong hunahuna nahibal-an sa tanan, mao ang pagbahin sa lamesa. Kasagaran kini lahi nga mga file sa mga hangyo sa disk ug span. Gipili niini ang usa ka partisyon nga mas maayo kung kini bahin sa normal nga partisyon.
Alang sa Zabbix, ilabi na, gigamit kini sa range, sa range, nga mao, naggamit kami og timestamp (usa ka regular nga numero, oras sukad sa pagsugod sa panahon). Gitakda nimo ang pagsugod sa adlaw/katapusan sa adlaw, ug kini ang partisyon. Tungod niini, kung mangayo ka sa datos nga duha ka adlaw ang edad, ang tanan makuha gikan sa database nga mas paspas, tungod kay kinahanglan nimo nga i-load ang usa ka file sa cache ug ibalik kini (kaysa usa ka dako nga lamesa).
Daghang mga database usab nagpadali sa pagsal-ot (pagsulud sa usa ka lamesa sa bata). Nagsulti ako nga abstract sa pagkakaron, apan posible usab kini. Kasagaran makatabang ang partitoning.
Elasticsearch alang sa NoSQL
Bag-ohay lang, sa 3.4, nagpatuman kami usa ka solusyon sa NoSQL. Gidugang ang abilidad sa pagsulat sa Elasticsearch. Mahimo nimong isulat ang pipila ka mga tipo: imong pilion - magsulat sa mga numero o pipila ka mga timailhan; kami adunay string nga teksto, mahimo nimong isulat ang mga troso sa Elasticsearch... Tungod niini, ang web interface maka-access usab sa Elasticsearch. Maayo kini sa pipila ka mga kaso, apan sa pagkakaron kini magamit.
TimescaleDB. Mga hypertable
Alang sa 4.4.2 among gihatagan ug pagtagad ang usa ka butang sama sa TimescaleDB. Unsa ni? Kini usa ka extension alang sa PostgreSQL, nga mao, kini adunay lumad nga PostgreSQL interface. Dugang pa, kini nga extension nagtugot kanimo sa pagtrabaho nga mas episyente sa timeseries data ug adunay awtomatik nga partitioning. Unsa ang hitsura niini:
Kini usa ka hypertable - adunay ingon nga konsepto sa Timescale. Kini usa ka hypertable nga imong gihimo, ug kini adunay mga tipik. Ang mga tipak mga partisyon, kini mga lamesa sa bata, kung wala ako masayop. Epektibo gyud.
TimescaleDB ug PostgreSQL
Sama sa gipasalig sa mga tiggama sa TimescaleDB, naggamit sila og mas husto nga algorithm alang sa pagproseso sa mga pangutana, ilabi na ang mga pagsal-ot, nga nagtugot kanila nga adunay gibana-bana nga makanunayon nga pasundayag uban ang nagkadako nga gidak-on sa insert sa dataset. Kana mao, pagkahuman sa 200 milyon nga mga laray sa Postgres, ang naandan nga usa nagsugod sa pag-us-os pag-ayo ug nawala ang pasundayag sa literal sa zero, samtang gitugotan ka sa Timescale nga isulud ang mga pagsal-ot nga labing kaepektibo sa bisan unsang kantidad sa datos.
Unsaon pag-instalar sa TimescaleDB? Yano ra!
Anaa kini sa dokumentasyon, gihulagway kini - mahimo nimo kini i-install gikan sa mga pakete alang sa bisan unsang ... Nagdepende kini sa opisyal nga mga pakete sa Postgres. Mahimong i-compile nga mano-mano. Nahitabo nga kinahanglan kong mag-compile para sa database.
Sa Zabbix gi-aktibo ra namon ang Extention. Nagtuo ko nga kadtong migamit ug Extention sa Postgres... I-activate mo lang ang Extention, mugnaa kini para sa Zabbix database nga imong gigamit.
Ug ang katapusang lakang ...
TimescaleDB. Paglalin sa mga talaan sa kasaysayan
Kinahanglan ka nga maghimo usa ka hypertable. Adunay usa ka espesyal nga function alang niini - Paghimo hypertable. Niini, ang una nga parameter mao ang lamesa nga gikinahanglan sa kini nga database (nga kinahanglan nimo maghimo usa ka hypertable).
Ang field sa paghimo, ug chunk_time_interval (kini ang interval sa mga chunks (mga partisyon nga kinahanglan gamiton). 86 kay usa ka adlaw.
Parameter sa Migrate_data: Kung imong i-insert sa true, ibalhin niini ang tanang kasamtangang data ngadto sa mga tipik nga nahimo nang daan.
Gigamit nako ang migrate_data sa akong kaugalingon - nagkinahanglag patas nga oras, depende kung unsa kadako ang imong database. Naa koy kapin sa usa ka terabyte - niabot ug kapin sa usa ka oras ang paghimo. Sa pipila ka mga kaso, sa panahon sa pagsulay, akong gitangtang ang makasaysayan nga datos alang sa teksto (history_text) ug string (history_str) aron dili kini mabalhin - dili gyud sila interesado kanako.
Ug gihimo namo ang katapusang update sa among db_extention: among gi-install ang timescaledb aron ang database ug, ilabi na, ang among Zabbix nakasabut nga adunay db_extention. Gi-activate niya kini ug gigamit ang husto nga syntax ug mga pangutana sa database, gamit ang mga "features" nga gikinahanglan alang sa TimescaleDB.
Pag-configure sa server
Duha ka server ang akong gigamit. Ang una nga server usa ka gamay nga virtual machine, 20 nga mga processor, 16 gigabytes nga RAM. Gi-configure nako ang Postgres 10.8 niini:
Ang operating system kay Debian, ang file system kay xfs. Naghimo ako og gamay nga mga setting aron magamit kining partikular nga database, minus kung unsa ang gamiton mismo ni Zabbix. Sa parehas nga makina adunay usa ka server sa Zabbix, PostgreSQL ug mga ahente sa pagkarga.
Gigamit nako ang 50 ka aktibo nga ahente nga naggamit sa LoadableModule aron dali nga makamugna ang lainlaing mga resulta. Sila ang nagmugna sa mga kuwerdas, numero, ug uban pa. Gipuno nako ang database sa daghang datos. Sa sinugdan, ang pag-configure adunay 5 ka libo nga mga elemento sa datos matag host, ug gibana-bana nga ang matag elemento sa datos adunay sulud - aron kini usa ka tinuud nga pag-setup. Usahay kinahanglan nimo ang labaw sa usa ka gatilyo aron magamit.
Gi-regulate nako ang agwat sa pag-update ug ang load mismo pinaagi sa dili lamang paggamit sa 50 nga mga ahente (pagdugang dugang), apan gigamit usab ang mga dinamikong elemento sa datos ug pagkunhod sa agwat sa pag-update sa 4 segundos.
Pagsulay sa performance. PostgreSQL: 36 ka libo nga NVP
Ang una nga paglansad, ang una nga pag-setup nga akong naa sa puro nga PostreSQL 10 sa kini nga hardware (35 ka libo nga kantidad matag segundo). Sa kinatibuk-an, ingon sa imong makita sa screen, ang pagsal-ot sa datos nagkinahanglan og mga tipik sa usa ka segundo - ang tanan maayo ug paspas, SSD drive (200 gigabytes). Ang bugtong butang mao nga ang 20 GB dali nga napuno.
Adunay daghang ingon nga mga graph sa umaabot. Kini usa ka sumbanan nga dashboard sa pasundayag sa server sa Zabbix.
Ang una nga graph mao ang gidaghanon sa mga kantidad matag segundo (asul, ibabaw sa wala), 35 ka libo nga mga kantidad sa kini nga kaso. Kini (ibabaw nga sentro) mao ang pagkarga sa mga proseso sa pagtukod, ug kini (ibabaw sa tuo) mao ang pagkarga sa mga internal nga proseso: mga history syncers ug housekeeper, nga dinhi (ubos nga sentro) dugay na nga nagdagan.
Kini nga graph (ubos nga sentro) nagpakita sa paggamit sa ValueCache - pila ka mga hit sa ValueCache alang sa mga nag-trigger (pila ka libo nga mga kantidad matag segundo). Ang laing importante nga graph mao ang ikaupat (sa wala sa ubos), nga nagpakita sa paggamit sa HistoryCache, nga akong gihisgutan, nga usa ka buffer sa wala pa isulod sa database.
Pagsulay sa performance. PostgreSQL: 50 ka libo nga NVP
Sunod, gidugangan nako ang load sa 50 ka libo nga kantidad matag segundo sa parehas nga hardware. Kung gikarga sa Housekeeper, 10 ka libo nga mga kantidad ang natala sa 2-3 segundos nga adunay kalkulasyon. Unsa, sa pagkatinuod, ang gipakita sa mosunod nga screenshot:
Ang "Housekeeper" nagsugod na sa pagpanghilabot sa trabaho, apan sa kinatibuk-an, ang load sa history-sinker trappers anaa pa sa lebel sa 60% (ikatulo nga graph, ibabaw sa tuo). Ang HistoryCache nagsugod na sa pagpuno nga aktibo samtang ang Housekeeper nagdagan (sa wala sa ubos). Kini mga tunga sa gigabyte, 20% nga puno.
Pagsulay sa performance. PostgreSQL: 80 ka libo nga NVP
Unya gidugangan nako kini sa 80 ka libo nga kantidad matag segundo:
Kini gibana-bana nga 400 ka libo nga mga elemento sa datos, 280 ka libo nga nag-trigger. Ang insert, ingon sa imong makita, sa mga termino sa load sa mga sinkers sa kasaysayan (adunay 30 niini) taas na kaayo. Unya gidugangan nako ang lainlaing mga parameter: mga sinker sa kasaysayan, cache... Sa kini nga hardware, ang pagkarga sa mga sinker sa kasaysayan nagsugod sa pagtaas sa labing taas, hapit "sa estante" - sumala niana, ang HistoryCache miadto sa taas kaayo nga karga:
Niining panahona akong gibantayan ang tanan nga mga parameter sa sistema (kung giunsa gigamit ang processor, RAM) ug nahibal-an nga ang paggamit sa disk labing kataas - Nakab-ot nako ang labing kataas nga kapasidad sa kini nga disk sa kini nga hardware, sa kini nga virtual machine. Ang "Postgres" nagsugod sa paglabay sa datos nga aktibo sa ingon nga intensity, ug ang disk wala nay panahon sa pagsulat, pagbasa ...
Mikuha ko og laing server nga aduna nay 48 ka processor ug 128 gigabytes sa RAM:
Ako usab "gitun-an" kini - gi-install ang History syncer (60 ka piraso) ug nakab-ot ang madawat nga pasundayag. Sa tinuud, wala kami "sa estante," apan kini tingali ang limitasyon sa pagka-produktibo, diin kinahanglan na nga buhaton ang usa ka butang bahin niini.
Pagsulay sa performance. TimescaleDB: 80 ka libo nga NVP
Ang akong panguna nga buluhaton mao ang paggamit sa TimescaleDB. Ang matag graph nagpakita sa usa ka paglusot:
Kini nga mga kapakyasan mao ang tukma nga pagbalhin sa datos. Pagkahuman niana, sa server sa Zabbix, ang pag-load sa profile sa mga sinkers sa kasaysayan, ingon sa imong nakita, nabag-o pag-ayo. Gitugotan ka niini nga magsal-ot sa datos hapit 3 ka beses nga mas paspas ug dili kaayo magamit ang HistoryCache - sumala niana, makabaton ka mga datos nga maipadala sa oras. Pag-usab, ang 80 ka libo nga mga kantidad matag segundo medyo taas nga rate (siyempre, dili alang sa Yandex). Sa kinatibuk-an kini usa ka medyo dako nga setup, nga adunay usa ka server.
Pagsulay sa pasundayag sa PostgreSQL: 120 ka libo nga NVP
Sunod, gipataas nako ang kantidad sa gidaghanon sa mga elemento sa datos sa tunga sa milyon ug nakadawat usa ka kalkulado nga kantidad nga 125 ka libo matag segundo:
Ug nakuha nako kini nga mga graph:
Sa prinsipyo, kini usa ka setup sa pagtrabaho, mahimo kini nga molihok sa dugay nga panahon. Apan tungod kay ako adunay usa ra ka 1,5 terabyte nga disk, gigamit nako kini sa pila ka adlaw. Ang labing hinungdanon nga butang mao nga sa parehas nga oras ang mga bag-ong partisyon gihimo sa TimescaleDB, ug kini hingpit nga wala namatikdan alang sa pasundayag, nga dili masulti bahin sa MySQL.
Kasagaran, ang mga partisyon gihimo sa gabii, tungod kay kini sa kasagaran nagbabag sa pagsal-ot ug pagtrabaho sa mga lamesa ug mahimong mosangpot sa pagkadaot sa serbisyo. Sa kini nga kaso dili kini ang kahimtang! Ang nag-unang tahas mao ang pagsulay sa mga kapabilidad sa TimescaleDB. Ang resulta mao ang mosunod nga numero: 120 ka libo nga mga kantidad matag segundo.
Adunay usab mga pananglitan sa komunidad:
Gi-on usab sa tawo ang TimescaleDB ug ang load sa paggamit sa io.weight nahulog sa processor; ug ang paggamit sa internal nga mga elemento sa proseso mikunhod usab tungod sa paglakip sa TimescaleDB. Dugang pa, kini mga ordinaryo nga pancake disk, nga mao, usa ka ordinaryo nga virtual machine sa ordinaryong mga disk (dili SSDs)!
Alang sa pipila ka gagmay nga mga pag-setup nga limitado sa pasundayag sa disk, ang TimescaleDB, sa akong opinyon, usa ka maayo kaayo nga solusyon. Magtugot kini kanimo sa pagpadayon sa pagtrabaho sa dili pa mobalhin sa mas paspas nga hardware alang sa database.
Gidapit ko kamong tanan sa among mga panghitabo: Conference sa Moscow, Summit sa Riga. Gamita ang among mga channel - Telegram, forum, IRC. Kung naa kay pangutana, adto sa among desk, pwede namong hisgutan ang tanan.
Mga Pangutana sa Mamiminaw
Pangutana gikan sa mamiminaw (pagkahuman niini - A): - Kung ang TimescaleDB sayon ra kaayo nga i-configure, ug kini naghatag sa ingon nga pag-uswag sa performance, nan tingali kini kinahanglan nga gamiton isip usa ka pinakamaayo nga praktis alang sa pag-configure sa Zabbix uban sa Postgres? Ug aduna bay mga lit-ag ug mga disbentaha niini nga solusyon, o human sa tanan, kung nakahukom ko sa paghimo sa Zabbix alang sa akong kaugalingon, dali nakong makuha ang mga Postgres, i-install ang Timescale didto dayon, gamiton kini ug dili maghunahuna sa bisan unsang mga problema ?
AG: - Oo, isulti ko nga kini usa ka maayong rekomendasyon: gamita dayon ang Postgres sa extension sa TimescaleDB. Sa ako nang giingon, daghang maayo nga mga pagribyu, bisan pa sa kamatuoran nga kini nga "feature" eksperimento. Apan ang tinuud nga mga pagsulay nagpakita nga kini usa ka maayo nga solusyon (uban ang TimescaleDB) ug sa akong hunahuna kini molambo! Among gimonitor kung giunsa pag-uswag ang kini nga extension ug maghimo mga pagbag-o kung kinahanglan.
Bisan sa panahon sa pag-uswag, nagsalig kami sa usa sa ilang nailhan nga "mga bahin": posible nga magtrabaho uban ang mga tipik nga medyo lahi. Apan pagkahuman giputol nila kini sa sunod nga pagpagawas, ug kinahanglan namon nga hunongon ang pagsalig sa kini nga code. Girekomenda nako ang paggamit niini nga solusyon sa daghang mga pag-setup. Kung mogamit ka sa MySQL ... Alang sa kasagaran nga mga pag-setup, ang bisan unsang solusyon molihok nga maayo.
A: - Sa katapusang mga graph gikan sa komunidad, adunay usa ka graph nga adunay "Housekeeper":
Nagpadayon siya sa pagtrabaho. Unsa ang gibuhat sa Housekeeper sa TimescaleDB?
AG: - Karon dili ko makasulti nga sigurado - akong tan-awon ang code ug isulti kanimo sa mas detalyado. Gigamit niini ang mga pangutana sa TimescaleDB nga dili pagtangtang sa mga tipak, apan aron mahiusa kini. Dili pa ko andam sa pagtubag niining teknikal nga pangutana. Atong mahibal-an ang dugang sa stand karon o ugma.
A: – Duna koy susamang pangutana – bahin sa performance sa delete operation sa Timescale.
A (tubag gikan sa mamiminaw): - Kung imong tangtangon ang datos gikan sa usa ka lamesa, kung buhaton nimo kini pinaagi sa pagtangtang, nan kinahanglan nimo nga moagi sa lamesa - pagtangtang, limpyo, markahan ang tanan alang sa umaabot nga vacuum. Sa Timescale, tungod kay ikaw adunay mga tipik, mahimo nimong ihulog. Sa kasagaran nga pagsulti, isulti lang nimo ang file nga naa sa dagkong datos: "Delete!"
Ang timescale yano nga nakasabut nga ang ingon nga tipik wala na. Ug tungod kay gilakip kini sa tigplano sa pangutana, naggamit kini mga kaw-it aron makuha ang imong mga kondisyon sa pinili o uban pang mga operasyon ug nahibal-an dayon nga kini nga tipik wala na - "Dili na ako moadto didto!" (dili magamit ang datos). Mao ra na! Kana mao, ang usa ka pag-scan sa lamesa gipulihan sa usa ka binary file nga pagtangtang, busa kini paspas.
A: – Nahikap na namo ang hisgutanan sa dili-SQL. Sa akong nasabtan, ang Zabbix dili gyud kinahanglan nga usbon ang datos, ug kining tanan sama sa usa ka troso. Posible ba nga gamiton ang mga espesyal nga database nga dili makabag-o sa ilang datos, apan sa samang higayon makatipig, magtigum, ug mag-apod-apod nga mas paspas - Clickhouse, pananglitan, usa ka butang nga sama sa Kafka?.. Ang Kafka usa usab ka log! Posible ba nga i-integrate sila sa usa ka paagi?
AG: - Ang pagdiskarga mahimong mahimo. Kami adunay usa ka piho nga "feature" sukad sa bersyon 3.4: mahimo nimong isulat ang tanan nga makasaysayan nga mga file, mga panghitabo, tanan pa sa mga file; ug dayon ipadala kini sa bisan unsang lain nga database gamit ang pipila nga handler. Sa tinuud, daghang mga tawo ang nagtrabaho ug nagsulat direkta sa database. Sa langaw, ang mga sinker sa kasaysayan isulat kining tanan ngadto sa mga file, i-rotate kini nga mga file, ug uban pa, ug mahimo nimo kining ibalhin sa Clickhouse. Dili ako makasulti bahin sa mga plano, apan tingali ang dugang nga suporta alang sa mga solusyon sa NoSQL (sama sa Clickhouse) magpadayon.
A: - Sa kinatibuk-an, kini nahimo nga hingpit nga makuha nimo ang mga postgres?
AG: – Siyempre, ang labing lisud nga bahin sa Zabbix mao ang makasaysayanon nga mga lamesa, nga naghimo sa labing daghang mga problema, ug mga panghitabo. Sa kini nga kaso, kung dili ka magtipig sa mga panghitabo sa dugay nga panahon ug magtipig sa kasaysayan nga adunay mga uso sa uban pang paspas nga pagtipig, nan sa kinatibuk-an, sa akong hunahuna, wala’y mga problema.
A: - Mahimo ba nimo mabanabana kung unsa ka paspas ang tanan kung molihok ka sa Clickhouse, pananglitan?
AG: - Wala pa nako kini gisulayan. Sa akong hunahuna nga labing menos ang parehas nga mga numero mahimong makab-ot nga yano, tungod kay ang Clickhouse adunay kaugalingon nga interface, apan dili ako makasulti nga sigurado. Mas maayo nga masulayan. Kini tanan nagdepende sa pag-configure: pila ang imong mga host, ug uban pa. Ang pagsal-ot usa ka butang, apan kinahanglan nimo usab nga makuha kini nga datos - Grafana o uban pa.
A: – Busa naghisgot kami bahin sa patas nga away, ug dili bahin sa dakong bentaha niining paspas nga mga database?
AG: – Sa akong hunahuna kon kita maghiusa, adunay mas tukma nga mga pagsulay.
A: – Diin napunta ang maayong daan nga RRD? Unsa ang nakapahimo kanimo sa pagbalhin sa mga database sa SQL? Sa sinugdan, ang tanang sukatan gikolekta sa RRD.
AG: - Ang Zabbix adunay RRD, tingali sa usa ka karaan nga bersyon. Adunay kanunay nga mga database sa SQL - usa ka klasiko nga pamaagi. Ang klasiko nga pamaagi mao ang MySQL, PostgreSQL (naglungtad na sila sa dugay nga panahon). Kami halos wala gayud mogamit sa usa ka komon nga interface alang sa SQL ug RRD databases.
Pipila ka mga ad 🙂
Salamat sa pagpabilin kanamo. Ganahan ka ba sa among mga artikulo? Gusto nga makakita og mas makapaikag nga sulod? Suportahi kami pinaagi sa pag-order o pagrekomenda sa mga higala, , usa ka talagsaon nga analogue sa mga entry-level server, nga giimbento namo alang kanimo: (anaa sa RAID1 ug RAID10, hangtod sa 24 ka mga core ug hangtod sa 40GB DDR4).
Dell R730xd 2 ka beses nga mas barato sa Equinix Tier IV data center sa Amsterdam? Dinhi lang sa Netherlands! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - gikan sa $99! Basaha ang mahitungod sa
Source: www.habr.com