🥇Flytting til ClickHouse: 3 år senere

Три года назад Виктор Тарнавский и Алексей Миловидов из Яндекса на сцене Høybelastning++ fortalte, hvor bra ClickHouse er, og hvordan det ikke bremser ned. Og på neste etappe var det Alexander Zaitsev с rapportere om å flytte til ClickHouse fra en annen analytisk DBMS og med konklusjonen at ClickHouse, selvfølgelig, bra, men ikke veldig praktisk. Når i 2016 selskapet Life, hvor Alexander da jobbet, konverterte et multi-petabyte analytisk system til ClickHouse, det var en fascinerende "gul mursteinsvei" full av ukjente farer - ClickHouse den gang så det ut som et minefelt.

Tre år senere ClickHouse ble mye bedre - i løpet av denne tiden grunnla Alexander selskapet Altinity, som ikke bare hjelper folk å flytte til ClickHouse десяткам проектов, но и совершенствует сам продукт вместе с коллегами из Яндекса. Сейчас ClickHouse fortsatt ikke en bekymringsløs spasertur, men ikke lenger et minefelt.

Alexander har jobbet med distribuerte systemer siden 2003, og utviklet store prosjekter på MySQL, Oracle и Vertica. På den siste HighLoad++ 2019 Александр, один из пионеров использования ClickHouse, fortalte hva dette DBMS er nå. Vi vil lære om hovedfunksjonene ClickHouse: hvordan det skiller seg fra andre systemer og i hvilke tilfeller det er mer effektivt å bruke det. Ved hjelp av eksempler vil vi se på nyere og prosjekttestet praksis for byggesystemer basert på ClickHouse.

Tilbakeblikk: hva skjedde for 3 år siden

Три года назад мы переводили компанию Life på ClickHouse fra en annen analytisk database, og migreringen av annonsenettverksanalyse så slik ut:

Июнь 2016. В Åpen kilde dukket ClickHouse og prosjektet vårt startet;
August. Bevis på konsept: stort annonsenettverk, infrastruktur og 200-300 terabyte med data;
Oktober. Første produksjonsdata;
Desember. Den fulle produktmengden er 10-50 milliarder hendelser per dag.
juni 2017. Vellykket migrering av brukere til ClickHouse, 2,5 petabyte med data på en klynge med 60 servere.

Under migrasjonsprosessen ble det en økende forståelse for det ClickHouse er et godt system som er hyggelig å jobbe med, men dette er et internt prosjekt i Yandex. Derfor er det nyanser: Yandex vil først håndtere sine egne interne kunder og først da med fellesskapet og behovene til eksterne brukere, og ClickHouse nådde da ikke bedriftsnivået på mange funksjonelle områder. Derfor grunnla vi Altinity i mars 2017 for å lage ClickHouse enda raskere og mer praktisk, ikke bare for Yandex, men også for andre brukere. Og nå vi:

Vi trener og hjelper til med å bygge løsninger basert på ClickHouse slik at kundene ikke får problemer, og slik at løsningen til slutt fungerer;
Обеспечиваем 24/7 поддержку ClickHouse- installasjoner;
Vi utvikler våre egne økosystemprosjekter;
Vi forplikter oss aktivt til oss selv ClickHouse, svarer på forespørsler fra brukere som ønsker å se visse funksjoner.

Og selvfølgelig hjelper vi til med flytting til ClickHouse с MySQL, Vertica, Oracle, Greenplum, rødforskyvning og andre systemer. Vi har vært involvert i en rekke grep, og de har alle vært vellykkede.

Hvorfor flytte til ClickHouse

Brekker ikke farten! Dette er hovedårsaken. ClickHouse - Veldig rask database for forskjellige scenarier:

Tilfeldige sitater fra folk som har jobbet med mennesker i lang tid ClickHouse.

Skalerbarhet. På en annen database kan du oppnå god ytelse på ett stykke maskinvare, men ClickHouse du kan skalere ikke bare vertikalt, men også horisontalt, ganske enkelt ved å legge til servere. Alt fungerer ikke så knirkefritt som vi ønsker, men det fungerer. Du kan utvide systemet etter hvert som virksomheten din vokser. Det er viktig at vi ikke begrenses av løsningen nå og det er alltid potensiale for utvikling.

