Theori ac ymarfer o ddefnyddio ClickHouse mewn cymwysiadau go iawn. Alexander Zaitsev (2018)

Er gwaethaf y ffaith bod llawer o ddata bron ym mhobman bellach, mae cronfeydd data dadansoddol yn dal yn eithaf egsotig. Nid ydynt yn hysbys iawn ac yn waeth byth maent yn gallu eu defnyddio'n effeithiol. Mae llawer yn parhau i "fwyta cactws" gyda MySQL neu PostgreSQL, sydd wedi'u cynllunio ar gyfer senarios eraill, yn dioddef gyda NoSQL, neu'n gordalu am atebion masnachol. Mae ClickHouse yn newid rheolau'r gêm ac yn gostwng yn sylweddol y trothwy ar gyfer mynd i mewn i fyd DBMS dadansoddol.

Adroddiad gan BackEnd Conf 2018 ac fe'i cyhoeddir gyda chaniatâd y siaradwr.

Pwy ydw i a pham ydw i'n siarad am ClickHouse? Rwy'n gyfarwyddwr datblygu yn LifeStreet, sy'n defnyddio ClickHouse. Hefyd, fi yw sylfaenydd Altinity. Mae'n bartner Yandex sy'n hyrwyddo ClickHouse ac yn helpu Yandex i wneud ClickHouse yn fwy llwyddiannus. Hefyd yn barod i rannu gwybodaeth am ClickHouse.

A dydw i ddim yn frawd i Petya Zaitsev. Gofynnir i mi yn aml am hyn. Na, nid brodyr ydym.

“Mae pawb yn gwybod” bod ClickHouse:

• Cyflym iawn,
• Cyfforddus iawn
• Defnyddir yn Yandex.

Mae ychydig yn llai yn hysbys ym mha gwmnïau a sut y caiff ei ddefnyddio.

Byddaf yn dweud wrthych pam, ble a sut y defnyddir ClickHouse, ac eithrio Yandex.

Byddaf yn dweud wrthych sut mae tasgau penodol yn cael eu datrys gyda chymorth ClickHouse mewn gwahanol gwmnïau, pa offer ClickHouse y gallwch eu defnyddio ar gyfer eich tasgau, a sut y cawsant eu defnyddio mewn gwahanol gwmnïau.

Codais dair enghraifft sy'n dangos ClickHouse o wahanol onglau. Rwy'n meddwl y bydd yn ddiddorol.

Y cwestiwn cyntaf yw: “Pam mae angen ClickHouse arnom?”. Ymddengys ei fod yn gwestiwn gweddol amlwg, ond mae mwy nag un ateb iddo.

• Yr ateb cyntaf yw perfformiad. Mae ClickHouse yn gyflym iawn. Mae dadansoddeg ar ClickHouse hefyd yn gyflym iawn. Yn aml gellir ei ddefnyddio lle mae rhywbeth arall yn araf iawn neu'n ddrwg iawn.
• Yr ail ateb yw cost. Ac yn gyntaf oll, cost graddio. Er enghraifft, mae Vertica yn gronfa ddata hollol wych. Mae'n gweithio'n dda iawn os nad oes gennych lawer o terabytes o ddata. Ond pan ddaw i gannoedd o terabytes neu petabytes, mae cost trwydded a chymorth yn mynd i swm eithaf sylweddol. Ac mae'n ddrud. Ac mae ClickHouse yn rhad ac am ddim.
• Y trydydd ateb yw cost gweithredu. Mae hwn yn ddull ychydig yn wahanol. Mae RedShift yn analog gwych. Ar RedShift, gallwch wneud penderfyniad yn gyflym iawn. Bydd yn gweithio'n dda, ond ar yr un pryd, bob awr, bob dydd, a bob mis, byddwch yn talu Amazon yn eithaf drud, oherwydd mae hwn yn wasanaeth sylweddol ddrud. Google BigQuery hefyd. Pe bai rhywun yn ei ddefnyddio, yna mae'n gwybod y gallwch chi redeg sawl cais a chael bil am gannoedd o ddoleri yn sydyn.

Nid oes gan ClickHouse y problemau hyn.

Ble mae ClickHouse yn cael ei ddefnyddio nawr? Yn ogystal â Yandex, defnyddir ClickHouse mewn criw o wahanol fusnesau a chwmnïau.

• Yn gyntaf oll, dadansoddeg cymwysiadau gwe yw hwn, h.y. mae hwn yn achos defnydd a ddaeth o Yandex.
• Mae llawer o gwmnïau AdTech yn defnyddio ClickHouse.
• Nifer o gwmnïau sydd angen dadansoddi logiau trafodion o wahanol ffynonellau.
• Mae sawl cwmni'n defnyddio ClickHouse i fonitro logiau diogelwch. Maent yn eu huwchlwytho i ClickHouse, yn gwneud adroddiadau, ac yn cael y canlyniadau sydd eu hangen arnynt.
• Mae cwmnïau'n dechrau ei ddefnyddio mewn dadansoddiad ariannol, h.y. yn raddol mae busnesau mawr hefyd yn agosáu at ClickHouse.
• fflêr cymylau. Os bydd rhywun yn dilyn ClickHouse, yna mae'n debyg eu bod wedi clywed enw'r cwmni hwn. Mae hwn yn un o'r cyfranwyr hanfodol o'r gymuned. Ac mae ganddyn nhw osodiad ClickHouse difrifol iawn. Er enghraifft, gwnaethant Kafka Engine ar gyfer ClickHouse.
• Dechreuodd cwmnïau telathrebu ddefnyddio. Mae sawl cwmni'n defnyddio ClickHouse naill ai fel prawf ar gysyniad neu eisoes yn cael ei gynhyrchu.
• Mae un cwmni'n defnyddio ClickHouse i fonitro prosesau cynhyrchu. Maent yn profi microcircuits, yn dileu criw o baramedrau, mae tua 2 o nodweddion. Ac yna maen nhw'n dadansoddi a yw'r gêm yn dda neu'n ddrwg.
• Dadansoddeg Blockchain. Mae yna gwmni o'r fath yn Rwsia â Bloxy.info. Mae hwn yn ddadansoddiad o'r rhwydwaith ethereum. Fe wnaethant hyn hefyd ar ClickHouse.

Ac nid yw'r maint o bwys. Mae yna lawer o gwmnïau sy'n defnyddio un gweinydd bach. Ac mae'n caniatáu iddynt ddatrys eu problemau. Ac mae hyd yn oed mwy o gwmnïau'n defnyddio clystyrau mawr o lawer o weinyddion neu ddwsinau o weinyddion.

Ac os edrychwch ar y cofnodion, yna:

• Yandex: 500+ o weinyddion, maen nhw'n storio 25 biliwn o gofnodion y dydd yno.
• LifeStreet: 60 o weinyddion, tua 75 biliwn o gofnodion y dydd. Mae llai o weinyddion, mwy o gofnodion nag yn Yandex.
• CloudFlare: 36 o weinyddion, maen nhw'n arbed 200 biliwn o gofnodion y dydd. Mae ganddyn nhw lai fyth o weinyddion ac maen nhw'n storio hyd yn oed mwy o ddata.
• Bloomberg: 102 o weinyddion, tua thriliwn o gofnodion y dydd. Deilydd cofnod.

Yn ddaearyddol, mae hyn hefyd yn llawer. Mae'r map yma yn dangos map gwres o ble mae ClickHouse yn cael ei ddefnyddio yn y byd. Mae Rwsia, Tsieina, America yn sefyll allan yn glir yma. Ychydig o wledydd Ewropeaidd sydd. Ac mae yna 4 clwstwr.

Mae hwn yn ddadansoddiad cymharol, nid oes angen edrych am ffigurau absoliwt. Mae hwn yn ddadansoddiad o ymwelwyr sy'n darllen deunyddiau Saesneg ar wefan Altinity, oherwydd nid oes unrhyw rai sy'n siarad Rwsieg yno. A Rwsia, Wcráin, Belarus, h.y. y rhan o'r gymuned sy'n siarad Rwsieg, dyma'r defnyddwyr mwyaf niferus. Yna daw'r Unol Daleithiau a Chanada. Mae Tsieina yn dal i fyny yn fawr iawn. Nid oedd bron dim Tsieina yno chwe mis yn ôl, erbyn hyn mae Tsieina eisoes wedi goddiweddyd Ewrop ac yn parhau i dyfu. Nid yw Hen Ewrop ymhell ar ei hôl hi ychwaith, a Ffrainc yw'r arweinydd yn y defnydd o ClickHouse, yn rhyfedd ddigon.

Pam ydw i'n dweud hyn i gyd? I ddangos bod ClickHouse yn dod yn ddatrysiad safonol ar gyfer dadansoddi data mawr a'i fod eisoes yn cael ei ddefnyddio mewn llawer o leoedd. Os ydych chi'n ei ddefnyddio, rydych chi yn y duedd iawn. Os nad ydych chi'n ei ddefnyddio eto, yna ni allwch ofni y cewch eich gadael ar eich pen eich hun ac ni fydd unrhyw un yn eich helpu, oherwydd mae llawer eisoes yn gwneud hyn.

Mae'r rhain yn enghreifftiau o ddefnydd ClickHouse go iawn mewn sawl cwmni.

• Yr enghraifft gyntaf yw rhwydwaith hysbysebu: mudo o Vertica i ClickHouse. Ac rwy'n gwybod am rai cwmnïau sydd wedi trosglwyddo o Vertica neu sydd yn y broses o drawsnewid.
• Yr ail enghraifft yw storio trafodion ar ClickHouse. Dyma enghraifft sydd wedi'i hadeiladu ar wrthbatrwm. Mae popeth na ddylid ei wneud yn ClickHouse ar gyngor datblygwyr yn cael ei wneud yma. Ac mae'n cael ei wneud mor effeithiol fel ei fod yn gweithio. Ac mae'n gweithio'n llawer gwell na'r ateb trafodion nodweddiadol.
• Y drydedd enghraifft yw cyfrifiadura dosranedig ar ClickHouse. Roedd cwestiwn ynghylch sut y gellir integreiddio ClickHouse i ecosystem Hadoop. Byddaf yn dangos enghraifft o sut y gwnaeth cwmni rywbeth tebyg i gynhwysydd lleihau map ar ClickHouse, gan gadw golwg ar leoleiddio data, ac ati, i gyfrifo tasg nad yw'n ddibwys iawn.

• Mae LifeStreet yn gwmni Ad Tech sydd â'r holl dechnoleg sy'n dod gyda rhwydwaith hysbysebu.
• Mae hi'n ymwneud ag optimeiddio hysbysebion, bidio rhaglennol.
• Llawer o ddata: tua 10 biliwn o ddigwyddiadau y dydd. Ar yr un pryd, gellir rhannu digwyddiadau yno yn nifer o is-ddigwyddiadau.
• Mae yna lawer o gleientiaid o'r data hwn, ac nid pobl yn unig yw'r rhain, llawer mwy - mae'r rhain yn algorithmau amrywiol sy'n ymwneud â bidio rhaglennol.

Mae'r cwmni wedi dod yn llwybr hir a dyrys. A siaradais amdano ar HighLoad. Yn gyntaf, symudodd LifeStreet o MySQL (gyda stop byr yn Oracle) i Vertica. A gallwch ddod o hyd i stori amdano.

Ac roedd popeth yn dda iawn, ond daeth yn amlwg yn gyflym bod y data'n tyfu a bod Vertica yn ddrud. Felly, ceisiwyd gwahanol ddewisiadau. Rhestrir rhai ohonynt yma. Ac mewn gwirionedd, gwnaethom brawf cysyniad neu weithiau profion perfformiad o bron pob cronfa ddata a oedd ar gael ar y farchnad o'r 13eg i'r 16eg flwyddyn ac a oedd yn fwy addas o ran ymarferoldeb. A soniais hefyd am rai ohonyn nhw ar HighLoad.

Y dasg oedd mudo o Vertica yn y lle cyntaf, oherwydd tyfodd y data. Ac fe wnaethon nhw dyfu'n esbonyddol dros y blynyddoedd. Yna aethant ar y silff, ond serch hynny. Ac yn rhagweld y twf hwn, gofynion busnes ar gyfer faint o ddata y mae angen gwneud rhyw fath o ddadansoddeg, roedd yn amlwg y byddai petabytes yn cael eu trafod yn fuan. Ac mae talu am petabytes eisoes yn ddrud iawn, felly roeddem yn chwilio am ddewis arall ble i fynd.

Ble i fynd? Ac am amser hir nid oedd yn glir o gwbl ble i fynd, oherwydd ar y naill law mae cronfeydd data masnachol, mae'n ymddangos eu bod yn gweithio'n dda. Mae rhai yn gweithio bron cystal â Vertica, rhai yn waeth. Ond maen nhw i gyd yn ddrud, dim byd rhatach ac ni ellid dod o hyd i ddim gwell.

Ar y llaw arall, mae yna atebion ffynhonnell agored, nad ydyn nhw'n niferus iawn, h.y. ar gyfer dadansoddeg, gellir eu cyfrif ar y bysedd. Ac maen nhw'n rhad ac am ddim neu'n rhad, ond yn araf. Ac yn aml nid oes ganddynt y swyddogaethau angenrheidiol a defnyddiol.

Ac nid oedd dim i gyfuno'r da sydd mewn cronfeydd data masnachol a'r holl rhad ac am ddim sydd mewn ffynhonnell agored.

Doedd dim byd nes, yn annisgwyl, i Yandex dynnu ClickHouse allan, fel consuriwr o het, fel cwningen. Ac roedd yn benderfyniad annisgwyl, maent yn dal i ofyn y cwestiwn: “Pam?”, ond serch hynny.

