Symud i ClickHouse: 3 blynedd yn ddiweddarach

Dair blynedd yn ôl Viktor Tarnavsky ac Alexey Milovidov o Yandex ar y llwyfan Llwyth Uchel++ dweud wrth, pa ClickHouse sy'n dda, a sut nad yw'n arafu. Ac ar y cam nesaf oedd Alexander Zaitsev с adroddiad am symud i CliciwchHouse gan DBMS dadansoddol arall a gyda'r casgliad bod CliciwchHouse, wrth gwrs, yn dda, ond nid yn gyfleus iawn. Pan yn 2016 y cwmni LifeStreet, lle'r oedd Alexander yn gweithio bryd hynny, yn trosi system ddadansoddol aml-petabyte yn CliciwchHouse, roedd yn "ffordd frics felen" hynod ddiddorol, yn llawn peryglon anhysbys - CliciwchHouse yna roedd yn edrych fel maes mwyngloddio.

Dair blynedd yn ddiweddarach CliciwchHouse Daeth yn llawer gwell - yn ystod y cyfnod hwn, sefydlodd Alexander y cwmni Altinity, sydd nid yn unig yn helpu i symud iddo CliciwchHouse dwsinau o brosiectau, ond hefyd yn gwella'r cynnyrch ei hun ynghyd â chydweithwyr o Yandex. Yn awr CliciwchHouse nid yw'n daith gerdded ddiofal o hyd, ond nid yn faes mwyngloddio mwyach.

Mae Alexander wedi bod yn ymwneud â systemau gwasgaredig ers 2003, gan ddatblygu prosiectau mawr ar MySQL, Oracle и Vertica. O'r diwedd Llwyth Uchel++ 2019 Alexander, un o arloeswyr y defnydd CliciwchHouse, wedi dweud beth yw'r DBMS hwn nawr. Byddwn yn dysgu am y prif nodweddion CliciwchHouse: sut mae'n wahanol i systemau eraill ac ym mha achosion mae'n fwy effeithiol ei ddefnyddio. Gan ddefnyddio enghreifftiau, gadewch i ni ystyried arferion ffres ac wedi'u profi gan brosiectau ar gyfer adeiladu systemau yn seiliedig ar CliciwchHouse.

Ôl-weithredol: beth ddigwyddodd 3 blynedd yn ôl

Dair blynedd yn ôl fe wnaethom drosglwyddo'r cwmni LifeStreet ar CliciwchHouse o gronfa ddata ddadansoddeg wahanol, ac roedd mudo dadansoddeg y rhwydwaith hysbysebu yn edrych fel hyn:

• Mehefin 2016. Yn Ffynhonnell agored ymddangosodd CliciwchHouse a dechreuodd ein prosiect;
• Awst. Prawf o Gysyniad: rhwydwaith hysbysebu mawr, seilwaith a 200-300 terabytes o ddata;
• Hydref. Data cynhyrchu cyntaf;
• Rhagfyr. Llwyth cynnyrch llawn - 10-50 biliwn o ddigwyddiadau y dydd.
• Mehefin 2017. Mudo defnyddwyr yn llwyddiannus i CliciwchHouse, 2,5 petabeit o ddata ar glwstwr o 60 o weinyddion.

Wrth i'r ymfudiad fynd rhagddo, tyfodd y ddealltwriaeth hynny CliciwchHouse yn system dda sy'n ddymunol i weithio gyda hi, ond mae hwn yn brosiect mewnol o Yandex. Felly, mae yna arlliwiau: yn gyntaf bydd Yandex yn delio â'i gwsmeriaid mewnol ei hun a dim ond wedyn â'r gymuned ac anghenion defnyddwyr allanol, tra na chyrhaeddodd ClickHouse y lefel fenter mewn llawer o feysydd swyddogaethol bryd hynny. Felly ym mis Mawrth 2017, fe wnaethom sefydlu Altinity i wneud CliciwchHouse hyd yn oed yn gyflymach ac yn fwy cyfleus nid yn unig i Yandex, ond hefyd i ddefnyddwyr eraill. Ac yn awr rydym yn:

• Rydym yn hyfforddi ac yn helpu i adeiladu atebion yn seiliedig ar CliciwchHouse fel nad yw cwsmeriaid yn llenwi bumps, ac fel bod yr ateb yn gweithio yn y pen draw;
• Rydym yn darparu cefnogaeth 24/7 CliciwchHouse- gosodiadau;
• Rydym yn datblygu ein prosiectau ecosystem ein hunain;
• Ymrwymwch yn weithredol i mi fy hun CliciwchHouse, ymateb i geisiadau gan ddefnyddwyr sydd am weld nodweddion penodol.

Ac wrth gwrs, rydyn ni'n helpu gyda'r symud i CliciwchHouse с MySQL, Vertica, Oracle, Plwm gwyrdd, Redshift a systemau eraill. Rydym wedi bod yn ymwneud ag amrywiaeth eang o adleoli ac maent i gyd wedi bod yn llwyddiannus.

Pam hyd yn oed symud i CliciwchHouse

Nid yw'n arafu! Dyma'r prif reswm. CliciwchHouse - cronfa ddata gyflym iawn ar gyfer gwahanol senarios:

Dyfyniadau ar hap gan bobl sy'n gweithio gyda nhw CliciwchHouse.

Scalability. Ar ryw gronfa ddata arall, gallwch chi gyflawni perfformiad da ar un darn o galedwedd, ond CliciwchHouse gallwch raddio nid yn unig yn fertigol, ond hefyd yn llorweddol trwy ychwanegu gweinyddwyr yn unig. Nid yw popeth yn gweithio mor llyfn ag yr hoffem, ond mae'n gweithio. Gallwch chi dyfu'r system wrth i'ch busnes dyfu. Mae’n bwysig nad ydym yn cael ein cyfyngu gan y penderfyniad yn awr ac mae potensial bob amser ar gyfer datblygu.

