HighLoad++, Yuri Nasretdinov (VKontakte): hur VK infogar data i ClickHouse från tiotusentals servrar

HighLoad++ Moskva 2018, kongresshallen. 9 november, 15:00

Sammanfattning och presentation: http://www.highload.ru/moscow/2018/abstracts/4066

Yuri Nasretdinov (VKontakte): rapporten kommer att tala om erfarenheten av att implementera ClickHouse i vårt företag - varför vi behöver det, hur mycket data vi lagrar, hur vi skriver det och så vidare.

Ytterligare material: använder Clickhouse som ersättning för ELK, Big Query och TimescaleDB

Yuri Nasretdinov: - Hej alla! Jag heter Yuri Nasretdinov, eftersom jag redan har blivit introducerad. Jag jobbar på VKontakte. Jag kommer att prata om hur vi infogar data i ClickHouse från vår serverflotta (tiotusentals).

Vad är stockar och varför samla in dem?

Vad vi kommer att berätta för dig: vad vi gjorde, varför vi behövde "ClickHouse", respektive varför vi valde det, vilken typ av prestanda du ungefär kan få utan att konfigurera något speciellt. Jag ska berätta mer om bufferttabeller, om problemen vi hade med dem och om våra lösningar som vi utvecklat från öppen källkod - KittenHouse och Lighthouse.

Varför behövde vi göra någonting alls (allt är alltid bra på VKontakte, eller hur?). Vi ville samla in felsökningsloggar (och det fanns hundratals terabyte data där), kanske på något sätt skulle det vara bekvämare att beräkna statistik; och vi har en flotta på tiotusentals servrar från vilka allt detta måste göras.

Varför bestämde vi oss? Vi hade nog lösningar för att lagra stockar. Här - det finns en sådan offentlig "Backend VK". Jag rekommenderar starkt att du prenumererar på den.

Vad är loggar? Detta är en motor som returnerar tomma arrayer. Motorer i VK är vad andra kallar mikrotjänster. Och här är ett leende klistermärke (ganska många likes). Hur så? Tja, lyssna vidare!

Vad kan användas för att lagra loggar? Det är omöjligt att inte nämna Hadup. Sedan till exempel Rsyslog (lagring av dessa loggar i filer). LSD. Vem vet vad LSD är? Nej, inte denna LSD. Lagra filer också. Tja, ClickHouse är ett konstigt alternativ.

Klickhus och konkurrenter: krav och möjligheter

Vad vill vi ha? Vi vill se till att vi inte behöver oroa oss för mycket om operationen, så att den fungerar direkt, helst med minimal konfiguration. Vi vill skriva mycket, och skriva snabbt. Och vi vill behålla den i alla möjliga månader, år, det vill säga under lång tid. Vi kanske vill förstå något problem som de kom till oss med och sa, "Något fungerar inte här," och det var 3 månader sedan), och vi vill kunna se vad som hände för 3 månader sedan " Datakomprimering – det är uppenbart varför det skulle vara ett plus – eftersom det minskar mängden utrymme det tar upp.

Och vi har ett så intressant krav: vi skriver ibland utdata från vissa kommandon (till exempel loggar), det kan vara mer än 4 kilobyte ganska enkelt. Och om den här saken fungerar över UDP, behöver den inte spendera ... den kommer inte att ha några "overhead" för anslutningen, och för ett stort antal servrar kommer detta att vara ett plus.

Låt oss se vad öppen källkod erbjuder oss. För det första har vi Logs Engine - det här är vår motor; Han kan i princip allt, han kan till och med skriva långa rader. Tja, det komprimerar inte data transparent - vi kan själva komprimera stora kolumner om vi vill... vi vill naturligtvis inte (om möjligt). Problemet är bara att han bara kan ge bort det som passar i hans minne; För att läsa resten måste du skaffa binloggen för denna motor och följaktligen tar det ganska lång tid.

Vilka andra alternativ finns det? Till exempel "Hadup". Enkel att använda... Vem tycker att Hadup är lätt att sätta upp? Självklart är det inga problem med inspelningen. När man läser uppstår ibland frågor. I princip skulle jag säga förmodligen inte, speciellt för stockar. Långtidslagring - naturligtvis, ja, datakomprimering - ja, långa strängar - det är klart att du kan spela in. Men inspelning från ett stort antal servrar... Du måste fortfarande göra något själv!