Ac ar unwaith yn ystod haf 2016, dechreuon ni edrych ar beth yw ClickHouse. Ac mae'n troi allan y gall weithiau fod yn gyflymach na Vertica. Fe wnaethon ni brofi gwahanol senarios ar wahanol ymholiadau. Ac os oedd yr ymholiad yn defnyddio un bwrdd yn unig, hynny yw, heb unrhyw uniadau (join), yna roedd ClickHouse ddwywaith mor gyflym â Vertica.

Nid oeddwn yn rhy ddiog ac edrychais ar brofion Yandex y diwrnod o'r blaen. Mae'r un peth yno: mae ClickHouse ddwywaith mor gyflym â Vertica, felly maen nhw'n aml yn siarad amdano.

Ond os oes uniadau yn yr ymholiadau, yna nid yw popeth yn troi allan yn ddiamwys iawn. A gall ClickHouse fod ddwywaith mor araf â Vertica. Ac os ydych chi ychydig yn cywiro'r cais a'i ailysgrifennu, yna maen nhw bron yn gyfartal. Ddim yn ddrwg. Ac am ddim.

Ac ar ôl derbyn canlyniadau'r profion, ac edrych arno o wahanol onglau, aeth LifeStreet i ClickHouse.

Dyma'r 16eg flwyddyn, rwy'n eich atgoffa. Roedd fel jôc am lygod yn crio ac yn pigo eu hunain, ond yn parhau i fwyta'r cactws. A disgrifiwyd hyn yn fanwl, mae fideo am hyn, ac ati.

Felly, ni siaradaf amdano’n fanwl, ni fyddaf ond yn siarad am y canlyniadau ac ychydig o bethau diddorol na siaradais amdanynt bryd hynny.

Y canlyniadau yw:

• Mudo llwyddiannus a mwy na blwyddyn mae'r system eisoes yn gweithio ym maes cynhyrchu.
• Mae cynhyrchiant a hyblygrwydd wedi cynyddu. O'r 10 biliwn o gofnodion y gallem fforddio eu storio bob dydd ac yna am gyfnod byr, mae LifeStreet bellach yn storio 75 biliwn o gofnodion y dydd a gallant wneud hyn am 3 mis neu fwy. Os ydych chi'n cyfrif ar y brig, yna mae hyn hyd at filiwn o ddigwyddiadau yr eiliad. Mae mwy na miliwn o ymholiadau SQL y dydd yn cyrraedd y system hon, yn bennaf gan wahanol robotiaid.
• Er gwaethaf y ffaith bod mwy o weinyddion yn cael eu defnyddio ar gyfer ClickHouse nag ar gyfer Vertica, fe wnaethant hefyd arbed ar galedwedd, oherwydd defnyddiwyd disgiau SAS braidd yn ddrud yn Vertica. Defnyddiodd ClickHouse SATA. A pham? Oherwydd yn Vertica mewnosoder yn gydamserol. Ac mae cydamseru yn ei gwneud yn ofynnol nad yw'r disgiau'n arafu gormod, a hefyd nad yw'r rhwydwaith yn arafu gormod, hynny yw, gweithrediad eithaf drud. Ac yn ClickHouse mewnosod yn asyncronaidd. Ar ben hynny, gallwch chi bob amser ysgrifennu popeth yn lleol, nid oes unrhyw gostau ychwanegol ar gyfer hyn, felly gellir mewnosod data yn ClickHouse yn gynt o lawer nag yn Vertika, hyd yn oed ar yriannau arafach. Ac mae darllen tua'r un peth. Wrth ddarllen ar SATA, os ydyn nhw mewn RAID, yna mae hyn i gyd yn ddigon cyflym.
• Heb ei gyfyngu gan drwydded, h.y. 3 phetabeit o ddata mewn 60 o weinyddion (mae 20 o weinyddion yn un replica) a 6 triliwn o gofnodion mewn ffeithiau a chyfuniadau. Ni ellid fforddio dim fel hyn yn Vertica.

Trof yn awr at bethau ymarferol yn yr enghraifft hon.

• Mae'r cyntaf yn gynllun effeithlon. Mae llawer yn dibynnu ar y sgema.
• Yr ail yw cynhyrchu SQL effeithlon.

Mae ymholiad OLAP nodweddiadol yn ddetholiad. Mae rhai o'r colofnau'n mynd i grwpio yn ôl, mae rhai o'r colofnau'n mynd i swyddogaethau cyfanredol. Mae lle, y gellir ei gynrychioli fel sleisen o giwb. Gellir meddwl am y grŵp cyfan fel tafluniad. A dyna pam y'i gelwir yn ddadansoddiad data aml-amrywedd.

Ac yn aml mae hyn yn cael ei fodelu ar ffurf cynllun seren, pan fydd ffaith ganolog a nodweddion y ffaith hon ar hyd yr ochrau, ar hyd y pelydrau.

Ac o ran dyluniad corfforol, sut mae'n ffitio ar y bwrdd, maen nhw fel arfer yn gwneud cynrychiolaeth normal. Gallwch ddadnormaleiddio, ond mae'n ddrud ar ddisg ac nid yw'n effeithlon iawn ar ymholiadau. Felly, maent fel arfer yn gwneud cynrychiolaeth normal, h.y. tabl ffeithiau a llawer, llawer o dablau dimensiwn.

Ond nid yw'n gweithio'n dda yn ClickHouse. Mae dau reswm:

• Mae'r cyntaf oherwydd nad oes gan ClickHouse uniadau da iawn, h.y. mae yna uniadau, ond maen nhw'n ddrwg. Tra yn ddrwg.
• Yr ail yw nad yw'r tablau'n cael eu diweddaru. Fel arfer yn y platiau hyn, sydd o amgylch y gylched seren, mae angen newid rhywbeth. Er enghraifft, enw cwsmer, enw cwmni, ac ati. Ac nid yw'n gweithio.

Ac mae ffordd allan o hyn yn ClickHouse. hyd yn oed dau:

• Y cyntaf yw'r defnydd o eiriaduron. Geiriaduron Allanol yw'r hyn sy'n helpu 99% i ddatrys y broblem gyda'r sgema seren, gyda diweddariadau ac ati.
• Yr ail yw'r defnydd o araeau. Mae araeau hefyd yn helpu i gael gwared ar uniadau a phroblemau gyda normaleiddio.

• Nid oes angen ymuno.
• Uwchraddadwy. Ers mis Mawrth 2018, mae cyfle heb ei ddogfennu wedi ymddangos (ni welwch hwn yn y ddogfennaeth) i ddiweddaru geiriaduron yn rhannol, h.y. y cofnodion hynny sydd wedi newid. Yn ymarferol, mae fel bwrdd.
• Bob amser yn y cof, felly yn ymuno â geiriadur yn gweithio'n gyflymach na phe bai'n fwrdd sydd ar ddisg ac nid yw'n ffaith eto ei fod yn y storfa, nid yn fwyaf tebygol.

