Að flytja í ClickHouse: 3 árum síðar

Fyrir þremur árum síðan Viktor Tarnavsky og Alexey Milovidov frá Yandex á sviðinu HighLoad++ sagt, hversu gott ClickHouse er og hvernig það hægir ekki á sér. Og á næsta stigi var Alexander Zaitsev с skýrslu um að flytja til smellahús frá öðru greiningarkerfi og með þeirri niðurstöðu að smellahús, auðvitað, gott, en ekki mjög þægilegt. Þegar árið 2016 var fyrirtækið Lifestreet, þar sem Alexander vann þá, var að breyta multi-petabæta greiningarkerfi í smellahús, þetta var heillandi „gulur múrsteinsvegur“ fullur af óþekktum hættum - smellahús þá leit þetta út eins og jarðsprengjusvæði.

Þremur árum síðar smellahús varð miklu betri - á þessum tíma stofnaði Alexander fyrirtækið Altinity, sem hjálpar fólki ekki bara að flytja til smellahús tugir verkefna, en bætir einnig vöruna sjálfa ásamt samstarfsfólki frá Yandex. Nú smellahús samt ekki áhyggjulaus rölta, en ekki lengur jarðsprengjusvæði.

Alexander hefur unnið með dreifð kerfi síðan 2003, þróað stór verkefni á MySQL, Oracle и Vertica. Á síðasta HighLoad++ 2019 Alexander, einn af frumkvöðlum notkunar smellahús, sagt hvað þetta DBMS er núna. Við munum læra um helstu eiginleika smellahús: hvernig það er frábrugðið öðrum kerfum og í hvaða tilvikum er skilvirkara að nota það. Með dæmum munum við skoða nýlegar og verkprófaðar venjur fyrir byggingarkerfi sem byggjast á smellahús.

Til baka: hvað gerðist fyrir 3 árum

Fyrir þremur árum fluttum við fyrirtækið Lifestreet á smellahús úr öðrum greiningargagnagrunni og greiningarflutningur auglýsinganetsins leit svona út:

• júní 2016. Í Open Source birtist smellahús og verkefnið okkar byrjaði;
• Ágúst. Sönnun hugtaks: stórt auglýsinganet, innviðir og 200-300 terabæta af gögnum;
• Október. Fyrstu framleiðslugögn;
• desember. Fullt vöruálag er 10-50 milljarðar atburða á dag.
• júní 2017. Vel heppnuð flutningur notenda til smellahús, 2,5 petabæta af gögnum á þyrping af 60 netþjónum.

Á flutningsferlinu jókst skilningur á því smellahús er gott kerfi sem er notalegt að vinna með, en þetta er innra verkefni Yandex. Þess vegna eru blæbrigði: Yandex mun fyrst takast á við eigin innri viðskiptavini og aðeins þá við samfélagið og þarfir utanaðkomandi notenda, og ClickHouse náði þá ekki fyrirtækisstigi á mörgum hagnýtum sviðum. Þess vegna stofnuðum við Altinity í mars 2017 til að gera smellahús enn hraðari og þægilegri, ekki aðeins fyrir Yandex, heldur einnig fyrir aðra notendur. Og nú:

• Við þjálfum og aðstoðum við að byggja upp lausnir út frá smellahús svo að viðskiptavinir lendi ekki í vandræðum og þannig að lausnin virki á endanum;
• Við veitum stuðning allan sólarhringinn smellahús- innsetningar;
• Við þróum okkar eigin vistkerfisverkefni;
• Við skuldbindum okkur á virkan hátt smellahús, bregðast við beiðnum frá notendum sem vilja sjá ákveðna eiginleika.

Og auðvitað aðstoðum við við að flytja til smellahús с MySQL, Vertica, Oracle, Greenplum, Redshift og önnur kerfi. Við höfum tekið þátt í ýmsum aðgerðum og þær hafa allar gengið vel.

Til hvers að flytja til smellahús

Ekki hægja á sér! Þetta er aðalástæðan. smellahús - mjög hraður gagnagrunnur fyrir mismunandi aðstæður:

Tilviljunarkenndar tilvitnanir í fólk sem hefur unnið með fólki í langan tíma smellahús.

Skalanleiki. Á einhverjum öðrum gagnagrunni geturðu náð góðum árangri á einu stykki af vélbúnaði, en smellahús þú getur skalað ekki aðeins lóðrétt heldur líka lárétt, einfaldlega með því að bæta við netþjónum. Allt gengur ekki eins vel og við viljum, en það virkar. Þú getur stækkað kerfið eftir því sem fyrirtæki þitt stækkar. Það er mikilvægt að við takmörkumst ekki lausnina núna og það eru alltaf möguleikar á þróun.

Færanleiki. Það er engin tenging við eitt. Til dæmis með Amazon Rauðskipting Það er erfitt að flytja eitthvað. A smellahús þú getur sett það upp á fartölvuna þína, miðlara, sett það í skýið, farið á Kubernetes — engar takmarkanir eru á rekstri innviðanna. Þetta er þægilegt fyrir alla og þetta er stór kostur sem margir aðrir svipaðir gagnagrunnar geta ekki státað af.

