HighLoad++ Moskva 2018, kongresshall. 9. november, 15:00
Sammendrag og presentasjon:
Yuri Nasretdinov (VKontakte): rapporten vil snakke om opplevelsen av å implementere ClickHouse i selskapet vårt - hvorfor vi trenger det, hvor mye data vi lagrer, hvordan vi skriver det, og så videre.
Tilleggsmateriell:
Yuri Nasretdinov: - Hei alle sammen! Mitt navn er Yuri Nasretdinov, som jeg allerede har blitt introdusert. Jeg jobber på VKontakte. Jeg vil snakke om hvordan vi setter inn data i ClickHouse fra serverflåten vår (ti tusenvis).
Hva er logger og hvorfor samle dem?
Hva vi vil fortelle deg: hva vi gjorde, hvorfor vi trengte "ClickHouse", henholdsvis hvorfor vi valgte det, hva slags ytelse du omtrent kan få uten å konfigurere noe spesielt. Jeg skal fortelle deg videre om buffertabeller, om problemene vi hadde med dem og om løsningene våre som vi utviklet fra åpen kildekode - KittenHouse og Lighthouse.
Hvorfor trengte vi å gjøre noe i det hele tatt (alt er alltid bra på VKontakte, ikke sant?). Vi ønsket å samle feilsøkingslogger (og det var hundrevis av terabyte med data der), kanskje det på en eller annen måte ville være mer praktisk å beregne statistikk; og vi har en flåte på titusenvis av servere som alt dette må gjøres fra.
Hvorfor bestemte vi oss? Vi hadde nok løsninger for oppbevaring av tømmerstokker. Her - det er en slik offentlig "Backend VK". Jeg anbefaler på det sterkeste å abonnere på den.
Hva er logger? Dette er en motor som returnerer tomme arrays. Motorer i VK er det andre kaller mikrotjenester. Og her er et smilende klistremerke (ganske mange likes). Hvordan det? Vel, hør videre!
Hva kan brukes til å lagre logger? Vi kan ikke la være å nevne Hadup. Deretter, for eksempel, Rsyslog (lagre disse loggene i filer). LSD. Hvem vet hva LSD er? Nei, ikke denne LSD. Lagre filer også. Vel, ClickHouse er et merkelig alternativ.
Klikkhus og konkurrenter: krav og muligheter
Hva vil vi? Vi ønsker å sikre at vi ikke trenger å bekymre oss for mye om operasjonen, slik at den fungerer ut av esken, helst med minimal konfigurasjon. Vi vil skrive mye, og skrive raskt. Og vi ønsker å beholde den i alle mulige måneder, år, altså i lang tid. Vi vil kanskje forstå et problem som de kom til oss med og sa: "Noe fungerer ikke her," og det var for 3 måneder siden), og vi ønsker å kunne se hva som skjedde for 3 måneder siden. Datakomprimering - det er klart hvorfor det ville være et pluss - fordi det reduserer mengden plass den tar opp.
Og vi har et så interessant krav: noen ganger skriver vi utdataene til noen kommandoer (for eksempel logger), det kan være mer enn 4 kilobyte ganske enkelt. Og hvis denne tingen fungerer over UDP, trenger den ikke å bruke ... den vil ikke ha noen "overhead" for tilkoblingen, og for et stort antall servere vil dette være et pluss.
La oss se hva åpen kildekode tilbyr oss. For det første har vi Logs Engine - dette er vår motor; I prinsippet kan han alt, han kan til og med skrive lange linjer. Vel, det komprimerer ikke data transparent - vi kan komprimere store kolonner selv hvis vi vil ... vi vil selvfølgelig ikke (hvis mulig). Problemet er bare at han bare kan gi bort det som passer i minnet hans; For å lese resten, må du få binlogen til denne motoren, og følgelig tar det ganske lang tid.
Hvilke andre alternativer er det? For eksempel "Hadup". Enkel betjening... Hvem tror at Hadup er lett å sette opp? Det er selvsagt ingen problemer med opptaket. Når du leser, dukker det noen ganger opp spørsmål. I prinsippet vil jeg si sannsynligvis ikke, spesielt for tømmerstokker. Langtidslagring - selvfølgelig, ja, datakomprimering - ja, lange strenger - det er klart at du kan ta opp. Men opptak fra et stort antall servere... Du må fortsatt gjøre noe selv!
Rsyslog. Faktisk brukte vi det som et sikkerhetskopieringsalternativ slik at vi kunne lese det uten å dumpe binloggen, men det kan ikke skrive lange linjer; i prinsippet kan det ikke skrive mer enn 4 kilobyte. Du må gjøre datakomprimering på samme måte selv. Lesing vil komme fra filer.
Så er det "badushka"-utviklingen av LSD. I hovedsak det samme som "Rsyslog": den støtter lange strenger, men den kan ikke fungere via UDP, og faktisk, på grunn av dette, må dessverre ganske mange ting skrives om der. LSD må redesignes for å kunne ta opp fra titusenvis av servere.
Og her! Et morsomt alternativ er ElasticSearch. Hvordan si det? Han klarer seg godt med lesing, det vil si at han leser raskt, men ikke så godt med å skrive. For det første, hvis den komprimerer data, er den veldig svak. Mest sannsynlig krever et fullstendig søk større datastrukturer enn det opprinnelige volumet. Det er vanskelig å betjene og det oppstår ofte problemer med det. Og igjen, innspilling i Elastic - vi må gjøre alt selv.
Her er ClickHouse selvfølgelig et ideelt alternativ. Det eneste er at opptak fra titusenvis av servere er et problem. Men det er i det minste ett problem, vi kan prøve å løse det på en eller annen måte. Og resten av rapporten handler om dette problemet. Hva slags ytelse kan du forvente fra ClickHouse?
Hvordan skal vi sette den inn? MergeTree
Hvem av dere har ikke hørt eller vet om "ClickHouse"? Jeg må fortelle deg, ikke sant? Veldig fort. Innsettingen der - 1-2 gigabit per sekund, serier på opptil 10 gigabit per sekund kan faktisk tåle denne konfigurasjonen - det er to 6-kjerners Xeoner (det vil si ikke engang de kraftigste), 256 gigabyte RAM, 20 terabyte i RAID (ingen konfigurert, standardinnstillinger). Alexey Milovidov, ClickHouse-utvikler, sitter sannsynligvis der og gråter fordi vi ikke konfigurerte noe (alt fungerte slik for oss). Følgelig kan en skannehastighet på for eksempel ca. 6 milliarder linjer per sekund oppnås hvis dataene er godt komprimert. Hvis du liker % på en tekststreng - 100 millioner linjer per sekund, det vil si at det virker ganske raskt.
Hvordan skal vi sette den inn? Vel, du vet at VK bruker PHP. Vi vil sette inn fra hver PHP-arbeider via HTTP i "ClickHouse", i MergeTree-tabellen for hver post. Hvem ser et problem med denne ordningen? Av en eller annen grunn var det ikke alle som rakte opp hendene. La meg fortelle deg.
For det første er det mange servere - følgelig vil det være mange tilkoblinger (dårlige). Da er det bedre å sette inn data i MergeTree ikke oftere enn én gang i sekundet. Og hvem vet hvorfor? Ok, ok. Jeg skal fortelle deg litt mer om dette. Et annet interessant spørsmål er at vi ikke gjør analyser, vi trenger ikke å berike dataene, vi trenger ikke mellomservere, vi vil sette inn direkte i "ClickHouse" (fortrinnsvis - jo mer direkte, jo bedre).
Følgelig, hvordan gjøres innsetting i MergeTree? Hvorfor er det bedre å sette inn i den ikke oftere enn en gang i sekundet eller sjeldnere? Faktum er at "ClickHouse" er en kolonneformet database og sorterer dataene i stigende rekkefølge av primærnøkkelen, og når du setter inn, opprettes et antall filer minst lik antall kolonner som dataene er sortert i. i stigende rekkefølge av primærnøkkelen (en egen katalog opprettes, et sett med filer på disken for hver innsetting). Så kommer neste innsetting, og i bakgrunnen blir de kombinert til større "partisjoner". Siden dataene er sortert, er det mulig å "slå sammen" to sorterte filer uten å bruke mye minne.
Men, som du kanskje gjetter, hvis du skriver 10 filer for hvert innlegg, vil ClickHouse (eller serveren din) raskt avsluttes, så det anbefales å sette inn i store partier. Derfor lanserte vi aldri den første ordningen i produksjon. Vi lanserte umiddelbart en, som her nr. 2 har:
Tenk deg her at det er rundt tusen servere vi har lansert på, det er bare PHP. Og på hver server er det vår lokale agent, som vi kalte "Kittenhouse", som opprettholder en forbindelse med "ClickHouse" og setter inn data med noen sekunders mellomrom. Setter inn data ikke i MergeTree, men i en buffertabell, som tjener nettopp til å unngå å sette direkte inn i MergeTree med en gang.
Arbeid med buffertabeller
Hva det er? Buffertabeller er et stykke minne som er sønderdelt (det vil si at det kan settes inn ofte). De består av flere stykker, og hver av stykkene fungerer som en uavhengig buffer, og de spyles uavhengig (hvis du har mange stykker i bufferen, så blir det mange innlegg i sekundet). Det er mulig å lese fra disse tabellene - da leser du foreningen av innholdet i bufferen og den overordnede tabellen, men i dette øyeblikk er skrivingen blokkert, så det er bedre å ikke lese derfra. Og buffertabeller viser veldig god QPS, det vil si at opptil 3 tusen QPS vil du ikke ha noen problemer i det hele tatt når du setter inn. Det er klart at hvis serveren mister strøm, kan dataene gå tapt, fordi de bare ble lagret i minnet.
Samtidig kompliserer ordningen med en buffer ALTER, fordi du først må droppe den gamle buffertabellen med den gamle ordningen (dataene vil ikke forsvinne noe sted, fordi de vil bli tømt før tabellen slettes). Deretter "endrer" du tabellen du trenger og lager buffertabellen på nytt. Følgelig, selv om det ikke er noen buffertabell, vil dataene dine ikke flyte hvor som helst, men du kan ha dem på disk i det minste lokalt.
Hva er Kittenhouse og hvordan fungerer det?
Hva er KittenHouse? Dette er en proxy. Gjett hvilket språk? Jeg samlet de fleste hype-emnene i rapporten min - "Clickhouse", Go, kanskje jeg husker noe annet. Ja, dette er skrevet i Go, fordi jeg egentlig ikke vet hvordan jeg skal skrive i C, jeg vil ikke.
Følgelig opprettholder den en forbindelse med hver server og kan skrive til minnet. For eksempel, hvis vi skriver feillogger til Clickhouse, så hvis Clickhouse ikke har tid til å sette inn data (tross alt, hvis det er skrevet for mye), så sveller vi ikke minnet - vi kaster bare ut resten. For hvis vi skriver flere gigabit per sekund med feil, så kan vi sannsynligvis kaste ut noen. Kittenhouse kan gjøre dette. I tillegg kan den utføre pålitelig levering, det vil si å skrive til disk på den lokale maskinen og en gang hver gang (der, en gang hvert par sekunder) prøver den å levere data fra denne filen. Og først brukte vi det vanlige verdiformatet - ikke et binært format, et tekstformat (som i vanlig SQL).
Men så skjedde dette. Vi brukte pålitelig levering, skrev logger og bestemte oss (det var en betinget testklynge)... Den ble satt ut i flere timer og brakt opp igjen, og en innsetting startet fra tusen servere - det viste seg at Clickhouse fortsatt hadde en "Tråd ved tilkobling" - følgelig, i tusen tilkoblinger, fører en aktiv innsetting til et gjennomsnittlig belastning på serveren på omtrent halvannet tusen. Overraskende nok godtok serveren forespørsler, men dataene ble fortsatt satt inn etter en stund; men det var veldig vanskelig for serveren å servere det...
Legg til nginx
En slik løsning for Thread per connection-modellen er nginx. Vi installerte nginx foran Clickhouse, samtidig satte vi opp balansering for to replikaer (innsettingshastigheten vår økte med 2 ganger, selv om det ikke er et faktum at dette skal være tilfelle) og begrenset antall tilkoblinger til Clickhouse, til oppstrøms og følgelig mer enn i 50 forbindelser, ser det ut til at det ikke er noen vits i å sette inn.
Da skjønte vi at denne ordningen generelt har ulemper, fordi vi bare har en nginx her. Følgelig, hvis denne nginxen krasjer, til tross for tilstedeværelsen av replikaer, mister vi data eller i det minste ikke skriver noe sted. Derfor har vi laget vår egen lastbalansering. Vi innså også at "Clickhouse" fortsatt er egnet for logger, og "demonen" begynte også å skrive loggene sine i "Clickhouse" - veldig praktisk, for å være ærlig. Vi bruker det fortsatt for andre "demoner".
Så oppdaget vi dette interessante problemet: hvis du bruker en ikke-standard metode for å sette inn i SQL-modus, tvinger det frem en fullverdig AST-basert SQL-parser, som er ganske treg. Derfor har vi lagt til innstillinger for å sikre at dette aldri skjer. Vi gjorde belastningsbalansering, helsesjekker, slik at hvis en dør, lar vi fortsatt dataene ligge. Vi har nå ganske mange tabeller som vi trenger for å ha forskjellige Clickhouse-klynger. Og vi begynte også å tenke på andre bruksområder - for eksempel ønsket vi å skrive logger fra nginx-moduler, men de vet ikke hvordan de skal kommunisere ved hjelp av RPC-en vår. Vel, jeg vil gjerne lære dem hvordan de sender i det minste på en eller annen måte - for eksempel å motta arrangementer på localhost via UDP og deretter videresende dem til Clickhouse.
Ett skritt unna løsningen
Det endelige opplegget begynte å se slik ut (den fjerde versjonen av dette opplegget): på hver server foran Clickhouse er det nginx (på samme server) og den sender rett og slett forespørsler til localhost med en grense på antall tilkoblinger på 50 stykker. Og denne ordningen fungerte allerede ganske bra, alt var ganske bra med den.
Vi levde slik i omtrent en måned. Alle var fornøyde, de la til tabeller, de la til, de la til... Generelt viste det seg at måten vi la til buffertabeller på ikke var særlig optimal (la oss si det sånn). Vi gjorde 16 stykker i hvert bord og et blinkintervall på et par sekunder; vi hadde 20 bord og hvert bord fikk 8 innlegg per sekund - og på dette tidspunktet begynte "Clickhouse"... postene begynte å avta. De gikk ikke engang gjennom ... Nginx hadde som standard en så interessant ting at hvis tilkoblinger ble avsluttet ved oppstrøms, så returnerte den ganske enkelt "502" til alle nye forespørsler.
Og her har vi (jeg så nettopp på loggene i selve Clickhouse) omtrent en halv prosent av forespørslene mislyktes. Følgelig var diskutnyttelsen høy, det var mange sammenslåinger. Vel, hva gjorde jeg? Naturligvis gadd jeg ikke finne ut hvorfor akkurat forbindelsen og oppstrøms sluttet.
Erstatter nginx med en omvendt proxy
Jeg bestemte meg for at vi må administrere dette selv, vi trenger ikke overlate det til nginx - nginx vet ikke hvilke tabeller det er i Clickhouse, og jeg erstattet nginx med en omvendt proxy, som jeg også skrev selv.
Hva er det han gjør? Det fungerer basert på fasthttp-biblioteket "goshnoy", det vil si raskt, nesten like raskt som nginx. Beklager, Igor, hvis du er til stede her (merk: Igor Sysoev er en russisk programmerer som opprettet nginx-nettserveren). Den kan forstå hva slags spørringer disse er – INSERT eller SELECT – følgelig har den forskjellige tilkoblingspooler for forskjellige typer spørringer.
Følgelig, selv om vi ikke har tid til å fullføre innsettingsforespørslene, vil "valgene" passere, og omvendt. Og den grupperer dataene i buffertabeller - med en liten buffer: hvis det var noen feil, syntaksfeil og så videre - slik at de ikke i stor grad ville påvirke resten av dataene, for når vi bare satt inn i buffertabeller, hadde liten "bachi", og alle syntaksfeilene påvirket bare denne lille biten; og her vil de allerede påvirke en stor buffer. Liten er 1 megabyte, det vil si ikke så liten.
Å sette inn en synkronisering og i hovedsak erstatte nginx, gjør i hovedsak det samme som nginx gjorde før - du trenger ikke å endre det lokale "Kittenhuset" for dette. Og siden den bruker fasthttp, er den veldig rask - du kan gjøre mer enn 100 tusen forespørsler per sekund for enkeltinnsettinger gjennom en omvendt proxy. Teoretisk sett kan du sette inn en linje om gangen i kittenhouse reverse proxy, men selvfølgelig gjør vi ikke det.
Ordningen begynte å se slik ut: "Kittenhus", omvendt proxy grupperer mange forespørsler i tabeller, og på sin side setter buffertabellene dem inn i de viktigste.
Killer er en midlertidig løsning, Kitten er permanent
Dette er et interessant problem... Har noen av dere brukt fasthttp? Hvem brukte fasthttp med POST-forespørsler? Sannsynligvis burde dette egentlig ikke vært gjort, fordi det buffer forespørselsteksten som standard, og bufferstørrelsen vår ble satt til 16 megabyte. Innsettingen sluttet å følge med på et tidspunkt, og 16 megabyte biter begynte å komme fra alle titusenvis av servere, og de ble alle bufret i minnet før de ble sendt til Clickhouse. Følgelig gikk minnet tomt, Out-Of-Memory Killer kom og drepte den omvendte proxyen (eller "Clickhouse", som teoretisk sett kunne "spise" mer enn den omvendte proxyen). Syklusen gjentok seg. Ikke et veldig hyggelig problem. Selv om vi snublet over dette først etter flere måneders drift.
Hva jeg har gjort? Igjen, jeg liker egentlig ikke å forstå hva som skjedde. Jeg synes det er ganske åpenbart at du ikke bør bufre inn i minnet. Jeg kunne ikke lappe fasthttp, selv om jeg prøvde. Men jeg fant en måte å gjøre det slik at det ikke var behov for å lappe noe, og jeg kom opp med min egen metode i HTTP - jeg kalte den KITTEN. Vel, det er logisk - "VK", "Kattunge" ... Hva annet? ..
Hvis en forespørsel kommer til serveren med Kitten-metoden, bør serveren svare "mjau" - logisk. Hvis han reagerer på dette, anses det for at han forstår denne protokollen, og så avskjærer jeg forbindelsen (fasthttp har en slik metode), og forbindelsen går inn i "rå"-modus. Hvorfor trenger jeg det? Jeg vil kontrollere hvordan lesing fra TCP-tilkoblinger skjer. TCP har en fantastisk egenskap: hvis ingen leser fra den andre siden, begynner skrivingen å vente, og minnet blir ikke spesielt brukt på dette.
Og så leste jeg fra rundt 50 klienter om gangen (fra femti fordi femti burde definitivt være nok, selv om prisen kommer fra en annen DC)... Forbruket har gått ned med denne tilnærmingen minst 20 ganger, men jeg, for å være ærlig , Jeg kunne ikke måle nøyaktig hvilken tid, fordi det allerede er meningsløst (det har allerede nådd feilnivået). Protokollen er binær, det vil si at den inneholder tabellnavnet og dataene; det er ingen http-hoder, så jeg brukte ikke en nettsocket (jeg trenger ikke å kommunisere med nettlesere - jeg laget en protokoll som passer våre behov). Og alt ble bra med ham.
Buffertabellen er trist
Nylig kom vi over en annen interessant funksjon ved buffertabeller. Og dette problemet er allerede mye mer smertefullt enn de andre. La oss forestille oss denne situasjonen: du bruker allerede Clickhouse aktivt, du har dusinvis av Clickhouse-servere, og du har noen forespørsler som tar veldig lang tid å lese (la oss si mer enn 60 sekunder); og du kommer og gjør Alter i dette øyeblikket... I mellomtiden vil ikke "selects" som begynte før "Alter" bli inkludert i denne tabellen, "Alter" vil ikke starte - sannsynligvis noen funksjoner for hvordan "Clickhouse" fungerer i dette stedet. Kanskje dette kan fikses? Eller er det umulig?
Generelt er det klart at dette i realiteten ikke er et så stort problem, men med buffertabeller blir det mer smertefullt. Fordi, la oss si, "Alter"-timeoutene dine (og det kan være tidsavbrudd på en annen vert - ikke på din, men på en replika, for eksempel), så... Du slettet buffertabellen, "Alter" ( eller en annen vert) ble tidsavbrutt. så har det oppstått en "Alter"-feil) - du må fortsatt sørge for at dataene fortsetter å bli skrevet: du oppretter buffertabellene tilbake (i henhold til samme skjema som den overordnede tabellen), og deretter "Alter" går gjennom, slutter tross alt, og bufferen tabellen begynner å avvike i skjema fra den overordnede. Avhengig av hva "Alter" var, kan det hende at innsatsen ikke lenger går til denne buffertabellen - dette er veldig trist.
Det er også et slikt tegn (kanskje noen la merke til det) - det kalles query_thread_log i nye versjoner av Clickhouse. Som standard var det en i noen versjoner. Her har vi samlet 840 millioner rekorder på et par måneder (100 gigabyte). Dette skyldes det faktum at "innlegg" ble skrevet der (kanskje nå, forresten, er de ikke skrevet). Som jeg fortalte deg, er "innleggene" våre små - vi hadde mange "innlegg" i buffertabellene. Det er tydelig at dette er deaktivert - jeg forteller deg bare hva jeg så på serveren vår. Hvorfor? Dette er nok et argument mot å bruke buffertabeller! Spotty er veldig trist.
Hvem visste at denne fyren het Spotty? VK-ansatte rakte opp hendene. OK.
Om planene for "KittenHouse"
Vanligvis deles ikke planer, ikke sant? Plutselig vil du ikke oppfylle dem og vil ikke se veldig bra ut i andres øyne. Men jeg tar risikoen! Vi ønsker å gjøre følgende: buffertabeller, ser det ut til, er fortsatt en krykke, og vi må buffere innsettingen selv. Men vi ønsker fortsatt ikke å bufre den på disken, så vi buffer innsettingen i minnet.
Følgelig, når en "innsetting" lages, vil den ikke lenger være synkron - den vil allerede fungere som en buffertabell, vil settes inn i den overordnede tabellen (vel, en dag senere) og rapportere via en egen kanal hvilke innsettinger som har passert og hvilke har ikke.
Hvorfor kan jeg ikke forlate den synkrone innsatsen? Det er mye mer praktisk. Faktum er at hvis du setter inn fra 10 tusen verter, så er alt bra - du vil få litt fra hver vert, du setter inn der en gang i sekundet, alt er bra. Men jeg vil at denne ordningen skal fungere, for eksempel fra to maskiner, slik at du kan laste ned i høy hastighet - kanskje ikke få maksimalt ut av Clickhouse, men skrive minst 100 megabyte per sekund fra en maskin gjennom en omvendt proxy - dette må ordningen skalere til både store og små mengder, så vi kan ikke vente et sekund på hver innsetting, så den må være asynkron. Og på samme måte bør asynkrone bekreftelser komme etter at innsettingen er gjennomført. Vi får vite om det gikk eller ikke.
Det viktigste er at vi i denne ordningen vet med sikkerhet om innsettingen fant sted eller ikke. Tenk deg denne situasjonen: du har en buffertabell, du skrev noe inn i den, og la oss si at tabellen gikk i skrivebeskyttet modus og prøvde å tømme bufferen. Hvor vil dataene gå? De vil forbli i bufferen. Men vi kan ikke være sikre på dette - hva om det er en annen feil, på grunn av hvilken dataene ikke vil forbli i bufferen... (Tiltaler Alexey Milovidov, Yandex, ClickHouse-utvikler) Eller vil den forbli? Alltid? Alexey overbeviser oss om at alt vil bli bra. Vi har ingen grunn til ikke å tro ham. Men likevel: hvis vi ikke bruker buffertabeller, vil det ikke være noen problemer med dem. Å lage dobbelt så mange bord er også upraktisk, selv om det i prinsippet ikke er store problemer. Dette er planen.
La oss snakke om lesing
La oss nå snakke om lesing. Vi har også skrevet vårt eget verktøy her. Det ser ut til, vel, hvorfor skrive ditt eget instrument her? .. Og hvem brukte Tabix? På en eller annen måte er det få som rakk opp hendene... Og hvem er fornøyd med ytelsen til Tabix? Vel, vi er ikke fornøyd med det, og det er ikke veldig praktisk for å se data. Det er greit for analyser, men bare for visning er det tydeligvis ikke optimalisert. Så jeg skrev mitt eget, mitt eget grensesnitt.
Det er veldig enkelt - det kan bare lese data. Han vet ikke hvordan han skal vise grafikk, han vet ikke hvordan han skal gjøre noe. Men det kan vise hva vi trenger: for eksempel hvor mange rader det er i tabellen, hvor mye plass den tar opp (uten å bryte den ned i kolonner), det vil si at et veldig grunnleggende grensesnitt er det vi trenger.
Og den ligner veldig på Sequel Pro, men bare laget på Twitters Bootstrap, og den andre versjonen. Du spør: "Yuri, hvorfor på den andre versjonen?" Hvilket år? 2018? Generelt gjorde jeg dette for ganske lenge siden for "Muscle" (MySQL) og endret bare et par linjer i spørringene der, og det begynte å fungere for "Clickhouse", som en spesiell takk for! Fordi parseren er veldig lik "muskelen", og spørringene er veldig like - veldig praktisk, spesielt i begynnelsen.
Vel, den kan filtrere tabeller, kan vise strukturen og innholdet i tabellen, lar deg sortere, filtrere etter kolonner, viser spørringen som resulterte i resultatet, de berørte radene (hvor mange som et resultat), det vil si grunnleggende ting for å se data. Ganske fort.
Det er også en redaktør. Jeg prøvde ærlig talt å stjele hele redaktøren fra Tabix, men jeg klarte det ikke. Men på en eller annen måte fungerer det. I prinsippet er det alt.
"Clickhouse" passer for hi
Jeg vil fortelle deg at Clickhouse, til tross for alle problemene som er beskrevet, er veldig godt egnet for logger. Viktigst av alt, det løser problemet vårt - det er veldig raskt og lar deg filtrere logger etter kolonner. I prinsippet har buffertabeller ikke fungert bra, men vanligvis er det ingen som vet hvorfor... Kanskje nå vet du bedre hvor du vil få problemer.
TCP? Generelt er det i VK vanlig å bruke UDP. Og da jeg brukte TCP... Selvfølgelig var det ingen som sa til meg: «Yuri, hva snakker du om! Du kan ikke, du trenger UDP." Det viste seg at TCP ikke er så skummelt. Det eneste er, hvis du har titusenvis av aktive forbindelser som du skriver, må du forberede det litt mer nøye; men det er mulig, og ganske enkelt.
Jeg lovet å legge ut “Kittenhouse” og “Lighthouse” på HighLoad Siberia hvis alle abonnerer på vår offentlige “VK backend”... Og du vet, ikke alle abonnerer... Selvfølgelig vil jeg ikke kreve at du abonnerer på vår offentlig. Det er fortsatt for mange av dere, noen kan til og med bli fornærmet, men likevel, abonner (og her må jeg lage øyne som en katt). Det er . Tusen takk! Github er vår . Med Clickhouse blir håret ditt mykt og silkeaktig.
moderator: - Venner, nå for spørsmål. Rett etter presenterer vi takknemlighetsbeviset og din rapport om VHS.
Yuri Nasretdinov (heretter referert til som YN): – Hvordan klarte du å ta opp rapporten min på VHS hvis den nettopp ble avsluttet?
moderator: – Du kan heller ikke helt bestemme hvordan "Clickhouse" vil fungere eller ikke! Venner, 5 minutter for spørsmål!
spørsmål
Spørsmål fra salen (heretter kalt Q): - God ettermiddag. Tusen takk for rapporten. Jeg har to spørsmål. Jeg begynner med noe useriøst: påvirker antall bokstaver t i navnet "Kattungehus" i diagrammene (3, 4, 7...) kattenes tilfredshet?
YN: - Mengde av hva?
Z: – Bokstav t. Det er tre t-er, et sted rundt tre t-er.
YN: - Har jeg ikke fikset det? Vel, selvfølgelig gjør det det! Dette er forskjellige produkter - jeg bare lurte deg hele denne tiden. Ok, jeg tuller - det spiller ingen rolle. Ah, akkurat her! Nei, det er det samme, jeg skrev en skrivefeil.
Z: - Takk skal du ha. Det andre spørsmålet er alvorlig. Så vidt jeg forstår, i Clickhouse, lever buffertabeller utelukkende i minnet, er ikke bufret til disk og er følgelig ikke vedvarende.
YN: - Ja.
Z: – Og samtidig buffere klienten til disk, noe som innebærer en viss garanti for levering av de samme loggene. Men dette er på ingen måte garantert hos Clickhouse. Forklar hvordan garantien utføres, på grunn av hva?.. Her er denne mekanismen mer detaljert
YN: – Ja, teoretisk er det ingen motsetninger her, for når Clickhouse faller, kan du faktisk oppdage det på en million forskjellige måter. Hvis Clickhouse krasjer (hvis den ender feil), kan du grovt sett spole tilbake litt av loggen din som du skrev ned og starte fra det øyeblikket alt var helt i orden. La oss si at du spoler et minutt tilbake, det vil si at det anses som at du har spylt alt på et minutt.
Z: – Det vil si at «Kattungehus» holder vinduet lenger og kan, ved fall, gjenkjenne det og spole det tilbake?
YN: – Men dette er i teorien. I praksis gjør vi ikke dette, og pålitelig levering er fra null til uendelig tid. Men i gjennomsnitt en. Vi er fornøyd med at hvis Clickhouse krasjer av en eller annen grunn eller serverne "starter på nytt", så taper vi litt. I alle andre tilfeller vil ingenting skje.
Z: - Hallo. Helt fra begynnelsen virket det for meg at du faktisk ville bruke UDP helt fra begynnelsen av rapporten. Du har http, alt det der... Og de fleste problemene du beskrev, slik jeg forstår det, var forårsaket av denne spesielle løsningen...
YN: – Hva bruker vi TCP?
Z: - I hovedsak ja.
YN: - Ikke.
Z: – Det var med fasthttp du hadde problemer, med tilkoblingen du hadde problemer. Hvis du bare hadde brukt UDP, ville du ha spart deg selv for litt tid. Vel, det ville være problemer med lange meldinger eller noe annet...
YN: - Med hva?
Z: – Med lange meldinger, siden det kanskje ikke passer inn i MTU, noe annet... Vel, det kan være deres egne problemer. Spørsmålet er: hvorfor ikke UDP?
YN: – Jeg tror at forfatterne som utviklet TCP/IP er mye smartere enn meg og vet bedre enn meg hvordan de skal serialisere pakker (slik at de går), samtidig justere sendevinduet, ikke overbelaste nettverket, gi tilbakemelding på hva er ikke lest, teller ikke på den andre siden... Alle disse problemene, etter min mening, ville eksistere i UDP, bare jeg måtte skrive enda mer kode enn jeg allerede skrev for å implementere det samme selv og mest sannsynlig dårlig. Jeg liker ikke engang å skrive i C, enn si der...
Z: - Bare praktisk! Sendt ok og ikke vent på noe - det er helt asynkront. Et varsel kom tilbake om at alt var i orden - det betyr at det kom; Hvis det ikke kommer, betyr det at det er dårlig.
YN: – Jeg trenger begge deler – jeg må kunne sende både med leveringsgaranti og uten leveringsgaranti. Dette er to forskjellige scenarier. Jeg trenger å ikke miste noen logger eller ikke miste dem innenfor rimelighetens grenser.
Z: – Jeg vil ikke kaste bort tid. Dette må diskuteres mer. Takk skal du ha.
moderator: – Hvem har spørsmål – hendene til himmelen!
Z: - Hei, jeg er Sasha. Et sted midt i rapporten dukket det opp en følelse av at det i tillegg til TCP var mulig å bruke en ferdig løsning – en slags Kafka.
YN: – Vel... Jeg fortalte deg at jeg ikke vil bruke mellomservere, fordi... i Kafka viser det seg at vi har ti tusen verter; faktisk har vi flere - titusenvis av verter. Det kan også være smertefullt å gjøre med Kafka uten noen proxyer. I tillegg, viktigst av alt, gir det fortsatt "latency", det gir ekstra verter som du trenger å ha. Men jeg vil ikke ha dem - jeg vil...
Z: "Men til slutt ble det sånn likevel."
YN: – Nei, det er ingen verter! Alt dette fungerer på Clickhouse-verter.
Z: - Vel, og "Kittenhus", som er omvendt - hvor bor han?
YN: – På Clickhouse-verten skriver den ikke noe til disken.
Z: - La oss anta.
moderator: - Er du fornøyd? Kan vi gi deg lønn?
Z: - Ja det kan du. Faktisk er det mange krykker for å få det samme, og nå - det forrige svaret om temaet TCP motsier, etter min mening, denne situasjonen. Det føles bare som om alt kunne vært gjort på knærne mine på mye kortere tid.
YN: – Og også hvorfor jeg ikke ville bruke Kafka, fordi det var ganske mange klager i Clickhouse Telegram-chatten om at for eksempel meldinger fra Kafka gikk tapt. Ikke fra Kafka selv, men i integrasjonen av Kafka og Clickhaus; eller noe henger ikke sammen der. Grovt sett ville det vært nødvendig å skrive en klient for Kafka da. Jeg tror ikke det kan være en enklere eller mer pålitelig løsning.
Z: – Si meg, hvorfor prøvde du ikke noen køer eller en slags felles buss? Siden du sier at med asynkron kan du sende loggene selv gjennom køen og motta svaret asynkront gjennom køen?
YN: – Vennligst foreslå hvilke køer som kan brukes?
Z: – Alle, selv uten garanti for at de er i orden. En slags Redis, RMQ...
YN: – Jeg har en følelse av at Redis mest sannsynlig ikke vil være i stand til å trekke et slikt volum av innsetting selv på én vert (i betydningen flere servere) som trekker ut Clickhouse. Jeg kan ikke sikkerhetskopiere dette med noen bevis (jeg har ikke benchmarked det), men det virker for meg som at Redis ikke er den beste løsningen her. I prinsippet kan dette systemet betraktes som en improvisert meldingskø, men som kun er skreddersydd for "Clickhouse"
moderator: – Yuri, tusen takk. Jeg foreslår å avslutte spørsmålene og svarene her og si hvem av de som stilte spørsmålet vi skal gi boken til.
YN: – Jeg vil gjerne gi en bok til den første personen som stilte et spørsmål.
moderator: - Herlig! Flott! Fabelaktig! Takk så mye!
Noen annonser 🙂
Takk for at du bor hos oss. Liker du artiklene våre? Vil du se mer interessant innhold? Støtt oss ved å legge inn en bestilling eller anbefale til venner, , en unik analog av entry-level servere, som ble oppfunnet av oss for deg: (tilgjengelig med RAID1 og RAID10, opptil 24 kjerner og opptil 40 GB DDR4).
Dell R730xd 2x billigere i Equinix Tier IV datasenter i Amsterdam? Bare her i Nederland! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - fra $99! Lese om
Kilde: www.habr.com