• Nid oes angen i chi ymuno chwaith.
• Mae hwn yn gynrychiolaeth gryno 1-i-lawer.
• Ac yn fy marn i, gwneir araeau ar gyfer geeks. Mae'r rhain yn swyddogaethau lambda ac yn y blaen.

Nid yw hyn ar gyfer geiriau coch. Mae hwn yn ymarferoldeb pwerus iawn sy'n eich galluogi i wneud llawer o bethau mewn ffordd syml a chain iawn.

Enghreifftiau nodweddiadol sy'n helpu i ddatrys araeau. Mae’r enghreifftiau hyn yn ddigon syml a chlir:

• Chwilio yn ôl tagiau. Os oes gennych chi hashnodau yno ac eisiau dod o hyd i rai postiadau trwy hashnod.
• Chwilio yn ôl parau gwerth allweddol. Mae yna hefyd rai nodweddion sydd â gwerth.
• Yn storio rhestrau o allweddi y mae angen ichi eu cyfieithu i rywbeth arall.

Gellir datrys yr holl dasgau hyn heb araeau. Gellir rhoi tagiau mewn rhyw linell a'u dewis gyda mynegiant rheolaidd neu mewn tabl ar wahân, ond yna mae'n rhaid i chi wneud uniadau.

Ac yn ClickHouse, nid oes angen i chi wneud unrhyw beth, mae'n ddigon i ddisgrifio'r arae llinynnol ar gyfer hashnodau neu wneud strwythur nythu ar gyfer systemau gwerth allweddol.

Efallai nad adeiledd nythu yw'r enw gorau. Mae'r rhain yn ddwy arae sydd â rhan gyffredin yn yr enw a rhai nodweddion cysylltiedig.

Ac mae'n hawdd iawn chwilio yn ôl tag. Cael swyddogaeth has, sy'n gwirio bod yr arae yn cynnwys elfen. Pawb, wedi dod o hyd i'r holl gofnodion sy'n ymwneud â'n cynhadledd.

Mae chwilio yn ôl subid ychydig yn fwy cymhleth. Mae angen i ni ddod o hyd i fynegai'r allwedd yn gyntaf, ac yna cymryd yr elfen gyda'r mynegai hwn a gwirio mai'r gwerth hwn yw'r hyn sydd ei angen arnom. Fodd bynnag, mae'n syml iawn ac yn gryno.

Y mynegiad rheolaidd yr hoffech ei ysgrifennu pe byddech yn cadw'r cyfan mewn un llinell, byddai, yn gyntaf, yn drwsgl. Ac, yn ail, fe weithiodd yn llawer hirach na dwy arae.

Enghraifft arall. Mae gennych arae lle rydych chi'n storio'r ID. A gallwch chi eu cyfieithu i enwau. Swyddogaeth arrayMap. Mae hon yn swyddogaeth lambda nodweddiadol. Rydych chi'n pasio ymadroddion lambda yno. Ac mae hi'n tynnu allan werth yr enw ar gyfer pob ID o'r geiriadur.

Gellir chwilio yn yr un modd. Mae swyddogaeth rhagfynegi yn cael ei phasio sy'n gwirio beth mae'r elfennau'n cyfateb.

Mae'r pethau hyn yn symleiddio'r gylched yn fawr ac yn datrys criw o broblemau.

Ond y broblem nesaf yr ydym yn ei hwynebu, ac yr hoffwn sôn amdani, yw ymholiadau effeithlon.

• Nid oes gan ClickHouse gynllunydd ymholiad. Ddim o gwbl.
• Serch hynny, mae angen cynllunio ymholiadau cymhleth o hyd. Ym mha achosion?
• Os oes sawl uniad yn yr ymholiad, rydych chi'n eu lapio mewn is-ddewisiadau. Ac mae'r drefn y cânt eu gweithredu yn bwysig.
• A'r ail - os yw'r cais yn cael ei ddosbarthu. Oherwydd mewn ymholiad dosranedig, dim ond yr is-ddewis mwyaf mewnol sy'n cael ei ddosbarthu, ac mae popeth arall yn cael ei drosglwyddo i un gweinydd y gwnaethoch chi gysylltu ag ef a'i weithredu yno. Felly, os ydych chi wedi dosbarthu ymholiadau gyda llawer o ymuno (join), yna mae angen i chi ddewis y drefn.

A hyd yn oed mewn achosion symlach, weithiau mae hefyd yn angenrheidiol i wneud gwaith y trefnydd ac ailysgrifennu ymholiadau ychydig.

Dyma enghraifft. Ar yr ochr chwith mae ymholiad sy'n dangos y 5 gwlad orau. Ac mae'n cymryd 2,5 eiliad, yn fy marn i. Ac ar yr ochr dde, yr un ymholiad, ond wedi'i ailysgrifennu ychydig. Yn hytrach na grwpio yn ôl llinyn, dechreuon ni grwpio yn ôl allwedd (int). Ac mae'n gyflymach. Ac yna fe wnaethon ni gysylltu geiriadur â'r canlyniad. Yn hytrach na 2,5 eiliad, mae'r cais yn cymryd 1,5 eiliad. Mae hyn yn dda.

Enghraifft debyg gyda hidlwyr ailysgrifennu. Dyma gais am Rwsia. Mae'n rhedeg am 5 eiliad. Os byddwn yn ei ailysgrifennu yn y fath fodd fel ein bod yn cymharu eto nid llinyn, ond rhifau gyda rhai set o'r allweddi hynny sy'n ymwneud â Rwsia, yna bydd yn llawer cyflymach.

Mae yna lawer o driciau o'r fath. Ac maen nhw'n caniatáu ichi gyflymu'n sylweddol ymholiadau rydych chi'n meddwl sydd eisoes yn rhedeg yn gyflym, neu, i'r gwrthwyneb, yn rhedeg yn araf. Gellir eu gwneud hyd yn oed yn gyflymach.

• Uchafswm gwaith yn y modd gwasgaredig.
• Didoli yn ôl mathau lleiaf, fel y gwnes i gan ints.
• Os oes unrhyw uniadau (join), geiriaduron, yna mae'n well eu gwneud fel y dewis olaf, pan fydd gennych ddata eisoes wedi'i grwpio'n rhannol o leiaf, yna bydd y gweithrediad ymuno neu alwad geiriadur yn cael ei alw'n llai o weithiau a bydd yn gyflymach. .
• Ailosod hidlwyr.

Mae technegau eraill, ac nid dim ond y rhai yr wyf wedi’u dangos. Ac weithiau gall pob un ohonynt gyflymu'r broses o gyflawni ymholiadau yn sylweddol.

Gadewch i ni symud ymlaen at yr enghraifft nesaf. Cwmni X o UDA. Beth mae hi'n gwneud?

Roedd tasg:

• Cysylltu trafodion hysbysebu all-lein.
• Modelu gwahanol fodelau rhwymo.

Beth yw'r senario?

