ProHoster >> Blog >> Administrimi >> Teoria dhe praktika e përdorimit të ClickHouse në aplikacione reale. Aleksandër Zaitsev (2018)

Teoria dhe praktika e përdorimit të ClickHouse në aplikacione reale. Aleksandër Zaitsev (2018)

Teoria dhe praktika e përdorimit të ClickHouse në aplikacione reale. Aleksandër Zaitsev (2018)

Megjithëse informacioni tani është i pranishëm pothuajse kudo, databankat analitike ende mbeten mjaft ekzotike. Ato njihen pak dhe përdoren akoma më pak në mënyrë efikase. Shumë njerëz vazhdojnë të "hanë kaktus" me MySQL ose PostgreSQL, të cilat janë projektuar për skenarë të tjerë, të vuajnë me NoSQL, ose të paguajnë shumë për zgjidhje komerciale. ClickHouse ndryshon rregullat e lojës dhe ndjeshëm ul barrierat për t'u futur në botën e DBMS analitik.

Raporti nga BackEnd Conf 2018 dhe është publikuar me leje nga folësi.


Luaj videon

Teoria dhe praktika e përdorimit të ClickHouse në aplikacione reale. Aleksandër Zaitsev (2018)
Kush jam unë dhe pse po flas për ClickHouse? Unë jam drejtor i zhvillimit në kompaninë LifeStreet, e cila përdor ClickHouse. Për më tepër, unë jam themelues i Altinity. Kjo është një partner i Yandex, i cili promovon ClickHouse dhe ndihmon Yandex-in ta bëjë ClickHouse më të suksesshëm. Gjithashtu, jam i gatshëm të ndaj njohuri mbi ClickHouse.

Teoria dhe praktika e përdorimit të ClickHouse në aplikacione reale. Aleksandër Zaitsev (2018)

Dhe akoma, unë nuk jam vëlla i Peti Zaitsev-it. Shpesh më pyesin për këtë. Jo, ne nuk jemi vëllezër.

Teoria dhe praktika e përdorimit të ClickHouse në aplikacione reale. Aleksandër Zaitsev (2018)

"Të gjithë e dinë", se ClickHouse:

  • ShumĂ« i shpejtĂ«,
  • ShumĂ« i pĂ«rshtatshĂ«m,
  • PĂ«rdoret nĂ« Yandex.

Pak më pak dihet se në cilat kompani dhe si përdoret ai.

Teoria dhe praktika e përdorimit të ClickHouse në aplikacione reale. Aleksandër Zaitsev (2018)

Do t'ju tregoj se për çfarë, ku dhe si përdoret ClickHouse, përveç Yandex-it.

Do të flas për mënyrat se si detyra specifike zgjidhen me ClickHouse në kompani të ndryshme, cilat mjete ClickHouse mund të përdorni për detyrat tuaja, dhe si janë përdorur ato në kompani të ndryshme.

Kam përgatitur tre shembuj që tregojnë ClickHouse nga disa këndvështrime. Mendoj se do të jetë interesante.

Teoria dhe praktika e përdorimit të ClickHouse në aplikacione reale. Aleksandër Zaitsev (2018)

Pyetja e parë: "Pse është i nevojshëm ClickHouse?". Duket si një pyetje e qartë, por ka më shumë se një përgjigje.

Teoria dhe praktika e përdorimit të ClickHouse në aplikacione reale. Aleksandër Zaitsev (2018)

  • PĂ«rgjigja e parĂ« – pĂ«r shkak tĂ« performancĂ«s. ClickHouse Ă«shtĂ« shumĂ« i shpejtĂ«. Analizat nĂ« ClickHouse gjithashtu janĂ« shumĂ« tĂ« shpejta. Ai shpesh mund tĂ« pĂ«rdoret atje ku diçka tjetĂ«r punon shumĂ« ngadalĂ« ose shumĂ« keq.
  • PĂ«rgjigja e dytĂ« – Ă«shtĂ« kostoja. NĂ« radhĂ« tĂ« parĂ«, kostoja e skalimit. PĂ«r shembull, Vertica Ă«shtĂ« njĂ« bazĂ« tĂ« dhĂ«nash krejtĂ«sisht e shkĂ«lqyer. Ajo funksionon shumĂ« mirĂ«, nĂ«se keni njĂ« sasi tĂ« vogĂ«l tĂ« terabajve tĂ« tĂ« dhĂ«nave. Por kur bĂ«het fjalĂ« pĂ«r qindra terabaj, ose petabaj, kostoja e licencĂ«s dhe mbĂ«shtetjes arrin njĂ« shumĂ« tĂ« konsiderueshme. Dhe kjo Ă«shtĂ« e shtrenjtĂ«. NdĂ«rsa ClickHouse Ă«shtĂ« falas.
  • PĂ«rgjigjja e tretĂ« Ă«shtĂ« kostoja operacionale. Kjo Ă«shtĂ« njĂ« qasje qĂ« vjen pak ndryshe. RedShift Ă«shtĂ« njĂ« alternativĂ« e shkĂ«lqyer. NĂ« RedShift, mund tĂ« krijoni zgjidhje shumĂ« shpejt. Ajo do tĂ« funksionojĂ« mirĂ«, por çdo orĂ«, çdo ditĂ« dhe çdo muaj do tĂ« paguani mjaft shtrenjtĂ« pĂ«r Amazon, sepse ky Ă«shtĂ« njĂ« shĂ«rbim tepĂ«r i kushtueshĂ«m. Edhe Google BigQuery Ă«shtĂ« i tillĂ«. NĂ«se dikush e ka pĂ«rdorur, e di se atje mund tĂ« ekzekutoni disa pyetje dhe tĂ« merrni njĂ« faturĂ« qĂ« shkon nĂ« qindarka dollarĂ« papritur.

Në ClickHouse nuk ka këto probleme.

Teoria dhe praktika e përdorimit të ClickHouse në aplikacione reale. Aleksandër Zaitsev (2018)

Ku përdoret tani ClickHouse? Përveç Yandex, ClickHouse përdoret në shumë biznese dhe kompani të ndryshme.

  • NĂ« radhĂ« tĂ« parĂ«, kjo Ă«shtĂ« analiza e aplikacioneve web, pra Ă«shtĂ« njĂ« rast pĂ«rdorimi qĂ« ka ardhur nga Yandex.
  • ShumĂ« kompani tĂ« AdTech pĂ«rdorin ClickHouse.
  • ShumĂ« kompani qĂ« kanĂ« nevojĂ« tĂ« analizojnĂ« logĂ«t operative nga burime tĂ« ndryshme.
  • Disa kompani pĂ«rdorin ClickHouse pĂ«r monitorimin e logĂ«ve tĂ« sigurisĂ«. Ato i ngarkojnĂ« nĂ« ClickHouse, bĂ«jnĂ« raporte dhe marrin rezultatet e nevojshme.
  • Kompani po fillojnĂ« ta pĂ«rdorin nĂ« analizĂ«n financiare, pra gradualisht biznesi i madh po e pranon gjithashtu ClickHouse.
  • CloudFlare. NĂ«se dikush po ndjek ClickHouse, me siguri ka dĂ«gjuar pĂ«r emrin e kĂ«saj kompanie. Ky Ă«shtĂ« njĂ« nga kontribuesit e rĂ«ndĂ«sishĂ«m nga komuniteti. Ata kanĂ« njĂ« instalim shumĂ« tĂ« rĂ«ndĂ«sishĂ«m tĂ« ClickHouse. PĂ«r shembull, ata krijuan Kafka Engine pĂ«r ClickHouse.
  • Kompani telekomunikacioni kanĂ« filluar ta pĂ«rdorin. Disa kompani ClickHouse e pĂ«rdorin ose si provĂ« koncepti, ose tashmĂ« nĂ« prodhim.
  • NjĂ« kompani e pĂ«rdor ClickHouse pĂ«r monitorimin e proceseve prodhuese. Ata testojnĂ« çipa, regjistrojnĂ« shumĂ« parametra, rreth 2,000 karakteristika. Dhe mĂ« pas analizojnĂ« – Ă«shtĂ« njĂ« partinĂ« e mirĂ« apo e keqe.
  • Analiza e blockchain. Ekziston njĂ« kompani ruse e quajtur Bloxy.info. Kjo Ă«shtĂ« analiza e rrjetit ethereum. KĂ«ta e realizuan gjithashtu nĂ« ClickHouse.

Teoria dhe praktika e përdorimit të ClickHouse në aplikacione reale. Aleksandër Zaitsev (2018)

Shkallëzimi nuk ka rëndësi. Ka shumë kompani që përdorin një server të vogël. Dhe ai u lejon atyre të zgjidhin problemet e tyre. Dhe më shumë kompani përdorin klastera të mëdhenj me shumë serverëve ose dhjetëra servera.

