ClickHouse'i efektiivne kasutamine. Alexey Milovidov (Yandex)

Kuna ClickHouse on spetsialiseeritud süsteem, on selle kasutamisel oluline arvesse võtta selle arhitektuuri omadusi. Selles ettekandes räägib Aleksei näidetest tüüpilistest vigadest ClickHouse'i kasutamisel, mis võivad viia ebaefektiivse tööni. Praktikast toome näiteid, kuidas andmete töötlemise erineva skeemi valik võib tootlikkust dramaatiliselt muuta.

Tere kõigile! Minu nimi on Aleksei, ma teen ClickHouse'i.

Esiteks, kiirustan teid rõõmustama, et ma ei hakka täna rääkima, mis on ClickHouse. Ausalt öeldes on see mul juba tüütuks muutunud. Ma räägin sellega iga kord. Ja ilmselt teavad kõik juba.

Kohapeal räägin hoopis sellest, millised on võimalikud takistused, st kuidas ClickHouse'i valesti kasutada. Tegelikult ei ole mõtet karta, kuna me arendame ClickHouse'i süsteemina, mis on lihtne, mugav ja töötab kohe. Paigaldad ja kõik, mingeid probleeme ei ole.

Kuid siiski tuleb arvestada, et see süsteem on spetsialiseeritud ja võib kerge vaevaga sattuda ebatavalisse kasutusskeemi, mis viib selle süsteemi mugavustsoonist välja.

Nii et, millised on takistused? Peamiselt räägin ma ilmselgetest asjadest. Kõigile on kõik ilmselge, kõik mõistavad ja saavad rõõmustada, et nad on nii targad, ja kes ei mõista, need saavad midagi uut teada.

Esimene, kõige lihtsam näide, mida kahjuks sageli kohtab, on suur arv sisendeid väikeste partiitide kaupa, st suur arv väikseid sisendeid.

Kui vaadata, kuidas ClickHouse sisestusi täidab, saate ühe päringu kaudu saata kas või terabaidi andmevoo. See ei ole probleem.

Vaadakem, milline oleks tüüpiline tootlikkus. Näiteks on meil tabel Yandex.Metrikast. Küllused. 105 mingisugust veergu. 700 baiti uncompressed. Ja sisestame õigesti partiitide kaupa miljon rida.

Sisestame tabelisse MergeTree, tulemuseks on 500 000 rida sekundis. Suurepärane. Replitseeritud tabelisse – veidi vähem, umbes 400 000 rida sekundis.

Ja kui sisse lülitada häältega sisestamine, siis on tulemuseks veidi vähem, kuid siiski korralik tootlikkus, 250 000 rida sekundis. Häältega sisestamine on ClickHouse's dokumenteerimata funktsionaalsus.

* 2020. aasta seisuga, on juba dokumenteeritud.

Mis juhtub, kui teeme halvasti? Me sisestame rida kaupa MergeTree tabelisse ja saame 59 rida sekundis. See on 10 000 korda aeglasem. ReplicatedMergeTree puhul on see 6 rida sekundis. Ja kui veel kvorum sisse lülitada, siis saame 2 rida sekundis. Minu arust on see täielik jama. Kuidas saab nii aeglaselt töötada? Mul on isegi T-särgil kirjutatud, et ClickHouse ei tohiks aeglustada. Kuid vahel juhtub ikkagi.

Tegelikult on see meie puudus. Me oleksime täiesti võinud teha nii, et kõik toimib normaalselt, aga me ei teinud. Ja me ei teinud seda, sest meie stsenaariumis ei olnud see vajalik. Meil olid nagunii partiid. Lihtsalt me saime sisendi partiidena ning sellega ei olnud probleeme. Sisestame ja kõik töötab normaalselt. Kuid muidugi on võimalikud erinevad stsenaariumid. Näiteks, kui teil on palju servereid, kus andmed genereeritakse. Ja nad sisestavad andmeid mitte nii tihti, kuid saadud on ikkagi sagedased sisestused. Ja seda tuleks kuidagi vältida.

Tehnilisest vaatepunktist on asi selles, et kui teete ClickHouse’is sisestamise, siis andmed ei satu ühtegi memtable’i. Meil ei ole isegi tõelist log structure MergeTree’d, vaid lihtsalt MergeTree, kuna puudub nii log kui memTable. Me lihtsalt salvestame andmed otse failisüsteemi, juba veergude kaupa jaotatuna. Ja kui teil on 100 veergu, siis tuleb salvestada rohkem kui 200 faili eraldi kausta. Kõik see on üsna mahukas.

Ja tekib küsimus: „Kuidas teha õigesti?“, kui on selline olukord, kus on ikkagi vaja kuidagi andmeid ClickHouse’i salvestada.

Meetod 1. See on kõige lihtsam meetod. Kasutage mõnda hajutatud järjekorda. Näiteks, Kafka. Lihtsalt võtate andmed Kafkast välja, batšite kord sekundis. Ja kõik läheb normaalselt, te salvestate, kõik töötab hästi.

Puuduseks on see, et Kafka on veel üks mahukas hajutatud süsteem. Ma saan aru, kui teie ettevõttes juba on Kafka. See on hea, see on mugav. Kuid kui seda ei ole, siis mõelge kolm korda, enne kui tõmbate endale projekti veel ühe hajutatud süsteemi. Seega tasub kaaluda alternatiive.

Meetod 2. Siin on selline vanakooli alternatiiv, mis on samas väga lihtne. Teil on server, mis genereerib teie logid. See lihtsalt salvestab teie logid faili. Ja iga sekundi järel, näiteks, nimetame selle faili ümber, loome uue. Ja eraldi skript, kas cronilt või mõni demon, võtab kõige vanema faili ja salvestab selle ClickHouse'i. Kui logid salvestada iga sekundi tagant, siis kõik töötab suurepäraselt.

Aga selle meetodi puudus on see, et kui teie server, kus logid genereeritakse, mingil põhjusel kaob, kaovad ka andmed.

Meetod 3. On veel üks huvitav meetod, mis ei vaja üldse ajutisi faile. Näiteks, teil võib olla mingi reklaamikäivitaja või mõni muu huvitav demon, mis genereerib andmeid. Ja te saate koguda hunniku andmeid otse mällu, puhvri sisse. Ja kui mõõdukas aeg on möödunud, eraldate selle puhvri, loote uue ja eraldi lõimes sisestate ClickHouse'i juba kogunenud andmed.

