Mutarea la ClickHouse: 3 ani mai târziu

Acum trei ani Viktor Tarnavsky și Alexey Milovidov de la Yandex pe scenă HighLoad ++ a declarat, cât de bun este ClickHouse și cum nu încetinește. Și pe următoarea etapă a existat Alexander Zaitsev с raport despre mutarea la Faceți clic pe Casă dintr-un alt SGBD analitic şi cu concluzia că Faceți clic pe Casă, desigur, bun, dar nu foarte convenabil. Când în 2016 compania LifeStreet, unde lucra atunci Alexander, transforma un sistem analitic cu mai mulți petaocteți în Faceți clic pe Casă, era un „drum din cărămidă galbenă” fascinant, plin de pericole necunoscute - Faceți clic pe Casă pe atunci arăta ca un câmp minat.

Trei ani mai tarziu Faceți clic pe Casă a devenit mult mai bun - în acest timp Alexander a fondat compania Altinity, care nu numai că îi ajută pe oameni să se mute Faceți clic pe Casă zeci de proiecte, dar îmbunătățește și produsul în sine împreună cu colegii de la Yandex. Acum Faceți clic pe Casă încă nu este o plimbare fără griji, dar nu mai este un câmp minat.

Alexander lucrează cu sisteme distribuite din 2003, dezvoltând proiecte mari pe MySQL, Oracle и Vertica. Pe ultimul HighLoad++ 2019 Alexander, unul dintre pionierii folosirii Faceți clic pe Casă, a spus ce este acest DBMS acum. Vom afla despre principalele caracteristici Faceți clic pe Casă: cum diferă de alte sisteme și în ce cazuri este mai eficient să-l folosești. Folosind exemple, vom analiza practicile recente și testate de proiecte pentru sistemele de construcție bazate pe Faceți clic pe Casă.

Retrospectivă: ce s-a întâmplat acum 3 ani

Acum trei ani am transferat compania LifeStreet pe Faceți clic pe Casă dintr-o altă bază de date analitică, iar migrarea analizei rețelei publicitare a arătat astfel:

• iunie 2016. În Sursă deschisă a apărut Faceți clic pe Casă și proiectul nostru a început;
• August. Dovada de concept: retea mare de publicitate, infrastructura si 200-300 terabytes de date;
• Octombrie. Primele date de producție;
• Decembrie. Încărcarea completă a produsului este de 10-50 de miliarde de evenimente pe zi.
• Iunie 2017. Migrarea cu succes a utilizatorilor către Faceți clic pe Casă, 2,5 petaocteți de date pe un cluster de 60 de servere.

În timpul procesului de migrare, a existat o înțelegere tot mai mare a faptului Faceți clic pe Casă este un sistem bun cu care este plăcut să lucrați, dar acesta este un proiect intern al Yandex. Prin urmare, există nuanțe: Yandex se va ocupa mai întâi de propriii clienți interni și abia apoi de comunitatea și de nevoile utilizatorilor externi, iar ClickHouse nu a atins apoi nivelul de întreprindere în multe domenii funcționale. De aceea am fondat Altinity în martie 2017 pentru a face Faceți clic pe Casă chiar mai rapid și mai convenabil nu numai pentru Yandex, ci și pentru alți utilizatori. Și acum noi:

• Ne antrenăm și ajutăm să construim soluții bazate pe Faceți clic pe Casă pentru ca clienții să nu aibă probleme și pentru ca soluția să funcționeze în cele din urmă;
• Oferim asistență 24/7 Faceți clic pe Casă- instalatii;
• Ne dezvoltăm propriile proiecte de ecosistem;
• Ne angajăm activ față de noi înșine Faceți clic pe Casă, răspunzând la solicitările utilizatorilor care doresc să vadă anumite funcții.

Și, desigur, ajutăm cu mutarea în Faceți clic pe Casă с MySQL, Vertica, Oracol, Prună verde, Redshift și alte sisteme. Am fost implicați într-o varietate de mișcări și toate au avut succes.

De ce să te muți la Faceți clic pe Casă

Nu încetinește! Acesta este motivul principal. Faceți clic pe Casă - baza de date foarte rapida pentru diferite scenarii:

Citate aleatorii de la oameni care lucrează cu oameni de mult timp Faceți clic pe Casă.

