ClickHouse for advanced users in questions and answers

Aprillis kavatsevad Avito insenerid osaleda veebikohtumisel ClickHouse peaarendaja Aleksei Milovidovi ja Integrosest pärit Golang-arendaja Kirill Shvakoviga. Räägime, kuidas me kasutame andmebaasi haldussüsteemi ja millised probleemid meil tekivad.

Kohtumise põhjal koostasime artikli, kus eksperdid vastavad meie ja vaatajatel esitatud küsimustele varukoopiate, andmete resharde, välistes sõnastikes, Golang-draiverite ja ClickHouse versioonide uuendamise kohta. See võib olla kasulik arendajatele, kes juba aktiivselt töötavad Yandexi DB-ga ja huvituvad selle olevikust ja tulevikust. Aleksei Milovidovi vastused on vaikimisi, kui ei ole märgitud teisiti.

Ole ettevaatlik, kuna allpool on palju teksti. Loodame, et küsimuste sisu aitab teil orientiire leida.

Sisukord

• ClickHouse värskendatakse pidevalt, kuid meie andmed ei. Mida sellega teha?
• Millised on praegu parimad praktikud ClickHouse andmete varundamiseks?
• Kas saab korraldada reprod kontrollitud hilinemisega?
• Mida teha, kui tabeli struktuur on muutunud?
• Millised on üldiselt parimad praktikud andmete resharde osas?
• ClickHouse'is on utiliit clickhouse-copier. Kas saate sellest rääkida?
• Teie oli pilootprojekt, mis kandis nime resharde. Mis selle on saanud?
• Kas on võimalik koondada kõik andmeosad enne aeglastele kettale üleminekut?
• Kuidas liikuda uutele ClickHouse versioonidele, kui ei ole võimalik eelnevalt ühilduvust kontrollida?
• Kill query peab tapma päringuid, kuid see ei toimi. Miks?
• Kuidas arvutada vastuse aega lugemise koormuse puhul?
• Mida tuneerida ClickHouse'is, et rohkem andmeid oleks vahemälus?
• Kuidas saab seadistada storage_configuration töötamise eesmärgil?
• Kuni millise unikaalsete väärtuste arvuni on Low Cardinality efektiivne?
• Millised on parimad praktikud täisteksti otsinguks tabelis, kus on viis miljardit rida?
• Kuidas korraldada ClickHouse'i juurdepääsu suurele kasutajate arvule?
• Kas on võimalik edastada ühe päringu tulemused kümnele kliendile?
• Kuidas olla asünkroonsete toimingute ja materialiseeritud vaadete puhul?
• ClickHouse'is on palju logisid. Kuidas saan näha kõike, mis serveriga hetkel juhtub?
• Kuidas mõjutada merge protsesse, et server ei kukuks OOM-i?
• Kuidas toimub Golang-draiveri arendamine ClickHouse'i jaoks?
• Väline sõnastik ei tõuse pärast taaskäivitamist üles, kui lazy_load seadistus on lubatud. Mida teha?
• Kuidas olla olukorras, kus system reload dictionaries ei saada ühtegi mitmest sõnastikust, kui vähemalt üks neist langeb veaga?
• Kas on võimalik ClickHouse konfiguratsioonis seadistada akreditiivid, kuid mitte näidata neid vigade korral?
• Boonus: taustad Zoomi koosolekute jaoks

Kui te ei soovi teksti lugeda, võite vaadata koosolekute salvestust meie YouTube'i kanalis. Ajakoodid on video esimese kommentaari all.

ClickHouse uuendab end pidevalt, kuid meie andmed ei uuene. Mida selleks teha?

ClickHouse uuendab end pidevalt, kuid meie andmed, mis olid optimize final töödeldud, ei uuene ja jäävad varukoopia alla.

Oletame, et meil on tekkinud mingi probleem ja andmed on kadunud. Otsustasime taastuda, ja selgus, et vanad partiid, mis on serverites varundamiseks, erinevad väga palju praegu kasutusel olevast ClickHouse versioonist. Mida sellises olukorras teha ja kas see on võimalik?

Olukord, kus te taastate varukoopiast andmed vanas formaadis, kuid uuemas versioonis nad ei sobi, ei ole võimalik. Me jälgime, et ClickHouse andmeformaat oleks alati tagasiühilduv. See on palju olulisem kui tagasipööratavus funktsionaalsuse osas, kui mõne harva kasutatava funktsiooni käitumine on muutunud. Andmed, mis on salvestatud kettale, peaks uus ClickHouse versioon alati olema suuteline lugema. See on seadus.

Millised on praegu parimad praktikud ClickHouse andmete varundamiseks?

Kuidas teha varukoopiaid, arvestades, et meil on optimize final operatsioonid, tohutud andmebaasid terabaitides ja andmed, mis uuenevad, oletame, viimase kolme päeva jooksul, ning edasi nendega mingit protseduuri ei toimu?

Me võime kasvatada oma lahendust ja bashis kirjutada: korralda niimoodi ja niimoodi need varukoopiad. Võib-olla ei ole vajagi midagi kasvatada, ja jalgratas on juba ammu välja mõeldud?

Alustuseks parimate praktikate kohta. Minu kolleegid soovitavad alati küsimustele varukoopiate kohta vastates meenutada teenust 'Yandex.Cloud', kus see ülesanne on juba lahendatud. Nii et kasutage seda, kui on selline võimalus.

Täielikku lahendust, mis oleks100% integreeritud ClickHouse'iga, varukoopiate jaoks ei ole. On olemas mõned malli, mida saab kasutada. Täieliku lahenduse saamiseks tuleb kas veidi käsitsi vaeva näha või teha skripti kujul ümbriseid.

Alustan kõige lihtsamatest lahendustest ja lõpetan kõige keerukamatega olenevalt andmete mahust ja klastrite suurusest. Mida suurem on klaster, seda keerulisemaks lahendus muutub.

Kui andmetabel hõivab ainult paar gigabaiti, saab varukoopia teha nii:

1. Salvesta tabelite määratlemine, st metaandmed — show create table.
2. Tee dump ClickHouse kliendi abil — select * from table faili. Vaikimisi saad faili TabSeparated formaadis. Kui soovid tõhusamalt, saad formaadis Native.

Kui andmete maht on suurem, siis varukoopia võtab rohkem aega ja palju ruumi. Seda nimetatakse loogiliseks varukoopiateks, see ei ole seotud ClickHouse andmeformaadiga. Kui see on olemas, saad hädaolukorras varukoopia võtta ja taastada MySQL-s.

Rohkemate edasijõudnute juhtumite jaoks on ClickHouse'is sisseehitatud võimalus luua partitsioonide snapshots kohalikus failisüsteemis. See võimalus on saadaval päringuna alter table freeze partition. Või lihtsalt alter table freeze — see on kogu tabeli snapshot.

Snapshot luuakse ühtlaselt ühe tabeli kohta ühes shardis, seega ei ole võimalik luua ühtlast snapshot'i kogu klastrist. Kuid enamike ülesannete jaoks ei ole seda vajalik, ja piisab, kui igas shardis teha päring ja saada ühtlane snapshot. See luuakse kõvadest linkidest ja seetõttu ei võta see lisaruumi. Edasi kopeerid selle snapshot'i varukoopia serverisse või hoidlatesse, mida kasutad varukoopiate jaoks.

Sellise varukoopia taastamine on piisavalt lihtne. Esimene — lood tabelid vastavalt olemasolevatele tabelite määratlemistele. Edasi kopeerid salvestatud partitsioonide snapshot'id Directory-Detached antud tabelite jaoks ja täidad päringu attach partition. Selline lahendus sobib täiesti suurte andmemahtude jaoks.

Mõnikord on vaja midagi veel ägedamat – olukordades, kus teil on igas serveris kümneid või isegi sadu terabajte ja sadu servereid. Siin on lahendus, mille ma märkasin kolleegidelt "Yandex.Metrica". Ma ei soovitaks seda igaleühele – lugege ise ja otsustage, kas see sobib või mitte.

Esialgu on vaja luua mitu serverit suurte kettalahendustega. Seejärel tõstatage nendele serveritele mitu ClickHouse serverit ja seadistage need nii, et need töötaksid nagu veel üks koopiate replikatsioon samadele shard'idele. Edasi kasutage nende serverite failisüsteemi või mingit tööriista, mis võimaldab luua snapshot'e. Siin on kaks võimalust. Esimene variant – LVM snapshot'id, teine variant – ZFS Linuxil.

Pärast seda tuleb igapäevaselt luua snapshot, mis jääb alles ja võtab mingi ruumi. Loomulikult, kui andmed muutuvad, siis aja jooksul suureneb ruum. Seda snapshot'i saab igal ajal välja võtta ja andmeid taastada, selline kummaline lahendus. Pluss peab veel piirama neid replikaid konfiguratsioonis, et nad ei püüaks saada liidriteks.

Kas saab korraldada reprod kontrollitud hilinemisega?

Sel aastal plaanite teha valusid ClickHouse'is. Kas oleks võimalik organiseerida neis kontrollitud replikate mahajäämus? Sooviksime selle abil end negatiivsete stsenaariumide eest kaitsta, sealhulgas altrite ja muude muudatuste eest.

Kas on võimalik teha mõningaid tagasikäike altritele? Näiteks võtta olemasolevast valust ja öelda, et kuni selle hetkeni rakenda muudatused, aga sellest hetkest alates lõpetage muudatuste rakendamine?

Kui meie klastrisse tuleb käsk ja rikub selle, siis meil on tinglik replik, mille mahajäämus on tund, kus me saame öelda, et kasutame just seda praegu, aga viimasest kümnest minutist tehtud muudatusi me rakendada ei soovi?

Esialgu kontrollitud replikate mahajäämusest. Kasutajate seas oli selline soov, ja me lõime GitHubis küsimuse: "Kui kellelegi see vajalik on, pange meeldimisi, pange südameid". Keegi ei pannud ja küsimus suleti. Siiski, juba praegu on võimalik saada selline võimalus, seadistades ClickHouse’i. Tõeletruult, alates versioonist 20.3.

ClickHouse tegevalt taustal andmete liitmist — merge. Kui merge on tehtud, asendatakse teatud andmeplokkide kogum suurema plokiga. Samal ajal jäävad varem olnud andmeplokid kettale teatud ajaks.