Teiselt poolt kaovad andmed samuti kill -9 korral. Kui teie server kukub, kaotate need andmed. Ja veel üheks probleemiks on see, et kui te ei saa andmeid andmebaasi salvestada, hakkavad need andmed kogunema mällu. Ja kas mälu saab otsa või kaotate lihtsalt andmed.

Meetod 4. Veel üks huvitav meetod. Teil on mingisugune serveriprotsess. Ja see võib saata andmeid ClickHouse'i kohe, kuid teha seda ühes ühenduses. Näiteks saata HTTP-päring transfer-encoding: chunked koos insert’iga. Ja genereerida chunk'e mitte liiga harva, saab saata iga rida, kuigi see lisab ülekoormust nende andmete raamistamisele.

Aga ikkagi, sellisel juhul saadetakse andmed ClickHouse'i kohe. Ja ClickHouse ise hakkab neid puhvritama.

Aga probleemid ilmnevad ka. Nüüd kaotate andmed, sealhulgas siis, kui teie protsess tapetakse ja kui ClickHouse'i protsess tapetakse, kuna see on lõpetamata insert. Ja ClickHouse'is on insertid aatomilised kuni teatud määratud ridade arvuni. Üldiselt on see huvitav meetod. Seda saab samuti kasutada.

Meetod 5. Siin on veel üks huvitav meetod. See on mingi community arendatud server, mis on mõeldud andmete töötlemiseks. Ma pole seda ise vaadanud, seega ei saa ma midagi garantii alla võtta. Siiski, isegi ClickHouse ei paku mingeid tagatisi. See on samuti avatud lähtekoodiga, kuid teisest küljest olete võib-olla harjunud teatud kvaliteedistandardiga, mida me püüame tagada. Selle tööriista osas - ma ei tea, minge GitHubi, vaadake koodi. Võib-olla on seal midagi normaalset kirjutatud.

* seisuga 2020. aasta, tuleks ka kaaluda KittenHouse.

Meetod 6. Veel üks meetod on Buffer tabelite kasutamine. Selle meetodi eeliseks on see, et selle kasutamine on väga lihtne. Loote Buffer tabeli ja lisate sinna andmed.

Aga puuduseks on see, et probleem ei lahene täielikult. Kui MergeTree tüüpi sisestamisel peate andmeid rühmitama ühe partii kohta sekundis, siis Buffer tabelisse sisestamisel peate rühmitama vähemalt paar tuhat sekundis. Kui on rohkem kui 10 000 sekundis, siis läheb ikkagi halvasti. Ja kui sisestada partii kaupa, siis nägite, et võib saada sadu tuhandeid ridu sekundis. Ja see juba raskete andmete puhul.

Ja ka Buffer tabelitel ei ole logi. Kui teie serveriga juhtub midagi, siis andmed kaotatakse.

Ja boonuseks, hiljuti ilmus ClickHouse'is võimalus andmeid Kafka'ist saada. On olemas tabelimootor - Kafka. Lihtsalt loote selle. Ja sellele saab kinnitada materialiseeritud vaateid. Sel juhul toob see ise andmed Kafka'st ja sisestab need teie soovitud tabelitesse.

Ja eriti rõõmustav on selles võimaluses see, et seda ei teinud meie. See on community funktsioon. Ja kui ma räägin 'community funktsioonist', siis ma ei räägi mingisuguse üleolekuga. Koodi oleme lugenud, ülevaate teinud, peaks tööle hakkama.

* seisuga 2020. aasta, ilmus sarnane tugi RabbitMQ.

Mis veel võib olla ebamugav või üllatav andmete sisestamisel? Kui teete insert values päringu ja values'is kirjutate mõningaid arvutuse väljendeid. Näiteks now() - see on samuti arvutuse väljend. Ja sel juhul peab ClickHouse igal real käivitama nende väljendite tõlgendi, ja jõudlus langeb järsult. Parem seda vältida.

* hetkel on probleem täielikult lahendatud, väärtuste mõistuslike väljendite kasutamisel ei ole enam jõudlusprobleeme.

Teine näide, kui võivad esineda mõned probleemid, kui ühes partiiandmete seas kuuluvad andmed mitmesse partitsiooni. ClickHouse'is on partitsioonid vaikimisi kuude kaupa. Ja kui sisestate partii miljonist reast, kus on andmed mitme aasta jooksul, siis on teil seal mitu kümnendat partitsiooni. Ja see on ekvivalentne sellega, et partiid on mitmekümne võrra väiksemad, kuna need jagunevad kõigepealt partitsioonide kaupa.

* hiljuti lisati ClickHouse'is eksperimentaalses režiimis toimetamise toetuseks kompaktne formaadi tükid ja tükid mälus koos eelneva logimisfailiga, mis lahendab probleemi peaaegu täielikult.

Nüüd vaatame teist tüüpi probleemi – andmete tüpiseerimine.

Andmete tüpiseerimine võib olla range või struktuurne. Struktuurne on see, kui te lihtsalt võtate ja kuulutate, et kõik teie väljad on tüüpi string. See on vale. Nii ei tohi teha.

Laske meil arutada, kuidas õigesti käituda olukordades, kus soovite öelda, et mõni väli on meil string ja laske ClickHouse'il ise aru saada, kuigi samas tasuks siiski mingit pingutust teha.

Näiteks meil on IP-aadress. Ühes olukorras salvestasime selle stringina. Näiteks 192.168.1.1. Teises olukorras on see arv tüübiga UInt32*. 32 bitti on piisav IPv4 aadresside jaoks.

Esiteks, kummalisel kombel kokkusurutud andmed on enam-vähem sama ulatusega. Seal on loomulikult erinevusi, kuid need ei ole nii suured. Seega ei ole diskivõimaluste osas erilisi probleeme.

Kuid on tõsine erinevus protsessori aja ja päringu täitmise aja osas.

Lugemisel unikaalsete IP-aadresside arvu, kui need on salvestatud numbritena. Tulemus on 137 miljonit rida sekundis. Kui sama toimub stringide kujul, siis 37 miljonit rida sekundis. Ma ei tea, miks selline kokkulangevus tekkis. Mina ise sooritasin neid päringuid. Kuid siiski on aeg umbes 4 korda aeglasem.

