Cassandra. Ger hûn tenê Oracle-ê dizanin meriv çawa nemire

Hey Habr.

Navê min Misha Butrimov e, ez dixwazim ji we re hinekî behsa Cassandra bikim. Çîroka min dê ji wan kesên ku tu carî bi databasên NoSQL re rû bi rû nebûn re bikêr be - ew gelek taybetmendiyên pêkanîn û xeletiyên ku hûn hewce ne ku pê zanibin hene. Û heke we ji bilî Oracle an databasek pêwendiyek din tiştek nedîtiye, ev tişt dê jiyana we xilas bikin.

Kassandra çi baş e? Ew danegehek NoSQL ye ku bêyî xalek têkçûnek yekane hatî sêwirandin ku baş dipîve. Heke hûn hewce ne ku ji bo hin databasê çend terabytes zêde bikin, hûn bi tenê girêkan li zengilê zêde bikin. Wê li navendek daneya din berfireh bikin? Giran li komê zêde bikin. RPS-ya pêvajoyî zêde bikin? Giran li komê zêde bikin. Di heman demê de berevajî vê yekê jî dixebite.

Cassandra. Ger hûn tenê Oracle-ê dizanin meriv çawa nemire

Wekî din ew di çi de baş e? Ew li ser birêvebirina gelek daxwazan e. Lê çiqas pir e? Di çirkeyê de 10, 20, 30, 40 hezar daxwaz ne pir in. 100 hezar daxwaz di çirkeyê de ji bo tomarkirinê - jî. Şîrket hene ku gotin ku ew di çirkeyê de 2 mîlyon daxwaz dikin. Dibe ku ew ê pê bawer bikin.

Û di prensîbê de, Cassandra yek cûdahiyek mezin ji daneyên pêwendiyê heye - ew bi wan re qet ne wekhev e. Û ev pir girîng e ku bîr bînin.

Ne her tiştê ku wekî hev xuya dike bi heman rengî dixebite

Carekê hevkarek hat ba min û jê pirsî: "Li vir zimanek lêpirsînê ya CQL Cassandra heye, û daxuyaniyek hilbijartî heye, li ku ye, heye û heye. Ez nameyan dinivîsim û naxebite. Çima?". Dermankirina Cassandra wekî databasek têkilî rêyek bêkêmasî ye ku meriv xwekujiya tundûtûjî bike. Û ez wê napejirînim, ew li Rûsyayê qedexe ye. Hûn ê tenê tiştek xelet dîzayn bikin.

Mesela, xerîdarek tê cem me û dibêje: “Em ji bo rêzefîlmên TV-yê databasekê, yan jî ji bo pelrêça reçeteyê databasek çêbikin. Em ê li wir xwarinên xwarinê hebin an jî lîsteya rêzefîlm û lîstikvanan tê de hebin.” Em bi kêfxweşî dibêjin: "Em herin!" Tenê du bytes, çend nîşanan bişînin û hûn qediyan, her tişt dê pir zû û pêbawer bixebite. Û her tişt baş e heta ku xerîdar werin û nebêjin ku jinên malê jî pirsgirêkek berevajî çareser dikin: lîsteya wan hilberan heye, û ew dixwazin bizanibin ka ew dixwazin çi xwarinê çêkin. Tu mirî yî.

Ji ber vê yekê ye ku Cassandra databasek hîbrîd e: ew di heman demê de nirxek sereke peyda dike û daneyan di stûnên berfireh de hilîne. Di Java an Kotlin de, ew dikare bi vî rengî were şirove kirin:

Map<RowKey, SortedMap<ColumnKey, ColumnValue>>

Ango nexşeyek ku nexşeyek rêzkirî jî tê de ye. Mifteya yekem a vê nexşeyê mifteya rêz an bişkojka dabeşkirinê ye - mifteya dabeşkirinê. Mifteya duyemîn, ku mifteya nexşeyek berê veqetandî ye, mifteya Clustering e.

Ji bo ronîkirina belavkirina databasê, werin em sê girêkan xêz bikin. Naha hûn hewce ne ku fêm bikin ka meriv çawa daneyan di nav girêkan de vediqetîne. Ji ber ku ger em her tiştî bixin yek (bi awayê, dibe ku hezar, du hezar, pênc hebin - bi qasî ku hûn dixwazin), ev bi rastî ne li ser belavkirinê ye. Ji ber vê yekê, em hewceyê fonksiyonek matematîkî ye ku dê hejmarek vegere. Tenê hejmarek, navgînek dirêj a ku dê bikeve nav hin rêzan. Û em ê yek girêk ji bo rêzek, ya duyemîn ji bo ya duyemîn, ya n-ya ji bo n-yê berpirsiyar bin.

Cassandra. Ger hûn tenê Oracle-ê dizanin meriv çawa nemire

Ev hejmar bi karanîna fonksiyonek hash tê girtin, ku li ser tiştê ku em jê re dibêjin bişkojka Parvekirinê tê sepandin. Ev stûna ku di dîrektîfa mifteya seretayî de hatî destnîşan kirin e, û ev stûna ku dê bibe mifteya yekem û herî bingehîn a nexşeyê ye. Ew diyar dike ku kîjan node dê kîjan daneyê bistîne. Tabloyek li Cassandra hema hema bi heman hevoksaziya SQL-ê tê afirandin:

CREATE TABLE users (
	user_id uu id,
	name text,
	year int,
	salary float,
	PRIMARY KEY(user_id)

)

Mifteya Seretayî di vê rewşê de ji yek stûnê pêk tê, û ew jî mifteya dabeşkirinê ye.

Dê bikarhênerên me çawa tevbigerin? Hin dê biçin yek girêk, hin ji bo yekî din, û hin ji bo sêyem. Encam tabloyek hash a asayî ye, ku wekî nexşeyek jî tê zanîn, ku di Python de wekî ferhengek jî tê zanîn, an avahiyek nirxa Key ya hêsan e ku em dikarin jê re hemî nirxan bixwînin, bi kilîtê bixwînin û binivîsin.

Cassandra. Ger hûn tenê Oracle-ê dizanin meriv çawa nemire

Hilbijêre: gava ku destûr bide fîlterkirin vediguhere şopandina tevahî, an tiştê ku neyê kirin

Ka em hin daxuyaniya bijartî binivîsin: select * from users where, userid = . Mîna Oracle derdikeve: em hilbijartî dinivîsin, şert û merc diyar dikin û her tişt dixebite, bikarhêner wê distînin. Lê heke hûn, mînakî, bikarhênerek bi salek diyarkirî hilbijêrin, Cassandra gilî dike ku ew nikare daxwazê ​​bicîh bîne. Ji ber ku ew bi tevahî tiştek nizane ka em çawa daneyên di derbarê sala jidayikbûnê de belav dikin - tenê stûnek wê wekî kilît hatî destnîşan kirin. Dû re dibêje, "Temam, ez hîn jî dikarim vê daxwazê ​​bi cih bînim. Destûra fîlterkirinê zêde bikin." Em dîrektîfê lê zêde dikin, her tişt dixebite. Û di vê gavê de tiştek tirsnak diqewime.

Dema ku em li ser daneyên testê dimeşînin, her tişt baş e. Û gava ku hûn di hilberînê de pirsek pêk tînin, li ku derê me, mînakî, 4 mîlyon tomar hene, wê hingê her tişt ji bo me ne pir baş e. Ji ber ku destûr fîlterkirin rêwerzek e ku destûrê dide Cassandra ku hemî daneyên vê tabloyê ji hemî girêk, hemî navendên daneyê (heke pir ji wan di vê komê de hebin) berhev bike û tenê wê hingê wê fîlter bike. Ev analogek Full Scan e, û çu kes jê kêfxweş nabe.

Ger em tenê ji hêla ID-ê ve hewceyê bikarhêneran bin, em ê bi vê yekê re baş bibin. Lê carinan pêdivî ye ku em pirsên din binivîsin û li ser hilbijartinê qedexeyên din ferz bikin. Ji ber vê yekê, em bîr tînin: ev hemî nexşeyek e ku mifteyek dabeşkirinê heye, lê di hundurê wê de nexşeyek rêzkirî ye.

Û kilîteke wê jî heye, ku em jê re dibêjin Kîlava Clustering. Ev kilît, ku di encamê de, ji stûnên ku em hildibijêrin pêk tê, bi alîkariya wê Cassandra fêm dike ka daneyên wê bi fizîkî çawa têne rêz kirin û dê li ser her girêkekê cih bigirin. Ango, ji bo hin bişkojên Dabeşkirinê, bişkojka Clustering dê ji we re bêje ka meriv çawa daneyê di vê darê de bikişîne, ew ê li wir çi cîh bigire.

Ev bi rastî darek e, berhevkarek tenê li wir tê gotin, ku em komek stûnên di forma tiştekê de derbas dikin, û ew jî wekî navnîşek stûnan tê destnîşan kirin.

