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

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

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

Megjithëse tani ka shumë të dhëna pothuajse kudo, bazat e të dhënave analitike ende janë mjaft ekzotike. Ato njihen pak dhe përdoren edhe më keq në mënyrë efikase. Shumë vazhdojnë të "hanë kaktusin" me MySQL ose PostgreSQL, të cilat janë projektuar për skenare të tjera, të vuajnë me NoSQL ose të paguajnë shumë për zgjidhje komerciale. ClickHouse e ndryshon lojën dhe e ul ndjeshëm pragun e hyrjes në botën e DBMS analitik.

Raporti nga BackEnd Conf 2018 dhe ai është botuar me lejen e referuesit.


Luaj videon

Teoria dhe praktika e përdorimit të ClickHouse në aplikacione të vërteta. Aleksandër Zaitsev (2018)
Kush jam unë dhe pse po flas për ClickHouse? Unë jam drejtori i zhvillimit në kompaninë LifeStreet, e cila përdor ClickHouse. Përveç kësaj, unë jam themeluesi i Altinity. Kjo është një partner i Yandex, që promovon ClickHouse dhe ndihmon Yandex-in ta bëjë ClickHouse më të suksesshëm. Gjithashtu, jam i gatshëm të ndaj njohuritë mbi ClickHouse.

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

Dhe akoma nuk jam vëllai i Petës Zaitsev. Shpesh më pyesin për këtë. Jo, ne nuk jemi vëllezër.

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

«E gjithë bota e di», që ClickHouse:

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

Pak më pak e njohur është se në cilat kompani dhe si përdoret.

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

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

Do t'ju tregoj si zgjidhen detyrat konkrete me ndihmën e ClickHouse në kompani të ndryshme, cilat mjete të ClickHouse mund të përdorni për detyrat tuaja dhe si janë përdorur në kompani të ndryshme.

Kam përzgjedhur tre shembuj që tregojnë ClickHouse nga ana të ndryshme. Mendoj se do të jetë interesante.

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

Pyetja e parë: «Përse nevojitet ClickHouse?». Duket si një pyetje e zakonshme, por përgjigjet për të janë më shumë se një.

Teoria dhe praktika e përdorimit të ClickHouse në aplikacione të vërteta. 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 funksionon shumĂ« ngadalĂ« ose shumĂ« keq.
  • PĂ«rgjigja e dytĂ« – Ă«shtĂ« costoja. Dhe nĂ« radhĂ« tĂ« parĂ«, costoja e shkallĂ«zimit. PĂ«r shembull, Vertica Ă«shtĂ« njĂ« bazĂ« tĂ« dhĂ«nash krejt e shkĂ«lqyer. Ajo punon shumĂ« mirĂ«, nĂ«se keni mĂ« shumĂ« se disa terabajtĂ« tĂ« dhĂ«nash. Por kur bĂ«het fjalĂ« pĂ«r qindra terabajtĂ«sh ose petabajtĂ«, atĂ«herĂ« kostoja e licencĂ«s dhe mbĂ«shtetjes arrin nĂ« njĂ« shumĂ« tĂ« konsiderueshme. Dhe kjo Ă«shtĂ« e shtrenjtĂ«. NdĂ«rsa ClickHouse Ă«shtĂ« falas.
  • PĂ«rgjigjja e tretĂ« Ă«shtĂ« kostoja operacionale. Ky Ă«shtĂ« njĂ« qasje pak nga njĂ« kĂ«ndvĂ«shtrim tjetĂ«r. RedShift Ă«shtĂ« njĂ« alternativĂ« e shkĂ«lqyer. NĂ« RedShift mund tĂ« realizoni njĂ« zgjidhje shumĂ« shpejt. Ajo do tĂ« funksionojĂ« mirĂ«, por çdo orĂ«, çdo ditĂ« dhe çdo muaj do tĂ« paguani mjaft shtrenjtĂ« Amazon, pasi Ă«shtĂ« njĂ« shĂ«rbim shumĂ« i kushtueshĂ«m. Google BigQuery gjithashtu. NĂ«se dikush e ka pĂ«rdorur, ai e di se atje mund tĂ« nisni disa kĂ«rkesa dhe tĂ« merrni faturĂ« pĂ«r qindra dollarĂ« papritur.

Në ClickHouse nuk ka këto probleme.

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

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

  • KĂ«tu pĂ«rfshihet kryesisht analizimi i aplikacioneve web, pra Ă«shtĂ« njĂ« rast pĂ«rdorimi qĂ« ka ardhur nga Yandex.
  • ShumĂ« kompani AdTech pĂ«rdorin ClickHouse.
  • ShumĂ« kompani qĂ« kanĂ« nevojĂ« tĂ« analizojnĂ« logjet operative nga burime tĂ« ndryshme.
  • Disa kompani pĂ«rdorin ClickHouse pĂ«r monitorimin e logjeve tĂ« sigurisĂ«. Ato i ngarkojnĂ« nĂ« ClickHouse, bĂ«jnĂ« raporte, marrin rezultate qĂ« u nevojiten.
  • KompanitĂ« fillojnĂ« ta pĂ«rdorin nĂ« analizĂ«n financiare, pra pĂ«r pak kohĂ«, bizneset e mĂ«dha po i afrohen gjithashtu ClickHouse.
  • CloudFlare. NĂ«se dikush ndjek ClickHouse, sigurisht ka dĂ«gjuar emrin e kĂ«saj kompanie. ËshtĂ« njĂ« nga kontribuesit e dukshĂ«m nga komuniteti. Dhe ata kanĂ« njĂ« instalim tĂ« rĂ«ndĂ«sishĂ«m tĂ« ClickHouse. PĂ«r shembull, ata krijuan Kafka Engine pĂ«r ClickHouse.
  • Kompani telekomunikacionesh kanĂ« filluar ta pĂ«rdorin. Disa kompani e pĂ«rdorin ClickHouse ose si njĂ« provĂ« koncepti, ose tashmĂ« nĂ« prodhim.
  • NjĂ« kompani pĂ«rdor ClickHouse pĂ«r monitorimin e proceseve prodhuese. Ata testojnĂ« çipa, regjistrojnĂ« njĂ« sĂ«rĂ« parametrash, rreth 2,000 karakteristika. Dhe mĂ« pas analizojnĂ« – a Ă«shtĂ« njĂ« ngarkesĂ« e mirĂ« apo njĂ« ngarkesĂ« e keqe.
  • Analitika e blockchain. Ka njĂ« kompani ruse si Bloxy.info. Kjo Ă«shtĂ« analiza e rrjetit ethereum. KĂ«tĂ« e bĂ«nĂ« gjithashtu nĂ« ClickHouse.

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

Për më tepër, madhësia nuk ka rëndësi. Ka shumë kompani që përdorin një server të vogël. Dhe ai u lejon të zgjidhin problemet e tyre. Dhe gjithashtu, më shumë kompani përdorin klastere të mëdha me shumë serverësh apo dhjetëra servera.

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

  • Yandex: 500+ servera, 25 miliardĂ« regjistrime nĂ« ditĂ« i ruajnĂ« atje.
  • LifeStreet: 60 servera, rreth 75 miliardĂ« regjistrime nĂ« ditĂ«. MĂ« pak servera, mĂ« shumĂ« regjistrime se nĂ« Yandex.
  • CloudFlare: 36 servera, ata ruajn 200 miliardĂ« shĂ«nimesh nĂ« ditĂ«. Ata kanĂ« edhe mĂ« pak servera dhe ruajnĂ« edhe mĂ« shumĂ« tĂ« dhĂ«na.
  • Bloomberg: 102 serverĂ«, rreth njĂ« trilion shĂ«nimesh nĂ« ditĂ«. Rekordmeni nĂ« regjistrime.

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