Ja kui arvutada vahe ketta ruumi osas, siis erinevus on samuti olemas. Ja see erinevus on umbes neljandik, sest unikaalseid IP-aadresse on piisavalt palju. Kui siin oleksid stringid väikese erinevate väärtuste hulgaga, siis need oleksid rahulikult sõnastiku järgi peaaegu sama suurusega kokku surutud.

Ja nelja korda erinev aeg teel ei ole tühjaks jäänud. Võib-olla teid see ei häiri, kuid kui näen selliseid erinevusi, tunnen end kurvana.

Vaadakem erinevaid juhtumeid.

1. Üks juhtum, kui teil on erinevaid unikaalseid väärtusi veidi. Sellisel juhul kasutame lihtsat praktikat, mida te ilmselt tunnete ja saate kasutada mis tahes andmebaasides. See on mõistlik mitte ainult ClickHouse'i jaoks. Lihtsalt salvestage andmebaasi numbrilised id-d. Ja konverteerida stringideks ja tagasi saab juba teie rakenduse poolel.

Näiteks, teil on regiooni andmed. Ja te üritate seda hoida stringina. Ja seal on näiteks: Moskva ja MO. Ja kui ma näen, et seal on kirjutatud "Moskva", siis see on veel okei, aga kui ka MO, siis muutub see kuidagi ikka kurvaks. See on ju palju baite.

Selle asemel salvestame lihtsalt numbri Ulnt32 ja 250. Meil on Yandexis 250, aga teil võib see olla teisiti. Igaks juhuks ütlen, et ClickHouse'il on sisseehitatud võimalus geobaasiga töötamiseks. Te salvestate lihtsalt regioonide katalooge, sealhulgas hierarhilise, st seal on nii Moskva kui mee, ning kõik, mis teile vajalik. Ja saate konverteerida päringu tasemel.

Teine variant on enam-vähem sama, kuid juba ClickHouse'i sees toe abil. See on Enum andmetüüp. Te lihtsalt määrate Enum'i sees kõik vajalikud väärtused. Näiteks seadme tüüp ja seal kirjutate: desktop, mobiilne, tahvelarvuti, televiisor. Kokku 4 varianti.

Puuduseks on see, et peate perioodiliselt muutma. Lisame vaid ühe variandi. Teeme alter table. Tegelikult on alter table ClickHouse'is tasuta. Eriti on see tasuta Enum'i osas, kuna andmed kettal ei muutu. Kuid sellegipoolest haarab alter tabelist lukku ja peab ootama, kuni kõik select'id lõpule viiakse. Ja alles pärast seda viidatakse alter'ile, st mugavus on siiski kohal.

* Uutes ClickHouse'i versioonides on ALTER täielikult blokeerimata.

Veel üks variant, mis on ClickHouse'ile piisavalt ainulaadne, on väliste sõnastike ühendamine. Te saate kirjutada ClickHouse'isse numbreid ja hoida oma katalooge mis tahes mugavas süsteemis. Näiteks võib kasutada: MySQL, Mongo, Postgres. Võite isegi oma mikroteenuse luua, mis edastab neid andmeid http kaudu. Ja ClickHouse'i tasemel kirjutate funktsiooni, mis muudab need andmed numbritest stringideks.

See on spetsialiseeritud, kuid väga tõhus viis välise tabeli ühendamiseks. Ja olemas on kaks varianti. Ühes variandis on need andmed täielikult vahemällu salvestatud, täielikult olemas mälus ja neid uuendatakse teatud ajavahemike järel. Teises variandis, kui andmed ei mahu mälusse, saab neid osaliselt vahemällu salvestada.

Siin on näide. On Yandex.Direct. Seal on reklaamikampaania ja bännerid. Reklaamikampaaniaid on ilmselt umbes kümme miljonit. Ja need mahutavad enamasti mälu. Ja bännerid – miljardeid, need ei mahu mälusse. Ja me kasutame MySQL-i vahemällu salvestatud sõnastikku.

Ainus probleem on see, et vahemällu salvestatud sõnastik töötab normaalselt, kui hit rate on lähedal 100%-le. Kui see on madalam, siis tuleb andmete töötlemisel iga andmepaki jaoks hankida puuduolevad võtmed ja tõmmata andmed MySQL-ist. ClickHouse'i osas võin veel kindel olla, et see ei aeglustu, teiste süsteemide puhul ei hakka ma rääkima.

Ja bonusena on see, et sõnastikud on väga lihtne viis andmete uuendamiseks ClickHouse'is tagantjärele. T. e. kui teil oli reklaamikampaaniate aruanne ja kasutaja lihtsalt muudab reklaamikampaaniat, siis kõikides vanades andmetes ja kõigis aruannetes muudetakse need andmed samuti. Kui kirjutada read otse tabelisse, siis nende uuendamine ei oleks võimalik.

Veel üks viis, kui te ei tea, kust oma ridade identifikaatoreid võtta. Võite lihtsalt need häkkida. Ja kõige lihtsam variant on võtta 64-bitine häkk.

Ainus probleem on see, et kui häkk on 64-bitine, siis on teil peaaegu kindlalt kollisioonid. Sest kui seal on miljard rida, siis tõenäosus hakkab tõeliselt tuntav olema.

Ja ei oleks väga hea hämada reklaamikampaaniate nimesid. Kui erinevate ettevõtete reklaamikampaaniad segamini lähevad, siis tekib midagi arusaamatut.

Ja on lihtne trikk. Tõsi, tõsiste andmete jaoks see eriti ei sobi, aga kui miski pole eriti tõsine, siis lisage lihtsalt sõnastiku võtmesse ka kliendi identifikaator. Ja siis tekivad kolliisiid, kuid ainult ühe kliendi piires. Sellist meetodit kasutame me Yandex.Metrikas lingikaardi jaoks. Meil on seal url'e, me salvestame hash'e. Ja me teame, et kolliisiid on olemas. Kuid kui leht kuvatakse, siis on tõenäosus, et ühel lehel ühel kasutajal on mingid url'id kokku jooksnud ja et seda märgatakse, hästi väike, sellega võib üle vaadata.

Boonusena – paljude toimingute jaoks piisab vaid hash'idest ja stringe ei pea kusagil salvestama.

Teine näide, kui stringid on lühikesed, näiteks veebisaitide domeenid. Neid saab salvestada sellisena. Või näiteks brauseri keel ru – 2 baiti. Mulle muidugi väga kahju nendest baitidest, aga ärge muretsege, 2 bitti pole kahju. Palun salvestage niisama, ärge muretsege.

