Effektiv användning av ClickHouse. Alexey Milovidov (Yandex)

Eftersom ClickHouse är ett specialiserat system, när du använder det är det viktigt att ta hänsyn till funktionerna i dess arkitektur. I den här rapporten kommer Alexey att prata om exempel på vanliga misstag vid användning av ClickHouse, vilket kan leda till ineffektivt arbete. Praktiska exempel kommer att visa hur valet av ett eller annat databehandlingsschema kan förändra prestandan i storleksordningar.

Hej alla! Jag heter Alexey, jag gör ClickHouse.

För det första skyndar jag mig att behaga dig direkt, idag kommer jag inte att berätta vad ClickHouse är. För att vara ärlig så är jag trött på det. Varje gång jag berättar vad det är. Och det vet nog alla redan.

Istället ska jag berätta vilka möjliga fel som finns, det vill säga hur du kan använda ClickHouse felaktigt. Det finns faktiskt ingen anledning att vara rädd, eftersom vi utvecklar ClickHouse som ett system som är enkelt, bekvämt och fungerar direkt. Jag installerade det, inga problem.

Men du måste fortfarande ta hänsyn till att detta system är specialiserat och du kan lätt stöta på ett ovanligt användningsfall som kommer att ta det här systemet ur sin komfortzon.

Så, vilken typ av rake finns det? För det mesta kommer jag att prata om självklara saker. Allt är självklart för alla, alla förstår allt och kan vara glada över att de är så smarta, och de som inte förstår kommer att lära sig något nytt.

Det första och enklaste exemplet, som tyvärr ofta förekommer, är ett stort antal skär med små partier, d.v.s. ett stort antal små skär.

Om vi ​​överväger hur ClickHouse utför infogning, kan du skicka minst en terabyte data i en begäran. Det är inte ett problem.

Och låt oss se vad den typiska prestandan skulle vara. Till exempel har vi en tabell från Yandex.Metrica-data. Träffar. 105 några kolumner. 700 byte okomprimerad. Och vi kommer att infoga på ett bra sätt i satser om en miljon rader.

Vi infogar MergeTree i tabellen, det visar sig en halv miljon rader per sekund. Bra. I en replikerad tabell blir den lite mindre, ungefär 400 000 rader per sekund.

Och om du aktiverar kvoruminsättning får du lite mindre, men ändå anständig prestanda, 250 000 termer per sekund. Insättning av kvorum är en odokumenterad funktion i ClickHouse*.

* från och med 2020, redan dokumenterat.

Vad händer om du gör något dåligt? Vi infogar en rad i MergeTree-tabellen och får 59 rader per sekund. Det är 10 000 gånger långsammare. I ReplicatedMergeTree – 6 rader per sekund. Och om kvorumet är påslaget, visar det sig 2 rader per sekund. Enligt min åsikt är detta någon form av absolut skit. Hur kan du sakta ner så? Jag har till och med skrivit på min t-shirt att ClickHouse inte ska sakta ner. Men ändå händer det ibland.

I själva verket är detta vår brist. Vi hade lätt kunnat få allt att fungera bra, men det gjorde vi inte. Och vi gjorde det inte för att vårt manus inte krävde det. Vi hade redan butcher. Vi fick precis partier vid vår entré, och inga problem. Vi sätter in den och allt fungerar bra. Men naturligtvis är alla möjliga scenarier möjliga. Till exempel när du har ett gäng servrar som data genereras på. Och de infogar inte data så ofta, men de slutar ändå med frekventa inlägg. Och vi måste på något sätt undvika detta.

Ur teknisk synvinkel är poängen att när man gör en insert i ClickHouse så hamnar inte datan i någon memtable. Vi har inte ens en riktig loggstruktur MergeTree, utan bara en MergeTree, eftersom det varken finns en logg eller en memTable. Vi skriver helt enkelt omedelbart data till filsystemet, redan ordnade i kolumner. Och om du har 100 kolumner, måste mer än 200 filer skrivas till en separat katalog. Allt detta är väldigt krångligt.

Och frågan uppstår: "Hur gör man det rätt?" Om situationen är sådan att du fortfarande behöver registrera data på något sätt i ClickHouse.

Metod 1. Detta är det enklaste sättet. Använd någon form av distribuerad kö. Till exempel Kafka. Du extraherar helt enkelt data från Kafka och batchar den en gång i sekunden. Och allt kommer att bli bra, du spelar in, allt fungerar bra.

Nackdelarna är att Kafka är ett annat skrymmande distribuerat system. Jag förstår också om du redan har Kafka i ditt företag. Det är bra, det är bekvämt. Men om det inte finns, bör du tänka tre gånger innan du drar ännu ett distribuerat system till ditt projekt. Och därför är det värt att överväga alternativ.

Metod 2. Detta är ett gammaldags alternativ och samtidigt väldigt enkelt. Har du någon sorts server som genererar dina loggar. Och den skriver bara dina loggar till en fil. Och en gång i sekunden döper vi till exempel om den här filen och river av en ny. Och ett separat skript, antingen via cron eller någon demon, tar den äldsta filen och skriver den till ClickHouse. Om du spelar in loggar en gång i sekunden kommer allt att bli bra.

Men nackdelen med den här metoden är att om din server som loggarna genereras på försvinner någonstans så försvinner även data.

Metod 3. Det finns en annan intressant metod, som inte kräver tillfälliga filer alls. Till exempel har du någon form av reklamsnurra eller någon annan intressant demon som genererar data. Och du kan samla en massa data direkt i RAM-minnet, i bufferten. Och när tillräckligt med tid har gått lägger du denna buffert åt sidan, skapar en ny och i en separat tråd infogar du det som redan har samlats i ClickHouse.

