🥇Prelazak u ClickHouse: 3 godine kasnije

Prije tri godine Viktor Tarnavsky i Alexey Milovidov iz Yandexa na pozornici Visoko opterećenje++ rekao, koliko je ClickHouse dobar i kako ne usporava. A na sljedećoj pozornici bilo je Aleksandar Zajcev с izvješće o preseljenju u klikanica iz drugog analitičkog DBMS-a i uz zaključak da klikanica, naravno, dobro, ali nije baš zgodno. Kada je 2016. tvrtka LifeStreet, gdje je Alexander tada radio, pretvarao je višepetabajtni analitički sustav u klikanica, bila je to fascinantna "žuta cesta" puna nepoznatih opasnosti - klikanica tada je izgledalo kao minsko polje.

Tri godine kasnije klikanica postao mnogo bolji - za to vrijeme Alexander je osnovao tvrtku Altinity, koja ne samo da pomaže ljudima da se presele u klikanica desetke projekata, ali i unapređuje sam proizvod zajedno s kolegama iz Yandexa. Sada klikanica još uvijek nije bezbrižna šetnja, ali više ni minsko polje.

Alexander radi s distribuiranim sustavima od 2003. godine, razvijajući velike projekte MySQL, Oracle и Vertica. Na posljednjem HighLoad++ 2019 Alexander, jedan od pionira korištenja klikanica, rekao je što je ovaj DBMS sada. Naučit ćemo o glavnim značajkama klikanica: kako se razlikuje od drugih sustava i u kojim slučajevima ga je učinkovitije koristiti. Koristeći primjere, pogledat ćemo nedavne i projektno testirane prakse za izgradnju sustava temeljenih na klikanica.

Retrospektiva: što se dogodilo prije 3 godine

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

lipnja 2016. In Otvoreni izvor pojavio klikanica i naš projekt je započeo;
Kolovoz. Dokaz koncepta: velika oglašivačka mreža, infrastruktura i 200-300 terabajta podataka;
Listopad. Prvi proizvodni podaci;
Prosinac. Puno opterećenje proizvoda je 10-50 milijardi događaja dnevno.
lipnja 2017. Uspješna migracija korisnika na klikanica, 2,5 petabajta podataka na klasteru od 60 poslužitelja.

Tijekom migracijskog procesa sve više se shvaćalo da klikanica je dobar sustav s kojim je ugodno raditi, ali ovo je interni projekt Yandexa. Dakle, postoje nijanse: Yandex će se prvo baviti vlastitim internim kupcima, a tek onda zajednicom i potrebama vanjskih korisnika, a ClickHouse tada nije dosegao razinu poduzeća u mnogim funkcionalnim područjima. Zato smo osnovali Altinity u ožujku 2017. kako bismo napravili klikanica 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 klikanica kako kupci ne bi upali u probleme i kako bi rješenje u konačnici uspjelo;
Pružamo podršku 24/7 klikanica- instalacije;
Razvijamo vlastite projekte ekosustava;
Aktivno se posvećujemo sebi klikanica, odgovarajući na zahtjeve korisnika koji žele vidjeti određene značajke.

I naravno, pomažemo oko preseljenja u klikanica с MySQL, Vertica, Proročanstvo, Zelena šljiva, crveni pomak i drugim sustavima. Sudjelovali smo u raznim potezima i svi su bili uspješni.

Zašto se preseliti u klikanica

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

Nasumični citati ljudi koji dugo rade s ljudima klikanica.

Skalabilnost. Na nekoj drugoj bazi podataka možete postići dobre performanse na jednom hardveru, ali klikanica možete skalirati ne samo okomito, već i vodoravno, jednostavnim dodavanjem poslužitelja. Ne ide sve glatko kako bismo htjeli, ali ide. Sustav možete proširiti kako vaše poslovanje raste. Važno je da sada nismo ograničeni rješenjem i uvijek postoji potencijal za razvoj.

