🥇Prelazak u ClickHouse: 3 godine kasnije

Pre tri godine na sceni Viktor Tarnavski i Aleksej Milovidov iz Yandexa HighLoad++ rekao je, koji je ClickHouse dobar, i kako ne usporava. I na sljedećoj fazi je bio Aleksandar Zajcev с izvještaj o preseljenju u clickhouse iz drugog analitičkog DBMS-a i sa zaključkom da clickhouse, naravno, dobro, ali ne baš zgodno. Kada je kompanija 2016 LifeStreet, gde je Aleksandar tada radio, prevodio je analitički sistem od više petabajta clickhouse, bio je to fascinantan "put od žute cigle", pun nepoznatih opasnosti - clickhouse tada je izgledalo kao minsko polje.

Tri godine kasnije clickhouse postao mnogo bolji - za to vrijeme Aleksandar je osnovao kompaniju Altinity, koja ne samo da pomaže da se preseli clickhouse desetine projekata, ali i poboljšava sam proizvod zajedno sa kolegama iz Yandexa. Sad clickhouse još uvijek nije bezbrižna šetnja, ali više ni minsko polje.

Alexander je uključen u distribuirane sisteme od 2003. godine, razvijajući velike projekte na MySQL, Oracle и Vertica. Na kraju HighLoad++ 2019 Aleksandar, jedan od pionira upotrebe clickhouse, rekao šta je ovaj DBMS sada. Naučit ćemo o glavnim karakteristikama clickhouse: po čemu se razlikuje od drugih sistema i u kojim slučajevima ga je efikasnije koristiti. Koristeći primjere, razmotrit ćemo svježe i projektno dokazane prakse za izgradnju sistema zasnovanih na clickhouse.

Retrospektiva: šta se dogodilo prije 3 godine

Prije tri godine smo prenijeli kompaniju LifeStreet na clickhouse iz druge analitičke baze podataka, a migracija analitike oglasne mreže izgledala je ovako:

jun 2016. In Open Source pojavila clickhouse i započeli naš projekat;
August Dokaz koncepta: velika oglasna mreža, infrastruktura i 200-300 terabajta podataka;
oktobar. Prvi podaci o proizvodnji;
decembar. Puno opterećenje proizvoda - 10-50 milijardi događaja dnevno.
Jun 2017. Uspješna migracija korisnika na clickhouse, 2,5 petabajta podataka na klasteru od 60 servera.

Kako je migracija napredovala, razumijevanje je to raslo clickhouse je dobar sistem sa kojim je prijatno raditi, ali ovo je interni projekat Yandex-a. Dakle, postoje nijanse: Yandex će se prvo baviti svojim internim kupcima, a tek onda zajednicom i potrebama eksternih korisnika, dok ClickHouse tada u mnogim funkcionalnim područjima nije dostigao nivo preduzeća. Tako smo u martu 2017. osnovali Altinity to make clickhouse još brže i praktičnije ne samo za Yandex, već i za druge korisnike. A sada mi:

Obučavamo i pomažemo u izgradnji rješenja na temelju clickhouse kako kupci ne bi popunili neravnine i kako bi rješenje na kraju uspjelo;
Pružamo podršku 24/7 clickhouse- instalacije;
Razvijamo sopstvene projekte ekosistema;
Aktivno se posvetiti sebi clickhouse, odgovarajući na zahtjeve korisnika koji žele vidjeti određene funkcije.

I naravno, pomažemo oko preseljenja clickhouse с MySQL, Vertica, proročanstvo, Greenplum, Crveni pomak i drugi sistemi. Učestvovali smo u raznim selidbama i sva su bila uspješna.

Zašto se čak preseliti u clickhouse

Ne usporava! Ovo je glavni razlog. clickhouse - vrlo brza baza podataka za različite scenarije:

Slučajni citati ljudi koji rade sa njima clickhouse.

Skalabilnost. Na nekoj drugoj bazi podataka možete postići dobre performanse na jednom komadu željeza, ali clickhouse možete skalirati ne samo vertikalno, već i horizontalno jednostavnim dodavanjem servera. Ne ide sve glatko kako bismo želeli, ali funkcioniše. Možete razvijati sistem kako vaše poslovanje raste. Važno je da sada nismo ograničeni odlukom i da uvijek postoji potencijal za razvoj.