Esiteks, nad jäävad alles seni, kuni on olemas select-päringud, mis neid kasutavad, et tagada mitteblokeeriv töö. Select-päringud saavad rahulikult lugeda vanadest plokkidest.

Teiseks on ka ajapiirang — vanad andmeplokid jäävad kettale kaheks minutiks. Need kaheksa minutit on seadistatavad ja neid saab muuta isegi üheks päevaks. See maksab kettaruumi: sõltuvalt andmete voogust võib juhtuda, et viimase päeva andmeid mitte ainult ei kahekordistata, vaid need võivad olla viis korda suuremad. Kuid tõsiste probleemide korral saate ClickHouse serveri peatada ja kõik korda teha.

Nüüd tekib küsimus, kuidas see kaitseb alterite vastu. Siin tasub sügavamale vaadata, sest ClickHouse vanemates versioonides töötas alter niimoodi, et vahetas lihtsalt plokid. On andmeplokk, kus on mingid failid, ja me teeme näiteks alter drop column. Siis see veerg füüsiliselt eemaldatakse kõigist plokkidest.

Aga alates versioonist 20.3 on alterite mehhanism täielikult muudetud ja nüüd on andmeplokid alati immutatiivsed. Need ei muutu üldse — alterid töötavad nüüd umbes sama moodi nagu merge'id. Selle asemel, et plokk koha peal muuta, loome uue. Uues plokis, kus failid ei ole muutunud, muutuvad need kõvade linkideks, ja kui me oleme mõne veeru eemaldanud, siis seda ei ole lihtsalt uues plokis. Vana plokk eemaldatakse vaikimisi kaheksa minuti pärast, ja siin saab reguleerida seadistusi, millest ülalpool räägiti.

Sama kehtib ka alterite kohta, mis on seotud mutatsioonidega. Kui teete alter delete või alter update, siis see ei muuda plokki, vaid loob uue. Ja siis eemaldab vana.

Mida teha, kui tabeli struktuur on muutunud?

Kuidas taastada varukoopia, mis tehti vana skeemi alusel? Ja teine küsimus on seoses snapshot'ide ja failisüsteemide vahenditega. Kas Btrfs sobib siin ZFS asemel Linux LVM-is?

Kui teete attach partition Kui partitsioonid on teistsuguse struktuuriga, siis ClickHouse ütleb teile, et nii ei saa. Lahendus on järgmine. Esiteks, looge ajutine MergeTree tüüpi tabel vanema struktuuriga, lisage sinna andmed attach abil, seejärel tehke alter päring. Siis saate kas kopeerida või liigutada need andmed ning teha attach uuesti, või kasutada päringut. alter table move partition.

Nüüd teine küsimus – kas Btrfs-i kasutada on võimalik. Esiteks, kui teil on LVM, siis piisab LVM snapshot'idest, failisüsteem võib olla ka ext4, see ei oma tähtsust. Btrfs-i puhul sõltub kõik teie kogemusest selle kasutamisel. See on küps failisüsteem, kuid siiski on tekkinud mõningaid kahtlusi selle osas, kuidas kõik praktikas toimib konkreetse stsenaariumi puhul. Ma ei soovitaks seda kasutada, kui teil ei ole Btrfs-i tootmisrežiimis.

Millised on üldiselt parimad praktikud andmete resharde osas?

Pereshardimise küsimus on keeruline ja mitmekesine. Siin saab kohe reageerida mitmeti. Üks võimalus on öelda, et ClickHouse'is ei ole sisse ehitatud võimalust pereshardimiseks. Kuid kardan, et see vastus ei rahulda kedagi. Seetõttu võib teise nurga alt öelda, et ClickHouse'is on palju viise andmete pereshardimiseks.

Kui klastris on koht otsas või see ei saa koormusega hakkama, lisate uusi servereid. Kuid need serverid on vaikimisi tühjad – andmeid neis ei ole, koormust ei toimu. Teil on vaja andmeid ümber paigutada, et need oleksid uues, suurendatud klastris ühtlaselt jaotatud.

Esimene viis, kuidas seda teha, on kopeerida osa partitsioonidest uutele serveritele päringu abil. alter table fetch partition. Näiteks, kui teil olid partitsioonid kuude kaupa, võtate esimese kuu 2017. aastast ja kopeerite selle uuele serverile, siis – kolmanda kuu kopeerite mõnele muule uuele serverile. Ja nii teete, kuni see on enam-vähem ühtlaselt jaotatud.

Ümberpaigutamine on võimalik ainult nende partitsioonide puhul, mis kirjutamise ajal ei muutu. Uute partitsioonide jaoks tuleb kirjutamine välja lülitada, sest nende ümberpaigutamine ei ole atomaarne. Vastasel juhul saate duplikaate või andmete vahelejääke. Sellegipoolest on see viis praktiline ja töötab piisavalt tõhusalt. Võrgus edastatakse juba valmis, kompresseeritud partitsioonid, see tähendab, et andmeid ei dekompressita ega rekodeerita.

Selle meetodi üks puudus seisneb selles, et see sõltub shardimise skeemist, mille olete üles ehitanud, ja milliseks shardimise võtme olete valinud. Teie näites olenevad metrikate korral shardimise võti – see on tee hash. Kui teete select Distributed tabelisse, suunatakse see kohe kõikidele klastri shardi ja sealt saadakse andmed.

See tähendab, et tegelikult ei oma teile tähtsust, millised andmed millises shardis asuvad. Peamine on see, et andmed ühes ja samas teekonnas asuvad ühes shardis, kuid millises, ei ole oluline. Sellisel juhul sobib valmisteeritud partiide edasiviimine suurepäraselt, kuna select päringute puhul saate te – olenemata sellest, kas enne või pärast shardingut, skeemi väärtused ei oma erilist tähtsust – täieliku ülevaate andmetest.

Aga on ka keerulisemaid juhtumeid. Kui rakenduse tasandil olete üles ehitanud spetsiaalse shardimise skeemi, et see klient asub määratud shardis ja päring saab kohe sinna saata, mitte Distributed tabelisse. Või kasutate piisavalt uut versiooni ClickHouse'ist ja olete lülitanud sisse seade optimize skip unused shards. Sel juhul analüüsitakse select päringu ajal where osas olevat väljendit ning arvutatakse, millistele shardidele tuleb minna vastavalt shardimise skeemile. See toimib tingimusel, et andmed on paigutatud täpselt vastavalt sellele shardimise skeemile. Kui olete need käsitsi ümber paigutanud, võib vastavus muutuda.

Nii et see on esimene meetod. Ootan teie vastust, kas see sobib, või liigume edasi.

Vladimir Kolobaev, juhtiv süsteemiadministraator Avitos: Aleksei, see meetod, mida mainisite, ei sobi hästi, kui tuleb jaotada koormust, sealhulgas ka lugemisel. Saame võtta kuu partiid ja saame eelmise kuu viia teisele sõlmele, kuid kui tuleb päring nende andmete järele, koormame ainult selle. Sooviksime koormata kogu klastrit, sest vastasel juhul, mingil hetkel, kogu lugemiskoormus töödeldakse kahe shardi poolt.

Aleksei Milovidov: Siin on kummaline vastus - jah, halb, aga võib ka toimida. Selgitan, kuidas täpselt. Tuleb vaadata koormusskeemi, mis järgneb teie andmetele. Kui need on jälgimisandmed, siis on peaaegu kindel, et enamik päringutest läheb värskete andmete järele.

Sa panid püsti uued serverid, viisid vanad partitioonid üle, kuid muutsid ka seda, kuidas salvestatakse värskeid andmeid. Ja värsked andmed hakkavad olema laiali kõikjal klastris. Nii et juba viie minutiga koormavad viimase viie minuti päringud ühtlaselt klastrit, päeva jooksul päringud 24 tunni kohta koormavad samuti klastrit ühtlaselt. Kahjuks lähevad eelneva kuu päringud ainult osa klastriserveritest.

Kuid sageli pole teil päringuid just 2019. aasta veebruari kohta. Tõenäoliselt, kui päringud on 2019. aastasse, siis need on kogu 2019. aasta kohta - suure ajaintervali kohta, mitte mingisuguse väikese vahemiku kohta. Ja sellised päringud suudavad samuti klastrit ühtlaselt koormata. Ent kokkuvõttes on teie tähelepanek täiesti õige, et see on selline ad hoc lahendus, mis ei hajuta andmeid täiesti ühtlaselt.

Mul on veel mõned punktid vastamiseks küsimusele. Üks neist on, kuidas algselt luua sharimisinfo skeem selliselt, et ümberjaotamisest oleks vähem vaeva. See ei pruugi alati olla võimalik.

Näiteks, teil on jälgimisandmed. Jälgimisandmed kasvavad kolmel põhjusel. Esimene - ajalooliste andmete kogumine. Teine - liikluse kasv. Ja kolmas - jälgimise alla kuuluvaid asjade arvu suurenemine. Tekivad uued mikroteenused ja mõõdikud, mida tuleb salvestada.

Võimalik, et neist on kõige suurem kasv seotud just kolmanda põhjusega - see on jälgimise kasutamise suurenemine. Ja antud juhul tasub vaadata koormuse iseloomu, millisest päringute valikust peaks lähtuma. Põhilised päringud valiku osas tulevad tõenäoliselt mõnest alamkogumist mõõdikutest.

Näiteks CPU kasutamine mingitel serveritel mingis teenuses. Tulemuseks on see, et on olemas teatud alamhulk võtmeid, mille alusel te need andmed välja tõite. Ja andmete päring ise on tõenäoliselt piisavalt lihtne ja toimub kümnete millisekundite jooksul. Kasutatakse jälgimisteenustes, armatuurlaudadel. Loodan, et mõistan seda õigesti.

Vladimir Kolobaev: Küsimus on selles, et me sageli tugineme ajaloolistele andmetele, kuna me reaalajas võrdleme praegust seisu ajaloolistega. Meile on oluline, et kiire juurdepääs suurele andmemahtudele oleks olemas, ja ClickHouse toimetab sellega suurepäraselt.