Rsyslog. Faktum är att vi använde det som ett backupalternativ så att vi kunde läsa det utan att dumpa binloggen, men det kan inte skriva långa rader, i princip kan det inte skriva mer än 4 kilobyte. Du måste göra datakomprimering på samma sätt själv. Läsning kommer från filer.

Sedan finns det "badushka"-utvecklingen av LSD. I huvudsak samma som "Rsyslog": det stöder långa strängar, men det kan inte fungera via UDP och faktiskt, på grund av detta, måste tyvärr en hel del saker skrivas om där. LSD behöver göras om för att kunna spela in från tiotusentals servrar.

Och här! Ett roligt alternativ är ElasticSearch. Hur säger man? Han är bra på att läsa, det vill säga han läser snabbt, men inte särskilt bra med att skriva. För det första, om den komprimerar data är den mycket svag. Troligtvis kräver en fullständig sökning större datastrukturer än den ursprungliga volymen. Det är svårt att operera och det uppstår ofta problem med det. Och, återigen, inspelning i Elastic - vi måste göra allt själva.

Här är ClickHouse naturligtvis ett idealiskt alternativ. Det enda är att inspelning från tiotusentals servrar är ett problem. Men det finns åtminstone ett problem, vi kan försöka lösa det på något sätt. Och resten av rapporten handlar om detta problem. Vilken typ av prestanda kan du förvänta dig av ClickHouse?

Hur ska vi sätta in den? MergeTree

Vem av er har inte hört eller känner till "ClickHouse"? Jag måste berätta för dig, eller hur? Väldigt snabbt. Insättningen där - 1-2 gigabit per sekund, skurar på upp till 10 gigabit per sekund kan faktiskt motstå denna konfiguration - det finns två 6-kärniga Xeoner (det vill säga inte ens de mest kraftfulla), 256 gigabyte RAM, 20 terabyte i RAID (ingen konfigurerad, standardinställningar). Alexey Milovidov, ClickHouse-utvecklare, sitter förmodligen där och gråter för att vi inte har konfigurerat någonting (allt fungerade så för oss). Följaktligen kan en skanningshastighet på, säg, cirka 6 miljarder linjer per sekund erhållas om data är väl komprimerad. Om du gillar % på en textsträng - 100 miljoner rader per sekund, det vill säga det verkar ganska snabbt.

Hur ska vi sätta in den? Tja, du vet att VK använder PHP. Vi kommer att infoga från varje PHP-arbetare via HTTP i "ClickHouse", i MergeTree-tabellen för varje post. Vem ser ett problem med detta upplägg? Av någon anledning räckte inte alla upp handen. Låt mig berätta för dig.

För det första finns det många servrar - följaktligen kommer det att finnas många anslutningar (dåliga). Då är det bättre att infoga data i MergeTree inte oftare än en gång per sekund. Och vem vet varför? Okej okej. Jag ska berätta lite mer om detta. En annan intressant fråga är att vi inte gör analyser, vi behöver inte berika data, vi behöver inte mellanliggande servrar, vi vill infoga direkt i "ClickHouse" (helst - ju mer direkt, desto bättre).

Följaktligen, hur görs infogning i MergeTree? Varför är det bättre att sätta in det inte oftare än en gång i sekunden eller mindre ofta? Faktum är att "ClickHouse" är en kolumnär databas och sorterar data i stigande ordning efter primärnyckeln, och när du gör en infogning skapas ett antal filer som är minst lika med antalet kolumner där data sorteras i stigande ordning för primärnyckeln (en separat katalog skapas, en uppsättning filer på disken för varje infogning). Sedan kommer nästa insättning, och i bakgrunden kombineras de till större "partitioner". Eftersom datan är sorterad är det möjligt att "sammanfoga" två sorterade filer utan att förbruka mycket minne.

Men, som du kanske gissar, om du skriver 10 filer för varje infogning kommer ClickHouse (eller din server) snabbt att sluta, så det rekommenderas att infoga i stora partier. Därför lanserade vi aldrig det första systemet i produktion. Vi lanserade omedelbart en, som här nr 2 har:

Föreställ dig här att det finns ungefär tusen servrar som vi har lanserat på, det finns bara PHP. Och på varje server finns vår lokala agent, som vi kallade "Kittenhouse", som upprätthåller en anslutning till "ClickHouse" och infogar data med några sekunders mellanrum. Infogar data inte i MergeTree, utan i en bufferttabell, som tjänar just till att undvika att infoga direkt i MergeTree direkt.