Портируемость. Det er ingen binding til én ting. For eksempel med Amazon RedShift Det er vanskelig å flytte et sted. EN ClickHouse du kan installere den på din bærbare datamaskin, server, distribuere den til skyen, gå til Kubernetes — det er ingen restriksjoner på driften av infrastrukturen. Dette er praktisk for alle, og dette er en stor fordel som mange andre lignende databaser ikke kan skryte av.

Fleksibilitet. ClickHouse stopper ikke ved én ting, for eksempel Yandex.Metrica, men utvikler og brukes i flere og flere forskjellige prosjekter og bransjer. Den kan utvides ved å legge til nye evner for å løse nye problemer. For eksempel antas det at lagring av logger i en database er dårlig oppførsel, så de kom opp med Elasticsearch. Men takket være fleksibilitet ClickHouse, du kan også lagre logger i den, og ofte er dette enda bedre enn i Elasticsearch - inn ClickHouse для этого требуется в 10 раз меньше железа.

Gratis Open Source. Du trenger ikke betale for noe. Det er ikke nødvendig å forhandle om tillatelse til å installere systemet på den bærbare datamaskinen eller serveren. Ingen skjulte avgifter. Samtidig kan ingen annen Open Source-databaseteknologi konkurrere i hastighet med ClickHouse. MySQL, MariaDB, Greenplum – de er alle mye tregere.

Fellesskap, driv og moro. I ClickHouse utmerket fellesskap: møter, chatter og Alexey Milovidov, som lader oss alle med sin energi og optimisme.

Flytter til ClickHouse

Å gå til ClickHouse av en eller annen grunn trenger du bare tre ting:

Forstå begrensningene ClickHouse og hva den ikke egner seg til.
Использовать преимущества teknologi og dens største styrker.
Eksperiment. Даже понимая как работает ClickHouse, det er ikke alltid mulig å forutsi når det vil være raskere, når det vil være tregere, når det vil bli bedre, og når det vil være verre. Så prøv det.

Bevegelsesproblem

Det er bare ett "men": hvis du flytter til ClickHouse с чего-то другого, то обычно что-то идет не так. Мы привыкли к каким-то практикам и вещам, которые работают в любимой БД. Например, любой человек, работающий с SQL-databaser anser følgende sett med funksjoner som obligatoriske:

transaksjoner;
begrensninger;
konsistens;
indekser;
UPDATE/DELETE;
NULL;
millisekunder;
automatisk type støpte;
множественные джойны;
vilkårlige partisjoner;
verktøy for klyngestyring.

Rekruttering er obligatorisk, men for tre år siden i ClickHouse Ingen av disse funksjonene var tilgjengelige! Nå gjenstår mindre enn halvparten av det som ikke er implementert: transaksjoner, begrensninger, konsistens, millisekunder og typestøping.

Og det viktigste er at i ClickHouse noen standard praksiser og tilnærminger fungerer ikke eller fungerer annerledes enn vi er vant til. Alt som vises i ClickHouse, tilsvarer "ClickHouse måte", dvs. funksjoner skiller seg fra andre databaser. For eksempel:

Indekser er ikke valgt, men hoppet over.
UPDATE/DELETE ikke synkron, men asynkron.
Det er flere sammenføyninger, men det er ingen spørringsplanlegger. Hvordan de deretter utføres er generelt lite klart for folk fra databaseverdenen.

ClickHouse-skript

I 1960, en amerikansk matematiker av ungarsk opprinnelse Wigner EP skrev en artikkel "Den urimelige effektiviteten av matematikk i naturvitenskapene” (“The Incomprehensible Effectiveness of Mathematics in the Natural Sciences”) at verden rundt oss av en eller annen grunn er godt beskrevet av matematiske lover. Matematikk er en abstrakt vitenskap, og fysiske lover uttrykt i matematisk form er ikke trivielle, og Wigner EP understreket at dette er veldig merkelig.

