ClickHouse edasijõudluse kasutajatele küsimustes ja vastustes

Aprillis kogunesid Avito insenerid veebikohtumisele ClickHouse peaarendaja Aleksei Milovidovi ja Integrosest pärit Golang arendaja Kirill Shvakoviga. Arutati, kuidas me kasutame andmebaasisüsteemi ja milliseid raskusi meile tekib.

Koosoleku põhjal oleme kokku pannud artikli ekspertide vastustega meie ja vaatajate küsimustele varukoopiate, andmete reshardingu, välistes sõnastikes, Golang draiveris ja ClickHouse versioonide uuendamises. See võiks olla kasulik arendajatele, kes juba aktiivselt töötavad Yandexi andmebaasisüsteemiga ja huvituvad selle praegusest ja tulevikust. Aleksei Milovidovi vastused on vaikimisi, kui ei ole märgitud teisiti.

Olge ettevaatlik, sest allpool on palju teksti. Loodame, et küsimustega sisu aitab teil orientiirida.

Sisu

• ClickHouse uuendatakse pidevalt, kuid meie andmed mitte. Mida sellega teha?
• Millised on hetkel parimad praktikad ClickHouse andmete varundamiseks?
• Kas on võimalik korraldada koormuse all kontrollitud replikate viivitust?
• Kuidas käituda, kui tabeli struktuur on muutunud?
• Millised on praegu parimad praktikad andmete resharde tegemiseks?
• ClickHouse'is on olemas utiliit clickhouse-copier. Kas saaksite rääkida selle kohta?
• Teie käes oli prooviversioon, mille nimi oli resharde. Mis sellest saanud on?
• Kas on võimalik kõik andmeosad enne aeglastele ketastele liikumist ühte koondada?
• Kuidas liikuda uutele ClickHouse'i versioonidele, kui eelnevalt ühilduvust kontrollida ei ole võimalik?
• Käsku Kill query peaks lõpetama päringud, kuid see ei toimi. Miks?
• Kuidas arvutada vastusaega lugemisekoormuse puhul?
• Mida optimeerida ClickHouse'is, et rohkem andmeid oleks vahemälus?
• Kuidas kohandada storage_configuration, et andmeid hoida mälus?
• Kui palju unikaalseid väärtusi on Low Cardinality efektiivne?
• Millised on parimad praktikad täisteksti otsimise jaoks tabelis, kus on viis miljardit rida?
• Kuidas korraldada ClickHouse'i juurdepääs suurte kasutajate hulkade jaoks?
• Kas on võimalik anda ühe päringu tulemused kümnele kliendile?
• Kuidas käituda asünkroonsete toimingute ja materialiseeritud vaadete puhul?
• ClickHouse'is on palju logisid. Kuidas saan näha kõike, mis serveriga toimumas on?
• Kuidas mõjutada merge'e, et server ei kukuks OOM-i?
• Kuidas toimub Golang-draiveri arendamine ClickHouse'ile?
• Väline sõnaraamat ei tõuse pärast taaskäivitamist üles, kui lazy_load seade on sisse lülitatud. Mida teha?
• Kuidas toimida, kui süsteemi sõnaraamatute uuendamine ei laadi ühtegi olemasolevat sõnaraamatut, kui vähemalt üks neist ebaõnnestub?
• Kas on võimalik seadistada andmeid ClickHouse'i konfigureerimises, ilma et neid vigade korral paljastada?
• Boonus: taustad Zoomi koosolekute jaoks

Kui teksti lugemine ei huvi, saab vaadata koosolekute salvestust meie YouTube'i kanalis. Aja koodid on video all olevas esimeses kommentaaris.

ClickHouse uuendatakse pidevalt, kuid meie andmed ei uuene. Mida sellega teha?

ClickHouse uuendatakse pidevalt, kuid meie andmed, mis on lõplikult optimeeritud, ei uuene ja jäävad varukoopiasse.

Oletame, et meil tekkis mõni probleem ja andmed kaotati. Otsustasime taastuda ja selgus, et vanad partiid, mis on salvestatud varukoopiate serveritesse, erinevad väga palju praegu kasutatava ClickHouse'i versioonist. Mida teha sellises olukorras, ja kas see on võimalik?

Situatsioon, kus olete taastanud andmed varukoopiast vanas formaadis ja need ei ole uue versiooniga ühildatavad, ei ole võimalik. Me hoolime, et ClickHouse andmevormaat jääks alati tagasiühilduvaks. See on palju tähtsam kui funktsionaalsuse tagasipöördumine, kui mõne harva kasutatava funktsiooni käitumine on muutunud. Andmed, mis on salvestatud kettale, peab uue versiooniga ClickHouse alati suutma lugeda. See on seadus.

Millised on hetkel parimad praktikad ClickHouse andmete varundamiseks?

Kuidas teha varukoopiaid arvesse võttes, et meil on optimeerimise lõppoperatsioonid, tohutu andmebaas terabaitides ja andmed, mis uuenevad eeldatavasti viimase kolme päeva jooksul, pärast mida nendega mingit protseduuri ei toimu?

Me võime teha oma lahenduse ja kirjutada Bashis: koguge niimoodi ja niimoodi need varukoopiad. Võib-olla pole midagi inovatiivselt leiutada ja rattast on juba ammu leiutatud?

Esiteks parimate praktikate osas. Mu kolleegid soovitavad alati, et varukoopiate küsimustele vastates meenutada "Yandex Cloud" teenust, kus see ülesanne on juba lahendatud. Nii et kasutage seda, kui võimalus on.

ClickHouse'iga täielikult integreeritud lahendust varundamiseks ei ole. On mõned mallid, mida saab kasutada. Täieliku lahenduse saamiseks tuleb kas natuke käsitsi tööd teha või kirjutada skripti kujul ümberpakendusi.

Alustan lihtsaimatest lahendustest ja lõpetan kõige keerulisematega, sõltuvalt andmete mahust ja klastrist. Mida suurem on klaster, seda keerulisemaks lahendus muutub.

Kui andmetabel hõivab vaid paar gigabaiti, saab varunduse teha nii:

1. Salvestada tabelite määratlemise ehk metaandmed — show create table.
2. Teha dump ClickHouse'i kliendi abil — select * from table faili. Vaikimisi saate faili TabSeparated formaadis. Kui soovite efektiivsemalt — saate kasutada Native formaati.

Kui andmete maht on suurem, võtab varundamine rohkem aega ja palju rohkem ruumi. Seda nimetatakse loogiliseks varundamiseks, see ei ole seotud ClickHouse'i andmeformaatidega. Kui see on olemas, saate viimase võimalusena varunduse võtta ja laadida MySQL-i taastamiseks.

ClickHouse'is on veel arenen võimalus luua partitsioonide snapshot kohaliku failisüsteemi. See funktsioon on saadaval päringu vormis alter table freeze partition. Või lihtsalt alter table freeze — see on kogu tabeli snapshot.

Snapshot luuakse ühte klassifikaatoritöötlusse konsistentse maksab, see tähendab, et ei saa luua konsistentset snapshot't kogu klastrile niimoodi. Kuid enamikul juhtudel ei ole see vajalik ja piisab, kui iga shardi puhul käivitada päring ja saada konsistentne snapshot. See luuakse kõvade sidemetega ja seetõttu ei võta see täiendavat ruumi. Seejärel kopeerite selle snapshot'i varundusserverisse või salvestusse, mida kasutate varukoopiate jaoks.

Sellise varukoopia taastamine on üsna lihtne. Esiteks loote tabelid olemasolevate tabelite määratlemiste põhjal. Seejärel kopeerite salvestatud partitsioonide snapshot'id Directory-Detached andmete tabelite jaoks ja käivitate päringu attach partition. Selline lahendus sobib suuremate andmehulkade jaoks.

Mõnikord on vajalik midagi veelgi võimsamat – juhul, kui teil on kümneid või isegi sadu terabajte igas serveris ja sadu servereid. Siin on lahendus, mille ma avastasin kolleegidelt 'Yandex.Metrics'. Ma ei soovitaks seda igaühele – lugege ja otsustage ise, kas see sobib teile või mitte.

Esmalt on vaja luua mitu serverit koos suurte kettasahtlitega. Edasi tuleb nendele serveritele seadistada mitu ClickHouse serverit ja seadistada need töötama nagu veel üks koopia samade shardide jaoks. Seejärel tuleks nendel serveritel kasutada failisüsteemi või mõnda tööriista, mis võimaldab luua snapshots. Siin on kaks varianti. Esimene variant on LVM snapshots, teine variant on ZFS Linuxil.

Pärast seda tuleb iga päev luua snapshot, mis jääb ja võtab mingisuguse ruumi. Loomulikult, kui andmed muutuvad, suurenevad mahtude osas võimalused aja jooksul. Selle snapshot'i saab igal ajal välja võtta ja andmed taastada, selline imelik lahendus. Lisaks tuleks piirata nende replikate kompaktset konfiguratsiooni, et nad ei püüaks saada juhtideks.

Kas on võimalik korraldada koormuse all kontrollitud replikate viivitust?

Kas sel aastal plaanite ClickHouse'is teha valli? Kas saaks seal korraldada replikate kontrollitud viivitust? Tahame seda kasutada, et end kaitsta negatiivsete stsenaariumide, nagu alternatiivide ja teiste muudatuste, eest.

Kas on võimalik teha mingeid tagasipöördeid alternatiivide jaoks? Näiteks olemasolevas valli võtta ja öelda, et kuni selle ajani rakenda muudatused, aga alates sellest ajast ära rakenda muudatusi?

Kui meie klastrisse siseneb rühm ja rikub selle, siis meil on tinglik replik viivitusega tund, kus me saame öelda, et kasutame just seda hetkel, kuid viimase kümne minuti muudatusi ei rakenda?

Alustame replikate kontrollitud viivituse temaatikast. Selline küsimus on kasutajatelt tulnud ja me lõime GitHubis teema palvega: 'Kui kellelegi see vajalik on, pange like või süda'. Keegi ei pannud, ja teema suleti. Siiski on juba praegu võimalik selline võimalus saada, seadistades ClickHouse'i. Tõsi, see on võimalik alates versioonist 20.3.