Arbeta med bufferttabeller

Vad det är? Bufferttabeller är ett minne som är söndert (det vill säga att det kan infogas i det ofta). De består av flera bitar, och var och en av bitarna fungerar som en oberoende buffert, och de spolas oberoende (om du har många bitar i bufferten kommer det att bli många insatser per sekund). Det är möjligt att läsa från dessa tabeller - då läser du föreningen av innehållet i bufferten och föräldratabellen, men för närvarande är skrivningen blockerad, så det är bättre att inte läsa därifrån. Och bufferttabeller visar mycket bra QPS, det vill säga upp till 3 tusen QPS kommer du inte att ha några problem alls när du infogar. Det är uppenbart att om servern tappar ström, så kan data gå förlorade, eftersom de bara lagrades i minnet.

Samtidigt komplicerar schemat med en buffert ALTER, eftersom du först måste släppa den gamla bufferttabellen med det gamla schemat (data kommer inte att försvinna någonstans, eftersom det kommer att tömmas innan tabellen raderas). Sedan "ändrar" du tabellen du behöver och skapar bufferttabellen igen. Följaktligen, även om det inte finns någon bufferttabell, kommer din data inte att flöda någonstans, men du kan ha den på disk åtminstone lokalt.

Vad är Kittenhouse och hur fungerar det?

Vad är KittenHouse? Detta är en proxy. Gissa vilket språk? Jag samlade de mest hypeämnena i min rapport - "Clickhouse", Go, jag kanske kommer ihåg något annat. Ja, det här är skrivet i Go, för jag vet inte riktigt hur man skriver i C, jag vill inte.

Följaktligen upprätthåller den en anslutning med varje server och kan skriva till minnet. Till exempel, om vi skriver felloggar till Clickhouse, och om Clickhouse inte har tid att infoga data (trots allt, om det skrivs för mycket), så sväller vi inte minnet - vi slänger helt enkelt ut resten. För om vi skriver flera gigabitar per sekund av fel, då kan vi förmodligen kasta ut några. Kittenhouse kan göra detta. Dessutom kan den utföra pålitlig leverans, det vill säga skriva till disk på den lokala maskinen och en gång varje gång (där, en gång varannan sekund) försöker den leverera data från den här filen. Och först använde vi det vanliga Values-formatet - inte något binärt format, ett textformat (som i vanlig SQL).

Men så hände detta. Vi använde pålitlig leverans, skrev loggar och bestämde oss sedan (det var ett villkorligt testkluster)... Det lades ut i flera timmar och togs upp igen, och en insättning startade från tusen servrar - det visade sig att Clickhouse fortfarande hade en "Tråd vid anslutning" - följaktligen, i tusen anslutningar, leder en aktiv infogning till ett belastningsmedelvärde på servern på cirka ett och ett halvt tusen. Överraskande nog accepterade servern förfrågningar, men uppgifterna infogades fortfarande efter en tid; men det var väldigt svårt för servern att servera det...

Lägg till nginx

En sådan lösning för tråden per anslutningsmodell är nginx. Vi installerade nginx framför Clickhouse, satte samtidigt upp balansering för två repliker (vår insättningshastighet ökade med 2 gånger, även om det inte är ett faktum att så borde vara fallet) och begränsade antalet anslutningar till Clickhouse, till uppströms och följaktligen fler än i 50 anslutningar verkar det inte vara någon mening med att infoga.

Sedan insåg vi att detta schema generellt har nackdelar, eftersom vi bara har en nginx här. Följaktligen, om denna nginx kraschar, trots förekomsten av repliker, förlorar vi data eller, åtminstone, inte skriver någonstans. Därför gjorde vi vår egen lastbalansering. Vi insåg också att "Clickhouse" fortfarande är lämplig för loggar, och "demonen" började också skriva sina loggar i "Clickhouse" - väldigt bekvämt, om jag ska vara ärlig. Vi använder det fortfarande för andra "demoner".

