Przechodzimy na ClickHouse: 3 lata później

Trzy lata temu Wiktor Tarnawski i Aleksiej Miłowidow z Yandexu na scenie HighLoad++ opowiadaliśmy, jak dobry jest ClickHouse i jak nie spowalnia. A na sąsiedniej scenie był Aleksander Zajcew z referat o migracji na ClickHouse inną analityczną bazę danych, z wnioskiem, że ClickHouse, oczywiście, jest dobry, ale niezbyt wygodny. Kiedy w 2016 roku firma LifeStreet, w której wtedy pracował Aleksander, przenosiła wielopetabajtowy system analityczny na ClickHouse, była to fascynująca "droga po żółtych cegłach", pełna nieznanych niebezpieczeństw — ClickHouse wtedy przypominała pole minowe.

Trzy lata później ClickHouse stał się znacznie lepszy — w tym czasie Aleksander założył firmę Altinity, która nie tylko pomaga przemieszczać się do ClickHouse dziesiątek projektów, ale również udoskonala sam produkt razem z kolegami z Yandexu. Teraz ClickHouse to już nie jest beztroski spacer, ale też nie jest to już pole minowe.

Aleksander zajmuje się systemami rozproszonymi od 2003 roku, opracowywał duże projekty na MySQL, Oracle. i VerticaNa odbywającym się HighLoad++ 2019 Aleksander, jeden z pionierów użycia ClickHouse, opowiedział, co obecnie sobą reprezentuje ta baza danych. Dowiemy się o głównych cechach ClickHouse: czym różni się od innych systemów i w jakich przypadkach jest skuteczniej używać. Na przykładach przyjrzymy się świeżym i sprawdzonym praktykom w budowaniu systemów na ClickHouse.

Retrospektywa: co działo się 3 lata temu

Trzy lata temu przenosiliśmy firmę LifeStreet na ClickHouse z innej bazy danych, a migracja analizy sieci reklamowej wyglądała tak:

• Czerwiec 2016. W OpenSource pojawił się ClickHouse i wystartował nasz projekt;
• Sierpień. Proof Of Concept: duża sieć reklamowa, infrastruktura i 200-300 terabajtów danych;
• Październik. Pierwsze dane produkcyjne;
• Grudzień. Pełne obciążenie produktowe — 10-50 miliardów zdarzeń dziennie.
• Czerwiec 2017. Udany transfer użytkowników na ClickHouse, 2,5 petabajtów danych na klastrze z 60 serwerami.

W trakcie migracji rosło zrozumienie, że ClickHouse — to dobry system, z którym przyjemnie się pracuje, ale to wewnętrzny projekt firmy Yandex. Dlatego są pewne niuanse: Yandex najpierw zajmie się własnymi wewnętrznymi klientami, a dopiero potem — zewnętrzną społecznością i potrzebami użytkowników zewnętrznych, a ClickHouse wtedy nie dorównywał poziomowi enterprise w wielu obszarach funkcjonalnych. Dlatego w marcu 2017 roku założyliśmy firmę Altinity, aby go rozwijać. ClickHouse jeszcze szybciej i wygodniej nie tylko dla Yandeksu, ale także dla innych użytkowników. A teraz my:

• Szkolimy i pomagamy budować rozwiązania na ClickHouse tak, aby klienci nie napotykali trudności i aby rozwiązanie ostatecznie działało;
• Zapewniamy wsparcie 24/7 ClickHouse-instalacji;
• Opracowujemy własne projekty ekosystemowe;
• Aktywnie angażujemy się w sam ClickHouse, odpowiadając na zapytania użytkowników, którzy chcą widzieć różne funkcje.

I oczywiście, pomagamy z migracją na ClickHouse z MySQL, Vertica, Oracle, Greenplum, Redshift i inne systemy. Uczestniczyliśmy w różnych migracjach, i wszystkie były udane.

Po co w ogóle migrować na ClickHouse

Nie zwalnia! To główny powód. ClickHouse — bardzo szybka baza danych do różnych scenariuszy:

Przypadkowe cytaty ludzi, którzy długo pracują z ClickHouse.

Skalowalność. Na jakiejś innej bazie danych można osiągnąć przyzwoitą wydajność na jednym serwerze, ale ClickHouse można skalować nie tylko pionowo, ale także poziomo, po prostu dodając serwery. Wszystko działa nie tak gładko, jak byśmy chcieli, ale działa. Można rozwijać system razem z rozwojem biznesu. To ważne, że nie jesteśmy ograniczeni do obecnego rozwiązania i zawsze jest potencjał dla rozwoju.

Przenośność. Nie ma związania z czymś jednym. Na przykład, z Amazon Redshift ciężko gdziekolwiek migrować. A ClickHouse można zainstalować na swoim laptopie, serwerze, wdrożyć w chmurze, przejść do Kubernetes — nie ma ograniczeń w eksploatacji infrastruktury. To wygodne dla wszystkich, i to duża zaleta, której nie mogą się pochwalić wiele innych podobnych baz danych.