Prenosivost. Ne postoji vezanost za jednu stvar. Na primjer, sa Amazon RedShift teško se pomeriti negde. A clickhouse možete ga staviti na svoj laptop, server, postaviti ga u oblak, ići na Kubernet - nema ograničenja u radu infrastrukture. Ovo je zgodno za sve, a to je velika prednost kojom se mnoge druge slične baze podataka ne mogu pohvaliti.

Fleksibilnost. clickhouse ne zaustavlja se na jednoj stvari, na primjer Yandex.Metrica, već se razvija i koristi u sve više različitih projekata i industrija. Može se proširiti dodavanjem novih funkcija za rješavanje novih problema. Na primjer, vjeruje se da je pohranjivanje dnevnika u bazi podataka loše ponašanje, pa su za to smislili Elasticsearch. Ali zahvaljujući fleksibilnosti clickhouse, u njega možete pohraniti i logove, a često je čak i bolji nego u Elasticsearch - u clickhouse potrebno je 10 puta manje gvožđa.

Besplatnyj Open Source. Ne morate ništa da platite. Nema potrebe da pregovarate o dozvoli za postavljanje sistema na vaš laptop ili server. Nema skrivenih naknada. Istovremeno, nijedna druga tehnologija baze podataka otvorenog koda ne može se takmičiti u brzini clickhouse. MySQL, MariaDB, Greenplum - svi su mnogo sporiji.

Zajednica, vozi i zabava. Da clickhouse sjajna zajednica: susreti, ćaskanja i Aleksej Milovidov, koji nas sve puni svojom energijom i optimizmom.

Prelazak u ClickHouse

Za prebacivanje na clickhouse sa nečim su vam potrebne samo tri stvari:

Shvatite ograničenja clickhouse i za šta nije pogodan.
Iskoristite pogodnosti tehnologija i njene najveće prednosti.
Eksperimentiraj. Čak i znajući kako to funkcionira clickhouse, nije uvijek moguće predvidjeti kada će biti brže, kada će biti sporije, kada će biti bolje, a kada gore. Pa probaj.

Problem selidbe

Postoji samo jedno "ali": ako pređete na clickhouse sa nečim drugim, nešto obično krene po zlu. Navikli smo na neke prakse i stvari koje rade u našoj omiljenoj bazi podataka. Na primjer, svako sa kim radi SQL-baze podataka, smatra sljedeći skup funkcija obaveznim:

transakcije;
ograničenja;
dosljednost;
indeksi;
AŽURIRAJ/IZBRIŠI;
NULL;
milisekundi;
automatske konverzije tipa;
višestruki spojevi;
proizvoljne particije;
alati za upravljanje klasterima.

Zapošljavanje je obavezno, ali prije tri godine u clickhouse nije bilo nijedne od ovih karakteristika! Sada ostaje manje od polovine nerealizovanog: transakcije, ograničenja, konzistentnost, milisekunde i kasting tipa.

A glavna stvar je da je unutra clickhouse neke standardne prakse i pristupi ne funkcionišu ili ne rade onako kako smo navikli. Sve što se pojavljuje u clickhouse, odgovara "click house way“, tj. funkcije se razlikuju od ostalih DB-ova. Na primjer:

Indeksi se ne biraju, već se preskaču.
AŽURIRAJ/IZBRIŠI ne sinhroni, već asinhroni.
Postoji više spajanja, ali ne postoji planer upita. Ljudima iz svijeta baza podataka općenito nije baš jasno kako se oni izvršavaju.

ClickHouse scenariji

Godine 1960. američki matematičar mađarskog porijekla WignerEP napisao članakNerazumna efikasnost matematike u prirodnim naukama”(“Neshvatljiva efikasnost matematike u prirodnim naukama”) da je svijet oko nas iz nekog razloga dobro opisan matematičkim zakonima. Matematika je apstraktna nauka, a fizički zakoni izraženi u matematičkom obliku nisu trivijalni i WignerEP naglasio da je to veoma čudno.

sa moje tačke gledišta, clickhouse - ista čudnost. Da preformulišemo Wignera, možemo reći ovo: neverovatna je nezamisliva efikasnost clickhouse u širokom spektru analitičkih aplikacija!