Sedan upptäckte vi det här intressanta problemet: om du använder en icke-standard metod för att infoga i SQL-läge, tvingar den fram en fullfjädrad AST-baserad SQL-parser, som är ganska långsam. Därför har vi lagt till inställningar för att säkerställa att detta aldrig händer. Vi gjorde lastbalansering, hälsokontroller, så att om en dör lämnar vi fortfarande data. Vi har nu ganska många bord som vi behöver för att ha olika Clickhouse-kluster. Och vi började också tänka på andra användningsområden - till exempel ville vi skriva loggar från nginx-moduler, men de vet inte hur de ska kommunicera med vår RPC. Tja, jag skulle vilja lära dem hur man skickar åtminstone på något sätt - till exempel att ta emot händelser på localhost via UDP och sedan vidarebefordra dem till Clickhouse.

Ett steg bort från lösningen

Det slutliga schemat började se ut så här (den fjärde versionen av detta schema): på varje server framför Clickhouse finns nginx (på samma server) och det skickar helt enkelt förfrågningar till localhost med en gräns på antalet anslutningar på 50 bitar. Och det här schemat fungerade redan ganska bra, allt var ganska bra med det.

Vi levde så här i ungefär en månad. Alla var nöjda, de la till tabeller, de la till, de la till... Generellt visade det sig att sättet vi la till bufferttabeller inte var särskilt optimalt (låt oss uttrycka det så). Vi gjorde 16 stycken i varje bord och ett flashintervall på ett par sekunder; vi hade 20 bord och varje bord fick 8 inlägg per sekund - och vid denna tidpunkt började "Clickhouse"... rekorden började sakta ner. De gick inte ens igenom... Nginx hade som standard en så intressant sak att om anslutningar slutade uppströms, så returnerade den helt enkelt "502" till alla nya förfrågningar.

Och här har vi (jag tittade precis på loggarna i själva Clickhouse) ungefär en halv procent av förfrågningarna misslyckades. Följaktligen var diskutnyttjandet högt, det fanns många sammanslagningar. Vad gjorde jag? Naturligtvis brydde jag mig inte om att ta reda på varför exakt anslutningen och uppströms slutade.

Ersätter nginx med en omvänd proxy

Jag bestämde mig för att vi måste hantera detta själva, vi behöver inte lämna det till nginx - nginx vet inte vilka tabeller som finns i Clickhouse, och jag ersatte nginx med en omvänd proxy, som jag också skrev själv.

Vad gör han? Det fungerar baserat på fasthttp-biblioteket "goshnoy", det vill säga snabbt, nästan lika snabbt som nginx. Förlåt, Igor, om du är närvarande här (notera: Igor Sysoev är en rysk programmerare som skapade nginx-webbservern). Den kan förstå vilken typ av frågor dessa är – INSERT eller SELECT – följaktligen har den olika anslutningspooler för olika typer av frågor.

Följaktligen, även om vi inte har tid att slutföra insättningsförfrågningarna, kommer "valen" att passera, och vice versa. Och den grupperar data i bufferttabeller - med en liten buffert: om det fanns några fel, syntaxfel och så vidare - så att de inte skulle påverka resten av datan i hög grad, för när vi helt enkelt infogade i bufferttabeller, hade liten "bachi", och alla syntaxfel påverkade bara denna lilla bit; och här kommer de redan att påverka en stor buffert. Liten är 1 megabyte, det vill säga inte så liten.

Att infoga en synkronisering och i huvudsak ersätta nginx, gör i princip samma sak som nginx gjorde tidigare - du behöver inte ändra det lokala "Kattungehuset" för detta. Och eftersom det använder fasthttp är det väldigt snabbt - du kan göra mer än 100 tusen förfrågningar per sekund för enstaka infogning via en omvänd proxy. Teoretiskt sett kan du infoga en rad åt gången i kittenhouse omvänd proxy, men det gör vi naturligtvis inte.

Schemat började se ut så här: "Kattungehus", den omvända proxyn grupperar många förfrågningar i tabeller och i sin tur infogar bufferttabellerna dem i de viktigaste.

Killer är en tillfällig lösning, Kitten är permanent

Detta är ett intressant problem... Har någon av er använt fasthttp? Vem använde fasthttp med POST-förfrågningar? Förmodligen borde detta verkligen inte ha gjorts, eftersom det buffrar förfrågningskroppen som standard, och vår buffertstorlek var inställd på 16 megabyte. Insättningen slutade att hänga med någon gång, och 16 megabyte bitar började anlända från alla tiotusentals servrar, och de buffrades alla i minnet innan de skickades till Clickhouse. Följaktligen tog minnet slut, Out-Of-Memory Killer kom och dödade den omvända proxyn (eller "Clickhouse", som teoretiskt kunde "äta" mer än den omvända proxyn). Cykeln upprepade sig. Inte ett särskilt trevligt problem. Även om vi snubblade över detta först efter flera månaders drift.