Scalabilitate. Pe o altă bază de date puteți obține performanțe bune pe o singură piesă de hardware, dar Faceți clic pe Casă puteți scala nu numai pe verticală, ci și pe orizontală, prin simpla adăugare de servere. Totul nu funcționează atât de bine pe cât ne-am dori, dar funcționează. Puteți extinde sistemul pe măsură ce afacerea dvs. crește. Este important să nu fim limitați de soluție acum și există întotdeauna potențial de dezvoltare.

Portabilitate. Nu există atașament față de un singur lucru. De exemplu, cu Amazon RedShift E greu să te muți undeva. A Faceți clic pe Casă îl puteți instala pe laptop, server, îl puteți implementa în cloud, accesați Kubernetes — nu există restricții privind exploatarea infrastructurii. Acest lucru este convenabil pentru toată lumea și acesta este un mare avantaj cu care multe alte baze de date similare nu se pot lăuda.

flexibilitate. Faceți clic pe Casă nu se oprește la un singur lucru, de exemplu, Yandex.Metrica, ci se dezvoltă și este utilizat în tot mai multe proiecte și industrii diferite. Poate fi extins prin adăugarea de noi capabilități pentru a rezolva noi probleme. De exemplu, se crede că stocarea jurnalelor într-o bază de date este o manieră proastă, așa că au venit cu Elasticsearch. Dar datorită flexibilității Faceți clic pe Casă, puteți stoca, de asemenea, jurnalele în el și adesea acest lucru este chiar mai bun decât în Elasticsearch - în Faceți clic pe Casă acest lucru necesită de 10 ori mai puțin fier.

gratuit Open Source. Nu trebuie să plătiți pentru nimic. Nu este nevoie să negociați permisiunea pentru a instala sistemul pe laptop sau server. Fără taxe ascunse. În același timp, nicio altă tehnologie de baze de date Open Source nu poate concura în viteză Faceți clic pe Casă. MySQL, MariaDB, Greenplum - toate sunt mult mai lente.

Comunitate, conduce și distracţie. În Faceți clic pe Casă comunitate excelentă: întâlniri, chat-uri și Alexey Milovidov, care ne încarcă pe toți cu energia și optimismul lui.

Mutarea la ClickHouse

A merge la Faceți clic pe Casă din anumite motive, ai nevoie doar de trei lucruri:

• Înțelegeți limitările Faceți clic pe Casă și pentru ce nu este potrivit.
• Profită tehnologie și cele mai mari puncte forte ale acesteia.
• Experiment. Chiar și înțelegerea cum funcționează Faceți clic pe Casă, nu este întotdeauna posibil să preziceți când va fi mai rapid, când va fi mai lent, când va fi mai bine și când va fi mai rău. Așa că încearcă.

Problema de mutare

Există un singur „dar”: dacă te muți la Faceți clic pe Casă de la altceva, atunci de obicei ceva nu merge bine. Suntem obișnuiți cu unele practici și lucruri care funcționează în baza noastră de date preferată. De exemplu, oricine lucrează cu SQBazele de date L consideră obligatoriu următorul set de funcții:

• tranzacții;
• constrângeri;
• consistenta;
• indici;
• ACTUALIZARE/ȘTERGERE;
• NULL-uri;
• milisecunde;
• turnări de tip automat;
• îmbinări multiple;
• partiții arbitrare;
• instrumente de management al clusterelor.

Recrutarea este obligatorie, dar acum trei ani în Faceți clic pe Casă Niciuna dintre aceste funcții nu era disponibilă! Acum mai puțin de jumătate din ceea ce nu a fost implementat rămâne: tranzacții, constrângeri, Consistență, milisecunde și tip casting.

Și principalul lucru este că în Faceți clic pe Casă unele practici și abordări standard nu funcționează sau funcționează altfel decât suntem obișnuiți. Tot ce apare în Faceți clic pe Casă, corespunde "Mod ClickHouse", adică funcțiile diferă de alte baze de date. De exemplu:

• Indecșii nu sunt selectați, dar ignorați.
• ACTUALIZARE/ȘTERGERE nu sincron, ci asincron.
• Există mai multe alinări, dar nu există un planificator de interogări. Cum sunt apoi efectuate, în general, nu este foarte clar pentru oamenii din lumea bazelor de date.

ClickHouse Scripts

În 1960, un matematician american de origine maghiară EP Wigner a scris un articol"Eficacitatea nerezonabilă a matematicii în științele naturii” („Eficacitatea de neînțeles a matematicii în științele naturii”) că lumea din jurul nostru este din anumite motive bine descrisă de legile matematice. Matematica este o știință abstractă, iar legile fizice exprimate sub formă matematică nu sunt triviale și EP Wigner a subliniat că acest lucru este foarte ciudat.

