🥇Selitev v ClickHouse: 3 leta pozneje

Pred tremi leti Viktor Tarnavsky in Alexey Milovidov iz Yandexa na odru HighLoad ++ povedal, kako dober je ClickHouse in kako ne upočasnjuje. In na naslednji stopnji je bilo Aleksander Zajcev с poročilo o selitvi v KlikniteHouse iz drugega analitičnega DBMS in z ugotovitvijo, da KlikniteHouse, seveda, dobro, vendar ne zelo priročno. Ko je leta 2016 podjetje LifeStreet, kjer je Alexander takrat delal, je pretvarjal večpetabajtni analitični sistem v KlikniteHouse, je bila fascinantna »rumena cesta«, polna neznanih nevarnosti - KlikniteHouse takrat je bilo videti kot minsko polje.

Tri leta kasneje KlikniteHouse postal veliko boljši - v tem času je Alexander ustanovil podjetje Altinity, ki ljudem ne pomaga le pri selitvi v KlikniteHouse več deset projektov, ampak tudi izboljšuje sam izdelek skupaj s kolegi iz Yandexa. zdaj KlikniteHouse še vedno ni brezskrben sprehod, a ne več minsko polje.

Alexander dela s porazdeljenimi sistemi od leta 2003 in razvija velike projekte MySQL, Oracle и Vertica. Na zadnji HighLoad ++ 2019 Aleksander, eden od pionirjev uporabe KlikniteHouse, povedal, kaj je zdaj ta DBMS. Spoznali bomo glavne značilnosti KlikniteHouse: v čem se razlikuje od drugih sistemov in v katerih primerih ga je bolj učinkovito uporabljati. Na primerih si bomo ogledali nedavne in projektno preizkušene prakse za gradnjo sistemov, ki temeljijo na KlikniteHouse.

Retrospektiva: kaj se je zgodilo pred 3 leti

Pred tremi leti smo prenesli podjetje LifeStreet o KlikniteHouse iz druge analitične baze podatkov, selitev analitike oglasnega omrežja pa je izgledala takole:

junij 2016. In Open source pojavil KlikniteHouse in naš projekt se je začel;
Avgusta. Dokaz koncepta: velika oglaševalska mreža, infrastruktura in 200-300 terabajtov podatkov;
oktobra. Prvi proizvodni podatki;
decembra. Polna obremenitev izdelka je 10–50 milijard dogodkov na dan.
Junij 2017. Uspešna selitev uporabnikov na KlikniteHouse, 2,5 petabajta podatkov v gruči 60 strežnikov.

Med migracijskim procesom je raslo razumevanje, da KlikniteHouse je dober sistem, s katerim je prijetno delati, vendar je to notranji projekt Yandexa. Zato obstajajo nianse: Yandex se bo najprej ukvarjal s svojimi notranjimi strankami in šele nato s skupnostjo in potrebami zunanjih uporabnikov, ClickHouse pa nato na številnih funkcionalnih področjih ni dosegel ravni podjetja. Zato smo marca 2017 ustanovili Altinity, da bi KlikniteHouse še hitreje in bolj priročno ne samo za Yandex, ampak tudi za druge uporabnike. In zdaj mi:

Usposabljamo in pomagamo graditi rešitve na podlagi KlikniteHouse da stranke ne zaidejo v težave in da rešitev na koncu deluje;
Nudimo podporo 24/7 KlikniteHouse- instalacije;
Razvijamo lastne ekosistemske projekte;
Aktivno se posvečamo sebi KlikniteHouse, ki odgovarja na zahteve uporabnikov, ki želijo videti določene funkcije.

In seveda pomagamo pri selitvi v KlikniteHouse с MySQL, Vertica, Oracle, Zelena sliva, Redshift in drugi sistemi. Sodelovali smo pri različnih potezah in vse so bile uspešne.

Zakaj se preseliti v KlikniteHouse

Ne upočasni! To je glavni razlog. KlikniteHouse - zelo hitra zbirka podatkov za različne scenarije:

Naključni citati ljudi, ki že dolgo delajo z ljudmi KlikniteHouse.

Razširljivost. Na neki drugi bazi podatkov lahko dosežete dobro zmogljivost na enem kosu strojne opreme, vendar KlikniteHouse lahko povečate ne samo navpično, ampak tudi vodoravno, preprosto z dodajanjem strežnikov. Ne gre vse tako gladko, kot bi si želeli, a gre. Sistem lahko razširite, ko vaše podjetje raste. Pomembno je, da zdaj nismo omejeni z rešitvijo in vedno obstaja potencial za razvoj.