Vad jag har gjort? Återigen, jag gillar inte riktigt att förstå vad som hände exakt. Jag tycker att det är ganska självklart att man inte ska buffra i minnet. Jag kunde inte patcha fasthttp, även om jag försökte. Men jag hittade ett sätt att göra det så att det inte behövdes patcha något, och jag kom på en egen metod i HTTP - jag kallade den KITTEN. Tja, det är logiskt - "VK", "Kattunge" ... Vad mer? ..

Om en förfrågan kommer till servern med Kitten-metoden, bör servern svara "mjau" - logiskt. Om han svarar på detta, så anses det att han förstår detta protokoll, och då avlyssnar jag anslutningen (fasthttp har en sådan metod), och anslutningen går in i "rå"-läge. Varför behöver jag det? Jag vill kontrollera hur läsning från TCP-anslutningar sker. TCP har en underbar egenskap: om ingen läser från andra sidan, börjar skrivningen vänta, och minnet spenderas inte särskilt på detta.

Och så läste jag från ett 50-tal klienter åt gången (från femtio eftersom femtio definitivt borde räcka, även om kursen kommer från en annan DC)... Konsumtionen har minskat med detta tillvägagångssätt minst 20 gånger, men jag, för att vara ärlig , Jag kunde inte mäta exakt vilken tid, eftersom det redan är meningslöst (det har redan nått felnivån). Protokollet är binärt, det vill säga det innehåller tabellnamnet och data; det finns inga http-rubriker, så jag använde inte en webbsocket (jag behöver inte kommunicera med webbläsare - jag gjorde ett protokoll som passar våra behov). Och allt blev bra med honom.

Bufferttabellen är trist

Nyligen stötte vi på en annan intressant egenskap hos bufferttabeller. Och detta problem är redan mycket mer smärtsamt än de andra. Låt oss föreställa oss denna situation: du använder redan aktivt Clickhouse, du har dussintals Clickhouse-servrar och du har några förfrågningar som tar väldigt lång tid att läsa (låt oss säga mer än 60 sekunder); och du kommer och gör Alter i detta ögonblick... Under tiden kommer "selects" som började före "Alter" inte att inkluderas i den här tabellen, "Alter" kommer inte att starta - förmodligen några funktioner i hur "Clickhouse" fungerar i denna plats. Kanske kan detta fixas? Eller är det omöjligt?

Generellt sett är det klart att detta i verkligheten inte är ett så stort problem, men med bufferttabeller blir det mer smärtsamt. För om, låt oss säga, dina "Alter" timeouts (och det kan timeout på en annan värd - inte på din, utan på en replik, till exempel), då... Du tog bort bufferttabellen, din "Alter" ( eller någon annan värd) tog timeout. sedan har ett "Alter"-fel inträffat) - du måste fortfarande se till att data fortsätter att skrivas: du skapar bufferttabellerna tillbaka (enligt samma schema som den överordnade tabellen), sedan "Alter" går igenom, slutar trots allt, och bufferten tabellen börjar skilja sig i schema från föräldern. Beroende på vad "Alter" var, kan infogningen inte längre gå till den här bufferttabellen - detta är väldigt tråkigt.

Det finns också ett sådant tecken (kanske någon har märkt det) - det kallas query_thread_log i nya versioner av Clickhouse. Som standard fanns det en i någon version. Här har vi samlat på oss 840 miljoner rekord på ett par månader (100 gigabyte). Detta beror på det faktum att "inlägg" skrevs där (kanske nu, förresten, de är inte skrivna). Som jag sa till dig är våra "inlägg" små - vi hade många "inlägg" i bufferttabellerna. Det är tydligt att detta är inaktiverat - jag berättar bara vad jag såg på vår server. Varför? Detta är ytterligare ett argument mot att använda bufferttabeller! Spotty är väldigt ledsen.

Vem visste att den här killen hette Spotty? VK-anställda räckte upp handen. OK.

Om planerna för "KitttenHouse"

Vanligtvis delas inte planer, eller hur? Plötsligt kommer du inte att uppfylla dem och kommer inte att se särskilt bra ut i andras ögon. Men jag tar risken! Vi vill göra följande: bufferttabeller, verkar det som jag, fortfarande är en krycka och vi måste buffra insättningen själva. Men vi vill fortfarande inte buffra den på disken, så vi buffrar insättningen i minnet.

