🥇Flytter til ClickHouse: 3 år senere

For tre år siden var Viktor Tarnavsky og Alexey Milovidov fra Yandex på scenen HighLoad ++ fortalt, hvilket ClickHouse er godt, og hvordan det ikke bremser. Og på næste etape var Alexander Zaitsev с rapport om at flytte til klikhus fra et andet analytisk DBMS og med den konklusion, at klikhusselvfølgelig godt, men ikke særlig praktisk. Når i 2016 virksomheden LifeStreet, hvor Alexander arbejdede dengang, var ved at oversætte et multi-petabyte analytisk system til klikhus, det var en fascinerende "gul murstensvej", fuld af ukendte farer - klikhus så lignede det et minefelt.

Tre år senere klikhus blev meget bedre - i løbet af denne tid grundlagde Alexander firmaet Altinity, som ikke kun er med til at flytte til klikhus snesevis af projekter, men forbedrer også selve produktet sammen med kolleger fra Yandex. Nu klikhus stadig ikke en ubekymret gåtur, men ikke længere et minefelt.

Alexander har været involveret i distribuerede systemer siden 2003 og udviklet store projekter på MySQL, Oracle и Vertica. Til sidst HighLoad ++ 2019 Alexander, en af pionererne inden for brugen klikhus, fortalte hvad denne DBMS er nu. Vi vil lære om hovedfunktionerne klikhus: hvordan det adskiller sig fra andre systemer og i hvilke tilfælde det er mere effektivt at bruge det. Lad os ved hjælp af eksempler overveje frisk og projektbevist praksis for at bygge systemer baseret på klikhus.

Tilbageblik: hvad skete der for 3 år siden

For tre år siden overdrog vi virksomheden LifeStreet på klikhus fra en anden analysedatabase, og migreringen af annoncenetværksanalyse så sådan ud:

juni 2016. I OpenSource optrådte klikhus og startede vores projekt;
August. Bevis for koncept: stort annoncenetværk, infrastruktur og 200-300 terabyte data;
Oktober. Første produktionsdata;
December. Fuld produktbelastning - 10-50 milliarder hændelser om dagen.
juni 2017. Vellykket migrering af brugere til klikhus, 2,5 petabyte data på en klynge på 60 servere.

Efterhånden som migrationen skred frem, voksede forståelsen klikhus er et godt system, der er behageligt at arbejde med, men dette er et internt projekt i Yandex. Derfor er der nuancer: Yandex vil først beskæftige sig med sine egne interne kunder og først derefter med fællesskabet og eksterne brugeres behov, mens ClickHouse ikke nåede virksomhedsniveauet på mange funktionelle områder dengang. Så i marts 2017 grundlagde vi Altinity for at lave klikhus endnu hurtigere og mere praktisk, ikke kun for Yandex, men også for andre brugere. Og nu vi:

Vi træner og hjælper med at bygge løsninger ud fra klikhus så kunderne ikke udfylder bump, og så løsningen til sidst virker;
Vi yder 24/7 support klikhus- installationer;
Vi udvikler vores egne økosystemprojekter;
Forpligter mig aktivt til mig selv klikhus, svar på anmodninger fra brugere, der ønsker at se visse funktioner.

Og vi hjælper selvfølgelig med flytningen til klikhus с MySQL, Vertica, Oracle, Greenplum, rødforskydning og andre systemer. Vi har været involveret i en lang række flytninger, og de har alle haft succes.

Hvorfor overhovedet flytte til klikhus

Sænker ikke farten! Dette er hovedårsagen. klikhus - meget hurtig database til forskellige scenarier:

Tilfældige citater fra folk, der arbejder med klikhus.

Skalerbarhed. På en anden database kan du opnå god ydeevne på ét stykke hardware, men klikhus du kan skalere ikke kun lodret, men også vandret ved blot at tilføje servere. Alt fungerer ikke så gnidningsløst, som vi gerne ville, men det fungerer. Du kan udvikle systemet, efterhånden som din virksomhed vokser. Det er vigtigt, at vi ikke er begrænset af beslutningen nu, og der er altid potentiale for udvikling.

Bærbarhed. Der er ingen binding til én ting. For eksempel med Amazon rødforskydning svært at flytte et sted hen. EN klikhus du kan sætte det på din bærbare computer, server, implementere det til skyen, gå til Kubernetes - der er ingen restriktioner for driften af infrastrukturen. Dette er praktisk for alle, og det er en stor fordel, som mange andre lignende databaser ikke kan prale af.

fleksibilitet. klikhus stopper ikke ved én ting, for eksempel Yandex.Metrica, men bliver udviklet og brugt i flere og flere forskellige projekter og brancher. Det kan udvides ved at tilføje nye funktioner for at løse nye problemer. For eksempel menes det, at lagring af logs i en database er dårlig manerer, så for dette kom de med Elasticsearch. Men takket være fleksibiliteten klikhus, du kan også gemme logfiler i den, og ofte er den endnu bedre end i Elasticsearch - ind klikhus det kræver 10 gange mindre jern.

Free Open Source. Du skal ikke betale for noget. Ingen grund til at forhandle tilladelse til at sætte systemet på din bærbare computer eller server. Der er ingen skjulte gebyrer. Samtidig kan ingen anden Open Source-databaseteknologi konkurrere i hastighed med klikhus. MySQL, MariaDB, Greenplum - de er alle meget langsommere.

Fællesskab, drive og sjovt. i klikhus fantastisk fællesskab: møder, chats og Alexey Milovidov, som oplader os alle med sin energi og optimisme.

Flytter til ClickHouse

At skifte til klikhus med noget behøver du kun tre ting:

Forstå begrænsninger klikhus og hvad den ikke egner sig til.
Brug fordelene teknologi og dens største styrker.
Eksperiment. Selv ved, hvordan det fungerer klikhus, det er ikke altid muligt at forudsige, hvornår det vil være hurtigere, hvornår det vil være langsommere, hvornår det bliver bedre, og hvornår det bliver værre. Så prøv.

Problemet med at flytte

Der er kun ét "men": hvis du flytter til klikhus med noget andet går noget normalt galt. Vi er vant til nogle praksisser og ting, der fungerer i vores yndlingsdatabase. For eksempel alle, der arbejder med SQL-databaser, anser følgende sæt funktioner for obligatoriske:

transaktioner;
begrænsninger;
konsistens;
indekser;
OPDATERING/SLET;
NULL;
millisekunder;
automatiske typekonverteringer;
flere sammenføjninger;
vilkårlige partitioner;
klyngestyringsværktøjer.

Rekruttering er obligatorisk, men for tre år siden i klikhus der var ingen af disse funktioner! Nu er mindre end halvdelen af de urealiserede tilbage: transaktioner, begrænsninger, konsistens, millisekunder og typestøbning.

Og det vigtigste er, at i klikhus nogle standardpraksis og tilgange virker ikke eller fungerer ikke, som vi er vant til. Alt hvad der optræder i klikhus, svarer til "klik hus måde”, dvs. funktioner er forskellige fra andre DB'er. For eksempel:

Indekser vælges ikke, men springes over.
OPDATERING/SLET ikke synkron, men asynkron.
Der er flere joinforbindelser, men der er ingen forespørgselsplanlægger. Hvordan de så udføres er generelt ikke særlig klart for folk fra databaseverdenen.

ClickHouse-scenarier

I 1960, en amerikansk matematiker af ungarsk oprindelse WignerEP skrev en artikelDen urimelige effektivitet af matematik i naturvidenskaberne”(“Matematikkens uforståelige effektivitet i naturvidenskaben”), at verden omkring os af en eller anden grund er godt beskrevet af matematiske love. Matematik er en abstrakt videnskab, og fysiske love udtrykt i matematisk form er ikke trivielle, og WignerEP understregede, at dette er meget mærkeligt.