Elastyczność. ClickHouse nie ogranicza się do jednego rozwiązania, na przykład, Yandex.Metrica, ale rozwija się i jest wykorzystywana w coraz większej liczbie różnych projektów i branż. Można ją rozszerzać, dodając nowe możliwości do rozwiązywania nowych zadań. Na przykład, uważa się, że przechowywanie logów w bazie danych jest faux pas, dlatego wymyślono Elasticsearch. Ale dzięki elastyczności ClickHouse, można w niej również przechowywać logi, i często jest to nawet lepsze niż w Elasticsearch — w ClickHouse do tego potrzeba 10 razy mniej sprzętu.

Darmowy Bardzo interesujące, ale mało znane narzędzie. W naszym przypadku za jego pomocą uruchomimy Juniper vMX i Cisco xRV9000 na zwykłym Ubuntu 20.04 LTS.. Nie trzeba za nic płacić. Nie trzeba negocjować pozwolenia na zainstalowanie systemu na swoim laptopie lub serwerze. Nie ma ukrytych opłat. Przy tym żadna inna technologia baz danych Open Source nie może rywalizować z prędkością z ClickHouse. MySQL, MariaDB, Greenplum — wszystkie są znacznie wolniejsze.

Społeczność, napęd i fun. U ClickHouse wspaniała społeczność: meetupy, czaty i Aleksiej Milowidow, który zaraża nas swoją energią i optymizmem.

Migracja do ClickHouse

Aby przejść na ClickHouse z czegoś, potrzebne są tylko trzy rzeczy:

• Zrozumieć ograniczenia ClickHouse i do czego nie jest odpowiedni.
• Wykorzystać zalety technologii i jej najmocniejsze strony.
• Eksperymentować. Nawet rozumiejąc, jak działa ClickHouse, nie zawsze można przewidzieć, kiedy będzie szybszy, kiedy wolniejszy, kiedy lepszy, a kiedy gorszy. Dlatego próbujcie.

Problem migracji

Jest tylko jedno «ale»: jeśli migrujesz z ClickHouse czegoś innego, to zazwyczaj coś idzie nie tak. Przyzwyczailiśmy się do pewnych praktyk i rzeczy, które działają w naszej ulubionej bazie danych. Na przykład każdy, kto pracuje z bazami danych SQL, uważa, że taki zestaw funkcji jest niezbędny:transakcje;

• ograniczenia;
• spójność;
• indeksy;
• UPDATE/DELETE
• NULLs;
• milisekundy;;
• automatyczne konwersje typów;
• wielokrotne złączenia;
• dowolne partycje;
• narzędzia do zarządzania klastrem.
• Zestaw jest obowiązkowy, ale trzy lata temu w

nie było żadnej z tych funkcji! Teraz z nierespektowanych pozostało mniej niż połowa: transakcje, ograniczenia, spójność, milisekundy i konwersja typów. ClickHouse I najważniejsze — to, że w

niektóre standardowe praktyki i podejścia nie działają lub działają inaczej niż się przyzwyczailiśmy. Wszystko, co pojawia się w ClickHouse , odpowiada « ClickHouseClickHouse way», to znaczy funkcje różnią się od innych baz danych. Na przykład:Indeksy nie są wybierane, a pomijane.

• nie są synchroniczne, a asynchroniczne.
• NULLs Wielokrotne złączenia istnieją, ale nie ma planera zapytań. Jak one są realizowane, nie jest zbyt jasne dla ludzi z świata baz danych.
• Scenariusze ClickHouse

W 1960 roku amerykański matematyk węgierskiego pochodzenia

Wigner E. P. napisał artykuł « The unreasonable effectiveness of mathematics in the natural sciences» («Niepojęta efektywność matematyki w naukach przyrodniczych») mówiący o tym, że świat wokół nas w jakiś sposób dobrze opisuje prawa matematyczne. Matematyka — nauka abstrakcyjna, a fizyczne prawa, wyrażone w postaci matematycznej, nie są trywialne, ipodkreślił, że to bardzo dziwne. napisał artykuł « Z mojej perspektywy,

— to ta sama dziwność. Przeformułowując Wignera, można powiedzieć tak: zdumiewająca jest niepojęta efektywność ClickHouse w najróżniejszych zastosowaniach analitycznych! ClickHouse Na przykład, weźmy

Magazyn Danych w Czasie Rzeczywistym Magazyn Danych w Czasie Rzeczywistym, do którego dane są ładowane praktycznie w sposób ciągły. Chcemy otrzymywać zapytania z opóźnieniem jednosekundowym. Proszę — używamy ClickHouse, ponieważ do tego scenariusza został zaprojektowany. ClickHouse właśnie w ten sposób jest używany nie tylko w sieci, ale także w marketingu i analizie finansowej, AdTech, a także w Fraud detection. W Real-time Data Warehouse stosuje się złożoną strukturalną schemę typu „gwiazda” lub „śnieżynka”, wiele tabel z JOIN (czasami wieloma), a dane zazwyczaj są przechowywane i zmieniane w jakichś systemach.