Na primjer, uzmimo Skladište podataka u realnom vremenu, u koji se podaci učitavaju gotovo kontinuirano. Želimo da primamo zahtjeve od njega sa drugim zakašnjenjem. Molimo koristite clickhousejer je dizajniran za ovaj scenario. clickhouse ovako se koristi ne samo na webu, već iu marketingu i finansijskoj analitici, AdTech, kao i u Fraud detecion. IN Skladište podataka u realnom vremenu koristi se složena strukturirana šema kao što je "zvijezda" ili "pahulja", sa mnogim tablicama JOIN (ponekad više), a podaci se obično pohranjuju i mijenjaju u nekim sistemima.

Uzmimo drugi scenario - Vremenske serije: uređaji za praćenje, mreže, statistika korištenja, internet stvari. Ovdje se susrećemo s prilično jednostavnim događajima poređanim na vrijeme. clickhouse nije prvobitno dizajniran za ovo, ali se dobro pokazao, pa ga velike kompanije koriste clickhouse kao spremište za praćenje informacija. Da vidim da li odgovara clickhouse za vremenske serije, napravili smo benčmark na osnovu pristupa i rezultata InfluxDB и TimescaleDB — specijalizirana vremenske serije baze podataka. Ispostavilo se, to clickhouse, čak i bez optimizacije za takve zadatke, pobjeđuje i na stranom terenu:

В vremenske serije obično se koristi uska tabela - nekoliko malih kolona. Puno podataka može doći iz praćenja - milioni zapisa u sekundi - i obično dolaze u malim umetcima (u realnom vremenu streaming). Stoga nam je potrebna drugačija skripta za umetanje i sami upiti - sa nekim svojim specifičnostima.

Upravljanje dnevnicima. Sakupljanje dnevnika u bazi podataka je obično loše, ali u clickhouse ovo se može uraditi sa nekim komentarima kao što je gore opisano. Mnoge kompanije koriste clickhouse samo za ovo. U ovom slučaju koristi se ravan široki stol, gdje pohranjujemo cijele trupce (na primjer, u obrascu JSON), ili iseći na komade. Podaci se obično učitavaju u velikim serijama (fajlovi), a mi tražimo neko polje.

Za svaku od ovih funkcija obično se koriste specijalizirane baze podataka. clickhouse može se sve i tako dobro da ih prestiže u performansama. Pogledajmo sada izbliza vremenske serije skripta i kako "kuvati" clickhouse po ovom scenariju.

Vremenske serije

Ovo je trenutno glavni scenario za koji clickhouse smatra se standardnim rešenjem. Vremenske serije je skup vremenski uređenih događaja koji predstavljaju promjene u nekom procesu tokom vremena. Na primjer, to može biti broj otkucaja srca po danu ili broj procesa u sistemu. Sve ono što vremenu daje neke dimenzije jeste vremenske serije:

Većina ovih događaja dolazi od praćenja. To može biti ne samo web nadzor, već i stvarni uređaji: automobili, industrijski sistemi, IoT, industrije ili bespilotnih taksija, u čiji prtljažnik već stavlja Yandex clickhouse-server.

Na primjer, postoje kompanije koje prikupljaju podatke s brodova. Svakih nekoliko sekundi senzori sa kontejnerskog broda šalju stotine različitih mjerenja. Inženjeri ih proučavaju, grade modele i pokušavaju da shvate koliko se brod efikasno koristi, jer kontejnerski brod ne bi trebalo da miruje ni sekunde. Svaki zastoj je gubljenje novca, stoga je važno predvidjeti rutu tako da parkiranje bude minimalno.

Sada postoji rast specijalizovanih baza podataka koje mere vremenske serije. Na sajtu DB-motori nekako su različite baze podataka rangirane, a mogu se pogledati po tipu:

Najbrže rastuća vrsta vremenske serijes. Grafičke baze podataka također rastu, ali vremenske serijerastu brže u posljednjih nekoliko godina. Tipični predstavnici ove porodice baza podataka su InfluxDB, Prometej, KDB, TimescaleDB (izgrađen na PostgreSQL), rješenja iz Amazon. clickhouse i ovdje se može koristiti, i koristi se. Dozvolite mi da vam dam nekoliko javnih primjera.