Fra mit synspunkt, klikhus - samme særhed. For at omformulere Wigner kan vi sige dette: fantastisk er den ufattelige effektivitet klikhus i en bred vifte af analytiske applikationer!

For eksempel, lad os tage Real-Time Data Warehouse, hvori data indlæses næsten kontinuerligt. Vi ønsker at modtage anmodninger fra ham med en anden forsinkelse. Brug venligst klikhusfordi den er designet til dette scenarie. klikhus det er sådan det bruges ikke kun på nettet, men også i marketing og finansielle analyser, AdTech, samt i Opdagelse af svindeln. I Datavarehus i realtid et komplekst struktureret skema som "stjerne" eller "snefnug" bruges, mange tabeller med JOIN (nogle gange flere), og dataene lagres og ændres normalt i nogle systemer.

Lad os tage et andet scenario - Tidsserier: overvågningsenheder, netværk, brugsstatistik, tingenes internet. Her mødes vi med ret simple arrangementer bestilt i tide. klikhus er ikke oprindeligt udviklet til dette, men har vist sig godt, så store virksomheder bruger klikhus som et lager til overvågning af information. For at se om det passer klikhus for tidsserier lavede vi et benchmark baseret på tilgangen og resultaterne TilstrømningDB и TidsskalaDB - specialiseret tidsserier databaser. Det viste sigDet klikhus, selv uden optimering til sådanne opgaver, vinder også på et fremmed felt:

В tidsserier normalt bruges en smal tabel - flere små kolonner. En masse data kan komme fra overvågning - millioner af registreringer i sekundet - og de kommer normalt i små indstik (realtid streaming). Derfor har vi brug for et andet indsættelsesscript og selve forespørgslerne - med nogle egne detaljer.

Log Management. Indsamling af logfiler i databasen er normalt dårligt, men i klikhus dette kan gøres med nogle kommentarer som beskrevet ovenfor. Mange virksomheder bruger klikhus kun for dette. I dette tilfælde bruges et fladt bredt bord, hvor vi opbevarer hele logfilerne (for eksempel i formularen JSON), eller skæres i stykker. Data indlæses normalt i store partier (filer), og vi leder efter nogle felter.

Til hver af disse funktioner anvendes sædvanligvis specialiserede databaser. klikhus man kan det hele og så godt, at det overhaler dem i ydeevne. Lad os nu se nærmere tidsserier script, og hvordan man "laver mad" klikhus under dette scenarie.

Tidsserier

Dette er i øjeblikket hovedscenariet for hvilket klikhus betragtes som standardløsningen. Tidsserier er et sæt tidsordnede hændelser, der repræsenterer ændringer i en proces over tid. Det kan for eksempel være pulsen per dag eller antallet af processer i systemet. Alt det, der giver tiden tikker med nogle dimensioner, er tidsserier:

De fleste af disse hændelser kommer fra overvågning. Dette kan ikke kun være webovervågning, men også rigtige enheder: biler, industrielle systemer, IoT, industrier eller ubemandede taxaer, i bagagerummet, som Yandex allerede sætter klikhus-server.

For eksempel er der virksomheder, der indsamler data fra skibe. Hvert par sekunder sender sensorer fra et containerskib hundredvis af forskellige målinger. Ingeniører studerer dem, bygger modeller og forsøger at forstå, hvor effektivt fartøjet bliver brugt, for et containerskib bør ikke stå stille et sekund. Enhver nedetid er spild af penge, så det er vigtigt at forudsige ruten, så parkering er minimal.

Nu er der en vækst af specialiserede databaser, der måler tidsserier. På siden DB-motorer på en eller anden måde er forskellige databaser rangeret, og de kan ses efter type:

Den hurtigst voksende type tidsseriers. Grafdatabaser vokser også, men tidsseriers er vokset hurtigere i de sidste par år. Typiske repræsentanter for denne familie af databaser er TilstrømningDB, Prometheus, KDB, TidsskalaDB (bygge på PostgreSQL), løsninger fra Amazon. klikhus også her kan bruges, og det bruges. Lad mig give dig et par offentlige eksempler.