Teine juhtum on see, kui stringe on vastupidiselt väga palju ja need on väga unikaalsed, lisaks on potentsiaalne arv piiramatu. Tüüpiline näide – see on otsingufraasid või url'id. Otsingufraasid, sealhulgas trükivigade tõttu. Vaadake, kui palju unikaalseid otsingufraase ööpäevas. Ilmneb, et need moodustavad peaaegu poole kõigist sündmustest. Ja sel juhul võiksite mõelda, et peaksite andmeid normaliseerima, identifikaatoreid arvestama, eraldi tabelisse koguma. Kuid nii teha ei ole vaja. Lihtsalt salvestage need stringid sellisena.

Parem on mitte midagi välja mõelda, sest kui salvestada eraldi, siis tuleb teha ühendus. Ja see ühendus – on parimal juhul juhuslik juurdepääs mälule, kui see maht mahub veel mällu. Kui ei mahutu, siis on probleemid.

Ja kui andmed on salvestatud in place, siis loetakse need lihtsalt vajalikus järjekorras failisüsteemist välja ja kõik on normaalselt.

Kui teil on url'e või mõni muu keeruline pikk string, siis tasub mõelda, et võiks arvutada mingisuguse kokkuvõtte ette ja salvestada eraldi veergu.

Url'ide puhul näiteks võite salvestada domeeni eraldi. Ja kui teil on tõeliselt vaja domeeni, siis kasutage lihtsalt seda veergu, samas kui url'id jäävad puutumatuks ja te ei puutu nendega isegi kokku.

Vaadake, milline on erinevus. ClickHouse'is on spetsialiseeritud funktsioon, mis arvutab domeeni. See on väga kiire, me oleme seda optimeerinud. Ja ausalt öeldes, see ei vasta isegi RFC-le, kuid vaatamata sellele loendab see kõike, mis meile vajalik on.

Ja ühes olukorras saame lihtsalt URL-id välja võtta ja domeeni arvutada. Tulemuseks on 166 millisekundit. Kui aga võtta valmislahendatud domeen, siis on tulemuseks vaid 67 millisekundit, st peaaegu kolm korda kiiremini. Kiirus ei tulene sellest, et peame tegema mingeid arvutusi, vaid sellest, et loeme vähem andmeid.

Miks mõne päringu kiirus, mis on aeglasem, on suurem gigabaitide sekundis. Sest see loeb rohkem gigabaiti. Need on täiesti tarbetud andmed. Päring töötab nagu oleks kiire, kuid tegelikult kestab see kauem.

Kui vaadata andmemahtu kettal, siis selgub, et URL on 126 megabaiti, samas kui domeen on vaid 5 megabaiti. See on 25 korda vähem. Sellegipoolest kestab päringu täitmine vaid 4 korda kiiremini. Kuid see on tingitud kuumadest andmetest. Kui andmed oleks külmad, siis oleks see tõenäoliselt 25 korda kiirem ketta sisendi-väljundi tõttu.

Muide, kui hinnata, kui palju domeen on väiksem kui URL, siis tuleb arvestada, et see on kuskil 4 korda. Kuid kummalisel kombel võtavad andmed kettal 25 korda vähem ruumi. Miks? See on tingitud survest. N nii URL kui ka domeen pressitakse kokku. Kuid tihti sisaldab URL hulgaliselt prügi.

Ja muidugi on oluline kasutada õigeid andmetüüpe, mis on spetsiaalselt mõeldud vajalike väärtuste jaoks või mis sobivad. Kui te kasutate IPv4, siis hoidke UInt32*. Kui IPv6, siis FixedString(16), sest IPv6 aadress on 128 bitti, st hoidke seda otse binaarformaadis.

Kuidas aga käituda, kui teil on mõnikord IPv4 aadresse ja mõnikord IPv6? Jah, mõlemat saab hoida. Üks veerg IPv4 jaoks, teine IPv6 jaoks. Muidugi on võimalus IPv4 kuvada IPv6-s. See töötaks ka, kuid kui teil on päringutes sageli vaja just IPv4 aadressi, siis oleks mõistlik see eraldi veergu panna.

* nüüd on ClickHouse'is eraldi andmetüübid IPv4, IPv6, mis talletavad andmeid sama efektiivselt nagu numbrid, kuid esitavad neid sama mugavalt nagu stringid.

Oluline on märkida, et andmed tuleks eelnevalt ette valmistada. Näiteks, kui teil on mõned toorlogid. Ja võib-olla ei tasu neid kohe ClickHouse'i sisestada, kuigi on väga ahvatlev mitte midagi teha ja kõik toimib. Kuid tasub siiski teha kõik võimalikud arvutused.

Näiteks brauserid. Ühes teises osakonnas, kuhu ma ei taha näpuga näidata, hoitakse brauseri versiooni niimoodi, s.t. stringina: 12.3. Ja siis, et aruannet teha, võtavad nad selle stringi, jagavad selle massiiviga ja seejärel massiivi esimese elemendiga. Loomulikult kõik aeglustub. Küsisin, miks nad nii teevad. Nad vastasid, et ei armasta enneaegset optimeerimist. Mina aga ei armasta enneaegset pessimistlikkust.

Seega oleks sel juhul õigustatud jagada need 4 veergu. Siin ärge kartke, sest see on ClickHouse. ClickHouse on veergude andmebaas. Ja mida rohkem on hoolikalt valmistatud väikseid veerge, seda paremad. Kui teil on 5 BrowserVersioni, tehke 5 veergu. See on normaalne.

Nüüd vaatame, mida teha, kui teil on palju väga pikki stringe, väga pikki massiive. Neid ei pea ClickHouse'is üldse hoidma. Selle asemel saate ClickHouse'is salvestada ainult mingi identifikaatori. Ja need pikad stringid pange mõnda teise süsteemi.

Näiteks on ühes meie analüüsiteenustes mõned sündmuste parameetrid. Ja kui sündmustele tuleb palju parameetreid, salvestame lihtsalt esimesed 512. Sest 512 – pole kahju.

Ja kui te ei saa kindlaks teha oma andmetüüpide, siis saate ka andmed ClickHouse'i salvestada, kuid ajutisse tabelisse, mis on spetsialiseerunud ajutistele andmetele. Pärast seda saate analüüsida, milline on teil seal väärtuste jaotus, mis seal üldse on ja koostada õiged tüübid.