Sveigjanleiki. smellahús stoppar ekki við eitt, til dæmis Yandex.Metrica, heldur þróar og er notað í fleiri og fleiri mismunandi verkefnum og atvinnugreinum. Það er hægt að stækka það með því að bæta við nýjum getu til að leysa ný vandamál. Til dæmis er talið að geymsla logs í gagnagrunni sé slæmur siður, svo þeir komust upp með Elasticsearch. En þökk sé sveigjanleika smellahús, þú getur líka geymt logs í því og oft er þetta jafnvel betra en í Elasticsearch - kl smellahús þetta krefst 10 sinnum minna járns.

Ókeypis Open Source. Þú þarft ekki að borga fyrir neitt. Það er engin þörf á að semja um leyfi til að setja upp kerfið á fartölvu eða netþjóni. Engin falin gjöld. Á sama tíma getur engin önnur Open Source gagnagrunnstækni keppt í hraða við smellahús. MySQL, MariaDB, Greenplum - þeir eru allir miklu hægari.

Samfélag, akstur og gaman. Hafa smellahús frábært samfélag: fundir, spjall og Alexey Milovidov, sem hleður okkur öll með orku sinni og bjartsýni.

Að flytja í ClickHouse

Að fara til smellahús af einhverjum ástæðum þarftu aðeins þrennt:

• Skilja takmarkanir smellahús og hvað það hentar ekki.
• Nýta tækni og stærstu styrkleika hennar.
• Tilraun. Jafnvel að skilja hvernig það virkar smellahús, það er ekki alltaf hægt að spá fyrir um hvenær það verður hraðar, hvenær það verður hægara, hvenær það verður betra og hvenær það verður verra. Svo reyndu það.

Flutningsvandamál

Það er aðeins eitt „en“: ef þú flytur til smellahús frá einhverju öðru, þá fer yfirleitt eitthvað úrskeiðis. Við erum vön sumum venjum og hlutum sem virka í uppáhalds gagnagrunninum okkar. Til dæmis allir sem vinna með SQL-gagnagrunnar telja eftirfarandi sett af aðgerðum skylda:

• viðskipti;
• þvingun;
• samkvæmni;
• vísitölur;
• UPPFÆRA/EYÐA;
• NULL;
• millisekúndur;
• sjálfvirk gerð afsteypa;
• margar tengingar;
• handahófskennd skipting;
• klasastjórnunartæki.

Ráðning er skylda, en fyrir þremur árum í smellahús Engin af þessum aðgerðum var tiltæk! Nú er minna en helmingur eftir af því sem ekki hefur verið innleitt: færslur, takmarkanir, samræmi, millisekúndur og tegundarsteypa.

Og aðalatriðið er að í smellahús sumar staðlaðar venjur og aðferðir virka ekki eða virka öðruvísi en við eigum að venjast. Allt sem birtist í smellahús, samsvarar til "ClickHouse leið“, þ.e. aðgerðir eru frábrugðnar öðrum gagnagrunnum. Til dæmis:

• Vísitölur eru ekki valdar heldur sleppt.
• UPPFÆRA/EYÐA ekki samstilltur, heldur ósamstilltur.
• Það eru margar sameiningar, en það er enginn fyrirspurnarskipuleggjandi. Hvernig þau eru síðan framkvæmd er fólki úr gagnagrunnsheiminum almennt ekki mjög ljóst.

ClickHouse Scripts

Árið 1960, bandarískur stærðfræðingur af ungverskum uppruna Wigner EP skrifaði grein "Ósanngjörn virkni stærðfræði í náttúruvísindum” („The Incomprehensible Effectiveness of Mathematics in the Natural Sciences“) að heiminum í kringum okkur sé einhverra hluta vegna vel lýst með stærðfræðilögmálum. Stærðfræði er óhlutbundin vísindi og eðlisfræðileg lögmál sett fram í stærðfræðilegu formi eru ekki léttvæg og Wigner EP lagði áherslu á að þetta væri mjög skrítið.

Frá mínu sjónarhorni, smellahús - sama undarlega. Til að endurorða Wigner getum við sagt þetta: óhugsandi skilvirkni er ótrúleg smellahús í fjölmörgum greiningarforritum!

Tökum til dæmis Rauntíma gagnavöruhús, þar sem gögnum er hlaðið nánast stöðugt. Við viljum fá beiðnir frá því með annarri töf. Vinsamlegast - notaðu það smellahús, vegna þess að þetta er atburðarásin sem hún var hönnuð fyrir. smellahús þetta er nákvæmlega hvernig það er notað ekki aðeins á vefnum, heldur einnig í markaðssetningu og fjármálagreiningum, AdTech, sem og í Uppgötvun svikan. IN Rauntíma gagnavöruhús flókið skipulagt kerfi eins og „stjarna“ eða „snjókorn“ er notað, margar töflur með JOIN (stundum mörg) og gögnin eru venjulega geymd og þeim breytt í sumum kerfum.

