to system zarządzania kolumnową bazą danych typu open source do przetwarzania zapytań analitycznych online (OLAP) stworzony przez firmę Yandex. Jest używany przez Yandex, CloudFlare, VK.com, Badoo i inne serwisy na całym świecie do przechowywania naprawdę dużych ilości danych (wstawianie tysięcy wierszy na sekundę lub petabajtów danych przechowywanych na dysku).
W normalnym, „łańcuchowym” DBMS, którego przykładami są MySQL, Postgres, MS SQL Server, dane są przechowywane w następującej kolejności:
W tym przypadku wartości związane z jednym wierszem są fizycznie przechowywane obok siebie. W kolumnowym DBMS wartości z różnych kolumn są przechowywane osobno, a dane z jednej kolumny są przechowywane razem:
Przykładami kolumnowych systemów DBMS 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 jest spedytorem pocztowym Zacząłem używać Clickhouse w 2018 roku do raportowania i byłem pod wrażeniem jego prostoty, skalowalności, obsługi SQL i szybkości. Szybkość tego DBMS-a graniczyła z magią.
Łatwość
Clickhouse instaluje się na Ubuntu za pomocą jednego polecenia. Jeśli znasz SQL, możesz od razu zacząć używać Clickhouse do swoich potrzeb. Nie oznacza to jednak, że możesz „pokazać tworzenie tabeli” w MySQL i skopiować i wkleić SQL w Clickhouse.
W porównaniu z MySQL istnieją istotne różnice w typach danych w definicjach schematów tabel w tym systemie DBMS, więc nadal potrzebujesz trochę czasu, aby zmienić definicje schematów tabel i nauczyć się silników tabel, aby poczuć się komfortowo.
Clickhouse działa świetnie bez dodatkowego oprogramowania, ale jeśli chcesz korzystać z replikacji, musisz zainstalować ZooKeeper. Analiza wydajności zapytań pokazuje doskonałe wyniki - tabele systemowe zawierają wszystkie informacje, a wszystkie dane można uzyskać za pomocą starego i nudnego SQL.
produktywność
- Porównanie Clickhouse z Vertica i MySQL na serwerze konfiguracji: dwugniazdowy procesor Intel® Xeon® E5-2650 v2 @ 2.60 GHz; 128 GiB RAM; md RAID-5 na 8 dyskach twardych SATA 6 TB, ext4.
- porównanie Clickhouse z przechowywaniem w chmurze Amazon RedShift.
- Fragmenty bloga :
Baza danych ClickHouse ma bardzo prostą konstrukcję - wszystkie węzły w klastrze mają taką samą funkcjonalność i używają tylko ZooKeeper do koordynacji. Zbudowaliśmy mały klaster składający się z kilku węzłów i przeprowadziliśmy testy, podczas których stwierdziliśmy, że system ma dość imponującą wydajność, co odpowiada deklarowanym zaletom w analitycznych testach porównawczych DBMS. Postanowiliśmy przyjrzeć się bliżej koncepcji ClickHouse. Pierwszą przeszkodą w badaniach był brak narzędzi i mała społeczność ClickHouse, więc zagłębiliśmy się w projekt tego DBMS, aby zrozumieć, jak to działa.
ClickHouse nie obsługuje odbierania danych bezpośrednio z Kafki, ponieważ jest to tylko baza danych, dlatego napisaliśmy własną usługę adaptera w Go. Odczytywał zakodowane wiadomości Cap'n Proto od Kafki, konwertował je na TSV i wstawiał do ClickHouse partiami za pośrednictwem interfejsu HTTP. Później przepisaliśmy tę usługę, aby korzystać z biblioteki Go w połączeniu z naszym własnym interfejsem ClickHouse w celu poprawy wydajności. Oceniając wydajność odbierania pakietów odkryliśmy ważną rzecz - okazało się, że dla ClickHouse ta wydajność silnie zależy od rozmiaru pakietu, czyli liczby wierszy wprowadzanych w tym samym czasie. Aby zrozumieć, dlaczego tak się dzieje, zbadaliśmy, w jaki sposób ClickHouse przechowuje dane.
Głównym silnikiem, a raczej rodziną silników tabel używanych przez ClickHouse do przechowywania danych, jest MergeTree. Ten silnik jest koncepcyjnie podobny do algorytmu LSM używanego w Google BigTable lub Apache Cassandra, ale unika budowania tablicy pamięci pośredniej i zapisuje dane bezpośrednio na dysku. Zapewnia to doskonałą przepustowość zapisu, ponieważ każdy wstawiony pakiet jest sortowany tylko według klucza podstawowego „klucza podstawowego”, kompresowany i zapisywany na dysku w celu utworzenia segmentu.
Brak tablicy pamięci czy jakiejkolwiek koncepcji „świeżości” danych oznacza również, że można je jedynie dodawać, system nie obsługuje zmiany ani usuwania. Na dzień dzisiejszy jedynym sposobem na usunięcie danych jest usunięcie ich według miesiąca kalendarzowego, ponieważ segmenty nigdy nie przekraczają granicy miesiąca. Zespół ClickHouse aktywnie pracuje nad dostosowaniem tej funkcji. Z drugiej strony sprawia, że pisanie i łączenie segmentów odbywa się bez rywalizacji, więc przepustowość jest skalowana liniowo wraz z liczbą równoległych wstawek, aż do nasycenia we/wy lub rdzeni.
Jednak ta okoliczność oznacza również, że system nie nadaje się do małych pakietów, więc do buforowania wykorzystywane są usługi Kafki i insertery. Ponadto ClickHouse w tle kontynuuje ciągłe łączenie segmentów, dzięki czemu wiele małych fragmentów informacji zostanie połączonych i nagranych więcej razy, zwiększając w ten sposób intensywność nagrywania. Jednak zbyt wiele niepowiązanych części spowoduje agresywne ograniczanie wkładek, dopóki trwa scalanie. Odkryliśmy, że najlepszym kompromisem między pozyskiwaniem danych w czasie rzeczywistym a wydajnością pozyskiwania jest akceptacja ograniczonej liczby wstawień do tabeli na sekundę.
Kluczem do wydajności odczytu tabeli jest indeksowanie i lokalizacja danych na dysku. Bez względu na to, jak szybkie jest przetwarzanie, kiedy silnik musi przeskanować terabajty danych z dysku i wykorzystać tylko ich ułamek, zajmie to trochę czasu. ClickHouse to magazyn kolumnowy, więc każdy segment zawiera plik dla każdej kolumny (kolumny) z posortowanymi wartościami dla każdego wiersza. W ten sposób całe kolumny, których nie ma w zapytaniu, można najpierw pominąć, a następnie wiele komórek można przetwarzać równolegle z wykonaniem wektorowym. Aby uniknąć pełnego skanowania, każdy segment ma mały plik indeksu.
Biorąc pod uwagę, że wszystkie kolumny są posortowane według „klucza podstawowego”, plik indeksu zawiera tylko etykiety (przechwycone wiersze) każdego N-tego wiersza, aby móc je przechowywać w pamięci nawet w przypadku bardzo dużych tabel. Na przykład możesz ustawić domyślne ustawienia na „zaznaczanie każdego 8192 wiersza”, a następnie „skromne” indeksowanie tabeli z 1 bilionem. linie, które łatwo mieszczą się w pamięci, zajęłyby tylko 122 070 znaków.
Rozwój systemu
Rozwój i doskonalenie Clickhouse można prześledzić i upewnij się, że proces „dorastania” przebiega w imponującym tempie.
Popularność
Wygląda na to, że popularność Clickhouse rośnie wykładniczo, zwłaszcza w społeczności rosyjskojęzycznej. Zeszłoroczna konferencja High load 2018 (Moskwa, 8-9 listopada 2018) pokazała, że potwory takie jak vk.com czy Badoo wykorzystują Clickhouse, który wstawia dane (np. logi) z dziesiątek tysięcy serwerów jednocześnie. W 40 minutowym filmie . Wkrótce opublikujemy transkrypcję na Habr dla wygody pracy z materiałem.
Aplikacje
Po spędzeniu trochę czasu na badaniach, myślę, że są obszary, w których ClickHouse może być przydatne lub może całkowicie 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. Poniżej znajdują się szczegóły wykorzystania ClickHouse do aktualizacji lub całkowitej wymiany powyższego DBMS.
Rozszerzanie MySQL i PostgreSQL
Ostatnio częściowo zastąpiliśmy MySQL platformą do biuletynów ClickHouse . Problem polegał na tym, że MySQL z powodu nieprzemyślanego projektu rejestrował każdy wysłany e-mail i każdy link w tym e-mailu z hashem base64, tworząc ogromną tabelę MySQL (email_stats). Po wysłaniu zaledwie 10 milionów e-maili do abonentów usługi, ta tabela zajmowała 150 GB miejsca w plikach, a MySQL zaczął „głupić” na proste zapytania. Aby rozwiązać problem z przestrzenią plików, z powodzeniem zastosowaliśmy kompresję tabel InnoDB, która zmniejszyła ją czterokrotnie. Jednak nadal nie ma sensu przechowywać ponad 4-20 milionów e-maili w MySQL tylko ze względu na czytanie historii, ponieważ każde proste zapytanie, które z jakiegoś powodu musi wykonać pełne skanowanie, skutkuje zamianą i dużymi operacjami we/wy narzutu, o którym regularnie otrzymywaliśmy ostrzeżenia Zabbix.
Clickhouse wykorzystuje dwa algorytmy kompresji, które zmniejszają ilość danych o ok , ale w tym konkretnym przypadku dane były szczególnie „ściśliwe”.
Wymiana ELK
Z własnego doświadczenia wynika, że stos ELK (ElasticSearch, Logstash i Kibana, w tym konkretnym przypadku ElasticSearch) wymaga znacznie więcej zasobów do uruchomienia niż potrzeba do przechowywania logów. ElasticSearch to świetny silnik, jeśli chcesz dobrze przeszukiwać dzienniki pełnotekstowe (czego nie sądzę, abyś naprawdę potrzebował), ale zastanawiam się, dlaczego stał się de facto standardowym silnikiem rejestrowania. Jego wydajność przetwarzania w połączeniu z Logstash sprawiała nam problemy nawet przy dość lekkich obciążeniach i wymagała dodawania coraz większej ilości pamięci RAM i miejsca na dysku. Jako baza danych Clickhouse jest lepsza niż ElasticSearch z następujących powodów:
- obsługa dialektów SQL;
- Najlepszy stopień kompresji przechowywanych danych;
- Obsługa wyszukiwania Regex zamiast wyszukiwania pełnotekstowego;
- Ulepszone planowanie zapytań i lepsza ogólna wydajność.
Obecnie największym problemem, jaki pojawia się przy porównywaniu ClickHouse z ELK, jest brak rozwiązań do wgrywania logów, a także brak dokumentacji i samouczków na ten temat. Jednocześnie każdy użytkownik może skonfigurować ELK korzystając z instrukcji Digital Ocean, co jest bardzo ważne dla szybkiego wdrożenia takich technologii. Jest tutaj silnik bazy danych, ale nie ma jeszcze Filebeat dla ClickHouse. Tak jest oraz system do pracy z logami , istnieje narzędzie wprowadzić dane pliku dziennika do ClickHouse, ale to wszystko zajmuje więcej czasu. Jednak ClickHouse nadal przoduje ze względu na swoją prostotę, dzięki czemu nawet początkujący mogą go łatwo zainstalować i rozpocząć w pełni funkcjonalne użytkowanie w zaledwie 10 minut.
Preferując rozwiązania minimalistyczne, próbowałem używać FluentBit, narzędzia do przesyłania logów o bardzo małej pamięci, z ClickHouse, starając się unikać używania Kafki. Należy jednak zająć się drobnymi niezgodnościami, takimi jak zanim będzie można to zrobić bez warstwy proxy, która konwertuje dane z FluentBit na ClickHouse.
Jako alternatywę dla Kibany możesz użyć ClickHouse jako backendu . O ile rozumiem, może to powodować problemy z wydajnością podczas renderowania ogromnej liczby punktów danych, szczególnie w przypadku starszych wersji Grafany. W Qwintry jeszcze tego nie próbowaliśmy, ale skargi na ten temat pojawiają się od czasu do czasu na kanale wsparcia ClickHouse w Telegramie.
Zastąpienie Google Big Query i Amazon RedShift (rozwiązanie dla dużych firm)
Idealnym przypadkiem użycia BigQuery jest załadowanie 1 TB danych JSON i wykonanie na nich zapytań analitycznych. Big Query to świetny produkt, którego skalowalność jest trudna do przecenienia. To znacznie bardziej złożone 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 „wycenić”, gdy zaczniesz płacić za każdy SELECT, więc jest to prawdziwe rozwiązanie SaaS ze wszystkimi zaletami i wadami.
ClickHouse to najlepszy wybór, gdy uruchamiasz wiele kosztownych obliczeniowo zapytań. Im więcej zapytań SELECT uruchamiasz każdego dnia, tym bardziej warto zamienić Big Query na ClickHouse, bo taka zamiana pozwoli Ci zaoszczędzić tysiące dolarów, jeśli chodzi o przetwarzanie wielu terabajtów danych. Nie dotyczy to przechowywanych danych, których przetwarzanie w Big Query jest dość tanie.
W artykule Aleksandra Zajcewa, współzałożyciela Altinity opisuje korzyści płynące z takiej migracji DBMS.
Wymiana bazy danych w skali czasu
TimescaleDB to rozszerzenie PostgreSQL, które optymalizuje pracę z szeregami czasowymi w zwykłej bazie danych (, ).
Co prawda ClickHouse nie jest poważnym konkurentem w niszy szeregów czasowych, ale pod względem struktury kolumnowej i wykonywania zapytań wektorowych jest znacznie szybszy niż TimescaleDB w większości przypadków przetwarzania zapytań analitycznych. Jednocześnie wydajność odbioru danych pakietowych ClickHouse jest około 3 razy wyższa, dodatkowo zużywa 20 razy mniej miejsca na dysku, co jest naprawdę ważne przy przetwarzaniu dużych wolumenów danych historycznych: .
W przeciwieństwie do ClickHouse, jedynym sposobem na zaoszczędzenie miejsca na dysku w TimescaleDB jest użycie ZFS lub podobnych systemów plików.
Nadchodzące aktualizacje ClickHouse prawdopodobnie wprowadzą kompresję delta, co sprawi, że będzie jeszcze bardziej odpowiedni do przetwarzania i przechowywania danych szeregów czasowych. TimescaleDB może być lepszym wyborem niż sam 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órych nie chcesz buforować do dużych fragmentów;
- lepsza spójność, jednolitość i wymagania dotyczące ACID;
- obsługa PostGIS;
- scalić z istniejącymi tabelami PostgreSQL, ponieważ Timescale DB to zasadniczo PostgreSQL.
Konkurencja z systemami Hadoop i MapReduce
Hadoop i inne produkty MapReduce mogą wykonywać wiele złożonych obliczeń, ale zwykle działają z dużymi opóźnieniami. ClickHouse rozwiązuje ten problem, przetwarzając terabajty danych i generując wyniki niemal natychmiast. Dzięki temu ClickHouse jest znacznie wydajniejszy w wykonywaniu szybkich, interaktywnych badań analitycznych, które powinny zainteresować data science.
Rywalizacja z Pinotem i Druidem
Najbliższymi konkurentami ClickHouse są kolumny, skalowalne liniowo produkty open source Pinot i Druid. W artykule opublikowano doskonałą pracę porównującą te systemy 1 lutego 2018 r.
Ten artykuł wymaga aktualizacji - jest napisane, że ClickHouse nie obsługuje operacji UPDATE i DELETE, co nie jest do końca prawdą w odniesieniu do najnowszych wersji.
Nie mamy dużego doświadczenia z tymi systemami DBMS, ale nie podoba mi się złożoność podstawowej infrastruktury wymaganej do uruchomienia Druida i Pinot - to cała masa „ruchomych części” otoczonych Javą ze wszystkich stron.
Druid i Pinot to projekty inkubatorów Apache, które są szczegółowo omówione przez Apache na ich stronach projektów GitHub. Pinot pojawił się w inkubatorze w październiku 2018 roku, a Druid urodził się 8 miesięcy wcześniej - w lutym.
Brak informacji o tym, jak działa AFS, nasuwa mi pewne, być może głupie, pytania. Zastanawiam się, czy autorzy Pinot zauważyli, że Fundacja Apache jest bardziej przychylna Druidowi i czy taki stosunek do konkurenta wywołał uczucie zazdrości? Czy rozwój Druida zwolni, a rozwój Pinot przyspieszy, jeśli sponsorzy wspierający tego pierwszego nagle zainteresują się tym drugim?
Wady ClickHouse
Niedojrzałość: Oczywiście jest to wciąż nudna technologia, ale w każdym razie nic takiego nie jest widoczne w innych kolumnowych DBMS.
Małe wkładki nie działają dobrze przy dużej szybkości: wkładki muszą być dzielone na duże porcje, ponieważ wydajność małych wstawek spada proporcjonalnie do liczby kolumn w każdym rzędzie. ClickHouse tak przechowuje dane na dysku - każda kolumna to 1 plik lub więcej, więc aby wstawić 1 wiersz zawierający 100 kolumn, trzeba otworzyć i zapisać co najmniej 100 plików. Dlatego buforowanie wstawiania wymaga pośrednika (chyba że sam klient zapewnia buforowanie) - zwykle Kafka lub jakiś system kolejkowania. Możesz także użyć silnika tabeli Buffer, aby później skopiować duże porcje danych do tabel MergeTree.
Łączenia tabel są ograniczone przez pamięć RAM serwera, ale przynajmniej tam są! Na przykład Druid i Pinot w ogóle nie mają takich połączeń, ponieważ trudno je zaimplementować bezpośrednio w systemach rozproszonych, które nie obsługują przenoszenia dużych porcji danych między węzłami.
odkrycia
W nadchodzących latach planujemy szeroko wykorzystywać ClickHouse w Qwintry, ponieważ ten DBMS zapewnia doskonałą równowagę wydajności, niskich kosztów ogólnych, skalowalności i prostoty. Jestem prawie pewien, że szybko się rozprzestrzeni, gdy społeczność ClickHouse wymyśli więcej sposobów wykorzystania go w małych i średnich instalacjach.
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