En af pionererne er virksomheden CloudFlare (CDNudbyder). De overvåger deres CDN gennem klikhus (DNS-anmodninger, HTTP-anmodninger) med en enorm belastning - 6 millioner hændelser i sekundet. Alt går igennem Kafka, går til klikhus, som giver mulighed for at se dashboards i realtid af hændelser i systemet.

Comcast - en af de førende inden for telekommunikation i USA: Internet, digitalt tv, telefoni. De skabte et lignende kontrolsystem CDN inden for Open Source projekt Apache Trafikkontrol at arbejde med deres enorme data. klikhus bruges som backend til analyser.

percona indbygget klikhus inde i din PMMat blive ved med at overvåge anderledes MySQL.

Specifikke krav

Tidsseriedatabaser har deres egne specifikke krav.

Hurtig indsættelse fra mange midler. Vi skal meget hurtigt indsætte data fra mange streams. klikhus gør det godt, fordi den har alle ikke-blokerende indsatser. Nogen INSERT er en ny fil på disken, og små inserts kan bufferes på den ene eller anden måde. I klikhus det er bedre at indsætte data i store batches i stedet for en linje ad gangen.
Fleksibelt kredsløb. I tidsserier vi kender normalt ikke strukturen af dataene fuldstændigt. Det er muligt at bygge et overvågningssystem til en specifik applikation, men så er det svært at bruge det til en anden applikation. Det kræver en mere fleksibel ordning. klikhus, giver dig mulighed for at gøre dette, selvom det er en stærkt indtastet base.
Effektiv lagring og "glemmer" af data. Normalt i tidsserier en enorm mængde data, så de skal opbevares så effektivt som muligt. For eksempel kl TilstrømningDB god kompression er dens vigtigste egenskab. Men udover opbevaring skal du også kunne "glemme" gamle data og lave noget nedsampling — automatisk optælling af aggregater.
Hurtige forespørgsler om aggregerede data. Nogle gange er det interessant at se på de sidste 5 minutter med en nøjagtighed på millisekunder, men på månedlige data er minut- eller sekundgranularitet muligvis ikke nødvendig - generel statistik er nok. Støtte af denne art er nødvendig, ellers vil en anmodning på 3 måneder blive eksekveret i meget lang tid selv i klikhus.
Forespørgsler som "sidste punkt, pr». Disse er typiske for tidsserier anmodninger: se på den sidste måling eller systemets tilstand på et tidspunkt t. For databasen er det ikke særlig behagelige forespørgsler, men de skal også kunne udføres.
"limning" tidsserier. Tidsserier er en tidsserie. Hvis der er to tidsserier, så skal de ofte forbindes og korreleres. Det er ikke bekvemt at gøre dette på alle databaser, især med ujusterede tidsserier: her er nogle tidsmærker, der er andre. Man kan overveje gennemsnittet, men pludselig vil der stadig være hul, så det er ikke klart.

Lad os se, hvordan disse krav opfyldes klikhus.

Ordningen

В klikhus ordning for tidsserier kan gøres på forskellige måder, afhængigt af graden af dataregularitet. Det er muligt at bygge et system på almindelige data, når vi kender alle målinger på forhånd. F.eks. gjorde CloudFlare med overvågning CDN er et veloptimeret system. Du kan bygge et mere generelt system, der overvåger hele infrastrukturen, forskellige tjenester. Ved uregelmæssige data ved vi ikke på forhånd, hvad vi overvåger – og det er nok det mest almindelige tilfælde.

almindelige data. Kolonner. Ordningen er enkel - kolonner med de nødvendige typer:

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

Dette er en almindelig tabel, der overvåger en form for systemstartaktivitet (bruger, systemet, tomgang, rart). Enkelt og bekvemt, men ikke fleksibelt. Hvis vi ønsker en mere fleksibel ordning, så kan vi bruge arrays.

Uregelmæssige data. Arrays:

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

Struktur Indlejret er to arrays: metrics.name и metrics.value. Her kan du gemme sådanne vilkårlige overvågningsdata som en række navne og en række målinger for hver hændelse. For yderligere optimering kan flere sådanne strukturer laves i stedet for én. For eksempel en til flyde-værdi, en anden - for int-betydning, fordi int Jeg vil gerne opbevare mere effektivt.

Men en sådan struktur er sværere at få adgang til. Du bliver nødt til at bruge en speciel konstruktion ved at bruge specielle funktioner til at trække værdierne ud først af indekset og derefter af arrayet:

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

Men det virker stadig hurtigt nok. En anden måde at gemme uregelmæssige data på er efter rækker.

Uregelmæssige data. Strenge. På denne traditionelle måde, uden arrays, er navne og værdier gemt på én gang. Hvis 5 målinger kommer fra én enhed på én gang, genereres 000 rækker i databasen:

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

klikhus klarer dette - den har specielle udvidelser klikhus SQL. For eksempel maxIf - en speciel funktion, der beregner maksimum ved metrikken, når en betingelse er opfyldt. Du kan skrive flere sådanne udtryk i én forespørgsel og straks beregne værdien for flere metrics.

Lad os sammenligne tre tilgange:

Detaljer

Her har jeg tilføjet "Data Size on Disk" til noget testdatasæt. I tilfælde af kolonner har vi den mindste datastørrelse: maksimal komprimering, maksimal forespørgselshastighed, men vi betaler ved at skulle rette alt på én gang.

I tilfælde af arrays er tingene lidt værre. Dataene komprimeres stadig godt, og det er muligt at gemme et uregelmæssigt mønster. Men klikhus - en kolonnedatabase, og når vi begynder at gemme alt i et array, bliver det til en strengdatabase, og vi betaler for fleksibilitet med effektivitet. For enhver operation bliver du nødt til at læse hele arrayet ind i hukommelsen og derefter finde det ønskede element i det - og hvis arrayet vokser, forringes hastigheden.

I en af de virksomheder, der bruger denne tilgang (f.eks. Uber), arrays skæres i stykker af 128 elementer. Dataene for flere tusinde metrics med en volumen på 200 TB data / dag er ikke lagret i et array, men i 10 eller 30 arrays med speciel lagerlogik.

Den enkleste tilgang er med strenge. Men dataene er dårligt komprimeret, tabellens størrelse er stor, og selv når forespørgsler er baseret på flere metrics, fungerer ClickHouse ikke optimalt.

hybrid ordning

Lad os antage, at vi har valgt et array-skema. Men hvis vi ved, at de fleste af vores dashboards kun viser bruger- og systemmetrics, kan vi desuden materialisere disse metrics i kolonner fra en matrix på tabelniveau på denne måde:

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

Når den er indsat klikhus vil automatisk tælle dem. På denne måde kan du kombinere forretning med fornøjelse: Ordningen er fleksibel og generel, men vi trak de mest brugte kolonner ud. Jeg bemærker, at dette ikke krævede at ændre indsatsen og ETL, som fortsætter med at indsætte arrays i tabellen. Det gjorde vi lige ALTER TABEL, tilføjede et par højttalere og fik en hybrid og hurtigere ordning, som du kan begynde at bruge med det samme.

Codecs og komprimering

for tidsserier det er vigtigt, hvor godt du pakker dataene, for rækken af informationer kan være meget stor. I klikhus der er et sæt værktøjer til at opnå effekten af komprimering 1:10, 1:20 og nogle gange mere. Det betyder, at 1 TB ukomprimeret data på disk fylder 50-100 GB. Mindre størrelse er godt, data kan læses og behandles hurtigere.

For at opnå et højt kompressionsniveau, klikhus understøtter følgende codecs:

Tabel eksempel:

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

Her definerer vi codec'et DoubleDelta i det ene tilfælde, i det andet Gorilla, og sørg for at tilføje flere LZ4 kompression. Som et resultat er størrelsen af dataene på disken stærkt reduceret:

Dette viser, hvor meget plads de samme data optager, men ved hjælp af forskellige codecs og komprimeringer:

i en GZIP-fil på disken;
i ClickHouse uden codecs, men med ZSTD-komprimering;
i ClickHouse med LZ4 og ZSTD codecs og komprimering.

Det kan ses, at tabeller med codecs fylder meget mindre.

Størrelsen betyder noget

Ikke mindre vigtigt выбрать korrekt datatype:

I alle ovenstående eksempler har jeg brugt Flyde64. Men hvis vi vælger Flyde32så ville det være endnu bedre. Dette blev godt demonstreret af fyrene fra Perkona i artiklen på linket ovenfor. Det er vigtigt at bruge den mest kompakte type, der passer til opgaven: endnu mindre for størrelse på disk end for forespørgselshastighed. klikhus meget følsom over for det.

Hvis du kan bruge int32 i stedet for int64, så forvent en næsten fordobling af ydeevnen. Dataene fylder mindre hukommelse, og al "regning" virker meget hurtigere. klikhus indeni er det et meget strengt maskinskrevet system, det udnytter alle de muligheder, som moderne systemer giver.

Aggregation og Materialiserede synspunkter

Aggregation og materialiserede visninger giver dig mulighed for at lave aggregater til forskellige lejligheder:

For eksempel kan du have ikke-aggregerede kildedata, og du kan hænge forskellige materialiserede visninger på dem med automatisk summering gennem en speciel motor SummingMergeTree (SMT). SMT er en speciel aggregerende datastruktur, der tæller aggregater automatisk. Rådata indsættes i databasen, det aggregeres automatisk, og dashboards kan bruges med det samme.

TTL - "glem" gamle data

Hvordan "glemmer" man data, der ikke længere er nødvendige? klikhus ved hvordan man gør det. Når du opretter tabeller, kan du angive TTL udtryk: for eksempel, at vi gemmer minutdata i en dag, daglige data i 30 dage og aldrig rører ugentlige eller månedlige data:

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

flere lag - partitionering af data på tværs af diske

Ved at udvikle denne idé kan data gemmes i klikhus forskellige steder. Antag, at vi vil gemme varme data for den sidste uge på en meget hurtig lokal SSD, og vi tilføjer flere historiske data til et andet sted. I klikhus nu er det muligt:

Du kan konfigurere opbevaringspolitikken (opbevaringspolitik) Altså klikhus vil automatisk overføre data til et andet lager, når visse betingelser er opfyldt.

Men det er ikke alt. På niveau med en bestemt tabel kan du definere regler for præcis, hvornår data overføres til kølelager. For eksempel ligger 7 dages data på en meget hurtig disk, og alt, der er ældre, overføres til en langsom. Dette er godt, fordi det giver systemet mulighed for at holde maksimal ydeevne, mens det kontrollerer omkostningerne og ikke bruger penge på kolde data:

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

Unikke muligheder klikhus

Næsten alt i klikhus der er sådanne "højdepunkter", men de udjævnes af det eksklusive - hvad der ikke er i andre databaser. For eksempel er her nogle af de unikke funktioner klikhus:

Arrays. I klikhus meget god støtte til arrays, samt evnen til at udføre komplekse beregninger på dem.
Aggregering af datastrukturer. Dette er en af de "dræberfunktioner" klikhus. På trods af at fyrene fra Yandex siger, at vi ikke ønsker at samle data, er alt samlet i klikhusfordi det er hurtigt og bekvemt.
Materialiserede synspunkter. Sammen med aggregerende datastrukturer giver materialiserede visninger dig mulighed for at lave en praktisk realtid sammenlægning.
ClickHouse SQL. Dette er en sprogudvidelse SQL med nogle ekstra og eksklusive funktioner, der kun er tilgængelige i klikhus. Tidligere var det sådan set en udvidelse på den ene side og en ulempe på den anden. Nu næsten alle mangler i forhold til SQL 92 vi fjernede det, nu er det bare en udvidelse.
Lambda-udtryk. Er de stadig i en eller anden database?
ML-support. Dette er i forskellige databaser, nogle er bedre, nogle er værre.
Åben kilde. Vi kan udvide klikhus sammen. Nu i klikhus omkring 500 bidragydere, og dette antal vokser konstant.