Gjeografikisht – kjo Ă«shtĂ« gjithashtu shumĂ«. Ky hartĂ« tregon heatmap, ku ClickHouse pĂ«rdoret nĂ« botĂ«. KĂ«tu pĂ«rfaqĂ«sohet me ngjyra Rusi, KinĂ«, AmerikĂ«. Ka shumĂ« pak vende evropiane. Mund tĂ« identifikohen 4 klasterĂ«.

Ky është një analizë krahasuese, këtu nuk duhet të kërkoni shifra absolute. Ky është analiza e vizitorëve që lexojnë materiale në anglisht në faqen e Altinity, sepse nuk ka material në rusisht aty. Dhe Rusia, Ukraina, Bjellorusia, pra pjesa rusisht-folëse e komunitetit, janë përdoruesit më të shumtë. Pas tyre vijnë SHBA dhe Kanada. Kina po e ndjek nga pas shumë fort. Para gjashtë muajve Kina pothuajse nuk ishte aty, tani Kina ka kaluar Evropën dhe vazhdon të rritet. Vjetërja Evropë gjithashtu nuk mbetet prapa, madje lideri i përdorimit të ClickHouse është, siç duket, Franca.

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

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

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

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

  • Shembulli i parĂ« – Ă«shtĂ« njĂ« rrjet reklamash: migrimi nga Vertica nĂ« ClickHouse. Dhe unĂ« njoh disa kompani qĂ« kanĂ« kaluar nga Vertica ose janĂ« nĂ« procesin e kalimit.
  • Shembulli i dytĂ« – hapĂ«sira transaksionale nĂ« ClickHouse. Ky Ă«shtĂ« njĂ« shembull qĂ« Ă«shtĂ« ndĂ«rtuar mbi antipaterns. TĂ« gjitha, çka nuk duhet bĂ«rĂ« nĂ« ClickHouse sipas kĂ«shillave tĂ« zhvilluesve, kĂ«tu Ă«shtĂ« bĂ«rĂ«. Dhe megjithatĂ« Ă«shtĂ« bĂ«rĂ« kaq efektivisht, sa qĂ« funksionon. Dhe funksionon shumĂ« mĂ« mirĂ« se njĂ« zgjidhje tipike transaksionale.
  • Shembulli i tretĂ« – janĂ« llogaritĂ« e shpĂ«rndara nĂ« ClickHouse. Kishte njĂ« pyetje se si mund tĂ« integrohet ClickHouse nĂ« ekosistemin Hadoop. Do tĂ« tregoj njĂ« shembull, si njĂ« kompani bĂ«ri nĂ« ClickHouse diçka si njĂ« analog tĂ« containerit map reduce, duke i ndjekur lokalizimet e tĂ« dhĂ«nave etj., pĂ«r tĂ« llogaritur njĂ« detyrĂ« shumĂ« jo triviale.

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

  • LifeStreet – Ă«shtĂ« njĂ« kompani Ad Tech, e cila ka tĂ« gjitha teknologjitĂ« e nevojshme pĂ«r njĂ« rrjet reklamash.
  • Ajo merret me optimizimin e reklama, programmatic bidding.
  • ShumĂ« tĂ« dhĂ«na: rreth 10 miliard ngjarjesh nĂ« ditĂ«. Gjithashtu, ngjarjet mund tĂ« pĂ«rfshijnĂ« disa nĂ«n-ngjarje.
  • ShumĂ« klientĂ« kanĂ« nevojĂ« pĂ«r kĂ«to tĂ« dhĂ«na, dhe kjo nuk janĂ« vetĂ«m njerĂ«z, por shumĂ« mĂ« tepĂ«r – janĂ« algoritme tĂ« ndryshme qĂ« merren me programimin e ofertave.

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

Kompania ka kaluar një rrugë të gjatë dhe të vështirë. E kam folur për këtë në HighLoad. Fillimisht, LifeStreet kaloi nga MySQL (me një ndalesë të vogël në Oracle) te Vertica. Mund të gjeni edhe tregimin për këtë.

Dhe gjithçka shkoi shumë mirë, por shpejt u kuptua se të dhënat po rriteshin dhe Vertica është e shtrenjtë. Prandaj, ishim në kërkim të alternativave të ndryshme. Disa prej tyre janë përmendur këtu. Në fakt, ne bëmë prova koncepti ose ndonjëherë teste performancës për pothuajse të gjitha sistemet e bazës së të dhënave që ishin në treg nga viti 2013 deri në vitin 2016 dhe që ishin të përshtatshme për funksionalitetin. Disa prej tyre i kam folur gjithashtu në HighLoad.

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

Ishte e nevojshme të migronim nga Vertica përparësisht, sepse të dhënat po rriteshin. Dhe ato rriteshin eksponencial për disa vite. Më pas arritën në një nivel, por sidoqoftë. Duke parashikuar këtë rritje dhe kërkesat e biznesit për sasinë e të dhënave për të cilat nevojitej të kryhej ndonjë analizë, ishte e qartë se së shpejti do të flasim për petabajtë. Dhe për petabajtë, është shumë e shtrenjtë të paguash, prandaj po kërkonim një alternativë për të kaluar.

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

Ku të shkojmë? Dhe për një kohë të gjatë nuk ishte e qartë se ku të shkonim, sepse nga njëra anë ekzistojnë sistemet e bazës së të dhënave komerciale, të cilat duket se funksionojnë mirë. Disa funksionojnë pothuajse 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Ă«, pra, pĂ«r analizĂ«, mund t’i numĂ«rosh me gishta. Ato janĂ« falas ose tĂ« lira, por funksionojnĂ« ngadalĂ«. Dhe shpesh u mungon funksionaliteti i nevojshĂ«m dhe tĂ« dobishĂ«m.

Dhe kështu, nuk kishte asgjë që të kombininte atë që është e mirë në sistemet komerciale të bazës së të dhënave dhe gjithçka që është falas në open source.

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

Nuk kishte asgjë derisa papritur Yandex e nxori, si një krimb nga një kapelë magjistari, ClickHouse. Dhe kjo ishte një zgjidhje e papritur, ende pyetet: "Pse?", por sidoqoftë.

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

Dhe në verën e vitit 2016, filluam të shqyrtojmë se çfarë është ClickHouse. Dhe rezultoi se ndonjëherë ai mund të jetë më i shpejtë se Vertica. Testuam skenarë të ndryshëm në kërkesa të ndryshme. Dhe nëse kërkesa përdorte vetëm një tabelë, dmth pa ndonjë bashkim (join), atëherë ClickHouse ishte dy herë më i shpejtë se Vertica.

Nuk u lodha dhe shqyrtova gjithashtu testet e Yandex-it para disa ditësh. Aty është e njëjta gjë: ClickHouse është dy herë më i shpejtë se Vertica, prandaj ata shpesh flasin për këtë.

