{"id":91438,"date":"2020-08-13T19:42:36","date_gmt":"2020-08-13T17:42:36","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/effektivnoe-ispolzovanie-clickhouse-aleksej-milovidov-yandeks"},"modified":"2020-08-13T19:42:36","modified_gmt":"2020-08-13T17:42:36","slug":"effektivnoe-ispolzovanie-clickhouse-aleksej-milovidov-yandeks","status":"publish","type":"post","link":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/effektivnoe-ispolzovanie-clickhouse-aleksej-milovidov-yandeks","title":{"rendered":"ClickHouse'i efektiivne kasutamine. Aleksei Milovidov (Yandex)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"ClickHouse'i<\/p>\n

<\/p>\n

Kuna ClickHouse on spetsiifiline s\u00fcsteem, tuleb selle kasutamisel arvesse v\u00f5tta selle arhitektuuri erip\u00e4ra. Selles ettekandes r\u00e4\u00e4gib Aleksei n\u00e4idetest t\u00fc\u00fcpilistest vigadest ClickHouse'i kasutamisel, mis v\u00f5ivad viia ebaefektiivse t\u00f6\u00f6ni. Praktikast tulevad n\u00e4ited n\u00e4itavad, kuidas andmete t\u00f6\u00f6tlemise skeemi valik v\u00f5ib oluliselt muuta j\u00f5udlust.<\/p>\n

<\/a><\/noindex><\/p>\n

Tere k\u00f5igile! Minu nimi on Aleksei, ma teen ClickHouse'i.<\/p>\n

<\/p>\n

\"ClickHouse'i<\/p>\n

<\/p>\n

Esiteks, kiirustan teid r\u00f5\u00f5mustama, et ma ei hakka t\u00e4na r\u00e4\u00e4kima, mis on ClickHouse. Ausalt \u00f6eldes, mulle on see juba t\u00fc\u00fctav. Iga kord r\u00e4\u00e4gin sellest. Ja t\u00f5en\u00e4oliselt teavad k\u00f5ik juba. <\/p>\n

<\/p>\n

\"ClickHouse'i<\/p>\n

<\/p>\n

Selle asemel r\u00e4\u00e4gin ma v\u00f5imalikest komistuskividest, st kuidas ClickHouse'i vale kasutamine v\u00f5ib juhtuda. Tegelikult ei ole p\u00f5hjust muretseda, sest me arendame ClickHouse'i s\u00fcsteemina, mis on lihtne, mugav ja t\u00f6\u00f6tab otse karbist. Paigaldad ja k\u00f5ik, mingeid probleeme pole. <\/p>\n

<\/p>\n

Siiski tuleb arvestada, et see s\u00fcsteem on spetsialiseeritud ning v\u00f5ib kergesti sattuda ebatavalisse kasutusstsenaariumi, mis viib selle mugavustsoonist v\u00e4lja.<\/p>\n

<\/p>\n

Nii et millised on n\u00e4htavad probleemid? Peamiselt r\u00e4\u00e4gin ilmselgetest asjadest. K\u00f5ik saavad aru, k\u00f5ik m\u00f5istavad ja v\u00f5ivad r\u00f5\u00f5mustada, et nad on nii targad, ning need, kes ei saa aru, saavad midagi uut teada. <\/p>\n

<\/p>\n

\"ClickHouse'i<\/p>\n

<\/p>\n

Esimene ja k\u00f5ige lihtsam n\u00e4ide, millega kahjuks sageli kokku puututakse, on suur hulk sisendeid, mis on v\u00e4ikesed partiid, st suur hulk v\u00e4ikeseid sisendeid.<\/p>\n

<\/p>\n

Kui vaadata, kuidas ClickHouse sisendeid sooritab, siis v\u00f5ite \u00fche p\u00e4ringuga saata isegi terabaidi andmevoo. See ei ole probleem. <\/p>\n

<\/p>\n

Vaatame n\u00fc\u00fcd, milline on t\u00fc\u00fcpiline tulemuslikkus. N\u00e4iteks meil on tabel Yandex.Metrika andmetega. Hitid. 105 erinevat veergu. 700 baiti tihendamata kujul. Ja alustame sisestamist korralike partiidena, kus on miljon rida. <\/p>\n

<\/p>\n

Sisestades MergeTree tabelisse, saame umbes pool miljonit rida sekundis. Suurep\u00e4rane! Replitseeritud tabelis on see veidi v\u00e4hem, umbes 400 000 rida sekundis. <\/p>\n

<\/p>\n

Ja kui aktiveerida kvora sisestamine, siis saadakse pisut v\u00e4hem, kuid ikkagi korralik j\u00f5udlus, 250 000 rida sekundis. Kvora sisestamine on dokumenteerimata v\u00f5imalus ClickHouse'is*.<\/p>\n

<\/p>\n

* seisuga 2020. aasta. on juba dokumenteeritud<\/a><\/noindex>.<\/p>\n

<\/p>\n

\"ClickHouse'i<\/p>\n

<\/p>\n

Mida teha, kui asjad l\u00e4hevad halvasti? Sisestame \u00fche rea korraga MergeTree tabelisse ja saame 59 rida sekundis. See on 10 000 korda aeglasem. ReplicatedMergeTree puhul on see 6 rida sekundis. Ja kui kvora veel sisse l\u00fclitada, siis on see 2 rida sekundis. Minu arvates on see t\u00e4ielik fiasco. Kuidas saab nii aeglane olla? Mul on isegi T-s\u00e4rgis kirjas, et ClickHouse ei tohi aeglane olla. Kuid siiski juhtub seda m\u00f5nikord. <\/p>\n

<\/p>\n

\"ClickHouse'i<\/p>\n

<\/p>\n

Tegelikult on see meie viga. Me oleks saand teha nii, et k\u00f5ik t\u00f6\u00f6taks normaalselt, aga me ei teinud. Ja me ei teinud sellep\u00e4rast, et meie stsenaariumis ei olnud see vajalik. Meil olid juba partiid. Lihtsalt meie jaoks tulid partiid sisse ja polnud mingeid probleeme. Paneme andmed sisse ja k\u00f5ik t\u00f6\u00f6tab normaalselt. Aga muidugi v\u00f5ivad esineda igasuguseid stsenaariume. N\u00e4iteks, kui teil on hulk servereid, kus andmeid genereeritakse. Ja nad sisestavad andmeid mitte nii sageli, kuid siiski tulevad sagedased sisestused. Ja sellega tuleb kuidagi toime tulla. <\/p>\n

<\/p>\n

Tehnilisest k\u00fcljest on asi selles, et kui teete ClickHouse'is sisestuse, ei satu andmed \u00fchtegi memtable'i. Meil pole isegi reaalset log structure MergeTree't, vaid lihtsalt MergeTree, kuna log'i ega memTable'i pole. Me kirjutame andmed otse failis\u00fcsteemi, juba veergude kaupa jaotatuna. Ja kui teil on 100 veergu, tuleb kirjutada \u00fcle 200 faili eraldi kausta. See k\u00f5ik on \u00fcsna mahukas. <\/p>\n

<\/p>\n

\"ClickHouse'i<\/p>\n

<\/p>\n

Ja tekib k\u00fcsimus: \"Kuidas \u00f5igesti teha?\", kui selline olukord, et tuleb siiski kuidagi andmeid ClickHouse'i salvestada.<\/p>\n

<\/p>\n

Meetod 1. See on k\u00f5ige lihtsam meetod. Kasutage m\u00f5nda hajutatud j\u00e4rjekorda, n\u00e4iteks Kafka. Lihtsalt t\u00f5state andmeid Kafka'st, bat\u0161it iga sekundi j\u00e4rel. Ja k\u00f5ik on korras, salvestate ja k\u00f5ik t\u00f6\u00f6tab normaalselt. <\/p>\n

<\/p>\n

Puuduseks on see, et Kafka on veel \u00fcks kohmakas hajutatud s\u00fcsteem. Ma saan aru, kui teil on ettev\u00f5ttes juba Kafka. See on hea, see on mugav. Kuid kui seda ei ole, siis tasub enne veel \u00fche hajutatud s\u00fcsteemi projekti toomist kolm korda m\u00f5elda. Seep\u00e4rast tasub kaaluda alternatiive. <\/p>\n

<\/p>\n

\"ClickHouse'i<\/p>\n

<\/p>\n

Meetod 2. Selline vanakooli alternatiiv, mis on samas v\u00e4ga lihtne. Teil on server, mis genereerib teie logisid. Ja see salvestab teie logid failina. Ja n\u00e4iteks korra sekundis nimetame selle faili \u00fcmber ja avame uue. Eraldi skript, kas croni v\u00f5i m\u00f5ne daemoni kaudu, v\u00f5tab k\u00f5ige vanema faili ja salvestab selle ClickHouse'i. Kui logisid salvestada korra sekundis, siis on k\u00f5ik suurep\u00e4rane. <\/p>\n

<\/p>\n

Kuid selle meetodi puudus on see, et kui teie server, kus logid genereeritakse, kuhugi kaob, kaovad ka andmed.<\/p>\n

<\/p>\n

\"ClickHouse'i<\/p>\n

<\/p>\n

Meetod 3. On veel \u00fcks huvitav viis, mis ei kasuta ajutisi faile. N\u00e4iteks v\u00f5ib teil olla m\u00f5ni reklaamip\u00f6\u00f6re v\u00f5i muu huvitav daemon, mis genereerib andmeid. Saate andmepaketi koguda otse m\u00e4lus, puhvrisse. Ja kui aega on m\u00f6\u00f6dunud piisavalt, asetate selle puhvri k\u00f5rvale, loote uue ning eraldi tahkudes sisestate juba kogunenud andmed ClickHouse'i.<\/p>\n