Mae ymwelydd cyffredin yn dod i'r wefan, er enghraifft, 20 gwaith y mis o wahanol hysbysebion, neu yn union fel yna weithiau'n dod heb unrhyw hysbysebion, oherwydd ei fod yn cofio'r wefan hon. Yn edrych ar rai cynhyrchion, yn eu rhoi yn y fasged, yn eu tynnu allan o'r fasged. Ac, yn y diwedd, mae rhywbeth yn prynu.

Cwestiynau rhesymol: "Pwy ddylai dalu am hysbysebu, os oes angen?" a “Pa hysbysebu a ddylanwadodd arno, os o gwbl?”. Hynny yw, pam y prynodd a sut i gael pobl fel y person hwn i brynu hefyd?

Er mwyn datrys y broblem hon, mae angen i chi gysylltu'r digwyddiadau sy'n digwydd ar y wefan yn y ffordd gywir, hynny yw, rhywsut adeiladu cysylltiad rhyngddynt. Yna fe'u hanfonir i DWH i'w dadansoddi. Ac yn seiliedig ar y dadansoddiad hwn, adeiladu modelau o bwy a pha hysbysebion i'w dangos.

Mae trafodiad hysbyseb yn set o ddigwyddiadau defnyddwyr cysylltiedig sy'n dechrau o ddangos hysbyseb, yna mae rhywbeth yn digwydd, yna efallai pryniant, ac yna efallai y bydd pryniannau o fewn pryniant. Er enghraifft, os yw hwn yn gais symudol neu gêm symudol, yna fel arfer mae gosod y cais yn digwydd am ddim, ac os gwneir rhywbeth yno, yna efallai y bydd angen arian ar gyfer hyn. A pho fwyaf y mae person yn ei wario yn y cais, y mwyaf gwerthfawr ydyw. Ond ar gyfer hyn mae angen i chi gysylltu popeth.

Mae yna lawer o fodelau rhwymol.

Y rhai mwyaf poblogaidd yw:

• Rhyngweithio Diwethaf, lle mae rhyngweithio naill ai'n glic neu'n argraff.
• Rhyngweithio Cyntaf, h.y. y peth cyntaf a ddaeth â pherson i’r safle.
• Cyfuniad llinellol - i gyd yn gyfartal.
• Gwanhau.
• Ac yn y blaen.

A sut y gweithiodd y cyfan yn y lle cyntaf? Roedd Runtime a Cassandra. Defnyddiwyd Cassandra fel storfa trafodion, h.y. roedd yr holl drafodion cysylltiedig yn cael eu storio ynddo. A phan ddaw rhyw ddigwyddiad yn Runtime, er enghraifft, yn dangos rhyw dudalen neu rywbeth arall, yna gwnaed cais i Cassandra - a oes person o'r fath ai peidio. Yna cafwyd y trafodion sy'n ymwneud ag ef. A gwnaed y cysylltiad.

Ac os yw'n ffodus bod gan y cais id trafodiad, yna mae'n hawdd. Ond fel arfer dim lwc. Felly, roedd angen dod o hyd i'r trafodiad olaf neu'r trafodiad gyda'r clic olaf, ac ati.

Ac fe weithiodd y cyfan yn dda iawn cyn belled â bod y rhwymiad i'r clic olaf. Oherwydd bod, dyweder, 10 miliwn o gliciau y dydd, 300 miliwn y mis, os byddwn yn gosod ffenestr am fis. Ac ers yn Cassandra mae'n rhaid iddo fod yn y cof i gyd er mwyn rhedeg yn gyflym, oherwydd bod angen i'r Runtime ymateb yn gyflym, cymerodd tua gweinyddwyr 10-15.

A phan oeddent am gysylltu trafodiad â'r arddangosfa, nid oedd mor hwyl ar unwaith. A pham? Gellir gweld bod angen storio 30 gwaith yn fwy o ddigwyddiadau. Ac, yn unol â hynny, mae angen 30 gwaith yn fwy o weinyddion arnoch chi. Ac mae'n ymddangos bod hwn yn rhyw fath o ffigwr seryddol. Er mwyn cadw hyd at 500 o weinyddion er mwyn gwneud y cysylltu, er gwaethaf y ffaith bod llawer llai o weinyddion yn Runtime, yna mae hwn yn rhyw fath o ffigwr anghywir. A dyma nhw'n dechrau meddwl beth i'w wneud.

Ac aethon ni i ClickHouse. A sut i wneud hynny ar ClickHouse? Ar yr olwg gyntaf, mae'n ymddangos mai set o wrth-batrymau yw hwn.

• Mae'r trafodiad yn tyfu, rydym yn cysylltu mwy a mwy o ddigwyddiadau ag ef, h.y. mae'n mutable, ac nid yw ClickHouse yn gweithio'n dda iawn gyda gwrthrychau mudadwy.
• Pan fydd ymwelydd yn dod atom, mae angen inni dynnu ei drafodion allan trwy allwedd, gan ei ymweliad id. Mae hwn hefyd yn ymholiad pwynt, nid ydynt yn gwneud hynny yn ClickHouse. Fel arfer mae gan ClickHouse sganiau mawr, ond yma mae angen i ni gael rhai cofnodion. Hefyd gwrthbatrwm.
• Yn ogystal, roedd y trafodiad yn json, ond nid oeddent am ei ailysgrifennu, felly roeddent am storio json mewn ffordd anstrwythuredig, ac os oedd angen, tynnu rhywbeth allan ohono. Ac mae hwn hefyd yn antipattern.

Hynny yw, set o wrthbatrymau.

Ond er hynny, daeth i fodolaeth system a weithiodd yn dda iawn.

Beth a wnaed? Ymddangosodd ClickHouse, y taflwyd boncyffion iddo, wedi'u rhannu'n gofnodion. Ymddangosodd gwasanaeth priodol a dderbyniodd logiau gan ClickHouse. Ar ôl hynny, ar gyfer pob cofnod, drwy id ymweliad, derbyniais drafodion nad oeddent efallai wedi’u prosesu eto, ynghyd â chipluniau, h.y. trafodion sydd eisoes wedi’u cysylltu, sef canlyniad gwaith blaenorol. Rwyf eisoes wedi gwneud rhesymeg allan ohonynt, dewisais y trafodiad cywir, cysylltu digwyddiadau newydd. Wedi mewngofnodi eto. Aeth y log yn ôl i ClickHouse, h.y. mae'n system gylchol gyson. Ac ar wahân, es i DWH i'w ddadansoddi yno.

Yn y ffurf hon nid oedd yn gweithio'n dda iawn. Ac i'w gwneud yn haws i ClickHouse, pan oedd cais trwy id ymweliad, fe wnaethant grwpio'r ceisiadau hyn yn flociau o 1-000 o IDau ymweliad a thynnu'r holl drafodion ar gyfer 2-000 o bobl allan. Ac yna fe weithiodd y cyfan.

Os edrychwch y tu mewn i ClickHouse, yna dim ond 3 phrif dabl sy'n gwasanaethu hyn i gyd.