CREATE TABLE users_by_year_salary_id (
	user_id uuid,
	name text,
	year int,
	salary float,
	PRIMARY KEY((year), salary, user_id)

Bala xwe bidin dîrektîfa mifteya seretayî; argumana wê ya yekem (di rewşa me de, sal) her gav mifteya dabeşkirinê ye. Ew dikare ji yek an çend stûnan pêk were, ne girîng e. Ger çend stûn hebin, pêdivî ye ku ew dîsa di nav kevanan de were rakirin da ku pêş-processorê ziman fam bike ku ev mifteya Seretayî ye, û li pişt wê hemî stûnên din mifteya Clustering in. Di vê rewşê de, ew ê bi rêza ku xuya dibin di berhevkarê de werin veguheztin. Ango stûna yekem girîngtir e, ya duyemîn kêm girîng e û hwd. Çawa em dinivîsin, wek nimûne, ji bo çînên daneyê zeviyan wekhev dike: em qadan navnîş dikin, û ji bo wan em dinivîsin ka kîjan mezintir û kîjan piçûktir in. Di Cassandra de, ev bi nisbetî, zeviyên çîna daneyê ne, ku dê wekheviyên ku ji bo wê hatine nivîsandin werin sepandin.

Me veqetandek danîne û qedexeyan ferz dikin

Pêdivî ye ku hûn ji bîr nekin ku rêzika cûrbecûr (xwarin, hilkişin, her çi dibe bila bibe) di heman kêliyê de dema ku kilît tê çêkirin tê saz kirin û ew paşê nayê guhertin. Ew bi fizîkî diyar dike ka dê data çawa were rêz kirin û dê çawa were hilanîn. Heke hûn hewce ne ku bişkojka Clustering biguhezînin an rêzika birêkûpêk bikin, divê hûn tabloyek nû biafirînin û daneyan veguhezînin wê. Ev ê bi ya heyî re nexebite.

Cassandra. Ger hûn tenê Oracle-ê dizanin meriv çawa nemire

Me tabloya xwe bi bikarhêneran tije kir û dît ku ew pêşî li gorî sala jidayikbûnê, û dûv re jî li hundurê her girêkekê li gorî meaş û nasnameya bikarhêner ketin zengilê. Naha em dikarin bi danîna qedexeyan hilbijêrin.

Karkerê me dîsa xuya dike where, and, û em bikarhêneran digirin, û her tişt dîsa baş e. Lê heke em hewl bidin ku tenê beşek ji mifteya Clustering-ê û ya hindik girîng bikar bînin, wê hingê Cassandra wê tavilê gilî bike ku ew nikane di nexşeya me de cîhê ku ev tişt, ku van qadan ji bo berhevkara null û ev yek heye, bibîne. ku nû hatibû danîn, - ew li ku derê radizê. Ez ê neçar bikim ku hemî daneyan ji vê nodê dîsa bikişînim û wê parz bikim. Û ev analogek Full Scan di hundurê nodê de ye, ev xirab e.

Di her rewşek ne diyar de, tabloyek nû çêbikin

Ger em dixwazin bi nasname, an ji hêla temen, an ji hêla meaş ve bikaribin bikarhêneran bikin hedef, divê em çi bikin? Netişt. Tenê du tabloyan bikar bînin. Heke hûn hewce ne ku bi sê awayên cûda xwe bigihînin bikarhêneran, dê sê tablo hebin. Demên ku me cîhê li ser çolê xilas kir derbas bûn. Ev çavkaniya herî erzan e. Mesrefa wê ji dema bersivê pir kêmtir e, ku dikare ji bikarhêner re zirarê bike. Ji bo bikarhêner ku di saniyeyekê de tiştek werdigire ji 10 hûrdeman pir xweştir e.

Em cîhê nehewce bazirganî dikin û daneyên denormalîzekirî ji bo kapasîteya baş pîvandinê û pêbawer xebitandinê. Beriya her tiştî, bi rastî, komek ku ji sê navendên daneyê pêk tê, ku her yek ji wan pênc girêk hene, bi astek pejirandî ya parastina daneyê (gava ku tiştek winda nebe), dikare ji mirina yek navendek daneyê bi tevahî sax bimîne. Û du girêkên din di her du du mayî de. Û tenê piştî vê yekê pirsgirêk dest pê dikin. Ev zêdebûnek pir baş e, hêjayî çend ajokarên SSD û pêvajoyên zêde ye. Ji ber vê yekê, ji bo ku hûn Cassandra bikar bînin, ku qet ne SQL ye, ku tê de têkiliyek, mifteyên biyanî tune ne, hûn hewce ne ku rêzikên hêsan zanibin.

Em her tiştî li gorî daxwaza we dîzayn dikin. Ya sereke ne dane ye, lê serîlêdan çawa bi wê re dixebite. Ger hewce bike ku ew daneyên cûda bi awayên cûda an heman daneyan bi awayên cûda werbigire, divê em wiya bi rengek ku ji bo serîlêdanê rehet e deynin. Wekî din, em ê di Full Scan de têk biçin û Cassandra dê tu avantajê nede me.

Denormalîzekirina daneyan norm e. Em formên normal ji bîr dikin, êdî databasên me yên pêwendîdar nînin. Ger em tiştekî 100 carî deynin xwarê, ew ê 100 carî raze. Dîsa jî ji rawestandinê erzantir e.

Em bişkojkên ji bo dabeşkirinê hilbijêrin da ku ew bi gelemperî bêne belav kirin. Em naxwazin ku haşa kilîtên me bikeve nav rêzek teng. Yanî di mînaka jorîn de sala jidayikbûnê mînakeke xerab e. Bi rastî, baş e heke bikarhênerên me bi gelemperî li gorî sala jidayikbûnê têne belav kirin, û xirab e heke em li ser xwendekarên pola 5-an dipeyivin - dabeşkirina li wir dê ne pir baş be.

Di qonaxa afirandina Klavyeya Clustering de veqetandin carekê tê hilbijartin. Ger hewce be ku were guheztin, em neçar in ku tabloya xwe bi mifteyek cûda nûve bikin.

Û ya herî girîng: ger hewce bike ku em heman daneyan bi 100 awayên cihêreng vegerînin, wê hingê em ê 100 tabloyên cûda hebin.

Source: www.habr.com

Add a comment