Presťahovanie sa do ClickHouse: o 3 roky neskôr

Pred tromi rokmi Viktor Tarnavsky a Alexey Milovidov z Yandex na pódiu HighLoad++ povedal, aký dobrý je ClickHouse a ako nespomaľuje. A v ďalšej fáze tam bolo Alexander Zaitsev с správa o presťahovaní sa do clickhouse z iného analytického DBMS a so záverom, že clickhouse, samozrejme, dobré, ale nie príliš pohodlné. Keď v roku 2016 spol LifeStreet, kde Alexander potom pracoval, konvertoval multi-petabajtový analytický systém na clickhousebola to fascinujúca „cesta zo žltých tehál“ plná neznámych nebezpečenstiev – clickhouse vtedy to vyzeralo ako v mínovom poli.

O tri roky neskôr clickhouse sa stal oveľa lepším - počas tejto doby Alexander založil spoločnosť Altinity, ktorá nielen pomáha ľuďom sťahovať sa clickhouse desiatky projektov, ale vylepšuje aj samotný produkt spolu s kolegami z Yandexu. Teraz clickhouse stále to nie je bezstarostná prechádzka, ale už ani mínové pole.

Alexander pracuje s distribuovanými systémami od roku 2003 a vyvíja veľké projekty MySQL, Oracle и Vertica. Na poslednom HighLoad++ 2019 Alexander, jeden z priekopníkov používania clickhouse, povedal, čo je tento DBMS teraz. Dozvieme sa o hlavných funkciách clickhouse: ako sa líši od iných systémov a v akých prípadoch je efektívnejšie ho používať. Na príkladoch sa pozrieme na najnovšie a projektovo overené postupy pre stavebné systémy založené na clickhouse.

Retrospektíva: čo sa stalo pred 3 rokmi

Pred tromi rokmi sme previedli firmu LifeStreet na clickhouse z inej analytickej databázy a migrácia analýzy reklamnej siete vyzerala takto:

• júna 2016. V Open Source objavil clickhouse a náš projekt sa začal;
• V auguste. Dôkaz koncepcie: veľká reklamná sieť, infraštruktúra a 200 – 300 terabajtov dát;
• októbra. Prvé výrobné údaje;
• December. Úplné zaťaženie produktu predstavuje 10 – 50 miliárd udalostí denne.
• Jún 2017. Úspešná migrácia používateľov na clickhouse, 2,5 petabajtov dát na klastri 60 serverov.

Počas procesu migrácie narastalo pochopenie toho clickhouse je dobrý systém, s ktorým je príjemné pracovať, ale toto je interný projekt spoločnosti Yandex. Preto existujú nuansy: Yandex sa najskôr bude zaoberať svojimi vlastnými internými zákazníkmi a až potom komunitou a potrebami externých používateľov a ClickHouse potom nedosiahol podnikovú úroveň v mnohých funkčných oblastiach. Preto sme založili Altinity v marci 2017, aby sme vyrobili clickhouse ešte rýchlejšie a pohodlnejšie nielen pre Yandex, ale aj pre ostatných používateľov. A teraz my:

• Školíme a pomáhame vytvárať riešenia založené na clickhouse aby sa zákazníci nedostali do problémov a aby riešenie nakoniec fungovalo;
• Poskytujeme podporu 24/7 clickhouse- inštalácie;
• Vyvíjame naše vlastné ekosystémové projekty;
• Aktívne sa zaväzujeme k sebe clickhouse, ktorý reaguje na požiadavky používateľov, ktorí chcú vidieť určité funkcie.

A samozrejme pomáhame pri sťahovaní clickhouse с MySQL, Vertica, veštec, Zelená slivka, červený posun a iné systémy. Boli sme zapojení do rôznych krokov a všetky boli úspešné.

Prečo sa presťahovať do clickhouse

Nespomalí! Toto je hlavný dôvod. clickhouse - veľmi rýchla databáza pre rôzne scenáre:

Náhodné citáty ľudí, ktorí s ľuďmi pracujú už dlho clickhouse.

Škálovateľnosť. Na niektorých iných databázach môžete dosiahnuť dobrý výkon na jednom hardvéri, ale clickhouse môžete škálovať nielen vertikálne, ale aj horizontálne, jednoducho pridaním serverov. Všetko nefunguje tak hladko, ako by sme chceli, ale ide to. Systém môžete rozširovať s rastom vášho podnikania. Je dôležité, aby sme neboli teraz limitovaní riešením a vždy existuje potenciál na rozvoj.