Y tabl cyntaf y mae logiau'n cael eu huwchlwytho ynddo, a'r logiau'n cael eu llwytho i fyny bron heb eu prosesu.

Ail fwrdd. Trwy'r farn berthnasol, o'r logiau hyn, cafodd digwyddiadau nad ydynt wedi'u priodoli eto, h.y. rhai nad ydynt yn gysylltiedig, eu brathu. A thrwy'r olygfa wirioneddol, tynnwyd trafodion allan o'r logiau hyn i adeiladu ciplun. Hynny yw, adeiladodd golygfa sylweddol arbennig gipolwg, sef cyflwr cronedig olaf y trafodiad.

Dyma'r testun a ysgrifennwyd yn SQL. Hoffwn wneud sylw ar ychydig o bethau pwysig ynddo.

Y peth pwysig cyntaf yw'r gallu i dynnu colofnau a chaeau allan o json yn ClickHouse. Hynny yw, mae gan ClickHouse rai dulliau ar gyfer gweithio gyda json. Maent yn gyntefig iawn, iawn.

Mae visitParamExtractInt yn caniatáu ichi dynnu priodoleddau o json, h.y. y gweithiau taro cyntaf. Ac fel hyn gallwch chi dynnu id trafodiad neu id ymweld. Y tro hwn.

Yn ail, defnyddir maes materol anodd yma. Beth mae'n ei olygu? Mae hyn yn golygu na allwch ei fewnosod yn y tabl, h.y. nid yw'n cael ei fewnosod, caiff ei gyfrifo a'i storio wrth ei fewnosod. Wrth gludo, mae ClickHouse yn gwneud y gwaith i chi. Ac mae'r hyn sydd ei angen arnoch yn nes ymlaen eisoes wedi'i dynnu allan o json.

Yn yr achos hwn, mae golygfa wedi'i gwireddu ar gyfer rhesi amrwd. Ac mae'r tabl cyntaf gyda logiau bron yn amrwd yn cael ei ddefnyddio. A beth mae'n ei wneud? Yn gyntaf, mae'n newid y didoli, h.y. mae didoli nawr yn mynd trwy ID ymweliad, oherwydd mae angen i ni dynnu ei drafodiad ar gyfer person penodol yn gyflym.

Yr ail beth pwysig yw index_granularity. Os ydych chi wedi gweld MergeTree, fel arfer mae'n 8 yn ôl index_granularity rhagosodedig. Beth yw e? Dyma baramedr teneurwydd y mynegai. Yn ClickHouse mae'r mynegai yn denau, nid yw byth yn mynegeio pob cofnod. Gwna hyn bob 192 8. Ac y mae hyn yn dda pan y mae yn ofynol cyfrif llawer o ddata, ond y mae yn ddrwg pan ychydig, oblegid y mae gorphwysiad mawr. Ac os ydym yn lleihau'r gronynnedd mynegai, yna rydym yn lleihau'r gorbenion. Ni ellir ei leihau i un, oherwydd efallai na fydd digon o gof. Mae'r mynegai bob amser yn cael ei storio yn y cof.

Mae Ciplun hefyd yn defnyddio rhai nodweddion ClickHouse diddorol eraill.

Yn gyntaf, mae'n AggregatingMergeTree. Ac mae AggregatingMergeTree yn storio argMax, h.y. dyma gyflwr y trafodiad sy'n cyfateb i'r stamp amser diwethaf. Mae trafodion yn cael eu cynhyrchu drwy'r amser ar gyfer ymwelydd penodol. Ac yng nghyflwr olaf y trafodiad hwn, fe wnaethom ychwanegu digwyddiad ac mae gennym gyflwr newydd. Mae'n taro ClickHouse eto. A thrwy argMax yn y farn hon wedi'i gwireddu, gallwn bob amser gael y cyflwr presennol.

• Mae'r rhwymiad yn cael ei "ddatgysylltu" o'r Runtime.
• Mae hyd at 3 biliwn o drafodion y mis yn cael eu storio a'u prosesu. Mae hon yn drefn maint yn fwy nag yr oedd yn Cassandra, h.y. mewn system drafodion nodweddiadol.
• Clwstwr o weinyddion ClickHouse 2x5. 5 gweinydd ac mae gan bob gweinydd replica. Mae hyn hyd yn oed yn llai nag yr oedd yn Cassandra er mwyn gwneud priodoli ar sail clic, ac yma mae gennym ni yn seiliedig ar argraff. Hynny yw, yn lle cynyddu nifer y gweinyddwyr 30 gwaith, fe lwyddon nhw i'w lleihau.

A'r enghraifft olaf yw cwmni ariannol Y, a ddadansoddodd y cydberthnasau o newidiadau mewn prisiau stoc.

A'r dasg oedd:

• Mae tua 5 o gyfranddaliadau.
• Mae dyfynbrisiau bob 100 milieiliad yn hysbys.
• Mae'r data wedi'i gronni dros 10 mlynedd. Mae'n debyg, i rai cwmnïau yn fwy, i rai llai.
• Mae tua 100 biliwn o resi i gyd.

Ac roedd angen cyfrifo'r gydberthynas o newidiadau.

Dyma ddwy stoc a'u dyfynbrisiau. Os bydd un yn mynd i fyny a'r llall yn codi, yna mae hyn yn gydberthynas gadarnhaol, h.y. mae un yn mynd i fyny a'r llall yn codi. Os yw un yn mynd i fyny, fel ar ddiwedd y graff, a’r llall yn mynd i lawr, yna mae hwn yn gydberthynas negatif, h.y. pan fydd un yn codi, mae’r llall yn disgyn.

Wrth ddadansoddi'r newidiadau cydfuddiannol hyn, gall rhywun wneud rhagfynegiadau yn y farchnad ariannol.

Ond mae'r dasg yn anodd. Beth sy'n cael ei wneud ar gyfer hyn? Mae gennym 100 biliwn o gofnodion sydd â: amser, stoc, a phris. Mae angen i ni gyfrifo yn gyntaf 100 biliwn gwaith y Gwahaniaeth rhedeg oddi wrth yr algorithm pris. Mae RunningDifference yn swyddogaeth yn ClickHouse sy'n cyfrifo'r gwahaniaeth rhwng dau linyn yn olynol.

Ac ar ôl hynny, mae angen i chi gyfrifo'r gydberthynas, a rhaid cyfrifo'r gydberthynas ar gyfer pob pâr. Ar gyfer 5 o gyfranddaliadau, mae parau yn 000 miliwn. Ac mae hyn yn llawer, h.y. 12,5 gwaith mae angen cyfrifo swyddogaeth cydberthynas o'r fath yn unig.

