Ym mis Ebrill, ymgasglodd peirianwyr Avito ar gyfer cyfarfodydd ar-lein gyda phrif ddatblygwr ClickHouse Alexey Milovidov a Kirill Shvakov, datblygwr Golang o Integros. Buom yn trafod sut rydym yn defnyddio system rheoli cronfa ddata a pha anawsterau rydym yn dod ar eu traws.
Yn seiliedig ar y cyfarfod, rydym wedi llunio erthygl gydag atebion arbenigwyr i'n cwestiynau ni a'r gynulleidfa am gopïau wrth gefn, ail-galedu data, geiriaduron allanol, gyrrwr Golang a diweddaru fersiynau ClickHouse. Gall fod yn ddefnyddiol i ddatblygwyr sydd eisoes yn gweithio'n weithredol gyda'r Yandex DBMS ac sydd â diddordeb yn ei bresennol a'i ddyfodol. Yn ddiofyn, Alexey Milovidov sy'n ateb, oni bai ei fod wedi'i ysgrifennu'n wahanol.
Byddwch yn ofalus, mae llawer o destun o dan y toriad. Gobeithiwn y bydd y cynnwys gyda chwestiynau yn eich helpu i lywio.
Cynnwys
Os nad ydych chi eisiau darllen y testun, gallwch wylio'r recordiad o'r cynulliadau . Mae codau amser yn y sylw cyntaf o dan y fideo.
Mae ClickHouse yn cael ei ddiweddaru'n gyson, ond nid yw ein data. Beth i'w wneud amdano?
Mae ClickHouse yn cael ei ddiweddaru'n gyson, ac nid yw ein data, a gafodd ei optimeiddio'n derfynol wedi'i brosesu, yn cael ei ddiweddaru ac mae mewn copi wrth gefn.
Gadewch i ni ddweud bod gennym rywfaint o broblem a chollwyd y data. Fe benderfynon ni adfer, a daeth yn amlwg bod yr hen raniadau, sy'n cael eu storio ar y gweinyddwyr wrth gefn, yn wahanol iawn i'r fersiwn a ddefnyddir ar hyn o bryd o ClickHouse. Beth i'w wneud mewn sefyllfa o'r fath, ac a yw'n bosibl?
Mae sefyllfa lle gwnaethoch chi adfer data o gopi wrth gefn mewn hen fformat, ond nid yw'n cysylltu â'r fersiwn newydd, yn amhosibl. Rydym yn sicrhau bod y fformat data yn ClickHouse bob amser yn gydnaws yn ôl. Mae hyn yn llawer pwysicach na chydweddoldeb yn ôl o ran ymarferoldeb os yw ymddygiad rhyw ffwythiant nas defnyddir yn aml wedi newid. Dylai'r fersiwn newydd o ClickHouse bob amser allu darllen y data sy'n cael ei storio ar ddisg. Dyma'r gyfraith.
Beth yw'r arferion gorau cyfredol ar gyfer gwneud copïau wrth gefn o ddata gan ClickHouse?
Sut i wneud copïau wrth gefn, gan gymryd i ystyriaeth ein bod wedi optimeiddio gweithrediadau terfynol, cronfa ddata enfawr o terabytes, a data sy'n cael ei ddiweddaru, dyweder, am y tri diwrnod diwethaf, ac yna nad oes unrhyw weithdrefnau yn digwydd iddo?
Gallwn wneud ein datrysiad ein hunain ac ysgrifennu ar y bash: casglwch y copïau wrth gefn hyn yn y fath fodd. Efallai nad oes angen bagio dim, a chafodd y beic ei ddyfeisio ers talwm?
Gadewch i ni ddechrau gyda'r arferion gorau. Mae fy nghydweithwyr bob amser yn cynghori, mewn ymateb i gwestiynau am gopïau wrth gefn, i'w hatgoffa am y gwasanaeth Yandex.Cloud, lle mae'r broblem hon eisoes wedi'i datrys. Felly defnyddiwch hi os yn bosibl.
Nid oes ateb cyflawn ar gyfer copïau wrth gefn, gant y cant wedi'i ymgorffori yn ClickHouse. Mae rhai bylchau y gellir eu defnyddio. I gael datrysiad cyflawn, bydd yn rhaid i chi naill ai tincian ychydig â llaw, neu greu deunydd lapio ar ffurf sgriptiau.
Dechreuaf gyda'r atebion symlaf a gorffen gyda'r rhai mwyaf soffistigedig, yn dibynnu ar faint o ddata a maint y clwstwr. Po fwyaf yw'r clwstwr, y mwyaf cymhleth y daw'r datrysiad.
Os mai dim ond ychydig gigabeit y mae'r tabl gyda data yn ei feddiannu, gellir gwneud copi wrth gefn fel hyn:
- Cadw diffiniad tabl h.y. metadata - dangos creu tabl.
- Gwnewch dymp gan ddefnyddio'r cleient ClickHouse - dewiswch * o fwrdd i ffeilio. Yn ddiofyn byddwch yn derbyn ffeil mewn fformat TabSeparated. Os ydych chi am fod yn fwy effeithlon, gallwch chi ei wneud mewn fformat Brodorol.
Os yw swm y data yn fwy, yna bydd y copi wrth gefn yn cymryd mwy o amser a llawer o le. Gelwir hyn yn gopi wrth gefn rhesymegol; nid yw'n gysylltiedig â fformat data ClickHouse. Os ydyw, yna fel dewis olaf gallwch gymryd copi wrth gefn a'i uwchlwytho i MySQL i'w adfer.
Ar gyfer achosion mwy datblygedig, mae gan ClickHouse allu adeiledig i greu ciplun o raniadau yn y system ffeiliau leol. Mae'r nodwedd hon ar gael fel cais newid rhaniad rhewi tabl. Neu yn syml newid rhewi bwrdd - dyma gipolwg ar y bwrdd cyfan.
Bydd y ciplun yn cael ei greu yn gyson ar gyfer un bwrdd ar un darn, hynny yw, mae'n amhosibl creu ciplun cyson o'r clwstwr cyfan yn y modd hwn. Ond ar gyfer y rhan fwyaf o dasgau nid oes angen o'r fath, ac mae'n ddigon i weithredu cais ar bob darn a chael ciplun cyson. Mae'n cael ei greu ar ffurf dolenni caled ac felly nid yw'n cymryd lle ychwanegol. Nesaf, rydych chi'n copïo'r ciplun hwn i'r gweinydd wrth gefn neu i'r storfa rydych chi'n ei ddefnyddio ar gyfer copïau wrth gefn.
Mae adfer copi wrth gefn o'r fath yn eithaf hawdd. Yn gyntaf, creu tablau gan ddefnyddio diffiniadau tablau presennol. Nesaf, copïwch y cipluniau sydd wedi'u cadw o'r rhaniadau i Directory-Detached ar gyfer y tablau hyn a rhedeg yr ymholiad atodi pared. Mae'r datrysiad hwn yn eithaf addas ar gyfer y cyfeintiau mwyaf difrifol o ddata.
Weithiau mae angen rhywbeth hyd yn oed yn oerach - mewn achosion lle mae gennych chi ddegau neu hyd yn oed gannoedd o terabytes ar bob gweinydd a channoedd o weinyddion. Mae yna ateb yma a godais gan fy nghydweithwyr o Yandex.Metrica. Ni fyddwn yn ei argymell i bawb - darllenwch ef a phenderfynwch drosoch eich hun a yw'n addas ai peidio.
Yn gyntaf mae angen i chi greu sawl gweinydd gyda silffoedd disg mawr. Nesaf, ar y gweinyddwyr hyn, codwch sawl gweinydd ClickHouse a'u ffurfweddu fel eu bod yn gweithio fel replica arall ar gyfer yr un darnau. Ac yna defnyddiwch system ffeiliau neu ryw offeryn ar y gweinyddwyr hyn sy'n eich galluogi i greu cipluniau. Mae dau opsiwn yma. Yr opsiwn cyntaf yw cipluniau LVM, yr ail opsiwn yw ZFS ar Linux.
Ar ôl hynny, bob dydd mae angen i chi greu ciplun, bydd yn gorwedd ac yn cymryd rhywfaint o le. Yn naturiol, os bydd y data yn newid, bydd maint y gofod yn cynyddu dros amser. Gellir tynnu'r ciplun hwn ar unrhyw adeg ac adfer y data, datrysiad mor rhyfedd. Hefyd, mae angen i ni hefyd gyfyngu ar y copïau hyn yn y ffurfwedd fel nad ydyn nhw'n ceisio dod yn arweinwyr.
A fydd yn bosibl trefnu oedi rheoledig o atgynyrchiadau yn y siafftiau?
Eleni rydych chi'n bwriadu gwneud siafftiau yn ClickHouse. A fydd yn bosibl trefnu oedi rheoledig o atgynyrchiadau ynddynt? Hoffem ei ddefnyddio i amddiffyn ein hunain rhag senarios negyddol gyda newidiadau a newidiadau eraill.
A yw'n bosibl gwneud rhyw fath o rolio'n ôl ar gyfer alters? Er enghraifft, mewn siafft sy'n bodoli eisoes, cymerwch a dywedwch eich bod chi'n cymhwyso'r newidiadau tan y foment hon, ac o'r eiliad hon rydych chi'n rhoi'r gorau i gymhwyso'r newidiadau?
Pe bai gorchymyn yn dod i’n clwstwr a’i dorri, yna mae gennym replica amodol gydag oedi o awr, lle gallwn ddweud y gadewch i ni ei ddefnyddio ar hyn o bryd, ond ni fyddwn yn gwneud newidiadau iddo am y deng munud olaf?
Yn gyntaf, am yr oedi rheoledig o atgynyrchiadau. Cafwyd cais o’r fath gan ddefnyddwyr, ac fe wnaethom greu problem ar Github gyda’r cais: “Os oes angen hwn ar rywun, fel ei fod, rhowch galon.” Ni thraddododd neb, a chaewyd y mater. Fodd bynnag, gallwch chi eisoes gael y cyfle hwn trwy sefydlu ClickHouse. Gwir, dim ond yn dechrau o fersiwn 20.3.
Mae ClickHouse yn perfformio uno data yn gyson yn y cefndir. Pan fydd cyfuniad wedi'i gwblhau, caiff set benodol o ddarnau o ddata ei ddisodli gan ddarn mwy. Ar yr un pryd, mae darnau o ddata a oedd yno o'r blaen yn parhau i aros ar y ddisg am beth amser.
Yn gyntaf, maent yn parhau i gael eu storio cyn belled â bod yna ymholiadau dethol sy'n eu defnyddio, er mwyn darparu gweithrediad di-flocio. Mae'n hawdd darllen ymholiadau dethol o hen dalpiau.
Yn ail, mae yna hefyd drothwy amser - mae hen ddarnau o ddata yn gorwedd ar y ddisg am wyth munud. Gellir addasu'r wyth munud hyn a hyd yn oed eu troi'n un diwrnod. Bydd hyn yn costio gofod disg: yn dibynnu ar y llif data, mae'n ymddangos na fydd y data yn dyblu yn unig yn y diwrnod olaf, gallai ddod yn bum gwaith yn fwy. Ond os oes problem ddifrifol, gallwch atal y gweinydd ClickHouse a datrys popeth.
Nawr mae'r cwestiwn yn codi sut mae hyn yn amddiffyn rhag newidiadau. Mae'n werth edrych yn ddyfnach yma, oherwydd mewn fersiynau hŷn o ClickHouse, gweithiodd yr alter yn y fath fodd fel ei fod yn syml yn newid darnau yn uniongyrchol. Mae darn o ddata gyda rhai ffeiliau, ac rydym yn gwneud hynny, er enghraifft, newid colofn gollwng. Yna mae'r golofn hon yn cael ei thynnu'n gorfforol o bob talp.
Ond gan ddechrau gyda fersiwn 20.3, mae'r mecanwaith alter wedi'i newid yn llwyr, ac erbyn hyn mae darnau o ddata bob amser yn ddigyfnewid. Nid ydynt yn newid o gwbl - mae alters bellach yn gweithio yn yr un ffordd fwy neu lai â chyfuniadau. Yn lle amnewid darn yn y fan a'r lle, rydyn ni'n creu un newydd. Yn y talp newydd, mae ffeiliau nad ydynt wedi newid yn dod yn ddolenni caled, ac os byddwn yn dileu colofn, yn syml, bydd ar goll yn y darn newydd. Bydd yr hen ddarn yn cael ei ddileu yn ddiofyn ar ôl wyth munud, ac yma gallwch chi newid y gosodiadau a grybwyllir uchod.
Mae'r un peth yn wir am newidiadau fel treigladau. Pan fyddwch chi'n gwneud newid dileu neu newid diweddariad, nid yw'n newid y darn, ond yn creu un newydd. Ac yna yn dileu'r hen un.
Beth os yw strwythur y bwrdd wedi newid?
Sut i adfer copi wrth gefn a wnaed gyda'r hen gynllun? Ac mae'r ail gwestiwn yn ymwneud â'r achos gyda chipluniau ac offer system ffeiliau. A yw Btrfs yn dda yma yn lle ZFS ar Linux LVM?
Os gwnewch chi hynny atodi pared rhaniadau gyda strwythur gwahanol, yna bydd ClickHouse yn dweud wrthych nad yw hyn yn bosibl. Dyma'r ateb. Y cyntaf yw creu tabl dros dro o'r math MergeTree gyda'r hen strwythur, atodi data yno gan ddefnyddio atodiad, a gwneud ymholiad alter. Yna gallwch naill ai gopïo neu drosglwyddo'r data hwn ac atodi eto, neu ddefnyddio cais newid rhaniad symud tabl.
Yn awr yr ail gwestiwn yw a ellir defnyddio Btrfs. I ddechrau, os oes gennych LVM, yna mae cipluniau LVM yn ddigon, a gall y system ffeiliau fod yn ext4, does dim ots. Gyda Btrts, mae popeth yn dibynnu ar eich profiad o'i ddefnyddio. Mae hon yn system ffeiliau aeddfed, ond mae rhai amheuon o hyd ynghylch sut y bydd popeth yn gweithio'n ymarferol mewn senario benodol. Ni fyddwn yn argymell defnyddio hwn oni bai bod gennych Btrfs yn cynhyrchu.
Beth yw'r arferion gorau ar hyn o bryd o ran ailgasglu data?
Mae mater ailgodi yn gymhleth ac amlochrog. Mae yna sawl ateb posib yma. Gallwch chi fynd o un ochr a dweud hyn - nid oes gan ClickHouse nodwedd ail-galdio adeiledig. Ond rwy'n ofni na fydd yr ateb hwn yn gweddu i unrhyw un. Felly, gallwch fynd o'r ochr arall a dweud bod gan ClickHouse lawer o ffyrdd i ail-galedu data.
Os yw'r clwstwr yn rhedeg allan o le neu os na all drin y llwyth, rydych chi'n ychwanegu gweinyddwyr newydd. Ond mae'r gweinyddwyr hyn yn wag yn ddiofyn, nid oes data arnynt, nid oes llwyth. Mae angen i chi aildrefnu'r data fel ei fod yn lledaenu'n gyfartal ar draws y clwstwr newydd, mwy.
Y ffordd gyntaf y gellir gwneud hyn yw copïo rhan o'r rhaniadau i weinyddion newydd gan ddefnyddio cais newid bwrdd nôl rhaniad. Er enghraifft, roedd gennych raniadau fesul mis, ac rydych chi'n cymryd mis cyntaf 2017 ac yn ei gopïo i weinydd newydd, yna copïwch y trydydd mis i ryw weinydd newydd arall. Ac rydych chi'n gwneud hyn nes iddo ddod yn gyfartal fwy neu lai.
Dim ond ar gyfer y rhaniadau hynny nad ydynt yn newid wrth recordio y gellir trosglwyddo. Ar gyfer rhaniadau ffres, bydd yn rhaid i gofnodi fod yn anabl, oherwydd nid yw eu trosglwyddiad yn atomig. Fel arall, byddwch yn cael dyblygiadau neu fylchau yn y data. Fodd bynnag, mae'r dull hwn yn ymarferol ac yn gweithio'n eithaf effeithiol. Mae rhaniadau cywasgedig parod yn cael eu trosglwyddo dros y rhwydwaith, hynny yw, nid yw'r data'n cael ei gywasgu na'i ail-amgodio.
Mae un anfantais i’r dull hwn, ac mae’n dibynnu ar y cynllun rhwygo, p’un a wnaethoch addo i’r cynllun darnio hwn, pa allwedd darnio oedd gennych. Yn eich enghraifft ar gyfer yr achos gyda metrigau, yr allwedd darnio yw hash y llwybr. Pan fyddwch chi'n dewis tabl Wedi'i Ddosbarthu, mae'n mynd i bob darn yn y clwstwr ar unwaith ac yn cymryd data oddi yno.
Mae hyn yn golygu nad oes ots gennych chi pa ddata a ddaeth i ben ar ba ddarn bach. Y prif beth yw bod data ar hyd un llwybr yn dod i ben ar un darn, ond nid yw pa un yn bwysig. Yn yr achos hwn, mae trosglwyddo rhaniadau parod yn berffaith, oherwydd gydag ymholiadau dethol byddwch hefyd yn derbyn data cyflawn - boed cyn ailseilio neu ar ôl, nid oes ots am y cynllun mewn gwirionedd.
Ond mae yna achosion sy'n fwy cymhleth. Os ar lefel rhesymeg y cais rydych chi'n dibynnu ar gynllun sharding arbennig, bod y cleient hwn wedi'i leoli ar ddarn o'r fath ac o'r fath, a gellir anfon y cais yn uniongyrchol yno, ac nid i'r tabl Dosbarthu. Neu rydych chi'n defnyddio fersiwn eithaf diweddar o ClickHouse ac wedi galluogi'r gosodiad optimeiddio sgip darnau heb eu defnyddio. Yn yr achos hwn, yn ystod yr ymholiad dethol, bydd y mynegiant yn yr adran lle yn cael ei ddadansoddi a bydd yn cael ei gyfrifo pa ddarnau y mae angen eu defnyddio yn ôl y cynllun sharding. Mae hyn yn gweithio ar yr amod bod y data'n cael ei rannu'n union yn unol â'r cynllun rhannu hwn. Os gwnaethoch eu haildrefnu â llaw, efallai y bydd yr ohebiaeth yn newid.
Felly dyma ddull rhif un. Ac rwy'n aros am eich ateb, p'un a yw'r dull yn addas, neu gadewch inni symud ymlaen.
Vladimir Kolobaev, gweinyddwr system arweiniol yn Avito: Alexey, nid yw'r dull a grybwyllwyd gennych yn gweithio'n dda iawn pan fydd angen i chi ledaenu'r llwyth, gan gynnwys darllen. Gallwn gymryd rhaniad sy'n fisol a gall fynd â'r mis blaenorol i nod arall, ond pan ddaw cais am y data hwn, byddwn yn ei lwytho yn unig. Ond hoffem lwytho'r clwstwr cyfan, oherwydd fel arall, am beth amser bydd y llwyth darllen cyfan yn cael ei brosesu gan ddau ddarn.
Alexey Milovidov: Mae'r ateb yma yn rhyfedd - ydy, mae'n ddrwg, ond efallai y bydd yn gweithio. Egluraf yn union sut. Mae'n werth edrych ar y senario llwyth sy'n dod y tu ôl i'ch data. Os mai data monitro yw hwn, yna mae bron yn sicr y gallwn ddweud bod mwyafrif helaeth y ceisiadau am ddata ffres.
Rydych chi wedi gosod gweinyddwyr newydd, wedi mudo hen raniad, ond hefyd wedi newid sut mae data ffres yn cael ei gofnodi. A bydd data ffres yn cael ei wasgaru ledled y clwstwr. Felly, ar ôl pum munud yn unig, bydd ceisiadau am y pum munud olaf yn llwytho'r clwstwr yn gyfartal; ar ôl diwrnod, bydd ceisiadau am XNUMX awr yn llwytho'r clwstwr yn gyfartal. A bydd ceisiadau ar gyfer y mis blaenorol, yn anffodus, yn mynd i ran o'r gweinyddwyr clwstwr yn unig.
Ond yn aml ni fydd gennych geisiadau penodol ar gyfer Chwefror 2019. Yn fwyaf tebygol, os bydd ceisiadau'n mynd i mewn i 2019, yna byddant ar gyfer 2019 cyfan - am gyfnod mawr o amser, ac nid ar gyfer rhai ystod fach. A bydd ceisiadau o'r fath hefyd yn gallu llwytho'r clwstwr yn gyfartal. Ond yn gyffredinol, mae eich sylw’n gwbl gywir mai ateb ad hoc yw hwn nad yw’n lledaenu’r data’n gwbl gyfartal.
Mae gennyf ychydig mwy o bwyntiau i ateb y cwestiwn. Mae un ohonynt yn ymwneud â sut i ddylunio cynllun darnio yn y lle cyntaf fel y byddai ail-rannu yn achosi llai o boen. Nid yw hyn bob amser yn bosibl.
Er enghraifft, mae gennych ddata monitro. Mae data monitro yn tyfu am dri rheswm. Y cyntaf yw cronni data hanesyddol. Yr ail yw twf traffig. A'r trydydd yw cynnydd yn nifer y pethau sy'n destun monitro. Mae yna ficrowasanaethau a metrigau newydd y mae angen eu harbed.
Mae'n bosibl bod y cynnydd mwyaf o'r rhain yn gysylltiedig â'r trydydd rheswm - y cynnydd yn y defnydd o fonitro. Ac yn yr achos hwn, mae'n werth edrych ar natur y llwyth, beth yw'r prif ymholiadau dethol. Mae'n debyg y bydd ymholiadau dethol sylfaenol yn seiliedig ar ryw is-set o fetrigau.
Er enghraifft, defnydd CPU ar rai gweinyddwyr gan rai gwasanaeth. Mae'n ymddangos bod yna is-set benodol o allweddi y byddwch chi'n cael y data hwn trwyddynt. Ac mae'r cais ei hun am y data hwn yn fwyaf tebygol yn eithaf syml ac yn cael ei gwblhau mewn degau o filieiliadau. Defnyddir ar gyfer monitro gwasanaethau a dangosfyrddau. Gobeithio fy mod yn deall hyn yn gywir.
Vladimir Kolobaev: Y ffaith yw ein bod yn aml yn apelio at ddata hanesyddol, gan ein bod yn cymharu'r sefyllfa bresennol â'r un hanesyddol mewn amser real. Ac mae'n bwysig i ni gael mynediad cyflym i lawer iawn o ddata, ac mae ClickHouse yn gwneud gwaith rhagorol gyda hyn.
Rydych yn llygad eich lle, rydym yn profi'r rhan fwyaf o'r ceisiadau a ddarllenwyd yn ystod y diwrnod olaf, fel unrhyw system fonitro. Ond ar yr un pryd, mae'r llwyth ar ddata hanesyddol hefyd yn eithaf mawr. Yn y bôn mae'n dod o system rybuddio sy'n mynd o gwmpas bob tri deg eiliad ac yn dweud wrth ClickHouse: “Rhowch y data i mi am y chwe wythnos diwethaf. Nawr adeiladwch ryw fath o gyfartaledd symudol oddi wrthynt, a gadewch i ni gymharu'r gwerth presennol â'r un hanesyddol.”
Hoffwn ddweud bod gennym ni, ar gyfer ceisiadau mor ddiweddar iawn, dabl bach arall lle rydyn ni'n storio dim ond dau ddiwrnod o ddata, ac mae'r prif geisiadau yn hedfan i mewn iddo. Dim ond ymholiadau hanesyddol mawr yr ydym yn eu hanfon at y bwrdd mawr wedi'i dorri.
Alexey Milovidov: Yn anffodus, mae'n troi allan i fod yn berthnasol iawn ar gyfer eich senario, ond byddaf yn dweud wrthych ddisgrifiad o ddau gynllun darnio gwael a chymhleth nad oes angen eu defnyddio, ond sy'n cael eu defnyddio yng ngwasanaeth fy ffrindiau.
Mae yna brif glwstwr gyda digwyddiadau Yandex.Metrica. Digwyddiadau yw golygfeydd tudalennau, cliciau a throsiadau. Mae'r rhan fwyaf o geisiadau yn mynd i wefan benodol. Rydych chi'n agor gwasanaeth Yandex.Metrica, mae gennych chi wefan - avito.ru, ewch i'r adroddiad, a gwneir cais am eich gwefan.
Ond mae yna geisiadau eraill - dadansoddol a byd-eang - sy'n cael eu gwneud gan ddadansoddwyr mewnol. Rhag ofn, nodaf fod dadansoddwyr mewnol yn gwneud ceisiadau am wasanaethau Yandex yn unig. Ond serch hynny, mae hyd yn oed gwasanaethau Yandex yn meddiannu cyfran sylweddol o'r holl ddata. Ceisiadau yw'r rhain nid am gownteri penodol, ond am hidlo ehangach.
Sut i drefnu data yn y fath fodd fel bod popeth yn gweithio'n effeithlon ar gyfer un cownter, ac ymholiadau byd-eang hefyd? Anhawster arall yw bod nifer y ceisiadau yn ClickHouse ar gyfer y clwstwr Metrics yn filoedd yr eiliad. Ar yr un pryd, ni all un gweinydd ClickHouse drin ceisiadau nad ydynt yn ddibwys, er enghraifft, sawl mil yr eiliad.
Maint y clwstwr yw chwe chant o weinyddion rhywbeth. Os ydych chi'n tynnu tabl wedi'i ddosbarthu dros y clwstwr hwn ac yn anfon miloedd o geisiadau yno, bydd yn waeth byth na'u hanfon at un gweinydd. Ar y llaw arall, mae'r opsiwn bod y data'n cael ei wasgaru'n gyfartal, ac rydyn ni'n mynd i ofyn amdano gan bob gweinydd, yn cael ei ddiystyru ar unwaith.
Mae yna opsiwn sy'n gwbl groes i'w gilydd. Dychmygwch os ydym yn rhannu'r data ar draws safleoedd, a bod cais am un safle yn mynd i un darn. Nawr bydd y clwstwr yn gallu delio â deng mil o geisiadau yr eiliad, ond ar un darn bydd unrhyw un cais yn gweithio'n rhy araf. Ni fydd yn graddio mwyach o ran trwybwn. Yn enwedig os mai dyma'r wefan avito.ru. Ni ddatgelaf y gyfrinach os dywedaf mai Avito yw un o'r safleoedd yr ymwelir â hwy fwyaf yn RuNet. A gwallgofrwydd fyddai ei brosesu ar un darn.
Felly, mae'r cynllun sharding wedi'i gynllunio mewn ffordd fwy cyfrwys. Rhennir y clwstwr cyfan yn nifer o glystyrau, yr ydym yn eu galw'n haenau. Mae pob clwstwr yn cynnwys o ddwsin i sawl dwsin o ddarnau. Mae tri deg naw o glystyrau o'r fath i gyd.
Sut mae hyn i gyd yn graddio? Nid yw nifer y clystyrau yn newid - fel yr oedd tri deg naw ychydig flynyddoedd yn ôl, mae'n parhau felly. Ond o fewn pob un ohonynt, rydym yn cynyddu'n raddol nifer y darnau darnau wrth i ni gronni data. Ac mae'r cynllun darnio yn ei gyfanrwydd fel hyn: mae'r clystyrau hyn wedi'u rhannu'n wefannau, ac er mwyn deall pa wefan sydd ar ba glwstwr, defnyddir metabase ar wahân yn MySQL. Un safle - ar un clwstwr. Ac y tu mewn iddo, mae hollti yn digwydd yn ôl IDau ymwelwyr.
Wrth gofnodi, rydym yn eu rhannu â gweddill rhaniad yr ID ymwelydd. Ond wrth ychwanegu darn newydd, mae’r cynllun rhwygo’n newid; rydym yn parhau i hollti, ond gyda gweddill y rhaniad gan rif arall. Mae hyn yn golygu bod un ymwelydd eisoes wedi'i leoli ar sawl gweinydd, ac ni allwch ddibynnu ar hyn. Gwneir hyn yn unig i sicrhau bod y data'n cael ei gywasgu'n well. Ac wrth wneud ceisiadau, rydyn ni'n mynd i'r tabl Distributed, sy'n edrych ar y clwstwr ac yn cyrchu dwsinau o weinyddion. Mae hwn yn gynllun mor wirion.
Ond bydd fy stori yn anghyflawn os na ddywedaf inni gefnu ar y cynllun hwn. Yn y cynllun newydd, fe wnaethom newid popeth a chopïo'r holl ddata gan ddefnyddio clickhouse-copier.
Yn y cynllun newydd, mae pob safle wedi'i rannu'n ddau gategori - mawr a bach. Nid wyf yn gwybod sut y dewiswyd y trothwy, ond y canlyniad oedd bod safleoedd mawr yn cael eu cofnodi ar un clwstwr, lle mae 120 darn gyda thri atgynhyrchiad yr un - hynny yw, 360 o weinyddion. Ac mae'r cynllun darnio yn golygu bod unrhyw gais yn mynd i bob darn ar unwaith. Os ydych chi nawr yn agor unrhyw dudalen adroddiad ar gyfer avito.ru yn Yandex.Metrica, bydd y cais yn mynd at 120 o weinyddion. Ychydig o safleoedd mawr sydd yn RuNet. Ac nid yw'r ceisiadau yn fil yr eiliad, ond hyd yn oed yn llai na chant. Mae hyn i gyd yn cael ei gnoi'n dawel gan y bwrdd Distributed, y mae pob un ohonynt yn ei brosesu gyda 120 o weinyddion.
Ac mae'r ail glwstwr ar gyfer safleoedd bach. Dyma gynllun darnio yn seiliedig ar ID y safle, ac mae pob cais yn mynd i un darn yn union.
Mae gan ClickHouse wasanaeth copïwr clic. Allwch chi ddweud wrthym amdani?
Fe ddywedaf ar unwaith fod yr ateb hwn yn fwy beichus ac ychydig yn llai cynhyrchiol. Y fantais yw ei fod yn taenu'r data yn gyfan gwbl yn ôl y patrwm rydych chi'n ei nodi. Ond anfantais y cyfleustodau yw nad yw'n gwneud yn anodd o gwbl. Mae'n copïo data o un sgema clwstwr i sgema clwstwr arall.
Mae hyn yn golygu bod yn rhaid i chi gael dau glwstwr er mwyn iddo weithio. Gellir eu lleoli ar yr un gweinyddwyr, ond, serch hynny, ni fydd y data yn cael ei symud yn gynyddrannol, ond bydd yn cael ei gopïo.
Er enghraifft, roedd pedwar gweinydd, erbyn hyn mae wyth. Rydych chi'n creu tabl Dosbarthedig newydd ar bob gweinydd, tablau lleol newydd ac yn lansio clickhouse-copier, gan nodi ynddo'r cynllun gwaith y dylai ei ddarllen oddi yno, derbyn y cynllun rhannu newydd a throsglwyddo'r data yno. Ac ar hen weinyddion bydd angen un a hanner gwaith yn fwy o le arnoch nag sydd ar hyn o bryd, oherwydd rhaid i'r hen ddata aros arnynt, a bydd hanner yr un hen ddata yn cyrraedd ar eu pennau. Os oeddech chi'n meddwl ymlaen llaw bod angen ail galedu'r data a bod lle, yna mae'r dull hwn yn addas.
Sut mae clickhouse-copier yn gweithio y tu mewn? Mae'n torri'r holl waith yn set o dasgau ar gyfer prosesu un rhaniad o un bwrdd ar un darn. Gellir cyflawni'r holl dasgau hyn ochr yn ochr, a gellir rhedeg clickhouse-copier ar wahanol beiriannau mewn sawl achos, ond nid yw'r hyn y mae'n ei wneud ar gyfer un rhaniad yn ddim mwy na dewis mewnosod. Mae'r data'n cael ei ddarllen, ei ddatgywasgu, ei ailrannu, yna ei gywasgu eto, ei ysgrifennu yn rhywle, a'i ail-ddidoli. Mae hwn yn benderfyniad anoddach.
Roedd gennych beth peilot o'r enw resharding. Beth gyda hi?
Yn ôl yn 2017, roedd gennych chi beth peilot o'r enw ail-archio. Mae yna opsiwn hyd yn oed yn ClickHouse. Yn ôl a ddeallaf, ni chymerodd i ffwrdd. A allwch ddweud wrthyf pam y digwyddodd hyn? Ymddengys ei fod yn berthnasol iawn.
Y broblem gyfan yw, os oes angen ail-galedu data yn ei le, mae angen cydamseru cymhleth iawn er mwyn gwneud hyn yn atomig. Pan ddechreuon ni edrych ar sut mae'r cydamseru hwn yn gweithio, daeth yn amlwg bod problemau sylfaenol. Ac mae'r problemau sylfaenol hyn nid yn unig yn ddamcaniaethol, ond ar unwaith dechreuodd ddangos eu hunain yn ymarferol ar ffurf rhywbeth y gellir ei esbonio'n syml iawn - nid oes dim yn gweithio.
A yw'n bosibl uno pob darn o ddata gyda'i gilydd cyn ei symud i ddisgiau araf?
Cwestiwn am TTL gyda'r opsiwn symud i ddisg araf yng nghyd-destun uno. A oes ffordd, heblaw trwy cron, i uno'r holl rannau yn un cyn eu symud i ddisgiau araf?
Yr ateb i'r cwestiwn yw ei bod hi'n bosibl rhywsut gludo'r holl ddarnau yn un yn awtomatig cyn eu trosglwyddo - na. Dydw i ddim yn meddwl bod hyn yn angenrheidiol. Nid oes rhaid i chi uno'r holl rannau yn un, ond yn syml cyfrif ar y ffaith y byddant yn cael eu trosglwyddo i ddisgiau araf yn awtomatig.
Mae gennym ddau faen prawf ar gyfer rheolau trosglwyddo. Mae'r cyntaf fel y mae wedi'i lenwi. Os oes gan yr haen storio gyfredol lai na chanran benodol o le am ddim, rydyn ni'n dewis un darn ac yn ei symud i storfa arafach. Neu yn hytrach, nid yn arafach, ond yr un nesaf - wrth i chi ffurfweddu.
Yr ail faen prawf yw maint. Mae'n ymwneud â symud darnau mawr. Gallwch chi addasu'r trothwy yn ôl y gofod rhydd ar y ddisg gyflym, a bydd y data'n cael ei drosglwyddo'n awtomatig.
Sut i fudo i fersiynau newydd o ClickHouse os nad oes unrhyw ffordd i wirio cydnawsedd ymlaen llaw?
Mae'r pwnc hwn yn cael ei drafod yn rheolaidd gan gymryd i ystyriaeth fersiynau gwahanol, ac o hyd. Pa mor ddiogel yw hi i uwchraddio o fersiwn 19.11 i 19.16 ac, er enghraifft, o 19.16 i 20.3. Beth yw'r ffordd orau o symud i fersiynau newydd heb allu gwirio cydnawsedd yn y blwch tywod ymlaen llaw?
Mae yna sawl rheol “aur” yma. Yn gyntaf - . Mae'n fawr, ond mae paragraffau ar wahân am newidiadau yn ôl anghydnaws. Peidiwch â thrin y pwyntiau hyn fel baner goch. Mae'r rhain fel arfer yn fân anghydnawsedd sy'n cynnwys rhywfaint o ymarferoldeb ymyl y mae'n debygol iawn na fyddwch chi'n ei ddefnyddio.
Yn ail, os nad oes unrhyw ffordd i wirio cydnawsedd yn y blwch tywod, a'ch bod am ddiweddaru ar unwaith wrth gynhyrchu, yr argymhelliad yw nad oes angen i chi wneud hyn. Yn gyntaf crëwch flwch tywod a phrofwch. Os nad oes amgylchedd prawf, yna mae'n debyg nad oes gennych chi gwmni mawr iawn, sy'n golygu y gallwch chi gopïo rhywfaint o'r data i'ch gliniadur a sicrhau bod popeth yn gweithio'n iawn arno. Gallwch hyd yn oed godi sawl atgynhyrchiad yn lleol ar eich peiriant. Neu gallwch godi fersiwn newydd yn rhywle gerllaw a llwytho rhywfaint o'r data yno - hynny yw, creu amgylchedd prawf byrfyfyr.
Rheol arall yw peidio â diweddaru am wythnos ar ôl rhyddhau'r fersiwn oherwydd dal bygiau wrth gynhyrchu ac atebion cyflym dilynol. Gadewch i ni gyfrifo rhifo fersiynau ClickHouse er mwyn peidio â drysu.
Mae fersiwn 20.3.4. Mae'r rhif 20 yn nodi blwyddyn y gweithgynhyrchu - 2020. O safbwynt yr hyn sydd y tu mewn, nid yw hyn o bwys, felly ni fyddwn yn talu sylw iddo. Nesaf - 20.3. Rydyn ni'n cynyddu'r ail rif - 3 yn yr achos hwn - bob tro rydyn ni'n rhyddhau datganiad gyda rhywfaint o ymarferoldeb newydd. Os ydym am ychwanegu rhywfaint o nodwedd at ClickHouse, rhaid inni gynyddu'r nifer hwn. Hynny yw, yn fersiwn 20.4 bydd ClickHouse yn gweithio hyd yn oed yn well. Y trydydd digid yw 20.3.4. Yma 4 yw nifer y datganiadau patsh lle na wnaethom ychwanegu nodweddion newydd, ond trwsio rhai chwilod. Ac mae 4 yn golygu ein bod ni wedi gwneud hynny bedair gwaith.
Peidiwch â meddwl bod hyn yn rhywbeth ofnadwy. Fel arfer gall y defnyddiwr osod y fersiwn ddiweddaraf a bydd yn gweithio heb unrhyw broblemau gyda uptime y flwyddyn. Ond dychmygwch, mewn rhyw swyddogaeth ar gyfer prosesu mapiau didau, a ychwanegwyd gan ein cyd-filwyr Tsieineaidd, fod y gweinydd yn chwalu wrth basio dadleuon anghywir. Mae gennym gyfrifoldeb i drwsio hyn. Byddwn yn rhyddhau fersiwn clwt newydd a bydd ClickHouse yn dod yn fwy sefydlog.
Os oes gennych ClickHouse yn rhedeg wrth gynhyrchu, a bod fersiwn newydd o ClickHouse yn dod allan gyda nodweddion ychwanegol - er enghraifft, 20.4.1 yw'r un cyntaf un, peidiwch â rhuthro i'w roi i mewn i gynhyrchu ar y diwrnod cyntaf un. Pam fod ei angen hyd yn oed? Os nad ydych chi eisoes yn defnyddio ClickHouse, yna gallwch chi ei osod, ac yn fwyaf tebygol bydd popeth yn iawn. Ond os yw ClickHouse eisoes yn gweithio'n sefydlog, yna cadwch lygad ar glytiau a diweddariadau i weld pa broblemau rydyn ni'n eu trwsio.
Kirill Shvakov: Hoffwn ychwanegu ychydig am amgylcheddau prawf. Mae pawb yn ofni amgylcheddau prawf yn fawr ac am ryw reswm maen nhw'n credu, os oes gennych chi glwstwr ClickHouse mawr iawn, yna ni ddylai'r amgylchedd prawf fod yn llai neu o leiaf ddeg gwaith yn llai. Nid felly y mae o gwbl.
Gallaf ddweud wrthych o fy enghraifft fy hun. Mae gen i brosiect, ac mae ClickHouse. Ar ei gyfer ef yn unig y mae ein hamgylchedd prawf - mae hwn yn beiriant rhithwir bach yn Hetzner am ugain ewro, lle mae popeth yn cael ei ddefnyddio. I wneud hyn, mae gennym awtomeiddio llawn yn Ansible, ac felly, mewn egwyddor, nid yw'n gwneud unrhyw wahaniaeth ble i fynd - i weinyddion caledwedd neu dim ond defnyddio mewn peiriannau rhithwir.
Beth ellir ei wneud? Byddai'n braf darparu enghraifft yn nogfennaeth ClickHouse ar sut i ddefnyddio clwstwr bach yn eich cartref eich hun - yn Docker, yn LXC, efallai creu llyfr chwarae Ansible, oherwydd mae gan wahanol bobl wahanol leoliadau. Bydd hyn yn symleiddio llawer. Pan fyddwch chi'n cymryd ac yn defnyddio clwstwr mewn pum munud, mae'n llawer haws ceisio darganfod rhywbeth. Mae hyn yn llawer mwy cyfleus, oherwydd nid yw rholio i mewn i fersiwn gynhyrchu nad ydych wedi'i brofi yn ffordd i unman. Weithiau mae'n gweithio ac weithiau nid yw'n gweithio. Ac felly, drwg yw gobeithio am lwyddiant.
Maxim Kotyakov, uwch beiriannydd cefndir Avito: Ychwanegaf ychydig am amgylcheddau prawf o gyfres o broblemau a wynebir gan gwmnïau mawr. Mae gennym glwstwr derbyn ClickHouse cyflawn; o ran cynlluniau data a gosodiadau, mae'n union gopi o'r hyn sy'n cael ei gynhyrchu. Mae'r clwstwr hwn yn cael ei ddefnyddio mewn cynwysyddion gweddol ddirywiedig gyda lleiafswm o adnoddau. Rydyn ni'n ysgrifennu canran benodol o'r data cynhyrchu yno, yn ffodus mae'n bosibl ailadrodd y nant yn Kafka. Mae popeth yno wedi'i gydamseru a'i raddfa - o ran cynhwysedd a llif, ac, mewn theori, a phopeth arall yn gyfartal, dylai ymddwyn fel cynhyrchu o ran metrigau. Mae popeth a allai fod yn ffrwydrol yn cael ei rolio i'r stondin hon yn gyntaf a'i adael yno am sawl diwrnod nes ei fod yn barod. Ond yn naturiol, mae'r ateb hwn yn ddrud, yn anodd ac mae ganddo gostau cynnal di-sero.
Alexey Milovidov: Fe ddywedaf wrthych sut beth yw amgylchedd prawf ein ffrindiau o Yandex.Metrica. Roedd gan un clwstwr 600 o weinyddion od, roedd gan un arall 360, ac mae traean a sawl clwstwr. Yr amgylchedd prawf ar gyfer un ohonynt yn syml yw dau ddarn gyda dau atgynhyrchiad ym mhob un. Pam dau ddarn? Fel nad ydych chi ar eich pen eich hun. A dylai fod copïau hefyd. Dim ond isafswm penodol y gallwch ei fforddio.
Mae'r amgylchedd prawf hwn yn caniatáu ichi wirio a yw'ch ymholiadau'n gweithio ac a oes unrhyw beth mawr wedi torri. Ond yn aml mae problemau'n codi o natur hollol wahanol, pan fydd popeth yn gweithio, ond mae rhai newidiadau bach yn y llwyth.
Gadewch imi roi enghraifft ichi. Fe benderfynon ni osod fersiwn newydd o ClickHouse. Mae wedi'i bostio ar amgylchedd prawf, mae profion awtomataidd wedi'u cwblhau yn Yandex.Metrica ei hun, sy'n cymharu data ar yr hen fersiwn a'r un newydd, gan redeg y biblinell gyfan. Ac wrth gwrs, profion gwyrdd o'n CI. Fel arall, ni fyddem hyd yn oed wedi cynnig y fersiwn hon.
Mae popeth yn iawn. Rydym yn dechrau symud i mewn i gynhyrchu. Rwy'n derbyn neges bod y llwyth ar y graffiau wedi cynyddu sawl gwaith. Rydym yn treiglo'r fersiwn yn ôl. Edrychaf ar y graff a gweld: mewn gwirionedd cynyddodd y llwyth sawl gwaith yn ystod y broses gyflwyno, a gostyngodd yn ôl pan wnaethant gyflwyno. Yna dechreuon ni rolio'r fersiwn yn ôl. A chynyddodd y llwyth yn yr un modd a syrthiodd yn ôl yn yr un ffordd. Felly'r casgliad yw hyn: mae'r llwyth wedi cynyddu oherwydd y gosodiad, dim syndod.
Yna roedd yn anodd argyhoeddi cydweithwyr i osod y fersiwn newydd. Rwy'n dweud: “Mae'n iawn, rholio allan. Croeswch eich bysedd, bydd popeth yn gweithio. Nawr mae'r llwyth ar y graffiau wedi cynyddu, ond mae popeth yn iawn. Arhoswch yno." Yn gyffredinol, gwnaethom hyn, a dyna ni - rhyddhawyd y fersiwn i'w gynhyrchu. Ond mae problemau tebyg yn codi bron gyda phob cynllun.
Kill ymholiad i fod i ladd ymholiadau, ond nid yw'n. Pam?
Daeth defnyddiwr, rhyw fath o ddadansoddwr, ataf a chreu cais a roddodd fy nghlwstwr ClickHouse. Rhywfaint neu glwstwr cyfan, yn dibynnu ar ba atgynhyrchiad neu ddarn o ddarn yr aeth y cais iddo. Gwelaf fod yr holl adnoddau CPU ar y gweinydd hwn mewn silff, mae popeth yn goch. Ar yr un pryd, mae ClickHouse ei hun yn ymateb i geisiadau. Ac rwy'n ysgrifennu: “Dangoswch i mi, rhestr prosesau, pa gais a greodd y gwallgofrwydd hwn.”
Rwy'n dod o hyd i'r cais hwn ac yn ysgrifennu lladd iddo. A gwelaf nad oes dim yn digwydd. Mae fy gweinydd mewn silff, mae ClickHouse wedyn yn rhoi rhai gorchmynion i mi, yn dangos bod y gweinydd yn fyw, ac mae popeth yn wych. Ond mae gen i ddiraddiad ym mhob cais defnyddiwr, mae diraddio yn dechrau gyda chofnodion yn ClickHouse, ac nid yw fy ymholiad lladd yn gweithio. Pam? Roeddwn i'n meddwl bod ymholiad lladd i fod i ladd ymholiadau, ond nid yw'n gwneud hynny.
Nawr bydd ateb braidd yn rhyfedd. Y pwynt yw nad yw ymholiad lladd yn lladd ymholiadau.
Mae Kill query yn gwirio blwch bach o'r enw “Rydw i eisiau i'r ymholiad hwn gael ei ladd.” Ac mae'r cais ei hun yn edrych ar y faner hon wrth brosesu pob bloc. Os caiff ei osod, mae'r cais yn peidio â gweithio. Mae'n ymddangos nad oes neb yn lladd y cais, mae'n rhaid iddo ef ei hun wirio popeth a stopio. A dylai hyn weithio ym mhob achos lle mae'r cais mewn cyflwr blociau prosesu data. Bydd yn prosesu'r bloc nesaf o ddata, yn gwirio'r faner, ac yn stopio.
Nid yw hyn yn gweithio mewn achosion lle mae'r cais yn cael ei rwystro ar rai llawdriniaeth. Yn wir, yn fwyaf tebygol nid dyma'ch achos chi, oherwydd, yn ôl chi, mae'n defnyddio tunnell o adnoddau gweinydd. Mae'n bosibl nad yw hyn yn gweithio yn achos didoli allanol ac mewn rhai manylion eraill. Ond yn gyffredinol ni ddylai hyn ddigwydd, mae'n nam. A'r unig beth y gallaf ei argymell yw diweddaru ClickHouse.
Sut i gyfrifo amser ymateb o dan lwyth darllen?
Mae yna fwrdd sy'n storio agregau eitemau - cownteri amrywiol. Mae nifer y llinellau tua chan miliwn. A yw'n bosibl cyfrif ar amser ymateb rhagweladwy os ydych chi'n arllwys 1K RPS ar gyfer eitemau 1K?
A barnu yn ôl y cyd-destun, yr ydym yn sôn am y llwyth darllen, oherwydd nid oes unrhyw broblemau gydag ysgrifennu - hyd yn oed mil, hyd yn oed can mil, ac weithiau gellir gosod sawl miliwn o resi.
Mae ceisiadau darllen yn wahanol iawn. Mewn dewis 1, gall ClickHouse berfformio tua degau o filoedd o geisiadau yr eiliad, felly bydd angen rhai adnoddau eisoes ar gyfer ceisiadau am un allwedd. A bydd ymholiadau pwynt o'r fath yn anoddach nag mewn rhai cronfeydd data gwerth allweddol, oherwydd ar gyfer pob darlleniad mae angen darllen bloc o ddata yn ôl mynegai. Nid yw ein mynegai yn mynd i'r afael â phob cofnod, ond pob ystod. Hynny yw, bydd yn rhaid i chi ddarllen yr ystod gyfan - dyma 8192 o linellau yn ddiofyn. A bydd yn rhaid i chi ddatgywasgu'r bloc data cywasgedig o 64 KB i 1 MB. Yn nodweddiadol, mae angen rhai milieiliadau i gwblhau ymholiadau wedi'u targedu o'r fath. Ond dyma'r opsiwn symlaf.
Gadewch i ni roi cynnig ar rai rhifyddeg syml. Os ydych chi'n lluosi ychydig filieiliadau â mil, byddwch chi'n cael ychydig eiliadau. Mae fel pe bai'n amhosibl cadw i fyny â mil o geisiadau yr eiliad, ond mewn gwirionedd mae'n bosibl, oherwydd mae gennym ni sawl craidd prosesydd. Felly, mewn egwyddor, gall ClickHouse weithiau ddal 1000 RPS, ond ar gyfer ceisiadau byr, rhai wedi'u targedu'n benodol.
Os oes angen i chi raddio clwstwr ClickHouse yn ôl nifer y ceisiadau syml, yna rwy'n argymell y peth symlaf - cynyddu nifer y copïau ac anfon ceisiadau at replica ar hap. Os bydd un replica yn dal pum cant o geisiadau yr eiliad, sy'n gwbl realistig, yna bydd tri atgynhyrchiad yn ymdrin â mil a hanner.
Weithiau, wrth gwrs, gallwch chi ffurfweddu ClickHouse ar gyfer y nifer uchaf o ddarlleniadau pwynt. Beth sydd ei angen ar gyfer hyn? Y cyntaf yw lleihau gronynnedd y mynegai. Yn yr achos hwn, ni ddylid ei leihau i un, ond ar y sail y bydd nifer y cofnodion yn y mynegai yn sawl miliwn neu ddegau o filiynau fesul gweinydd. Os oes gan y bwrdd gan miliwn o resi, yna gellir gosod y gronynnedd i 64.
Gallwch leihau maint y bloc cywasgedig. Mae gosodiadau ar gyfer hyn min cywasgu maint bloc, maint bloc cywasgu mwyaf. Gellir eu lleihau, eu hail-lenwi â data, ac yna bydd ymholiadau wedi'u targedu yn gyflymach. Ond o hyd, nid yw ClickHouse yn gronfa ddata gwerth allweddol. Mae nifer fawr o geisiadau bach yn antipattern llwyth.
Kirill Shvakov: Rhoddaf gyngor rhag ofn y bydd cyfrifon cyffredin yno. Mae hon yn sefyllfa weddol safonol pan fo ClickHouse yn storio rhyw fath o gownter. Mae gen i ddefnyddiwr, mae'n dod o wlad o'r fath ac o'r fath, a rhyw drydydd maes, ac mae angen i mi gynyddu rhywbeth yn gynyddrannol. Cymerwch MySQL, gwnewch allwedd unigryw - yn MySQL mae'n allwedd ddyblyg, ac yn PostgreSQL mae'n wrthdaro - ac ychwanegwch arwydd plws. Bydd hyn yn gweithio'n llawer gwell.
Pan nad oes gennych lawer o ddata, nid oes llawer o bwynt defnyddio ClickHouse. Mae cronfeydd data rheolaidd ac maent yn gwneud hyn yn dda.
Beth alla i ei newid yn ClickHouse fel bod mwy o ddata yn y storfa?
Gadewch i ni ddychmygu sefyllfa - mae gan y gweinyddwyr 256 GB o RAM, yn y drefn ddyddiol mae ClickHouse yn cymryd tua 60-80 GB, yn yr oriau brig - hyd at 130. Yr hyn y gellir ei alluogi a'i addasu fel bod mwy o ddata yn y storfa ac, yn unol â hynny, oes llai o deithiau i'r ddisg?
Yn nodweddiadol, mae storfa tudalennau'r system weithredu yn gwneud gwaith da o hyn. Os ydych chi'n agor y brig yn unig, edrychwch yno wedi'i storio neu am ddim - mae hefyd yn dweud faint sy'n cael ei storio - yna byddwch yn sylwi bod yr holl gof am ddim yn cael ei ddefnyddio ar gyfer y storfa. Ac wrth ddarllen y data hwn, bydd yn cael ei ddarllen nid o'r ddisg, ond o'r RAM. Ar yr un pryd, gallaf ddweud bod y storfa'n cael ei ddefnyddio'n effeithiol oherwydd mai'r data cywasgedig sy'n cael ei storio.
Fodd bynnag, os ydych chi am gyflymu rhai ymholiadau syml hyd yn oed yn fwy, mae'n bosibl galluogi storfa yn y data datgywasgedig y tu mewn i ClickHouse. Fe'i gelwir storfa heb ei chywasgu. Yn y ffeil cyfluniad config.xml, gosodwch y maint cache anghywasgedig i'r gwerth sydd ei angen arnoch - nid wyf yn argymell mwy na hanner yr RAM rhad ac am ddim, oherwydd bydd y gweddill yn mynd o dan y storfa dudalen.
Yn ogystal, mae dau leoliad lefel cais. Gosodiad cyntaf - defnyddio storfa heb ei chywasgu - yn cynnwys ei ddefnydd. Argymhellir ei alluogi ar gyfer pob cais, ac eithrio rhai trwm, sy'n gallu darllen yr holl ddata a fflysio'r storfa. Ac mae'r ail osodiad yn rhywbeth fel y nifer uchaf o linellau i ddefnyddio'r storfa. Mae'n cyfyngu ymholiadau mawr yn awtomatig fel eu bod yn osgoi'r storfa.
Sut alla i ffurfweddu storage_configuration ar gyfer storio yn RAM?
Yn y ddogfennaeth ClickHouse newydd darllenais yr adran berthnasol . Mae'r disgrifiad yn cynnwys enghraifft gyda SSD cyflym.
Tybed sut y gellir ffurfweddu'r un peth â chof poeth cyfaint. Ac un cwestiwn arall. Sut mae dewis yn gweithio gyda'r sefydliad data hwn, a fydd yn darllen y set gyfan neu dim ond yr un sydd ar ddisg, ac a yw'r data hwn wedi'i gywasgu yn y cof? A sut mae'r adran prewhere yn gweithio gyda sefydliad data o'r fath?
Mae'r gosodiad hwn yn effeithio ar storio talpiau data, ac nid yw eu fformat yn newid mewn unrhyw ffordd.
Gadewch i ni edrych yn agosach.
Gallwch chi ffurfweddu storfa ddata yn RAM. Y cyfan sydd wedi'i ffurfweddu ar gyfer y ddisg yw ei llwybr. Rydych chi'n creu rhaniad tmpfs sydd wedi'i osod ar ryw lwybr yn y system ffeiliau. Rydych chi'n nodi'r llwybr hwn fel y llwybr ar gyfer storio data ar gyfer y rhaniad poethaf, mae darnau o ddata'n dechrau cyrraedd a chael eu hysgrifennu yno, mae popeth yn iawn.
Ond nid wyf yn argymell gwneud hyn oherwydd dibynadwyedd isel, er os oes gennych o leiaf dri atgynhyrchiad mewn gwahanol ganolfannau data, yna mae'n bosibl. Os bydd unrhyw beth yn digwydd, bydd y data yn cael ei adfer. Gadewch i ni ddychmygu bod y gweinydd wedi'i ddiffodd yn sydyn a'i droi yn ôl ymlaen. Gosodwyd y pared eto, ond nid oedd dim yno. Pan fydd gweinydd ClickHouse yn cychwyn, mae'n gweld nad oes ganddo'r darnau hyn, er, yn ôl metadata ZooKeeper, dylent fod yno. Mae'n edrych ar ba atgynyrchiadau sydd ganddynt, yn gofyn amdanynt ac yn eu llwytho i lawr. Fel hyn bydd y data yn cael ei adfer.
Yn yr ystyr hwn, nid yw storio data mewn RAM yn sylfaenol wahanol i'w storio ar ddisg, oherwydd pan fydd data'n cael ei ysgrifennu ar ddisg, mae hefyd yn dod i ben gyntaf yn storfa'r dudalen ac yn cael ei ysgrifennu'n gorfforol yn ddiweddarach. Mae hyn yn dibynnu ar yr opsiwn mowntio system ffeiliau. Ond rhag ofn, byddaf yn dweud nad yw ClickHouse yn cydamseru wrth fewnosod.
Yn yr achos hwn, mae'r data yn y RAM yn cael ei storio yn union yr un fformat ag ar y ddisg. Mae'r ymholiad dethol yn yr un modd yn dewis y darnau sydd angen eu darllen, yn dewis yr ystodau data angenrheidiol yn y darnau, ac yn eu darllen. Ac mae prewhere yn gweithio'n union yr un peth, ni waeth a oedd y data mewn RAM neu ar ddisg.
Hyd at ba nifer o werthoedd unigryw y mae Cardinality Isel yn effeithiol?
Mae Cardinality Isel wedi'i ddylunio'n glyfar. Mae'n llunio geiriaduron data, ond maent yn lleol. Yn gyntaf, mae geiriaduron gwahanol ar gyfer pob darn, ac yn ail, hyd yn oed o fewn un darn gallant fod yn wahanol ar gyfer pob ystod. Pan fydd nifer y gwerthoedd unigryw yn cyrraedd rhif trothwy—miliwn, rwy’n meddwl—mae’r geiriadur yn syml wedi’i roi o’r neilltu ac un newydd yn cael ei greu.
Mae'r ateb yn gyffredinol: ar gyfer pob ystod leol - dyweder, ar gyfer pob dydd - rhywle hyd at filiwn o werthoedd unigryw Cardinality Isel yn effeithiol. Wedi hynny bydd yna wrth gefn yn unig, lle bydd llawer o eiriaduron gwahanol yn cael eu defnyddio, ac nid un yn unig. Bydd yn gweithio tua'r un peth â cholofn llinynnol arferol, efallai ychydig yn llai effeithlon, ond ni fydd unrhyw ddiraddio perfformiad difrifol.
Beth yw'r arferion gorau ar gyfer testun llawn chwilio tabl gyda phum biliwn o resi?
Mae yna wahanol atebion. Y cyntaf yw dweud nad yw ClickHouse yn beiriant chwilio testun llawn. Mae systemau arbennig ar gyfer hyn, er enghraifft, и . Fodd bynnag, rwy'n gweld mwy a mwy o bobl yn dweud eu bod yn newid o Elasticsearch i ClickHouse.
Pam mae hyn yn digwydd? Maent yn esbonio hyn gan y ffaith bod Elasticsearch yn rhoi'r gorau i ymdopi â'r llwyth ar rai cyfeintiau, gan ddechrau gydag adeiladu mynegeion. Mae mynegeion yn mynd yn rhy feichus, ac os ydych chi'n trosglwyddo'r data i ClickHouse, mae'n ymddangos eu bod yn cael eu storio sawl gwaith yn fwy effeithlon o ran cyfaint. Ar yr un pryd, nid oedd ymholiadau chwilio yn aml yn golygu bod angen dod o hyd i ymadrodd yn y gyfrol gyfan o ddata, gan ystyried morffoleg, ond rhai cwbl wahanol. Er enghraifft, darganfyddwch rywfaint o ddilyniant beit yn y logiau dros yr ychydig oriau diwethaf.
Yn yr achos hwn, rydych chi'n creu mynegai yn ClickHouse, a'r maes cyntaf fydd y dyddiad a'r amser. A bydd y torbwynt data mwyaf yn seiliedig ar yr ystod dyddiadau. O fewn yr ystod dyddiad a ddewiswyd, fel rheol, mae eisoes yn bosibl cynnal chwiliad testun llawn, hyd yn oed gan ddefnyddio'r dull grym 'n ysgrublaidd gan ddefnyddio tebyg. Y gweithredwr tebyg yn ClickHouse yw'r gweithredwr tebyg mwyaf effeithlon y gallwch chi ddod o hyd iddo. Os dewch chi o hyd i rywbeth gwell, dywedwch wrthyf.
Ond eto, fel sgan llawn. A gall sgan llawn fod yn araf nid yn unig ar y CPU, ond hefyd ar y ddisg. Os yn sydyn mae gennych un terabyte o ddata y dydd, a'ch bod yn chwilio am air yn ystod y dydd, yna bydd yn rhaid i chi sganio'r terabyte. Ac mae'n debyg ei fod ar yriannau caled rheolaidd, ac yn y diwedd byddant yn cael eu llwytho yn y fath fodd fel na fyddwch yn gallu cyrchu'r gweinydd hwn trwy SSH.
Yn yr achos hwn, rwy'n barod i gynnig un tric bach arall. Mae'n arbrofol - efallai y bydd yn gweithio, efallai na fydd. Mae gan ClickHouse fynegeion testun llawn ar ffurf hidlwyr trigram Bloom. Mae ein cydweithwyr yn Arenadata eisoes wedi rhoi cynnig ar y mynegeion hyn, ac maent yn aml yn gweithio'n union fel y bwriadwyd.
Er mwyn eu defnyddio'n gywir, dylai fod gennych ddealltwriaeth dda o sut yn union y maent yn gweithio: beth yw hidlydd Bloom trigram a sut i ddewis ei faint. Gallaf ddweud y byddant yn helpu ar gyfer ymholiadau ar rai ymadroddion prin, is-linynnau na cheir yn aml yn y data. Yn yr achos hwn, bydd subranges yn cael eu dewis gan fynegai a bydd llai o ddata yn cael ei ddarllen.
Yn ddiweddar, mae ClickHouse wedi ychwanegu swyddogaethau hyd yn oed yn fwy datblygedig ar gyfer chwilio testun llawn. Mae hwn, yn gyntaf, yn chwiliad am griw o is-linynnau ar unwaith mewn un tocyn, gan gynnwys opsiynau sy'n sensitif i achosion, yn ansensitif i achosion, gyda chefnogaeth ar gyfer UTF-8 neu dim ond ar gyfer ASCII. Dewiswch yr un mwyaf effeithiol sydd ei angen arnoch chi.
Mae chwilio am ymadroddion rheolaidd lluosog mewn un tocyn hefyd wedi ymddangos. Nid oes angen i chi ysgrifennu X fel un is-linyn neu X fel is-linyn arall. Rydych chi'n ysgrifennu ar unwaith, a gwneir popeth mor effeithlon â phosibl.
Yn drydydd, mae yna bellach chwiliad bras am regexps a chwiliad bras am is-linynnau. Os bydd rhywun wedi camsillafu gair, bydd yn cael ei chwilio am yr uchafswm cyfatebol.
Beth yw'r ffordd orau o drefnu mynediad i ClickHouse ar gyfer nifer fawr o ddefnyddwyr?
Dywedwch wrthym beth yw'r ffordd orau o drefnu mynediad ar gyfer nifer fawr o ddefnyddwyr a dadansoddwyr. Sut i ffurfio ciw, blaenoriaethu'r ymholiadau cydamserol mwyaf, a gyda pha offer?
Os yw'r clwstwr yn ddigon mawr, yna ateb da fyddai codi dau weinydd arall, a fydd yn dod yn bwynt mynediad i ddadansoddwyr. Hynny yw, peidiwch â chaniatáu i ddadansoddwyr gael mynediad i ddarnau penodol yn y clwstwr, ond yn syml creu dau weinydd gwag, heb ddata, a ffurfweddu hawliau mynediad arnynt. Yn yr achos hwn, mae gosodiadau defnyddwyr ar gyfer ceisiadau dosbarthedig yn cael eu trosglwyddo i weinyddion anghysbell. Hynny yw, rydych chi'n ffurfweddu popeth ar y ddau weinydd hyn, ac mae'r gosodiadau'n cael effaith ar y clwstwr cyfan.
Mewn egwyddor, nid oes gan y gweinyddwyr hyn unrhyw ddata, ond mae faint o RAM sydd arnynt yn bwysig iawn ar gyfer gweithredu ceisiadau. Gellir defnyddio'r ddisg hefyd ar gyfer data dros dro os yw cydgasglu allanol neu ddidoli allanol wedi'i alluogi.
Mae'n bwysig edrych ar y gosodiadau sy'n gysylltiedig â'r holl derfynau posibl. Os byddaf yn awr yn mynd i'r clwstwr Yandex.Metrica fel dadansoddwr a gofyn cais dewis cyfrif o drawiadau, yna rhoddir eithriad i mi ar unwaith na allaf gyflawni y cais. Uchafswm nifer y rhesi y caniateir i mi eu sganio yw cant biliwn, ac mae yna hanner cant triliwn ohonyn nhw i gyd mewn un bwrdd ar y clwstwr. Dyma'r cyfyngiad cyntaf.
Gadewch i ni ddweud fy mod yn dileu'r terfyn rhes a rhedeg yr ymholiad eto. Yna byddaf yn gweld yr eithriad canlynol - gosod wedi'i alluogi mynegai grym yn ôl dyddiad. Ni allaf gwblhau'r ymholiad os nad wyf wedi nodi ystod dyddiadau. Nid oes rhaid i chi ddibynnu ar ddadansoddwyr i'w nodi â llaw. Achos nodweddiadol yw pan fydd ystod dyddiadau yn cael ei ysgrifennu lle mae digwyddiad yn dyddio rhwng wythnos. Ac yna maent yn nodi yn syml braced yn y lle anghywir, ac yn lle ac mae'n troi allan i fod yn neu - neu URL cyfateb. Os nad oes terfyn, bydd yn cropian y golofn URL a dim ond gwastraffu tunnell o adnoddau.
Yn ogystal, mae gan ClickHouse ddau leoliad blaenoriaeth. Yn anffodus, maent yn gyntefig iawn. Gelwir un yn syml blaenoriaeth. Os yw blaenoriaeth ≠ 0, a cheisiadau gyda rhywfaint o flaenoriaeth yn cael eu gweithredu, ond bod cais gyda gwerth blaenoriaeth o lai na, sy'n golygu blaenoriaeth uwch, yn cael ei weithredu, yna cais gyda gwerth blaenoriaeth o fwy, sy'n golygu blaenoriaeth is , yn syml wedi'i atal ac ni fydd yn gweithio o gwbl yn ystod y cyfnod hwn.
Mae hwn yn osodiad amrwd iawn ac nid yw'n addas ar gyfer achosion lle mae gan y clwstwr lwyth cyson. Ond os oes gennych chi geisiadau byr, byrstiog sy'n bwysig, a bod y clwstwr yn segur ar y cyfan, mae'r gosodiad hwn yn addas.
Gelwir y gosodiad blaenoriaeth nesaf Blaenoriaeth edau OS. Yn syml, mae'n gosod y gwerth braf ar gyfer yr holl edafedd gweithredu cais ar gyfer y trefnydd Linux. Mae'n gweithio felly-felly, ond mae'n dal i weithio. Os ydych chi'n gosod y gwerth neis lleiaf - dyma'r gwerth mwyaf, ac felly'r flaenoriaeth isaf - a gosod -19 ar gyfer ceisiadau â blaenoriaeth uchel, yna bydd y CPU yn defnyddio ceisiadau â blaenoriaeth isel tua phedair gwaith yn llai na rhai â blaenoriaeth uchel.
Mae angen i chi hefyd ffurfweddu'r uchafswm amser gweithredu ceisiadau - dyweder, pum munud. Y cyflymder lleiaf ar gyfer cyflawni ymholiad yw'r peth oeraf. Mae'r gosodiad hwn wedi bod o gwmpas ers amser maith, ac mae'n ofynnol nid yn unig honni nad yw ClickHouse yn arafu, ond i'w orfodi.
Dychmygwch, rydych chi wedi sefydlu: os yw rhai ymholiad yn prosesu llai na miliwn o resi yr eiliad, ni allwch wneud hynny. Mae hyn yn gwarthu ein henw da, ein cronfa ddata dda. Gadewch i ni wahardd hyn. Mewn gwirionedd mae dau leoliad. Gelwir un cyflymder gweithredu min - mewn llinellau yr eiliad, a gelwir yr ail yn terfyn amser cyn gwirio cyflymder gweithredu min - pymtheg eiliad yn ddiofyn. Hynny yw, mae pymtheg eiliad yn bosibl, ac yna, os yw'n araf, yna taflu eithriad ac erthylu'r cais.
Mae angen i chi hefyd sefydlu cwotâu. Mae gan ClickHouse nodwedd cwota adeiledig sy'n cyfrif y defnydd o adnoddau. Ond, yn anffodus, nid adnoddau caledwedd megis CPU, disgiau, ond rhai rhesymegol - nifer y ceisiadau wedi'u prosesu, llinellau a beit darllen. A gallwch chi ffurfweddu, er enghraifft, uchafswm o gant o geisiadau o fewn pum munud a mil o geisiadau yr awr.
Pam ei fod yn bwysig? Oherwydd bydd rhai ymholiadau dadansoddeg yn cael eu perfformio â llaw yn uniongyrchol gan y cleient ClickHouse. A bydd popeth yn iawn. Ond os oes gennych ddadansoddwyr datblygedig yn eich cwmni, byddant yn ysgrifennu sgript, ac efallai y bydd gwall yn y sgript. A bydd y gwall hwn yn achosi i'r cais gael ei weithredu mewn dolen anfeidrol. Dyma beth sydd angen i ni amddiffyn ein hunain rhagddi.
A yw'n bosibl rhoi canlyniadau un ymholiad i ddeg cleient?
Mae gennym nifer o ddefnyddwyr sy'n hoffi dod i mewn gyda cheisiadau mawr iawn ar yr un pryd. Mae'r cais yn fawr ac, mewn egwyddor, yn cael ei weithredu'n gyflym, ond oherwydd y ffaith bod llawer o geisiadau o'r fath ar yr un pryd, mae'n dod yn boenus iawn. A yw'n bosibl gweithredu'r un cais, a gyrhaeddodd ddeg gwaith yn olynol, unwaith, a rhoi'r canlyniad i ddeg o gleientiaid?
Y broblem yw nad oes gennym ganlyniadau'r storfa neu'r storfa o ddata canolradd. Mae storfa dudalen o'r system weithredu, a fydd yn eich atal rhag darllen data o'r ddisg eto, ond, yn anffodus, bydd y data'n dal i gael ei ddatgywasgu, ei ddad-gyfrifo a'i ailbrosesu.
Hoffwn osgoi hyn rywsut, naill ai trwy gadw data canolradd, neu drwy drefnu ymholiadau tebyg mewn rhyw fath o giw ac ychwanegu storfa canlyniadau. Ar hyn o bryd mae gennym un cais tynnu yn cael ei ddatblygu sy'n ychwanegu storfa cais, ond dim ond ar gyfer subqueries yn yr adrannau mewn ac ymuno - hynny yw, yr ateb yn anghyflawn.
Fodd bynnag, rydym hefyd yn wynebu sefyllfa o’r fath. Enghraifft arbennig o ganonaidd yw ymholiadau tudalenedig. Mae yna adroddiad, mae ganddo sawl tudalen, ac mae yna gais am gyfyngiad 10. Yna yr un peth, ond terfyn 10,10. Yna tudalen nesaf arall. A'r cwestiwn yw, pam rydyn ni'n cyfrif hyn i gyd bob tro? Ond nawr nid oes ateb, ac nid oes unrhyw ffordd i'w osgoi.
Mae yna ateb arall sy'n cael ei osod fel car ochr wrth ymyl ClickHouse - .
Kirill Shvakov: Mae gan ClickHouse Proxy gyfyngydd cyfradd adeiledig a storfa canlyniadau adeiledig. Gwnaethpwyd llawer o leoliadau yno oherwydd bod problem debyg yn cael ei datrys. Mae dirprwy yn caniatáu ichi gyfyngu ar geisiadau trwy eu ciwio a ffurfweddu pa mor hir y mae storfa'r cais yn byw. Pe bai'r ceisiadau yr un peth mewn gwirionedd, bydd Proxy yn eu hanfon sawl gwaith, ond dim ond unwaith y bydd yn mynd i ClickHouse.
Mae gan Nginx storfa hefyd yn y fersiwn am ddim, a bydd hyn hefyd yn gweithio. Mae gan Nginx leoliadau hyd yn oed os bydd ceisiadau'n cyrraedd ar yr un pryd, bydd yn arafu eraill nes bod un wedi'i gwblhau. Ond yn ClickHouse Proxy y mae'r gosodiad yn cael ei wneud yn llawer gwell. Fe'i gwnaed yn benodol ar gyfer ClickHouse, yn benodol ar gyfer y ceisiadau hyn, felly mae'n fwy addas. Wel, mae'n hawdd ei osod.
Beth am weithrediadau asyncronaidd a safbwyntiau wedi'u gwireddu?
Mae yna broblem bod gweithrediadau gyda'r injan ailchwarae yn asyncronaidd - yn gyntaf mae'r data'n cael ei ysgrifennu, yna mae'n cwympo. Os yw tabled wedi'i gwireddu gyda rhai agregau yn byw o dan yr arwydd, yna bydd copïau dyblyg yn cael eu hysgrifennu ati. Ac os nad oes rhesymeg gymhleth, yna bydd y data yn cael ei ddyblygu. Beth allwch chi ei wneud amdano?
Mae yna ateb amlwg - gweithredu sbardun ar ddosbarth penodol o fatviews yn ystod gweithrediad cwymp asyncronaidd. A oes unrhyw fwledi arian neu gynlluniau i roi swyddogaethau tebyg ar waith?
Mae'n werth deall sut mae dad-ddyblygu yn gweithio. Nid yw'r hyn a ddywedaf wrthych yn awr yn berthnasol i'r cwestiwn, ond rhag ofn ei fod yn werth ei gofio.
Wrth fewnosod mewn tabl wedi'i ddyblygu, mae'r blociau cyfan sydd wedi'u mewnosod yn cael eu dileu. Os byddwch yn ailgyflwyno'r un bloc sy'n cynnwys yr un nifer o'r un rhesi yn yr un drefn, yna caiff y data ei ddad-ddyblygu. Byddwch yn derbyn “Iawn” mewn ymateb i fewnosod, ond mewn gwirionedd bydd un pecyn o ddata yn cael ei ysgrifennu, ac ni fydd yn cael ei ddyblygu.
Mae hyn yn angenrheidiol er sicrwydd. Os byddwch chi'n derbyn "Iawn" wrth fewnosod, yna mae'ch data wedi'i fewnosod. Os ydych chi'n derbyn gwall gan ClickHouse, mae'n golygu na chawsant eu mewnosod a bod angen i chi ailadrodd y mewnosodiad. Ond os yw'r cysylltiad wedi'i dorri wrth fewnosod, yna nid ydych chi'n gwybod a gafodd y data ei fewnosod ai peidio. Yr unig opsiwn yw ailadrodd y gosodiad eto. Os mewnosodwyd y data mewn gwirionedd a'ch bod wedi'i ail-osod, mae yna ddad-ddyblygu bloc. Mae angen hyn er mwyn osgoi dyblygu.
Ac mae hefyd yn bwysig sut mae'n gweithio ar gyfer safbwyntiau materol. Os cafodd y data ei ddad-ddyblygu wrth ei fewnosod yn y prif dabl, yna ni fydd yn mynd i mewn i'r golwg wedi'i wireddu ychwaith.
Yn awr am y cwestiwn. Mae eich sefyllfa'n fwy cymhleth oherwydd eich bod yn cofnodi dyblygu llinellau unigol. Hynny yw, nid y pecyn cyfan sy'n cael ei ddyblygu, ond llinellau penodol, ac maent yn cwympo yn y cefndir. Yn wir, bydd y data'n cwympo yn y prif dabl, ond bydd y data sydd heb ei gwympo yn mynd i'r golwg wedi'i wireddu, ac yn ystod uno ni fydd unrhyw beth yn digwydd i'r golygfeydd sydd wedi'u gwireddu. Oherwydd nid yw golygfa wedi'i gwireddu yn ddim mwy na sbardun mewnosod. Yn ystod gweithrediadau eraill, nid oes dim byd ychwanegol yn digwydd iddo.
Ac ni allaf eich gwneud yn hapus yma. Does ond angen i chi chwilio am ateb penodol ar gyfer yr achos hwn. Er enghraifft, a yw'n bosibl ei ailchwarae mewn golygfa wedi'i gwireddu, a gallai'r dull dad-ddyblygu weithio yr un ffordd. Ond yn anffodus, nid bob amser. Os yw'n agregu, ni fydd yn gweithio.
Kirill Shvakov: Cawsom hefyd adeiladu baglau yn ôl yn y dydd. Roedd problem bod yna argraffiadau hysbysebu, ac mae rhywfaint o ddata y gallwn ei ddangos mewn amser real - dim ond argraffiadau yw'r rhain. Anaml y cânt eu dyblygu, ond os bydd hyn yn digwydd, byddwn yn eu dymchwel yn ddiweddarach beth bynnag. Ac roedd yna bethau na ellid eu dyblygu - cliciau a'r stori gyfan hon. Ond roeddwn i eisiau dangos iddyn nhw bron ar unwaith hefyd.
Sut y gwnaed y safbwyntiau gwirioneddol? Roedd safbwyntiau lle cafodd ei ysgrifennu'n uniongyrchol - fe'i hysgrifennwyd i ddata crai, ac ysgrifennwyd i safbwyntiau. Yno, ar ryw adeg nid yw'r data yn gywir iawn, mae'n cael ei ddyblygu, ac ati. Ac mae ail ran o'r tabl, lle maent yn edrych yn union yr un fath â safbwyntiau wedi'u gwireddu, hynny yw, maent yn hollol union yr un fath o ran strwythur. O bryd i'w gilydd rydym yn ailgyfrifo'r data, yn cyfrif y data heb ddyblygiadau, yn ysgrifennu at y tablau hynny.
Aethon ni trwy'r API - ni fydd hyn yn gweithio yn ClickHouse â llaw. Ac mae'r API yn edrych: pan fydd gennyf ddyddiad yr ychwanegiad olaf i'r tabl, lle gwarantir bod y data cywir eisoes wedi'i gyfrifo, ac mae'n gwneud cais i un tabl ac i dabl arall. O un mae'r cais yn dewis hyd at swm penodol o amser, ac o'r llall mae'n cael yr hyn nad yw wedi'i gyfrifo eto. Ac mae'n gweithio, ond nid trwy ClickHouse yn unig.
Os oes gennych chi ryw fath o API - ar gyfer dadansoddwyr, ar gyfer defnyddwyr - yna, mewn egwyddor, mae hwn yn opsiwn. Rydych chi bob amser yn cyfrif, bob amser yn cyfrif. Gellir gwneud hyn unwaith y dydd neu rywbryd arall. Rydych chi'n dewis i chi'ch hun ystod nad oes ei hangen arnoch chi ac nad yw'n hollbwysig.
Mae gan ClickHouse lawer o logiau. Sut alla i weld cipolwg ar bopeth sy'n digwydd i'r gweinydd?
Mae gan ClickHouse nifer fawr iawn o wahanol logiau, ac mae'r nifer hwn yn cynyddu. Mewn fersiynau newydd, mae rhai ohonynt hyd yn oed yn cael eu galluogi yn ddiofyn; mewn fersiynau hŷn mae'n rhaid eu galluogi wrth eu diweddaru. Fodd bynnag, mae mwy a mwy ohonynt. Yn y pen draw, hoffwn weld beth sy'n digwydd gyda'm gweinydd nawr, efallai ar ryw fath o ddangosfwrdd cryno.
A oes gennych chi dîm ClickHouse, neu dimau eich ffrindiau, sy'n cefnogi rhywfaint o ymarferoldeb dangosfyrddau parod a fyddai'n arddangos y logiau hyn fel cynnyrch gorffenedig? Yn y pen draw, dim ond edrych ar logiau yn ClickHouse yn wych. Ond byddai'n cŵl iawn pe bai eisoes wedi'i baratoi ar ffurf dangosfwrdd. Byddwn yn cael cic allan ohono.
Mae dangosfyrddau, er nad ydynt wedi'u safoni. Yn ein cwmni, mae tua 60 o dimau yn defnyddio ClickHouse, a'r peth rhyfeddaf yw bod gan lawer ohonynt ddangosfyrddau y gwnaethant iddynt eu hunain, a rhai ychydig yn wahanol. Mae rhai timau'n defnyddio gosodiad Yandex.Cloud mewnol. Mae rhai adroddiadau parod, er nad yw pob un yn angenrheidiol. Mae gan eraill eu rhai eu hunain.
Mae gan fy nghydweithwyr o Metrica eu dangosfwrdd eu hunain yn Grafana, ac mae gennyf fy un i ar gyfer eu clwstwr. Yr wyf yn edrych ar bethau fel taro cache ar gyfer y storfa serif. A hyd yn oed yn fwy anodd yw ein bod yn defnyddio gwahanol offer. Creais fy dangosfwrdd gan ddefnyddio teclyn hen iawn o'r enw Graphite-web. Mae e'n hollol hyll. Ac rwy'n dal i'w ddefnyddio fel hyn, er mae'n debyg y byddai Grafana yn fwy cyfleus a hardd.
Yr un peth yw'r peth sylfaenol mewn dangosfyrddau. Mae'r rhain yn fetrigau system ar gyfer y clwstwr: CPU, cof, disg, rhwydwaith. Eraill - nifer y ceisiadau cydamserol, nifer y cyfuniadau cydamserol, nifer y ceisiadau yr eiliad, nifer uchaf y darnau ar gyfer rhaniadau tabl MergeTree, oedi wrth ddyblygu, maint y ciw atgynhyrchu, nifer y rhesi a fewnosodwyd yr eiliad, nifer y blociau a fewnosodwyd yr eiliad. Dyma'r cyfan a geir nid o foncyffion, ond o fetrigau.
Vladimir Kolobaev: Alexey, hoffwn ei gywiro ychydig. Mae yna Grafana. Mae gan Grafana ffynhonnell ddata, sef ClickHouse. Hynny yw, gallaf wneud ceisiadau gan Grafana yn uniongyrchol i ClickHouse. Mae gan ClickHouse fwrdd gyda logiau, mae'r un peth i bawb. O ganlyniad, rwyf am gael mynediad i'r tabl log hwn yn Grafana a gweld y ceisiadau y mae fy gweinydd yn eu gwneud. Byddai'n wych cael dangosfwrdd fel hyn.
Fe wnes i ei feicio fy hun. Ond mae gen i gwestiwn - os yw'r cyfan wedi'i safoni, a Grafana yn cael ei ddefnyddio gan bawb, pam nad oes gan Yandex ddangosfwrdd mor swyddogol?
Kirill Shvakov: Mewn gwirionedd, mae'r ffynhonnell ddata sy'n mynd i ClickHouse bellach yn cefnogi Altinity. A dwi jyst eisiau rhoi fector o ble i gloddio a phwy i wthio. Gallwch ofyn iddynt, oherwydd mae Yandex yn dal i wneud ClickHouse, ac nid y stori o'i gwmpas. Altinity yw'r prif gwmni sy'n hyrwyddo ClickHouse ar hyn o bryd. Ni fyddant yn cefnu arno, ond yn ei gefnogi. Oherwydd, mewn egwyddor, i uwchlwytho dangosfwrdd i wefan Grafana, dim ond i chi gofrestru a'i uwchlwytho - nid oes unrhyw broblemau arbennig.
Alexey Milovidov: Dros y flwyddyn ddiwethaf, mae ClickHouse wedi ychwanegu llawer o alluoedd proffilio ymholiadau. Mae metrigau ar gyfer pob cais ar y defnydd o adnoddau. Ac yn ddiweddar, fe wnaethom ychwanegu proffiliwr ymholiad lefel is fyth i weld lle mae ymholiad yn gwario pob milieiliad. Ond i ddefnyddio'r swyddogaeth hon, mae'n rhaid i mi agor cleient y consol a theipio cais, yr wyf bob amser yn ei anghofio. Fe wnes i ei achub yn rhywle a dal i anghofio ble yn union.
Hoffwn pe bai teclyn sydd newydd ei ddweud, dyma eich ymholiadau trwm, wedi'u grwpio yn ôl dosbarth ymholiad. Pwysais ar un, a byddent yn dweud wrthyf mai dyna pam ei fod yn drwm. Nid oes ateb o'r fath yn awr. Ac mae'n rhyfedd iawn pan fydd pobl yn gofyn i mi: “Dywedwch wrthyf, a oes unrhyw ddangosfyrddau parod ar gyfer Grafana?”, dywedaf: “Ewch i wefan Grafana, mae yna gymuned “Dashboards”, ac mae dangosfwrdd o Dimka, mae dangosfwrdd o Kostyan. Dydw i ddim yn gwybod beth ydyw, nid wyf wedi ei ddefnyddio fy hun.”
Sut i ddylanwadu ar gyfuniadau fel nad yw'r gweinydd yn chwalu i OOM?
Mae gen i fwrdd, dim ond un rhaniad sydd yn y tabl, ReplacingMergeTree yw e. Rwyf wedi bod yn ysgrifennu data iddo ers pedair blynedd. Roedd angen i mi wneud newid ynddo a dileu rhywfaint o ddata.
Gwnes hyn, ac yn ystod prosesu'r cais hwn, defnyddiwyd yr holl gof ar yr holl weinyddion yn y clwstwr, ac aeth yr holl weinyddion yn y clwstwr i OOM. Yna fe wnaethon nhw i gyd godi gyda'i gilydd, dechrau uno'r un llawdriniaeth hon, y bloc data hwn, a syrthio i OOM eto. Yna codasant eto a syrthio eto. Ac ni stopiodd y peth hwn.
Yna mae'n troi allan bod hwn mewn gwirionedd yn nam bod y guys trwsio. Mae hyn yn cŵl iawn, diolch yn fawr iawn. Ond arhosodd gweddill. Ac yn awr, pan fyddaf yn meddwl am wneud rhyw fath o uno yn y tabl, mae gennyf gwestiwn - pam na allaf ddylanwadu ar y cyfuniadau hyn rywsut? Er enghraifft, cyfyngu arnynt gan faint o RAM sydd ei angen, neu, mewn egwyddor, gan y swm a fydd yn prosesu'r tabl penodol hwn.
Mae gen i fwrdd o'r enw “Metrics”, os gwelwch yn dda ei brosesu i mi mewn dwy edefyn. Nid oes angen creu deg neu bump o gyfuniadau yn gyfochrog, gwnewch hynny mewn dau. Credaf fod gennyf ddigon o gof i ddau, ond efallai na fydd yn ddigon i brosesu deg. Pam mae ofn yn parhau? Oherwydd bod y tabl yn tyfu, a rhyw ddydd byddaf yn wynebu sefyllfa nad yw, mewn egwyddor, bellach oherwydd byg, ond oherwydd y bydd y data'n newid mor fawr fel na fydd gennyf ddigon o gof ar y gweinydd. Ac yna bydd y gweinydd yn chwalu i OOM wrth uno. Ar ben hynny, gallaf ganslo'r treiglad, ond nid yw Merji yno mwyach.
Rydych chi'n gwybod, wrth uno, ni fydd y gweinydd yn disgyn i OOM, oherwydd wrth uno, dim ond ar gyfer un ystod fach o ddata y defnyddir faint o RAM. Felly bydd popeth yn iawn waeth faint o ddata.
Vladimir Kolobaev: Iawn. Yma mae'r foment yn golygu, ar ôl i'r byg gael ei drwsio, i mi lawrlwytho fersiwn newydd i mi fy hun, ac ar fwrdd arall, un llai, lle mae yna lawer o raniadau, fe wnes i weithrediad tebyg. Ac yn ystod yr uno, llosgwyd tua 100 GB o RAM ar y gweinydd. Roeddwn i wedi meddiannu 150, 100 wedi'u bwyta, a ffenestr 50 GB ar ôl, felly wnes i ddim syrthio i OOM.
Beth ar hyn o bryd sy'n fy amddiffyn rhag syrthio i OOM os yw'n defnyddio 100 GB o RAM mewn gwirionedd? Beth i'w wneud os bydd yr RAM ar y cyfuniadau yn dod i ben yn sydyn?
Alexey Milovidov: Mae cymaint o broblem fel nad yw'r defnydd o RAM yn benodol ar gyfer uno yn gyfyngedig. A'r ail broblem yw, os oes rhyw fath o uno wedi'i neilltuo, yna mae'n rhaid ei weithredu oherwydd ei fod wedi'i gofnodi yn y log atgynhyrchu. Y log atgynhyrchu yw'r camau gweithredu sydd eu hangen i ddod â'r atgynhyrchiad i gyflwr cyson. Os na fyddwch yn gwneud manipulations â llaw a fydd yn treiglo'n ôl y log atgynhyrchu hwn, bydd yn rhaid i'r uno gael ei berfformio un ffordd neu'r llall.
Wrth gwrs, ni fyddai'n ddiangen cael cyfyngiad RAM sydd “rhag ofn” yn amddiffyn rhag OOM. Ni fydd yn helpu'r uno i gwblhau, bydd yn dechrau eto, yn cyrraedd rhywfaint o drothwy, yn taflu eithriad, ac yna'n dechrau eto - ni ddaw dim da o hyn. Ond mewn egwyddor, byddai'n ddefnyddiol cyflwyno'r cyfyngiad hwn.
Sut bydd gyrrwr Golang ar gyfer ClickHouse yn cael ei ddatblygu?
Mae gyrrwr Golang, a ysgrifennwyd gan Kirill Shvakov, bellach yn cael ei gefnogi'n swyddogol gan dîm ClickHouse. Ef , mae bellach yn fawr ac yn real.
Nodyn bach. Mae yna storfa hyfryd ac annwyl o ffurfiau arferol o drefn anfeidrol - Vertica yw hwn. Mae ganddyn nhw hefyd eu gyrrwr python swyddogol eu hunain, sy'n cael ei gefnogi gan ddatblygwyr Vertica. Ac fe ddigwyddodd sawl gwaith bod y fersiynau storio a'r fersiynau gyrrwr wedi dargyfeirio'n eithaf dramatig, ac fe stopiodd y gyrrwr weithio ar ryw adeg. A'r ail bwynt. Mae cefnogaeth i'r gyrrwr swyddogol hwn, mae'n ymddangos i mi, yn cael ei gyflawni gan y system “deth” - rydych chi'n ysgrifennu mater iddynt, ac mae'n hongian am byth.
Mae gennyf ddau gwestiwn. Nawr gyrrwr Golang Kirill bron yw'r ffordd ddiofyn i gyfathrebu o Golang â ClickHouse. Oni bai bod rhywun yn dal i gyfathrebu trwy'r rhyngwyneb http oherwydd ei fod yn ei hoffi felly. Sut fydd datblygiad y gyrrwr hwn yn mynd rhagddo? A fydd yn cael ei gydamseru ag unrhyw newidiadau torri yn y gadwrfa ei hun? A beth yw'r drefn ar gyfer ystyried mater?
Kirill Shvakov: Y cyntaf yw sut mae popeth yn cael ei drefnu'n fiwrocrataidd. Ni thrafodwyd y pwynt hwn, felly nid oes gennyf ddim i’w ateb.
I ateb y cwestiwn am y mater, mae angen ychydig o hanes y gyrrwr. Roeddwn i'n gweithio i gwmni oedd â llawer o ddata. Roedd yn droellwr hysbysebu gyda nifer enfawr o ddigwyddiadau yr oedd angen eu storio yn rhywle. Ac ar ryw adeg ymddangosodd ClickHouse. Fe wnaethon ni ei lenwi â data, ac ar y dechrau roedd popeth yn iawn, ond yna damwain ClickHouse. Ar y foment honno fe benderfynon ni nad oedd ei angen arnom ni.
Flwyddyn yn ddiweddarach, fe wnaethom ddychwelyd at y syniad o ddefnyddio ClickHouse, ac roedd angen i ni ysgrifennu data yno rywsut. Y neges ragarweiniol oedd hyn: mae'r caledwedd yn wan iawn, prin yw'r adnoddau. Ond rydym bob amser wedi gweithio fel hyn, ac felly rydym yn edrych tuag at y protocol brodorol.
Gan ein bod yn gweithio yn Go, roedd yn amlwg bod angen gyrrwr Go arnom. Fe wnes i bron yn llawn amser - fy nhasg waith oedd hi. Daethom ag ef i ryw bwynt, ac mewn egwyddor nid oedd neb yn tybio y byddai neb heblaw ni yn ei ddefnyddio. Yna daeth CloudFlare gyda'r un broblem yn union, ac am beth amser buom yn gweithio gyda nhw yn esmwyth iawn, oherwydd roedd ganddynt yr un tasgau. Ar ben hynny, gwnaethom hyn yn ClickHouse ein hunain ac yn y gyrrwr.
Ar ryw adeg, fe wnes i roi'r gorau i'w wneud, oherwydd newidiodd fy ngweithgaredd o ran ClickHouse a gwaith ychydig. Felly nid yw materion wedi'u cau. O bryd i'w gilydd, mae pobl sydd angen rhywbeth eu hunain yn ymrwymo i'r gadwrfa. Yna rwy'n edrych ar y cais tynnu ac weithiau byddaf hyd yn oed yn golygu rhywbeth fy hun, ond anaml y mae hyn yn digwydd.
Rwyf am ddychwelyd at y gyrrwr. Sawl blwyddyn yn ôl, pan ddechreuodd yr holl beth hwn, roedd ClickHouse hefyd yn wahanol a gyda galluoedd gwahanol. Nawr mae gennym ddealltwriaeth o sut i ail-wneud y gyrrwr fel ei fod yn gweithio'n dda. Os bydd hyn yn digwydd, yna bydd fersiwn 2 yn anghydnaws beth bynnag oherwydd y baglau cronedig.
Nid wyf yn gwybod sut i drefnu'r mater hwn. Does gen i ddim llawer o amser fy hun. Os bydd rhai pobl yn gorffen y gyrrwr, gallaf eu helpu a dweud wrthynt beth i'w wneud. Ond nid yw cyfranogiad gweithredol Yandex yn natblygiad y prosiect wedi'i drafod eto.
Alexey Milovidov: Mewn gwirionedd, nid oes unrhyw fiwrocratiaeth ynglŷn â’r ysgogwyr hyn eto. Yr unig beth yw eu bod yn cael eu cyflwyno i sefydliad swyddogol, hynny yw, mae'r gyrrwr hwn yn cael ei gydnabod fel yr ateb diofyn swyddogol ar gyfer Go. Mae yna rai gyrwyr eraill, ond maen nhw'n dod ar wahân.
Nid oes gennym unrhyw ddatblygiad mewnol ar gyfer y ysgogwyr hyn. Y cwestiwn yw a allwn logi person unigol, nid ar gyfer y gyrrwr penodol hwn, ond ar gyfer datblygiad pob gyrrwr cymunedol, neu a allwn ddod o hyd i rywun o'r tu allan.
Nid yw'r geiriadur allanol yn llwytho ar ôl ailgychwyn gyda'r gosodiad lazy_load wedi'i alluogi. Beth i'w wneud?
Mae'r gosodiad lazy_load wedi'i alluogi, ac ar ôl i'r gweinydd gael ei ailgychwyn, nid yw'r geiriadur yn llwytho ar ei ben ei hun. Dim ond ar ôl i'r defnyddiwr gael mynediad i'r geiriadur hwn y caiff ei godi. A'r tro cyntaf i mi gael mynediad iddo, mae'n rhoi gwall. A yw'n bosibl rhywsut i lwytho geiriaduron yn awtomatig gan ddefnyddio ClickHouse, neu a oes angen i chi reoli eu parodrwydd eich hun bob amser fel nad yw defnyddwyr yn derbyn gwallau?
Efallai bod gennym ni hen fersiwn o ClickHouse, felly ni wnaeth y geiriadur lwytho'n awtomatig. A allai hyn fod yn wir?
Yn gyntaf, gall geiriaduron gael eu gorfodi gan ddefnyddio ymholiad geiriaduron ail-lwytho system. Yn ail, ynghylch y gwall - os yw'r geiriadur eisoes wedi'i lwytho, yna bydd yr ymholiadau'n gweithio yn seiliedig ar y data a lwythwyd. Os nad yw'r geiriadur wedi'i lwytho eto, bydd yn cael ei lwytho'n uniongyrchol yn ystod y cais.
Nid yw hyn yn gyfleus iawn ar gyfer geiriaduron trwm. Er enghraifft, mae angen i chi dynnu miliwn o resi o MySQL. Mae rhywun yn gwneud dewis syml, ond bydd y dewis hwn yn aros am yr un miliwn o resi. Mae dau ateb yma. Y cyntaf yw diffodd lazy_load. Yn ail, pan fydd y gweinydd i fyny, cyn rhoi'r llwyth arno, gwnewch geiriadur ail-lwytho system neu dim ond gwneud ymholiad sy'n defnyddio geiriadur. Yna bydd y geiriadur yn cael ei lwytho. Mae angen i chi reoli argaeledd geiriaduron gyda'r gosodiad lazy_load wedi'i alluogi, oherwydd nid yw ClickHouse yn eu llwytho'n awtomatig.
Yr ateb i'r cwestiwn olaf yw naill ai bod y fersiwn yn hen neu mae angen ei ddadfygio.
Beth i'w wneud â'r ffaith nad yw geiriaduron ail-lwytho systemau yn llwytho unrhyw un o'r geiriaduron niferus os bydd o leiaf un ohonynt yn cael damwain?
Mae cwestiwn arall am eiriaduron ail-lwytho systemau. Mae gennym ddau eiriadur - nid yw un wedi'i lwytho, mae'r ail yn cael ei lwytho. Yn yr achos hwn, nid yw geiriaduron ail-lwytho System yn llwytho unrhyw eiriadur, ac mae'n rhaid i chi lwytho un pwynt-wrth-bwynt penodol wrth ei enw gan ddefnyddio geiriadur ail-lwytho system. A yw hyn hefyd yn gysylltiedig â fersiwn ClickHouse?
Rwyf am eich gwneud yn hapus. Roedd yr ymddygiad hwn yn newid. Mae hyn yn golygu, os byddwch chi'n diweddaru ClickHouse, bydd hefyd yn newid. Os nad ydych yn hapus gyda'ch ymddygiad presennol geiriaduron ail-lwytho system, diweddaru, a gadewch i ni obeithio y bydd yn newid er gwell.
A oes ffordd i ffurfweddu manylion yn y ffurfwedd ClickHouse, ond heb eu harddangos rhag ofn y bydd gwallau?
Mae'r cwestiwn nesaf yn ymwneud â gwallau sy'n gysylltiedig â'r geiriadur, sef manylion. Rydym wedi nodi'r manylion cyswllt yn y ffurfwedd ClickHouse ar gyfer y geiriadur, ac os oes gwall, rydym yn derbyn y manylion a'r cyfrinair hyn mewn ymateb.
Fe wnaethom ddatrys y gwall hwn trwy ychwanegu manylion at ffurfwedd gyrrwr ODBC. A oes unrhyw ffordd i ffurfweddu'r manylion yn y ffurfwedd ClickHouse, ond heb ddangos y manylion hyn rhag ofn y bydd gwallau?
Yr ateb go iawn yma yw nodi'r tystlythyrau hyn yn odbc.ini, ac yn ClickHouse ei hun nodwch Enw Ffynhonnell Data ODBC yn unig. Ni fydd hyn yn digwydd ar gyfer ffynonellau geiriadur eraill - nid ar gyfer y geiriadur gyda MySQL, nac ar gyfer y lleill, ni ddylech weld y cyfrinair pan fyddwch yn derbyn neges gwall. Ar gyfer ODBC, byddaf hefyd yn edrych - os yw'n bodoli, does ond angen i chi ei dynnu.
Bonws: cefndiroedd ar gyfer Zoom o gynulliadau
Trwy glicio ar y llun, bydd cefndiroedd bonws o'r cynulliadau yn agor i'r darllenwyr mwyaf cyson. Rydyn ni'n diffodd y tân ynghyd â masgotiaid technoleg Avito, rydyn ni'n ymgynghori â chydweithwyr o ystafell gweinyddwr y system neu'r clwb cyfrifiaduron hen ysgol, ac rydyn ni'n cynnal cyfarfodydd dyddiol o dan y bont yn erbyn cefndir graffiti.
Ffynhonnell: hab.com