Við skulum taka aðra atburðarás - Tímaröð: eftirlit með tækjum, netkerfum, notkunartölfræði, Internet of Things. Hér lendum við í frekar einföldum atburðum sem raðað er í tíma. smellahús var upphaflega ekki þróað fyrir þetta, en hefur sýnt sig að virka vel og þess vegna nota stór fyrirtæki smellahús sem geymsla fyrir eftirlit með upplýsingum. Til að kanna hvort það henti smellahús fyrir tímaraðir, gerðum við viðmið byggt á nálgun og niðurstöðum InnstreymiDB и TímastigDB - sérhæfður tímaröð gagnagrunna. Það kom í ljósÞað smellahús, jafnvel án hagræðingar fyrir slík verkefni, vinnur á erlendum vettvangi:

В tímaröð Venjulega er notað þröngt borð - nokkrir litlar dálkar. Mikið af gögnum geta komið frá vöktun—milljónir skráa á sekúndu—og þau koma venjulega í litlum hraða (raunverulegur-tími streymi). Þess vegna þarf annað innsetningarforskrift og fyrirspurnirnar sjálfar hafa sínar eigin sérkenni.

Log Stjórn. Að safna annálum í gagnagrunn er venjulega slæmt, en smellahús þetta er hægt að gera með nokkrum athugasemdum eins og lýst er hér að ofan. Mörg fyrirtæki nota smellahús einmitt í þessum tilgangi. Í þessu tilviki notum við flatt breitt borð þar sem við geymum heilu stokkana (til dæmis í formi JSON), eða skera í bita. Gögn eru venjulega hlaðin í stórum lotum (skrám) og við leitum eftir einhverju sviði.

Fyrir hverja þessara aðgerða eru venjulega notaðir sérhæfðir gagnagrunnar. smellahús maður getur þetta allt og svo vel að það fer fram úr þeim. Við skulum nú skoða nánar tímaröð atburðarás og hvernig á að „elda“ rétt smellahús fyrir þessa atburðarás.

Tímaröð

Eins og er er þetta helsta atburðarás sem smellahús talin staðlað lausn. Tímaröð er safn atburða raðað í tíma, sem táknar breytingar á einhverju ferli með tímanum. Þetta gæti til dæmis verið hjartsláttur á dag eða fjöldi ferla í kerfinu. Allt sem gefur tíma tifar með einhverjum víddum er tímaröð:

Flestir þessara tegunda atburða koma frá eftirliti. Þetta getur ekki aðeins verið eftirlit með vefnum, heldur einnig raunveruleg tæki: bílar, iðnaðarkerfi, IOT, verksmiðjur eða ómannaða leigubíla, í skottinu sem Yandex er nú þegar að setja smellahús-þjónn.

Til dæmis eru fyrirtæki sem safna gögnum frá skipum. Á nokkurra sekúndna fresti senda skynjarar á gámaskipinu hundruð mismunandi mælinga. Vélstjórar rannsaka þau, smíða líkön og reyna að skilja hversu skilvirkt skipið er notað, því gámaskip ætti ekki að vera aðgerðalaus í eina sekúndu. Sérhver niðurstaða er peningatap og því er mikilvægt að spá fyrir um leiðina þannig að stöðvun sé sem minnst.

Nú á dögum er vöxtur sérhæfðra gagnagrunna sem mæla tímaröð. Á síðunni DB-vélar Mismunandi gagnagrunnum er einhvern veginn raðað og þú getur skoðað þá eftir gerð:

Ört vaxandi tegundin er tímaröðs. Línurit gagnagrunnar eru líka að stækka, en tímaröðs hafa vaxið hraðar á undanförnum árum. Dæmigert fulltrúar þessarar fjölskyldu gagnagrunna eru InnstreymiDB, Prometheus, KDB, TímastigDB (byggt á PostgreSQL), lausnir frá Amazon. smellahús er hægt að nota hér líka, og er notað. Leyfðu mér að gefa þér nokkur opinber dæmi.

Einn af frumkvöðlunum er fyrirtækið CloudFlare (CDN-veitanda). Þeir fylgjast með sínum CDN gegnum smellahús (DNS-beiðnir, HTTP-fyrirspurnir) með miklu álagi - 6 milljónir atburða á sekúndu. Allt gengur í gegn Kafka, fer til smellahús, sem gefur tækifæri til að sjá mælaborð yfir atburði í kerfinu í rauntíma.

Comcast - einn af leiðandi í fjarskiptum í Bandaríkjunum: Internet, stafrænt sjónvarp, símtækni. Þeir bjuggu til svipað eftirlitskerfi CDN innan rammans Open Source verkefnið Apache umferðareftirlit til að vinna með risastóru gögnin þín. smellahús notað sem bakendi fyrir greiningar.

percona innbyggð smellahús inni hjá þér PMMað geyma eftirlit með ýmsu MySQL.

Sérstakar kröfur

Tímaraðir gagnagrunnar hafa sínar sérstakar kröfur.