Weźmy inny scenariusz — Time Series: monitorowanie urządzeń, sieci, statystyki użycia, Internet rzeczy. Tutaj spotykamy uporządkowane w czasie dość proste zdarzenia. ClickHouse do tego nie został pierwotnie zaprojektowany, ale dobrze się sprawdził, dlatego duże firmy go używają ClickHouse jako magazyn informacji monitorujących. Aby zbadać, czy ClickHouse jest odpowiedni dla time-series, przeprowadziliśmy benchmark na podstawie podejścia i wyników InfluxDB i TimescaleDB — specjalistycznych baz danych time-series. Okazało się , że, nawet bez optymalizacji pod takie zadania, wygrywa i na obcym terenie: ClickHousezwykle stosowana jest wąska tabela — kilka małych kolumn. Z monitorowania może napływać bardzo dużo danych — miliony rekordów na sekundę — i zazwyczaj przychodzą one małymi wstawieniami (

W baz danych time-series. real-timestreaming). Dlatego potrzebny jest inny scenariusz wstawiania, a same zapytania — z pewną specyfiką. Log Management

. Zbieranie logów w bazie danych — zazwyczaj jest to słabe rozwiązanie, ale wmożna to robić z pewnymi uwagami, jak opisano powyżej. Wiele firm używa ClickHouse właśnie do tego. W takim przypadku stosowana jest płaska, szeroka tabela, w której przechowujemy logi w całości (na przykład w postaci ClickHouse ), lub dzielimy je na części. Dane zwykle ładowane są dużymi partiami (plikami), a szukamy po jakimś polu. YANGDo każdej z tych funkcji zazwyczaj stosuje się specjalistyczne bazy danych.

jeden może robić to wszystko i tak dobrze, że przewyższa je pod względem wydajności. Przyjrzyjmy się teraz dokładnie ClickHouse scenariuszowi i jak prawidłowo „przygotować” baz danych time-series. pod ten scenariusz. ClickHouse Time-Series

W tej chwili to główny scenariusz, dla którego

uważane jest za standardowe rozwiązanie. ClickHouse Time-series Seria czasowa to jest zestaw uporządkowanych w czasie zdarzeń, przedstawiających zmiany jakiegoś procesu w czasie. Na przykład, może to być częstotliwość bicia serca w ciągu dnia lub liczba procesów w systemie. Wszystko, co daje tętna czasowe z jakimiś pomiarami – to baz danych time-series.:

Najwięcej tego rodzaju zdarzeń pochodzi z monitoringu. Może to być nie tylko monitoring sieci, ale i rzeczywistych urządzeń: samochodów, systemów przemysłowych, IoT, produkcji lub autonomicznych taksówek, do bagażnika których Yandex już teraz wkłada ClickHouse-serwer.

Na przykład, są firmy, które zbierają dane z statków. Co kilka sekund czujniki na kontenerowcu wysyłają setki różnych pomiarów. Inżynierowie je analizują, budują modele i starają się zrozumieć, jak efektywnie wykorzystywany jest statek, ponieważ kontenerowiec nie powinien stać ani sekundy. Każda przerwa to strata pieniędzy, dlatego ważne jest przewidzenie trasy tak, aby postój był minimalny.

Obecnie obserwuje się wzrost wyspecjalizowanych baz danych, które mierzą baz danych time-series.. Na stronie DB-Engines w jakiś sposób są klasyfikowane różne bazy danych, które można przeglądać według typów:

Najbardziej dynamicznie rozwijający się typ to time-seriess. Również bazy danych grafowe zyskują na popularności, ale time-seriess rozwijają się szybciej w ostatnich kilku latach. Typowymi przedstawicielami baz danych tej rodziny są InfluxDB, Prometheus, KDB, TimescaleDB (zbudowana na PostgreSQL), rozwiązania od Amazon. ClickHouse tutaj również mogą być stosowane, i są stosowane. Podam kilka publicznych przykładów.

Jednym z pionierów jest firma CloudFlare (CDN-dostawca). Monitorują swoje CDN przez ClickHouse (DNS-zapytania, HTTP-zapytania) z ogromnym obciążeniem — 6 milionów zdarzeń na sekundę. Wszystko przechodzi przez Kafka, jest wysyłane do ClickHouse, który zapewnia możliwość w czasie rzeczywistym przeglądania pulpitów zdarzeń w systemie.

Comcast — jeden z liderów telekomunikacji w USA: internet, telewizja cyfrowa, telefonia. Stworzyli podobny system zarządzania CDN w ramach Bardzo interesujące, ale mało znane narzędzie. W naszym przypadku za jego pomocą uruchomimy Juniper vMX i Cisco xRV9000 na zwykłym Ubuntu 20.04 LTS. projektu Apache Traffic Control do pracy z ich ogromnymi danymi. ClickHouse jest używany jako backend do analityki.

Percona wbudowali ClickHouse w swój PMM, aby przechowywać monitorowanie różnych MySQL.

Specyficzne wymagania

Bazy danych typu time-series mają swoje specyficzne wymagania.

