{"id":38927,"date":"2019-10-31T22:26:48","date_gmt":"2019-10-31T19:26:48","guid":{"rendered":"https:\/\/prohoster.info\/blog\/vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie-zabbix-s-podderzhkoj-timescaledb\/"},"modified":"2019-10-31T22:26:48","modified_gmt":"2019-10-31T19:26:48","slug":"vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie-zabbix-s-podderzhkoj-timescaledb","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie-zabbix-s-podderzhkoj-timescaledb","title":{"rendered":"Wysoka wydajno\u015b\u0107 i natywne partycjonowanie: Zabbix z obs\u0142ug\u0105 TimescaleDB","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Zabbix to system monitorowania. Jak ka\u017cda inna system, stoi przed trzema g\u0142\u00f3wnymi problemami wszystkich system\u00f3w monitorowania: zbieranie i przetwarzanie danych, przechowywanie historii oraz jej czyszczenie.<\/p>\n<p>Etapy pozyskiwania, przetwarzania i zapisu danych zajmuj\u0105 czas. Troch\u0119, ale w du\u017cym systemie mo\u017ce to prowadzi\u0107 do znacznych op\u00f3\u017anie\u0144. Problem przechowywania to kwestia dost\u0119pu do danych. S\u0105 one wykorzystywane do raport\u00f3w, inspekcji i trigger\u00f3w. Op\u00f3\u017anienia w dost\u0119pie do danych r\u00f3wnie\u017c wp\u0142ywaj\u0105 na wydajno\u015b\u0107. Gdy bazy danych rosn\u0105, nieaktualne dane musz\u0105 by\u0107 usuwane. Usuni\u0119cie jest operacj\u0105 obci\u0105\u017caj\u0105c\u0105, kt\u00f3ra r\u00f3wnie\u017c zu\u017cywa cz\u0119\u015b\u0107 zasob\u00f3w.<\/p>\n<p><img decoding=\"async\" alt=\"Wysoka wydajno\u015b\u0107 i natywne partycjonowanie: Zabbix z obs\u0142ug\u0105 TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/9b7aa23705cd32b4d8d858ad78b181fd.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nProblemy z op\u00f3\u017anieniami przy zbieraniu i przechowywaniu w Zabbixie s\u0105 rozwi\u0105zywane za pomoc\u0105 cache'owania: r\u00f3\u017cnych typ\u00f3w cache'\u00f3w, cache'owania w bazie danych. Aby rozwi\u0105za\u0107 trzeci problem, cache'owanie nie jest odpowiednie, dlatego w Zabbixie zastosowano TimescaleDB. O tym opowie <strong>Andriej Gu\u015bcin<\/strong> \u2014 in\u017cynier wsparcia technicznego <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/zabbix\/\">Zabbix SIA<\/a><\/noindex>. W wsparciu Zabbix Andriej pracuje od ponad 6 lat i bezpo\u015brednio zajmuje si\u0119 wydajno\u015bci\u0105.<\/p>\n<p>Jak dzia\u0142a TimescaleDB, jak\u0105 wydajno\u015b\u0107 mo\u017ce zapewni\u0107 w por\u00f3wnaniu do zwyk\u0142ego PostgreSQL? Jak\u0105 rol\u0119 odgrywa Zabbix dla baz danych TimescaleDB? Jak zacz\u0105\u0107 od zera i jak migrowa\u0107 z PostgreSQL, a jaka konfiguracja daje lepsz\u0105 wydajno\u015b\u0107? O tym wszystkim poni\u017cej.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><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<h2>Wyzwania wydajno\u015bci<\/h2>\n<p>\nKa\u017cdy system monitorowania napotyka okre\u015blone wyzwania wydajno\u015bci. Opowiem o trzech z nich: zbieraniu i przetwarzaniu danych, przechowywaniu, czyszczeniu historii.<\/p>\n<p><strong>Szybkie zbieranie i przetwarzanie danych. <\/strong>Dobra system monitorowania musi szybko pozyskiwa\u0107 wszystkie dane i przetwarza\u0107 je zgodnie z wyra\u017ceniami trigger\u00f3w \u2014 wed\u0142ug swoich kryteri\u00f3w. Po przetworzeniu system musi r\u00f3wnie\u017c szybko zapisa\u0107 te dane w bazie danych, aby p\u00f3\u017aniej m\u00f3c je wykorzysta\u0107.<\/p>\n<p><strong>Przechowywanie historii. <\/strong>Dobra system monitorowania musi przechowywa\u0107 histori\u0119 w bazie danych i zapewnia\u0107 wygodny dost\u0119p do metryk. Historia jest potrzebna do wykorzystywania jej w raportach, wykresach, triggerach, warto\u015bciach progowych oraz obliczanych elementach danych do powiadomie\u0144.<\/p>\n<p><strong>Czyszczenie historii. <\/strong>Czasami nadchodzi dzie\u0144, kiedy nie musisz przechowywa\u0107 metryk. Po co ci dane zebrane pi\u0119\u0107 lat temu, miesi\u0105c czy dwa: niekt\u00f3re w\u0119z\u0142y zosta\u0142y usuni\u0119te, niekt\u00f3re hosty lub metryki s\u0105 ju\u017c niepotrzebne, poniewa\u017c sta\u0142y si\u0119 przestarza\u0142e i przesta\u0142y by\u0107 zbierane. Dobrze zaprojektowany system monitorowania powinien przechowywa\u0107 dane historyczne i okresowo je usuwa\u0107, aby baza danych nie rozros\u0142a si\u0119.<\/p>\n<blockquote><p>Usuwanie przestarza\u0142ych danych to wa\u017cna kwestia, kt\u00f3ra w znacz\u0105cy spos\u00f3b wp\u0142ywa na wydajno\u015b\u0107 bazy danych.<\/p><\/blockquote>\n<p><\/p>\n<h2>Cache'owanie w Zabbixie<\/h2>\n<p>\nW Zabbixie pierwsze i drugie wywo\u0142ania s\u0105 realizowane za pomoc\u0105 cache'owania. Do zbierania i przetwarzania danych u\u017cywana jest pami\u0119\u0107 operacyjna. W celu przechowywania danych historia znajduje si\u0119 w wyzwalaczach, wykresach i obliczanych elementach danych. Po stronie bazy danych istnieje pewne cache'owanie dla g\u0142\u00f3wnych zapyta\u0144, na przyk\u0142ad dla wykres\u00f3w.<\/p>\n<p>Cache'owanie po stronie samego serwera Zabbix to:<\/p>\n<ul>\n<li>ConfigurationCache;<\/li>\n<li>ValueCache;<\/li>\n<li>HistoryCache;<\/li>\n<li>TrendsCache.<\/li>\n<\/ul>\n<p>\nPrzyjrzyjmy si\u0119 im bli\u017cej.<\/p>\n<h3>ConfigurationCache<\/h3>\n<p>\nTo g\u0142\u00f3wny cache, w kt\u00f3rym przechowujemy metryki, hosty, elementy danych, wyzwalacze \u2013 wszystko, co jest potrzebne do wst\u0119pnego przetwarzania i zbierania danych.<\/p>\n<p><img decoding=\"async\" alt=\"Wysoka wydajno\u015b\u0107 i natywne partycjonowanie: Zabbix z obs\u0142ug\u0105 TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/122708198f6cd136fbd0420876c06e9c.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nWszystko to jest przechowywane w ConfigurationCache, aby unikn\u0105\u0107 zb\u0119dnych zapyta\u0144 do bazy danych. Po uruchomieniu serwera aktualizujemy ten cache, tworzymy i okresowo aktualizujemy konfiguracje.<\/p>\n<h3>Zbieranie danych<\/h3>\n<p>\nSchemat jest do\u015b\u0107 rozbudowany, ale jego g\u0142\u00f3wnym elementem s\u0105 <strong>zbieracze<\/strong>. To r\u00f3\u017cne \u201epollery\u201d \u2013 procesy zbierania. Odpowiadaj\u0105 za r\u00f3\u017cne rodzaje zbierania danych: zbieraj\u0105 dane przez SNMP, IPMI i przesy\u0142aj\u0105 je do wst\u0119pnego przetwarzania.<\/p>\n<p><img decoding=\"async\" alt=\"Wysoka wydajno\u015b\u0107 i natywne partycjonowanie: Zabbix z obs\u0142ug\u0105 TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/deff5d9ff358f1b04b505d18c7770f21.jpg\" style=\"display:block;margin: 0 auto;\" \/><em>Zbieracze s\u0105 zaznaczone pomara\u0144czow\u0105 lini\u0105.<\/em><\/p>\n<p>W Zabbixie istniej\u0105 obliczeniowe elementy danych agregacyjnych, kt\u00f3re s\u0105 potrzebne do agregacji sprawdze\u0144. Je\u015bli je mamy, pobieramy dane dla nich bezpo\u015brednio z ValueCache.<\/p>\n<h3>PreProcessing HistoryCache<\/h3>\n<p>\nWszystkie zbieracze u\u017cywaj\u0105 ConfigurationCache, aby otrzymywa\u0107 zadania. Nast\u0119pnie przekazuj\u0105 je do wst\u0119pnego przetwarzania.<\/p>\n<p><img decoding=\"async\" alt=\"Wysoka wydajno\u015b\u0107 i natywne partycjonowanie: Zabbix z obs\u0142ug\u0105 TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/116e25100ebdf9ed209a9b04fa6fa156.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nWst\u0119pne przetwarzanie wykorzystuje ConfigurationCache do otrzymywania krok\u00f3w przetwarzania. Przetwarza dane na r\u00f3\u017cne sposoby.<\/p>\n<p>Po przetworzeniu danych za pomoc\u0105 wst\u0119pnego przetwarzania, zapisujemy je w HistoryCache, aby je przetworzy\u0107. Na tym ko\u0144czy si\u0119 zbieranie danych i przechodzimy do g\u0142\u00f3wnego procesu w Zabbixie \u2013 <strong>history syncer<\/strong>, poniewa\u017c jest to monolityczna architektura.<\/p>\n<p><em>Uwaga: Wst\u0119pne przetwarzanie to do\u015b\u0107 wymagaj\u0105ca operacja. Od wersji 4.2 zosta\u0142o przeniesione na proxy. Je\u015bli masz bardzo du\u017cy Zabbix z wieloma elementami danych i wysok\u0105 cz\u0119stotliwo\u015bci\u0105 zbierania, znacznie to u\u0142atwia prac\u0119.<\/em><\/p>\n<h3>ValueCache, cache historii i trend\u00f3w<\/h3>\n<p><\/p>\n<blockquote><p>History syncer to g\u0142\u00f3wny proces, kt\u00f3ry atomowo przetwarza ka\u017cdy element danych, czyli ka\u017cd\u0105 warto\u015b\u0107.<\/p><\/blockquote>\n<p>\nHistory syncer pobiera warto\u015bci z HistoryCache i sprawdza w Configuration obecno\u015b\u0107 wyzwalaczy do oblicze\u0144. Je\u015bli s\u0105, to wykonuje obliczenia.<\/p>\n<p>History syncer tworzy zdarzenie, eskalacj\u0119, aby zrealizowa\u0107 powiadomienia, je\u015bli jest to wymagane przez konfiguracj\u0119, i zapisuje. Je\u015bli istniej\u0105 wyzwalacze do dalszego przetwarzania, zapami\u0119tuje t\u0119 warto\u015b\u0107 w ValueCache, aby unikn\u0105\u0107 ponownego dost\u0119pu do tabeli historii. W ten spos\u00f3b ValueCache wype\u0142nia si\u0119 danymi niezb\u0119dnymi do oblicze\u0144 wyzwalaczy, obliczanych element\u00f3w.<\/p>\n<p>History syncer zapisuje wszystkie dane w bazie danych, a ta \u2014 na dysku. Proces przetwarzania na tym si\u0119 ko\u0144czy.<\/p>\n<p><img decoding=\"async\" alt=\"Wysoka wydajno\u015b\u0107 i natywne partycjonowanie: Zabbix z obs\u0142ug\u0105 TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/4d74195381fda7756b0250982f6896be.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Cache w bazie danych<\/h3>\n<p>\nPo stronie bazy danych istniej\u0105 r\u00f3\u017cne cache, gdy chcesz ogl\u0105da\u0107 wykresy lub raporty dotycz\u0105ce zdarze\u0144:<\/p>\n<ul>\n<li><code>Innodb_buffer_pool<\/code> po stronie MySQL;<\/li>\n<li><code>shared_buffers<\/code> po stronie PostgreSQL;<\/li>\n<li><code>effective_cache_size<\/code> po stronie Oracle;<\/li>\n<li><code>shared_pool<\/code> po stronie DB2.<\/li>\n<\/ul>\n<p>\nJest jeszcze wiele innych cache, ale to s\u0105 g\u0142\u00f3wne dla wszystkich baz danych. Pozwalaj\u0105 one na trzymanie w pami\u0119ci operacyjnej danych, kt\u00f3re cz\u0119sto s\u0105 potrzebne do zapyta\u0144. Ka\u017cdy z nich ma swoje technologie do tego.<\/p>\n<h3>Wydajno\u015b\u0107 bazy danych jest krytycznie wa\u017cna<\/h3>\n<p>\nZabbix serwer ci\u0105gle zbiera dane i je zapisuje. Przy restarcie r\u00f3wnie\u017c odczytuje z historii, aby wype\u0142ni\u0107 ValueCache. U\u017cywa skrypt\u00f3w i raport\u00f3w <strong>Zabbix API<\/strong>, kt\u00f3re s\u0105 oparte na interfejsie Web. Zabbix API zwraca si\u0119 do bazy danych i pozyskuje niezb\u0119dne dane do wykres\u00f3w, raport\u00f3w, list zdarze\u0144 i aktualnych problem\u00f3w.<\/p>\n<p><img decoding=\"async\" alt=\"Wysoka wydajno\u015b\u0107 i natywne partycjonowanie: Zabbix z obs\u0142ug\u0105 TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/dd0efdc4e57c1197d448ce453012091e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDo wizualizacji \u2014 <strong>Grafana<\/strong>. W\u015br\u00f3d naszych u\u017cytkownik\u00f3w to popularne rozwi\u0105zanie. Umo\u017cliwia bezpo\u015brednie wysy\u0142anie zapyta\u0144 przez Zabbix API, zar\u00f3wno w BD, jak i tworzy pewn\u0105 konkurencj\u0119 do uzyskiwania danych. Dlatego wymagana jest bardziej precyzyjna i dobra konfiguracja BD, aby spe\u0142nia\u0107 szybkie wydawanie wynik\u00f3w i testowania.<\/p>\n<h2>Housekeeper<\/h2>\n<p>\nTrzecim wyzwaniem wydajno\u015bci w Zabbix jest czyszczenie historii za pomoc\u0105 Housekeeper. Przestrzega on wszystkich ustawie\u0144 \u2014 w elementach danych okre\u015blono, ile dni przechowywa\u0107 dynamik\u0119 zmian (trend\u00f3w).<\/p>\n<p>TrendsCache obliczamy na bie\u017c\u0105co. Gdy pojawiaj\u0105 si\u0119 dane, agregujemy je za jeden godzin\u0119 i zapisujemy w tabelach do dynamiki zmian trend\u00f3w.<\/p>\n<p>Housekeeper uruchamia si\u0119 i usuwa informacje z BD zwyk\u0142ymi \u201eselectami\u201d. To nie zawsze jest wydajne, co mo\u017cna zauwa\u017cy\u0107 na wykresach wydajno\u015bci proces\u00f3w wewn\u0119trznych.<\/p>\n<p><img decoding=\"async\" alt=\"Wysoka wydajno\u015b\u0107 i natywne partycjonowanie: Zabbix z obs\u0142ug\u0105 TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/a3af1badd14b1092bc26e0b53845ae04.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nCzerwony wykres pokazuje, \u017ce History syncer jest ca\u0142y czas zaj\u0119ty. Pomara\u0144czowy wykres u g\u00f3ry to Housekeeper, kt\u00f3ry nieustannie dzia\u0142a. Czeka na baz\u0119 danych, aby usun\u0119\u0142a wszystkie wiersze, kt\u00f3re zdefiniowa\u0142.<\/p>\n<p>Kiedy nale\u017cy wy\u0142\u0105czy\u0107 Housekeepera? Na przyk\u0142ad, je\u015bli mamy \u201eItem ID\u201d i trzeba usun\u0105\u0107 ostatnie 5 tysi\u0119cy wierszy z okre\u015blonego okresu. Oczywi\u015bcie odbywa si\u0119 to na podstawie indeks\u00f3w. Jednak zwykle zestaw danych jest bardzo du\u017cy, a baza danych nadal odczytuje z dysku i \u0142aduje do pami\u0119ci podr\u0119cznej. To zawsze bardzo kosztowna operacja dla bazy danych i w zale\u017cno\u015bci od rozmiar\u00f3w bazy mo\u017ce prowadzi\u0107 do problem\u00f3w z wydajno\u015bci\u0105.<\/p>\n<p><img decoding=\"async\" alt=\"Wysoka wydajno\u015b\u0107 i natywne partycjonowanie: Zabbix z obs\u0142ug\u0105 TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/0778318b539fbe33318e8a7310f8a89b.jpg\" style=\"display:block;margin: 0 auto;\" \/> <\/p>\n<p>Housekeepera mo\u017cna po prostu wy\u0142\u0105czy\u0107. W interfejsie internetowym jest opcja w \u201eAdministracja og\u00f3lna\u201d dla Housekeepera. Wy\u0142\u0105czamy wewn\u0119trzny housekeeping dla historii trend\u00f3w, a on ju\u017c tym nie zarz\u0105dza.<\/p>\n<p>Housekeeper zosta\u0142 wy\u0142\u0105czony, wykresy si\u0119 wyr\u00f3wna\u0142y \u2014 jakie mog\u0105 by\u0107 w tym przypadku problemy i co mo\u017ce pom\u00f3c w rozwi\u0105zaniu trzeciego wezwania wydajno\u015bci?<\/p>\n<h2>Partitioning \u2014 sekcjonowanie lub partycjonowanie<\/h2>\n<p>\nZwykle partycjonowanie konfiguruje si\u0119 w r\u00f3\u017cny spos\u00f3b w ka\u017cdej relacyjnej bazie danych, kt\u00f3r\u0105 wymieni\u0142em. Ka\u017cda ma swoj\u0105 technologi\u0119, ale s\u0105 podobne og\u00f3lnie. Tworzenie nowej partycji cz\u0119sto prowadzi do okre\u015blonych problem\u00f3w.<\/p>\n<p>Zwykle partycje konfiguruje si\u0119 w zale\u017cno\u015bci od \u201esetup\u201d \u2014 ilo\u015bci danych, kt\u00f3re s\u0105 generowane w ci\u0105gu jednego dnia. Z regu\u0142y partycjonowanie ustawia si\u0119 na ca\u0142y dzie\u0144, to minimum. Dla trend\u00f3w nowa partycja to minimum 1 miesi\u0105c.<\/p>\n<p>Warto\u015bci mog\u0105 si\u0119 zmienia\u0107 w przypadku bardzo du\u017cego \u201esetup\u201d. Je\u015bli ma\u0142y \u201esetup\u201d to do 5 000 nvps (nowych warto\u015bci na sekund\u0119), \u015bredni to od 5 000 do 25 000, a du\u017cy to powy\u017cej 25 000 nvps. To du\u017ce i bardzo du\u017ce instalacje, kt\u00f3re wymagaj\u0105 starannej konfiguracji samej bazy danych.<\/p>\n<p>W bardzo du\u017cych instalacjach odcinek jednego dnia mo\u017ce nie by\u0107 optymalny. Widzia\u0142em w MySQL partycje o pojemno\u015bci 40 GB i wi\u0119kszej na dzie\u0144. To bardzo du\u017ca ilo\u015b\u0107 danych, kt\u00f3ra mo\u017ce prowadzi\u0107 do problem\u00f3w, wi\u0119c nale\u017cy j\u0105 zmniejszy\u0107.<\/p>\n<h3>Co daje Partitioning?<\/h3>\n<p>\n<strong>Sekcjonowanie tabel<\/strong>. Cz\u0119sto s\u0105 to oddzielne pliki na dysku. Plan zapyta\u0144 wybiera jedn\u0105 partycj\u0119 w spos\u00f3b bardziej optymalny. Zwykle partycjonowanie odbywa si\u0119 w oparciu o zakres \u2014 dla Zabbixa te\u017c jest to prawda. U\u017cywamy tam \u201etimestamp\u201d \u2014 czas od pocz\u0105tku epoki. U nas to zwyk\u0142e liczby. Ustalasz pocz\u0105tek i koniec dnia \u2014 to jest partycja.<\/p>\n<p><strong>Szybkie usuwanie<\/strong> \u2014 <code>USU\u0143<\/code>Wybierany jest jeden plik\/subtabela, a nie zbi\u00f3r wierszy do usuni\u0119cia.<\/p>\n<p><strong>Wyra\u017anie przyspiesza pobieranie danych.<\/strong> <code>SELECT<\/code> \u2014 wykorzystuje jedn\u0105 lub wi\u0119cej partycji, a nie ca\u0142\u0105 tabel\u0119. Je\u015bli odwo\u0142ujesz si\u0119 do danych sprzed dw\u00f3ch dni, s\u0105 one wybierane z bazy danych szybciej, poniewa\u017c trzeba za\u0142adowa\u0107 do cache i wydoby\u0107 tylko jeden plik, a nie du\u017c\u0105 tabel\u0119.<\/p>\n<p>Cz\u0119sto wiele baz danych r\u00f3wnie\u017c przyspiesza <code>INSERT<\/code> \u2014 wstawki do tabeli podrz\u0119dnej.<\/p>\n<h2>TimescaleDB<\/h2>\n<p>\nDla wersji 4.2 zwr\u00f3cili\u015bmy uwag\u0119 na TimescaleDB. Jest to rozszerzenie dla PostgreSQL z natywnym interfejsem. Rozszerzenie skutecznie dzia\u0142a z danymi szereg\u00f3w czasowych, nie trac\u0105c przy tym zalet relacyjnych baz danych. TimescaleDB automatycznie partycjonuje r\u00f3wnie\u017c.<\/p>\n<p>W TimescaleDB istnieje poj\u0119cie <strong>hipertabela<\/strong> (hypertable), kt\u00f3r\u0105 tworzysz. Znajduj\u0105 si\u0119 w niej <strong>fragmenty<\/strong> \u2014 partycje. Fragmenty to automatycznie zarz\u0105dzane kawa\u0142ki hipertabeli, kt\u00f3re nie wp\u0142ywaj\u0105 na inne fragmenty. Dla ka\u017cdego fragmentu obowi\u0105zuje w\u0142asny zakres czasowy.<\/p>\n<p><img decoding=\"async\" alt=\"Wysoka wydajno\u015b\u0107 i natywne partycjonowanie: Zabbix z obs\u0142ug\u0105 TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/91a24560ff12aa17f98689e3445f50e1.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>TimescaleDB vs PostgreSQL<\/h3>\n<p>\nTimescaleDB dzia\u0142a naprawd\u0119 efektywnie. Producenci rozszerzenia twierdz\u0105, \u017ce u\u017cywaj\u0105 bardziej odpowiedniego algorytmu przetwarzania zapyta\u0144, w szczeg\u00f3lno\u015bci &lt;code&gt;wstawek&lt;\/code&gt;. Gdy rozmiary wstawek datasetu rosn\u0105, algorytm utrzymuje sta\u0142\u0105 wydajno\u015b\u0107.<\/p>\n<p><img decoding=\"async\" alt=\"Wysoka wydajno\u015b\u0107 i natywne partycjonowanie: Zabbix z obs\u0142ug\u0105 TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/52f042018180ffd2cb6a2cf4a3af603e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPo przekroczeniu 200 milion\u00f3w wierszy PostgreSQL zazwyczaj zaczyna mocno traci\u0107 wydajno\u015b\u0107, a\u017c do zera. TimescaleDB pozwala efektywnie wstawia\u0107 \u00abwstawki\u00bb przy dowolnej ilo\u015bci danych.<\/p>\n<h3>Instalacja<\/h3>\n<p>\nInstalacja TimescaleDB jest wystarczaj\u0105co prosta dla wszystkich pakiet\u00f3w. W <noindex><a rel=\"nofollow\" href=\"https:\/\/docs.timescale.com\/v1.3\/getting-started\">dokumentacji<\/a><\/noindex> wszystko jest opisane szczeg\u00f3\u0142owo \u2014 zale\u017cy od oficjalnych pakiet\u00f3w PostgreSQL. TimescaleDB mo\u017cna r\u00f3wnie\u017c zbudowa\u0107 i skompilowa\u0107 r\u0119cznie.<\/p>\n<p>Dla bazy danych Zabbix po prostu aktywujemy rozszerzenie:<\/p>\n<pre><code class=\"sql\">echo \"CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;\" | sudo -u postgres psql zabbix<\/code><\/pre>\n<p>\nAktywujesz <code>rozszerzenie<\/code> i tworzysz je dla bazy danych Zabbix. Ostatnim krokiem jest stworzenie hipertabeli.<\/p>\n<h3>Migracja tabel historii do TimescaleDB<\/h3>\n<p>\nDla tego jest specjalna funkcja <code>create_hypertable<\/code>:<\/p>\n<pre><code class=\"sql\">SELECT create_hypertable(\u2018history\u2019, \u2018clock\u2019, chunk_time_interval =&gt; 86400, migrate_data =&gt; true);\nSELECT create_hypertable(\u2018history_unit\u2019, \u2018clock\u2019, chunk_time_interval =&gt; 86400, migrate_data =&gt; true);\nSELECT create_hypertable(\u2018history_log\u2019, \u2018clock\u2019, chunk_time_interval =&gt; 86400, migrate_data =&gt; true);\nSELECT create_hypertable(\u2018history_text\u2019, \u2018clock\u2019, chunk_time_interval =&gt; 86400, migrate_data =&gt; true);\nSELECT create_hypertable(\u2018history_str\u2019, \u2018clock\u2019, chunk_time_interval =&gt; 86400, migrate_data =&gt; true);\nSELECT create_hypertable(\u2018trends\u2019, \u2018clock\u2019, chunk_time_interval =&gt; 86400, migrate_data =&gt; true);\nSELECT create_hypertable(\u2018trends_unit\u2019, \u2018clock\u2019, chunk_time_interval =&gt; 86400, migrate_data =&gt; true);\nUPDATE config SET db_extension=\u2019timescaledb\u2019, hk_history_global=1, hk_trends_global=1<\/code><\/pre>\n<p>\nFunkcja ma trzy parametry. Pierwszy \u2014<strong> tabela w bazie danych<\/strong>, dla kt\u00f3rej nale\u017cy utworzy\u0107 hipertabel\u0119. Drugi \u2014 <strong>pole<\/strong>, na podstawie kt\u00f3rego nale\u017cy utworzy\u0107 <code>chunk_time_interval<\/code> \u2014 interwa\u0142 chunk\u00f3w partycji, kt\u00f3re nale\u017cy u\u017cywa\u0107. W moim przypadku interwa\u0142 to jeden dzie\u0144 \u2014 86 400.<\/p>\n<p>Trzeci parametr \u2014 <code><strong>migracja_danych<\/strong><\/code>. Je\u015bli ustawisz <code>true<\/code>, wszystkie istniej\u0105ce dane zostan\u0105 przeniesione do wcze\u015bniej stworzonych chunk\u00f3w. Osobi\u015bcie u\u017cywa\u0142em <code>migracja_danych<\/code>. Mia\u0142em oko\u0142o 1 TB, co zaj\u0119\u0142o ponad godzin\u0119. Nawet w niekt\u00f3rych przypadkach podczas test\u00f3w usuwa\u0142em niepotrzebne dane historyczne typu znakowego, aby ich nie przenosi\u0107.<\/p>\n<p>Ostatni krok \u2014\u00a0<code><strong>UPDATE<\/strong><\/code>: w <code>db_extension<\/code> ustawiamy <code>timescaledb<\/code>, aby baza danych rozumia\u0142a, \u017ce istnieje to rozszerzenie. Zabbix go aktywuje i poprawnie u\u017cywa sk\u0142adni oraz zapyta\u0144 ju\u017c do bazy danych \u2014 tych funkcji, kt\u00f3re s\u0105 niezb\u0119dne dla TimescaleDB.<\/p>\n<h2>Konfiguracja sprz\u0119tu<\/h2>\n<p>\nU\u017cywa\u0142em dw\u00f3ch serwer\u00f3w. Pierwszy \u2014 <strong>maszyna VMware<\/strong>. Jest do\u015b\u0107 ma\u0142a: 20 procesor\u00f3w Intel\u00ae Xeon\u00ae CPU E5-2630 v 4 @ 2.20GHz, 16 GB pami\u0119ci RAM i dysk SSD o pojemno\u015bci 200 GB.<\/p>\n<p>Zainstalowa\u0142em na niej PostgreSQL 10.8 z systemem operacyjnym Debian 10.8-1.pgdg90+1 oraz systemem plik\u00f3w xfs. Wszystko zosta\u0142o minimalnie skonfigurowane, aby u\u017cywa\u0107 tej konkretnej bazy danych, z wyj\u0105tkiem tego, co b\u0119dzie u\u017cywa\u0107 sam Zabbix.<\/p>\n<p>Na tej samej maszynie znajdowa\u0142 si\u0119 serwer Zabbix, PostgreSQL i <strong>agenci obci\u0105\u017cenia<\/strong>. Mia\u0142em 50 aktywnych agent\u00f3w, kt\u00f3rzy u\u017cywali <code>LoadableModule<\/code>, aby bardzo szybko generowa\u0107 r\u00f3\u017cne wyniki: liczby, napisy. Zasila\u0142em baz\u0119 du\u017c\u0105 ilo\u015bci\u0105 danych.<\/p>\n<p>Pocz\u0105tkowa konfiguracja zawiera\u0142a <strong>5 000 element\u00f3w<\/strong> danych na ka\u017cdy host. Prawie ka\u017cdy element zawiera\u0142 wyzwalacz, aby to przypomina\u0142o rzeczywiste instalacje. W niekt\u00f3rych przypadkach by\u0142o wi\u0119cej ni\u017c jeden wyzwalacz. Na jeden w\u0119ze\u0142 sieci przypada\u0142o <strong>3 000-7 000 wyzwalaczy<\/strong>.<\/p>\n<p>Interwa\u0142 aktualizacji element\u00f3w danych \u2014 <strong>4-7 sekund<\/strong>Obci\u0105\u017ca\u0142em system, u\u017cywaj\u0105c nie tylko 50 agent\u00f3w, ale tak\u017ce dodaj\u0105c ich wi\u0119cej. Ponadto, za pomoc\u0105 element\u00f3w danych dynamicznych regulowa\u0142em obci\u0105\u017cenie i zmniejsza\u0142em interwa\u0142 aktualizacji do 4 s.<\/p>\n<h3>PostgreSQL. 35 000 nvps<\/h3>\n<p>\nPierwsze uruchomienie na tym sprz\u0119cie mia\u0142o miejsce z czystym PostgreSQL \u2014 35 tys. warto\u015bci na sekund\u0119. Jak wida\u0107, wstawianie danych zajmuje u\u0142amki sekundy \u2014 wszystko jest w porz\u0105dku i szybko. Jedynym problemem jest to, \u017ce dysk SSD o pojemno\u015bci 200 GB szybko si\u0119 zape\u0142nia.<\/p>\n<p><img decoding=\"async\" alt=\"Wysoka wydajno\u015b\u0107 i natywne partycjonowanie: Zabbix z obs\u0142ug\u0105 TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/e84b2eb0f6fbbd902c5feab367c750ee.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nTo standardowy dashboard wydajno\u015bci Zabbix \u2014 serwery.<\/p>\n<p><img decoding=\"async\" alt=\"Wysoka wydajno\u015b\u0107 i natywne partycjonowanie: Zabbix z obs\u0142ug\u0105 TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/c3afe021acf8e272813b8d8c2f82e762.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPierwszy niebieski wykres \u2014 liczba warto\u015bci na sekund\u0119. Drugi wykres po prawej \u2014 obci\u0105\u017cenie proces\u00f3w zbieraj\u0105cych. Trzeci \u2014 obci\u0105\u017cenie wewn\u0119trznych proces\u00f3w zbieraj\u0105cych: syncery historii i Housekeeper, kt\u00f3ry by\u0142 tu aktywny przez ca\u0142kiem d\u0142ugi czas.<\/p>\n<p>Czwarty wykres pokazuje wykorzystanie HistoryCache. To pewnego rodzaju bufor przed wstawianiem do bazy danych. Zielony pi\u0105ty wykres pokazuje u\u017cycie ValueCache, czyli ile hit\u00f3w ValueCache dla wyzwalaczy \u2014 to kilka tysi\u0119cy warto\u015bci na sekund\u0119.<\/p>\n<h3>PostgreSQL. 50 000 nvps<\/h3>\n<p>\nNast\u0119pnie zwi\u0119kszy\u0142em obci\u0105\u017cenie do 50 tys. warto\u015bci na sekund\u0119 na tym samym sprz\u0119cie.<\/p>\n<p><img decoding=\"async\" alt=\"Wysoka wydajno\u015b\u0107 i natywne partycjonowanie: Zabbix z obs\u0142ug\u0105 TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/8f10944486d5502b57d36059382d551b.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPodczas \u0142adowania z Housekeeperem wstawienie 10 tys. warto\u015bci zajmowa\u0142o 2-3 s.<\/p>\n<p><img decoding=\"async\" alt=\"Wysoka wydajno\u015b\u0107 i natywne partycjonowanie: Zabbix z obs\u0142ug\u0105 TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/5228c1735f0ee2da7f827093f3c7b1f9.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<em>Housekeeper zaczyna ju\u017c przeszkadza\u0107 w pracy.<\/em><\/p>\n<p>Na trzecim wykresie wida\u0107, \u017ce og\u00f3lnie obci\u0105\u017cenie trapper\u00f3w i syncer\u00f3w historii nadal utrzymuje si\u0119 na poziomie 60%. Na czwartym wykresie HistoryCache w czasie pracy Housekeepera zaczyna by\u0107 do\u015b\u0107 aktywnie zape\u0142niony. Zape\u0142ni\u0142 si\u0119 w 20% \u2014 to oko\u0142o 0,5 GB.<\/p>\n<h3>PostgreSQL. 80 000 nvps<\/h3>\n<p>\nNast\u0119pnie zwi\u0119kszy\u0142em obci\u0105\u017cenie do 80 tys. warto\u015bci na sekund\u0119. To oko\u0142o 400 tys. element\u00f3w danych i 280 tys. wyzwalaczy.<\/p>\n<p><img decoding=\"async\" alt=\"Wysoka wydajno\u015b\u0107 i natywne partycjonowanie: Zabbix z obs\u0142ug\u0105 TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/f6c6b0d6793f96523f7406e68f98c608.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<em>Wstawienie przy obci\u0105\u017ceniu trzydziestu syncer\u00f3w historii jest ju\u017c do\u015b\u0107 wysokie.<\/em><\/p>\n<p>Zwi\u0119ksza\u0142em tak\u017ce r\u00f3\u017cne parametry: syncery historii, cache.<\/p>\n<p><img decoding=\"async\" alt=\"Wysoka wydajno\u015b\u0107 i natywne partycjonowanie: Zabbix z obs\u0142ug\u0105 TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/6ca7edd76aea6fdec00a61a0a6dc34e5.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nNa moim sprz\u0119cie obci\u0105\u017cenie syncer\u00f3w historii osi\u0105ga\u0142o maksimum. HistoryCache szybko zape\u0142nia\u0142 si\u0119 danymi \u2014 w buforze zgromadzi\u0142y si\u0119 dane do przetworzenia.<\/p>\n<p>Przez ca\u0142y ten czas obserwowa\u0142em, jak wykorzystywane s\u0105 procesor, pami\u0119\u0107 RAM i inne parametry systemu, i odkry\u0142em, \u017ce wykorzystanie dysk\u00f3w by\u0142o maksymalne.<\/p>\n<p><img decoding=\"async\" alt=\"Wysoka wydajno\u015b\u0107 i natywne partycjonowanie: Zabbix z obs\u0142ug\u0105 TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/e964a000156b561accd23b4e1644f4a8.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nUzyska\u0142em wykorzystanie <strong>maksymalnych mo\u017cliwo\u015bci dysku<\/strong> na tym sprz\u0119cie i na tej maszynie wirtualnej. Przy takiej intensywno\u015bci PostgreSQL zacz\u0105\u0142 aktywnie zrzuca\u0107 dane, a dysk nie nad\u0105\u017ca\u0142 ju\u017c z operacjami zapisu i odczytu.<\/p>\n<h3>Drugi serwer<\/h3>\n<p>\nWzi\u0105\u0142em inny serwer, kt\u00f3ry mia\u0142 ju\u017c 48 procesor\u00f3w i 128 GB pami\u0119ci RAM. Dostosowa\u0142em go \u2013 zainstalowa\u0142em 60 history syncer i osi\u0105gn\u0105\u0142em przyzwoit\u0105 wydajno\u015b\u0107.<\/p>\n<p><img decoding=\"async\" alt=\"Wysoka wydajno\u015b\u0107 i natywne partycjonowanie: Zabbix z obs\u0142ug\u0105 TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/591fc759b336d5fb2091460036b136bf.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nW rzeczywisto\u015bci to ju\u017c granica wydajno\u015bci, gdzie trzeba podj\u0105\u0107 jakie\u015b dzia\u0142ania.<\/p>\n<h3>TimescaleDB. 80 000 nvps<\/h3>\n<p>\nMoim g\u0142\u00f3wnym celem jest przetestowa\u0107 mo\u017cliwo\u015bci TimescaleDB pod obci\u0105\u017ceniem Zabbixa. 80 tysi\u0119cy warto\u015bci na sekund\u0119 to du\u017co, cz\u0119stotliwo\u015b\u0107 zbierania metryk (poza Yandexem, oczywi\u015bcie) oraz znaczny \u201esetup\u201d.<\/p>\n<p><img decoding=\"async\" alt=\"Wysoka wydajno\u015b\u0107 i natywne partycjonowanie: Zabbix z obs\u0142ug\u0105 TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/aa569847e7bc31baab91661db1ee78a2.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nNa ka\u017cdym wykresie s\u0105 spadki \u2014 to w\u0142a\u015bnie migracja danych. Po spadkach na serwerze Zabbix profil obci\u0105\u017cenia history syncer zmieni\u0142 si\u0119 znacz\u0105co \u2014 spad\u0142 trzykrotnie.<\/p>\n<blockquote><p>TimescaleDB pozwala na wstawianie danych prawie trzy razy szybciej i u\u017cywanie mniej HistoryCache.<\/p><\/blockquote>\n<p>\nOdpowiednio, dane b\u0119d\u0105 dostarczane na czas.<\/p>\n<h3>TimescaleDB. 120 000 nvps<\/h3>\n<p>\nNast\u0119pnie zwi\u0119kszy\u0142em liczb\u0119 element\u00f3w danych do 500 tysi\u0119cy. G\u0142\u00f3wnym celem by\u0142o przetestowanie mo\u017cliwo\u015bci TimescaleDB \u2013 uzyska\u0142em obliczon\u0105 warto\u015b\u0107 125 tysi\u0119cy warto\u015bci na sekund\u0119.<\/p>\n<p><img decoding=\"async\" alt=\"Wysoka wydajno\u015b\u0107 i natywne partycjonowanie: Zabbix z obs\u0142ug\u0105 TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/4770ca4030e1c086f2fd9305a12496bb.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nTo dzia\u0142aj\u0105cy \u201esetup\u201d, kt\u00f3ry mo\u017ce d\u0142ugo funkcjonowa\u0107. Ale poniewa\u017c m\u00f3j dysk mia\u0142 tylko 1,5 TB, zape\u0142ni\u0142em go w ci\u0105gu kilku dni.<\/p>\n<p><img decoding=\"async\" alt=\"Wysoka wydajno\u015b\u0107 i natywne partycjonowanie: Zabbix z obs\u0142ug\u0105 TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/1ad521b909a22a7db81a9ed802d348e7.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nNajwa\u017cniejsze, \u017ce w tym samym czasie tworzono nowe partycje w TimescaleDB.<\/p>\n<p>Dla wydajno\u015bci jest to ca\u0142kowicie niewidoczne. Kiedy partycje s\u0105 tworzone w MySQL, na przyk\u0142ad, wszystko dzia\u0142a inaczej. Zwykle dzieje si\u0119 to w nocy, poniewa\u017c blokuje og\u00f3lne wstawianie, prac\u0119 z tabelami i mo\u017ce prowadzi\u0107 do degradacji us\u0142ug. W przypadku TimescaleDB to nie wyst\u0119puje.<\/p>\n<p>Na przyk\u0142ad poka\u017c\u0119 jeden wykres z wielu w community. Na obrazku w\u0142\u0105czono TimescaleDB, dzi\u0119ki temu obci\u0105\u017cenie zwi\u0105zane z u\u017cyciem io.weight na procesorze spad\u0142o. U\u017cycie element\u00f3w wewn\u0119trznych proces\u00f3w r\u00f3wnie\u017c zmniejszy\u0142o si\u0119. Chocia\u017c to zwyk\u0142a wirtualka na standardowych dyskach talerzowych, a nie SSD.<\/p>\n<p><img decoding=\"async\" alt=\"Wysoka wydajno\u015b\u0107 i natywne partycjonowanie: Zabbix z obs\u0142ug\u0105 TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/bea0cd0f1448e1d1b3a5f979d51ce61c.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Wnioski<\/h2>\n<p>\n<strong>TimescaleDB to dobre rozwi\u0105zanie dla ma\u0142ych \u201esetup\u201d.<\/strong>, kt\u00f3re napotykaj\u0105 na ograniczenia wydajno\u015bci dysku. Pozwoli to na dobr\u0105 kontynuacj\u0119 pracy a\u017c do migracji bazy danych na szybszy sprz\u0119t.<\/p>\n<p>TimescaleDB jest prosty w konfiguracji, zapewnia wzrost wydajno\u015bci, dobrze wsp\u00f3\u0142pracuje z Zabbix i <strong>ma przewagi w por\u00f3wnaniu z PostgreSQL.<\/strong>.<\/p>\n<p>Je\u015bli korzystasz z PostgreSQL i nie planujesz go zmienia\u0107, to polecam <strong>u\u017cywa\u0107 PostgreSQL z rozszerzeniem TimescaleDB w po\u0142\u0105czeniu z Zabbixem.<\/strong>To rozwi\u0105zanie efektywnie dzia\u0142a do \u015brednich \u201esetup\u201d.<\/p>\n<blockquote>\n<p>M\u00f3wi\u0105c \u201ewysoka wydajno\u015b\u0107\u201d \u2014 mamy na my\u015bli <noindex><a rel=\"nofollow\" href=\"https:\/\/www.highload.ru\/moscow\/2019\">HighLoad++<\/a><\/noindex>. Czeka\u0107, aby zapozna\u0107 si\u0119 z technologiami i praktykami, kt\u00f3re umo\u017cliwiaj\u0105 serwisom obs\u0142ug\u0119 milion\u00f3w u\u017cytkownik\u00f3w, to ju\u017c nied\u0142ugo. Lista <noindex><a rel=\"nofollow\" href=\"https:\/\/www.highload.ru\/moscow\/2019\/abstracts\">raport\u00f3w<\/a><\/noindex> na 7 i 8 listopada ju\u017c zosta\u0142a przygotowana, a <noindex><a rel=\"nofollow\" href=\"https:\/\/www.highload.ru\/moscow\/2019\/meetups\">meetupy<\/a><\/noindex> mo\u017cna jeszcze zaproponowa\u0107.<\/p>\n<p>\u015aled\u017a nasz\u0105 <noindex><a rel=\"nofollow\" href=\"http:\/\/eepurl.com\/VYVaf\">list\u0119 mailingow\u0105<\/a><\/noindex> i <noindex><a rel=\"nofollow\" href=\"https:\/\/t.me\/HighLoadChannel\">telegram<\/a><\/noindex>, w kt\u00f3rych ujawniamy szczeg\u00f3\u0142y nadchodz\u0105cej konferencji i dowiedz si\u0119, jak maksymalnie skorzysta\u0107.<\/p>\n<\/blockquote>\n<p>\u0179r\u00f3d\u0142o: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/oleg-bunin\/blog\/470902\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>Zabbix \u2014 \u044d\u0442\u043e \u0441\u0438\u0441\u0442\u0435\u043c\u0430 \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430. \u041a\u0430\u043a \u0438 \u043b\u044e\u0431\u0430\u044f \u0434\u0440\u0443\u0433\u0430\u044f \u0441\u0438\u0441\u0442\u0435\u043c\u0430, \u043e\u043d\u0430 \u0441\u0442\u0430\u043b\u043a\u0438\u0432\u0430\u0435\u0442\u0441\u044f \u0441 \u0442\u0440\u0435\u043c\u044f \u043e\u0441\u043d\u043e\u0432\u043d\u044b\u043c\u0438 \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0430\u043c\u0438 \u0432\u0441\u0435\u0445 \u0441\u0438\u0441\u0442\u0435\u043c \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430: \u0441\u0431\u043e\u0440 \u0438 \u043e\u0431\u0440\u0430\u0431\u043e\u0442\u043a\u0430 \u0434\u0430\u043d\u043d\u044b\u0445, \u0445\u0440\u0430\u043d\u0435\u043d\u0438\u0435 \u0438\u0441\u0442\u043e\u0440\u0438\u0438, \u0435\u0435 \u043e\u0447\u0438\u0441\u0442\u043a\u0430. \u042d\u0442\u0430\u043f\u044b \u043f\u043e\u043b\u0443\u0447\u0435\u043d\u0438\u044f, \u043e\u0431\u0440\u0430\u0431\u043e\u0442\u043a\u0438 \u0438 \u0437\u0430\u043f\u0438\u0441\u0438 \u0434\u0430\u043d\u043d\u044b\u0445 \u0437\u0430\u043d\u0438\u043c\u0430\u044e\u0442 \u0432\u0440\u0435\u043c\u044f. \u041d\u0435\u043c\u043d\u043e\u0433\u043e, \u043d\u043e \u0434\u043b\u044f \u043a\u0440\u0443\u043f\u043d\u043e\u0439 \u0441\u0438\u0441\u0442\u0435\u043c\u044b \u044d\u0442\u043e \u043c\u043e\u0436\u0435\u0442 \u0432\u044b\u043b\u0438\u0432\u0430\u0442\u044c\u0441\u044f \u0432 \u0431\u043e\u043b\u044c\u0448\u0438\u0435 \u0437\u0430\u0434\u0435\u0440\u0436\u043a\u0438. \u041f\u0440\u043e\u0431\u043b\u0435\u043c\u0430 \u0445\u0440\u0430\u043d\u0435\u043d\u0438\u044f \u2014 \u044d\u0442\u043e \u0432\u043e\u043f\u0440\u043e\u0441 \u0434\u043e\u0441\u0442\u0443\u043f\u0430 \u043a \u0434\u0430\u043d\u043d\u044b\u043c. \u041e\u043d\u0438 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":29204,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-38927","post","type-post","status-publish","format-standard","has-post-thumbnail","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=\"Zabbix \u2014 \u044d\u0442\u043e \u0441\u0438\u0441\u0442\u0435\u043c\u0430 \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430.\" \/>\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\/vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie-zabbix-s-podderzhkoj-timescaledb\" \/>\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\udd47\u0412\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: Zabbix \u0441 \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u043a\u043e\u0439 TimescaleDB | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"Zabbix \u2014 \u044d\u0442\u043e \u0441\u0438\u0441\u0442\u0435\u043c\u0430 \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie-zabbix-s-podderzhkoj-timescaledb\" \/>\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=\"2019-10-31T19:26:48+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T19:26:48+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\udd47 Wysoka wydajno\u015b\u0107 i natywna partycjonowanie: Zabbix z wsparciem TimescaleDB | ProHoster","description":"Zabbix to system monitorowania.","canonical_url":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie-zabbix-s-podderzhkoj-timescaledb","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\udd47\u0412\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: Zabbix \u0441 \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u043a\u043e\u0439 TimescaleDB | ProHoster","og:description":"Zabbix \u2014 \u044d\u0442\u043e \u0441\u0438\u0441\u0442\u0435\u043c\u0430 \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430.","og:url":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie-zabbix-s-podderzhkoj-timescaledb","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":"2019-10-31T19:26:48+00:00","article:modified_time":"2019-10-31T19:26:48+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"38927","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":"2026-01-23 23:59:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 21:14:06","updated":"2026-01-23 23:59:19","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\/38927","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=38927"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/posts\/38927\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/media\/29204"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/media?parent=38927"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/categories?post=38927"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/tags?post=38927"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}