Aprillis kogunesid Avito insenerid veebikogunemistele ClickHouse'i peaarendaja Aleksei Milovidovi ja Integrose Golangi arendaja Kirill Shvakoviga. Arutasime, kuidas me andmebaasihaldussüsteemi kasutame ja milliste raskustega kokku puutume.
Koosoleku põhjal koostasime artikli, kus on ekspertide vastused meie ja publiku küsimustele varundamise, andmete ümberjagamise, väliste sõnaraamatute, Golangi draiveri ja ClickHouse'i versiooniuuenduste kohta. See võib olla kasulik arendajatele, kes juba töötavad aktiivselt Yandexi DBMS-iga ning on huvitatud selle olevikust ja tulevikust. Aleksei Milovidovi vastused vaikimisi, kui pole märgitud teisiti.
Ettevaatust, lõike all on palju teksti. Loodame, et küsimustega sisu aitab teil navigeerida.
Sisu
Kes teksti lugeda ei soovi, saab vaadata kogunemiste salvestust . Ajatemplid on esimeses kommentaaris video all.
ClickHouse'i uuendatakse pidevalt, kuid meie andmeid mitte. Mida sellega teha?
ClickHouse'i uuendatakse pidevalt ja meie optimeerimisfinaali poolt töödeldud andmeid ei uuendata ja need on varukoopias.
Oletame, et meil on mingi probleem ja andmed läksid kaotsi. Otsustasime taastada ja selgus, et vanad partitsioonid, mida varuserverites hoitakse, erinevad oluliselt praegu kasutatavast ClickHouse'i versioonist. Mida sellises olukorras teha ja kas see on võimalik?
Olukord, kus taastasite andmed varukoopiast vanas vormingus, kuid uues versioonis pole need ühendatud, on võimatu. Tagame, et ClickHouse'i andmevorming jääb alati tagasiühilduvaks. See on palju olulisem kui funktsionaalsuse tagasiühilduvus, kui mõne harva kasutatava funktsiooni käitumine on muutunud. Kettale salvestatud andmeid peaks ClickHouse'i uus versioon alati suutma lugeda. See on seadus.
Millised on praegused parimad tavad ClickHouse'i andmete varundamiseks?
Kuidas teha varukoopiaid, võttes arvesse, et meil on optimeeritud lõpptoimingud, tohutu terabaitide andmebaas ja andmed, mida uuendatakse, ütleme, et viimased kolm päeva ja siis ei juhtu nendega ühtegi protseduuri?
Võime oma lahenduse kokku panna ja pähe kirjutada: koguge neid varukoopiaid nii ja naa. Võib-olla pole teil vaja midagi karkuda ja jalgratas leiutati juba ammu?
Alustame parimatest tavadest. Mu kolleegid soovitavad alati vastuseks varukoopiate kohta küsimustele meelde tuletada teenust Yandex.Cloud, kus see ülesanne on juba lahendatud. Nii et võimalusel kasutage seda.
Varukoopiate tegemiseks pole täielikku lahendust, mis oleks ClickHouse'i sisse ehitatud. Seal on mõned toorikud, mida saate kasutada. Täieliku lahenduse saamiseks peate kas käsitsi veidi nuputama või tegema skriptide kujul ümbriseid.
Alustan kõige lihtsamate lahendustega ja lõpetan kõige keerukamate lahendustega, olenevalt andmemahust ja klastri suurusest. Mida suurem on klaster, seda keerulisemaks lahendus muutub.
Kui andmetabel võtab enda alla vaid mõne gigabaidi, saab varundada järgmiselt:
- Salvestage tabelite määratlus, st metaandmed − näita loo tabelit.
- Tehke tõmmis ClickHouse'i kliendiga − valima * laualt viilima. Vaikimisi saate faili TabSeparated vormingus. Kui soovite olla tõhusam, võite kasutada algvormingut.
Kui andmemaht on suurem, võtab varundamine rohkem aega ja ruumi. Seda nimetatakse loogiliseks varukoopiaks, see ei ole seotud ClickHouse'i andmevorminguga. Kui see on nii, saate teha varukoopia ja laadida selle taastamiseks MySQL-i.
Täpsemate juhtumite jaoks on ClickHouse'il sisseehitatud võimalus luua kohalikus failisüsteemis partitsioonide hetktõmmis. See funktsioon on saadaval soovi korral. muuda tabeli külmutamise partitsiooni. Või lihtsalt muuda laua külmutamist - see on kogu tabeli hetktõmmis.
Hetktõmmis luuakse ühe tabeli kohta ühe killu kohta, see tähendab, et sel viisil on võimatu kogu klastrist ühtset hetktõmmist luua. Kuid enamiku ülesannete puhul pole sellist vajadust ja piisab, kui täita iga killu päring ja saada järjepidev hetktõmmis. See on loodud kõvalinkide kujul ja seetõttu ei võta see täiendavat ruumi. Seejärel kopeerite selle hetktõmmise varuserverisse või salvestusruumi, mida kasutate varundamiseks.
Sellise varukoopia taastamine on üsna lihtne. Esiteks loote tabelid vastavalt olemasolevatele tabelimääratlustele. Järgmisena kopeerige salvestatud partitsiooni hetktõmmised nende tabelite jaoks kausta Eraldatud kataloog ja käivitage päring kinnita vahesein. See lahendus on üsna sobiv kõige tõsisemate andmemahtude jaoks.
Mõnikord on vaja midagi veelgi lahedamat - juhtudel, kui teil on igas serveris kümneid või isegi sadu terabaite ja sadu servereid. Siin on lahendus, mida luurasin Yandex.Metrica kolleegidelt. Ma ei soovita seda kõigile - lugege läbi ja otsustage ise, kas see sobib või mitte.
Kõigepealt peate looma mitu suurte kettariiulitega serverit. Järgmisena tõstke nendes serverites mitu ClickHouse'i serverit ja konfigureerige need nii, et need töötaksid samade kildude teise koopiana. Ja seejärel kasutage nendes serverites failisüsteemi või mõnda tööriista, mis võimaldab teil hetktõmmiseid luua. Siin on kaks võimalust. Esimene võimalus on LVM-i hetktõmmised, teine valik on ZFS Linuxis.
Pärast seda peate iga päev tegema hetktõmmise, see valetab ja võtab natuke ruumi. Loomulikult, kui andmed muutuvad, siis aja jooksul ruumi maht suureneb. Saate selle hetktõmmise igal ajal teha ja andmed taastada, selline kummaline otsus. Lisaks peate ikkagi piirama neid koopiaid konfiguratsioonis, et nad ei prooviks saada liidriteks.
Kas šahtides on võimalik korraldada kontrollitud koopiate mahajäämus?
Sel aastal on sul plaanis ClickHouse’is šahtid teha. Kas nendes on võimalik korraldada kontrollitud koopiate viivitus? Soovime seda kasutada, et kaitsta end negatiivsete stsenaariumide eest muudatuste ja muude muudatustega.
Kas alterite jaoks on võimalik mingisugune tagasipööramine teha? Näiteks olemasolevas šahtis võtta ja öelda, et kuni selle hetkeni rakenda muudatusi ja sellest hetkest lõpeta muudatuste rakendamine?
Kui meie klastrisse tuli käsk ja selle katki läks, siis meil on tunnise viivitusega tingimuslik replika, kus saame öelda, et kasutame seda hetkel, aga viimased kümme minutit me selles muudatusi ei rakenda?
Alustuseks kontrollitud koopiate mahajäämuse kohta. Kasutajatelt tuli selline palve ja lõime Githubis probleemi palvega: "Kui kellelgi on seda vaja, pange like, pange süda." Keegi ei panustanud ja probleem suleti. Selle võimaluse saad aga juba ClickHouse’i seadistamisega. Tõsi, alles alates versioonist 20.3.
ClickHouse liidab pidevalt andmeid taustal – ühenda. Ühendamisel asendatakse mõni andmetükkide komplekt suurema osaga. Samal ajal jäävad kettale veel mõnda aega varem olnud andmetükid.
Esiteks jätkatakse nende salvestamist seni, kuni leidub valitud päringuid, mis neid kasutavad, et tagada mitteblokeeriv töö. Valitud taotlusi loetakse vaikselt vanadest tükkidest.
Teiseks on ka ajaline lävi – vanad andmekillud lebavad kettal kaheksa minutit. Neid kaheksat minutit saab kohandada ja muuta isegi üheks päevaks. See maksab kettaruumi: olenevalt andmevoost selgub, et viimase päeva jooksul andmed mitte ainult ei kahekordistu, vaid võivad kasvada viis korda rohkem. Kuid tõsise probleemi korral saate ClickHouse'i serveri peatada ja kõigega tegeleda.
Nüüd on küsimus selles, kuidas see kaitseb muutuste eest. Siin tasub vaadata sügavamalt, sest ClickHouse'i vanemates versioonides töötas alter nii, et vahetas lihtsalt tükke otse välja. Mõnede failidega on osa andmeid ja me teeme näiteks muuda tilkveergu. Seejärel eemaldatakse see veerg füüsiliselt kõigist tükkidest.
Kuid alates versioonist 20.3 on muutmismehhanismi täielikult muudetud ja nüüd on andmetükid alati muutumatud. Need ei muutu üldse – muudatused töötavad nüüd samamoodi nagu liitmised. Selle asemel, et tükki paigas vahetada, loome uue. Uues tükis muutuvad muutmata failid kõvalinkideks ja kui kustutame veeru, siis uues tükis see lihtsalt puudub. Vana tükk kustutatakse vaikimisi kaheksa minuti pärast ja siin saate ülalmainitud seadeid muuta.
Sama kehtib ka muutuste kohta nagu mutatsioonid. Kui teete muuda kustuta või muuda värskendust, see ei muuda tükki, vaid loob uue. Ja siis kustutab vana.
Mis siis, kui tabeli struktuur on muutunud?
Kuidas tõsta varukoopiat, mis tehti vana skeemiga? Ja teine küsimus puudutab hetktõmmiste ja failisüsteemi tööriistade juhtumit. Kas Linux LVM-is ZFS-i asemel sobib siin Btrfs?
Kui teete kinnita vahesein erineva struktuuriga partitsioonid, siis ClickHouse ütleb teile, et see pole võimalik. See on lahendus. Esimene on luua vana struktuuriga MergeTree tüüpi ajutine tabel, lisada sinna manusega andmed ja teha muutmispäring. Seejärel saate need andmed kopeerida või üle kanda ja uuesti lisada või kasutada päringut muuda tabeli teisaldamise partitsiooni.
Nüüd on teine küsimus, kas Btrfsi saab kasutada. Alustuseks, kui teil on LVM, siis piisab LVM-i hetktõmmistest ja failisüsteem võib olla ext4, see pole oluline. Btrtsi puhul sõltub kõik teie kogemusest selle kasutamisel. See on väljakujunenud failisüsteem, kuid siiski on kahtlusi, kuidas kõik konkreetse stsenaariumi korral praktikas toimib. Ma ei soovita seda kasutada, kui teil pole Btrf-i tootmises.
Millised on andmete uuesti jagamise praegused parimad tavad?
Taastükeldamise küsimus on keeruline ja mitmetahuline. Siin saate vastata mitmele võimalusele korraga. Võite minna ühelt poolt ja öelda seda – ClickHouse'is pole sisseehitatud taasjaotamise võimalust. Aga ma kardan, et see vastus ei sobi kellelegi. Seetõttu võite minna teiselt poolt ja öelda, et ClickHouse'il on palju võimalusi andmete taastamiseks.
Kui klastris saab ruum otsa või see ei saa koormusega hakkama, lisate uued serverid. Aga need serverid on vaikimisi tühjad, neil pole andmeid, koormust pole. Peate andmeid nihutama nii, et need jaguneksid ühtlaselt uues suuremas klastris.
Esimene viis selleks on kopeerida osa partitsioonidest päringu abil uutesse serveritesse muuda tabeli toomise partitsiooni. Näiteks olid teil partitsioonid kuude kaupa ja kopeerite 2017. aasta esimese kuu uude serverisse, seejärel kopeerite kolmanda kuu mõnda teise uude serverisse. Ja nii teete, kuni see muutub enam-vähem ühtlaseks.
Ülekandmist saab teha ainult nende partitsioonide jaoks, mis salvestamise ajal ei muutu. Värskete partitsioonide puhul tuleb kirjutamine keelata, kuna nende ülekandmine ei ole aatom. Vastasel juhul tekib andmetes duplikaate või lünki. Kuid see meetod on praktiline ja töötab üsna tõhusalt. Valmis tihendatud partitsioonid edastatakse üle võrgu, see tähendab, et andmeid ei tihendata ega ümber kodeerita.
Sellel meetodil on üks puudus ja see sõltub jagamisskeemist, kas lubasite seda jaotusskeemi kasutada ja milline jagamisvõti teil oli. Teie näites mõõdikute puhul on jaotusvõti tee räsi. Kui valite hajutatud tabeli, läheb see korraga kõikidesse klastri killudesse ja võtab sealt andmeid.
See tähendab, et teie jaoks pole tegelikult vahet, millised andmed millisele killule jõuavad. Peaasi, et ühel teel olevad andmed satuvad ühele killule, kuid milline neist, pole oluline. Sel juhul on valmis partitsioonide ülekandmine ideaalne, sest valitud päringutega saate ka täielikud andmed - nii enne uuesti jagamist kui ka pärast seda pole skeemil tegelikult tähtsust.
Kuid on juhtumeid, mis on keerulisemad. Kui rakendusloogika tasemel toetuda spetsiaalsele jagamisskeemile, et see klient asub sellisel ja sellisel killul ja päringu saab saata kohe sinna, mitte tabelisse Distributed. Või kasutate ClickHouse'i üsna värsket versiooni ja olete selle sätte lubanud optimeerige kasutamata kildude vahelejätmine. Sel juhul parsitakse valikupäringu käigus avaldis jaotises where ja arvutatakse, millistele kildudele minna vastavalt sharding-skeemile. See toimib tingimusel, et andmed jaotatakse täpselt vastavalt sellele jaotusskeemile. Kui nihutasite neid käsitsi, võib kirjavahetus muutuda.
Nii et see on number üks viis. Ja ma ootan teie vastust, kas meetod sobib või jätkake.
Vladimir Kolobaev, Avito juhtiv süsteemiadministraator: Aleksei, teie mainitud meetod ei sobi eriti hästi, kui teil on vaja koormust hajutada, sealhulgas lugemist. Saame võtta igakuise partitsiooni ja eelmise kuu teise sõlme, kuid kui nende andmete päring tuleb, laadime need ainult. Kuid ma tahaksin laadida kogu klastri, sest vastasel juhul töödeldakse mõnda aega kogu lugemiskoormust kaks kildu.
Aleksei Milovidov: Vastus on siin kummaline – jah, see on halb, kuid see võib toimida. Selgitan täpselt, kuidas. Tasub vaadata andmetega kaasasolevat laadimisstsenaariumit. Kui tegemist on seireandmetega, siis on peaaegu kindel, et valdav enamus päringuid on värskete andmete saamiseks.
Installisite uusi servereid, migreerisite vanad partitsioonid, kuid muutsite ka värskete andmete salvestamise viisi. Ja värsked andmed levivad kogu klastris. Seega juba viie minuti pärast laadivad viimase viie minuti päringud klastri ühtlaselt; päeva pärast laadivad XNUMX tunni taotlused klastri ühtlaselt. Ja eelmise kuu taotlused lähevad kahjuks ainult osale klastri serveritest.
Kuid sageli pole teil 2019. aasta veebruariks taotlusi. Tõenäoliselt, kui taotlused lähevad 2019. aastasse, on need kogu 2019. aastaks - pikaks perioodiks, mitte väikeseks vahemikuks. Ja sellised taotlused saavad ka klastri ühtlaselt laadida. Aga üldiselt on sinu märkus täiesti õige, et tegemist on ad hoc lahendusega, mis ei hajuta andmeid täiesti ühtlaselt.
Mul on küsimusele vastamiseks veel paar punkti. Üks neist puudutab seda, kuidas algselt kujundada killustamisskeem nii, et uuesti killustamine tekitaks vähem valu. See ei ole alati võimalik.
Näiteks on teil seireandmed. Seireandmed kasvavad kolmel põhjusel. Esimene on ajalooliste andmete kogumine. Teine on liikluse kasv. Ja kolmas on järelevalve alla kuuluvate asjade arvu suurenemine. Seal on uued mikroteenused ja mõõdikud, mis tuleb salvestada.
Võimalik, et neist suurim kasv on tingitud kolmandast põhjusest - see on monitooringu kasutamise suurenemine. Ja sel juhul tasub vaadata koormuse olemust, millised on peamised soovid valida. Peamised valikupäringud järgivad tõenäoliselt mõnda mõõdikute alamhulka.
Näiteks mõne teenuse CPU kasutamine mõnes serveris. Selgub, et nende andmete saamiseks on mõni võtmete alamhulk. Ja nende andmete päring ise on tõenäoliselt üsna lihtne ja kestab kümneid millisekundeid. Kasutatakse seireteenuste jaoks, armatuurlaudade jaoks. Loodan, et sain sellest õigesti aru.
Vladimir Kolobaev: Fakt on see, et me tugineme väga sageli ajaloolistele andmetele, kuna võrdleme praegust olukorda ajaloolisega reaalajas. Ja meie jaoks on oluline kiire juurdepääs suurele hulgale andmetele ja ClickHouse teeb sellega suurepärast tööd.
Teil on täiesti õigus, enamik lugemistaotlusi kogeme viimase päeva jooksul, nagu iga seiresüsteem. Kuid samal ajal on ka ajalooliste andmete koormus üsna suur. See pärineb enamasti hoiatussüsteemist, mis käib ringi iga kolmekümne sekundi järel ja ütleb ClickHouse'ile: "Andke mulle viimase kuue nädala andmed. Ja nüüd koostage mulle nendest mõni liikuv keskmine ja võrdleme praegust väärtust ajaloolise väärtusega.
Tahaksin öelda, et selliste väga värskete päringute jaoks on meil veel üks väike tabel, kuhu salvestame ainult kahe päeva andmeid ja peamised päringud lendavad sinna. Saadame suurde tükeldatud tabelisse ainult suured ajaloolised päringud.
Aleksei Milovidov: Kahjuks osutub see teie stsenaariumi jaoks halvasti rakendatavaks, kuid kirjeldan kahte halba ja keerulist jaotusskeemi, mida pole vaja kasutada, kuid mida kasutatakse minu sõprade teenuses.
Seal on Yandex.Metrica sündmuste põhiklaster. Sündmused on lehevaatamised, klõpsud ja üleminekud. Enamik taotlusi suunatakse konkreetsele veebisaidile. Avate Yandex.Metrica teenuse, teil on veebisait - avito.ru, minge aruandele ja teie veebisaidile esitatakse taotlus.
Kuid on ka teisi taotlusi - analüütilisi ja globaalseid, mille esitavad siseanalüütikud. Igaks juhuks märgin, et siseanalüütikud teevad päringuid ainult Yandexi teenuste kohta. Kuid sellegipoolest hõivavad isegi Yandexi teenused märkimisväärse osa kõigist andmetest. Need on taotlused mitte konkreetsete loendurite, vaid laiema filtreerimise jaoks.
Kuidas korraldada andmeid nii, et kõik toimiks tõhusalt ühe loenduri jaoks ja ka globaalsed päringud? Teine raskus seisneb selles, et ClickHouse'i taotluste arv mõõdikute klastri jaoks on mitu tuhat sekundis. Samas üks ClickHouse'i server ei käsitle mittetriviaalseid päringuid, näiteks mitu tuhat sekundis.
Klastri suurus on kuussada ja midagi serverit. Kui venitate hajutatud tabeli lihtsalt üle selle klastri ja saadate sinna mitu tuhat päringut, muutub see veelgi hullemaks, kui saata need ühte serverisse. Seevastu variant, et andmed jaotatakse ühtlaselt ja me läheme ja küsime kõikidelt serveritelt, jäetakse kohe kõrvale.
On diametraalselt vastupidine variant. Kujutage ette, kui eraldame andmeid saidi kaupa ja ühe saidi päring läheb ühele killule. Nüüd suudab klaster välja tõmmata kümme tuhat päringut sekundis, kuid ühel killul töötab üks päring liiga aeglaselt. See ei skaleeri enam ribalaiust. Eriti kui see on sait avito.ru. Ma ei avalda saladust, kui ütlen, et Avito on Runeti üks enimkülastatud saite. Ja seda ühe killu pealt töödelda oleks hullumeelsus.
Seetõttu on jaotusskeem korraldatud keerulisemal viisil. Kogu klaster on jagatud mitmeks klastriks, mida me nimetame kihtideks. Iga klastri sees on kümme kuni mitukümmend kildu. Kokku on selliseid klastreid kolmkümmend üheksa.
Kuidas see kõik ulatub? Klastrite arv ei muutu – nagu see oli kolmkümmend üheksa aastat tagasi, jääb see samaks. Kuid igas neist suurendame andmete kogunedes järk-järgult kildude arvu. Ja jagamise skeem tervikuna on selline – jaotus neisse klastritesse käib veebisaitide kaupa ja selleks, et aru saada, milline sait millises klastris asub, kasutatakse üldiselt MySQL-is eraldi metabaasi. Üks sait – ühes klastris. Ja selle sees toimub killustamine vastavalt külastajate tunnustele.
Salvestamisel jagame need külastaja ID jaotuse jäägiga. Kuid uue killu lisamisel jagamise skeem muutub; jätkame poolitamist, kuid ülejäänud osa jagamisest teise numbriga. See tähendab, et üks külastaja asub juba mitmes serveris ja sellele ei saa loota. Seda tehakse ainult selleks, et tagada andmete parem tihendamine. Ja päringute tegemisel läheme tabelisse Distributed, mis vaatab klastrit ja pääseb juurde kümnetele serveritele. See on nii rumal skeem.
Aga mu jutt jääb poolikuks, kui ma ei ütle, et me sellest skeemist loobusime. Uues skeemis muutsime kõike ja kopeerisime kõik andmed, kasutades clickhouse-copier.
Uues skeemis on kõik saidid jagatud kahte kategooriasse - suured ja väikesed. Ma ei tea, kuidas seal lävi valiti, kuid selle tulemusel selgus, et ühes klastris salvestatakse suured saidid, kus igas on 120 kildu kolme koopiaga - see tähendab 360 serverit. Ja killustamise skeem on selline, et iga päring läheb kõikidele kildudele korraga. Kui avate nüüd Yandex.Metricas avito.ru mis tahes aruandelehe, suunatakse päring 120 serverisse. Runetis on vähe suuri saite. Ja taotlusi pole mitte tuhat sekundis, vaid isegi alla saja. Seda kõike närib vaikselt Distributed tabel, millest igaüks töötleb 120 serverit.
Ja teine klaster on väikeste saitide jaoks. Siin on jagamisskeem saidi ID järgi ja iga päring läheb täpselt ühele killule.
ClickHouse'il on Clickhouse-koopiamasina utiliit. Kas saate meile temast rääkida?
Pean kohe ütlema, et see lahendus on tülikam ja mõnevõrra vähem tootlik. Eeliseks on see, et see määrib andmed täielikult vastavalt teie määratud skeemile. Kuid utiliidi puuduseks on see, et see ei hakka üldse uuesti tükeldama. See kopeerib andmed ühest klastri skeemist teise klastri skeemi.
See tähendab, et selle toimimiseks peab teil olema kaks klastrit. Need võivad asuda samades serverites, kuid sellest hoolimata ei liigutata andmeid järk-järgult, vaid kopeeritakse.
Näiteks servereid oli neli, nüüd on kaheksa. Lood kõigis serverites uue Distributed tabeli, uued lokaalsed tabelid ja käivitad clickhouse-copier, määrates selles tööskeemi, mida ta sealt lugema peaks, aktsepteerima uut jagamisskeemi ja edastama sinna andmed. Ja vanadel serveritel läheb vaja poolteist korda rohkem ruumi kui praegu, sest vanad andmed peavad sinna jääma ja pooled samad vanad andmed tulevad nende peale. Kui arvasite ette, et andmed tuleb uuesti killustada ja ruumi on, siis see meetod sobib.
Kuidas Clickhouse-koopiamasin sees töötab? See jagab kogu töö ülesannete kogumiks ühe tabeli ühe partitsiooni töötlemiseks ühel killul. Kõik need ülesanded võivad töötada paralleelselt ja clickhouse-copier võib käitada erinevates masinates mitut eksemplari, kuid see, mida see ühe partitsiooni jaoks teeb, pole midagi muud kui sisestamise valik. Andmed loetakse, pakkitakse lahti, jaotatakse ümber, seejärel tihendatakse uuesti, kirjutatakse kuhugi, sorteeritakse ümber. See on raskem otsus.
Teil oli piloot, mida nimetatakse uuesti killustatuks. Mis temaga saab?
2017. aastal oli teil piloot, mida kutsuti taastükeldamiseks. ClickHouse'is on isegi valik. Ma saan aru, et see ei tõusnud. Kas oskate öelda, miks see juhtus? Tundub, et see on väga asjakohane.
Kogu probleem seisneb selles, et kui teil on vaja andmeid uuesti paika panna, on selle atomaarseks tegemiseks vaja väga keerulist sünkroonimist. Kui hakkasime uurima, kuidas see sünkroniseerimine töötab, sai selgeks, et seal on põhimõttelised probleemid. Ja need fundamentaalsed probleemid pole mitte ainult teoreetilised, vaid hakkasid end kohe ka praktikas näitama millegi kujul, mida saab väga lihtsalt seletada – miski ei tööta.
Kas enne aeglastele ketastele üleminekut on võimalik kõik andmete osad kokku liita?
Küsimus TTL-i kohta koos üleminekuga aeglasele kettale liitmiste kontekstis. Kas on võimalik muul viisil kui cron ühendada kõik osad üheks enne aeglastele ketastele üleminekut?
Küsimusele, kas kõik tükid on võimalik enne teisaldamist kuidagi automaatselt üheks liimida, on eitav. Mulle tundub, et see pole vajalik. Te ei saa kõiki osi üheks liita, vaid lihtsalt tugineda asjaolule, et need kantakse automaatselt üle aeglastele ketastele.
Meil on üleviimise reeglite jaoks kaks kriteeriumi. Esimene on siis, kui see täitub. Kui praegusel salvestustasemel on vaba ruumi alla teatud protsendi, valime ühe tüki ja teisaldame selle aeglasemale salvestusruumile. Õigemini, mitte aeglasemalt, vaid järgnevalt – kuidas seadistad.
Teine kriteerium on suurus. Ta räägib suurte tükkide teisaldamisest. Saate reguleerida läve kiirketta vaba ruumi alusel ja andmed migreeritakse automaatselt.
Kuidas minna üle ClickHouse'i uutele versioonidele, kui ühilduvust pole võimalik eelnevalt kontrollida?
Seda teemat arutatakse regulaarselt võttes arvesse erinevaid versioone, ja veel. Kui turvaline on uuendada versioonilt 19.11 versioonile 19.16 ja näiteks versioonilt 19.16 versioonile 20.3. Kuidas on parim viis uutele versioonidele üle minna, ilma et saaksite eelnevalt liivakastis ühilduvust kontrollida?
Siin on mõned kuldreeglid. Esiteks - . See on suur, kuid tagasiühildumatute muudatuste kohta on eraldi punktid. Ärge käsitlege neid esemeid punase lipuna. Need on tavaliselt väikesed kokkusobimatused, mis on seotud mõne servafunktsiooniga, mida te tõenäoliselt ei kasuta.
Teiseks, kui liivakastis ei ole võimalik ühilduvust kontrollida ja soovite kohe tootmist uuendada, ei ole soovitatav seda teha. Esmalt looge liivakast ja testige. Kui testkeskkonda pole, siis suure tõenäosusega pole sul väga suurt ettevõtet, mis tähendab, et saad osa andmetest sülearvutisse kopeerida ja veenduda, et kõik sellel töötab õigesti. Saate isegi mõned koopiad oma masinas kohapeal kuvada. Või võid tõsta kuskile lähedale uue versiooni ja sinna mingid andmed üles laadida – ehk teha eksprompt testkeskkonna.
Teine reegel on see, et mitte värskendada nädala jooksul pärast versiooni väljaandmist, kuna ilmnevad vead tootmises ja sellele järgnevad kiirparandused. Mõistame ClickHouse'i versioonide nummerdamist, et mitte segadusse sattuda.
Olemas on versioon 20.3.4. Number 20 tähistab tootmisaastat - 2020. Sees oleva seisukohast pole see oluline, seega me ei pööra sellele tähelepanu. Edasi - 20.3. Teist numbrit – antud juhul 3 – suurendame iga kord, kui väljalaseme mõne uue funktsiooniga väljalase. Kui tahame ClickHouse'i mõne funktsiooni lisada, peame seda arvu suurendama. See tähendab, et versioonis 20.4 töötab ClickHouse veelgi paremini. Kolmas number on 20.3.4. Siin on 4 väljaannete arvu, millesse me ei lisanud uusi funktsioone, vaid parandasime mõned vead. Ja 4 tähendab, et tegime seda neli korda.
Ärge arvake, et see on midagi kohutavat. Tavaliselt saab kasutaja installida uusima versiooni ja see töötab ilma probleemideta tööajaga aastas. Kuid kujutage ette, et mõnes meie hiina seltsimeeste lisatud bitikaartide töötlemise funktsioonis jookseb server kokku valede argumentide edastamisel. Peame selle parandama. Anname välja uue plaastri versiooni ja ClickHouse muutub stabiilsemaks.
Kui teil on ClickHouse tootmises ja ClickHouse'i uus versioon ilmub koos lisavõimalustega - näiteks 20.4.1 on kõige esimene, ärge kiirustage seda esimesel päeval tootmisse panema. Miks seda üldse vaja on? Kui te veel ClickHouse'i ei kasuta, siis saate selle installida ja tõenäoliselt läheb kõik hästi. Aga kui ClickHouse töötab juba stabiilselt, siis hoidke plaastritel ja uuendustel silm peal, et näha, milliseid probleeme me parandame.
Kirill Shvakov: Tahan lisada veidi testkeskkondade kohta. Kõik kardavad väga testkeskkondi ja millegipärast usuvad, et kui sul on väga suur ClickHouse'i klaster, siis ei tohiks testkeskkond olla väiksem või vähemalt kümme korda väiksem. See pole üldse nii.
Võin öelda oma näitel. Mul on projekt ja seal on ClickHouse. Meie testikeskkond tema jaoks on Hetzneris paarikümne euro eest väike virtuaalmasin, kus on kasutusele võetud absoluutselt kõik. Selleks on meil Ansible'is täielik automatiseerimine ja seetõttu pole põhimõtteliselt vahet, kus veeretada - raudserverites või lihtsalt virtuaalmasinates.
Mida saaks teha? Tore oleks ClickHouse'i dokumentatsioonis tuua näide väikese klastri iseseisva juurutamise kohta - Dockeris LXC-s võib-olla luua Ansible mänguraamat, kuna erinevatel inimestel on erinevad juurutused. See muudab paljud asjad lihtsamaks. Kui võtate ja juurutate klastri viie minutiga, on palju lihtsam proovida midagi välja mõelda. Nii on palju mugavam, sest testimata versiooni tootmisse viimine viib kuhugi. Mõnikord see töötab ja mõnikord mitte. Ja seega on edu loota halb.
Maxim Kotyakov, vanem taustainsener Avito: Lisan natukene testkeskkondade kohta, mis on seotud suurte ettevõtete probleemidega. Meil on täisväärtuslik ClickHouse'i vastuvõtuklaster, andmeskeemide ja seadistuste poolest on see täpne koopia tootmises olevast. See klaster on juurutatud üsna ammendatud konteinerites minimaalsete ressurssidega. Sinna kirjutame teatud protsendi tootmisandmetest, õnneks on kafkas võimalik voogu korrata. Seal on kõik sünkroniseeritud ja skaleeritud – nii võimsuse kui vooluhulga osas ning teoreetiliselt, kui kõik muud asjad on võrdsed, peaks see mõõdikute osas käituma nagu tootmine. Kõik potentsiaalselt plahvatusohtlik veeretatakse esmalt sellele alusele ja jäetakse sinna mitmeks päevaks, kuni see on valmis. Kuid loomulikult on see lahendus kallis, keeruline ja selle tugikulud on nullist erinevad.
Aleksei Milovidov: Ma räägin teile, milline on meie Yandex.Metrica sõprade testikeskkond. Ühes klastris oli umbes 600 serverit, teises 360 ning kolmandas ja mitu klastrit. Neist ühe testimiskeskkond on vaid kaks killust, millest kummaski on kaks koopiat. Miks kaks kildu? Et mitte üksi olla. Ja koopiad ka, et olla. Lihtsalt mingi minimaalne summa, mida saate endale lubada.
See testkeskkond võimaldab teil kontrollida päringute seisukorda ja seda, kas midagi on suures plaanis katki. Tihti tekivad aga hoopis teistsuguse iseloomuga probleemid, kui kõik toimib, kuid koormusega kaasnevad väikesed muutused.
Lubage mul tuua teile näide. Otsustasime installida ClickHouse'i uue versiooni. See on postitatud testkeskkonda, Yandex.Metricas endas on lõpule viidud automatiseeritud testid, mis võrdlevad andmeid vana ja uue versiooni kohta, jooksutades kogu torujuhtme. Ja muidugi meie CI rohelised testid. Muidu poleks me seda versiooni isegi välja pakkunud.
Kõik on korras. Hakkame tootmisse üle minema. Saan teate, et graafikute koormus on mitu korda suurenenud. Pöörame versiooni tagasi. Vaatan graafikut ja näen: tegelikult kasvas koormus mitu korda kasutuselevõtu ajal ja vähenes tagasi, kui need välja veeresid. Seejärel hakkasime versiooni tagasi kerima. Ja koormus kasvas samamoodi ja langes samamoodi tagasi. Järeldus on siis järgmine: koormus on paigutuse tõttu suurenenud, pole midagi üllatavat.
Siis oli raske veenda kolleege uut versiooni installima. Ma ütlen: "Pole midagi, veeretage välja. Hoidke pöialt, kõik läheb korda. Nüüd on koormus edetabelites suurenenud, aga kõik on korras. Oota." Üldiselt tegime seda ja kõik - versioon postitatakse tootmiskohale. Kuid peaaegu iga arvutuse korral tekivad sarnased probleemid.
Kill query peaks päringud hävitama, kuid see ei juhtu. Miks?
Minu juurde tuli kasutaja, mingi analüütik, ja tegi teatud päringu, mis pani minu ClickHouse klastri. Mõni sõlm või terve klaster, olenevalt sellest, millisesse koopiasse või killusse päring sattus. Ma näen, et kõik selle serveri CPU ressursid on riiulis, kõik on punane. Samal ajal vastab ClickHouse ise päringutele. Ja ma kirjutan: "Palun näidake mulle protsesside loendit, milline taotlus selle hulluse tekitas."
Ma leian selle taotluse ja kirjutan sellele kill. Ja ma näen, et midagi ei juhtu. Minu server on riiulis, ClickHouse annab siis mõned käsud, näitab, et server on elus ja kõik on korras. Kuid minu kõigis kasutajataotlustes on halvenemine, ClickHouse'i sisenemine algab ja minu tapmispäring ei tööta. Miks? Arvasin, et tapmispäring peaks päringud hävitama, kuid see ei juhtu.
Nüüd tuleb üsna kummaline vastus. Asi on selles, et tapmispäring ei tapa taotlusi.
Kill-päring märgib väikese kasti nimega "Ma tahan, et see päring taptaks". Ja taotlus ise vaatab seda lippu iga ploki töötlemisel. Kui see on määratud, lakkab taotlus töötamast. Selgub, et keegi ei tapa taotlust, ta peab ise kõike kontrollima ja lõpetama. Ja see peaks toimima kõigil juhtudel, kui päring on andmeplokkide töötlemise olekus. See töötleb järgmist andmeplokki, kontrollib lippu ja peatub.
See ei tööta juhtudel, kui taotlus on mõne toimingu puhul blokeeritud. Tõsi, see pole tõenäoliselt teie juhtum, sest teie sõnul kasutab see hunnikut serveriressursse. Võimalik, et välise sorteerimise ja mõne muu detaili puhul see ei tööta. Kuid üldiselt ei tohiks see nii olla, see on viga. Ja ainus, mida saan nõustada, on ClickHouse'i värskendamine.
Kuidas arvutada lugemiskoormuse ajal reageerimisaega?
Seal on tabel, mis salvestab kaupade agregaadid - erinevad loendurid. Liinide arv on umbes sada miljonit. Kas on võimalik arvestada prognoositava reageerimisajaga, kui valate 1K RPS-i 1K esemele?
Konteksti järgi otsustades räägime lugemiskoormusest, sest kirjutamisega probleeme pole - vähemalt tuhat, vähemalt sada tuhat ja mõnikord mitu miljonit rida saab sisestada.
Lugemissoovid on väga erinevad. Valitud 1 puhul suudab ClickHouse täita umbes kümneid tuhandeid päringuid sekundis, nii et isegi ühe võtme taotlused nõuavad juba teatud ressursse. Ja sellised punktipäringud on keerulisemad kui mõnes võtmeväärtuste andmebaasis, kuna iga lugemise jaoks on vaja lugeda andmeplokk indeksi kaupa. Meie indeks ei käsitle iga kirjet, vaid iga vahemikku. See tähendab, et peate lugema kogu vahemikku - need on vaikimisi 8192 rida. Ja tihendatud andmeploki tuleb lahti pakkida 64 KB-lt 1 MB-le. Tavaliselt võtavad sellised punktipäringud aega mõnest millisekundist. Kuid see on kõige lihtsam variant.
Proovime lihtsat aritmeetikat. Kui korrutate mõne millisekundi tuhandega, saate mõne sekundi. Tundub, nagu oleks võimatu sammu pidada tuhande päringuga sekundis, kuid tegelikult on see võimalik, kuna meil on mitu protsessorituuma. Nii et põhimõtteliselt mahub ClickHouse mõnikord 1000 RPS-i, kuid lühikeste päringute puhul konkreetselt sihitud päringud.
Kui teil on vaja ClickHouse'i klastrit skaleerida lihtsate päringute arvu järgi, siis soovitan kõige lihtsamat - suurendage koopiate arvu ja saatke päringud juhuslikule koopiale. Kui üks koopia mahutab viissada päringut sekundis, mis on täiesti realistlik, siis kolm koopiat mahutab poolteist tuhat.
Mõnikord saab muidugi ka ClickHouse'i seadistada maksimaalse punktinäitude arvu jaoks. Mida selleks vaja on? Esimene on indeksi detailsuse vähendamine. Samas ei tohiks seda vähendada ühele, vaid lähtuda sellest, et registri kirjete arv oleks mitu miljonit või kümneid miljoneid serveri kohta. Kui tabelis on sada miljonit rida, saab täpsuseks määrata 64.
Kokkusurutud ploki suurust saate vähendada. Selleks on sätted min tihendusploki suurus, maksimaalne tihendusploki suurus. Saate neid vähendada, andmeid uuesti laadida ja siis on punktipäringud kiiremad. Kuid siiski ei ole ClickHouse võtmeväärtuste andmebaas. Suur hulk väikeseid taotlusi on laadimisvastane muster.
Kirill Shvakov: Annan nõu juhuks, kui on tavalisi raamatupidajaid. See on üsna tavaline olukord, kui ClickHouse'is on salvestatud mingi loendur. Mul on kasutaja, ta on sellisest ja sellisest riigist, mõnest teisest kolmandast valdkonnast ja ma pean midagi järk-järgult suurendama. Võtke MySQL, tehke unikaalne võti - MySQL-is on see duplikaatvõti ja PostgreSQL-is on see konflikt - ja lisage plussmärk. See toimib palju paremini.
Kui teil pole palju andmeid, pole ClickHouse'i kasutamisel erilist mõtet. Seal on regulaarsed andmebaasid ja nad teevad seda hästi.
Mida ClickHouse'is muuta, et vahemälus oleks rohkem andmeid?
Kujutagem ette olukorda - serverites on 256 GB muutmälu, igapäevases rutiinis kulub ClickHouse'ile ca 60-80 GB, tipphetkel - kuni 130. Mida saab lubada ja timmida, et vahemälus oleks rohkem andmeid ja vastavalt sellele , on kettale vähem sõite?
Tavaliselt teeb operatsioonisüsteemi lehe vahemälu sellega head tööd. Kui avad lihtsalt ülaosa, vaatad sinna vahemällu või vaba – seal on ka kirjas, kui palju vahemällu on –, siis märkad, et kogu vaba mälu kasutatakse vahemälu jaoks. Ja neid andmeid lugedes ei loeta neid kettalt, vaid RAM-ist. Samas võin öelda, et vahemälu kasutatakse efektiivselt, sest vahemällu salvestatakse just tihendatud andmed.
Kui aga soovite mõnda lihtsat päringut veelgi kiirendada, on võimalik ClickHouse'i sees dekompresseeritud andmetes lubada vahemälu. Seda nimetatakse tihendamata vahemälu. Seadistage konfiguratsioonifailis config.xml tihendamata vahemälu suuruseks vajalik väärtus - soovitan mitte rohkem kui pool vabast RAM-ist, sest ülejäänud osa läheb lehe vahemälu alla.
Lisaks on kaks päringu taseme seadet. Esimene seadistus - kasutada tihendamata vahemälu - hõlmab selle kasutamist. Soovitatav on see lubada kõigi päringute jaoks, välja arvatud raskete päringute jaoks, mis saavad lugeda kõiki andmeid ja tühjendada vahemälu. Ja teine säte on umbes nagu vahemälu kasutamise maksimaalne ridade arv. See piirab automaatselt suuri taotlusi, nii et need on vahemälust möödas.
Kuidas konfigureerida RAM-i salvestamiseks atribuuti storage_configuration?
Uues ClickHouse'i dokumentatsioonis lugesin sellega seotud jaotist . Kirjelduses on näide kiire SSD-ga.
Huvitav, kuidas saate sama helitugevuse kuummäluga konfigureerida. Ja veel üks küsimus. Kuidas valik selle andmekorraldusega töötab, kas see loeb kogu komplekti või ainult kettal olevat ja kas need andmed tihendatakse mällu? Ja kuidas prewhere sektsioon sellise andmekorralduse juures töötab?
See säte mõjutab andmete salvestamist ja nende vorming ei muutu kuidagi.
Vaatame lähemalt.
Saate seadistada andmete salvestamise RAM-is. Kõik, mis on ketta jaoks konfigureeritud, on selle tee. Loote tmpfs-i partitsiooni, mis ühendatakse failisüsteemis mõnele teele. Määrake see tee kuumima partitsiooni andmete salvestamise teeks, andmed hakkavad saabuma ja sinna kirjutama, kõik on korras.
Kuid ma ei soovita seda teha madala töökindluse tõttu, kuigi kui teil on erinevates andmekeskustes vähemalt kolm koopiat, saate seda teha. Kui jah, siis andmed taastatakse. Kujutage ette, et server lülitati ootamatult välja ja uuesti sisse. Sektsioon paigaldati uuesti, kuid seal on tühimik. Käivitamisel näeb ClickHouse'i server, et need tükid on puudu, kuigi ZooKeeperi metaandmete järgi peaksid nad olema. Ta vaatab, millistel koopiatel need on, küsib neid ja laadib need alla. Seega andmed taastatakse.
Selles mõttes ei erine andmete salvestamine RAM-is põhimõtteliselt kettale salvestamisest, sest kettale kirjutades langevad need ka esmalt lehe vahemällu ja kirjutatakse hiljem füüsiliselt. See sõltub sellest, kuidas failisüsteem on ühendatud. Aga igaks juhuks ütlen, et ClickHouse ei fsync on insert.
Sel juhul salvestatakse RAM-is olevad andmed täpselt samas vormingus nagu kettale. Valimispäring valib samamoodi lugemiseks olevad tükid, valib tükkides vajalikud andmevahemikud ja loeb need. Ja prewhere töötab täpselt samamoodi, olenemata sellest, kas andmed olid RAM-is või kettal.
Kui mitme kordumatu väärtuseni on Low Cardinality efektiivne?
Madal kardinaalsus on keeruline. See koostab andmesõnastikke, kuid need on kohalikud. Esiteks on sõnastikud iga kirjatüki jaoks erinevad ja teiseks võivad need isegi ühe tüki piires olla iga vahemiku jaoks erinevad. Kui unikaalsete väärtuste arv jõuab künnise - ma arvan, miljon -, jäetakse sõnastik lihtsalt kõrvale ja luuakse uus.
Vastus on üldine: iga kohaliku vahemiku puhul – näiteks iga päeva kohta – kuskil kuni miljon kordumatut väärtust on madal kardinaalsus efektiivne. Pärast seda on lihtsalt varu, milles kasutatakse palju erinevaid sõnastikke, mitte ainult ühte. See töötab samamoodi nagu tavaline stringi tüüpi veerg, võib-olla veidi vähem tõhusalt, kuid see ei põhjusta tõsist jõudluse halvenemist.
Millised on parimad tavad täisteksti otsimiseks viie miljardi reaga tabelis?
Vastuseid on erinevaid. Esimene on öelda, et ClickHouse ei ole täisteksti otsingumootor. Selleks on olemas spetsiaalsed süsteemid, näiteks и . Siiski näen üha rohkem inimesi, kes ütlevad, et liiguvad Elasticsearchilt ClickHouse'i.
Miks see juhtub? Nad seletavad seda asjaoluga, et Elasticsearch ei tule toime mõne köite koormusega, alustades indeksite ehitamisest. Indeksid muutuvad liiga kohmakaks ja kui andmed lihtsalt ClickHouse'i üle kanda, selgub, et need salvestatakse mahu poolest kordades tõhusamalt. Samas ei olnud otsingupäringud sageli sellised, et kogu andmehulgast oleks vaja morfoloogiat arvestades leida mingi fraas, vaid hoopis teistsugused. Näiteks mõne baitide alamjada jaoks logidest viimase paari tunni leidmiseks.
Sel juhul loote ClickHouse'is indeksi, mille esimeseks väljaks on kuupäev koos ajaga. Ja suurim andmete piirang on täpselt kuupäevavahemiku kohta. Valitud kuupäevavahemikus on reeglina juba võimalik teostada täistekstiotsingut isegi brute-force meetodil kasutades like. ClickHouse'i sarnane avaldus on kõige tõhusam sarnane avaldus, mida võite leida. Kui leiate parema, ütle mulle.
Kuid ikkagi, nagu on täielik skaneerimine. Ja täielik skannimine võib olla aeglane mitte ainult protsessoris, vaid ka kettal. Kui teil on järsku üks terabait andmemahtu päevas ja te otsite päeva jooksul sõna, peate skannima terabaidi. Ja tõenäoliselt on see tavalistel kõvaketastel ja selle tulemusel laaditakse need nii, et te ei sisene SSH kaudu sellesse serverisse.
Sel juhul olen valmis pakkuma veel ühe väikese nipi. See on eksperimentaalse kategooriast – see võib töötada või mitte. ClickHouse'il on täisteksti indeksid trigrammi õitsengufiltrite kujul. Meie Arenada kolleegid on neid indekseid juba proovinud ja sageli töötavad need täpselt nii, nagu ette nähtud.
Nende õigeks kasutamiseks peaksite hästi teadma, kuidas need täpselt töötavad: mis on trigrammi õitsemise filter ja kuidas selle suurust valida. Võin öelda, et need aitavad päringuid mõne haruldase fraasi, alamstringi kohta, mida andmetes harva leidub. Sel juhul valitakse alamvahemikud indeksite järgi ja loetakse vähem andmeid.
ClickHouse on hiljuti lisanud täistekstiotsingu jaoks veelgi täpsemaid funktsioone. Esiteks otsitakse korraga korraga hulga alamstringe, sealhulgas tõstutundlikke, tõstutundlikke, UTF-8-toega või ainult ASCII-valikuid. Valige kõige tõhusam, mida vajate.
Ühes läbimises otsiti ka mitut regulaaravaldist. Te ei pea kirjutama X-i ühe alamstringina ega X-i nagu teise alamstringina. Kirjutage kohe ja kõik tehakse nii tõhusalt kui võimalik.
Kolmandaks on nüüd olemas ligikaudne regexpi ja alamstringide ligikaudne otsing. Kui keegi kirjutas sõna kirjaveaga, otsitakse sellest maksimaalset vastet.
Milline on parim viis ClickHouse'i juurdepääsu korraldamiseks suurele hulgale kasutajatele?
Rääkige meile, kuidas kõige paremini korraldada juurdepääsu paljudele tarbijatele ja analüütikutele. Kuidas moodustada järjekorda, prioriseerida maksimaalselt samaaegseid päringuid ja milliste tööriistadega?
Kui klaster on piisavalt suur, siis oleks hea lahendus tõsta veel kaks serverit, millest saab analüütikute sisenemispunkt. See tähendab, et ärge laske analüütikuid konkreetsetesse klastrikildudesse, vaid looge lihtsalt kaks tühja serverit ilma andmeteta ja määrake neile juba juurdepääsuõigused. Samal ajal edastatakse kasutaja seaded hajutatud päringute ajal kaugserveritesse. See tähendab, et konfigureerite kõik nendes kahes serveris ja seaded mõjutavad kogu klastrit.
Põhimõtteliselt on need serverid ilma andmeteta, kuid päringute täitmiseks on nende RAM-i maht väga oluline. Ketast saab kasutada ka ajutiste andmete jaoks, kui väline koondamine või väline sortimine on lubatud.
Oluline on vaadata seadeid, mis on seotud kõigi võimalike piirangutega. Kui ma lähen nüüd analüütikuks Yandex.Metrica klastrisse ja küsin päringu valige tabamuste arv, siis tehakse mulle kohe erand, et ma ei saa palvet täita. Maksimaalne ridade arv, mida mul on lubatud skaneerida, on sada miljardit ja ühes tabelis on klastris kokku viiskümmend triljonit. See on esimene piirang.
Oletame, et eemaldan ridade arvu piirangu ja käivitan päringu uuesti. Siis näen järgmist erandit – säte on lubatud jõuindeks kuupäeva järgi. Ma ei saa päringut käivitada, kui ma pole kuupäevavahemikku määranud. Selle käsitsi sisestamiseks ei pea te lootma analüütikutele. Tüüpiline juhtum - kuupäevavahemik on kirjutatud, kus sündmuse kuupäev jääb nädala vahele. Ja siis nad lihtsalt ei määranud seal sulgu ja selle asemel osutus see või - või URL-i vasteks. Kui piirangut pole, roomab see URL-i veerus ja raiskab palju ressursse.
Lisaks on ClickHouse'il kaks prioriteetseadistust. Kahjuks on nad väga primitiivsed. Ühte nimetatakse lihtsalt prioriteet. Kui prioriteet ≠ 0 ja teatud prioriteediga päringud täidetakse, kuid täidetakse madalama prioriteediga taotlus, mis tähendab kõrgemat prioriteeti, siis päring prioriteedi väärtusega suurem kui, mis tähendab madalamat prioriteeti lihtsalt peatatud ja ei tööta selle aja jooksul üldse.
See on väga konarlik seadistus ja ei sobi olukordades, kus klastril on pidev koormus. Kuid kui teil on lühikesed impulsiivsed taotlused, mis on olulised ja klaster on enamasti jõude, sobib see seade.
Kutsutakse järgmine prioriteedi seadistus OS-i lõime prioriteet. See lihtsalt paljastab kõik päringu täitmislõimed Linuxi planeerija jaoks meeldiva väärtusega. See töötab nii ja naa, aga töötab ikkagi. Kui seate väga minimaalse kena väärtuse – see on väärtuselt suurim ja seega ka madalaima prioriteediga – ja määrate kõrge prioriteediga päringute jaoks väärtuseks –19, siis tarbib protsessor madala prioriteediga päringuid umbes neli korda vähem kui kõrge prioriteediga päringuid.
Samuti peate määrama päringu maksimaalse täitmise aja – näiteks viis minutit. Minimaalne päringu täitmise kiirus on kõige lahedam asi. See säte on kehtinud pikka aega ja seda ei nõuta mitte ainult kinnitamiseks, et ClickHouse ei aeglusta, vaid ka selleks, et seda sundida.
Kujutage ette, et seadistate: kui päring töötleb vähem kui miljon rida sekundis, ei saa te seda teha. See rikub meie head nime ja meie head andmebaasi. Keelame ära. Seadeid on tegelikult kaks. Ühte kutsutakse minimaalne täitmiskiirus - ridades sekundis ja sekundit nimetatakse enne minimaalse täitmiskiiruse kontrollimist ajalõpuks - vaikimisi viisteist sekundit. See tähendab, et viisteist sekundit on võimalik ja kui aeglaselt, siis tehke lihtsalt erand - katkestage taotlus.
Samuti peate määrama kvoodid. ClickHouse'il on sisseehitatud kvoodifunktsioon, mis loeb ressursitarbimist. Kuid kahjuks mitte raudressursid, nagu protsessor, kettad, vaid loogilised - töödeldud päringute arv, loetud read ja baitid. Ja saate seadistada näiteks maksimaalselt sada päringut viie minuti jooksul ja tuhat päringut tunnis.
Miks see oluline on? Kuna mõned analüüsipäringud täidetakse käsitsi otse ClickHouse'i kliendist. Ja kõik saab korda. Aga kui teie ettevõttes on edasijõudnud analüütikud, kirjutavad nad skripti ja skriptis võib olla viga. Ja see viga põhjustab päringu täitmise lõpmatus tsüklis. Seda tuleb kaitsta.
Kas ühe päringu tulemusi on võimalik anda kümnele kliendile?
Meil on mitu kasutajat, kellele meeldib korraga sisse tulla väga suurte päringutega. Taotlus on suur, põhimõtteliselt täidetakse kiiresti, kuid tänu sellele, et selliseid taotlusi on korraga palju, muutub see väga valusaks. Kas sama päringut, mis saabus kümme korda järjest, on võimalik täita ühe korra ja anda tulemus kümnele kliendile?
Probleem on selles, et meil pole vahemälu tulemusi ega vahepealset andmevahemälu. Operatsioonisüsteemis on lehe vahemälu, mis võimaldab teil kettalt andmeid uuesti mitte lugeda, kuid kahjuks tehakse andmed siiski lahti, deserialiseeritakse ja töödeldakse uuesti.
Tahaks seda kuidagi vältida, kas vaheandmete vahemällu salvestades või sarnased päringud mingisse järjekorda reastades ja tulemuste vahemälu lisades. Nüüd on meil arenduses üks tõmbepäring, mis lisab päringu vahemälu, kuid ainult alamtaotluste jaoks sisse- ja liitumissektsioonides – see tähendab, et lahendus on kehvem.
Meil on aga ka selline olukord. Eriti kanooniline näide on leheküljenumbriga päringud. Seal on aruanne, sellel on mitu lehekülge ja päring on limiit 10. Siis sama asi, aga limiit 10,10. Siis teine leht. Ja küsimus on, miks me seda kõike iga kord kokku loeme? Kuid praegu pole lahendust ja seda ei saa kuidagi vältida.
On olemas alternatiivne lahendus, mis asetatakse ClickHouse'i kõrvale külgkorviks - .
Kirill Shvakov: ClickHouse Proxyl on sisseehitatud kiiruse piiraja ja sisseehitatud tulemuste vahemälu. Seal on palju seadistusi tehtud, sest sarnane ülesanne sai lahendatud. Puhverserver võimaldab teil taotlusi piirata, asetades need järjekorda, ja konfigureerida, kui kaua päringu vahemälu kestab. Kui päringud olid tõesti samad, esitab puhverserver need mitu korda ja läheb ClickHouse'i ainult üks kord.
Nginxil on ka tasuta versioonis vahemälu ja see töötab ka. Nginxil on isegi sätted, nii et kui päringud tulevad samal ajal, peatab see teised, kuni üks lõpetab. Aga just ClickHouse'i puhverserveris tehakse sätteid palju paremaks. See tehti spetsiaalselt ClickHouse'i jaoks, spetsiaalselt nende taotluste jaoks, nii et see on sobivam. Noh, seda on lihtne seadistada.
Kuidas on lood asünkroonsete operatsioonide ja materialiseeritud vaadetega?
Tekib selline probleem, et toimingud asendava mootoriga on asünkroonsed – andmed kirjutatakse esmalt, siis kukuvad kokku. Kui tahvelarvuti all elab materialiseerunud tahvelarvuti koos mõningate agregaatidega, siis kirjutatakse sinna duplikaadid. Ja kui keerulist loogikat pole, siis andmed dubleeritakse. Mida sellega teha saab?
On ilmne lahendus – rakendada asünkroonse kokkuvarisemise ajal päästikut konkreetsele matview klassile. Kas sellist funktsionaalsust on plaanis rakendada?
Tasub mõista, kuidas deduplikatsioon töötab. See, mida ma teile nüüd ütlen, ei ole küsimusega seotud, kuid igaks juhuks tasub seda meeles pidada.
Replitseeritud tabelisse sisestamisel eemaldatakse kogu sisestatud plokkide dubleerimine. Kui sisestate uuesti sama ploki, mis sisaldab sama arvu samu ridu samas järjekorras, siis andmed dubleeritakse. Saate vastuseks sisestamisele "Ok", kuid tegelikult kirjutatakse üks andmepakett ja seda ei dubleerita.
See on vajalik kindluse tagamiseks. Kui sisestamise ajal kuvatakse "Ok", siis on teie andmed sisestatud. Kui saate ClickHouse'ilt veateate, tähendab see, et neid pole sisestatud ja peate sisestamist kordama. Aga kui ühendus katkeb sisestamise ajal, siis sa ei tea, kas andmed on sisestatud või mitte. Ainus võimalus on sisestust uuesti korrata. Kui andmed tegelikult sisestati ja te sisestasite need uuesti, toimub plokkide dubleerimine. See on vajalik dubleerimise vältimiseks.
Ja oluline on ka see, kuidas see materialiseerunud vaadete puhul toimib. Kui põhitabelisse sisestamisel andmed dubleeriti, siis ei lähe need ka materialiseeritud vaatesse.
Nüüd küsimusest. Teie olukord on keerulisem, kuna kirjutate üksikute ridade duplikaate. See tähendab, et mitte kogu pakk ei dubleerita, vaid konkreetsed read ja need vajuvad taustal kokku. Tõepoolest, andmed põhitabelis tõmbuvad kokku ja ahendamata andmed lähevad materialiseeritud vaatesse ning materialiseeritud vaadetega ei juhtu liitmise ajal midagi. Kuna materialiseeritud vaade pole midagi muud kui sisestuse päästiku. Muude operatsioonide ajal sellega midagi muud ei juhtu.
Ja ma ei saa siin õnnelik olla. Selle juhtumi jaoks on vaja ainult konkreetset lahendust otsida. Näiteks, kas seda on võimalik asendada materialiseeritud vaates ja võib-olla töötab deduplikatsioonimeetod samamoodi. Kuid kahjuks mitte alati. Kui see koondab, siis see ei tööta.
Kirill Shvakov: Meil oli omal ajal ka luuehitus. Tekkis probleem, et on reklaamide näitamisi ja on andmeid, mida saame reaalajas näidata – need on vaid näitamised. Neid dubleeritakse harva, aga kui juhtub, siis ahendame need niikuinii. Ja oli asju, mida ei saa dubleerida – klõpsud ja kogu see lugu. Aga ma tahtsin neid ka peaaegu kohe näidata.
Kuidas tehti materialiseeritud vaateid? Oli vaateid, kus kirjutatakse otse - algandmetes on kirje ja see on vaadetes kirjas. Seal ei ole mingil hetkel andmed väga õiged, dubleeritakse jne. Ja seal on tabeli teine osa, kus need näevad välja täpselt samasugused kui materialiseerunud vaated, st on oma ülesehituselt täpselt samasugused. Aeg-ajalt arvutame andmed ümber, loendame andmed ilma duplikaatideta, kirjutame nendesse tabelitesse.
Läbisime API - see ei tööta ClickHouse'is käsitsi. Ja API vaatab: kui mul on tabelis viimase lisamise kuupäev, kus on garanteeritud, et õiged andmed on juba arvutatud ja teeb päringu ühte tabelisse ja teise tabelisse. Ühest päringust valitakse kuni teatud ajavahemik ja teisest saab see, mida pole veel arvutatud. Ja see töötab, kuid mitte ühe ClickHouse'i abil.
Kui teil on mingi API - analüütikutele, kasutajatele -, siis põhimõtteliselt on see valik. Sa loed alati, loe alati. Seda saab teha üks kord päevas või mõnel muul ajal. Valite ise selle vahemiku, mida te ei vaja ja mis pole kriitiline.
ClickHouse'il on palju logisid. Kuidas ma näen kõike, mis serveriga hetkega juhtub?
ClickHouse'is on väga palju erinevaid logisid ja see arv kasvab. Uutes versioonides on osa neist isegi vaikimisi lubatud, vanemates versioonides tuleb need uuendamisel lubada. Neid tuleb aga aina juurde. Tahaks lõpuks näha, mis minu serveriga praegu toimub, võib-olla mõnel kokkuvõtlikul armatuurlaual.
Kas teil on ClickHouse'i meeskonnas või teie sõprade meeskondades, kes toetavad mõnda funktsionaalsust valmis armatuurlaudadest, mis neid logisid valmistootena kuvaksid? Lõppkokkuvõttes on lihtsalt ClickHouse'i logide vaatamine suurepärane. Aga oleks väga lahe, kui see oleks juba armatuurlaua kujul ette valmistatud. Ma läheksin sellest kõrgele.
Armatuurlaudu on, kuigi need pole standardiseeritud. Meie ettevõttes on ClickHouse'i kasutamas umbes 60 meeskonda ja kõige kummalisem on see, et paljudel neist on nende enda tehtud armatuurlauad ja veidi teistsugused. Mõned meeskonnad kasutavad Yandex.Cloudi sisemist installi. On olemas mõned valmis aruanded, kuigi mitte kõik vajalikud. Teistel on oma.
Minu kolleegidel Metricast on Grafanas oma armatuurlaud ja minul on oma nende klastri jaoks. Ma vaatan selliseid asju nagu vahemälu tabamus serifi vahemälu jaoks. Ja veelgi keerulisem on see, et kasutame erinevaid tööriistu. Lõin oma armatuurlaua väga vana tööriistaga, mille nimi on Graphite-web. Ta on täiesti kole. Ja ma kasutan seda siiani nii, kuigi Grafana oleks ilmselt mugavam ja ilusam.
Armatuurlaudade põhiasi on sama. Need on klastri süsteemimõõdikud: protsessor, mälu, ketas, võrk. Muud – samaaegsete päringute arv, samaaegsete liitmiste arv, taotluste arv sekundis, MergeTree tabelipartitsioonide maksimaalne tükkide arv, replikatsiooni viivitus, replikatsioonijärjekorra suurus, sisestatud ridade arv sekundis, sisestatud plokkide arv sekundis. See on kõik, mis saadakse mitte logidest, vaid mõõdikutest.
Vladimir Kolobaev: Aleksei, ma tahaksin natuke parandada. Seal on Grafana. Grafanal on andmeallikas ClickHouse. See tähendab, et saan Grafanalt taotlusi esitada otse ClickHouse'ile. ClickHouse'is on tabel logidega, see on kõigile sama. Selle tulemusena tahan ma Grafanas sellele logitabelile juurde pääseda ja näha päringuid, mida mu server rakendab. Oleks tore omada sellist armatuurlauda.
Ise sõitsin rattaga. Kuid mul on küsimus - kui see kõik on standarditud ja Grafanat kasutavad kõik, siis miks ei ole Yandexil sellist ametlikku armatuurlauda?
Kirill Shvakov: Tegelikult toetab ClickHouse'i andmeallikas nüüd Altinityt. Ja ma tahan lihtsalt anda vektori, kuhu kaevata ja keda lükata. Võite neilt küsida, sest Yandex teeb ikkagi ClickHouse'i, mitte lugu selle ümber. Altinity on praegu peamine ClickHouse'i reklaamiv ettevõte. Nad ei hülga teda, vaid toetavad teda. Sest põhimõtteliselt tuleb Grafana veebilehele armatuurlaua üleslaadimiseks vaid registreeruda ja see üles laadida – erilisi probleeme pole.
Aleksei Milovidov: Viimase aasta jooksul on ClickHouse lisanud palju päringute profileerimise funktsioone. Iga ressursikasutuse taotluse kohta on olemas mõõdikud. Ja viimasel ajal on lisatud veelgi madalama taseme päringuprofiil, et näha, kuhu päring iga millisekundi kulub. Kuid selle funktsiooni kasutamiseks pean avama konsoolikliendi ja sisestama päringu, mille unustan. Salvestasin selle kuhugi ja unustan alati, kus täpselt.
Soovin, et oleks tööriist, mis lihtsalt ütleb – siin on teie rasked päringud, mis on rühmitatud päringuklasside kaupa. Klõpsasin ühel ja nad ütlesid mulle, et see on seetõttu raske. Nüüd sellist lahendust pole. Ja see on tõesti üsna kummaline, et kui inimesed küsivad minult: "Ütle mulle, kas Grafana jaoks on valmis armatuurlaudu?", vastan: "Minge Grafana veebisaidile, seal on Dashboardsi kogukond ja seal on Dimka armatuurlaud. , seal Kostjanilt. Ma ei tea, mis see on, ma pole seda ise kasutanud."
Kuidas mõjutada merdzhit nii, et server OOM-i ei satuks?
Mul on tabel, tabelis on ainult üks partitsioon, see on ReplaceingMergeTree. Olen sinna andmeid kirjutanud neli aastat. Pidin seda muutma ja mõned andmed kustutama.
Tegin seda ja selle päringu töötlemise käigus söödi klastri kõigi serverite kogu mälu ära ja kõik klastri serverid läksid koos OOM-i. Siis tõusid nad kõik koos püsti, hakkasid ühte ja sama toimingut, seda andmeplokki, liitma ja sattusid jälle OOM-i. Siis tõusid nad uuesti püsti ja kukkusid uuesti maha. Ja see asi ei peatunud.
Siis selgus, et see on tegelikult viga, mille poisid parandasid. See on väga lahe, tänan teid väga. Aga jääk jäi. Ja kui ma nüüd mõtlen sellele, et tabelis on vaja teatud liitmist teha, siis tekib mul küsimus – miks ma ei võiks neid liitmisi võtta ja kuidagi mõjutada? Näiteks piirake neid vajaliku RAM-i hulga või põhimõtteliselt nende arvuga, mis seda konkreetset tabelit töötleb.
Mul on tabel nimega "Mõõdikud", palun töötle seda minu jaoks kahes lõimes. Pole vaja paralleelselt luua kümmet või viit liitmist, tehke seda kahekesi. Arvan, et mul on kahe jaoks piisavalt mälu, aga kümne töötlemiseks ei pruugi sellest piisata. Miks hirm jääb? Kuna tabel kasvab ja kunagi seisan silmitsi olukorraga, mis põhimõtteliselt ei tulene enam veast, vaid sellest, et andmed muutuvad nii suures mahus, et mul lihtsalt ei jätku mälu server. Ja siis jookseb server ühendamisel OOM-i. Pealegi võin ma mutatsiooni tühistada, kuid Merjit pole enam.
Teate küll, liitmisel ei satu server OOM-i, sest liitmisel kulub RAM-i hulk vaid ühe väikese andmevahemiku jaoks. Nii et kõik läheb hästi olenemata andmemahust.
Vladimir Kolobaev: Hästi. Siin on hetk selline, et peale veaparanduse tegemist laadisin endale uue versiooni ja teises väiksemas lauas, kus on palju partitsioone, tegin sarnase toimingu. Ja ühendamise käigus põletati serveris umbes 100 GB RAM-i. Mul oli 150 hõivatud, sõin 100 ja aken oli 50 GB, nii et ma ei langenud OOM-i.
Mis kaitseb mind praegu OOM-i sattumise eest, kui see tegelikult tarbib 100 GB muutmälu? Mida teha, kui liidetud RAM saab äkki otsa?
Aleksei Milovidov: On selline probleem, et RAM-i tarbimine ei piirdu merdzhiga. Ja teine probleem on see, et kui ühendamine on määratud, siis tuleb see käivitada, sest see on kirjutatud replikatsiooni logisse. Replikatsioonilogi on toimingud, mida on vaja replika järjepidevasse olekusse viimiseks. Kui te ei tee käsitsi manipuleerimisi, et see replikatsioonilogi tagasi keeraks, tuleb liitmine ühel või teisel viisil läbi viia.
Muidugi poleks üleliigne piirata RAM-i, mis "igaks juhuks" kaitseb OOM-i eest. See ei aita ühinemisele kaasa, see alustab uuesti, jõuab mingi läveni, teeb erandi ja alustab siis uuesti – sellest ei tule midagi head. Aga põhimõtteliselt oleks kasulik see piirang kehtestada.
Kuidas toimub ClickHouse'i Golangi draiveri arendamine?
Kirill Shvakovi kirjutatud Golangi draiverit toetab nüüd ametlikult ClickHouse'i meeskond. Ta , on ta nüüd suur ja tõeline.
Väike märkus. Seal on suurepärane ja armastatud lõpmatu korra normaalvormide hoidla – see on Vertica. Neil on ka oma ametlik pythoni draiver, mida haldavad Vertica arendajad. Ja mitu korda juhtus, et salvestusruumi versioonid ja draiveri versioonid läksid üsna järsult lahku ning draiver lakkas mingil hetkel töötamast. Ja teine punkt. Mulle tundub, et selle ametliku draiveri tuge säilitab "nipple" süsteem - kirjutate neile probleemi ja see hangub igavesti.
Mul on kaks küsimust. Nüüd on Kirilli Golangi draiver peaaegu vaikeviisiks Golangist ClickHouse'iga suhtlemiseks. Kui just keegi ikka läbi http liidese ei suhtle, sest see talle nii meeldib. Kuidas seda draiverit arendatakse? Kas see sünkroonitakse hoidla enda murranguliste muudatustega? Ja milline on probleemi käsitlemise kord?
Kirill Shvakov: Esimene on see, kuidas kõik on bürokraatlikult korraldatud. Seda punkti pole arutatud, seega pole mul midagi vastata.
Probleemi puudutavale küsimusele vastamiseks vajame veidi juhi ajalugu. Töötasin ettevõttes, kus oli palju andmeid. See oli reklaamikeerutaja, kus oli tohutult palju sündmusi, mida oli vaja kuhugi salvestada. Ja mingil hetkel ilmus ClickHouse. Kallasime sinna andmed ja alguses oli kõik korras, aga siis ClickHouse kukkus. Sel ajal otsustasime, et meil pole seda vaja.
Aasta hiljem pöördusime tagasi ClickHouse'i kasutamise idee juurde ja meil oli vaja sinna kuidagi andmed kirjutada. Sisend oli selline - raud on väga nõrk, ressursse on vähe. Kuid me oleme alati nii töötanud ja seetõttu vaatasime omakeelse protokolli poole.
Kuna töötasime Go kallal, oli selge, et vajame Go draiverit. Tegin seda peaaegu täiskohaga – see oli minu tööülesanne. Kuni teatud hetkeni tõime selle üles ja põhimõtteliselt ei oodanud keegi, et keegi peale meie seda kasutab. Siis tuli CloudFlare täpselt sama probleemiga kaasa ja mõnda aega töötasime nendega väga sujuvalt, sest neil olid samad ülesanded. Ja me tegime seda nii ClickHouse'is endas kui ka draiveris.
Mingil hetkel ma lihtsalt lõpetasin selle tegemise, sest minu aktiivsus ClickHouse'i ja tööga on veidi muutunud. Seetõttu ei ole probleemid suletud. Aeg-ajalt pühenduvad hoidlasse inimesed, kes ise midagi vajavad. Siis vaatan tõmbamistaotlust ja vahel isegi muudan midagi ise, aga seda juhtub harva.
Tahan naasta juhi juurde. Paar aastat tagasi, kui kogu see asi alguse sai, oli ClickHouse ka teistsugune ja erinevate funktsioonidega. Nüüd on tekkinud arusaam, kuidas juht ümber teha nii, et see hea oleks. Kui see juhtub, on versioon 2 nagunii kokkusobimatu kogunenud karkude tõttu.
Ma ei tea, kuidas seda korraldada. Mul endal pole palju aega. Kui mõni inimene lõpetab juhi, saan neid aidata ja öelda, mida teha. Kuid Yandexi aktiivne osalemine projekti väljatöötamises pole veel mingil moel arutatud.
Aleksei Milovidov: Tegelikult pole nende juhtide osas veel bürokraatiat. Ainus asi on see, et need viiakse üle ametlikku organisatsiooni, see tähendab, et see draiver tunnistatakse Go ametlikuks vaikelahenduseks. On ka teisi juhte, aga need tulevad eraldi.
Meil pole nende draiverite jaoks mingit arendust sees. Küsimus on selles, kas saame palgata üksikisiku, mitte spetsiaalselt selle juhi jaoks, vaid kõigi kogukonna juhtide arendamiseks, või leiame kellegi väljastpoolt.
Välist sõnastikku ei avata pärast taaskäivitamist, kui lazy_load on lubatud. Mida teha?
Meil on säte lazy_load lubatud ja pärast serveri taaskäivitamist ei tõuse sõnastik ise. See tõstetakse üles alles pärast seda, kui kasutaja seda sõnaraamatut külastab. Ja see annab esimesel kõnel vea. Kas ClickHouse'i abil on võimalik kuidagi automaatselt sõnastikke laadida või tuleb alati nende valmisolekut ise kontrollida, et kasutajatele ei tekiks vigu?
Võib-olla on meil ClickHouse'i vana versioon, nii et sõnastikku ei laaditud automaatselt. See võiks olla?
Esiteks saab sõnaraamatuid päringu abil sundlaadida süsteemi sõnaraamatute uuesti laadimine. Teiseks vea kohta - kui sõnastik on juba laaditud, siis päringud töötavad laaditud andmetega. Kui sõnastikku pole veel laaditud, siis laaditakse see kohe päringu esitamise hetkel.
Raskete sõnaraamatute jaoks pole see eriti mugav. Näiteks peate MySQL-ist tooma miljon rida. Keegi teeb lihtsa valiku, kuid see valik ootab sama miljonit rida. Siin on kaks lahendust. Esimene on lazy_load väljalülitamine. Teine on siis, kui server tõuseb, enne selle koormuse sisselülitamist süsteemi uuesti laadimise sõnastik või lihtsalt täitke sõnaraamatut kasutav päring. Seejärel laaditakse sõnaraamat. Peate kontrollima sõnastike saadavust, kui säte laisa_koormus on lubatud, kuna ClickHouse ei tõmba neid automaatselt üles.
Vastus viimasele küsimusele on see, et versioon on vana või tuleb seda siluda.
Mis saab sellest, et süsteemi uuesti laadimise sõnastikud ei laadi paljudest sõnastikest ühtegi, kui vähemalt üks neist jookseb veaga kokku?
Süsteemi uuesti laadimise sõnaraamatute kohta on veel üks küsimus. Meil on kaks sõnaraamatut – üks on laadimata, teine on laetud. Süsteemi uuesti laadimise sõnaraamatud ei laadi sel juhul ühtegi sõnastikku ja konkreetse sõna tuleb punktist punkti laadida selle nime järgi, kasutades süsteemi uuesti laadimissõnastikku. Kas see on seotud ka ClickHouse'i versiooniga?
Ma tahan meeldida. See käitumine on muutunud. Seega, kui uuendate ClickHouse'i, muutub see ka. Kui te ei ole praeguse käitumisega rahul süsteemi sõnaraamatute uuesti laadimine, värskendage ja loodame, et see muutub paremaks.
Kas ClickHouse'i konfiguratsioonis on võimalik üksikasju konfigureerida, kuid mitte vigade korral valgustada?
Järgmine küsimus puudutab sõnastikuga seotud vigu, nimelt üksikasju. Oleme registreerinud ClickHouse konfiguratsioonis olevad ühenduse andmed sõnastikku ja vea korral saame need andmed ja parooli vastuseks.
Lahendasime selle vea, lisades ODBC draiveri konfiguratsiooni üksikasjad. Kas ClickHouse'i konfiguratsioonis on võimalik üksikasju kuidagi konfigureerida, kuid mitte neid detaile vigade puhul esile tuua?
Siin on lahendus tõesti - nende mandaatide määramiseks failis odbc.ini ja ClickHouse'is endas määrake ainult ODBC andmeallika nimi. Teiste sõnastikuallikate puhul seda ei juhtu – ei MySQL-iga sõnastiku ega ka muu puhul ei tohiks te veateates parooli näha. ODBC jaoks vaatan ka - kui selline asi on, siis tuleb see lihtsalt eemaldada.
Boonus: Zuma taustad koosviibimistelt
Pildile klõpsates avanevad kõige järjekindlamatele lugejatele boonus taustad koosviibimistelt. Koos Avito tehnikamaskottidega tuld kustutamas, kolleegidega süsteemiadministraatoritoast või vanakooli arvutiklubist nõu pidamas ning silla all grafiti taustal päevapäeva pidamine.
Allikas: www.habr.com