• Szybkie wstawianie z wielu agentów.Musimy bardzo szybko wstawiać dane z wielu strumieni. ClickHouse dobrze to robi, ponieważ wszystkie swoje wstawienia wykonuje bez blokowania. Jakiekolwiek insert — to nowy plik na dysku, a małe wstawki można buforować w różny sposób. W ClickHouse lepiej wstawiać dane dużymi pakietami, a nie po jednej linijce.
• Elastyczna schematy. W baz danych time-series. zazwyczaj nie znamy struktury danych do końca. Można zbudować system monitorowania dla konkretnej aplikacji, ale wtedy trudno jest go używać w innym zastosowaniu. Potrzebny jest bardziej elastyczny schemat. ClickHouse, co pozwala na to, nawet jeśli to jest ściśle typizowana baza.
• Efektywne przechowywanie i „zapominanie” danych. Zazwyczaj w baz danych time-series. gigantycznej ilości danych, więc należy je przechowywać maksymalnie efektywnie. Na przykład, u InfluxDB dobra kompresja — to jego główny atut. Ale oprócz przechowywania, należy też umieć „zapominać” stare dane i robić jakiś downsampling — automatyczne zliczanie agregatów.
• Szybkie zapytania o dane agregowane. Czasami interesuje nas ostatnie 5 minut z dokładnością do milisekund, ale w przypadku danych miesięcznych minutowa lub sekundowa granularność może nie być potrzebna — wystarczy ogólna statystyka. Wsparcie tego rodzaju jest konieczne, w przeciwnym razie zapytanie za 3 miesiące będzie wykonywane bardzo długo nawet w ClickHouse.
• Zapytania typu „last point, as of». To typowe dla baz danych time-series. zapytania: patrzymy na ostatnie pomiary lub stan systemu w danym momencie t. Dla baz danych to nie są zbyt przyjemne zapytania, ale też trzeba je umieć wykonywać.
• „Sklejenie” szeregów czasowych. Seria czasowa — to szereg czasowy. Jeśli są dwa szeregi czasowe, często potrzeba je łączyć i korelować. Nie w każdej bazie danych jest to wygodne do zrobienia, szczególnie z niewyregulowanymi szeregami czasowymi: tutaj — inne znaki czasowe, tam — inne. Można liczyć średnie, ale nagle będziemy mieli dziurkę, więc niezrozumiałe.

Spójrzmy, jak te wymagania są spełniane w ClickHouse.

Schemat

W ClickHouse schemat dla baz danych time-series. można zrobić na różne sposoby, w zależności od stopnia regularności danych. Można zbudować system w oparciu o regularne dane, kiedy znamy wszystkie metryki z góry. Na przykład, tak zrobił CloudFlare z monitorowaniem CDN — to dobrze zoptymalizowany system. Można zbudować bardziej ogólny system, który monitoruje całą infrastrukturę, różne usługi. W przypadku nieregularnych danych, nie wiemy z góry, co monitorujemy — i prawdopodobnie to jest najogólniejszy przypadek.

Regularne dane. Kolumny. Schemat prosty – kolumny z odpowiednimi typami:

UTWÓRZ TABELĘ cpu (
  created_date Date DEFAULT today(),  
  created_at DateTime DEFAULT now(),  
  time String,  
  tags_id UInt32,  
  /* połączenie do dim_tag */
  usage_user Float64,  
  usage_system Float64,  
  usage_idle Float64,  
  usage_nice Float64,  
  usage_iowait Float64,  
  usage_irq Float64,  
  usage_softirq Float64,  
  usage_steal Float64,  
  usage_guest Float64,  
  usage_guest_nice Float64
) ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

To jest zwykła tabela, która monitoruje pewną aktywność pod względem obciążenia systemu (użytkownik, system, bezczynność, miły). Prosta i wygodna, ale nie elastyczna. Jeśli potrzebujemy bardziej elastycznej struktury, można użyć tablic.

Dane nieregularne. Tablice:

UTWÓRZ TABELĘ cpu_alc (
  created_date Date,  
  created_at DateTime,  
  time String,  
  tags_id UInt32,  
  metrics Nested(
    name LowCardinality(String),  
    value Float64
  )
) ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

SELECT max(metrics.value[indexOf(metrics.name,'usage_user')]) FROM ...

Struktura Zagnieżdżony — to dwie tablice: metrics.name i metrics.value. Można tu przechowywać takie dowolne dane monitorujące, jak tablica nazw i tablica wartości przy każdym wydarzeniu. Aby dalej zoptymalizować, zamiast jednej takiej struktury można utworzyć kilka. Na przykład jedną dla float-wartości, drugą dla int-wartości, ponieważ int chcemy przechowywać to bardziej efektywnie.

Jednak taka struktura jest trudniejsza do obsługi. Będziemy musieli użyć specjalnej konstrukcji, aby wydobyć wartości najpierw z indeksu, a potem z tablicy:

SELECT max(metrics.value[indexOf(metrics.name,'usage_user')]) FROM ...

Ale to wciąż działa wystarczająco szybko. Innym sposobem przechowywania danych nieregularnych są wiersze.

Dane nieregularne. Wiersze. W tej tradycyjnej metodzie bez tablicy od razu przechowywane są nazwy i wartości. Jeśli z jednego urządzenia przychodzi od razu 5000 pomiarów — generowane jest 5000 wierszy w bazie danych:

UTWÓRZ TABELĘ cpu_rlc (
  created_date Date,  
  created_at DateTime,  
  time String,  
  tags_id UInt32,  
  metric_name LowCardinality(String),  
  metric_value Float64
) ENGINE = MergeTree(created_date, (metric_name, tags_id, created_at), 8192);


SELECT 
    maxIf(metric_value, metric_name = 'usage_user'),
    ... 
FROM cpu_r
WHERE metric_name IN ('usage_user', ...)

ClickHouse z tym radzi sobie — ma specjalne rozszerzenia ClickHouse SQL. Na przykład, maxIf — specjalna funkcja, która oblicza maksimum dla metryki spełniającej pewne warunki. Można w jednym zapytaniu napisać kilka takich wyrażeń i od razu obliczyć wartość dla kilku metryk.

Porównajmy trzy podejścia:

Szczegóły

Tutaj dodałem „Rozmiar danych na dysku” dla pewnego zestawu danych testowych. W przypadku kolumn mamy najmniejszy rozmiar danych: maksymalne kompresowanie, maksymalna prędkość zapytań, ale płacimy za to, że musimy wszystko od razu zablokować.

W przypadku tablic jest nieco gorzej. Dane nadal można dobrze kompresować, a także można przechowywać nieregularną strukturę. Ale ClickHouse — kolumnowa baza danych, a kiedy zaczynamy przechowywać wszystko w tablicy, to zamienia się w szereg, i płacimy za elastyczność wydajnością. Na operację trzeba załadować całą tablicę do pamięci, a następnie znaleźć w niej potrzebny element — a jeśli tablica rośnie, to prędkość degradacji.

W jednej z firm, która stosuje takie podejście (na przykład, Uber), tablice dzielą się na kawałki po 128 elementów. Dane kilku tysięcy metryk o objętości 200 TB danych/dzień nie są przechowywane w jednej tablicy, ale w 10 lub 30 tablicach z specjalną logiką przechowywania.

Najprostsze podejście polega na używaniu łańcuchów. Ale dane słabo się kompresują, rozmiar tabeli staje się duży, a kiedy zapytania są wykonywane na kilku metrykach, ClickHouse pracuje suboptymalnie.

Schemat hybrydowy

Załóżmy, że wybraliśmy schemat z tablicą. Ale jeśli wiemy, że większość naszych pulpitów nawigacyjnych pokazuje tylko metryki użytkownika i systemu, możemy dodatkowo z tablicy na poziomie tabeli zmaterializować te metryki w kolumnach w następujący sposób:

CREATE TABLE cpu_alc (
  created_date Date,  
  created_at DateTime,  
  time String,  
  tags_id UInt32,  
  metrics Nested(
    name LowCardinality(String),  
    value Float64
  ),
  usage_user Float64 
             MATERIALIZED metrics.value[indexOf(metrics.name,'usage_user')],
  usage_system Float64 
             MATERIALIZED metrics.value[indexOf(metrics.name,'usage_system')]
) ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

Podczas wstawiania ClickHouse automatycznie je policzy. To pozwala połączyć przyjemne z pożytecznym: schemat jest elastyczny i ogólny, ale najczęściej używane kolumny zostały wyciągnięte. Zaznaczam, że nie wymagało to zmiany wstawiania i ETL, który nadal wstawia tablice do tabeli. Po prostu zrobiliśmy ALTER TABLE, dodaliśmy kilka kolumn i otrzymaliśmy hybrydowy i szybszy schemat, którego można od razu zacząć używać.

Kodeki i kompresja

Dla baz danych time-series. ważne jest, jak dobrze pakujesz dane, ponieważ masa informacji może być bardzo duża. W ClickHouse istnieje zestaw narzędzi do osiągania efektu kompresji 1:10, 1:20, a czasem nawet więcej. To oznacza, że niepakowane dane o pojemności 1 TB na dysku zajmują 50-100 GB. Mniejszy rozmiar to zaleta, ponieważ dane można szybciej odczytywać i przetwarzać.

Aby osiągnąć wysoki poziom kompresji, ClickHouse obsługuje następujące kodeki:

Przykład tabeli:

CREATE TABLE benchmark.cpu_codecs_lz4 (
    created_date Date DEFAULT today(), 
    created_at DateTime DEFAULT now() Codec(DoubleDelta, LZ4), 
    tags_id UInt32, 
    usage_user Float64 Codec(Gorilla, LZ4), 
    usage_system Float64 Codec(Gorilla, LZ4), 
    usage_idle Float64 Codec(Gorilla, LZ4), 
    usage_nice Float64 Codec(Gorilla, LZ4), 
    usage_iowait Float64 Codec(Gorilla, LZ4), 
    usage_irq Float64 Codec(Gorilla, LZ4), 
    usage_softirq Float64 Codec(Gorilla, LZ4), 
    usage_steal Float64 Codec(Gorilla, LZ4), 
    usage_guest Float64 Codec(Gorilla, LZ4), 
    usage_guest_nice Float64 Codec(Gorilla, LZ4), 
    additional_tags String DEFAULT ''
)
ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

