{"id":80775,"date":"2020-05-08T13:42:47","date_gmt":"2020-05-08T11:42:47","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/clickhouse-dlya-prodvinutyh-polzovatelej-v-voprosah-i-otvetah"},"modified":"2020-05-08T13:42:47","modified_gmt":"2020-05-08T11:42:47","slug":"clickhouse-dlya-prodvinutyh-polzovatelej-v-voprosah-i-otvetah","status":"publish","type":"post","link":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/clickhouse-dlya-prodvinutyh-polzovatelej-v-voprosah-i-otvetah","title":{"rendered":"ClickHouse voor gevorderde gebruikers in vragen en antwoorden","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>In april kwamen de ingenieurs van Avito samen voor online bijeenkomsten met hoofdontwikkelaar van ClickHouse, Alexey Milovidov, en Kirill Shvakov, een Golang-ontwikkelaar van het bedrijf Integros. Ze bespraken hoe ze het databasesysteem gebruiken en welke problemen ze tegenkomen. <\/p>\n<p><\/p>\n<p>Op basis van de bijeenkomst hebben we een artikel samengesteld met antwoorden van experts op onze en kijkersvragen over back-ups, hersharding van gegevens, externe woordenboeken, de Golang-driver en versie-updates van ClickHouse. Het kan nuttig zijn voor ontwikkelaars die al actief werken met de database van \u2018Yandex\u2019 en ge\u00efnteresseerd zijn in het heden en de toekomst ervan. In principe zijn de antwoorden van Alexey Milovidov, tenzij anders vermeld. <\/p>\n<p><\/p>\n<p>Let op, onder de cut is veel tekst. We hopen dat de inhoud met vragen je helpt om je te ori\u00ebnteren.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"ClickHouse voor gevorderde gebruikers in vragen en antwoorden\" src=\"\/wp-content\/uploads\/2020\/05\/242b1d8d002fe115614435c242297fd2.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2 id=\"soderzhanie\">Inhoud<\/h2>\n<p><\/p>\n<ul>\n<li><noindex><a rel=\"nofollow\" href=\"#old-data\">ClickHouse wordt voortdurend ge\u00fcpdatet, maar onze data niet. Wat moeten we hiermee doen?<\/a><\/noindex> <\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#backup-best-practicies\">Wat zijn momenteel de beste praktijken voor het maken van back-ups van gegevens uit ClickHouse?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#replication\">Is het mogelijk om een gecontroleerde vertraging van replica's in de clusters te organiseren?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#soooo-changeable\">Wat te doen als de tabelstructuur is veranderd?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#resharding-best-practices\">Wat zijn momenteel de beste praktijken voor hersharding van gegevens?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#clickhouse-copier\">ClickHouse heeft een tool genaamd clickhouse-copier. Kun je daar meer over vertellen?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#resharding-tool\">Je had een pilotproject dat hersharding heette. Wat is daarmee gebeurd?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#move-to-slow-disk\">Is het mogelijk om alle delen van gegevens samen te voegen voordat ze naar langzame schijven worden verplaatst?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#up-to-date\">Hoe verhuis je naar nieuwe versies van ClickHouse als je de compatibiliteit niet van tevoren kunt controleren?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#kill-query\">Kill query zou zoekopdrachten moeten be\u00ebindigen, maar dat doet het niet. Waarom niet?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#reading-time\">Hoe bereken je de responstijd bij leesbelasting?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#pimp-my-clickhouse\">Wat moet je tunen in ClickHouse zodat er meer gegevens in de cache komen?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#storage-configuration\">Hoe kan ik storage_configuration instellen voor opslag in het RAM?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#low-cardinality\">Tot hoeveel unieke waarden is Low Cardinality effectief?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#fulltext-search\">Wat zijn de beste praktijken voor full-text zoekopdrachten op een tabel met vijf miljard rijen?<\/a><\/noindex> <\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#hello-and-welcome\">Hoe organiseer je het beste de toegang tot ClickHouse voor een groot aantal gebruikers?<\/a><\/noindex> <\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#smorgasbord\">Is het mogelijk om de resultaten van \u00e9\u00e9n query aan tien klanten te geven?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#asynchronous\">Hoe ga je om met asynchrone bewerkingen en materi\u00eble weergaven?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#dashboard\">In ClickHouse zijn er veel logs. Hoe kan ik alles zien wat er op dat moment met de server gebeurt?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#zen\">Hoe be\u00efnvloed je de merges zodat de server niet crasht door OOM?<\/a><\/noindex> <\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#go\">Hoe zal de ontwikkeling van de Golang-driver voor ClickHouse plaatsvinden?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#lazy-load\">Het externe woordenboek wordt niet geladen na een herstart met de instelling lazy_load ingeschakeld. Wat moet je doen?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#reload-dictionaries\">Hoe om te gaan met het feit dat system reload dictionaries geen van de vele woordenboeken laadt als er ten minste \u00e9\u00e9n met een fout faalt?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#connection\">Is there a way to configure the credentials in the ClickHouse config without exposing them in case of errors?<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"#zoom-backgrounds\">Bonus: backgrounds for Zoom from meetings<\/a><\/noindex><\/li>\n<\/ul>\n<p><\/p>\n<blockquote><p>Als je geen tekst wilt lezen, kun je de opname van de bijeenkomsten bekijken <noindex><a rel=\"nofollow\" href=\"https:\/\/www.youtube.com\/watch?v=n1tm4j4W8ZQ&amp;t=8147s\">op ons YouTube-kanaal<\/a><\/noindex>. Timestamps are in the first comment below the video.<\/p><\/blockquote>\n<p><\/p>\n<h2 id=\"anchorold-dataanchorclickhouse-postoyanno-obnovlyaetsya-a-nashi-dannyenbsp-net-chto-snbspetim-delat\"><noindex><a rel=\"nofollow\" name=\"old-data\"><\/a><\/noindex>ClickHouse is constantly updating, but our data is not. What should we do about it?<\/h2>\n<p><\/p>\n<blockquote><p>ClickHouse is constantly updating, but our data that has been optimized final is not updating and is kept in backup. <\/p>\n<p>Suppose we have encountered some problem and data was lost. We decided to restore, and it turns out that the old partitions stored on backup servers diverge significantly from the currently used version of ClickHouse. What should be done in this situation, and is it possible?<\/p><\/blockquote>\n<p>The situation where you restored data from a backup in an old format, and they do not connect in the new version, is impossible. We ensure that the data format in ClickHouse always remains backward compatible. This is much more important than backward compatibility in functionality if the behavior of some rarely used function changes. Data stored on disk should always be readable by the new version of ClickHouse. This is the rule. <\/p>\n<p><\/p>\n<h2 id=\"anchorbackup-best-practiciesanchorkakie-luchshie-praktiki-est-nanbspdannyy-moment-ponbsprezervnomu-kopirovaniyu-dannyh-iznbspclickhouse\"><noindex><a rel=\"nofollow\" name=\"backup-best-practicies\"><\/a><\/noindex>Wat zijn momenteel de beste praktijken voor het maken van back-ups van gegevens uit ClickHouse?<\/h2>\n<p><\/p>\n<blockquote><p>How to make backups considering that we have optimize final operations, a huge database in terabytes, and data that is updated over the last three days, and after that no procedures occur with them? <\/p>\n<p>We can cobble together our own solution and write in Bash: gather these backups like this and that. Perhaps we don\u2019t need to cobble anything, and the bicycle was invented a long time ago? <\/p><\/blockquote>\n<p>First of all, regarding best practices. My colleagues always advise in response to backup questions to remind about the Yandex.Cloud service, where this task has already been solved. So use it if possible. <\/p>\n<p><\/p>\n<p>There is no complete solution, a hundred percent integrated into ClickHouse, for backups. There are some templates that can be used. To get a complete solution, you will have to either tinker a bit manually or create wrappers in the form of scripts.<\/p>\n<p><\/p>\n<p>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 ingewikkelder de oplossing wordt.<\/p>\n<p><\/p>\n<p>Als de tabel met gegevens slechts enkele gigabytes groot is, kunt u de back-up als volgt maken: <\/p>\n<p><\/p>\n<ol>\n<li>Bewaar de definitie van de tabellen, dat wil zeggen metadata \u2014 <strong>show create table<\/strong>.<\/li>\n<li>Maak een dump met de ClickHouse-client \u2014 <strong>select<\/strong> * <strong>from table<\/strong> in een bestand. Standaard krijgt u een bestand in TabSeparated-formaat. Als u effici\u00ebnter wilt zijn, kunt u het in Native-formaat doen. <\/li>\n<\/ol>\n<p><\/p>\n<p>Als de hoeveelheid data groter is, kost de back-up meer tijd en neemt deze veel meer ruimte in. Dit wordt een logische back-up genoemd, die niet aan het ClickHouse-datatype is gebonden. Als het bestaat, kunt u in het uiterste geval een back-up nemen en deze in MySQL laden voor herstel. <\/p>\n<p><\/p>\n<p>Voor meer geavanceerde gevallen heeft ClickHouse de mogelijkheid ingebouwd om een snapshot van partities in het lokale bestandssysteem te maken. Deze mogelijkheid is beschikbaar in de vorm van een query. <strong>alter table freeze partition<\/strong>. Of gewoon <strong>alter table freeze<\/strong> \u2014 dit is een snapshot van de hele tabel. <\/p>\n<p><\/p>\n<p>Het snapshot wordt consistent aangemaakt voor \u00e9\u00e9n tabel op \u00e9\u00e9n shard, dat wil zeggen dat het niet mogelijk is om op deze manier een consistent snapshot van het hele cluster te maken. Maar voor de meeste taken is deze noodzaak er niet, en is het voldoende om op elke shard de query uit te voeren en een consistent snapshot te verkrijgen. Het wordt gemaakt in de vorm van harde links en neemt daarom geen extra ruimte in beslag. Vervolgens kopieert u dit snapshot naar de back-upserver of naar de opslag die u gebruikt voor back-ups.<\/p>\n<p><\/p>\n<p>Het herstellen van een dergelijke back-up is vrij eenvoudig. Eerst maakt u de tabellen aan volgens de beschikbare definitie van de tabellen. Vervolgens kopieert u de opgeslagen snapshots van de partities naar Directory-Detached voor de gegevens tabellen en voert u de query uit. <strong>attach partition<\/strong>. Deze oplossing is prima geschikt voor de meest serieuze datahoeveelheden. <\/p>\n<p><\/p>\n<p>Soms is er iets nog indrukwekkenders nodig \u2014 in gevallen waarin u tientallen of zelfs honderden terabytes op elke server en honderden servers heeft. Hier is er een oplossing die ik heb afgekeken van mijn collega's van \u2018Yandex.Metrica\u2019. Ik zou het niet voor iedereen aanbevelen \u2014 lees het en beslis zelf of het geschikt is of niet. <\/p>\n<p><\/p>\n<p>Eerst moeten we enkele servers met grote schappen maken. Vervolgens moeten we op deze servers verschillende ClickHouse-servers opzetten en configureren zodat ze als een extra replica voor dezelfde shards functioneren. Daarna kunnen we op deze servers een bestandssysteem of een tool gebruiken die snapshots aanmaakt. Hier zijn twee opties. De eerste optie zijn LVM-snapshots, de tweede optie is ZFS op Linux. <\/p>\n<p><\/p>\n<p>Daarna moet je elke dag een snapshot maken, deze zal opslagruimte innemen. Natuurlijk, als de gegevens veranderen, zal de hoeveelheid ruimte in de loop van de tijd toenemen. Dit snapshot kan op elk moment worden teruggehaald om de gegevens te herstellen, zo'n vreemde oplossing. Bovendien moet je deze replicas in de configuratie beperken, zodat ze niet proberen leiders te worden.<\/p>\n<p><\/p>\n<h2 id=\"anchorreplicationanchormozhno-li-budet-organizovat-kontroliruemoe-otstavanie-replik-vnbspvalah\"><noindex><a rel=\"nofollow\" name=\"replication\"><\/a><\/noindex>Is het mogelijk om een gecontroleerde vertraging van replica's in de clusters te organiseren?<\/h2>\n<p><\/p>\n<blockquote><p>Dit jaar ben je van plan om walvissen in ClickHouse te maken. Zal het mogelijk zijn om gecontroleerde achterstand van replicas te organiseren? We willen ons hiermee beschermen tegen negatieve scenario's met alternatieven en andere wijzigingen. <\/p>\n<p>Is het mogelijk om roll backs voor alternatieven te maken? Bijvoorbeeld, in de bestaande walvis zeggen dat tot dat moment wijzigingen van toepassing zijn, en vanaf dat moment stop je met het toepassen van wijzigingen?<\/p>\n<p>Als een team onze cluster komt binnenvallen en deze stuk maakt, hebben we een soort replica met een uur achterstand, waar we kunnen zeggen dat we deze op dit moment willen gebruiken, maar de laatste tien minuten van wijzigingen in deze replica niet willen toepassen? <\/p><\/blockquote>\n<p>Laten we beginnen met de gecontroleerde achterstand van replicas. Zo'n verzoek kwam van gebruikers, en we hebben een issue op GitHub aangemaakt met het verzoek: 'Als iemand dit nodig heeft, geef een duim omhoog, geef een hartje'. Nobody has liked it, so the issue was closed. Desondanks is het al mogelijk om deze functie te krijgen door ClickHouse te configureren, maar alleen vanaf versie 20.3.<\/p>\n<p><\/p>\n<p>ClickHouse voert voortdurend een gegevensmerge op de achtergrond uit. Wanneer de merge is uitgevoerd, wordt een bepaalde set datablokken vervangen door een grotere blok. Tegelijkertijd blijven de eerdere datablokjes nog enige tijd op de schijf staan.<\/p>\n<p><\/p>\n<p>Ten eerste blijven ze bestaan totdat er select-opvragen zijn die ze gebruiken om een niet-blokkerende werking te garanderen. Select-opvragen kunnen rustig lezen uit oude stukken.<\/p>\n<p><\/p>\n<p>Ten tweede is er ook een tijdslimiet \u2014 oude datablokken blijven acht minuten op de schijf staan. Deze acht minuten zijn instelbaar en kunnen zelfs \u00e9\u00e9n dag worden. Dit kost schijfruimte: afhankelijk van de datastroom kan het zo zijn dat de gegevens in de afgelopen dag niet alleen verdubbelen, maar zelfs vijf keer zoveel worden. Maar bij een serieus probleem kun je de ClickHouse-server stoppen en alles in orde maken.<\/p>\n<p><\/p>\n<p>Nu rijst de vraag hoe dit beschermt tegen alternatieven. Hier moet je dieper kijken, want in oude versies van ClickHouse werkte de alter-bewerking zo dat deze gewoon de blokken wijzigde. Er is een blok gegevens met bepaalde bestanden, en we doen bijvoorbeeld, <strong>alter drop column<\/strong>. Op dat moment wordt deze kolom fysiek verwijderd uit alle blokken.<\/p>\n<p><\/p>\n<p>Maar vanaf versie 20.3 is het mechanisme voor alters volledig veranderd en nu zijn datablokken altijd immutabel. Ze veranderen helemaal niet \u2014 alters werken nu ongeveer zoals merges. In plaats van een blok ter plaatse te wijzigen, cre\u00ebren we een nieuw blok. In het nieuwe blok worden de bestanden die niet zijn veranderd hardlinks, en als we een kolom hebben verwijderd, zal deze gewoon ontbreken in het nieuwe blok. Het oude blok wordt standaard na acht minuten verwijderd, en hier kunnen we de instellingen aanpassen die hierboven zijn beschreven. <\/p>\n<p><\/p>\n<p>Hetzelfde geldt voor alters van het type mutaties. Wanneer je <strong>alter delete<\/strong> of <strong>alter update<\/strong>, wijzigt het geen fragment, maar cre\u00ebert het een nieuw fragment. En dan verwijdert het het oude fragment.<\/p>\n<p><\/p>\n<h2 id=\"anchorsoooo-changeableanchorkak-byt-esli-struktura-tablicy-pomenyalas\"><noindex><a rel=\"nofollow\" name=\"soooo-changeable\"><\/a><\/noindex>Wat te doen als de tabelstructuur is veranderd?<\/h2>\n<p><\/p>\n<blockquote><p>Hoe kun je een backup terugzetten die is gemaakt met de oude structuur? En de tweede vraag betreft de case met snapshots en bestandssystemen. Is Btrfs geschikt in plaats van ZFS op Linux LVM?<\/p><\/blockquote>\n<p>Als je <strong>attach partition<\/strong> partities met een andere structuur, dan zal ClickHouse je vertellen dat dit niet mogelijk is. De oplossing is als volgt. Ten eerste \u2014 cre\u00eber een tijdelijk MergeTree-tabblad met de oude structuur, koppel daar de gegevens aan met attach, en voer een alter-query uit. Vervolgens kun je deze gegevens ofwel kopi\u00ebren of verplaatsen en opnieuw attachen, of de query gebruiken. <strong>alter table move partition<\/strong>.<\/p>\n<p><\/p>\n<p>Laten we beginnen met de tweede vraag \u2014 kan Btrfs worden gebruikt? Als je LVM hebt, zijn LVM-snapshots voldoende en kan het bestandssysteem ext4 zijn, dat maakt niet uit. Wat Btrfs betreft, dat hangt af van je ervaring met het gebruik ervan. Het is een volwassen bestandssysteem, maar er zijn nog steeds enige twijfels over hoe het in de praktijk zal presteren onder specifieke scenario's. Ik zou het niet aanraden als je geen ervaring met Btrfs in productie hebt.<\/p>\n<p><\/p>\n<h2 id=\"anchorresharding-best-practicesanchorkakie-seychas-luchshie-praktiki-vnbspreshardinge-dannyh\"><noindex><a rel=\"nofollow\" name=\"resharding-best-practices\"><\/a><\/noindex>Wat zijn momenteel de beste praktijken voor hersharding van gegevens?<\/h2>\n<p><\/p>\n<p>De vraag over her-sharding is complex en veelzijdig. Je kunt dit op verschillende manieren beantwoorden. Je zou kunnen zeggen dat ClickHouse geen ingebouwde mogelijkheid voor her-sharding heeft. Ik ben bang dat dit antwoord niemand tevreden zal stellen. Daarom kun je ook van de andere kant benaderen en zeggen dat er veel manieren zijn om gegevens in ClickHouse te herschikken. <\/p>\n<p><\/p>\n<p>Als er geen ruimte meer is in de cluster of deze niet meer om kan gaan met de belasting, voeg je nieuwe servers toe. Maar deze servers zijn standaard leeg, er zijn geen gegevens op, er is geen belasting. Je moet de gegevens herschikken zodat ze gelijkmatig verspreid worden over de nieuwe, grotere cluster.<\/p>\n<p><\/p>\n<p>De eerste manier om dit te doen is door een deel van de partities naar de nieuwe servers te kopi\u00ebren met behulp van een query. <strong>alter table fetch partition<\/strong>Bijvoorbeeld, als je partities per maand had, neem je de eerste maand van 2017 en kopieert deze naar de nieuwe server, en daarna kopieer je de derde maand naar weer een andere nieuwe server. En zo ga je door totdat het meer of minder gelijkmatig is.<\/p>\n<p><\/p>\n<p>Verplaatsing kan alleen plaatsvinden voor die partities die niet veranderen tijdens het schrijven. Voor nieuwe partities moet het schrijven worden uitgeschakeld, omdat hun verplaatsing niet-atomair is. Anders krijg je duplicaten of hiaten in de gegevens. Desondanks is deze methode praktisch en werkt het behoorlijk effici\u00ebnt. Samengeperste partities worden al via het netwerk verzonden, wat betekent dat de gegevens niet opnieuw worden gecomprimeerd of gecodeerd.<\/p>\n<p><\/p>\n<p>Deze methode heeft \u00e9\u00e9n nadeel, en dat hangt af van het sharding-schema, of je dit sharding-schema hebt ingesteld en wat je sharding-sleutel was. In jouw voorbeeld voor het geval van metrics is de sharding-sleutel de hash van het pad. Wanneer je een select-query uitvoert op een Distributed-tabel, worden de gegevens onmiddellijk van alle shards in het cluster opgehaald. <\/p>\n<p><\/p>\n<p>Dit betekent dat het voor jou feitelijk niet uitmaakt welke gegevens er op welke shard terechtkomen. Het belangrijkste is dat de gegevens van \u00e9\u00e9n pad op \u00e9\u00e9n shard komen, maar welke dat is, doet er niet toe. In dit geval is het verplaatsen van bestaande partities perfect geschikt, omdat je bij select-queries ook \u2013 zowel v\u00f3\u00f3r als na het her-sharden \u2013 geen verschil in de structuur van waarden zult zien; je krijgt volledige gegevens.<\/p>\n<p><\/p>\n<p>Maar er zijn ook complexere gevallen. Als je in de logica van de applicatie uitgaat van een speciaal sharding-schema, waarbij deze klant op een bepaalde shard is geplaatst, kan de query direct daarheen worden gestuurd, in plaats van naar de Distributed-tabel. Of je gebruikt een relatief nieuwe versie van ClickHouse en hebt de instelling ingeschakeld. <strong>optimize skip unused shards<\/strong>In dat geval wordt tijdens de select-query de expressie in de where-sectie geanalyseerd en wordt berekend op welke shards er volgens het sharding-schema gegevens moeten worden opgehaald. Dit werkt alleen als de gegevens volgens dit sharding-schema zijn verdeeld. Als je ze handmatig hebt verplaatst, kan de overeenkomst veranderen.<\/p>\n<p><\/p>\n<p>Dus, dit is methode \u00e9\u00e9n. En ik wacht op je antwoord, of deze methode geschikt is of dat we verder gaan.<\/p>\n<p><\/p>\n<p><strong>Vladimir Kolobaev, lead system administrator bij Avito<\/strong>: Alexey, de methode die je noemde past niet heel goed als je de belasting, inclusief die van het lezen, wilt verspreiden. We kunnen een maandelijkse partitie nemen en de vorige maand naar een andere node verplaatsen, maar wanneer de aanvraag voor deze gegevens komt, zullen we alleen die node belasten. En we willen graag het hele cluster belasten, want anders zal een bepaalde tijd de volledige leesbelasting door slechts twee shards worden verwerkt.<\/p>\n<p><\/p>\n<p><strong>Alexey Milovidov:<\/strong> Het antwoord hier is vreemd \u2013 ja, slecht, maar het kan ook werken. Laat me uitleggen hoe precies. Het is belangrijk om naar het belastingscenario te kijken dat voor jouw gegevens geldt. Als het gegevens voor monitoring betreft, kan je bijna met zekerheid zeggen dat het overgrote deel van de aanvragen voor verse gegevens is. <\/p>\n<p><\/p>\n<p>U heeft nieuwe servers ge\u00efnstalleerd, oude partities verhuisd, maar ook de manier waarop verse gegevens worden vastgelegd veranderd. Deze verse gegevens zullen zich verspreiden over de hele cluster. Hierdoor zullen al na vijf minuten de aanvragen voor de afgelopen vijf minuten gelijkmatig de cluster belasten, en na een dag zullen de aanvragen voor de afgelopen dag de cluster gelijkmatig belasten. Helaas zullen de aanvragen voor de vorige maand slechts naar een deel van de servers in de cluster gaan.<\/p>\n<p><\/p>\n<p>Maar vaak zult u geen aanvragen voor de specifieke maand februari 2019 hebben. Waarschijnlijk, als de aanvragen in 2019 zijn, dan zullen ze voor het hele jaar 2019 zijn \u2014 voor een langere tijdsperiode, en niet voor een klein bereik. Dergelijke aanvragen zullen ook de cluster gelijkmatig belasten. Maar uw opmerking is absoluut juist dat dit een ad hoc oplossing is, die de gegevens niet volledig gelijkmatig verspreidt.<\/p>\n<p><\/p>\n<p>Ik heb nog een paar punten om te antwoorden op uw vraag. Een daarvan is hoe je aanvankelijk een sharding-schema kunt maken zodat het her-sharden minder pijnlijk is. Dit is niet altijd mogelijk.<\/p>\n<p><\/p>\n<p>Bijvoorbeeld, u heeft monitoringsgegevens. Monitoringsgegevens groeien om drie redenen. De eerste is de accumulatie van historische gegevens. De tweede is de toename van verkeer. En de derde is de groei van het aantal dingen die onder monitoring vallen. Er komen nieuwe microservices en meetwaarden bij die moeten worden opgeslagen. <\/p>\n<p><\/p>\n<p>Het is mogelijk dat de grootste groei verband houdt met de derde reden \u2014 de toename van het gebruik van monitoring. In dat geval is het belangrijk om naar het type belasting te kijken, wat de belangrijkste select-aanvragen zijn. De belangrijkste select-aanvragen zullen waarschijnlijk een subset van meetwaarden zijn.<\/p>\n<p><\/p>\n<p>Bijvoorbeeld, het CPU-gebruik van bepaalde servers door een bepaalde service. Het blijkt dat er een subset van sleutels is waarover u deze gegevens ophaalt. En de aanvraag voor deze gegevens is waarschijnlijk vrij eenvoudig en duurt tientallen milliseconden. Dit wordt gebruikt voor monitoringdiensten, voor dashboards. Ik hoop dat ik dit goed begrijp.<\/p>\n<p><\/p>\n<p><strong>Vladimir Kolobaev:<\/strong> Het is zo dat we zeer vaak verwijzen naar historische gegevens, omdat we in real time de huidige toestand vergelijken met het historische. Voor ons is het belangrijk om snel toegang te hebben tot een grote hoeveelheid gegevens, en ClickHouse biedt daar uitstekende ondersteuning voor.<\/p>\n<p><\/p>\n<p>U heeft absoluut gelijk, de meeste leesverzoeken ervaren we in de afgelopen dag, zoals elke monitoringsysteem. Maar tegelijkertijd is de belasting op historische gegevens ook behoorlijk groot. Deze komt voornamelijk van het alarmingssysteem, dat elke dertig seconden vraagt aan ClickHouse: 'Geef me de gegevens van de afgelopen zes weken. En nu, bouw een of andere voortschrijdende gemiddelde voor me en laten we de huidige waarde vergelijken met het historische.' <\/p>\n<p><\/p>\n<p>Ik wil zeggen dat we voor dergelijke zeer recente verzoeken een kleine tabel hebben, waarin we slechts twee dagen aan gegevens opslaan, en de belangrijkste verzoeken gaan naar deze tabel. Grote historische verzoeken worden naar de grote geshardte tabel gestuurd.<\/p>\n<p><\/p>\n<p><strong>Alexey Milovidov:<\/strong> Helaas is het voor uw scenario niet goed toepasbaar, maar ik zal een beschrijving geven van twee slechte en complexe sharding-schema's die niet gebruikt moeten worden, maar die in de service van mijn vrienden worden toegepast. <\/p>\n<p><\/p>\n<p>Er is een hoofdk cluster met gebeurtenissen van 'Yandex.Metrica'. Gebeurtenissen zijn paginaweergaven, klikken en overschakelingen. De meeste verzoeken zijn gericht op een specifieke website. U opent de service 'Yandex.Metrica', u heeft een website \u2014 avito.ru, u gaat naar het rapport, en er gaat een verzoek uit naar uw website.<\/p>\n<p><\/p>\n<p>Maar er zijn ook andere verzoeken \u2014 analytische en wereldwijde, die interne analisten doen. Voor alle zekerheid vermeld ik dat interne analisten verzoeken doen alleen voor de 'Yandex' services. Maar desondanks nemen zelfs de 'Yandex' services een substantieel deel van alle gegevens in beslag. Dit zijn verzoeken niet voor specifieke telmachines, maar voor bredere filtering.<\/p>\n<p><\/p>\n<p>Hoe organiseer je de gegevens zo dat het zowel effici\u00ebnt werkt voor \u00e9\u00e9n telmachine als voor wereldwijde verzoeken? De complicatie is bovendien dat het aantal verzoeken in ClickHouse voor het 'Metrica' cluster \u2014 enkele duizenden per seconde. Bij deze niet-triviale verzoeken kan bijvoorbeeld \u00e9\u00e9n ClickHouse-server geen enkele duizenden verzoeken per seconde aan.<\/p>\n<p><\/p>\n<p>De grootte van de cluster is ongeveer zeshonderd servers. Als je gewoon een Distributed tabel over deze cluster legt en daar enkele duizenden verzoeken naartoe stuurt, dan wordt het nog erger dan alles naar \u00e9\u00e9n server sturen. Aan de andere kant, als de data gelijkmatig zijn verspreid en we verzoeken van alle servers doen, dan valt die optie meteen af.<\/p>\n<p><\/p>\n<p>Er is een diametraal tegenovergestelde optie. Stel je voor dat we de data sharden op basis van websites, en een verzoek voor \u00e9\u00e9n website naar \u00e9\u00e9n shard gaat. Nu kan de cluster gemakkelijk tienduizend verzoeken per seconde aan, maar op \u00e9\u00e9n shard zal een bepaald verzoek veel te langzaam zijn. Het kan niet schalen qua capaciteit. Vooral als het gaat om de website avito.ru. Het is geen geheim dat Avito een van de meest bezochte websites in het Russisch internet is. Het verwerken van deze site op \u00e9\u00e9n shard zou waanzin zijn.<\/p>\n<p><\/p>\n<p>Daarom is het schakelschema slimmer ingericht. De hele cluster is verdeeld in een aantal clusters die we lagen noemen. Binnen elk cluster bevinden zich tussen de tien en enkele tientallen shards. In totaal zijn er negenendertig van zulke clusters. <\/p>\n<p><\/p>\n<p>Hoe schaalt dit alles? Het aantal clusters verandert niet \u2014 het is al een paar jaar negenendertig. Maar binnen elk van deze clusters verhogen we geleidelijk het aantal shards naarmate de data accumuleert. En het shardingschema in zijn geheel is als volgt \u2014 de verdeling in deze clusters gebeurt op basis van websites, en om te begrijpen welke site op welk cluster staat, wordt er een aparte metadatabank in MySQL gebruikt. E\u00e9n site op \u00e9\u00e9n cluster. En binnen dat cluster vindt de sharding plaats op basis van bezoekersidentificatie.<\/p>\n<p><\/p>\n<p>Bij het schrijven splitsen we ze op basis van de rest na deling van de bezoekersidentificator. Maar zodra we een nieuwe shard toevoegen, verandert het sharding-schema; we blijven splitsen, maar nu op basis van de rest na deling door een ander getal. Dit betekent dat \u00e9\u00e9n bezoeker zich al op meerdere servers bevindt, en daarop kun je niet rekenen. Dit is uitsluitend gedaan zodat de gegevens beter gecomprimeerd kunnen worden. Bij aanvragen gaan we naar de Distributed-tabel, die naar de cluster kijkt en contact maakt met tientallen servers. Zo'n onhandig schema.<\/p>\n<p><\/p>\n<p>Maar mijn verhaal zou onvolledig zijn als ik niet zeg dat we van dit schema zijn afgeweken. In het nieuwe schema hebben we alles veranderd en alle gegevens gekopieerd met behulp van clickhouse-copier.<\/p>\n<p><\/p>\n<p>In het nieuwe schema worden alle websites verdeeld in twee categorie\u00ebn \u2014 grote en kleine. Ik weet niet hoe de grens is bepaald, maar uiteindelijk zijn de grote websites opgenomen in \u00e9\u00e9n cluster, met 120 shards en drie replicaties in elke shard \u2014 dat zijn dus 360 servers. En het sharding-schema is zodanig dat elke aanvraag direct naar alle shards gaat. Als je nu in 'Yandex.Metrica' een willekeurige rapportpagina voor avito.ru opent, gaat de aanvraag naar 120 servers. Er zijn maar weinig grote websites in het Russisch segment van het internet. En het aantal aanvragen is niet duizend per seconde, maar zelfs minder dan honderd. Dit verwerkt de Distributed-tabel zonder problemen, die elk van hen verwerkt met 120 servers.<\/p>\n<p><\/p>\n<p>Het tweede cluster is voor kleine websites. Hier is het sharding-schema op basis van de website-identificator en elke aanvraag gaat precies naar \u00e9\u00e9n shard.<\/p>\n<p><\/p>\n<h2 id=\"anchorclickhouse-copieranchorv-clickhouse-est-utilita-clickhouse-copier-mozhete-pronbspneyo-rasskazat\"><noindex><a rel=\"nofollow\" name=\"clickhouse-copier\"><\/a><\/noindex>ClickHouse heeft een tool genaamd clickhouse-copier. Kun je daar meer over vertellen?<\/h2>\n<p><\/p>\n<p>Ik moet meteen zeggen dat deze oplossing zwaarder en iets minder effici\u00ebnt is. Het voordeel is dat het de gegevens volledig verspreidt volgens het schema dat je opgeeft. Maar het nadeel van het hulpprogramma is dat het helemaal geen resharding uitvoert. Het kopieert gegevens van de ene clusterstructuur naar de andere clusterstructuur.<\/p>\n<p><\/p>\n<p>Dit betekent dat je voor het functioneren ervan twee clusters moet hebben. Ze kunnen op dezelfde servers zijn geplaatst, maar desalniettemin zullen de gegevens niet incrementeel worden verplaatst, maar gekopieerd worden. <\/p>\n<p><\/p>\n<p>Bijvoorbeeld, er waren vier servers, nu zijn er acht. Je cre\u00ebert op alle servers een nieuwe Distributed tabel, nieuwe lokale tabellen en start clickhouse-copier, waarbij je de werkwijze aangeeft dat hij daar moet lezen, de nieuwe sharding-schema moet aannemen en de data daarheen moet overplaatsen. En je hebt op de oude servers anderhalf keer zoveel ruimte nodig als nu, omdat de oude data daar moet blijven, en daar bovenop komt een deel van deze oude data. Als je van tevoren hebt nagedacht over het opnieuw sharden van de data en er is ruimte, dan is deze aanpak geschikt.<\/p>\n<p><\/p>\n<p>Hoe werkt clickhouse-copier intern? Het splitst het hele werk op in een set taken voor het verwerken van \u00e9\u00e9n partitie van \u00e9\u00e9n tabel op \u00e9\u00e9n shard. Al deze taken kunnen parallel worden uitgevoerd, en clickhouse-copier kan op verschillende machines in meerdere instanties draaien, maar wat hij doet voor \u00e9\u00e9n partitie is niets anders dan insert select. Gegevens worden gelezen, gedecomprimeerd, opnieuw verdeeld, vervolgens weer gecomprimeerd, ergens geschreven en opnieuw gesorteerd. Dit is een zwaardere oplossing.<\/p>\n<p><\/p>\n<h2 id=\"anchorresharding-toolanchoru-vas-byla-pilotnaya-shtuka-kotoraya-nazyvalas-resharding-chto-snbspney\"><noindex><a rel=\"nofollow\" name=\"resharding-tool\"><\/a><\/noindex>Je had een pilotproject dat hersharding heette. Wat is daarmee gebeurd?<\/h2>\n<p><\/p>\n<blockquote><p>Je had in 2017 een proefproject, dat resharding heette. Er is zelfs een optie in ClickHouse. Ik begrijp dat dit niet succesvol was. Kun je uitleggen waarom dat zo is? Het lijkt erg relevant.<\/p><\/blockquote>\n<p>Het probleem is dat het bij de noodzaak om de data ter plaatse opnieuw te sharden, een vrij complexe synchronisatie vereist is om dit atomair 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, ze tonen zich onmiddellijk in de praktijk door iets heel eenvoudigs uit te leggen \u2014 niets werkt.<\/p>\n<p><\/p>\n<h2 id=\"anchormove-to-slow-diskanchormozhno-li-slivat-vse-chasti-dannyh-voedino-perednbspperemescheniem-nanbspmedlennye-diski\"><noindex><a rel=\"nofollow\" name=\"move-to-slow-disk\"><\/a><\/noindex>Is het mogelijk om alle delen van gegevens samen te voegen voordat ze naar langzame schijven worden verplaatst?<\/h2>\n<p><\/p>\n<blockquote><p>Vraag over TTL met de optie move to slow disk in de context van merges. Is er een manier, behalve via cron, om alle delen in \u00e9\u00e9n samen te voegen voordat ze naar langzame schijven worden verplaatst?<\/p><\/blockquote>\n<p>Het antwoord op de vraag of je alle stukken automatisch in \u00e9\u00e9n kunt samenvoegen voor hun verplaatsing \u2014 nee. Ik denk niet dat dat nodig is. Je kunt ook gewoon rekenen op het automatisch verplaatsen van de delen naar de langzame schijven. <\/p>\n<p><\/p>\n<p>We hebben twee criteria voor migratie. De eerste is op basis van opslagcapaciteit. Als er minder dan een bepaald percentage vrije ruimte op het huidige opslagniveau is, kiezen we een stuk en verplaatsen we dit naar langzamere opslag. Of beter gezegd, niet per se langzamer, maar de volgende \u2014 zoals je instelt.<\/p>\n<p><\/p>\n<p>Het tweede criterium betreft de grootte. Dit gaat over het verplaatsen van grote stukken. Je kunt de drempel voor vrije ruimte op de snelle schijf aanpassen, en de gegevens worden automatisch verplaatst.<\/p>\n<p><\/p>\n<h2 id=\"anchorup-to-dateanchorkak-pereezzhat-nanbspnovye-versii-clickhouse-esli-net-vozmozhnosti-zaranee-proverit-sovmestimost\"><noindex><a rel=\"nofollow\" name=\"up-to-date\"><\/a><\/noindex>Hoe verhuis je naar nieuwe versies van ClickHouse als je de compatibiliteit niet van tevoren kunt controleren?<\/h2>\n<p><\/p>\n<blockquote><p>This topic is regularly discussed <noindex><a rel=\"nofollow\" href=\"https:\/\/teleg.run\/clickhouse_ru\">in de Telegram-chat van ClickHouse<\/a><\/noindex> met inachtneming van verschillende versies, en toch. 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 de mogelijkheid om vooraf compatibiliteit in een sandbox te controleren?<\/p><\/blockquote>\n<p>Hier zijn enkele 'gouden' regels. De eerste is <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/ClickHouse\/ClickHouse\/blob\/master\/CHANGELOG.md\">to read the changelog<\/a><\/noindex>. Het is groot, maar er zijn afzonderlijke punten over achterwaarts incompatibele veranderingen. Je moet deze punten niet beschouwen als een rode vlag. Gewoonlijk zijn dit kleine incompatibiliteiten die verband houden met bepaalde randfunctionaliteiten die je waarschijnlijk niet gebruikt.<\/p>\n<p><\/p>\n<p>De tweede is \u2014 als je geen mogelijkheid hebt om compatibiliteit in een sandbox te controleren, en je wilt direct in de productie upgraden, is het advies \u2014 doe dit niet. Maak eerst een sandbox en test het. Als je geen testomgeving hebt, betekent dit waarschijnlijk dat je een relatief klein bedrijf bent, en dus kun je een deel van de gegevens naar je laptop kopi\u00ebren en controleren of alles correct werkt. Je kunt zelfs lokaal meerdere replica's op je eigen machine opzetten. Of je kunt ergens in de buurt een nieuwe versie opzetten en een deel van de gegevens daarheen uploaden \u2014 dat wil zeggen, een ge\u00efmproviseerde testomgeving cre\u00ebren. <\/p>\n<p><\/p>\n<p>Een andere regel is \u2014 doe geen upgrade binnen een week na het uitbrengen van een versie vanwege het opsporen van bugs in de productie en de daaropvolgende snelle fixes. Laten we de versie-numeratie van ClickHouse duidelijk maken, zodat we niet in de war raken. <\/p>\n<p><\/p>\n<p>Er is versie 20.3.4. Het cijfer 20 geeft het jaar van uitgave aan \u2014 2020. Wat betreft de inhoud maakt dit verder niets uit, dus laten we dit vergeten. Verder \u2014 20.3. Het tweede cijfer \u2014 in dit geval 3 \u2014 verhogen we elke keer als we een release uitbrengen met nieuwe functionaliteit. Als we een functie aan ClickHouse willen toevoegen, zijn we verplicht dit getal te verhogen. Dus in versie 20.4 zal ClickHouse nog beter presteren. Het derde cijfer \u2014 20.3.4. Hier staat 4 voor het aantal patch-releases waarin we geen nieuwe functies hebben toegevoegd, maar wel bugs hebben opgelost. En 4 betekent dat we dit vier keer hebben gedaan.<\/p>\n<p><\/p>\n<p>Je moet niet denken dat dit iets ergs is. Gewoonlijk kan de gebruiker de meest recente versie installeren, en deze zal een jaar lang zonder problemen draaien. Maar stel je voor dat er in een functie voor het verwerken van bitmap gegevens, die door onze Chinese collega's is toegevoegd, de server crasht bij het doorgeven van onjuiste argumenten. We zijn verplicht dit op te lossen. We zullen een nieuwe patchversie uitbrengen, en ClickHouse zal stabieler worden.<\/p>\n<p><\/p>\n<p>Als je ClickHouse in productie draait en er komt een nieuwe versie van ClickHouse uit met extra functies \u2014 bijvoorbeeld, 20.4.1 \u2014 neem dan niet de eerste dag de sprong om deze in productie te zetten. Waarom is deze versie \u00fcberhaupt nodig? Als je ClickHouse nog niet gebruikt, kun je het installeren en waarschijnlijk zal alles goed gaan. Maar als ClickHouse al stabiel draait, houd dan de patches en updates in de gaten \u2014 welke problemen we oplossen.<\/p>\n<p><\/p>\n<p><strong>Kirill Shvakov:<\/strong> Ik wil iets toevoegen over testomgevingen. Iedereen is erg bang voor testomgevingen en denkt om de een of andere reden dat als je een grote ClickHouse-cluster hebt, de testomgeving ook minstens even groot moet zijn of ten minste tien keer kleiner moet zijn. Dat is helemaal niet het geval.<\/p>\n<p><\/p>\n<p>Ik kan uit mijn eigen ervaring spreken. Ik heb een project waar ClickHouse in draait. Onze testomgeving daarvoor is een kleine virtuele machine in Hetzner voor twintig euro, waarin alles volledig is opgezet. Om dit te doen, hebben we volledige automatisering met Ansible, en daarom maakt het in principe geen verschil waar je het draait \u2014 op fysieke servers of gewoon op virtuele machines.<\/p>\n<p><\/p>\n<p>Wat kun je doen? Het zou goed zijn om in de ClickHouse-documentatie een voorbeeld op te nemen van hoe je een kleine cluster kunt opzetten \u2014 in Docker, in LXC, en misschien een Ansible-playbook te maken, omdat verschillende mensen verschillende implementaties hebben. Dit zou veel vergemakkelijken. Wanneer je in vijf minuten een cluster opzet, is het veel eenvoudiger om iets uit te zoeken. Het is veel handiger, omdat het uitrollen van een productieversie die je niet hebt getest \u2014 dat is de weg naar nergens. Soms werkt het, en soms niet. Dus hopen op succes is slecht.<\/p>\n<p><\/p>\n<p><strong>Maxim Kotyakov, senior backend engineer bij Avito:<\/strong> Ik zal nog wat toevoegen over testomgevingen, een van de problemen van grote bedrijven. We hebben een volledige acceptatiecluster van ClickHouse, met datamodellen en instellingen die exacte kopie\u00ebn zijn van wat er in productie is. Deze cluster is opgezet in vrij verouderde containers met minimale middelen. We schrijven daar een bepaald percentage van de productiedata naartoe, gelukkig is er de mogelijkheid om de stroom in Kafka te repliceren. Alles is gesynchroniseerd en geschaald \u2014 zowel qua vermogen als stroom, en theoretisch gezien zou het, onder gelijke voorwaarden, zich qua metriek moeten gedragen als productie. Alles wat potentieel explosief is, wordt eerst op deze stand gegooid en daar een paar dagen 'gerijpt' tot het klaar is. Maar uiteraard is deze oplossing duur, zwaar en met niet-nul ondersteuningskosten. <\/p>\n<p><\/p>\n<p><strong>Alexey Milovidov:<\/strong> Ik zal uitleggen wat de testomgeving van onze vrienden van 'Yandex.Metrica' inhoudt. E\u00e9n cluster had meer dan 600 servers, een ander had er 360, en er zijn nog een derde en verschillende clusters. De testomgeving voor een van hen is gewoon twee shards met twee replica's in elk. Waarom twee shards? Om niet maar \u00e9\u00e9n te hebben. En ook replica's moeten er zijn. Gewoon een minimale hoeveelheid die je je kunt veroorloven.<\/p>\n<p><\/p>\n<p>Deze testomgeving maakt het mogelijk om de werking van de verzoeken te controleren en ervoor te zorgen dat er geen grote problemen zijn. Maar vaak ontstaan de problemen van een heel andere aard, wanneer alles werkt, maar er enkele kleine veranderingen zijn in de belasting.<\/p>\n<p><\/p>\n<p>Ik geef een voorbeeld. We besloten om de nieuwe versie van ClickHouse te installeren. Deze is beschikbaar gemaakt in de testomgeving, en geautomatiseerde tests in de 'Yandex.Metrica' zijn uitgevoerd, waarbij de gegevens van de oude versie en de nieuwe versie met elkaar vergeleken werden, met de hele keten doorgelopen. En natuurlijk zijn de tests in onze CI ook groen. Anders zouden we deze versie zelfs niet hebben voorgesteld.<\/p>\n<p><\/p>\n<p>Alles is prima. We beginnen met de uitrol naar productie. Ik ontvang een melding dat de belasting op de grafieken meerdere keren is toegenomen. We draaien de versie terug. Ik kijk naar de grafiek en zie: de belasting is inderdaad meerdere keren gestegen tijdens de uitrol, en weer gedaald toen we het terugdraaiden. Toen we de versie terugdraaide, steeg de belasting net zo goed en daalde weer terug. Dus de conclusie is dat de belasting steeg door de uitrol, niets verrassends.<\/p>\n<p><\/p>\n<p>Daarna was het moeilijk om de collega's te overtuigen om de nieuwe versie daadwerkelijk uit te rollen. Ik zeg: 'Alles is goed, rol uit. Houd je duimen gekruist, alles zal werken. De belasting op de grafieken is nu toegenomen, maar alles is goed. Blijf sterk.' We hebben het zo gedaan, en de versie is uitgerold naar productie. Maar bijna bij elke uitrol ontstaan vergelijkbare problemen.<\/p>\n<p><\/p>\n<h2 id=\"anchorkill-queryanchorkill-query-dolzhen-ubivat-zaprosy-no-on-etogo-ne-delaet-pochemu\"><noindex><a rel=\"nofollow\" name=\"kill-query\"><\/a><\/noindex>Kill query zou zoekopdrachten moeten be\u00ebindigen, maar dat doet het niet. Waarom niet?<\/h2>\n<p><\/p>\n<blockquote><p>Een gebruiker, een bepaalde analist, kwam naar me toe en maakte een verzoek dat mijn ClickHouse-cluster platlegde. Een bepaalde node of het hele cluster, afhankelijk van waar de replicatie of shard het verzoek heeft ontvangen. Ik zie dat alle CPU-bronnen op deze server vol zijn, alles is rood. Tegelijkertijd reageert ClickHouse wel op verzoeken. En ik schrijf: 'Kun je me alsjeblieft de process list laten zien, welk verzoek dit gekkenhuis heeft veroorzaakt?'<\/p>\n<p>Ik vind dit verzoek en schrijf de kill-opdracht. En ik zie dat er niets gebeurt. Mijn server is vol, ClickHouse geeft verder wat commando's, laat zien dat de server levend is, en alles is geweldig. Maar ik ervaar degradatie bij alle gebruikersverzoeken, er begint degradatie op te treden bij het schrijven naar ClickHouse, en mijn kill query werkt niet. Waarom? Ik dacht dat de kill query verzoeken moest be\u00ebindigen, maar dat gebeurt niet.<\/p><\/blockquote>\n<p>Nu komt er een behoorlijk vreemde reactie. Het probleem is dat de kill query verzoeken niet be\u00ebindigt. <\/p>\n<p><\/p>\n<p>De Kill-query stelt een kleine vlag in met de naam 'ik wil dat deze query wordt be\u00ebindigd'. De query controleert tijdens het verwerken van elk gegevensblok deze vlag. Als deze is ingesteld, stopt de query met werken. Dit betekent dat niemand de query be\u00ebindigt; deze moet zelf alles controleren en stoppen. Dit moet werken in alle gevallen waarin de query zich in de staat van gegevensverwerking bevindt. Het verwerkt het volgende gegevensblok, controleert de vlag en stopt.<\/p>\n<p><\/p>\n<p>Dit werkt niet in gevallen waarin de query geblokkeerd is door een bepaalde operatie. Waarschijnlijk is dit niet uw geval, want volgens uw woorden verbruikt het een hoop serverresources. Het kan zijn dat dit niet werkt bij externe sortering en nog enkele details. Maar in principe zou dit niet moeten ontbreken, dat is een bug. Het enige dat ik kan aanbevelen, is ClickHouse bij te werken.<\/p>\n<p><\/p>\n<h2 id=\"anchorreading-timeanchorkak-rasschitat-vremya-otveta-pri-chitayuschey-nagruzke\"><noindex><a rel=\"nofollow\" name=\"reading-time\"><\/a><\/noindex>Hoe bereken je de responstijd bij een leesbelasting?<\/h2>\n<p><\/p>\n<blockquote><p>Er is een tabel waarin aggregaties per item worden opgeslagen - verschillende telpunten. Het aantal rijen is ongeveer honderd miljoen. Kan ik rekenen op een voorspelbare responstijd als ik 1K RPS over 1K items laat lopen? <\/p><\/blockquote>\n<p>Gezien de context gaat het over de leesbelasting, want voor schrijven zijn er geen problemen - of je nu duizend of honderdduizend of soms zelfs miljoenen rijen invoert. <\/p>\n<p><\/p>\n<p>Lezen queries zijn er in allerlei soorten. In select 1 kan ClickHouse ongeveer tienduizenden queries per seconde uitvoeren, dus zelfs queries op \u00e9\u00e9n sleutel zullen al wat resources vereisen. En dergelijke puntqueries zijn moeilijker dan in bijvoorbeeld key-value databases, omdat voor elk lezen een gegevensblok op index moet worden gelezen. De index adresseert niet elke record, maar elk bereik. Dus je moet het hele bereik lezen - dat is standaard 8192 rijen. En je moet het gecomprimeerde gegevensblok van 64 Kb tot 1 Mb uitpakken. Gewoonlijk duren dergelijke puntqueries van enkele milliseconden. Maar dit is de eenvoudigste variant.<\/p>\n<p><\/p>\n<p>Laten we een eenvoudige wiskunde proberen. Als je een aantal milliseconden met duizend vermenigvuldigt, krijg je een aantal seconden. Het lijkt misschien alsof duizend aanvragen per seconde niet mogelijk zijn, maar in werkelijkheid kan het, omdat we verschillende processor-kernen hebben. In principe kan 1000 RPS ClickHouse soms aan, maar alleen bij korte, specifieke aanvragen.<\/p>\n<p><\/p>\n<p>Als je de ClickHouse-cluster wilt schalen op het aantal eenvoudige aanvragen, raad ik de eenvoudigste oplossing aan: vergroot het aantal replica's en stuur aanvragen naar een willekeurige replica. Als \u00e9\u00e9n replica vijfhonderd aanvragen per seconde kan verwerken, wat volkomen haalbaar is, dan zullen drie replica's anderhalve duizend aanvragen aan kunnen.<\/p>\n<p><\/p>\n<p>Soms kun je ClickHouse ook optimaliseren voor het maximale aantal specifieke leesacties. Wat heb je daarvoor nodig? Ten eerste moet je de granulariteit van de index verlagen. Deze moet daarbij niet tot \u00e9\u00e9n worden verlaagd, maar afhankelijk van het aantal records in de index, wat enkele miljoenen of tientallen miljoenen per server zal zijn. Als je honderd miljoen rijen in de tabel hebt, kun je de granulariteit op 64 instellen.<\/p>\n<p><\/p>\n<p>Je kunt de grootte van het gecomprimeerde blok verkleinen. Hiervoor zijn instellingen beschikbaar. <strong>min compress blokgrootte<\/strong>, <strong>max compress blokgrootte<\/strong>Je kunt ze verlagen, de gegevens opnieuw laden, en dan zullen specifieke aanvragen sneller zijn. Maar ClickHouse is nog steeds geen key-value databasissysteem. Een grote hoeveelheid kleine aanvragen is een antipatroon voor belasting.<\/p>\n<p><\/p>\n<p><strong>Kirill Shvakov:<\/strong> Ik geef je een advies voor het geval je daar gewone counters hebt. Dit is een vrij standaard situatie waarbij ClickHouse een bepaalde teller opslaat. Ik heb een gebruiker uit een bepaald land, nog een derde veld, en het moet incrementeel iets worden verhoogd. Neem MySQL, maak een unieke sleutel \u2014 in MySQL is dit een duplicate key, en in PostgreSQL is dit een conflict \u2014 en voeg met een plusteken toe. Dit zal veel beter werken. <\/p>\n<p><\/p>\n<p>Als je niet veel gegevens hebt, heeft het weinig zin om ClickHouse te gebruiken. Er zijn reguliere databases en die doen dit goed. <\/p>\n<p><\/p>\n<h2 id=\"anchorpimp-my-clickhouseanchorchto-podtyunit-v-clickhouse-chtoby-bolshe-dannyh-bylo-vnbspkeshe\"><noindex><a rel=\"nofollow\" name=\"pimp-my-clickhouse\"><\/a><\/noindex>Wat kun je tunen in ClickHouse om meer gegevens in de cache te krijgen?<\/h2>\n<p><\/p>\n<blockquote><p>Stel je voor: de servers hebben 256 GB RAM, in de dagelijkse routine gebruikt ClickHouse ongeveer 60-80 GB, met pieken tot 130. Wat kun je inschakelen en tunen om meer gegevens in de cache te krijgen en dus minder schrijfoperaties naar de schijf?<\/p><\/blockquote>\n<p>Over het algemeen gaat de pagina-cache van het besturingssysteem goed om met deze taak. Als je gewoon de top opent, kijk dan naar cached of free \u2014 daar staat ook hoeveel er gecached is \u2014 dan kun je zien dat al het vrije geheugen wordt gebruikt voor cache. En deze gegevens worden bij het lezen niet vanaf de schijf, maar uit het RAM gelezen. Ik kan hierbij zeggen dat de cache effectief wordt gebruikt, omdat precies gecomprimeerde gegevens gecached worden.<\/p>\n<p><\/p>\n<p>Toch, als je sommige eenvoudige verzoeken nog verder wilt versnellen, is er een mogelijkheid om binnen ClickHouse de cache in gedecomprimeerde gegevens in te schakelen. Dit wordt genoemd <strong>ongecomprimeerde cache<\/strong>. In het configuratiebestand config.xml stel je de uncompressed cache size in op de gewenste waarde \u2014 ik raad aan om niet meer dan de helft van het vrije RAM te gebruiken, omdat de rest naar de pagina-cache zal gaan. <\/p>\n<p><\/p>\n<p>Daarnaast zijn er twee instellingen op het niveau van verzoeken. De eerste instelling is <strong>use uncompressed cache<\/strong> \u2014 schakelt het gebruik ervan in. Het wordt aanbevolen om dit in te schakelen voor alle verzoeken, behalve zware verzoeken die mogelijk alle gegevens in \u00e9\u00e9n keer kunnen lezen en deze cache kunnen leegmaken. En de tweede instelling is iets als het maximale aantal rijen voor cachegebruik. Het beperkt automatisch grote verzoeken, zodat ze om de cache heen gaan.<\/p>\n<p><\/p>\n<h2 id=\"anchorstorage-configurationanchorkak-mozhno-nastroit-storage_configuration-dlya-hraneniya-v-operativke\"><noindex><a rel=\"nofollow\" name=\"storage-configuration\"><\/a><\/noindex>Hoe kan ik storage_configuration instellen voor opslag in het RAM?<\/h2>\n<p><\/p>\n<blockquote><p>In de nieuwe ClickHouse-documentatie las ik een sectie die gerelateerd is <noindex><a rel=\"nofollow\" href=\"https:\/\/clickhouse.tech\/docs\/en\/single\/#table_engine-mergetree-multiple-volumes\">met data opslag<\/a><\/noindex>. In de beschrijving staat een voorbeeld met snelle SSD. <\/p>\n<p>Het is interessant hoe je hetzelfde kunt configureren met volume hot memory. En nog een vraag. Hoe werkt select met zo'n organisatie van gegevens, zal het de hele set lezen of alleen datgene wat op de schijf ligt, en worden deze gegevens in het geheugen gecomprimeerd? En hoe werkt de prewhere-sectie met zo'n organisatie van gegevens?<\/p><\/blockquote>\n<p>Deze instelling heeft invloed op de opslag van datablokken, en hun formaat verandert op geen enkele manier.<br \/>\nLaten we het nader bekijken. <\/p>\n<p><\/p>\n<p>De opslag van gegevens in RAM kan worden ingesteld. Alles wat voor de schijf geconfigureerd wordt \u2014 dat is het pad. Je cre\u00ebert een tmpfs-partitie die is gemonteerd op een bepaald pad in het bestandssysteem. Je geeft dit pad op als het pad voor de opslag van gegevens voor de hot partition, waar datablokken beginnen binnen te komen en te worden geschreven, alles werkt goed. <\/p>\n<p><\/p>\n<p>Maar ik raad aan om dit niet te doen vanwege de lage betrouwbaarheid, hoewel het mogelijk is als je minstens drie replica's in verschillende datacenters hebt. Als dat nodig is, worden de gegevens hersteld. Stel je voor dat de server plotseling is uitgeschakeld en weer is ingeschakeld. De sectie is opnieuw gemonteerd, maar er is leegte. De ClickHouse-server ziet bij het opstarten dat deze stukken ontbreken, terwijl ze volgens de metadata van ZooKeeper aanwezig zouden moeten zijn. Hij controleert op welke replica's ze beschikbaar zijn, vraagt deze op en downloadt ze. Zo worden de gegevens hersteld. <\/p>\n<p><\/p>\n<p>In die zin verschilt het opslaan van gegevens in het RAM fundamenteel niet van het opslaan op schijf, omdat gegevens bij het opslaan op schijf ook eerst in de page cache komen en fysiek met vertraging worden weggeschreven. Dit hangt af van de manier waarop het bestandssysteem is gemonteerd. Maar voor de zekerheid zeg ik dat ClickHouse geen fsync uitvoert bij insert.<\/p>\n<p><\/p>\n<p>Tegelijkertijd worden de gegevens in het RAM opgeslagen in exact hetzelfde formaat als op schijf. De select-query selecteert op dezelfde manier de stukken die moeten worden gelezen, kiest de benodigde dataranges in die stukken en leest ze. En prewhere werkt absoluut hetzelfde, ongeacht of de gegevens in het RAM of op schijf stonden.<\/p>\n<p><\/p>\n<h2 id=\"anchorlow-cardinalityanchordo-kakogo-kolichestva-unikalnyh-znacheniy-effektiven-low-cardinality\"><noindex><a rel=\"nofollow\" name=\"low-cardinality\"><\/a><\/noindex>Tot hoeveel unieke waarden is Low Cardinality effectief?<\/h2>\n<p><\/p>\n<p>Low Cardinality is ingenieus opgezet. Het maakt datadatabases, maar ze zijn lokaal. Ten eerste zijn de dictionaries specifiek voor elk stuk, en ten tweede kunnen ze zelfs binnen \u00e9\u00e9n stuk verschillen per bereik. Wanneer het aantal unieke waarden de drempelwaarde bereikt \u2014 naar mijn mening \u00e9\u00e9n miljoen \u2014 wordt de dictionary gewoon uitgesteld en wordt er een nieuwe aangemaakt.<\/p>\n<p><\/p>\n<p>Het antwoord in het algemeen: voor elk lokaal bereik \u2014 laten we zeggen voor elke dag \u2014 is Low Cardinality effici\u00ebnt tot ongeveer \u00e9\u00e9n miljoen unieke waarden. Daarna zal er gewoon een fallback zijn, waarbij meerdere verschillende dictionaries in plaats van \u00e9\u00e9n worden gebruikt. Het zal ongeveer net zo werken als een gewone kolom van het type string, misschien iets minder effici\u00ebnt, maar er zal geen ernstige degratie van de prestaties optreden. <\/p>\n<p><\/p>\n<h2 id=\"anchorfulltext-searchanchorkakie-luchshie-praktiki-ponbsppolnotekstovomu-poisku-ponbsptablice-snbsppyatyu-milliardami-strok\"><noindex><a rel=\"nofollow\" name=\"fulltext-search\"><\/a><\/noindex>Wat zijn de beste praktijken voor full-text zoekopdrachten op een tabel met vijf miljard rijen?<\/h2>\n<p><\/p>\n<p>Er zijn verschillende mogelijke antwoorden. De eerste is te zeggen dat ClickHouse geen systeem voor full-text zoekopdrachten is. Hiervoor zijn er speciale systemen, bijvoorbeeld, <noindex><a rel=\"nofollow\" href=\"https:\/\/www.elastic.co\/enterprise-search\">Elasticsearch<\/a><\/noindex> en <noindex><a rel=\"nofollow\" href=\"http:\/\/sphinxsearch.com\/\">Sphinx<\/a><\/noindex>. Desondanks kom ik steeds vaker mensen tegen die zeggen dat ze van Elasticsearch naar ClickHouse overstappen.<\/p>\n<p><\/p>\n<p>Waarom gebeurt dit? Ze leggen het uit door te zeggen dat Elasticsearch moeite heeft met het omgaan met bepaalde volumes, vooral als het gaat om het opbouwen van indexen. Indexen worden te omvangrijk, en als je de gegevens gewoon in ClickHouse plaatst, blijken ze veel effectiever qua volume opgeslagen te worden. Bovendien zijn zoekopdrachten vaak niet zo dat je een bepaalde frase in de gehele dataset moet vinden met inachtneming van morfologie, maar heel anders. Bijvoorbeeld, het zoeken in de logs naar een bepaalde byte-volgorde van de afgelopen paar uur.<\/p>\n<p><\/p>\n<p>In dit geval maak je een index in ClickHouse, waarbij het eerste veld de datum en tijd zal zijn. En de grootste filter op de gegevens zal juist op basis van het datumbereik zijn. Binnen het geselecteerde datumbereik kan in de regel een fulltext-zoekopdracht zelfs met brute-force-methoden door middel van like worden uitgevoerd. De like-operator in ClickHouse is de meest effectieve like-operator die je kunt vinden. Als je een betere vindt, laat het me weten. <\/p>\n<p><\/p>\n<p>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 \u00e9\u00e9n terabyte aan gegevens per dag hebt, en je zoekt gedurende een dag naar een bepaald woord, dan moet je die terabyte scannen. En die bevindt zich zeker op gewone harde schijven, wat betekent dat ze zo belast zullen zijn dat je niet meer via SSH op deze server kunt inloggen.<\/p>\n<p><\/p>\n<p>In dit geval ben ik bereid nog een kleine truc voor te stellen. Het is van experimentele aard \u2014 het kan werken, maar het kan ook niet. In ClickHouse zijn er fulltext-indexen in de vorm van trigram Bloom-filters. Onze collega's van Arenadata hebben deze indexen al getest en vaak werken ze precies zoals bedoeld.<\/p>\n<p><\/p>\n<p>Om ze correct te gebruiken, moet je goed begrijpen hoe ze werken: wat een trigram Bloom-filter is en hoe je de grootte ervan kunt kiezen. Ik kan zeggen dat ze nuttig zullen zijn voor zoekopdrachten naar zeldzame zinnen en substrings die zelden in de gegevens voorkomen. In dat geval worden subranges via de indexen gekozen en zal er minder data gelezen worden.<\/p>\n<p><\/p>\n<p>Onlangs zijn er in ClickHouse nog geavanceerdere functies voor full-text zoekopdrachten toegevoegd. Dit omvat in de eerste plaats het zoeken naar meerdere substrings in \u00e9\u00e9n doorzoeking, waaronder varianties met en zonder hoofdlettergebruik, met ondersteuning voor UTF-8 of alleen voor ASCII. Kies de meest effectieve optie die u nodig heeft. <\/p>\n<p><\/p>\n<p>Ook is er nu de mogelijkheid om meerdere reguliere expressies in \u00e9\u00e9n doorzoeking te zoeken. U hoeft niet X like \u00e9\u00e9n substring of X like een andere substring te schrijven. U schrijft het gewoon, en alles wordt zo effici\u00ebnt mogelijk uitgevoerd.<\/p>\n<p><\/p>\n<p>Ten derde is er nu een benaderende zoekfunctie voor regex en een benaderende substring-zoekfunctie. Als iemand een woord met een fout heeft geschreven, zal het worden gezocht op basis van de maximale overeenkomst.<\/p>\n<p><\/p>\n<h2 id=\"anchorhello-and-welcomeanchorkak-luchshe-organizovat-dostup-vnbspclickhouse-dlyanbspbolshogo-kolichestva-polzovateley\"><noindex><a rel=\"nofollow\" name=\"hello-and-welcome\"><\/a><\/noindex>Hoe organiseer je het beste de toegang tot ClickHouse voor een groot aantal gebruikers?<\/h2>\n<p><\/p>\n<blockquote><p>Vertel hoe u de toegang voor een groot aantal consumenten en analisten het beste kunt organiseren. Hoe kunt u een wachtrij vormen, verzoeken prioriteren voor max gelijktijdige verzoeken, en met welke hulpmiddelen?<\/p><\/blockquote>\n<p>Als het cluster groot genoeg is, is het een goed idee om nog twee servers op te zetten die als toegangspunt voor analisten dienen. Dat wil zeggen, laat analisten niet naar specifieke shards van het cluster gaan, maar maak gewoon twee lege servers zonder gegevens aan, en stel daarop toegangrechten in. Deze gebruikersinstellingen worden bij gedistribueerde verzoeken naar externe servers overgedragen. U configureert alles op deze twee servers, en de instellingen hebben effect op het hele cluster.<\/p>\n<p><\/p>\n<p>In principe zijn deze servers zonder gegevens, maar de hoeveelheid RAM op hen is essentieel voor het uitvoeren van verzoeken. De schijf kan ook worden gebruikt voor tijdelijke gegevens, als externe aggregatie of externe sortering is ingeschakeld.<\/p>\n<p><\/p>\n<p>Het is belangrijk om te kijken naar de instellingen die verband houden met alle mogelijke limieten. Als ik nu als analist op het cluster 'Yandex.Metrica' kom en een verzoek doe, <strong>select count from hits<\/strong>, krijg ik meteen een uitzondering dat ik het verzoek niet kan uitvoeren. Het maximale aantal rijen dat ik mag scannen is honderd miljard, terwijl er in totaal vijftig biljoen in \u00e9\u00e9n tabel op het cluster zijn. Dit is de eerste beperking. <\/p>\n<p><\/p>\n<p>Stel dat ik de beperking op het aantal rijen verwijder en het verzoek opnieuw uitvoer. Dan zie ik de volgende uitzondering \u2014 de instelling is ingeschakeld <strong>force index by date<\/strong>Ik kan de aanvraag niet uitvoeren als ik geen datumbereik heb opgegeven. Verwacht niet dat analisten dit handmatig zullen invoeren. Een typisch geval is&nbsp;\u2014 een datumbereik geschreven waar de gebeurtenisdatum tussen een week ligt. En dan wordt er gewoon niet goed met haakjes omgegaan, waardoor in plaats van and or URL overeenstemmen ontstaat. Als er geen beperkingen zijn, begint het te scannen in de URL-kolom en verspilt het gewoon een hoop middelen.<\/p>\n<p><\/p>\n<p>Bovendien zijn er in ClickHouse twee instellingen voor prioriteiten. Helaas zijn ze erg primitief. De ene wordt gewoon genoemd <strong>priority<\/strong>. Als de prioriteit&nbsp;\u2260&nbsp;0 is en er aanvragen met&nbsp;een bepaalde prioriteit worden uitgevoerd, maar er wordt een aanvraag uitgevoerd met een prioriteit die lager is, wat betekent dat dit een hogere prioriteit is, wordt de aanvraag met een hogere prioriteit, wat een lagere prioriteit betekent, gewoon opgeschort en zal helemaal niet werken in die tijd.<\/p>\n<p><\/p>\n<p>Dit is een zeer ruwe instelling, en deze is niet geschikt voor&nbsp;gevallen waarin er constante belasting op de cluster is. Maar als je korte, impulsieve aanvragen belangrijk zijn en de cluster voornamelijk inactief is, dan is deze instelling geschikt.<\/p>\n<p><\/p>\n<p>De volgende prioriteitsinstelling heet <strong>OS-threadprioriteit<\/strong>. Het stelt gewoon voor&nbsp;alle threads van de aanvraag-uitvoering een waarde nice in voor de Linux-scheduler. Het werkt zoals het hoort, maar het werkt nog steeds. Als je de laagste waarde nice instelt&nbsp;\u2014 die is het grootst in waarde, wat de laagste prioriteit betekent&nbsp;\u2014 en voor aanvragen met hoge prioriteit -19 instelt, dan zal de CPU ongeveer vier keer minder lage prioriteitsaanvragen verwerken dan hoge prioriteitsaanvragen. <\/p>\n<p><\/p>\n<p>Daarnaast moet je de maximale tijd voor de uitvoering van de aanvraag instellen&nbsp;\u2014 laten we zeggen, vijf minuten. De minimale snelheid van de aanvraagverwerking&nbsp;\u2014 dat is het allerbelangrijkste. Deze instelling bestaat al een tijdje en is nodig om niet alleen te beweren dat ClickHouse niet vertraagt, maar ook om dit af te dwingen.<\/p>\n<p><\/p>\n<p>Stel je voor, je stelt in: als een aanvraag minder dan \u00e9\u00e9n miljoen rijen per seconde verwerkt&nbsp;\u2014 dat kan niet. Dit schaadt onze goede naam, onze goede database. Laten we dit gewoon verbieden. Er zijn eigenlijk twee instellingen. De ene heet <strong>minimale uitvoeringssnelheid<\/strong> \u2014 in&nbsp;lijnen per&nbsp;seconde, en de tweede heet timeout voordat de minimale uitvoeringstijd wordt gecontroleerd&nbsp;\u2014 standaard vijftien seconden. Dus vijftien seconden is mogelijk, en daarna, als het traag is, kan er eenvoudig een uitzondering worden gegooid \u2014 de aanvraag onderbreken.<\/p>\n<p><\/p>\n<p>Daarnaast moeten quota worden ingesteld. In&nbsp;ClickHouse is er een ingebouwde mogelijkheid voor quota, die het verbruik van bronnen bijhoudt. Maar helaas niet voor harde bronnen zoals CPU, schijven, maar voor logische&nbsp;\u2014 het aantal verwerkte aanvragen, rijen en gelezen bytes. En je kunt bijvoorbeeld instellen dat er maximaal honderd aanvragen binnen vijf minuten en duizend aanvragen per uur zijn.<\/p>\n<p><\/p>\n<p>Waarom is dit belangrijk? Omdat sommige analytische aanvragen handmatig zullen worden uitgevoerd vanuit&nbsp;de ClickHouse-client. En alles zal goed gaan. Maar als je geavanceerde analisten in je bedrijf hebt, zullen zij een script schrijven, en in dat script kan er een fout zitten. En deze fout kan ertoe leiden dat de aanvraag in een eindeloze lus wordt uitgevoerd. Dit is wat je moet beschermen.<\/p>\n<p><\/p>\n<h2 id=\"anchorsmorgasbordanchormozhno-li-otdat-rezultaty-odnogo-zaprosa-desyati-klientam\"><noindex><a rel=\"nofollow\" name=\"smorgasbord\"><\/a><\/noindex>Is het mogelijk om de resultaten van \u00e9\u00e9n query aan tien klanten te geven?<\/h2>\n<p><\/p>\n<blockquote><p>We hebben een aantal gebruikers die graag met zeer grote aanvragen op hetzelfde moment komen. De aanvraag is groot en wordt snel uitgevoerd, maar door het feit dat er veel van zulke aanvragen tegelijkertijd zijn, wordt het pijnlijk. Is het mogelijk om dezelfde aanvraag die tien keer achter elkaar is binnengekomen, \u00e9\u00e9n keer uit te voeren en het resultaat aan tien klanten te geven?<\/p><\/blockquote>\n<p>Het probleem is dat we geen resultaten van cache of tussentijdse gegevens hebben. Er is een page cache van het besturingssysteem, die voorkomt dat gegevens opnieuw van de schijf worden gelezen, maar helaas moeten de gegevens toch worden uitgepakt, gedeserialiseerd en opnieuw verwerkt. <\/p>\n<p><\/p>\n<p>We zouden dit op de een of andere manier willen vermijden, hetzij door tussentijdse gegevens te cachen, hetzij door soortgelijke aanvragen in een wachtrij te plaatsen en resultaten te cachen. Momenteel hebben we \u00e9\u00e9n pull request in ontwikkeling die caching van aanvragen toevoegt, maar alleen voor subaanvragen in de secties in en join \u2014 dat wil zeggen dat de oplossing niet volledig is.<\/p>\n<p><\/p>\n<p>Toch hebben we ook zo'n situatie. Een klassiek voorbeeld is verzoeken met paginering. Er is een rapport, met verschillende pagina's, en er wordt een verzoek gedaan met limit 10. Dan hetzelfde, maar limit 10,10. Vervolgens weer de volgende pagina. En de vraag is, waarom tellen we dit telkens opnieuw? Maar momenteel is er geen oplossing en kunnen we dit niet vermijden.<\/p>\n<p><\/p>\n<p>Er is een alternatief dat als sidecar naast ClickHouse wordt geplaatst \u2014 <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/Vertamedia\/chproxy\">ClickHouse Proxy<\/a><\/noindex>.<\/p>\n<p><\/p>\n<p><strong>Kirill Shvakov:<\/strong> In ClickHouse Proxy is er een ingebouwde rate limiter en ingebouwde cache voor resultaten. Er zijn veel instellingen gemaakt 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 voor verzoeken geldig blijft. Als de verzoeken echt identiek waren, zal Proxy ze meerdere keren teruggeven, maar zal het maar \u00e9\u00e9n keer naar ClickHouse gaan.<\/p>\n<p><\/p>\n<p>Nginx heeft ook een cache in de gratis versie, en dat zal ook werken. Nginx heeft zelfs instellingen die ervoor zorgen dat als aanvragen gelijktijdig binnenkomen, het de andere zal vertragen totdat \u00e9\u00e9n is voltooid. Maar specifiek in ClickHouse Proxy is de instelling veel beter gedaan. Het is specifiek ontwikkeld voor ClickHouse, voor deze verzoeken, en is daarom geschikter. En het is eenvoudig te installeren. <\/p>\n<p><\/p>\n<h2 id=\"anchorasynchronousanchorkak-byt-snbspasinhronnymi-operaciyami-i-materializovannymi-predstavleniyami\"><noindex><a rel=\"nofollow\" name=\"asynchronous\"><\/a><\/noindex>Hoe ga je om met asynchrone bewerkingen en materi\u00eble weergaven?<\/h2>\n<p><\/p>\n<blockquote><p>Er is een probleem dat operaties met de replacing-engine asynchroon zijn \u2014 eerst worden de gegevens geschreven, dan vindt de samenvoeging plaats. Als er een gematerialiseerde tabel onder deze tabel leeft met bepaalde aggregaten, zullen er duplicaten in worden geschreven. En als er geen complexe logica is, worden de gegevens gedupliceerd. Wat kunnen we hieraan doen?<\/p>\n<p>Er is een duidelijke oplossing \u2014 implementeer een trigger op een bepaalde klasse van materialized views tijdens een asynchrone samenvoegoperatie. Zijn er 'zilverpijlen', plannen voor de implementatie van dergelijke functionaliteiten?<\/p><\/blockquote>\n<p>Het is de moeite waard om te begrijpen hoe deduplicatie werkt. Wat ik nu ga uitleggen, is niet gerelateerd aan de kwestie, maar het is goed om dit in gedachten te houden.<\/p>\n<p><\/p>\n<p>Bij het invoegen in een gerepliceerde tabel is er deduplicatie van volledig ingevoegde blokken. Als je hetzelfde blok opnieuw hebt ingevoegd, met hetzelfde aantal van dezelfde rijen in dezelfde volgorde, worden de gegevens gededupliceerd. Je ontvangt 'Ok' als antwoord op de insert, maar feitelijk wordt er slechts \u00e9\u00e9n batch gegevens geschreven, en deze wordt niet gedupliceerd.<\/p>\n<p><\/p>\n<p>Dit is nodig voor de zekerheid. Als je tijdens het invoegen 'Ok' hebt ontvangen, betekent dit dat je gegevens zijn ingevoegd. Als je een fout van ClickHouse hebt ontvangen, zijn ze niet ingevoegd en moet je de invoegen opnieuw uitvoeren. Maar als de verbinding tijdens het invoegen verbroken is, weet je niet of de gegevens zijn ingevoerd of niet. De enige optie is om de invoegen opnieuw te herhalen. Als de gegevens daadwerkelijk zijn ingevoegd en je ze opnieuw invoegt, is er blokdeduplicatie. Dit is nodig om duplicaten te voorkomen. <\/p>\n<p><\/p>\n<p>En het is ook belangrijk hoe het werkt voor gematerialiseerde weergaven. Als de gegevens zijn gededupliceerd bij het invoegen in de hoofdtabel, zullen ze ook niet naar de gematerialiseerde weergave gaan.<\/p>\n<p><\/p>\n<p>Nu over de vraag. Je hebt een complexere situatie, omdat je duplicaten van afzonderlijke rijen schrijft. Dat wil zeggen, niet een volledige batch is gedupliceerd, maar specifieke rijen, en deze worden in de achtergrond samengevoegd. Inderdaad, de gegevens zullen worden samengevoegd in de hoofdtabel, terwijl de niet-samengevoegde naar de gematerialiseerde weergave gaan, en bij merges zal er niets met de gematerialiseerde weergaven gebeuren. Omdat de gematerialiseerde weergave niets anders is dan een trigger voor de insert. Bij andere operaties gebeurt er niets extra's mee.<\/p>\n<p><\/p>\n<p>En daar kan ik helaas geen vreugde brengen. Je moet alleen een specifieke oplossing voor dit geval zoeken. Bijvoorbeeld, is het mogelijk om in de gematerialiseerde weergave ook een vervanging te doen, en misschien werkt de deduplicatiemethode zo ook. Maar helaas is dat niet altijd het geval. Als het aggregatief is, werkt het niet. <\/p>\n<p><\/p>\n<p><strong>Kirill Shvakov:<\/strong> Ook wij hadden destijds onze eigen uitdagingen met adverteren. Er was een probleem met het tonen van advertenties en er waren bepaalde gegevens die we in real-time konden weergeven \u2014 dat zijn gewoon weergaven. Ze worden zelden gedupliceerd, maar als dat gebeurt, passen we ze later alsnog aan. En er waren dingen die we niet konden dupliceren \u2014 klikken en al die zaken. Maar we wilden ze ook praktisch meteen laten zien.<\/p>\n<p><\/p>\n<p>Hoe zijn de gematerialiseerde weergaven gemaakt? Er waren weergaven waarin rechtstreeks werd geschreven \u2014 gegevens werden aan ruwe data toegevoegd en in de views geschreven. Op een bepaald moment waren de gegevens daar niet helemaal correct; ze werden gedupliceerd, enzovoort. En er is een tweede deel van de tabel, waar ze er exact hetzelfde uitzien als de gematerialiseerde weergaven, dat wil zeggen, qua structuur zijn ze absoluut identiek. Af en toe tellen we de gegevens opnieuw en voegen we de gegevens zonder duplicaten toe aan die tabellen. <\/p>\n<p><\/p>\n<p>We gingen via de API \u2014 met ClickHouse zal dit handmatig niet werken. De API kijkt: wanneer heb ik de datum van de laatste toevoeging in de tabel, waar gegarandeerd al correcte berekende gegevens zijn, en dan maakt hij een verzoek naar de ene tabel en de andere tabel. Van de ene tabel selecteert hij gegevens tot een bepaald tijdstip, en van de andere haalt hij de gegevens op die nog niet zijn berekend. En dat werkt, maar niet met alleen ClickHouse.<\/p>\n<p><\/p>\n<p>Als u een API heeft \u2014 voor analisten, voor gebruikers \u2014 dan is dat in principe een optie. U telt altijd bij, u rekent altijd opnieuw. Dit kan eens per dag of op een ander moment gebeuren. U kiest zelf het bereik dat u niet nodig heeft en dat niet cruciaal is.<\/p>\n<p><\/p>\n<h2 id=\"anchordashboardanchorv-clickhouse-mnogo-logov-kak-ya-mogu-videt-vsyo-chto-proishodit-s-serverom-vnbspmomente\"><noindex><a rel=\"nofollow\" name=\"dashboard\"><\/a><\/noindex>In ClickHouse zijn er veel logs. Hoe kan ik alles zien wat er op het moment met de server gebeurt?<\/h2>\n<p><\/p>\n<blockquote><p>In ClickHouse zijn er een groot aantal verschillende logs, en dit aantal neemt toe. In de nieuwe versies zijn sommige daarvan zelfs standaard ingeschakeld, terwijl je in eerdere versies deze moest inschakelen bij een update. Desondanks worden het er steeds meer. Ik zou graag willen zien wat er op dit moment met mijn server gebeurt, misschien op een samenvoegdashboard. <\/p>\n<p>Heeft u binnen uw team ClickHouse, of in de teams van uw vrienden, iemand die een bepaalde functionaliteit van kant-en-klare dashboards ondersteunt, die deze logs als een kant-en-klaar product weergeven? Uiteindelijk is het gewoon leuk om logs in ClickHouse te bekijken, maar het zou geweldig zijn als dit al als een dashboard zou zijn voorbereid. Ik zou daar echt van genieten. <\/p><\/blockquote>\n<p>Er zijn dashboards, maar ze zijn niet gestandaardiseerd. Bij ons in het bedrijf gebruiken ongeveer 60 teams ClickHouse, en het meest 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 benodigde. Anderen hebben hun eigen. <\/p>\n<p><\/p>\n<p>Mijn collega's van 'Metrics' hebben hun eigen dashboard in Grafana, en ik heb het mijne op hun cluster. Daar bekijk ik dingen als cache hits voor de cache van registraties. En het wordt nog ingewikkelder omdat we verschillende tools gebruiken. Mijn dashboard heb ik gemaakt met een heel oude tool genaamd Graphite-web. Het is absoluut lelijk. En ik gebruik het nog steeds, hoewel Grafana waarschijnlijk handiger en mooier zou zijn. <\/p>\n<p><\/p>\n<p>De basiszaken in dashboards zijn hetzelfde. Dit zijn de systeemprestaties van de cluster: CPU, geheugen, schijf, netwerk. Andere omvatten het aantal gelijktijdige aanvragen, het aantal gelijktijdige merges, het aantal aanvragen per seconde, het maximale aantal stukjes voor MergeTree tabelpartities, de replicatielatentie, de grootte van de replicatiequeue, het aantal rijen dat per seconde is ingevoegd, en het aantal blokken dat per seconde is ingevoegd. Dit is alles wat niet uit logs, maar uit metrics komt.<\/p>\n<p><\/p>\n<p><strong>Vladimir Kolobaev:<\/strong> Aleksej, ik wil een beetje aanpassen. Er is Grafana. Grafana heeft een datasource, die ClickHouse is. Dit betekent dat ik vanuit Grafana direct aanvragen in ClickHouse kan doen. In ClickHouse is er een tabel met logs, die is voor iedereen hetzelfde. Ik wil in de uiteindelijke resultaten in Grafana naar deze logtabel verwijzen en de aanvragen zien die mijn server verwerkt. Het zou geweldig zijn om een dergelijk dashboard te hebben.<\/p>\n<p><\/p>\n<p>Ik heb het zelf in elkaar geflanst. Maar ik heb een vraag \u2014 als alles gestandaardiseerd is en Grafana door iedereen wordt gebruikt, waarom is er dan geen officieel dashboard bij 'Yandex'?<\/p>\n<p><\/p>\n<p><strong>Kirill Shvakov:<\/strong> In feite ondersteunt Altinity momenteel de datasource die aan ClickHouse is verbonden. En ik wil gewoon een richting geven waar te zoeken en wie te benaderen. Je kunt hen om uitleg vragen, want 'Yandex' doet uiteindelijk ClickHouse en niet de geschiedenis eromheen. Altinity is het belangrijkste bedrijf dat ClickHouse momenteel promoot. Ze zullen het niet in de steek laten, maar blijven het ondersteunen. Want in principe is het niet moeilijk om een dashboard op de Grafana-website te laden; je hoeft alleen maar te registreren en het te uploaden. <\/p>\n<p><\/p>\n<p><strong>Alexey Milovidov:<\/strong> Het afgelopen jaar zijn er veel mogelijkheden toegevoegd aan ClickHouse voor het profileren van queries. Er zijn metrics voor elke query met betrekking tot resourcegebruik. En heel recent is er een nog laagdrempeliger queryprofiler toegevoegd, waarmee je kunt zien waar elke milliseconde van de query naartoe gaat. Maar om deze functionaliteit te gebruiken, moet ik de consoleclient openen en de query typen die ik steeds vergeet. Ik heb het ergens opgeslagen, maar ik vergeet telkens waar precies. <\/p>\n<p><\/p>\n<p>Ik zou willen dat er een tool was waarin simpelweg staat: dit zijn uw zware queries, gegroepeerd op querytypes. Klik op een van hen, en dan zou me verteld worden dat hij om deze redenen zwaar is. Op dit moment is er geen oplossing voor. Het is echt vrij vreemd dat wanneer mensen me vragen: \"Zijn er kant-en-klare dashboards voor Grafana?\", ik zeg: \"Ga naar de Grafana-website, daar is een community 'Dashboards', en daar is een dashboard van Dima, er is een dashboard van Kostya. Wat dat is, weet ik niet, ik heb het zelf niet gebruikt.\"<\/p>\n<p><\/p>\n<h2 id=\"anchorzenanchorkak-vozdeystvovat-na-merdzhi-chtoby-server-ne-padal-vnbspoom\"><noindex><a rel=\"nofollow\" name=\"zen\"><\/a><\/noindex>Hoe be\u00efnvloed je de merges zodat de server niet in OOM valt?<\/h2>\n<p><\/p>\n<blockquote><p>Ik heb een tabel, en in de tabel is er slechts \u00e9\u00e9n partitie, het is een ReplacingMergeTree. Ik schrijf er al vier jaar lang gegevens in. Ik moest een alter uitvoeren en enkele gegevens verwijderen.<\/p>\n<p>Ik deed dit, en tijdens de verwerking van deze query werd al het geheugen op alle servers in het cluster opgegeten, en alle servers in het cluster gingen gezamenlijk in OOM. Daarna kwamen ze samen weer online, begonnen de merge van dezelfde operatie uit te voeren, deze gegevensblok, en vielen weer in OOM. Daarna kwamen ze weer online en vielen opnieuw. En dit hield maar niet op.<\/p>\n<p>Het bleek dat dit in feite een bug was die de jongens hebben opgelost. Dat is geweldig, heel erg bedankt. Maar de smaak blijft wel hangen. En nu, wanneer ik denk aan het doen van een merge in de tabel, komt de vraag bij me op \u2014 waarom kan ik niet op de een of andere manier invloed uitoefenen op deze merges? Bijvoorbeeld, hen beperken op het aantal vereiste RAM, of in principe op het aantal dat deze tabel specifiek zal verwerken.<\/p>\n<p>Ik heb een tabel genaamd \"Metrics\", en verwerk deze alsjeblieft met twee threads. Geen need om tien of vijf merges parallel te cre\u00ebren, doe het met twee. Ik denk dat twee genoeg RAM voor mij zal hebben, maar voor het verwerken van tien kan dat misschien niet voldoende zijn. Waarom blijft de angst bestaan? Omdat de tabel groeit, en ooit zal ik in een situatie komen waarin ik niet alleen door een bug, maar ook doordat de gegevens in zo'n grote hoeveelheid zullen veranderen, gewoon niet genoeg RAM op de server heb. En dan zal de server in OOM gaan bij de merge. Bovendien kan ik de mutatie annuleren, maar de merges niet.<\/p><\/blockquote>\n<p>Weet je, bij merges zal de server niet in OOM gaan, omdat bij een merge alleen het benodigde geheugen voor een klein gegevensbereik wordt gebruikt. Dus het zal goed gaan, ongeacht de hoeveelheid data.<\/p>\n<p><\/p>\n<p><strong>Vladimir Kolobaev:<\/strong> Ok\u00e9. Hier is het geval, nadat ze de bugfix hebben gedaan, heb ik de nieuwe versie gedownload en op een andere, kleinere tabel met veel partities een soortgelijke operatie uitgevoerd. En tijdens de merge was er ongeveer 100 Gb RAM op de server verbruikt. Ik had 150 in gebruik, 100 is verbruikt, en er bleef een buffer van 50 Gb over, dus ik viel niet in OOM.<\/p>\n<p><\/p>\n<p>Wat beschermt me op dit moment tegen OOM, als het echt 100 Gb RAM verbruikt? Hoe te handelen als ineens het RAM tijdens de merges opraakt?<\/p>\n<p><\/p>\n<p><strong>Alexey Milovidov:<\/strong> Er is een probleem dat het geheugenverbruik tijdens merges niet beperkt is. Een ander probleem is dat als er een merge is gepland, deze moet worden uitgevoerd omdat deze in het replicatielog is vastgelegd. Het replicatielog bevat de acties die nodig zijn om de replica in een consistente toestand te brengen. Als je geen handmatige handelingen uitvoert die deze replicatielog terugdraaien, moet de merge uiteindelijk worden uitgevoerd, hoe dan ook.<\/p>\n<p><\/p>\n<p>Natuurlijk zou het nuttig zijn om een geheugenlimiet te hebben die 'voor de zekerheid' beschermt tegen OOM. Het zal de merge niet helpen om succesvol te zijn; deze zal opnieuw beginnen, een bepaalde drempel bereiken, een uitzondering gooien en dan opnieuw beginnen \u2014 daar komt niets goeds uit. Maar in principe zou het nuttig zijn om deze beperking in te voeren.<\/p>\n<p><\/p>\n<h2 id=\"anchorgoanchorkak-budet-proishodit-razrabotka-golang-drayvera-dlya-clickhouse\"><noindex><a rel=\"nofollow\" name=\"go\"><\/a><\/noindex>Hoe zal de ontwikkeling van de Golang-driver voor ClickHouse plaatsvinden?<\/h2>\n<p><\/p>\n<blockquote><p>De Golang-driver, geschreven door Kirill Shvakov, wordt nu officieel ondersteund door het ClickHouse-team. Hij <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/ClickHouse\/clickhouse-go\">is in de ClickHouse-repository,<\/a><\/noindex>en hij is nu groot en echt.<\/p>\n<p>Een kleine opmerking. Er is een geweldige en door iedereen geliefde opslag van normale vormen van oneindige orde \u2014 dat is Vertica. Zij hebben ook hun eigen offici\u00eble 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\u00eble driver lijkt door het systeem \u2018nippel\u2019 te worden gedaan \u2014 je schrijft hen een issue, en het hangt eeuwig.<\/p>\n<p>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? <\/p><\/blockquote>\n<p><strong>Kirill Shvakov:<\/strong> Ten eerste \u2014 hoe alles bureaucratisch is geregeld. Dit punt is niet besproken, dus ik heb er geen antwoord op.<\/p>\n<p><\/p>\n<p>Om de vraag over het issue te beantwoorden, is een korte geschiedenis van de driver nodig. Ik werkte in een bedrijf met een enorme hoeveelheid data. Dit was een advertentieplatform met een groot aantal gebeurtenissen die ergens opgeslagen moesten worden. En op een gegeven moment verscheen ClickHouse. We hebben data daarheen gestuurd, en in eerste instantie ging alles goed, maar daarna viel ClickHouse uit. Op dat moment besloten we dat we het niet nodig hadden. <\/p>\n<p><\/p>\n<p>Een jaar later keerden we terug naar het idee om ClickHouse te gebruiken, en we moesten op een of andere manier data naar daar schrijven. De uitgangssituatie was zo \u2014 de hardware was erg zwak, middelen waren schaars. Maar we werkten altijd zo en dus keken we naar het native protocol.<\/p>\n<p><\/p>\n<p>Aangezien we op Go werkten, was het duidelijk dat we een driver voor Go nodig hadden. Ik werkte er praktisch fulltime aan \u2014 het was mijn werktaak. Tot een bepaald moment hebben we het ontwikkeld, en in principe verwachtte niemand dat iemand anders het zou gebruiken. Toen kwam CloudFlare met precies dezelfde problematiek, en een tijdje werkten we heel goed samen omdat zij dezelfde taken hadden. We deden dit zowel in ClickHouse zelf als in de driver. <\/p>\n<p><\/p>\n<p>Op een bepaald moment ben ik gewoon gestopt met het ermee bezig zijn, omdat mijn activiteit met betrekking tot ClickHouse en mijn werk een beetje veranderd zijn. Daarom worden issues niet gesloten. Af en toe committen mensen iets in de repository omdat ze zelf iets nodig hebben. Dan kijk ik naar de pull request en soms pas ik zelfs iets aan, maar dat komt zelden voor.<\/p>\n<p><\/p>\n<p>Ik wil terugkomen op de driver. Een paar jaar geleden, toen dit allemaal begon, was ClickHouse ook anders en had het andere mogelijkheden. Tegenwoordig hebben we een idee hoe we de driver kunnen herontwerpen, zodat het goed is. Als dit gebeurt, zal versie 2 in ieder geval incompatibel zijn vanwege de opgebouwde hacks. <\/p>\n<p><\/p>\n<p>Hoe we dit kunnen organiseren, weet ik niet. Ik zelf heb niet zo veel tijd. Als er mensen zijn die de driver verder willen ontwikkelen, kan ik hen helpen en vertellen wat te doen. Maar actieve deelname van \u2018Yandex\u2019 aan de ontwikkeling van het project is vooralsnog niet besproken. <\/p>\n<p><\/p>\n<p><strong>Alexey Milovidov:<\/strong> Eigenlijk is er voorlopig geen bureaucratie rondom deze drivers. Het enige is dat ze zijn ondergebracht in een offici\u00eble organisatie, wat betekent dat deze driver wordt erkend als de standaard oplossing voor Go. Er zijn andere drivers, maar die zijn apart. <\/p>\n<p><\/p>\n<p>Intern hebben wij geen ontwikkeling voor deze drivers. De vraag is of we iemand kunnen aannemen die niet specifiek voor deze driver werkt, maar voor de ontwikkeling van alle community-drivers, of dat we iemand van buitenaf kunnen vinden. <\/p>\n<p><\/p>\n<h2 id=\"anchorlazy-loadanchorvneshniy-slovar-ne-podnimaetsya-posle-perezagruzki-snbspvklyuchennoy-nastroykoy-lazy_load-chto-delat\"><noindex><a rel=\"nofollow\" name=\"lazy-load\"><\/a><\/noindex>De externe woordenlijst wordt niet geladen na een herstart met de instelling lazy_load ingeschakeld. Wat te doen?<\/h2>\n<p><\/p>\n<blockquote><p>Wij hebben de instelling lazy_load ingeschakeld, en na het herstarten van de server wordt de woordenlijst niet automatisch geladen. Hij wordt alleen geladen wanneer een gebruiker toegang heeft tot deze woordenlijst. En bij de eerste toegang geeft het een foutmelding. Is het mogelijk om woordenlijsten automatisch te laden met ClickHouse, of moeten we altijd zelf de gereedheid ervan controleren, zodat gebruikers geen foutmeldingen krijgen?<\/p>\n<p>Misschien hebben we een oude versie van ClickHouse, waardoor de woordenlijst niet automatisch werd geladen. Is dat mogelijk?<\/p><\/blockquote>\n<p>Allereerst kunnen woordenlijsten geforceerd worden geladen met behulp van een query. <strong>system reload dictionaries<\/strong>Ten eerste, over de fout \u2014 als het woordenboek al is geladen, zullen de verzoeken werken met de gegevens die zijn geladen. Als het woordenboek nog niet is geladen, zal het worden geladen tijdens het verzoek.<\/p>\n<p><\/p>\n<p>Voor zware woordenboeken is dit niet heel handig. Bijvoorbeeld, je moet een miljoen rijen uit MySQL ophalen. Iemand doet een eenvoudige select, maar die select zal wachten op die miljoen rijen. Hier zijn twee oplossingen. De eerste is om lazy_load uit te schakelen. De tweede is, wanneer de server opstart, voordat je belasting op hem legt,\u00a0maak een <strong>system reload dictionary<\/strong> of voer gewoon een verzoek uit dat het woordenboek gebruikt. Dan zal het woordenboek worden geladen. Je moet zelf de beschikbaarheid van de woordenboeken met de instelling lazy_load inschakelen, omdat ClickHouse ze niet automatisch ophaalt.<\/p>\n<p><\/p>\n<p>Op de laatste vraag is het antwoord: of de versie is oud, of het moet worden gedebugd. <\/p>\n<p><\/p>\n<h2 id=\"anchorreload-dictionariesanchorkak-byt-snbsptem-chto-system-reload-dictionaries-ne-podgruzhaet-ni-odin-iznbspmnozhestva-slovarey-esli-hotya-by-odin-iznbspnih-padaet-snbsposhibkoy\"><noindex><a rel=\"nofollow\" name=\"reload-dictionaries\"><\/a><\/noindex>Hoe om te gaan met het feit dat system reload dictionaries geen van de vele woordenboeken laadt als er ten minste \u00e9\u00e9n met een fout faalt?<\/h2>\n<p><\/p>\n<blockquote><p>Er is nog een vraag over system reload dictionaries. We hebben twee woordenboeken \u2014 \u00e9\u00e9n laadt niet, de andere laadt wel. System reload dictionaries laadt in dit geval geen enkel woordenboek, en we moeten dit specifiek laden op basis van de naam met behulp van system reload dictionary. Heeft dit ook te maken met de versie van ClickHouse?<\/p><\/blockquote>\n<p>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 <strong>system reload dictionaries<\/strong>, update en we hopen dat het in de betere richting verandert.<\/p>\n<p><\/p>\n<h2 id=\"anchorconnectionanchorest-li-sposob-konfigurirovat-rekvizity-vnbspkonfige-clickhouse-no-ne-svetit-ih-prinbsposhibkah\"><noindex><a rel=\"nofollow\" name=\"connection\"><\/a><\/noindex>Is there a way to configure the credentials in the ClickHouse config without exposing them in case of errors?<\/h2>\n<p><\/p>\n<blockquote><p>De volgende vraag is over fouten gerelateerd aan het woordenboek, namelijk de referenties. We hebben de verbindingsreferenties in de ClickHouse-configuratie voor het woordenboek ingesteld, en bij een fout krijgen we deze referenties en het wachtwoord in het antwoord. <\/p>\n<p>We hebben deze fout opgelost door de referenties in de configuratie van de ODBC-driver te plaatsen. Is er een manier om de referenties in de ClickHouse-configuratie op te geven, maar deze referenties niet zichtbaar te maken bij fouten?<\/p><\/blockquote>\n<p>Hier is de oplossing inderdaad om deze credentials in odbc.ini op te geven, en in ClickHouse alleen de ODBC Data Source Name te vermelden. Voor de andere bronnen van woordenboeken zal dit niet het geval zijn \u2014 noch voor het woordenboek met MySQL, noch voor de andere zou je het wachtwoord bij een foutmelding moeten zien. Voor ODBC zal ik ook kijken \u2014 als dat er is, moet dat gewoon worden verwijderd.<\/p>\n<p><\/p>\n<h2 id=\"anchorzoom-backgroundsanchorbonus-fony-dlya-zuma-snbspposidelok\"><noindex><a rel=\"nofollow\" name=\"zoom-backgrounds\"><\/a><\/noindex>Bonus: backgrounds for Zoom from meetings<\/h2>\n<p><\/p>\n<p>Door op de afbeelding te klikken, worden bonusachtergronden met ontmoetingen geopend voor de meest volhardende lezers. We blussen de brand samen met de mascottes van Avito-technologie\u00ebn, overleggen met collega's uit de systeembeheerderkamer of de oldschool computerclub, en houden dagelijks onze vergaderingen onder de brug tegen de achtergrond van graffiti.<\/p>\n<p><\/p>\n<p><noindex><a rel=\"nofollow\" href=\"http:\/\/amp.gs\/KvUr\"><img decoding=\"async\" alt=\"ClickHouse voor gevorderde gebruikers in vragen en antwoorden\" src=\"\/wp-content\/uploads\/2020\/05\/38b2ea076283285d934913c395863eb1.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><\/p>\n<p>Bron: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/avito\/blog\/500678\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0412 \u0430\u043f\u0440\u0435\u043b\u0435 \u0438\u043d\u0436\u0435\u043d\u0435\u0440\u044b \u0410\u0432\u0438\u0442\u043e \u0441\u043e\u0431\u0438\u0440\u0430\u043b\u0438\u0441\u044c \u043d\u0430&nbsp;\u043e\u043d\u043b\u0430\u0439\u043d-\u043f\u043e\u0441\u0438\u0434\u0435\u043b\u043a\u0438 \u0441 \u0433\u043b\u0430\u0432\u043d\u044b\u043c \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u043e\u043c ClickHouse \u0410\u043b\u0435\u043a\u0441\u0435\u0435\u043c \u041c\u0438\u043b\u043e\u0432\u0438\u0434\u043e\u0432\u044b\u043c \u0438 \u041a\u0438\u0440\u0438\u043b\u043b\u043e\u043c \u0428\u0432\u0430\u043a\u043e\u0432\u044b\u043c, Golang-\u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u043e\u043c \u0438\u0437&nbsp;\u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 Integros. \u041e\u0431\u0441\u0443\u0436\u0434\u0430\u043b\u0438, \u043a\u0430\u043a \u043c\u044b \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u043c \u0441\u0438\u0441\u0442\u0435\u043c\u0443 \u0443\u043f\u0440\u0430\u0432\u043b\u0435\u043d\u0438\u044f \u0431\u0430\u0437\u0430\u043c\u0438 \u0434\u0430\u043d\u043d\u044b\u0445 \u0438 \u043a\u0430\u043a\u0438\u0435 \u0441\u043b\u043e\u0436\u043d\u043e\u0441\u0442\u0438 \u0443&nbsp;\u043d\u0430\u0441 \u0432\u043e\u0437\u043d\u0438\u043a\u0430\u044e\u0442. \u041f\u043e&nbsp;\u043c\u043e\u0442\u0438\u0432\u0430\u043c \u0432\u0441\u0442\u0440\u0435\u0447\u0438 \u043c\u044b \u0441\u043e\u0431\u0440\u0430\u043b\u0438 \u0441\u0442\u0430\u0442\u044c\u044e \u0441&nbsp;\u043e\u0442\u0432\u0435\u0442\u0430\u043c\u0438 \u044d\u043a\u0441\u043f\u0435\u0440\u0442\u043e\u0432 \u043d\u0430&nbsp;\u043d\u0430\u0448\u0438 \u0438 \u0437\u0440\u0438\u0442\u0435\u043b\u044c\u0441\u043a\u0438\u0435 \u0432\u043e\u043f\u0440\u043e\u0441\u044b \u043f\u0440\u043e&nbsp;\u0431\u044d\u043a\u0430\u043f\u044b, \u0440\u0435\u0448\u0430\u0440\u0434\u0438\u043d\u0433 \u0434\u0430\u043d\u043d\u044b\u0445, \u0432\u043d\u0435\u0448\u043d\u0438\u0435 \u0441\u043b\u043e\u0432\u0430\u0440\u0438, Golang-\u0434\u0440\u0430\u0439\u0432\u0435\u0440 \u0438 \u043e\u0431\u043d\u043e\u0432\u043b\u0435\u043d\u0438\u0435 \u0432\u0435\u0440\u0441\u0438\u0439 ClickHouse. \u041e\u043d\u0430 \u043c\u043e\u0436\u0435\u0442 \u0431\u044b\u0442\u044c [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":80776,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-80775","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.3 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0412 \u0430\u043f\u0440\u0435\u043b\u0435 \u0438\u043d\u0436\u0435\u043d\u0435\u0440\u044b \u0410\u0432\u0438\u0442\u043e \u0441\u043e\u0431\u0438\u0440\u0430\u043b\u0438\u0441\u044c \u043d\u0430 \u043e\u043d\u043b\u0430\u0439\u043d-\u043f\u043e\u0441\u0438\u0434\u0435\u043b\u043a\u0438 \u0441 \u0433\u043b\u0430\u0432\u043d\u044b\u043c \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u043e\u043c ClickHouse \u0410\u043b\u0435\u043a\u0441\u0435\u0435\u043c \u041c\u0438\u043b\u043e\u0432\u0438\u0434\u043e\u0432\u044b\u043c \u0438 \u041a\u0438\u0440\u0438\u043b\u043b\u043e\u043c \u0428\u0432\u0430\u043a\u043e\u0432\u044b\u043c, Golang-\u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u043e\u043c \u0438\u0437 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 Integros.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/clickhouse-dlya-prodvinutyh-polzovatelej-v-voprosah-i-otvetah\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"nl_NL\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47ClickHouse \u0434\u043b\u044f \u043f\u0440\u043e\u0434\u0432\u0438\u043d\u0443\u0442\u044b\u0445 \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0435\u0439 \u0432 \u0432\u043e\u043f\u0440\u043e\u0441\u0430\u0445 \u0438 \u043e\u0442\u0432\u0435\u0442\u0430\u0445 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0412 \u0430\u043f\u0440\u0435\u043b\u0435 \u0438\u043d\u0436\u0435\u043d\u0435\u0440\u044b \u0410\u0432\u0438\u0442\u043e \u0441\u043e\u0431\u0438\u0440\u0430\u043b\u0438\u0441\u044c \u043d\u0430 \u043e\u043d\u043b\u0430\u0439\u043d-\u043f\u043e\u0441\u0438\u0434\u0435\u043b\u043a\u0438 \u0441 \u0433\u043b\u0430\u0432\u043d\u044b\u043c \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u043e\u043c ClickHouse \u0410\u043b\u0435\u043a\u0441\u0435\u0435\u043c \u041c\u0438\u043b\u043e\u0432\u0438\u0434\u043e\u0432\u044b\u043c \u0438 \u041a\u0438\u0440\u0438\u043b\u043b\u043e\u043c \u0428\u0432\u0430\u043a\u043e\u0432\u044b\u043c, Golang-\u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u043e\u043c \u0438\u0437 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 Integros.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/clickhouse-dlya-prodvinutyh-polzovatelej-v-voprosah-i-otvetah\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-05-08T11:42:47+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-05-08T11:42:47+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47ClickHouse voor geavanceerde gebruikers in vragen en antwoorden | ProHoster","description":"In april kwamen de ingenieurs van Avito online bijeen met de chief developer van ClickHouse, Alexey Milovidov, en Kirill Shvakov, een Golang-ontwikkelaar van Integros.","canonical_url":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/clickhouse-dlya-prodvinutyh-polzovatelej-v-voprosah-i-otvetah","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"nl_NL","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47ClickHouse \u0434\u043b\u044f \u043f\u0440\u043e\u0434\u0432\u0438\u043d\u0443\u0442\u044b\u0445 \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0435\u0439 \u0432 \u0432\u043e\u043f\u0440\u043e\u0441\u0430\u0445 \u0438 \u043e\u0442\u0432\u0435\u0442\u0430\u0445 | ProHoster","og:description":"\u0412 \u0430\u043f\u0440\u0435\u043b\u0435 \u0438\u043d\u0436\u0435\u043d\u0435\u0440\u044b \u0410\u0432\u0438\u0442\u043e \u0441\u043e\u0431\u0438\u0440\u0430\u043b\u0438\u0441\u044c \u043d\u0430 \u043e\u043d\u043b\u0430\u0439\u043d-\u043f\u043e\u0441\u0438\u0434\u0435\u043b\u043a\u0438 \u0441 \u0433\u043b\u0430\u0432\u043d\u044b\u043c \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u043e\u043c ClickHouse \u0410\u043b\u0435\u043a\u0441\u0435\u0435\u043c \u041c\u0438\u043b\u043e\u0432\u0438\u0434\u043e\u0432\u044b\u043c \u0438 \u041a\u0438\u0440\u0438\u043b\u043b\u043e\u043c \u0428\u0432\u0430\u043a\u043e\u0432\u044b\u043c, Golang-\u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u043e\u043c \u0438\u0437 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 Integros.","og:url":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/clickhouse-dlya-prodvinutyh-polzovatelej-v-voprosah-i-otvetah","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-05-08T11:42:47+00:00","article:modified_time":"2020-05-08T11:42:47+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"80775","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 16:11:22","updated":"2022-09-28 05:48:13","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/80775","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/comments?post=80775"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/80775\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media\/80776"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media?parent=80775"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/categories?post=80775"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/tags?post=80775"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}