Przyjrzymy się, jak Zabbix współpracuje z bazą danych TimescaleDB jako backendem. Pokażemy Ci jak zacząć od zera i jak przeprowadzić migrację z PostgreSQL. Przeprowadzimy również porównawcze testy wydajności obu konfiguracji.
HighLoad++ Syberia 2019. Hala Tomsk. 24 czerwca, 16:00. Tezy i . Najbliższa konferencja HighLoad++ odbędzie się 6 i 7 kwietnia 2020 w St. Petersburgu. Szczegóły i bilety .
Andrey Gushchin (dalej – AG): – Jestem inżynierem wsparcia technicznego ZABBIX (zwanym dalej „Zabbix”), trenerem. Pracuję w dziale pomocy technicznej od ponad 6 lat i mam bezpośrednie doświadczenie w wydajności. Dzisiaj opowiem o wydajności, jaką może zapewnić TimescaleDB w porównaniu ze zwykłym PostgreSQL 10. Oraz kilka słów wprowadzających o tym, jak to działa ogólnie.
Najważniejsze wyzwania związane z produktywnością: od gromadzenia danych po czyszczenie danych
Zacznijmy od tego, że każdy system monitorowania musi stawić czoła pewnym wyzwaniom związanym z wydajnością. Pierwszym wyzwaniem związanym z produktywnością jest szybkie gromadzenie i przetwarzanie danych.
Dobry system monitorowania powinien szybko i terminowo odbierać wszystkie dane, przetwarzać je według wyrażeń wyzwalających, czyli przetwarzać według pewnych kryteriów (w różnych systemach jest to różne) i zapisywać w bazie danych, aby móc wykorzystać te dane w procesie przyszły.
Drugim wyzwaniem związanym z wydajnością jest przechowywanie historii. Często przechowuj dane w bazie danych i miej szybki i wygodny dostęp do wskaźników gromadzonych przez pewien okres czasu. Najważniejsze, żeby te dane były wygodne do pozyskania, wykorzystania w raportach, wykresach, wyzwalaczach, w niektórych wartościach progowych, do alertów itp.
Trzecim wyzwaniem związanym z wydajnością jest czyszczenie historii, to znaczy dotarcie do punktu, w którym nie trzeba przechowywać żadnych szczegółowych metryk zebranych w ciągu 5 lat (nawet miesięcy lub dwóch miesięcy). Niektóre węzły sieciowe lub niektóre hosty zostały usunięte, metryki nie są już potrzebne, ponieważ są już nieaktualne i nie są już gromadzone. Wszystko to należy wyczyścić, aby baza danych nie powiększyła się zbytnio. Ogólnie rzecz biorąc, czyszczenie historii jest najczęściej poważnym testem dla pamięci masowej - często ma bardzo duży wpływ na wydajność.
Jak rozwiązać problemy z buforowaniem?
Teraz będę mówić konkretnie o Zabbixie. W Zabbix pierwsze i drugie wywołanie są rozwiązywane przy użyciu buforowania.
Gromadzenie i przetwarzanie danych – do przechowywania wszystkich tych danych używamy pamięci RAM. Dane te zostaną teraz omówione bardziej szczegółowo.
Również po stronie bazy danych istnieje buforowanie głównych selekcji - dla wykresów i innych rzeczy.
Buforowanie po stronie samego serwera Zabbix: mamy ConfigurationCache, ValueCache, HistoryCache, TrendsCache. Co to jest?
ConfigurationCache to główna pamięć podręczna, w której przechowujemy metryki, hosty, elementy danych, wyzwalacze; wszystko, czego potrzebujesz do przetwarzania wstępnego, zbierania danych, z jakich hostów zbierać i z jaką częstotliwością. Wszystko to jest przechowywane w ConfigurationCache, aby nie trafiać do bazy danych i nie tworzyć niepotrzebnych zapytań. Po uruchomieniu serwera aktualizujemy tę pamięć podręczną (tworzymy ją) i aktualizujemy ją okresowo (w zależności od ustawień konfiguracyjnych).
Buforowanie w Zabbixie. Zbieranie danych
Tutaj schemat jest dość duży:
Głównymi w schemacie są te kolektory:
Są to same procesy montażowe, różne „pollery”, które odpowiadają za różne typy złożeń. Zbierają dane za pośrednictwem icmp, ipmi i różnych protokołów i przekazują je do wstępnego przetwarzania.
Przetwarzanie wstępne HistoryCache
Ponadto, jeśli mamy obliczone elementy danych (ci, którzy znają Zabbix, wiedzą), czyli obliczone elementy danych agregacyjnych, pobieramy je bezpośrednio z ValueCache. Później powiem ci, jak się go napełnia. Wszystkie te moduły zbierające używają ConfigurationCache do odbierania zadań, a następnie przekazywania ich do wstępnego przetwarzania.
Przetwarzanie wstępne wykorzystuje również pamięć ConfigurationCache do uzyskania etapów przetwarzania wstępnego i przetwarza te dane na różne sposoby. Począwszy od wersji 4.2 przenieśliśmy go do serwera proxy. Jest to bardzo wygodne, ponieważ sama obróbka wstępna jest dość trudną operacją. A jeśli masz bardzo dużego Zabbixa, z dużą liczbą elementów danych i dużą częstotliwością gromadzenia danych, to znacznie upraszcza to pracę.
W związku z tym, po przetworzeniu tych danych w jakiś sposób za pomocą wstępnego przetwarzania, zapisujemy je w HistoryCache w celu dalszego przetwarzania. Na tym kończy się zbieranie danych. Przechodzimy do głównego procesu.
Praca synchronizatora historii
Głównym procesem w Zabbixie (ponieważ jest to architektura monolityczna) jest synchronizator historii. Jest to główny proces, który dotyczy konkretnie przetwarzania atomowego każdego elementu danych, czyli każdej wartości:
- wartość pochodzi (pobiera ją z HistoryCache);
- sprawdza w Configuration syncer: czy istnieją jakieś wyzwalacze do obliczeń – oblicza je;
jeśli istnieje - tworzy zdarzenia, tworzy eskalację w celu wygenerowania alertu, jeśli jest to konieczne zgodnie z konfiguracją; - rejestruje wyzwalacze do późniejszego przetwarzania, agregacji; jeśli agregujesz przez ostatnią godzinę itd., wartość ta jest pamiętana przez ValueCache, aby nie trafiać do tabeli historii; Tym samym ValueCache zostaje wypełniony niezbędnymi danymi niezbędnymi do wyliczenia wyzwalaczy, elementów wyliczanych itp.;
- następnie Synchronizator historii zapisuje wszystkie dane do bazy danych;
- baza danych zapisuje je na dysk – na tym kończy się proces przetwarzania.
Baza danych. Buforowanie
Po stronie bazy danych, jeśli chcesz wyświetlić wykresy lub raporty o zdarzeniach, dostępne są różne pamięci podręczne. Ale w tym raporcie nie będę o nich mówić.
W przypadku MySQL istnieje Innodb_buffer_pool i kilka różnych pamięci podręcznych, które również można skonfigurować.
Ale to są najważniejsze:
- wspólne_bufory;
- efektywny_rozmiar_cache;
- wspólna_pula.
W przypadku wszystkich baz danych powiedziałem, że istnieją pewne pamięci podręczne, które pozwalają przechowywać w pamięci RAM dane często potrzebne do zapytań. Mają do tego własne technologie.
Informacje o wydajności bazy danych
W związku z tym istnieje środowisko konkurencyjne, to znaczy serwer Zabbix zbiera dane i je rejestruje. Po ponownym uruchomieniu odczytuje również historię, aby wypełnić ValueCache i tak dalej. Tutaj możesz mieć skrypty i raporty korzystające z API Zabbix, które jest zbudowane na interfejsie internetowym. Zabbix API wchodzi do bazy danych i odbiera niezbędne dane w celu uzyskania wykresów, raportów, czy też jakiejś listy zdarzeń, ostatnich problemów.
Bardzo popularnym rozwiązaniem do wizualizacji jest także Grafana, z której korzystają nasi użytkownicy. Możliwość bezpośredniego logowania zarówno poprzez API Zabbix, jak i poprzez bazę danych. Stwarza to również pewną konkurencję w zakresie pozyskiwania danych: konieczne jest dokładniejsze i lepsze dostrojenie bazy danych, aby zapewnić szybkie dostarczanie wyników i przeprowadzanie testów.
Czyszczenie historii. Zabbix ma gospodynię
Trzecie wywołanie używane w Zabbix to czyszczenie historii za pomocą Housekeeper. Housekeeper podąża za wszystkimi ustawieniami, czyli nasze elementy danych wskazują, jak długo przechowywać (w dniach), jak długo przechowywać trendy i dynamikę zmian.
Nie mówiłem o TrendCache, który wyliczamy na bieżąco: dane przychodzą, agregujemy je za godzinę (przeważnie są to liczby z ostatniej godziny), ilość jest średnia/minimalna i zapisujemy ją raz na godzinę w tabela dynamiki zmian („Trendy”). „Gospodyni” uruchamia i usuwa dane z bazy danych za pomocą zwykłych selekcji, co nie zawsze jest skuteczne.
Jak zrozumieć, że jest to nieskuteczne? Na wykresach wydajności procesów wewnętrznych można zobaczyć następujący obraz:
Twój synchronizator historii jest stale zajęty (czerwony wykres). I „czerwony” wykres, który znajduje się na górze. Jest to „Gosposia”, która uruchamia się i czeka, aż baza danych usunie wszystkie określone wiersze.
Weźmy identyfikator przedmiotu: musisz usunąć ostatnie 5 tysięcy; oczywiście według indeksów. Jednak zwykle zbiór danych jest dość duży - baza danych i tak odczytuje go z dysku i umieszcza w pamięci podręcznej, a jest to bardzo kosztowna operacja dla bazy danych. W zależności od rozmiaru może to prowadzić do pewnych problemów z wydajnością.
Możesz wyłączyć Housekeepera w prosty sposób - mamy znajomy interfejs sieciowy. Ustawienia w Administracji ogólne (ustawienia dla „Gospodyni”) wyłączamy wewnętrzne porządkowanie dla wewnętrznej historii i trendów. W związku z tym Gospodyni nie kontroluje już tego:
Co możesz zrobić dalej? Wyłączyłeś, wykresy się wyrównały... Jakie dalsze problemy mogą się w tym przypadku pojawić? Co może pomóc?
Partycjonowanie (sekcje)
Zwykle jest to konfigurowane w inny sposób w każdej relacyjnej bazie danych, którą wymieniłem. MySQL ma własną technologię. Ale ogólnie są bardzo podobne, jeśli chodzi o PostgreSQL 10 i MySQL. Oczywiście istnieje wiele wewnętrznych różnic w sposobie, w jaki to wszystko jest zaimplementowane i jak to wszystko wpływa na wydajność. Ale ogólnie rzecz biorąc, utworzenie nowej partycji często prowadzi również do pewnych problemów.
W zależności od Twojej konfiguracji (ile danych utworzysz w ciągu jednego dnia) zazwyczaj ustalają minimum - jest to 1 dzień / partia, a dla „trendów” dynamika zmian - 1 miesiąc / nowa partia. Może się to zmienić, jeśli masz bardzo dużą konfigurację.
Powiedzmy od razu o wielkości setupu: do 5 tysięcy nowych wartości na sekundę (tzw. nvps) – będzie to traktowane jako mały „setup”. Średnia – od 5 do 25 tysięcy wartości na sekundę. To wszystko co powyżej to już duże i bardzo duże instalacje wymagające bardzo starannej konfiguracji bazy danych.
W przypadku bardzo dużych instalacji 1 dzień może nie być optymalny. Osobiście widziałem partycje w MySQL o wielkości 40 gigabajtów dziennie (a może być więcej). Jest to bardzo duża ilość danych, co może powodować pewne problemy. Należy to zmniejszyć.
Dlaczego potrzebujesz partycjonowania?
Myślę, że wszyscy wiedzą, że partycjonowanie zapewnia partycjonowanie tabeli. Często są to oddzielne pliki na żądaniach dysku i zakresu. Wybiera jedną partycję bardziej optymalnie, jeśli jest ona częścią normalnego partycjonowania.
W szczególności w Zabbixie jest on używany według zakresu, czyli według zakresu, czyli używamy znacznika czasu (zwykła liczba, czas od początku epoki). Określasz początek/koniec dnia i to jest partycja. W związku z tym, jeśli poprosisz o dane sprzed dwóch dni, wszystko zostanie pobrane z bazy danych szybciej, ponieważ wystarczy załadować tylko jeden plik do pamięci podręcznej i zwrócić go (a nie dużą tabelę).
Wiele baz danych przyspiesza także wstawianie (wstawianie do jednej tabeli podrzędnej). Na razie mówię abstrakcyjnie, ale jest to również możliwe. Podział na części często pomaga.
Elasticsearch dla NoSQL
Niedawno w wersji 3.4 wdrożyliśmy rozwiązanie NoSQL. Dodano możliwość pisania w Elasticsearch. Możesz pisać określone typy: wybierasz - albo napisz liczby, albo jakieś znaki; mamy tekst tekstowy, możesz zapisywać logi w Elasticsearch... W związku z tym interfejs sieciowy będzie również miał dostęp do Elasticsearch. W niektórych przypadkach działa to świetnie, ale w tej chwili można z niego skorzystać.
Skala czasuDB. Hipertabele
W wersji 4.4.2 zwróciliśmy uwagę na jedną rzecz, taką jak TimescaleDB. Co to jest? Jest to rozszerzenie dla PostgreSQL, czyli posiada natywny interfejs PostgreSQL. Ponadto to rozszerzenie umożliwia znacznie wydajniejszą pracę z danymi szeregów czasowych i automatyczne partycjonowanie. Jak to wygląda:
To jest hipertable – istnieje taka koncepcja w Timescale. Jest to hipertabela, którą tworzysz i zawiera fragmenty. Kawałki to partycje, to są tabele podrzędne, jeśli się nie mylę. To naprawdę skuteczne.
TimescaleDB i PostgreSQL
Jak zapewniają producenci TimescaleDB, stosują oni bardziej poprawny algorytm przetwarzania zapytań, w szczególności wstawek, co pozwala im uzyskać w przybliżeniu stałą wydajność wraz ze wzrostem rozmiaru wstawki zbioru danych. Oznacza to, że po 200 milionach wierszy Postgresa zwykły zaczyna bardzo mocno opadać i traci wydajność dosłownie do zera, natomiast Timescale pozwala na możliwie efektywne wstawianie wstawek przy dowolnej ilości danych.
Jak zainstalować TimescaleDB? To proste!
Jest w dokumentacji, jest opisane - możesz zainstalować go z pakietów dla dowolnego... To zależy od oficjalnych pakietów Postgres. Można skompilować ręcznie. Tak się złożyło, że musiałem skompilować do bazy danych.
W Zabbix po prostu aktywujemy rozszerzenie. Myślę, że ci, którzy używali Extention w Postgres... Po prostu aktywujesz Extention, tworzysz je dla bazy danych Zabbix, której używasz.
I ostatni krok...
Skala czasuDB. Migracja tabel historii
Musisz utworzyć hipertabelę. Jest do tego specjalna funkcja – Utwórz hipertabelę. W nim pierwszym parametrem jest tabela potrzebna w tej bazie danych (dla której musisz utworzyć hipertabelę).
Pole, według którego należy utworzyć, oraz chunk_time_interval (jest to odstęp między porcjami (partycjami, które należy wykorzystać). 86 400 to jeden dzień.
Parametr Migrate_data: Jeśli wstawisz wartość true, spowoduje to migrację wszystkich bieżących danych do wcześniej utworzonych fragmentów.
Sam korzystałem z migracji_data - zajmuje to sporo czasu, w zależności od wielkości Twojej bazy danych. Miałem ponad terabajt – tworzenie zajęło ponad godzinę. W niektórych przypadkach podczas testów usuwałem dane historyczne dla tekstu (history_text) i stringu (history_str), aby ich nie przenosić - nie były one dla mnie specjalnie interesujące.
I dokonujemy ostatniej aktualizacji w naszym db_extention: instalujemy timescaledb, aby baza danych, a w szczególności nasz Zabbix, rozumiała, że istnieje db_extention. 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
Korzystałem z dwóch serwerów. Pierwszy serwer to dość mała maszyna wirtualna, 20 procesorów, 16 gigabajtów pamięci RAM. Skonfigurowałem na nim Postgres 10.8:
System operacyjny to Debian, system plików to xfs. Dokonałem minimalnych ustawień, aby używać tej konkretnej bazy danych, pomijając to, czego będzie używał sam Zabbix. Na tej samej maszynie znajdował się serwer Zabbix, PostgreSQL i agenty ładowania.
Użyłem 50 aktywnych agentów, którzy używają LoadableModule do szybkiego generowania różnych wyników. To oni wygenerowali ciągi znaków, liczby i tak dalej. Wypełniłem bazę danych dużą ilością danych. Początkowo konfiguracja zawierała 5 tysięcy elementów danych na hosta i mniej więcej każdy element danych zawierał wyzwalacz – aby była to prawdziwa konfiguracja. Czasami do użycia potrzebny jest nawet więcej niż jeden wyzwalacz.
Regulowałem interwał aktualizacji i samo obciążenie, nie tylko wykorzystując 50 agentów (dodając więcej), ale także wykorzystując dynamiczne elementy danych i skracając interwał aktualizacji do 4 sekund.
Test wydajności. PostgreSQL: 36 tys. NVP
Pierwsze uruchomienie, pierwsza konfiguracja, jaką miałem, odbyła się na czystym PostreSQL 10 na tym sprzęcie (35 tysięcy wartości na sekundę). Generalnie jak widać na zrzucie ekranu, wkładanie danych zajmuje ułamki sekund - wszystko sprawnie i szybko, dyski SSD (200 gigabajtów). Jedyną rzeczą jest to, że 20 GB zapełnia się dość szybko.
Takich wykresów będzie w przyszłości całkiem sporo. To jest standardowy pulpit nawigacyjny wydajności serwera Zabbix.
Pierwszy wykres to liczba wartości na sekundę (niebieski, lewy górny róg), w tym przypadku 35 tysięcy wartości. To (na górze pośrodku) to ładowanie procesów kompilacji, a to (na górze po prawej) to ładowanie procesów wewnętrznych: synchronizatorów historii i gospodyni, która tutaj (na dole pośrodku) działa już od dłuższego czasu.
Ten wykres (na dole po środku) pokazuje wykorzystanie ValueCache – ile trafień ValueCache dla wyzwalaczy (kilka tysięcy wartości na sekundę). Kolejnym ważnym wykresem jest czwarty (lewy dolny róg), który pokazuje wykorzystanie HistoryCache, o którym mówiłem, czyli bufora przed wstawieniem do bazy danych.
Test wydajności. PostgreSQL: 50 tys. NVP
Następnie zwiększyłem obciążenie do 50 tysięcy wartości na sekundę na tym samym sprzęcie. Po załadowaniu przez Housekeepera, podczas obliczeń, w ciągu 10-2 sekund zarejestrowano 3 tysięcy wartości. Co tak naprawdę widać na poniższym zrzucie ekranu:
„Gospodyni” zaczyna już przeszkadzać w pracy, ale ogólnie obciążenie traperów-pogłębiaczy historii nadal utrzymuje się na poziomie 60% (trzeci wykres, u góry po prawej). HistoryCache już zaczyna się aktywnie wypełniać, gdy Housekeeper jest uruchomiony (na dole po lewej). Miał około pół gigabajta i był zapełniony w 20%.
Test wydajności. PostgreSQL: 80 tys. NVP
Następnie zwiększyłem go do 80 tysięcy wartości na sekundę:
Było to około 400 tysięcy elementów danych, 280 tysięcy wyzwalaczy. Wkładka jak widać pod względem obciążenia historycznymi obciążnikami (było ich 30) była już dość wysoka. Następnie zwiększyłem różne parametry: obciążniki historii, pamięć podręczną... Na tym sprzęcie obciążenie obciążników historii zaczęło wzrastać do maksimum, prawie „na półce” - odpowiednio HistoryCache wszedł w bardzo duże obciążenie:
Przez cały ten czas monitorowałem wszystkie parametry systemu (sposób wykorzystania procesora, RAM) i stwierdziłem, że wykorzystanie dysku jest maksymalne - maksymalną pojemność tego dysku osiągnąłem na tym sprzęcie, na tej maszynie wirtualnej. „Postgres” zaczął z taką intensywnością dość aktywnie zrzucać dane, a dysk nie miał już czasu na zapis, odczyt...
Wziąłem inny serwer, który miał już 48 procesorów i 128 gigabajtów RAM:
„Dostrojiłem” go także - zainstalowałem synchronizator historii (60 sztuk) i osiągnąłem akceptowalną wydajność. Tak naprawdę nie jesteśmy „na półce”, ale prawdopodobnie jest to granica produktywności, gdzie trzeba już coś z tym zrobić.
Test wydajności. TimescaleDB: 80 tysięcy NVP
Moim głównym zadaniem było użycie TimescaleDB. Każdy wykres pokazuje spadek:
Te awarie to właśnie migracja danych. Po tym, jak widać, na serwerze Zabbix profil ładowania obciążonych historii bardzo się zmienił. Dzięki niemu możesz wprowadzać dane niemal 3 razy szybciej i zużywać mniej HistoryCache – dzięki temu dane otrzymasz na czas. Ponownie 80 tysięcy wartości na sekundę to dość wysoki wskaźnik (oczywiście nie dla Yandex). Ogólnie rzecz biorąc, 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 dostałem takie wykresy:
W zasadzie jest to działająca konfiguracja, może działać dość długo. Ale ponieważ miałem tylko dysk 1,5 terabajta, zużyłem go w ciągu kilku dni. Najważniejsze, że w tym samym czasie na TimescaleDB powstały nowe partycje, a to zostało całkowicie niezauważone pod względem wydajności, czego nie można powiedzieć o MySQL.
Zwykle partycje są tworzone w nocy, ponieważ zazwyczaj blokuje to wstawianie i pracę z tabelami oraz może prowadzić do degradacji usługi. W tym przypadku tak nie jest! Głównym zadaniem było przetestowanie możliwości TimescaleDB. Rezultatem była następująca liczba: 120 tysięcy wartości na sekundę.
Istnieją również przykłady w społeczności:
Osoba ta włączyła także TimescaleDB i obciążenie procesora przy użyciu io.weight spadło; a wykorzystanie wewnętrznych elementów procesu również spadło ze względu na włączenie TimescaleDB. Co więcej, są to zwykłe dyski naleśnikowe, czyli zwykła maszyna wirtualna na zwykłych dyskach (nie SSD)!
W przypadku niektórych małych konfiguracji, które są ograniczone wydajnością dysku, TimescaleDB jest, moim zdaniem, bardzo dobrym rozwiązaniem. Umożliwi to kontynuację pracy przed migracją bazy danych na szybszy sprzęt.
Zapraszam wszystkich na nasze wydarzenia: Konferencja w Moskwie, Szczyt w Rydze. Skorzystaj z naszych kanałów - Telegram, forum, IRC. Jeśli masz jakieś pytania, przyjdź do naszego biurka, porozmawiamy o wszystkim.
Pytania publiczności
Pytanie od publiczności (dalej - A): - Jeśli TimescaleDB jest tak łatwy w konfiguracji i daje taki wzrost wydajności, to może powinno to zostać wykorzystane jako najlepsza praktyka przy konfigurowaniu Zabbix z Postgres? I czy są jakieś pułapki i wady tego rozwiązania, czy w końcu gdybym zdecydował się zrobić Zabbix dla siebie, mogę spokojnie pobrać Postgres, zainstalować tam od razu Timescale, używać go i nie myśleć o żadnych problemach?
AG: – Tak, powiedziałbym, że to dobra rekomendacja: natychmiast użyj Postgres z rozszerzeniem TimescaleDB. Jak już powiedziałem, wiele dobrych recenzji, mimo że ta „funkcja” jest eksperymentalna. Ale tak naprawdę testy pokazują, że jest to świetne rozwiązanie (z TimescaleDB) i myślę, że będzie ewoluować! Monitorujemy rozwój tego rozszerzenia i w razie potrzeby będziemy wprowadzać zmiany.
Nawet podczas projektowania polegaliśmy na jednej z ich dobrze znanych „funkcji”: możliwa była nieco inna praca z fragmentami. Ale potem wycięli to w następnej wersji i musieliśmy przestać polegać na tym kodzie. Poleciłbym użycie tego rozwiązania w wielu konfiguracjach. Jeśli używasz MySQL... W przypadku przeciętnych konfiguracji każde rozwiązanie będzie dobre.
A: – Na ostatnich wykresach od społeczności pojawił się wykres z „Gospodynią”:
Kontynuował pracę. Co Housekeeper robi z TimescaleDB?
AG: – Teraz nie mogę tego powiedzieć na pewno – sprawdzę kod i powiem więcej szczegółów. Używa zapytań TimescaleDB nie do usuwania fragmentów, ale do ich agregowania. Nie jestem jeszcze gotowy, aby odpowiedzieć na to pytanie techniczne. Więcej dowiemy się dziś lub jutro na stoisku.
A: – Mam podobne pytanie – dotyczące wykonania operacji usuwania w Skali Czasu.
A (odpowiedź publiczności): – Kiedy usuwasz dane z tabeli, jeśli robisz to poprzez usuwanie, to musisz przejrzeć tabelę - usuń, wyczyść, zaznacz wszystko do przyszłego odkurzenia. W skali czasu, ponieważ masz kawałki, możesz je upuścić. Z grubsza mówiąc, po prostu mówisz plikowi zawierającemu duże zbiory danych: „Usuń!”
Timescale po prostu rozumie, że taki fragment już nie istnieje. A ponieważ jest zintegrowany z narzędziem do planowania zapytań, wykorzystuje haki do przechwytywania warunków w operacjach wyboru lub innych operacjach i natychmiast rozumie, że ten fragment już nie istnieje – „Już tam nie pójdę!” (dane nie dostępne). To wszystko! Oznacza to, że skanowanie tabeli zostaje zastąpione usunięciem pliku binarnego, więc jest szybkie.
A: – Dotykaliśmy już tematu non-SQL. O ile rozumiem, Zabbix tak naprawdę nie musi modyfikować danych, a wszystko to jest czymś w rodzaju dziennika. Czy można korzystać ze specjalistycznych baz danych, które nie mogą zmieniać swoich danych, a jednocześnie znacznie szybciej je zapisywać, gromadzić i rozpowszechniać – na przykład Clickhouse, coś w stylu Kafki?.. Kafka to też logi! Czy da się je jakoś zintegrować?
AG: - Istnieje możliwość rozładunku. Od wersji 3.4 mamy pewną „funkcję”: możesz zapisywać w plikach wszystkie pliki historyczne, wydarzenia i wszystko inne; a następnie wyślij go do dowolnej innej bazy danych za pomocą jakiegoś modułu obsługi. W rzeczywistości wiele osób przerabia i zapisuje bezpośrednio do bazy danych. Osoby zajmujące się historią zapisują to wszystko na bieżąco w plikach, obracają je itd., a następnie można je przenieść do Clickhouse. Nie mogę powiedzieć nic o planach, ale być może dalsze wsparcie dla rozwiązań NoSQL (takich jak Clickhouse) będzie kontynuowane.
A: – Ogólnie okazuje się, że można całkowicie pozbyć się postgresu?
AG: – Oczywiście najtrudniejszą częścią Zabbix są tabele historyczne, które stwarzają najwięcej problemów i wydarzeń. W takim przypadku, jeśli nie przechowujesz zdarzeń przez długi czas, a historię z trendami przechowujesz w innym szybkim magazynie, to ogólnie myślę, że nie będzie problemów.
A: – Czy możesz oszacować, o ile szybciej wszystko będzie działać, jeśli na przykład przejdziesz na Clickhouse?
AG: – Nie testowałem tego. Myślę, że przynajmniej te same liczby można osiągnąć w prosty sposób, biorąc pod uwagę, że Clickhouse ma swój własny interfejs, ale nie mogę tego powiedzieć na pewno. Lepiej przetestować. Wszystko zależy od konfiguracji: ile masz hostów i tak dalej. Wstawienie to jedno, ale trzeba też te dane odzyskać – Grafana czy coś innego.
A: – Czyli mówimy o równej walce, a nie o ogromnej przewadze, jaką dają te szybkie bazy danych?
AG: – Myślę, że jak się zintegrujemy, to będą dokładniejsze testy.
A: – Gdzie podział się stary, dobry RRD? Co skłoniło Cię do przejścia na bazy danych SQL? Początkowo wszystkie wskaźniki zbierano w RRD.
AG: – Zabbix miał RRD, być może w bardzo starożytnej wersji. Zawsze istniały bazy danych SQL – podejście klasyczne. Klasyczne podejście to MySQL, PostgreSQL (istnieją od bardzo dawna). Prawie nigdy nie korzystaliśmy ze wspólnego interfejsu dla baz danych SQL i RRD.
Kilka reklam 🙂
Dziękujemy za pobyt z nami. Podobają Ci się nasze artykuły? Chcesz zobaczyć więcej ciekawych treści? Wesprzyj nas składając zamówienie lub polecając znajomym, , unikalny odpowiednik serwerów klasy podstawowej, który został przez nas wymyślony dla Ciebie: (dostępne z RAID1 i RAID10, do 24 rdzeni i do 40 GB DDR4).
Dell R730xd 2 razy taniej w centrum danych Equinix Tier IV w Amsterdamie? Tylko tutaj w Holandii! Dell R420 — 2x E5-2430 2.2 GHz 6C 128 GB DDR3 2x960 GB SSD 1 Gb/s 100 TB — od 99 USD! Czytać o
Źródło: www.habr.com