Liigume ClickHouse'i: 3 aastat hiljem

Kolm aastat tagasi rääkisid Viktor Tarnavski ja Aleksei Milovidov Yandexist laval HighLoad++ rääkinud, kui hea ClickHouse on ja kui sujuvalt see töötab. Samal ajal oli kõrvalsel laval Aleksandr Zaitsev jot ettekanne üleminekust ClickHouse teisele analüüsisüsteemile ja tulemuseks oli see, et ClickHouse, muidugi, see on hea, kuid mitte kõige mugavam. Kui 2016. aastal ettevõte LifeStreet, kus Aleksandr tol ajal töötas, tõlkis mitme petabaiti analüüsisüsteemi ClickHouse, oli see põnev "kollase tellise tee", täis tundmatuid ohte — ClickHouse tollal nägi see välja nagu miiniväli.

Kolm aastat hiljem ClickHouse on palju parem — selle aja jooksul asutas Aleksandr ettevõtte Altinity, mis mitte ainult ei aitaüleminekuid teha ClickHouse kümnete projektide jaoks, vaid täiustab ka toodet koos kolleegidega Yandexist. Praegu ClickHouse pole see enam muretu jalutuskäik, kuid see ei ole ka miiniväli.

Aleksandr on tegelenud jagatud süsteemidega 2003. aastast, töötanud suurtes projektides MySQL, Oracle ja Vertica. Möödunud HighLoad++ 2019 Aleksandr, üks pioneeridest, kes kasutas ClickHouse, rääkis, milline see andmebaas praegu on. Uurime selle peamisi omadusi ClickHouse: millega see erineb teistest süsteemidest ja millistes olukordades on seda efektiivsem kasutada. Vaatame näiteid värskete ja katsetatud praktikate kohta süsteemide loomisel ClickHouse.

Tagasivaade: mis toimus 3 aastat tagasi

Kolm aastat tagasi tegime ülemineku ettevõttelt LifeStreet . Tundub, et ClickHouse teisele analüüsibaasile ja reklaamivõrgu analüüsi migratsioon nägi välja järgmiselt:

• Juuni 2016. Avati OpenSource ja käivitasime oma projekti; ClickHouse August.
• Proof Of Concept : suur reklaamivõrk, infrastruktuur ja 200-300 terabaidi andmeid;Oktoober. Esimesed tootmised andmed;
• Detsember. Täielik koormus — 10-50 miljardit sündmust päevas.
• Juuni 2017. Kasutajate edukas üleviimine
• , 2,5 petabaiti andmeid 60 serverist koosnevas klastris. ClickHouseMigratsiooni käigus kasvas teadlikkus, et

see on hea süsteem, millega on meeldiv töötada, kuid see on Yandexi sisemine projekt. Seega on teatud nüansid: Yandex tegeleb esmalt oma sisemiste tellijatega, ja alles seejärel kogukonna ja välistarbijate vajadustega, ning ClickHouse ei vastanud siis paljudes funktsionaalsetes valdkondades ettevõtte tasemele. Seetõttu asutasime 2017. aasta märtsis ettevõtte Altinity, et teha ClickHouse — see on tore süsteem, millega on meeldiv töötada, kuid see on Yandexi sisemine projekt. Seetõttu on teatud nüansid: Yandex tegeleb esmalt oma sisemiste klientidega ja alles seejärel väliskogukonna ja väliste kasutajate vajadustega, ning ClickHouse ei ulatunud toona paljude funktsionaalsete valdkondade osas ettevõtte tasemeni. Seetõttu asutasime 2017. aasta märtsis ettevõtte Altinity, et luua ClickHouse veel kiirem ja mugavam mitte ainult Yandexile, vaid ka teistele kasutajatele. Ja nüüd me:

• Koolitame ja aitame lahendusi luua ClickHouse nii, et tellijad ei saaks peksa ja lahendus toimiks lõpuks;
• Pakume 24/7 tuge ClickHouse-paigaldustele;
• Arendame oma ökosüsteemi projekte;
• Aktiivselt panustame sellesse ClickHouse, vastates kasutajate soovidele, kes tahavad näha teatud funktsioone.

Ja muidugi, me aitame üleminekul ClickHouse jot MySQL, Vertica, Oracle, Greenplum, Redshift ja teistesse süsteemidesse. Oleme osalenud väga erinevates üleminekutes ja kõik need on olnud edukad.

Miks üldse üleminek teha ClickHouse

Ei pidurda! See on peamine põhjus. ClickHouse — väga kiire andmebaas erinevate stsenaariumide jaoks:

Juhuslikud tsitaadid inimestelt, kes on pikka aega töötanud ClickHouse.