Te olete täiesti õigustatud, enamik lugemisotsuseid on meil viimase päeva jooksul, nagu igasugustes jälgimisteenustes. Kuid ajaloolistele andmetele on koormus samuti piisavalt suur. See tuleb peamiselt häirete süsteemist, mis iga kolmekümne sekundi tagant küsib ClickHouse'ilt: "Anna mulle andmed viimase kuue nädala jooksul. Nüüd ehita mulle nende põhjal mingi libisev keskmine ja võrrelge praegust väärtust ajaloolisega."

Tahaksin öelda, et meil on selliste väga värskete päringute jaoks olemas veel üks väike tabel, millel hoiame ainult kahe päeva andmeid, ja peamised päringud suunduvad just sinna. Suure sharded tabelisse saadame ainult suuremad ajaloolised päringud.

Aleksei Milovidov: Kahjuks ei sobi see teie stsenaariumi jaoks hästi, kuid räägin kahest halvast ja keerulisest sharding scheemist, mida ei tohiks kasutada, kuid mida mu sõprade teenuses kasutatakse.

On peamine klaster "Yandex.Metrica" sündmustega. Sündmused on lehevaated, klõpsud ja üleminekud. Enamik päringud käivad konkreetse veebisaidi suunas. Te avate teenuse "Yandex.Metrica", teil on veebisait - avito.ru, sisenete aruandesse ja päring läheb teie veebisaidile.

Kuid on ka teisi päringuid - analüütilisi ja globaalseid, mida teevad siseanalüütikud. Huvi pärast märgin, et siseanalüütikud teevad päringuid ainult "Yandexi" teenuste kohta. Siiski, isegi "Yandexi" teenused hõivavad märkimisväärse osa kõigist andmetest. Need päringud ei ole suunatud konkreetsetele mõõdikutele, vaid laiemale filtreerimisele.

Kuidas andmeid korraldada nii, et kõik töötaks tõhusalt nii ühe mõõdiku kaudu kui ka globaalsete päringute puhul? Probleemiks on ka see, et ClickHouse'i päringute hulk klastris "Metriik" on mitu tuhat sekundis. Samas ei suuda üks ClickHouse'i server töödelda mitme tuhande mitte triviaalset päringut sekundis.

Klastri suurus on üle kuue saja serveri. Kui selle klastriga lihtsalt tahame kasutada jaotatud tabelit ning saata sinna mitu tuhat päringut, siis läheb asi hullemaks kui nende saatmine ühte serverisse. Teiselt poolt, variant, kus andmed on ühtlaselt jaotatud ning me küsime kõigilt serveritelt, jääb kohe välja.

On ka diametraalselt vastupidine variant. Kujutage ette, et me jagame andmeid veebisaitide kaupa ning ühe veebisaidi päring läheb ühele shardile. Nüüd suudab klaster tõepoolest taluda kümmet tuhat päringut sekundis, kuid ühel shardil töötav päring võib olla liiga aeglane. See ei suuda enam skaleeruda läbilaskevõime osas. Erinevalt avito.ru-st. Ma ei avalda saladust, kui ütlen, et Avito on üks enimmugeldatavaid saite Venemaa Internetis. Ja selle töötlemine ühel shardil oleks vale.

Seetõttu on sharding'u skeem koostatud keerukamal viisil. Kogu klaster on jagatud teatud arvu klastersüsteemideks, mida nimetame kihtideks. Igas klustri süsteemis on kümne kuni mitme kümne shardiga. Kokku on selliseid klastrisüsteeme kolmkümmend üheksa.

Kuidas see kõik skaleerub? Klastrite arv ei muutu - nagu see oli mitu aastat tagasi kolmkümmend üheksa, nii on see ka jäänud. Kuid igaühes me järk-järgult suurendame shardide arvu andmete kogunedes. Ja sharding'u skeem on üldiselt selline - jagunemine nende klastrisüsteemide kaupa toimub veebisaitide alusel, ja selleks, et mõista, milline sait on millises klastris, kasutatakse tegelikult eraldi metabaasi MySQL-is. Üks sait - ühes klastrisüsteemis. Ja selle sees toimub sharding külastajate identifikaatorite kaupa.

Kandidaatide registreerimisel jagame neid külastaja identifikaatori jäägi järgi. Kuid uue shard'i lisamisel muutub shardimise skeem, me jätkame jagamist, kuid jääk jagamisel on erinev. See tähendab, et üks külastaja on tegelikult mitmel serveril ja sellele ei saa toetuda. See on tehtud ainult selleks, et andmed paremini kokku suruda. Kui aga teeme päringuid, suundume me jaotatud tabelisse, mis vaatab klastrisse ja pöördub kümnete serverite poole. Nii toimib see kummaline skeem.

Aga minu jutt oleks puudulik, kui ma ei ütleks, et sellest skeemist oleme loobunud. Uues skeemis oleme kõik muutnud ja kõik andmed kopeeritud clickhouse-copier'i abil.

Uues skeemis jagunevad kõik saidid kaheks kategooriaks – suurteks ja väikesteks. Ma ei tea, kuidas see künnis valiti, kuid lõpptulemusena kirjutatakse suured saidid ühe klastrisse, kus on 120 shard'i, kolm koopiat igas – see tähendab 360 serverit. Ja shardimise skeem on selline, et iga päring läheb kohe kõigile shard'idele. Kui avate praegu "Yandex.Metrica"-s mis tahes aruande lehe avito.ru jaoks, läheb päring 120 serverile. Suuri saite on venekeelses Internetis vähe. Ja päringute hulk ei ulatu tuhande sekundi kohta, isegi vähem kui sada. Kõiki neid käsitleb rahulikult jaotatud tabel, mille igat neist töötleb 120 serverit.

Teine klaster – väikestele saitidele. Siin on shardimise skeem saidi identifikaatori järgi ja iga päring läheb just ühe shard'i peale.

ClickHouse'is on utiliit clickhouse-copier. Kas saate sellest rääkida?

Kohanen kohe, et see lahendus on mahukam ja veidi vähem tootlik. Eeliseks on see, et see levitab andmed täielikult vastavalt sellele skeemile, mida te näitate. Kuid tõukeratta puuduseks on see, et see ei tee ümbershardimist. See kopeerib andmed ühe klastriskeemiga teise klastriskeemi.

See tähendab, et selle tööks peavad teil olema kaks klastrit. Need võivad asuda samadel serveritel, kuid andmed ei hüppa järk-järgult, vaid kopeeritakse.

Näiteks, kui algselt oli neli serverit, siis nüüd on neid kaheksa. Te loote kõigis serverites uue Distributed tabeli, uued lokaalsed tabelid ja käivitate clickhouse-copier'i, määrates selle töörežiimi, et ta peab lugema sealt, võtma vastu uue sharding skeemi ja üle kandma andmed sinna. Vanadel serveritel on teil vaja ruumi poolteist korda rohkem, kui seda on praegu, sest vanad andmed peavad sinna jääma ning nende peale tuleb pool vanadest andmetest. Kui te olete ette mõelnud, et andmed tuleb üle shardida ja ruumi on piisavalt, siis see meetod sobib.

Kuidas clickhouse-copier sees töötab? Ta jagab kogu töö ülesanneteks, mis töötlevad ühe partitsiooni ühes tabelis ühel shardil. Kõiki neid ülesandeid saab käitada paralleelselt ja clickhouse-copier'i saab käivitada erinevates masinates mitmes eksemplaris, kuid see, mida ta teeb ühe partitsiooni jaoks, on mitte midagi muud, kui insert select. Andmed loetakse, dekompressitakse, jaotatakse uuesti, seejärel kompressitakse uuesti, salvestatakse kuhugi, järjestatakse ümber. See on keerulisem lahendus.

Teie oli pilootprojekt, mis kandis nime resharde. Mis selle on saanud?

Teil oli veel 2017. aastal katse, mis nimetati reshardinguks. Seal on isegi valik ClickHouse'is. Ma saan aru, et see ei õnnestunud. Kas te saaksite rääkida, miks nii juhtus? Tundub, et see oli isegi väga aktuaalne.

Kogu probleem seisneb selles, et andmete kohandatud shardimist nõudva vajaduse korral on vajalik väga keeruline sünkroniseerimine, et seda teha atomaarsemalt. Kui me hakkasime vaatama, kuidas see sünkroniseerimine on üles ehitatud, siis sai selgeks, et on fundamentaalsed probleemid. Ja need fundamentaalsed probleemid pole mitte ainult teoreetilised, vaid hakkasid kohe praktikas end näitama sellega, et võib väga lihtsalt selgitada — mitte midagi ei toimi.

Kas on võimalik koondada kõik andmeosad enne aeglastele kettale üleminekut?

Küsimus TTL-de kohta koos valikuga move to slow disk seoses merge'idega. Kas on mingit võimalust, peale cron'i, liita kõik osad enne aeglastele diskidele üleviimist?

Vastus küsimusele, kas on kuidagi automaatselt võimalik kõik tükid ühte tõmmata enne nende üleviimist — ei. Minu arvates pole selles vajadust. Ei pea kõiki osi ühte liitma, vaid lihtsalt arvestama, et need liiguvad automaatselt aeglastele diskidele.

Meil on kaks kriteeriumi andmete üleviimise reeglite jaoks. Esiteks — täitmise taseme järgi. Kui praeguses salvestusruumis on vähem kui teatud protsent vaba ruumi, valime ühe tüki ja kanname selle üle aeglasemasse salvestusse. Täpsemalt mitte aeglasemasse, vaid järgnevasse — kuidas olete seadistanud.

Teiseks kriteeriumiks on suuruse järgi. See puudutab suurte tükkide üleviimist. Saate kohandada künnist kiire diskiga vaba ruumi osas ja andmed kantakse automaatselt üle.

Kuidas liikuda uutele ClickHouse versioonidele, kui ei ole võimalik eelnevalt ühilduvust kontrollida?

Seda teemat arutatakse regulaarselt ClickHouse'i Telegrami vestluses , arvestades erinevaid versioone, ja kuidagi. Kui ohutu on uuendada versioonilt 19.11 versioonile 19.16 ja näiteks versioonilt 19.16 versioonile 20.3? Kuidas on parem uutele versioonidele üle minna, kui ei ole võimalik eelnevalt kontrollida ühilduvust liivakastis?

