I april samlades ingenjörerna frÄn Avito för online-möten med huvudutvecklaren av ClickHouse, Alexey Milovidov, och Kirill Shvakov, en Golang-utvecklare frÄn företaget Integros. De diskuterade hur vi anvÀnder databashanteringssystemet och vilka utmaningar vi möter.
Baserat pÄ mötet har vi sammanstÀllt en artikel med experternas svar pÄ vÄra och publikens frÄgor om sÀkerhetskopiering, omstrukturering av data, externa ordböcker, Golang-drivrutinen och versionuppdatering av ClickHouse. Den kan vara anvÀndbar för utvecklare som redan aktivt arbetar med Yandex DB och Àr intresserade av dess nuvarande och framtida tillstÄnd. Responses from Alexey Milovidov are provided by default unless otherwise stated.
Varning, det finns mycket text nedanför. Vi hoppas att innehÄllet med frÄgorna hjÀlper er att orientera er.
InnehÄll
Om du inte vill lÀsa texten kan du titta pÄ inspelningen av mötena . Timestamps finns i den första kommentaren under videon.
ClickHouse uppdateras stÀndigt, men vÄra data uppdateras inte. Vad ska vi göra med det?
ClickHouse uppdateras stÀndigt, men vÄra data som har behandlats med optimize final uppdateras inte och ligger i sÀkerhetskopior.
Anta att vi har stött pÄ ett problem och att data har gÄtt förlorad. Vi bestÀmde oss för att ÄterhÀmta oss, och det visade sig att de gamla partitionerna som ligger pÄ sÀkerhetskopiserverna mycket starkt avviker frÄn den version av ClickHouse som anvÀnds för tillfÀllet. Vad ska man göra i en sÄdan situation, och Àr det möjligt?
Situationen dÀr du ÄterstÀller data frÄn sÀkerhetskopian i gammalt format, och de nyare versionerna inte kan ansluta, Àr omöjlig. Vi ser till att datformatet i ClickHouse alltid förblir bakÄtkompatibelt. Detta Àr mycket viktigare Àn bakÄtkompatibilitet med funktionaliteten, om beteendet hos en sÀllan anvÀnd funktion har Àndrats. De data som lagras pÄ disk ska alltid kunna lÀsas av den nya versionen av ClickHouse. Detta Àr en regel.
Vilka Àr de bÀsta metoderna för sÀkerhetskopiering av data frÄn ClickHouse just nu?
Hur ska man skapa sÀkerhetskopior med tanke pÄ att vi har operationer för optimize final, enorma databaser pÄ terabyte och data som uppdateras, lÄt oss sÀga, under de senaste tre dagarna, och dÀr efter sker ingen procedur med dem?
Vi kan skapa en egen lösning och skriva pÄ Bash: samla dessa sÀkerhetskopior pÄ ett sÀrskilt sÀtt. Kanske behöver vi inte göra nÄgot eget, utan cykeln Àr redan uppfunnen?
Först angÄende bÀsta praxis. Mina kollegor rekommenderar alltid i svar pÄ frÄgor om sÀkerhetskopior att pÄminna om tjÀnsten "Yandex.Cloud", dÀr denna uppgift redan har lösts. SÄ anvÀnd den om du har möjlighet.
Det finns ingen fullstÀndig lösning, hundra procent integrerad i ClickHouse, för sÀkerhetskopiering. Det finns nÄgra förberedelser som kan anvÀndas. För att fÄ en komplett lösning mÄste man antingen jobba lite manuellt eller skapa omslag i form av skript.
Jag börjar med de enklaste lösningarna och avslutar med de mest avancerade beroende pÄ datamÀngden och klusterstorleken. Ju större klustret Àr, desto mer komplicerad blir lösningen.
Om tabellen med data bara tar upp nÄgra gigabyte kan sÀkerhetskopiering göras sÄ hÀr:
- Spara tabellens definitioner, det vill sĂ€ga metadata â show create table.
- Gör en dump med hjĂ€lp av ClickHouse-klienten â select * from table till en fil. Som standard fĂ„r du en fil i TabSeparated-format. Om du vill ha det mer effektivt kan du anvĂ€nda Native-format.
Om datamÀngden Àr större tar sÀkerhetskopieringen mer tid och mycket utrymme. Detta kallas en logisk sÀkerhetskopiering, och den Àr inte kopplad till ClickHouse-formatet. Om den finns kan du i vÀrsta fall ta sÀkerhetskopian och ladda upp den i MySQL för ÄterstÀllning.
För mer avancerade fall har ClickHouse inbyggd möjlighet att skapa ögonblicksbilder av partitioner i det lokala filsystemet. Denna möjlighet Ă€r tillgĂ€nglig i form av en förfrĂ„gan alter table freeze partition. Eller helt enkelt alter table freeze â detta skapar en ögonblicksbild av hela tabellen.
Ăgonblicksbilden kommer att skapas konsekvent för en tabell pĂ„ en shard, det vill sĂ€ga att det Ă€r omöjligt att skapa en konsekvent ögonblicksbild av hela klustret pĂ„ detta sĂ€tt. Men för de flesta uppgifter finns det ingen sĂ„dan behov, och det Ă€r tillrĂ€ckligt att utföra förfrĂ„gan pĂ„ varje shard och fĂ„ en konsekvent ögonblicksbild. Den skapas i form av hardlinks och tar dĂ€rför ingen extra plats. Sedan kopierar du denna ögonblicksbild till sĂ€kerhetskopiservern eller det lagringsutrymme du anvĂ€nder för sĂ€kerhetskopior.
Att Ă„terstĂ€lla en sĂ„dan sĂ€kerhetskopia Ă€r ganska enkelt. För det första â skapa tabeller baserat pĂ„ de existerande tabelldefinitionerna. Sedan kopierar du de sparade ögonblicksbilderna av partitioner till Directory-Detached för de aktuella tabellerna och utför förfrĂ„gan attach partition. En sĂ„dan lösning Ă€r helt lĂ€mplig för de mest betydande datamĂ€ngderna.
Ibland behövs nĂ„got Ă€nnu mer imponerande â i de fallen nĂ€r du har tiotals eller till och med hundratals terabyte pĂ„ varje server och hundratals servrar. HĂ€r finns det en lösning som jag snappade upp frĂ„n kollegor pĂ„ "Yandex.Metrica". Jag skulle inte rekommendera detta till alla â lĂ€s och avgör om det passar dig eller inte.
Först behöver du skapa flera servrar med stora diskhyllor. DÀrefter ska du installera flera ClickHouse-servrar pÄ dessa servrar och konfigurera dem sÄ att de fungerar som ytterligare en replik för samma shardar. AnvÀnd sedan filsystemet pÄ dessa servrar eller nÄgot verktyg som möjliggör skapande av snapshots. Det finns tvÄ alternativ. Det första alternativet Àr LVM-snapshots, det andra alternativet Àr ZFS pÄ Linux.
Efter detta bör du skapa en snapshot varje dag, som kommer att ta upp en del utrymme. Naturligtvis, om data Àndras, kommer utrymmet att öka över tid. Denna snapshot kan du Äterskapa nÀr som helst, en nÄgot udda lösning. Dessutom mÄste du begrÀnsa dessa repliker i konfigurationen sÄ att de inte försöker bli ledare.
Kan man organisera kontrollerad fördröjning av repliker i kluster?
I Är planerar ni att göra val i ClickHouse. Kommer det att vara möjligt att organisera kontrollerad fördröjning av repliker? Vi skulle vilja anvÀnda den för att skydda oss mot negativa scenarier med alterningar och andra förÀndringar.
Ăr det möjligt att göra nĂ„gon form av rollback för alternativer? Till exempel, i den befintliga vallen, kan vi sĂ€ga att till denna punkt ska Ă€ndringar tillĂ€mpas, och frĂ„n denna punkt ska inga Ă€ndringar tillĂ€mpas?
Om ett team kommer in i vÄr kluster och bryter det, har vi en sorts replik med en timmes fördröjning dÀr vi kan sÀga att lÄt oss anvÀnda just den för tillfÀllet, men vi ska inte tillÀmpa de senaste tio minuters Àndringar dÀr?
Först om den kontrollerade fördröjningen av repliker. En sĂ„dan begĂ€ran har kommit frĂ„n anvĂ€ndare, och vi skapade ett issue pĂ„ GitHub med frĂ„gan: "Om nĂ„gon behöver detta, gilla det, ge det ett hjĂ€rta." Ingen gillade det, och frĂ„gan stĂ€ngdes. ĂndĂ„ kan man redan nu fĂ„ den möjligheten genom att konfigurera ClickHouse. Det Ă€r dock endast frĂ„n version 20.3.
ClickHouse kör stĂ€ndigt en fusion av data i bakgrunden â merge. NĂ€r merge Ă€r genomfört ersĂ€tts en viss uppsĂ€ttning datakluster med ett större kluster. Samtidigt fortsĂ€tter de tidigare dataklusterna att finnas kvar pĂ„ disken under en tid.
För det första lagras de tills det finns SELECT-frÄgor som anvÀnder dem, för att sÀkerstÀlla icke-blockerande drift. SELECT-frÄgor kan lugnt lÀsa frÄn de gamla klustren.
För det andra finns det ocksĂ„ en tidsgrĂ€ns â de gamla dataklusterna ligger pĂ„ disken i Ă„tta minuter. Denna Ă„tta minuter kan justeras och till och med göras till en dag. Det kommer att kosta diskutrymme: beroende pĂ„ datatrafiken kan det hĂ€nda att datan under den senaste dagen inte bara dubbleras, utan kan bli fem gĂ„nger större. Men du kan vid allvarliga problem stoppa ClickHouse-servern och ta itu med det.
Nu uppstÄr frÄgan om hur detta skyddar mot ALTER-kommandon. HÀr mÄste man titta djupare, för i Àldre versioner av ClickHouse fungerade ALTER sÄ att det helt enkelt Àndrade kluster direkt. Det finns ett datakluster med vissa filer, och vi gör till exempel ALTER DROP COLUMN. DÄ tas den kolumnen fysiskt bort frÄn alla kluster.
Men frĂ„n och med version 20.3 har mekanismen för ALTERs Ă€ndrats helt, och nu Ă€r datakluster alltid oförĂ€nderliga. De förĂ€ndras inte alls â ALTERs fungerar nu pĂ„ ett sĂ€tt som liknar merges. IstĂ€llet för att Ă€ndra klustret pĂ„ plats skapar vi ett nytt. I det nya klustret blir de filer som inte har förĂ€ndrats hĂ„rd-lĂ€nkar, och om vi har tagit bort en kolumn sĂ„ kommer den helt enkelt att saknas i det nya klustret. Det gamla klustret tas bort automatiskt efter Ă„tta minuter, och hĂ€r kan vi justera instĂ€llningarna som nĂ€mnts tidigare.
Detsamma gÀller för ALTERs av typen mutationer. NÀr du gör ALTER DELETE eller ALTER UPDATE, sÄ Àndrar det inte klustret utan skapar ett nytt. Och sedan tas det gamla bort.
Vad ska man göra om tabellens struktur har Àndrats?
Hur ÄterstÀller man en backup som gjordes med det gamla schemat? Och den andra frÄgan handlar om fallet med snapshots och filsystemet. GÄr Btrfs bra istÀllet för ZFS pÄ Linux LVM?
Om du gör attach partition Om partitionerna har en annan struktur kommer ClickHouse att meddela att det inte gÄr. Lösningen Àr följande. Först mÄste du skapa en temporÀr tabell av typen MergeTree med den gamla strukturen, koppla dit data med hjÀlp av attach och göra en alter-frÄga. DÀrefter kan du antingen kopiera eller flytta dessa data och göra attach igen, eller anvÀnda en frÄga alter table move partition.
Nu till den andra frĂ„gan â Ă€r det möjligt att anvĂ€nda Btrfs? Först, om du har LVM, rĂ€cker det med LVM-snapshots, och filsystemet kan vara ext4, det spelar ingen roll. NĂ€r det gĂ€ller Btrfs beror allt pĂ„ din erfarenhet av dess anvĂ€ndning. Det Ă€r ett moget filsystem, men det finns fortfarande en del tveksamheter om hur allt kommer att fungera i praktiken i ett specifikt scenario. Jag skulle inte rekommendera att anvĂ€nda det om du inte har Btrfs i produktion.
Vilka Àr de aktuella bÀsta metoderna för omstrukturering av data?
FrÄgan om ompartitionering Àr komplex och mÄngfacetterad. HÀr kan man svara pÄ flera sÀtt. Man kan gÄ in pÄ ett sÀtt och sÀga att ClickHouse inte har inbyggd funktionalitet för ompartitionering. Men jag Àr rÀdd att det svaret inte kommer att behaga nÄgon. DÀrför kan man se det pÄ ett annat sÀtt och sÀga att ClickHouse har mÄnga sÀtt att ompartitionera data.
Om det börjar ta slut pÄ utrymme i klustret eller det inte klarar av belastningen, kan du lÀgga till nya servrar. Men dessa servrar Àr som standard tomma, det finns inga data pÄ dem, och ingen belastning genereras. Du behöver omfördela data sÄ att de jÀmnt sprids över det nya, större klustret.
Det första sÀttet att göra detta Àr att kopiera en del av partitionerna till de nya servrarna med hjÀlp av en frÄga alter table fetch partition. Till exempel, om du hade partitioner per mÄnad, och du tar den första mÄnaden av 2017 och kopierar till en ny server, sedan kopierar du den tredje mÄnaden till en annan ny server. SÄ hÀr fortsÀtter du tills det blir mer eller mindre jÀmnt.
Flyttning kan endast göras för de partitioner som inte Àndras vid skrivning. För nya partitioner mÄste skrivning stÀngas av, eftersom deras flyttning inte Àr atomÀr. Annars fÄr du dubbletter eller luckor i datan. Trots detta Àr metoden praktisk och fungerar tillrÀckligt effektivt. De redan komprimerade partitionerna överförs över nÀtverket, vilket innebÀr att data inte komprimeras eller omkodas.
Denna metod har en nackdel, och den beror pÄ shardningsschemat; om ni har byggt in det i ert shardningsschema, vilken shardnyckel ni anvÀnde. I ert exempel, för fallet med mÀtningar, Àr shardnyckeln en hash frÄn vÀgen. NÀr ni gör en select i den distribuerade tabellen gÄr den direkt till alla kluster-sharder och hÀmtar data dÀrifrÄn.
Det betyder att det faktiskt inte spelar nĂ„gon roll för er vilken data som finns pĂ„ vilken shard. Huvudsaken Ă€r att data för en vĂ€g hamnar pĂ„ en shard, men vilken som helst Ă€r oviktig. I det hĂ€r fallet passar överföring av fĂ€rdiga partitioner bra eftersom ni vid select-förfrĂ„gningar ocksĂ„ â oavsett om det Ă€r före eller efter shardningen, tar emot fullstĂ€ndiga data.
Men det finns ocksÄ mer komplexa fall. Om ni pÄ applikationslogikens nivÄ bygger en speciell shardningsschema för att denna klient ligger pÄ en viss shard, kan förfrÄgan skickas direkt dit istÀllet för till den distribuerade tabellen. Eller om ni anvÀnder en relativt ny version av ClickHouse och har aktiverat instÀllningen optimize skip unused shards. I det fallet kommer uttrycket i where-sektionen att analyseras under select-förfrÄgan, och det kommer att berÀknas vilka sharder som mÄste nÄs enligt shardningsschemat. Detta fungerar under förutsÀttning att data Àr distribuerade i enlighet med detta shardningsschema. Om ni har flyttat dem manuellt kan överensstÀmmelsen förÀndras.
SÄ, detta Àr metod nummer ett. Jag vÀntar pÄ ert svar, om metoden passar eller om vi gÄr vidare.
Vladimir Kolobaev, lead system administrator pÄ Avito: Alexey, den metod du nÀmnde fungerar inte sÀrskilt bra nÀr man mÄste fördela belastningen, inklusive lÀsning. Vi kan ta en mÄnatlig partition och flytta föregÄende mÄnad till en annan nod, men nÀr förfrÄgan kommer gÀllande dessa data, kommer vi bara att belasta den. Och vi skulle vilja belasta hela klustret, eftersom annars kommer all lÀsningsbelastning under en tid att hanteras av tvÄ sharder.
Alexey Milovidov: Svaret hĂ€r Ă€r konstigt â ja, det Ă€r dĂ„ligt, men det kan fungera. Jag ska förklara hur. Det Ă€r vĂ€rt att titta pĂ„ belastningsscenariot som följer dina data. Om det handlar om övervakningsdata kan man nĂ€stan sĂ€kert sĂ€ga att den övervĂ€gande delen av förfrĂ„gningarna gĂ„r efter fĂ€rska data.
Du har installerat nya servrar, flyttat gamla partitioner, men ocksÄ Àndrat hur fÀrska data skrivs. FÀrska data kommer att spridas över hela klustret. SÄ redan efter fem minuter kommer förfrÄgningarna för de senaste fem minuterna att belasta klustret jÀmnt, efter en dag kommer förfrÄgningarna för dygnet att belasta klustret jÀmnt. TyvÀrr kommer förfrÄgningarna för föregÄende mÄnad bara att gÄ till en del av klustrets servrar.
Men ofta kommer du inte ha nĂ„gra förfrĂ„gningar specifikt för februari 2019. Troligtvis, om förfrĂ„gningarna gĂ„r tillbaka till 2019, sĂ„ handlar de om hela 2019 â om en stor tidsperiod, snarare Ă€n nĂ„got litet intervall. Och sĂ„dana förfrĂ„gningar kommer ocksĂ„ att kunna belasta klustret jĂ€mnt. Men i stort sett har du helt rĂ€tt i att det Ă€r en sĂ„dan ad hoc-lösning som inte sprider data helt jĂ€mnt.
Jag har ytterligare nÄgra punkter för att svara pÄ frÄgan. En av dem handlar om hur man frÄn början kan göra shardingschemat pÄ ett sÀtt sÄ att det blir mindre smÀrtsamt vid omsharding. Detta Àr inte alltid möjligt.
Till exempel, om du har övervakningsdata. Ăvervakningsdata vĂ€xer av tre skĂ€l. För det första â ackumuleringen av historiska data. För det andra â trafikökningen. Och för det tredje â ökningen av antalet saker som faller under övervakningen. Nya mikrotjĂ€nster och mĂ€tvĂ€rden dyker upp som behöver sparas.
Det Ă€r möjligt att den största tillvĂ€xten Ă€r kopplad till den tredje orsaken â det Ă€r en ökning av anvĂ€ndningen av övervakning. I sĂ„ fall Ă€r det vĂ€rt att titta pĂ„ belastningskaraktĂ€ren, vad de viktigaste förfrĂ„gningarna för select Ă€r. De viktigaste förfrĂ„gningarna för select kommer troligen att komma frĂ„n en viss undergrupp av mĂ€tvĂ€rden.
Till exempel, anvÀndningen av CPU pÄ vissa servrar av en viss tjÀnst. Det visar sig att det finns en viss delmÀngd av nycklar, dÀrifrÄn du hÀmtar dessa data. SjÀlva förfrÄgan efter dessa data Àr förmodligen ganska enkel och utförs pÄ nÄgra tiotals millisekunder. Det anvÀnds för övervakningstjÀnster, för dashboards. Jag hoppas jag förstÄr detta rÀtt.
Vladimir Kolobajev: Grejen Àr att vi ofta hÀnvisar till historiska data, eftersom vi i realtid jÀmför den aktuella situationen med historiska. För oss Àr det viktigt att ha snabb tillgÄng till stora datamÀngder, och ClickHouse hanterar detta utmÀrkt.
Du har helt rÀtt, de flesta lÀsfrÄgor upplever vi under det senaste dygnet, precis som alla övervakningssystem. Men samtidigt Àr belastningen pÄ historiska data ocksÄ ganska stor. Den kommer huvudsakligen frÄn varningssystemet, som var trettionde sekund gör en förfrÄgan till ClickHouse: "Ge mig data för de senaste sex veckorna. Och nu, bygg mig en glidande medelvÀrde av dessa, och lÄt oss jÀmföra det aktuella vÀrdet med historiska."
Jag vill sÀga att vi har en liten tabell för sÄdana mycket fÀrska förfrÄgningar, dÀr vi lagrar endast tvÄ dagars data, och de huvudsakliga frÄgorna gÄr till den. Till den större sharderade tabellen skickar vi bara stora historiska förfrÄgningar.
Alexey Milovidov: TyvÀrr gÀller det hÀr inte för ditt scenario, men jag kommer att berÀtta om tvÄ dÄliga och komplicerade shardingscheman som inte bör anvÀndas, men som anvÀnds av mina vÀnners tjÀnst.
Det finns ett huvudkluster med hĂ€ndelser frĂ„n "Yandex.Metrika". HĂ€ndelser Ă€r sidvisningar, klick och övergĂ„ngar. De flesta förfrĂ„gningar gĂ„r till en specifik webbplats. Du öppnar tjĂ€nsten "Yandex.Metrika", har en webbplats â avito.ru, gĂ„r in i rapporten, och det görs en förfrĂ„gan pĂ„ din webbplats.
Men det finns ocksĂ„ andra förfrĂ„gningar â analytiska och globala, som görs av interna analytiker. För sĂ€kerhets skull vill jag nĂ€mna att interna analytiker bara gör förfrĂ„gningar om "Yandex"-tjĂ€nster. Men Ă€ndĂ„ utgör till och med "Yandex"-tjĂ€nster en betydande del av alla data. Detta Ă€r förfrĂ„gningar inte om specifika rĂ€knare, utan om bredare filtrering.
Hur kan vi organisera data sÄ att den fungerar effektivt bÄde med en och flera rÀknare? Komplexiteten ligger ocksÄ i att antalet förfrÄgningar i ClickHouse-klustret "Metrics" Àr flera tusen per sekund. Samtidigt orkar inte en ensam ClickHouse-server med sÄdana icke-triviala förfrÄgningar, till exempel flera tusen per sekund.
Storleken pÄ klustret Àr över sex hundra servrar. Om vi bara strÀcker en distribuerad tabell över detta kluster och skickar dit flera tusen förfrÄgningar, sÄ blir det Ànnu vÀrre Àn att skicka dem till en enda server. à andra sidan avfÀrdar vi alternativet dÀr data Àr jÀmnt spritt och vi gör förfrÄgningar frÄn alla servrar.
Det finns ett diametralt motsatt alternativ. TÀnk om vi shardade data baserat pÄ webbplatser, och en förfrÄgan för en webbplats gÄr till en shard. Nu kan klustret hantera tio tusen förfrÄgningar per sekund, men pÄ en shard kan en enskild förfrÄgan gÄ för lÄngsamt. Den kommer inte lÀngre att kunna skalas upp i kapacitet. SÀrskilt om det Àr webbplatsen avito.ru. Jag avslöjar ingen hemlighet nÀr jag sÀger att Avito Àr en av de mest besökta webbplatserna i Ryssland. Att bearbeta den pÄ en shard skulle vara galenskap.
DÀrför Àr sharding-schemat utformat pÄ ett mer raffinerat sÀtt. Hela klustret Àr uppdelat i ett antal kluster som vi kallar lager. Inom varje kluster finns det frÄn ett tiotal till flera tiotals shards. Totalt finns det trettionio sÄdana kluster.
Hur skalas allt detta? Antalet kluster har inte förÀndrats - som det var trettionio för flera Är sedan, sÄ Àr det fortfarande. Men inom varje av dem ökar vi gradvis antalet shards efterhand som datamÀngden vÀxer. Och sharding-schemat i stort ser ut sÄ hÀr - uppdelningen i dessa kluster sker baserat pÄ webbplatser, och för att förstÄ vilken webbplats som hör till vilket kluster anvÀnds en separat metadatabas i MySQL. En webbplats gÄr till ett kluster. Inom det sker sharding baserat pÄ besökares identifikatorer.
Vid inspelning delar vi upp dem baserat pÄ resten frÄn divisionen av besökarens identifierare. Men nÀr en ny shard lÀggs till Àndras shardningsschemat, vi fortsÀtter att dela upp men vid resten av divisionen pÄ ett annat tal. Det innebÀr att en besökare faktiskt kan befinna sig pÄ flera servrar, och man kan inte rÀkna med det. Detta görs uteslutande för att data ska komprimeras bÀttre. Vid förfrÄgningar gÄr vi till den distribuerade tabellen som tittar pÄ klustret och kontaktar tiotals servrar. SÄ hÀr ser den knepiga schemat ut.
Men min berÀttelse skulle vara ofullstÀndig om jag inte nÀmnde att vi har övergett detta schema. I det nya schemat har vi Àndrat allt och kopierat all data med hjÀlp av clickhouse-copier.
I det nya schemat delas alla webbplatser in i tvÄ kategorier - stora och smÄ. Jag vet inte hur tröskeln valdes dÀr, men resultatet blev att stora webbplatser skrivs till ett kluster som har 120 shards med tre repliker i varje - det vill sÀga 360 servrar. Och shardningsschemat Àr sÄdant att varje förfrÄgan gÄr direkt till alla shards. Om du nu öppnar vilken sida som helst i rapporten för avito.ru i 'Yandex.Metrica', kommer förfrÄgan att gÄ till 120 servrar. Det finns fÄ stora webbplatser i Ryssland. Och förfrÄgningarna uppgÄr till inte ett tusental per sekund, utan till och med mindre Àn hundra. Detta hanteras utan problem av den distribuerade tabellen, vilken var och en behandlar 120 servrar.
Det andra klustret Àr för smÄ webbplatser. HÀr Àr shardningsschemat baserat pÄ webbplatsens identifierare, och varje förfrÄgan gÄr exakt till en shard.
ClickHouse har ett verktyg som heter clickhouse-copier. Kan ni berÀtta om det?
Jag sÀger direkt att denna lösning Àr mer skrymmande och nÄgot mindre effektiv. Fördelen Àr att den helt fördelar data enligt det schema som du anger. Men nackdelen med verktyget Àr att det inte genomför reshÀrdning. Det kopierar data frÄn ett kluster schema till ett annat kluster schema.
Detta innebÀr att för dess funktion mÄste du ha tvÄ kluster. De kan vara placerade pÄ samma servrar, men ÀndÄ kommer inte data att flyttas inkrementellt, utan kommer att kopieras.
Till exempel, var det fyra servrar, nu Àr det Ätta. Du skapar en ny Distributed-tabell pÄ alla servrar, nya lokala tabeller och kör clickhouse-copier, dÀr du anger hur den ska arbeta, att den ska lÀsa dÀrifrÄn, ta emot den nya shardingen och flytta datan dit. Och du kommer behöva plats pÄ de gamla servrarna som Àr 1,5 gÄnger större Àn vad som finns nu, eftersom de gamla datan mÄste stanna dÀr, och ovanpÄ det kommer hÀlften av dessa gamla data att komma dit. Om du har tÀnkt pÄ att datan behöver resharda och att det finns plats, sÄ Àr den hÀr metoden lÀmplig.
Hur Àr clickhouse-copier uppbyggd inuti? Den delar upp hela arbetet i en uppsÀttning uppgifter för att hantera en partition av en tabell pÄ en shard. Alla dessa uppgifter kan utföras parallellt, och clickhouse-copier kan köras pÄ olika maskiner i flera instanser, men det den gör för en partition Àr inget annat Àn insert select. Data lÀses, packas upp, omdistribueras, komprimeras igen, skrivs nÄgonstans och sorteras om. Detta Àr en tyngre lösning.
Ni hade en pilotversion som kallades omstrukturering. Vad hÀnde med den?
Ni hade en pilotgrej redan 2017 som kallades resharding. Det finns till och med ett alternativ i ClickHouse. SÄvitt jag förstÄr, sÄ flög den inte. Kan ni berÀtta varför det blev sÄ? Det verkar ju vara ganska aktuellt.
Hela problemet Ă€r att vid behov av att resharda data pĂ„ plats krĂ€vs en ganska komplex synkronisering för att göra det atomĂ€rt. NĂ€r vi började titta pĂ„ hur den synkroniseringen Ă€r uppbyggd, blev det tydligt att det fanns fundamentala problem. Och dessa fundamentala problem Ă€r inte bara teoretiska, utan visar sig omedelbart i praktiken genom att förklara mycket enkelt â inget fungerar.
Kan man slÄ samman alla delar av data innan man flyttar dem till lÄngsamma diskar?
FrÄgan om TTL med alternativet move to slow disk i samband med merge. Finns det nÄgot sÀtt, förutom via cron, att slÄ ihop alla bitar till en innan de flyttas till lÄngsamma diskar?
Svaret pĂ„ frĂ„gan om det gĂ„r att automatiskt klistra ihop alla bitar till en innan deras överföring â nej. Jag tror inte det Ă€r nödvĂ€ndigt. Man kan ocksĂ„ lĂ„ta bli att slĂ„ ihop alla delar till en, utan bara lita pĂ„ att de kommer att flyttas till lĂ„ngsamma diskar automatiskt.
Vi har tvĂ„ kriterier för överföringsregler. Den första Ă€r baserad pĂ„ fillnivĂ„n. Om den aktuella lagringsnivĂ„n har mindre Ă€n en viss procent ledigt utrymme, vĂ€ljer vi en del och flyttar den till en lĂ„ngsammare lagring. Mer exakt, inte en lĂ„ngsammare, utan nĂ€sta â som du konfigurerar.
Det andra kriteriet handlar om storlek. Det gÀller överföring av stora bitar. Du kan justera tröskeln för ledigt utrymme pÄ den snabba disken, sÄ att data automatiskt flyttas.
Hur migrerar man till nya versioner av ClickHouse om det inte gÄr att kontrollera kompatibiliteten i förvÀg?
Detta Àmne diskuteras regelbundet med hÀnsyn till olika versioner, och ÀndÄ. Hur sÀkert Àr det att uppgradera frÄn version 19.11 till 19.16 och till exempel frÄn 19.16 till 20.3? Hur bör man flytta till nya versioner utan möjlighet att i förvÀg kontrollera kompatibilitet i en sandlÄda?
HÀr finns nÄgra "gyllene" regler. Den första Àr . Den Àr stor, men det finns sÀrskilda punkter angÄende bakÄtkompatibla Àndringar. Man bör inte betrakta dessa punkter som röda flaggor. Vanligtvis handlar det om smÄ inkompatibiliteter som relaterar till viss grÀnsfunktionalitet som troligen inte anvÀnds av dig.
För det andra â om du inte har möjlighet att kontrollera kompatibilitet i en sandlĂ„da, och du vill uppgradera direkt i produktion, Ă€r rekommendationen att inte göra det. Först skapa en sandlĂ„da och kontrollera. Om du inte har nĂ„gon testmiljö, sĂ„ har du förmodligen inte ett sĂ„ stort företag, vilket betyder att du kan kopiera en del av data till din bĂ€rbara dator och pĂ„ den kontrollera att allt fungerar korrekt. Du kan till och med sĂ€tta upp flera repliker lokalt pĂ„ din maskin. Eller sĂ„ kan du sĂ€tta upp en ny version nĂ„gonstans i nĂ€rheten och ladda upp en del data dit â det vill sĂ€ga, skapa en improviserad testmiljö.
En annan regel Àr att inte uppgradera inom en vecka efter att en version har slÀppts pÄ grund av att man jagar buggar i produktionen och efterföljande snabba fixar. LÄt oss gÄ igenom versionsnumreringen av ClickHouse för att inte bli förvirrade.
Det finns en version 20.3.4. Siffran 20 betecknar Äret den slÀpptes - 2020. Ur ett innehÄllsmÀssigt perspektiv har detta ingen betydelse, sÄ vi kommer inte att fokusera pÄ det. Vidare - 20.3. Den andra siffran - i det hÀr fallet 3 - ökar vi varje gÄng vi slÀpper en version med nÄgon ny funktionalitet. Om vi vill lÀgga till en funktion i ClickHouse mÄste vi öka detta nummer. SÄ i version 20.4 kommer ClickHouse att fungera Ànnu bÀttre. Den tredje siffran - 20.3.4. HÀr Àr 4 antalet patchutgÄvor dÀr vi inte har lagt till nÄgra nya funktioner, men fixat vissa buggar. Och 4 betyder att vi har gjort detta fyra gÄnger.
Det Àr ingen idé att tro att detta Àr nÄgot hemskt. Vanligtvis kan anvÀndaren installera den senaste versionen, och den kommer att fungera utan nÄgra problem under ett Är. Men förestÀll dig att en viss funktion för att bearbeta bitmappar, som vÄra kinesiska kollegor la till, fÄr servern att falla om fel argument skickas. Vi Àr skyldiga att ÄtgÀrda detta. Vi kommer att slÀppa en ny patchversion och ClickHouse kommer att bli mer stabilt.
Om du har ClickHouse som körs i produktion, och en ny version av ClickHouse med extra funktioner slÀpps - till exempel 20.4.1 - skynda dig inte att installera den i produktion första dagen. Vad Àr egentligen behovet av den? Om du inte redan anvÀnder ClickHouse kan du installera den, och det kommer troligen att gÄ bra. Men om ClickHouse redan fungerar stabilt, sÄ hÄll koll pÄ patcharna och uppdateringarna - vilka problem vi ÄtgÀrdar.
Kirill Shvakov: Jag vill komplettera om testmiljöer. MÄnga Àr rÀdda för testmiljöer och tror av nÄgon anledning att om du har en vÀldigt stor ClickHouse-kluster, sÄ bör testmiljön vara minst lika stor eller Ätminstone tio gÄnger mindre. SÄ Àr inte fallet alls.
Jag kan sÀga utifrÄn min egen erfarenhet. Jag har ett projekt som anvÀnder ClickHouse. VÄr testmiljö för detta Àr en liten virtuell maskin i Hetzner för tjugo euro, dÀr absolut allt Àr installerat. För att göra detta har vi fullstÀndig automatisering med Ansible, sÄ det spelar egentligen ingen roll om vi kör pÄ faktiska servrar eller bara anvÀnder virtuella maskiner.
Vad kan göras? Det vore bra att i ClickHouse-dokumentationen inkludera ett exempel pĂ„ hur man sĂ€tter upp en liten klusterlokalt â i Docker, i LXC, kanske skapa en Ansible-playbook, eftersom olika mĂ€nniskor har olika deployment. Detta skulle förenkla mycket. NĂ€r du kan stĂ€lla upp en kluster pĂ„ fem minuter blir det mycket enklare att försöka förstĂ„ nĂ„got. Det Ă€r sĂ„ mycket mer bekvĂ€mt, eftersom att köra en produktionsversion som du inte har testat â det Ă€r en vĂ€g utan Ă„tervĂ€ndo. Ibland fungerar det, och ibland gör det inte. DĂ€rför Ă€r det dĂ„ligt att hoppas pĂ„ framgĂ„ng.
Maxim Kotyakov, senior backend engineer pĂ„ Avito: Jag vill lĂ€gga till lite om testmiljöerna som Ă€r ett av problemen för stora företag. Vi har en fullstĂ€ndig acceptanskluster för ClickHouse, som Ă€r en exakt kopia av produktionssystemen vad gĂ€ller datamodeller och instĂ€llningar. Denna kluster Ă€r implementerad i tillrĂ€ckligt seg kandidatcontainrar med minimala resurser. Vi skriver dit en viss procent av produktionsdata, lyckligtvis finns möjligheten att replikera strömmen i Kafka. Allt Ă€r synkroniserat och skalat â bĂ„de nĂ€r det gĂ€ller kapacitet och strömning, och i teorin ska det, under lika omstĂ€ndigheter, bete sig som produktion enligt metrik. Allt potentiellt explosivt testas först pĂ„ denna plattform och mognar i flera dagar innan det Ă€r klart. Men naturligtvis, denna lösning Ă€r dyr, tung och har vissa kostnader för underhĂ„ll.
Alexey Milovidov: Jag ska berĂ€tta vad testmiljön för vĂ„ra vĂ€nner frĂ„n Yandex.Metrica bestĂ„r av. En kluster hade över 600 servrar, en annan över 360, och det finns ocksĂ„ en tredje och flera kluster. Testmiljön för en av dem â det Ă€r helt enkelt tvĂ„ shardar med tvĂ„ repliker i varje. Varför tvĂ„ shardar? SĂ„ att det inte bara finns en. Och repliker för att det ska finnas. Bara en viss minimal mĂ€ngd som man kan ha rĂ„d med.
Denna testmiljö gör det möjligt att kontrollera funktionaliteten av frÄgorna och sÀkerstÀlla att inget har gÄtt seriöst fel. Men ofta uppstÄr problem av helt annan karaktÀr, dÀr allt fungerar, men det finns vissa smÄ Àndringar med lasten.
LÄt mig ge ett exempel. Vi beslutade att installera en ny version av ClickHouse. Den har blivit distribuerad till testmiljön, automatiserade tester har genomförts i Yandex.Metrica, som jÀmför data pÄ den gamla versionen och den nya, genom att köra hela pipelinen. Och naturligtvis, de gröna testerna frÄn vÄr CI. Annars skulle vi inte ens ha föreslagit denna version.
Allt Àr bra. Vi börjar rulla ut till produktion. Jag fÄr ett meddelande om att belastningen pÄ graferna har ökat flera gÄnger. Vi rullar tillbaka versionen. Jag tittar pÄ grafen och ser att belastningen verkligen har ökat flera gÄnger under rollout, och minskade tillbaka nÀr vi rullade ut. Sedan började vi rulla tillbaka versionen. Och belastningen ökade precis pÄ samma sÀtt och föll tillbaka pÄ samma sÀtt. SÄ slutsatsen Àr att belastningen ökade i samband med utlÀggningen, inget förvÄnande.
Sedan var det svĂ„rt att övertyga kollegorna att faktiskt installera den nya versionen. Jag sĂ€ger: "Det Ă€r okej, rulla ut. HĂ„ll tummarna, allt kommer att fungera. Just nu har belastningen ökat pĂ„ graferna, men allt Ă€r okej. HĂ„ll ut." SĂ„ vi gjorde sĂ„, och allt â versionen har lagts ut pĂ„ produktion. Men nĂ€stan vid varje utlĂ€ggning uppstĂ„r liknande problem.
Kill query ska stoppa frÄgorna, men det fungerar inte. Varför?
En anvĂ€ndare kom till mig, nĂ„gon analytiker, och skapade en förfrĂ„gan som kraschade min ClickHouse-kluster. Antingen en nod eller hela klustret â beroende pĂ„ vilken replik eller shard som förfrĂ„gan hamnade i. Jag ser att alla resurser pĂ„ CPU: n pĂ„ denna server Ă€r fulla, allt Ă€r rött. Samtidigt svarar ClickHouse pĂ„ förfrĂ„gningarna. Och jag skriver: "Visa mig gĂ€rna processlistan, vilken förfrĂ„gan orsakade detta kaos."
Jag hittar den hÀr förfrÄgan och skriver kill. Och jag ser att ingenting hÀnder. Min server Àr full, ClickHouse ger mig fortfarande olika kommandon, visar att servern lever, och allt Àr bra. Men jag har en degradering i alla anvÀndarförfrÄgningar, degradering börjar i skrivningen till ClickHouse, och min kill query fungerar inte. Varför? Jag trodde att kill query skulle döda förfrÄgningar, men sÄ Àr det inte.
Nu kommer ett ganska konstigt svar. Problemet Àr att kill query inte dödar förfrÄgningar.
Kill query sÀtter en liten flagga med namnet "jag vill att denna förfrÄgan ska dödas". SjÀlva förfrÄgan kollar pÄ den hÀr flaggan under bearbetningen av varje block. Om den Àr instÀlld, slutar förfrÄgan att fungera. SÄ egentligen dödar ingen förfrÄgningar, den mÄste sjÀlv kontrollera allt och stanna. Och det hÀr ska fungera i alla fall nÀr förfrÄgan Àr i ett tillstÄnd av blockbehandling. Den bearbetar nÀsta databasblock, kollar flaggan och stoppar.
Det fungerar inte i de fall dÀr förfrÄgan blockeras vid nÄgon operation. Men det Àr troligtvis inte ditt fall, eftersom du sÀger att det anvÀnder en massa serverresurser. Det kan hÀnda att det inte fungerar vid extern sortering och nÄgra andra detaljer. Men i stort sett borde det inte vara sÄ hÀr, det Àr en bugg. Det enda jag kan rekommendera Àr att uppdatera ClickHouse.
Hur berÀknar man svarstiden vid lÀsbelastning?
Det finns en tabell som lagrar aggregat per item - olika rÀknare. Antalet rader Àr ungefÀr hundra miljoner. GÄr det att rÀkna med en förutsÀgbar svarstid om man skickar 1K RPS med 1K item?
UtifrÄn sammanhanget handlar det om lÀsbelastning, eftersom det inte finns nÄgra problem vid skrivning - man kan infoga tusentals, till och med hundratusentals rader, och ibland flera miljoner.
LÀsförfrÄgningar kan vara av olika slag. I select 1 kan ClickHouse utföra upp till tiotusentals förfrÄgningar per sekund, sÄ Àven förfrÄgningar pÄ en enda nyckel kommer att krÀva vissa resurser. Dessa punktförfrÄgningar kommer att vara mer komplexa Àn i nÄgot nyckel-vÀrde-databaser, eftersom varje lÀsning krÀver att en datablok lÀses via index. Indexet adresserar inte varje post, utan varje intervall. Det betyder att hela intervallet mÄste lÀsas - det Àr 8192 rader som standard. Och databloken mÄste dekomprimeras frÄn 64 Kb till 1 Mb. Vanligtvis tar sÄdana punktförfrÄgningar frÄn nÄgra millisekunder. Men det Àr det enklaste alternativet.
LÄt oss försöka göra enkel aritmetik. Om man multiplicerar nÄgra millisekunder med tusen fÄr man nÄgra sekunder. Det verkar som att det inte gÄr att hantera tusen förfrÄgningar per sekund, men i verkligheten Àr det möjligt eftersom vi har flera processorkÀrnor. SÄ i princip kan ClickHouse ibland klara av 1000 RPS, men pÄ korta förfrÄgningar, just punktförfrÄgningar.
Om du behöver skala ClickHouse-klustret efter antalet enkla förfrÄgningar, rekommenderar jag den enklaste metoden - öka antalet repliker och skicka förfrÄgningar till en slumpmÀssig replik. Om en replik hanterar femhundra förfrÄgningar per sekund, vilket Àr helt realistiskt, kommer tre repliker att hantera femtonhundra.
Ibland kan man förstÄs stÀlla in ClickHouse för att maximera antalet punktlÀsningar. Vad behöver man för att göra det? För det första - minska granulariteten hos indexet. Det bör dock inte minska till en, utan med tanke pÄ att antalet poster i indexet kommer att vara flera miljoner eller tiotals miljoner pÄ servern. Om tabellen har hundra miljoner rader kan granulariteten stÀllas in pÄ 64.
Man kan minska storleken pÄ den komprimerade blocken. Det finns instÀllningar för detta. min compress block size, max compress block size. Man kan minska dem, flytta om data, och dÄ kommer punktfrÄgorna att bli snabbare. Men ClickHouse Àr fortfarande inte en key-value databas. Ett stort antal smÄ frÄgor Àr ett antipattern för belastning.
Kirill Shvakov: Jag ger ett rÄd ifall det handlar om vanliga konton. Det Àr en ganska standard situation nÀr ClickHouse lagrar nÄgon typ av rÀknare. Jag har en anvÀndare, han Àr frÄn ett visst land, och det finns ett tredje fÀlt, och nÄgot behöver ökas inkrementellt. Ta MySQL, skapa en unik nyckel - i MySQL Àr det en duplikatnyckel, och i PostgreSQL Àr det en konflikt - och lÀgg till med ett plustecken. Det kommer att fungera mycket bÀttre.
NÀr ni har lite data finns det ingen mening med att anvÀnda ClickHouse. Det finns vanliga databaser, och de hanterar detta bra.
Vad kan man justera i ClickHouse för att fÄ mer data i cachen?
TÀnk er en situation - servrarna har 256 GB RAM, i den dagliga rutinen anvÀnder ClickHouse ungefÀr 60-80 GB, som mest upp till 130. Vad kan man aktivera och justera för att fÄ mer data i cachen och dÀrmed fÀrre diskÄtgÄngar?
Som regel hanterar operativsystemets page cache denna uppgift vÀl. Om man öppnar bara toppen, ser man dÀr cached eller free - det stÄr ocksÄ hur mycket som Àr cacheat - sÄ kan man mÀrka att all ledig minne anvÀnds för cache. Och dessa data kommer vid lÀsning inte att lÀsas frÄn disken, utan frÄn RAM. Jag kan sÀga att cachen anvÀnds effektivt, eftersom komprimerade data cachas.
Som sagt, om ni vill snabba upp vissa enkla frĂ„gor Ă€nnu mer, finns det möjlighet att aktivera cachen för de okomprimerade data inom ClickHouse. Detta kallas uncompressed cache. I konfigurationsfilen config.xml stĂ€ller du in uncompressed cache size till det vĂ€rde som passar dig â jag rekommenderar inte mer Ă€n hĂ€lften av det fria RAM-minnet, eftersom resten kommer att anvĂ€ndas för page cache.
Dessutom finns det tvĂ„ instĂ€llningar pĂ„ förfrĂ„gningsnivĂ„. Den första instĂ€llningen â use uncompressed cache â aktiverar dess anvĂ€ndning. Det rekommenderas att aktivera den för alla förfrĂ„gningar, förutom tunga som kan lĂ€sa hela datamĂ€ngden och rensa denna cache. Och den andra instĂ€llningen â Ă€r nĂ„got som liknar maximalt antal rader för att anvĂ€nda cachen. Den begrĂ€nsar automatiskt stora förfrĂ„gningar sĂ„ att de gĂ„r förbi cachen.
Hur kan man konfigurera storage_configuration för att lagra i RAM?
I den nya dokumentationen för ClickHouse lÀste jag en sektion relaterad . I beskrivningen finns ett exempel med snabb SSD.
Det Àr intressant hur man kan konfigurera samma sak med volym hot memory. Och en annan frÄga. Hur fungerar select med en sÄdan datalagringsorganisation, kommer den att lÀsa hela uppsÀttningen eller bara den som ligger pÄ disken, och komprimeras dessa data i minnet? Och hur fungerar sektionen prewhere i en sÄdan datalagringsorganisation?
Denna instÀllning pÄverkar lagringen av dataskivor, och deras format Àndras inte.
LÄt oss titta pÄ det i detalj.
Att konfigurera lagring av data i RAM Ă€r möjligt. Allt som konfigureras för disken â Ă€r dess sökvĂ€g. Du skapar en tmpfs-partition som Ă€r monterad pĂ„ en viss sökvĂ€g i filsystemet. Du anger denna sökvĂ€g som sökvĂ€g för lagring av data för den hetaste partitionen, dit bitarna av data börjar strömma och skrivas, allt fungerar bra.
Men jag rekommenderar inte att göra det pÄ grund av lÄg tillförlitlighet, Àven om du har minst tre repliker i olika datacenter, sÄ kan det fungera. Om nÄgot, kommer datan att ÄterstÀllas. LÄt oss förestÀlla oss att servern plötsligt stÀngdes av och Äterstartades. Partitionen monterades igen, men dÀr Àr det tomt. ClickHouse-servern ser vid sin start att dessa bitar saknas, Àven om de enligt metadata frÄn ZooKeeper borde finnas. Den ser pÄ vilka repliker de finns, begÀr dem och laddar ner dem. PÄ sÄ sÀtt kommer datan att ÄterstÀllas.
I detta avseende skiljer sig lagring av data i RAM inte principiellt frÄn lagring pÄ disk, eftersom data nÀr de skrivs till disk först hamnar i page cache och skrivs fysiskt ut fördröjt. Detta beror pÄ hur filsystemet Àr monterat. Men för sÀkerhets skull kan jag nÀmna att ClickHouse inte gör fsync vid insert.
Samtidigt lagras data i RAM i exakt samma format som pÄ disk. En select-frÄga hÀmtar pÄ samma sÀtt de bitar som behöver lÀsas, vÀljer nödvÀndiga dataintervall frÄn skivorna och lÀser dem. Och prewhere fungerar pÄ exakt samma sÀtt, oavsett om data var i RAM eller pÄ disk.
Till hur mÄnga unika vÀrden Àr Low Cardinality effektiv?
Low Cardinality Ă€r smart utformat. Det skapar datordbok, men de Ă€r lokala. För det första har varje bit sin egen ordbok, och för det andra kan de Ă€ven vara olika inom samma bit för varje intervall. NĂ€r antalet unika vĂ€rden nĂ„r en tröskelnivĂ„ â pĂ„ minnet Ă€r det en miljon â sĂ„ skjuts ordboken helt enkelt upp, och en ny skapas.
Svaret i allmĂ€nhet: för varje lokalt intervall â lĂ„t oss sĂ€ga för varje dag â Ă€r Low Cardinality effektivt upp till nĂ€stan en miljon unika vĂ€rden. Efter det kommer det istĂ€llet att bli fallback, dĂ€r mĂ„nga olika ordböcker anvĂ€nds istĂ€llet för en. Det kommer att fungera ungefĂ€r som en vanlig kolumn av typen string, kanske nĂ„got mindre effektivt, men det kommer inte att ske nĂ„gon allvarlig försĂ€mring av prestandan.
Vilka Àr de bÀsta metoderna för fulltextsökning i en tabell med fem miljarder rader?
Det finns olika svarsalternativ. Det första Ă€r att sĂ€ga att ClickHouse inte Ă€r ett system för fulltextsökning. För detta finns det speciella system som till exempel och . ĂndĂ„ möter jag allt oftare personer som sĂ€ger att de övergĂ„r frĂ„n Elasticsearch till ClickHouse.
Varför sker detta? De förklarar att Elasticsearch inte lÀngre klarar belastningen vid vissa volymer, sÀrskilt nÀr det gÀller indexering. Indexen blir för omfÄngsrika, och om man helt enkelt överför data till ClickHouse visar det sig att de lagras flera gÄnger mer effektivt i volym. Samtidigt handlade mÄnga sökfrÄgor inte om att hitta en fras i hela datamÀngden med hÀnsyn till morfologi, utan var helt andra. Till exempel att hitta i loggarna för de senaste timmarna baserat pÄ en viss byte-subsekvens.
I det hÀr fallet skapar du ett index i ClickHouse dÀr det första fÀltet Àr datum med tid. Den största avgrÀnsningen av data kommer att ske just efter datumintervall. Inom det valda datumintervallet kan man vanligtvis utföra fulltextsökning Àven med brute force-metoden med hjÀlp av like. Operatorn like i ClickHouse Àr den mest effektiva like-operatorn som du kan hitta. Om du hittar en bÀttre, lÄt mig veta.
Men ÀndÄ Àr like en fullstÀndig skanning. Och en fullstÀndig skanning kan vara lÄngsam inte bara för CPU:n, utan Àven för disken. Om du skulle ha en terabyte data per dag och du söker efter ett ord pÄ en dag, mÄste du skanna en terabyte. Och den kommer förmodligen att ligga pÄ vanliga hÄrddiskar, och i slutÀndan kommer de att vara sÄ belastade att du inte kan logga in pÄ den servern via SSH.
I det hĂ€r fallet Ă€r jag beredd att föreslĂ„ Ă€nnu ett litet knep. Det Ă€r av den experimentella typen â det kan fungera, eller sĂ„ kanske det inte gör det. I ClickHouse finns det fulltextiga indexer i form av trigram Bloom-filter. VĂ„ra kollegor frĂ„n företaget Arenadata har redan testat dessa indexer, och ofta fungerar de precis som de Ă€r avsedda.
För att anvÀnda dem korrekt bör man förstÄ hur de faktiskt fungerar: vad trigram Bloom-filtret bestÄr av och hur man vÀljer dess storlek. Jag kan sÀga att de kommer att vara till hjÀlp för frÄgor som rör sÀllsynta fraser eller substringar som sÀllan förekommer i datan. I det hÀr fallet kommer underintervall att vÀljas baserat pÄ indexerna, och mindre data kommer att lÀsas.
Nyligen har ClickHouse Àven fÄtt mer avancerade funktioner för fulltextsökning. För det första kan man söka efter flera substrÀngar i ett enda steg, inklusive alternativ med hÀnsyn till versaler, utan hÀnsyn till versaler, med UTF-8-stöd eller endast för ASCII. VÀlj det mest effektiva alternativet som du behöver.
Det har ocksÄ introducerats sökning efter flera reguljÀra uttryck i ett enda steg. Du behöver inte skriva X like en substrÀng or X like en annan substrÀng. Skriv helt enkelt, och allt utförs maximalt effektivt.
För det tredje finns nu approximativ sökning av reguljÀra uttryck och approximativ sökning av substrÀngar. Om nÄgon har skrivit ett ord med stavfel, kommer det att sökas med maximal överensstÀmmelse.
Hur ska man organisera tillgÄngen i ClickHouse för ett stort antal anvÀndare?
BerÀtta hur man bÀst organiserar Ätkomst för ett stort antal anvÀndare och analytiker. Hur formar man en kö, prioriterar max samtidiga frÄgor och vilka verktyg anvÀnds?
Om klustret Àr tillrÀckligt stort, sÄ Àr en bra lösning att lÀgga till ytterligare tvÄ servrar, som blir ingÄngspunkter för analytiker. Det vill sÀga att inte ge analytiker Ätkomst till specifika shardar i klustret, utan att bara skapa tvÄ tomma servrar utan data och konfigurera ÄtkomstrÀttigheter pÄ dem. InstÀllningarna för anvÀndarna överförs vid distribuerade frÄgor till de fjÀrrservrarna. Det innebÀr att du konfigurerar allt pÄ dessa tvÄ servrar, och instÀllningarna gÀller för hela klustret.
I princip Àr dessa servrar utan data, men mÀngden RAM-minne pÄ dem Àr mycket viktig för att utföra frÄgor. Disken kan ocksÄ anvÀndas för temporÀra data om extern aggregering eller extern sortering Àr aktiverat.
Det Àr viktigt att titta pÄ instÀllningarna relaterade till alla möjliga grÀnser. Om jag just nu gÄr in pÄ klustret "Yandex.Metrica" som analytiker och stÀller en frÄga select count from hits, sÄ fÄr jag genast ett undantag som sÀger att jag inte kan utföra frÄgan. Det maximala antalet rader som jag fÄr skanna Àr hundra miljarder, medan det totalt finns femtio triljoner i klustret i en tabell. Detta Àr den första begrÀnsningen.
Anta att jag tar bort begrĂ€nsningen pĂ„ antalet rader, och kör frĂ„gan igen. DĂ„ kommer jag att se följande undantag â instĂ€llningen force index by dateĂ€r aktiverad. Jag kan inte utföra frĂ„gan om jag inte specificerar datumintervallet. Man bör inte rĂ€kna med att analytikerna kommer att ange det manuellt. Ett typiskt fall Ă€r att man har skrivit ett datumintervall dĂ€r eventdatumet ligger mellan en vecka. Och sedan har man helt enkelt angivit parentesen fel, och istĂ€llet för and blev det or â or URL match. Om det inte finns nĂ„gon begrĂ€nsning kommer systemet att börja skanna URL-kolumnen och slösa en massa resurser.
Dessutom finns det tvĂ„ instĂ€llningar för prioriteter i ClickHouse. TyvĂ€rr Ă€r de mycket primitiva. Den ena kallas helt enkelt priorityOm priority â 0 och förfrĂ„gningar med nĂ„gon prioritet görs, men en förfrĂ„gning utförs med en prioritet som har ett vĂ€rde som Ă€r mindre, vilket betyder högre prioritet, kommer en förfrĂ„gan med ett vĂ€rde av prioritet som Ă€r högre, vilket innebĂ€r lĂ€gre prioritet, bara att pausas och kommer inte att fungera överhuvudtaget under den tiden.
Det hÀr Àr en vÀldigt grov instÀllning och den passar inte för de fall dÀr det finns en konstant belastning pÄ klustret. Men om du har korta, impulsiva förfrÄgningar som Àr viktiga och klustret mestadels stÄr still, sÄ kan denna instÀllning passa.
Den nÀsta prioritetsinstÀllningen kallas OS trÄdprioritet. Den stÀller helt enkelt in nice-vÀrdet för alla trÄdar som utför förfrÄgningar i Linux-schemalÀggaren. Den fungerar sÄdÀr, men fungerar ÀndÄ. Om du stÀller in det minsta möjliga nice-vÀrdet - det Àr det högsta i storlek och betyder lÀgst prioritet - och stÀller förfrÄgningar med hög prioritet till -19, kommer CPU:n att konsumera lÄgprioriterade förfrÄgningar ungefÀr fyra gÄnger mindre Àn högprioriterade.
Du behöver ocksÄ stÀlla in maximal utförandetid för en förfrÄgan - sÀg, fem minuter. Den minimiutförandehastigheten för en förfrÄgan - det Àr det bÀsta. Den hÀr instÀllningen har funnits lÀnge och den krÀvs för att inte bara pÄstÄ att ClickHouse inte laggar utan för att tvinga det.
FörestĂ€ll dig att du stĂ€ller in: om nĂ„gon förfrĂ„gan behandlar mindre Ă€n en miljon rader per sekund - sĂ„ kan man inte göra sĂ„. Det förnedrar vĂ„rt goda namn, vĂ„r goda databas. LĂ„t oss bara förbjuda det. Det Ă€r faktiskt tvĂ„ instĂ€llningar dĂ€r. Den ena kallas min utförandehastighet â i rader per sekund, och den andra kallas timeout innan kolla min utförandehastighet - som standard femton sekunder. SĂ„ femton sekunder Ă€r okej, men sedan, om det gĂ„r lĂ„ngsamt, sĂ„ kastar man helt enkelt ett undantag - avbryter förfrĂ„gan.
Du behöver ocksÄ stÀlla in kvoter. I ClickHouse finns det en inbyggd möjlighet till kvotering som rÀknar resursanvÀndning. Men tyvÀrr inte hÄrdvaruresurser som CPU, diskar, utan logiska - antal behandlade förfrÄgningar, rader och lÀsta byte. Och du kan stÀlla in, till exempel, max ett hundra förfrÄgningar under fem minuter och tusen förfrÄgningar per timme.
Varför Àr detta viktigt? För att en del av analysförfrÄgningarna kommer att utföras manuellt direkt frÄn ClickHouse-klienten. Och allt kommer att vara bra. Men om ni har avancerade analytiker i ert företag kommer de att skriva ett skript, och i skriptet kan det finnas ett fel. Och det felet kan leda till att förfrÄgan körs i en oÀndlig loop. Det Àr det som man mÄste skydda sig mot.
Kan man ge resultaten av en frÄga till tio kunder?
Vi har flera anvÀndare som gillar att komma med mycket stora förfrÄgningar samtidigt. FörfrÄgan Àr stor, den körs i princip snabbt, men eftersom det finns sÄ mÄnga sÄdana förfrÄgningar samtidigt blir det vÀldigt smÀrtsamt. Kan man utföra samma förfrÄgan som kommit tio gÄnger i rad bara en gÄng och ge resultatet till tio kunder?
Problemet Àr att vi inte har nÄgra cache-resultat eller cache av mellanlagrade data. Det finns page cache frÄn operativsystemet som gör att man inte behöver lÀsa data frÄn disken igen, men tyvÀrr kommer data ÀndÄ att behöva dekomprimeras, deserialiseras och behandlas igen.
Vi skulle vilja undvika det pĂ„ nĂ„got sĂ€tt, antingen genom att cache-lagra mellanliggande data eller genom att stĂ€lla liknande förfrĂ„gningar i nĂ„gon kö och lĂ€gga till en resultatcache. Just nu har vi en pull request under utveckling som lĂ€gger till en cache av förfrĂ„gningar, men endast för underförfrĂ„gningar i in- och join-sektionen â det vill sĂ€ga lösningen Ă€r ofullstĂ€ndig.
ĂndĂ„ har vi ocksĂ„ en sĂ„dan situation. Ett klassiskt exempel Ă€r förfrĂ„gningar med paginering. Det finns en rapport med flera sidor, och det görs en förfrĂ„gan limit 10. Sedan samma sak igen, men limit 10,10. Sedan nĂ€sta sida. Och man undrar, varför rĂ€knar vi detta varje gĂ„ng? Men för tillfĂ€llet finns det ingen lösning, och man kan inte undvika detta.
Det finns en alternativ lösning som placeras som en sidokar bredvid ClickHouse â .
Kirill Shvakov: I ClickHouse Proxy finns det en inbyggd hastighetsbegrÀnsare och inbyggd resultatcache. Det har gjorts mÄnga instÀllningar hÀr, eftersom man hanterade en liknande uppgift. Proxy tillÄter att begrÀnsa förfrÄgningar genom att stÀlla dem i kö och konfigurera hur lÀnge cachade förfrÄgningar lever. Om förfrÄgningarna verkligen var identiska kommer Proxy att returnera dem flera gÄnger, medan den bara gÄr till ClickHouse en gÄng.
Nginx har ocksÄ caching i den kostnadsfria versionen, och det kommer ocksÄ att fungera. Nginx har till och med instÀllningar för att om förfrÄgningar kommer in samtidigt, kommer det att pausa andra tills en har genomförts. Men just i ClickHouse Proxy Àr instÀllningen mycket bÀttre. Den Àr specifikt designad för ClickHouse och dessa förfrÄgningar, sÄ den passar bÀttre. Dessutom Àr installationen enkel.
Vad ska man göra med asynkrona operationer och materialiserade vyer?
Det finns ett problem med att operationer med replikeringsmotorn Ă€r asynkrona â först skrivs data, sedan sker en komprimering. Om det under tabellen finns en materialiserad vy med nĂ„gra aggregeringar, kommer dubbletter att skrivas in i den. Och om det inte finns nĂ„gon komplex logik, kommer data att bli duplicerade. Vad kan göras Ă„t detta?
Det finns en uppenbar lösning â att implementera en trigger för en viss klass av materialiserade vyer vid asynkron komprimeringsoperation. Finns det nĂ„gra "silverkulor", planer för att implementera sĂ„dana funktioner?
Det Àr viktigt att förstÄ hur deduplicering fungerar. Det jag nu ska berÀtta om hör inte till frÄgan, men det Àr ÀndÄ vÀrt att tÀnka pÄ.
Vid insÀttning i en replikerad tabell sker en deduplicering av hela patchede insatta block. Om du sÀtter in samma block igen som innehÄller samma antal av samma rader i samma ordning, sÄ kommer datan att dedupliceras. Du fÄr "Ok" som svar pÄ insert, men i verkligheten kommer en datapatch att skrivas, och den kommer inte att bli duplicerad.
Detta behövs för att sÀkerstÀlla tydlighet. Om du under insÀttningen fÄtt "Ok", betyder det att dina data har infogats. Om du fÄtt ett fel frÄn ClickHouse, sÄ betyder det att de inte har infogats, och insÀttningen mÄste upprepas. Men om anslutningen bröts under insÀttningen, vet du inte om datan har infogats eller inte. Det enda alternativet Àr att upprepa insÀttningen igen. Om data faktiskt har infogats och du sÀtter in dem igen finns det deduplicering av blocken. Det behövs för att undvika dubbletter.
Och det Àr ocksÄ viktigt hur det fungerar för materialiserade vyer. Om data har deduplicerats vid insÀttningen i huvudtabellen kommer de inte heller att gÄ in i den materialiserade vyn.
Nu till frÄgan. Ni har en mer komplicerad situation eftersom ni registrerar dubbletter av enskilda rader. Det Àr inte hela batchen som Àr dublikat, utan just specifika rader, och de komprimeras i bakgrunden. Faktiskt kommer dessa data att komprimeras i huvudtabellen, medan de osammanpressade gÄr till det materialiserade vyn, och vid sammanslagningar kommer ingenting att hÀnda med de materialiserade vyerna. För materialiserad vy Àr inte annat Àn en trigger för insert. Vid andra operationer hÀnder inget ytterligare med den.
Och jag kan tyvÀrr inte glÀdja er hÀr. Man mÄste bara leta efter en specifik lösning för det hÀr fallet. Till exempel, kan man ocksÄ göra en ersÀttning i det materialiserade vyn, och metoden för deduplicering kanske ocksÄ fungerar. Men tyvÀrr fungerar det inte alltid. Om den Àr aggregerande, sÄ gÄr det inte.
Kirill Shvakov: Vi hade ocksĂ„ en del klurigheter för lĂ€nge sedan. Det fanns ett problem med att vi har visningar av annonser, och det finns vissa data som vi kan visa i realtid â det Ă€r bara visningar. De dupliceras sĂ€llan, men om det hĂ€nder, sĂ„ kommer vi Ă€ndĂ„ att komprimera dem senare. Och det fanns saker som inte fĂ„r dupliceras â klick och hela den historien. Men vi ville ocksĂ„ gĂ€rna visa dem nĂ€stan omedelbart.
Hur gjordes de materialiserade vyerna? Det fanns vyer dit man skriver direkt â det gĂ„r en inspelning till rĂ„data, och det skrivs till vyerna. I nĂ„got skede Ă€r datan inte riktigt korrekt, de dupliceras och sĂ„ vidare. Och det finns en andra del av tabellen, dĂ€r de ser exakt likadana ut som de materialiserade vyerna, det vill sĂ€ga i strukturen Ă€r de helt identiska. En gĂ„ng per viss tid rĂ€knar vi om data, rĂ€knar data utan dubbletter, skriver till de tabellerna.
Vi gick via API â i ClickHouse kommer det inte att fungera manuellt. Och API:t tittar: nĂ€r jag har datumet för den senaste tillagda posten i tabellen, dĂ€r data garanterat redan Ă€r korrekta, berĂ€knade, och den gör en begĂ€ran till en tabell och en annan tabell. FrĂ„n en tabell vĂ€ljer den fram till en viss tid, och frĂ„n den andra kompletterar den det som fortfarande inte har berĂ€knats. Och det fungerar, men inte med medel av ett enda ClickHouse.
Om du har nÄgot API för analytiker eller anvÀndare, Àr det i princip ett alternativ. Du rÀknar alltid, du berÀknar alltid om. Detta kan göras en gÄng om dagen eller vid nÄgon annan tidpunkt. Du vÀljer sjÀlv den tidsram som Àr obetydlig för dig.
I ClickHouse finns det mÄnga loggar. Hur kan jag se allt som hÀnder med servern i realtid?
Det finns en stor mĂ€ngd olika loggar i ClickHouse, och antalet ökar. I de nya versionerna Ă€r vissa av dem till och med aktiverade som standard, medan de i Ă€ldre versioner mĂ„ste aktiveras vid uppdateringen. ĂndĂ„ blir de bara fler och fler. Jag skulle vilja se vad som hĂ€nder just nu med min server, kanske pĂ„ nĂ„gon sammanfattande dashboard.
Har ni i teamet ClickHouse, eller i vÀnners team, nÄgot stöd för fÀrdiga dashboards som visar dessa loggar i form av en fÀrdig produkt? I slutÀndan, att bara titta pÄ loggarna i ClickHouse Àr bra. Men det skulle vara fantastiskt om det redan var förberett i form av en dashboard. Jag skulle verkligen uppskatta det.
Det finns dashboards, men de Àr inte standardiserade. I vÄrt företag anvÀnder cirka 60 team ClickHouse, och det mest konstiga Àr att mÄnga av dem har dashboards som de sjÀlva har gjort och som Àr lite olika. Vissa team anvÀnder en intern installation av "Yandex.Cloud". DÀr finns det nÄgra fÀrdiga rapporter, Àven om inte alla nödvÀndiga. Andra har sina egna.
Mina kollegor frÄn "Metri" har sin egen dashboard i Grafana, och jag har min egen som bygger pÄ deras kluster. Jag tittar pÄ saker som cache-hit för cache-avlÀsningar. Och det Àr Ànnu mer komplicerat eftersom vi anvÀnder olika verktyg. Jag skapade min dashboard pÄ ett mycket gammalt verktyg som heter Graphite-web. Den Àr helt ful. Och jag anvÀnder den fortfarande, Àven om Grafana skulle vara mer bekvÀm och vackrare.
Det grundlÀggande i dashboards Àr detsamma. Det handlar om systemmetrik för klustret: CPU, minne, disk, nÀtverk. Andra inkluderar antal samtidiga förfrÄgningar, antal samtidiga sammanslagningar, antal förfrÄgningar per sekund, maximalt antal bitar för partitioner i MergeTree-tabeller, replikationslagg, storlek pÄ replikationskö, antal insatta rader per sekund, antal insatta block per sekund. Det hÀr Àr allt som hÀmtas frÄn metrik, inte frÄn loggar.
Vladimir Kolobajev: Alexey, jag skulle vilja göra en liten justering. Det finns Grafana. Grafana har en datakÀlla, som Àr ClickHouse. Det betyder att jag kan göra förfrÄgningar direkt till ClickHouse frÄn Grafana. I ClickHouse finns det en loggtabell, som Àr densamma för alla. Jag vill i resultatet i Grafana kunna referera till denna loggtabell och se de förfrÄgningar som min server gör. Det skulle vara bra att ha en sÄdan dashboard.
Jag har gjort det hÀr sjÀlv. Men jag har en frÄga - om allt Àr standardiserat, och Grafana anvÀnds av alla, varför finns det inget officiellt dashboard för 'Yandex'?
Kirill Shvakov: Faktum Àr att datakÀllan som Àr kopplad till ClickHouse för nÀrvarande stöds av Altinity. Och jag vill bara ge en riktning för vad man ska titta pÄ och vem man ska föra fram. Man kan frÄga dem, eftersom 'Yandex' faktiskt gör ClickHouse, och inte historien kring det. Altinity Àr det frÀmsta företaget som för nÀrvarande marknadsför ClickHouse. De kommer inte att överge det, utan fortsÀtta att stödja det. För att ladda upp en dashboard pÄ Grafanas webbplats behöver man bara registrera sig och ladda upp den - inga större problem.
Alexey Milovidov: Under det senaste Äret har mÄnga möjligheter tillkommit i ClickHouse för att profilera förfrÄgningar. Det finns metoder för varje förfrÄgning angÄende resursanvÀndning. Och nyligen har Ànnu en mer lÄg nivÄ profileringsverktyg lagts till för att se var förfrÄgan spenderar varje millisekund. Men för att kunna anvÀnda denna funktionalitet Àr jag tvungen att öppna kommandoradsclienten och skriva en förfrÄgan som jag stÀndigt glömmer. Jag har sparat den nÄgonstans och glömmer hela tiden var.
Jag skulle vilja ha ett verktyg dÀr det enkelt stÄr - hÀr Àr dina tunga förfrÄgningar, grupperade efter förfrÄgningsklasser. Jag klickar pÄ en och fÄr veta att den Àr tung av den anledningen. Just nu finns det ingen sÄdan lösning. Det Àr faktiskt ganska konstigt att nÀr folk frÄgar mig: "Finns det nÄgon fÀrdig dashboard för Grafana?", sÀger jag: "GÄ till Grafanas webbplats, dÀr finns ett community för 'Dashboards', och dÀr finns en dashboard frÄn Dimka, en frÄn Kostyan. Vad det Àr, vet jag inte, jag har sjÀlv inte anvÀnt det."
Hur kan jag pÄverka sammanslagningarna sÄ att servern inte kraschar i OOM?
Jag har en tabell med bara en partition, den Àr ReplacingMergeTree. Jag har skrivit data till den under fyra Är. Jag behövde göra en alter och ta bort vissa data.
Jag gjorde det, och under behandling av denna förfrÄgan tog all minne slut pÄ alla servrar i klustret, och alla servrar i klustret kraschade vÀnligt i OOM. Sedan stod de alla upp igen, började göra en sammanslagning av just denna operation, denna datablok, och kraschade igen i OOM. Sedan stÄende upp igen, kraschade igen. Och det hÀr slutade inte.
Sedan visade det sig att det faktiskt var en bugg som de fixade. Det Àr jÀttebra, stort tack. Men jag har ÀndÄ en olustig kÀnsla kvar. Och nu nÀr jag tÀnker pÄ att jag mÄste göra nÄgon form av sammanslagning i tabellen, fÄr jag frÄgan - varför kan jag inte pÄ nÄgot sÀtt pÄverka dessa sammanslagningar? Till exempel, begrÀnsa dem enligt den mÀngd minne som krÀvs, eller i allmÀnhet antalet som specifikt ska hantera denna tabell.
Jag har en tabell som heter 'Metriker', vÀnligen bearbeta den i tvÄ trÄdar. Skapa inte parallellt tio eller fem sammanslagningar, gör det med tvÄ. Jag tror att med tvÄ kommer jag att ha tillrÀckligt med minne, men för att bearbeta tio kanske det inte rÀcker. Varför kvarstÄr rÀdslan? För tabellen vÀxer, och nÄgon gÄng kommer jag att stÄ inför situationen att det helt enkelt inte Àr en bugg, utan att data kommer att förÀndras i sÄdana stora mÀngder att jag helt enkelt inte har tillrÀckligt med minne pÄ servern. Och dÄ kommer servern att krascha i OOM vid sammanslagningen. FörÀndringen kan jag avboka, men sammanslagningar kan jag inte.
Du vet, vid sammanslagningar kommer servern inte att falla i OOM, eftersom det vid sammanslagning anvÀnds endast en liten mÀngd minne för ett litet dataintervall. SÄ allt kommer att gÄ bra oavsett datavolym.
Vladimir Kolobajev: Bra. HÀr Àr det sÄ att efter att jag gjort en buggfix, laddade jag ner den nya versionen, och pÄ en annan, mindre tabell dÀr det finns mÄnga partitioner, genomförde jag en liknande operation. Under sammanslagningen pÄ servern förbrukades cirka 100 GB minne. Jag hade 150 GB upptaget, 100 GB anvÀndes, och jag hade 50 GB kvar, sÄ jag gick inte i OOM.
Vad skyddar mig just nu frÄn att jag gÄr i OOM, om det verkligen förbrukar 100 GB minne? Hur ska jag hantera situationen om minnet plötsligt tar slut under sammanslagningar?
Alexey Milovidov: Det finns ett problem, nÀmligen att minnesanvÀndningen under sammanslagningar inte Àr begrÀnsad. Och det andra problemet Àr att om en viss sammanslagning har blivit schemalagd sÄ mÄste den genomföras, eftersom den Àr inspelad i replikationsloggen. Replikationsloggen Àr de ÄtgÀrder som behövs för att fÄ replikationen i ett konsekvent tillstÄnd. Om man inte gör manuella ÄtgÀrder för att rulla tillbaka denna replikationslogg, sÄ mÄste sammanslagningen pÄ ett eller annat sÀtt genomföras.
SjÀlvklart skulle det vara bra att ha en grÀns för minnesanvÀndning, som "för sÀkerhets skull" skyddar just mot OOM. Det kommer inte att hjÀlpa sammanslagningen att genomföras, den kommer att börja om, nÄ upp till en viss nivÄ, kasta ett undantag, och sedan börja om igen - inget bra kommer att komma ur det. Men i princip skulle det vara anvÀndbart att införa en sÄdan begrÀnsning.
Hur kommer utvecklingen av Golang-drivrutinen för ClickHouse att gÄ till?
Golang-drivrutinen som Kirill Shvakov har skrivit stöds nu officiellt av ClickHouse-teamet. Den , den Àr nu stor och verklig.
En liten anmĂ€rkning. Det finns en fantastisk och omtyckt databas för oĂ€ndlig ordning â Vertica. De har ocksĂ„ sin officiella Python-drivrutin som stöds av Vertica-utvecklarna. Flera gĂ„nger har det hĂ€nt att versionerna av databasen och drivrutinen har skiljt sig Ă„t ganska mycket, vilket har gjort att drivrutinen slutade fungera vid vissa tillfĂ€llen. En annan sak Ă€r att stödet för denna officiella drivrutin, verkar det som, bedrivs genom systemet "nipplar" â du skriver till dem om problem, och det hĂ€nger kvar i evigheter.
Jag har tvÄ frÄgor. Just nu Àr Kirills Golang-drivrutin nÀstan standardmetoden för att kommunicera frÄn Golang med ClickHouse. Endast de som fortfarande kommunicerar via http-grÀnssnittet gör det för att de föredrar det. Hur kommer utvecklingen av denna drivrutin att gÄ till? Kommer den att synkroniseras med nÄgra brytande förÀndringar i sjÀlva databasen? Och hur gÄr Àrendehanteringen till?
Kirill Shvakov: Första punkten â hur allt Ă€r organiserat byrĂ„kratiskt. Detta har inte diskuterats, sĂ„ jag har inget att svara.
För att svara pÄ frÄgan om problem Àr det en liten historia om drivrutinen. Jag jobbade pÄ ett företag med mycket data. Det var en reklamplattform med ett stort antal hÀndelser som behövde lagras. Plötsligt dök ClickHouse upp. Vi hÀllde in data dÀr, och i början var allt bra, men sedan kraschade ClickHouse. Vid den tidpunkten bestÀmde vi att vi inte behövde det.
Ett Är senare Äterkom vi till idén om att anvÀnda ClickHouse, och vi behövde ett sÀtt att skriva data dit. FörutsÀttningen var att hÄrdvaran var vÀldigt svag och resurserna fÄ. Men vi hade alltid arbetat sÄ, sÄ vi tittade pÄ den inbyggda protokollet.
Eftersom vi arbetade pĂ„ Go, var det klart att vi behövde en drivrutin i Go. Jag arbetade pĂ„ den nĂ€stan heltid â det var min arbetsuppgift. Tills viss punkt nĂ„dde vi en bra nivĂ„, och ingen trodde egentligen att nĂ„gon annan Ă€n vi skulle anvĂ€nda den. Sedan kom CloudFlare med exakt samma problem, och en tid arbetade vi mycket tillsammans eftersom de hade samma uppgifter. Vi gjorde detta bĂ„de i ClickHouse sjĂ€lv och i drivrutinen.
Vid nÄgot tillfÀlle slutade jag helt enkelt att arbeta med dem, eftersom min aktivitet med ClickHouse och arbetet förÀndrades nÄgot. DÀrför stÀngs inte Àrendena. Ibland gör personer commit till repositoryn för att de sjÀlva behöver nÄgot. DÄ tittar jag pÄ pull requesten och korrigerar ibland Àven nÄgot sjÀlv, men det hÀnder sÀllan.
Jag vill ÄtervÀnda till drivrutinen. För nÄgra Är sedan, nÀr allt detta började, var ClickHouse ocksÄ annorlunda och hade andra möjligheter. Nu finns det en förstÄelse för hur man kan omarbeta drivrutinen sÄ att den fungerar bra. Om detta sker kommer version 2 pÄ nÄgot sÀtt att bli inkompatibel pÄ grund av ackumulerade tillfÀlliga lösningar.
Jag vet inte hur jag ska organisera detta. Jag har inte sÄ mycket tid sjÀlv. Om nÄgra personer vill vidareutveckla drivrutinen kan jag hjÀlpa dem och förklara vad de ska göra. Men att "Yandex" aktivt deltar i projektets utveckling har Ànnu inte diskuterats.
Alexey Milovidov: För nÀrvarande finns det ingen byrÄkrati angÄende dessa drivrutiner. Det enda Àr att de har överförts till en officiell organisation, vilket innebÀr att denna drivrutin erkÀnns som den officiella lösningen som standard för Go. Det finns nÄgra andra drivrutiner, men de Àr separata.
Vi har ingen intern utveckling för dessa drivrutiner. FrÄgan Àr om vi kan anstÀlla en separat person, inte specifikt för denna drivrutin, utan för att utveckla alla community-drivrutiner, eller om vi kan hitta nÄgon utanför.
Den externa ordboken laddas inte efter omstart med instÀllningen lazy_load aktiverad. Vad ska man göra?
Vi har instÀllningen lazy_load aktiverad, och efter omstart av servern laddas ordboken inte automatiskt. Den laddas först efter att anvÀndaren har anropat denna ordbok. Och vid första anropet ger den ett fel. Kan man pÄ nÄgot sÀtt automatiskt ladda ordböcker med ClickHouse, eller mÄste vi alltid kontrollera deras beredskap sjÀlva sÄ att anvÀndarna inte fÄr nÄgra fel?
Kanske har vi en gammal version av ClickHouse, dÀrför laddades ordboken inte automatiskt. Kan det vara sÄ?
För det första kan ordböcker tvingas att laddas med hjĂ€lp av frĂ„gan system reload dictionaries. För det andra, angĂ„ende felet â om ordboken redan Ă€r laddad kommer frĂ„gor att fungera med de data som har laddats. Om ordboken Ă€nnu inte har laddats kommer den att laddas direkt under frĂ„gan.
För tunga ordböcker Àr detta inte sÀrskilt bekvÀmt. Till exempel, om man behöver dra en miljon rader frÄn MySQL. Vissa gör en enkel select, men den selecten kommer att vÀnta pÄ just dessa en miljon rader. HÀr finns det tvÄ lösningar. Den första Àr att stÀnga av lazy_load. Den andra Àr att nÀr servern startas, innan den belastas, göra system reload dictionary eller helt enkelt utföra en frÄga som anvÀnder ordboken. DÄ kommer ordboken att laddas. Man behöver sjÀlva kontrollera tillgÀngligheten av ordböcker med aktiv instÀllning för lazy_load, eftersom ClickHouse inte automatiskt hÀmtar dem.
Svaret pÄ den sista frÄgan Àr att antingen Àr versionen gammal, eller sÄ behöver man felsöka.
Hur ska vi hantera att systemet inte laddar nÄgra av de mÄnga ordböckerna om Ätminstone en av dem misslyckas med ett fel?
Det finns ocksĂ„ en frĂ„ga angĂ„ende system reload dictionaries. Vi har tvĂ„ ordböcker â en laddas inte, den andra laddas. System reload dictionaries laddar i sĂ„dana fall ingen av ordböckerna, och vi mĂ„ste ladda en specifik ordbok utifrĂ„n dess namn med hjĂ€lp av system reload dictionary. Beror detta ocksĂ„ pĂ„ versionen av ClickHouse?
Jag vill gladeligen informera er. Detta beteende har Àndrats. SÄ, om ni uppdaterar ClickHouse, kommer det ocksÄ att förÀndras. Om ni inte Àr nöjda med det nuvarande beteendet system reload dictionaries, uppdatera och vi hoppas att det kommer att förÀndras till det bÀttre.
Finns det nÄgot sÀtt att konfigurera behörigheterna i ClickHouse-konfigurationen utan att avslöja dem vid fel?
NÀsta frÄga handlar om fel som Àr relaterade till ordboken, nÀmligen autentiseringsuppgifterna. Vi har angett autentiseringsuppgifterna i ClickHouse-konfigurationen för ordboken, och vid fel fÄr vi dessa autentiseringsuppgifter och lösenordet i svaret.
Vi löste detta fel genom att föra över autentiseringsuppgifterna till ODBC-drivrutinskonfigurationen. Finns det nÄgot sÀtt att konfigurera autentiseringsuppgifterna i ClickHouse-konfigurationen utan att visa dessa autentiseringsuppgifter vid fel?
HĂ€r Ă€r lösningen verkligen att ange dessa credentials i odbc.ini, och i sjĂ€lva ClickHouse ange endast ODBC Datasource Namn. För andra kĂ€llor av ordböcker blir det inte sĂ„ â varken för ordboken med MySQL eller för andra ska ni se lösenordet vid felmeddelande. För ODBC ska jag ocksĂ„ kolla â om det finns nĂ„got sĂ„dant, sĂ„ mĂ„ste det bara tas bort.
Bonus: bakgrunder för Zoom-möten
Vid klick pÄ bilden kommer bonusbakgrunder med sittande att öppnas för de mest ihÀrdiga lÀsarna. Vi slÀcker brÀnder tillsammans med Avitos teknologimascotar, konfererar med kollegor frÄn systemadministratörens rum eller den gamla klassiska datorklubben och hÄller dagliga möten under bron mot bakgrund av graffiti.
KĂ€lla: habr.com
