W ciągu ostatnich kilku lat bazy danych czasowych (Time-series databases) przeszły z rzadkiego narzędzia (specjalnie używanego w systemach monitorowania lub w projektach Big Data) do „towaru powszechnego użytku”. Na terenie Rosji w szczególności należy podziękować za to Yandexowi i ClickHouse'owi. Do tego momentu, jeśli potrzebowałeś przechować dużą ilość danych czasowych, musiałeś albo pogodzić się z koniecznością wdrożenia monstrualnego stosu Hadoop i jego utrzymaniem, albo skomunikować się z protokołami specyficznymi dla każdej systemu.
Może się wydawać, że w 2019 roku artykuł o tym, którą TSDB warto użyć, będzie składał się z jednego zdania: „po prostu użyj ClickHouse”. Ale… są niuanse.
Rzeczywiście, ClickHouse rozwija się dynamicznie, baza użytkowników rośnie, a wsparcie jest bardzo aktywne, ale czy nie staliśmy się zakładnikami publicznego sukcesu ClickHouse'a, który przyćmił inne, być może bardziej efektywne/wiarygodne rozwiązania?
Na początku ubiegłego roku zajęliśmy się przekształceniem naszego własnego systemu monitorowania, w trakcie którego pojawił się temat wyboru odpowiedniej bazy do przechowywania danych. O historii tego wyboru chcę tutaj opowiedzieć.
Sformułowanie zadania
Przede wszystkim – niezbędne wprowadzenie. Czemu w ogóle potrzebujemy własnego systemu monitorowania i jak on został zbudowany?
Rozpoczęliśmy świadczenie usług wsparcia w 2008 roku, a do 2010 roku stało się jasne, że agregowanie danych o procesach zachodzących w infrastrukturze klientów przy użyciu dostępnych wtedy rozwiązań stało się trudne (mówimy o, przepraszam, Cacti, Zabbixie i rozwijającym się Graphite).
Nasze główne wymagania były następujące:
- wsparcie (wtedy – dziesiątek, a w przyszłości – setek) klientów w ramach jednego systemu oraz posiadanie scentralizowanego systemu zarządzania powiadomieniami;
- elastyczność w zarządzaniu systemem powiadomień (escalacja powiadomień między dyżurami, uwzględnianie harmonogramu, baza wiedzy);
- możliwość głębokiego stawiania szczegółów na wykresach (Zabbix w tamtym czasie rysował wykresy jako obrazy);
- długoterminowe przechowywanie dużej ilości danych (rok lub więcej) oraz możliwość ich szybkiego wydobycia.
W tym artykule interesuje nas ostatni punkt.
Mówiąc o przechowywaniu, wymagania były następujące:
- system musi działać szybko;
- pożądane, aby system miał interfejs SQL;
- system musi być stabilny i mieć aktywną bazę użytkowników oraz wsparcie (kiedyś mieliśmy do czynienia z koniecznością utrzymywania takich systemów jak MemcacheDB, które przestały być rozwijane, czy rozproszonego magazynu MooseFS, którego śledzenie błędów prowadzone było w języku chińskim: nie chcieliśmy powtarzać tej historii w naszym projekcie);
- zgodność z teorią CAP: Spójność (konieczna) — dane muszą być aktualne, nie chcemy, aby system zarządzania powiadomieniami nie otrzymał nowych danych i wygenerował alerty o braku danych we wszystkich projektach; Tolerancja partycji (konieczna) — nie chcemy mieć systemu typu Split Brain; Dostępność (niekrytyczna, w przypadku istnienia aktywnej repliki) — możemy przestawić się na system zapasowy, w przypadku awarii, kodem.
Jak to dziwnie brzmi, w tym momencie idealnym rozwiązaniem dla nas okazał się MySQL. Nasza struktura danych była niezwykle prosta: id serwera, id licznika, znacznik czasu i wartość; szybkie pobieranie gorących danych było zapewnione przez dużą pojemność bufora, a pobieranie danych historycznych — przez SSD.
W ten sposób osiągnęliśmy pobieranie świeżych danych dwutygodniowych, z dokładnością do sekundy w czasie 200 ms do momentu pełnego wyświetlenia danych, i żyliśmy w tym systemie przez dość długi czas.
Tymczasem czas mijał, a ilość danych rosła. Do 2016 roku objętość danych osiągnęła dziesiątki terabajtów, co w warunkach wynajmowanych magazynów SSD stanowiło znaczny wydatek.
W tym momencie aktywne rozpowszechnienie uzyskały bazy danych kolumnowych, o których zaczęliśmy intensywnie myśleć: w bazach danych kolumnowych dane są przechowywane, jak można to zrozumieć, w kolumnach, a jeśli spojrzeć na nasze dane, łatwo dostrzec dużą ilość duplikatów, które mogłyby być w przypadku zastosowania bazy kolumnowej skompresowane.
Jednak kluczowy system firmy nadal działał stabilnie, i nie chcieliśmy eksperymentować z przejściem na coś innego.
W 2017 roku, na konferencji Percona Live w San Jose, po raz pierwszy zaprezentowali się deweloperzy Clickhouse. Na pierwszy rzut oka system wydawał się gotowy do produkcji (no bo Yandex.Metrica to jeden z poważniejszych projektów produkcyjnych), wsparcie było szybkie i proste, a co najważniejsze, obsługa była bezproblemowa. Od 2018 roku rozpoczęliśmy proces migracji. Jednak w tym czasie na rynku pojawiło się wiele "dojrzałych" i sprawdzonych systemów TSDB, postanowiliśmy więc poświęcić znaczną ilość czasu na porównanie alternatyw, aby upewnić się, że nie ma żadnych rozwiązań alternatywnych do Clickhouse, które spełniałyby nasze wymagania.
Oprócz już wymienionych wymagań dotyczących magazynu pojawiły się nowe:
- nowy system musi zapewniać co najmniej taką samą wydajność jak MySQL, na tym samym sprzęcie;
- magazyn nowego systemu powinien zajmować znacznie mniej miejsca;
- DBMS nadal powinien być łatwy w zarządzaniu;
- chcieliśmy minimalnie zmieniać aplikację przy zmianie DBMS.
Jakie systemy zaczęliśmy rozważać
Apache Hive/Apache Impala
Stary, sprawdzony Hadoop stack. W zasadzie jest to interfejs SQL zbudowany na bazie danych w specjalnych formatach na HDFS.
Zalety.
- Przy stabilnej eksploatacji bardzo łatwo skalować dane.
- Istnieją rozwiązania kolumnowe do przechowywania danych (mniej miejsca).
- Bardzo szybkie wykonywanie zrównoleglonych zadań przy odpowiednich zasobach.
Wady.
- To Hadoop, a jego obsługa jest skomplikowana. Jeśli nie jesteśmy gotowi na gotowe rozwiązanie w chmurze (a nie jesteśmy ze względu na koszty), cały stack będzie musiał być składany i utrzymywany przez administratorów, a tego bardzo nie chcemy.
- Dane agregowane są .
Jednakże:
Szybkość osiąga się przez zwiększenie liczby serwerów obliczeniowych. Mówiąc prościej, jeśli jesteśmy dużą firmą zajmującą się analizą i dla nas krytycznie 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. Jednak nie byliśmy gotowi do znaczącego zwiększenia floty sprzętowej w celu przyspieszenia realizacji zadań.
Druid/Pinot
Już zdecydowanie bardziej konkretny w zakresie TSDB, ale znowu — Hadoop stack.
Tak .
Jeśli w kilku słowach: Druid/Pinot wyglądają lepiej niż Clickhouse w przypadkach, gdy:
- Masz heterogeniczny charakter danych (w naszym przypadku zapisujemy tylko szereg czasowy metryk serwerowych i w istocie jest to jedna tabela. Mogą istnieć także inne przypadki: szeregi czasowe urządzeń, szeregi czasowe ekonomiczne itp. — każdy z własną strukturą, które należy agregować i przetwarzać).
- Jednak tych danych jest bardzo wiele.
- Tabele i dane z szeregami czasowymi pojawiają się i znikają (to znaczy, że jakiś zestaw danych przyszedł, został przeanalizowany i usunięty).
- Nie ma wyraźnego kryterium, według którego dane mogą być partycjonowane.
W przeciwnych przypadkach lepiej sprawdza się ClickHouse, a to jest nasz przypadek.
ClickHouse
- SQL-owy.
- Prosty w zarządzaniu.
- Ludzie mówią, że działa.
Wchodzi na krótką listę testów.
InfluxDB
Zagraniczna alternatywa dla ClickHouse’a. Z minusów: Wysoka dostępność występuje tylko w wersji komercyjnej, ale warto porównać.
Wchodzi na krótką listę testów.
Cassandra
Z jednej strony wiemy, że używa się go do przechowywania metrycznych szeregów czasowych w takich systemach monitorujących jak, na przykład, lub OkMeter. Jest jednak pewna specyfika.
Cassandra nie jest kolumnową bazą danych w tradycyjnym rozumieniu. Wygląda bardziej jak liniowa, ale w każdym wierszu może być różna liczba kolumn, co pozwala łatwo zorganizować przedstawienie kolumnowe. W tym sensie jasne jest, że przy ograniczeniu do 2 miliardów kolumn można przechowywać pewne dane właśnie w kolumnach (np. te same szeregi czasowe). Na przykład, w MySQL istnieje ograniczenie do 4096 kolumn i łatwo natknąć się na błąd o kodzie 1117, jeśli spróbujesz zrobić to samo.
Silnik Cassandra jest zaprojektowany do przechowywania dużych ilości danych w rozproszonej systemie bez mastera, a według wspomnianej teorii CAP, Cassandra bardziej koncentruje się na AP, czyli dostępności danych i odporności na podziały partycji. Dlatego narzędzie to może być idealne, jeśli potrzebujesz tylko zapisywać w tej bazie i rzadko z niej odczytywać. W związku z tym sensowne jest użycie Cassandry jako "zimnego" magazynu. To znaczy jako długoterminowego, niezawodnego miejsca do przechowywania dużych zbiorów danych historycznych, które są rzadko potrzebne, ale można je odzyskać w razie potrzeby. Niemniej jednak, dla pełności obrazu, przetestujemy ją również. Jednak, jak wcześniej mówiłem, nie chcę aktywnie przepisywać kodu pod wybrane rozwiązanie bazodanowe, więc przetestujemy ją w ograniczonym zakresie — bez dostosowywania struktury bazy do specyfiki Cassandry.
Prometheus
Cóż, z czystej ciekawości postanowiliśmy przetestować wydajność magazynu Prometheus — po prostu po to, aby zrozumieć, czy jesteśmy szybszy niż obecne rozwiązania, czy wolniejszy i w jakim stopniu.
Metodyka i wyniki testowania
Przetestowaliśmy 5 baz danych w następujących 6 konfiguracjach: ClickHouse (1 węzeł), ClickHouse (dystrybuowana tabela na 3 węzły), InfluxDB, Mysql 8, Cassandra (3 węzły) i Prometheus. Plan testów wygląda tak:
- załadowanie danych historycznych za tydzień (840 milionów wartości dziennie; 208 tysięcy metryk);
- generowanie obciążenia zapisu (rozważaliśmy 6 trybów obciążenia, patrz poniżej);
- równocześnie z zapisem okresowo wykonujemy odczyty, emulując zapytania użytkownika pracującego z wykresami. Aby nie komplikować zbytnio, wybieraliśmy dane dla 10 metryk (dokładnie tyle ich było na wykresie CPU) za tydzień.
Obciążamy, emulując zachowanie agenta naszego monitoringu, który wysyła wartości do każdej metryki co 15 sekund. Przy tym interesuje nas zmienić:
- ogólną liczbę metryk, do których są zapisywane dane;
- interwał wysyłania wartości do jednej metryki;
- rozmiar partii.
O rozmiarze partii. Ponieważ niemal wszystkie nasze testowe bazy nie zalecają obciążania jednorazowymi insertami, potrzebujemy relay'a, który zbiera przychodzące metryki i grupuje je, a następnie zapisuje je do bazy za pomocą batch insert.
Aby lepiej zrozumieć, jak później interpretować otrzymane dane, wyobraźmy sobie, że nie wysyłamy po prostu mnóstwa metryk, ale metryki zorganizowane w serwery — po 125 metryk na serwer. Tutaj serwer to po prostu wirtualna jednostka — by zrozumieć, że na przykład 10 000 metryk odpowiada około 80 serwerom.
I z uwagi na to, nasze 6 trybów obciążenia bazy na zapis:
Są tu dwie rzeczy. Po pierwsze, dla Cassandry te rozmiary batchy okazały się zbyt duże, tam używaliśmy wartości 50 lub 100. Po drugie, ponieważ Prometeusz działa wyłącznie w trybie pull, tzn. sam pobiera dane z źródeł metryk (a nawet pushgateway, mimo nazwy, w zasadzie nie zmienia sytuacji), odpowiednie obciążenia zostały zrealizowane za pomocą kombinacji statycznych konfiguracji.
Wyniki testowania są następujące:
Co warto zauważyć: fantastycznie szybkie zapytania z Prometeusza, przeraźliwie wolne zapytania z Cassandry, nieakceptowalnie wolne zapytania z InfluxDB; pod względem szybkości zapisu wygrał ClickHouse, a Prometeusz nie bierze udziału w rywalizacji, ponieważ sam wprowadza dane w sobie i niczego nie mierzymy.
W konsekwencji,: najlepiej wypadły ClickHouse i InfluxDB, ale klaster z Influxa można zbudować tylko na podstawie wersji Enterprise, która kosztuje pieniądze, a ClickHouse nic nie kosztuje i został stworzony w Rosji. Logicznym jest, że w USA wybór prawdopodobnie pada na InfluxDB, a u nas — na ClickHouse.
Źródło: habr.com