Por nëse kërkesat kanë bashkime (join), atëherë gjithçka bëhet e paqartë. Dhe ClickHouse mund të jetë më i ngadaltë se Vertica deri në dy herë. Por nëse pak e ndryshojmë kërkesën dhe e riformulojmë, atëherë ato janë afërsisht të barabarta. Jo keq. Dhe falas.

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

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

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

Kjo është viti 2016, më kujtohet. Ishte si në anekdotën për miu, të cilët qanë dhe u gërvishtën, por vazhduan të hanë kaktus. Dhe për këtë është folur në detaje, ka video për këtë, etj.

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

Prandaj nuk do të flas në detaje për këtë, do të flas vetëm për rezultatet dhe mbi disa gjëra interesante që nuk kam treguar 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 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Ă« kulm, kjo Ă«shtĂ« deri nĂ« njĂ« milion ngjarje nĂ« sekondĂ« qĂ« ruhen. MĂ« shumĂ« se njĂ« milion SQL-kĂ«rkesa nĂ« ditĂ« vijnĂ« nĂ« kĂ«tĂ« sistem, kryesisht nga robotĂ« tĂ« ndryshĂ«m.
  • PavarĂ«sisht se pĂ«r ClickHouse filluan tĂ« pĂ«rdoren mĂ« shumĂ« serverĂ« se pĂ«r Vertica, kursimi ndodhi edhe nĂ« metal, sepse nĂ« Vertica ishin pĂ«rdorur disqe SAS mjaft tĂ« shtrenjta. NĂ« ClickHouse ishin pĂ«rdorur SATA. Pse? Sepse nĂ« Vertica, inserti Ă«shtĂ« sinkron. Dhe sinkronizimi kĂ«rkon qĂ« disqet tĂ« mos ngadalĂ«sohen shumĂ«, si dhe qĂ« rrjeti tĂ« mos ngadalĂ«sohet, dmth, njĂ« operacion mjaft i shtrenjtĂ«. NdĂ«rsa nĂ« ClickHouse, inserti Ă«shtĂ« asinkron. PĂ«r mĂ« tepĂ«r, gjithmonĂ« mund tĂ« shkruani gjithçka 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, ato janĂ« afĂ«rsisht tĂ« njĂ«jta. Leximi nĂ« SATA, nĂ«se ato janĂ« nĂ« RAID, atĂ«herĂ« gjithçka Ă«shtĂ« mjaft e shpejtĂ«.
  • Nuk ka kufizime pĂ«r licencĂ«n, dmth 3 petabayta tĂ« dhĂ«nash nĂ« 60 serverĂ« (20 serverĂ« janĂ« njĂ« replikĂ«) dhe 6 trilion tĂ« dhĂ«na nĂ« fakte dhe agregatĂ«. AsgjĂ« e tillĂ« nuk mund tĂ« lejohej nĂ« Vertica.

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

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

  • E para Ă«shtĂ« njĂ« skemĂ« efikase. ShumĂ« gjĂ«ra varen nga skema.
  • E dyta Ă«shtĂ« gjenerimi i SQL efikas.

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

Një pyetje tipike OLAP është një select. Një pjesë e koloneve shkon në group by, një pjesë e koloneve shkon në funksionet agregate. Ka një where, të cilën mund ta përfaqësojmë si një prerje kubi. E gjithë group by mund të përfaqësohet si një projektim. Dhe prandaj kjo quhet analizë shumëdimensionale e të dhënave.

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

Dhe shpesh kjo modelizohet në formën e një skeme star, kur ka një fakt qendror dhe karakteristikat e këtij fakti në anët, në rrethe.

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

Dhe nga pikëpamja e dizajnit fizik, se si bazohet në tabelë, zakonisht bëhet një paraqitje e normalizuar. Mund ta denormalizoni, por kjo është e shtrenjtë për disku dhe nuk është shumë efikase për kërkesat. Prandaj zakonisht bëhet një paraqitje e normalizuar, dmth një tabelë fakti dhe shumë shumë tabela masash.

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

  • E para Ă«shtĂ« sepse nĂ« ClickHouse nuk ka gjĂ«ra tĂ« mira pĂ«r bashkim (join), dmth ka bashkime (join), por ato janĂ« tĂ« kĂ«qija. Me sa duket, ende tĂ« kĂ«qija.
  • E dyta Ă«shtĂ« qĂ« tabelat nuk pĂ«rditĂ«sohen. Zakonisht nĂ« kĂ«to tabela, qĂ« janĂ« rreth skemĂ«s star, duhet tĂ« ndryshohet diçka. PĂ«r shembull, emri i klientit, emri i kompanisĂ« dhe tĂ« tjera. Dhe kjo nuk funksionon.

Dhe ka një zgjidhje për këtë në ClickHouse. madje dy të plota:

  • E para Ă«shtĂ« pĂ«rdorimi i fjalorĂ«ve. FjalĂ«t e Jashtme – janĂ« ato qĂ« ndihmojnĂ« tĂ« zgjidhin 99% tĂ« problemit me skemĂ«n star, me pĂ«rditĂ«simet dhe tĂ« tjera.
  • E dyta Ă«shtĂ« pĂ«rdorimi i masivĂ«ve. MasivĂ«t gjithashtu ndihmojnĂ« tĂ« heqin dorĂ« nga bashkimet (join) dhe nga problemet e normalizimit.

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

  • Nuk nevojitet bashkim (join).
  • TĂ« pĂ«rditĂ«sueshme. QĂ« nga marsi i vitit 2018 u shfaq njĂ« mundĂ«si e pa dokumentuar (nĂ« dokumentacion nuk do ta gjeni kĂ«tĂ«) pĂ«r tĂ« pĂ«rditĂ«suar pjesĂ«risht fjalorĂ«t, dmth ato tĂ« dhĂ«na qĂ« janĂ« ndĂ«rruar. Praktikisht, kjo Ă«shtĂ« si njĂ« tabelĂ«.
  • GjithmonĂ« nĂ« memorje, prandaj bashkimet (join) me fjalorin punojnĂ« mĂ« shpejt sesa, nĂ«se do tĂ« ishte njĂ« tabelĂ« qĂ« ndodhet nĂ« disk dhe nuk Ă«shtĂ« fakt qĂ« Ă«shtĂ« nĂ« cache, me siguri qĂ« jo.

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

  • AsnjĂ«herĂ« nuk nevojitet bashkim (join).
  • Kjo Ă«shtĂ« njĂ« paraqitje kompakte 1 me shumĂ«.
  • Dhe nĂ« mendimin tim, masivĂ«t janĂ« bĂ«rĂ« pĂ«r gjerĂ«. KĂ«to janĂ« funksionet lambda dhe tĂ« tjera.

Kjo nuk është për të bërë show. Kjo është një funksionalitet shumë i fuqishëm që lejon të bëni shumë gjëra shumë thjesht dhe me elegancë.

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

Shembuj tipikë që ndihmojnë në zgjidhjen e masave. Këta shembuj janë të thjeshtë dhe mjaft ilustrues:

  • KĂ«rkimi sipas etiketave. NĂ«se keni hashtag dhe dĂ«shironi tĂ« gjeni disa shĂ«nime sipas hashtagut.
  • KĂ«rkimi sipas çifteve key-value. Igjithashtu ka disa atribute me vlera.
  • Ruajtja e listave tĂ« çelĂ«save qĂ« duhet t'i pĂ«rktheni nĂ« diçka tjetĂ«r.