Fra mitt synspunkt, ClickHouse - samme merkelighet. For å omformulere Wigner kan vi si dette: den ufattelige effektiviteten er forbløffende ClickHouse i en rekke analytiske applikasjoner!

For eksempel, la oss ta Sanntidsdatavarehus, в который данные грузятся практически непрерывно. Мы хотим получать от него запросы с секундной задержкой. Пожалуйста — используем ClickHouse, потому что для этого сценария он и был разработан. ClickHouse именно так и используется не только в веб, но и в маркетинговой и финансовой аналитике, AdTech, а также в Oppdagelse av svindeln. I Datavarehus i sanntid et komplekst strukturert opplegg som "stjerne" eller "snøfnugg" brukes, mange tabeller med BLI (noen ganger flere), og dataene lagres og endres vanligvis i noen systemer.

La oss ta et annet scenario - Tidsserier: мониторинг устройств, сетей, статистика использования, интернет вещей. Здесь мы встречаемся с упорядоченными по времени достаточно простыми событиями. ClickHouse ble opprinnelig ikke utviklet for dette, men har vist seg å fungere godt, og det er derfor store bedrifter bruker ClickHouse som et depot for overvåking av informasjon. For å utforske om det egner seg ClickHouse для time-series, мы сделали бенчмарк на основе подхода и результатах TilstrømningDB и TidsskalaDB - spesialisert tidsserier databaser. Det viste segAt ClickHouse, selv uten optimalisering for slike oppgaver, vinner på et fremmed felt:

В tidsserier Vanligvis brukes en smal tabell - flere små kolonner. Mye data kan komme fra overvåking – millioner av poster per sekund – og de kommer vanligvis i små serier (sanntids streaming). Derfor er det nødvendig med et annet innsettingsskript, og selve spørringene har sine egne spesifikasjoner.

Log Management. Å samle logger inn i en database er vanligvis dårlig, men ClickHouse dette kan gjøres med noen kommentarer som beskrevet ovenfor. Mange bedrifter bruker ClickHouse akkurat for dette formålet. I dette tilfellet bruker vi et flatt bredt bord der vi lagrer hele loggene (for eksempel i skjemaet JSON), eller kutt i biter. Data lastes vanligvis inn i store batcher (filer), og vi søker etter et felt.

For hver av disse funksjonene brukes vanligvis spesialiserte databaser. ClickHouse один может делать это всё и настолько хорошо, что обгоняет их по производительности. Давайте теперь подробно рассмотрим tidsserier scenario, og hvordan "lage mat" riktig ClickHouse for dette scenariet.

Tidsserier

Foreløpig er dette hovedscenarioet som ClickHouse betraktet som standardløsningen. Tidsserier er et sett med hendelser ordnet i tid, som representerer endringer i en eller annen prosess over tid. Dette kan for eksempel være hjertefrekvensen per dag eller antall prosesser i systemet. Alt som gir tid tikker med noen dimensjoner er tidsserier:

De fleste av denne typen hendelser kommer fra overvåking. Dette kan ikke bare være overvåking av nettet, men også ekte enheter: biler, industrielle systemer, IOT, fabrikker eller ubemannede drosjer, i bagasjerommet som Yandex allerede legger ClickHouse-server.

Например, есть компании, которые собирают данные с судов. Каждые несколько секунд датчики с контейнеровоза отправляют сотни различных измерений. Инженеры их изучают, строят модели и пытаются понять, насколько эффективно используется судно, потому что контейнеровоз не должен простаивать ни секунды. Любой простой — это потеря денег, поэтому важно спрогнозировать маршрут так, чтобы стоянки были минимальными.

Сейчас наблюдается рост специализированных БД, которые измеряют tidsserier. På siden DB-motorer каким-то образом ранжируются разные базы данных, и их можно посмотреть по типам:

Den raskest voksende typen er tidsseriers. Grafdatabaser vokser også, men tidsseriers растут быстрее последние несколько лет. Типичные представители БД этого семейства — это TilstrømningDB, Prometheus, KDB, TidsskalaDB (построенная на PostgreSQL), решения от Amazon. ClickHouse здесь тоже может быть использован, и он используется. Приведу несколько публичных примеров.