<\/p>\n

Teisest k\u00fcljest kaovad andmed kill -9 korral. Kui teie server crashes, kaotate need andmed. Ja veel on probleemiks see, et kui te ei saanud andmeid andmebaasi salvestada, hakkavad need andmed kuhjuma m\u00e4llu. Kasmalt kaotate m\u00e4lu v\u00f5i kaotate lihtsalt andmed. <\/p>\n

<\/p>\n

\"ClickHouse'i<\/p>\n

<\/p>\n

Meetod 4. Veel \u00fcks huvitav viis. Kui teil on m\u00f5ni serveriprotsess. Ja ta v\u00f5ib andmeid saata ClickHouse'i kohe, aga seda \u00fches \u00fchenduses. N\u00e4iteks, saadetakse http-p\u00e4ring koos transfer-encoding: chunked ja insert\u2019iga. Ja genereeritakse t\u00fckkide kaupa mitte liiga harva, v\u00f5ib igat rida saata, kuigi andmete framing'i t\u00f5ttu tekib \u00fclekandekiirus. <\/p>\n

<\/p>\n

Kuid sel juhul saadetakse andmed siiski kohe ClickHouse'i. Ja ClickHouse bufrib neid ise. <\/p>\n

<\/p>\n

Aga tekkivad probleemid. N\u00fc\u00fcd kaotate andmed, sealhulgas siis, kui teie protsess katkestatakse ja kui ClickHouse'i protsess katkestatakse, kuna see j\u00e4\u00e4b l\u00f5petamata insert'i taha. ClickHouse'i insert'id on aatomilised teatud ridade piiri ulatuses. \u00dcldiselt on see huvitav meetod. Seda v\u00f5ib kasutada ka.<\/p>\n

<\/p>\n

\"ClickHouse'i<\/p>\n

<\/p>\n

Meetod 5. Siin on veel \u00fcks huvitav meetod. See on mingisugune kogukonna v\u00e4lja t\u00f6\u00f6tatud server andmete grupiseerimiseks. Ma ei ole seda ise vaatamas k\u00e4inud, seega ei saa ma midagi garanteerida. Siiski ei anta ka ClickHouse'i enda puhul mingeid garantiisid. See on samuti avatud l\u00e4htekoodiga, kuid teisest k\u00fcljest v\u00f5ite olla harjunud teatud kvaliteedistandardiga, mida me p\u00fc\u00fcame tagada. Ent selle asja kohta \u2013 ma ei tea, minge GitHub'i, vaadake koodi. V\u00f5ib-olla on seal midagi normaalset kirjutatud. <\/p>\n

<\/p>\n

* seisuga 2020. aasta, tuleks lisada ka kaalu alla KittenHouse<\/a><\/noindex>.<\/p>\n

<\/p>\n

\"ClickHouse'i<\/p>\n

<\/p>\n

Meetod 6. Veel \u00fcks meetod on Buffer tabelite kasutamine. Selle meetodi eeliseks on see, et selle kasutamine on v\u00e4ga lihtne. Loote Buffer tabeli ja lisate sinna. <\/p>\n

<\/p>\n

Kuid puuduseks on see, et probleem ei lahene t\u00e4ielikult. Kui MergeTree t\u00fc\u00fcpi lisamiste korral peate andmeid grupeerima \u00fche partii kaupa sekundis, siis Buffer tabelisse lisamisel peate grupeerima v\u00e4hemalt mitu tuhat sekundis. Kui neid on rohkem kui 10 000 sekundis, on see ikka halb. Ja kui te lisate partiidena, siis n\u00e4gite, et seal v\u00f5ib olla sadu tuhandeid ridu sekundis. Ja see on juba \u00fcsna raskete andmete puhul. <\/p>\n

<\/p>\n

Samuti ei oma buffer tabelid logi. Ja kui teie serveriga on midagi valesti, siis andmed kaovad. <\/p>\n

<\/p>\n

\"ClickHouse'i<\/p>\n

<\/p>\n

Boonusena on ClickHouse'il hiljuti v\u00f5imalus andmeid Kafka'st kinni p\u00fc\u00fcda. On olemas tabeli mootori nimi - Kafka. Loote selle lihtsalt. Ja sellele saab kinnitada materialiseeritud vaateid. Sel juhul toob see automaatselt andmed Kafka'st ja lisab need soovitud tabelitesse. <\/p>\n

<\/p>\n

Ja see, mis selle v\u00f5imaluse juures eriti r\u00f5\u00f5mustab, on see, et seda ei teinud meie. See on kogukonna funktsioon. Ja kui ma r\u00e4\u00e4gin 'kogukonna funktsioonist', siis ei r\u00e4\u00e4gi ma seda mingisuguse p\u00f5lgusega. Me lugesime koodi, tegime \u00fclevaate, see peaks normaalselt t\u00f6\u00f6tama. <\/p>\n

<\/p>\n

* seisuga 2020. aasta, on saadaval sarnane tugi RabbitMQ<\/a><\/noindex>.<\/p>\n

<\/p>\n

\"ClickHouse'i<\/p>\n

<\/p>\n

Mis veel v\u00f5ib olla ebamugav v\u00f5i ootamatu andmete sisestamisel? Kui teete sisestamise p\u00e4ringu ja values'is kirjutate mingi arvutuslikke v\u00e4ljendeid. N\u00e4iteks, now() \u2013 see on samuti arvutuslik v\u00e4ljend. Sel juhul peab ClickHouse iga rea jaoks k\u00e4ivitama nende v\u00e4ljendite t\u00f5lgendaja, ja j\u00f5udlus langeb oluliselt. Paremini on seda v\u00e4ltida.<\/p>\n

<\/p>\n

* hetkel on probleem t\u00e4ielikult lahendatud, j\u00f5udluselangust v\u00e4ljendite kasutamisel VALUES'is enam ei esine.<\/p>\n

<\/p>\n

Teine olukord, kus v\u00f5ivad tekkida probleemid, on see, kui teil on \u00fches partiiandmestikus palju partiisid. ClickHouse'is on partiiandmestik vaikimisi kuude kaupa. Ja kui sisestate partii miljonist reast, kus andmed on mitme aasta kohta, on teil seal mitu k\u00fcmmet partiid. See on ekvivalentne sellega, et partii on mitu korda v\u00e4iksem, sest need jagunevad alati k\u00f5igepealt partiiandmestike kaupa.<\/p>\n

<\/p>\n

* Hiljuti on ClickHouse'is katsere\u017eiimis lisatud toetus kompaktsel formaadil osadele ja osadele m\u00e4lus koos write-ahead log'iga, mis peaaegu t\u00e4ielikult lahendab probleemi.<\/p>\n

<\/p>\n

\"ClickHouse'i<\/p>\n

<\/p>\n

N\u00fc\u00fcd vaatame teist t\u00fc\u00fcpi probleemi \u2013 andmete t\u00fc\u00fcpimist. <\/p>\n

<\/p>\n

Andmete t\u00fc\u00fcpimine v\u00f5ib olla range v\u00f5i stringiline. Stringiline on siis, kui olete lihtsalt \u00f6elnud, et k\u00f5ik teie v\u00e4ljad on t\u00fc\u00fcpi string. See on halb. Nii ei tohiks teha. <\/p>\n

<\/p>\n

Vaatame, kuidas \u00f5igesti teha olukordades, kus soovite \u00f6elda, et m\u00f5ni v\u00e4li on meil string ja las ClickHouse ise sellega tegeleb, aga siiski on m\u00f5istlik katta m\u00f5ned vaeva. <\/p>\n

<\/p>\n

\"ClickHouse'i<\/p>\n

<\/p>\n

N\u00e4iteks meil on IP-aadress. \u00dches n\u00e4ites oleme selle salvestanud stringina. N\u00e4iteks 192.168.1.1. Teises n\u00e4ites on see number t\u00fc\u00fcpi UInt32*. 32 bitti on piisavalt IPv4 aadressi jaoks.<\/p>\n

<\/p>\n

Esiteks, kuigi see v\u00f5ib tunduda kummaline, surutakse andmed kokku ligikaudu \u00fchtemoodi. Seal on vahe, muidugi, aga mitte nii suur. Nii et ketta sisendi- ja v\u00e4ljundi osas erilisi probleeme pole. <\/p>\n

<\/p>\n

Aga on m\u00e4rkimisv\u00e4\u00e4rne vahe protsessori ajal ja p\u00e4ringu t\u00e4itmise ajas. <\/p>\n

<\/p>\n

Arvutame ainulaadsete IP-aadresside arvu, kui need on salvestatud numbritena. Tulemuseks on 137 miljonit rida sekundis. Kui sama stringide kujul, siis 37 miljonit rida sekundis. Ma ei tea, miks selline kokkusattumine juhtus. Mina ise tegin need p\u00e4ringud. Kuid siiski on see umbes 4 korda aeglasem. <\/p>\n

<\/p>\n

Ja kui arvestada vahet diskil, siis vahe on ka olemas. Ja vahe on umbes veerandi ulatuses, sest ainulaadseid IP-aadresse on piisavalt palju. Kui siin oleks read v\u00e4ikese arvu erinevate v\u00e4\u00e4rtustega, siis need suruksid ennast s\u00f5nastiku j\u00e4rgi t\u00f5en\u00e4oliselt umbes \u00fchesugusesse mahtu. <\/p>\n

<\/p>\n

