I april samlades Avitos ingenjörer för ett online-möte med ClickHouses huvudutvecklare Alexey Milovidov och Kirill Shvakov, en Golang-utvecklare frÄn Integros. Vi diskuterade hur vi anvÀnder databashanteringssystemet och vilka svÄrigheter vi stöter pÄ.
Baserat pÄ mötet har vi sammanstÀllt en artikel med experters svar pÄ vÄra och tittarnas frÄgor om sÀkerhetskopior, dataresharding, externa ordböcker, Golang-drivrutinen och uppdatering av ClickHouse-versioner. Det kan vara anvÀndbart för utvecklare som redan aktivt arbetar med Yandex DBMS och Àr intresserade av dess nutid och framtid. Som standard svar av Alexey Milovidov, om inte annat anges.
Var försiktig, det Àr mycket text under snittet. Vi hoppas att innehÄllet med frÄgorna hjÀlper dig att orientera dig.
InnehÄll
Om du inte vill lÀsa texten kan du titta pÄ inspelningen av sammankomsten . Tidskoder finns i första kommentaren under videon.
ClickHouse uppdateras stÀndigt, men inte vÄr data. Vad ska man göra Ät det?
ClickHouse uppdateras stÀndigt, och vÄra data, som optimerades och slutligen bearbetades, uppdateras inte och finns i en sÀkerhetskopia.
LÄt oss sÀga att vi hade ett problem och att informationen gick förlorad. Vi bestÀmde oss för att ÄterstÀlla, och det visade sig att de gamla partitionerna som lagrades pÄ sÀkerhetskopieringsservrarna var vÀldigt annorlunda frÄn den version av ClickHouse som anvÀndes för nÀrvarande. Vad ska man göra i en sÄdan situation, och Àr det möjligt?
Situationen dÀr du ÄterstÀllde data frÄn en sÀkerhetskopia i det gamla formatet, men den inte ansluter till den nya versionen, Àr omöjlig. Vi sÀkerstÀller att dataformatet i ClickHouse alltid förblir bakÄtkompatibelt. Detta Àr mycket viktigare Àn bakÄtkompatibilitet i funktionalitet om beteendet hos nÄgon sÀllan anvÀnd funktion har förÀndrats. Den nya versionen av ClickHouse ska alltid kunna lÀsa data som lagras pÄ disken. Detta Àr lagen.
Vilka Àr de bÀsta metoderna för att sÀkerhetskopiera data frÄn ClickHouse för nÀrvarande?
Hur gör man sÀkerhetskopior med tanke pÄ att vi har optimerat slutliga operationer, en enorm databas med terabyte och data som uppdateras, sÀg, under de senaste tre dagarna, och sedan utförs inga procedurer med den?
Vi kan piska upp vÄr egen lösning och skriva pÄ festen: samla dessa sÀkerhetskopior pÄ det och det sÀttet. Kanske finns det ingen anledning att krycka nÄgonting, och cykeln uppfanns för lÀnge sedan?
Först, om bÀsta praxis. Mina kollegor rÄder alltid, som svar pÄ frÄgor om sÀkerhetskopior, att pÄminna om Yandex.Cloud-tjÀnsten, dÀr den hÀr uppgiften redan har lösts. SÄ anvÀnd det om du har möjlighet.
Det finns ingen komplett lösning för sÀkerhetskopior som Àr 100 % inbyggd i ClickHouse. Det finns nÄgra tomma rutor som kan anvÀndas. För att fÄ en komplett lösning mÄste du antingen experimentera 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Ä datamÀngden och klustrets storlek. Ju större klustret Àr, desto mer komplex blir lösningen.
Om tabellen med data bara tar upp nÄgra fÄ gigabyte kan du göra en sÀkerhetskopia sÄ hÀr:
- Spara tabelldefinitionen, dvs. metadata - visa skapa tabell.
- Gör en dumpning med ClickHouse-klienten â vĂ€lj * frĂ„n bordet att arkivera. Som standard fĂ„r du en fil i tabbavgrĂ€nsat format. Om du vill ha mer effektivitet kan du anvĂ€nda nativt format.
Om datamÀngden À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 den finns kan du i extrema fall ta en sÀkerhetskopia och ladda 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. Den hĂ€r funktionen Ă€r tillgĂ€nglig pĂ„ begĂ€ran. Ă€ndra tabellens fryspartition. Eller bara Ă€ndra bordsfrysning â detta Ă€r en ögonblicksbild av hela tabellen.
Ăgonblicksbilden skapas konsekvent för en tabell pĂ„ en shard, det vill sĂ€ga det Ă€r omöjligt att skapa en konsekvent ögonblicksbild av hela klustret pĂ„ det hĂ€r sĂ€ttet. Men för de flesta uppgifter finns det inget sĂ„dant behov, och det rĂ€cker med att köra en frĂ„ga pĂ„ varje shard och fĂ„ en konsekvent ögonblicksbild. Den skapas i form av hĂ„rda lĂ€nkar och tar dĂ€rför inte upp extra utrymme. DĂ€refter kopierar du den hĂ€r ögonblicksbilden till sĂ€kerhetskopieringsservern eller till den lagring som du anvĂ€nder för sĂ€kerhetskopior.
Det Àr ganska enkelt att ÄterstÀlla en sÄdan sÀkerhetskopia. Skapa först tabeller baserade pÄ befintliga tabelldefinitioner. Kopiera sedan de sparade partitionssnapshotsen 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 datamÀngderna.
Ibland behöver man nĂ„got Ă€nnu kraftfullare â i de fall dĂ€r man har tiotals eller till och med hundratals terabyte pĂ„ varje server och hundratals servrar. Det finns en lösning hĂ€r som jag spionerade pĂ„ frĂ„n mina kollegor pĂ„ Yandex.Metrica. Jag skulle inte rekommendera den till alla â lĂ€s den och avgör sjĂ€lv om den Ă€r rĂ€tt för dig eller inte.
Först behöver du skapa flera servrar med stora diskhyllor. Sedan, pÄ dessa servrar, konfigurera flera ClickHouse-servrar för att fungera som en annan replik för samma shards. AnvÀnd sedan ett filsystem eller nÄgot verktyg pÄ dessa servrar som lÄter dig skapa snapshots. Det finns tvÄ alternativ hÀr. Det första alternativet Àr LVM-snapshots, det andra alternativet Àr ZFS pÄ Linux.
Efter det behöver du skapa en ögonblicksbild varje dag, den kommer att ligga dÀr och ta upp lite plats. Naturligtvis, om data Àndras, kommer mÀngden utrymme att öka med tiden. Denna ögonblicksbild kan hÀmtas nÀr som helst och informationen kan ÄterstÀllas, en sÄdan konstig lösning. Dessutom mÄste vi 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 fördröjning av replikor i schakten?
I Är planerar du att göra skaft i ClickHouse. Kommer det att vara möjligt att organisera en kontrollerad fördröjning av repliker i dem? Vi vill anvÀnda det 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 rollback för Ă€ndringar? Till exempel, i ett befintligt schakt, ta och sĂ€g att fram till denna punkt tillĂ€mpa Ă€ndringarna, och frĂ„n och med denna punkt sluta tillĂ€mpa Ă€ndringarna?
Om ett team kom till vÄrt kluster och förstörde det, har vi dÄ en villkorlig replik med en timmes fördröjning, dÀr vi kan sÀga att vi anvÀnder den just nu, men att vi inte kommer att tillÀmpa de sista tio minuterna av Àndringar pÄ den?
Först, om kontrollerad fördröjning av repliker. Det kom en sĂ„dan förfrĂ„gan frĂ„n anvĂ€ndare, och vi skapade ett Ă€rende pĂ„ GitHub med förfrĂ„gan: âOm nĂ„gon behöver detta, gillar det, sĂ€tt ett hjĂ€rta.â Ingen levererade, och Ă€rendet avslutades. Du kan dock redan fĂ„ denna möjlighet genom att skapa ClickHouse. Sant, bara frĂ„n och med version 20.3.
ClickHouse sammanfogar stÀndigt data i bakgrunden. NÀr en sammanslagning sker ersÀtts en viss uppsÀttning datablock med en större block. Samtidigt fortsÀtter de data som fanns dÀr tidigare att finnas kvar pÄ disken ett tag.
För det första fortsÀtter de att lagras sÄ lÀnge det finns urvalsfrÄgor som anvÀnder dem, för att sÀkerstÀlla att driften inte blockerar. Select-frÄgor kan lÀsas frÄn gamla chunks utan problem.
För det andra finns det ocksĂ„ en tidsgrĂ€ns â gamla data finns kvar pĂ„ disken i Ă„tta minuter. Dessa Ă„tta minuter kan anpassas och förvandlas till Ă€nnu en dag. Detta kommer att kosta diskutrymme: beroende pĂ„ dataflödet visar det sig att datamĂ€ngden under det sista dygnet inte bara kommer att fördubblas, utan det kan finnas fem gĂ„nger mer. Men om det uppstĂ„r ett allvarligt problem kan du stoppa ClickHouse-servern och ordna upp allt.
Nu uppstÄr frÄgan, hur skyddar detta mot förÀndringar? Det Àr vÀrt att titta djupare hÀr, eftersom i Àldre versioner av ClickHouse fungerade Àndringen pÄ ett sÄdant sÀtt att den helt enkelt Àndrade bitarna direkt. Det finns en datafil med nÄgra filer, och vi gör till exempel Àndra slÀppkolumnen. Sedan tas denna kolumn fysiskt bort frÄn alla delar.
Men frĂ„n och med version 20.3 Ă€ndrades Ă€ndringsmekanismen helt, och nu Ă€r datablock alltid oförĂ€nderliga. De Ă€ndras inte alls â alters fungerar nu pĂ„ i stort sett samma sĂ€tt som sammanslagningar. IstĂ€llet för att Ă€ndra en bit pĂ„ plats skapar vi en ny. I den nya chunken blir filer som inte har Ă€ndrats hĂ„rda lĂ€nkar, och om vi har tagit bort nĂ„gon kolumn kommer den helt enkelt att saknas i den nya chunken. Den gamla delen 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 borttagning eller Àndra uppdatering, den Àndrar inte stycket, utan skapar ett nytt. Och sedan raderar man den gamla.
Vad hÀnder om tabellstrukturen har Àndrats?
Hur kan jag Ă„terstĂ€lla en sĂ€kerhetskopia som gjorts med det gamla schemat? Och den andra frĂ„gan gĂ€ller fallet med snapshots och filsystemresurser. Ăr Btrfs lĂ€mpligt hĂ€r istĂ€llet för ZFS? Linux LVM?
Om du gör det fÀst partition partitioner med en annan struktur, sÄ kommer ClickHouse att sÀga att detta inte Àr möjligt. Lösningen Àr följande. Det första Àr att skapa en temporÀr tabell av MergeTree-typen med den gamla strukturen, koppla data dit med hjÀlp av attach och göra en alter-frÄga. Sedan kan du antingen kopiera eller flytta dessa data och bifoga dem igen, eller anvÀnda en frÄga Àndra tabell flytta partition.
Nu Àr den andra frÄgan om det Àr möjligt att anvÀnda Btrfs. Först och frÀmst, om du har LVM, sÄ rÀcker det med LVM-snapshots, och filsystemet kan vara ext4, det spelar ingen roll. Med Btrts beror allt pÄ din erfarenhet av att anvÀnda det. Det Àr ett moget filsystem, men det finns fortfarande vissa farhÄgor om hur det kommer att fungera i praktiken i ett givet scenario. Jag skulle inte rekommendera att anvÀnda detta om du inte har Btrfs i produktion.
Vilka Àr de bÀsta metoderna för data-resharding för nÀrvarande?
FrÄgan om resharding Àr komplex och mÄngfacetterad. HÀr kan du svara pÄ flera frÄgor samtidigt. Man kan nÀrma sig det frÄn ena sidan och sÀga sÄ hÀr: ClickHouse har ingen inbyggd resharding-funktion. Men jag Àr rÀdd att det hÀr svaret inte kommer att tillfredsstÀlla nÄgon. SÄ man kan nÀrma sig det frÄn andra sidan och sÀga att ClickHouse har mÄnga sÀtt att omstrukturera data.
Om klustret fÄr slut pÄ utrymme eller inte kan hantera belastningen lÀgger du till nya servrar. Men dessa servrar Àr tomma som standard, det finns ingen data pÄ dem och det Àr ingen belastning. Du mÄste ordna om informationen sÄ att den Àr jÀmnt fördelad över det nya, större klustret.
Det första sÀttet att göra detta Àr att kopiera nÄgra av partitionerna till de nya servrarna med hjÀlp av en frÄga Àndra tabell hÀmtningspartitionen. Till exempel, du hade partitioner per mÄnad, och du tar den första mÄnaden av 2017 och kopierar den till en ny server, sedan kopierar du den tredje mÄnaden till en annan ny server. Och du gör detta tills det blir mer eller mindre jÀmnt.
Endast partitioner som inte Àndras nÀr de skrivs till kan migreras. För nya partitioner mÄste skrivning inaktiveras eftersom deras överföring inte Àr atomÀr. Annars fÄr du dubbletter eller luckor i informationen. Denna metod Àr dock praktisk och fungerar ganska effektivt. FÀrdiga komprimerade partitioner överförs över nÀtverket, vilket innebÀr att informationen inte komprimeras eller kodas om.
Den hÀr metoden har en nackdel, och det beror pÄ sharding-schemat, om du planerade att anvÀnda detta sharding-schema och vilken sharding-nyckel du hade. I ditt exempel, för mÀtvÀrdesfallet, Àr sharding-nyckeln hashen för sökvÀgen. NÀr du vÀljer en distribuerad tabell gÄr den till alla shards i klustret samtidigt och hÀmtar data dÀrifrÄn.
Det betyder att det egentligen inte spelar nĂ„gon roll för dig vilken data som hamnar pĂ„ vilken shard. Det viktigaste Ă€r att data lĂ€ngs en vĂ€g hamnar pĂ„ en shard, men exakt vilken Ă€r inte viktigt. I det hĂ€r fallet Ă€r det perfekt att migrera fĂ€rdiga partitioner eftersom du med select-frĂ„gor ocksĂ„ fĂ„r fullstĂ€ndig data â bĂ„de före och efter resharding spelar schemat egentligen ingen roll.
Men det finns mer komplexa fall. Om du pÄ applikationslogiknivÄ förlitar dig pÄ ett speciellt sharding-schema, sÄ finns den hÀr klienten pÄ en viss shard, och begÀran kan skickas direkt dit, och inte till den distribuerade tabellen. Eller sÄ anvÀnder du en relativt ny version av ClickHouse och har aktiverat instÀllningen optimera hoppa över oanvÀnda shards. I det hÀr fallet, under urvalsfrÄgan, kommer uttrycket i where-klausulen att analyseras och det kommer att berÀknas vilka shards som ska gÄ till enligt sharding-schemat. Detta fungerar förutsatt att data partitioneras enligt detta sharding-schema. Om du har flyttat dem manuellt kan korrespondensen Àndras.
SÄ, det Àr vÀg nummer ett. Och jag vÀntar pÄ ditt svar, Àr den hÀr metoden lÀmplig eller ska vi gÄ vidare?
Vladimir Kolobaev, huvudsystemadministratör pÄ AvitoAlexey, metoden du nÀmnde fungerar inte sÀrskilt bra nÀr man behöver sprida ut arbetsbördan, inklusive lÀsning. Vi kan ta en partition som Àr mÄnadsvis och vi kan överföra föregÄende mÄnad till en annan nod, men nÀr en begÀran om dessa data kommer kommer vi bara att ladda dem. Men vi vill lÀsa in hela klustret, för annars kommer hela vÄr lÀsbelastning att bearbetas av tvÄ shards under en tid.
Alexey Milovidov: Svaret hĂ€r Ă€r konstigt â ja, det Ă€r dĂ„ligt, men det kanske fungerar. LĂ„t mig förklara exakt hur. Det Ă€r vĂ€rt att titta pĂ„ belastningsscenariot som ingĂ„r i dina data. Om detta Ă€r övervakningsdata Ă€r det nĂ€stan sĂ€kert att den stora majoriteten av förfrĂ„gningarna gĂ€ller fĂ€rsk data.
Du har konfigurerat nya servrar, migrerat gamla partitioner, men ocksÄ Àndrat hur ny data skrivs. Och fÀrsk data kommer att spridas över hela klustret. SÄledes kommer förfrÄgningarna frÄn de senaste fem minuterna att ladda klustret jÀmnt pÄ fem minuter, och pÄ en dag kommer förfrÄgningarna frÄn det senaste dygnet att ladda klustret jÀmnt. TyvÀrr kommer förfrÄgningar för föregÄende mÄnad bara att gÄ till en del av klusterservrarna.
Men ofta kommer du inte att ha förfrĂ„gningar specifikt för februari 2019. Om förfrĂ„gningar kommer under 2019 kommer de troligtvis att gĂ€lla hela 2019 â under en lĂ€ngre tidsperiod, och inte för nĂ„got kort intervall. Och sĂ„dana förfrĂ„gningar kommer ocksĂ„ att kunna ladda klustret jĂ€mnt. Men överlag Ă€r din poĂ€ng helt korrekt att detta Ă€r en ad hoc-lösning som inte sprider informationen helt jĂ€mnt.
Jag har nÄgra fler punkter för att besvara frÄgan. En av dem handlar om hur man initialt skapar ett sharding-schema sÄ att Ätersharding Àr mindre smÀrtsamt. Detta Àr inte alltid möjligt.
Till exempel har du övervakningsdata. Ăvervakningsdata ökar av tre skĂ€l. Det första Ă€r ackumulering av historisk data. Det andra Ă€r trafiktillvĂ€xten. Och det tredje Ă€r en ökning av antalet saker som Ă€r föremĂ„l för övervakning. Nya mikrotjĂ€nster och mĂ€tvĂ€rden dyker upp som behöver underhĂ„llas.
Det Ă€r möjligt att den största ökningen av dessa beror pĂ„ den tredje orsaken â ökningen av anvĂ€ndningen av övervakning. Och i det hĂ€r fallet Ă€r det vĂ€rt att titta pĂ„ lastens art, vilka Ă€r de viktigaste förfrĂ„gningarna för att vĂ€lja. De huvudsakliga urvalsfrĂ„gorna kommer troligtvis att handla om 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 med vilka du fÄr dessa data. Och sjÀlva begÀran om dessa data Àr troligtvis ganska enkel och exekveras pÄ tiotals millisekunder. AnvÀnds för övervakningstjÀnster, för dashboards. Jag hoppas att jag förstÄr detta rÀtt.
Vladimir Kolobajev: PoÀngen Àr att vi vÀldigt ofta hÀnvisar till historiska data, eftersom vi jÀmför den aktuella 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 hanterar detta perfekt.
Du har helt rÀtt, vi testar de flesta lÀsförfrÄgningarna under det senaste dygnet, precis som alla övervakningssystem. Men samtidigt Àr belastningen pÄ historisk data ocksÄ ganska stor. Det kommer frÀmst frÄn varningssystemet, som gÄr runt var trettio sekunder och sÀger till ClickHouse: "Ge mig data frÄn de senaste sex veckorna. Bygg nu ett slags glidande medelvÀrde av dem, och lÄt oss jÀmföra det aktuella vÀrdet med det historiska."
Jag skulle vilja sÀga att för sÄdana vÀldigt fÀrska förfrÄgningar har vi en annan 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 den stora shardade tabellen.
Alexey Milovidov: TyvÀrr fungerar det inte bra för ditt scenario, men jag ska beskriva tvÄ dÄliga och komplicerade sharding-scheman som inte borde anvÀndas, men som anvÀnds i mina vÀnners tjÀnst.
Det finns ett huvudkluster med Yandex.Metrica-hÀndelser. HÀndelser Àr sidvisningar, klick och övergÄngar. De flesta förfrÄgningar gÄr till en specifik webbplats. Du öppnar Yandex.Metrica-tjÀnsten, du har en webbplats - avito.ru, du gÄr till rapporten och en begÀran görs för 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 pĂ„peka att interna analytiker endast gör förfrĂ„gningar om Yandex-tjĂ€nster. Men Ă€ven Yandex-tjĂ€nster stĂ„r för en betydande andel av all data. Det hĂ€r Ă€r inte förfrĂ„gningar om specifika rĂ€knare, utan om bredare filtrering.
Hur organiserar man data pÄ ett sÄdant sÀtt att allt fungerar effektivt för en rÀknare, och Àven för globala frÄgor? En annan svÄrighet Àr att antalet förfrÄgningar i ClickHouse till Metrica-klustret Àr flera tusen per sekund. Samtidigt kan en ClickHouse-server inte hantera icke-triviala förfrÄgningar, till exempel flera tusen per sekund.
Klustrets storlek Àr sexhundra och nÄgot servrar. Om du bara strÀcker ut en distribuerad tabell över det hÀr klustret och skickar flera tusen förfrÄgningar dit, blir det Ànnu vÀrre Àn att skicka dem till en server. à andra sidan, alternativet att informationen ska spridas jÀmnt, och vi gÄr och begÀr den frÄn alla servrar, förkastar vi omedelbart.
Det finns ett diametralt motsatt alternativ. TÀnk dig om vi shardar data över olika webbplatser, och en begÀran för en webbplats gÄr till en shard. Nu kommer klustret att kunna hantera tiotusen förfrÄgningar per sekund, men pÄ en shard kommer en förfrÄgan att arbeta för lÄngsamt. Det kommer inte lÀngre att skalas i dataflöde. SÀrskilt om det Àr webbplatsen avito.ru. Jag kommer inte att avslöja en hemlighet om jag sÀger att Avito Àr en av de mest besökta webbplatserna pÄ RuNet. Och att bearbeta det pÄ en skÀrva vore galenskap.
DÀrför Àr sharding-schemat utformat pÄ ett mer sofistikerat sÀtt. Hela klustret Àr uppdelat i ett antal smÄ kluster, som vi kallar lager. Inom varje kluster finns det frÄn ett dussin till flera dussin skÀrvor. Det finns totalt trettionio sÄdana kluster.
Hur skalar allt detta? Antalet kluster har inte förĂ€ndrats - det förblev detsamma som det var för nĂ„gra Ă„r sedan, trettionio. Men inom var och en av dem ökar vi gradvis antalet shards allt eftersom data ackumuleras. Och sharding-schemat som helhet Ă€r följande: uppdelningen i dessa kluster görs av webbplatser, och för att förstĂ„ vilken webbplats som finns pĂ„ vilket kluster anvĂ€nds en helt separat metabas i MySQL. En plats â pĂ„ ett kluster. Och inuti den görs sharding med hjĂ€lp av besökaridentifierare.
Vid inspelningen delar vi upp dem enligt resten av besökar-ID-indelningen. Men nÀr vi lÀgger till en ny shard Àndras sharding-schemat, vi fortsÀtter att dela, men med resten frÄn att dividera med ett annat tal. Det betyder att en besökare redan finns pÄ flera servrar, och du kan inte rÀkna med detta. Detta görs enbart för att göra informationen mer komprimerbar. Och nÀr vi gör förfrÄgningar gÄr vi till den distribuerade tabellen, som tittar pÄ klustret och har Ätkomst till dussintals servrar. Det hÀr Àr ett sÄ dumt upplÀgg.
Men min berÀttelse skulle vara ofullstÀndig om jag inte sa att vi övergav den hÀr planen. I det nya schemat Àndrade vi allt och kopierade all data med hjÀlp av clickhouse-copier.
I det nya systemet Ă€r alla platser indelade i tvĂ„ kategorier: stora och smĂ„. Jag vet inte hur tröskelvĂ€rdet valdes dĂ€r, men resultatet blir att stora webbplatser skrivs till ett kluster, dĂ€r det finns 120 shards med tre repliker i varje â det vill sĂ€ga 360 servrar. Och sharding-schemat Ă€r sĂ„dant att varje förfrĂ„gan gĂ„r till alla shards samtidigt. Om du nu öppnar nĂ„gon sida i rapporten för avito.ru i Yandex.Metrica, kommer begĂ€ran att gĂ„ till 120 servrar. Det finns fĂ„ stora webbplatser i RuNet. Och förfrĂ„gningarna Ă€r inte tusen per sekund, utan Ă€nnu fĂ€rre Ă€n hundra. Allt detta tuggas lugnt av den distribuerade tabellen, som bearbetas av 120 servrar vardera.
Och det andra klustret Àr för smÄ webbplatser. HÀr Àr ett sharding-schema efter webbplats-ID, och varje begÀran gÄr till exakt en shard.
ClickHouse har ett verktyg som heter clickhouse-copier. Kan du berÀtta om henne?
Jag sÀger direkt att den hÀr lösningen Àr mer besvÀrlig och nÄgot mindre produktiv. Fördelen Àr att den sprider informationen helt enligt det mönster du anger. Men nackdelen med verktyget Àr att det inte gör resharding alls. Den kopierar data frÄn ett klusterschema till ett annat klusterschema.
Det betyder att du mÄste ha tvÄ kluster för att det ska fungera. De kan finnas pÄ samma servrar, men informationen kommer fortfarande inte att flyttas stegvis, utan kommer att kopieras.
Till exempel fanns det fyra servrar, nu finns det Ätta. Du skapar en ny distribuerad tabell pÄ alla servrar, nya lokala tabeller och startar clickhouse-copier, och anger i den arbetsschemat som den ska lÀsa dÀrifrÄn, accepterar det nya sharding-schemat och överför data dit. Och ni kommer att behöva en och en halv gÄnger mer utrymme pÄ de gamla servrarna Àn ni har nu, eftersom den gamla datan mÄste finnas kvar pÄ dem, och hÀlften av samma gamla data kommer att lÀggas ovanpÄ dem. Om du i förvÀg trodde att informationen behövde omdelas och att det finns utrymme, sÄ fungerar den hÀr metoden.
Hur fungerar ClickHouse-copier inuti? Den bryter ner allt arbete i en uppsÀttning uppgifter för att bearbeta 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 vad den gör för en partition Àr inget annat Àn att infoga och vÀlja. Data lÀses, dekomprimeras, ompartitioneras, komprimeras sedan igen, skrivs nÄgonstans och sorteras om. Detta Àr ett svÄrare beslut.
Ni hade en pilotgrej som hette resharding. Vad Àr det för fel pÄ henne?
Ni hade en pilotgrej 2017 som hette resharding. Det finns till och med ett alternativ i ClickHouse. Jag antar att den inte lyfte. Kan du berÀtta varför detta hÀnde? Det verkar vara vÀldigt relevant.
Problemet Ă€r att nĂ€r man behöver omstrukturera data pĂ„ plats, krĂ€ver det en mycket komplex synkronisering för att göra det atomĂ€rt. NĂ€r vi började titta pĂ„ hur denna synkronisering fungerar blev det tydligt att det finns grundlĂ€ggande problem. Och dessa grundlĂ€ggande problem Ă€r inte bara teoretiska, utan började ocksĂ„ omedelbart visa sig i praktiken i form av nĂ„got som kan förklaras mycket enkelt â ingenting fungerar.
Ăr det möjligt att sammanfoga alla datadelar innan man flyttar till lĂ„ngsamma diskar?
FrÄga om TTL med alternativet att flytta till lÄngsam disk i samband med sammanslagningar. Finns det ett annat sÀtt Àn cron att sammanfoga alla delar till ett innan man byter till lÄngsamma diskar?
Svaret pÄ frÄgan om det Àr möjligt att pÄ nÄgot sÀtt automatiskt limma alla bitar i en innan de överförs Àr nej. Jag tror inte att det finns nÄgot behov av detta. Du behöver inte slÄ ihop alla delar till en, utan rÀkna bara med att de överförs till lÄngsamma diskar automatiskt.
Vi har tvÄ kriterier för överföringsregler. Den första Àr nÀr den fylls upp. Om det finns mindre Àn en viss procentandel ledigt utrymme pÄ den aktuella lagringsnivÄn, vÀljer vi en chunk och flyttar den till den lÄngsammare lagringen. Mer exakt, inte lÄngsammare, utan nÀsta - som du stÀller in den.
Det andra kriteriet Àr storlek. Det handlar om att flytta stora delar. Du kan justera tröskelvÀrdet beroende pÄ det lediga utrymmet pÄ den snabba hÄrddisken, och informationen överförs automatiskt.
Hur migrerar man till nya versioner av ClickHouse om det inte finns nÄgot sÀtt att kontrollera kompatibilitet 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? Vilket Àr det bÀsta sÀttet att migrera till nya versioner utan att kunna kontrollera kompatibilitet i en sandlÄda i förvÀg?
Det finns flera "gyllene" regler hÀr. Först - . Den Àr stor, men den har separata punkter om bakÄtkompatibla förÀndringar. Dessa punkter bör inte tas som varningssignaler. Det hÀr Àr vanligtvis mindre inkompatibiliteter som involverar viss edge-funktionalitet som du förmodligen 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 produktion, Ă€r rekommendationen att inte göra detta. Skapa först en sandlĂ„da och testa den. Om det inte finns nĂ„gon testmiljö har du troligtvis 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. Du kan till och med köra nĂ„gra repliker lokalt pĂ„ din maskin. Eller sĂ„ kan du stĂ€lla in en ny version nĂ„gonstans i nĂ€rheten och ladda upp lite data till den â det vill sĂ€ga skapa en improviserad testmiljö.
En annan regel Àr att inte uppdatera under en vecka efter att en version slÀppts pÄ grund av buggsökning i produktionen och efterföljande snabba korrigeringar. LÄt oss titta pÄ ClickHouse-versionsnumreringen för att undvika förvirring.
Det finns version 20.3.4. Siffran 20 stĂ„r för produktionsĂ„ret - 2020. NĂ€r det gĂ€ller vad som finns inuti spelar detta ingen roll alls, sĂ„ vi kommer inte att uppmĂ€rksamma det. NĂ€sta - 20.3. Vi ökar det andra numret â i det hĂ€r fallet 3 â varje gĂ„ng vi slĂ€pper en ny funktion. Om vi ââvill lĂ€gga till nĂ„gon funktion i ClickHouse mĂ„ste vi öka detta antal. Det betyder att ClickHouse kommer att fungera Ă€nnu bĂ€ttre i version 20.4. Den tredje siffran Ă€r 20.3.4. HĂ€r Ă€r 4 antalet patch-utgĂ„vor dĂ€r vi inte lade till nya funktioner, men fixade vissa buggar. Och 4 betyder att vi gjorde det fyra gĂ„nger.
Det finns ingen anledning att tro att detta Àr nÄgot hemskt. Vanligtvis kan en anvÀndare installera den senaste versionen och den kommer att fungera utan problem med drifttiden i ett Är. Men tÀnk 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 mÄste fixa det hÀr. Vi kommer att slÀppa en ny patchversion och ClickHouse kommer att bli mer stabil.
Om du har ClickHouse i produktion och en ny version av ClickHouse kommer ut med ytterligare funktioner â till exempel 20.4.1 â den allra första, sĂ„ skynda dig inte att installera den i produktion redan första dagen. Varför behövs det överhuvudtaget? Om du inte redan anvĂ€nder ClickHouse kan du installera det och troligtvis kommer allt att fungera. Men om ClickHouse redan fungerar stabilt, följ dĂ„ patcharna och uppdateringarna - vilka problem vi Ă„tgĂ€rdar.
Kirill Shvakov: Jag skulle vilja tillÀgga 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Ä borde testmiljön inte vara mindre eller Ätminstone tio gÄnger mindre. Detta Àr inte sant alls.
Jag kan berĂ€tta det av egen erfarenhet. Jag har ett projekt och det har ClickHouse. VĂ„r testmiljö specifikt för honom Ă€r en liten virtuell maskin i Hetzner för tjugo euro, dĂ€r absolut allting Ă€r driftsatt. 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 rulla â till hĂ„rdvaruservrar eller helt enkelt distribuera i virtuella maskiner.
Vad kan göras? Det vore bra att ha ett exempel i ClickHouse-dokumentationen pĂ„ hur man driftsĂ€tter ett litet kluster â i Docker, i LXC, kanske skapa en Ansible-playbook, eftersom olika personer har olika driftsĂ€ttningar. Detta kommer att göra saker och ting mycket enklare. NĂ€r man bara kan fĂ„ igĂ„ng ett kluster pĂ„ fem minuter Ă€r det mycket lĂ€ttare att försöka lista ut saker. Detta Ă€r mycket bekvĂ€mare, eftersom det Ă€r en vĂ€g till ingenstans att lansera en version till produktion som du inte har testat. 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 pĂ„ Avito: Jag ska lĂ€gga till lite om testmiljöer frĂ„n serien av problem hos stora företag. Vi har ett fullfjĂ€drat ClickHouse-acceptanskluster, med datascheman och instĂ€llningar som Ă€r en exakt kopia av vad som finns i produktion. Detta kluster distribueras i ganska skrangliga containrar med minimala resurser. Vi skriver en viss procentandel av produktionsdata dĂ€r, eftersom det Ă€r möjligt att replikera strömmen i Kafka. Allt dĂ€r Ă€r synkroniserat och skalbart â bĂ„de vad gĂ€ller kapacitet och flöde, och i teorin, allt annat lika, borde det bete sig som produktion vad gĂ€ller mĂ€tvĂ€rden. Allt potentiellt explosivt material 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 noll.
Alexey Milovidov: LÄt mig berÀtta hur testmiljön hos vÄra vÀnner frÄn Yandex.Metrica ser ut. Ett kluster hade cirka 600 servrar, ett annat hade 360, och det finns ett tredje och flera kluster. Testmiljön för en av dem Àr helt enkelt tvÄ shards med tvÄ repliker i varje. Varför tvÄ skÀrvor? SÄ att jag inte Àr ensam. Och det borde finnas replikor ocksÄ. Bara ett visst minimibelopp du har rÄd med.
Den hÀr testmiljön lÄter dig kontrollera att dina frÄgor fungerar och att inget allvarligt Àr trasigt. Men ofta uppstÄr problem av helt annan karaktÀr, nÀr allt fungerar, men det sker nÄgra smÄ förÀndringar med belastningen.
LÄt mig ge dig ett exempel. BestÀmde mig för att installera en ny version av ClickHouse. Den har laddats upp till testmiljön, och automatiserade tester har genomförts i sjÀlva Yandex.Metrica, vilka jÀmför data pÄ den gamla versionen och den nya, och kör hela pipelinen. Och naturligtvis gröna tester av vÄrt CI. Annars hade vi inte ens föreslagit den hÀr versionen.
Allt Àr bra. Vi börjar rulla in i produktionen. Jag fÄr ett meddelande om att belastningen pÄ graferna har ökat flera gÄnger. Vi ÄterstÀller versionen. Jag tittar pÄ grafen och ser att belastningen faktiskt ökade flera gÄnger under utrullningen, och sedan minskade igen nÀr den rullades ut. Sedan började vi rulla tillbaka versionen. Och belastningen ökade pÄ exakt samma sÀtt och sjönk sedan tillbaka pÄ exakt samma sÀtt. SÄ slutsatsen Àr denna: belastningen har ökat pÄ grund av layouten, inget förvÄnande.
Det var dĂ„ svĂ„rt att övertyga kollegorna att installera den nya versionen. Jag sĂ€ger: âAllt Ă€r bra, kör pĂ„. HĂ„ll tummarna, allt kommer att ordna sig. Nu har belastningen pĂ„ graferna ökat, men allt Ă€r bra. HĂ„ll ut.â I allmĂ€nhet gjorde vi det sĂ„ hĂ€r, och det Ă€r allt â versionen Ă€r publicerad i produktion. Men med nĂ€stan varje layout uppstĂ„r liknande problem.
Kill query borde avsluta frÄgor, men det gör den inte. Varför?
En anvĂ€ndare, nĂ„gon analytiker, kom till mig och skapade en frĂ„ga som kraschade mitt ClickHouse-kluster. En nod eller hela klustret, beroende pĂ„ vilken replik eller shard som begĂ€ran trĂ€ffade. Jag ser att alla CPU-resurser pĂ„ den hĂ€r servern finns pĂ„ hyllan, allt Ă€r rött. Samtidigt svarar ClickHouse sjĂ€lvt pĂ„ förfrĂ„gningar. Och jag skriver: âVisa mig processlistan, vilken frĂ„ga som genererade denna galenskap.â
Jag hittar den hÀr förfrÄgan och skriver kill till den. Och jag ser att ingenting hÀnder. Min server stÄr i hyllan, ClickHouse ger mig sedan nÄgra kommandon, visar att servern Àr aktiv och att allt Àr toppen. Men jag har försÀmring i alla anvÀndarfrÄgor, försÀmringen börjar nÀr jag skriver till ClickHouse, och min kill-frÄga fungerar inte. Varför? Jag trodde att kill query skulle avsluta queries, men det gör det inte.
Nu kommer det ett ganska mÀrkligt svar. Grejen Àr den att kill query inte kill queries.
En avstÀngningsfrÄga sÀtter en liten flagga som heter "Jag vill att den hÀr frÄgan ska avstÀngas". Och sjÀlva begÀran tittar pÄ denna flagga nÀr den bearbetar varje block. Om den Àr instÀlld slutar begÀran att fungera. Det visar sig att ingen dödar förfrÄgan, den mÄste kontrollera allt sjÀlv och stoppa. Och detta borde fungera i alla fall dÀr begÀran Àr i datablockbearbetningstillstÄnd. Den kommer att bearbeta nÀsta datablock, kontrollera flaggan och stoppa.
Detta fungerar inte i fall dÀr begÀran Àr blockerad för nÄgon ÄtgÀrd. Detta Àr dock troligtvis inte ditt fall, eftersom det, enligt dig, anvÀnder mycket serverresurser. Det kanske inte fungerar för extern sortering och vissa andra detaljer. Men generellt sett borde detta inte hÀnda, det Àr en bugg. Och det enda jag kan rÄda Àr att uppdatera ClickHouse.
Hur berÀknar man svarstid under lÀsbelastning?
Det finns en tabell som lagrar aggregeringar per objekt - olika rÀknare. Antalet linjer Àr ungefÀr hundra miljoner. Kan man förvÀnta sig en förutsÀgbar svarstid om man hÀller 1 RPS pÄ 1 föremÄl?
Att döma av sammanhanget talar vi om lÀsbelastningen, eftersom det inte finns nÄgra problem med att skriva - du kan infoga minst tusen, minst hundra tusen och ibland till och med flera miljoner rader.
LÀsfrÄgor finns i alla möjliga olika typer. I select 1 kan ClickHouse utföra ungefÀr tiotusentals frÄgor per sekund, sÄ Àven frÄgor för en nyckel kommer redan att krÀva vissa resurser. Och sÄdana punktfrÄgor kommer att vara mer komplicerade Àn i vissa nyckel-vÀrdesdatabaser, eftersom det för varje lÀsning Àr nödvÀndigt att lÀsa ett datablock efter index. VÄrt index behandlar inte varje post, utan varje intervall. Det vill sÀga, du mÄste lÀsa hela intervallet - det Àr 8192 rader som standard. Och du mÄste dekomprimera det komprimerade datablocket frÄn 64 KB till 1 MB. Vanligtvis tar sÄdana punktförfrÄgningar nÄgra millisekunder. Men detta Àr det enklaste alternativet.
LÄt oss försöka göra lite enkel aritmetik. Om du multiplicerar nÄgra millisekunder med tusen fÄr du nÄgra sekunder. Det verkar omöjligt att hantera tusen förfrÄgningar per sekund, men i sjÀlva verket Àr det möjligt, eftersom vi har flera processorkÀrnor. SÄ, i princip, kan ClickHouse ibland upprÀtthÄlla 1000 RPS, men bara pÄ korta, specifikt riktade, frÄgor.
Om du behöver skala ett ClickHouse-kluster med antalet enkla frĂ„gor, rekommenderar jag det enklaste â öka antalet repliker och skicka frĂ„gor till en slumpmĂ€ssig replik. Om en replik rymmer femhundra förfrĂ„gningar per sekund, vilket Ă€r helt realistiskt, sĂ„ kommer tre repliker att rymma ett och ett halvt tusen.
Ibland kan du naturligtvis konfigurera ClickHouse till 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 baseras pÄ berÀkningen 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.
Det Àr möjligt att minska storleken pÄ det komprimerade blocket. Det finns instÀllningar för detta. min komprimeringsblockstorlek, maximal komprimeringsblockstorlek. De kan minskas, informationen kan fyllas i pÄ nytt, och dÄ blir punktfrÄgor snabbare. Men ClickHouse Àr fortfarande inte en nyckel-vÀrdesdatabas. Ett stort antal smÄ förfrÄgningar Àr ett belastningsmotmönster.
Kirill Shvakov: Jag ska ge dig nĂ„gra rĂ„d ifall det finns vanliga konton dĂ€r. Detta Ă€r en ganska vanlig situation nĂ€r nĂ„gon rĂ€knare lagras i ClickHouse. Jag har en anvĂ€ndare, han Ă€r frĂ„n ett visst land, det finns ocksĂ„ ett tredje fĂ€lt, och jag behöver öka nĂ„got stegvis. Du tar MySQL, skapar en unik nyckel â i MySQL Ă€r det en duplicerad nyckel, och i PostgreSQL Ă€r det en konflikt â och lĂ€gger till ett plustecken. Detta kommer att fungera mycket bĂ€ttre.
NÀr du inte har mycket data Àr det inte sÄ mycket poÀng med att anvÀnda ClickHouse. Det finns vanliga databaser, och de gör detta bra.
Vad ska jag stÀlla in i ClickHouse för att ha mer data i cachen?
LÄt oss förestÀlla oss en situation - servrarna har 256 GB RAM, i det dagliga tar ClickHouse cirka 60-80 GB, som mest - upp till 130. Vad kan aktiveras och justeras sÄ att mer data finns i cachen och dÀrmed fÀrre resor till disken?
Vanligtvis gör operativsystemets sidcache ett bra jobb med den hĂ€r uppgiften. Om du bara öppnar toppen, letar dĂ€r efter cachad eller ledig â det stĂ„r ocksĂ„ hur mycket som Ă€r cachad â dĂ„ kan du se att allt ledigt minne anvĂ€nds för cache. Och nĂ€r man lĂ€ser dessa data kommer de inte att lĂ€sas frĂ„n disken, utan frĂ„n RAM-minnet. Samtidigt kan jag sĂ€ga att cachen anvĂ€nds effektivt eftersom det Ă€r den komprimerade datan som cachas.
Men om du vill snabba upp vissa enkla frÄgor Ànnu mer finns det ett alternativ att aktivera cachelagring i dekomprimerad data i ClickHouse. Det kallas okomprimerad cache. I konfigurationsfilen config.xml stÀller du 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 gÄr till sidans cache.
Dessutom finns det tvĂ„ instĂ€llningar pĂ„ begĂ€rannivĂ„. Första installationen - anvĂ€nd okomprimerad cache â inkluderar dess anvĂ€ndning. Det rekommenderas att aktivera det för alla förfrĂ„gningar, förutom tunga, vilka kan lĂ€sa all data och tömma cachen. Och den andra instĂ€llningen Ă€r nĂ„got i stil med det maximala antalet rader som ska anvĂ€ndas i cachen. Den begrĂ€nsar automatiskt stora frĂ„gor sĂ„ att de inte cachas.
Hur kan jag konfigurera storage_configuration för att lagra i RAM?
I den nya ClickHouse-dokumentationen lÀste jag avsnittet relaterat till . Det finns ett exempel med snabb SSD i beskrivningen.
Jag undrar hur samma sak kan konfigureras med volym-hot-minne. Och en frÄga till. Hur fungerar select med sÄdan dataorganisation, kommer den att lÀsa hela uppsÀttningen eller bara den som finns pÄ disk, och Àr denna data komprimerad i minnet? Och hur fungerar prewhere-sektionen med en sÄdan dataorganisation?
Den hÀr instÀllningen pÄverkar hur datablock lagras 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 konfigureras för en disk Àr dess sökvÀg. Du skapar en tmpfs-partition som Àr monterad pÄ nÄgon sökvÀg i filsystemet. Du anger den hÀr sökvÀgen som sökvÀgen för att lagra data för den hetaste partitionen, data börjar anlÀnda och skrivas dit, allt Àr bra.
Men jag rekommenderar inte att göra detta pÄ grund av lÄg tillförlitlighet, Àven om du kan göra det om du har minst tre repliker i olika datacenter. Om nÄgot hÀnder kommer informationen att ÄterstÀllas. LÄt oss förestÀlla oss att servern plötsligt stÀngdes av och sedan pÄ igen. SkiljevÀggen monterades igen, men den var tom. Vid uppstart ser ClickHouse-servern att dessa delar saknas, Àven om de enligt ZooKeeper-metadata borde finnas dÀr. Han tittar pÄ vilka replikor de finns pÄ, begÀr dem och laddar ner dem. PÄ sÄ sÀtt kommer informationen att ÄterstÀllas.
I den hÀr meningen Àr det inte fundamentalt annorlunda att lagra data i RAM-minnet frÄn att lagra dem pÄ disk, eftersom nÀr data skrivs till disk gÄr de ocksÄ först till sidcachen och skrivs fysiskt uppskjutet. Det beror pÄ filsystemets monteringsalternativ. Men bara för sÀkerhets skull vill jag sÀga att ClickHouse inte gör fsync vid insert.
I det hÀr fallet lagras informationen i RAM-minnet i exakt samma format som pÄ disken. PÄ liknande sÀtt vÀljer urvalsfrÄgan de segment som behöver lÀsas, vÀljer de nödvÀndiga dataintervallen inom segmenten och lÀser dem. Och prewhere fungerar exakt likadant, oavsett om informationen fanns i RAM-minnet eller pÄ disken.
Upp till hur mÄnga unika vÀrden Àr lÄg kardinalitet effektiv?
LĂ„g kardinalitet Ă€r smart utformad. Den bygger dataordböcker, men de Ă€r lokala. För det första Ă€r ordböckerna olika för varje stycke, och för det andra kan de Ă€ven inom ett stycke vara olika för varje intervall. NĂ€r antalet unika vĂ€rden nĂ„r ett tröskelvĂ€rde â jag tror en miljon â lĂ€ggs ordboken helt enkelt Ă„t sidan och en ny skapas.
Svaret i allmĂ€nhet Ă€r att för varje lokalt intervall â sĂ€g, varje dag â nĂ„gonstans upp till en miljon unika vĂ€rden, Ă€r lĂ„g kardinalitet effektiv. EfterĂ„t kommer det helt enkelt att finnas en reservfunktion, som kommer att anvĂ€nda mĂ„nga olika ordböcker, inte bara en. Den kommer att fungera pĂ„ ungefĂ€r samma sĂ€tt som en vanlig strĂ€ngkolumn, kanske lite mindre effektivt, men det kommer inte att bli nĂ„gon allvarlig försĂ€mring av prestandan.
Vilka Àr de bÀsta metoderna för fulltextsökning i en tabell med 5 miljarder rader?
Det finns olika möjliga svar. Det första Àr att sÀga att ClickHouse inte Àr ett fulltextsöksystem. Det finns speciella system för detta, till exempel О . Jag möter dock allt oftare mÀnniskor som sÀger att de byter frÄn Elasticsearch till ClickHouse.
Varför hÀnder detta? De förklarar detta med att Elasticsearch slutar hantera lasten vid vissa volymer, med början i konstruktionen av index. Index blir för otympliga, och om man bara flyttar datan till ClickHouse visar det sig att de lagras volymmÀssigt flera gÄnger mer effektivt. Dessutom var sökfrÄgor ofta inte sÄdana att det var nödvÀndigt att hitta en viss fras i hela datamÀngden med hÀnsyn till morfologi, utan helt andra. Till exempel, hitta en delsekvens 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 datamÀngden kommer att vara just per datumintervall. Inom det valda datumintervallet Àr det som regel redan möjligt att utföra en fulltextsökning Àven med brute-force-metoden med hjÀlp av "like". Gilla-operatorn i ClickHouse Àr den kraftfullaste gilla-operatorn du kan hitta. Om du hittar nÄgot bÀttre, sÀg till.
Men ÀndÄ, liksom en fullstÀndig skanning. Och en fullstÀndig skanning kan vara lÄngsam, inte bara för processorn utan Àven för hÄrddisken. Om du plötsligt har en terabyte data per dag, och du söker efter ett ord under dagen, dÄ mÄste du skanna en terabyte. 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 ytterligare ett litet knep. 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 testat dessa index, och de fungerar ofta precis som avsett.
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 man vÀljer dess storlek. Jag kan sÀga att de kommer att hjÀlpa till med frÄgor om vissa sÀllsynta fraser, delstrÀngar som sÀllan finns i data. I det hÀr fallet kommer delintervall att vÀljas baserat pÄ indexen och mindre data kommer att lÀsas.
ClickHouse har nyligen lagt till Ànnu mer avancerade funktioner för fulltextsökning. Först söker den efter en mÀngd delstrÀngar samtidigt i ett svep, inklusive skiftlÀgeskÀnsliga, skiftlÀgesokÀnsliga, UTF-8-aktiverade eller endast ASCII-alternativ. VÀlj den mest effektiva du behöver.
Det finns ocksÄ en ny funktion för att söka efter flera reguljÀra uttryck i ett svep. 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 stavade ett ord fel, kommer det att sökas efter den maximala matchningen.
Vilket Àr det bÀsta sÀttet att organisera Ätkomst till ClickHouse för ett stort antal anvÀndare?
BerÀtta för oss hur vi bÀst organiserar Ätkomst för ett stort antal konsumenter och analytiker. Hur skapar man en kö, prioriterar maximalt antal samtidiga frÄgor och med vilka verktyg?
Om klustret Àr tillrÀckligt stort, vore en bra lösning att skapa ytterligare tvÄ servrar, vilket blir ingÄngspunkten för analytiker. Det vill sÀga, tillÄt inte analytiker att komma Ät specifika klusterfragment, 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, du konfigurerar allt pÄ dessa tvÄ servrar, och instÀllningarna pÄverkar hela klustret.
I princip Àr dessa servrar datalösa, men mÀngden RAM pÄ dem Àr mycket viktig för att utföra förfrÄgningar. Disk kan ocksÄ anvÀndas för tillfÀlliga data om extern aggregering eller extern sortering Àr aktiverad.
Det Àr viktigt att titta pÄ de instÀllningar som Àr kopplade till alla möjliga grÀnser. Om jag nu gÄr till Yandex.Metrica-klustret som analytiker och skriver in en frÄga vÀlj antal frÄn trÀffar, dÄ fÄr jag omedelbart ett undantag om att jag inte kan uppfylla begÀran. Det maximala antalet rader jag fÄr skanna Àr ett hundra miljarder, och det finns femtio biljoner av dem i en enda 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Ă„ ser jag följande undantag - instĂ€llningen Ă€r aktiverad tvinga index efter datum. Jag kan inte köra frĂ„gan om jag inte anger ett datumintervall. Du bör inte förlita dig pĂ„ att analytiker matar in det manuellt. Ett typiskt fall Ă€r nĂ€r ett datumintervall skrivs dĂ€r hĂ€ndelsedatumet Ă€r mellan vecka. Och sedan satte de helt enkelt parentesen pĂ„ fel plats, och istĂ€llet för och fick de eller â eller URL-matchning. Om det inte finns nĂ„gon grĂ€ns kommer den att skanna URL-kolumnen och slösa bort massor av resurser.
Dessutom har ClickHouse tvĂ„ prioritetsinstĂ€llningar. TyvĂ€rr Ă€r de vĂ€ldigt primitiva. En kallas helt enkelt prioritet. Om prioritet â 0, och förfrĂ„gningar med viss prioritet körs, men samtidigt körs en förfrĂ„gan med ett lĂ€gre prioritetsvĂ€rde, vilket innebĂ€r en högre prioritet, sĂ„ pausas förfrĂ„gan med ett högre prioritetsvĂ€rde, vilket innebĂ€r en lĂ€gre prioritet, helt enkelt 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 det Àr en konstant belastning pÄ klustret. Men om du har korta, pulserade frÄgor som Àr viktiga, och klustret Àr mestadels inaktivt, kommer den hÀr konfigurationen att fungera.
NĂ€sta prioritetsinstĂ€llning kallas OS-trĂ„dprioritetDen anger helt enkelt det fina vĂ€rdet för schemalĂ€ggaren för alla trĂ„dar för exekvering av begĂ€ran. LinuxDet fungerar slarvigt, men det fungerar Ă€ndĂ„. Om du stĂ€ller in nice-vĂ€rdet till det lĂ€gsta vĂ€rdet â det Ă€r det största och dĂ€rför den lĂ€gsta prioriteten â och stĂ€ller in högprioriterade förfrĂ„gningar till -19, kommer lĂ„gprioriterade förfrĂ„gningar att förbruka ungefĂ€r fyra gĂ„nger mindre CPU Ă€n högprioriterade.
Du mĂ„ste ocksĂ„ ange den maximala körtiden för frĂ„gan â sĂ€g fem minuter. Minimihastigheten för frĂ„gekörning Ă€r det coolaste. Den hĂ€r instĂ€llningen har funnits lĂ€nge, och det krĂ€vs inte bara för att pĂ„stĂ„ att ClickHouse inte Ă€r lĂ„ngsamt, utan för att tvinga fram det.
TĂ€nk dig att du konfigurerar: om en frĂ„ga bearbetar fĂ€rre Ă€n en miljon rader per sekund kan du inte göra det. Detta Ă€r en skam för vĂ„rt goda namn, vĂ„r utmĂ€rkta databas. LĂ„t oss bara förbjuda detta. Det finns egentligen tvĂ„ instĂ€llningar. En kallas minsta exekveringshastighet â i rader per sekund, och den andra kallas timeout innan minsta exekveringshastighet kontrolleras â som standard femton sekunder. Det vill sĂ€ga, femton sekunder Ă€r möjligt, och sedan, om det Ă€r lĂ„ngsamt, kastar man helt enkelt ett undantag och avbryter begĂ€ran.
Du behöver ocksÄ sÀtta upp kvoter. ClickHouse har en inbyggd kvotfunktion som rÀknar resursförbrukning. Men tyvÀrr inte hÄrdvaruresurser som CPU, diskar, utan logiska - antalet bearbetade förfrÄgningar, rader och lÀsta byte. Och du kan till exempel stÀlla in maximalt hundra förfrÄgningar inom fem minuter och tusen förfrÄgningar per timme.
Varför Àr detta viktigt? Eftersom vissa av analysfrÄgorna 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 det hÀr felet kommer att göra att frÄgan körs i en oÀndlig loop. Det hÀr Àr vad vi behöver skydda oss mot.
Ăr det möjligt att ge resultaten av en frĂ„ga till tio klienter?
Vi har nĂ„gra anvĂ€ndare som gĂ€rna kommer in med vĂ€ldigt stora förfrĂ„gningar samtidigt. BegĂ€ran Ă€r stor, och i princip behandlas den snabbt, men pĂ„ grund av att det finns mĂ„nga sĂ„dana förfrĂ„gningar samtidigt blir det mycket smĂ€rtsamt. Ăr det möjligt att köra samma begĂ€ran som har kommit tio gĂ„nger i rad en gĂ„ng och ge resultatet till tio klienter?
Problemet Àr att vi varken har resultatcachen eller mellanliggande datacache. Det finns en sidcache i operativsystemet, vilket gör att du kan undvika att lÀsa data frÄn disken igen, men tyvÀrr kommer informationen fortfarande att dekomprimeras, avserialiseras och bearbetas igen.
Jag skulle vilja undvika detta pĂ„ nĂ„got sĂ€tt, antingen genom att cacha mellanliggande data, eller genom att rada upp liknande förfrĂ„gningar i nĂ„gon form av kö och lĂ€gga till en cache med resultat. Vi har för nĂ€rvarande en pull request under utveckling som lĂ€gger till en frĂ„gecache, men bara för underfrĂ„gor i in- och join-sektionerna â sĂ„ lösningen Ă€r ofullstĂ€ndig.
Men Àven vi har den hÀr situationen. Ett sÀrskilt kanoniskt exempel Àr frÄgor med paginering. 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 annan sida. Och frÄgan Àr, varför rÀknar vi 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 en sidovagn bredvid ClickHouse - .
Kirill Shvakov: ClickHouse Proxy har en inbyggd hastighetsbegrÀnsare och en inbyggd resultatcache. MÄnga instÀllningar gjordes dÀr eftersom ett liknande problem löstes. Med proxy kan du begrÀnsa förfrÄgningar genom att köa dem 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 det kommer ocksÄ att fungera. Nginx har till och med instÀllningar som gör att om förfrÄgningar kommer in samtidigt, sÄ saktar de andra ner tills en Àr klar. Men det Àr i ClickHouse Proxy som instÀllningarna Àr mycket bÀttre gjorda. Den gjordes specifikt för ClickHouse, specifikt för dessa önskemÄl, sÄ den Àr mer lÀmplig. Tja, det Àr lÀtt att installera.
Vad sÀgs om asynkrona operationer och materialiserade vyer?
Det finns ett problem med att operationer med replikeringsmotorn Àr asynkrona - först skrivs data, sedan komprimeras de. Om en materialiserad platta med nÄgra enheter finns under plattan, kommer dubbletter att skrivas in i den. Och om det inte finns nÄgon komplex logik, kommer informationen att dupliceras. Vad kan man göra Ät detta?
Det finns en uppenbar lösning - implementera en trigger pÄ en specifik klass av matvyukh under en asynkron kollapsoperation. Finns det nÄgra "mystiska lösningar" eller planer pÄ att implementera liknande funktioner?
Det Àr vÀrt att förstÄ hur deduplicering fungerar. Det jag ska berÀtta Àr inte relevant för frÄgan, men det Àr vÀrt att komma ihÄg ifall att.
Vid infogning i en replikerad tabell sker deduplicering av hela infogade block. Om du infogar samma block igen som innehÄller samma antal av samma rader i samma ordning, dedupliceras data. Du fÄr ett "Ok"-svar för att infoga, men i sjÀlva verket kommer en enda databatch att skrivas och den kommer inte att dupliceras.
Detta Àr nödvÀndigt för sÀkerhetens skull. Om du fÄr "Ok" under inmatningen har dina data infogades. Om du fÄr ett felmeddelande frÄn ClickHouse betyder det att de inte har infogats och att du mÄste upprepa infogningen. Men om anslutningen bryts under infogningen, vet du inte om informationen har infogas eller inte. Det enda alternativet Àr att upprepa insÀttningen igen. Om data faktiskt infogades och du infogar dem igen, sker blockdeduplicering. Det behövs för att undvika dubbletter.
Och det Àr ocksÄ viktigt hur det fungerar för materialiserade representationer. Om data deduplicerades nÀr de infogades i huvudtabellen kommer de inte heller att visas i den materialiserade vyn.
Nu angÄende frÄgan. Din situation Àr mer komplicerad eftersom du skriver dubbletter av enskilda rader. Det vill sÀga, det Àr inte hela paketet som dupliceras, utan specifika rader, och de kollapsar i bakgrunden. Visserligen kommer informationen att hopfÀllas i huvudtabellen, men den ohopfÀllda informationen kommer att hamna i den materialiserade vyn, och ingenting kommer att hÀnda med de materialiserade vyerna under sammanslagningarna. Eftersom en materialiserad vy inte Àr nÄgot mer Àn en infogningstrigger. Under andra operationer hÀnder inget annat med den.
Och jag kan inte ge nĂ„gon glĂ€dje hĂ€r. Vi behöver bara leta efter en specifik lösning för det hĂ€r fallet. Ăr det till exempel möjligt att göra replikering i en materialiserad vy ocksĂ„, och dedupliceringsmetoden kan fungera pĂ„ samma sĂ€tt. Men tyvĂ€rr, inte alltid. Om det Ă€r aggregerande kommer det inte att fungera.
Kirill Shvakov: Vi hade ocksĂ„ tillverkning av kryckor pĂ„ den tiden. Det uppstod ett problem med att det finns annonsvisningar, och det finns viss data som vi kan visa i realtid â det hĂ€r Ă€r bara visningar. De dupliceras sĂ€llan, men om det hĂ€nder kommer vi att kollapsa dem Ă€ndĂ„. Och det fanns saker som inte kunde dupliceras â klick och allt det dĂ€r. Men jag ville ocksĂ„ visa dem nĂ€stan omedelbart.
Hur gjordes de materialiserade representationerna? Det fanns representationer dÀr det skrivs direkt - det skrivs till rÄdata, och det skrivs till vyer. DÀr, vid nÄgon tidpunkt, Àr informationen inte sÀrskilt korrekt, den dupliceras, och sÄ vidare. Och det finns en andra del av tabellen, dÀr de ser helt likadana ut som materialiserade vyer, det vill sÀga, i struktur Àr de helt identiska. DÄ och dÄ berÀknar vi om informationen, berÀknar informationen utan dubbletter och skriver den i tabellerna.
Vi gick igenom API:et â i ClickHouse fungerar detta inte manuellt. Och API:et ser ut: nĂ€r jag har datumet för det senaste tillĂ€gget till tabellen, dĂ€r korrekta data garanteras att berĂ€knas, 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 enbart med hjĂ€lp av ClickHouse.
Om du har nĂ„gon form av API â för analytiker, för anvĂ€ndare â sĂ„ Ă€r detta i princip ett alternativ. Du adderar alltid, du rĂ€knar alltid om. Detta kan göras en gĂ„ng om dagen eller vid nĂ„gon annan tidpunkt. Du vĂ€ljer sjĂ€lv det intervall som du inte behöver och som inte Ă€r kritiskt.
ClickHouse har mÄnga loggar. Hur kan jag se allt som hÀnder med servern just nu?
ClickHouse har ett mycket stort antal olika loggar, och detta antal ö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. Jag skulle vilja se i slutÀndan vad som hÀnder med min server nu, kanske pÄ nÄgon form av konsoliderad instrumentpanel.
Har ni nÄgra ClickHouse-teammedlemmar, eller nÄgot av era vÀnners team, som stöder nÄgon funktionalitet hos fÀrdiga dashboards 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 vore riktigt coolt om detta redan var förberett i form av en dashboard. Jag skulle fÄ en kick av det hÀr.
Det finns dashboards, men de Àr inte standardiserade. Vi har ungefÀr 60 team i vÄrt företag som anvÀnder ClickHouse, och det konstigaste Àr att mÄnga av dem har dashboards som de sjÀlva har skapat, och lite annorlunda. Vissa team anvÀnder en intern installation av Yandex.Cloud. Det finns nÄgra fÀrdiga rapporter, men alla Àr inte nödvÀndiga. Andra har sina egna.
Mina kollegor frÄn Metrika har sin egen dashboard i Grafana, och jag har min för deras kluster. Jag letar dÀr efter saker som cachetrÀff för cachen av marks. Och det som Àr Ànnu svÄrare Àr att vi anvÀnder olika verktyg. Jag skapade min dashboard i ett mycket gammalt verktyg som heter Graphite-web. Han Àr inte alls snygg. Och jag anvÀnder det fortfarande, Àven om Grafana förmodligen skulle vara mer bekvÀmt och vackert.
Det grundlĂ€ggande i dashboards Ă€r detsamma. Detta Ă€r systemmĂ„tt för klustret: CPU, minne, disk, nĂ€tverk. Ăvrigt - Antal samtidiga förfrĂ„gningar, Antal samtidiga sammanslagningar, Antal förfrĂ„gningar per sekund, Maximalt antal segment för MergeTree-tabellpartitioner, Replikeringsfördröjning, Replikeringsköns storlek, Antal rader som infogas per sekund, Antal block som infogas per sekund. Allt detta kommer inte frĂ„n loggar, utan frĂ„n mĂ€tvĂ€rden.
Vladimir Kolobajev: Alexey, jag skulle vilja rÀtta till en liten sak. DÀr finns 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 ett bord med stockar, det Àr likadant 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 vore fantastiskt att ha en sÄdan hÀr instrumentpanel.
Jag cyklade den 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 följer med ClickHouse nu stöder Altinity. Och jag vill bara ge en vektor för var man ska grĂ€va och vem man ska pusha. Du kan frĂ„ga dem, för det Ă€r Yandex som gör ClickHouse, och inte historien kring 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 att ladda upp en instrumentpanel till Grafanas webbplats behöver du i princip bara registrera dig och ladda upp den â det finns inga speciella problem.
Alexey Milovidov: Under det senaste Äret har ClickHouse lagt till mÄnga funktioner för frÄgeprofilering. Det finns mÀtvÀrden för varje begÀran om resursanvÀndning. Och alldeles nyligen lades en Ànnu lÀgre nivÄ av frÄgeprofilerare till för att se var en frÄga tillbringar varje millisekund. Men för att anvÀnda den hÀr funktionen mÄste jag öppna konsolklienten och skriva en frÄga, vilket jag alltid glömmer. Jag sparade den nÄgonstans och jag glömmer hela tiden var exakt.
Jag önskar att det fanns ett verktyg som bara sa: "HĂ€r Ă€r dina tunga frĂ„gor, grupperade efter frĂ„geklass". Jag tryckte pĂ„ en och de sa att den var tung pĂ„ grund av det. Det finns ingen sĂ„dan lösning för nĂ€rvarande. Och det Ă€r egentligen ganska konstigt att nĂ€r folk frĂ„gar mig: âSĂ€g mig, finns det nĂ„gra fĂ€rdiga dashboards för Grafana?â, sĂ„ sĂ€ger jag: âGĂ„ till Grafanas webbplats, dĂ€r finns en âDashboardsâ-community, och det finns en dashboard frĂ„n Dimka, det finns en dashboard frĂ„n Kostyan. Jag vet inte vad det Ă€r, jag har inte anvĂ€nt den sjĂ€lv.â
Hur kan man pÄverka sammanslagningar sÄ att servern inte hamnar i OOM?
Jag har en tabell, tabellen har bara en partition, det Àr ReplacementMergeTree. Jag har skrivit in data i den i fyra Är. Jag var tvungen att göra en Àndring i den och radera lite data.
Jag gjorde detta, och under bearbetningen av denna begÀran Äts allt minne pÄ alla servrar i klustret upp, och alla servrar i klustret gick in i OOM. Sedan reste de sig alla upp tillsammans, började sammanfoga samma operation, det hÀr datablocket, och hamnade i OOM igen. Sedan reste de sig upp igen och föll ner igen. Och det hÀr tog inte slut.
Sedan visade det sig att det hĂ€r faktiskt var en bugg, vilket killarna fixade. Det hĂ€r Ă€r verkligen toppen, tack sĂ„ mycket. Men sedimentet fanns kvar. Och nu, nĂ€r jag funderar pĂ„ att göra en viss sammanslagning i tabellen, har jag en frĂ„ga â varför kan jag inte bara ta och pĂ„ nĂ„got sĂ€tt pĂ„verka dessa sammanslagningar? BegrĂ€nsa dem till exempel med mĂ€ngden RAM-minne som krĂ€vs, eller i princip med antalet som kommer att bearbeta just den hĂ€r tabellen.
Jag har en tabell som heter "MÀtvÀrden", var vÀnlig bearbeta den Ät mig i tvÄ strömmar. Du behöver inte multiplicera tio eller fem sammanslagningar parallellt, gör det i tvÄ. Jag tror att jag har tillrÀckligt med minne för tvÄ, men jag kanske inte har tillrÀckligt för att bearbeta tio. Varför finns rÀdslan kvar? Eftersom tabellen vÀxer, och jag en dag kommer att stöta pÄ en situation som i princip inte beror pÄ en bugg, utan pÄ att informationen kommer att Àndras i sÄ stora mÀngder att jag helt enkelt inte kommer att ha tillrÀckligt med minne pÄ servern. Och sedan kraschar servern i OOM under sammanslagningen. Dessutom kan jag avbryta mutationen, men det blir ingen sammanslagning.
Du vet, nÀr du sammanfogar kommer servern inte att hamna i OOM, eftersom mÀngden RAM vid sammanfogning bara anvÀnds för ett litet dataintervall. SÄ allt kommer att ordna sig oavsett datamÀngd.
Vladimir Kolobajev: Bra. Grejen Àr den att efter att de fixat buggen laddade jag ner en ny version och gjorde en liknande operation pÄ en annan tabell, en mindre, dÀr det finns mÄnga partitioner. Och under sammanslagningen förbrukades cirka 100 GB RAM pÄ servern. Jag hade 150 upptagna, 100 uppÀtna, och ett fönster pÄ 50 GB Äterstod, sÄ jag hamnade inte i OOM.
Vad skyddar mig för nÀrvarande frÄn att gÄ in i OOM om det verkligen förbrukar 100 GB RAM? Vad ska man göra i en situation om RAM-minnet pÄ sammanslagningarna plötsligt tar slut?
Alexey Milovidov: Det finns ett problem att RAM-förbrukningen specifikt för sammanslagningar inte Àr begrÀnsad. Och det andra problemet Àr att om nÄgon sammanslagning har tilldelats, mÄste den utföras, eftersom den skrivs till replikeringsloggen. Replikeringsloggen Àr de ÄtgÀrder som krÀvs för att fÄ repliken att fungera korrekt. Om du inte gör manuella manipulationer som ÄterstÀller den hÀr replikeringsloggen, 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 starta om, nÄ ett visst tröskelvÀrde, utlösa ett undantag och sedan börja om igen - inget gott kommer att komma av det. Men i princip vore det bra att införa denna begrÀnsning.
Hur kommer utvecklingen av Golang-drivrutinen för ClickHouse att ske?
Golang-drivrutinen skriven av Kirill Shvakov stöds nu officiellt av ClickHouse-teamet. Han , han Àr stor och verklig nu.
En liten anmÀrkning. Det finns ett underbart och Àlskat arkiv av normala former av oÀndlig ordning - Vertica. De har ocksÄ sin egen officiella Python-drivrutin, som stöds av Vertica-utvecklare. Och flera gÄnger hÀnde det att versionerna av lagring och versionerna av drivrutinen skilde sig ganska kraftigt Ät, och drivrutinen slutade vid nÄgon tidpunkt fungera. Och den andra punkten. Det verkar som att stöd för den hÀr officiella drivrutinen tillhandahÄlls av "nippel"-systemet - du skriver ett Àrende till dem, och det hÀnger sig för alltid.
Jag har tvÄ frÄgor. Kirills Golang-drivrutin Àr nu nÀstan standardsÀttet att kommunicera frÄn Golang till ClickHouse. Kanske kommunicerar nÄgon fortfarande via http-grÀnssnittet för att de gillar det sÄ. Hur kommer denna drivkraft att utvecklas? Kommer det att synkroniseras med eventuella Àndringar som inte fungerar i sjÀlva arkivet? Och vilken Àr ordningen för behandling av frÄgan?
Kirill Shvakov: Det första Àr hur allting Àr organiserat byrÄkratiskt. Denna punkt diskuterades inte, sÄ jag har inget att svara pÄ.
För att besvara frÄgan om problemet behöver vi lite historia om föraren. Jag jobbade för ett företag som hade mycket data. Det var en reklamsnurra med ett enormt antal hÀndelser som behövde lagras nÄgonstans. Och vid nÄgon tidpunkt dök ClickHouse upp. Vi fyllde pÄ med data, och till en början var allt bra, men sedan kraschade ClickHouse. Vid den tidpunkten bestÀmde vi oss för att vi inte behövde det.
Ett Är senare Ätergick vi till idén att anvÀnda ClickHouse, och vi behövde pÄ nÄgot sÀtt skriva data dÀr. Introduktionen var denna: hÄrdvaran Àr mycket svag, det finns fÄ resurser. Men vi har alltid arbetat sÄ hÀr, sÄ vi tittade pÄ det inbyggda protokollet.
Eftersom vi arbetade med Go var det tydligt att vi behövde en drivrutin för Go. Jag gjorde det nĂ€stan pĂ„ heltid â det var min arbetsuppgift. Vi kom till en viss punkt, och i princip antog ingen att nĂ„gon annan Ă€n vi skulle anvĂ€nda det. Sedan kom CloudFlare med exakt samma problem, och under en tid arbetade vi med dem vĂ€ldigt smidigt, eftersom de hade samma uppgifter. Dessutom gjorde vi detta bĂ„de i sjĂ€lva ClickHouse och i drivrutinen.
Vid nÄgon tidpunkt slutade jag helt enkelt med det, eftersom min aktivitet vad gÀller ClickHouse och arbete förÀndrades lite. Det Àr dÀrför Àrenden inte Àr avslutade. Med jÀmna mellanrum binder sig personer som sjÀlva behöver nÄgot till arkivet. Sedan tittar jag pÄ pull request och ibland redigerar jag till och med nÄgot sjÀlv, men det hÀnder sÀllan.
Jag vill ÄtergÄ till föraren. 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 omforma drivrutinen sÄ att den fungerar bra. Om detta hÀnder kommer version 2 ÀndÄ att vara inkompatibel pÄ grund av de ackumulerade lösningarna.
Jag vet inte hur jag ska organisera den hÀr saken. SjÀlv har jag inte mycket tid. Om nÄgra personer avslutar föraren kan jag hjÀlpa dem och berÀtta vad de ska göra. Men Yandex aktiva deltagande i projektets utveckling har Ànnu inte diskuterats.
Alexey Milovidov: Det finns faktiskt ingen byrÄkrati kring dessa förare Ànnu. Det enda Àr att de skickas till den officiella organisationen, det vill sÀga att den hÀr drivrutinen Àr erkÀnd som den officiella standardlösningen för Go. Det finns nÄgra andra förare, 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 för just den hÀr föraren, utan för utvecklingen av alla förare i samhÀllet, eller om vi kan hitta nÄgon utifrÄn.
Extern ordbok startas inte efter omstart med lazy_load-instÀllningen aktiverad. Vad ska man göra?
Vi har instĂ€llningen lazy_load aktiverad, och efter att servern har startats om startar inte ordboken upp av sig sjĂ€lv. Den aktiveras först efter att anvĂ€ndaren har öppnat den hĂ€r ordboken. Och första gĂ„ngen man försöker fĂ„r man ett felmeddelande. Ăr det möjligt att pĂ„ nĂ„got sĂ€tt automatiskt ladda ner ordböcker med ClickHouse, eller mĂ„ste man alltid sjĂ€lv övervaka att de Ă€r beredskapsklara sĂ„ att anvĂ€ndarna inte fĂ„r felmeddelanden?
Vi kanske har en gammal version av ClickHouse, sÄ ordboken laddades inte automatiskt. Skulle detta vara möjligt?
För det första kan ordböcker tvingas laddas med hjÀlp av en frÄga systemomladdningsordböcker. För det andra, angÄende felet - om ordboken redan Àr laddad, kommer frÄgorna att fungera pÄ den data som laddades. Om ordboken inte har laddats Ànnu, kommer den att laddas direkt under begÀran.
För tunga ordböcker Àr detta inte sÀrskilt bekvÀmt. Till exempel behöver du hÀmta en miljon rader frÄn MySQL. NÄgon gör en enkel select, men denna select vÀntar i samma miljon rader. Det finns tvÄ lösningar hÀr. StÀng först av lazy_load. För det andra, nÀr servern Àr uppe, innan du belastar den, gör det systemomladdningsordlista eller helt enkelt köra en frÄga som anvÀnder ordboken. Sedan laddas ordboken. Du mÄste sjÀlv kontrollera tillgÀngligheten för ordböcker med instÀllningen lazy_load aktiverad, eftersom ClickHouse inte automatiskt öppnar dem.
Svaret pÄ den sista frÄgan Àr antingen att versionen Àr gammal, eller sÄ behöver den felsökas.
Vad ska man göra om systemets omladdning av ordböcker inte laddar nÄgon av de mÄnga ordböckerna om minst en av dem kraschar med ett fel?
Det finns en annan frĂ„ga om systeminlĂ€sningsordböcker. Vi har tvĂ„ ordböcker â den ena laddas inte, den andra laddas. I det hĂ€r fallet laddar inte System Reload Dictionary nĂ„gon ordbok, och du mĂ„ste selektivt ladda en specifik ordbok med dess namn med hjĂ€lp av System Reload Dictionary. Ăr detta Ă€ven relaterat till ClickHouse-versionen?
Jag vill göra dig lycklig. Detta beteende förÀndrades. SÄ om du uppdaterar ClickHouse kommer det ocksÄ att Àndras. Om du inte Àr nöjd med det nuvarande beteendet systemomladdningsordböcker, uppdatera dig sjÀlv, och lÄt oss hoppas att det förÀndras till det bÀttre.
Finns det ett sÀtt att konfigurera detaljerna i ClickHouse-konfigurationen, men inte visa dem nÀr fel uppstÄr?
NÀsta frÄga handlar om fel relaterade till ordboken, nÀmligen detaljerna. Vi har registrerat anslutningsuppgifterna i ClickHouse-konfigurationen till ordboken, och om det uppstÄr ett fel fÄr vi dessa uppgifter och lösenordet som svar.
Vi löste det hÀr felet genom att flytta informationen till ODBC-drivrutinskonfigurationen. Finns det ett sÀtt att konfigurera detaljerna i ClickHouse-konfigurationen, men att inte visa dessa detaljer nÀr fel uppstÄr?
HĂ€r Ă€r lösningen egentligen att ange dessa inloggningsuppgifter i odbc.ini, och i ClickHouse sjĂ€lva ange endast ODBC-datakĂ€llans namn. För andra ordbokskĂ€llor kommer detta inte att hĂ€nda - varken för ordboken med MySQL eller för de andra, bör du inte se lösenordet nĂ€r du rapporterar ett fel. Jag ska ocksĂ„ titta pĂ„ ODBC â om det finns nĂ„got sĂ„dant behöver det bara tas bort.
Bonus: Zoom-bakgrunder frÄn sammankomsten
Genom att klicka pÄ bilden öppnas bonusbakgrunder frÄn trÀffarna för de mest ihÀrdiga lÀsarna. Vi slÀcker brÀnder tillsammans med Avitos teknikmaskotar, samrÄder med kollegor frÄn systemadministratörens rum eller den gamla datorklubben och hÄller ett dagligt möte under bron mot en bakgrund av graffiti.
KĂ€lla: will.com
