HighLoad++ Moskva 2018, Kongressalen. 9. november klokken 15
Abstracts og præsentation:
Yuri Nasretdinov (VKontakte): rapporten vil tale om oplevelsen af at implementere ClickHouse i vores virksomhed - hvorfor vi har brug for det, hvor meget data vi gemmer, hvordan vi skriver det, og så videre.
Yderligere materialer:
Yuri Nasretdinov: - Hej alle! Mit navn er Yuri Nasretdinov, da jeg allerede er blevet introduceret. Jeg arbejder hos VKontakte. Jeg vil tale om, hvordan vi indsætter data i ClickHouse fra vores serverflåde (ti tusindvis).
Hvad er logfiler og hvorfor indsamle dem?
Hvad vi vil fortælle dig: hvad vi gjorde, hvorfor vi havde brug for "ClickHouse", hhv. hvorfor vi valgte det, hvilken slags ydeevne du cirka kan få uden at konfigurere noget specielt. Jeg vil fortælle dig yderligere om buffertabeller, om de problemer, vi havde med dem, og om vores løsninger, som vi udviklede fra open source - KittenHouse og Lighthouse.
Hvorfor skulle vi overhovedet gøre noget (alt er altid godt på VKontakte, ikke?). Vi ønskede at indsamle fejlretningslogfiler (og der var hundredvis af terabyte data der), måske ville det på en eller anden måde være mere bekvemt at beregne statistik; og vi har en flåde på titusindvis af servere, hvorfra alt dette skal gøres.
Hvorfor besluttede vi os? Vi havde sikkert løsninger til opbevaring af logs. Her - der er sådan en offentlig "Backend VK". Jeg kan varmt anbefale at abonnere på det.
Hvad er logs? Dette er en motor, der returnerer tomme arrays. Motorer i VK er, hvad andre kalder mikrotjenester. Og her er et smilende klistermærke (ret mange likes). Hvordan det? Nå, hør videre!
Hvad kan bruges til at opbevare logfiler? Det er umuligt ikke at nævne Hadup. Så for eksempel Rsyslog (lagring af disse logfiler i filer). LSD. Hvem ved, hvad LSD er? Nej, ikke denne LSD. Gem filer også. Nå, ClickHouse er en mærkelig mulighed.
Klikhus og konkurrenter: krav og muligheder
Hvad vil vi? Vi vil gerne sikre, at vi ikke skal bekymre os for meget om betjeningen, så den fungerer ud af boksen, helst med minimal konfiguration. Vi vil skrive meget, og skrive hurtigt. Og vi vil beholde den i alle mulige måneder, år, altså i lang tid. Vi vil måske gerne forstå et eller andet problem, som de kom til os med og sagde, "Der er noget, der ikke fungerer her," og det var for 3 måneder siden), og vi vil gerne være i stand til at se, hvad der skete for 3 måneder siden. Datakomprimering - det er klart, hvorfor det ville være et plus - fordi det reducerer mængden af plads, det optager.
Og vi har sådan et interessant krav: vi skriver nogle gange outputtet af nogle kommandoer (for eksempel logfiler), det kan være mere end 4 kilobyte ret nemt. Og hvis denne ting fungerer over UDP, så behøver den ikke at bruge ... den vil ikke have nogen "overhead" for forbindelsen, og for et stort antal servere vil dette være et plus.
Lad os se, hvad open source tilbyder os. For det første har vi Logs Engine - dette er vores motor; I princippet kan han alt, han kan endda skrive lange linjer. Nå, det komprimerer ikke data gennemsigtigt - vi kan selv komprimere store kolonner, hvis vi vil ... det vil vi selvfølgelig ikke (hvis muligt). Det eneste problem er, at han kun kan give væk, hvad der passer i hans hukommelse; For at læse resten skal du hente binlogen til denne motor, og derfor tager det ret lang tid.
Hvilke andre muligheder er der? For eksempel "Hadup". Nem betjening... Hvem synes, at Hadup er let at sætte op? Der er selvfølgelig ingen problemer med optagelsen. Når man læser, opstår der nogle gange spørgsmål. I princippet vil jeg sige, at det nok ikke er, især for logs. Langtidslagring - selvfølgelig, ja, datakomprimering - ja, lange strenge - det er klart, at du kan optage. Men optagelse fra et stort antal servere... Du skal stadig gøre noget selv!
Rsyslog. Faktisk brugte vi det som en backup-mulighed, så vi kunne læse det uden at dumpe binloggen, men det kan ikke skrive lange linjer; i princippet kan det ikke skrive mere end 4 kilobyte. Du skal selv lave datakomprimering på samme måde. Læsning vil komme fra filer.
Så er der "badushka"-udviklingen af LSD. Grundlæggende det samme som "Rsyslog": det understøtter lange strenge, men det kan ikke fungere via UDP, og faktisk på grund af dette, er der desværre mange ting, der skal omskrives der. LSD skal redesignes for at kunne optage fra titusindvis af servere.
Og her! En sjov mulighed er ElasticSearch. Hvordan skal man sige? Han klarer sig godt med at læse, det vil sige han læser hurtigt, men ikke særlig godt med at skrive. For det første, hvis det komprimerer data, er det meget svagt. Mest sandsynligt kræver en fuld søgning større datastrukturer end den oprindelige mængde. Den er svær at betjene, og der opstår ofte problemer med den. Og igen, optagelse i Elastic - vi skal gøre alt selv.
Her er ClickHouse selvfølgelig en ideel mulighed. Det eneste er, at optagelse fra titusindvis af servere er et problem. Men der er i det mindste et problem, vi kan prøve at løse det på en eller anden måde. Og resten af rapporten handler om dette problem. Hvilken slags ydeevne kan du forvente af ClickHouse?
Hvordan skal vi indsætte det? MergeTree
Hvem af jer har ikke hørt eller kender til "ClickHouse"? Jeg er nødt til at fortælle dig, ikke? Meget hurtig. Indsættelsen der - 1-2 gigabit pr. sekund, bursts på op til 10 gigabit pr. sekund kan faktisk modstå denne konfiguration - der er to 6-core Xeoner (det vil sige, ikke engang den mest kraftfulde), 256 gigabyte RAM, 20 terabyte i RAID (ingen er konfigureret, standardindstillinger). Alexey Milovidov, ClickHouse-udvikler, sidder sandsynligvis der og græder, fordi vi ikke har konfigureret noget (alt fungerede sådan for os). Følgelig kan der opnås en scanningshastighed på f.eks. omkring 6 milliarder linjer pr. sekund, hvis dataene er godt komprimeret. Hvis du kan lide % på en tekststreng - 100 millioner linjer i sekundet, det vil sige, det virker ret hurtigt.
Hvordan skal vi indsætte det? Nå, du ved, at VK bruger PHP. Vi vil indsætte fra hver PHP-arbejder via HTTP i "ClickHouse" i MergeTree-tabellen for hver post. Hvem ser et problem med denne ordning? Af en eller anden grund rakte ikke alle hænderne op. Lad mig fortælle dig.
For det første er der mange servere - derfor vil der være mange forbindelser (dårlige). Så er det bedre at indsætte data i MergeTree ikke oftere end én gang i sekundet. Og hvem ved hvorfor? Okay okay. Jeg vil fortælle dig lidt mere om dette. Et andet interessant spørgsmål er, at vi ikke laver analyser, vi behøver ikke berige dataene, vi har ikke brug for mellemservere, vi vil indsætte direkte i "ClickHouse" (helst - jo mere direkte, jo bedre).
I overensstemmelse hermed, hvordan udføres indsættelse i MergeTree? Hvorfor er det bedre at indsætte i det ikke oftere end én gang i sekundet eller sjældnere? Faktum er, at "ClickHouse" er en kolonnebaseret database og sorterer dataene i stigende rækkefølge efter den primære nøgle, og når du laver en indsættelse, oprettes et antal filer, der mindst svarer til antallet af kolonner, hvori dataene er sorteret. i stigende rækkefølge af den primære nøgle (der oprettes en separat mappe, et sæt filer på disken for hver indsættelse). Så kommer den næste indsættelse, og i baggrunden kombineres de til større "partitioner". Da dataene er sorteret, er det muligt at "flette" to sorterede filer uden at bruge meget hukommelse.
Men, som du måske kan gætte, hvis du skriver 10 filer for hver insert, så slutter ClickHouse (eller din server) hurtigt, så det anbefales at indsætte i store batches. Derfor lancerede vi aldrig den første ordning i produktion. Vi lancerede straks en, som her nr. 2 har:
Forestil dig her, at der er omkring tusinde servere, som vi har lanceret på, der er bare PHP. Og på hver server er der vores lokale agent, som vi kaldte "Kittenhouse", som opretholder en forbindelse med "ClickHouse" og indsætter data med få sekunders mellemrum. Indsætter data ikke i MergeTree, men i en buffertabel, som netop tjener til at undgå at indsætte direkte i MergeTree med det samme.
Arbejde med buffertabeller
Hvad er det? Buffertabeller er et stykke hukommelse, der er sønderdelt (det vil sige, at det ofte kan indsættes i det). De består af flere brikker, og hver af brikkerne fungerer som en selvstændig buffer, og de skylles uafhængigt (hvis du har mange brikker i bufferen, så vil der være mange indsatser i sekundet). Det er muligt at læse fra disse tabeller - så læser du foreningen af indholdet af bufferen og den overordnede tabel, men i dette øjeblik er skrivningen blokeret, så det er bedre ikke at læse derfra. Og buffertabeller viser meget god QPS, det vil sige, op til 3 tusinde QPS vil du slet ikke have nogen problemer, når du indsætter. Det er klart, at hvis serveren mister strøm, så kan data gå tabt, fordi de kun blev gemt i hukommelsen.
Samtidig komplicerer skemaet med en buffer ALTER, fordi du først skal droppe den gamle buffertabel med det gamle skema (dataene forsvinder ikke nogen steder, fordi de bliver tømt, før tabellen slettes). Så "ændrer" du den tabel, du skal bruge, og opretter buffertabellen igen. Derfor, mens der ikke er nogen buffertabel, vil dine data ikke flyde nogen steder, men du kan have dem på disken i det mindste lokalt.
Hvad er Kittenhouse, og hvordan fungerer det?
Hvad er KittenHouse? Dette er en proxy. Gæt hvilket sprog? Jeg har samlet de mest hype-emner i min rapport - "Clickhouse", Go, måske husker jeg noget andet. Ja, det er skrevet i Go, for jeg ved ikke rigtig, hvordan man skriver i C, det vil jeg ikke.
Følgelig opretholder den en forbindelse med hver server og kan skrive til hukommelsen. For eksempel, hvis vi skriver fejllogs til Clickhouse, så hvis Clickhouse ikke har tid til at indsætte data (hvis der trods alt er skrevet for meget), så svulmer vi ikke hukommelsen - vi smider simpelthen resten ud. For hvis vi skriver flere gigabit pr. sekund af fejl, så kan vi nok smide nogle ud. Kittenhouse kan gøre dette. Plus, den kan udføre pålidelig levering, det vil sige at skrive til disk på den lokale maskine, og en gang hver gang (der, en gang hvert par sekunder) forsøger den at levere data fra denne fil. Og først brugte vi det almindelige værdier-format - ikke et eller andet binært format, et tekstformat (som i almindelig SQL).
Men så skete dette. Vi brugte pålidelig levering, skrev logs og besluttede så (det var en betinget testklynge)... Den blev sat ud i flere timer og bragt op igen, og en indsættelse startede fra tusinde servere - det viste sig, at Clickhouse stadig havde en "Tråd på forbindelse" - følgelig i tusind forbindelser fører en aktiv indsættelse til et belastningsgennemsnit på serveren på omkring halvanden tusinde. Overraskende nok accepterede serveren anmodninger, men dataene blev stadig indsat efter nogen tid; men det var meget svært for serveren at servere det...
Tilføj nginx
En sådan løsning til Thread-per-forbindelse-modellen er nginx. Vi installerede nginx foran Clickhouse, satte samtidig balancering op for to replikaer (vores indsættelseshastighed steg med 2 gange, selvom det ikke er et faktum, at dette skulle være tilfældet) og begrænsede antallet af forbindelser til Clickhouse, til opstrøms og følgelig mere end i 50 forbindelser, ser det ud til, at der ikke er nogen mening i at indsætte.
Så indså vi, at denne ordning generelt har ulemper, fordi vi kun har én nginx her. Derfor, hvis denne nginx går ned, på trods af tilstedeværelsen af replikaer, mister vi data eller skriver i det mindste ingen steder. Derfor lavede vi vores egen load balancering. Vi indså også, at "Clickhouse" stadig er velegnet til logfiler, og "dæmonen" begyndte også at skrive sine logfiler i "Clickhouse" - meget praktisk, for at være ærlig. Vi bruger det stadig til andre "dæmoner".
Så opdagede vi dette interessante problem: Hvis du bruger en ikke-standard metode til indsættelse i SQL-tilstand, fremtvinger det en fuldgyldig AST-baseret SQL-parser, som er ret langsom. Derfor har vi tilføjet indstillinger for at sikre, at dette aldrig sker. Vi lavede belastningsbalancering, sundhedstjek, så hvis en dør, efterlader vi stadig dataene. Vi har nu ret mange borde, som vi skal have forskellige Clickhouse-klynger. Og vi begyndte også at tænke på andre anvendelser - for eksempel ville vi skrive logs fra nginx-moduler, men de ved ikke, hvordan de skal kommunikere ved hjælp af vores RPC. Nå, jeg vil gerne lære dem at sende i det mindste på en eller anden måde - for eksempel at modtage begivenheder på localhost via UDP og derefter videresende dem til Clickhouse.
Et skridt væk fra løsningen
Det endelige skema begyndte at se sådan ud (den fjerde version af dette skema): på hver server foran Clickhouse er der nginx (på den samme server), og den proxyer simpelthen anmodninger til localhost med en begrænsning på antallet af forbindelser på 50 stykker. Og denne ordning fungerede allerede ret godt, alt var ret godt med den.
Vi levede sådan i omkring en måned. Alle var glade, de tilføjede tabeller, de tilføjede, de tilføjede... Generelt viste det sig, at måden vi tilføjede buffertabeller på ikke var særlig optimal (lad os sige det sådan). Vi lavede 16 stykker i hver tabel og et flashinterval på et par sekunder; vi havde 20 borde, og hvert bord modtog 8 inserts i sekundet - og på dette tidspunkt begyndte "Clickhouse"... rekorderne begyndte at blive langsommere. De gik ikke engang igennem ... Nginx havde som standard en så interessant ting, at hvis forbindelser sluttede ved opstrøms, så returnerede den simpelthen "502" til alle nye anmodninger.
Og her har vi (jeg har lige set på logfilerne i selve Clickhouse) omkring en halv procent af anmodningerne mislykkedes. Følgelig var diskudnyttelsen høj, der var mange fusioner. Nå, hvad gjorde jeg? Naturligvis gad jeg ikke finde ud af, hvorfor netop forbindelsen og opstrøms sluttede.
Udskiftning af nginx med en omvendt proxy
Jeg besluttede, at vi skal styre dette selv, vi behøver ikke overlade det til nginx - nginx ved ikke, hvilke tabeller der er i Clickhouse, og jeg erstattede nginx med en omvendt proxy, som jeg også selv skrev.
Hvad laver han? Det virker baseret på fasthttp-biblioteket "goshnoy", det vil sige hurtigt, næsten lige så hurtigt som nginx. Beklager, Igor, hvis du er til stede her (bemærk: Igor Sysoev er en russisk programmør, der har oprettet nginx-webserveren). Den kan forstå, hvilken slags forespørgsler disse er – INSERT eller SELECT – derfor har den forskellige forbindelsespuljer for forskellige typer forespørgsler.
Derfor, selvom vi ikke har tid til at fuldføre indsættelsesanmodningerne, vil "valgene" passere og omvendt. Og den grupperer dataene i buffertabeller - med en lille buffer: hvis der var fejl, syntaksfejl osv havde lille "bachi", og alle syntaksfejl påvirkede kun dette lille stykke; og her vil de allerede påvirke en stor buffer. Lille er 1 megabyte, det vil sige ikke så lille.
At indsætte en synkronisering og i det væsentlige erstatte nginx, gør stort set det samme, som nginx gjorde før - du behøver ikke at ændre det lokale "Kittenhouse" for dette. Og da den bruger fasthttp, er den meget hurtig - du kan lave mere end 100 anmodninger i sekundet for enkelte indsættelser gennem en omvendt proxy. Teoretisk set kan du indsætte en linje ad gangen i kittenhouse reverse proxy, men det gør vi selvfølgelig ikke.
Ordningen begyndte at se sådan ud: "Kittenhus", den omvendte proxy grupperer mange anmodninger i tabeller, og til gengæld indsætter buffertabellerne dem i de vigtigste.
Killer er en midlertidig løsning, Kitten er permanent
Dette er et interessant problem... Har nogen af jer brugt fasthttp? Hvem brugte fasthttp med POST-anmodninger? Sandsynligvis burde dette virkelig ikke have været gjort, fordi det buffer forespørgselslegemet som standard, og vores bufferstørrelse blev sat til 16 megabyte. Indsættelsen holdt op med at følge med på et tidspunkt, og 16 megabyte bidder begyndte at ankomme fra alle titusindvis af servere, og de blev alle bufferet i hukommelsen, før de blev sendt til Clickhouse. Følgelig løb hukommelsen tør, Out-Of-Memory Killer kom og dræbte den omvendte proxy (eller "Clickhouse", som teoretisk kunne "spise" mere end den omvendte proxy). Cyklussen gentog sig selv. Ikke et særlig behageligt problem. Selvom vi først faldt over dette efter flere måneders drift.
Hvad jeg har gjort? Igen, jeg bryder mig ikke rigtig om at forstå, hvad der præcist skete. Jeg synes, det er ret indlysende, at du ikke skal buffere i hukommelsen. Jeg kunne ikke lappe fasthttp, selvom jeg prøvede. Men jeg fandt en måde at gøre det på, så der ikke var behov for at patche noget, og jeg fandt på min egen metode i HTTP – jeg kaldte den KITTEN. Nå, det er logisk - "VK", "Kitten" ... Hvad ellers? ..
Hvis en anmodning kommer til serveren med Kitten-metoden, skal serveren svare "miauw" - logisk. Hvis han reagerer på dette, så anses det for, at han forstår denne protokol, og så opsnapper jeg forbindelsen (fasthttp har sådan en metode), og forbindelsen går i "rå" tilstand. Hvorfor har jeg brug for det? Jeg vil kontrollere, hvordan læsning fra TCP-forbindelser sker. TCP har en vidunderlig egenskab: Hvis ingen læser fra den anden side, begynder skrivningen at vente, og hukommelsen bliver ikke brugt særlig meget på dette.
Og så læste jeg fra omkring 50 klienter ad gangen (fra halvtreds, fordi halvtreds burde absolut være nok, selvom kursen kommer fra en anden DC)... Forbruget er faldet med denne tilgang mindst 20 gange, men jeg, for at være ærlig , Jeg kunne ikke måle præcist hvad tid, fordi det allerede er meningsløst (det har allerede nået fejlniveauet). Protokollen er binær, dvs. den indeholder tabelnavnet og dataene; der er ingen http-headere, så jeg brugte ikke en web-socket (jeg behøver ikke at kommunikere med browsere - jeg lavede en protokol, der passer til vores behov). Og alt blev fint med ham.
Buffertabellen er trist
For nylig stødte vi på et andet interessant træk ved buffertabeller. Og dette problem er allerede meget mere smertefuldt end de andre. Lad os forestille os denne situation: du bruger allerede aktivt Clickhouse, du har snesevis af Clickhouse-servere, og du har nogle anmodninger, der tager meget lang tid at læse (lad os sige mere end 60 sekunder); og du kommer og laver Alter i dette øjeblik... I mellemtiden vil "selects", der begyndte før "Alter" ikke blive inkluderet i denne tabel, "Alter" vil ikke starte - sandsynligvis nogle funktioner i, hvordan "Clickhouse" fungerer i dette sted. Måske kan dette rettes? Eller er det umuligt?
Generelt er det klart, at det i virkeligheden ikke er så stort et problem, men med buffertabeller bliver det mere smertefuldt. Fordi, hvis, lad os sige, dine "Alter" timeouts (og det kan timeout på en anden vært - ikke på din, men på en replika, for eksempel), så... Du slettede buffertabellen, din "Alter" ( eller en anden vært) timeout. så er der opstået en "Alter"-fejl) - du skal stadig sikre dig, at dataene fortsætter med at blive skrevet: du opretter buffertabellerne tilbage (i henhold til samme skema som den overordnede tabel), så "Alter" går igennem, slutter trods alt, og bufferen begynder tabellen at afvige i skema fra forælderen. Afhængigt af, hvad "Alter" var, kan indsatsen ikke længere gå til denne buffertabel - det er meget trist.
Der er også sådan et tegn (måske har nogen bemærket det) - det hedder query_thread_log i nye versioner af Clickhouse. Som standard var der en i nogle versioner. Her har vi samlet 840 millioner rekorder på et par måneder (100 gigabyte). Dette skyldes, at der blev skrevet "indsæt" (måske nu i øvrigt ikke er skrevet). Som jeg fortalte dig, er vores "inserts" små - vi havde mange "inserts" i buffertabellerne. Det er klart, at dette er deaktiveret - jeg fortæller dig bare, hvad jeg så på vores server. Hvorfor? Dette er endnu et argument imod at bruge buffertabeller! Spotty er meget trist.
Hvem vidste, at denne fyr hed Spotty? VK-medarbejdere rakte hånden op. OKAY.
Om planerne for "KittenHouse"
Planer deles normalt ikke, vel? Pludselig vil du ikke opfylde dem og vil ikke se særlig godt ud i andres øjne. Men jeg tager risikoen! Vi ønsker at gøre følgende: buffertabeller, forekommer det mig, er stadig en krykke, og vi skal selv buffere indsættelsen. Men vi ønsker stadig ikke at buffere det på disken, så vi buffer indsættelsen i hukommelsen.
Når et "indsæt" er lavet, vil det derfor ikke længere være synkront - det vil allerede fungere som en buffertabel, vil indsætte i den overordnede tabel (nå, en dag senere) og rapportere via en separat kanal, hvilke inserts der er bestået, og hvilke har ikke.
Hvorfor kan jeg ikke forlade den synkrone indsats? Det er meget mere bekvemt. Faktum er, at hvis du indsætter fra 10 tusind værter, så er alt i orden - du vil få en lille smule fra hver vært, du indsætter der en gang i sekundet, alt er fint. Men jeg vil gerne have denne ordning til at fungere, for eksempel fra to maskiner, så du kan downloade med høj hastighed - måske ikke få det maksimale ud af Clickhouse, men skrive mindst 100 megabyte i sekundet fra en maskine gennem en omvendt proxy - dette skal skemaet skalere til både store og små mængder, så vi kan ikke vente et sekund på hver indsættelse, så det skal være asynkront. Og på samme måde skulle asynkrone bekræftelser komme efter indsættelsen er gennemført. Vi ved, om det bestod eller ej.
Det vigtigste er, at vi i denne ordning ved med sikkerhed, om indsættelsen fandt sted eller ej. Forestil dig denne situation: du har en buffertabel, du skrev noget ind i den, og lad os sige, at tabellen gik i skrivebeskyttet tilstand og forsøgte at tømme bufferen. Hvor bliver dataene hen? De forbliver i bufferen. Men vi kan ikke være sikre på dette - hvad nu hvis der er en anden fejl, på grund af hvilken dataene ikke forbliver i bufferen... (adresser til Alexey Milovidov, Yandex, ClickHouse-udvikler) Eller vil de forblive? Altid? Alexey overbeviser os om, at alt bliver godt. Vi har ingen grund til ikke at tro på ham. Men alligevel: Hvis vi ikke bruger buffertabeller, vil der ikke være nogen problemer med dem. At lave dobbelt så mange borde er også ubelejligt, selvom der i princippet ikke er de store problemer. Dette er planen.
Lad os tale om læsning
Lad os nu tale om læsning. Vi har også skrevet vores eget værktøj her. Det ser ud til, ja, hvorfor skrive dit eget instrument her?.. Og hvem brugte Tabix? På en eller anden måde rakte de færreste hænderne op... Og hvem er tilfreds med Tabix' præstation? Nå, vi er ikke tilfredse med det, og det er ikke særlig praktisk til at se data. Det er fint til analyser, men bare til visning er det tydeligvis ikke optimeret. Så jeg skrev min egen, min egen grænseflade.
Det er meget enkelt - det kan kun læse data. Han ved ikke, hvordan man viser grafik, han ved ikke, hvordan man gør noget. Men det kan vise, hvad vi har brug for: for eksempel, hvor mange rækker der er i tabellen, hvor meget plads den fylder (uden at opdele den i kolonner), det vil sige, en meget grundlæggende grænseflade er, hvad vi har brug for.
Og det ligner meget Sequel Pro, men kun lavet på Twitters Bootstrap, og den anden version. Du spørger: "Yuri, hvorfor på den anden version?" Hvilket år? 2018? Generelt gjorde jeg dette for ganske lang tid siden for "Muscle" (MySQL) og ændrede lige et par linjer i forespørgslerne der, og det begyndte at fungere for "Clickhouse", hvilket jeg takker for! Fordi parseren er meget lig den "muskel", og forespørgslerne er meget ens - meget praktisk, især i starten.
Nå, det kan filtrere tabeller, kan vise strukturen og indholdet af tabellen, giver dig mulighed for at sortere, filtrere efter kolonner, viser forespørgslen, der resulterede i resultatet, de berørte rækker (hvor mange som et resultat), dvs. grundlæggende ting for at se data. Ret hurtigt.
Der er også en redaktør. Jeg forsøgte ærligt talt at stjæle hele redaktøren fra Tabix, men jeg kunne ikke. Men på en eller anden måde virker det. I princippet er det alt.
"Clickhouse" er velegnet til huler
Jeg vil gerne fortælle dig, at Clickhouse, på trods af alle de beskrevne problemer, er meget velegnet til logs. Vigtigst af alt, det løser vores problem - det er meget hurtigt og giver dig mulighed for at filtrere logfiler efter kolonner. I princippet har buffertabeller ikke fungeret godt, men normalt ved ingen hvorfor... Måske ved du nu bedre, hvor du vil få problemer.
TCP? Generelt er det i VK sædvanligt at bruge UDP. Og da jeg brugte TCP... Selvfølgelig var der ingen, der sagde til mig: “Yuri, hvad taler du om! Det kan du ikke, du har brug for UDP." Det viste sig, at TCP ikke er så skræmmende. Det eneste er, hvis du har titusindvis af aktive stoffer, som du skriver, skal du forberede det lidt mere omhyggeligt; men det er muligt, og ret nemt.
Jeg lovede at poste "Kittenhouse" og "Lighthouse" på HighLoad Siberia, hvis alle abonnerer på vores offentlige "VK backend"... Og du ved, det er ikke alle, der abonnerer... Selvfølgelig vil jeg ikke kræve, at du abonnerer på vores offentlig. Der er stadig for mange af jer, nogen kan endda blive stødt, men alligevel, abonner venligst (og her skal jeg lave øjne som en kat). Det er . Mange tak! Github er vores . Med Clickhouse bliver dit hår blødt og silkeblødt.
Førende: - Venner, nu til spørgsmål. Lige efter præsenterer vi påskønnelsesbeviset og din rapport om VHS.
Yuri Nasretdinov (i det følgende benævnt YN): – Hvordan kunne du optage min rapport på VHS, hvis den lige sluttede?
Førende: – Du kan heller ikke helt afgøre, hvordan "Clickhouse" vil fungere eller ej! Venner, 5 minutter til spørgsmål!
R'RѕRїSЂRѕSЃS <
Spørgsmål fra salen (i det følgende benævnt Q): - God eftermiddag. Mange tak for rapporten. Jeg har to spørgsmål. Jeg starter med noget useriøst: Påvirker antallet af bogstaver t i navnet "Kittenhus" i diagrammerne (3, 4, 7...) kattenes tilfredshed?
YN: - Mængde af hvad?
Z: – Bogstav t. Der er tre t'er, et sted omkring tre t'er.
YN: - Har jeg ikke rettet det? Nå, selvfølgelig gør det det! Det er forskellige produkter - jeg har bare snydt dig hele tiden. Okay, jeg laver sjov - det er lige meget. Ah, lige her! Nej, det er det samme, jeg lavede en tastefejl.
Z: - Tak skal du have. Det andet spørgsmål er alvorligt. Så vidt jeg forstår, lever buffertabeller i Clickhouse udelukkende i hukommelsen, er ikke bufret til disk og er følgelig ikke persistente.
YN: - Ja.
Z: – Og samtidig bufferer din klient til disk, hvilket indebærer en vis garanti for levering af de samme logfiler. Men dette er på ingen måde garanteret hos Clickhouse. Forklar hvordan garantien udføres, på grund af hvad?.. Her er denne mekanisme mere detaljeret
YN: – Ja, teoretisk er der ingen modsætninger her, for når Clickhouse falder, kan man faktisk opdage det på en million forskellige måder. Hvis Clickhouse går ned (hvis det ender forkert), kan du groft sagt spole lidt af din log, som du skrev ned, tilbage og starte fra det øjeblik, hvor alt var helt fint. Lad os sige, at du spoler et minut tilbage, det vil sige, at det anses for, at du har skyllet alt på et minut.
Z: – Det vil sige, "Kittenhus" holder vinduet længere og kan i tilfælde af et fald genkende det og spole det tilbage?
YN: - Men det er i teorien. I praksis gør vi ikke dette, og pålidelig levering er fra nul til uendeligt. Men i gennemsnit én. Vi er tilfredse med, at hvis Clickhouse går ned af en eller anden grund, eller serverne "genstarter", så taber vi lidt. I alle andre tilfælde vil der ikke ske noget.
Z: - Hej. Lige fra begyndelsen forekom det mig, at du faktisk ville bruge UDP lige fra begyndelsen af rapporten. Du har http, alt det... Og de fleste af de problemer, du beskrev, som jeg forstår det, var forårsaget af denne særlige løsning...
YN: – Hvad bruger vi TCP?
Z: - I bund og grund ja.
YN: - Nej.
Z: – Det var med fasthttp, du havde problemer, med forbindelsen, du havde problemer. Hvis du bare havde brugt UDP, ville du have sparet dig selv noget tid. Nå, der ville være problemer med lange beskeder eller noget andet...
YN: - Med hvad?
Z: – Med lange beskeder, da det måske ikke passer ind i MTU'en, noget andet... Tja, der kan være deres egne problemer. Spørgsmålet er: hvorfor ikke UDP?
YN: – Jeg tror på, at forfatterne, der har udviklet TCP/IP, er meget klogere end mig og ved bedre end mig, hvordan man serialiserer pakker (så de går), samtidig justerer sendevinduet, ikke overbelaste netværket, giver feedback på, hvad er ikke læst, tæller ikke på den anden side... Alle disse problemer ville efter min mening eksistere i UDP, kun jeg skulle skrive endnu mere kode end jeg allerede skrev for at implementere det samme selv og højst sandsynligt dårligt. Jeg kan ikke engang rigtig godt lide at skrive i C, endsige der...
Z: - Bare praktisk! Sendt ok og vent ikke på noget - det er fuldstændig asynkront. En meddelelse kom tilbage om, at alt var i orden - det betyder, at det ankom; Hvis det ikke kommer, betyder det, at det er slemt.
YN: – Jeg skal bruge begge dele – Jeg skal kunne sende både med leveringsgaranti og uden leveringsgaranti. Det er to forskellige scenarier. Jeg skal ikke miste nogle logfiler eller ikke miste dem inden for rimelighedens grænser.
Z: - Jeg vil ikke spilde tiden. Dette skal diskuteres mere. Tak skal du have.
Førende: – Hvem har spørgsmål – hænder til himlen!
Z: - Hej, jeg hedder Sasha. Et sted midt i rapporten opstod en følelse af, at det udover TCP var muligt at bruge en færdiglavet løsning - en slags Kafka.
YN: – Tja... jeg fortalte dig, at jeg ikke vil bruge mellemservere, fordi... i Kafka viser det sig, at vi har ti tusinde værter; faktisk har vi flere - titusindvis af værter. Det kan også være smertefuldt at gøre med Kafka uden nogen fuldmagter. Derudover, vigtigst af alt, giver det stadig "latency", det giver ekstra værter, som du skal have. Men jeg vil ikke have dem - jeg vil...
Z: "Men i sidste ende blev det sådan alligevel."
YN: – Nej, der er ingen værter! Alt dette virker på Clickhouse-værter.
Z: - Nå, og "Kittenhus", som er omvendt - hvor bor han?
YN: – På Clickhouse-værten skriver den ikke noget til disken.
Z: - Lad os antage.
Førende: - Er du tilfreds? Kan vi give dig løn?
Z: - Ja du kan. Faktisk er der mange krykker for at få det samme, og nu - det tidligere svar om emnet TCP modsiger efter min mening denne situation. Det føles bare som om alt kunne have været gjort på mine knæ på meget kortere tid.
YN: – Og også hvorfor jeg ikke ville bruge Kafka, for der var ret mange klager i Clickhouse Telegram-chatten over, at for eksempel beskeder fra Kafka gik tabt. Ikke fra Kafka selv, men i integrationen af Kafka og Clickhaus; eller noget hang ikke sammen der. Det ville groft sagt være nødvendigt at skrive en klient til Kafka dengang. Jeg tror ikke, der kunne være en enklere eller mere pålidelig løsning.
Z: – Sig mig, hvorfor prøvede du ikke nogen køer eller en slags fælles bus? Siden du siger, at man med asynkroni kunne sende selve logfilerne gennem køen og modtage svaret asynkront gennem køen?
YN: – Foreslå venligst, hvilke køer der kan bruges?
Z: – Enhver, også uden garanti for, at de er i orden. En slags Redis, RMQ...
YN: – Jeg har en fornemmelse af, at Redis højst sandsynligt ikke vil være i stand til at trække et sådant volumen af indsættelse selv på én vært (i betydningen flere servere), der trækker Clickhouse ud. Jeg kan ikke bakke dette op med nogen beviser (jeg har ikke benchmarked det), men det forekommer mig, at Redis ikke er den bedste løsning her. I princippet kan dette system betragtes som en improviseret beskedkø, men som kun er skræddersyet til "Clickhouse"
Førende: – Yuri, mange tak. Jeg foreslår at afslutte spørgsmålene og svarene her og sige, hvem af dem, der stillede spørgsmålet, vi vil give bogen til.
YN: – Jeg vil gerne give en bog til den første person, der stillede et spørgsmål.
Førende: - Vidunderligt! Store! Fabelagtig! Mange tak!
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