I april samlades Avitos ingenjörer för onlinemöten med den frÀmsta ClickHouse-utvecklaren Alexey Milovidov och Kirill Shvakov, en Golang-utvecklare frÄn Integros. Vi diskuterade hur vi anvÀnder ett databashanteringssystem och vilka svÄrigheter vi stöter pÄ.
UtifrÄn mötet har vi sammanstÀllt en artikel med experternas svar pÄ vÄra och publikens frÄgor om sÀkerhetskopiering, dataomdelning, externa ordböcker, Golang-drivrutinen och uppdatering av ClickHouse-versioner. Det kan vara anvÀndbart för utvecklare som redan arbetar aktivt med Yandex DBMS och Àr intresserade av dess nutid och framtid. Som standard Àr svaren av Alexey Milovidov, om inte annat skrivits.
Var försiktig, det Àr mycket text under snittet. Vi hoppas att innehÄllet med frÄgor hjÀlper dig att navigera.
InnehÄll
Om du inte vill lÀsa texten kan du se inspelningen av sammankomsterna . Tidskoder finns i den första kommentaren under videon.
ClickHouse uppdateras stÀndigt, men vÄr data Àr det inte. Vad ska man göra Ät det?
ClickHouse uppdateras stÀndigt och vÄr data, som optimerades slutbearbetad, uppdateras inte och finns i en sÀkerhetskopia.
LÄt oss sÀga att vi hade nÄgot problem och att data gick förlorade. Vi bestÀmde oss för att ÄterstÀlla, och det visade sig att de gamla partitionerna, som Àr lagrade pÄ backupservrarna, skiljer sig mycket frÄn den för nÀrvarande anvÀnda versionen av ClickHouse. Vad ska man göra i en sÄdan situation, och Àr det möjligt?
En situation dÀr du har ÄterstÀllt data frÄn en sÀkerhetskopia i ett gammalt format, men det inte ansluter till den nya versionen, Àr omöjligt. Vi ser till att dataformatet i ClickHouse alltid förblir bakÄtkompatibelt. Detta Àr mycket viktigare Àn bakÄtkompatibilitet i funktionalitet om beteendet hos nÄgon funktion som sÀllan anvÀnds har förÀndrats. Den nya versionen av ClickHouse ska alltid kunna lÀsa data som finns lagrad pÄ disken. Detta Àr lagen.
Vilka Àr de nuvarande bÀsta metoderna för att sÀkerhetskopiera data frÄn ClickHouse?
Hur gör man sÀkerhetskopior, med hÀnsyn till att vi har optimerat slutoperationer, en enorm databas med terabyte och data som uppdateras, till exempel, för de senaste tre dagarna, och sedan hÀnder inga procedurer med det?
Vi kan göra vÄr egen lösning och skriva pÄ bash: samla in dessa sÀkerhetskopior pÄ ett och annat sÀtt. Kanske finns det inget behov av att krycka nÄgot, och cykeln uppfanns för lÀnge sedan?
LÄt oss börja med de bÀsta metoderna. Mina kollegor rekommenderar alltid, som svar pÄ frÄgor om sÀkerhetskopior, att pÄminna dem om Yandex.Cloud-tjÀnsten, dÀr detta problem redan har lösts. SÄ anvÀnd den om möjligt.
Det finns ingen komplett lösning för sÀkerhetskopiering, hundra procent inbyggd i ClickHouse. Det finns nÄgra Àmnen som kan anvÀndas. För att fÄ en komplett lösning mÄste du antingen mixtra lite manuellt, eller skapa omslag i form av skript.
Jag börjar med de enklaste lösningarna och slutar med de mest sofistikerade, beroende pÄ mÀngden data och storleken pÄ klustret. Ju större kluster, desto mer komplex blir lösningen.
Om tabellen med data bara upptar nÄgra fÄ gigabyte kan sÀkerhetskopieringen göras sÄ hÀr:
- Spara tabelldefinition, dvs metadata â visa skapa tabell.
- Gör en dump med ClickHouse-klienten - vÀlj * frÄn bordet att arkivera. Som standard kommer du att fÄ en fil i TabSeparated-format. Om du vill bli mer effektiv kan du göra det i Native-format.
Om mÀngden data Àr större kommer sÀkerhetskopieringen att ta mer tid och mycket utrymme. Detta kallas en logisk sÀkerhetskopia, den Àr inte knuten till ClickHouse-dataformatet. Om det Àr det kan du som en sista utvÀg ta en sÀkerhetskopia och ladda upp den till MySQL för ÄterstÀllning.
För mer avancerade fall har ClickHouse en inbyggd möjlighet att skapa en ögonblicksbild av partitioner i det lokala filsystemet. Denna funktion Àr tillgÀnglig pÄ begÀran Àndra tabellfrysningspartition. Eller bara Àndra bordsfrysning - Det hÀr Àr en ögonblicksbild av hela tabellen.
Ăgonblicksbilden kommer att skapas konsekvent för en tabell pĂ„ en skĂ€rva, det vill sĂ€ga det Ă€r omöjligt att skapa en konsekvent ögonblicksbild av hela klustret pĂ„ detta sĂ€tt. Men för de flesta uppgifter finns det inget sĂ„dant behov, och det rĂ€cker med att utföra en begĂ€ran pĂ„ varje skĂ€rva och fĂ„ en konsekvent ögonblicksbild. Den skapas i form av hĂ„rda lĂ€nkar och tar dĂ€rför inte upp ytterligare utrymme. DĂ€refter kopierar du denna ögonblicksbild till backupservern eller till lagringen som du anvĂ€nder för sĂ€kerhetskopiering.
Att ÄterstÀlla en sÄdan sÀkerhetskopia Àr ganska enkelt. Skapa först tabeller med hjÀlp av befintliga tabelldefinitioner. Kopiera sedan de sparade ögonblicksbilderna av partitionerna till Directory-Detached för dessa tabeller och kör frÄgan fÀst partition. Denna lösning Àr ganska lÀmplig för de mest allvarliga mÀngderna data.
Ibland behöver du nĂ„got Ă€nnu coolare - i de fall du har tiotals eller till och med hundratals terabyte pĂ„ varje server och hundratals servrar. Det finns en lösning hĂ€r som jag hĂ€mtade frĂ„n mina kollegor frĂ„n Yandex.Metrica. Jag skulle inte rekommendera den till alla â lĂ€s den och avgör sjĂ€lv om den passar eller inte.
Först mÄste du skapa flera servrar med stora diskhyllor. DÀrefter, pÄ dessa servrar, höj flera ClickHouse-servrar och konfigurera dem sÄ att de fungerar som en annan replik för samma skÀrvor. Och anvÀnd sedan ett filsystem eller nÄgot verktyg pÄ dessa servrar som lÄter dig skapa ögonblicksbilder. Det finns tvÄ alternativ hÀr. Det första alternativet Àr LVM-ögonblicksbilder, det andra alternativet Àr ZFS pÄ Linux.
Efter det, varje dag du behöver skapa en ögonblicksbild, kommer den att ligga och ta upp lite plats. Naturligtvis, om data Àndras, kommer mÀngden utrymme att öka med tiden. Denna ögonblicksbild kan tas ut nÀr som helst och data ÄterstÀllas, en sÄ konstig lösning. Dessutom mÄste vi ocksÄ begrÀnsa dessa repliker i konfigurationen sÄ att de inte försöker bli ledare.
Kommer det att vara möjligt att organisera en kontrollerad efterslÀpning av repliker i axlarna?
I Är planerar du att göra schakt i ClickHouse. Kommer det att vara möjligt att organisera en kontrollerad efterslÀpning av repliker i dem? Vi skulle vilja anvÀnda den för att skydda oss frÄn negativa scenarier med förÀndringar och andra förÀndringar.
Ăr det möjligt att göra nĂ„gon form av Ă„terstĂ€llning för förĂ€ndringar? Till exempel, i ett befintligt schakt, ta och sĂ€g att du tillĂ€mpar Ă€ndringarna tills detta ögonblick, och frĂ„n detta ögonblick slutar du tillĂ€mpa Ă€ndringarna?
Om ett kommando kom till vÄrt kluster och bröt det, sÄ har vi en villkorlig replik med en timmes fördröjning, dÀr vi kan sÀga att lÄt oss anvÀnda det för tillfÀllet, men vi kommer inte att tillÀmpa Àndringar pÄ det under de senaste tio minuterna?
Först om den kontrollerade efterslÀpningen av repliker. Det fanns en sÄdan begÀran frÄn anvÀndare, och vi skapade ett problem pÄ Github med begÀran: "Om nÄgon behöver det hÀr, gilla det, lÀgg ett hjÀrta." Ingen levererade och frÄgan avslutades. Du kan dock redan nu fÄ denna möjlighet genom att stÀlla in ClickHouse. Det Àr sant, frÄn och med version 20.3.
ClickHouse utför stÀndigt datasammanslagningar i bakgrunden. NÀr en sammanslagning Àr klar ersÀtts en viss uppsÀttning databitar med en större bit. Samtidigt fortsÀtter databitar som fanns dÀr att ligga kvar pÄ disken en tid.
För det första fortsÀtter de att lagras sÄ lÀnge det finns utvalda frÄgor som anvÀnder dem, för att tillhandahÄlla icke-blockerande operation. Utvalda frÄgor lÀses enkelt frÄn gamla bitar.
För det andra finns det ocksÄ en tidsgrÀns - gamla bitar av data ligger pÄ disken i Ätta minuter. Dessa Ätta minuter kan anpassas och till och med förvandlas till en dag. Detta kommer att kosta diskutrymme: beroende pÄ dataflödet visar det sig att data den sista dagen inte bara kommer att fördubblas, den kan bli fem gÄnger mer. Men om det finns ett allvarligt problem kan du stoppa ClickHouse-servern och reda ut allt.
Nu uppstÄr frÄgan om hur detta skyddar mot förÀndringar. Det Àr vÀrt att ta en djupare titt hÀr, för i Àldre versioner av ClickHouse fungerade altern pÄ ett sÄdant sÀtt att den helt enkelt bytte bitar direkt. Det finns en bit data med vissa filer, och vi gör t.ex. Àndra droppkolumnen. Sedan tas denna kolumn fysiskt bort frÄn alla bitar.
Men frÄn och med version 20.3 har Àndringsmekanismen Àndrats helt, och nu Àr databitar alltid oförÀnderliga. De förÀndras inte alls - förÀndringar fungerar nu ungefÀr pÄ samma sÀtt som sammanslagningar. IstÀllet för att ersÀtta en del pÄ plats skapar vi en ny. I den nya biten blir filer som inte har Àndrats hÄrdlÀnkar, och om vi tar bort en kolumn kommer den helt enkelt att saknas i den nya biten. Den gamla biten kommer att raderas som standard efter Ätta minuter, och hÀr kan du justera instÀllningarna som nÀmns ovan.
Detsamma gÀller förÀndringar som mutationer. NÀr du gör Àndra radera eller Àndra uppdatering, det Àndrar inte biten, utan skapar en ny. Och raderar sedan den gamla.
Vad hÀnder om tabellstrukturen har Àndrats?
Hur Ă„terstĂ€ller man en sĂ€kerhetskopia som gjordes med det gamla schemat? Och den andra frĂ„gan handlar om fallet med ögonblicksbilder och filsystemverktyg. Ăr Btrfs bra hĂ€r istĂ€llet för ZFS pĂ„ Linux LVM?
Om du gör fÀst partition partitioner med en annan struktur, kommer ClickHouse att berÀtta att detta inte Àr möjligt. Detta Àr lösningen. Den första Àr att skapa en temporÀr tabell av typen MergeTree med den gamla strukturen, bifoga data dÀr med attach och göra en ÀndringsfrÄga. Sedan kan du antingen kopiera eller överföra dessa uppgifter och bifoga igen, eller anvÀnda en begÀran Àndra tabell flytta partition.
Nu Àr den andra frÄgan om Btrfs kan anvÀndas. Till att börja med, om du har LVM, rÀcker det med LVM-ögonblicksbilder, och filsystemet kan vara ext4, det spelar ingen roll. Med Btrts beror allt pÄ din erfarenhet av att anvÀnda det. Det hÀr Àr ett moget filsystem, men det finns fortfarande vissa misstankar om hur allt kommer att fungera i praktiken i ett visst scenario. Jag skulle inte rekommendera att anvÀnda detta om du inte har Btrfs i produktion.
Vilka Àr de nuvarande bÀsta metoderna för omdelning av data?
FrĂ„gan om omskĂ€rning Ă€r komplex och mĂ„ngfacetterad. Det finns flera möjliga svar hĂ€r. Du kan gĂ„ frĂ„n ena sidan och sĂ€ga sĂ„ hĂ€r â ClickHouse har inte en inbyggd resharding-funktion. Men jag Ă€r rĂ€dd att det hĂ€r svaret inte kommer att passa nĂ„gon. DĂ€rför kan du gĂ„ frĂ„n andra sidan och sĂ€ga att ClickHouse har mĂ„nga sĂ€tt att Ă„terföra data.
Om klustret fÄr ont om utrymme eller det inte kan hantera belastningen lÀgger du till nya servrar. Men dessa servrar Àr tomma som standard, det finns ingen data pÄ dem, det finns ingen belastning. Du mÄste ordna om data sÄ att den blir jÀmnt spridd över det nya, större klustret.
Det första sÀttet detta kan göras Àr att kopiera en del av partitionerna till nya servrar med hjÀlp av en begÀran Àndra tabellhÀmtningspartition. Till exempel hade du partitioner per mÄnad, och du tar den första mÄnaden av 2017 och kopierar den till en ny server och kopierar sedan den tredje mÄnaden till nÄgon annan ny server. Och det gör man tills det blir mer eller mindre jÀmnt.
Ăverföring kan endast utföras för de partitioner som inte Ă€ndras under inspelning. För nya partitioner mĂ„ste inspelningen inaktiveras, eftersom deras överföring inte Ă€r atomĂ€r. Annars kommer du att fĂ„ dubbletter eller luckor i data. Denna metod Ă€r dock praktisk och fungerar ganska effektivt. FĂ€rdiga komprimerade partitioner sĂ€nds över nĂ€tverket, det vill sĂ€ga att data inte komprimeras eller omkodas.
Den hÀr metoden har en nackdel, och det beror pÄ skÀrningsschemat, om du lovade detta skÀrningsschema, vilken skÀrningsnyckel du hade. I ditt exempel för fallet med mÀtvÀrden Àr sharding-nyckeln sökvÀgens hash. NÀr du vÀljer en distribuerad tabell gÄr den till alla skÀrvor i klustret pÄ en gÄng och tar data dÀrifrÄn.
Det betyder att det faktiskt inte spelar nÄgon roll för dig vilken data som hamnade pÄ vilken skÀrva. Huvudsaken Àr att data lÀngs en vÀg hamnar pÄ en skÀrva, men vilken Àr inte viktig. I det hÀr fallet Àr överföring av fÀrdiga partitioner perfekt, för med utvalda frÄgor kommer du ocksÄ att fÄ fullstÀndiga data - oavsett om det Àr före omskÀrning eller efter, schemat spelar ingen roll.
Men det finns fall som Àr mer komplexa. Om du pÄ applikationslogiknivÄn förlitar dig pÄ ett speciellt skÀrningsschema, att denna klient Àr placerad pÄ en sÄdan och en sÄdan skÀrva, och begÀran kan skickas direkt dit, och inte till den distribuerade tabellen. Eller sÄ anvÀnder du en ganska ny version av ClickHouse och har aktiverat instÀllningen optimera hoppa över oanvÀnda skÀrvor. I det hÀr fallet, under urvalsfrÄgan, kommer uttrycket i where-avsnittet att analyseras och det kommer att berÀknas vilka shards som behöver anvÀndas enligt sharding-schemat. Detta fungerar förutsatt att data Àr uppdelade exakt enligt detta skÀrningsschema. Om du ordnade om dem manuellt kan korrespondensen Àndras.
SÄ det hÀr Àr metod nummer ett. Och jag vÀntar pÄ ditt svar, om metoden Àr lÀmplig, eller lÄt oss gÄ vidare.
Vladimir Kolobaev, ledande systemadministratör i Avito: Alexey, metoden som du nÀmnde fungerar inte sÀrskilt bra nÀr du behöver fördela belastningen, inklusive lÀsning. Vi kan ta en partition som Àr mÄnatlig och kan ta föregÄende mÄnad till en annan nod, men nÀr en begÀran kommer om denna data kommer vi bara att ladda den. Men vi skulle vilja ladda hela klustret, för annars kommer hela lÀsbelastningen under en tid att bearbetas av tvÄ skÀrvor.
Alexey Milovidov: Svaret hÀr Àr konstigt - ja, det Àr dÄligt, men det kanske fungerar. Jag ska förklara exakt hur. Det Àr vÀrt att titta pÄ belastningsscenariot som kommer bakom dina data. Om detta Àr övervakningsdata kan vi nÀstan sÀkert sÀga att den stora majoriteten av förfrÄgningarna Àr för fÀrska data.
Du installerade nya servrar, migrerade gamla partitioner, men Àndrade ocksÄ hur fÀrsk data registreras. Och fÀrsk data kommer att spridas över hela klustret. Efter bara fem minuter kommer förfrÄgningar för de senaste fem minuterna att ladda klustret jÀmnt, efter ett dygn kommer förfrÄgningar under XNUMX timmar att ladda klustret jÀmnt. Och förfrÄgningar för föregÄende mÄnad kommer tyvÀrr bara att gÄ till en del av klusterservrarna.
Men ofta har du inga förfrÄgningar specifikt för februari 2019. Med största sannolikhet, om förfrÄgningar gÄr in i 2019, kommer de att gÀlla för hela 2019 - under en lÄng tidsperiod och inte för ett litet intervall. Och sÄdana förfrÄgningar kommer ocksÄ att kunna ladda klustret jÀmnt. Men generellt sett Àr ditt pÄpekande helt korrekt att detta Àr en ad hoc-lösning som inte sprider datan helt jÀmnt.
Jag har nÄgra fler punkter för att svara pÄ frÄgan. En av dem handlar om hur man initialt utformar ett skÀrningsschema sÄ att omskÀrning skulle orsaka mindre smÀrta. Detta Àr inte alltid möjligt.
Till exempel har du övervakningsdata. Ăvervakningsdata vĂ€xer av tre anledningar. Den första Ă€r ackumuleringen av historiska data. Det andra Ă€r trafiktillvĂ€xt. Och det tredje Ă€r en ökning av antalet saker som Ă€r föremĂ„l för övervakning. Det finns nya mikrotjĂ€nster och mĂ€tvĂ€rden som mĂ„ste sparas.
Det Àr möjligt att av dessa Àr den största ökningen förknippad med det tredje skÀlet - ökningen av anvÀndningen av övervakning. Och i det hÀr fallet Àr det vÀrt att titta pÄ belastningens natur, vilka Àr de viktigaste urvalsfrÄgorna. GrundlÀggande urvalsfrÄgor kommer sannolikt att baseras pÄ nÄgon delmÀngd av mÀtvÀrden.
Till exempel CPU-anvÀndning pÄ vissa servrar av nÄgon tjÀnst. Det visar sig att det finns en viss delmÀngd av nycklar som du fÄr denna data med. Och sjÀlva begÀran om denna data Àr troligen ganska enkel och slutförs pÄ tiotals millisekunder. AnvÀnds för övervakning av tjÀnster och instrumentpaneler. Jag hoppas att jag förstÄr detta rÀtt.
Vladimir Kolobaev: Faktum Àr att vi vÀldigt ofta vÀdjar till historiska data, eftersom vi jÀmför den nuvarande situationen med den historiska i realtid. Och det Àr viktigt för oss att ha snabb tillgÄng till en stor mÀngd data, och ClickHouse gör ett utmÀrkt jobb med detta.
Du har helt rÀtt, vi upplever de flesta lÀsförfrÄgningar den sista dagen, som vilket övervakningssystem som helst. Men samtidigt Àr belastningen pÄ historisk data ocksÄ ganska stor. Det Àr i princip frÄn ett varningssystem som gÄr runt var trettionde sekund och sÀger till ClickHouse: "Ge mig data för de senaste sex veckorna. Bygg nu nÄgot slags glidande medelvÀrde för mig frÄn dem, och lÄt oss jÀmföra det nuvarande vÀrdet med det historiska."
Jag skulle vilja sÀga att för sÄdana mycket nyliga förfrÄgningar har vi ytterligare en liten tabell dÀr vi bara lagrar tvÄ dagars data, och de viktigaste förfrÄgningarna flyger in i den. Vi skickar bara stora historiska frÄgor till det stora sönderdelade bordet.
Alexey Milovidov: TyvÀrr visar det sig vara dÄligt applicerbart för ditt scenario, men jag kommer att berÀtta en beskrivning av tvÄ dÄliga och komplexa skÀrningsscheman som inte behöver anvÀndas, men som anvÀnds i mina vÀnners tjÀnst.
Det finns ett huvudkluster med Yandex.Metrica-evenemang. HÀndelser Àr sidvisningar, klick och omvandlingar. De flesta förfrÄgningar gÄr till en specifik webbplats. Du öppnar Yandex.Metrica-tjÀnsten, du har en webbplats - avito.ru, gÄ till rapporten och en begÀran görs för din webbplats.
Men det finns andra förfrÄgningar - analytiska och globala - som görs av interna analytiker. För sÀkerhets skull noterar jag att interna analytiker endast gör förfrÄgningar om Yandex-tjÀnster. Men ÀndÄ upptar Àven Yandex-tjÀnster en betydande del av all data. Dessa Àr förfrÄgningar inte för specifika rÀknare, utan för bredare filtrering.
Hur organiserar man data pÄ ett sÄdant sÀtt att allt fungerar effektivt för en rÀknare, och globala frÄgor ocksÄ? En annan svÄrighet Àr att antalet förfrÄgningar i ClickHouse för Metrics-klustret Àr flera tusen per sekund. Samtidigt kan en ClickHouse-server inte hantera icke-triviala förfrÄgningar, till exempel flera tusen per sekund.
Klusterstorleken Àr sexhundra-nÄgot servrar. Om du helt enkelt drar en distribuerad tabell över detta kluster och skickar flera tusen förfrÄgningar dit kommer det att bli Ànnu vÀrre Àn att skicka dem till en server. à andra sidan avfÀrdas omedelbart alternativet att data sprids ut jÀmnt, och vi gÄr och begÀr frÄn alla servrar.
Det finns ett alternativ som Àr diametralt motsatt. FörestÀll dig om vi delar data över webbplatser, och en begÀran om en webbplats gÄr till en fragment. Nu kommer klustret att kunna hantera tiotusen förfrÄgningar per sekund, men pÄ en skÀrpa kommer varje begÀran att fungera för lÄngsamt. Det kommer inte lÀngre att skalas i termer av genomströmning. Speciellt om detta Àr sajten avito.ru. Jag kommer inte att avslöja hemligheten om jag sÀger att Avito Àr en av de mest besökta sajterna i RuNet. Och att bearbeta den pÄ en skÀrva skulle vara galenskap.
DÀrför Àr skÀrningsschemat utformat pÄ ett mer listigt sÀtt. Hela klustret Àr uppdelat i ett antal kluster, som vi kallar lager. Varje kluster innehÄller frÄn ett dussin till flera dussin skÀrvor. Det finns totalt trettionio sÄdana kluster.
Hur skalar allt detta? Antalet kluster förÀndras inte - eftersom det var trettionio för nÄgra Är sedan Àr det fortfarande sÄ. Men inom var och en av dem ökar vi gradvis antalet skÀrvor nÀr vi samlar data. Och skÀrningsschemat som helhet Àr sÄ hÀr: dessa kluster Àr uppdelade i webbplatser, och för att förstÄ vilken webbplats som finns pÄ vilket kluster anvÀnds en separat metabas i MySQL. En plats - pÄ ett kluster. Och inuti den sker skÀrning enligt besökar-ID.
Vid inspelning delar vi dem med resten av uppdelningen av besöks-ID. Men nÀr man lÀgger till en ny skÀrpa Àndras skÀrningsschemat, vi fortsÀtter att dela upp, men med en Äterstod av divisionen med ett annat nummer. Det betyder att en besökare redan finns pÄ flera servrar, och du kan inte lita pÄ detta. Detta görs enbart för att sÀkerstÀlla att data komprimeras bÀttre. Och nÀr vi gör förfrÄgningar gÄr vi till tabellen Distributed, som tittar pÄ klustret och har Ätkomst till dussintals servrar. Det hÀr Àr ett sÄ dumt upplÀgg.
Men min berÀttelse kommer att vara ofullstÀndig om jag inte sÀger att vi övergav detta upplÀgg. I det nya schemat Àndrade vi allt och kopierade all data med clickhouse-copier.
I det nya systemet Àr alla platser indelade i tvÄ kategorier - stora och smÄ. Jag vet inte hur tröskeln valdes, men resultatet blev att stora sajter registreras pÄ ett kluster, dÀr det finns 120 skÀrvor med tre repliker vardera - det vill sÀga 360 servrar. Och skÀrvningsschemat Àr sÄdant att varje begÀran gÄr till alla skÀrvor pÄ en gÄng. Om du nu öppnar en rapportsida för avito.ru i Yandex.Metrica, kommer begÀran att gÄ till 120 servrar. Det finns fÄ stora sajter i RuNet. Och förfrÄgningarna Àr inte tusen per sekund, utan till och med mindre Àn hundra. Allt detta tuggas i tysthet av tabellen Distributed, som var och en av dem bearbetar med 120 servrar.
Och det andra klustret Àr för smÄ platser. HÀr Àr ett skÀrningsschema baserat pÄ webbplatsens ID, och varje begÀran gÄr till exakt en skÀrva.
ClickHouse har ett clickhouse-kopiatorverktyg. Kan du berÀtta om henne?
Jag ska genast sÀga att den hÀr lösningen Àr mer besvÀrlig och nÄgot mindre produktiv. Fördelen Àr att den smetar ut data helt enligt det mönster du anger. Men nackdelen med verktyget Àr att det inte skÀrs om alls. Den kopierar data frÄn ett klusterschema till ett annat klusterschema.
Det betyder att för att det ska fungera mÄste du ha tvÄ kluster. De kan finnas pÄ samma servrar, men ÀndÄ kommer data inte att flyttas stegvis, utan kommer att kopieras.
Det fanns till exempel fyra servrar, nu Àr det Ätta. Du skapar en ny distribuerad tabell pÄ alla servrar, nya lokala tabeller och startar clickhouse-copier, anger i den arbetsschemat som den ska lÀsa dÀrifrÄn, accepterar det nya sönderdelningsschemat och överför data dit. Och pÄ gamla servrar kommer du att behöva en och en halv gÄnger mer utrymme Àn det finns nu, eftersom den gamla data mÄste finnas kvar pÄ dem, och hÀlften av samma gamla data kommer att anlÀnda ovanpÄ dem. Om du pÄ förhand trodde att data mÄste omskÀras och det finns utrymme, sÄ Àr den hÀr metoden lÀmplig.
Hur fungerar clickhouse-kopiator inuti? Det delar upp allt arbete i en uppsÀttning uppgifter för att bearbeta en partition av en tabell pÄ en skÀrva. Alla dessa uppgifter kan utföras parallellt, och clickhouse-copier kan köras pÄ olika maskiner i flera instanser, men vad den gör för en partition Àr inget annat Àn en insÀttningsval. Data lÀses, dekomprimeras, partitioneras om, komprimeras sedan igen, skrivs nÄgonstans och sorteras om. Det hÀr Àr ett tuffare beslut.
Du hade en pilotgrej som hette resharding. Vad med henne?
Redan 2017 hade du en pilotsak som heter resharding. Det finns till och med ett alternativ i ClickHouse. Som jag förstÄtt det tog det inte fart. Kan du berÀtta varför detta hÀnde? Det verkar vara vÀldigt relevant.
Hela problemet Àr att om det Àr nödvÀndigt att skÀra om data pÄ plats, krÀvs mycket komplex synkronisering för att göra detta atomÀrt. NÀr vi började titta pÄ hur denna synkronisering fungerar stod det klart att det fanns grundlÀggande problem. Och dessa grundlÀggande problem Àr inte bara teoretiska, utan började genast visa sig i praktiken i form av nÄgot som kan förklaras vÀldigt enkelt - ingenting fungerar.
Ăr det möjligt att slĂ„ samman alla bitar av data innan de flyttas till lĂ„ngsamma diskar?
FrÄga om TTL med övergÄngen till alternativet för lÄngsam disk i samband med sammanslagningar. Finns det nÄgot sÀtt, annat Àn via cron, att slÄ samman alla delar till en innan du flyttar dem till lÄngsamma skivor?
Svaret pÄ frÄgan Àr det möjligt att pÄ nÄgot sÀtt automatiskt limma alla bitar i en innan du överför dem - nej. Jag tror inte att detta Àr nödvÀndigt. Du behöver inte slÄ samman alla delar till en, utan bara rÀkna med att de automatiskt kommer att överföras till lÄngsamma diskar.
Vi har tvÄ kriterier för överföringsregler. Den första Àr som den Àr fylld. Om den nuvarande lagringsnivÄn har mindre Àn en viss procentandel ledigt utrymme vÀljer vi en bit och flyttar den till lÄngsammare lagring. Eller snarare, inte lÄngsammare, utan nÀsta - som du konfigurerar.
Det andra kriteriet Àr storlek. Det handlar om att flytta stora bitar. Du kan justera tröskeln efter det lediga utrymmet pÄ snabbdisken, och data överförs automatiskt.
Hur migrerar man till nya versioner av ClickHouse om det inte finns nÄgot sÀtt att kontrollera kompatibiliteten i förvÀg?
Detta Àmne diskuteras regelbundet med hÀnsyn till olika versioner, och fortfarande. 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. Vad Àr det bÀsta sÀttet att migrera till nya versioner utan att kunna kontrollera kompatibiliteten i sandlÄdan i förvÀg?
Det finns flera "gyllene" regler hÀr. Först - . Den Àr stor, men det finns separata stycken om bakÄtinkompatibla Àndringar. Behandla inte dessa punkter som en röd flagga. Dessa Àr vanligtvis mindre inkompatibiliteter som involverar nÄgon kantfunktionalitet som du med stor sannolikhet inte anvÀnder.
För det andra, om det inte finns nĂ„got sĂ€tt att kontrollera kompatibiliteten i sandlĂ„dan och du vill uppdatera omedelbart i produktionen, Ă€r rekommendationen att du inte behöver göra detta. Skapa först en sandlĂ„da och testa. Om det inte finns nĂ„gon testmiljö sĂ„ har du med största sannolikhet inte ett sĂ€rskilt stort företag, vilket innebĂ€r att du kan kopiera en del av datan till din bĂ€rbara dator och se till att allt fungerar korrekt pĂ„ den. Du kan till och med höja flera repliker lokalt pĂ„ din maskin. Eller sĂ„ kan du hĂ€mta en ny version nĂ„gonstans i nĂ€rheten och ladda upp en del av datan dĂ€r â det vill sĂ€ga skapa en improviserad testmiljö.
En annan regel Àr att inte uppdatera förrÀn en vecka efter releasen av versionen pÄ grund av buggar i produktionen och efterföljande snabbfixar. LÄt oss ta reda pÄ numreringen av ClickHouse-versioner för att inte bli förvirrade.
Det finns version 20.3.4. Siffran 20 indikerar tillverkningsĂ„ret - 2020. Ur synvinkeln av vad som finns inuti spelar det ingen roll, sĂ„ vi kommer inte att uppmĂ€rksamma det. NĂ€sta - 20.3. Vi ökar den andra siffran - i det hĂ€r fallet 3 - varje gĂ„ng vi slĂ€pper en release med lite ny funktionalitet. Om vi ââvill lĂ€gga till nĂ„gon funktion till ClickHouse mĂ„ste vi öka detta antal. Det vill sĂ€ga, i version 20.4 kommer ClickHouse att fungera Ă€nnu bĂ€ttre. Den tredje siffran Ă€r 20.3.4. HĂ€r 4 Ă€r antalet patchutgĂ„vor dĂ€r vi inte lagt till nya funktioner, utan fixat nĂ„gra buggar. Och 4 betyder att vi gjorde det fyra gĂ„nger.
Tro inte att det hÀr Àr nÄgot hemskt. Vanligtvis kan anvÀndaren installera den senaste versionen och det kommer att fungera utan problem med drifttid per Är. Men förestÀll dig att i nÄgon funktion för att bearbeta bitmappar, som lades till av vÄra kinesiska kamrater, kraschar servern nÀr felaktiga argument skickas. Vi har ett ansvar att fixa detta. Vi kommer att slÀppa en ny patchversion och ClickHouse kommer att bli mer stabil.
Om du har ClickHouse igÄng i produktion och en ny version av ClickHouse slÀpps med ytterligare funktioner - till exempel Àr 20.4.1 den allra första, skynda dig inte att sÀtta den i produktion den första dagen. Varför behövs det överhuvudtaget? Om du inte anvÀnder ClickHouse Ànnu kan du installera det, och med största sannolikhet kommer allt att bli bra. Men om ClickHouse redan fungerar stabilt, hÄll dÄ ett öga pÄ patchar och uppdateringar för att se vilka problem vi fixar.
Kirill Shvakov: Jag skulle vilja lÀgga till lite om testmiljöer. Alla Àr vÀldigt rÀdda för testmiljöer och av nÄgon anledning tror de att om man har ett vÀldigt stort ClickHouse-kluster sÄ ska testmiljön vara varken eller minst tio gÄnger mindre. Det Àr inte alls sÄ.
Jag kan berĂ€tta frĂ„n mitt eget exempel. Jag har ett projekt, och det finns ClickHouse. VĂ„r testmiljö Ă€r bara för honom - det hĂ€r Ă€r en liten virtuell maskin i Hetzner för tjugo euro, dĂ€r absolut allt Ă€r utplacerat. För att göra detta har vi full automatisering i Ansible, och dĂ€rför spelar det i princip ingen roll vart man ska gĂ„ â till hĂ„rdvaruservrar eller bara distribuera i virtuella maskiner.
Vad kan göras? Det skulle vara trevligt att ge ett exempel i ClickHouse-dokumentationen pÄ hur man distribuerar ett litet kluster i ditt eget hem - i Docker, i LXC, kanske skapa en Ansible-spelbok, eftersom olika mÀnniskor har olika distributioner. Detta kommer att förenkla mycket. NÀr du tar och distribuerar ett kluster pÄ fem minuter Àr det mycket lÀttare att försöka komma pÄ nÄgot. Detta Àr mycket bekvÀmare, eftersom att trycka in i en produktionsversion som du inte har testat Àr en vÀg till ingenstans. Ibland fungerar det och ibland inte. Och dÀrför Àr det dÄligt att hoppas pÄ framgÄng.
Maxim Kotyakov, senior backend-ingenjör Avito: Jag kommer att lĂ€gga till lite om testmiljöer frĂ„n en rad problem som stora företag stĂ„r inför. Vi har ett fullfjĂ€drat ClickHouse-acceptanskluster, vad gĂ€ller datascheman och instĂ€llningar Ă€r det en exakt kopia av det som Ă€r i produktion. Detta kluster distribueras i ganska nedgĂ„ngna behĂ„llare med ett minimum av resurser. Vi skriver en viss procent av produktionsdata dĂ€r, lyckligtvis gĂ„r det att replikera strömmen i Kafka. Allt dĂ€r Ă€r synkroniserat och skalat â bĂ„de vad gĂ€ller kapacitet och flöde, och i teorin borde det, allt annat lika, bete sig som produktion i termer av mĂ„tt. Allt potentiellt explosivt rullas först upp pĂ„ detta stativ och lĂ€mnas dĂ€r i flera dagar tills det Ă€r klart. Men naturligtvis Ă€r den hĂ€r lösningen dyr, svĂ„r och har supportkostnader som inte Ă€r lika med noll.
Alexey Milovidov: Jag ska berÀtta hur testmiljön för vÄra vÀnner frÄn Yandex.Metrica Àr. Ett kluster hade 600-udda servrar, ett annat hade 360, och det finns ett tredje och flera kluster. Testmiljön för en av dem Àr helt enkelt tvÄ skÀrvor med tvÄ repliker i varje. Varför tvÄ skÀrvor? SÄ att du inte Àr ensam. Och det borde finnas repliker ocksÄ. Bara ett visst minimibelopp som du har rÄd med.
Denna testmiljö lÄter dig kontrollera om dina frÄgor fungerar och om nÄgot större Àr trasigt. Men ofta uppstÄr problem av en helt annan karaktÀr, nÀr allt fungerar, men det Àr nÄgra smÄ förÀndringar i belastningen.
LÄt mig ge dig ett exempel. Vi bestÀmde oss för att installera en ny version av ClickHouse. Det har lagts ut i en testmiljö, automatiserade tester har slutförts i sjÀlva Yandex.Metrica, som jÀmför data om den gamla versionen och den nya, som kör hela pipelinen. Och naturligtvis gröna tester av vÄr CI. Annars skulle vi inte ens ha föreslagit denna version.
Allt Àr bra. Vi börjar gÄ in i produktionen. 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: belastningen ökade faktiskt flera gÄnger under utrullningen, och minskade tillbaka nÀr de rullade ut. Sedan började vi rulla tillbaka versionen. Och belastningen ökade pÄ samma sÀtt och föll tillbaka pÄ samma sÀtt. SÄ slutsatsen Àr denna: belastningen har ökat pÄ grund av layouten, inget överraskande.
DÄ var det svÄrt att övertyga kollegor att installera den nya versionen. Jag sÀger: "Det Àr okej, rulla ut. HÄller tummarna, allt kommer att fungera. Nu har belastningen pÄ graferna ökat, men allt Àr bra. HÄll ut." I allmÀnhet gjorde vi detta, och det Àr det - versionen slÀpptes för produktion. Men nÀstan med varje layout uppstÄr liknande problem.
Kill query Àr tÀnkt att döda querys, men det gör den inte. Varför?
En anvÀndare, nÄgon slags analytiker, kom till mig och skapade en förfrÄgan som satte mitt ClickHouse-kluster. NÄgon nod eller ett helt kluster, beroende pÄ vilken replik eller skÀrva begÀran gick till. Jag ser att alla CPU-resurser pÄ den hÀr servern finns i en hylla, allt Àr rött. Samtidigt svarar ClickHouse sjÀlv pÄ förfrÄgningar. Och jag skriver: "SnÀlla visa mig, processlista, vilken begÀran som genererade denna galenskap."
Jag hittar denna begÀran och skriver döda till den. Och jag ser att ingenting hÀnder. Min server Àr i en hylla, ClickHouse ger mig sedan nÄgra kommandon, visar att servern Àr vid liv och allt Àr bra. Men jag har försÀmring i alla anvÀndarförfrÄgningar, försÀmring börjar med poster i ClickHouse, och min kill-frÄga fungerar inte. Varför? Jag trodde att kill query skulle döda frÄgor, men det gör det inte.
Nu kommer det ett ganska konstigt svar. PoÀngen Àr att kill query inte dödar querys.
Kill query markerar en liten ruta som heter "Jag vill att den hÀr frÄgan ska dödas." Och sjÀlva begÀran tittar pÄ denna flagga nÀr varje block bearbetas. Om den Àr instÀlld slutar begÀran att fungera. Det visar sig att ingen dödar förfrÄgan, han mÄste sjÀlv kontrollera allt och sluta. Och detta bör fungera i alla fall dÀr begÀran Àr i tillstÄndet att bearbeta datablock. Den kommer att behandla nÀsta datablock, kontrollera flaggan och stoppa.
Detta fungerar inte i fall dÀr begÀran Àr blockerad pÄ nÄgon operation. Det Àr sant, troligen Àr detta inte ditt fall, eftersom det enligt dig anvÀnder massor av serverresurser. Det Àr möjligt att detta inte fungerar vid extern sortering och i vissa andra detaljer. Men i allmÀnhet borde detta inte hÀnda, det Àr en bugg. Och det enda jag kan rekommendera Àr att uppdatera ClickHouse.
Hur berÀknar man svarstid under lÀsbelastning?
Det finns en tabell som lagrar artikelaggregat - olika rĂ€knare. Antalet rader Ă€r cirka hundra miljoner. Ăr det möjligt att rĂ€kna med en förutsĂ€gbar svarstid om du hĂ€ller 1K RPS för 1K föremĂ„l?
Av sammanhanget att döma talar vi om lÀsmÀngden, eftersom det inte finns nÄgra problem med att skriva - till och med tusen, till och med hundra tusen, och ibland flera miljoner rader kan infogas.
LÀsförfrÄgningar Àr vÀldigt olika. I utvald 1 kan ClickHouse utföra ungefÀr tiotusentals förfrÄgningar per sekund, sÄ Àven förfrÄgningar om en nyckel kommer redan att krÀva vissa resurser. Och sÄdana punktfrÄgor kommer att vara svÄrare Àn i vissa nyckelvÀrdedatabaser, eftersom det för varje lÀsning Àr nödvÀndigt att lÀsa ett datablock efter index. VÄrt index adresserar inte varje post, utan varje omrÄde. Det vill sÀga, du mÄste lÀsa hela intervallet - detta Àr 8192 rader som standard. Och du mÄste dekomprimera det komprimerade datablocket frÄn 64 KB till 1 MB. Vanligtvis tar sÄdana riktade frÄgor nÄgra millisekunder att slutföra. Men detta Àr det enklaste alternativet.
LÄt oss prova lite enkel aritmetik. Om du multiplicerar nÄgra millisekunder med tusen fÄr du nÄgra sekunder. Det Àr som om det Àr omöjligt att hÄlla jÀmna steg med tusen förfrÄgningar per sekund, men det Àr faktiskt möjligt, eftersom vi har flera processorkÀrnor. SÄ i princip kan ClickHouse ibland hÄlla 1000 RPS, men för korta förfrÄgningar, specifikt riktade.
Om du behöver skala ett ClickHouse-kluster efter antalet enkla förfrÄgningar, sÄ rekommenderar jag det enklaste - öka antalet repliker och skicka förfrÄgningar till en slumpmÀssig replik. Om en replik rymmer femhundra förfrÄgningar per sekund, vilket Àr helt realistiskt, kommer tre repliker att hantera ett och ett halvt tusen.
Ibland kan du förstÄs konfigurera ClickHouse för maximalt antal punktavlÀsningar. Vad behövs för detta? Det första Àr att minska indexets granularitet. I det hÀr fallet bör det inte reduceras till en, utan utifrÄn att antalet poster i indexet kommer att vara flera miljoner eller tiotals miljoner per server. Om tabellen har hundra miljoner rader kan granulariteten stÀllas in pÄ 64.
Du kan minska storleken pÄ det komprimerade blocket. Det finns instÀllningar för detta min komprimeringsblockstorlek, max komprimeringsblockstorlek. De kan minskas, fyllas pÄ med data, och dÄ blir riktade frÄgor snabbare. Men fortfarande, ClickHouse Àr inte en nyckel-vÀrde databas. Ett stort antal smÄ förfrÄgningar Àr ett belastningsantimönster.
Kirill Shvakov: Jag ger rÄd ifall det finns vanliga konton dÀr. Detta Àr en ganska standardsituation nÀr ClickHouse lagrar nÄgon form av disk. Jag har en anvÀndare, han kommer frÄn ett sÄdant och ett sÄdant land, och nÄgot tredje fÀlt, och jag behöver öka nÄgot stegvis. Ta MySQL, gör en unik nyckel - i MySQL Àr det en dubblettnyckel, och i PostgreSQL Àr det en konflikt - och lÀgg till ett plustecken. Detta kommer att fungera mycket bÀttre.
NÀr du inte har mycket data, Àr det ingen mening med att anvÀnda ClickHouse. Det finns vanliga databaser och de gör det bra.
Vad kan jag justera i ClickHouse sÄ att mer data finns i cachen?
LÄt oss förestÀlla oss en situation - servrarna har 256 GB RAM, i den dagliga rutinen tar ClickHouse cirka 60-80 GB, pÄ topp - upp till 130. Vad kan aktiveras och justeras sÄ att mer data finns i cachen och följaktligen, det Àr fÀrre resor till disken?
Vanligtvis gör operativsystemets sidcache ett bra jobb med detta. Om du bara öppnar toppen, tittar dÀr cachad eller ledig - det stÄr ocksÄ hur mycket som Àr cachad - dÄ kommer du att mÀrka att allt ledigt minne anvÀnds för cachen. Och nÀr du lÀser denna data kommer den inte att lÀsas frÄn disken, utan frÄn RAM. Samtidigt kan jag sÀga att cachen anvÀnds effektivt eftersom det Àr den komprimerade datan som cachelagras.
Men om du vill pÄskynda nÄgra enkla frÄgor Ànnu mer, Àr det möjligt att aktivera en cache i den dekomprimerade datan inuti ClickHouse. Det kallas okomprimerad cache. I konfigurationsfilen config.xml, stÀll in den okomprimerade cachestorleken till det vÀrde du behöver - jag rekommenderar inte mer Àn hÀlften av det lediga RAM-minnet, eftersom resten kommer att hamna under sidcachen.
Dessutom finns det tvÄ förfrÄgningsnivÄinstÀllningar. Första instÀllningen - anvÀnd okomprimerad cache - inkluderar dess anvÀndning. Det rekommenderas att aktivera det för alla förfrÄgningar, förutom tunga, som kan lÀsa all data och tömma cachen. Och den andra instÀllningen Àr ungefÀr det maximala antalet rader för att anvÀnda cachen. Det begrÀnsar automatiskt stora frÄgor sÄ att de kringgÄr cachen.
Hur kan jag konfigurera storage_configuration för lagring i RAM?
I den nya ClickHouse-dokumentationen lÀste jag avsnittet relaterat . Beskrivningen innehÄller ett exempel med snabb SSD.
Jag undrar hur samma sak kan konfigureras med volym hett minne. Och en frÄga till. Hur fungerar select med denna dataorganisation, kommer den att lÀsa hela uppsÀttningen eller bara den som finns pÄ disken, och Àr denna data komprimerad i minnet? Och hur fungerar prewhere-sektionen med en sÄdan dataorganisation?
Den hÀr instÀllningen pÄverkar lagringen av databitar och deras format Àndras inte pÄ nÄgot sÀtt.
LÄt oss ta en nÀrmare titt.
Du kan konfigurera datalagring i RAM. Allt som Àr konfigurerat för disken Àr dess sökvÀg. Du skapar en tmpfs-partition som Àr monterad pÄ nÄgon sökvÀg i filsystemet. Du anger denna sökvÀg som sökvÀgen för att lagra data för den hetaste partitionen, bitar av data börjar anlÀnda och skrivs dÀr, allt Àr bra.
Men jag rekommenderar inte att du gör detta pÄ grund av lÄg tillförlitlighet, men om du har minst tre repliker i olika datacenter, sÄ Àr det möjligt. Om nÄgot hÀnder kommer data att ÄterstÀllas. LÄt oss förestÀlla oss att servern plötsligt stÀngdes av och slogs pÄ igen. SkiljevÀggen monterades igen, men det fanns ingenting dÀr. NÀr ClickHouse-servern startar ser den att den inte har dessa bitar, Àven om de enligt ZooKeeper-metadata borde finnas dÀr. Han tittar pÄ vilka repliker som har dem, begÀr dem och laddar ner dem. PÄ sÄ sÀtt kommer data att ÄterstÀllas.
I den meningen skiljer sig lagring av data i RAM inte i grunden frÄn att lagra den pÄ disk, för nÀr data skrivs till disk hamnar den ocksÄ först i sidcachen och skrivs fysiskt senare. Detta beror pÄ filsystemets monteringsalternativ. Men för sÀkerhets skull ska jag sÀga att ClickHouse inte fsynkroniserar vid insÀttning.
I detta fall lagras data i RAM-minnet i exakt samma format som pÄ disken. VÀljfrÄgan vÀljer pÄ samma sÀtt de delar som behöver lÀsas, vÀljer de nödvÀndiga dataomrÄdena i bitarna och lÀser dem. Och prewhere fungerar exakt likadant, oavsett om data fanns i RAM eller pÄ disk.
Upp till hur mÄnga unika vÀrden Àr Low Cardinality effektiv?
Low Cardinality Ă€r smart designat. Den sammanstĂ€ller dataordböcker, men de Ă€r lokala. För det första finns det olika ordböcker för varje stycke, och för det andra, Ă€ven inom ett stycke kan de vara olika för varje intervall. NĂ€r antalet unika vĂ€rden nĂ„r ett tröskeltal â en miljon tror jag â lĂ€ggs ordboken helt enkelt pĂ„ hyllan och en ny skapas.
Svaret Àr generellt: för varje lokalt omrÄde - sÀg för varje dag - nÄgonstans Àr upp till en miljon unika vÀrden Low Cardinality effektiv. EfterÄt blir det helt enkelt en reserv, dÀr mÄnga olika ordböcker kommer att anvÀndas, och inte bara en. Det kommer att fungera ungefÀr som en vanlig strÀngkolonn, kanske lite mindre effektiv, men det kommer inte att bli nÄgon allvarlig prestandaförsÀmring.
Vilka Àr de bÀsta metoderna för fulltextsökning i en tabell med fem miljarder rader?
Det finns olika svar. Den första Àr att sÀga att ClickHouse inte Àr en fulltextsökmotor. Det finns speciella system för detta, t.ex. О . Men jag ser allt oftare att folk sÀger att de byter frÄn Elasticsearch till ClickHouse.
Varför hÀnder detta? De förklarar detta med det faktum att Elasticsearch upphör att klara av belastningen vid vissa volymer, frÄn och med konstruktionen av index. Index blir för krÄngliga och om man helt enkelt överför data till ClickHouse visar det sig att de lagras flera gÄnger mer effektivt volymmÀssigt. Samtidigt var sökfrÄgor ofta inte sÄdana att det var nödvÀndigt att hitta nÄgon fras i hela datavolymen, med hÀnsyn till morfologi, utan helt andra. Hitta till exempel en efterföljd av byte i loggarna under de senaste timmarna.
I det hÀr fallet skapar du ett index i ClickHouse, vars första fÀlt kommer att vara datum och tid. Och den största datagrÀnsen kommer att baseras pÄ datumintervallet. Inom det valda datumintervallet Àr det som regel redan möjligt att utföra en fulltextsökning, Àven med brute force-metoden med liknande. Lika-operatören i ClickHouse Àr den mest effektiva liknande-operatören du kan hitta. Om du hittar nÄgot bÀttre, berÀtta för mig.
Men ÀndÄ Àr det en fullstÀndig genomsökning. Och full scan kan vara lÄngsam, inte bara pÄ processorn utan ocksÄ pÄ disken. Om du plötsligt har en terabyte data per dag, och du söker efter ett ord under dagen, mÄste du skanna terabyten. Och det Àr förmodligen pÄ vanliga hÄrddiskar, och i slutÀndan kommer de att laddas pÄ ett sÄdant sÀtt att du inte kommer att kunna komma Ät den hÀr servern via SSH.
I det hÀr fallet Àr jag redo att erbjuda ett litet knep till. Det Àr experimentellt - det kanske fungerar, det kanske inte. ClickHouse har fulltextindex i form av trigram Bloom-filter. VÄra kollegor pÄ Arenadata har redan provat dessa index, och de fungerar ofta precis som de Àr tÀnkta.
För att kunna anvÀnda dem korrekt bör du ha en god förstÄelse för exakt hur de fungerar: vad ett trigram Bloom-filter Àr och hur du vÀljer dess storlek. Jag kan sÀga att de kommer att hjÀlpa till för frÄgor om nÄgra sÀllsynta fraser, delstrÀngar som sÀllan finns i data. I det hÀr fallet kommer delomrÄden att vÀljas av index och mindre data kommer att lÀsas.
Nyligen har ClickHouse lagt till Ànnu mer avancerade funktioner för fulltextsökning. Detta Àr för det första en sökning efter ett gÀng delstrÀngar samtidigt i ett pass, inklusive alternativ som Àr skiftlÀgeskÀnsliga, skiftlÀgesokÀnsliga, med stöd för UTF-8 eller endast för ASCII. VÀlj den mest effektiva du behöver.
Sök efter flera reguljÀra uttryck i ett pass har ocksÄ dykt upp. Du behöver inte skriva X som en delstrÀng eller X som en annan delstrÀng. Du skriver direkt, och allt görs sÄ effektivt som möjligt.
För det tredje finns det nu en ungefÀrlig sökning efter regexps och en ungefÀrlig sökning efter delstrÀngar. Om nÄgon har stavat ett ord fel kommer det att sökas efter maximal matchning.
Vad Àr det bÀsta sÀttet att organisera Ätkomst till ClickHouse för ett stort antal anvÀndare?
BerÀtta för oss hur man bÀst organiserar Ätkomst för ett stort antal konsumenter och analytiker. Hur bildar man en kö, prioriterar max samtidiga frÄgor och med vilka verktyg?
Om klustret Àr tillrÀckligt stort, skulle en bra lösning vara att höja ytterligare tvÄ servrar, vilket kommer att bli en ingÄngspunkt för analytiker. Det vill sÀga, tillÄt inte analytiker att komma Ät specifika shards i klustret, utan skapa helt enkelt tvÄ tomma servrar, utan data, och konfigurera ÄtkomstrÀttigheter pÄ dem. I det hÀr fallet överförs anvÀndarinstÀllningar för distribuerade förfrÄgningar till fjÀrrservrar. Det vill sÀga att du konfigurerar allt pÄ dessa tvÄ servrar, och instÀllningarna pÄverkar hela klustret.
I princip har dessa servrar inga data, men mÀngden RAM pÄ dem Àr mycket viktig för att exekvera förfrÄgningar. Disken kan ocksÄ anvÀndas för temporÀr data om extern aggregering eller extern sortering Àr aktiverad.
Det Àr viktigt att titta pÄ instÀllningarna som Àr förknippade med alla möjliga grÀnser. Om jag nu gÄr till Yandex.Metrica-klustret som analytiker och ber en förfrÄgan vÀlj antal trÀffar, dÄ fÄr jag omedelbart ett undantag att jag inte kan verkstÀlla begÀran. Det maximala antalet rader som jag fÄr skanna Àr hundra miljarder, och totalt finns det femtio biljoner av dem i en tabell i klustret. Detta Àr den första begrÀnsningen.
LÄt oss sÀga att jag tar bort radgrÀnsen och kör frÄgan igen. DÄ kommer jag att se följande undantag - instÀllningen aktiverad kraftindex efter datum. Jag kan inte slutföra frÄgan om jag inte har angett ett datumintervall. Du behöver inte förlita dig pÄ analytiker för att specificera det manuellt. Ett typiskt fall Àr nÀr ett datumintervall skrivs dÀr hÀndelsedatum mellan vecka. Och dÄ angav de helt enkelt en parentes pÄ fel stÀlle, och istÀllet för och visade det sig vara eller - eller URL-matchning. Om det inte finns nÄgon grÀns kommer den att genomsöka URL-kolumnen och bara slösa bort massor av resurser.
Dessutom har ClickHouse tvĂ„ prioritetsinstĂ€llningar. TyvĂ€rr Ă€r de vĂ€ldigt primitiva. En heter helt enkelt prioritet. Om prioritet â 0, och förfrĂ„gningar med en viss prioritet exekveras, men en begĂ€ran med ett prioritetsvĂ€rde pĂ„ mindre Ă€n, vilket betyder en högre prioritet, exekveras, dĂ„ en begĂ€ran med ett prioritetsvĂ€rde större, vilket betyder en lĂ€gre prioritet , Ă€r helt enkelt avstĂ€ngd och kommer inte att fungera alls under denna tid.
Detta Àr en mycket grov instÀllning och Àr inte lÀmplig för fall dÀr klustret har en konstant belastning. Men om du har korta, sprÀngfyllda förfrÄgningar som Àr viktiga, och klustret för det mesta Àr inaktivt, Àr den hÀr instÀllningen lÀmplig.
NÀsta prioritetsinstÀllning anropas OS trÄdprioritet. Det stÀller helt enkelt det trevliga vÀrdet för alla trÄdar för exekvering av begÀran för Linux-schemalÀggaren. Det fungerar sÄ som sÄ, men det fungerar fortfarande. Om du stÀller in det minsta nice-vÀrdet - det Àr det största i vÀrde, och dÀrför den lÀgsta prioriteten - och stÀller in -19 för förfrÄgningar med hög prioritet, sÄ kommer CPU:n att förbruka lÄgprioriterade förfrÄgningar ungefÀr fyra gÄnger mindre Àn högprioriterade.
Du mÄste ocksÄ konfigurera den maximala exekveringstiden för begÀran - sÀg fem minuter. Den lÀgsta hastigheten för exekvering av frÄgor Àr det coolaste. Den hÀr instÀllningen har funnits lÀnge, och det krÀvs inte bara för att hÀvda att ClickHouse inte saktar ner, utan för att tvinga den.
FörestÀll dig, du stÀller in: om en frÄga bearbetar mindre Àn en miljon rader per sekund kan du inte göra det. Detta skamlar vÄrt goda namn, vÄr goda databas. LÄt oss bara förbjuda detta. Det finns faktiskt tvÄ instÀllningar. En kallas min exekveringshastighet - i rader per sekund, och den andra kallas timeout innan du kontrollerar min exekveringshastighet - femton sekunder som standard. Det vill sÀga femton sekunder Àr möjligt, och sedan, om det Àr lÄngsamt, slÀng bara ett undantag och avbryt begÀran.
Du mÄste ocksÄ stÀlla in kvoter. ClickHouse har en inbyggd kvotfunktion som rÀknar resursförbrukning. Men tyvÀrr inte hÄrdvaruresurser som CPU, diskar, utan logiska sÄdana - antalet bearbetade förfrÄgningar, rader och byte lÀsta. Och du kan konfigurera till exempel maximalt hundra förfrÄgningar inom fem minuter och tusen förfrÄgningar per timme.
Varför Àr det viktigt? Eftersom vissa analysfrÄgor kommer att utföras manuellt direkt frÄn ClickHouse-klienten. Och allt kommer att bli bra. Men om du har avancerade analytiker i ditt företag kommer de att skriva ett manus, och det kan finnas ett fel i manuset. Och detta fel kommer att göra att begÀran exekveras i en oÀndlig loop. Det Àr detta vi behöver skydda oss frÄn.
Ăr det möjligt att ge resultatet av en frĂ„ga till tio kunder?
Vi har flera anvĂ€ndare som gillar att komma in med mycket stora förfrĂ„gningar vid samma tidpunkt. FörfrĂ„gan Ă€r stor och utförs i princip snabbt, men pĂ„ grund av att det finns mĂ„nga sĂ„dana förfrĂ„gningar samtidigt blir det vĂ€ldigt smĂ€rtsamt. Ăr det möjligt att utföra samma begĂ€ran, som kom tio gĂ„nger i rad, en gĂ„ng och ge resultatet till tio klienter?
Problemet Àr att vi inte har resultaten av cachen eller cachen för mellanliggande data. Det finns en sidcache i operativsystemet, som kommer att hindra dig frÄn att lÀsa data frÄn disken igen, men tyvÀrr kommer data fortfarande att dekomprimeras, deserialiseras och omarbetas.
Jag skulle vilja undvika detta pÄ nÄgot sÀtt, antingen genom att cachelagra mellanliggande data eller genom att rada upp liknande frÄgor i nÄgon form av kö och lÀgga till en resultatcache. Vi har för nÀrvarande en pull-begÀran under utveckling som lÀgger till en begÀran-cache, men endast för subqueries i in- och join-sektionerna - det vill sÀga lösningen Àr ofullstÀndig.
Men vi stÄr ocksÄ inför en sÄdan situation. Ett sÀrskilt kanoniskt exempel Àr paginerade frÄgor. Det finns en rapport, den har flera sidor, och det finns en begÀran om grÀns 10. Sedan samma sak, men grÀns 10,10. Sedan en till nÀsta sida. Och frÄgan Àr varför vi rÀknar allt detta varje gÄng? Men nu finns det ingen lösning, och det finns inget sÀtt att undvika det.
Det finns en alternativ lösning som placeras som sidovagn bredvid ClickHouse - .
Kirill Shvakov: ClickHouse Proxy har en inbyggd hastighetsbegrÀnsare och en inbyggd resultatcache. En hel del justeringar gjordes dÀr eftersom ett liknande problem höll pÄ att lösas. Proxy lÄter dig begrÀnsa förfrÄgningar genom att stÀlla dem i kö och konfigurera hur lÀnge förfrÄgningscachen lever. Om förfrÄgningarna verkligen var desamma kommer Proxy att skicka dem mÄnga gÄnger, men kommer bara att gÄ till ClickHouse en gÄng.
Nginx har ocksÄ en cache i gratisversionen, och detta kommer ocksÄ att fungera. Nginx har till och med instÀllningar att om förfrÄgningar kommer samtidigt, kommer det att sakta ner andra tills en Àr klar. Men det Àr i ClickHouse Proxy som installationen görs mycket bÀttre. Det gjordes specifikt för ClickHouse, specifikt för dessa förfrÄgningar, sÄ det Àr mer lÀmpligt. Tja, det Àr lÀtt att installera.
Hur Àr det med asynkrona operationer och materialiserade vyer?
Det finns ett problem att operationer med replay-motorn Àr asynkrona - först skrivs data, sedan kollapsar den. Om en materialiserad tablett med vissa aggregat lever under tecknet, kommer dubbletter att skrivas till den. Och om det inte finns nÄgon komplex logik, kommer data att dupliceras. Vad kan du göra Ät det?
Det finns en uppenbar lösning - att implementera en trigger pÄ en viss klass av matvyer under en asynkron kollapsoperation. Finns det nÄgra silverkulor eller planer pÄ att implementera liknande funktionalitet?
Det Àr vÀrt att förstÄ hur deduplicering fungerar. Det jag ska berÀtta nu Àr inte relevant för frÄgan, utan bara ifall det Àr vÀrt att komma ihÄg.
NÀr du infogar i en replikerad tabell sker deduplicering av hela infogade block. Om du infogar samma block som innehÄller samma antal av samma rader i samma ordning, dedupliceras data. Du kommer att fÄ "Ok" som svar pÄ infogning, men i sjÀlva verket kommer ett datapaket att skrivas, och det kommer inte att dupliceras.
Detta Àr nödvÀndigt för sÀkerhet. Om du fÄr "Ok" under infogningen har dina data infogats. Om du fÄr ett felmeddelande frÄn ClickHouse betyder det att de inte infogades och att du mÄste upprepa infogningen. Men om anslutningen bryts under infogningen vet du inte om data infogades eller inte. Det enda alternativet Àr att upprepa infogningen igen. Om data faktiskt infogades och du infogade den igen, finns det blockdeduplicering. Detta behövs för att undvika dubbletter.
Och det Àr ocksÄ viktigt hur det fungerar för materialiserade Äsikter. Om data deduplicerades nÀr de infogades i huvudtabellen kommer den inte heller att gÄ in i den materialiserade vyn.
Nu till frÄgan. Din situation Àr mer komplicerad eftersom du spelar in dubbletter av enskilda rader. Det vill sÀga, det Àr inte hela paketet som dupliceras, utan specifika linjer, och de kollapsar i bakgrunden. Faktum Àr att data kommer att kollapsa i huvudtabellen, men de okomprimerade data kommer att gÄ till den materialiserade vyn, och under sammanslagningar kommer ingenting att hÀnda med de materialiserade vyerna. Eftersom en materialiserad vy inte Àr nÄgot annat Àn en insÀttningsutlösare. Under andra operationer hÀnder inget mer med det.
Och jag kan inte göra dig lycklig hĂ€r. Du behöver bara leta efter en specifik lösning för det hĂ€r fallet. Ăr det till exempel möjligt att spela upp det i en materialiserad vy, och dedupliceringsmetoden kan fungera pĂ„ samma sĂ€tt. Men tyvĂ€rr inte alltid. Om det aggregeras kommer det inte att fungera.
Kirill Shvakov: Vi byggde ocksĂ„ kryckor förr i tiden. Det uppstod ett problem med att det finns annonsvisningar, och det finns en del data som vi kan visa i realtid â det hĂ€r Ă€r bara visningar. De dupliceras sĂ€llan, men om detta hĂ€nder kommer vi att kollapsa dem senare Ă€ndĂ„. Och det fanns saker som inte gick att duplicera - klick och hela den hĂ€r historien. Men jag ville ocksĂ„ visa dem nĂ€stan direkt.
Hur skapades de materialiserade Äsikterna? Det fanns vyer dÀr det skrevs direkt - det skrevs till rÄdata och skrevs till vyer. DÀr Àr uppgifterna vid nÄgot tillfÀlle inte sÀrskilt korrekta, de dupliceras och sÄ vidare. Och det finns en andra del av tabellen, dÀr de ser exakt likadana ut som materialiserade vyer, det vill sÀga de Àr helt identiska i struktur. DÄ och dÄ rÀknar vi om data, rÀknar data utan dubbletter, skriver till de tabellerna.
Vi gick igenom API - detta kommer inte att fungera manuellt i ClickHouse. Och API:t ser ut: nÀr jag har datumet för det senaste tillÀgget till tabellen, dÀr det Àr garanterat att korrekt data redan har berÀknats, och det gör en begÀran till en tabell och till en annan tabell. FrÄn den ena vÀljer begÀran upp till en viss tid, och frÄn den andra fÄr den det som Ànnu inte har berÀknats. Och det fungerar, men inte bara genom ClickHouse.
Om du har nÄgon form av API - för analytiker, för anvÀndare - sÄ Àr detta i princip ett alternativ. Du rÀknar alltid, rÀknar alltid. Detta kan göras en gÄng om dagen eller vid nÄgon annan tidpunkt. Du vÀljer sjÀlv ett sortiment som du inte behöver och inte Àr kritiskt.
ClickHouse har mÄnga loggar. Hur kan jag se allt som hÀnder med servern pÄ ett ögonblick?
ClickHouse har ett vÀldigt stort antal olika loggar, och antalet ökar. I nya versioner Àr vissa av dem till och med aktiverade som standard, i Àldre versioner mÄste de aktiveras vid uppdatering. Det finns dock fler och fler av dem. I slutÀndan skulle jag vilja se vad som hÀnder med min server nu, kanske pÄ nÄgon form av översiktspanel.
Har du ett ClickHouse-team, eller dina vÀnners team, som stöder nÄgon funktionalitet av fÀrdiga instrumentpaneler som skulle visa dessa loggar som en fÀrdig produkt? I slutÀndan Àr det bra att bara titta pÄ loggar i ClickHouse. Men det skulle vara vÀldigt coolt om det redan var förberett i form av en instrumentbrÀda. Jag skulle fÄ en kick av det.
Det finns instrumentpaneler, Àven om de inte Àr standardiserade. I vÄrt företag anvÀnder ett 60-tal team ClickHouse och det mÀrkligaste Àr att mÄnga av dem har instrumentpaneler som de gjort Ät sig sjÀlva, och lite olika. Vissa team anvÀnder en intern Yandex.Cloud-installation. Det finns nÄgra fÀrdiga rapporter, men inte alla nödvÀndiga. Andra har sina egna.
Mina kollegor frÄn Metrica har sin egen instrumentpanel i Grafana, och jag har en egen för deras kluster. Jag tittar pÄ saker som cachehit för serif-cachen. Och Ànnu svÄrare Àr att vi anvÀnder olika verktyg. Jag skapade min instrumentpanel med ett mycket gammalt verktyg som heter Graphite-web. Han Àr helt ful. Och jag anvÀnder det fortfarande pÄ det hÀr sÀttet, Àven om Grafana förmodligen skulle vara bekvÀmare och vackrare.
Det grundlĂ€ggande i instrumentpaneler Ă€r detsamma. Dessa Ă€r systemmĂ„tt för klustret: CPU, minne, disk, nĂ€tverk. Ăvriga - antal samtidiga förfrĂ„gningar, antal samtidiga sammanslagningar, antal förfrĂ„gningar per sekund, maximalt antal bitar för MergeTree-tabellpartitioner, replikeringsfördröjning, replikeringsköstorlek, antal infogade rader per sekund, antal infogade block per sekund. Detta Ă€r allt som erhĂ„lls inte frĂ„n loggar, utan frĂ„n mĂ„tt.
Vladimir Kolobaev: Alexey, jag skulle vilja korrigera det lite. DÀr Àr Grafana. Grafana har en datakÀlla, som Àr ClickHouse. Det vill sÀga jag kan göra förfrÄgningar frÄn Grafana direkt till ClickHouse. ClickHouse har en tabell med loggar, det Àr lika för alla. Som ett resultat vill jag komma Ät den hÀr loggtabellen i Grafana och se de förfrÄgningar som min server gör. Det skulle vara bra att ha en sÄdan hÀr instrumentpanel.
Jag cyklade sjÀlv. Men jag har en frÄga - om allt Àr standardiserat och Grafana anvÀnds av alla, varför har inte Yandex en sÄdan officiell instrumentpanel?
Kirill Shvakov: Faktum Àr att datakÀllan som gÄr till ClickHouse nu stöder Altinity. Och jag vill bara ge en vektor för var man ska grÀva och vem man ska trycka pÄ. Du kan frÄga dem, eftersom Yandex fortfarande gör ClickHouse, och inte historien runt det. Altinity Àr det huvudsakliga företaget som för nÀrvarande marknadsför ClickHouse. De kommer inte att överge honom, utan kommer att stödja honom. För för att i princip ladda upp en instrumentpanel till Grafanas webbplats behöver du bara registrera dig och ladda upp den - det finns inga speciella problem.
Alexey Milovidov: Under det senaste Äret har ClickHouse lagt till mÄnga frÄgeprofileringsmöjligheter. Det finns mÀtvÀrden för varje begÀran om resursanvÀndning. Och alldeles nyligen lade vi till en frÄgeprofilerare pÄ Ànnu lÀgre nivÄ för att se var en frÄga spenderar varje millisekund. Men för att anvÀnda den hÀr funktionen mÄste jag öppna konsolklienten och skriva en begÀran, som jag alltid glömmer. Jag sparade den nÄgonstans och glömmer hela tiden var exakt.
Jag önskar att det fanns ett verktyg som just sa, hÀr Àr dina tunga frÄgor, grupperade efter frÄgeklass. Jag tryckte pÄ en och de sa till mig att det Àr dÀrför den Àr tung. Det finns ingen sÄdan lösning nu. Och det Àr egentligen ganska konstigt att nÀr folk frÄgar mig: "SÀg mig, finns det nÄgra fÀrdiga instrumentpaneler för Grafana?", jag sÀger: "GÄ till Grafanas webbplats, det finns en "Dashboards"-community och det finns en instrumentbrÀda. frÄn Dimka, det finns en instrumentbrÀda frÄn Kostyan. Jag vet inte vad det Àr, jag har inte anvÀnt det sjÀlv."
Hur pÄverkar man sammanslagningar sÄ att servern inte kraschar in i OOM?
Jag har en tabell, det finns bara en partition i tabellen, det Àr ReplaceingMergeTree. Jag har skrivit in data i den i fyra Är. Jag behövde göra en Àndring i den och radera en del data.
Jag gjorde detta, och under behandlingen av denna begÀran förbrukades allt minne pÄ alla servrar i klustret, och alla servrar i klustret gick in i OOM. Sedan reste de sig alla tillsammans, började slÄ samman samma operation, detta datablock, och föll in i OOM igen. Sedan reste de sig igen och föll igen. Och det hÀr slutade inte.
Sedan visade det sig att det hÀr faktiskt var en bugg som killarna fixade. Det hÀr Àr vÀldigt coolt, tack sÄ mycket. Men en rest fanns kvar. Och nu, nÀr jag tÀnker pÄ att göra nÄgon form av sammanslagning i tabellen, har jag en frÄga - varför kan jag inte pÄ nÄgot sÀtt pÄverka dessa sammanslagningar? BegrÀnsa dem till exempel med mÀngden RAM som krÀvs, eller, i princip, med mÀngden som kommer att bearbeta just denna tabell.
Jag har en tabell som heter "MÀtvÀrden", bearbeta den Ät mig i tvÄ trÄdar. Det finns ingen anledning att skapa tio eller fem sammanslagningar parallellt, gör det i tvÄ. Jag tror att jag har tillrÀckligt med minne för tvÄ, men det kanske inte rÀcker för att bearbeta tio. Varför finns rÀdslan kvar? Eftersom tabellen vÀxer, och en dag kommer jag att stÀllas inför en situation som i princip inte lÀngre beror pÄ en bugg, utan pÄ att data kommer att förÀndras i sÄ stor mÀngd att jag helt enkelt inte kommer att ha tillrÀckligt med minne pÄ server. Och sedan kommer servern att krascha in i OOM vid sammanslagning. Dessutom kan jag avbryta mutationen, men Merji Àr inte lÀngre dÀr.
Du vet, vid sammanslagning kommer servern inte att falla in i OOM, för vid sammanslagning anvÀnds mÀngden RAM bara för ett litet dataomrÄde. SÄ allt kommer att bli bra oavsett mÀngden data.
Vladimir Kolobaev: Bra. HÀr Àr ögonblicket sÄdant att efter att felet fixats laddade jag ner en ny version för mig sjÀlv, och pÄ ett annat bord, ett mindre, dÀr det finns mÄnga partitioner, utförde jag en liknande operation. Och under sammanslagningen brÀndes cirka 100 GB RAM pÄ servern. Jag hade 150 upptagna, 100 Àtit och ett fönster pÄ 50 GB kvar, sÄ jag föll inte i OOM.
Vad skyddar mig för nÀrvarande frÄn att falla i OOM om den faktiskt förbrukar 100 GB RAM? Vad ska man göra om RAM-minnet pÄ sammanslagningarna plötsligt tar slut?
Alexey Milovidov: Det finns ett sÄdant problem att förbrukningen av RAM specifikt för sammanslagning inte Àr begrÀnsad. Och det andra problemet Àr att om nÄgon form av sammanslagning har tilldelats, mÄste den exekveras eftersom den registreras i replikeringsloggen. Replikeringsloggen Àr de ÄtgÀrder som behövs för att fÄ repliken till ett konsekvent tillstÄnd. Om du inte gör manuella manipulationer som kommer att rulla tillbaka denna replikeringslogg, mÄste sammanslagningen utföras pÄ ett eller annat sÀtt.
Naturligtvis skulle det inte vara överflödigt att ha en RAM-begrÀnsning som "för sÀkerhets skull" skyddar mot OOM. Det kommer inte att hjÀlpa sammanslagningen att slutföras, den kommer att börja om, nÄ nÄgon tröskel, kasta ett undantag och sedan börja igen - inget bra kommer att komma av detta. Men i princip skulle det vara bra att införa denna begrÀnsning.
Hur kommer Golang-drivrutinen för ClickHouse att utvecklas?
Golang-föraren, som skrevs av Kirill Shvakov, stöds nu officiellt av ClickHouse-teamet. han , han Àr nu stor och riktig.
En liten notis. Det finns ett underbart och Àlskat förrÄd av normala former av oÀndlig ordning - det hÀr Àr Vertica. De har ocksÄ sin egen officiella python-drivrutin, som stöds av Vertica-utvecklarna. Och flera gÄnger hÀnde det att lagringsversionerna och drivrutinsversionerna skiljde sig ganska dramatiskt, och drivrutinen vid nÄgot tillfÀlle slutade fungera. Och den andra punkten. Stöd för den hÀr officiella föraren, verkar det som jag, utförs av "nipple" -systemet - du skriver ett problem till dem, och det hÀnger för alltid.
Jag har tvÄ frÄgor. Nu Àr Kirills Golang-drivrutin nÀstan standardsÀttet att kommunicera frÄn Golang med ClickHouse. Om inte nÄgon fortfarande kommunicerar via http-grÀnssnittet för att han gillar det sÄ. Hur kommer utvecklingen av denna drivrutin att gÄ vidare? Kommer det att synkroniseras med eventuella brytande Àndringar i sjÀlva förvaret? Och vad Àr proceduren för att övervÀga en frÄga?
Kirill Shvakov: Den första Àr hur allt Àr organiserat byrÄkratiskt. Denna punkt diskuterades inte, sÄ jag har inget att svara pÄ.
För att svara pÄ frÄgan om problemet behöver vi lite historia om föraren. Jag arbetade för ett företag som hade mycket data. Det var en reklamsnurra med ett enormt antal evenemang som behövde lagras nÄgonstans. Och nÄgon gÄng dök ClickHouse upp. Vi fyllde den med data, och först var allt bra, men sedan kraschade ClickHouse. I det ögonblicket bestÀmde vi oss för att vi inte behövde det.
Ett Är senare ÄtervÀnde vi till idén om att anvÀnda ClickHouse, och vi behövde skriva data dÀr pÄ nÄgot sÀtt. Det inledande budskapet var detta: hÄrdvaran Àr mycket svag, det finns fÄ resurser. Men vi har alltid arbetat pÄ det hÀr sÀttet, och dÀrför tittade vi mot det inhemska protokollet.
Eftersom vi jobbade i Go stod det klart att vi behövde en Go-förare. Jag gjorde det nĂ€stan pĂ„ heltid â det var min arbetsuppgift. Vi förde det till en viss punkt, och i princip ingen antog att nĂ„gon annan Ă€n vi skulle anvĂ€nda det. Sedan kom CloudFlare med exakt samma problem, och under en tid arbetade vi vĂ€ldigt smidigt med dem, eftersom de hade samma uppgifter. Dessutom gjorde vi detta bĂ„de i ClickHouse sjĂ€lva och i drivrutinen.
Vid nÄgot tillfÀlle slutade jag helt enkelt med det, eftersom min aktivitet vad gÀller ClickHouse och arbete förÀndrades lite. DÀrför Àr frÄgor inte stÀngda. Periodvis förbinder sig mÀnniskor som behöver nÄgot sjÀlva till förvaret. Sedan tittar jag pÄ pull-förfrÄgan och ibland redigerar jag till och med nÄgot sjÀlv, men det hÀnder sÀllan.
Jag vill tillbaka till föraren. För flera Är sedan, nÀr det hela började, var ClickHouse ocksÄ annorlunda och med olika möjligheter. Nu har vi en förstÄelse för hur man gör om drivrutinen sÄ att den fungerar bra. Om detta hÀnder kommer version 2 att vara inkompatibel i alla fall pÄ grund av de ackumulerade kryckorna.
Jag vet inte hur jag ska organisera den hÀr saken. Jag har inte mycket tid sjÀlv. Om nÄgra personer avslutar föraren kan jag hjÀlpa dem och tala om för dem vad de ska göra. Men Yandex aktiva deltagande i utvecklingen av projektet har Ànnu inte diskuterats.
Alexey Milovidov: Det finns faktiskt ingen byrÄkrati kring dessa förare Àn. Det enda Àr att de skickas till en officiell organisation, det vill sÀga den hÀr drivrutinen Àr erkÀnd som den officiella standardlösningen för Go. Det finns nÄgra andra förare, men de kommer separat.
Vi har ingen intern utveckling för dessa förare. FrÄgan Àr om vi kan anstÀlla en enskild person, inte för just denna förare, utan för utveckling av alla samhÀllsförare, eller kan vi hitta nÄgon utifrÄn.
Den externa ordlistan laddas inte efter en omstart med lazy_load-instÀllningen aktiverad. Vad ska man göra?
Vi har instĂ€llningen lazy_load aktiverad, och efter att servern har startat om laddas inte ordboken av sig sjĂ€lv. Den höjs först efter att anvĂ€ndaren kommer Ă„t denna ordbok. Och första gĂ„ngen jag kommer Ă„t det ger det ett felmeddelande. Ăr det möjligt att pĂ„ nĂ„got sĂ€tt automatiskt ladda ordböcker med ClickHouse, eller mĂ„ste du alltid kontrollera deras beredskap sjĂ€lv sĂ„ att anvĂ€ndarna inte fĂ„r fel?
Kanske har vi en gammal version av ClickHouse, sÄ ordboken laddades inte automatiskt. Kan detta vara fallet?
För det första kan ordböcker tvingas laddas med hjÀlp av en frÄga system ladda om ordböcker. För det andra, angÄende felet - om ordboken redan Àr laddad, kommer frÄgorna att fungera baserat pÄ den data som laddades. Om ordlistan Ànnu inte har laddats kommer den att laddas direkt under förfrÄgan.
Detta Àr inte sÀrskilt bekvÀmt för tunga ordböcker. Till exempel behöver du dra en miljon rader frÄn MySQL. NÄgon gör ett enkelt val, men detta val vÀntar pÄ samma miljoner rader. Det finns tvÄ lösningar hÀr. Det första Àr att stÀnga av lazy_load. För det andra, nÀr servern Àr uppe, innan du lÀgger belastningen pÄ den, gör det system ladda om ordbok eller gör bara en frÄga som anvÀnder en ordbok. DÄ kommer ordboken att laddas. Du mÄste kontrollera tillgÀngligheten för ordböcker med lazy_load-instÀllningen aktiverad, eftersom ClickHouse inte automatiskt laddar dem.
Svaret pÄ den sista frÄgan Àr antingen versionen Àr gammal eller sÄ mÄste den felsökas.
Vad ska man göra med att systemet laddar om ordböcker inte laddar nÄgon av de mÄnga ordböckerna om Ätminstone en av dem kraschar med ett fel?
Det finns en annan frĂ„ga om systemladdningsordböcker. Vi har tvĂ„ ordböcker - en Ă€r inte laddad, den andra Ă€r laddad. I det hĂ€r fallet lĂ€ser Systemreload-ordböcker inte in nĂ„gon ordbok, och du mĂ„ste lĂ€sa in en specifik ordbok punkt för punkt med dess namn med hjĂ€lp av systemreload-lexikon. Ăr detta ocksĂ„ relaterat till ClickHouse-versionen?
Jag vill göra dig glad. Detta beteende höll pÄ att förÀndras. Det betyder att om du uppdaterar ClickHouse kommer det ocksÄ att Àndras. Om du inte Àr nöjd med ditt nuvarande beteende system ladda om ordböcker, uppdatera och lÄt oss hoppas att det förÀndras till det bÀttre.
Finns det nÄgot sÀtt att konfigurera detaljer i ClickHouse-konfigurationen, men inte visa dem i hÀndelse av fel?
NÀsta frÄga handlar om fel relaterade till ordboken, nÀmligen detaljer. Vi har specificerat anslutningsdetaljerna i ClickHouse-konfigurationen för ordboken, och om det finns ett fel fÄr vi dessa uppgifter och lösenord som svar.
Vi löste det hÀr felet genom att lÀgga till detaljer i ODBC-drivrutinens konfiguration. Finns det nÄgot sÀtt att konfigurera detaljerna i ClickHouse-konfigurationen, men inte visa dessa detaljer i hÀndelse av fel?
Den verkliga lösningen hÀr Àr att ange dessa referenser i odbc.ini, och i sjÀlva ClickHouse ange endast ODBC-datakÀllans namn. Detta kommer inte att hÀnda för andra ordbokskÀllor - varken för ordboken med MySQL, eller för de andra, bör du inte se lösenordet nÀr du fÄr ett felmeddelande. För ODBC ska jag ocksÄ titta - om det finns behöver du bara ta bort det.
Bonus: bakgrunder för Zoom frÄn sammankomster
Genom att klicka pÄ bilden öppnas bonusbakgrunder frÄn sammankomsterna för de mest ihÀrdiga lÀsarna. Vi slÀcker branden tillsammans med Avitos teknikmaskoter, vi konfererar med kollegor frÄn systemadministratörens rum eller gamla skolans dataklubb och vi genomför dagliga möten under bron mot bakgrund av graffiti.
KĂ€lla: will.com