Prenosnosť. Neexistuje žiadna pripútanosť k jednej veci. Napríklad s Amazon Redshift Je ťažké sa niekam posunúť. A clickhouse môžete si ho nainštalovať na svoj laptop, server, nasadiť ho do cloudu, prejsť na Kubernetes — neexistujú žiadne obmedzenia týkajúce sa prevádzky infraštruktúry. To je výhodné pre každého a to je veľká výhoda, ktorou sa mnohé iné podobné databázy nemôžu pochváliť.

flexibilita. clickhouse sa nezastaví pri jednej veci, napríklad Yandex.Metrica, ale vyvíja sa a používa sa v čoraz väčšom počte rôznych projektov a odvetví. Dá sa rozšíriť pridaním nových schopností na riešenie nových problémov. Napríklad sa verí, že ukladanie protokolov do databázy je neslušné, a tak prišli s ElasticSearch. Ale vďaka flexibilite clickhouse, môžete v ňom uložiť aj polená a často je to ešte lepšie ako v ElasticSearch - v clickhouse to vyžaduje 10-krát menej železa.

zadarmo Open Source. Nemusíte za nič platiť. Nie je potrebné vyjednávať o povolení na inštaláciu systému na váš laptop alebo server. Žiadne skryté poplatky. Zároveň žiadna iná Open Source databázová technológia nemôže konkurovať v rýchlosti clickhouse. MySQL, MariaDB, Greenplum - všetky sú oveľa pomalšie.

Spoločenstvo, riadiť a zábava, v clickhouse výborná komunita: meetupy, chaty a Alexey Milovidov, ktorý nás všetkých nabíja energiou a optimizmom.

Presťahovanie sa do ClickHouse

Ísť do clickhouse z nejakého dôvodu potrebujete iba tri veci:

• Pochopte obmedzenia clickhouse a na čo sa nehodí.
• Využite výhody technológie a jej najväčšie prednosti.
• Experimentujte. Dokonca pochopiť, ako to funguje clickhouse, nie vždy sa dá predpovedať, kedy to bude rýchlejšie, kedy pomalšie, kedy lepšie a kedy horšie. Tak to skúste.

Problém s pohybom

Existuje len jedno „ale“: ak sa presťahujete do clickhouse z niečoho iného, ​​potom sa väčšinou niečo pokazí. Na niektoré praktiky a veci, ktoré fungujú v našej obľúbenej databáze, sme si už zvykli. Napríklad ktokoľvek, s kým spolupracuje SQL-databázy považujú za povinný nasledujúci súbor funkcií:

• transakcie;
• obmedzenia;
• konzistencia;
• indexy;
• AKTUALIZOVAŤ/VYMAZAŤ;
• NULL;
• milisekúnd;
• odliatky automatického typu;
• viacnásobné spojenia;
• ľubovoľné oddiely;
• nástroje na správu klastrov.

Nábor je povinný, ale pred tromi rokmi v r clickhouse Žiadna z týchto funkcií nebola k dispozícii! Teraz zostáva menej ako polovica toho, čo nebolo implementované: transakcie, obmedzenia, konzistencia, milisekundy a pretypovanie.

A hlavné je, že v clickhouse niektoré štandardné postupy a prístupy nefungujú alebo fungujú inak, ako sme zvyknutí. Všetko, čo sa objaví v clickhouse, sa viaže na "ClickHouse spôsobom“, t.j. funkcie sa líšia od iných databáz. Napríklad:

• Indexy nie sú vybrané, ale preskočené.
• AKTUALIZOVAŤ/VYMAZAŤ nie synchrónne, ale asynchrónne.
• Existuje viacero spojení, ale neexistuje žiadny plánovač dopytov. Ako sa potom vykonávajú, ľuďom z databázového sveta vo všeobecnosti nie je príliš jasné.

ClickHouse Scripts

V roku 1960 americký matematik maďarského pôvodu Wigner EP napísal článok"Neprimeraná účinnosť matematiky v prírodných vedách“ („Nepochopiteľná efektívnosť matematiky v prírodných vedách“), že svet okolo nás je z nejakého dôvodu dobre popísaný matematickými zákonmi. Matematika je abstraktná veda a fyzikálne zákony vyjadrené v matematickej forme nie sú triviálne a Wigner EP zdôraznil, že je to veľmi zvláštne.

