Deoarece ClickHouse este un sistem specializat, atunci când îl utilizați este important să țineți cont de caracteristicile arhitecturii sale. În acest raport, Alexey va vorbi despre exemple de greșeli comune atunci când utilizați ClickHouse, care pot duce la o muncă ineficientă. Exemplele practice vor arăta cum alegerea uneia sau a alteia scheme de procesare a datelor poate schimba performanța în ordine de mărime.
Salutare tuturor! Numele meu este Alexey, fac ClickHouse.
În primul rând, mă grăbesc să vă fac pe plac imediat, astăzi nu vă voi spune ce este ClickHouse. Sincer să fiu, m-am săturat de asta. De fiecare dată când vă spun ce este. Și probabil toată lumea știe deja.
În schimb, îți voi spune ce posibile greșeli există, adică cum poți folosi ClickHouse incorect. De fapt, nu trebuie să vă fie teamă, deoarece dezvoltăm ClickHouse ca un sistem simplu, convenabil și funcționează din nou. L-am instalat, fara probleme.
Dar tot trebuie să ții cont de faptul că acest sistem este specializat și poți întâlni cu ușurință un caz de utilizare neobișnuit care va scoate acest sistem din zona de confort.
Deci, ce fel de greblă există? De cele mai multe ori voi vorbi despre lucruri evidente. Totul este evident pentru toată lumea, toată lumea înțelege totul și se poate bucura că sunt atât de deștepți, iar cei care nu înțeleg vor învăța ceva nou.
Primul și cel mai simplu exemplu, care, din păcate, apare adesea, este un număr mare de inserții cu loturi mici, adică un număr mare de inserții mici.
Dacă luăm în considerare modul în care ClickHouse efectuează inserarea, atunci puteți trimite cel puțin un terabyte de date într-o singură solicitare. Nu este o problemă.
Și să vedem care ar fi performanța tipică. De exemplu, avem un tabel din datele Yandex.Metrica. Hituri. 105 unele coloane. 700 de octeți necomprimați. Și vom introduce într-un mod bun în loturi de un milion de rânduri.
Inserăm MergeTree în tabel, rezultă o jumătate de milion de rânduri pe secundă. Grozav. Într-un tabel replicat, acesta va fi puțin mai mic, aproximativ 400 de rânduri pe secundă.
Și dacă activați inserarea cvorumului, obțineți un pic mai puțin, dar încă performanță decentă, 250 de termeni pe secundă. Inserarea cvorumului este o caracteristică nedocumentată în ClickHouse*.
* din 2020, .
Ce se întâmplă dacă faci ceva rău? Inserăm un rând în tabelul MergeTree și obținem 59 de rânduri pe secundă. Este de 10 de ori mai lent. În ReplicatedMergeTree – 000 rânduri pe secundă. Și dacă cvorumul este activat, atunci rezultă 6 linii pe secundă. După părerea mea, acesta este un fel de prostie absolută. Cum poți încetini așa? Chiar am scris pe tricoul meu că ClickHouse nu ar trebui să încetinească. Dar, cu toate acestea, se întâmplă uneori.
De fapt, acesta este deficiența noastră. Am fi putut face totul să funcționeze bine, dar nu am făcut-o. Și nu am făcut-o pentru că scenariul nostru nu o necesita. Aveam deja măcelari. Tocmai am primit loturi la intrarea noastră și nicio problemă. Îl introducem și totul merge bine. Dar, desigur, tot felul de scenarii sunt posibile. De exemplu, când aveți o grămadă de servere pe care sunt generate date. Și nu inserează date la fel de des, dar se termină cu inserări frecvente. Și trebuie să evităm cumva acest lucru.
Din punct de vedere tehnic, ideea este că atunci când faci o inserare în ClickHouse, datele nu ajung în niciun memorabil. Nici măcar nu avem o structură de jurnal real MergeTree, ci doar un MergeTree, deoarece nu există nici un jurnal, nici un memTable. Pur și simplu scriem imediat datele în sistemul de fișiere, deja aranjate în coloane. Și dacă aveți 100 de coloane, atunci mai mult de 200 de fișiere vor trebui scrise într-un director separat. Toate acestea sunt foarte greoaie.
Și apare întrebarea: „Cum se face corect?” Dacă situația este de așa natură încât trebuie să înregistrați cumva date în ClickHouse.
Metoda 1. Acesta este cel mai simplu mod. Utilizați un fel de coadă distribuită. De exemplu, Kafka. Pur și simplu extrageți date de la Kafka și le grupați o dată pe secundă. Și totul va fi bine, înregistrați, totul funcționează bine.
Dezavantajele sunt că Kafka este un alt sistem voluminos distribuit. Înțeleg și dacă îl aveți deja pe Kafka în compania dumneavoastră. E bine, e convenabil. Dar dacă nu există, atunci ar trebui să te gândești de trei ori înainte de a trage încă un alt sistem distribuit în proiectul tău. Și așa că merită să luați în considerare alternative.
Metoda 2. Aceasta este o alternativă de școală veche și în același timp foarte simplă. Aveți un fel de server care vă generează jurnalele. Și doar scrie jurnalele dvs. într-un fișier. Și o dată pe secundă, de exemplu, redenumim acest fișier și smulgem unul nou. Și un script separat, fie prin cron, fie prin intermediul unui daemon, ia cel mai vechi fișier și îl scrie în ClickHouse. Dacă înregistrați jurnalele o dată pe secundă, atunci totul va fi bine.
Dar dezavantajul acestei metode este că dacă serverul tău pe care sunt generate jurnalele dispare undeva, atunci și datele vor dispărea.
Metoda 3. Există o altă metodă interesantă, care nu necesită deloc fișiere temporare. De exemplu, aveți un fel de spinner de publicitate sau un alt demon interesant care generează date. Și poți acumula o grămadă de date direct în RAM, în buffer. Și când a trecut suficient timp, puneți acest buffer deoparte, creați unul nou și, într-un fir separat, introduceți ceea ce a acumulat deja în ClickHouse.
Pe de altă parte, datele dispar și cu kill -9. Dacă serverul dvs. se blochează, veți pierde aceste date. Și o altă problemă este că, dacă nu ați putut scrie în baza de date, atunci datele dvs. se vor acumula în RAM. Și fie RAM-ul se va epuiza, fie pur și simplu veți pierde date.
Metoda 4. O altă metodă interesantă. Aveți un fel de proces de server. Și poate trimite date către ClickHouse imediat, dar o face într-o singură conexiune. De exemplu, am trimis o cerere http cu codificare de transfer: fragmentată cu inserare. Și generează bucăți nu prea rar, puteți trimite fiecare linie, deși va exista o suprasarcină pentru încadrarea acestor date.
Cu toate acestea, în acest caz datele vor fi trimise imediat către ClickHouse. Și ClickHouse le va tampona singur.
Dar apar și probleme. Acum veți pierde date, inclusiv când procesul dvs. este oprit și dacă procesul ClickHouse este oprit, deoarece va fi o inserare incompletă. Și în ClickHouse inserțiile sunt atomice până la un anumit prag specificat în dimensiunea rândurilor. În principiu, acesta este un mod interesant. Poate fi folosit și.
Metoda 5. Iată o altă metodă interesantă. Acesta este un fel de server dezvoltat de comunitate pentru lotizarea datelor. Eu nu m-am uitat la el, așa că nu pot garanta nimic. Cu toate acestea, nu sunt oferite garanții pentru ClickHouse în sine. Acesta este, de asemenea, open source, dar, pe de altă parte, s-ar putea să fiți obișnuit cu un standard de calitate pe care încercăm să-l oferim. Dar pentru acest lucru - nu știu, mergi la GitHub, uită-te la cod. Poate au scris ceva normal.
* din 2020, ar trebui, de asemenea, adăugate în considerare .
Metoda 6. O altă metodă este utilizarea tabelelor tampon. Avantajul acestei metode este că este foarte ușor să începeți să utilizați. Creați un tabel tampon și introduceți-l în el.
Dezavantajul este că problema nu este complet rezolvată. Dacă, într-o rată precum MergeTree, trebuie să grupați datele cu un lot pe secundă, atunci într-o rată într-un tabel tampon, trebuie să grupați cel puțin până la câteva mii pe secundă. Dacă este mai mult de 10 pe secundă, tot va fi rău. Și dacă îl introduceți în loturi, atunci ați văzut că se dovedește a fi o sută de mii de linii pe secundă. Și acest lucru este deja pe date destul de grele.
Și, de asemenea, tabelele buffer nu au un jurnal. Și dacă există ceva în neregulă cu serverul dvs., atunci datele se vor pierde.
Și ca bonus, recent am avut ocazia la ClickHouse de a prelua date de la Kafka. Există un motor de masă - Kafka. Pur și simplu creezi. Și puteți agăța pe el reprezentări materializate. În acest caz, va extrage ea însăși datele din Kafka și le va insera în tabelele de care aveți nevoie.
Și ceea ce este deosebit de plăcut la această oportunitate este că nu noi am făcut-o. Aceasta este o caracteristică comunitară. Și când spun „funcție comunitară”, mă refer la asta fără nici un dispreț. Am citit codul, am făcut o revizuire, ar trebui să funcționeze bine.
* din 2020, a apărut un suport similar pentru .
Ce altceva ar putea fi incomod sau neașteptat la inserarea datelor? Dacă faceți o solicitare de inserare a valorilor și scrieți câteva expresii calculate în valori. De exemplu, now() este, de asemenea, o expresie calculată. Și în acest caz, ClickHouse este forțat să lanseze interpretul acestor expresii pe fiecare linie, iar performanța va scădea cu ordine de mărime. Este mai bine să evitați acest lucru.
* momentan, problema este complet rezolvată, nu mai există nicio regresie de performanță la utilizarea expresiilor în VALORI.
Un alt exemplu este atunci când pot apărea unele probleme atunci când aveți date pe un lot care aparține unui grup de partiții. În mod implicit, partițiile ClickHouse sunt pe lună. Și dacă inserați un lot de un milion de rânduri și există date de câțiva ani, atunci veți avea câteva zeci de partiții acolo. Și acest lucru este echivalent cu faptul că vor exista loturi de câteva zeci de ori mai mici, deoarece în interior sunt întotdeauna mai întâi împărțite în partiții.
* Recent, în modul experimental, ClickHouse a adăugat suport pentru formatul compact de bucăți și bucăți în RAM cu jurnal de scriere anticipată, ceea ce rezolvă aproape complet problema.
Acum să ne uităm la al doilea tip de problemă - tastarea datelor.
Tastarea datelor poate fi strictă sau șir. String este atunci când tocmai l-ați luat și ați declarat că toate câmpurile dvs. sunt de tip șir. Asta e nasol. Nu este nevoie să faci asta.
Să ne dăm seama cum să o facem corect în acele cazuri în care vrei să spui că avem un câmp, un șir și lăsăm ClickHouse să-și dea seama singur, și nu mă voi deranja. Dar tot merită să faci niște efort.
De exemplu, avem o adresă IP. Într-un caz, l-am salvat ca șir. De exemplu, 192.168.1.1. Și într-un alt caz, va fi un număr de tip UInt32*. 32 de biți sunt suficienți pentru o adresă IPv4.
În primul rând, destul de ciudat, datele vor fi comprimate aproximativ în mod egal. Va fi o diferență, desigur, dar nu atât de mare. Deci nu există probleme speciale cu I/O pe disc.
Dar există o diferență serioasă în timpul procesorului și timpul de execuție a interogărilor.
Să numărăm numărul de adrese IP unice dacă acestea sunt stocate ca numere. Asta înseamnă 137 de milioane de linii pe secundă. Dacă același lucru este sub formă de șiruri, atunci 37 de milioane de linii pe secundă. Nu știu de ce s-a întâmplat această coincidență. Am îndeplinit chiar eu aceste solicitări. Dar totusi de vreo 4 ori mai lent.
Și dacă calculezi diferența de spațiu pe disc, atunci există și o diferență. Iar diferența este de aproximativ un sfert, pentru că există destul de multe adrese IP unice. Și dacă ar exista linii cu un număr mic de semnificații diferite, atunci acestea ar fi ușor comprimate conform dicționarului în aproximativ același volum.
Iar diferența de timp de patru ori nu se află pe drum. Poate că nu-ți pasă, desigur, dar când văd o asemenea diferență, mă întristează.
Să ne uităm la diferite cazuri.
1. Un caz când aveți câteva valori unice diferite. În acest caz, folosim o practică simplă pe care probabil o cunoașteți și pe care o puteți folosi pentru orice SGBD. Toate acestea au sens nu numai pentru ClickHouse. Doar scrieți identificatori numerici în baza de date. Și puteți converti în șiruri și înapoi pe partea laterală a aplicației dvs.
De exemplu, aveți o regiune. Și încerci să-l salvezi ca șir. Și acolo va fi scris: Moscova și Regiunea Moscovei. Și când văd că scrie „Moscova”, nu este nimic, dar când este Moscova, devine cumva complet trist. Acesta este câți octeți.
În schimb, notăm pur și simplu numărul Ulnt32 și 250. Avem 250 în Yandex, dar al tău poate fi diferit. Pentru orice eventualitate, voi spune că ClickHouse are o capacitate încorporată de a lucra cu o bază geografică. Scrieți pur și simplu un director cu regiuni, inclusiv unul ierarhic, adică vor fi Moscova, Regiunea Moscovei și tot ce aveți nevoie. Și puteți converti la nivel de solicitare.
A doua opțiune este aproximativ aceeași, dar cu suport în interiorul ClickHouse. Acesta este tipul de date Enum. Pur și simplu scrieți toate valorile de care aveți nevoie în Enum. De exemplu, tipul de dispozitiv și scrieți acolo: desktop, mobil, tabletă, televizor. Există 4 opțiuni în total.
Dezavantajul este că trebuie să-l schimbi periodic. Doar o opțiune adăugată. Să modificăm masa. De fapt, modificarea tabelului în ClickHouse este gratuită. Mai ales gratuit pentru Enum, deoarece datele de pe disc nu se modifică. Dar, cu toate acestea, alter dobândește o blocare* pe masă și trebuie să aștepte până când toate selectările sunt executate. Și numai după ce această modificare va fi executată, adică mai există unele inconveniente.
* în cele mai recente versiuni de ClickHouse, ALTER este făcut complet neblocant.
O altă opțiune destul de unică pentru ClickHouse este conectarea dicționarelor externe. Puteți scrie numere în ClickHouse și puteți păstra directoarele în orice sistem convenabil pentru dvs. De exemplu, puteți utiliza: MySQL, Mongo, Postgres. Puteți chiar să vă creați propriul microserviciu care va trimite aceste date prin http. Și la nivelul ClickHouse, scrieți o funcție care va converti aceste date din numere în șiruri.
Aceasta este o modalitate specializată, dar foarte eficientă, de a efectua o îmbinare pe o masă externă. Și există două opțiuni. Într-o variantă de realizare, aceste date vor fi complet stocate în cache, complet prezente în RAM și actualizate cu o anumită frecvență. Și într-o altă opțiune, dacă aceste date nu se potrivesc în memoria RAM, atunci le puteți stoca parțial în cache.
Iată un exemplu. Există Yandex.Direct. Și există o companie de publicitate și bannere. Probabil că există aproximativ zeci de milioane de companii de publicitate. Și se potrivesc aproximativ în RAM. Și există miliarde de bannere, nu se potrivesc. Și folosim un dicționar cache din MySQL.
Singura problemă este că dicționarul din cache va funcționa bine dacă rata de accesare este aproape de 100%. Dacă este mai mic, atunci când procesați interogări pentru fiecare lot de date, va trebui să luați cheile lipsă și să luați datele de la MySQL. Despre ClickHouse, încă pot garanta că - da, nu încetinește, nu voi vorbi despre alte sisteme.
Și ca bonus, dicționarele sunt o modalitate foarte ușoară de a actualiza retroactiv datele în ClickHouse. Adică aveai un raport despre companiile de publicitate, utilizatorul a schimbat pur și simplu compania de publicitate și în toate datele vechi, în toate rapoartele, s-au schimbat și aceste date. Dacă scrieți rânduri direct în tabel, va fi imposibil să le actualizați.
O altă modalitate când nu știi de unde să obții identificatorii pentru șirurile tale. poți pur și simplu să-l hash. Mai mult decât atât, cea mai simplă opțiune este să luați un hash pe 64 de biți.
Singura problemă este că, dacă hash-ul este pe 64 de biți, atunci aproape sigur veți avea coliziuni. Pentru că dacă există un miliard de linii acolo, atunci probabilitatea devine deja vizibilă.
Și n-ar fi foarte bine să ștergeți în acest fel numele companiilor de publicitate. Dacă campaniile publicitare ale diferitelor companii sunt amestecate, atunci va fi ceva de neînțeles.
Și există un truc simplu. Adevărat, nici nu este foarte potrivit pentru date serioase, dar dacă ceva nu este foarte serios, atunci adăugați identificatorul clientului la cheia dicționarului. Și atunci veți avea coliziuni, dar numai în cadrul unui singur client. Și folosim această metodă pentru hărțile de link în Yandex.Metrica. Avem URL-uri acolo, stocăm hashuri. Și știm că, desigur, există ciocniri. Dar atunci când pagina este afișată, probabilitatea ca pe o pagină a unui utilizator unele URL-uri să fie lipite împreună și acest lucru să fie observat poate fi neglijată.
Ca bonus, pentru multe operațiuni, hashurile sunt suficiente și șirurile în sine nu trebuie să fie stocate nicăieri.
Un alt exemplu este dacă șirurile sunt scurte, de exemplu, domeniile site-ului web. Ele pot fi depozitate ca atare. Sau, de exemplu, limba browserului ru este de 2 octeți. Desigur, îmi pare foarte rău pentru octeți, dar nu vă faceți griji, 2 octeți nu sunt păcat. Vă rugăm să-l păstrați așa cum este, nu vă faceți griji.
Un alt caz este atunci când, dimpotrivă, există o mulțime de linii și există o mulțime de unice în ele, și chiar și setul este potențial nelimitat. Un exemplu tipic sunt expresiile de căutare sau adresele URL. Expresii de căutare, inclusiv greșeli de scriere. Să vedem câte expresii de căutare unice există pe zi. Și se dovedește că sunt aproape jumătate din toate evenimentele. Și în acest caz, ați putea crede că trebuie să normalizați datele, să numărați identificatorii și să le puneți într-un tabel separat. Dar nu trebuie să faci asta. Păstrează aceste rânduri așa cum sunt.
Este mai bine să nu inventați nimic, pentru că dacă îl stocați separat, va trebui să faceți o alăturare. Și această unire este, în cel mai bun caz, un acces aleatoriu la memorie, dacă încă se potrivește în memorie. Dacă nu se potrivește, atunci vor fi probleme.
Și dacă datele sunt stocate în loc, atunci pur și simplu sunt citite în ordinea necesară din sistemul de fișiere și totul este în regulă.
Dacă aveți adrese URL sau alt șir lung complex, atunci merită să luați în considerare faptul că puteți calcula în avans un fel de extras și îl puteți scrie într-o coloană separată.
Pentru adrese URL, de exemplu, puteți stoca domeniul separat. Și dacă într-adevăr aveți nevoie de un domeniu, atunci utilizați doar această coloană, iar URL-urile vor fi acolo și nici măcar nu le veți atinge.
Să vedem care este diferența. ClickHouse are o funcție specializată care calculează domeniul. Este foarte rapid, l-am optimizat. Și, să fiu sincer, nici măcar nu respectă RFC, dar totuși ia în considerare tot ce avem nevoie.
Și într-un caz vom obține pur și simplu URL-urile și vom calcula domeniul. Asta înseamnă 166 de milisecunde. Și dacă luați un domeniu gata făcut, atunci se dovedește a fi doar 67 de milisecunde, adică de aproape trei ori mai rapid. Și este mai rapid nu pentru că trebuie să facem niște calcule, ci pentru că citim mai puține date.
De aceea, o cerere, care este mai lentă, are o viteză mai mare de gigaocteți pe secundă. Pentru că citește mai mulți gigaocteți. Acestea sunt date complet inutile. Solicitarea pare să ruleze mai repede, dar durează mai mult pentru a se finaliza.
Și dacă te uiți la cantitatea de date de pe disc, se dovedește că adresa URL este de 126 de megaocteți, iar domeniul este de doar 5 megaocteți. Se dovedește de 25 de ori mai puțin. Dar, cu toate acestea, cererea este executată doar de 4 ori mai rapid. Dar asta pentru că datele sunt fierbinți. Și dacă ar fi frig, probabil că ar fi de 25 de ori mai rapid datorită I/O pe disc.
Apropo, dacă estimați cât de mai mic este un domeniu decât o adresă URL, se dovedește a fi de aproximativ 4 ori mai mic.Dar din anumite motive, datele ocupă de 25 de ori mai puțin pe disc. De ce? Datorită compresiei. Și URL-ul este comprimat, iar domeniul este comprimat. Dar adesea URL-ul conține o grămadă de gunoi.
Și, desigur, merită să utilizați tipurile de date potrivite, care sunt concepute special pentru valorile dorite sau care sunt potrivite. Dacă sunteți în IPv4, stocați UInt32*. Dacă IPv6, atunci FixedString(16), deoarece adresa IPv6 este de 128 de biți, adică stocată direct în format binar.
Dar ce se întâmplă dacă uneori aveți adrese IPv4 și alteori IPv6? Da, le puteți stoca pe amândouă. O coloană pentru IPv4, alta pentru IPv6. Desigur, există o opțiune de a afișa IPv4 în IPv6. Și acest lucru va funcționa, dar dacă aveți adesea nevoie de o adresă IPv4 în solicitări, atunci ar fi bine să o puneți într-o coloană separată.
* ClickHouse are acum tipuri separate de date IPv4, IPv6 care stochează datele la fel de eficient ca numerele, dar le reprezintă la fel de convenabil ca șirurile de caractere.
De asemenea, este important să rețineți că merită să preprocesați datele în avans. De exemplu, primiți niște bușteni bruti. Și poate că nu ar trebui să le puneți imediat în ClickHouse, deși este foarte tentant să nu faceți nimic și totul va funcționa. Dar încă merită să efectuați calculele posibile.
De exemplu, versiunea browserului. Într-un departament din apropiere, spre care nu vreau să arăt cu degetul, versiunea de browser este stocată astfel, adică sub formă de șir: 12.3. Și apoi, pentru a face un raport, iau acest șir și îl împart într-o matrice, apoi în primul element al matricei. Desigur, totul încetinește. Am întrebat de ce fac asta. Mi-au spus că nu le place optimizarea prematură. Și nu-mi place pesimizarea prematură.
Deci, în acest caz, ar fi mai corect să se împartă în 4 coloane. Nu vă fie teamă aici, pentru că acesta este ClickHouse. ClickHouse este o bază de date cu coloane. Și cu cât coloanele sunt mai îngrijite, cu atât mai bine. Vor fi 5 BrowserVersions, faceți 5 coloane. Este în regulă.
Acum să ne uităm la ce să faceți dacă aveți o mulțime de șiruri foarte lungi, matrice foarte lungi. Nu trebuie să fie stocate deloc în ClickHouse. În schimb, puteți stoca doar un identificator în ClickHouse. Și pune aceste linii lungi într-un alt sistem.
De exemplu, unul dintre serviciile noastre de analiză are niște parametri de eveniment. Și dacă există mulți parametri pentru evenimente, pur și simplu salvăm primii 512 care apar, deoarece 512 nu este păcat.
Și dacă nu vă puteți decide asupra tipurilor dvs. de date, atunci puteți înregistra date și în ClickHouse, dar într-un tabel temporar de tip Log, special pentru date temporare. După aceasta, puteți analiza ce distribuție de valori aveți acolo, ce există în general și să creați tipurile corecte.
*ClickHouse are acum un tip de date ceea ce vă permite să stocați corzi eficient cu mai puțin efort.
Acum să ne uităm la un alt caz interesant. Uneori lucrurile funcționează ciudat pentru oameni. Intru și văd asta. Și se pare imediat că acest lucru a fost făcut de un administrator foarte experimentat, inteligent, care are o experiență vastă în configurarea MySQL versiunea 3.23.
Aici vedem o mie de tabele, fiecare dintre ele înregistrând restul împărțirii cine știe ce la o mie.
În principiu, respect experiența altor oameni, inclusiv înțelegerea suferinței care poate fi dobândită prin această experiență.
Iar motivele sunt mai mult sau mai puțin clare. Acestea sunt stereotipuri vechi care s-au acumulat în timpul lucrului cu alte sisteme. De exemplu, tabelele MyISAM nu au o cheie primară grupată. Și acest mod de împărțire a datelor poate fi o încercare disperată de a obține aceeași funcționalitate.
Un alt motiv este că este dificil să faci operațiuni de modificare pe mese mari. Totul va fi blocat. Deși în versiunile moderne de MySQL această problemă nu mai este atât de gravă.
Sau, de exemplu, microsharding, dar mai multe despre asta mai târziu.
Nu este nevoie să faceți acest lucru în ClickHouse, deoarece, în primul rând, cheia primară este grupată, datele sunt ordonate după cheia primară.
Și uneori oamenii mă întreabă: „Cum variază performanța interogărilor de interval în ClickHouse în funcție de dimensiunea tabelului?” Eu zic ca nu se schimba deloc. De exemplu, aveți un tabel cu un miliard de rânduri și citiți un interval de un milion de rânduri. Totul e bine. Dacă într-un tabel există un trilion de rânduri și citiți un milion de rânduri, va fi aproape la fel.
Și, în al doilea rând, tot felul de lucruri precum partițiile manuale nu sunt necesare. Dacă intri și te uiți la ce este pe sistemul de fișiere, vei vedea că tabelul este o afacere destul de mare. Și există ceva de genul pereților despărțitori în interior. Adică, ClickHouse face totul pentru tine și nu trebuie să suferi.
Modificarea în ClickHouse este gratuită dacă modificați coloana adăugați/eliminați.
Și nu ar trebui să faceți mese mici, pentru că dacă aveți 10 rânduri sau 10 de rânduri într-un tabel, atunci nu contează deloc. ClickHouse este un sistem care optimizează debitul, nu latența, așa că nu are sens să procesezi 000 linii.
Este corect să folosiți o singură masă mare. Scapă de vechile stereotipuri, totul va fi bine.
Și ca bonus, în cea mai recentă versiune avem acum capacitatea de a crea o cheie de partiționare arbitrară pentru a efectua tot felul de operațiuni de întreținere pe partiții individuale.
De exemplu, aveți nevoie de multe tabele mici, de exemplu, când este nevoie să procesați unele date intermediare, primiți bucăți și trebuie să efectuați o transformare pe ele înainte de a scrie în tabelul final. Pentru acest caz, există un motor de masă minunat - StripeLog. Este un fel de TinyLog, doar că mai bine.
* acum are și ClickHouse .
Un alt antipattern este microshardingul. De exemplu, trebuie să fragmentați date și aveți 5 servere, iar mâine vor fi 6 servere. Și vă gândiți cum să reechilibrați aceste date. Și în schimb nu spargi în 5 cioburi, ci în 1 de cioburi. Și apoi mapați fiecare dintre aceste microshard-uri pe un server separat. Și veți obține, de exemplu, 000 de ClickHouses pe un server, de exemplu. Instanțe separate pe porturi separate sau baze de date separate.
Dar acest lucru nu este foarte bun în ClickHouse. Deoarece chiar și o instanță ClickHouse încearcă să folosească toate resursele disponibile de server pentru a procesa o cerere. Adică ai un fel de server și are, de exemplu, 56 de nuclee de procesor. Executați o interogare care durează o secundă și va folosi 56 de nuclee. Și dacă ați plasat acolo 200 de ClickHouses pe un server, atunci se dovedește că vor începe 10 de fire. În general, totul va fi foarte rău.
Un alt motiv este că distribuția muncii în aceste cazuri va fi inegală. Unele vor termina mai devreme, altele vor termina mai târziu. Dacă toate acestea s-ar întâmpla într-un singur caz, atunci ClickHouse însuși și-ar da seama cum să distribuie corect datele între fire.
Și un alt motiv este că veți avea comunicare interprocesor prin TCP. Datele vor trebui serializate, deserializate, iar acesta este un număr mare de microshard-uri. Pur și simplu nu va funcționa eficient.
Un alt antipattern, deși cu greu poate fi numit antipattern. Aceasta este o cantitate mare de pre-agregare.
În general, pre-agregarea este bună. Aveai un miliard de rânduri, l-ai agregat și a devenit 1 de rânduri, iar acum interogarea este executată instantaneu. Totul e minunat. Poți sa faci asta. Și pentru aceasta, chiar și ClickHouse are un tip de tabel special, AggregatingMergeTree, care efectuează o agregare incrementală pe măsură ce sunt inserate datele.
Dar există momente când te gândești că vom agrega astfel de date și vom agrega astfel de date. Și în unele departamente vecine, nici nu vreau să spun care dintre ele, folosesc tabelele SummingMergeTree pentru a rezuma după cheia primară și aproximativ 20 de coloane sunt folosite ca cheie primară. Pentru orice eventualitate, am schimbat numele unor coloane pentru secret, dar cam asta este.
Și apar astfel de probleme. În primul rând, volumul de date nu scade prea mult. De exemplu, scade de trei ori. De trei ori ar fi un preț bun pentru a vă permite capabilitățile de analiză nelimitate care apar dacă datele dvs. nu sunt agregate. Dacă datele sunt agregate, atunci în loc de analize veți obține doar statistici jalnice.
Și ce este atât de special la asta? Cert este că acești oameni din departamentul vecin merg uneori și cer să adauge o altă coloană la cheia primară. Adică am agregat datele așa, dar acum ne dorim puțin mai mult. Dar ClickHouse nu are o cheie primară de modificare. Prin urmare, trebuie să scriem câteva scripturi în C++. Și nu-mi plac scripturile, chiar dacă sunt în C++.
Și dacă te uiți la pentru ce a fost creat ClickHouse, atunci datele neagregate sunt exact scenariul pentru care s-au născut. Dacă utilizați ClickHouse pentru date neagregate, atunci procedați corect. Dacă adunați, acest lucru este uneori de iertare.
Un alt caz interesant este interogările într-o buclă infinită. Uneori merg la un server de producție și mă uit la lista de procese de afișare acolo. Și de fiecare dată descopăr că se întâmplă ceva groaznic.
De exemplu, așa. Este imediat clar că totul poate fi făcut dintr-o singură cerere. Doar scrieți adresa URL și lista acolo.
De ce multe astfel de interogări într-o buclă nesfârșită sunt proaste? Dacă nu se folosește un index, atunci veți avea mai multe treceri peste aceleași date. Dar dacă se folosește indexul, de exemplu, aveți o cheie primară pentru ru și scrieți url = ceva acolo. Și crezi că dacă se citește doar un URL din tabel, totul va fi bine. Dar de fapt nu. Pentru că ClickHouse face totul în loturi.
Când are nevoie să citească un anumit interval de date, citește puțin mai mult, deoarece indexul din ClickHouse este rar. Acest index nu vă permite să găsiți un rând individual în tabel, ci doar un anumit interval. Și datele sunt comprimate în blocuri. Pentru a citi un rând, trebuie să luați întregul bloc și să-l descundeți. Și dacă faci o grămadă de interogări, vei avea multe suprapuneri și vei avea multă muncă de făcut din nou și din nou.
Și ca bonus, puteți observa că în ClickHouse nu ar trebui să vă fie frică să transferați chiar și megaocteți și chiar sute de megabiți în secțiunea IN. Îmi amintesc din practica noastră că, dacă în MySQL transferăm o grămadă de valori în secțiunea IN, de exemplu, transferăm 100 de megaocteți din unele numere acolo, atunci MySQL consumă 10 gigaocteți de memorie și nu se întâmplă nimic altceva, totul functioneaza prost.
Și a doua este că, în ClickHouse, dacă interogările dvs. folosesc un index, atunci acesta nu este întotdeauna mai lento decât o scanare completă, adică dacă trebuie să citiți aproape întregul tabel, acesta va merge secvenţial și va citi întregul tabel. În general, el își va da seama singur.
Dar, totuși, există unele dificultăți. De exemplu, faptul că IN cu o subinterogare nu folosește indexul. Dar aceasta este problema noastră și trebuie să o rezolvăm. Nu este nimic fundamental aici. O vom repara*.
Și un alt lucru interesant este că dacă aveți o cerere foarte lungă și procesarea cererilor distribuite este în curs, atunci această solicitare foarte lungă va fi trimisă fiecărui server fără compresie. De exemplu, 100 de megaocteți și 500 de servere. Și, în consecință, veți avea 50 de gigaocteți transferați prin rețea. Va fi transmis și apoi totul va fi finalizat cu succes.
* utilizați deja; Totul a fost rezolvat conform promisiunii.
Și un caz destul de comun este atunci când solicitările vin de la API. De exemplu, ați creat un fel de serviciu propriu. Și dacă cineva are nevoie de serviciul tău, atunci deschizi API-ul și literalmente două zile mai târziu vezi că se întâmplă ceva de neînțeles. Totul este supraîncărcat și vin niște solicitări teribile care nu ar fi trebuit să se întâmple niciodată.
Și există o singură soluție. Dacă ați deschis API-ul, atunci va trebui să îl tăiați. De exemplu, introduceți un fel de cote. Nu există alte opțiuni normale. În caz contrar, vor scrie imediat un scenariu și vor apărea probleme.
Și ClickHouse are o caracteristică specială - calculul cotei. Mai mult, vă puteți transfera cheia de cotă. Acesta este, de exemplu, ID-ul utilizatorului intern. Iar cotele vor fi calculate independent pentru fiecare dintre ele.
Acum încă un lucru interesant. Aceasta este replicare manuală.
Cunosc multe cazuri în care, deși ClickHouse are suport de replicare încorporat, oamenii reproduc ClickHouse manual.
Care este principiul? Aveți o conductă de procesare a datelor. Și funcționează independent, de exemplu, în diferite centre de date. Scrieți aceleași date în același mod în ClickHouse. Adevărat, practica arată că datele vor diverge în continuare din cauza unor caracteristici din codul tău. Sper să fie în al tău.
Și din când în când va trebui să vă sincronizați manual. De exemplu, o dată pe lună, administratorii fac rsync.
De fapt, este mult mai ușor să utilizați replicarea încorporată în ClickHouse. Dar pot exista unele contraindicații, deoarece pentru aceasta trebuie să utilizați ZooKeeper. Nu o să spun nimic rău despre ZooKeeper, în principiu, sistemul funcționează, dar se întâmplă ca oamenii să nu-l folosească din cauza java-fobiei, pentru că ClickHouse este un sistem atât de bun, scris în C++, pe care îl poți folosi și totul va fi bine. Și ZooKeeper este în java. Și cumva nici nu vrei să te uiți, dar apoi poți folosi replicarea manuală.
ClickHouse este un sistem practic. Ea ține cont de nevoile tale. Dacă aveți replicare manuală, atunci puteți crea un tabel distribuit care se uită la replicile dvs. manuale și face o transferare între ele. Și există chiar și o opțiune specială care îți permite să eviți flop-urile, chiar dacă liniile tale diverg sistematic.
Pot apărea alte probleme dacă utilizați motoarele de tabel primitive. ClickHouse este un constructor care are o grămadă de motoare de tabele diferite. Pentru toate cazurile grave, așa cum este scris în documentație, utilizați tabele din familia MergeTree. Și restul - așa este, pentru cazuri individuale sau pentru teste.
Într-un tabel MergeTree, nu trebuie să aveți nicio dată și oră. Îl poți folosi în continuare. Dacă nu există dată și oră, scrieți că implicit este 2000. Acest lucru va funcționa și nu va necesita resurse.
Și în noua versiune a serverului, puteți chiar să specificați că aveți partiționare personalizată fără o cheie de partiție. Va fi la fel.
Pe de altă parte, puteți utiliza motoarele de tabel primitive. De exemplu, completați datele o dată și priviți, răsuciți și ștergeți. Puteți folosi Log.
Sau stocarea unor volume mici pentru procesarea intermediară este StripeLog sau TinyLog.
Memoria poate fi folosită dacă cantitatea de date este mică și puteți pur și simplu să învârtiți ceva în RAM.
ClickHouse nu prea îi plac datele renormalizate.
Iată un exemplu tipic. Acesta este un număr mare de adrese URL. Le pui în următorul tabel. Și apoi au decis să facă JOIN cu ei, dar acest lucru nu va funcționa, de regulă, deoarece ClickHouse acceptă doar Hash JOIN. Dacă nu există suficientă RAM pentru o mulțime de date care trebuie conectate, atunci JOIN nu va funcționa*.
Dacă datele sunt de cardinalitate ridicată, atunci nu vă faceți griji, stocați-le într-o formă denormalizată, adresele URL sunt direct la locul lor în tabelul principal.
* și acum ClickHouse are și un merge join și funcționează în condițiile în care datele intermediare nu se potrivesc în RAM. Dar acest lucru este ineficient și recomandarea rămâne în vigoare.
Încă câteva exemple, dar deja mă îndoiesc dacă sunt anti-model sau nu.
ClickHouse are un defect cunoscut. Nu știe cum să actualizeze*. În unele privințe, acest lucru este chiar bun. Dacă aveți niște date importante, de exemplu, contabilitate, atunci nimeni nu le va putea trimite, deoarece nu există actualizări.
* Suportul pentru actualizare și ștergere în modul lot a fost adăugat cu mult timp în urmă.
Dar există câteva modalități speciale care permit actualizările ca în fundal. De exemplu, tabele precum ReplaceMergeTree. Ei fac actualizări în timpul îmbinărilor în fundal. Puteți forța acest lucru utilizând tabelul de optimizare. Dar nu faceți acest lucru prea des, deoarece va suprascrie complet partiția.
JOIN-urile distribuite în ClickHouse sunt, de asemenea, gestionate prost de către planificatorul de interogări.
Rău, dar uneori ok.
Folosind ClickHouse numai pentru a citi datele înapoi folosind select*.
Nu aș recomanda utilizarea ClickHouse pentru calcule greoaie. Dar acest lucru nu este în întregime adevărat, pentru că deja ne îndepărtăm de această recomandare. Și am adăugat recent capacitatea de a aplica modele de învățare automată în ClickHouse - Catboost. Și mă deranjează pentru că mă gândesc: „Ce groază. Iată câte cicluri pe octet rezultă! Chiar urăsc să irosesc ceasurile pe octeți.
Dar nu vă fie teamă, instalați ClickHouse, totul va fi bine. Dacă ceva, avem o comunitate. Apropo, comunitatea ești tu. Și dacă aveți probleme, puteți măcar să accesați chat-ul nostru și sperăm că vă vor ajuta.
întrebări
Multumesc pentru raport! Unde mă pot plânge de blocarea ClickHouse?
Poți să-mi plângi personal chiar acum.
Am început recent să folosesc ClickHouse. Am renunțat imediat la interfața cli.
Esti norocos.
Puțin mai târziu, am blocat serverul cu un mic select.
Ai talent.
Am deschis un bug GitHub, dar a fost ignorat.
Vom vedea.
Alexey m-a păcălit să particip la raport, promițându-mi că îmi va spune cum accesezi datele din interior.
Foarte simplu.
Mi-am dat seama de asta ieri. Mai multe detalii.
Nu există trucuri groaznice acolo. Există doar compresie bloc cu bloc. Valoarea implicită este LZ4, puteți activa ZSTD*. Blocuri de la 64 de kiloocteți la 1 megaoctet.
* există și suport pentru codecuri de compresie specializate care pot fi utilizate în lanț cu alți algoritmi.
Sunt blocurile doar date brute?
Nu complet crud. Există matrice. Dacă aveți o coloană numerică, atunci numerele dintr-un rând sunt plasate într-o matrice.
Este clar.
Alexey, un exemplu care a fost cu uniqExact peste IP-uri, adică faptul că uniqExact durează mai mult pentru a calcula prin linii decât după numere și așa mai departe. Ce se întâmplă dacă folosim o fereață cu urechile și aruncăm în momentul corecturii? Adică se pare că ai spus că pe discul nostru nu este foarte diferit. Dacă citim linii de pe disc și turnăm, agregatele noastre vor fi mai rapide sau nu? Sau vom câștiga încă puțin aici? Mi se pare că ați testat acest lucru, dar din anumite motive nu l-ați indicat în benchmark.
Cred că va fi mai lent decât fără casting. În acest caz, adresa IP trebuie analizată din șir. Desigur, la ClickHouse, analizarea adreselor noastre IP este și ea optimizată. Am încercat foarte mult, dar aici aveți numerele scrise în forma a zece miile. Foarte inconfortabil. Pe de altă parte, funcția uniqExact va funcționa mai lent pe șiruri, nu numai pentru că acestea sunt șiruri, ci și pentru că este selectată o specializare diferită a algoritmului. Șirurile sunt pur și simplu procesate diferit.
Ce se întâmplă dacă luăm un tip de date mai primitiv? De exemplu, am notat ID-ul utilizatorului, pe care îl avem, l-am notat ca o linie, apoi l-am amestecat, va fi mai distractiv sau nu?
Mă îndoiesc. Cred că va fi și mai trist, pentru că până la urmă, analizarea numerelor este o problemă serioasă. Mi se pare că acest coleg chiar a dat un raport despre cât de greu este să analizezi numerele în forma a zece miile, dar poate că nu.
Alexey, mulțumesc foarte mult pentru raport! Și mulțumesc foarte mult pentru ClickHouse! Am o întrebare despre planuri. Există planuri pentru o funcție de actualizare incompletă a dicționarelor?
Adică o repornire parțială?
Da Da. La fel ca și capacitatea de a seta un câmp MySQL acolo, adică actualizați după, astfel încât numai aceste date să fie încărcate dacă dicționarul este foarte mare.
O caracteristică foarte interesantă. Și cred că cineva a sugerat-o în chat-ul nostru. Poate ai fost chiar tu.
Eu nu cred acest lucru.
Super, acum se dovedește că sunt două cereri. Și poți începe încet să o faci. Dar vreau să vă avertizez imediat că această caracteristică este destul de simplu de implementat. Adică, în teorie, trebuie doar să scrieți numărul versiunii în tabel și apoi să scrieți: versiune mai mică decât așa și cutare. Asta înseamnă că, cel mai probabil, vom oferi acest lucru pasionaților. Esti un entuziast?
Da, dar, din păcate, nu în C++.
Colegii tăi știu să scrie în C++?
Voi găsi pe cineva.
Grozav*.
* caracteristica a fost adăugată la două luni după raport - autorul întrebării a dezvoltat-o și a trimis-o pe a lui .
Vă mulțumim!
Buna ziua! Multumesc pentru raport! Ați menționat că ClickHouse este foarte bun la consumarea tuturor resurselor disponibile. Iar vorbitorul de lângă Luxoft a vorbit despre soluția lui pentru Russian Post. El a spus că le-a plăcut foarte mult ClickHouse, dar nu l-au folosit în locul principalului lor competitor tocmai pentru că consuma tot procesorul. Și nu l-au putut conecta la arhitectura lor, la ZooKeeper cu dockeri. Este posibil să limitezi cumva ClickHouse, astfel încât să nu consume tot ce îi devine disponibil?
Da, este posibil și foarte ușor. Dacă doriți să consumați mai puține nuclee, scrieți set max_threads = 1. Și asta este tot, va executa cererea într-un singur nucleu. Mai mult, puteți specifica setări diferite pentru diferiți utilizatori. Deci nicio problemă. Și spuneți-le colegilor de la Luxoft că nu este bine că nu au găsit această setare în documentație.
Alexey, salut! Aș dori să întreb despre această întrebare. Nu este prima dată când aud că mulți oameni încep să folosească ClickHouse ca stocare pentru jurnalele. La raport ați spus să nu faceți acest lucru, adică nu trebuie să stocați șiruri lungi. Ce crezi despre asta?
În primul rând, jurnalele sunt, de regulă, șiruri lungi. Există, desigur, și excepții. De exemplu, un serviciu scris în java aruncă o excepție, este înregistrat. Și așa mai departe într-o buclă nesfârșită, iar spațiul de pe hard disk se epuizează. Soluția este foarte simplă. Dacă liniile sunt foarte lungi, atunci tăiați-le. Ce înseamnă lung? Zeci de kiloocteți sunt răi*.
* în cele mai recente versiuni de ClickHouse, „granularitatea indexului adaptiv” este activată, ceea ce elimină problema stocării rândurilor lungi în cea mai mare parte.
Este normal un kilobyte?
E normal.
Buna ziua! Multumesc pentru raport! Am întrebat deja despre asta în chat, dar nu-mi amintesc dacă am primit un răspuns. Există planuri de a extinde cumva secțiunea WITH în maniera CTE?
Nu încă. Secțiunea noastră WITH este oarecum frivolă. Este ca o mică caracteristică pentru noi.
Am înțeles. Mulțumesc!
Multumesc pentru raport! Foarte interesant! Întrebare globală. Există planuri de modificare a ștergerii datelor, poate sub forma unor cioturi?
Neapărat. Aceasta este prima noastră sarcină din coada noastră. Acum ne gândim în mod activ la cum să facem totul corect. Și ar trebui să începeți să apăsați tastatura*.
* a apăsat butoanele de pe tastatură și a făcut totul.
Va afecta acest lucru cumva performanța sistemului sau nu? Va fi inserarea la fel de rapidă ca acum?
Poate că ștergerile în sine și actualizările în sine vor fi foarte grele, dar acest lucru nu va afecta performanța selectărilor sau performanța inserărilor.
Și încă o mică întrebare. La prezentare ați vorbit despre cheia primară. În consecință, avem partiționare, care este lunară implicit, corect? Și când setăm un interval de date care se încadrează într-o lună, atunci doar această partiție este citită, nu?
Da.
O intrebare. Dacă nu putem selecta nicio cheie primară, atunci este corect să o facem în mod specific conform câmpului „Data”, astfel încât în fundal să existe mai puțină rearanjare a acestor date, astfel încât să se potrivească într-o manieră mai ordonată? Dacă nu aveți interogări de interval și nici măcar nu puteți selecta nicio cheie primară, merită să puneți o dată în cheia principală?
Da.
Poate că are sens să puneți un câmp în cheia primară care va comprima mai bine datele dacă sunt sortate după acest câmp. De exemplu, ID utilizator. Utilizatorul, de exemplu, merge pe același site. În acest caz, puneți ID-ul utilizatorului și ora. Și apoi datele tale vor fi mai bine comprimate. În ceea ce privește data, dacă într-adevăr nu aveți și nu aveți niciodată interogări privind intervalul de date, atunci nu trebuie să puneți data în cheia primară.
OK multumesc foarte mult!
Sursa: www.habr.com