Jedan od pionira je kompanija CloudFlare (CDNprovajder). Oni prate svoje CDN kroz clickhouse (DNS-zahtjevi, HTTP-zahtjevi) sa ogromnim opterećenjem - 6 miliona događaja u sekundi. Sve prolazi Kafka, ide na clickhouse, koji pruža mogućnost da vidite kontrolne table događaja u sistemu u realnom vremenu.

Comcast - jedan od lidera u telekomunikacijama u Sjedinjenim Državama: Internet, digitalna televizija, telefonija. Stvorili su sličan sistem kontrole CDN u okviru Open Source projekat Apache kontrola prometa da rade sa njihovim ogromnim podacima. clickhouse koristi se kao backend za analitiku.

percona ugrađeno clickhouse unutar vašeg PMMda nastavite sa praćenjem drugačije MySQL.

Specifični zahtjevi

Baze podataka vremenskih serija imaju svoje specifične zahtjeve.

Brzo umetanje od mnogih agenata. Moramo vrlo brzo ubaciti podatke iz mnogih tokova. clickhouse radi dobro, jer ima sve neblokirajuće umetke. Bilo koji umetnite je nova datoteka na disku, a mali umetci mogu biti baferovani na ovaj ili onaj način. IN clickhouse bolje je umetati podatke u velikim serijama, a ne red po red.
Fleksibilno kolo. The vremenske serije obično ne poznajemo u potpunosti strukturu podataka. Moguće je izgraditi sistem nadzora za određenu aplikaciju, ali ga je tada teško koristiti za drugu aplikaciju. Ovo zahtijeva fleksibilniju shemu. clickhouse, vam omogućava da to učinite, iako je jako ukucana baza.
Efikasno skladištenje i "zaboravljanje" podataka. Obično u vremenske serije ogromna količina podataka, pa ih je potrebno što efikasnije pohraniti. Na primjer, kod InfluxDB dobra kompresija je njegova glavna karakteristika. Ali pored skladištenja, morate biti u mogućnosti da "zaboravite" stare podatke i uradite neke smanjenje uzorkovanja — automatsko brojanje agregata.
Brzi upiti o agregiranim podacima. Ponekad je zanimljivo pogledati zadnjih 5 minuta s preciznošću od milisekundi, ali na mjesečnim podacima možda neće biti potrebna minuta ili sekundna granularnost - dovoljna je opća statistika. Podrška ove vrste je neophodna, inače će se zahtjev za 3 mjeseca izvršavati jako dugo čak i u clickhouse.
Zahtjevi poput "poslednja tačka, od». Ovo su tipične za vremenske serije zahtjevi: pogledajte posljednje mjerenje ili stanje sistema u određenom trenutku t. Za bazu podataka, ovo nisu baš prijatni upiti, ali ih takođe treba moći izvršiti.
"lepljenje" vremenskih serija. Vremenske serije je vremenska serija. Ako postoje dvije vremenske serije, onda ih je često potrebno povezati i korelirati. Nije zgodno to raditi na svim bazama podataka, posebno sa neusklađenim vremenskim serijama: ovdje su neke vremenske oznake, postoje druge. Možete uzeti u obzir prosjek, ali odjednom će i dalje biti rupa, tako da nije jasno.

Pogledajmo kako su ovi zahtjevi ispunjeni clickhouse.

Shema

В clickhouse shema za vremenske serije može se izvršiti na različite načine, u zavisnosti od stepena pravilnosti podataka. Moguće je izgraditi sistem na redovnim podacima kada znamo sve metrike unaprijed. Na primjer, jeste CloudFlare sa praćenjem CDN je dobro optimizovan sistem. Možete izgraditi opštiji sistem koji nadgleda cjelokupnu infrastrukturu, različite usluge. U slučaju neregularnih podataka, ne znamo unaprijed šta pratimo – a to je vjerovatno najčešći slučaj.

redovni podaci. Kolone. Shema je jednostavna - stupci s potrebnim vrstama:

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

Ovo je obična tabela koja prati neku vrstu aktivnosti pokretanja sistema (korisnik, sistem, idle, lijep). Jednostavno i praktično, ali ne i fleksibilno. Ako želimo fleksibilniju shemu, onda možemo koristiti nizove.