Prenosivost. Ne postoji vezanost za jednu stvar. Na primjer, sa Amazon RedShift Teško se nekamo preseliti. A klikanica možete ga instalirati na svoje prijenosno računalo, poslužitelj, implementirati ga u oblak, otići na Kubernetes — 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.

savitljivost. klikanica ne zaustavlja se samo na jednoj stvari, npr. Yandex.Metrica, već se razvija i koristi u sve više različitih projekata i industrija. Može se proširiti dodavanjem novih mogućnosti za rješavanje novih problema. Na primjer, vjeruje se da je pohranjivanje logova u bazu podataka loš način, pa su se dosjetili Elasticsearch. Ali zahvaljujući fleksibilnosti klikanica, u njega možete pohraniti i cjepanice, a često je to čak i bolje nego u Elasticsearch - u klikanica ovo zahtijeva 10 puta manje željeza.

Besplatno Open Source. Ne morate ništa platiti. Nema potrebe pregovarati o dopuštenju za instalaciju sustava na vašem prijenosnom računalu ili poslužitelju. Bez skrivenih naknada. U isto vrijeme, nijedna druga tehnologija baze podataka otvorenog koda ne može se natjecati u brzini klikanica. MySQL, MariaDB, Greenplum - svi su puno sporiji.

Zajednica, pogon i zabava. U klikanica odlična zajednica: susreti, chatovi i Alexey Milovidov koji nas sve puni svojom energijom i optimizmom.

Prelazak u ClickHouse

Ići klikanica iz nekog razloga, trebate samo tri stvari:

Shvatite ograničenja klikanica a za što nije prikladan.
Iskoristiti tehnologija i njezine najveće prednosti.
Eksperiment. Čak i razumijevanje kako funkcionira klikanica, nije uvijek moguće predvidjeti kada će biti brži, kada će biti sporiji, kada će biti bolji, a kada lošiji. Pa pokušajte.

Problem s kretanjem

Postoji samo jedno "ali": ako se preselite u klikanica od nečeg drugog, tada obično nešto pođe po zlu. Navikli smo na neke prakse i stvari koje rade u našoj omiljenoj bazi podataka. Na primjer, svatko tko radi s SQL-baze podataka smatraju sljedeći skup funkcija obveznim:

transakcije;
ograničenja;
dosljednost;
indeksi;
AŽURIRAJ/IZBRIŠI;
NULL-ovi;
milisekunde;
automatski odljevci tipa;
višestruki spojevi;
proizvoljne pregrade;
alati za upravljanje klasterima.

Zapošljavanje je obavezno, ali prije tri godine u klikanica Nijedna od ovih funkcija nije bila dostupna! Sada je ostalo manje od polovice onoga što nije implementirano: transakcije, ograničenja, dosljednost, milisekunde i određivanje tipa.

A glavno je da u klikanica neke standardne prakse i pristupi ne funkcioniraju ili djeluju drugačije nego što smo navikli. Sve što se pojavljuje u klikanica, odgovara "ClickHouse način", tj. funkcije razlikuju od ostalih baza podataka. Na primjer:

Indeksi se ne biraju, već se preskaču.
AŽURIRAJ/IZBRIŠI ne sinkrono, nego asinkrono.
Postoji više spajanja, ali ne postoji planer upita. Kako se onda izvode općenito nije jasno ljudima iz svijeta baza podataka.

ClickHouse skripte

1960. američki matematičar mađarskog podrijetla Wigner EP napisao članak "Nerazumna učinkovitost matematike u prirodnim znanostima” (“The Uncomprehensible Effectiveness of Mathematics in the Natural Sciences”) da je svijet oko nas iz nekog razloga dobro opisan matematičkim zakonima. Matematika je apstraktna znanost, a fizikalni zakoni izraženi u matematičkom obliku nisu trivijalni, a Wigner EP naglasio da je to vrlo čudno.

S moje točke gledišta, klikanica - ista neobičnost. Da preformuliramo Wignera, možemo reći ovo: nepojmljiva učinkovitost je zapanjujuća klikanica u širokom spektru analitičkih primjena!