Të gjitha këto detyra mund të zgjidhen pa masa. Etiketat mund të vendosen në një rresht dhe të zgjidhen me një shprehje të rregullt 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 të vërteta. Aleksandër Zaitsev (2018)

Në ClickHouse nuk keni nevojë të bëni asgjë, është mjaft të përshkruani një masë string për hashtag-et ose të bëni një strukturë të thellë për sisteme të tipit key-value.

Struktura e thellĂ« – ndoshta nuk Ă«shtĂ« emri mĂ« i mirĂ«. KĂ«to janĂ« dy masa qĂ« kanĂ« njĂ« pjesĂ« tĂ« pĂ«rbashkĂ«t nĂ« emĂ«r dhe disa karakteristika tĂ« lidhura.

Dhe të kërkosh sipas etiketës është shumë e thjeshtë. Ka një funksion ka, i cili kontrollon se a ka një element në masë. Të gjitha, e gjetëm të gjitha shënimet që i përkasin konferencës tonë.

Kërkimi sipas subid është pak mëNdërmjetës ndërsa duhet të gjejmë fillimisht indeksin e çelësit, dhe pastaj të marim elementin me atë indeks dhe të kontrollojmë nëse vlera është ajo që na nevojitet. Por gjithsesi, është shumë e thjeshtë dhe kompakte.

Shprehja e rregullt, që do të dëshironit të shkruani, nëse do ta mbanit gjithçka në një rresht, do të ishte, së pari, e çuditshme. Dhe, së dyti, do të funksiononte shumë më gjatë se dy masa.

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

Një shembull tjetër. Keni një masë ku ruani ID-të. Dhe mund t'i përktheni ato në emra. Funksioni arrayMap. Kjo është një funksion tipik lambda. Ju e kaloni atje shprehjen lambda. Dhe ajo nxjerr vlerën e emrit për çdo ID nga fjalori.

Gjithashtu mund të bëni kërkimin. Kaloni një funksion predikat, i cili kontrollon se çfarë i përgjigjen elementet.

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

Këto gjëra thjeshtojnë ndjeshëm skemën dhe zgjidhin shumë probleme.

Por problemi tjetër, me të cilin ishim ballafaquar dhe për të cilin do doja të flisja, janë kërkesat efikase.

  • NĂ« ClickHouse nuk ka planifikues tĂ« kĂ«rkesave. NĂ« pĂ«rgjithĂ«si, nuk ka.
  • Por megjithatĂ« kĂ«rkesat e komplikuara duhet tĂ« planifikohen. NĂ« cilat raste?
  • NĂ«se kĂ«rkesa ka disa bashkime (join), tĂ« cilat i mbuloni me nĂ«nkĂ«rkesa. Dhe renditja nĂ« tĂ« cilĂ«n ato ekzekutohen ka rĂ«ndĂ«si.
  • Dhe e dyta Ă«shtĂ« nĂ«se kĂ«rkesa Ă«shtĂ« e distribuar. Sepse nĂ« kĂ«rkesat e distribuuara vetĂ«m nĂ«nkĂ«rkesa mĂ« e brendshme ekzekutohet nĂ« mĂ«nyrĂ« distribuar, ndĂ«rsa tĂ« gjitha tĂ« tjera kalojnĂ« nĂ« njĂ« server tĂ« vetĂ«m, me tĂ« cilin jeni lidhur dhe ekzekutohen atje. Pra, nĂ«se keni kĂ«rkesa tĂ« distribuuara me shumĂ« bashkime (join), duhet tĂ« zgjidhni rendin.

Edhe në raste më të thjeshta ndonjëherë duhet të kryeni punën e planifikuesit dhe të rishkruani pak kërkesat.

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

Ja një shembull. Në pjesën e majtë, kërkesa që tregon 5 vendet më të mira. Dhe ai ekzekutohet për 2.5 sekonda, mendoj. Ndërsa në pjesën e djathtë është e njëjta kërkesë, por e rishkruar pak. Ne, në vend që të grupojmë sipas rreshtit, filluam të grupojmë sipas çelësit (int). Dhe kjo është më e shpejtë. Pastaj, i lidhëm rezultatet me një fjalor. Në vend të 2.5 sekondave, kërkesa ekzekutohet për 1.5 sekonda. Kjo është e mirë.

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

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

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

Ka shumë truke të tilla. Dhe ato lejojnë të përshpejtojnë ndjeshëm kërkesat që ju duket se funksionojnë tashmë shpejt, ose, përkundrazi, funksionojnë ngadalë. Ato mund të bëhen edhe më të shpejta.

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

  • Maksimumi i punĂ«s nĂ« mĂ«nyrĂ« distribuar.
  • Renditja sipas llojeve minimale, siç e kam bĂ«rĂ« pĂ«r int.
  • NĂ«se ka ndonjĂ« bashkim (join), fjalorĂ«, Ă«shtĂ« mĂ« mirĂ« tĂ« bĂ«hen nĂ« fund tĂ« fundit, kur keni tĂ« dhĂ«na sĂ« paku pjesĂ«risht tĂ« grupuara, atĂ«herĂ« operacioni i bashkimit (join) ose thirrja e fjalorit do tĂ« kĂ«rkohet mĂ« pak herĂ« dhe do tĂ« jetĂ« mĂ« e shpejtĂ«.
  • ZĂ«vendĂ«simi i filtrave.

Ka edhe teknika të tjera, dhe jo vetëm ato që unë demonstrova. Të gjitha ato ndonjëherë lejojnë të përshpejtojnë ndjeshëm ekzekutimin e kërkesave.

Teoria dhe praktika e përdorimit të ClickHouse në aplikacione të vërteta. 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 të vërteta. Aleksandër Zaitsev (2018)

ÇfarĂ« pĂ«rfshin skenari?

Një vizitor i zakonshëm hyn në faqen e internetit, për shembull, 20 herë në muaj nga reklama të ndryshme ose ndonjëherë thjesht vjen pa ndonjë reklamë, sepse e mban mend këtë faqe. Ai shikon disa produkte, i vendos ato në shportë, i heq ato nga shporta dhe, në fund, diçka blen.

Pyetje të arsyeshme: "Kë duhet të paguaj për reklamën, nëse duhet?" dhe "Cila reklamë e ndikoi, nëse e ndikoi?" Domethënë, pse e bleu dhe si ta bëjmë që njerëz të ngjashëm me këtë person të blejnë gjithashtu?

Për të zgjidhur këtë detyrë, është e nevojshme të lidhim ngjarjet që ndodhin në faqen e internetit në mënyrën e duhur, domethënë, të krijojmë një lidhje ndërmjet tyre. Pastaj, t'i dërgojmë ato për analizë në DWH. Dhe mbi bazën e kësaj analize të ndërtosh modele se kujt dhe cilën reklamë duhet të shfaqësh.

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