Z môjho pohľadu, clickhouse - rovnaká zvláštnosť. Na preformulovanie Wignera môžeme povedať toto: nepredstaviteľná účinnosť je ohromujúca clickhouse v širokej škále analytických aplikácií!

Zoberme si napríklad Dátový sklad v reálnom čase, do ktorého sa dáta načítavajú takmer nepretržite. Chceme od nej prijímať žiadosti s druhým oneskorením. Prosím - použite to clickhouse, pretože pre tento scenár bol navrhnutý. clickhouse presne takto sa používa nielen na webe, ale aj v marketingu a finančnej analytike, AdTech, ako aj v Odhaľovanie podvodovn. IN Dátový sklad v reálnom čase používa sa komplexná štruktúrovaná schéma ako „hviezda“ alebo „snehová vločka“, s mnohými tabuľkami REGISTRÁCIA (niekedy viac) a údaje sa zvyčajne ukladajú a menia v niektorých systémoch.

Zoberme si iný scenár - Časové rady: monitorovanie zariadení, sietí, štatistiky používania, internet vecí. Tu sa stretávame s pomerne jednoduchými udalosťami zoradenými v čase. clickhouse nebol pôvodne vyvinutý na tento účel, ale ukázalo sa, že funguje dobre, a preto ho veľké spoločnosti používajú clickhouse ako úložisko monitorovacích informácií. Preskúmať, či je to vhodné clickhouse pre časové rady sme urobili benchmark na základe prístupu a výsledkov InfluxDB и Časová mierkaDB - špecializovaný časový rad databázy. Ukázalo saŽe clickhouse, aj bez optimalizácie pre takéto úlohy vyhráva na cudzom poli:

В časový rad Zvyčajne sa používa úzky stôl - niekoľko malých stĺpcov. Veľa údajov môže pochádzať z monitorovania – milióny záznamov za sekundu – a zvyčajne prichádzajú v malých dávkach (real-time streaming). Preto je potrebný iný vkladací skript a samotné dotazy majú svoje špecifiká.

vedenie Log. Zhromažďovanie protokolov do databázy je zvyčajne zlé, ale clickhouse to sa dá urobiť s niektorými komentármi, ako je popísané vyššie. Mnoho spoločností používa clickhouse presne na tento účel. V tomto prípade používame plochý široký stôl, kde ukladáme celé polená (napríklad vo forme JSON), alebo nakrájajte na kúsky. Dáta sa zvyčajne načítavajú vo veľkých dávkach (súboroch) a vyhľadávame podľa nejakého poľa.

Pre každú z týchto funkcií sa zvyčajne používajú špecializované databázy. clickhouse človek to všetko dokáže a tak dobre, že ich predčí. Poďme sa teraz na to pozrieť bližšie časový rad scenár a ako správne „variť“. clickhouse pre tento scenár.

Časový rad

V súčasnosti je to hlavný scenár, pre ktorý clickhouse považovať za štandardné riešenie. Časový rad je súbor udalostí usporiadaných v čase, predstavujúci zmeny v nejakom procese v čase. Môže to byť napríklad srdcová frekvencia za deň alebo počet procesov v systéme. Všetko, čo dáva času tiká s nejakými rozmermi, je časový rad:

Väčšina týchto typov udalostí pochádza z monitorovania. Môže to byť nielen monitorovanie webu, ale aj reálnych zariadení: autá, priemyselné systémy, IoT, továrne či bezpilotné taxíky, do kufra ktorých už Yandex dáva clickhouse-server.

Existujú napríklad spoločnosti, ktoré zbierajú údaje z lodí. Každých pár sekúnd pošlú senzory na kontajnerovej lodi stovky rôznych meraní. Inžinieri ich študujú, stavajú modely a snažia sa pochopiť, ako efektívne je plavidlo využívané, pretože kontajnerová loď by nemala byť nečinná ani sekundu. Akékoľvek prestoje sú stratou peňazí, preto je dôležité predvídať trasu tak, aby prestávky boli minimálne.

V súčasnosti dochádza k nárastu špecializovaných databáz, ktoré merajú časový rad. Online DB-motory Rôzne databázy sú nejakým spôsobom zoradené a môžete ich zobraziť podľa typu:

Najrýchlejšie rastúci druh je časové radys. Rastú aj grafové databázy, ale časové radyv posledných rokoch rástli rýchlejšie. Typickými predstaviteľmi tejto rodiny databáz sú InfluxDB, Prometheus, KDB, Časová mierkaDB (postavená na PostgreSQL), riešenia z Amazonka. clickhouse možno použiť aj tu a používa sa. Dovoľte mi uviesť niekoľko verejných príkladov.