ClickHouse teostab pidevalt andmete sulandamist – merge. Kui sulandumine on toimunud, asendatakse teatud andmeplokkide kogum suurema plokiga. Sellegipoolest jäävad varasemad andmeplokid kõvakettale teatud ajaks.

Esiteks, need 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 ajapiir – vanad andmeplokid jäävad kõvakettale kaheks minutiks. Need kaheksa minutit saab konfigureerida ja muuta isegi üheks päevaks. See võtab kõvakettal ruumi: sõltuvalt andmevoolust võib viimase päeva andmete maht mitte ainult kahekordistuda, vaid kasvada isegi viis korda rohkem. Kuid tõsise probleemi korral saate ClickHouse'i serveri peatada ja kõike lahendada.

Nüüd tõstatub küsimus, kuidas see kaitseb alterite eest. Siin tasub sügavamale vaadata, sest ClickHouse'i vanemates versioonides töötas alter nii, et see muutis lihtsalt otse plokke. On andmeplokk, kus on mingid failid, ja teeme näiteks, alter drop column. Siis see veerg eemaldatakse füüsiliselt kõigist tükkidest.

Kuid alates versioonist 20.3 on alterite mehhanism täielikult muutunud ning nüüd on andme tükkide allikad alati muutumatud. Need ei muutu üldse – alterid töötavad nüüd ligikaudu nagu sulandumised. Selle asemel, et muuta tükk koha peal, loome uue. Uues tükis muutumatuid faile käsitletakse kõvapingutustena ja kui me oleme mõne veeru eemaldanud, siis see lihtsalt ei ole uues tükis. Vana tükk eemaldatakse vaikimisi kaheksanda minutiga ning siinsa saab seadistusi kohandada, nagu eelnevalt öeldud.

Sama kehtib mutatsioonide tüüpi alterite kohta. Kui teete alter delete või alter update, ei muuda see tükki, vaid loob uue. Ja seejärel eemaldab vana.

Kuidas käituda, kui tabeli struktuur on muutunud?

Kuidas taastada varukoopia, mis on tehtud vana skeemiga? Ja teine küsimus seoses snapshot’ide ja failisüsteemi tööriistadega. Kas Btrfs sobib siia ZFS asemel Linux LVM-is?

Kui teete attach partition Kui partitsioonide struktuur on erinev, ütleb ClickHouse, et seda ei saa teha. Lahendus on selline: esmalt luua ajutine MergeTree tüüpi tabel vana struktuuriga, liita sinna andmed attach abil ja teha alter päring. Seejärel saate kas need andmed kopeerida või ümber tõsta ja attach teha uuesti, või kasutada päringut. alter table move partition.

Nüüd teine küsimus – kas Btrfs on kasutatav? Esiteks, kui teil on LVM, siis piisavad LVM-i snapshot'id ja failisüsteem võib olla ext4, sellel pole tähtsust. Btrfs puhul sõltub kõik teie kogemustest selle kasutamisel. See on küps failisüsteem, kuid siiski on mõned kahtlused selle üle, kuidas kõik praktikas konkreetsetes stsenaariumites toimib. Ma ei soovitaks seda kasutada, kui teil pole Btrfs-i tootmises.

Millised on praegu parimad praktikad andmete resharde tegemiseks?

Küsimus ümberjaotamiseks on keeruline ja mitmekesine. Siin saab vastata mitmete variantide kaudu. Ühelt poolt võib öelda, et ClickHouse'is ei ole sisseehitatud võimalust ümberjaotamiseks. Kuid ma kardan, et see vastus kedagi ei rahulda. Seetõttu võib teiselt poolt öelda, et ClickHouse'is on palju viise andmete ümberjaotamiseks.

Kui klastris lõppeb koht või see ei suuda koormust taluda, lisate uusi servereid. Kuid need serverid on vaikimisi tühjad, andmeid neis ei ole, koormust ei ole. Teil on vaja andmeid ümber tõsta, et need oleksid uues, suurendatud klastris ühtlaselt jaotatud.

Esimene viis, kuidas seda teha, on osade partitsioonide kopeerimine uutele serveritele päringu abil alter table fetch partition. Näiteks kui teil olid partitsioonid kuude kaupa, siis võtate esimese kuu 2017. aastast ja kopeerite selle uuele serverile ning seejärel - kolmanda kuu kopeerite mõnda teise uude serverisse. Ja teete nii, kuni see on enam-vähem ühtlaselt jaotatud.

Ülekannet saab teha ainult nende partitsioonide puhul, mis ei muutu kirjutamise ajal. Uute partitsioonide puhul tuleb kirjutamine välja lülitada, kuna nende ülekandmine ei ole atomaarne. Vastasel juhul võite saada dubleeritud või puuduvaid andmeid. Siiski on see meetod praktiline ja töötab piisavalt tõhusalt. Võrgus edastatakse juba valmis kokkusurutud partitsioonid, mis tähendab, et andmeid ei pigistata ega kodeerita uuesti.

Sellel meetodil on üks puudus, mis sõltub shardimise skeemist, millele te panustasite, ning milline oli teie shardimise võti. Teie näites, mis käsitleb mõõdikuid, on shardimise võti - see on hash teelt. Kui teete Distributed tabelis select päringu, läheb see kohe kõigile klastri shardidele ja toob sealt andmed.

See tähendab, et tegelikult ei oma tähtsust, millised andmed millisel shardil asuvad. Peamine on see, et andmed ühel teel asuvad ühel shardil ja millisel täpselt, pole oluline. Sel juhul sobib valmiste partiide ülekandmine suurepäraselt, kuna select-päringute puhul saate te samuti — olgu see enne või pärast uue shard'i loomist, skeemil pole erilist tähtsust — täielikud andmed.

Kuid on ka keerulisemaid juhtumeid. Kui rakenduse loogika tasemel toetate te spetsiaalset sharding'u skeemi, mis näeb ette, et see klient asub teatud shardil, ja päring saab saata otse sinna, mitte Distributed tabelisse. Või kasutate piisavalt uut ClickHouse'i versiooni ja olete aktiveerinud seadistuse optimize skip unused shards. Sel juhul analüüsitakse select-päringu ajal where-i ja arvutatakse, millistele shardidele minna vastavalt sharding'u skeemile. See töötab eeldusel, et andmed on paigutatud just selle sharding'u skeemi järgi. Kui olete need käsitsi ümber paigutanud, võib vastavus muutuda.

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

Vladimir Kolobaev, peamine süsteemiadministraator Avitos: Alexei, see viis, mida mainisite, ei sobi hästi, kui on vaja koormust jagada ka lugemiseks. Saame võtta kuupõhise partitsiooni ja viia eelmise kuu teisele sõlmele, kuid kui küsitakse nende andmete järele, koormame ainult seda. Sooviksime aga koormata kogu klastri, sest muidu jääb kogu lugemisekoormus teatud ajaks kahte shard'i.

Alexei Milovidov: Vastus on siin kummaline — jah, halb, aga võib ka toimida. Selgitan, kuidas täpselt. Tuleb vaadata koormusskeemi, mis kaasneb teie andmetega. Kui need on jälgimisandmed, siis võib peaaegu kindlasti öelda, et enamik päringutest puudutab värskeid andmeid.

Te olete installinud uued serverid, migreerinud vana partitsioonid, kuid muutnud ka seda, kuidas värskeid andmeid salvestatakse. Nii et värsked andmed jaotatakse kogu klastrisse. Seega, juba viie minuti pärast laevad viimase viie minuti päringud ühtlaselt klastrit, päeva jooksul laevad viimase päeva päringud ühtlaselt klastrit. Kahjuks lähevad eelmine kuu päringud ainult osa klastriserveritesse.

Kuid sageli pole teil päringuid just veebruaris 2019. Tõenäoliselt, kui päringud juba 2019. aastal käivad, siis need on kogu 2019. aasta vältel — pika aja jooksul, mitte mingisuguste väikeste vahemike kaupa. Ja sellised päringud saavad samuti klastrit ühtlaselt koormata. Kuid teie tähelepanek on täielikult õige, et see on ad hoc lahendus, mis ei jaota andmeid täielikult ühtlaselt.

Mul on veel mõned punktid, et vastata küsimusele. Üks neist on see, kuidas algselt luua shardimise skeem, et taasjagamisest saaks vähem valu. See ei pruugi alati olla võimalik.

Näiteks, teil on jälgimisandmed. Jälgimisandmed kasvavad kolmel põhjusel. Esimene on ajalooliste andmete kogumine. Teine on liikluse suurenemine. Ja kolmas on jälgimise alla kuuluvate elementide arvu suurenemine. Uued mikroteenused ja mõõdikud, mida tuleb salvestada, ilmuvad pidevalt.

Võib-olla on neist kõige suurem kasv seotud just kolmanda põhjusega — see on jälgimise kasutamise suurenemine. Sellisel juhul tasub vaadata koormuse iseloomu, millised on peamised select-päringud. Peamised select-päringud tulevad tõenäoliselt mingist alamkogumist mõõdikutest.

Näiteks, CPU kasutamine mõnes serveris mingi teenuse poolt. Tulemuseks on, et on olemas teatud alamkogum võtmeid, mille alusel need andmed kätte saadakse. Ja päring nende andmete järele on tõenäoliselt piisavalt lihtne ja toimub kümnete millisekundite jooksul. Kasutatakse jälgimisteenuste ja juhtpaneelide jaoks. Loodan, et ma saan seda õigesti aru.

Vladimir Kolobaev: Asi on see, et me viidame sageli ajaloolistele andmetele, kuna me reaalajas võrreldame praegust seisundit ajaloolisega. Meie jaoks on oluline, et meil oleks kiire juurdepääs suurele andmemahule, ja ClickHouse teeb selles osas suurepärast tööd.