Prenosljivost. Ni navezanosti na eno stvar. Na primer, z Amazon RedShift Težko se je kam premakniti. A KlikniteHouse lahko ga namestite na prenosni računalnik, strežnik, uvedete v oblak, obiščete Kubernetes — ni nobenih omejitev glede delovanja infrastrukture. To je priročno za vsakogar in to je velika prednost, s katero se mnoge druge podobne baze podatkov ne morejo pohvaliti.

Prilagodljivost. KlikniteHouse se ne ustavi pri eni stvari, na primer Yandex.Metrica, ampak se razvija in uporablja v vedno več različnih projektih in panogah. Lahko se razširi z dodajanjem novih zmogljivosti za reševanje novih problemov. Na primer, menijo, da je shranjevanje dnevnikov v bazi podatkov slaba manira, zato so se domislili Elastično iskanje. Toda zahvaljujoč fleksibilnosti KlikniteHouse, vanj lahko shranjujete tudi polena, pogosto pa je to celo bolje kot v Elastično iskanje - v KlikniteHouse to zahteva 10-krat manj železa.

Brezplačen open Source. Ničesar vam ni treba plačati. Za namestitev sistema na prenosni računalnik ali strežnik se ni treba pogajati za dovoljenje. Brez skritih stroškov. Hkrati se nobena druga odprtokodna tehnologija baze podatkov ne more kosati s hitrostjo KlikniteHouse. MySQL, MariaDB, Greenplum - vsi so veliko počasnejši.

Skupnost, pogon in zabava. Imam KlikniteHouse odlična skupnost: srečanja, klepeti in Alexey Milovidov, ki nas vse napolni s svojo energijo in optimizmom.

Selitev v ClickHouse

Iti KlikniteHouse iz nekega razloga potrebujete samo tri stvari:

Razumeti omejitve KlikniteHouse in za kaj ni primeren.
Izkoristiti tehnologijo in njene največje prednosti.
Eksperimentirajte. Celo razumevanje, kako deluje KlikniteHouse, ni vedno mogoče predvideti, kdaj bo hitrejši, kdaj počasnejši, kdaj bo boljši in kdaj slabši. Torej poskusite.

Težave s premikanjem

Obstaja samo en "ampak": če se preselite v KlikniteHouse od česa drugega, potem gre običajno kaj narobe. Navajeni smo nekaterih praks in stvari, ki delujejo v naši najljubši bazi podatkov. Na primer, kdorkoli dela s SQPodatkovne baze L obravnavajo naslednji nabor funkcij kot obveznega:

transakcije;
omejitve;
doslednost;
indeksi;
POSODOBI/IZBRIŠI;
NULL;
milisekunde;
avtomatski tipski ulitki;
več združevanj;
poljubne predelne stene;
orodja za upravljanje grozdov.

Zaposlovanje je obvezno, a je pred tremi leti v KlikniteHouse Nobena od teh funkcij ni bila na voljo! Zdaj ostaja manj kot polovica tega, kar še ni bilo implementirano: transakcije, omejitve, doslednost, milisekunde in pretvorba vrst.

In glavno je, da v KlikniteHouse nekatere standardne prakse in pristopi ne delujejo ali delujejo drugače, kot smo vajeni. Vse, kar se pojavi v KlikniteHouse, odgovarja "ClickHouse način", tj. funkcije razlikujejo od drugih baz podatkov. Na primer:

Indeksi niso izbrani, ampak preskočeni.
POSODOBI/IZBRIŠI ne sinhrono, ampak asinhrono.
Obstaja več združevanj, vendar ni načrtovalca poizvedb. Kako se nato izvajajo, ljudem iz sveta baz podatkov na splošno ni zelo jasno.

Skripte ClickHouse

Leta 1960 ameriški matematik madžarskega porekla Wigner EP napisal članek "Nerazumna učinkovitost matematike v naravoslovju” (“Nerazumljiva učinkovitost matematike v naravoslovju”), da svet okoli nas iz neznanega razloga dobro opisujejo matematični zakoni. Matematika je abstraktna znanost in fizikalni zakoni, izraženi v matematični obliki, niso trivialni in Wigner EP poudaril, da je to zelo čudno.