• Fljótleg innsetning frá mörgum umboðsmönnum. Við verðum að setja inn gögn úr mörgum straumum mjög fljótt. smellahús Það gerir þetta vel vegna þess að öll innlegg þess eru óblokkandi. Einhver setja er ný skrá á diski og hægt er að stilla smá innskoti á einn eða annan hátt. IN smellahús Það er betra að setja gögn inn í stórar lotur frekar en eina línu í einu.
• Sveigjanlegt kerfi. Í tímaröð við þekkjum venjulega ekki uppbygging gagna alveg. Það er hægt að byggja upp eftirlitskerfi fyrir tiltekið forrit en þá er erfitt að nota það fyrir annað forrit. Þetta krefst sveigjanlegra kerfis. smellahús, gerir þér kleift að gera þetta, jafnvel þó að það sé sterklega sleginn grunnur.
• Skilvirk geymsla og gleyma gögnum. Venjulega í tímaröð gríðarlegt magn af gögnum og því verður að geyma þau á eins skilvirkan hátt og hægt er. Til dæmis, kl InnstreymiDB góð þjöppun er aðaleinkenni þess. En fyrir utan að geyma þarftu líka að geta „gleymt“ gömlum gögnum og gert einhvers konar niðursýni — sjálfvirk talning á heildarupphæðum.
• Fljótar fyrirspurnir um uppsöfnuð gögn. Stundum er áhugavert að skoða síðustu 5 mínúturnar með nákvæmni upp á millisekúndur, en á mánaðarlegum gögnum gæti verið að ekki sé þörf á nákvæmni mínútu eða sekúndu - almenn tölfræði er nóg. Stuðningur af þessu tagi er nauðsynlegur, annars tekur beiðni um 3 mánuði mjög langan tíma að klára jafnvel inn smellahús.
• Beiðnir eins og "síðasta lið, frá og með». Þetta eru dæmigerð fyrir tímaröð fyrirspurnir: skoðaðu síðustu mælingu eða stöðu kerfisins á augnabliki t. Þetta eru ekki mjög skemmtilegar fyrirspurnir um gagnagrunn, en þú þarft líka að geta framkvæmt þær.
• „Gluing“ tímaröð. Tímaröð er tímaröð. Ef um er að ræða tvær tímaraðir þarf oft að tengja þær saman og tengja þær saman. Það er ekki þægilegt að gera þetta á öllum gagnagrunnum, sérstaklega með ósamræmdar tímaraðir: hér eru nokkrir tímapunktar, það eru aðrir. Þú getur íhugað meðaltal, en allt í einu verður enn hola þar, svo það er ekki ljóst.

Við skulum sjá hvernig þessar kröfur eru uppfylltar smellahús.

Kerfið

В smellahús áætlun fyrir tímaröð hægt að gera á mismunandi vegu, allt eftir því hversu regluleg gögnin eru. Það er hægt að byggja upp kerfi á venjulegum gögnum þegar við vitum allar mælingar fyrirfram. Ég gerði þetta til dæmis CloudFlare með eftirliti CDN er vel fínstillt kerfi. Hægt er að byggja upp almennara kerfi sem fylgist með öllum innviðum og ýmsum þjónustum. Þegar um óregluleg gögn er að ræða þá vitum við ekki fyrirfram hverju við erum að fylgjast með - og það er líklega algengasta tilvikið.

Regluleg gögn. Dálkar. Skipulagið er einfalt - dálkar með nauðsynlegum gerðum:

CREATE TABLE cpu (
  created_date Date DEFAULT today(),  
  created_at DateTime DEFAULT now(),  
  time String,  
  tags_id UInt32,  /* join to dim_tag */
  usage_user Float64,  
  usage_system Float64,  
  usage_idle Float64,  
  usage_nice Float64,  
  usage_iowait Float64,  
  usage_irq Float64,  
  usage_softirq Float64,  
  usage_steal Float64,  
  usage_guest Float64,  
  usage_guest_nice Float64
) ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

Þetta er venjuleg tafla sem fylgist með einhvers konar hleðsluvirkni kerfisins (notandi, kerfið, aðgerðalaus, gott). Einfalt og þægilegt, en ekki sveigjanlegt. Ef við viljum sveigjanlegra kerfi, þá getum við notað fylki.

Óregluleg gögn. Fylki:

CREATE TABLE cpu_alc (
  created_date Date,  
  created_at DateTime,  
  time String,  
  tags_id UInt32,  
  metrics Nested(
    name LowCardinality(String),  
    value Float64
  )
) ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

SELECT max(metrics.value[indexOf(metrics.name,'usage_user')]) FROM ...

Uppbygging Hreiður eru tvær fylkingar: metrics.name и mæligildi.gildi. Hér getur þú geymt slík handahófskennd vöktunargögn sem fjölda nafna og fjölda mælinga fyrir hvern atburð. Fyrir frekari hagræðingu, í stað einnar slíkrar uppbyggingar, geturðu búið til nokkrar. Til dæmis einn fyrir fljóta-gildi, annað - fyrir int-sem þýðir vegna þess int Ég vil geyma á skilvirkari hátt.

En slíkt mannvirki er erfiðara að nálgast. Þú verður að nota sérstaka byggingu, nota sérstakar aðgerðir til að draga út gildi fyrst vísitölunnar og síðan fylkisins:

SELECT max(metrics.value[indexOf(metrics.name,'usage_user')]) FROM ...

En það virkar samt frekar fljótt. Önnur leið til að geyma óregluleg gögn er eftir röð.