Te olete täiesti õiged, enamus lugemisetaotlusi tekib meil viimase päeva jooksul, nagu igasugustes enda jälgimissüsteemides. Kuid ajaloolistele andmetele on ka suurem koormus. See tuleb peamiselt alarmisüsteemist, mis käib iga kolmekümne sekundi tagant ja ütleb ClickHouse'ile: 'Anna mulle andmeid viimase kuue nädala jooksul. Ja nüüd ehita mulle sealt mingisugune liikuv keskmine ning võrdleme praegust väärtust ajaloolisega.'

Soovin öelda, et meil on selliste väga värskete päringute jaoks veel üks väike tabel, kus me hoiame ainult kahe päeva andmeid, ja peamised päringud suunduvad sinna. Suures sharditud tabelis saadame ainult suured ajaloolised päringud.

Alexei Milovidov: Kahjuks ei sobi teie stsenaarium hästi, kuid ma räägin kahest halvast ja keerulisest shardimise skeemist, mida ei tohiks kasutada, kuid mis on minu sõprade teenuses kasutuses.

On olemas peamine klaster «Yandex.Metrika» sündmustega. Sündmused on lehevaated, klikkimised ja üleminekud. Enamus päringutest suundub konkreetsele veebisaidile. Avate teenuse «Yandex.Metrika», teil on sait — avito.ru, sisenete raportisse ja toimub päring teie saidi kohta.

Kuid on ka teisi päringuid — analüütilisi ja globaalseid, mida teevad sisemised analüütikud. Igaks juhuks mainin, et sisemised analüütikud teevad päringuid ainult «Yandexi» teenuste kohta. Siiski, isegi «Yandexi» teenused hõivavad märkimisväärse osa kõikidest andmetest. Need päringud ei ole konkreetsed loendurite, vaid laiemate filtreerimiste kohta.

Kuidas korraldada andmeid nii, et üksikute andurite kaudu töötaks kõik efektiivselt ja globaalsetele päringutele vastaks samuti? Probleem on ka see, et päringute arv ClickHouse'i 'Metrika' klastri kohta ulatub mitme tuhande päringuni sekundi jooksul. Selliste keeruliste päringute puhul ei suuda üks ClickHouse'i server taluda sellist koormust.

Klastri suurus on üle kuue saja serveri. Kui lihtsalt rakendada selle klastri kohal jaotatud tabelit ja suunata sinna mitut tuhat päringut, läheb asi veel hullemaks kui need suunata ühele serverile. Teisalt, variant, kus andmed on ühtlaselt jaotatud ja me küsime kõigilt serveritelt, tõukame kohe kõrvale.

On olemas täiesti vastupidine variant. Kujutage ette, et me shardime andmed veebisaitide kaupa, ja ühe saidi päring suunatakse ühele shardile. Nüüd suudab klaster tõmmata kuni kümme tuhat päringut sekundis, kuid ühel shardil võib mingi kindel päring töötada liiga aeglaselt. See ei skaala enam läbilaskevõime järgi. Eriti kui see on veebisait avito.ru. Ma ei avalda saladust, kui ütlen, et Avito on üks kõige külastatumaid saite Venemaa internetis. Ja selle töötlemine ühel shardil oleks meeletus.

Seetõttu on shardinguskeem keerulisem. Kogu klaster on jagatud teatud arvu klastriteks, mida me nimetame kihtideks. Iga klaster sisaldab kümmet kuni mitukümmend shardit. Kokku on selliseid klastreid kolmkümmend üheksa.

Kuidas see kõik skaleerub? Klusterite arv ei muutu — nagu oli paar aastat tagasi kolmkümmend üheksa, nii on see endiselt. Kuid iga kihi sees suurendame järk-järgult shardide arvu andmete kogunedes. Ja shardimise skeem üldiselt on selline — jaotus nende klasterite järgi käib veebisaitide põhjal ning selleks, et mõista, milline sait millises klusteris asub, kasutatakse eraldi metabasi MySQL-is. Üks sait — ühes klusteris. Ja selle sees käib shardimine külastajate tuvastajate järgi.

Kirjutamise ajal jagame neid külastaja tuvastaja arvu jäägi järgi. Kuid uue shardi lisamisel muutub shardimise skeem, me jätkame purustamist, kuid ülestähendamisel teise numbri jäägi järgi. See tähendab, et üks külastaja on siiski mitmetes serverites, ja sellele ei saa toetuda. See on tehtud lihtsalt selleks, et andmed pigem kokku suruda. Ja päringute korral liigume Distributed tabelisse, mis vaatab klusterile ja pöördub kümnete serverite poole. Selline kummaline skeem.

Aga minu jutt jääks puudulikuks, kui ma ei ütleks, et sellest skeemist me loobusime. Uues skeemis muutsime kõik ja kõik andmed kopeeriti clickhouse-copier abil.

Uues skeemis jagunevad kõik saidid kahe kategooria vahel – suured ja väikesed. Ma ei tea, kuidas seal valitakse piir, aga tulemuseks on see, et suured saidid registreeritakse ühes klastris, kus on 120 shard'i, igas kolm koopiat – kokku 360 serverit. Ja shardimise skeem on selline, et iga päring läheb kohe kõigile shard'idele. Kui te praegu "Yandex.Metrica" avate ja vaatate mis tahes aruande lehte avito.ru jaoks, läheb päring 120 serverile. Suuri saite on rünnetes vähe. Ja päringute arv ei ole tuhat sekundis, vaid isegi vähem kui sada. Kõike seda suudab rahulikult töödelda Distributed tabel, mida iga neist haldab 120 serverit.

Teine klaster on väikeste saitide jaoks. Siin on shardimise skeem saidi идентификatori järgi, ja iga päring läheb täpselt ühe shardi peale.

ClickHouse'is on olemas utiliit clickhouse-copier. Kas saaksite rääkida selle kohta?

Ma ütlen kohe, et see lahendus on mahukam ja veidi vähem efektiivne. Eelis on see, et see jagab andmed täielikult vastavalt teie määratud skeemile. Kuid utiliidi puuduseks on see, et see ei teosta ülekohandamist. See kopeerib andmed ühest klastriskeemist teise klastriskeemi.

See tähendab, et selle töötamiseks peab teil olema kaks klastrit. Need võivad asuda samadel serveritel, kuid andmeid ei liikuda inkrementaalselt, vaid nad kopeeritakse.

Näiteks, kui oli neli serverit, saab kaheksa. Loote kõigis serverites uue jaotatud tabeli, uued kohalikud tabelid ja käivitate clickhouse-copier'i, määrates selle töö skeemi, millest ta peab lugema, et aktsepteerida uut jagamisskeemi ja teisaldada andmed sinna. Ja vanadel serveritel on vaja kohta poole võrra rohkem, kui praegu on, sest need vanad andmed peavad seal jääma ja nende peale tuleb pool neist vanadest andmetest. Kui olete eelnevalt mõelnud, et andmeid tuleb ülekohandada ja ruumi on, siis sobib see meetod.

Kuidas clickhouse-copier töötas? See jagab kogu töö ülesandeks ühe partitsiooni ühe tabeli ühel shard'il töötlemiseks. Kõik need ülesanded saavad toimuda paralleelselt, ning clickhouse-copier võib töötada erinevates masinates mitmes eksemplaris, kuid see, mida ta ühele partitsioonile teeb, on mitte midagi muud kui insert select. Andmed loetakse, dekompressitakse, ümber jagatakse, seejärel kompressitakse uuesti, kirjutatakse kuhugi, ümber sorteeritakse. See on keerukam lahendus.

Teie käes oli prooviversioon, mille nimi oli resharde. Mis sellest saanud on?

Teie pilootprojekti, mis kandis nime resharding, oli juba 2017. aastal. Isegi ClickHouse'is on olemas valik. Arusaamatult ei hakanud see tööle. Kas saaksite rääkida, miks see nii juhtus? See tundub ju väga asjakohane.

Probleem seisneb selles, et vajadusel nõuab andmete ümberasustamine kohapeal liigset keerulist sünkroneerimist, et see oleks aatomaarne. Kui hakkasime vaatama, kuidas see sünkroneerimine toimub, sai selgeks, et on põhilisi probleeme. Need põhilised probleemid ei ole mitte ainult teoreetilised, vaid ilmusid kohe ka praktikas nähtavale, sellega, et seda on lihtne seletada — mitte midagi ei toimi.

Kas on võimalik kõik andmeosad enne aeglastele ketastele liikumist ühte koondada?

TTL küsimus seoses slow diskile liikumise valikuga konteksti liitumistes. Kas on olemas viis, kuidas peale cron'i kõik osad kokku sulandada enne nende liigutamist aeglastele ketastele?

Küsimusele, kas on kuidagi võimalik automaatselt kõik tükid kokku liita enne nende üleviimist — ei, seda ei ole. Minu arvates ei ole selles vajadust. Ei pea kõik osad kokku sulandama, vaid võib lihtsalt loota, et need kantakse aeglastele ketastele automaatselt.

Meil on kaks andmete migreerimise kriteeriumi. Esimene on täituvuse järgi. Kui praegusel salvestustaseme vabal kohal on alla teatud protsendi, valime ühe osa ja viime selle aeglasemale salvestusele. Täpsemalt öeldes mitte aeglasemale, vaid järgmisele — nagu olete seadnud.

Teine kriteerium on suuruse järgi. See käsitleb suurte osade migreerimist. Saate kohandada künnist kiirel kettal oleva vaba ruumi põhjal, ja andmed kantakse automaatselt üle.

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

Seda teemat arutatakse regulaarselt ClickHouse'i Telegrami grupis erinevate versioonide arvestusega, ja siiski. Kui turvaline on versioonilt 19.11 versioonile 19.16 uuendamine ja näiteks versioonilt 19.16 versioonile 20.3? Kuidas on parem uutele versionitele üle minna, kui ei ole võimalust eelnevalt kontrollida ühilduvust liivakastis?

Siin on mõned „kuldreeglid“. Esimene on lugeda changelog. See on ulatuslik, kuid seal on eraldi punktid, mis käsitlevad tagasiühilduvad muudatused. Neid punkte ei tohiks pidada punaseks lipuks. Tüüpiliselt on need väikesed ühilduvuse probleemid, mis on seotud teatud äärefunktsionaalsusega, mida tõenäoliselt ei kasutata.