Z mojega vidika, KlikniteHouse - ista nenavadnost. Če preoblikujemo Wignerja, lahko rečemo takole: nepojmljiva učinkovitost je osupljiva KlikniteHouse v najrazličnejših analitičnih aplikacijah!

Na primer, vzemimo Podatkovno skladišče v realnem času, v katerega se skoraj neprekinjeno nalagajo podatki. Od njega želimo prejemati zahteve z drugo zamudo. Prosim - uporabite ga KlikniteHouse, ker je to scenarij, za katerega je bil zasnovan. KlikniteHouse natanko tako se uporablja ne samo na spletu, ampak tudi v trženju in finančni analitiki, AdTech, pa tudi v Odkrivanje goljufijn. IN Podatkovno skladišče v realnem času uporablja se kompleksna strukturirana shema, kot sta "zvezda" ali "snežinka", številne tabele z PRIDRUŽITE (včasih več), podatki pa se običajno shranjujejo in spreminjajo v nekaterih sistemih.

Vzemimo drug scenarij - Časovne serije: spremljanje naprav, omrežij, statistika uporabe, internet stvari. Tu naletimo na dokaj preproste dogodke, urejene v času. KlikniteHouse prvotno ni bil razvit za to, vendar se je izkazal za dobro delo, zato ga uporabljajo velika podjetja KlikniteHouse kot repozitorij za spremljanje informacij. Raziskati, ali je primeren KlikniteHouse za časovne serije smo na podlagi pristopa in rezultatov izdelali merilo InfluxDB и Časovni okvirDB - specializirano Časovne serije baze podatkov. Izkazalo se jeTo KlikniteHouse, tudi brez optimizacije za take naloge zmaga na tujem terenu:

В Časovne serije Običajno se uporablja ozka tabela - več majhnih stolpcev. Iz spremljanja lahko pride veliko podatkov – na milijone zapisov na sekundo – in običajno prihajajo v majhnih izbruhih (v realnem času pretakanje). Zato je potreben drug skript za vstavljanje, same poizvedbe pa imajo svoje posebnosti.

upravljanje log. Zbiranje dnevnikov v bazo podatkov je običajno slabo, vendar KlikniteHouse to je mogoče storiti z nekaj komentarji, kot je opisano zgoraj. Mnoga podjetja uporabljajo KlikniteHouse točno v ta namen. V tem primeru uporabimo ravno široko mizo, kamor shranimo celotne hlode (npr. v obliki JSON), ali narežemo na koščke. Podatki se običajno nalagajo v velikih paketih (datotekah), iščemo pa po nekem polju.

Za vsako od teh funkcij se običajno uporabljajo specializirane zbirke podatkov. KlikniteHouse nekdo zmore vse in tako dobro, da jih prekaša. Poglejmo zdaj pobližje Časovne serije scenarij in kako pravilno »kuhati«. KlikniteHouse za ta scenarij.

Časovne serije

Trenutno je to glavni scenarij, za katerega KlikniteHouse velja za standardno rešitev. Časovne serije je niz dogodkov, urejenih v času, ki predstavljajo spremembe v nekem procesu skozi čas. To je lahko na primer srčni utrip na dan ali število procesov v sistemu. Vse, kar daje času tiktaka z nekimi dimenzijami, je Časovne serije:

Večina tovrstnih dogodkov izvira iz spremljanja. To je lahko ne samo spremljanje spleta, ampak tudi resnične naprave: avtomobili, industrijski sistemi, Internet stvari, tovarne ali taksiji brez posadke, v prtljažnik katerih že spravlja Yandex KlikniteHouse-strežnik.

Na primer, obstajajo podjetja, ki zbirajo podatke z ladij. Vsakih nekaj sekund senzorji na kontejnerski ladji pošljejo na stotine različnih meritev. Inženirji jih preučujejo, izdelujejo modele in poskušajo razumeti, kako učinkovito je plovilo izkoriščeno, saj kontejnerska ladja ne bi smela mirovati niti sekunde. Vsak izpad je izguba denarja, zato je pomembno predvideti pot, da bo zastojev čim manj.

Danes rastejo specializirane baze podatkov, ki merijo Časovne serije. Na strani DB-motorji Različne zbirke podatkov so nekako razvrščene in si jih lahko ogledate po vrsti:

Najhitreje rastoča vrsta je Časovne serijes. Rastejo tudi baze podatkov grafov, vendar Časovne serijev zadnjih nekaj letih rastejo hitreje. Tipični predstavniki te družine baz podatkov so InfluxDB, Prometej, KDB, Časovni okvirDB (zgrajen na PostgreSQL), rešitve iz Amazon. KlikniteHouse se lahko uporablja tudi tukaj in se uporablja. Naj vam navedem nekaj javnih primerov.

Eden od pionirjev je podjetje CloudFlare (CDN-ponudnik). Spremljajo svoje CDN prek KlikniteHouse (DNS- prošnje, HTTP-poizvedbe) z veliko obremenitvijo - 6 milijonov dogodkov na sekundo. Vse gre skozi Kafka, gre v KlikniteHouse, ki omogoča vpogled v nadzorne plošče dogodkov v sistemu v realnem času.

Comcast - eden vodilnih v telekomunikacijah v ZDA: internet, digitalna televizija, telefonija. Ustvarili so podoben nadzorni sistem CDN v tem okviru open Source projekt Nadzor prometa Apache za delo z vašimi ogromnimi podatki. KlikniteHouse uporablja kot zaledje za analitiko.

Percona vgrajen KlikniteHouse znotraj tvojega PMMza shranjevanje spremljanje različnih MySQL.

Posebne zahteve

Podatkovne zbirke časovnih vrst imajo svoje posebne zahteve.

Hitro vstavljanje številnih agentov. Zelo hitro moramo vstaviti podatke iz številnih tokov. KlikniteHouse To počne dobro, ker vsi njegovi vložki ne blokirajo. Kaj vstavite je nova datoteka na disku, majhni vstavki pa se lahko tako ali drugače shranijo v medpomnilnik. IN KlikniteHouse Bolje je, da podatke vnašate v velikih serijah, kot pa eno vrstico naenkrat.
Prilagodljiva shema. V Časovne serije običajno strukture podatkov ne poznamo popolnoma. Možno je zgraditi nadzorni sistem za določeno aplikacijo, vendar ga je potem težko uporabiti za drugo aplikacijo. To zahteva bolj prožno shemo. KlikniteHouse, vam to omogoča, čeprav gre za močno tipizirano osnovo.
Učinkovito shranjevanje in pozabljanje podatkov. Ponavadi v Časovne serije ogromno podatkov, zato morajo biti shranjeni čim bolj učinkovito. Na primer, pri InfluxDB dobra kompresija je njegova glavna značilnost. Toda poleg shranjevanja morate imeti možnost tudi »pozabiti« stare podatke in narediti nekaj zmanjšanje vzorčenja — samodejno štetje agregatov.
Hitre poizvedbe po zbirnih podatkih. Včasih je zanimivo pogledati zadnjih 5 minut z natančnostjo do milisekunde, pri mesečnih podatkih pa razdrobljenost minut ali sekund morda ne bo potrebna - dovolj je splošna statistika. Tovrstna podpora je nujna, sicer se bo zahteva za 3 mesece zelo dolgo izpolnjevala tudi v KlikniteHouse.
Zahteve, kot je "zadnja točka, od». Te so značilne za Časovne serije poizvedbe: poglejte zadnjo meritev ali stanje sistema v določenem trenutku t. To niso zelo prijetne poizvedbe za podatkovno bazo, vendar jih morate znati tudi izvesti.
»Lepljenje« časovnih vrst. Časovne serije je časovna vrsta. Če obstajata dve časovni vrsti, ju je pogosto treba povezati in korelirati. To ni priročno narediti v vseh bazah podatkov, zlasti pri neusklajenih časovnih serijah: tukaj so nekatere časovne točke, druge so. Lahko upoštevate povprečje, a nenadoma bo tam še vedno luknja, tako da ni jasno.

Poglejmo, kako so te zahteve izpolnjene KlikniteHouse.

Shema

В KlikniteHouse shema za Časovne serije je mogoče izvesti na različne načine, odvisno od stopnje pravilnosti podatkov. Na običajnih podatkih je mogoče zgraditi sistem, ko poznamo vse metrike vnaprej. Na primer, naredil sem to CloudFlare s spremljanjem CDN je dobro optimiziran sistem. Lahko zgradite bolj splošen sistem, ki spremlja celotno infrastrukturo in različne storitve. Pri nepravilnih podatkih ne vemo vnaprej, kaj spremljamo – in to je verjetno najpogostejši primer.

Redni podatki. Stolpci. Shema je preprosta - stolpci z zahtevanimi vrstami:

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