* praegu on ClickHouse'is andmetüüp, LowCardinality , mis võimaldab tõhusalt hoida stringe väiksemate töömahtude tõttu.

Nüüd vaatame veel üht huvitavat juhtumit. Mõnikord töötab inimestel kõik kuidagi imelikult. Ma sisenen ja näen sellist pilti. Ja kohe tundub, et seda on teinud mõni väga kogenud, nutikas admin, kellel on suur kogemus MySQL versiooni 3.23 seadistamisel.

Siin näeme tuhandet tabelit, milles igas on salvestatud jäänus mingist imelikust jagamisest tuhande peale.

Põhimõtteliselt austan teiste kogemusi ja mõistan, milliste kannatustega see kogemus on saadud.

Ja põhjused on enam-vähem arusaadavad. Need on vanad stereotüübid, mis on võinud tekkida teiste süsteemidega töötades. Näiteks MyISAM tabelites ei ole klasterdatud esmaseid võtmeid. Ja selline andmete jagamise viis võib olla meeleheitlik katse saada sama funktsionaalsust.

Teine põhjus on see, et igasuguseid operatsioone nagu alter on suurte tabelite puhul raske teha. Kõik saab blokeeritud. Kuigi kaasaegsetes MySQL versioonides ei ole see probleem enam nii tõsine.

Või näiteks mikrošardimise kohta, kuid sellest räägime veidi hiljem.

ClickHouse'is ei ole seda vaja teha, kuna esmase võti on klasterdatud ja andmed on esmase võtme järgi järjestatud.

Ja mõnikord küsitakse minult: "Kuidas muutub ClickHouse-i vahemiku päringute jõudlus tabeli suuruse kasvades?". Ma ütlen, et see ei muutu üldse. Näiteks, kui teil on miljard rida tabelis ning loete vahemikku üks miljon rida. Kõik on korras. Kui tabelis on triljon rida ja te loete ühe million rida, siis on tulemused peaaegu samad.

Ja teiseks, sellised asjad nagu käsitsi partitsioonid ei ole vajalikud. Kui te vaatate, mis on failisüsteemis, näete, et tabel on tõsine asi. Seal sees on midagi nagu partitsioonid. See tähendab, et ClickHouse teeb kõik ise teie eest ja te ei pea muretsema.

Alter ClickHouse'is on tasuta, kui tegemist on alter add/drop column.

Ja väikeste tabelite tegemine ei ole vajalik, kuna kui teil on 10 rida või 10 000 rida tabelis, ei ole sellel suurt tähtsust. ClickHouse on süsteem, mis optimeerib läbilaskevõimet, mitte latentsust, seega ei ole mõtet töödelda 10 rida.

Tõeliselt õige on kasutada ühte suurt tabelit. Vabanege vanadest stereotüüpidest, kõik läheb hästi.

Ja boonusena on meie viimases versioonis lisandunud võimalus teha suvaline partitsioneerimise võti, et teostada erinevaid hooldusoperatsioone eraldi partitsioonide üle.

Näiteks, kui teil on vaja palju väikeseid tabelite, näiteks kui peate töötlema vaheandmeid, siis teil tulevad chunk'id ja peate nende kallal tõlked tegema enne nende kirjutamist lõplikku tabelisse. Selle juhtumi jaoks on suurepärane tabelimootor – StripeLog. See on midagi sarnast TinyLogiga, aga parem.

* nüüd on ClickHouse'is veelgi tabelifunktsioon input.

Veel üks antipattern on mikrosülemine. Näiteks, kui peate andmeid sülema ja teil on 5 serverit, aga homme tuleb 6serverit. Ja te mõtlete, kuidas neid andmeid ümber jagada. Ja selle asemel, et jagada 5 partii, teete 1 000 partiid. Ja edasi jagate igaühe nende mikrosülemite sarnaselt eraldi serveritele. Ja teil võib olla näiteks ühes serveris 200 ClickHouse'i instance, näiteks. Eraldi instance'id erinevatel portidel või eraldi andmebaasid.

Aga ClickHouse'is pole see väga hea. Sest isegi üks ClickHouse instance püüab kasutada kõik saadaval olevad serveri ressursid ühe päringu töötlemiseks. St. teil on mingi server ja seal on näiteks 56 protsessorituuma. Teete päringu, mis kestab ühe sekundi ja see kasutab 56 tuuma. Ja kui te olete sinna paigutanud 200 ClickHouse'i ühte serverisse, siis tähendab, et käivitub 10 000 lõime. Ühesõnaga, kõik läheb väga halvasti.

Teine põhjus on see, et töö jaotus nende instance'ide vahel on ebaühtlane. Mõni lõpetab varem, mõni hiljem. Kui see kõik toimuks ühes instance'is, siis ClickHouse saaks ise aru, kuidas andmeid õigele lõime jaotada.

Ja veel üks põhjus on see, et teil on protsessoritevaheline suhtlemine TCP kaudu. Andmeid tuleb serialiseerida, deserialiseerida ja see on tohutu hulk mikrosülemeid. Lihtsalt ei ole efektiivne töö.

Veel üks antipattern, kuigi seda on raske antipatterniks nimetada. See on suur hulk eelagreed.

Üldiselt on eelagregeerimine hea. Teil oli miljard rida, te aggregeerisite selle ja see muutus 1 000 reaks, ja nüüd käib päring hetkega. Kõik on suurepärane. Nii võib teha. Ja selle jaoks on isegi ClickHouse'is spetsiaalne tabelitüüp AggregatingMergeTree, mis teeb inkrementaalse aggregeerimise andmete sisestamise käigus.

Aga on olukordi, kus te arvate, et me kogume andmeid selliselt ja veel ka niimoodi. Ja mingis naaberosakonnas, millest ma ei taha rääkida, kasutatakse SummingMergeTree tabeleid summade kogumiseks põhivõtme järgi, ning põhivõtmena kasutatakse 20 erinevat veergu. Ma muutsin mõned veergude nimetused varjamiseks, kuid umbes nii see ongi.

Ja tekivad sellised probleemid. Esiteks, teie andmete maht ei vähene kuigi palju. Näiteks väheneb see kolm korda. Kolm korda – see oleks hea hind, et lubada endale piiramatud analüüsi võimalused, mis tekivad, kui andmed ei ole koondatud. Kui andmed on koondatud, siis saate analüüsi asemel vaid kehva statistika.