Teiseks, kui pole võimalik kontrollida ühilduvust liivakastis ja soovite kohe tootmisesse uuendada, on soovitus selline – ärge tehke seda. Esiteks looge liivakast ja kontrollige. Kui katsekeskkonda ei ole, siis tõenäoliselt ei ole teie ettevõte väga suur, seega võib andmete osa kopeerida oma sülearvutisse ja seal veenduda, et kõik töötab õigesti. Võite isegi oma masinas mitmeid koopiaid üles tõsta. Või võite kuskil lähedal tõsta üles uue versiooni ja laadida sinna osa andmeid – see tähendab, et looge improvisatsiooniline katsekeskkond.

Veel üks reegel – pärast versiooni väljaandet ei tohi nädal aega uuendada, et vead tootmises kinni püüda ja järgmisi kiireid parandusi teha. Vaatame ClickHouse'i versioonide numbreid, et mitte segadusse minna.

On versioon 20.3.4. Number 20 tähistab väljaandmise aastat — 2020. Sisu poolest pole sellel mingit tähtsust, seega ei pea me sellele tähelepanu pöörama. Järgmine number on 20.3. Teist numbrit — antud juhul 3 — suurendame iga kord, kui vabastame uue versiooni, millel on uus funktsionaalsus. Kui soovime ClickHouse'i lisada mõnda võimalust, peame seda numbrit suurendama. See tähendab, et versioonis 20.4 töötab ClickHouse veel paremini. Kolmas number — 20.3.4. Siin on 4 — see tähistab patšiversioonide arvu, kus me uusi võimalusi ei lisanud, kuid parandasime teatud vigu. Ja 4 tähendab, et oleme seda teinud neli korda.

Ärge arvake, et see on midagi kohutavat. Tavaliselt saab kasutaja installida kõige värskema versiooni, ja see töötab aasta jooksul probleemideta. Kuid kujutage ette, et mingis bitmapide töötlemise funktsioonis, mille meie Hiina kolleegid lisasid, server kaob vale argumentide edastamisel. Peame selle parandama. Me vabastame uue patšiversiooni ja ClickHouse muutub stabiilsemaks.

Kui ClickHouse on teil tootmises töötamas ja tuleb välja uus versioon ClickHouse'ist koos uue funktsionaalsusega — näiteks 20.4.1 — siis ärge kiirustage seda tootmisesse esimesel päeval paigaldama. Miks see üldse vajalik on? Kui te veel ClickHouse'i ei kasuta, siis võite selle paigaldada ja tõenäoliselt läheb kõik hästi. Kuid kui ClickHouse töötab juba stabiilselt, jälgige plaastrite ja värskenduste üle — milliseid probleeme me lahendame.

Kirill Shvakov: Tahaksin veidi rääkida testkeskkondadest. Kõik kardavad testkeskkondi ja kuidagi arvavad, et kui teil on väga suur ClickHouse'i klaster, peab ka testkeskkond olema vähemalt sama suur või vähemalt kümme korda väiksem. See ei ole sugugi nii.

Võin rääkida oma kogemusest. Mul on projekt ja seal on ClickHouse. Meie testkeskkond selle jaoks on väike virtuaalmasin Hetzneris, mis maksab kakskümmend eurot, kus on kõik täielikult kasutusele võetud. Selle saavutamiseks on meil täielik automatiseerimine Ansible'is, nii et põhimõtteliselt ei ole vahet, kas rakendada füüsilistele serveritele või lihtsalt virtuaalmasinatesse.

Mida on võimalik teha? Oleks hea, kui ClickHouse dokumentatsioonis oleks näide, kuidas üles seada väike klaster - Dockeris, LXC-s, võib-olla luua Ansible playbook, kuna erinevatel inimestel on erinevad paigaldused. See lihtsustab palju. Kui suudate klastrit üles seada viie minutiga, on palju lihtsam proovida millegi kallal töötada. Nii on palju mugavam, sest minna tootmisversiooni, mida te ei ole kontrollinud - on tee mitte kuhugi. Mõnikord see töötab, mõnikord ei tööta. Seetõttu on lootmine edule halb.

Maksim Kotjakov, vanem backendi insener Avitos: Lisa, et näitaksin suurettevõtete probleemide testimisringide kohta. Meil on täielik ClickHouse'i vastuvõtuklasster, mis on andmemudelite ja seadistuste osas täpselt sama, mis tootmises. See klaster on paigaldatud piisavalt nõrkadesse konteineritesse, kus on minimaalsed ressursid. Me suuname sinna teatud protsendi tootmisandmetest, kuna meil on võimalik Kafkas voolu replikeerida. Seal on kõik sünkroniseeritud ja skaleeritud - nii võimekus, vool kui ka teoorias, võrreldes teistega peaks see käituma nagu tootmine. Kõik potentsiaalselt plahvatusohtlikud elemendid suunatakse kõigepealt sellele katsetuskeskkonnale ja seal nad seisavad mitu päeva, kuni on valmis. Kuid loomulikult on see lahendus kallis, raske ja nõuab märkimisväärseid hoolduskulusid.

Alexei Milovidov: Räägin, milline on meie sõprade «Yandex.Metrica» testikeskkond. Üks klaster koosnes 600-st serverist ja teine 360-st, lisaks on veel kolmas ja mitu klastrit. Ühe neist testikeskkond on lihtsalt kaks shard'i, kus igas on kaks replikat. Miks kaks shard'i? Et poleks ainult ühte. Ja replikad on samuti vajalikud. Lihtsalt minimaalne arv, mida endale lubada saab.

See testikeskkond võimaldab kontrollida päringute töökindlust ja seda, kas midagi suurt on katki läinud. Kuid sageli tekivad probleemid hoopis teistsuguse iseloomuga, kui kõik töötab, kuid koormuses on mõned väikesed muutused.

Tõin näiteks. Otsustasime installida uue ClickHouse versiooni. See on üles laetud testikeskkonda, automaatkatsetused «Yandex.Metricas» on läbi viidud, mis võrdlevad andmeid vanas ja uues versioonis, läbides kogu torustiku. Ja loomulikult meie CI rohelised testid. Vastasel juhul ei oleks me isegi seda versiooni pakkunud.

Kõik on suurepärane. Alustame tootmisse viimist. Mul tuleb teade, et diagrammidel on koormus mitu korda suurenenud. Me tühistame versiooni. Vaatan diagrammi ja näen: koormus on tõepoolest väljalaskmisel mitu korda tõusnud ning tagasi vähenenud, kui see välja lasti. Siis hakkasime versiooni tagasi pöörama. Ja koormus tõusis täpselt samuti ja täpselt sama palju kukkus tagasi. Nii et järeldus on selline – koormus suurenes seoses väljalaskmisega, pole midagi üllatavat.

Edasi oli keeruline veenda kolleege ikkagi uut versiooni paigaldama. Ütlen: "Kõik on korras, laske välja. Hoidke pöialt, kõik töötab. Praegu on diagrammidel koormus tõusnud, aga kõik on korras. Hoidke vastu." Kokkuvõttes tegime nii ja kõik – versioon on tootmises. Kuid peaaegu iga väljalaskmisega tekivad sarnased probleemid.

Käsku Kill query peaks lõpetama päringud, kuid see ei toimi. Miks?

Külastaja tuli minu juurde, mingi analüütik, ja esitas küsimuse, mis põhjustas minu ClickHouse klastrisse probleeme. Mõni sõlm või kogu klaster — sõltuvalt sellest, kuhu repliika või shard see päring sattus. Näen, et kõik CPU ressursid sellel serveril on ületäitunud, kõik punane. Sellegipoolest vastab ClickHouse päringutele. Ja ma kirjutan: "Palun näita mulle protsesside nimekirja, milline päring tekitas selle segaduse."

Leian selle päringu ja kirjutame kill. Ja näen, et midagi ei juhtu. Minu server on ületäitunud, ClickHouse annab mulle endiselt mõned käsud, näitab, et server on elus, ja kõik on korras. Aga mul on kõikides kasutajapäringutes halvenemine, hakkab halvenema ka kirjutamine ClickHouse'i, ja minu kill query ei tööta. Miks? Ma arvasin, et kill query peaks päringud tapma, aga seda ei juhtu.

Praegu tuleb üsna kummaline vastus. Asi on selles, et kill query ei tapa päringuid.

Kill query seadistab väikese lipu nimega „ma tahan, et see päring tapetaks“. Ja ise päring töötlemise iga andmepaketi puhul vaatab seda lippu. Kui see on seatud, siis päring lõpetab oma töö. Tulemusena ei tapa keegi päringut, see peab ise kõik kontrollima ja peatuma. Ja see peaks töötama kõigis olukordades, kui päring on andmepakettide töötlemise seisundis. See töötleb järgmise andmepaketi, kontrollib lippu ja peatub.

See ei toimi juhtudel, kui päring on mingis operatsioonis blokeeritud. Tõsi, kõige tõenäolisemalt ei ole see teie juhtum, kuna teie sõnul kasutab see tohutult serveri ressursse. Võib-olla ei tööta see välise sortimise juhul ja veel mõnedes detailides. Kuid üldiselt ei tohiks sellist asja juhtuda, see on viga. Ja ainus, mida soovitada saan, on ClickHouse'i uuendamine.

Kuidas arvutada vastuse aega lugemisekoormuse korral?

On tabel, kus hoitakse erinevaid kontoaggregate item'i järgi. Ridade arv on umbes sada miljonit. Kas on võimalik arvestada ennustatavat vastuse aega, kui lasta sisse 1K RPS 1K item'i kohta?

Kontekti põhjal räägime lugemisest, kuna kirjutamise osas pole probleeme – saab sisestada nii tuhandeid, sadu tuhandeid kui ka miljoneid ridu.

