Àr ett kolumnbaserat databashanteringssystem för onlineanalysfrÄgor (OLAP) med öppen kÀllkod, utvecklat av Yandex. Det anvÀnds av Yandex, CloudFlare, VK.com, Badoo och andra tjÀnster vÀrlden över för att lagra verkligt stora datamÀngder (insÀttningar av tusentals rader per sekund eller petabyte av data lagrade pÄ disk).
I en vanlig, "radbaserad" databashanterare, exempelvis MySQL, Postgres, MS SQL Server, lagras data i följande ordning:
HÀr lagras vÀrden som tillhör en rad fysiskt nÀra varandra. I kolumnbaserade databashanterare lagras vÀrden frÄn olika kolumner separat, och data frÄn en kolumn lagras tillsammans:
Exempel pÄ kolumnbaserade databashanterare inkluderar Vertica, Paraccel (Actian Matrix, Amazon Redshift), Sybase IQ, Exasol, Infobright, InfiniDB, MonetDB (VectorWise, Actian Vector), LucidDB, SAP HANA, Google Dremel, Google PowerDrill, Druid, kdb+.
Företag â e-post vidarebefordrare började anvĂ€nda Clickhouse 2018 för att skapa rapporter och blev mycket imponerad av dess enkelhet, skalbarhet, SQL-stöd och hastighet. Denna databashanterares hastighet grĂ€nsade till magi.
Enkelhet
Clickhouse installeras pÄ Ubuntu med en enda kommando. Om du kÀnner till SQL kan du omedelbart börja anvÀnda Clickhouse för dina behov. Men det betyder inte att du kan utföra "show create table" i MySQL och kopiera och klistra in SQL i Clickhouse.
JÀmfört med MySQL finns det viktiga skillnader i datatyper i tabellschema ddefinitionerna i denna databashanterare, sÄ för bekvÀm anvÀndning kommer du att behöva lite tid att Àndra definitionerna av tabellscheman och studera tabellmotorer.
Clickhouse fungerar utmÀrkt utan nÄgon ytterligare programvara, men om du vill anvÀnda replikering mÄste du installera ZooKeeper. Prestandaanalysen av frÄgor visar utmÀrkta resultat - systemtabeller innehÄller all information och all data kan hÀmtas med hjÀlp av gammaldags och trÄkig SQL.
Performance
- jÀmförelser av Clickhouse med Vertica och MySQL pÄ en serverkonfiguration: tvÄ socklar IntelŸ XeonŸ CPU E5-2650 v2 @ 2.60GHz; 128 GiB RAM; md RAID-5 pÄ 8 6TB SATA HDD, ext4.
- jÀmförelser av Clickhouse med Amazon RedShift molndatalager.
- Utdrag frÄn Cloudflare-bloggen om Clickhouses prestanda :
ClickHouse-databasen har en mycket enkel design â alla noder i klustret har samma funktionalitet och anvĂ€nder endast ZooKeeper för samordning. Vi byggde ett litet kluster med flera noder och genomförde tester, dĂ€r vi upptĂ€ckte att systemet har en ganska imponerande prestanda som motsvarar de pĂ„stĂ„dda fördelarna i benchmark-tester av analytiska databaser. Vi beslutade oss för att titta nĂ€rmare pĂ„ konceptet bakom ClickHouse. Det första hindret för vĂ„ra studier var avsaknaden av verktyg och det begrĂ€nsade ClickHouse-communityt, sĂ„ vi grĂ€vde djupare in i designen av denna databashanterare för att förstĂ„ hur den fungerar.
ClickHouse stödjer inte direkt mottagning av data frĂ„n Kafka, eftersom det bara Ă€r en databas, sĂ„ vi skrev vĂ„r egen adaptertjĂ€nst i Go. Den lĂ€ste de kodade Capân Proto-meddelanden frĂ„n Kafka, konverterade dem till TSV och infogade dem i ClickHouse i block via HTTP-grĂ€nssnittet. Senare omskrev vi den hĂ€r tjĂ€nsten för att anvĂ€nda Go-biblioteket tillsammans med vĂ„rt eget ClickHouse-grĂ€nssnitt för att förbĂ€ttra prestandan. NĂ€r vi utvĂ€rderade prestandan för paketmottagning upptĂ€ckte vi en viktig sak â det visade sig att ClickHouse-prestandan Ă€r starkt beroende av pakets storlek, det vill sĂ€ga antalet samtidigt infogade rader. För att förstĂ„ varför detta hĂ€nder, studerade vi hur ClickHouse lagrar data.
Den primÀra motorn, eller snarare, familjen av motorer för tabeller som anvÀnds av ClickHouse för att lagra data Àr MergeTree. Denna motor Àr konceptuellt lik LSM-algoritmen som anvÀnds i Google BigTable eller Apache Cassandra, men undviker att bygga en mellanliggande minnestabell och skriver data direkt till disken. Detta ger den utmÀrkt skrivbandbredd, eftersom varje infogat paket sorteras endast efter "primÀrnyckeln" primary key, komprimeras och skrivs till disken för att bilda ett segment.
Avsaknaden av minnestabeller eller nĂ„got begrepp om "fĂ€rskhet" av data innebĂ€r ocksĂ„ att de endast kan lĂ€ggas till, medan systemet inte stöder Ă€ndring eller borttagning. Idag Ă€r det enda sĂ€ttet att ta bort data att ta bort dem mĂ„nadsvis, eftersom segment aldrig korsar mĂ„nadens grĂ€ns. ClickHouse-teamet arbetar aktivt med att göra denna funktion konfigurerbar. Ă
andra sidan gör detta skrivning och sammanslagning av segment konfliktfritt, vilket gör att bandbredden för insamling skalar linjÀrt med antalet parallella insÀttningar, sÄ lÀnge det inte sker mÀttnad av I/O eller kÀrnor.
Men denna omstÀndighet innebÀr ocksÄ att systemet inte Àr lÀmpat för smÄ paket, sÄ Kafka-tjÀnster och insÀttare anvÀnds för buffring. Dessutom fortsÀtter ClickHouse konstant att utföra sammanslagning av segment i bakgrunden, sÄ att mÄnga smÄ delar av information kommer att slÄs samman och skrivas flera gÄnger, vilket ökar intensiteten i skrivningen. Samtidigt kan för mÄnga osammanhÀngande delar leda till aggressiv dÀmpning av insÀttningar sÄ lÀnge sammanslagningen pÄgÄr. Vi har upptÀckt att den bÀsta kompromissen mellan realtidsdata och prestanda för mottagning Àr att ta emot ett begrÀnsat antal insÀttningar per sekund i tabellen.
Nyckeln till lÀsprestanda för tabeller Àr indexering och datas placering pÄ disken. Oavsett hur snabbt bearbetningen Àr, nÀr motorn behöver skanna terabyte av data pÄ disken och anvÀnda endast en del av dem, kommer det att ta tid. ClickHouse Àr ett kolumnar datalager, sÄ varje segment innehÄller en fil för varje kolumn med sorterade vÀrden för varje rad. DÀrför kan hela kolumner som inte ingÄr i frÄgan först hoppas över och sedan kan flera celler bearbetas parallellt med vektoriserad exekvering. För att undvika fullstÀndig skanning har varje segment en liten indexfil.
Med tanke pÄ att alla kolumner Àr sorterade efter "primÀrnyckeln", innehÄller indexfilen endast etiketter (fÄngade rader) av varje N:e rad för att kunna lagra dem i minnet Àven för mycket stora tabeller. Till exempel kan standardinstÀllningen "markera var 8192:e rad" stÀllas in, dÄ kommer "fattig" indexering av en tabell med 1 biljon rader, som enkelt fÄr plats i minnet, att ta endast 122 070 tecken.
Utveckling av systemet
Utvecklingen och förbÀttringen av Clickhouse kan spÄras pÄ och man kan se att "tillvÀxtprocessen" sker i imponerande takt.
Popularitet
Det verkar som om populariteten för Clickhouse vÀxer exponentiellt, sÀrskilt inom den rysktalande gemenskapen. Förra Ärets konferens High Load 2018 (Moskva, 8-9 november 2018) visade att monster som vk.com och Badoo anvÀnder Clickhouse, med hjÀlp av vilken de matar in data (till exempel loggar) frÄn tiotusentals servrar samtidigt. I en 40-minuters video . Snart kommer vi att publicera transkriptionen pÄ Habr för att underlÀtta arbetet med materialet.
AnvÀndningsomrÄden
Efter att ha lagt ner lite tid pÄ undersökningar tror jag att det finns omrÄden dÀr ClickHouse kan vara anvÀndbart eller kan helt ersÀtta andra, mer traditionella och populÀra lösningar som MySQL, PostgreSQL, ELK, Google Big Query, Amazon RedShift, TimescaleDB, Hadoop, MapReduce, Pinot och Druid. Nedan följer detaljer om anvÀndning av ClickHouse för att modernisera eller helt ersÀtta ovanstÄende databashanterare.
Utökning av MySQL och PostgreSQL
För inte sÄ lÀnge sedan delvis ersatte vi MySQL med ClickHouse för plattformen för nyhetsbrev Problemet var att MySQL pÄ grund av en dÄligt genomtÀnkt design registrerade varje skickat mejl och varje lÀnk i detta mejl med en base64-hash, vilket skapade en enorm MySQL-tabell (email_stats). Efter att ha skickat ut 10 miljoner mejl till abonnenterna upptog denna tabell 150 GB diskutrymme, och MySQL började "sakta ner" vid enkla förfrÄgningar. För att ÄtgÀrda problemet med diskutrymmet anvÀnde vi framgÄngsrikt InnoDB-tabellkomprimering, vilket minskade storleken med fyra gÄnger. Men det Àr fortfarande meningslöst att lagra mer Àn 20-30 miljoner e-postmeddelanden i MySQL endast för att lÀsa historik, eftersom varje enkel förfrÄgan som av nÄgon anledning mÄste göra en fullstÀndig genomsökning leder till swap och en stor belastning pÄ I/O, vilket vi regelbundet fick varningar om frÄn Zabbix.
Clickhouse anvÀnder tvÄ komprimeringsalgoritmer som minskar datamÀngden med ungefÀr , men i detta specifika fall var datan sÀrskilt "komprimerbar".
ErsÀttning av ELK
Enligt egen erfarenhet krÀver ELK-stacken (ElasticSearch, Logstash och Kibana, i detta specifika fall ElasticSearch) mycket mer resurser för att köra Àn vad som verkligen behövs för att lagra loggar. ElasticSearch Àr en utmÀrkt motor om du behöver bra fulltextsökning i loggar (och jag tror inte att du verkligen behöver det), men jag undrar varför det de facto har blivit standardmotorn för loggning. Dess abonnemangsbandbredd tillsammans med Logstash skapade problem för oss Àven vid ganska smÄ belastningar och krÀvde att vi la till allt mer RAM och diskutrymme. Som databas Àr Clickhouse bÀttre Àn ElasticSearch av följande skÀl:
- Stöd för SQL-dialekt;
- BÀttre komprimeringsgrad för lagrad data;
- Stöd för regex-sökning istÀllet för fulltextsökning;
- FörbÀttrad förfrÄgningsplanering och högre total prestanda.
För nÀrvarande Àr det största problemet som uppstÄr vid jÀmförelse av ClickHouse med ELK bristen pÄ lösningar för loggutdelning, samt bristen pÄ dokumentation och utbildningsmaterial om Àmnet. Samtidigt kan varje anvÀndare stÀlla in ELK med hjÀlp av Digital Oceans guide, vilket Àr mycket viktigt för snabb implementering av sÄdana teknologier. HÀr finns en databasmotor, men Àn sÄ lÀnge finns det ingen Filebeat för ClickHouse. Ja, det finns och systemet för att arbeta med loggar , finns det ett verktyg för att föra in loggfilers data i ClickHouse, men allt detta tar mer tid. Men ClickHouse Àr trots allt ledande pÄ grund av sin enkelhet, sÄ Àven nybörjare kan enkelt installera det och börja anvÀnda det fullt ut bokstavligen inom 10 minuter.
Genom att föredra minimalistiska lösningar försökte jag anvÀnda FluentBit, ett verktyg för att exportera loggar med mycket lÄg minnesanvÀndning, tillsammans med ClickHouse, och försökte undvika att anvÀnda Kafka. Men det behövs ÄtgÀrdas vissa mindre kompatibilitetsproblem, som , innan detta kan göras utan ett proxy-lager som konverterar data frÄn FluentBit till ClickHouse.
Som alternativ till Kibana kan ClickHouse anvÀndas som backend . SÄvitt jag förstÄr kan det uppstÄ prestandaproblem vid rendering av stora datamÀngder, sÀrskilt med Àldre versioner av Grafana. Vi har Ànnu inte provat detta pÄ Qwintry, men klagomÄl om detta dyker tidsenligt upp pÄ ClickHouse-supportkanalen i Telegram.
ErsÀttning för Google Big Query och Amazon RedShift (lösning för stora företag)
Den perfekta anvÀndningen av BigQuery Àr att ladda upp 1 TB JSON-data och utföra analytiska frÄgor pÄ dem. BigQuery Àr en fantastisk produkt vars skalbarhet Àr svÄr att överskatta. Det Àr mycket mer komplex mjukvara Àn ClickHouse, som körs pÄ intern kluster, men ur kundens perspektiv har det mycket gemensamt med ClickHouse. BigQuery kan snabbt "bli dyrt" sÄ snart du börjar betala per SELECT, sÄ det Àr en verklig SaaS-lösning med alla dess fördelar och nackdelar.
ClickHouse Àr det bÀsta valet om du kör mÄnga resurskrÀvande frÄgor. Ju fler SELECT-frÄgor du kör varje dag, desto mer meningsfullt Àr det att byta ut BigQuery mot ClickHouse, eftersom en sÄdan byte kan spara dig tusentals dollar nÀr det gÀller mÄnga terabyte av bearbetade data. Detta gÀller inte för lagrad data, vars bearbetning i BigQuery Àr ganska billig.
I artikeln av Altinities medgrundare Alexander Zaitsev beskrivs fördelarna med en sÄdan databasövergÄng.
ErsÀttning för TimescaleDB
TimescaleDB Àr en utvidgning av PostgreSQL som optimerar arbetet med tidsserier i en vanlig databas, ).
Ăven om ClickHouse inte Ă€r en seriös konkurrent inom tidsserieomrĂ„det, Ă€r det mycket snabbare Ă€n TimescaleDB för de flesta analytiska förfrĂ„gningar tack vare sin kolumnstruktur och vektoriserade frĂ„geexekvering. Dessutom Ă€r ClickHouse:s prestanda för att ta emot batchdata cirka tre gĂ„nger bĂ€ttre, och den anvĂ€nder dessutom 20 gĂ„nger mindre lagringsutrymme, vilket Ă€r avgörande för hantering av stora mĂ€ngder historiska data:.
Till skillnad frÄn ClickHouse Àr det enda sÀttet att spara lite lagringsutrymme i TimescaleDB att anvÀnda ZFS eller liknande filsystem.
Framtida uppdateringar av ClickHouse kommer förmodligen att införa delta-kompression som gör det Ànnu mer lÀmpligt för att hantera och lagra tidsseriedata. TimescaleDB kan vara det bÀttre valet Àn "rena" ClickHouse i följande fall:
- smÄ installationer med mycket lite RAM (<3 GB);
- ett stort antal smÄ INSERT-operationer som du inte vill buffra i stora block;
- bÀttre konsekvens, enhetlighet och ACID-krav;
- stöd för PostGIS;
- integration med befintliga PostgreSQL-tabeller, eftersom TimescaleDB i huvudsak Àr PostgreSQL.
Konkurrens med Hadoop och MapReduce
Hadoop och andra MapReduce-produkter kan utföra mÄnga komplexa berÀkningar, men de verkar vanligtvis med enorma fördröjningar. ClickHouse löser detta problem genom att bearbeta terabyte av data och nÀstan omedelbart producera resultat. DÀrför Àr ClickHouse mycket effektivare för att utföra snabb, interaktiv analytisk forskning, vilket bör intressera databehandlingsspecialister.
Konkurrens med Pinot och Druid
De nÀrmaste konkurrenterna till ClickHouse Àr kolumnar linjÀrt skalbara open source-produkter som Pinot och Druid. UtmÀrkt arbete med att jÀmföra dessa system publicerades i artikeln den 1 februari 2018.
Denna artikel behöver uppdateras â den pĂ„stĂ„r att ClickHouse inte stöder UPDATE och DELETE-operationer, vilket inte Ă€r helt korrekt i förhĂ„llande till de senaste versionerna.
Vi har inte tillrĂ€cklig erfarenhet av att arbeta med dessa databashanteringssystem, men jag gillar verkligen inte komplexiteten hos den infrastruktur som krĂ€vs för att köra Druid och Pinot â det Ă€r en hel del "rörliga delar" omgiven av Java frĂ„n alla hĂ„ll.
Druid och Pinot Ă€r inkubatorprojekt inom Apache, vars utvecklingsförlopp detaljerat belyses av Apache pĂ„ sina GitHub-projekt. Pinot debuterade i inkubatorn i oktober 2018, medan Druid föddes Ă„tta mĂ„nader tidigare â i februari.
Bristen pÄ information om hur AFS fungerar vÀcker nÄgra, och kanske fÄniga, frÄgor hos mig. Jag undrar om författarna till Pinot har mÀrkt att Apache Foundation Àr mer gynnsam mot Druid, och om denna instÀllning till konkurrenten har orsakat nÄgon form av avundsjuka? Kommer Druid att bromsa sin utveckling medan Pinot snabbt gÄr framÄt, om sponsorerna som stödjer den förra plötsligt blir intresserade av den senare?
Nackdelar med ClickHouse
Omoget: det Àr uppenbart att det fortfarande Àr en fascinerande teknik, men det finns ÀndÄ ingenting liknande i andra kolumnbaserade databashanteringssystem.
SmĂ„ insĂ€ttningar fungerar dĂ„ligt med hög hastighet: insĂ€ttningar mĂ„ste delas upp i större bitar, eftersom prestandan för smĂ„ insĂ€ttningar minskar i proportion till antalet kolumner i varje rad. SĂ„ hĂ€r lagras data i ClickHouse pĂ„ disken â varje kolumn motsvarar en eller flera filer, sĂ„ för att infoga en rad som innehĂ„ller 100 kolumner mĂ„ste minst 100 filer öppnas och skrivas. DĂ€rför krĂ€vs en medlare för att buffra insĂ€ttningar (om inte sjĂ€lva klienten tillhandahĂ„ller buffring) â vanligtvis Ă€r det Kafka eller nĂ„got köhanteringssystem. Man kan ocksĂ„ anvĂ€nda Buffer table-motorn för att senare kopiera stora datasegment till MergeTree-tabeller.
Tabellanslutningar begrÀnsas av serverns arbetsminne, men Ätminstone finns de dÀr! Till exempel finns det inga sÄdana anslutningar i Druid och Pinot, eftersom de Àr svÄra att implementera direkt i distribuerade system som inte stödjer överföring av stora datamÀngder mellan noder.
Slutsatser
Under de kommande Ären planerar vi att anvÀnda ClickHouse i Qwintry i stor utstrÀckning, eftersom denna databas ger en utmÀrkt balans mellan prestanda, lÄga overheadkostnader, skalbarhet och enkelhet. Jag Àr nÀstan sÀker pÄ att den kommer att börja spridas snabbt sÄ snart ClickHouse-gemenskapen hittar fler sÀtt att anvÀnda den i smÄ och medelstora installationer.
Lite reklam đ
Tack för att ni stannar kvar hos oss. Gillar ni vÄra artiklar? Vill ni se fler intressanta material? Stöd oss genom att göra en bestÀllning eller rekommendera oss till era vÀnner, , en unik motsvarighet till entry-level servrar som vi har skapat för er: (alternativ med RAID1 och RAID10 finns tillgÀngliga, upp till 24 kÀrnor och upp till 40GB DDR4).
Dell R730xd Ă€r tvĂ„ gĂ„nger billigare i datacentret Equinix Tier IV i Amsterdam? Bara hos oss i NederlĂ€nderna! Dell R420 â 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB â frĂ„n $99! LĂ€s om
KĂ€lla: habr.com
