— to system zarządzania bazami danych oparta na kolumnach do online'owego przetwarzania zapytań analitycznych (OLAP) z otwartym kodem źródłowym, stworzona przez Yandex. Używają jej firmy takie jak Yandex, CloudFlare, VK.com, Badoo oraz inne serwisy na całym świecie do przechowywania naprawdę dużych zbiorów danych (wstawianie tysięcy wierszy na sekundę lub petabajty danych przechowywanych na dysku).
W standardowej, «wierszowej» bazie danych, przykładami których są MySQL, Postgres, MS SQL Server, dane są przechowywane w takiej kolejności:
Przy tym wartości odnoszące się do jednego wiersza są fizycznie przechowywane blisko siebie. W kolumnowych bazach danych wartości z różnych kolumn są przechowywane osobno, a dane jednej kolumny – razem:
Przykładami kolumnowych baz danych są Vertica, Paraccel (Actian Matrix, Amazon Redshift), Sybase IQ, Exasol, Infobright, InfiniDB, MonetDB (VectorWise, Actian Vector), LucidDB, SAP HANA, Google Dremel, Google PowerDrill, Druid, kdb+.
Firma – przekierowująca maile zaczęła korzystać z Clickhouse w 2018 roku do przygotowywania raportów i była bardzo pod wrażeniem jego prostoty, skalowalności, wsparcia dla SQL oraz szybkości. Prędkość działania tej bazy danych graniczyła z magią.
Prostota
Clickhouse instalowany jest w Ubuntu jednym poleceniem. Jeśli znasz SQL, możesz od razu zacząć używać Clickhouse do swoich potrzeb. Jednak nie oznacza to, że możesz wykonać „show create table” w MySQL i skopiować SQL do Clickhouse.
W porównaniu do MySQL, w tej bazie danych istnieją istotne różnice w typach danych w definicjach schematów tabeli, dlatego dla wygodnej pracy będziesz potrzebować trochę czasu na dostosowanie definicji schematów tabel i poznawanie silników tabel.
Clickhouse działa doskonale bez dodatkowego oprogramowania, ale jeśli chcesz korzystać z replikacji, będziesz musiał zainstalować ZooKeeper. Analiza wydajności zapytań pokazuje świetne wyniki — tabele systemowe zawierają wszystkie informacje, a wszystkie dane można uzyskać za pomocą starego i nudnego SQL.
Wydajność
- porównania Clickhouse z Vertica i MySQL na serwerze o konfiguracji: dwa gniazda Intel® Xeon® CPU E5-2650 v2 @ 2.60GHz; 128 GiB RAM; md RAID-5 na 8 dyskach SATA HDD po 6 TB, ext4.
- porównania Clickhouse z chmurą danych Amazon RedShift.
- Wyciągi z bloga :
Baza danych ClickHouse ma bardzo prosty design — wszystkie węzły w klastrze mają taką samą funkcjonalność i korzystają tylko z ZooKeeper do koordynacji. Zbudowaliśmy mały klaster z kilku węzłów i przeprowadziliśmy testy, podczas których odkryliśmy, że system ma dość imponującą wydajność, która odpowiada deklarowanym zaletom w benchmarkach analitycznych baz danych. Postanowiliśmy dokładniej zbadać koncepcję stojącą za ClickHouse. Pierwszą przeszkodą w badaniach było brak narzędzi i mała liczba użytkowników ClickHouse, dlatego zagłębiliśmy się w projekt tej bazy danych, aby zrozumieć, jak to działa.
ClickHouse nie obsługuje przyjmowania danych bezpośrednio z Kafka, ponieważ jest to tylko baza danych, dlatego napisaliśmy własną usługę adapterów w języku Go. Odczytywał zakodowane wiadomości Cap’n Proto z Kafka, przekształcał je w TSV i wstawiał do ClickHouse partiami przez interfejs HTTP. Później przepisaliśmy tę usługę, aby korzystała z biblioteki Go w połączeniu z własnym interfejsem ClickHouse w celu zwiększenia wydajności. Podczas oceny wydajności przyjmowania pakietów odkryliśmy coś ważnego — okazało się, że wydajność ClickHouse w dużej mierze zależy od rozmiaru pakietu, a więc od liczby równocześnie wstawianych wierszy. Aby zrozumieć, dlaczego tak się dzieje, zbadaliśmy, jak ClickHouse przechowuje dane.
Podstawowym silnikiem, a właściwie rodziną silników dla tabel, używaną przez ClickHouse do przechowywania danych, jest MergeTree. Ten silnik jest koncepcyjnie podobny do algorytmu LSM stosowanego w Google BigTable czy Apache Cassandra, jednak unika budowania tymczasowej tabeli w pamięci i zapisuje dane bezpośrednio na dysk. Daje mu to doskonałą przepustowość zapisu, ponieważ każdy wstawiony pakiet jest sortowany tylko według „klucza podstawowego” primary key, kompresowany i zapisywany na dysku, aby utworzyć segment.
Brak tabeli pamięci lub jakiegokolwiek pojęcia "świeżości" danych oznacza również, że można je jedynie dodawać; modyfikacje lub usunięcia nie są wspierane przez system. Do dziś jedynym sposobem na usunięcie danych jest usunięcie ich w cyklach miesięcznych, ponieważ segmenty nigdy nie przekraczają granicy miesiąca. Zespół ClickHouse intensywnie pracuje nad tym, aby uczynić tę funkcję konfigurowalną. Z drugiej strony, to sprawia, że zapis i łączenie segmentów są bezkonfliktowe, co z kolei umożliwia liniowe skalowanie przepustowości przyjęcia wraz z liczbą równoległych wstawek, aż do momentu nasycenia I/O lub rdzeni.
Jednakże ta okoliczność oznacza również, że system nie nadaje się do małych paczek, dlatego do buforowania używane są usługi Kafka i insertery. Ponadto ClickHouse w tle nieustannie wykonuje łączenie segmentów, dzięki czemu wiele drobnych części informacji jest scalanych i zapisywanych więcej razy, co zwiększa intensywność zapisu. Przy tym zbyt wiele niepowiązanych części spowoduje agresywne ograniczenie wstawek, dopóki trwają procesy łączenia. Odkryliśmy, że najlepszym kompromisem między przyjęciem danych w czasie rzeczywistym a wydajnością przyjęcia jest przyjmowanie w tabeli ograniczonej liczby wstawek na sekundę.
Kluczem do wydajności odczytu tabel jest indeksowanie oraz lokalizacja danych na dysku. Niezależnie od tego, jak szybka jest obróbka, gdy silnik musi przeskanować terabajty danych z dysku i użyć tylko ich części, zajmuje to czas. ClickHouse jest magazynem kolumnowym, dlatego każdy segment zawiera plik dla każdej kolumny z posortowanymi wartościami dla każdego wiersza. Dzięki temu całe kolumny, które nie są w zapytaniu, mogą być pominięte, a następnie kilka komórek może być przetwarzanych równolegle przy użyciu wektoryzowanego wykonania. Aby uniknąć pełnego skanowania, każdy segment ma mały plik indeksowy.
Biorąc pod uwagę, że wszystkie kolumny są uporządkowane według „klucza podstawowego”, plik indeksu zawiera tylko etykiety (uchwycone wiersze) każdego N-tego wiersza, aby móc je przechowywać w pamięci, nawet dla bardzo dużych tabel. Na przykład można ustawić domyślne opcje na „oznaczanie każdego 8192. wiersza”, wtedy „ubogie” indeksowanie tabeli z 1 bilionem wierszy, które łatwo mieści się w pamięci, zajmie tylko 122 070 znaków.
Rozwój systemu
Rozwój i doskonalenie Clickhouse można śledzić na i upewnić się, że proces „dorastania” przebiega w imponującym tempie.
Popularność
Wygląda na to, że popularność Clickhouse rośnie wykładniczo, szczególnie w społeczności rosyjskojęzycznej. Konferencja High load 2018 w zeszłym roku (Moskwa, 8-9 listopada 2018 r.) pokazała, że tacy giganci jak vk.com i Badoo korzystają z Clickhouse, za pomocą którego wprowadzają dane (np. logi) z dziesiątek tysięcy serwerów jednocześnie. W 40-minutowym wideo . Wkrótce opublikujemy transkrypcję na Habrze dla ułatwienia pracy z materiałem.
Obszary zastosowania
Po spędzeniu pewnego czasu na badaniach, sądzę, że istnieją obszary, w których ClickHouse może być korzystny lub w pełni zastąpić inne, bardziej tradycyjne i popularne rozwiązania, takie jak MySQL, PostgreSQL, ELK, Google Big Query, Amazon RedShift, TimescaleDB, Hadoop, MapReduce, Pinot i Druid. Szczegóły dotyczące wykorzystania ClickHouse do modernizacji lub całkowitej wymiany powyższych baz danych przedstawiono poniżej.
Rozszerzenie możliwości MySQL i PostgreSQL
Niedawno częściowo zastąpiliśmy MySQL ClickHouse na platformie informacji o biuletynach Problem polegał na tym, że MySQL z powodu nieprzemyślanej struktury rejestrował każde wysłane e-mail oraz każdy link w tych e-mailach z hashem base64, tworząc ogromną tabelę MySQL (email_stats). Po wysłaniu subskrybentom usługi zaledwie 10 milionów e-maili ta tabela zajmowała 150 GB przestrzeni dyskowej, a MySQL zaczynał „zwalniać” przy prostych zapytaniach. Aby rozwiązać problem z przestrzenią dyskową, skutecznie zastosowaliśmy kompresję tabeli InnoDB, co zmniejszyło jej rozmiar czterokrotnie. Jednak nadal nie ma sensu przechowywać więcej niż 20-30 milionów e-maili w MySQL tylko po to, aby zachować historię, ponieważ każde proste zapytanie, które z jakiegoś powodu musi wykonać pełne skanowanie, prowadzi do swapa i dużego obciążenia I/O, co regularnie skutkowało ostrzeżeniami Zabbix.
Clickhouse wykorzystuje dwa algorytmy kompresji, które zmniejszają objętość danych o około , ale w tym konkretnym przypadku dane były szczególnie "kompresowalne".
Zastąpienie ELK
Na podstawie własnego doświadczenia stos ELK (ElasticSearch, Logstash i Kibana, w tym konkretnym przypadku ElasticSearch) wymaga znacznie więcej zasobów do uruchomienia, niż to konieczne do przechowywania logów. ElasticSearch to świetny silnik, jeśli potrzebujesz dobrego wyszukiwania pełnotekstowego w logach (a nie sądzę, że rzeczywiście tego potrzebujesz), ale ciekawe jest, dlaczego de facto stał się standardowym silnikiem do prowadzenia logów. Jego wydajność przyjmowania w połączeniu z Logstash sprawiała nam problemy nawet przy stosunkowo niewielkich obciążeniach i wymagała dodawania coraz większej ilości pamięci RAM i przestrzeni dyskowej. Jako baza danych, Clickhouse jest lepszy od ElasticSearch z następujących powodów:
- Wsparcie dla dialektu SQL;
- Lepszy stopień kompresji przechowywanych danych;
- Wsparcie wyszukiwania wyrażeń regularnych zamiast wyszukiwania pełnotekstowego;
- Ulepszone planowanie zapytań i wyższa ogólna wydajność.
Obecnie największym problemem przy porównywaniu ClickHouse z ELK jest brak rozwiązań do przesyłania logów, a także niedobór dokumentacji i materiałów szkoleniowych w tym zakresie. Każdy użytkownik może jednak skonfigurować ELK korzystając z przewodnika Digital Ocean, co jest niezwykle ważne dla szybkiego wdrożenia takich technologii. Istnieje silnik bazy danych, ale jak na razie brakuje Filebeat dla ClickHouse. Tak, jest tam obecny i systema do pracy z logami , istnieje narzędzie do wprowadzania danych logów do ClickHouse, ale wszystko to zajmuje więcej czasu. Mimo to ClickHouse nadal dominuje ze względu na swoją prostotę, więc nawet nowicjusze mogą go zainstalować i rozpocząć pełnoprawne użytkowanie dosłownie w ciągu 10 minut.
Preferując minimalistyczne rozwiązania, próbowałem użyć FluentBit, narzędzie do przesyłania logów o bardzo małym zużyciu pamięci, razem z ClickHouse, starając się unikać użycia Kafka. Jednak konieczne jest rozwiązanie drobnych niezgodności, takich jak , zanim będzie można to zrobić bez warstwy proxy, która przekształca dane z FluentBit do ClickHouse.
Alternatywnie, jako backend do ClickHouse można użyć . Z tego, co rozumiem, mogą wystąpić problemy z wydajnością przy renderowaniu ogromnej liczby punktów danych, szczególnie w starszych wersjach Grafana. W Qwintry jeszcze tego nie próbowaliśmy, ale skargi na to od czasu do czasu pojawiają się na kanale wsparcia ClickHouse w Telegramie.
Zamiennik Google Big Query i Amazon RedShift (rozwiązanie dla dużych przedsiębiorstw)
Idealnym zastosowaniem BigQuery jest załadowanie 1 TB danych JSON i wykonywanie na nich zapytań analitycznych. Big Query to znakomity produkt, którego skalowalność jest trudna do przecenienia. To znacznie bardziej skomplikowane oprogramowanie niż ClickHouse, działające na wewnętrznym klastrze, ale z punktu widzenia klienta ma wiele wspólnego z ClickHouse. BigQuery może szybko "podrożeć", gdy zaczniesz płacić za każde SELECT, więc to prawdziwe rozwiązanie SaaS ze wszystkimi swoimi zaletami i wadami.
ClickHouse jest najlepszym wyborem, gdy wykonujesz wiele kosztownych obliczeniowo zapytań. Im więcej zapytań SELECT wykonujesz codziennie — tym bardziej sensowne jest zastąpienie Big Query ClickHouse, ponieważ taka wymiana pomoże Ci zaoszczędzić tysiące dolarów, gdy mówimy o wielu terabajtach przetwarzanych danych. To nie dotyczy danych przechowywanych, których przetwarzanie w Big Query jest stosunkowo tanie.
W artykule współzałożyciela firmy Altinity Aleksandra Zajcewa opisywane są zalety takiej migracji bazy danych.
Zamiennik TimescaleDB
TimescaleDB jest rozszerzeniem PostgreSQL, które optymalizuje pracę z danymi czasowymi w tradycyjnej bazie danych., ).
Chociaż ClickHouse nie jest poważnym konkurentem w niszy danych czasowych, jego struktura kolumnowa i wektorowe wykonywanie zapytań sprawiają, że w większości przypadków przetwarzania zapytań analitycznych jest znacznie szybszy niż TimescaleDB. Ponadto wydajność przyjmowania danych partiami w ClickHouse jest około 3 razy wyższa, a do tego zużywa 20 razy mniej miejsca na dysku, co jest naprawdę istotne przy przetwarzaniu dużych zbiorów danych historycznych..
W przeciwieństwie do ClickHouse, jedynym sposobem na zaoszczędzenie miejsca na dysku w TimescaleDB jest użycie systemu plików ZFS lub podobnych.
Nadchodzące aktualizacje ClickHouse prawdopodobnie wprowadzą kompresję delta, co uczyni go jeszcze bardziej odpowiednim do przetwarzania i przechowywania danych czasowych. TimescaleDB może być lepszym wyborem niż "goły" ClickHouse w następujących przypadkach:
- małe instalacje z bardzo małą ilością pamięci RAM (<3 GB);
- duża liczba małych INSERT-ów, które nie chcą być bufrowane w duże fragmenty;
- lepsza spójność, jednolitość i wymogi ACID;
- wsparcie PostGIS;
- integracja z istniejącymi tabelami PostgreSQL, ponieważ w zasadzie TimescaleDB jest PostgreSQL.
konkurencja z systemami Hadoop i MapReduce
Hadoop i inne produkty MapReduce mogą przeprowadzać wiele skomplikowanych obliczeń, ale zazwyczaj działają z ogromnymi opóźnieniami. ClickHouse rozwiązuje ten problem, przetwarzając terabajty danych i niemal natychmiast wydając wyniki. Dzięki temu ClickHouse jest znacznie bardziej efektywny w przeprowadzaniu szybkich, interaktywnych badań analitycznych, co powinno zainteresować specjalistów w dziedzinie przetwarzania danych.
konkurencja z Pinot i Druid
Najbliższymi konkurentami ClickHouse są kolumnowe produkty open source skalowane liniowo: Pinot i Druid. Doskonała analiza porównawcza tych systemów została opublikowana w artykule z 1 lutego 2018 r.
Artykuł wymaga aktualizacji – stwierdza, że ClickHouse nie obsługuje operacji UPDATE i DELETE, co nie jest całkowicie prawdą w odniesieniu do najnowszych wersji.
Nie mamy wystarczającego doświadczenia z tymi bazami danych, ale całkowicie nie podoba mi się złożoność infrastruktury wymaganej do uruchomienia Druid i Pinot — to wszystko jest mnóstwo "ruchomych części", otoczonych Javą z każdej strony.
Druid i Pinot to projekty inkubatorowe Apache, których rozwój jest szczegółowo relacjonowany przez Apache na stronach ich projektów GitHub. Pinot pojawił się w inkubatorze w październiku 2018, a Druid zadebiutował 8 miesięcy wcześniej – w lutym.
Brak informacji na temat działania AFS budzi we mnie pewne, być może nierozsądne, pytania. Ciekawe, czy autorzy Pinot zauważyli, że Apache Foundation jest bardziej przychylne Druid, i czy takie podejście do konkurencji wywołało uczucie zazdrości? Czy rozwój Druid zwolni, a rozwój Pinot przyspieszy, jeśli sponsorzy wspierający pierwszy nagle zainteresują się drugim?
Wady ClickHouse
Niedojrzałość: oczywiście, że to wciąż interesująca technologia, ale w każdym razie nie zauważa się nic podobnego w innych bazach danych kolumnowych.
Małe wstawki źle działają przy wysokiej prędkości: wstawki powinny być podzielone na większe kawałki, ponieważ wydajność małych wstawek spada proporcjonalnie do liczby kolumn w każdym wierszu. Tak właśnie w ClickHouse dane są przechowywane na dysku — każda kolumna oznacza 1 plik lub więcej, dlatego, aby wstawić 1 wiersz zawierający 100 kolumn, należy otworzyć i zapisać co najmniej 100 plików. Dlatego do buforowania wstawek potrzebny jest pośrednik (chyba że sam klient zapewnia buforowanie) — zazwyczaj jest to Kafka lub jakiś system zarządzania kolejkami. Można również użyć silnika Buffer table, aby później kopiować duże fragmenty danych do tabel MergeTree.
Połączenia tabel ograniczone są pamięcią operacyjną serwera, ale przynajmniej są! Na przykład Druid i Pinot w ogóle nie mają takich połączeń, ponieważ trudno je zaimplementować bezpośrednio w rozproszonych systemach, które nie wspierają przenoszenia dużych kawałków danych między węzłami.
Wnioski
W najbliższych latach planujemy szerokie wdrożenie ClickHouse w Qwintry, ponieważ ta baza danych zapewnia doskonałą równowagę między wydajnością, niskimi kosztami, skalowalnością i prostotą. Jestem niemal pewien, że zacznie się szybko rozwijać, gdy społeczność ClickHouse wymyśli więcej sposobów na jej wykorzystanie w małych i średnich instalacjach.
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