Å andra sidan försvinner även data med kill -9. Om din server kraschar kommer du att förlora denna data. Och ett annat problem är att om du inte kunde skriva till databasen, kommer dina data att samlas i RAM-minnet. Och antingen kommer RAM-minnet att ta slut, eller så förlorar du helt enkelt data.

Metod 4. En annan intressant metod. Har du någon form av serverprocess. Och det kan skicka data till ClickHouse omedelbart, men gör det i en anslutning. Till exempel skickade jag en http-förfrågan med transfer-encoding: chunked with insert. Och det genererar inte alltför sällan bitar, du kan skicka varje rad, även om det kommer att finnas overhead för att rama in denna data.

Men i det här fallet kommer data att skickas till ClickHouse omedelbart. Och ClickHouse kommer att buffra dem själv.

Men problem uppstår också. Nu kommer du att förlora data, inklusive när din process är dödad och om ClickHouse-processen dödas, eftersom det kommer att vara en ofullständig infogning. Och i ClickHouse är inlägg atomära upp till en viss specificerad tröskel i storleken på rader. I princip är detta ett intressant sätt. Kan även användas.

Metod 5. Här är en annan intressant metod. Det här är någon slags gemenskapsutvecklad server för databatchning. Jag har inte tittat på det själv, så jag kan inte garantera något. Däremot ges inga garantier för själva ClickHouse. Detta är också öppen källkod, men å andra sidan kanske du är van vid någon kvalitetsstandard som vi försöker tillhandahålla. Men för den här saken - jag vet inte, gå till GitHub, titta på koden. Kanske skrev de något normalt.

* från och med 2020, bör också läggas till i övervägande KittenHouse.

Metod 6. En annan metod är att använda bufferttabeller. Fördelen med denna metod är att den är väldigt lätt att börja använda. Skapa en bufferttabell och infoga den i den.

Nackdelen är att problemet inte är helt löst. Om du i en takt som MergeTree måste gruppera data med en batch per sekund, så måste du i en hastighet i en bufferttabell gruppera minst upp till flera tusen per sekund. Om det är mer än 10 000 per sekund blir det fortfarande dåligt. Och om du sätter in det i omgångar, så såg du att det visar sig vara hundra tusen rader per sekund. Och detta finns redan på ganska tung data.

Och även bufferttabeller har ingen logg. Och om det är något fel på din server kommer data att gå förlorade.

Och som en bonus fick vi nyligen möjligheten på ClickHouse att hämta data från Kafka. Det finns en bordsmotor - Kafka. Du skapar helt enkelt. Och du kan hänga materialiserade representationer på den. I det här fallet kommer den själv att extrahera data från Kafka och infoga den i de tabeller du behöver.

Och det som är särskilt glädjande med denna möjlighet är att det inte var vi som gjorde det. Detta är en gemenskapsfunktion. Och när jag säger "gemenskapsinslag" menar jag det utan något förakt. Vi läste koden, gjorde en recension, den borde fungera bra.

* från och med 2020 har liknande stöd dykt upp för RabbitMQ.

Vad mer kan vara obekvämt eller oväntat när du infogar data? Om du gör en infoga värdebegäran och skriv några beräknade uttryck i värden. Till exempel är now() också ett beräknat uttryck. Och i det här fallet tvingas ClickHouse att starta tolken av dessa uttryck på varje rad, och prestandan kommer att sjunka i storleksordningar. Det är bättre att undvika detta.

* för tillfället är problemet helt löst, det finns inte längre någon prestandaregression när du använder uttryck i VALUES.

Ett annat exempel är när det kan uppstå problem när du har data på en batch som tillhör ett gäng partitioner. Som standard är ClickHouse-partitioner per månad. Och om du infogar en sats på en miljon rader och det finns data för flera år, kommer du att ha flera dussin partitioner där. Och detta motsvarar det faktum att det kommer att finnas partier flera tiotals gånger mindre i storlek, eftersom de inuti alltid först är uppdelade i partitioner.

* Nyligen, i experimentellt läge, lade ClickHouse till stöd för det kompakta formatet av bitar och bitar i RAM-minne med skriv-ahead-logg, vilket nästan helt löser problemet.

Låt oss nu titta på den andra typen av problem - dataskrivning.

Datainmatning kan vara strikt eller sträng. String är när du precis tog den och förklarade att alla dina fält är av typen string. Det här suger. Det finns inget behov av att göra detta.

Låt oss ta reda på hur man gör det på rätt sätt i de fall du vill säga att vi har ett fält, en sträng, och låt ClickHouse ta reda på det på egen hand, och jag ska inte bry mig. Men det är ändå värt att anstränga sig.

Vi har till exempel en IP-adress. I ett fall sparade vi det som ett snöre. Till exempel 192.168.1.1. Och i ett annat fall blir det ett antal av typen UInt32*. 32 bitar räcker för en IPv4-adress.

För det första kommer data märkligt nog att komprimeras ungefär lika mycket. Det blir förstås skillnad, men inte så stor. Så det finns inga speciella problem med disk I/O.

Men det finns en allvarlig skillnad i processortid och frågekörningstid.

Låt oss räkna antalet unika IP-adresser om de lagras som nummer. Det blir 137 miljoner rader per sekund. Om samma är i form av strängar, då 37 miljoner linjer per sekund. Jag vet inte varför denna slump hände. Jag utförde dessa förfrågningar själv. Men fortfarande ca 4 gånger långsammare.