Jedným z priekopníkov je spoločnosť CloudFlare (CDN- poskytovateľ). Sledujú ich CDN cez clickhouse (DNS- žiadosti, HTTP-dotazy) s obrovským zaťažením - 6 miliónov udalostí za sekundu. Všetko prechádza Kafka, ide clickhouse, ktorý poskytuje možnosť vidieť dashboardy udalostí v systéme v reálnom čase.

Comcast - jeden z lídrov v oblasti telekomunikácií v USA: Internet, digitálna televízia, telefonovanie. Vytvorili podobný riadiaci systém CDN v rámci Open Source projekt Apache Traffic Control pracovať s vašimi obrovskými údajmi. clickhouse používa sa ako backend pre analytiku.

percona zabudovaný clickhouse vo svojom vnútri PMMuložiť monitorovanie rôznych MySQL.

Špecifické požiadavky

Databázy časových radov majú svoje špecifické požiadavky.

• Rýchle vkladanie od mnohých agentov. Údaje z mnohých streamov musíme vkladať veľmi rýchlo. clickhouse Robí to dobre, pretože všetky jeho vložky sú neblokujúce. akýkoľvek vložiť je nový súbor na disku a malé vložky môžu byť ukladané do vyrovnávacej pamäte tak či onak. IN clickhouse Je lepšie vkladať údaje vo veľkých dávkach a nie po jednom riadku.
• Flexibilná schéma. V časový rad zvyčajne nepoznáme úplne štruktúru údajov. Je možné vybudovať monitorovací systém pre konkrétnu aplikáciu, ale potom je ťažké ho použiť pre inú aplikáciu. To si vyžaduje flexibilnejšiu schému. clickhouse, vám to umožňuje, aj keď ide o silne typizovaný základ.
• Efektívne ukladanie a zabúdanie údajov. Zvyčajne v časový rad obrovské množstvo dát, preto ich treba uchovávať čo najefektívnejšie. Napríklad pri InfluxDB dobrá kompresia je jeho hlavnou vlastnosťou. Ale okrem ukladania musíte byť tiež schopní „zabudnúť“ na staré údaje a urobiť nejaký druh downsampling — automatické počítanie agregátov.
• Rýchle dotazy na agregované údaje. Niekedy je zaujímavé pozrieť sa na posledných 5 minút s presnosťou milisekúnd, ale pri mesačných údajoch nemusí byť potrebná minútová alebo sekundová granularita – stačia všeobecné štatistiky. Podpora tohto druhu je nevyhnutná, inak bude vybavenie žiadosti na 3 mesiace trvať veľmi dlho, dokonca aj v clickhouse.
• Žiadosti ako "posledný bod zo dňa». Tieto sú typické pre časový rad otázky: pozrite sa na posledné meranie alebo stav systému v danom okamihu t. Nie sú to veľmi príjemné dotazy na databázu, ale musíte ich tiež vedieť vykonávať.
• „Lepenie“ časových radov. Časový rad je časový rad. Ak existujú dva časové rady, často musia byť prepojené a korelované. Nie je vhodné to robiť vo všetkých databázach, najmä v prípade nezarovnaných časových radov: tu sú niektoré časové body, sú iné. Môžete to považovať za priemer, ale zrazu tam bude stále diera, takže to nie je jasné.

Pozrime sa, ako sú tieto požiadavky splnené clickhouse.

Schéma

В clickhouse schéma pre časový rad možno vykonať rôznymi spôsobmi v závislosti od stupňa pravidelnosti údajov. Na bežných dátach je možné postaviť systém, keď vopred poznáme všetky metriky. Urobil som napríklad toto CloudFlare s monitorovaním CDN je dobre optimalizovaný systém. Môžete si vybudovať všeobecnejší systém, ktorý monitoruje celú infraštruktúru a rôzne služby. Pri nepravidelných údajoch vopred nevieme, čo sledujeme – a to je asi najčastejší prípad.

Pravidelné údaje. Stĺpce. Schéma je jednoduchá - stĺpce s požadovanými typmi:

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

Toto je bežná tabuľka, ktorá monitoruje nejaký druh aktivity načítania systému (užívateľ, systém, nečinný, pekný). Jednoduché a pohodlné, ale nie flexibilné. Ak chceme flexibilnejšiu schému, môžeme použiť polia.