Lugemispäringud on väga erinevad. Select 1 puhul suudab ClickHouse teostada kümneid tuhandeid päringuid sekundis, seega isegi ühe võtmega päringud vajavad juba mõningaid ressursse. Sellised täpsed päringud on keerulisemad kui mõnes key-value andmebaasis, kuna iga lugemise jaoks on vajalik lugeda andmepakett indeksi kaudu. Meie indeks ei aadresseeri iga kirjeid, vaid iga vahemikku. See tähendab, et tuleb lugeda kogu vahemik – see on vaikimisi 8192 rida. Ja tuleb dekompressida 64 Kb suurune andmepakett 1 Mb-ni. Tüüpiliselt kulub sellistele täpsetele päringutele mitu millisekundit. Kuid see on kõige lihtsam variant.

Proovime teha lihtsat aritmeetikat. Kui korrutada mitu millisekundit tuhandele, saame paar sekundit. Just nagu hoida tuhat päringut sekundis ei saa, kuid tegelikult on see võimalik, sest meil on mitu protsessorituuma. Nii et põhimõtteliselt võib 1000 RPS ClickHouse mõnikord taluda, kuid lühikeste päringute, just punktipäringute puhul.

Kui on vaja suurendada ClickHouse klastrit lihtsete päringute arvu osas, soovitan kõige lihtsamat - suurendada replikate arvu ja saata päringud juhuslikule replikale. Kui üks replik suudab taluda viissada päringut sekundis, mis on täiesti reaalne, siis kolm replikat suudavad taluda poolteist tuhat.

Mõnikord on loomulikult võimalik ka ClickHouse seadistada maksimaalse arvu punktisel lugemiseks. Mida selleks teha? Esiteks, vähendada indeksi granulaarsust. Siiski tuleks seda vähendada mitte üksuseni, vaid arvestades, et indeksi sissekandeid on serveris paar miljonit või kymmened miljonid. Kui tabelis on sada miljonit rida, võib granulaarsuse seadistamiseks määrata 64.

Kompresseeritud ploki suurust on võimalik vähendada. Selleks on olemas seadistused. min. kompressioonibloki suurus, max. kompressioonibloki suurus. Nende vähenemine ja andmete ümberlaadimine kiirendab punktipäringute täitmist. Kuid ClickHouse ei ole siiski key-value andmebaas. Suur hulk väikeseid päringuid on koormuse antipaater.

Kirill Shvakov: Annan nõu, juhul kui seal on tavalised kontod. See on üsna tavaline olukord, kui ClickHouse'is hoitakse mingit arvestit. Mul on kasutaja, ta on pärit sellisest riigist, veel mingi kolmas väli, ja on vaja inkrementeerida midagi. Võtke MySQL, looge unikaalne võti - MySQL'is on see duplicate key, PostgreSQL'is on see conflict - ja lisage plusse. See töötab oluliselt paremini.

Kui teil on vähe andmeid, siis ClickHouse'i kasutamisel ei ole eriti mõtet. On tavalised andmebaasid, mis selle ülesandega hästi hakkama saavad.

Mida Tuneerida ClickHouse'is, et rohkem andmeid oleks vahemälus?

Kujutame ette olukorda - serverites on 256 GB RAM, igapäevases rutiinis kasutab ClickHouse umbes 60–80 GB, tipul kuni 130. Mida saab sisse lülitada ja timmida, et rohkem andmeid oleks vahemälus ja seega vähem käike kettale?

Üldiselt tegeleb operatsioonisüsteemi page cache selle ülesandega hästi. Kui avate lihtsalt top-i ja vaatate seal cached või free, on seal ka näha, kui palju on vahemällu salvestatud. Saate märgata, et kogu vabamälu kasutatakse vahemäluks. Sel juhul loetakse need andmed mitte diskilt, vaid mälust. Võin öelda, et vahemälu kasutatakse tõhusalt, kuna salvestatakse kompressitud andmed.

Siiski, kui soovite mõned lihtsad päringud veelgi kiiremaks muuta, on võimalik ClickHouse'is sisse lülitada vahemälu dekompressitud andmete jaoks. Seda nimetatakse uncompressed cache. Konfiguratsioonifailis config.xml seadistage uncompressed cache size soovitud väärtuseks – soovitan mitte rohkem kui poole vabast mälust, kuna ülejäänu läheb page cache'i alla.

Lisaks on olemas kaks päringutaseme seadistust. Esimene seadistus on use uncompressed cache — seda kasutatakse. Soovitame seda rakendada kõigi päringute jaoks, välja arvatud raskete puhul, mis võivad kogu andmevahemiku kustutada. Teine seadistus on midagi sellist nagu maksimaalne ridade arv vahemälu kasutamiseks. See piirab automaatselt suuremaid päringuid, et nad ei oleks vahemälust mööda.

Kuidas kohandada storage_configuration, et andmeid hoida mälus?

Uues ClickHouse dokumentatsioonis leidisin jaotis, mis oli seotud andmete salvestamisega. Kirjelduses on näide kiire SSD-ga.

Huvitav, kuidas saaks sarnast seadistust konfigureerida mahtkuum mälu jaoks. Ja veel üks küsimus. Kuidas select töötleb sellise andmete korraldusega, kas ta loeb kogu komplekti või ainult selle, mis on kettal, ja kas need andmed komprimeeritakse mälus? Ja kuidas töötab prewhere lõik sellise andmete korraldusega?

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

Andmete salvestamine RAM-is on võimalik. Kõik, mis kettale seadistatakse, on selle tee. Loote tmpfs partitsiooni, mis on monteeritud mõnesse teatud kohta failisüsteemis. Määrate selle tee kuumade andmete salvestamise teena, kuhu hakkavad voolama ja kirjutama andmeplokid, kõik on korras.

Aga ma ei soovita seda teha madala usaldusväärsuse tõttu, kuigi kui teil on vähemalt kolm koopiat erinevates andmekeskustes, siis tasub. Kui midagi juhtub, siis andmed taastatakse. Kujutame ette, et server lülitati äkki välja ja tagasi sisse. Partitsioon monteeriti uuesti, kuid seal on tühjus. ClickHouse server käivitamisel näeb, et tal on need plokid puudu, kuigi vastavalt ZooKeeperi metaandmetele peaksid nad olemas olema. Ta vaatab, millistel koopiatel nad on, küsib neid ja laadib alla. Nii taastatakse andmed.

Selles mõttes ei erine andmete salvestamine mälus põhimõtteliselt nende salvestamisest kettale, sest andmete salvestamisel kettale satuvad need esmalt page cache'i ja salvestatakse füüsiliselt edasi lükatult. See sõltub failisüsteemi montaaživariandist. Kuid igaks juhuks ütlen, et ClickHouse ei tee fsync'i sisestamisel.

Sellegipoolest salvestatakse mälus olevad andmed täpselt samas vormingus nagu kettal. Select-päring valib täpselt samamoodi osad, mida on vaja lugeda, valib osades vajalikud andmevahemikud ja loeb neid. Ja prewhere töötab täiesti samamoodi, olenemata sellest, kas andmed olid mälus või kettal.

Kui palju unikaalseid väärtusi on Low Cardinality efektiivne?

Low Cardinality on nutikalt üles ehitatud. See loob andmesõnastikke, kuid need on kohalikud. Esiteks, igal osal on omad sõnastikud ja teiseks, isegi ühe osa sees võivad need iga vahemiku jaoks olla erinevad. Kui unikaalsete väärtuste arv jõuab künniseni - minu arvates on see miljon - siis sõnastik lihtsalt lükatakse edasi ja luuakse uus.

Kokkuvõtteks: iga lokaalse vahemiku jaoks — näiteks iga päeva puhul — on madala kardinaalsuse efektiivne kuni miljon unikaalset väärtust. Pärast seda on lihtsalt tagasiviske variant, kus kasutatakse erinevaid sõnastikke, mitte ühte. See töötab umbes nagu tavaline stringi tüübiga veerg, võib-olla veidi vähem efektiivselt, kuid tõsiseid jõudluslangusi ei teki.

Millised on parimad praktikad täisteksti otsimise jaoks tabelis, kus on viis miljardit rida?

On erinevaid vastuse variante. Esimene — öelda, et ClickHouse ei ole süsteem täisteksti otsimiseks. Selle jaoks on olemas eraldi süsteemid, näiteks Elasticsearch ja Sphinx. Siiski kohtan üha enam inimesi, kes ütlevad, et nad lähevad Elasticsearchilt ClickHousele üle.

Mis see süüdistus on? Nad selgitavad seda sellega, et Elasticsearch lõpetab teatud mahtudega koormuse talumise, alustades indeksite loomisega. Indeksid muutuvad liiga mahukaks ja kui andmed lihtsalt ClickHouse'i üle viia, selgub, et need salvestatakse mitu korda efektiivsemalt. Samal ajal ei olnud otsingupäringud sageli sellised, et leida mingit fraasi kogu andmemahu hulgast morfoloogiat arvesse võttes, vaid hoopis teistsugused. Näiteks leida mõne viimase tunni jooksul logidest mingi baitide alase järjendi.

Sel juhul loote ClickHouse'is indeksi, mille esimene väli on kuupäev koos ajaga. Andmete suurim piirang on just kuupäevade vahe. Valitud kuupäevade vahemikus on pärast seda tavaliselt võimalik teha täisteksti otsingut isegi bruteforce-meetodil like abil. Like operaator ClickHouse'is on kõige tõhusam like operaator, mille leiate. Kui leiate parema — öelge mulle.

Kuid siiski on like — see on täielik skaneerimine. Ja täielik skaneerimine võib olla aeglane mitte ainult CPU, vaid ka ketaste osas. Kui teil on näiteks üks terabait andmeid päevas ja otsite ühe päeva jooksul mingit sõna, tuleb teil skaneerida terabait. Ja see on tõenäoliselt tavalistel kõvaketastel, mis tähendab, et need tõstavad koormust nii palju, et te ei pääse sellele serverile SSH kaudu.

Selles olukorras olen valmis pakkuma veel ühte väikest trikki. See on katsetusmudel — see võib töötada või võib ka mitte töötada. ClickHouse'is on täistekstitüüpi indeksid trigrammsete Bloom-filtide kujul. Meie kolleegid ettevõttest Arenadata on juba proovinud neid indekseid ja sageli töötavad nad just nii, nagu ette nähtud.