Följaktligen, när en "insert" görs, kommer den inte längre att vara synkron - den kommer redan att fungera som en bufferttabell, infogas i den överordnade tabellen (nåja, någon dag senare) och rapporterar via en separat kanal vilka inserts som har passerat och vilka har inte.

Varför kan jag inte lämna den synkrona insatsen? Det är mycket bekvämare. Faktum är att om du infogar från 10 tusen värdar, så är allt bra - du kommer att få lite från varje värd, du sätter in där en gång i sekunden, allt är bra. Men jag skulle vilja att det här schemat skulle fungera, till exempel från två maskiner, så att du kan ladda ner i hög hastighet - kanske inte få ut maximalt av Clickhouse, men skriva minst 100 megabyte per sekund från en maskin genom en omvänd proxy - detta måste schemat skalas till både stora och små kvantiteter, så vi kan inte vänta en sekund för varje infogning, så det måste vara asynkront. Och på samma sätt bör asynkrona bekräftelser komma efter att insättningen är klar. Vi får veta om det gick igenom eller inte.

Det viktigaste är att i detta schema vet vi säkert om insättningen ägde rum eller inte. Föreställ dig den här situationen: du har en bufferttabell, du skrev något i den, och låt oss säga att tabellen gick in i skrivskyddat läge och försökte tömma bufferten. Vart ska uppgifterna ta vägen? De kommer att stanna kvar i bufferten. Men vi kan inte vara säkra på detta - tänk om det finns något annat fel, på grund av vilket data inte kommer att finnas kvar i bufferten... (Att tilltalar Alexey Milovidov, Yandex, ClickHouse-utvecklare) Eller kommer det att finnas kvar? Alltid? Alexey övertygar oss om att allt kommer att bli bra. Vi har ingen anledning att inte tro honom. Men ändå: om vi inte använder bufferttabeller kommer det inte att vara några problem med dem. Att skapa dubbelt så många bord är också obekvämt, även om det i princip inte är några stora problem. Det här är planen.

Låt oss prata om läsning

Låt oss nu prata om läsning. Vi skrev också vårt eget verktyg här. Det verkar, ja, varför skriva ditt eget instrument här? .. Och vem använde Tabix? På något sätt räckte få människor upp handen... Och vem är nöjd med Tabix prestanda? Tja, vi är inte nöjda med det, och det är inte särskilt bekvämt för att visa data. Det är bra för analyser, men bara för visning är det uppenbarligen inte optimerat. Så jag skrev mitt eget, mitt eget gränssnitt.

Det är väldigt enkelt - det kan bara läsa data. Han vet inte hur man visar grafik, han vet inte hur man gör någonting. Men det kan visa vad vi behöver: till exempel hur många rader som finns i tabellen, hur mycket utrymme den tar upp (utan att dela upp det i kolumner), det vill säga ett väldigt grundläggande gränssnitt är vad vi behöver.

Och det ser väldigt likt Sequel Pro, men bara gjort på Twitters Bootstrap, och den andra versionen. Du frågar: "Yuri, varför på den andra versionen?" Vilket år? 2018? I allmänhet gjorde jag detta för ganska länge sedan för "Muscle" (MySQL) och ändrade bara ett par rader i frågorna där, och det började fungera för "Clickhouse", vilket särskilt tack! Eftersom parsern är väldigt lik "muskeln", och frågorna är väldigt lika - mycket bekvämt, särskilt i början.

Tja, det kan filtrera tabeller, kan visa strukturen och innehållet i tabellen, låter dig sortera, filtrera efter kolumner, visar frågan som resulterade i resultatet, de berörda raderna (hur många som ett resultat), det vill säga grundläggande saker för att visa data. Ganska snabbt.

Det finns också en redaktör. Jag försökte ärligt talat stjäla hela redaktören från Tabix, men jag kunde inte. Men på något sätt fungerar det. I princip är det allt.

"Clickhouse" är lämplig för hålor

Jag vill berätta att Clickhouse, trots alla beskrivna problem, lämpar sig väldigt bra för stockar. Viktigast av allt, det löser vårt problem - det är väldigt snabbt och låter dig filtrera loggar efter kolumner. I princip har bufferttabeller inte fungerat bra, men oftast vet ingen varför... Kanske vet du nu bättre var du kommer att få problem.