Nepravidelné údaje. Polia:

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

Štruktúra Vnorené sú dve polia: metriky.názov и metriky.hodnota. Tu môžete uložiť také ľubovoľné monitorovacie údaje, ako je pole mien a pole meraní pre každú udalosť. Pre ďalšiu optimalizáciu môžete namiesto jednej takejto štruktúry vytvoriť niekoľko. Napríklad jeden pre vznášať sa-hodnota, iný - za int- to znamená preto int Chcem skladovať efektívnejšie.

Takáto štruktúra je však ťažšie dostupná. Budete musieť použiť špeciálnu konštrukciu pomocou špeciálnych funkcií na vytiahnutie hodnôt najprv indexu a potom poľa:

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

Ale stále to funguje pomerne rýchlo. Ďalším spôsobom ukladania nepravidelných údajov je riadok.

Nepravidelné údaje. Struny. V tejto tradičnej metóde, bez polí, sa názvy a hodnoty ukladajú súčasne. Ak z jedného zariadenia pochádza 5 000 meraní naraz, v databáze sa vygeneruje 5 000 riadkov:

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 sa s tým vyrovná - má špeciálne rozšírenia clickhouse SQL, Napríklad maxIf — špeciálna funkcia, ktorá vypočítava maximum podľa metriky, keď je splnená nejaká podmienka. V jednej požiadavke môžete napísať niekoľko takýchto výrazov a okamžite vypočítať hodnotu pre niekoľko metrík.

Porovnajme tri prístupy:

Детали

Tu som pridal "Veľkosť údajov na disku" pre niektoré testovacie údaje. V prípade stĺpcov máme najmenšiu veľkosť údajov: maximálnu kompresiu, maximálnu rýchlosť dotazovania, ale platíme tým, že musíme všetko zaznamenať naraz.

V prípade polí je všetko trochu horšie. Dáta sú stále dobre komprimované a je možné uložiť nepravidelný vzor. ale clickhouse - stĺpcová databáza a keď začneme všetko ukladať do poľa, zmení sa na riadkovú a za flexibilitu platíme efektívnosťou. Pri akejkoľvek operácii budete musieť načítať celé pole do pamäte, potom v ňom nájsť požadovaný prvok – a ak pole narastie, zníži sa rýchlosť.

V jednej zo spoločností, ktorá používa tento prístup (napr. Uber), polia sú rozrezané na kúsky so 128 prvkami. Dáta z niekoľkých tisíc metrík s objemom 200 TB dát/deň sú uložené nie v jednom poli, ale v 10 alebo 30 poliach so špeciálnou úložnou logikou.

Najjednoduchší prístup je so strunami. Údaje sú však zle komprimované, veľkosť tabuľky je veľká a aj keď sú dopyty založené na niekoľkých metrikách, ClickHouse nefunguje optimálne.

Hybridná schéma

Predpokladajme, že sme si vybrali obvod poľa. Ak však vieme, že väčšina našich informačných panelov zobrazuje iba používateľské a systémové metriky, môžeme tieto metriky dodatočne zhmotniť do stĺpcov z poľa na úrovni tabuľky týmto spôsobom:

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 vkladaní clickhouse ich automaticky spočíta. Týmto spôsobom môžete spojiť podnikanie s potešením: schéma je flexibilná a všeobecná, ale vytiahli sme najčastejšie používané stĺpce. Upozorňujeme, že to nevyžadovalo výmenu vložky a ETLktorý pokračuje vo vkladaní polí do tabuľky. Práve sme to urobili ALTER TABLE, pridal pár reproduktorov a dostali sme hybridnú a rýchlejšiu schému, ktorú môžete hneď začať používať.

Kodeky a kompresia

pre časový rad Záleží na tom, ako dobre zabalíte údaje, pretože množstvo informácií môže byť veľmi veľké. IN clickhouse Existuje sada nástrojov na dosiahnutie kompresného efektu 1:10, 1:20 a niekedy aj viac. To znamená, že 1 TB rozbalených dát na disku zaberie 50-100 GB. Menšia veľkosť je dobrá, dáta sa dajú čítať a spracovávať rýchlejšie.

Ak chcete dosiahnuť vysokú úroveň kompresie, clickhouse podporuje nasledujúce kodeky:

Príklad tabuľky:

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