Na primjer, uzmimo Skladište podataka u stvarnom vremenu, u koji se podaci gotovo neprekidno učitavaju. Želimo primati zahtjeve od njega sa drugom odgodom. Molimo - iskoristite ga klikanica, jer je to scenarij za koji je dizajniran. klikanica upravo se tako koristi ne samo na webu, već iu marketinškoj i financijskoj analitici, AdTech, kao i u Otkrivanje prijevaran. U Skladište podataka u stvarnom vremenu koristi se složena strukturirana shema poput "zvijezde" ili "pahuljice", mnoge tablice sa PRIDRUŽITE (ponekad više), a podaci se obično pohranjuju i mijenjaju u nekim sustavima.

Uzmimo drugi scenarij - Vremenske serije: praćenje uređaja, mreže, statistika korištenja, Internet stvari. Ovdje se susrećemo s prilično jednostavnim događajima poredanim u vremenu. klikanica nije izvorno razvijen za to, ali se pokazao kao dobar, zbog čega ga velike tvrtke koriste klikanica kao spremište za praćenje informacija. Da istražimo je li prikladno klikanica za vremenske serije, napravili smo referentnu vrijednost na temelju pristupa i rezultata InfluxDB и Vremenska skalaDB - specijalizirani vremenske serije baze podataka. Ispostavilo seDa klikanica, čak i bez optimizacije za takve zadatke, pobjeđuje na stranom terenu:

В vremenske serije Obično se koristi uska tablica - nekoliko malih stupaca. Puno podataka može doći iz praćenja—milijuni zapisa u sekundi—i obično dolaze u malim nizovima (stvarnom vremenu strujanje). Stoga je potrebna drugačija skripta za umetanje, a i sami upiti imaju svoje specifičnosti.

Upravljanje Prijavite. Prikupljanje zapisa u bazu podataka obično je loše, ali klikanica to se može učiniti s nekim komentarima kao što je gore opisano. Mnoge tvrtke koriste klikanica upravo za ovu svrhu. U ovom slučaju koristimo ravni široki stol na koji spremamo cijele trupce (npr. u obliku JSON), ili izrezati na komade. Podaci se obično učitavaju u velikim paketima (datotekama), a tražimo po nekom polju.

Za svaku od ovih funkcija obično se koriste specijalizirane baze podataka. klikanica može se sve i tako dobro da ih nadmašuje. Pogledajmo sada pobliže vremenske serije scenarij i kako pravilno „kuhati“. klikanica za ovaj scenarij.

Vremenske serije

Trenutno je ovo glavni scenarij za koji klikanica smatra standardnim rješenjem. Vremenske serije je skup događaja poredanih u vremenu, koji predstavljaju promjene u nekom procesu tijekom vremena. Na primjer, to može biti broj otkucaja srca po danu ili broj procesa u sustavu. Sve što daje vremenu otkucaje s nekim dimenzijama jest vremenske serije:

Većina ovih vrsta događaja dolazi od praćenja. To može biti ne samo praćenje weba, već i stvarnih uređaja: automobila, industrijskih sustava, IOT, tvornice ili taksiji bez posade, u čiji prtljažnik Yandex već stavlja klikanica-poslužitelj.

Na primjer, postoje tvrtke koje prikupljaju podatke s brodova. Svakih nekoliko sekundi senzori na kontejnerskom brodu šalju stotine različitih mjerenja. Inženjeri ih proučavaju, izrađuju modele i pokušavaju shvatiti koliko se učinkovito koristi plovilo, jer kontejnerski brod ne smije stajati ni sekunde. Svaki zastoj je gubitak novca, stoga je važno predvidjeti rutu kako bi zastoji bili minimalni.

U današnje vrijeme postoji porast specijaliziranih baza podataka koje mjere vremenske serije. Na liniji DB-motori Različite baze podataka su nekako rangirane i možete ih pregledati prema vrsti:

Najbrže rastući tip je vremenske serijes. Graf baze podataka također rastu, ali vremenske serijerastu brže u posljednjih nekoliko godina. Tipični predstavnici ove obitelji baza podataka su InfluxDB, Prometej, KDB, Vremenska skalaDB (izgrađen na PostgreSQL), rješenja iz Amazon. klikanica može se koristiti i ovdje, i koristi se. Navest ću vam nekoliko javnih primjera.

Jedan od pionira je tvrtka CloudFlare (CDN-pružatelj). Oni prate svoje CDN kroz klikanica (DNS-zahtjevi, HTTP-upiti) s ogromnim opterećenjem - 6 milijuna događaja u sekundi. Sve prolazi Kafka, Ide na klikanica, koji pruža mogućnost uvida u nadzorne ploče događaja u sustavu u stvarnom vremenu.

Comcast - jedan od vodećih u telekomunikacijama u SAD-u: Internet, digitalna televizija, telefonija. Stvorili su sličan sustav kontrole CDN unutar okvira Open Source projekt Apache kontrola prometa za rad s vašim ogromnim podacima. klikanica koristi se kao pozadina za analitiku.

percona ugrađeni klikanica unutar vašeg PMMza pohranjivanje praćenja raznih MySQL.

Posebni zahtjevi

Baze podataka vremenskih serija imaju svoje posebne zahtjeve.

Brzo umetanje od mnogih agenata. Moramo vrlo brzo umetnuti podatke iz mnogih tokova. klikanica To čini dobro jer svi njegovi umeci ne blokiraju. Bilo koje INSERT je nova datoteka na disku, a mali umetci se mogu spremiti u međuspremnik na ovaj ili onaj način. U klikanica Bolje je unositi podatke u velikim serijama, a ne jedan redak odjednom.
Fleksibilna shema. U vremenske serije strukturu podataka obično ne znamo u potpunosti. Moguće je izgraditi sustav nadzora za određenu aplikaciju, ali ga je onda teško koristiti za drugu aplikaciju. To zahtijeva fleksibilniju shemu. klikanica, omogućuje vam da to učinite, iako se radi o strogo tipiziranoj bazi.
Učinkovito pohranjivanje i zaboravljanje podataka. Obično u vremenske serije ogromnu količinu podataka, pa ih je potrebno pohraniti što učinkovitije. Na primjer, na InfluxDB dobra kompresija je njegova glavna karakteristika. Ali osim pohranjivanja, također morate biti u mogućnosti "zaboraviti" stare podatke i napraviti neku vrstu smanjivanje uzorkovanja — automatsko brojanje agregata.
Brzi upiti na agregiranim podacima. Ponekad je zanimljivo pogledati zadnjih 5 minuta s točnošću od milisekundi, ali na mjesečnim podacima granularnost minuta ili sekundi možda neće biti potrebna - dovoljna je opća statistika. Podrška ove vrste je neophodna, inače će zahtjev za 3 mjeseca trajati jako dugo čak i u klikanica.
Zahtjevi poput "zadnja točka, od». Ovo je tipično za vremenske serije upiti: pogledajte posljednje mjerenje ili stanje sustava u određenom trenutku t. Ovo nisu baš ugodni upiti za bazu podataka, ali i njih morate znati izvesti.
“Lijepljenje” vremenskih serija. Vremenske serije je vremenska serija. Ako postoje dvije vremenske serije, često ih je potrebno povezati i korelirati. Nije prikladno to raditi na svim bazama podataka, posebno s neusklađenim vremenskim serijama: ovdje su neke vremenske točke, postoje druge. Možete uzeti u obzir prosjek, ali iznenada će tamo i dalje biti rupa, tako da nije jasno.

Pogledajmo kako su ti zahtjevi ispunjeni klikanica.

Shema

В klikanica shema za vremenske serije može se obaviti na različite načine, ovisno o stupnju ispravnosti podataka. Moguće je izgraditi sustav na regularnim podacima kada unaprijed znamo sve metrike. Na primjer, napravio sam ovo CloudFlare uz praćenje CDN je dobro optimiziran sustav. Možete izgraditi općenitiji sustav koji nadzire cjelokupnu infrastrukturu i razne usluge. U slučaju nepravilnih podataka ne znamo unaprijed što pratimo – a to je vjerojatno najčešći slučaj.

Redoviti podaci. Stupci. Shema je jednostavna - stupci s potrebnim tipovima:

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 tablica koja prati neku vrstu aktivnosti učitavanja sustava (korisnik, sistem, besposlen, lijepo). Jednostavan i praktičan, ali ne i fleksibilan. Ako želimo fleksibilniju shemu, tada možemo koristiti nizove.

Neregularni 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 Ugniježđena su dva niza: metrika.naziv и metrika.vrijednost. Ovdje možete pohraniti proizvoljne podatke praćenja kao niz imena i niz mjerenja za svaki događaj. Za daljnju optimizaciju, umjesto jedne takve strukture, možete napraviti nekoliko. Na primjer, jedan za plutati-vrijednost, drugi - za int- što znači jer int Želim učinkovitije skladištiti.

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

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

Ali i dalje radi prilično brzo. Drugi način pohranjivanja nepravilnih podataka je po redu.

Neregularni podaci. Žice. U ovoj tradicionalnoj metodi, bez nizova, imena i vrijednosti pohranjuju se istovremeno. Ako 5 mjerenja dolazi s jednog uređaja odjednom, 000 redaka 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', ...)

klikanica nosi s tim - ima posebne nastavke klikanica SQL, Na primjer maxIf — posebna funkcija koja računa maksimum pomoću metrike kada je ispunjen neki uvjet. Možete napisati nekoliko takvih izraza u jednom zahtjevu i odmah izračunati vrijednost za nekoliko metrika.

Usporedimo tri pristupa:

Detalji

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

U slučaju nizova, sve je malo gore. Podaci su još uvijek dobro komprimirani i mogu se pohraniti nepravilni uzorci. Ali klikanica - stupčasta baza podataka, a kada počnemo sve pohranjivati u nizu, on se pretvara u redak, a fleksibilnost plaćamo učinkovitošću. Za bilo koju operaciju, morat ćete pročitati cijeli niz u memoriju, zatim pronaći željeni element u njemu - i ako niz raste, tada se brzina smanjuje.

U jednoj od tvrtki koja koristi ovaj pristup (npr. Uber), nizovi su izrezani na dijelove od 128 elemenata. Podaci iz nekoliko tisuća metrika s volumenom od 200 TB podataka/dan pohranjuju se ne u jedno polje, već u 10 ili 30 polja s posebnom logikom pohrane.

Najjednostavniji pristup je s nizovima. No podaci su slabo komprimirani, veličina tablice je velika, a čak i kada se upiti temelje na nekoliko metrika, ClickHouse ne radi optimalno.

Hibridna shema

Pretpostavimo da smo odabrali sklop polja. Ali ako znamo da većina naših nadzornih ploča prikazuje samo metriku korisnika i sustava, možemo dodatno materijalizirati te metrike u stupce iz niza na razini tablice 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);

Prilikom umetanja klikanica automatski će ih prebrojati. Na ovaj način možete spojiti posao s užitkom: shema je fleksibilna i općenita, ali izvukli smo najčešće korištene stupce. Imajte na umu da ovo nije zahtijevalo promjenu umetka i ETLkoji nastavlja umetanje nizova u tablicu. Upravo jesmo ALTER TABLE, dodao par zvučnika i dobili smo hibridnu i bržu shemu koju možete odmah početi koristiti.

Kodeci i kompresija

za vremenske serije Važno je koliko dobro upakirate podatke jer količina informacija može biti vrlo velika. U klikanica Postoji skup alata za postizanje učinka kompresije od 1:10, 1:20, a ponekad i više. To znači da 1 TB neraspakiranih podataka na disku zauzima 50-100 GB. Manja veličina je dobra, podaci se mogu čitati i brže obraditi.

Da biste postigli visoku razinu kompresije, klikanica 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, a sigurno ćemo dodati još LZ4 kompresija. Kao rezultat toga, veličina podataka na disku je znatno smanjena:

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

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

Vidi se da tablice s kodecima zauzimaju puno manje prostora.

Veličina je važna

Ne manje važno odabrati ispravan tip podataka:

U svim gornjim primjerima koje sam koristio Plutanje64. Ali ako smo birali Plutanje32, onda bi to bilo još bolje. To su dobro pokazali dečki iz Perkone u gore navedenom članku. Važno je koristiti najkompaktniji tip koji je prikladan za zadatak: čak i manje za veličinu diska nego za brzinu upita. klikanica vrlo osjetljiv na ovo.

Ako možete koristiti intxnumx umjesto intxnumx, očekujte gotovo dvostruko povećanje performansi. Podaci zauzimaju manje memorije, a sva "aritmetika" radi mnogo brže. klikanica interno je to vrlo strogo tipiziran sustav, maksimalno iskorištava sve mogućnosti koje moderni sustavi pružaju.

Agregacija i Materijalizirani pogledi

Agregacija i materijalizirani pogledi omogućuju vam stvaranje agregata za različite prilike:

Na primjer, možete imati neagregirane izvorne podatke i možete im priložiti različite materijalizirane poglede s automatskim zbrajanjem putem posebnog mehanizma SummingMergeTree (SMT). SMT je posebna struktura agregatnih podataka koja automatski izračunava agregate. Neobrađeni podaci ubacuju se u bazu podataka, automatski se agregiraju i na njima se odmah mogu koristiti nadzorne ploče.

TTL - “zaboravite” stare podatke

Kako “zaboraviti” podatke koji više nisu potrebni? klikanica zna kako to učiniti. Prilikom izrade tablica možete odrediti TTL izrazi: na primjer, da pohranjujemo minutne podatke za jedan dan, dnevne podatke za 30 dana i nikada ne dodirujemo tjedne 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 - podijeliti podatke po diskovima

Uzimajući ovu ideju dalje, podaci se mogu pohraniti u klikanica na različitim mjestima. Pretpostavimo da želimo pohraniti vruće podatke za prošli tjedan na vrlo brzom lokalu SSD, a više povijesnih podataka stavljamo na drugo mjesto. U klikanica ovo je sada moguće:

Možete konfigurirati pravila pohrane (politika skladištenja) Dakle klikanica će automatski prenijeti podatke nakon postizanja određenih uvjeta u drugu pohranu.

Ali to nije sve. Na razini određene tablice možete definirati pravila za točno vrijeme kada podaci idu u hladno skladište. Primjerice, podaci se na vrlo brzom disku čuvaju 7 dana, a sve što je starije prebacuje se na spori. Ovo je dobro jer vam omogućuje da sustav održite na maksimalnim performansama, dok kontrolirate troškove i ne gubite novac na hladne podatke:

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

Jedinstvene značajke klikanica

Gotovo u svemu klikanica Postoje takvi "istaknuti", ali oni su nadoknađeni ekskluzivnošću - nečim čega nema u drugim bazama podataka. Na primjer, ovdje su neke od jedinstvenih značajki klikanica:

nizovi. U klikanica vrlo dobra podrška za nizove, kao i mogućnost izvođenja složenih izračuna na njima.
Agregiranje struktura podataka. Ovo je jedna od "ubojitih karakteristika" klikanica. Unatoč činjenici da dečki iz Yandexa kažu da ne želimo agregirati podatke, sve je agregirano u klikanica, jer je brz i praktičan.
Materijalizirani pogledi. Zajedno s agregirajućim strukturama podataka, materijalizirani pogledi omogućuju vam da učinite praktičnim stvarnom vremenu agregacija.
ClickHouse SQL. Ovo je proširenje jezika SQL s nekim dodatnim i ekskluzivnim značajkama koje su dostupne samo u klikanica. Prije je to s jedne strane bilo kao ekspanzija, a s druge strane nedostatak. Sada gotovo sve nedostatke u usporedbi s SQL 92 uklonili smo ga, sada je samo proširenje.
Lambda– izrazi. Jesu li još u nekoj bazi podataka?
ML- podrška. Ovo je dostupno u različitim bazama podataka, neke su bolje, neke lošije.
otvoreni izvor. Možemo se proširiti klikanica zajedno. Sada unutra klikanica oko 500 suradnika, a taj broj stalno raste.

Varljivi upiti

В klikanica postoji mnogo različitih načina da učinite istu stvar. Na primjer, možete vratiti posljednju vrijednost iz tablice na tri različita načina za CPU (ima i četvrti, ali je još egzotičniji).

Prvi pokazuje koliko je to zgodno raditi u klikanica upite kada to želite provjeriti torka koji se nalazi u podupitu. To je nešto što je meni osobno jako nedostajalo u drugim bazama podataka. Ako želim nešto usporediti s podupitom, tada se u drugim bazama podataka s tim može usporediti samo skalar, ali za nekoliko stupaca moram napisati PRIDRUŽITE. U klikanica 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)

Druga metoda čini istu stvar, ali koristi agregatnu funkciju argMax:

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

В klikanica postoji nekoliko desetaka agregatnih funkcija, a ako koristite kombinatore, tada ćete prema zakonima kombinatorike dobiti oko tisuću njih. ArgMax - jedna od funkcija koja izračunava maksimalnu vrijednost: zahtjev vraća vrijednost usage_user, pri kojoj se postiže 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 PRIDRUŽITE SE — “lijepljenje” redaka s različitim vremenima. Ovo je jedinstvena značajka za baze podataka koja je dostupna samo u kdb+. Ako postoje dva vremenska niza s različitim vremenima, ASOF PRIDRUŽITE SE omogućuje vam da ih premjestite i spojite u jedan zahtjev. Za svaku vrijednost u jednoj vremenskoj seriji pronalazi se najbliža vrijednost u drugoj i one se vraćaju u istom retku:

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;

В klikanica Ne možete to učiniti - ne podržava standard SQL-2003 i vjerojatno to nikada neće učiniti. Umjesto toga, u klikanica Uobičajeno je pisati ovako:

Obećao sam lambde - evo ih!

Ovo je analogija analitičkog upita u standardu SQL-2003: on računa razliku između to dvoje vremenska oznaka, trajanje, redni broj - sve ono što obično smatramo analitičkim funkcijama. U klikanica Brojimo ih kroz nizove: prvo sažimamo podatke u niz, nakon toga na nizu radimo sve što želimo, a zatim ga ponovno proširujemo. Nije baš zgodno, zahtijeva minimalnu ljubav prema funkcionalnom programiranju, ali je vrlo fleksibilno.

Posebne funkcije

Osim toga, u klikanica mnoge specijalizirane funkcije. Na primjer, kako odrediti koliko se sesija odvija istovremeno? Tipičan zadatak praćenja je određivanje maksimalnog opterećenja jednim zahtjevom. U klikanica U tu svrhu postoji posebna funkcija:

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

trčanjeRazlika, trčanjeAkumulacija, susjed;
sumMap(ključ, vrijednost);
timeSeriesGroupSum(uid, timestamp, value);
timeSeriesGroupRateSum(uid, timestamp, value);
skewPop, skewSamp, kurtPop, kurtSamp;
SA ISPUNOM / SA VEZICAMA;
jednostavnaLinearnaRegresija, stohastičkaLinearnaRegresija.

Ovo nije potpuni popis funkcija, ima ih ukupno 500-600. Savjet: sve funkcije u klikanica nalazi se u tablici sustava (nisu svi dokumentirani, ali su svi zanimljivi):

select * from system.functions order by name

klikanica pohranjuje mnogo informacija o sebi, uključujući log tablice, dnevnik_upita, dnevnik praćenja, dnevnik operacija s blokovima podataka (part_log), zapisnik metrike i zapisnik sustava, koji obično zapisuje na disk. Log metrics je vremenske serije в klikanica zapravo klikanica: Sama baza podataka može igrati ulogu vremenske serije baze podataka, te tako “proždire” samu sebe.

Ovo je također jedinstvena stvar - jer radimo dobar posao za vremenske serije, zašto sve što nam treba ne možemo pohraniti u sebe? Mi ne trebamo Prometej, sve držimo za sebe. Povezan grafana i nadgledamo sami sebe. Međutim, ako klikanica padne, nećemo vidjeti zašto, pa to obično ne čine.