Transaksioni reklamor është një grup ngjarjesh të lidhura me përdoruesin, që fillon nga shfaqja e reklamës, pastaj ndodh diçka, dhe ndoshta blerja, e më pas mund të ndodhin blerje brenda blerjes. Për shembull, nëse është një aplikacion mobil ose një lojë mobile, instalimi i aplikacionit nganjëherë është falas, dhe nëse bëhet diçka më tutje, atëherë mund të nevojiten para. Dhe sa më shumë një person të shpenzojë në aplikacion, aq më i vlefshëm është. Por për këtë, duhet t'i lidhim të gjitha.

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

Ka shumë modele lidhjeje.

Modelet më të njohura janë:

  • Interaksioni i fundit, ku interaksioni Ă«shtĂ« ose klikimi, ose shfaqja.
  • Interaksioni i parĂ«, domethĂ«nĂ«, e para qĂ« e çoi njeriun nĂ« faqe.
  • Kombinimi linear – tĂ« gjithĂ« pĂ«r njĂ«soj.
  • Zgjatja.
  • Dhe tĂ« tjera.

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

Dhe si funksiononte gjithçka fillimisht? Kishim Runtime dhe Cassandra. Cassandra pĂ«rdorej si ruajtje transaksionesh, domethĂ«nĂ«, aty ruheshin tĂ« gjitha transaksionet e lidhura. Dhe kur ndodhte njĂ« ngjarje nĂ« Runtime, pĂ«r shembull, shfaqja e ndonjĂ« faqeje ose ndonjĂ« gjĂ« tjetĂ«r, bĂ«hej njĂ« kĂ«rkesĂ« nĂ« Cassandra – a Ă«shtĂ« ky person apo jo. Pastaj nxirreshin transaksionet qĂ« bĂ«heshin lidhur me tĂ« dhe lidhej.

Dhe nëse kishte fat që në kërkesë të ishte id e transaksionit, atëherë ishte e lehtë. Por zakonisht nuk ka fat. Prandaj, duhej të gjehej transaksioni i fundit ose transaksioni me klikimin e fundit etj.

Dhe kjo ka funksionuar shumë mirë, derisa lidhi me klikimin e fundit. Sepse kishte, le të themi, 10 milion klikime në ditë, 300 milion në muaj, nëse vendosim një dritare mujor. Dhe duke qenë se në Cassandra gjithçka duhet të jetë në kujtesë për të funksionuar shpejt, sepse Runtime kërkon të përgjigjet shpejt, ne kishte nevojë për rreth 10-15 servera.

Por kur deshĂ«n tĂ« lidhnin transaksionin me shfaqjen, menjĂ«herĂ« nuk doli ashtu siç pritej. Pse? ËshtĂ« e dukshme se duhet ruajtur 30 herĂ« mĂ« shumĂ« ngjarje. Dhe, pĂ«r pasojĂ«, duhen gjithashtu 30 herĂ« mĂ« shumĂ« servera. Dhe rezulton se kjo Ă«shtĂ« njĂ« shifĂ«r astronomike. TĂ« mbash deri nĂ« 500 servera pĂ«r tĂ« bĂ«rĂ« kĂ«tĂ« lidhje, ndĂ«rsa nĂ« Runtime ka ndjeshĂ«m mĂ« pak servera, kjo Ă«shtĂ« njĂ« shifĂ«r e papĂ«rshtatshme. Dhe filluan tĂ« mendojnĂ«, çfarĂ« tĂ« bĂ«jnĂ«.

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

Dhe dolën te ClickHouse. Si mund të veprohet me ClickHouse? Në shikim të parë duket si një grup antipatish.

  • Transaksioni rritet, ne i lidhen gjithnjĂ« e mĂ« shumĂ« ngjarje, dmth. Ă«shtĂ« mutable, ndĂ«rsa 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. Kjo gjithashtu Ă«shtĂ« njĂ« kĂ«rkesĂ« point, nĂ« ClickHouse nuk bĂ«het kĂ«shtu. Zakonisht nĂ« ClickHouse ka skane tĂ« mĂ«dha, ndĂ«rsa kĂ«tu na nevojitet tĂ« nxjerrim disa regjistra. Kjo Ă«shtĂ« po ashtu njĂ« antipat.
  • PĂ«r mĂ« tepĂ«r, transaksioni ishte nĂ« json, por nuk donin ta riletronin, kĂ«shtu qĂ« donin tĂ« ruanin json tĂ« pa strukturuar, dhe nĂ«se ishte e nevojshme, tĂ« nxirrnin diçka nga ai. Edhe kjo Ă«shtĂ« njĂ« antipat.

Dmth. një grup antipatish.

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

Megjithatë, arritën të krijonin një sistem që funksiononte shumë mirë.

ÇfarĂ« u bĂ«? U shfaq ClickHouse, nĂ« tĂ« cilin u hodhĂ«n logjet, tĂ« ndara nĂ« regjistra. U shfaq njĂ« shĂ«rbim atribues, i cili merrte logjet nga ClickHouse. Pas kĂ«saj, pĂ«r çdo regjistĂ«r sipas visit id merrte transaksionet, tĂ« cilat mund tĂ« ishin ende tĂ« pa pĂ«rpunuara, dhe plus snapshotet, dmth. transaksionet tashmĂ« tĂ« lidhura, e saktĂ«sisht rezultati i punĂ«s sĂ« mĂ«parshme. Nga ato pĂ«rgatit logjikĂ«n, zgjidhte transaksionin e duhur, lidhen ngjarje tĂ« reja. SĂ«rish e regjistronte nĂ« log. Logu shkonte sĂ«rish nĂ« ClickHouse, dmth. kjo Ă«shtĂ« njĂ« sistem vazhdimisht ciklik. Dhe pĂ«r mĂ« tepĂ«r, shkonte nĂ« DWH pĂ«r ta analizuar atje.

Në këtë formë, kjo nuk funksiononte shumë mirë. Dhe që ClickHouse të kishte më lehtësi, kur bëhej kërkesa për id vizite, ato kërkesa grupoheshin në blloqe prej 1,000 deri në 2,000 id vizite dhe për 1,000-2,000 njerëz nxirrnin të gjitha transaksionet. Dhe atëherë gjithçka funksionoi.

Teoria dhe praktika e përdorimit të ClickHouse në aplikacione të vërteta. 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 ngarkohen log-et, ngarkohet pothuajse pa përpunim.

Tabela e dytë. Përmes materialized view, këto log-e përmbajnë ngjarje që ende nuk janë atribuuar, dmth, të pa lidhura. Dhe përmes materialized view nxirreshin transaksionet për ndërtimin e snapshot-it. Dmth, një materialized view ndihmon në ndërtimin e snapshot-it, konkretisht gjendja më e fundit e grumbulluar e transaksionit.

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

Këtu është shkruar një tekst në SQL. Do 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 nga json, pra, në ClickHouse ka disa metoda për të punuar me json. Ato janë shumë, shumë primitive.

visitParamExtractInt lejon nxjerrjen e atributeve nga json, dmth, hera e parë kur ndodh aktivizohet. Dhe kështu mund të nxirren id transaksioni ose id vizite. Kjo është një.

E dyta - kĂ«tu Ă«shtĂ« pĂ«rdorur njĂ« fushĂ« materialized e mençur. ÇfarĂ« do tĂ« thotĂ« kjo? Kjo do tĂ« thotĂ« se nuk mund ta vendosni nĂ« tabelĂ«, dmth, nuk futet, por llogaritet dhe ruhet gjatĂ« vendosjes. GjatĂ« vendosjes, ClickHouse bĂ«n punĂ«n pĂ«r ju. Dhe tashmĂ« nxirret nga json ajo qĂ« do t'ju nevojitet mĂ« vonĂ«.

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