Vanskelige forespørgsler

В klikhus der er mange forskellige måder at gøre det samme på. For eksempel er der tre forskellige måder at returnere den sidste værdi fra en tabel for CPU (der er også en fjerde, men den er endnu mere eksotisk).

Den første viser, hvor praktisk det er at gøre i klikhus forespørgsler, når du vil tjekke det tupel indeholdt i underforespørgslen. Dette er noget, som jeg personligt virkelig manglede i andre databaser. Hvis jeg vil sammenligne noget med en underforespørgsel, så i andre databaser kan kun en skalar sammenlignes med den, og for flere kolonner skal jeg skrive JOIN. I klikhus du kan bruge tuple:

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

Den anden måde gør det samme, men bruger en aggregeret funktion argMax:

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

В klikhus der er flere dusin samlede funktioner, og hvis du bruger kombinatorer, så får du ifølge kombinatorikkens love omkring tusind af dem. ArgMax - en af de funktioner, der tæller den maksimale værdi: forespørgslen returnerer værdien usage_user, hvor den maksimale værdi nås oprettet_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 - "limning" af rækker med forskellige tidspunkter. Dette er en unik funktion til databaser og er kun tilgængelig i kdb+. Hvis der er to tidsserier med forskellige tidspunkter, ASOF JOIN tillader dem at blive forskudt og limet i én anmodning. For hver værdi i en tidsserie findes den nærmeste værdi i en anden, og de returneres på samme linje:

Analytiske funktioner

I standarden SQL-2003 du kan skrive sådan her:

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;

В klikhus dette er ikke muligt - det understøtter ikke standarden SQL-2003 og vil nok aldrig. I stedet for i klikhus det er sædvanligt at skrive sådan her:

Jeg lovede lambdas – her er de!

Dette er en analog af en analytisk forespørgsel i standarden SQL-2003: det tæller forskellen mellem to tidsstempel, varighed, Ordinal - alt det, vi normalt betragter som analytiske funktioner. I klikhus vi tæller dem gennem arrays: først kollapser vi dataene til et array, derefter gør vi hvad vi vil på arrayet, og derefter udvider vi det tilbage. Det er ikke særlig praktisk, det kræver i det mindste en kærlighed til funktionel programmering, men det er meget fleksibelt.

Særlige funktioner

Desuden i klikhus mange specialiserede funktioner. For eksempel, hvordan bestemmer man, hvor mange sessioner der kører på samme tid? En typisk opgave for overvågning er at bestemme den maksimale belastning i en enkelt anmodning. I klikhus der er en speciel funktion til dette formål:

Generelt har ClickHouse specielle funktioner til mange formål:

runningDifference, runningAccumulate, nabo;
sumMap(nøgle, værdi);
timeSeriesGroupSum(uid, timestamp, value);
timeSeriesGroupRateSum(uid, timestamp, value);
skewPop, skewSamp, kurtPop, kurtSamp;
MED FYLD / MED BÅND;
simpleLinearRegression, stochasticLinearRegression.

Dette er ikke en komplet liste over funktioner, der er kun 500-600 af dem. Tip: alle funktioner i klikhus er i systemtabellen (ikke alle er dokumenterede, men alle er interessante):

select * from system.functions order by name

klikhus gemmer en masse information om sig selv, bl.a log tabeller, query_log, sporingslog, operationslog med datablokke (del_log), metrikloggen og systemloggen, som den normalt skriver til disken. Metrik-loggen er tidsserier в klikhus rent faktisk klikhus: selve databasen kan spille en rolle tidsserier databaser, og dermed "sluger" sig selv.

