In april kwamen Avito-ingenieurs bijeen voor online vergaderingen met de belangrijkste ClickHouse-ontwikkelaar Alexey Milovidov en Kirill Shvakov, een Golang-ontwikkelaar van Integros. We bespraken hoe we een databasebeheersysteem gebruiken en welke moeilijkheden we tegenkomen.
Op basis van de bijeenkomst hebben we een artikel samengesteld met antwoorden van experts op vragen van ons en het publiek over back-ups, het opnieuw opslaan van gegevens, externe woordenboeken, het Golang-stuurprogramma en het updaten van ClickHouse-versies. Het kan nuttig zijn voor ontwikkelaars die al actief met het Yandex DBMS werken en geïnteresseerd zijn in het heden en de toekomst ervan. Standaard zijn de antwoorden van Alexey Milovidov, tenzij anders geschreven.
Wees voorzichtig, er staat veel tekst onder de snede. We hopen dat de inhoud met vragen u zal helpen navigeren.
Inhoud
Als u de tekst niet wilt lezen, kunt u de opname van de bijeenkomsten bekijken . Tijdcodes staan in de eerste reactie onder de video.
ClickHouse wordt voortdurend bijgewerkt, maar onze gegevens niet. Wat moet je eraan doen?
ClickHouse wordt voortdurend bijgewerkt en onze gegevens, die bij de uiteindelijke verwerking zijn geoptimaliseerd, worden niet bijgewerkt en bevinden zich in een back-up.
Stel dat we een probleem hebben en dat de gegevens verloren zijn gegaan. We besloten om te herstellen en het bleek dat de oude partities, die op de back-upservers zijn opgeslagen, heel anders zijn dan de momenteel gebruikte versie van ClickHouse. Wat te doen in een dergelijke situatie, en is het mogelijk?
Een situatie waarin u gegevens uit een back-up in een oud formaat hebt teruggezet, maar deze geen verbinding maakt met de nieuwe versie, is onmogelijk. Wij zorgen ervoor dat het dataformaat in ClickHouse altijd achterwaarts compatibel blijft. Dit is veel belangrijker dan achterwaartse compatibiliteit in functionaliteit als het gedrag van een zelden gebruikte functie is veranderd. De nieuwe versie van ClickHouse moet altijd de gegevens kunnen lezen die op schijf zijn opgeslagen. Dit is de wet.
Wat zijn de huidige best practices voor het maken van back-ups van gegevens van ClickHouse?
Hoe kunnen we back-ups maken, rekening houdend met het feit dat we de eindbewerkingen hebben geoptimaliseerd, een enorme database van terabytes en gegevens die bijvoorbeeld de afgelopen drie dagen zijn bijgewerkt, en dat er vervolgens geen procedures mee gebeuren?
We kunnen onze eigen oplossing bedenken en op de bash schrijven: verzamel deze back-upkopieën op die en die manier. Misschien is het niet nodig om iets te kruken en is de fiets al lang geleden uitgevonden?
Laten we beginnen met de best practices. Mijn collega's adviseren altijd om, in antwoord op vragen over back-ups, hen te herinneren aan de Yandex.Cloud-service, waar dit probleem al is opgelost. Maak er dus indien mogelijk gebruik van.
Er is geen totaaloplossing voor backups, honderd procent ingebouwd in ClickHouse. Er zijn enkele spaties die kunnen worden gebruikt. Om een complete oplossing te krijgen, zul je handmatig een beetje moeten sleutelen, of wrappers in de vorm van scripts moeten maken.
Ik begin met de eenvoudigste oplossingen en eindig met de meest geavanceerde, afhankelijk van de hoeveelheid data en de grootte van het cluster. Hoe groter het cluster, hoe complexer de oplossing wordt.
Als de tabel met gegevens slechts enkele gigabytes in beslag neemt, kunt u als volgt een back-up maken:
- Bewaar de tabeldefinitie, d.w.z. metadata − toon tabel maken.
- Maak een dump met behulp van de ClickHouse-client - kiezen * van tafel archiveren. Standaard ontvangt u een bestand in TabSeparated-formaat. Als u efficiënter wilt zijn, kunt u dit in Native formaat doen.
Als de hoeveelheid gegevens groter is, zal de back-up meer tijd en veel ruimte in beslag nemen. Dit wordt een logische back-up genoemd; deze is niet gebonden aan het ClickHouse-gegevensformaat. Als dit het geval is, kunt u als laatste redmiddel een back-up maken en deze uploaden naar MySQL voor herstel.
Voor meer geavanceerde gevallen heeft ClickHouse een ingebouwde mogelijkheid om een momentopname van partities in het lokale bestandssysteem te maken. Deze functie is beschikbaar als aanvraag wijzig de bevriezingspartitie van de tabel. Of gewoon tafel bevriezen wijzigen - dit is een momentopname van de hele tabel.
De momentopname wordt consistent gemaakt voor één tabel op één Shard. Dat wil zeggen dat het onmogelijk is om op deze manier een consistente momentopname van het hele cluster te maken. Maar voor de meeste taken bestaat een dergelijke noodzaak niet, en het is voldoende om op elke shard een verzoek uit te voeren en een consistente momentopname te verkrijgen. Het wordt gemaakt in de vorm van hardlinks en neemt daarom geen extra ruimte in beslag. Vervolgens kopieert u deze snapshot naar de backupserver of naar de opslag die u gebruikt voor backups.
Het herstellen van een dergelijke back-up is vrij eenvoudig. Maak eerst tabellen met behulp van bestaande tabeldefinities. Kopieer vervolgens de opgeslagen momentopnamen van de partities naar Directory-Detached voor deze tabellen en voer de query uit partitie bevestigen. Deze oplossing is zeer geschikt voor de grootste hoeveelheden gegevens.
Soms heb je iets nog coolers nodig - in gevallen waarin je tientallen of zelfs honderden terabytes op elke server en honderden servers hebt. Er is hier een oplossing die ik heb opgepikt van mijn collega's van Yandex.Metrica. Ik zou het niet iedereen aanraden - lees het en beslis zelf of het geschikt is of niet.
Eerst moet u verschillende servers met grote schijfplanken maken. Zet vervolgens op deze servers verschillende ClickHouse-servers op en configureer ze zo dat ze als een andere replica voor dezelfde shards werken. En gebruik dan een bestandssysteem of een tool op deze servers waarmee u snapshots kunt maken. Er zijn hier twee opties. De eerste optie is LVM-snapshots, de tweede optie is ZFS op Linux.
Daarna moet je elke dag een momentopname maken, deze zal liggen en wat ruimte in beslag nemen. Als de gegevens veranderen, zal de hoeveelheid ruimte uiteraard in de loop van de tijd toenemen. Deze momentopname kan op elk moment worden verwijderd en de gegevens worden hersteld, wat een vreemde oplossing. Bovendien moeten we deze replica's in de configuratie beperken, zodat ze geen leiders proberen te worden.
Zal het mogelijk zijn om een gecontroleerde vertraging van replica's in de schachten te organiseren?
Dit jaar ben je van plan om schachten te maken in ClickHouse. Zal het mogelijk zijn om daarin een gecontroleerde vertraging van replica's te organiseren? We willen het graag gebruiken om onszelf te beschermen tegen negatieve scenario’s met alters en andere veranderingen.
Is het mogelijk om een soort rollback uit te voeren voor wijzigingen? Neem bijvoorbeeld in een bestaande schacht en zeg dat u tot dit moment de wijzigingen toepast, en vanaf dit moment stopt u met het toepassen van de wijzigingen?
Als er een commando naar ons cluster komt en het verbreekt, dan hebben we een voorwaardelijke replica met een vertraging van een uur, waarbij we kunnen zeggen: laten we het op dit moment gebruiken, maar we zullen er de afgelopen tien minuten geen wijzigingen in aanbrengen?
Ten eerste over de gecontroleerde vertraging van replica's. Er was zo'n verzoek van gebruikers en we hebben een issue op Github gemaakt met het verzoek: "Als iemand dit nodig heeft, vind het leuk, zet dan een hartje." Niemand heeft geleverd en de kwestie is gesloten. U kunt deze mogelijkheid echter al krijgen door ClickHouse op te zetten. Toegegeven, pas vanaf versie 20.3.
ClickHouse voert voortdurend gegevens samen op de achtergrond. Wanneer een samenvoeging is voltooid, wordt een bepaalde set gegevens vervangen door een groter stuk. Tegelijkertijd blijven stukjes gegevens die er eerder waren, nog een tijdje op de schijf staan.
Ten eerste blijven ze opgeslagen zolang er geselecteerde zoekopdrachten zijn die er gebruik van maken, om een niet-blokkerende werking te bieden. Bepaalde zoekopdrachten kunnen eenvoudig worden gelezen uit oude brokken.
Ten tweede is er ook een tijdsdrempel: oude stukjes gegevens blijven acht minuten op de schijf staan. Deze acht minuten kunnen worden aangepast en zelfs in één dag worden omgezet. Dit kost schijfruimte: afhankelijk van de datastroom blijkt dat de data op de laatste dag niet alleen zullen verdubbelen, maar zelfs vijf keer zo groot kunnen worden. Maar als er een ernstig probleem is, kunt u de ClickHouse-server stopzetten en alles regelen.
Nu rijst de vraag hoe dit beschermt tegen veranderingen. Het is de moeite waard om hier dieper op in te gaan, omdat in oudere versies van ClickHouse de alter zo werkte dat hij eenvoudigweg direct van stuk veranderde. Bij sommige bestanden zit een stukje data, en dat doen we bijvoorbeeld drop-kolom wijzigen. Vervolgens wordt deze kolom fysiek uit alle chunks verwijderd.
Maar vanaf versie 20.3 is het wijzigingsmechanisme volledig veranderd, en nu zijn stukjes gegevens altijd onveranderlijk. Ze veranderen helemaal niet - alters werken nu op vrijwel dezelfde manier als merges. In plaats van ter plekke een stuk te vervangen, maken we een nieuw exemplaar. In het nieuwe deel worden bestanden die niet zijn gewijzigd hardlinks, en als we een kolom verwijderen, ontbreekt deze eenvoudigweg in het nieuwe deel. Het oude stuk wordt na acht minuten standaard verwijderd en hier kunt u de hierboven genoemde instellingen aanpassen.
Hetzelfde geldt voor wijzigingen zoals mutaties. Wanneer je dat doet wijzigen verwijderen of update wijzigen, het verandert het stuk niet, maar creëert een nieuw stuk. En verwijdert vervolgens de oude.
Wat moet ik doen als de tabelstructuur is veranderd?
Hoe herstel ik een back-up die met het oude schema is gemaakt? En de tweede vraag gaat over het geval met snapshots en bestandssysteemtools. Is Btrfs hier goed in plaats van ZFS op Linux LVM?
Als je dat doet partitie bevestigen partities met een andere structuur, dan zal ClickHouse u vertellen dat dit niet mogelijk is. Dit is de oplossing. De eerste is om een tijdelijke tabel van het MergeTree-type met de oude structuur te maken, daar gegevens aan toe te voegen met behulp van Attach en een alter-query te maken. Vervolgens kunt u deze gegevens kopiëren of overdragen en opnieuw bijvoegen, of gebruik maken van een verzoek wijzig de tabelverplaatsingspartitie.
De tweede vraag is nu of Btrfs gebruikt kan worden. Om te beginnen, als je LVM hebt, zijn LVM-snapshots voldoende, en het bestandssysteem kan ext4 zijn, het maakt niet uit. Met Btrts hangt alles af van uw ervaring met het gebruik ervan. Dit is een volwassen bestandssysteem, maar er zijn nog steeds enkele vermoedens over hoe alles in een bepaald scenario in de praktijk zal uitpakken. Ik zou dit niet aanraden, tenzij je Btrfs in productie hebt.
Wat zijn de huidige best practices op het gebied van het opnieuw harden van gegevens?
De kwestie van herharding is complex en veelzijdig. Er zijn hier verschillende mogelijke antwoorden. U kunt het van één kant bekijken en dit zeggen: ClickHouse heeft geen ingebouwde herhardingsfunctie. Maar ik ben bang dat dit antwoord voor niemand geschikt zal zijn. Daarom kun je de andere kant opgaan en zeggen dat ClickHouse veel manieren heeft om gegevens opnieuw te harden.
Als het cluster onvoldoende ruimte heeft of de belasting niet aankan, voegt u nieuwe servers toe. Maar deze servers zijn standaard leeg, er staan geen gegevens op, er is geen belasting. U moet de gegevens opnieuw rangschikken, zodat deze gelijkmatig over het nieuwe, grotere cluster worden verspreid.
De eerste manier waarop dit kan worden gedaan is door een deel van de partities met behulp van een verzoek naar nieuwe servers te kopiëren verander de tabelophaalpartitie. U had bijvoorbeeld partities per maand en u kopieert de eerste maand van 2017 naar een nieuwe server en kopieert vervolgens de derde maand naar een andere nieuwe server. En je doet dit totdat het min of meer gelijk wordt.
Overdracht kan alleen worden uitgevoerd voor partities die tijdens de opname niet veranderen. Voor nieuwe partities moet de opname worden uitgeschakeld, omdat de overdracht ervan niet atomair is. Anders krijg je duplicaten of gaten in de gegevens. Deze methode is echter praktisch en werkt behoorlijk effectief. Kant-en-klare gecomprimeerde partities worden via het netwerk verzonden, dat wil zeggen dat de gegevens niet worden gecomprimeerd of opnieuw gecodeerd.
Deze methode heeft één nadeel, en het hangt af van het sharding-schema, of u zich aan dit sharding-schema hebt verbonden en welke sharding-sleutel u had. In uw voorbeeld voor metrische gegevens is de sharding-sleutel de hash van het pad. Wanneer u een gedistribueerde tabel selecteert, gaat deze in één keer naar alle shards in het cluster en haalt daar gegevens vandaan.
Dit betekent dat het voor u eigenlijk niet uitmaakt welke gegevens op welke shard terecht zijn gekomen. Het belangrijkste is dat gegevens langs één pad op één shard terechtkomen, maar welke is niet belangrijk. In dit geval is het overbrengen van kant-en-klare partities perfect, omdat u bij bepaalde query's ook volledige gegevens ontvangt - of het nu vóór het opnieuw harden is of erna, het schema doet er niet echt toe.
Maar er zijn gevallen die complexer zijn. Als u op applicatielogicaniveau vertrouwt op een speciaal sharding-schema, dan bevindt deze client zich op die en die shard en kan het verzoek rechtstreeks daarheen worden verzonden, en niet naar de gedistribueerde tabel. Of u gebruikt een vrij recente versie van ClickHouse en heeft de instelling ingeschakeld optimaliseren en ongebruikte scherven overslaan. In dit geval wordt tijdens de selectiequery de expressie in de sectie Where geanalyseerd en wordt berekend welke shards moeten worden gebruikt volgens het sharding-schema. Dit werkt op voorwaarde dat de gegevens precies volgens dit sharding-schema worden gepartitioneerd. Als u ze handmatig opnieuw rangschikt, kan de correspondentie veranderen.
Dit is dus methode nummer één. En ik wacht op je antwoord, of de methode geschikt is, of laten we verder gaan.
Vladimir Kolobaev, hoofdsysteembeheerder bij Avito: Alexey, de methode die je noemde werkt niet erg goed als je de last moet spreiden, inclusief lezen. We kunnen een partitie nemen die maandelijks is en de vorige maand naar een ander knooppunt kunnen brengen, maar als er een verzoek voor deze gegevens komt, zullen we deze alleen laden. Maar we willen graag het hele cluster laden, omdat anders de gehele leesbelasting enige tijd door twee shards wordt verwerkt.
Alexey Milovidov: Het antwoord is hier vreemd: ja, het is slecht, maar het zou kunnen werken. Ik zal je precies uitleggen hoe. Het is de moeite waard om naar het laadscenario te kijken dat achter uw gegevens schuilgaat. Als dit monitoringgegevens betreft, kunnen we vrijwel zeker zeggen dat de overgrote meerderheid van de verzoeken om nieuwe gegevens gaat.
U hebt nieuwe servers geïnstalleerd, oude partities gemigreerd, maar ook de manier gewijzigd waarop nieuwe gegevens worden vastgelegd. En nieuwe gegevens zullen door het hele cluster worden verspreid. Dus na slechts vijf minuten zullen verzoeken voor de laatste vijf minuten het cluster gelijkmatig belasten; na een dag zullen verzoeken voor XNUMX uur het cluster gelijkmatig belasten. En verzoeken voor de voorgaande maand gaan helaas slechts naar een deel van de clusterservers.
Maar vaak heb je geen aanvragen specifiek voor februari 2019. Als verzoeken in 2019 binnenkomen, zullen ze hoogstwaarschijnlijk voor het hele 2019 gelden - voor een lange periode, en niet voor een klein bereik. En dergelijke verzoeken zullen het cluster ook gelijkmatig kunnen laden. Maar over het algemeen is uw opmerking volkomen juist dat dit een ad-hocoplossing is die de gegevens niet volledig gelijkmatig verdeelt.
Ik heb nog een paar punten om de vraag te beantwoorden. Eén ervan gaat over hoe je in eerste instantie een sharding-schema kunt ontwerpen, zodat het opnieuw sharden minder pijn zou veroorzaken. Dit is niet altijd mogelijk.
U beschikt bijvoorbeeld over monitoringgegevens. De monitoringgegevens groeien om drie redenen. De eerste is de accumulatie van historische gegevens. De tweede is de verkeersgroei. En de derde is een toename van het aantal dingen dat aan monitoring onderworpen is. Er zijn nieuwe microservices en statistieken die moeten worden opgeslagen.
Het is mogelijk dat hiervan de grootste stijging verband houdt met de derde reden: de toename van het gebruik van monitoring. En in dit geval is het de moeite waard om naar de aard van de belasting te kijken, wat de belangrijkste selectiequery's zijn. Basisselectiequery's zullen hoogstwaarschijnlijk gebaseerd zijn op een subset van statistieken.
Bijvoorbeeld CPU-gebruik op sommige servers door een bepaalde service. Het blijkt dat er een bepaalde subset van sleutels is waarmee u deze gegevens krijgt. En het verzoek zelf om deze gegevens is hoogstwaarschijnlijk vrij eenvoudig en wordt in tientallen milliseconden voltooid. Gebruikt voor monitoringservices en dashboards. Ik hoop dat ik dit goed begrijp.
Vladimir Kolobaev: Feit is dat we heel vaak een beroep doen op historische gegevens, omdat we de huidige situatie in realtime vergelijken met de historische. En het is voor ons belangrijk om snel toegang te hebben tot een grote hoeveelheid data, en ClickHouse doet daar uitstekend werk mee.
Je hebt volkomen gelijk, we ervaren de meeste leesverzoeken de afgelopen dag, zoals bij elk monitoringsysteem. Maar tegelijkertijd is de belasting van historische gegevens ook behoorlijk groot. Het komt eigenlijk van een waarschuwingssysteem dat elke dertig seconden rondgaat en tegen ClickHouse zegt: “Geef me de gegevens van de afgelopen zes weken. Bouw er nu een soort voortschrijdend gemiddelde van, en laten we de huidige waarde vergelijken met de historische waarde.
Ik zou willen zeggen dat we voor zulke zeer recente verzoeken nog een kleine tabel hebben waarin we slechts twee dagen aan gegevens opslaan, en de belangrijkste verzoeken vliegen erin. We sturen alleen grote historische query's naar de grote shardtabel.
Alexey Milovidov: Helaas blijkt het slecht toepasbaar voor jouw scenario, maar ik zal je een beschrijving vertellen van twee slechte en complexe sharding-schema's die niet hoeven te worden gebruikt, maar die worden gebruikt in de dienst van mijn vrienden.
Er is een hoofdcluster met Yandex.Metrica-evenementen. Gebeurtenissen zijn paginaweergaven, klikken en conversies. De meeste verzoeken gaan naar een specifieke website. U opent de Yandex.Metrica-service, u heeft een website - avito.ru, gaat naar het rapport en er wordt een verzoek ingediend voor uw website.
Maar er zijn andere verzoeken – analytisch en mondiaal – die door interne analisten worden gedaan. Voor het geval merk ik op dat interne analisten alleen verzoeken indienen voor Yandex-services. Maar toch nemen zelfs Yandex-services een aanzienlijk deel van alle gegevens in beslag. Dit zijn verzoeken niet voor specifieke tellers, maar voor bredere filtering.
Hoe organiseer je data zo dat alles efficiënt werkt voor één loket, en ook voor globale queries? Een ander probleem is dat het aantal verzoeken in ClickHouse voor het Metrics-cluster enkele duizenden per seconde bedraagt. Tegelijkertijd kan één ClickHouse-server niet-triviale verzoeken niet verwerken, bijvoorbeeld enkele duizenden per seconde.
De clustergrootte is zeshonderd servers. Als je simpelweg een gedistribueerde tabel over dit cluster trekt en daar enkele duizenden verzoeken naartoe stuurt, wordt het zelfs nog erger dan ze naar één server te sturen. Aan de andere kant wordt de optie dat de gegevens gelijkmatig worden verspreid en we bij alle servers gaan opvragen, onmiddellijk van de hand gewezen.
Er is een optie die diametraal tegenovergesteld is. Stel je voor dat we de gegevens over verschillende sites verdelen, en een verzoek voor één site naar één scherf gaat. Nu zal het cluster tienduizend verzoeken per seconde kunnen verwerken, maar op één shard zal elk verzoek te langzaam werken. Het zal niet langer schalen in termen van doorvoer. Vooral als dit de site avito.ru is. Ik zal het geheim niet onthullen als ik zeg dat Avito een van de meest bezochte sites in RuNet is. En het op één scherf verwerken zou waanzin zijn.
Daarom is het sharding-schema op een sluwere manier ontworpen. Het gehele cluster is verdeeld in een aantal clusters, die we lagen noemen. Elke cluster bevat tientallen tot enkele tientallen scherven. Er zijn in totaal negenendertig van dergelijke clusters.
Hoe schaalt dit allemaal? Het aantal clusters verandert niet; zoals het een paar jaar geleden negenendertig was, blijft dat zo. Maar binnen elk ervan verhogen we geleidelijk het aantal scherven naarmate we gegevens verzamelen. En het sharding-schema als geheel is als volgt: deze clusters zijn onderverdeeld in websites, en om te begrijpen welke website zich op welk cluster bevindt, wordt een aparte metabase in MySQL gebruikt. Eén site - op één cluster. En daarbinnen vindt sharding plaats op basis van bezoekers-ID's.
Bij het opnemen delen we ze door de rest van de deling van de bezoekers-ID. Maar bij het toevoegen van een nieuwe scherf verandert het scherfschema; we blijven splitsen, maar met een rest van de deling door een ander getal. Dit betekent dat één bezoeker zich al op meerdere servers bevindt en daar kun je niet op vertrouwen. Dit wordt uitsluitend gedaan om ervoor te zorgen dat de gegevens beter worden gecomprimeerd. En bij het doen van verzoeken gaan we naar de gedistribueerde tabel, die naar het cluster kijkt en toegang heeft tot tientallen servers. Dit is zo'n stom plan.
Maar mijn verhaal zal onvolledig zijn als ik niet zeg dat we dit plan hebben opgegeven. In het nieuwe schema hebben we alles veranderd en alle gegevens gekopieerd met behulp van clickhouse-copier.
In het nieuwe schema zijn alle sites verdeeld in twee categorieën: groot en klein. Ik weet niet hoe de drempel werd gekozen, maar het resultaat was dat grote sites worden geregistreerd op één cluster, waar er 120 shards zijn met elk drie replica's - dat wil zeggen 360 servers. En het sharding-schema is zodanig dat elk verzoek in één keer naar alle shards gaat. Als u nu een rapportpagina voor avito.ru in Yandex.Metrica opent, gaat het verzoek naar 120 servers. Er zijn weinig grote sites in RuNet. En de verzoeken zijn niet duizend per seconde, maar zelfs minder dan honderd. Dit alles wordt stilletjes opgegeten door de gedistribueerde tafel, die elk van hen verwerkt met 120 servers.
En het tweede cluster is voor kleine sites. Hier is een shardingschema op basis van de site-ID, en elke aanvraag gaat naar precies één shard.
ClickHouse heeft een Clickhouse-kopieerhulpprogramma. Kun je ons over haar vertellen?
Ik zal meteen zeggen dat deze oplossing omslachtiger en iets minder productief is. Het voordeel is dat de gegevens volledig worden uitgesmeerd volgens het patroon dat u opgeeft. Maar het nadeel van het hulpprogramma is dat het helemaal niet opnieuw wordt uitgevoerd. Het kopieert gegevens van het ene clusterschema naar een ander clusterschema.
Dit betekent dat u, om te kunnen werken, twee clusters moet hebben. Ze kunnen zich op dezelfde servers bevinden, maar desalniettemin worden de gegevens niet stapsgewijs verplaatst, maar gekopieerd.
Waren er bijvoorbeeld vier servers, nu zijn het er acht. U maakt een nieuwe gedistribueerde tabel op alle servers, nieuwe lokale tabellen en start clickhouse-copier, waarbij u daarin het werkschema aangeeft dat het van daaruit moet lezen, het nieuwe sharding-schema accepteert en de gegevens daarheen overbrengt. En op oude servers heb je anderhalf keer meer ruimte nodig dan nu, omdat de oude data erop moeten blijven staan, en de helft van dezelfde oude data daarbovenop komt. Als u van tevoren dacht dat de gegevens opnieuw moeten worden opgeslagen en er ruimte is, dan is deze methode geschikt.
Hoe werkt het Clickhouse-kopieerapparaat binnen? Het verdeelt al het werk in een reeks taken voor het verwerken van één partitie van één tabel op één scherf. Al deze taken kunnen parallel worden uitgevoerd, en clickhouse-copier kan in meerdere instanties op verschillende machines worden uitgevoerd, maar wat het voor één partitie doet, is niets meer dan een invoegselectie. De gegevens worden gelezen, gedecomprimeerd, opnieuw gepartitioneerd en vervolgens opnieuw gecomprimeerd, ergens naartoe geschreven en opnieuw gesorteerd. Dit is een zwaardere beslissing.
Je had een pilot-ding genaamd resharding. Wat met haar?
In 2017 had je een pilot-ding genaamd resharding. Er is zelfs een optie in ClickHouse. Zoals ik het begrijp is het niet van de grond gekomen. Kunt u mij vertellen waarom dit gebeurde? Het lijkt erg relevant te zijn.
Het hele probleem is dat als het nodig is om de aanwezige gegevens opnieuw te harden, er een zeer complexe synchronisatie nodig is om dit op atomaire wijze te doen. Toen we begonnen te kijken naar hoe deze synchronisatie werkt, werd het duidelijk dat er fundamentele problemen waren. En deze fundamentele problemen zijn niet alleen theoretisch, maar begonnen zich onmiddellijk in de praktijk te manifesteren in de vorm van iets dat heel eenvoudig kan worden verklaard: niets werkt.
Is het mogelijk om alle gegevens samen te voegen voordat deze naar langzame schijven worden verplaatst?
Vraag over TTL met de overstap naar langzame schijfoptie in het kader van samenvoegingen. Is er een andere manier dan via cron om alle onderdelen samen te voegen voordat ze naar langzame schijven worden verplaatst?
Het antwoord op de vraag is dat het mogelijk is om op de een of andere manier automatisch alle stukken in één te lijmen voordat ze worden overgebracht - nee. Ik denk niet dat dit nodig is. Je hoeft niet alle onderdelen tot één samen te voegen, maar reken er gewoon op dat ze automatisch naar langzame schijven worden overgebracht.
We hebben twee criteria voor overdrachtsregels. De eerste is zoals hij gevuld is. Als de huidige opslaglaag minder dan een bepaald percentage vrije ruimte heeft, selecteren we één deel en verplaatsen we dit naar langzamere opslag. Of beter gezegd, niet langzamer, maar de volgende - zoals u configureert.
Het tweede criterium is grootte. Het gaat om het verplaatsen van grote stukken. U kunt de drempel aanpassen aan de vrije ruimte op de snelle schijf, waarna de gegevens automatisch worden overgedragen.
Hoe migreer ik naar nieuwe versies van ClickHouse als er geen manier is om de compatibiliteit vooraf te controleren?
Dit onderwerp wordt regelmatig besproken rekening houdend met verschillende versies, en nog steeds. Hoe veilig is het om te upgraden van versie 19.11 naar 19.16 en bijvoorbeeld van 19.16 naar 20.3. Wat is de beste manier om naar nieuwe versies te migreren zonder vooraf de compatibiliteit in de sandbox te kunnen controleren?
Er zijn hier verschillende ‘gouden’ regels. Eerst - . Het is groot, maar er zijn aparte paragrafen over achterwaarts onverenigbare wijzigingen. Beschouw deze punten niet als een rode vlag. Dit zijn meestal kleine incompatibiliteiten die een randfunctionaliteit met zich meebrengen die u zeer waarschijnlijk niet gebruikt.
Ten tweede: als er geen manier is om de compatibiliteit in de sandbox te controleren en u onmiddellijk tijdens de productie wilt updaten, is de aanbeveling dat u dit niet hoeft te doen. Maak eerst een sandbox en test. Als er geen testomgeving is, heb je waarschijnlijk geen heel groot bedrijf, wat betekent dat je een deel van de gegevens naar je laptop kunt kopiëren en ervoor kunt zorgen dat alles daarop correct werkt. U kunt zelfs meerdere replica's lokaal op uw machine aanmaken. Of u kunt ergens in de buurt een nieuwe versie ophalen en daar een deel van de gegevens uploaden - dat wil zeggen: een geïmproviseerde testomgeving creëren.
Een andere regel is dat je een week na de release van de versie geen updates mag uitvoeren vanwege het opsporen van bugs in de productie en daaropvolgende snelle oplossingen. Laten we de nummering van ClickHouse-versies achterhalen om niet in de war te raken.
Er is versie 20.3.4. Het cijfer 20 geeft het bouwjaar aan - 2020. Vanuit het oogpunt van wat erin zit, doet dit er niet toe, dus we zullen er geen aandacht aan besteden. Volgende - 20.3. We verhogen het tweede getal - in dit geval 3 - elke keer dat we een release uitbrengen met nieuwe functionaliteit. Als we een functie aan ClickHouse willen toevoegen, moeten we dit aantal verhogen. Dat wil zeggen dat ClickHouse in versie 20.4 nog beter zal werken. Het derde cijfer is 20.3.4. Hier is 4 het aantal patchreleases waarin we geen nieuwe functies hebben toegevoegd, maar enkele bugs hebben opgelost. En 4 betekent dat we het vier keer hebben gedaan.
Denk niet dat dit iets verschrikkelijks is. Meestal kan de gebruiker de nieuwste versie installeren en deze werkt zonder problemen met uptime per jaar. Maar stel je voor dat in een functie voor het verwerken van bitmaps, die door onze Chinese kameraden is toegevoegd, de server crasht bij het doorgeven van onjuiste argumenten. Wij hebben de verantwoordelijkheid om dit op te lossen. We zullen een nieuwe patchversie uitbrengen en ClickHouse zal stabieler worden.
Als u ClickHouse in productie hebt en er is een nieuwe versie van ClickHouse uitgebracht met extra functies (20.4.1 is bijvoorbeeld de allereerste), haast u dan niet om deze op de eerste dag in productie te nemen. Waarom is het eigenlijk nodig? Als u ClickHouse nog niet gebruikt, kunt u het installeren en hoogstwaarschijnlijk komt alles goed. Maar als ClickHouse al stabiel werkt, houd dan de patches en updates in de gaten om te zien welke problemen we oplossen.
Kirill Sjvakov: Ik wil graag iets toevoegen over testomgevingen. Iedereen is erg bang voor testomgevingen en om de een of andere reden zijn ze van mening dat als je een heel groot ClickHouse-cluster hebt, de testomgeving niet minder of minstens tien keer kleiner zou moeten zijn. Het is helemaal niet zo.
Ik kan het je vertellen uit mijn eigen voorbeeld. Ik heb een project en er is ClickHouse. Onze testomgeving is speciaal voor hem: dit is een kleine virtuele machine in Hetzner voor twintig euro, waar werkelijk alles wordt ingezet. Om dit te doen, hebben we volledige automatisering in Ansible, en daarom maakt het in principe niet uit waar we heen moeten: naar hardwareservers of gewoon implementeren in virtuele machines.
Wat gedaan kan worden? Het zou leuk zijn om in de ClickHouse-documentatie een voorbeeld te geven over hoe je een klein cluster in je eigen huis kunt implementeren - maak in Docker, in LXC misschien een Ansible-playbook, omdat verschillende mensen verschillende implementaties hebben. Dit zal een hoop vereenvoudigen. Als je binnen vijf minuten een cluster neemt en implementeert, is het veel gemakkelijker om iets uit te zoeken. Dit is veel handiger, omdat het invoeren van een productieversie die je nog niet hebt getest een weg naar nergens is. Soms werkt het en soms niet. En daarom is hopen op succes slecht.
Maxim Kotyakov, senior backend-ingenieur Avito: Ik zal iets toevoegen over testomgevingen vanuit een reeks problemen waarmee grote bedrijven worden geconfronteerd. Wij beschikken over een volwaardig ClickHouse acceptatiecluster; het is qua dataschema’s en instellingen een exacte kopie van wat er in productie is. Dit cluster wordt ingezet in redelijk vervallen containers met een minimum aan resources. We schrijven daar een bepaald percentage van de productiegegevens, gelukkig is het mogelijk om de stream in Kafka te repliceren. Alles daar is gesynchroniseerd en geschaald - zowel in termen van capaciteit als stroom, en, in theorie, als alle andere dingen gelijk zijn, zou het zich in termen van metrieken moeten gedragen als productie. Alles wat potentieel explosief is, wordt eerst op deze standaard gerold en daar een aantal dagen achtergelaten totdat het klaar is. Maar deze oplossing is uiteraard duur en moeilijk en kent geen ondersteuningskosten.
Alexey Milovidov: Ik zal je vertellen hoe de testomgeving van onze vrienden van Yandex.Metrica eruit ziet. Eén cluster had zo'n 600 servers, een ander had er 360, en er is een derde en meerdere clusters. De testomgeving voor een ervan bestaat eenvoudigweg uit twee shards met elk twee replica's. Waarom twee scherven? Zodat je niet alleen bent. En er zouden ook replica's moeten zijn. Gewoon een bepaald minimumbedrag dat u zich kunt veroorloven.
In deze testomgeving kunt u controleren of uw zoekopdrachten werken en of er iets belangrijks kapot is. Maar vaak ontstaan er problemen van een heel andere aard, wanneer alles werkt, maar er zijn enkele kleine veranderingen in de belasting.
Laat me je een voorbeeld geven. We hebben besloten een nieuwe versie van ClickHouse te installeren. Het is op een testomgeving geplaatst en er zijn geautomatiseerde tests voltooid in Yandex.Metrica zelf, die gegevens over de oude en de nieuwe versie vergelijken en de hele pijplijn draaien. En natuurlijk groene tests van onze CI. Anders hadden we deze versie niet eens voorgesteld.
Alles is in orde. We beginnen over te gaan tot productie. Ik krijg een melding dat de belasting van de grafieken meerdere keren is toegenomen. We draaien de versie terug. Ik kijk naar de grafiek en zie: de belasting is feitelijk verschillende keren toegenomen tijdens de uitrol, en weer afgenomen toen ze uitrolden. Toen zijn we begonnen met het terugdraaien van de versie. En de last nam op dezelfde manier toe en viel op dezelfde manier terug. De conclusie is dus deze: de belasting is toegenomen door de indeling, niets verrassends.
Vervolgens was het lastig om collega’s te overtuigen de nieuwe versie te installeren. Ik zeg: “Het is oké, rol maar uit. Houd je vingers gekruist, alles zal werken. Nu is de belasting van de grafieken toegenomen, maar alles is in orde. Houd vol." Over het algemeen hebben we dit gedaan, en dat is alles: de versie is vrijgegeven voor productie. Maar bijna bij elke lay-out doen zich soortgelijke problemen voor.
Het is de bedoeling dat query's worden beëindigd, maar dat gebeurt niet. Waarom?
Een gebruiker, een soort analist, kwam naar mij toe en creëerde een verzoek om mijn ClickHouse-cluster te plaatsen. Een knooppunt of een heel cluster, afhankelijk van naar welke replica of shard de aanvraag is gegaan. Ik zie dat alle CPU-bronnen op deze server zich in een plank bevinden, alles is rood. Tegelijkertijd reageert ClickHouse zelf op verzoeken. En ik schrijf: “Laat me alstublieft zien, proceslijst, welk verzoek deze waanzin heeft veroorzaakt.”
Ik vind dit verzoek en schrijf er 'kill' naar toe. En ik zie dat er niets gebeurt. Mijn server staat in een plank, ClickHouse geeft me dan een aantal commando's, laat zien dat de server leeft en alles is geweldig. Maar ik heb degradatie in alle gebruikersverzoeken, degradatie begint met records in ClickHouse en mijn kill-query werkt niet. Waarom? Ik dacht dat het doden van zoekopdrachten bedoeld was om zoekopdrachten te doden, maar dat is niet het geval.
Nu zal er een nogal vreemd antwoord zijn. Het punt is dat query's doden geen query's doodt.
Query beëindigen vinkt een klein vakje aan met de naam "Ik wil dat deze query wordt gedood." En het verzoek zelf kijkt naar deze vlag bij het verwerken van elk blok. Als dit is ingesteld, werkt het verzoek niet meer. Het blijkt dat niemand het verzoek doodt, hij moet zelf alles controleren en stoppen. En dit zou moeten werken in alle gevallen waarin het verzoek zich in de staat bevindt van het verwerken van gegevensblokken. Het verwerkt het volgende gegevensblok, controleert de vlag en stopt.
Dit werkt niet in gevallen waarin het verzoek bij een bepaalde bewerking wordt geblokkeerd. Het is waar dat dit hoogstwaarschijnlijk niet jouw geval is, omdat het volgens jou heel veel serverbronnen gebruikt. Het is mogelijk dat dit niet werkt bij externe sortering en bij sommige andere details. Maar over het algemeen zou dit niet mogen gebeuren, het is een bug. En het enige dat ik kan aanbevelen is om ClickHouse te updaten.
Hoe bereken ik de responstijd onder leesbelasting?
Er is een tabel waarin itemaggregaten worden opgeslagen - verschillende tellers. Het aantal lijnen bedraagt ongeveer honderd miljoen. Is het mogelijk om op een voorspelbare responstijd te rekenen als je 1K RPS voor 1K items stort?
Afgaande op de context hebben we het over de leesbelasting, omdat er geen problemen zijn met schrijven - er kunnen zelfs duizend, zelfs honderdduizend en soms enkele miljoenen rijen worden ingevoegd.
Leesverzoeken zijn heel verschillend. In selectie 1 kan ClickHouse ongeveer tienduizenden verzoeken per seconde uitvoeren, dus zelfs verzoeken om één sleutel vereisen al enige bronnen. En dergelijke puntquery's zullen moeilijker zijn dan in sommige sleutelwaardedatabases, omdat het voor elke lezing noodzakelijk is om een blok gegevens per index te lezen. Onze index behandelt niet elk record, maar elk bereik. Dat wil zeggen dat u het hele bereik moet lezen - dit zijn standaard 8192 regels. En u zult het gecomprimeerde datablok moeten decomprimeren van 64 KB naar 1 MB. Normaal gesproken duurt het voltooien van dergelijke gerichte zoekopdrachten enkele milliseconden. Maar dit is de eenvoudigste optie.
Laten we wat eenvoudige rekenkunde proberen. Als je een paar milliseconden met duizend vermenigvuldigt, krijg je een paar seconden. Het is alsof het onmogelijk is om duizend verzoeken per seconde bij te houden, maar in feite is het mogelijk omdat we verschillende processorkernen hebben. In principe kan ClickHouse dus soms 1000 RPS bevatten, maar voor korte verzoeken zijn deze specifiek gericht.
Als u een ClickHouse-cluster moet schalen op basis van het aantal eenvoudige verzoeken, dan raad ik het eenvoudigste aan: verhoog het aantal replica's en stuur verzoeken naar een willekeurige replica. Als één replica vijfhonderd verzoeken per seconde bevat, wat volkomen realistisch is, dan kunnen drie replica’s er anderhalfduizend aan.
Soms kunt u ClickHouse uiteraard configureren voor het maximale aantal puntmetingen. Wat is hiervoor nodig? De eerste is het verminderen van de granulariteit van de index. In dit geval moet het niet worden teruggebracht tot één, maar moet ervan worden uitgegaan dat het aantal vermeldingen in de index enkele miljoenen of tientallen miljoenen per server zal bedragen. Als de tabel honderd miljoen rijen heeft, kan de granulariteit worden ingesteld op 64.
U kunt de grootte van het gecomprimeerde blok verkleinen. Hier zijn instellingen voor min. comprimeerblokgrootte, maximale comprimeringsblokgrootte. Ze kunnen worden verminderd, opnieuw worden gevuld met gegevens, en gerichte zoekopdrachten zullen sneller zijn. Maar toch is ClickHouse geen sleutel-waardedatabase. Een groot aantal kleine verzoeken is een belasting-antipatroon.
Kirill Sjvakov: Ik zal advies geven voor het geval er gewone rekeningen zijn. Dit is een vrij standaardsituatie wanneer ClickHouse een soort teller opslaat. Ik heb een gebruiker, hij komt uit dat en dat land, en een derde veld, en ik moet iets stapsgewijs verhogen. Neem MySQL, maak een unieke sleutel - in MySQL is het een dubbele sleutel, en in PostgreSQL is het een conflict - en voeg een plusteken toe. Dit zal veel beter werken.
Als u niet veel gegevens heeft, heeft het weinig zin om ClickHouse te gebruiken. Er zijn reguliere databases en die doen dit goed.
Wat kan ik in ClickHouse aanpassen zodat er meer gegevens in de cache staan?
Laten we ons een situatie voorstellen: de servers hebben 256 GB RAM, in de dagelijkse routine neemt ClickHouse ongeveer 60-80 GB in beslag, op piekniveau - tot 130. Wat kan worden ingeschakeld en aangepast zodat er meer gegevens in de cache staan en dienovereenkomstig er minder uitstapjes naar de schijf zijn?
Meestal doet de paginacache van het besturingssysteem dit goed. Als je gewoon de bovenkant opent en daar in de cache of gratis kijkt - er staat ook hoeveel er in de cache is opgeslagen - dan zul je merken dat al het vrije geheugen wordt gebruikt voor de cache. En bij het lezen van deze gegevens worden deze niet van de schijf gelezen, maar van het RAM-geheugen. Tegelijkertijd kan ik zeggen dat de cache effectief wordt gebruikt, omdat het de gecomprimeerde gegevens zijn die in de cache worden opgeslagen.
Als u enkele eenvoudige zoekopdrachten echter nog sneller wilt doen, is het mogelijk om een cache in de gedecomprimeerde gegevens in ClickHouse in te schakelen. Het heet ongecomprimeerde cache. Stel in het configuratiebestand config.xml de ongecomprimeerde cachegrootte in op de waarde die u nodig heeft - ik raad niet meer dan de helft van het vrije RAM aan, omdat de rest onder de paginacache gaat.
Daarnaast zijn er twee verzoekniveau-instellingen. Eerste instelling - gebruik ongecomprimeerde cache - omvat het gebruik ervan. Het wordt aanbevolen om dit voor alle verzoeken in te schakelen, behalve voor zware verzoeken, die alle gegevens kunnen lezen en de cache kunnen leegmaken. En de tweede instelling is zoiets als het maximale aantal regels dat de cache mag gebruiken. Het beperkt automatisch grote zoekopdrachten zodat ze de cache omzeilen.
Hoe kan ik storage_configuration configureren voor opslag in RAM?
In de nieuwe ClickHouse-documentatie las ik het betreffende gedeelte . In de beschrijving staat een voorbeeld met snelle SSD.
Ik vraag me af hoe hetzelfde kan worden geconfigureerd met volume hot memory. En nog een vraag. Hoe werkt Select met deze gegevensorganisatie? Zal het de hele set lezen of alleen degene die op schijf staat, en worden deze gegevens gecomprimeerd in het geheugen? En hoe werkt de prewhere-sectie met zo’n data-organisatie?
Deze instelling heeft invloed op de opslag van gegevensblokken en hun formaat verandert op geen enkele manier.
Laten we dat eens van dichterbij bekijken.
U kunt de gegevensopslag in RAM configureren. Het enige dat voor de schijf is geconfigureerd, is het pad. U maakt een tmpfs-partitie die aan een pad in het bestandssysteem is gekoppeld. Je specificeert dit pad als het pad voor het opslaan van gegevens voor de heetste partitie, er beginnen stukjes gegevens aan te komen en daar te worden geschreven, alles is in orde.
Maar ik raad dit niet aan vanwege de lage betrouwbaarheid, maar als je ten minste drie replica’s in verschillende datacenters hebt, is het wel mogelijk. Als er iets gebeurt, worden de gegevens hersteld. Laten we ons voorstellen dat de server plotseling werd uitgeschakeld en weer ingeschakeld. De partitie werd opnieuw gemonteerd, maar er was niets. Wanneer de ClickHouse-server start, ziet hij dat deze deze stukken niet heeft, hoewel ze er volgens de metadata van ZooKeeper wel zouden moeten zijn. Hij kijkt welke replica’s ze hebben, vraagt ze op en downloadt ze. Op deze manier worden de gegevens hersteld.
In die zin verschilt het opslaan van gegevens in RAM niet fundamenteel van het opslaan op schijf, omdat wanneer gegevens naar schijf worden geschreven, deze ook eerst in de paginacache terechtkomen en later fysiek worden geschreven. Dit is afhankelijk van de optie voor het koppelen van het bestandssysteem. Maar voor het geval dat, zal ik zeggen dat ClickHouse niet fsync tijdens het invoegen.
In dit geval worden de gegevens in het RAM opgeslagen in exact hetzelfde formaat als op de schijf. De selectiequery selecteert op dezelfde manier de stukken die moeten worden gelezen, selecteert de benodigde gegevensbereiken in de stukken en leest ze. En prewhere werkt precies hetzelfde, ongeacht of de gegevens zich in het RAM-geheugen of op schijf bevonden.
Tot hoeveel unieke waarden is Lage Kardinaliteit effectief?
Lage kardinaliteit is slim ontworpen. Het stelt gegevenswoordenboeken samen, maar deze zijn lokaal. Ten eerste zijn er voor elk stuk verschillende woordenboeken, en ten tweede kunnen ze zelfs binnen één stuk voor elk bereik verschillend zijn. Wanneer het aantal unieke waarden een drempelwaarde bereikt – een miljoen, denk ik – wordt het woordenboek eenvoudigweg op de plank gelegd en wordt er een nieuw woordenboek gemaakt.
Het antwoord is in het algemeen: voor elk lokaal bereik – zeg maar voor elke dag – zijn ergens tot een miljoen unieke waarden Lage Kardinaliteit effectief. Daarna komt er simpelweg een fallback, waarbij veel verschillende woordenboeken worden gebruikt, en niet slechts één. Het zal ongeveer hetzelfde werken als een gewone stringkolom, misschien iets minder efficiënt, maar er zal geen ernstige prestatievermindering optreden.
Wat zijn de beste werkwijzen voor het doorzoeken van de volledige tekst in een tabel met vijf miljard rijen?
Er zijn verschillende antwoorden. De eerste is om te zeggen dat ClickHouse geen volledige tekstzoekmachine is. Hiervoor bestaan speciale systemen, bijv. и . Ik zie echter steeds vaker mensen zeggen dat ze overstappen van Elasticsearch naar ClickHouse.
Waarom gebeurt dit? Ze verklaren dit door het feit dat Elasticsearch bij sommige volumes de belasting niet meer aankan, te beginnen met de constructie van indexen. Indexen worden te omslachtig en als je de gegevens simpelweg naar ClickHouse overzet, blijken ze qua volume meerdere malen efficiënter te worden opgeslagen. Tegelijkertijd waren de zoekopdrachten vaak niet van dien aard dat het nodig was om een of andere zin in het hele gegevensvolume te vinden, rekening houdend met de morfologie, maar totaal verschillende. Zoek bijvoorbeeld een deelreeks bytes in de logboeken van de afgelopen uren.
In dit geval maakt u een index aan in ClickHouse, waarvan het eerste veld de datum en tijd is. En de grootste datalimiet zal gebaseerd zijn op het datumbereik. Binnen het geselecteerde datumbereik is het in de regel al mogelijk om in de volledige tekst te zoeken, zelfs met behulp van de brute force-methode met like. De like-operator in ClickHouse is de meest efficiënte like-operator die je kunt vinden. Als je iets beters vindt, vertel het me dan.
Maar toch, zoals een volledige scan. En een volledige scan kan niet alleen traag zijn op de CPU, maar ook op de schijf. Als je opeens één terabyte aan data per dag hebt, en je zoekt overdag naar een woord, dan zul je de terabyte moeten scannen. En waarschijnlijk staat het op gewone harde schijven, en uiteindelijk worden ze zo geladen dat je via SSH geen toegang meer hebt tot deze server.
In dit geval ben ik bereid nog een klein trucje aan te bieden. Het is experimenteel: het zou kunnen werken, misschien niet. ClickHouse beschikt over full-text indexen in de vorm van trigram Bloom-filters. Onze collega’s bij Arenadata hebben deze indexen al uitgeprobeerd en vaak werken ze precies zoals bedoeld.
Om ze correct te kunnen gebruiken, moet je goed begrijpen hoe ze precies werken: wat een Trigram Bloom-filter is en hoe je de grootte ervan kiest. Ik kan zeggen dat ze zullen helpen bij vragen over enkele zeldzame zinsdelen, substrings die zelden in de gegevens voorkomen. In dit geval worden subbereiken geselecteerd door indexen en worden er minder gegevens gelezen.
Onlangs heeft ClickHouse nog meer geavanceerde functies toegevoegd voor zoeken in volledige tekst. Dit is in de eerste plaats een zoektocht naar een aantal substrings tegelijk in één keer, inclusief opties die hoofdlettergevoelig of hoofdletterongevoelig zijn, met ondersteuning voor UTF-8 of alleen voor ASCII. Kies de meest effectieve die je nodig hebt.
Er is ook gezocht naar meerdere reguliere expressies in één keer. U hoeft X niet als een subtekenreeks te schrijven, of X als een andere subtekenreeks. Je schrijft meteen en alles gebeurt zo efficiënt mogelijk.
Ten derde is er nu een geschatte zoekopdracht naar regexps en een geschatte zoekopdracht naar substrings. Als iemand een woord verkeerd heeft gespeld, wordt er gezocht naar de maximale overeenkomst.
Wat is de beste manier om de toegang tot ClickHouse voor een groot aantal gebruikers te organiseren?
Vertel ons hoe we de toegang voor een groot aantal consumenten en analisten het beste kunnen organiseren. Hoe vorm je een wachtrij, geef je prioriteit aan het maximale aantal gelijktijdige zoekopdrachten en met welke tools?
Als het cluster groot genoeg is, zou het een goede oplossing zijn om nog twee servers op te zetten, die een toegangspunt voor analisten zullen worden. Dat wil zeggen: geef analisten geen toegang tot specifieke shards in het cluster, maar creëer eenvoudigweg twee lege servers, zonder gegevens, en configureer de toegangsrechten daarop. In dit geval worden gebruikersinstellingen voor gedistribueerde verzoeken overgedragen naar externe servers. Dat wil zeggen: u configureert alles op deze twee servers en de instellingen hebben effect op het hele cluster.
Deze servers hebben in principe geen data, maar de hoeveelheid RAM die erop staat is van groot belang voor het uitvoeren van verzoeken. De schijf kan ook worden gebruikt voor tijdelijke gegevens als externe aggregatie of externe sortering is ingeschakeld.
Het is belangrijk om te kijken naar de instellingen die bij alle mogelijke limieten horen. Als ik nu als analist naar het Yandex.Metrica-cluster ga en een verzoek vraag selecteer het aantal hits, dan krijg ik direct de uitzondering dat ik het verzoek niet kan uitvoeren. Het maximale aantal rijen dat ik mag scannen is honderd miljard, en in totaal staan er vijftig biljoen in één tabel op het cluster. Dit is de eerste beperking.
Stel dat ik de rijlimiet verwijder en de query opnieuw uitvoer. Dan zie ik de volgende uitzondering: instelling ingeschakeld forceer index op datum. Ik kan de zoekopdracht niet voltooien als ik geen datumbereik heb opgegeven. U hoeft er niet op te vertrouwen dat analisten dit handmatig opgeven. Een typisch geval is wanneer een datumbereik wordt geschreven waarbij de datum van de gebeurtenis tussen de week ligt. En toen specificeerden ze eenvoudigweg een haakje op de verkeerde plaats, en in plaats van en bleek het een of - of URL-match te zijn. Als er geen limiet is, zal het de URL-kolom crawlen en een hoop bronnen verspillen.
Bovendien heeft ClickHouse twee prioriteitsinstellingen. Helaas zijn ze erg primitief. Er wordt er gewoon één gebeld prioriteit. Als prioriteit ≠ 0 en verzoeken met enige prioriteit worden uitgevoerd, maar een verzoek met een prioriteitswaarde van minder dan, wat een hogere prioriteit betekent, wordt uitgevoerd, dan wordt een verzoek met een prioriteitswaarde groter uitgevoerd, wat een lagere prioriteit betekent , is eenvoudigweg opgeschort en zal gedurende deze periode helemaal niet werken.
Dit is een zeer ruwe instelling en is niet geschikt voor gevallen waarin het cluster een constante belasting heeft. Maar als u korte, snelle verzoeken hebt die belangrijk zijn, en het cluster grotendeels inactief is, is deze opstelling geschikt.
De volgende prioriteitsinstelling wordt opgeroepen Threadprioriteit van het besturingssysteem. Het stelt eenvoudigweg de mooie waarde in voor alle threads voor het uitvoeren van verzoeken voor de Linux-planner. Het werkt zo-zo, maar het werkt nog steeds. Als je de minimale nice-waarde instelt - deze is de grootste in waarde en daarom de laagste prioriteit - en -19 instelt voor verzoeken met hoge prioriteit, dan zal de CPU verzoeken met een lage prioriteit ongeveer vier keer minder verbruiken dan verzoeken met een hoge prioriteit.
U moet ook de maximale uitvoeringstijd van het verzoek configureren, bijvoorbeeld vijf minuten. De minimale snelheid voor het uitvoeren van zoekopdrachten is het coolste. Deze instelling bestaat al heel lang en het is niet alleen nodig om te beweren dat ClickHouse niet vertraagt, maar ook om het te forceren.
Stel je voor, je configureert: als een query minder dan een miljoen rijen per seconde verwerkt, kun je dat niet doen. Dit schaadt onze goede naam, onze goede database. Laten we dit gewoon verbieden. Er zijn eigenlijk twee instellingen. Er wordt er één gebeld minimale uitvoeringssnelheid - in regels per seconde, en de seconde wordt time-out genoemd voordat de minimale uitvoeringssnelheid wordt gecontroleerd - standaard vijftien seconden. Dat wil zeggen, vijftien seconden is mogelijk, en als het langzaam is, gooi dan gewoon een uitzondering en annuleer het verzoek.
U moet ook quota instellen. ClickHouse heeft een ingebouwde quotafunctie die het resourceverbruik telt. Maar helaas geen hardwarebronnen zoals CPU, schijven, maar logische bronnen - het aantal verwerkte verzoeken, gelezen regels en bytes. En u kunt bijvoorbeeld maximaal honderd aanvragen binnen vijf minuten en duizend aanvragen per uur configureren.
Waarom is het belangrijk? Omdat sommige analysequery's handmatig rechtstreeks vanuit de ClickHouse-client worden uitgevoerd. En alles zal goed komen. Maar als u geavanceerde analisten in uw bedrijf heeft, zullen zij een script schrijven, en er kan een fout in het script zitten. En deze fout zorgt ervoor dat het verzoek in een oneindige lus wordt uitgevoerd. Dit is waar we onszelf tegen moeten beschermen.
Is het mogelijk om de resultaten van één zoekopdracht aan tien klanten te geven?
We hebben verschillende gebruikers die graag op hetzelfde tijdstip met zeer grote verzoeken binnenkomen. Het verzoek is groot en wordt in principe snel uitgevoerd, maar doordat er veel van dergelijke verzoeken tegelijkertijd zijn, wordt het erg pijnlijk. Is het mogelijk om hetzelfde verzoek, dat tien keer achter elkaar is binnengekomen, één keer uit te voeren en het resultaat aan tien klanten te geven?
Het probleem is dat we niet de resultaten hebben van de cache of cache van tussenliggende gegevens. Er is een paginacache van het besturingssysteem, waardoor u de gegevens niet opnieuw van de schijf kunt lezen, maar helaas worden de gegevens nog steeds gedecomprimeerd, gedeserialiseerd en opnieuw verwerkt.
Ik zou dit op de een of andere manier willen vermijden, hetzij door tussentijdse gegevens in het cachegeheugen op te slaan, of door vergelijkbare zoekopdrachten in een soort wachtrij te plaatsen en een resultatencache toe te voegen. We hebben momenteel één pull-request in ontwikkeling die een request-cache toevoegt, maar alleen voor subquery's in de in- en join-secties - dat wil zeggen dat de oplossing onvolledig is.
Wij worden echter ook met een dergelijke situatie geconfronteerd. Een bijzonder canoniek voorbeeld zijn gepagineerde zoekopdrachten. Er is een rapport, het bestaat uit meerdere pagina's, en er is een verzoek voor limiet 10. Dan hetzelfde, maar dan limiet 10,10. Dan nog een volgende pagina. En de vraag is: waarom tellen we dit allemaal elke keer mee? Maar nu is er geen oplossing, en er is geen manier om deze te vermijden.
Er is een alternatieve oplossing die als zijspan naast ClickHouse wordt geplaatst - .
Kirill Sjvakov: ClickHouse Proxy heeft een ingebouwde snelheidsbegrenzer en een ingebouwde resultatencache. Daar zijn veel instellingen gedaan omdat een soortgelijk probleem werd opgelost. Met Proxy kunt u verzoeken beperken door ze in de wachtrij te plaatsen en configureren hoe lang de verzoekcache blijft bestaan. Als de verzoeken werkelijk hetzelfde zijn, zal Proxy ze vele malen versturen, maar slechts één keer naar ClickHouse gaan.
Nginx heeft ook een cache in de gratis versie, en dit zal ook werken. Nginx heeft zelfs instellingen die ervoor zorgen dat als aanvragen tegelijkertijd binnenkomen, andere worden vertraagd totdat er één is voltooid. Maar het is in ClickHouse Proxy dat de installatie veel beter wordt gedaan. Het is speciaal voor ClickHouse gemaakt, specifiek voor deze verzoeken, dus geschikter. Nou, het is eenvoudig te installeren.
Hoe zit het met asynchrone bewerkingen en gematerialiseerde weergaven?
Er is een probleem dat bewerkingen met de replay-engine asynchroon zijn: eerst worden de gegevens geschreven en daarna storten ze in. Als een gematerialiseerde tablet met enkele aggregaten onder het bord leeft, zullen er duplicaten naar worden geschreven. En als er geen complexe logica is, worden de gegevens gedupliceerd. Wat kun je eraan doen?
Er is een voor de hand liggende oplossing: het implementeren van een trigger op een bepaalde klasse matviews tijdens een asynchrone samenvouwoperatie. Zijn er wondermiddelen of plannen om vergelijkbare functionaliteit te implementeren?
Het is de moeite waard om te begrijpen hoe deduplicatie werkt. Wat ik je nu ga vertellen is niet relevant voor de vraag, maar voor het geval het de moeite waard is om te onthouden.
Bij het invoegen in een gerepliceerde tabel vindt deduplicatie plaats van de gehele ingevoegde blokken. Als u hetzelfde blok met hetzelfde aantal rijen in dezelfde volgorde opnieuw invoegt, worden de gegevens ontdubbeld. U ontvangt "Ok" als antwoord op het invoegen, maar in feite wordt er één gegevenspakket geschreven en wordt het niet gedupliceerd.
Dit is nodig voor de zekerheid. Als u bij het invoeren de melding “Ok” krijgt, zijn uw gegevens ingevoerd. Als u een foutmelding krijgt van ClickHouse, betekent dit dat ze niet zijn ingevoegd en dat u het invoegen moet herhalen. Maar als de verbinding tijdens het invoegen wordt verbroken, weet u niet of de gegevens zijn ingevoegd of niet. De enige optie is om het invoegen opnieuw te herhalen. Als de gegevens daadwerkelijk zijn ingevoegd en u deze opnieuw hebt ingevoegd, is er sprake van blokontdubbeling. Dit is nodig om duplicaten te voorkomen.
En het is ook belangrijk hoe het werkt voor gematerialiseerde weergaven. Als de gegevens zijn gededupliceerd toen ze in de hoofdtabel werden ingevoegd, worden deze ook niet in de gerealiseerde weergave weergegeven.
Nu over de vraag. Uw situatie is ingewikkelder omdat u duplicaten van afzonderlijke regels opneemt. Dat wil zeggen, het is niet het hele pakket dat wordt gedupliceerd, maar specifieke regels, en deze vallen op de achtergrond samen. De gegevens vallen inderdaad samen in de hoofdtabel, maar de niet-samengevouwen gegevens gaan naar de gematerialiseerde weergave, en tijdens het samenvoegen gebeurt er niets met de gematerialiseerde weergaven. Omdat een gematerialiseerde weergave niets meer is dan een invoegtrigger. Tijdens andere handelingen gebeurt er verder niets mee.
En ik kan je hier niet gelukkig maken. U hoeft alleen maar op zoek te gaan naar een specifieke oplossing voor dit geval. Is het bijvoorbeeld mogelijk om het opnieuw af te spelen in een gematerialiseerde weergave, en zou de deduplicatiemethode op dezelfde manier kunnen werken. Maar helaas niet altijd. Als het samenvoegt, zal het niet werken.
Kirill Sjvakov: Wij hadden vroeger ook een krukconstructie. Er was een probleem met de advertentievertoningen, en er zijn enkele gegevens die we in realtime kunnen laten zien. Dit zijn slechts vertoningen. Ze worden zelden gedupliceerd, maar als dit gebeurt, zullen we ze later toch samenvouwen. En er waren dingen die niet konden worden gedupliceerd: klikken en dit hele verhaal. Maar ik wilde ze ook vrijwel meteen laten zien.
Hoe kwamen de gematerialiseerde standpunten tot stand? Er waren views waarin het rechtstreeks werd geschreven: het werd naar onbewerkte gegevens geschreven en naar views geschreven. Daar zijn de gegevens op een gegeven moment niet erg correct, worden ze gedupliceerd, enzovoort. En er is een tweede deel van de tabel, waar ze er precies hetzelfde uitzien als gematerialiseerde weergaven, dat wil zeggen dat ze absoluut identiek zijn qua structuur. Af en toe herberekenen we de gegevens, tellen we de gegevens zonder duplicaten, schrijven we naar die tabellen.
We hebben de API doorlopen - dit werkt niet handmatig in ClickHouse. En de API kijkt: als ik de datum heb van de laatste toevoeging aan de tabel, waarbij gegarandeerd is dat de juiste gegevens al zijn berekend, en doet hij een verzoek aan de ene tabel en aan een andere tabel. Van de een selecteert het verzoek tot een bepaalde hoeveelheid tijd, en van de ander krijgt het wat nog niet is berekend. En het werkt, maar niet alleen via ClickHouse.
Als je een soort API hebt – voor analisten, voor gebruikers – dan is dit in principe een optie. Je bent altijd aan het tellen, altijd aan het tellen. Dit kan één keer per dag of op een ander tijdstip. Je kiest zelf een assortiment dat je niet nodig hebt en niet kritisch is.
ClickHouse heeft veel logboeken. Hoe kan ik in één oogopslag zien wat er met de server gebeurt?
ClickHouse beschikt over een zeer groot aantal verschillende logs, en dit aantal neemt toe. In nieuwe versies zijn sommige zelfs standaard ingeschakeld; in oudere versies moeten ze ingeschakeld zijn bij het updaten. Er zijn er echter steeds meer. Uiteindelijk zou ik graag willen zien wat er nu met mijn server gebeurt, misschien op een soort samenvattend dashboard.
Heeft u een ClickHouse-team, of de teams van uw vrienden, die een bepaalde functionaliteit van kant-en-klare dashboards ondersteunen die deze logboeken als eindproduct weergeven? Uiteindelijk is alleen al het bekijken van logbestanden in ClickHouse geweldig. Maar het zou heel gaaf zijn als het al in de vorm van een dashboard zou worden opgesteld. Ik zou er een kick van krijgen.
Er zijn dashboards, hoewel deze niet gestandaardiseerd zijn. In ons bedrijf gebruiken ongeveer 60 teams ClickHouse, en het vreemdste is dat velen van hen dashboards hebben die ze voor zichzelf hebben gemaakt, en enigszins andere. Sommige teams gebruiken een interne Yandex.Cloud-installatie. Er zijn enkele kant-en-klare rapporten, maar niet alle noodzakelijke. Anderen hebben hun eigen.
Mijn collega's van Metrica hebben hun eigen dashboard in Grafana, en ik heb mijn eigen dashboard voor hun cluster. Ik kijk naar zaken als cachehit voor de serif-cache. En nog lastiger is dat we verschillende tools gebruiken. Ik heb mijn dashboard gemaakt met een heel oud hulpmiddel genaamd Graphite-web. Hij is helemaal lelijk. En ik gebruik het nog steeds op deze manier, hoewel Grafana waarschijnlijk handiger en mooier zou zijn.
De basis van dashboards is hetzelfde. Dit zijn systeemstatistieken voor het cluster: CPU, geheugen, schijf, netwerk. Overige - aantal gelijktijdige verzoeken, aantal gelijktijdige samenvoegingen, aantal verzoeken per seconde, maximaal aantal chunks voor MergeTree-tabelpartities, replicatievertraging, grootte van de replicatiewachtrij, aantal ingevoegde rijen per seconde, aantal ingevoegde blokken per seconde. Dit is alles dat niet uit logboeken wordt verkregen, maar uit statistieken.
Vladimir Kolobaev: Alexey, ik wil het graag een beetje corrigeren. Er is Grafana. Grafana heeft een gegevensbron, ClickHouse. Dat wil zeggen dat ik vanuit Grafana rechtstreeks verzoeken aan ClickHouse kan doen. ClickHouse heeft een tabel met logboeken, deze is voor iedereen hetzelfde. Als gevolg hiervan wil ik toegang krijgen tot deze logtabel in Grafana en de verzoeken zien die mijn server doet. Het zou geweldig zijn om zo’n dashboard te hebben.
Ik heb er zelf op gefietst. Maar ik heb een vraag: als het allemaal gestandaardiseerd is en Grafana door iedereen wordt gebruikt, waarom heeft Yandex dan niet zo'n officieel dashboard?
Kirill Sjvakov: In feite ondersteunt de gegevensbron die naar ClickHouse gaat nu Altinity. En ik wil gewoon een vector geven van waar te graven en wie te duwen. Je kunt het ze vragen, want Yandex maakt nog steeds ClickHouse, en niet het verhaal eromheen. Altinity is het belangrijkste bedrijf dat momenteel ClickHouse promoot. Ze zullen hem niet in de steek laten, maar hem steunen. Omdat u voor het uploaden van een dashboard naar de Grafana-website in principe alleen maar hoeft te registreren en uploaden - er zijn geen speciale problemen.
Alexey Milovidov: Het afgelopen jaar heeft ClickHouse veel mogelijkheden voor het profileren van zoekopdrachten toegevoegd. Er zijn statistieken voor elk verzoek over het resourcegebruik. En onlangs hebben we een queryprofiler op een nog lager niveau toegevoegd om te zien waar een query elke milliseconde aan besteedt. Maar om deze functionaliteit te gebruiken, moet ik de consoleclient openen en een verzoek typen, wat ik altijd vergeet. Ik heb het ergens opgeslagen en vergeet steeds waar precies.
Ik wou dat er een tool was die zojuist zei: hier zijn je zware zoekopdrachten, gegroepeerd op zoekopdrachtklasse. Ik drukte er op en ze vertelden me dat het daarom zwaar was. Een dergelijke oplossing bestaat nu niet. En het is echt heel vreemd dat als mensen mij vragen: “Zeg eens, zijn er kant-en-klare dashboards voor Grafana?”, ik zeg: “Ga naar de Grafana-website, daar is een ‘Dashboards’-community en er is een dashboard van Dimka, er is een dashboard van Kostyan. Ik weet niet wat het is, ik heb het zelf niet gebruikt.”
Hoe kun je merges beïnvloeden, zodat de server niet in OOM crasht?
Ik heb een tabel, er is maar één partitie in de tabel, het is ReplacingMergeTree. Ik schrijf er al vier jaar gegevens in. Ik moest er een wijziging in aanbrengen en enkele gegevens verwijderen.
Ik deed dit en tijdens de verwerking van dit verzoek werd al het geheugen op alle servers in het cluster verbruikt en gingen alle servers in het cluster naar OOM. Toen stonden ze allemaal samen op, begonnen dezelfde operatie, dit datablok, samen te voegen en vielen weer in OOM. Toen stonden ze weer op en vielen weer. En deze zaak hield niet op.
Toen bleek dat dit eigenlijk een bug was die de jongens hadden opgelost. Dit is heel cool, heel erg bedankt. Maar er bleef een residu achter. En nu, als ik erover nadenk om een of andere samenvoeging in de tabel te maken, heb ik een vraag: waarom kan ik deze samenvoegingen op de een of andere manier niet beïnvloeden? Beperk ze bijvoorbeeld op de hoeveelheid RAM die nodig is, of, in principe, op de hoeveelheid die deze specifieke tabel zal verwerken.
Ik heb een tabel met de naam 'Metrische gegevens'. Verwerk deze voor mij in twee threads. Het is niet nodig om tien of vijf samenvoegingen parallel te maken, doe het in twee. Ik denk dat ik genoeg geheugen heb voor twee, maar het is misschien niet genoeg om er tien te verwerken. Waarom blijft angst bestaan? Omdat de tabel groeit en ik op een dag te maken zal krijgen met een situatie die in principe niet langer te wijten is aan een bug, maar omdat de gegevens in zo'n grote hoeveelheid zullen veranderen dat ik simpelweg niet genoeg geheugen op de computer heb server. En dan crasht de server bij het samenvoegen in OOM. Bovendien kan ik de mutatie annuleren, maar Merji is er niet meer.
Weet je, bij het samenvoegen zal de server niet in OOM vallen, omdat bij het samenvoegen de hoeveelheid RAM slechts voor een klein gegevensbereik wordt gebruikt. Alles komt dus goed, ongeacht de hoeveelheid gegevens.
Vladimir Kolobaev: Prima. Hier is het moment zo dat ik, nadat de bug was verholpen, een nieuwe versie voor mezelf heb gedownload, en op een andere tafel, een kleinere, waar veel partities zijn, een soortgelijke bewerking heb uitgevoerd. En tijdens de samenvoeging werd ongeveer 100 GB RAM op de server gebrand. Ik had er 150 bezet, 100 gegeten en nog een venster van 50 GB over, dus ik viel niet in OOM.
Wat beschermt mij momenteel tegen het vallen in OOM als het daadwerkelijk 100 GB RAM verbruikt? Wat te doen als het RAM-geheugen bij de samenvoegingen plotseling opraakt?
Alexey Milovidov: Er is zo'n probleem dat het RAM-verbruik specifiek voor het samenvoegen niet beperkt is. En het tweede probleem is dat als er een soort samenvoeging is toegewezen, deze moet worden uitgevoerd omdat deze wordt vastgelegd in het replicatielogboek. Het replicatielogboek bevat de acties die nodig zijn om de replica in een consistente staat te brengen. Als u geen handmatige manipulaties uitvoert die dit replicatielogboek terugdraaien, zal de samenvoeging op de een of andere manier moeten worden uitgevoerd.
Het zou natuurlijk niet overbodig zijn om een RAM-beperking te hebben die “voor het geval dat” beschermt tegen OOM. Het zal de samenvoeging niet helpen voltooien, het zal opnieuw beginnen, een bepaalde drempel bereiken, een uitzondering genereren en dan opnieuw beginnen - hier zal niets goeds uit voortkomen. Maar in principe zou het nuttig zijn om deze beperking in te voeren.
Hoe wordt de Golang-driver voor ClickHouse ontwikkeld?
De Golang-driver, geschreven door Kirill Shvakov, wordt nu officieel ondersteund door het ClickHouse-team. Hij , hij is nu groot en echt.
Een kleine opmerking. Er is een prachtige en geliefde opslagplaats van normale vormen van oneindige orde: dit is Vertica. Ze hebben ook hun eigen officiële Python-stuurprogramma, dat wordt ondersteund door de Vertica-ontwikkelaars. En verschillende keren gebeurde het dat de opslagversies en de driverversies behoorlijk dramatisch uiteenliepen, en dat de driver op een gegeven moment stopte met werken. En het tweede punt. Ondersteuning voor deze officiële driver wordt, zo lijkt mij, uitgevoerd door het "tepel" -systeem - je schrijft ze een probleem en het blijft voor altijd hangen.
Ik heb twee vragen. Nu is het Golang-stuurprogramma van Kirill bijna de standaardmanier om vanuit Golang met ClickHouse te communiceren. Tenzij iemand nog via de http-interface communiceert omdat hij dat prettig vindt. Hoe zal de ontwikkeling van deze driver verlopen? Zal het worden gesynchroniseerd met eventuele belangrijke wijzigingen in de repository zelf? En wat is de procedure voor het overwegen van een probleem?
Kirill Sjvakov: De eerste is hoe alles bureaucratisch is georganiseerd. Dit punt is niet besproken, dus ik heb niets te antwoorden.
Om de vraag over het probleem te beantwoorden, hebben we een beetje geschiedenis van de bestuurder nodig. Ik werkte voor een bedrijf dat veel data had. Het was een reclamespinner met een enorm aantal evenementen die ergens opgeslagen moesten worden. En op een gegeven moment verscheen ClickHouse. We hebben het gevuld met gegevens en in eerste instantie was alles in orde, maar toen crashte ClickHouse. Op dat moment besloten we dat we het niet nodig hadden.
Een jaar later kwamen we terug op het idee om ClickHouse te gebruiken, en we moesten daar op de een of andere manier gegevens schrijven. De inleidende boodschap was deze: de hardware is erg zwak, er zijn weinig bronnen. Maar we hebben altijd op deze manier gewerkt en daarom keken we naar het oorspronkelijke protocol.
Omdat we in Go werkten, was het duidelijk dat we een Go-chauffeur nodig hadden. Ik deed het bijna fulltime - het was mijn werktaak. We hebben het tot een bepaald punt gebracht, en in principe ging niemand ervan uit dat iemand anders dan wij er gebruik van zou maken. Toen kwam CloudFlare met precies hetzelfde probleem, en een tijdje hebben we heel soepel met ze samengewerkt, omdat ze dezelfde taken hadden. Bovendien deden we dit zowel in ClickHouse zelf als in de driver.
Op een gegeven moment ben ik er gewoon mee gestopt, omdat mijn activiteiten op het gebied van ClickHouse en werk een beetje veranderden. Daarom zijn de kwesties niet gesloten. Periodiek verbinden mensen die zelf iets nodig hebben zich aan de repository. Vervolgens kijk ik naar de pull request en soms bewerk ik zelfs zelf iets, maar dit gebeurt zelden.
Ik wil terug naar de chauffeur. Enkele jaren geleden, toen dit allemaal begon, was ClickHouse ook anders en met andere mogelijkheden. Nu begrijpen we hoe we de driver opnieuw kunnen maken, zodat deze goed werkt. Mocht dit gebeuren, dan is versie 2 sowieso incompatibel vanwege de opeenhoping van krukken.
Ik weet niet hoe ik deze zaak moet organiseren. Zelf heb ik niet veel tijd. Als sommige mensen de chauffeur afmaken, kan ik ze helpen en vertellen wat ze moeten doen. Maar de actieve deelname van Yandex aan de ontwikkeling van het project is nog niet besproken.
Alexey Milovidov: In feite bestaat er nog geen bureaucratie rond deze chauffeurs. Het enige is dat ze worden ingediend bij een officiële organisatie, dat wil zeggen dat dit stuurprogramma wordt erkend als de officiële standaardoplossing voor Go. Er zijn nog enkele andere stuurprogramma's, maar deze worden afzonderlijk geleverd.
We hebben geen interne ontwikkeling voor deze drijfveren. De vraag is of we een individuele persoon kunnen inhuren, niet voor deze specifieke chauffeur, maar voor de ontwikkeling van alle gemeenschapschauffeurs, of kunnen we iemand van buitenaf vinden.
Het externe woordenboek wordt niet geladen na een herstart waarbij de lazy_load-instelling is ingeschakeld. Wat moeten we doen?
We hebben de lazy_load-instelling ingeschakeld en nadat de server opnieuw is opgestart, wordt het woordenboek niet vanzelf geladen. Het wordt pas weergegeven nadat de gebruiker dit woordenboek heeft geopend. En de eerste keer dat ik er toegang toe krijg, geeft het een foutmelding. Is het mogelijk om woordenboeken op de een of andere manier automatisch te laden met ClickHouse, of moet je altijd zelf de gereedheid ervan controleren, zodat gebruikers geen fouten krijgen?
Misschien hebben we een oude versie van ClickHouse, waardoor het woordenboek niet automatisch werd geladen. Zou dit het geval kunnen zijn?
Ten eerste kunnen woordenboeken geforceerd worden geladen met behulp van een query systeem herlaadt woordenboeken. Ten tweede, wat betreft de fout: als het woordenboek al is geladen, werken de zoekopdrachten op basis van de gegevens die zijn geladen. Als het woordenboek nog niet is geladen, wordt dit direct tijdens het verzoek geladen.
Dit is niet erg handig voor zware woordenboeken. U moet bijvoorbeeld een miljoen rijen uit MySQL halen. Iemand maakt een eenvoudige selectie, maar deze selectie wacht op hetzelfde miljoen rijen. Er zijn hier twee oplossingen. De eerste is om lazy_load uit te schakelen. Ten tweede, als de server actief is, doe dit dan voordat u de belasting erop legt systeem herladen woordenboek of voer gewoon een zoekopdracht uit waarbij een woordenboek wordt gebruikt. Vervolgens wordt het woordenboek geladen. U moet de beschikbaarheid van woordenboeken controleren terwijl de lazy_load-instelling is ingeschakeld, omdat ClickHouse ze niet automatisch laadt.
Het antwoord op de laatste vraag is dat de versie oud is of dat er fouten in moeten worden opgespoord.
Wat te doen met het feit dat het systeem bij het opnieuw laden van woordenboeken geen van de vele woordenboeken laadt als ten minste één ervan crasht met een fout?
Er is nog een vraag over het opnieuw laden van woordenboeken. We hebben twee woordenboeken: één is niet geladen, de tweede is geladen. In dit geval laadt het systeemherlaadwoordenboek geen enkel woordenboek, en moet u een specifiek woordenboek punt voor punt laden op basis van de naam met behulp van het systeemherlaadwoordenboek. Heeft dit ook te maken met de ClickHouse-versie?
Ik wil je gelukkig maken. Dit gedrag was aan het veranderen. Dit betekent dat als u ClickHouse bijwerkt, dit ook verandert. Als u niet tevreden bent met uw huidige gedrag systeem herlaadt woordenboeken, update en laten we hopen dat dit ten goede verandert.
Is er een manier om details in de ClickHouse-configuratie te configureren, maar deze niet weer te geven in geval van fouten?
De volgende vraag gaat over fouten met betrekking tot het woordenboek, namelijk details. We hebben de verbindingsgegevens gespecificeerd in de ClickHouse-configuratie voor het woordenboek en als er een fout optreedt, ontvangen we deze gegevens en het wachtwoord als reactie.
We hebben deze fout opgelost door details toe te voegen aan de ODBC-stuurprogrammaconfiguratie. Is er een manier om de details in de ClickHouse-configuratie te configureren, maar deze details niet weer te geven in geval van fouten?
De echte oplossing hier is om deze referenties op te geven in odbc.ini, en in ClickHouse zelf alleen de ODBC-gegevensbronnaam op te geven. Dit zal niet gebeuren voor andere woordenboekbronnen - noch voor het woordenboek met MySQL, noch voor de andere, je zou het wachtwoord niet moeten zien als je een foutmelding krijgt. Voor ODBC zal ik ook kijken: als het bestaat, hoef je het alleen maar te verwijderen.
Bonus: achtergronden voor Zoom van bijeenkomsten
Door op de afbeelding te klikken, worden bonusachtergronden van de bijeenkomsten geopend voor de meest vasthoudende lezers. We blussen samen met de technologiemascottes van Avito de brand, we overleggen met collega’s van de kamer van de systeembeheerder of de ouderwetse computerclub en we voeren dagelijks bijeenkomsten onder de brug tegen de achtergrond van graffiti.
Bron: www.habr.com