GjĂ«ja tjetĂ«r e rĂ«ndĂ«sishme Ă«shtĂ« index_granularity. NĂ«se keni parĂ« MergeTree, zakonisht nĂ« mĂ«nyrĂ« parazgjedhĂ«se Ă«shtĂ« 8,192 pĂ«r index_granularity. ÇfarĂ« Ă«shtĂ« kjo? Ky Ă«shtĂ« parametri i hollĂ«sive tĂ« indeksit. NĂ« ClickHouse indeksi Ă«shtĂ« i hollĂ«, ai kurrĂ« nuk indekson çdo regjistrim. E bĂ«n kĂ«tĂ« çdo 8,192. Dhe kjo Ă«shtĂ« mirĂ« kur nevojiten shumĂ« tĂ« dhĂ«na pĂ«r tĂ« bĂ«rĂ« llogaritje, por e keqe kur Ă«shtĂ« pak, sepse ka shumĂ« overhead. Dhe nĂ«se e uleni index granularity, atĂ«herĂ« ne e ulim overhead-in. Nuk mund ta uleni nĂ« 1, sepse mund tĂ« mos ketĂ« mjaft memorie. Indeksi ruhet gjithmonĂ« nĂ« memorie.

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

Dhe snapshoti përdor disa funksione interesante të tjera të ClickHouse.

Së pari, është AggregatingMergeTree. Në AggregatingMergeTree ruhet argMax, që do të thotë se ky është gjendja e transaksionit që përputhet me timestamp-in e fundit. Transaksionet gjithnjë e më të reja gjenerohen për këtë vizitor. Dhe në gjendjen më të fundit të këtij transaksioni ne shtuam një ngjarje dhe fituam një gjendje të re. Ajo sërish u fut në ClickHouse. Dhe nëpërmjet argMax në këtë prezantim të materializuar ne gjithmonë mund të marrim gjendjen aktuale.

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

  • Lidhja "keqkuptohet" nga Runtime.
  • Ruhet dhe pĂ«rpunohet deri nĂ« 3 miliardĂ« transaksione nĂ« muaj. Ky Ă«shtĂ« njĂ« rend tjetĂ«r mĂ« shumĂ« se çfarĂ« ishte nĂ« Cassandra, do tĂ« thotĂ« nĂ« njĂ« sistem tipik transaksionesh.
  • Klusteri i 2x5 serverĂ«ve ClickHouse. 5 serverĂ« dhe çdo server ka njĂ« replikĂ«. Kjo Ă«shtĂ« edhe mĂ« pak se çfarĂ« kishte nĂ« Cassandra pĂ«r tĂ« realizuar atribucionin e bazuar nĂ« klikim, dhe kĂ«tu kemi atribucion tĂ« bazuar nĂ« impresion. Do tĂ« thotĂ«, nĂ« vend qĂ« tĂ« rritet numri i serverĂ«ve 30 herĂ«, ata arritĂ«n t'i zvogĂ«lojnĂ«.

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

Dhe shembulli i fundit është kompania financiare Y, e cila analizonte korrelacionet e ndryshimeve të çmimeve të aksioneve.

Dhe detyra ishte si vijon:

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

Dhe duhej të llogaritej korrelacioni i ndryshimeve.

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

Këtu ka dy aksione dhe çmimet e tyre. Nëse njëra shkon lart, dhe tjetra shkon lart, atëherë kjo është një korrelacion pozitiv, do të thotë njëra rritet dhe tjetra rritet. Nëse njëra shkon lart, si në fund të grafikët, dhe tjetra poshtë, atëherë kjo është një korrelacion negativ, do të thotë kur njëra rritet, tjetra bie.

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

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

Por detyra Ă«shtĂ« e vĂ«shtirĂ«. ÇfarĂ« bĂ«het pĂ«r kĂ«tĂ«? Ne kemi 100 miliardĂ« tĂ« dhĂ«na, ku kemi: kohĂ«, aksion dhe çmim. Na nevojitet tĂ« llogarisim fillimisht 100 miliardĂ« herĂ« runningDifference tĂ« algoritmit tĂ« çmimit. RunningDifference Ă«shtĂ« njĂ« funksion nĂ« ClickHouse qĂ« llogarit diferencĂ«n midis dy rreshtave nĂ« mĂ«nyrĂ« tĂ« vazhdueshme.

Dhe pas kësaj duhet llogaritur korrelacioni, dhe duhet llogaritur korrelacioni për çdo çift. Për 5,000 aksione kemi 12.5 milion çifte. Dhe kjo është shumë, do të thotë 12.5 herë duhet të llogaritet një funksion të tillë korrelacioni.

Dhe nĂ«se dikush e ka harruar, ͞x dhe ͞y – janĂ« pritet matimore pĂ«r mostrat. Pra, duhet tĂ« llogaritni jo vetĂ«m rrĂ«njĂ«t dhe shumat, por gjithashtu brenda kĂ«tyre shumave edhe njĂ« herĂ« shumat e tjera. Duhet tĂ« kryhen shumĂ« kalkulime 12.5 milion herĂ«, dhe gjithashtu duhet tĂ« grumbullohen sipas orĂ«ve. Dhe kemi shumĂ« orĂ«. Dhe duhet ta bĂ«jmĂ« brenda 60 sekondave. ËshtĂ« njĂ« shakĂ«.

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

Duhej të arrinim ndonjë gjë, sepse gjithçka po funksiononte shumë, shumë ngadalë, para se të vinte ClickHouse.

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

Ata provuan ta llogarisin këtë në Hadoop, në Spark, në Greenplum. Dhe gjithçka ishte shumë ngadalë ose e shtrenjtë. Pra, mund të ishte llogaritur në njëfarë mënyre, por më pas bëhej e shtrenjtë.

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

Dhe pastaj erdhi ClickHouse dhe gjithçka u bë shumë më mirë.

Dua tĂ« kujtoj, problemi ynĂ« Ă«shtĂ« me lokalitetin e tĂ« dhĂ«nave, prandaj korelacionet nuk mund tĂ« lokalizohen. Ne nuk mund ta mbledhim njĂ« pjesĂ« tĂ« tĂ« dhĂ«nave nĂ« njĂ« server, njĂ« pjesĂ« nĂ« njĂ« tjetĂ«r dhe t’i llogarisim, duhet tĂ« kemi tĂ« dhĂ«nat gjithmonĂ« kudo.

ÇfarĂ« bĂ«nĂ« ata? Fillimisht, tĂ« dhĂ«nat ishin tĂ« lokalizuara. NĂ« secilin nga serverĂ«t ruhen tĂ« dhĂ«nat pĂ«r çmimet e njĂ« grupi tĂ« caktuar aksionesh. Dhe ato nuk pĂ«rputhen. Pra, mund tĂ« llogarisim paralelisht dhe nĂ« mĂ«nyrĂ« tĂ« pavarur logReturn, gjithçka ndodh ndĂ«rkohĂ« paralelisht dhe e shpĂ«rndarĂ«.