Óregluleg gögn. Strengir. Í þessari hefðbundnu aðferð, án fylkja, eru nöfn og gildi geymd samtímis. Ef 5 mælingar koma frá einu tæki í einu myndast 000 línur í gagnagrunninum:

CREATE TABLE cpu_rlc (
  created_date Date,  
  created_at DateTime,  
  time String,  
  tags_id UInt32,  
  metric_name LowCardinality(String),  
  metric_value Float64
) ENGINE = MergeTree(created_date, (metric_name, tags_id, created_at), 8192);


SELECT 
    maxIf(metric_value, metric_name = 'usage_user'),
    ... 
FROM cpu_r
WHERE metric_name IN ('usage_user', ...)

smellahús tekst á við þetta - það hefur sérstakar framlengingar smellahús SQL. Til dæmis, maxEf — sérstakt fall sem reiknar hámarkið með mæligildi þegar einhverju skilyrði er uppfyllt. Þú getur skrifað nokkrar slíkar tjáningar í einni beiðni og reiknað strax út gildið fyrir nokkrar mælingar.

Við skulum bera saman þrjár aðferðir:

upplýsingar

Hér hef ég bætt við "Disk Data Size" fyrir nokkur prófunargagnasett. Þegar um dálka er að ræða höfum við minnstu gagnastærð: hámarksþjöppun, hámarks fyrirspurnarhraða, en við borgum með því að þurfa að skrá allt í einu.

Þegar um fylki er að ræða er allt aðeins verra. Gögnin eru enn vel þjappuð og hægt er að geyma óreglulegt mynstur. En smellahús - dálkagagnagrunnur og þegar við byrjum að geyma allt í fylki breytist hann í eina röð og við borgum fyrir sveigjanleika með skilvirkni. Fyrir hvaða aðgerð sem er, verður þú að lesa allt fylkið inn í minnið, finna síðan þann þátt sem óskað er eftir í því - og ef fylkið stækkar, þá minnkar hraðinn.

Í einu af fyrirtækjum sem nota þessa aðferð (td. Uber), fylki eru skorin í stykki af 128 þáttum. Gögn úr nokkur þúsund mæligildum með rúmmál 200 TB af gögnum á dag eru geymd ekki í einu fylki, heldur í 10 eða 30 fylkjum með sérstakri geymslurökfræði.

Einfaldasta aðferðin er með strengjum. En gögnin eru illa þjöppuð, töflustærðin er stór og jafnvel þegar fyrirspurnir eru byggðar á nokkrum mælingum virkar ClickHouse ekki sem best.

Hybrid kerfi

Gerum ráð fyrir að við höfum valið fylkisrás. En ef við vitum að flest mælaborðin okkar sýna aðeins notenda- og kerfismælingar, getum við auk þess sett þessar mælingar í dálka úr fylki á töflustigi á þennan hátt:

CREATE TABLE cpu_alc (
  created_date Date,  
  created_at DateTime,  
  time String,  
  tags_id UInt32,  
  metrics Nested(
    name LowCardinality(String),  
    value Float64
  ),
  usage_user Float64 
             MATERIALIZED metrics.value[indexOf(metrics.name,'usage_user')],
  usage_system Float64 
             MATERIALIZED metrics.value[indexOf(metrics.name,'usage_system')]
) ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

Við innsetningu smellahús mun sjálfkrafa telja þá. Þannig geturðu sameinað viðskipti og ánægju: kerfið er sveigjanlegt og almennt, en við tókum út þá dálka sem oftast eru notaðir. Athugaðu að til þess þurfti ekki að breyta innskotinu og ETLsem heldur áfram að setja fylki inn í töfluna. Við gerðum það bara ALTER TAFLA, bætti við nokkrum hátölurum og við fengum blendingur og hraðari kerfi sem þú getur byrjað að nota strax.

Merkjamál og þjöppun

Fyrir tímaröð Það skiptir máli hversu vel þú pakkar gögnunum því magn upplýsinga getur verið mjög mikið. IN smellahús Það er sett af verkfærum til að ná þjöppunaráhrifum upp á 1:10, 1:20 og stundum meira. Þetta þýðir að 1 TB af ópakkuðum gögnum á disknum tekur 50-100 GB. Minni stærð er góð, gögn er hægt að lesa og vinna hraðar.

Til að ná háu stigi þjöppunar, smellahús styður eftirfarandi merkjamál:

Dæmi tafla:

CREATE TABLE benchmark.cpu_codecs_lz4 (
    created_date Date DEFAULT today(), 
    created_at DateTime DEFAULT now() Codec(DoubleDelta, LZ4), 
    tags_id UInt32, 
    usage_user Float64 Codec(Gorilla, LZ4), 
    usage_system Float64 Codec(Gorilla, LZ4), 
    usage_idle Float64 Codec(Gorilla, LZ4), 
    usage_nice Float64 Codec(Gorilla, LZ4), 
    usage_iowait Float64 Codec(Gorilla, LZ4), 
    usage_irq Float64 Codec(Gorilla, LZ4), 
    usage_softirq Float64 Codec(Gorilla, LZ4), 
    usage_steal Float64 Codec(Gorilla, LZ4), 
    usage_guest Float64 Codec(Gorilla, LZ4), 
    usage_guest_nice Float64 Codec(Gorilla, LZ4), 
    additional_tags String DEFAULT ''
)
ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