Nepravilni podaci. Nizovi:

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 ...

struktura Gnezden su dva niza: metrics.name и metrics.value. Ovdje možete pohraniti takve proizvoljne podatke praćenja kao niz imena i niz mjerenja za svaki događaj. Za dalju optimizaciju može se napraviti nekoliko takvih struktura umjesto jedne. Na primjer, jedan za float-vrijednost, drugo - za Int-znači, jer Int Želim efikasnije skladištiti.

Ali takvoj strukturi je teže pristupiti. Morat ćete koristiti posebnu konstrukciju, koristeći posebne funkcije za izvlačenje vrijednosti prvo iz indeksa, a zatim iz niza:

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

Ali i dalje radi dovoljno brzo. Drugi način pohranjivanja nepravilnih podataka je po redovima.

Nepravilni podaci. Strings. Na ovaj tradicionalan način, bez nizova, imena i vrijednosti se pohranjuju odjednom. Ako 5 mjerenja dolazi s jednog uređaja odjednom, 000 redova se generira u bazi podataka:

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', ...)

clickhouse nosi s tim - ima posebne ekstenzije clickhouse SQL. Na primjer maxIf - posebna funkcija koja izračunava maksimum po metrici kada je ispunjen neki uslov. Možete napisati nekoliko takvih izraza u jednom upitu i odmah izračunati vrijednost za nekoliko metrika.

Uporedimo tri pristupa:

Детали

Ovdje sam dodao "Veličina podataka na disku" za neki skup podataka testa. U slučaju kolona, imamo najmanju veličinu podataka: maksimalnu kompresiju, maksimalnu brzinu upita, ali plaćamo tako što moramo sve popraviti odjednom.

U slučaju nizova stvari su malo gore. Podaci se i dalje dobro komprimiraju i moguće je pohraniti nepravilan obrazac. Ali clickhouse - baza podataka kolona, a kada počnemo da skladištimo sve u nizu, ona se pretvara u bazu podataka nizova, a fleksibilnost plaćamo efikasnošću. Za bilo koju operaciju, morat ćete pročitati cijeli niz u memoriju, zatim pronaći željeni element u njemu - a ako niz raste, brzina se smanjuje.

U jednoj od kompanija koja koristi ovaj pristup (npr. uber), nizovi su izrezani na komade od 128 elemenata. Podaci od nekoliko hiljada metrika sa zapreminom od 200 TB podataka/dan se ne pohranjuju u jedan niz, već u 10 ili 30 nizova sa posebnom logikom skladištenja.

Najjednostavniji pristup je sa žicama. Ali podaci su loše komprimirani, veličina tablice je velika, a čak i kada su upiti zasnovani na nekoliko metrika, ClickHouse ne radi optimalno.

hibridna šema

Pretpostavimo da smo odabrali šemu niza. Ali ako znamo da većina naših nadzornih ploča prikazuje samo korisničke i sistemske metrike, možemo dodatno materijalizirati ove metrike u stupce iz niza na nivou tabele na ovaj način:

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

Kada se zalijepi clickhouse automatski će ih prebrojati. Na ovaj način možete kombinovati posao sa zadovoljstvom: shema je fleksibilna i opšta, ali izvukli smo najčešće korištene kolone. Napominjem da to nije zahtijevalo promjenu umetka i ETL, koji nastavlja da umeće nizove u tabelu. Upravo smo to uradili ALTER TABLE, dodao je nekoliko zvučnika i dobio hibridnu i bržu shemu koju možete početi koristiti odmah.

Kodeci i kompresija

Do vremenske serije važno je koliko dobro spakujete podatke, jer niz informacija može biti veoma velik. IN clickhouse postoji set alata za postizanje efekta kompresije 1:10, 1:20, a ponekad i više. To znači da 1 TB nekomprimiranih podataka na disku zauzima 50-100 GB. Manja veličina je dobra, podaci se brže čitaju i obrađuju.

Za postizanje visokog nivoa kompresije, clickhouse podržava sljedeće kodeke:

Primjer tablice:

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

Ovdje definiramo kodek DoubleDelta u jednom slučaju, u drugom gorila, i svakako dodajte još LZ4 kompresija. Kao rezultat toga, veličina podataka na disku je znatno smanjena:

Ovo pokazuje koliko prostora zauzimaju isti podaci, ali koristeći različite kodeke i kompresije:

u GZIP datoteci na disku;
u ClickHouseu bez kodeka, ali sa ZSTD kompresijom;
u ClickHouse sa LZ4 i ZSTD kodecima i kompresijom.

Vidi se da tabele sa kodecima zauzimaju mnogo manje prostora.

Veličina je bitna

Ne manje važno выбрать ispravan tip podataka:

U svim gornjim primjerima koje sam koristio Float64. Ali ako biramo Float32onda bi to bilo još bolje. To su dobro pokazali momci iz Perkone u članku na linku iznad. Važno je koristiti najkompaktniji tip koji odgovara zadatku: čak i manje za veličinu diska nego za brzinu upita. clickhouse veoma osetljiva na to.

Ako možete koristiti int32 umjesto int64, onda očekujte skoro dvostruko povećanje performansi. Podaci zauzimaju manje memorije, a sva "aritmetika" radi mnogo brže. clickhouse unutar njega je vrlo striktno tipiziran sistem, maksimalno iskorištava sve mogućnosti koje moderni sistemi pružaju.

Agregacija i Materijalizirani pogledi

Agregacija i materijalizovani prikazi vam omogućavaju da napravite agregate za različite prilike:

Na primjer, možda imate neagregirane izvorne podatke i na njih možete objesiti različite materijalizirane poglede s automatskim zbrajanjem kroz poseban mehanizam SummingMergeTree (SMT). SMT je posebna struktura podataka agregiranja koja automatski broji agregate. Sirovi podaci se ubacuju u bazu podataka, automatski se agregiraju i kontrolne ploče se mogu odmah koristiti.

TTL - "zaboravite" stare podatke

Kako "zaboraviti" podatke koji više nisu potrebni? clickhouse zna kako to da uradi. Prilikom kreiranja tabela, možete odrediti TTL izrazi: na primjer, da pohranjujemo minutne podatke za jedan dan, dnevne podatke za 30 dana i nikada ne dodirujemo sedmične ili mjesečne podatke:

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

Višeslojni - particioniranje podataka po diskovima

Razvijajući ovu ideju, podaci se mogu pohraniti u clickhouse na različitim mjestima. Pretpostavimo da želimo pohraniti vruće podatke za prošlu sedmicu na vrlo brzom lokalnom SSD, a mi dodajemo više istorijskih podataka na drugo mjesto. IN clickhouse sada je moguće:

Možete konfigurirati politiku zadržavanja (politika skladištenja) Dakle clickhouse će automatski prenijeti podatke u drugu pohranu kada se ispune određeni uvjeti.

Ali to nije sve. Na nivou određene tabele možete definisati pravila za tačno kada se podaci prenose u hladnjaču. Na primjer, 7 dana podataka leži na vrlo brzom disku, a sve što je starije prenosi se na spori. Ovo je dobro jer omogućava sistemu da zadrži maksimalne performanse, dok kontroliše troškove i ne troši novac na hladne podatke:

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

Jedinstvene karakteristike clickhouse

Skoro sve unutra clickhouse postoje takvi "vrhunci", ali su nivelisani po ekskluzivi - onoga što nema u drugim bazama podataka. Na primjer, evo nekih od jedinstvenih karakteristika clickhouse:

Nizovi. The clickhouse vrlo dobra podrška za nizove, kao i mogućnost izvođenja složenih proračuna na njima.
Agregiranje struktura podataka. Ovo je jedna od "ubistvenih karakteristika" clickhouse. Uprkos činjenici da momci iz Yandexa kažu da ne želimo agregirati podatke, sve je agregirano u clickhousejer je brz i zgodan.
Materijalizovani pogledi. Zajedno sa agregirajućim strukturama podataka, materijalizirani prikazi vam omogućavaju da napravite pogodan u realnom vremenu agregacija.
ClickHouse SQL. Ovo je jezička ekstenzija SQL s nekim dodatnim i ekskluzivnim funkcijama koje su dostupne samo u clickhouse. Ranije je to bilo, s jedne strane, proširenje, a s druge mana. Sada skoro svi nedostaci u odnosu na SQL 92 uklonili smo ga, sada je samo proširenje.
Lambda-izrazi. Jesu li još uvijek u nekoj bazi podataka?
ML-podrška. Ovo je u različitim bazama podataka, neke su bolje, neke lošije.
open source. Možemo se proširiti clickhouse zajedno. Sada unutra clickhouse oko 500 saradnika, a ovaj broj stalno raste.