MĂ« pas, ata vendosĂ«n qĂ« tĂ« reduktonin kĂ«to tĂ« dhĂ«na, pa humbur shprehshmĂ«rinĂ«. TĂ« reduktojnĂ« pĂ«rmes masivave, pra, pĂ«r çdo segment kohor tĂ« krijojnĂ« njĂ« masiv aksionesh dhe njĂ« masiv çmimesh. KĂ«shtu, kjo merr shumĂ« mĂ« pak hapĂ«sirĂ« dhe Ă«shtĂ« mĂ« e lehtĂ« pĂ«r t’u punuar me to. KĂ«to janĂ« operacione pothuajse paralel, pra ne llogarisim pjesĂ«risht paralelisht dhe pastaj regjistrojmĂ« nĂ« server.

Pas kĂ«saj, ato mund tĂ« replikohen. Shkronja «r» do tĂ« thotĂ« se kĂ«to tĂ« dhĂ«na ne i kemi replikuar. Pra, ne kemi tĂ« dhĂ«na tĂ« njĂ«jta nĂ« tĂ« tre serverat – kĂ«to masiva.

Dhe mĂ« pas me njĂ« script tĂ« veçantĂ« nga ky grup prej 12.5 milion korelacionesh qĂ« duhen llogaritur, mund tĂ« krijojmĂ« paketa. Pra, 2,500 detyra me 5,000 çifte korelacionesh. Dhe kĂ«tĂ« detyrĂ« tĂ« llogaritim nĂ« njĂ« server tĂ« caktuar ClickHouse. TĂ« gjitha tĂ« dhĂ«nat i ka, sepse tĂ« dhĂ«nat janĂ« tĂ« njĂ«jta dhe ai mund t’i llogarisĂ« ato nĂ« mĂ«nyrĂ« radhitĂ«se.

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

PĂ«r herĂ« tĂ« dytĂ«, si duket kjo. SĂ« pari, ne kemi tĂ« gjitha tĂ« dhĂ«nat nĂ« kĂ«tĂ« strukturĂ«: koha, aksionet, çmimi. Pastaj ne llogaritĂ«m logReturn, dmth. tĂ« dhĂ«nat e sĂ« njĂ«jtĂ«s strukturĂ«, vetĂ«m se pĂ«r çmimin tani kemi logReturn. MĂ« pas, i pĂ«rpunuam, dmth. na dolĂ«n koha dhe groupArray sipas aksioneve dhe çmimeve. I bashkuam. Dhe pas kĂ«saj, gjeneruam njĂ« sĂ«rĂ« detyrash dhe ua dhamĂ« ClickHouse-it qĂ« t’i llogarisĂ« ato. Dhe kjo funksionon.

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

Në provën e konceptit, detyra ishte një nëndetyre, dmth. morëm më pak të dhëna. Dhe gjithçka në tre serverë.

Këta dy etapa të para: llogaritja e Log_return dhe mbështjella në array, zuri rreth një orë secila.

Por llogaritja e korrelacionit zgjati dikur 50 orë. Por 50 orë është pak, sepse më parë atyre iu duhej javë. Kjo ishte një sukses i madh. Dhe nëse llogaritet, gjithçka u llogarit 70 herë në sekondë në këtë klaster.

Por gjëja më e rëndësishme është që ky sistem është praktikisht pa ngushtica, dmth. ai shkallëzohet praktikisht në mënyrë lineare. Dhe ata e verifikuan atë. E skaluan me sukses.

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

  • Schema e saktĂ« Ă«shtĂ« gjysma e suksesit. Dhe schema e saktĂ« Ă«shtĂ« pĂ«rdorimi i tĂ« gjitha teknologjive tĂ« nevojshme tĂ« ClickHouse.
  • Summing/AggregatingMergeTrees janĂ« teknologji qĂ« lejojnĂ« tĂ« agregohen ose llogariten snapshot state si njĂ« rast tĂ« veçantĂ«. Dhe kjo e thjeshton ndjeshĂ«m shumĂ« gjĂ«ra.
  • Materialized Views lejojnĂ« tĂ« anashkalosh kufizimin nĂ« njĂ« indeks. Ndoshta nuk e kam shpjeguar shumĂ« qartĂ«, por kur ngarkonim logĂ«t, logĂ«t e papĂ«rpunuar ishin nĂ« njĂ« tabelĂ« me njĂ« indeks, ndĂ«rsa logĂ«t e atributeve ishin nĂ« tabelĂ«, dmth. tĂ« njĂ«jtat tĂ« dhĂ«na, vetĂ«m tĂ« filtruar, por indekset ishin plotĂ«sisht tĂ« ndryshme. Duket se janĂ« tĂ« njĂ«jtat tĂ« dhĂ«na, por pĂ«rpunimi Ă«shtĂ« ndryshe. Dhe Materialized Views lejon, nĂ«se Ă«shtĂ« e nevojshme, tĂ« anashkalosh njĂ« kufizim tĂ« tillĂ« tĂ« ClickHouse.
  • Reduktoni granularitetin e indeksit pĂ«r kĂ«rkesa tĂ« saktĂ«.
  • Dhe shpĂ«rndani tĂ« dhĂ«nat nĂ« mĂ«nyrĂ« tĂ« mençur, pĂ«rpiquni tĂ« lokalizoni sa mĂ« shumĂ« tĂ« dhĂ«na brenda serverit. Dhe pĂ«rpiquni qĂ« kĂ«rkesat tĂ« pĂ«rdorin gjithashtu lokalizimin atje ku Ă«shtĂ« maksimalisht e mundur.

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

Dhe në përfundim të kësaj prezantimi të vogël, mund të thuhet se ClickHouse tani ka pushtuar qartë territorin e bazave të të dhënave komerciale dhe atyre open source, dmth për analitikë. Ai është integruar mjaft mirë në këtë peizazh. Dhe më shumë, ai ngadalë po fillon të zëvendësojë të tjerë, sepse kur keni ClickHouse, nuk keni nevojë për InfiniDB. Vertica, ndoshta së shpejti nuk do të jetë e nevojshme, nëse ata bëjnë mbështetje të mirë për SQL. Përdorni!

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

—Faleminderit pĂ«r raportin! Mjaft interesante! A pati ndonjĂ« krahasim me Apache Phoenix?