En av pionerene er selskapet CloudFlare (CDN-forsørger). De overvåker deres CDN gjennom ClickHouse (DNS-forespørsler, HTTP-spørringer) med en enorm belastning - 6 millioner hendelser per sekund. Alt går gjennom Kafka, går til ClickHouse, som gir mulighet til å se dashboards av hendelser i systemet i sanntid.

Comcast — один из лидеров телекоммуникаций в США: интернет, цифровое телевидение, телефония. Они создали аналогичную систему управления CDN innenfor rammen Open Source prosjekt Apache Traffic Control å jobbe med dine enorme data. ClickHouse brukes som en backend for analyser.

percona innebygd ClickHouse inne i din PMMå lagre overvåking av div MySQL.

Spesifikke krav

К time-series базам данных есть свои специфические требования.

Rask innsetting fra mange agenter. Vi må sette inn data fra mange strømmer veldig raskt. ClickHouse Den gjør dette bra fordi alle innsatsene er ikke-blokkerende. Noen Sett er en ny fil på disk, og små innlegg kan bufres på en eller annen måte. I ClickHouse Det er bedre å sette inn data i store grupper i stedet for én linje om gangen.
Fleksibel ordning. I tidsserier vi kjenner vanligvis ikke datastrukturen helt. Det er mulig å bygge et overvåkingssystem for en spesifikk applikasjon, men da er det vanskelig å bruke det til en annen applikasjon. Dette krever en mer fleksibel ordning. ClickHouse, lar deg gjøre dette, selv om det er en sterkt skrevet base.
Effektiv lagring og glemning av data. Vanligvis i tidsserier en enorm mengde data, så den må lagres så effektivt som mulig. For eksempel kl TilstrømningDB god kompresjon er hovedfunksjonen. Men i tillegg til å lagre, må du også kunne "glemme" gamle data og gjøre noe nedsampling — automatisk telling av aggregater.
Raske spørringer på aggregerte data. Noen ganger er det interessant å se på de siste 5 minuttene med en nøyaktighet på millisekunder, men på månedlige data er det kanskje ikke nødvendig med minutt- eller sekundgranularitet - generell statistikk er nok. Støtte av denne typen er nødvendig, ellers vil en forespørsel på 3 måneder ta svært lang tid å fullføre selv i ClickHouse.
Forespørsler som "siste punkt, pr». Disse er typiske for tidsserier spørringer: se på siste måling eller tilstand til systemet på et tidspunkt t. Dette er ikke særlig hyggelige spørringer for en database, men du må også kunne utføre dem.
"Liming" tidsserie. Tidsserier er en tidsserie. Hvis det er to tidsserier, må de ofte kobles sammen og korreleres. Det er ikke praktisk å gjøre dette på alle databaser, spesielt med ujusterte tidsserier: her er noen tidspunkter, det er andre. Du kan vurdere gjennomsnittlig, men plutselig vil det fortsatt være et hull der, så det er ikke klart.

La oss se hvordan disse kravene oppfylles ClickHouse.

Ordningen

В ClickHouse ordning for tidsserier kan gjøres på forskjellige måter, avhengig av graden av regelmessighet til dataene. Det er mulig å bygge et system på vanlige data når vi kjenner alle beregningene på forhånd. Jeg gjorde for eksempel dette CloudFlare med overvåking CDN — это хорошо оптимизированная система. Можно построить более общую систему, которая мониторит всю инфраструктуру, разные сервисы. В случае нерегулярных данных, мы не знаем заранее, что мониторим — и, наверное, это наболее общий случай.

Vanlige data. Kolonner. Ordningen er enkel - kolonner med de nødvendige typene:

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 vanlig tabell som overvåker en slags systemlastingsaktivitet (bruker, system, tomgang, fint). Enkelt og praktisk, men ikke fleksibelt. Hvis vi ønsker en mer fleksibel ordning, kan vi bruke 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 Nøstet er to matriser: metrics.name и metrics.value. Her kan du lagre slike vilkårlige overvåkingsdata som en rekke navn og en rekke målinger for hver hendelse. For ytterligere optimalisering, i stedet for en slik struktur, kan du lage flere. For eksempel en for flyte-verdi, en annen - for int- som betyr fordi int Jeg ønsker å lagre mer effektivt.

