W ciągu ostatnich kilku lat bazy danych szeregów czasowych przestały być czymś dziwacznym (wysoce wyspecjalizowanym, wykorzystywanym czy to w otwartych systemach monitorowania (i powiązanym z konkretnymi rozwiązaniami), czy w projektach Big Data) w „produkt konsumencki”. Na terenie Federacji Rosyjskiej należą się za to szczególne podziękowania firmom Yandex i ClickHouse. Do tego momentu, jeśli trzeba było przechowywać dużą ilość danych szeregów czasowych, trzeba było albo pogodzić się z koniecznością zbudowania monstrualnego stosu Hadoop i jego utrzymania, albo komunikować się za pomocą protokołów indywidualnych dla każdego systemu.
Może się wydawać, że w 2019 roku artykuł, o którym warto skorzystać z TSDB, będzie składał się tylko z jednego zdania: „po prostu użyj ClickHouse”. Ale... są niuanse.
Rzeczywiście ClickHouse aktywnie się rozwija, baza użytkowników rośnie, a wsparcie jest bardzo aktywne, ale czy nie staliśmy się zakładnikami publicznego sukcesu ClickHouse, który przyćmił inne, być może bardziej skuteczne/niezawodne rozwiązania?
Na początku ubiegłego roku rozpoczęliśmy przeróbkę własnego systemu monitoringu, w trakcie której pojawiło się pytanie o wybór odpowiedniej bazy danych do przechowywania danych. Chcę tutaj opowiedzieć o historii tego wyboru.
Stwierdzenie problemu
Przede wszystkim niezbędny wstęp. Po co nam w ogóle własny system monitoringu i jak został on zaprojektowany?
Zaczęliśmy świadczyć usługi wsparcia w 2008 roku, a już w 2010 roku stało się jasne, że trudno jest agregować dane o procesach zachodzących w infrastrukturze klienta z istniejącymi wówczas rozwiązaniami (mówimy o Boże przebacz mi, Cacti, Zabbix i powstający grafit).
Naszymi głównymi wymaganiami było:
- obsługa (wówczas kilkudziesięciu, a w przyszłości setek) klientów w ramach jednego systemu i jednocześnie obecność scentralizowanego systemu zarządzania alertami;
- elastyczność w zarządzaniu systemem alertów (eskalacja alertów pomiędzy funkcjonariuszami dyżurnymi, harmonogram, baza wiedzy);
- możliwość szczegółowego tworzenia wykresów (wówczas Zabbix renderował wykresy w formie obrazów);
- długotrwałe przechowywanie dużej ilości danych (rok lub dłużej) i możliwość szybkiego ich odzyskania.
W tym artykule interesuje nas ostatni punkt.
Jeśli chodzi o przechowywanie, wymagania były następujące:
- system musi działać szybko;
- pożądane jest, aby system miał interfejs SQL;
- system musi być stabilny i mieć aktywną bazę użytkowników oraz wsparcie (kiedyś stanęliśmy przed koniecznością obsługi systemów takich jak MemcacheDB, który nie był już rozwijany, czy rozproszona pamięć masowa MooseFS, której moduł śledzenia błędów był prowadzony w języku chińskim: powtarzamy tę historię, ponieważ nasz projekt nie chciał);
- zgodność z twierdzeniem CAP: Spójność (wymagane) - dane muszą być aktualne, nie chcemy, aby system zarządzania alertami nie otrzymywał nowych danych i nie wypluwał alertów o nienadejściu danych dla wszystkich projektów; Partition Tolerance (wymagane) - nie chcemy systemu Split Brain; Dostępność (nie krytyczna, jeśli jest aktywna replika) - w razie wypadku możemy samodzielnie przełączyć się na system zapasowy, za pomocą kodu.
Co dziwne, w tym czasie MySQL okazał się dla nas idealnym rozwiązaniem. Nasza struktura danych była niezwykle prosta: identyfikator serwera, identyfikator licznika, znacznik czasu i wartość; szybkie próbkowanie gorących danych zapewniała duża pula buforów, a próbkowanie danych historycznych zapewniał dysk SSD.
W ten sposób uzyskaliśmy próbkę świeżych danych z dwóch tygodni, ze szczegółami sięgającymi sekund 200 ms przed całkowitym wyrenderowaniem danych, i żyliśmy w tym systemie przez dość długi czas.
Tymczasem czas mijał, a ilość danych rosła. Do 2016 roku wolumen danych sięgał kilkudziesięciu terabajtów, co w kontekście wynajmowanej pamięci SSD stanowiło znaczny wydatek.
Do tego czasu kolumnowe bazy danych stały się aktywnie rozpowszechnione, o czym zaczęliśmy aktywnie myśleć: w kolumnowych bazach danych dane są przechowywane, jak można zrozumieć, w kolumnach, a jeśli spojrzysz na nasze dane, łatwo jest zobaczyć duży liczba duplikatów, które mogłyby, w Jeśli używasz kolumnowej bazy danych, skompresuj ją za pomocą kompresji.
Jednak kluczowy system firmy w dalszym ciągu działał stabilnie i nie chciałem eksperymentować z przesiadką na coś innego.
W 2017 roku na konferencji Percona Live w San Jose deweloperzy Clickhouse zapowiedzieli się prawdopodobnie po raz pierwszy. Na pierwszy rzut oka system był gotowy do produkcji (cóż, Yandex.Metrica to trudny system produkcyjny), wsparcie było szybkie i proste, a co najważniejsze, obsługa była prosta. Od 2018 roku rozpoczęliśmy proces przejścia. Ale do tego czasu istniało wiele „dorosłych” i sprawdzonych systemów TSDB i postanowiliśmy poświęcić sporo czasu na porównanie alternatyw, aby upewnić się, że nie ma alternatywnych rozwiązań dla Clickhouse, zgodnie z naszymi wymaganiami.
Oprócz już określonych wymagań dotyczących przechowywania, pojawiły się nowe:
- nowy system powinien zapewniać co najmniej taką samą wydajność jak MySQL na tej samej ilości sprzętu;
- przechowywanie nowego systemu powinno zajmować znacznie mniej miejsca;
- DBMS musi być nadal łatwy w zarządzaniu;
- Chciałem minimalnie zmienić aplikację przy zmianie DBMS.
Jakie systemy zaczęliśmy rozważać?
Apache Hive/Apache Impala
Stary, przetestowany w boju stos Hadoop. Zasadniczo jest to interfejs SQL zbudowany w oparciu o przechowywanie danych w natywnych formatach w systemie HDFS.
Profesjonalistów.
- Dzięki stabilnej pracy bardzo łatwo jest skalować dane.
- Istnieją rozwiązania kolumnowe do przechowywania danych (mniej miejsca).
- Bardzo szybka realizacja zadań równoległych w przypadku dostępności zasobów.
Przeciw.
- To Hadoop i jest trudny w użyciu. Jeśli nie jesteśmy gotowi na gotowe rozwiązanie w chmurze (i nie jesteśmy gotowi pod względem kosztów), cały stos będzie musiał zostać zmontowany i obsługiwany rękami administratorów, a tak naprawdę nie chcemy Ten.
- Dane są agregowane .
Ale:
Szybkość osiąga się poprzez skalowanie liczby serwerów obliczeniowych. Mówiąc najprościej, jeśli jesteśmy dużą firmą, zajmujemy się analityką i dla biznesu ważne jest jak najszybsze agregowanie informacji (nawet kosztem użycia dużej ilości zasobów obliczeniowych), może to być nasz wybór. Nie byliśmy jednak gotowi na pomnażanie floty sprzętowej w celu przyspieszenia zadań.
Druid/Pinot
W szczególności o TSDB jest znacznie więcej, ale znowu o stosie Hadoop.
Jest .
W kilku słowach: Druid/Pinot wyglądają lepiej niż Clickhouse w przypadkach, gdy:
- Masz heterogeniczny charakter danych (w naszym przypadku rejestrujemy tylko szeregi czasowe metryk serwera i tak naprawdę jest to jedna tabela. Mogą jednak zaistnieć inne przypadki: szeregi czasowe sprzętu, szeregi czasowe ekonomiczne itp. - każdy z własną strukturę, która wymaga agregacji i przetworzenia).
- Co więcej, tych danych jest mnóstwo.
- Tabele i dane z szeregami czasowymi pojawiają się i znikają (tzn. jakiś zestaw danych przybył, został przeanalizowany i usunięty).
- Nie ma jasnego kryterium podziału danych.
W odwrotnych przypadkach ClickHouse radzi sobie lepiej i tak właśnie jest w naszym przypadku.
Kliknij Dom
- Podobnie jak SQL
- Łatwe w zarządzaniu.
- Ludzie mówią, że to działa.
Zostaje zakwalifikowany do testów.
NapływDB
Zagraniczna alternatywa dla ClickHouse. Z minusów: Wysoka dostępność występuje tylko w wersji komercyjnej, ale trzeba ją porównać.
Zostaje zakwalifikowany do testów.
Cassandra
Z jednej strony wiemy, że służy do przechowywania metrycznych szeregów czasowych przez takie systemy monitorujące jak np. lub OkMeter. Są jednak konkrety.
Cassandra nie jest kolumnową bazą danych w tradycyjnym tego słowa znaczeniu. Wygląda bardziej jak widok wierszowy, ale każda linia może mieć inną liczbę kolumn, co ułatwia organizację widoku kolumnowego. W tym sensie jasne jest, że przy limicie 2 miliardów kolumn możliwe jest przechowywanie niektórych danych w kolumnach (i w tych samych szeregach czasowych). Na przykład w MySQL istnieje limit 4096 kolumn i łatwo natknąć się na błąd z kodem 1117, jeśli spróbujesz zrobić to samo.
Silnik Cassandra nastawiony jest na przechowywanie dużych ilości danych w systemie rozproszonym bez mastera, a wspomniane powyżej twierdzenie Cassandry CAP bardziej dotyczy AP, czyli dostępności danych i odporności na partycjonowanie. Dlatego to narzędzie może być świetne, jeśli potrzebujesz tylko pisać do tej bazy danych i rzadko z niej czytać. I tutaj logiczne jest użycie Cassandry jako „chłodni” magazynu. Czyli jako długoterminowe, niezawodne miejsce do przechowywania dużej ilości danych historycznych, które są rzadko potrzebne, ale można je odzyskać w razie potrzeby. Niemniej jednak, dla kompletności, również to przetestujemy. Ale tak jak mówiłem wcześniej, nie ma potrzeby aktywnego przepisywania kodu dla wybranego rozwiązania bazodanowego, dlatego przetestujemy je nieco w ograniczonym zakresie – bez dostosowywania struktury bazy danych do specyfiki Cassandry.
Prometheus
Otóż z ciekawości postanowiliśmy przetestować wydajność pamięci Prometheus – żeby dowiedzieć się, czy jesteśmy szybsi, czy wolniejsi od obecnych rozwiązań i o ile.
Metodologia i wyniki badań
Przetestowaliśmy zatem 5 baz danych w 6 konfiguracjach: ClickHouse (1 węzeł), ClickHouse (tabela rozproszona dla 3 węzłów), InfluxDB, Mysql 8, Cassandra (3 węzły) i Prometheus. Plan testów wygląda następująco:
- przesyłaj dane historyczne za tydzień (840 milionów wartości dziennie; 208 tysięcy metryk);
- generujemy obciążenie rejestrujące (uwzględniono 6 trybów obciążenia, patrz poniżej);
- Równolegle z zapisem okresowo dokonujemy selekcji, emulując żądania użytkownika pracującego z wykresami. Aby nie komplikować zbytnio sprawy, wybraliśmy dane dla 10 metryk (tyle jest dokładnie na wykresie procesora) na tydzień.
Ładujemy emulując zachowanie naszego agenta monitorującego, który wysyła wartości do każdej metryki raz na 15 sekund. Jednocześnie jesteśmy zainteresowani zróżnicowaniem:
- całkowita liczba metryk, w których zapisywane są dane;
- interwał wysyłania wartości do jednej metryki;
- wielkość partii.
O wielkości partii. Ponieważ nie jest zalecane ładowanie prawie wszystkich naszych eksperymentalnych baz danych pojedynczymi wstawkami, będziemy potrzebować przekaźnika, który zbiera przychodzące metryki, grupuje je w grupy i zapisuje je do bazy danych jako wstawkę wsadową.
Ponadto, aby lepiej zrozumieć, jak następnie interpretować otrzymane dane, wyobraźmy sobie, że nie tylko wysyłamy kilka metryk, ale metryki są zorganizowane w serwery – 125 metryk na serwer. Tutaj serwer jest po prostu jednostką wirtualną - tak dla zrozumienia, że np. 10000 80 metryk odpowiada około XNUMX serwerom.
A oto, biorąc to wszystko pod uwagę, naszych 6 trybów ładowania zapisu do bazy danych:
Są tu dwa punkty. Po pierwsze, dla Cassandry te wielkości partii okazały się za duże, tam zastosowaliśmy wartości 50 lub 100. Po drugie, ponieważ Prometheus działa stricte w trybie pull, tj. sam chodzi i zbiera dane ze źródeł metryk (a nawet pushgateway, wbrew nazwie, zasadniczo nie zmienia sytuacji), odpowiednie obciążenia zostały zaimplementowane przy użyciu kombinacji statycznych konfiguracji.
Wyniki testu są następujące:
Na co warto zwrócić uwagę: fantastycznie szybkie próbki z Prometheusa, strasznie wolne próbki z Cassandry, niedopuszczalnie wolne próbki z InfluxDB; Pod względem szybkości nagrywania ClickHouse zwyciężył wszystkich, a Prometheus w konkursie nie bierze udziału, bo sam robi wstawki, a my niczego nie mierzymy.
W efekcie,: ClickHouse i InfluxDB okazały się najlepsze, ale klaster firmy Influx można zbudować tylko w oparciu o wersję Enterprise, która kosztuje, podczas gdy ClickHouse nie kosztuje nic i jest produkowany w Rosji. Logiczne jest, że w USA wybór prawdopodobnie padł na inInfluxDB, a w naszym kraju na korzyść ClickHouse.
Źródło: www.habr.com