Ja neljakordne ajavahe teel ei ole mitte midagi. V\u00f5ib-olla sind ei huvita, aga kui ma n\u00e4en sellist vahet, tunnen ma end kurvalt.<\/p>\n

<\/p>\n

\"ClickHouse'i<\/p>\n

<\/p>\n

Vaatame erinevaid juhtumeid. <\/p>\n

<\/p>\n

1. \u00dcks juhtum, kui sul on erinevaid unikaalseid v\u00e4\u00e4rtusi v\u00e4he. Sel juhul kasutame lihtsat praktikat, mida sa t\u00f5en\u00e4oliselt tead ja saad kasutada mis tahes andmebaaside halduss\u00fcsteemide puhul. See kehtib mitte ainult ClickHouse'i jaoks. Salvestage lihtsalt numbrilisi identifikaatoreid. Ja teisendada stringideks ja tagasi saab juba oma rakenduse poolel. <\/p>\n

<\/p>\n

N\u00e4iteks, kui sul on piirkond. Ja sa p\u00fc\u00fcad seda salvestada stringina. Seal kirjutatakse: Moskva ja MO. Kui ma n\u00e4en, et seal on kirjas 'Moskva', siis pole hullu, kuid kui lisada ka MO, l\u00e4heb k\u00f5ik veel nukramaks. Kui palju see on baite. <\/p>\n

<\/p>\n

Kuna me salvestame lihtsalt arvu Ulnt32 ja 250. Meil on 250 Yandexis, aga sul v\u00f5ib olla teisiti. Igaks juhuks \u00fctlen, et ClickHouse'il on sisseehitatud funktsioon geobaasiga t\u00f6\u00f6tamiseks. Sa lihtsalt salvestad piirkondade loendi, sealhulgas ka hierarhilise, st seal on nii Moskva kui MO, ja k\u00f5ik, mis sul vaja on. Ja seda saab teisendada p\u00e4ringu tasemel. <\/p>\n

<\/p>\n

\"ClickHouse'i<\/p>\n

<\/p>\n

Teine variant on umbes sama, kuid toega ClickHouse'is. See on Enum andmet\u00fc\u00fcp. Sa lihtsalt m\u00e4\u00e4ratled Enum'is k\u00f5ik vajalikud v\u00e4\u00e4rtused. N\u00e4iteks seadme t\u00fc\u00fcp, kuhu kirjutad: lauaarvuti, nutitelefon, tahvelarvuti, televiisor. Kokku 4 varianti. <\/p>\n

<\/p>\n

Puuduseks on see, et tuleb perioodiliselt teha muutmine. Lisati vaid \u00fcks variant. Teeme alter table. Tegelikult on alter table ClickHouse'is tasuta. Eriti tasuta Enum'i puhul, sest andmed kettal ei muutu. Siiski, alter v\u00f5tab tabeli peale lukustuse* ja peab ootama, kuni k\u00f5ik select'id on l\u00f5pule viidud. Ja alles siis t\u00e4idetakse alter, s.t. siiski on m\u00f5ned ebamugavused.<\/p>\n

<\/p>\n

* Uuemates ClickHouse'i versioonides on ALTER tehtud t\u00e4iesti mitteblokkeerivaks.<\/p>\n

<\/p>\n

\"ClickHouse'i<\/p>\n

<\/p>\n

Veel \u00fcks variant, mis on ClickHouse'i jaoks piisavalt ainulaadne, on v\u00e4liste s\u00f5nastike \u00fchendamine. Sa v\u00f5id kirjutada ClickHouse'i numbreid ja hoida oma s\u00f5nastikke igas mugavas s\u00fcsteemis. N\u00e4iteks v\u00f5ib kasutada: MySQL, Mongo, Postgres. V\u00f5id isegi luua oma mikroteenuse, mis edastab neid andmeid http kaudu. Ja ClickHouse'i tasemel kirjutad funktsiooni, mis muudab need andmed numbreid ridadeks. <\/p>\n

<\/p>\n

See on spetsialiseeritud, kuid v\u00e4ga t\u00f5hus viis liita andmeid v\u00e4lise tabeliga. On kaks varianti. \u00dches variandis on need andmed t\u00e4ielikult vahem\u00e4lustatud, t\u00e4iesti olemas m\u00e4lus ja uuendatakse teatud perioodilisusega. Teises variandis, kui andmed ei mahu m\u00e4llu, saab neid osaliselt vahem\u00e4lustada. <\/p>\n

<\/p>\n

Siin on n\u00e4ide. On Yandex.Direct. Seal on reklaamikampaania ja b\u00e4nnerid. Reklaamikampaaniaid on t\u00f5en\u00e4oliselt k\u00fcmneid miljoneid. Need mahuvad enamasti m\u00e4llu. Aga b\u00e4nnerid \u2013 miljardeid, need ei mahu. Ja me kasutame vahem\u00e4lustatavat s\u00f5nastikku MySQL-st.<\/p>\n

<\/p>\n

Ainus probleem on see, et vahem\u00e4lustatav s\u00f5nastik t\u00f6\u00f6tab korralikult ainult siis, kui hit rate on l\u00e4hedane 100%-le. Kui see on madalam, siis iga andmepaki t\u00f6\u00f6tlemisel tuleb tegelikult v\u00f5tta puuduvaid v\u00f5tmeid ja minna andmeid MySQL-st hankima. ClickHouse'i kohta v\u00f5in veel kinnitada, et \u2013 jah, see ei pidurda, teiste s\u00fcsteemide kohta ei hakka ma r\u00e4\u00e4kima.<\/p>\n

<\/p>\n

Ja boonusena on see, et s\u00f5nastikud on v\u00e4ga lihtne viis andmete ajakohastamiseks ClickHouse'is tagantj\u00e4rele. See t\u00e4hendab, et kui teil oli reklaamikampaania aruanne, vahetab kasutaja lihtsalt reklaamikampaaniat ja k\u00f5ikides vanades andmetes, k\u00f5igis aruannetes muutuvad need andmed samuti. Kui kirjutada read otse tabelisse, siis nende uuendamine ei ole v\u00f5imalik. <\/p>\n

<\/p>\n

\"ClickHouse'i<\/p>\n

<\/p>\n

Teine v\u00f5imalus, kui te ei tea, kust leida oma ridade identifikaatoreid, on lihtsalt need hashida. Ja k\u00f5ige lihtsam variant on v\u00f5tta 64-bitine hash. <\/p>\n

<\/p>\n

Ainus probleem on see, et kui hash on 64-bitine, siis kollisiidid on praktiliselt garanteeritud. Sest kui seal on miljard rida, siis t\u00f5en\u00e4osus muutub juba oluliseks. <\/p>\n

<\/p>\n

Ja ei oleks v\u00e4ga hea hashida reklaamikampaaniate nimesid nii. Kui reklaamikampaaniad erinevate ettev\u00f5tete vahel segamini l\u00e4hevad, siis tekib mingi arusaamatus. <\/p>\n

<\/p>\n

Ja on \u00fcks lihtne nipp. T\u00f5si, see ei sobi t\u00f5siste andmete jaoks, kuid kui tegemist ei ole millegi t\u00f5sisega, siis lisage lihtsalt s\u00f5nastiku v\u00f5tmesse veel kliendi identifikaator. Siis esinevad konfliktid, kuid ainult \u00fche kliendi piires. Sellist meetodit kasutame me Yandex.Metrica lingikaardi puhul. Meil on seal URL-id, salvestame hash'e. Ja me teame, et konfliktid esinevad, kuid kui lehek\u00fclg kuvatakse, siis on t\u00f5en\u00e4osus, et just \u00fchel lehek\u00fcljel on \u00fchel kasutajal mingid URL-id kokku j\u00e4\u00e4nud ja seda m\u00e4rgatakse, nii et seda v\u00f5ib ignoreerida. <\/p>\n

<\/p>\n

Boonusena \u2013 paljude operatsioonide jaoks piisab ainult hash'idest, ja ise stringe ei pea kuskil hoidma. <\/p>\n

<\/p>\n

\"ClickHouse'i<\/p>\n

<\/p>\n

Teine n\u00e4ide, kui stringid on l\u00fchikesed, n\u00e4iteks domeenid. Need v\u00f5ib salvestada sellisena, nagu need on. V\u00f5i n\u00e4iteks brauseri keel ru \u2013 2 baiti. Muidugi on mul kahju pisikestest baitidest, aga \u00e4rge muretsege, 2 baiti ei ole kahju. Palun salvestage, nagu on, \u00e4rge muretsege. <\/p>\n

<\/p>\n

\"ClickHouse'i<\/p>\n

<\/p>\n

Teine olukord on see, kui ridasid on palju ja need on \u00fchtlasi v\u00e4ga unikaalsed ning palju potentsiaalselt piiramatuid. T\u00fc\u00fcpiline n\u00e4ide on otsingufraasid v\u00f5i URL-id. Otsingufraasid, sealhulgas tippimisvead. Vaatame, kui palju unikaalseid otsingufraase p\u00e4evas. Ja selgub, et need moodustavad peaaegu poole k\u00f5igist s\u00fcndmustest. Sel juhul v\u00f5ite m\u00f5elda, et andmeid tuleb normaliseerida, tuvastada identifikaatorid ja koguda eraldi tabelisse. Aga nii teha ei tohiks. Lihtsalt hoidke neid ridu sellisena, nagu nad on. <\/p>\n

<\/p>\n

Parem on mitte midagi v\u00e4lja m\u00f5elda, sest kui hoida eraldi, tuleb teha join. Ja see join on parimal juhul juhuslik juurdep\u00e4\u00e4s m\u00e4lule, kui see veel m\u00e4llu mahtuda suudab. Kui ei mahu, siis tekivad \u00fcldse probleemid. <\/p>\n