Men en slik struktur er vanskeligere tilgjengelig. Du må bruke en spesiell konstruksjon, bruke spesielle funksjoner for å trekke ut verdiene til først indeksen og deretter matrisen:

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

Men det fungerer fortsatt ganske raskt. En annen måte å lagre uregelmessige data på er radvis.

Uregelmessige data. Strenger. I denne tradisjonelle metoden, uten matriser, lagres navn og verdier samtidig. Hvis 5 målinger kommer fra én enhet samtidig, genereres 000 rader 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', ...)

ClickHouse takler dette - den har spesielle utvidelser ClickHouse SQL. For eksempel, maxIf — en spesiell funksjon som beregner maksimum ved en metrikk når en betingelse er oppfylt. Du kan skrive flere slike uttrykk i én forespørsel og umiddelbart beregne verdien for flere beregninger.

La oss sammenligne tre tilnærminger:

Детали

Her har jeg lagt til "Disk Data Size" for noen testdatasett. Når det gjelder kolonner, har vi den minste datastørrelsen: maksimal komprimering, maksimal spørringshastighet, men vi betaler ved å måtte registrere alt på en gang.

Når det gjelder arrays, er alt litt verre. Dataene er fortsatt godt komprimert og et uregelmessig mønster kan lagres. Men ClickHouse - en kolonneformet database, og når vi begynner å lagre alt i en array, blir den til en rad én, og vi betaler for fleksibilitet med effektivitet. For enhver operasjon må du lese hele arrayet inn i minnet, og deretter finne ønsket element i det - og hvis arrayet vokser, reduseres hastigheten.

В одной из компаний, которая использует такой подход (например, Uber), matriser kuttes i biter med 128 elementer. Data fra flere tusen beregninger med et volum på 200 TB data/dag lagres ikke i én array, men i 10 eller 30 arrays med spesiell lagringslogikk.

Den enkleste tilnærmingen er med strenger. Men dataene er dårlig komprimert, tabellstørrelsen er stor, og selv når spørringene er basert på flere beregninger, fungerer ikke ClickHouse optimalt.

Hybrid opplegg

La oss anta at vi har valgt en array-krets. Men hvis vi vet at de fleste av dashbordene våre bare viser bruker- og systemberegninger, kan vi i tillegg materialisere disse beregningene til kolonner fra en matrise på tabellnivå på denne måten:

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

Ved innsetting ClickHouse vil automatisk telle dem. På denne måten kan du kombinere forretning med fornøyelse: Ordningen er fleksibel og generell, men vi trakk ut de mest brukte kolonnene. Merk at dette ikke krevde å bytte innsats og ETLsom fortsetter å sette inn matriser i tabellen. Det gjorde vi nettopp ALTER TABLE, la til et par høyttalere og vi fikk et hybrid og raskere opplegg som du kan begynne å bruke med en gang.

Kodeker og komprimering

For tidsserier важно, насколько хорошо вы упаковываете данные, потому что массив информации может быть очень большой. В ClickHouse Det er et sett med verktøy for å oppnå en komprimeringseffekt på 1:10, 1:20 og noen ganger mer. Dette betyr at 1 TB med utpakket data på disken tar opp 50-100 GB. Mindre størrelse er bra, data kan leses og behandles raskere.

For å oppnå et høyt kompresjonsnivå, ClickHouse støtter følgende kodeker:

Eksempeltabell:

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 kodeken DoubleDelta i ett tilfelle, i det andre - Gorilla, og vi vil definitivt legge til flere LZ4 kompresjon. Som et resultat er størrelsen på dataene på disken kraftig redusert:

Dette viser hvor mye plass de samme dataene tar opp, men med forskjellige kodeker og komprimeringer:

i en GZIP-fil på disk;
i ClickHouse uten kodeker, men med ZSTD-komprimering;
i ClickHouse med kodeker og komprimering LZ4 og ZSTD.

