In april kwamen de ingenieurs van Avito samen voor online vergaderingen met de hoofduitvoerder van ClickHouse, Alexey Milovidov, en Kirill Shvakov, een Golang-ontwikkelaar van het bedrijf Integros. Ze bespraken hoe we het databasebeheersysteem gebruiken en welke problemen we tegenkomen.
Op basis van de bijeenkomst hebben we een artikel samengesteld met de antwoorden van experts op onze en de vragen van het publiek over back-ups, herverdeling van gegevens, externe woordenboeken, de Golang-driver en versie-updates van ClickHouse. Het kan nuttig zijn voor ontwikkelaars die al actief werken met de databases van 'Yandex' en geĆÆnteresseerd zijn in de huidige en toekomstige ontwikkelingen. Tenzij anders vermeld, zijn de antwoorden van Alexey Milovidov.
Let op, er is veel tekst onder de kat. We hopen dat de inhoud met vragen je helpt je te oriƫnteren.
Inhoud
Als je geen tekst wilt lezen, kun je de opname van de bijeenkomsten bekijken . Tijdstempels staan in de eerste reactie onder de video.
ClickHouse wordt voortdurend bijgewerkt, maar onze gegevens niet. Wat moeten we hiermee doen?
ClickHouse wordt voortdurend bijgewerkt, maar onze gegevens, die met optimize final zijn verwerkt, worden niet bijgewerkt en liggen in een reservekopie.
Stel dat we een probleem hebben en gegevens verloren zijn gegaan. We besloten om te herstellen, en het bleek dat de oude partities die zijn opgeslagen op de back-upservers heel sterk uiteenlopen met de versie van ClickHouse die we op dit moment gebruiken. Wat te doen in zo'n situatie, en is dat mogelijk?
Een situatie waarbij je gegevens uit een back-up herstelt in een oud formaat, terwijl ze in de nieuwe versie niet aansluiten, is onmogelijk. We zorgen ervoor dat het gegevensformaat in ClickHouse altijd achterwaarts compatibel blijft. Dit is veel belangrijker dan achterwaartse compatibiliteit op functionaliteit, als het gedrag van een zelden gebruikte functie is veranderd. Gegevens die op schijf zijn opgeslagen, moet de nieuwe versie van ClickHouse altijd kunnen lezen. Dat is een wet.
Wat zijn op dit moment de beste praktijken voor het maken van back-ups van gegevens uit ClickHouse?
Hoe maak je back-ups rekening houdend met het feit dat we optimize final-operaties hebben, een enorme database van terabytes hebben en gegevens die, laten we zeggen, voor de afgelopen drie dagen zijn bijgewerkt, terwijl er verder geen procedures voor plaatsvinden?
We kunnen een eigen oplossing samenstellen en op Bash schrijven: verzamel zo en zo deze back-ups. Misschien is er niets nodig en is de fiets al lang uitgevonden?
Laten we beginnen met de beste praktijken. Mijn collegaās adviseren altijd, in antwoord op vragen over back-ups, om de service āYandex.Cloudā te herinneren, waar deze taak al is opgelost. Gebruik het dus, als dat mogelijk is.
Er zijn geen volledige oplossingen, die honderd procent zijn ingebouwd in ClickHouse, voor back-ups. Er zijn enkele sjablonen die gebruikt kunnen worden. Om een volledige oplossing te krijgen, moet je ofwel een beetje handmatig aan de slag of scripts schrijven.
Ik begin met de eenvoudigste oplossingen en eindig met de meest geavanceerde, afhankelijk van de hoeveelheid gegevens en de grootte van het cluster. Hoe groter het cluster, hoe ingewikkelder de oplossing wordt.
Als de tabel met gegevens slechts enkele gigabytes groot is, kan de back-up als volgt worden gemaakt:
- Bewaar de definitie van de tabellen, dat wil zeggen metadata ā show create table.
- Maak een dump met behulp van de ClickHouse-client ā select * from table in een bestand. Standaard krijg je een bestand in het TabSeparated-formaat. Als je het efficiĆ«nter wilt, kan het in het Native-formaat.
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, die niet aan het gegevensformaat van ClickHouse is gekoppeld. Als deze beschikbaar is, kun je in het uiterste geval de back-up nemen en deze in MySQL laden voor herstel.
Voor meer geavanceerde gevallen biedt ClickHouse de mogelijkheid om een snapshot van partities in het lokale bestandssysteem te maken. Deze mogelijkheid is beschikbaar in de vorm van een query alter table freeze partition. Of gewoon alter table freeze ā dit is een snapshot van de hele tabel.
Het snapshot wordt consistent gemaakt voor Ć©Ć©n tabel op Ć©Ć©n shard, wat betekent dat een consistente snapshot van het gehele cluster op deze manier niet mogelijk is. Maar voor de meeste taken is deze behoefte er niet, en is het voldoende om de query op elke shard uit te voeren en een consistente snapshot te krijgen. Het wordt aangemaakt in de vorm van hardlinks en neemt daarom geen extra ruimte in beslag. Vervolgens kopieer je dit snapshot naar de back-upserver of naar de opslag die je gebruikt voor back-ups.
Het herstellen van zo'n back-up is vrij eenvoudig. Eerst maak je de tabellen aan volgens de bestaande definitie van de tabellen. Vervolgens kopieer je de opgeslagen snapshots van de partities naar Directory-Detached voor de gegevens van deze tabellen en voer je de query uit attach partition. Deze oplossing is heel geschikt voor de meest serieuze hoeveelheden gegevens.
Soms is er iets nog coolers nodig ā in de gevallen waarin je tientallen of zelfs honderden terabytes op elke server hebt en honderden servers. Hier is een oplossing die ik heb gezien bij collega's van 'Yandex.Metrica'. Ik zou het niet voor iedereen aanbevelen ā lees het zelf en beslis of het voor jou geschikt is.
Eerst moet je verschillende servers met grote schijfopslag maken. Vervolgens moet je op deze servers enkele ClickHouse-servers opzetten en ze zo configureren dat ze functioneren als een extra replica voor dezelfde shards. Daarna gebruik je op deze servers een bestandssysteem of een ander hulpmiddel dat het mogelijk maakt om snapshots te creƫren. Hier zijn twee opties. De eerste optie is LVM-snapshots, de tweede optie is ZFS op Linux.
Daarna moet je elke dag een snapshot maken, die zal worden opgeslagen en een zekere hoeveelheid ruimte in beslag neemt. Uiteraard zal de bezette ruimte toenemen naarmate de gegevens veranderen. Deze snapshot kan op elk moment worden opgehaald om de gegevens te herstellen, zo'n vreemde oplossing. Daarnaast moet je deze replicas in de configuratie beperken, zodat ze geen leiders willen worden.
Zal het mogelijk zijn om gecontroleerde achterstand van replicaties in de perioden te organiseren?
Dit jaar ben je van plan om walzen in ClickHouse te maken. Is het mogelijk om gecontroleerde achterstand van replicas daarin te organiseren? We zouden dit willen gebruiken om onszelf te beschermen tegen negatieve scenario's met alteraties en andere wijzigingen.
Is het mogelijk om rollbacks voor alters te maken? Bijvoorbeeld, in de bestaande wal een moment aan te wijzen waarop de wijzigingen moeten worden toegepast, en vanaf dat moment moeten de wijzigingen stoppen?
Als er een team in onze cluster komt en het kapot maakt, dan hebben we een soort replica met een achterstand van een uur, waar we kunnen zeggen: laten we deze op dit moment gebruiken, maar de laatste tien minuten van de wijzigingen daar niet toepassen?
Laten we beginnen met de gecontroleerde achterstand van replicas. Er was een verzoek van gebruikers en we hebben een issue op GitHub aangemaakt met het verzoek: 'Als iemand dit nodig heeft, like het, geef een hartje'. Niemand heeft geliket en de issue is gesloten. Desondanks kan je nu al deze mogelijkheid verkrijgen door ClickHouse te configureren. Het kan echter alleen vanaf versie 20.3.
ClickHouse voert voortdurend het samenvoegen van gegevens op de achtergrond uit - een merge. Wanneer de merge is uitgevoerd, wordt een bepaalde set datafragmenten vervangen door een groter fragment. De eerdere datafragmenten blijven echter enige tijd op de schijf staan.
Ten eerste blijven ze opgeslagen zolang er select-query's zijn die ze gebruiken, om een niet-blokkerende werking te garanderen. Select-query's kunnen rustig lezen vanuit de oude fragmenten.
Ten tweede is er ook een tijdslimiet - oude datafragmenten liggen acht minuten op de schijf. Deze acht minuten kunnen worden aangepast en zelfs tot Ć©Ć©n dag worden uitgebreid. Dit kost schijfruimte: afhankelijk van de datastroom kan het zo zijn dat de gegevens in Ć©Ć©n dag niet verdubbelen, maar zelfs tot vijf keer toenemen. Maar je kunt de ClickHouse-server onderbreken bij een ernstig probleem en alles oplossen.
Nu rijst de vraag hoe dit bescherming biedt tegen alters. Hier moeten we dieper kijken, want in oude versies van ClickHouse werkte de alter zo dat het direct de fragmenten wijzigde. Er is een datafragment met bepaalde bestanden, en we voeren bijvoorbeeld alter drop column. Dan wordt deze kolom fysiek verwijderd uit alle fragmenten.
Maar vanaf versie 20.3 is het alter-mechanisme volledig gewijzigd, en nu zijn de datafragmenten altijd immutabel. Ze veranderen helemaal niet - alters werken nu ongeveer zoals merges. In plaats van het fragment op zijn plaats te wijzigen, creƫren we een nieuw fragment. In het nieuwe fragment worden de onveranderde bestanden harde koppelingen, en als we een bepaalde kolom hebben verwijderd, zal deze eenvoudigweg ontbreken in het nieuwe fragment. Het oude fragment wordt standaard na acht minuten verwijderd, en hier kunt u de eerder genoemde instellingen aanpassen.
Hetzelfde geldt voor alters van het type mutaties. Wanneer je alter delete of alter update, wijzigt het geen fragment, maar creƫert het een nieuw fragment. En dan verwijdert het het oude fragment.
Wat te doen als de tabelstructuur is veranderd?
Hoe herstel je een back-up die is gemaakt met een oude schema? En de tweede vraag betreft de case met snapshots en bestandssystemen. Is Btrfs hier geschikt in plaats van ZFS op Linux LVM?
Als je attach partition Als er partities zijn met een andere structuur, zal ClickHouse u vertellen dat dat niet kan. De oplossing is als volgt. Ten eerste - creƫer een tijdelijke tabel van het type MergeTree met de oude structuur, voeg daar de gegevens aan toe met behulp van attach, voer een alter-query uit. Vervolgens kunt u de gegevens kopiƫren of verplaatsen en opnieuw attachen, of een query gebruiken. alter table move partition.
Nu de tweede vraag - kan Btrfs worden gebruikt? In de eerste plaats, als u LVM heeft, dan zijn LVM-snapshots voldoende, en het bestandssysteem kan ext4 zijn, dat doet er niet toe. Met Btrfs hangt alles af van uw ervaring met het gebruik ervan. Het is een volwassen bestandssysteem, maar het zijn er nog steeds enige twijfels over hoe alles in de praktijk zal functioneren in een specifiek scenario. Ik zou het niet aanraden als u Btrfs niet in de productie heeft.
Wat zijn momenteel de beste praktijken voor het herverdelen van gegevens?
De vraag over her-sharding is complex en veelzijdig. Hier kan ik meteen met verschillende opties antwoorden. Je kunt het vanuit Ć©Ć©n kant benaderen en zeggen - ClickHouse heeft geen ingebouwde mogelijkheid voor her-sharding. Maar ik vrees dat dit antwoord niemand zal bevallen. Dus je kunt het vanuit de andere kant bekijken en zeggen dat ClickHouse veel manieren heeft om gegevens te her-sharden.
Als de ruimte op het cluster opraakt of het niet meer aankan, voegt u nieuwe servers toe. Maar deze servers zijn standaard leeg, er zijn geen gegevens en er is geen belasting. U moet de gegevens herschikken zodat ze gelijkmatig verdeeld zijn over het vergrote cluster.
De eerste manier om dit te doen is door een deel van de partities naar de nieuwe servers te kopiƫren met behulp van een query. alter table fetch partition. Bijvoorbeeld, als u partities per maanden had en u neemt de eerste maand van 2017 en kopieert deze naar een nieuwe server, daarna - de derde maand kopieert u naar een andere nieuwe server. En zo doet u dit totdat het meer of minder gelijkmatig is.
Migratie kan alleen worden uitgevoerd voor die partities die niet veranderen tijdens het schrijven. Voor nieuwe partities moet het schrijven worden uitgeschakeld, omdat hun migratie niet atomair is. Anders krijgt u duplicaten of missers in de gegevens. Desondanks is deze methode praktisch en werkt deze vrij effectief. De reeds voorbereid gecomprimeerde partities worden over het netwerk verzonden, wat betekent dat de gegevens niet opnieuw worden gecomprimeerd of gecodeerd.
Deze methode heeft Ć©Ć©n nadeel, en dat hangt af van het sharding-schema, of je deze sharding-schema hebt ingesteld, en wat je sharding-sleutel is geweest. In jouw voorbeeld, voor de situatie met metrics, is de sharding-sleutel de hash van het pad. Wanneer je een select-query op de Distributed tabel uitvoert, gaat deze meteen naar alle shards van de cluster en haalt het gegevens daarvandaan.
Dit betekent dat het voor jou feitelijk niet uitmaakt welke gegevens op welke shard zijn terechtgekomen. Het belangrijkste is dat de gegevens voor Ć©Ć©n pad op Ć©Ć©n shard terechtkomen, maar welke dat precies is, maakt niet uit. In dit geval is het verplaatsen van kant-en-klare partitionen perfect, want bij select-queryās krijg je ook - zowel voor als na de reshuffling - geen problemen met het schema.
Maar er zijn ook complexere gevallen. Als je op applicatieniveau rekening houdt met een speciale sharding-schema, zodat deze klant op een bepaalde shard is geplaatst, en de query kan daar direct naartoe worden gestuurd in plaats van naar de Distributed tabel. Of je gebruikt een vrij recente versie van ClickHouse en hebt de instelling ingeschakeld optimize skip unused shards. In dat geval zal tijdens de select-query de expressie in de where-sectie worden geanalyseerd en berekend op welke shards je moet gaan volgens het sharding-schema. Dit werkt onder de voorwaarde dat de gegevens precies volgens dit sharding-schema zijn verdeeld. Als je ze handmatig hebt verplaatst, kan de overeenstemming veranderen.
Dus, dit is methode Ć©Ć©n. En ik wacht op je antwoord, of deze methode geschikt is of dat we verder gaan.
Vladimir Kolobaev, lead system administrator bij Avito: Alexey, de methode die je noemde, werkt niet goed wanneer je de belasting ook over lezen moet spreiden. We kunnen een partition nemen die maandelijks is en de vorige maand naar een andere node verplaatsen, maar wanneer de aanvraag voor deze gegevens komt, belasten we alleen die node. En we willen graag de hele cluster belasten, want anders hebben we een tijdje dat de volledige leeslast door twee shards wordt afgehandeld.
Alexey Milovidov: Het antwoord hier is vreemd - ja, het is slecht, maar het kan ook werken. Ik zal uitleggen hoe. We moeten kijken naar het belastingscenario dat achter uw gegevens zit. Als het om monitoringgegevens gaat, dan kunnen we bijna met zekerheid zeggen dat het overgrote deel van de verzoeken om verse gegevens gaat.
U heeft nieuwe servers geplaatst, oude partities overgezet, maar ook veranderd hoe verse gegevens worden geschreven. En verse gegevens zullen verspreid zijn over het hele cluster. Zo zullen verzoeken van de laatste vijf minuten al na vijf minuten gelijkmatig het cluster belasten, en over een dag zullen verzoeken van de afgelopen dag het cluster gelijkmatig belasten. Helaas zullen verzoeken van de vorige maand alleen naar een deel van de servers in het cluster gaan.
Maar vaak heeft u mogelijk geen verzoeken specifiek voor februari 2019. Waarschijnlijk, als de verzoeken naar 2019 gaan, dan zullen ze voor het hele jaar 2019 zijn - voor een lange tijdsperiode, en niet voor een klein interval. En zulke verzoeken zullen ook het cluster gelijkmatig kunnen belasten. Maar in het algemeen is uw opmerking volkomen juist, dat dit een ad hoc-oplossing is die de gegevens niet volledig gelijkmatig verspreidt.
Ik heb nog een paar punten om op uw vraag te antwoorden. Een daarvan gaat over hoe je de sharding-schema oorspronkelijk kunt opzetten, zodat er minder pijn is bij het herschalen. Dit is niet altijd mogelijk.
Bijvoorbeeld, u heeft monitoringgegevens. Monitoringgegevens groeien om drie redenen. De eerste is de accumulatie van historische gegevens. De tweede is de toename van verkeer. En de derde is de toename van het aantal dingen dat onder monitoring valt. Nieuwe microservices en metrics verschijnen die moeten worden opgeslagen.
Het is mogelijk dat de grootste groei precies met de derde reden samenhangt - de toename van het gebruik van monitoring. In dat geval moet je kijken naar het belastingprofiel, wat de belangrijkste select-verzoeken zijn. De belangrijkste select-verzoeken zullen waarschijnlijk gaan over een bepaalde subset van metrics.
Bijvoorbeeld, het gebruik van CPU op bepaalde servers door een bepaalde service. Dit betekent dat er een subset van sleutelwaarden is waarlangs je deze gegevens ophaalt. En de vraag om deze gegevens is waarschijnlijk vrij eenvoudig en wordt uitgevoerd in enkele tientallen milliseconden. Het wordt gebruikt voor monitoring services, voor dashboards. Ik hoop dat ik dit goed begrijp.
Vladimir Kolobaev: Het probleem is dat we vaak een beroep doen op historische gegevens, omdat we in real-time de huidige situatie vergelijken met de historische gegevens. Het is belangrijk voor ons om snel toegang te hebben tot een grote hoeveelheid gegevens, en ClickHouse kan dit uitstekend aan.
U heeft absoluut gelijk, de meeste leesverzoeken die we ervaren, komen van de afgelopen dag, net als elke monitoringsysteem. Maar daarbij is er ook een behoorlijk grote belasting op historische gegevens. Deze komt voornamelijk van het alertsysteem, dat elke dertig seconden vraagt aan ClickHouse: 'Geef me de gegevens van de afgelopen zes weken. En nu, maak een voortschrijdend gemiddelde daarvan, en laten we de huidige waarde vergelijken met de historische.'
Ik wil zeggen dat we voor zulke zeer recente aanvragen een kleine tabel hebben waarin we slechts twee dagen aan gegevens opslaan, en de belangrijkste verzoeken worden naar die tabel gestuurd. We sturen alleen de grote historische verzoeken naar de grote gesharderde tabel.
Alexey Milovidov: Helaas is het niet goed toepasbaar voor uw scenario, maar ik zal de beschrijving geven van twee slechte en complexe sharding schema's die je niet moet gebruiken, maar die wel worden gebruikt in de service van mijn vrienden.
Er is een hoofdcluster met gebeurtenissen van 'Yandex.Metrica'. Gebeurtenissen zijn paginaweergaven, klikken en overgangen. Het grootste deel van de verzoeken is gericht op een specifieke website. Je opent de service 'Yandex.Metrica', je hebt een site ā avito.ru, gaat naar het rapport, en er wordt een verzoek gedaan voor je site.
Maar er zijn ook andere verzoeken ā analytische en globale, die door interne analisten worden gedaan. Voor de duidelijkheid, interne analisten doen verzoeken alleen voor de 'Yandex'-services. Maar toch nemen zelfs de 'Yandex'-services een aanzienlijk aandeel in alle gegevens in beslag. Dit zijn verzoeken niet voor specifieke tellers, maar voor bredere filtratie.
Hoe organiseer je de gegevens zodanig dat het zowel met ƩƩn teller efficiƫnt werkt als ook met wereldwijde aanvragen? De complexiteit ligt ook in het feit dat het aantal aanvragen in ClickHouse op de 'Metrics'-cluster enkele duizenden per seconde bedraagt. Bij niet-triviale aanvragen, bijvoorbeeld, kan ƩƩn ClickHouse-server dat niet aan.
De grootte van de cluster is meer dan zeshonderd servers. Als je gewoon een Distributed-tabel over deze cluster legt en er enkele duizenden aanvragen naartoe stuurt, wordt het zelfs nog erger dan ze naar Ć©Ć©n server te sturen. Aan de andere kant, de optie waarin de gegevens gelijkmatig verdeeld zijn en wij verzoeken van alle servers aanvragen, schieten we direct af.
Er is een diametraal tegenovergestelde optie. Stel je voor dat we de gegevens scharden op basis van websites, en dat de aanvraag voor Ć©Ć©n website naar Ć©Ć©n shard gaat. Nu kan de cluster zonder problemen tienduizend aanvragen per seconde aan, maar op Ć©Ć©n shard zal een bepaalde aanvraag te langzaam werken. Die kan niet meer opgeschaald worden qua doorvoer. Vooral als het om de site avito.ru gaat. Het zou geen geheim zijn als ik zeg dat Avito een van de meest bezochte websites in het Russische internet is. Het verwerken ervan op Ć©Ć©n shard zou waanzin zijn.
Daarom is het shardschema op een slimmere manier opgezet. De hele cluster is verdeeld in een bepaald aantal kleine clusters, die wij lagen noemen. Binnen elke kleine cluster zijn er van tien tot enkele tientallen shards. In totaal zijn er negenendertig van zulke kleine clusters.
Hoe schaalt dit allemaal? Het aantal kleine clusters verandert niet ā zoals het enkele jaren geleden negenendertig was, zo is het gebleven. Maar binnen elk van hen vergroten we geleidelijk het aantal shards naarmate de gegevens zich ophopen. En het schardschema is in het algemeen als volgt: de opsplitsing in deze kleine clusters gebeurt op basis van websites, en om te begrijpen welke website bij welke cluster hoort, wordt er een aparte metadata-database in MySQL gebruikt. EĆ©n website ā in Ć©Ć©n kleine cluster. En binnen dat cluster gebeurt het scharden op basis van bezoekersidentificaties.
Bij het registreren splitsen we ze op basis van de rest van de deling van de bezoekers-ID. Maar bij het toevoegen van een nieuwe shard verandert het sharding-schema; we blijven splitsen, maar op basis van de rest van de deling door een ander getal. Dit betekent dat Ć©Ć©n bezoeker wel degelijk op meerdere servers is geplaatst, en daar kan niet op gerekend worden. Dit is uitsluitend gedaan zodat de gegevens beter gecomprimeerd worden. Bij verzoeken raadplegen we de Distributed-tabel, die kijkt naar de cluster en zich richt op tientallen servers. Zo'n onhandig schema.
Maar mijn verhaal zou incompleet zijn als ik niet zou zeggen dat we van dit schema zijn afgestapt. In het nieuwe schema hebben we alles veranderd en alle gegevens gekopieerd met behulp van clickhouse-copier.
In het nieuwe schema worden alle sites verdeeld in twee categorieƫn: grote en kleine. Ik weet niet hoe de grens daar is gekozen, maar het resultaat is dat grote sites worden opgeslagen op ƩƩn cluster met 120 shards, elk met drie replicaties - wat betekent 360 servers. En het sharding-schema is zo dat elke aanvraag onmiddellijk naar alle shards gaat. Als je nu in 'Yandex.Metrica' een willekeurige rapportpagina opent voor avito.ru, gaat de aanvraag naar 120 servers. Er zijn niet veel grote sites in het Russischtalige internet. En het aantal aanvragen is niet duizend per seconde, maar zelfs minder dan honderd. Dit alles wordt probleemloos verwerkt door de Distributed-tabel, die elk van hen met 120 servers behandelt.
En de tweede cluster is voor kleine sites. Hier is het sharding-schema op basis van de site-ID, en elke aanvraag gaat precies naar Ć©Ć©n shard.
ClickHouse heeft een hulpprogramma genaamd clickhouse-copier. Kun je daar meer over vertellen?
Ik zal meteen zeggen dat deze oplossing omvangrijker en iets minder efficiƫnt is. Het voordeel is dat het de gegevens volledig verspreidt volgens het schema dat u opgeeft. Maar een nadeel van de tool is dat deze absoluut geen resharding uitvoert. Het kopieert gegevens van het ene cluster-schema naar het andere cluster-schema.
Dit betekent dat voor het functioneren hiervan u twee clusters moet hebben. Ze kunnen op dezelfde servers worden geplaatst, maar desalniettemin zullen de gegevens niet incrementeel worden verplaatst, maar worden gekopieerd.
Bijvoorbeeld, er waren vier servers, nu zijn er acht. U maakt op alle servers een nieuwe Distributed-tabel, nieuwe lokale tabellen aan en start de clickhouse-copier, waarbij u de werkwijze opgeeft, dat hij daaruit moet lezen, de nieuwe shardingschema moet aannemen en de gegevens daarheen moet verplaatsen. En u heeft op de oude servers anderhalf keer meer ruimte nodig dan er nu is, omdat de oude gegevens daarop moeten blijven, en daarbovenop komt de helft van dezelfde oude gegevens. Als u van tevoren hebt nagedacht over het her-sharden van de gegevens en er is ruimte, dan is deze methode geschikt.
Hoe is clickhouse-copier intern ingesteld? Het verdeelt het hele werk in een set van taken voor het verwerken van Ć©Ć©n partitie van Ć©Ć©n tabel op Ć©Ć©n shard. Al deze taken kunnen parallel worden uitgevoerd, en clickhouse-copier kan op verschillende machines in meerdere instanties worden uitgevoerd, maar wat het doet voor Ć©Ć©n partitie is niets anders dan insert select. Gegevens worden gelezen, gedecomprimeerd, opnieuw geshard, vervolgens opnieuw gecomprimeerd, ergens geschreven, en weer hersorteerd. Dit is een zwaardere oplossing.
Jullie hadden een proefstuk dat herverdeling heette. Wat is daarmee gebeurd?
U had al in 2017 een pilotproject dat resharding werd genoemd. Er is zelfs een optie in ClickHouse. Ik begrijp dat het niet van de grond is gekomen. Kunt u uitleggen waarom dat zo is? Het lijkt namelijk heel relevant.
Het probleem is dat bij de noodzaak om gegevens ter plekke te hersharderen een vrij complexe synchronisatie vereist is om dit atomair te doen. Toen we begonnen te kijken naar hoe deze synchronisatie is ingesteld, werd het duidelijk dat er fundamentele problemen zijn. En deze fundamentele problemen zijn niet alleen theoretisch, maar beginnen zich ook onmiddellijk in de praktijk te tonen in de vorm van iets wat heel eenvoudig te verklaren is ā niets werkt.
Is het mogelijk om alle delen van gegevens samen te voegen voordat ze naar langzame schijven worden verplaatst?
Een vraag over TTL met de optie verplaatsen naar langzamere schijven in de context van merges. Is er een manier, behalve via cron, om alle delen samen te voegen tot Ć©Ć©n voordat ze naar langzamere schijven worden verplaatst?
Het antwoord op de vraag of het mogelijk is om automatisch alle stukken samen te voegen tot Ć©Ć©n vĆ³Ć³r verplaatsing ā is nee. Ik denk dat dit niet nodig is. Het is ook mogelijk om niet alle delen tot Ć©Ć©n te combineren, maar gewoon aan te nemen dat ze automatisch naar de langzamere schijven worden verplaatst.
We have two criteria for the migration rules. The first is based on usage. If there's less than a certain percentage of free space at the current storage level, we select one chunk and transfer it to slower storage. To be precise, it's not slower, but the next one ā depending on your setup.
The second criterion is based on size. It concerns the transfer of large chunks. You can adjust the threshold for free space on the fast disk, and data will be transferred automatically.
Hoe kan ik upgraden naar nieuwe versies van ClickHouse als ik de compatibiliteit niet van tevoren kan controleren?
This topic is regularly discussed taking different versions into account. Still, how safe is it to upgrade from version 19.11 to 19.16 and, for example, from 19.16 to 20.3? Whatās the best way to transition to new versions without the opportunity to check compatibility in a sandbox beforehand?
There are a few 'golden' rules. The first is . It's extensive, but it includes specific points about backward-incompatible changes. These points shouldn't be seen as red flags. Usually, they are minor incompatibilities related to specific edge functionalities that you're probably not using.
The second rule is, if there's no way to check compatibility in a sandbox and you want to upgrade directly in production, the recommendation is ā don't do it. First, create a sandbox and test it. If you lack a test environment, your company is likely not very large, meaning you can copy part of the data onto your laptop and verify that everything works correctly. You can even set up several replicas locally on your machine. Alternatively, you can set up a new version nearby and import some data there ā thus creating an improvised test environment.
Another rule is not to upgrade within a week after a version release due to bug fixes in production and subsequent quick patches. Letās break down ClickHouse version numbering to avoid confusion.
Er is versie 20.3.4. Het getal 20 staat voor het jaar van uitgave - 2020. Wat betreft de interne werking heeft dit echter geen belang, dus daar zullen we niet op ingaan. Verder - 20.3. We verhogen het tweede cijfer - in dit geval 3 - elke keer wanneer we een release uitbrengen met nieuwe functionaliteit. Als we een functie in ClickHouse willen toevoegen, moeten we dit getal verhogen. Dit betekent dat ClickHouse in versie 20.4 nog beter zal presteren. Het derde cijfer - 20.3.4. Hier is 4 het aantal patch-releases waarin we geen nieuwe functies hebben toegevoegd, maar wel bugs hebben verholpen. En 4 betekent dat we dit vier keer hebben gedaan.
Je moet niet denken dat dit iets vreselijks is. Doorgaans kan de gebruiker de meest recente versie installeren en deze zal zonder problemen Ć©Ć©n jaar functioneren. Maar stel je voor dat bij een functie voor het verwerken van bitmap-afbeeldingen, die door onze Chinese collega's is toegevoegd, de server crasht bij het doorgeven van onjuiste argumenten. We moeten dit corrigeren. We zullen een nieuwe patch-versie uitbrengen en ClickHouse zal stabieler worden.
Als je ClickHouse in productie draait en er komt een nieuwe versie van ClickHouse met extra functies - bijvoorbeeld 20.4.1 - wees dan niet te haastig om deze direct in productie te nemen. Waarom zou je deze Ć¼berhaupt nodig hebben? Als je ClickHouse nog niet gebruikt, kun je het installeren en zal het waarschijnlijk goed gaan. Maar als ClickHouse al stabiel draait, volg dan de patches en updates - welke problemen we verhelpen.
Kirill Shvakov: Ik wil nog iets toevoegen over testomgevingen. Iedereen is erg bang voor testomgevingen en denkt om de een of andere reden dat als je een zeer grote ClickHouse-cluster hebt, de testomgeving ook even groot moet zijn, of op zijn minst tien keer kleiner. Dat is absoluut niet het geval.
Ik kan zeggen op basis van mijn eigen ervaring. Ik heb een project en daar is ClickHouse. Onze testomgeving voor dit project is een kleine virtuele machine in Hetzner voor twintig euro, waar alles volledig is opgezet. Om dit te doen, hebben we volledige automatisering in Ansible, en daarom maakt het in principe niet uit waar je het draait - op fysieke servers of eenvoudigweg in virtuele machines.
Wat kan er gedaan worden? Het zou goed zijn om in de ClickHouse-documentatie een voorbeeld op te nemen van hoe je zelf een kleine cluster kunt opzetten - in Docker, in LXC, en mogelijk een Ansible-playbook te maken, omdat verschillende mensen verschillende implementaties hebben. Dit zou veel vereenvoudigen. Wanneer je in vijf minuten een cluster opzet, is het veel eenvoudiger om iets uit te zoeken. Het is veel handiger, want een productieversie draaien die je niet hebt getest - dat is een weg naar nergens. Soms werkt het, en soms niet. Daarom is het slecht om op succes te hopen.
Maxim Kotyakov, senior backend engineer bij Avito: Ik zal iets meer vertellen over testomgevingen vanuit de problemen van grote bedrijven. Wij hebben een volledige acceptatiecluster van ClickHouse, dat qua dataschema's en instellingen een exacte kopie is van onze productie. Dit cluster draait in behoorlijk verwaarloosde containers met minimale middelen. We schrijven een bepaald percentage van de productiegegevens daarheen, gelukkig hebben we de mogelijkheid om de stroom in Kafka te repliceren. Alles daar is gesynchroniseerd en schaalbaar - zowel qua kracht als qua stroom, en in theorie zou het qua metrics zich moeten gedragen als productie, als alle andere dingen gelijk zijn. Alles wat potentieel explosief is, gaat eerst naar deze testomgeving en rijpt daar enkele dagen tot het klaar is. Maar natuurlijk is deze oplossing duur, zwaar en met niet-nul kosten voor ondersteuning.
Alexey Milovidov: Ik zal uitleggen wat de testomgeving van onze vrienden bij "Yandex.Metrica" inhoudt. EĆ©n cluster had meer dan 600 servers, een andere ongeveer 360, en er is nog een derde en meerdere clusters. De testomgeving voor een van hen bestaat simpelweg uit twee shards met twee replicas in elk. Waarom twee shards? Zodat er niet slechts Ć©Ć©n is. En ook replicas zodat deze er zijn. Simpelweg een minimaal aantal dat je je kunt veroorloven.
Deze testomgeving maakt het mogelijk om de werking van queries te controleren en te zien of er geen grote storingen zijn. Maar vaak ontstaan problemen van geheel andere aard, waarbij alles werkt, maar er zijn enkele kleine veranderingen in de belasting.
Ik geef een voorbeeld. We hebben besloten om de nieuwe versie van ClickHouse te installeren. Deze is beschikbaar gesteld in de testomgeving, geautomatiseerde tests zijn uitgevoerd in "Yandex.Metrica" die de gegevens tussen de oude versie en de nieuwe vergelijken, terwijl de hele pipeline draait. Uiteraard zijn ook de groene tests van onze CI uitgevoerd. Anders zouden we deze versie zelfs niet hebben aangeboden.
Alles gaat prima. We beginnen met uitrollen naar productie. Ik ontvang een melding dat de belasting op de grafieken meerdere keren is gestegen. We rollen de versie terug. Ik kijk naar de grafiek en zie: de belasting is tijdens de uitrol inderdaad meerdere keren gestegen en is weer gedaald toen we het terugdraaiden. Toen begonnen we de versie terug te rollen. En de belasting steeg precies op die manier weer en daalde precies weer terug. Dus de conclusie is dat de belasting steeg in verband met de uitrol, dat is niets vreemds.
Daarna was het moeilijk om collega's ervan te overtuigen uiteindelijk de nieuwe versie te installeren. Ik zeg: "Alles is in orde, rol het uit. Houd je duimen omhoog, alles zal werken. De belasting is nu gestegen op de grafieken, maar het is goed. Houd vol." Kortom, dat hebben we gedaan, en het is gedaan ā de versie is uitgerold naar productie. Maar bijna bij elke uitrol doen zich soortgelijke problemen voor.
Kill query zou zoekopdrachten moeten beƫindigen, maar dat doet het niet. Waarom niet?
Er kwam een gebruiker naar me toe, een of andere analist, en creĆ«erde een verzoek dat mijn ClickHouse-cluster hielp. Een of andere node of het cluster in zijn geheel ā afhankelijk van waar de replica of shard dat verzoek terechtkwam. Ik zie dat alle CPU-bronnen op deze server in de min staan, alles is rood. Toch antwoordt ClickHouse op de verzoeken. En ik schrijf: "Toon me alsjeblieft de process list, welk verzoek veroorzaakte deze waanzin."
Ik vind dat verzoek en schrijf hem kill. En ik zie dat er niets gebeurt. Mijn server staat in de min, ClickHouse geeft me verder een aantal commando's en laat zien dat de server nog leeft, en alles is goed. Maar ik heb degredatie in alle gebruikersverzoeken, degredatie in het schrijven naar ClickHouse begint, en mijn kill query werkt niet. Waarom? Ik dacht dat kill query's verzoeken moesten stoppen, maar dat gebeurt niet.
Dit wordt een vrij vreemd antwoord. Het probleem is dat kill query niet verzoeken beƫindigt.
Kill query stelt een klein vlaggetje in genaamd "ik wil dat dit verzoek beƫindigd wordt". En het verzoek kijkt bij het verwerken van elk blok naar dat vlaggetje. Als het is ingesteld, stopt het verzoek. Dit betekent dat niemand het verzoek beƫindigt; het moet zelf alles controleren en stoppen. Dit zou in alle gevallen moeten werken wanneer het verzoek zich in een staat van blokkenverwerking bevindt. Het verwerkt het volgende gegevensblok, controleert het vlaggetje en stopt.
Dit werkt niet in gevallen waarbij de aanvraag is geblokkeerd voor een bepaalde bewerking. Het is echter waarschijnlijk niet uw geval, omdat u zegt dat het een hoop serverresources verbruikt. Het is mogelijk dat dit niet werkt bij externe sortering en nog enkele andere details. Maar over het algemeen zou dit niet zo moeten zijn, het is een bug. Het enige wat ik kan adviseren, is om ClickHouse te updaten.
Hoe bereken je de responstijd bij een leesbelasting?
Er is een tabel waarin aggregaties per item worden opgeslagen - verschillende tellingen. Het aantal rijen is ongeveer honderd miljoen. Is het mogelijk om op een voorspelbare responstijd te rekenen als er 1K RPS voor 1K items binnenkomt?
Gezien de context lijkt het te gaan om een leesbelasting, want voor schrijven zijn er geen problemen - of het nu duizend, honderdduizend of soms zelfs meerdere miljoenen rijen zijn die ingevoegd kunnen worden.
Leessverzoeken zijn heel divers. Bij select 1 kan ClickHouse ongeveer tienduizenden aanvragen per seconde verwerken, dus zelfs aanvragen op Ć©Ć©n sleutel vereisen al enige resources. En zulke puntverzoeken zijn moeilijker dan in bepaalde key-value databases, omdat voor elke lezing een gegevensblok per index moet worden gelezen. De index adresseert niet elke record, maar elk bereik. Dit betekent dat je het volledige bereik moet lezen - dat is standaard 8192 rijen. En je zult een gecomprimeerd gegevensblok van 64 Kb tot 1 Mb moeten decomprimeren. Gewoonlijk duren zulke puntverzoeken enkele milliseconden. Maar dit is de eenvoudigste optie.
Laten we een eenvoudige rekensom maken. Als je enkele milliseconden met duizend vermenigvuldigt, krijg je enkele seconden. Het lijkt alsof het onmogelijk is om duizend aanvragen per seconde te verwerken, maar in werkelijkheid is het mogelijk omdat we meerdere CPU-kernen hebben. Dus in principe kan ClickHouse soms 1000 RPS aan, maar voornamelijk bij korte, puntachtige aanvragen.
Als je een ClickHouse-cluster moet opschalen op basis van het aantal eenvoudige aanvragen, raad ik het eenvoudigste aan - verhoog het aantal replicas en stuur aanvragen naar een willekeurige replica. Als Ć©Ć©n replica vijfhonderd aanvragen per seconde aankan, wat volledig haalbaar is, dan kunnen drie replicas anderhalve duizend aanvragen aan.
Soms is het mogelijk om ClickHouse te configureren voor het maximaal aantal puntlezingen. Wat is daarvoor nodig? Ten eerste, verlaag de granulariteit van de index. Dit moet echter niet tot Ć©Ć©n worden verlaagd, maar met het idee dat het aantal records in de index enkele miljoenen of tientallen miljoenen op de server zal zijn. Als er honderd miljoen rijen in de tabel staan, kan de granulariteit op 64 worden ingesteld.
Je kunt de grootte van het gecomprimeerde blok verminderen. Hiervoor zijn er instellingen. min compress blokgrootte, max compress blokgrootte. Deze kunnen worden verminderd, gegevens kunnen opnieuw worden geladen, en dan zullen puntopdrachten sneller zijn. Maar ClickHouse is nog steeds geen key-value database. Een groot aantal kleine verzoeken is een antipatronenlast.
Kirill Shvakov: Ik geef een advies voor het geval daar gewone counters zijn. Dit is een vrij standaard situatie waarin ClickHouse een teller opslaat. Ik heb een gebruiker, hij komt uit een bepaald land, plus nog een derde veld, en er moet incrementeel iets worden verhoogd. Neem MySQL, maak een unieke sleutel - in MySQL is dit duplicaat sleutel, en in PostgreSQL is dit conflict - en voeg met een plusteken toe. Dit zal veel beter werken.
Wanneer je maar een beetje gegevens hebt, heeft het weinig zin om ClickHouse te gebruiken. Er zijn gewone databases en die kan dit goed aan.
Wat kan je afstemmen in ClickHouse om meer gegevens in de cache te hebben?
Stel de situatie voor - de servers hebben 256 GB RAM, in de dagelijkse routine neemt ClickHouse ongeveer 60-80 GB en pieken tot 130. Wat kan er worden ingeschakeld en afgestemd om meer gegevens in de cache te hebben en daardoor minder disktoegangen?
In het algemeen gaat de page cache van het besturingssysteem goed om met deze taak. Als je gewoon top opent en daar kijkt naar cached of free - daar staat ook hoeveel er in de cache is opgeslagen - dan kun je opmerken dat al het vrije geheugen gebruikt is voor de cache. En deze gegevens zullen bij het lezen niet van de schijf komen, maar uit het RAM. Ik kan zeggen dat de cache effectief wordt gebruikt, omdat precies de gecomprimeerde gegevens worden gecachet.
Toch, als je sommige eenvoudige verzoeken nog sneller wilt maken, is er de mogelijkheid om binnen ClickHouse een cache voor ongecomprimeerde gegevens in te schakelen. Dit wordt genoemd. ongecomprimeerde cache. In het configuratiebestand config.xml stelt u de uncompressed cache size in op de waarde die u nodig hebt - ik raad aan niet meer dan de helft van het beschikbare RAM te gebruiken, omdat de rest voor page cache zal worden gebruikt.
Daarnaast zijn er twee instellingen op het niveau van verzoeken. De eerste instelling is use uncompressed cache ā schakelt het gebruik ervan in. Het wordt aanbevolen om dit in te schakelen voor alle verzoeken, behalve zware verzoeken die alle gegevens kunnen lezen en deze cache kunnen legen. En de tweede instelling is iets als het maximale aantal rijen dat voor de cache kan worden gebruikt. Het beperkt automatisch grote verzoeken zodat ze om de cache heen gaan.
Hoe kan ik storage_configuration instellen voor opslag in het RAM?
In de nieuwe ClickHouse-documentatie las ik een sectie die gerelateerd is . In de beschrijving is er een voorbeeld met een snelle SSD.
Het is interessant hoe hetzelfde kan worden geconfigureerd met volume hot memory. En nog een vraag. Hoe werkt select met zo'n dataorganisatie, zal het de hele set lezen of alleen wat op de schijf ligt, en worden deze gegevens in het geheugen gecomprimeerd? En hoe werkt de sectie prewhere met zo'n organisatie van gegevens?
Deze instelling heeft invloed op de opslag van datablokken, en hun indeling verandert niet.
Laten we het nader bekijken.
Het is mogelijk om dataopslag in RAM in te stellen. Alles wat voor de schijf wordt geconfigureerd, is het pad. U creƫert een tmpfs-partitie die is gemonteerd op een pad in het bestandssysteem. U geeft dit pad op als het pad voor de opslag van gegevens voor de heetste partitie, daar beginnen de datablokken te stromen en op te slaan, alles goed.
Maar ik raad aan dit niet te doen vanwege de lage betrouwbaarheid, hoewel als u minimaal drie replica's in verschillende datacentra heeft, dan kan het. Mocht er iets zijn, dan worden de gegevens hersteld. Stel je voor dat de server plotseling wordt uitgeschakeld en weer wordt ingeschakeld. De partitie is opnieuw gemonteerd, maar er is leegte. De ClickHouse-server ziet bij het opstarten dat deze blokken ontbreken, hoewel ze volgens de metadata van ZooKeeper aanwezig zouden moeten zijn. Hij kijkt op welke replica's ze aanwezig zijn, vraagt ze op en downloadt ze. Op deze manier worden de gegevens hersteld.
In dit opzicht verschilt het opslaan van gegevens in het RAM fundamenteel niet van het opslaan op de schijf, omdat bij het schrijven van gegevens naar de schijf ze ook eerst in de page cache terechtkomen en fysiek uitgesteld worden opgeslagen. Dit hangt af van de manier waarop het bestandssysteem is gemonteerd. Maar voor de zekerheid, ik zeg dat ClickHouse geen fsync doet bij insert.
De gegevens in het RAM worden precies in hetzelfde formaat opgeslagen als op de schijf. Een select-query selecteert op dezelfde manier de delen die gelezen moeten worden, kiest benodigde dataranges en leest deze. En prewhere werkt precies hetzelfde, ongeacht of de gegevens in het RAM of op de schijf stonden.
Tot hoeveel unieke waarden is Low Cardinality effectief?
Low Cardinality is ingenieus opgezet. Het maakt gegevenswoordenboeken, maar deze zijn lokaal. Ten eerste heeft elk stuk zijn eigen woordenboek, ten tweede kunnen ze zelfs binnen Ć©Ć©n stuk verschillend zijn voor elk bereik. Wanneer het aantal unieke waarden een drempelwaarde bereikt - ik geloof, Ć©Ć©n miljoen - wordt het woordenboek eenvoudig uitgesteld en wordt er een nieuw aangemaakt.
Het antwoord in het algemeen: voor elk lokaal bereik - laten we zeggen, voor elke dag - is Low Cardinality effectief tot ongeveer een miljoen unieke waarden. Daarna zal er gewoon een fallback zijn, waarbij er veel verschillende woordenboeken worden gebruikt in plaats van ƩƩn. Het zal ongeveer zo werken als een gewone string-kolom, misschien iets minder efficiƫnt, maar er zal niet echt een grote prestatieverandering optreden.
Wat zijn de beste praktijken voor full-text search op een tabel met vijf miljard rijen?
Er zijn verschillende antwoorden mogelijk. De eerste is te zeggen dat ClickHouse geen systeem is voor full-text zoekopdrachten. Daar zijn speciale systemen voor, bijvoorbeeld, en . Desondanks kom ik steeds vaker mensen tegen die zeggen dat ze van Elasticsearch naar ClickHouse overstappen.
Waarom gebeurt dit? Ze leggen uit dat Elasticsearch bij bepaalde volumes niet meer met de belasting omgaat, te beginnen met de indexbouw. Indexen worden te zwaar en als je de gegevens simpelweg naar ClickHouse verplaatst, blijken ze in volume veel efficiƫnter opgeslagen te zijn. Daarbij zijn zoekopdrachten vaak niet zo dat je een zin met inachtneming van morfologie in alle gegevens moet vinden, maar heel andere. Bijv. vinden in de logs van de afgelopen uren op een bepaalde byte-subsequentie.
In dit geval maak je in ClickHouse een index waarbij het eerste veld de datum met tijd is. En de grootste beperking van gegevens zal inderdaad gebaseerd zijn op een datumbereik. Binnen het geselecteerde datumbereik kun je doorgaans een full-text zoekopdracht uitvoeren, zelfs met de brute force-methode met behulp van like. De like-operator in ClickHouse is de meest efficiƫnte like-operator die je kunt vinden. Als je een betere vindt, laat het me weten.
Maar like is nog steeds een full scan. En een full scan kan traag zijn, niet alleen qua CPU, maar ook qua schijf. Stel dat je Ć©Ć©n terabyte aan gegevens per dag hebt, en je zoekt een bepaald woord, dan moet je die terabyte scannen. En dat is waarschijnlijk op gewone harde schijven, wat er uiteindelijk toe leidt dat je niet meer via SSH op deze server kunt inloggen.
In dit geval ben ik bereid een kleine truc voor te stellen. Het is een experimentele aanpak - het kan werken, maar het kan ook niet. In ClickHouse zijn er full-text indexen in de vorm van trigram Bloom-filters. Onze collega's van het bedrijf Arenadata hebben deze indexen al getest, en vaak functioneren ze precies zoals bedoeld.
Om ze goed te gebruiken, is het belangrijk om goed te begrijpen hoe ze werken: wat een trigram Bloom-filter is en hoe je de grootte ervan kiest. Ik kan zeggen dat ze nuttig zijn voor queries naar zeldzame zinnen en substrings die zelden in de gegevens voorkomen. In dit geval worden subbereiken uit de indexen gekozen, en worden er minder gegevens gelezen.
Onlangs zijn er in ClickHouse nog geavanceerdere functies voor full-text zoeken toegevoegd. Ten eerste is er nu de mogelijkheid om meerdere substrings tegelijk in ƩƩn doorloop te doorzoeken, inclusief opties voor het rekening houden van hoofdlettergebruik, zonder hoofdlettergebruik, met ondersteuning voor UTF-8 of alleen voor ASCII. Kies de meest efficiƫnte die je nodig hebt.
Er is nu ook de mogelijkheid om meerdere reguliere expressies in ƩƩn keer te doorzoeken. Je hoeft niet te schrijven X like ƩƩn substring or X like een andere substring. Je schrijft het direct, en alles wordt maximaal efficiƫnt uitgevoerd.
Ten derde - er is nu benaderd zoeken met regex en benaderd zoeken naar substrings. Als iemand een woord met een typefout heeft geschreven, wordt het gezocht op basis van maximale overeenkomst.
Hoe organiseer je de toegang tot ClickHouse voor een groot aantal gebruikers?
Vertel ons hoe we de toegang voor een groot aantal gebruikers en analisten het best kunnen organiseren. Hoe vormen we een wachtrij, prioriteren we verzoeken voor max gelijktijdige queries en welke tools gebruiken we?
Als de cluster groot genoeg is, kan het een goed idee zijn om twee extra servers op te zetten, die als toegangspunt voor analisten dienen. Dit betekent dat we analisten niet direct toegang geven tot specifieke shards van de cluster, maar gewoon twee lege servers creƫren, zonder data, en daar de toegangsrechten op instellen. Bij dit proces worden gebruikersinstellingen voor gedistribueerde verzoeken doorgegeven aan de externe servers. Dat wil zeggen, je configureert alles op deze twee servers, en de instellingen hebben effect op de hele cluster.
In principe zijn deze servers zonder data, maar de hoeveelheid RAM die ze hebben is cruciaal 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 naar de instellingen te kijken die verband houden met alle mogelijke limieten. Als ik nu als analist de cluster 'Yandex.Metrica' binnenkom en een verzoek doe, select count from hits, dan krijg ik onmiddellijk een uitzondering dat ik de query niet kan uitvoeren. Het maximale aantal rijen dat ik mag scannen is honderd miljard, terwijl er in totaal vijftig biljoen rijen zijn in Ć©Ć©n tabel op de cluster. Dit is de eerste beperking.
Stel dat ik de limiet voor het aantal rijen verwijder en de query opnieuw uitvoer. Dan zie ik de volgende uitzondering: de instelling is ingeschakeld, force index by date. Ik kan de query niet uitvoeren zonder een datumbereik op te geven. Verwacht niet dat analisten dit handmatig zullen invoeren. Een typisch geval is dat je een datumbereik schrijft waar event date between week is. En dan is er gewoon ergens een haakje verkeerd geplaatst, waardoor in plaats van and or ontstaat ā or URL match. Als er geen limiet is, gaat het de URL-kolom scannen en verbruikt het gewoon enorm veel middelen.
Bovendien zijn er in ClickHouse twee prioriteitsinstellingen. Helaas zijn ze erg primitief. EĆ©n wordt simpelweg genoemd, priority. Als de prioriteit āØ 0 is en aanvragen met een bepaalde prioriteit worden uitgevoerd, maar er wordt tegelijkertijd een aanvraag uitgevoerd met een prioriteit die een lager waarde heeft, wat betekent een hogere prioriteit, dan wordt de aanvraag met de hogere prioriteitswaarde, wat een lagere prioriteit betekent, simpelweg gepauzeerd en werkt niet gedurende deze tijd.
Dit is een zeer grove instelling en is niet geschikt voor situaties waarin er een constante belasting op de cluster is. Maar als je korte, impulsieve belangrijke aanvragen hebt en de cluster meestal inactief is, kan deze instelling geschikt zijn.
De volgende prioriteitsinstelling heet OS-threadprioriteit. Deze stelt simpelweg de nice-waarde in voor alle threads die een aanvraag verwerken voor de Linux-scheduler. Het werkt niet perfect, maar het werkt toch. Als je de laagste nice-waarde instelt ā dat is de grootste waarde, wat betekent de laagste prioriteit ā en voor aanvragen met hoge prioriteit -19 instelt, dan zal de CPU laagprioritaire aanvragen ongeveer vier keer minder consumeren dan hoogprioritaire aanvragen.
Daarnaast moet je de maximale uitvoeringstijd van een aanvraag instellen ā laten we zeggen vijf minuten. De minimale snelheid van de uitvoering van een aanvraag ā dat is de meest geavanceerde instelling. Deze instelling is al lang geleden beschikbaar en is nodig om niet alleen te stellen dat ClickHouse niet vertraagt, maar om dit daadwerkelijk af te dwingen.
Stel je voor dat je instelt: als een aanvraag minder dan Ć©Ć©n miljoen rijen per seconde verwerkt ā dat moet niet zo zijn. Dit doet ons goede naam en onze uitstekende database tekort. Laten we dit gewoon verbieden. Er zijn eigenlijk twee instellingen hiervan. De ene heet minimale uitvoeringssnelheid ā in rijen per seconde, en de andere heet timeout voordat de minimale uitvoeringssnelheid wordt gecontroleerd ā standaard vijftien seconden. Dus vijftien seconden is toegestaan, en daarna, als het langzaam is, dan gewoon een uitzondering gooien ā de aanvraag onderbreken.
Daarnaast moeten er quota worden ingesteld. In ClickHouse is er een ingebouwde mogelijkheid voor quota die het verbruik van middelen bijhoudt. Maar helaas zijn deze niet voor fysieke middelen zoals CPU, schijven, maar voor logische middelen ā het aantal verwerkte aanvragen, rijen en gelezen bytes. En je kunt bijvoorbeeld maximaal honderd aanvragen in vijf minuten en duizend aanvragen per uur instellen.
Waarom is dit belangrijk? Omdat sommige analytische verzoeken handmatig vanaf de ClickHouse-client worden uitgevoerd. En dat zal goed gaan. Maar als je geavanceerde analisten in je bedrijf hebt, zullen ze een script schrijven, en in dat script kan een fout zitten. En die fout zorgt ervoor dat het verzoek in een oneindige lus wordt uitgevoerd. Dat is waar je je tegen moet beschermen.
Is het mogelijk om de resultaten van Ć©Ć©n query aan tien klanten te geven?
We hebben een paar gebruikers die graag met zeer grote verzoeken op hetzelfde moment komen. Het verzoek is groot, het 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 komt, slechts Ć©Ć©n keer uit te voeren en het resultaat aan tien klanten te geven?
Het probleem is dat we geen resultaten in de cache of cache van tussentijdse gegevens hebben. Er is een page cache van het besturingssysteem, die ervoor zorgt dat gegevens niet opnieuw van de schijf hoeven te worden gelezen, maar helaas zullen de gegevens nog steeds worden uitgepakt, gedeserialiseerd en opnieuw verwerkt.
We zouden op een of andere manier dat willen vermijden, hetzij door tussentijdse gegevens te cachen, hetzij door soortgelijke verzoeken in een wachtrij te plaatsen en een resultaten-cache toe te voegen. Momenteel hebben we een pull request in ontwikkeling die een cache voor verzoeken toevoegt, maar alleen voor subvragen in de secties in en join ā dat wil zeggen, de oplossing is niet volledig.
Desondanks komt ook bij ons deze situatie voor. Een sprekend voorbeeld zijn verzoeken met paginering. Er is een rapport, het heeft meerdere pagina's, en er wordt een verzoek gedaan met limit 10. Dan hetzelfde, maar limit 10,10. Vervolgens de volgende pagina. En de vraag is, waarom berekenen we dit telkens weer? Maar momenteel is er geen oplossing, en dit kan niet worden vermeden.
Er is een alternatieve oplossing die naast ClickHouse wordt geplaatst ā .
Kirill Shvakov: In ClickHouse Proxy is er een ingebouwde rate limiter en ingebouwde resultaten-cache. Er zijn heel veel instellingen gedaan, omdat een vergelijkbare taak moest worden opgelost. Proxy maakt het mogelijk om verzoeken te beperken door ze in een wachtrij te plaatsen en in te stellen hoe lang de cache van verzoeken meegaat. Als de verzoeken inderdaad hetzelfde zijn, zal Proxy ze meerdere keren teruggeven, maar slechts Ć©Ć©n keer naar ClickHouse gaan.
In Nginx is er ook caching in de gratis versie, en dat zal ook werken. Nginx heeft zelfs instellingen dat als verzoeken tegelijkertijd binnenkomen, het andere zal vertragen totdat Ć©Ć©n voltooid is. Maar de configuratie in ClickHouse Proxy is veel beter. Het is specifiek ontworpen voor ClickHouse, precies voor deze verzoeken, en past daardoor beter. En het is ook eenvoudig te installeren.
Hoe omgaan met asynchrone operaties en materialized views?
Er is een probleem dat bewerkingen met de replicatie-engine asynchroon zijn - eerst worden de gegevens geschreven, daarna vindt de samenvoeging plaats. Als er onder de tabel een gematerialiseerde tabel met aggregraties leeft, zullen er duplicaten in worden geschreven. En als er geen complexe logica is, zullen de gegevens gedupliceerd worden. Wat kan hiermee gedaan worden?
Er is een voor de hand liggende oplossing - implementeer een trigger voor een bepaalde klasse van materialized views tijdens de asynchrone samenvoegoperatie. Zijn er enige 'zilver bullet'-oplossingen of plannen voor het implementeren van dergelijke functionaliteiten?
Het is belangrijk om te begrijpen hoe deduplicatie werkt. Wat ik nu ga vertellen, is niet direct gerelateerd aan de vraag, maar het is goed om dit in gedachten te houden.
Bij het invoegen in een gerepliceerde tabel is er deduplicatie van geheel ingevoegde blokken. Als je hetzelfde blok opnieuw invoegt, met hetzelfde aantal rijen in dezelfde volgorde, dan worden de gegevens gededupliceerd. Je krijgt 'Ok' als antwoord op de insert, maar feitelijk zal er slechts Ć©Ć©n batch gegevens worden vastgelegd, en deze zal niet worden gedupliceerd.
Dit is nodig voor de duidelijkheid. Als je tijdens het invoegen 'Ok' hebt ontvangen, betekent dat dat je gegevens zijn ingevoegd. Als je een fout van ClickHouse ontvangt, betekent dit dat ze niet zijn ingevoegd en dat de invoeging herhaald moet worden. Maar als de verbinding tijdens het invoegen is verbroken, weet je niet of de gegevens zijn ingevoegd of niet. De enige optie is om de invoeging opnieuw te herhalen. Als de gegevens daadwerkelijk zijn ingevoegd en je ze opnieuw invoegt, is er deduplicatie van de blokken. Dit is nodig om duplicaten te voorkomen.
Het is ook belangrijk hoe dit werkt voor gematerialiseerde weergaven. Als de gegevens zijn gededupliceerd bij het invoegen in de hoofdtafel, zullen ze ook niet naar de gematerialiseerde weergave gaan.
Laten we nu het probleem bespreken. U heeft een complexere situatie, omdat u duplicaten van specifieke regels vastlegt. Dat wil zeggen, niet een hele batch is gedupliceerd, maar specifieke regels, en ze worden in de achtergrond samengevoegd. Inderdaad, de gegevens zullen samengevoegd worden in de hoofdtafel, terwijl de niet-samengevoegde gegevens naar de materialized view gaan, en bij merges gebeurt er niets met de materialized views. Want een materialized view is niets minder dan een trigger op insert. Bij andere bewerkingen gebeurt er verder niets mee.
En hierin kan ik u helaas niet verheugen. We moeten alleen naar een specifieke oplossing voor deze situatie zoeken. Bijvoorbeeld, is het mogelijk om ook een replacement in de materialized view te maken, en misschien werkt de methode voor deduplicatie ook zo. Maar helaas, niet altijd. Als het aggregatief is, zal het niet lukken.
Kirill Shvakov: Wij hadden ook onze eigen uitdagingen indertijd. Er was een probleem dat we advertenties tonen, en er zijn bepaalde gegevens die we in real-time kunnen tonen ā dat zijn gewoon de impressies. Deze worden zelden gedupliceerd, maar als dat gebeurt, voegen we ze uiteindelijk toch samen. En er waren dingen die niet gedupliceerd mochten worden ā klikken en al die verhalen. Maar het was ook wenselijk om ze praktisch direct te tonen.
Hoe werden de materialized views gemaakt? Er waren views waarin direct geschreven werd ā er gaat een Š·Š°ŠæŠøŃŃ naar de ruwe gegevens, en er wordt geschreven naar de views. Op een gegeven moment zijn de gegevens daar niet erg correct, ze worden gedupliceerd enzovoort. En er is een tweede deel van de tabel, waar ze er precies zo uitzien als de materialized views, dat wil zeggen dat ze qua structuur absoluut identiek zijn. Op een bepaald moment tellen we de gegevens opnieuw, tellen we de gegevens zonder duplicaten, en schrijven we naar die tabellen.
We gingen via de API ā handmatig zal dit niet werken in ClickHouse. En de API kijkt: wanneer ik een datum heb van de laatste toevoeging in de tabel, waar gegarandeerd al correcte gegevens zijn geteld, en hij doet een query naar de ene tabel en naar de andere tabel. Uit de ene haalt hij gegevens tot een bepaalde tijd, en uit de andere voegt hij aan wat nog niet is geteld. En dat werkt, maar niet met de middelen van Ć©Ć©n ClickHouse.
Als je een API hebt - voor analisten, voor gebruikers - dan is dat in principe een optie. Je houdt altijd bij, je rekent altijd opnieuw. Dit kan dagelijks of op een ander moment gedaan worden. Je kiest zelf het bereik dat je niet nodig hebt en dat niet kritisch is.
ClickHouse heeft veel logs. Hoe kan ik alles zien wat er op het moment met de server gebeurt?
ClickHouse heeft een zeer groot aantal verschillende logs, en dat aantal neemt toe. In nieuwe versies zijn sommige van deze logs zelfs standaard ingeschakeld, terwijl je in oude versies ze moet inschakelen bij de upgrade. Desondanks worden het er steeds meer. Ik zou graag willen zien wat er momenteel met mijn server gebeurt, misschien op een samenvattend dashboard.
Hebben jullie in het ClickHouse-team, of in de teams van jullie vrienden, iemand die functionaliteit biedt voor kant-en-klare dashboards die deze logs weergeven als een al gemaakt product? Uiteindelijk is het leuk om logs in ClickHouse te bekijken, maar het zou geweldig zijn als dit al in de vorm van een dashboard was voorbereid. Ik zou daar echt van genieten.
Er zijn dashboards, maar ze zijn niet gestandaardiseerd. In ons bedrijf gebruiken ongeveer 60 teams ClickHouse, en het vreemde is dat veel van hen dashboards hebben gemaakt die net iets anders zijn. Sommige teams gebruiken een interne installatie van āYandex.Cloudā. Daar zijn enkele kant-en-klare rapporten, hoewel niet alle noodzakelijke. Anderen hebben hun eigen.
Mijn collega's van 'Metrics' hebben hun eigen dashboard in Grafana, en ik heb mijn eigen op hun cluster. Ik kijk daar naar zaken zoals cache hits voor de cache van steekproeven. En nog ingewikkelder is dat we verschillende tools gebruiken. Mijn dashboard heb ik gemaakt met een heel oude tool, die Graphite-web heet. Het is absoluut lelijk. En ik gebruik het nog steeds, hoewel Grafana waarschijnlijk handiger en mooier zou zijn.
De basiscomponent van dashboards is hetzelfde. Dit zijn de systeemmetrieke voor de cluster: CPU, geheugen, schijf, netwerk. Andere zijn het aantal gelijktijdige verzoeken, het aantal gelijktijdige merges, het aantal verzoeken per seconde, het maximale aantal fragmenten voor de MergeTree-tabelpartities, de replicatielatentie, de grootte van de replicatieregel, het aantal ingevoegde rijen per seconde, het aantal ingevoegde blokken per seconde. Dit is alles wat niet uit logs komt, maar uit metrieke gegevens.
Vladimir Kolobaev: Alexey, ik zou graag een kleine correctie willen maken. Er is Grafana. Grafana heeft een datasource, namelijk ClickHouse. Dit betekent dat ik vanuit Grafana direct verzoeken naar ClickHouse kan doen. In ClickHouse is er een tabel met logs, deze is bij iedereen hetzelfde. Ik wil in Grafana naar deze logtabel verwijzen en die verzoeken zien die mijn server doet. Het zou geweldig zijn om zo'n dashboard te hebben.
Ik heb het zelf in elkaar gezet. Maar ik heb een vraag: als alles gestandaardiseerd is en Grafana door iedereen wordt gebruikt, waarom is er dan geen officieel dashboard bij 'Yandex'?
Kirill Shvakov: Eigenlijk wordt de datasource die naar ClickHouse gaat nu ondersteund door Altinity. En ik wil gewoon een richting aangeven waar je moet zoeken en wie je moet benaderen. Je kunt het hen vragen, want 'Yandex' maakt tenslotte ClickHouse, en niet alleen de geschiedenis eromheen. Altinity is het belangrijkste bedrijf dat ClickHouse momenteel promoot. Ze zullen het niet in de steek laten, maar blijven ondersteunen. Want in principe, om een dashboard op de Grafana-site te uploaden, hoef je alleen maar je te registreren en het te uploaden - er zijn geen bijzondere problemen.
Alexey Milovidov: In het afgelopen jaar zijn er veel mogelijkheden toegevoegd voor het profilereren van verzoeken in ClickHouse. Er zijn metrieke gegevens voor elk verzoek over het gebruik van middelen. Onlangs is er een nog meer laagdrempelige profiler voor verzoeken toegevoegd, zodat je kunt zien waar een verzoek elke milliseconde doorbrengt. Maar om van deze functionaliteit gebruik te maken, moet ik de consoleclient openen en het verzoek typen dat ik constant vergeet. Ik heb het ergens opgeslagen en vergeet constant waar precies.
Ik zou willen dat er een tool is waarin simpelweg staat: dit zijn je zware queries, gegroepeerd op klassen van queries. Als ik op een van hen klik, zou ik te horen krijgen dat hij zwaar is om die reden. Op dit moment is er geen oplossing. Het is echt vreemd dat wanneer mensen mij vragen: "Zijn er kant-en-klare dashboards voor Grafana?", ik zeg: "Ga naar de grafana-website, daar is de community 'Dashboards', en daar is een dashboard van Dima, een dashboard van Kostiantyn. Wat dat is, weet ik niet, ik heb zelf niet gebruikt."
Hoe invloed uit te oefenen op merges, zodat de server niet crasht in OOM?
Ik heb een tabel, in de tabel is er maar Ć©Ć©n partitie, het is een ReplacingMergeTree. Ik schrijf gegevens in gedurende vier jaar. Ik moest een alter in deze uitvoeren en enkele gegevens verwijderen.
Ik deed dit, en tijdens het verwerken van deze aanvraag werd al het geheugen op alle servers van de cluster gebruikt, en alle servers van de cluster gingen samen in OOM. Daarna kwamen ze allemaal weer op, begonnen deze zelfde operatie, deze data-blok te mergen, en vielen opnieuw in OOM. Toen kwamen ze opnieuw op en vielen weer. En deze situatie stopte niet.
Later bleek dat dit eigenlijk een bug was, die de jongens hebben opgelost. Dat is geweldig, heel erg bedankt. Maar de nasmaak blijft. En nu, als ik denk aan het maken van een merge in de tabel, heb ik de vraag - waarom kan ik daar op een of andere manier invloed op uitoefenen? Bijvoorbeeld, kan ik ze beperken in de hoeveelheid benodigde RAM, of in principe in hun aantal dat specifiek deze tabel zal verwerken.
Ik heb een tabel genaamd "Metrics", verwerk deze alsjeblieft in twee threads. Laat niet tien of vijf merges gelijktijdig ontstaan, doe het in twee. Ik denk dat twee genoeg geheugen voor mij hebben, en voor tien verwerken misschien niet genoeg is. Waarom blijft de angst bestaan? Omdat de tabel groeit, en op een dag zal ik in een situatie komen dat het in principe niet door een bug is, maar omdat de gegevens in zo'n grote hoeveelheid zullen veranderen, dat ik gewoon niet genoeg geheugen op de server heb. En dan zal de server in OOM vallen tijdens de merge. Welnu, de mutatie kan ik annuleren, maar de merges kunnen dat niet.
Je weet, bij merges zal de server niet in OOM (Out Of Memory) vallen, omdat er bij het mergen slechts een klein bereik aan gegevens in het geheugen wordt gebruikt. Dus het komt goed, ongeacht de hoeveelheid gegevens.
Vladimir Kolobaev: Goed. Er is echter Ć©Ć©n punt dat ik wil maken: nadat we de bugfix hadden uitgevoerd, heb ik de nieuwe versie gedownload en op een andere, kleinere tabel met veel partitities heb ik een soortgelijke bewerking gedaan. En tijdens de merge op de server is ongeveer 100 GB aan RAM verbruikt. Ik had 150 GB in gebruik, 100 GB werd verbruikt, en ik had nog 50 GB over, dus ik viel niet in OOM.
Wat beschermt me momenteel tegen het vallen in OOM, als het echt 100 GB aan RAM verbruikt? Wat moet ik doen als de RAM tijdens de merges opraakt?
Alexey Milovidov: Er is een probleem, want het gebruik van RAM tijdens merges is niet beperkt. En er is een ander probleem: als er een merge is ingepland, moet deze worden uitgevoerd omdat deze is vastgelegd in het replicatielog. Het replicatielog zijn de acties die nodig zijn om de replica in een consistente staat te brengen. Als je geen handmatige manipulaties uitvoert die het replicatielog terugdraait, moet de merge hoe dan ook worden uitgevoerd.
Het zou uiteraard niet verkeerd zijn om een beperking op het RAM in te voeren die "voor alle zekerheid" specifiek tegen OOM beschermt. Het zal de merge niet helpen om uit te voeren; deze zal opnieuw beginnen, een bepaalde drempel bereiken, een uitzondering werpen en dan weer opnieuw beginnen - daar komt niets goeds uit voort. Maar in principe zou het nuttig zijn om deze beperking in te voeren.
Hoe zal de ontwikkeling van de Golang-driver voor ClickHouse plaatsvinden?
De Golang-driver, geschreven door Kirill Shvakov, wordt nu officieel ondersteund door het ClickHouse-team. Hij en hij is nu groot en echt.
Een kleine opmerking. Er is een geweldige en door iedereen geliefde opslag van normale vormen van oneindige orde ā dat is Vertica. Zij hebben ook hun eigen officiĆ«le Python-driver, die wordt ondersteund door de ontwikkelaars van Vertica. En het is een paar keer voorgekomen dat de versies van de opslag en de versies van de driver behoorlijk uit elkaar gingen, waardoor de driver op een gegeven moment niet meer werkte. En een tweede punt. De ondersteuning van deze officiĆ«le driver lijkt door het systeem ānippelā te worden gedaan ā je schrijft hen een issue, en het hangt eeuwig.
Ik heb twee vragen. Momenteel is de Golang-driver van Kirill de bijna standaard manier om uit Golang met ClickHouse te communiceren. Behalve dat iemand misschien nog steeds via de http-interface communiceert, omdat hij dat leuk vindt. Hoe zal de ontwikkeling van deze driver plaatsvinden? Zal het worden gesynchroniseerd met enige breaking changes in de opslag zelf? En wat is de procedure voor het behandelen van issues?
Kirill Shvakov: Eerste punt ā hoe alles bureaucratisch is geregeld. Dit punt is niet besproken, dus ik heb daar geen antwoord op.
Om de vraag over issues te beantwoorden, is een klein verhaal over de driver nodig. Ik werkte voor een bedrijf met veel gegevens. Het was een advertentierotator met een enorme hoeveelheid gebeurtenissen die ergens opgeslagen moesten worden. En op een gegeven moment verscheen ClickHouse. We hebben daar gegevens in geladen, en de eerste tijd ging alles goed, maar toen viel ClickHouse uit. Op dat moment besloten we dat we het niet nodig hadden.
Een jaar later keerden we terug naar het idee om ClickHouse te gebruiken, en we moesten op de een of andere manier gegevens schrijven. De uitgangssituatie was zo ā de hardware was erg zwak, er waren weinig middelen. Maar we werkten altijd zo, dus keken we naar de native protocoloptie.
Aangezien we op Go werkten, was het duidelijk dat er een driver voor Go nodig was. Ik heb dit vrijwel fulltime gedaan ā het was mijn werptaak. Tot op een gegeven moment hebben we het afgemaakt, en in principe verwachtte niemand dat iemand anders het zou gebruiken. Toen kwam CloudFlare met precies hetzelfde probleem, en een tijdje werkten we heel goed samen, omdat zij dezelfde taken hadden. We deden dit zowel in ClickHouse zelf, als in de driver.
Op een bepaald moment ben ik gewoon gestopt met het bezig zijn, omdat mijn betrokkenheid bij ClickHouse en mijn werk een beetje veranderd zijn. Daarom worden er geen issues gesloten. Periodiek worden er commits in de repository gedaan door mensen die zelf iets nodig hebben. Dan kijk ik naar de pull request en soms pas ik zelfs iets aan, maar dat gebeurt zelden.
Ik wil graag terugkeren naar de driver. Enkele jaren geleden, toen dit allemaal begon, was ClickHouse ook anders en had het andere mogelijkheden. Nu is er een beter begrip van hoe de driver te herzien zodat deze goed werkt. Als dit gebeurt, zal versie 2 in ieder geval niet compatibel zijn vanwege de verzamelde workaround.
Hoe we dit moeten organiseren, weet ik niet. Ik heb zelf ook niet zoveel tijd. Als er mensen zijn die de driver verder willen ontwikkelen, kan ik hen helpen en vertellen wat te doen. Maar de actieve deelname van 'Yandex' aan de ontwikkeling van het project is tot nu toe nog niet besproken.
Alexey Milovidov: Eigenlijk is er tot nu toe geen bureaucratie rond deze drivers. Het enige is dat ze zijn ondergebracht in een officiƫle organisatie, wat betekent dat deze driver erkend is als de standaardoplossing voor Go. Er zijn andere drivers, maar deze zijn apart.
Intern hebben we geen ontwikkeling voor deze drivers. De vraag is of we een aparte persoon kunnen aannemen, niet specifiek voor deze driver, maar voor de ontwikkeling van alle community-drivers, of dat we iemand van buitenaf kunnen vinden.
De externe woordenlijst wordt niet geladen na een herstart met de instelling lazy_load ingeschakeld. Wat te doen?
Wij hebben de instelling lazy_load ingeschakeld, en na het herstarten van de server wordt de woordenlijst niet automatisch geladen. Deze wordt alleen geladen als de gebruiker deze woordenlijst aanspreekt. En bij het eerste verzoek geeft het een foutmelding. Is het mogelijk om op een automatische manier met ClickHouse woordenlijsten te laden, of moeten we zelf altijd hun gereedheid controleren, zodat gebruikers geen fouten krijgen?
Het is mogelijk dat we een oude versie van ClickHouse hebben, waardoor de woordenlijst niet automatisch werd geladen. Zou dat kunnen?
Ten eerste kunnen woordenlijsten geforceerd worden geladen met behulp van de query system reload dictionaries. Ten tweede, over de fout: als de woordenlijst al is geladen, zullen de verzoeken werken met de gegevens die zijn geladen. Als de woordenlijst nog niet is geladen, zal deze tijdens het verzoek worden geladen.
Voor zware woordenboeken is dit niet erg handig. Bijvoorbeeld, je moet miljoen regels uit MySQL ophalen. Iemand doet een eenvoudige select, maar die select zal wachten op die miljoen regels. Hier zijn twee oplossingen. De eerste is lazy_load uit te schakelen. De tweede is, wanneer de server opstart, voordat je belasting aan het systeem toevoegt, te doen system reload dictionary of gewoon een query uitvoeren die het woordenboek gebruikt. Dan zal het woordenboek worden geladen. Je moet zelf de beschikbaarheid van de woordenboeken controleren met de instelling lazy_load ingeschakeld, want automaat trekt ClickHouse ze niet aan.
Het antwoord op de laatste vraag is: of de versie is oud, of het moet worden gedebugd.
Hoe omgaan met het feit dat system reload dictionaries geen van de vele woordenlijsten laadt als er ook maar Ć©Ć©n daarvan met een fout faalt?
Er is ook een vraag over system reload dictionaries. We hebben twee woordenboeken: eentje laadt niet, de andere laadt wel. System reload dictionaries laadt in dit geval geen enkel woordenboek, en je moet specifiek het juiste woordenboek laden met behulp van system reload dictionary. Is dit ook gerelateerd aan de ClickHouse versie?
Ik wil je geruststellen. Dit gedrag is veranderd. Dus als je ClickHouse bijwerkt, zal het ook veranderen. Als je niet tevreden bent met het huidige gedrag system reload dictionaries, werk dan bij en laten we hopen dat het naar de betere kant verandert.
Is er een manier om vereisten in de ClickHouse-configuratie te configureren, maar deze niet zichtbaar te maken bij fouten?
De volgende vraag betreft de fouten die verband houden met het woordenboek, namelijk de referenties. We hebben de verbindingsreferenties in de configuratie van ClickHouse naar het woordenboek geschreven, en bij een fout krijgen we deze referenties en het wachtwoord in de respons.
We hebben deze fout opgelost door de referenties in de ODBC-driverconfiguratie te plaatsen. Is er een manier om de referenties in de ClickHouse-configuratie te configureren zonder deze referenties zichtbaar te maken bij fouten?
Hier is de oplossing inderdaad om deze credentials in odbc.ini aan te geven, en in ClickHouse zelf alleen de ODBC Data Source Name op te geven. Voor andere woordenboekbronnen zal dit niet het geval zijn: je mag geen wachtwoord zien bij een foutmelding voor het woordenboek met MySQL of andere. Voor ODBC kijk ik ook ā als dit er is, moet het gewoon verwijderd worden.
Bonus: achtergronden voor Zoom van de bijeenkomsten
Bij het klikken op de afbeelding openen zich bonus achtergronden voor de meest volhardende lezers. We blussen het vuur samen met de mascottes van Avito-technologieƫn, overleggen met collega's uit de systeembeheerderskamer of de old-school computerclub en houden dagelijkse meetings onder de brug tegen een graffiti-achtergrond.
Bron: habr.com