Dhe nëse shikoni rekordet, atëherë:

  • Yandex: 500+ servera, 25 miliardĂ« regjistrime nĂ« ditĂ« qĂ« ata ruajnĂ« aty.
  • LifeStreet: 60 servera, rreth 75 miliardĂ« regjistrime nĂ« ditĂ«. MĂ« pak servera, mĂ« shumĂ« regjistrime se nĂ« Yandex.
  • CloudFlare: 36 serverĂ«, 200 miliardĂ« regjistrime nĂ« ditĂ« ata ruajnĂ«. Ata kanĂ« edhe pĂ«r sĂ« tepĂ«rmi pak serverĂ« dhe edhe mĂ« shumĂ« tĂ« dhĂ«na qĂ« ruajnĂ«.
  • Bloomberg: 102 serverit, rreth njĂ« trilion regjistrimesh nĂ« ditĂ«. Rekordmeni pĂ«r regjistrime.

Teoria dhe praktika e përdorimit të ClickHouse në aplikacione reale. Aleksandër Zaitsev (2018)

Gjeografikisht – Ă«shtĂ« gjithashtu shumĂ«. Kjo hartĂ« tregon heatmap-in, ku ClickHouse pĂ«rdoret nĂ« botĂ«. KĂ«tu spikasin qartĂ« Rusia, Kina, Amerika. Ka pak vende evropiane. Dhe mund tĂ« veçojmĂ« 4 klastera.

Ky është një analizë krahasuese, nuk ka nevojë të kërkosh numra absolutë. Ky është një analizë e vizitorëve që lexojnë materiale në anglishte në faqen e Altinity, sepse atje nuk ka material në rusisht. Dhe Rusia, Ukraina, Bjellorusia, dmth. pjesa rusishtfolëse e komunitetit, janë përdoruesit më të shumtë. Më pas vjen SHBA dhe Kanada. Kina po ngjitet shumë shpejt. Para gjashtë muajve nuk kishte pothuajse asgjë nga Kina, tani Kina ka kaluar Evropën dhe vazhdon të rritet. Vjetër-Evropa gjithashtu nuk mbetet prapa, ndërsa lideri në përdorimin e ClickHouse është, siç nuk është për t'u besuar, Franca.

Teoria dhe praktika e përdorimit të ClickHouse në aplikacione reale. Aleksandër Zaitsev (2018)

Pse po tregoj gjithë këtë? Për të treguar se ClickHouse po bëhet zgjidhja standarde për analizimin e të dhënave të mëdha dhe se po përdoret në shumë vende. Nëse e përdorni, jeni në rrugën e duhur. Nëse ende nuk e përdorni, mund të mos keni frikë se do të mbeteni vetëm dhe askush nuk do t'ju ndihmojë, sepse shumë njerëz tashmë po merren me këtë.

Teoria dhe praktika e përdorimit të ClickHouse në aplikacione reale. Aleksandër Zaitsev (2018)

Këto janë shembuj të përdorimit të vërtetë të ClickHouse në disa kompani.

  • Shembulli i parĂ« Ă«shtĂ« njĂ« rrjet reklamash: migrimi nga Vertica nĂ« ClickHouse. Dhe unĂ« di disa kompani qĂ« janĂ« transferuar nga Vertica ose janĂ« nĂ« procesin e kalimit.
  • Shembulli i dytĂ« Ă«shtĂ« njĂ« depo tranzaksionesh nĂ« ClickHouse. Ky Ă«shtĂ« njĂ« shembull i ndĂ«rtuar mbi antipat ndĂ«rsa. Çdo gjĂ« qĂ« nuk duhet bĂ«rĂ« nĂ« ClickHouse sipas kĂ«shillave tĂ« zhvilluesve, kĂ«tu Ă«shtĂ« bĂ«rĂ«. Dhe gjithashtu Ă«shtĂ« bĂ«rĂ« aq efektivisht sa funksionon. Dhe funksionon shumĂ« mĂ« mirĂ« se njĂ« zgjidhje tipike tranzaksionesh.
  • Shembulli i tretĂ« Ă«shtĂ« llogaritjet e shpĂ«rndara nĂ« ClickHouse. Kishte njĂ« pyetje nĂ« lidhje me mĂ«nyrĂ«n se si mund tĂ« integrohet ClickHouse nĂ« ekosistemin Hadoop. Do tĂ« tregoj njĂ« shembull se si njĂ« kompani bĂ«ri nĂ« ClickHouse diçka si njĂ« analog tĂ« kontejnerit map reduce, duke mbajtur parasysh lokalizimin e tĂ« dhĂ«nave etj., pĂ«r tĂ« llogaritur njĂ« detyrĂ« shumĂ« jo triviale.

Teoria dhe praktika e përdorimit të ClickHouse në aplikacione reale. Aleksandër Zaitsev (2018)

  • LifeStreet – Ă«shtĂ« njĂ« kompani Ad Tech, qĂ« ka tĂ« gjitha teknologjitĂ« pĂ«rkatĂ«se pĂ«r njĂ« rrjet reklamash.
  • Ajo merret me optimizimin e reklamave, ofertat programatike.
  • ShumĂ« tĂ« dhĂ«na: rreth 10 miliard ngjarje nĂ« ditĂ«. NĂ« tĂ« njĂ«jtĂ«n kohĂ«, kĂ«to ngjarje mund tĂ« ndahen nĂ« disa nĂ«n-ngjarje.
  • ShumĂ« klientĂ« pĂ«rdorin kĂ«to tĂ« dhĂ«na, dhe kjo nuk janĂ« vetĂ«m njerĂ«zit, ka shumĂ« mĂ« tepĂ«r – janĂ« algoritme tĂ« ndryshme qĂ« merret me ofertat programatike.

Teoria dhe praktika e përdorimit të ClickHouse në aplikacione reale. Aleksandër Zaitsev (2018)

Kompania ka kaluar një rrugë të gjatë dhe me sfida. E kam përmendur këtë në HighLoad. Fillimisht, LifeStreet kaloi nga MySQL (me një ndalesë të vogël në Oracle) në Vertica. Dhe mund të gjeni informacion mbi këtë.

Gjithçka shkoi shumë mirë, por mjaft shpejt u kuptua që të dhënat po rriteshin dhe Vertica është e shtrenjtë. Prandaj, u kërkuan alternativa të ndryshme. Disa prej tyre janë përmendur këtu. Në të vërtetë, ne bëmë një provë koncepti ose ndonjëherë testim performancë për gati të gjitha databazat që ishin në dispozicion në treg nga viti 2013 deri në 2016 dhe që përshtateshin për funksionalitetin. Dhe për disa prej tyre kam folur gjithashtu në HighLoad.

Teoria dhe praktika e përdorimit të ClickHouse në aplikacione reale. Aleksandër Zaitsev (2018)

I ishte njĂ« detyrĂ« – tĂ« migrohej nga Vertica fillimisht, sepse tĂ« dhĂ«nat po rriteshin. Ato rriteshin eksponencialisht pĂ«r disa vite. Pastaj dolĂ«n nĂ« njĂ« nivel tĂ« caktuar, megjithatĂ«. Duke parashikuar kĂ«tĂ« rritje, kĂ«rkesat e biznesit pĂ«r volum tĂ« tĂ« dhĂ«nave, pĂ«r tĂ« cilat duhet tĂ« bĂ«hej ndonjĂ« analizĂ«, ishte e qartĂ« se shumĂ« shpejt do tĂ« diskutohej pĂ«r petabajt. Dhe pĂ«r petabajt, pagesa tashmĂ« Ă«shtĂ« shumĂ« e shtrenjtĂ«, prandaj po kĂ«rkonim alternativĂ« ku mund tĂ« iknim.

Teoria dhe praktika e përdorimit të ClickHouse në aplikacione reale. Aleksandër Zaitsev (2018)

Ku të iknim? Dhe për një kohë të gjatë ishte krejtësisht e paqartë, ku të iknim, sepse nga njëra anë ekzistojnë bazat e të dhënave komerciale, ato duket se funksionojnë mirë. Disa funksionojnë pothuajse po aq mirë sa Vertica, disa më keq. Por të gjitha janë të shtrenjta, nuk arritëm të gjenim asgjë më të lirë dhe më të mirë.

Nga ana tjetër, ekzistojnë zgjidhje open source, të cilat nuk janë shumë, dmth. për analizë mund të numërohen me gishta. Dhe ato janë pa pagesë ose të lira, por funksionojnë ngadalë. Dhe shpesh u mungon funksionaliteti i nevojshëm dhe i dobishëm.