Tutaj definiujemy kodek DoubleDelta w jednym przypadku, w drugim — Gorilla, i koniecznie dodajemy jeszcze LZ4 kompresję. W rezultacie rozmiar danych na dysku znacznie się zmniejsza:

Tutaj widać, ile miejsca zajmują te same dane, ale przy użyciu różnych kodeków i kompresji:

• w pliku skompresowanym GZIP na dysku;
• w ClickHouse bez kodeków, ale z kompresją ZSTD;
• w ClickHouse z kodekami i kompresją LZ4 oraz ZSTD.

Widać, że tabele z kodekami zajmują znacznie mniej miejsca.

Rozmiar ma znaczenie

Nie mniej ważne jest wybrać właściwy typ danych:

We wszystkich powyższych przykładach użyłem Float64. Ale gdybyśmy wybrali Float32, byłoby to nawet lepsze. Dobrze pokazali to ludzie z Percony w artykule podlinkowanym powyżej. Ważne jest, aby używać maksymalnie kompaktowego typu, odpowiedniego do zadania: nawet w mniejszym stopniu dla rozmiaru na dysku, niż dla szybkości zapytań. ClickHouse jest na to bardzo wrażliwy.

Jeśli możesz użyć int32 zamiast int64, to spodziewaj się prawie podwojenia wydajności. Dane zajmują mniej pamięci, a cała 'arytmika' działa znacznie szybciej. ClickHouse wewnętrznie — to bardzo ściśle typizowany system, który maksymalnie wykorzystuje wszystkie możliwości, jakie oferują nowoczesne systemy.

Agregacja i Materialized Views

Agregacja i zmaterializowane widoki pozwalają na tworzenie agregatów na różne przypadki użycia:

Na przykład, możesz mieć nieaggregowane dane źródłowe, do których można podłączyć różne materializowane widoki z automatycznym sumowaniem za pomocą specjalnego silnika. SummingMergeTree (SMT). SMT to specjalna struktura danych do agregacji, która automatycznie oblicza agregaty. Surowe dane są wstawiane do bazy danych, automatycznie agregowane i od razu można z nich korzystać w dashboardach.

TTL zapominamy o starych danych

Jak „zapominać” dane, które już nie są potrzebne? ClickHouse potrafi to. Przy tworzeniu tabel można wskazać TTL wyrażenia: na przykład, że dane minutowe przechowujemy przez jeden dzień, dane dzienne – przez 30 dni, a dane tygodniowe lub miesięczne nie są w ogóle dotykane:

CREATE TABLE aggr_by_minute
…
TTL time + interval 1 day

CREATE TABLE aggr_by_day
…
TTL time + interval 30 day

CREATE TABLE aggr_by_week
…
/* no TTL */

Multi-tier dzielimy dane według dysków

Rozwijając tę ideę, dane można przechowywać ClickHouse w różnych miejscach. Załóżmy, że chcemy przechowywać gorące dane z ostatniego tygodnia na bardzo szybkim lokalnym SSD, a bardziej historyczne dane odkładamy w inne miejsce. W ClickHouse teraz to możliwe:

Można skonfigurować politykę przechowywania (storage policy) tak, że ClickHouse automatycznie przenosi dane po spełnieniu pewnych warunków do innego magazynu.

Ale to nie wszystko. Na poziomie konkretnej tabeli można określić zasady, kiedy dane przechodzą na zimne przechowywanie. Na przykład, przez 7 dni dane leżą na bardzo szybkim dysku, a wszystko, co starsze, przenoszone jest na wolniejszy. Jest to dobre, ponieważ pozwala systemowi utrzymać maksymalną wydajność, jednocześnie kontrolując koszty i nie wydając środków na zimne dane:

CREATE TABLE 
... 
TTL date + INTERVAL 7 DAY TO VOLUME 'cold_volume', 
    date + INTERVAL 180 DAY DELETE

Unikalne możliwości ClickHouse

Prawie w każdej dziedzinie w ClickHouse są takie „smaczki”, ale są one zrównoważone przez ekskluzywność — to, czego nie ma w innych bazach danych. Na przykład, oto niektóre z unikalnych funkcji ClickHouse:

• Tablice. W ClickHouse bardzo dobra obsługa tablic, a także możliwość wykonywania na nich skomplikowanych obliczeń.
• Struktury danych do agregacji. To jedna z „killer feature” ClickHouse. Mimo że ludzie z Yandexu mówią, że nie chcemy agregować danych, wszyscy agregują w ClickHouse, ponieważ to szybkie i wygodne.
• Materializowane widoki. Wraz z agregującymi strukturami danych zmaterializowane widoki pozwalają na wygodną streaming). Dlatego potrzebny jest inny scenariusz wstawiania, a same zapytania — z pewną specyfiką. agregację.
• ClickHouse SQL. To rozszerzenie języka SQL z kilkoma dodatkowymi i ekskluzywnymi funkcjami, które dostępne są tylko w ClickHouse. Kiedyś było to z jednej strony rozszerzenie, a z drugiej ograniczenie. Teraz prawie wszystkie wady w porównaniu do SQL 92 usunięto, teraz to tylko rozszerzenie.
• Wyrażenia Lambda– czy są jeszcze w jakiejś bazie danych?ML
• - wsparcie.Jest to dostępne w różnych bazach danych, w niektórych lepiej, w innych gorzej.Otwarty kod
• . Możemy rozwijaćrazem. Obecnie w ClickHouse jest około 500 kontrybutorów, a ta liczba stale rośnie. ClickHouse Sprytne zapytania

