HighLoad++ Moskou 2018, Congreszaal. 9 november, 15:00 uur
Samenvattingen en presentatie:
Yuri Nasretdinov (VKontakte): het rapport zal vertellen over de ervaringen met de implementatie van ClickHouse in ons bedrijf - waarom we het nodig hebben, hoeveel gegevens we opslaan, hoe we het schrijven, enzovoort.
Aanvullende materialen:
Joeri Nasretdinov: - Dag Allemaal! Mijn naam is Yuri Nasretdinov, zoals ik al ben voorgesteld. Ik werk bij VKontakte. Ik zal het hebben over hoe we gegevens in ClickHouse invoegen vanaf onze servervloot (tienduizenden).
Wat zijn logbestanden en waarom worden deze verzameld?
Wat we u zullen vertellen: wat we deden, waarom we respectievelijk “ClickHouse” nodig hadden, waarom we ervoor kozen, wat voor soort prestaties u ongeveer kunt krijgen zonder iets speciaals te configureren. Ik vertel je verder over buffertabellen, over de problemen die we ermee hadden en over onze oplossingen die we vanuit open source ontwikkelden: KittenHouse en Lighthouse.
Waarom moesten we überhaupt iets doen (alles is altijd goed op VKontakte, toch?). We wilden debuglogs verzamelen (en daar waren honderden terabytes aan gegevens), misschien zou het op de een of andere manier handiger zijn om statistieken te berekenen; en we hebben een vloot van tienduizenden servers waarop dit allemaal moet gebeuren.
Waarom hebben we besloten? We hadden waarschijnlijk oplossingen voor het opslaan van logboeken. Hier – er is zo’n openbare “Backend VK”. Ik raad je ten zeerste aan om je erop te abonneren.
Wat zijn logboeken? Dit is een engine die lege arrays retourneert. Engines in VK zijn wat anderen microservices noemen. En hier is een lachende sticker (behoorlijk veel likes). Hoe komt het? Nou, luister verder!
Wat kan worden gebruikt om logboeken op te slaan? Het is onmogelijk om Hadup niet te noemen. Vervolgens bijvoorbeeld Rsyslog (deze logs opslaan in bestanden). LSD. Wie weet wat LSD is? Nee, niet deze LSD. Bewaar ook bestanden. Nou, ClickHouse is een vreemde optie.
Clickhouse en concurrenten: vereisten en kansen
Wat willen we? We willen ervoor zorgen dat we ons niet al te veel zorgen hoeven te maken over de bediening, zodat deze out-of-the-box werkt, het liefst met minimale configuratie. We willen veel schrijven en snel schrijven. En we willen het maanden, jaren, dat wil zeggen, voor een lange tijd bewaren. We willen misschien een probleem begrijpen waarmee ze naar ons toe kwamen en zeiden: "Er werkt hier iets niet", en dat was drie maanden geleden), en we willen kunnen zien wat er drie maanden geleden is gebeurd " Datacompressie – het is duidelijk waarom dit een pluspunt zou zijn – omdat het de hoeveelheid ruimte die het inneemt vermindert.
En we hebben zo'n interessante vereiste: we schrijven soms de uitvoer van sommige opdrachten (bijvoorbeeld logs), deze kan vrij gemakkelijk meer dan 4 kilobytes zijn. En als dit ding via UDP werkt, hoeft het geen geld uit te geven... het heeft geen "overhead" voor de verbinding, en voor een groot aantal servers zal dit een pluspunt zijn.
Laten we eens kijken wat open source ons biedt. Ten eerste hebben we de Logs Engine - dit is onze engine; In principe kan hij alles, hij kan zelfs lange regels schrijven. Welnu, het comprimeert gegevens niet op transparante wijze - we kunnen grote kolommen zelf comprimeren als we dat willen... dat willen we natuurlijk niet (indien mogelijk). Het enige probleem is dat hij alleen kan weggeven wat in zijn geheugen past; Om de rest te lezen, heb je de binlog van deze engine nodig en daarom duurt het behoorlijk lang.
Welke andere opties zijn er? Bijvoorbeeld 'Hadup'. Bedieningsgemak... Wie denkt dat Hadup eenvoudig te installeren is? Uiteraard zijn er geen problemen met de opname. Bij het lezen rijzen er soms vragen. In principe zou ik zeggen: waarschijnlijk niet, vooral voor logs. Opslag op lange termijn - natuurlijk, ja, datacompressie - ja, lange reeksen - het is duidelijk dat je kunt opnemen. Maar opnemen vanaf een groot aantal servers... Je moet toch zelf iets doen!
Rsyslog. In feite hebben we het als back-upoptie gebruikt, zodat we het konden lezen zonder de binlog te dumpen, maar het kan geen lange regels schrijven; in principe kan het niet meer dan 4 kilobytes schrijven. Datacompressie moet u zelf op dezelfde manier uitvoeren. Het lezen komt uit bestanden.
Dan is er de ‘badushka’-ontwikkeling van LSD. In wezen hetzelfde als "Rsyslog": het ondersteunt lange strings, maar het kan niet via UDP werken en daarom moeten er helaas heel wat dingen herschreven worden. LSD moet opnieuw worden ontworpen om te kunnen opnemen vanaf tienduizenden servers.
En hier! Een grappige optie is ElasticSearch. Hoe zeg je? Hij doet het goed met lezen, dat wil zeggen, hij leest snel, maar niet zo goed met schrijven. Ten eerste is het erg zwak als het gegevens comprimeert. Hoogstwaarschijnlijk vereist een volledige zoekopdracht grotere datastructuren dan het oorspronkelijke volume. Het is lastig te bedienen en er ontstaan vaak problemen mee. En nogmaals, opnemen in Elastic - we moeten alles zelf doen.
Hier is ClickHouse natuurlijk een ideale optie. Het enige is dat opnemen vanaf tienduizenden servers een probleem is. Maar er is tenminste één probleem, we kunnen proberen het op de een of andere manier op te lossen. En de rest van het rapport gaat over dit probleem. Welke prestaties kunt u van ClickHouse verwachten?
Hoe gaan we het invoegen? Boom samenvoegen
Wie van jullie heeft nog nooit gehoord van “ClickHouse” of kent het niet? Ik moet het je vertellen, nietwaar? Erg snel. De invoeging daar - 1-2 gigabits per seconde, bursts tot 10 gigabits per seconde kunnen deze configuratie daadwerkelijk weerstaan - er zijn twee 6-core Xeons (dat wil zeggen, niet eens de krachtigste), 256 gigabyte RAM, 20 terabytes in RAID (niemand geconfigureerd, standaardinstellingen). Alexey Milovidov, ClickHouse-ontwikkelaar, zit daar waarschijnlijk te huilen omdat we niets hebben geconfigureerd (alles werkte zo voor ons). Dienovereenkomstig kan een scansnelheid van bijvoorbeeld ongeveer 6 miljard regels per seconde worden verkregen als de gegevens goed worden gecomprimeerd. Als je % op een tekstreeks leuk vindt - 100 miljoen regels per seconde, dan lijkt het behoorlijk snel.
Hoe gaan we het invoegen? Nou, je weet dat VK PHP gebruikt. We zullen van elke PHP-werker via HTTP invoegen in “ClickHouse”, in de MergeTree-tabel voor elk record. Wie ziet een probleem in dit plan? Om de een of andere reden stak niet iedereen zijn hand op. Laat me het je vertellen.
Ten eerste zijn er veel servers - dienovereenkomstig zullen er veel verbindingen zijn (slecht). Dan kun je beter niet vaker dan één keer per seconde gegevens in MergeTree invoegen. En wie weet waarom? Oke oke. Ik zal je hier wat meer over vertellen. Een andere interessante vraag is dat we geen analyses uitvoeren, dat we de gegevens niet hoeven te verrijken, dat we geen tussenliggende servers nodig hebben, dat we deze rechtstreeks in “ClickHouse” willen invoegen (bij voorkeur: hoe directer, hoe beter).
Hoe gebeurt het invoegen in MergeTree? Waarom is het beter om er niet vaker dan één keer per seconde of minder vaak in te plaatsen? Feit is dat “ClickHouse” een kolomvormige database is en de gegevens sorteert in oplopende volgorde van de primaire sleutel, en wanneer u een invoeging uitvoert, wordt er een aantal bestanden aangemaakt dat minimaal gelijk is aan het aantal kolommen waarin de gegevens zijn gesorteerd in oplopende volgorde van de primaire sleutel (er wordt een aparte map aangemaakt, een set bestanden op schijf voor elke invoeging). Dan komt de volgende invoeging en op de achtergrond worden ze gecombineerd tot grotere "partities". Omdat de gegevens gesorteerd zijn, is het mogelijk om twee gesorteerde bestanden samen te voegen zonder veel geheugen te verbruiken.
Maar zoals u wellicht wel kunt raden, zal ClickHouse (of uw server) snel eindigen als u voor elke invoeging 10 bestanden schrijft, dus het wordt aanbevolen om in grote batches in te voegen. Dienovereenkomstig hebben we het eerste schema nooit in productie genomen. We hebben er meteen een gelanceerd, die hier nr. 2 heeft:
Stel je voor dat er ongeveer duizend servers zijn waarop we zijn gelanceerd, er is alleen PHP. En op elke server bevindt zich onze lokale agent, die we “Kittenhouse” noemden, die één verbinding onderhoudt met “ClickHouse” en elke paar seconden gegevens invoegt. Voegt gegevens niet in MergeTree in, maar in een buffertabel, wat precies dient om te voorkomen dat ze meteen rechtstreeks in MergeTree worden ingevoegd.
Werken met buffertabellen
Wat het is? Buffertabellen zijn een stukje geheugen dat wordt geshard (dat wil zeggen dat het er regelmatig in kan worden ingevoegd). Ze bestaan uit meerdere stukken, en elk van de stukken werkt als een onafhankelijke buffer, en ze worden onafhankelijk gespoeld (als je veel stukken in de buffer hebt, dan zullen er veel inserts per seconde zijn). Het is mogelijk om uit deze tabellen te lezen - dan lees je de vereniging van de inhoud van de buffer en de bovenliggende tabel, maar op dit moment is het schrijven geblokkeerd, dus het is beter om vanaf daar niet te lezen. En buffertabellen laten een zeer goede QPS zien, dat wil zeggen dat u tot 3 QPS helemaal geen problemen zult ondervinden bij het invoegen. Het is duidelijk dat als de server stroom verliest, de gegevens verloren kunnen gaan, omdat deze alleen in het geheugen zijn opgeslagen.
Tegelijkertijd maakt het schema met een buffer ALTER ingewikkeld, omdat je eerst de oude buffertabel met het oude schema moet laten vallen (de gegevens verdwijnen nergens, omdat deze worden leeggemaakt voordat de tabel wordt verwijderd). Vervolgens “wijzigt” u de tabel die u nodig heeft en maakt u de buffertabel opnieuw aan. Dienovereenkomstig, hoewel er geen buffertabel is, zullen uw gegevens nergens heen stromen, maar u kunt ze op zijn minst lokaal op schijf hebben.
Wat is Kittenhouse en hoe werkt het?
Wat is KittenHouse? Dit is een proxy. Raad eens welke taal? Ik heb de meest hype-onderwerpen in mijn rapport verzameld - "Clickhouse", Go, misschien herinner ik me nog iets anders. Ja, dit is geschreven in Go, want ik weet niet echt hoe ik in C moet schrijven, dat wil ik niet.
Dienovereenkomstig onderhoudt het een verbinding met elke server en kan het naar het geheugen schrijven. Als we bijvoorbeeld foutenlogboeken naar Clickhouse schrijven, en Clickhouse geen tijd heeft om gegevens in te voegen (als er immers te veel wordt geschreven), dan vergroten we het geheugen niet - we gooien gewoon de rest weg. Want als we meerdere gigabits per seconde aan fouten schrijven, kunnen we er waarschijnlijk een aantal weggooien. Kittenhouse kan dit doen. Bovendien kan het betrouwbare levering uitvoeren, dat wil zeggen schrijven naar schijf op de lokale machine en elke keer (daar, elke paar seconden) probeert het gegevens uit dit bestand af te leveren. En in eerste instantie gebruikten we het reguliere Waarden-formaat - niet een of ander binair formaat, een tekstformaat (zoals in gewone SQL).
Maar toen gebeurde dit. We gebruikten betrouwbare levering, schreven logs en besloten toen (het was een voorwaardelijk testcluster)... Het werd enkele uren uitgezet en weer opgestart, en het invoegen begon vanaf duizend servers - het bleek dat Clickhouse nog steeds een "Thread on Connection" - dienovereenkomstig leidt een actieve invoeging bij duizend verbindingen tot een gemiddelde belasting op de server van ongeveer anderhalf duizend. Verrassend genoeg accepteerde de server verzoeken, maar de gegevens werden na enige tijd nog steeds ingevoegd; maar het was erg moeilijk voor de server om het te serveren. . .
Voeg nginx toe
Een dergelijke oplossing voor het Thread per Connection-model is nginx. We installeerden nginx vóór Clickhouse, stelden tegelijkertijd de balancering in voor twee replica's (onze invoegsnelheid werd tweemaal verhoogd, hoewel het geen feit is dat dit het geval zou moeten zijn) en beperkten het aantal verbindingen met Clickhouse, tot de stroomopwaarts en dus meer dan bij 2 verbindingen lijkt het geen zin te hebben om in te voegen.
Toen realiseerden we ons dat dit schema over het algemeen nadelen heeft, omdat we hier maar één nginx hebben. Als deze nginx crasht, ondanks de aanwezigheid van replica's, verliezen we dus gegevens of schrijven we in ieder geval nergens. Daarom hebben we onze eigen load-balancing gemaakt. We realiseerden ons ook dat "Clickhouse" nog steeds geschikt is voor logs, en de "demon" begon ook zijn logs in "Clickhouse" te schrijven - erg handig, om eerlijk te zijn. We gebruiken het nog steeds voor andere “demonen”.
Toen ontdekten we dit interessante probleem: als je een niet-standaard invoegmethode in de SQL-modus gebruikt, forceert dit een volwaardige op AST gebaseerde SQL-parser, wat behoorlijk traag is. Daarom hebben we instellingen toegevoegd om ervoor te zorgen dat dit nooit gebeurt. We hebben loadbalancing en gezondheidscontroles uitgevoerd, zodat als er iemand sterft, we de gegevens nog steeds achterlaten. We hebben nu behoorlijk wat tafels die we nodig hebben voor verschillende Clickhouse-clusters. En we begonnen ook na te denken over andere toepassingen. We wilden bijvoorbeeld logs schrijven van nginx-modules, maar ze weten niet hoe ze moeten communiceren met behulp van onze RPC. Nou, ik zou ze graag willen leren hoe ze op zijn minst op de een of andere manier kunnen verzenden - bijvoorbeeld om evenementen op localhost via UDP te ontvangen en ze vervolgens door te sturen naar Clickhouse.
Eén stap verwijderd van de oplossing
Het uiteindelijke schema begon er als volgt uit te zien (de vierde versie van dit schema): op elke server voor Clickhouse staat nginx (op dezelfde server) en deze proxy's eenvoudigweg verzoeken naar localhost met een limiet op het aantal verbindingen van 50 stukken. En dit schema werkte al behoorlijk, alles was er redelijk goed mee.
Zo hebben we ongeveer een maand geleefd. Iedereen was blij, ze voegden tabellen toe, ze voegden toe, ze voegden toe... Over het algemeen bleek dat de manier waarop we buffertabellen toevoegden niet erg optimaal was (laten we het zo zeggen). We deden 16 stukken in elke tafel en een flitsinterval van een paar seconden; we hadden 20 tafels en elke tafel ontving 8 inserts per seconde - en op dit punt begon "Clickhouse"... de records begonnen te vertragen. Ze gingen niet eens door... Nginx had standaard zoiets interessants dat als de verbindingen stroomopwaarts eindigden, het eenvoudigweg "502" retourneerde aan alle nieuwe verzoeken.
En hier hebben we (ik heb zojuist naar de logbestanden in Clickhouse zelf gekeken) ongeveer een half procent van de verzoeken mislukt. Dienovereenkomstig was het schijfgebruik hoog en waren er veel fusies. Wat heb ik gedaan? Natuurlijk nam ik niet de moeite om erachter te komen waarom de verbinding en stroomopwaarts precies eindigde.
Nginx vervangen door een omgekeerde proxy
Ik besloot dat we dit zelf moeten beheren, we hoeven het niet aan nginx over te laten - nginx weet niet welke tabellen er in Clickhouse zijn, en ik heb nginx vervangen door een reverse proxy, die ik ook zelf heb geschreven.
Wat is hij aan het doen? Het werkt op basis van de fasthttp-bibliotheek “goshnoy”, dat wil zeggen snel, bijna net zo snel als nginx. Sorry, Igor, als je hier aanwezig bent (let op: Igor Sysoev is een Russische programmeur die de nginx-webserver heeft gemaakt). Het kan begrijpen wat voor soort vragen dit zijn – INSERT of SELECT – en beschikt daarom over verschillende verbindingspools voor verschillende soorten vragen.
Dienovereenkomstig, zelfs als we geen tijd hebben om de invoegverzoeken te voltooien, zullen de “selects” passeren, en omgekeerd. En het groepeert de gegevens in buffertabellen - met een kleine buffer: als er fouten, syntaxisfouten, enzovoort zijn - zodat deze de rest van de gegevens niet erg zouden beïnvloeden, want als we simpelweg buffertabellen invoegden, had een kleine "bachi", en alle syntaxisfouten hadden alleen betrekking op dit kleine stukje; en hier zullen ze al een grote buffer aantasten. Klein is 1 megabyte, dat wil zeggen niet zo klein.
Het invoegen van een synchronisatie en het feitelijk vervangen van nginx, doet in essentie hetzelfde als nginx voorheen deed - je hoeft hiervoor het lokale “Kittenhouse” niet te veranderen. En omdat het fasthttp gebruikt, is het erg snel: je kunt meer dan 100 verzoeken per seconde doen voor afzonderlijke invoegingen via een reverse proxy. Theoretisch kun je regel voor regel in de kittenhouse reverse proxy invoegen, maar dat doen wij natuurlijk niet.
Het schema begon er als volgt uit te zien: "Kittenhouse", de omgekeerde proxy groepeert veel verzoeken in tabellen en op zijn beurt voegen de buffertabellen ze in de belangrijkste in.
Killer is een tijdelijke oplossing, Kitten is permanent
Dit is een interessant probleem... Heeft iemand van jullie fasthttp gebruikt? Wie gebruikte fasthttp met POST-verzoeken? Waarschijnlijk had dit eigenlijk niet moeten gebeuren, omdat het standaard de hoofdtekst van het verzoek buffert en onze buffergrootte was ingesteld op 16 megabytes. Op een gegeven moment stopte de invoeging en kwamen er stukjes van 16 megabyte binnen van alle tienduizenden servers, en ze werden allemaal in het geheugen gebufferd voordat ze naar Clickhouse werden gestuurd. Dienovereenkomstig raakte het geheugen op, de Out-Of-Memory Killer kwam en doodde de reverse proxy (of "Clickhouse", die theoretisch meer zou kunnen "eten" dan de reverse proxy). De cyclus herhaalde zich. Geen erg prettig probleem. Hoewel we dit pas na enkele maanden gebruik tegenkwamen.
Wat ik heb gedaan? Nogmaals, ik begrijp niet zo graag wat er precies is gebeurd. Ik denk dat het vrij duidelijk is dat je niet in het geheugen moet bufferen. Ik kon fasthttp niet patchen, hoewel ik het probeerde. Maar ik vond een manier om het zo te maken dat het niet nodig was om iets te patchen, en ik bedacht mijn eigen methode in HTTP - ik noemde het KITTEN. Nou, het is logisch - "VK", "Kitten"... Wat nog meer?...
Als er een verzoek bij de server binnenkomt met de Kitten-methode, moet de server logischerwijs "miauw" reageren. Als hij hierop reageert, wordt aangenomen dat hij dit protocol begrijpt, en dan onderschep ik de verbinding (fasthttp heeft zo'n methode) en gaat de verbinding in de "raw" modus. Waarom heb ik het nodig? Ik wil bepalen hoe het lezen van TCP-verbindingen gebeurt. TCP heeft een prachtige eigenschap: als niemand vanaf de andere kant leest, begint het schrijven te wachten en wordt er niet bijzonder veel geheugen aan besteed.
En zo lees ik van ongeveer 50 klanten tegelijk (van vijftig want vijftig zou zeker genoeg moeten zijn, ook al komt het tarief uit een ander DC)... Het verbruik is met deze aanpak zeker 20 keer gedaald, maar ik, eerlijk gezegd , ik kon niet precies meten hoe laat, omdat het al zinloos is (het heeft het foutenniveau al bereikt). Het protocol is binair, dat wil zeggen dat het de tabelnaam en gegevens bevat; er zijn geen http-headers, dus ik heb geen websocket gebruikt (ik hoef niet met browsers te communiceren - ik heb een protocol gemaakt dat aan onze behoeften voldoet). En alles ging goed met hem.
De buffertafel is triest
Onlangs kwamen we nog een interessant kenmerk van buffertabellen tegen. En dit probleem is al veel pijnlijker dan de andere. Laten we ons deze situatie eens voorstellen: u maakt al actief gebruik van Clickhouse, u beschikt over tientallen Clickhouse-servers en u heeft enkele verzoeken die erg lang duren om te lezen (laten we zeggen meer dan 60 seconden); en jij komt op dit moment Alter doen... In de tussentijd worden "selecties" die vóór "Alter" zijn begonnen, niet in deze tabel opgenomen, "Alter" zal niet starten - waarschijnlijk enkele kenmerken van hoe "Clickhouse" werkt deze plaats. Misschien kan dit opgelost worden? Of is het niet mogelijk?
Over het algemeen is het duidelijk dat dit in werkelijkheid niet zo'n groot probleem is, maar bij buffertabellen wordt het pijnlijker. Want als, laten we zeggen, je “Alter” time-outs (en het kan een time-out zijn op een andere host - niet die van jou, maar bijvoorbeeld op een replica), dan... Je hebt de buffertabel verwijderd, je “Alter” ( of een andere host) is een time-out opgetreden, dan is er een “Alter”-fout opgetreden) - u moet er nog steeds voor zorgen dat de gegevens verder worden geschreven: u maakt de buffertabellen terug (volgens hetzelfde schema als de bovenliggende tabel) en vervolgens “Alter” gaat door, eindigt tenslotte, en de buffer van de tabel begint qua schema te verschillen van de ouder. Afhankelijk van wat de "Alter" was, gaat de insert mogelijk niet langer naar deze buffertabel - dit is erg triest.
Er is ook zo'n bord (misschien heeft iemand het opgemerkt) - het heet query_thread_log in nieuwe versies van Clickhouse. Standaard was er in sommige versies één. Hier hebben we in een paar maanden tijd 840 miljoen records verzameld (100 gigabyte). Dit komt door het feit dat daar "inserts" zijn geschreven (misschien zijn ze nu trouwens niet geschreven). Zoals ik je vertelde, zijn onze “inserts” klein - we hadden veel “inserts” in de buffertabellen. Het is duidelijk dat dit is uitgeschakeld. Ik vertel je alleen wat ik op onze server heb gezien. Waarom? Dit is nog een argument tegen het gebruik van buffertabellen! Spotty is erg verdrietig.
Wie wist dat de naam van deze man Spotty was? VK-medewerkers staken hun hand op. OK.
Over de plannen voor “KitttenHouse”
Plannen worden meestal niet gedeeld, toch? Opeens zul je ze niet meer vervullen en zul je er in de ogen van anderen niet zo goed uitzien. Maar ik neem het risico! We willen het volgende doen: buffertabellen zijn volgens mij nog steeds een kruk en we moeten de invoeging zelf bufferen. Maar we willen het nog steeds niet op schijf bufferen, dus bufferen we de invoeging in het geheugen.
Dienovereenkomstig, wanneer een “insert” wordt gemaakt, zal deze niet langer synchroon zijn - hij zal al werken als een buffertabel, zal in de bovenliggende tabel worden ingevoegd (nou ja, op een dag later) en via een apart kanaal rapporteren welke inserts zijn gepasseerd en welke heb niet.
Waarom kan ik de synchrooninzet niet verlaten? Het is veel handiger. Het feit is dat als je vanaf 10 hosts invoegt, alles in orde is - je krijgt een klein beetje van elke host, als je daar een keer per seconde invoegt, is alles in orde. Maar ik zou graag willen dat dit schema bijvoorbeeld vanaf twee machines werkt, zodat je met hoge snelheid kunt downloaden - misschien niet het maximale uit Clickhouse haalt, maar minimaal 100 megabytes per seconde schrijft vanaf één machine via een reverse proxy - Hiervoor moet het schema worden geschaald naar zowel grote als kleine hoeveelheden, dus we kunnen niet voor elke invoeging een seconde wachten, dus het moet asynchroon zijn. En op dezelfde manier zouden asynchrone bevestigingen moeten komen nadat het invoegen is voltooid. We zullen weten of het voorbij is of niet.
Het belangrijkste is dat we in dit schema zeker weten of de invoeging heeft plaatsgevonden of niet. Stel je deze situatie eens voor: je hebt een buffertabel, je hebt er iets in geschreven, en dan, laten we zeggen, ging de tabel naar de alleen-lezen-modus en probeerde de buffer leeg te maken. Waar gaan de gegevens naartoe? Ze blijven in de buffer. Maar we kunnen hier niet zeker van zijn - wat als er een andere fout is, waardoor de gegevens niet in de buffer blijven... (Adressen Alexey Milovidov, Yandex, ClickHouse-ontwikkelaar) Of blijft dit zo? Altijd? Alexey overtuigt ons ervan dat alles goed komt. Wij hebben geen reden om hem niet te geloven. Maar toch: als we geen buffertabellen gebruiken, zullen er geen problemen mee zijn. Ook is het lastig om twee keer zoveel tabellen te maken, al zijn er in principe geen grote problemen. Dit is het plan.
Laten we het hebben over lezen
Laten we het nu over lezen hebben. We hebben hier ook onze eigen tool geschreven. Het lijkt erop, waarom zou je hier je eigen instrument schrijven? En wie heeft Tabix gebruikt? Op de een of andere manier staken weinig mensen hun hand op... En wie is tevreden over de prestaties van Tabix? Nou, we zijn er niet blij mee, en het is niet erg handig om gegevens te bekijken. Het is prima voor analyse, maar alleen voor weergave is het duidelijk niet geoptimaliseerd. Dus schreef ik mijn eigen, mijn eigen interface.
Het is heel eenvoudig: het kan alleen gegevens lezen. Hij weet niet hoe hij afbeeldingen moet weergeven, hij weet niet hoe hij iets moet doen. Maar het kan laten zien wat we nodig hebben: hoeveel rijen staan er bijvoorbeeld in de tabel, hoeveel ruimte deze in beslag neemt (zonder deze in kolommen op te splitsen), dat wil zeggen dat we een heel eenvoudige interface nodig hebben.
En het lijkt erg op Sequel Pro, maar alleen gemaakt op Twitter's Bootstrap en de tweede versie. Je vraagt: "Yuri, waarom in de tweede versie?" Welk jaar? 2018? Over het algemeen deed ik dit een hele tijd geleden voor “Muscle” (MySQL) en veranderde ik een paar regels in de queries daar, en het begon te werken voor “Clickhouse”, waarvoor speciale dank! Omdat de parser erg lijkt op de 'spier'-parser, en de zoekopdrachten erg op elkaar lijken - erg handig, vooral in het begin.
Welnu, het kan tabellen filteren, kan de structuur en inhoud van de tabel weergeven, stelt u in staat te sorteren, filteren op kolommen, toont de zoekopdracht die tot het resultaat heeft geleid, de betrokken rijen (hoeveel als resultaat), dat wil zeggen de basiszaken voor het bekijken van gegevens. Vrij snel.
Er is ook een redacteur. Ik heb eerlijk gezegd geprobeerd de hele editor van Tabix te stelen, maar dat lukte niet. Maar op de een of andere manier werkt het. In principe is dat alles.
"Clickhouse" is geschikt voor holen
Ik wil je vertellen dat Clickhouse, ondanks alle beschreven problemen, zeer geschikt is voor logs. Het belangrijkste is dat het ons probleem oplost: het is erg snel en u kunt logboeken op kolommen filteren. In principe hebben buffertabellen niet goed gepresteerd, maar meestal weet niemand waarom... Misschien weet u nu beter waar u problemen zult ondervinden.
TCP? Over het algemeen is het in VK gebruikelijk om UDP te gebruiken. En toen ik TCP gebruikte... Niemand zei natuurlijk tegen mij: “Yuri, waar heb je het over! Dat kan niet, je hebt UDP nodig.” Het bleek dat TCP niet zo eng is. Het enige is dat als je tienduizenden actieve verbindingen hebt die je schrijft, je deze wat zorgvuldiger moet voorbereiden; maar het is mogelijk, en vrij eenvoudig.
Ik heb beloofd om “Kittenhouse” en “Lighthouse” op HighLoad Siberia te posten als iedereen zich zou abonneren op onze openbare “VK-backend”... En weet je, niet iedereen heeft zich geabonneerd... Natuurlijk zal ik niet eisen dat je je abonneert op onze openbaar. Er zijn nog steeds te veel van jullie, iemand kan zelfs beledigd zijn, maar toch, abonneer je (en hier moet ik ogen maken als die van een kat). Dat is . Hartelijk dank! Github is van ons . Met Clickhouse wordt uw haar zacht en zijdeachtig.
leidend: - Vrienden, nu voor vragen. Direct daarna overhandigen wij het certificaat van waardering en uw rapport op VHS.
Yuri Nasretdinov (hierna YN genoemd): – Hoe kon je mijn verslag op VHS opnemen als het net was afgelopen?
leidend: – Je kunt ook niet volledig bepalen hoe “Clickhouse” zal werken of niet! Vrienden, 5 minuten voor vragen!
vragen
Vraag uit het publiek (hierna Q): - Goedemiddag. Hartelijk dank voor het rapport. Ik heb twee vragen. Ik begin met iets frivools: heeft het aantal letters t in de naam "Kittenhouse" in de diagrammen (3, 4, 7...) invloed op de tevredenheid van de katten?
JN: - Hoeveelheid van wat?
Z: – Letter t. Er zijn drie t's, ergens rond de drie t's.
JN: - Heb ik het niet opgelost? Nou ja, natuurlijk wel! Dit zijn verschillende producten. Ik heb je de hele tijd alleen maar bedrogen. Oké, ik maak een grapje, het maakt niet uit. Aha, hier! Nee, het is hetzelfde, ik heb een typefout gemaakt.
Z: - Bedankt. De tweede vraag is serieus. Voor zover ik het begrijp, leven buffertabellen in Clickhouse uitsluitend in het geheugen, worden ze niet op schijf gebufferd en zijn ze dienovereenkomstig niet persistent.
JN: - Ja.
Z: – En tegelijkertijd buffert uw client naar schijf, wat een zekere garantie impliceert voor de levering van dezelfde logbestanden. Maar dit is bij Clickhouse geenszins gegarandeerd. Leg uit hoe de garantie wordt uitgevoerd, vanwege wat?.. Hier is dit mechanisme in meer detail
JN: – Ja, theoretisch zijn er hier geen tegenstrijdigheden, want als Clickhouse valt, kun je dat op een miljoen verschillende manieren detecteren. Als Clickhouse crasht (als het verkeerd eindigt), kun je grofweg een stukje van je log terugspoelen die je hebt opgeschreven en beginnen vanaf het moment waarop alles precies in orde was. Laten we zeggen dat u een minuut terugspoelt, dat wil zeggen dat er wordt aangenomen dat u alles in een minuut hebt doorgespoeld.
Z: – Dat wil zeggen: “Kittenhouse” houdt het raam langer vast en kan het bij een val herkennen en terugdraaien?
JN: – Maar dit is in theorie. In de praktijk doen wij dit niet en is betrouwbare levering van nul tot oneindig. Maar gemiddeld één. We zijn tevreden dat als Clickhouse om de een of andere reden crasht of de servers opnieuw opstarten, we een beetje verliezen. In alle andere gevallen gebeurt er niets.
Z: - Hallo. Vanaf het allereerste begin leek het mij dat u inderdaad vanaf het begin van het rapport UDP zou gebruiken. Je hebt http, dat allemaal... En de meeste problemen die je beschreef, zoals ik het begrijp, werden veroorzaakt door deze specifieke oplossing...
JN: – Wat gebruiken we TCP?
Z: - In wezen wel.
JN: - Niet.
Z: – Het was met fasthttp dat je problemen had, met de verbinding had je problemen. Als je gewoon UDP had gebruikt, had je jezelf wat tijd bespaard. Nou ja, er zouden problemen zijn met lange berichten of iets anders...
JN: - Met wat?
Z: – Bij lange berichten, omdat het misschien niet in de MTU past, is er iets anders... Nou ja, er kunnen eigen problemen zijn. De vraag is: waarom niet UDP?
JN: – Ik geloof dat de auteurs die TCP/IP hebben ontwikkeld veel slimmer zijn dan ik en beter weten dan ik hoe ze pakketten moeten serialiseren (zodat ze gaan), en tegelijkertijd het verzendvenster moeten aanpassen, het netwerk niet kunnen overbelasten, feedback moeten geven over wat wordt niet gelezen, aan de andere kant niet meegerekend... Al deze problemen zouden naar mijn mening bestaan in UDP, alleen zou ik nog meer code moeten schrijven dan ik al heb geschreven om hetzelfde zelf te implementeren en hoogstwaarschijnlijk slecht. Ik hou niet eens zo van schrijven in C, laat staan daar...
Z: - Gewoon handig! Oké verzonden en wacht nergens op - het is volledig asynchroon. Er kwam een melding terug dat alles in orde was - dat betekent dat het arriveerde; Als het niet komt, betekent dit dat het slecht is.
JN: – Ik heb beide nodig – Ik moet zowel met leveringsgarantie als zonder leveringsgarantie kunnen verzenden. Dit zijn twee verschillende scenario's. Ik wil sommige logboeken niet kwijtraken of ze binnen redelijke grenzen kwijtraken.
Z: – Ik zal geen tijd verspillen. Dit moet meer besproken worden. Bedankt.
leidend: – Wie heeft vragen – handen naar de hemel!
Z: - Hallo, ik ben Sasha. Ergens midden in het rapport ontstond het gevoel dat het naast TCP mogelijk was om een kant-en-klare oplossing te gebruiken: een soort Kafka.
JN: – Nou... ik heb je gezegd dat ik geen tussenliggende servers wil gebruiken, omdat... in Kafka blijkt dat we tienduizend hosts hebben; sterker nog, we hebben er meer: tienduizenden hosts. Het kan ook pijnlijk zijn om met Kafka te doen zonder enige proxy's. Bovendien, het allerbelangrijkste, geeft het nog steeds “latency”, het geeft extra hosts die je nodig hebt. Maar ik wil ze niet hebben - ik wil...
Z: “Maar uiteindelijk is het toch zo geworden.”
JN: – Nee, er zijn geen hosts! Dit werkt allemaal op Clickhouse-hosts.
Z: - Nou ja, en "Kittenhouse", wat het omgekeerde is - waar woont hij?
JN: – Op de Clickhouse-host schrijft deze niets naar de schijf.
Z: - Laten we eens veronderstellen.
leidend: - Ben je tevreden? Mogen wij u een salaris geven?
Z: - Ja, dat kan. In feite zijn er veel krukken om hetzelfde te krijgen, en nu is het vorige antwoord over het onderwerp TCP naar mijn mening in tegenspraak met deze situatie. Het voelt gewoon alsof alles in veel minder tijd op mijn knieën had kunnen worden gedaan.
JN: – En ook waarom ik Kafka niet wilde gebruiken, want er kwamen nogal wat klachten binnen in de Clickhouse Telegram-chat dat bijvoorbeeld berichten van Kafka verloren gingen. Niet vanuit Kafka zelf, maar in de integratie van Kafka en Clickhaus; of daar is iets niet aangesloten. Grofweg zou het dan nodig zijn om een opdrachtgever voor Kafka te schrijven. Ik denk niet dat er een eenvoudigere of betrouwbaardere oplossing bestaat.
Z: – Vertel me eens, waarom heb je geen wachtrijen of een soort gewone bus geprobeerd? Omdat u zegt dat u met asynchronie de logboeken zelf door de wachtrij kunt sturen en het antwoord asynchroon via de wachtrij kunt ontvangen?
JN: – Kunt u voorstellen welke wachtrijen kunnen worden gebruikt?
Z: – Alle, zelfs zonder garantie dat ze in orde zijn. Een soort Redis, RMQ...
JN: – Ik heb het gevoel dat Redis hoogstwaarschijnlijk niet in staat zal zijn om zo'n invoegvolume op te halen, zelfs niet op één host (in de zin van meerdere servers) die Clickhouse eruit haalt. Ik kan dit niet ondersteunen met enig bewijs (ik heb het niet gebenchmarkt), maar het lijkt mij dat Redis hier niet de beste oplossing is. Dit systeem kan in principe worden beschouwd als een geïmproviseerde berichtenwachtrij, maar is alleen op maat gemaakt voor “Clickhouse”
leidend: – Joeri, heel erg bedankt. Ik stel voor om de vragen en antwoorden hier te beëindigen en te zeggen aan wie van degenen die de vraag hebben gesteld, wij het boek zullen geven.
JN: – Ik wil graag een boek geven aan de eerste persoon die een vraag stelt.
leidend: - Prachtig! Geweldig! Geweldig! Hartelijk bedankt!
Sommige advertenties 🙂
Bedankt dat je bij ons bent gebleven. Vind je onze artikelen leuk? Wil je meer interessante inhoud zien? Steun ons door een bestelling te plaatsen of door vrienden aan te bevelen, , een unieke analoog van servers op instapniveau, die door ons voor u is uitgevonden: (beschikbaar met RAID1 en RAID10, tot 24 cores en tot 40GB DDR4).
Dell R730xd 2x goedkoper in Equinix Tier IV datacenter in Amsterdam? Alleen hier in Nederland! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - vanaf $99! Lees over
Bron: www.habr.com