Dhe për të kombinuar ato të mira që ekzistojnë në bazat e të dhënave komerciale dhe gjithçka që është pa pagesë në open source, nuk kishte asgjë.

Teoria dhe praktika e përdorimit të ClickHouse në aplikacione reale. Aleksandër Zaitsev (2018)

Nuk kishte asgjë deri sa papritur Yandex nxori, si një magjistar që nxjerr një lepur nga një kapelë, ClickHouse. Dhe kjo ishte një zgjidhje e papritur, ende shijoje pyetjen: "Pse?", por megjithatë.

Teoria dhe praktika e përdorimit të ClickHouse në aplikacione reale. Aleksandër Zaitsev (2018)

Dhe menjëherë në verën e vitit 2016 filluam të shikojmë se çfarë ishte ClickHouse. Dhe rezultoi se ndonjëherë mund të ishte më i shpejtë se Vertica. Ne testuam skenarë të ndryshëm me kërkesa të ndryshme. Dhe nëse kërkesa përdorte vetëm një tabelë, pra pa ndonjë bashkëngjitje (join), ClickHouse ishte dy herë më i shpejtë se Vertica.

Nuk u larova dhe shikova testet e Yandex në ditët e fundit. Aty ishte e njëjta gjë: ClickHouse dy herë më i shpejtë se Vertica, prandaj ata shpesh flasin për këtë.

Por nëse kërkesat përmbajnë bashkëngjitje (join), atëherë gjithçka bëhet jo shumë e qartë. Dhe ClickHouse mund të jetë dy herë më i ngadaltë se Vertica. Por nëse pak e rregullojmë kërkesën dhe e rishkruajmë, atëherë janë afërsisht të barabarta. Jo keq. Dhe falas.

Teoria dhe praktika e përdorimit të ClickHouse në aplikacione reale. Aleksandër Zaitsev (2018)

Dhe duke marrë rezultatet e testeve dhe duke e parë nga kënde të ndryshme, LifeStreet kaloi në ClickHouse.

Teoria dhe praktika e përdorimit të ClickHouse në aplikacione reale. Aleksandër Zaitsev (2018)

Kjo është vitin 2016, kujtoj. Ishte si në një anekdotë për miqtë, që qanin dhe mbusheshin me gjilpërë, por vazhdonin të hanin kaktusin. Dhe për këtë u përshkrua në detaje, ka video për të, etj.

Teoria dhe praktika e përdorimit të ClickHouse në aplikacione reale. Aleksandër Zaitsev (2018)

Prandaj nuk do të flas në detaje rreth kësaj, do të ndaj vetëm rezultatet dhe disa gjëra interesante që nuk i kam përmendur atëherë.

Rezultatet janë:

  • Migrimi i suksesshĂ«m dhe sistemi tashmĂ« funksionon nĂ« prodhim pĂ«r mĂ« shumĂ« se njĂ« vit.
  • Performanca dhe fleksibiliteti janĂ« rritur. Nga 10 miliardĂ« regjistrime qĂ« mund tĂ« lejonim tĂ« ruheshin pĂ«r njĂ« ditĂ« dhe atĂ« pĂ«r njĂ« kohĂ« tĂ« shkurtĂ«r, tani LifeStreet ruan 75 miliardĂ« regjistrime nĂ« ditĂ« dhe mund ta bĂ«jĂ« kĂ«tĂ« pĂ«r 3 muaj e mĂ« shumĂ«. NĂ« pikun e aktivitetit, ruhet deri nĂ« njĂ« milion ngjarje nĂ« sekondĂ«. MĂ« shumĂ« se njĂ« milion kĂ«rkesa SQL nĂ« ditĂ« arrijnĂ« nĂ« kĂ«tĂ« sistem, kryesisht nga robotĂ« tĂ« ndryshĂ«m.
  • MegjithĂ«se pĂ«r ClickHouse po pĂ«rdoren mĂ« shumĂ« serverĂ« se pĂ«r Vertica, kursimi dhe nĂ« hardware Ă«shtĂ« arritur, sepse nĂ« Vertica janĂ« pĂ«rdorur disqe SAS mjaft tĂ« shtrenjta. NdĂ«rsa nĂ« ClickHouse janĂ« pĂ«rdorur SATA. Pse? Sepse nĂ« Vertica, inserti Ă«shtĂ« sinkron. Dhe sinkronizimi kĂ«rkon qĂ« disqet tĂ« mos ngadalĂ«sohen shumĂ«, si dhe rrjeti tĂ« mos ngadalĂ«sohet shumĂ«, dmth, Ă«shtĂ« njĂ« operacion mjaft i shtrenjtĂ«. NdĂ«rsa nĂ« ClickHouse, inserti Ă«shtĂ« asinkron. PĂ«r mĂ« tepĂ«r, gjithçka mund tĂ« shkruhet gjithmonĂ« lokal, nuk ka shpenzime shtesĂ« pĂ«r kĂ«tĂ«, prandaj tĂ« dhĂ«nat nĂ« ClickHouse mund tĂ« futen shumĂ« mĂ« shpejt se nĂ« Vertica edhe nĂ« disqe qĂ« nuk janĂ« nga mĂ« tĂ« shpejtit. NdĂ«rsa nĂ« lexim janĂ« pĂ«rafĂ«rsisht tĂ« njĂ«jta. Leximi nĂ« SATA, nĂ«se janĂ« nĂ« RAID, atĂ«herĂ« kjo Ă«shtĂ« e gjitha mjaft e shpejtĂ«.
  • Nuk janĂ« tĂ« kufizuar nga licenca, dmth. 3 petabayta tĂ« dhĂ«nash nĂ« 60 serverĂ« (20 serverĂ« - Ă«shtĂ« njĂ« replikĂ«) dhe 6 trilion artikuj nĂ« fakte dhe agregate. AsgjĂ« e tillĂ« nuk mund tĂ« lejohej nĂ« Vertica.

Teoria dhe praktika e përdorimit të ClickHouse në aplikacione reale. Aleksandër Zaitsev (2018)

Tani po kaloj në gjërat praktike në këtë shembull.

  • E para - Ă«shtĂ« njĂ« skemĂ« efikase. Nga skema varet shumĂ«.
  • E dyta - Ă«shtĂ« gjenerimi i SQL-it efikas.

Teoria dhe praktika e përdorimit të ClickHouse në aplikacione reale. Aleksandër Zaitsev (2018)

Një pyetje tipike OLAP është një select. Disa kolona shkojnë në group by, disa kolona shkojnë në funksionet agregate. Ka një where, të cilën mund ta përshkruajmë si një prerje të kubit. I gjithë group by mund të përfaqësohet si një projekcion. Pra, kjo quhet analiza multidimensionale e të dhënave.

Teoria dhe praktika e përdorimit të ClickHouse në aplikacione reale. Aleksandër Zaitsev (2018)

Dhe shpesh kjo modelizohet në formën e një skeme yll, kur ka një fakt qendror dhe karakteristikat e këtij fakti përreth, në rrezatimin jashtë.

Teoria dhe praktika e përdorimit të ClickHouse në aplikacione reale. Aleksandër Zaitsev (2018)

Dhe nga këndvështrimi i dizajnit fizik, se si shtrihet në tabela, zakonisht bëhet një përfaqësim i normalizuar. Mund të bëni denormalizim, por kjo është e shtrenjtë në disk dhe jo shumë efikase në pyetje. Prandaj, zakonisht bëhet një përfaqësim i normalizuar, pra, tabela e faktit dhe shumë tabele dimensionale.

Por në ClickHouse kjo funksionon keq. Ka dy arsye:

  • E para – Ă«shtĂ« sepse nĂ« ClickHouse nuk ka shumĂ« lidhje (join) tĂ« mira, pra, lidhje (join) ka, por ato janĂ« tĂ« kĂ«qija. Ose pĂ«r momentin janĂ« tĂ« kĂ«qija.
  • E dyta – Ă«shtĂ« se tabelat nuk pĂ«rditĂ«sohen. Zakonisht nĂ« kĂ«to tabela, qĂ« rrethojnĂ« skemĂ«n e yllit, nevojitet tĂ« ndryshohet diçka. PĂ«r shembull, emri i klientit, emri i kompanisĂ« dhe tĂ« tjera. Dhe kjo nuk funksionon.

Dhe ka dy zgjidhje për këtë në ClickHouse:

  • E para nĂ« pĂ«rdorimi i fjalorĂ«ve. FjalorĂ«t e JashtĂ«m janĂ« ato qĂ« ndihmojnĂ« pĂ«r tĂ« zgjidhur me 99% problemin e skemĂ«s star, me pĂ«rditĂ«simet dhe tĂ« tjera.
  • E dyta – Ă«shtĂ« pĂ«rdorimi i masivave. Masivat gjithashtu ndihmojnĂ« pĂ«r tĂ« eliminuar bashkĂ«ngjitjet (join) dhe problemet me normalizimin.