Et neid õigesti kasutada, tuleks hästi aru saada, kuidas need täpselt toimivad: mis on trigrammne Bloom-filter ja kuidas valida selle suurus. Võin öelda, et need aitavad haruldaste fraaside, alalõikude päringute korral, mis esinevad andmetes harva. Sellisel juhul valitakse indeksite põhjal alamvahemikud ja loetakse vähem andmeid.

Hiljuti lisandus ClickHouse'i veelgi arenenumaid funktsioone täisteksti otsinguks. Esiteks, on nüüd võimalik korraga otsida mitmeid alamsõnu ühe läbimisega, sealhulgas arvestades suur- ja väiketähti, ilma suur- ja väiketähti arvestamata, UTF-8 toe või ainult ASCII puhul. Valige kõige efektiivsem variant, mis teile sobib.

Samuti on nüüd olemas võime otsida mitu regulaarset väljendit ühe korraga. Te ei pea kirjutama X like üks alamsõna or X like teine alamsõna. Kirjutage kohe ja kõik toimub maksimaalselt efektiivselt.

Kolmandaks — nüüd on olemas lähendus regulaarsete väljendite otsingule ja lähendatud alamsõnade otsingule. Kui keegi on kirjutanud sõna vale kirjaga, otsitakse seda maksimaalse vaste alusel.

Kuidas korraldada ClickHouse'i juurdepääs suurte kasutajate hulkade jaoks?

Rääkige, kuidas paremini korraldada ligipääsu suurtele tarbijatele ja analüütikutele. Kuidas luua järjekord, prioriseerida päringud max concurent queries ja milliste tööriistade abil?

Kui klaster on piisavalt suur, on mõistlikuks lahenduseks tõsta veel kaks serverit, mis toimivad analüütikute sisenemise punktidena. See tähendab, et analüütikuid ei lasta konkreetsetesse klastrite shardidesse, vaid luuakse lihtsalt kaks tühja serverit, ilma andmeteta, ja neile seadistatakse juurdepääsuõigused. Samal ajal edastatakse kasutajate seadistused hajutatud päringute puhul kaugserveritele. See tähendab, et te seadistate kõik neis kahes serveris ning seadistused mõjuvad kogu klastris.

Need serverid on põhimõtteliselt andmeteta, kuid nende mälu maht on päringute täitmiseks väga oluline. Ketast saab kasutada ka ajutiste andmete jaoks, kui väline agregatsioon või väline sorteerimine on lubatud.

On oluline vaadata seadistusi, mis on seotud kõikide võimalike limiitidega. Kui ma nüüd sisenen "Yandex.Metrika" klastrisse kui analüütik ja esitan päringu select count from hits, siis antakse mulle kohe välja erand, et ma ei saa päringut täita. Maximaalne ridade arv, mida mul on lubatud skaneerida, on sada miljardit, kuid klastris on kokku viiskümmend triljonit ühes tabelis. See on esimene piirang.

Oletame, et ma eemaldan ridade arvu piirangu ja sooritan päringu uuesti. Siis näen järgmist erandit — seadistus on lubatud. kaudne indekseerimine kuupäeva järgi. Ma ei saa päringut sooritada, kui ma ei ole määranud kuupäevavahemikku. Ei tasu loota, et analüütikud määravad selle käsitsi. Tüüpiline olukord on, et kuupäevavahemikud on määratud, kus ürituse kuupäev on vahemikus nädal. Ja siis on lihtsalt vale sulg, ning and ja asemel on or — või URL-i vastavus. Kui piiranguid ei ole, läheb see skaneerima URL-i veergu ja kulutab lihtsalt tohutult ressursse.

Lisaks on ClickHouse'is kaks prioriteeti seadistust. Kahjuks on need väga primitiivsed. Üks neist on lihtsalt nimetatud prioriteet. Kui prioriteet ≠ 0 ja päringud on teatud prioriteediga, kuid samal ajal toimub päring prioriteediga, mille väärtus on madalam, mis tähendab kõrgemat prioriteeti, siis päring, mille prioriteedi väärtus on suurem, mis tähistab madalamat prioriteeti, lihtsalt peatatakse ja ei tööta selle aja jooksul kindlasti.

See on väga jäik seadistus, mis ei sobi juhul, kui klastril on pidev koormus. Kui aga teil on lühikesed ja kiireloomulised päringud, mis on olulised, ja enamasti klaster seisab, siis selline seadistus sobib hästi.

Järgmine prioriteetide seadistus on OS thread priority. See määrab kõigile päringute täitmise lõimedele Linuxi ajakava jaoks nice väärtuse. See töötab enam-vähem, kuid ikkagi toimib. Kui seada kõige madalam nice väärtus – mis on kõige suurem, seega kõige madalam prioriteet – ja kõrge prioriteediga päringute puhul seada -19, siis CPU tarbib madala prioriteediga päringute töötlemiseks umbes neli korda vähem ressursse kui kõrge prioriteediga päringute jaoks.

Samuti on vaja seadistada maksimaalne päringu täitmise aeg – ütleme viis minutit. Minimaalne päringu täitmise kiirus – see on kõige olulisem. See seadistus on juba olemas olnud ja see on vajalik, et mitte lihtsalt väita, et ClickHouse ei aeglusta, vaid et seda ka sundida.

Kujutage ette, et seadistate: kui mõni päring töötleb vähem kui miljonit rida sekundis — nii ei tohi teha. See häbistab meie head nime, meie head andmebaasi. Geuda see lihtsalt keelata. Seal on tegelikult kaks seadistust. Üks nimetatakse min execution speed — ridade kaupa sekundis, ja teine nimetatakse timeout before checking min execution speed — vaikimisi viisteist sekundit. See tähendab, et viisteist sekundit on lubatud, ja siis, kui see on aeglane, visatakse lihtsalt erand — päring katkestatakse.

Kuid peate seadistama ka kvoodid. ClickHouse'is on sisseehitatud kvoodi võimalus, mis jälgib ressursside tarbimist. Kahjuks ei ole see rauaresursside, nagu CPU ja kettad, vaid loogiliste — töödeldud päringute arvu, ridade ja loetud baitide suurus. Ja saate seada näiteks maksimaalselt sada päringut viie minuti jooksul ja tuhat päringut tunni jooksul.

Miks see oluline on? Sest osa analüüsiküsimusi käitatakse käsitsi otse ClickHouse'i kliendist. Ja kõik läheb hästi. Kuid kui teie ettevõttes on edasijõudnud analüütikud, kirjutavad nad skripti, ja skripti sees võib olla viga. Ja see viga põhjustab selle, et päring toimub lõpmatus tsüklis. Sellest tuleb kaitse alla võtta.

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

Meil on mitmeid kasutajaid, kes armastavad tulla väga suurte päringutega samal ajal. Päring on suur, see käivitub põhimõtteliselt kiiresti, kuid kuna selliseid päringuid on korraga palju, muutub see väga valusaks. Kas on võimalik sama päring, mis saabus kümme korda järjest, teha ainult üks kord ning andmed edasi anda kümnele kliendile?

Probleem on selles, et meil pole tulemuste vahemälu ega vaheandmete vahemälu. On olemas operatsioonisüsteemi lehe vahemälu, mis võimaldab andmeid kettalt uuesti mitte lugeda, kuid kahjuks peavad andmed ikkagi dekompressioonima, deserialiseerima ja uuesti töötlema.

Soovitaksime leida viise selle vältimiseks, kas vaheandmete vahemäluga või korraldades sarnased päringud mingisse järjekorda ja lisades tulemuste vahemälu. Praegu on meil arenduses üks pull request, mis lisab päringute vahemälu, kuid ainult alampäringutele sektsioonides in ja join — seega pole lahendus täiuslik.

Kuid meil tekib ka selline olukord. Eriti tüüpiline näide on päringud lehekestega. On aruanne, milles on mitu lehte, ja päring käib limit 10. Siis sama asja, kuid limit 10,10. Seejärel tuleb järgmine lehekülg. Ja tekib küsimus, miks me iga kord seda kõik arvutame? Kuid praegu 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 kiiruspiiraja ja tulemuste vahemälu. Seal on palju seadeid, kuna lahendati sarnane probleem. Proxy võimaldab piirata päringuid, korraldades need järjekorda, ning seadistada, kui kaua päringute vahemälu kehtib. Kui päringud olid tõeliselt sama, annab Proxy need mitu korda, kuid ClickHouse'i poole pöördub vaid kord.

Nginx'il on tasuta versioonis ka cache, ja see töötab samuti. Nginx'il on isegi seaded, mis võimaldavad, kui päringud saabusid samal ajal, aeglustada teisi, kuni üks neist on täielikult täidetud. Kuid ClickHouse Proxy seadistus on tehtud tunduvalt paremini. See on loodud spetsiaalselt ClickHouse'ile, et toetada just selliseid päringuid, mistõttu sobib see paremini. Ja selle seadistamine on lihtne.

Kuidas käituda asünkroonsete toimingute ja materialiseeritud vaadete puhul?

On olemas probleem, et toimingud replikeerimise mootori puhul on asünkroonsed — esmalt salvestatakse andmed, seejärel toimub nende kokkuliitmine. Kui tabeli all elab materialiseeritud tabel koos mõnede agregaatidega, siis nendele kirjutatakse dubleeritud andmed. Ja kui puudub keeruline loogika, siis andmed dubleeritakse. Mis selle probleemiga teha saab?

On ilmne lahendus — rakendada esmase funktsiooni aktiveerimise käigus triggereid teatud tüüpi matviews'ide jaoks asünkroonsete kokkuliitmiste korral. Kas on mingeid "kuldpalle", plaane selliste funktsionaalsuste rakendamiseks?

Tasub uurida, kuidas deduplikatsioon töötab. See, millest ma praegu räägin, ei puutu küsimusega kokku, aga igaks juhuks tasub seda meeles pidada.