Din punctul meu de vedere, Faceți clic pe Casă - aceeași ciudățenie. Pentru a reformula Wigner, putem spune așa: eficiența de neconceput este uluitoare Faceți clic pe Casă într-o mare varietate de aplicații analitice!

De exemplu, să luăm Depozit de date în timp real, în care datele sunt încărcate aproape continuu. Dorim să primim cereri de la acesta cu o a doua întârziere. Te rog - folosește-l Faceți clic pe Casă, pentru că acesta este scenariul pentru care a fost conceput. Faceți clic pe Casă exact așa este folosit nu numai pe web, ci și în marketing și analiză financiară, AdTech, precum și în Detectarea fraudein. ÎN Depozit de date în timp real se folosește o schemă structurată complexă precum „stea” sau „fulg de zăpadă”, multe tabele cu JOIN (uneori multiple), iar datele sunt de obicei stocate și modificate în unele sisteme.

Să luăm un alt scenariu - Seria de timp: monitorizarea dispozitivelor, rețelelor, statistici de utilizare, Internet of Things. Aici întâlnim evenimente destul de simple ordonate în timp. Faceți clic pe Casă nu a fost dezvoltat inițial pentru acest lucru, dar s-a dovedit a funcționa bine, motiv pentru care companiile mari folosesc Faceți clic pe Casă ca depozit pentru monitorizarea informațiilor. Pentru a explora dacă este potrivit Faceți clic pe Casă pentru seriile temporale, am făcut un etalon bazat pe abordare și rezultate InfluxDB и TimecaleDB - de specialitate serii temporale baze de date. S-a doveditCă Faceți clic pe Casă, chiar și fără optimizare pentru astfel de sarcini, câștigă pe un teren străin:

В serii temporale De obicei, se folosește un tabel îngust - mai multe coloane mici. O mulțime de date pot proveni din monitorizare - milioane de înregistrări pe secundă - și de obicei vin în rafale mici (în timp real streaming). Prin urmare, este necesar un script de inserare diferit, iar interogările în sine au propriile lor specificuri.

Managementul log. Colectarea jurnalelor într-o bază de date este de obicei proastă, dar Faceți clic pe Casă acest lucru se poate face cu câteva comentarii așa cum este descris mai sus. Multe companii folosesc Faceți clic pe Casă exact in acest scop. În acest caz, folosim o masă plată și largă în care stocăm bustenii întregi (de exemplu, în formularul JSON), sau tăiați în bucăți. Datele sunt de obicei încărcate în loturi mari (fișiere) și căutăm după un anumit câmp.

Pentru fiecare dintre aceste funcții se folosesc de obicei baze de date specializate. Faceți clic pe Casă se poate face totul și atât de bine încât îi depășește. Acum să aruncăm o privire mai atentă serii temporale scenariu și cum să „gătești” corect Faceți clic pe Casă pentru acest scenariu.

Seria temporală

În prezent acesta este scenariul principal pentru care Faceți clic pe Casă considerată soluția standard. Serii temporale este un set de evenimente ordonate în timp, reprezentând schimbări într-un anumit proces în timp. De exemplu, aceasta ar putea fi ritmul cardiac pe zi sau numărul de procese din sistem. Tot ceea ce dă timpului cu anumite dimensiuni este serii temporale:

Cele mai multe dintre aceste tipuri de evenimente provin din monitorizare. Aceasta poate fi nu numai monitorizarea web-ului, ci și a dispozitivelor reale: mașini, sisteme industriale, IoT, taxiuri de producție sau fără pilot, în portbagajul cărora deja pune Yandex Faceți clic pe Casă-Server.

De exemplu, există companii care colectează date de pe nave. La fiecare câteva secunde, senzorii de pe nava container trimit sute de măsurători diferite. Inginerii le studiază, construiesc modele și încearcă să înțeleagă cât de eficient este utilizat nava, deoarece o navă container nu ar trebui să fie inactivă nici măcar o secundă. Orice timp nefuncțional este o pierdere de bani, așa că este important să preziceți traseul, astfel încât opririle să fie minime.

În zilele noastre există o creștere a bazelor de date specializate care măsoară serii temporale. Pe net DB-Motoare Diferitele baze de date sunt oarecum clasificate și le puteți vizualiza după tip:

Tipul cu cea mai rapidă creștere este serii de timps. Bazele de date grafice sunt, de asemenea, în creștere, dar serii de timpau crescut mai rapid în ultimii ani. Reprezentanții tipici ai acestei familii de baze de date sunt InfluxDB, Prometeu, KDB, TimecaleDB (construit pe PostgreSQL), soluții din Amazon. Faceți clic pe Casă poate fi folosit și aici și este folosit. Permiteți-mi să vă dau câteva exemple publice.

Unul dintre pionierii este compania Cloudflare (CDN-furnizor). Ei își monitorizează CDN prin Faceți clic pe Casă (DNS-cereri, HTTP-interogări) cu o încărcare uriașă - 6 milioane de evenimente pe secundă. Totul trece prin Kafka, merge la Faceți clic pe Casă, care oferă posibilitatea de a vedea tablouri de bord ale evenimentelor din sistem în timp real.

Comcast - unul dintre liderii în telecomunicații din SUA: Internet, televiziune digitală, telefonie. Au creat un sistem de control similar CDN în cadrul Open Source proiect Apache Traffic Control pentru a lucra cu datele tale uriașe. Faceți clic pe Casă folosit ca backend pentru analiză.

percona incorporat Faceți clic pe Casă în interiorul tău PMMpentru a stoca monitorizarea diverselor MySQL.

Cerințe specifice

Bazele de date cu serii temporale au propriile lor cerințe specifice.

• Inserare rapidă de la mulți agenți. Trebuie să inserăm foarte repede date din multe fluxuri. Faceți clic pe Casă Face acest lucru bine, deoarece toate inserțiile sale sunt neblocante. Orice insera este un fișier nou pe disc, iar inserțiile mici pot fi stocate într-un fel sau altul. ÎN Faceți clic pe Casă Este mai bine să inserați datele în loturi mari decât o linie la un moment dat.
• Schema flexibila. În serii temporale de obicei, nu cunoaștem complet structura datelor. Este posibil să construiți un sistem de monitorizare pentru o anumită aplicație, dar apoi este dificil să îl utilizați pentru o altă aplicație. Acest lucru necesită o schemă mai flexibilă. Faceți clic pe Casă, vă permite să faceți acest lucru, chiar dacă este o bază puternic tastată.
• Stocarea eficientă și uitarea datelor. De obicei în serii temporale o cantitate imensă de date, așa că trebuie stocate cât mai eficient posibil. De exemplu, la InfluxDB compresia bună este principala sa caracteristică. Dar, pe lângă stocare, trebuie să poți „uita” datele vechi și să faci ceva prelevare de probe — numărarea automată a agregatelor.
• Interogări rapide asupra datelor agregate. Uneori este interesant să privim ultimele 5 minute cu o precizie de milisecunde, dar pe datele lunare este posibil să nu fie necesară granularitatea minutelor sau secundelor - statisticile generale sunt suficiente. Suportul de acest fel este necesar, altfel o solicitare de 3 luni va dura foarte mult pentru a se finaliza chiar și în Faceți clic pe Casă.
• Cereri precum "ultimul punct, de la». Acestea sunt tipice pentru serii temporale interogări: uitați-vă la ultima măsurătoare sau starea sistemului la un moment dat t. Acestea nu sunt interogări foarte plăcute pentru o bază de date, dar trebuie și să le poți efectua.
• Serii cronologice „Lipirea”.. Serii temporale este o serie temporală. Dacă există două serii temporale, acestea trebuie adesea conectate și corelate. Nu este convenabil să faci acest lucru pe toate bazele de date, mai ales cu seriile temporale nealiniate: iată câteva momente de timp, există altele. Puteți considera medie, dar dintr-o dată va mai fi o gaură acolo, așa că nu este clar.

Să vedem cum sunt îndeplinite aceste cerințe în Faceți clic pe Casă.

Schema

В Faceți clic pe Casă schema pentru serii temporale poate fi realizată în moduri diferite, în funcție de gradul de regularitate al datelor. Este posibil să construim un sistem pe date obișnuite atunci când cunoaștem toate valorile în avans. De exemplu, am făcut asta Cloudflare cu monitorizare CDN este un sistem bine optimizat. Puteți construi un sistem mai general care monitorizează întreaga infrastructură și diverse servicii. În cazul datelor neregulate, nu știm dinainte ce monitorizăm - și acesta este probabil cel mai frecvent caz.

Date regulate. Coloane. Schema este simplă - coloane cu tipurile necesare:

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