Skaleeritavus. Teises andmebaasis võib saavutada korralikku jõudlust ühel raual, kuid ClickHouse saab skaleerida mitte ainult vertikaalselt, vaid ka horisontaalselt, lihtsalt lisades servereid. Kõik ei toimi nii sujuvalt, kui sooviks, aga töötab. Süsteemi saab kasvatada koos äri kasvuga. On oluline, et me ei ole praeguses lahenduses piiratud ja potentsiaal arenguks on alati olemas.

Kandmiseks. Ei ole sidet millegi kindlega. Näiteks, kui Amazon Redshift on raske kuhugi üleminek teha. Aga ClickHouse võib paigaldada oma sülearvutile, serverisse, rakendada pilve, liikuda Kubernetes — ei ole piiranguid infrastruktuuri kasutamiseks. See on mugav kõigile ning see on suur eelis, millega ei saa kiidelda paljud teised sarnased andmebaasid.

Paindlikkus. ClickHouse ei seisa millegi ühes asjas, näiteks Yandex.Metrikas, vaid areneb ja kasutatakse üha rohkemates erinevates projektides ja valdkondades. Seda saab laiendada, lisades uusi võimalusi uute ülesannete lahendamiseks. Näiteks, arvatakse, et logide hoidmine andmebaasis on halb tava, seega selleks on välja mõeldud Elasticsearch. Kuid tänu paindlikkusele ClickHouse, on seal ka võimalik logisid hoida ja sageli on see isegi parem kui Elasticsearch — ClickHouse selleks on vaja 10 korda vähem riistvara.

Tasuta Open Source. Ei ole vaja millegi eest maksta. Ei ole vaja kokku leppida, et paigaldada süsteem oma sülearvutisse või serverisse. Ei ole varjatud makseid. Selle juures ei saa ükski teine avatud koodiga andmebaasitehnoloogia kiiruselt konkurentsi pakkuda ClickHouse. MySQL, MariaDB, Greenplum — kõik need on palju aeglasemad.

Kogukond, ajend ja lõbu. Meie ClickHouse suurepärane kogukond: kohtumised, vestlused ja Aleksei Milovidov, kes laadib meid kõiki oma energia ja optimismiga.

Ränne ClickHouse'ile

Et minna üle ClickHouse millegilt, on vaja vaid kolme asja:

• Mõista piiranguid ClickHouse ja mille jaoks see ei sobi.
• Kasutada tehnoloogia eeliseid ja selle kõige tugevamaid külgi.
• Katsetada. Isegi mõistes, kuidas see töötab ClickHouse, ei ole alati võimalik ennustada, millal see on kiirem, millal aeglasem, millal parem ja millal halvem. Seetõttu proovige.

Rände probleem

On ainult üks "aga": kui lähete üle ClickHouse millegi teisest, siis tavaliselt läheb midagi valesti. Oleme harjunud teatud praktikate ja asjadega, mis töötavad meie lemmikandmebaasis. Näiteks arvab iga inimene, kes töötab SQL-andmebaasidega, et selline funktsioonide hulk on kohustuslik:

• tehingud;
• piirangud;
• järjepidevus;
• indeksid;
• UPDATE/DELETE;
• NULLid;
• millisekundid;
• automaatne tüüpide muundamine;
• mitmekordsed liitmine;
• juhuslikud partitsioonid;
• klastrihaldusvahendid.

Nii et komplekt on kohustuslik, kuid kolm aastat tagasi ei olnud ClickHouse ühtki neist funktsioonidest! Praegu on realiseerimata jäänud vähem kui pool: tehingud, piirangud, järjepidevus, millisekundid ja tüüpide muundamine.

Ja kõige tähtsam — et mõned standardpraktikad ja lähenemised ei tööta või ei tööta nii, nagu me harjunud oleme. Kõik, mis ilmub ClickHouse , vastab " ClickHouseClickHouse'i viis", st funktsioonid erinevad teistest andmebaasidest. Näiteks:Indeksid ei vali, vaid jätavad vahele.

• Ei ole sünkroneid, vaid asünkroneid.
• UPDATE/DELETE Mitmekordsed liitmine on olemas, kuid päringute planeerija puudub. Kuidas need siis täidetakse, ei ole andmebaasi maailmast inimestele üldse selge.
• ClickHouse'i stsenaariumid

1960. aastal kirjutas Ameerika matemaatik Ungari päritolu

Wigner E. P. artikli " Matemaatika ebaaus tõhusus loodusvaldkondades" ("Matemaatika ebaaus tõhusus loodusvaldkondades") selle kohta, et ümbritsev maailm on imelikul kombel hästi kirjeldatav matemaatiliste seadustega. Matemaatika on abstraktne teadus, ja füüsikalised seadused, mis on väljendatud matemaatilises vormis, ei ole triviaalne, ningtoonitas, et see on väga kummaline. artikli " Minu arvates on