Tricky Queries

В clickhouse postoji mnogo različitih načina da se uradi ista stvar. Na primjer, postoje tri različita načina da se vrati posljednja vrijednost iz tablice za CPU (postoji i četvrti, ali je još egzotičniji).

Prvi pokazuje koliko je to zgodno raditi clickhouse upite kada to želite provjeriti kortež sadržane u potupitu. Ovo je nešto što je meni lično zaista nedostajalo u drugim bazama podataka. Ako želim nešto da uporedim sa podupitom, onda se u drugim bazama podataka može porediti samo skalar sa njim, a za nekoliko kolona treba da napišem JOIN. The clickhouse možete koristiti tuple:

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

Drugi način radi isto, ali koristi agregatnu funkciju argMax:

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

В clickhouse postoji nekoliko desetina agregatnih funkcija, a ako koristite kombinatore, onda prema zakonima kombinatorike, dobijete ih oko hiljadu. ArgMax - jedna od funkcija koja broji maksimalnu vrijednost: upit vraća vrijednost usage_user, na kojoj je dostignuta maksimalna vrijednost 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 - "lijepljenje" redova sa različitim vremenima. Ovo je jedinstvena karakteristika za baze podataka i dostupna je samo u kdb+. Ako postoje dvije vremenske serije s različitim vremenima, ASOF JOIN omogućava njihovo pomicanje i lijepljenje u jednom zahtjevu. Za svaku vrijednost u jednoj vremenskoj seriji, nalazi se najbliža vrijednost u drugoj i vraćaju se u istom redu:

Analitičke funkcije

U standardu SQL-2003 možete napisati ovako:

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;

В clickhouse ovo nije moguće - ne podržava standard SQL-2003 i vjerovatno nikad neće. Umjesto toga, u clickhouse uobičajeno je pisati ovako:

Obećao sam lambde - evo ih!

Ovo je analog analitičkog upita u standardu SQL-2003: broji razliku između dva vremenska oznaka, trajanje, ordinal - sve što obično smatramo analitičkim funkcijama. IN clickhouse brojimo ih kroz nizove: prvo skupljamo podatke u niz, nakon toga radimo šta god želimo na nizu, a zatim ga ponovo širimo. Nije baš zgodno, zahtijeva barem ljubav prema funkcionalnom programiranju, ali je vrlo fleksibilan.

Posebne karakteristike

Osim toga, u clickhouse mnoge specijalizovane karakteristike. Na primjer, kako odrediti koliko sesija se izvodi u isto vrijeme? Tipičan zadatak za praćenje je određivanje maksimalnog opterećenja u jednom zahtjevu. IN clickhouse za tu svrhu postoji posebna funkcija:

Općenito, ClickHouse ima posebne funkcije za mnoge svrhe:

runDifference, runningAccumulate, susjed;
sumMap(ključ, vrijednost);
timeSeriesGroupSum(uid, vremenska oznaka, vrijednost);
timeSeriesGroupRateSum(uid, vremenska oznaka, vrijednost);
skewPop, skewSamp, kurtPop, kurtSamp;
SA PUNJEM / SA VEZAMA;
simpleLinearRegression, stochasticLinearRegression.

Ovo nije potpuna lista funkcija, ima ih samo 500-600. Savjet: sve funkcije u clickhouse nalazi se u sistemskoj tabeli (nisu svi dokumentovani, ali su svi zanimljivi):

select * from system.functions order by name

clickhouse pohranjuje mnogo informacija o sebi, uključujući log tablice, query_log, dnevnik praćenja, dnevnik operacija sa blokovima podataka (part_log), dnevnik metrike i sistemski dnevnik, koji obično zapisuje na disk. Dnevnik metrike je vremenske serije в clickhouse zapravo clickhouse: sama baza podataka može igrati ulogu vremenske serije baze podataka, "proždirući" samu sebe.

Ovo je takođe jedinstvena stvar - jer radimo dobar posao za vremenske serijezašto sve što nam je potrebno ne možemo pohraniti u sebe? Ne trebamo Prometej, sve držimo u sebi. Povezano grafana i pratimo sami sebe. Međutim, ako clickhouse padne, nećemo vidjeti - zašto - zato to obično ne rade.

Velika grupa ili mnogo malih clickhouse

Što je bolje - jedan veliki klaster ili više malih ClickHouse-a? Tradicionalni pristup DWH je veliki klaster u kojem su sheme dodijeljene za svaku aplikaciju. Došli smo do administratora baze podataka - dajte nam šemu i dobili smo je:

В clickhouse možete to učiniti drugačije. Može li svaka aplikacija napraviti svoju clickhouse:

Ne treba nam više veliko čudovište DWH i nekooperativni administratori. Svakoj aplikaciji možemo dati svoju clickhouse, a programer to može učiniti sam, budući da clickhouse vrlo jednostavan za instalaciju i ne zahtijeva složenu administraciju:

Ali ako imamo puno clickhouse, i morate ga često postavljati, onda želite da automatizujete ovaj proces. Za to možemo, na primjer, koristiti Kubernet и clickhouse-operater. IN Kubernetes ClickHouse možete staviti "na klik": mogu kliknuti na dugme, pokrenuti manifest i baza podataka je spremna. Možete odmah kreirati šemu, početi učitavati metriku tamo i nakon 5 minuta imam spremnu kontrolnu ploču grafana. Tako je jednostavno!

Šta je na kraju?

Tako clickhouse - ovo je:

Brzo. Svi to znaju.
Jednostavno. Malo diskutabilno, ali mislim da je teško naučiti, lako se boriti. Ako razumete kako clickhouse radi, sve je vrlo jednostavno.
Univerzalno. Pogodan je za različite scenarije: DWH, vremenske serije, skladište dnevnika. Ali nije OLTP bazu podataka, tako da ne pokušavajte da radite kratke umetke i čitanja tamo.
Zanimljivo. Verovatno onaj sa kojim radi clickhouse, doživjela mnogo zanimljivih minuta u dobrom i lošem smislu. Na primjer, izašlo je novo izdanje, sve je prestalo raditi. Ili kada ste se mučili sa zadatkom dva dana, ali nakon pitanja u Telegram chatu, zadatak je bio riješen za dvije minute. Ili, kao na konferenciji u izveštaju Leše Milovidova, snimak ekrana iz clickhouse prekinuo prenos HighLoad++. Ovakve stvari se stalno dešavaju i čine naš život clickhouse svijetlo i zanimljivo!

Prezentacija se može pogledati ovdje.

Dugo očekivani sastanak programera sistema visokog opterećenja na HighLoad++ održaće se 9. i 10. novembra u Skolkovu. Konačno, to će biti vanmrežna konferencija (iako uz sve mjere predostrožnosti), jer se energija HighLoad++ ne može pakovati na mreži.

Za konferenciju pronalazimo i pokazujemo vam slučajeve o maksimalnim mogućnostima tehnologije: HighLoad ++ je bio, jeste i biće jedino mjesto gdje ćete za dva dana naučiti kako funkcioniraju Facebook, Yandex, VKontakte, Google i Amazon.

Održavajući naše sastanke bez prekida od 2007. godine, ove godine ćemo se sastati po 14. put. Za to vrijeme konferencija je porasla 10 puta, prošle godine je ključni događaj industrije okupio 3339 učesnika, 165 govornika izvještaja i sastanaka, a istovremeno je sviralo 16 pjesama.
Prošle godine za vas je bilo 20 autobusa, 5280 litara čaja i kafe, 1650 litara voćnih pića i 10200 flaša vode. I još 2640 kilograma hrane, 16 tanjira i 000 šoljica. Inače, novcem prikupljenim od recikliranog papira zasadili smo 25 hrastovih sadnica 🙂

Ulaznice se mogu kupiti ovdje, primajte vijesti o konferenciji — ovdje, i pričajte na svim društvenim mrežama: telegram, Facebook, Vkontakte и cvrkut.

izvor: www.habr.com

Prelazak u ClickHouse: 3 godine kasnije