Ja mis eriti häirib? Et need inimesed naaberosakonnast tulevad ja küsivad mõnikord, et lisage veel üks veerg põhivõtmesse. T. e. me oleme koondanud andmeid, aga nüüd tahame midagi rohkemat. Kuid ClickHouse'is ei ole võimalik põhivõtit muuta. Seega peame kirjutama mingeid skripte C++. Ja ma ei armasta skripte, isegi kui need on C++.

Ja kui vaadata, milleks ClickHouse loodi, siis mitteagreggeeritud andmed on just see stsenaarium, mille jaoks see on loodud. Kui kasutate ClickHouse't mitteagreggeeritud andmete jaoks, siis teete kõik õigesti. Kui te aga koondate, siis mõnikord on see möödapääsmatu.

Veel üks huvitav juhtum – see on lõpmatus tsüklis toimuvad päringud. Ma mõnikord sisenen mõnele tootmisserverile ja vaatan seal show processlist. Ja iga kord avastan, et toimub midagi kohutavat.

Näiteks midagi sellist. Siit on kohe selge, et kõik oleks saanud teostada ühes päringus. Lihtsalt kirjutage url in ja nimekiri.

Miks on palju selliseid päringuid lõpmatus tsüklis halb? Kui indeksi ei kasutata, siis teil on palju läbimineid samade andmete kohta. Kuid kui indeks on kasutusel, näiteks kui teil on põhivõti ru ja kirjutate url = millegi kohta. Ja te arvate, et loetakse tabelist ühe url'i, siis kõik on korras. Kuid tegelikult ei ole. Sest ClickHouse teeb kõik pakettide kaupa.

Kui tal on vaja lugeda andmete vahemikku, loeb ta veidi rohkem, kuna ClickHouse'i indeks on haruldane. See indeks ei võimalda tabelist leida ühte konkreetset rida, vaid ainult mingit vahemikku. Andmed tihendatakse plokkide kaupa. Ühe rea lugemiseks tuleb võtta kogu plokk ja see avada. Ja kui teete hulga päringuid, siis teil on palju kattuvusi ja palju tööd, mida tehakse jälle ja jälle.

Ja boonusena võib märkida, et ClickHouse'is ei pea kartma edastada isegi megabaite ja isegi sadu megabaite IN-sektsiooni. Mäletan meie praktikast, et kui MySQL-is edastame palju väärtusi IN-sektsiooni, näiteks edastame 100 megabaidi numbreid, siis MySQL sööb 10 gigabaiti mälu ja sellega enam midagi ei juhtu, kõik töötab halvasti.

Ja teiseks – ClickHouse'is, kui teie päringud kasutavad indeksit, siis see ei ole kunagi aeglasem kui täiskann, st kui lugeda tuleb peaaegu kogu tabelit, siis see toimub järjestikku ja loeb kogu tabeli. Üldiselt mõistab see ise, millega on tegu.

Kuid sellel on siiski teatud keerukused. Näiteks see, et IN koos alampäringuga ei kasuta indeksit. Kuid see on meie probleem ja peame selle parandama. Siin pole midagi fundamentaalset. Parandame selle.

Ja veel üks huvitav asi – kui teil on väga pikk päring ja jaotatud päringute töötlemine käib, siis see väga pikk päring saadetakse igale serverile ilma tihendamiseta. Näiteks 100 megabaidi ja 500 serveriga. Seega edastatakse teie võrgus 50 gigabaiti. See edastatakse ja seejärel täidetakse kõik edukalt.

* juba kasutab; kõik on parandatud, nagu lubatud.

Ja üsna sagedane juhtum on see, kui päringud tulevad API-st. Näiteks olete loonud oma teenuse. Ja kui teie teenus on kellelegi vajalik, siis olete avanud API ja juba kaks päeva hiljem näete, et toimub midagi arusaamatut. Kõik on üle koormatud ja paar kohutavat päringut tuleb, mida kunagi ei oleks pidanud olema.

Ja siin on lahendus üks. Kui olete avanud API, peate selle kärpima. Näiteks tuleks kehtestada mingid kvoodid. Teisi normaalseid võimalusi pole. Vastasel juhul kirjutatakse kohe skript ja tekivad probleemid.

Ja ClickHouse'is on spetsiaalne võimalus – kvota arvestamine. Lisaks on võimalik edastada oma kvota võti. See võib olla näiteks kasutaja sisemine identifikaator. Ja kvotad arvestatakse igaühe jaoks eraldi.

Nüüd veel üks huvitav asi. See on käsitsi juhitav replikeerimine.

Ma tean palju juhtumeid, kus, hoolimata ClickHouse'is olevast sisseehitatud replikeerimise toest, replikeerivad inimesed ClickHouse'i käsitsi.

Millisest printsiibist on jutt? Teil on andmete töötlemise pipeline. Ja see toimib iseseisvalt, näiteks erinevates andmekeskustes. Te kirjutate sama teavet ClickHouse'i samamoodi. Tõsi, praktika näitab, et andmed lähevad ikkagi erinevaks, sõltuvalt teie koodis esinevatest eripärastest. Loodetavasti mitte teie omades.

Ja aeg-ajalt peate ikkagi käsitsi sünkroonima. Näiteks kord kuus teevad administraatorid rsync'i.

Tegelikult on palju lihtsam kasutada ClickHouse'i sisseehitatud replikeerimist. Kuid siin võivad olla teatud vastunäidustused, sest selleks peate kasutama ZooKeeperit. Ma ei ütle midagi halba ZooKeeperi kohta, põhimõtteliselt on süsteem töövõimel, kuid mõnikord ei kasuta inimesed seda java-fobi tõttu, sest ClickHouse on nii hea süsteem, mis on kirjutatud C++-s, mida saab kasutada ja kõik töötab hästi. Aga ZooKeeper on java peal. Ja kuidagi ei tahaks isegi vaadata, kuid siis võite kasutada käsitsi juhitavat replikeerimist.

ClickHouse on praktiline süsteem. See arvestab teie vajadustega. Kui teil on käsitsi juhitav replikeerimine, siis saate luua Jaotatud tabeli, mis vaatab teie käsitsireplikaid ja teeb nende vahel automaatse failover'i. Ja on isegi spetsiaalne valik, mis võimaldab vältida flappe, isegi kui teie replikad erinevad süsteemselt.

