er et åpen kildekode kolonnebasert databasebehandlingssystem for online analytisk spørringsbehandling (OLAP) laget av Yandex. Den brukes av Yandex, CloudFlare, VK.com, Badoo og andre tjenester over hele verden for å lagre virkelig store datamengder (innsetting av tusenvis av rader per sekund eller petabyte med data lagret på disk).
I en vanlig "streng" DBMS, eksempler på disse er MySQL, Postgres, MS SQL Server, lagres data i denne rekkefølgen:
I dette tilfellet lagres verdiene knyttet til en rad fysisk side ved side. I kolonneformet DBMS lagres verdier fra forskjellige kolonner separat, og dataene til en kolonne lagres sammen:
Eksempler på kolonneformede DBMS-er er Vertica, Paraccel (Actian Matrix, Amazon Redshift), Sybase IQ, Exasol, Infobright, InfiniDB, MonetDB (VectorWise, Actian Vector), LucidDB, SAP HANA, Google Dremel, Google PowerDrill, Druid, kdb+.
Selskapet er postformidler Jeg begynte å bruke Clickhouse i 2018 for rapportering og var veldig imponert over dens enkelhet, skalerbarhet, SQL-støtte og hastighet. Hastigheten til dette DBMS grenset til magi.
lette
Clickhouse installeres på Ubuntu med en enkelt kommando. Hvis du kan SQL, kan du umiddelbart begynne å bruke Clickhouse for dine behov. Dette betyr imidlertid ikke at du kan "vise opprette tabell" i MySQL og kopiere og lime inn SQL i Clickhouse.
Sammenlignet med MySQL er det viktige datatypeforskjeller i tabellskjemadefinisjonene i dette DBMS, så du trenger fortsatt litt tid til å endre tabellskjemadefinisjonene og lære tabellmotorene for å bli komfortabel.
Clickhouse fungerer utmerket uten ekstra programvare, men hvis du vil bruke replikering, må du installere ZooKeeper. Analyse av spørringsytelse viser utmerkede resultater - systemtabellene inneholder all informasjon, og all data kan hentes ved hjelp av gammel og kjedelig SQL.
Производительность
- Clickhouse versus Vertica og MySQL sammenligninger på konfigurasjonsserver: to sokler Intel® Xeon® CPU E5-2650 v2 @ 2.60GHz; 128 GiB RAM; md RAID-5 på 8 6TB SATA HDD, ext4.
- sammenligning av Clickhouse med Amazon RedShift skylagring.
- Bloggutdrag :
ClickHouse-databasen har en veldig enkel design - alle noder i klyngen har samme funksjonalitet og bruker kun ZooKeeper for koordinering. Vi bygde en liten klynge med flere noder og utførte testing, hvor vi fant ut at systemet har ganske imponerende ytelse, som tilsvarer de påståtte fordelene i analytiske DBMS-benchmarks. Vi bestemte oss for å se nærmere på konseptet bak ClickHouse. Den første hindringen for forskning var mangelen på verktøy og det lille fellesskapet til ClickHouse, så vi fordypet oss i utformingen av dette DBMS for å forstå hvordan det fungerer.
ClickHouse støtter ikke mottak av data direkte fra Kafka, da det kun er en database, så vi skrev vår egen adaptertjeneste i Go. Den leste Cap'n Proto-kodede meldinger fra Kafka, konverterte dem til TSV og satte dem inn i ClickHouse i grupper via HTTP-grensesnittet. Vi skrev senere om denne tjenesten for å bruke Go-biblioteket sammen med vårt eget ClickHouse-grensesnitt for å forbedre ytelsen. Da vi evaluerte ytelsen til å motta pakker, oppdaget vi en viktig ting - det viste seg at for ClickHouse avhenger denne ytelsen sterkt av størrelsen på pakken, det vil si antall rader som er satt inn samtidig. For å forstå hvorfor dette skjer, studerte vi hvordan ClickHouse lagrer data.
Hovedmotoren, eller rettere sagt, en familie av tabellmotorer som brukes av ClickHouse for lagring av data, er MergeTree. Denne motoren ligner konseptuelt på LSM-algoritmen som brukes i Google BigTable eller Apache Cassandra, men unngår å bygge en mellomliggende minnetabell og skriver data direkte til disk. Dette gir den utmerket skrivegjennomstrømning, ettersom hver innsatt pakke bare sorteres etter primærnøkkelen "primærnøkkel", komprimert og skrevet til disk for å danne et segment.
Fraværet av en minnetabell eller et konsept for "friskhet" av data betyr også at de bare kan legges til, systemet støtter ikke endring eller sletting. Per i dag er den eneste måten å slette data på å slette dem etter kalendermåned, siden segmenter aldri krysser en månedsgrense. ClickHouse-teamet jobber aktivt med å gjøre denne funksjonen tilpassbar. På den annen side gjør det skriving og sammenslåing av segmenter konfliktfri, så motta gjennomstrømningsskalaer lineært med antall parallelle innlegg til I/O eller kjerner er mettet.
Denne omstendigheten betyr imidlertid også at systemet ikke er egnet for små pakker, så Kafka-tjenester og innsettingsprogrammer brukes til buffering. Videre fortsetter ClickHouse i bakgrunnen å kontinuerlig slå sammen segmentene, slik at mange små biter av informasjon vil bli kombinert og tatt opp flere ganger, og dermed øke opptaksintensiteten. Imidlertid vil for mange urelaterte deler forårsake aggressiv struping av innsatser så lenge sammenslåingen fortsetter. Vi har funnet ut at det beste kompromisset mellom datainntak i sanntid og inntaksytelse er å godta et begrenset antall innsettinger per sekund i tabellen.
Nøkkelen til ytelse for tabelllesing er indeksering og plassering av dataene på disken. Uansett hvor rask behandlingen er, når motoren trenger å skanne terabyte med data fra disken og bare bruke en brøkdel av den, vil det ta tid. ClickHouse er en kolonnebutikk, så hvert segment inneholder en fil for hver kolonne (kolonne) med sorterte verdier for hver rad. Dermed kan hele kolonner som ikke er til stede i spørringen først hoppes over, og deretter kan flere celler behandles parallelt med vektorisert utførelse. For å unngå full skanning har hvert segment en liten indeksfil.
Gitt at alle kolonner er sortert etter "primærnøkkelen", inneholder indeksfilen kun etikettene (fangede rader) til hver N. rad, for å kunne holde dem i minnet selv for veldig store tabeller. Du kan for eksempel sette standardinnstillingene til å "merke hver 8192. rad", deretter "mager" indeksering av en tabell med 1 billion. linjer som passer lett inn i minnet vil bare ta 122 070 tegn.
Systemutvikling
Utviklingen og forbedringen av Clickhouse kan spores på og sørg for at prosessen med å "vokse opp" skjer i et imponerende tempo.
Popularitet
Det ser ut til at Clickhouses popularitet vokser eksponentielt, spesielt i det russisktalende samfunnet. Fjorårets High load 2018-konferanse (Moskva, 8.-9. november 2018) viste at monstre som vk.com og Badoo bruker Clickhouse, som setter inn data (for eksempel logger) fra titusenvis av servere samtidig. I en 40 minutters video . Snart vil vi legge ut transkripsjonen på Habr for å gjøre det enklere å jobbe med materialet.
søknader
Etter å ha brukt litt tid på research, tror jeg det er områder hvor ClickHouse kan være nyttig eller i stand til å fullstendig erstatte andre mer tradisjonelle og populære løsninger som MySQL, PostgreSQL, ELK, Google Big Query, Amazon RedShift, TimescaleDB, Hadoop, MapReduce, Pinot og Druid. Følgende er detaljene for bruk av ClickHouse for å oppgradere eller fullstendig erstatte DBMS ovenfor.
Utvidelse av MySQL og PostgreSQL
Senest har vi delvis erstattet MySQL med ClickHouse for nyhetsbrevplattformen . Problemet var at MySQL på grunn av dårlig gjennomtenkt design logget hver e-post som ble sendt og hver lenke i den e-posten med en base64-hash, og skapte en enorm MySQL-tabell (email_stats). Etter å ha sendt bare 10 millioner e-poster til tjenestens abonnenter, tok dette bordet 150 GB filplass, og MySQL begynte å bli "dum" på enkle spørsmål. For å fikse problemet med filplass brukte vi InnoDB-tabellkomprimering, som reduserte den med en faktor på 4. Det gir imidlertid fortsatt ingen mening å lagre mer enn 20-30 millioner e-poster i MySQL bare for å lese historikken, ettersom enhver enkel spørring som av en eller annen grunn må gjøre en full skanning resulterer i bytte og tung I/O overhead, som vi regelmessig mottok Zabbix-advarsler om.
Clickhouse bruker to komprimeringsalgoritmer som reduserer datamengden med ca , men i dette spesielle tilfellet var dataene spesielt "komprimerbare".
ELK erstatning
Basert på min egen erfaring, krever ELK-stakken (ElasticSearch, Logstash og Kibana, i dette spesielle tilfellet ElasticSearch) mye mer ressurser å kjøre enn det som er nødvendig for å lagre logger. ElasticSearch er en flott motor hvis du vil ha et godt loggsøk i fulltekst (og jeg tror egentlig ikke du trenger det), men jeg lurer på hvorfor det har blitt de facto standard loggingsmotoren. Inntaksytelsen, kombinert med Logstash, ga oss problemer selv ved ganske lette arbeidsbelastninger og krevde tillegg av mer og mer RAM og diskplass. Som database er Clickhouse bedre enn ElasticSearch av følgende grunner:
- SQL-dialektstøtte;
- Den beste graden av komprimering av lagrede data;
- Støtte for regex-søk i stedet for fulltekstsøk;
- Forbedret spørringsplanlegging og bedre total ytelse.
Foreløpig er det største problemet som oppstår når man sammenligner ClickHouse med ELK mangelen på løsninger for opplasting av logger, samt mangelen på dokumentasjon og veiledninger om dette emnet. Samtidig kan hver bruker sette opp ELK ved hjelp av Digital Ocean-manualen, som er svært viktig for rask implementering av slike teknologier. Det er en databasemotor her, men det er ingen Filebeat for ClickHouse ennå. Ja det er og et system for arbeid med logger , det er et verktøy å legge inn loggfildata i ClickHouse, men alt dette tar mer tid. ClickHouse leder imidlertid fortsatt an på grunn av sin enkelhet, så selv nybegynnere kan enkelt installere den og starte fullt funksjonell bruk på bare 10 minutter.
Jeg foretrakk minimalistiske løsninger, og prøvde å bruke FluentBit, et verktøy for opplasting av logg med svært lite minne, med ClickHouse mens jeg prøvde å unngå å bruke Kafka. Imidlertid må mindre inkompatibiliteter tas opp, som f.eks før det kan gjøres uten proxy-laget som konverterer data fra FluentBit til ClickHouse.
Som et alternativ til Kibana kan du bruke ClickHouse som backend . Så vidt jeg forstår, kan dette forårsake ytelsesproblemer ved gjengivelse av et stort antall datapunkter, spesielt med eldre versjoner av Grafana. I Qwintry har vi ikke prøvd dette enda, men klager på dette dukker opp fra tid til annen på ClickHouse-støttekanalen i Telegram.
Erstatning av Google Big Query og Amazon RedShift (løsning for store selskaper)
Den ideelle brukssaken for BigQuery er å laste 1 TB med JSON-data og kjøre analytiske spørringer på den. Big Query er et flott produkt hvis skalerbarhet er vanskelig å overvurdere. Dette er mye mer kompleks programvare enn ClickHouse som kjører på en intern klynge, men fra kundens synspunkt har den mye til felles med ClickHouse. BigQuery kan raskt "prise opp" når du begynner å betale for hvert SELECT, så det er en ekte SaaS-løsning med alle fordeler og ulemper.
ClickHouse er det beste valget når du kjører mange beregningsmessig dyre spørringer. Jo flere SELECT-søk du kjører hver dag, jo mer poeng er det å erstatte Big Query med ClickHouse, fordi en slik erstatning vil spare deg for tusenvis av dollar når det gjelder mange terabyte med data som behandles. Dette gjelder ikke lagret data, som er ganske billig å behandle i Big Query.
I en artikkel av Alexander Zaitsev, medgründer av Altinity beskriver fordelene med en slik DBMS-migrering.
TidsskalaDB-erstatning
TimescaleDB er en PostgreSQL-utvidelse som optimerer arbeidet med tidsserier i en vanlig database (, ).
Selv om ClickHouse ikke er en seriøs konkurrent i tidsserienisjen, men når det gjelder kolonnestruktur og utførelse av vektorspørringer, er det mye raskere enn TimescaleDB i de fleste tilfeller av behandling av analytiske spørringer. Samtidig er ytelsen til å motta ClickHouse-pakkedata omtrent 3 ganger høyere, i tillegg bruker den 20 ganger mindre diskplass, noe som er veldig viktig for å behandle store mengder historiske data: .
I motsetning til ClickHouse, er den eneste måten å spare diskplass i TimescaleDB på å bruke ZFS eller lignende filsystemer.
Kommende oppdateringer til ClickHouse vil sannsynligvis introdusere delta-komprimering, noe som vil gjøre det enda mer egnet for behandling og lagring av tidsseriedata. TimescaleDB kan være et bedre valg enn bare ClickHouse i følgende tilfeller:
- små installasjoner med svært lite RAM (<3 GB);
- et stort antall små INSERT-er som du ikke vil bufre til store fragmenter;
- bedre konsistens, enhetlighet og ACID-krav;
- PostGIS-støtte;
- slå sammen med eksisterende PostgreSQL-tabeller, siden Timescale DB i hovedsak er PostgreSQL.
Konkurranse med Hadoop- og MapReduce-systemer
Hadoop og andre MapReduce-produkter kan utføre mange komplekse beregninger, men de har en tendens til å kjøre med stor forsinkelse. ClickHouse løser dette problemet ved å behandle terabyte med data og produsere resultater nesten umiddelbart. Dermed er ClickHouse mye mer effektivt for å utføre rask, interaktiv analytisk forskning, som burde være av interesse for dataforskere.
Konkurranse med Pinot og Druid
ClickHouses nærmeste konkurrenter er de søyleformede, lineært skalerbare open source-produktene Pinot og Druid. En utmerket jobb med å sammenligne disse systemene er publisert i artikkelen 1. februar 2018
Denne artikkelen må oppdateres – den sier at ClickHouse ikke støtter OPPDATERING og SLETT-operasjoner, noe som ikke er helt sant i forhold til de nyeste versjonene.
Vi har ikke mye erfaring med disse DBMS-ene, men jeg liker ikke kompleksiteten til den underliggende infrastrukturen som kreves for å kjøre Druid og Pinot – det er en hel haug med «bevegelige deler» omgitt av Java fra alle kanter.
Druid og Pinot er Apache-inkubatorprosjekter, som dekkes i detalj av Apache på GitHub-prosjektsidene deres. Pinot dukket opp i inkubatoren i oktober 2018, og Druid ble født 8 måneder tidligere - i februar.
Mangelen på informasjon om hvordan AFS fungerer reiser noen, og kanskje dumme, spørsmål for meg. Jeg lurer på om forfatterne av Pinot la merke til at Apache Foundation er mer disponert mot Druid, og forårsaket en slik holdning til en konkurrent en følelse av misunnelse? Vil utviklingen av Druid avta og utviklingen av Pinot akselerere hvis sponsorene som støtter førstnevnte plutselig blir interessert i sistnevnte?
Ulemper med ClickHouse
Umodenhet: Selvfølgelig er dette fortsatt en kjedelig teknologi, men i alle fall er ingenting slikt sett i andre kolonneformede DBMS.
Små innsatser fungerer ikke bra ved høy hastighet: innsatser må deles i store biter fordi ytelsen til små innsatser reduseres proporsjonalt med antall kolonner i hver rad. Dette er hvordan ClickHouse lagrer data på disk - hver kolonne betyr 1 fil eller mer, så for å sette inn 1 rad som inneholder 100 kolonner, må du åpne og skrive minst 100 filer. Dette er grunnen til at innsettingsbuffring krever en mellommann (med mindre klienten selv sørger for buffering) - vanligvis Kafka eller et slags køsystem. Du kan også bruke buffertabellmotoren til senere å kopiere store databiter til MergeTree-tabeller.
Bordkoblinger er begrenset av server-RAM, men de er i det minste der! Druid og Pinot har for eksempel ikke slike forbindelser i det hele tatt, siden de er vanskelige å implementere direkte i distribuerte systemer som ikke støtter flytting av store databiter mellom noder.
Funn
I de kommende årene planlegger vi å gjøre omfattende bruk av ClickHouse i Qwintry, da dette DBMS gir en utmerket balanse mellom ytelse, lav overhead, skalerbarhet og enkelhet. Jeg er ganske sikker på at det vil spre seg raskt når ClickHouse-fellesskapet kommer opp med flere måter å bruke det på i små og mellomstore installasjoner.
Noen annonser 🙂
Takk for at du bor hos oss. Liker du artiklene våre? Vil du se mer interessant innhold? Støtt oss ved å legge inn en bestilling eller anbefale til venner, , en unik analog av entry-level servere, som ble oppfunnet av oss for deg: (tilgjengelig med RAID1 og RAID10, opptil 24 kjerner og opptil 40 GB DDR4).
Dell R730xd 2x billigere i Equinix Tier IV datasenter i Amsterdam? Bare her i Nederland! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - fra $99! Lese om
Kilde: www.habr.com