Siin on mitu «kuldset» reeglit. Esimene — looge changelog. See on suur, kuid seal on eraldi punktid tagasi ühilduvuse muutuste kohta. Ärge vaadake neid punkte kui punast lippu. Üldiselt on need väikesed ühilduvuse probleemid, mis on seotud mõningate äärmuste funktsionaalsustega, mida teil tõenäoliselt ei ole.

Teine — kui ei ole võimalik kontrollida ühilduvust liivakastis ja soovite uuendada otse tootmises, on soovitus selline — ärge tehke seda. Looge esmalt liivakast ja kontrollige. Kui testimiskeskkonda pole, siis tõenäoliselt ei ole teil väga suurt ettevõtet, seega on võimalik kopeerida osa andmeid oma sülearvutisse ja seal veenduda, et kõik toimib korrektselt. Võib isegi käivitada mitu koopiat kohalikult oma masinas. Või saab kuskil lähedal tõsta uue versiooni ja laadida sinna osa andmeid — st luua improviseeritud testimiskeskkond.

Veel üks reegel — ärge uuendage esimesel nädalal pärast versiooni väljaandmist, kuna tootmises leitakse vigu ja järgnevad kiiret parandused. Vaatame ClickHouse'i versioonide nummerdamist, et mitte segadusse sattuda.

On versioon 20.3.4. Number 20 tähistab väljaandmise aastat — 2020. Sellel ei ole sisu poolest mingit tähtsust, seega ei pea me sellele tähelepanu pöörama. Edasi — 20.3. Teist numbrit — antud juhul 3 — suurendame iga kord, kui välja anname versiooni koos mõne uue funktsiooniga. Kui soovime ClickHouse'i juurde lisada mingi võimaluse, peame seda arvu suurendama. See tähendab, et versioonis 20.4 töötab ClickHouse veelgi paremini. Kolmas number — 20.3.4. Siin 4 on patši väljaandmiste arv, kus me ei ole uusi funktsioone lisanud, kuid oleme mõned vead fikseerinud. Ja 4 tähendab, et oleme seda neli korda teinud.

Ärge arvake, et see on midagi kohutavat. Tavaline kasutaja võib tavaliselt installida kõige värskema versiooni, ja see töötab probleemideta kuni aasta. Kuid kujutage ette, et mõnes funktsioonis, mis puudutab bitmapide töötlemist ja mis on lisatud meie Hiina kolleegide poolt, kukub server alla vale argumentide edastamisel. Me peame selle parandama. Me anname välja uue patši versiooni, ja ClickHouse muutub stabiilsemaks.

Kui teie ClickHouse töötab tootmises ja ilmub uus versioon ClickHouse'ist koos lisafunktsioonidega — näiteks 20.4.1 — siis ärge kiirustage seda tootmisse paigaldama esimesel päeval. Miks see üldse vajalik on? Kui te veel ClickHouse'i ei kasuta, siis võite selle installida ja tõenäoliselt läheb kõik hästi. Kuid kui ClickHouse töötab juba stabiilselt, siis jälgige patše ja uuendusi — milliseid probleeme me parandame.

Kirill Shvakov: Tahaksin lisada veidi testkeskkondade kohta. Kõik kardavad testkeskkondi ja kuidagi arvavad, et kui teil on väga suur ClickHouse'i klaster, siis peab ka testkeskkond olema vähemalt sama suur või vähemalt kümne korra väiksem. See ei ole sugugi nii.

Võin rääkida oma kogemusest. Mul on projekt, kus on ClickHouse. Meie testkeskkond selle jaoks on väike virtuaalmasin Hetzneris kahekümne euro eest, kus on kõik täielikult üles seatud. Et seda teha, on meil täielik automatiseerimine Ansible'is, seega ei ole põhimõtteliselt vahet, kas paigaldada metallserveritesse või lihtsalt virtuaalmasinatesse.

Mida saab teha? Oleks kena, kui ClickHouse'i dokumentatsioonis oleks näide, kuidas endale väike klaster üles seada — Dockeris, LXC-s, võib-olla luua Ansible playbook, kuna erinevatel inimestel on erinevad deploy'd. See lihtsustaks palju. Kui sa saad klastrit üles seada viie minutiga, on palju lihtsam proovida milleski selgusele jõuda. See on palju mugavam, sest uuema versiooniga edasi liikumine, mida sa pole kontrollinud — see on teed tühjusesse. Mõnikord see töötab, aga mõnikord mitte. Ja seepärast lootmine õnnele — on halb.

Maksim Kotjakov, senior backend engineer Avito: Täiendaksin natuke testkeskkondade kohta, mis on suurte ettevõtete probleemide seerias. Meil on täisfunktsionaalne ClickHouse'i testklaster, mis on andmemudelite ja seadistuste poolest täpne koopia sellest, mis on produktsioonis. See klaster on üles seatud üsna vanade konteineritega, millel on minimaalsed ressursid. Me kirjutame sinna teatud protsendi produktsioonandmetest, õnneks on võimalik voogu Kafkas replitseerida. Seal on kõik sünkroonitud ja skaleeritud — nii võimsuste kui voogude osas, ja teoorias peaks see, teiste asjaolude ühtluses, käituma metrite järgi nagu produktsioon. Kõik potentsiaalselt plahvatusohtlik algul läheb sellele seismisele ja seal liguneb paar päeva kuni valmiduseni. Aga loomulikult on see lahendus kallis, raske ja mitte nullikuludega toe osas.

Aleksei Milovidov: Räägin, mida kujutab endast meie sõprade testkeskkond «Yandex.Metrica» juures. Üks klaster oli 600+ serveriga, teine 360 ja on veel kolmas ning mitu klastrit. Ühe jaoks on testkeskkond lihtsalt kaks shard'i, milles igas on kaks replikat. Miks kaks shard'i? Et üks ei oleks. Ja replikad on ka sellepärast, et neid oleks. Lihtsalt teatud minimaalne kogus, mida endale lubada saab.

See testkeskkond võimaldab kontrollida päringute töökorrasolekut ja ei ole suures plaanis midagi purustatud. Kuid tihti tekivad probleemid täiesti teistsuguse iseloomuga, kui kõik töötab, kuid on mõned väikesed muudatused koormuses.

Tooksin näiteks. Otsustasime installeerida uue ClickHouse'i versiooni. See on üles pandud testkeskkonda, automatiseeritud testid on läbinud «Yandex.Metrica's», mis võrreldavad andmeid vana ja uue versiooni vahel, läbides kogu protsessi. Ja loomulikult ka meie CI rohelised testid. Muud juhul me ei olekski seda versiooni soovitanud.

Kõik on suurepärane. Alustame tootmisse viimist. Saadan sõnumi, et graafikutel on koormus mitmekordistunud. Tõmbame versiooni tagasi. Vaatan graafikule ja näen: koormus on tõepoolest mitmekordistunud versiooni väljalaskmise ajal, ja vähenes tagasi, kui versioon väljatõmmati. Seejärel hakkasime versiooni tagasi tõmbama. Ja koormus kasvas samuti ja langes samuti tagasi. Järeldus on selline — koormus suurenes seoses väljalaskmisega, see ei ole üllatav.

Edasi oli raske veenda kolleege siiski uut versioon setamaa. Ma ütlen: "Kõik on korras, väljastage. Hoidke pöialt, kõik töötab. Praegu on graafikutel koormus tõusnud, aga see on normaalne. Hoidke vastu." Kokkuvõttes tegime nii, ja kõik — versioon viidi tootmisse. Kuid peaaegu iga väljalaskmise puhul tekivad sarnased probleemid.

Kill query peab tapma päringuid, kuid see ei toimi. Miks?

Mulle tuli kasutaja, mingi analüütik, ja esitas päringu, mis pani minu ClickHouse klastrisse. Kas mõne sõlme või kogu klastrisse — sõltuvalt sellest, millisesse replikasse või shard'i päring sattus. Näen, et kõik CPU ressursid sellel serveril on ummistunud, kõik on punane. Samas ClickHouse vastab päringutele. Ja ma kirjutan: "Palun näita mulle protsesside nimekirja, milline päring tekitas selle hulluse."

Leian selle päringu ja kirjutan talle kill. Ja näen, et midagi ei juhtu. Minu server on ummistunud, ClickHouse jätkab mingi sisuga vastamist, näitab, et server on elus ja kõik on korras. Kuid mul on degradatsioon kõigis kasutaja päringutes, algab degradatsioon ka ClickHouse'is kirjutamisel, ja minu kill päring ei toimi. Miks? Arvasin, et kill päring peab päringud tapma, aga seda ei juhtu.

Nüüd tuleb üsna kummaline vastus. Asi on selles, et kill päring ei tapa päringuid.

Kill päring seab väikese lipu nimega "ma tahan, et see päring tapetaks". Ja päring vaatab iga ploki töötlemise ajal sellele lipule. Kui see on seadistatud, peatub päring töös. Tulemuseks on see, et keegi ei tapa päringut, see peab ise kõik kontrollima ja peatuma. Ja see peab töötama kõigis juhtudel, kui päring on andmeplokkide töötlemise seisundis. See töötleb järgmise andmeploki, kontrollib lippu ja peatub.

See ei tööta juhtudel, kui päring on blokeeritud mingisuguses operatsioonis. Tõenäoliselt ei ole see teie juhtum, kuna teie sõnade kohaselt kasutab see palju serveri ressursse. Võib-olla ei toimi see välise sortimise korral ja veel mõnedes detailides. Kuid üldiselt ei tohiks nii olla, see on tõrge. Ja ainus soovitus, mida ma teile annan, on uuendada ClickHouse'i.

Kuidas arvutada vastuse aega lugemise koormuse korral?

On olemas tabel, kus hoitakse aggrekaate item'i kohta - erinevad loendurid. Ridade arv on umbes sada miljonit. Kas võib loota ettearvatavale vastuse ajale, kui suunata 1K RPS 1K item'ile?

Konteksti kohaselt on jutt lugemise koormusest, sest kirjutamisega ei ole probleeme - võite sisestada kas tuhande, sada tuhat või isegi paar miljonit rida.