hygludedd. Nid oes ymlyniad wrth un peth. Er enghraifft, gyda Redshift Amazon anodd symud i rywle. A CliciwchHouse gallwch ei roi ar eich gliniadur, gweinydd, ei ddefnyddio i'r cwmwl, ewch i Kubernetes - nid oes unrhyw gyfyngiadau ar weithrediad y seilwaith. Mae hyn yn gyfleus i bawb, ac mae hon yn fantais fawr na all llawer o gronfeydd data tebyg eraill ymffrostio ynddi.

Hyblygrwydd. CliciwchHouse nid yw'n dod i ben ar un peth, er enghraifft, Yandex.Metrica, ond mae'n cael ei ddatblygu a'i ddefnyddio mewn mwy a mwy o brosiectau a diwydiannau gwahanol. Gellir ei ehangu trwy ychwanegu nodweddion newydd i ddatrys problemau newydd. Er enghraifft, credir bod storio boncyffion mewn cronfa ddata yn foesau drwg, felly fe wnaethant feddwl am hyn Elastig. Ond diolch i'r hyblygrwydd CliciwchHouse, gallwch hefyd storio logiau ynddo, ac yn aml mae hyd yn oed yn well nag yn Elastig - yn CliciwchHouse mae angen 10 gwaith yn llai o haearn arno.

Am ddim Ffynhonnell Agored. Nid oes rhaid i chi dalu am unrhyw beth. Nid oes angen negodi caniatâd i roi'r system ar eich gliniadur neu'ch gweinydd. Nid oes unrhyw ffioedd cudd. Ar yr un pryd, ni all unrhyw dechnoleg cronfa ddata Ffynhonnell Agored arall gystadlu'n gyflym â hi CliciwchHouse. MySQL, MariaDB, Greenplum - maen nhw i gyd yn llawer arafach.

Cymuned, gyrru a hwyl. Yn CliciwchHouse cymuned wych: cyfarfodydd, sgyrsiau ac Alexey Milovidov, sy'n rhoi ei egni a'i optimistiaeth i ni i gyd.

Symud i ClickHouse

I newid i CliciwchHouse gyda rhywbeth, dim ond tri pheth sydd eu hangen arnoch chi:

• Deall cyfyngiadau CliciwchHouse a'r hyn nad yw'n addas ar ei gyfer.
• Defnyddiwch y manteision dechnoleg a'i chryfderau mwyaf.
• Arbrawf. Hyd yn oed gwybod sut mae'n gweithio CliciwchHouse, nid yw bob amser yn bosibl rhagweld pryd y bydd yn gyflymach, pryd y bydd yn arafach, pryd y bydd yn well, a phryd y bydd yn waeth. Felly ceisiwch.

Y broblem o symud

Nid oes ond un "ond" : os symudwch i CliciwchHouse gyda rhywbeth arall, mae rhywbeth fel arfer yn mynd o'i le. Rydym wedi arfer â rhai arferion a phethau sy'n gweithio yn ein hoff gronfa ddata. Er enghraifft, unrhyw un sy'n gweithio gyda SQCronfeydd data L, yn ystyried y set ganlynol o swyddogaethau yn orfodol:

• trafodion;
• cyfyngiadau;
• cysondeb;
• mynegeion;
• DIWEDDARIAD/DILEU;
• NULLs;
• milieiliadau;
• trawsnewidiadau math awtomatig;
• uno lluosog;
• rhaniadau mympwyol;
• offer rheoli clwstwr.

Mae recriwtio yn orfodol, ond tair blynedd yn ôl yn CliciwchHouse nid oedd yr un o'r nodweddion hyn! Nawr mae llai na hanner yr olion heb eu gwireddu: trafodion, cyfyngiadau, Cysondeb, milieiliadau a castio math.

A'r prif beth yw bod yn CliciwchHouse nid yw rhai arferion a dulliau safonol yn gweithio neu nid ydynt yn gweithio fel yr ydym wedi arfer. Popeth sy'n ymddangos yn CliciwchHouse, yn cyfateb i "cliciwch ffordd tŷ”, h.y. swyddogaethau yn wahanol i DBs eraill. Er enghraifft:

• Nid yw mynegeion yn cael eu dewis, ond yn cael eu hepgor.
• DIWEDDARIAD/DILEU nid cydamserol, ond asyncronaidd.
• Mae sawl uniad, ond nid oes cynllunydd ymholiad. Yn gyffredinol, nid yw sut y cânt eu gweithredu wedyn yn glir iawn i bobl o fyd y gronfa ddata.

Senarios ClickHouse

Yn 1960, mathemategydd Americanaidd o darddiad Hwngari WignerEP ysgrifennodd erthyglEffeithiolrwydd afresymol mathemateg yn y gwyddorau naturiol” (“ Effeithiolrwydd annealladwy mathemateg yn y gwyddorau naturiol ”) bod y byd o’n cwmpas am ryw reswm yn cael ei ddisgrifio’n dda gan gyfreithiau mathemategol. Gwyddoniaeth haniaethol yw mathemateg, ac nid yw deddfau corfforol a fynegir ar ffurf fathemategol yn ddibwys, a WignerEP pwysleisio bod hyn yn rhyfedd iawn.

O fy safbwynt, CliciwchHouse — yr un rhyfeddod. I ailfformiwleiddio Wigner, gallwn ddweud hyn: rhyfeddol yw'r effeithlonrwydd annirnadwy CliciwchHouse mewn amrywiaeth eang o gymwysiadau dadansoddol!

Er enghraifft, gadewch i ni gymryd Warws Data Amser Real, y mae data'n cael ei lwytho i mewn iddo bron yn barhaus. Rydym am dderbyn ceisiadau ganddo gydag ail oedi. Defnyddiwch CliciwchHouseoherwydd fe'i cynlluniwyd ar gyfer y senario hwn. CliciwchHouse dyma sut mae'n cael ei ddefnyddio nid yn unig ar y we, ond hefyd mewn marchnata a dadansoddeg ariannol, AdTech, yn ogystal ag yn Canfod twylln. YN Warws Data amser real defnyddir sgema strwythuredig cymhleth fel "seren" neu "pluen eira", llawer o fyrddau gyda YMUNO (weithiau lluosog), ac mae'r data fel arfer yn cael ei storio a'i newid mewn rhai systemau.