Och om du räknar ut skillnaden i diskutrymme, så finns det också en skillnad. Och skillnaden är ungefär en fjärdedel, eftersom det finns ganska många unika IP-adresser. Och om det fanns rader med ett litet antal olika betydelser, så skulle de lätt komprimeras enligt ordboken till ungefär samma volym.

Och den fyrfaldiga tidsskillnaden ligger inte på vägen. Man kanske inte bryr sig såklart, men när jag ser en sådan skillnad blir jag ledsen.

Låt oss titta på olika fall.

1. Ett fall när du har få olika unika värden. I det här fallet använder vi en enkel praxis som du förmodligen känner till och kan använda för alla DBMS. Allt detta är vettigt inte bara för ClickHouse. Skriv bara numeriska identifierare i databasen. Och du kan konvertera till strängar och tillbaka på sidan av din applikation.

Du har till exempel en region. Och du försöker spara den som en sträng. Och det kommer att skrivas där: Moskva och Moskvaregionen. Och när jag ser att det står "Moskva" är det ingenting, men när det är Moskva blir det på något sätt helt sorgligt. Detta är hur många byte.

Istället skriver vi helt enkelt ner numret Ulnt32 och 250. Vi har 250 i Yandex, men ditt kan vara annorlunda. För säkerhets skull ska jag säga att ClickHouse har en inbyggd förmåga att arbeta med en geobas. Du skriver helt enkelt ner en katalog med regioner, inklusive en hierarkisk, dvs det kommer att finnas Moskva, Moskvaregionen och allt du behöver. Och du kan konvertera på begäran nivå.

Det andra alternativet är ungefär detsamma, men med stöd inuti ClickHouse. Detta är datatypen Enum. Du skriver helt enkelt alla värden du behöver inuti Enum. Till exempel typ av enhet och skriv där: stationär, mobil, surfplatta, TV. Det finns totalt 4 alternativ.

Nackdelen är att du behöver ändra den med jämna mellanrum. Bara ett alternativ har lagts till. Låt oss ändra tabell. Faktum är att ändra tabell i ClickHouse är gratis. Särskilt gratis för Enum eftersom data på disken inte ändras. Men ändå får alter ett lås* på bordet och måste vänta tills alla val har utförts. Och först efter att denna ändring kommer att utföras, d.v.s. det finns fortfarande några olägenheter.

* i de senaste versionerna av ClickHouse är ALTER helt icke-blockerande.

Ett annat alternativ som är ganska unikt för ClickHouse är att ansluta externa ordböcker. Du kan skriva siffror i ClickHouse och behålla dina kataloger i vilket system som helst som passar dig. Du kan till exempel använda: MySQL, Mongo, Postgres. Du kan till och med skapa din egen mikrotjänst som skickar denna data via http. Och på ClickHouse-nivå skriver du en funktion som konverterar denna data från siffror till strängar.

Detta är ett specialiserat men mycket effektivt sätt att utföra en join på ett externt bord. Och det finns två alternativ. I en utföringsform kommer denna data att vara fullständigt cachelagrad, helt närvarande i RAM:et och uppdaterad med viss frekvens. Och i ett annat alternativ, om dessa data inte passar in i RAM-minnet, kan du delvis cache det.

Här är ett exempel. Det finns Yandex.Direct. Och det finns ett reklamföretag och banners. Det finns förmodligen ungefär tiotals miljoner reklamföretag. Och de passar ungefär in i RAM-minnet. Och det finns miljarder banderoller, de passar inte. Och vi använder en cachad ordbok från MySQL.

Det enda problemet är att den cachade ordboken fungerar bra om träfffrekvensen är nära 100 %. Om den är mindre måste du faktiskt ta de saknade nycklarna och hämta data från MySQL när du bearbetar frågor för varje databatt. Om ClickHouse kan jag fortfarande garantera att - ja, det saktar inte ner, jag kommer inte att prata om andra system.

Och som en bonus är ordböcker ett mycket enkelt sätt att retroaktivt uppdatera data i ClickHouse. Det vill säga, du hade en rapport om reklamföretag, användaren ändrade helt enkelt reklamföretaget och i alla gamla data, i alla rapporter, ändrades även denna data. Om du skriver rader direkt till tabellen blir det omöjligt att uppdatera dem.

Ett annat sätt när du inte vet var du kan få tag i identifierarna för dina strängar. du kan helt enkelt hasha det. Dessutom är det enklaste alternativet att ta en 64-bitars hash.

Det enda problemet är att om hashen är 64-bitars kommer du nästan säkert att ha kollisioner. För om det finns en miljard rader där, så blir sannolikheten redan märkbar.

Och det skulle inte vara särskilt bra att hasha namnen på reklamföretag på det här sättet. Om olika företags reklamkampanjer blandas ihop blir det något obegripligt.

Och det finns ett enkelt knep. Det är sant att det inte heller är särskilt lämpligt för seriösa data, men om något inte är särskilt allvarligt, lägg bara till klientidentifieraren i ordboksnyckeln. Och då kommer du att ha kollisioner, men bara inom en klient. Och vi använder den här metoden för länkkartor i Yandex.Metrica. Vi har webbadresser där, vi lagrar hash. Och vi vet att det förstås finns kollisioner. Men när sidan visas kan sannolikheten att på en sida hos en användare vissa webbadresser har fastnat ihop och detta kommer att märkas försummas.

Som en bonus är det tillräckligt med hash för många operationer och själva strängarna behöver inte lagras någonstans.

