Heta van demên dawî, Odnoklassniki bi qasî 50 TB daneyên ku di wextê rast de di SQL Serverê de hatî hilanîn hilanîn. Ji bo hêjmarek wusa, hema hema ne gengaz e ku meriv bi karanîna SQL DBMS-ê zû û pêbawer, û tewra gihîştina têkçûna-toleransê ya navenda daneyê peyda bike. Bi gelemperî, di rewşên weha de, yek ji depoyên NoSQL tê bikar anîn, lê ne her tişt dikare li NoSQL were veguheztin: hin sazî garantiyên danûstendinê ACID hewce dikin.
Vê yekê me rê da ku em hilanîna NewSQL bikar bînin, ango, DBMS-yek ku tolerasyona xeletiyê, pîvanbûn û performansa pergalên NoSQL peyda dike, lê di heman demê de garantiyên ACID-ê yên ku ji pergalên klasîk re naskirî diparêze. Sîstemên pîşesazî yên vê çîna nû kêm in, ji ber vê yekê me bi xwe pergalek weha pêk anî û xiste nav xebata bazirganî.
Çawa dixebite û çi qewimî - di bin qutkirinê de bixwînin.
Îro, temaşevanên mehane yên Odnoklassniki zêdetirî 70 mîlyon mêvanên bêhempa ne. Em mezintirîn torên civakî li cîhanê, û di nav bîst malperên ku bikarhêner herî zêde dema xwe li ser derbas dikin. Binesaziya OK bargiraniyên pir zêde hildibijêre: zêdetirî mîlyonek daxwazên HTTP / sec li pêş. Parçeyên fîloya serverê ya ku ji zêdetirî 8000 perçeyan pêk tê, nêzî hev in - li çar navendên daneya Moskowê, ku rê dide derengiya torê ya ji 1 ms kêmtir di navbera wan de.
Em ji sala 2010-an vir ve Cassandra bikar tînin, bi guhertoya 0.6-ê dest pê dike. Îro bi dehan kom di operasyonê de ne. Grûba herî bilez di çirkeyê de zêdetirî 4 mîlyon operasyonan dike, û yên herî mezin 260 TB diparêze.
Lêbelê, ev hemî komên NoSQL yên normal in ku ji bo hilanînê têne bikar anîn jimare. Me xwest ku depoya domdar a sereke, Microsoft SQL Server, ku ji damezrandina Odnoklassniki ve hatî bikar anîn, biguhezînin. Depo ji zêdetirî 300 makîneyên SQL Server Standard Edition pêk tê, ku tê de 50 TB dane hene - saziyên karsaziyê. Ev dane wekî beşek ji danûstendinên ACID-ê têne guhertin û hewce dike .
Ji bo belavkirina daneyan li ser girêkên SQL Server, me hem vertîkal û hem jî horizontal bikar anîn (parvekirin). Ji hêla dîrokî ve, me nexşeyek parvekirina daneya hêsan bikar anî: her hebûnek bi tokenek ve girêdayî bû - fonksiyonek nasnameya saziyê. Saziyên bi heman tokenê li ser heman servera SQL hatin danîn. Têkiliya master-detail hate bicîh kirin ku nîşaneyên tomarên sereke û zarokan her gav li hev dikevin û li ser heman serverê cih digirin. Di torgilokek civakî de, hema hema hemî tomar li ser navê bikarhêner têne hilberandin, ku tê vê wateyê ku hemî daneyên bikarhêner di nav yek binepergalek fonksiyonel de li ser yek serverê têne hilanîn. Ango, danûstendinek karsaziyê hema hema her gav tabloyên ji yek serverek SQL-ê vedihewîne, ku ev gengaz kir ku bi karanîna danûstendinên herêmî yên ACID-ê bihevrejiyana daneyê piştrast bike, bêyî hewcedariya karanîna danûstandinên ACID belav kirin.
Spas ji parvekirinê û bilezkirina SQL:
- Em astengên mifteya biyanî bikar naynin, ji ber ku dema parvekirina nasnameyê dibe ku li ser serverek din be.
- Ji ber barkirina zêde ya li ser CPU-ya DBMS, em prosedurên hilanîn û teşqeleyan bikar naynin.
- Em JOIN-ê ji ber hemî jorîn û gelek xwendinên bêserûber ji dîskê bikar naynin.
- Li derveyî danûstendinê, em asta îzolasyona Read Uncommitted bikar tînin da ku xitimiyan kêm bikin.
- Em tenê danûstendinên kurt dikin (bi navînî ji 100 ms kurttir).
- Em ji ber jimareya mezin a xitimandinê NÛZEXANÊN pir-rêzî û JERBEXT bikar naynin - em di carekê de tenê tomarek nûve dikin.
- Em her gav pirsan tenê li ser indexan dikin - pirsek bi plansaziyek tabloya tam ji bo me tê wateya barkirina databasê û sedema têkçûna wê.
Van gavan hişt ku em hema hema performansa herî zêde ji serverên SQL derxînin. Lê belê pirsgirêk her ku diçû zêdetir dibûn. Ka em li wan binêrin.
Pirsgirêkên SQL
- Ji ber ku me parvekirina xwe-nivîskî bikar anî, lê zêdekirina pariyên nû ji hêla rêveberan ve bi destan hate kirin. Hemî vê demê, kopiyên daneya berbelav ne daxwazên xizmetkirinê bûn.
- Her ku hejmara tomarên di tabloyê de zêde dibe, leza lêvekirin û guherandinê kêm dibe, dema ku îndeks li tabloyek heyî tê zêdekirin, leza bi faktorekê dadikeve û ji nû ve çêkirina indexan pêk tê;
- Di hilberînê de hebûna piçûkek Windows-ê ji bo SQL Server rêveberiya binesaziyê dijwar dike
Lê pirsgirêka sereke ev e
tolerans xelet
Pêşkêşkara SQL-ya klasîk xwedan tolerasyona xeletiya qels e. Ka em bibêjin ku we tenê serverek databasê heye, û ew her sê salan carekê têk diçe. Di vê demê de malper ji bo 20 hûrdeman dakêşin, ku ev tê qebûl kirin. Ger 64 serverên we hebin, wê hingê malper her sê hefte carekê têk diçe. Û heger 200 serverên we hene, wê hingê malper her hefte naxebite. Ev pirsgirêk e.
Ji bo baştirkirina tolerasyona xeletiya serverek SQL çi dikare were kirin? Wîkîpediya me vedixwîne avakirinê : ku di egera têkçûna yek ji pêkhateyan de paşgirek heye.
Ji bo vê yekê fîloya alavên biha hewce dike: gelek dubarekirin, fîbera optîkî, hilanîna hevpar, û tevlêbûna rezervan bi pêbawer naxebite: Nêzîkî 10% guheztinê bi têkçûna girêka paşvekêşanê wekî trênek li pişt girêka sereke bi dawî dibe.
Lê kêmasiya sereke ya komek wusa pir berdest hebûna sifir e heke navenda daneyê ya ku ew tê de ye têk biçe. Odnoklassniki çar navendên daneyê hene, û pêdivî ye ku em di bûyerek têkçûnek bêkêmasî de yek ji wan operasyonê piştrast bikin.
Ji bo vê yekê em dikarin bikar bînin dubarekirin di SQL Server de hatî çêkirin. Ev çareserî ji ber lêçûna nermalavê pir bihatir e û di warê dubarekirinê de pirsgirêkên naskirî dikişîne - derengiya danûstendinê ya nediyar bi dubarekirina hevdem û dereng di sepandina dubareyan de (û, wekî encam, guheztinên winda) bi dubarekirina asynchronous. Ya tê wateya vê vebijarkê bi tevahî ji me re nepêkan e.
Ji van hemû pirsgirêkan re çareseriyek radîkal lazim bû û me dest bi analîzkirina wan bi berfirehî kir. Li vir pêdivî ye ku em bi tiştê ku SQL Server bi gelemperî dike - danûstendinan nas bikin.
Danûstendina hêsan
Werin em ji nihêrîna bernamenûsek SQL-ya sepandî, danûstendina herî hêsan bifikirin: wêneyek li albûmê zêde bikin. Album û wêne di lewheyên cuda de têne hilanîn. Di albûmê de jimareyek wêneya gelemperî heye. Dûv re danûstendinek weha di gavên jêrîn de tê dabeş kirin:
- Em bi kilîtê albûmê asteng dikin.
- Di tabloya wêneyê de têketinek çêbikin.
- Ger wêne xwedî statûyek giştî be, wê hingê jimareyek wêneya giştî li albûmê zêde bikin, tomarê nûve bikin û danûstendinê bikin.
An jî di pseudocode de:
TX.start("Albums", id);
Album album = albums.lock(id);
Photo photo = photos.create(…);
if (photo.status == PUBLIC ) {
album.incPublicPhotosCount();
}
album.update();
TX.commit();Em dibînin ku senaryoya danûstendina karsaziyê ya herî gelemperî ev e ku meriv daneyên ji databasê di bîra servera serîlêdanê de bixwîne, tiştek biguhezîne û nirxên nû li databasê hilîne. Bi gelemperî di danûstendinek wusa de em çend saziyan, çend tabloyan nûve dikin.
Dema ku danûstendinek tête kirin, dibe ku guhartina hevdemî ya heman daneyê ji pergalek din çêbibe. Mînakî, Antispam dikare biryar bide ku bikarhêner bi rengek gumanbar e û ji ber vê yekê divê hemî wêneyên bikarhêner êdî ne gelemperî bin, pêdivî ye ku ew ji bo nermbûnê bêne şandin, ku tê vê wateyê ku wêne.statû bi nirxek din ve biguhezîne û jimareyên têkildar jê bike. Eşkere ye, heke ev operasyon bêyî garantiyên atomî yên sepanê û veqetandina guhertinên hevrikî pêk were, wek ku di , wê hingê encam dê ne be ya ku hewce ye - an jimareya wêneyê dê nirxa xelet nîşan bide, an jî dê hemî wêne ji bo nermbûnê neyên şandin.
Di tevahiya hebûna Odnoklassniki de gelek kodên bi heman rengî, ku di nav yek danûstendinê de saziyên karsaziyê yên cihêreng manîpule dikin, hatine nivîsandin. Li ser bingeha ezmûna koçberan ji NoSQL re Em dizanin ku dijwariya herî mezin (û veberhênana dem) ji pêşdebirina kodê tê ku hevgirtina daneyan biparêze. Ji ber vê yekê, me hewcedariya sereke ya hilanîna nû nirxand ku ji bo mantiqa serîlêdanê danûstendinên rastîn ên ACID be.
Pêdiviyên din, ne kêmtir girîng, ev bûn:
- Ger navenda daneyê têk biçe, divê hem xwendin û hem jî nivîsandina hilanîna nû hebe.
- Parastina leza pêşveçûna heyî. Ango, dema ku bi depoyek nû re dixebitin, pêdivî ye ku hêjmara kodê bi qasî hev be, hewce nebe ku tiştek li depoyê zêde bikin, algorîtmayan ji bo çareserkirina nakokiyan pêşve bibin, pêvekên duyemîn, hwd.
- Leza hilanîna nû diviyabû ku hem dema xwendina daneyan û hem jî dema ku danûstendinan bişopîne pir zêde be, ku bi bandor tê vê wateyê ku çareseriyên akademîk hişk, gerdûnî, lê hêdî, wek mînak, ne pêkan in. .
- Pîvana otomatîkî li ser-firînê.
- Bikaranîna serverên erzan ên birêkûpêk, bêyî ku hewcedariya kirîna hardware ya biyanî hebe.
- Ihtîmala pêşveçûna hilanînê ji hêla pêşdebirên pargîdanî ve. Bi gotinek din, pêşîn ji çareseriyên xwedan an çavkaniya vekirî re, bi tercîhî di Java de, hate dayîn.
Biryar, biryar
Bi analîzkirina çareseriyên gengaz, em gihîştin du vebijarkên mîmarî yên gengaz:
Ya yekem ev e ku meriv serverek SQL bigire û tolerasyona xeletiya hewce, mekanîzmaya pîvandinê, komika têkçûn, çareserkirina nakokî û danûstendinên ACID-ê yên pêbawer û bilez bicîh bîne. Me ev vebijark wekî pir ne-pîvan û kedkar nirxand.
Vebijarka duyemîn ev e ku meriv hilanînek NoSQL-ya amade bi pîvandina bicîhkirî, komikek têkçûyî, çareserkirina nakokî, û danûstendinan û SQL-ya xwe bicîh bîne. Di nihêrîna pêşîn de, tewra peywira bicihanîna SQL-ê, ku nebêjin danûstendinên ACID-ê, wekî karekî ku dê bi salan bigire xuya dike. Lê paşê me fêm kir ku taybetmendiya SQL ya ku em di pratîkê de bikar tînin bi qasî ANSI SQL dûr e ji ANSI SQL dûr. Dema ku em hîn nêziktir li CQL mêze bikin, me fêm kir ku ew bi ya ku ji me re hewce bû pir nêzîk bû.
Cassandra û CQL
Ji ber vê yekê, li ser Cassandra çi balkêş e, çi kapasîteyên wê hene?
Pêşîn, li vir hûn dikarin tabloyên ku cûrbecûr daneyan piştgirî dikin biafirînin, hûn dikarin li ser mifteya bingehîn SELECT an nûve bikin.
CREATE TABLE photos (id bigint KEY, owner bigint,…);
SELECT * FROM photos WHERE id=?;
UPDATE photos SET … WHERE id=?;Ji bo pêbaweriya hevgirtina daneya replica, Cassandra bikar tîne . Di rewşa herî hêsan de, ev tê vê wateyê ku gava sê kopiyên heman rêzê li ser girêkên cihêreng ên komê têne danîn, heke piraniya girêkan (ango du ji sê) serkeftina vê operasyona nivîsandinê piştrast bikin, nivîsandin serketî tê hesibandin. . Daneyên rêzê hevgirtî têne hesibandin heke, dema xwendinê, pirraniya girêkan hatin hilkolandin û wan piştrast kirin. Bi vî rengî, bi sê kopiyan re, heke yek nod têk biçe, hevgirtina daneya tam û tavilê tê garantî kirin. Vê nêzîkatiyê rê da me ku em nexşeyek hê pêbawertir bicîh bînin: her gav daxwaz ji her sê kopiyan re bişînin, li benda bersivek ji her du yên herî bilez in. Bersiva dereng a kopya sêyemîn di vê rewşê de tê avêtin. Nodek ku di bersivdayînê de dereng be dibe ku pirsgirêkên cidî hebin - frendan, berhevkirina çopê di JVM de, vegerandina rasterast a bîranînê di kernel Linux de, têkçûna hardware, qutbûna ji torê. Lêbelê, ev bi ti awayî bandorê li ser operasyon an daneyên xerîdar nake.
Nêzîkatiya gava ku em bi sê nokan re têkilî daynin û ji duyan bersivek werbigirin tê gotin : daxwazek ji bo kopiyên zêde jî berî ku ew "hilweşe" tê şandin.
Feydeyek din a Cassandra Batchlog e, mekanîzmayek ku piştrast dike ku komek guhartinên ku hûn dikin bi tevahî têne sepandin an jî qet nayên sepandin. Ev dihêle ku em A-yê di ACID de çareser bikin - atomî li derveyî qutiyê.
Tiştê herî nêzîk ji danûstendinên li Cassandra re tê gotin "". Lê ew ji danûstendinên ACID yên "rastîn" dûr in: bi rastî, ev fersendek e ku meriv bike li ser daneyên tenê yek tomar, bi karanîna lihevhatina bi karanîna protokola giran a Paxos. Ji ber vê yekê, leza danûstandinên weha kêm e.
Tiştê ku me li Cassandra winda kiribû
Ji ber vê yekê, me neçar ma ku li Cassandra danûstendinên rastîn ên ACID-ê bicîh bikin. Bi karanîna ku em dikarin bi hêsanî du taybetmendiyên din ên hêsan ên DBMS-a klasîk bicîh bînin: Endeksên bilez ên domdar, yên ku dihêlin ku em ne tenê ji hêla mifteya bingehîn ve hilbijarkên daneyê pêk bînin, û jeneratorek birêkûpêk a nasnameyên xweser ên monotonîk.
C*Yek
Bi vî awayî DBMSek nû çêbû C*Yek, ji sê celeb nodên serverê pêk tê:
- Storage - (hema hema) pêşkêşkerên standard Cassandra ku berpirsiyariya hilanîna daneyan li ser dîskên herêmî ne. Her ku bar û qebareya daneyan mezin dibe, mîqdara wan bi hêsanî dikare bi dehan û bi sedan were pîvan kirin.
- Koordînatorên danûstendinê - pêkanîna danûstendinan piştrast dikin.
- Xerîdar serverên serîlêdanê ne ku karûbarên karsaziyê bicîh dikin û danûstandinan didin destpêkirin. Dibe ku bi hezaran mişteriyên weha hebin.
Serverên her cûre parçeyek komikek hevpar in, protokola peyama Cassandra ya navxweyî bikar tînin da ku bi hevûdu re têkilî daynin û ji bo danûstandina agahdariya komê. Bi Heartbeat re, pêşkêşker li ser têkçûnên hevdu fêr dibin, nexşeyek daneya yekane diparêzin - tablo, avahî û dubarekirina wan; nexşeya dabeşkirinê, topolojiya komê, hwd.
Clients
Li şûna ajokarên standard, moda Fat Client tê bikar anîn. Nodek wusa daneyan hilnagire, lê dikare wekî koordînatorek ji bo pêkanîna daxwazê tevbigere, ango Xerîdar bixwe wekî koordînatorê daxwazên xwe tevdigere: ew li kopiyên hilanînê dipirse û nakokiyan çareser dike. Ev ne tenê ji ajokera standard pêbawertir û zûtir e, ku pêwendiya bi hevrêzek dûr re hewce dike, lê di heman demê de dihêle hûn veguheztina daxwazan jî kontrol bikin. Li derveyî danûstendinek ku li ser xerîdar vekirî ye, daxwaz ji depoyan re têne şandin. Ger xerîdar danûstendinek vekiriye, wê hingê hemî daxwazên di hundurê danûstendinê de ji koordînatorê danûstendinê re têne şandin.
C * Yek Koordînatorê Transaction
Koordînator tiştek e ku me ji bo C * One ji sifirê pêk anî. Ew berpirsiyar e ji bo birêvebirina danûstendinan, kilîtkirin, û rêza ku danûstendinan têne sepandin.
Ji bo her danûstendina servekirî, koordînator nîşanek dem çêdike: her danûstendina paşîn ji danûstendina berê mezintir e. Ji ber ku pergala çareseriya pevçûnê ya Cassandra li ser bingeha demjimêran (ji du tomarên nakok, ya ku bi demjimêra herî paşîn heyî tê hesibandin) ye), nakokî dê her gav di berjewendiya danûstendina paşîn de were çareser kirin. Bi vî awayî me pêk anî - rêyek erzan ji bo çareserkirina nakokiyan di pergalek belavkirî de.
Locks
Ji bo ku îzolasyonê misoger bikin, me biryar da ku em rêbaza herî hêsan bikar bînin - kilîdên pessimîst ku li ser bingeha mifteya bingehîn a tomarê ye. Bi gotineke din, di danûstendinekê de, divê pêşî tomarek were girtin, tenê paşê were xwendin, guheztin û tomarkirin. Tenê piştî peywirdariyek serketî dikare tomarek were vekirin da ku danûstendinên hevrikî karibin wê bikar bînin.
Pêkanîna kilîtkirina weha di hawîrdorek ne-belavkirî de hêsan e. Di pergalek belavkirî de, du vebijarkên sereke hene: an girtina belavkirî li ser komê bicîh bikin, an danûstendinan belav bikin da ku danûstendinên bi heman tomarê re her gav ji hêla heman koordînatorê ve bêne xizmet kirin.
Ji ber ku di rewşa me de dane ji berê ve di nav komên danûstendinên herêmî yên SQL de têne belav kirin, biryar hate girtin ku komên danûstendinê yên herêmî ji koordînatoran re werin veqetandin: yek koordînator hemî danûstendinan bi nîşanan ji 0 heta 9 dike, ya duyemîn - bi nîşanekan ji 10 heta 19, wate ya vê çîye. Wekî encamek, her yek ji mînakên koordînatorê dibe serwerê koma danûstendinê.
Dûv re kilît dikarin di forma HashMapek banal de di bîranîna koordînatorê de werin bicîh kirin.
Têkçûnên koordînatorê
Ji ber ku yek koordînator bi taybetî komek danûstendinê re xizmet dike, pir girîng e ku meriv zû rastiya têkçûna wê diyar bike da ku hewildana duyemîn a pêkanîna danûstendinê biqede. Ji bo ku em vê bilez û pêbawer bikin, me protokolek lêdana bihîstinê ya bi tevahî girêdayî bikar anî:
Her navendek daneyê bi kêmî ve du girêkên koordînatorê mêvandar dike. Dem bi dem, her koordînator peyamek lêdana dil ji koordînatorên din re dişîne û wan di derbarê xebata xwe de agahdar dike, û her weha ew peyamên lêdana dil cara dawî ji kîjan koordînatorên komê wergirtiye.
Agahiyên bi vî rengî ji yên din wekî beşek ji peyamên lêdana dilê xwe werdigirin, her koordînator bi xwe biryarê dide ka kîjan girêkên komê kar dikin û kîjan na, bi rêgezek quorum ve têne rêve kirin: heke girê X ji piraniya girêkên komê di derheqê normalê de agahdarî wergirtiye. wergirtina peyaman ji node Y, paşê, Y dixebite. Û berevajî vê yekê, gava ku pirranî rapor dike ku peyamên ji node Y winda ne, wê hingê Y red kiriye. Meraq e ku heke quorum ji girê X agahdar bike ku ew êdî ji wê peyaman wernagire, wê hingê girê X bixwe dê xwe wekî têkçûyî bihesibîne.
Peyamên lêdana dil bi frekansa bilind, bi qasî 20 caran di çirkeyê de, bi heyama 50 ms re têne şandin. Di Java-yê de, ji ber dirêjahiya berawirdî ya rawestanên ku ji hêla berhevkarê çopê ve têne peyda kirin, dijwar e ku meriv bersiva serîlêdanê di nav 50 ms de garantî bike. Me karîbû vê dema bersivê bi karanîna berhevkarê çopê G1 bi dest bixin, ku destûrê dide me ku em ji bo dirêjahiya pausesên GC-ê armancek diyar bikin. Lêbelê, carinan, pir kêm kêm, berhevkar ji 50 ms derbas dibe, ku dikare bibe sedema tespîtkirina xeletiyek derewîn. Ji bo pêşîgirtina vê yekê, koordînator têkçûna girêkek dûr rapor nake dema ku yekem peyama lêdana dil ji wê winda dibe, tenê heke çend kes li pey hev winda bûne Bi vî rengî me karî têkçûnek girêka kordînatorê di 200 de tespît bike ms.
Lê ne bes e ku meriv zû fam bike ka kîjan node fonksiyonê rawestandiye. Divê em li ser vê yekê tiştek bikin.
Alîdanînî
Plana klasîk, di bûyera têkçûnek master de, destpêkirina hilbijartinek nû bi karanîna yek ji wan vedihewîne algorîtmayan. Lêbelê, algorîtmayên bi vî rengî pirsgirêkên naskirî bi hevgirtina demê û dirêjahiya pêvajoya hilbijartinê bixwe re hene. Me karîbû bi karanîna nexşeyek veguheztina koordînatorê di torgilokek bi tevahî ve girêdayî de derengiyên wusa zêde dûr bixin:
Em bibêjin ku em dixwazin di koma 50 de danûstendinek pêk bînin. Werin em pêşwext nexşeya veguheztinê diyar bikin, ango di bûyera têkçûna kordînatorê sereke de kîjan girêk dê di koma 50 de danûstandinan pêk bînin. Armanca me ew e ku di bûyera têkçûna navenda daneyê de fonksiyona pergalê biparêzin. Ka em destnîşan bikin ku rezerva yekem dê girêkek ji navendek daneya din be, û rezerva duyemîn dê girêkek ji sêyemîn be. Ev nexşe carekê tê hilbijartin û heya ku topolojiya komê neguhere, yanî heya ku girêkên nû têkevin nav wê naguhere (ku pir kêm diqewime). Pêvajoya hilbijartina masterek çalak a nû heke ya kevin têk neçe dê her gav wiha be: rezerva yekem dê bibe serwerê çalak, û heke ew kar raweste, rezerva duyemîn dê bibe masterê çalak.
Ev nexşe ji algorîtmaya gerdûnî pêbawertir e, ji ber ku ji bo çalakkirina masterek nû bes e ku meriv têkçûna ya kevin diyar bike.
Lê dê xerîdar çawa fêm bikin ka kîjan master naha dixebite? Ne gengaz e ku di 50 ms de agahdariya bi hezaran xerîdar re bişînin. Dema ku xerîdar daxwazek ji bo vekirina danûstendinê bişîne, rewşek mimkun e ku hîna nizane ku ev master êdî naxebite, û daxwaz dê biqede. Ji bo pêşîgirtina vê yekê, xerîdar bi spekulatîf daxwazek ji bo vekirina danûstendinê ji masterê komê û her du rezervên wî re yekcar dişînin, lê tenê yê ku di vê gavê de serwerê çalak e dê bersivê bide vê daxwazê. Xerîdar dê hemî danûstendina paşîn di hundurê danûstendinê de tenê bi masterê çalak re bike.
Mamosteyên paşvekişandinê daxwaznameyên danûstendinên ku ne yên wan in, di rêza danûstendinên çênebûyî de digirin, ku ew ji bo demekê têne hilanîn. Ger masterê çalak bimire, masterê nû daxwaza vekirina danûstendinan ji rêza xwe dike û bersivê dide xerîdar. Ger xerîdar berê danûstendinek bi masterê kevn re vekiriye, wê hingê bersiva duyemîn tê paşguh kirin (û, eşkere, danûstendinek wusa dê neqede û dê ji hêla xerîdar ve were dubare kirin).
Çawa danûstandinê dixebite
Ka em bibêjin xerîdarek daxwazek ji koordînatorê re şandiye ku ji bo filan saziyek bi keyek bingehîn a wusa û wusa ve danûstendinek veke. Koordînator vê saziyê kilît dike û di bîranînê de di tabloya qefleyê de bi cih dike. Ger hewce be, koordînator vê saziyê ji depoyê dixwîne û daneyên encam di rewşek danûstendinê de di bîra koordînatorê de hilîne.
Dema ku xerîdar bixwaze di danûstendinekê de daneyan biguhezîne, ew daxwazek ji koordînatorê re dişîne da ku saziyê biguhezîne, û koordînator daneyên nû di tabloya rewşa danûstendinê de di bîranînê de bi cîh dike. Ev tomar temam dike - tu tomar ji hilanînê re nayê çêkirin.
Dema ku xerîdar daneyên xwe yên guhertî wekî beşek danûstendinek çalak daxwaz dike, koordînator wiha tevdigere:
- heke ID jixwe di danûstendinê de be, wê hingê data ji bîrê tê girtin;
- heke di bîranînê de ID tune be, wê hingê daneyên winda ji girêkên hilanînê, bi yên ku berê di bîrê de ne, têne xwendin û encam ji xerîdar re tê dayîn.
Bi vî rengî, xerîdar dikare guhertinên xwe bixwîne, lê xerîdarên din van guhertinan nabînin, ji ber ku ew tenê di bîra koordînatorê de têne hilanîn;
Dema ku xerîdar commit dişîne, rewşa ku di bîra karûbarê de bû ji hêla koordînatorê ve di komek tomarkirî de tê hilanîn, û wekî komek tomarkirî ji hilanîna Cassandra re tê şandin. Firoşgeh her tiştê ku hewce dike dikin da ku pê ewle bibin ku ev pakêt bi atomî (bi tevahî) were sepandin, û bersivek ji koordînatorê re vedigerîne, yê ku qefilan berdide û serkeftina danûstendinê ji xerîdar re piştrast dike.
Û ji bo vegerê, koordînator tenê hewce dike ku bîranîna ku ji hêla dewleta danûstendinê ve hatî dagir kirin azad bike.
Di encama başkirinên jorîn de, me prensîbên ACID bicîh anîn:
- Atomicity. Ev garantiyek e ku dê ti danûstendinek bi qismî di pergalê de neyê tomar kirin, an dê hemî bineoperasyonên wê biqede, an jî dê yek neqede. Em bi vê prensîbê bi berhevoka qeydkirî ya li Cassandra ve girêdayî ne.
- Consistency. Her danûstendina serketî, ji hêla pênase ve, tenê encamên derbasdar tomar dike. Ger, piştî vekirina danûstendinê û pêkanîna beşek operasyonan, were dîtin ku encam nederbasdar e, paşvekêşandinek tê kirin.
- Cudakirin. Dema ku danûstendinek tête kirin, danûstendinên hevdemî divê bandorê li encama wê neke. Danûstandinên hevrikî bi karanîna kilîdên pessimîst ên li ser koordînatorê têne veqetandin. Ji bo xwendina li derveyî danûstendinê, prensîba veqetandinê di asta Read Committed de tê dîtin.
- Berdewamî. Tevî pirsgirêkên di astên jêrîn de - reşkirina pergalê, têkçûna hardware - guheztinên ku ji hêla danûstendinek bi serfirazî ve hatî çêkirin divê dema ku kar ji nû ve dest pê bikin bêne parastin.
Xwendina bi indexan
Ka em tabloyek sade bînin:
CREATE TABLE photos (
id bigint primary key,
owner bigint,
modified timestamp,
…)Nasnameyek (mifteya bingehîn), xwedan û dîroka guherandinê heye. Pêdivî ye ku hûn daxwazek pir hêsan bikin - daneyên li ser xwedan bi dîroka guhartinê "ji bo roja paşîn" hilbijêrin.
SELECT *
WHERE owner=?
AND modified>?Ji bo ku pirsek wusa zû were hilanîn, di SQL DBMS-ya klasîk de hûn hewce ne ku pêdekek bi stûnan (xwedî, guheztin) ava bikin. Em dikarin vê yekê bi hêsanî bikin, ji ber ku me nuha garantiya ACID heye!
Indeksên di C * One
Tabloyek çavkanî ya bi wêneyan heye ku tê de nasnameya tomarê mifteya bingehîn e.
Ji bo indexek, C*One tabloyek nû diafirîne ku kopiyek orîjînal e. Bişkojk wekî îfadeya pêvekê ye, û di heman demê de mifteya bingehîn a tomarê ji tabloya çavkaniyê jî vedigire:
Naha pirsa "xwediyê roja paşîn" dikare wekî hilbijarkek ji tabloyek din ji nû ve were nivîsandin:
SELECT * FROM i1_test
WHERE owner=?
AND modified>?Hevgirtina daneyan di wêneyên tabloya çavkaniyê û tabloya î1 de bixweber ji hêla koordînatorê ve têne parastin. Tenê li ser bingeha şema daneyê, dema ku guherînek tê wergirtin, koordînator ne tenê di tabloya sereke, lê di heman demê de di kopiyan de jî guhertinek çêdike û hilîne. Li ser tabloya îndeksê kiryarên zêde nayên kirin, têketin nayên xwendin, û kilît nayên bikar anîn. Ango, lêzêdekirina îndeksan hema hema ti çavkaniyan dixwe û bi rastî bandorek li ser leza sepandina guheztinan nake.
Bi karanîna ACID-ê, me karîbû navnîşên mîna SQL bicîh bikin. Ew hevdeng in, berbelav in, bilez in, çêdibin, û di zimanê pirsê CQL de hatine çêkirin. Ji bo piştgirîkirina indexan guheztinên koda serîlêdanê ne hewce ne. Her tişt wekî SQL hêsan e. Û ya herî girîng, index bandorê li leza pêkanîna guheztinên tabloya danûstendinê ya orjînal nake.
Çi qewimî
Me sê sal berê C*One pêş xist û ew dest bi xebata bazirganî kir.
Di dawiyê de me çi bi dest xist? Werin em vê yekê bi mînaka binepergala hilberandin û hilanînê wêneyan binirxînin, yek ji celebên herî girîng ên daneyê di tora civakî de. Em ne li ser bedenên wêneyan bi xwe diaxivin, lê li ser her cûre meta-agahiyê. Naha Odnoklassniki bi qasî 20 mîlyar tomarên weha hene, pergal di çirkeyê de 80 hezar daxwazên xwendinê, heya 8 hezar danûstendinên ACID di çirkeyê de bi guherandina daneyê re têkildar dike.
Gava ku me SQL bi faktora dubarekirinê = 1 bikar anî (lê di RAID 10-ê de), metaformasyona wêneyê li ser komek pir berdest a 32 makîneyên ku Microsoft SQL Server-ê dixebitin (zêde 11 paşvekêşan) hate hilanîn. 10 pêşkêşker jî ji bo hilanîna paşgiran hatine veqetandin. Bi tevahî 50 otomobîlên biha. Di heman demê de, pergal bi barkirina binavkirî, bêyî rezervê xebitî.
Piştî koçkirina pergala nû, me faktora dubarekirinê = 3 - kopiyek li her navendek daneyê wergirt. Pergal ji 63 girêkên hilanînê Cassandra û 6 makîneyên koordînatorê, bi tevahî 69 pêşkêşkeran pêk tê. Lê van makîneyan pir erzantir in, lêçûna giştî ya wan bi qasî 30% ji lêçûna pergala SQL ye. Di heman demê de, barkirin di 30% de tête girtin.
Bi danasîna C*One re, dereng jî kêm bû: di SQL de, operasyonek nivîsandinê bi qasî 4,5 ms girt. Di C * One de - nêzîkî 1,6 ms. Demjimêra danûstendinê bi navînî ji 40 ms kêmtir e, peywir di 2 ms de tê qedandin, dema xwendin û nivîsandinê bi navînî 2 ms e. Ji sedî 99-an - tenê 3-3,1 ms, jimara wextan 100 carî kêm bûye - hemî ji ber karanîna berbelav a spekulasyonê.
Heya nuha, piraniya girêkên SQL Server hatine hilweşandin tenê hilberên nû bi karanîna C * One têne pêşve xistin. Me C* One adapte kir ku di ewrê xwe de bixebite , ku ev gengaz kir ku lezkirina belavkirina komên nû, hêsankirina veavakirinê û otomatîkkirina xebatê. Bêyî koda çavkaniyê, kirina vê yekê dê pir dijwar û girantir be.
Naha em li ser veguheztina dezgehên xweyên hilanînê yên din li ewr dixebitin - lê ew çîrokek bi tevahî cûda ye.
Source: www.habr.com