Acesta este un tabel obișnuit care monitorizează un fel de activitate de încărcare a sistemului (utilizator, sistem, inactiv, frumos). Simplu și convenabil, dar nu flexibil. Dacă vrem o schemă mai flexibilă, atunci putem folosi matrice.

Date neregulate. Matrice:

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

Structura Cuibărit sunt două matrice: metrici.nume и metrici.valoare. Aici puteți stoca astfel de date de monitorizare arbitrare ca o serie de nume și o serie de măsurători pentru fiecare eveniment. Pentru o optimizare suplimentară, în loc de o astfel de structură, puteți face mai multe. De exemplu, unul pentru pluti-valoare, alta - pentru int- adică pentru că int Vreau să depozitez mai eficient.

Dar o astfel de structură este mai greu de accesat. Va trebui să utilizați o construcție specială, folosind funcții speciale pentru a scoate mai întâi valorile indexului și apoi ale matricei:

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

Dar încă funcționează destul de repede. O altă modalitate de a stoca date neregulate este prin rând.

Date neregulate. Siruri de caractere. În această metodă tradițională, fără matrice, numele și valorile sunt stocate simultan. Dacă 5 de măsurători provin de la un dispozitiv simultan, în baza de date sunt generate 000 de rânduri:

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

Faceți clic pe Casă face față acestui lucru - are extensii speciale Faceți clic pe Casă SQL. De exemplu maxDacă — o funcție specială care calculează maximul printr-o metrică atunci când este îndeplinită o anumită condiție. Puteți scrie mai multe astfel de expresii într-o singură solicitare și puteți calcula imediat valoarea pentru mai multe valori.

Să comparăm trei abordări:

Detalii

Aici am adăugat „Dimensiunea datelor discului” pentru un set de date de testare. În cazul coloanelor, avem cea mai mică dimensiune a datelor: compresie maximă, viteză maximă de interogare, dar plătim fiind nevoiți să înregistrăm totul deodată.

În cazul matricelor, totul este puțin mai rău. Datele sunt încă bine comprimate și un model neregulat poate fi stocat. Dar Faceți clic pe Casă - o bază de date în coloană, iar când începem să stocăm totul într-o matrice, se transformă într-o bază de rând și plătim pentru flexibilitate cu eficiență. Pentru orice operațiune, va trebui să citiți întreaga matrice în memorie, apoi să găsiți elementul dorit în ea - și dacă matricea crește, atunci viteza se degradează.

Într-una dintre companiile care utilizează această abordare (de exemplu, Uber), matricele sunt tăiate în bucăți de 128 de elemente. Datele de la câteva mii de metrici cu un volum de 200 TB de date/zi sunt stocate nu într-o singură matrice, ci în 10 sau 30 de matrice cu o logică specială de stocare.

Cea mai simplă abordare este cu șiruri. Dar datele sunt slab comprimate, dimensiunea tabelului este mare și chiar și atunci când interogările se bazează pe mai multe valori, ClickHouse nu funcționează optim.

Schema hibridă

Să presupunem că am ales un circuit matrice. Dar dacă știm că majoritatea tablourilor noastre de bord afișează numai valori de utilizator și de sistem, putem materializa în plus aceste valori în coloane dintr-o matrice la nivel de tabel în acest fel:

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

La introducere Faceți clic pe Casă le va număra automat. Astfel poți combina afacerile cu plăcerea: schema este flexibilă și generală, dar am scos coloanele cele mai des folosite. Rețineți că acest lucru nu a necesitat schimbarea inserției și ETLcare continuă să insereze tablouri în tabel. Tocmai am făcut-o ALTER TABLE, a adăugat câteva difuzoare și am obținut o schemă hibridă și mai rapidă pe care o puteți începe imediat.

Codec-uri și compresie

Pentru serii temporale Contează cât de bine împachetați datele deoarece cantitatea de informații poate fi foarte mare. ÎN Faceți clic pe Casă Există un set de instrumente pentru a obține un efect de compresie de 1:10, 1:20 și, uneori, mai mult. Aceasta înseamnă că 1 TB de date despachetate de pe disc ocupă 50-100 GB. Dimensiunea mai mică este bună, datele pot fi citite și procesate mai rapid.

Pentru a atinge un nivel ridicat de compresie, Faceți clic pe Casă acceptă următoarele codecuri:

Exemplu de tabel:

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