Hér skilgreinum við merkjamálið DoubleDelta í einu tilviki, í öðru - Gorilla, og við munum örugglega bæta við fleiri LZ4 þjöppun. Fyrir vikið minnkar stærð gagna á diski verulega:

Þetta sýnir hversu mikið pláss sömu gögn taka, en með því að nota mismunandi merkjamál og þjöppun:

• í GZIP skrá á diski;
• í ClickHouse án merkjamál, en með ZSTD þjöppun;
• í ClickHouse með merkjamáli og samþjöppun LZ4 og ZSTD.

Það má sjá að töflur með merkjamál taka mun minna pláss.

Stærð skiptir máli

Ekki síður mikilvægt выбрать rétt gagnategund:

Í öllum dæmunum hér að ofan notaði ég Fljóta64. En ef við kjósum Fljóta32, þá væri það enn betra. Þetta sýndu strákarnir frá Perkona vel í greininni sem tengd var hér að ofan. Það er mikilvægt að nota þéttustu gerðina sem hentar verkefninu: jafnvel minni fyrir diskstærð en fyrir fyrirspurnarhraða. smellahús mjög viðkvæm fyrir þessu.

Ef þú getur notað int32 í staðinn fyrir int64, þá búast við næstum tvöföldun á frammistöðu. Gögnin taka minna minni og öll „reikningur“ virkar mun hraðar. smellahús Innbyrðis er þetta mjög strangt vélritað kerfi; það nýtir alla þá möguleika sem nútíma kerfi bjóða upp á.

Söfnun og Veruleikasjónarmið

Söfnun og efnislegar skoðanir gera þér kleift að búa til einingar fyrir mismunandi tilefni:

Til dæmis gætir þú verið með ósöfnuð upprunagögn og þú getur hengt ýmsar efnislegar skoðanir við þau með sjálfvirkri samantekt í gegnum sérstaka vél SummingMergeTree (SMT). SMT er sérstakt uppsöfnunargagnaskipulag sem reiknar samanlagnir sjálfkrafa. Hrágögn eru sett inn í gagnagrunninn, þau safnast saman sjálfkrafa og hægt er að nota mælaborð strax á þeim.

TTL - „gleyma“ gömlum gögnum

Hvernig á að „gleyma“ gögnum sem ekki er lengur þörf á? smellahús veit hvernig á að gera þetta. Þegar þú býrð til töflur geturðu tilgreint TTL orðatiltæki: til dæmis að við geymum mínútugögn í einn dag, dagleg gögn í 30 daga og snertum aldrei vikuleg eða mánaðarleg gögn:

CREATE TABLE aggr_by_minute
…
TTL time + interval 1 day

CREATE TABLE aggr_by_day
…
TTL time + interval 30 day

CREATE TABLE aggr_by_week
…
/* no TTL */

Fjölþrepa - skipta gögnum yfir diska

Með því að taka þessa hugmynd lengra er hægt að geyma gögn í smellahús á mismunandi stöðum. Segjum sem svo að við viljum geyma heit gögn fyrir síðustu viku á mjög hröðum stað SSD, og við setjum fleiri söguleg gögn á annan stað. IN smellahús þetta er nú hægt:

Þú getur stillt geymslustefnu (geymslustefnu) Svo smellahús mun sjálfkrafa flytja gögn þegar tilteknum skilyrðum er náð í aðra geymslu.

En það er ekki allt. Á stigi tiltekinnar töflu er hægt að skilgreina reglur um nákvæmlega hvenær gögnin fara í frystigeymslu. Til dæmis eru gögn geymd á mjög hröðum diski í 7 daga og allt sem er eldra er flutt yfir á hægan disk. Þetta er gott vegna þess að það gerir þér kleift að halda kerfinu í hámarks afköstum, á meðan þú stjórnar kostnaði og sóar ekki peningum í köld gögn:

CREATE TABLE 
... 
TTL date + INTERVAL 7 DAY TO VOLUME 'cold_volume', 
    date + INTERVAL 180 DAY DELETE

Einstakir eiginleikar smellahús

Í nánast öllu smellahús Það eru svona „hápunktar“ en á móti þeim kemur einkarétt - eitthvað sem er ekki í öðrum gagnagrunnum. Til dæmis, hér eru nokkrar af einstöku eiginleikum smellahús:

• Fylki. Í smellahús mjög góður stuðningur við fylki, sem og getu til að framkvæma flókna útreikninga á þeim.
• Söfnun gagnauppbygginga. Þetta er einn af "drápseiginleikunum" smellahús. Þrátt fyrir þá staðreynd að krakkar frá Yandex segi að við viljum ekki safna gögnum, er allt safnað saman í smellahús, vegna þess að það er fljótlegt og þægilegt.
• Veruleikaviðhorf. Ásamt uppsöfnun gagnaskipulags, gera efnislegar skoðanir þér kleift að gera þægilegt raunverulegur-tími samansafn.
• ClickHouse SQL. Þetta er tungumálaviðbót SQL með nokkrum viðbótareiginleikum sem eru aðeins fáanlegir í smellahús. Áður fyrr var það eins og stækkun annars vegar og ókostur hins vegar. Nú nánast allir ókostir miðað við SQL 92 við fjarlægðum það, nú er það bara framlenging.
• Lambda-tjáningar. Eru þeir enn í einhverjum gagnagrunni?
• ML-stuðningur. Þetta er fáanlegt í mismunandi gagnagrunnum, sumir eru betri, aðrir verri.
• opinn uppspretta. Við getum stækkað smellahús saman. Nú inn smellahús um 500 þátttakendur og fer þessi fjöldi stöðugt vaxandi.