— sama kummalisus. Wignerit parafraseerides võib öelda nii: üllatavalt ebaaus tõhusus ClickHouse erinevates analüütilistes rakendustes! ClickHouse Näiteks võtame

Reaalajas andmete laod Reaalajas Andmehoidla, mille andmed laaditakse praktiliselt katkematult. Soovime saada sellelt päringuid ühe sekundi viivitusega. Palun — kasutame ClickHouse, sest selle stsenaariumi jaoks on ta välja töötatud. ClickHouse just nii kasutatakse seda mitte ainult veebis, vaid ka turunduse ja finantsanalüüsis, AdTech, samuti Fraud detection. Siin Reaalajas andmehoidla kasutab keerukat struktureeritud skeemi, mis on kas «täht» või «lumehelves», palju tabeleid JOIN (mõnikord ka mitme järjestusega), ja andmed tavaliselt hoitakse ja muudetakse mingites süsteemides.

Võtame teise stsenaariumi — Aja seeria: seadmete, võrkude, kasutusstatistika jälgimine, asjade internet. Siin kohtame ajaliselt järjestatud suhteliselt lihtsaid sündmusi. ClickHouse selleks ei olnud algselt välja töötatud, kuid on näidanud head tulemust, seega kasutavad suured ettevõtted ClickHouse seda jälgimisinfohoidla jaoks. Et uurida, kas ClickHouse sobib aja seeriaks, tegime testimise põhjal lähenemist ja tulemusi InfluxDB ja TimescaleDB — spetsialiseeritud aja seeria andmebaasid. Selgus, et ClickHouse, et isegi ilma selliste ülesannete optimeerimiseta, saavutab ta edumaa ka teistel maadel:

Uues aja seeria tavaliselt kasutatakse kitsast tabelit — paar väikest veergu. Jälgimisest võib tulla väga palju andmeid — miljoneid kirjeid sekundis — ja neid tavaliselt saadetakse väikeste sisestuste kaupa (reaalajas voogedastusega). Seetõttu on vajalik teine sisestusstsenaarium, ja iseärasused on ka päringutel.

Logihaldus. Logide kogumine andmebaasi — see on tavaliselt halb, kuid ClickHouse seda saab teha mõningate märkustega, nagu eespool kirjeldatud. Paljud ettevõtted kasutavad ClickHouse just selleks. Sellisel juhul kasutatakse tasapinnalist laia tabelit, kus hoiame logisid tervikuna (näiteks JSON), või jagame need osadeks. Andmed laaditakse tavaliselt suurte partiitide (failide) kaupa ja otsitakse mõne välja järgi.

Iga nende funktsioonide jaoks kasutatakse tavaliselt spetsialiseeritud andmebaase. ClickHouse kuid üks võib kõike seda teha nii hästi, et ületab neid tulemuslikkuses. Vaatame nüüd lähemalt aja seeria stsenaariumit ja kuidas õigesti «ette valmistada» ClickHouse seda stsenaariumi.

Aja seeria

Praegu on see peamine stsenaarium, mille jaoks ClickHouse peetakse standardlahenduseks. Aja seeria on ajakohaste sündmuste kogum, mis kujutab mingisuguse protsessi muutusi ajas. Näiteks võib see olla südametegevuse sagedus päeva jooksul või protsesside arv süsteemis. Kõik, mis annab ajatilkude mõõtmisi, on aja seeria:

Seda tüüpi sündmusi tuleb kõige rohkem jälgimisest. See ei pruugi olla ainult veebijälgimine, vaid ka reaalsed seadmed: autod, tööstussüsteemid, IoT, tootmisüksused või isesõitvad taksod, mille pagasiruumi Yandex juba praegu paneb ClickHouse-server.

Näiteks on olemas ettevõtteid, mis koguvad andmeid laevadelt. Iga paari sekundi järel saadavad konteinerlaeva sensorid sadu erinevaid mõõtmisi. Insenerid uurivad neid, loovad mudeleid ja proovivad mõista, kui tõhusalt kasutatakse laeva, kuna konteinerlaev ei tohiks jääda seisma sekundi kaupa. Iga seismine tähendab rahakaotust, seetõttu on oluline prognoosida marsruuti nii, et peatused oleksid minimaalsed.

Praegu on näha spetsialiseeritud andmebaaside kasvu, mis mõõdavad aja seeria. Veebisaidil DB-Engines järgmisel viisil järjestatakse erinevaid andmebaase, millest neid saab vaadata liikide järgi:

Kiireim kasvav liik on aeg-seeriad. Samuti kasvavad graafikud andmebaasid, kuid aeg-seeriad on viimase paari aasta jooksul kasvanud kiiremini. Selle pereliikme tüüpilised esindajad on InfluxDB, Prometheus, KDB, TimescaleDB (ehitatud PostgreSQL), lahendused firmalt Amazon. ClickHouse on siin samuti kasutusel ja seda kasutatakse. Too mõned avalikud näited.