Ett annat exempel är om strängarna är korta, till exempel webbplatsdomäner. De kan förvaras som de är. Eller, till exempel, webbläsarspråket ru är 2 byte. Naturligtvis tycker jag verkligen synd om byten, men oroa dig inte, 2 byte är inte synd. Behåll det som det är, oroa dig inte.

Ett annat fall är när, tvärtom, det finns många rader och det finns många unika i dem, och även uppsättningen är potentiellt obegränsad. Ett typiskt exempel är sökfraser eller webbadresser. Sökfraser, inklusive stavfel. Låt oss se hur många unika sökfraser det finns per dag. Och det visar sig att de är nästan hälften av alla evenemang. Och i det här fallet kanske du tror att du behöver normalisera data, räkna identifierarna och lägga dem i en separat tabell. Men du behöver inte göra det. Behåll bara dessa rader som de är.

Det är bättre att inte uppfinna något, för om du lagrar det separat måste du göra en koppling. Och denna sammanfogning är i bästa fall en slumpmässig tillgång till minnet, om den fortfarande får plats i minnet. Om det inte passar så blir det problem.

Och om data lagras på plats läses den helt enkelt i önskad ordning från filsystemet och allt är bra.

Om du har webbadresser eller någon annan komplex lång sträng, är det värt att tänka på att du kan beräkna någon form av extrakt i förväg och skriva det i en separat kolumn.

För webbadresser, till exempel, kan du lagra domänen separat. Och om du verkligen behöver en domän, använd bara den här kolumnen, så kommer webbadresserna att ligga där, och du kommer inte ens att röra dem.

Låt oss se vad skillnaden är. ClickHouse har en specialiserad funktion som beräknar domänen. Det är väldigt snabbt, vi har optimerat det. Och, för att vara ärlig, överensstämmer den inte ens med RFC, men ändå tar den hänsyn till allt vi behöver.

Och i ett fall får vi helt enkelt webbadresserna och beräknar domänen. Det blir 166 millisekunder. Och om du tar en färdig domän, så visar det sig att det bara är 67 millisekunder, dvs nästan tre gånger snabbare. Och det är snabbare inte för att vi behöver göra några beräkningar, utan för att vi läser mindre data.

Det är därför en begäran, som är långsammare, har en högre hastighet på gigabyte per sekund. Eftersom den läser mer gigabyte. Detta är helt onödiga uppgifter. Begäran verkar gå snabbare, men det tar längre tid att slutföra.

Och om du tittar på mängden data på disken, visar det sig att URL:en är 126 megabyte, och domänen är bara 5 megabyte. Det visar sig 25 gånger mindre. Men inte desto mindre exekveras begäran bara 4 gånger snabbare. Men det beror på att data är heta. Och om det vore kallt skulle det förmodligen vara 25 gånger snabbare på grund av disk I/O.

Förresten, om man uppskattar hur mycket mindre en domän är än en URL så visar den sig vara cirka 4 gånger mindre.Men av någon anledning tar data upp 25 gånger mindre på disken. Varför? På grund av kompression. Och URL:en är komprimerad, och domänen är komprimerad. Men ofta innehåller webbadressen en massa skräp.

Och, naturligtvis, lönar det sig att använda rätt datatyper som är utformade specifikt för de önskade värdena eller som är lämpliga. Om du använder IPv4, lagra då UInt32*. Om IPv6, då FixedString(16), eftersom IPv6-adressen är 128 bitar, dvs lagras direkt i binärt format.

Men vad händer om du ibland har IPv4-adresser och ibland IPv6? Ja, du kan lagra båda. En kolumn för IPv4, en annan för IPv6. Naturligtvis finns det ett alternativ att visa IPv4 i IPv6. Detta kommer också att fungera, men om du ofta behöver en IPv4-adress i förfrågningar, så skulle det vara trevligt att lägga den i en separat kolumn.

* ClickHouse har nu separata IPv4, IPv6 datatyper som lagrar data lika effektivt som siffror, men representerar dem lika bekvämt som strängar.

Det är också viktigt att notera att det är värt att förbehandla data i förväg. Till exempel får du några råloggar. Och du kanske inte bara ska lägga dem i ClickHouse direkt, även om det är väldigt frestande att inte göra någonting och allt kommer att fungera. Men det är ändå värt att genomföra de beräkningar som är möjliga.

Till exempel webbläsarversion. I någon närliggande avdelning, som jag inte vill peka finger på, lagras webbläsarversionen så här, det vill säga som en sträng: 12.3. Och sedan, för att göra en rapport, tar de den här strängen och delar upp den i en array och sedan i det första elementet i arrayen. Naturligtvis saktar allt ner. Jag frågade varför de gör så här. De sa till mig att de inte gillar för tidig optimering. Och jag gillar inte för tidig pessimisering.

Så i det här fallet skulle det vara mer korrekt att dela upp i 4 kolumner. Var inte rädd här, för det här är ClickHouse. ClickHouse är en kolumnformad databas. Och ju mer prydliga små kolumner, desto bättre. Det kommer att finnas 5 webbläsarversioner, skapa 5 kolumner. Det här är okej.

Låt oss nu titta på vad du ska göra om du har många väldigt långa strängar, väldigt långa arrayer. De behöver inte förvaras i ClickHouse alls. Istället kan du bara lagra en identifierare i ClickHouse. Och lägg dessa långa rader i något annat system.

Till exempel har en av våra analystjänster några händelseparametrar. Och om det finns många parametrar för händelser sparar vi helt enkelt de första 512 som stöter på. För 512 är inte synd.

Och om du inte kan bestämma dig för dina datatyper kan du också spela in data i ClickHouse, men i en tillfällig tabell av typen Logg, speciellt för temporär data. Efter detta kan du analysera vilken fördelning av värden du har där, vad som finns där i allmänhet och skapa rätt typer.

