tabelifunktsioon input<\/a><\/noindex>.<\/p>\n<\/p>\n
<\/p>\n
Veel \u00fcks antipattern on mikros\u00fclemine. N\u00e4iteks, kui peate andmeid s\u00fclema ja teil on 5 serverit, aga homme tuleb 6serverit. Ja te m\u00f5tlete, kuidas neid andmeid \u00fcmber jagada. Ja selle asemel, et jagada 5 partii, teete 1 000 partiid. Ja edasi jagate iga\u00fche nende mikros\u00fclemite sarnaselt eraldi serveritele. Ja teil v\u00f5ib olla n\u00e4iteks \u00fches serveris 200 ClickHouse'i instance, n\u00e4iteks. Eraldi instance'id erinevatel portidel v\u00f5i eraldi andmebaasid. <\/p>\n
<\/p>\n
<\/p>\n
Aga ClickHouse'is pole see v\u00e4ga hea. Sest isegi \u00fcks ClickHouse instance p\u00fc\u00fcab kasutada k\u00f5ik saadaval olevad serveri ressursid \u00fche p\u00e4ringu t\u00f6\u00f6tlemiseks. St. teil on mingi server ja seal on n\u00e4iteks 56 protsessorituuma. Teete p\u00e4ringu, mis kestab \u00fche sekundi ja see kasutab 56 tuuma. Ja kui te olete sinna paigutanud 200 ClickHouse'i \u00fchte serverisse, siis t\u00e4hendab, et k\u00e4ivitub 10 000 l\u00f5ime. \u00dches\u00f5naga, k\u00f5ik l\u00e4heb v\u00e4ga halvasti.<\/p>\n
<\/p>\n
Teine p\u00f5hjus on see, et t\u00f6\u00f6 jaotus nende instance'ide vahel on eba\u00fchtlane. M\u00f5ni l\u00f5petab varem, m\u00f5ni hiljem. Kui see k\u00f5ik toimuks \u00fches instance'is, siis ClickHouse saaks ise aru, kuidas andmeid \u00f5igele l\u00f5ime jaotada. <\/p>\n
<\/p>\n
Ja veel \u00fcks p\u00f5hjus on see, et teil on protsessoritevaheline suhtlemine TCP kaudu. Andmeid tuleb serialiseerida, deserialiseerida ja see on tohutu hulk mikros\u00fclemeid. Lihtsalt ei ole efektiivne t\u00f6\u00f6.<\/p>\n
<\/p>\n
<\/p>\n
Veel \u00fcks antipattern, kuigi seda on raske antipatterniks nimetada. See on suur hulk eelagreed.<\/p>\n
<\/p>\n
\u00dcldiselt on eelagregeerimine hea. Teil oli miljard rida, te aggregeerisite selle ja see muutus 1 000 reaks, ja n\u00fc\u00fcd k\u00e4ib p\u00e4ring hetkega. K\u00f5ik on suurep\u00e4rane. Nii v\u00f5ib teha. Ja selle jaoks on isegi ClickHouse'is spetsiaalne tabelit\u00fc\u00fcp AggregatingMergeTree, mis teeb inkrementaalse aggregeerimise andmete sisestamise k\u00e4igus. <\/p>\n
<\/p>\n
Aga on olukordi, kus te arvate, et me kogume andmeid selliselt ja veel ka niimoodi. Ja mingis naaberosakonnas, millest ma ei taha r\u00e4\u00e4kida, kasutatakse SummingMergeTree tabeleid summade kogumiseks p\u00f5hiv\u00f5tme j\u00e4rgi, ning p\u00f5hiv\u00f5tmena kasutatakse 20 erinevat veergu. Ma muutsin m\u00f5ned veergude nimetused varjamiseks, kuid umbes nii see ongi.<\/p>\n
<\/p>\n
<\/p>\n
Ja tekivad sellised probleemid. Esiteks, teie andmete maht ei v\u00e4hene kuigi palju. N\u00e4iteks v\u00e4heneb see kolm korda. Kolm korda \u2013 see oleks hea hind, et lubada endale piiramatud anal\u00fc\u00fcsi v\u00f5imalused, mis tekivad, kui andmed ei ole koondatud. Kui andmed on koondatud, siis saate anal\u00fc\u00fcsi asemel vaid kehva statistika. <\/p>\n
<\/p>\n
Ja mis eriti h\u00e4irib? Et need inimesed naaberosakonnast tulevad ja k\u00fcsivad m\u00f5nikord, et lisage veel \u00fcks veerg p\u00f5hiv\u00f5tmesse. T. e. me oleme koondanud andmeid, aga n\u00fc\u00fcd tahame midagi rohkemat. Kuid ClickHouse'is ei ole v\u00f5imalik p\u00f5hiv\u00f5tit muuta. Seega peame kirjutama mingeid skripte C++. Ja ma ei armasta skripte, isegi kui need on C++.<\/p>\n
<\/p>\n
Ja kui vaadata, milleks ClickHouse loodi, siis mitteagreggeeritud andmed on just see stsenaarium, mille jaoks see on loodud. Kui kasutate ClickHouse't mitteagreggeeritud andmete jaoks, siis teete k\u00f5ik \u00f5igesti. Kui te aga koondate, siis m\u00f5nikord on see m\u00f6\u00f6dap\u00e4\u00e4smatu. <\/p>\n
<\/p>\n
<\/p>\n
Veel \u00fcks huvitav juhtum \u2013 see on l\u00f5pmatus ts\u00fcklis toimuvad p\u00e4ringud. Ma m\u00f5nikord sisenen m\u00f5nele tootmisserverile ja vaatan seal show processlist. Ja iga kord avastan, et toimub midagi kohutavat. <\/p>\n
<\/p>\n
N\u00e4iteks midagi sellist. Siit on kohe selge, et k\u00f5ik oleks saanud teostada \u00fches p\u00e4ringus. Lihtsalt kirjutage url in ja nimekiri.<\/p>\n
<\/p>\n
<\/p>\n
Miks on palju selliseid p\u00e4ringuid l\u00f5pmatus ts\u00fcklis halb? Kui indeksi ei kasutata, siis teil on palju l\u00e4bimineid samade andmete kohta. Kuid kui indeks on kasutusel, n\u00e4iteks kui teil on p\u00f5hiv\u00f5ti ru ja kirjutate url = millegi kohta. Ja te arvate, et loetakse tabelist \u00fche url'i, siis k\u00f5ik on korras. Kuid tegelikult ei ole. Sest ClickHouse teeb k\u00f5ik pakettide kaupa. <\/p>\n
<\/p>\n
Kui tal on vaja lugeda andmete vahemikku, loeb ta veidi rohkem, kuna ClickHouse'i indeks on haruldane. See indeks ei v\u00f5imalda tabelist leida \u00fchte konkreetset rida, vaid ainult mingit vahemikku. Andmed tihendatakse plokkide kaupa. \u00dche rea lugemiseks tuleb v\u00f5tta kogu plokk ja see avada. Ja kui teete hulga p\u00e4ringuid, siis teil on palju kattuvusi ja palju t\u00f6\u00f6d, mida tehakse j\u00e4lle ja j\u00e4lle.<\/p>\n
<\/p>\n
<\/p>\n
Ja boonusena v\u00f5ib m\u00e4rkida, et ClickHouse'is ei pea kartma edastada isegi megabaite ja isegi sadu megabaite IN-sektsiooni. M\u00e4letan meie praktikast, et kui MySQL-is edastame palju v\u00e4\u00e4rtusi IN-sektsiooni, n\u00e4iteks edastame 100 megabaidi numbreid, siis MySQL s\u00f6\u00f6b 10 gigabaiti m\u00e4lu ja sellega enam midagi ei juhtu, k\u00f5ik t\u00f6\u00f6tab halvasti. <\/p>\n
<\/p>\n
Ja teiseks \u2013 ClickHouse'is, kui teie p\u00e4ringud kasutavad indeksit, siis see ei ole kunagi aeglasem kui t\u00e4iskann, st kui lugeda tuleb peaaegu kogu tabelit, siis see toimub j\u00e4rjestikku ja loeb kogu tabeli. \u00dcldiselt m\u00f5istab see ise, millega on tegu.<\/p>\n
<\/p>\n
Kuid sellel on siiski teatud keerukused. N\u00e4iteks see, et IN koos alamp\u00e4ringuga ei kasuta indeksit. Kuid see on meie probleem ja peame selle parandama. Siin pole midagi fundamentaalset. Parandame selle. <\/p>\n
<\/p>\n
Ja veel \u00fcks huvitav asi \u2013 kui teil on v\u00e4ga pikk p\u00e4ring ja jaotatud p\u00e4ringute t\u00f6\u00f6tlemine k\u00e4ib, siis see v\u00e4ga pikk p\u00e4ring saadetakse igale serverile ilma tihendamiseta. N\u00e4iteks 100 megabaidi ja 500 serveriga. Seega edastatakse teie v\u00f5rgus 50 gigabaiti. See edastatakse ja seej\u00e4rel t\u00e4idetakse k\u00f5ik edukalt.<\/p>\n
<\/p>\n
* juba kasutab; k\u00f5ik on parandatud, nagu lubatud.<\/p>\n
<\/p>\n
<\/p>\n
Ja \u00fcsna sagedane juhtum on see, kui p\u00e4ringud tulevad API-st. N\u00e4iteks olete loonud oma teenuse. Ja kui teie teenus on kellelegi vajalik, siis olete avanud API ja juba kaks p\u00e4eva hiljem n\u00e4ete, et toimub midagi arusaamatut. K\u00f5ik on \u00fcle koormatud ja paar kohutavat p\u00e4ringut tuleb, mida kunagi ei oleks pidanud olema. <\/p>\n
<\/p>\n
Ja siin on lahendus \u00fcks. Kui olete avanud API, peate selle k\u00e4rpima. N\u00e4iteks tuleks kehtestada mingid kvoodid. Teisi normaalseid v\u00f5imalusi pole. Vastasel juhul kirjutatakse kohe skript ja tekivad probleemid. <\/p>\n
<\/p>\n
Ja ClickHouse'is on spetsiaalne v\u00f5imalus \u2013 kvota arvestamine. Lisaks on v\u00f5imalik edastada oma kvota v\u00f5ti. See v\u00f5ib olla n\u00e4iteks kasutaja sisemine identifikaator. Ja kvotad arvestatakse iga\u00fche jaoks eraldi. <\/p>\n
<\/p>\n
<\/p>\n
N\u00fc\u00fcd veel \u00fcks huvitav asi. See on k\u00e4sitsi juhitav replikeerimine. <\/p>\n
<\/p>\n
Ma tean palju juhtumeid, kus, hoolimata ClickHouse'is olevast sisseehitatud replikeerimise toest, replikeerivad inimesed ClickHouse'i k\u00e4sitsi.<\/p>\n
<\/p>\n
Millisest printsiibist on jutt? Teil on andmete t\u00f6\u00f6tlemise pipeline. Ja see toimib iseseisvalt, n\u00e4iteks erinevates andmekeskustes. Te kirjutate sama teavet ClickHouse'i samamoodi. T\u00f5si, praktika n\u00e4itab, et andmed l\u00e4hevad ikkagi erinevaks, s\u00f5ltuvalt teie koodis esinevatest erip\u00e4rastest. Loodetavasti mitte teie omades. <\/p>\n
<\/p>\n
Ja aeg-ajalt peate ikkagi k\u00e4sitsi s\u00fcnkroonima. N\u00e4iteks kord kuus teevad administraatorid rsync'i.<\/p>\n
<\/p>\n
Tegelikult on palju lihtsam kasutada ClickHouse'i sisseehitatud replikeerimist. Kuid siin v\u00f5ivad olla teatud vastun\u00e4idustused, sest selleks peate kasutama ZooKeeperit. Ma ei \u00fctle midagi halba ZooKeeperi kohta, p\u00f5him\u00f5tteliselt on s\u00fcsteem t\u00f6\u00f6v\u00f5imel, kuid m\u00f5nikord ei kasuta inimesed seda java-fobi t\u00f5ttu, sest ClickHouse on nii hea s\u00fcsteem, mis on kirjutatud C++-s, mida saab kasutada ja k\u00f5ik t\u00f6\u00f6tab h\u00e4sti. Aga ZooKeeper on java peal. Ja kuidagi ei tahaks isegi vaadata, kuid siis v\u00f5ite kasutada k\u00e4sitsi juhitavat replikeerimist. <\/p>\n
<\/p>\n
<\/p>\n
ClickHouse on praktiline s\u00fcsteem. See arvestab teie vajadustega. Kui teil on k\u00e4sitsi juhitav replikeerimine, siis saate luua Jaotatud tabeli, mis vaatab teie k\u00e4sitsireplikaid ja teeb nende vahel automaatse failover'i. Ja on isegi spetsiaalne valik, mis v\u00f5imaldab v\u00e4ltida flappe, isegi kui teie replikad erinevad s\u00fcsteemselt.<\/p>\n
<\/p>\n
<\/p>\n
Edasi v\u00f5ivad tekkida probleemid, kui kasutate primitiivseid tabelimootoreid. ClickHouse on nagu ehituskonstruktor, kus on palju erinevaid tabelimootoreid. K\u00f5igi t\u00f5siste juhtumite jaoks, nagu on dokumentatsioonis kirjutatud, kasutage MergeTree perekonna tabeleid. K\u00f5ik teised on pigem erijuhtumiteks v\u00f5i testimiseks.<\/p>\n
<\/p>\n
MergeTree tabelis ei pea teil olema mingit kuup\u00e4eva ja aega. Saate ikkagi kasutada. Kui kuup\u00e4eva ja aega ei ole, kirjutage default \u2013 2000. aasta. See t\u00f6\u00f6tab ja ei n\u00f5ua ressursse. <\/p>\n
<\/p>\n
Ja uues serveri versioonis on isegi v\u00f5imalik m\u00e4\u00e4rata, et teil oleks kohandatud jagamine ilma partitsiooni v\u00f5tmeta. See on sama. <\/p>\n
<\/p>\n
<\/p>\n
Teiselt poolt v\u00f5ib kasutada primitiivseid tabelimootoreid. N\u00e4iteks laadige andmed \u00fcks kord sisse ja vaadake, m\u00e4ngige nendega ja kustutage. V\u00f5ite kasutada Logi.<\/p>\n
<\/p>\n
V\u00f5i salvestada v\u00e4ikseid mahtusid vahepealseks t\u00f6\u00f6tlemiseks \u2013 see on StripeLog v\u00f5i TinyLog.<\/p>\n
<\/p>\n
M\u00e4lu saab kasutada, kui andmete maht on v\u00e4ike ja lihtsalt m\u00e4ngitakse midagi m\u00e4llu. <\/p>\n
<\/p>\n
<\/p>\n
ClickHouse ei armasta \u00fclem\u00e4\u00e4raselt normaliseeritud andmeid. <\/p>\n
<\/p>\n
Siin on t\u00fc\u00fcpiline n\u00e4ide. See on tohutu hulk URL-e. Te panite need naabertabelisse. Siis otsustasite neid JOINida, aga see ei toimi, kuna ClickHouse toetab ainult Hash JOINi. Kui m\u00e4lust ei piisa andmete koguni, millega tuleb liita, siis JOIN ei \u00f5nnestu.* <\/p>\n
<\/p>\n
Kui andmed on suure kardinaalsusega, siis \u00e4rge muretsege, hoidke neid denormaliseeritud kujul, URL-id otse p\u00f5hitaotluses. <\/p>\n
<\/p>\n
* kuid n\u00fc\u00fcd on ClickHouse'il ka merge join ja see t\u00f6\u00f6tab, kui vaheandmed ei mahu m\u00e4llu. Kuid see ei ole efektiivne ja soovitus kehtib endiselt.<\/p>\n
<\/p>\n
<\/p>\n
Veel paar n\u00e4idet, kuid ma juba kahtlen, kas need on t\u00f5eliselt antipaaterid v\u00f5i mitte. <\/p>\n
<\/p>\n
ClickHouse'il on \u00fcks tuntud puudus. Ta ei oska uuendusi teha*. Teatud m\u00f5ttes on see isegi hea. Kui teil on olulisi andmeid, n\u00e4iteks raamatupidamine, siis keegi ei suuda neid saata, sest uuendusi pole.<\/p>\n
<\/p>\n
* juba ammu on lisatud toetus uuendamiseks ja kustutamiseks partii re\u017eiimis.<\/p>\n
<\/p>\n
Kuid on m\u00f5ned erilised viisid, mis v\u00f5imaldavad uuendusi nagu taustal. N\u00e4iteks ReplaceMergeTree t\u00fc\u00fcpi tabelid. Need teevad uuendusi taustal toimuvate \u00fchinemiste ajal. Saate seda sundida optimize table abil. Kuid \u00e4rge tehke seda liiga tihti, sest see t\u00e4hendab partitsiooni t\u00e4ielikku kirjutamist. <\/p>\n
<\/p>\n
Jaotatud JOIN'id ClickHouse'is \u2013 see on samuti halvasti planeerimisre\u017eiimiga t\u00f6\u00f6deldud. <\/p>\n
<\/p>\n
Halb, kuid m\u00f5nikord on see korras.<\/p>\n
<\/p>\n
ClickHouse'i kasutamine ainult selleks, et lugeda andmeid tagasi select* abil.<\/p>\n
<\/p>\n
Ma ei soovitaks ClickHouse'i kasutada mahukate arvutuste jaoks. Kuid asi ei ole t\u00e4iesti nii, kuna me oleme juba sellest soovitusest k\u00f5rvale kaldumas. Ja meil on hiljuti lisandunud v\u00f5imalus rakendada masin\u00f5ppemudeleid ClickHouse'is \u2013 Catboost. See teeb mind murelikuks, sest ma m\u00f5tlen: \"Kohutav. Kui palju siis takte byte kohta tuleb!\". Mul on t\u00f5eliselt kahju, et takte byte'ide peale kulutada. <\/p>\n
<\/p>\n
<\/p>\n
Aga \u00e4rge muretsege, installige ClickHouse ja k\u00f5ik l\u00e4heb h\u00e4sti. Kui midagi juhtub, on meil kogukond. Muide, kogukond olete teie. Ja kui teil on mingeid probleeme, saate v\u00e4hemalt meie chati astuda ja loodan, et teid aidatakse. <\/p>\n
<\/p>\n
K\u00fcsimused<\/p>\n
<\/p>\n
Ait\u00e4h ettekande eest! Kuhu kaevata ClickHouse'i kokkuvarisemise \u00fcle?<\/em><\/p>\n<\/p>\n
V\u00f5ite kaevata otse minu juurde praegu. <\/p>\n
<\/p>\n
Ma hakkasin hiljuti ClickHouse'i kasutama. Koheselt kukutasin cli liidese.<\/em><\/p>\n<\/p>\n
Teid on \u00f5nnistatud. <\/p>\n
<\/p>\n
Veidi hiljem kukutasin v\u00e4ikese select'iga serveri.<\/em><\/p>\n<\/p>\n
Teil on anne. <\/p>\n
<\/p>\n
Avasin GitHubis vea, kuid seda ignoreeriti.<\/em> <\/p>\n<\/p>\n
Vaadake. <\/p>\n
<\/p>\n
Aleksei t\u00f5i mind ettekandesse vale p\u00e4rast, lubades r\u00e4\u00e4kida, kuidas te andmeid pressite.<\/em><\/p>\n<\/p>\n
V\u00e4ga lihtne. <\/p>\n
<\/p>\n
Seda ma arvasin juba eile. Rohkem konkreetikast.<\/em> <\/p>\n<\/p>\n
Seal pole mingeid kohutavaid trikke. Seal on lihtsalt blokkide kaupa tihendamine. Vaikimisi kasutatakse LZ4, ZSTD* saab sisse l\u00fclitada. Blokid on vahemikus 64 kilobaiti kuni 1 megabaidini.<\/p>\n
<\/p>\n
* Samuti on olemas spetsialiseeritud tihenduskoodikate tugi, mida saab kasutada muude algoritmidega ahelas.<\/p>\n
<\/p>\n
Kas blokid sisaldavad lihtsalt tooreid andmeid?<\/em><\/p>\n<\/p>\n
Ei ole t\u00e4iesti toored. Seal on massiivid. Kui teil on numbriline veerg, siis numbrid on j\u00e4rjestikku massiivis. <\/p>\n
<\/p>\n
Selge.<\/em> <\/p>\n<\/p>\n
Aleksei, n\u00e4ide, mis oli uniqExact'iga ip aadresside puhul, st see, et uniqExact arvutamine ridade peal kestab kauem kui numbrite jaoks jne. Aga kui me rakendame trikki ja castime kokku lugemise ajal? St te, n\u00e4iliselt \u00fctlesite, et kettal ei erine see oluliselt. Kui me loeme ketas ridu, castime, kas siis on meil aggregaadid kiiremad v\u00f5i ei? V\u00f5i me siiski ei saa siin m\u00e4rgatavat kasu? Mul on tunne, et te testisite seda, kuid mingil p\u00f5hjusel ei maininud te seda benchmark'is.<\/em> <\/p>\n<\/p>\n
Ma arvan, et see on aeglasem kui ilma kastita. Sel juhul tuleb IP-aadressi stringist eraldada. Meil on ClickHouse'is ka IP-aadresside eraldamine optimeeritud. Me oleme selle nimel k\u00f5vasti vaeva n\u00e4inud, aga seal on numbrid kirja pandud k\u00fcmnendvormis. V\u00e4ga ebamugav. Teisest k\u00fcljest t\u00f6\u00f6tab uniqExact funktsioon stringide puhul aeglasemalt mitte ainult sellep\u00e4rast, et need on stringid, vaid ka seet\u00f5ttu, et valitakse teine algoritmi spetsialiseerumine. Stringe t\u00f6\u00f6deldakse lihtsalt teistmoodi.<\/p>\n
<\/p>\n
Aga kui v\u00f5tta lihtsam andmet\u00fc\u00fcp? N\u00e4iteks, kui me paneme kirja user id, mis meil on in, kirjutame selle stringina ja siis kastime, kas siis on l\u00f5busam v\u00f5i mitte?<\/em><\/p>\n<\/p>\n
Ma kahtlen. Arvan, et see on isegi kurvem, sest numbrite eraldamine on t\u00f5eliselt t\u00f5sine probleem. Ma arvan, et sellel kollegil oli isegi esitluses teema, kuidas numbrite eraldamine k\u00fcmnendvormis on keeruline, v\u00f5i v\u00f5ib-olla mitte. <\/p>\n
<\/p>\n
Aleksei, suur ait\u00e4h esitluse eest! Ja suur ait\u00e4h ClickHouse'i eest! Mul on k\u00fcsimus plaanide kohta. Kas on plaanis funktsioon, et s\u00f5naraamatute osalist uuendamist?<\/em><\/p>\n<\/p>\n
T. e. osaline taask\u00e4ivitamine?<\/p>\n
<\/p>\n
Jah-jah. Nagu v\u00f5imalus m\u00e4\u00e4rata seal MySQL v\u00e4li, t. e. uuendada after, et laadida ainult need andmed, kui s\u00f5naraamat on v\u00e4ga suur.<\/em><\/p>\n<\/p>\n
V\u00e4ga huvitav funktsioon. Ja mulle tundub, et keegi inimene pakkus seda meie vestluses. V\u00f5ib-olla olite see isegi teie. <\/p>\n
<\/p>\n
Ma ei arva, et see olin mina.<\/em><\/p>\n<\/p>\n
Suurep\u00e4rane, n\u00fc\u00fcd on siis kaks p\u00e4ringut. Ja v\u00f5ib rahulikult alustada tegemist. Aga tahan kohe teid hoiatada, et see funktsioon on \u00fcsna lihtne ellu viia. T. e. p\u00f5him\u00f5tteliselt tuleb lihtsalt tabelisse kirjutada versiooni number ja seej\u00e4rel kirjutada: versioon on v\u00e4iksem kui see ja see. Ja see t\u00e4hendab, et me t\u00f5en\u00e4oliselt pakume selle tegemiseks entusiastidele. Kas te olete entusiast? <\/p>\n
<\/p>\n
Jah, aga kahjuks mitte C++-s.<\/em><\/p>\n<\/p>\n
Kas teie kolleegid oskavad C++-s kirjutada? <\/p>\n
<\/p>\n
Ma leian kellegi.<\/em><\/p>\n<\/p>\n
Suurep\u00e4rane*.<\/p>\n
<\/p>\n
* funktsioon lisati kaks kuud p\u00e4rast esitluse tegemist \u2013 selle t\u00f6\u00f6tas v\u00e4lja k\u00fcsimuse autor ja saatis oma pull request<\/a><\/noindex>.<\/p>\n<\/p>\n
Ait\u00e4h!<\/em><\/p>\n<\/p>\n
Tere! Ait\u00e4h ettekande eest! Mainisite, et ClickHouse kasutab v\u00e4ga h\u00e4sti \u00e4ra k\u00f5ik selle jaoks saadaval olevad ressursid. Ja naaberettekande tegija Luxsoftist r\u00e4\u00e4kis oma lahendusest Venemaa Posti jaoks. Ta \u00fctles, et ClickHouse meeldis neile v\u00e4ga, kuid nad ei kasutanud seda oma peamise konkurendi asemel just sellep\u00e4rast, et see kasutas \u00e4ra kogu protsessori. Ja nad ei suutnud seda integreerida oma arhitektuuri, oma ZooKeeperi ja konteineritega. Kas on v\u00f5imalus kuidagi piirata ClickHouse'i, et see ei kasutaks k\u00f5ike, mis talle k\u00e4tte satub?<\/em><\/p>\n<\/p>\n
Jah, see on v\u00f5imalik ja v\u00e4ga lihtne. Kui soovite, et see kasutaks v\u00e4hem tuumasid, kirjutage lihtsalt set max_threads = 1<\/code>. Ja k\u00f5ik, see t\u00e4idab p\u00e4ringu \u00fches tuumas. Samuti saavad erinevad kasutajad kasutada erinevaid seadeid. Seega ei ole probleeme. Ja edastage oma kolleegidele Luxsoftist, et ei ole hea, et nad ei leidnud seda seadet dokumentatsioonist. <\/p>\n<\/p>\n
Tere, Aleksei! Sooviksin k\u00fcsida sellise k\u00fcsimuse. Juba mitte esimest korda kuulen, et paljud hakkavad kasutama ClickHouse'i logide hoidmiseks. Ettekandes \u00fctlesite, et seda ei tohi teha, st ei ole vaja hoida pikki ridu. Kuidas Te sellele suhtute?<\/em><\/p>\n<\/p>\n
Esiteks, logid on reeglina mitte pikad read. Muidugi, erandeid v\u00f5ib olla. N\u00e4iteks, kui mingi teenus, mis on kirjutatud java's, viskab exception'i ja see logitakse. Ja nii l\u00f5pmatus ts\u00fcklis, ja l\u00f5puks l\u00f5peb koht k\u00f5vakettal. Lahendus on v\u00e4ga lihtne. Kui read on liiga pikad, siis l\u00f5igake need. Ja mis t\u00e4hendab pikad? K\u00fcmned kilobaitid \u2013 see on halb*.<\/p>\n
<\/p>\n
* uutes versioonides ClickHouse on sisse l\u00fclitatud "kohandatav graanulite indeks", mis lahendab peamiselt probleemid pikkade stringide salvestamisega.<\/p>\n
<\/p>\n
Aga kilobait \u2013 see on normaalne?<\/em><\/p>\n<\/p>\n
Normaalne. <\/p>\n
<\/p>\n
Tere! Ait\u00e4h ettekande eest! Olen juba sellest vestluses k\u00fcsinud, aga ei m\u00e4leta, kas sain vastuse. Kas plaanitakse laiendada ANDMESEKTSIOONI nagu CTE?<\/em><\/p>\n<\/p>\n
Praegu ei. Meie ANDMESEKTSIOON on natuke ebasiiras. See on meil nagu v\u00e4ike funktsioon.<\/p>\n
<\/p>\n
Sain aru. Ait\u00e4h!<\/em><\/p>\n<\/p>\n
Ait\u00e4h ettekande eest! V\u00e4ga huvitav! \u00dcks globaalne k\u00fcsimus. Kas on plaanis ehk teha m\u00f5ningaid silte andmete kustutamise modifikatsiooniks?<\/em><\/p>\n<\/p>\n
Kohustuslikult. See on meie esmane \u00fclesanne meie j\u00e4rjekorras. Praegu oleme aktiivselt v\u00e4lja m\u00f5tlemas, kuidas k\u00f5ike \u00f5igesti teha. Ja n\u00fc\u00fcd on aeg hakata klaviatuurile vajutama*.<\/p>\n
<\/p>\n
* vajutades klahve klaviatuuril, tegime k\u00f5ik \u00e4ra.<\/p>\n
<\/p>\n
Kas see m\u00f5jutab kuidagi s\u00fcsteemi j\u00f5udlust v\u00f5i mitte? Kas sisestamine on sama kiire, kui see on praegu?<\/em><\/p>\n<\/p>\n
V\u00f5ib-olla ise deletes, ise updates on v\u00e4ga rasked, kuid see ei m\u00f5juta selects ja inserts j\u00f5udlust.<\/p>\n
<\/p>\n
Ja veel \u00fcks v\u00e4ike k\u00fcsimus. Esitluses r\u00e4\u00e4kisite peamise v\u00f5tme kohta. Seega, meil on partitsioneerimine, mis on vaikimisi kuup\u00f5hine, eks? Ja kui me m\u00e4\u00e4rame kuup\u00e4evade vahemiku, mis mahub kuusse, siis loetakse ainult seda partitsiooni, eks?<\/em><\/p>\n<\/p>\n
Jah.<\/p>\n
<\/p>\n
Selline k\u00fcsimus. Kui me ei saa m\u00e4\u00e4rata mingit peamist v\u00f5tit, kas on \u00f5ige teha see v\u00e4ljale \"Kuup\u00e4ev\" selleks, et taustal oleks v\u00e4hem andmete \u00fcmberkorraldamist ning need oleksid korrastatumalt paigutatud? Kui teil ei ole vahemiku p\u00e4ringuid ja te isegi ei saa valida mingit peamist v\u00f5tit, kas on siis m\u00f5tet kuup\u00e4eva peamisse v\u00f5tmesse panna?<\/em><\/p>\n<\/p>\n
Jah.<\/p>\n
<\/p>\n
V\u00f5ib-olla on m\u00f5istlik panna peamisse v\u00f5tmesse selline v\u00e4li, mille j\u00e4rgi andmeid oleks lihtsam kompressida, kui need on selle v\u00e4li j\u00e4rgi sorteeritud. N\u00e4iteks, kasutaja identifikaator. Kasutaja, n\u00e4iteks, k\u00fclastab sama veebisaiti. Sellisel juhul panege kasutaja id ja aeg. Siis on teie andmed paremini kompressitud. Seoses kuup\u00e4evaga, kui teil t\u00f5epoolest ei ole ja ei ole kunagi vahemiku p\u00e4ringuid kuup\u00e4evade j\u00e4rgi, siis ei ole m\u00f5tet kuup\u00e4eva peamisse v\u00f5tmesse panna. <\/p>\n
<\/p>\n
Hea, ait\u00e4h palju!<\/em><\/p>\nAllikas: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0422\u0430\u043a \u043a\u0430\u043a ClickHouse \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0441\u043f\u0435\u0446\u0438\u0430\u043b\u0438\u0437\u0438\u0440\u043e\u0432\u0430\u043d\u043d\u043e\u0439 \u0441\u0438\u0441\u0442\u0435\u043c\u043e\u0439, \u043f\u0440\u0438 \u0435\u0433\u043e \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043d\u0438\u0438 \u0432\u0430\u0436\u043d\u043e \u0443\u0447\u0438\u0442\u044b\u0432\u0430\u0442\u044c \u043e\u0441\u043e\u0431\u0435\u043d\u043d\u043e\u0441\u0442\u0438 \u0435\u0433\u043e \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u044b. \u0412 \u044d\u0442\u043e\u043c \u0434\u043e\u043a\u043b\u0430\u0434\u0435 \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u0440\u0430\u0441\u0441\u043a\u0430\u0436\u0435\u0442 \u043e \u043f\u0440\u0438\u043c\u0435\u0440\u0430\u0445 \u0442\u0438\u043f\u0438\u0447\u043d\u044b\u0445 \u043e\u0448\u0438\u0431\u043e\u043a \u043f\u0440\u0438 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043d\u0438\u0438 ClickHouse, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043c\u043e\u0433\u0443\u0442 \u043f\u0440\u0438\u0432\u0435\u0441\u0442\u0438 \u043a \u043d\u0435\u044d\u0444\u0444\u0435\u043a\u0442\u0438\u0432\u043d\u043e\u0439 \u0440\u0430\u0431\u043e\u0442\u0435. \u041d\u0430 \u043f\u0440\u0438\u043c\u0435\u0440\u0430\u0445 \u0438\u0437 \u043f\u0440\u0430\u043a\u0442\u0438\u043a\u0438 \u0431\u0443\u0434\u0435\u0442 \u043f\u043e\u043a\u0430\u0437\u0430\u043d\u043e, \u043a\u0430\u043a \u0432\u044b\u0431\u043e\u0440 \u0442\u043e\u0439 \u0438\u043b\u0438 \u0438\u043d\u043e\u0439 \u0441\u0445\u0435\u043c\u044b \u043e\u0431\u0440\u0430\u0431\u043e\u0442\u043a\u0438 \u0434\u0430\u043d\u043d\u044b\u0445 \u043c\u043e\u0436\u0435\u0442 \u0438\u0437\u043c\u0435\u043d\u0438\u0442\u044c \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u044c \u043d\u0430 \u043f\u043e\u0440\u044f\u0434\u043a\u0438. \u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442! \u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":91439,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-91438","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"ClickHouse'i](\"\/wp-content\/uploads\/2020\/08\/8e42c1fffffcc964eacef240ea90bbc5.jpg\")
<\/p>\n