Aici definim codecul DoubleDelta într-un caz, în al doilea - Gorilă, și cu siguranță vom adăuga mai multe LZ4 comprimare. Ca rezultat, dimensiunea datelor de pe disc este mult redusă:

Aceasta arată cât spațiu ocupă aceleași date, dar folosind codecuri și compresii diferite:

• într-un fișier GZIP de pe disc;
• în ClickHouse fără codecuri, dar cu compresie ZSTD;
• în ClickHouse cu codecuri și compresie LZ4 și ZSTD.

Se poate observa că tabelele cu codecuri ocupă mult mai puțin spațiu.

Dimensiunea contează

Nu mai puțin important выбрать tip de date corect:

În toate exemplele de mai sus le-am folosit Plutitor64. Dar dacă alegem Plutitor32, atunci ar fi chiar mai bine. Acest lucru a fost bine demonstrat de băieții de la Perkona în articolul de mai sus. Este important să folosiți cel mai compact tip care este potrivit pentru sarcină: chiar mai puțin pentru dimensiunea discului decât pentru viteza de interogare. Faceți clic pe Casă foarte sensibil la asta.

Dacă poți folosi int32 în loc de int64, atunci așteptați-vă la o creștere de aproape două ori a performanței. Datele ocupă mai puțină memorie și toată „aritmetica” funcționează mult mai rapid. Faceți clic pe Casă pe plan intern este un sistem foarte strict tipizat, folosește la maximum toate posibilitățile pe care le oferă sistemele moderne.

Agregarea și Vizualizări materializate

Vizualizările agregate și materializate vă permit să creați agregate pentru diferite ocazii:

De exemplu, este posibil să aveți date sursă neagregate și le puteți atașa diferite vederi materializate cu însumare automată printr-un motor special SummingMergeTree (SMT). SMT este o structură specială de date de agregare care calculează agregatele automat. Datele brute sunt inserate în baza de date, sunt agregate automat, iar tablourile de bord pot fi folosite imediat pe aceasta.

TTL - „uitați” datele vechi

Cum să „uiți” datele care nu mai sunt necesare? Faceți clic pe Casă știe cum să facă asta. Când creați tabele, puteți specifica TTL expresii: de exemplu, că stocăm date minute pentru o zi, date zilnice timp de 30 de zile și nu atingem niciodată date săptămânale sau lunare:

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

Multi-nivel - împărțiți datele pe discuri

Luând această idee mai departe, datele pot fi stocate în Faceți clic pe Casă în locuri diferite. Să presupunem că vrem să stocăm datele fierbinți pentru ultima săptămână pe un local foarte rapid SSD, și punem mai multe date istorice în alt loc. ÎN Faceți clic pe Casă acest lucru este acum posibil:

Puteți configura o politică de stocare (politica de stocare) Asa de Faceți clic pe Casă va transfera automat datele la atingerea anumitor condiții într-o altă stocare.

Dar asta nu este tot. La nivelul unui anumit tabel, puteți defini reguli pentru exact momentul în care datele intră în depozitare frigorifică. De exemplu, datele sunt stocate pe un disc foarte rapid timp de 7 zile, iar tot ce este mai vechi este transferat pe unul lent. Acest lucru este bun pentru că vă permite să mențineți sistemul la performanță maximă, controlând în același timp costurile și fără a pierde bani pe date reci:

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

Oportunități unice Faceți clic pe Casă

În aproape orice Faceți clic pe Casă Există astfel de „relege”, dar sunt compensate de exclusivitate - ceva care nu se află în alte baze de date. De exemplu, iată câteva dintre caracteristicile unice Faceți clic pe Casă:

• matrice. În Faceți clic pe Casă suport foarte bun pentru matrice, precum și capacitatea de a efectua calcule complexe pe ele.
• Agregarea structurilor de date. Aceasta este una dintre „trăsăturile ucigașe” Faceți clic pe Casă. În ciuda faptului că băieții de la Yandex spun că nu vrem să cumulăm date, totul este agregat în Faceți clic pe Casă, pentru că este rapid și convenabil.
• Vederi materializate. Împreună cu structurile de date agregate, vizualizările materializate vă permit să faceți convenabil în timp real agregare.
• ClickHouse SQL. Aceasta este o extensie de limbă SQL cu unele caracteristici suplimentare și exclusive care sunt disponibile numai în Faceți clic pe Casă. Anterior, era ca o expansiune pe de o parte și un dezavantaj pe de altă parte. Acum aproape toate dezavantajele în comparație cu SQL 92 l-am eliminat, acum este doar o extensie.
• Lambda-expresii. Mai sunt în vreo bază de date?
• ML-a sustine. Acesta este disponibil în diferite baze de date, unele sunt mai bune, altele sunt mai rele.
• sursa deschisa. Ne putem extinde Faceți clic pe Casă împreună. Acum in Faceți clic pe Casă aproximativ 500 de colaboratori, iar acest număr este în continuă creștere.