*ClickHouse har nu en datatyp Låg kardinalitet vilket gör att du kan lagra strängar effektivt med mindre ansträngning.

Låt oss nu titta på ett annat intressant fall. Ibland fungerar saker konstigt för människor. Jag kommer in och ser det här. Och det verkar direkt som att detta gjordes av en mycket erfaren, smart administratör som har lång erfarenhet av att konfigurera MySQL version 3.23.

Här ser vi tusen tabeller, som var och en registrerar resten av att dividera vem som vet vad med tusen.

I princip respekterar jag andra människors erfarenheter, inklusive förståelsen för det lidande som kan uppnås genom denna erfarenhet.

Och skälen är mer eller mindre tydliga. Det här är gamla stereotyper som kan ha ackumulerats under arbetet med andra system. Till exempel har MyISAM-tabeller inte en klustrad primärnyckel. Och det här sättet att dela upp data kan vara ett desperat försök att få samma funktionalitet.

En annan anledning är att det är svårt att göra några ändringsoperationer på stora bord. Allt kommer att blockeras. Även om detta problem inte längre är så allvarligt i moderna versioner av MySQL.

Eller till exempel microsharding, men mer om det senare.

Det finns inget behov av att göra detta i ClickHouse, eftersom primärnyckeln för det första är klustrad, data sorteras efter primärnyckeln.

Och ibland frågar folk mig: "Hur varierar prestandan för intervallfrågor i ClickHouse beroende på tabellstorleken?" Jag säger att det inte förändras alls. Till exempel har du en tabell med en miljard rader och du läser ett intervall på en miljon rader. Allt är bra. Om det finns en biljon rader i en tabell och du läser en miljon rader blir det nästan detsamma.

Och för det andra krävs inte alla möjliga saker som manuella partitioner. Om du går in och tittar på vad som finns i filsystemet ser du att tabellen är en ganska stor sak. Och det finns något som skiljer inuti. Det vill säga, ClickHouse gör allt för dig och du behöver inte lida.

Ändra i ClickHouse är gratis om ändra lägg till/släpp kolumn.

Och du bör inte göra små tabeller, för om du har 10 rader eller 10 000 rader i en tabell, så spelar det ingen roll. ClickHouse är ett system som optimerar genomströmning, inte latens, så det är ingen mening att bearbeta 10 rader.

Det är korrekt att använda ett stort bord. Bli av med gamla stereotyper, allt blir bra.

Och som en bonus, i den senaste versionen har vi nu möjlighet att skapa en godtycklig partitioneringsnyckel för att utföra alla typer av underhållsoperationer på enskilda partitioner.

Till exempel behöver du många små tabeller, till exempel när det finns ett behov av att bearbeta en del mellanliggande data får du bitar och du behöver utföra en transformation på dem innan du skriver till finalbordet. För det här fallet finns det en underbar bordsmotor - StripeLog. Det är ungefär som TinyLog, bara bättre.

* nu har ClickHouse också tabellfunktionsingång.

Ett annat antimönster är microsharding. Till exempel behöver du klippa data och du har 5 servrar, och imorgon kommer det att finnas 6 servrar. Och du tänker på hur du ska balansera om denna data. Och istället bryter du inte i 5 skärvor, utan i 1 000 skärvor. Och sedan mappar du var och en av dessa mikroskärvor till en separat server. Och du får till exempel 200 ClickHouses på en server till exempel. Separata instanser på separata portar eller separata databaser.

Men detta är inte särskilt bra i ClickHouse. Eftersom även en ClickHouse-instans försöker använda alla tillgängliga serverresurser för att behandla en begäran. Det vill säga att du har någon slags server och den har till exempel 56 processorkärnor. Du kör en fråga som tar en sekund och den kommer att använda 56 kärnor. Och om du placerade 200 ClickHouses där på en server, så visar det sig att 10 000 trådar kommer att starta. I allmänhet kommer allt att vara väldigt dåligt.

En annan anledning är att arbetsfördelningen mellan dessa instanser blir ojämn. Vissa kommer att sluta tidigare, vissa kommer att sluta senare. Om allt detta hände i en instans, skulle ClickHouse själv ta reda på hur man korrekt distribuerar data mellan trådarna.

Och en annan anledning är att du kommer att ha interprocessorkommunikation via TCP. Data kommer att behöva serialiseras, deserialiseras, och detta är ett stort antal mikroskärvor. Det kommer helt enkelt inte att fungera effektivt.

Ett annat antimönster, även om det knappast kan kallas ett antimönster. Detta är en stor mängd föraggregation.

I allmänhet är föraggregation bra. Du hade en miljard rader, du aggregerade det och det blev 1 000 rader, och nu körs frågan omedelbart. Allt är bra. Du kan göra det här. Och för detta har även ClickHouse en speciell tabelltyp, AggregatingMergeTree, som utför inkrementell aggregering när data infogas.

Men det finns tillfällen då du tror att vi kommer att aggregera data som denna och aggregerade data som denna. Och i någon angränsande avdelning vill jag inte heller säga vilken, de använder SummingMergeTree-tabeller för att sammanfatta med primärnyckeln, och cirka 20 kolumner används som primärnyckel. För säkerhets skull ändrade jag namnen på några kolumner för sekretess, men det är i stort sett det.

Och sådana problem uppstår. För det första minskar inte din datavolym för mycket. Den minskar till exempel tre gånger. Tre gånger skulle vara ett bra pris för att ha råd med de obegränsade analysmöjligheterna som uppstår om din data inte är aggregerad. Om uppgifterna är aggregerade får du istället för analyser bara ynklig statistik.