Vandaðar fyrirspurnir

В smellahús það eru margar mismunandi leiðir til að gera það sama. Til dæmis er hægt að skila síðasta gildi úr töflu á þrjá mismunandi vegu fyrir CPU (það er líka fjórði, en hann er enn framandi).

Sú fyrri sýnir hversu þægilegt það er að gera það smellahús fyrirspurnir þegar þú vilt athuga það túpu sem er í undirfyrirspurninni. Þetta er eitthvað sem ég persónulega saknaði í öðrum gagnagrunnum. Ef ég vil bera eitthvað saman við undirfyrirspurn, þá er aðeins hægt að bera saman skalar í öðrum gagnagrunnum við það, en fyrir nokkra dálka þarf ég að skrifa JOIN. Í smellahús þú getur notað tuple:

SELECT *
  FROM cpu 
 WHERE (tags_id, created_at) IN 
    (SELECT tags_id, max(created_at)
        FROM cpu 
        GROUP BY tags_id)

Önnur aðferðin gerir það sama en notar samansafnað fall argMax:

SELECT 
    argMax(usage_user), created_at),
    argMax(usage_system), created_at),
...
 FROM cpu 

В smellahús það eru nokkrir tugir samanlagðra aðgerða og ef þú notar combinator þá færðu um þúsund þeirra samkvæmt lögmálum combinatorics. ArgMax - ein af aðgerðunum sem reiknar út hámarksgildi: beiðnin skilar gildinu usage_user, þar sem hámarksgildi er náð búið_hjá:

SELECT now() as created_at,
       cpu.*
  FROM (SELECT DISTINCT tags_id from cpu) base 
  ASOF LEFT JOIN cpu USING (tags_id, created_at)

ASOF JOIN — „líma“ raðir með mismunandi tímum. Þetta er einstakur eiginleiki fyrir gagnagrunna sem er aðeins fáanlegur í kdb+. Ef það eru tvær tímaraðir með mismunandi tíma, ASOF JOIN gerir þér kleift að færa og sameina þau í einni beiðni. Fyrir hvert gildi í einni tímaröð finnst næst gildi í hinni og þeim er skilað á sömu línu:

Greiningaraðgerðir

Í staðlinum SQL-2003 þú getur skrifað svona:

SELECT origin,
       timestamp,
       timestamp -LAG(timestamp, 1) OVER (PARTITION BY origin ORDER BY timestamp) AS duration,
       timestamp -MIN(timestamp) OVER (PARTITION BY origin ORDER BY timestamp) AS startseq_duration,
       ROW_NUMBER() OVER (PARTITION BY origin ORDER BY timestamp) AS sequence,
       COUNT() OVER (PARTITION BY origin ORDER BY timestamp) AS nb
  FROM mytable
ORDER BY origin, timestamp;

В smellahús Þú getur ekki gert það - það styður ekki staðalinn SQL-2003 og mun líklega aldrei gera það. Í staðinn, í smellahús Venjan er að skrifa svona:

Ég lofaði lambdunum - hér eru þær!

Þetta er hliðstæða greiningarfyrirspurnarinnar í staðlinum SQL-2003: hann telur muninn á þessu tvennu tímastimpill, lengd, raðtala - allt sem við teljum venjulega greiningaraðgerðir. IN smellahús Við teljum þau í gegnum fylki: fyrst drögum við saman gögnin í fylki, eftir það gerum við allt sem við viljum á fylkinu og stækkum það svo aftur. Það er ekki mjög þægilegt, það krefst ást á hagnýtri forritun í lágmarki, en það er mjög sveigjanlegt.

Sérstakar aðgerðir

Að auki, í smellahús margar sérhæfðar aðgerðir. Til dæmis, hvernig á að ákvarða hversu margar lotur eiga sér stað samtímis? Dæmigert eftirlitsverkefni er að ákvarða hámarksálag með einni beiðni. IN smellahús Það er sérstök aðgerð í þessu skyni:

Almennt séð hefur ClickHouse sérstakar aðgerðir í mörgum tilgangi:

• runningDifference, runningSafna, nágranni;
• sumMap(lykill, gildi);
• timeSeriesGroupSum(uid, timestamp, value);
• timeSeriesGroupRateSum(uid, timestamp, value);
• skewPop, skewSamp, kurtPop, kurtSamp;
• MEÐ FYLLU / MEÐ BINDUM;
• simpleLinearRegression, stochasticLinearRegression.

Þetta er ekki tæmandi listi yfir aðgerðir, það eru 500-600 alls. Ábending: allar aðgerðir í smellahús er í kerfistöflunni (ekki eru allar skjalfestar, en allar áhugaverðar):