TCP? I allmänhet är det i VK vanligt att använda UDP. Och när jag använde TCP... Naturligtvis var det ingen som sa till mig: ”Yuri, vad pratar du om! Du kan inte, du behöver UDP." Det visade sig att TCP inte är så läskigt. Det enda är att om du har tiotusentals aktiva föreningar som du skriver måste du förbereda det lite mer noggrant; men det är möjligt och ganska enkelt.

Jag lovade att lägga upp "Kattungehus" och "Lighthouse" på HighLoad Siberia om alla prenumererade på vår offentliga "VK backend"... Och du vet, alla prenumererade inte... Jag kommer naturligtvis inte kräva att du prenumererar på vår offentlig. Det är fortfarande för många av er, någon kan till och med bli förolämpad, men ändå, prenumerera (och här måste jag göra ögon som en katt). Det är länk till den förresten. Tack så mycket! Github är vår just här. Med Clickhouse blir ditt hår mjukt och silkeslent.

Ledande: - Vänner, nu till frågor. Direkt efter presenterar vi uppskattningsbeviset och din rapport om VHS.

Yuri Nasretdinov (nedan kallad YN): – Hur kunde du spela in min rapport på VHS om den bara tog slut?

Ledande: – Du kan inte heller helt bestämma hur "Clickhouse" kommer att fungera eller inte! Vänner, 5 minuter för frågor!

frågor

Fråga från publiken (nedan kallad Q): - God eftermiddag. Tack så mycket för rapporten. Jag har två frågor. Jag börjar med något oseriöst: påverkar antalet bokstäver t i namnet "Kattungehus" i diagrammen (3, 4, 7...) katternas tillfredsställelse?

YN: - Kvantitet av vad?

З: – Bokstaven t. Det finns tre t, någonstans runt tre t.

YN: - Fixade jag det inte? Jo, självklart gör det det! Det här är olika produkter - jag har bara lurat dig hela tiden. Okej, jag skojar - det spelar ingen roll. Ah, precis här! Nej, det är samma sak, jag gjorde ett stavfel.

З: - Tack. Den andra frågan är allvarlig. Såvitt jag förstår, i Clickhouse, lever bufferttabeller uteslutande i minnet, buffras inte till disk och är följaktligen inte persistenta.

YN: - Ja.

З: – Och samtidigt buffrar din klient till disk, vilket innebär en viss garanti för leverans av samma loggar. Men detta är på inget sätt garanterat på Clickhouse. Förklara hur garantin utförs, på grund av vad?.. Här är denna mekanism mer detaljerat

YN: – Ja, teoretiskt sett finns det inga motsägelser här, för när Clickhouse faller kan man faktiskt upptäcka det på en miljon olika sätt. Om Clickhouse kraschar (om det slutar fel) kan du grovt sett spola tillbaka lite av din logg som du skrivit ner och börja från det ögonblick då allt var helt okej. Låt oss säga att du spolar tillbaka en minut, det vill säga det anses att du har spolat allt på en minut.

З: – Det vill säga, "Kattungehus" håller fönstret längre och kan, vid ett fall, känna igen det och spola tillbaka det?

YN: – Men det här är i teorin. I praktiken gör vi inte detta, och pålitlig leverans är från noll till oändligt. Men i genomsnitt en. Vi är nöjda med att om Clickhouse kraschar av någon anledning eller servrarna "startar om" så tappar vi lite. I alla andra fall kommer ingenting att hända.

З: - Hallå. Redan från början verkade det för mig att du verkligen skulle använda UDP från början av rapporten. Du har http, allt det där... Och de flesta av problemen som du beskrev, som jag förstår det, orsakades av just den här lösningen...

YN: – Vad använder vi TCP?

З: – I huvudsak ja.

YN: - Nej.

З: – Det var med fasthttp du hade problem, med anslutningen du hade problem. Om du bara hade använt UDP hade du sparat lite tid. Tja, det skulle vara problem med långa meddelanden eller något annat...

YN: - Med vad?

З: – Med långa meddelanden, eftersom det kanske inte passar in i MTU:n, något annat... Tja, det kan finnas egna problem. Frågan är: varför inte UDP?