Det kan sees at tabeller med kodeker tar opp mye mindre plass.

Størrelsen er viktig

Ikke mindre viktig выбрать riktig datatype:

I alle eksemplene ovenfor brukte jeg Flyte64. Men hvis vi velger Flyte32, da ville det vært enda bedre. Dette ble godt demonstrert av gutta fra Perkona i artikkelen linket ovenfor. Det er viktig å bruke den mest kompakte typen som passer for oppgaven: enda mindre for diskstørrelse enn for spørringshastighet. ClickHouse veldig følsom for dette.

Hvis du kan bruke int32 i stedet for int64, forvent en nesten dobling av ytelsen. Dataene tar opp mindre minne, og all "aritmetikk" fungerer mye raskere. ClickHouse internt er det et veldig strengt skrevet system; det utnytter alle mulighetene som moderne systemer gir maksimalt.

Агрегация и Materialiserte visninger

Aggregering og materialiserte visninger lar deg lage aggregater for forskjellige anledninger:

For eksempel kan du ha ikke-aggregerte kildedata, og du kan legge ved ulike materialiserte visninger til dem med automatisk summering gjennom en spesiell motor SummingMergeTree (SMT). SMT er en spesiell aggregatdatastruktur som beregner aggregater automatisk. Rådata settes inn i databasen, de blir automatisk aggregert, og dashboard kan brukes umiddelbart på den.

TTL - "glem" gamle data

Hvordan "glemme" data som ikke lenger er nødvendig? ClickHouse vet hvordan dette skal gjøres. Når du oppretter tabeller, kan du spesifisere TTL uttrykk: for eksempel at vi lagrer minuttdata for én dag, daglige data i 30 dager, og aldri berører ukentlige 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 */

Flerlag - dele data på tvers av disker

Ta denne ideen videre, data kan lagres i ClickHouse på forskjellige steder. Anta at vi ønsker å lagre varme data for den siste uken på en veldig rask lokal SSD, og vi legger flere historiske data et annet sted. I ClickHouse dette er nå mulig:

Du kan konfigurere en lagringspolicy (lagringspolicy) Så ClickHouse vil automatisk overføre data når visse betingelser er nådd til en annen lagring.

Men det er ikke alt. På nivået til en spesifikk tabell kan du definere regler for nøyaktig når dataene skal inn i fryselager. For eksempel lagres data på en veldig rask disk i 7 dager, og alt som er eldre overføres til en treg. Dette er bra fordi det lar deg holde systemet med maksimal ytelse, samtidig som du kontrollerer kostnadene og ikke kaster bort penger på kalde data:

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

Unike egenskaper ClickHouse

I nesten alt ClickHouse Det er slike "høydepunkter", men de oppveies av eksklusivitet - noe som ikke finnes i andre databaser. For eksempel, her er noen av de unike funksjonene ClickHouse:

arrays. I ClickHouse veldig god støtte for arrays, samt muligheten til å utføre komplekse beregninger på dem.
Aggregering av datastrukturer. Dette er en av "killer-funksjonene" ClickHouse. Несмотря на то, что ребята из Яндекса говорят, что мы не хотим агрегировать данные, все агрегируют в ClickHouse, fordi det er raskt og praktisk.
Materialiserte synspunkter. Sammen med aggregerende datastrukturer lar materialiserte visninger deg gjøre det praktisk sanntids aggregering.
ClickHouse SQL. Это расширение языка SQL med noen ekstra og eksklusive funksjoner som kun er tilgjengelig i ClickHouse. Tidligere var det som en utvidelse på den ene siden, og en ulempe på den andre. Nå nesten alle ulempene i forhold til SQL 92 мы убрали, теперь это только расширение.
Lambda-uttrykkene. Er de fortsatt i en database?
ML-Brukerstøtte. Dette er tilgjengelig i forskjellige databaser, noen er bedre, noen er dårligere.
åpen kilde. Vi kan utvide ClickHouse sammen. Nå i ClickHouse ca. 500 bidragsytere, og dette tallet vokser stadig.

Vanskelige spørsmål

