Gan fod ClickHouse yn system arbenigol, wrth ei defnyddio mae'n bwysig ystyried nodweddion ei bensaernïaeth. Yn yr adroddiad hwn, bydd Alexey yn siarad am enghreifftiau o gamgymeriadau cyffredin wrth ddefnyddio ClickHouse, a all arwain at waith aneffeithiol. Bydd enghreifftiau ymarferol yn dangos sut y gall dewis un neu gynllun prosesu data arall newid perfformiad yn ôl trefn maint.
Helo pawb! Fy enw i yw Alexey, rwy'n gwneud ClickHouse.
Yn gyntaf, brysiaf i'ch plesio ar unwaith, heddiw ni fyddaf yn dweud wrthych beth yw ClickHouse. I fod yn onest, dwi wedi blino arno fe. Bob tro rwy'n dweud wrthych beth ydyw. Ac mae'n debyg bod pawb eisoes yn gwybod.
Yn lle hynny, dywedaf wrthych pa gamgymeriadau posibl sydd, hynny yw, sut y gallwch ddefnyddio ClickHouse yn anghywir. Mewn gwirionedd, nid oes angen bod ofn, oherwydd rydym yn datblygu ClickHouse fel system sy'n syml, yn gyfleus, ac yn gweithio allan o'r bocs. Fe'i gosodais, dim problemau.
Ond mae angen i chi gymryd i ystyriaeth o hyd bod y system hon yn arbenigol a gallwch ddod ar draws achos defnydd anarferol yn hawdd a fydd yn tynnu'r system hon allan o'i barth cysur.
Felly, pa fath o rhaca sydd yna? Yn bennaf byddaf yn siarad am bethau amlwg. Mae popeth yn amlwg i bawb, mae pawb yn deall popeth a gallant fod yn falch eu bod mor smart, a bydd y rhai nad ydynt yn deall yn dysgu rhywbeth newydd.
Yr enghraifft gyntaf a symlaf, sydd, yn anffodus, yn aml yn digwydd, yw nifer fawr o fewnosodiadau gyda sypiau bach, h.y. nifer fawr o fewnosodiadau bach.
Os byddwn yn ystyried sut mae ClickHouse yn perfformio mewnosod, yna gallwch anfon o leiaf terabyte o ddata mewn un cais. Nid yw'n broblem.
A gadewch i ni weld beth fyddai'r perfformiad nodweddiadol. Er enghraifft, mae gennym dabl o ddata Yandex.Metrica. Trawiadau. 105 rhai colofnau. 700 beit heb ei gywasgu. A byddwn yn mewnosod mewn ffordd dda mewn sypiau o filiwn o resi.
Rydyn ni'n mewnosod MergeTree yn y tabl, mae'n troi allan hanner miliwn o resi yr eiliad. Gwych. Mewn tabl wedi'i ddyblygu bydd ychydig yn llai, tua 400 o resi yr eiliad.
Ac os ydych chi'n galluogi gosod cworwm, byddwch chi'n cael ychydig yn llai, ond yn dal yn berfformiad gweddus, 250 o delerau yr eiliad. Mae mewnosod cworwm yn nodwedd heb ei dogfennu yn ClickHouse*.
* o 2020 ymlaen, .
Beth sy'n digwydd os gwnewch rywbeth drwg? Rydyn ni'n mewnosod un rhes yn y tabl MergeTree ac yn cael 59 rhes yr eiliad. Mae hynny 10 gwaith yn arafach. Yn ReplicatedMergeTree - 000 rhes yr eiliad. Ac os caiff y cworwm ei droi ymlaen, yna mae'n troi allan 6 linell yr eiliad. Yn fy marn i, mae hyn yn rhyw fath o crap absoliwt. Sut gallwch chi arafu fel hynny? Rwyf hyd yn oed wedi ei ysgrifennu ar fy nghrys-T na ddylai ClickHouse arafu. Ond serch hynny mae'n digwydd weithiau.
Mewn gwirionedd, dyma ein diffyg. Gallem fod wedi gwneud i bopeth weithio'n iawn yn hawdd, ond ni wnaethom. Ac ni wnaethom hynny oherwydd nad oedd ei angen ar ein sgript. Roedd gennym ni gigyddion yn barod. Rydym newydd dderbyn sypiau wrth ein mynedfa, a dim problemau. Rydyn ni'n ei fewnosod ac mae popeth yn gweithio'n iawn. Ond, wrth gwrs, mae pob math o senarios yn bosibl. Er enghraifft, pan fydd gennych griw o weinyddion y cynhyrchir data arnynt. Ac nid ydynt yn mewnosod data mor aml, ond maent yn dal i gael mewnosodiadau aml. Ac mae angen inni osgoi hyn rywsut.
O safbwynt technegol, y pwynt yw pan fyddwch chi'n gwneud mewnosodiad yn ClickHouse, nid yw'r data yn y pen draw mewn unrhyw femtable. Nid oes gennym hyd yn oed strwythur log go iawn MergeTree, ond dim ond MergeTree, oherwydd nid oes log na memTable. Yn syml, rydyn ni'n ysgrifennu'r data ar unwaith i'r system ffeiliau, sydd eisoes wedi'i drefnu mewn colofnau. Ac os oes gennych chi 100 o golofnau, yna bydd angen ysgrifennu mwy na 200 o ffeiliau i gyfeiriadur ar wahân. Mae hyn i gyd yn feichus iawn.
Ac mae'r cwestiwn yn codi: “Sut i wneud pethau'n iawn?” Os yw'r sefyllfa'n golygu bod dal angen i chi gofnodi data yn ClickHouse rywsut.
Dull 1. Dyma'r ffordd hawsaf. Defnyddiwch ryw fath o giw gwasgaredig. Er enghraifft, Kafka. Yn syml, rydych chi'n tynnu data o Kafka a'i swpio unwaith yr eiliad. A bydd popeth yn iawn, rydych chi'n cofnodi, mae popeth yn gweithio'n iawn.
Yr anfanteision yw bod Kafka yn system ddosbarthedig swmpus arall. Rwyf hefyd yn deall a oes gennych Kafka yn eich cwmni eisoes. Mae'n dda, mae'n gyfleus. Ond os nad yw'n bodoli, yna dylech feddwl deirgwaith cyn llusgo system ddosbarthedig arall i'ch prosiect. Ac felly mae'n werth ystyried dewisiadau eraill.
Dull 2. Mae hwn yn ddewis hen ysgol ac ar yr un pryd yn syml iawn. A oes gennych ryw fath o weinydd sy'n cynhyrchu eich logiau. Ac mae'n ysgrifennu eich logiau i ffeil. Ac unwaith yr eiliad, er enghraifft, rydyn ni'n ailenwi'r ffeil hon ac yn rhwygo un newydd i ffwrdd. Ac mae sgript ar wahân, naill ai trwy cron neu ryw ellyll, yn cymryd y ffeil hynaf ac yn ei hysgrifennu i ClickHouse. Os byddwch chi'n recordio logiau unwaith yr eiliad, yna bydd popeth yn iawn.
Ond anfantais y dull hwn yw, os yw'ch gweinydd y cynhyrchir y logiau arno yn diflannu yn rhywle, yna bydd y data hefyd yn diflannu.
Dull 3. Mae dull diddorol arall, nad oes angen ffeiliau dros dro o gwbl. Er enghraifft, mae gennych ryw fath o droellwr hysbysebu neu ryw ellyll diddorol arall sy'n cynhyrchu data. A gallwch chi gronni criw o ddata yn uniongyrchol yn yr RAM, yn y byffer. A phan fydd digon o amser wedi mynd heibio, rydych chi'n rhoi'r byffer hwn o'r neilltu, yn creu un newydd, ac mewn edefyn ar wahân, yn mewnosod yr hyn sydd eisoes wedi cronni i ClickHouse.
Ar y llaw arall, mae'r data hefyd yn diflannu gyda lladd -9. Os bydd eich gweinydd yn chwalu, byddwch yn colli'r data hwn. A phroblem arall yw pe na baech yn gallu ysgrifennu at y gronfa ddata, yna bydd eich data'n cronni yn yr RAM. A naill ai bydd yr RAM yn dod i ben, neu byddwch yn colli data.
Dull 4. Dull diddorol arall. A oes gennych ryw fath o broses gweinydd. A gall anfon data i ClickHouse ar unwaith, ond gwnewch hynny mewn un cysylltiad. Er enghraifft, anfonais gais http gyda throsglwyddo-amgodio: chunked with insert. Ac mae'n cynhyrchu talpiau nad ydynt yn rhy anaml, gallwch anfon pob llinell, er y bydd gorbenion ar gyfer fframio'r data hwn.
Fodd bynnag, yn yr achos hwn bydd y data yn cael ei anfon i ClickHouse ar unwaith. A bydd ClickHouse yn eu clustogi ei hun.
Ond mae problemau'n codi hefyd. Nawr byddwch chi'n colli data, gan gynnwys pan fydd eich proses yn cael ei ladd ac os bydd y broses ClickHouse yn cael ei ladd, oherwydd bydd yn fewnosodiad anghyflawn. Ac yn ClickHouse mae mewnosodiadau yn atomig hyd at drothwy penodol penodol ym maint y rhesi. Mewn egwyddor, mae hon yn ffordd ddiddorol. Gellir ei ddefnyddio hefyd.
Dull 5. Dyma ddull diddorol arall. Mae hwn yn rhyw fath o weinydd a ddatblygwyd gan y gymuned ar gyfer sypynnu data. Nid wyf wedi edrych arno fy hun, felly ni allaf warantu dim. Fodd bynnag, ni ddarperir unrhyw warantau ar gyfer ClickHouse ei hun. Mae hwn hefyd yn ffynhonnell agored, ond ar y llaw arall, efallai eich bod wedi arfer â rhyw safon ansawdd yr ydym yn ceisio ei darparu. Ond am y peth hwn - wn i ddim, ewch i GitHub, edrychwch ar y cod. Efallai eu bod wedi ysgrifennu rhywbeth arferol.
* o 2020, dylid ei ychwanegu at yr ystyriaeth hefyd .
Dull 6. Dull arall yw defnyddio tablau byffer. Mantais y dull hwn yw ei fod yn hawdd iawn i ddechrau ei ddefnyddio. Creu bwrdd Clustogi a'i fewnosod ynddo.
Yr anfantais yw nad yw'r broblem wedi'i datrys yn llwyr. Os, mewn cyfradd fel MergeTree, mae'n rhaid i chi grwpio data fesul un swp yr eiliad, yna mewn cyfradd mewn tabl byffer, mae angen i chi grwpio o leiaf hyd at rai miloedd yr eiliad. Os yw'n fwy na 10 yr eiliad, bydd yn dal yn ddrwg. Ac os ydych chi'n ei fewnosod mewn sypiau, yna fe welsoch chi ei fod yn troi allan i fod yn gan mil o linellau yr eiliad. Ac mae hyn eisoes ar ddata eithaf trwm.
A hefyd nid oes gan dablau clustogi log. Ac os oes rhywbeth o'i le ar eich gweinydd, yna bydd y data yn cael ei golli.
Ac fel bonws, yn ddiweddar cawsom gyfle yn ClickHouse i adfer data o Kafka. Mae peiriant bwrdd - Kafka. Yn syml, rydych chi'n creu. A gallwch hongian cynrychioliadau materol arno. Yn yr achos hwn, bydd ei hun yn tynnu data o Kafka a'i fewnosod yn y tablau sydd eu hangen arnoch.
A'r hyn sy'n arbennig o braf am y cyfle hwn yw nad ni a wnaeth hynny. Mae hon yn nodwedd gymunedol. A phan ddywedaf “nodwedd gymunedol,” rwy’n ei olygu heb unrhyw ddirmyg. Fe wnaethon ni ddarllen y cod, gwneud adolygiad, dylai weithio'n iawn.
* o 2020, mae cefnogaeth debyg wedi ymddangos ar ei gyfer .
Beth arall allai fod yn anghyfleus neu'n annisgwyl wrth fewnosod data? Os gwnewch gais mewnosod gwerthoedd ac ysgrifennwch rai mynegiadau wedi'u cyfrifo mewn gwerthoedd. Er enghraifft, mae now() hefyd yn fynegiad wedi'i gyfrifo. Ac yn yr achos hwn, mae ClickHouse yn cael ei orfodi i lansio dehonglydd yr ymadroddion hyn ar bob llinell, a bydd perfformiad yn gostwng yn ôl trefn maint. Mae'n well osgoi hyn.
* ar hyn o bryd, mae'r broblem wedi'i datrys yn llwyr, nid oes unrhyw atchweliad perfformiad mwyach wrth ddefnyddio ymadroddion mewn GWERTHOEDD.
Enghraifft arall yw pan allai fod rhai problemau pan fydd gennych ddata ar un swp sy'n perthyn i griw o raniadau. Yn ddiofyn, mae rhaniadau ClickHouse fesul mis. Ac os mewnosodwch swp o filiwn o resi, a bod data ers sawl blwyddyn, yna bydd gennych sawl dwsin o raniad yno. Ac mae hyn yn cyfateb i'r ffaith y bydd sypiau sawl degau o weithiau'n llai o ran maint, oherwydd y tu mewn maent bob amser yn cael eu rhannu'n rhaniadau yn gyntaf.
* Yn ddiweddar, yn y modd arbrofol, ychwanegodd ClickHouse gefnogaeth ar gyfer y fformat cryno o dalpiau a thapiau mewn RAM gyda log ysgrifennu ymlaen llaw, sydd bron yn datrys y broblem yn llwyr.
Nawr, gadewch i ni edrych ar yr ail fath o broblem - teipio data.
Gall teipio data fod yn llym neu'n llinynnol. Llinyn yw pan fyddwch newydd ei gymryd a datgan bod eich holl feysydd yn llinyn fath. Mae hyn yn ofnadwy. Nid oes angen gwneud hyn.
Gadewch i ni ddarganfod sut i'w wneud yn gywir yn yr achosion hynny pan fyddwch chi eisiau dweud bod gennym ni ryw faes, llinyn, a gadewch i ClickHouse ei gyfrifo ar ei ben ei hun, ac ni fyddaf yn trafferthu. Ond mae'n dal yn werth gwneud rhywfaint o ymdrech.
Er enghraifft, mae gennym gyfeiriad IP. Mewn un achos, fe wnaethom ei arbed fel llinyn. Er enghraifft, 192.168.1.1. Ac mewn achos arall, bydd yn nifer o fath UInt32 *. Mae 32 did yn ddigon ar gyfer cyfeiriad IPv4.
Yn gyntaf, yn rhyfedd ddigon, bydd y data yn cael ei gywasgu fwy neu lai yn gyfartal. Bydd gwahaniaeth, wrth gwrs, ond nid mor fawr â hynny. Felly nid oes unrhyw broblemau arbennig gyda disg I/O.
Ond mae gwahaniaeth difrifol yn amser prosesydd ac amser gweithredu ymholiad.
Gadewch i ni gyfrif nifer y cyfeiriadau IP unigryw os ydynt yn cael eu storio fel rhifau. Mae hynny'n cyfateb i 137 miliwn o linellau yr eiliad. Os yw'r un peth ar ffurf llinynnau, yna 37 miliwn o linellau yr eiliad. Nid wyf yn gwybod pam y digwyddodd y cyd-ddigwyddiad hwn. Cyflawnais y ceisiadau hyn fy hun. Ond yn dal i fod tua 4 gwaith yn arafach.
Ac os ydych chi'n cyfrifo'r gwahaniaeth yn y gofod disg, yna mae gwahaniaeth hefyd. Ac mae'r gwahaniaeth tua chwarter, oherwydd mae yna lawer iawn o gyfeiriadau IP unigryw. A phe ceid llinellau ag iddynt nifer fechan o wahanol ystyron, hawdd fyddai eu cywasgu yn ol y geiriadur i'r un gyfrol tua'r un faint.
Ac nid yw'r gwahaniaeth amser pedwarplyg yn gorwedd ar y ffordd. Efallai nad ydych yn rhoi damn, wrth gwrs, ond pan welaf y fath wahaniaeth, mae'n fy ngwneud yn drist.
Gadewch i ni edrych ar wahanol achosion.
1. Un achos pan nad oes gennych lawer o wahanol werthoedd unigryw. Yn yr achos hwn, rydym yn defnyddio arfer syml y mae'n debyg eich bod yn ei wybod ac y gallwch ei ddefnyddio ar gyfer unrhyw DBMS. Mae hyn i gyd yn gwneud synnwyr nid yn unig i ClickHouse. Ysgrifennwch ddynodwyr rhifol i'r gronfa ddata. A gallwch chi drosi i llinynnau ac yn ôl ar ochr eich cais.
Er enghraifft, mae gennych chi ranbarth. Ac rydych chi'n ceisio ei arbed fel llinyn. A bydd yn cael ei ysgrifennu yno: Moscow a Moscow Rhanbarth. A phan welaf ei fod yn dweud “Moscow”, nid yw’n ddim byd, ond pan mai Moscow ydyw, mae’n mynd yn hollol drist rywsut. Dyma faint o beit.
Yn lle hynny, rydyn ni'n ysgrifennu'r rhif Ulnt32 a 250 i lawr. Mae gennym ni 250 yn Yandex, ond gall eich rhif chi fod yn wahanol. Rhag ofn, byddaf yn dweud bod gan ClickHouse allu adeiledig i weithio gyda geobase. Yn syml, rydych chi'n ysgrifennu cyfeiriadur gyda rhanbarthau, gan gynnwys un hierarchaidd, h.y. bydd Moscow, Rhanbarth Moscow, a phopeth sydd ei angen arnoch chi. A gallwch chi drosi ar lefel y cais.
Mae'r ail opsiwn tua'r un peth, ond gyda chefnogaeth y tu mewn i ClickHouse. Dyma'r math o ddata Enum. Yn syml, rydych chi'n ysgrifennu'r holl werthoedd sydd eu hangen arnoch chi y tu mewn i'r Enum. Er enghraifft, math o ddyfais ac ysgrifennu yno: bwrdd gwaith, ffôn symudol, tabled, teledu. Mae cyfanswm o 4 opsiwn.
Yr anfantais yw bod angen i chi ei newid o bryd i'w gilydd. Dim ond un opsiwn sydd wedi'i ychwanegu. Gadewch i ni newid y tabl. Mewn gwirionedd, mae tabl alter yn ClickHouse yn rhad ac am ddim. Yn enwedig am ddim i Enum oherwydd nad yw'r data ar ddisg yn newid. Ond serch hynny, mae alter yn caffael clo* ar y bwrdd a rhaid iddo aros nes bod pob dewis wedi'i gyflawni. A dim ond ar ôl i'r newid hwn gael ei wneud, h.y. mae rhai anghyfleustra o hyd.
* yn y fersiynau diweddaraf o ClickHouse, mae ALTER yn cael ei wneud yn hollol ddi-rwystro.
Opsiwn arall sy'n eithaf unigryw i ClickHouse yw cysylltu geiriaduron allanol. Gallwch ysgrifennu rhifau yn ClickHouse, a chadw'ch cyfeiriaduron mewn unrhyw system sy'n gyfleus i chi. Er enghraifft, gallwch ddefnyddio: MySQL, Mongo, Postgres. Gallwch hyd yn oed greu eich meicrowasanaeth eich hun a fydd yn anfon y data hwn trwy http. Ac ar lefel ClickHouse, rydych chi'n ysgrifennu swyddogaeth a fydd yn trosi'r data hwn o rifau i linynnau.
Mae hon yn ffordd arbenigol ond effeithlon iawn o berfformio uniad ar fwrdd allanol. Ac mae dau opsiwn. Mewn un ymgorfforiad, bydd y data hwn yn cael ei storio'n llwyr, yn gwbl bresennol yn yr RAM a'i ddiweddaru'n eithaf aml. Ac mewn opsiwn arall, os nad yw'r data hwn yn ffitio i'r RAM, yna gallwch chi ei storio'n rhannol.
Dyma enghraifft. Mae yna Yandex.Direct. Ac mae yna gwmni hysbysebu a baneri. Mae'n debyg bod tua degau o filiynau o gwmnïau hysbysebu. Ac maen nhw'n ffitio'n fras i'r RAM. Ac mae yna biliynau o faneri, dydyn nhw ddim yn ffitio. Ac rydym yn defnyddio geiriadur wedi'i storio o MySQL.
Yr unig broblem yw y bydd y geiriadur cached yn gweithio'n iawn os yw'r gyfradd taro yn agos at 100%. Os yw'n llai, yna wrth brosesu ymholiadau ar gyfer pob swp o ddata, mewn gwirionedd bydd yn rhaid i chi gymryd yr allweddi coll a mynd i gael y data o MySQL. Ynglŷn â ClickHouse, gallaf warantu o hyd - ie, nid yw'n arafu, ni fyddaf yn siarad am systemau eraill.
Ac fel bonws, mae geiriaduron yn ffordd hawdd iawn o ddiweddaru data yn ôl-weithredol yn ClickHouse. Hynny yw, cawsoch adroddiad ar gwmnïau hysbysebu, newidiodd y defnyddiwr y cwmni hysbysebu yn syml ac yn yr holl hen ddata, ym mhob adroddiad, newidiodd y data hwn hefyd. Os byddwch chi'n ysgrifennu rhesi yn uniongyrchol i'r bwrdd, bydd yn amhosibl eu diweddaru.
Ffordd arall pan nad ydych chi'n gwybod ble i gael y dynodwyr ar gyfer eich llinynnau. gallwch chi ei hash yn syml. Ar ben hynny, yr opsiwn symlaf yw cymryd hash 64-bit.
Yr unig broblem yw, os yw'r hash yn 64-bit, yna mae bron yn sicr y byddwch chi'n cael gwrthdrawiadau. Oherwydd os oes biliwn o linellau yno, yna mae'r tebygolrwydd eisoes yn dod yn amlwg.
Ac ni fyddai'n dda iawn hash enwau cwmnïau hysbysebu yn y modd hwn. Os yw ymgyrchoedd hysbysebu gwahanol gwmnïau yn gymysg, yna bydd rhywbeth annealladwy.
Ac mae tric syml. Yn wir, nid yw hefyd yn addas iawn ar gyfer data difrifol, ond os nad yw rhywbeth yn ddifrifol iawn, yna ychwanegwch y dynodwr cleient at allwedd y geiriadur. Ac yna bydd gennych wrthdrawiadau, ond dim ond o fewn un cleient. Ac rydym yn defnyddio'r dull hwn ar gyfer mapiau cyswllt yn Yandex.Metrica. Mae gennym URLs yno, rydym yn storio hashes. Ac rydym ni'n gwybod, wrth gwrs, bod yna wrthdrawiadau. Ond pan fydd y dudalen yn cael ei harddangos, gellir esgeuluso'r tebygolrwydd bod rhai URLau ar un dudalen o un defnyddiwr yn sownd gyda'i gilydd a bydd hyn yn cael ei sylwi.
Fel bonws, ar gyfer llawer o lawdriniaethau mae hashes yn unig yn ddigon ac nid oes angen storio'r tannau eu hunain yn unrhyw le.
Enghraifft arall yw os yw'r llinynnau'n fyr, er enghraifft, parthau gwefan. Gellir eu storio fel y mae. Neu, er enghraifft, iaith y porwr ru – 2 beit. Wrth gwrs, dwi wir yn teimlo trueni am y bytes, ond peidiwch â phoeni, nid yw 2 beit yn drueni. Cadwch ef fel y mae, peidiwch â phoeni.
Achos arall yw pan, i'r gwrthwyneb, mae yna lawer o linellau ac mae yna lawer o rai unigryw ynddynt, ac mae hyd yn oed y set yn ddiderfyn o bosibl. Enghraifft nodweddiadol yw ymadroddion chwilio neu URLs. Ymadroddion chwilio, gan gynnwys teipio. Gadewch i ni weld faint o ymadroddion chwilio unigryw sydd bob dydd. Ac mae'n troi allan eu bod bron i hanner yr holl ddigwyddiadau. Ac yn yr achos hwn, efallai y byddwch chi'n meddwl bod angen i chi normaleiddio'r data, cyfrif y dynodwyr, a'i roi mewn tabl ar wahân. Ond nid oes angen i chi wneud hynny. Cadwch y llinellau hyn fel y maent.
Mae'n well peidio â dyfeisio unrhyw beth, oherwydd os ydych chi'n ei storio ar wahân, bydd angen i chi ymuno. Ac mae'r ymuno hwn, ar y gorau, yn fynediad ar hap i'r cof, os yw'n dal i ffitio yn y cof. Os nad yw'n ffitio, yna bydd problemau.
Ac os yw'r data'n cael ei storio yn ei le, yna fe'i darllenir yn y drefn gywir o'r system ffeiliau ac mae popeth yn iawn.
Os oes gennych URLs neu linyn hir cymhleth arall, yna mae'n werth ystyried y gallwch chi gyfrifo rhyw fath o ddyfyniad ymlaen llaw a'i ysgrifennu mewn colofn ar wahân.
Ar gyfer URLs, er enghraifft, gallwch storio'r parth ar wahân. Ac os oes gwir angen parth arnoch chi, yna defnyddiwch y golofn hon, a bydd yr URLau yn gorwedd yno, ac ni fyddwch hyd yn oed yn eu cyffwrdd.
Gawn ni weld beth yw'r gwahaniaeth. Mae gan ClickHouse swyddogaeth arbenigol sy'n cyfrifo'r parth. Mae'n gyflym iawn, rydym wedi ei optimeiddio. Ac, i fod yn onest, nid yw hyd yn oed yn cydymffurfio â'r Clwb Rygbi, ond serch hynny mae'n ystyried popeth sydd ei angen arnom.
Ac mewn un achos, byddwn yn syml yn cael yr URLs ac yn cyfrifo'r parth. Mae hynny'n gweithio allan i 166 milieiliad. Ac os cymerwch barth parod, yna mae'n troi allan i fod yn ddim ond 67 milieiliad, h.y. bron deirgwaith yn gyflymach. Ac mae'n gyflymach nid oherwydd bod angen i ni wneud rhai cyfrifiadau, ond oherwydd ein bod yn darllen llai o ddata.
Dyna pam mae gan un cais, sy'n arafach, gyflymder uwch o gigabeit yr eiliad. Oherwydd ei fod yn darllen mwy gigabeit. Mae hwn yn ddata cwbl ddiangen. Mae'n ymddangos bod y cais yn rhedeg yn gyflymach, ond mae'n cymryd mwy o amser i'w gwblhau.
Ac os edrychwch ar faint o ddata ar y ddisg, mae'n ymddangos bod yr URL yn 126 megabeit, a dim ond 5 megabeit yw'r parth. Mae'n troi allan 25 gwaith yn llai. Ond serch hynny, dim ond 4 gwaith yn gyflymach y gweithredir y cais. Ond mae hynny oherwydd bod y data yn boeth. A phe bai'n oer, mae'n debyg y byddai 25 gwaith yn gyflymach oherwydd disg I/O.
Gyda llaw, os ydych chi'n amcangyfrif faint yn llai yw parth nag URL, mae'n troi allan i fod tua 4 gwaith yn llai.Ond am ryw reswm, mae'r data'n cymryd 25 gwaith yn llai ar ddisg. Pam? Oherwydd cywasgu. Ac mae'r URL wedi'i gywasgu, ac mae'r parth wedi'i gywasgu. Ond yn aml mae'r URL yn cynnwys llawer o sbwriel.
Ac, wrth gwrs, mae'n talu i ddefnyddio'r mathau cywir o ddata sydd wedi'u cynllunio'n benodol ar gyfer y gwerthoedd a ddymunir neu sy'n addas. Os ydych chi yn IPv4, storiwch UInt32*. Os yw IPv6, yna FixedString(16), oherwydd bod y cyfeiriad IPv6 yn ddarnau 128, h.y. wedi'i storio'n uniongyrchol mewn fformat deuaidd.
Ond beth os oes gennych chi weithiau gyfeiriadau IPv4 ac weithiau IPv6? Oes, gallwch chi storio'r ddau. Un golofn ar gyfer IPv4, un arall ar gyfer IPv6. Wrth gwrs, mae opsiwn i arddangos IPv4 yn IPv6. Bydd hyn hefyd yn gweithio, ond os oes angen cyfeiriad IPv4 arnoch yn aml mewn ceisiadau, yna byddai'n braf ei roi mewn colofn ar wahân.
* Bellach mae gan ClickHouse fathau o ddata IPv4, IPv6 ar wahân sy'n storio data mor effeithlon â rhifau, ond yn eu cynrychioli mor gyfleus â llinynnau.
Mae hefyd yn bwysig nodi ei bod yn werth rhagbrosesu'r data ymlaen llaw. Er enghraifft, byddwch yn derbyn rhai logiau amrwd. Ac efallai na ddylech chi eu rhoi yn ClickHouse ar unwaith, er ei bod yn demtasiwn iawn gwneud dim a bydd popeth yn gweithio. Ond mae'n dal yn werth gwneud y cyfrifiadau sy'n bosibl.
Er enghraifft, fersiwn porwr. Mewn rhai adrannau cyfagos, nad wyf am bwyntio bys ati, mae fersiwn y porwr yn cael ei storio fel hyn, hynny yw, fel llinyn: 12.3. Ac yna, i wneud adroddiad, maen nhw'n cymryd y llinyn hwn ac yn ei rannu'n arae, ac yna yn elfen gyntaf yr arae. Yn naturiol, mae popeth yn arafu. Gofynnais pam eu bod yn gwneud hyn. Dywedasant wrthyf nad ydynt yn hoffi optimeiddio cynamserol. A dydw i ddim yn hoffi pesimeiddio cynamserol.
Felly yn yr achos hwn byddai'n fwy cywir rhannu'n 4 colofn. Peidiwch â bod ofn yma, oherwydd ClickHouse yw hwn. Cronfa ddata golofnog yw ClickHouse. A gorau po fwyaf o golofnau bach taclus. Bydd 5 BrowserVersions, gwnewch 5 colofn. Mae hyn yn iawn.
Nawr, gadewch i ni edrych ar beth i'w wneud os oes gennych lawer o linynnau hir iawn, araeau hir iawn. Nid oes angen eu storio yn ClickHouse o gwbl. Yn lle hynny, dim ond yn ClickHouse y gallwch chi storio dynodwr. A rhowch y llinellau hir hyn mewn rhyw system arall.
Er enghraifft, mae gan un o'n gwasanaethau dadansoddeg rai paramedrau digwyddiadau. Ac os oes llawer o baramedrau ar gyfer digwyddiadau, rydym yn syml yn arbed y 512 cyntaf sy'n dod ar eu traws, oherwydd nid yw 512 yn drueni.
Ac os na allwch benderfynu ar eich mathau o ddata, yna gallwch hefyd gofnodi data yn ClickHouse, ond mewn tabl dros dro o'r math Log, arbennig ar gyfer data dros dro. Ar ôl hyn, gallwch ddadansoddi pa ddosbarthiad o werthoedd sydd gennych yno, beth sydd yno yn gyffredinol, a chreu'r mathau cywir.
*Mae gan ClickHouse fath o ddata bellach sy'n eich galluogi i storio llinynnau'n effeithlon gyda llai o ymdrech.
Nawr, gadewch i ni edrych ar achos diddorol arall. Weithiau mae pethau'n gweithio'n rhyfedd i bobl. Rwy'n dod i mewn i weld hwn. Ac mae'n ymddangos ar unwaith bod hyn wedi'i wneud gan weinyddwr craff, profiadol iawn sydd â phrofiad helaeth o sefydlu fersiwn MySQL 3.23.
Yma gwelwn fil o fyrddau, a phob un ohonynt yn cofnodi gweddill y rhannu pwy a wyr beth â mil.
Mewn egwyddor, rwy’n parchu profiad pobl eraill, gan gynnwys y ddealltwriaeth o’r dioddefaint y gellir ei ennill trwy’r profiad hwn.
Ac mae'r rhesymau fwy neu lai yn glir. Mae'r rhain yn hen stereoteipiau a allai fod wedi cronni wrth weithio gyda systemau eraill. Er enghraifft, nid oes gan dablau MyISAM allwedd gynradd glystyrog. Ac efallai y bydd y ffordd hon o rannu data yn ymgais anobeithiol i gael yr un ymarferoldeb.
Rheswm arall yw ei bod yn anodd gwneud unrhyw weithrediadau newid ar fyrddau mawr. Bydd popeth yn cael ei rwystro. Er mewn fersiynau modern o MySQL nid yw'r broblem hon mor ddifrifol mwyach.
Neu, er enghraifft, microsharding, ond mwy am hynny yn nes ymlaen.
Nid oes angen gwneud hyn yn ClickHouse, oherwydd, yn gyntaf, mae'r allwedd gynradd wedi'i chlystyru, mae'r data wedi'i drefnu yn ôl yr allwedd gynradd.
Ac weithiau mae pobl yn gofyn i mi: “Sut mae perfformiad ymholiadau amrediad yn ClickHouse yn amrywio yn dibynnu ar faint y bwrdd?” Rwy'n dweud nad yw'n newid o gwbl. Er enghraifft, mae gennych chi fwrdd gyda biliwn o resi ac rydych chi'n darllen ystod o filiwn o resi. Mae popeth yn iawn. Os oes triliwn o resi mewn tabl a'ch bod chi'n darllen miliwn o resi, bydd bron yr un peth.
Ac, yn ail, nid oes angen pob math o bethau fel rhaniadau llaw. Os ewch chi i mewn ac edrych ar yr hyn sydd ar y system ffeiliau, fe welwch fod y tabl yn fargen eithaf mawr. Ac mae rhywbeth fel rhaniadau y tu mewn. Hynny yw, mae ClickHouse yn gwneud popeth i chi ac nid oes rhaid i chi ddioddef.
Mae alter yn ClickHouse am ddim os newidiwch y golofn ychwanegu/gollwng.
Ac ni ddylech wneud tablau bach, oherwydd os oes gennych 10 rhes neu 10 o resi mewn tabl, yna nid oes ots o gwbl. Mae ClickHouse yn system sy'n gwneud y gorau o fewnbwn, nid hwyrni, felly nid yw'n gwneud unrhyw synnwyr i brosesu 000 llinell.
Mae'n gywir defnyddio un bwrdd mawr. Cael gwared ar hen stereoteipiau, bydd popeth yn iawn.
Ac fel bonws, yn y fersiwn ddiweddaraf mae gennym bellach y gallu i greu allwedd rhaniad mympwyol er mwyn cyflawni pob math o weithrediadau cynnal a chadw ar raniadau unigol.
Er enghraifft, mae angen llawer o dablau bach arnoch chi, er enghraifft, pan fydd angen prosesu rhywfaint o ddata canolradd, rydych chi'n derbyn talpiau ac mae angen i chi berfformio trawsnewidiad arnyn nhw cyn ysgrifennu at y tabl terfynol. Ar gyfer yr achos hwn, mae peiriant bwrdd gwych - StripeLog. Mae'n fath o fel TinyLog, dim ond yn well.
* nawr mae gan ClickHouse hefyd .
Antipattern arall yw microsharding. Er enghraifft, mae angen i chi dorri data ac mae gennych 5 gweinydd, ac yfory bydd 6 gweinydd. Ac rydych chi'n meddwl sut i ail-gydbwyso'r data hwn. Ac yn lle hynny rydych chi'n torri nid yn 5 darn, ond yn 1 o ddarnau. Ac yna rydych chi'n mapio pob un o'r microshards hyn i weinydd ar wahân. A byddwch yn cael, er enghraifft, 000 ClickHouses ar un gweinydd, er enghraifft. Achosion ar wahân ar borthladdoedd ar wahân neu gronfeydd data ar wahân.
Ond nid yw hyn yn dda iawn yn ClickHouse. Oherwydd bod hyd yn oed un enghraifft ClickHouse yn ceisio defnyddio'r holl adnoddau gweinydd sydd ar gael i brosesu un cais. Hynny yw, mae gennych chi ryw fath o weinydd ac mae ganddo, er enghraifft, 56 craidd prosesydd. Rydych chi'n rhedeg ymholiad sy'n cymryd eiliad a bydd yn defnyddio 56 craidd. Ac os gwnaethoch chi osod 200 o ClickHouses yno ar un gweinydd, yna mae'n ymddangos y bydd 10 o edafedd yn cychwyn. Yn gyffredinol, bydd popeth yn ddrwg iawn.
Rheswm arall yw y bydd dosbarthiad y gwaith ar draws yr achosion hyn yn anghyson. Bydd rhai yn gorffen yn gynharach, bydd rhai yn gorffen yn ddiweddarach. Pe bai hyn i gyd yn digwydd mewn un achos, yna byddai ClickHouse ei hun yn darganfod sut i ddosbarthu'r data yn gywir ymhlith yr edafedd.
A rheswm arall yw y bydd gennych gyfathrebu rhyngbrosesydd trwy TCP. Bydd yn rhaid i'r data gael ei gyfresoli, ei ddad-gyfresi, ac mae hyn yn nifer enfawr o microshards. Yn syml, ni fydd yn gweithio'n effeithiol.
Gwrthbatrwm arall, er mai prin y gellir ei alw'n wrthbattern. Mae hyn yn swm mawr o rhag-gasglu.
Yn gyffredinol, mae cyn-gasgliad yn dda. Roedd gennych chi biliwn o resi, fe wnaethoch chi ei agregu a daeth yn 1 o resi, a nawr mae'r ymholiad yn cael ei weithredu ar unwaith. Mae popeth yn wych. Gallwch chi wneud hyn. Ac ar gyfer hyn, mae gan hyd yn oed ClickHouse fath o dabl arbennig, AggregatingMergeTree, sy'n perfformio agregu cynyddrannol wrth i ddata gael ei fewnosod.
Ond mae yna adegau pan fyddwch chi'n meddwl y byddwn ni'n cydgrynhoi data fel hyn a data cyfanredol fel hyn. Ac mewn rhai adrannau cyfagos, nid wyf ychwaith am ddweud pa un, maen nhw'n defnyddio tablau SummingMergeTree i grynhoi yn ôl yr allwedd gynradd, a defnyddir tua 20 colofn fel y brif allwedd. Rhag ofn, fe wnes i newid enwau rhai colofnau er mwyn cyfrinachedd, ond dyna ni fwy neu lai.
Ac mae problemau o'r fath yn codi. Yn gyntaf, nid yw cyfaint eich data yn lleihau gormod. Er enghraifft, mae'n gostwng deirgwaith. Byddai tair gwaith yn bris da i fforddio'r galluoedd dadansoddeg diderfyn sy'n codi os na chaiff eich data ei agregu. Os caiff y data ei agregu, yna yn lle dadansoddeg dim ond ystadegau truenus a gewch.
A beth sydd mor arbennig amdano? Y ffaith yw bod y bobl hyn o'r adran gyfagos weithiau'n mynd i ofyn am ychwanegu colofn arall at y cywair cynradd. Hynny yw, fe wnaethon ni gyfuno'r data fel hyn, ond nawr rydyn ni eisiau ychydig mwy. Ond nid oes gan ClickHouse allwedd gynradd alter. Felly, mae'n rhaid i ni ysgrifennu rhai sgriptiau yn C ++. A dydw i ddim yn hoffi sgriptiau, hyd yn oed os ydyn nhw yn C ++.
Ac os edrychwch ar yr hyn y crëwyd ClickHouse ar ei gyfer, yna data heb ei agregu yw'r union senario y cafodd ei eni ar ei gyfer. Os ydych chi'n defnyddio ClickHouse ar gyfer data heb ei agregu, yna rydych chi'n ei wneud yn iawn. Os byddwch yn agregu, mae hyn weithiau'n faddeuadwy.
Achos diddorol arall yw ymholiadau mewn dolen ddiddiwedd. Weithiau rwy'n mynd i ryw weinydd cynhyrchu ac yn edrych ar restr proses y sioe yno. A phob tro dwi'n darganfod bod rhywbeth ofnadwy yn digwydd.
Er enghraifft, fel hyn. Mae'n amlwg ar unwaith y gellid gwneud popeth mewn un cais. Ysgrifennwch yr url a'r rhestr yno.
Pam mae llawer o ymholiadau o'r fath mewn dolen ddiddiwedd yn ddrwg? Os na ddefnyddir mynegai, yna bydd gennych lawer o basiadau dros yr un data. Ond os defnyddir y mynegai, er enghraifft, mae gennych allwedd gynradd ar gyfer ru a byddwch yn ysgrifennu url = rhywbeth yno. Ac rydych chi'n meddwl, os mai dim ond un URL sy'n cael ei ddarllen o'r tabl, bydd popeth yn iawn. Ond mewn gwirionedd na. Oherwydd bod ClickHouse yn gwneud popeth mewn sypiau.
Pan fydd angen iddo ddarllen ystod benodol o ddata, mae'n darllen ychydig mwy, oherwydd mae'r mynegai yn ClickHouse yn denau. Nid yw'r mynegai hwn yn caniatáu ichi ddod o hyd i un rhes unigol yn y tabl, dim ond ystod o ryw fath. Ac mae'r data wedi'i gywasgu mewn blociau. Er mwyn darllen un llinell, mae angen i chi gymryd y bloc cyfan a'i ddadelfennu. Ac os ydych chi'n gwneud criw o ymholiadau, bydd gennych chi lawer o orgyffwrdd, a bydd gennych chi lawer o waith i'w wneud dro ar ôl tro.
Ac fel bonws, gallwch nodi yn ClickHouse na ddylech ofni trosglwyddo hyd yn oed megabeit a hyd yn oed cannoedd o megabeit i'r adran IN. Rwy'n cofio o'n harfer, os ydym yn MySQL yn trosglwyddo criw o werthoedd i'r adran IN, er enghraifft, rydym yn trosglwyddo 100 megabeit o rai niferoedd yno, yna mae MySQL yn bwyta 10 gigabeit o gof a dim byd arall yn digwydd iddo, popeth yn gweithio'n wael.
A'r ail yw, yn ClickHouse, os yw'ch ymholiadau'n defnyddio mynegai, yna nid yw bob amser yn arafach na sgan llawn, h.y. os oes angen i chi ddarllen bron y tabl cyfan, bydd yn mynd yn olynol ac yn darllen y tabl cyfan. Yn gyffredinol, bydd yn ei ddarganfod ar ei ben ei hun.
Ond serch hynny, mae rhai anawsterau. Er enghraifft, y ffaith nad yw IN gyda subquery yn defnyddio'r mynegai. Ond dyma ein problem ni ac mae angen i ni ei thrwsio. Nid oes dim byd sylfaenol yma. Byddwn yn ei drwsio*.
A pheth diddorol arall yw, os oes gennych gais hir iawn a bod prosesu ceisiadau wedi'u dosbarthu ar y gweill, yna bydd y cais hir iawn hwn yn cael ei anfon at bob gweinydd heb ei gywasgu. Er enghraifft, 100 megabeit a 500 o weinyddion. Ac, yn unol â hynny, bydd gennych 50 gigabeit wedi'i drosglwyddo dros y rhwydwaith. Bydd yn cael ei drosglwyddo ac yna bydd popeth yn cael ei gwblhau'n llwyddiannus.
* eisoes yn defnyddio; Roedd popeth yn sefydlog fel yr addawyd.
Ac achos eithaf cyffredin yw pan ddaw ceisiadau gan yr API. Er enghraifft, fe wnaethoch chi greu rhyw fath o'ch gwasanaeth eich hun. Ac os oes angen eich gwasanaeth ar rywun, yna rydych chi'n agor yr API ac yn llythrennol ddeuddydd yn ddiweddarach rydych chi'n gweld bod rhywbeth annealladwy yn digwydd. Mae popeth wedi'i orlwytho ac mae rhai ceisiadau ofnadwy yn dod i mewn na ddylai byth fod wedi digwydd.
A dim ond un ateb sydd. Os ydych chi wedi agor yr API, yna bydd yn rhaid i chi ei dorri. Er enghraifft, cyflwyno rhyw fath o gwotâu. Nid oes unrhyw opsiynau arferol eraill. Fel arall, byddant yn ysgrifennu sgript ar unwaith a bydd problemau.
Ac mae gan ClickHouse nodwedd arbennig - cyfrifiad cwota. Ar ben hynny, gallwch drosglwyddo eich allwedd cwota. Dyma, er enghraifft, yr ID defnyddiwr mewnol. A bydd cwotâu yn cael eu cyfrifo'n annibynnol ar gyfer pob un ohonynt.
Nawr peth diddorol arall. Dyblygiad â llaw yw hwn.
Gwn am lawer o achosion lle mae pobl, er bod ClickHouse yn cynnwys cefnogaeth atgynhyrchu, yn atgynhyrchu ClickHouse â llaw.
Beth yw'r egwyddor? Mae gennych chi biblinell prosesu data. Ac mae'n gweithio'n annibynnol, er enghraifft, mewn gwahanol ganolfannau data. Rydych chi'n ysgrifennu'r un data yn yr un modd yn ClickHouse. Yn wir, mae arfer yn dangos y bydd y data yn dal i ymwahanu oherwydd rhai nodweddion yn eich cod. Rwy'n gobeithio ei fod yn eich un chi.
Ac o bryd i'w gilydd bydd yn rhaid i chi gysoni â llaw o hyd. Er enghraifft, unwaith y mis mae gweinyddwyr yn gwneud rsync.
Mewn gwirionedd, mae'n llawer haws defnyddio'r atgynhyrchu sydd wedi'i ymgorffori yn ClickHouse. Ond efallai y bydd rhai gwrtharwyddion, oherwydd ar gyfer hyn mae angen i chi ddefnyddio ZooKeeper. Ni ddywedaf unrhyw beth drwg am ZooKeeper, mewn egwyddor, mae'r system yn gweithio, ond mae'n digwydd nad yw pobl yn ei ddefnyddio oherwydd java-phobia, oherwydd mae ClickHouse yn system mor dda, wedi'i hysgrifennu yn C ++, y gallwch ei defnyddio a bydd popeth yn iawn . Ac mae ZooKeeper yn java. A rhywsut nid ydych chi hyd yn oed eisiau edrych, ond yna gallwch chi ddefnyddio dyblygu â llaw.
Mae ClickHouse yn system ymarferol. Mae hi'n cymryd eich anghenion i ystyriaeth. Os oes gennych chi ddyblygiad â llaw, yna gallwch chi greu tabl Dosbarthedig sy'n edrych ar eich atgynyrchiadau â llaw ac sy'n gwneud methiant rhyngddynt. Ac mae hyd yn oed opsiwn arbennig sy'n eich galluogi i osgoi fflops, hyd yn oed os yw'ch llinellau'n dargyfeirio'n systematig.
Gall problemau pellach godi os byddwch yn defnyddio peiriannau bwrdd cyntefig. Mae ClickHouse yn adeiladwr sydd â llawer o wahanol beiriannau bwrdd. Ar gyfer pob achos difrifol, fel yr ysgrifennwyd yn y ddogfennaeth, defnyddiwch dablau o'r teulu MergeTree. A'r gweddill i gyd - mae hyn felly, ar gyfer achosion unigol neu ar gyfer profion.
Mewn tabl MergeTree, nid oes angen i chi gael unrhyw ddyddiad ac amser. Gallwch chi ei ddefnyddio o hyd. Os nad oes dyddiad ac amser, ysgrifennwch mai 2000 yw'r rhagosodiad. Bydd hyn yn gweithio ac ni fydd angen adnoddau.
Ac yn y fersiwn newydd o'r gweinydd, gallwch chi hyd yn oed nodi bod gennych chi raniad arferol heb allwedd rhaniad. Bydd yr un peth.
Ar y llaw arall, gallwch ddefnyddio peiriannau bwrdd cyntefig. Er enghraifft, llenwch y data unwaith ac edrych, troelli a dileu. Gallwch ddefnyddio Log.
Neu storio cyfeintiau bach ar gyfer prosesu canolradd yw StripeLog neu TinyLog.
Gellir defnyddio cof os yw'r swm o ddata yn fach a'ch bod yn gallu twiddle rhywbeth yn yr RAM.
Nid yw ClickHouse yn hoff iawn o ddata wedi'i ailnormaleiddio.
Dyma enghraifft nodweddiadol. Mae hyn yn nifer enfawr o URLs. Rydych chi'n eu rhoi yn y tabl nesaf. Ac yna fe benderfynon nhw YMUNO â nhw, ond ni fydd hyn yn gweithio, fel rheol, oherwydd mae ClickHouse yn cefnogi Hash JOIN yn unig. Os nad oes digon o RAM ar gyfer llawer o ddata y mae angen ei gysylltu, yna ni fydd JOIN yn gweithio*.
Os yw'r data o gardinalrwydd uchel, yna peidiwch â phoeni, storiwch ef ar ffurf ddadnormaleiddio, mae'r URLau yn eu lle yn uniongyrchol yn y prif dabl.
* a nawr mae gan ClickHouse uniad uno hefyd, ac mae'n gweithio mewn amodau lle nad yw data canolradd yn ffitio i'r RAM. Ond mae hyn yn aneffeithiol ac mae'r argymhelliad yn parhau mewn grym.
Cwpl mwy o enghreifftiau, ond rwyf eisoes yn amau a ydynt yn wrth-batrwm ai peidio.
Mae gan ClickHouse un nam hysbys. Nid yw'n gwybod sut i ddiweddaru *. Mewn rhai ffyrdd, mae hyn hyd yn oed yn dda. Os oes gennych chi rywfaint o ddata pwysig, er enghraifft, cyfrifyddu, yna ni fydd unrhyw un yn gallu ei anfon, oherwydd nid oes unrhyw ddiweddariadau.
* Mae cefnogaeth ar gyfer diweddaru a dileu yn y modd swp wedi'i ychwanegu amser maith yn ôl.
Ond mae yna rai ffyrdd arbennig sy'n caniatáu diweddariadau fel pe bai yn y cefndir. Er enghraifft, tablau fel ReplaceMergeTree. Maent yn gwneud diweddariadau yn ystod cyfuniadau cefndir. Gallwch orfodi hyn gan ddefnyddio tabl optimeiddio. Ond peidiwch â gwneud hyn yn rhy aml, oherwydd bydd yn trosysgrifo'r rhaniad yn llwyr.
Mae'r cynlluniwr ymholiad hefyd yn delio'n wael ag JOINs Dosranedig yn ClickHouse.
Drwg, ond weithiau Iawn.
Defnyddio ClickHouse yn unig i ddarllen data yn ôl gan ddefnyddio dewis*.
Ni fyddwn yn argymell defnyddio ClickHouse ar gyfer cyfrifiadau beichus. Ond nid yw hyn yn gwbl wir, oherwydd rydym eisoes yn symud oddi wrth yr argymhelliad hwn. Ac yn ddiweddar fe wnaethom ychwanegu'r gallu i gymhwyso modelau dysgu peiriant yn ClickHouse - Catboost. Ac mae'n fy mhoeni oherwydd dwi'n meddwl, “Am arswyd. Dyma faint o gylchredau fesul beit mae'n troi allan! Dwi wir yn casáu gwastraffu clociau ar beit.
Ond peidiwch â bod ofn, gosodwch ClickHouse, bydd popeth yn iawn. Os rhywbeth, mae gennym ni gymuned. Gyda llaw, chi yw'r gymuned. Ac os oes gennych unrhyw broblemau, gallwch o leiaf fynd i'n sgwrs, a gobeithio y byddant yn eich helpu.
cwestiynau
Diolch am yr adroddiad! Ble alla i gwyno am ddamwain ClickHouse?
Gallwch chi gwyno wrthyf yn bersonol ar hyn o bryd.
Dechreuais ddefnyddio ClickHouse yn ddiweddar. Fe wnes i ollwng y rhyngwyneb cli ar unwaith.
Am sgôr.
Ychydig yn ddiweddarach fe wnes i ddamwain y gweinydd gyda dewis bach.
Mae gennych dalent.
Agorais fyg GitHub, ond cafodd ei anwybyddu.
Gawn ni weld.
Twyllodd Alexey fi i fynychu'r adroddiad, gan addo dweud wrthyf sut rydych chi'n cyrchu'r data y tu mewn.
Syml iawn.
Sylweddolais hyn ddoe. Mwy o fanylion.
Nid oes unrhyw driciau ofnadwy yno. Dim ond cywasgu bloc wrth bloc sydd. Y rhagosodiad yw LZ4, gallwch chi alluogi ZSTD *. Blociau o 64 kilobeit i 1 megabeit.
* mae cefnogaeth hefyd i godecs cywasgu arbenigol y gellir eu defnyddio mewn cadwyn ag algorithmau eraill.
Ai data crai yn unig yw'r blociau?
Ddim yn hollol amrwd. Mae yna araeau. Os oes gennych chi golofn rifiadol, yna mae rhifau mewn rhes yn cael eu rhoi mewn arae.
Mae'n amlwg.
Alexey, enghraifft a oedd gydag uniqExact dros IPs, h.y. y ffaith bod uniqExact yn cymryd mwy o amser i’w gyfrifo fesul llinellau nag yn ôl rhifau, ac ati. Beth os byddwn yn defnyddio feint gyda'n clustiau a'n cast ar adeg prawfddarllen? Hynny yw, mae'n ymddangos eich bod wedi dweud nad yw'n wahanol iawn ar ein disg. Os byddwn yn darllen llinellau o ddisg a chast, a fydd ein hagregau yn gyflymach ai peidio? Neu a fyddwn ni'n dal i ennill ychydig yma? Mae'n ymddangos i mi eich bod wedi profi hyn, ond am ryw reswm heb ei nodi yn y meincnod.
Rwy'n credu y bydd yn arafach na heb gastio. Yn yr achos hwn, rhaid dosrannu'r cyfeiriad IP o'r llinyn. Wrth gwrs, yn ClickHouse, mae ein dosrannu cyfeiriad IP hefyd wedi'i optimeiddio. Fe wnaethon ni ymdrechu'n galed iawn, ond mae gennych chi'r niferoedd wedi'u hysgrifennu mewn deng milfed dosbarth. Yn anghyfforddus iawn. Ar y llaw arall, bydd y swyddogaeth uniqExact yn gweithio'n arafach ar linynnau, nid yn unig oherwydd bod y rhain yn llinynnau, ond hefyd oherwydd bod arbenigedd gwahanol o'r algorithm yn cael ei ddewis. Yn syml, caiff llinynnau eu prosesu'n wahanol.
Beth os ydym yn cymryd math o ddata mwy cyntefig? Er enghraifft, fe wnaethon ni ysgrifennu'r ID defnyddiwr, sydd gennym ni, ei ysgrifennu i lawr fel llinell, ac yna ei sgramblo, a fydd yn fwy o hwyl ai peidio?
Rwy'n amau. Rwy’n meddwl y bydd yn dristach fyth, oherwydd wedi’r cyfan, mae dosrannu niferoedd yn broblem ddifrifol. Mae’n ymddangos i mi fod y cydweithiwr hwn hyd yn oed wedi rhoi adroddiad ar ba mor anodd yw hi i ddosrannu niferoedd mewn deng milfed dosbarth, ond efallai ddim.
Alexey, diolch yn fawr iawn am yr adroddiad! A diolch yn fawr iawn am ClickHouse! Mae gennyf gwestiwn am gynlluniau. A oes unrhyw gynlluniau ar gyfer nodwedd i ddiweddaru geiriaduron yn anghyflawn?
Hynny yw, ailgychwyn rhannol?
Ydy Ydy. Fel y gallu i osod maes MySQL yno, h.y. diweddaru ar ôl fel mai dim ond y data hwn sy'n cael ei lwytho os yw'r geiriadur yn fawr iawn.
Nodwedd ddiddorol iawn. A dwi'n meddwl bod rhyw berson wedi ei awgrymu yn ein sgwrs. Efallai ei fod hyd yn oed chi.
Dydw i ddim yn meddwl hynny.
Gwych, nawr mae'n troi allan bod dau gais. A gallwch chi ddechrau ei wneud yn araf. Ond rwyf am eich rhybuddio ar unwaith bod y nodwedd hon yn eithaf syml i'w gweithredu. Hynny yw, mewn theori, does ond angen i chi ysgrifennu rhif y fersiwn yn y tabl ac yna ysgrifennu: fersiwn yn llai na'r cyfryw ac o'r fath. Mae hyn yn golygu, yn fwyaf tebygol, y byddwn yn cynnig hyn i selogion. Ydych chi'n frwd?
Ie, ond, yn anffodus, nid yn C++.
A yw eich cydweithwyr yn gwybod sut i ysgrifennu yn C++?
Byddaf yn dod o hyd i rywun.
Gwych*.
* ychwanegwyd y nodwedd ddeufis ar ol yr adroddiad — datblygodd awdwr y cwestiwn ef ac anfonodd ei .
Diolch yn fawr!
Helo! Diolch am yr adroddiad! Soniasoch fod ClickHouse yn dda iawn am ddefnyddio'r holl adnoddau sydd ar gael iddo. A siaradodd y siaradwr wrth ymyl Luxoft am ei ateb ar gyfer Post Rwsia. Dywedodd eu bod yn hoff iawn o ClickHouse, ond ni wnaethant ei ddefnyddio yn lle eu prif gystadleuydd yn union oherwydd ei fod yn bwyta'r holl CPU. Ac ni allent ei blygio i mewn i'w pensaernïaeth, yn eu ZooKeeper gyda docwyr. A yw'n bosibl cyfyngu ar ClickHouse rywsut fel nad yw'n bwyta popeth sy'n dod ar gael iddo?
Ydy, mae'n bosibl ac yn hawdd iawn. Os ydych chi eisiau defnyddio llai o greiddiau, yna ysgrifennwch set max_threads = 1. A dyna ni, bydd yn gweithredu'r cais mewn un craidd. Ar ben hynny, gallwch chi nodi gwahanol leoliadau ar gyfer gwahanol ddefnyddwyr. Felly dim problem. A dywedwch wrth eich cydweithwyr o Luxoft nad yw'n dda na ddaethon nhw o hyd i'r gosodiad hwn yn y ddogfennaeth.
Alexei, helo! Hoffwn ofyn am y cwestiwn hwn. Nid dyma'r tro cyntaf i mi glywed bod llawer o bobl yn dechrau defnyddio ClickHouse fel storfa ar gyfer logiau. Yn yr adroddiad, dywedasoch i beidio â gwneud hyn, h.y. nid oes angen i chi storio llinynnau hir. Beth ydych chi'n ei feddwl amdano?
Yn gyntaf, nid yw boncyffion, fel rheol, yn llinynnau hir. Mae yna, wrth gwrs, eithriadau. Er enghraifft, mae rhywfaint o wasanaeth a ysgrifennwyd yn java yn taflu eithriad, mae wedi'i gofnodi. Ac yn y blaen mewn dolen ddiddiwedd, ac mae'r gofod ar y gyriant caled yn rhedeg allan. Mae'r ateb yn syml iawn. Os yw'r llinellau'n hir iawn, yna torrwch nhw. Beth mae hir yn ei olygu? Mae degau o kilobytes yn ddrwg*.
* yn y fersiynau diweddaraf o ClickHouse, mae “gronynnedd mynegai addasol” wedi'i alluogi, sy'n dileu'r broblem o storio rhesi hir ar y cyfan.
Ydy cilobeit yn normal?
Iawn.
Helo! Diolch am yr adroddiad! Gofynnais am hyn eisoes yn y sgwrs, ond nid wyf yn cofio a gefais ateb. A oes cynlluniau rhywsut i ehangu'r adran GYDA yn null CTE?
Ddim eto. Mae ein hadran WITH braidd yn wamal. Mae fel nodwedd fach i ni.
Rwy'n deall. Diolch!
Diolch am yr adroddiad! Diddorol iawn! Cwestiwn byd-eang. A oes unrhyw gynlluniau i addasu dileu data, efallai ar ffurf rhyw fath o fonion?
O reidrwydd. Dyma ein tasg gyntaf yn ein ciw. Rydyn ni nawr yn meddwl yn weithredol am sut i wneud popeth yn gywir. A dylech chi ddechrau pwyso'r bysellfwrdd *.
* Pwysodd y botymau ar y bysellfwrdd a gwneud popeth.
A fydd hyn rywsut yn effeithio ar berfformiad y system ai peidio? A fydd y gosodiad mor gyflym ag y mae nawr?
Efallai y bydd y dileadau eu hunain a'r diweddariadau eu hunain yn drwm iawn, ond ni fydd hyn yn effeithio ar berfformiad detholion na pherfformiad mewnosodiadau.
Ac un cwestiwn bach arall. Yn y cyflwyniad buoch yn sôn am allwedd gynradd. Yn unol â hynny, mae gennym rhaniad, sy'n fisol yn ddiofyn, yn gywir? A phan fyddwn yn gosod ystod dyddiad sy'n cyd-fynd â mis, yna dim ond y rhaniad hwn sy'n cael ei ddarllen, iawn?
Ydw.
Cwestiwn. Os na allwn ddewis unrhyw allwedd gynradd, yna a yw'n gywir ei wneud yn benodol yn ôl y maes “Dyddiad” fel bod llai o ad-drefnu'r data hwn yn y cefndir fel ei fod yn ffitio'n fwy trefnus? Os nad oes gennych chi ymholiadau amrediad ac ni allwch hyd yn oed ddewis unrhyw allwedd gynradd, a yw'n werth rhoi dyddiad yn yr allwedd gynradd?
Ydw.
Efallai ei bod yn gwneud synnwyr i roi maes yn y brif allwedd a fydd yn cywasgu'r data yn well os caiff ei ddidoli yn ôl y maes hwn. Er enghraifft, ID defnyddiwr. Defnyddiwr, er enghraifft, yn mynd i'r un safle. Yn yr achos hwn, rhowch yr id defnyddiwr ac amser. Ac yna bydd eich data yn cael ei gywasgu'n well. O ran y dyddiad, os nad oes gennych chi, a byth, ymholiadau ystod ar ddyddiadau, yna does dim rhaid i chi roi'r dyddiad yn yr allwedd gynradd.
OK diolch yn fawr iawn!
Ffynhonnell: hab.com