Teoria dhe praktika e përdorimit të ClickHouse në aplikacione reale. Aleksandër Zaitsev (2018)

  • Nuk nevojiten bashkĂ«ngjitje (join).
  • TĂ« pĂ«rditĂ«sueshme. QĂ« nga marsi i vitit 2018, ka ardhur njĂ« mundĂ«si e pa dokumentuar (nuk do ta gjeni nĂ« dokumentacion) pĂ«r tĂ« pĂ«rditĂ«suar pjesĂ«risht fjalorĂ«t, dmth, ato shĂ«nime qĂ« kanĂ« ndryshuar. Praktikisht – Ă«shtĂ« si njĂ« tabelĂ«.
  • GjithmonĂ« nĂ« memorie, kĂ«shtu qĂ« bashkĂ«ngjitjet (join) me fjalorin punojnĂ« mĂ« shpejt se sa do tĂ« ishte njĂ« tabelĂ« qĂ« ndodhet nĂ« disk dhe nuk dihet akoma nĂ«se Ă«shtĂ« nĂ« cache, ndoshta nuk Ă«shtĂ«.

Teoria dhe praktika e përdorimit të ClickHouse në aplikacione reale. Aleksandër Zaitsev (2018)

  • Po ashtu nuk nevojiten bashkĂ«ngjitje (join).
  • Kjo Ă«shtĂ« njĂ« pĂ«rfaqĂ«sim kompakt 1 ndaj shumĂ«.
  • Dhe sipas mendimit tim, masivat janĂ« bĂ«rĂ« pĂ«r geek-Ă«t. KĂ«to janĂ« funksionet lambda dhe tĂ« tjera.

Kjo nuk është për fjalë të kuqe. Kjo është një funksionalitet shumë i fuqishëm që lejon të bëni shumë gjëra shumë thjesht dhe elegant.

Teoria dhe praktika e përdorimit të ClickHouse në aplikacione reale. Aleksandër Zaitsev (2018)

Shembuj tipikë që ndihmojnë për të zgjidhur masivat. Këta shembuj janë të thjeshtë dhe mjaft të qartë:

  • KĂ«rkimi sipas etiketave. NĂ«se keni atje hashtag dhe dĂ«shironi tĂ« gjeni disa shĂ«nime sipas hashtags.
  • KĂ«rkoni nĂ« parametrat key-value. Ka disa atribute me vlera gjithashtu.
  • Ruani listat e çelĂ«save qĂ« duhet t'i pĂ«rktheni nĂ« ndonjĂ« gjĂ« tjetĂ«r.

Të gjitha këto detyra mund të zgjidhen pa masa. Etiketat mund të vendosen në një varg dhe të zgjedhen me shprehje reguli ose në një tabelë të veçantë, por atëherë do t'ju duhet të bëni bashkime (join).

Teoria dhe praktika e përdorimit të ClickHouse në aplikacione reale. Aleksandër Zaitsev (2018)

Në ClickHouse nuk ka nevojë të bëni asgjë, mjafton të përshkruani një varg string për hashtagët ose të krijoni një strukturë të thelluar për sisteme si key-value.

Struktura e thelluar – ndoshta nuk Ă«shtĂ« emri mĂ« i mirĂ«. JanĂ« dy vargje qĂ« kanĂ« njĂ« pjesĂ« tĂ« pĂ«rbashkĂ«t nĂ« emĂ«r dhe disa karakteristika tĂ« lidhura.

Dhe të kërkosh për etiketën është shumë e thjeshtë. Ekziston një funksion ka, që kontrollon nëse një element është në varg. Këtu, gjetëm të gjitha regjistrimet që i përkasin konferencës tonë.

Kërkimi për subid është pak më i komplikuar. Fillimisht duhet të gjejmë indeksin e çelësit, pastaj të marrim elementin me këtë indeks dhe të kontrollojmë nëse vlera është ajo që duam. Megjithatë, është shumë e thjeshtë dhe kompakte.

Një shprehje e rregullt që do të dëshironit të shkruani, nëse do ta ruanit të gjitha këto në një rresht, do të ishte, para së gjithash, e çuditshme. Dhe, për më tepër, do të funksiononte shumë më ngadalë se dy tabela.

Teoria dhe praktika e përdorimit të ClickHouse në aplikacione reale. Aleksandër Zaitsev (2018)

Një shembull tjetër. Keni një array ku ruani ID-të. Dhe mund t'i konvertoni ato në emra. Funksioni arrayMap. Ky është një funksion tipik lambda. Ju dërgoni atje shprehje lambda. Dhe ai nxjerr vlerën e emrit për secilën ID nga fjalori.

Në mënyrë të ngjashme, mund të bëni kërkimin. Kalohet një funksion predikati, i cili kontrollon se çfarë i përket elementeve.

Teoria dhe praktika e përdorimit të ClickHouse në aplikacione reale. Aleksandër Zaitsev (2018)

Këto gjëra ndihmojnë shumë në thjeshtimin e skemës dhe zgjidhin shumë probleme.

Por problemi tjetër me të cilin u përballëm, dhe që do të doja të përmendja, janë kërkesat efektive.

  • NĂ« ClickHouse nuk ka planifikues kĂ«rkesash. NĂ« tĂ«rĂ«si, nuk ka.
  • MegjithatĂ«, kĂ«rkesat komplekse ende duhet tĂ« planifikohen. NĂ« cilat raste?
  • NĂ«se nĂ« kĂ«rkesĂ« ka disa bashkime (join), tĂ« cilat i vendosni nĂ« sub-selekta. Dhe rendi nĂ« tĂ« cilin ata ekzekutohen ka rĂ«ndĂ«si.
  • Dhe e dyta – nĂ«se kĂ«rkesa Ă«shtĂ« e shpĂ«rndarĂ«. Sepse nĂ« njĂ« kĂ«rkesĂ« tĂ« shpĂ«rndarĂ«, vetĂ«m nĂ«nklauzola mĂ« e brendshme ekzekutohet nĂ« mĂ«nyrĂ« tĂ« shpĂ«rndarĂ«, ndĂ«rsa e gjithĂ« pjesa tjetĂ«r dĂ«rgohet nĂ« njĂ« server, te i cili jeni lidhur dhe ekzekutohet atje. Prandaj, nĂ«se keni kĂ«rkesa tĂ« shpĂ«rndara me shumĂ« bashkĂ«ngjitje (join), duhet tĂ« zgjidhni rendin.

Edhe në raste më të thjeshta, ndonjëherë duhet të bëni punën e planifikuesit dhe të riformuloni paksa kërkesat.

Teoria dhe praktika e përdorimit të ClickHouse në aplikacione reale. Aleksandër Zaitsev (2018)

Ja një shembull. Në anën e majtë është kërkesa që tregon 5 vendet kryesore. Dhe ajo ekzekutohet për 2,5 sekonda, mendoj. Ndërsa në anën e djathtë është e njëjta kërkesë, por pak e riformuluar. Në vend që të grupojmë sipas vargut, ne filluam të grupojmë sipas çelësit (int). Dhe kjo është më e shpejtë. Pastaj ne lidhim një fjalor me rezultatin. Në vend të 2,5 sekondave, kërkesa ekzekutohet për 1,5 sekonda. Kjo është mirë.

Teoria dhe praktika e përdorimit të ClickHouse në aplikacione reale. Aleksandër Zaitsev (2018)

Një shembull i ngjashëm me riformulimin e filtrave. Këtu është një kërkesë për Rusinë. Ajo ekzekutohet për 5 sekonda. Nëse e riformulojmë në këtë mënyrë, që të krahasojmë përsëri jo vargje, por numra me një grup të atyre çelësave që lidhen me Rusinë, atëherë kjo do të jetë shumë më shpejt.

Teoria dhe praktika e përdorimit të ClickHouse në aplikacione reale. Aleksandër Zaitsev (2018)

Kaç teknikë të tilla ka. Ato lejojnë të përshpejtohen ndjeshëm kërkesat që ndiheni se tashmë funksionojnë shpejt, ose, përkundrazi, që funksionojnë ngadalë. Mund të bëhen edhe më shpejt.