Gadewch i ni gymryd senario arall - Cyfres Amser: dyfeisiau monitro, rhwydweithiau, ystadegau defnydd, rhyngrwyd pethau. Yma rydym yn cyfarfod â digwyddiadau eithaf syml wedi'u trefnu mewn pryd. CliciwchHouse Ni ddatblygwyd yn wreiddiol ar gyfer hyn, ond mae wedi dangos ei hun yn dda, felly mae cwmnïau mawr yn defnyddio CliciwchHouse fel storfa ar gyfer monitro gwybodaeth. I weld a yw'n cyd-fynd CliciwchHouse ar gyfer cyfresi amser, gwnaethom feincnod yn seiliedig ar y dull gweithredu a'r canlyniadau MewnlifDB и AmserlenDB - arbenigol cyfres amser cronfeydd data. Mae'n troi allanBod CliciwchHouse, hyd yn oed heb optimeiddio ar gyfer tasgau o'r fath, hefyd yn ennill ar faes tramor:

В cyfres amser fel arfer defnyddir bwrdd cul - sawl colofn fach. Gall llawer o ddata ddod o fonitro - miliynau o gofnodion yr eiliad - ac maent fel arfer yn dod mewn mewnosodiadau bach (real-amser ffrydio). Felly, mae angen sgript fewnosod wahanol arnom, a'r ymholiadau eu hunain - gyda rhai manylion eu hunain.

Rheoli Log. Mae casglu logiau yn y gronfa ddata fel arfer yn ddrwg, ond i mewn CliciwchHouse gellir gwneud hyn gyda rhai sylwadau fel y disgrifir uchod. Mae llawer o gwmnïau'n defnyddio CliciwchHouse dim ond ar gyfer hyn. Yn yr achos hwn, defnyddir bwrdd gwastad llydan, lle rydym yn storio'r logiau cyfan (er enghraifft, yn y ffurflen JSON), neu ei dorri'n ddarnau. Mae data fel arfer yn cael ei lwytho mewn sypiau mawr (ffeiliau), ac rydym yn chwilio am ryw faes.

Ar gyfer pob un o'r swyddogaethau hyn, defnyddir cronfeydd data arbenigol fel arfer. CliciwchHouse gall rhywun wneud y cyfan ac mor dda ei fod yn eu goddiweddyd mewn perfformiad. Gadewch i ni nawr edrych yn agosach cyfres amser sgript, a sut i "goginio" CliciwchHouse o dan y senario hwn.

Cyfres Amser

Ar hyn o bryd dyma'r prif senario ar ei gyfer CliciwchHouse ystyried y datrysiad safonol. Cyfres amser yn gyfres o ddigwyddiadau trefn amser sy'n cynrychioli newidiadau mewn rhai prosesau dros amser. Er enghraifft, gall fod yn gyfradd curiad y galon y dydd neu nifer y prosesau yn y system. Mae popeth sy'n rhoi amser yn ticio gyda rhai dimensiynau yn cyfres amser:

Daw'r rhan fwyaf o'r digwyddiadau hyn o fonitro. Gall hyn fod nid yn unig yn monitro gwe, ond hefyd yn ddyfeisiadau go iawn: ceir, systemau diwydiannol, IOT, diwydiannau neu dacsis di-griw, yn y gefnffordd y mae Yandex eisoes yn ei roi CliciwchHouse-gweinydd.

Er enghraifft, mae yna gwmnïau sy'n casglu data o longau. Bob ychydig eiliadau, mae synwyryddion o long cynhwysydd yn anfon cannoedd o wahanol fesuriadau. Mae peirianwyr yn eu hastudio, yn adeiladu modelau ac yn ceisio deall pa mor effeithlon y mae'r llong yn cael ei defnyddio, oherwydd ni ddylai llong gynhwysydd sefyll yn segur am eiliad. Mae unrhyw amser segur yn wastraff arian, felly mae'n bwysig rhagweld y llwybr fel mai ychydig iawn o lefydd sydd i'w parcio.

Nawr mae yna dwf o gronfeydd data arbenigol sy'n mesur cyfres amser. Ar y safle DB-Peiriannau rhywsut mae cronfeydd data gwahanol yn cael eu rhestru, a gellir eu gweld yn ôl math:

Y math sy'n tyfu gyflymaf cyfres amsers. Mae cronfeydd data graff hefyd yn tyfu, ond cyfres amsers wedi bod yn tyfu'n gyflymach yn yr ychydig flynyddoedd diwethaf. Mae cynrychiolwyr nodweddiadol y teulu hwn o gronfeydd data yn MewnlifDB, Prometheus, KDB, AmserlenDB (adeiladu ar PostgreSQL), atebion o Amazon. CliciwchHouse yma hefyd y gellir ei ddefnyddio, ac fe'i defnyddir. Gadewch imi roi ychydig o enghreifftiau cyhoeddus ichi.

Un o'r arloeswyr yw'r cwmni CloudFlare (CDNdarparwr). Maent yn monitro eu CDN drwy CliciwchHouse (DNS- ceisiadau, HTTP-ceisiadau) gyda llwyth enfawr - 6 miliwn o ddigwyddiadau yr eiliad. Mae popeth yn mynd drwodd Kafka, yn mynd i CliciwchHouse, sy'n darparu'r gallu i weld dangosfyrddau amser real o ddigwyddiadau yn y system.

Comcast - un o'r arweinwyr ym maes telathrebu yn yr Unol Daleithiau: Rhyngrwyd, teledu digidol, teleffoni. Fe wnaethon nhw greu system reoli debyg CDN o fewn y fframwaith Ffynhonnell Agored y prosiect Rheoli Traffig Apache i weithio gyda'u data enfawr. CliciwchHouse ei ddefnyddio fel cefndir ar gyfer dadansoddeg.

percona adeiledig yn CliciwchHouse tu mewn i'ch PMMi gadw monitro yn wahanol MySQL.

Gofynion Penodol