Tu definujeme kodek DoubleDelta v jednom prípade, v druhom - Gorila, a určite pridáme ďalšie LZ4 kompresia. V dôsledku toho sa veľkosť údajov na disku výrazne zníži:

Toto ukazuje, koľko miesta zaberajú rovnaké dáta, ale s použitím rôznych kodekov a kompresií:

• v súbore GZIP na disku;
• v ClickHouse bez kodekov, ale s kompresiou ZSTD;
• v ClickHouse s kodekmi a kompresiou LZ4 a ZSTD.

Je vidieť, že tabuľky s kodekmi zaberajú oveľa menej miesta.

Veľkosť je dôležitá

Nie menej dôležité выбрать správny typ údajov:

Vo všetkých vyššie uvedených príkladoch som použil Plavák64. Ale keby sme si vybrali Plavák32, potom by to bolo ešte lepšie. Dobre to predviedli chalani z Perkony vo vyššie odkazovanom článku. Je dôležité použiť najkompaktnejší typ, ktorý je vhodný pre danú úlohu: ešte menej pre veľkosť disku ako pre rýchlosť dotazu. clickhouse veľmi citlivý na toto.

Ak môžete použiť int32 namiesto int64, potom očakávajte takmer dvojnásobný nárast výkonu. Dáta zaberajú menej pamäte a všetka „aritmetika“ funguje oveľa rýchlejšie. clickhouse vnútorne ide o veľmi striktne typizovaný systém, maximálne využíva všetky možnosti, ktoré moderné systémy poskytujú.

Agregácia a Zhmotnené pohľady

Agregácia a materializované zobrazenia vám umožňujú vytvárať agregáty pre rôzne príležitosti:

Napríklad môžete mať neagregované zdrojové údaje a môžete k nim pripojiť rôzne zhmotnené pohľady s automatickým sčítaním prostredníctvom špeciálneho nástroja SummingMergeTree (SMT). SMT je špeciálna agregujúca dátová štruktúra, ktorá automaticky vypočítava agregáty. Nespracované dáta sa vkladajú do databázy, automaticky sa agregujú a dajú sa na nich okamžite používať dashboardy.

TTL - „zabudnite“ na staré údaje

Ako „zabudnúť“ údaje, ktoré už nie sú potrebné? clickhouse vie, ako to urobiť. Pri vytváraní tabuliek môžete určiť TTL výrazy: napríklad, že uchovávame minútové údaje za jeden deň, denné údaje za 30 dní a nikdy sa nedotýkame týždenných alebo mesačných údajov:

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

Viacvrstvové - rozdeliť dáta medzi disky

Ak ideme ďalej, dáta môžu byť uložené v clickhouse na rôznych miestach. Predpokladajme, že chceme uložiť horúce údaje za posledný týždeň na veľmi rýchlom mieste SSDa ďalšie historické údaje sme umiestnili na iné miesto. IN clickhouse toto je teraz možné:

Môžete nakonfigurovať politiku ukladania (pravidlá skladovania) Takže clickhouse automaticky prenesie údaje po dosiahnutí určitých podmienok do iného úložiska.

To však nie je všetko. Na úrovni špecifickej tabuľky môžete definovať pravidlá, kedy presne dáta idú do chladiaceho priestoru. Dáta sú napríklad uložené na veľmi rýchlom disku 7 dní a všetko, čo je staršie, sa prenáša na pomalý. To je dobré, pretože vám to umožňuje udržiavať systém na maximálnom výkone a zároveň kontrolovať náklady a neplytvať peniazmi za studené dáta:

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

Jedinečné príležitosti clickhouse

Takmer vo všetkom clickhouse Existujú také „zvýraznenia“, ale sú kompenzované exkluzivitou - niečo, čo nie je v iných databázach. Tu sú napríklad niektoré jedinečné funkcie clickhouse:

• Polia. V clickhouse veľmi dobrá podpora pre polia, ako aj schopnosť vykonávať na nich zložité výpočty.
• Agregácia dátových štruktúr. Toto je jedna z "zabijáckych vlastností" clickhouse. Napriek tomu, že chlapci z Yandexu hovoria, že nechceme agregovať údaje, všetko je agregované clickhouse, pretože je to rýchle a pohodlné.
• Zhmotnené pohľady. Spoločne s agregovanými dátovými štruktúrami vám materializované zobrazenia umožňujú pohodlnejšie real-time agregácia.
• ClickHouse SQL. Toto je jazykové rozšírenie SQL s niektorými ďalšími a exkluzívnymi funkciami, ktoré sú dostupné iba v clickhouse. Predtým to bolo na jednej strane ako expanzia a na druhej nevýhoda. Teraz takmer všetky nevýhody v porovnaní s SQL 92 odstránili sme to, teraz je to len rozšírenie.
• Lambda– výrazy. Sú ešte v nejakej databáze?
• ML-podpora. Toto je dostupné v rôznych databázach, niektoré sú lepšie, iné horšie.
• open source. Môžeme expandovať clickhouse spolu. Teraz v clickhouse okolo 500 prispievateľov a toto číslo neustále rastie.