Interogări dificile

В Faceți clic pe Casă există multe moduri diferite de a face același lucru. De exemplu, puteți returna ultima valoare dintr-un tabel în trei moduri diferite pentru Procesor (există și un al patrulea, dar este și mai exotic).

Prima arată cât de convenabil este să faci în Faceți clic pe Casă întrebări când doriți să verificați asta tuplu conținute în subinterogare. Acesta este un lucru pe care personal mi-a lipsit cu adevărat în alte baze de date. Dacă vreau să compar ceva cu o subinterogare, atunci în alte baze de date doar un scalar poate fi comparat cu el, dar pentru mai multe coloane trebuie să scriu JOIN. În Faceți clic pe Casă poți folosi tuplu:

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

A doua metodă face același lucru, dar folosește o funcție de agregare argMax:

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

В Faceți clic pe Casă există câteva zeci de funcții agregate, iar dacă utilizați combinatoare, atunci conform legilor combinatoriei veți obține aproximativ o mie dintre ele. ArgMax - una dintre funcțiile care calculează valoarea maximă: cererea returnează valoarea utilizare_utilizator, la care se atinge valoarea maximă creat la:

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 — „lipirea” rândurilor cu timpi diferiți. Aceasta este o caracteristică unică pentru bazele de date, care este disponibilă numai în kdb+. Dacă există două serii temporale cu timpi diferiți, ASOF JOIN vă permite să le mutați și să le îmbinați într-o singură solicitare. Pentru fiecare valoare dintr-o serie temporală, se găsește cea mai apropiată valoare din cealaltă și sunt returnate pe aceeași linie:

Funcții analitice

În standard SQL-2003 poti scrie asa:

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;

В Faceți clic pe Casă Nu poți face asta - nu acceptă standardul SQL-2003 și probabil nu o va face niciodată. În schimb, în Faceți clic pe Casă Se obișnuiește să scrie așa:

Am promis lambda - iată-le!

Acesta este un analog al interogării analitice din standard SQL-2003: el numără diferența dintre cele două marca temporală, durată, număr ordinal - tot ceea ce considerăm de obicei funcții analitice. ÎN Faceți clic pe Casă Le numărăm prin matrice: mai întâi restrângem datele într-o matrice, după aceea facem tot ce ne dorim pe matrice și apoi le extindem înapoi. Nu este foarte convenabil, necesită un minim de dragoste pentru programarea funcțională, dar este foarte flexibil.

Caracteristici speciale

În plus, în Faceți clic pe Casă multe funcții specializate. De exemplu, cum să determinați câte sesiuni au loc simultan? O sarcină tipică de monitorizare este determinarea sarcinii maxime cu o singură solicitare. ÎN Faceți clic pe Casă Există o funcție specială în acest scop:

În general, ClickHouse are funcții speciale pentru mai multe scopuri:

• runningDifference, runningAcumulate, vecin;
• sumMap(cheie, valoare);
• timeSeriesGroupSum(uid, timestamp, value);
• timeSeriesGroupRateSum(uid, timestamp, value);
• skewPop, skewSamp, kurtPop, kurtSamp;
• CU Umplutură / CU LEVATE;
• simplăLinearRegression, stochasticLinearRegression.

Aceasta nu este o listă completă de funcții, sunt 500-600 în total. Sugestie: toate funcțiile în Faceți clic pe Casă este în tabelul de sistem (nu toate sunt documentate, dar toate sunt interesante):

select * from system.functions order by name

Faceți clic pe Casă stochează o mulțime de informații despre sine, inclusiv tabele de jurnal, query_log, jurnal de urmărire, jurnal de operațiuni cu blocuri de date (jurnal_parte), jurnalul de metrici și jurnalul de sistem, pe care de obicei le scrie pe disc. Valorile jurnalului sunt serii temporale в Faceți clic pe Casă de fapt Faceți clic pe Casă: Baza de date în sine poate juca un rol serii temporale baze de date, „devorându-se” astfel.

