Ker je ClickHouse specializiran sistem, je pri njegovi uporabi pomembno upoštevati značilnosti njegove arhitekture. V tem poročilu bo Alexey govoril o primerih pogostih napak pri uporabi ClickHouse, ki lahko vodijo do neučinkovitega dela. Praktični primeri bodo pokazali, kako lahko izbira ene ali druge sheme obdelave podatkov spremeni zmogljivost za velikostne rede.
Pozdravljeni vsi skupaj! Moje ime je Alexey, izdelujem ClickHouse.
Prvič, hitim, da vas prosim takoj, danes vam ne bom povedal, kaj je ClickHouse. Če sem iskren, sem tega naveličan. Vsakič ti povem, kaj je. In verjetno že vsi vedo.
Namesto tega vam bom povedal, katere možne napake so, torej kako lahko ClickHouse uporabljate nepravilno. Pravzaprav se ni treba bati, saj ClickHouse razvijamo kot sistem, ki je preprost, priročen in deluje takoj. Inštaliral sem, brez težav.
Vendar morate še vedno upoštevati, da je ta sistem specializiran in zlahka naletite na nenavaden primer uporabe, ki bo ta sistem popeljal iz cone udobja.
Kakšne grablje torej obstajajo? Večinoma bom govoril o očitnih stvareh. Vsem je vse jasno, vsi vse razumejo in so lahko veseli, da so tako pametni, tisti, ki ne razumejo, pa se bodo kaj novega naučili.
Prvi in najenostavnejši primer, ki se na žalost pogosto pojavlja, je veliko število vložkov z majhnimi serijami, torej veliko število majhnih vložkov.
Če upoštevamo, kako ClickHouse izvaja vstavljanje, potem lahko v eni zahtevi pošljete vsaj terabajt podatkov. To ni problem.
In poglejmo, kakšna bi bila tipična uspešnost. Na primer, imamo tabelo iz podatkov Yandex.Metrica. Zadetki. 105 nekaj stolpcev. 700 bajtov nestisnjenih. In vstavili bomo na dober način v serijah po milijon vrstic.
V tabelo vstavimo MergeTree, izkaže se pol milijona vrstic na sekundo. Super. V replicirani tabeli bo nekoliko manjši, približno 400 vrstic na sekundo.
In če omogočite vstavljanje kvoruma, dobite malo manjšo, a še vedno spodobno zmogljivost, 250 členov na sekundo. Vstavljanje kvoruma je nedokumentirana funkcija v ClickHouse*.
* od leta 2020, .
Kaj se zgodi, če narediš nekaj slabega? V tabelo MergeTree vstavimo eno vrstico in dobimo 59 vrstic na sekundo. To je 10-krat počasneje. V ReplicatedMergeTree – 000 vrstic na sekundo. In če je kvorum vklopljen, se izkaže 6 vrstici na sekundo. Po mojem mnenju je to nekakšna absolutna bedarija. Kako lahko tako upočasniš? Na majici imam celo napisano, da ClickHouse ne sme upočasniti. Ampak kljub temu se včasih zgodi.
Pravzaprav je to naša pomanjkljivost. Z lahkoto bi lahko uredili, da bi vse dobro delovalo, a nam ni uspelo. In tega nismo storili, ker naš scenarij tega ni zahteval. Butče smo že imeli. Pravkar smo prejeli serije na našem vhodu in brez težav. Vstavimo ga in vse deluje v redu. Možni pa so seveda najrazličnejši scenariji. Na primer, ko imate kup strežnikov, na katerih se generirajo podatki. In podatkov ne vstavljajo tako pogosto, a vseeno na koncu pridejo do pogostih vstavkov. In temu se moramo nekako izogniti.
S tehničnega vidika je bistvo, da ko naredite vstavljanje v ClickHouse, podatki ne končajo v nobeni memtable. Niti nimamo prave strukture dnevnika MergeTree, ampak samo MergeTree, ker ni niti dnevnika niti memTable. Podatke preprosto takoj zapišemo v datotečni sistem, že urejene v stolpce. In če imate 100 stolpcev, bo treba več kot 200 datotek zapisati v ločen imenik. Vse to je zelo okorno.
In postavlja se vprašanje: "Kako to narediti prav?" Če je situacija taka, da morate še vedno nekako beležiti podatke v ClickHouse.
Metoda 1. To je najlažji način. Uporabite nekakšno porazdeljeno čakalno vrsto. Na primer Kafka. Preprosto izvlečete podatke iz Kafke in jih enkrat na sekundo serirate. In vse bo v redu, posnemite, vse deluje v redu.
Slabosti so, da je Kafka še en zajeten porazdeljen sistem. Razumem tudi, če Kafko že imate v podjetju. Dobro je, priročno je. Če pa ne obstaja, potem morate trikrat premisliti, preden v svoj projekt vlečete še en porazdeljen sistem. In zato je vredno razmisliti o alternativah.
Metoda 2. To je alternativa stare šole in hkrati zelo preprosta. Ali imate kakšen strežnik, ki ustvarja vaše dnevnike. In samo zapiše vaše dnevnike v datoteko. In enkrat na sekundo, na primer, preimenujemo to datoteko in odtrgamo novo. In ločen skript, bodisi prek crona ali kakšnega demona, vzame najstarejšo datoteko in jo zapiše v ClickHouse. Če zapisujete dnevnike enkrat na sekundo, bo vse v redu.
Toda slabost tega načina je, da če vaš strežnik, na katerem se generirajo dnevniki, nekje izgine, potem bodo izginili tudi podatki.
Metoda 3. Obstaja še ena zanimiva metoda, ki sploh ne zahteva začasnih datotek. Na primer, imate nekakšen oglaševalski spinner ali kakšen drug zanimiv demon, ki ustvarja podatke. In kup podatkov lahko kopičite neposredno v RAM-u, v medpomnilniku. In ko mine dovolj časa, ta medpomnilnik odložiš, ustvariš novega in v ločeni niti vstaviš, kar se je že nabralo v ClickHouse.
Po drugi strani pa podatki izginejo tudi s kill -9. Če se vaš strežnik zruši, boste izgubili te podatke. In še ena težava je, da če niste mogli pisati v bazo podatkov, se bodo vaši podatki kopičili v RAM-u. In bodisi bo zmanjkalo RAM-a ali pa boste preprosto izgubili podatke.
Metoda 4. Še ena zanimiva metoda. Ali imate kakšen strežniški proces. Podatke lahko pošlje ClickHouse takoj, vendar to stori v eni povezavi. Na primer, poslal sem zahtevo http s kodiranjem prenosa: razdeljeno na kose z vstavitvijo. In ne preredko ustvarja kose, lahko pošljete vsako vrstico, čeprav bodo stroški za uokvirjanje teh podatkov.
Vendar bodo v tem primeru podatki takoj poslani podjetju ClickHouse. In ClickHouse jih bo sam medpomnil.
Pojavijo pa se tudi težave. Zdaj boste izgubili podatke, vključno s tem, ko je vaš proces uničen in če je ukinjen proces ClickHouse, ker bo to nepopoln vstavek. In v ClickHouse so vstavki atomični do določenega podanega praga v velikosti vrstic. Načeloma je to zanimiv način. Lahko se tudi uporablja.
Metoda 5. Tukaj je še ena zanimiva metoda. To je nekakšen strežnik, ki ga je razvila skupnost za pakiranje podatkov. Sam je nisem gledal, tako da ne morem ničesar zagotoviti. Vendar za ClickHouse ni zagotovljenih nobenih jamstev. Tudi to je odprtokodno, po drugi strani pa ste morda navajeni nekega standarda kakovosti, ki ga poskušamo zagotoviti. Toda za to stvar - ne vem, pojdite na GitHub, poglejte kodo. Mogoče so napisali kaj normalnega.
* od leta 2020 je treba upoštevati tudi .
Metoda 6. Druga metoda je uporaba medpomnilniških tabel. Prednost te metode je, da jo je zelo enostavno začeti uporabljati. Ustvarite medpomnilniško tabelo in jo vstavite vanjo.
Pomanjkljivost je, da problem ni popolnoma rešen. Če morate pri hitrosti, kot je MergeTree, grupirati podatke po enem paketu na sekundo, potem morate pri hitrosti v vmesni tabeli grupirati vsaj do nekaj tisoč podatkov na sekundo. Če bo več kot 10 na sekundo, bo še vedno slabo. In če ga vstavite v serijah, ste videli, da se izkaže za sto tisoč vrstic na sekundo. In to je že na precej težkih podatkih.
In tudi vmesne tabele nimajo dnevnika. In če je kaj narobe z vašim strežnikom, bodo podatki izgubljeni.
In kot bonus smo pred kratkim pri ClickHouse dobili priložnost pridobiti podatke iz Kafke. Obstaja namizni motor - Kafka. Enostavno ustvarjate. In nanj lahko obesite materializirane predstavitve. V tem primeru bo sama izluščila podatke iz Kafke in jih vstavila v tabele, ki jih potrebujete.
In kar je pri tej priložnosti še posebej razveseljivo, je, da tega nismo storili mi. To je funkcija skupnosti. In ko rečem »funkcija skupnosti«, to mislim brez prezira. Prebrali smo kodo, pregledali, mora delovati v redu.
* od leta 2020 se je pojavila podobna podpora za .
Kaj bi še lahko bilo neprijetno ali nepričakovano pri vnašanju podatkov? Če naredite zahtevo za vstavljanje vrednosti in napišete nekaj izračunanih izrazov v vrednosti. Na primer, now() je prav tako izračunan izraz. In v tem primeru je ClickHouse prisiljen zagnati tolmača teh izrazov v vsaki vrstici in zmogljivost se bo zmanjšala za stopnje velikosti. Temu se je bolje izogniti.
* trenutno je težava popolnoma odpravljena, pri uporabi izrazov v VALUES ni več nobene regresije zmogljivosti.
Drug primer je, ko lahko pride do težav, ko imate podatke v enem paketu, ki pripada množici particij. Particije ClickHouse so privzeto razvrščene po mesecih. In če vstavite serijo milijona vrstic in obstajajo podatki za več let, potem boste tam imeli več deset particij. In to je enakovredno dejstvu, da bodo serije nekaj desetkrat manjše, ker so znotraj vedno najprej razdeljene na particije.
* Pred kratkim je ClickHouse v poskusnem načinu dodal podporo za kompaktno obliko kosov in kosov v RAM-u z dnevnikom pisanja vnaprej, kar skoraj v celoti reši težavo.
Zdaj pa poglejmo drugo vrsto težave - tipkanje podatkov.
Tipkanje podatkov je lahko strogo ali nizovno. Niz je, ko ste ga pravkar vzeli in izjavili, da so vsa vaša polja vrste niz. To je zanič. Tega ni treba storiti.
Ugotovimo, kako to narediti pravilno v tistih primerih, ko želite reči, da imamo neko polje, niz, in pustite, da ClickHouse to ugotovi sam, jaz pa se ne bom trudil. A vseeno se je vredno potruditi.
Na primer, imamo naslov IP. V enem primeru smo ga shranili kot niz. Na primer 192.168.1.1. In v drugem primeru bo to številka tipa UInt32*. Za naslov IPv32 zadostuje 4 bitov.
Prvič, nenavadno bodo podatki stisnjeni približno enako. Razlika seveda bo, a ne tako velika. Z diskovnim V/I torej ni posebnih težav.
Obstaja pa resna razlika v procesorskem času in času izvajanja poizvedbe.
Preštejmo število edinstvenih naslovov IP, če so shranjeni kot številke. To pomeni 137 milijonov vrstic na sekundo. Če je isto v obliki nizov, potem 37 milijonov vrstic na sekundo. Ne vem, zakaj je prišlo do tega naključja. Sam sem izpolnil te zahteve. Ampak še vedno približno 4-krat počasneje.
In če izračunate razliko v prostoru na disku, potem je tudi razlika. In razlika je približno ena četrtina, ker je unikatnih naslovov IP kar veliko. In če bi obstajale vrstice z majhnim številom različnih pomenov, bi jih zlahka stisnili glede na slovar v približno enak obseg.
In štirikratna časovna razlika ne leži na cesti. Mogoče ti je seveda vseeno, a ko vidim takšno razliko, mi postane hudo.
Poglejmo različne primere.
1. En primer, ko imate nekaj različnih edinstvenih vrednosti. V tem primeru uporabljamo preprosto prakso, ki jo verjetno poznate in jo lahko uporabite za kateri koli DBMS. Vse to ni smiselno le za ClickHouse. Samo zapišite številske identifikatorje v bazo podatkov. Na strani aplikacije lahko pretvorite v nize in nazaj.
Na primer, imate regijo. In poskušate ga shraniti kot niz. In tam bo zapisano: Moskva in Moskovska regija. In ko vidim, da piše Moskva, ni nič, ko pa je Moskva, postane nekako čisto žalostno. To je koliko bajtov.
Namesto tega preprosto zapišemo številko Ulnt32 in 250. V Yandexu imamo 250, vendar je vaša morda drugačna. Za vsak slučaj bom rekel, da ima ClickHouse vgrajeno možnost dela z geobazo. Preprosto zapišete imenik z regijami, vključno s hierarhično, tj. Moskva, Moskovska regija in vse, kar potrebujete. In lahko pretvorite na ravni zahteve.
Druga možnost je približno enaka, vendar s podporo znotraj ClickHouse. To je podatkovni tip Enum. Preprosto napišete vse vrednosti, ki jih potrebujete, znotraj Enuma. Na primer, vrsto naprave in tam napišite: namizje, mobilni telefon, tablica, TV. Skupno so na voljo 4 možnosti.
Pomanjkljivost je, da ga morate občasno spremeniti. Dodana samo ena možnost. Spremenimo mizo. Pravzaprav je alter table v ClickHouse brezplačen. Še posebej brezplačno za Enum, ker se podatki na disku ne spreminjajo. Toda kljub temu alter pridobi zaklep* na mizi in mora počakati, da se izvedejo vse izbire. In šele potem, ko bo ta sprememba izvedena, tj. še vedno obstajajo nekatere nevšečnosti.
* v zadnjih različicah ClickHouse je ALTER popolnoma neblokiran.
Druga možnost, ki je precej edinstvena za ClickHouse, je povezovanje zunanjih slovarjev. Številke lahko pišete v ClickHouse in svoje imenike hranite v katerem koli sistemu, ki vam ustreza. Na primer, lahko uporabite: MySQL, Mongo, Postgres. Ustvarite lahko celo lastno mikrostoritev, ki bo pošiljala te podatke prek http. In na ravni ClickHouse napišete funkcijo, ki bo te podatke pretvorila iz števil v nize.
To je specializiran, a zelo učinkovit način za izvedbo združevanja na zunanji tabeli. In obstajata dve možnosti. V eni izvedbi bodo ti podatki popolnoma predpomnjeni, v celoti prisotni v RAM-u in posodobljeni z določeno frekvenco. In v drugi možnosti, če se ti podatki ne prilegajo v RAM, jih lahko delno predpomnite.
Tukaj je primer. Obstaja Yandex.Direct. In obstaja oglaševalsko podjetje in transparenti. Verjetno obstaja približno desetine milijonov oglaševalskih podjetij. In se približno prilegajo v RAM. In obstaja na milijarde transparentov, ki se ne prilegajo. In uporabljamo predpomnjeni slovar iz MySQL.
Edina težava je, da bo predpomnjeni slovar dobro deloval, če je stopnja zadetkov blizu 100 %. Če je manjši, boste morali pri obdelavi poizvedb za vsako serijo podatkov dejansko vzeti manjkajoče ključe in iti po podatke iz MySQL. Glede ClickHouse še vedno lahko zagotovim - da, ne upočasnjuje, o drugih sistemih ne bom govoril.
In kot bonus so slovarji zelo enostaven način za retroaktivno posodabljanje podatkov v ClickHouse. Se pravi, imeli ste poročilo o oglaševalskih podjetjih, uporabnik je preprosto zamenjal oglaševalsko podjetje in v vseh starih podatkih, v vseh poročilih se je tudi ta podatek spremenil. Če pišete vrstice neposredno v tabelo, jih ne bo mogoče posodobiti.
Drug način, ko ne veste, kje dobiti identifikatorje za svoje nize. lahko preprosto zgostite. Poleg tega je najpreprostejša možnost vzeti 64-bitno zgoščeno vrednost.
Edina težava je, da če je hash 64-bitni, boste skoraj zagotovo imeli kolizije. Ker če je tam milijarda vrstic, potem verjetnost že postane opazna.
In ne bi bilo dobro, če bi na ta način zgoščevali imena oglaševalskih podjetij. Če se oglaševalske akcije različnih podjetij pomešajo, potem bo nekaj nerazumljivega.
In obstaja preprost trik. Res je, da tudi ni zelo primeren za resne podatke, a če nekaj ni zelo resno, potem preprosto dodajte identifikator stranke v ključ slovarja. In potem boste imeli trke, vendar samo znotraj ene stranke. In to metodo uporabljamo za zemljevide povezav v Yandex.Metrici. Tam imamo URL-je, shranjujemo zgoščene vrednosti. In vemo, da seveda prihaja do kolizij. Ko pa je stran prikazana, lahko zanemarimo verjetnost, da je na eni strani enega uporabnika nekaj URL-jev zlepljenih skupaj in se bo to opazilo.
Kot bonus za številne operacije zadoščajo samo zgoščene vrednosti in samih nizov ni treba nikamor shranjevati.
Drug primer je, če so nizi kratki, na primer domene spletnih mest. Lahko jih shranite takšne, kot so. Ali pa je na primer jezik brskalnika ru 2 bajta. Seveda mi je res žal za bajte, ampak ne skrbi, 2 bajtov ni škoda. Prosim, naj ostane tako, kot je, ne skrbite.
Drugi primer je, nasprotno, ko je vrstic veliko in v njih je veliko unikatnih, celo nabor je potencialno neomejen. Tipičen primer so iskalni izrazi ali URL-ji. Iskalni izrazi, vključno s tipkarskimi napakami. Poglejmo, koliko edinstvenih iskalnih fraz je na dan. In izkazalo se je, da so skoraj polovica vseh dogodkov. In v tem primeru bi morda pomislili, da morate normalizirati podatke, prešteti identifikatorje in jih dati v ločeno tabelo. Ampak tega vam ni treba storiti. Ohranite te vrstice takšne, kot so.
Bolje je, da si ničesar ne izmislite, ker če ga shranite ločeno, boste morali narediti združitev. In to združevanje je v najboljšem primeru naključen dostop do pomnilnika, če še ustreza pomnilniku. Če ne ustreza, bodo težave.
In če so podatki shranjeni na mestu, se preprosto preberejo v zahtevanem vrstnem redu iz datotečnega sistema in vse je v redu.
Če imate URL-je ali kakšen drug zapleten dolg niz, je vredno razmisliti, da lahko vnaprej izračunate nekakšen izvleček in ga zapišete v ločen stolpec.
Za URL-je lahko na primer domeno shranite ločeno. In če resnično potrebujete domeno, potem preprosto uporabite ta stolpec in URL-ji bodo ležali tam in se jih ne boste niti dotaknili.
Poglejmo, kakšna je razlika. ClickHouse ima specializirano funkcijo, ki izračuna domeno. Je zelo hiter, optimizirali smo ga. In, če sem iskren, ni niti v skladu z RFC, a kljub temu upošteva vse, kar potrebujemo.
In v enem primeru bomo preprosto dobili URL-je in izračunali domeno. To pomeni 166 milisekund. In če vzamete že pripravljeno domeno, se izkaže, da je le 67 milisekund, torej skoraj trikrat hitreje. In ni hitrejši zato, ker bi morali narediti nekaj izračunov, ampak zato, ker beremo manj podatkov.
Zato ima ena zahteva, ki je počasnejša, večjo hitrost gigabajtov na sekundo. Ker bere več gigabajtov. To so popolnoma nepotrebni podatki. Zdi se, da se zahteva izvaja hitreje, vendar traja dlje, da se dokonča.
In če pogledate količino podatkov na disku, se izkaže, da je URL 126 megabajtov, domena pa le 5 megabajtov. Izkazalo se je 25-krat manj. Toda kljub temu se zahteva izvrši le 4-krat hitreje. Ampak to je zato, ker so podatki vroči. In če bi bil hladen, bi bil verjetno 25-krat hitrejši zaradi disk I/O.
Mimogrede, če ocenite, koliko je domena manjša od URL-ja, se izkaže, da je približno 4-krat manjša, vendar iz nekega razloga podatki na disku zavzamejo 25-krat manj. Zakaj? Zaradi stiskanja. In URL je stisnjen in domena je stisnjena. Pogosto pa URL vsebuje kup smeti.
In seveda se splača uporabiti prave tipe podatkov, ki so zasnovani posebej za želene vrednosti ali ki so primerni. Če uporabljate IPv4, shranite UInt32*. Če je IPv6, potem FixedString(16), ker je naslov IPv6 128 bitov, tj. shranjen neposredno v binarni obliki.
Kaj pa, če imate včasih naslove IPv4 in včasih IPv6? Da, lahko shranite oboje. En stolpec za IPv4, drugi za IPv6. Seveda obstaja možnost prikaza IPv4 v IPv6. To bo tudi delovalo, vendar če pogosto potrebujete naslov IPv4 v zahtevah, bi bilo dobro, da ga postavite v ločen stolpec.
* ClickHouse ima zdaj ločene vrste podatkov IPv4, IPv6, ki shranjujejo podatke enako učinkovito kot številke, vendar jih predstavljajo tako priročno kot nize.
Pomembno je tudi upoštevati, da je vredno vnaprej obdelati podatke. Na primer, prejmete nekaj neobdelanih dnevnikov. In morda jih ne bi smeli kar takoj dati v ClickHouse, čeprav je zelo mamljivo, da ne storite ničesar in bo vse delovalo. Vendar je še vedno vredno izvesti izračune, ki so možni.
Na primer različica brskalnika. V nekem bližnjem oddelku, na katerega ne želim kazati s prstom, je različica brskalnika shranjena takole, torej kot niz: 12.3. In potem, da naredijo poročilo, vzamejo ta niz in ga razdelijo v niz, nato pa v prvi element niza. Seveda se vse upočasni. Vprašal sem, zakaj to počnejo. Rekli so mi, da ne marajo prezgodnje optimizacije. In ne maram prezgodnje pesimizacije.
Torej bi bilo v tem primeru bolj pravilno razdeliti v 4 stolpce. Tu se ne bojte, saj je to ClickHouse. ClickHouse je stolpčna zbirka podatkov. In več urejenih majhnih stolpcev, bolje je. Na voljo bo 5 različic brskalnika, naredite 5 stolpcev. To je v redu.
Zdaj pa poglejmo, kaj storiti, če imate veliko zelo dolgih nizov, zelo dolgih nizov. Sploh jih ni treba shranjevati v ClickHouse. Namesto tega lahko v ClickHouse shranite samo identifikator. In te dolge vrstice vstavite v drug sistem.
Na primer, ena od naših analitičnih storitev ima nekaj parametrov dogodkov. In če je parametrov za dogodke veliko, preprosto shranimo prvega, ki naleti na 512. Ker 512 ni škoda.
In če se ne morete odločiti za svoje tipe podatkov, potem lahko zapisujete podatke tudi v ClickHouse, vendar v začasno tabelo tipa Log, posebno za začasne podatke. Po tem lahko analizirate, kakšno porazdelitev vrednosti imate tam, kaj je na splošno, in ustvarite pravilne vrste.
*ClickHouse ima zdaj podatkovni tip ki vam omogoča učinkovito shranjevanje nizov z manj truda.
Zdaj pa poglejmo še en zanimiv primer. Včasih stvari ljudem delujejo čudno. Pridem in vidim to. In takoj se zdi, da je to naredil nek zelo izkušen, pameten skrbnik, ki ima bogate izkušnje z nastavitvijo MySQL različice 3.23.
Tukaj vidimo tisoč tabel, od katerih vsaka beleži preostanek deljenja kdo ve česa s tisoč.
Načeloma spoštujem izkušnje drugih ljudi, tudi razumevanje trpljenja, ki ga lahko pridobimo s to izkušnjo.
In razlogi so bolj ali manj jasni. To so stari stereotipi, ki so se morda nabrali pri delu z drugimi sistemi. Na primer, tabele MyISAM nimajo primarnega ključa v gruči. In ta način delitve podatkov je lahko obupen poskus pridobitve enake funkcionalnosti.
Drugi razlog je, da je na velikih tabelah težko izvajati kakršne koli operacije spreminjanja. Vse bo blokirano. Čeprav v sodobnih različicah MySQL ta težava ni več tako resna.
Ali na primer microsharding, a o tem kasneje.
V ClickHouse tega ni treba storiti, ker je, prvič, primarni ključ združen v gruče, podatki so razvrščeni po primarnem ključu.
In včasih me ljudje vprašajo: "Kako se uspešnost poizvedb obsega v ClickHouse razlikuje glede na velikost tabele?" Jaz pravim, da se sploh ne spremeni. Na primer, imate tabelo z milijardo vrstic in berete obseg enega milijona vrstic. Vse je vredu. Če je v tabeli bilijon vrstic in preberete milijon vrstic, bo skoraj enako.
In drugič, vse vrste stvari, kot so ročne particije, niso potrebne. Če vstopite in pogledate, kaj je v datotečnem sistemu, boste videli, da je tabela precej velika stvar. In v notranjosti je nekaj podobnega predelnim stenam. To pomeni, da ClickHouse naredi vse namesto vas in vam ni treba trpeti.
Alter v ClickHouse je brezplačen, če spremenite stolpec za dodajanje/spuščanje.
In ne bi smeli delati majhnih tabel, ker če imate 10 vrstic ali 10 vrstic v tabeli, potem to sploh ni pomembno. ClickHouse je sistem, ki optimizira prepustnost, ne latence, zato nima smisla obdelati 000 vrstic.
Pravilno je uporabiti eno veliko mizo. Znebite se starih stereotipov, vse bo v redu.
In kot bonus, v najnovejši različici imamo zdaj možnost ustvariti poljuben particijski ključ za izvajanje vseh vrst vzdrževalnih operacij na posameznih particijah.
Na primer, potrebujete veliko majhnih tabel, na primer, ko je treba obdelati nekaj vmesnih podatkov, prejmete kose in jih morate preoblikovati, preden zapišete v končno tabelo. Za ta primer obstaja čudovit namizni mehanizem - StripeLog. Nekako je kot TinyLog, le boljši.
* zdaj ima tudi ClickHouse .
Drug antivzorec je mikrosharding. Na primer, morate razdeliti podatke in imate 5 strežnikov, jutri pa bo 6 strežnikov. In razmišljate o tem, kako ponovno uravnotežiti te podatke. Namesto tega se ne razbijete na 5 drobcev, ampak na 1 drobcev. In potem vsakega od teh mikroshardov preslikate v ločen strežnik. In dobili boste na primer 000 ClickHouse na enem strežniku, na primer. Ločeni primerki na ločenih vratih ali ločenih zbirkah podatkov.
Toda to v ClickHouse ni zelo dobro. Ker celo ena instanca ClickHouse poskuša uporabiti vse razpoložljive vire strežnika za obdelavo ene zahteve. Se pravi, imate nekakšen strežnik in ima na primer 56 procesorskih jeder. Izvajate poizvedbo, ki traja eno sekundo in bo uporabila 56 jeder. In če postavite 200 ClickHouse na en strežnik, potem se izkaže, da se bo začelo 10 niti. Na splošno bo vse zelo slabo.
Drugi razlog je, da bo porazdelitev dela med temi instancami neenakomerna. Nekateri bodo končali prej, nekateri kasneje. Če bi se vse to zgodilo v enem primeru, bi ClickHouse sam ugotovil, kako pravilno porazdeliti podatke med niti.
In drugi razlog je, da boste imeli medprocesorsko komunikacijo prek TCP. Podatke bo treba serializirati, deserializirati, to pa je ogromno število microshardov. Enostavno ne bo delovalo učinkovito.
Še en antipattern, čeprav ga težko imenujemo antipattern. To je velika količina predzdruževanja.
Na splošno je predhodno združevanje dobro. Imeli ste milijardo vrstic, to ste združili in postalo je 1 vrstic, zdaj pa se poizvedba izvede takoj. Vse je super. Zmoreš. In za to ima celo ClickHouse posebno vrsto tabele, AggregatingMergeTree, ki izvaja inkrementalno združevanje, ko so podatki vstavljeni.
Toda včasih mislite, da bomo združili podatke, kot je ta, in podatke, kot je ta. In v nekem sosednjem oddelku, tudi ne želim povedati, v katerem, uporabljajo tabele SummingMergeTree za povzemanje po primarnem ključu, kot primarni ključ pa se uporablja približno 20 stolpcev. Za vsak slučaj sem zaradi skrivnosti spremenil imena nekaterih stolpcev, a to je skoraj vse.
In takšne težave nastanejo. Prvič, količina vaših podatkov se ne zmanjša preveč. Na primer, zmanjša se za trikrat. Trikrat bi bila dobra cena, da bi si privoščili neomejene analitične zmogljivosti, ki nastanejo, če vaši podatki niso združeni. Če so podatki agregirani, potem namesto analitike dobite le bedno statistiko.
In kaj je na njem tako posebnega? Dejstvo je, da ti ljudje iz sosednjega oddelka včasih gredo in prosijo, da primarnemu ključu dodajo še en stolpec. Se pravi, podatke smo takole agregirali, zdaj pa hočemo malo več. Toda ClickHouse nima spremenjenega primarnega ključa. Zato moramo napisati nekaj skriptov v C++. In ne maram skriptov, tudi če so v C++.
In če pogledate, za kaj je bil ClickHouse ustvarjen, potem so neagregirani podatki natanko scenarij, za katerega je bil rojen. Če uporabljate ClickHouse za neagregirane podatke, potem delate prav. Če seštevaš, je to včasih odpustljivo.
Drug zanimiv primer so poizvedbe v neskončni zanki. Včasih grem na kakšen produkcijski strežnik in tam pogledam show processlist. In vsakič ugotovim, da se dogaja nekaj groznega.
Na primer takole. Takoj je jasno, da je vse mogoče narediti v eni zahtevi. Samo vpišite url in seznam tam.
Zakaj je veliko takih poizvedb v neskončni zanki slabih? Če indeksa ne uporabite, boste imeli več prehodov čez iste podatke. Če pa se na primer uporablja indeks, imate primarni ključ za ru in tam napišete url = nekaj. In mislite, da če se iz tabele prebere samo en URL, bo vse v redu. Ampak pravzaprav ne. Ker ClickHouse dela vse v serijah.
Ko mora prebrati določen obseg podatkov, jih prebere malo več, saj je indeks v ClickHouse redek. Ta indeks vam ne omogoča iskanja ene posamezne vrstice v tabeli, temveč le nekakšen obseg. In podatki so stisnjeni v blokih. Če želite prebrati eno vrstico, morate vzeti celoten blok in ga sprostiti. In če opravljate kup poizvedb, se bo veliko prekrivalo in boste imeli vedno znova veliko dela.
In kot bonus, lahko upoštevate, da se v ClickHouse ne bi smeli bati prenesti niti megabajtov in celo sto megabajtov v razdelek IN. Iz naše prakse se spomnim, da če v MySQL prenesemo kup vrednosti v razdelek IN, na primer, tam prenesemo 100 megabajtov nekih številk, potem MySQL poje 10 gigabajtov pomnilnika in nič drugega se mu ne zgodi, vse deluje slabo.
In drugo je, da v ClickHouse, če vaše poizvedbe uporabljajo indeks, potem vedno ni nič počasnejše od popolnega skeniranja, tj. če morate prebrati skoraj celotno tabelo, bo šlo zaporedno in prebralo celotno tabelo. Na splošno bo to ugotovil sam.
Toda kljub temu obstajajo nekatere težave. Na primer dejstvo, da IN s podpoizvedbo ne uporablja indeksa. Ampak to je naš problem in ga moramo rešiti. Tukaj ni nič temeljnega. Bomo popravili*.
In še ena zanimivost je, da če imate zelo dolgo zahtevo in je v teku porazdeljena obdelava zahteve, bo ta zelo dolga zahteva poslana vsakemu strežniku brez stiskanja. Na primer 100 megabajtov in 500 strežnikov. In v skladu s tem boste imeli 50 gigabajtov prenesenih po omrežju. Preneseno bo in potem bo vse uspešno zaključeno.
* že uporabljam; Vse je bilo popravljeno, kot je bilo obljubljeno.
In dokaj pogost primer je, ko zahteve prihajajo iz API-ja. Na primer, ustvarili ste nekakšno lastno storitev. In če nekdo potrebuje vašo storitev, potem odprete API in dobesedno dva dni kasneje vidite, da se dogaja nekaj nerazumljivega. Vse je preobremenjeno in prihajajo grozljive zahteve, ki se ne bi smele zgoditi.
In rešitev je samo ena. Če ste odprli API, ga boste morali rezati. Na primer, uvesti neke vrste kvote. Drugih običajnih možnosti ni. V nasprotnem primeru bodo takoj napisali scenarij in bodo težave.
In ClickHouse ima posebnost - izračun kvote. Poleg tega lahko prenesete svoj ključ kvote. To je na primer interni ID uporabnika. In kvote bodo izračunane neodvisno za vsakega od njih.
Zdaj pa še ena zanimivost. To je ročna replikacija.
Poznam veliko primerov, ko kljub temu, da ima ClickHouse vgrajeno podporo za replikacijo, ljudje ClickHouse replicirajo ročno.
Kaj je princip? Imate cevovod za obdelavo podatkov. In deluje neodvisno, na primer v različnih podatkovnih centrih. Iste podatke zapišete na enak način v ClickHouse. Res je, praksa kaže, da se podatki še vedno razlikujejo zaradi nekaterih funkcij v vaši kodi. Upam, da je v tvojem.
In od časa do časa boste še vedno morali ročno sinhronizirati. Enkrat na mesec skrbniki na primer izvedejo rsync.
Pravzaprav je veliko lažje uporabljati replikacijo, vgrajeno v ClickHouse. Lahko pa obstajajo nekatere kontraindikacije, ker za to morate uporabiti ZooKeeper. O ZooKeeperju ne bom rekel nič slabega, načeloma sistem deluje, vendar se zgodi, da ga ljudje ne uporabljajo zaradi javafobije, ker je ClickHouse tako dober sistem, napisan v C++, ki ga lahko uporabljate in vse bo v redu In ZooKeeper je v Javi. In nekako si sploh ne želite pogledati, potem pa lahko uporabite ročno replikacijo.
ClickHouse je praktičen sistem. Upošteva vaše potrebe. Če imate ročno podvajanje, lahko ustvarite porazdeljeno tabelo, ki pregleduje vaše ročne dvojnike in med njimi izvede samodejni preklop. Obstaja celo posebna možnost, ki vam omogoča, da se izognete neuspehom, tudi če se vaše linije sistematično razlikujejo.
Dodatne težave lahko nastanejo, če uporabljate primitivne mehanizme tabel. ClickHouse je konstruktor, ki ima kup različnih mehanizmov tabel. Za vse hujše primere, kot piše v dokumentaciji, uporabite tabele iz družine MergeTree. In vse ostalo - to je tako, za posamezne primere ali za teste.
V tabeli MergeTree vam ni treba imeti nobenega datuma in ure. Še vedno ga lahko uporabljate. Če datuma in časa ni, napišite, da je privzeto 2000. To bo delovalo in ne bo zahtevalo sredstev.
In v novi različici strežnika lahko celo določite, da imate particijo po meri brez particijskega ključa. Enako bo.
Po drugi strani pa lahko uporabite primitivne motorje tabel. Na primer, enkrat vnesite podatke in poglejte, zavrtite in izbrišite. Uporabite lahko Log.
Ali shranjevanje majhnih količin za vmesno obdelavo je StripeLog ali TinyLog.
Pomnilnik se lahko uporablja, če je količina podatkov majhna in lahko preprosto nekaj vrtite v RAM-u.
ClickHouse res ne mara renormaliziranih podatkov.
Tukaj je tipičen primer. To je ogromno URL-jev. Daš jih v naslednjo tabelo. In potem so se odločili, da bodo z njimi naredili JOIN, vendar to praviloma ne bo delovalo, ker ClickHouse podpira samo Hash JOIN. Če ni dovolj RAM-a za veliko podatkov, ki jih je treba povezati, JOIN ne bo deloval*.
Če so podatki visoke kardinalnosti, potem ne skrbite, shranite jih v denormalizirani obliki, URL-ji so neposredno na mestu v glavni tabeli.
* in zdaj ima ClickHouse tudi združevanje in deluje v pogojih, ko se vmesni podatki ne prilegajo v RAM. Vendar je to neučinkovito in priporočilo ostaja v veljavi.
Še par primerov, pa že dvomim, ali so proti vzorcu ali ne.
ClickHouse ima eno znano napako. Ne zna posodobiti*. Na nek način je to celo dobro. Če imate pomembne podatke, na primer računovodstvo, jih nihče ne bo mogel poslati, ker ni posodobitev.
* podpora za posodobitev in brisanje v paketnem načinu je bila dodana že zdavnaj.
Obstaja pa nekaj posebnih načinov, ki omogočajo posodobitve kot v ozadju. Na primer tabele, kot je ReplaceMergeTree. Posodabljajo med združevanjem v ozadju. To lahko vsilite z uporabo optimizirane tabele. Vendar tega ne počnite prepogosto, ker bo popolnoma prepisal particijo.
Porazdeljene JOIN-e v ClickHouse tudi načrtovalec poizvedb slabo obravnava.
Slabo, ampak včasih OK.
Uporaba ClickHouse samo za branje podatkov nazaj z uporabo select*.
Ne priporočam uporabe ClickHouse za okorne izračune. A to ne drži povsem, saj se od tega priporočila že odmikamo. Nedavno smo dodali možnost uporabe modelov strojnega učenja v ClickHouse - Catboost. In moti me, ker si mislim: »Kakšna groza. To je, koliko ciklov na bajt se izkaže! Resnično sovražim zapravljanje ur z bajti.
Ampak ne bojte se, namestite ClickHouse, vse bo v redu. Če kaj, imamo skupnost. Mimogrede, skupnost ste vi. In če imate kakršne koli težave, lahko greste vsaj na naš klepet in upam, da vam bodo pomagali.
vprašanja
Hvala za poročilo! Kje se lahko pritožim zaradi sesutja ClickHouse?
Zdaj se lahko pritožiš meni osebno.
Pred kratkim sem začel uporabljati ClickHouse. Takoj sem opustil vmesnik cli.
Kakšen rezultat.
Malo kasneje sem z majhno izbiro sesul strežnik.
Imate talent.
Odprl sem napako GitHub, vendar je bila prezrta.
Videli bomo.
Alexey me je prevaral, da sem se udeležil poročila, z obljubo, da mi bo povedal, kako dostopate do podatkov v notranjosti.
Zelo preprosto.
To sem ugotovil včeraj. Več podrobnosti.
Tam ni nobenih strašnih trikov. Obstaja samo stiskanje po blokih. Privzeto je LZ4, lahko omogočite ZSTD*. Bloki od 64 kilobajtov do 1 megabajta.
* obstaja tudi podpora za specializirane kompresijske kodeke, ki jih je mogoče uporabiti v verigi z drugimi algoritmi.
Ali so bloki le neobdelani podatki?
Ne popolnoma surov. Obstajajo nizi. Če imate številski stolpec, so številke v vrsti postavljene v matriko.
To je jasno.
Alexey, primer, ki je bil z uniqExact prek IP-jev, tj. dejstvo, da uniqExact rabi več časa za izračun po vrsticah kot po številkah itd. Kaj pa, če pri lektoriranju uporabimo finto z ušesi in zasedbo? To pomeni, da ste rekli, da na našem disku ni zelo drugače. Če beremo vrstice z diska in predvajamo, bodo naši agregati hitrejši ali ne? Ali pa bomo tu vseeno nekoliko pridobili? Zdi se mi, da ste to preizkusili, vendar iz nekega razloga tega niste navedli v merilu uspešnosti.
Mislim, da bo šlo počasneje kot brez kastinga. V tem primeru je treba naslov IP razčleniti iz niza. Seveda je pri ClickHouse optimizirano tudi naše razčlenjevanje naslovov IP. Zelo smo se trudili, a tukaj so številke zapisane v desettisočinki. Zelo neprijetno. Po drugi strani pa bo funkcija uniqExact na nizih delovala počasneje, ne le zato, ker so to nizi, ampak tudi zato, ker je izbrana drugačna specializacija algoritma. Strune so preprosto obdelane drugače.
Kaj pa, če vzamemo bolj primitiven tip podatkov? Zapisali smo na primer ID uporabnika, ki ga imamo noter, zapisali kot vrstico in nato premešali, bo bolj zabavno ali ne?
Dvomim. Mislim, da bo še bolj žalostno, saj je navsezadnje razčlenjevanje številk resen problem. Zdi se mi, da je ta kolega celo poročal o tem, kako težko je razčleniti števila v desettisočinki, morda pa tudi ne.
Alexey, najlepša hvala za poročilo! In najlepša hvala za ClickHouse! Imam vprašanje glede načrtov. Ali obstajajo kakšni načrti za funkcijo nepopolnega posodabljanja slovarjev?
Se pravi delni ponovni zagon?
Da Da. Na primer možnost, da tam nastavite polje MySQL, tj. posodobite po, tako da se naložijo samo ti podatki, če je slovar zelo velik.
Zelo zanimiva funkcija. In mislim, da je nekdo to predlagal v našem klepetu. Mogoče si bil celo ti.
Mislim, da ne.
Super, zdaj se je izkazalo, da sta zahtevi dve. In počasi lahko začnete s tem. Vendar vas želim takoj opozoriti, da je ta funkcija precej preprosta za izvedbo. To pomeni, da v teoriji morate samo napisati številko različice v tabelo in nato napisati: različica nižja od take in take. To pomeni, da bomo to najverjetneje ponudili navdušencem. Ste entuziast?
Da, vendar na žalost ne v C++.
Ali vaši kolegi znajo pisati v C++?
Bom našel nekoga.
Super*.
* funkcija je bila dodana dva meseca po prijavi - avtor vprašanja jo je razvil in poslal svoje .
Hvala!
Zdravo! Hvala za poročilo! Omenili ste, da je ClickHouse zelo dober pri porabi vseh sredstev, ki so mu na voljo. In govornik poleg Luxoft je za Rusko pošto spregovoril o svoji rešitvi. Povedal je, da jim je bil ClickHouse zelo všeč, vendar ga niso uporabili namesto glavnega konkurenta ravno zato, ker je požrl ves CPU. In tega niso mogli vključiti v svojo arhitekturo, v svoj ZooKeeper s pristanišči. Ali je mogoče ClickHouse nekako omejiti, da ne bi porabil vsega, kar mu je na voljo?
Da, možno je in zelo enostavno. Če želite porabiti manj jeder, potem samo pišite set max_threads = 1. In to je to, zahtevo bo izvedel v enem jedru. Poleg tega lahko določite različne nastavitve za različne uporabnike. Torej ni problema. In povejte kolegom iz Luxofta, da ni dobro, da te nastavitve niso našli v dokumentaciji.
Alexey, pozdravljen! Rad bi vprašal o tem vprašanju. To ni prvič, da sem slišal, da veliko ljudi začne uporabljati ClickHouse kot shrambo za dnevnike. V poročilu ste rekli, da tega ne počnete, tj. ni vam treba shranjevati dolgih nizov. Kaj misliš o tem?
Prvič, dnevniki praviloma niso dolgi nizi. So pa seveda izjeme. Na primer, neka storitev, napisana v Javi, vrže izjemo, se zabeleži. In tako naprej v neskončni zanki, prostora na trdem disku pa zmanjkuje. Rešitev je zelo preprosta. Če so črte zelo dolge, jih odrežite. Kaj pomeni dolgo? Na desetine kilobajtov je slabo*.
* v zadnjih različicah ClickHouse je omogočena “adaptive index granularity”, ki večinoma odpravi problem shranjevanja dolgih vrstic.
Ali je kilobajt normalen?
To je normalno.
Zdravo! Hvala za poročilo! O tem sem že vprašal v klepetu, vendar se ne spomnim, ali sem prejel odgovor. Ali obstajajo načrti za nekako razširitev razdelka WITH na način CTE?
Ne še. Naša rubrika Z je nekoliko neresna. To je kot majhna funkcija za nas.
Razumem. Hvala vam!
Hvala za poročilo! Zelo zanimivo! Globalno vprašanje. Ali obstajajo načrti za spremembo brisanja podatkov, morda v obliki kakšnih škrbin?
Nujno. To je naša prva naloga v naši čakalni vrsti. Zdaj aktivno razmišljamo, kako narediti vse pravilno. In morali bi začeti pritiskati tipkovnico*.
* pritisnil gumbe na tipkovnici in naredil vse.
Bo to nekako vplivalo na delovanje sistema ali ne? Bo vstavljanje tako hitro kot sedaj?
Morda bodo sami izbrisi in same posodobitve zelo težki, vendar to ne bo vplivalo na delovanje izbir ali delovanje vstavljanj.
In še eno majhno vprašanje. Na predstavitvi ste govorili o primarnem ključu. V skladu s tem imamo particioniranje, ki je privzeto mesečno, kajne? In ko nastavimo časovno obdobje, ki ustreza enemu mesecu, se bere samo ta particija, kajne?
Da.
Vprašanje. Če ne moremo izbrati nobenega primarnega ključa, ali je potem pravilno, da to naredimo posebej glede na polje "Datum", tako da je v ozadju manj preurejanja teh podatkov, tako da se prilegajo na bolj urejen način? Če nimate poizvedb po obsegu in ne morete niti izbrati nobenega primarnega ključa, ali je vredno v primarni ključ vnesti datum?
Da.
Morda je smiselno v primarni ključ dati polje, ki bo podatke bolje stisnilo, če bodo razvrščeni po tem polju. Na primer ID uporabnika. Uporabnik gre na primer na isto spletno mesto. V tem primeru vnesite ID uporabnika in čas. In potem bodo vaši podatki bolje stisnjeni. Kar se tiče datuma, če res nimate in nikoli nimate poizvedb po obsegu datumov, potem vam datuma ni treba dati v primarni ključ.
OK hvala lepa!
Vir: www.habr.com