-Jo, nuk kam dëgjuar që dikush ka bërë krahasim. Ne dhe Yandex përpiqemi të ndjekim të gjitha krahasimet e ClickHouse me bazat e të dhënave të ndryshme. Sepse nëse ndonjëherë ndodh që diçka të jetë më e shpejtë se ClickHouse, Aleksei Milovidov nuk mund të fleë natën dhe fillon ta përshpejtojë shpejt. Nuk kam dëgjuar për një krahasim të tillë.

  • (Aleksei Milovidov) Apache Phoenix Ă«shtĂ« njĂ« motor SQL pĂ«r Hbase. Hbase kryesisht Ă«shtĂ« menduar pĂ«r skenarĂ« pune tĂ« tipit key-value. 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 tĂ« tilla si Hbase, Cassandra. Dhe pĂ«r to, kĂ«rkesat analitike tĂ« rĂ«nda nuk do tĂ« funksionojnĂ« mirĂ«. Ose mund tĂ« mendoni se ato funksionojnĂ« mirĂ«, nĂ«se nuk keni pasur ndonjĂ« pĂ«rvojĂ« pune me ClickHouse.

  • anonim kommentatorit

    • MirĂ«dita! UnĂ« kam bĂ«rĂ« mjaft hulumtime nĂ« kĂ«tĂ« temĂ«, sepse kam njĂ« nĂ«n-sistem analitik. Por kur shikoj nĂ« ClickHouse, kam ndjenjĂ«n se ClickHouse Ă«shtĂ« shumĂ« i pĂ«rshtatshĂ«m pĂ«r analizimin e eventeve, mutable. Dhe nĂ«se mĂ« duhet tĂ« analizoj shumĂ« tĂ« dhĂ«na biznesi me shumĂ« tabela tĂ« mĂ«dha, atĂ«herĂ« ClickHouse, sa po kuptoj, nuk mĂ« pĂ«rshtatet shumĂ«? Sidomos nĂ«se ato ndryshojnĂ«. A Ă«shtĂ« e saktĂ« kjo apo ka shembuj qĂ« mund ta mohojnĂ« kĂ«tĂ«?

    • Kjo Ă«shtĂ« e saktĂ«. Dhe kjo Ă«shtĂ« e vĂ«rtetĂ« pĂ«r shumicĂ«n e bazave tĂ« dhĂ«nash analitike tĂ« specializuara. Ato janĂ« tĂ« pĂ«rshtatura pĂ«r atĂ« qĂ« ekziston njĂ« ose disa tabela tĂ« mĂ«dha, tĂ« cilat janĂ« mutable, dhe shumĂ« tĂ« vogla, tĂ« cilat ndryshojnĂ« ngadalĂ«. KĂ«shtu, ClickHouse nuk Ă«shtĂ« si Oracle, ku mund tĂ« vendosni gjithçka dhe tĂ« ndĂ«rttoni disa kĂ«rkesa shumĂ« tĂ« komplikuara. PĂ«r tĂ« pĂ«rdorur ClickHouse nĂ« mĂ«nyrĂ« efektive, duhet tĂ« strukturohet skema nĂ« njĂ« mĂ«nyrĂ« qĂ« funksionon mirĂ« nĂ« ClickHouse. Kjo do tĂ« thotĂ« qĂ« tĂ« evitoni normalizimin e tepruar, tĂ« pĂ«rdorni fjalorĂ«, dhe tĂ« pĂ«rpiqeni tĂ« krijoni sa mĂ« pak lidhje tĂ« gjata. NĂ«se skema strukturohet kĂ«shtu, atĂ«herĂ« detyra tĂ« ngjashme biznesi nĂ« ClickHouse mund tĂ« zgjidhen shumĂ« mĂ« efikasitet se nĂ« njĂ« bazĂ« tĂ« dhĂ«nash tradicionale relationale.

Faleminderit për raportin! Kam një pyetje për rastin e fundit financiar. Ata kishin analitikë. Duhej të krahasoheshin, si shkojnë lart-poshtë. Dhe e kuptoj që ju e ndërtuat sistemin pikërisht për këtë analitikë? Nëse ata nesër, për shembull, kanë nevojë për një raport tjetër mbi këto të dhëna, duhet të rindërtojnë përsëri skemën dhe të ngarkojnë të dhënat? Kështu, a duhet të bëni ndonjë përpunim paraprak për të marrë kërkesën?

Sigurisht, kjo Ă«shtĂ« pĂ«rdorimi i ClickHouse pĂ«r njĂ« detyrĂ« tĂ« caktuar. Ajo tradicionalisht mund tĂ« zgjidhet brenda Hadoop. PĂ«r Hadoop – kjo Ă«shtĂ« njĂ« detyrĂ« ideale. Por nĂ« Hadoop Ă«shtĂ« shumĂ« e ngadalshme. Dhe qĂ«llimi im Ă«shtĂ« tĂ« demonstrohet se nĂ« ClickHouse mund tĂ« zgjidhen detyra qĂ« zakonisht zgjidhen me mjete krejtĂ«sisht tĂ« tjera, por me shumĂ« efikasitet mĂ« tĂ« madh. Kjo Ă«shtĂ« e fokusuar pĂ«r njĂ« detyrĂ« specifike. E qartĂ« Ă«shtĂ« qĂ« nĂ«se ka njĂ« detyrĂ« tĂ« ngjashme, atĂ«herĂ« mund tĂ« zgjidhet nĂ« njĂ« mĂ«nyrĂ« tĂ« ngjashme.

E kuptoj. Ju thatë se u procesuan 50 orë. A ka filluar nga fillimi, kur ngarkuat të dhënat apo morët rezultatet?

Po-po.

Mirë, faleminderit shumë.

Kjo ndodhi në një klaster me 3 serverë.

Përshëndetje! Faleminderit për raportin! Gjithçka është shumë interesante. Po pyes pak për funksionimin, jo për funksionalitetin, por për përdorimin e ClickHouse nga pikëpamja e stabilitetit. A ka ndodhur ndonjëherë që ju të keni pasur nevojë të rikuperoni? Si sillet ClickHouse gjatë kësaj? Dëshiruam të dija nëse ka ndodhur që edhe replika ka rënë? Ne, për shembull, kemi hasur në një problem me ClickHouse, kur ai papritmas kalon limitin e tij dhe bie.

Sigurisht, nuk ka sisteme perfekte. Edhe ClickHouse ka problemet e tij. Por a keni dëgjuar ndonjëherë që Yandex.Metrica të mos funksiononte për një kohë të gjatë? Ndoshta jo. Ajo funksionon besnikërisht që nga viti 2012-2013 në ClickHouse. Mund të flas edhe për përvojën time. Kurrë nuk kemi pasur ndalime të plota. Disa çështje pjesore mund të ndodhnin, por kurrë nuk kanë qenë kaq kritike sa të ndikojnë seriozisht në biznes. Kurrë nuk ka ndodhur një gjë e tillë. ClickHouse është mjaft i besueshëm dhe nuk bie rastësisht. Nuk keni arsye të shqetësoheni për këtë. Nuk është një gjë e papërfunduar. Kjo është provuar nga shumë kompani.

Përshëndetje! Ju thatë se duhet të mendoni mirë për mendimin tuaj të dhënave që në fillim. Por çfarë ndodhi nëse kjo ndodhi? Të dhënat po derdhen vazhdimisht. Kalojnë gjashtë muaj dhe unë kuptoj se nuk mund të jetoj kështu, duhet të ripak të dhënat dhe të bëj diçka me to.

Kjo varet, sigurisht, nga sistemi juaj. Ka disa mënyra për ta bërë këtë pothuajse pa ndalim. Për shembull, mund të krijoni një Materialized View, në të cilin të bëni një strukturë të ndryshme të të dhënave, nëse ajo mund të mapeohet qartë. Domethënë, nëse lejon mapimin përmes ClickHouse, që do të thotë të nxjerrësh disa gjëra, të ndryshosh çelësin kryesor, të ndryshosh ndarjen, atëherë mund të krijosh një Materialized View. Aty do të shkruhen të dhënat tuaja të vjetra, dhe të rejat do të shkruhen automatikisht. Pastaj thjesht kaloni në përdorimin e Materialized View, më pas ndërroni shkresën dhe shkatërroni tabelën e vjetër. Kjo është një metodë pa ndalim.

Faleminderit.

Burimi: habr.com

Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster