{"id":55734,"date":"2020-01-27T00:00:00","date_gmt":"2020-01-26T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/highload-andrej-gushhin-zabbix-vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie"},"modified":"2020-02-18T14:03:52","modified_gmt":"2020-02-18T11:03:52","slug":"highload-andrej-gushhin-zabbix-vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie","status":"publish","type":"post","link":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/highload-andrej-gushhin-zabbix-vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie","title":{"rendered":"HighLoad++, Andrei Gu\u0219chin (Zabbix): performan\u021b\u0103 ridicat\u0103 \u0219i partajare nativ\u0103.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Vom discuta despre utilizarea Zabbix cu TimescaleDB ca backend. V\u0103 vom ar\u0103ta cum s\u0103 porni\u021bi de la zero \u0219i cum s\u0103 migra\u021bi de la PostgreSQL. De asemenea, vom prezenta teste comparative de performan\u021b\u0103 pentru cele dou\u0103 configura\u021bii.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0219chin (Zabbix): performan\u021b\u0103 ridicat\u0103 \u0219i partajare nativ\u0103.\" src=\"\/wp-content\/uploads\/2020\/01\/fb4f7ea4585b6dcdafec9d0d1e3a71e4.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHighLoad++ Siberia 2019. Sala \u201eTomsk\u201d. 24 iunie, 16:00. Teze \u0219i <noindex><a rel=\"nofollow\" href=\"https:\/\/www.highload.ru\/siberia\/2019\/abstracts\/5390\">prezentare<\/a><\/noindex>. Cea de-a doua conferin\u021b\u0103 HighLoad++ va avea loc pe 6 \u0219i 7 aprilie 2020 la Sankt Petersburg. Detalii \u0219i bilete <noindex><a rel=\"nofollow\" href=\"http:\/\/bit.ly\/2sSxgBx\">la link<\/a><\/noindex>.<\/p>\n<p><b>Andrei Gu\u0219in (\u00een continuare \u2013 AG):<\/b> \u2013 Eu sunt inginer de suport tehnic la ZABBIX (\u00een continuare \u2013 \u201eZabbix\u201d), formator. Activez de mai bine de 6 ani \u00een suportul tehnic \u0219i m-am confruntat direct cu performan\u021ba. Ast\u0103zi voi vorbi despre performan\u021ba pe care o poate oferi TimescaleDB, compar\u00e2nd-o cu PostgreSQL 10 obi\u0219nuit. De asemenea, voi oferi o prezentare general\u0103 despre modul \u00een care func\u021bioneaz\u0103.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h3>Principalele provoc\u0103ri de performan\u021b\u0103: de la colectare la cur\u0103\u021barea datelor<\/h3>\n<p>\nS\u0103 \u00eencepem prin a spune c\u0103 exist\u0103 anumite provoc\u0103ri de performan\u021b\u0103 cu care se confrunt\u0103 fiecare sistem de monitorizare. Prima provocare de performan\u021b\u0103 este colectarea \u0219i procesarea rapid\u0103 a datelor.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0219chin (Zabbix): performan\u021b\u0103 ridicat\u0103 \u0219i partajare nativ\u0103.\" src=\"\/wp-content\/uploads\/2020\/01\/a2cb78b549a55c3b59d7fcdb8b8865b3.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nUn sistem de monitorizare bun trebuie s\u0103 primeasc\u0103 rapid \u0219i la timp toate datele, s\u0103 le proceseze conform expresiilor trigger, adic\u0103 s\u0103 le proceseze \u00een func\u021bie de anumite criterii (\u00een diferite sisteme este diferit) \u0219i s\u0103 le salveze \u00een baza de date pentru a putea fi utilizate ulterior.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0219chin (Zabbix): performan\u021b\u0103 ridicat\u0103 \u0219i partajare nativ\u0103.\" src=\"\/wp-content\/uploads\/2020\/01\/a3ce55c3aec3eb93948150684838a5b3.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nA doua provocare de performan\u021b\u0103 este stocarea istoriei. Este important s\u0103 p\u0103stra\u021bi \u00een baza de date datele \u0219i s\u0103 ave\u021bi acces rapid \u0219i convenabil la aceste metrici, care au fost colectate pe o anumit\u0103 perioad\u0103 de timp. Cel mai important este s\u0103 ave\u021bi u\u0219urin\u021ba de a ob\u021bine aceste date, pentru a le folosi \u00een rapoarte, grafice, tr\u0103g\u0103tori, \u00een anumite valori prag, pentru alerte etc.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0219chin (Zabbix): performan\u021b\u0103 ridicat\u0103 \u0219i partajare nativ\u0103.\" src=\"\/wp-content\/uploads\/2020\/01\/325363d79f0270d620f956eeb8ab3402.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nA treia provocare de performan\u021b\u0103 este cur\u0103\u021barea istoriei, adic\u0103 atunci c\u00e2nd ajunge\u021bi \u00een acea zi \u00een care nu mai este nevoie s\u0103 p\u0103stra\u021bi anumite metrici detaliate, care au fost colectate \u00een ultimii 5 ani (chiar \u0219i luni sau dou\u0103 luni). Anumite noduri din re\u021bea au fost eliminate sau anumite gazde, iar metricile nu mai sunt necesare, deoarece au devenit \u00eenvechite \u0219i nu mai sunt colectate. Totul trebuie cur\u0103\u021bat pentru a evita extinderea bazei de date la o dimensiune mare. \u00cen general, cur\u0103\u021barea istoriei este, de cele mai multe ori, o provocare serioas\u0103 pentru stocare \u2013 afecteaz\u0103 semnificativ performan\u021ba.<\/p>\n<h3>Cum s\u0103 rezolv\u0103m problemele de cache?<\/h3>\n<p>\nAcum voi vorbi \u00een mod specific despre \u201eZabbix\u201d. \u00cen \u201eZabbix\u201d, prima \u0219i a doua apelare sunt rezolvate prin intermediul cache-ului.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0219chin (Zabbix): performan\u021b\u0103 ridicat\u0103 \u0219i partajare nativ\u0103.\" src=\"\/wp-content\/uploads\/2020\/01\/d5510b31553ee8e63a0c240789d51622.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nColectarea \u0219i procesarea datelor \u2013 folosim memoria RAM pentru a stoca toate aceste date. Acum, despre aceste date va fi vorbit mai \u00een detaliu.<\/p>\n<p>De asemenea, pe partea bazei de date exist\u0103 un anumit caching pentru selec\u021biile de baz\u0103 \u2013 pentru grafice \u0219i alte elemente.<\/p>\n<p>Caching pe serverul Zabbix \u00een sine: avem ConfigurationCache, ValueCache, HistoryCache, TrendsCache. Ce \u00eenseamn\u0103 acestea?<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0219chin (Zabbix): performan\u021b\u0103 ridicat\u0103 \u0219i partajare nativ\u0103.\" src=\"\/wp-content\/uploads\/2020\/01\/241a131145eccd280a7411c43b2cdce4.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nConfigurationCache \u2013 acesta este cache-ul principal, unde stoc\u0103m metricele, gazdele, elementele de date, trigerii; tot ce este necesar pentru preprocesare, colectarea datelor, de pe ce gazde s\u0103 colect\u0103m, cu ce frecven\u021b\u0103. Totul este stocat \u00een ConfigurationCache, pentru a nu apela baza de date, a nu crea cereri suplimentare. Dup\u0103 ce serverul porne\u0219te, actualiz\u0103m acest cache (\u00eel cre\u0103m) \u0219i-l actualiz\u0103m periodic (\u00een func\u021bie de set\u0103rile de configurare).<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0219chin (Zabbix): performan\u021b\u0103 ridicat\u0103 \u0219i partajare nativ\u0103.\" src=\"\/wp-content\/uploads\/2020\/01\/474ac0db2e46aa945a0da62197f72987.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Caching \u00een Zabbix. Colectarea datelor<\/h3>\n<p>\nAici schema este destul de mare:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0219chin (Zabbix): performan\u021b\u0103 ridicat\u0103 \u0219i partajare nativ\u0103.\" src=\"\/wp-content\/uploads\/2020\/01\/a6ad9dbd5deebac5440433a47c693fcf.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPrincipalele din schem\u0103 \u2013 acestea sunt colectoarele:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0219chin (Zabbix): performan\u021b\u0103 ridicat\u0103 \u0219i partajare nativ\u0103.\" src=\"\/wp-content\/uploads\/2020\/01\/feb932586302e2284bd44595caf9ee1b.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAcestea sunt procesele de colectare \u00een sine, diferite \u201epollere\u201d care se ocup\u0103 cu diferite tipuri de colectare. Ele colecteaz\u0103 date prin icmp, ipmi, prin diferite protocoale \u0219i transmit toate acestea c\u0103tre preprocesare.<\/p>\n<h3>PreProcessing HistoryCache<\/h3>\n<p>\nDe asemenea, dac\u0103 avem elemente de date calculabile (cei care sunt familiariza\u021bi cu \u201eZabbix\u201d \u0219tiu), adic\u0103 elemente de date calculabile, de agregare \u2013 le extragem direct din ValueCache. Despre cum se umple acesta, voi povesti mai t\u00e2rziu. Toate aceste colectoare folosesc ConfigurationCache pentru a primi sarcinile lor \u0219i apoi le transmit pentru preprocesare.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0219chin (Zabbix): performan\u021b\u0103 ridicat\u0103 \u0219i partajare nativ\u0103.\" src=\"\/wp-content\/uploads\/2020\/01\/3948ee1167c52856949c25e2043be974.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPreprocesarea utilizeaz\u0103 de asemenea ConfigurationCache pentru ob\u021binerea pa\u0219ilor preproces\u0103rii, proceseaz\u0103 aceste date \u00een diverse moduri. \u00cencep\u00e2nd cu versiunea 4.2, aceasta a fost mutat\u0103 pe proxy. Este foarte convenabil, deoarece preprocesarea \u00een sine este o opera\u021bie destul de grea. \u0218i dac\u0103 ave\u021bi un \u201eZabbix\u201d foarte mare, cu un num\u0103r mare de elemente de date \u0219i o frecven\u021b\u0103 mare de colectare, atunci asta u\u0219ureaz\u0103 foarte mult munca.<\/p>\n<p>Prin urmare, dup\u0103 ce am procesat aceste date \u00eentr-un fel cu ajutorul preproces\u0103rii, le stoc\u0103m \u00een HistoryCache pentru a le procesa ulterior. Aici se \u00eencheie colectarea datelor. Trecem la procesul principal.<\/p>\n<h3>Func\u021bia History syncer<\/h3>\n<p>\n<img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0219chin (Zabbix): performan\u021b\u0103 ridicat\u0103 \u0219i partajare nativ\u0103.\" src=\"\/wp-content\/uploads\/2020\/01\/66539e4184d041ed84f797080226ba24.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPrincipalul proces \u00een \u00abZabbix\u00bb (deoarece este o arhitectur\u0103 monolitic\u0103) este History syncer. Acesta este procesul principal care se ocup\u0103 de prelucrarea atomica a fiec\u0103rui element de date, adic\u0103 a fiec\u0103rui valoare:<\/p>\n<ul>\n<li>prime\u0219te valoarea (o preia din HistoryCache);<\/li>\n<li>verific\u0103 \u00een Configuration syncer: exist\u0103 vreo regul\u0103 pentru calculare - le calculeaz\u0103;<br \/>\ndac\u0103 exist\u0103 - creeaz\u0103 evenimente, creeaz\u0103 escalad\u0103ri pentru a genera o notificare, dac\u0103 este necesar conform configura\u021biei;<\/li>\n<li>\u00eenregistreaz\u0103 regulile pentru prelucrarea ulterioar\u0103, agregare; dac\u0103 agregi pentru ultima or\u0103 \u0219i a\u0219a mai departe, aceast\u0103 valoare este memorat\u0103 de ValueCache, pentru a nu face referire la tabelul istoric; astfel, ValueCache se completeaz\u0103 cu datele necesare pentru calcularea regulilor, a elementelor calculate etc.;<\/li>\n<li>apoi History syncer scrie toate datele \u00een baza de date;<\/li>\n<li>baza de date le scrie pe disc - procesul de prelucrare se finalizeaz\u0103 aici.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Baze de date. Cache-uri<\/h3>\n<p>\nPe partea bazei de date, c\u00e2nd vrei s\u0103 vizualizezi grafice sau diverse rapoarte despre evenimente, exist\u0103 diferite cache-uri. Dar \u00een cadrul acestei prezent\u0103ri nu voi discuta despre ele.<\/p>\n<p>Pentru MySQL exist\u0103 Innodb_buffer_pool, o mul\u021bime de cache-uri diferite care pot fi de asemenea configurate.<br \/>\nDar acestea sunt principalele:<\/p>\n<ul>\n<li>shared_buffers;<\/li>\n<li>effective_cache_size;<\/li>\n<li>shared_pool.<\/li>\n<\/ul>\n<p>\n<img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0219chin (Zabbix): performan\u021b\u0103 ridicat\u0103 \u0219i partajare nativ\u0103.\" src=\"\/wp-content\/uploads\/2020\/01\/925e7abb21cfaa2516ff2b33ab161dc0.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAm prezentat pentru toate bazele de date c\u0103 exist\u0103 anumite cache-uri care permit p\u0103strarea \u00een memorie a datelor care sunt frecvent necesare pentru interog\u0103ri. Acestea au propriile tehnologii pentru asta.<\/p>\n<h3>Despre performan\u021ba bazei de date<\/h3>\n<p>\nPrin urmare, exist\u0103 un mediu concurential, adic\u0103 serverul Zabbix colecteaz\u0103 date \u0219i le stocheaz\u0103. La repornire, de asemenea, cite\u0219te din istorie pentru a completa ValueCache \u0219i a\u0219a mai departe. De asemenea, pot exista scripturi \u0219i rapoarte care utilizeaz\u0103 API-ul Zabbix, care este construit pe baza interfe\u021bei web. API-ul Zabbix intr\u0103 \u00een baza de date \u0219i ob\u021bine datele necesare pentru a genera grafice, rapoarte sau o list\u0103 a evenimentelor, ultimelor probleme.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0219chin (Zabbix): performan\u021b\u0103 ridicat\u0103 \u0219i partajare nativ\u0103.\" src=\"\/wp-content\/uploads\/2020\/01\/10a55cb1af660aace3172a572bea6692.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDe asemenea, o solu\u021bie foarte popular\u0103 pentru vizualizare este Grafana, utilizat\u0103 de utilizatorii no\u0219tri. Aceasta poate accesa direct at\u00e2t prin API-ul Zabbix, c\u00e2t \u0219i prin baza de date. De asemenea, creeaz\u0103 o anumit\u0103 competi\u021bie pentru ob\u021binerea datelor: este necesar\u0103 o configurare mai rafinat\u0103 \u0219i bun\u0103 a bazei de date, pentru a asigura o livrare rapid\u0103 a rezultatelor \u0219i testarea.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0219chin (Zabbix): performan\u021b\u0103 ridicat\u0103 \u0219i partajare nativ\u0103.\" src=\"\/wp-content\/uploads\/2020\/01\/8a008e55dbee5635d386cec2fc1c40f5.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Cur\u0103\u021barea istoricului. \u00cen Zabbix exist\u0103 Housekeeper<\/h3>\n<p>\nA treia apelare utilizat\u0103 \u00een \u00abZabbix\u00bb este cur\u0103\u021barea istoricului cu ajutorul Housekeeper. \u00abHousekeeper\u00bb respect\u0103 toate set\u0103rile, adic\u0103 \u00een elementele de date este specificat c\u00e2t timp s\u0103 p\u0103stra\u021bi (\u00een zile), c\u00e2t timp s\u0103 p\u0103stra\u021bi tendin\u021bele \u0219i dinamica schimb\u0103rilor.<\/p>\n<p>Nu am povestit despre TrendCache, pe care \u00eel calcul\u0103m pe loc: datele sosesc, le agreg\u0103m pe parcursul unei ore (de obicei sunt numere pentru ultima or\u0103), cantitatea medie \/ minim\u0103 \u0219i le \u00eenregistr\u0103m o dat\u0103 pe or\u0103 \u00een tabelul dinamicii schimb\u0103rilor (\u00abTrends\u00bb). \u00abHousekeeper\u00bb este activat \u0219i \u0219terge datele din baza de date cu selec\u021bii obi\u0219nuite, ceea ce nu este \u00eentotdeauna eficient.<\/p>\n<p>Cum se poate \u00een\u021belege c\u0103 nu este eficient? Pute\u021bi vedea \u00een graficele de performan\u021b\u0103 a proceselor interne aceast\u0103 imagine:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0219chin (Zabbix): performan\u021b\u0103 ridicat\u0103 \u0219i partajare nativ\u0103.\" src=\"\/wp-content\/uploads\/2020\/01\/f413ec989491d4186a05c779978e2f6d.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAve\u021bi \u0219i History syncer constant ocupat (grafic ro\u0219u). Iar graficul \u201eportocalie\u201d, care se afl\u0103 deasupra. Acesta este \u00abHousekeeper\u00bb, care este activat \u0219i a\u0219teapt\u0103 de la baza de date s\u0103 \u0219tearg\u0103 toate r\u00e2ndurile pe care le-a specificat.<\/p>\n<p>S\u0103 lu\u0103m un anumit ID de element: trebuie s\u0103 \u0219tergem ultimele 5.000; desigur, pe baza indicilor. Dar, \u00een general, setul de date este suficient de mare \u2013 baza de date tot trebuie s\u0103 citeasc\u0103 de pe disc \u0219i s\u0103-l aduc\u0103 \u00een cache, iar aceasta este o opera\u021biune foarte costisitoare pentru baza de date. \u00cen func\u021bie de dimensiunile acesteia, acest lucru poate duce la anumite probleme de performan\u021b\u0103.<\/p>\n<p>Dezactivarea \u00abHousekeeper\u00bb se poate face simplu \u2013 avem interfa\u021ba web cunoscut\u0103. Set\u0103rile din Administration general (set\u0103rile pentru \u00abHousekeeper\u00bb) dezactiv\u0103m housekeeping-ul intern pentru istoricul \u0219i tendin\u021bele interne. Prin urmare, \u00abHousekeeper\u00bb nu mai gestioneaz\u0103 acest lucru:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0219chin (Zabbix): performan\u021b\u0103 ridicat\u0103 \u0219i partajare nativ\u0103.\" src=\"\/wp-content\/uploads\/2020\/01\/c9dc3ca86e7fd0c1229f6b9bc5d31270.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nCe se poate face mai departe? A\u021bi dezactivat, graficele s-au aliniat\u2026 Ce probleme ar putea ap\u0103rea \u00een continuare? Ce ar putea ajuta?<\/p>\n<h3>Parti\u021bionarea<\/h3>\n<p>\n\u00cen general, aceasta se configureaz\u0103 pe fiecare baz\u0103 de date rela\u021bional\u0103 men\u021bionat\u0103 de mine, \u00eentr-un mod diferit. MySQL are propria tehnologie. Dar, \u00een general, sunt foarte asem\u0103n\u0103toare, vorbim despre PostgreSQL 10 \u0219i MySQL. Desigur, exist\u0103 multe diferen\u021be interne \u00een modul \u00een care este implementat totul \u0219i modul \u00een care afecteaz\u0103 performan\u021ba. \u00cens\u0103, \u00een general, crearea unei noi parti\u021bii duce adesea \u0219i la anumite probleme.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0219chin (Zabbix): performan\u021b\u0103 ridicat\u0103 \u0219i partajare nativ\u0103.\" src=\"\/wp-content\/uploads\/2020\/01\/729114d61794314e19383f09ee9b5d61.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n\u00cen func\u021bie de configura\u021bia dvs. (c\u00e2t de multe date genera\u021bi \u00eentr-o singur\u0103 zi), de obicei se stabile\u0219te cea mai minim\u0103 \u2013 este de 1 zi\/parti\u021bie, iar pentru \u201etendin\u021be\u201d, dinamica schimb\u0103rilor \u2013 1 lun\u0103\/parti\u021bie nou\u0103. Aceasta poate varia dac\u0103 ave\u021bi o configura\u021bie foarte mare.<\/p>\n<p>S\u0103 v\u0103 spun de la \u00eenceput despre dimensiunile configura\u021biei: p\u00e2n\u0103 la 5.000 de valori noi pe secund\u0103 (nvps, a\u0219a-numitul) \u2013 acesta va fi considerat un \u00abset-up\u00bb mic. Mediu \u2013 de la 5 la 25 de mii de valori pe secund\u0103. Tot ce dep\u0103\u0219e\u0219te \u2013 este deja instala\u021bii mari \u0219i foarte mari, care necesit\u0103 o configurare foarte atent\u0103 a bazei de date.<\/p>\n<p>Pe instala\u021biile foarte mari, 1 zi \u2013 ar putea s\u0103 nu fie optim. Personal, am v\u0103zut \u00een MySQL parti\u021bii de 40 de gigabai\u021bi pe zi (\u0219i ar putea fi chiar mai mult). Acesta este un volum foarte mare de date, care poate duce la anumite probleme. Trebuie s\u0103 fie redus.<\/p>\n<h3>De ce este necesar\u0103 parti\u021bionarea?<\/h3>\n<p>\nCe aduce parti\u021bionarea, cred c\u0103 toat\u0103 lumea \u0219tie \u2013 este sec\u021bionarea tabelelor. Adesea sunt fi\u0219iere separate pe disc \u0219i interog\u0103ri span. Este mai optim s\u0103 selectezi o parti\u021bie, dac\u0103 aceasta este inclus\u0103 \u00een parti\u021bionarea obi\u0219nuit\u0103.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0219chin (Zabbix): performan\u021b\u0103 ridicat\u0103 \u0219i partajare nativ\u0103.\" src=\"\/wp-content\/uploads\/2020\/01\/4920fb3415733799f0a90b1bc7af0114.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPentru \u00abZabbix\u00bb, \u00een special, se folose\u0219te pe interval, adic\u0103 folosim timestamp (un num\u0103r obi\u0219nuit, timp de la \u00eenceputul epocii). Stabili\u021bi \u00eenceputul zilei\/terminarea zilei, iar aceasta reprezint\u0103 parti\u021bia. \u00cen consecin\u021b\u0103, dac\u0103 accesa\u021bi datele cu dou\u0103 zile \u00een urm\u0103, acestea sunt selectate mai repede din baza de date, deoarece trebuie s\u0103 \u00eenc\u0103rca\u021bi doar un fi\u0219ier \u00een cache \u0219i s\u0103-l emite\u021bi (nu o tabel\u0103 mare).<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0219chin (Zabbix): performan\u021b\u0103 ridicat\u0103 \u0219i partajare nativ\u0103.\" src=\"\/wp-content\/uploads\/2020\/01\/f5ee4e0b471eb5ebe701615aa617d66d.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nMulte baze de date, de asemenea, accelereaz\u0103 inserarea (inserarea \u00eentr-o sub-tabel\u0103). De\u0219i vorbesc abstract \u00een acest moment, dar este posibil. Parti\u021bionarea ajut\u0103 adesea.<\/p>\n<h3>Elasticsearch pentru NoSQL<\/h3>\n<p>\nRecent, \u00een 3.4, am implementat o solu\u021bie pentru NoSQL. Am ad\u0103ugat posibilitatea de a scrie \u00een Elasticsearch. Pute\u021bi scrie anumite tipuri: alege\u021bi \u2013 fie scrie\u021bi numere, fie c\u00e2teva semne; avem text de tip \u0219ir, pute\u021bi scrie jurnale \u00een Elasticsearch... \u00cen consecin\u021b\u0103, interfa\u021ba web va apela deja la Elasticsearch. Aceasta func\u021bioneaz\u0103 excelent \u00een anumite cazuri, dar \u00een prezent poate fi utilizat\u0103.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0219chin (Zabbix): performan\u021b\u0103 ridicat\u0103 \u0219i partajare nativ\u0103.\" src=\"\/wp-content\/uploads\/2020\/01\/24fe7d19c9e42474cd786ba59846c18c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>TimescaleDB. Hiper-tabele<\/h3>\n<p>\nPentru versiunea 4.4.2, am observat un lucru, \u0219i anume TimescaleDB. Ce este aceasta? Este o extensie pentru PostgreSQL, adic\u0103 are o interfa\u021b\u0103 nativ\u0103 PostgreSQL. \u00cen plus, aceast\u0103 extensie permite o gestionare mult mai eficient\u0103 a datelor de tip time-series \u0219i ofer\u0103 partajare automat\u0103. Cum arat\u0103 asta:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0219chin (Zabbix): performan\u021b\u0103 ridicat\u0103 \u0219i partajare nativ\u0103.\" src=\"\/wp-content\/uploads\/2020\/01\/de921f06453476215b6240ab9da6fae1.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAceasta este o hypertable \u2013 un concept din Timescale. Este o hiper-tabel\u0103 pe care o crea\u021bi, iar \u00een ea se afl\u0103 chunk-uri. Chunk-urile sunt parti\u021bii, sunt sub-tabele, dac\u0103 nu m\u0103 \u00een\u0219el. Este \u00eentr-adev\u0103r eficient.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0219chin (Zabbix): performan\u021b\u0103 ridicat\u0103 \u0219i partajare nativ\u0103.\" src=\"\/wp-content\/uploads\/2020\/01\/719eb3f5d8c9f57544dfc4010850610c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>TimescaleDB \u0219i PostgreSQL<\/h3>\n<p>\nA\u0219a cum sus\u021bin produc\u0103torii TimescaleDB, ace\u0219tia folosesc un algoritm mai corect pentru gestionarea interog\u0103rilor, \u00een special pentru inser\u021bii, care permite men\u021binerea unei performan\u021be aproape constante pe m\u0103sur\u0103 ce dimensiunea dataset-ului de inser\u021bii cre\u0219te. Adic\u0103 dup\u0103 200 de milioane de r\u00e2nduri, PostgreSQL \u00eencepe s\u0103 \u00eencetineasc\u0103 semnificativ \u0219i pierde performan\u021ba practic la zero, \u00een timp ce Timescale permite inserarea datelor c\u00e2t mai eficient, indiferent de cantitatea de date.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0219chin (Zabbix): performan\u021b\u0103 ridicat\u0103 \u0219i partajare nativ\u0103.\" src=\"\/wp-content\/uploads\/2020\/01\/a613d505a9dfe6008551ce981da7b24e.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Cum se instaleaz\u0103 TimescaleDB? Este simplu!<\/h3>\n<p>\nEste descris \u00een documenta\u021bie \u2013 poate fi instalat din pachete pentru orice... Depinde de pachetele oficiale PostgreSQL. Poate fi compilat manual. A\u0219a s-a \u00eent\u00e2mplat c\u0103 a trebuit s\u0103 compilez pentru baza de date.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0219chin (Zabbix): performan\u021b\u0103 ridicat\u0103 \u0219i partajare nativ\u0103.\" src=\"\/wp-content\/uploads\/2020\/01\/6767927fa92260103d318f9aa70ef5b3.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPe Zabbix, pur \u0219i simplu activ\u0103m extensia. Cred c\u0103 cei care au folosit extensia \u00een PostgreSQL... Pur \u0219i simplu activa\u021bi extensia, o crea\u021bi pentru baza de date Zabbix pe care o folosi\u021bi.<\/p>\n<p>\u0218i ultimul pas...<\/p>\n<h3>TimescaleDB. Migrarea tabelelor de istorie<\/h3>\n<p>\nTrebuie s\u0103 crea\u021bi o hypertable. Exist\u0103 o func\u021bie special\u0103 pentru asta \u2013 Create hypertable. Primul parametru indic\u0103 tabelul necesar \u00een aceast\u0103 baz\u0103 de date (pentru care trebuie creat\u0103 hipertabela).<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0219chin (Zabbix): performan\u021b\u0103 ridicat\u0103 \u0219i partajare nativ\u0103.\" src=\"\/wp-content\/uploads\/2020\/01\/47350f79fd9829c12685c1df8f0ff9a6.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nC\u00e2mpul pe care trebuie s\u0103-l crea\u021bi \u0219i chunk_time_interval (acesta este intervalul chunk-urilor (parti\u021biilor care trebuie utilizate). 86 400 \u2013 este o zi. <\/p>\n<p>Parametrul migrate_data: dac\u0103 \u00eel seta\u021bi pe true, va muta toate datele curente \u00een chunk-urile deja create.<\/p>\n<p>Eu am folosit migrate_data \u2013 dureaz\u0103 un timp considerabil, \u00een func\u021bie de dimensiunea bazei de date. Am avut peste un terabyte \u2013 crearea a durat mai mult de o or\u0103. \u00cen unele cazuri, \u00een timpul test\u0103rii, am \u0219ters datele istorice pentru text (history_text) \u0219i string (history_str), pentru a nu le muta \u2013 pentru c\u0103, de fapt, nu m-au interesat.<\/p>\n<p>\u0218i ultima actualizare o facem \u00een extensia noastr\u0103 db_extention: instal\u0103m timescaledb, astfel \u00eenc\u00e2t baza de date \u0219i, \u00een special, \u201eZabbix\u201d, s\u0103 \u00een\u021beleag\u0103 c\u0103 exist\u0103 o extensie db. Aceasta o activeaz\u0103 \u0219i folose\u0219te sintaxa \u0219i interog\u0103rile corecte c\u0103tre baza de date, folosind deja acele \u201efunc\u021bionalit\u0103\u021bi\u201d necesare pentru TimescaleDB.<\/p>\n<h3>Configurarea serverului<\/h3>\n<p>\nAm folosit dou\u0103 servere. Primul server este o ma\u0219in\u0103 virtual\u0103 destul de mic\u0103, cu 20 de procesoare \u0219i 16 gigabytes de memorie RAM. Am configurat pe ea \u201ePostgreSQL\u201d 10.8:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0219chin (Zabbix): performan\u021b\u0103 ridicat\u0103 \u0219i partajare nativ\u0103.\" src=\"\/wp-content\/uploads\/2020\/01\/990805374a2380a5c645c578404489bd.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSistemul de operare a fost Debian, sistemul de fi\u0219iere \u2013 xfs. Am realizat set\u0103ri minime pentru a utiliza aceast\u0103 baz\u0103 de date, \u00een afar\u0103 de ceea ce va folosi \u00eens\u0103\u0219i \u201eZabbix\u201d. Pe aceast\u0103 ma\u0219in\u0103 se afl\u0103 serverul \u201eZabbix\u201d, PostgreSQL \u0219i agen\u021bi de \u00eenc\u0103rcare.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0219chin (Zabbix): performan\u021b\u0103 ridicat\u0103 \u0219i partajare nativ\u0103.\" src=\"\/wp-content\/uploads\/2020\/01\/a6efa9ab9cd58f0061d04f13fe31018c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAm folosit 50 de agen\u021bi activi, care folosesc LoadableModule pentru a genera rapid rezultate variate. Ace\u0219tia au generat linii, numere \u0219i a\u0219a mai departe. Am umplut baza de date cu o cantitate mare de date. Ini\u021bial, configura\u021bia con\u021binea 5000 de elemente de date pentru fiecare host, iar aproximativ fiecare element de date con\u021binea un trigger \u2013 pentru a face ca aceasta s\u0103 fie o configura\u021bie real\u0103. Uneori, pentru a utiliza, chiar este necesar mai mult de un trigger.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0219chin (Zabbix): performan\u021b\u0103 ridicat\u0103 \u0219i partajare nativ\u0103.\" src=\"\/wp-content\/uploads\/2020\/01\/d5a3c306402e08bf2532eb6203a4aab4.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAm reglat intervalul de actualizare \u0219i \u00eenc\u0103rc\u0103tura folosind nu doar cei 50 de agen\u021bi (am ad\u0103ugat \u0219i altele), ci \u0219i prin elemente de date dinamice, reduc\u00e2nd intervalul de actualizare la 4 secunde.<\/p>\n<h3>Test de performan\u021b\u0103. PostgreSQL: 36 de mii de NVP-uri<\/h3>\n<p>\nPrima rulare, prima configura\u021bie a fost pe un PostgreSQL 10 curat pe acest hardware (35 de mii de valori pe secund\u0103). \u00cen general, a\u0219a cum se poate vedea pe ecran, inserarea datelor dureaz\u0103 frac\u021biuni de secund\u0103 \u2013 totul este bine \u0219i rapid, SSD-uri (200 gigabytes). Singurul lucru este c\u0103 20 GB se umplu destul de repede.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0219chin (Zabbix): performan\u021b\u0103 ridicat\u0103 \u0219i partajare nativ\u0103.\" src=\"\/wp-content\/uploads\/2020\/01\/6803a64fedd26093b9117a036d2993ae.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nVor fi destul de multe astfel de grafice. Acesta este dashboard-ul standard de performan\u021b\u0103 al serverului \u201eZabbix\u201d.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0219chin (Zabbix): performan\u021b\u0103 ridicat\u0103 \u0219i partajare nativ\u0103.\" src=\"\/wp-content\/uploads\/2020\/01\/081cc11c6bf42db3f8f16b6cc4e6ee0c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPrimul grafic \u2013 num\u0103rul de valori pe secund\u0103 (albastru, \u00een col\u021bul din st\u00e2nga sus), 35 de mii de valori \u00een acest caz. Acesta (\u00een partea de sus, la centru) este \u00eenc\u0103rcarea proceselor de colectare, iar aceasta (\u00een col\u021bul din dreapta sus) este \u00eenc\u0103rcarea proceselor interne: history syncers \u0219i housekeeper, care aici (\u00een partea de jos la centru) au fost executa\u021bi timp destul.<\/p>\n<p>Acest grafic (\u00een centrul de jos) arat\u0103 utilizarea ValueCache \u2013 c\u00e2te hituri ValueCache pentru declan\u0219atori (c\u00e2teva mii de valori pe secund\u0103). Un alt graf important este al patrulea (\u00een st\u00e2nga jos), care arat\u0103 utilizarea HistoryCache, despre care am vorbit, care este un buffer \u00eenainte de inser\u021bia \u00een Baz\u0103 de Date.<\/p>\n<h3>Test de performan\u021b\u0103. PostgreSQL: 50 de mii NVP-uri<\/h3>\n<p>\nApoi am crescut sarcina la 50 de mii de valori pe secund\u0103 pe aceea\u0219i ma\u0219in\u0103. La \u00eenc\u0103rcarea cu \u201eHousekeeper\u201d, 10 mii de valori erau deja scrise \u00een 2-3 secunde, inclusiv calculele. A\u0219a cum este ilustrat \u00een captura de ecran urm\u0103toare:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0219chin (Zabbix): performan\u021b\u0103 ridicat\u0103 \u0219i partajare nativ\u0103.\" src=\"\/wp-content\/uploads\/2020\/01\/80824da986dbee2f8d5ebe0ead4fbcfd.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n\u201eHousekeeper\u201d \u00eencepe deja s\u0103 interfereze cu func\u021bionarea, dar \u00een general, \u00eenc\u0103rcarea trapper-elor history-syncer este \u00een continuare la 60 % (al treilea grafic, \u00een dreapta sus). HistoryCache \u00eencepuse s\u0103 se umple activ chiar \u00een timpul utiliz\u0103rii \u201eHousekeeper\u201d-ului (\u00een st\u00e2nga jos). Era de aproximativ o jum\u0103tate de gigabyte, umplut cu 20%.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0219chin (Zabbix): performan\u021b\u0103 ridicat\u0103 \u0219i partajare nativ\u0103.\" src=\"\/wp-content\/uploads\/2020\/01\/9e1bcd4f3b9f3e8a1c9a36b2083ec61b.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Test de performan\u021b\u0103. PostgreSQL: 80 de mii NVP-uri<\/h3>\n<p>\nAm crescut apoi la 80 de mii de valori pe secund\u0103:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0219chin (Zabbix): performan\u021b\u0103 ridicat\u0103 \u0219i partajare nativ\u0103.\" src=\"\/wp-content\/uploads\/2020\/01\/13ae1589d6b9d35b4dda9c6c7d989cc2.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAsta a fost aproximativ 400 de mii de elemente de date, 280 de mii de declan\u0219atori. Inser\u021bia, a\u0219a cum pute\u021bi vedea, a dus la o \u00eenc\u0103rcare considerabil\u0103 a history-syncer-elor (erau 30). Apoi am crescut diferite parametere: history-syncer-ii, cache-ul\u2026 Pe aceast\u0103 ma\u0219in\u0103, \u00eenc\u0103rcarea history-syncer-ilor a \u00eenceput s\u0103 creasc\u0103 la maxim, practic, \u201e\u00een raft\u201d \u2013 astfel, HistoryCache a intrat \u00eentr-o \u00eenc\u0103rcare foarte mare:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0219chin (Zabbix): performan\u021b\u0103 ridicat\u0103 \u0219i partajare nativ\u0103.\" src=\"\/wp-content\/uploads\/2020\/01\/0ec528256c8fa7b16e1c7c95c8119535.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n\u00cen tot acest timp am observat toate parametrii sistemului (cum este utilizat procesorul, memoria RAM) \u0219i am descoperit c\u0103 utilizarea discurilor era la maximum \u2013 am atingea capacitatea maxim\u0103 a acestui disc pe aceast\u0103 ma\u0219in\u0103, pe aceast\u0103 ma\u0219in\u0103 virtual\u0103. \u201ePostgres\u201d a \u00eenceput s\u0103 elimine date activ la o astfel de intensitate \u0219i discul deja nu mai reu\u0219ea s\u0103 scrie, s\u0103 citeasc\u0103\u2026<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0219chin (Zabbix): performan\u021b\u0103 ridicat\u0103 \u0219i partajare nativ\u0103.\" src=\"\/wp-content\/uploads\/2020\/01\/0809dbd7638e7ee003ea24c611984a0c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAm luat un alt server, care avea deja 48 de procesoare \u0219i 128 de gigabyte de memorie RAM:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0219chin (Zabbix): performan\u021b\u0103 ridicat\u0103 \u0219i partajare nativ\u0103.\" src=\"\/wp-content\/uploads\/2020\/01\/53410b502a4574aac5d40f1a2a6d3f42.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDe asemenea, l-am \u201etunat\u201d \u2013 am instalat History syncer (60 de buc\u0103\u021bi) \u0219i am ob\u021binut o performan\u021b\u0103 acceptabil\u0103. Practic nu suntem \u201e\u00een raft\u201d, dar probabil c\u0103 aceasta este limita de performan\u021b\u0103, unde este necesar s\u0103 \u00eentreprindem ceva.<\/p>\n<h3>Test de performan\u021b\u0103. TimescaleDB: 80 de mii NVP-uri<\/h3>\n<p>\nAm avut ca obiectiv principal utilizarea TimescaleDB. Pe fiecare grafic se observ\u0103 o c\u0103dere:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0219chin (Zabbix): performan\u021b\u0103 ridicat\u0103 \u0219i partajare nativ\u0103.\" src=\"\/wp-content\/uploads\/2020\/01\/b0064068895a34b93b5aa6771aba05cb.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAceste e\u0219u\u0103ri sunt, de fapt, migrarea datelor. Dup\u0103 aceasta, \u00een serverul \u201eZabbix\u201d, profilul de \u00eenc\u0103rcare a istoriei sincronizatoarelor, dup\u0103 cum vede\u021bi, s-a schimbat semnificativ. Acesta permite practic inserarea datelor de aproape trei ori mai repede \u0219i folose\u0219te mai pu\u021bin HistoryCache \u2013 \u00een consecin\u021b\u0103, datele vor fi livrate la timp. Din nou, 80 de mii de valori pe secund\u0103 este o rat\u0103 destul de ridicat\u0103 (desigur, nu pentru \u201eYandex\u201d). \u00cen general, acesta este un setup destul de mare, cu un singur server.<\/p>\n<h3>Test de performan\u021b\u0103 PostgreSQL: 120 de mii de NVP-uri<\/h3>\n<p>\nApoi, am crescut valoarea num\u0103rului de elemente de date la o jum\u0103tate de milion \u0219i am ob\u021binut o valoare estimat\u0103 de 125 de mii pe secund\u0103:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0219chin (Zabbix): performan\u021b\u0103 ridicat\u0103 \u0219i partajare nativ\u0103.\" src=\"\/wp-content\/uploads\/2020\/01\/7d0cf2ef7c6691c1bbf4b90afd34e4bb.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n\u0218i am ob\u021binut graficele astfel:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0219chin (Zabbix): performan\u021b\u0103 ridicat\u0103 \u0219i partajare nativ\u0103.\" src=\"\/wp-content\/uploads\/2020\/01\/9c09333a50e016921a8a5b70e00397a1.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n\u00cen principiu, acesta este un setup func\u021bional, poate opera pentru o perioad\u0103 destul de lung\u0103. Dar, deoarece aveam un disc de doar 1,5 terabyte, l-am consumat \u00een c\u00e2teva zile. Cel mai important este c\u0103, \u00een acela\u0219i timp, s-au creat noi parti\u021bii \u00een TimescaleDB, iar acest lucru, pentru performan\u021b\u0103, a trecut complet neobservat, spre deosebire de MySQL.<\/p>\n<p>De obicei, parti\u021biile sunt create noaptea, deoarece acest lucru blocheaz\u0103 complet inser\u021bia \u0219i lucrul cu tabelele, put\u00e2nd duce la degradarea serviciului. \u00cen acest caz, acest lucru nu s-a \u00eent\u00e2mplat! Principala sarcin\u0103 a fost s\u0103 verific\u0103m capacit\u0103\u021bile TimescaleDB. Rezultatul ob\u021binut a fost: 120 de mii de valori pe secund\u0103.<\/p>\n<p>Exist\u0103, de asemenea, exemple \u00een \u201ecomunitate\u201d:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0219chin (Zabbix): performan\u021b\u0103 ridicat\u0103 \u0219i partajare nativ\u0103.\" src=\"\/wp-content\/uploads\/2020\/01\/66aa6b1d4c559d12082e4d91b6a1ca10.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nO persoan\u0103 a activat \u0219i TimescaleDB \u0219i utilizarea io.weight a sc\u0103zut pe procesor; iar utilizarea elementelor proceselor interne a sc\u0103zut, de asemenea, datorit\u0103 activ\u0103rii TimescaleDB. De altfel, acestea sunt discuri obi\u0219nuite, adic\u0103 o ma\u0219in\u0103 virtual\u0103 pe discuri normale (nu SSD)!<\/p>\n<p>Pentru anumite setup-uri mici, care se confrunt\u0103 cu performan\u021ba discului, TimescaleDB, dup\u0103 p\u0103rerea mea, este o solu\u021bie foarte bun\u0103. Aceasta va permite s\u0103 continui s\u0103 lucrezi p\u00e2n\u0103 c\u00e2nd vei migra pe hardware mai rapid pentru baza de date.<\/p>\n<p>V\u0103 invit pe to\u021bi la evenimentele noastre: Conferin\u021ba \u2013 \u00een Moscova, Summit \u2013 \u00een Riga. Folosi\u021bi canalele noastre \u2013 \u201eTelegram\u201d, forum, IRC. Dac\u0103 ave\u021bi \u00eentreb\u0103ri \u2013 veni\u021bi la noi la stand, putem vorbi despre tot.<\/p>\n<h3>\u00centreb\u0103rile audien\u021bei<\/h3>\n<p>\n\u00centrebare din audien\u021b\u0103 (\u00een continuare \u2013 A): \u2013 Dac\u0103 TimescaleDB este at\u00e2t de simplu de configurat \u0219i ofer\u0103 un astfel de impuls de performan\u021b\u0103, atunci, poate, ar trebui utilizat ca cea mai bun\u0103 practic\u0103 pentru configurarea \u201eZabbix\u201d cu \u201ePostgres\u201d? \u0218i exist\u0103 vreo capcan\u0103 sau dezavantaj al acestei solu\u021bii, sau totu\u0219i, dac\u0103 am decis s\u0103 fac \u201eZabbix\u201d, pot lua lini\u0219tit \u201ePostgres\u201d, s\u0103 instalez deodat\u0103 \u201eTimescale\u201d \u0219i s\u0103 folosesc f\u0103r\u0103 a m\u0103 g\u00e2ndi la probleme?<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0219chin (Zabbix): performan\u021b\u0103 ridicat\u0103 \u0219i partajare nativ\u0103.\" src=\"\/wp-content\/uploads\/2020\/01\/314845a019724806283a957b15d857cc.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>AG:<\/b> \u2013 Da, a\u0219 spune c\u0103 este o recomandare bun\u0103: s\u0103 folose\u0219ti \u201ePostgres\u201d direct cu extensia TimescaleDB. A\u0219a cum am spus, exist\u0103 multe recenzii pozitive, \u00een ciuda faptului c\u0103 aceast\u0103 \u201ecaracteristic\u0103\u201d este experimental\u0103. Dar, de fapt, testele arat\u0103 c\u0103 este o solu\u021bie excelent\u0103 (cu TimescaleDB), \u0219i cred c\u0103 va continua s\u0103 evolueze! Urm\u0103rim cum se dezvolt\u0103 aceast\u0103 extensie \u0219i vom corecta ce trebuie.<\/p>\n<p>Chiar \u0219i \u00een timpul dezvolt\u0103rii ne-am bazat pe una dintre cele mai cunoscute \u201ecaracteristici\u201d: acolo puteai lucra pu\u021bin diferit cu buc\u0103\u021bile. Dar apoi au eliminat asta \u00een urm\u0103toarea versiune \u0219i a trebuit s\u0103 nu ne mai baz\u0103m pe acel cod. A\u0219 recomanda utilizarea acestei solu\u021bii \u00een multe set\u0103ri. Dac\u0103 folose\u0219ti MySQL\u2026 pentru set\u0103rile medii, orice solu\u021bie func\u021bioneaz\u0103 destul de bine.<\/p>\n<p><b>A:<\/b> \u2013 \u00cen ultimele grafice, care provin de la comunitate, a fost un grafic cu \u201eHousekeeper\u201d:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0219chin (Zabbix): performan\u021b\u0103 ridicat\u0103 \u0219i partajare nativ\u0103.\" src=\"\/wp-content\/uploads\/2020\/01\/d01549b6b9b97d8bdf5372efe05d9039.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nA continuat s\u0103 func\u021bioneze. Ce face \u201eHousekeeper\u201d \u00een cazul TimescaleDB?<\/p>\n<p><b>AG:<\/b> \u2013 Acum nu pot spune cu exactitate \u2013 voi verifica codul \u0219i voi oferi detalii suplimentare. Folose\u0219te interog\u0103ri specifice TimescaleDB nu pentru eliminarea buc\u0103\u021bilor, ci cumva pentru agregare. P\u00e2n\u0103 atunci, nu sunt preg\u0103tit s\u0103 r\u0103spund la aceast\u0103 \u00eentrebare tehnic\u0103. O s\u0103 clarific\u0103m ast\u0103zi sau m\u00e2ine la stand.<\/p>\n<p><b>A:<\/b> \u2013 Am o \u00eentrebare similar\u0103 \u2013 despre performan\u021ba opera\u021biunii de eliminare \u00een \u201eTimescale\u201d.<br \/>\nA (r\u0103spuns din audien\u021b\u0103): \u2013 C\u00e2nd elimini date dintr-un tabel, dac\u0103 faci asta prin delete, atunci trebuie s\u0103 parcurgi tabelul \u2013 s\u0103 \u0219tergi, s\u0103 cure\u021bi, s\u0103 marchezi totul pentru un viitor vacuum. \u00cen \u201eTimescale\u201d, av\u00e2nd buc\u0103\u021bi, po\u021bi s\u0103 le \u0219tergi. \u00cen termeni practici, \u00eei spui pur \u0219i simplu fi\u0219ierului care se afl\u0103 \u00een big data: \u201e\u0218terge!\u201d<\/p>\n<p>\u00abTimescale\u00bb \u00een\u021belege pur \u0219i simplu c\u0103 acel chunk nu mai exist\u0103. \u0218i cum se integreaz\u0103 \u00een planificatorul de cereri, prinde condi\u021biile tale din select sau din alte opera\u021bii \u0219i \u00een\u021belege imediat c\u0103 acel chunk nu mai este - \u201eNu m\u0103 voi duce acolo din nou!\u201d (datele sunt absente). \u0218i asta e tot! Asta \u00eenseamn\u0103 c\u0103 scanarea tabelului este \u00eenlocuit\u0103 de \u0219tergerea fi\u0219ierului binar, deci este rapid.<\/p>\n<p><b>A:<\/b> \u2013 Am abordat deja subiectul non-SQL. Din c\u00e2te \u00een\u021beleg, \u201eZabbix\u201d nu are nevoie foarte mult s\u0103 modifice datele, ci totul este mai mult un fel de log. Se pot folosi baze de date specializate care nu pot schimba datele, dar care salveaz\u0103, acumuleaz\u0103, ofer\u0103 date mult mai repede \u2013 Clickhouse, de exemplu, ceva asem\u0103n\u0103tor cu Kafka?.. Kafka este totu\u0219i tot un log! Se pot integra cumva?<\/p>\n<p><b>AG:<\/b> \u2013 Se poate face exportul. Avem o anumit\u0103 \u201efunc\u021bionalitate\u201d din versiunea 3.4: po\u021bi scrie \u00een fi\u0219iere toate fi\u0219ierele istorice, evenimentele, tot ce exist\u0103; \u0219i apoi, cu un anumit procesor, trimite c\u0103tre orice alt\u0103 baz\u0103 de date. De fapt, mul\u021bi reconfigureaz\u0103 \u0219i scriu direct \u00een baza de date. Istoricul e scris \u00een fi\u0219iere, se rotesc aceste fi\u0219iere \u0219i a\u0219a mai departe, iar acest lucru poate fi transferat \u00een \u201eClickhouse\u201d. Nu pot spune nimic despre planuri, dar, posibil, suportul pentru solu\u021biile NoSQL (precum \u201eClickhouse\u201d) va continua.<\/p>\n<p><b>A:<\/b> \u2013 Deci, se pare c\u0103 se poate sc\u0103pa complet de Postgres?<\/p>\n<p><b>AG:<\/b> \u2013 Desigur, cea mai complicat\u0103 parte \u00een \u201eZabbix\u201d sunt tabelele istorice, care creeaz\u0103 cele mai multe probleme, \u0219i evenimentele. \u00cen acest caz, dac\u0103 nu p\u0103strezi evenimentele pentru mult timp \u0219i p\u0103strezi istoricul cu tendin\u021be \u00eentr-un alt depozit rapid, atunci \u00een general nu ar trebui s\u0103 fie probleme.<\/p>\n<p><b>A:<\/b> \u2013 Po\u021bi evalua c\u00e2t de mult mai repede va func\u021biona totul dac\u0103 trecem la \u201eClickhouse\u201d, de exemplu?<\/p>\n<p><b>AG:<\/b> \u2013 Nu am testat. Cred c\u0103, m\u0103car acelea\u0219i cifre pot fi atinse destul de u\u0219or, av\u00e2nd \u00een vedere c\u0103 \u201eClickhouse\u201d are propriul s\u0103u interfa\u021b\u0103, dar nu pot spune cu certitudine. Ar fi mai bine s\u0103 test\u0103m. Totul depinde de configura\u021bie: c\u00e2te hosturi ai \u0219i a\u0219a mai departe. Inserarea este una, dar trebuie s\u0103 retragi aceste date \u2013 cu Grafana sau altceva.<\/p>\n<p><b>A:<\/b> \u2013 Deci, se vorbe\u0219te despre o competi\u021bie echilibrat\u0103, nu despre un avantaj mare al acestor baze de date rapide?<\/p>\n<p><b>AG:<\/b> \u2013 Cred c\u0103, atunci c\u00e2nd integr\u0103m, vom avea teste mai precise.<\/p>\n<p><b>A:<\/b> \u2013 Unde a disp\u0103rut vechiul \u0219i bunul RRD? Ce a determinat trecerea la bazele de date SQL? Ini\u021bial, toate metricile erau colectate pe RRD.<\/p>\n<p><b>AG:<\/b> \u2013 \u00cen \u00abZabbix\u00bb, RRD a existat, poate, \u00eentr-o versiune foarte veche. Au existat \u00eentotdeauna baze de date SQL \u2013 abordarea clasic\u0103. Abordarea clasic\u0103 este MySQL, PostgreSQL (exist\u0103 de foarte mult timp). Noi avem o interfa\u021b\u0103 comun\u0103 pentru bazele de date SQL \u0219i RRD, pe care practic nu am folosit-o niciodat\u0103.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrei Gu\u0219chin (Zabbix): performan\u021b\u0103 ridicat\u0103 \u0219i partajare nativ\u0103.\" src=\"\/wp-content\/uploads\/2020\/01\/ac5f02494c63983601cc09c0b22e722b.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<center><div class=\"youtube-placeholder\" data-id=\"umRk94j5M8o\" onclick=\"loadVideo(this)\">\r\n        <img decoding=\"async\" src=\"https:\/\/img.youtube.com\/vi\/umRk94j5M8o\/hqdefault.jpg\" alt=\"Reda\u021bi video\" loading=\"lazy\" width=\"480\" height=\"360\" style=\"width:100%;height:auto;\">\r\n        <div class=\"play-button\"><\/div>\r\n    <\/div><\/center><\/p>\n<h3>Pu\u021bin publicitate \ud83d\ude42<\/h3>\n<p>\nMul\u021bumim c\u0103 r\u0103m\u00e2ne\u021bi cu noi. V\u0103 plac articolele noastre? Dori\u021bi s\u0103 vede\u021bi mai multe materiale interesante? Sus\u021bine\u021bi-ne, efectu\u00e2nd o comand\u0103 sau recomand\u00e2ndu-ne prietenilor, <noindex><a rel=\"nofollow\" href=\"https:\/\/ua-hosting.company\/cloudvps\/nl\">VPS cloud pentru dezvoltatori de la 4,99 $<\/a><\/noindex>, <b>un echivalent unic pentru serverele entry-level, care a fost creat de noi pentru voi:<\/b> <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/company\/ua-hosting\/blog\/347386\/\">Toat\u0103 adev\u0103rul despre VPS (KVM) E5-2697 v3 (6 nuclee) 10GB DDR4 480GB SSD 1Gbps de la 19 $ sau cum s\u0103 \u00eemp\u0103r\u021bi\u021bi corect un server?<\/a><\/noindex> (sunt disponibile op\u021biuni cu RAID1 \u0219i RAID10, p\u00e2n\u0103 la 24 nuclee \u0219i p\u00e2n\u0103 la 40GB DDR4).<\/p>\n<p><b>Dell R730xd la jum\u0103tate de pre\u021b \u00een centrul de date Equinix Tier IV din Amsterdam?<\/b> Numai la noi <b><noindex><a rel=\"nofollow\" href=\"https:\/\/ua-hosting.company\/serversnl\">2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TB de la 199 $<\/a><\/noindex> \u00een Olanda! <b>Dell R420 \u2014 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB \u2014 de la 99 $!<\/b><\/b> Citi\u021bi despre <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/company\/ua-hosting\/blog\/329618\/\">Cum s\u0103 construi\u021bi o infrastructur\u0103 de clas\u0103 enterprise folosind servere Dell R730xd E5-2650 v4 la pre\u021buri foarte mici de 9000 \u20ac?<\/a><\/noindex><br \/>\n<br \/>Sursa: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/ua-hosting\/blog\/485470\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041c\u044b \u0440\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0438\u043c \u0440\u0430\u0431\u043e\u0442\u0443 Zabbix \u0441 \u0431\u0430\u0437\u043e\u0439 \u0434\u0430\u043d\u043d\u044b\u0445 TimescaleDB \u0432 \u043a\u0430\u0447\u0435\u0441\u0442\u0432\u0435 backend. \u041f\u043e\u043a\u0430\u0436\u0435\u043c, \u043a\u0430\u043a \u0437\u0430\u043f\u0443\u0441\u0442\u0438\u0442\u044c \u0441 \u043d\u0443\u043b\u044f \u0438 \u043a\u0430\u043a \u043c\u0438\u0433\u0440\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u0441 PostgreSQL. \u0422\u0430\u043a\u0436\u0435 \u043f\u0440\u0438\u0432\u0435\u0434\u0435\u043c \u0441\u0440\u0430\u0432\u043d\u0438\u0442\u0435\u043b\u044c\u043d\u044b\u0435 \u0442\u0435\u0441\u0442\u044b \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u0438 \u0434\u0432\u0443\u0445 \u043a\u043e\u043d\u0444\u0438\u0433\u0443\u0440\u0430\u0446\u0438\u0439. HighLoad++ Siberia 2019. \u0417\u0430\u043b \u00ab\u0422\u043e\u043c\u0441\u043a\u00bb. 24 \u0438\u044e\u043d\u044f, 16:00. \u0422\u0435\u0437\u0438\u0441\u044b \u0438 \u043f\u0440\u0435\u0437\u0435\u043d\u0442\u0430\u0446\u0438\u044f. \u0421\u043b\u0435\u0434\u0443\u044e\u0449\u0430\u044f \u043a\u043e\u043d\u0444\u0435\u0440\u0435\u043d\u0446\u0438\u044f HighLoad++ \u043f\u0440\u043e\u0439\u0434\u0435\u0442 6 \u0438 7 \u0430\u043f\u0440\u0435\u043b\u044f 2020 \u0433\u043e\u0434\u0430 \u0432 \u0421\u0430\u043d\u043a\u0442-\u041f\u0435\u0442\u0435\u0440\u0431\u0443\u0440\u0433\u0435. \u041f\u043e\u0434\u0440\u043e\u0431\u043d\u043e\u0441\u0442\u0438 \u0438 \u0431\u0438\u043b\u0435\u0442\u044b \u043f\u043e [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-55734","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.2.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041c\u044b \u0440\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0438\u043c \u0440\u0430\u0431\u043e\u0442\u0443 Zabbix \u0441 \u0431\u0430\u0437\u043e\u0439 \u0434\u0430\u043d\u043d\u044b\u0445 TimescaleDB \u0432 \u043a\u0430\u0447\u0435\u0441\u0442\u0432\u0435 backend. \u041f\u043e\u043a\u0430\u0436\u0435\u043c, \u043a\u0430\u043a \u0437\u0430\u043f\u0443\u0441\u0442\u0438\u0442\u044c \u0441 \u043d\u0443\u043b\u044f \u0438 \u043a\u0430\u043a \u043c\u0438\u0433\u0440\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u0441 PostgreSQL.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/highload-andrej-gushhin-zabbix-vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"ro_RO\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47HighLoad++, \u0410\u043d\u0434\u0440\u0435\u0439 \u0413\u0443\u0449\u0438\u043d (Zabbix): \u0432\u044b\u0441\u043e\u043a\u0430\u044f \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u044c \u0438 \u043d\u0430\u0442\u0438\u0432\u043d\u043e\u0435 \u043f\u0430\u0440\u0442\u0438\u0446\u0438\u043e\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041c\u044b \u0440\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0438\u043c \u0440\u0430\u0431\u043e\u0442\u0443 Zabbix \u0441 \u0431\u0430\u0437\u043e\u0439 \u0434\u0430\u043d\u043d\u044b\u0445 TimescaleDB \u0432 \u043a\u0430\u0447\u0435\u0441\u0442\u0432\u0435 backend. \u041f\u043e\u043a\u0430\u0436\u0435\u043c, \u043a\u0430\u043a \u0437\u0430\u043f\u0443\u0441\u0442\u0438\u0442\u044c \u0441 \u043d\u0443\u043b\u044f \u0438 \u043a\u0430\u043a \u043c\u0438\u0433\u0440\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u0441 PostgreSQL.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/highload-andrej-gushhin-zabbix-vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-01-26T21:00:00+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-02-18T11:03:52+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47HighLoad++, Andrei Gu\u0219in (Zabbix): performan\u021b\u0103 ridicat\u0103 \u0219i parti\u021bionare nativ\u0103 | ProHoster","description":"Vom analiza modul \u00een care Zabbix func\u021bioneaz\u0103 cu baza de date TimescaleDB ca backend. Vom ar\u0103ta cum s\u0103 pornim de la zero \u0219i cum s\u0103 migr\u0103m de la PostgreSQL.","canonical_url":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/highload-andrej-gushhin-zabbix-vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"ro_RO","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47HighLoad++, \u0410\u043d\u0434\u0440\u0435\u0439 \u0413\u0443\u0449\u0438\u043d (Zabbix): \u0432\u044b\u0441\u043e\u043a\u0430\u044f \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u044c \u0438 \u043d\u0430\u0442\u0438\u0432\u043d\u043e\u0435 \u043f\u0430\u0440\u0442\u0438\u0446\u0438\u043e\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 | ProHoster","og:description":"\u041c\u044b \u0440\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0438\u043c \u0440\u0430\u0431\u043e\u0442\u0443 Zabbix \u0441 \u0431\u0430\u0437\u043e\u0439 \u0434\u0430\u043d\u043d\u044b\u0445 TimescaleDB \u0432 \u043a\u0430\u0447\u0435\u0441\u0442\u0432\u0435 backend. \u041f\u043e\u043a\u0430\u0436\u0435\u043c, \u043a\u0430\u043a \u0437\u0430\u043f\u0443\u0441\u0442\u0438\u0442\u044c \u0441 \u043d\u0443\u043b\u044f \u0438 \u043a\u0430\u043a \u043c\u0438\u0433\u0440\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u0441 PostgreSQL.","og:url":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/highload-andrej-gushhin-zabbix-vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-01-26T21:00:00+00:00","article:modified_time":"2020-02-18T11:03:52+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"55734","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 19:37:39","updated":"2022-09-28 01:51:35","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts\/55734","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/comments?post=55734"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts\/55734\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/media?parent=55734"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/categories?post=55734"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/tags?post=55734"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}