Ac os bydd rhywun yn anghofio, yna mae ͞x a ͞y yn checkmate. disgwyliad samplu. Hynny yw, mae angen nid yn unig cyfrifo'r gwreiddiau a'r symiau, ond hefyd symiau un arall y tu mewn i'r symiau hyn. Mae angen gwneud llawer o gyfrifiadau 12,5 miliwn o weithiau, a hyd yn oed eu grwpio fesul oriau. Mae gennym ni lawer o oriau hefyd. Ac mae'n rhaid i chi ei wneud mewn 60 eiliad. Mae'n jôc.

Roedd angen cael amser o leiaf rhywsut, oherwydd roedd hyn i gyd yn gweithio'n araf iawn, iawn cyn i ClickHouse ddod.

Ceisiasant ei gyfrifo ar Hadoop, ar Spark, ar Greenplum. Ac roedd hyn i gyd yn araf iawn neu'n ddrud. Hynny yw, roedd yn bosibl cyfrifo rhywsut, ond yna roedd yn ddrud.

Ac yna daeth ClickHouse ymlaen ac fe aeth pethau'n llawer gwell.

Fe’ch atgoffaf fod gennym broblem gyda lleoliad data, oherwydd ni ellir lleoleiddio cydberthnasau. Ni allwn roi rhywfaint o'r data ar un gweinydd, rhai ar un arall a chyfrifo, rhaid inni gael yr holl ddata ym mhobman.

Beth wnaethon nhw? I ddechrau, mae'r data wedi'i leoleiddio. Mae pob gweinydd yn storio data ar brisio set benodol o gyfranddaliadau. Ac nid ydynt yn gorgyffwrdd. Felly, mae'n bosibl cyfrifo logReturn yn gyfochrog ac yn annibynnol, mae hyn i gyd yn digwydd hyd yn hyn yn gyfochrog ac wedi'i ddosbarthu.

Yna fe benderfynon ni leihau'r data hyn, heb golli mynegiant. Lleihau gan ddefnyddio araeau, h.y. ar gyfer pob cyfnod o amser, gwnewch amrywiaeth o stociau ac amrywiaeth o brisiau. Felly, mae'n cymryd llawer llai o le data. Ac maen nhw ychydig yn haws i weithio gyda nhw. Mae'r rhain bron yn weithrediadau cyfochrog, h.y. rydym yn darllen yn rhannol yn gyfochrog ac yna'n ysgrifennu at y gweinydd.

Ar ôl hynny, gellir ei ailadrodd. Mae'r llythyren "r" yn golygu ein bod wedi ailadrodd y data hwn. Hynny yw, mae gennym yr un data ar bob un o'r tri gweinydd - dyma'r araeau.

Ac yna gyda sgript arbennig o'r set hon o 12,5 miliwn o gydberthnasau y mae angen eu cyfrifo, gallwch chi wneud pecynnau. Hynny yw, 2 o dasgau gyda 500 o barau o gydberthnasau. Ac mae'r dasg hon i'w chyfrifo ar weinydd ClickHouse penodol. Mae ganddo'r holl ddata, oherwydd mae'r data yr un peth a gall eu cyfrifo'n ddilyniannol.

Unwaith eto, dyma sut mae'n edrych. Yn gyntaf, mae gennym yr holl ddata yn y strwythur hwn: amser, cyfranddaliadau, pris. Yna fe wnaethom gyfrifo logReturn, h.y. data o'r un strwythur, ond yn lle'r pris mae gennym logReturn eisoes. Yna cawsant eu hail-wneud, h.y. cawsom yr amser a'r grŵpArray ar gyfer stociau a phrisiau. Atgynhyrchu. Ac ar ôl hynny, fe wnaethon ni gynhyrchu criw o dasgau a'u bwydo i ClickHouse fel y byddai'n eu cyfrif. Ac mae'n gweithio.

Ar brawf o gysyniad, roedd y dasg yn is-dasg, h.y., cymerwyd llai o ddata. A dim ond tri gweinydd.

Cymerodd y ddau gam cyntaf: cyfrifo Log_return a lapio mewn araeau tua awr.

Ac mae cyfrifiad y gydberthynas tua 50 awr. Ond nid yw 50 awr yn ddigon, oherwydd roedden nhw'n arfer gweithio am wythnosau. Roedd yn llwyddiant mawr. Ac os ydych chi'n cyfrif, yna 70 gwaith yr eiliad roedd popeth yn cael ei gyfrif ar y clwstwr hwn.

Ond y peth pwysicaf yw bod y system hon yn ymarferol heb dagfeydd, h.y., mae'n graddio bron yn llinol. Ac maen nhw'n ei wirio. Graddiodd yn llwyddiannus.

• Hanner y frwydr yw'r cynllun cywir. A'r cynllun cywir yw defnyddio'r holl dechnolegau ClickHouse angenrheidiol.
• Mae Crynhoi/AgreguMergeTrees yn dechnolegau sy'n eich galluogi i agregu neu ystyried ciplun o'r cyflwr fel achos arbennig. Ac mae'n symleiddio llawer o bethau yn fawr.
• Mae Golygfeydd Materol yn caniatáu ichi osgoi'r terfyn mynegai un. Efallai na wnes i ei ddweud yn glir iawn, ond pan wnaethom lwytho'r logiau, roedd y logiau crai yn y tabl gydag un mynegai, ac roedd y logiau priodoledd yn y tabl, hy yr un data, wedi'i hidlo'n unig, ond roedd y mynegai yn gyfan gwbl eraill. Mae'n ymddangos i fod yr un data, ond didoli gwahanol. Ac mae Materialized Views yn caniatáu ichi, os oes ei angen arnoch, i osgoi cyfyngiad ClickHouse o'r fath.
• Lleihau ronynnedd mynegai ar gyfer ymholiadau pwynt.
• A dosbarthwch y data'n drwsiadus, ceisiwch leoleiddio'r data o fewn y gweinydd cymaint â phosib. A cheisiwch sicrhau bod ceisiadau hefyd yn defnyddio lleoleiddio cymaint â phosibl lle bo modd.

Ac wrth grynhoi'r araith fer hon, gallwn ddweud bod ClickHouse bellach wedi meddiannu tiriogaeth cronfeydd data masnachol a chronfeydd data ffynhonnell agored, h.y., yn benodol ar gyfer dadansoddeg. Mae'n ffitio'n berffaith i'r dirwedd hon. A beth sy'n fwy, mae'n dechrau gorlenwi eraill yn araf, oherwydd pan fydd gennych ClickHouse, nid oes angen InfiniDB arnoch chi. Efallai na fydd angen Vertika yn fuan os byddant yn gwneud cefnogaeth SQL arferol. Mwynhewch!

-Diolch am yr adroddiad! Diddorol iawn! A oedd unrhyw gymariaethau ag Apache Phoenix?

Na, nid wyf wedi clywed unrhyw un yn cymharu. Rydyn ni a Yandex yn ceisio cadw golwg ar yr holl gymariaethau ClickHouse â gwahanol gronfeydd data. Oherwydd os bydd rhywbeth yn sydyn yn troi allan i fod yn gyflymach na ClickHouse, yna ni all Lesha Milovidov gysgu yn y nos ac mae'n dechrau ei gyflymu'n gyflym. Nid wyf wedi clywed am gymhariaeth o'r fath.

• (Aleksey Milovidov) Mae Apache Phoenix yn injan SQL sy'n cael ei bweru gan Hbase. Mae Hbase yn bennaf ar gyfer senario gwaith gwerth allweddol. Yno, ym mhob llinell, gall fod nifer mympwyol o golofnau ag enwau mympwyol. Gellir dweud hyn am systemau fel Hbase, Cassandra. Ac mae'n union ymholiadau dadansoddol trwm na fydd yn gweithio fel arfer iddynt. Neu efallai eich bod chi'n meddwl eu bod nhw'n gweithio'n iawn os nad ydych chi wedi cael unrhyw brofiad gyda ClickHouse.

• Diolch

  • Prynhawn Da Mae gen i ddiddordeb mawr yn y pwnc hwn yn barod, oherwydd mae gen i is-system ddadansoddol. Ond pan fyddaf yn edrych ar ClickHouse, rwy'n cael y teimlad bod ClickHouse yn addas iawn ar gyfer dadansoddi digwyddiadau, yn mutable. Ac os oes angen i mi ddadansoddi llawer o ddata busnes gyda chriw o dablau mawr, yna nid yw ClickHouse, cyn belled ag y deallaf, yn addas iawn i mi? Yn enwedig os ydynt yn newid. A yw hyn yn gywir neu a oes enghreifftiau a all wrthbrofi hyn?

  • Mae hyn yn iawn. Ac mae hyn yn wir am y rhan fwyaf o gronfeydd data dadansoddol arbenigol. Maent wedi'u teilwra ar gyfer y ffaith bod un neu fwy o fyrddau mawr sy'n treiglo, ac ar gyfer llawer o rai bach sy'n newid yn araf. Hynny yw, nid yw ClickHouse yn debyg i Oracle, lle gallwch chi roi popeth ac adeiladu rhai ymholiadau cymhleth iawn. Er mwyn defnyddio ClickHouse yn effeithiol, mae angen i chi adeiladu cynllun mewn ffordd sy'n gweithio'n dda yn ClickHouse. Hynny yw, osgoi normaleiddio gormodol, defnyddio geiriaduron, ceisio gwneud llai o gysylltiadau hir. Ac os caiff y sgema ei adeiladu yn y modd hwn, yna gellir datrys tasgau busnes tebyg ar ClickHouse yn llawer mwy effeithlon nag ar gronfa ddata berthynol draddodiadol.

Diolch am yr adroddiad! Mae gennyf gwestiwn am yr achos ariannol diweddaraf. Roedd ganddyn nhw ddadansoddeg. Roedd angen cymharu sut maen nhw'n mynd i fyny ac i lawr. A deallaf ichi adeiladu'r system yn benodol ar gyfer y dadansoddiadau hyn? Os yfory, er enghraifft, mae angen rhyw adroddiad arall arnynt ar y data hwn, a oes angen iddynt ailadeiladu'r sgema a llwytho'r data i fyny? Hynny yw, gwneud rhyw fath o ragbrosesu i gael y cais?

Wrth gwrs, dyma'r defnydd o ClickHouse ar gyfer tasg benodol iawn. Yn draddodiadol, gellid ei datrys o fewn Hadoop. I Hadoop, mae hon yn dasg ddelfrydol. Ond ar Hadoop mae'n araf iawn. A fy nod yw dangos y gall ClickHouse ddatrys tasgau sydd fel arfer yn cael eu datrys trwy ddulliau hollol wahanol, ond ar yr un pryd eu gwneud yn llawer mwy effeithlon. Mae hwn wedi'i deilwra ar gyfer tasg benodol. Mae'n amlwg, os oes problem gyda rhywbeth tebyg, yna gellir ei datrys mewn ffordd debyg.

Mae'n amlwg. Dywedasoch fod 50 awr wedi’u prosesu. Ai o'r cychwyn cyntaf, pryd wnaethoch chi lwytho'r data neu gael y canlyniadau?

Ydy Ydy.

OK diolch yn fawr iawn.

Mae hyn ar glwstwr o 3 gweinydd.

Cyfarchion! Diolch am yr adroddiad! Mae popeth yn ddiddorol iawn. Ni fyddaf yn gofyn ychydig am y swyddogaeth, ond am y defnydd o ClickHouse o ran sefydlogrwydd. Hynny yw, a oedd gennych unrhyw, a oedd yn rhaid i chi adfer? Sut mae ClickHouse yn ymddwyn yn yr achos hwn? Ac a ddigwyddodd fod gennych chi replica hefyd? Er enghraifft, daethom ar draws problem gyda ClickHouse pan fydd yn dal i fynd allan o'i derfyn ac yn cwympo.

Wrth gwrs, nid oes unrhyw systemau delfrydol. Ac mae gan ClickHouse ei broblemau ei hun hefyd. Ond ydych chi wedi clywed am Yandex.Metrica ddim yn gweithio ers amser maith? Mae'n debyg na. Mae wedi bod yn gweithio'n ddibynadwy ers 2012-2013 ar ClickHouse. Gallaf ddweud yr un peth am fy mhrofiad. Nid ydym erioed wedi cael methiannau llwyr. Gallai rhai pethau rhannol ddigwydd, ond nid oeddent byth yn ddigon hanfodol i effeithio'n ddifrifol ar y busnes. Ni ddigwyddodd erioed. Mae ClickHouse yn eithaf dibynadwy ac nid yw'n chwalu ar hap. Does dim rhaid i chi boeni amdano. Nid yw'n beth amrwd. Mae hyn wedi'i brofi gan lawer o gwmnïau.

Helo! Dywedasoch fod angen ichi feddwl am y sgema data ar unwaith. Beth os digwyddodd? Mae fy data yn arllwys ac yn arllwys. Mae chwe mis yn mynd heibio, a dwi'n deall ei bod hi'n amhosib byw fel hyn, mae angen i mi ail-lwytho'r data a gwneud rhywbeth gyda nhw.

Mae hyn yn dibynnu wrth gwrs ar eich system. Mae sawl ffordd o wneud hyn heb fawr ddim stop. Er enghraifft, gallwch greu Gwedd Materol lle gallwch wneud strwythur data gwahanol os gellir ei fapio'n unigryw. Hynny yw, os yw'n caniatáu mapio gan ddefnyddio ClickHouse, h.y. echdynnu rhai pethau, newid yr allwedd gynradd, newid rhaniad, yna gallwch chi wneud Gwedd Materol. Trosysgrifwch eich hen ddata yno, bydd rhai newydd yn cael eu hysgrifennu'n awtomatig. Ac yna dim ond newid i ddefnyddio'r View Materialized, yna newid y cofnod a lladd yr hen fwrdd. Yn gyffredinol, mae hwn yn ddull di-stop.

Diolch yn fawr.

Ffynhonnell: hab.com