er et open source kolonnebaseret databasestyringssystem til online analytisk forespørgselsbehandling (OLAP) skabt af Yandex. Det bruges af Yandex, CloudFlare, VK.com, Badoo og andre tjenester rundt om i verden til at gemme virkelig store mængder data (indsættelse af tusindvis af rækker i sekundet eller petabyte data gemt på disken).
I en normal "streng" DBMS, som eksempler er MySQL, Postgres, MS SQL Server, lagres data i denne rækkefølge:
I dette tilfælde er værdierne relateret til en række fysisk gemt side om side. I søjleformet DBMS gemmes værdier fra forskellige kolonner separat, og dataene i en kolonne gemmes sammen:
Eksempler på søjleformede 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+.
Virksomheden er postformidler Jeg begyndte at bruge Clickhouse i 2018 til rapportering og var meget imponeret over dets enkelhed, skalerbarhed, SQL-understøttelse og hastighed. Hastigheden af dette DBMS grænsede til magi.
Ease
Clickhouse installeres på Ubuntu med en enkelt kommando. Hvis du kender SQL, kan du straks begynde at bruge Clickhouse til dine behov. Det betyder dog ikke, at du kan "vise oprette tabel" i MySQL og copy-paste SQL i Clickhouse.
Sammenlignet med MySQL er der vigtige datatypeforskelle i tabelskemadefinitionerne i dette DBMS, så du har stadig brug for lidt tid til at ændre tabelskemadefinitionerne og lære tabelmotorerne at blive fortrolige.
Clickhouse fungerer godt uden yderligere software, men hvis du vil bruge replikering, skal du installere ZooKeeper. Forespørgselsydelsesanalyse viser fremragende resultater - systemtabellerne indeholder al information, og alle data kan hentes ved hjælp af gammel og kedelig SQL.
Ydelse
- Clickhouse versus Vertica og MySQL sammenligninger på konfigurationsserver: to sokler Intel® Xeon® CPU E5-2650 v2 @ 2.60GHz; 128 GiB RAM; md RAID-5 på 8 6TB SATA HDD, ext4.
- sammenligning af Clickhouse med Amazon RedShift cloud storage.
- Bloguddrag :
ClickHouse-databasen har et meget simpelt design - alle noder i klyngen har samme funktionalitet og bruger kun ZooKeeper til koordinering. Vi byggede en lille klynge af flere noder og udførte test, hvor vi fandt ud af, at systemet har en ganske imponerende ydeevne, hvilket svarer til de påståede fordele i analytiske DBMS-benchmarks. Vi besluttede at se nærmere på konceptet bag ClickHouse. Den første hindring for forskning var manglen på værktøjer og det lille fællesskab af ClickHouse, så vi dykkede ned i designet af dette DBMS for at forstå, hvordan det fungerer.
ClickHouse understøtter ikke modtagelse af data direkte fra Kafka, da det blot er en database, så vi skrev vores egen adaptertjeneste i Go. Den læste Cap'n Proto-kodede beskeder fra Kafka, konverterede dem til TSV og indsatte dem i ClickHouse i batches via HTTP-grænsefladen. Vi omskrev senere denne tjeneste til at bruge Go-biblioteket i forbindelse med vores egen ClickHouse-grænseflade for at forbedre ydeevnen. Da vi evaluerede ydeevnen for at modtage pakker, opdagede vi en vigtig ting - det viste sig, at for ClickHouse afhænger denne ydeevne stærkt af pakkens størrelse, det vil sige antallet af rækker, der er indsat på samme tid. For at forstå, hvorfor dette sker, har vi undersøgt, hvordan ClickHouse gemmer data.
Hovedmotoren, eller rettere sagt, en familie af tabelmotorer, der bruges af ClickHouse til lagring af data, er MergeTree. Denne motor ligner konceptuelt LSM-algoritmen, der bruges i Google BigTable eller Apache Cassandra, men undgår at bygge en mellemliggende hukommelsestabel og skriver data direkte til disken. Dette giver den fremragende skrivegennemstrømning, da hver indsat pakke kun sorteres efter "primær nøgle" primærnøgle, komprimeres og skrives til disk for at danne et segment.
Fraværet af en hukommelsestabel eller et begreb om "friskhed" af data betyder også, at de kun kan tilføjes, systemet understøtter ikke ændring eller sletning. Fra i dag er den eneste måde at slette data på at slette dem efter kalendermåned, da segmenter aldrig krydser en månedsgrænse. ClickHouse-teamet arbejder aktivt på at gøre denne funktion tilpasselig. På den anden side gør det skrivning og fletning af segmenter fri for stridigheder, så modtag gennemløbsskalaer lineært med antallet af parallelle inserts, indtil I/O eller kerner mættes.
Men denne omstændighed betyder også, at systemet ikke er egnet til små pakker, så Kafka-tjenester og indsættere bruges til buffering. Yderligere fortsætter ClickHouse i baggrunden med løbende at flette segmenterne sammen, så mange små stykker information vil blive kombineret og optaget flere gange, hvilket øger optageintensiteten. Men for mange ikke-relaterede dele vil forårsage aggressiv drosling af skær, så længe sammenfletningen fortsætter. Vi har fundet ud af, at det bedste kompromis mellem dataindtagelse i realtid og indtagelsesydelse er at acceptere et begrænset antal indsættelser pr. sekund i tabellen.
Nøglen til tabellæseydelse er indekseringen og placeringen af dataene på disken. Uanset hvor hurtig behandlingen er, vil det tage tid, når motoren skal scanne terabyte af data fra disken og kun bruge en brøkdel af dem. ClickHouse er en kolonnebutik, så hvert segment indeholder en fil for hver kolonne (kolonne) med sorterede værdier for hver række. Hele kolonner, der ikke er til stede i forespørgslen, kan således først springes over, og derefter kan flere celler behandles parallelt med vektoriseret udførelse. For at undgå en fuld scanning har hvert segment en lille indeksfil.
Da alle kolonner er sorteret efter "primær nøgle", indeholder indeksfilen kun etiketterne (fangede rækker) for hver N'te række, for at kunne opbevare dem i hukommelsen selv for meget store tabeller. For eksempel kan du indstille standardindstillingerne til at "markere hver 8192. række", derefter "mager" indeksering af en tabel med 1 trillion. linjer, der nemt passer ind i hukommelsen, ville kun tage 122 tegn.
Systemudvikling
Udviklingen og forbedringen af Clickhouse kan spores på og sørg for, at processen med at "vokse op" sker i et imponerende tempo.
Popularitet
Det ser ud til, at Clickhouses popularitet vokser eksponentielt, især i det russisktalende samfund. Sidste års High load 2018-konference (Moskva, 8.-9. november 2018) viste, at monstre som vk.com og Badoo bruger Clickhouse, som indsætter data (for eksempel logfiler) fra titusindvis af servere samtidigt. I en 40 minutters video . Snart vil vi lægge udskriften på Habr for at gøre det nemmere at arbejde med materialet.
applikationer
Efter at have brugt noget tid på at researche, tror jeg, at der er områder, hvor ClickHouse kan være nyttige eller i stand til fuldstændig at erstatte andre mere traditionelle og populære løsninger såsom MySQL, PostgreSQL, ELK, Google Big Query, Amazon RedShift, TimescaleDB, Hadoop, MapReduce, Pinot og Druide. Følgende er detaljerne om brug af ClickHouse til at opgradere eller fuldstændigt erstatte ovenstående DBMS.
Udvidelse af MySQL og PostgreSQL
Senest har vi delvist erstattet MySQL med ClickHouse til nyhedsbrevsplatformen . Problemet var, at MySQL på grund af et dårligt gennemtænkt design loggede hver e-mail, der blev sendt, og hvert link i den e-mail med en base64-hash, hvilket skabte en enorm MySQL-tabel (email_stats). Efter kun at have sendt 10 millioner e-mails til tjenestens abonnenter, optog dette bord 150 GB filplads, og MySQL begyndte at "dumme" på simple forespørgsler. For at løse problemet med filpladsen brugte vi med succes InnoDB-tabelkomprimering, som reducerede den med en faktor på 4. Det giver dog stadig ikke mening at gemme mere end 20-30 millioner e-mails i MySQL bare for at læse historien, da enhver simpel forespørgsel, der af en eller anden grund skal lave en fuld scanning resulterer i swap og tung I/O overhead, som vi jævnligt modtog Zabbix-advarsler om.
Clickhouse bruger to kompressionsalgoritmer, der reducerer mængden af data med ca , men i dette særlige tilfælde var dataene særligt "komprimerbare".
ELK udskiftning
Baseret på min egen erfaring kræver ELK-stakken (ElasticSearch, Logstash og Kibana, i dette særlige tilfælde ElasticSearch) meget flere ressourcer at køre, end der er nødvendigt for at gemme logfiler. ElasticSearch er en fantastisk motor, hvis du vil have god fuldtekst-logsøgning (og jeg tror ikke, du virkelig har brug for det), men jeg undrer mig over, hvorfor det er blevet den de facto-standard-logningsmotor. Dens indtagelsesydelse, kombineret med Logstash, gav os problemer selv ved forholdsvis lette arbejdsbelastninger og krævede tilføjelse af mere og mere RAM og diskplads. Som database er Clickhouse bedre end ElasticSearch af følgende grunde:
- SQL-dialektunderstøttelse;
- Den bedste grad af komprimering af lagrede data;
- Understøttelse af Regex-søgning i stedet for fuldtekstsøgning;
- Forbedret forespørgselsplanlægning og bedre generel ydeevne.
I øjeblikket er det største problem, der opstår, når man sammenligner ClickHouse med ELK, manglen på løsninger til upload af logfiler, samt manglen på dokumentation og vejledninger om dette emne. Samtidig kan hver bruger opsætte ELK ved hjælp af Digital Ocean-manualen, hvilket er meget vigtigt for hurtig implementering af sådanne teknologier. Der er en databasemotor her, men der er endnu ingen Filebeat til ClickHouse. Ja der er og et system til at arbejde med logfiler , der er et værktøj at indtaste logfildata i ClickHouse, men alt dette tager længere tid. ClickHouse er dog stadig førende på grund af sin enkelhed, så selv begyndere kan nemt installere det og starte fuldt funktionsdygtigt på kun 10 minutter.
Foretrak minimalistiske løsninger, jeg prøvede at bruge FluentBit, et værktøj til upload af logfiler med meget lav hukommelse, med ClickHouse, mens jeg forsøgte at undgå at bruge Kafka. Der skal dog tages hånd om mindre uforeneligheder, som f.eks før det kan gøres uden proxy-laget, der konverterer data fra FluentBit til ClickHouse.
Som et alternativ til Kibana kan du bruge ClickHouse som backend . Så vidt jeg forstår, kan dette forårsage problemer med ydeevnen ved gengivelse af et stort antal datapunkter, især med ældre versioner af Grafana. I Qwintry har vi ikke prøvet dette endnu, men klager over dette dukker fra tid til anden op på ClickHouse supportkanalen i Telegram.
Udskiftning af Google Big Query og Amazon RedShift (løsning til store virksomheder)
Den ideelle use case for BigQuery er at indlæse 1 TB JSON-data og køre analytiske forespørgsler på det. Big Query er et fantastisk produkt, hvis skalerbarhed er svær at overvurdere. Dette er meget mere kompleks software end ClickHouse, der kører på en intern klynge, men set fra kundens synspunkt har det meget til fælles med ClickHouse. BigQuery kan hurtigt "prise op", når du begynder at betale for hver SELECT, så det er en rigtig SaaS-løsning med alle dens fordele og ulemper.
ClickHouse er det bedste valg, når du kører mange beregningsmæssigt dyre forespørgsler. Jo flere SELECT-forespørgsler du kører hver dag, desto mere mening giver det at erstatte Big Query med ClickHouse, fordi en sådan udskiftning vil spare dig for tusindvis af dollars, når det kommer til mange terabyte data, der behandles. Dette gælder ikke for lagrede data, som er ret billige at behandle i Big Query.
I en artikel af Alexander Zaitsev, medstifter af Altinity beskriver fordelene ved en sådan DBMS-migrering.
TidsskalaDB-erstatning
TimescaleDB er en PostgreSQL-udvidelse, der optimerer arbejdet med tidsserier i en almindelig database (, ).
Selvom ClickHouse ikke er en seriøs konkurrent i tidsserienichen, men med hensyn til søjlestruktur og vektorforespørgselsudførelse, er det meget hurtigere end TimescaleDB i de fleste tilfælde af behandling af analytiske forespørgsler. Samtidig er ydelsen ved modtagelse af ClickHouse-pakkedata omkring 3 gange højere, derudover bruger den 20 gange mindre diskplads, hvilket er virkelig vigtigt for at behandle store mængder historiske data: .
I modsætning til ClickHouse er den eneste måde at spare diskplads i TimescaleDB på at bruge ZFS eller lignende filsystemer.
Kommende opdateringer til ClickHouse vil sandsynligvis introducere delta-komprimering, hvilket vil gøre det endnu mere velegnet til behandling og lagring af tidsseriedata. TimescaleDB kan være et bedre valg end bare ClickHouse i følgende tilfælde:
- små installationer med meget lidt RAM (<3 GB);
- et stort antal små INSERT'er, som du ikke ønsker at bufre til store fragmenter;
- bedre konsistens, ensartethed og ACID-krav;
- PostGIS support;
- flette med eksisterende PostgreSQL-tabeller, da Timescale DB i det væsentlige er PostgreSQL.
Konkurrence med Hadoop- og MapReduce-systemer
Hadoop og andre MapReduce-produkter kan udføre en masse komplekse beregninger, men de har en tendens til at køre med enorm latency.ClickHouse løser dette problem ved at behandle terabyte data og producere resultater næsten øjeblikkeligt. ClickHouse er således meget mere effektivt til at udføre hurtig, interaktiv analytisk forskning, som burde være interessant for dataforskere.
Konkurrence med Pinot og Druid
ClickHouses nærmeste konkurrenter er de søjleformede, lineært skalerbare open source-produkter Pinot og Druid. Et fremragende arbejde med at sammenligne disse systemer er offentliggjort i artiklen 1. februar 2018
Denne artikel skal opdateres - den siger, at ClickHouse ikke understøtter UPDATE og DELETE operationer, hvilket ikke er helt sandt i forhold til de nyeste versioner.
Vi har ikke meget erfaring med disse DBMS'er, men jeg kan ikke lide kompleksiteten af den underliggende infrastruktur, der kræves for at køre Druid og Pinot - det er en hel masse "bevægelige dele" omgivet af Java fra alle sider.
Druid og Pinot er Apache-inkubatorprojekter, som er dækket i detaljer af Apache på deres GitHub-projektsider. Pinot dukkede op i inkubatoren i oktober 2018, og Druid blev født 8 måneder tidligere - i februar.
Manglen på information om, hvordan AFS fungerer, rejser nogle, og måske dumme, spørgsmål for mig. Jeg spekulerer på, om forfatterne af Pinot bemærkede, at Apache Foundation er mere indstillet på Druid, og forårsagede en sådan holdning til en konkurrent en følelse af misundelse? Vil udviklingen af Druid bremse og udviklingen af Pinot accelerere, hvis sponsorerne, der støtter førstnævnte, pludselig bliver interesseret i sidstnævnte?
Ulemper ved ClickHouse
Umodenhed: Det er klart, at dette stadig er en kedelig teknologi, men under alle omstændigheder ses intet lignende i andre kolonneformede DBMS.
Små skær fungerer ikke godt ved høj hastighed: skær skal opdeles i store bidder, fordi ydeevnen af små skær forringes i forhold til antallet af kolonner i hver række. Sådan gemmer ClickHouse data på disken - hver kolonne betyder 1 fil eller mere, så for at indsætte 1 række med 100 kolonner, skal du åbne og skrive mindst 100 filer. Dette er grunden til, at insert buffering kræver en mellemmand (medmindre klienten selv sørger for buffering) - normalt Kafka eller en slags køsystem. Du kan også bruge buffertabelmotoren til senere at kopiere store bidder af data til MergeTree-tabeller.
Table joins er begrænset af server RAM, men i det mindste er de der! For eksempel har Druid og Pinot slet ikke sådanne forbindelser, da de er svære at implementere direkte i distribuerede systemer, der ikke understøtter flytning af store bidder af data mellem noder.
Fund
I de kommende år planlægger vi at gøre omfattende brug af ClickHouse i Qwintry, da dette DBMS giver en fremragende balance mellem ydeevne, lav overhead, skalerbarhed og enkelhed. Jeg er ret sikker på, at det vil sprede sig hurtigt, når ClickHouse-fællesskabet kommer op med flere måder at bruge det på i små og mellemstore installationer.
Nogle annoncer 🙂
Tak fordi du blev hos os. Kan du lide vores artikler? Vil du se mere interessant indhold? Støt os ved at afgive en ordre eller anbefale til venner, , en unik analog af entry-level servere, som blev opfundet af os til dig: (tilgængelig med RAID1 og RAID10, op til 24 kerner og op til 40 GB DDR4).
Dell R730xd 2 gange billigere i Equinix Tier IV datacenter i Amsterdam? Kun her i Holland! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - fra $99! Læse om
Kilde: www.habr.com