Dette er også en unik ting - da vi gør et godt stykke arbejde for tidsserierhvorfor kan vi ikke gemme alt, hvad vi har brug for i os selv? Vi behøver ikke Prometheus, vi holder alt i os selv. Forbundet grafana og vi overvåger os selv. Men hvis klikhus falder, vil vi ikke se - hvorfor - det er derfor, de normalt ikke gør det.

Stor klynge eller mange små klikhus

Hvad er bedre - en stor klynge eller mange små ClickHouses? Den traditionelle tilgang til DWH er en stor klynge, hvor der tildeles ordninger for hver ansøgning. Vi kom til databaseadministratoren - giv os et skema, og vi fik det:

В klikhus du kan gøre det anderledes. Kan hver ansøgning lave sin egen klikhus:

Vi har ikke brug for et stort monster længere DWH og usamarbejdsvillige administratorer. Vi kan give hver ansøgning sin egen klikhus, og udvikleren kan gøre det selv, siden klikhus meget nem at installere og kræver ikke kompleks administration:

Men hvis vi har meget klikhus, og du skal indstille det ofte, så vil du automatisere denne proces. Hertil kan vi f.eks. bruge Kubernetes и klikhus-operatør. I Kubernetes ClickHouse du kan sætte "på klik": Jeg kan klikke på en knap, køre manifestet og databasen er klar. Du kan straks oprette et skema, begynde at indlæse metrics der, og efter 5 minutter har jeg et dashboard klar grafana. Det er så enkelt!

Resultatet?

således klikhus - Det her:

Быстро. Alle ved dette.
bare. Lidt diskutabelt, men jeg synes, det er svært at lære, let at kæmpe. Hvis du forstår hvordan klikhus virker, alt er meget enkelt.
Universelt. Det er velegnet til forskellige scenarier: DWH, Time Series, Log Storage. Men det er det ikke OLTP database, så prøv ikke at lave korte indsættelser og læsninger der.
Interessant. Formentlig den, der arbejder med klikhus, oplevet mange interessante minutter i god og dårlig forstand. For eksempel kom en ny udgivelse, alt holdt op med at fungere. Eller når du kæmpede med en opgave i to dage, men efter et spørgsmål i Telegram-chatten blev opgaven løst på to minutter. Eller, som på konferencen til Lesha Milovidovs rapport, et skærmbillede fra klikhus brød udsendelsen HighLoad ++. Den slags ting sker hele tiden og gør vores liv med klikhus lyst og interessant!

Præsentationen kan ses her.

Det længe ventede møde for udviklere af højbelastningssystemer kl HighLoad ++ finder sted den 9. og 10. november i Skolkovo. Endelig bliver det en offline konference (omend med alle forholdsregler), da energien fra HighLoad++ ikke kan pakkes online.

Til konferencen finder og viser vi dig cases om teknologiens maksimale muligheder: HighLoad ++ var, er og bliver det eneste sted, hvor du på to dage kan lære, hvordan Facebook, Yandex, VKontakte, Google og Amazon fungerer.

Efter at have holdt vores møder uden afbrydelser siden 2007, mødes vi i år for 14. gang. I løbet af denne tid er konferencen vokset 10 gange, sidste år samlede branchens nøglebegivenhed 3339 deltagere, 165 foredragsholdere af rapporter og meetups, og 16 numre spillede på samme tid.
Sidste år var der 20 busser til dig, 5280 liter te og kaffe, 1650 liter frugtdrikke og 10200 flasker vand. Og yderligere 2640 kilo mad, 16 tallerkener og 000 kopper. Forresten, med pengene indsamlet fra genbrugspapir plantede vi 25 egeplanter 🙂

Billetter kan købes her, modtag nyheder om konferencen — her, og tal i alle sociale netværk: Telegram, Facebook, Vkontakte и Twitter.

Kilde: www.habr.com

Flytning til ClickHouse: 3 år senere