Och vad är det som är så speciellt med det? Faktum är att dessa personer från grannavdelningen ibland går och ber om att få lägga till ytterligare en kolumn till primärnyckeln. Det vill säga att vi aggregerade uppgifterna så här, men nu vill vi ha lite mer. Men ClickHouse har inte en alter-primärnyckel. Därför måste vi skriva några skript i C++. Och jag gillar inte skript, även om de är i C++.

Och om du tittar på vad ClickHouse skapades för, så är icke-aggregerad data exakt det scenario som det föddes för. Om du använder ClickHouse för icke-aggregerad data, gör du det rätt. Om du sammanställer är detta ibland förlåtligt.

Ett annat intressant fall är frågor i en oändlig loop. Ibland går jag till någon produktionsserver och tittar på show processlist där. Och varje gång upptäcker jag att något hemskt händer.

Till exempel så här. Det är direkt klart att allt kan göras på en begäran. Skriv bara in webbadressen och listan där.

Varför är många sådana frågor i en oändlig loop dåliga? Om ett index inte används kommer du att ha många pass över samma data. Men om indexet används, till exempel, har du en primärnyckel för ru och du skriver url = något där. Och du tror att om bara en webbadress läses från tabellen kommer allt att bli bra. Men faktiskt nej. Eftersom ClickHouse gör allt i omgångar.

När han behöver läsa en viss mängd data läser han lite mer, eftersom indexet i ClickHouse är sparsamt. Detta index tillåter dig inte att hitta en enskild rad i tabellen, bara ett intervall av något slag. Och data komprimeras i block. För att kunna läsa en rad måste du ta hela blocket och lossa det. Och om du gör en massa frågor kommer du att ha mycket överlappning, och du kommer att ha mycket arbete att göra om och om igen.

Och som en bonus kan du notera att i ClickHouse bör du inte vara rädd för att överföra till och med megabyte och till och med hundratals megabyte till IN-sektionen. Jag minns från vår praktik att om vi i MySQL överför ett gäng värden till IN-sektionen, till exempel överför vi 100 megabyte av vissa nummer dit, då äter MySQL upp 10 gigabyte minne och inget annat händer med det, allt fungerar dåligt.

Och det andra är att i ClickHouse, om dina frågor använder ett index, är det alltid inte långsammare än en fullständig skanning, det vill säga om du behöver läsa nästan hela tabellen, kommer den att gå sekventiellt och läsa hela tabellen. I allmänhet kommer han att ta reda på det på egen hand.

Men ändå finns det vissa svårigheter. Till exempel det faktum att IN med en underfråga inte använder indexet. Men det här är vårt problem och vi måste åtgärda det. Det finns inget grundläggande här. Vi fixar det*.

Och en annan intressant sak är att om du har en mycket lång förfrågan och distribuerad förfrågningsbehandling pågår, så kommer denna mycket långa begäran att skickas till varje server utan komprimering. Till exempel 100 megabyte och 500 servrar. Och följaktligen kommer du att ha 50 gigabyte överförda över nätverket. Det kommer att överföras och sedan kommer allt att slutföras framgångsrikt.

* använder redan; Allt fixades som utlovat.

Och ett ganska vanligt fall är när förfrågningar kommer från API:et. Till exempel skapade du någon form av din egen tjänst. Och om någon behöver din tjänst, då öppnar du API:t och bokstavligen två dagar senare ser du att något obegripligt händer. Allt är överbelastat och det kommer in några hemska förfrågningar som aldrig borde ha hänt.

Och det finns bara en lösning. Om du har öppnat API:et måste du klippa det. Till exempel införa någon form av kvotering. Det finns inga andra normala alternativ. Annars kommer de genast att skriva ett manus och det blir problem.

Och ClickHouse har en speciell funktion - kvotberäkning. Dessutom kan du överföra din kvotnyckel. Detta är till exempel det interna användar-ID:t. Och kvoter kommer att beräknas oberoende för var och en av dem.

Nu en annan intressant sak. Detta är manuell replikering.

Jag känner till många fall där, trots att ClickHouse har inbyggt replikeringsstöd, människor replikerar ClickHouse manuellt.

Vad är principen? Du har en pipeline för databehandling. Och det fungerar självständigt, till exempel i olika datacenter. Du skriver samma data på samma sätt i ClickHouse. Det är sant att praxis visar att data fortfarande kommer att skilja sig på grund av vissa funktioner i din kod. Jag hoppas att den finns i din.

Och från tid till annan måste du fortfarande synkronisera manuellt. Till exempel, en gång i månaden gör administratörer rsync.

Faktum är att det är mycket lättare att använda replikeringen som är inbyggd i ClickHouse. Men det kan finnas några kontraindikationer, för för detta måste du använda ZooKeeper. Jag ska inte säga något dåligt om ZooKeeper, i princip fungerar systemet, men det händer att folk inte använder det på grund av java-fobi, eftersom ClickHouse är ett så bra system, skrivet i C++, som du kan använda och allt kommer att bli bra. Och ZooKeeper är i java. Och på något sätt vill du inte ens titta, men då kan du använda manuell replikering.

ClickHouse är ett praktiskt system. Hon tar hänsyn till dina behov. Om du har manuell replikering kan du skapa en distribuerad tabell som tittar på dina manuella repliker och gör en failover mellan dem. Och det finns till och med ett speciellt alternativ som låter dig undvika floppar, även om dina linjer systematiskt divergerar.

