Kuna ClickHouse on spetsialiseerunud süsteem, siis on selle kasutamisel oluline arvestada selle arhitektuuri iseärasusi. Selles aruandes räägib Aleksei ClickHouse'i kasutamisel esinevate tüüpiliste vigade näidetest, mis võivad põhjustada ebaefektiivset tööd. Praktiliste näidete abil näitame, kuidas ühe või teise andmetöötlusskeemi valik võib jõudlust suurusjärkude kaupa muuta.
Tere kõigile! Minu nimi on Aleksei, ma teen ClickHouse'i.
Esiteks kiirustan teile kohe meeldima, ma ei ütle teile täna, mis on ClickHouse. Ausalt öeldes olen sellest väsinud. Ma ütlen teile iga kord, mis see on. Ja ilmselt kõik juba teavad.
Selle asemel räägin teile, mis on võimalik reha, st kuidas ClickHouse'i kuritarvitada saab. Tegelikult ei tasu karta, sest arendame ClickHouse’i süsteemina, mis on lihtne, mugav ja töötab juba karbist välja. Kõik installitud, pole probleeme.
Kuid siiski tuleb meeles pidada, et see süsteem on spetsialiseerunud ja võite kergesti komistada ebatavalise kasutusjuhtumi otsa, mis viib selle süsteemi mugavustsoonist välja.
Niisiis, mis on rehad? Põhimõtteliselt räägin ilmselgetest asjadest. Kõik on kõigile arusaadav, kõik saavad kõigest aru ja võivad rõõmustada, et nad nii targad on, ja kes aru ei saa, õpib midagi uut.
Esimene lihtsaim näide, mida kahjuks sageli ette tuleb, on suur hulk sisestusi väikeste partiidega, st suur hulk väikeseid sisestusi.
Kui arvestada, kuidas ClickHouse sisestab, saate ühe päringuga saata vähemalt terabaidi andmeid. See pole probleem.
Ja vaatame, milline saab olema tüüpiline esitus. Näiteks on meil tabel Yandex.Metricsi andmetega. Hitid. 105 mõned veerud. 700 baiti tihendamata. Ja me sisestame heas mõttes ühe miljoni rea partiid.
Sisestame MergeTree tabelisse, saadakse pool miljonit rida sekundis. Suurepärane. Kopeeritud tabelis - see on veidi vähem, umbes 400 000 rida sekundis.
Ja kui lülitate sisse kvoorumi lisa, saate natuke vähem, kuid siiski korralikku jõudlust, 250 000 korda sekundis. Kvoorumi lisamine on ClickHouse'i* dokumentideta funktsioon.
* 2020. aasta seisuga, .
Mis juhtub, kui teete seda valesti? Sisestame MergeTree tabelisse ühe rea ja saame 59 rida sekundis. See on 10 000 korda aeglane. Teenuses ReplicatedMergeTree – 6 rida sekundis. Ja kui kvoorum lülitub sisse, saadakse 2 rida sekundis. Minu arust on see mingi täielik jama. Kuidas saab niimoodi hoogu maha võtta? Minu T-särgil on isegi kirjas, et ClickHouse ei tohiks hoogu maha võtta. Kuid sellegipoolest juhtub seda mõnikord.
Tegelikult on see meie puudus. Oleksime võinud selle suurepäraselt toimima panna, aga me ei teinud seda. Ja me ei teinud seda, sest meie stsenaarium ei vajanud seda. Meil olid juba partiid. Saime just sissepääsu juures partiid kätte ja probleeme polnud. Ühendage see vooluvõrku ja kõik töötab hästi. Aga loomulikult on võimalikud igasugused stsenaariumid. Näiteks kui teil on hulk servereid, kus andmeid genereeritakse. Ja nad ei sisesta andmeid nii sageli, kuid neid sisestatakse siiski sageli. Ja seda tuleb kuidagi vältida.
Tehnilisest vaatenurgast võib öelda, et kui teete ClickHouse'is lisamise, ei satu andmed ühegi mälutahvlisse. Meil pole isegi päris MergeTree logistruktuuri, vaid lihtsalt MergeTree, sest seal pole ei logi ega memTabelit. Kirjutame andmed kohe veergudeks jaotatud failisüsteemi. Ja kui teil on 100 veergu, tuleb rohkem kui 200 faili kirjutada eraldi kataloogi. Kõik see on väga tülikas.
Ja tekib küsimus: "Kuidas seda õigesti teha?" Sellise olukorra korral peate ikkagi kuidagi ClickHouse'i andmed kirjutama.
1. meetod. See on kõige lihtsam viis. Kasutage mingit hajutatud järjekorda. Näiteks Kafka. Võtke lihtsalt andmed Kafkast välja, me koondame need kord sekundis. Ja kõik saab korda, salvestate, kõik töötab hästi.
Puuduseks on see, et Kafka on veel üks tülikas hajutatud süsteem. Saan ka aru, kui Kafka sul juba firmas on. See on hea, see on mugav. Aga kui seda pole, peaksite kolm korda mõtlema, enne kui lohistate oma projekti mõne muu hajutatud süsteemi. Ja seetõttu tasub kaaluda alternatiive.
Meetod 2. Siin on selline vana kooli alternatiiv ja samas väga lihtne. Kas teil on mingi server, mis teie logisid genereerib? Ja see lihtsalt kirjutab teie logid faili. Ja näiteks kord sekundis nimetame selle faili ümber, avame uue. Ja eraldi skript kas cron või mõne deemoni poolt võtab vanima faili ja kirjutab selle ClickHouse'i. Kui kirjutad logisid korra sekundis, siis on kõik hästi.
Aga selle meetodi miinuseks on see, et kui sinu server, millel logisid genereeritakse, on kuhugi kadunud, siis kaovad ka andmed.
3. meetod. On veel üks huvitav viis, mis on ilma ajutiste failideta. Näiteks on teil mingi reklaamikeerutaja või mõni muu huvitav deemon, mis andmeid genereerib. Ja saate koguda hunniku andmeid otse RAM-i, puhvrisse. Ja kui piisav aeg möödub, paned selle puhvri kõrvale, teed uue ja sisestad juba kogunenud ClickHouse'i eraldi lõime.
Teisest küljest kaovad andmed ka kill -9 korral. Kui teie server läheb alla, kaotate need andmed. Ja teine probleem on see, et kui te ei saanud andmebaasi kirjutada, kogunevad teie andmed RAM-i. Ja kas RAM saab otsa või kaotate lihtsalt andmed.
4. meetod. Veel üks huvitav viis. Kas teil on serveriprotsess. Ja ta saab ClickHouse'i andmeid saata korraga, kuid teha seda ühes ühenduses. Näiteks saatsin http päringu koos transfer-kodeeringuga: chunked with insert. Ja see genereerib tükke mitte liiga harva, saate saata iga rea, kuigi nende andmete raamimine on lisakulu.
Kuid sel juhul saadetakse andmed kohe ClickHouse'i. Ja ClickHouse ise puhverdab need.
Kuid on ka probleeme. Nüüd kaotate andmed, sealhulgas siis, kui teie protsess suletakse ja kui ClickHouse'i protsess tapetakse, kuna see on mittetäielik sisestus. Ja ClickHouse'is on sisestused aatomi kuni teatud ridade suuruses määratud künniseni. Põhimõtteliselt on see huvitav viis. Võib kasutada ka.
5. meetod. Siin on veel üks huvitav viis. See on mingi kogukonna poolt välja töötatud server andmete pakkimiseks. Ise pole vaadanud, seega ei saa midagi garanteerida. ClickHouse'i enda jaoks aga garantiid pole. See on samuti avatud lähtekoodiga, kuid teisest küljest võiksite harjuda mõne kvaliteedistandardiga, mida me püüame pakkuda. Aga selle asja jaoks - ma ei tea, minge GitHubisse, vaadake koodi. Võib-olla kirjutasid nad midagi head.
*alates 2020. aastast tuleks samuti arvesse võtta .
6. meetod. Teine võimalus on kasutada puhvertabeleid. Selle meetodi eeliseks on see, et seda on väga lihtne kasutada. Looge puhvritabel ja sisestage see.
Kuid puuduseks on see, et probleem pole täielikult lahendatud. Kui MergeTree tüüpi kiirusega peate andmeid rühmitama ühe partii kaupa sekundis, siis puhvertabelis oleva kiirusega peate rühmitama vähemalt kuni mitu tuhat sekundis. Kui on üle 10 000 sekundis, siis on ikka paha. Ja kui sisestate partiidena, siis nägite, et seal saadakse sada tuhat rida sekundis. Ja see on juba üsna rasketel andmetel.
Ja ka puhvertabelitel pole logi. Ja kui teie serveriga on midagi valesti, lähevad andmed kaotsi.
Ja boonusena oli meil hiljuti võimalus ClickHouse'is Kafka andmeid koguda. Seal on lauamootor - Kafka. Te lihtsalt loote. Ja saate sellele riputada materialiseeritud vaateid. Sel juhul võtab ta Kafkast andmed välja ja sisestab need teile vajalikesse tabelitesse.
Ja mis selle võimaluse juures eriti rõõmustav, on see, et meil ei õnnestunud. See on kogukonna funktsioon. Ja kui ma ütlen "kogukonna tunnus", siis ütlen seda ilma põlguseta. Lugesime koodi, vaatasime üle, see peaks hästi töötama.
* Alates 2020. aastast on samasugune tugi olemas .
Mis veel võib andmete sisestamisel olla ebamugav või ootamatu? Kui teete väärtuste sisestamise päringu ja kirjutate väärtusteks mõned arvutatud avaldised. Näiteks now() on samuti hinnatud avaldis. Ja sel juhul on ClickHouse sunnitud käivitama iga rea jaoks nende avaldiste tõlgi ja jõudlus langeb suurusjärkude võrra. Parem seda vältida.
* hetkel on probleem täielikult lahendatud, VALUES avaldiste kasutamisel enam jõudluse regressiooni ei toimu.
Teine näide, kus võib esineda probleeme, on see, kui teie andmed ühes partiis kuuluvad partitsioonide hulka. Vaikimisi ClickHouse'i partitsioonid kuude kaupa. Ja kui sisestate miljonist reast koosneva partii ja andmeid on mitu aastat, on teil seal mitukümmend partitsiooni. Ja see on samaväärne tõsiasjaga, et partiid on mitukümmend korda väiksemad, sest sees jagatakse need alati kõigepealt vaheseinteks.
* Hiljuti lisati ClickHouse'i eksperimentaalrežiimis tugi RAM-i tükkide ja tükkide kompaktsele vormingule koos ettekirjutamise logiga, mis lahendab probleemi peaaegu täielikult.
Nüüd kaaluge teist tüüpi probleemi – andmete sisestamist.
Andmete sisestamine võib olla range ja mõnikord ka stringiga. String – see on siis, kui võtsite ja teatasite, et teil on kõik string tüüpi väljad. See on nõme. Sa ei pea seda tegema.
Mõtleme välja, kuidas seda õigesti teha juhtudel, kui tahad öelda, et meil on mingi põld, string ja las ClickHouse ise nuputab, aga leili ma ei võta. Kuid sellegipoolest tasub pingutada.
Näiteks on meil IP-aadress. Ühel juhul salvestasime selle stringina. Näiteks 192.168.1.1. Vastasel juhul on see number UInt32*. IPv32 aadressi jaoks piisab 4 bitist.
Esiteks, kummalisel kombel tihendatakse andmed umbes samamoodi. Kindlasti on erinevus, kuid mitte nii suur. Seega pole ketta I/O-ga erilisi probleeme.
Kuid protsessori ajas ja päringu täitmise ajas on tõsine erinevus.
Loendame kordumatute IP-aadresside arvu, kui need on salvestatud numbritena. Selgub, et 137 miljonit rida sekundis. Kui sama, mis read, siis 37 miljonit rida sekundis. Ma ei tea, miks see kokkusattumus juhtus. Olen need palved ise täitnud. Aga sellegipoolest umbes 4 korda aeglasemalt.
Ja kui arvutada kettaruumi erinevus, siis on ka erinevus. Ja vahe on umbes veerand, sest unikaalseid IP-aadresse on päris palju. Ja kui oleks olnud väikese arvu erinevate väärtustega ridu, siis oleks need sõnastikus vaikselt kokku surutud umbes samasse mahtu.
Ja neljakordne ajavahe ei leba tee peal. Võib-olla teid muidugi ei huvita, aga kui ma sellist erinevust näen, tunnen kurbust.
Vaatleme erinevaid juhtumeid.
1. Üks juhtum, kui teil on vähe erinevaid unikaalseid väärtusi. Sel juhul kasutame lihtsat tava, mida te tõenäoliselt teate ja saate kasutada mis tahes DBMS-i jaoks. See kõik on mõttekas mitte ainult ClickHouse'i jaoks. Lihtsalt kirjutage numbrilised identifikaatorid andmebaasi. Ja saate teisendada stringideks ja tagasi oma rakenduse küljel.
Näiteks on teil piirkond. Ja proovite seda stringina salvestada. Ja sinna kirjutatakse: Moskva ja Moskva piirkond. Ja kui ma näen, et sinna on kirjutatud “Moskva”, siis see pole ikka midagi ja kui on MO, siis läheb kuidagi täitsa kurvaks. Nii palju baite.
Selle asemel kirjutame lihtsalt üles Ulnt32 numbri ja 250. Meil on Yandexis 250, kuid teie oma võib olla erinev. Igaks juhuks ütlen, et ClickHouse'il on sisseehitatud võimalus töötada geobaasiga. Lihtsalt kirjutage üles kataloog piirkondadega, sealhulgas hierarhiline, st seal on Moskva, Moskva piirkond ja kõik vajalik. Ja saate teisendada taotluse tasemel.
Teine võimalus on umbes sama, kuid ClickHouse'i toega. See on Enum andmetüüp. Kirjutage lihtsalt kõik vajalikud väärtused Enumi sisse. Näiteks seadme tüüp ja kirjutage sinna: lauaarvuti, mobiil, tahvelarvuti, teler. Ainult 4 võimalust.
Puuduseks on see, et peate perioodiliselt muutma. Lisatud on ainult üks võimalus. Teeme vahetuslaua. Tegelikult on ClickHouse'i muutmise tabel tasuta. Eriti tasuta Enumi jaoks, sest kettal olevad andmed ei muutu. Kuid sellegipoolest omandab alter laual luku * ja peab ootama, kuni kõik valikud on lõpetatud. Ja alles pärast seda teostatakse alter, st on veel ebamugavusi.
* ClickHouse'i viimastes versioonides on ALTER tehtud täiesti mitteblokeerivaks.
Teine ClickHouse'i jaoks üsna ainulaadne võimalus on väliste sõnaraamatute ühendamine. ClickHouse'is saate kirjutada numbreid ja hoida oma katalooge mis tahes teile sobivas süsteemis. Näiteks võite kasutada: MySQL, Mongo, Postgres. Saate isegi luua oma mikroteenuse, mis saadab need andmed http kaudu. Ja ClickHouse'i tasemel kirjutate funktsiooni, mis teisendab need andmed numbritest stringideks.
See on spetsiaalne, kuid väga tõhus viis välise laua ühendamiseks. Ja on kaks võimalust. Ühe võimaluse korral salvestatakse need andmed täielikult vahemällu, need on täielikult RAM-is ja neid värskendatakse teatud ajavahemike järel. Ja teises variandis, kui need andmed RAM-i ei mahu, saate need osaliselt vahemällu salvestada.
Siin on näide. Seal on Yandex.Direct. Ja seal on reklaamifirma ja bännerid. Reklaamifirmasid on ilmselt kümneid miljoneid. Ja mahub umbes RAM-i. Ja bännereid on miljardeid, need ei sobi. Ja me kasutame MySQL-i vahemällu salvestatud sõnastikku.
Ainus probleem on see, et vahemällu salvestatud sõnastik töötab hästi, kui tabamusmäär on 100% lähedal. Kui see on väiksem, siis iga andmepaketi päringute töötlemisel tuleb tegelikult võtta puuduvad võtmed ja minna MySQL-ist andmeid võtma. ClickHouse'i kohta võin siiski garanteerida - jah, see ei aeglusta, ma ei räägi teistest süsteemidest.
Ja boonusena on sõnastikud väga lihtne viis ClickHouse'i andmete tagasiulatuvalt uuendamiseks. See tähendab, et teil oli reklaamiettevõtete aruanne, kasutaja vahetas lihtsalt reklaamiettevõtet ja kõigis vanades andmetes, kõigis aruannetes muutusid ka need andmed. Kui kirjutate read otse tabelisse, ei saa te neid värskendada.
Teine võimalus, kui te ei tea, kust oma stringide identifikaatoreid hankida. sa võid lihtsalt räsida. Ja kõige lihtsam variant on võtta 64-bitine räsi.
Ainus probleem on see, et kui räsi on 64-bitine, on teil peaaegu kindlasti kokkupõrkeid. Sest kui rida on miljard, siis on tõenäosus juba käegakatsutavaks muutumas.
Ja reklaamifirmade nimesid poleks väga hea niimoodi räsida. Kui erinevate firmade reklaamikampaaniad sassi lähevad, siis jääb midagi arusaamatut.
Ja seal on lihtne nipp. Tõsi, tõsiste andmete jaoks see ka väga ei sobi, aga kui miski pole väga tõsine, siis lisa lihtsalt sõnastikuvõtmesse mõni muu kliendi identifikaator. Ja siis on teil kokkupõrkeid, kuid ainult ühe kliendi sees. Ja me kasutame seda meetodit Yandex.Metrica linkide kaardi jaoks. Meil on seal URL-id, me talletame räsi. Ja me teame, et loomulikult on konflikte. Aga kui kuvatakse leht, siis tõenäosus, et ühe kasutaja jaoks on ühel lehel, jäävad mingid URL-id kokku ja seda märgatakse, siis võib selle tähelepanuta jätta.
Boonusena piisab paljude operatsioonide jaoks ainult räsidest ja stringe endid ei saa kuhugi salvestada.
Teine näide, kui stringid on lühikesed, näiteks veebisaidi domeenid. Neid saab säilitada nii, nagu on. Või näiteks brauseri keel ru on 2 baiti. Muidugi on mul kahju baitidest, aga ärge muretsege, 2 baiti pole kahju. Palun hoidke seda nii nagu on, ärge muretsege.
Teine juhtum on see, kui keeli on vastupidi palju ja samas on neis palju unikaalseid ning isegi komplekt on potentsiaalselt piiramatu. Tüüpiline näide on otsingufraasid või URL-id. Otsingufraasid, sealhulgas kirjavigade tõttu. Vaatame, kui palju kordumatuid otsingufraase päevas. Ja selgub, et need on peaaegu pooled kõigist sündmustest. Ja sel juhul võiks mõelda, et tuleb andmed normaliseerida, identifikaatorid kokku lugeda, eraldi tabelisse panna. Aga sa ei pea seda tegema. Jätke need read nii nagu on.
Parem - ärge leiutage midagi, sest kui hoiate seda eraldi, peate tegema liitmise. Ja see liitumine on parimal juhul juhuslik juurdepääs mälule, kui see ikka mällu mahub. Kui see ei sobi, siis on üldiselt probleeme.
Ja kui andmed on paigas, siis loetakse need lihtsalt failisüsteemist õiges järjekorras välja ja kõik on korras.
Kui teil on url-id või mõni muu keeruline pikk string, siis peaksite mõtlema sellele, et saate eelnevalt arvutada mõne pigistuse ja kirjutada selle eraldi veergu.
Näiteks URL-ide jaoks saate domeeni eraldi salvestada. Ja kui teil on tõesti domeeni vaja, kasutage lihtsalt seda veergu ja URL-id valetavad ja te ei puuduta neid isegi.
Vaatame, mis vahe on. ClickHouse'il on spetsiaalne funktsioon, mis arvutab domeeni. See on väga kiire, oleme selle optimeerinud. Ja ausalt öeldes ei vasta see isegi RFC-le, kuid arvestab sellegipoolest kõike, mida me vajame.
Ja ühel juhul saame lihtsalt URL-id ja arvutame domeeni. Selgub 166 millisekundit. Ja kui võtate valmis domeeni, selgub see vaid 67 millisekundit, see tähendab peaaegu kolm korda kiiremini. Ja kiiremini, mitte sellepärast, et peaksime tegema arvutusi, vaid sellepärast, et loeme vähem andmeid.
Millegipärast saab üks päring, mis on aeglasem, suurema kiiruse gigabaitides sekundis. Sest see loeb rohkem gigabaite. Need on täiesti üleliigsed andmed. Tundub, et taotlus töötab kiiremini, kuid selle täitmine võtab kauem aega.
Ja kui vaadata ketta andmemahtu, siis selgub, et URL on 126 megabaiti ja domeen vaid 5 megabaiti. Selgub 25 korda vähem. Päring on siiski vaid 4 korda kiirem. Aga see on sellepärast, et andmed on kuumad. Ja kui oleks külm, oleks see ketta I / O tõttu ilmselt 25 korda kiirem.
Muide, kui hinnata, kui palju on domeen väiksem kui url, siis selgub, et see on umbes 4 korda. Aga millegipärast kulub ketta andmeid 25 korda vähem. Miks? Kompressiooni tõttu. Ja url tihendatakse ja domeen tihendatakse. Kuid sageli sisaldab url hunnikut prügi.
Ja loomulikult tasub kasutada õigeid andmetüüpe, mis on spetsiaalselt loodud õigete väärtuste jaoks või sobivad. Kui kasutate IPv4, salvestage UInt32*. Kui IPv6, siis FixedString(16), sest IPv6 aadress on 128 bitti, st salvestab otse binaarvormingus.
Aga mis siis, kui teil on mõnikord IPv4-aadressid ja mõnikord IPv6-aadressid? Jah, võite mõlemad endale jätta. Üks veerg IPv4 jaoks, teine IPv6 jaoks. Muidugi on võimalus IPv4 vastendada IPv6-ga. See toimib ka, kuid kui vajate oma päringutes sageli IPv4-aadressi, oleks tore see eraldi veergu panna.
* Nüüd on ClickHouse'il eraldi IPv4, IPv6 andmetüübid, mis salvestavad andmeid sama tõhusalt kui numbreid, kuid esitavad neid sama mugavalt kui stringe.
Samuti on oluline märkida, et andmeid tasub eelnevalt töödelda. Näiteks mõned toored palgid tulevad teie juurde. Ja võib-olla ei tohiks te neid kohe ClickHouse'i panna, kuigi on väga ahvatlev mitte midagi teha ja kõik toimib. Kuid siiski tasub teha need arvutused, mis on võimalikud.
Näiteks brauseri versioon. Mõnes naaberosakonnas, millele ma näpuga näidata ei taha, on brauseri versioon sinna salvestatud nii, st stringina: 12.3. Ja siis aruande koostamiseks võtavad nad selle stringi ja jagavad massiiviga ja seejärel massiivi esimese elemendiga. Loomulikult kõik aeglustub. Küsisin, miks nad seda teevad. Nad ütlesid mulle, et neile ei meeldi enneaegne optimeerimine. Ja mulle ei meeldi ennatlik pessimism.
Nii et antud juhul oleks õigem jagada 4 veergu. Ärge kartke siin, sest see on ClickHouse. ClickHouse on veergude andmebaas. Ja mida korralikumad väikesed veerud, seda parem. Seal on 5 BrowserVersion, tehke 5 veergu. See sobib.
Nüüd mõelge, mida teha, kui teil on palju väga pikki stringe, väga pikki massiive. Neid ei pea üldse ClickHouse'is salvestama. Selle asemel saate ClickHouse'i salvestada ainult mõne identifikaatori. Ja need pikad järjekorrad suruvad nad mingisse teise süsteemi.
Näiteks ühel meie analüüsiteenusel on mõned sündmuste parameetrid. Ja kui sündmustele tuleb palju parameetreid, salvestame lihtsalt esimesed ettetulevad 512. Sest 512 pole kahju.
Ja kui te ei saa otsustada oma andmetüüpide üle, saate andmed kirjutada ka ClickHouse'i, kuid logi tüüpi ajutisse tabelisse, mis on ajutiste andmete jaoks spetsiaalne. Pärast seda saate analüüsida, milline väärtuste jaotus teil seal on, mis seal üldiselt on ja moodustada õiged tüübid.
* Nüüd on ClickHouse'il andmetüüp mis võimaldab vähema vaevaga stringe tõhusalt salvestada.
Mõelge nüüd veel ühele huvitavale juhtumile. Mõnikord toimivad asjad inimeste jaoks veidral viisil. Ma lähen ja vaatan seda. Ja kohe tundub, et seda tegi mõni väga kogenud ja tark administraator, kellel on laialdased kogemused MySQL versiooni 3.23 seadistamisel.
Siin näeme tuhat tabelit, millest igaüks sisaldab ülejäänud osa jagades pole selge, mida tuhandega.
Põhimõtteliselt austan teiste inimeste kogemusi, sealhulgas mõistmist, milliseid kannatusi see kogemus võib saada.
Ja põhjused on enam-vähem selged. Need on vanad stereotüübid, mis võivad olla kogunenud teiste süsteemidega töötades. Näiteks ei ole MyISAM-i tabelitel rühmitatud primaarvõtit. Ja selline andmete jagamise viis võib olla meeleheitlik katse sama funktsiooni hankimiseks.
Teine põhjus on see, et suurtes laudades on raske teha muudatusi. Kõik blokeeritakse. Kuigi MySQL-i kaasaegsetes versioonides pole see probleem enam nii tõsine.
Või näiteks microsharding, aga sellest hiljem.
ClickHouse'is ei pea te seda tegema, sest esiteks on primaarvõti rühmitatud, andmed on järjestatud primaarvõtme järgi.
Ja mõnikord küsivad inimesed minult: "Kuidas muutub ClickHouse'i vahemikupäringute toimivus tabeli suurusega?". Ma ütlen, et see ei muutu üldse. Näiteks on teil tabel miljardi reaga ja te loete ühe miljoni rea vahemikku. Kõik on korras. Kui tabelis on triljon rida ja te loete miljon rida, siis on see peaaegu sama.
Ja teiseks ei ole vaja selliseid detaile nagu käsitsi vaheseinad. Kui lähete sisse ja vaatate, mis failisüsteemis on, näete, et tabel on üsna tõsine asi. Ja seal sees on midagi vaheseinte taolist. See tähendab, et ClickHouse teeb kõik teie eest ja te ei pea kannatama.
Muutmine ClickHouse'is on tasuta, kui muuda lisamise/kukkumise veergu.
Ja väikseid tabeleid ei tohiks teha, sest kui su tabelis on 10 rida või 10 000 rida, siis pole sellel üldse tähtsust. ClickHouse on süsteem, mis optimeerib läbilaskevõimet, mitte latentsust, seega pole mõtet 10 rida töödelda.
Õige on kasutada ühte suurt lauda. Vabanege vanadest stereotüüpidest, kõik saab korda.
Ja boonusena on meil viimases versioonis võimalus teha suvaline partitsioonivõti, et teha üksikutel sektsioonidel kõikvõimalikke hooldustoiminguid.
Näiteks vajate palju väikeseid tabeleid, näiteks kui on vaja töödelda mingeid vaheandmeid, saate tükid ja peate nendes enne lõpptabelisse kirjutamist tegema teisenduse. Selleks puhuks on suurepärane lauamootor - StripeLog. See on nagu TinyLog, ainult parem.
* Nüüd on ClickHouse'il rohkem .
Teine antimuster on mikrokillustumine. Näiteks peate andmeid killustama ja teil on 5 serverit ja homme on 6 serverit. Ja mõtlete, kuidas need andmed uuesti tasakaalustada. Ja selle asemel ei jaga te mitte 5 killuks, vaid 1 killuks. Ja siis kaardistate kõik need mikrokillud eraldi serverisse. Ja sa saad hakkama ühes serveris, näiteks 000 ClickHouse'is. Eraldi eksemplar eraldi portides või eraldi andmebaasides.
Kuid ClickHouse'is pole see eriti hea. Sest isegi üks ClickHouse'i eksemplar püüab ühe päringu töötlemiseks kasutada kõiki saadaolevaid serveriressursse. See tähendab, et teil on mingi server ja seal on näiteks 56 protsessori tuuma. Käitate päringu, mis võtab ühe sekundi ja kasutab 56 tuuma. Ja kui panid sinna ühte serverisse 200 ClickHouse'i, siis selgub, et algab 10 000 lõime. Üldiselt läheb kõik väga halvasti.
Teine põhjus on see, et töö jaotus nende juhtumite vahel on ebaühtlane. Mõni lõpetab varem, mõni hiljem. Kui see kõik juhtuks ühel juhul, oleks ClickHouse ise välja mõelnud, kuidas andmeid voogude vahel õigesti jaotada.
Ja teine põhjus on see, et teil on protsessoritevaheline suhtlus TCP kaudu. Andmed tuleb serialiseerida, deserialiseerida ja see on tohutu hulk mikrokilde. See lihtsalt ei tööta.
Veel üks antimuster, kuigi vaevalt saab seda antimustriks nimetada. See on suur hulk eelliitmist.
Üldiselt on eelliitmine hea. Teil oli miljard rida, agregeerisite selle ja sellest sai 1 rida ning nüüd täidetakse päring koheselt. Kõik on hästi. Nii saate seda teha. Ja selleks on isegi ClickHouse'il spetsiaalne AggregatingMergeTree tabelitüüp, mis teeb andmete sisestamisel järkjärgulist liitmist.
Kuid mõnikord arvate, et koondame selliseid andmeid ja koondame selliseid andmeid. Ja mõnes naaberosakonnas ei taha ma ka öelda, millises, nad kasutavad primaarvõtme alusel summeerimiseks SummingMergeTree tabeleid ja primaarvõtmena kasutatakse 20 veergu. Igaks juhuks muutsin vandenõu mõttes mõne veeru nimed ära, aga see selleks.
Ja sellised probleemid tekivad. Esiteks ei vähendata teie andmete hulka liiga palju. Näiteks vähendatakse seda kolm korda. Kolm korda oleks hea hind, et lubada endale piiramatut analüütikat, mis kaasneb koondamata andmetega. Kui andmed on koondatud, saate analüütika asemel ainult viletsa statistika.
Ja mis on eriti hea? Et need järgmise osakonna inimesed läheksid ja paluksid vahel lisada primaarvõtmesse veel üks veerg. See tähendab, et oleme andmed niimoodi koondanud ja nüüd tahame natuke rohkem. Kuid ClickHouse'is pole muud primaarvõtit. Seetõttu peate kirjutama mõned skriptid C ++ keeles. Ja mulle ei meeldi skriptid, isegi kui need on C++ keeles.
Ja kui vaadata, milleks ClickHouse loodi, siis agregeerimata andmed on just see stsenaarium, mille jaoks need sündisid. Kui kasutate ClickHouse'i koondamata andmete jaoks, siis teete kõik õigesti. Kui koondate, on see mõnikord andestatav.
Veel üks huvitav juhtum on päringud lõpmatus tsüklis. Mõnikord lähen mõne tootmisserveri juurde ja vaatan sealset show processlisti. Ja iga kord avastan, et midagi kohutavat on juhtumas.
Näiteks siin on see. Kohe on selge, et ühe palvega oli võimalik kõik ära teha. Lihtsalt kirjutage url ja loend sinna.
Miks on paljud sellised lõpmatus tsüklis olevad taotlused halvad? Kui indeksit ei kasutata, on teil samade andmete üle mitu korda. Aga kui kasutatakse näiteks indeksit, siis sul on ru peal primaarvõti ja sa kirjutad sinna url = midagi. Ja sa arvad, et üks url loetakse tabelist punktlikult välja, siis on kõik korras. Aga tõesti ei. Sest ClickHouse teeb kõike partiidena.
Kui tal on vaja lugeda mõningaid andmeid, loeb ta natuke rohkem, sest ClickHouse'i indeks on hõre. See indeks ei võimalda tabelist leida ühte üksikut rida, vaid ainult mingit vahemikku. Ja andmed tihendatakse plokkideks. Ühe rea lugemiseks peate võtma kogu ploki ja lahti pakkima. Ja kui käivitate hulga päringuid, on teil palju nende ristumiskohti ja teil on ikka ja jälle palju tööd.
Ja boonusena näete, et ClickHouse'is ei tohiks te karta isegi megabaite ja isegi sadu megabaite IN sektsiooni üle kanda. Mäletan oma praktikast, et kui edastame näiteks MySQL-i jaotises IN hunniku väärtusi, edastame seal mõnda numbrit 100 megabaiti, siis MySQL sööb 10 gigabaiti mälu ja muud ei juhtu. see, kõik töötab halvasti.
Ja teine asi on see, et ClickHouse'is, kui teie päringud kasutavad indeksit, ei ole see alati aeglasem kui täielik kontroll, st kui teil on vaja lugeda peaaegu kogu tabel, läheb see järjestikku ja loeb kogu tabelit. Üldiselt saab ta selle välja.
Siiski on mõningaid raskusi. Näiteks see IN koos alampäringuga ei kasuta indeksit. Kuid see on meie probleem ja me peame selle parandama. Siin pole midagi põhimõttelist. Teeme seda*.
Ja veel üks huvitav asi on see, et kui teil on väga pikk päring ja hajutatud päringu töötlemine toimub, siis see väga pikk päring saadetakse igasse serverisse ilma tihendamiseta. Näiteks 100 megabaiti ja 500 serverit. Ja vastavalt sellele kantakse üle võrgu 50 gigabaiti. See kantakse üle ja siis on kõik edukalt täidetud.
* juba kasutusel; kõik sai korda nagu lubatud.
Ja see on üsna tavaline, kui päringud tulevad API-st. Näiteks olete teinud mingi teenuse. Ja kui keegi vajab teie teenust, siis avasite API ja sõna otseses mõttes kaks päeva hiljem näete, et toimub midagi arusaamatut. Kõik on ülekoormatud ja tulevad kohutavad taotlused, mida poleks tohtinud olla.
Ja lahendusi on ainult üks. Kui olete API avanud, peate selle lõikama. Näiteks mõne kvoodi sisestamiseks. Muid mõistlikke variante pole. Vastasel juhul kirjutavad nad kohe stsenaariumi ja tekivad probleemid.
Ja ClickHouse'il on eriline funktsioon - see on kvootide arvutamine. Lisaks saate oma kvoodivõtme üle kanda. See on näiteks sisemine kasutaja ID. Ja kvoodid arvutatakse igaühe jaoks eraldi.
Nüüd veel üks huvitav asi. See on käsitsi paljundamine.
Tean palju juhtumeid, kus vaatamata ClickHouse'ile sisseehitatud replikatsioonitoega kopeerivad inimesed ClickHouse'i käsitsi.
Mis on põhimõte? Teil on andmetöötluskonveier. Ja see töötab iseseisvalt näiteks erinevates andmekeskustes. Sa kirjutad samad andmed samamoodi ClickHouse'i justkui. Tõsi, praktika näitab, et teie koodi teatud iseärasuste tõttu andmed siiski lahknevad. Loodan, et teie oma.
Ja perioodiliselt peate ikkagi käsitsi sünkroonima. Näiteks kord kuus teevad administraatorid rsynci.
Tegelikult on ClickHouse'i sisseehitatud replikatsiooni kasutamine palju lihtsam. Kuid sellel võib olla vastunäidustusi, sest selleks peate kasutama ZooKeeperit. Ma ei ütle ZooKeeperi kohta midagi halba, põhimõtteliselt süsteem töötab, aga juhtub, et inimesed ei kasuta seda java-foobia tõttu, kuna ClickHouse on nii hea C ++ keeles kirjutatud süsteem, mida saate kasutada ja kõik saab korda. Ja ZooKeeper javas. Ja millegipärast ei taha te isegi vaadata, kuid siis saate kasutada käsitsi paljundamist.
ClickHouse on praktiline süsteem. See võtab arvesse teie vajadusi. Kui teil on käsitsi paljundamine, saate luua hajutatud tabeli, mis vaatab teie käsitsi koopiaid ja teeb nende vahel tõrkesiirde. Ja seal on isegi spetsiaalne võimalus, mis võimaldab teil vältida floppe, isegi kui teie read on süstemaatiliselt erinevad.
Lisaks võib primitiivsete tabelimootorite kasutamisel tekkida probleeme. ClickHouse on selline konstruktor, millel on hunnik erinevaid tabelimootoreid. Kõigi tõsiste juhtumite puhul, nagu dokumentatsioonis kirjas, kasutage MergeTree perekonna tabeleid. Ja kõik ülejäänud - see on nii üksikjuhtumite või testide jaoks.
MergeTree tabelis ei pea teil olema kuupäeva ja kellaaega. Võite endiselt kasutada. Kui kuupäeva ja kellaaega pole, kirjutage, et vaikimisi on 2000. See toimib ja ei nõua ressursse.
Ja serveri uues versioonis saate isegi määrata, et teil on kohandatud partitsioonid ilma partitsioonivõtmeta. See saab olema sama.
Teisest küljest võib kasutada primitiivseid lauamootoreid. Näiteks täitke andmed üks kord ja vaadake, keerake ja kustutage. Saate kasutada Logi.
Või väikeste mahtude salvestamine vahepealseks töötlemiseks on StripeLog või TinyLog.
Mälu saab kasutada, kui andmeid on vähe ja RAM-is lihtsalt midagi keerata.
ClickHouse'ile ei meeldi väga ümbernormeeritud andmed.
Siin on tüüpiline näide. See on tohutu hulk URL-e. Paned need kõrvalolevasse tabelisse. Ja siis otsustasime nendega JOIN-i teha, kuid see reeglina ei tööta, kuna ClickHouse toetab ainult Hash JOIN-i. Kui ühenduse loomiseks pole paljude andmete jaoks piisavalt RAM-i, siis JOIN ei tööta *.
Kui andmed on suure kardinaalsusega, siis ärge muretsege, salvestage need denormaliseeritud kujul, URL-id on põhitabelis otse paigas.
* ja nüüd on ClickHouse'il ka liitmine ja see töötab tingimustes, kus vaheandmed ei mahu RAM-i. Kuid see on ebaefektiivne ja soovitus jääb kehtima.
Paar näidet veel, aga ma juba kahtlen, kas need on mustritevastased või mitte.
ClickHouse'il on üks teadaolev puudus. Ta ei tea, kuidas * värskendada. Mõnes mõttes on see isegi hea. Kui teil on mõned olulised andmed, näiteks raamatupidamine, siis ei saa keegi neid saata, kuna värskendusi pole.
* Pakettrežiimis värskendamise ja kustutamise tugi on juba ammu lisatud.
Kuid on mõned eriviisid, mis võimaldavad värskendusi taustal kuvada. Näiteks ReplaceMergeTree tüüpi tabelid. Nad värskendavad taustal liitmise ajal. Saate seda sundida optimeerimistabeli abil. Kuid ärge tehke seda liiga sageli, sest see kirjutab partitsiooni täielikult üle.
Jaotatud JOIN-id ClickHouse'is – ka sellega tegeleb päringuplaneerija halvasti.
Halb, aga mõnikord OK.
ClickHouse'i kasutamine lihtsalt andmete lugemiseks valikuga*.
Ma ei soovitaks kasutada ClickHouse'i mahukate arvutuste jaoks. Kuid see pole täiesti tõsi, sest me oleme sellest soovitusest juba eemaldumas. Ja hiljuti lisasime ClickHouse'is Catboostis masinõppemudelite rakendamise võimaluse. Ja see teeb mulle muret, sest ma mõtlen: “Milline õudus. Nii palju tsükleid baidi kohta selgub! Mul on kahju baitidel kellatsükleid käivitada.
Kuid ärge kartke, installige ClickHouse, kõik saab korda. Kui midagi, siis meil on kogukond. Muide, kogukond olete teie. Ja kui teil on probleeme, võite minna vähemalt meie vestlusesse ja ma loodan, et teid aidatakse.
küsimused
Täname raporti eest! Kuhu ClickHouse'i krahhi üle kaevata?
Võite praegu kaevata mulle isiklikult.
Hakkasin hiljuti kasutama ClickHouse'i. Lõpetas kohe kliliidese.
Milline skoor.
Veidi hiljem viskasin serveri väikese valikuga maha.
Sul on annet.
Avasin GitHubi vea, kuid seda eirati.
Eks me näe.
Aleksey meelitas mind raportis osalema, lubades mulle öelda, kuidas te andmeid sees pigistate.
Väga lihtne.
Seda ma eile taipasin. Täpsemalt.
Hirmsaid trikke pole. See on lihtsalt ploki kaupa tihendamine. Vaikimisi on LZ4, saate lubada ZSTD*. Blokeerib 64 kilobaidist 1 megabaidini.
* Toetatakse ka spetsiaalseid tihenduskoodekeid, mida saab kasutada ahelas teiste algoritmidega.
Kas plokid on ainult töötlemata andmed?
Mitte just toores. Seal on massiivid. Kui teil on numbriline veerg, on rea numbrid virnastatud massiivi.
See on selge.
Aleksei, näide, mis oli seotud uniqExactiga üle IP-de, st asjaolu, et uniqExacti loendamine stringide järgi võtab rohkem aega kui numbrite järgi jne. Mis siis, kui me teeme oma kõrvadega pettust ja paneme korrektuuri hetkel sisse? See tähendab, et näib olevat öelnud, et see ei erine kettal palju. Kui loeme kettalt ridu, valame, siis kas saame agregaadid kiiremini või mitte? Või võidame siin siiski marginaalselt? Mulle tundub, et sa testisid seda, kuid mingil põhjusel ei märkinud seda võrdlusaluses.
Ma arvan, et see on aeglasem kui ilma castideta. Sel juhul tuleb IP-aadress stringist sõeluda. Loomulikult on ClickHouse'is optimeeritud ka IP-aadressi parsimine. Püüdsime väga, aga samas kohas on teil numbrid kümnetuhandikes kirjutatud. Väga ebamugav. Teisest küljest töötab funktsioon uniqExact stringide puhul aeglasemalt, mitte ainult seetõttu, et need on stringid, vaid ka seetõttu, et valitud on erinev algoritmi spetsialiseerumine. Stringe lihtsalt käsitletakse erinevalt.
Ja kui me võtame primitiivsema andmetüübi? Näiteks kirjutasid nad üles kasutaja ID, mis meil sees on, kirjutasid selle reana üles ja siis viskasid, kas on lõbusam või mitte?
Ma kahtlen. Ma arvan, et see on veelgi kurvem, sest lõppude lõpuks on numbrite sõelumine tõsine probleem. Mulle tundub, et sellel kolleegil oli isegi aruanne selle kohta, kui raske on numbreid kümnetuhandikes sõeluda, aga võib-olla mitte.
Aleksei, tänan teid väga raporti eest! Ja suur tänu ClickHouse'i eest! Mul on küsimus plaanide kohta. Kas sõnaraamatute uuendamise plaanides on funktsioon puudulik?
st osaline taaskäivitamine?
Jah Jah. Nagu võimalus seada sinna MySQL-i väli, st värskendada pärast nii, et laaditakse ainult need andmed, kui sõnastik on väga suur.
Väga huvitav funktsioon. Ja mulle tundub, et keegi soovitas seda meie vestluses. Võib-olla oli see isegi sina.
Ma ei usu.
Suurepärane, nüüd selgus, et kaks taotlust. Ja võite hakata seda aeglaselt tegema. Kuid ma tahan teid kohe hoiatada, et seda funktsiooni on üsna lihtne rakendada. See tähendab, et teoreetiliselt peate lihtsalt tabelisse kirjutama versiooni numbri ja seejärel kirjutama: versioon on väiksem kui selline ja selline. Ja see tähendab, et suure tõenäosusega pakume seda entusiastidele. Kas olete entusiast?
Jah, kuid kahjuks mitte C++ keeles.
Kas teie kolleegid oskavad C++ keeles kirjutada?
Ma leian kellegi.
Suurepärane*.
* funktsioon lisati kaks kuud pärast aruannet – selle töötas välja küsimuse autor ja esitas tema .
Tänan!
Tere! Täname raporti eest! Mainisite, et ClickHouse kulutab väga hästi ära kõik tema käsutuses olevad ressursid. Ja Luxofti kõrval esineja rääkis oma otsusest Vene Posti jaoks. Ta ütles, et ClickHouse meeldis neile väga, kuid nad ei kasutanud seda oma peamise konkurendi asemel just seetõttu, et see sõi ära kogu protsessori. Ja nad ei suutnud seda oma arhitektuuri, dokkijatega ZooKeeperisse sobitada. Kas ClickHouse'i on võimalik kuidagi piirata nii, et see ei tarbiks kõike, mis talle kättesaadavaks saab?
Jah, see on võimalik ja väga lihtne. Kui tahad vähem südamikke tarbida, siis lihtsalt kirjuta set max_threads = 1. Ja see on kõik, see täidab päringu ühes tuumas. Lisaks saate erinevatele kasutajatele määrata erinevaid seadeid. Nii et pole probleemi. Ja öelge oma kolleegidele Luxoftist, et pole hea, et nad seda seadet dokumentatsioonist ei leidnud.
Aleksei, tere! Tahaksin esitada selle küsimuse. See pole esimene kord, kui kuulen, et paljud inimesed hakkavad ClickHouse'i logide hoidlana kasutama. Aruandes ütlesite, et ärge seda tehke, st te ei pea pikki ridu hoidma. Mis sa sellest arvad?
Esiteks ei ole palgid tavaliselt pikad read. Muidugi on ka erandeid. Näiteks mõni javas kirjutatud teenus teeb erandi, see logitakse. Ja nii lõputu tsükliga ja kõvakettaruum hakkab otsa saama. Lahendus on väga lihtne. Kui jooned on väga pikad, siis lõigake need ära. Mida tähendab pikk? Kümned kilobaidid on halb *.
* ClickHouse'i viimastes versioonides on "adaptiivne indeksi granulaarsus" lubatud, mis eemaldab suures osas pikkade stringide salvestamise probleemi.
Kas kilobait on normaalne?
See on normaalne.
Tere! Täname raporti eest! Küsisin selle kohta juba vestluses, kuid ma ei mäleta, kas sain vastuse. Kas on plaanis WITH-i sektsiooni CTE-viisiliselt laiendada?
Mitte veel. JAOTIS KOOS on mõnevõrra kergemeelne. See on meie jaoks nagu väike funktsioon.
ma saan aru. Aitäh!
Täname raporti eest! Väga huvitav! globaalne küsimus. Kas on plaanis teha, võib-olla mingite stubide näol, andmete kustutamise muutmist?
Tingimata. See on meie järjekorras esimene ülesanne. Nüüd mõtleme aktiivselt, kuidas kõike õigesti teha. Ja peaksite hakkama klaviatuuri vajutama*.
* vajutasin klaviatuuri nuppe ja kõik oli tehtud.
Kas see mõjutab kuidagi süsteemi jõudlust või mitte? Kas sisestus on sama kiire kui praegu?
Võib-olla on kustutamised ise, värskendused ise väga rasked, kuid see ei mõjuta mingil viisil valikute ja lisade jõudlust.
Ja veel üks väike küsimus. Esitlusel rääkisite primaarvõtmest. Sellest lähtuvalt on meil partitsioonid, mis on vaikimisi igakuised, eks? Ja kui me määrame kuupäevavahemiku, mis mahub kuu sisse, siis loeme ainult seda partitsiooni, eks?
Jah.
Küsimus. Kui me ei saa valida ühtegi primaarvõtit, siis kas on õige teha seda täpselt välja “Kuupäev” järgi, et taustal toimuks nende andmete väiksem ümberstruktureerimine, et need paremini sobituksid? Kui teil pole vahemiku päringuid ja te ei saa isegi primaarvõtit valida, kas tasub primaarvõtmesse kuupäeva panna?
Jah.
Võib-olla on mõttekas panna primaarvõtmesse väli, mille järgi on andmed paremini kokku surutud, kui need on selle välja järgi sorteeritud. Näiteks kasutaja ID. Näiteks kasutaja läheb samale saidile. Sel juhul sisestage kasutaja ID ja kellaaeg. Ja siis on teie andmed paremini tihendatud. Mis puutub kuupäeva, siis kui teil tõesti ei ole ega ole kunagi kuupäevade vahemiku päringuid, ei saa te kuupäeva primaarvõtmesse panna.
OK tänan teid väga!
Allikas: www.habr.com