Veliki grozd ili mnogo malih klikanica

Što je bolje - jedan veliki klaster ili mnogo malih ClickHousesa? Tradicionalni pristup DWH je veliki klaster u kojem su sklopovi dodijeljeni svakoj aplikaciji. Došli smo do administratora baze podataka - dajte nam dijagram, a oni su nam dali jedan:

В klikanica možete to učiniti drugačije. Svaku aplikaciju možete napraviti vlastitom klikanica:

Ne treba nam više taj veliki monstruoz DWH i neposlušni admini. Svakoj aplikaciji možemo dati vlastitu klikanica, a programer to može učiniti sam, jer klikanica vrlo jednostavan za instalaciju i ne zahtijeva složenu administraciju:

Ali ako imamo puno klikanica, a trebate ga često instalirati, tada želite automatizirati ovaj proces. Za to možemo, na primjer, koristiti Kubernetes и klikanica-operater. U Kubernetes ClickHouse možete ga staviti "na klik": mogu kliknuti gumb, pokrenuti manifest i baza podataka je spremna. Mogu odmah izraditi dijagram, tamo početi učitavati metrike i za 5 minuta imam spremnu nadzornu ploču grafana. Tako je jednostavno!

Rezultat?

Dakle, klikanica - ovo:

brzo. Svi to znaju.
samo. Malo kontroverzno, ali vjerujem da je teško na treningu, lako u borbi. Ako razumijete kako klikanica radi, onda je sve vrlo jednostavno.
Univerzalno. Pogodan je za različite scenarije: DWH, vremenski niz, pohrana dnevnika. Ali nije OLTP baze podataka, stoga ne pokušavajte tamo raditi kratke umetke i čitanja.
Zanimljivo. Vjerojatno onaj koji radi sa klikanica, doživio mnoge zanimljive trenutke u dobrom i lošem smislu. Na primjer, izašlo je novo izdanje, sve je prestalo raditi. Ili kada ste se dva dana mučili sa zadatkom, ali nakon postavljanja pitanja u Telegram chatu zadatak je riješen za dvije minute. Ili kao na konferenciji na izvješću Leshe Milovidova, snimka zaslona klikanica prekinuo prijenos Visoko opterećenje++. Ovakve stvari se stalno događaju i otežavaju nam život. klikanica svijetle i zanimljive!

Možete pogledati prezentaciju здесь.

Dugo očekivani sastanak programera visokoopterećenih sustava u Visoko opterećenje++ održat će se 9. i 10. studenog u Skolkovu. Konačno, ovo će biti offline konferencija (iako uz sve mjere opreza), budući da se energija HighLoad++ ne može pakirati online.

Za konferenciju pronalazimo i prikazujemo vam slučajeve o maksimalnim mogućnostima tehnologije: HighLoad++ je bio, jest i bit će jedino mjesto gdje u dva dana možete naučiti kako funkcioniraju Facebook, Yandex, VKontakte, Google i Amazon.

Nakon što naše susrete održavamo bez prekida od 2007. godine, ove ćemo se godine sastati po 14. put. Tijekom tog vremena konferencija je narasla 10 puta; prošle je godine ključni događaj u industriji okupio 3339 sudionika, 165 govornika, izvještaja i susreta, a 16 staza se odvijalo istovremeno.
Prošle godine bilo je 20 autobusa, 5280 litara čaja i kave, 1650 litara voćnih napitaka i 10200 boca vode. I još 2640 kilograma hrane, 16 tanjura i 000 šalica. Inače, novcem prikupljenim od recikliranog papira posadili smo 25 sadnica hrasta :)

Možete kupiti ulaznice здесь, saznajte novosti o konferenciji - здесь, i razgovarati na svim društvenim mrežama: Telegram, Facebook, Vkontakte и X / Twitter.

Izvor: www.habr.com

Prelazak u ClickHouse: 3 godine kasnije