Teoria dhe praktika e përdorimit të ClickHouse në aplikacione reale. Aleksandër Zaitsev (2018)

  • Maksimumi i punĂ«s nĂ« mĂ«nyrĂ« tĂ« shpĂ«rndarĂ«.
  • SĂ« pari, renditja sipas llojeve minimale, ashtu siç e kam bĂ«rĂ« me integerĂ«t.
  • NĂ«se ka ndonjĂ« bashkim (join), fjalorĂ«, atĂ«herĂ« Ă«shtĂ« mĂ« mirĂ« t'i bĂ«ni ato nĂ« fund tĂ« fundit, kur tĂ« keni tĂ« dhĂ«nat e grumbulluara tĂ« paktĂ«n nĂ« pjesĂ«, atĂ«herĂ« operacioni i bashkimit (join) ose thirrja e fjalorit do tĂ« ndodhĂ« mĂ« pak herĂ« dhe do tĂ« jetĂ« mĂ« shpejt.
  • ZĂ«vendĂ«simi i filtrave.

Ka edhe teknika të tjera, jo vetëm ato që unë demonstroj. Të gjitha këto ndonjëherë lejojnë përshpejtimin ndjeshëm të ekzekutimit të kërkesave.

Teoria dhe praktika e përdorimit të ClickHouse në aplikacione reale. Aleksandër Zaitsev (2018)

TĂ« kalojmĂ« nĂ« shembullin tjetĂ«r. Kompania X nga SHBA. ÇfarĂ« bĂ«n ajo?

Ishte një detyrë:

  • Lidhja offline e transaksioneve tĂ« reklamave.
  • Modelimi i modeleve tĂ« ndryshme tĂ« lidhjes.

Teoria dhe praktika e përdorimit të ClickHouse në aplikacione reale. Aleksandër Zaitsev (2018)

Në çfarë përbëhet skenari?

Një vizitor i zakonshëm hyn në sit, për shembull, 20 herë në muaj nga reklama të ndryshme ose ndonjëherë vjen thjesht sepse e mban mend këtë sit. Ai shikon disa produkte, i vendos në shportë, i nxjerr nga shporta. Dhe, në fund, diçka blen.

Pyetje të arsyeshme: "Kë duhet të paguajë për reklama nëse është e nevojshme?" dhe "Cila reklamë e ndikoi, nëse ndikoi?". Pra, përse bleu dhe si të sigurohemi që njerëz të ngjashëm me këtë person të blejnë gjithashtu?

Për të zgjidhur këtë detyrë, është e nevojshme të lidhen ngjarjet që ndodhin në uebsajt në mënyrën e duhur, pra të krijohet një lidhje ndërmjet tyre. Më pas ato duhet të dërgohen për analizë në DWH. Dhe në bazë të kësaj analize, të ndërtohen modele se kujt dhe cfarë reklame t'i tregojmë.

Teoria dhe praktika e përdorimit të ClickHouse në aplikacione reale. Aleksandër Zaitsev (2018)

Transaksioni reklamues është një grup ngjarjesh të lidhura që fillon nga shfaqja e një reklame, pastaj ndodhin diçka, mund të jetë një blerje, dhe më pas mund të ketë blerje të tjera. Për shembull, nëse është një aplikacion mobil ose një lojë mobile, zakonisht instalimi i aplikacionit është falas, dhe nëse ndodhin aktivitete të tjera, mund të kërkohet pagesë për to. Sa më shumë të shpenzojë një person në aplikacion, aq më i vlefshëm është ai. Por për këtë duhet të lidhësh gjithçka.

Teoria dhe praktika e përdorimit të ClickHouse në aplikacione reale. Aleksandër Zaitsev (2018)

Ka shumë modele lidhjeje.

Modelet më të njohura janë:

  • Interaksioni i fundit, ku interaksioni Ă«shtĂ« ose njĂ« klikim, ose njĂ« shfaqje.
  • Interaksioni i parĂ«, domethĂ«nĂ«, ajo qĂ« e solli fillimisht personin nĂ« faqe.
  • Kombinimi linear – tĂ« gjithĂ« nĂ« mĂ«nyrĂ« tĂ« barabartĂ«.
  • Zbehja.
  • Dhe tĂ« tjera.

Teoria dhe praktika e përdorimit të ClickHouse në aplikacione reale. Aleksandër Zaitsev (2018)

Si ka funksionuar gjithçka fillimisht? Ka pasur Runtime dhe Cassandra. Cassandra u pĂ«rdor si ruajtje transaksionesh, dmth. tĂ« gjitha transaksionet e lidhura ruheshin atje. Kur ndodhte njĂ« ngjarje nĂ« Runtime, pĂ«r shembull, shfaqja e njĂ« faqeje ose diçka tjetĂ«r, dikush bĂ«hej njĂ« kĂ«rkesĂ« nĂ« Cassandra – nĂ«se ekzistonte ky person apo jo. MĂ« pas nxirrnin transaksionet qĂ« i pĂ«rkasin atij. Dhe bĂ«hej lidhja.

Nëse ka fat që në kërkesë ka një ID transaksioni, është e lehtë. Por zakonisht nuk ka fat. Prandaj, duhej të gjendej transaksioni i fundit ose transaksioni me klikimin e fundit, etj.

Dhe gjithçka funksiononte shumë mirë derisa lidhja ishte me klikimin e fundit. Sepse, le të themi, ka 10 milion klikime në ditë, 300 milion në muaj, nëse vendosni një dritare për muajin. Dhe pasi që në Cassandra gjithçka duhet të jetë në memorie për të funksionuar shpejt, sepse kërkohet që Runtime të japë përgjigje shpejt, nevojiteshin rreth 10-15 serverë.

Dhe kur u dëshirua të lidhej transaksioni me shfaqjen, menjëherë kjo nuk doli aq argëtuese. Pse? Duke parë, është e qartë se duhen ruajtur 30 herë më shumë ngjarje. Dhe, për rrjedhojë, nevojiten 30 herë më shumë serverë. Dhe rezulton se është një numër astronomik. Të mbash deri në 500 serverë për të bërë lidhje, ndërsa në Runtime ka shumë më pak serverë, kjo është një shifër e gabuar. Dhe filluam të mendojmë se çfarë të bëjmë.

Teoria dhe praktika e përdorimit të ClickHouse në aplikacione reale. Aleksandër Zaitsev (2018)

Dhe arritëm te ClickHouse. Si mund ta bëjmë këtë në ClickHouse? Në shikim të parë duket si një grup antipatish.

  • Transaksioni po rritet, ne po lidhim ngjarje tĂ« reja me tĂ«, pra Ă«shtĂ« mutable, dhe ClickHouse nuk punon shumĂ« mirĂ« me objekte mutable.
  • Kur na vjen njĂ« vizitor, ne duhet tĂ« nxjerrim transaksionet e tij sipas çelĂ«sit, sipas visit ID-sĂ« sĂ« tij. Kjo gjithashtu Ă«shtĂ« njĂ« point query, dhe nĂ« ClickHouse nuk bĂ«het kĂ«shtu. Zakonisht nĂ« ClickHouse ka skane tĂ« mĂ«dha... dhe kĂ«tu na nevojitet tĂ« nxjerrim disa regjistra. Po ashtu Ă«shtĂ« njĂ« antipattern.
  • PĂ«rveç kĂ«saj, transaksioni ishte nĂ« json, por nuk donin ta ri-shkruanin, kĂ«shtu qĂ« donin ta ruanin json-in nĂ« njĂ« formĂ« jo tĂ« strukturuar, dhe nĂ«se ishte e nevojshme, tĂ« nxirrnin diçka nga ai. Dhe kjo gjithashtu Ă«shtĂ« njĂ« antipattern.

Pra, një grup antipatternesh.

Teoria dhe praktika e përdorimit të ClickHouse në aplikacione reale. Aleksandër Zaitsev (2018)

Por megjithatë, arritëm të krijojmë një sistem që punonte shumë mirë.

ÇfarĂ« Ă«shtĂ« bĂ«rĂ«? U shfaq ClickHouse, nĂ« tĂ« cilin hidhen logĂ«t, tĂ« ndara nĂ« regjistra. U shfaq njĂ« shĂ«rbim i atribuar, i cili merr logĂ«t nga ClickHouse. Pas kĂ«saj, pĂ«r secilin regjistĂ«r sipas visit id, merrte transaksionet qĂ« mund tĂ« ishin akoma tĂ« pa pĂ«rpunuara dhe plus snapshots, domethĂ«nĂ« transaksionet tashmĂ« tĂ« lidhura, veçanĂ«risht rezultati i punĂ«s sĂ« mĂ«parshme. Nga ato, krijohej logjika, zgjidheshin transaksionet e duhura, bashkoheshin ngjarje tĂ« reja. PĂ«rsĂ«ri regjistrohej nĂ« log. Logu shkonte pĂ«rsĂ«ri nĂ« ClickHouse, domethĂ«nĂ« kjo Ă«shtĂ« njĂ« sistem i vazhdueshĂ«m ciklik. Dhe pĂ«rveç kĂ«saj, shkonte nĂ« DWH pĂ«r ta analizuar atje.