Mae gan gronfeydd data cyfres amser eu gofynion penodol eu hunain.

• Mewnosod cyflym gan lawer o asiantau. Mae angen inni fewnosod data o lawer o ffrydiau yn gyflym iawn. CliciwchHouse yn ei wneud yn dda, oherwydd mae ganddo'r holl fewnosodiadau nad ydynt yn rhwystro. Unrhyw mewnosod yn ffeil newydd ar ddisg, a gellir byffro mewnosodiadau bach un ffordd neu'r llall. YN CliciwchHouse mae'n well mewnosod data mewn sypiau mawr, yn hytrach nag un llinell ar y tro.
• Cylchdaith Hyblyg. Yn cyfres amser fel arfer nid ydym yn gwybod strwythur y data yn llwyr. Mae'n bosibl adeiladu system fonitro ar gyfer cais penodol, ond yna mae'n anodd ei defnyddio ar gyfer cais arall. Mae hyn yn gofyn am gynllun mwy hyblyg. CliciwchHouse, yn eich galluogi i wneud hyn, er ei fod yn sylfaen wedi'i deipio'n gryf.
• Storio effeithlon ac "anghofio" data. Fel arfer mewn cyfres amser llawer iawn o ddata, felly mae angen eu storio mor effeithlon â phosibl. Er enghraifft, yn MewnlifDB cywasgu da yw ei brif nodwedd. Ond yn ogystal â storio, mae angen i chi hefyd allu "anghofio" hen ddata a gwneud rhai issamplu — cyfrif agregau yn awtomatig.
• Ymholiadau cyflym ar ddata cyfun. Weithiau mae'n ddiddorol edrych ar y 5 munud olaf gyda chywirdeb milieiliadau, ond ar ddata misol, efallai na fydd angen ronynnedd munud neu eiliad - mae ystadegau cyffredinol yn ddigon. Mae angen cefnogaeth o'r fath, fel arall bydd cais am 3 mis yn cael ei weithredu am amser hir iawn hyd yn oed o fewn CliciwchHouse.
• Ceisiadau fel "pwynt olaf, fel o». Mae'r rhain yn nodweddiadol ar gyfer cyfres amser ceisiadau: edrychwch ar y mesuriad olaf neu gyflwr y system ar adeg benodol t. Ar gyfer y gronfa ddata, nid yw'r rhain yn ymholiadau dymunol iawn, ond mae angen iddynt allu gweithredu hefyd.
• cyfres amser "gludo".. Cyfres amser yn gyfres amser. Os oes dwy gyfres amser, yna yn aml mae angen eu cysylltu a'u cydberthyn. Nid yw'n gyfleus gwneud hyn ar bob cronfa ddata, yn enwedig gyda chyfresi amser heb eu halinio: dyma rai marciau amser, mae yna rai eraill. Gallwch chi ystyried y cyfartaledd, ond yn sydyn bydd twll o hyd, felly nid yw'n glir.

Gawn ni weld sut mae'r gofynion hyn yn cael eu bodloni yn CliciwchHouse.

Cynllun

В CliciwchHouse cynllun ar gyfer cyfres amser gellir ei wneud mewn gwahanol ffyrdd, yn dibynnu ar ba mor gyson yw'r data. Mae'n bosibl adeiladu system ar ddata rheolaidd pan fyddwn yn gwybod yr holl fetrigau ymlaen llaw. Er enghraifft, gwnaeth CloudFlare gyda monitro CDN yn system sydd wedi'i optimeiddio'n dda. Gallwch adeiladu system fwy cyffredinol sy'n monitro'r seilwaith cyfan, gwahanol wasanaethau. Yn achos data afreolaidd, nid ydym yn gwybod ymlaen llaw beth rydym yn ei fonitro - ac mae'n debyg mai dyma'r achos mwyaf cyffredin.

data rheolaidd. Colofnau. Mae'r cynllun yn syml - colofnau gyda'r mathau angenrheidiol:

CREATE TABLE cpu (
  created_date Date DEFAULT today(),  
  created_at DateTime DEFAULT now(),  
  time String,  
  tags_id UInt32,  /* join to dim_tag */
  usage_user Float64,  
  usage_system Float64,  
  usage_idle Float64,  
  usage_nice Float64,  
  usage_iowait Float64,  
  usage_irq Float64,  
  usage_softirq Float64,  
  usage_steal Float64,  
  usage_guest Float64,  
  usage_guest_nice Float64
) ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

Mae hwn yn dabl rheolaidd sy'n monitro rhyw fath o weithgaredd cychwyn system (defnyddiwr, system, segur, braf). Syml a chyfleus, ond nid yn hyblyg. Os ydym am gael cynllun mwy hyblyg, yna gallwn ddefnyddio araeau.

Data afreolaidd. Araeau:

CREATE TABLE cpu_alc (
  created_date Date,  
  created_at DateTime,  
  time String,  
  tags_id UInt32,  
  metrics Nested(
    name LowCardinality(String),  
    value Float64
  )
) ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

SELECT max(metrics.value[indexOf(metrics.name,'usage_user')]) FROM ...

Strwythur Nythu yn ddau arae: mydryddiaeth.enw и metrigau.gwerth. Yma gallwch storio data monitro mympwyol o'r fath fel amrywiaeth o enwau ac amrywiaeth o fesuriadau ar gyfer pob digwyddiad. Ar gyfer optimeiddio pellach, gellir gwneud sawl strwythur o'r fath yn lle un. Er enghraifft, un ar gyfer arnofio-gwerth, arall - am int-ystyr, oherwydd int Rwyf am storio'n fwy effeithlon.

Ond mae strwythur o'r fath yn anoddach ei gyrchu. Bydd yn rhaid i chi ddefnyddio adeiladwaith arbennig, gan ddefnyddio swyddogaethau arbennig i dynnu allan y gwerthoedd yn gyntaf o'r mynegai, ac yna'r arae:

SELECT max(metrics.value[indexOf(metrics.name,'usage_user')]) FROM ...