Záludné otázky

В clickhouse existuje veľa rôznych spôsobov, ako urobiť to isté. Napríklad môžete vrátiť poslednú hodnotu z tabuľky tromi rôznymi spôsobmi CPU (existuje aj štvrtá, ale tá je ešte exotickejšia).

Prvý ukazuje, aké pohodlné je robiť v clickhouse otázky, keď to chcete skontrolovať násobný obsiahnuté v poddotaze. To je niečo, čo mne osobne v iných databázach veľmi chýbalo. Ak chcem niečo porovnať s poddotazom, tak v iných databázach sa s ním dá porovnať iba skalár, ale pre niekoľko stĺpcov potrebujem napísať REGISTRÁCIA. V clickhouse môžete použiť tuple:

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

Druhá metóda robí to isté, ale používa agregovanú funkciu argMax:

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

В clickhouse agregačných funkcií je niekoľko desiatok a ak použijete kombinatory, tak podľa zákonov kombinatoriky ich dostanete asi tisíc. ArgMax - jedna z funkcií, ktorá vypočíta maximálnu hodnotu: požiadavka vráti hodnotu use_user, pri ktorej sa dosiahne maximálna hodnota vytvorené_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 PRIDAJ SA — „lepenie“ riadkov s rôznym časom. Toto je jedinečná funkcia pre databázy, ktorá je dostupná iba v kdb+. Ak existujú dva časové rady s rôznymi časmi, ASOF PRIDAJ SA umožňuje ich presúvať a spájať v jednej žiadosti. Pre každú hodnotu v jednom časovom rade sa nájde najbližšia hodnota v druhom a vrátia sa na rovnaký riadok:

Analytické funkcie

V štandarde SQL-2003 môžeš písať takto:

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 Nemôžete to urobiť - nepodporuje štandard SQL-2003 a pravdepodobne to nikdy neurobí. Namiesto toho v clickhouse Je zvykom písať takto:

Sľúbil som lambdy - tu sú!

Toto je analógia analytického dotazu v štandarde SQL-2003: počíta rozdiel medzi nimi časová pečiatka, trvanie, poradové číslo - všetko, čo zvyčajne považujeme za analytické funkcie. IN clickhouse Počítame ich cez polia: najprv dáta zbalíme do poľa, potom na poli urobíme všetko, čo chceme, a potom ho rozbalíme späť. Nie je to veľmi pohodlné, vyžaduje to minimálne lásku k funkčnému programovaniu, ale je to veľmi flexibilné.

Špeciálne vlastnosti

Okrem toho v clickhouse veľa špecializovaných funkcií. Ako napríklad určiť, koľko relácií prebieha súčasne? Typickou úlohou monitorovania je určiť maximálnu záťaž jednou požiadavkou. IN clickhouse Na tento účel existuje špeciálna funkcia:

Vo všeobecnosti má ClickHouse špeciálne funkcie na mnohé účely:

• behRozdiel, behAkumulovať, sused;
• sumMap(kľúč, hodnota);
• timeSeriesGroupSum(uid, casova pečiatka, hodnota);
• timeSeriesGroupRateSum(uid, casova pečiatka, hodnota);
• skewPop, skewSamp, kurtPop, kurtSamp;
• S VÝPLŇOU / S VAZBAMI;
• simpleLinearRegression, stochasticLinearRegression.

Toto nie je úplný zoznam funkcií, celkovo ich je 500-600. Tip: všetky funkcie v clickhouse je v systémovej tabuľke (nie všetky sú zdokumentované, ale všetky sú zaujímavé):

select * from system.functions order by name

clickhouse ukladá o sebe veľa informácií, vrátane log tabuľky, query_log, protokol sledovania, protokol operácií s blokmi údajov (part_log), denník metrík a systémový denník, ktoré zvyčajne zapisuje na disk. Metriky denníka sú časový rad в clickhouse v skutočnosti clickhouse: Úlohu môže zohrať aj samotná databáza časový rad databázy, čím sa „požiera“.

