{"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\/pl\/blog\/administrirovanie\/highload-andrej-gushhin-zabbix-vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie","title":{"rendered":"HighLoad++, Andrey Gushchin (Zabbix): wysoka wydajno\u015b\u0107 i natywne partycjonowanie","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Om\u00f3wimy prac\u0119 Zabbix z baz\u0105 danych TimescaleDB jako backendem. Poka\u017cemy, jak uruchomi\u0107 od podstaw oraz jak migrowa\u0107 z PostgreSQL. Przedstawimy tak\u017ce por\u00f3wnawcze testy wydajno\u015bci dw\u00f3ch konfiguracji.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): wysoka wydajno\u015b\u0107 i natywne partycjonowanie\" src=\"\/wp-content\/uploads\/2020\/01\/fb4f7ea4585b6dcdafec9d0d1e3a71e4.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHighLoad++ Syberia 2019. Sala \u201eTomsk\u201d. 24 czerwca, 16:00. Tezy oraz <noindex><a rel=\"nofollow\" href=\"https:\/\/www.highload.ru\/siberia\/2019\/abstracts\/5390\">prezentacja<\/a><\/noindex>. Nast\u0119pna konferencja HighLoad++ odb\u0119dzie si\u0119 6 i 7 kwietnia 2020 roku w Petersburgu. Szczeg\u00f3\u0142y i bilety <noindex><a rel=\"nofollow\" href=\"http:\/\/bit.ly\/2sSxgBx\">pod tym linkiem<\/a><\/noindex>.<\/p>\n<p><b>Andriej Gu\u015bcin (dalej \u2013 AG):<\/b> \u2013 Jestem in\u017cynierem wsparcia technicznego ZABBIX (dalej \u2013 \u201eZabbix\u201d), szkoleniowcem. Pracuj\u0119 od ponad 6 lat w wsparciu technicznym i bezpo\u015brednio zajmowa\u0142em si\u0119 wydajno\u015bci\u0105. Dzi\u015b opowiem o wydajno\u015bci, jak\u0105 mo\u017ce zapewni\u0107 TimescaleDB, w por\u00f3wnaniu do zwyk\u0142ego PostgreSQL 10. B\u0119dzie te\u017c kr\u00f3tki wst\u0119p o tym, jak to wszystko dzia\u0142a.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h3>G\u0142\u00f3wne wyzwania wydajno\u015bci: od zbierania do czyszczenia danych<\/h3>\n<p>\nZacznijmy od tego, \u017ce istniej\u0105 okre\u015blone wyzwania wydajno\u015bci, z kt\u00f3rymi boryka si\u0119 ka\u017cdy system monitorowania. Pierwszym wyzwaniem wydajno\u015bci jest szybkie zbieranie i przetwarzanie danych.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): wysoka wydajno\u015b\u0107 i natywne partycjonowanie\" src=\"\/wp-content\/uploads\/2020\/01\/a2cb78b549a55c3b59d7fcdb8b8865b3.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDobry system monitorowania powinien szybko i terminowo zbiera\u0107 wszystkie dane, przetwarza\u0107 je zgodnie z wyra\u017ceniami wyzwalaj\u0105cymi, czyli przetwarza\u0107 wed\u0142ug jakich\u015b kryteri\u00f3w (w r\u00f3\u017cnych systemach jest to r\u00f3\u017cnie) i zapisywa\u0107 w bazie danych, aby p\u00f3\u017aniej m\u00f3c te dane wykorzysta\u0107.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): wysoka wydajno\u015b\u0107 i natywne partycjonowanie\" src=\"\/wp-content\/uploads\/2020\/01\/a3ce55c3aec3eb93948150684838a5b3.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDrugim wyzwaniem wydajno\u015bci jest przechowywanie historii. Nale\u017cy przechowywa\u0107 w bazie danych cz\u0119sto i mie\u0107 szybki oraz wygodny dost\u0119p do tych metryk, kt\u00f3re zosta\u0142y zebrane w okre\u015blonym okresie czasu. Najwa\u017cniejsze, aby te dane by\u0142o wygodnie uzyska\u0107, wykorzysta\u0107 je w raportach, wykresach, wyzwalaczach, w pewnych warto\u015bciach progowych, do powiadomie\u0144 itd.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): wysoka wydajno\u015b\u0107 i natywne partycjonowanie\" src=\"\/wp-content\/uploads\/2020\/01\/325363d79f0270d620f956eeb8ab3402.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nTrzecim wyzwaniem wydajno\u015bci jest czyszczenie historii, co oznacza, \u017ce nadchodzi taki dzie\u0144, kiedy nie trzeba ju\u017c przechowywa\u0107 szczeg\u00f3\u0142owych metryk, kt\u00f3re by\u0142y zbierane przez 5 lat (nawet przez miesi\u0105ce lub dwa). Niekt\u00f3re w\u0119z\u0142y sieci zosta\u0142y usuni\u0119te, albo jakie\u015b hosty, a metryki ju\u017c nie s\u0105 potrzebne poniewa\u017c sta\u0142y si\u0119 nieaktualne i przesta\u0142y by\u0107 zbierane. To wszystko trzeba wyczy\u015bci\u0107, aby baza danych nie rozros\u0142a si\u0119 do du\u017cych rozmiar\u00f3w. Og\u00f3lnie rzecz bior\u0105c, czyszczenie historii najcz\u0119\u015bciej stanowi powa\u017cne wyzwanie dla przechowywania \u2013 cz\u0119sto ma to silny wp\u0142yw na wydajno\u015b\u0107.<\/p>\n<h3>Jak rozwi\u0105za\u0107 problemy z cachowaniem?<\/h3>\n<p>\nTeraz b\u0119d\u0119 m\u00f3wi\u0107 konkretnie o \u201eZabbixie\u201d. W \u201eZabbixie\u201d pierwszy i drugi wywo\u0142ania s\u0105 rozwi\u0105zywane za pomoc\u0105 cachowania.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): wysoka wydajno\u015b\u0107 i natywne partycjonowanie\" src=\"\/wp-content\/uploads\/2020\/01\/d5510b31553ee8e63a0c240789d51622.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nZbieranie i przetwarzanie danych \u2013 u\u017cywamy pami\u0119ci podr\u0119cznej do przechowywania wszystkich tych danych. O tych danych b\u0119dzie teraz mowa szczeg\u00f3\u0142owo.<\/p>\n<p>Na stronie bazy danych r\u00f3wnie\u017c istnieje pewne cachowanie dla g\u0142\u00f3wnych zapyta\u0144 \u2013 dla wykres\u00f3w i innych element\u00f3w.<\/p>\n<p>Cachowanie po stronie samego serwera Zabbix: mamy ConfigurationCache, ValueCache, HistoryCache, TrendsCache. Czym to jest?<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): wysoka wydajno\u015b\u0107 i natywne partycjonowanie\" src=\"\/wp-content\/uploads\/2020\/01\/241a131145eccd280a7411c43b2cdce4.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nConfigurationCache \u2013 to g\u0142\u00f3wny cache, w kt\u00f3rym przechowujemy metryki, hosty, elementy danych, wyzwalacze; wszystko, co jest potrzebne do przetwarzania wst\u0119pnego, zbierania danych, z jakich host\u00f3w zbiera\u0107 oraz z jak\u0105 cz\u0119stotliwo\u015bci\u0105. Wszystko to jest przechowywane w ConfigurationCache, aby nie wchodzi\u0107 do bazy danych ani nie tworzy\u0107 zb\u0119dnych zapyta\u0144. Po uruchomieniu serwera aktualizujemy ten cache (tworzymy) i okresowo go aktualizujemy (w zale\u017cno\u015bci od ustawie\u0144 konfiguracyjnych).<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): wysoka wydajno\u015b\u0107 i natywne partycjonowanie\" src=\"\/wp-content\/uploads\/2020\/01\/474ac0db2e46aa945a0da62197f72987.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Cachowanie w Zabbixie. Zbieranie danych.<\/h3>\n<p>\nTutaj schemat jest do\u015b\u0107 du\u017cy:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): wysoka wydajno\u015b\u0107 i natywne partycjonowanie\" src=\"\/wp-content\/uploads\/2020\/01\/a6ad9dbd5deebac5440433a47c693fcf.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nG\u0142\u00f3wne elementy w schemacie \u2013 to te zbieracze:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): wysoka wydajno\u015b\u0107 i natywne partycjonowanie\" src=\"\/wp-content\/uploads\/2020\/01\/feb932586302e2284bd44595caf9ee1b.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nTo same procesy zbierania, r\u00f3\u017cne \u201epollery\u201d, kt\u00f3re odpowiadaj\u0105 za r\u00f3\u017cne rodzaje zbierania. Zbieraj\u0105 dane po icmp, ipmi, r\u00f3\u017cnymi protoko\u0142ami i przekazuj\u0105 je do przetwarzania wst\u0119pnego.<\/p>\n<h3>PreProcessing HistoryCache<\/h3>\n<p>\nJe\u015bli mamy obliczane elementy danych (ci, kt\u00f3rzy znaj\u0105 \u201eZabbixa\u201d \u2013 wiedz\u0105), to s\u0105 obliczane, agregacyjne elementy danych \u2013 pobieramy je bezpo\u015brednio z ValueCache. O tym, jak on jest wype\u0142niany, opowiem p\u00f3\u017aniej. Wszystkie te zbieracze u\u017cywaj\u0105 ConfigurationCache do uzyskania swoich zada\u0144 i nast\u0119pnie przekazuj\u0105 je do przetwarzania wst\u0119pnego.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): wysoka wydajno\u015b\u0107 i natywne partycjonowanie\" src=\"\/wp-content\/uploads\/2020\/01\/3948ee1167c52856949c25e2043be974.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPrzetwarzanie wst\u0119pne r\u00f3wnie\u017c korzysta z ConfigurationCache do uzyskania krok\u00f3w przetwarzania wst\u0119pnego, przetwarza te dane na r\u00f3\u017cne sposoby. Pocz\u0105wszy od wersji 4.2, zosta\u0142o to przeniesione na proxy. To bardzo wygodne, poniewa\u017c samo przetwarzanie wst\u0119pne to do\u015b\u0107 ci\u0119\u017cka operacja. Je\u015bli masz bardzo du\u017cego \u201eZabbixa\u201d, z du\u017c\u0105 ilo\u015bci\u0105 element\u00f3w danych i wysok\u0105 cz\u0119stotliwo\u015bci\u0105 zbierania, to znacznie u\u0142atwia prac\u0119.<\/p>\n<p>W zwi\u0105zku z tym, po tym jak w jaki\u015b spos\u00f3b przetworzyli\u015bmy te dane za pomoc\u0105 przetwarzania wst\u0119pnego, zapisujemy je w HistoryCache, aby je dalej przetwarza\u0107. Na tym ko\u0144czy si\u0119 zbieranie danych. Przechodzimy do g\u0142\u00f3wnego procesu.<\/p>\n<h3>Praca History syncer<\/h3>\n<p>\n<img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): wysoka wydajno\u015b\u0107 i natywne partycjonowanie\" src=\"\/wp-content\/uploads\/2020\/01\/66539e4184d041ed84f797080226ba24.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nG\u0142\u00f3wny proces w \"Zabbixie\" (poniewa\u017c jest to architektura monolityczna) \u2013 History syncer. To g\u0142\u00f3wny proces, kt\u00f3ry zajmuje si\u0119 atomow\u0105 obr\u00f3bk\u0105 ka\u017cdego elementu danych, to znaczy ka\u017cdej warto\u015bci:<\/p>\n<ul>\n<li>przychodzi warto\u015b\u0107 (bierze j\u0105 z HistoryCache);<\/li>\n<li>sprawdza w Configuration syncer: czy s\u0105 jakie\u015b wyzwalacze do obliczenia \u2013 oblicza je;<br \/>\nje\u015bli s\u0105 \u2013 tworzy zdarzenia, tworzy eskalacj\u0119, aby wygenerowa\u0107 powiadomienie, je\u015bli to konieczne zgodnie z konfiguracj\u0105;<\/li>\n<li>zapisuje wyzwalacze do dalszej obr\u00f3bki, agregacji; je\u015bli agregujesz za ostatni\u0105 godzin\u0119 i tak dalej, ta warto\u015b\u0107 zapami\u0119tuje j\u0105 w ValueCache, aby nie odwo\u0142ywa\u0107 si\u0119 do tabeli historii; w ten spos\u00f3b ValueCache wype\u0142nia si\u0119 potrzebnymi danymi, kt\u00f3re s\u0105 niezb\u0119dne do obliczenia wyzwalaczy, obliczanych element\u00f3w itp.;<\/li>\n<li>nast\u0119pnie History syncer zapisuje wszystkie dane do bazy danych;<\/li>\n<li>baza danych zapisuje je na dysku \u2013 na tym proces przetwarzania si\u0119 ko\u0144czy.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Bazy danych. Caching<\/h3>\n<p>\nPo stronie bazy danych, kiedy chcesz zobaczy\u0107 wykresy lub jakie\u015b raporty dotycz\u0105ce zdarze\u0144, istniej\u0105 r\u00f3\u017cne cache. Jednak w ramach tego referatu nie b\u0119d\u0119 o nich m\u00f3wi\u0107.<\/p>\n<p>Dla MySQL istnieje Innodb_buffer_pool, a tak\u017ce wiele r\u00f3\u017cnych cache, kt\u00f3re r\u00f3wnie\u017c mo\u017cna skonfigurowa\u0107.<br \/>\nAle to s\u0105 podstawowe:<\/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++, Andrey Gushchin (Zabbix): wysoka wydajno\u015b\u0107 i natywne partycjonowanie\" src=\"\/wp-content\/uploads\/2020\/01\/925e7abb21cfaa2516ff2b33ab161dc0.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPodaj\u0119 dla wszystkich baz danych, \u017ce istniej\u0105 okre\u015blone cache, kt\u00f3re pozwalaj\u0105 przechowywa\u0107 w pami\u0119ci RAM te dane, kt\u00f3re cz\u0119sto s\u0105 potrzebne do zapyta\u0144. Maj\u0105 swoje technologie do tego.<\/p>\n<h3>O wydajno\u015bci bazy danych<\/h3>\n<p>\nOdpowiednio, istnieje konkurencyjne \u015brodowisko, to znaczy serwer \"Zabbix\" zbiera dane i zapisuje je. Przy ponownym uruchomieniu te\u017c odczytuje z historii, aby wype\u0142ni\u0107 ValueCache itd. Tutaj mog\u0105 by\u0107 skrypty i raporty, kt\u00f3re korzystaj\u0105 z \"Zabbix API\", kt\u00f3ry jest zbudowany na podstawie interfejsu webowego. \"Zabbix API\" wchodzi do bazy danych i uzyskuje niezb\u0119dne dane do generowania wykres\u00f3w, raport\u00f3w lub jakiej\u015b listy zdarze\u0144, ostatnich problem\u00f3w.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): wysoka wydajno\u015b\u0107 i natywne partycjonowanie\" src=\"\/wp-content\/uploads\/2020\/01\/10a55cb1af660aace3172a572bea6692.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nBardzo popularnym rozwi\u0105zaniem do wizualizacji jest Grafana, kt\u00f3ra jest u\u017cywana przez naszych u\u017cytkownik\u00f3w. Mo\u017ce bezpo\u015brednio wchodzi\u0107 zar\u00f3wno przez \"Zabbix API\", jak i przez baz\u0119 danych. To r\u00f3wnie\u017c stwarza pewn\u0105 konkurencj\u0119 do uzyskiwania danych: potrzebna jest bardziej precyzyjna, dobra konfiguracja bazy danych, aby odpowiedzie\u0107 na szybkie wydawanie wynik\u00f3w i testowania.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): wysoka wydajno\u015b\u0107 i natywne partycjonowanie\" src=\"\/wp-content\/uploads\/2020\/01\/8a008e55dbee5635d386cec2fc1c40f5.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Czyszczenie historii. W Zabbixie znajduje si\u0119 Housekeeper<\/h3>\n<p>\nTrzecie wywo\u0142anie u\u017cywane w \u201eZabbixie\u201d to czyszczenie historii za pomoc\u0105 Housekeepera. \u201eHousekeeper\u201d przestrzega wszystkich ustawie\u0144, tzn. w naszych elementach danych okre\u015blono, jak d\u0142ugo przechowywa\u0107 (w dniach), ile przechowywa\u0107 trendy, dynamik\u0119 zmian.<\/p>\n<p>Nie wspomnia\u0142em o TrendCache, kt\u00f3ry obliczamy w locie: dane przychodz\u0105, agregujemy je za jedn\u0105 godzin\u0119 (g\u0142\u00f3wnie s\u0105 to liczby za ostatni\u0105 godzin\u0119), \u015brednia warto\u015b\u0107 \/ minimalna i zapisujemy to raz na godzin\u0119 w tabeli dynamiki zmian (\u201eTrendy\u201d). \u201eHousekeeper\u201d uruchamia si\u0119 i usuwa dane z bazy danych zwyk\u0142ymi selektami, co nie zawsze jest efektywne.<\/p>\n<p>Jak zrozumie\u0107, \u017ce to jest nieefektywne? Na wykresach wydajno\u015bci proces\u00f3w wewn\u0119trznych mo\u017cesz zobaczy\u0107 taki obraz:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): wysoka wydajno\u015b\u0107 i natywne partycjonowanie\" src=\"\/wp-content\/uploads\/2020\/01\/f413ec989491d4186a05c779978e2f6d.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nTw\u00f3j History syncer jest stale zaj\u0119ty (czerwony wykres). A \u201epomara\u0144czowy\u201d wykres, kt\u00f3ry idzie na g\u00f3rze. To \u201eHousekeeper\u201d, kt\u00f3ry si\u0119 uruchamia i czeka od bazy danych, a\u017c usunie wszystkie wiersze, kt\u00f3re zleci\u0142.<\/p>\n<p>We\u017amy jaki\u015b ID elementu: trzeba usun\u0105\u0107 ostatnie 5 tysi\u0119cy; oczywi\u015bcie, wed\u0142ug indeks\u00f3w. Ale zazwyczaj zbi\u00f3r danych jest wystarczaj\u0105co du\u017cy \u2013 baza danych i tak odczytuje to z dysku i podnosi do pami\u0119ci podr\u0119cznej, co jest bardzo drog\u0105 operacj\u0105 dla bazy danych. W zale\u017cno\u015bci od jej rozmiar\u00f3w, mo\u017ce to prowadzi\u0107 do okre\u015blonych problem\u00f3w z wydajno\u015bci\u0105.<\/p>\n<p>Mo\u017cna wy\u0142\u0105czy\u0107 \u201eHousekeepera\u201d prostym sposobem \u2013 mamy znany wszystkim interfejs internetowy. Ustawienia w administracji og\u00f3lnej (ustawienia dla \u201eHousekeepera\u201d) wy\u0142\u0105czamy wewn\u0119trzne housekeeping dla wewn\u0119trznej historii i trend\u00f3w. W zwi\u0105zku z tym \u201eHousekeeper\u201d ju\u017c tym nie zarz\u0105dza:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): wysoka wydajno\u015b\u0107 i natywne partycjonowanie\" src=\"\/wp-content\/uploads\/2020\/01\/c9dc3ca86e7fd0c1229f6b9bc5d31270.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nCo mo\u017cna dalej zrobi\u0107? Wy\u0142\u0105czy\u0142e\u015b, twoje wykresy si\u0119 wyr\u00f3wna\u0142y\u2026 Jakie w takim przypadku mog\u0105 by\u0107 dalsze problemy? Co mo\u017ce pom\u00f3c?<\/p>\n<h3>Partycjonowanie<\/h3>\n<p>\nZwykle jest to konfigurowane w ka\u017cdej relacyjnej bazie danych, kt\u00f3re wymieni\u0142em, w r\u00f3\u017cny spos\u00f3b. W MySQL istnieje w\u0142asna technologia. Ale og\u00f3lnie s\u0105 bardzo podobne, je\u015bli m\u00f3wimy o PostgreSQL 10 i MySQL. Oczywi\u015bcie jest tam wiele r\u00f3\u017cnic wewn\u0119trznych, jak to wszystko jest zrealizowane i jak to wp\u0142ywa na wydajno\u015b\u0107. Ale og\u00f3lnie tworzenie nowej partycji cz\u0119sto prowadzi r\u00f3wnie\u017c do okre\u015blonych problem\u00f3w.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): wysoka wydajno\u015b\u0107 i natywne partycjonowanie\" src=\"\/wp-content\/uploads\/2020\/01\/729114d61794314e19383f09ee9b5d61.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nW zale\u017cno\u015bci od Twojej konfiguracji (jak du\u017co danych tworzysz w ci\u0105gu jednego dnia), zazwyczaj ustawia si\u0119 najni\u017cszy \u2013 to 1 dzie\u0144\/partycja, a dla \u201etrend\u00f3w\u201d, dynamiki zmian \u2013 1 miesi\u0105c\/nowa partycja. Mo\u017ce si\u0119 to zmienia\u0107, je\u015bli masz bardzo du\u017c\u0105 konfiguracj\u0119.<\/p>\n<p>Od razu powiem o rozmiarach konfiguracji: do 5 tysi\u0119cy nowych warto\u015bci na sekund\u0119 (nvps) \u2013 to b\u0119dzie uwa\u017cane za ma\u0142\u0105 konfiguracj\u0119. \u015arednia to od 5 do 25 tysi\u0119cy warto\u015bci na sekund\u0119. Wszystko, co powy\u017cej, to ju\u017c du\u017ce i bardzo du\u017ce instalacje, kt\u00f3re wymagaj\u0105 bardzo starannej konfiguracji samej bazy danych.<\/p>\n<p>W przypadku bardzo du\u017cych instalacji 1 dzie\u0144 \u2013 to mo\u017ce by\u0107 nieoptymalne. Osobi\u015bcie widzia\u0142em w MySQL partycje po 40 gigabajt\u00f3w na dzie\u0144 (a mog\u0105 by\u0107 i wi\u0119ksze). To bardzo du\u017ca ilo\u015b\u0107 danych, kt\u00f3ra mo\u017ce powodowa\u0107 pewne problemy. Nale\u017cy to zmniejsza\u0107.<\/p>\n<h3>Po co jest partycjonowanie?<\/h3>\n<p>\nCo daje partycjonowanie, my\u015bl\u0119, \u017ce wszyscy wiedz\u0105 \u2013 to sekcjonowanie tabel. Cz\u0119sto s\u0105 to oddzielne pliki na dysku oraz zapytania span. Wybiera ono jedn\u0105 partycj\u0119 w spos\u00f3b bardziej optymalny, je\u015bli to mie\u015bci si\u0119 w standardowym partycjonowaniu.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): wysoka wydajno\u015b\u0107 i natywne partycjonowanie\" src=\"\/wp-content\/uploads\/2020\/01\/4920fb3415733799f0a90b1bc7af0114.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDla \u201eZabbiksa\u201d, w szczeg\u00f3lno\u015bci, stosuje si\u0119 po zakresie, czyli u\u017cywamy znacznika czasowego (liczba zwyk\u0142a, czas od pocz\u0105tku epoki). Ustawiasz pocz\u0105tek dnia\/koniec dnia, a to stanowi partycj\u0119. W zwi\u0105zku z tym, je\u015bli si\u0119gasz po dane sprzed dw\u00f3ch dni, wszystko to jest wybierane z bazy danych szybciej, poniewa\u017c trzeba za\u0142adowa\u0107 tylko jeden plik do pami\u0119ci podr\u0119cznej i wyda\u0107 (a nie du\u017c\u0105 tabel\u0119).<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): wysoka wydajno\u015b\u0107 i natywne partycjonowanie\" src=\"\/wp-content\/uploads\/2020\/01\/f5ee4e0b471eb5ebe701615aa617d66d.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nWiele baz danych r\u00f3wnie\u017c przyspiesza wstawianie (do jednej tabeli dzieci\u0119cej). M\u00f3wi\u0119 to na razie og\u00f3lnie, ale to r\u00f3wnie\u017c jest mo\u017cliwe. Partycjonowanie cz\u0119sto pomaga.<\/p>\n<h3>Elasticsearch dla NoSQL<\/h3>\n<p>\nNiedawno, w 3.4, wdro\u017cyli\u015bmy rozwi\u0105zanie dla NoSQL. Dodali\u015bmy mo\u017cliwo\u015b\u0107 zapisywania w Elasticsearch. Mo\u017cesz zapisywa\u0107 oddzielne typy: wybierasz \u2013 albo liczby, albo jakie\u015b znaki; mamy tekst string, logi mo\u017cesz zapisywa\u0107 w Elasticsearch\u2026 W zwi\u0105zku z tym interfejs webowy r\u00f3wnie\u017c b\u0119dzie si\u0119ga\u0142 po Elasticsearch. To \u015bwietnie dzia\u0142a w niekt\u00f3rych przypadkach, ale w tej chwili mo\u017cna to wykorzysta\u0107.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): wysoka wydajno\u015b\u0107 i natywne partycjonowanie\" 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>\nW wersji 4.4.2 zwr\u00f3cili\u015bmy uwag\u0119 na jedn\u0105 rzecz, jak\u0105 jest TimescaleDB. Czym to jest? To rozszerzenie dla PostgreSQL, co oznacza, \u017ce ma natywny interfejs PostgreSQL. Ponadto to rozszerzenie pozwala na znacznie efektywniejsz\u0105 prac\u0119 z danymi szereg\u00f3w czasowych oraz automatyczne partycjonowanie. Jak to wygl\u0105da:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): wysoka wydajno\u015b\u0107 i natywne partycjonowanie\" src=\"\/wp-content\/uploads\/2020\/01\/de921f06453476215b6240ab9da6fae1.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nTo jest hypertable \u2013 takie poj\u0119cie w Timescale. To hipertablica, kt\u00f3r\u0105 tworzysz, a w niej znajduj\u0105 si\u0119 chunk'i (chunk). Chunki to partycje, to tabele podrz\u0119dne, je\u015bli si\u0119 nie myl\u0119. To naprawd\u0119 wydajne.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): wysoka wydajno\u015b\u0107 i natywne partycjonowanie\" src=\"\/wp-content\/uploads\/2020\/01\/719eb3f5d8c9f57544dfc4010850610c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>TimescaleDB i PostgreSQL<\/h3>\n<p>\nJak zapewniaj\u0105 producenci TimescaleDB, stosuj\u0105 bardziej poprawny algorytm przetwarzania zapyta\u0144, w szczeg\u00f3lno\u015bci insert\u00f3w, kt\u00f3ry pozwala na utrzymanie mniej wi\u0119cej sta\u0142ej wydajno\u015bci przy rosn\u0105cym rozmiarze zestawu danych. To znaczy, \u017ce po 200 milionach wierszy standardowy PostgreSQL zaczyna bardzo mocno zwalnia\u0107 i traci wydajno\u015b\u0107 dos\u0142ownie do zera, podczas gdy Timescale pozwala na jak najefektywniejsze wstawianie insert\u00f3w przy dowolnej ilo\u015bci danych.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): wysoka wydajno\u015b\u0107 i natywne partycjonowanie\" src=\"\/wp-content\/uploads\/2020\/01\/a613d505a9dfe6008551ce981da7b24e.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Jak zainstalowa\u0107 TimescaleDB? To proste!<\/h3>\n<p>\nJest w jego dokumentacji, opisano \u2013 mo\u017cna zainstalowa\u0107 z pakiet\u00f3w dla dowolnych... Zale\u017cy od oficjalnych pakiet\u00f3w PostgreSQL. Mo\u017cna r\u00f3wnie\u017c skompilowa\u0107 r\u0119cznie. Tak si\u0119 z\u0142o\u017cy\u0142o, \u017ce musia\u0142em kompilowa\u0107 dla bazy danych.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): wysoka wydajno\u015b\u0107 i natywne partycjonowanie\" src=\"\/wp-content\/uploads\/2020\/01\/6767927fa92260103d318f9aa70ef5b3.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nW Zabbixie po prostu aktywujemy Extention. My\u015bl\u0119, \u017ce ci, kt\u00f3rzy korzystali z Extention w PostgreSQL... Po prostu aktywujesz Extention, tworzysz go dla bazy danych Zabbix, kt\u00f3rej u\u017cywasz.<\/p>\n<p>I ostatni krok...<\/p>\n<h3>TimescaleDB. Migracja tabel historii<\/h3>\n<p>\nMusisz stworzy\u0107 hypertable. W tym celu jest specjalna funkcja \u2013 Create hypertable. W niej jako pierwszy parametr podajesz tabel\u0119, kt\u00f3ra w tej bazie danych jest potrzebna (dla kt\u00f3rej nale\u017cy stworzy\u0107 hipertablic\u0119).<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): wysoka wydajno\u015b\u0107 i natywne partycjonowanie\" src=\"\/wp-content\/uploads\/2020\/01\/47350f79fd9829c12685c1df8f0ff9a6.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPole, wed\u0142ug kt\u00f3rego ma by\u0107 stworzone, oraz chunk_time_interval (to interwa\u0142 chunk\u00f3w (partycji, kt\u00f3re nale\u017cy wykorzysta\u0107). 86 400 \u2013 to jeden dzie\u0144. <\/p>\n<p>Parametr migrate_data: je\u015bli ustawisz na true, przenosi to wszystkie bie\u017c\u0105ce dane do wcze\u015bniej stworzonych chunk\u00f3w.<\/p>\n<p>Osobi\u015bcie u\u017cywa\u0142em migrate_data \u2013 zajmuje to sporo czasu, w zale\u017cno\u015bci od tego, jak du\u017c\u0105 masz baz\u0119 danych. Mia\u0142em ponad terabajt \u2013 proces tworzenia zajmowa\u0142 ponad godzin\u0119. W niekt\u00f3rych przypadkach podczas testowania usuwa\u0142em dane historyczne tekstu (history_text) i ci\u0105gu (history_str), \u017ceby ich nie przenosi\u0107 \u2013 nie by\u0142y mi tak naprawd\u0119 interesuj\u0105ce.<\/p>\n<p>I ostatnia aktualizacja, kt\u00f3r\u0105 wprowadzamy w naszym db_extension: instalujemy TimescaleDB, aby baza danych, a w szczeg\u00f3lno\u015bci nasz 'Zabbix', rozumia\u0142a, \u017ce istnieje db_extension. Aktywuje go i u\u017cywa poprawnej sk\u0142adni oraz zapyta\u0144 do bazy danych, korzystaj\u0105c z tych 'funkcji', kt\u00f3re s\u0105 niezb\u0119dne dla TimescaleDB.<\/p>\n<h3>Konfiguracja serwera<\/h3>\n<p>\nU\u017cy\u0142em dw\u00f3ch serwer\u00f3w. Pierwszy serwer to wirtualna maszyna o do\u015b\u0107 ma\u0142ej mocy, 20 procesor\u00f3w, 16 gigabajt\u00f3w pami\u0119ci RAM. Skonfigurowa\u0142em na niej 'PostgreSQL' 10.8:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): wysoka wydajno\u015b\u0107 i natywne partycjonowanie\" src=\"\/wp-content\/uploads\/2020\/01\/990805374a2380a5c645c578404489bd.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSystem operacyjny to by\u0142 Debian, a system plik\u00f3w \u2013 xfs. Dokona\u0142em minimalnych ustawie\u0144, aby u\u017cywa\u0107 w\u0142a\u015bnie tej bazy danych, z wyj\u0105tkiem tego, co b\u0119dzie wykorzystywane przez 'Zabbix'. Na tej samej maszynie dzia\u0142a\u0142 serwer 'Zabbix', PostgreSQL oraz agenci obci\u0105\u017cenia.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): wysoka wydajno\u015b\u0107 i natywne partycjonowanie\" src=\"\/wp-content\/uploads\/2020\/01\/a6efa9ab9cd58f0061d04f13fe31018c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nU\u017cy\u0142em 50 aktywnych agent\u00f3w, kt\u00f3rzy korzystaj\u0105 z LoadableModule, aby szybko generowa\u0107 r\u00f3\u017cne wyniki. To oni generowali ci\u0105gi, liczby itd. Prze\u0142adowywa\u0142em baz\u0119 danych du\u017c\u0105 ilo\u015bci\u0105 danych. Pocz\u0105tkowo konfiguracja zawiera\u0142a 5000 element\u00f3w danych na ka\u017cdy host, a ka\u017cdy element danych mia\u0142 mniej wi\u0119cej jeden wyzwalacz \u2013 aby to by\u0142o prawdziwe ustawienie. Czasami do dzia\u0142ania wymagane s\u0105 nawet wi\u0119cej ni\u017c jeden wyzwalacz.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): wysoka wydajno\u015b\u0107 i natywne partycjonowanie\" src=\"\/wp-content\/uploads\/2020\/01\/d5a3c306402e08bf2532eb6203a4aab4.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nInterwa\u0142 aktualizacji, sam\u0105 obci\u0105\u017cenie regulowa\u0142em tym, \u017ce nie tylko u\u017cywa\u0142em 50 agent\u00f3w (dodawa\u0142em wi\u0119cej), ale tak\u017ce dzi\u0119ki dynamicznym elementom danych, zmniejsza\u0142em interwa\u0142 aktualizacji do 4 sekund.<\/p>\n<h3>Test wydajno\u015bci. PostgreSQL: 36 tysi\u0119cy NVPs<\/h3>\n<p>\nPierwsze uruchomienie, pierwsza konfiguracja mia\u0142em na czystym PostgreSQL 10 na tym sprz\u0119cie (35 tysi\u0119cy warto\u015bci na sekund\u0119). Og\u00f3lnie, jak wida\u0107 na ekranie, wstawianie danych zajmuje u\u0142amki sekundy \u2013 wszystko dzia\u0142a dobrze i szybko, dyski SSD (200 gigabajt\u00f3w). Jedynie to, \u017ce 20 GB szybko si\u0119 zape\u0142nia.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): wysoka wydajno\u015b\u0107 i natywne partycjonowanie\" src=\"\/wp-content\/uploads\/2020\/01\/6803a64fedd26093b9117a036d2993ae.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nB\u0119dzie jeszcze sporo takich wykres\u00f3w. To standardowy dashboard wydajno\u015bci serwera 'Zabbix'.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): wysoka wydajno\u015b\u0107 i natywne partycjonowanie\" src=\"\/wp-content\/uploads\/2020\/01\/081cc11c6bf42db3f8f16b6cc4e6ee0c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPierwszy wykres \u2013 liczba warto\u015bci na sekund\u0119 (niebieski, u g\u00f3ry po lewej), 35 tysi\u0119cy warto\u015bci w tym przypadku. To (na g\u00f3rze w centrum) obci\u0105\u017cenie proces\u00f3w zbierania danych, a to (na g\u00f3rze po prawej) \u2013 obci\u0105\u017cenie wewn\u0119trznych proces\u00f3w: history syncers oraz housekeeper, kt\u00f3ry tutaj (na dole w centrum) dzia\u0142a\u0142 przez znaczny czas.<\/p>\n<p>Ten wykres (na dole na \u015brodku) pokazuje wykorzystanie ValueCache \u2013 ile hit\u00f3w ValueCache dla trigger\u00f3w (kilka tysi\u0119cy warto\u015bci na sekund\u0119). Inny wa\u017cny wykres \u2013 czwarty (na dole po lewej), kt\u00f3ry pokazuje wykorzystanie HistoryCache, o kt\u00f3rym wspomnia\u0142em, b\u0119d\u0105cym buforem przed wstawianiem do bazy danych.<\/p>\n<h3>Test wydajno\u015bci. PostgreSQL: 50 tysi\u0119cy NVPs<\/h3>\n<p>\nNast\u0119pnie zwi\u0119kszy\u0142em obci\u0105\u017cenie do 50 tysi\u0119cy warto\u015bci na sekund\u0119 na tej samej maszynie. Przy obci\u0105\u017ceniu \u201eHausskeeperem\u201d 10 tysi\u0119cy warto\u015bci zapisywano ju\u017c w 2-3 sekundy z obliczeniami. Co zreszt\u0105 pokazuje nast\u0119pny zrzut ekranu:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): wysoka wydajno\u015b\u0107 i natywne partycjonowanie\" src=\"\/wp-content\/uploads\/2020\/01\/80824da986dbee2f8d5ebe0ead4fbcfd.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n\u201eHausskeeper\u201d zaczyna ju\u017c kolidowa\u0107 z dzia\u0142aniem, ale og\u00f3lnie obci\u0105\u017cenie traper\u00f3w history-synk\u00f3w wci\u0105\u017c utrzymuje si\u0119 na poziomie 60 % (trzeci wykres, w g\u00f3rnym prawym rogu). HistoryCache podczas pracy \u201eHausskeepera\u201d zaczyna si\u0119 aktywnie zape\u0142nia\u0107 (na dole po lewej). Mia\u0142 oko\u0142o p\u00f3\u0142 gigabajta i zape\u0142ni\u0142 si\u0119 o 20%.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): wysoka wydajno\u015b\u0107 i natywne partycjonowanie\" src=\"\/wp-content\/uploads\/2020\/01\/9e1bcd4f3b9f3e8a1c9a36b2083ec61b.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Test wydajno\u015bci. PostgreSQL: 80 tysi\u0119cy NVPs<\/h3>\n<p>\nNast\u0119pnie zwi\u0119kszy\u0142em do 80 tysi\u0119cy warto\u015bci na sekund\u0119:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): wysoka wydajno\u015b\u0107 i natywne partycjonowanie\" src=\"\/wp-content\/uploads\/2020\/01\/13ae1589d6b9d35b4dda9c6c7d989cc2.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nTo by\u0142o oko\u0142o 400 tysi\u0119cy element\u00f3w danych, 280 tysi\u0119cy trigger\u00f3w. Wstawka, jak wida\u0107, pod wzgl\u0119dem obci\u0105\u017cenia history-synk\u00f3w (by\u0142o ich 30) by\u0142a ju\u017c dostatecznie wysoka. Nast\u0119pnie zwi\u0119ksza\u0142em r\u00f3\u017cne parametry: history-synki, cache... Na tej maszynie obci\u0105\u017cenie history-synk\u00f3w zacz\u0119\u0142o wzrasta\u0107 do maksimum, praktycznie \u201ew p\u00f3lce\u201d \u2013 w zwi\u0105zku z tym HistoryCache posz\u0142o w bardzo wysokie obci\u0105\u017cenie:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): wysoka wydajno\u015b\u0107 i natywne partycjonowanie\" src=\"\/wp-content\/uploads\/2020\/01\/0ec528256c8fa7b16e1c7c95c8119535.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nCa\u0142y czas obserwowa\u0142em wszystkie parametry systemu (jak procesor jest u\u017cywany, pami\u0119\u0107 RAM) i odkry\u0142em, \u017ce utylizacja dysk\u00f3w by\u0142a maksymalna \u2013 osi\u0105gn\u0105\u0142em maksymaln\u0105 wydajno\u015b\u0107 tego dysku na tej maszynie, na tej maszynie wirtualnej. \u201ePostgres\u201d przy takiej intensywno\u015bci zacz\u0105\u0142 do\u015b\u0107 aktywnie zrzuca\u0107 dane, a dysk nie nad\u0105\u017ca\u0142 z zapisem, odczytem\u2026<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): wysoka wydajno\u015b\u0107 i natywne partycjonowanie\" src=\"\/wp-content\/uploads\/2020\/01\/0809dbd7638e7ee003ea24c611984a0c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nWzi\u0105\u0142em inny serwer, kt\u00f3ry mia\u0142 ju\u017c 48 procesor\u00f3w i 128 gigabajt\u00f3w pami\u0119ci RAM:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): wysoka wydajno\u015b\u0107 i natywne partycjonowanie\" src=\"\/wp-content\/uploads\/2020\/01\/53410b502a4574aac5d40f1a2a6d3f42.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDodatkowo go \u201etuningowa\u0142em\u201d \u2013 zainstalowa\u0142em History syncer (60 sztuk) i osi\u0105gn\u0105\u0142em akceptowaln\u0105 wydajno\u015b\u0107. W rzeczywisto\u015bci nie jeste\u015bmy \u201ew p\u00f3lce\u201d, ale to ju\u017c prawdopodobnie limit wydajno\u015bci, gdzie wci\u0105\u017c nale\u017cy co\u015b z tym zrobi\u0107.<\/p>\n<h3>Test wydajno\u015bci. TimescaleDB: 80 tysi\u0119cy NVPs<\/h3>\n<p>\nMia\u0142em g\u0142\u00f3wne zadanie \u2013 u\u017cy\u0107 TimescaleDB. Na ka\u017cdym wykresie wida\u0107 spadek:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): wysoka wydajno\u015b\u0107 i natywne partycjonowanie\" src=\"\/wp-content\/uploads\/2020\/01\/b0064068895a34b93b5aa6771aba05cb.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nTe awarie to w\u0142a\u015bnie migracja danych. Po tym w serwerze \u201eZabbix\u201d profil \u0142adowania history syncer\u00f3w, jak widzisz, bardzo si\u0119 zmieni\u0142. Teraz umo\u017cliwia to niemal trzykrotne szybsze wstawianie danych i u\u017cywa mniej HistoryCache \u2013 dzi\u0119ki temu dane b\u0119d\u0105 dostarczane na czas. Znowu, 80 tysi\u0119cy warto\u015bci na sekund\u0119 to do\u015b\u0107 wysoki wska\u017anik (oczywi\u015bcie nie dla \u201eYandexu\u201d). Og\u00f3lnie jest to do\u015b\u0107 du\u017ca konfiguracja z jednym serwerem.<\/p>\n<h3>Test wydajno\u015bci PostgreSQL: 120 tysi\u0119cy NVP.<\/h3>\n<p>\nNast\u0119pnie zwi\u0119kszy\u0142em warto\u015b\u0107 liczby element\u00f3w danych do p\u00f3\u0142 miliona i otrzyma\u0142em obliczon\u0105 warto\u015b\u0107 125 tysi\u0119cy na sekund\u0119:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): wysoka wydajno\u015b\u0107 i natywne partycjonowanie\" src=\"\/wp-content\/uploads\/2020\/01\/7d0cf2ef7c6691c1bbf4b90afd34e4bb.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nI uzyska\u0142em takie wykresy:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): wysoka wydajno\u015b\u0107 i natywne partycjonowanie\" src=\"\/wp-content\/uploads\/2020\/01\/9c09333a50e016921a8a5b70e00397a1.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nW zasadzie jest to dzia\u0142aj\u0105ca konfiguracja, kt\u00f3ra mo\u017ce dzia\u0142a\u0107 przez d\u0142u\u017cszy czas. Ale poniewa\u017c mia\u0142em dysk o pojemno\u015bci tylko 1,5 terabajta, zu\u017cy\u0142em go w ci\u0105gu kilku dni. Najwa\u017cniejsze jest to, \u017ce w tym samym czasie tworzy\u0142y si\u0119 nowe partycje w TimescaleDB, a to dzia\u0142o si\u0119 ca\u0142kowicie niezauwa\u017calnie dla wydajno\u015bci, czego nie mo\u017cna powiedzie\u0107 o MySQL.<\/p>\n<p>Zwykle partycje tworzy si\u0119 w nocy, poniewa\u017c blokuje to wstawianie i prac\u0119 z tabelami, co mo\u017ce prowadzi\u0107 do degradacji us\u0142ugi. W tym przypadku tego nie ma! G\u0142\u00f3wnym celem by\u0142o sprawdzenie mo\u017cliwo\u015bci TimescaleDB. Oto wyniki: 120 tysi\u0119cy warto\u015bci na sekund\u0119.<\/p>\n<p>W spo\u0142eczno\u015bci znajduj\u0105 si\u0119 r\u00f3wnie\u017c przyk\u0142ady:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): wysoka wydajno\u015b\u0107 i natywne partycjonowanie\" src=\"\/wp-content\/uploads\/2020\/01\/66aa6b1d4c559d12082e4d91b6a1ca10.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nJedna osoba r\u00f3wnie\u017c w\u0142\u0105czy\u0142a TimescaleDB, a obci\u0105\u017cenie zwi\u0105zane z u\u017cywaniem io.weight spad\u0142o na procesorze; a tak\u017ce wykorzystanie element\u00f3w proces\u00f3w wewn\u0119trznych r\u00f3wnie\u017c zmniejszy\u0142o si\u0119 dzi\u0119ki w\u0142\u0105czeniu TimescaleDB. I to na zwyk\u0142ych dyskach twardych, czyli na zwyk\u0142ej maszynie wirtualnej na zwyk\u0142ych dyskach (nie SSD)!<\/p>\n<p>Dla ma\u0142ych konfiguracji, kt\u00f3re napotykaj\u0105 na wydajno\u015b\u0107 dysku, TimescaleDB, jak mi si\u0119 wydaje, to bardzo dobre rozwi\u0105zanie. Pozwoli ono ca\u0142kiem nie\u017ale pracowa\u0107, zanim przejdzie si\u0119 na szybsze podzespo\u0142y dla bazy danych.<\/p>\n<p>Zapraszam wszystkich na nasze wydarzenia: Konferencja \u2013 w Moskwie, Szczyt \u2013 w Rydze. Korzystajcie z naszych kana\u0142\u00f3w \u2013 \u201eTelegram\u201d, forum, IRC. Je\u015bli macie jakiekolwiek pytania \u2013 przyjd\u017acie do nas na stoisko, mo\u017cemy porozmawia\u0107 o wszystkim.<\/p>\n<h3>Pytania od publiczno\u015bci<\/h3>\n<p>\nPytanie z sali (dalej \u2013 A): \u2013 Je\u015bli TimescaleDB jest tak \u0142atwy w konfiguracji i daje tak du\u017cy wzrost wydajno\u015bci, to mo\u017ce warto to wykorzysta\u0107 jako najlepsz\u0105 praktyk\u0119 do konfigurowania \u00abZabbix\u00bb z \u00abPostgresem\u00bb? Czy s\u0105 jakie\u015b ukryte pu\u0142apki lub minusy tego rozwi\u0105zania, czy jednak, je\u015bli zdecydowa\u0142em si\u0119 na \u00abZabbix\u00bb, mog\u0119 spokojnie u\u017cywa\u0107 \u00abPostgresa\u00bb, od razu instalowa\u0107 \u00abTimescale\u00bb i nie przejmowa\u0107 si\u0119 \u017cadnymi problemami?<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): wysoka wydajno\u015b\u0107 i natywne partycjonowanie\" src=\"\/wp-content\/uploads\/2020\/01\/314845a019724806283a957b15d857cc.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>AG:<\/b> \u2013 Tak, powiedzia\u0142bym, \u017ce to dobra rekomendacja: u\u017cywa\u0107 \u00abPostgresa\u00bb od razu z rozszerzeniem TimescaleDB. Jak ju\u017c m\u00f3wi\u0142em, s\u0105 liczne dobre opinie, mimo \u017ce ta \u00abfunkcja\u00bb jest eksperymentalna. Ale w rzeczywisto\u015bci testy pokazuj\u0105, \u017ce to \u015bwietne rozwi\u0105zanie (z TimescaleDB), i my\u015bl\u0119, \u017ce b\u0119dzie si\u0119 rozwija\u0107! \u015aledzimy, jak to rozszerzenie si\u0119 rozwija i wprowadzimy potrzebne poprawki.<\/p>\n<p>Nawet podczas rozwoju opierali\u015bmy si\u0119 na jednej z ich znanych \u00abfunkcji\u00bb: mo\u017cna by\u0142o pracowa\u0107 z chunkami troch\u0119 inaczej. Ale potem usun\u0119li to w nast\u0119pnej wersji, i musieli\u015bmy przesta\u0107 opiera\u0107 si\u0119 na tym kodzie. Poleci\u0142bym to rozwi\u0105zanie w wielu setupach. Je\u015bli u\u017cywasz MySQL\u2026 Dla \u015brednich setup\u00f3w ka\u017cde rozwi\u0105zanie dobrze dzia\u0142a.<\/p>\n<p><b>A:<\/b> \u2013 Na ostatnich wykresach od spo\u0142eczno\u015bci by\u0142 wykres z \u00abHousekeeper\u00bb:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): wysoka wydajno\u015b\u0107 i natywne partycjonowanie\" src=\"\/wp-content\/uploads\/2020\/01\/d01549b6b9b97d8bdf5372efe05d9039.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nOn nadal dzia\u0142a. Co robi \u00abHousekeeper\u00bb w przypadku TimescaleDB?<\/p>\n<p><b>AG:<\/b> \u2013 Teraz nie mog\u0119 dok\u0142adnie powiedzie\u0107 \u2013 spojrz\u0119 na kod i powiem dok\u0142adniej. U\u017cywa zapyta\u0144 bezpo\u015brednio TimescaleDB, nie do usuwania chunk\u00f3w, ale w jaki\u015b spos\u00f3b agreguje. Na razie nie jestem got\u00f3w odpowiedzie\u0107 na to techniczne pytanie. Na stoisku dzisiaj lub jutro wyja\u015bnimy.<\/p>\n<p><b>A:<\/b> \u2013 Mam podobne pytanie \u2013 o wydajno\u015b\u0107 operacji usuwania w \u00abTimescale\u00bb.<br \/>\nA (odpowied\u017a z sali): \u2013 Kiedy usuwasz dane z tabeli, je\u015bli robisz to przez delete, musisz przej\u015b\u0107 przez tabel\u0119 \u2013 usun\u0105\u0107, oczy\u015bci\u0107, oznaczy\u0107 wszystko do przysz\u0142ego vacuum. W \u00abTimescale\u00bb, poniewa\u017c masz chunk, mo\u017cesz to dropowa\u0107. M\u00f3wi\u0105c w skr\u00f3cie, po prostu m\u00f3wisz plikowi, kt\u00f3ry le\u017cy w big data: \u201eUsu\u0144!\u201d<\/p>\n<p>\u201eTimescale\u201c po prostu rozumie, \u017ce ten chunk ju\u017c nie istnieje. I poniewa\u017c jest zintegrowany z harmonogramem zapyta\u0144, wychwytuje Twoje warunki w select lub w innych operacjach i od razu zdaje sobie spraw\u0119, \u017ce ten chunk ju\u017c nie istnieje \u2013 \u201eJu\u017c tam nie p\u00f3jd\u0119!\u201d (dane s\u0105 niedost\u0119pne). I to wszystko! To znaczy, skanowanie tabeli zast\u0119powane jest usuni\u0119ciem pliku binarnego, wi\u0119c to jest szybkie.<\/p>\n<p><b>A:<\/b> \u2013 Ju\u017c poruszali\u015bmy temat nie-SQL. Jakkolwiek rozumiem, Zabbix nie potrzebuje zbytnio modyfikowa\u0107 danych, a wszystko to jest czym\u015b w rodzaju loga. Czy mo\u017cna u\u017cywa\u0107 specjalizowanych baz danych, kt\u00f3re nie mog\u0105 zmienia\u0107 swoich danych, ale jednocze\u015bnie o wiele szybciej zapisuj\u0105, gromadz\u0105, przekazuj\u0105 \u2013 Clickhouse, na przyk\u0142ad, co\u015b w stylu Kafki?.. Kafka to r\u00f3wnie\u017c log! Czy mo\u017cna je jako\u015b zintegrowa\u0107?<\/p>\n<p><b>AG:<\/b> \u2013 Eksport mo\u017cna zrealizowa\u0107. Mamy pewn\u0105 funkcjonalno\u015b\u0107 od wersji 3.4: mo\u017cesz zapisywa\u0107 wszystkie historyczne pliki, wydarzenia, wszystko inne w plikach; a potem jakim\u015b przetwornikiem wysy\u0142a\u0107 do innej bazy danych. W rzeczywisto\u015bci wiele os\u00f3b przerabia i pisze bezpo\u015brednio do bazy danych. Synchronizatory historii na bie\u017c\u0105co zapisuj\u0105 to wszystko w plikach, rotuj\u0105 te pliki itd., a to mo\u017cesz przerzuca\u0107 do \u201eClickhouse\u201d. Nie mog\u0119 nic powiedzie\u0107 o planach, ale by\u0107 mo\u017ce dalsze wsparcie dla rozwi\u0105za\u0144 NoSQL (takich jak \u201eClickhouse\u201d) b\u0119dzie kontynuowane.<\/p>\n<p><b>A:<\/b> \u2013 W og\u00f3le, wychodzi na to, \u017ce mo\u017cna ca\u0142kowicie zrezygnowa\u0107 z Postgresa?<\/p>\n<p><b>AG:<\/b> \u2013 Oczywi\u015bcie, najtrudniejsz\u0105 cz\u0119\u015bci\u0105 w Zabbixie s\u0105 historyczne tabele, kt\u00f3re stwarzaj\u0105 najwi\u0119cej problem\u00f3w, oraz wydarzenia. W tym przypadku, je\u015bli nie b\u0119dziesz d\u0142ugo przechowywa\u0107 wydarze\u0144 i b\u0119dziesz przechowywa\u0107 histori\u0119 z trendami w jakim\u015b innym szybkim magazynie, to og\u00f3lnie nie powinno by\u0107 \u017cadnych problem\u00f3w.<\/p>\n<p><b>A:<\/b> \u2013 Mo\u017cesz oszacowa\u0107, jak wiele szybciej wszystko b\u0119dzie dzia\u0142a\u0107, je\u015bli przejdziemy na \u201eClickhouse\u201d, powiedzmy?<\/p>\n<p><b>AG:<\/b> \u2013 Nie testowa\u0142em. My\u015bl\u0119, \u017ce przynajmniej te same wyniki mo\u017cna osi\u0105gn\u0105\u0107 do\u015b\u0107 \u0142atwo, bior\u0105c pod uwag\u0119, \u017ce \u201eClickhouse\u201d ma sw\u00f3j interfejs, ale nie mog\u0119 powiedzie\u0107 z ca\u0142\u0105 pewno\u015bci\u0105. Lepiej przetestowa\u0107. Wszystko zale\u017cy od konfiguracji: ilu masz host\u00f3w itd. Wstawianie to jedno, ale trzeba r\u00f3wnie\u017c te dane pozyskiwa\u0107 \u2013 Grafana lub co\u015b innego.<\/p>\n<p><b>A:<\/b> \u2013 Czyli m\u00f3wimy o r\u00f3wnej walce, a nie o du\u017cej przewadze tych szybkich baz danych?<\/p>\n<p><b>AG:<\/b> \u2013 My\u015bl\u0119, \u017ce kiedy zintegrowane, b\u0119d\u0105 dok\u0142adniejsze testy.<\/p>\n<p><b>A:<\/b> \u2013 Gdzie znikn\u0105\u0142 stary dobry RRD? Co spowodowa\u0142o przej\u015bcie na bazy danych SQL? Pocz\u0105tkowo wszystkie metryki zbierano na RRD.<\/p>\n<p><b>AG:<\/b> \u2013 W \u00abZabbix\u00bb RRD mo\u017ce by\u0142 w bardzo starej wersji. Zawsze by\u0142y bazy SQL \u2013 klasyczne podej\u015bcie. Klasyczne podej\u015bcie to MySQL, PostgreSQL (istniej\u0105 od bardzo dawna). Mamy wsp\u00f3lny interfejs dla baz danych SQL, a RRD praktycznie nigdy nie u\u017cywali\u015bmy.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andrey Gushchin (Zabbix): wysoka wydajno\u015b\u0107 i natywne partycjonowanie\" 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=\"Odtwarzaj wideo\" 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>Troch\u0119 reklamy \ud83d\ude42<\/h3>\n<p>\nDzi\u0119kujemy, \u017ce jeste\u015b z nami. Podobaj\u0105 Ci si\u0119 nasze artyku\u0142y? Chcesz zobaczy\u0107 wi\u0119cej interesuj\u0105cych materia\u0142\u00f3w? Wspieraj nas sk\u0142adaj\u0105c zam\u00f3wienie lub polecaj\u0105c nas znajomym, <noindex><a rel=\"nofollow\" href=\"https:\/\/ua-hosting.company\/cloudvps\/nl\">chmurowe VPS dla programist\u00f3w od 4,99 $<\/a><\/noindex>, <b>unikatowy odpowiednik serwer\u00f3w entry-level, kt\u00f3ry zosta\u0142 stworzony przez nas dla Ciebie:<\/b> <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/company\/ua-hosting\/blog\/347386\/\">Ca\u0142a prawda o VPS (KVM) E5-2697 v3 (6 rdzeni) 10GB DDR4 480GB SSD 1Gbps od 19 $ lub jak prawid\u0142owo podzieli\u0107 serwer?<\/a><\/noindex> (dost\u0119pne opcje z RAID1 i RAID10, do 24 rdzeni i do 40GB DDR4).<\/p>\n<p><b>Dell R730xd dwa razy ta\u0144szy w centrum danych Equinix Tier IV w Amsterdamie?<\/b> Tylko u nas <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 100TB od 199 dolar\u00f3w<\/a><\/noindex> w Holandii! <b>Dell R420 \u2014 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB \u2014 od 99 dolar\u00f3w!<\/b><\/b> Czytaj o tym <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/company\/ua-hosting\/blog\/329618\/\">Jak zbudowa\u0107 infrastruktur\u0119 klasy korporacyjnej z zastosowaniem serwer\u00f3w Dell R730xd E5-2650 v4 kosztuj\u0105cych 9000 euro za grosze?<\/a><\/noindex><br \/>\n<br \/>\u0179r\u00f3d\u0142o: <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.1.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\/pl\/blog\/administrirovanie\/highload-andrej-gushhin-zabbix-vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"pl_PL\" \/>\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\/pl\/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++, Andriej Guszczin (Zabbix): wysoka wydajno\u015b\u0107 i natywne partycjonowanie | ProHoster","description":"Om\u00f3wimy dzia\u0142anie Zabbixa z baz\u0105 danych TimescaleDB jako backend. Poka\u017cemy, jak uruchomi\u0107 od podstaw i jak migrowa\u0107 z PostgreSQL.","canonical_url":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/highload-andrej-gushhin-zabbix-vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"pl_PL","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\/pl\/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\/pl\/wp-json\/wp\/v2\/posts\/55734","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/comments?post=55734"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/posts\/55734\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/media?parent=55734"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/categories?post=55734"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/tags?post=55734"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}