Di Nîsanê de, endezyarên Avito ji bo civînên serhêl bi pêşdebirê sereke ClickHouse Alexey Milovidov û Kirill Shvakov, pêşdebirek Golang ji Integros re civiyan. Me nîqaş kir ku em çawa pergala rêveberiya databasê bikar tînin û em bi çi zehmetiyan re rû bi rû dimînin.
Li ser bingeha civînê, me gotarek bi bersivên pisporan li ser pirsên me û temaşevanan ên derbarê paşvekişandinê, nûvekirina daneyan, ferhengên derveyî, ajokara Golang û nûvekirina guhertoyên ClickHouse berhev kiriye. Dibe ku ew ji pêşdebirên ku berê bi çalak bi Yandex DBMS re dixebitin û bi niha û paşeroja wê re eleqedar dibin re kêrhatî be. Bi xwerû, bersiv ji hêla Alexey Milovidov ve ne, heya ku wekî din neyê nivîsandin.
Hay ji xwe hebin, di bin birîn de gelek nivîs heye. Em hêvî dikin ku naveroka bi pirsan dê ji we re bibe alîkar ku hûn rêve bibin.
Contains
Ger hûn nexwazin nivîsê bixwînin, hûn dikarin li tomarkirina kombûnê temaşe bikin . Kodên demjimêr di şîroveya yekem de di bin vîdyoyê de ne.
ClickHouse bi berdewamî tê nûve kirin, lê daneyên me ne. Li ser wê çi bikin?
ClickHouse bi domdarî tê nûve kirin, û daneyên me, yên ku di dawîn de hatine xweş kirin, nayên nûve kirin û di kopiyek hilanînê de ne.
Ka em bibêjin hin pirsgirêkek me hebû û dane winda bûn. Me biryar da ku em sererast bikin, û derket holê ku dabeşên kevn, ku li ser pêşkêşkerên paşvekêşanê têne hilanîn, ji guhertoya ku niha tê bikar anîn ClickHouse pir cûda ne. Di rewşeke weha de çi bikin, û ew gengaz e?
Rewşek ku we daneya ji hilanînê di formatek kevn de sererast kir, lê ew bi guhertoya nû ve nayê girêdan, ne gengaz e. Em piştrast dikin ku formata daneyê ya li ClickHouse her gav bi paş ve lihevhatî dimîne. Ger tevgera hin fonksiyonên ku kêm têne bikar anîn guheztin ev ji lihevhatina paşverû ya di fonksiyonê de pir girîngtir e. Guhertoya nû ya ClickHouse divê her gav bikaribe daneyên ku li ser dîskê têne hilanîn bixwîne. Ev qanûn e.
Pratîkên çêtirîn ên heyî yên ji bo piştgirîkirina daneyan ji ClickHouse çi ne?
Meriv çawa paşvekişandinê çêdike, bihesibîne ku me operasyonên dawîn çêtirîn, databasek mezin a terabytes, û daneyên ku, bêje, sê rojên dawîn têne nûve kirin, hene, û dûv re tu prosedurek jê re çênabe?
Em dikarin çareseriya xwe çêbikin û li ser bash binivîsin: van kopiyên paşverû bi vî rengî û wusa berhev bikin. Dibe ku ne hewce ye ku tiştek biqelînin, û bisîklet ji zû ve hatî îcad kirin?
Ka em bi pratîkên çêtirîn dest pê bikin. Hevalên min her gav şîret dikin, di bersiva pirsên di derbarê paşvekişandinê de, ku wan di derheqê karûbarê Yandex.Cloud de, ku ev pirsgirêk jixwe hatî çareser kirin, bi bîr bînin. Ji ber vê yekê heke gengaz be wê bikar bînin.
Ji bo hilanînê çareseriyek bêkêmasî tune, ji sedî sed di ClickHouse de hatî çêkirin. Hin valahiyên ku dikarin werin bikar anîn hene. Ji bo ku hûn çareseriyek bêkêmasî bistînin, hûn ê hewce ne ku hinekî bi destan bişoxilînin, an jî di forma nivîsan de pêçanan biafirînin.
Ez ê bi çareseriyên herî hêsan dest pê bikim û bi yên herî sofîstîke bi dawî bikim, li gorî qebareya daneyê û mezinahiya komê. Komik her ku mezin be, çareserî jî tevlihevtir dibe.
Ger tabloya bi daneyan tenê çend gigabayt dagir dike, hilanînê dikare bi vî rengî were kirin:
- Danasîna tabloyê tomar bike ango metadata − nîşan bide çêkirina tabloyê.
- Bi karanîna muwekîlê ClickHouse çolê çêbikin - neqandin * ji sifrê pelê kirin. Bi xwerû hûn ê pelek bi formata TabSeparated bistînin. Heke hûn dixwazin bikêrtir bin, hûn dikarin wê di forma Native de bikin.
Ger mîqdara daneyê mezintir be, wê hingê hilanînê dê bêtir dem û pir cîh bigire. Ji vê re kopiyek mentiqî tê gotin; ew bi formata daneya ClickHouse ve ne girêdayî ye. Ger wusa be, wê hingê wekî çareya paşîn hûn dikarin hilanînê hilînin û wê ji bo başbûnê li MySQL bar bikin.
Ji bo dozên pêşkeftî, ClickHouse xwedan jêhatîbûnek çêkirî ye ku di pergala pelê herêmî de wêneyek dabeşan biafirîne. Ev taybetmendî wekî daxwazek heye alter sifrê cemidandinê partition. An jî bi hêsanî alter sifrê cemidandinê - ev dîmenek ji tevahiya tabloyê ye.
Dê wêneyek bi domdarî ji bo tabloyek li ser yek perçeyê were afirandin, ango ne gengaz e ku bi vî rengî wêneyek hevgirtî ya tevahiya komê were afirandin. Lê ji bo piraniya peywiran hewcedariyek wusa tune, û bes e ku meriv daxwazek li ser her perçeyek bicîh bike û wêneyek domdar bistîne. Ew di forma girêdanên hişk de tête çêkirin û ji ber vê yekê cîhê zêde nagire. Dûv re, hûn vê wêneyê li ser servera hilanînê an hilanîna ku hûn ji bo hilanînê bikar tînin kopî dikin.
Vegerandina vegerek wusa pir hêsan e. Pêşîn, bi karanîna pênaseyên tabloya heyî tabloyan biafirînin. Dûv re, dîmenên tomarkirî yên dabeşan ji bo van tabloyan li Directory-Detached kopî bikin û lêpirsînê bimeşînin. dabeşkirinê pêve bike. Ev çareserî ji bo cildên herî giran ên daneyê pir maqûl e.
Carinan hûn hewceyê tiştek hê sartir in - di rewşên ku hûn li ser her serverek bi dehan an jî bi sedan terabyte û bi sedan server hene. Li vir çareseriyek heye ku min ji hevkarên xwe yên Yandex.Metrica hilbijart. Ez ê wê ji her kesî re pêşniyar nakim - wê bixwînin û bi xwe biryar bidin ka ew guncan e an na.
Pêşî hûn hewce ne ku çend serverên bi refikên dîskê yên mezin biafirînin. Dûv re, li ser van serveran, çend serverên ClickHouse rakin û wan mîheng bikin da ku ew ji bo heman şûşeyan wekî kopiyek din bixebitin. Û dûv re li ser van serveran pergalek pelan an amûrek bikar bînin ku destûrê dide we ku hûn wêneyan biafirînin. Li vir du vebijark hene. Vebijarka yekem wêneyên LVM-ê ye, vebijarka duyemîn ZFS li Linux-ê ye.
Piştî wê, her roj hûn hewce ne ku wêneyek biafirînin, ew ê derewan bike û hin cîh bigire. Bi xwezayî, heke daneyan biguhere, dê mêjera cîh bi demê re zêde bibe. Ev wêne di her kêliyê de dikare were derxistin û dane nûve kirin, çareseriyek wusa ecêb. Zêdeyî, pêdivî ye ku em di konfigurasyonê de van kopiyan jî sînordar bikin da ku ew hewl nekin ku bibin serok.
Ma ew ê gengaz be ku derengiyek kontrolkirî ya kopiyan di şaneyan de organîze bike?
Vê salê hûn plan dikin ku li ClickHouse şaftan çêbikin. Ma dê gengaz be ku di wan de derengiyek kontrolkirî ya kopiyan organîze bike? Em dixwazin wê bikar bînin da ku xwe ji senaryoyên neyînî bi guhertin û guhertinên din biparêzin.
Ma gengaz e ku meriv ji bo guhertinan cûreyek paşvekişînê bike? Mînakî, di şaftek heyî de, bigire û bêje ku heya vê gavê hûn guhartinan bicîh tînin, û ji vê gavê hûn sepandina guhertinan rawestînin?
Ger fermanek hat koma me û ew şikand, wê hingê em kopiyek şertî ya bi demjimêrek dereng heye, li wir em dikarin bibêjin ku em wê gavê bikar bînin, lê em ê di deh hûrdemên paşîn de guhartinan li ser nekin?
Pêşîn, li ser derengiya kontrolkirî ya kopiyan. Ji bikarhêneran daxwazek wusa hebû, û me li ser Github pirsgirêkek bi vê daxwazê çêkir: "Ger kesek hewceyê vê yekê be, mîna wê, dilê xwe deyne." Kesî radest nekir û mesele hat girtin. Lêbelê, hûn dikarin jixwe vê derfetê bi sazkirina ClickHouse-ê bistînin. Rast e, tenê ji guhertoya 20.3 dest pê dike.
ClickHouse bi domdarî hevgirtina daneyan di paşerojê de pêk tîne. Dema ku hevgirtinek qediya, komek hin perçeyên daneyê bi perçeyek mezintir tê guheztin. Di heman demê de, perçeyên daneyên ku berê li wir bûn, ji bo demekê li ser dîskê dimînin.
Pêşîn, ew berdewam têne hilanîn heya ku pirsên bijartî yên ku wan bikar tînin hebin, da ku operasyona ne-astengkirinê peyda bikin. Pirsên hilbijartî bi hêsanî ji perçeyên kevn têne xwendin.
Ya duyemîn, di heman demê de bendek dem jî heye - perçeyên daneya kevn heşt hûrdeman li ser dîskê dimînin. Van heşt hûrdeman dikarin bêne xweş kirin û tewra di rojekê de werin zivirandin. Ev ê cîhê dîskê lêçûn: Li gorî herikîna daneyê, derdikeve holê ku di roja paşîn de dane ne tenê ducarî, dibe ku pênc carî zêdetir jî bibe. Lê heke pirsgirêkek cidî hebe, hûn dikarin servera ClickHouse rawestînin û her tiştî ji hev derxînin.
Niha pirs derdikeve holê ka ev çawa li hember guhertinan diparêze. Hêja ye ku meriv li vir hûr hûr hûr bibe, ji ber ku di guhertoyên kevntir ên ClickHouse de, guhêrbar bi vî rengî xebitî ku ew bi tenê rasterast perçeyan diguhezand. Bi hin pelan re perçeyek daneyê heye, û em dikin, wek nimûne, stûna avêtinê biguherîne. Dûv re ev stûn bi fîzîkî ji hemî perçeyan tê derxistin.
Lê ji guhertoya 20.3-ê dest pê kir, mekanîzmaya guheztinê bi tevahî hate guheztin, û naha perçeyên daneyê her gav neguhêrbar in. Ew qet nayên guheztin - guheztin niha bi heman awayê yekbûnê dixebitin. Li şûna ku em perçeyek di cih de biguhezînin, em perçeyek nû diafirînin. Di perçeya nû de, pelên ku nehatine guhertin dibin girêdanên hişk, û heke em stûnek jêbirin, ew ê bi tenê di perçeya nû de winda bibe. Parçeya kevn dê piştî heşt hûrdeman ji hêla xwerû ve were jêbirin, û li vir hûn dikarin mîhengên ku li jor hatine destnîşan kirin biguhezînin.
Heman tişt ji bo guhertinên wekî mutasyon jî derbas dibe. Dema ku hûn bikin biguherîne jêbirin an nûvekirin biguherîne, ew perçe naguhere, lê yê nû diafirîne. Û paşê yê kevin jê dike.
Ger avahiya sifrê hatibe guhertin?
Meriv çawa paşgirek ku bi pilana kevn hatî çêkirin sererast dike? Û pirsa duyemîn di derbarê doza wêneyan û amûrên pergala pelan de ye. Ma Btrfs li vir li şûna ZFS li Linux LVM baş e?
Heke hûn bikin dabeşkirinê pêve bike dabeşên bi avahiyek cûda, wê hingê ClickHouse dê ji we re vebêje ku ev ne gengaz e. Ev çareserî ye. Ya yekem ev e ku meriv tabloyek demkî ya celebê MergeTree bi strûktûra kevn ve biafirîne, bi karanîna pêvekirinê daneyan li wir girêbide, û pirsek guhêrbar bike. Dûv re hûn dikarin van daneyan kopî bikin an veguhezînin û dîsa pêve bikin, an daxwazek bikar bînin alter sifrê move partition.
Naha pirsa duyemîn ev e ku gelo Btrf dikare were bikar anîn. Destpêkê, heke we LVM heye, wê hingê wêneyên LVM bes in, û pergala pelê dikare ext4 be, ne girîng e. Bi Btrts re, her tişt bi ezmûna we ya karanîna wê ve girêdayî ye. Ev pergalek pelê ya gihîştî ye, lê hîn jî hin guman hene ku dê di senaryoyek taybetî de çawa her tişt di pratîkê de bixebite. Ez ê vê yekê bikar neyînim heya ku hûn Btrfs di hilberînê de nebin.
Di nûvekirina daneyan de pratîkên çêtirîn ên heyî çi ne?
Pirsgirêka reşkirinê tevlihev û piralî ye. Li vir çend bersivên gengaz hene. Hûn dikarin ji aliyekî ve biçin û vê yekê bibêjin - ClickHouse xwedan taybetmendiyek nûvekirinê ya çêkirî nîne. Lê ez ditirsim ku ev bersiv kêrî kesî neyê. Ji ber vê yekê, hûn dikarin ji aliyekî din ve biçin û bibêjin ku ClickHouse gelek awayên ji nûvekirina daneyan heye.
Ger cîh ji komê xilas bibe an ew nikaribe barkirinê hilgire, hûn serverên nû lê zêde dikin. Lê ev server ji hêla xwerû ve vala ne, daneyên wan tune, bar tune. Pêdivî ye ku hûn daneyan ji nû ve saz bikin da ku ew bi rengek wekhev li koma nû, mezintir belav bibe.
Awayê yekem ku ev dikare were kirin ev e ku bi karanîna daxwaznameyekê beşek ji dabeşan li serverên nû kopî bike tabloya dabeşkirina hilanînê biguherîne. Mînakî, we bi mehê veqetandin hebûn, û hûn meha yekem a 2017-an digirin û wê li serverek nû kopî dikin, dûv re meha sêyemîn li serverek din a nû kopî bikin. Û hûn vê yekê dikin heta ku ew kêm-zêde jî bibe.
Veguheztin tenê ji bo wan dabeşên ku di dema tomarkirinê de naguherin dikare were kirin. Ji bo dabeşên nû, tomarkirin dê neçar be, ji ber ku veguheztina wan ne atomî ye. Wekî din, hûn ê di daneyan de dubare an kêmasiyan biqedînin. Lêbelê, ev rêbaz pratîk e û pir bi bandor dixebite. Parçeyên berhevkirî yên amade li ser torê têne veguheztin, yanî dane nayên pêçan an ji nû ve têne kod kirin.
Vê rêbazê yek kêmasiyek heye, û ew bi pilana parvekirinê ve girêdayî ye, gelo we soza vê nexşeya parvekirinê daye an na, we kîjan mifteya parvekirinê hebû. Di mînaka we de ji bo doza bi metrîkan re, mifteya parvekirinê heşê rê ye. Gava ku hûn tabloyek Belavkirî hildibijêrin, ew di yekcarê de diçe hemî perçeyên komê û ji wir daneyan digire.
Ev tê vê wateyê ku bi rastî ji we re ne girîng e ka kîjan daneyan li ser kîjan şikilê bi dawî bûne. Ya sereke ev e ku daneya li ser yek rêyek li ser yek şiklê diqede, lê kîjan ne girîng e. Di vê rewşê de, veguheztina dabeşên hazir bêkêmasî ye, ji ber ku bi pirsên hilbijartî hûn ê daneya bêkêmasî jî bistînin - çi berî nûvekirinê, çi jî paşê, nexşe bi rastî ne girîng e.
Lê rewşên ku tevlihevtir in hene. Ger di asta mentiqa serîlêdanê de hûn xwe bispêrin nexşeyek parvekirina taybetî, ku ev xerîdar li ser şikilek wusa û wusa ye, û daxwaz dikare rasterast li wir were şandin, ne ji tabloya Belavkirî. An jî hûn guhertoyek pir nû ya ClickHouse bikar tînin û mîhengê çalak kirine optîmîze bike ku şûşeyên neyên bikaranîn derbas bike. Di vê rewşê de, di dema lêpirsîna hilbijartî de, dê îfadeya di beşa ku derê de were analîz kirin û dê were hesibandin ku li gorî nexşeya parvekirinê divê kîjan şûşeyan were bikar anîn. Ev kar dike bi şertê ku dane tam li gorî vê pilana parvekirinê were dabeş kirin. Ger we wan bi destan ji nû ve saz kir, dibe ku hevpeyivîn biguhere.
Ji ber vê yekê ev rêbazek hejmar yek e. Û ez li benda bersiva we me, gelo rêbaz guncan e, an jî em bimeşin.
Vladîmîr Kolobaev, rêveberê pergalê li Avito: Alexey, rêbaza ku we behs kir dema ku hûn hewce ne ku bar belav bikin, tevî xwendinê, pir baş naxebite. Em dikarin dabeşek ku mehane ye û dikare meha berê bigihîne nodek din, lê gava ku daxwazek ji bo vê daneyê were, em ê tenê wê bar bikin. Lê em dixwazin tevahiya komê bar bikin, ji ber ku wekî din, ji bo demekê dê tevahiya barkirina xwendinê ji hêla du perçeyan ve were hilberandin.
Alexey Milovidov: Bersiv li vir xerîb e - erê, ew xirab e, lê dibe ku ew bixebite. Ez ê tam rave bikim ka çawa. Hêja ye ku li senaryoya barkirinê ya ku li pişt daneyên we tê binêre. Ger ev daneyên çavdêriyê ye, wê hingê em hema bêje bê guman dikarin bibêjin ku pirraniya daxwaziyan ji bo daneyên nû ne.
We serverên nû saz kirin, dabeşên kevn koç kirin, lê di heman demê de guheztin ka çawa daneyên nû têne tomar kirin. Û daneyên nû dê li seranserê komê belav bibin. Bi vî rengî, tenê piştî pênc hûrdeman, daxwazên ji bo pênc deqeyên paşîn dê komê bi rengek wekhev bar bikin; piştî rojekê, daxwazên XNUMX demjimêran dê komê bi rengek wekhev bar bikin. Û daxwazên meha berê, mixabin, dê tenê biçin beşek ji pêşkêşkerên komê.
Lê pir caran hûn ê daxwazên bi taybetî ji bo Sibata 2019-an nebin. Bi îhtîmalek mezin, ger daxwaz bikevin sala 2019-an, wê hingê ew ê ji bo tevahiya 2019-an bin - ji bo demek mezin, û ne ji bo hin rêzek piçûk. Û daxwazên weha dê di heman demê de karibin komê bi rengek wekhev bar bikin. Lê bi gelemperî, têbîniya we bi tevahî rast e ku ev çareseriyek ad hoc e ku daneyan bi tevahî yeksan belav nake.
Çend xalên min ên din hene ku bersiva pirsê bidim. Yek ji wan ew e ku meriv çawa di destpêkê de nexşeyek şûştinê dîzayn dike da ku ji nû ve parvekirin bibe sedema êşek kêmtir. Ev her tim ne gengaz e.
Mînakî, we daneyên çavdêriyê hene. Daneyên çavdêriyê ji ber sê sedeman mezin dibin. Ya yekem komkirina daneyên dîrokî ye. Ya duyemîn mezinbûna trafîkê ye. Û ya sêyemîn jî zêdebûna hejmara tiştên ku di bin çavdêriyê de ne. Microservices û metrîkên nû hene ku divê bêne xilas kirin.
Dibe ku ji van, mezinbûna herî mezin bi sedema sêyemîn ve girêdayî ye - zêdebûna karanîna çavdêriyê. Û di vê rewşê de, hêja ye ku meriv li xwezaya barkirinê binêre, pirsên bijartî yên sereke çi ne. Pirsên hilbijartî yên bingehîn bi îhtîmalek mezin dê li ser bingeha hin binkomê metrîkan bin.
Mînakî, karanîna CPU li ser hin serveran ji hêla hin karûbar ve. Derket holê ku hin binkokên ku hûn vê daneyê digirin hene. Û daxwaziya xwe ji bo vê daneyê bi îhtîmalek pir hêsan e û di deh milliseconan de tê qedandin. Ji bo çavdêriya karûbar û tabloyan tê bikar anîn. Ez hêvî dikim ku ez vê yekê rast fêm bikim.
Vladimir Kolobaev: Rastî ev e ku em gelek caran serî li daneyên dîrokî didin, ji ber ku em rewşa heyî bi ya dîrokî re di wextê rast de didin ber hev. Û ji me re girîng e ku zû bigihîjin hejmarek mezin a daneyan, û ClickHouse bi vê yekê re karekî hêja dike.
Hûn bi rastî rast in, em di roja paşîn de, mîna her pergalên çavdêriyê, piraniya daxwazên xwendinê diceribînin. Lê di heman demê de, barê daneyên dîrokî jî pir mezin e. Ew di bingeh de ji pergalek hişyariyê ye ku her sî saniyeyekê li dora xwe digere û ji ClickHouse re dibêje: “Daneyên şeş hefteyên dawî bide min. Naha ji min re celebek navînî ji wan ava bikin, û werin em nirxa heyî bi ya dîrokî re bidin ber hev."
Ez dixwazim bibêjim ku ji bo daxwazên weha yên herî dawî me tabloyek piçûkek din heye ku em tê de tenê du rojan dane hilînin, û daxwazên sereke di nav wê de diherikin. Em tenê pirsên dîrokî yên mezin dişînin ser tabloya mezin a perçekirî.
Alexey Milovidov: Mixabin, ew ji bo senaryoya we nebaş tê sepandin, lê ez ê ji we re ravekirina du pileyên parvekirina xirab û tevlihev ên ku ne hewce ne ku werin bikar anîn, lê di karûbarê hevalên min de têne bikar anîn vebêjim.
Bi bûyerên Yandex.Metrica re komek sereke heye. Bûyer dîtinên rûpelê, klîk û veguhertin in. Pir daxwazî diçin malperek taybetî. Hûn karûbarê Yandex.Metrica vedikin, malperek we heye - avito.ru, diçin raporê, û daxwazek ji bo malpera we tê kirin.
Lê daxwazên din hene - analîtîk û gerdûnî - ku ji hêla analîstên navxweyî ve têne kirin. Tenê di rewşê de, ez destnîşan dikim ku vekolerên navxweyî tenê ji bo karûbarên Yandex daxwazan dikin. Lê dîsa jî, tewra karûbarên Yandex jî beşek girîng a hemî daneyan digire. Ev daxwaz ne ji bo jimarvanên taybetî, lê ji bo fîlterkirinek berfireh in.
Meriv çawa daneyan bi vî rengî organîze dike ku her tişt ji bo yek jimarvan, û pirsên gerdûnî jî bi bandor bixebite? Zehmetiyek din jî ev e ku hejmara daxwazên li ClickHouse ji bo koma Metrics çend hezar di çirkeyê de ye. Di heman demê de, serverek ClickHouse nikare daxwazên ne-taybetî hilgire, mînakî, çend hezar di çirkeyê de.
Mezinahiya komê şeş sed-tiştek server e. Ger hûn bi tenê tabloyek Dabeşkirî li ser vê komê bikişînin û çend hezar daxwazan li wir bişînin, ew ê ji şandina wan ji yek serverek re hîn xirabtir bibe. Ji hêla din ve, vebijarka ku dane bi rengek wekhev têne belav kirin, û em diçin û ji hemî serveran daxwaz dikin, tavilê tê rakirin.
Vebijêrkek ku bi diametralkî berevajî ye heye. Bifikirin ku em daneyan di nav malperan de parve bikin, û daxwazek ji bo yek malperê diçe yek perçek. Naha kom dê karibe deh hezar daxwazan di çirkekê de bi rê ve bibe, lê li ser yek perçeyek yek daxwazek dê pir hêdî bixebite. Ew ê êdî di warê karûbarê de pîvaz nebe. Bi taybetî heke ev malper avito.ru ye. Ger ez bibêjim Avito yek ji wan malperên herî serdankirî yên RuNet-ê ye, ez ê sirê eşkere nekim. Û pêvajokirina wê li ser yek perçek dê dînbûn be.
Ji ber vê yekê, pilana parvekirinê bi rengek bikêrtir hatî sêwirandin. Tevahiya komê di nav çend koman de dabeş dibe, ku em jê re dibêjin qat. Her komik ji dehan heta çend deh şitlan dihewîne. Bi tevahî sî û neh komên weha hene.
Ev hemû pîvan çawa ye? Hejmara koman naguhere - wekî çend sal berê sî û neh bû, wusa dimîne. Lê di hundurê her yek ji wan de, gava ku em daneyan berhev dikin, em hêdî hêdî hejmara şûşeyan zêde dikin. Û plana parvekirinê bi tevahî wiha ye: ev kom li ser malperan têne dabeş kirin, û ji bo ku were fam kirin ka kîjan malper li ser kîjan komê ye, di MySQL de metabasek cihêreng tê bikar anîn. Yek malper - li ser yek komê. Û di hundurê wê de, parvekirin li gorî nasnameyên mêvanan pêk tê.
Dema tomarkirinê, em wan bi dabeşkirina nasnama mêvanê mayî ve dabeş dikin. Lê dema ku şaxek nû lê zêde bike, pilana parvekirinê diguhere; em dabeşbûnê didomînin, lê bi dabeşkirina mayî bi hejmareke din re. Ev tê vê wateyê ku yek serdan jixwe li ser çend serveran cih digire, û hûn nekarin xwe bispêrin vê. Ev bi tenê tê kirin da ku pê ewle bibe ku dane çêtir têne berhev kirin. Û dema ku daxwazan dikin, em diçin tabloya Belavkirî, ku li komê dinêre û bi dehan pêşkêşkeran digihîne. Ev planeke wisa ehmeqî ye.
Lê ger ez nebêjim ku me dev ji vê planê berdaye dê çîroka min temam nebe. Di pilana nû de, me her tişt guhert û hemî daneyan bi karanîna clickhouse-copier kopî kir.
Di pilana nû de, hemî malper li du kategoriyan têne dabeş kirin - mezin û piçûk. Ez nizanim ku bend çawa hate hilbijartin, lê encam ev e ku malperên mezin li ser yek komê têne tomar kirin, ku li wir 120 şûşe hene ku her yek jê sê replica hene - ango 360 pêşkêşker. Û plana şûştinê wisa ye ku her daxwazek di yekcarê de diçe hemî şûşeyan. Ger hûn niha rûpelek raporê ji bo avito.ru li Yandex.Metrica vekin, daxwaz dê biçin 120 pêşkêşkeran. Di RuNet de çend malperên mezin hene. Û daxwaz di çirkeyê de ne hezar in, ji sed jî kêmtir in. Hemî ev ji hêla tabloya Belavkirî ve, ku her yek ji wan bi 120 pêşkêşkeran re pêvajoyê dike, bi bêdengî tê xwar.
Û koma duyemîn ji bo malperên piçûk e. Li vir nexşeyek parvekirinê ye ku li ser bingeha nasnameya malperê ye, û her daxwazek tam bi yek şiklê diçe.
ClickHouse xwedan amûrek klîk-kopîker e. Tu dikarî ji me re behsa wê bikî?
Ez ê di cih de bibêjim ku ev çareserî bikêrtir e û hinekî kêm berhemdar e. Awantaj ev e ku ew daneyan bi tevahî li gorî şêwaza ku hûn diyar dikin dişewitîne. Lê kêmasiya kargêriyê ev e ku ew qet ji nû ve nayê rijandin. Ew daneyan ji şemayek komê berbi şemek komê din kopî dike.
Ev tê vê wateyê ku ji bo ku ew bixebite divê hûn du koman hebin. Ew dikarin li ser heman serveran bêne bicîh kirin, lê, di heman demê de, dane dê zêde neyên guheztin, lê dê bêne kopî kirin.
Mînakî, çar server hebûn, niha heşt hene. Hûn li ser hemî pêşkêşkeran, tabloyên nû yên herêmî tabloyek Dabeşkirî ya nû diafirînin û klîk-kopîkerê didin destpêkirin, di wê de nexşeya xebatê destnîşan dikin ku divê ew ji wir bixwîne, nexşeya nû ya parvekirinê qebûl bike û daneyan li wir veguhezîne. Û li ser serverên kevn hûn ê ji ya nuha yek û nîv carî bêtir cîh hewce bikin, ji ber ku daneyên kevn divê li ser wan bimînin, û nîvê heman daneya kevn dê bigihîje serê wan. Ger we berê difikirî ku dane pêdivî ye ku ji nû ve were guheztin û cîh heye, wê hingê ev rêbaz guncan e.
Çawa clickhouse-copier di hundurê de dixebite? Ew hemî karan di nav komek peywiran de vediqetîne da ku yek dabeşkirina yek tabloyê li ser yek şiklê hilîne. Van hemî peywiran dikarin bi paralelî bêne darve kirin, û clickhouse-copier dikare li ser makîneyên cihêreng di gelek mînakan de were xebitandin, lê ya ku ew ji bo yek dabeşkirinê dike ji bilî hilbijarkek têxe ne tiştek din e. Daneyên têne xwendin, dakêşandin, ji nû ve têne dabeş kirin, paşê dîsa têne kom kirin, li cîhek têne nivîsandin û ji nû ve têne rêz kirin. Ev biryareke dijwartir e.
Tiştek pîlotê we hebû ku jê re digotin reşarding. Çi bi wê re?
Di sala 2017-an de, we tiştek pilotek bi navê resharding hebû. Di ClickHouse de vebijarkek jî heye. Wekî ku ez têdigihim, ew derneket. Tu dikarî ji min re bibêjî çima ev yek çêbû? Ew xuya dike ku pir têkildar e.
Tevahiya pirsgirêk ev e ku ger hewce be ku daneyan di cîh de ji nû ve were guheztin, ji bo ku ev bi atomî were kirin hevdengiyek pir tevlihev hewce ye. Dema ku me dest bi nihêrîna ku ev hevdengkirin çawa dixebite, eşkere bû ku pirsgirêkên bingehîn hene. Û ev pirsgirêkên bingehîn ne tenê teorîk in, lê tavilê dest pê kirin ku xwe di pratîkê de di forma tiştek ku pir bi hêsanî were ravekirin - nîşan bidin - tiştek naxebite.
Ma gengaz e ku meriv hemî perçeyên daneyê bi hev re bike yek berî ku ew berbi dîskên hêdî bikişîne?
Pirsa di derbarê TTL-ê de digel veguheztina berbi vebijarka dîskê hêdî di çarçoweya yekbûnê de. Ma rêyek heye, ji xeynî bi riya cron, ku meriv hemî beşan di yek de bike yek berî ku wan biguhezîne dîskên hêdî?
Bersiva pirsê mimkun e ku meriv bi rengek bixweber hemî perçeyan berî veguheztina wan bike yek - na. Ez nafikirim ku ev pêdivî ye. Ne hewce ye ku hûn hemî beşan li yek yek bikin, lê tenê li ser vê yekê hesab bikin ku ew ê bixweber li dîskên hêdî werin veguheztin.
Ji bo qaîdeyên veguhestinê du pîvanên me hene. Ya yekem wekî ku tê dagirtin e. Ger asta hilanînê ya heyî ji sedî hin cîhê belaş kêmtir be, em perçeyek hilbijêrin û wê diguhezînin hilanîna hêdîtir. An jî, ne hêdîtir, lê ya din - wekî ku hûn mîheng dikin.
Pîvana duyemîn mezinahî ye. Ew li ser barkirina perçeyên mezin e. Hûn dikarin li gorî cîhê belaş a li ser dîskê bilez veqetînin, û data dê bixweber werin veguheztin.
Meriv çawa koçî guhertoyên nû yên ClickHouse dike ger rêyek tune ku pêşî lihevhatina kontrol bike?
Ev mijar bi rêkûpêk tê nîqaş kirin guhertoyên cûda li ber çavan digirin, û hîn jî. Nûvekirina ji guhertoya 19.11 ber 19.16 û, mînakî, ji 19.16 ber 20.3 çiqas ewle ye. Awayê çêtirîn ji bo koçkirina guhertoyên nû çi ye bêyî ku meriv pêşî lihevhatina di sandboxê de kontrol bike?
Li vir çend qaîdeyên "zêrîn" hene. Yekem - . Ew mezin e, lê di derheqê guheztinên paşverû yên nehevgirtî de paragrafên cihê hene. Van xalan wek ala sor nekin. Vana bi gelemperî nelihevhatinên piçûk in ku hin fonksiyonên qeraxê yên ku hûn bi îhtîmalek mezin bikar neynin vedihewîne.
Ya duyemîn, heke rê tune ku meriv lihevhatina di sandboxê de kontrol bike, û hûn dixwazin di hilberînê de tavilê nûve bikin, pêşniyar ev e ku hûn ne hewce ne ku vê yekê bikin. Pêşî sandboxek çêbikin û ceribandin. Ger hawîrdora ceribandinê tune be, wê hingê bi îhtîmalek we pargîdaniyek pir mezin tune, ku tê vê wateyê ku hûn dikarin hin daneyan li laptopa xwe kopî bikin û pê ewle bibin ku her tişt li ser wê rast dixebite. Tewra hûn dikarin li ser makîneya xwe gelek kopiyên herêmî bilind bikin. An jî hûn dikarin guhertoyek nû li deverek nêzîk hilbijêrin û hin daneyan li wir bar bikin - ango, hawîrdorek ceribandinê ya xwerû biafirînin.
Rêgezek din ev e ku hûn hefteyek piştî berdana guhertoyê ji ber girtina xeletiyên di hilberînê û dûv re rastkirinên bilez de nûve nekin. Ka em jimareya guhertoyên ClickHouse-ê fam bikin da ku tevlihev nebin.
Guhertoya 20.3.4 heye. Hejmara 20 sala çêkirinê nîşan dide - 2020. Ji nihêrîna ku di hundurê de ye, ev ne girîng e, ji ber vê yekê em ê guh nedin wê. Piştre - 20.3. Em hejmara duyemîn zêde dikin - di vê rewşê de 3 - her carê ku em serbestberdanek bi hin fonksiyonên nû derdixin. Ger em bixwazin hin taybetmendiyê li ClickHouse zêde bikin, divê em vê hejmarê zêde bikin. Ango, di guhertoya 20.4 de ClickHouse dê hê çêtir bixebite. Reqema sêyem 20.3.4 e. Li vir 4 hejmara serbestberdana patchê ye ku tê de me taybetmendiyên nû lê zêde nekir, lê hin xeletî rast kirin. Û 4 tê vê wateyê ku me çar caran kir.
Nefikirin ku ev tiştek tirsnak e. Bi gelemperî bikarhêner dikare guhertoya herî paşîn saz bike û ew ê her sal bêyî pirsgirêk bi dema xebatê re bixebite. Lê bifikire ku di hin fonksiyonên ji bo pêvajokirina bitmapsê de, ku ji hêla hevalên me yên Chineseînî ve hatî zêdekirin, server dema ku argumanên çewt derbas dike têk diçe. Berpirsiyariya me heye ku em vê rast bikin. Em ê guhertoyek patchek nû derxînin û ClickHouse dê aramtir bibe.
Ger we ClickHouse di hilberînê de dimeşe, û guhertoyek nû ya ClickHouse bi taybetmendiyên zêde derdikeve - mînakî, 20.4.1 ya yekem e, lez nekin ku wê di roja yekem de bixin nav hilberînê. Çima ew jî hewce ye? Heke hûn jixwe ClickHouse bikar neynin, wê hingê hûn dikarin wê saz bikin, û bi îhtîmalek mezin dê her tişt baş be. Lê heke ClickHouse jixwe bi îstîqrar kar dike, wê hingê çavê xwe li paç û nûvekirinan bigirin da ku bibînin ka em çi pirsgirêkan rast dikin.
Kirill Shvakov: Ez dixwazim hinekî li ser hawîrdorên ceribandinê zêde bikim. Her kes ji hawîrdorên ceribandinê pir ditirse û ji ber hin sedeman ew bawer dikin ku heke we komek ClickHouse pir mezin hebe, wê hingê divê hawîrdora ceribandinê ne kêmtir an bi kêmî ve deh carî piçûktir be. Qet ne wisa ye.
Ez dikarim ji mînaka xwe ji we re bibêjim. Projeyek min heye, û ClickHouse heye. Jîngeha ceribandina me tenê ji bo wî ye - ev makîneyek piçûk a virtual li Hetzner bi bîst euro ye, ku bê guman her tişt tê bicîh kirin. Ji bo kirina vê yekê, me di Ansible de xwedan otomasyona tam heye, û ji ber vê yekê, di prensîbê de, ferq nake ku em biçin ku derê - pêşkêşkerên hardware an tenê di makîneyên virtual de bicîh bikin.
Çi dikare bê kirin? Dê xweş be ku meriv di belgeya ClickHouse-ê de mînakek peyda bike ka meriv çawa komek piçûk li mala xwe bicîh dike - li Docker, li LXC, dibe ku pirtûkek lîstika Ansible biafirîne, ji ber ku mirovên cihêreng xwedan sazkirinên cihê ne. Ev ê pir hêsan bike. Gava ku hûn di pênc hûrdeman de komekê digirin û bicîh dikin, pir hêsantir e ku hûn hewl bidin ku tiştek fêm bikin. Ev pir hêsantir e, ji ber ku gêrkirina nav guhertoyek hilberandinê ya ku we ceribandî nekiriye rêyek berbi cîhê ye. Carinan kar dike û carinan jî nake. Û ji ber vê yekê, hêviya serkeftinê xirab e.
Maxim Kotyakov, endezyarê payebilind Avito: Ez ê di derheqê hawîrdorên ceribandinê de ji rêzek pirsgirêkên ku ji hêla pargîdaniyên mezin ve rû bi rû dimînin hinekî zêde bikim. Me komek pejirandina ClickHouse ya bêkêmasî heye; di warê nexşe û mîhengên daneyê de, ew kopiyek rastîn a tiştê ku di hilberînê de ye ye. Ev kom di nav konteynerên bi kêmasî yên bi hindiktirîn çavkaniyan de tê bicîh kirin. Em rêjeyek diyarkirî ya daneyên hilberînê li wir dinivîsin, bi bextewarî gengaz e ku em di Kafka de tîrêjê dubare bikin. Her tişt li wir hevdem û pîvan e - hem di warê kapasîteyê û herikînê de, hem jî, di teoriyê de, hemî tiştên din wekhev in, divê ew di warê metrîkê de mîna hilberînê tevbigere. Her tiştê potansiyel teqemenî pêşî li ser vê standê tê gerandin û heya ku amade bibe çend rojan li wir tê hiştin. Lê bi xwezayî, ev çareserî biha ye, dijwar e û lêçûnên piştgiriyê ne-sifir e.
Alexey Milovidov: Ez ê ji we re bibêjim ku hawîrdora ceribandinê ya hevalên me ji Yandex.Metrica çawa ye. Komek 600 pêşkêşkerên cewherî hebûn, ya din jî 360 bû, û komek sêyem û çend kom hene. Jîngeha ceribandinê ji bo yek ji wan bi tenê du şûşe ye ku di her yekê de du replica hene. Çima du qirş? Da ku hûn ne tenê ne. Û divê replica jî hebin. Tenê mîqdarek hindiktirîn a ku hûn dikarin bidin.
Vê hawîrdora ceribandinê dihêle hûn kontrol bikin ka pirsên we dixebitin û gelo tiştek girîng şikestiye. Lê pir caran pirsgirêk ji cewherek bi tevahî cûda derdikevin, dema ku her tişt dixebite, lê di barkirinê de hin guhertinên piçûk hene.
Ez ji we re mînakek bidim. Me biryar da ku guhertoyek nû ya ClickHouse saz bikin. Ew li ser hawîrdorek ceribandinê hate şandin, ceribandinên otomatîkî di Yandex.Metrica bixwe de hatine qedandin, ku daneyên li ser guhertoya kevn û ya nû dide ber hev û tevahiya boriyê dimeşîne. Û bê guman, ceribandinên kesk ên CI-ya me. Wekî din me ê vê versiyonê jî pêşniyar nekira.
Her tişt baş e. Em dest bi hilberînê dikin. Ez peyamek distînim ku barkirina li ser grafikan çend caran zêde bûye. Em guhertoyê paşde vedigerînin. Ez li grafîkê mêze dikim û dibînim: barkirin bi rastî çend caran di dema avêtinê de zêde bû, û gava ku ew derketin paşde kêm bû. Dûv re me dest bi vegerandina guhertoyê kir. Û bar jî bi heman awayî zêde bû û bi heman awayî paşda ket. Ji ber vê yekê encam ev e: bar ji ber sêwiranê zêde bûye, ne tiştek ecêb e.
Dûv re dijwar bû ku hevalan razî bikin ku guhertoya nû saz bikin. Ez dibêm: “Baş e, derkeve. Tiliyên xwe li hev bihêlin, her tişt dê bixebite. Naha barkirina li ser grafikan zêde bûye, lê her tişt baş e. Li wir bisekinin." Bi gelemperî, me ev kir, û ew e - guhertoya ji bo hilberînê hate berdan. Lê hema hema bi her sêwiranê re pirsgirêkên weha derdikevin.
Kill Query tê xwestin ku pirsan bikuje, lê ew nake. Çima?
Bikarhênerek, celebek analîstek, hat ba min û daxwazek çêkir ku koma ClickHouse-a min danî. Hin girêk an tevahiya komê, li gorî ku daxwaz çûye kîjan replica an perçeyê. Ez dibînim ku hemî çavkaniyên CPU-yê li ser vê serverê di refê de ne, her tişt sor e. Di heman demê de, ClickHouse bixwe bersiva daxwazan dide. Û ez dinivîsim: "Ji kerema xwe nîşanî min bidin, navnîşa pêvajoyê, kîjan daxwazî ev dînbûn çêkir."
Ez vê daxwazê dibînim û jê re kuştinê dinivîsim. Û ez dibînim ku tiştek nabe. Pêşkêşkara min di refê de ye, ClickHouse dûv re hin fermanan dide min, nîşan dide ku server sax e, û her tişt pir xweş e. Lê min di hemî daxwazên bikarhêneran de hilweşandin heye, hilweşandin bi tomarên li ClickHouse dest pê dike, û pirsa kuştina min nexebite. Çima? Min fikir kir ku pirsa kuştinê diviya bû ku pirsan bikuje, lê ew nake.
Niha dê bersivek pir ecêb hebe. Mesele ev e ku pirsa kuştinê pirsan nakuje.
Kill query qutiyek piçûk a bi navê "Ez dixwazim ev pirs were kuştin" kontrol dike. Û daxwaz bixwe dema ku her blokek pêvajoyê dike li vê alê dinêre. Ger ew were danîn, daxwaz kar disekine. Derket holê ku kes daxwazê nakuje, divê ew bi xwe her tiştî kontrol bike û raweste. Û ev pêdivî ye ku di hemî rewşên ku daxwaz di rewşa hilanîna blokên daneyê de ye de bixebite. Ew ê bloka paşîn a daneyê pêvajoyê bike, ala kontrol bike û bisekine.
Ev di rewşên ku daxwaz li ser hin operasyonan tê asteng kirin de kar nake. Rast e, bi îhtîmaleke mezin ev ne doza we ye, ji ber ku, li gorî we, ew tonek çavkaniyên serverê bikar tîne. Mimkûn e ku ev yek di mijara dabeşkirina derveyî û di hin hûrguliyên din de nexebite. Lê bi gelemperî divê ev nebe, ev xeletiyek e. Û tenê tiştê ku ez dikarim pêşniyar bikim nûvekirina ClickHouse ye.
Meriv çawa dema bersivê di bin barê xwendinê de hesab dike?
Tabloyek heye ku berhevokên tiştan hildide - hejmarên cihêreng. Hejmara rêzan bi qasî sed mîlyon e. Ger hûn 1K RPS ji bo 1K tiştan birijînin gelo gengaz e ku meriv li ser demek bersivê ya pêşbînîkirî hesab bike?
Li gorî çarçoweyê dadbar kirin, em li ser barkirina xwendinê diaxivin, ji ber ku di nivîsandinê de pirsgirêk tune - tewra hezar, hetta sed hezar, û carinan jî çend mîlyon rêz dikarin werin danîn.
Daxwazên xwendinê pir cûda ne. Di hilbijartina 1-ê de, ClickHouse dikare di çirkeyê de bi deh hezaran daxwazan pêk bîne, ji ber vê yekê jî daxwazên yek mifteyê dê jixwe hin çavkaniyan hewce bike. Û pirsên xalên weha dê ji hin databasên key-nirxê dijwartir bin, ji ber ku ji bo her xwendinê pêdivî ye ku meriv bloka daneyê bi navnîşan were xwendin. Indeksa me ne her tomar, lê her rêzek navnîşan dike. Ango, hûn neçar in ku tevahiya rêzê bixwînin - ev 8192 rêzikên xwerû ye. Û hûn neçar in ku bloka daneya pêçandî ji 64 KB berbi 1 MB veqetînin. Bi gelemperî, pirsên weha armanckirî çend millisecond digirin ku temam bibin. Lê ev bijareya herî hêsan e.
Werin em hin hejmarên hêsan biceribînin. Ger hûn çend mîlîçirkeyan bi hezarî zêde bikin, hûn çend saniyeyan distînin. Mîna ku ne gengaz e ku meriv serê saniyeyê bi hezar daxwazî de bidomîne, lê di rastiyê de ew gengaz e, ji ber ku me çend navgînên pêvajoyê hene. Ji ber vê yekê, di prensîbê de, ClickHouse carinan dikare 1000 RPS bigire, lê ji bo daxwazên kurt, bi taybetî yên armanckirî.
Heke hûn hewce ne ku komek ClickHouse li gorî hejmara daxwazên hêsan pîvandin, wê hingê ez tiştê herî hêsan pêşniyar dikim - hejmara kopiyan zêde bikin û daxwazan ji kopiyek rasthatî re bişînin. Ger yek replica di çirkekê de pênc sed daxwazan bigire, ku bi tevahî rast e, wê hingê sê kopiyek dê hezar û nîvek bişopînin.
Carinan, bê guman, hûn dikarin ClickHouse-ê ji bo hejmara herî zêde ya xwendinên xalê mîheng bikin. Ji bo vê çi hewce ye? Ya yekem ev e ku meriv granularbûna îndeksê kêm bike. Di vê rewşê de, pêdivî ye ku ew ne yek yek were kêm kirin, lê li ser bingeha ku hejmara navnîşan di navnîşan de dê ji her serverek çend mîlyon an bi deh mîlyonan be. Ger tablo sed mîlyon rêz hebin, wê hingê hûrgulî dikare bibe 64.
Hûn dikarin mezinahiya bloka pêçandî kêm bikin. Ji bo vê yekê mîheng hene mezinahiya blokê ya hûrgelê ya min, mezinahiya blokê ya herî zêde. Ew dikarin bêne kêm kirin, bi daneyan ji nû ve werin dagirtin, û dûv re dê pirsên armanckirî zûtir bibin. Lê dîsa jî, ClickHouse ne databasek key-nirx e. Hejmarek mezin a daxwazên piçûk antîpatternek barkirinê ye.
Kirill Shvakov: Ger li wir hesabên asayî hebin ez ê şîretan bikim. Dema ku ClickHouse cûreyek jimarvan hildide ev rewşek pir standard e. Bikarhênerek min heye, ew ji welatek wusa û wusa ye, û ji qada sêyemîn e, û ez hewce dikim ku tiştek zêde zêde bikim. MySQL bigirin, mifteyek yekta çêbikin - di MySQL de ew mifteyek dubare ye, û di PostgreSQL de ew nakokî ye - û nîşanek plus lê zêde bikin. Ev ê pir çêtir bixebite.
Gava ku hûn pir dane nebin, di karanîna ClickHouse de pir xal tune. Daneyên birêkûpêk hene û ew vê yekê baş dikin.
Ez dikarim çi di ClickHouse de tweak bikim da ku bêtir dane di cache de bin?
Ka em rewşek xeyal bikin - server xwedan 256 GB RAM in, di rûtîniya rojane de ClickHouse bi qasî 60-80 GB digire, di lûtkeyê de - heya 130. Çi dikare were çalak kirin û birêkûpêk kirin da ku bêtir dane di cache de bin û, li gorî vê, rêwîtiyên kêmtir li ser dîskê hene?
Bi gelemperî, cache rûpela pergala xebitandinê vê yekê baş dike. Ger hûn tenê jor vekin, li wir cached an belaş binihêrin - ew jî dibêje ka çiqas cache ye - wê hingê hûn ê bibînin ku hemî bîranîna belaş ji bo cache-ê tê bikar anîn. Û dema xwendina vê daneyê, ew ê ne ji dîskê, lê ji RAM-ê were xwendin. Di heman demê de, ez dikarim bibêjim ku cache bi bandor tê bikar anîn ji ber ku ew daneya pêçandî ye ku tê girtin.
Lêbelê, heke hûn dixwazin hin pirsên hêsan hê bêtir bilezînin, mimkun e ku meriv cache di daneyên dakêşandî yên hundurê ClickHouse de çalak bike. Tê gotin cache nekompressed. Di pela veavakirinê de config.xml, mezinahiya cache-ya nekompresandî li gorî nirxa ku hûn hewce ne destnîşan bikin - ez ji nîvê RAM-a belaş bêtir pêşniyar dikim, ji ber ku yên mayî dê di binê cacheya rûpelê de biçin.
Wekî din, du mîhengên asta daxwazê hene. Mîhenga yekem - cache-ê nekompresandî bikar bînin - bikaranîna wê dihewîne. Tête pêşniyar kirin ku ew ji bo hemî daxwazan çalak bikin, ji bilî yên giran, ku dikarin hemî daneyan bixwînin û cache-ê bişon. Û mîhenga duyemîn tiştek wekî hejmara herî zêde ya rêzan e ku meriv cache bikar bîne. Ew bixweber pirsên mezin sînordar dike da ku ew cache derbas bikin.
Ez çawa dikarim storage_configuration ji bo hilanînê di RAM-ê de mîheng bikim?
Di belgeya nû ya ClickHouse de min beşa têkildar xwend . Danasîn mînakek bi SSD-ya bilez heye.
Ez meraq dikim ka heman tişt çawa dikare bi bîranîna germê ya volume-yê re were mîheng kirin. Û pirsek din. Hilbijartina bi vê rêxistina daneyê re çawa dixebite, ew ê tevahî komê an tenê ya ku li ser dîskê ye bixwîne, û gelo ev dane di bîranînê de tê berhev kirin? Û beşa prewhere çawa bi rêxistinek daneya wusa re dixebite?
Ev mîheng bandorê li hilanîna perçeyên daneyê dike, û formata wan bi tu awayî nayê guhertin.
Werin em ji nêzîk ve lê binêrin.
Hûn dikarin hilanîna daneyê di RAM-ê de mîheng bikin. Tiştê ku ji bo dîskê hatî mîheng kirin riya wê ye. Hûn dabeşek tmpfs-ê ku di pergala pelan de li hin rêgezek hatî danîn diafirînin. Hûn vê rêyê wekî riya hilanîna daneyan ji bo dabeşkirina herî germ destnîşan dikin, perçeyên daneyê dest pê dikin ku digihîjin û li wir têne nivîsandin, her tişt baş e.
Lê ez kirina vê yekê ji ber pêbaweriya kêm pêşniyar nakim, her çend heke we bi kêmî ve sê kopiyên li navendên daneyên cihêreng hebin, wê hingê ew gengaz e. Ger tiştek biqewime, dê dane were sererast kirin. Werin em bifikirin ku server ji nişka ve hate girtin û vegerandin. Parvekirin dîsa hate çêkirin, lê tiştek li wir tune bû. Dema ku servera ClickHouse dest pê dike, ew dibîne ku ew van perçeyan tune, her çend, li gorî metadata ZooKeeper, divê ew li wir bin. Ew li kîjan kopiyên wan hene dinêre, wan daxwaz dike û wan dadixe. Bi vî rengî dê dane bêne vegerandin.
Di vê wateyê de, hilanîna daneyan di RAM-ê de bi bingehîn ji hilanîna wê li ser dîskê ne cûda ye, ji ber ku dema ku dane li ser dîskê têne nivîsandin, ew di heman demê de pêşî di cache rûpelê de diqede û paşê bi fîzîkî tê nivîsandin. Ev bi vebijarka sazkirina pergala pelê ve girêdayî ye. Lê di her rewşê de, ez ê bibêjim ku ClickHouse dema têxe senkronîze nake.
Di vê rewşê de, daneyên di RAM-ê de tam di heman formatê de wekî li ser dîskê têne hilanîn. Pirsa hilbijartî bi heman rengî perçeyên ku divê werin xwendin hildibijêre, rêzikên daneya pêwîst di perçeyan de hildibijêre û wan dixwîne. Û prewhere bi heman rengî dixebite, bêyî ku daneyên di RAM-ê de an li ser dîskê bûn.
Cardinality Kêm bi çend hejmarên nirxên bêhempa bandorker e?
Cardinality Low bi jîr hatiye dîzaynkirin. Ew ferhengên daneyan berhev dike, lê ew herêmî ne. Ya yekem, ji bo her perçeyê ferhengên cûda hene, û ya duyemîn jî, di nav yek perçeyê de jî ew dikarin ji bo her rêzek cûda bin. Dema ku jimara nirxên bêhempa digihîje jimareyek - mîlyonek, ez difikirim - ferheng bi hêsanî tê hilanîn û ferhengek nû tê afirandin.
Bersiv bi gelemperî ev e: ji bo her rêzek herêmî - bêje, ji bo her rojê - li deverek heya mîlyonek nirxên bêhempa Kardînaliya kêm bandorker e. Dûv re dê bi tenê paşverokek hebe, ku tê de gelek ferhengên cûda dê werin bikar anîn, ne tenê yek. Ew ê bi qasî stûnek rêzek birêkûpêk bixebite, dibe ku hinekî kêmtir bikêrhatî be, lê dê xirabûna performansa ciddî nebe.
Ji bo lêgerîna tabloyek bi pênc mîlyar rêzan pratîkên çêtirîn çi ne?
Bersivên cuda hene. Ya yekem ev e ku meriv bibêje ku ClickHouse ne motorek lêgerînê ya tevahî-text e. Ji bo vê pergalên taybetî hene, mînakî, и . Lêbelê, ez her ku diçe mirovan dibînim ku ew ji Elasticsearch veguherînin ClickHouse.
Çima ev dibe? Ew vê yekê bi vê yekê rave dikin ku Elasticsearch bi avakirina îndeksan dest pê dike ku bi barkirinê re li hin cildan radiweste. Indeks pir giran dibin, û heke hûn tenê daneyan li ClickHouse veguhezînin, derdikeve holê ku ew di warê qebareyê de çend caran bi bandor têne hilanîn. Di heman demê de, pirsên lêgerînê bi gelemperî ne wusa bûn ku hewce bû ku di tevahiya hêjeya daneyê de hin hevokan bibînin, li gorî morfolojiyê, lê yên bi tevahî cûda. Mînakî, di çend demjimêrên paşîn de hin rêzikên byteyan di têketinê de bibînin.
Di vê rewşê de, hûn di ClickHouse de indexek çêdikin, qada yekem a ku dê tarîx û dem be. Û qutkirina daneya herî mezin dê li ser bingeha rêza tarîxê be. Di nav rêza tarîxa hilbijartî de, wekî qaîdeyek, jixwe gengaz e ku meriv lêgerînek tev-nivîsê bike, tewra bi karanîna rêbaza hêza hovane bi karanîna mîna. Operatorê mîna li ClickHouse wekî operatorê herî bikêrhatî ye ku hûn dikarin bibînin. Ger hûn tiştek çêtir bibînin, ji min re bêjin.
Lê dîsa jî, mîna şopandinek tevahî ye. Û şopandina tevahî dikare ne tenê li ser CPU, lê di heman demê de li ser dîskê jî hêdî be. Ger ji nişka ve her roj yek terabyte daneya we hebe, û hûn di nav rojê de li peyvekê bigerin, wê hingê hûn neçar in ku terabyte bişopînin. Û belkî ew li ser dîskên hişk ên birêkûpêk e, û di dawiyê de ew ê bi vî rengî werin barkirin ku hûn ê nikaribin bi SSH-ê ve bigihîjin vê serverê.
Di vê rewşê de, ez amade me ku hîleyek piçûktir pêşkêşî bikim. Ew ceribandin e - dibe ku ew bixebite, dibe ku ne. ClickHouse di forma parzûnên Bloom-ê yên trigramê de indexên tevahî-text hene. Hevalên me yên li Arenadata berê van indexan ceribandine, û ew bi gelemperî wekî ku tê xwestin dixebitin.
Ji bo ku hûn wan rast bikar bînin, divê hûn baş têgihiştinek bi rastî ew çawa dixebitin: Parzûna Bloom ya trigram çi ye û meriv çawa mezinahiya wê hilbijêrin. Ez dikarim bibêjim ku ew ê ji bo pirsnameyên li ser hin hevokên kêm, binerdeyên ku kêm di daneyan de têne dîtin de bibin alîkar. Di vê rewşê de, binîqaş dê ji hêla navnîşan ve bêne hilbijartin û kêmtir dane dê bêne xwendin.
Di van demên dawî de, ClickHouse ji bo lêgerîna tev-nivîsê fonksiyonên hîn pêşkeftî zêde kiriye. Ev, yekem, lêgerînek e ku di yek derbasbûnê de bi yekcarî li komek binerêzan, di nav wan de vebijarkên ku hesas bi doz, nehesas in, bi piştgirîya UTF-8 an tenê ji bo ASCII. Ya herî bi bandor a ku hûn hewce ne hilbijêrin.
Lêgerîna gelek bêjeyên birêkûpêk di yek derbasbûnê de jî xuya bû. Hûn ne hewce ne ku X-ê wekî binerxek an X-ê wekî binerêzek din binivîsin. Hûn tavilê dinivîsin, û her tişt bi qasî ku pêkan bi bandor tê kirin.
Ya sêyem, naha ji bo regexps-an lêgerînek texmînî û ji bo binerdiyan lêgerînek texmînî heye. Ger kesek peyvek xelet binivîse, ew ê ji bo maqûlbûna herî zêde were lêgerîn.
Awayê çêtirîn ji bo organîzekirina gihîştina ClickHouse ji bo hejmarek mezin ji bikarhêneran çi ye?
Ji me re vebêjin ka meriv çawa gihîştina ji bo hejmarek mezin ji xerîdar û analîstan organîze dike. Meriv çawa rêzek çêdike, herî zêde pirsên hevdemî pêşanî dide, û bi kîjan amûran?
Ger kom bi têra xwe mezin be, wê hingê çareseriyek baş dê bilindkirina du serverên din be, ku dê bibe xalek têketinê ji bo analîstan. Ango, rê nedin analîstan ku xwe bigihînin perçeyên taybetî yên di komê de, lê bi tenê du serverên vala, bê dane, biafirînin û mafên gihîştinê li ser wan mîheng bikin. Di vê rewşê de, mîhengên bikarhêner ji bo daxwazên belavkirî li serverên dûr têne veguheztin. Ango, hûn her tiştî li ser van her du serveran mîheng dikin, û mîhengan bandorek li ser tevahiya komê dike.
Di prensîbê de, van serveran dane tune, lê mîqdara RAM-a li ser wan ji bo pêkanîna daxwazan pir girîng e. Ger berhevkirina derveyî an dabeşkirina derveyî çalak be, dîsk dikare ji bo daneyên demkî jî were bikar anîn.
Girîng e ku meriv li mîhengên ku bi hemî sînorên gengaz ve girêdayî ne binêre. Ger ez niha wekî analîstek biçim koma Yandex.Metrica û daxwazek bipirsim hejmartina ji hits hilbijêre, wê gavê dê ji min re îstîsnayek were dayîn ku ez nikarim daxwazê bi cih bînim. Hejmara herî zêde ya rêzên ku destûr ji min re tê dayîn sed mîlyar e, û bi tevahî pêncî trîlyon ji wan di tabloyek li ser komê de hene. Ev sînorê yekem e.
Ka em bibêjin ez sînorê rêzê radikim û pirsê dîsa dimeşînim. Dûv re ez ê îstîsna jêrîn bibînim - mîheng çalak e index hêzê ji aliyê date. Ez nikarim pirsê temam bikim ger min rêzek tarîx diyar nekiribe. Hûn ne hewce ne ku xwe bispêrin analîstan ku wê bi destan diyar bikin. Bûyerek tîpîk ev e dema ku rêzek tarîxek tê nivîsandin ku dîroka bûyerê di navbera hefteyê de ye. Û dûv re wan bi tenê bendek li cîhek xelet destnîşan kirin, û li şûna wê û ew derket holê ku an - an URL-ê lihevhatî ye. Ger ti sînor tune be, ew ê stûna URL-ê bikişîne û tenê tonek çavkaniyan winda bike.
Wekî din, ClickHouse du mîhengên pêşîn hene. Mixabin, ew pir prîmîtîv in. Yek bi tenê tê gotin pêşeyî. Ger pêşanî ≠ 0, û daxwazên bi hin pêşanî têne darve kirin, lê daxwazek bi nirxek pêşîn kêmtir ji, ku tê wateya pêşanîyek bilindtir, tête darve kirin, wê hingê daxwazek bi nirxa pêşîn a mezintir, ku tê wateya pêşînek kêmtir , bi tenê tê sekinandin û dê di vê demê de qet kar neke.
Ev mîhengek pir xav e û ji bo rewşên ku kom xwedan barek domdar e ne minasib e. Lê ger daxwazên weyên kurt û şikestî yên girîng hebin, û kom bi piranî bêkar e, ev sazûman guncan e.
Mîhenga pêşîn a din tê gotin Pêşîniya Mijara OS. Ew bi tenê nirxa xweş ji bo hemî mijarên pêkanîna daxwaznameyê ji bo nexşerêya Linux-ê destnîşan dike. Ew wusa- wusa dixebite, lê dîsa jî dixebite. Ger hûn nirxa herî kêm a xweş destnîşan bikin - ew di nirxê de ya herî mezin e, û ji ber vê yekê pêşîniya herî nizm e - û -19-ê ji bo daxwazên bi pêşengiya bilind destnîşan bikin, wê hingê CPU dê daxwazên kêm-pêşeng bi qasî çar caran kêmtir ji yên pêşanî bixwe.
Di heman demê de hûn hewce ne ku dema pêkanîna daxwazê ya herî zêde mîheng bikin - bêjin, pênc hûrdeman. Leza herî kêm a pêkanîna pirsê tiştê herî xweş e. Ev mîheng ji bo demek dirêj ve heye, û pêdivî ye ku ne tenê piştrast bikin ku ClickHouse hêdî nake, lê zorê jî dike.
Bifikirin, we saz kir: heke hin pirs di çirkeyê de ji yek mîlyon rêzan kêmtir pêvajoyê bikin, hûn nekarin wiya bikin. Ev navê me yê baş, databasa me ya baş riswa dike. Bila tenê vê qedexe bikin. Bi rastî du mîheng hene. Yek tê gotin leza înfazê min - di rêzan de serê saniyeyê de, û ya duyemîn berî kontrolkirina leza înfazê ya min - panzdeh çirke ji hêla xwerû ve dem jê tê gotin. Ango, panzdeh saniye mimkun e, û dûv re, heke hêdî be, wê hingê tenê îstisnayek bavêjin û daxwazê betal bikin.
Hûn jî hewce ne ku kotayan saz bikin. ClickHouse xwedan taybetmendiyek kotaya çêkirî ye ku xerckirina çavkaniyê dihejmêre. Lê, mixabin, ne çavkaniyên hardware yên wekî CPU, dîskên, lê yên mentiqî - hejmara daxwazên pêvajoyî, rêzik û bytes têne xwendin. Û hûn dikarin mîheng bikin, wek nimûne, herî zêde sed daxwazî di nav pênc hûrdeman de û hezar daxwazî di saetekê de.
Çima girîng e? Ji ber ku hin pirsên analîtîk dê rasterast ji xerîdar ClickHouse bi destan bêne kirin. Û her tişt dê baş be. Lê heke we di pargîdaniya we de analîstên pêşkeftî hebin, ew ê senaryoyek binivîsin, û dibe ku di senaryoyê de xeletiyek hebe. Û ev xeletî dê bibe sedem ku daxwaz di çerxek bêdawî de were darve kirin. Ya ku divê em xwe jê biparêzin ev e.
Ma gengaz e ku meriv encamên yek pirsê bide deh xerîdar?
Gelek bikarhênerên me hene ku dixwazin di heman demê de bi daxwazên pir mezin werin hundur. Daxwazek mezin e û, di prensîbê de, zû tête bicîh kirin, lê ji ber ku di heman demê de gelek daxwazên weha hene, ew pir bi êş dibe. Ma gengaz e ku meriv heman daxwaziya ku deh caran li pey hev hatî, carekê were bicîhanîn û encamê bide deh xerîdar?
Pirsgirêk ev e ku me encamên cache an cache daneyên navîn tune. Rûpelek pelê ya pergala xebitandinê heye, ku dê rê li ber we bigire ku hûn dîsa daneyên ji dîskê bixwînin, lê, mixabin, ew ê dane hîn jî were veqetandin, deserialîzekirin û ji nû ve pêvajoy kirin.
Ez dixwazim bi rengekî ji vê yekê dûr bixim, an bi cachkirina daneyên navîn, an jî bi rêzkirina pirsên wekhev di cûreyek rêzê de û lêzêdekirina cache encamek. Naha di pêşkeftinê de daxwazek meya vekişînê heye ku cacheyek daxwazê lê zêde dike, lê tenê ji bo jêrpirsînan di beşên nav û tevlêbûnê de - ango, çareserî ne temam e.
Lê belê em jî bi rewşeke wiha re rû bi rû ne. Nimûneyek taybetî ya kanonîkî pirsên paşînkirî ne. Raporek heye, çend rûpel hene û daxwaza sînorê 10 heye. Paşê heman tişt, lê sînor 10,10. Piştre rûpelek din. Û pirs ev e, çima em van hemûyan her car hesab dikin? Lê niha ne çareserî ye û ne jî rêyek ku jê birevin.
Çareseriyek alternatîf heye ku wekî kêlek li kêleka ClickHouse tête danîn - .
Kirill Shvakov: ClickHouse Proxy xwedan sînorkerek rêjeyê ya çêkirî û cache-ya encamek çêkirî ye. Ji ber ku pirsgirêkek bi vî rengî dihat çareserkirin, li wir gelek sererastkirin hatin kirin. Proxy destûrê dide te ku hûn daxwazan bi rêzkirina wan sînordar bikin û mîheng bikin ka kaşê daxwazê çiqas dimîne. Ger daxwaz bi rastî yek bûn, Proxy dê wan gelek caran bişîne, lê dê tenê carekê biçin ClickHouse.
Nginx di guhertoya belaş de jî cache heye, û ev jî dê bixebite. Nginx tewra mîhengan heye ku ger daxwaz di heman demê de werin, ew ê yên din hêdî bike heya ku yek biqede. Lê ew di ClickHouse Proxy de ye ku sazkirin pir çêtir tête çêkirin. Ew bi taybetî ji bo ClickHouse, bi taybetî ji bo van daxwazan hate çêkirin, ji ber vê yekê ew maqûltir e. Welê, sazkirina wê hêsan e.
Çi li ser operasyonên asynchronous û dîtinên maddî?
Pirsgirêkek heye ku operasyonên bi motora vegerandinê re asynkron in - pêşî dane têne nivîsandin, dûv re ew têk diçe. Ger tabletek materyalkirî ya ku bi hin berhevokan re di binê nîşanê de bimîne, wê hingê dê dubareyên jê re bêne nivîsandin. Û heke mentiqek tevlihev tune be, wê hingê dê dane dubare bibin. Hûn dikarin li ser wê çi bikin?
Çareseriyek eşkere heye - di dema operasyonek hilweşîna asynchronous de li ser çînek matview-ê kêşeyek bicîh bikin. Ma fîşekên zîv an plan hene ku fonksiyonek wekhev bicîh bikin?
Hêjayî fêmkirinê ye ku deduplication çawa dixebite. Tiştê ku ez ê nuha ji we re bibêjim ne bi pirsê re têkildar e, lê tenê heke ew hêjayî bîranînê ye.
Dema ku têxin nav tabloyek dubarekirî, hemî blokên hatine veqetandin tê derxistin. Ger hûn heman bloka ku heman hejmara heman rêzan tê de di heman rêzê de ji nû ve têxin nav hev, wê hingê dane têne jêbirin. Hûn ê di bersivê de "Ok" bistînin, lê di rastiyê de yek pakêtek daneyê dê were nivîsandin, û ew ê neyê dubare kirin.
Ev ji bo teqez pêwîst e. Heke hûn di dema danînê de "Ok" bistînin, wê hingê daneyên we hatine danîn. Ger hûn ji ClickHouse xeletiyek bistînin, ev tê vê wateyê ku ew nehatine danîn û hûn hewce ne ku têxê dubare bikin. Lê heke di dema têketinê de pêwendî qut bibe, wê hingê hûn nizanin ka dane hatine danîn an na. Vebijêrk yekane ev e ku hûn têxê dîsa dubare bikin. Ger dane bi rastî hatibe xistin û we ew ji nû ve bi cih kiribe, bloka jêbirinê heye. Ev hewce ye ku ji dubareyan dûr nekevin.
Û ev jî girîng e ku ew çawa ji bo dîtinên materyalî dixebite. Ger dema ku dane di tabloya sereke de hate jêbirin, wê hingê ew ê neçe nav dîtina materyalkirî jî.
Niha li ser pirsê. Rewşa we tevlihevtir e ji ber ku hûn dubareyên rêzikên kesane tomar dikin. Ango, ne tevahiya pakêtê ye ku tê dubare kirin, lê rêzikên taybetî ne, û ew di paşerojê de hilweşin. Bi rastî, dane dê di tabloya sereke de hilweşin, lê daneyên neqewimin dê biçin dîtina materyalkirî, û di dema yekbûnê de dê tiştek bi dîtinên materyalkirî re neyê. Ji ber ku nêrînek maddî ji pêvek pêve ne tiştek din e. Di dema operasyonên din de, tiştek zêde jê re çênabe.
Û ez nikarim te li vir kêfxweş bikim. Hûn tenê hewce ne ku ji bo vê dozê li çareseriyek taybetî bigerin. Mînakî, gelo gengaz e ku meriv wê di dîmenek materyalî de ji nû ve were lîstin, û dibe ku rêbaza dakêşandinê bi heman rengî bixebite. Lê mixabin, ne her dem. Ger kom bibe, ew ê nexebite.
Kirill Shvakov: Di heman demê de me di heman demê de avakirina kêşan jî hebû. Pirsgirêkek hebû ku bandorên reklamê hene, û hin dane hene ku em dikarin di wextê rast de nîşan bidin - ev tenê bandor in. Ew kêm kêm têne dubare kirin, lê heke wusa be, em ê paşê wan bi her awayî hilweşînin. Û tiştên ku nedihatin dubarekirin hebûn - klîk û ev hemî çîrok. Lê min jî xwest hema yekser nîşanî wan bidim.
Nêrînên maddî çawa hatin çêkirin? Nêrîn hebûn ku ew rasterast hatibû nivîsandin - ew bi daneyên xav hatî nivîsandin, û ji bo dîtinan hate nivîsandin. Li wir, di hin xalan de dane ne pir rast in, têne dubare kirin û hwd. Û beşek duyemîn a tabloyê heye, ku ew tam wekî nêrînên materyalkirî xuya dikin, ango, ew di strukturê de bi tevahî yek in. Carekê em daneyan ji nû ve dihejmêrin, daneyan bêyî dubare dihejmêrin, li wan tabloyan dinivîsin.
Me API-yê derbas kir - ev ê di ClickHouse-ê de bi destan nexebite. Û API dixuye: gava ku min dîroka lêzêdekirina paşîn a tabloyê heye, li wir tê garantî kirin ku daneyên rast ji berê ve hatine hesibandin, û ew daxwazek ji tabloyek û tabloyek din dike. Ji yekê daxwaz heya demek diyarkirî hildibijêre, û ji ya din tiştê ku hêj nehatiye hesibandin distîne. Û ew dixebite, lê ne tenê bi ClickHouse.
Ger we celebek API-yê heye - ji bo analîstan, ji bo bikarhêneran - wê hingê, di prensîbê de, ev vebijarkek e. Tu her tim dihejmêre, her tim dihejmêre. Ev dikare rojê carekê an demek din were kirin. Hûn ji bo xwe rêzek ku hûn ne hewce ne û ne krîtîk e hilbijêrin.
ClickHouse gelek têketin hene. Ez çawa dikarim her tiştê ku diqewime serverê bi nihêrînek bibînim?
ClickHouse hejmareke pir mezin a têketinên cihêreng hene, û ev hejmar her ku diçe zêde dibe. Di guhertoyên nû de, hin ji wan jî ji hêla xwerû ve têne çalak kirin; di guhertoyên kevn de divê dema nûvekirinê werin çalak kirin. Lêbelê, ji wan bêtir û bêtir hene. Di dawiyê de, ez dixwazim bibînim ka niha bi servera min re çi diqewime, dibe ku li ser celebek dashboardek kurtayî.
Ma we tîmek ClickHouse, an tîmên hevalên we hene, ku hin fonksiyonên dashboardên amade piştgirî dikin ku dê van têketinan wekî hilberek qediyayî nîşan bidin? Di dawiyê de, tenê lênihêrîna têketinên li ClickHouse pir xweş e. Lê heke ew jixwe di forma dashboardê de were amadekirin dê pir xweş be. Ez ê lêk jê bistînim.
Tablo hene, her çend ew ne standard in. Di pargîdaniya me de, nêzîkê 60 tîm ClickHouse bikar tînin, û ya herî ecêb ev e ku gelek ji wan dashboardên ku wan ji xwe re çêkirine hene, û yên hinekî cûda. Hin tîm saziyek navxweyî ya Yandex.Cloud bikar tînin. Hin raporên amade hene, her çend ne hemî hewce ne. Yên din yên xwe hene.
Hevalên min ên ji Metrica li Grafana dashboarda xwe hene, û ez jî ya xwe ji bo koma wan heye. Ez li tiştên wekî cache hit ji bo cache serif digerim. Û hê dijwartir ew e ku em amûrên cûda bikar tînin. Min dashboarda xwe bi karanîna amûrek pir kevn a bi navê Graphite-web afirand. Ew bi tevahî gemar e. Û ez hîn jî bi vî rengî bikar tînim, her çend Grafana belkî hêsantir û xweşiktir be.
Tişta bingehîn di dashboardan de yek e. Van metrîkên pergalê ji bo komê ne: CPU, bîranîn, dîsk, torê. Yên din - hejmara daxwazên hevdemî, hejmara hevberdana hevdemî, hejmara daxwazan di çirkeyê de, hejmara herî zêde ya perçeyan ji bo dabeşên tabloya MergeTree, derengiya dubarekirinê, mezinahiya rêza dubarekirinê, hejmara rêzikên ku di çirkeyê de hatine danîn, hejmara blokên ku di çirkeyê de hatine danîn. Ev her tiştê ku ne ji têketin, lê ji metrîkan tê wergirtin e.
Vladimir Kolobaev: Alexey, ez dixwazim wê hinekî rast bikim. Grafana heye. Grafana xwedan çavkaniyek daneyê ye, ku ClickHouse ye. Ango, ez dikarim daxwazên ji Grafana rasterast ji ClickHouse re bikim. ClickHouse tabloyek bi têketin heye, ew ji bo her kesî yek e. Wekî encamek, ez dixwazim bigihîjim vê tabloya têketinê li Grafana û daxwazên ku servera min dike bibînim. Dê pir baş be ku dashboardek bi vî rengî hebe.
Min bi xwe ajot. Lê pirsek min heye - heke ew hemî standardkirî ye, û Grafana ji hêla her kesî ve tê bikar anîn, çima Yandex xwedan panelek wusa fermî nîne?
Kirill Shvakov: Bi rastî, çavkaniya daneya ku diçe ClickHouse naha Altinity piştgirî dike. Û ez tenê dixwazim vektorek bidim ku ez li ku bikolim û kê bikişînim. Hûn dikarin ji wan bipirsin, ji ber ku Yandex hîn jî ClickHouse dike, û ne çîroka li dora wê. Altinity pargîdaniya sereke ye ku niha ClickHouse pêşve dike. Dê dev ji wî bernedin, dê piştgiriyê bidin wî. Ji ber ku, di prensîbê de, ji bo barkirina dashboardek li ser malpera Grafana, hûn tenê hewce ne ku wê qeyd bikin û barkirin - pirsgirêkên taybetî tune.
Alexey Milovidov: Di sala borî de, ClickHouse gelek kapasîteyên profîlkirina pirsê zêde kir. Ji bo her daxwazek li ser karanîna çavkaniyê metrîk hene. Û tenê vê dawiyê, me profîlek lêpirsînê ya asta jêrîn jî lê zêde kir da ku bibînin ka pirsek her millisecondê li ku derê xerc dike. Lê ji bo ku ez vê fonksiyonê bikar bînim, pêdivî ye ku ez muwekîlê konsolê vekim û daxwazek ku ez her gav ji bîr dikim binivîsim. Min ew li cîhek xilas kir û ji bîr dikim ku tam li ku derê ye.
Xwezî amûrek hebûya ku tenê digot, li vir pirsên weyên giran hene, ku ji hêla çîna pirsê ve têne kom kirin. Min pê li yek kir, û ew ê ji min re bibêjin ku ji ber vê yekê ew giran e. Niha çareseriyek wisa nîne. Û bi rastî pir ecêb e ku dema ku mirov ji min dipirsin: "Ji min re bêje, ji bo Grafana tabloyên amade hene?", ez dibêjim: "Here malpera Grafana, civatek "Dashboards" heye, û dashboardek heye. ji Dimka, dashboardek ji Kostyan heye. Ez nizanim ew çi ye, min bi xwe ew bikar neaniye."
Meriv çawa bandorê li yekbûnê dike da ku server di OOM-ê de nekeve?
Tabloyek min heye, di tabloyê de tenê parçeyek heye, ew ReplacingMergeTree ye. Ev çar sal in ez daneyan dinivîsim. Min hewce kir ku di wê de guhertinek çêbikim û hin daneyan jêbirin.
Min ev kir, û di dema pêvajoyek vê daxwazê de, hemî bîranîna li ser hemî serverên di komê de hate xerc kirin, û hemî pêşkêşkerên di komê de çûn OOM. Dûv re hemî rabûn hev, dest bi yekkirina heman operasyonê, vê bloka daneyê kirin, û dîsa ketin OOM. Paşê dîsa rabûn û dîsa ketin. Û ev tişt nesekinî.
Dûv re derket holê ku ev bi rastî xeletiyek bû ku hevalan rast kirin. Ev pir xweş e, gelek spas. Lê mayînek ma. Û naha, dema ku ez li ser çêkirina cûreyek hevgirtinê di tabloyê de difikirim, pirsek min heye - çima ez nikarim bi rengekî bandorê li van hevgirtinan bikim? Mînakî, wan bi mîqdara RAM-a ku hewce dike, an, bi prensîb, bi mîqdara ku dê vê tabloya taybetî bişopîne sînor bike.
Tabloyek min a bi navê "Metrics" heye, ji kerema xwe wê ji min re di du mijaran de bişopînin. Ne hewce ye ku deh-pênc hevbendî bi hevra çêkin, di duduyan de bikin. Ez difikirim ku ji bo duyan têra bîranîna min heye, lê dibe ku ew ne bes be ku ez deh bişopînim. Çima tirs dimîne? Ji ber ku tablo mezin dibe, û rojekê ez ê bi rewşek re rû bi rû bim ku, di prensîbê de, êdî ne ji ber xeletiyekê ye, lê ji ber ku dane dê di rêjeyek wusa mezin de biguhezin ku ez ê tenê têra bîranîna min nekim. server. Û dûv re dema ku meriv tevde bibe server dê têkeve OOM. Wekî din, ez dikarim mutasyonê betal bikim, lê Mercî nema li wir e.
Hûn dizanin, dema ku yekbûnek çêdibe, server dê nekeve OOM-ê, ji ber ku dema ku yek dibe, mîqdara RAM tenê ji bo yek rêzek piçûk a daneyê tê bikar anîn. Ji ber vê yekê dê her tişt baş be bêyî ku mîqdara daneyê.
Vladimir Kolobaev: Baş. Li vir dem wusa ye ku piştî ku xeletî hate rast kirin, min guhertoyek nû ji bo xwe dakêşand, û li ser maseyek din, piçûktir, ku tê de gelek dabeş hene, min operasyonek bi vî rengî kir. Û di dema yekbûnê de, nêzîkî 100 GB RAM li ser serverê hate şewitandin. Min 150 dagîr kiribû, 100 xwar, û pencereyek 50 GB mabû, ji ber vê yekê ez neketim OOM.
Ger ew bi rastî 100 GB RAM-ê dixwe, naha min ji ketina OOM-ê diparêze? Ger ji nişka ve RAM-a li ser hevgirtinê biqede, çi bikin?
Alexey Milovidov: Pirsgirêkek wusa heye ku karanîna RAM-ê bi taybetî ji bo hevgirtinê ne tixûbdar e. Pirsgirêka duyemîn ev e ku heke celebek hevgirtinê hatibe tayîn kirin, wê hingê divê ew were darve kirin ji ber ku ew di qeyda dubarekirinê de tête tomar kirin. Daxuyaniya dubarekirinê ew kirinên ku hewce ne ku replica bikeve rewşek hevgirtî. Ger hûn manîpulasyonên bi destan nekin ku dê vê qeyda dubarekirinê paşde vegerînin, pêdivî ye ku yekbûn bi rengekî an din were kirin.
Bê guman, dê ne zêde be ku meriv xwedan sînorkirinek RAM-ê ku "tenê di rewşê de" li dijî OOM-ê diparêze. Ew ê ne alîkar be ku yekbûn biqede, ew ê ji nû ve dest pê bike, bigihîje hin astekê, îstisnayek bavêje, û dûv re dîsa dest pê bike - tiştek baş dê ji vê dernekeve. Lê di prensîbê de, dê bikêrhatî be ku ev sînorkirin were danîn.
Dê ajokera Golang ji bo ClickHouse çawa were pêşve xistin?
Ajokarê Golang, ku ji hêla Kirill Shvakov ve hatî nivîsandin, nuha bi fermî ji hêla tîmê ClickHouse ve tê piştgirî kirin. Ew , ew niha mezin û rast e.
Têbînîyek piçûk. Depoyek ecêb û hezkirî ya formên normal ên nîzama bêdawî heye - ev Vertica ye. Di heman demê de ajokara xweya fermî ya python jî heye, ku ji hêla pêşdebirên Vertica ve têne piştgirî kirin. Û çend caran qewimî ku guhertoyên hilanînê û guhertoyên ajokerê bi rengek berbiçav ji hev cuda bûn, û ajokar di demek de xebitîn. Û xala duyemîn. Piştgiriya ji bo vê ajokerê fermî, ji min re xuya dike, ji hêla pergala "nipple" ve tête kirin - hûn ji wan re pirsgirêkek dinivîsin, û ew herheyî disekine.
Du pirsên min hene. Naha ajokarê Golangê Kirill hema hema awayê xwerû ye ku ji Golangê bi ClickHouse re danûstendinê dike. Heya ku kesek hîn jî bi navgîniya http re têkilî dayne ji ber ku ew bi vî rengî jê hez dike. Pêşkeftina vê ajokerê dê çawa pêş bikeve? Ma ew ê bi guhertinên şikestî yên di depoyê bixwe re were hevdem kirin? Û ji bo nirxandina pirsgirêkê çi ye?
Kirill Shvakov: Ya yekem ew e ku her tişt çawa bi awayekî burokratîk tê organîzekirin. Ev xal nehat nîqaşkirin, ji ber vê yekê tiştek min tune ku ez bersiv bidim.
Ji bo bersiva pirsa li ser pirsgirêkê, em hewceyê piçûkek dîroka ajokerê ne. Ez ji bo pargîdaniyek ku gelek daneyên wê hebûn xebitîm. Ew spinnerek reklamê bû ku bi hejmareke mezin bûyeran re hewce bû ku li cîhek were hilanîn. Û di demekê de ClickHouse xuya bû. Me ew bi daneyan tije kir, û di destpêkê de her tişt baş bû, lê paşê ClickHouse têk çû. Di wê demê de me biryar da ku em ne hewce ne.
Salek şûnda, em vegeriyan ramana karanîna ClickHouse, û me hewce bû ku bi rengekî daneyan li wir binivîsin. Peyama destpêkê ev bû: hardware pir qels e, çavkanî hindik in. Lê me her tim bi vî awayî xebitî û ji ber vê yekê me li protokola xwemalî nihêrî.
Ji ber ku em li Go dixebitîn, diyar bû ku hewcedariya me bi ajokarek Go heye. Min ew hema hema tev-dem kir - ew karê min bû. Me ew gihandiye xalek diyarkirî, û di prensîbê de kesek texmîn nedikir ku ji bilî me dê kesek din bikar bîne. Dûv re CloudFlare bi tam heman pirsgirêkê hat, û ji bo demekê em bi wan re pir xweş xebitîn, ji ber ku wan heman peywir hebûn. Wekî din, me ev hem li ClickHouse xwe û hem jî di ajokerê de kir.
Di hin xalan de, min bi tenê dev ji kirina wê berda, ji ber ku çalakiya min di warê ClickHouse û xebatê de hinekî guherî. Ji ber vê yekê pirsgirêk nayên girtin. Dem bi dem, mirovên ku hewcedariya wan bi tiştek heye, bi xwe xwe didin depoyê. Dûv re ez li daxwaza kişandinê dinêrim û carinan ez bixwe jî tiştek diguhezînim, lê ev kêm kêm dibe.
Ez dixwazim vegerim ba ajokar. Çend sal berê, dema ku ev tişt dest pê kir, ClickHouse jî cûda û bi kapasîteyên cihêreng bû. Naha me têgihîştinek heye ka meriv çawa ajokerê ji nû ve çêdike da ku ew baş bixebite. Ger ev çêbibe, wê hingê guhertoya 2-ê dê di her rewşê de ji ber kulîlkên berhevkirî ne lihevhatî be.
Ez nizanim vê mijarê çawa birêxistin bikim. Ez bi xwe zêde wextê min tune. Ger hin kes ajokarê biqedînin, ez dikarim alîkariya wan bikim û ji wan re bibêjim ka çi bikin. Lê beşdarbûna çalak ya Yandex di pêşveçûna projeyê de hîn nehatiye nîqaş kirin.
Alexey Milovidov: Bi rastî di derbarê van ajokaran de hêj burokrasî tune. Tiştek tenê ev e ku ew ji rêxistinek fermî re têne şandin, ango, ev ajokar wekî çareseriya xwerû ya fermî ji bo Go tê nas kirin. Hin ajokarên din jî hene, lê ew ji hev cuda têne.
Ji bo van ajokaran tu pêşveçûnek navxweyî ya me tune. Pirs ev e ku gelo em dikarin kesek takekesî bikin, ne ji bo vî ajokarê taybetî, lê ji bo pêşkeftina hemî ajokarên civakê, an em dikarin kesek ji derve bibînin.
Ferhenga derve piştî ji nû ve destpêkirinê bi mîhenga lazy_load çalakkirî nayê barkirin. Çi bikim?
Me mîhenga lazy_load aktîf kiriye, û piştî ku server ji nû ve were destpêkirin, ferheng bi serê xwe bar nake. Ew tenê piştî ku bikarhêner bigihîje vê ferhengê tê bilind kirin. Û cara yekem ku ez gihîştim wê, ew xeletiyek dide. Ma gengaz e ku meriv bi rengek bixweber ferhengan bi karanîna ClickHouse bar bike, an jî hûn hewce ne ku her gav amadebûna wan bixwe kontrol bikin da ku bikarhêner xeletiyan negirin?
Dibe ku me guhertoyek kevn a ClickHouse heye, ji ber vê yekê ferheng bixweber nehat barkirin. Dibe ku ev yek bibe?
Ya yekem, ferheng dikarin bi darê zorê bi karanîna pirsnameyekê werin barkirin pergalên reload ferhengên. Ya duyemîn, di derbarê xeletiyê de - heke ferheng jixwe hatî barkirin, wê hingê pirs dê li gorî daneyên ku hatine barkirin bixebitin. Ger ferheng hêj nehatibe barkirin, dê di dema daxwazê de rasterast were barkirin.
Ev ji bo ferhengên giran ne pir rehet e. Mînakî, hûn hewce ne ku mîlyon rêzan ji MySQL derxînin. Kesek hilbijarkek hêsan çêdike, lê ev hilbijartî dê li benda heman mîlyon rêzan bimîne. Li vir du çareserî hene. Ya yekem ev e ku meriv lazy_load vebike. Ya duyemîn, gava ku server rabe, berî barkirinê li ser wê bikin, bikin ferheng nûbarkirina pergalê an jî tenê pirsek ku ferhengek bikar tîne bike. Paşê ferheng dê were barkirin. Pêdivî ye ku hûn hebûna ferhengan bi mîhenga lazy_load çalakkirî kontrol bikin, ji ber ku ClickHouse bixweber wan bar nake.
Bersiva pirsa paşîn ev e ku guhertoyek kevn e an jî pêdivî ye ku ew were jêbirin.
Ger ku bi kêmanî yek ji wan bi xeletiyek têk biçe, bi vê yekê re çi bikin ku ferhengên ji nû ve barkirina pergalê yek ji gelek ferhengan bar nake?
Pirsek din di derbarê ferhengên ji nû ve barkirina pergalê de heye. Du ferhengên me hene - yek ne barkirî ye, ya duyemîn barkirî ye. Di vê rewşê de, ferhengên ji nû ve barkirina pergalê ti ferhengê bar nake, û divê hûn xal-bi-xal yekî taybetî bi navê wê bi karanîna ferhenga barkirina pergalê bar bikin. Ma ev jî bi guhertoya ClickHouse re têkildar e?
Ez dixwazim te kêfxweş bikim. Ev tevger dihat guhertin. Ev tê vê wateyê ku heke hûn ClickHouse-ê nûve bikin, ew ê jî biguhere. Heke hûn ji tevgera xwe ya heyî ne kêfxweş in pergalên reload ferhengên, nûvekirin, û em hêvî dikin ku ew ji bo çêtir biguhere.
Ma rêyek heye ku meriv hûrguliyan di mîhengê ClickHouse de mîheng bike, lê di bûyera xeletiyan de wan nîşan nede?
Pirsa din li ser xeletiyên bi ferhengê ve girêdayî ye, ango hûrgulî. Me hûrguliyên pêwendiyê di veavakirina ClickHouse de ji bo ferhengê diyar kiriye, û heke xeletiyek hebe, em van hûrgulî û şîfreyê di bersivê de digirin.
Me ev xeletî bi zêdekirina hûrguliyan li mîhenga ajokera ODBC çareser kir. Ma rêyek heye ku meriv hûrguliyan di mîhengê ClickHouse de mîheng bike, lê di bûyera xeletiyan de van hûrguliyan nîşan nede?
Li vir çareseriya rastîn ev e ku meriv van pêbaweriyan di odbc.ini de diyar bike, û di ClickHouse bixwe de tenê Navê Çavkaniya Daneyên ODBC diyar bike. Ev ê ji bo çavkaniyên ferhengê yên din çênebe - ne ji bo ferhenga bi MySQL, ne jî ji bo yên din, divê hûn şîfreyê nebînin dema ku hûn peyamek xeletiyek werdigirin. Ji bo ODBC, ez ê jî binerim - heke ew hebe, hûn tenê hewce ne ku wê jê bikin.
Bonus: paşnavên Zoom ji kombûnên
Bi tikandina li ser wêneyê, paşnavên bonus ên ji kombûnê dê ji xwendevanên herî domdar re vebin. Em bi tabloyên teknolojiya Avito re bi hev re agir vemirînin, em bi hevkarên jûreya rêveberê pergalê an klûba komputerê ya dibistana kevn re diaxivin, û em civînên rojane li binê pirê li dijî paşxaneya grafîtîyê pêk tînin.
Source: www.habr.com