Në këtë formë, kjo nuk funksiononte shumë mirë. Dhe për ta bërë më të lehtë ClickHouse, kur kishte një kërkesë sipas visit id, kërkesat grupoheshin në blloqe nga 1,000-2,000 visit id dhe merrnim për 1,000-2,000 njerëz të gjitha transaksionet. Dhe atëherë gjithçka filloi të funksionojë.

Teoria dhe praktika e përdorimit të ClickHouse në aplikacione reale. Aleksandër Zaitsev (2018)

Nëse shikoni brenda ClickHouse, ka vetëm 3 tabela kryesore që e shërbejnë këtë.

Tabela e parë, ku hidhen logët, dhe logët hidhen praktikisht pa u përpunuar.

Tabela e dytë. Përmes materialized view nga këto log-e, u nxorrën evenete që ende nuk ishin të atribuuara, dmth të pa lidhura. Dhe përmes materialized view nga këto log-e u nxorrën transaksionet për ndërtimin e snapshot-it. Pra, një materialized view i veçantë ndërtoi snapshot-in, konkretisht gjendjen e fundit të akumuluar të transaksionit.

Teoria dhe praktika e përdorimit të ClickHouse në aplikacione reale. Aleksandër Zaitsev (2018)

Këtu është shkruar teksti në SQL. Do të doja të komentoj disa gjëra të rëndësishme në të.

GjĂ«ja e parĂ« e rĂ«ndĂ«sishme – Ă«shtĂ« mundĂ«sia nĂ« ClickHouse pĂ«r tĂ« nxjerrĂ« kolona, fusha nga json. Pra, nĂ« ClickHouse ka disa metoda pĂ«r tĂ« punuar me json. Ato janĂ« shumĂ«, shumĂ« primitive.

visitParamExtractInt lejon të nxjerrësh atribute nga json, dmth, e para që kapet aktivizohet. Dhe në këtë mënyrë mund të nxjerrësh transaction id ose visit id. Kjo është një.

E dyta – kĂ«tu Ă«shtĂ« pĂ«rdorur njĂ« fushĂ« materialized e zgjuar. ÇfarĂ« do tĂ« thotĂ« kjo? Do tĂ« thotĂ« se nuk mund ta pĂ«rfshish nĂ« tabelĂ«, dmth nuk shtohet, por llogaritet dhe ruhet gjatĂ« proçesit tĂ« shtimit. GjatĂ« shtimit, ClickHouse bĂ«n punĂ«n pĂ«r ju. Dhe pastaj nxirret nga json ajo qĂ« do t'ju nevojitet mĂ« pas.

NĂ« kĂ«tĂ« rast, materialized view Ă«shtĂ« pĂ«r rreshta tĂ« papĂ«rpunuar. Dhe pikĂ«risht pĂ«rdoret tabela e parĂ« me log-e praktikisht tĂ« papĂ«rpunuara. ÇfarĂ« bĂ«n? SĂ« pari, ndryshon renditjen, dmth. renditja tani bĂ«het sipas visit id, sepse na nevojitet tĂ« nxjerrim shpejt transaksionin e njĂ« individi tĂ« caktuar.

I dyti aspekt i rĂ«ndĂ«sishĂ«m Ă«shtĂ« index_granularity. NĂ«se keni parĂ« MergeTree, zakonisht nĂ« default Ă«shtĂ« 8,192 pĂ«r index_granularity. ÇfarĂ« Ă«shtĂ« kjo? Ky Ă«shtĂ« njĂ« parametĂ«r i hollĂ«sisĂ« sĂ« indeksit. NĂ« ClickHouse indeksi Ă«shtĂ« i hollĂ«, ai nuk indekson kurrĂ« çdo regjistrim. E bĂ«n kĂ«tĂ« çdo 8,192. Kjo Ă«shtĂ« mirĂ« kur nevojiten shumĂ« tĂ« dhĂ«na pĂ«r tĂ« llogaritur, por e keqe kur nevojiten pak, sepse ka njĂ« overhead tĂ« madh. Dhe nĂ«se e zvogĂ«lojmĂ« index granularity, ne zvogĂ«lojmĂ« overhead-in. Nuk mund ta zvogĂ«lojmĂ« deri nĂ« njĂ«, sepse mund tĂ« mos ketĂ« mjaftueshĂ«m memorie. Indeksi gjithmonĂ« ruhet nĂ« memorien.

Teoria dhe praktika e përdorimit të ClickHouse në aplikacione reale. Aleksandër Zaitsev (2018)

Dhe snapshot-i përdor disa funksione interesante të ClickHouse.

Së pari, ky është AggregatingMergeTree. Në AggregatingMergeTree ruhet argMax, pra kjo është gjendja e transaksionit që korrespondon me timestamp-in e fundit. Transaksionet gjithëmonë krijohen të reja për këtë vizitor. Dhe në gjendjen më të fundit të këtij transaksioni ne kemi shtuar një event dhe tani kemi një gjendje të re. Ajo përsëri është rifutur në ClickHouse. Dhe përmes argMax në këtë paraqitje materializuar gjithmonë mund të marrim gjendjen aktuale.

Teoria dhe praktika e përdorimit të ClickHouse në aplikacione reale. Aleksandër Zaitsev (2018)

  • Lidhja "e çmontuar" nga Runtime.
  • Ruhet dhe pĂ«rpunohen deri nĂ« 3 miliard transaksionesh nĂ« muaj. Kjo Ă«shtĂ« shumĂ« mĂ« shumĂ« se nĂ« Cassandra, pra nĂ« njĂ« sistem tipik transaksionesh.
  • Kluster i 2x5 serverave ClickHouse. 5 servera dhe çdo server ka njĂ« replikĂ«. Kjo Ă«shtĂ« edhe mĂ« pak se sa ishte nĂ« Cassandra pĂ«r tĂ« realizuar atributimin bazuar nĂ« klikĂ«, ndĂ«rsa kĂ«tu kemi atributimin bazuar nĂ« impresion. Pra, nĂ« vend qĂ« tĂ« rritej numri i serverave 30 herĂ«, ata arritĂ«n ta ulen.

Teoria dhe praktika e përdorimit të ClickHouse në aplikacione reale. Aleksandër Zaitsev (2018)

Dhe shembulli i fundit – Ă«shtĂ« kompania financiare Y, e cila analizoi korrelacionet e ndryshimeve tĂ« çmimeve tĂ« aksioneve.

Dhe detyra ishte e tillë:

  • Ka rreth 5,000 aksione.
  • Çmimet çdo 100 milisekonda janĂ« tĂ« njohura.
  • TĂ« dhĂ«nat janĂ« grumbulluar pĂ«r 10 vjet. NjĂ«herazi, pĂ«r disa kompani mĂ« shumĂ«, pĂ«r disa mĂ« pak.
  • NĂ« total rreth 100 miliardĂ« rreshta.

Dhe duhej të llogaritej korelacioni i ndryshimeve.

Teoria dhe praktika e përdorimit të ClickHouse në aplikacione reale. Aleksandër Zaitsev (2018)

Këtu janë dy aksione dhe kotacionet e tyre. Nëse njëra ngjitet, dhe tjetra ngjitet, atëherë kjo është korelacion pozitiv, dmth, një rritet dhe tjetra rritet. Nëse njëra ngjitet, si në fund të grafikut, ndërsa tjetra bie, atëherë kjo është korelacion negativ, dmth, kur një rritet, tjetra bie.

Duke analizuar këto ndryshime të ndërsjellta mund të bëhen parashikime në tregun financiar.

Teoria dhe praktika e përdorimit të ClickHouse në aplikacione reale. Aleksandër Zaitsev (2018)

Por detyra Ă«shtĂ« e komplikuar. ÇfarĂ« bĂ«het pĂ«r kĂ«tĂ«? Ne kemi 100 miliardĂ« regjistrime, nĂ« tĂ« cilat ka: koha, aksioni dhe çmimi. Na nevojitet tĂ« llogarisim fillimisht 100 miliardĂ« herĂ« vlerĂ«n e runningDifference nga algoritmi i çmimit. RunningDifference Ă«shtĂ« njĂ« funksion nĂ« ClickHouse, i cili llogarit ndryshimin mes dy rreshtave njĂ«pasnjĂ«shĂ«m.

Dhe pas kësaj, duhet të llogaritet korelacioni, për më tepër korelacioni duhet të llogaritet për çdo çift. Për 5,000 aksione, ka 12.5 milionë çifte. Dhe kjo është shumë, dmth, 12.5 herë duhen llogaritur një funksion të tillë korelacioni.