Lugemisettevõtted on väga erinevad. Select 1 käivitab ClickHouse'is umbes tosin tuhat päringut sekundis, seega isegi ühe võtme päringud nõuavad juba mõningaid ressursse. Ja sellised punktipäringud on keerulisemad kui mingites key-value andmebaasides, sest iga lugemise jaoks tuleb lugeda andmeplokk indeksi kaudu. Meie indeks ei suuna iga kirje, vaid iga vahemiku poole. See tähendab, et tuleb lugeda kogu vahemik - see on vaikimisi 8192 rida. Ja tuleb dekomprimeerida 64 Kb andmeplokk 1 Mb-ks. Sellised punktipäringud võtavad tavaliselt mitu millisekundit. Kuid see on kõige lihtsam variant.

Proovime teha lihtsat aritmeetikat. Kui korrutada mitu millisekundit tuhandega, saadakse mitu sekundit. Justkui oleks mingil kombel võimatu hoida tuhande päringut sekundis, aga tegelikult on see võimalik, kuna meil on mitu protsessorituuma. Nii et põhimõtteliselt suudab ClickHouse mõnikord hoida 1000 RPS, kuid lühikeste, täpsete päringute korral.

Kui on vajalik suurendada ClickHouse'i klastri mahtu lihtsate päringute kaudu, siis soovitan kõige lihtsamat - suurendada koopiate arvu ja suunata päringud juhuslikule koopiale. Kui üks koopia suudab hoida viissada päringut sekundis, mis on täiesti reaalsus, siis kolm koopiat hoiavad tuhat viissada.

Mõnikord on muidugi võimalik ClickHouse'i seadistada maksimaalse arvu punktipäringute jaoks. Mis selleks vajalik on? Esiteks tuleb vähendada indeksi granulaarsust. Samal ajal tuleb seda vähendada mitte ühte, vaid arvestades, et indeksi kirjeid on mitu miljonit või kümneid milloneid serveris. Kui tabelis on sada miljonit rida, võib granulaarsuseks seada 64.

Selle kompressitud ploki suurust saab vähendada. Selleks on olemas seadistused min compress block size, max compress block size. Neid saab vähendada, andmeid uuesti suunata ja siis punktipäringud toimivad kiiremini. Kuid ClickHouse ei ole siiski key-value andmebaas. Suur hulk väikseid päringute tegemisi on koormuse antipattern.

Kirill Shvakov: Annan nõu juhuks, kui seal on tavalised kontod. See on piisavalt tavaline olukord, kus ClickHouse'is säilitakse mingit arvestit. Mul on kasutaja, ta on mingist riigist, veel mingi kolmas väli ja tuleb inkrementaalselt midagi suurendada. Võtate MySQL, loote unikaalse võtme - MySQL'is on see duplicate key, PostgreSQL'is konflikti - ja lisate plussiga. See töötab palju paremini.

Kui teil on vähe andmeid, pole ClickHouse'i kasutamisel eriti mõtet. On tavalised andmebaasid ja need teevad sellega hästi toimetulekut.

Mida saaks ClickHouse'is häälestada, et rohkem andmeid oleks vahemälus?

Kujutame ette olukorda - serverites on 256 GB RAM-i, igapäevaste toimingute korral kasutab ClickHouse umbes 60-80 GB, tipptasemel kuni 130. Mida saaks lubada ja häälestada, et rohkem andmeid oleks vahemälus ja seega vähem juurdepässe kettale?

Reeglina suudab operatsioonisüsteemi lehe vahemälu selle ülesandega hästi toime tulla. Kui avate lihtsalt top ja vaatate seal cached või free - seal on ka kirjas, kui palju on vahemällu salvestatud - siis võib märgata, et kogu vaba mälu on kasutatud vahemäluks. Ja need andmed loetakse lugemise ajal mitte kettalt, vaid RAM-ist. Samuti võin öelda, et vahemälu on efektiivselt kasutatud, kuna talletatakse just kokku surutud andmeid.

Kuid kui soovite mõningaid lihtsaid päringuid veelgi kiirendada, on võimalus sisse lülitada ClickHouse'is vahemälu dekompresseeritud andmete jaoks. Seda nimetatakse uncompressed cache. Konfiguratsioonifailis config.xml seadistate uncompressed cache size soovitud väärtuseks - soovitan mitte rohkem kui pool vaba mälu, sest ülejäänu kasutatakse page cache'iks.

Lisaks on olemas kaks päringutaseme seadet. Esimene seadistus - kasutada uncompressed cache — lubab selle kasutamist. Soovitatav on see lubada kõikide päringute jaoks, välja arvatud rasked, mis võivad kõik andmed täielikult lugeda ja selle vahemälu tühjendada. Ja teine seadistus - see on midagi nagu maksimaalne ridade arv vahemälu kasutamiseks. See piirab automaatselt suuri päringuid, et need vahemälusse ei satuks.

Kuidas saab seadistada storage_configuration töötamise eesmärgil?

Uues ClickHouse dokumentatsioonis lugesin lõiku, mis on seotud andmete salvestamisega. Kirjelduses on näide kiire SSD kohta.

Huvitav, kuidas sama seadistada volume hot memory'ga. Ja veel üks küsimus. Kuidas töötab select sellise andmete korraldusega, kas ta loeb kogu komplekti või ainult selle, mis asub kettal, ja kas need andmed tihendatakse mälus? Ja kuidas töötab prewhere sektsioon sellise andmede korraldusega?

See seadistus mõjutab andmefragmentide salvestamist, ja nende formaat ei muutu.
Vaatame lähemalt.

Andmete salvestamist mällu on võimalik seadistada. Kõik, mis on konfigureeritud kettale, on selle tee. Loote tmpfs jagamise, mis on mountitud mingisse teed failisüsteemis. Määrate selle tee andmete salvestamise teena kõige kuumemale jagamisele, kuhu hakkavad sisse tulema ja kirjutama andmefragmentid, kõik on korras.

Aga ma ei soovita nii teha madala usaldusväärsuse tõttu, kuigi kui teil on vähemalt kolm koopiat erinevates andmekeskustes, siis võib. Kui midagi juhtub, andmed taastatakse. Kujutage ette, et server lülitati äkki välja ja lülitati tagasi sisse. Jagamine on uuesti mountitud, kuid seal on tühjus. ClickHouse server käivitamisel näeb, et need fragmentid puuduvad, kuigi vastavalt ZooKeeperi metanõuetele peaksid nad olema. Ta vaatab, millistes koopiates nad on, küsib neid ja laadib alla. Seega andmed taastatakse.

Selles mõttes ei erine andmete salvestamine RAM-is põhimõtteliselt nende salvestamisest kettale, kuna andmete kirjutamisel kettale jõuavad need esmalt page cache'i ja salvestatakse füüsiliselt hiljem. See sõltub failisüsteemi mountimise variandist. Aga igaks juhuks ütlen, et ClickHouse ei tee fsync'i insert'i ajal.

Samas salvestatakse andmed RAM-is täpselt samas formaadis, nagu need on kettal. Select päring valib samuti osad, mida on vaja lugeda, valib vajalikud andmevahemikud ja loeb need. Prewhere töötab absoluutselt sama moodi, sõltumata sellest, kas andmed on RAM-is või kettal.

Kuni millise unikaalsete väärtuste arvuni on Low Cardinality efektiivne?

Low Cardinality on nutikalt üles ehitatud. See loob andmesõnastikke, kuid need on lokaalsed. Esiteks, igal tükkide jaoks on erinevad sõnastikud, ja teiseks, isegi ühes tükis võivad need olla erinevad iga vahemiku jaoks. Kui unikaalsete väärtuste arv saavutab künnise - minu arvates on see miljon - siis sõnastik lihtsalt lükatakse kõrvale ja luuakse uus.

Üldine vastus: iga kohaliku vahemiku jaoks - ütleme, iga päeva puhul - on Low Cardinality efektiivne kuni miljoni unikaalse väärtuseni. Edasi tuleb lihtsalt fallback, kus kasutatakse palju erinevaid sõnastikke, mitte ühte. See töötab umbes nagu tavaline string-tüüpi veerg, võib-olla veidi vähem efektiivselt, kuid tõsist jõudluse langust ei juhtuks.

Millised on parimad praktikud täisteksti otsinguks tabelis, kus on viis miljardit rida?

On erinevaid vastuse variante. Esimene - öelda, et ClickHouse ei ole täiesti tekstiotsingu süsteem. Selleks on olemas spetsiaalsed süsteemid, näiteks Elasticsearch ja Sphinx. Siiski, üha enam kohtan inimesi, kes ütlevad, et nad ülevad Elasticsearch'ilt ClickHouse'ile.

Miks see nii on? Nad selgitavad seda sellega, et Elasticsearch ei suuda teatud mahtudega enam koormusega toime tulla, alustades indeksite koostamisest. Indeksid muutuvad liiga mahukateks ja kui lihtsalt andmed ClickHouse'i üle viia, selgub, et need salvestatakse mahult mitu korda efektiivsemalt. Samal ajal ei olnud otsingupäringud tihti sellised, et oleks vaja leida kogu andmemahtudes mingit fraasi morfoloogiat arvestades, vaid hoopis teistsugused. Näiteks leida viimase paaritunni jooksul logidest mingi alajärjestus bite.

Selles olukorras loote ClickHouse'is indeksi, mille esimeseks feltiks on kuupäev ajaga. Ja suurim andmete piirang on just kuupäevade vahemiku põhjal. Valitud kuupäevade vahemikus on tavaliselt võimalik teostada ka täisteksti otsingut isegi bruteforce-meetodil, kasutades like. Like operaator ClickHouse'is on kõige tõhusam like operaator, mida leiate. Kui leiate parema, andke mulle teada.

Kuid like on ikkagi full scan. Ja full scan võib olla aeglane mitte ainult CPU, vaid ka ketas. Kui teil on ühe terabaiti andmeid päevas ja otsite ühte sõna, siis peate skaneerima terabaiti. See on tõenäoliselt tavakõvaketastel ja seetõttu nad on nii koormatud, et te ei pääse sellele serverile SSH kaudu.

Selles olukorras olen valmis pakkuma veel ühte väikest trikki. See on katsetuste seeriast — see võib töötada, aga võib ka mitte. ClickHouse'is on täisteksti indeksid trigrammi Bloom-filtrite kujul. Meie kolleegid ettevõttest Arenadata on neid indekseid juba proovinud ja sageli töötavad need just nii, nagu on ettenähtud.