Ytterligare problem kan uppstå om du använder primitiva bordsmotorer. ClickHouse är en konstruktör som har en massa olika bordsmotorer. För alla allvarliga fall, som skrivet i dokumentationen, använd tabeller från MergeTree-familjen. Och allt annat - det är så, för enskilda fall eller för tester.

I en MergeTree-tabell behöver du inte ha något datum och tid. Du kan fortfarande använda den. Om det inte finns något datum och tid, skriv att standard är 2000. Detta kommer att fungera och kommer inte att kräva resurser.

Och i den nya versionen av servern kan du till och med ange att du har anpassad partitionering utan en partitionsnyckel. Det blir samma sak.

Å andra sidan kan du använda primitiva bordsmotorer. Fyll till exempel i uppgifterna en gång och titta, vrid och radera. Du kan använda Log.

Eller att lagra små volymer för mellanbehandling är StripeLog eller TinyLog.

Minne kan användas om mängden data är liten och du kan helt enkelt snurra något i RAM-minnet.

ClickHouse gillar inte renormaliserad data.

Här är ett typiskt exempel. Detta är ett stort antal webbadresser. Du lägger dem i nästa tabell. Och sedan bestämde de sig för att göra JOIN med dem, men detta kommer inte att fungera, som regel, eftersom ClickHouse bara stöder Hash JOIN. Om det inte finns tillräckligt med RAM-minne för mycket data som behöver anslutas, så fungerar inte JOIN*.

Om data är av hög kardinalitet, oroa dig inte, lagra den i en denormaliserad form, webbadresserna är direkt på plats i huvudtabellen.

* och nu har ClickHouse också en merge join, och den fungerar under förhållanden där mellanliggande data inte passar in i RAM-minnet. Men detta är ineffektivt och rekommendationen förblir i kraft.

Ett par exempel till, men jag tvivlar redan på om de är antimönster eller inte.

ClickHouse har ett känt fel. Den vet inte hur man uppdaterar*. På vissa sätt är detta till och med bra. Om du har några viktiga uppgifter, till exempel bokföring, kommer ingen att kunna skicka det, eftersom det inte finns några uppdateringar.

* stöd för uppdatering och radering i batchläge har lagts till för länge sedan.

Men det finns några speciella sätt som tillåter uppdateringar som i bakgrunden. Till exempel tabeller som ReplaceMergeTree. De gör uppdateringar under bakgrundssammanslagningar. Du kan tvinga fram detta med hjälp av optimeringstabell. Men gör inte detta för ofta, eftersom det kommer att skriva över partitionen helt.

Distribuerade JOINs i ClickHouse hanteras också dåligt av frågeplaneraren.

Dåligt, men ibland ok.

Använder endast ClickHouse för att läsa tillbaka data med select*.

Jag skulle inte rekommendera att använda ClickHouse för krångliga beräkningar. Men detta är inte helt sant, eftersom vi redan går bort från denna rekommendation. Och vi har nyligen lagt till möjligheten att tillämpa maskininlärningsmodeller i ClickHouse - Catboost. Och det stör mig för jag tänker: "Vilken fasa. Så här många cykler per byte blir det! Jag hatar verkligen att slösa klockor på bytes.

Men var inte rädd, installera ClickHouse, allt kommer att bli bra. Om något så har vi en gemenskap. Förresten, gemenskapen är du. Och om du har några problem kan du åtminstone gå in på vår chatt, och förhoppningsvis hjälper de dig.

frågor

Tack för rapporten! Var kan jag klaga på att ClickHouse kraschar?

Du kan klaga till mig personligen just nu.

Jag började nyligen använda ClickHouse. Jag tappade omedelbart cli-gränssnittet.

Du har tur.

Lite senare kraschade jag servern med ett litet urval.

Du har talang.

Jag öppnade en GitHub-bugg, men den ignorerades.

Vi kommer att se.

Alexey lurade mig att delta i rapporten och lovade att berätta för mig hur du kommer åt data inuti.

Mycket enkelt.

Jag insåg detta igår. Mer detaljer.

Det finns inga hemska knep där. Det är bara block-för-block-komprimering. Standard är LZ4, du kan aktivera ZSTD*. Blockerar från 64 kilobyte till 1 megabyte.

* det finns också stöd för specialiserade komprimeringskodekar som kan användas i en kedja med andra algoritmer.

Är blocken bara rådata?

Inte helt rå. Det finns arrayer. Om du har en numerisk kolumn, placeras siffror i en rad i en matris.

Kusten är klar.

Alexey, ett exempel som var med uniqExact över IP:er, dvs det faktum att uniqExact tar längre tid att beräkna med rader än med siffror, och så vidare. Tänk om vi använder en finta med öronen och kasta vid korrekturläsningen? Det vill säga, du verkar ha sagt att på vår disk är det inte särskilt annorlunda. Om vi ​​läser rader från disk och cast, blir våra aggregat snabbare eller inte? Eller kommer vi fortfarande att vinna lite här? Det verkar för mig att du testat detta, men av någon anledning inte angett det i riktmärket.

Jag tror att det blir långsammare än utan casting. I det här fallet måste IP-adressen analyseras från strängen. Naturligtvis, på ClickHouse är vår IP-adressanalys också optimerad. Vi försökte mycket, men där har du siffrorna skrivna i tiotusendel. Väldigt obekvämt. Å andra sidan kommer uniqExact-funktionen att arbeta långsammare på strängar, inte bara för att dessa är strängar, utan också för att en annan specialisering av algoritmen är vald. Strängar bearbetas helt enkelt annorlunda.