Replitseeritud tabelisse sisestamisel toimub täielikult sisestatud plokkide dedupeerimine. Kui olete uuesti sisestanud sama ploki, mis sisaldab sama arvu samu ridu samas järjestuses, dedupeeritakse andmed. Te saate sisestusele „Ok“ vastuse, kuid tegelikult salvestatakse vaid üks andmepartii ning see ei kordustu.

See on vajalik selguse jaoks. Kui sisestamise ajal saite „Ok“, tähendab see, et teie andmed on sisestatud. Kui saite ClickHouse'ilt vea, tähendab see, et nad ei ole sisestatud ja sisestamist tuleb korrata. Kuid kui sisestamise ajal kadus ühendus, ei tea te, kas andmed on sisestatud või mitte. Ainuke võimalus on sisestamist uuesti korrata. Kui andmed tegelikult olid sisestatud ja te sisestate need uuesti, toimub plokkide dedupeerimine. See on vajalik duplikaatide vältimiseks.

Ja on oluline ka see, kuidas see töötab materialiseeritud vaadete jaoks. Kui andmed on sisestamisel peamisele tabelile dedupeeritud, siis materialiseeritud vaates nad ei liigu.

Nüüd seoses küsimusega. Teie olukord on keerulisem, kuna salvestate ainulaadsete ridade koopiaid. See tähendab, et mitte kogu rida ei ole duplikeeritud, vaid konkreetsed read, ja need kokkukuuluvad taustal. Tõepoolest, andmed koonduvad põh tabelisse, samas kui materialiseeritud vaates lähevad need mittekoonduvad ja liitmise korral ei juhtu materialiseeritud vaadetega midagi. Sest materialiseeritud vaade on mitte midagi muud kui insert-trigger. Muude toimingute ajal ei toimu selle suhtes midagi täiendavat.

Ja ma ei saa siin midagi head öelda. Tuleb ainult otsida konkreetset lahendust sellele juhtumile. Näiteks, kas on võimalik ka materialiseeritud vaates teha asendust, ja võib-olla dedupikatsiooni meetod töötab samuti. Kuid kahjuks ei toimi see alati. Kui see on koondav, siis ei õnnestu.

Kirill Shvakov: Meil oli ka omal ajal sisuliselt nagu köitmine. Oli probleem, et reklaamieelarved eksisteerivad, ja on mõned andmed, mida saame reaalajas näidata — need on lihtsalt näitamine. Need harva korduvad, kuid kui see juhtub, siis me ikkagi sulgeme need hiljem. Ja olid asjad, mida ei saanud dubleerida — klikkide ja kogu selle looga. Kuid neid oleks tahtnud peaaegu kohe näidata.

Kuidas loodi materialiseeritud vaated? Oli vaated, kuhu kirjutatakse otse — andmed kirjutatakse tooredata, ja kirjutatakse vaateisse. Seal mingi hetk andmed ei ole väga õiged, need dubleeritakse jne. Ja on teine osa tabelist, kus need näevad täpselt samad välja nagu materialiseeritud vaated, s.t. struktuurilt on nad täiesti ühesugused. Aeg-ajalt me ümber arvestame andmed, arvutame andmed ilma dubleeringuteta ja kirjutame need tabelitesse.

Käisime API kaudu — ClickHouse'iga käsitsi seda teha ei saa. API jälgib: kui mul on tabelis viimane lisamise kuupäev, kus andmed on täpsed ja arvutatud, siis teeb ta päringu ühest tabelist teise. Ühest valib ta kindla ajani, ja teisest lisab, mis veel arvutamata on. Ja see töötab, aga mitte ühegi ClickHouse'i vahendiga.

Kui teil on mingi API — analüütikute jaoks, kasutajate jaoks — siis põhimõtteliselt on see variant. Te alati arvutate, alati uuesti kokku. Seda võib teha kord päevas või mingil muul ajal. Te valite ise enda jaoks perioodi, mis teile ei ole vajalik ega kriitiline.

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

ClickHouse'is on väga suur hulk erinevaid logisid ning see hulk kasvab. Uutes versioonides on mõned neist isegi vaikimisi sisse lülitatud, vanemates versioonides tuleb neid uuendamisel sisse lülitada. Sellegipoolest on neid järjest rohkem. Sooviksin lõppkokkuvõttes näha, mis minu serveriga praegu toimub, võib-olla mõnel kokkuvõtvad armatuurlaual.

Kas teil või teie sõprade meeskonnas on ClickHouse'i spetsialiste, kes toetavad valmis dashboards'e, mis kuvavad logsid juba valmis tootena? Lõppkokkuvõttes on logsid ClickHouse'is vaatamine tore. Kuid oleks tõeliselt äge, kui need oleksid juba dashboard'ina valmis. See tooks suuri rõõme.

Dashboards'id on olemas, kuid need ei ole standardiseeritud. Meie ettevõttes kasutab ClickHouse'i umbes 60 meeskonda, ja mis kõige kummalisem, paljudel neist on omaenda tehtud dashboards'id, mis on veidi erinevad. Mõned meeskonnad kasutavad Yandexi pilveteenuse sisemist installatsiooni. Seal on mõned valmis raportid, kuigi mitte kõik vajalikud. Teistel on omad.

Minu kolleegidel „Metrist” on oma dashboard Grafanas, ja mul on oma nende klastriga. Seal jälgin asju nagu cache hit kihi jälgimiseks. Ja asi on isegi keerulisem, kuna kasutame erinevaid tööriistu. Olin loonud oma dashboard'i väga vana tööriistaga nimega Graphite-web. See on täiesti kole. Ja ma kasutan seda endiselt, kuigi Grafana oleks kindlasti mugavam ja ilusam.

Dashboardide põhielement on sama. Need on süsteemilised mõõdikud klastrite kohta: CPU, mälu, ketas, võrk. Teised - samaaegsete päringute arv, samaaegsete ühinemiste arv, päringute arv sekundis, maksimaalne osade arv MergeTree tabelite partitsioonide jaoks, replikatsiooni viivitus, replikatsiooni järjekorra suurus, sekundi kohta sisestatud ridade arv, sekundi kohta sisestatud plokkide arv. See on kõik, mis tuleb mitte logidest, vaid mõõdikutest.

Vladimir Kolobaev: Aleksei, ma tahaksin veidi 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 Grafanas viidatakse sellele logide tabelile ja näeksin neid päringuid, mida minu server esitab. Oleks suurepärane omada sellist dashboard'i.

Ma tegin selle ise. Aga mul tekib küsimus - kui see on kõik standardiseeritud ja Grafanat kasutavad kõik, miks ei ole 'Yandexis' sellist ametlikku dashboard'i?

Kirill Shvakov: Tegelikult toetab ClickHouse'i andmeallikat praegu Altinity. Ja ma tahan lihtsalt anda suunise, kuhu kaevata ja keda lükata. Neilt võib küsida, kuna Yandex tegeleb siiski ClickHouse'iga, mitte selle ümber olevate asjadega. Altinity on peamine ettevõte, mis praegu ClickHouse'i edendab. Nad ei jäta seda tähelepanuta, vaid jätkavad toetust. Sest põhimõtteliselt, et laadida paneel Grafana veebisaidile, peab lihtsalt registreeruma ja selle üles laadima - erilisi probleeme ei ole.

Alexei Milovidov: Viimase aasta jooksul on ClickHouse'i lisatud palju võimalusi päringute profileerimiseks. Igal päringul on ressursikasutuse metoodikud. Just hiljuti lisati veel madalama taseme päringu profilaator, et näha, kus päring kulutab iga millisekundi. Kuid selle funktsionaalsuse kasutamiseks pean avama konsooli klienti ja sisestama päringu, mille ma pidevalt unustan. Olen selle kuhugi salvestanud ja unustan pidevalt, kuhu täpselt.

Soovin, et oleks tööriist, kus lihtsalt on öeldud - siin on teie rasked päringud, rühmitatud päringute klasside järgi. Klõpsasin mõnel ja mulle öeldakse, et see on sellepärast keeruline. Praegu sellist lahendust pole. Tõeliselt kummaline on, et kui inimesed mind küsivad: „Kas on olemas mõni valmis armatuurpaneel Grafana jaoks?“, ütlen ma: „Minge Grafana saidile, sinna on kogukonna 'Armatuurpaneelid', seal on Dima armatuurpaneel, on Kostja armatuurpaneel. Mis need on, ei tea, ise pole kasutanud.”

Kuidas mõjutada merdžisid, et server ei kukuks OOM-i?

Mul on tabel, tabelis on vaid üks partitsioon, see on ReplacingMergeTree. Kirjutan sinna andmeid juba nelja aasta jooksul. Ma pidin sinna tegema alteri ja kustutama mõned andmed.

Tegin seda ja selle päringu töötlemise käigus läks kogu mälu kõikidesse klastriserveritesse ja kõik klastriserverid kukkusid ühiselt OOM-i. Siis nad kõik koos tõusid, hakkasid täitma selle sama toimingu merdžimist, selle andmeploki merdžimist ja kukkusid jälle OOM-i. Siis nad tõusid jälle ja kukkusid taas. See asi ei lõppenud.

Hiljem selgus, et tegu oli tegelikult veaga, mille nad parandasid. See on suurepärane, suur aitäh. Aga tunne jäi alles. Ja nüüd, kui mõtlen, et tuleb teha mingisugune liitmine tabelis, tekib mul küsimus - miks ma ei saa kuidagi nende liitmistele mõjuda? Näiteks, piirata neid vajaliku süsteemi mälu järgi või üldiselt nende arvu osas, mida see konkreetne tabel töödelda suudab.

Mul on tabel, mida nimetatakse "Mõõdikud". Palun töötle seda kahe vooga. Ära loo samal ajal kümmet või viit liitmist, tee seda kahel. Ma arvan, et kahega mul piisab mälust, aga kümne töötlemiseks ei pruugi piisata. Miks hirm jääb? Sest tabel kasvab ja kunagi satun ma olukorda, kus mitte enam vea tõttu, vaid sellepärast, et andmed muutuvad nii suurel hulgal, et mul lihtsalt ei jätku serveris mälu. Ja siis kukub server OOM-i liitmise käigus. Muidugi saan ma mutatsiooni tagasi võtta, aga liitmisi ei saa.