Nende õigeks kasutamiseks tuleb hästi mõista, kuidas nad tegelikult töötavad: mis on trigrammi Bloom-filter ja kuidas valida selle suurus. Võin öelda, et need aitavad haruldaste fraaside otsingutes, alaminfodes, mis esinevad harva andmetes. Sel juhul valitakse indeksite kaudu alamvahemikud ja loetakse vähem andmeid.

Hiljuti ilmus ClickHouse'is veelgi arenenumaid funktsioone täisteksti otsimiseks. Esiteks on see, et kähku otsitakse korraga mitmeid alaminfode variante, sh variante, mis arvestavad suurtähti, mitte arvestavad suurtähti, toetavad UTF-8 või ainult ASCII. Valige kõige tõhusam, mida vajate.

Nüüd on ka mitme regulaaravalduse otsimine ühe sammu jooksul. Te ei pea kirjutama X like üks alaminf või X like teine alaminf. Kirjutage lihtsalt ja kõik tehakse maksimaalselt efektiivselt.

Kolmas asi — nüüd on olemas ligikaudne regulaatori otsing ja ligikaudne alaminfode otsing. Kui keegi on kirjutanud sõna vale kirjutamisega, otsitakse seda maksimaalse vastavuse põhjal.

Kuidas korraldada ClickHouse'i juurdepääsu suurele kasutajate arvule?

Kuidas korraldada juurdepääsu suure hulga tarbijate ja analüütikute jaoks? Kuidas moodustada järjekord, prioriseerida päringud ja milliseid tööriistu kasutada max concurrent queries?

Kui klaster on piisavalt suur, siis on hea lahendus tõsta üles kaks lisaserverit, mis muutuvad analüütikutele sisenemispunktiks. See tähendab, et analüütikuid ei lasta konkreetsetele klastrite shardidele, vaid luuakse kaks tühja serverit, andmeteta, ja neil seadistatakse juurdepääsuõigused. Samas kantakse kasutajaseadistused jaotatud päringute puhul üle kaugserveritele. Seega seadistate kõik nendele kahele serverile ja seadistused mõjavad kogu klastrit.

Põhimõtteliselt on need serverid andmeteta, kuid nende mälu maht on päringute täitmiseks väga oluline. Disk võib samuti kasutada ajutiste andmete jaoks, kui välimine agregatsioon või välimine sortimine on sisse lülitatud.

Oluline on vaadata seadistusi, mis on seotud kõikide võimalike limiitidega. Kui ma sisenen klastrisse "Yandex.Metrica" analüütikuna ja esitan päringu select count from hits, siis antakse mulle kohe erand, et ma ei saa päringut täita. Maksimaalne ridade arv, mida mul on lubatud skaneerida, on sada miljardit, ja kogu klastris on neid viiskümmend triljonit ühes tabelis. See on esimene piirang.

Oletame, et ma eemaldan ridade arvu piirangu ja täidan päringu uuesti. Siis näen järgmist erandit - seadistus on sisse lülitatud force index by date. Ma ei saa päringut täita, kui ma ei ole määranud kuupäevade vahemikku. Ei pea lootma, et analüütikud määravad selle käsitsi. Tüüpiline juhtum on, et on kirjutatud kuupäevade vahemik where event date between nädal. Ja siis lihtsalt pandi sulud valesse kohta ning andis or — or URL match. Kui piiranguid pole, hakkan seda URL-i veergu skaneerima ja kulutan lihtsalt tohutult ressursse.

Lisaks on ClickHouse'is kaks prioriteediseadistust. Kahjuks on need väga primitiivsed. Üks on lihtsalt nimetatud priority. Kui prioriteet ≠ 0 ja tehakse päringute seadistusi teatud prioriteediga, kuid samal ajal tehakse päring, mille prioriteet on madalam, mis tähendab kõrgemat prioriteeti, siis päring, mille prioriteedi väärtus on kõrgem, mis tähistab madalamat prioriteeti, lihtsalt peatatakse ja ei toimi selle aja jooksul.

See on väga jäme seadistus ja see ei sobi olukordadesse, kus klastri koormus on pidev. Kuid kui teil on lühikesed, impulsi päringud, mis on tähtsad, ning enamik klastri ajast on tühjas olekus, siis selline seadistus sobib.

Järgmine prioriteetide seadistus nimetatakse OS teema prioriteet. See määrab kõigile päringute täitmise thread'idele Linuxi ajakava jaoks nice väärtuse. See töötab pigem keskpäraselt, kuid siiski töötab. Kui määrate kõige madalama nice väärtuse - see on kõige suurem ja seega madalaim prioriteet - ning kõrge prioriteediga päringutele määrate -19, siis CPU tarvitab madala prioriteediga päringud umbes neli korda vähem kui kõrge prioriteediga päringud.

Samuti tuleb seadistada maksimaalne päringu täitmise aeg - ütleme, et viis minutit. Päringu minimaalne täitmiskiirus - see on kõige olulisem. See seadistus on ammu olemas ja seda on vaja, et mitte lihtsalt väita, et ClickHouse ei aeglusta, vaid et seda rakendada.

Kujutage ette, et seadistate: kui mõni päring töötleb vähem kui miljon rida sekundis - seda ei tohi teha. See häbistab meie head nime, meie head andmebaasi. Lihtsalt keelame selle. Tegelikult on seal kaks seadistust. Üks nimetatakse min execution speed - ridade kaupa sekundis, ja teine nimetatakse timeout before checking min execution speed - vaikeolekus viisteist sekundit. See tähendab, et viisteist sekundit on lubatud, kuid seejärel, kui aeglaselt, visata lihtsalt erand - katkestada päring.

Samuti tuleb seadistada kvoodid. ClickHouse'il on sisseehitatud kvoodivõime, mis loendab ressursikasutust. Kuid kahjuks mitte riistvaraliste ressursside nagu CPU, kett, vaid loogiliste - töödeldud päringute, ridade ja lugenud baitide arv. Näiteks saab seadistada maksimaalselt sada päringut viie minuti jooksul ja tuhat päringut tunni jooksul.

Miks see oluline on? Sest osa analüüsiküsitlustest viiakse läbi otse ClickHouse kliendi kaudu käsitsi. Ja kõik läheb hästi. Kuid kui teie firmas on arenenud analüütikud, kirjutavad nad skripti, ja skriptis võib olla viga. See viga toob kaasa selle, et päring täidetakse lõpmatus tsüklis. Sellest tuleb end kaitsta.

Kas on võimalik edastada ühe päringu tulemused kümnele kliendile?

Meil on mitu kasutajat, kes armastavad tulla väga suurte päringutega samal ajal. Päring on suur, töötab põhimõtteliselt kiiresti, kuid kuna selliseid päringuid on korraga palju, muutub see väga vaevanõudvaks. Kas saame sama päringu, mis tuli kümme korda järjest, täita ainult kord, ja anda selle tulemuse kümnele kliendile?

Probleem on selles, et meil puuduvad vahedata korra või tulemuste vahemälu. On olemas operatsioonisüsteemi lehtede vahemälu, mis võimaldab andmeid uuesti kettalt mitte lugeda, kuid kahjuks peavad andmed siiski olema dekompressitud, deserialiseeritud ja uuesti töödeldud.

Sooviksime mingil viisil seda vältida, kas vaheandmeid vahemälustades või sarnased päringud mingisse järjekorda seades ja tulemuste vahemälu lisades. Hetkel on meil arenduses üks pull request, mis lisab päringute vahemälu, kuid ainult alampäringute jaoks sektsioonis in ja join — see tähendab, et lahendus ei ole täielik.

Kuid meil tekib ka selline olukord. Eriti kanoniline näide - see on päringud lehtede haldamisega. On raport, milles on mitu lehte, ja toimub päring limit 10. Siis sama asi, kuid limit 10,10. Siis veel järgmine leht. Ja küsitakse, miks me iga kord seda kõike arvutame? Kuid hetkel pole lahendust ja seda ei saa vältida.

On alternatiivne lahendus, mis paigaldatakse ClickHouse'i kõrvale — ClickHouse Proxy.

Kirill Shvakov: ClickHouse Proxy's on sisseehitatud kiiruselimit ja sisseehitatud tulemuste vahemälu. Seal on palju seadistusi, sest lahendati sarnane probleem. Proxy võimaldab päringute piiramist, seades need järjekorda, ja seadistada, kui kaua vahemälu päringud kehtivad. Kui päringud on tõeliselt identsed, annab Proxy need mitu korda välja, kuid külastab ClickHouse'i vaid kord.

Nginxil on ka tasuta versioonis vahemälu ning see töötab samamoodi. Nginxil on isegi seaded, mis aeglustavad teisi päringuid, kui päringud tulevad samaaegselt, kuni üks neist täidetakse. Kuid ClickHouse Proxy seadistus on selles osas palju parem. See on loodud just ClickHouse'i jaoks, just nende päringute jaoks, seega sobib see palju paremini. Ja paigaldamine on lihtne.

Kuidas olla asünkroonsete toimingute ja materialiseeritud vaadete puhul?

On olemas probleem, et replikatsiooni mootori toimingud on asünkroonsed - esiteks salvestatakse andmed ja seejärel toimub nende koondamine. Kui tabeli all elab materialiseeritud tabel mingite agregaatidega, siis kirjutatakse sinna dubleeringud. Ja kui mingit keerulist loogikat pole, siis andmed dubleeritakse. Mida saame selle probleemiga teha?

On ilmne lahendus - rakendada käivituspunkt teatud tüüpi materialiseeritud vaadete jaoks asünkroonse koondamise toimingu ajal. Kas on mingeid 'hõbedaseid kuule', plaane sarnase funktsionaalsuse rakendamiseks?

Tuleb välja selgitada, kuidas deduplication töötab. See, millest ma praegu räägin, ei puuduta küsimust, kuid igaks juhuks tasub seda meeles pidada.

Replitseeritud tabelisse sisestamisel toimub deduplication kogu sisestatud plokkide ulatuses. Kui insertite taas ühe ja sama ploki, mis sisaldab sama arvu samu ridu samas järjekorras, siis andmeid dedupplitakse. Te saate sisestamise kohta 'Ok' vastuseks, kuid tegelikult salvestatakse ainult üks andmeplokk ja see ei dubleeru.