Dhe nĂ«se dikush e harroi, atĂ«herĂ« ͞x dhe ͞y janĂ« pritet e matematikĂ«s nĂ« mostrĂ«n. Pra, duhet jo vetĂ«m tĂ« llogarisni rrĂ«njĂ«t dhe shumat, por gjithashtu brenda kĂ«tyre shumave tĂ« bĂ«ni edhe njĂ« herĂ« shuma. Duhen kryer shumĂ« llogaritje 12.5 milion herĂ«, dhe gjithashtu duhet tĂ« grupohen sipas orĂ«ve. Dhe orĂ«t kemi tĂ« shumta. Dhe duhet ta pĂ«rfundojmĂ« brenda 60 sekondave. Kjo Ă«shtĂ« njĂ« shaka.

Teoria dhe praktika e përdorimit të ClickHouse në aplikacione reale. Aleksandër Zaitsev (2018)

Duhej të arrinim të bënim diçka, sepse gjithë kjo punonte shumë-ngadalë, para se të vinte ClickHouse.

Teoria dhe praktika e përdorimit të ClickHouse në aplikacione reale. Aleksandër Zaitsev (2018)

Ata u përpoqën ta llogaritnin këtë në Hadoop, në Spark, në Greenplum. Dhe gjithçka ishte shumë ngadalë ose e shtrenjtë. Pra, ishte e mundur ta llogarisnin në një farë mënyre, por më pas ishte e shtrenjtë.

Teoria dhe praktika e përdorimit të ClickHouse në aplikacione reale. Aleksandër Zaitsev (2018)

Dhe pastaj erdhi ClickHouse dhe gjithçka u përmirësua shumë.

Ju kujtoj, problemi ynë është me lokalitetin e të dhënave, prandaj korrelacionet nuk mund të lokalizohen. Nuk mund të grumbullojmë një pjesë të të dhënave në një server, një pjesë në një tjetër dhe ta llogarisim, sepse ne duhet të kemi të gjitha të dhënat kudo.

ÇfarĂ« bĂ«nĂ« ata? Fillimisht tĂ« dhĂ«nat ishin tĂ« lokalizuara. NĂ« secilin nga serverĂ«t ruheshin tĂ« dhĂ«nat pĂ«r çmimet e njĂ« grupi tĂ« caktuar tĂ« aksioneve. Dhe ato nuk ndĂ«rthuren. Prandaj Ă«shtĂ« e mundur tĂ« llogaritet logReturn paralelisht dhe nĂ« mĂ«nyrĂ« tĂ« pavarur, gjithçka ndodh ndĂ«rkohĂ« nĂ« mĂ«nyrĂ« paralele dhe tĂ« shpĂ«rndarĂ«.

Më pas vendosëm t'i reduktonim këto të dhëna, pa humbur asnjë shprehshmëri. T'i reduktonim përmes masivave, dmth, për secilën periudhë kohore të krijonim një masiv të aksioneve dhe një masiv të çmimeve. Kështu të dhënat zënë shumë më pak hapësirë. Dhe është më e lehtë të punosh me to. Këto janë praktika pothuajse paralele, dmth, ne llogarisim pjesërisht në mënyrë paralele dhe më pas i regjistrojmë në server.

Pas kësaj, këto mund të replikohen. Shkronja "r" tregon se këto të dhëna i kemi replikuar. Domethënë, ne kemi të njëjtat të dhëna në të tri serverat - këto masiva.

Më pas, me një skript të veçantë nga ky grup prej 12.5 milion korrelacionesh që duhet të llogariten, mund të krijohen pako. Domethënë, 2,500 detyra me 5,000 çifte korrelacionesh. Dhe këtë detyrë do ta llogarisim në një server të caktuar ClickHouse. Të gjithë të dhënat i ka, sepse të dhënat janë të njëjta dhe ai mund t'i llogarisë ato në mënyrë të radhitur.

Teoria dhe praktika e përdorimit të ClickHouse në aplikacione reale. Aleksandër Zaitsev (2018)

Për herë tjetër, si duket kjo? Së pari, ne kemi të gjitha të dhënat në një strukturë të tillë: koha, aksionet, çmimi. Pastaj kemi llogaritur logReturn, pra të dhënat e së njëjtës strukturë, vetëm se në vend të çmimit tani kemi logReturn. Më pas, i kemi transformuar, pra kemi marrë kohën dhe groupArray për aksionet dhe çmimet. I kemi bërë të gjitha bashkë. Dhe, pas kësaj, kemi gjeneruar një sasi të madhe detyrash dhe i kemi ushqyer ClickHouse-i për ta llogaritur. Dhe kjo funksionon.

Teoria dhe praktika e përdorimit të ClickHouse në aplikacione reale. Aleksandër Zaitsev (2018)

Në provën e konceptit, detyra ishte një nën-detyrë, pra kemi marrë më pak të dhëna. Dhe gjithçka në tre serverë.

Këto dy etapa të para: llogaritja e Log_return dhe rrethimi në kodi, zuri rreth një orë secila.

Ndërsa llogaritja e korrelacionit zuri rreth 50 orë. Por 50 orë janë pak, sepse më parë ky proces kishte zgjatur javë të tëra. Kjo ishte një sukses i madh. Dhe nëse e llogaritim, në këtë klaster gjithçka llogaritej 70 herë në sekondë.

Por më e rëndësishmja, kjo sistem është praktikisht pa ngushtica, pra ajo shkallëzohet praktikisht linear. Dhe ata e kanë verifikuar këtë. E kanë shkallëzuar me sukses.

Teoria dhe praktika e përdorimit të ClickHouse në aplikacione reale. Aleksandër Zaitsev (2018)

  • Skema e duhur Ă«shtĂ« gjysma e suksesit. Dhe skema e duhur Ă«shtĂ« pĂ«rdorimi i tĂ« gjitha teknologjive tĂ« nevojshme tĂ« ClickHouse.
  • Summing/AggregatingMergeTrees – janĂ« teknologji qĂ« lejojnĂ« agregimin ose llogaritjen e snapshots state si njĂ« rast tĂ« veçantĂ«. Kjo e thjeshton ndjeshĂ«m shumĂ« gjĂ«ra.
  • Materialized Views lejojnĂ« tĂ« anashkaloni kufizimin e njĂ« indeksi. Ndoshta nuk e kam shprehur shumĂ« qartĂ«, por kur ngarkonim log-et, log-et e papĂ«rpunuara ishin nĂ« njĂ« tabelĂ« me njĂ« indeks, ndĂ«rsa log-et mbi atributet ishin nĂ« njĂ« tabelĂ«, pra tĂ« njĂ«jtat tĂ« dhĂ«na, vetĂ«m tĂ« filtruar, por indeksi ishte krejtĂ«sisht ndryshe. Duket si tĂ« njĂ«jtat tĂ« dhĂ«na, por renditja Ă«shtĂ« e ndryshme. Dhe Materialized Views lejon, nĂ«se e keni nevojĂ«, tĂ« anashkaloni njĂ« kufizim tĂ« tillĂ« nĂ« ClickHouse.
  • Reduktoni granularitetin e indeksit pĂ«r kĂ«rkesa specifike.
  • Dhe shpĂ«rndani tĂ« dhĂ«nat nĂ« mĂ«nyrĂ« tĂ« mençur, kĂ«rkoni tĂ« lokalizoni sa mĂ« shumĂ« qĂ« tĂ« jetĂ« e mundur tĂ« dhĂ«nat brenda serverit. Gjithashtu, pĂ«rpiquni qĂ« kĂ«rkesat tĂ« pĂ«rdorin gjithashtu lokalizimin aty ku Ă«shtĂ« e mundur maksimalisht.

Teoria dhe praktika e përdorimit të ClickHouse në aplikacione reale. Aleksandër Zaitsev (2018)

Duke përmbledhur këtë fjalim të vogël, mund të themi se ClickHouse tani ka zënë qartë pozita në territoret e bazave të dhënave komerciale dhe ato open source, dmth. pikërisht për analizën. Ai është integruar mrekullisht në këtë peizazh. E më shumë se kaq, ai gradualisht po fillon të zëvendësojë të tjerët, sepse kur keni ClickHouse, nuk ju nevojitet InfiniDB. Vertica, ndoshta për shpejt do të bëhet e panevojshme, nëse ata realizojnë një mbështetje të duhur për SQL. Përdorni!

Teoria dhe praktika e përdorimit të ClickHouse në aplikacione reale. Aleksandër Zaitsev (2018)

—Faleminderit pĂ«r referatin! ShumĂ« interesante! A kishte ndonjĂ« krahasim me Apache Phoenix?