Acesta este, de asemenea, un lucru unic - deoarece facem o treabă bună pentru serii temporale, de ce nu putem stoca tot ce avem nevoie în noi înșine? Nu avem nevoie Prometeu, păstrăm totul pentru noi. Conectat grafana și ne monitorizăm pe noi înșine. Cu toate acestea, dacă Faceți clic pe Casă cade, nu vom vedea de ce, așa că de obicei nu fac asta.

Ciorchine mare sau multe mici Faceți clic pe Casă

Ce este mai bine - un grup mare sau mai multe ClickHouses mici? Abordare tradițională a DWH este un cluster mare în care sunt alocate circuite pentru fiecare aplicație. Am venit la administratorul bazei de date - dă-ne o diagramă și ne-au dat una:

В Faceți clic pe Casă o poti face altfel. Puteți face ca fiecare aplicație să fie proprie Faceți clic pe Casă:

Nu mai avem nevoie de cel mare monstruos DWH și admini insolubili. Putem oferi fiecărei aplicații propriile aplicații Faceți clic pe Casă, iar dezvoltatorul o poate face singur, din moment ce Faceți clic pe Casă foarte usor de instalat si nu necesita administrare complexa:

Dar dacă avem multe Faceți clic pe Casă, și trebuie să îl instalați des, apoi doriți să automatizați acest proces. Pentru aceasta putem, de exemplu, să folosim Kubernetes и clickhouse-operator. ÎN Kubernetes ClickHouse îl poți pune „on-click”: pot face clic pe un buton, pot rula manifestul și baza de date este gata. Pot crea imediat o diagramă, pot începe să încarc valori acolo și în 5 minute am un tablou de bord gata grafana. Este atât de simplu!

Rezultatul?

Astfel, Faceți clic pe Casă - aceasta este:

• repede. Toată lumea știe asta.
• doar. Puțin controversat, dar cred că este greu la antrenament, ușor în luptă. Dacă înțelegi cum Faceți clic pe Casă funcționează, atunci totul este foarte simplu.
• Universal. Este potrivit pentru diferite scenarii: DWH, serii temporale, stocare jurnal. Dar nu este OLTP baza de date, așa că nu încercați să faceți inserări și citiri scurte acolo.
• Interesant. Probabil cel cu care lucrează Faceți clic pe Casă, a trăit multe momente interesante în sens bun și rău. De exemplu, a apărut o nouă ediție, totul a încetat să funcționeze. Sau când te-ai luptat cu o sarcină timp de două zile, dar după ce ai pus o întrebare în chat-ul Telegram, sarcina a fost rezolvată în două minute. Sau ca la conferința la raportul lui Lesha Milovidov, o captură de ecran de la Faceți clic pe Casă a întrerupt emisiunea HighLoad ++. Acest gen de lucruri se întâmplă tot timpul și ne îngreunează viața. Faceți clic pe Casă luminos si interesant!

Puteți urmări prezentarea aici.

Întâlnirea mult așteptată a dezvoltatorilor de sisteme de mare sarcină la HighLoad ++ va avea loc pe 9 și 10 noiembrie la Skolkovo. În cele din urmă, aceasta va fi o conferință offline (deși cu toate măsurile de precauție în vigoare), deoarece energia HighLoad++ nu poate fi ambalată online.

Pentru conferință, găsim și vă arătăm cazuri despre capacitățile maxime ale tehnologiei: HighLoad++ a fost, este și va fi singurul loc unde puteți afla în două zile cum funcționează Facebook, Yandex, VKontakte, Google și Amazon.

Ținând întâlnirile noastre fără întrerupere din 2007, anul acesta ne vom întâlni pentru a 14-a oară. În acest timp, conferința a crescut de 10 ori; anul trecut, evenimentul cheie din industrie a reunit 3339 de participanți, 165 de vorbitori, rapoarte și întâlniri, iar 16 piese au fost difuzate simultan.
Anul trecut au fost 20 de autobuze, 5280 de litri de ceai și cafea, 1650 de litri de băuturi din fructe și 10200 de sticle de apă. Și încă 2640 de kilograme de mâncare, 16 de farfurii și 000 de căni. Apropo, cu banii strânși din hârtie reciclată, am plantat 25 de puieți de stejar :)

Puteți cumpăra bilete aici, primiți știri despre conferință - aiciși vorbește pe toate rețelele sociale: Telegramă, Facebook, VKontakte и Twitter.

Sursa: www.habr.com