istnieje wiele różnych sposobów na zrealizowanie tego samego celu. Na przykład, można trzy różne sposoby zwrócić ostatnią wartość z tabeli dla

W ClickHouse (jest także czwarty, ale jest jeszcze bardziej egzotyczny). CPU Pierwszy sposób pokazuje, jak wygodnie to robić w

zapytaniach, gdy chcesz sprawdzić, czy ClickHouse krotka znajduje się w podzapytaniu. To jest coś, czego osobiście bardzo mi brakowało w innych bazach danych. Jeśli chcę coś porównać z podzapytaniem, to w innych bazach danych porównuję to tylko z wartością skalarną, a dla kilku kolumn muszę pisać można użyć krotki: JOIN. W ClickHouse SELECT * FROM cpu WHERE (tags_id, created_at) IN (SELECT tags_id, max(created_at) FROM cpu GROUP BY tags_id)

Drugi sposób robi to samo, ale używa funkcji agregującej

argMax SELECT argMax(usage_user), created_at), argMax(usage_system), created_at), ... FROM cpu:

jest kilka dziesiątek funkcji agregujących, a jeśli używać łączników, to według zasad kombinatoryki otrzymamy ich około tysiąca. 

W ClickHouse ArgMax to jedna z funkcji, która oblicza maksymalną wartość: zapytanie zwraca wartość usage_user , dla której osiągnięta została maksymalna wartośćcreated_at SELECT now() as created_at, cpu.* FROM (SELECT DISTINCT tags_id from cpu) base ASOF LEFT JOIN cpu USING (tags_id, created_at):

ASOF JOIN

– „łączenie” szeregów z różnymi czasami. To unikalna funkcja baz danych, która jest jeszcze tylko w kdb+ . Jeśli są dwa szereg czasowe z różnymi czasami,pozwala je przesunąć i połączyć w jednym zapytaniu. Dla każdej wartości w jednym szereg czasowym znajduje się najbliższa wartość w drugim, a one są zwracane w jednej linii: – „łączenie” szeregów z różnymi czasami. Funkcje analityczne

W standardzie

SQL-2003 można pisać tak: można pisać tak:

WYBIERZ origin,
       timestamp,
       timestamp -LAG(timestamp, 1) OVER (PARTITION BY origin ORDER BY timestamp) AS duration,
       timestamp -MIN(timestamp) OVER (PARTITION BY origin ORDER BY timestamp) AS startseq_duration,
       ROW_NUMBER() OVER (PARTITION BY origin ORDER BY timestamp) AS sequence,
       COUNT() OVER (PARTITION BY origin ORDER BY timestamp) AS nb
  Z MYTABLE
ORDER BY origin, timestamp;

W ClickHouse to nie działa — nie obsługuje standardu można pisać tak: i prawdopodobnie nigdy tego nie zrobi. Zamiast tego w ClickHouse przyjęło się pisać tak:

Obiecałem lambdy – oto są!

To jest analog zapytania analitycznego w standardzie można pisać tak:: oblicza różnicę między dwoma timestamp, duration, numer porządkowy — wszystko, co zwykle obliczamy jako funkcje analityczne. W ClickHouse liczymy je przez tablice: najpierw agregujemy dane do tablicy, a następnie na tablicy robimy wszystko, co chcemy, a potem rozwijamy z powrotem. Nie jest to zbyt wygodne, wymaga miłości do programowania funkcyjnego, co najmniej, ale jest bardzo elastyczne.

Funkcje specjalne

Ponadto w ClickHouse jest wiele specjalizowanych funkcji. Na przykład, jak określić, ile sesji przebiega równocześnie? Typowe zadanie w monitorowaniu – określić maksymalne obciążenie jednym zapytaniem. W ClickHouse jest specjalna funkcja do tego celu:

Ogólnie, dla wielu celów w ClickHouse są specjalne funkcje:

• runningDifference, runningAccumulate, neighbor;
• sumMap(key, value);
• timeSeriesGroupSum(uid, timestamp, value);
• timeSeriesGroupRateSum(uid, timestamp, value);
• skewPop, skewSamp, kurtPop, kurtSamp;
• WITH FILL / WITH TIES;
• simpleLinearRegression, stochasticLinearRegression.

To nie jest pełna lista funkcji, jest ich w sumie 500-600. Wskazówka: wszystkie funkcje w ClickHouse są w tabeli systemowej (nie wszystkie są udokumentowane, ale wszystkie są interesujące):

select * from system.functions order by name