Ond mae'n dal i weithio'n ddigon cyflym. Ffordd arall o storio data afreolaidd yw trwy resi.

Data afreolaidd. Llinynnau. Yn y ffordd draddodiadol hon, heb araeau, ni chaiff enwau a gwerthoedd eu storio ar unwaith. Os daw 5 o fesuriadau o un ddyfais ar unwaith, cynhyrchir 000 o resi yn y gronfa ddata:

CREATE TABLE cpu_rlc (
  created_date Date,  
  created_at DateTime,  
  time String,  
  tags_id UInt32,  
  metric_name LowCardinality(String),  
  metric_value Float64
) ENGINE = MergeTree(created_date, (metric_name, tags_id, created_at), 8192);


SELECT 
    maxIf(metric_value, metric_name = 'usage_user'),
    ... 
FROM cpu_r
WHERE metric_name IN ('usage_user', ...)

CliciwchHouse yn ymdopi â hyn - mae ganddo estyniadau arbennig CliciwchHouse SQL. Er enghraifft maxIf - swyddogaeth arbennig sy'n cyfrifo'r uchafswm yn ôl y metrig pan fodlonir rhyw amod. Gallwch ysgrifennu sawl ymadrodd o'r fath mewn un ymholiad a chyfrifo'r gwerth ar gyfer sawl metrig ar unwaith.

Gadewch i ni gymharu tri dull:

Manylion

Yma rwyf wedi ychwanegu "Maint Data ar Ddisg" ar gyfer rhai set ddata prawf. Yn achos colofnau, mae gennym y maint data lleiaf: cywasgiad uchaf, cyflymder ymholiad uchaf, ond rydym yn talu trwy orfod trwsio popeth ar unwaith.

Yn achos araeau, mae pethau ychydig yn waeth. Mae'r data yn dal i gywasgu'n dda ac mae'n bosibl storio patrwm afreolaidd. Ond CliciwchHouse - cronfa ddata colofn, a phan fyddwn yn dechrau storio popeth mewn amrywiaeth, mae'n troi'n gronfa ddata llinynnol, ac rydym yn talu am hyblygrwydd gydag effeithlonrwydd. Ar gyfer unrhyw weithrediad, bydd yn rhaid i chi ddarllen yr arae gyfan yn y cof, yna dod o hyd i'r elfen a ddymunir ynddo - ac os yw'r arae'n tyfu, yna mae'r cyflymder yn diraddio.

Yn un o'r cwmnïau sy'n defnyddio'r dull hwn (er enghraifft, Chynnyrch), mae araeau yn cael eu torri'n ddarnau o 128 o elfennau. Nid yw data sawl mil o fetrigau gyda chyfaint o 200 TB o ddata / dydd yn cael ei storio mewn un arae, ond mewn araeau 10 neu 30 gyda rhesymeg storio arbennig.

Y dull symlaf yw gyda llinynnau. Ond mae'r data wedi'i gywasgu'n wael, mae maint y tabl yn fawr, a hyd yn oed pan fydd ymholiadau'n seiliedig ar sawl metrig, nid yw ClickHouse yn gweithio'n optimaidd.

cynllun hybrid

Gadewch i ni dybio ein bod wedi dewis sgema arae. Ond os ydym yn gwybod bod y rhan fwyaf o'n dangosfyrddau yn dangos metrigau defnyddwyr a system yn unig, gallwn hefyd droi'r metrigau hyn yn golofnau o arae ar lefel y tabl fel hyn:

CREATE TABLE cpu_alc (
  created_date Date,  
  created_at DateTime,  
  time String,  
  tags_id UInt32,  
  metrics Nested(
    name LowCardinality(String),  
    value Float64
  ),
  usage_user Float64 
             MATERIALIZED metrics.value[indexOf(metrics.name,'usage_user')],
  usage_system Float64 
             MATERIALIZED metrics.value[indexOf(metrics.name,'usage_system')]
) ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

Pan gaiff ei gludo CliciwchHouse yn eu cyfrif yn awtomatig. Fel hyn gallwch chi gyfuno busnes â phleser: mae'r cynllun yn hyblyg ac yn gyffredinol, ond fe wnaethom dynnu allan y colofnau a ddefnyddir amlaf. Sylwaf nad oedd angen newid y mewnosodiad a ETL, sy'n parhau i fewnosod araeau yn y bwrdd. Rydym newydd wneud ALTER TABL, ychwanegu cwpl o siaradwyr a chael cynllun hybrid a chyflymach y gallwch chi ddechrau ei ddefnyddio ar unwaith.

Codecs a chywasgu

I cyfres amser mae'n bwysig pa mor dda yr ydych yn pacio'r data, oherwydd gall yr amrywiaeth o wybodaeth fod yn fawr iawn. YN CliciwchHouse mae set o offer i gyflawni effaith cywasgu 1:10, 1:20, ac weithiau mwy. Mae hyn yn golygu bod 1 TB o ddata anghywasgedig ar ddisg yn cymryd 50-100 GB. Mae maint llai yn dda, gellir darllen a phrosesu data yn gyflymach.

Er mwyn cyflawni lefel uchel o gywasgu, CliciwchHouse yn cefnogi'r codecau canlynol:

Enghraifft tabl:

CREATE TABLE benchmark.cpu_codecs_lz4 (
    created_date Date DEFAULT today(), 
    created_at DateTime DEFAULT now() Codec(DoubleDelta, LZ4), 
    tags_id UInt32, 
    usage_user Float64 Codec(Gorilla, LZ4), 
    usage_system Float64 Codec(Gorilla, LZ4), 
    usage_idle Float64 Codec(Gorilla, LZ4), 
    usage_nice Float64 Codec(Gorilla, LZ4), 
    usage_iowait Float64 Codec(Gorilla, LZ4), 
    usage_irq Float64 Codec(Gorilla, LZ4), 
    usage_softirq Float64 Codec(Gorilla, LZ4), 
    usage_steal Float64 Codec(Gorilla, LZ4), 
    usage_guest Float64 Codec(Gorilla, LZ4), 
    usage_guest_nice Float64 Codec(Gorilla, LZ4), 
    additional_tags String DEFAULT ''
)
ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