See on vajalik selguse huvides. Kui sisestamise ajal saate 'Ok', tähendab see, et teie andmed on sisestatud. Kui saite ClickHouse'ilt tõrke, siis need andmed ei ole sisestatud ja peate sisestamise kordama. Kuid kui sisestamise ajal katkevad ühendused, siis ei tea te, kas andmed on sisestatud või mitte. Ainus võimalus on uuesti sisestada. Kui andmed tegelikult sisestati ja te sisestasite need uuesti, toimub plokkide deduplication. See on vajalik dubleeringute vältimiseks.

Ja on oluline, kuidas see töötab materialiseeritud vaadete jaoks. Kui andmed on peamise tabeli sisestamisel dedupplitud, siis need ei lähe ka materialiseeritud vaatesse.

Nüüd küsimuse juurde. Teie olukord on keerulisem, kuna salvestate üksikute ridade koopiaid. See tähendab, et mitte tervet pakki ei dubleeri, vaid konkreetsed read, ja need kokku langevad taustal. Tegelikult koondatakse andmed põhitaablis, kuid materialiseeritud vaatesse lähevad koondamata andmed, ja mergide puhul ei juhtu materialiseeritud vaadetega midagi. Sest materialiseeritud vaade on mitte enam kui sisestamise käivitus. Teiste toimingute korral ei juhtu temaga midagi lisaks.

Ja ma ei saa siin üldse rõõmustada. Tuleb ainult otsida konkreetset lahendust sellele juhtumile. Näiteks, kas saab materialiseeritud vaates samuti sellele mingit asendamist teha, ja võib-olla töötab dedupikatsiooni meetod ka. Kuid kahjuks ei toimi see alati. Kui see on agregatiivne, siis ei õnnestu.

Kirill Shvakov: Meil oli ka oma ajal omajagu hetki, kus pidime asja nagu troppide ülesehitamisega tegelema. Oli probleem, et olid reklaami näitamised, ja on mõned andmed, mida saame reaalajas kuvada — need on lihtsalt näitamised. Need harva dubleeritakse, aga kui see juhtub, koondame need ikkagi hiljem. Ja oli asju, mida ei saanud dubleerida - klikke ja kogu seda lugu. Aga neid soovisime näidata praktiliselt kohe.

Kuidas materialiseeritud vaateid tehti? Oli vaateid, kuhu kirjutatakse otse - andmed sisestatakse tooretesse andmetesse ja kirjutatakse vaateisse. Seal mingil hetkel ei olnud andmed väga õiged, need dubleerusid ja nii edasi. Ja on teine osa tabelist, kus need näevad välja täpselt samasugused nagu materialiseeritud vaated, st struktuurilt on nad täiesti identsed. Korra mingi aja tagant arvutame andmed ümber, arvutame andmed ilma dubleeringuteta ja kirjutame nendesse tabelitesse.

Käisime läbi API — ClickHouse'i kaudu ei toimi see käsitsi. Ja API vaatab: kui mul on tabelisse viimase lisamise kuupäev, kus on гарантированно õiged, arvutatud andmed, ja ta teeb päringu ühte ja teise tabelisse. Ühelt valib ta välja ühe kindla ajani, ja teisest täiendab seda, mis pole veel arvutatud. Ja see töötab, aga mitte ühe ClickHouse'i vahenditega.

Kui teil on API — analüütikutele, kasutajatele — siis see on üks võimalus. Te alati loete, alati ümber arvutate. Seda saab teha kord päevas või muul ajal. Te valite ise vahemiku, mis ei ole teile vajalik ja kriitiline.

ClickHouse'is on palju logisid. Kuidas ma saan näha kõike, mis serveriga juhtub, reaalajas?

ClickHouse'is on väga suur hulk erinevaid logisid, ja see hulk kasvab. Uutes versioonides on mõned neist isegi vaikimisi sisse lülitatud, vanemates versioonides tuleb need aktiivseks teha uuendamise käigus. Sellegipoolest nende arv kasvab. Tahaks näha, mis mu serveriga praegu toimub, võib-olla mingil kokkuvõtval armatuurlaud.

Kas teil on ClickHouse meeskonnas või teie sõprade meeskondades, kes toetavad mingit funktsionaalsust valmis armatuurlaudade jaoks, mis kuvavad neid logisid juba valmis tootena? Lõppkokkuvõttes on tore vaadata logisid ClickHouse'is — see on suurepärane. Aga oleks väga äge, kui see oleks juba armatuurlaudade kujul. Sellest oleksin tõeliselt vaimustatud.

Armatuurlaudu on, tõsi, need ei ole standardiseeritud. Meie ettevõttes kasutab ClickHouse'i umbes 60 meeskonda, ja kõige kummalisem on see, et paljudel neist on armatuurlaud, mis nad ise on teinud, ja need on veidi erinevad. Mõned meeskonnad kasutavad Yandex.Cloud sisestust. Seal on mõned valmis aruanded, kuigi mitte kõik vajalikud. Teistel on oma.

Minu kolleegidel «Metrika» on oma armatuurlaud Grafanas, aga mul on oma nende klastril. Ma vaatan seal asju nagu cache hit vahekaartide jaoks. Ja isegi veel keerulisem on see, et me kasutame erinevaid tööriistu. Oma armatuurlauda lõin väga vanal tööriistal, mida nimetatakse Graphite-web. See on täiesti kole. Ja ma kasutan seda endiselt, kuigi Grafana oleks tõenäoliselt mugavam ja ilusam.

Dashbordide põhiväli on sama. Need on süsteemi meetrikad klastrile: CPU, mälu, kett, võrk. Teised on samaaegsete päringute arv, samaaegsete liitmiste arv, päringute arv sekundis, maksimaalne osade arv MergeTree tabelite partitsioonide jaoks, replikatsiooni viivitus, replikatsiooni järjekorra suurus, sisestatud ridade arv sekundis, sisestatud plokkide arv sekundis. Need on kõik, mis ei tulene logidest, vaid meetrikatest.

Vladimir Kolobaev: Aleksei, ma tahaksin natuke täpsustada. On olemas Grafana. Grafanal on andmeallikas, milleks on ClickHouse. See tähendab, et ma saan Grafanast päringuid otse ClickHouse'i teha. ClickHouse'is on logide tabel, mis on kõigil sama. Ma tahan, et Grafana lõpetaks selle logide tabeliga ja näeks neid päringuid, mida mu server esitab. Ol бы tore, kui meil oleks selline dashbord.

Ma tegelesin sellega ise. Kuid mul on küsimus – kui see kõik on standardiseeritud ja Grafanat kasutavad kõik omavahel, siis miks «Yandexis» ei ole sellist ametlikku dashbordi?

Kirill Shvakov: Tegelikult toetab ClickHouse'i andmeallikas praegu Altinity. Ja ma tahan lihtsalt anda suuna, kuhu kaevata ja keda tõukama. Saame neilt küsida, sest «Yandex» tegeleb siiski ClickHouse'iga, mitte selle ümber oleva looga. Altinity on peamine ettevõte, kes praegu ClickHouse'i edendab. Nad ei jäta seda, vaid toetavad seda. Sest põhimõtteliselt, et laadida dashbord Grafana veebisaidile, peab lihtsalt registreeruma ja selle üles laadima – erilisi probleeme ei ole.

Aleksei Milovidov: Viimase aasta jooksul on ClickHouse'is lisandunud palju võimalusi päringute profileerimiseks. Iga päringu ressursikasutuse jaoks on saadaval mõõdikud. Ja koos just hiljuti on lisatud veel madalamal tasemel päringute profiler, et näha, kus päring veedab iga millisekundi. Kuid selle funktsionaalsuse kasutamiseks pean avama konsooli klienti ja sisestama päringu, mida ma pidevalt unustan. Olen selle kuhugi salvestanud ja pidevalt unustan, kuhu just.

Soovin, et oleks tööriist, kus lihtsalt öeldakse - siin on teie rasked päringud, klasside kaupa rühmitatuna. Vajutage mõnele ja mulle öeldakse, et see on põhjus, miks see on raske. Praegu sellist lahendust pole. Ja see on tõesti üsna kummaline, et kui inimesed küsivad: „Kas teil on mingid valmiskujutised Grafana jaoks?” , siis ütlen: „Minge Grafana veebisaidile, seal on kogukond 'Dashboards', ja seal on Dima tahvel, on Kostjani tahvel. Mis see on, ma ei tea, ma ise ei ole kasutanud."

Kuidas mõjutada mergemisi, et server ei jookseks OOM-i?

Mul on tabel, kus on ainult üks partitsioon, see on ReplacingMergeTree. Olen sinna kirja pannud andmeid nelja aasta jooksul. Pean sellel tegema alternatiivi ja eemaldama mõned andmed.

Tehtud, ja selle päringu töötlemise käigus tarvitas kogu mälumaht klastris, ja kõik serverid klastris läksid sõbralikult OOM-i. Siis nad kõik koos tõusid, hakkasid sama operatsiooni, selle andmeploki merge'ima ja langesid jälle OOM-i. Siis nad taas tõusid ja jälle langesid. Ja see asjaolu ei lõppenud.

Hiljem selgus, et see oli tegelikult bugi, mille nad ära fikseerisid. See on väga tore, suured tänud. Kuid tunne jäi. Ja nüüd, kui mõtlen, et pean tegema mingit merge'i tabelis, kerkib mul küsimus - miks ma ei saa nendele merge'idele mingil moel mõjuda? Näiteks piirata neid nõutava mälu koguse järgi või üldiselt nende arvu järgi, mis konkreetse tabeliga tegeleb.

Mul on tabel, mille nimi on 'Metrika', palun töötle seda kahes voos. Ära loo kümmet või viit merge'i paralleelselt, tee kahes. Ma arvan, et kahes on mul mälu piisavalt, kuid kümne töötlemiseks ei pruugi piisata. Miks jääb hirm? Sest tabel kasvab, ja ühel päeval sattun olukorda, kus mitte bugi tõttu, vaid sellepärast, et andmeid muutub nii palju, et mul lihtsalt ei ole serveris piisavalt mälu. Ja siis server jookseb OOM-i mergimise ajal. Tõepoolest, ma saan mutatsiooni tühistada, aga merge'e enam ei saa.