To je navadna tabela, ki spremlja nekakšno aktivnost nalaganja sistema (uporabnik, sistem, nedejaven, lepo). Enostavno in priročno, vendar ne prilagodljivo. Če želimo bolj prilagodljivo shemo, potem lahko uporabimo nize.

Nepravilni podatki. Nizi:

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 Gnezdi sta dva niza: metrics.name и metrics.value. Tukaj lahko shranite tako poljubne podatke spremljanja kot niz imen in niz meritev za vsak dogodek. Za nadaljnjo optimizacijo lahko namesto ene takšne strukture naredite več. Na primer, enega za float-vrednost, drugo - za int- kar pomeni, ker int Želim učinkoviteje shranjevati.

Toda takšna struktura je težje dostopna. Uporabiti boste morali posebno konstrukcijo, z uporabo posebnih funkcij, da izvlečete vrednosti najprej indeksa in nato matrike:

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

Ampak še vedno deluje precej hitro. Drug način za shranjevanje nepravilnih podatkov je po vrsticah.

Nepravilni podatki. Strune. Pri tej tradicionalni metodi, brez nizov, so imena in vrednosti shranjeni hkrati. Če iz ene naprave naenkrat pride 5 meritev, se v bazi podatkov ustvari 000 vrstic:

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

KlikniteHouse se spopade s tem - ima posebne razširitve KlikniteHouse SQL. Na primer maxIf — posebna funkcija, ki izračuna maksimum z metriko, ko je izpolnjen nek pogoj. V eno zahtevo lahko napišete več takih izrazov in takoj izračunate vrednost za več metrik.

Primerjajmo tri pristope:

podrobnosti

Tukaj sem dodal "Velikost podatkov na disku" za nekaj nabora testnih podatkov. Pri stolpcih imamo najmanjšo velikost podatkov: maksimalno stiskanje, največjo hitrost poizvedovanja, vendar plačamo tako, da moramo zabeležiti vse naenkrat.

Pri nizih je vse malo slabše. Podatki so še vedno dobro stisnjeni in lahko se shrani nepravilen vzorec. Ampak KlikniteHouse - stolpčna zbirka podatkov, in ko začnemo vse shranjevati v matriko, se ta spremeni v vrstično, fleksibilnost pa plačamo z učinkovitostjo. Za vsako operacijo boste morali celotno matriko prebrati v pomnilnik, nato pa v njej poiskati želeni element - in če matrika raste, se hitrost zmanjša.

V enem od podjetij, ki uporablja ta pristop (npr. Uber), nizi so razrezani na kose po 128 elementov. Podatki iz več tisoč metrik z volumnom 200 TB podatkov/dan se ne shranjujejo v enem polju, temveč v 10 ali 30 nizih s posebno logiko shranjevanja.

Najenostavnejši pristop je z nizi. Toda podatki so slabo stisnjeni, velikost tabele je velika in tudi če poizvedbe temeljijo na več metrikah, ClickHouse ne deluje optimalno.

Hibridna shema

Predpostavimo, da smo izbrali matrično vezje. Toda če vemo, da večina naših nadzornih plošč prikazuje le uporabniške in sistemske meritve, lahko te meritve dodatno materializiramo v stolpce iz matrike na ravni tabele na ta 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);

Pri vstavljanju KlikniteHouse jih bo samodejno preštel. Tako lahko združite posel z užitkom: shema je prilagodljiva in splošna, vendar smo izločili najpogosteje uporabljene stolpce. Upoštevajte, da za to ni bilo treba spremeniti vložka in ETLki nadaljuje z vstavljanjem nizov v tabelo. Pravkar smo ALTER TABLE, dodali nekaj zvočnikov in dobili smo hibridno in hitrejšo shemo, ki jo lahko začnete uporabljati takoj.

Kodeki in stiskanje

Za Časovne serije Pomembno je, kako dobro zapakirate podatke, saj je količina informacij lahko zelo velika. IN KlikniteHouse Obstaja nabor orodij za doseganje učinka stiskanja 1:10, 1:20 in včasih več. To pomeni, da 1 TB nepakiranih podatkov na disku zavzame 50-100 GB. Manjša velikost je dobra, podatke je mogoče brati in hitreje obdelati.

Da bi dosegli visoko stopnjo kompresije, KlikniteHouse podpira naslednje kodeke:

Primer tabele:

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