Vad händer om vi tar en mer primitiv datatyp? Vi skrev till exempel ner användar-id, som vi har i, skrev ner det som en rad och sedan förvrängde det, blir det roligare eller inte?

Jag tvivlar. Jag tror att det kommer att bli ännu tråkigare, för trots allt är det ett allvarligt problem att analysera siffror. Det förefaller mig som om den här kollegan till och med gav en rapport om hur svårt det är att analysera siffror i tiotusendelsform, men kanske inte.

Alexey, tack så mycket för rapporten! Och tack så mycket för ClickHouse! Jag har en fråga om planerna. Finns det några planer på en funktion för att uppdatera ordböcker ofullständigt?

Det vill säga en partiell omstart?

Jaja. Som möjligheten att ställa in ett MySQL-fält där, dvs uppdatera efter så att endast denna data laddas om ordboken är väldigt stor.

En mycket intressant funktion. Och jag tror att någon person föreslog det i vår chatt. Kanske var det till och med du.

Jag tror inte det.

Jättebra, nu visar det sig att det finns två förfrågningar. Och du kan sakta börja göra det. Men jag vill genast varna dig för att den här funktionen är ganska enkel att implementera. Det vill säga, i teorin behöver du bara skriva versionsnumret i tabellen och sedan skriva: version mindre än så och så. Det betyder att vi med största sannolikhet kommer att erbjuda detta till entusiaster. Är du en entusiast?

Ja, men tyvärr inte i C++.

Vet dina kollegor hur man skriver i C++?

Jag hittar någon.

Bra*.

* funktionen lades till två månader efter rapporten - författaren till frågan utvecklade den och skickade sin dra förfrågan.

Tack!

Hallå! Tack för rapporten! Du nämnde att ClickHouse är väldigt bra på att konsumera alla tillgängliga resurser. Och talaren bredvid Luxoft pratade om sin lösning för Russian Post. Han sa att de verkligen gillade ClickHouse, men de använde det inte istället för sin huvudkonkurrent just för att det äter upp all CPU. Och de kunde inte koppla in den i sin arkitektur, till sin ZooKeeper med hamnarbetare. Är det möjligt att på något sätt begränsa ClickHouse så att det inte konsumerar allt som blir tillgängligt för det?

Ja, det är möjligt och väldigt enkelt. Om du vill konsumera färre kärnor är det bara att skriva set max_threads = 1. Och det är det, det kommer att utföra begäran i en kärna. Dessutom kan du ange olika inställningar för olika användare. Så inga problem. Och berätta för dina kollegor från Luxoft att det inte är bra att de inte hittade den här inställningen i dokumentationen.

Alexey, hej! Jag skulle vilja fråga om denna fråga. Det är inte första gången jag har hört att många människor börjar använda ClickHouse som lagring för loggar. I rapporten sa du att du inte skulle göra detta, d.v.s. du behöver inte lagra långa strängar. Vad tycker du om det?

För det första är stockar som regel inte långa strängar. Det finns naturligtvis undantag. Till exempel, någon tjänst skriven i java ger ett undantag, det loggas. Och så vidare i en oändlig loop, och utrymmet på hårddisken tar slut. Lösningen är väldigt enkel. Om linjerna är mycket långa, klipp sedan av dem. Vad betyder lång? Tiotals kilobyte är dåliga*.

* i de senaste versionerna av ClickHouse är "adaptive index granularity" aktiverad, vilket eliminerar problemet med att lagra långa rader för det mesta.

Är en kilobyte normalt?

Det är normalt.

Hallå! Tack för rapporten! Jag har redan frågat om detta i chatten, men jag kommer inte ihåg om jag fick svar. Finns det planer på att på något sätt utöka WITH-sektionen på samma sätt som CTE?

Inte än. Vår WITH-sektion är något oseriös. Det är som en liten funktion för oss.

Jag förstår. Tack!

Tack för rapporten! Mycket intressant! Global fråga. Finns det några planer på att ändra dataradering, kanske i form av någon form av stubbar?

Nödvändigtvis. Detta är vår första uppgift i vår kö. Vi funderar nu aktivt på hur vi ska göra allt korrekt. Och du bör börja trycka på tangentbordet*.

* tryckte på knapparna på tangentbordet och gjorde allt.

Kommer detta att påverka systemets prestanda på något sätt eller inte? Kommer insättningen att gå lika snabbt som nu?

Kanske kommer själva borttagningarna och själva uppdateringarna att vara mycket tunga, men detta kommer inte att påverka prestandan för urval eller prestandan för insatser.

Och en liten fråga till. Vid presentationen pratade du om primärnyckel. Följaktligen har vi partitionering, som är månadsvis som standard, eller hur? Och när vi ställer in ett datumintervall som passar in i en månad är det bara den här partitionen som läses, eller hur?

Ja.

En fråga. Om vi ​​inte kan välja någon primärnyckel, är det då korrekt att göra det specifikt enligt "Datum"-fältet så att det i bakgrunden blir mindre omarrangemang av denna data så att den passar på ett mer ordnat sätt? Om du inte har intervallfrågor och du inte ens kan välja någon primärnyckel, är det värt att ange ett datum i primärnyckeln?

Ja.

Kanske är det vettigt att lägga ett fält i primärnyckeln som kommer att komprimera data bättre om det sorteras efter detta fält. Till exempel användar-ID. Användare, till exempel, går till samma webbplats. I det här fallet anger du användar-ID och tid. Och då blir din data bättre komprimerad. När det gäller datumet, om du verkligen inte har och aldrig har intervallfrågor på datum, behöver du inte ange datumet i primärnyckeln.

OK tack så mycket!

Källa: will.com