To je tiež jedinečná vec - pretože robíme dobrú prácu pre časový radPrečo si nemôžeme uložiť všetko, čo potrebujeme? Nepotrebujeme Prometheus, všetko si nechávame pre seba. Pripojené grafana a sledujeme sami seba. Ak však clickhouse pády, neuvidíme prečo, takže to zvyčajne nerobia.

Veľký zhluk alebo veľa malých clickhouse

Čo je lepšie - jeden veľký klaster alebo veľa malých ClickHouses? Tradičný prístup k DWH je veľký klaster, v ktorom sú pre každú aplikáciu pridelené okruhy. Prišli sme k správcovi databázy - dajte nám diagram a oni nám jeden dali:

В clickhouse môžete to urobiť inak. Každú aplikáciu si môžete nastaviť podľa seba clickhouse:

Ten veľký obludný už nepotrebujeme DWH a neovládateľní správcovia. Každej aplikácii môžeme dať to svoje clickhouse, a vývojár to môže urobiť sám, keďže clickhouse veľmi jednoduchá inštalácia a nevyžaduje zložitú správu:

Ale ak máme veľa clickhousea musíte ho často inštalovať, potom chcete tento proces automatizovať. Na to môžeme použiť napr Kubernetes и clickhouse-operátor. IN Kubernetes ClickHouse môžete to dať „on-click“: môžem kliknúť na tlačidlo, spustiť manifest a databáza je pripravená. Hneď si vytvorím diagram, začnem tam nahrávať metriky a za 5 minút mám dashboard hotový grafana. Je to také jednoduché!

Výsledok?

Takže, clickhouse - toto je:

• rýchlo. Každý to vie.
• proste. Trochu kontroverzné, ale verím, že je to ťažké v tréningu, ľahké v boji. Ak chápete ako clickhouse funguje to, potom je všetko veľmi jednoduché.
• všeobecne. Je vhodný pre rôzne scenáre: DWH, časové rady, ukladanie denníkov. Ale nie je OLTP databázy, takže sa tam nesnažte robiť krátke vložky a čítania.
• Zaujímavo. Pravdepodobne ten, kto pracuje s clickhouse, zažil veľa zaujímavých momentov v dobrom aj zlom zmysle. Napríklad vyšlo nové vydanie, všetko prestalo fungovať. Alebo keď ste sa s úlohou trápili dva dni, no po položení otázky v telegramovom chate bola úloha vyriešená za dve minúty. Alebo ako na konferencii pri správe Leshy Milovidovovej, screenshot z clickhouse prerušil vysielanie HighLoad++. Takéto veci sa stávajú neustále a sťažujú nám život. clickhouse svetlé a zaujímavé!

Prezentáciu si môžete pozrieť tu.

Dlho očakávané stretnutie vývojárov vysoko zaťažených systémov o HighLoad++ sa uskutoční 9. a 10. novembra v Skolkove. Nakoniec, toto bude offline konferencia (hoci so všetkými preventívnymi opatreniami), pretože energiu HighLoad++ nemožno zabaliť online.

Pre konferenciu nájdeme a ukážeme prípady o maximálnych možnostiach technológie: HighLoad++ bolo, je a bude jediným miestom, kde sa za dva dni dozviete, ako funguje Facebook, Yandex, VKontakte, Google a Amazon.

Po tom, čo sa naše stretnutia konali bez prerušenia od roku 2007, tento rok sa stretneme už po 14. raz. Počas tejto doby sa konferencia rozrástla 10-krát, minulý rok sa na kľúčovom podujatí v odvetví stretlo 3339 165 účastníkov, 16 rečníkov, správ a stretnutí a súčasne bežalo XNUMX skladieb.
Vlani to bolo 20 autobusov, 5280 litrov čaju a kávy, 1650 litrov ovocných nápojov a 10200 fliaš vody. A ďalších 2640 16 kilogramov jedla, 000 25 tanierov a 000 100 šálok. Mimochodom, za peniaze vyzbierané z recyklovaného papiera sme vysadili XNUMX dubových sadeníc :)

Lístky si môžete kúpiť tu, dostávať novinky o konferencii - tua rozprávajte sa na všetkých sociálnych sieťach: telegram, facebook, VKontakte и Twitter.

Zdroj: hab.com