Üks pioneeridest on ettevõte CloudFlare (CDN-teenuse pakkuja). Nad jälgivad oma CDN läbi ClickHouse (DNS-küsimusi, HTTP-taotlusi) tohutu koormusega - 6 miljonit sündmust sekundis. Kõik läheb läbi Kafka, saadetakse ClickHouse, mis pakub reaalajas võimalust näha süsteemi sündmuste juhtpaneele.

Comcast on üks USA juhtivaid telekommunikatsiooniettevõtteid: Internet, digitaaltelevisioon, telefoniteenus. Nad lõid sarnase juhtimisse süsteemi CDN Apache Traffic Control Open Source projekti oma tohutute andmete haldamiseks. kasutatakse analüütika taustsüsteemina. ClickHouse Percona

integreeris oma ClickHouse PMM , et salvestada erinevatespetsiifilisi nõudeid. Aeg-seeria andmebaasidel on omad spetsiifilised nõuded. MySQL.

Kiire andmete sisestamine paljusid agentaid. Me peame väga kiiresti sisestama andmeid paljusid vooge.

teeb seda hästi, kuna sellel on kõik sisestamised, mis ei blokeeri. Igaüks

• Kiire sisestamine paljusid agendeid pidi. Me peame väga kiiresti andmeid paljusidest voogudest sisestama. ClickHouse teeb seda hästi, kuna kõik sisestamised ei blokeeri midagi. Igaüks sisestage — see on uus fail kettal ja väiksele sisestusele saab kasutada vahemälu erinevatel viisidel. ClickHouse Andmeid on parem sisestada suurte pakkidena, mitte ühe reana.
• Paindlik skeem. Failis aja seeria me ei tea tavaliselt andmete struktuuri lõpuni. Saame luua jälgimissüsteemi konkreetse rakenduse jaoks, kuid siis on seda raske kasutada teise rakenduse jaoks. Selleks on vaja paindlikumat skeemi. ClickHouse, see võimaldab seda teha, isegi kui tegemist on rangelt tüübistatud andmebaasiga.
• Tõhus andmete salvestamine ja „unustamine”. Tavaliselt on aja seeria hiiglaslik andmemaht, seega tuleb neid salvestada maksimaalse efektiivsusega. Näiteks, InfluxDB hea tihendus on selle põhifunktsioon. Kuid lisaks salvestamisele tuleb ka vanu andmeid „unustada” ja teha mingit allapoole näitamine — automaatne arvutamine kogumite jaoks.
• Kiired päringud kogutud andmetele. Va sometimes tahaksime vaadata viimase 5 minuti jooksul, täpsusega millisekundilise, kuid kuupõhiste andmete puhul võib minuti või sekundi granulaarsus olema ebavajalik — piisab üldstatistikast. Sellise toetuse olemasolu on vajalik, vastasel juhul kestab 3 kuu päring väga kaua, isegi ClickHouse.
• Päringud nagu “viimane punkt, kuupäev». Need on tüüpilised aja seeria päringud: vaatame viimast mõõtmist või süsteemi seisundit antud ajahetkel t. Andmebaaside jaoks ei ole need päringud eriti meeldivad, kuid neid tuleb ka osata teha.
• Aja ridade „liimimine”. Aja seeria — see on ajaline rida. Kui on olemas kaks ajalist rida, tuleb need sageli ühendada ja korreleerida. Kõikide andmebaaside puhul ei ole see mugav, eriti mitteühtlaste ajaliste ridade korral: siin — on ühed ajamärgid, seal — teised. Võib arvutada keskmisi, kuid äkki seal on ikkagi auk, seega pole selge.

Vaadakem, kuidas need nõuded on täidetud ClickHouse.

Schema

Uues ClickHouse skeemi jaoks aja seeria saab teha erinevate viiside kaudu, sõltuvalt andmete regulaarsete olemuse astmest. Võime luua süsteemi regulaarsete andmete jaoks, kui me teame kõiki mõõtmeid ette. Näiteks on nii teinud CloudFlare jälgimisega CDN — see on hästi optimeeritud süsteem. Saame luua üldisema süsteemi, mis jälgib kogu infrastruktuuri, erinevaid teenuseid. Ebaregulaarsete andmete puhul ei tea me ette, mida jälgime — ja tõenäoliselt on see kõige üldisem juhtum.

Regulaarsed andmed. Veerud. Skeem on lihtne – veerud soovitud tüüpidega:

LOOD 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);

See tavaliselt tabel, mis jälgib mingit süsteemi koormuse aktiivsust (kasutaja, system, üksik, nice). Lihtne ja mugav, kuid mitte paindlik. Kui soovime paindlikumat skeemi, saame kasutada massiive.

