Tri vjetĂ« mĂ« parĂ«, Viktor Taranovski dhe Aleksej Milovidov nga Yandex nĂ« skenĂ« HighLoad++ , treguan se sa i mirĂ« Ă«shtĂ« ClickHouse, dhe si ai nuk ngadalĂ«sohet. NdĂ«rsa nĂ« skenĂ«n ngjitur ishte AleksandĂ«r Zajcev me pĂ«r kalimin nĂ« ClickHouse nga njĂ« tjetĂ«r sistem analizues dhe me pĂ«rfundimin se ClickHouse, padyshim, Ă«shtĂ« i mirĂ«, por jo shumĂ« i kĂ«ndshĂ«m pĂ«r t'u pĂ«rdorur. Kur nĂ« vitin 2016, kompania LifeStreet, nĂ« tĂ« cilĂ«n Aleksandri punonte atĂ«herĂ«, po transferonte njĂ« sistem analizues me shumĂ« petabajtĂ« nĂ« ClickHouse, kjo ishte njĂ« "rrugĂ« nga tulla tĂ« verdha", e mbushur me rreziqe tĂ« panjohura â ClickHouse atĂ«herĂ« tĂ« ngjashme me njĂ« fushĂ« mines.
Tri vjet mĂ« vonĂ« ClickHouse Ă«shtĂ« bĂ«rĂ« shumĂ« mĂ« mirĂ« â gjatĂ« kĂ«saj kohe, Aleksandri themeloi kompaninĂ« Altinity, e cila jo vetĂ«m qĂ« ndihmon nĂ« kalimin nĂ« ClickHouse dhjetĂ«ra projekte, por gjithashtu pĂ«rmirĂ«son vetĂ« produktin sĂ« bashku me kolegĂ«t nga Yandex. Tani ClickHouse nuk Ă«shtĂ« njĂ« shĂ«titje pa brenga, por gjithashtu nuk Ă«shtĂ« mĂ« njĂ« fushĂ« mines.
Aleksandri merret me sisteme të shpërndara që nga viti 2003, ka zhvilluar projekte të mëdha në MySQL, Oracle dhe Vertica. Në konferencën e zhvilluar HighLoad++ 2019 Aleksandri, një nga pionierët në përdorimin ClickHouse, tregoi se çfarë përfaqëson tani ky sistem menaxhimi të të dhënave. Ne do të mësojmë për karakteristikat kryesore ClickHouse: si ai dallon nga sistemet e tjera dhe në cilat raste është më efektiv të përdoret. Me shembuj do të shqyrtojmë praktika të reja dhe të provuara nga projektet për ndërtimin e sistemeve mbi ClickHouse.
Retrospektivë: çfarë ndodhi 3 vjet më parë
Tri vjet më parë ne po transferonim kompaninë LifeStreet në ClickHouse nga një bazë të dhënash analitike tjetër, dhe migrimi i analizës së rrjetit të reklamave dukej kështu:
- Qershor 2016. Në OpenSource doli ClickHouse dhe filloi projekti ynë;
- Gusht. Proof Of Concept: një rrjet i madh reklamash, infrastrukturë dhe 200-300 terabajtë të dhënash;
- Tetor. Të dhënat e para në prodhim;
- Dhjetor. Ngarkesa e plotĂ« produktive â 10-50 miliardĂ« ngjarjesh nĂ« ditĂ«.
- Qershor 2017. Migrimi i suksesshëm i përdoruesve në ClickHouse, 2.5 petabajtë të dhënash në një klaster prej 60 serverash.
Gjatë procesit të migrimit u rrit kuptimi se ClickHouse është një sistem i mirë, me të cilin është këndshme të punosh, por është një projekt të brendshëm i kompanisë Yandex. Prandaj ka nuanca: Yandex fillimisht do të merret me kërkesat e brendshme dhe vetëm më vonë me komunitetin dhe nevojat e përdoruesve të jashtëm, ndërsa ClickHouse nuk arrinte atëherë në nivelin e ndërmarrjes në shumë fusha funksionale. Prandaj, në mars 2017 themeluam kompaninë Altinity, për të bërë ClickHouse edhe më të shpejtë dhe më të rehatshëm jo vetëm për Yandex, por edhe për përdorues të tjerë. Dhe tani ne:
- Mësojmë dhe ndihmojmë në ndërtimin e zgjidhjeve mbi ClickHouse në mënyrë që klientët të mos hasin vështirësi dhe që zgjidhja përfundimisht të funksionojë;
- Sigurojmë mbështetje 24/7 ClickHouse-instalimeve;
- Zhvillojmë projekte të ecosistemit tonë;
- Aktivisht angazhohemi në vetë ClickHouse, duke përgjigjur në kërkesat e përdoruesve që duan të shohin tipare të caktuara.
Natyrisht, ne ndihmojmë gjithashtu me kalimin në ClickHouse me MySQL, Vertica, Oracle, Greenplum, Redshift dhe sisteme të tjera. Ne kemi marrë pjesë në kalime të ndryshme, dhe të gjitha kanë qenë të suksesshme.
Pse duhet të kaloni në ClickHouse
Nuk ngadalĂ«son! Kjo Ă«shtĂ« arsyeja kryesore. ClickHouse â njĂ« bazĂ« tĂ« dhĂ«nash shumĂ« tĂ« shpejtĂ« pĂ«r skenarĂ« tĂ« ndryshĂ«m:
Citatet rastësore të njerëzve që punojnë për një kohë të gjatë me ClickHouse.
ShkallĂ«zimi. NĂ« njĂ« bazĂ« tjetĂ«r tĂ« dhĂ«nash, mund tĂ« arrini performancĂ« tĂ« mirĂ« nĂ« njĂ« hardware tĂ« vetĂ«m, por ClickHouse mund tĂ« shkallĂ«zohet jo vetĂ«m nĂ« mĂ«nyrĂ« vertikale, por edhe horizontalisht, thjesht duke shtuar servera. Gjithçka nuk funksionon aq smooth sa do tĂ« dĂ«shironit, por funksionon. Mund tĂ« rritni sistemin me rritjen e biznesit. ĂshtĂ« e rĂ«ndĂ«sishme qĂ« nuk jemi tĂ« kufizuar nga zgjidhja tani dhe gjithmonĂ« ka potencial pĂ«r zhvillim.
Portabiliteti. Nuk ka varësi nga diçka të vetme. Për shembull, me Amazon Redshift është e vështirë të kalosh diku tjetër. Ndërsa ClickHouse mund ta instaloni në laptopin tuaj, server, ta vendosni në cloud, të shkoni në Kubernetes nuk ka kufizime për të shfrytëzuar infrastrukturën. Kjo është e sigurt për të gjithë dhe është një avantazh i madh që shumë baze të dhënash të ngjashme nuk mund ta lavdërojnë.
Fleksibiliteti. ClickHouse nuk ndalet nĂ« diçka tĂ« vetme, siç Ă«shtĂ« Yandex.Metrika, por zhvillohet dhe pĂ«rdoret nĂ« njĂ« numĂ«r gjithnjĂ« e mĂ« tĂ« madh projektesh dhe industrish. Mund ta zgjeroni atĂ«, duke shtuar mundĂ«si tĂ« reja pĂ«r tĂ« zgjidhur detyra tĂ« reja. PĂ«r shembull, besohet se ruajtja e log-eve nĂ« bazĂ«n e tĂ« dhĂ«nave Ă«shtĂ« njĂ« lloj faux pas, prandaj pĂ«r kĂ«tĂ« Ă«shtĂ« shpikur Elasticsearch. Por, falĂ« fleksibilitetit tĂ« ClickHouse, gjithashtu mund tĂ« ruani log-e dhe shpesh kjo Ă«shtĂ« madje mĂ« mirĂ« sesa nĂ« Elasticsearch â nĂ« ClickHouse pĂ«r kĂ«tĂ« kĂ«rkohet 10 herĂ« mĂ« shumĂ« hardware.
FalĂ« Open Source. Nuk ka nevojĂ« tĂ« paguani pĂ«r asgjĂ«. Nuk ka nevojĂ« tĂ« kontaktoni pĂ«r tĂ« marrĂ« leje pĂ«r ta vendosur sistemin nĂ« laptopin ose serverin tuaj. Nuk ka pagesa tĂ« fshehura. NĂ« tĂ« njĂ«jtĂ«n kohĂ«, asnjĂ« teknologji tjetĂ«r Open Source baze tĂ« dhĂ«nash nuk mund tĂ« konkurrojĂ« nĂ« shpejtĂ«si me ClickHouse. MySQL, MariaDB, Greenplum â tĂ« gjitha ato janĂ« shumĂ« mĂ« tĂ« ngadalta.
Komuniteti, dinamikat dhe fun. ClickHouse një komunitet i shkëlqyer: takime, biseda dhe Aleksei Milovidov, i cili na ngroh të gjithëve me energjinë dhe optimizmin e tij.
Kalimi në ClickHouse
Për të kaluar në ClickHouse një tjetër sistem, ju nevojiten vetëm tri gjëra:
- Të kuptoni kufizimet ClickHouse dhe për çfarë nuk është i përshtatshëm.
- Të përdorni avantazhet e teknologjisë dhe karakteristikat e saj më të forta.
- Të eksperimentoni. Edhe duke kuptuar se si funksionon ClickHouse, nuk është gjithmonë e mundur të parashikohet kur ai do të jetë më i shpejtë, kur më i ngadaltë, kur më i mirë dhe kur më i keq. Prandaj provoni.
Problemi i kalimit
Ka vetëm një "por": nëse kaloni nga ClickHouse një sistem tjetër, zakonisht diçka nuk shkon siç duhet. Ne jemi mësuar me disa praktika dhe gjëra që funksionojnë në bazën tonë të të dhënave të preferuar. Për shembull, çdo person që punon me baza të dhënash SQL, e konsideron si të domosdoshme një grup funksionesh:transaksionet;
- kufizimet;
- koherenca;
- indekset;
- UPDATE/DELETE
- NULLs;
- milisekonda;;
- konsistenca automatike e tipave;
- bashkëveprimi i shumëfishtë;
- particionet arbitrare;
- mjetet për menaxhimin e klasterëve.
- Grupi është i domosdoshëm, por tre vjet më parë në
nuk kishte asnjë nga këto funksione! Tani nga ato që nuk ishin realizuar, ka mbetur më pak se gjysma: transaksionet, kufizimet, koherenca, milisekondat dhe automatizimi i tipave. ClickHouse Dhe e rëndësishmja është se në
disa praktika dhe qasje standarde nuk funksionojnë ose funksionojnë ndryshe nga ç'jemi mësuar. Gjithçka që shfaqet në ClickHouse , përputhet me " ClickHouseClickHouse way", dmth. funksionet ndryshojnë nga bazat e tjera të të dhënave. Për shembull:Indekset nuk përzgjidhen, por kalohen.
- nuk janë sinkron, por asinkron.
- NULLs Ka bashkëveprime të shumëfishta, por nuk ka planifikues kërkesash. Si realizohen ata, nuk është përgjithësisht shumë e qartë për njerëzit nga bota e bazave të të dhënave.
- Skenarët e ClickHouse
Në vitin 1960, matematicieni amerikan me origjinë hungareze
Wigner E. P. shkroi njĂ« artikull " The unreasonable effectiveness of mathematics in the natural sciences" ("Efektiviteti i paarsyeshĂ«m i matematikĂ«s nĂ« shkencat natyrore") mbi faktin se bota rreth nesh pĂ«r njĂ« arsye tĂ« caktuar pĂ«rshkruhet mirĂ« nga ligjet matematikore. MatematikĂ« â njĂ« shkencĂ« abstrakte dhe ligjet fizike, tĂ« shprehura nĂ« formĂ«n matematike nuk janĂ« triviale, dhenxori nĂ« pah se kjo Ă«shtĂ« shumĂ« e çuditshme. shkroi njĂ« artikull " Sipas mendimit tim,
â Ă«shtĂ« njĂ«lloj çuditĂ«ri. Duke e rimodelluar Wigner-in, mund tĂ« themi kĂ«shtu: Ă«shtĂ« mahnitĂ«se efekti i paarsyeshĂ«m ClickHouse nĂ« aplikacione analitikĂ« tĂ« shumĂ«llojshme! ClickHouse PĂ«r shembull, le tĂ« marrim
Real-Time Data Warehouse Depoja e DhĂ«nash nĂ« KohĂ« Reale, nĂ« tĂ« cilin tĂ« dhĂ«nat ngarkohet praktikisht vazhdimisht. Ne duam tĂ« marrim kĂ«rkesa prej tij me vonesĂ« njĂ« sekondĂ«. TĂ« lutem â pĂ«rdorim ClickHouse, sepse pĂ«r kĂ«tĂ« skenar Ă«shtĂ« dizajnuar. ClickHouse kĂ«shtu pĂ«rdoret jo vetĂ«m nĂ« web, por edhe nĂ« analizat e marketingut dhe financiare, AdTech, si dhe nĂ« Fraud detection. NĂ« Real-time Data Warehouse pĂ«rdoret njĂ« skemĂ« e kompleks strukturĂ«s tip «yll» ose «flokë», shumĂ« tabela me JOIN (nganjĂ«herĂ« tĂ« shumĂ«fishta), dhe tĂ« dhĂ«nat zakonisht ruhen dhe ndryshohen nĂ« ndonjĂ« sistem.
Le tĂ« marrim njĂ« skenar tjetĂ«r â Time Series: monitorimi i pajisjeve, rrjeteve, statistika e pĂ«rdorimit, interneti i gjĂ«rave. KĂ«tu ndeshemi me ngjarje tĂ« thjeshta tĂ« renditura sipas kohĂ«s. ClickHouse pĂ«r kĂ«tĂ« nuk u dizajnua fillimisht, por e tregoi veten mirĂ«, prandaj kompanitĂ« e mĂ«dha e pĂ«rdorin ClickHouse si njĂ« depo pĂ«r informacionet e monitorimit. PĂ«r tĂ« studiuar nĂ«se ClickHouse Ă«shtĂ« i pĂ«rshtatshĂ«m pĂ«r time-series, ne bĂ«mĂ« njĂ« benchmark mbi qasjen dhe rezultatet InfluxDB dhe TimescaleDB â bazat e tĂ« dhĂ«nave tĂ« specializuara time-series , edhe pa optimizim pĂ«r kĂ«to detyra, fiton dhe nĂ« fushĂ« tĂ« huaj: , qĂ« ClickHousezakonisht pĂ«rdoret njĂ« tabelĂ« e ngushtĂ« â disa kolona tĂ« vogla. Nga monitorimi mund tĂ« vijnĂ« shumĂ« tĂ« dhĂ«na, â miliona regjistrimeve nĂ« sekondĂ«, â dhe zakonisht ato vijnĂ« nĂ« kĂ«rcime tĂ« vogla (
NĂ« time-series streaming). Prandaj, nevojitet njĂ« skenar tjetĂ«r i futjes, dhe vetĂ« kĂ«rkesat â me ndonjĂ« specifikĂ«.real-time Log Management
. Grumbullimi i logeve nĂ« DB â kjo zakonisht Ă«shtĂ« keq, por nĂ«mund tĂ« bĂ«het me disa komente, siç u pĂ«rmend mĂ« sipĂ«r. ShumĂ« kompani e pĂ«rdorin ClickHouse pikĂ«risht pĂ«r kĂ«tĂ«. NĂ« kĂ«tĂ« rast pĂ«rdoret njĂ« tabelĂ« e gjerĂ« dhe e sheshtĂ«, ku ruajmĂ« loget e plota (p.sh., nĂ« formĂ«n e ClickHouse ), ose i prenojmĂ« nĂ« pjesĂ«. TĂ« dhĂ«nat ngarkohen zakonisht nĂ« grupe tĂ« mĂ«dha (skedarĂ«), dhe kĂ«rkohet ndonjĂ« fushĂ«. JSONPĂ«r secilĂ«n nga kĂ«to funksione zakonisht pĂ«rdoren DB tĂ« specializuara.
një mund ta bëjë këtë të gjitha dhe aq mirë, sa e tejkalon ato në performancë. Le të shqyrtojmë tani në detaje ClickHouse skenerin, dhe si të «përgatisim» time-series për këtë skenar. ClickHouse Time-Series
Në këtë moment, ky është skenari kryesor për të cilin
nĂ« konsiderohet zgjidhja standarde. ClickHouse Time-series time-series â Ă«shtĂ« njĂ« grup ngjarjesh tĂ« renditura nĂ« kohĂ«, qĂ« paraqesin ndryshimet e njĂ« procesi nĂ« kohĂ«. PĂ«r shembull, kjo mund tĂ« jetĂ« frekuenca e rrahjeve tĂ« zemrĂ«s pĂ«r njĂ« ditĂ« ose numri i proceseve nĂ« njĂ« sistem. Ădo gjĂ« qĂ« ofron tick tĂ« kohĂ«s me disa masa â Ă«shtĂ« time-series:
Më shumë nga këto lloje ngjarjesh vijnë nga monitorimi. Kjo mund të jetë jo vetëm monitorimi i webit, por edhe i pajisjeve reale: automjete, sisteme industriale, IoT, prodhimesh ose taksive të pa pilot, në bagazhin e të cilave Yandex tashmë po vendos ClickHouse-server.
PĂ«r shembull, ka kompani qĂ« mbledhin tĂ« dhĂ«na nga anijet. Ădo disa sekonda sensorĂ« nga njĂ« anije kontejner ndajnĂ« qindra masa tĂ« ndryshme. InxhinierĂ«t i studiojnĂ«, ndĂ«rtojnĂ« modele dhe pĂ«rpiqen tĂ« kuptojnĂ« sa efektivisht po shfrytĂ«zohet anija, sepse anija kontejner nuk duhet tĂ« qĂ«ndrojĂ« asnjĂ« sekondĂ«. Ădo qĂ«ndrim â Ă«shtĂ« humbje parash, prandaj Ă«shtĂ« e rĂ«ndĂ«sishme tĂ« parashikohet rruta nĂ« mĂ«nyrĂ« qĂ« ndalesat tĂ« ishin minimale.
Aktualisht po vërehet një rritje e DB-ve të specializuara që mat time-series. Në uebfaqen DB-Engines për ndonjë arsye renditen databaza të ndryshme dhe mund të shihen sipas llojeve:
Lloji më në rritje është time-series. Gjithashtu po rriten DB të grafikëve, por time-series po rriten më shpejt vitet e fundit. Pjesëtare tipike të këtij familjeje DB janë InfluxDB, Prometheus, KDB, TimescaleDB (ndërtuar mbi PostgreSQL), zgjidhjet nga Amazon. ClickHouse këtu gjithashtu mund të përdoret, dhe përdoret. Do të jap disa shembuj publik.
NjĂ« nga pionierĂ«t Ă«shtĂ« kompania CloudFlare (CDN-ofrues). Ata monitorojnĂ« CDN nĂ«pĂ«rmjet ClickHouse (DNS-kĂ«rkesat, HTTP-kĂ«rkesat) me njĂ« ngarkesĂ« tĂ« madhe â 6 milion ngjarje nĂ« sekondĂ«. TĂ« gjitha kalojnĂ« pĂ«rmes Kafka, dĂ«rgohet nĂ« ClickHouse, i cili ofron mundĂ«sinĂ« pĂ«r tĂ« parĂ« nĂ« kohĂ« reale dashboardet e ngjarjeve nĂ« sistem.
Comcast â njĂ« nga liderĂ«t e telekomunikacioneve nĂ« SHBA: internet, televizion digjital, telefonia. Ata krijuan njĂ« sistem tĂ« ngjashĂ«m menaxhimi CDN nĂ« kuadĂ«r tĂ« Open Source i projektit Apache Traffic Control pĂ«r tĂ« punuar me tĂ« dhĂ«nat e tyre tĂ« mĂ«dha. ClickHouse pĂ«rdoret si backend pĂ«r analizĂ«.
Percona kanë integruar ClickHouse brenda PMM, për të ruajtur monitorimin e të ndryshmeve MySQL.
KĂ«rkesat specifike
DB-ve time-series kanë kërkesat e tyre specifike.
- VĂ«nia e shpejtĂ« nga shumĂ« agjentĂ«.Duhet tĂ« vendosim shumĂ« shpejt tĂ« dhĂ«na nga shumĂ« rrjedha. ClickHouse bĂ«n mirĂ« kĂ«tĂ«, sepse tĂ« gjitha vĂ«niet e saj nuk janĂ« bllokuese. Ădo insert â Ă«shtĂ« njĂ« skedar i ri nĂ« disk, dhe mund tĂ« bĂ«hen bufere tĂ« vogla nĂ« njĂ« mĂ«nyrĂ« ose nĂ« njĂ« tjetĂ«r. NĂ« ClickHouse Ă«shtĂ« mĂ« mirĂ« tĂ« vendosni tĂ« dhĂ«nat nĂ« paketa tĂ« mĂ«dha, e jo njĂ« rresht tĂ« vetĂ«m.
- Skema e përshtatshme. Në time-series ne zakonisht nuk e dimë strukturën e të dhënave deri në fund. Mund të ndërtojmë një sistem monitorimi për një aplikacion të caktuar, por atëherë është e vështirë ta përdorim për një aplikacion tjetër. Për këtë nevojitet një skemë më fleksibile. ClickHouse, e cila lejon ta bëjë këtë, edhe pse kjo është një bazë e tipizuar rreptësisht.
- Ruajtja efikase dhe "harresimi" i tĂ« dhĂ«nave. Zakonisht nĂ« time-series njĂ« volum gjigand tĂ« dhĂ«nash, prandaj duhet tĂ« ruhet sa mĂ« efektivisht. PĂ«r shembull, InfluxDB kompresimi i mirĂ« â Ă«shtĂ« karakteristika e tij kryesore. Por pĂ«rveç ruajtjes, duhet edhe tĂ« jemi nĂ« gjendje tĂ« "harrojmĂ«" tĂ« dhĂ«nat e vjetra dhe tĂ« bĂ«jmĂ« ndonjĂ« downsampling â llogaritje automatike tĂ« agregateve.
- KĂ«rkesa tĂ« shpejta pĂ«r tĂ« dhĂ«nat e agreguara. NdonjĂ«herĂ« Ă«shtĂ« interesante tĂ« shohĂ«sh 5 minutat e fundit me saktĂ«si deri nĂ« milisekonda, por nĂ« tĂ« dhĂ«nat mujore, granulariteti minutor ose sekondar mund tĂ« mos jetĂ« i nevojshĂ«m â statistika e pĂ«rgjithshme Ă«shtĂ« e mjaftueshme. MbĂ«shtetje e tillĂ« Ă«shtĂ« e nevojshme, ndryshe kĂ«rkesa pĂ«r 3 muaj do tĂ« ekzekutohet shumĂ« ngadalĂ« edhe nĂ« ClickHouse.
- Kërkesat e tipit "pikën e fundit, deri në». Këto janë kërkesa tipike për time-series : shikojmë matjen ose gjendjen më të fundit të sistemit në një moment të caktuar t. Për DB nuk janë kërkesa shumë të këndshme, por duhet të mësojmë si t'i ekzekutojmë ato.
- "Lidhja" e serive temporale. time-series â Ă«shtĂ« njĂ« seri temporale. NĂ«se ka dy seria temporale, shpesh ato duhet tĂ« bashkohen dhe korelacionohen. Nuk Ă«shtĂ« e pĂ«rshtatshme ta bĂ«sh kĂ«tĂ« nĂ« tĂ« gjitha DB, veçanĂ«risht me seria temporale qĂ« nuk janĂ« tĂ« rregulluara: kĂ«tu â janĂ« disa kohĂ«, atje â disa tĂ« tjera. Mund tĂ« llogariten mesatarja, por ndoshta do tĂ« ketĂ« ende njĂ« boshllĂ«k, prandaj nuk Ă«shtĂ« e qartĂ«.
Le të shohim se si plotësohen këto kërkesa në ClickHouse.
Skema
NĂ« ClickHouse skema pĂ«r time-series mund tĂ« bĂ«het nĂ« mĂ«nyra tĂ« ndryshme, nĂ« varĂ«si tĂ« shkallĂ«s sĂ« rregullshmĂ«risĂ« sĂ« tĂ« dhĂ«nave. Mund tĂ« ndĂ«rtojmĂ« njĂ« sistem mbi tĂ« dhĂ«na tĂ« rregullta, kur e dimĂ« tĂ« gjitha metrikat paraprakisht. PĂ«r shembull, kĂ«shtu bĂ«ri CloudFlare me monitorimin CDN â Ă«shtĂ« njĂ« sistem i optimizuar mirĂ«. Mund tĂ« ndĂ«rtojmĂ« njĂ« sistem mĂ« tĂ« pĂ«rgjithshĂ«m, i cili monitoron tĂ« gjithĂ« infrastrukturĂ«n, shĂ«rbime tĂ« ndryshme. NĂ« rastin e tĂ« dhĂ«nave tĂ« pa-rregulluara, ne nuk e dimĂ« paraprakisht se çfarĂ« po monitorojmĂ« â dhe ndoshta ky Ă«shtĂ« rasti mĂ« i pĂ«rgjithshĂ«m.
TĂ« dhĂ«na tĂ« rregullta. Kolonat. Skema Ă«shtĂ« e thjeshtĂ« â kolona me llojet e nevojshme:
KRIJONI TABELĂN cpu (
created_date Date DEFAULT today(),
created_at DateTime DEFAULT now(),
time String,
tags_id UInt32,
/* bashkëngjiteni 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);Kjo është një tabelë e zakonshme që monitoron ndonjë aktivitet në ngarkesën e sistemit (user, sistem., i lirë, nice). E thjeshtë dhe e përshtatshme, por jo e çvendosur. Nëse duam një skemë më të përshtatshme, mund të përdorim array.
Të dhëna jo të rregullta. Array:
KRIJONI TABELĂN 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 ...
Struktura Nested â Ă«shtĂ« dy array: metrics.name dhe metrics.value. KĂ«tu mund tĂ« ruhen tĂ« dhĂ«na tĂ« tilla monitoruese tĂ« rastit si njĂ« array emrash dhe njĂ« array masash nĂ« çdo ngjarje. PĂ«r optimizim tĂ« mĂ«tejshĂ«m, nĂ« vend tĂ« njĂ« strukture tĂ« tillĂ« mund tĂ« bĂ«jmĂ« disa. P.sh., njĂ« pĂ«r filestream-vlerĂ«, njĂ« tjetĂ«r pĂ«r int-vlerĂ«, sepse int duhet tĂ« ruajmĂ« nĂ« mĂ«nyrĂ« mĂ« efikase.
Por, kjo strukturë është më e vështirë për t'u aksesuar. Do të duhet të përdorim një konstrukcion të veçantë, përmes funksioneve speciale për të nxjerrë fillimisht vlerat nga indeksi dhe pastaj nga array:
SELECT max(metrics.value[indexOf(metrics.name,'usage_user')]) FROM ...Por kjo akoma funksionon mjaft shpejt. Një mënyrë tjetër për të ruajtur të dhëna jo të rregullta është sipas rreshtave.
TĂ« dhĂ«na jo tĂ« rregullta. Rreshtat. NĂ« kĂ«tĂ« mĂ«nyrĂ« tradicionale pa array ruhen direkt emrat dhe vlerat. NĂ«se nga njĂ« pajisje vijnĂ« menjĂ«herĂ« 5,000 masa â krijohen 5,000 rreshta nĂ« DB:
KRIJONI TABELĂN 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 kĂ«tĂ« e bĂ«n â ai ka zgjerime speciale ClickHouse SQL. PĂ«r shembull, maxIf â Ă«shtĂ« njĂ« funksion special qĂ« llogarit maksimumin sipas metrike kur pĂ«rmbushet njĂ« kusht. Mund tĂ« shkruhen disa shprehje tĂ« tilla nĂ« njĂ« kĂ«rkesĂ« dhe menjĂ«herĂ« tĂ« llogaritet vlera pĂ«r disa metrika.
Le të krahasojmë tri qasje:
Këtu kam shtuar "Madhësia e të dhënave në disk" për një grup testues të dhënash. Në rastin e kolonave, kemi madhësinë më të vogël të të dhënave: kompresim maksimal, shpejtësi maksimale të kërkesave, por paguajmë me faktin se duhet ta regjistrojmë gjithçka menjëherë.
NĂ« rastin e skemave, gjĂ«rat janĂ« pak mĂ« keq. TĂ« dhĂ«nat pĂ«rsĂ«ri kompresohen mirĂ«, dhe mund tĂ« ruajmĂ« njĂ« skemĂ« tĂ« papĂ«rfillshme. Por ClickHouse â baza e tĂ« dhĂ«nave kolonale, dhe kur fillojmĂ« tĂ« ruajmĂ« gjithçka nĂ« skema, ajo transformohet nĂ« njĂ« varg, dhe paguajmĂ« pĂ«r fleksibilitetin me efikasitetin. PĂ«r çdo operacion do tĂ« duhet tĂ« lexojmĂ« tĂ« gjithĂ« skemĂ«n nĂ« memorie, dhe pastaj tĂ« gjejmĂ« elementin e nevojshĂ«m â dhe nĂ«se skema rritet, shpejtĂ«sia degradon.
Në një nga kompanitë që përdorin këtë qasje (për shembull, ), skemat ndahen në pjesë prej 128 elementësh. Të dhënat e disa mijëra metrike me një volum prej 200 TB të dhënash/në ditë ruhen në jo një, por në 10 ose 30 skema me logjikë të veçantë për ruajtje.
Qasja më e thjeshtë është me vargjet. Por të dhënat nuk kompresohen mirë, madhësia e tabelës rezulton e madhe, dhe kur kërkesat shkojnë përmes disa metrike, ClickHouse funksionon në mënyrë jo optimale.
Skema hibride
Le të supozojmë se kemi zgjedhur një skemë me skema. Por nëse e dimë se shumica e paneleve tona tregojnë vetëm metrike përdoruesi dhe sistemi, mund të materializojmë këto metrika nga skema në nivel tabelash në këtë mënyrë:
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);
Gjatë futjes ClickHouse automatikisht do t'i llogarisë. Në këtë mënyrë mund të kombinojmë të këndshmen me të dobishmen: skema është fleksibël dhe e përgjithshme, por kolonat më të përdorura i kemi nxjerrë. Vërej se kjo nuk kërkoi të ndryshonim futjen dhe ETL, i cili vazhdon të fusë skemat në tabelë. Ne thjesht bëmë ALTER TABLE, shtuam disa kolona dhe rezultoi një skemë hibride dhe më të shpejtë, e cila mund të fillojë të përdoret menjëherë.
Kodekët dhe kompresimi
Për time-series është e rëndësishme, sa mirë e paketoni të dhënat, sepse sasia e informacionit mund të jetë verye e madhe. Në ClickHouse ka një grup mjetesh për të arritur një efekt kompresimi 1:10, 1:20, e ndonjëherë më shumë. Kjo do të thotë se të dhënat e paketuara me një volum prej 1 TB në disk zënë 50-100 GB. Një madhësi më e vogël është e mirë, të dhënat mund të lexohen dhe përpunohen më shpejt.
Për të arritur një nivel të lartë kompresimi, ClickHouse pajisni me kodekët e mëposhtëm:
Shembuj të tabelës:
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);KĂ«tu pĂ«rcaktojmĂ« kodekun DoubleDelta nĂ« njĂ« rast, nĂ« rastin tjetĂ«r â Gorilla, dhe patjetĂ«r shtojmĂ« LZ4 kompresimin. Si rezultat, madhĂ«sia e tĂ« dhĂ«nave nĂ« disk zvogĂ«lohet shumĂ«:
Këtu është treguar se sa hapësirë zënë të njëjtat të dhëna, por me përdorimin e kodekëve dhe kompresioneve të ndryshme:
- në skedarin GZIP në disk;
- në ClickHouse pa kodekë, por me kompresimin ZSTD;
- në ClickHouse me kodekë dhe kompresim LZ4 dhe ZSTD.
E dukshme se tabelat me kodekë zënë shumë më pak hapësirë.
Madhësia ka rëndësi
Po aq e rëndësishme është lloji i duhur i të dhënave:
NĂ« tĂ« gjitha shembujt mĂ« sipĂ«r, unĂ« pĂ«rdora Float64. Por nĂ«se do tĂ« kishim zgjedhur Float32, atĂ«herĂ« do tĂ« ishte edhe mĂ« mirĂ«. Kjo u demonstruar mirĂ« nga ekipet nga Perkona nĂ« artikullin e lidhur mĂ« sipĂ«r. ĂshtĂ« e rĂ«ndĂ«sishme tĂ« pĂ«rdorĂ«sh llojin mĂ« tĂ« kompakt tĂ« mundshĂ«m, qĂ« i pĂ«rshtatet detyrĂ«s: madje nĂ« njĂ« masĂ« mĂ« tĂ« vogĂ«l pĂ«r madhĂ«sinĂ« nĂ« disk, sesa pĂ«r shpejtĂ«sinĂ« e pyetjeve. ClickHouse Ă«shtĂ« shumĂ« ndjesore ndaj kĂ«saj.
NĂ«se mund tĂ« pĂ«rdorni int32 nĂ« vend tĂ« int64, prisni njĂ« rritje pothuajse dyfish tĂ« performancĂ«s. TĂ« dhĂ«nat zĂ«nĂ« mĂ« pak memorie, dhe gjithĂ« "aritmetikĂ«n" e punĂ«s e bĂ«n shumĂ« mĂ« shpejt. ClickHouse brenda vetes â njĂ« sistem i tipizuar shumĂ« strikt, ai maksimalisht shfrytĂ«zon tĂ« gjitha mundĂ«sitĂ« qĂ« ofrojnĂ« sistemet moderne.
Agregimi dhe Materialized Views
Agregimi dhe pamjet e materializuara lejojnë krijimin e agregateve për raste të ndryshme:
PĂ«r shembull, mund tĂ« keni tĂ« dhĂ«na burimore tĂ« paagreguara, dhe mbi to mund tĂ« vendosni pamje tĂ« ndryshme materializuara me pĂ«rllogaritje automatike pĂ«rmes motorit tĂ« veçantĂ« SummingMergeTree (SMT). SMT â Ă«shtĂ« njĂ« strukturĂ« e veçantĂ« tĂ« dhĂ«nash qĂ« agregon automatikisht agregatet. TĂ« dhĂ«nat bruto futen nĂ« bazĂ«n e tĂ« dhĂ«nave, ato agregohen automatikisht dhe menjĂ«herĂ« mund tĂ« pĂ«rdoren pĂ«r panelat.
TTL â «e harrojmë» tĂ« dhĂ«nat e vjetra
Si mund të «harrojmë» të dhënat që nuk na nevojiten më? ClickHouse e bën këtë. Gjatë krijimit të tabelave mund të specifikoni TTL shprehje: për shembull, të dhënat minutore i ruajmë për një ditë, ato ditore për 30 ditë, ndërsa ato javore ose mujore nuk i prekim kurrë:
KRIJO TABELĂ aggr_by_minute
âŠ
TTL kohë + interval 1 ditë
KRIJO TABELĂ aggr_by_day
âŠ
TTL kohë + interval 30 ditë
KRIJO TABELĂ aggr_by_week
âŠ
/* pa TTL */
Multi-tier â ndajmĂ« tĂ« dhĂ«nat sipas disqeve
Duke zhvilluar këtë ide, të dhënat mund të ruhen në ClickHouse në vende të ndryshme. Supozoni se duam të ruajmë të dhënat e nxehta për javën e fundit në një SSDdisk lokal shumë të shpejtë, ndërsa të dhënat më historike i vendosim në një vend tjetër. Në ClickHouse tani është e mundur:
Mund të konfigurohet politika e ruajtjes (politika e ruajtjes) në mënyrë që ClickHouse të zhvendosë automatikisht të dhënat kur arrijmë disa kushte në një ruajtje tjetër.
Por nuk është vetëm kjo. Në nivelin e tabelës specifike mund të përcaktohen rregulla, kur pikërisht sipas kohës të dhënat kalojnë në ruajtje të ftohtë. Për shembull, për 7 ditë të dhënat qëndrojnë në një disk shumë të shpejtë, ndërsa gjithçka që është më e vjetër transferohet në një të ngadalshme. Kjo është e mirë pasi lejon sistemin të mbajë performancën maksimale, duke kontrolluar shpenzimet dhe pa ndjerë kosto për të dhënat e ftohta:
KRIJO TABELĂ
...
TTL data + INTERVAL 7 DITĂ TĂ VOLUMIT 'cold_volume',
data + INTERVAL 180 DITĂ FSHIJ
Mundësitë unike ClickHouse
Gati nĂ« çdo gjĂ« nĂ« ClickHouse ka kĂ«to «pikat e veçanta», por ato zbehen nga ekskluziviteti â ajo qĂ« nuk ndodhet nĂ« bazat e tjera tĂ« tĂ« dhĂ«nave. PĂ«r shembull, kĂ«tu janĂ« disa nga funksionet unike ClickHouse:
- Array. Në ClickHouse mbështetje shumë e mirë për array-t, si dhe mundësia për të kryer llogaritje komplekse mbi to.
- Strukturat agreguese të të dhënave. Kjo është një nga «karakteristikat e vrastarëve» ClickHouse. Pavarësisht se djemtë nga Yandex thonë se ne nuk duam të agregojmë të dhënat, të gjithë agregojnë në ClickHouse, sepse është e shpejtë dhe e përshtatshme.
- Përshtatjet e materializuara. Së bashku me strukturat agreguese të të dhënave, përshtatjet e materializuara lejojnë kryerjen e një real-time agregimi të lehtë.
- ClickHouse SQL. Kjo është një zgjerim i gjuhës SQL me disa karakteristika shtesë dhe ekskluzive që i ka vetëm në ClickHouse. Disa herë ishte si një zgjerim nga njëra anë, dhe nga ana tjetër një disavantazh. Tani, pothuajse të gjitha disavantazhet në krahasim me SQL 92 i kemi hequr, tani është vetëm një zgjerim.
- Lambda-shprehjet. A kanë ato ende ndonjë bazë të dhënash tjetër?
- ML-mbështetje. Kjo është e pranishme në baza të ndryshme të dhënash, në disa më mirë, në disa më keq.
- Kod i hapur. Ne mund të zgjerojmë ClickHouse bashkë. Tani në ClickHouse rreth 500 kontribues, dhe ky numër po rritet vazhdimisht.
KĂ«rkesat e zgjuara
Në ClickHouse ka shumë mënyra të ndryshme për të bërë të njëjtën gjë. Për shembull, mund të kthejmë vlerën e fundit nga tabela në tri mënyra të ndryshme për CPU (ka edhe një të katërt, por ai është edhe më ekzotik).
E para tregon se sa e lehtë është të bësh në ClickHouse kërkesa, kur dëshiron të kontrollosh se tuple është e pranishme në një nënkërkesë. Kjo është ajo që personalisht më ka munguar shumë në baza të tjera të dhënash. Nëse dëshiroj të krahasoj ndonjë gjë me një nënkërkesë, atëherë në baza të tjera të dhënash mund të krahasoj vetëm një skalar, dhe për disa kolona duhet të shkruaj JOIN. Në ClickHouse mund të përdorësh tuple:
SELECT *
FROM cpu
WHERE (tags_id, created_at) IN
(SELECT tags_id, max(created_at)
FROM cpu
GROUP BY tags_id)Mënyra e dytë bën të njëjtën gjë, por përdor funksionin agregat argMax:
SELECT
argMax(usage_user), created_at),
argMax(usage_system), created_at),
...
FROM cpu Në ClickHouse ka disa dhjetëra funksione agregate, dhe nëse përdoren kombinatorët, atëherë sipas ligjeve të kombinatorikës do të përfundojë me rreth një mijë. ArgMax -një nga funksionet që llogarit vlerën maksimale: kërkesa kthen vlerën usage_user, në të cilën arrihet vlera maksimale created_at:
SELECT now() as created_at,
cpu.*
FROM (SELECT DISTINCT tags_id from cpu) base
ASOF LEFT JOIN cpu USING (tags_id, created_at)
ASOF JOIN -"në lidhje" të rreshtave me kohë të ndryshme. Kjo është një funksion unik për bazat e dhënash, i cili gjendet gjithashtu vetëm në kdb+. Nëse ka dy seri kohore me kohë të ndryshme, ASOF JOIN lejon t'i zhvendosësh dhe t'i bashkosh ato në një kërkesë. Për çdo vlerë në një seri kohore gjendet vlera më e afërt në tjetrën, dhe ato kthehen në një rresht:
Funksionet analitike
Në standardin SQL-2003 mund të shkruhen kështu:
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;
Në ClickHouse kështu nuk mund të bëhet - ai nuk mbështet standardin SQL-2003 dhe ndoshta kurrë nuk do ta bëjë këtë. Në vend të kësaj në ClickHouse është e pranuar të shkruhet kështu:
Premtova lambda â ja ato!
Kjo Ă«shtĂ« njĂ« ekuivalente e njĂ« kĂ«rkese analitike nĂ« standardin SQL-2003: ajo llogarit diferencĂ«n mes dy timestamp, duration, numri rendor â gjithçka qĂ« zakonisht ne e konsiderojmĂ« funksione analitike. NĂ« ClickHouse ne i konsiderojmĂ« pĂ«rmes arrays: fillimisht e thellojmĂ« tĂ« dhĂ«nat nĂ« njĂ« array, pastaj nĂ« array bĂ«jmĂ« gjithçka qĂ« duam, dhe mĂ« pas e kthyejmĂ« pĂ«rsĂ«ri. Kjo nuk Ă«shtĂ« shumĂ« e pĂ«rshtatshme, kĂ«rkon dashuri pĂ«r programimin funksional, si minimum, por Ă«shtĂ« shumĂ« fleksibĂ«l.
Funksione speciale
PĂ«r mĂ« tepĂ«r, nĂ« ClickHouse ka shumĂ« funksione tĂ« specializuara. PĂ«r shembull, si tĂ« pĂ«rcaktojmĂ« se sa sesione kalojnĂ« nĂ« tĂ« njĂ«jtĂ«n kohĂ«? NjĂ« detyrĂ« tipike pĂ«r monitorimin â tĂ« pĂ«rcaktojmĂ« ngarkesĂ«n maksimale nga njĂ« kĂ«rkesĂ«. NĂ« ClickHouse ka njĂ« funksion tĂ« veçantĂ« pĂ«r kĂ«tĂ« qĂ«llim:
Në të vërtetë, për shumë qëllime në ClickHouse ka funksione speciale:
- runningDifference, runningAccumulate, neighbor;
- sumMap(key, value);
- timeSeriesGroupSum(uid, timestamp, value);
- timeSeriesGroupRateSum(uid, timestamp, value);
- skewPop, skewSamp, kurtPop, kurtSamp;
- WITH FILL / WITH TIES;
- simpleLinearRegression, stochasticLinearRegression.
Ky nuk është një listë e plotë e funksioneve, gjithsej ka 500-600. Një sugjerim: të gjitha funksionet në ClickHouse janë në tabelën sistematike (jo të gjitha janë të dokumentuara, por të gjitha janë interesante):
select * from system.functions order by nameClickHouse vetĂ« pĂ«rmban shumĂ« informacion nĂ« lidhje me veten, pĂ«rfshirĂ« log tables, query_log, logun e gjurmimit, logun e operacioneve me blloqe tĂ« tĂ« dhĂ«nave (part_log), logun e metrikave, dhe logun sistemor, i cili zakonisht shkruan nĂ« disk. Logu i metrikave Ă«shtĂ« time-series nĂ« ClickHouse nĂ« tĂ« vĂ«rtetĂ« ClickHouse: DB vetĂ« mund tĂ« luajĂ« rolin e saj time-series tĂ« bazave tĂ« tĂ« dhĂ«nave, duke ângrĂ«nĂ«â veten.
Kjo Ă«shtĂ« gjithashtu njĂ« gjĂ« unikĂ« â pasi bĂ«jmĂ« punĂ«n mirĂ« pĂ«r time-series, pse nuk mund tĂ« ruajmĂ« gjithçka qĂ« na nevojitet brenda vetes? Nuk na nevojitet Prometheus, ne ruajmĂ« gjithçka brenda. Kemi lidhur NĂ«se tashmĂ« e dini se çfarĂ« Ă«shtĂ« analiza e grupeve dhe se si ta bĂ«ni nĂ« SQL, kaloni menjĂ«herĂ« nĂ« seksionin e fundit. dhe monitorojmĂ« veten. SidoqoftĂ«, nĂ«se ClickHouse ra, atĂ«herĂ« ne nuk do ta shohim, â pse, â prandaj zakonisht nuk bĂ«het kĂ«shtu.
Një klaster i madh ose shumë të vogla ClickHouse
ĂfarĂ« Ă«shtĂ« mĂ« mirĂ« â njĂ« klaster i madh ose shumĂ« tĂ« vogla ClickHouse? Qasje tradicionale pĂ«r DWH â Ă«shtĂ« njĂ« klaster i madh, nĂ« tĂ« cilin ndahen skemat pĂ«r çdo aplikacion. Shkuam te administratori i DB â na jepni njĂ« skemĂ«, dhe na e dhanĂ«:
Në ClickHouse mund ta bëjmë ndryshe. Mund t'i japim çdo aplikacioni skemën e tij ClickHouse:
Nuk na nevojitet më një DWH monstruoz dhe adminstratorë të pakënaqur. Mund t'i japim çdo aplikacioni skemën e tij ClickHouse, dhe zhvilluesi mund ta bëjë vetë, pasi ClickHouse është shumë e thjeshtë për t'u instaluar dhe nuk kërkon administrim të komplikuar:
Por nëse kemi shumë ClickHouse, dhe duhet ta instalojmë shpesh, atëherë duam ta automatizojmë këtë proces. Për këtë mund të përdorim, për shembull, Kubernetes dhe clickhouse-operatorin. Në Kubernetes ClickHouse mund të instalohet "me një klik": mund të klikoj një buton, të nis një manifest dhe baza është gati. Mund të krijoj menjëherë një skemë, të filloj të ngarkoj metrikat, dhe pas 5 minutash kam një tabllo të gatshme Nëse tashmë e dini se çfarë është analiza e grupeve dhe se si ta bëni në SQL, kaloni menjëherë në seksionin e fundit.. Aq e thjeshtë është!
ĂfarĂ« nĂ« pĂ«rfundim?
Pra, ClickHouse â kjo Ă«shtĂ«:
- Shpejt. Kjo është e njohur për të gjithë.
- Thjesht. Pak e diskutueshme, por unë mendoj se është e vështirë në mësim, e lehtë në betejë. Nëse kupton se si ClickHouse funksionon, pastaj gjithçka është shumë e thjeshtë.
- Universale. Ai përshtatet për skenarë të ndryshëm: DWH, Kohë Njësive, Ruajtja e Logëve. Por kjo nuk është baza e të dhënave OLTP, prandaj mos u përpiqni të bëni atje inserte të shkurtra dhe lexime. Interesant
- . Ndoshta ai që punon me, ka përjetuar shumë minuta interesante në një kuptim të mirë dhe të keq. Për shembull, doli një version i ri, gjithçka ndaloi së funksionuari. Ose kur keni luftuar me një problem për dy ditë, por pas një pyetjeje në Telegram, problemi u zgjidh për dy minuta. Ose si në konferencë në prezantimin e Leosh Milovidov, screenshot-i nga ClickHouseshkaktoi ndalimin e transmetimit ClickHouse . Këto lloj gjërash ndodhin vazhdimisht dhe e bëjnë jetën tonë me HighLoad++të gjallë dhe interesante! ClickHouse Prezantimin mund ta shihni
Takimi i pritur i zhvilluesve të sistemeve me ngarkesë të lartë në .
do të zhvillohet më 9 dhe 10 nëntor në Skolkovo. Më në fund do të jetë një konferencë offline (pavarësisht nga të gjitha masat e sigurisë), pasi energjia e HighLoad++ nuk mund të paketizohet në online. Për konferencën ne gjejmë dhe ju tregojmë raste të mundësive maksimale të teknologjive: HighLoad++ ka qenë, është dhe do të jetë vendi i vetëm ku mund të mësoni brenda dy ditësh se si janë ndërtuar Facebook, Yandex, VKontakte, Google dhe Amazon.
Duke mbajtur takimet tona pa ndërprerje që nga viti 2007, këtë vit do të takohemi për herë të 14-të. Gjatë kësaj kohe, konferenca është rritur 10 herë, vitin e kaluar ngjarja kryesore e industrisë mbajti 3339 pjesëmarrës, 165 folës të prezantimeve dhe takimeve, ndërsa në të njëjtën kohë u mbajtën 16 trajekta.
Vitin e kaluar kishim 20 autobusa, 5280 litra çaji dhe kafeje, 1650 litra lĂ«ng frutash dhe 10200 shishe ujĂ«. Po ashtu 2640 kilogram ushqim, 16,000 pjatat dhe 25,000 gota. PĂ«rveç kĂ«saj, me paratĂ« e fituara nga riciklimi i letrĂ«s, mbollĂ«m 100 fidanishte dushi đ
Biletat mund tĂ« blihen, merrni lajme rreth konferencĂ«s â , merrni lajme rreth konferencĂ«s â , dhe pĂ«r tĂ« biseduar â nĂ« tĂ« gjitha rrjetet sociale: , , dhe .
Burimi: habr.com
