Omówimy pracę Zabbix z bazą danych TimescaleDB jako backendem. Pokażemy, jak uruchomić od podstaw oraz jak migrować z PostgreSQL. Przedstawimy także porównawcze testy wydajności dwóch konfiguracji.
HighLoad++ Syberia 2019. Sala „Tomsk”. 24 czerwca, 16:00. Tezy oraz . Następna konferencja HighLoad++ odbędzie się 6 i 7 kwietnia 2020 roku w Petersburgu. Szczegóły i bilety .
Andriej Guścin (dalej – AG): – Jestem inżynierem wsparcia technicznego ZABBIX (dalej – „Zabbix”), szkoleniowcem. Pracuję od ponad 6 lat w wsparciu technicznym i bezpośrednio zajmowałem się wydajnością. Dziś opowiem o wydajności, jaką może zapewnić TimescaleDB, w porównaniu do zwykłego PostgreSQL 10. Będzie też krótki wstęp o tym, jak to wszystko działa.
Główne wyzwania wydajności: od zbierania do czyszczenia danych
Zacznijmy od tego, że istnieją określone wyzwania wydajności, z którymi boryka się każdy system monitorowania. Pierwszym wyzwaniem wydajności jest szybkie zbieranie i przetwarzanie danych.
Dobry system monitorowania powinien szybko i terminowo zbierać wszystkie dane, przetwarzać je zgodnie z wyrażeniami wyzwalającymi, czyli przetwarzać według jakichś kryteriów (w różnych systemach jest to różnie) i zapisywać w bazie danych, aby później móc te dane wykorzystać.
Drugim wyzwaniem wydajności jest przechowywanie historii. Należy przechowywać w bazie danych często i mieć szybki oraz wygodny dostęp do tych metryk, które zostały zebrane w określonym okresie czasu. Najważniejsze, aby te dane było wygodnie uzyskać, wykorzystać je w raportach, wykresach, wyzwalaczach, w pewnych wartościach progowych, do powiadomień itd.
Trzecim wyzwaniem wydajności jest czyszczenie historii, co oznacza, że nadchodzi taki dzień, kiedy nie trzeba już przechowywać szczegółowych metryk, które były zbierane przez 5 lat (nawet przez miesiące lub dwa). Niektóre węzły sieci zostały usunięte, albo jakieś hosty, a metryki już nie są potrzebne ponieważ stały się nieaktualne i przestały być zbierane. To wszystko trzeba wyczyścić, aby baza danych nie rozrosła się do dużych rozmiarów. Ogólnie rzecz biorąc, czyszczenie historii najczęściej stanowi poważne wyzwanie dla przechowywania – często ma to silny wpływ na wydajność.
Jak rozwiązać problemy z cachowaniem?
Teraz będę mówić konkretnie o „Zabbixie”. W „Zabbixie” pierwszy i drugi wywołania są rozwiązywane za pomocą cachowania.
Zbieranie i przetwarzanie danych – używamy pamięci podręcznej do przechowywania wszystkich tych danych. O tych danych będzie teraz mowa szczegółowo.
Na stronie bazy danych również istnieje pewne cachowanie dla głównych zapytań – dla wykresów i innych elementów.
Cachowanie po stronie samego serwera Zabbix: mamy ConfigurationCache, ValueCache, HistoryCache, TrendsCache. Czym to jest?
ConfigurationCache – to główny cache, w którym przechowujemy metryki, hosty, elementy danych, wyzwalacze; wszystko, co jest potrzebne do przetwarzania wstępnego, zbierania danych, z jakich hostów zbierać oraz z jaką częstotliwością. Wszystko to jest przechowywane w ConfigurationCache, aby nie wchodzić do bazy danych ani nie tworzyć zbędnych zapytań. Po uruchomieniu serwera aktualizujemy ten cache (tworzymy) i okresowo go aktualizujemy (w zależności od ustawień konfiguracyjnych).
Cachowanie w Zabbixie. Zbieranie danych.
Tutaj schemat jest dość duży:
Główne elementy w schemacie – to te zbieracze:
To same procesy zbierania, różne „pollery”, które odpowiadają za różne rodzaje zbierania. Zbierają dane po icmp, ipmi, różnymi protokołami i przekazują je do przetwarzania wstępnego.
PreProcessing HistoryCache
Jeśli mamy obliczane elementy danych (ci, którzy znają „Zabbixa” – wiedzą), to są obliczane, agregacyjne elementy danych – pobieramy je bezpośrednio z ValueCache. O tym, jak on jest wypełniany, opowiem później. Wszystkie te zbieracze używają ConfigurationCache do uzyskania swoich zadań i następnie przekazują je do przetwarzania wstępnego.
Przetwarzanie wstępne również korzysta z ConfigurationCache do uzyskania kroków przetwarzania wstępnego, przetwarza te dane na różne sposoby. Począwszy od wersji 4.2, zostało to przeniesione na proxy. To bardzo wygodne, ponieważ samo przetwarzanie wstępne to dość ciężka operacja. Jeśli masz bardzo dużego „Zabbixa”, z dużą ilością elementów danych i wysoką częstotliwością zbierania, to znacznie ułatwia pracę.
W związku z tym, po tym jak w jakiś sposób przetworzyliśmy te dane za pomocą przetwarzania wstępnego, zapisujemy je w HistoryCache, aby je dalej przetwarzać. Na tym kończy się zbieranie danych. Przechodzimy do głównego procesu.
Praca History syncer
Główny proces w "Zabbixie" (ponieważ jest to architektura monolityczna) – History syncer. To główny proces, który zajmuje się atomową obróbką każdego elementu danych, to znaczy każdej wartości:
- przychodzi wartość (bierze ją z HistoryCache);
- sprawdza w Configuration syncer: czy są jakieś wyzwalacze do obliczenia – oblicza je;
jeśli są – tworzy zdarzenia, tworzy eskalację, aby wygenerować powiadomienie, jeśli to konieczne zgodnie z konfiguracją; - zapisuje wyzwalacze do dalszej obróbki, agregacji; jeśli agregujesz za ostatnią godzinę i tak dalej, ta wartość zapamiętuje ją w ValueCache, aby nie odwoływać się do tabeli historii; w ten sposób ValueCache wypełnia się potrzebnymi danymi, które są niezbędne do obliczenia wyzwalaczy, obliczanych elementów itp.;
- następnie History syncer zapisuje wszystkie dane do bazy danych;
- baza danych zapisuje je na dysku – na tym proces przetwarzania się kończy.
Bazy danych. Caching
Po stronie bazy danych, kiedy chcesz zobaczyć wykresy lub jakieś raporty dotyczące zdarzeń, istnieją różne cache. Jednak w ramach tego referatu nie będę o nich mówić.
Dla MySQL istnieje Innodb_buffer_pool, a także wiele różnych cache, które również można skonfigurować.
Ale to są podstawowe:
- shared_buffers;
- effective_cache_size;
- shared_pool.
Podaję dla wszystkich baz danych, że istnieją określone cache, które pozwalają przechowywać w pamięci RAM te dane, które często są potrzebne do zapytań. Mają swoje technologie do tego.
O wydajności bazy danych
Odpowiednio, istnieje konkurencyjne środowisko, to znaczy serwer "Zabbix" zbiera dane i zapisuje je. Przy ponownym uruchomieniu też odczytuje z historii, aby wypełnić ValueCache itd. Tutaj mogą być skrypty i raporty, które korzystają z "Zabbix API", który jest zbudowany na podstawie interfejsu webowego. "Zabbix API" wchodzi do bazy danych i uzyskuje niezbędne dane do generowania wykresów, raportów lub jakiejś listy zdarzeń, ostatnich problemów.
Bardzo popularnym rozwiązaniem do wizualizacji jest Grafana, która jest używana przez naszych użytkowników. Może bezpośrednio wchodzić zarówno przez "Zabbix API", jak i przez bazę danych. To również stwarza pewną konkurencję do uzyskiwania danych: potrzebna jest bardziej precyzyjna, dobra konfiguracja bazy danych, aby odpowiedzieć na szybkie wydawanie wyników i testowania.
Czyszczenie historii. W Zabbixie znajduje się Housekeeper
Trzecie wywołanie używane w „Zabbixie” to czyszczenie historii za pomocą Housekeepera. „Housekeeper” przestrzega wszystkich ustawień, tzn. w naszych elementach danych określono, jak długo przechowywać (w dniach), ile przechowywać trendy, dynamikę zmian.
Nie wspomniałem o TrendCache, który obliczamy w locie: dane przychodzą, agregujemy je za jedną godzinę (głównie są to liczby za ostatnią godzinę), średnia wartość / minimalna i zapisujemy to raz na godzinę w tabeli dynamiki zmian („Trendy”). „Housekeeper” uruchamia się i usuwa dane z bazy danych zwykłymi selektami, co nie zawsze jest efektywne.
Jak zrozumieć, że to jest nieefektywne? Na wykresach wydajności procesów wewnętrznych możesz zobaczyć taki obraz:
Twój History syncer jest stale zajęty (czerwony wykres). A „pomarańczowy” wykres, który idzie na górze. To „Housekeeper”, który się uruchamia i czeka od bazy danych, aż usunie wszystkie wiersze, które zlecił.
Weźmy jakiś ID elementu: trzeba usunąć ostatnie 5 tysięcy; oczywiście, według indeksów. Ale zazwyczaj zbiór danych jest wystarczająco duży – baza danych i tak odczytuje to z dysku i podnosi do pamięci podręcznej, co jest bardzo drogą operacją dla bazy danych. W zależności od jej rozmiarów, może to prowadzić do określonych problemów z wydajnością.
Można wyłączyć „Housekeepera” prostym sposobem – mamy znany wszystkim interfejs internetowy. Ustawienia w administracji ogólnej (ustawienia dla „Housekeepera”) wyłączamy wewnętrzne housekeeping dla wewnętrznej historii i trendów. W związku z tym „Housekeeper” już tym nie zarządza:
Co można dalej zrobić? Wyłączyłeś, twoje wykresy się wyrównały… Jakie w takim przypadku mogą być dalsze problemy? Co może pomóc?
Partycjonowanie
Zwykle jest to konfigurowane w każdej relacyjnej bazie danych, które wymieniłem, w różny sposób. W MySQL istnieje własna technologia. Ale ogólnie są bardzo podobne, jeśli mówimy o PostgreSQL 10 i MySQL. Oczywiście jest tam wiele różnic wewnętrznych, jak to wszystko jest zrealizowane i jak to wpływa na wydajność. Ale ogólnie tworzenie nowej partycji często prowadzi również do określonych problemów.
W zależności od Twojej konfiguracji (jak dużo danych tworzysz w ciągu jednego dnia), zazwyczaj ustawia się najniższy – to 1 dzień/partycja, a dla „trendów”, dynamiki zmian – 1 miesiąc/nowa partycja. Może się to zmieniać, jeśli masz bardzo dużą konfigurację.
Od razu powiem o rozmiarach konfiguracji: do 5 tysięcy nowych wartości na sekundę (nvps) – to będzie uważane za małą konfigurację. Średnia to od 5 do 25 tysięcy wartości na sekundę. Wszystko, co powyżej, to już duże i bardzo duże instalacje, które wymagają bardzo starannej konfiguracji samej bazy danych.
W przypadku bardzo dużych instalacji 1 dzień – to może być nieoptymalne. Osobiście widziałem w MySQL partycje po 40 gigabajtów na dzień (a mogą być i większe). To bardzo duża ilość danych, która może powodować pewne problemy. Należy to zmniejszać.
Po co jest partycjonowanie?
Co daje partycjonowanie, myślę, że wszyscy wiedzą – to sekcjonowanie tabel. Często są to oddzielne pliki na dysku oraz zapytania span. Wybiera ono jedną partycję w sposób bardziej optymalny, jeśli to mieści się w standardowym partycjonowaniu.
Dla „Zabbiksa”, w szczególności, stosuje się po zakresie, czyli używamy znacznika czasowego (liczba zwykła, czas od początku epoki). Ustawiasz początek dnia/koniec dnia, a to stanowi partycję. W związku z tym, jeśli sięgasz po dane sprzed dwóch dni, wszystko to jest wybierane z bazy danych szybciej, ponieważ trzeba załadować tylko jeden plik do pamięci podręcznej i wydać (a nie dużą tabelę).
Wiele baz danych również przyspiesza wstawianie (do jednej tabeli dziecięcej). Mówię to na razie ogólnie, ale to również jest możliwe. Partycjonowanie często pomaga.
Elasticsearch dla NoSQL
Niedawno, w 3.4, wdrożyliśmy rozwiązanie dla NoSQL. Dodaliśmy możliwość zapisywania w Elasticsearch. Możesz zapisywać oddzielne typy: wybierasz – albo liczby, albo jakieś znaki; mamy tekst string, logi możesz zapisywać w Elasticsearch… W związku z tym interfejs webowy również będzie sięgał po Elasticsearch. To świetnie działa w niektórych przypadkach, ale w tej chwili można to wykorzystać.
TimescaleDB. Hiper-tabele
W wersji 4.4.2 zwróciliśmy uwagę na jedną rzecz, jaką jest TimescaleDB. Czym to jest? To rozszerzenie dla PostgreSQL, co oznacza, że ma natywny interfejs PostgreSQL. Ponadto to rozszerzenie pozwala na znacznie efektywniejszą pracę z danymi szeregów czasowych oraz automatyczne partycjonowanie. Jak to wygląda:
To jest hypertable – takie pojęcie w Timescale. To hipertablica, którą tworzysz, a w niej znajdują się chunk'i (chunk). Chunki to partycje, to tabele podrzędne, jeśli się nie mylę. To naprawdę wydajne.
TimescaleDB i PostgreSQL
Jak zapewniają producenci TimescaleDB, stosują bardziej poprawny algorytm przetwarzania zapytań, w szczególności insertów, który pozwala na utrzymanie mniej więcej stałej wydajności przy rosnącym rozmiarze zestawu danych. To znaczy, że po 200 milionach wierszy standardowy PostgreSQL zaczyna bardzo mocno zwalniać i traci wydajność dosłownie do zera, podczas gdy Timescale pozwala na jak najefektywniejsze wstawianie insertów przy dowolnej ilości danych.
Jak zainstalować TimescaleDB? To proste!
Jest w jego dokumentacji, opisano – można zainstalować z pakietów dla dowolnych... Zależy od oficjalnych pakietów PostgreSQL. Można również skompilować ręcznie. Tak się złożyło, że musiałem kompilować dla bazy danych.
W Zabbixie po prostu aktywujemy Extention. Myślę, że ci, którzy korzystali z Extention w PostgreSQL... Po prostu aktywujesz Extention, tworzysz go dla bazy danych Zabbix, której używasz.
I ostatni krok...
TimescaleDB. Migracja tabel historii
Musisz stworzyć hypertable. W tym celu jest specjalna funkcja – Create hypertable. W niej jako pierwszy parametr podajesz tabelę, która w tej bazie danych jest potrzebna (dla której należy stworzyć hipertablicę).
Pole, według którego ma być stworzone, oraz chunk_time_interval (to interwał chunków (partycji, które należy wykorzystać). 86 400 – to jeden dzień.
Parametr migrate_data: jeśli ustawisz na true, przenosi to wszystkie bieżące dane do wcześniej stworzonych chunków.
Osobiście używałem migrate_data – zajmuje to sporo czasu, w zależności od tego, jak dużą masz bazę danych. Miałem ponad terabajt – proces tworzenia zajmował ponad godzinę. W niektórych przypadkach podczas testowania usuwałem dane historyczne tekstu (history_text) i ciągu (history_str), żeby ich nie przenosić – nie były mi tak naprawdę interesujące.
I ostatnia aktualizacja, którą wprowadzamy w naszym db_extension: instalujemy TimescaleDB, aby baza danych, a w szczególności nasz 'Zabbix', rozumiała, że istnieje db_extension. Aktywuje go i używa poprawnej składni oraz zapytań do bazy danych, korzystając z tych 'funkcji', które są niezbędne dla TimescaleDB.
Konfiguracja serwera
Użyłem dwóch serwerów. Pierwszy serwer to wirtualna maszyna o dość małej mocy, 20 procesorów, 16 gigabajtów pamięci RAM. Skonfigurowałem na niej 'PostgreSQL' 10.8:
System operacyjny to był Debian, a system plików – xfs. Dokonałem minimalnych ustawień, aby używać właśnie tej bazy danych, z wyjątkiem tego, co będzie wykorzystywane przez 'Zabbix'. Na tej samej maszynie działał serwer 'Zabbix', PostgreSQL oraz agenci obciążenia.
Użyłem 50 aktywnych agentów, którzy korzystają z LoadableModule, aby szybko generować różne wyniki. To oni generowali ciągi, liczby itd. Przeładowywałem bazę danych dużą ilością danych. Początkowo konfiguracja zawierała 5000 elementów danych na każdy host, a każdy element danych miał mniej więcej jeden wyzwalacz – aby to było prawdziwe ustawienie. Czasami do działania wymagane są nawet więcej niż jeden wyzwalacz.
Interwał aktualizacji, samą obciążenie regulowałem tym, że nie tylko używałem 50 agentów (dodawałem więcej), ale także dzięki dynamicznym elementom danych, zmniejszałem interwał aktualizacji do 4 sekund.
Test wydajności. PostgreSQL: 36 tysięcy NVPs
Pierwsze uruchomienie, pierwsza konfiguracja miałem na czystym PostgreSQL 10 na tym sprzęcie (35 tysięcy wartości na sekundę). Ogólnie, jak widać na ekranie, wstawianie danych zajmuje ułamki sekundy – wszystko działa dobrze i szybko, dyski SSD (200 gigabajtów). Jedynie to, że 20 GB szybko się zapełnia.
Będzie jeszcze sporo takich wykresów. To standardowy dashboard wydajności serwera 'Zabbix'.
Pierwszy wykres – liczba wartości na sekundę (niebieski, u góry po lewej), 35 tysięcy wartości w tym przypadku. To (na górze w centrum) obciążenie procesów zbierania danych, a to (na górze po prawej) – obciążenie wewnętrznych procesów: history syncers oraz housekeeper, który tutaj (na dole w centrum) działał przez znaczny czas.
Ten wykres (na dole na środku) pokazuje wykorzystanie ValueCache – ile hitów ValueCache dla triggerów (kilka tysięcy wartości na sekundę). Inny ważny wykres – czwarty (na dole po lewej), który pokazuje wykorzystanie HistoryCache, o którym wspomniałem, będącym buforem przed wstawianiem do bazy danych.
Test wydajności. PostgreSQL: 50 tysięcy NVPs
Następnie zwiększyłem obciążenie do 50 tysięcy wartości na sekundę na tej samej maszynie. Przy obciążeniu „Hausskeeperem” 10 tysięcy wartości zapisywano już w 2-3 sekundy z obliczeniami. Co zresztą pokazuje następny zrzut ekranu:
„Hausskeeper” zaczyna już kolidować z działaniem, ale ogólnie obciążenie traperów history-synków wciąż utrzymuje się na poziomie 60 % (trzeci wykres, w górnym prawym rogu). HistoryCache podczas pracy „Hausskeepera” zaczyna się aktywnie zapełniać (na dole po lewej). Miał około pół gigabajta i zapełnił się o 20%.
Test wydajności. PostgreSQL: 80 tysięcy NVPs
Następnie zwiększyłem do 80 tysięcy wartości na sekundę:
To było około 400 tysięcy elementów danych, 280 tysięcy triggerów. Wstawka, jak widać, pod względem obciążenia history-synków (było ich 30) była już dostatecznie wysoka. Następnie zwiększałem różne parametry: history-synki, cache... Na tej maszynie obciążenie history-synków zaczęło wzrastać do maksimum, praktycznie „w pólce” – w związku z tym HistoryCache poszło w bardzo wysokie obciążenie:
Cały czas obserwowałem wszystkie parametry systemu (jak procesor jest używany, pamięć RAM) i odkryłem, że utylizacja dysków była maksymalna – osiągnąłem maksymalną wydajność tego dysku na tej maszynie, na tej maszynie wirtualnej. „Postgres” przy takiej intensywności zaczął dość aktywnie zrzucać dane, a dysk nie nadążał z zapisem, odczytem…
Wziąłem inny serwer, który miał już 48 procesorów i 128 gigabajtów pamięci RAM:
Dodatkowo go „tuningowałem” – zainstalowałem History syncer (60 sztuk) i osiągnąłem akceptowalną wydajność. W rzeczywistości nie jesteśmy „w pólce”, ale to już prawdopodobnie limit wydajności, gdzie wciąż należy coś z tym zrobić.
Test wydajności. TimescaleDB: 80 tysięcy NVPs
Miałem główne zadanie – użyć TimescaleDB. Na każdym wykresie widać spadek:
Te awarie to właśnie migracja danych. Po tym w serwerze „Zabbix” profil ładowania history syncerów, jak widzisz, bardzo się zmienił. Teraz umożliwia to niemal trzykrotne szybsze wstawianie danych i używa mniej HistoryCache – dzięki temu dane będą dostarczane na czas. Znowu, 80 tysięcy wartości na sekundę to dość wysoki wskaźnik (oczywiście nie dla „Yandexu”). Ogólnie jest to dość duża konfiguracja z jednym serwerem.
Test wydajności PostgreSQL: 120 tysięcy NVP.
Następnie zwiększyłem wartość liczby elementów danych do pół miliona i otrzymałem obliczoną wartość 125 tysięcy na sekundę:
I uzyskałem takie wykresy:
W zasadzie jest to działająca konfiguracja, która może działać przez dłuższy czas. Ale ponieważ miałem dysk o pojemności tylko 1,5 terabajta, zużyłem go w ciągu kilku dni. Najważniejsze jest to, że w tym samym czasie tworzyły się nowe partycje w TimescaleDB, a to działo się całkowicie niezauważalnie dla wydajności, czego nie można powiedzieć o MySQL.
Zwykle partycje tworzy się w nocy, ponieważ blokuje to wstawianie i pracę z tabelami, co może prowadzić do degradacji usługi. W tym przypadku tego nie ma! Głównym celem było sprawdzenie możliwości TimescaleDB. Oto wyniki: 120 tysięcy wartości na sekundę.
W społeczności znajdują się również przykłady:
Jedna osoba również włączyła TimescaleDB, a obciążenie związane z używaniem io.weight spadło na procesorze; a także wykorzystanie elementów procesów wewnętrznych również zmniejszyło się dzięki włączeniu TimescaleDB. I to na zwykłych dyskach twardych, czyli na zwykłej maszynie wirtualnej na zwykłych dyskach (nie SSD)!
Dla małych konfiguracji, które napotykają na wydajność dysku, TimescaleDB, jak mi się wydaje, to bardzo dobre rozwiązanie. Pozwoli ono całkiem nieźle pracować, zanim przejdzie się na szybsze podzespoły dla bazy danych.
Zapraszam wszystkich na nasze wydarzenia: Konferencja – w Moskwie, Szczyt – w Rydze. Korzystajcie z naszych kanałów – „Telegram”, forum, IRC. Jeśli macie jakiekolwiek pytania – przyjdźcie do nas na stoisko, możemy porozmawiać o wszystkim.
Pytania od publiczności
Pytanie z sali (dalej – A): – Jeśli TimescaleDB jest tak łatwy w konfiguracji i daje tak duży wzrost wydajności, to może warto to wykorzystać jako najlepszą praktykę do konfigurowania «Zabbix» z «Postgresem»? Czy są jakieś ukryte pułapki lub minusy tego rozwiązania, czy jednak, jeśli zdecydowałem się na «Zabbix», mogę spokojnie używać «Postgresa», od razu instalować «Timescale» i nie przejmować się żadnymi problemami?
AG: – Tak, powiedziałbym, że to dobra rekomendacja: używać «Postgresa» od razu z rozszerzeniem TimescaleDB. Jak już mówiłem, są liczne dobre opinie, mimo że ta «funkcja» jest eksperymentalna. Ale w rzeczywistości testy pokazują, że to świetne rozwiązanie (z TimescaleDB), i myślę, że będzie się rozwijać! Śledzimy, jak to rozszerzenie się rozwija i wprowadzimy potrzebne poprawki.
Nawet podczas rozwoju opieraliśmy się na jednej z ich znanych «funkcji»: można było pracować z chunkami trochę inaczej. Ale potem usunęli to w następnej wersji, i musieliśmy przestać opierać się na tym kodzie. Poleciłbym to rozwiązanie w wielu setupach. Jeśli używasz MySQL… Dla średnich setupów każde rozwiązanie dobrze działa.
A: – Na ostatnich wykresach od społeczności był wykres z «Housekeeper»:
On nadal działa. Co robi «Housekeeper» w przypadku TimescaleDB?
AG: – Teraz nie mogę dokładnie powiedzieć – spojrzę na kod i powiem dokładniej. Używa zapytań bezpośrednio TimescaleDB, nie do usuwania chunków, ale w jakiś sposób agreguje. Na razie nie jestem gotów odpowiedzieć na to techniczne pytanie. Na stoisku dzisiaj lub jutro wyjaśnimy.
A: – Mam podobne pytanie – o wydajność operacji usuwania w «Timescale».
A (odpowiedź z sali): – Kiedy usuwasz dane z tabeli, jeśli robisz to przez delete, musisz przejść przez tabelę – usunąć, oczyścić, oznaczyć wszystko do przyszłego vacuum. W «Timescale», ponieważ masz chunk, możesz to dropować. Mówiąc w skrócie, po prostu mówisz plikowi, który leży w big data: „Usuń!”
„Timescale“ po prostu rozumie, że ten chunk już nie istnieje. I ponieważ jest zintegrowany z harmonogramem zapytań, wychwytuje Twoje warunki w select lub w innych operacjach i od razu zdaje sobie sprawę, że ten chunk już nie istnieje – „Już tam nie pójdę!” (dane są niedostępne). I to wszystko! To znaczy, skanowanie tabeli zastępowane jest usunięciem pliku binarnego, więc to jest szybkie.
A: – Już poruszaliśmy temat nie-SQL. Jakkolwiek rozumiem, Zabbix nie potrzebuje zbytnio modyfikować danych, a wszystko to jest czymś w rodzaju loga. Czy można używać specjalizowanych baz danych, które nie mogą zmieniać swoich danych, ale jednocześnie o wiele szybciej zapisują, gromadzą, przekazują – Clickhouse, na przykład, coś w stylu Kafki?.. Kafka to również log! Czy można je jakoś zintegrować?
AG: – Eksport można zrealizować. Mamy pewną funkcjonalność od wersji 3.4: możesz zapisywać wszystkie historyczne pliki, wydarzenia, wszystko inne w plikach; a potem jakimś przetwornikiem wysyłać do innej bazy danych. W rzeczywistości wiele osób przerabia i pisze bezpośrednio do bazy danych. Synchronizatory historii na bieżąco zapisują to wszystko w plikach, rotują te pliki itd., a to możesz przerzucać do „Clickhouse”. Nie mogę nic powiedzieć o planach, ale być może dalsze wsparcie dla rozwiązań NoSQL (takich jak „Clickhouse”) będzie kontynuowane.
A: – W ogóle, wychodzi na to, że można całkowicie zrezygnować z Postgresa?
AG: – Oczywiście, najtrudniejszą częścią w Zabbixie są historyczne tabele, które stwarzają najwięcej problemów, oraz wydarzenia. W tym przypadku, jeśli nie będziesz długo przechowywać wydarzeń i będziesz przechowywać historię z trendami w jakimś innym szybkim magazynie, to ogólnie nie powinno być żadnych problemów.
A: – Możesz oszacować, jak wiele szybciej wszystko będzie działać, jeśli przejdziemy na „Clickhouse”, powiedzmy?
AG: – Nie testowałem. Myślę, że przynajmniej te same wyniki można osiągnąć dość łatwo, biorąc pod uwagę, że „Clickhouse” ma swój interfejs, ale nie mogę powiedzieć z całą pewnością. Lepiej przetestować. Wszystko zależy od konfiguracji: ilu masz hostów itd. Wstawianie to jedno, ale trzeba również te dane pozyskiwać – Grafana lub coś innego.
A: – Czyli mówimy o równej walce, a nie o dużej przewadze tych szybkich baz danych?
AG: – Myślę, że kiedy zintegrowane, będą dokładniejsze testy.
A: – Gdzie zniknął stary dobry RRD? Co spowodowało przejście na bazy danych SQL? Początkowo wszystkie metryki zbierano na RRD.
AG: – W «Zabbix» RRD może był w bardzo starej wersji. Zawsze były bazy SQL – klasyczne podejście. Klasyczne podejście to MySQL, PostgreSQL (istnieją od bardzo dawna). Mamy wspólny interfejs dla baz danych SQL, a RRD praktycznie nigdy nie używaliśmy.
Trochę reklamy 🙂
Dziękujemy, że jesteś z nami. Podobają Ci się nasze artykuły? Chcesz zobaczyć więcej interesujących materiałów? Wspieraj nas składając zamówienie lub polecając nas znajomym, , unikatowy odpowiednik serwerów entry-level, który został stworzony przez nas dla Ciebie: (dostępne opcje z RAID1 i RAID10, do 24 rdzeni i do 40GB DDR4).
Dell R730xd dwa razy tańszy w centrum danych Equinix Tier IV w Amsterdamie? Tylko u nas w Holandii! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — od 99 dolarów! Czytaj o tym
Źródło: habr.com