В ClickHouse det er mange forskjellige måter å gjøre det samme på. For eksempel kan du returnere den siste verdien fra en tabell på tre forskjellige måter for prosessor (det er også en fjerde, men den er enda mer eksotisk).

Den første viser hvor praktisk det er å gjøre det ClickHouse spør når du vil sjekke det tuppel inneholdt i underspørringen. Dette er noe jeg personlig savnet i andre databaser. Hvis jeg vil sammenligne noe med en underspørring, så i andre databaser kan bare en skalar sammenlignes med den, men for flere kolonner må jeg skrive BLI. I ClickHouse du kan bruke tuple:

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

Den andre metoden gjør det samme, men bruker en aggregert funksjon argMax:

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

В ClickHouse det er flere dusin samlede funksjoner, og hvis du bruker kombinatorer, vil du i henhold til kombinatorikkens lover få omtrent tusen av dem. ArgMax - en av funksjonene som beregner maksimumsverdien: forespørselen returnerer verdien usage_user, hvor maksimumsverdien er nådd opprettet_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 BLI MED — "liming" av rader med forskjellige tider. Dette er en unik funksjon for databaser som kun er tilgjengelig i kdb+. Hvis det er to tidsserier med forskjellige tider, ASOF BLI MED lar deg flytte og slå dem sammen i én forespørsel. For hver verdi i en tidsserie, blir den nærmeste verdien i den andre funnet, og de returneres på samme linje:

Analytiske funksjoner

I standarden SQL-2003 du kan skrive slik:

SELECT origin,
       timestamp,
       timestamp -LAG(timestamp, 1) OVER (PARTITION BY origin ORDER BY timestamp) AS duration,
       timestamp -MIN(timestamp) OVER (PARTITION BY origin ORDER BY timestamp) AS startseq_duration,
       ROW_NUMBER() OVER (PARTITION BY origin ORDER BY timestamp) AS sequence,
       COUNT() OVER (PARTITION BY origin ORDER BY timestamp) AS nb
  FROM mytable
ORDER BY origin, timestamp;

В ClickHouse Du kan ikke gjøre det - det støtter ikke standarden SQL-2003 og vil sannsynligvis aldri gjøre det. I stedet, i ClickHouse Det er vanlig å skrive slik:

Jeg lovet lambdaer – her er de!

Dette er en analog av den analytiske spørringen i standarden SQL-2003: han teller forskjellen mellom de to tidsstempel, varighet, порядковый номер — всё, что обычно мы считаем аналитическими функциями. В ClickHouse Vi teller dem gjennom matriser: først kollapser vi dataene til en matrise, etter det gjør vi alt vi vil ha på matrisen, og deretter utvider vi den tilbake. Det er ikke veldig praktisk, det krever minst en forkjærlighet for funksjonell programmering, men det er veldig fleksibelt.

Spesielle funksjoner

Dessuten i ClickHouse mange spesialiserte funksjoner. For eksempel, hvordan finne ut hvor mange økter som finner sted samtidig? En typisk overvåkingsoppgave er å bestemme maksimal belastning med én forespørsel. I ClickHouse Det er en spesiell funksjon for dette formålet:

Generelt har ClickHouse spesielle funksjoner for mange formål:

runningDifference, runningAccumulate, neighbor;
sumMap(nøkkel, verdi);
timeSeriesGroupSum(uid, tidsstempel, verdi);
timeSeriesGroupRateSum(uid, timestamp, value);
skewPop, skewSamp, kurtPop, kurtSamp;
MED FYLL / MED BÅND;
simpleLinearRegression, stochasticLinearRegression.

Dette er ikke en fullstendig liste over funksjoner, det er 500-600 totalt. Hint: alle funksjoner i ClickHouse есть в системной таблице (не все документированы, но все интересны):

select * from system.functions order by name

ClickHouse den lagrer mye informasjon om seg selv, inkludert loggtabeller, query_log, sporingslogg, logg over operasjoner med datablokker (del_logg), metrikklogg og systemlogg, som den vanligvis skriver til disk. Loggberegninger er tidsserier в ClickHouse faktisk ClickHouse: Selve databasen kan spille en rolle tidsserier databaser, og dermed «sluker» seg selv.