Tukaj definiramo kodek DoubleDelta v enem primeru, v drugem - Gorilla, in zagotovo bomo dodali še več LZ4 stiskanje. Posledično se velikost podatkov na disku močno zmanjša:

To prikazuje, koliko prostora zavzamejo isti podatki, vendar z uporabo različnih kodekov in kompresij:

v datoteki GZIP na disku;
v ClickHouse brez kodekov, vendar s kompresijo ZSTD;
v ClickHouse s kodeki in kompresijo LZ4 in ZSTD.

Vidi se, da tabele s kodeki zavzamejo veliko manj prostora.

Velikost je pomembna

Nič manj pomembno выбрать pravilen tip podatkov:

V vseh zgornjih primerih, ki sem jih uporabil Float64. Ampak, če smo izbrali Float32, potem bi bilo še bolje. To so fantje iz Perkone dobro prikazali v članku na zgornji povezavi. Pomembno je, da uporabite najbolj kompakten tip, ki je primeren za nalogo: celo manj za velikost diska kot za hitrost poizvedbe. KlikniteHouse zelo občutljiv na to.

Če lahko uporabite intxnumx namesto intxnumx, potem pričakujte skoraj dvakratno povečanje zmogljivosti. Podatki zavzamejo manj pomnilnika, vsa "aritmetika" pa deluje veliko hitreje. KlikniteHouse interno je zelo strogo tipiziran sistem, ki maksimalno izkorišča vse možnosti, ki jih sodobni sistemi ponujajo.

Združevanje in Materializirani pogledi

Združevanje in materializirani pogledi vam omogočajo ustvarjanje agregatov za različne priložnosti:

Na primer, morda imate neagregirane izvorne podatke in jim lahko pripnete različne materializirane poglede s samodejnim seštevanjem prek posebnega mehanizma SummingMergeTree (SMT). SMT je posebna struktura združevanja podatkov, ki samodejno izračunava agregate. Neobdelani podatki se vstavijo v bazo podatkov, se samodejno združijo in nadzorne plošče lahko takoj uporabite na njih.

TTL - »pozabite« stare podatke

Kako »pozabiti« podatke, ki jih ne potrebujemo več? KlikniteHouse ve, kako to narediti. Pri ustvarjanju tabel lahko določite TTL izrazi: na primer, da hranimo minutne podatke za en dan, dnevne podatke za 30 dni in se nikoli ne dotikamo tedenskih ali mesečnih podatkov:

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

Večstopenjski - razdelite podatke po diskih

Če nadaljujemo s to idejo, lahko podatke shranimo v KlikniteHouse na različnih mestih. Recimo, da želimo shraniti vroče podatke za zadnji teden na zelo hitrem lokalu SSD, več zgodovinskih podatkov pa smo postavili na drugo mesto. IN KlikniteHouse to je sedaj možno:

Konfigurirate lahko politiko shranjevanja (politiko shranjevanja) Torej KlikniteHouse samodejno prenese podatke, ko doseže določene pogoje, v drugo shrambo.

A to še ni vse. Na ravni določene tabele lahko definirate pravila, kdaj točno gredo podatki v hladilnico. Podatki se na primer na zelo hitrem disku hranijo 7 dni, vse, kar je starejše, pa se prenese na počasnega. To je dobro, ker vam omogoča, da ohranite sistem pri največji zmogljivosti, hkrati pa nadzorujete stroške in ne zapravljate denarja za hladne podatke:

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

Edinstvene značilnosti KlikniteHouse

Skoraj v vsem KlikniteHouse Obstajajo takšni "poudarki", vendar jih izravnava ekskluzivnost - nekaj, česar ni v drugih zbirkah podatkov. Tukaj je na primer nekaj edinstvenih funkcij KlikniteHouse:

Nizi. V KlikniteHouse zelo dobra podpora za polja, pa tudi možnost izvajanja kompleksnih izračunov na njih.
Združevanje podatkovnih struktur. To je ena od "ubijalskih lastnosti" KlikniteHouse. Kljub temu, da fantje iz Yandexa pravijo, da ne želimo združevati podatkov, je vse združeno v KlikniteHouse, ker je hiter in priročen.
Materializirani pogledi. Skupaj z združevanjem podatkovnih struktur vam materializirani pogledi omogočajo priročno v realnem času združevanje.
ClickHouse SQL. To je jezikovna razširitev SQL z nekaterimi dodatnimi in ekskluzivnimi funkcijami, ki so na voljo samo v KlikniteHouse. Prej je bilo to po eni strani kot širitev, po drugi pa slabost. Zdaj skoraj vse slabosti v primerjavi z SQL 92 odstranili smo ga, zdaj je samo podaljšek.
Lambda– izrazi. So še v kakšni bazi?
ML- podpora. To je na voljo v različnih zbirkah podatkov, nekatere so boljše, druge slabše.
Odprtokodno. Lahko se razširimo KlikniteHouse skupaj. Zdaj noter KlikniteHouse okoli 500 sodelujočih in ta številka nenehno raste.