Te tead, et server ei kuku OOM-i, kui teeme merge, sest merge'i ajal kasutatakse ainult väikeses andmevahemikus mälu. Nii et kõik läheb hästi, sõltumata andmete mahust.

Vladimir Kolobaev: Hea. Siin on see moment, et pärast defekti parandamist laadisin endale uue versiooni ja tegin sarnase operatsiooni teises, väiksemas tabelis, kus on palju partitsioone. Ja merge'i käigus kulus serveris umbes 100 GB mälu. Mul oli 150 kasutuses, 100 kasutas ja jäin 50 GB kogumälu peale, seega ma ei kukkunud OOM-i.

Mis kaitseb mind hetkel OOM-ist langemise eest, kui see tõepoolest tarvitab 100 GB mälu? Kuidas käituda olukorras, kui merge'ide käigus mälu äkki otsa saab?

Aleksei Milovidov: On selline probleem, et mälu kasutamine merge'ide jaoks ei piirdu ainult. Ja teine probleem on see, et kui mõni merge on määratud, tuleb see kindlasti täita, sest see on registreeritud replikatsiooni logis. Replikatsiooni log on need toimingud, mis on vajalikud, et tuua replikatsioon järjepidevasse seisundisse. Kui ei tehta käsitsi manipulatsioone, mis logi tagasi viivad, peab merge'i mingil juhul täitma.

Muidugi oleks kasulik rakendada mingit mälu piiri, mis „juhu” jaoks kaitseks OOM-i eest. See ei aita merge'il täituda, see algab uuesti, jõuab teatud piirini, viskab erandi ja algab uuesti - midagi head sellest ei tule. Kuid piiri seadmine oleks põhimõtteliselt kasulik.

Kuidas toimub Golang-i draiveri arendus ClickHouse jaoks?

Golang-i draiver, mille kirjutas Kirill Shvakov, näib nüüd olevat ametlikult ClickHouse meeskonna poolt toetatud. See asub ClickHouse repozitooriumis, see on nüüd suures ja tõelises vormis.

Väike märkus. On olemas suurepärane ja kõigile meeldiv lõpmatute järkjärguliste vormide ladustamine - see on Vertica. Nendel on ka oma ametlik Python draiver, mida toetavad Vertica arendajad. On olnud mitmeid kordi, kus ladustamise ja draiveri versioonid on tõeliselt kaugele läinud ning draiver on mingi hetk lõpetanud töötamise. Ja teine asi. Selle ametliku draiveri tugi, tundub mulle, toimib süsteemiga "nippli" - sa kirjutad neile probleemist ja see jääb igaveseks rippuma.

Mul on kaks küsimust. Praegu on Kirilli Golang draiver peaaegu vaikimisi viis, kuidas Golang suhelda ClickHouse'iga. Ainult, et keegi suhtleb endiselt http liidese kaudu, sest talle meeldib nii. Kuidas seda draiverit arendatakse? Kas see sünkroniseeritakse mõnede ladustamise oluliste muudatustega? Ja milline on probleemide arutamise kord?

Kirill Shvakov: Esiteks - kuidas kõik bürokraatiliselt toimub. Seda teemat ei arutatud, seega ei ole mul sellele vastata.

Et vastata küsimusele probleemide kohta, on vajalik lühike draiveri ajalugu. Töötasin firmas, kus oli palju andmeid. See oli reklaamiring, kus oli tohutult sündmusi, mida tuli kusagil säilitada. Ja mingil hetkel ilmus ClickHouse. Suunatud andmed sinna ja alguses oli kõik hästi, kuid siis ClickHouse kukkus kokku. Sellisel hetkel otsustasime, et see ei ole meile vajalik.

Aasta hiljem naasime idee juurde kasutada ClickHouse'i ja meil oli vaja kuidagi sinna andmeid kirjutada. Sissejuhatus oli selline - raud on väga nõrk, ressursse on vähe. Kuid me oleme alati nii töötanud ja seetõttu vaatlesime natiivprotokolli suunas.

Kuna me töötasime Go peal, oli selge, et vajame Go draiverit. Ma töötasin selle kallal praktiliselt täiskohaga - see oli minu tööülesanne. Kuni mingi hetk viisime selle lõpule ja sisuliselt ei eeldanud keegi, et keegi peale meie seda kasutab. Siis tuli CloudFlare täpselt sama probleemiga ja mingil hetkel töötasime nendega väga sujuvalt, kuna neil olid samad ülesanded. Ning me tegime seda nii ClickHouse'i enda ja ka draiveris.

Mingil on hetk, kus ma lihtsalt lõpetasin nende tegemise, sest minu tegevus ClickHouse'i osas ja töö on natuke muutunud. Seetõttu teemasid ei suleta. Vahel teevad inimesed reposse commit'e, kuna neil on midagi vaja. Siis vaatan pull request'i ja mõnikord isegi parandan midagi ise, kuid see juhtub harva.

Soovin tagasi pöörduda draiveri juurde. Mõned aastad tagasi, kui kõik see algas, oli ClickHouse ka teine ja erinevate võimalustega. Praegu on meil arusaam, kuidas draiverit ümber teha, et see oleks hea. Kui see juhtub, siis versioon 2 on igal juhul ühilduv, arvestades kogunenud 'kruve'.

Kuidas seda korraldada, ma ei tea. Mul endal ei ole nii palju aega. Kui mõni inimene hakkab draiverit edasi arendama, suudan neid aidata ja rääkida, mida teha. Kuid täpselt aktiivne osalemine "Yandexi" poolt projekti arendamisel ei ole seni arutatud.

Aleksei Milovidov: Tegelikult ei ole nende draiverite osas praegu mingit bürokraatiat. Ainult see, et nad on ametlikku organisatsiooni viidud, st see draiver on tunnustatud ametlikuks lahenduseks Go jaoks. On ka teised draiverid, kuid need on eraldi.

Meil ei ole nende draiverite jaoks seesugust arendust. Küsimus on – kas suudame palgata eraldi inimese, mitte just selle draiveri jaoks, vaid kõigi kogukonna draiverite arendamiseks, või leiame kellegagi väljastpoolt.

Väline sõnastik ei tõuse pärast taaskäivitust, kui lazy_load seadistus on sisse lülitatud. Mida teha?

Meil on lazy_load sisse lülitatud ja pärast serveri taaskäivitust sõnastik ise ei tõuse. See tõuseb ainult siis, kui kasutaja pöördub selle sõnastiku poole. Ja esimesel pöördumisel annab see vea. Kas ClickHouse'i kaudu on võimalik sõnastikke automaatselt laadida, või peame ise alati kontrollima nende valmisolekut, et kasutajad ei saaks vigu?

Võib-olla on meil vana versioon ClickHouse'ist, seetõttu sõnastik ei laaditud automaatselt. Kas see võib olla?

Esiteks, sõnastikke saab sundlaadida päringu abil system reload dictionaries. Teiseks, seoses veaga – kui sõnastik on juba laaditud, siis päringud töötavad nende andmete põhjal, mis on laaditud. Kui sõnastik ei ole veel laaditud, siis see laaditakse päringu käigus.

Raskete sõnastike jaoks ei ole see väga mugav. Näiteks, kui on vaja MySQL-ist tuua miljon rida. Keegi teeb lihtsa select'i, kuid see select ootab selle miljoni rida. Siin on kaks lahendust. Esimene - väljalülitada lazy_load. Teine - enne serveri koormamist teha see, kui server tõuseb, süsteem laadib sõnastikku uuesti või lihtsalt teha päring, mis kasutab sõnastikku. Siis sõnastik laaditakse. Peame ise jälgima sõnastike kättesaadavust, kui lazy_load seade on sisse lülitatud, sest ClickHouse ei tõmba neid automaatselt.

Viimasele küsimusele vastus - kas versioon on vana või tuleb seda debugida.

Kuidas olla olukorras, kus system reload dictionaries ei saada ühtegi mitmest sõnastikust, kui vähemalt üks neist langeb veaga?

On veel küsimus süsteemi uuesti laadimisest sõnastike kohta. Meil on kaks sõnastikku - üks ei lae, teine laadib. Sellisel juhul ei laadi süsteem uuesti tähesõnastikke, ja peame eraldi laadima konkreetse tema nime abil süsteemiga uuesti sõnastikku. Kas see on samuti seotud ClickHouse'i versiooniga?

Soovin rõõmustada. See käitumine on muutunud. Kui uuendate ClickHouse'i, siis muudab see ka. Kui te ei ole rahul praeguse käitumisega system reload dictionaries, uuendage ja loodame, et see muutub paremaks.

Kas on võimalik ClickHouse konfiguratsioonis seadistada akreditiivid, kuid mitte näidata neid vigade korral?

Järgmine küsimus puudutab vigu, mis on seotud sõnastikuga, nimelt rekordid. Oleme seadnud ühenduse rekordid ClickHouse'i konfiguratsioonis sõnastikku ja veateate korral saame need rekordid ja parooli vastuses.

Lahendasime selle vea viies rekordid ODBC draiveri konfiguratsiooni. Kas on mingi viis seadistada rekordid ClickHouse'i konfiguratsioonis, kuid mitte paljastada neid vigu esitatud veateates?

Siin on lahendus tõepoolest - märkida need autentimisdokumendid failis odbc.ini ja ClickHouse'is märkida ainult ODBC andmeallika nimi. Muude sõnastike allikate puhul ei tohiks seda olla - ei MySQL-i sõnastiku ega teiste puhul ei tohiks te parooli veateates näha. Vaatan ka ODBC puhul — kui see on olemas, siis tuleb see lihtsalt eemaldada.

Boonus: taustad Zoomi koosolekute jaoks

Klikkides pildil avanevad kõige visama lugemise huvilistele boonusfondid kokkusaamistest. Kustutame koos Avito tehnoloogia maskottidega tulekahju, arutame oma kolleegidega süsteemiadministraatori toas või vanakooli arvutiklubi ning viime läbi juhtimiskoosoleku sillal graffiti taustal.

Allikas: habr.com