Teate, server ei kuku OOM-i, kuna merge'i käigus kasutatakse mälu vaid ühe väikese andmevahemiku jaoks. Nii et kõik läheb hästi, olenemata andmete mahust.

Vladimir Kolobaev: Hea. Siin on selline moment, et pärast vea parendamist tõmbasin endale uue versiooni ja teises, väiksemas tabelis, kus on palju partitioone, tegin sarnase toimingu. Merge'i käigus põletati serveris umbes 100 GB mälu. Mul oli 150 kasutuses, 100 kasutas ära ja jäi 50 GB vaba, seega ma ei kukkunud OOM-i.

Mis mind praegu OOM-i langemise eest kaitseb, kui see tõesti tarvitab 100 GB mälu? Kuidas käituda olukorras, kui merge'i käigus mälu järsku otsa lõppeb?

Alexei Milovidov: On sel probleem, et mälu kasutamine merge'ide puhul ei piirdub ainult sellega. Teine probleem on see, et kui mingi merge on määratud, tuleb see ka täita, kuna see on logitute replikaatoris. Replikaatori logi on need toimingud, mis on vajalikud, et tuua replika järjepidevasse seisundisse. Kui ei tehta käsitsi toiminguid, mis see replikaatorite logi tagasi kerib, tuleb merge mingil juhul täita.

Loomulikult oleks kasulik omada mälu piirangut, mis "igaks juhuks" kaitseb OOM-i vastu. See ei aita merge'il toimuda, see algab uuesti, jõuab mingisse punkti, viskab erandi ja siis algab taas — midagi head ei tule sellest. Kuid põhimõtteliselt oleks see piirang kasulik kehtestada.

Kuidas toimub Golangi draiveri arendamine ClickHouse'i jaoks?

Golang draiver, mille on kirjutanud Kirill Shvakov, näib nüüd olema ametlikult toetatud ClickHouse'i meeskonna poolt. Ta on ClickHouse'i hoidlas, ta on nüüd suur ja tõeline.

Väike märk. On olemas suurepärane ja kõigile armastusväärne normaalsete lõpmatute järjestuste hoidla — Vertica. Neil on ka oma ametlik Python-draiver, mida toetavad Vertica arendajad. On olnud kordi, kui hoidla ja draiveri versioonid erinevad üksteisest oluliselt ning draiver lakkab mingil hetkel töötamast. Teine asi. Selle ametliku draiveri tugi, nagu mulle tundub, põhineb süsteemil "nipel" — kirjutad neile probleemist, ja see jääb igaveseks ootele.

Mul on kaks küsimust. Praegu on Kirilli Golang-draiver peaaegu vaikimisi viis kommunikatsiooniks Golangi ja ClickHouse'i vahel. Olgu, et keegi suhtleb endiselt HTTP liidese kaudu, kuna talle see sobib. Kuidas toimub selle draiveri arendamine? Kas see sünkroniseeritakse hoidlas toimuvate breaking changes'idega? Ja kuidas toimub probleemide arutamine?

Kirill Shvakov: Esimene on see, kuidas kõik on bürokraatlikult korraldatud. Seda teemat ei arutatud, seega pole mul sellele vastata.

Küsimusele vastamiseks on vajalik väike lugu draiverist. Töötasin ettevõttes, kus oli palju andmeid. See oli reklaamitootmine, kus oli tohutult sündmusi, mida tuli kuskil salvestada. Ja mingil hetkel tuli ClickHouse. Valasime sinna andmed ja esialgu läks kõik hästi, aga hiljem ClickHouse kukkus kokku. Sel hetkel otsustasime, et see pole meile vajalik.

Aasta pärast naasime mõtte juurde kasutada ClickHouse'i ning meil tuli kuidagi andmeid seal kirjutada. Sissejuhatus oli selline — riistvara oli väga nõrk, ressursse oli vähe. Aga me oleme alati nii töötanud, seega vaatasime kohalikku protokolli poole.

Kuna me töötasime Go keeles, oli selge, et vajame Go draiverit. Teisin seda praktiliselt täiskohaga — see oli minu tööülesanne. Kuni mingisuguse hetkeni viimistlesime seda, ja põhimõtteliselt ei eeldanud keegi, et keegi peale meie seda kasutama hakkab. Siis tuli CloudFlare sama probleemiga ning mingil hetkel töötasime nendega väga ühte moodi, sest neil olid samad ülesanded. Tegime seda nii ClickHouse'is kui ka draiveris.

Mõnel hetkel lihtsalt lõpetasin sellega tegelemise, sest minu tegevus ClickHouse'i osas ja töö on natuke muutunud. Seetõttu jäävad probleemid lahendamata. Aeg-ajalt teevad inimesed meie hoidlasse commit'e, kellel on ka midagi tarvis. Siis vaatan pull request'e ja mõnikord isegi parandan midagi ise, kuid see juhtub harva.

Tahaksin draiveriga tagasi pöörduda. Mõni aasta tagasi, kui kõik see algas, oli ClickHouse ka teine ja selle võimalused olid teised. Praegu on aga aru saadud, kuidas draiverit ümber teha, et see toimiks hästi. Kui see juhtub, siis versioon 2 on igal juhul ühilduv, kuna vanad lahendused on kogunenud.

Kuidas seda korraldada, ei tea ma. Mul endal ei ole palju aega. Kui mõned inimesed hakkavad draiverit edasi arendama, saan neid aidata ja selgitada, mida teha. Kuid just aktiivne «Yandexi» osalemine projekti arengus ei ole veel arutlusele tulnud.

Alexei Milovidov: Praegu ei ole nende draiverite osas mingeid bürokraatiaid. Ainult see, et need on ametlikule organisatsioonile üle antud, mis tähendab, et see draiver on Go jaoks ametlikuks vaikimisi lahenduseks tunnustatud. On olemas muid draivereid, kuid need on eraldi.

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

Väline sõnastik ei tõuse pärast taaskäivitamist, kui lazy_load seade on sisse lülitatud. Mis peaks siis tegema?

Meil on sisse lülitatud lazy_load seade, ja pärast serveri taaskäivitamist ei tõuse sõnastik automaatselt. See tõuseb ainult siis, kui kasutaja sellele sõnastikule pöördub. Ja esmarakendamisel annab see veateate. Kas on võimalik kuidagi automaatselt ClickHouse'i abiga sõnastikke laadida, või peame alati nende valmisolekut ise jälgima, et kasutajad ei saaks vigu?

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

Esiteks on võimalik sõnastikke sundida laadima, kasutades päringut. süsteemi sõnastike uuendamine. Teiseks, mis puudutab viga — kui sõnastik on juba laaditud, siis päringud töötavad laaditud andmete järgi. Kui sõnastik pole veel laaditud, laaditakse see päringu hetkel.

Raskete sõnastike puhul pole see eriti mugav. Näiteks tuleb MySQL-st laadida miljon rida. Keegi teeb lihtsa select-i, kuid see select ootab miljonit rida. Siin on kaks lahendust. Esimene on välja lülitada lazy_load. Teine on see, et kui server käivitub, siis enne koormuse peale panemist teha süsteemi sõnastiku uuendamine või lihtsalt täita päring, mis kasutab sõnastikku. Siis laaditakse sõnastik. Peame ise kontrollima sõnastike kättesaadavust, kui lazy_load on sisse lülitatud, sest ClickHouse ei tõmba neid automaatselt.

Viimasele küsimusele vastus — kas versioon on vana või tuleb seda tõrkeotsinguga seadistada.

Kuidas toimida, kui süsteemi sõnaraamatute uuendamine ei laadi ühtegi olemasolevat sõnaraamatut, kui vähemalt üks neist ebaõnnestub?

Kas teil on veel küsimusi system reload dictionaries kohta? Meil on kaks sõnastikku — üks ei laadi, teine laaditakse. System reload dictionaries ei laadi sel juhul ühtegi sõnastikku, mistõttu tuleb konkreetsed sõnastikud uuesti laadida nende nimede kaudu system reload dictionary abil. Kas see on samuti seotud ClickHouse'i versiooniga?

Tahaksin teile head uudist. See käitumine on muutunud. Seega, kui te uuendate ClickHouse'i, siis see muutub ka. Kui teile praegune käitumine ei meeldi, süsteemi sõnastike uuendamine, siis uuendage ja loodame, et see muutub paremaks.

Kas on võimalik seadistada andmeid ClickHouse'i konfigureerimises, ilma et neid vigade korral paljastada?

Järgmiseks küsimuseks on vead, mis on seotud sõnastikuga, nimelt rekvisiidi. Oleme määranud ühenduse rekvisiidi ClickHouse'i konfiguratsioonis sõnastiku jaoks ja veateate korral saame need rekvisiidid ja parooli vastuseks.

Oleme selle vea lahendanud, viies rekvisiidid ODBC draiveri konfiguratsiooni. Kas on mingeid võimalusi rekvisiitide seadistamiseks ClickHouse'i konfiguratsioonis, ilma et me neid vigu esitades näitaksime?

Siin on lahendus: need credentials tuleb märkida odbc.ini failis, samas ClickHouse'is tuleb kasutada ainult ODBC Data Source Name'i. Muude andmeallikate puhul seda ei juhtu — ei MySQLi sõnastiku ega muude puhul ei tohiks te näha parooli veateate korral. ODBC osas vaatan ka — kui see on olemas, tuleb see lihtsalt eemaldada.

Boonus: taustad Zoomi koosolekute jaoks

Pildi klikkimisel avanevad kõige kangekaelsematele lugejatele boonuses foonid koos ühiselt veedetud hetkede teemadega. Tuleme koos tulekahjuga toime Avito tehnikate maskottide seltsis, arutame kolleegidega süsteemiadministraatori ruumis või vanakoolilise arvutiklubi keskkonnas ning viibime igapäevases koosolekus graffiti taustal silla all.

Allikas: habr.com