Yma rydym yn diffinio'r codec DwblDelta mewn un achos, yn yr ail Gorilla, a gofalwch eich bod yn ychwanegu mwy LZ4 cywasgu. O ganlyniad, mae maint y data ar ddisg yn cael ei leihau'n fawr:

Mae hyn yn dangos faint o le y mae'r un data yn ei gymryd, ond gan ddefnyddio gwahanol godecs a chywasgiadau:

• mewn ffeil GZIP ar ddisg;
• yn ClickHouse heb godecs, ond gyda chywasgu ZSTD;
• yn ClickHouse gyda codecau LZ4 a ZSTD a chywasgu.

Gellir gweld bod tablau gyda chodecs yn cymryd llawer llai o le.

Mae maint yn bwysig

Ddim yn llai pwysig i ddewis math cywir o ddata:

Yn yr holl enghreifftiau uchod rydw i wedi'u defnyddio Arnofio64. Ond pe dewisem Arnofio32yna byddai hynny hyd yn oed yn well. Dangoswyd hyn yn dda gan y dynion o Perkona yn yr erthygl yn y ddolen uchod. Mae'n bwysig defnyddio'r math mwyaf cryno sy'n gweddu i'r dasg: hyd yn oed yn llai ar gyfer maint ar ddisg nag ar gyfer cyflymder ymholiad. CliciwchHouse sensitif iawn iddo.

Os gallwch chi ddefnyddio intxnumx yn hytrach na intxnumx, yna disgwyliwch gynnydd deublyg bron mewn perfformiad. Mae'r data yn cymryd llai o gof, ac mae'r holl "rifyddeg" yn gweithio'n llawer cyflymach. CliciwchHouse y tu mewn iddo mae system wedi'i theipio'n llym iawn, mae'n gwneud y gorau o'r holl bosibiliadau y mae systemau modern yn eu darparu.

cydgasglu a Golygfeydd Perthnasol

Mae agregu a golygfeydd wedi'u gwireddu yn eich galluogi i wneud agregau ar gyfer gwahanol achlysuron:

Er enghraifft, efallai bod gennych chi ddata ffynhonnell heb ei agregu, a gallwch chi hongian gwahanol safbwyntiau perthnasol arnyn nhw gyda chrynhoad awtomatig trwy beiriant arbennig SummingMergeTree (UDRh). Uwch Dîm Rheoli yn strwythur data agregu arbennig sy'n cyfrif agregau yn awtomatig. Mewnosodir data crai yn y gronfa ddata, caiff ei agregu'n awtomatig, a gellir defnyddio dangosfyrddau ar unwaith.

TTL - "anghofio" hen ddata

Sut i "anghofio" data nad oes ei angen mwyach? CliciwchHouse yn gwybod sut i wneud hynny. Wrth greu tablau, gallwch chi nodi TTL ymadroddion: er enghraifft, ein bod yn storio data munudau am un diwrnod, data dyddiol am 30 diwrnod, a byth yn cyffwrdd â data wythnosol neu fisol:

CREATE TABLE aggr_by_minute
…
TTL time + interval 1 day

CREATE TABLE aggr_by_day
…
TTL time + interval 30 day

CREATE TABLE aggr_by_week
…
/* no TTL */

aml haen - rhannu data ar draws disgiau

Wrth ddatblygu'r syniad hwn, gellir storio data CliciwchHouse mewn gwahanol leoedd. Tybiwch ein bod am storio data poeth ar gyfer yr wythnos ddiwethaf ar leol cyflym iawn Adran Gwasanaethau Cymdeithasol, ac rydym yn ychwanegu mwy o ddata hanesyddol i le arall. YN CliciwchHouse nawr mae'n bosibl:

Gallwch chi ffurfweddu'r polisi cadw (polisi storio) Felly CliciwchHouse yn trosglwyddo data yn awtomatig i storfa arall pan fodlonir amodau penodol.

Ond nid dyna'r cyfan. Ar lefel tabl penodol, gallwch ddiffinio rheolau ar gyfer union pryd y caiff data ei drosglwyddo i storfa oer. Er enghraifft, mae 7 diwrnod o ddata yn gorwedd ar ddisg gyflym iawn, ac mae popeth sy'n hŷn yn cael ei drosglwyddo i un araf. Mae hyn yn dda oherwydd ei fod yn caniatáu i'r system gadw ar y perfformiad mwyaf posibl, wrth reoli costau a pheidio â gwario arian ar ddata oer:

CREATE TABLE 
... 
TTL date + INTERVAL 7 DAY TO VOLUME 'cold_volume', 
    date + INTERVAL 180 DAY DELETE

Nodweddion unigryw CliciwchHouse

Bron popeth i mewn CliciwchHouse mae yna "uchafbwyntiau" o'r fath, ond maen nhw'n cael eu lefelu gan yr unigryw - yr hyn nad yw mewn cronfeydd data eraill. Er enghraifft, dyma rai o'r nodweddion unigryw CliciwchHouse:

• Araeau. Yn CliciwchHouse cefnogaeth dda iawn ar gyfer araeau, yn ogystal â'r gallu i wneud cyfrifiadau cymhleth arnynt.
• Strwythurau Data Cydgasglu. Dyma un o'r "nodweddion lladd" CliciwchHouse. Er gwaethaf y ffaith bod y dynion o Yandex yn dweud nad ydym am agregu data, mae popeth wedi'i agregu i mewn CliciwchHouseoherwydd ei fod yn gyflym ac yn gyfleus.
• Golygfeydd Materol. Ynghyd â strwythurau data agregu, mae golygfeydd wedi'u gwireddu yn caniatáu ichi wneud cyfleuster cyfleus real-amser cydgasgliad.
• ClickHouse SQL. Estyniad iaith yw hwn SQL gyda rhai nodweddion ychwanegol ac unigryw sydd ond ar gael yn CliciwchHouse. Yn flaenorol, yr oedd, fel petai, yn estyniad ar y naill law, ac yn anfantais ar y llaw arall. Nawr mae bron pob un o'r diffygion o gymharu â SQL 92 fe wnaethon ni ei ddileu, nawr dim ond estyniad ydyw.
• Lambda-mynegiant. Ydyn nhw dal mewn rhyw gronfa ddata?
• ML-cefnogaeth. Mae hyn mewn gwahanol gronfeydd data, mae rhai yn well, mae rhai yn waeth.
• ffynhonnell agor. Gallwn ehangu CliciwchHouse gyda'i gilydd. Yn awr i mewn CliciwchHouse tua 500 o gyfranwyr, ac mae'r nifer hwn yn cynyddu'n gyson.