Zapletena vprašanja

В KlikniteHouse obstaja veliko različnih načinov za isto stvar. Na primer, zadnjo vrednost iz tabele lahko vrnete na tri različne načine za CPU (obstaja tudi četrti, a je še bolj eksotičen).

Prvi prikazuje, kako priročno je to narediti v KlikniteHouse poizvedbe, ko želite to preveriti tuple ki jih vsebuje podpoizvedba. To je nekaj, kar sem osebno zelo pogrešal v drugih zbirkah podatkov. Če želim nekaj primerjati s podpoizvedbo, potem lahko v drugih bazah podatkov z njo primerjam samo skalar, vendar moram za več stolpcev napisati PRIDRUŽITE. V KlikniteHouse lahko uporabite tuple:

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

Druga metoda naredi isto, vendar uporablja agregatno funkcijo argMax:

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

В KlikniteHouse obstaja več deset agregatnih funkcij in če uporabljate kombinatorje, jih boste po zakonih kombinatorike dobili približno tisoč. ArgMax - ena od funkcij, ki izračuna največjo vrednost: zahteva vrne vrednost usage_user, pri kateri je dosežena največja vrednost 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)

PRIDRUŽI SE ASOF — »lepljenje« vrstic z različnimi časi. To je edinstvena funkcija za zbirke podatkov, ki je na voljo samo v kdb+. Če obstajata dve časovni vrsti z različnimi časi, PRIDRUŽI SE ASOF omogoča premikanje in združevanje v eno zahtevo. Za vsako vrednost v eni časovni vrsti je najdena najbližja vrednost v drugi in vrnjeni sta v isti vrstici:

Analitične funkcije

V standardu SQL-2003 lahko napišeš takole:

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;

В KlikniteHouse Tega ne morete storiti - ne podpira standarda SQL-2003 in verjetno tega ne bo nikoli naredil. Namesto tega v KlikniteHouse Običajno je pisati takole:

Obljubil sem lambde - tukaj so!

To je analog analitične poizvedbe v standardu SQL-2003: on šteje razliko med obema časovni žig, trajanje, redna številka - vse, kar običajno štejemo za analitične funkcije. IN KlikniteHouse Štejemo jih skozi nize: najprej podatke strnemo v niz, nato na nizu naredimo vse, kar želimo, nato pa ga razširimo nazaj. Ni zelo priročno, zahteva vsaj ljubezen do funkcionalnega programiranja, je pa zelo prilagodljivo.

Posebne lastnosti

Poleg tega v KlikniteHouse veliko specializiranih funkcij. Na primer, kako ugotoviti, koliko sej poteka hkrati? Tipična naloga spremljanja je določitev največje obremenitve z eno zahtevo. IN KlikniteHouse V ta namen obstaja posebna funkcija:

Na splošno ima ClickHouse posebne funkcije za številne namene:

runDifference, runningAccumulate, сосед;
sumMap(ključ, vrednost);
timeSeriesGroupSum(uid, timestamp, value);
timeSeriesGroupRateSum(uid, timestamp, value);
skewPop, skewSamp, kurtPop, kurtSamp;
S POLNILOM / Z VEZICAMI;
preprosta linearna regresija, stohastična linearna regresija.

To ni popoln seznam funkcij, skupaj jih je 500-600. Namig: vse funkcije v KlikniteHouse je v sistemski tabeli (niso vsi dokumentirani, so pa vsi zanimivi):

select * from system.functions order by name

KlikniteHouse o sebi hrani veliko informacij, med drugim log tabele, query_log, dnevnik sledenja, dnevnik operacij s podatkovnimi bloki (part_log), dnevnik meritev in sistemski dnevnik, ki ga običajno zapiše na disk. Log metrics je Časovne serije в KlikniteHouse pravzaprav KlikniteHouse: Baza podatkov sama lahko igra vlogo Časovne serije baz podatkov in se tako »požre«.