Ebaregulaarne teave. Massiivid:

LOOD 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);

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

Struktuur Nested — need on kaks massiivi: metrics.name ja metrics.value. Siin saab hoida selliseid väljakutsuvaid monitooringuandmeid nagu nimede massiiv ja mõõtmiste massiiv iga sündmuse puhul. Edasiseks optimeerimiseks võib selle struktuuri asemel teha mitu. Näiteks üks — tekst-väärtus, teine — int-väärtus, sest int tahaks efektiivsemalt hoida.

Kuid sellise struktuuriga on keerulisem tegutseda. Tuleb kasutada erilist konstruktsiooni, et spetsiaalsete funktsioonidega välja tuua väärtusi esmalt indeksi, seejärel massiivi kaudu:

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

Kuid see töötab ikkagi piisavalt kiiresti. Teine viis ebaregulaarses andmete hoidmiseks on ridade kaupa.

Ebaregulaarne teave. Rida. Selle traditsioonilise meetodi puhul hoitakse koheselt pealkirju ja väärtusi ilma massiivideta. Kui ühest seadmest tuleb korraga 5 000 mõõtmist — genereeritakse andmebaasis 5 000 rida:

LOOD 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);


VALI 
    maxIf(metric_value, metric_name = 'usage_user'),
    ... 
FROM cpu_r
KUS metric_name IN ('usage_user', ...)

ClickHouse sellega tõhus - tal on erilised laiendused ClickHouse SQL. Näiteks, maxIf — erifunktsioon, mis arvutab maksimumit mõõte korral, kui mingid tingimused on täidetud. Ühes päringus saab kirjutada mitu sellist väljendit ja koheselt korraga arvutada mitme mõõtme väärtuse.

Võrdleme kolme lähenemist:

Detailid

Siin lisasin "Andmete maht kettal" mõne testandmestiku jaoks. Veergude puhul on meil kõige väiksem andmehulga suurus: maksimaalne tihendamine, maksimaalne päringute kiirus, kuid maksame selle eest sellega, et peame kõik korraga fikseerima.

Massiivide puhul on kõik pisut halvem. Andmed tihenduvad siiski hästi ja võib hoida ebaühtlast skeemi. Kuid ClickHouse — veergude andmebaas, ja kui hakkame kõike massiivi salvestama, muutub see stringiks ning maksame paindlikkuse eest efektiivsusega. Igaks toiminguks tuleb lugeda kogu massiiv mälu, pärast seda leida sealt sobiv element — ja kui massiiv kasvab, siis kiirus halveneb.

Ühes ettevõttes, kes kasutab sellist lähenemist (näiteks Uber), jagatakse massiivid 128 elemendi tükkideks. Tuhandeid mõõtmeid mahus 200 TB andmeid/päevas ei hoita ühes massiivis, vaid 10 või 30 massiivis koos spetsiaalse loogikaga säilitamiseks.

Vähemalt lihtne lähenemine — stringidega. Kuid andmed tihenduvad halvasti, tabeli suurus on suur, ja kui päringud lähevad läbi mitmete mõõtmete, siis ClickHouse töötab mitteoptimaalselt.

Hübriidskeem

Oletame, et valisime massiivide skeemi. Kuid kui me teame, et enamik meie armatuurlaudu näitavad ainult user ja system mõõtmeid, saame täiendavalt massiivist tabeli tasandil need mõõtmed veergudeks materialiseerida järgmiselt:

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);

Sisestamisel ClickHouse arvutab need automaatselt. Nii on võimalik ühendata meeldiv kasuliku: skeem on paindlik ja üldine, kuid kõige sagedamini kasutatavad veerud oleme välja toonud. Tõin välja, et see ei nõudnud sisestamise muutmist ja ETL, mis jätkab massiivide sisestamist tabelisse. Me lihtsalt tegime ALTER TABLE, lisasime paar veergu ja saime hübriidse ja kiirema skeemi, millega saab kohe alustada kasutamist.

Koodekid ja tihendamine

Tooge aja seeria on oluline, kui hästi te andmeid pakendate, sest info massiiv võib olla väga suur. V ClickHouse on saadaval vahendid kompressiooniefekti saavutamiseks suhe 1:10, 1:20 ja mõnikord isegi rohkem. See tähendab, et pakendamata 1 TB andmed kettal võtavad 50-100 GB. Väiksem maht on hea, andmeid saab kiiremini lugeda ja töödelda.

Kõrge kompressioonitaseme saavutamiseks, ClickHouse toetab järgmisi koodekeid:

Näide tabelist:

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);

Siin määratleme koodeki DoubleDelta ühes olukorras, teises — Gorilla, ja me peame kindlasti lisama veel LZ4 kompressiooni. Selle tulemusena andmete maht kettal väheneb oluliselt:

Siin on näidatud, kui palju ruumi võtab sama andmete kogus, kuid erinevate koodekite ja kompressioonidega:

• GZIPitud fail kettal;
• ClickHouse'is ilma koodekideta, kuid ZSTD-kompressiooniga;
• ClickHouse'is koos koodekite ja LZ4 ning ZSTD kompressiooniga.

On näha, et koodekitega tabelid võtavad palju vähem ruumi.

Suurus on oluline

Vähemalt sama oluline valida õige andmetüüp:

Kõikides ülaltoodud näidetes olen kasutanud Float64. Kuid kui oleksime valinud Float32, siis oleks see olnud isegi parem. Seda on hästi demonstreerinud inimesed Perkonast artiklis, mis on üleval linkides. Oluline on kasutada võimalikult kompaktset tüüpi, mis sobib ülesande jaoks: isegi vähem kettaruumi kui päringute kiirus. ClickHouse on sellele väga tundlik.

Kui saate kasutada int32 asemel int64, siis oodake peaaegu kahekordset jõudluse suurenemist. Andmed võtavad vähem mälu ja kogu "aritmeetika" töötab palju kiiremini. ClickHouse iseenesest — väga rangelt tüübistatud süsteem, mis kasutab maksimaalselt ära kõiki kaasaegsete süsteemide võimalusi.

Agregeerimine ja Materialiseeritud vaated

Agregeerimine ja materialiseeritud vaated võimaldavad luua agregaatide variatsioone erinevate elusituatsioonide jaoks:

Näiteks võivad teil olla mitteaggregeeritud algandmed, millele saab siduda erinevaid materialiseeritud vaateid automaatse summeerimisega spetsiaalse mootoriga SummingMergeTree (SMT). SMT on spetsiaalne aggregeeriv andmestruktuur, mis arvutab aggregeeritud andmed automaatselt. Andmebaasi sisestatakse toorandmed, need aggregeeritakse automaatselt ja nende põhjal saab kohe kasutada juhtpaneele.

TTL unustame vanad andmed

Kuidas unustada andmeid, mida enam ei vajata? ClickHouse oskab seda. Tabelite loomisel saab määrata TTL avaldised: näiteks salvestame minutilised andmed üheks päevaks, päevased — 30 päevaks, kuid nädalased või kuised ei puutu kunagi:

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 */

Mitme tasandi jagame andmeid ketaste vahel

Seda ideed arendades saab andmeid hoida ClickHouse erinevates kohtades. Oletame, et tahame viimase nädala kuumi andmeid hoida väga kiirel kohalikul SSD, samas kui vanemad ajaloolised andmed paigutatakse mujale. See on ClickHouse praegu võimalik:

Saame konfigureerida ladustamispoliitika (storage policy) nii, et ClickHouse ülekandab andmed automaatselt mõnede tingimuste täitmisel teise salvestusse.

Kuid see ei ole veel kõik. Konkreetse tabeli tasandil saab määratleda reeglid, millal andmed ajaliselt külmasse ladustamisse liiguvad. Näiteks, 7 päeva andmed asuvad väga kiirel kettal, ja kõik, mis on vanem, kantakse aeglasele. See on hea, kuna see võimaldab süsteemi hoida maksimaalses jõudluses, samal ajal kulusid kontrollides ja mitte raisates raha külmadele andmetele:

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

Ainulaadsed võimalused ClickHouse

Peaaegu kõikides ClickHouse on sellised "erilised omadused", kuid need tasakaalustatakse eksklusiivsusega — millegi olemasoluga, mida teistes andmebaasides ei ole. Näiteks siin on mõned ainulaadsed funktsioonid ClickHouse:

• Massiivid. Failis ClickHouse väga hea toetus massiividele ning ka võimalus teha nende peal keerulisi arvutusi.
• Aggregeerivad andmestruktuurid. See on üks "müügipunkte" ClickHouse. Kuigi Yandexi tüübid ütlevad, et me ei soovi andmeid aggregeerida, aggregeerib kõik ClickHouse, kuna see on kiire ja mugav.
• Materialiseeritud vaated. Koos koos aggregatiivsete andmestruktuuridega võimaldavad materialiseeritud vaated mugavalt reaalajas aggregatsiooni.
• ClickHouse SQL. See on keele laiendus SQL mõnedelt lisafunktsioonidelt, mis on saadaval ainult ClickHouse. Varem oli see teatud mõttes nii laiendus kui ka puudus. Nüüd oleme peaaegu kõik puudused võrreldes SQL 92 ära kõrvaldanud, nüüd on see ainult laiendus.
• Lambda-väljendid. Kas need on veel mingis andmebaasis?
• ML-toetuse. Seda leidub erinevates andmebaasides, mõnedes paremini, mõnes halvasti.
• Avaalne kood. Me saame laiendada ClickHouse koos. Praegu on ClickHouse umbes 500 ühendajat ja see arv kasvab pidevalt.