Ymholiadau Anodd

В CliciwchHouse mae yna lawer o wahanol ffyrdd o wneud yr un peth. Er enghraifft, mae tair ffordd wahanol o ddychwelyd y gwerth olaf o dabl ar gyfer CPU (mae pedwerydd hefyd, ond mae hyd yn oed yn fwy egsotig).

Mae'r un cyntaf yn dangos pa mor gyfleus yw hi i wneud yn CliciwchHouse ymholiadau pan fyddwch am wirio hynny twple a gynhwysir yn y subquery. Mae hyn yn rhywbeth yr oeddwn yn bersonol yn brin iawn mewn cronfeydd data eraill. Os wyf am gymharu rhywbeth gyda subquery, yna mewn cronfeydd data eraill dim ond sgalar y gellir ei gymharu ag ef, ac ar gyfer sawl colofn mae angen i mi ysgrifennu YMUNO. Yn CliciwchHouse gallwch ddefnyddio tuple:

SELECT *
  FROM cpu 
 WHERE (tags_id, created_at) IN 
    (SELECT tags_id, max(created_at)
        FROM cpu 
        GROUP BY tags_id)

Mae'r ail ffordd yn gwneud yr un peth ond mae'n defnyddio swyddogaeth agregau argMax:

SELECT 
    argMax(usage_user), created_at),
    argMax(usage_system), created_at),
...
 FROM cpu 

В CliciwchHouse mae yna sawl dwsin o swyddogaethau agregau, ac os ydych chi'n defnyddio combinators, yna yn unol â chyfreithiau combinatorics, byddwch chi'n cael tua mil ohonyn nhw. ArgMax - un o'r swyddogaethau sy'n cyfrif y gwerth mwyaf: mae'r ymholiad yn dychwelyd y gwerth defnydd_defnyddiwr, lle cyrhaeddir y gwerth mwyaf creu_at:

SELECT now() as created_at,
       cpu.*
  FROM (SELECT DISTINCT tags_id from cpu) base 
  ASOF LEFT JOIN cpu USING (tags_id, created_at)

YMUNWCH ASOF - "gludo" rhesi gyda gwahanol amseroedd. Mae hon yn nodwedd unigryw ar gyfer cronfeydd data a dim ond ar gael yn kdb+. Os oes dwy gyfres amser gydag amseroedd gwahanol, YMUNWCH ASOF yn caniatáu iddynt gael eu symud a'u gludo mewn un cais. Ar gyfer pob gwerth mewn un gyfres amser, darganfyddir y gwerth agosaf mewn un arall, ac fe'u dychwelir ar yr un llinell:

Swyddogaethau Dadansoddol

Yn y safon SQL-2003 gallwch ysgrifennu fel hyn:

SELECT origin,
       timestamp,
       timestamp -LAG(timestamp, 1) OVER (PARTITION BY origin ORDER BY timestamp) AS duration,
       timestamp -MIN(timestamp) OVER (PARTITION BY origin ORDER BY timestamp) AS startseq_duration,
       ROW_NUMBER() OVER (PARTITION BY origin ORDER BY timestamp) AS sequence,
       COUNT() OVER (PARTITION BY origin ORDER BY timestamp) AS nb
  FROM mytable
ORDER BY origin, timestamp;

В CliciwchHouse nid yw hyn yn bosibl - nid yw'n cefnogi'r safon SQL-2003 ac mae'n debyg na fydd byth. Yn lle hynny, yn CliciwchHouse mae'n arferol ysgrifennu fel hyn:

Fe wnes i addo lambdas - dyma nhw!

Mae hwn yn analog o ymholiad dadansoddol yn y safon SQL-2003: mae'n cyfrif y gwahaniaeth rhwng dau stamp amser, hyd, trefnol - popeth yr ydym fel arfer yn ystyried swyddogaethau dadansoddol. YN CliciwchHouse rydym yn eu cyfrif trwy araeau: yn gyntaf rydyn ni'n cwympo'r data yn arae, wedi hynny rydyn ni'n gwneud beth bynnag rydyn ni ei eisiau ar yr arae, ac yna rydyn ni'n ei ehangu'n ôl. Nid yw'n gyfleus iawn, mae angen cariad at raglennu swyddogaethol o leiaf, ond mae'n hyblyg iawn.

Swyddogaethau arbennig

Eithr, mewn CliciwchHouse llawer o nodweddion arbenigol. Er enghraifft, sut i benderfynu faint o sesiynau sy'n cael eu cynnal ar yr un pryd? Tasg nodweddiadol ar gyfer monitro yw pennu'r llwyth uchaf mewn un cais. YN CliciwchHouse mae swyddogaeth arbennig at y diben hwn:

Yn gyffredinol, mae gan ClickHouse swyddogaethau arbennig at lawer o ddibenion:

• rhedegDifference, runningAccumulate, cymydog;
• SumMap (allwedd, gwerth);
• timeSeriesGroupSum(uid, stamp amser, gwerth);
• timeSeriesGroupRateSum(uid, stamp amser, gwerth);
• sgiwPop, skewSamp, kurtPop, kurtSamp;
• GYDA LLENWI / WITH TIES;
• simpleLinearRegression, stochasticLinearRegression.