<\/p>\n

Aga kui andmed on in place, lugetakse need lihtsalt \u00f5igesse j\u00e4rjekorda failis\u00fcsteemist ja k\u00f5ik on korras.<\/p>\n

<\/p>\n

\"ClickHouse'i<\/p>\n

<\/p>\n

Kui teil on URL-id v\u00f5i mingi muu keeruline pikk rida, siis tasub m\u00f5elda, et v\u00f5iks mingisuguse kokkuv\u00f5tte eelnevalt arvutada ja salvestada eraldi veergu. <\/p>\n

<\/p>\n

N\u00e4iteks URL-de puhul saab eraldi hoida domeeni. Ja kui teil on tegelikult domeen vajalik, siis kasutage lihtsalt seda veergu, ja URL-id l\u00e4hevad olema, ning te ei pea neile isegi puudutama. <\/p>\n

<\/p>\n

Vaatame, milline on erinevus. ClickHouse'is on spetsialiseeritud funktsioon, mis arvutab domeeni. See on v\u00e4ga kiire; me optimeerisime selle. Ja ausalt \u00f6eldes ei vasta see isegi RFC-le, aga see arvestab ikkagi k\u00f5ike, mis meil vajalik on. <\/p>\n

<\/p>\n

\u00dches juhul saame me lihtsalt URL-e v\u00e4lja t\u00f5mmata ja domeeni arvutada. See v\u00f5tab 166 millisekundit. Kui v\u00f5tta aga valmis domeen, siis kulub vaid 67 millisekundit, see t\u00e4hendab peaaegu kolm korda kiiremini. Kiirus ei tulene mitte vajadusest teha mingeid arvutusi, vaid sellest, et me loeme v\u00e4hem andmeid. <\/p>\n

<\/p>\n

Kuid mingil p\u00f5hjusel on \u00fchel p\u00e4ringul, mis on aeglasem, suurem gigabaitide kiirus. Sest see loeb rohkem gigabaite. Need on t\u00e4iesti \u00fcleliigsed andmed. P\u00e4ring t\u00f6\u00f6tab nagu kiiremini, kuid t\u00e4idab \u00fclesannet kauem.<\/p>\n

<\/p>\n

Ja kui vaadata andmete mahtu kettal, siis selgub, et URL on 126 megabaiti, aga domeen vaid 5 megabaiti. See on 25 korda v\u00e4hem. Siiski toimub p\u00e4ringu t\u00e4itmine vaid 4 korda kiiremini. See on sellep\u00e4rast, et andmed on kuumad. Kui aga need oleks k\u00fclmad, oleks kahtlemata kiirus 25 korda suurem diskikande t\u00f5ttu. <\/p>\n

<\/p>\n

Tegelikult, kui hinnata, kui palju domeen on v\u00e4iksem kui URL, siis see on umbes 4 korda. Kuid kummalisel kombel v\u00f5tab andmete maht kettal 25 korda v\u00e4hem. Miks? Selle p\u00f5hjuseks on tihendamine. Nii URL kui domeen tihendatakse. Kuid sageli sisaldab URL palju pr\u00fcgi. <\/p>\n

<\/p>\n

\"ClickHouse'i<\/p>\n

<\/p>\n

Ja muidugi, tuleks kasutada \u00f5igeid andmet\u00fc\u00fcpe, mis on spetsiaalselt m\u00f5eldud vajalike v\u00e4\u00e4rtuste jaoks v\u00f5i mis sobivad. Kui olete IPv4, hoidke UInt32*. Kui IPv6, siis FixedString(16), sest IPv6 aadress on 128 bit, st hoidke see otse binaarformaadis. <\/p>\n

<\/p>\n

Ent mida teha, kui teil on vahel IPv4 aadresse ja vahel IPv6? Jah, saate hoida m\u00f5lemat. \u00dcks veerg IPv4 jaoks, teine IPv6 jaoks. Loomulikult on v\u00f5imalus kuvada IPv4 IPv6-s. See t\u00f6\u00f6tab ka, kuid kui teil on p\u00e4ringutes sageli vajalik just IPv4 aadress, siis oleks parem see panna eraldi veergu. <\/p>\n

<\/p>\n

* n\u00fc\u00fcd on ClickHouse'is eraldi andmet\u00fc\u00fcbid IPv4 ja IPv6, mis salvestavad andmeid sama t\u00f5husalt nagu numbrid, kuid esitavad neid sama mugavalt nagu stringid.<\/p>\n

<\/p>\n

\"ClickHouse'i<\/p>\n

<\/p>\n

Samuti on oluline m\u00e4rkida, et andmed tuleks eelnevalt t\u00f6\u00f6delda. N\u00e4iteks kui teile saabuvad m\u00f5ned toored logid. Ja v\u00f5ib-olla ei tasu neid kohe ClickHouse'i toppida, kuigi on v\u00e4ga ahvatlev mitte midagi teha ja k\u00f5ik t\u00f6\u00f6tab. Kuid siiski tasub teha need arvutused, mis on v\u00f5imalik.<\/p>\n

<\/p>\n

N\u00e4iteks brauseri versioon. \u00dches naaberosakonnas, kuhu ma ei taha n\u00e4puga n\u00e4idata, hoitakse brauseri versiooni nii, st stringina: 12.3. Ja siis, et aruannet teha, v\u00f5tavad nad selle stringi ja jagavad selle massiiviga, ja siis esimese elemendiga massiivist. Loomulikult, k\u00f5ik hakkab aeglaselt liikuma. K\u00fcsisin, miks nad nii teevad. Nad vastasid, et ei armasta enneaegset optimeerimist. Aga mina ei armasta enneaegset pessimistlikku l\u00e4henemist.<\/p>\n

<\/p>\n

Nii et sel juhul oleks \u00f5igem jagada 4 veerguks. Siin \u00e4rge kartke, sest see on ClickHouse. ClickHouse on veergude andmebaas. Ja mida rohkem korralikke v\u00e4ikeseid veerge, seda parem. Kui on 5 BrowserVersion'i, tehke 5 veergu. See on normaalne. <\/p>\n

<\/p>\n

\"ClickHouse'i<\/p>\n

<\/p>\n

N\u00fc\u00fcd vaatame, mida teha, kui teil on palju v\u00e4ga pikki ridu v\u00f5i v\u00e4ga pikki massiive. Neid ei pea ClickHouse'is \u00fcldse hoidma. Selle asemel saate ClickHouse'i salvestada ainult mingi identifikaatori. Need pikad read tasub panna m\u00f5nesse teise s\u00fcsteemi. <\/p>\n

<\/p>\n

N\u00e4iteks \u00fches meie anal\u00fc\u00fctikateenustes on m\u00f5ned s\u00fcndmuste parameetrid. Ja kui s\u00fcndmustele tuleb palju parameetreid, salvestame lihtsalt esimesed 512. Sest 512 ei ole kahju. <\/p>\n

<\/p>\n

\"ClickHouse'i<\/p>\n

<\/p>\n

Ja kui te ei suuda oma andmet\u00fc\u00fcpe m\u00e4\u00e4rata, saate ka andmed ClickHouse'i kirjutada, kuid ajutisse Log-t\u00fc\u00fcpi tabelisse, mis on spetsiaalne ajutiste andmete jaoks. P\u00e4rast seda saate anal\u00fc\u00fcsida, milline on teie v\u00e4\u00e4rtuste jaotus, mis seal \u00fcldse olemas on, ja koostada \u00f5iged t\u00fc\u00fcbid.<\/p>\n

<\/p>\n

* praegu on ClickHouse'is andmet\u00fc\u00fcp LowCardinality<\/a><\/noindex> mis v\u00f5imaldab efektiivselt salvestada ridu v\u00e4iksema t\u00f6\u00f6mahu jaotusega.<\/p>\n

<\/p>\n

\"ClickHouse'i<\/p>\n

<\/p>\n

N\u00fc\u00fcd vaatame veel \u00fchte huvitavat juhtumit. M\u00f5nikord t\u00f6\u00f6tab inimestel k\u00f5ik kuidagi veidralt. Sisenen ja n\u00e4en sellist. Ja kohe on selge, et seda on teinud mingi v\u00e4ga kogenud, nutikas administraator, kellel on suur kogemus MySQL versiooni 3.23 seadistamisel. <\/p>\n

<\/p>\n

Siin n\u00e4eme tuhandet tabelit, milles igas on kirjas j\u00e4\u00e4k, mis tuleneb arusaamatust jagamisest tuhandega. <\/p>\n

<\/p>\n

\u00dches\u00f5naga, ma austan teiste kogemusi, sealhulgas m\u00f5istan, kui suure vaevaga see kogemus on saadud. <\/p>\n

<\/p>\n

\"ClickHouse'i<\/p>\n

<\/p>\n

Ja p\u00f5hjused on enam-v\u00e4hem arusaadavad. Need on vanad stereot\u00fc\u00fcbid, mis on v\u00f5inud tekkida t\u00f6\u00f6tades teiste s\u00fcsteemidega. N\u00e4iteks MyISAM tabelites ei ole klasterp\u00e4randv\u00f5tit. Ja selline andmete jagamise viis v\u00f5ib olla meeleheitlik katse saavutada sama funktsionaalsus. <\/p>\n

<\/p>\n

Teine p\u00f5hjus on see, et erinevad operatsioonid, nagu alter, suurte tabelite puhul on keerulised. K\u00f5ik j\u00e4\u00e4b lukku. Kuigi t\u00e4nap\u00e4evaste MySQL versioonide puhul ei ole see probleem enam nii t\u00f5sine. <\/p>\n

<\/p>\n

V\u00f5i n\u00e4iteks mikroshardimine, aga sellest r\u00e4\u00e4gime natuke hiljem.<\/p>\n

<\/p>\n

\"ClickHouse'i<\/p>\n

<\/p>\n

ClickHouse'i puhul ei ole seda vaja teha, kuna esiteks on klasterp\u00e4randv\u00f5ti, andmed on j\u00e4rjestatud klasterp\u00e4randv\u00f5tme j\u00e4rgi. <\/p>\n

<\/p>\n

Ja m\u00f5nikord k\u00fcsitakse minult: \u201eKuidas muutub ClickHouse'i j\u00e4lgimisp\u00e4ringute j\u00f5udlus tabeli suurusest?\u201c. Ma \u00fctlen, et see ei muutu kuidagi. N\u00e4iteks, kui teil on tabel, kus on miljard rida, ja loete satuvust miljon rida. K\u00f5ik on korras. Kui tabelis on triljon rida ja loete miljon rida, siis on see peaaegu sama. <\/p>\n

<\/p>\n

Ja teiseks, igasuguseid asju nagu k\u00e4sitsi partitsioonide seadmine ei ole vajalik. Kui te l\u00e4hete ja vaatate, mis seal failis\u00fcsteemis on, n\u00e4ete, et tabel on p\u00e4ris t\u00f5sine asi. Seal sees on midagi nagu partitsioonid. Ehk siis ClickHouse teeb k\u00f5ik teie eest \u00e4ra ja te ei pea muretsema.<\/p>\n

<\/p>\n

\"ClickHouse'i<\/p>\n

<\/p>\n

Alter ClickHouse'is on tasuta, kui lisate\/eemaldate veeru. <\/p>\n

<\/p>\n

Ja v\u00e4ikeste tabelite loomine ei ole m\u00f5ttekas, sest kui teie tabelis on 10 rida v\u00f5i 10 000 rida, ei oma see mingit t\u00e4htsust. ClickHouse on s\u00fcsteem, mis optimeerib l\u00e4bilaskev\u00f5imet, mitte latentsust, nii et 10 rida t\u00f6\u00f6tlemine ei ole m\u00f5istlik. <\/p>\n

<\/p>\n

\"ClickHouse'i<\/p>\n

<\/p>\n

\u00d5ige on kasutada \u00fchte suurt tabelit. Vabanege vanadest stereot\u00fc\u00fcpidest, k\u00f5ik l\u00e4heb h\u00e4sti. <\/p>\n

<\/p>\n

Ja boonuseks on meie uusimas versioonis v\u00f5imalus luua arbitraarseid partitsioneerimise v\u00f5tmeid, et teostada erinevaid hooldusoperatsioone \u00fcksikute partitsioonide \u00fcle. <\/p>\n

<\/p>\n

N\u00e4iteks, kui teil on palju v\u00e4ikseid tabeleid, n\u00e4iteks kui on vaja t\u00f6\u00f6delda vaheandmeid, kus te saate kokkusurutud andmestikke ja peate enne nende salvestamist l\u00f5pptabelisse teostama teisendusi. Selle jaoks on olemas suurep\u00e4rane tabelimootor \u2013 StripeLog. See on umbes nagu TinyLog, aga parem. <\/p>\n

<\/p>\n

* n\u00fc\u00fcd on ClickHouse'is olemas veel ka tabelifunktsioon input<\/a><\/noindex>.<\/p>\n

<\/p>\n

\"ClickHouse'i<\/p>\n

<\/p>\n

Veel \u00fcks antipattern on mikrot\u00fckeldamine. N\u00e4iteks, kui peate oma andmed jagama ja teil on 5 serverit, kuid homme tuleb 6 serverit. Ja te m\u00f5tlete, kuidas neid andmeid \u00fcmber jagada. Selle asemel, et jagada 5 shards'i peale, jagate te need 1 000 shards'i peale. Ja siis suunate iga\u00fche neist mikrot\u00fckeldustest eraldi serverisse. N\u00e4iteks v\u00f5ib \u00fches serveris olla 200 ClickHouse'i. Erinevad instantsid erinevatel portidel v\u00f5i eraldi andmebaasid. <\/p>\n

<\/p>\n

\"ClickHouse'i<\/p>\n

<\/p>\n

Kuid ClickHouse'is ei ole see eriti hea. Sest isegi \u00fcks ClickHouse'i instants p\u00fc\u00fcab kasutada k\u00f5iki serveri ressursse \u00fche p\u00e4ringu t\u00f6\u00f6tlemiseks. St, kui teil on n\u00e4iteks server, kus on 56 protsessorituuma. Teete p\u00e4ringu, mis kestab \u00fche sekundi, ja see kasutab 56 tuuma. Ja kui olete sinna paigutanud 200 ClickHouse'i \u00fchte serverisse, siis k\u00e4ivitatakse kokku 10 000 l\u00f5ime. \u00dches\u00f5naga, k\u00f5ik l\u00e4heb t\u00f5eliselt halvasti.<\/p>\n

<\/p>\n

Teine p\u00f5hjus on see, et t\u00f6\u00f6jaotamine nende instantside vahel ei ole \u00fchtlane. M\u00f5ni l\u00f5petab varem, m\u00f5ni hiljem. Kui kogu see asi toimuks \u00fche instantsi sees, siis ClickHouse oskaks ise andmed \u00f5igesti l\u00f5imede vahel jaotada. <\/p>\n

<\/p>\n

Ja veel \u00fcks p\u00f5hjus on see, et teil on protsessoritevaheline suhtlus TCP kaudu. Andmed tuleb serialiseerida, deserialiseerida ja see on tohutu hulk mikro-sharde. See ei t\u00f6\u00f6ta lihtsalt t\u00f5husalt.<\/p>\n

<\/p>\n

\"ClickHouse'i<\/p>\n

<\/p>\n

Veel \u00fcks antim\u00e4\u00e4ratlemine, kuigi seda on raske antim\u00e4\u00e4ratlemiseks pidada. See on suur hulk eelaggregatsiooni.<\/p>\n

<\/p>\n

\u00dcldiselt on eelagregatsioon hea. Kui teil oli miljard rida ja te agreegasite selle ning n\u00fc\u00fcd on 1 000 rida, siis p\u00e4ring toimub kohe. K\u00f5ik on suurep\u00e4rane. Nii saab teha. Selle jaoks on ClickHouse'is isegi spetsiaalne tabelit\u00fc\u00fcp AggregatingMergeTree, mis teeb inkrementaalset aggregeerimist, kui andmeid sisestatakse. <\/p>\n

<\/p>\n

Aga on juhtumeid, kui arvate, et me peaksime andmeid selliselt kokku koondama ja veel teistmoodi kokku koondama. Ja mingis naaberosakonnas, millest ma ei soovi r\u00e4\u00e4kida, kasutatakse SummingMergeTree tabeleid summamiseks p\u00f5hiv\u00f5tme j\u00e4rgi, ja p\u00f5hiv\u00f5tmena kasutatakse umbes 20 erinevat veergu. Muutsin m\u00f5ningaid veergude nimesid konspiratsiooni huvides, aga umbes nii need asjad on.<\/p>\n

<\/p>\n

\"ClickHouse'i<\/p>\n

<\/p>\n

Ja tekivad sellised probleemid. Esiteks, andmete maht ei v\u00e4hene piisavalt. N\u00e4iteks v\u00e4heneb see kolm korda. Kolm korda oleks hea hind, et lubada endale piiramatu anal\u00fc\u00fcsi v\u00f5imalusi, mis tekivad, kui andmed ei ole agreggeeritud. Kui andmed on agreggeeritud, siis saate anal\u00fc\u00fcsi asemel vaid halva statistika. <\/p>\n

<\/p>\n

Ja ja, mis seal eriti h\u00e4irib? See, et need inimesed naaberosakonnast k\u00e4ivad ja paluvad aeg-ajalt lisada veel \u00fcks veerg algusv\u00f5tmesse. See t\u00e4hendab, et oleme andmeid selliselt kokku kogunud, aga n\u00fc\u00fcd tahame natuke rohkem. Kuid ClickHouse'is ei saa algusv\u00f5tit muuta. Seet\u00f5ttu peab kirjutama mingisuguseid skripte C++-s. Ja mulle ei meeldi skriptid, isegi kui need on C++-s.<\/p>\n

<\/p>\n

Ja kui vaadata, milleks ClickHouse loodi, siis mitteaggregeeritud andmed on just see stsenaarium, mille jaoks see on s\u00fcndinud. Kui kasutate ClickHouse'i mitteaggregeeritud andmete jaoks, siis teete k\u00f5ik \u00f5igesti. Kui aggregeerite, siis see on m\u00f5nikord andestatav. <\/p>\n

<\/p>\n

\"ClickHouse'i<\/p>\n

<\/p>\n

Veel \u00fcks huvitav juhtum on p\u00e4ringud l\u00f5putus ts\u00fcklis. Ma vahel l\u00e4hen m\u00f5nele tootmisserverile ja vaatan seal show processlist. Ja iga kord avastan, et toimub midagi kohutavat. <\/p>\n

<\/p>\n

N\u00e4iteks selline. Siit on kohe selge, et k\u00f5ik oleks saanud teha \u00fche p\u00e4ringuga. Lihtsalt kirjutage sinna url in ja nimekiri.<\/p>\n

<\/p>\n

\"ClickHouse'i<\/p>\n

<\/p>\n

Miks on nii palju selliseid p\u00e4ringute l\u00f5pmatuid ts\u00fckleid \u2013 see on halb? Kui indeksit ei kasutata, siis toimub sul palju l\u00e4bik\u00e4ike samade andmete kaudu. Kuid kui indeksit kasutatakse, n\u00e4iteks kui sul on p\u00f5hiv\u00f5ti ru ja sa kirjutad url = millelegi. Sa arvad, et loetakse tabelist \u00fcht kindlat URL-i, siis k\u00f5ik on korras. Aga tegelikult ei ole. Sest ClickHouse teeb k\u00f5ike pakendatult. <\/p>\n

<\/p>\n

Kui tal on vaja lugeda mingit andmevahemikku, loeb ta natuke rohkem, kuna clickHouse\u2019i indeks on harv. See indeks ei luba leida tabelist \u00fchte individuaalset rida, vaid ainult mingit vahemikku. Ja andmed tihendatakse plokkidena. \u00dche rea lugemiseks tuleb v\u00f5tta terve plokk ja see lahti suruda. Ja kui sa teed kuhjaga p\u00e4ringuid, siis sul on palju kattuvusi ja palju t\u00f6\u00f6d tuleb sul ikka ja j\u00e4lle teha.<\/p>\n

<\/p>\n

\"ClickHouse'i<\/p>\n

<\/p>\n

Ja boonuseks v\u00f5ib \u00f6elda, et ClickHouse'is ei ole vaja karta isegi megabaidide ja isegi sadade megabaidide edastamist IN-sektsiooni. M\u00e4letan meie praktikast, et kui MySQL-is edastame hulga v\u00e4\u00e4rtusi IN-sektsiooni, n\u00e4iteks edastame 100 megabaiti mingisuguseid numbreid, siis MySQL tarbib 10 gigabaiti m\u00e4lust ja rohkem ei juhtu midagi, k\u00f5ik t\u00f6\u00f6tab halvasti. <\/p>\n

<\/p>\n

Ja teine asi on see, et ClickHouse'is, kui teie p\u00e4ringud kasutavad indeksit, siis see ei ole kunagi aeglasem kui full scan, st kui tuleb lugeda peaaegu kogu tabelit, siis ta l\u00e4heb j\u00e4rjestikku ja loeb kogu tabelit. \u00dches\u00f5naga, ta saadab end ise asja korda.<\/p>\n

<\/p>\n

Kuid siiski on m\u00f5ned keerukused. N\u00e4iteks see, et IN koos alam p\u00e4ringuga ei kasuta indeksit. Kuid see on meie probleem ja me peame seda parandama. Siin ei ole midagi fundamentaalset. Parandame seda. <\/p>\n

<\/p>\n

Ja veel \u00fcks huvitav asi on see, et kui teil on v\u00e4ga pikk p\u00e4ring ja p\u00e4ringute jaotatud t\u00f6\u00f6tlemine k\u00e4ib, siis see v\u00e4ga pikk p\u00e4ring saadetakse igale serverile ilma kokkusurumiseta. N\u00e4iteks 100 megabaiti ja 500 serverit. Seega edastatakse teie v\u00f5rgus 50 gigabaiti. See saadetakse ja siis k\u00f5ik l\u00f5petatakse edukalt.<\/p>\n

<\/p>\n

* juba kasutab; k\u00f5ik on korras, nagu lubatud.<\/p>\n

<\/p>\n

\"ClickHouse'i<\/p>\n

<\/p>\n

Ja \u00fcsna sage juhtum, kui p\u00e4ringud tulevad API-st. N\u00e4iteks, kui olete loonud oma teenuse. Ja kui teie teenust keegi vajab, siis avate API ja juba kahe p\u00e4eva p\u00e4rast n\u00e4ete, et toimub midagi ebaselget. K\u00f5ik on \u00fcle koormatud ja tulevad mingid kohutavad p\u00e4ringud, mida ei oleks kunagi pidanud olema. <\/p>\n

<\/p>\n

Ja siin on lahendus. Kui olete API avanud, peate seda k\u00e4rpima. N\u00e4iteks, kehtestama mingid piirangud. Teisi normaalseid variante ei ole. Vastasel juhul kirjutatakse kohe skript ja tekivad probleemid. <\/p>\n

<\/p>\n

Ja ClickHouse'is on spetsiaalne funktsioon \u2013 kvootide arvestus. Samuti saate edastada oma kvoodi v\u00f5tme. See on n\u00e4iteks kasutaja sisemine identifikaator. Ja kvoote arvestatakse s\u00f5ltumatult iga\u00fche jaoks. <\/p>\n

<\/p>\n

\"ClickHouse'i<\/p>\n

<\/p>\n

N\u00fc\u00fcd veel \u00fcks huvitav asi. See on replikatsioon k\u00e4sitsi juhtimisega. <\/p>\n

<\/p>\n

Ma tean palju juhtumeid, kus, hoolimata sellest, et ClickHouse'il on sisseehitatud replikatsiooni tugi, replitseerivad inimesed ClickHouse'i k\u00e4sitsi.<\/p>\n

<\/p>\n

Milline on p\u00f5him\u00f5te? Teil on andmet\u00f6\u00f6tluse pipeline, mis t\u00f6\u00f6tab iseseisvalt, n\u00e4iteks erinevates andmekeskustes. Te kirjutate andmed ClickHouse'i samal viisil. T\u00f5si, praktika n\u00e4itab, et andmed l\u00e4hevad siiski lahku, kuna teie koodis on m\u00f5ningaid erip\u00e4rasid. Loodan, et see ei kehti teie kohta. <\/p>\n

<\/p>\n

Ja perioodiliselt peate ikkagi k\u00e4sitsi s\u00fcnkroonima. N\u00e4iteks kord kuus teevad adminnid rsync'i.<\/p>\n

<\/p>\n

T\u00f5epoolest, ClickHouse'is on palju lihtsam kasutada sisseehitatud replikatsiooni. Kuid siin v\u00f5ivad olla teatud vastun\u00e4idustused, kuna selleks tuleb kasutada ZooKeeper'i. Ma ei \u00fctle ZooKeeper'i kohta halba, sisuliselt on s\u00fcsteem t\u00f6\u00f6kindel, kuid m\u00f5nikord ei kasuta inimesed seda java-fobia t\u00f5ttu, kuna ClickHouse on nii suurep\u00e4rane s\u00fcsteem, mis on kirjutatud C++-s ja millega saab ikka ideaalselt t\u00f6\u00f6tada. Aga ZooKeeper on java peal. Ja seda ei tahaks isegi vaadata, kuid juhul kui, siis v\u00f5ite kasutada manuaalisel p\u00f5hinevat replikatsiooni. <\/p>\n

<\/p>\n

\"ClickHouse'i<\/p>\n

<\/p>\n

ClickHouse on praktiline s\u00fcsteem. See arvestab teie vajadusi. Kui teil on replikatsioon k\u00e4sitsi k\u00e4ivitatud, saate luua jaotatud tabeli, mis vaatab teie k\u00e4sitsi replikate poole ja teostab nende vahel automaatse \u00fclemineku. On isegi eriline valik, mis aitab v\u00e4ltida t\u00f5rkeid, isegi kui teie replikad pidevalt eralduvad.<\/p>\n

<\/p>\n

\"ClickHouse'i<\/p>\n

<\/p>\n

Edasi v\u00f5ivad tekkida probleemid, kui kasutate primitiivseid tabelimootoreid. ClickHouse on selline ehitaja, kus on palju erinevaid tabelimootoreid. K\u00f5igi t\u00f5siste juhtumite jaoks, nagu dokumentatsioonis on kirjutatud, kasutage MergeTree perekonna tabeleid. K\u00f5ik teised on lihtsalt erijuhtudeks v\u00f5i testimiseks.<\/p>\n

<\/p>\n

MergeTree tabelis ei ole tingimata vajalik, et teil oleks mingi kuup\u00e4ev ja kellaaeg. V\u00f5ite ikkagi kasutada. Kui kuup\u00e4eva ja kellaaega pole, kirjutage, et vaikev\u00e4\u00e4rtus on 2000. aasta. See t\u00f6\u00f6tab ja ei n\u00f5ua ressursse. <\/p>\n

<\/p>\n

Ja uues serveriversioonis on isegi v\u00f5imalik n\u00e4idata, et teil on kohandatud partitseerimine ilma partitsiooni v\u00f5tmeta. See on sama asi. <\/p>\n

<\/p>\n

\"ClickHouse'i<\/p>\n

<\/p>\n

Teisest k\u00fcljest on v\u00f5imalik kasutada primitiivseid tabelimootoreid. N\u00e4iteks laadige andmed \u00fcks kord, vaadake neid, keerake ringi ja eemaldage. Saate kasutada Log.<\/p>\n

<\/p>\n

V\u00f5i v\u00e4ikeste mahtude salvestamine vahepealseks t\u00f6\u00f6tlemiseks \u2014 see on StripeLog v\u00f5i TinyLog.<\/p>\n

<\/p>\n

Memory v\u00f5ib kasutada, kui andmemahu on v\u00e4ike ja lihtsalt keerata midagi m\u00e4letsejas. <\/p>\n

<\/p>\n

\"ClickHouse'i<\/p>\n

<\/p>\n

ClickHouse ei armasta v\u00e4ga \u00fcleliigselt normaliseeritud andmeid. <\/p>\n

<\/p>\n

Siin on t\u00fc\u00fcpiline n\u00e4ide. See on tohutu hulk URL-e. Te panite need naabertabelisse. Ja siis otsustasite nendega JOIN teha, kuid see ei t\u00f6\u00f6ta tavaliselt, kuna ClickHouse toetab ainult Hash JOIN-i. Kui m\u00e4lu ei piisa paljude andmete jaoks, millega tuleb \u00fchendada, ei saa JOIN-i teostada*. <\/p>\n

<\/p>\n

Kui andmed on suure kardinaalsusega, siis \u00e4rge muretsege, hoidke neid denormeeritud kujul, URL-id otse p\u00f5hitahel. <\/p>\n

<\/p>\n

* kuid n\u00fc\u00fcd on ClickHouse'il ka merge join ja see t\u00f6\u00f6tab tingimustes, kus vaheandmed ei mahuta m\u00e4llu. Kuid see ei ole efektiivne ja soovitus j\u00e4\u00e4b kehtima.<\/p>\n

<\/p>\n

\"ClickHouse'i<\/p>\n

<\/p>\n

Veel paar n\u00e4idet, kuid n\u00fc\u00fcd kahtlen, kas need on antipatternid v\u00f5i mitte. <\/p>\n

<\/p>\n

ClickHouse'il on \u00fcks tuntud puudus. See ei toeta uuendusi*. M\u00f5nes m\u00f5ttes on see isegi hea. Kui teil on olulised andmed, n\u00e4iteks raamatupidamine, siis ei saa keegi neid saata, kuna uuendusi ei ole.<\/p>\n

<\/p>\n

* uuenduse ja kustutamise tugi on juba ammu lisatud batch-re\u017eiimis.<\/p>\n

<\/p>\n

Kuid on m\u00f5ned erilised viisid, mis v\u00f5imaldavad uuendusi peaaegu 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 viib kogu partitsiooni \u00fcmberkirjutamiseni. <\/p>\n

<\/p>\n

Jaotatud JOIN'id ClickHouse'is \u2013 need on samuti halva p\u00e4ringuplaanijaga. <\/p>\n

<\/p>\n

Halb, aga m\u00f5nikord okei.<\/p>\n

<\/p>\n

ClickHouse'i kasutamine ainult selleks, et andmeid tagasi lugeda select* abil.<\/p>\n

<\/p>\n

Ma ei soovitaks ClickHouse'i kasutada mahukate arvutuste jaoks. Kuid see pole p\u00e4ris nii, kuna me juba eemaldume sellest soovitusest. Ja meil on hiljuti lisandunud v\u00f5imalus rakendada masin\u00f5ppemudeleid ClickHouse's \u2013 Catboost. Ja see teeb mind murelikuks, sest ma m\u00f5tlen: \u201eKui hirmus. Kui palju takte \u00fche byte'i kohta tuleb!\u201c. Mul on v\u00e4ga kahju, kui takte byte'ide peale kulutada. <\/p>\n

<\/p>\n

\"ClickHouse'i<\/p>\n

<\/p>\n

Aga \u00e4rge kartke, installige ClickHouse, k\u00f5ik l\u00e4heb h\u00e4sti. Kui midagi juhtub, on meil kogukond. \u00dctleme nii, et see olete teie. Ja kui teil on mingeid probleeme, saate v\u00e4hemalt meie vestlusesse astuda ja loodetavasti saavad nad teid aidata. <\/p>\n

<\/p>\n

K\u00fcsimused<\/p>\n

<\/p>\n

Ait\u00e4h ettekande eest! Kuhu saab ClickHouse'i t\u00f5rgete \u00fcle kaevata?<\/em><\/p>\n

<\/p>\n

V\u00f5ite p\u00f6\u00f6rduda minu poole isiklikult juba praegu. <\/p>\n

<\/p>\n

Ma hakkasin hiljuti ClickHouse'i kasutama. T\u00f5mbasin kohe cli liidese alla.<\/em><\/p>\n

<\/p>\n

Teil on vedanud. <\/p>\n

<\/p>\n

Hiljem t\u00f5mbasin serveri alla v\u00e4ikese selectiga.<\/em><\/p>\n

<\/p>\n

Teie talent on silmapaistev. <\/p>\n

<\/p>\n

Avasin GitHubis vea, kuid see j\u00e4eti t\u00e4helepanuta.<\/em> <\/p>\n

<\/p>\n

Vaatan, mis juhtub. <\/p>\n

<\/p>\n

Aleksandr t\u00f5mbas mind ettekandele, lubades r\u00e4\u00e4kida, kuidas te andmeid pressite.<\/em><\/p>\n

<\/p>\n

See on v\u00e4ga lihtne. <\/p>\n

<\/p>\n

Selle sain eile aru. Rohkem konkreetsust.<\/em> <\/p>\n

<\/p>\n

Seal pole mingeid hirmsaid nippe. Seal on lihtsalt plokkide p\u00f5hine kompressioon. Vaikimisi kasutatakse LZ4, kuid saate lubada ZSTD*. Plokid on suurusega 64 kilobaiti kuni 1 megabait.<\/p>\n

<\/p>\n

* on saadaval ka spetsialiseeritud kompressioonikoodikud, mida saab kasutada koos teiste algoritmidega.<\/p>\n

<\/p>\n

Kas plokkides on lihtsalt toored andmed?<\/em><\/p>\n

<\/p>\n

Ei ole p\u00e4ris toored. Seal on massiivid. Kui teil on numbriline veerg, siis on seal numbrid j\u00e4rjestikku massiivis paigutatud. <\/p>\n

<\/p>\n

Selge.<\/em> <\/p>\n

<\/p>\n

Aleksandr, n\u00e4ide, mis oli uniqExact'i puhul IP-aadressidega, st see, et uniqExact'i arvutamine stringide pealt v\u00f5tab kauem aega kui numbrite pealt ja nii edasi. Aga kui me kasutame nippe ja teisendame lugemise ajal? St te \u00fctlesite, et ketas ei erine meil palju. Kui me loeme kettalt stringe ja teisendame need, kas meie aggregeerimine siis kiireneb v\u00f5i mitte? V\u00f5i saame me ikkagi siin vaid v\u00e4he parema tulemuse? Mul on tunne, et te olete seda testinud, kuid mingil p\u00f5hjusel ei n\u00e4idanud seda tulemuste v\u00f5rdluses.<\/em> <\/p>\n

<\/p>\n

Ma arvan, et see on aeglasem kui ilma teisendamiseta. Sel juhul tuleb IP-aadress stringist v\u00e4lja lugeda. Meil on ClickHouse's IP-aadresside parsimine samuti optimeeritud. Me oleme selle nimel t\u00f5esti vaeva n\u00e4inud, kuid seal on ju numbrid salvestatud k\u00fcmnendikku vormi. See on t\u00f5eliselt ebamugav. Teisest k\u00fcljest t\u00f6\u00f6tab uniqExact stringide pealt aeglasemalt mitte ainult seet\u00f5ttu, et need on stringid, vaid ka seet\u00f5ttu, et valitakse teine algoritmi spetsialiseerumine. Stringe t\u00f6\u00f6deldakse lihtsalt teisiti.<\/p>\n

<\/p>\n

Aga kui v\u00f5tta m\u00f5ni primitiivsem andmet\u00fc\u00fcp? N\u00e4iteks oleme salvestanud kasutaja ID, mis meil on sisse, salvestanud selle stringina ja siis teisendame, kas oleks toredam v\u00f5i mitte?<\/em><\/p>\n

<\/p>\n

Ma kahtlen. Arvan, et see on isegi kurvem, sest numbrite parsimine on t\u00f5sine probleem. Tundub, et sellel kolleegil oli isegi ettekande teema, kuidas on keeruline numbreid k\u00fcmne tuhandes vormis parsida, v\u00f5i v\u00f5ib-olla ei olnud? <\/p>\n

<\/p>\n

Aleksei, suur ait\u00e4h ettekande eest! Ja samuti suur ait\u00e4h ClickHouse'i eest! Mul on k\u00fcsimus plaanide kohta. Kas plaanis on funktsiooni, mis v\u00f5imaldab s\u00f5nastike osalisi uuendusi?<\/em><\/p>\n

<\/p>\n

Ehk osaline taask\u00e4ivitamine?<\/p>\n

<\/p>\n

Jah-jah. T\u00f5en\u00e4oliselt v\u00f5imalus m\u00e4\u00e4rata seal MySQL v\u00e4li, st uuendada 'after', et laadida ainult need andmed, kui s\u00f5nastik on v\u00e4ga suur.<\/em><\/p>\n

<\/p>\n

V\u00e4ga huvitav funktsioon. Ja mulle tundub, et keegi inimene oli seda meie vestluses soovitanud. V\u00f5ib-olla olite see isegi teie. <\/p>\n

<\/p>\n

Ei arva, et mina.<\/em><\/p>\n

<\/p>\n

Suurep\u00e4rane, n\u00fc\u00fcd on kaks p\u00e4ringut. Ja n\u00fc\u00fcd saab rahulikult alustada. Kuid tahan teid kohe hoiatada, et see funktsioon on piisavalt lihtne rakendada. St idee on kirjutada lihtsalt tabelisse versiooninumber ja edasi kirjutada: versioon on v\u00e4iksem kui see ja see. Ja see t\u00e4hendab, et t\u00f5en\u00e4oliselt pakume seda huvilistele. Kas olete huviline? <\/p>\n

<\/p>\n

Jah, kuid kahjuks mitte C++-s.<\/em><\/p>\n

<\/p>\n

Kas teie kolleegid oskavad C++-s kirjutada? <\/p>\n

<\/p>\n

Leian kedagi.<\/em><\/p>\n

<\/p>\n

Suurep\u00e4rane.<\/p>\n

<\/p>\n

* v\u00f5imalus lisati kaks kuud p\u00e4rast ettekannet \u2013 selle arendas v\u00e4lja k\u00fcsimuse autor ja saatis selle edasi pull request<\/a><\/noindex>.<\/p>\n

<\/p>\n

Ait\u00e4h!<\/em><\/p>\n

<\/p>\n

Tere! Ait\u00e4h ettekande eest! Te mainisite, et ClickHouse tarbib k\u00f5iki talle saadaval olevaid ressursse v\u00e4ga h\u00e4sti. Ja ettekandja, kes oli Glassifti k\u00f5rval, r\u00e4\u00e4kis oma lahendusest Post Vene tagasi. Ta \u00fctles, et neile meeldis ClickHouse v\u00e4ga, kuid nad ei kasutanud seda oma peamise konkurendi asemel, just sellep\u00e4rast, et see v\u00f5ttis k\u00f5ik protsessori j\u00f5u. Ja nad ei suutnud seda oma arhitektuuri, oma ZooKeeperi ja konteineritega integreerida. Kas on v\u00f5imalik mingil moel piirata ClickHouse'i, et see ei tarbiks k\u00f5ike, mis talle k\u00e4tte saadav on?<\/em><\/p>\n

<\/p>\n

Jah, on v\u00f5imalik ja v\u00e4ga lihtne. Kui soovite, et v\u00e4hem tuumasid tarbitakse, kirjutage lihtsalt set max_threads = 1<\/code>. Ja k\u00f5ik, see t\u00e4idab p\u00e4ringu \u00fche tuumaga. T\u00f5si, erinevatele kasutajatele saab m\u00e4\u00e4rata erinevaid seadeid. Nii et probleeme pole. Ja edastage oma kolleegidele Glassiftis, et nad ei leidnud seda seadet dokumentatsioonist, see pole hea. <\/p>\n

<\/p>\n

Tere, Aleksei! Soovin k\u00fcsida sellist k\u00fcsimust. See ei ole esimene kord, kui kuulen, et paljud hakkavad kasutama ClickHouse'i logide salvestamiseks. Esitluses r\u00e4\u00e4kisite, et seda ei peaks tegema, ehk siis pikki ridu ei tohiks salvestada. Kuidas te sellele suhtute?<\/em><\/p>\n

<\/p>\n

Esiteks, logid ei ole reeglina pikad read. Loomulikult on erandeid. N\u00e4iteks, kui m\u00f5ni teenus, mis on kirjutatud Java's, viskab exception'i, siis see logitakse. Ja nii l\u00f5putus ts\u00fcklis, kuni k\u00f5vakettal ei j\u00e4tku ruumi. Lahendus on v\u00e4ga lihtne. Kui read on liiga pikad, siis k\u00e4rpige neid. Mis t\u00e4hendab liiga pikka? K\u00fcmneid kilobaiti \u2013 see on halb.<\/p>\n

<\/p>\n

* \u0432 \u0441\u0432\u0435\u0436\u0438\u0445 \u0432\u0435\u0440\u0441\u0438\u044f\u0445 ClickHouse, \u0432\u043a\u043b\u044e\u0447\u0435\u043d\u0430 "\u0430\u0434\u0430\u043f\u0442\u0438\u0432\u043d\u0430\u044f \u0433\u0440\u0430\u043d\u0443\u043b\u0438\u0440\u043e\u0432\u0430\u043d\u043d\u043e\u0441\u0442\u044c \u0438\u043d\u0434\u0435\u043a\u0441\u0430", \u0447\u0442\u043e \u0441\u043d\u0438\u043c\u0430\u0435\u0442 \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0443 \u0445\u0440\u0430\u043d\u0435\u043d\u0438\u044f \u0434\u043b\u0438\u043d\u043d\u044b\u0445 \u0441\u0442\u0440\u043e\u043a \u043f\u043e \u0431\u043e\u043b\u044c\u0448\u0435\u0439 \u0447\u0430\u0441\u0442\u0438.<\/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! Ma juba k\u00fcsisin sellest vestluses, aga ei m\u00e4leta, kas sain vastuse. Kas plaanitakse laiendada WITH jaotist nagu CTE?<\/em><\/p>\n

<\/p>\n

Praegu ei. Meie WITH jaotis on pigem t\u00f5siseltv\u00f5etmatu. See on meil nagu v\u00e4ike funktsioon.<\/p>\n

<\/p>\n

M\u00f5istan. Ait\u00e4h!<\/em><\/p>\n

<\/p>\n

Ait\u00e4h ettekande eest! V\u00e4ga huvitav! \u00dcks globaalne k\u00fcsimus. Kas plaanitakse luua, v\u00f5ib-olla, mingite suunavate lahenduste kaudu andmete kustutamise muudatusetappi?<\/em><\/p>\n

<\/p>\n

Kindlasti. See on meie prioriteetide nimekirjas esimene \u00fclesanne. Me oleme aktiivselt v\u00e4lja m\u00f5elnud, kuidas k\u00f5ike \u00f5igesti teha. Ja on aeg hakata klaviatuurile vajutama*.<\/p>\n

<\/p>\n

* vajutasime klahve klaviatuuril ja tegime k\u00f5ik korda.<\/p>\n

<\/p>\n

Kas see m\u00f5jutab kuidagi s\u00fcsteemi j\u00f5udlust v\u00f5i mitte? Kas sisestamine j\u00e4\u00e4b sama kiireks kui praegu?<\/em><\/p>\n

<\/p>\n

V\u00f5ib-olla on kustutamised ja uuendused v\u00e4ga keerulised, kuid see ei m\u00f5juta valikute ja sisestuste j\u00f5udlust.<\/p>\n

<\/p>\n

Ja veel \u00fcks v\u00e4ike k\u00fcsimus. Esitluses r\u00e4\u00e4kisite primaarv\u00f5tmega. Seega on meil partitsioneerimine, mis on vaikimisi kuup\u00f5hine, eks? Ja kui m\u00e4\u00e4rame kuup\u00e4evade vahemiku, mis mahub kuusse, loetakse ainult see partitsioon, eks?<\/em><\/p>\n

<\/p>\n

Jah.<\/p>\n

<\/p>\n

Tavaliselt tekib k\u00fcsimus: kui me ei suuda m\u00e4\u00e4rata mingit primaarset v\u00f5tit, kas on \u00f5ige teha seda \u201eKuup\u00e4eva\u201d v\u00e4lja alusel, et v\u00e4hendada taustal nende andmete \u00fcmberstruktureerimist ja muuta need paremini organiseerituks? Kui teil ei ole vahemikup\u00e4ringuid ja te ei suuda valida \u00fchtegi primaarset v\u00f5tit, siis kas on m\u00f5tet kuup\u00e4eva primaarseks v\u00f5tme panna?<\/em><\/p>\n

<\/p>\n

Jah.<\/p>\n

<\/p>\n

V\u00f5ib-olla on m\u00f5istlik lisada primaarsetesse v\u00f5tmetesse v\u00e4li, mille alusel andmed l\u00e4bivad paremini tihendamist, kui need on selle v\u00e4lja j\u00e4rgi j\u00e4rjestatud. N\u00e4iteks kasutaja identifikaator. Kasutaja k\u00fclastab sama saiti. Sellisel juhul lisage kasutaja ID ja aeg. Siis tihendatakse teie andmed paremini. Kuup\u00e4eva osas, kui teil t\u00f5eliselt ei ole ja ei ole kunagi vahemikup\u00e4ringuid kuup\u00e4evade j\u00e4rgi, siis ei pea kuup\u00e4eva primaarsetesse v\u00f5tmetesse lisama. <\/p>\n

<\/p>\n

Ait\u00e4h, suur ait\u00e4h!<\/em><\/p>\n

Allikas: 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\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47T\u00f5hus ClickHouse'i kasutamine. Aleksei Milovidov (Yandex) | ProHoster","description":"Kuna ClickHouse on spetsialiseeritud s\u00fcsteem, on selle kasutamisel oluline arvestada selle arhitektuuri erip\u00e4ra. Selles ettekandes r\u00e4\u00e4gib Aleksei t\u00fc\u00fcpilistest vigadest ClickHouse'i kasutamisel, mis v\u00f5ivad viia ebat\u00f5husale t\u00f6\u00f6le. Praktiliste n\u00e4idete kaudu n\u00e4idatakse, kuidas erineva andmet\u00f6\u00f6tlusmeetodi valik v\u00f5ib muuta j\u00f5udlust mitmeid kordi. Tere k\u00f5igile! Minu nimi on","canonical_url":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/effektivnoe-ispolzovanie-clickhouse-aleksej-milovidov-yandeks","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"et_EE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u042d\u0444\u0444\u0435\u043a\u0442\u0438\u0432\u043d\u043e\u0435 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043d\u0438\u0435 ClickHouse. \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041c\u0438\u043b\u043e\u0432\u0438\u0434\u043e\u0432 (\u042f\u043d\u0434\u0435\u043a\u0441) | ProHoster","og:description":"\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","og:url":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/effektivnoe-ispolzovanie-clickhouse-aleksej-milovidov-yandeks","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-08-13T17:42:36+00:00","article:modified_time":"2020-08-13T17:42:36+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"91438","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 12:27:23","updated":"2022-09-28 17:25:41"},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/91438","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/comments?post=91438"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/91438\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media\/91439"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media?parent=91438"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/categories?post=91438"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/tags?post=91438"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}