select * from system.functions order by name

smellahús það geymir mikið af upplýsingum um sjálft sig, þar á meðal log töflur, fyrirspurnarskrá, rekjaskrá, skrá yfir aðgerðir með gagnablokkum (part_log), mælingaskrá og kerfisskrá, sem það skrifar venjulega á disk. Log mæligildi er tímaröð в smellahús reyndar smellahús: Gagnagrunnurinn sjálfur getur gegnt hlutverki tímaröð gagnagrunna, og „eyðir“ þannig sjálfum sér.

Þetta er líka einstakur hlutur - þar sem við vinnum gott starf fyrir tímaröð, af hverju getum við ekki geymt allt sem við þurfum innra með okkur? Við þurfum ekki Prometheus, við höldum öllu fyrir okkur sjálf. Tengdur grafana og við fylgjumst með sjálfum okkur. Hins vegar, ef smellahús fellur, við munum ekki sjá hvers vegna, svo þeir gera það venjulega ekki.

Stór klasi eða margir litlir smellahús

Hvað er betra - einn stór þyrping eða mörg lítil ClickHouses? Hefðbundin nálgun við DWH er stór þyrping þar sem hringrásum er úthlutað fyrir hverja umsókn. Við komum til gagnagrunnsstjórans - gefðu okkur skýringarmynd og þeir gáfu okkur eina:

В smellahús þú getur gert þetta öðruvísi. Þú getur gert hvert forrit að þínu eigin smellahús:

Við þurfum ekki stóra voðalega lengur DWH og óleysanlegir stjórnendur. Við getum gefið hverri umsókn sína smellahús, og verktaki getur gert það sjálfur, þar sem smellahús mjög auðvelt að setja upp og krefst ekki flóknar stjórnun:

En ef við eigum mikið smellahús, og þú þarft að setja það upp oft, þá viltu gera þetta ferli sjálfvirkt. Til þess getum við til dæmis notað Kubernetes и smellahús-rekstraraðili. IN Kubernetes ClickHouse þú getur sett það „á smell“: ég get smellt á hnapp, keyrt upplýsingaskrána og gagnagrunnurinn er tilbúinn. Ég get strax búið til skýringarmynd, byrjað að hlaða upp mæligildum þangað og eftir 5 mínútur er ég með mælaborð tilbúið grafana. Það er svo einfalt!

Niðurstaðan?

Svo, smellahús - þetta er:

• Hratt. Þetta vita allir.
• Einfaldlega. Svolítið umdeilt, en ég tel að það sé erfitt í þjálfun, auðvelt í bardaga. Ef þú skilur hvernig smellahús það virkar, þá er allt mjög einfalt.
• Alheims. Það er hentugur fyrir mismunandi aðstæður: DWH, Time Series, Log Storage. En svo er ekki OLTP gagnagrunn, svo ekki reyna að setja inn stutt innskot og lesa þar.
• Athyglisvert. Sennilega sá sem vinnur með smellahús, upplifði margar áhugaverðar stundir í góðum og slæmum skilningi. Til dæmis kom ný útgáfa, allt hætti að virka. Eða þegar þú glímir við verkefni í tvo daga, en eftir að hafa spurt spurninga í Telegram spjalli, var verkefnið leyst á tveimur mínútum. Eða eins og á ráðstefnunni í skýrslu Lesha Milovidov, skjáskot frá smellahús braut útsendinguna HighLoad++. Svona hlutir gerast alltaf og gera líf okkar erfitt. smellahús björt og áhugaverð!

Hægt er að horfa á kynninguna hér.

Langþráður fundur þróunaraðila háálagskerfa kl HighLoad++ fer fram 9. og 10. nóvember í Skolkovo. Að lokum verður þetta ráðstefna án nettengingar (að vísu með allar varúðarráðstafanir), þar sem ekki er hægt að pakka orku HighLoad++ á netinu.

Fyrir ráðstefnuna finnum við og sýnum þér dæmi um hámarksgetu tækninnar: HighLoad++ var, er og verður eini staðurinn þar sem þú getur lært á tveimur dögum hvernig Facebook, Yandex, VKontakte, Google og Amazon virka.

Eftir að hafa haldið fundi okkar án truflana síðan 2007, munum við hittast í 14. sinn í ár. Á þessum tíma hefur ráðstefnan stækkað 10 sinnum; á síðasta ári kom lykilatburður iðnaðarins saman 3339 þátttakendur, 165 fyrirlesara, skýrslur og fundi og 16 lög voru í gangi samtímis.
Í fyrra voru 20 rútur, 5280 lítrar af te og kaffi, 1650 lítrar af ávaxtadrykkjum og 10200 flöskur af vatni. Og önnur 2640 kíló af mat, 16 diska og 000 bolla. Við the vegur, með peningana sem safnað var úr endurunnum pappír, gróðursettum við 25 eikarplöntur :)

Hægt er að kaupa miða hér, fáðu fréttir af ráðstefnunni - hér, og talaðu á öllum samfélagsnetum: Telegram, Facebook, VKontakte и twitter.

Heimild: www.habr.com