YN: – Jag tror att författarna som utvecklade TCP/IP är mycket smartare än mig och vet bättre än jag hur man serialiserar paket (så att de går), samtidigt justerar sändningsfönstret, inte överbelastas nätverket, ger feedback om vad läses inte, räknas inte på andra sidan... Alla dessa problem skulle enligt min mening existera i UDP, bara jag skulle behöva skriva ännu mer kod än jag redan skrivit för att implementera samma sak själv och med största sannolikhet dåligt. Jag gillar inte ens att skriva i C, än mindre där...

З: - Bara bekvämt! Skickades ok och vänta inte på någonting - det är helt asynkront. Ett meddelande kom tillbaka om att allt var bra - det betyder att det kom; Om det inte kommer betyder det att det är dåligt.

YN: – Jag behöver båda – Jag måste kunna skicka både med leveransgaranti och utan leveransgaranti. Det är två olika scenarier. Jag behöver inte förlora några loggar eller inte förlora dem inom rimliga gränser.

З: – Jag kommer inte att slösa tid. Detta måste diskuteras mer. Tack.

Ledande: – Vem har frågor – hands to the sky!

З: - Hej, jag heter Sasha. Någonstans i mitten av rapporten infann sig en känsla av att det förutom TCP gick att använda en färdig lösning – någon slags Kafka.

YN: – Tja... Jag sa till dig att jag inte vill använda mellanliggande servrar, för... i Kafka visar det sig att vi har tiotusen värdar; i själva verket har vi fler - tiotusentals värdar. Det kan också vara smärtsamt att göra med Kafka utan några fullmakter. Dessutom, viktigast av allt, det ger fortfarande "latency", det ger extra värdar som du behöver ha. Men jag vill inte ha dem - jag vill...

З: "Men till slut blev det så ändå."

YN: – Nej, det finns inga värdar! Allt detta fungerar på Clickhouse-värdar.

З: - Tja, och "Kattungehuset", vilket är tvärtom - var bor han?

YN: – På Clickhouse-värden skriver den ingenting till disken.

З: - Låt oss anta.

Ledande: - Är du nöjd? Kan vi ge dig lön?

З: - Jo det kan du. Faktum är att det finns många kryckor för att få samma sak, och nu - det tidigare svaret på ämnet TCP motsäger, enligt min mening, denna situation. Det känns bara som att allt kunde ha gjorts på mina knän på mycket kortare tid.

YN: – Och även varför jag inte ville använda Kafka, för det fanns ganska många klagomål i Clickhouse Telegram-chatten om att till exempel meddelanden från Kafka gick förlorade. Inte från Kafka själv, utan i integrationen av Kafka och Clickhaus; eller något hängde inte ihop där. Grovt sett skulle det vara nödvändigt att skriva en klient till Kafka då. Jag tror inte att det kan finnas en enklare eller mer pålitlig lösning.

З: – Säg mig, varför provade du inte några köer eller någon slags gemensam buss? Eftersom du säger att man med asynkroni skulle kunna skicka själva loggarna genom kön och ta emot svaret asynkront genom kön?

YN: – Vänligen föreslå vilka köer som kan användas?

З: – Alla, även utan garanti för att de är i ordning. Någon sorts Redis, RMQ...

YN: – Jag har en känsla av att Redis med största sannolikhet inte kommer att kunna dra en sådan insättningsvolym ens på en värd (i betydelsen flera servrar) som drar ut Clickhouse. Jag kan inte backa upp detta med några bevis (jag har inte benchmarkat det), men det verkar för mig att Redis inte är den bästa lösningen här. I princip kan detta system betraktas som en improviserad meddelandekö, men som endast är skräddarsydd för "Clickhouse"

Ledande: – Yuri, tack så mycket. Jag föreslår att avsluta frågorna och svaren här och säga vem av dem som ställde frågan vi ska ge boken till.

YN: – Jag skulle vilja ge en bok till den första personen som ställde en fråga.

Ledande: - Underbar! Bra! Fantastisk! Tack så mycket!

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, moln VPS för utvecklare från $4.99, en unik analog av ingångsservrar, som uppfanns av oss för dig: Hela sanningen om VPS (KVM) E5-2697 v3 (6 kärnor) 10GB DDR4 480GB SSD 1Gbps från $19 eller hur delar man en server? (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 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV från $199 i Nederländerna! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - från $99! Läs om Hur man bygger infrastructure corp. klass med användning av Dell R730xd E5-2650 v4-servrar värda 9000 XNUMX euro för en slant?

Källa: will.com