Ji ber ku ClickHouse pergalek pispor e, dema karanîna wê girîng e ku meriv taybetmendiyên mîmariya wê bigire ber çavan. Di vê raporê de, Alexey dê di dema karanîna ClickHouse de, ku dikare bibe sedema xebata bêbandor, li ser mînakên xeletiyên hevpar biaxive. Nimûneyên pratîkî dê nîşan bidin ka meriv çawa bijartina yek an pileyek pêvajoyek daneyê dikare bi rêzikên mezinahiyê performansê biguhezîne.
Silav hemû! Navê min Alexey e, ez ClickHouse çê dikim.
Pêşîn, ez lez dikim ku tavilê ji we razî bikim, îro ez ê ji we re nebêjim ClickHouse çi ye. Bi rastî ez jê westiyame. Her gava ku ez ji we re dibêjim ew çi ye. Û dibe ku her kes jixwe dizane.
Di şûna wê de, ez ê ji we re bibêjim ka çi xeletiyên mimkun hene, ango hûn çawa dikarin ClickHouse bi xeletî bikar bînin. Bi rastî, ne hewce ye ku meriv bitirse, ji ber ku em ClickHouse wekî pergalek ku hêsan e, rehet e û ji qutîkê dixebite pêş dixe. Min ew saz kir, pirsgirêk tune.
Lê dîsa jî hûn hewce ne ku guh bidin ku ev pergal pispor e û hûn dikarin bi hêsanî rastî bûyerek karanîna ne asayî ya ku dê vê pergalê ji qada xweya aramiyê derxîne.
Ji ber vê yekê, çi celeb rakêşî heye? Bi piranî ez ê li ser tiştên eşkere biaxivim. Her tişt ji her kesî re eşkere ye, her kes ji her tiştî fam dike û dikare şa bibe ku ew ew qas jîr in, û yên ku fêm nakin dê tiştek nû fêr bibin.
Mînaka yekem û herî hêsan, ku, mixabin, pir caran çêdibe, hejmareke mezin a têkelên bi heviyên piçûk in, ango hejmareke mezin a têlên piçûk e.
Ger em bifikirin ka ClickHouse çawa têxê dike, wê hingê hûn dikarin di yek daxwazê de herî kêm terabyte daneyê bişînin. Ne pirsgirêk e.
Û em bibînin ka performansa tîpîk dê çi be. Mînakî, me tabloyek ji daneya Yandex.Metrica heye. Hits. 105 çend stûn. 700 bytes bêkompresyon. Û em ê bi awayekî baş têxin nav komên yek mîlyon rêzan.
Em MergeTree têxin tabloyê, ew di çirkekê de nîv mîlyon rêz derdixe. Ecêb. Di tabloyek dubarekirî de ew ê piçek piçûktir be, bi qasî 400 rêz di çirkekê de.
Û heke hûn têketina quorumê çalak bikin, hûn di çirkeyê de 250 şertan hinekî kêmtir, lê dîsa jî performansa maqûl digirin. Di ClickHouse* de têketina Quorum taybetmendiyek bêbelge ye.
* ji sala 2020 de, .
Heke hûn tiştek xirab bikin çi dibe? Em rêzek têxin tabloya MergeTree û di çirkekê de 59 rêzan distînin. Ew 10 carî hêdîtir e. Di ReplicateMergeTree - 000 rêz di çirkeyê de. Û heke ku quorum were zivirandin, wê hingê ew di çirkeyê de 6 rêz derdikeve. Bi dîtina min, ev celebek bêkêmasî ye. Çawa hûn dikarin wisa hêdî hêdî bikin? Tewra min li ser T-shirtê xwe jî nivîsandiye ku ClickHouse divê hêdî nebe. Lê dîsa jî carinan carinan dibe.
Bi rastî ev kêmasiya me ye. Me dikaribû bi hêsanî her tişt baş bikira, lê me nekir. Û me ew nekir ji ber ku senaryoya me hewce nekir. Jixwe qesabên me hebûn. Me tenê li ber deriyê xwe bexş werdigirt, û tu pirsgirêk tune. Em wê têxin û her tişt baş dixebite. Lê, bê guman, her cûre senaryo mimkun e. Mînakî, gava ku hûn komek server hene ku li ser wan dane têne çêkirin. Û ew bi gelemperî daneyan têxin nav xwe, lê dîsa jî ew bi têketina pir caran diqedin. Û divê em bi awayekî ji vê yekê dûr bisekinin.
Ji hêla teknîkî ve, xal ev e ku gava ku hûn di ClickHouse-ê de pêvekek bikin, dane di tu memtable de naqede. Tewra ne têketinek me ya rastîn MergeTree heye, lê tenê MergeTree heye, ji ber ku ne têketin û ne jî memTable heye. Em bi tenê yekser daneyan li pergala pelan, ku berê di stûnan de hatine rêz kirin, dinivîsin. Û heke 100 stûnên we hebin, wê hingê pêdivî ye ku bêtirî 200 pelan li pelrêçek cûda bêne nivîsandin. Hemî ev pir giran e.
Û pirs derdikeve holê: "Ma meriv wê çawa rast bike?" Ger rewş wusa be ku hûn hîn jî hewce ne ku bi rengek daneyan li ClickHouse tomar bikin.
Rêbaz 1. Ev riya herî hêsan e. Hin cûreyek rêza belavkirî bikar bînin. Mînak Kafka. Hûn bi tenê daneyan ji Kafka derdixin û di saniyeyekê de carek dişoxilînin. Û her tişt dê baş be, hûn tomar bikin, her tişt baş dixebite.
Dezavantaj ev in ku Kafka sîstemeke din a belavbûyî ya mezin e. Ez jî fêm dikim ku jixwe Kafka di nav we de heye. Baş e, rehet e. Lê heke ew tune be, wê hingê divê hûn sê caran bifikirin berî ku pergalek din a belavkirî di projeya xwe de bikişîne. Û ji ber vê yekê ew hêja ye ku alternatîfan bifikirin.
Rêbaz 2. Ev alternatîfek dibistana kevn e û di heman demê de pir hêsan e. Ma we celebek serverek heye ku têketinên we çêdike. Û ew tenê têketinên we li pelek dinivîse. Mînakî, saniyeyek carekê, em navê vê pelê biguhezînin û yekî nû jê dikin. Û nivîsarek veqetandî, an bi riya cron an hin daemon, pelê herî kevn digire û li ClickHouse dinivîse. Ger hûn saniyeyekê carekê têketin tomar bikin, wê hingê her tişt dê baş be.
Lê kêmasiya vê rêbazê ev e ku ger servera weya ku têketin li ser têne çêkirin li cîhek wenda bibe, wê hingê dê dane jî winda bibin.
Rêbaz 3. Rêbazek din a balkêş heye, ku bi tevahî pelên demkî hewce nake. Mînakî, we cûreyek spinnerek reklamê an şeytanek din a balkêş heye ku daneyan çêdike. Û hûn dikarin komek daneyan rasterast di RAM-ê de, di tamponê de berhev bikin. Û gava ku dem têra xwe derbas bû, hûn vê tamponê didin aliyekî, yekî nû diafirînin, û di mijarek cihê de, tiştê ku berê berhev kiriye têxin ClickHouse.
Ji hêla din ve, data jî bi kuştina -9 winda dibe. Ger servera we têk bibe, hûn ê vê daneyê winda bikin. Û pirsgirêkek din jî ev e ku heke we nikaribin li databasê binivîsin, wê hingê daneyên we dê di RAM-ê de kom bibin. Û yan RAM dê biqede, an jî hûn ê tenê daneyan winda bikin.
Rêbaz 4. Rêbazek din a balkêş. Ma hûn cûreyek pêvajoya serverê heye. Û ew dikare tavilê daneyan bişîne ClickHouse, lê wê di yek pêwendiyê de bike. Mînakî, min daxwazek http bi veguhez-encoding şand: bi têxê ve hatî perçe kirin. Û ew perçeyan ne pir kêm çêdike, hûn dikarin her rêzê bişînin, her çend dê ji bo çarçovekirina vê daneyê serek hebe.
Lêbelê, di vê rewşê de dê dane yekser ji ClickHouse re bêne şandin. Û ClickHouse dê wan bixwe tampon bike.
Lê pirsgirêk jî derdikevin. Naha hûn ê daneyan winda bikin, di nav de dema ku pêvajoya we were kuştin û ger pêvajoya ClickHouse were kuştin, ji ber ku ew ê têkelek netemam be. Û di ClickHouse-ê de pêvekên atomî heta bergehek diyarkirî di mezinahiya rêzan de ne. Di prensîbê de, ev rêbazek balkêş e. Her weha dikare were bikar anîn.
Rêbaz 5. Li vir rêbazek din a balkêş e. Ev celeb serverek pêşkeftî ya civakê ye ji bo berhevkirina daneyan. Min bi xwe lê nenihêrî, ji ber vê yekê ez nikarim tiştek garantî bikim. Lêbelê, ji bo ClickHouse bixwe garantî nayê peyda kirin. Ev jî çavkaniyek vekirî ye, lê ji hêla din ve, dibe ku hûn bi hin standardek kalîteyê ya ku em hewl didin peyda bikin bikar bînin. Lê ji bo vê yekê - ez nizanim, biçin GitHub, li kodê binêrin. Belkî tiştekî normal nivîsîbin.
* ji sala 2020-an pê ve, divê li ber çavan jî were zêdekirin .
Rêbaz 6. Rêbazek din jî bikaranîna tabloyên Buffer e. Feydeya vê rêbazê ev e ku karanîna wê pir hêsan e. Tabloyek Buffer ava bikin û têxin nav wê.
Kêmasî ew e ku pirsgirêk bi tevahî nayê çareser kirin. Ger, di rêjeyek mîna MergeTree de, hûn neçar in ku daneyan di çirkekê de bi yek komê kom bikin, wê hingê di rêjeyek tabloyek tampon de, hûn hewce ne ku di çirkeyê de herî kêm çend hezar kom bikin. Ger ew ji 10 di çirkeyê de bêtir be, ew ê dîsa jî xirab be. Û heke hûn wê di koman de têxin hev, wê hingê we dît ku ew di çirkeyê de sed hezar xet dibe. Û ev jixwe li ser daneyên pir giran e.
Û her weha tabloyên tampon têketinek tune. Û heger tiştek di servera we de çewt e, wê hingê dê dane winda bibin.
Û wek bonus, me vê dawîyê li ClickHouse fersend girt ku em daneyan ji Kafka bistînin. Motora sifrê heye - Kafka. Hûn tenê biafirînin. Û hûn dikarin nûnerên maddî li ser wê daliqînin. Di vê rewşê de, ew ê bixwe daneyan ji Kafka derxe û têxe tabloyên ku hûn hewce ne.
Û ya ku bi taybetî di vê fersendê de kêfxweş e ev e ku ne em bûn ku ew kir. Ev taybetmendiyek civakê ye. Û gava ku ez dibêjim "taybetmendiya civakê," ez bêyî heqaretê mebest dikim. Me kod xwend, vekolînek kir, divê ew baş bixebite.
* ji sala 2020-an pê ve, piştgirîyek wusa ji bo xuya bû .
Di dema danîna daneyan de çi din dibe ku nerehetî an nediyar be? Ger hûn daxwazek nirxan têxin nav nirxan û di nirxan de hin îfadeyên hesabkirî binivîsin. Mînakî, niha() jî îfadeyek hesabkirî ye. Û di vê rewşê de, ClickHouse neçar e ku wergêrê van îfadeyan li ser her rêzê bide destpêkirin, û performans dê bi fermanên mezinbûnê dakevin. Çêtir e ku ji vê yekê dûr bixin.
* di vê gavê de, pirsgirêk bi tevahî çareser bûye, dema ku bêjeyên di VALUES de bikar tînin êdî paşveçûnek performansê tune.
Nimûneyek din ev e ku gava ku hûn daneyên li ser yek komê ku girêdayî komek dabeşan e, hin pirsgirêk hebin. Bi xwerû, dabeşên ClickHouse li gorî mehê ne. Û heke hûn komek ji mîlyon rêzan têxin, û çend salan dane hene, wê hingê hûn ê li wir bi dehan dabeşan hebin. Û ev yek bi wê yekê re ye ku dê beşên bi deh caran piçûktir hebin, ji ber ku di hundurê wan de ew her gav yekem li dabeşan têne dabeş kirin.
* Di van demên dawî de, di moda ceribandinê de, ClickHouse piştgirî ji bo formata berhevokê ya perçe û perçeyên RAM-ê bi têketina pêş-nivîsandinê zêde kir, ku hema hema bi tevahî pirsgirêkê çareser dike.
Naha em li celebê duyemîn ê pirsgirêkê binêrin - tîpkirina daneyê.
Nivîsandina daneyan dikare hişk an rêzik be. String ev e ku we tenê ew girt û daxuyand ku hemî zeviyên we ji rêzika tîpê ne. Ev dişewite. Ne hewce ye ku vê yekê bikin.
Werin em fêhm bikin ka meriv çawa wiya rast di wan rewşan de bike gava ku hûn dixwazin bibêjin ku me qadek, rêzek heye, û bila ClickHouse wê bi serê xwe fêhm bike, û ez ê aciz nekim. Lê dîsa jî hêjayî hin hewldan e.
Mînakî, navnîşek IP-ya me heye. Di rewşek de, me ew wekî string xilas kir. Mînakî, 192.168.1.1. Û di rewşeke din de, ew ê hejmarek celeb UInt32 * be. Ji bo navnîşana IPv32 4 bit bes e.
Ya yekem, bi rengek ecêb, dê dane bi qasî wekhev bêne berhev kirin. Cûdahî dê hebe, bê guman, lê ne ew qas mezin. Ji ber vê yekê pirsgirêkên taybetî bi I/O-ya dîskê re tune.
Lê di dema pêvajoyê û dema darvekirina pirsê de cûdahiyek cidî heye.
Ka em hejmara navnîşanên IP-ya yekta bijmêrin heke ew wekî jimar têne hilanîn. Ew di çirkeyê de 137 mîlyon xetên dixebite. Ger heman di forma têlan de be, wê hingê 37 mîlyon rêz di çirkeyê de. Ez nizanim çima ev tesaduf çêbû. Min bi xwe van daxwazan pêk anî. Lê dîsa jî bi qasî 4 caran hêdîtir.
Û heke hûn cûdahiya cîhê dîskê hesab bikin, wê hingê ferqek jî heye. Cûdahî bi qasî çaryek e, ji ber ku gelek navnîşanên IP-ya bêhempa hene. Û ger rêzikên bi hejmarek hindik wateyên cihê hebin, wê hingê ew ê bi hêsanî li gorî ferhengê di heman cildê de bihatana berhev kirin.
Û ferqa demê ya çaralî li ser rê dernakeve. Belkî jî helbet tu guh nadî, lê dema ez ferqeke wiha dibînim ez xemgîn dibim.
Werin em li dozên cuda binêrin.
1. Yek rewş dema ku we çend nirxên bêhempa yên cûda hene. Di vê rewşê de, em pratîkek hêsan bikar tînin ku hûn belkî dizanin û dikarin ji bo her DBMS bikar bînin. Ev hemî ne tenê ji bo ClickHouse re watedar e. Tenê nasnameyên hejmarî di databasê de binivîsin. Û hûn dikarin li kêleka serîlêdana xwe veguhezînin rêzan û paşde bikin.
Mînakî, herêmek we heye. Û hûn hewl didin ku wê wekî têl xilas bikin. Û li wir wê were nivîsandin: Moskow û Herêma Moskowê. Û gava ku ez dibînim ku ew dibêje "Moskow", ew ne tiştek e, lê gava ku ew Moskow e, ew bi rengek bi tevahî xemgîn dibe. Ev çend byte ye.
Di şûna wê de, em tenê hejmara Ulnt32 û 250 dinivîsin. Di Yandex de 250 me hene, lê dibe ku ya we cûda be. Tenê di rewşê de, ez ê bibêjim ku ClickHouse xwedan jêhatîbûnek çêkirî ye ku bi geobase re bixebite. Hûn bi tenê pelrêçek bi herêman re, di nav de yek hiyerarşîk, binivîsin, ango dê Moskow, Herêma Moskowê û her tiştê ku hûn hewce ne hebin. Û hûn dikarin di asta daxwazê de veguherînin.
Vebijarka duyemîn bi qasî heman e, lê bi piştgirî di hundurê ClickHouse de. Ev cureyê daneya Enum e. Hûn tenê hemî nirxên ku hûn hewce ne di hundurê Enum-ê de binivîsin. Mînakî, amûrê binivîsin û li wir binivîsin: sermaseya, mobîl, tablet, TV. Bi tevahî 4 vebijark hene.
Kêmasî ev e ku hûn hewce ne ku wê bi demkî biguhezînin. Tenê vebijarkek lê zêde kirin. Ka em tabloya alter bikin. Bi rastî, tabloya alter li ClickHouse belaş e. Bi taybetî ji bo Enum belaş ji ber ku daneyên li ser dîskê nayê guhertin. Lê dîsa jî, alter li ser masê qeflek* peyda dike û divê li bendê bimîne heya ku hemî hilbijartî werin darve kirin. Û tenê piştî ku ev guhertin dê were darve kirin, ango hîna hin nerehetî hene.
* di guhertoyên herî dawî yên ClickHouse de, ALTER bi tevahî ne-astengkirî tête çêkirin.
Vebijarkek din a ku ji bo ClickHouse pir bêhempa ye, girêdana ferhengên derveyî ye. Hûn dikarin li ClickHouse jimareyan binivîsin, û pelrêçayên xwe di her pergalê de ji bo we rehet bihêlin. Mînakî, hûn dikarin bikar bînin: MySQL, Mongo, Postgres. Hûn dikarin mîkroxizmeta xwe jî biafirînin ku dê vê daneyê bi http bişîne. Û di asta ClickHouse de, hûn fonksiyonek dinivîsin ku dê vê daneyê ji hejmaran veguherîne rêzan.
Ev rêgezek pispor lê pir bikêr e ku meriv tevlêbûnek li ser maseyek derveyî pêk bîne. Û du vebijark hene. Di yek pêkvekirinê de, ev dane dê bi tevahî cache, bi tevahî di RAM-ê de hebe û bi hin frekansan ve were nûve kirin. Û di vebijarkek din de, heke ev dane di RAM-ê de cîh nagire, wê hingê hûn dikarin qismî wê cache bikin.
Li vir mînakek e. Yandex.Direct heye. Û şirketek reklamê û pankart hene. Dibe ku bi deh mîlyonan pargîdaniyên reklamê hene. Û ew hema hema di RAM-ê de cih digirin. Û bi mîlyaran pankart hene, ew li hev nakin. Û em ferhengek cached ji MySQL bikar tînin.
Pirsgirêk tenê ev e ku ferhenga cache dê baş bixebite heke rêjeya lêdanê nêzî 100% be. Ger ew piçûktir be, wê hingê gava ku ji bo her komek daneyê lêpirsînan hildiberînin, hûn ê bi rastî neçar bin ku mifteyên winda bigirin û biçin daneyan ji MySQL bistînin. Di derbarê ClickHouse de, ez hîn jî dikarim garantî bikim ku - erê, ew hêdî nabe, ez ê li ser pergalên din biaxivim.
Û wekî bonus, ferheng rêgezek pir hêsan e ku hûn bi paşverû daneya li ClickHouse nûve bikin. Ango, we raporek li ser pargîdaniyên reklamê hebû, bikarhêner bi tenê pargîdaniya reklamê guherand û di hemî daneyên kevn de, di hemî raporan de ev dane jî guherî. Ger hûn rêzikan rasterast li ser sifrê binivîsin, nûvekirina wan ne gengaz e.
Rêyek din dema ku hûn nizanin nasnavên rêzikên xwe ji ku derê bistînin. hûn dikarin bi hêsanî wê bişopînin. Wekî din, vebijarka herî hêsan ev e ku meriv hashek 64-bit bigire.
Pirsgirêk tenê ev e ku heke hash 64-bit be, wê hingê hûn ê hema hema bê guman pevçûn hebin. Ji ber ku heke li wir mîlyar xet hebin, wê hingê îhtimal jixwe xuya dibe.
Û ne pir baş e ku meriv navên pargîdaniyên reklamê bi vî rengî bişewitîne. Ger kampanyayên reklamê yên pargîdaniyên cûda tevlihev bibin, wê hingê tiştek nayê fêm kirin.
Û fenek hêsan heye. Rast e, ew ji bo daneyên ciddî jî ne pir maqûl e, lê heke tiştek ne pir ciddî ye, wê hingê tenê nasnavê xerîdar li mifteya ferhengê zêde bikin. Û paşê hûn ê pevçûnan hebin, lê tenê di nav yek xerîdar de. Û em vê rêbazê ji bo nexşeyên girêdana li Yandex.Metrica bikar tînin. Li wir URLên me hene, em haşeyan hilînin. Û em dizanin ku, bê guman, pevçûn hene. Lê gava ku rûpel tê xuyang kirin, îhtîmala ku li ser rûpelek bikarhênerek hin URL li hev zeliqin û ev yek were îhmalkirin dikare were paşguh kirin.
Wekî bonus, ji bo gelek operasyonan tenê haş bes in û ne hewce ye ku rêz bixwe li deverek were hilanîn.
Mînakek din ev e ku ger rêzikên kurt bin, mînakî, domên malperê. Ew dikarin wekî ku têne hilanîn. An jî, wek nimûne, zimanê gerokê ru 2 byte ye. Bê guman, ez bi rastî ji bo bîtan xemgîn dibim, lê xem neke, 2 bayt ne heyf in. Ji kerema xwe wê wekî xwe bihêle, xem neke.
Bûyerek din ew e ku, berevajî, gelek xêz hene û di nav wan de gelek yên bêhempa hene, û tewra set jî potansiyel bêsînor e. Mînakek tîpîk hevokên lêgerînê an URLan e. Peyvên lêgerînê, tevî xeletiyên tîpan. Ka em bibînin ka rojane çend hevokên lêgerînê yên bêhempa hene. Û derket holê ku ew hema hema nîvê hemî bûyeran in. Û di vê rewşê de, hûn dikarin bifikirin ku hûn hewce ne ku daneyan normal bikin, nasnameyan bijmêrin, û wê di tabloyek cûda de bixin. Lê hûn ne hewce ne ku hûn wiya bikin. Tenê van rêzan wekî ku ne biparêzin.
Çêtir e ku hûn tiştek îcad nekin, ji ber ku heke hûn wê ji hev cuda hilînin, hûn ê hewce bikin ku tevlêbûnê bikin. Û ev tevlêbûn, herî baş, gihîştinek rasthatî ya bîranînê ye, heke ew hîn jî di bîranînê de cih bigire. Ger ne li hev be, wê demê dê pirsgirêk derkevin.
Û heke daneyên li cîhê xwe têne hilanîn, wê hingê ew bi tenê bi rêza pêdivî ji pergala pelê tê xwendin û her tişt baş e.
Ger we URL an rêzikek dirêj a tevlihev a din heye, wê hingê hêja ye ku hûn bifikirin ku hûn dikarin cûreyek jêgirtinê pêşî hesab bikin û wê di stûnek cihê de binivîsin.
Ji bo URLan, wek nimûne, hûn dikarin domainê ji hev cuda hilînin. Û heke hûn bi rastî hewceyê domainek in, wê hingê tenê vê stûnê bikar bînin, û URL dê li wir bimînin, û hûn ê dest nedin wan jî.
Ka em bibînin ka ferqa çi ye. ClickHouse fonksiyonek pispor heye ku domainê hesab dike. Ew pir zû ye, me ew xweşbîn kiriye. Û, rast be, ew bi RFC-ê re jî tevnagere, lê dîsa jî ew her tiştê ku em hewce dike dihesibîne.
Û di yek rewşê de em ê tenê URLan bistînin û domainê hesab bikin. Ew bi 166 millisecond dixebite. Û heke hûn domainek amade bistînin, wê hingê ew tenê 67 milî çirkeyan çêdibe, ango hema sê carî zûtir e. Û ew zûtir e ne ji ber ku em hewce ne ku hin hesaban bikin, lê ji ber ku em kêmtir daneyan dixwînin.
Ji ber vê yekê yek daxwazek, ku hêdîtir e, leza wê ya gigabayt di çirkekê de zêdetir e. Ji ber ku ew bêtir gigabytes dixwîne. Ev daneyên bi tevahî nepêwist e. Dixuye ku daxwaz zûtir dimeşe, lê ji bo temamkirina wê demek dirêj digire.
Û heke hûn li mîqdara daneyên li ser dîskê binihêrin, derdikeve holê ku URL 126 megabyte ye, û domain tenê 5 megabyte ye. Ew 25 carî kêmtir dibe. Lê dîsa jî, daxwaz tenê 4 carî zûtir tê pêkanîn. Lê ji ber ku dane germ e. Û heke sar bûya, ji ber I/O ya dîskê belkî 25 qat zûtir bibûya.
Bi awayê, heke hûn texmîn bikin ku domainek ji URL-ê çiqas piçûktir e, ew bi qasî 4 carî piçûktir dibe. Lê ji ber hin sedeman, dane 25 carî kêmtir li ser dîskê digire. Çima? Ji ber zextê. Û URL-ê tête kirin, û domainê tête kirin. Lê pir caran URL komek çopê dihewîne.
Û, bê guman, ew dide ku meriv celebên daneya rast ên ku bi taybetî ji bo nirxên xwestinê hatine sêwirandin an ku guncan in bikar bînin. Heke hûn di IPv4 de ne, wê hingê UInt32* hilînin. Ger IPv6, wê hingê FixedString(16), ji ber ku navnîşana IPv6 128 bit e, ango rasterast di forma binary de tê hilanîn.
Lê heke hûn carinan navnîşanên IPv4 û carinan jî IPv6 hene? Erê, hûn dikarin herduyan hilînin. Stûnek ji bo IPv4, ya din ji bo IPv6. Bê guman, vebijarkek heye ku IPv4 di IPv6 de nîşan bide. Ev ê di heman demê de bixebite, lê heke hûn di daxwazan de pir caran hewceyê navnîşek IPv4 bin, wê hingê baş e ku hûn wê di stûnek cihê de bixin.
* ClickHouse naha celebên daneya IPv4, IPv6 yên cihêreng hene ku daneyan bi qasî hejmaran bi bandor hilîne, lê wan bi hêsanî wekî rêzan temsîl dike.
Di heman demê de girîng e ku meriv bala xwe bide ku ew hêja ye ku daneya pêşdibistanê were hilberandin. Mînakî, hûn hin têketinên xav distînin. Û dibe ku hûn ne tenê di cih de wan bixin nav ClickHouse, her çend ew pir ceribandî ye ku hûn tiştek nekin û her tişt dê bixebite. Lê dîsa jî hêja ye ku hesabên ku mimkun in bêne kirin.
Mînakî, guhertoya gerokê. Li hin dezgehên nêzîk, ku ez naxwazim tiliyek lê bidim, guhertoya gerokê bi vî rengî tête hilanîn, ango wekî rêzek: 12.3. Û dûv re, ji bo ku raporek çêbikin, ew vê rêzê digirin û di nav rêzek, û paşê jî di hêmana yekem a rêzê de dabeş dikin. Bi xwezayî, her tişt hêdî dibe. Min pirsî çima ew vê yekê dikin. Wan ji min re got ku ew ji xweşbîniya zû hez nakin. Û ez ji reşbîniya zû hez nakim.
Ji ber vê yekê di vê rewşê de dê rasttir be ku meriv li 4 stûnan dabeş bike. Li vir netirsin, ji ber ku ev ClickHouse ye. ClickHouse databasek stûnek e. Û her ku stûnên piçûk ên xweştir, çêtir e. Dê 5 Guhertoyên Gerokê hebin, 5 stûnan çêbikin. Ev baş e.
Naha em binihêrin ka hûn çi bikin heke hûn gelek têlên pir dirêj, rêzikên pir dirêj hebin. Ne hewce ye ku ew qet li ClickHouse werin hilanîn. Di şûna wê de, hûn dikarin tenê di ClickHouse de nasnameyek hilînin. Û van rêzikên dirêj bixin nav sîstemeke din.
Mînakî, yek ji karûbarên meya analîtîk hin pîvanên bûyerê hene. Û heger ji bo bûyeran gelek parametre hebin, em bi tenê 512-a yekem a ku tê de hilînin. Ji ber ku 512 ne heyf e.
Û heke hûn nekarin li ser celebên daneyên xwe biryar bidin, wê hingê hûn dikarin daneyan li ClickHouse jî tomar bikin, lê di tabloyek demkî ya celebê Log de, ji bo daneyên demkî taybetî. Piştî vê yekê, hûn dikarin analîz bikin ka kîjan dabeşkirina nirxên we li wir heye, bi gelemperî çi heye, û celebên rast biafirînin.
*ClickHouse niha celebek daneyê heye ku destûrê dide te ku hûn bi hewildanek kêmtir rêzan bi bandor hilînin.
Naha em li dozek din a balkêş binêrin. Carinan tişt ji bo mirovan xerîb dixebitin. Ez têm û vê dibînim. Û tavilê dixuye ku ev ji hêla rêveberek pir bi tecrûbe, jîr ve hatî çêkirin ku di sazkirina guhertoya MySQL 3.23 de xwedî ezmûnek berfireh e.
Li vir em hezar tabloyan dibînin, ku her yek ji wan mayî dabeşkirina kî dizane çi bi hezarî re tomar dike.
Di prensîbê de, ez ji ezmûna mirovên din re rêz dikim, tevî têgihîştina êşa ku dikare bi vê ezmûnê were bidestxistin.
Û sedem jî kêm-zêde zelal in. Ev stereotipên kevn in ku dibe ku dema ku bi pergalên din re dixebitin berhev bûne. Mînakî, tabloyên MyISAM xwedan mifteyek bingehîn a komkirî tune. Û ev awayê dabeşkirina daneyan dibe ku hewldanek bêhêvî be ji bo bidestxistina heman fonksiyonê.
Sedemek din jî ev e ku dijwar e ku meriv li ser maseyên mezin operasyonên guheztinê bike. Her tişt wê bê astengkirin. Her çend di guhertoyên nûjen ên MySQL de ev pirsgirêk êdî ew qas giran e.
An jî, wek nimûne, microsharding, lê bêtir li ser wê paşê.
Di ClickHouse de ne hewce ye ku vê yekê bikin, ji ber ku, yekem, mifteya bingehîn komkirî ye, dane ji hêla mifteya bingehîn ve têne ferman kirin.
Û carinan mirov ji min dipirsin: "Performansa pirsên rêzê li ClickHouse li gorî mezinahiya tabloyê çawa diguhere?" Ez dibêjim qey qet nayê guhertin. Mînakî, we tabloyek bi mîlyar rêzek heye û hûn rêzek yek mîlyon rêzan dixwînin. Her tişt baş e. Ger di tabloyekê de trîlyon rêz hebin û hûn mîlyon rêzek bixwînin, dê hema wisa be.
Û, ya duyemîn, her cûre tiştên wekî dabeşên destan ne hewce ne. Ger hûn têkevin hundur û li tiştê ku li ser pergala pelan heye binihêrin, hûn ê bibînin ku tablo tiştek pir mezin e. Û di hundurê de tiştek wekî dabeşan heye. Ango, ClickHouse ji bo we her tiştî dike û hûn ne hewce ne ku cefayê bikişînin.
Ger stûnek lê zêde bike/dake biguherîne, di ClickHouse de guhertin belaş e.
Û divê hûn tabloyên piçûk nekin, ji ber ku heke we di tabloyekê de 10 rêz an 10 rêz hebin, wê hingê ew qet ne girîng e. ClickHouse pergalek e ku rêgezê xweşbîn dike, ne derengiyê, ji ber vê yekê ne wate ye ku meriv 000 rêzan bike.
Rast e ku meriv yek tabloyek mezin bikar bîne. Ji qalibên kevn dûr bikevin, dê her tişt baş bibe.
Û wekî bonus, di guhertoya herî paşîn de naha me jêhatî ye ku em mifteyek dabeşkirinê ya kêfî biafirînin da ku em her cûre operasyonên lênihêrînê li ser dabeşên kesane pêk bînin.
Mînakî, ji we re gelek tabloyên piçûk lazim in, mînakî, gava ku hewcedarî bi pêvajokirina hin daneyên navîn hebe, hûn perçeyan distînin û hûn hewce ne ku berî ku hûn li tabloya paşîn binivîsin veguherînek li ser wan bikin. Ji bo vê rewşê, motorek sifrê ya ecêb heye - StripeLog. Ew mîna TinyLog e, tenê çêtir e.
* niha ClickHouse jî heye .
Antîpatternek din jî microsharding e. Mînakî, hûn hewce ne ku daneyan parve bikin û 5 serverên we hene, û sibê dê 6 server hebin. Û hûn difikirin ka meriv çawa vê daneyê ji nû ve hevseng bike. Û di şûna wê de hûn ne di nav 5 perçeyan, lê di nav 1 perçeyan de vediqetînin. Û dûv re hûn her yek ji van mîkroşardan li ser serverek cûda nexşe dikin. Û hûn ê, wek nimûne, 000 ClickHouses li ser yek serverê bistînin. Mînakên li ser portên cihê an databasên cihêreng veqetînin.
Lê ev di ClickHouse de ne pir baş e. Ji ber ku yek mînakek ClickHouse jî hewl dide ku hemî çavkaniyên serverê yên berdest bikar bîne da ku yek daxwazek pêvajoyê bike. Ango, we celebek serverek heye û ew, mînakî, 56 korikên pêvajoyê hene. Hûn pirsek dimeşînin ku yek saniye digire û ew ê 56 core bikar bîne. Û heke we 200 ClickHouses li wir li ser yek serverê bicîh bikin, wê hingê derdikeve ku dê 10 mijar dest pê bikin. Bi gelemperî, her tişt dê pir xirab be.
Sedemek din jî ew e ku dabeşkirina kar li ser van mînakan dê neyeksan be. Hin dê zûtir biqedînin, hin dê paşê biqedin. Ger ev hemî di yek nimûne de qewimî, wê hingê ClickHouse bixwe dê bizanibe ka meriv çawa bi rast daneyan di nav mijaran de belav dike.
Û sedemek din jî ev e ku hûn ê bi rêya TCP-ê pêwendiya interprocessor hebe. Pêdivî ye ku dane bêne serialîzekirin, deserialîzekirin, û ev hejmareke mezin a mîkroşardan e. Ew ê bi tenê bi bandor nexebite.
Antîpatternek din, her çend ew bi zor dikare wekî antîpattern were gotin. Ev mîqdarek mezin a pêş-kombûnê ye.
Bi gelemperî, pêş-kombûn baş e. Milyar rêzên we hebûn, we ew berhev kir û ew bû 1 rêz, û naha pirs di cih de tê pêkanîn. Her tişt mezin e. Hûn dikarin vê yekê bikin. Û ji bo vê yekê, tewra ClickHouse jî celebek tabloyek taybetî ye, AggregatingMergeTree, ku dema ku dane tê danîn berhevkirina zêde pêk tîne.
Lê carinan hene ku hûn difikirin ku em ê daneyên bi vî rengî berhev bikin û daneyên bi vî rengî berhev bikin. Û li hin dezgehên cîran, ez jî naxwazim bibêjim kîjan, ew tabloyên SummingMergeTree bikar tînin da ku ji hêla mifteya bingehîn ve kurt bikin, û nêzîkê 20 stûn wekî mifteya bingehîn têne bikar anîn. Tenê di rewşê de, min navên hin stûnan ji bo nepenîtiyê guhart, lê ew pir zêde ye.
Û pirsgirêkên wiha derdikevin. Pêşîn, hêjeya daneyên we pir kêm nabe. Ji bo nimûne, ew sê caran kêm dibe. Sê caran dê bihayek baş be ku meriv kapasîteyên analîtîk ên bêsînor ên ku derdikevin heke daneyên we neyên berhev kirin. Ger dane berhev kirin, wê hingê li şûna analîtîk hûn tenê statîstîkên xemgîn digirin.
Û çi taybetmendiya wê heye? Rastî ev e ku ev kesên ji beşa cîran carinan diçin û dipirsin ku stûnek din li mifteya bingehîn zêde bikin. Ango me daneyan bi vî rengî berhev kir, lê niha em hinekî din dixwazin. Lê ClickHouse xwedan mifteyek bingehîn a guhêrbar tune. Ji ber vê yekê, divê em hin tîpan di C++ de binivîsin. Û ez ji senaryoyan hez nakim, her çend ew di C ++ de bin.
Û heke hûn li ku ClickHouse ji bo çi hate afirandin, wê hingê daneyên ne-hevkirî tam senaryoya ku ew ji dayik bûye ye. Heke hûn ClickHouse-ê ji bo daneyên ne-hevkirî bikar tînin, wê hingê hûn wê rast dikin. Ger hûn berhev bikin, ev carinan efûkirin e.
Bûyerek din a balkêş pirsên di çerxek bêdawî de ye. Carinan ez diçim hin serverek hilberînê û li wir li navnîşa pêvajoyê ya pêşandanê dinihêrim. Û her gava ku ez kifş dikim ku tiştek tirsnak diqewime.
Mînakî, bi vî rengî. Di cih de diyar e ku her tişt dikare di yek daxwazê de were kirin. Tenê url û navnîşê li wir binivîsin.
Çima gelek pirsên weha di xelekek bêdawî de xirab in? Ger indexek neyê bikar anîn, wê hingê hûn ê li ser heman daneyê gelek derbas bibin. Lê heke index were bikar anîn, mînakî, we mifteyek bingehîn ji bo ru heye û hûn li wir url = tiştek dinivîsin. Û hûn difikirin ku heke tenê yek URL ji sifrê were xwendin, dê her tişt baş be. Lê bi rastî na. Ji ber ku ClickHouse her tiştî bi koman dike.
Gava ku ew hewce dike ku hin rêzek daneyan bixwîne, ew hinekî din dixwîne, ji ber ku index li ClickHouse kêm e. Ev index nahêle ku hûn di tabloyê de rêzek kesane bibînin, tenê rêzek cûreyek. Û daneyan di blokan de têne berhev kirin. Ji bo ku hûn yek rêzek bixwînin, hûn hewce ne ku tevahiya blokê bigirin û jê vekin. Û heger hûn komek pirsan dikin, hûn ê gelek hevûdu hebin, û hûn ê gelek kar hebin ku hûn dîsa û dîsa bikin.
Û wekî bonus, hûn dikarin bala xwe bidin ku di ClickHouse de divê hûn netirsin ku tewra megabytes û hetta bi sedan megabyte veguhezînin beşa IN. Ji pratîka me tê bîra min ku heke di MySQL de em komek nirxan veguhezînin beşa IN, mînakî, em 100 megabyte hin hejmaran vediguhezînin wir, wê hingê MySQL 10 gigabayt bîranînê dixwe û tiştek din jê re nayê, her tişt xirab dixebite.
Û ya duyemîn jî ev e ku di ClickHouse de, heke pirsên we indexek bikar bînin, wê hingê ew her gav ji şopandinek bêkêmasî hêdîtir nabe, ango heke hûn hewce ne ku hema hema tevahî tabloyê bixwînin, ew ê bi rêz biçe û tevahî tabloyê bixwîne. Bi gelemperî, ew ê wê bi serê xwe fêhm bike.
Lê dîsa jî hinek zehmetî hene. Mînakî, rastiya ku IN bi jêrpirsînek pêvekê bikar nayîne. Lê ev pirsgirêka me ye û divê em çareser bikin. Li vir tiştek bingehîn nîne. Em ê çareser bikin*.
Tiştek din a balkêş ev e ku heke we daxwazek pir dirêj hebe û pêvajoyek daxwaziya belavkirî di pêş de be, wê hingê ev daxwaziya pir dirêj dê ji her serverê re bê tewandin were şandin. Ji bo nimûne, 100 megabytes û 500 server. Û, li gorî vê yekê, hûn ê 50 gigabayt li ser torê werin veguheztin. Ew ê were veguheztin û paşê her tişt dê bi serfirazî were qedandin.
* jixwe bikar tîne; Her tişt wekî ku soz dabû rast kirin.
Û bûyerek pir gelemperî dema ku daxwaz ji API-ê têne. Mînakî, we celebek karûbarê xwe çêkir. Û heger kesek hewceyê xizmeta we be, wê hingê hûn API-ê vedikin û bi rastî du roj şûnda hûn dibînin ku tiştek nayê fêm kirin diqewime. Her tişt zêde barkirî ye û hin daxwazên tirsnak têne ku diviyabû qet çênebûna.
Û tenê yek çareserî heye. Ger we API vekir, wê hingê hûn neçar in ku wê qut bikin. Mînakî, hin cûre kotayan destnîşan bikin. Vebijarkên din ên normal tune. Wekî din, ew ê tavilê senaryoyekê binivîsin û dê pirsgirêk derkevin.
Û ClickHouse taybetmendiyek taybetî heye - hesabkirina kotayê. Wekî din, hûn dikarin mifteya kotaya xwe veguherînin. Ev, wek nimûne, nasnameya bikarhênerê navxweyî ye. Û kota dê ji bo her yek ji wan serbixwe bêne hesibandin.
Niha tiştek din a balkêş. Ev dubarekirina destan e.
Ez gelek bûyeran dizanim ku, tevî ku ClickHouse xwedan piştevaniya dubarekirinê ya çêkirî ye, mirov ClickHouse bi destan dubare dikin.
prensîb çi ye? Xetek we ya hilberandina daneyê heye. Û ew serbixwe dixebite, wek nimûne, di navendên daneyên cuda de. Hûn di ClickHouse de heman daneyan bi heman rengî dinivîsin. Rast e, pratîk destnîşan dike ku dê dane ji ber hin taybetmendiyên di koda we de hîn jî ji hev cuda bibin. Ez hêvî dikim ku ew di ya we de ye.
Û dem bi dem hûn ê hîn jî neçar bibin ku bi destan hevdeng bikin. Mînakî, mehê carekê rêvebiran rsync dikin.
Bi rastî, karanîna dubarekirina ku li ClickHouse hatî çêkirin pir hêsantir e. Lê dibe ku hin nakokî hebin, ji ber ku ji bo vê yekê hûn hewce ne ku ZooKeeper bikar bînin. Ez ê li ser ZooKeeper tiştek xirab nebêjim, di prensîbê de, pergal dixebite, lê diqewime ku mirov wê ji ber java-phobia bikar neynin, ji ber ku ClickHouse pergalek wusa baş e, bi C++ hatî nivîsandin, ku hûn dikarin bikar bînin û dê her tişt baş bibe. Û ZooKeeper di java de ye. Û bi awayekî hûn jî naxwazin lê binihêrin, lê hingê hûn dikarin dubarekirina destan bikar bînin.
ClickHouse pergalek pratîkî ye. Ew hewcedariyên we digire. Ger we replikasyona bi destan heye, wê hingê hûn dikarin tabloyek Belavkirî biafirînin ku li kopiyên desta we dinihêre û di navbera wan de têkçûnek çêdike. Tewra vebijarkek taybetî jî heye ku dihêle hûn ji flopsan dûr bikevin, hetta ku xetên we bi rêkûpêk ji hev cuda bibin.
Ger hûn motorên tabloya primitive bikar bînin dibe ku pirsgirêkên din derkevin holê. ClickHouse avakerek e ku komek motorên tabloyê yên cihêreng hene. Ji bo hemî bûyerên giran, wekî ku di belgeyê de hatî nivîsandin, tabloyên ji malbata MergeTree bikar bînin. Û hemî yên mayî - ev ji bo dozên kesane an ji bo ceribandinan wusa ye.
Di tabloyek MergeTree de, ne hewce ye ku hûn tarîx û dem hebin. Hûn dikarin hîn jî bikar bînin. Ger dîrok û dem tune be, binivîse ku standard 2000 e. Ev ê bixebite û dê çavkaniyan ne hewce bike.
Û di guhertoya nû ya serverê de, tewra hûn dikarin diyar bikin ku we dabeşkirina xwerû bêyî mifteya dabeşkirinê heye. Wê wisa be.
Ji hêla din ve, hûn dikarin motorên tabloya primitive bikar bînin. Mînakî, carekê daneyan dagirin û binihêrin, bizivirînin û jêbikin. Hûn dikarin Log bikar bînin.
An jî hilanîna cildên piçûk ji bo pêvajoyek navîn StripeLog an TinyLog e.
Heke mîqdara daneyê piçûk be û hûn dikarin bi tenê tiştek di RAM-ê de biqelînin, bîranîn dikare were bikar anîn.
ClickHouse bi rastî ji daneyên nûvekirî hez nake.
Li vir mînakek tîpîk e. Ev hejmareke mezin a URLan e. Tu wan di tabloya din de bikî. Û dûv re wan biryar da ku bi wan re JOIN bikin, lê ev ê wekî qaîdeyek nexebite, ji ber ku ClickHouse tenê Hash JOIN piştgirî dike. Ger ji bo gelek daneyên ku divê werin girêdan RAM têr nebe, wê hingê JOIN dê nexebite*.
Ger daneya kardînalîteya bilind e, wê hingê netirsin, wê bi rengek denormalîzekirî hilînin, URL rasterast di tabloya sereke de cih digirin.
* û naha ClickHouse di heman demê de tevlîheviyek hevgirtinê jî heye, û ew di şert û mercên ku daneyên navîn di RAM-ê de cîh nagirin de dixebite. Lê ev bêbandor e û pêşniyar di meriyetê de dimîne.
Çend mînakên din, lê ez jixwe guman dikim ka ew dij-pattern in an na.
ClickHouse yek xeletiyek naskirî heye. Ew nizane çawa nûve bike*. Di hin awayan de, ev jî baş e. Ger hin daneyên we yên girîng hebin, mînakî, hesabkirin, wê hingê kes nikare wê bişîne, ji ber ku nûvekirin tune.
* Piştgiriya nûvekirin û jêbirina di moda hevîrê de demek dirêj berê hate zêdekirin.
Lê hin awayên taybetî hene ku destûrê didin nûvekirinên mîna ku di paşerojê de bin. Mînakî, tabloyên mîna ReplaceMergeTree. Ew di dema yekbûnên paşîn de nûvekirinan çêdikin. Hûn dikarin vê bi karanîna tabloya optîmîzekirinê zor bikin. Lê pir caran vê yekê nekin, ji ber ku ew ê dabeşkirinê bi tevahî binivîsîne.
JOINên belavbûyî yên li ClickHouse jî ji hêla plansazkerê pirsê ve nebaş têne rêve kirin.
Xerab, lê carinan Ok.
Bikaranîna ClickHouse tenê ji bo xwendina daneyan bi karanîna hilbijartî *.
Ez ê pêşniyar nakim ku ClickHouse ji bo hesabên giran bikar bînin. Lê ev bi tevahî ne rast e, ji ber ku em berê ji vê pêşniyarê dûr dikevin. Û me vê dawîyê şiyana sepandina modelên fêrbûna makîneyê li ClickHouse - Catboost zêde kir. Û ew min aciz dike ji ber ku ez difikirim, "Çi tirsnak e. Ev çend çerxên per byte derdikeve! Ez bi rastî nefret dikim ku demjimêrên li ser bytes winda bikin.
Lê netirsin, ClickHouse saz bikin, dê her tişt baş be. Ger tiştek hebe, civakek me heye. Bi awayê, civak tu yî. Û heke pirsgirêkên we hebin, hûn dikarin bi kêmanî biçin sohbeta me, û hêvîdarim ku ew ê ji we re bibin alîkar.
Pirsên
Spas ji bo raporê! Ez dikarim li ku derê gilî bikim li ser têkçûna ClickHouse?
Hûn dikarin niha ji min re şexsî gilî bikin.
Min herî dawî dest bi karanîna ClickHouse kir. Min yekser pêwendiya cli avêt.
Çi puan e.
Demek şûnda min server bi hilbijarkek piçûk qut kir.
Tu xwedî talent.
Min xeletiyek GitHub vekir, lê ew paşguh kirin.
Ka em bibînin.
Alexey ez xapandim da ku ez beşdarî raporê bibim, soz da ku ez ji min re vebêjim ka hûn çawa digihîjin daneyên hundur.
Ew pir hêsan e.
Min doh ev yek fêm kir. Zêdetir taybetmendî.
Li wir hîleyên tirsnak nîn in. Tenê blok-bi-block compression heye. Vebijêrk LZ4 e, hûn dikarin ZSTD * çalak bikin. Blokên ji 64 kilobyte heta 1 megabyte.
* Di heman demê de piştgirî ji bo kodekên berhevkirina pispor jî heye ku dikare di zincîreyekê de bi algorîtmayên din re were bikar anîn.
Ma blokên tenê daneyên xav in?
Bi tevahî ne xav. Array hene. Ger stûnek jimareyî ya we hebe, wê hingê hejmarên li pey hev di rêzek de têne danîn.
Diyar e.
Alexey, mînakek ku bi uniqExact-ê li ser IP-yan bû, ango rastiya ku uniqExact ji hêla jimaran ve ji hêla rêzan ve bêtir tê hesibandin, û hwd. Ger em di dema rastnivîsînê de bi guhên xwe fêkiyek bi kar bînin? Ango, we dixuye ku we got ku li ser dîska me ew ne pir cûda ye. Ger em rêzikên ji dîskê bixwînin û avêtin, dê berhevokên me zûtir bibin an na? An jî em ê dîsa jî li vir hinekî qezenc bikin? Ji min re dixuye ku we ev ceriband, lê ji ber hin sedeman ew di pîvanê de destnîşan nekir.
Ez difikirim ku ew ê ji bêyî avêtinê hêdîtir be. Di vê rewşê de, navnîşana IP-ê divê ji rêzê were pars kirin. Bê guman, li ClickHouse, parkirina navnîşana IP-ya me jî xweşbîn e. Me gelek hewl da, lê li wir hejmarên we bi forma deh hezarî hatine nivîsandin. Pir nerehetî. Ji hêla din ve, fonksiyona uniqExact dê li ser rêzan hêdîtir bixebite, ne tenê ji ber ku ev rêz in, lê di heman demê de ji ber ku pisporiyek cûda ya algorîtmayê jî tê hilbijartin. Strings bi tenê bi rengek cûda têne hilberandin.
Ger em celebek daneya primitivetir bigirin? Mînakî, me id-ya bikarhênerê ya ku tê de heye nivîsand, wekî rêzek nivîsand, û dûv re jî xêz kir, gelo ew ê xweştir be an na?
Ez guman dikim. Ez difikirim ku ew ê hê xemgîntir be, ji ber ku her tiştî, parskirina hejmar pirsgirêkek ciddî ye. Ji min re dixuye ku vî hevkarê tewra raporek da ku çiqas zehmet e parkirina hejmaran di forma deh hezarî de, lê dibe ku ne.
Alexey, ji bo raporê gelek spas! Û ji bo ClickHouse gelek spas! Li ser planan pirsek min heye. Ma ji bo taybetmendiyekê plan hene ku ferhengan bi tevahî nûve bikin?
Ango rebootek qismî?
Yes Yes. Mîna şiyana danîna qadek MySQL li wir, ango piştî nûvekirinê da ku heke ferheng pir mezin be tenê ev dane were barkirin.
Taybetmendiyek pir balkêş. Û ez difikirim ku hinek kesan di sohbeta me de pêşniyar kir. Dibe ku ew jî tu bûya.
Ez wisa nafikirim.
Baş e, naha derket holê ku du daxwaz hene. Û hûn dikarin hêdî hêdî dest bi kirina wê bikin. Lê ez dixwazim di cih de we hişyar bikim ku ev taybetmendî ji bo pêkanîna pir hêsan e. Ango, di teoriyê de, hûn tenê hewce ne ku jimareya guhertoyê di tabloyê de binivîsin û dûv re binivîsin: guhertoya ji wilo kêmtir. Ev tê wê wateyê ku, bi îhtîmalek mezin, em ê vê yekê pêşkêşî dilsozan bikin. Ma hûn dilsozek in?
Erê, lê, mixabin, ne di C ++ de.
Ma hevkarên we dizanin ka meriv çawa bi C ++ dinivîse?
Ez ê kesek bibînim.
Ecêb*.
* Taybetmendî du meh piştî raporê hate zêdekirin - nivîskarê pirsê ew pêşxist û ya xwe şand .
Spas!
Slav! Spas ji bo raporê! We behs kir ku ClickHouse di vexwarina hemî çavkaniyên ku jê re peyda dibin pir baş e. Û axaftvanê li kêleka Luxoft li ser çareseriya xwe ji bo Russian Post axivî. Wî got ku wan bi rastî ji ClickHouse hez kir, lê wan ew li şûna hevrikê xwe yê sereke bi kar neanî, ji ber ku ew hemî CPU-yê dixwar. Û wan nekarî wê bi mîmariya xwe ve, bi dokeran ve têxin nav ZooKeeper xwe. Ma gengaz e ku meriv bi rengek ClickHouse sînordar bike da ku ew her tiştê ku jê re peyda dibe nexwe?
Erê, ew gengaz e û pir hêsan e. Heke hûn dixwazin ku hindik naverok bixwin, wê hingê tenê binivîsin set max_threads = 1. Û ew e, ew ê daxwazê di yek bingehîn de bicîh bike. Wekî din, hûn dikarin ji bo bikarhênerên cûda mîhengên cihêreng diyar bikin. Ji ber vê yekê pirsgirêk tune. Û ji hevkarên xwe yên ji Luxoft re bêjin ku ne baş e ku wan ev mîheng di belgeyê de nedît.
Alexey, silav! Ez dixwazim li ser vê pirsê bipirsim. Ev ne cara yekem e ku min dibihîst ku gelek kes dest bi karanîna ClickHouse-ê wekî hilanînê ji bo têketinan dikin. Di raporê de we got ku hûn vê nekin, ango hûn ne hewce ne ku hûn têlên dirêj hilînin. Hûn li ser wê çi difikirin?
Ya yekem, têketin, wekî qaîdeyek, ne rêzikên dirêj in. Bê guman, îstîsna hene. Mînakî, hin karûbarek ku di java-yê de hatî nivîsandin îstîsnayek derdixe, ew tê tomar kirin. Û bi vî awayî di pêlekek bêdawî de, û cîhê li ser dîska hişk diqede. Çareserî pir hêsan e. Ger xetên pir dirêj in, paşê wan bibirrin. Wateya dirêj çi ye? Bi dehan kilobyt xerab in*.
* di guhertoyên herî paşîn ên ClickHouse de, "granulariya pêveka adaptive" tê çalak kirin, ku bi piranî pirsgirêka hilanîna rêzên dirêj ji holê radike.
Kilobyte normal e?
Baş e.
Slav! Spas ji bo raporê! Min berê di sohbetê de ev pirs kir, lê nayê bîra min gelo min bersivek wergirt. Ma plan hene ku bi rengekî CTE beşa WITH berfireh bikin?
Hêşta na. Beşa me ya BI WITH hinekî bêaqil e. Ew ji bo me wekî taybetmendiyek piçûk e.
Ez dizanim. Sipas ji were!
Spas ji bo raporê! Gelek balkêş! Pirsa gerdûnî. Ma ti plan hene ku jêbirina daneyan biguhezînin, dibe ku di forma celebek stûyê de?
Pêdivî ye. Ev karê me yê yekem e di rêza me de. Em niha bi aktîvî difikirin ka meriv çawa her tiştî bi rêkûpêk bike. Û divê hûn dest bi tikandina klavyeyê * bikin.
* pêl bişkokên li ser klavyeyê kir û her tişt kir.
Ma ev ê bi rengek bandor li ser performansa pergalê bike an na? Dê têxistin bi qasî ku niha ye bilez be?
Dibe ku xwe jêbirin û nûvekirin bixwe pir giran bin, lê ev ê bandorê li performansa hilbijarkan an performansa insertan neke.
Û pirsek piçûktir. Di pêşkêşiyê de we li ser mifteya bingehîn axivî. Li gorî vê yekê, dabeşkirina me heye, ku ji hêla xwerû mehane ye, rast e? Û gava ku em rêzek tarîxek ku di mehekê de cih digire destnîşan dikin, wê hingê tenê ev dabeşkirin tê xwendin, rast?
Erê
Pirsek. Ger em nekarin mifteyek bingehîn hilbijêrin, wê hingê rast e ku em wiya bi taybetî li gorî qada "Dîrok" bikin da ku di paşerojê de kêmtir vesazkirina van daneyan hebe da ku ew bi rengek birêkûpêk bi cih bibe? Ger pirsên we yên rêzê tune ne û hûn nekarin mifteyek bingehîn jî hilbijêrin, gelo hêja ye ku tarîxek di mifteya bingehîn de bihêlin?
Erê
Dibe ku maqûl be ku meriv di mifteya bingehîn de zevîyek bihêle ku heke ew li gorî vê zeviyê were rêz kirin dê daneyan çêtir bitewîne. Mînakî, nasnameya bikarhêner. Bikarhêner, ji bo nimûne, diçe heman malperê. Di vê rewşê de, nasnameya bikarhêner û dema xwe bixin. Û wê hingê daneyên we dê çêtir werin berhev kirin. Di derbarê tarîxê de, heke we bi rastî li ser tarîxan nebin û qet pirsên rêzê tunebin, wê hingê ne hewce ye ku hûn tarîxê têxin mifteya bingehîn.
OK gelek spas!
Source: www.habr.com