Nid yw hon yn rhestr gyflawn o nodweddion, dim ond 500-600 ohonynt sydd. Awgrym: pob swyddogaeth i mewn CliciwchHouse yn y tabl system (nid yw pob un wedi'i ddogfennu, ond mae pob un yn ddiddorol):

select * from system.functions order by name

CliciwchHouse yn storio llawer o wybodaeth amdano'i hun, gan gynnwys byrddau log, ymholiad_log, log olrhain, log gweithrediad gyda blociau data (rhan_log), y log metrigau, a log y system, y mae fel arfer yn ei ysgrifennu i ddisg. Mae'r log metrigau yn cyfres amser в CliciwchHouse mewn gwirionedd CliciwchHouse: gall y gronfa ddata ei hun chwarae rhan cyfres amser cronfeydd data, a thrwy hynny "diflanu" ei hun.

Mae hyn hefyd yn beth unigryw - gan ein bod yn gwneud gwaith da ar gyfer cyfres amserpam na allwn ni storio popeth sydd ei angen arnom ynom ein hunain? Nid oes angen Prometheus, rydym yn cadw popeth yn ein hunain. Wedi'i gysylltu Grafana ac rydym yn monitro ein hunain. Fodd bynnag, os CliciwchHouse yn cwympo, ni fyddwn yn gweld - pam - dyna pam nad ydyn nhw fel arfer yn gwneud hynny.

Clwstwr mawr neu lawer o rai bach CliciwchHouse

Beth sy'n well - un clwstwr mawr neu lawer o ClickHouses bach? Yr ymagwedd draddodiadol at DWH yn glwstwr mawr lle dyrennir cynlluniau ar gyfer pob cais. Daethom at weinyddwr y gronfa ddata - rhowch sgema i ni, a rhoddwyd iddo:

В CliciwchHouse gallwch chi ei wneud yn wahanol. A all pob cais wneud ei gais ei hun CliciwchHouse:

Nid oes angen anghenfil mawr arnom mwyach DWH a gweinyddwyr anghydweithredol. Gallwn roi ei gais ei hun i bob cais CliciwchHouse, a gall y datblygwr ei wneud ei hun, ers hynny CliciwchHouse hawdd iawn i'w gosod ac nid oes angen gweinyddiaeth gymhleth:

Ond os oes gennym ni lawer CliciwchHouse, ac mae angen i chi ei osod yn aml, yna rydych chi am awtomeiddio'r broses hon. Ar gyfer hyn gallwn, er enghraifft, ddefnyddio Kubernetes и clichouse-gweithredwr. YN Kubernetes ClickHouse gallwch chi roi "ar glic": Gallaf glicio botwm, rhedeg y maniffest ac mae'r gronfa ddata yn barod. Gallwch chi greu cynllun ar unwaith, dechrau llwytho metrigau yno, ac ar ôl 5 munud mae gen i ddangosfwrdd yn barod Grafana. Mae mor syml!

Y canlyniad?

Felly, CliciwchHouse - Hyn:

• Быстро. Mae pawb yn gwybod hyn.
• Yn syml. Ychydig yn ddadleuol, ond rwy'n meddwl ei fod yn anodd ei ddysgu, yn hawdd ymladd. Os ydych yn deall sut CliciwchHouse yn gweithio, mae popeth yn syml iawn.
• Yn gyffredinol. Mae'n addas ar gyfer gwahanol senarios: DWH, Cyfres Amser, Storio Logiau. Ond nid ydyw OLTP cronfa ddata, felly peidiwch â cheisio gwneud mewnosodiadau byr a darlleniadau yno.
• Yn ddiddorol. Mae'n debyg yr un sy'n gweithio gyda CliciwchHouse, wedi profi llawer o funudau diddorol mewn synnwyr da a drwg. Er enghraifft, daeth datganiad newydd allan, stopiodd popeth weithio. Neu pan wnaethoch chi gael trafferth gyda thasg am ddau ddiwrnod, ond ar ôl cwestiwn yn y sgwrs Telegram, cafodd y dasg ei datrys mewn dau funud. Neu, fel yn y gynhadledd yn adroddiad Lesha Milovidov, sgrinlun o CliciwchHouse torri'r darllediad Llwyth Uchel++. Mae'r mathau hyn o bethau yn digwydd drwy'r amser ac yn gwneud ein bywyd gyda CliciwchHouse llachar a diddorol!

Gellir gweld y cyflwyniad yma.

Mae'r cyfarfod hir-ddisgwyliedig o ddatblygwyr systemau llwyth uchel yn Llwyth Uchel++ yn digwydd ar 9 a 10 Tachwedd yn Skolkovo. Yn olaf, bydd yn gynhadledd all-lein (er gyda phob rhagofal), gan na ellir pecynnu egni HighLoad++ ar-lein.

Ar gyfer y gynhadledd, rydym yn darganfod ac yn dangos achosion i chi am y posibiliadau mwyaf o dechnoleg: HighLoad ++ oedd, a dyma fydd yr unig le y gallwch chi ddysgu mewn dau ddiwrnod sut mae Facebook, Yandex, VKontakte, Google ac Amazon yn gweithio.

Ar ôl cynnal ein cyfarfodydd heb ymyrraeth ers 2007, eleni byddwn yn cyfarfod am y 14eg tro. Yn ystod y cyfnod hwn, mae'r gynhadledd wedi tyfu 10 gwaith, y llynedd casglodd digwyddiad allweddol y diwydiant 3339 o gyfranogwyr, 165 o siaradwyr adroddiadau a chyfarfodydd, ac roedd 16 trac yn chwarae ar yr un pryd.
Y llynedd roedd 20 bws i chi, 5280 litr o de a choffi, 1650 litr o ddiodydd ffrwythau a 10200 potel o ddŵr. A 2640 cilogram arall o fwyd, 16 o blatiau a 000 o gwpanau. Gyda llaw, gyda'r arian a godwyd o bapur wedi'i ailgylchu, fe wnaethom blannu 25 o eginblanhigion derw 🙂

Gellir prynu tocynnau yma, derbyn newyddion am y gynhadledd - yma, a siarad ym mhob rhwydwaith cymdeithasol: Telegram, Facebook, VKontakte и Twitter.

Ffynhonnell: hab.com