To je tudi edinstvena stvar - saj dobro delamo za Časovne serije, zakaj ne moremo vsega, kar potrebujemo, shraniti v sebi? Ne potrebujemo Prometej, vse držimo zase. Povezan grafana in se spremljamo. Vendar, če KlikniteHouse padcev, ne bomo videli, zakaj, zato tega običajno ne počnejo.

Velik grozd ali veliko majhnih KlikniteHouse

Kaj je bolje - en velik grozd ali več majhnih ClickHouse? Tradicionalni pristop k DWH je velika gruča, v kateri so vezja dodeljena vsaki aplikaciji. Prišli smo do skrbnika baze podatkov - dajte nam diagram in dali so nam ga:

В KlikniteHouse lahko narediš drugače. Vsako aplikacijo lahko naredite po svoje KlikniteHouse:

Velikega pošastnega ne potrebujemo več DWH in nepopustljivi admini. Vsaki aplikaciji lahko damo svojo KlikniteHouse, razvijalec pa lahko to stori sam, saj KlikniteHouse zelo enostaven za namestitev in ne zahteva kompleksne administracije:

Če pa imamo veliko KlikniteHouse, in ga morate pogosto namestiti, potem želite ta postopek avtomatizirati. Za to lahko uporabimo npr Kubernetes и klikhouse- operater. IN Kubernetes ClickHouse lahko ga postavite »na klik«: lahko kliknem gumb, zaženem manifest in zbirka podatkov je pripravljena. Takoj lahko ustvarim diagram, začnem tja nalagati meritve in v 5 minutah imam pripravljeno nadzorno ploščo grafana. Tako preprosto je!

Kakšen je rezultat?

Torej, KlikniteHouse - to je:

Hitro. Vsi to vedo.
Preprosto. Malo kontroverzno, a verjamem, da je težko na treningu, enostavno v boju. Če razumete, kako KlikniteHouse deluje, potem je vse zelo preprosto.
Univerzalno. Primeren je za različne scenarije: DWH, časovne vrste, shranjevanje dnevnika. Ampak ni OLTP baze podatkov, zato tam ne poskušajte delati kratkih vstavkov in branj.
Zanimivo. Verjetno tisti, ki dela s KlikniteHouse, doživel veliko zanimivih trenutkov v dobrem in slabem smislu. Na primer, izšla je nova izdaja, vse je prenehalo delovati. Ali ko ste se dva dni mučili z nalogo, a je bila po vprašanju v klepetu Telegram naloga rešena v dveh minutah. Ali kot na konferenci ob poročilu Leshe Milovidov, posnetek zaslona iz KlikniteHouse prekinil oddajo HighLoad ++. Takšne stvari se dogajajo ves čas in nam otežujejo življenje. KlikniteHouse svetlo in zanimivo!

Predstavitev si lahko ogledate tukaj.

Dolgo pričakovano srečanje razvijalcev visokoobremenjenih sistemov na HighLoad ++ bo 9. in 10. novembra v Skolkovu. Končno bo to konferenca brez povezave (čeprav z vsemi previdnostnimi ukrepi), saj energije HighLoad++ ni mogoče zapakirati na spletu.

Za konferenco najdemo in vam pokažemo primere o največjih zmožnostih tehnologije: HighLoad++ je bil, je in bo edino mesto, kjer se lahko v dveh dneh naučite, kako delujejo Facebook, Yandex, VKontakte, Google in Amazon.

Ker naša srečanja neprekinjeno potekajo že od leta 2007, se bomo letos srečali že 14. V tem času se je konferenca povečala za 10-krat, lani je ključni industrijski dogodek združil 3339 udeležencev, 165 govorcev, poročil in srečanj, hkrati pa je potekalo 16 trakov.
Lani je bilo 20 avtobusov, 5280 litrov čaja in kave, 1650 litrov sadnih pijač in 10200 plastenk vode. In še 2640 kilogramov hrane, 16 krožnikov in 000 skodelic. Mimogrede, z zbranim denarjem od recikliranega papirja smo posadili 25 sadik hrasta :)

Lahko kupite vstopnice tukaj, novice o konferenci - tukaj, in govorite na vseh družbenih omrežjih: Telegram, Facebook , Vkontakte и Twitter.

Vir: www.habr.com

Selitev v ClickHouse: 3 leta kasneje