je open-source systém pro správu sloupcových databází pro online analytické zpracování dotazů (OLAP) vytvořený společností Yandex. Používají jej Yandex, CloudFlare, VK.com, Badoo a další služby po celém světě k ukládání opravdu velkého množství dat (vkládání tisíců řádků za vteřinu nebo petabajtů dat uložených na disku).
V normálním "řetězcovém" DBMS, jehož příklady jsou MySQL, Postgres, MS SQL Server, jsou data uložena v tomto pořadí:
V tomto případě jsou hodnoty týkající se jednoho řádku fyzicky uloženy vedle sebe. Ve sloupcovém DBMS jsou hodnoty z různých sloupců uloženy samostatně a data jednoho sloupce jsou uložena společně:
Příklady sloupcových DBMS jsou Vertica, Paraccel (Actian Matrix, Amazon Redshift), Sybase IQ, Exasol, Infobright, InfiniDB, MonetDB (VectorWise, Actian Vector), LucidDB, SAP HANA, Google Dremel, Google PowerDrill, Druid, kdb+.
Společnost je zasílatel pošty Clickhouse jsem začal používat pro vytváření sestav v roce 2018 a velmi mě zaujala jeho jednoduchost, škálovatelnost, podpora SQL a rychlost. Rychlost tohoto DBMS hraničila s magií.
Jednoduchost
Clickhouse se na Ubuntu nainstaluje jediným příkazem. Pokud znáte SQL, můžete okamžitě začít používat Clickhouse pro své potřeby. To však neznamená, že můžete v MySQL „ukázat vytvořit tabulku“ a v Clickhouse zkopírovat a vložit SQL.
Ve srovnání s MySQL jsou v tomto DBMS důležité rozdíly v datových typech v definicích schématu tabulek, takže na změnu definic schémat tabulek a naučení se tabulkových enginů potřebujete ještě nějaký čas.
Clickhouse funguje skvěle bez dalšího softwaru, ale pokud chcete používat replikaci, budete si muset nainstalovat ZooKeeper. Analýza výkonu dotazů ukazuje vynikající výsledky - systémové tabulky obsahují všechny informace a všechna data lze získat pomocí starého a nudného SQL.
Производительность
- Srovnání Clickhouse versus Vertica a MySQL na konfiguračním serveru: dvě patice Intel® Xeon® CPU E5-2650 v2 @ 2.60 GHz; 128 GiB RAM; md RAID-5 na 8 6TB SATA HDD, ext4.
- srovnání Clickhouse s cloudovým úložištěm Amazon RedShift.
- Výňatky z blogu :
Databáze ClickHouse má velmi jednoduchý design – všechny uzly v clusteru mají stejnou funkcionalitu a ke koordinaci využívají pouze ZooKeeper. Postavili jsme malý cluster několika uzlů a provedli testování, během kterého jsme zjistili, že systém má docela působivý výkon, který odpovídá proklamovaným výhodám v analytických DBMS benchmarcích. Rozhodli jsme se blíže podívat na koncept ClickHouse. První překážkou výzkumu byl nedostatek nástrojů a malá komunita ClickHouse, takže jsme se ponořili do návrhu tohoto DBMS, abychom pochopili, jak funguje.
ClickHouse nepodporuje příjem dat přímo z Kafky, protože se jedná pouze o databázi, proto jsme v Go napsali vlastní službu adaptéru. Četl zakódované zprávy od Kafky Cap'n Proto, převáděl je do TSV a vkládal je do ClickHouse v dávkách přes rozhraní HTTP. Později jsme tuto službu přepsali, abychom používali knihovnu Go ve spojení s naším vlastním rozhraním ClickHouse, abychom zlepšili výkon. Při vyhodnocování výkonu příjmu paketů jsme zjistili důležitou věc – ukázalo se, že u ClickHouse tento výkon silně závisí na velikosti paketu, tedy na počtu současně vložených řádků. Abychom pochopili, proč k tomu dochází, studovali jsme, jak ClickHouse ukládá data.
Hlavním motorem, nebo spíše rodinou tabulkových motorů, které ClickHouse používá pro ukládání dat, je MergeTree. Tento engine je koncepčně podobný algoritmu LSM používanému v Google BigTable nebo Apache Cassandra, ale vyhýbá se vytváření mezipaměťové tabulky a zapisuje data přímo na disk. To mu dává vynikající propustnost zápisu, protože každý vložený paket je pouze tříděn podle primárního klíče „primárního klíče“, komprimován a zapsán na disk, aby vytvořil segment.
Absence paměťové tabulky nebo jakýkoli koncept „čerstvosti“ dat také znamená, že je lze pouze přidávat, systém nepodporuje změnu ani mazání. Od dnešního dne je jediným způsobem, jak smazat data, smazat je podle kalendářního měsíce, protože segmenty nikdy nepřekročí hranici měsíce. Tým ClickHouse aktivně pracuje na tom, aby byla tato funkce přizpůsobitelná. Na druhou stranu umožňuje zápis a slučování segmentů bez sporů, takže přijímejte propustnost lineárně s počtem paralelních vložek, dokud se I/O nebo jádra nenasytí.
Tato okolnost však také znamená, že systém není vhodný pro malé pakety, proto se pro ukládání do vyrovnávací paměti používají služby Kafka a vkladače. ClickHouse na pozadí dále nepřetržitě slučuje segmenty, takže mnoho malých informací bude kombinováno a zaznamenáno vícekrát, čímž se zvýší intenzita záznamu. Příliš mnoho nesouvisejících částí však způsobí agresivní škrcení břitových destiček, dokud bude sloučení pokračovat. Zjistili jsme, že nejlepším kompromisem mezi přijímáním dat v reálném čase a výkonem zpracování je přijmout do tabulky omezený počet vložení za sekundu.
Klíčem k výkonu čtení tabulky je indexování a umístění dat na disku. Bez ohledu na to, jak rychlé je zpracování, když engine potřebuje skenovat terabajty dat z disku a použít jen zlomek z nich, bude to chvíli trvat. ClickHouse je úložiště sloupců, takže každý segment obsahuje soubor pro každý sloupec (sloupec) s seřazenými hodnotami pro každý řádek. Celé sloupce, které se v dotazu nenacházejí, lze tedy nejprve přeskočit a poté lze paralelně s vektorizovaným prováděním zpracovat více buněk. Aby se zabránilo úplnému skenování, má každý segment malý indexový soubor.
Vzhledem k tomu, že všechny sloupce jsou seřazeny podle "primárního klíče", indexový soubor obsahuje pouze popisky (zachycené řádky) každého N-tého řádku, aby bylo možné je uchovat v paměti i pro velmi rozsáhlé tabulky. Můžete například nastavit výchozí nastavení na „označit každý 8192. řádek“ a poté na „skrovné“ indexování tabulky s 1 bilionem. řádky, které se snadno vejdou do paměti, by zabraly pouze 122 070 znaků.
Vývoj systému
Vývoj a zlepšování Clickhouse lze vysledovat a ujistěte se, že proces „dospívání“ probíhá působivým tempem.
Popularita
Zdá se, že popularita Clickhouse roste exponenciálně, zejména v rusky mluvící komunitě. Loňská konference High load 2018 (Moskva, 8. – 9. listopadu 2018) ukázala, že monstra jako vk.com a Badoo používají Clickhouse, který vkládá data (například logy) z desítek tisíc serverů současně. Ve 40minutovém videu . Brzy přepis zveřejníme na Habrovi pro usnadnění práce s materiálem.
Aplikace
Poté, co jsem strávil nějaký čas zkoumáním, myslím, že existují oblasti, kde může být ClickHouse užitečný nebo schopný zcela nahradit jiná tradičnější a populární řešení, jako jsou MySQL, PostgreSQL, ELK, Google Big Query, Amazon RedShift, TimescaleDB, Hadoop, MapReduce, Pinot a Druid. Níže jsou uvedeny podrobnosti o použití ClickHouse k upgradu nebo úplnému nahrazení výše uvedeného DBMS.
Rozšíření MySQL a PostgreSQL
Nedávno jsme částečně nahradili MySQL za ClickHouse pro platformu newsletterů . Problém byl v tom, že MySQL kvůli nedomyšlenému designu zaprotokolovalo každý odeslaný e-mail a každý odkaz v tomto e-mailu pomocí hash base64, čímž vznikla obrovská tabulka MySQL (email_stats). Po odeslání pouhých 10 milionů e-mailů předplatitelům služby tato tabulka zabírala 150 GB souborového prostoru a MySQL začalo „blbnout“ na jednoduché dotazy. K vyřešení problému s prostorem v souboru jsme úspěšně použili kompresi tabulky InnoDB, která jej snížila faktorem 4. Stále však nemá smysl ukládat více než 20-30 milionů e-mailů v MySQL jen kvůli historii čtení, protože jakýkoli jednoduchý dotaz, který z nějakého důvodu musí provést úplné skenování, má za následek swap a těžké I/O režii, na což jsme pravidelně dostávali varování Zabbixe.
Clickhouse používá dva kompresní algoritmy, které snižují množství dat přibližně , ale v tomto konkrétním případě byla data obzvláště "stlačitelná".
Výměna ELK
Na základě mých vlastních zkušeností vyžaduje zásobník ELK (ElasticSearch, Logstash a Kibana, v tomto konkrétním případě ElasticSearch) mnohem více zdrojů, než je potřeba pro ukládání protokolů. ElasticSearch je skvělý nástroj, pokud chcete dobré fulltextové prohledávání protokolů (což si myslím, že ve skutečnosti nepotřebujete), ale zajímalo by mě, proč se stal de facto standardním protokolem. Jeho výkon při přijímání v kombinaci s Logstash nám dělal problémy i při poměrně nízké zátěži a vyžadoval přidávání stále větší paměti RAM a místa na disku. Jako databáze je Clickhouse lepší než ElasticSearch z následujících důvodů:
- podpora dialektů SQL;
- Nejlepší stupeň komprese uložených dat;
- Podpora pro vyhledávání Regex namísto fulltextového vyhledávání;
- Vylepšené plánování dotazů a lepší celkový výkon.
Aktuálně největším problémem, který vyvstává při porovnávání ClickHouse s ELK, je chybějící řešení pro nahrávání logů a také chybějící dokumentace a tutoriály na toto téma. Každý uživatel si přitom může nastavit ELK pomocí manuálu Digital Ocean, který je velmi důležitý pro rychlé zavedení takových technologií. Existuje zde databázový stroj, ale zatím neexistuje žádný Filebeat pro ClickHouse. Ano, tam je a systém pro práci s logy , existuje nástroj zadat data souboru protokolu do ClickHouse, ale to vše zabere více času. ClickHouse však stále vede svou jednoduchostí, takže jej snadno nainstalují i začátečníci a za pouhých 10 minut začnou plně funkční používat.
Preferoval jsem minimalistická řešení a pokusil jsem se použít FluentBit, nástroj pro nahrávání protokolu s velmi nízkou pamětí, s ClickHouse a zároveň jsem se snažil vyhnout se používání Kafka. Je však potřeba řešit drobné nekompatibility, jako např než to bude možné provést bez proxy vrstvy, která převádí data z FluentBit do ClickHouse.
Jako alternativu k Kibana můžete jako backend použít ClickHouse . Pokud jsem pochopil, může to způsobit problémy s výkonem při vykreslování velkého počtu datových bodů, zejména u starších verzí Grafany. V Qwintry jsme to ještě nezkoušeli, ale na kanálu podpory ClickHouse v Telegramu se čas od času objevují stížnosti.
Nahrazení Google Big Query a Amazon RedShift (řešení pro velké společnosti)
Ideálním případem použití pro BigQuery je načíst 1 TB dat JSON a spustit na nich analytické dotazy. Big Query je skvělý produkt, jehož škálovatelnost je těžké přeceňovat. Jedná se o mnohem složitější software než ClickHouse běžící na interním clusteru, ale z pohledu klienta má s ClickHouse mnoho společného. BigQuery se může rychle „zdražit“, jakmile začnete platit za každý SELECT, takže jde o skutečné řešení SaaS se všemi jeho klady a zápory.
ClickHouse je nejlepší volbou, když spouštíte spoustu výpočetně drahých dotazů. Čím více dotazů SELECT spouštíte každý den, tím větší smysl má nahradit Big Query ClickHouse, protože taková náhrada vám ušetří tisíce dolarů, pokud jde o zpracování mnoha terabajtů dat. To se netýká uložených dat, jejichž zpracování v Big Query je poměrně levné.
V článku Alexandra Zaitseva, spoluzakladatele Altinity popisuje výhody takové migrace DBMS.
TimescaleDB Výměna
TimescaleDB je rozšíření PostgreSQL, které optimalizuje práci s časovými řadami v běžné databázi (, ).
ClickHouse sice není vážným konkurentem ve výklenku časových řad, ale pokud jde o sloupcovou strukturu a provádění vektorových dotazů, je ve většině případů zpracování analytických dotazů mnohem rychlejší než TimescaleDB. Výkon příjmu paketových dat ClickHouse je přitom zhruba 3x vyšší, navíc využívá 20x méně místa na disku, což je pro zpracování velkých objemů historických dat opravdu důležité: .
Na rozdíl od ClickHouse je jediným způsobem, jak ušetřit místo na disku v TimescaleDB, použití ZFS nebo podobných souborových systémů.
Nadcházející aktualizace ClickHouse pravděpodobně zavedou delta kompresi, díky čemuž bude ještě vhodnější pro zpracování a ukládání dat časových řad. TimescaleDB může být lepší volbou než holý ClickHouse v následujících případech:
- malé instalace s velmi malou pamětí RAM (<3 GB);
- velký počet malých INSERTů, které nechcete ukládat do vyrovnávací paměti do velkých fragmentů;
- lepší konzistence, jednotnost a požadavky na ACID;
- podpora PostGIS;
- sloučit se stávajícími tabulkami PostgreSQL, protože Timescale DB je v podstatě PostgreSQL.
Konkurence se systémy Hadoop a MapReduce
Hadoop a další produkty MapReduce mohou provádět mnoho složitých výpočtů, ale mají tendenci běžet s obrovskou latencí. ClickHouse řeší tento problém zpracováním terabajtů dat a produkováním výsledků téměř okamžitě. ClickHouse je tedy mnohem efektivnější pro provádění rychlého, interaktivního analytického výzkumu, který by měl zajímat datové vědce.
Soutěž s Pinotem a Druidem
Nejbližšími konkurenty ClickHouse jsou sloupcové, lineárně škálovatelné open source produkty Pinot a Druid. Výborná práce srovnání těchto systémů je zveřejněna v článku 1. února 2018
Tento článek je potřeba aktualizovat – píše se v něm, že ClickHouse nepodporuje operace UPDATE a DELETE, což ve vztahu k nejnovějším verzím není úplně pravda.
S těmito DBMS nemáme moc zkušeností, ale nelíbí se mi složitost základní infrastruktury, která je ke spuštění Druid a Pinot potřeba – je to celá hromada „pohyblivých částí“ obklopených Javou ze všech stran.
Druid a Pinot jsou projekty inkubátorů Apache, kterým se Apache podrobně věnuje na jejich stránkách projektu GitHub. Pinot se v inkubátoru objevil v říjnu 2018 a Druid se narodil o 8 měsíců dříve - v únoru.
Nedostatek informací o tom, jak AFS funguje, ve mně vyvolává některé a možná hloupé otázky. Zajímalo by mě, jestli si autoři Pinotu všimli, že nadace Apache je více nakloněna Druidovi a vyvolal takový postoj ke konkurenci pocit závisti? Zpomalí se vývoj Druida a zrychlí se vývoj Pinotu, pokud se sponzoři podporující to první najednou začnou zajímat o to druhé?
Nevýhody ClickHouse
Nezralost: Je zřejmé, že je to stále nudná technologie, ale v žádném případě se nic takového v jiných sloupcových DBMS nevidí.
Malé břitové destičky nefungují dobře při vysoké rychlosti: břitové destičky je nutné rozdělit na velké kusy, protože výkon malých břitových destiček klesá úměrně počtu sloupců v každém řádku. Takto ClickHouse ukládá data na disk – každý sloupec znamená 1 soubor nebo více, takže pro vložení 1 řádku obsahujícího 100 sloupců je potřeba otevřít a zapsat alespoň 100 souborů. To je důvod, proč ukládání do vyrovnávací paměti vložení vyžaduje prostředníka (pokud samotný klient neposkytuje ukládání do vyrovnávací paměti) - obvykle Kafka nebo nějaký druh systému řazení do fronty. K pozdějšímu kopírování velkých částí dat do tabulek MergeTree můžete také použít tabulkový modul Buffer.
Spojení tabulek jsou omezena RAM serveru, ale alespoň tam jsou! Například Druid a Pinot taková spojení vůbec nemají, protože je obtížné je přímo implementovat v distribuovaných systémech, které nepodporují přesun velkých kusů dat mezi uzly.
Závěry
V nadcházejících letech plánujeme rozsáhlé využití ClickHouse v Qwintry, protože tento DBMS poskytuje vynikající rovnováhu mezi výkonem, nízkou režií, škálovatelností a jednoduchostí. Jsem si docela jistý, že se to rychle rozšíří, jakmile komunita ClickHouse přijde s více způsoby, jak to použít v malých a středních instalacích.
Nějaké inzeráty 🙂
Děkujeme, že s námi zůstáváte. Líbí se vám naše články? Chcete vidět více zajímavého obsahu? Podpořte nás objednávkou nebo doporučením přátelům, , jedinečný analog serverů základní úrovně, který jsme pro vás vymysleli: (k dispozici s RAID1 a RAID10, až 24 jader a až 40 GB DDR4).
Dell R730xd 2krát levnější v datovém centru Equinix Tier IV v Amsterdamu? Pouze zde V Nizozemsku! Dell R420 – 2x E5-2430 2.2 GHz 6C 128 GB DDR3 2 x 960 GB SSD 1 Gb/s 100 TB – od 99 $! Číst o
Zdroj: www.habr.com