Kavalad päringud

Uues ClickHouse on palju erinevaid viise sama asja tegemiseks. Näiteks saab viimast väärtust tabelist tuua kolme erineva meetodi abil CPU (on veel neljas, kuid see on veel eksootilisem).

Esimene näitab, kui mugav on seda teha ClickHouse päringutes, kui soovite kontrollida, et tulp on alampäringus. Seda oli isiklikult teistes andmebaasides väga puudu. Kui soovin midagi alampäringuga võrrelda, siis teistes andmebaasides saab selle võrrelda ainult skalaariga, kuid mitme veeru jaoks tuleb kirjutada JOIN. Failis ClickHouse saab kasutada tulpa:

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

Teine meetod teeb sama asja, kuid kasutab agregaatfunktsiooni argMax:

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

Uues ClickHouse olemas mitu tosinat agregaatfunktsiooni, ja kui kasutada kombinatoore, siis nende seaduste kohaselt on neid umbes tuhat. ArgMax on üks funktsioonidest, mis arvutab maksimaalse väärtuse: päring tagastab väärtuse usage_user, mille korral saavutatakse maksimaalne väärtus created_at:

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 on erineva ajaga ridade "liitmine". See on ainulaadne funktsioon andmebaaside jaoks, mida leidub ainult kdb+. Kui on kaks ajajoonte rida erineva ajaga, ASOF JOIN võimaldab neid nihutada ja ühes päringus liita. Iga väärtuse puhul ühel ajajoonte reas leitakse lähim väärtus teises ja need tagastatakse ühel real:

Analüütilised funktsioonid

Standardis SQL-2003 saab kirjutada nii:

VALI origin,
       timestamp,
       timestamp -LAG(timestamp, 1) OVER (PARTITION BY origin ORDER BY timestamp) KUI duration,
       timestamp -MIN(timestamp) OVER (PARTITION BY origin ORDER BY timestamp) KUI startseq_duration,
       RIDA_NUMBER() OVER (PARTITION BY origin ORDER BY timestamp) KUI sequence,
       COUNT() OVER (PARTITION BY origin ORDER BY timestamp) KUI nb
  FROM mytable
ORDER BY origin, timestamp;

Uues ClickHouse nii ei saa - see ei toeta standardit SQL-2003 ja tõenäoliselt ei hakka kunagi seda tegema. Selle asemel on ClickHouse tavaks kirjutada nii:

Ma lubasin lambdasid – siin need on!

See on analoog analüütilisest päringust standardis SQL-2003: see arvutab vahe kahe timestamp, duration, järjestusnumber - kõik, mida me tavaliselt analüütiliste funktsioonide puhul arvestame. Me ClickHouse loeme neid massiivide kaudu: esmalt koondame andmed massiivi, seejärel teeme massiiviga kõike, mida soovime, ja lõpuks avame tagasi. See ei ole väga mugav, nõuab armastust funktsionaalse programmeerimise vastu, vähemalt, kuid see on väga paindlik.

Spetsiaalsed funktsioonid

Lisaks on ClickHouse palju spetsialiseeritud funktsioone. Näiteks kuidas määrata, kui palju seansse kulgeb samaaegselt? Tüüpiline järelevalveülesanne – määrata maksimaalne koormus ühe päringuga. Siin on ClickHouse eriline funktsioon selle eesmärgi saavutamiseks:

Üldiselt on ClickHouse’is paljusid spetsiaalseid funktsioone:

• runningDifference, runningAccumulate, neighbor;
• sumMap(key, value);
• timeSeriesGroupSum(uid, timestamp, value);
• timeSeriesGroupRateSum(uid, timestamp, value);
• skewPop, skewSamp, kurtPop, kurtSamp;
• WITH FILL / WITH TIES;
• simpleLinearRegression, stochasticLinearRegression.

See ei ole ametlik funktsioonide nimekiri, neid on kokku 500-600. Näpunäide: kõik funktsioonid ClickHouse on süsteemitabelis (kõiki ei ole dokumenteeritud, kuid kõik on huvitavad):

select * from system.functions order by name

ClickHouse iseendaga salvestab palju teavet enda kohta, sealhulgas log tabelid, query_log, jälgimistabel, andmepakkide operatsioonide logi (part_log), mõõdiku logi ja süsteemne logi, mida ta tavaliselt kirjutab kettale. Mõõdiku logi – see on aja seeria ja ClickHouse üldiselt: ClickHouseAndmebaas ise võib enda jaoks mängida rolli aja seeria andmebaas, seeläbi "neelates" ennast ise.

