är ett kolumnformat databashanteringssystem med öppen källkod för online analytisk frågebehandling (OLAP) skapat av Yandex. Den används av Yandex, CloudFlare, VK.com, Badoo och andra tjänster runt om i världen för att lagra riktigt stora mängder data (införande av tusentals rader per sekund eller petabyte data lagrad på disk).
I en normal "sträng" DBMS, som exempel är MySQL, Postgres, MS SQL Server, lagras data i denna ordning:
I det här fallet lagras värden relaterade till en rad fysiskt i närheten. I kolumnära DBMS:er lagras värden från olika kolumner separat, och data från en kolumn lagras tillsammans:
Exempel på kolumnära DBMS är 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öretaget är postbefordrare började använda Clickhouse 2018 för rapportering och var mycket imponerad av sin enkelhet, skalbarhet, SQL-stöd och snabbhet. Hastigheten på detta DBMS gränsade till magi.
Enkelhet
Clickhouse installeras på Ubuntu med ett enda kommando. Om du kan SQL kan du direkt börja använda Clickhouse för dina behov. Detta betyder dock inte att du kan "visa skapa tabell" i MySQL och kopiera-klistra in SQL i Clickhouse.
Jämfört med MySQL finns det viktiga datatypsskillnader i tabellschemadefinitionerna i detta DBMS, så du behöver fortfarande lite tid för att ändra tabellschemadefinitionerna och lära dig tabellmotorerna för att bli bekväm.
Clickhouse fungerar utmärkt utan ytterligare programvara, men om du vill använda replikering måste du installera ZooKeeper. Analys av frågeprestanda visar utmärkta resultat - systemtabellerna innehåller all information, och all data kan erhållas med gammal och tråkig SQL.
Производительность
- Clickhouse kontra Vertica och MySQL-jämförelser på konfigurationsserver: två sockel Intel® Xeon® CPU E5-2650 v2 @ 2.60 GHz; 128 GiB RAM; md RAID-5 på 8 6TB SATA HDD, ext4.
- jämförelse av Clickhouse med Amazon RedShift molnlagring.
- Bloggutdrag :
ClickHouse-databasen har en mycket enkel design - alla noder i klustret har samma funktionalitet och använder endast ZooKeeper för koordinering. Vi byggde ett litet kluster av flera noder och utförde tester, under vilka vi fann att systemet har ganska imponerande prestanda, vilket motsvarar de påstådda fördelarna i analytiska DBMS-riktmärken. Vi bestämde oss för att titta närmare på konceptet bakom ClickHouse. Det första hindret för forskning var bristen på verktyg och det lilla samhället ClickHouse, så vi grävde ner oss i designen av detta DBMS för att förstå hur det fungerar.
ClickHouse stöder inte att ta emot data direkt från Kafka eftersom det bara är en databas, så vi skrev vår egen adaptertjänst i Go. Den läste Cap'n Proto-kodade meddelanden från Kafka, konverterade dem till TSV och infogade dem i ClickHouse i omgångar via HTTP-gränssnittet. Vi skrev senare om den här tjänsten för att använda Go-biblioteket i kombination med ClickHouses eget gränssnitt för att förbättra prestandan. När vi utvärderade prestandan för att ta emot paket upptäckte vi en viktig sak - det visade sig att för ClickHouse beror denna prestanda starkt på storleken på paketet, det vill säga antalet samtidigt infogade rader. För att förstå varför detta händer tittade vi på hur ClickHouse lagrar data.
Huvudmotorn, eller snarare, en familj av tabellmotorer som används av ClickHouse för att lagra data, är MergeTree. Denna motor liknar konceptuellt 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 skrivgenomströmning, eftersom varje infogat paket endast sorteras efter primärnyckeln "primärnyckel", komprimeras och skrivs till disk för att bilda ett segment.
Frånvaron av en minnestabell eller något koncept av "färskhet" av data betyder också att de bara kan läggas till, systemet stöder inte ändring eller radering. Från och med idag är det enda sättet att radera data att radera den per kalendermånad, eftersom segment aldrig passerar en månadsgräns. ClickHouse-teamet arbetar aktivt med att göra denna funktion anpassningsbar. Å andra sidan gör det skrivning och sammanslagning av segment fria från konflikter, så ta emot genomströmningsskalor linjärt med antalet parallella insatser tills I/O eller kärnor mättas.
Men denna omständighet gör också att systemet inte är lämpligt för små paket, så Kafka-tjänster och insättare används för buffring. Vidare fortsätter ClickHouse i bakgrunden att kontinuerligt slå samman segment, så att många små bitar av information kommer att kombineras och spelas in fler gånger, vilket ökar intensiteten i inspelningen. Men för många orelaterade delar kommer att orsaka aggressiv strypning av skär så länge sammanfogningen fortsätter. Vi har funnit att den bästa kompromissen mellan realtidsdataintag och inmatningsprestanda är att acceptera ett begränsat antal infogningar per sekund i tabellen.
Nyckeln till tabellläsprestanda är indexeringen och placeringen av data på disken. Oavsett hur snabb bearbetningen är, när motorn behöver skanna terabyte med data från disken och bara använda en bråkdel av den, kommer det att ta tid. ClickHouse är en kolumnbutik, så varje segment innehåller en fil för varje kolumn (kolumn) med sorterade värden för varje rad. Således kan hela kolumner som inte finns i frågan först hoppas över, och sedan kan flera celler bearbetas parallellt med vektoriserad exekvering. För att undvika en fullständig genomsökning har varje segment en liten indexfil.
Med tanke på att alla kolumner är sorterade efter "primärnyckeln", innehåller indexfilen endast etiketterna (infångade rader) för varje N:te rad för att kunna behålla dem i minnet även för mycket stora tabeller. Du kan till exempel ställa in standardinställningarna för att "markera varje 8192:a rad", sedan "mager" indexering av en tabell med 1 biljon. rader som lätt passar in i minnet skulle bara ta 122 070 tecken.
Systemutveckling
Utvecklingen och förbättringen av Clickhouse kan spåras på och se till att processen att "växa upp" sker i en imponerande takt.
Popularitet
Det verkar som att Clickhouses popularitet växer exponentiellt, särskilt i det rysktalande samhället. Förra årets High load 2018-konferens (Moskva, 8-9 november 2018) visade att monster som vk.com och Badoo använder Clickhouse, som infogar data (till exempel loggar) från tiotusentals servrar samtidigt. I en 40 minuters video . Snart kommer vi att lägga upp utskriften på Habr för att underlätta arbetet med materialet.
tillämpningar
Efter att ha lagt ner lite tid på research tror jag att det finns områden där ClickHouse kan vara användbar eller helt kunna 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. Följande är detaljerna för att använda ClickHouse för att uppgradera eller helt ersätta ovanstående DBMS.
Utöka MySQL och PostgreSQL
Senast ersatte vi delvis MySQL med ClickHouse för nyhetsbrevsplattformen . Problemet var att MySQL på grund av ogenomtänkt design loggade varje e-postmeddelande som skickades och varje länk i det e-postmeddelandet med en base64-hash, vilket skapade en enorm MySQL-tabell (email_stats). Efter att ha skickat endast 10 miljoner e-postmeddelanden till tjänstens prenumeranter, upptog detta bord 150 GB filutrymme, och MySQL började bli "dum" på enkla frågor. För att åtgärda problemet med filutrymme använde vi framgångsrikt InnoDB-tabellkomprimering, vilket minskade det med en faktor 4. Men det är fortfarande inte meningsfullt att lagra mer än 20-30 miljoner e-postmeddelanden i MySQL bara för att läsa historikens skull, eftersom varje enkel fråga som av någon anledning måste göra en fullständig genomsökning resulterar i swap och tung I/O overhead, som vi regelbundet fick Zabbix-varningar om.
Clickhouse använder två komprimeringsalgoritmer som minskar datavolymen med ungefär , men i det här specifika fallet var data särskilt "komprimerbara".
Ersätter ELK
Baserat på min egen erfarenhet kräver ELK-stacken (ElasticSearch, Logstash och Kibana, i detta speciella fall ElasticSearch) mycket mer resurser att köra än vad som är nödvändigt för att lagra loggar. ElasticSearch är en bra motor om du behöver en bra loggsökning i fulltext (som jag inte tror att du verkligen behöver), men jag undrar varför det har blivit den de facto-standardloggningsmotorn. Dess intagsprestanda i kombination med Logstash gav oss problem även under ganska lätt belastning och krävde att vi lade till mer och mer RAM och diskutrymme. Som databas är Clickhouse bättre än ElasticSearch av följande skäl:
- SQL-dialektstöd;
- Den bästa graden av komprimering av lagrad data;
- Stöd för Regex-sökning istället för fulltextsökning;
- Förbättrad frågeschemaläggning och bättre övergripande prestanda.
För närvarande är det största problemet som uppstår när man jämför ClickHouse med ELK bristen på lösningar för att ladda upp loggar, samt bristen på dokumentation och handledningar i ämnet. Dessutom kan varje användare konfigurera ELK med hjälp av Digital Ocean-manualen, vilket är mycket viktigt för snabb implementering av sådana teknologier. Det finns en databasmotor här, men det finns ingen Filebeat för ClickHouse än. Ja, det finns och ett system för att arbeta med loggar , det finns ett verktyg att ange loggfilsdata i ClickHouse, men allt detta tar längre tid. ClickHouse är dock fortfarande ledande på grund av sin enkelhet, så även nybörjare kan enkelt installera det och börja använda det fullt funktionellt på bara 10 minuter.
Jag föredrog minimalistiska lösningar och försökte använda FluentBit, ett verktyg för uppladdning av loggfiler med mycket låg minne, med ClickHouse samtidigt som jag försökte undvika att använda Kafka. Mindre oförenligheter måste dock åtgärdas, som t.ex innan det kan göras utan proxyskiktet som konverterar data från FluentBit till ClickHouse.
Som ett alternativ kan Kibana användas som en ClickHouse backend . Såvitt jag förstår kan detta orsaka prestandaproblem vid rendering av ett stort antal datapunkter, särskilt med äldre versioner av Grafana. I Qwintry har vi inte provat detta än, men klagomål om detta dyker upp då och då på ClickHouse supportkanal i Telegram.
Ersättning av Google Big Query och Amazon RedShift (lösning för stora företag)
Det idealiska användningsfallet för BigQuery är att ladda 1 TB JSON-data och köra analytiska frågor på den. Big Query är en fantastisk produkt vars skalbarhet är svår att överskatta. Detta är mycket mer komplex mjukvara än ClickHouse som körs på ett internt kluster, men ur kundens synvinkel har det mycket gemensamt med ClickHouse. BigQuery kan snabbt "prissätta" när du börjar betala för varje SELECT, så det är en riktig SaaS-lösning med alla dess för- och nackdelar.
ClickHouse är det bästa valet när du kör många beräkningsdyra frågor. Ju fler SELECT-frågor du kör varje dag, desto mer poänger är det att ersätta Big Query med ClickHouse, eftersom en sådan ersättning kommer att spara tusentals dollar när det kommer till att många terabyte data bearbetas. Detta gäller inte lagrad data, som är ganska billig att bearbeta i Big Query.
I en artikel av Alexander Zaitsev, medgrundare av Altinity beskriver fördelarna med en sådan DBMS-migrering.
TimescaleDB-ersättning
TimescaleDB är ett PostgreSQL-tillägg som optimerar arbetet med tidsserier i en vanlig databas (, ).
Även om ClickHouse inte är en seriös konkurrent i tidsserienisschen, men när det gäller kolumnstruktur och vektorförfrågeexekvering är det mycket snabbare än TimescaleDB i de flesta fall av bearbetning av analytiska frågor. Samtidigt är prestandan för att ta emot ClickHouse-paketdata cirka 3 gånger högre, dessutom använder den 20 gånger mindre diskutrymme, vilket är riktigt viktigt för att bearbeta stora volymer historisk data: .
Till skillnad från ClickHouse är det enda sättet att spara lite diskutrymme i TimescaleDB att använda ZFS eller liknande filsystem.
Kommande uppdateringar av ClickHouse kommer sannolikt att introducera delta-komprimering, vilket kommer att göra det ännu mer lämpligt för bearbetning och lagring av tidsseriedata. TimescaleDB kan vara ett bättre val än bara ClickHouse i följande fall:
- små installationer med mycket lite RAM (<3 GB);
- ett stort antal små INSERT som du inte vill buffra till stora fragment;
- bättre konsekvens, enhetlighet och SYRA-krav;
- PostGIS-stöd;
- sammanfogning med befintliga PostgreSQL-tabeller, eftersom Timescale DB i huvudsak är PostgreSQL.
Konkurrens med Hadoop- och MapReduce-system
Hadoop och andra MapReduce-produkter kan utföra många komplexa beräkningar, men de tenderar att köras med enorm latens. ClickHouse fixar detta problem genom att bearbeta terabyte med data och producera resultat nästan omedelbart. Därför är ClickHouse mycket effektivare för att utföra snabb, interaktiv analytisk forskning, vilket borde vara av intresse för datavetare.
Konkurrens med Pinot och Druid
ClickHouses närmaste konkurrenter är de kolumnära, linjärt skalbara open source-produkterna Pinot och Druid. Ett utmärkt jobb att jämföra dessa system publiceras i artikeln 1 februari 2018
Den här artikeln behöver uppdateras - den säger att ClickHouse inte stöder UPDATE och DELETE operationer, vilket inte är helt sant i förhållande till de senaste versionerna.
Vi har inte så mycket erfarenhet av dessa DBMS, men jag gillar inte komplexiteten i den underliggande infrastrukturen som krävs för att köra Druid och Pinot – det är ett helt gäng "rörliga delar" omgivna av Java från alla håll.
Druid och Pinot är Apache-inkubatorprojekt, som behandlas i detalj av Apache på deras GitHub-projektsidor. Pinot dök upp i inkubatorn i oktober 2018, och Druid föddes 8 månader tidigare - i februari.
Bristen på information om hur AFS fungerar väcker vissa, och kanske dumma, frågor för mig. Jag undrar om Pinot-författarna märkte att Apache Foundation är mer gynnsam mot Druid, och om denna inställning till konkurrenten orsakade en känsla av avund? Kommer Druids utveckling att sakta ner och Pinots utveckling påskyndas om den förstnämndes stödjare plötsligt blir intresserade av den senare?
Nackdelar med ClickHouse
Omognad: Uppenbarligen är detta fortfarande ingen tråkig teknik, men i alla fall observeras inget liknande i andra kolumnära DBMS.
Små skär fungerar inte bra vid hög hastighet: skär måste delas upp i stora bitar eftersom prestandan för små skär försämras i proportion till antalet kolumner i varje rad. Så här lagrar ClickHouse data på disk - varje kolumn betyder 1 fil eller mer, så för att infoga 1 rad som innehåller 100 kolumner måste du öppna och skriva minst 100 filer. Det är därför som infogningsbuffring kräver en mellanhand (om inte klienten själv tillhandahåller buffring) - vanligtvis Kafka eller något slags kösystem. Du kan också använda bufferttabellmotorn för att senare kopiera stora bitar av data till MergeTree-tabeller.
Bordsanslutningar begränsas av serverns RAM, men de finns åtminstone där! Druid och Pinot har till exempel inga sådana kopplingar alls, eftersom de är svåra att implementera direkt i distribuerade system som inte har stöd för att flytta stora bitar av data mellan noder.
Resultat
Under de kommande åren planerar vi att i stor utsträckning använda ClickHouse i Qwintry, eftersom detta DBMS ger en utmärkt balans mellan prestanda, låg overhead, skalbarhet och enkelhet. Jag är ganska säker på att det kommer att spridas snabbt när ClickHouse-communityt kommer på fler sätt att använda det i små och medelstora installationer.
Några annonser 🙂
Tack för att du stannar hos oss. Gillar du våra artiklar? Vill du se mer intressant innehåll? Stöd oss genom att lägga en beställning eller rekommendera till vänner, , en unik analog av ingångsservrar, som uppfanns av oss för dig: (tillgänglig med RAID1 och RAID10, upp till 24 kärnor och upp till 40 GB DDR4).
Dell R730xd 2 gånger billigare i Equinix Tier IV datacenter i Amsterdam? Bara här 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: will.com