Dette er også en unik ting - siden vi gjør en god jobb for tidsserier, hvorfor kan vi ikke lagre alt vi trenger i oss selv? Vi trenger ikke Prometheus, vi holder alt for oss selv. Tilkoblet grafana og vi overvåker oss selv. Imidlertid, hvis ClickHouse faller, vil vi ikke se hvorfor, så de gjør vanligvis ikke det.

Большой кластер или много маленьких ClickHouse

Hva er bedre - en stor klynge eller mange små ClickHouses? Tradisjonell tilnærming til DWH er en stor klynge der kretser er tildelt for hver applikasjon. Vi kom til databaseadministratoren - gi oss et diagram, og de ga oss et:

В ClickHouse можно сделать это по-другому. Можно каждому приложению сделать свой собственный ClickHouse:

Vi trenger ikke den store monstrøse lenger DWH и несговорчивые админы. Мы можем каждому приложению выдать свой собственный ClickHouse, и разработчик может это сделать сам, так как ClickHouse veldig enkel å installere og krever ikke komplisert administrasjon:

Но если у нас много ClickHouse, og du må installere det ofte, så vil du automatisere denne prosessen. Til dette kan vi for eksempel bruke Kubernetes и klikkhus-operatør. I Kubernetes ClickHouse du kan sette det "på-klikk": Jeg kan klikke på en knapp, kjøre manifestet og databasen er klar. Jeg kan umiddelbart lage et diagram, begynne å laste opp beregninger der, og om 5 minutter har jeg et dashbord klart grafana. Det er så enkelt!

Resultatet?

således ClickHouse - dette er:

raskt. Alle vet dette.
bare. Litt kontroversielt, men jeg tror at det er vanskelig på trening, lett i kamp. Hvis du forstår hvordan ClickHouse det fungerer, da er alt veldig enkelt.
Universelt. Den passer for forskjellige scenarier: DWH, tidsserier, logglagring. Men det er det ikke OLTP database, så ikke prøv å lage korte innlegg og les der.
Interessant. Sannsynligvis den som jobber med ClickHouse, opplevd mange interessante øyeblikk i god og dårlig forstand. For eksempel kom en ny utgivelse, alt sluttet å fungere. Eller når du slet med en oppgave i to dager, men etter å ha stilt et spørsmål i Telegram-chatten, ble oppgaven løst på to minutter. Eller som på konferansen på rapporten til Lesha Milovidov, et skjermbilde fra ClickHouse brøt sendingen Høybelastning++. Denne typen ting skjer hele tiden og gjør livene våre vanskelige. ClickHouse lyst og interessant!

Презетацию можно посмотреть her.

Det etterlengtede møtet for utviklere av høylastsystemer kl Høybelastning++ finner sted 9. og 10. november i Skolkovo. Til slutt vil dette være en offline-konferanse (om enn med alle forholdsregler på plass), siden energien til HighLoad++ ikke kan pakkes online.

Til konferansen finner og viser vi deg case om teknologiens maksimale muligheter: HighLoad++ var, er og blir det eneste stedet hvor du på to dager kan lære hvordan Facebook, Yandex, VKontakte, Google og Amazon fungerer.

Etter å ha holdt møtene våre uten avbrudd siden 2007, møtes vi i år for 14. gang. I løpet av denne tiden har konferansen vokst 10 ganger; i fjor samlet den viktigste bransjebegivenheten 3339 deltakere, 165 foredragsholdere, rapporter og møter, og 16 spor kjørte samtidig.
I fjor var det 20 busser, 5280 liter te og kaffe, 1650 liter fruktdrikk og 10200 flasker vann. Og ytterligere 2640 kilo mat, 16 tallerkener og 000 kopper. Forresten, med pengene samlet inn fra resirkulert papir, plantet vi 25 eikefrøplanter :)

Du kan kjøpe billetter her, få nyheter om konferansen - her, og snakk på alle sosiale nettverk: Telegram, Facebook , Vkontakte и Twitter.

Kilde: www.habr.com

Flytte til ClickHouse: 3 år senere