See on ka ainulaadne asi - kuna teeme meie jaoks head tööd aja seeria, miks ei saa me alles hoida kõike, mis on vajalik? Me ei vaja Prometheus, me hoiame kõike enda sees. Ühendasime Grafana ja jälgime iseennast. Kuid kui ClickHouse kukub, siis me ei näe, - miks, - seetõttu ei tehta seda tavaliselt.

Suur klaster või palju väikeseid ClickHouse

Mis on parem - üks suur klaster või palju väikeseid ClickHouse? Traditsiooniline lähenemine DWH — see on suur klaster, kus iga rakenduse jaoks on eraldatud skeemid. Me pöördusime andmebaasi administraatori poole — andke meile skeem ja me saime selle:

Uues ClickHouse seda on võimalik teha ka teistmoodi. Iga rakenduse jaoks saab luua omaette ClickHouse:

Me ei vaja enam suurt, tohutut DWH ja koostöövalimat administraatorit. Me saame iga rakenduse jaoks anda omaette ClickHouse, ja arendaja saab selle ise teha, kuna ClickHouse see on väga lihtne paigaldada ja ei vaja keerulist haldust:

Kuid kui meil on palju ClickHouse, ja me peame seda sageli paigaldama, siis sooviksime selle protsessi automatiseerida. Sel juhul saame kasutada näiteks Kubernetes ja clickhouse-operaatorit. K ubernetes ClickHouse saab paigaldada „nupu klõpsuga”: ma saan vajutada nuppu, käivitada manifesti ja andmebaas on valmis. Saame kohe luua skeemi, alustada mõõdikute laadimist ja viie minutiga on mul juba valmis juhtpaneel. Grafana. Kõik on nii lihtne!

Kokkuvõttes?

Nii, ClickHouse — see on:

• Kiire. See on kõigile teada.
• Lihtne. Veidi vaieldav, aga ma arvan, et raske õppimisel, kerge lahingus. Kui mõista, kuidas ClickHouse see töötab, siis edasi on kõik väga lihtne.
• Universaalne. See sobib erinevate stsenaariumite jaoks: DWH, Aegrea, Logi Salvestamine. Kuid see ei ole OLTP andmebaas, seega ärge püüdke seal teha lühikesi sisendeid ja lugemisi.
• Huvitav. Ilmselt on see, kes töötas ClickHouse, kogenud palju huvitavaid hetki nii heas kui halvas mõttes. Näiteks uus versioon välja, kõik lakkas töötamast. Või kui sa vaevasid ülesande kallal kaks päeva, kuid pärast küsimust Telegrami vestluses lahendati see kahe minutiga. Või kuidas konverentsil Aleksei Milovidovi ettekandes purunes ekraan ClickHouse . Sellised asjad juhtuvad pidevalt ja muudavad meie elu HighLoad++värvikaks ja huvitavaks! ClickHouse Esitluse saab vaadata

Oodatud kohtumine kõrgkoormuslike süsteemide arendajatega siin.

toimub 9. ja 10. novembril Skolkovo. L lõpuks toimub see füüsilisel konverentsil (kuigi kõiki ettevaatusabinõusid järgides), kuna HighLoad++ energiat ei saa internetis pakendada. HighLoad++ Konverentsil leiame ja näitame teile juhtumeid tehnoloogiate maksimaalsetest võimalustest: HighLoad++ oli, on ja jääb ainukeseks kohaks, kus kahe päeva jooksul saab teada, kuidas on korraldatud Facebook, Yandex, VKontakte, Google ja Amazon.

Konverentsil toome teieni tehnoloogiate maksimaalsed võimalused ja juhtumianalüüsid: HighLoad++ oli, on ja jääb ainukeseks kohaks, kus kahe päeva jooksul tutvuda, kuidas Facebook, Yandex, VKontakte, Google ja Amazon toimivad.

Alates meie kohtumistest 2007. aastast oleme sel aastal koos 14. korda. Selle aja jooksul on konverents kasvanud kümme korda, eelmisel aastal jõudis tööstuse peamine üritus kokku 3339 osalejat, 165 esinejat ettekannete ja koosolekute jaoks, ning toimusid samaaegselt 16 rada.
Eelmisel aastal oli teie jaoks 20 bussi, 5280 liitrit teed ja kohvi, 1650 liitrit mahlajooke ja 10200 pudelit vett. Lisaks oli 2640 kilogrammi toitu, 16000 taldrikut ja 25000 klaasikest. Muide, taaskasutatud paberi müügist saadud raha eest istutasime 100 tammesimooni 🙂

Piletid on saadaval siin, et saada konverentsi uudiseid — siin, ja vestlemiseks — kõigis sotsiaalmeedia kanalites: Telegram, Facebook, Vkontakte ja Twitteris.

Allikas: habr.com