Edasi võivad tekkida probleemid, kui kasutate primitiivseid tabelimootoreid. ClickHouse on nagu ehituskonstruktor, kus on palju erinevaid tabelimootoreid. Kõigi tõsiste juhtumite jaoks, nagu on dokumentatsioonis kirjutatud, kasutage MergeTree perekonna tabeleid. Kõik teised on pigem erijuhtumiteks või testimiseks.

MergeTree tabelis ei pea teil olema mingit kuupäeva ja aega. Saate ikkagi kasutada. Kui kuupäeva ja aega ei ole, kirjutage default – 2000. aasta. See töötab ja ei nõua ressursse.

Ja uues serveri versioonis on isegi võimalik määrata, et teil oleks kohandatud jagamine ilma partitsiooni võtmeta. See on sama.

Teiselt poolt võib kasutada primitiivseid tabelimootoreid. Näiteks laadige andmed üks kord sisse ja vaadake, mängige nendega ja kustutage. Võite kasutada Logi.

Või salvestada väikseid mahtusid vahepealseks töötlemiseks – see on StripeLog või TinyLog.

Mälu saab kasutada, kui andmete maht on väike ja lihtsalt mängitakse midagi mällu.

ClickHouse ei armasta ülemääraselt normaliseeritud andmeid.

Siin on tüüpiline näide. See on tohutu hulk URL-e. Te panite need naabertabelisse. Siis otsustasite neid JOINida, aga see ei toimi, kuna ClickHouse toetab ainult Hash JOINi. Kui mälust ei piisa andmete koguni, millega tuleb liita, siis JOIN ei õnnestu.*

Kui andmed on suure kardinaalsusega, siis ärge muretsege, hoidke neid denormaliseeritud kujul, URL-id otse põhitaotluses.

* kuid nüüd on ClickHouse'il ka merge join ja see töötab, kui vaheandmed ei mahu mällu. Kuid see ei ole efektiivne ja soovitus kehtib endiselt.

Veel paar näidet, kuid ma juba kahtlen, kas need on tõeliselt antipaaterid või mitte.

ClickHouse'il on üks tuntud puudus. Ta ei oska uuendusi teha*. Teatud mõttes on see isegi hea. Kui teil on olulisi andmeid, näiteks raamatupidamine, siis keegi ei suuda neid saata, sest uuendusi pole.

* juba ammu on lisatud toetus uuendamiseks ja kustutamiseks partii režiimis.

Kuid on mõned erilised viisid, mis võimaldavad uuendusi nagu taustal. Näiteks ReplaceMergeTree tüüpi tabelid. Need teevad uuendusi taustal toimuvate ühinemiste ajal. Saate seda sundida optimize table abil. Kuid ärge tehke seda liiga tihti, sest see tähendab partitsiooni täielikku kirjutamist.

Jaotatud JOIN'id ClickHouse'is – see on samuti halvasti planeerimisrežiimiga töödeldud.

Halb, kuid mõnikord on see korras.

ClickHouse'i kasutamine ainult selleks, et lugeda andmeid tagasi select* abil.

Ma ei soovitaks ClickHouse'i kasutada mahukate arvutuste jaoks. Kuid asi ei ole täiesti nii, kuna me oleme juba sellest soovitusest kõrvale kaldumas. Ja meil on hiljuti lisandunud võimalus rakendada masinõppemudeleid ClickHouse'is – Catboost. See teeb mind murelikuks, sest ma mõtlen: "Kohutav. Kui palju siis takte byte kohta tuleb!". Mul on tõeliselt kahju, et takte byte'ide peale kulutada.

Aga ärge muretsege, installige ClickHouse ja kõik läheb hästi. Kui midagi juhtub, on meil kogukond. Muide, kogukond olete teie. Ja kui teil on mingeid probleeme, saate vähemalt meie chati astuda ja loodan, et teid aidatakse.

Küsimused

Aitäh ettekande eest! Kuhu kaevata ClickHouse'i kokkuvarisemise üle?

Võite kaevata otse minu juurde praegu.

Ma hakkasin hiljuti ClickHouse'i kasutama. Koheselt kukutasin cli liidese.

Teid on õnnistatud.

Veidi hiljem kukutasin väikese select'iga serveri.

Teil on anne.

Avasin GitHubis vea, kuid seda ignoreeriti.

Vaadake.

Aleksei tõi mind ettekandesse vale pärast, lubades rääkida, kuidas te andmeid pressite.

Väga lihtne.

Seda ma arvasin juba eile. Rohkem konkreetikast.

Seal pole mingeid kohutavaid trikke. Seal on lihtsalt blokkide kaupa tihendamine. Vaikimisi kasutatakse LZ4, ZSTD* saab sisse lülitada. Blokid on vahemikus 64 kilobaiti kuni 1 megabaidini.

* Samuti on olemas spetsialiseeritud tihenduskoodikate tugi, mida saab kasutada muude algoritmidega ahelas.

Kas blokid sisaldavad lihtsalt tooreid andmeid?

Ei ole täiesti toored. Seal on massiivid. Kui teil on numbriline veerg, siis numbrid on järjestikku massiivis.

Selge.

Aleksei, näide, mis oli uniqExact'iga ip aadresside puhul, st see, et uniqExact arvutamine ridade peal kestab kauem kui numbrite jaoks jne. Aga kui me rakendame trikki ja castime kokku lugemise ajal? St te, näiliselt ütlesite, et kettal ei erine see oluliselt. Kui me loeme ketas ridu, castime, kas siis on meil aggregaadid kiiremad või ei? Või me siiski ei saa siin märgatavat kasu? Mul on tunne, et te testisite seda, kuid mingil põhjusel ei maininud te seda benchmark'is.

Ma arvan, et see on aeglasem kui ilma kastita. Sel juhul tuleb IP-aadressi stringist eraldada. Meil on ClickHouse'is ka IP-aadresside eraldamine optimeeritud. Me oleme selle nimel kõvasti vaeva näinud, aga seal on numbrid kirja pandud kümnendvormis. Väga ebamugav. Teisest küljest töötab uniqExact funktsioon stringide puhul aeglasemalt mitte ainult sellepärast, et need on stringid, vaid ka seetõttu, et valitakse teine algoritmi spetsialiseerumine. Stringe töödeldakse lihtsalt teistmoodi.

Aga kui võtta lihtsam andmetüüp? Näiteks, kui me paneme kirja user id, mis meil on in, kirjutame selle stringina ja siis kastime, kas siis on lõbusam või mitte?

