Tre vjetĂ« mĂ« parĂ«, Viktor Taranavskiy dhe Aleksey Milovidov nga Yandex ishin nĂ« skenĂ« HighLoad++ , sa i mirĂ« Ă«shtĂ« ClickHouse dhe si nuk ngadalĂ«sohet. NdĂ«rsa nĂ« skenĂ«n pĂ«rballĂ« ishte AleksandĂ«r Zaytsev me rreth kalimit nĂ« ClickHouse nga njĂ« DB analitike tjetĂ«r dhe pĂ«rfundimi se ClickHouse, sigurisht, Ă«shtĂ« e mirĂ«, por jo shumĂ« e pĂ«rshtatshme. Kur nĂ« vitin 2016 kompania LifeStreet, nĂ« tĂ« cilĂ«n Aleksandri atĂ«herĂ« punonte, po kalonte njĂ« sistem analitik multi-petabajt nĂ« ClickHouse, kjo ishte njĂ« "rrugĂ« me tulla tĂ« verdha", e mbushur me rreziqe tĂ« panjohuraâ ClickHouse atĂ«herĂ« dukej si njĂ« minĂ«.
Tre vjet mĂ« vonĂ« ClickHouse ka ardhur shumĂ« mĂ« mirĂ«â gjatĂ« kĂ«saj kohe Aleksandri themeloi kompaninĂ« Altinity, e cila jo vetĂ«m qĂ« ndihmon nĂ« kalimin nĂ« ClickHouse disa projekte, por gjithashtu pĂ«rmirĂ«son produktin vetĂ« sĂ« bashku me kolegĂ«t nga Yandex. TashmĂ« ClickHouse nuk Ă«shtĂ« ende njĂ« shĂ«titje pa ndarje, por gjithashtu nuk Ă«shtĂ« mĂ« njĂ« minĂ«.
Aleksandri merret me sisteme të shpërndara që nga viti 2003, duke zhvilluar projekte të mëdha mbi MySQL, Oracle dhe Vertica. Në konferencën e kaluar HighLoad++ 2019 Aleksandri, një nga pionierët e përdorimit ClickHouse, tregoi se çfarë përfaqëson tani kjo DB. Ne do të mësojmë për tiparet kryesore ClickHouse: çfarë e dallon atë nga sistemet e tjera dhe në cilat raste është më efektive ta përdorim. Në shembuj, do të shqyrtojmë praktikat e reja dhe të provuara nga projektet për ndërtimin e sistemeve mbi ClickHouse.
Retrospektivë: çfarë ndodhi 3 vjet më parë
Tre vjet më parë ne po kalonim kompaninë LifeStreet në ClickHouse nga një bazë të dhënash analitike tjetër, dhe migraimi i analitikës së rrjetit reklamues dukej kështu:
- Qershor 2016. Në OpenSource ka dalë ClickHouse dhe filloi projekti ynë;
- Gusht. Proof Of Concept: një rrjet i madh reklamues, infrastruktura dhe 200-300 terabajt të dhënash;
- Tetor. Të dhënat e para në prodhim;
- TĂ« DhjetĂ«. Ngarkesa e plotĂ« produktiveâ 10-50 miliard ngjarjesh nĂ« ditĂ«.
- Qershor 2017. Kalimi i suksesshëm i përdoruesve në ClickHouse, 2.5 petabajt të dhënash në një klasë prej 60 serverësh.
Gjatë procesit të migrimit, kuptimi se ClickHouse është një sistem i mirë, me të cilin është kënaqësi të punosh, por është një projekt i brendshëm i kompanisë Yandex. Prandaj ka nuanca: Yandex fillimisht do të merret me porositë e veta të brendshme dhe vetëm pastaj me komunitetin dhe nevojat e përdoruesve të jashtëm, dhe ClickHouse atëherë nuk arrinte në nivelin e ndërmarrjes në shumë fusha funksionale. Prandaj, në mars 2017 ne themeluam kompaninë Altinity, për ta bërë ClickHouse edhe më të shpejtë dhe më të lehtë jo vetëm për Yandex, por edhe për përdoruesit e tjerë. Dhe tani ne:
- Trajmë dhe ndihmojmë në ndërtimin e zgjidhjeve mbi ClickHouse në mënyrë që klientët të mos bëjnë gabime, dhe që zgjidhja të funksionojë në përfundim;
- Sigurojmë mbështetje 24/7 ClickHouse-instalimeve;
- Zhvillojmë projekte të ekosistemit tonë;
- Aktivisht kontributojmë në vetë ClickHouse, duke iu përgjigjur kërkesave të përdoruesve, të cilët duan të shohin disa funksionalitete.
Dhe natyrisht, ne ndihmojmë në kalimin në ClickHouse me MySQL, Vertica, Oracle, Greenplum, Redshift dhe sisteme të tjera. Ne kemi marrë pjesë në kalime të ndryshme dhe të gjitha janë e suksesshme.
Pse të kalosh në ClickHouse
Nuk ngadalëson! Kjo është arsyeja kryesore. ClickHouse - është një bazë të dhënash shumë e shpejtë për skenarë të ndryshëm:
Citatet e rastësishme nga njerëzit që punojnë gjatë me ClickHouse.
Shkallëzueshmëria. Në një DB tjetër, mund të arrijmë një performancë të mirë në një server, por ClickHouse mund të shkallëzohet jo vetëm vertikalisht, por edhe horizontalisht, thjesht duke shtuar serverë. Gjithçka nuk funksionon aq smoothly, sa do të donim, por funksionon. Mund të rritet sistemi me rritjen e biznesit. Kjo është e rëndësishme, sepse nuk jemi të kufizuar në zgjidhje tani dhe gjithmonë ka potencial për zhvillim.
Portabilitet. Nuk ka lidhje me diçka të vetme. P.sh., me Amazon Redshift është e vështirë të kalosh diku. Por ClickHouse mund të instalohet në laptopin tënd, server, ta ndajë në cloud, të shkojë në Kubernetes - nuk ka kufizime për eksploatimin e infrastrukturës. Kjo është e përshtatshme për të gjithë, dhe kjo është një avantazh i madh që shumë DB të tjera të ngjashme nuk e kanë.
Fleksibiliteti. ClickHouse nuk ndalet nĂ« diçka tĂ« vetme, p.sh., nĂ« Yandex.Metrica, por zhvillohet dhe pĂ«rdoret nĂ« njĂ« numĂ«r gjithnjĂ« e mĂ« tĂ« madh projektesh dhe industrish. Mund tĂ« zgjerohet duke shtuar mundĂ«si tĂ« reja pĂ«r zgjidhjen e detyrave tĂ« reja. P.sh., besohet se ruajtja e logeve nĂ« DBâ Ă«shtĂ« njĂ« mospĂ«rputhje, prandaj pĂ«r kĂ«tĂ« Ă«shtĂ« menduar Elasticsearch. Por, falĂ« fleksibilitetit ClickHouse, mund tĂ« ruajmĂ« loget aty, dhe shpesh Ă«shtĂ« madje mĂ« mirĂ« se nĂ« Elasticsearch â nĂ« ClickHouse pĂ«r kĂ«tĂ« kĂ«rkohet 10 herĂ« mĂ« pak harduer.
Falësisht Open Source. Nuk ka nevojë të paguash për asgjë. Nuk ka nevojë të bisedosh për lejen për të vendosur sistemin në laptopin tënd ose server. Nuk ka pagesa të fshehta. Në të njëjtën kohë, asnjë teknologji tjetër të hapur burimi të bazave të dhënash nuk mund të konkurrojë me shpejtësinë e ClickHouse. MySQL, MariaDB, Greenplum - të gjithë ata janë shumë më të ngadalshëm.
Komuniteti, energjia dhe argëtim. Ka ClickHouse një komunitet të shkëlqyer: meetups, biseda dhe Aleksey Milovidov, i cili na ngarkon të gjithëve me energjinë dhe optimizmin e tij.
Kalimi në ClickHouse
Për të kaluar në ClickHouse nga diçka, ju nevojiten vetëm tre gjëra:
- Të kuptoni kufijtë ClickHouse dhe për çfarë nuk i përshtatet.
- Të shfrytëzoni avantazhet e teknologjisë dhe forcat e saj më të mëdha.
- Të eksperimentoni. Edhe duke e kuptuar si funksionon ClickHouse, nuk është gjithmonë e mundur të parashikohet se kur është më i shpejtë, kur më i ngadalshëm, kur më i mirë, e kur më i keq. Prandaj provoni.
Problemi i migrimit
Ka vetëm një "por": nëse po migroni nga ClickHouse nga diçka tjetër, zakonisht diçka shkon keq. Jemi të zakonshëm me disa praktika dhe gjëra që funksionojnë në DB-në tonë të preferuar. Për shembull, çdo person që punon me SQ-bazat e të dhënave, i konsideron të domosdoshme këtë grup funksionesh:
- transaksione;
- kushtet;
- konstistenca;
- indekset;
- UPDATE/DELETE;
- NULLs;
- milisekonda;
- konvertimet automatike;
- bashkime të shumta;
- particionet e rastit;
- mjetet e menaxhimit të klasterit.
Grupi është i domosdoshëm, por tre vjet më parë në ClickHouse nuk ekzistonte asnjë nga këto funksione! Tani nga ato që nuk janë realizuar ka mbetur më pak se gjysma: transaksione, kushtet, Konsistenca, milisekonda dhe konvertimi i tipit.
Dhe e rĂ«ndĂ«sishmja â ka disa praktika standarde dhe qasje qĂ« nuk funksionojnĂ« ose funksionojnĂ« ndryshe nga çâmĂ«sojmĂ« ne. Gjithçka qĂ« shfaqet nĂ« ClickHouse , i pĂ«rket " ClickHouseClickHouse way", dmth. funksionet ndryshojnĂ« nga tĂ« tjerat Baza tĂ« tĂ« dhĂ«nave. PĂ«r shembull:Indekset nuk zgjidhen, por kalohen.
- nuk janë sinkrone, por asinkrone.
- UPDATE/DELETE Bashkimet e shumta ekzistojnë, por plani i kërkesës mungon. Si realizohen ato pastaj, njerëzit nga bota e Baza të të dhënave nuk e kuptojnë shumë.
- Scenarë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" ("E pamundur efektiviteti i matematikĂ«s nĂ« shkencat natyrore") pĂ«r faktin se bota pĂ«rreth na pĂ«rshkruhet mirĂ« nga ligjet matematikore. Matematika â njĂ« shkencĂ« abstrakte, dhe ligjet fizike, tĂ« shprehura nĂ« formĂ«n matematikore, nuk janĂ« triviale, dhetheksoi se kjo Ă«shtĂ« shumĂ« e çuditshme. shkroi njĂ« artikull " Sipas mendimit tim,
â njĂ« çudi e tillĂ«. Duke e riformuluar Wigner, mund tĂ« thuhet kĂ«shtu: e habitshme efikasiteti i pamundur ClickHouse nĂ« aplikacione analitike tĂ« ndryshme! ClickHouse PĂ«r shembull, tĂ« marrim
Real-Time Data Warehouse , nĂ« tĂ« cilin tĂ« dhĂ«nat merren pothuajse vazhdimisht. Ne duam tĂ« marrim nga ai kĂ«rkesa me vonesĂ« sekondore. Ju lutemi â pĂ«rdorim, sepse pĂ«r kĂ«tĂ« skenar Ă«shtĂ« projektuar. ClickHousepikĂ«risht kĂ«shtu pĂ«rdoret jo vetĂ«m nĂ« ueb, por edhe nĂ« analitikĂ«n marketingut dhe financave, ClickHouse AdTech , si dhe nĂ«detectio n e mashtrimit. NĂ«Real-time Data Warehouse pĂ«rdoret njĂ« strukturĂ« e ndĂ«rlikuar e tipit "yll" ose "gjak", shumĂ« tabela me (ndonjĂ«herĂ« tĂ« shumta), dhe tĂ« dhĂ«nat zakonisht ruhen dhe ndryshojnĂ« nĂ« disa sisteme. JOIN TĂ« marrim njĂ« tjetĂ«r skenar â
Time Series : monitorimi i pajisjeve, rrjeteve, statistika e pĂ«rdorimit, interneti i gjĂ«rave. KĂ«tu ne pĂ«rballemi me ngjarje mjaft tĂ« thjeshta tĂ« renditura me kohĂ«.pĂ«r kĂ«tĂ« nuk Ă«shtĂ« projektuar fillimisht, por ka treguar rezultate tĂ« mira, kĂ«shtu qĂ« kompanitĂ« e mĂ«dha e pĂ«rdorin ClickHouse si njĂ« depo pĂ«r informacionin e monitorimit. PĂ«r tĂ« studiuar, nĂ«se ClickHouse pĂ«rshtatet pĂ«r time-series, ne kemi bĂ«rĂ« njĂ« benchmark mbi qasjen dhe rezultatet ClickHouse pĂ«r seritĂ« e kohĂ«s, ne bĂ«mĂ« njĂ« benchmark tĂ« bazuar nĂ« qasjen dhe rezultatet InfluxDB dhe TimescaleDB â bazat e tĂ« dhĂ«nave tĂ« specializuara time-series. databases. , qĂ« ClickHouse, madje pa optimizim pĂ«r kĂ«to detyra, fiton dhe nĂ« fushĂ«n e huaj:
NĂ« time-series. zakonisht pĂ«rdoret njĂ« tabelĂ« e ngushtĂ« â disa kolona tĂ« vogla. Nga monitorimi mund tĂ« vijnĂ« shumĂ« tĂ« dhĂ«na â miliona regjistrime nĂ« sekondĂ« â dhe zakonisht ato vijnĂ« me inserts tĂ« vogla (trafik nĂ« kohĂ« reale streaming). Prandaj, ne kemi nevojĂ« pĂ«r njĂ« skenar tjetĂ«r tĂ« insertit, dhe vetĂ« kĂ«rkesat â me disa specifika tĂ« saj.
Log Management. Grumbullimi i log-eve në DB zakonisht është i keq, por në ClickHouse kjo mund të bëhet me disa komente, siç përshkruhet më lart. Shumë kompani përdorin ClickHouse pikërisht për këtë. Në këtë rast përdoret një tabelë e gjerë e sheshtë, ku ne ruajmë log-et tërësisht (për shembull, në formën JSON), ose i presim në pjesë. Të dhënat zakonisht merren me grupe të mëdha (skedarëve), dhe ne e kërkojmë sipas ndonjë fushe.
Për secilën nga këto funksione zakonisht përdoren Baza të të dhënave të specializuara. ClickHouse njëra mund ta bëjë të gjitha këto dhe aq mirë sa e tejkalon atë në performancë. Le të shqyrtojmë tani time-series. skenerin dhe si të "përgatitni" ClickHouse për këtë skenar.
Time-Series
Aktualisht ky Ă«shtĂ« skenari kryesor, pĂ«r tĂ« cilin ClickHouse njihet si zgjidhja standarte. Time-series â Ă«shtĂ« njĂ« grup ngjarjesh tĂ« renditura me kohĂ«, qĂ« pĂ«rfaqĂ«sojnĂ« ndryshimet e njĂ« procesi gjatĂ« kohĂ«s. PĂ«r shembull, mund tĂ« jetĂ« frekuenca e rrahjeve tĂ« zemrĂ«s pĂ«r ditĂ« ose numri i proceseve nĂ« sistem. Ădo gjĂ« qĂ« jep tik-tak tĂ« kohĂ«s me disa matje â Ă«shtĂ« pĂ«rdorimi i time-series.:
Ngjarjet e tilla vijnë kryesisht nga monitorimi. Kjo mund të përfshijë jo vetëm monitorimin e uebit, por edhe të pajisjeve reale: automjeteve, sistemeve industriale, IoT, prodhimi ose taksitë pa pilot, në bagazhin e të cilëve Yandex tashmë po vendos ClickHouse-server.
PĂ«r shembull, ka kompani qĂ« mbledhin tĂ« dhĂ«na nga anijet. Ădo disa sekonda sensorĂ«t e njĂ« kontejneri dĂ«rgojnĂ« qindra matje tĂ« ndryshme. InxhinierĂ«t i studiojnĂ« ato, ndĂ«rtuan modele dhe pĂ«rpiqen tĂ« kuptojnĂ« sa eficient pĂ«rdoret anija, sepse njĂ« kontejner nuk duhet tĂ« qĂ«ndrojĂ« as njĂ« sekondĂ« pa punĂ«. Ădo ndalim Ă«shtĂ« humbje parash, prandaj Ă«shtĂ« e rĂ«ndĂ«sishme tĂ« parashikohet rruge qĂ« ndalesat tĂ« jenĂ« minimale.
Aktualisht ka një rritje të DB-ve të specializuara, të cilat masin time-series.. Në faqen DB-Engines siç janë klasifikuar në mënyra të ndryshme bazat e të dhënave, dhe ato mund të shikohen sipas llojeve:
Lloji më në rritje të shpejtë është time-seriess. Gjithashtu po rriten DB-të grafike, por time-seriess po rriten më shpejt gjatë viteve të fundit. Përfaqësues tipikë të kësaj familjeje të DB-ve janë InfluxDB, Prometheus, KDB, TimescaleDB (e 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 pioniere Ă«shtĂ« kompania CloudFlare (CDN-ofrues). Ata monitorojnĂ« CDN pĂ«rmes ClickHouse (DNS-kĂ«rkesat, HTTP-kĂ«rkesat) me njĂ« ngarkesĂ« tĂ« madhe â 6 milion ngjarje nĂ« sekondĂ«. TĂ« gjitha kalojnĂ« pĂ«rmes Kafka, dĂ«rguar nĂ« ClickHouse, e cila ofron mundĂ«sinĂ« pĂ«r tĂ« parĂ« nĂ« kohĂ« reale tabela tĂ« ngjarjeve nĂ« sistem.
Comcast është një nga liderët e telekomunikacioneve në SHBA: interneti, televizionin digjital, telefoninë. Ata krijuan një sistem të ngjashëm menaxhimi CDN në kuadër të Open Source projekti Apache Traffic Control për punën me të dhënat e tyre të mëdha. ClickHouse përdoret si backend për analitikë.
Percona ata e ndërtuan ClickHouse brenda PMM, për të ruajtur monitorimin e ndryshëm MySQL.
KĂ«rkesat specifike
Për databazat time-series ka kërkesa specifike.
- NjĂ« futje e shpejtĂ« nga shumĂ« agjentĂ«.Duhet tĂ« futim tĂ« dhĂ«na shumĂ« shpejt nga shumĂ« rrjedha. ClickHouse e bĂ«n kĂ«tĂ« mirĂ«, sepse tĂ« gjitha futjet janĂ« qĂ« nuk bllokojnĂ«. Ădo insert ka tĂ« bĂ«jĂ« me njĂ« skedĂ« tĂ« re nĂ« disk, dhe futjet e vogla mund tĂ« bufrizohen nĂ« njĂ« mĂ«nyrĂ« ose njĂ« tjetĂ«r. NĂ« ClickHouse Ă«shtĂ« mĂ« mirĂ« tĂ« futni tĂ« dhĂ«nat me grupe tĂ« mĂ«dha, e jo rresht pas rreshti.
- Skema fleksibël. Në time-series. 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ë kërkohet një skemë më fleksibël. ClickHouse, që e lejon këtë të bëhet, edhe pse është një bazë e tipizuar strikt.
- Ruajtja efektive dhe "harresa" e tĂ« dhĂ«nave. Zakonisht nĂ« time-series. volume tĂ« mĂ«dha tĂ« dhĂ«nash, prandaj ato duhet tĂ« ruhet sa mĂ« efektivisht. PĂ«r shembull, e InfluxDB kompresimi i mirĂ« â Ă«shtĂ« veçoria e tij kryesore. Por pĂ«rveç ruajtjes, duhet tĂ« dimĂ« gjithashtu si tĂ« "harrojmĂ«" tĂ« dhĂ«nat e vjetra dhe tĂ« bĂ«jmĂ« ndonjĂ« downsampling â llogaritje automatike tĂ« agregateve.
- KĂ«rkesat e shpejta tĂ« tĂ« dhĂ«nave tĂ« agreguara. Disa herĂ« Ă«shtĂ« interesante tĂ« shikoni 5 minutat e fundit me saktĂ«si deri nĂ« milisekondĂ«, por pĂ«r tĂ« dhĂ«nat mujore, granulariteti minutor ose sekondar mund tĂ« mos jetĂ« e nevojshme â statistika e pĂ«rgjithshme Ă«shtĂ« e mjaftueshme. MbĂ«shtetje e tillĂ« Ă«shtĂ« e nevojshme, ndryshe kĂ«rkesa pĂ«r 3 muaj do tĂ« realizohet shumĂ« ngadalĂ«, edhe nĂ« ClickHouse.
- Kërkesat e tipit "last point, as of». Këto janë përcaktimin e time-series. kërkesat: shohim matjen e fundit ose gjendjen e sistemit në një moment të caktuar t. Për DB-në këto nuk janë kërkesa shumë të këndshme, por ato duhet të mund të realizohen gjithashtu.
- "Bashkimi" i serive kohore. Time-series â Ă«shtĂ« njĂ« seri e kohore. NĂ«se ka dy seri kohore, shpesh nevojitet t'i bashkojmĂ« dhe t'i korrelacionojmĂ« ato. Jo nĂ« tĂ« gjitha DB-tĂ« Ă«shtĂ« e lehtĂ« tĂ« bĂ«het kjo, veçanĂ«risht me seritĂ« kohore qĂ« nuk janĂ« tĂ« rregullta: kĂ«tu â njĂ« sĂ«rĂ« pĂ«rkohĂ«sish, atje â tjetra. Mund tĂ« llogariten mesatarĂ«t, por ndoshta gjithsesi do tĂ« ketĂ« njĂ« vend bosh, kĂ«shtu qĂ« nuk Ă«shtĂ« e qartĂ«.
Le të shohim se si këto kërkesa realizohen në ClickHouse.
Skema
NĂ« ClickHouse njĂ« skemĂ« pĂ«r time-series. mund tĂ« bĂ«het nĂ« mĂ«nyra tĂ« ndryshme, nĂ« varĂ«si tĂ« shkallĂ«s sĂ« rregullt tĂ« tĂ« dhĂ«nave. Mund tĂ« ndĂ«rtojmĂ« njĂ« sistem nĂ« tĂ« dhĂ«na tĂ« rregullta, kur e dimĂ« tĂ« gjitha metrikat paraprakisht. PĂ«r shembull, kĂ«shtu bĂ«ri CloudFlare me monitorimin CDN â kjo Ă«shtĂ« njĂ« sistem i optimizuar mirĂ«. Mund tĂ« ndĂ«rtojmĂ« njĂ« sistem mĂ« tĂ« pĂ«rgjithshĂ«m, i cili monitoron gjithĂ« infrastrukturĂ«n, shĂ«rbime tĂ« ndryshme. NĂ« rastet e tĂ« dhĂ«nave jo tĂ« rregullta, ne nuk e dimĂ« paraprakisht se çfarĂ« po monitorojmĂ« â dhe ndoshta, ky Ă«shtĂ« rasti mĂ« i pĂ«rgjithshĂ«m.
TĂ« dhĂ«nat e rregullta. Kolonat. Skema e thjeshtĂ« â kolonat me llojet e nevojshme:
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);Kjo është një tabelë e zakonshme që monitoron një aktivitet të caktuar për ngarkesën e sistemit (përdorues, system, idle, nice). E thjeshtë dhe e përshtatshme, por jo fleksibile. Nëse duam një skemë më fleksibile, mund të përdorim seria.
Të dhëna jo të rregullta. Seritë:
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 ...
Struktura Nested â janĂ« dy seria: metrics.name dhe metrics.value. KĂ«tu mund tĂ« ruhen tĂ« dhĂ«na tĂ« tilla monitoruese si seria tĂ« emrave dhe seria tĂ« vlerave nĂ« secilin ngjarje. PĂ«r njĂ« optimizim tĂ« mĂ«tejshĂ«m, nĂ« vend tĂ« njĂ« strukture tĂ« tillĂ« mund tĂ« krijojmĂ« disa. PĂ«r shembull, njĂ« â pĂ«r float-vlerĂ«n, njĂ« tjetĂ«r â pĂ«r int-vlerĂ«n, sepse int duam tĂ« ruajmĂ« mĂ« efektivisht.
Por me këtë strukturë është më e vështirë të aksesosh. Do të duhet të përdorësh një strukturë speciale, përmes funksioneve speciale për të nxjerrë vlerat fillimisht nga indeksi, e më pas nga seria:
SELECT max(metrics.value[indexOf(metrics.name,'usage_user')]) FROM ...Por kjo funksionon ende mjaft shpejt. NjĂ« mĂ«nyrĂ« tjetĂ«r pĂ«r tĂ« ruajtur tĂ« dhĂ«nat jo tĂ« rregullta â rreshtat.
TĂ« dhĂ«na jo tĂ« rregullta. Rreshtat. NĂ« kĂ«tĂ« mĂ«nyrĂ« tradicionale, pa seria ruhen menjĂ«herĂ« emrat dhe vlerat. NĂ«se nga njĂ« pajisje vijnĂ« menjĂ«herĂ« 5,000 matje â gjenerohen 5,000 rreshta nĂ« DB:
CREATE TABLE cpu_rlc (
created_date Date,
created_at DateTime,
time String,
tags_id UInt32,
metric_name LowCardinality(String),
metric_value Float64
) ENGINE = MergeTree(created_date, (metric_name, tags_id, created_at), 8192);
SELECT
maxIf(metric_value, metric_name = 'usage_user'),
...
FROM cpu_r
WHERE metric_name IN ('usage_user', ...)
ClickHouse kjo e pĂ«rballon â ka zgjerime speciale ClickHouse SQL. PĂ«r shembull, maxIf â njĂ« funksion special qĂ« llogarit maksimumin e metrikes nĂ«n njĂ« kusht tĂ« caktuar. Mund tĂ« shkruash disa shprehje tĂ« tilla nĂ« njĂ« kĂ«rkesĂ« dhe menjĂ«herĂ« tĂ« llogaritĂ«sh vlerĂ«n 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 të dhënash testuese. Në rastin e kolonave, kemi madhësinë më të vogël të të dhënave: kompresimi maksimal, shpejtësinë maksimale të kërkimeve, por paguajmë që duhet të regjistrojmë gjithçka menjëherë.
NĂ« rastin e serive, gjĂ«rat janĂ« pak mĂ« keq. TĂ« dhĂ«nat ende kompresohen mirĂ« dhe mund tĂ« ruajmĂ« njĂ« skemĂ« tĂ« pa rregullt. Por ClickHouse â njĂ« bazĂ« tĂ« dhĂ«nash kolonale, dhe kur fillojmĂ« tĂ« ruajmĂ« gjithçka nĂ« seri, ajo kthehet nĂ« njĂ« bazĂ« tĂ« dhĂ«nash rreshtore, dhe paguajmĂ« pĂ«r fleksibilitet me efikasitet. PĂ«r çdo operacion, do tĂ« duhet tĂ« lexojmĂ« tĂ« gjithĂ« serinĂ« nĂ« memorie, e pastaj tĂ« gjejmĂ« elementin e nevojshĂ«m â dhe tĂ« rritet seria, shpejtĂ«sia degradon.
Në një nga kompanitë që përdorin këtë qasje (për shembull, ), seritë ndahen në pjesë prej 128 elementësh. Të dhënat e disa mijëra metrike me një volum prej 200 TB të dhënash/ditë ruhen jo në një seri, por në 10 ose 30 seria me logjikë speciale për ruajtjen.
Qasja më e thjeshtë është me rreshta. Por të dhënat kompresohen keq, madhësia e tabelës bëhet e madhe, dhe kur kërkesat shkojnë për disa metrika, ClickHouse punon në mënyrë jo optimale.
Schema hibride
Supozoni se kemi zgjedhur skemën me seri. Por nqs e dimë se shumica e tabelave tona tregojnë vetëm metriks user dhe system, ne mund të materializojmë këto metrika në kolona në nivelin e tabelës 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);
Kur vendosim ClickHouse automatikisht do t'i llogaritë ato. Kështu mund të bashkoni të mirën me të dobishmen: skema është fleksible dhe e përgjithshme, por ne kemi nxjerrë kolona që përdoren më shpesh. Dua të theksoj se kjo nuk kërkoi të ndryshoja vendosjen dhe ETL, i cili vazhdon të vendosë në tabelë seritë. Ne thjesht bëmë ALTER TABLE, shtuam disa kolona dhe mora një skemë hibride dhe më të shpejtë, që mund të fillojmë ta përdorim menjëherë.
Kodekët dhe kompresimi
PĂ«r time-series. Ă«shtĂ« e rĂ«ndĂ«sishme, sa mĂ« mirĂ« i paketoni tĂ« dhĂ«nat, sepse seria e informacionit mund tĂ« jetĂ« shumĂ« e madhe. NĂ« ClickHouse ka njĂ« set mjetesh pĂ«r arritjen e efektit tĂ« kompresimit 1:10, 1:20, dhe ndonjĂ«herĂ« edhe mĂ« shumĂ«. Kjo do tĂ« thotĂ« se tĂ« dhĂ«nat e paketuara me volumin 1 TB nĂ« disk zĂ«nĂ« 50-100 GB. MadhĂ«sia mĂ« e vogĂ«l â Ă«shtĂ« mirĂ«, tĂ« dhĂ«nat lexohen mĂ« shpejt dhe mund tĂ« pĂ«rpunohen.
Për të arritur një nivel të lartë kompresimi, ClickHouse mbështet kodekët e mëposhtëm:
Shembull tabele:
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 ne pĂ«rcaktojmĂ« kodekĂ«t DoubleDelta nĂ« njĂ« rast, kurse nĂ« tĂ« dytin â Gorilla, dhe patjetĂ«r shtojmĂ« edhe LZ4 kompresimin. Si rezultat, madhĂ«sia e tĂ« dhĂ«nave nĂ« disk zvogĂ«lohet ndjeshĂ«m:
Këtu tregohet se sa hapësirë zënë të dhënat e njëjta, por duke përdorur kodeka dhe kompresione të ndryshme:
- në një skedar të kompresuar GZIP në disk;
- në ClickHouse pa kodeka, por me kompresimin ZSTD;
- në ClickHouse me kodeka dhe kompresimin LZ4 dhe ZSTD.
Duket që tabelat me kodekë zënë shumë më pak hapësirë.
Madhësia ka rëndësi
Po aq e rëndësishme tipin e duhur të të dhënave:
NĂ« tĂ« gjitha shembujt e sipĂ«rm kam pĂ«rdorur Float64. Por nĂ«se do tĂ« kishim zgjedhur Float32, do tĂ« kishte qenĂ« madje mĂ« mirĂ«. Kjo Ă«shtĂ« demonstruar mirĂ« nga ekipi i PerkonĂ«s nĂ« artikullin nĂ« lidhjen e mĂ«sipĂ«rme. ĂshtĂ« e rĂ«ndĂ«sishme tĂ« pĂ«rdorim tipin mĂ« kompakt tĂ« mundshĂ«m qĂ« i pĂ«rshtatet detyrĂ«s: madje mĂ« pak pĂ«r madhĂ«sinĂ« nĂ« disk, sesa pĂ«r shpejtĂ«sinĂ« e pyetjeve. ClickHouse Ă«shtĂ« shumĂ« i ndjeshĂ«m ndaj kĂ«tij faktori.
NĂ«se mund tĂ« pĂ«rdorni int32 nĂ« vend tĂ« int64, pritni njĂ« rritje pothuajse dyfish tĂ« performancĂ«s. TĂ« dhĂ«nat zĂ«nĂ« mĂ« pak kujtesĂ« dhe e gjithĂ« "aritmetika" punon shumĂ« mĂ« shpejt. ClickHouse brenda vetes â njĂ« sistem shumĂ« i tipizuar, ai e shfrytĂ«zon maksimalisht tĂ« gjitha mundĂ«sitĂ« qĂ« ofrojnĂ« sistemet moderne.
Agregimi dhe Materialized Views
Agregimi dhe pamjet e materializuara lejojnë krijimin e agregatëve për raste të ndryshme:
PĂ«r shembull, mund tĂ« keni tĂ« dhĂ«na origjinale tĂ« paagreguara, dhe mbi to mund tĂ« vendosni pamje tĂ« ndryshme materializuara me shumimin automatik pĂ«rmes motorit tĂ« veçantĂ« SummingMergeTree (SMT). SMT â Ă«shtĂ« njĂ« strukturĂ« e veçantĂ« e dhĂ«nash qĂ« bĂ«n agregatĂ«t automatikisht. TĂ« dhĂ«nat e papĂ«rpunuara futen nĂ« bazĂ«n e tĂ« dhĂ«nave, ato agregatizohen automatikisht, dhe menjĂ«herĂ« mund tĂ« pĂ«rdoren pĂ«r dashboardet.
TTL â "harrojmĂ«" tĂ« dhĂ«nat e vjetra
Si "tĂ« harrojmĂ«" tĂ« dhĂ«nat qĂ« nuk janĂ« mĂ« tĂ« nevojshme? ClickHouse e di kĂ«tĂ«. Kur krijoni tabela, mund tĂ« specifikoni TTL shprehje: pĂ«r shembull, qĂ« tĂ« dhĂ«nat minutore i ruajmĂ« njĂ« ditĂ«, ato ditore â 30 ditĂ«, kurse ato javore ose mujore nuk i prekim kurrĂ«:
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-tier â ndajmĂ« tĂ« dhĂ«nat sipas disqeve
Duke zhvilluar këtë idenë, të dhënat mund të ruhen në ClickHouse në vende të ndryshme. Supozoni se dëshirojmë të ruajmë të dhënat e nxehta nga java e fundit në një disk lokal shumë të shpejtë, SSDkurse të dhënat më historike i ruajmë në një vend tjetër. Në ClickHouse tani është e mundur:
Mund të konfigurohet një politikë ruajtjeje (storage policy) në atë mënyrë që ClickHouse automatikisht të transferojë të dhënat kur të arrihen disa kushte në një ruajtje tjetër.
Por kjo nuk është e gjitha. Në nivelin e një tabele të veçantë, mund të përcaktoni rregulla, kur pikërisht sipas kohës të dhënat kalojnë në ruajtjen e ftohtë. Për shembull, 7 ditë të dhënat qëndrojnë në një disk shumë të shpejtë, dhe gjithçka që është më e vjetër transferohet në të ngadalshëm. Kjo është e mirë sepse lejon sistemin të ruajë performancën maksimale, duke kontrolluar menjëherë shpenzimet dhe pa shpenzuar fonde për të dhënat e ftohta:
CREATE TABLE
...
TTL date + INTERVAL 7 DAY TO VOLUME 'cold_volume',
date + INTERVAL 180 DAY DELETE
Mundësi unike ClickHouse
NĂ« pothuajse gjithçka nĂ« ClickHouse ka kĂ«to "carakteristika", por ato neutralizohen nga ekskluziviteti â ajo qĂ« nuk e ka ndonjĂ« DB tjetĂ«r. PĂ«r shembull, kĂ«tu janĂ« disa nga funksionet unike ClickHouse:
- Tabelat. Në ClickHouse mbështetje shumë e mirë për tabela, si dhe mundësinë për të kryer llogaritje të komplikuara mbi to.
- Struktura agreguese e të dhënave.Kjo është një nga "tiparet" vrasëse. ClickHouseMegjithëse ekipi nga Yandex thotë se ne nuk dëshirojmë të agregojmë të dhënat, të gjithë agregojnë në ClickHouse, sepse është e shpejtë dhe e përshtatshme.
- Pamjet materializuara.Së bashku me struktura agreguese të të dhënave, pamjet materializuara lejojnë të bëjnë një agregim të përshtatshëm. trafik në kohë reale ClickHouse SQL.
- Ky Ă«shtĂ« njĂ« zgjerim i gjuhĂ«sme disa funksione shtesĂ« dhe ekskluzive qĂ« janĂ« vetĂ«m nĂ« SQL . MĂ« parĂ«, kjo ishte si njĂ« zgjerim nga njĂ«ra anĂ«, dhe nga ana tjetĂ«r â njĂ« disavantazh. Tani pothuajse tĂ« gjitha disavantazhet nĂ« krahasim me ClickHouseSQL 92 i kemi eliminuar, tani Ă«shtĂ« vetĂ«m njĂ« zgjerim. Lambda
- âshprehjet.A kanĂ« ato ende ndonjĂ« databazĂ« tjetĂ«r?A janĂ« ata akoma nĂ« ndonjĂ« bazĂ« tjetĂ«r tĂ« dhĂ«nash?
- ML-mbështetje.Kjo është e pranishme në DB të ndryshme, në disa më mirë, në disa më keq.
- Kodi i hapur. Ne mund të zgjerim ClickHouse se bashku. Tani në ClickHouse rreth 500 kontribuues, dhe ky numër po rritet vazhdimisht.
Kërkesa të sofistikuara
Në ClickHouse ka shumë mënyra të ndryshme për të bërë të njëjtën gjë. Për shembull, mund të merrni vlerën e fundit nga tabela në tre mënyra CPU (ka edhe një të katërt, por është më eksotike).
E para tregon se si e bën të lehtë në ClickHouse kërkesat, kur dëshoni të kontrolloni se tuple çfarë përmban një nënkërkesë. Kjo është diçka që personalisht më ka munguar shumë në bazat e tjera të të dhënave. Nëse dua të krahasoj diçka me nënkërkesën, në bazat e tjera të të dhënave mund të krahasoj vetëm skalarë, ndersa për disa kolona duhet të shkruaj JOIN. Në ClickHouse mund të përdorim 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ërdorim kombinatorë, për ligjet e kombinatorikës do të marrim rreth një mijë. ArgMax është 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 është "bashkimi" i rreshtave me kohë të ndryshme. Kjo është një funksion unik për bazat e të dhënave, i cili ka edhe në kdb+. Nëse ka dy seri kohore me kohë të ndryshme, ASOF JOIN lejon që ato të zhvendosen dhe të bashkohen 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 funksionon â 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 zakonshme tĂ« shkruhen kĂ«shtu:
Premtova lambda â ja ato!
Kjo Ă«shtĂ« njĂ« ekuivalent i kĂ«rkesĂ«s analitike nĂ« standardin SQL-2003: ajo llogarit diferencĂ«n midis dy timestamp, duration, numri rendor â gjithçka qĂ« zakonisht ne e konsiderojmĂ« funksione analitike. NĂ« ClickHouse i llogarisim ato pĂ«rmes array-ve: sĂ« pari pĂ«rmbledhim tĂ« dhĂ«nat nĂ« njĂ« array, mĂ« pas i bĂ«jmĂ« gjithçka qĂ« duam nĂ« atĂ« array, dhe pastaj i shtrijmĂ« sĂ«rish. Kjo nuk Ă«shtĂ« shumĂ« e pĂ«rshtatshme, kĂ«rkon dashuri pĂ«r programimin funksional, tĂ« paktĂ«n, por Ă«shtĂ« shumĂ« fleksibil.
Funksionet speciale
Për më tepër në ClickHouse ka shumë funksione të specializuara. Për shembull, si të përcaktohet se sa session-e kalojnë në të njëjtën kohë? Një detyrë tipike për monitorimin është të përcaktohet ngarkesa maksimale me 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ë funksionesh, në total janë 500-600. Një këshillë: të gjitha funksionet në ClickHouse janë në tabelën sistemike (jo të gjitha të dokumentuara, por të gjitha interesante):
select * from system.functions order by nameClickHouse vetë mban shumë informacion rreth vetes, përfshirë log tables, query_log, log i gjurmimit, log i operacioneve me blloqe të dhënash (part_log), log i metrikeve, dhe log sistemor, që zakonisht shkruan në disk. Log-u i metrikeve është time-series. në ClickHouse realisht: ClickHouseBD-ja vetë mund të luajë rolin e time-series. bazës së të dhënave, duke "ngrënë" vetveten.
Kjo Ă«shtĂ« gjithashtu njĂ« gjĂ« unike â pasi ne bĂ«jmĂ« mirĂ« punĂ«n 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 vetes. Aktivizuam Grafana dhe monitorojmĂ« vetveten. MegjithatĂ«, nĂ«se ClickHouse rahin, atĂ«herĂ« nuk do ta shohim, â pse, â ndaj zakonisht nuk bĂ«het kĂ«shtu.
Klastër i madh ose shumë të vegjël ClickHouse
ĂfarĂ« Ă«shtĂ« mĂ« mirĂ« â njĂ« klaster i madh ose shumĂ« tĂ« vegjĂ«l ClickHouse? Qasja tradicionale pĂ«r DWH Ă«shtĂ« njĂ« klaster i madh, nĂ« tĂ« cilin ndahen skema pĂ«r çdo aplikacion. Ne shkuam te administratori i BD-sĂ« â na jepni njĂ« skemĂ«, dhe na u dha ajo:
Në ClickHouse mund të bëhet ndryshe. Mund të bëjmë çdo aplikacion të ketë skemën e tij të vet. ClickHouse:
Një klaster i madh monstroz dhe admin të padëshiruar nuk janë më të nevojshme. Ne mund të japim çdo aplikacion skemën e vet, dhe zhvilluesi mund ta bëjë atë vetë, sepse DWH instalohet shumë lehtë dhe nuk kërkon administrim të komplikuar: ClickHousePor nëse kemi shumë ClickHouse , dhe duam ta instalohet shpesh, atëherë dëshirojmë ta automatizojmë këtë proces. Për këtë mund, për shembull, të përdorim
Por nëse kemi shumë ClickHouse-operatorin. Në Kubernetes dhe clickhouseKubernetes ClickHouse Kubernetes ClickHouse mund të vendoset «me një klik»: unë mund të shtyp butonin, të nis manifestin dhe baza është gati. Mund të krijoj menjëherë një skemë, të filloj të ngarkoj metrikat, dhe brenda 5 minutash kam tashmë një panel Grafana. Janë kaq të thjeshta!
ĂfarĂ« doli pĂ«rfundimisht?
Pra, ClickHouse â Ă«shtĂ«:
- Shpejt. Të gjithë e dinë këtë.
- Thjeshtë. Pak e diskutueshme, por mendoj se është e vështirë në mësim, e lehtë në luftë. Nëse kupton si ClickHouse punon, më pas gjithçka është shumë e thjeshtë.
- Universale. Ai përshtatet për skenarë të ndryshëm: DWH, Seritë e Kohës, Ruajtja e Log-eve. Por kjo nuk është baza e të dhënave OLTP, prandaj mos u përpiqni të bëni aty futje dhe lexime të shkurtra. bazë të dhënash, prandaj mos u përpiqni të bëni atje inserte dhe leximet e shkurtra.
- Interesante. Ndoshta, ai që punon me ClickHouse, ka përjetuar shumë minuta interesante në kuptim të mirë dhe të keq. Për shembull, doli një version i ri, gjithçka u ndal. Ose kur ishit duke u munduar me një detyrë për dy ditë, por pas një pyetjeje në Telegram, detyra u zgjidh në dy minuta. Ose si në konferencë në ligjëratën e Alexey Milovidov, ekrani i ClickHouse prishi transmetimin HighLoad++. Këto lloje gjërash ndodhin vazhdimisht dhe e bëjnë jetën tonë me ClickHouse të gjallë dhe interesante!
Prezantimin mund ta shihni .
Takimi i pritur i zhvilluesve të sistemeve me ngarkesë të lartë në do të mbahet më 9 dhe 10 nëntor në Skolkovo. Më në fund do të jetë një konferencë offline (përkundër të gjitha masave të sigurisë), sepse energjia e HighLoad++ nuk mund të paketizohet në online.
Për konferencën ne gjejmë dhe ju tregojmë raste mbi mundësitë maksimale të teknologjive: HighLoad++ ka qenë, është dhe do të jetë vendi i vetëm ku mund të mësoni për dy ditë si funksionojnë 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 dhjetëfish, vitin e kaluar ngjarja kryesore e industrisë mbajti 3339 pjesëmarrës, 165 folës të ligjëratave dhe takimeve, dhe për njëkohësisht kishte 16 rrugë.
Vitin e kaluar ju ofruam 20 autobuzĂ«, 5280 liter çaji dhe kafeje, 1650 litra lĂ«ngje dhe 10200 shishe uji. Gjithashtu 2640 kilogramĂ« ushqim, 16000 pjatĂ« dhe 25000 gota. PĂ«r mĂ« tepĂ«r, me paratĂ« e fituara nga letĂ«rsia e ricikluar, ne mbollĂ«m 100 fidanĂ« dushku đBiletat mund tĂ« blihen , tĂ« merrni lajme pĂ«r konferencĂ«n â , dhe tĂ« flisni â nĂ« tĂ« gjitha rrjetet sociale: , , dhe .
Burimi: habr.com
