Ang Zabbix ay isang sistema ng pagsubaybay. Tulad ng iba pang sistema, nahaharap ito sa tatlong pangunahing problema ng lahat ng sistema ng pagsubaybay: pagkolekta at pagproseso ng data, pag-iimbak ng kasaysayan, at paglilinis nito.
Ang mga yugto ng pagtanggap, pagproseso at pagtatala ng data ay tumatagal ng oras. Hindi gaano, ngunit para sa isang malaking sistema maaari itong magresulta sa malalaking pagkaantala. Ang problema sa storage ay isang isyu sa pag-access ng data. Ginagamit ang mga ito para sa mga ulat, pagsusuri at pag-trigger. Ang mga latency sa pag-access ng data ay nakakaapekto rin sa pagganap. Kapag lumaki ang mga database, kailangang tanggalin ang walang kaugnayang data. Ang pag-alis ay isang mahirap na operasyon na kumakain din ng ilang mapagkukunan.
Ang mga problema ng mga pagkaantala sa panahon ng pagkolekta at pag-iimbak sa Zabbix ay nalutas sa pamamagitan ng pag-cache: ilang uri ng mga cache, pag-cache sa database. Upang malutas ang pangatlong problema, ang pag-cache ay hindi angkop, kaya ginamit ni Zabbix ang TimescaleDB. Sasabihin niya sa iyo ang tungkol dito Andrey Gushchin - inhinyero ng teknikal na suporta . Si Andrey ay sumusuporta sa Zabbix nang higit sa 6 na taon at may direktang karanasan sa pagganap.
Paano gumagana ang TimescaleDB, anong performance ang maibibigay nito kumpara sa regular na PostgreSQL? Anong papel ang ginagampanan ng Zabbix para sa database ng TimescaleDB? Paano magsimula mula sa simula at kung paano lumipat mula sa PostgreSQL at aling pagsasaayos ang may mas mahusay na pagganap? Tungkol sa lahat ng ito sa ilalim ng hiwa.
Mga Hamon sa Produktibidad
Ang bawat sistema ng pagsubaybay ay nahaharap sa mga partikular na hamon sa pagganap. Tatlo sa kanila ang pag-uusapan ko: pagkolekta at pagproseso ng data, pag-iimbak, at pag-clear ng kasaysayan.
Mabilis na pangongolekta at pagproseso ng data. Ang isang mahusay na sistema ng pagsubaybay ay dapat na mabilis na makatanggap ng lahat ng data at iproseso ito ayon sa mga expression ng trigger - ayon sa pamantayan nito. Pagkatapos ng pagproseso, dapat ding mabilis na i-save ng system ang data na ito sa database para magamit sa ibang pagkakataon.
Imbakan ng kasaysayan. Ang isang mahusay na sistema ng pagsubaybay ay dapat mag-imbak ng kasaysayan sa isang database at magbigay ng madaling pag-access sa mga sukatan. Kailangang magamit ang kasaysayan sa mga ulat, graph, trigger, threshold, at nakalkulang mga item sa data ng alerto.
Pag-clear ng kasaysayan. Minsan darating ang araw na hindi mo kailangang mag-imbak ng mga sukatan. Bakit kailangan mo ng data na nakolekta 5 taon na ang nakakaraan, isang buwan o dalawa: ang ilang mga node ay tinanggal, ang ilang mga host o sukatan ay hindi na kailangan dahil ang mga ito ay luma na at hindi na nakolekta. Ang isang mahusay na sistema ng pagsubaybay ay dapat mag-imbak ng makasaysayang data at tanggalin ito paminsan-minsan upang hindi lumaki ang database.
Ang paglilinis ng lipas na data ay isang kritikal na isyu na lubos na nakakaapekto sa pagganap ng database.
Pag-cache sa Zabbix
Sa Zabbix, ang una at pangalawang tawag ay nalutas gamit ang caching. Ang RAM ay ginagamit upang mangolekta at magproseso ng data. Para sa imbakan - kasaysayan sa mga trigger, graph at kalkuladong elemento ng data. Sa gilid ng database mayroong ilang caching para sa mga pangunahing seleksyon, halimbawa, mga graph.
Ang pag-cache sa gilid ng server ng Zabbix mismo ay:
- ConfigurationCache;
- ValueCache;
- HistoryCache;
- TrendsCache.
Isaalang-alang ang mga ito nang mas detalyado.
ConfigurationCache
Ito ang pangunahing cache kung saan nag-iimbak kami ng mga sukatan, host, data item, trigger - lahat ng kailangan namin para sa PreProcessing at para sa pangongolekta ng data.
Ang lahat ng ito ay naka-imbak sa ConfigurationCache upang hindi lumikha ng mga hindi kinakailangang query sa database. Pagkatapos magsimula ng server, ina-update namin ang cache na ito, gumagawa at pana-panahong nag-a-update ng mga configuration.
Pagkolekta ng data
Ang diagram ay medyo malaki, ngunit ang pangunahing bagay dito ay mga kolektor. Ito ay iba't ibang "mga poller" - mga proseso ng pagpupulong. Responsable sila para sa iba't ibang uri ng pagpupulong: nangongolekta sila ng data sa pamamagitan ng SNMP, IPMI, at inililipat ang lahat sa PreProcessing.
Ang mga kolektor ay nakabalangkas sa orange.
Kinakalkula ng Zabbix ang mga item ng pagsasama-sama na kinakailangan upang pagsama-samahin ang mga pagsusuri. Kung mayroon kami ng mga ito, kinukuha namin ang data para sa kanila nang direkta mula sa ValueCache.
PreProcessing HistoryCache
Ang lahat ng mga kolektor ay gumagamit ng ConfigurationCache upang makatanggap ng mga trabaho. Pagkatapos ay inilipat nila ang mga ito sa PreProcessing.
Ang PreProcessing ay gumagamit ng ConfigurationCache upang makatanggap ng mga hakbang sa PreProcessing. Pinoproseso nito ang data na ito sa iba't ibang paraan.
Pagkatapos iproseso ang data gamit ang PreProcessing, ise-save namin ito sa HistoryCache para sa pagproseso. Tinatapos nito ang pagkolekta ng data at nagpapatuloy kami sa pangunahing proseso sa Zabbix - history syncr, dahil ito ay isang monolitikong arkitektura.
Tandaan: Ang PreProcessing ay medyo mahirap na operasyon. Sa v 4.2 ito ay inilipat sa proxy. Kung mayroon kang napakalaking Zabbix na may malaking bilang ng mga elemento ng data at dalas ng pagkolekta, kung gayon, mas pinapadali nito ang gawain.
ValueCache, kasaysayan at mga trend cache
Ang history syncer ay ang pangunahing proseso na atomiko na nagpoproseso ng bawat elemento ng data, iyon ay, ang bawat halaga.
Kinukuha ng history syncer ang mga halaga mula sa HistoryCache at sinusuri ang Configuration para sa pagkakaroon ng mga trigger para sa mga kalkulasyon. Kung mayroon sila, kinakalkula nito.
Gumagawa ang history syncer ng isang kaganapan, pagdami upang lumikha ng mga alerto kung kinakailangan ayon sa configuration, at mga tala. Kung may mga nag-trigger para sa kasunod na pagproseso, iniimbak nito ang halagang ito sa ValueCache upang hindi ma-access ang talahanayan ng kasaysayan. Ito ay kung paano napuno ang ValueCache ng data na kinakailangan upang kalkulahin ang mga trigger at kinakalkula na mga elemento.
Sinusulat ng history syncer ang lahat ng data sa database, at nagsusulat ito sa disk. Dito nagtatapos ang proseso ng pagproseso.
Pag-cache sa database
Sa gilid ng database mayroong iba't ibang mga cache kapag gusto mong tingnan ang mga graph o ulat sa mga kaganapan:
Innodb_buffer_poolsa gilid ng MySQL;shared_bufferssa gilid ng PostgreSQL;effective_cache_sizesa bahagi ng Oracle;shared_poolsa gilid ng DB2.
Mayroong maraming iba pang mga cache, ngunit ito ang mga pangunahing para sa lahat ng mga database. Pinapayagan ka nitong mag-imbak ng data sa RAM na kadalasang kinakailangan para sa mga query. Mayroon silang sariling mga teknolohiya para dito.
Ang pagganap ng database ay kritikal
Ang server ng Zabbix ay patuloy na nangongolekta ng data at isinusulat ito. Kapag na-restart, nagbabasa rin ito mula sa kasaysayan upang punan ang ValueCache. Gumagamit ng mga script at ulat Zabbix API, na binuo sa isang Web interface. Ina-access ng Zabbix API ang database at kinukuha ang kinakailangang data para sa mga graph, ulat, listahan ng kaganapan at pinakabagong isyu.
Para sa visualization - grafana. Ito ay isang tanyag na solusyon sa aming mga gumagamit. Maaari itong direktang magpadala ng mga kahilingan sa pamamagitan ng Zabbix API at sa database, at lumikha ng isang tiyak na kumpetisyon para sa pagtanggap ng data. Samakatuwid, ang mas pino at mas mahusay na pag-tune ng database ay kailangan upang tumugma sa mabilis na paghahatid ng mga resulta at pagsubok.
Tagapangalaga ng bahay
Ang pangatlong hamon sa pagganap sa Zabbix ay ang pag-clear ng kasaysayan gamit ang Housekeeper. Sinusunod nito ang lahat ng mga setting - ipinapahiwatig ng mga elemento ng data kung gaano katagal iimbak ang dynamics ng mga pagbabago (trend) sa mga araw.
Kinakalkula namin ang TrendsCache sa mabilisang. Kapag dumating ang data, pinagsama-sama namin ito sa loob ng isang oras at itinatala ito sa mga talahanayan para sa dynamics ng mga pagbabago sa trend.
Sinisimulan at tinatanggal ng housekeeper ang impormasyon mula sa database gamit ang karaniwang "mga pinili". Ito ay hindi palaging epektibo, tulad ng makikita mula sa mga graph ng pagganap ng mga panloob na proseso.
Ang pulang graph ay nagpapakita na ang History syncer ay palaging abala. Ang orange na graph sa itaas ay Housekeeper, na patuloy na tumatakbo. Hinihintay niyang tanggalin ng database ang lahat ng row na tinukoy niya.
Kailan mo dapat i-disable ang Housekeeper? Halimbawa, mayroong isang "Item ID" at kailangan mong tanggalin ang huling 5 libong mga hilera sa loob ng isang tiyak na oras. Siyempre, nangyayari ito sa pamamagitan ng index. Ngunit kadalasan ang dataset ay napakalaki, at ang database ay nagbabasa pa rin mula sa disk at inilalagay ito sa cache. Ito ay palaging isang napakamahal na operasyon para sa database at, depende sa laki ng database, ay maaaring humantong sa mga problema sa pagganap.
Madaling i-disable ang housekeeper. Sa Web interface mayroong isang setting sa "Pangkalahatang Administrasyon" para sa Housekeeper. Hindi namin pinapagana ang panloob na Housekeeping para sa kasaysayan ng panloob na trend at hindi na nito pinamamahalaan ito.
Na-off ang housekeeper, na-level out ang mga graph - anong mga problema ang maaaring magkaroon sa kasong ito at ano ang makakatulong sa paglutas ng pangatlong hamon sa pagganap?
Paghahati - paghahati o paghahati
Karaniwan, ang partitioning ay naka-configure sa ibang paraan sa bawat relational database na aking inilista. Ang bawat isa ay may sariling teknolohiya, ngunit pareho sila sa pangkalahatan. Ang paglikha ng isang bagong partisyon ay madalas na humahantong sa ilang mga problema.
Karaniwan, ang mga partisyon ay na-configure depende sa "setup" - ang dami ng data na nilikha sa isang araw. Bilang isang patakaran, ang Partitioning ay ibinibigay sa isang araw, ito ang pinakamababa. Para sa mga trend ng isang bagong batch - 1 buwan.
Ang mga halaga ay maaaring magbago kung ang "setup" ay napakalaki. Kung ang isang maliit na "setup" ay hanggang sa 5 nvps (mga bagong halaga bawat segundo), ang isang katamtaman ay mula 000 hanggang 5, kung gayon ang isang malaki ay higit sa 000 nvps. Ang mga ito ay malalaki at napakalaking installation na nangangailangan ng maingat na pagsasaayos ng database.
Sa napakalaking mga pag-install, ang isang panahon ng isang araw ay maaaring hindi pinakamainam. Nakita ko ang mga partisyon ng MySQL na 40 GB o higit pa bawat araw. Ito ay isang napakalaking dami ng data na maaaring magdulot ng mga problema at kailangang bawasan.
Ano ang ibinibigay ng Partitioning?
Paghahati ng mga talahanayan. Kadalasan ang mga ito ay hiwalay na mga file sa disk. Pinipili ng query plan ang isang partition nang mas mahusay. Karaniwan ang partitioning ay ginagamit ayon sa range - totoo rin ito para sa Zabbix. Gumagamit kami ng "timestamp" doon - oras mula noong simula ng panahon. Ito ay mga ordinaryong numero para sa amin. Itinakda mo ang simula at pagtatapos ng araw - isa itong partition.
Mabilis na pagtanggal - DELETE. Isang file/subtable ang pinili, sa halip na isang seleksyon ng mga row para tanggalin.
Makabuluhang nagpapabilis sa pagkuha ng data SELECT - gumagamit ng isa o higit pang mga partisyon, sa halip na ang buong talahanayan. Kung nag-a-access ka ng data na dalawang araw na ang edad, ito ay nakuha mula sa database nang mas mabilis dahil kailangan mo lamang mag-load ng isang file sa cache at ibalik ito, hindi isang malaking talahanayan.
Kadalasan maraming mga database ay pinabilis din INSERT — pagsingit sa child table.
TimescaleDB
Para sa v 4.2, ibinaling namin ang aming pansin sa TimescaleDB. Ito ay isang extension para sa PostgreSQL na may katutubong interface. Ang extension ay epektibong gumagana sa data ng time series, nang hindi nawawala ang mga benepisyo ng relational database. Ang TimescaleDB ay awtomatikong nagpi-partition din.
May konsepto ang TimescaleDB hypertable (hypertable) na iyong nilikha. Naglalaman ito mga tipak - mga partisyon. Ang mga chunk ay awtomatikong pinamamahalaan ang mga hypertable na fragment na hindi nakakaapekto sa iba pang mga fragment. Ang bawat tipak ay may sariling hanay ng oras.
TimescaleDB kumpara sa PostgreSQL
Gumagana talaga ang TimescaleDB. Sinasabi ng mga tagagawa ng extension na gumagamit sila ng mas tamang algorithm sa pagproseso ng query, sa partikular inserts . Habang lumalaki ang laki ng insert ng dataset, pinapanatili ng algorithm ang patuloy na pagganap.
Pagkatapos ng 200 milyong mga row, ang PostgreSQL ay karaniwang nagsisimulang lumubog nang malaki at nawawala ang pagganap sa 0. Binibigyang-daan ka ng TimescaleDB na mahusay na magpasok ng "mga pagsingit" para sa anumang dami ng data.
Instalasyon
Ang pag-install ng TimescaleDB ay medyo madali para sa anumang pakete. SA ang lahat ay inilarawan nang detalyado - depende ito sa opisyal na mga pakete ng PostgreSQL. Ang TimescaleDB ay maaari ding itayo at i-compile nang manu-mano.
Para sa database ng Zabbix, ina-activate lang namin ang extension:
echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix
I-activate mo extension at likhain ito para sa database ng Zabbix. Ang huling hakbang ay gumawa ng hypertable.
Paglipat ng mga talahanayan ng kasaysayan sa TimescaleDB
Mayroong isang espesyal na function para dito 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 ay may tatlong mga parameter. Una - talahanayan sa database, kung saan kailangan mong lumikha ng hypertable. Pangalawa - patlang, ayon sa kung saan kailangan mong lumikha chunk_time_interval — pagitan ng mga partition chunks na gagamitin. Sa aking kaso, ang pagitan ay isang araw - 86.
Ikatlong parameter - migrate_data. Kung itinakda mo true, pagkatapos ang lahat ng kasalukuyang data ay ililipat sa mga paunang nilikha na mga tipak. Ako mismo ang gumamit nito migrate_data. Nagkaroon ako ng humigit-kumulang 1 TB, na tumagal ng mahigit isang oras. Kahit na sa ilang mga kaso, sa panahon ng pagsubok, tinanggal ko ang makasaysayang data ng mga uri ng character na hindi kinakailangan para sa imbakan, upang hindi mailipat ang mga ito.
Huling hakbang - UPDATE: sa db_extension ilagay timescaledbupang maunawaan ng database na umiiral ang extension na ito. Ina-activate ito ng Zabbix at wastong ginagamit ang syntax at mga query sa database - ang mga feature na kailangan para sa TimescaleDB.
Pag-configure ng hardware
Dalawang server ang ginamit ko. Una - VMware machine. Ito ay medyo maliit: 20 Intel® Xeon® CPU E5-2630 v 4 @ 2.20GHz na mga processor, 16 GB ng RAM at isang 200 GB SSD.
Nag-install ako ng PostgreSQL 10.8 dito gamit ang Debian 10.8-1.pgdg90+1 OS at xfs file system. Na-configure ko ang lahat nang kaunti upang magamit ang partikular na database na ito, minus kung ano mismo ang gagamitin ng Zabbix.
Sa parehong makina mayroong isang server ng Zabbix, PostgreSQL at mga ahente ng pagkarga. Mayroon akong 50 aktibong ahente na gumagamit LoadableModuleupang napakabilis na makabuo ng iba't ibang mga resulta: mga numero, mga string. Pinuno ko ang database ng maraming data.
Sa una ang configuration na nilalaman 5 elemento data bawat host. Halos bawat elemento ay naglalaman ng trigger upang gawin itong katulad ng mga tunay na pag-install. Sa ilang mga kaso mayroong higit sa isang trigger. Para sa isang network node mayroong 3-000 trigger.
Interval ng Pag-update ng Item ng Data − 4 7-segundo. Inayos ko ang load mismo sa pamamagitan ng paggamit ng hindi lamang 50 ahente, ngunit pagdaragdag pa. Gayundin, gamit ang mga elemento ng data, pabago-bago kong inayos ang pagkarga at binawasan ang pagitan ng pag-update sa 4 na segundo.
PostgreSQL. 35 nvps
Ang una kong pagtakbo sa hardware na ito ay sa purong PostgreSQL - 35 libong halaga bawat segundo. Tulad ng nakikita mo, ang pagpasok ng data ay tumatagal ng mga fraction ng isang segundo - lahat ay mabuti at mabilis. Ang tanging bagay ay mabilis na mapupuno ang isang 200 GB SSD disk.
Ito ay isang karaniwang dashboard ng pagganap ng server ng Zabbix.
Ang unang asul na graph ay ang bilang ng mga halaga bawat segundo. Ang pangalawang graph sa kanan ay ang paglo-load ng mga proseso ng build. Ang pangatlo ay ang paglo-load ng mga internal na proseso ng build: history syncers at Housekeeper, na medyo matagal nang tumatakbo dito.
Ipinapakita ng ikaapat na graph ang paggamit ng HistoryCache. Ito ay isang uri ng buffer bago ipasok sa database. Ipinapakita ng berdeng ikalimang graph ang paggamit ng ValueCache, ibig sabihin, kung gaano karaming mga hit ng ValueCache para sa mga trigger - ito ay ilang libong halaga bawat segundo.
PostgreSQL. 50 nvps
Pagkatapos ay dinagdagan ko ang pagkarga sa 50 libong halaga bawat segundo sa parehong hardware.
Kapag naglo-load mula sa Housekeeper, ang pagpasok ng 10 libong halaga ay tumagal ng 2-3 segundo.
Nagsisimula nang manghimasok ang kasambahay sa trabaho.
Ang ikatlong graph ay nagpapakita na, sa pangkalahatan, ang load sa mga trapper at history synchers ay nasa 60% pa rin. Sa ikaapat na graph, ang HistoryCache ay nagsisimula nang mapuno nang medyo aktibo sa panahon ng operasyon ng Housekeeper. Ito ay 20% puno, na halos 0,5 GB.
PostgreSQL. 80 nvps
Pagkatapos ay dinagdagan ko ang pagkarga sa 80 libong halaga bawat segundo. Ito ay humigit-kumulang 400 libong mga elemento ng data at 280 libong mga trigger.
Medyo mataas na ang halaga ng paglo-load ng tatlumpung history synchers.
Dinagdagan ko rin ang iba't ibang mga parameter: mga history syncers, mga cache.
Sa aking hardware, ang paglo-load ng mga history syncers ay tumaas sa maximum. Mabilis na napuno ng data ang HistoryCache - ang data para sa pagproseso ay naipon sa buffer.
Sa lahat ng oras na ito, napagmasdan ko kung paano ginamit ang processor, RAM at iba pang mga parameter ng system, at natagpuan na ang paggamit ng disk ay nasa maximum nito.
Nakamit ko ang paggamit maximum na mga kakayahan sa disk sa hardware na ito at sa virtual machine na ito. Sa ganoong intensity, ang PostgreSQL ay nagsimulang mag-flush ng data nang medyo aktibo, at ang disk ay wala nang oras upang magsulat at magbasa.
Pangalawang server
Kumuha ako ng isa pang server, na mayroon nang 48 processor at 128 GB ng RAM. Na-tono ko ito - itinakda ito sa 60 history syncer, at nakamit ang katanggap-tanggap na pagganap.
Sa katunayan, ito na ang limitasyon ng pagiging produktibo kung saan may kailangang gawin.
TimescaleDB. 80 nvps
Ang aking pangunahing gawain ay subukan ang mga kakayahan ng TimescaleDB laban sa Zabbix load. Ang 80 libong halaga bawat segundo ay marami, ang dalas ng pagkolekta ng mga sukatan (maliban sa Yandex, siyempre) at isang medyo malaking "setup".
Mayroong pagbaba sa bawat graph - ito mismo ang paglipat ng data. Matapos ang mga pagkabigo sa server ng Zabbix, ang pag-load ng profile ng history syncer ay nagbago nang malaki - bumaba ito nang tatlong beses.
Binibigyang-daan ka ng TimescaleDB na magpasok ng data nang halos 3 beses nang mas mabilis at gumamit ng mas kaunting HistoryCache.
Alinsunod dito, makakatanggap ka ng data sa isang napapanahong paraan.
TimescaleDB. 120 nvps
Pagkatapos ay dinagdagan ko ang bilang ng mga elemento ng data sa 500 libo. Ang pangunahing gawain ay upang subukan ang mga kakayahan ng TimescaleDB - Nakatanggap ako ng kinakalkula na halaga ng 125 libong halaga bawat segundo.
Ito ay isang gumaganang "setup" na maaaring gumana nang mahabang panahon. Ngunit dahil ang aking disk ay 1,5 TB lamang, napuno ko ito sa loob ng ilang araw.
Ang pinakamahalagang bagay ay na kasabay nito ay nilikha ang mga bagong partisyon ng TimescaleDB.
Ito ay ganap na hindi napapansin para sa pagganap. Kapag ang mga partisyon ay nilikha sa MySQL, halimbawa, lahat ay iba. Karaniwan itong nangyayari sa gabi dahil hinaharangan nito ang pangkalahatang pagpapasok, gumagana sa mga talahanayan at maaaring lumikha ng pagkasira ng serbisyo. Hindi ito ang kaso sa TimescaleDB.
Bilang halimbawa, magpapakita ako ng isang graph mula sa marami sa komunidad. Sa larawan, ang TimescaleDB ay pinagana, salamat sa kung saan ang pag-load sa paggamit ng io.weight sa processor ay bumaba. Nabawasan din ang paggamit ng mga panloob na elemento ng proseso. Bukod dito, ito ay isang ordinaryong virtual machine sa mga ordinaryong pancake disk, hindi isang SSD.
Natuklasan
Ang TimescaleDB ay isang magandang solusyon para sa maliit na "setup", na nakakaapekto sa pagganap ng disk. Papayagan ka nitong magpatuloy sa pagtatrabaho nang maayos hanggang sa mailipat ang database sa hardware sa lalong madaling panahon.
Ang TimescaleDB ay madaling i-configure, nagbibigay ng mga nadagdag sa pagganap, gumagana nang maayos sa Zabbix at ay may mga pakinabang sa PostgreSQL.
Kung gumagamit ka ng PostgreSQL at hindi planong baguhin ito, inirerekomenda ko gumamit ng PostgreSQL kasama ang extension ng TimescaleDB kasabay ng Zabbix. Ang solusyon na ito ay epektibong gumagana hanggang sa isang medium na "setup".
Kapag sinabi nating "mataas na pagganap" ang ibig nating sabihin . Hindi ka na maghihintay ng mahabang panahon upang matutunan ang tungkol sa mga teknolohiya at kasanayan na nagbibigay-daan sa mga serbisyo na makapaghatid ng milyun-milyong user. Listahan para sa Nobyembre 7 at 8 ay naipon na namin, ngunit dito higit pa ang maaaring imungkahi.
Mag-subscribe sa aming и , kung saan ibinubunyag namin ang mga tampok ng paparating na kumperensya, at alamin kung paano masulit ito.
Pinagmulan: www.habr.com