Ma kahtlen. Arvan, et see on isegi kurvem, sest numbrite eraldamine on tõeliselt tõsine probleem. Ma arvan, et sellel kollegil oli isegi esitluses teema, kuidas numbrite eraldamine kümnendvormis on keeruline, või võib-olla mitte.

Aleksei, suur aitäh esitluse eest! Ja suur aitäh ClickHouse'i eest! Mul on küsimus plaanide kohta. Kas on plaanis funktsioon, et sõnaraamatute osalist uuendamist?

T. e. osaline taaskäivitamine?

Jah-jah. Nagu võimalus määrata seal MySQL väli, t. e. uuendada after, et laadida ainult need andmed, kui sõnaraamat on väga suur.

Väga huvitav funktsioon. Ja mulle tundub, et keegi inimene pakkus seda meie vestluses. Võib-olla olite see isegi teie.

Ma ei arva, et see olin mina.

Suurepärane, nüüd on siis kaks päringut. Ja võib rahulikult alustada tegemist. Aga tahan kohe teid hoiatada, et see funktsioon on üsna lihtne ellu viia. T. e. põhimõtteliselt tuleb lihtsalt tabelisse kirjutada versiooni number ja seejärel kirjutada: versioon on väiksem kui see ja see. Ja see tähendab, et me tõenäoliselt pakume selle tegemiseks entusiastidele. Kas te olete entusiast?

Jah, aga kahjuks mitte C++-s.

Kas teie kolleegid oskavad C++-s kirjutada?

Ma leian kellegi.

Suurepärane*.

* funktsioon lisati kaks kuud pärast esitluse tegemist – selle töötas välja küsimuse autor ja saatis oma pull request.

Aitäh!

Tere! Aitäh ettekande eest! Mainisite, et ClickHouse kasutab väga hästi ära kõik selle jaoks saadaval olevad ressursid. Ja naaberettekande tegija Luxsoftist rääkis oma lahendusest Venemaa Posti jaoks. Ta ütles, et ClickHouse meeldis neile väga, kuid nad ei kasutanud seda oma peamise konkurendi asemel just sellepärast, et see kasutas ära kogu protsessori. Ja nad ei suutnud seda integreerida oma arhitektuuri, oma ZooKeeperi ja konteineritega. Kas on võimalus kuidagi piirata ClickHouse'i, et see ei kasutaks kõike, mis talle kätte satub?

Jah, see on võimalik ja väga lihtne. Kui soovite, et see kasutaks vähem tuumasid, kirjutage lihtsalt set max_threads = 1. Ja kõik, see täidab päringu ühes tuumas. Samuti saavad erinevad kasutajad kasutada erinevaid seadeid. Seega ei ole probleeme. Ja edastage oma kolleegidele Luxsoftist, et ei ole hea, et nad ei leidnud seda seadet dokumentatsioonist.

Tere, Aleksei! Sooviksin küsida sellise küsimuse. Juba mitte esimest korda kuulen, et paljud hakkavad kasutama ClickHouse'i logide hoidmiseks. Ettekandes ütlesite, et seda ei tohi teha, st ei ole vaja hoida pikki ridu. Kuidas Te sellele suhtute?

Esiteks, logid on reeglina mitte pikad read. Muidugi, erandeid võib olla. Näiteks, kui mingi teenus, mis on kirjutatud java's, viskab exception'i ja see logitakse. Ja nii lõpmatus tsüklis, ja lõpuks lõpeb koht kõvakettal. Lahendus on väga lihtne. Kui read on liiga pikad, siis lõigake need. Ja mis tähendab pikad? Kümned kilobaitid – see on halb*.

* Uuemates ClickHouse'i versioonides on sisse lülitatud "kohandatud granulaarsuse indeks", mis lahendab pika ridade hoidmise probleemi peaaegu täielikult.

Aga kilobait – see on normaalne?

Normaalne.

Tere! Aitäh ettekande eest! Olen juba sellest vestluses küsinud, aga ei mäleta, kas sain vastuse. Kas plaanitakse laiendada ANDMESEKTSIOONI nagu CTE?

Praegu ei. Meie ANDMESEKTSIOON on natuke ebasiiras. See on meil nagu väike funktsioon.

Sain aru. Aitäh!

Aitäh ettekande eest! Väga huvitav! Üks globaalne küsimus. Kas on plaanis ehk teha mõningaid silte andmete kustutamise modifikatsiooniks?

Kohustuslikult. See on meie esmane ülesanne meie järjekorras. Praegu oleme aktiivselt välja mõtlemas, kuidas kõike õigesti teha. Ja nüüd on aeg hakata klaviatuurile vajutama*.

* vajutades klahve klaviatuuril, tegime kõik ära.

Kas see mõjutab kuidagi süsteemi jõudlust või mitte? Kas sisestamine on sama kiire, kui see on praegu?

Võib-olla ise deletes, ise updates on väga rasked, kuid see ei mõjuta selects ja inserts jõudlust.

Ja veel üks väike küsimus. Esitluses rääkisite peamise võtme kohta. Seega, meil on partitsioneerimine, mis on vaikimisi kuupõhine, eks? Ja kui me määrame kuupäevade vahemiku, mis mahub kuusse, siis loetakse ainult seda partitsiooni, eks?

Jah.

Selline küsimus. Kui me ei saa määrata mingit peamist võtit, kas on õige teha see väljale "Kuupäev" selleks, et taustal oleks vähem andmete ümberkorraldamist ning need oleksid korrastatumalt paigutatud? Kui teil ei ole vahemiku päringuid ja te isegi ei saa valida mingit peamist võtit, kas on siis mõtet kuupäeva peamisse võtmesse panna?

Jah.

Võib-olla on mõistlik panna peamisse võtmesse selline väli, mille järgi andmeid oleks lihtsam kompressida, kui need on selle väli järgi sorteeritud. Näiteks, kasutaja identifikaator. Kasutaja, näiteks, külastab sama veebisaiti. Sellisel juhul panege kasutaja id ja aeg. Siis on teie andmed paremini kompressitud. Seoses kuupäevaga, kui teil tõepoolest ei ole ja ei ole kunagi vahemiku päringuid kuupäevade järgi, siis ei ole mõtet kuupäeva peamisse võtmesse panna.

Hea, aitäh palju!

Allikas: habr.com