-Jo, nuk kam dëgjuar që dikush të ketë bërë krahasime. Ne dhe Yandex përpiqemi të ndjekim të gjitha krahasimet e ClickHouse me bazat e ndryshme të dhënash. Sepse nëse ndonjëherë diçka del më e shpejtë se ClickHouse, atëherë Alexey Milovidov nuk mund të flejë në netë dhe fillon ta përshpejtojë atë menjëherë. Nuk kam dëgjuar për një krahasim të tillë.

  • (АлДĐșсДĐč ĐœĐžĐ»ĐŸĐČĐžĐŽĐŸĐČ) Apache Phoenix – Ă«shtĂ« njĂ« motor SQL mbi Hbase. Hbase Ă«shtĂ« kryesisht e dizajnuar pĂ«r skenarĂ« pune tĂ« llojit key-value. Atje nĂ« çdo rresht mund tĂ« ketĂ« njĂ« numĂ«r tĂ« rastĂ«sishĂ«m kolonash me emra tĂ« rastĂ«sishĂ«m. Kjo mund tĂ« thuhet pĂ«r sisteme si Hbase, Cassandra. Dhe pĂ«r ta, kĂ«rkesat analitike tĂ« rĂ«nda nuk do tĂ« funksionojnĂ« siç duhet. Ose mund tĂ« mendoni se ato funksionojnĂ« mirĂ«, nĂ«se nuk keni pasur asnjĂ« pĂ«rvojĂ« me ClickHouse.

  • Faleminderit

    • PĂ«rshĂ«ndetje! UnĂ« kam qenĂ« duke u interesuar pĂ«r kĂ«tĂ« temĂ« pĂ«r njĂ« kohĂ« tĂ« gjatĂ«, sepse unĂ« kam njĂ« nĂ«n-sistem analitik. Por kur shoh ClickHouse, ndiej se ClickHouse Ă«shtĂ« shumĂ« i pĂ«rshtatshĂ«m pĂ«r analizĂ«n e eventeve, mutable. Dhe nĂ«se kam nevojĂ« tĂ« analizoj shumĂ« tĂ« dhĂ«na biznesi me njĂ« mori tabelash tĂ« mĂ«dha, atĂ«herĂ« ClickHouse, aq sa kuptoj, nuk Ă«shtĂ« shumĂ« i pĂ«rshtatshĂ«m pĂ«r mua? Sidomos nĂ«se ato ndryshojnĂ«. A Ă«shtĂ« kjo e saktĂ« apo ka shembuj qĂ« mund ta falsifikojnĂ« kĂ«tĂ«?

    • Kjo Ă«shtĂ« e saktĂ«. Dhe kjo vlen pĂ«r shumicĂ«n e bazave tĂ« tĂ« dhĂ«nave analitike tĂ« specializuara. Ato janĂ« tĂ« dizajnuara pĂ«r tĂ« punuar me njĂ«rĂ«n ose mĂ« shumĂ« tabela tĂ« mĂ«dha, qĂ« janĂ« tĂ« ndryshueshme, dhe shumĂ« tĂ« vogla qĂ« ndryshojnĂ« ngadalĂ«. DomethĂ«nĂ«, ClickHouse nuk Ă«shtĂ« si Oracle, ku mund tĂ« vendosni gjithçka dhe tĂ« ndĂ«rtoni kĂ«rkesa shumĂ« komplekse. PĂ«r ta pĂ«rdorur ClickHouse nĂ« mĂ«nyrĂ« efektive, duhet tĂ« zhvilloni skemĂ«n nĂ« njĂ« mĂ«nyrĂ« qĂ« funksionon mirĂ« nĂ« ClickHouse. DomethĂ«nĂ«, tĂ« shmangni normalizimin e tepruar, tĂ« pĂ«rdorni fjalorĂ«, dhe tĂ« pĂ«rpiqeni tĂ« keni mĂ« pak lidhje tĂ« gjata. NĂ«se skema Ă«shtĂ« zhvilluar nĂ« kĂ«tĂ« mĂ«nyrĂ«, ato detyra tĂ« ngjashme biznesi nĂ« ClickHouse mund tĂ« zgjidhen shumĂ« mĂ« efikashem se sa nĂ« njĂ« bazĂ« tĂ« dhĂ«nash relacional tradicionale.

Faleminderit për raportin! Kam një pyetje për rastin financiar të fundit. Ata kishin analizën. Duhej të krahasohej si shkonin lart-poshtë. Dhe e kuptoj se ju ndërtuat sistemin pikërisht për këtë analizë? Nëse nesër, supozoni, atyre u nevojitet një raport tjetër mbi këto të dhëna, a duhet ri-ndërtuar skema dhe të ngarkohen të dhënat përsëri? Domethënë, të bëni ndonjë përpunim paraprak për të marrë kërkesën?

Sigurisht, ky Ă«shtĂ« pĂ«rdorimi i ClickHouse pĂ«r njĂ« detyrĂ« mjaft specifike. Ajo tradicionalisht mund tĂ« zgjidhej brenda Hadoop. PĂ«r Hadoop – kjo Ă«shtĂ« njĂ« detyrĂ« ideale. Por nĂ« Hadoop Ă«shtĂ« shumĂ« e ngadaltĂ«. QĂ«llimi im Ă«shtĂ« tĂ« demonstroj se me ClickHouse mund tĂ« zgjidhni detyra qĂ« zakonisht zgjidhen me mjete krejtĂ«sisht tĂ« tjera, por duke e bĂ«rĂ« kĂ«tĂ« shumĂ« mĂ« efikase. Kjo Ă«shtĂ« e destinuar pĂ«r njĂ« detyrĂ« specifike. ËshtĂ« e qartĂ« se nĂ«se ka njĂ« detyrĂ« tĂ« ngjashme, mund ta zgjidhni nĂ« njĂ« mĂ«nyrĂ« tĂ« ngjashme.

E kuptoj. Ju thatë se u përpunuan 50 orë. A është kjo që nga fillimi, kur u ngarkuan të dhënat apo kur morët rezultatet?

Po-po.

Mirë, faleminderit shumë.

Kjo është në një klaster me 3 servera.

Përshëndetje! Faleminderit për prezantimin! Gjithçka është shumë interesante. Unë do të pyes pak jo për funksionalitetin, por për përdorimin e ClickHouse nga pikëpamja e stabilitetit. Domethënë, a keni hasur ndonjëherë në ndonjë kërkesë, keni pasur nevojë të riktheni? Si sillet ClickHouse në këto raste? A ka ndodhur që edhe replicimi të ketë dështuar? Na, për shembull, kemi hasur në problemin me ClickHouse kur ai kalon kufirin e tij dhe dështon.

Sigurisht, sistemet ideale nuk ekzistojnë. Edhe ClickHouse ka problemet e veta. Por a keni dëgjuar që Yandex.Metrika ka funksionuar gjatë dhe nuk ka punuar? Ndoshta jo. Ajo ka funksionuar me besueshmëri që nga viti 2012-2013 mbi ClickHouse. Edhe për përvojën time mund të them. Kurrë nuk kemi pasur ndalime totale. Disa gjëra të pjesshme mund të kanë ndodhur, por ato kurrë nuk kanë qenë kaq kritike sa të ndikojnë seriozisht në biznes. Kurrë nuk ka ndodhur. ClickHouse është mjaft i besueshëm dhe nuk bien rastësisht. Mund të mos shqetësoheni për këtë. Nuk është një gjë e papërfunduar. Kjo është provuar nga shumë kompani.

Përshëndetje! Thatë se duhet të mendohet mirë për skemën e të dhënave nga fillimi. Po nëse kjo ndodhi? Të dhënat e mia po derdhen. Kalon gjysmë viti, dhe kuptoj që nuk mund të jetoj kështu, duhet të rishkarkoj të dhënat dhe të bëj diçka me to.

Sigurisht, kjo varet nga sistemi juaj. Ka disa mënyra për ta bërë këtë praktikisht pa ndalesa. Për shembull, mund të krijoni një Materialized View, në të cilin të krijoni një strukturë të ndryshme të dhënash, nëse ajo mund të mapohet qartë. Pra, nëse ajo lejon mapimin përmes ClickHouse, dmth. nxjerrjen e disa gjërave, ndryshimin e çelësit primar, ndryshimin e ndarjes në particione, atëherë mund të krijoni një Materialized View. Atje do të shkruani të dhënat tuaja të vjetra, dhe të rejat do të shkruhen automatikisht. Pastaj, thjesht ndërroni në përdorimin e Materialized View, pas kësaj ndryshoni shkrimin dhe fshini tabelën e vjetër. Kjo është një mënyrë për ta bërë pra pa ndalesa.

Faleminderit.

Burimi: habr.com

Bli njĂ« hosting tĂ« besueshĂ«m pĂ«r faqet me mbrojtje DDoS, VPS VDS serverĂ« đŸ”„ Bli njĂ« hosting tĂ« besueshĂ«m pĂ«r faqet me mbrojtje DDoS, VPS VDS serverĂ« | ProHoster