Titingnan natin kung paano gumagana ang Zabbix sa database ng TimescaleDB bilang backend. Ipapakita namin sa iyo kung paano magsimula sa simula at kung paano mag-migrate mula sa PostgreSQL. Magbibigay din kami ng mga comparative performance test ng dalawang configuration.
HighLoad++ Siberia 2019. Tomsk Hall. Hunyo 24, 16:00. Mga tesis at . Ang susunod na HighLoad++ conference ay gaganapin sa Abril 6 at 7, 2020 sa St. Petersburg. Mga detalye at tiket .
Andrey Gushchin (pagkatapos nito - AG): – Ako ay isang ZABBIX technical support engineer (mula rito ay tinutukoy bilang “Zabbix”), isang trainer. Ako ay nagtatrabaho sa teknikal na suporta para sa higit sa 6 na taon at nagkaroon ng direktang karanasan sa pagganap. Ngayon ay magsasalita ako tungkol sa pagganap na maibibigay ng TimescaleDB kung ihahambing sa regular na PostgreSQL 10. Gayundin, ang ilang panimulang bahagi tungkol sa kung paano ito gumagana sa pangkalahatan.
Mga nangungunang hamon sa pagiging produktibo: mula sa pangongolekta ng data hanggang sa paglilinis ng data
Upang magsimula, may ilang mga hamon sa pagganap na kinakaharap ng bawat sistema ng pagsubaybay. Ang unang hamon sa pagiging produktibo ay mabilis na pagkolekta at pagproseso ng data.
Ang isang mahusay na sistema ng pagsubaybay ay dapat na mabilis, napapanahong makatanggap ng lahat ng data, iproseso ito ayon sa mga expression ng pag-trigger, iyon ay, iproseso ito ayon sa ilang pamantayan (iba ito sa iba't ibang mga system) at i-save ito sa isang database upang magamit ang data na ito sa kinabukasan.
Ang pangalawang hamon sa pagganap ay imbakan ng kasaysayan. Madalas na mag-imbak sa isang database at magkaroon ng mabilis at maginhawang pag-access sa mga sukatang ito na nakolekta sa loob ng isang yugto ng panahon. Ang pinakamahalagang bagay ay ang data na ito ay maginhawa upang makuha, gamitin ito sa mga ulat, graph, trigger, sa ilang mga halaga ng threshold, para sa mga alerto, atbp.
Ang pangatlong hamon sa pagganap ay ang pag-clear ng kasaysayan, iyon ay, kapag dumating ka sa punto na hindi mo na kailangang mag-imbak ng anumang mga detalyadong sukatan na nakolekta sa loob ng 5 taon (kahit na buwan o dalawang buwan). Ang ilang mga network node ay tinanggal, o ang ilang mga host, ang mga sukatan ay hindi na kailangan dahil ang mga ito ay luma na at hindi na nakolekta. Ang lahat ng ito ay kailangang linisin upang ang iyong database ay hindi lumaki nang masyadong malaki. Sa pangkalahatan, ang pag-clear sa history ay kadalasang isang seryosong pagsubok para sa storage - madalas itong may napakalakas na epekto sa performance.
Paano malutas ang mga problema sa pag-cache?
Ngayon ay partikular na magsasalita ako tungkol sa Zabbix. Sa Zabbix, ang una at pangalawang tawag ay nalutas gamit ang caching.
Pangongolekta at pagproseso ng data - Gumagamit kami ng RAM upang iimbak ang lahat ng data na ito. Ang mga datos na ito ay tatalakayin ngayon nang mas detalyado.
Gayundin sa gilid ng database mayroong ilang pag-cache para sa mga pangunahing seleksyon - para sa mga graph at iba pang mga bagay.
Pag-cache sa gilid ng server mismo ng Zabbix: mayroon kaming ConfigurationCache, ValueCache, HistoryCache, TrendsCache. Ano ito?
Ang ConfigurationCache ay ang pangunahing cache kung saan kami nag-iimbak ng mga sukatan, host, data item, trigger; lahat ng kailangan mo upang maproseso ang preprocessing, mangolekta ng data, mula sa kung aling mga host ang kolektahin, kung gaano kadalas. Ang lahat ng ito ay naka-imbak sa ConfigurationCache upang hindi pumunta sa database at lumikha ng mga hindi kinakailangang query. Pagkatapos magsimula ng server, ina-update namin ang cache na ito (ginagawa ito) at pana-panahong i-update ito (depende sa mga setting ng configuration).
Pag-cache sa Zabbix. Pagkolekta ng data
Narito ang diagram ay medyo malaki:
Ang mga pangunahing nasa scheme ay ang mga kolektor na ito:
Ito ang mga mismong proseso ng pagpupulong, iba't ibang "mga poller" na responsable para sa iba't ibang uri ng mga pagtitipon. Kinokolekta nila ang data sa pamamagitan ng icmp, ipmi, at iba't ibang protocol at inililipat ang lahat sa preprocessing.
PreProcessing HistoryCache
Gayundin, kung nakalkula namin ang mga elemento ng data (alam ng mga pamilyar sa Zabbix), iyon ay, kalkulado, mga elemento ng pagsasama-sama ng data, direktang kinukuha namin ang mga ito mula sa ValueCache. Sasabihin ko sa iyo kung paano ito napuno mamaya. Ang lahat ng mga kolektor na ito ay gumagamit ng ConfigurationCache upang matanggap ang kanilang mga trabaho at pagkatapos ay ipasa ang mga ito sa preprocessing.
Ginagamit din ng preprocessing ang ConfigurationCache upang makakuha ng mga hakbang sa preprocessing at iproseso ang data na ito sa iba't ibang paraan. Simula sa bersyon 4.2, inilipat namin ito sa isang proxy. Ito ay napaka-maginhawa, dahil ang preprocessing mismo ay isang medyo mahirap na operasyon. At kung mayroon kang isang napakalaking Zabbix, na may malaking bilang ng mga elemento ng data at isang mataas na dalas ng koleksyon, kung gayon ito ay lubos na nagpapadali sa gawain.
Alinsunod dito, pagkatapos naming maproseso ang data na ito sa ilang paraan gamit ang preprocessing, ise-save namin ito sa HistoryCache upang maproseso pa ito. Ito ang nagtatapos sa pagkolekta ng datos. Lumipat kami sa pangunahing proseso.
Trabaho ng history syncr
Ang pangunahing proseso sa Zabbix (dahil ito ay isang monolitikong arkitektura) ay ang History syncer. Ito ang pangunahing proseso na partikular na tumatalakay sa atomic processing ng bawat elemento ng data, ibig sabihin, bawat value:
- ang halaga ay dumating (ito ay kinukuha ito mula sa HistoryCache);
- mga pagsusuri sa Configuration syncer: kung mayroong anumang mga trigger para sa pagkalkula - kinakalkula ang mga ito;
kung mayroon - lumilikha ng mga kaganapan, lumilikha ng escalation upang lumikha ng isang alerto, kung kinakailangan ayon sa pagsasaayos; - nagtatala ng mga trigger para sa kasunod na pagproseso, pagsasama-sama; kung pinagsama-sama mo sa huling oras at iba pa, ang halagang ito ay naaalala ng ValueCache upang hindi mapunta sa talahanayan ng kasaysayan; Kaya, ang ValueCache ay puno ng kinakailangang data na kinakailangan upang makalkula ang mga trigger, kinakalkula na mga elemento, atbp.;
- pagkatapos History syncers writes lahat ng data sa database;
- isinusulat sila ng database sa disk - dito nagtatapos ang proseso ng pagproseso.
Database. Pag-cache
Sa panig ng database, kapag gusto mong tingnan ang mga graph o ilang ulat sa mga kaganapan, mayroong iba't ibang mga cache. Ngunit sa ulat na ito ay hindi ko sila pag-uusapan.
Para sa MySQL mayroong Innodb_buffer_pool, at isang grupo ng iba't ibang mga cache na maaari ding i-configure.
Ngunit ito ang mga pangunahing:
- shared_buffers;
- effective_cache_size;
- shared_pool.
Para sa lahat ng mga database, sinabi ko na may ilang mga cache na nagbibigay-daan sa iyo upang iimbak sa RAM ang data na madalas na kailangan para sa mga query. Mayroon silang sariling mga teknolohiya para dito.
Tungkol sa Pagganap ng Database
Alinsunod dito, mayroong isang mapagkumpitensyang kapaligiran, iyon ay, ang server ng Zabbix ay nangongolekta ng data at naitala ito. Kapag na-restart, nagbabasa rin ito mula sa kasaysayan upang punan ang ValueCache at iba pa. Dito maaari kang magkaroon ng mga script at ulat na gumagamit ng Zabbix API, na binuo sa isang web interface. Ang Zabbix API ay pumapasok sa database at tumatanggap ng kinakailangang data upang makakuha ng mga graph, ulat, o ilang uri ng listahan ng mga kaganapan, kamakailang mga problema.
Isa ring napakasikat na solusyon sa visualization ay ang Grafana, na ginagamit ng aming mga user. Magagawang direktang mag-log in kapwa sa pamamagitan ng Zabbix API at sa pamamagitan ng database. Lumilikha din ito ng isang tiyak na kumpetisyon para sa pagkuha ng data: ang isang mas pino, mas mahusay na pag-tune ng database ay kailangan upang makasunod sa mabilis na paghahatid ng mga resulta at pagsubok.
Pag-clear ng kasaysayan. May Housekeeper si Zabbix
Ang pangatlong tawag na ginagamit sa Zabbix ay ang pag-clear ng history gamit ang Housekeeper. Sinusunod ng Housekeeper ang lahat ng mga setting, iyon ay, ang aming mga elemento ng data ay nagpapahiwatig kung gaano katagal mag-iimbak (sa mga araw), gaano katagal mag-imbak ng mga trend, at ang dynamics ng mga pagbabago.
Hindi ko pinag-usapan ang TrendCache, na mabilis naming kinakalkula: dumarating ang data, pinagsama-sama namin ito sa loob ng isang oras (karamihan ay mga numero ito para sa huling oras), ang halaga ay average/minimum at itinatala namin ito isang beses sa isang oras sa talahanayan ng dynamics ng mga pagbabago (“Mga Uso”) . Ang "Housekeeper" ay nagsisimula at nagtatanggal ng data mula sa database gamit ang mga regular na pinili, na hindi palaging epektibo.
Paano maintindihan na ito ay hindi epektibo? Maaari mong makita ang sumusunod na larawan sa mga graph ng pagganap ng mga panloob na proseso:
Ang iyong History syncer ay palaging abala (pulang graph). At ang "pula" na graph na napupunta sa itaas. Ito ay isang "Housekeeper" na nagsisimula at naghihintay para sa database na tanggalin ang lahat ng mga row na tinukoy nito.
Kumuha tayo ng ilang Item ID: kailangan mong tanggalin ang huling 5 libo; siyempre, sa pamamagitan ng index. Ngunit kadalasan ang dataset ay medyo malaki - binabasa pa rin ito ng database mula sa disk at inilalagay ito sa cache, at ito ay isang napakamahal na operasyon para sa database. Depende sa laki nito, maaari itong humantong sa ilang mga problema sa pagganap.
Maaari mong i-disable ang Housekeeper sa simpleng paraan - mayroon kaming pamilyar na web interface. Mga Setting sa Pangkalahatang Administrasyon (mga setting para sa "Housekeeper") hindi namin pinapagana ang panloob na housekeeping para sa panloob na kasaysayan at mga uso. Alinsunod dito, hindi na ito kinokontrol ng Housekeeper:
Ano ang maaari mong gawin sa susunod? In-off mo ito, nag-level out na ang iyong mga graph... Ano pang mga problema ang maaaring lumitaw sa kasong ito? Ano ang makakatulong?
Paghati (sectioning)
Kadalasan ito ay naka-configure sa ibang paraan sa bawat relational database na aking inilista. Ang MySQL ay may sariling teknolohiya. Ngunit sa pangkalahatan ay halos magkapareho sila pagdating sa PostgreSQL 10 at MySQL. Siyempre, maraming panloob na pagkakaiba sa kung paano ipinatupad ang lahat at kung paano ito nakakaapekto sa pagganap. Ngunit sa pangkalahatan, ang paglikha ng isang bagong partisyon ay madalas na humahantong sa ilang mga problema.
Depende sa iyong setup (kung gaano karaming data ang gagawin mo sa isang araw), karaniwang itinatakda nila ang minimum - ito ay 1 araw / batch, at para sa "mga uso", dynamics ng mga pagbabago - 1 buwan / bagong batch. Maaaring magbago ito kung mayroon kang napakalaking setup.
Sabihin natin kaagad ang tungkol sa laki ng pag-setup: hanggang sa 5 libong mga bagong halaga bawat segundo (tinatawag na nvps) - ito ay ituturing na isang maliit na "setup". Average – mula 5 hanggang 25 libong halaga bawat segundo. Ang lahat ng nasa itaas ay malaki na at napakalaking installation na nangangailangan ng napakaingat na pagsasaayos ng database.
Sa napakalaking mga pag-install, maaaring hindi pinakamainam ang 1 araw. Personal kong nakita ang mga partisyon sa MySQL na 40 gigabytes bawat araw (at maaaring marami pa). Ito ay isang napakalaking halaga ng data, na maaaring humantong sa ilang mga problema. Kailangan itong bawasan.
Bakit kailangan mo ng partitioning?
Ang ibinibigay ng Partitioning, sa tingin ko ay alam ng lahat, ay ang table partitioning. Kadalasan ang mga ito ay hiwalay na mga file sa mga kahilingan sa disk at span. Pinipili nito ang isang partition nang mas mahusay kung ito ay bahagi ng normal na partitioning.
Para sa Zabbix, sa partikular, ito ay ginagamit ayon sa saklaw, ayon sa saklaw, iyon ay, gumagamit kami ng timestamp (isang regular na numero, oras mula noong simula ng panahon). Tinukoy mo ang simula ng araw/pagtatapos ng araw, at ito ang partition. Alinsunod dito, kung humihingi ka ng data na dalawang araw na ang edad, ang lahat ay nakuha mula sa database nang mas mabilis, dahil kailangan mo lamang na i-load ang isang file sa cache at ibalik ito (sa halip na isang malaking talahanayan).
Maraming mga database din ang nagpapabilis sa pagpasok (pagpasok sa isang talahanayan ng bata). Abstractly ang pagsasalita ko sa ngayon, ngunit posible rin ito. Madalas na nakakatulong ang partitoning.
Elasticsearch para sa NoSQL
Kamakailan, sa 3.4, nagpatupad kami ng isang solusyon sa NoSQL. Nagdagdag ng kakayahang sumulat sa Elasticsearch. Maaari kang magsulat ng ilang uri: pipiliin mo - magsulat ng mga numero o ilang mga palatandaan; mayroon kaming string text, maaari kang magsulat ng mga log sa Elasticsearch... Alinsunod dito, maa-access din ng web interface ang Elasticsearch. Ito ay mahusay na gumagana sa ilang mga kaso, ngunit sa sandaling ito ay magagamit.
TimescaleDB. Mga hypertable
Para sa 4.4.2 binigyan namin ng pansin ang isang bagay tulad ng TimescaleDB. Ano ito? Ito ay isang extension para sa PostgreSQL, iyon ay, mayroon itong katutubong interface ng PostgreSQL. Dagdag pa, binibigyang-daan ka ng extension na ito na gumana nang mas mahusay sa data ng timeseries at magkaroon ng awtomatikong paghati. Ano ang hitsura nito:
Ito ay hypertable - mayroong ganitong konsepto sa Timescale. Ito ay isang hypertable na iyong nilikha, at naglalaman ito ng mga chunks. Ang mga tipak ay mga partisyon, ito ay mga talahanayan ng bata, kung hindi ako nagkakamali. Effective talaga.
TimescaleDB at PostgreSQL
Tulad ng tiniyak ng mga tagagawa ng TimescaleDB, gumagamit sila ng mas tamang algorithm para sa pagproseso ng mga query, sa partikular na mga pagsingit, na nagbibigay-daan sa kanila na magkaroon ng humigit-kumulang pare-pareho ang pagganap na may tumataas na laki ng insert ng dataset. Iyon ay, pagkatapos ng 200 milyong mga row ng Postgres, ang karaniwan ay nagsisimulang lumubog nang husto at literal na nawawala ang pagganap sa zero, habang pinapayagan ka ng Timescale na magpasok ng mga pagsingit nang mahusay hangga't maaari sa anumang dami ng data.
Paano mag-install ng TimescaleDB? Ito ay simple!
Ito ay nasa dokumentasyon, ito ay inilarawan - maaari mong i-install ito mula sa mga pakete para sa anumang... Depende ito sa mga opisyal na pakete ng Postgres. Maaaring i-compile nang manu-mano. Nagkataon na kailangan kong mag-compile para sa database.
Sa Zabbix ay ina-activate lang namin ang Extention. Sa tingin ko ang mga gumamit ng Extention sa Postgres... I-activate mo lang ang Extention, gawin mo para sa Zabbix database na ginagamit mo.
At ang huling hakbang...
TimescaleDB. Paglipat ng mga talahanayan ng kasaysayan
Kailangan mong lumikha ng hypertable. Mayroong isang espesyal na function para dito - Lumikha ng hypertable. Sa loob nito, ang unang parameter ay ang talahanayan na kinakailangan sa database na ito (kung saan kailangan mong lumikha ng hypertable).
Ang field kung saan lilikha, at chunk_time_interval (ito ang pagitan ng mga chunks (mga partisyon na kailangang gamitin). 86 ay isang araw.
Parameter ng Migrate_data: Kung maglalagay ka sa true, ima-migrate nito ang lahat ng kasalukuyang data sa mga paunang ginawang chunks.
Gumamit ako ng migrate_data sa aking sarili - nangangailangan ito ng sapat na oras, depende sa kung gaano kalaki ang iyong database. Mayroon akong higit sa isang terabyte - umabot ng mahigit isang oras upang makalikha. Sa ilang mga kaso, sa panahon ng pagsubok, tinanggal ko ang makasaysayang data para sa teksto (history_text) at string (history_str) upang hindi mailipat ang mga ito - hindi talaga sila interesado sa akin.
At ginagawa namin ang huling pag-update sa aming db_extention: nag-install kami ng timescaledb upang ang database at, lalo na, naiintindihan ng aming Zabbix na mayroong db_extention. Ina-activate niya ito at ginagamit ang tamang syntax at mga query sa database, gamit ang mga "feature" na kailangan para sa TimescaleDB.
Configuration ng server
Dalawang server ang ginamit ko. Ang unang server ay isang medyo maliit na virtual machine, 20 processors, 16 gigabytes ng RAM. Na-configure ko ang Postgres 10.8 dito:
Ang operating system ay Debian, ang file system ay xfs. Gumawa ako ng kaunting mga setting upang magamit ang partikular na database na ito, minus kung ano mismo ang gagamitin ng Zabbix. Sa parehong makina ay mayroong isang server ng Zabbix, PostgreSQL at mga ahente ng pag-load.
Gumamit ako ng 50 aktibong ahente na gumagamit ng LoadableModule upang mabilis na makabuo ng iba't ibang resulta. Sila ang gumawa ng mga string, numero, at iba pa. Pinuno ko ang database ng maraming data. Sa una, ang configuration ay naglalaman ng 5 libong elemento ng data bawat host, at humigit-kumulang sa bawat elemento ng data ay naglalaman ng trigger - upang ito ay maging isang tunay na setup. Minsan kailangan mo pa ng higit sa isang trigger para magamit.
Kinokontrol ko ang agwat ng pag-update at ang pag-load mismo sa pamamagitan ng hindi lamang paggamit ng 50 ahente (pagdaragdag ng higit pa), ngunit gumagamit din ng mga dynamic na elemento ng data at pagbabawas ng agwat ng pag-update sa 4 na segundo.
Pagsubok sa pagganap. PostgreSQL: 36 libong NVP
Ang unang paglulunsad, ang unang setup na mayroon ako ay nasa purong PostreSQL 10 sa hardware na ito (35 thousand values per second). Sa pangkalahatan, tulad ng nakikita mo sa screen, ang pagpasok ng data ay tumatagal ng mga fraction ng isang segundo - lahat ay mabuti at mabilis, SSD drive (200 gigabytes). Ang tanging bagay ay ang 20 GB ay mabilis na mapupuno.
Magkakaroon ng napakaraming ganoong mga graph sa hinaharap. Ito ay isang karaniwang dashboard ng pagganap ng server ng Zabbix.
Ang unang graph ay ang bilang ng mga halaga bawat segundo (asul, kaliwang tuktok), 35 libong mga halaga sa kasong ito. Ito (gitna sa itaas) ay ang paglo-load ng mga proseso ng build, at ito (kanang tuktok) ay ang paglo-load ng mga internal na proseso: mga history syncers at housekeeper, na dito (bottom center) ay tumatakbo nang medyo matagal na.
Ipinapakita ng graph na ito (gitna sa ibaba) ang paggamit ng ValueCache - kung gaano karaming mga hit ng ValueCache para sa mga trigger (ilang libong halaga bawat segundo). Ang isa pang mahalagang graph ay ang pang-apat (kaliwa sa ibaba), na nagpapakita ng paggamit ng HistoryCache, na aking napag-usapan, na isang buffer bago ipasok sa database.
Pagsubok sa pagganap. PostgreSQL: 50 libong NVP
Susunod, dinagdagan ko ang pagkarga sa 50 libong halaga bawat segundo sa parehong hardware. Kapag na-load ng Housekeeper, 10 libong mga halaga ang naitala sa 2-3 segundo na may pagkalkula. Ano, sa katunayan, ang ipinapakita sa sumusunod na screenshot:
Ang "Housekeeper" ay nagsisimula nang makagambala sa trabaho, ngunit sa pangkalahatan, ang load sa history-sinker trappers ay nasa antas pa rin ng 60% (ikatlong graph, kanang itaas). Nagsisimula nang mapuno ang HistoryCache habang tumatakbo ang Housekeeper (kaliwa sa ibaba). Ito ay halos kalahating gigabyte, 20% na puno.
Pagsubok sa pagganap. PostgreSQL: 80 libong NVP
Pagkatapos ay dinagdagan ko ito sa 80 libong halaga bawat segundo:
Ito ay humigit-kumulang 400 libong mga elemento ng data, 280 libong mga nag-trigger. Ang insert, tulad ng nakikita mo, sa mga tuntunin ng pagkarga ng mga sinkers ng kasaysayan (mayroong 30 sa kanila) ay medyo mataas na. Pagkatapos ay nadagdagan ko ang iba't ibang mga parameter: mga sinker ng kasaysayan, cache... Sa hardware na ito, ang pag-load sa mga sinker ng kasaysayan ay nagsimulang tumaas hanggang sa maximum, halos "sa istante" - nang naaayon, ang HistoryCache ay pumasok sa napakataas na pag-load:
Sa lahat ng oras na ito ay sinusubaybayan ko ang lahat ng mga parameter ng system (kung paano ginagamit ang processor, RAM) at natuklasan na ang paggamit ng disk ay maximum - Nakamit ko ang maximum na kapasidad ng disk na ito sa hardware na ito, sa virtual machine na ito. Ang "Postgres" ay nagsimulang mag-dump ng data nang medyo aktibo sa ganoong intensity, at ang disk ay wala nang oras upang magsulat, magbasa...
Kumuha ako ng isa pang server na mayroon nang 48 processor at 128 gigabytes ng RAM:
"Na-tono" ko rin ito - na-install ang History syncer (60 piraso) at nakamit ang katanggap-tanggap na pagganap. Sa katunayan, hindi tayo "nasa istante," ngunit ito marahil ang limitasyon ng pagiging produktibo, kung saan kailangan nang gumawa ng isang bagay tungkol dito.
Pagsubok sa pagganap. TimescaleDB: 80 libong NVP
Ang aking pangunahing gawain ay ang paggamit ng TimescaleDB. Ang bawat graph ay nagpapakita ng pagbaba:
Ang mga pagkabigo na ito ay tiyak na paglilipat ng data. Pagkatapos nito, sa server ng Zabbix, ang pag-load ng profile ng mga sinker ng kasaysayan, tulad ng nakikita mo, ay nagbago nang malaki. Pinapayagan ka nitong magpasok ng data nang halos 3 beses nang mas mabilis at gumamit ng mas kaunting HistoryCache - nang naaayon, magkakaroon ka ng data na maihahatid sa oras. Muli, ang 80 libong halaga bawat segundo ay medyo mataas na rate (siyempre, hindi para sa Yandex). Sa pangkalahatan ito ay isang medyo malaking setup, na may isang server.
Pagsubok sa pagganap ng PostgreSQL: 120 libong NVP
Susunod, pinataas ko ang halaga ng bilang ng mga elemento ng data sa kalahating milyon at nakatanggap ng kinakalkula na halaga na 125 libo bawat segundo:
At nakuha ko ang mga graph na ito:
Sa prinsipyo, ito ay isang gumaganang pag-setup, maaari itong gumana nang mahabang panahon. Ngunit dahil mayroon lang akong 1,5 terabyte disk, nagamit ko ito sa loob ng ilang araw. Ang pinakamahalagang bagay ay na sa parehong oras ang mga bagong partisyon ay nilikha sa TimescaleDB, at ito ay ganap na hindi napapansin para sa pagganap, na hindi masasabi tungkol sa MySQL.
Karaniwan, ang mga partisyon ay ginagawa sa gabi, dahil sa pangkalahatan ay hinaharangan nito ang pagpasok at gumagana sa mga talahanayan at maaaring humantong sa pagkasira ng serbisyo. Sa kasong ito, hindi ito ang kaso! Ang pangunahing gawain ay upang subukan ang mga kakayahan ng TimescaleDB. Ang resulta ay ang sumusunod na figure: 120 thousand values per second.
Mayroon ding mga halimbawa sa komunidad:
In-on din ng tao ang TimescaleDB at ang pag-load sa paggamit ng io.weight ay bumaba sa processor; at ang paggamit ng mga panloob na elemento ng proseso ay nabawasan din dahil sa pagsasama ng TimescaleDB. Bukod dito, ito ay mga ordinaryong pancake disk, iyon ay, isang ordinaryong virtual machine sa mga ordinaryong disk (hindi SSD)!
Para sa ilang maliliit na pag-setup na nalilimitahan ng pagganap ng disk, ang TimescaleDB, sa palagay ko, ay isang napakahusay na solusyon. Papayagan ka nitong magpatuloy sa pagtatrabaho bago lumipat sa mas mabilis na hardware para sa database.
Inaanyayahan ko kayong lahat sa aming mga kaganapan: Conference sa Moscow, Summit sa Riga. Gamitin ang aming mga channel - Telegram, forum, IRC. Kung mayroon kang anumang mga katanungan, pumunta sa aming desk, maaari naming pag-usapan ang lahat.
Mga Tanong sa Madla
Tanong mula sa madla (simula dito - A): - Kung ang TimescaleDB ay napakadaling i-configure, at nagbibigay ito ng ganoong pagpapalakas ng pagganap, kung gayon marahil ito ay dapat gamitin bilang isang pinakamahusay na kasanayan para sa pag-configure ng Zabbix sa Postgres? At mayroon bang anumang mga pitfalls at disadvantages ng solusyon na ito, o pagkatapos ng lahat, kung nagpasya akong gumawa ng Zabbix para sa aking sarili, madali kong makuha ang Postgres, i-install ang Timescale doon kaagad, gamitin ito at huwag mag-isip tungkol sa anumang mga problema ?
AG: – Oo, sasabihin ko na ito ay isang magandang rekomendasyon: gamitin kaagad ang Postgres sa extension ng TimescaleDB. Tulad ng nasabi ko na, maraming magagandang pagsusuri, sa kabila ng katotohanan na ang "tampok" na ito ay pang-eksperimento. Ngunit ang aktwal na mga pagsubok ay nagpapakita na ito ay isang mahusay na solusyon (na may TimescaleDB) at sa tingin ko ito ay magbabago! Sinusubaybayan namin kung paano bubuo ang extension na ito at gagawa ng mga pagbabago kung kinakailangan.
Kahit na sa panahon ng pag-unlad, umasa kami sa isa sa kanilang kilalang "mga tampok": posible na magtrabaho sa mga chunks nang medyo naiiba. Ngunit pagkatapos ay pinutol nila ito sa susunod na paglabas, at kinailangan naming ihinto ang pag-asa sa code na ito. Inirerekumenda ko ang paggamit ng solusyon na ito sa maraming mga setup. Kung gumagamit ka ng MySQL... Para sa mga karaniwang setup, gumagana nang maayos ang anumang solusyon.
A: – Sa mga huling graph mula sa komunidad, mayroong isang graph na may "Kasambahay":
Nagpatuloy siya sa pagtatrabaho. Ano ang ginagawa ng Housekeeper sa TimescaleDB?
AG: – Ngayon hindi ko masasabing sigurado – Titingnan ko ang code at sasabihin sa iyo nang mas detalyado. Gumagamit ito ng mga query sa TimescaleDB upang hindi magtanggal ng mga chunks, ngunit upang kahit papaano ay pagsama-samahin ang mga ito. Hindi pa ako handang sagutin ang teknikal na tanong na ito. Malalaman natin ang higit pa sa stand ngayon o bukas.
A: – Mayroon akong katulad na tanong – tungkol sa pagganap ng operasyon ng pagtanggal sa Timescale.
A (sagot mula sa madla): – Kapag nagtanggal ka ng data mula sa isang talahanayan, kung gagawin mo ito sa pamamagitan ng pagtanggal, kailangan mong dumaan sa talahanayan - tanggalin, linisin, markahan ang lahat para sa hinaharap na vacuum. Sa Timescale, dahil mayroon kang mga chunks, maaari kang mag-drop. Sa madaling salita, sasabihin mo lang sa file na nasa malaking data: "Tanggalin!"
Nauunawaan lang ng Timescale na hindi na umiiral ang naturang tipak. At dahil isinama ito sa query planner, gumagamit ito ng mga hook para makuha ang iyong mga kundisyon sa piling o iba pang mga operasyon at agad na nauunawaan na ang chunk na ito ay wala na - "Hindi na ako pupunta doon!" (hindi magagamit ang data). Iyon lang! Iyon ay, ang isang table scan ay pinapalitan ng isang binary file na pagtanggal, kaya ito ay mabilis.
A: – Nahawakan na namin ang paksa ng non-SQL. Sa pagkakaintindi ko, hindi talaga kailangang baguhin ng Zabbix ang data, at ang lahat ng ito ay parang log. Posible bang gumamit ng mga dalubhasang database na hindi mababago ang kanilang data, ngunit sa parehong oras ay i-save, maipon, at ipamahagi nang mas mabilis - Clickhouse, halimbawa, isang bagay na katulad ng Kafka?.. Ang Kafka ay isang log din! Posible bang isama ang mga ito kahit papaano?
AG: - Maaaring gawin ang pagbabawas. Mayroon kaming isang tiyak na "tampok" mula noong bersyon 3.4: maaari mong isulat ang lahat ng makasaysayang file, kaganapan, lahat ng iba pa sa mga file; at pagkatapos ay ipadala ito sa anumang iba pang database gamit ang ilang handler. Sa katunayan, maraming tao ang muling gumagawa at direktang sumulat sa database. Sa mabilisang paraan, isinulat ng mga sinker ng kasaysayan ang lahat ng ito sa mga file, paikutin ang mga file na ito, at iba pa, at maaari mong ilipat ito sa Clickhouse. Hindi ko masasabi ang tungkol sa mga plano, ngunit marahil ang karagdagang suporta para sa mga solusyon sa NoSQL (tulad ng Clickhouse) ay magpapatuloy.
A: – Sa pangkalahatan, lumalabas na maaari mong ganap na mapupuksa ang mga postgres?
AG: – Siyempre, ang pinakamahirap na bahagi sa Zabbix ay ang mga makasaysayang talahanayan, na lumilikha ng pinakamaraming problema, at mga kaganapan. Sa kasong ito, kung hindi ka mag-imbak ng mga kaganapan sa loob ng mahabang panahon at mag-imbak ng kasaysayan na may mga uso sa ilang iba pang mabilis na imbakan, kung gayon sa pangkalahatan, sa palagay ko, walang mga problema.
A: – Maaari mo bang tantiyahin kung gaano kabilis ang lahat kung lilipat ka sa Clickhouse, halimbawa?
AG: - Hindi ko pa ito nasubukan. Sa palagay ko, ang hindi bababa sa parehong mga numero ay maaaring makamit nang simple, dahil ang Clickhouse ay may sariling interface, ngunit hindi ko masasabi nang sigurado. Mas mainam na subukan. Ang lahat ay nakasalalay sa pagsasaayos: kung gaano karaming mga host ang mayroon ka, at iba pa. Ang pagpasok ay isang bagay, ngunit kailangan mo ring kunin ang data na ito - Grafana o iba pa.
A: – Kaya pinag-uusapan natin ang tungkol sa pantay na laban, at hindi tungkol sa malaking bentahe ng mga mabilis na database na ito?
AG: – Sa tingin ko kapag nag-integrate tayo, magkakaroon ng mas tumpak na mga pagsubok.
A: – Saan napunta ang magandang lumang RRD? Ano ang dahilan kung bakit ka lumipat sa mga database ng SQL? Sa una, lahat ng sukatan ay nakolekta sa RRD.
AG: – Ang Zabbix ay may RRD, marahil sa isang napaka sinaunang bersyon. Palaging may mga database ng SQL - isang klasikong diskarte. Ang klasikong diskarte ay MySQL, PostgreSQL (sila ay umiral nang napakatagal na panahon). Halos hindi kami gumamit ng karaniwang interface para sa mga database ng SQL at RRD.
Ilang ad 🙂
Salamat sa pananatili sa amin. Gusto mo ba ang aming mga artikulo? Gustong makakita ng mas kawili-wiling nilalaman? Suportahan kami sa pamamagitan ng pag-order o pagrekomenda sa mga kaibigan, , isang natatanging analogue ng mga entry-level na server, na inimbento namin para sa iyo: (magagamit sa RAID1 at RAID10, hanggang 24 na core at hanggang 40GB DDR4).
Dell R730xd 2x na mas mura sa Equinix Tier IV data center sa Amsterdam? Dito lang sa Netherlands! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - mula $99! Basahin ang tungkol sa
Pinagmulan: www.habr.com