ClickHouse sama w sobie przechowuje wiele informacji o sobie, w tym log tables, query_log, log śledzenia, log operacji z blokami danych (part_log), log metryk, i systemowy log, który z reguły zapisuje na dysk. Log metryk – to baz danych time-series. do ClickHouse na samym ClickHouse: Baza danych sama dla siebie może pełnić rolę baz danych time-series. baz danych, w ten sposób "pożerając" samą siebie.

To też unikalna rzecz — skoro wykonujemy dobrze pracę dla baz danych time-series., dlaczego nie możemy przechowywać wszystkiego, co potrzebne, w sobie? Nie potrzebujemy Prometheus, przechowujemy wszystko w sobie. Podłączyliśmy Grafana i monitorujemy siebie. Jednak, jeśli ClickHouse upadnie, to nie zobaczymy, — dlaczego, — dlatego zazwyczaj tak nie robimy.

Duży klaster czy wiele małych ClickHouse

Co lepsze — jeden duży klaster czy wiele małych ClickHouse? Tradycyjne podejście do DWH — to duży klaster, w którym przydzielane są schemy dla każdej aplikacji. Zwróciliśmy się do administratora bazy danych — dajcie nam schemę, a oni nam ją wydali:

W ClickHouse można to zrobić inaczej. Każdej aplikacji można przydzielić własną ClickHouse:

Nie potrzebujemy już dużego monstrualnego DWH i nieugiętych administratorów. Możemy każdej aplikacji przydzielić własne ClickHouse, a programista może to zrobić samodzielnie, ponieważ ClickHouse jest bardzo proste w instalacji i nie wymaga skomplikowanej administracji:

Ale jeśli mamy dużo ClickHouse, a często trzeba je instalować, to chcielibyśmy ten proces zautomatyzować. Można, na przykład, wykorzystać Kubernetes i clickhouse-operatora. W Kubernetes ClickHouse może być zainstalowany „jednym kliknięciem”: mogę nacisnąć przycisk, uruchomić manifest i baza jest gotowa. Można od razu stworzyć schemę, zacząć ładować metryki, a po 5 minutach już mam gotowy dashboard Grafana. Tak proste!

Co z tego wynika?

Otóż ClickHouse — to:

• Szybko. To wszystkim wiadomo.
• Prosto. Trochę kontrowersyjne, ale uważam, że trudno w nauce, łatwo w boju. Jeśli zrozumiesz, jak ClickHouse to działa, potem wszystko staje się bardzo proste.
• Uniwersalne. Nadaje się do różnych scenariuszy: DWH, Time Series, Log Storage. Ale to nie jest baza danych OLTP, więc nie próbuj robić tam krótkich wstawek i odczytów. Interesujące
• . Pewnie ten, kto pracuje z, przeżył wiele interesujących chwil w dobrym i złym sensie. Na przykład, pojawiła się nowa wersja, wszystko przestało działać. Lub kiedy zmagałeś się z zadaniem przez dwa dni, ale po pytaniu na czacie Telegram, problem rozwiązał się w dwie minuty. Albo jak na konferencji podczas wykładu Leszka Milovidova zrzut ekranu z ClickHousezłamał transmisję ClickHouse . Tego rodzaju rzeczy zdarzają się stale i sprawiają, że nasze życie z HighLoad++jest kolorowe i interesujące! ClickHouse Prezentację można zobaczyć

W oczekiwaniu na spotkanie deweloperów systemów o wysokim obciążeniu w tutaj.

odbędzie się 9 i 10 listopada w Skolkowie. W końcu będzie to konferencja offline (nawet z przestrzeganiem wszystkich środków ostrożności), ponieważ energii HighLoad++ nie można zapakować w formie online. HighLoad++ Na konferencję znajdujemy i pokazujemy wam przypadki maksymalnych możliwości technologii: HighLoad++ był, jest i będzie jedynym miejscem, gdzie można przez dwa dni dowiedzieć się, jak działają Facebook, Yandex, Vkontakte, Google i Amazon.

Na konferencji znajdujemy i pokazujemy przypadki maksymalnych możliwości technologii: HighLoad++ był, jest i będzie jedynym miejscem, gdzie w ciągu dwóch dni można dowiedzieć się, jak funkcjonują Facebook, Yandex, VKontakte, Google i Amazon.

Od 2007 roku nasze spotkania odbywają się bez przerwy, a w tym roku spotkamy się po raz 14. W tym czasie konferencja wzrosła dziesięciokrotnie. W ubiegłym roku kluczowe wydarzenie branżowe zgromadziło 3339 uczestników, 165 prelegentów oraz 16 równoległych ścieżek.
W ubiegłym roku mieliśmy dla Was 20 autobusów, 5280 litrów herbaty i kawy, 1650 litrów napojów owocowych oraz 10200 butelek wody. Dodatkowo 2640 kilogramów jedzenia, 16000 talerzy i 25000 kubków. Na marginesie, za pieniądze uzyskane z recyklingu papieru posadziliśmy 100 sadzonek dębu 🙂

Można kupić bilety tutaj, aby otrzymać wiadomości o konferencji — tutaj, a rozmowy prowadzić — na wszystkich platformach społecznościowych: Telegram, Facebook, Vkontakte i Twitter.

Źródło: habr.com