Ohar. itzul.: Jaana Dogan Google-ko esperientziadun ingeniari bat da, eta une honetan Go-n idatzitako konpainiaren ekoizpen-zerbitzuen behagarritasuna lantzen ari da. Ingelesez hitz egiten duten publikoaren artean ospe handia lortu zuen artikulu honetan, 17 puntutan bildu zituen DBMSei (eta, oro har, batzuetan banatutako sistemei) buruzko xehetasun tekniko garrantzitsuak, aplikazio handi/eskatzen duten garatzaileentzat kontuan hartzeko erabilgarriak direnak.
Sistema informatiko gehienek beren egoeraren jarraipena egiten dute eta, horren ondorioz, nolabaiteko datuak biltegiratzeko sistema behar dute. Datu-baseei buruzko ezagutza pilatu nuen denbora luzean, eta bide horretan, diseinu-akatsak eginez, datuak galtzea eta etenaldiak eragin zituzten. Informazio bolumen handiak prozesatzen dituzten sistemetan, datu-baseak sistemaren arkitekturaren muinean daude eta funtsezko elementu gisa jokatzen dute soluzio optimoa aukeratzeko. Datu-basearen lanari arreta handia jartzen zaion arren, aplikazioen garatzaileek aurreikusten saiatzen diren arazoak icebergaren punta baino ez dira askotan. Artikulu sorta honetan, arlo honetan espezializatuak ez diren garatzaileentzat erabilgarriak izango diren ideia batzuk partekatzen ditut.
- Zortea duzu denboraren % 99,999an sareak arazorik sortzen ez badu.
- AZIDOA hainbat gauza esan nahi du.
- Datu-base bakoitzak bere mekanismoak ditu koherentzia eta isolamendua bermatzeko.
- Blokeo baikorra erreskatatu egiten da ohikoa mantentzea zaila denean.
- Irakurketa zikinak eta datuak galtzeaz gain, beste anomalia batzuk daude.
- Datu-basea eta erabiltzailea ez dira beti ados jardutearen inguruan.
- Aplikazio-mailako zatiketak aplikaziotik kanpo eraman daitezke.
- Autoincrementing arriskutsua izan daiteke.
- Datu zaharkituak erabilgarriak izan daitezke eta ez dute blokeatu beharrik.
- Distortsioak ohikoak dira edozein garaiko iturrietarako.
- Atzeratzeak esanahi asko ditu.
- Errendimendu-eskakizunak transakzio zehatz baterako ebaluatu behar dira.
- Habiaratutako transakzioak arriskutsuak izan daitezke.
- Transakzioak ez dira aplikazioaren egoerarekin lotu behar.
- Kontsulta-planifikatzaileek datu-baseei buruz asko esan dezakete.
- Sareko migrazioa zaila da, baina posiblea.
- Datu-basea nabarmen handitzeak ezustekoa areagotzea dakar.
Eskerrak eman nahi nizkieke Emmanuel Odeke, Rein Henrichs eta beste batzuei artikulu honen aurreko bertsio bati buruzko iritziengatik.
Zortea duzu denboraren % 99,999an sareak arazorik sortzen ez badu.
Sare-teknologia modernoak zenbaterainoko fidagarriak diren eta sareko hutsegiteen ondorioz sistemak zenbateraino gelditzen diren jakiteko galdera izaten jarraitzen du. Gai honi buruzko informazioa urria da eta ikerketan sare, ekipamendu eta langile espezializatuak dituzten erakunde handiak izaten dira nagusi.
Spanner-en (Google-ren mundu mailan banatutako datu-basea) % 99,999ko erabilgarritasun-tasarekin, Google-k soilik dio arazoak sarearekin lotuta daude. Aldi berean, konpainiak bere sare espezializatua erabilgarritasun handiko "zutabe nagusia" deitzen du. Aztertu 2014an egindakoa, erronka bat jartzen du β", Peter Deutsch-ek 1994an formulatu zuena. Benetan fidagarria al da sarea?
Enpresa erraldoietatik kanpoko ikerketa integrala, Internet zabalagorako egina, besterik gabe, ez da existitzen. Era berean, eragile nagusien datu nahikorik ez dago bezeroen arazoen ehunekoa sarearekin erlazionatuta dagoenari buruz. Ondo dakigu hodeiko hornitzaile handien sare-pilaren etenaldiak, hainbat orduz Interneten zati oso bat ken dezaketela, pertsona eta enpresa askori eragiten dieten oihartzun handiko gertaerak direlako. Sareko etenaldiek arazoak sor ditzakete kasu askoz gehiagotan, nahiz eta kasu horiek guztiak fokuan ez egon. Hodeiko zerbitzuen bezeroek ere ez dakite ezer arazoen arrazoiei buruz. Hutsik badago, ia ezinezkoa da sareko akats bati egoztea zerbitzu-hornitzailearen aldetik. Haientzat, hirugarrenen zerbitzuak kutxa beltzak dira. Ezinezkoa da eragina ebaluatzea zerbitzu-hornitzaile handia izan gabe.
Jokalari handiek beren sistemei buruz berri ematen dutena kontuan hartuta, seguru zorte zaudela esatea sareko zailtasunek geldialdi-arazo potentzialen ehuneko txiki bat baino ez badute. Sareko komunikazioek oraindik ere gauza arruntak jasaten dituzte hardware-akatsak, topologia-aldaketak, administrazio-konfigurazio-aldaketak eta elektrizitate-eteteak. Duela gutxi, harritu egin nintzen arazo posibleen zerrenda gehitu zela jakiteak (bai, ondo entzun duzu).
AZIDOA gauza ezberdin asko esan nahi du
ACID akronimoak Atomicity, Consistency, Isolation, Reliability esan nahi du. Transakzioen propietate horiek baliozkotasuna bermatu nahi dute akatsak, akatsak, hardware-akatsak, etab. ACID edo antzeko eskemarik gabe, zaila izango litzateke aplikazioen garatzaileei zertaz arduratzen diren eta datu-basea zertaz arduratzen den bereiztea. Erlaziozko transakzio datu-base gehienak ACID betetzen saiatzen dira, baina NoSQL bezalako ikuspegi berriek ACID transakziorik gabeko datu-base asko sortu dituzte, ezartzeko garestiak direlako.
Industrian sartu nintzenean, gure arduradun teknikoak ACID kontzeptua zein garrantzitsua zen hitz egin zuen. Zintzoa izateko, ACID ezartzeko estandar zorrotz bat baino deskribapen zakarra jotzen da. Gaur egun gehienbat erabilgarria iruditzen zait, gai-kategoria zehatz bat planteatzen duelako (eta irtenbide posibleak proposatzen dituelako).
DBMS guztiek ez dute ACID betetzen; Aldi berean, ACID onartzen duten datu-baseen inplementazioek desberdin ulertzen dute eskakizun multzoa. ACID-en inplementazioak ezkutatuta egotearen arrazoietako bat ACID eskakizunak ezartzeko egin behar diren truke-off askoren ondoriozkoa da. Sortzaileek beren datu-baseak ACID-ekin bat datozenak aurkez ditzakete, baina ertz-kasuen interpretazioa nabarmen alda daiteke, eta gertaera "ezezkoak" kudeatzeko mekanismoa ere izango da. Gutxienez, garatzaileek oinarrizko inplementazioen korapilatsuen ulermena lor dezakete beren portaera berezia eta diseinu-konpromisoak behar bezala ulertzeko.
MongoDB ACID eskakizunak betetzen dituen ala ez eztabaidak jarraitzen du 4. bertsioa kaleratu ondoren ere. MongoDB ez da denbora luzez onartzen , nahiz eta lehenespenez datuak diskora konprometitu ez diren 60 segundoan behin baino gehiagotan. Imajinatu honako eszenatoki hau: aplikazio batek bi idazketa argitaratzen ditu (w1 eta w2). MongoDB-k w1 behar bezala gordetzen du, baina w2 galtzen da hardware hutsegite baten ondorioz.
Eszenarioa ilustratzen duen eskema. MongoDB huts egiten du datuak diskoan idatzi aurretik
Diskoarekin konprometitzea prozesu garestia da. Maiz egindako konpromisoak saihestuz, garatzaileek grabazioaren errendimendua hobetzen dute fidagarritasunaren kaltetan. Une honetan MongoDB-k erregistroa onartzen du, baina idazketa zikinek oraindik ere eragina izan dezakete datuen osotasunean, erregistroak lehenespenez 100 ms behin hartzen baitira. Hau da, oraindik ere antzeko eszenatoki bat posible da erregistroetarako eta horietan aurkezten diren aldaketetarako, nahiz eta arriskua askoz txikiagoa den.
Datu-base bakoitzak bere koherentzia eta isolamendu mekanismoak ditu
ACID eskakizunetatik, koherentzia eta isolamenduak inplementazio ezberdinen kopuru handiena harrotzen dute, merkataritza-eskaintza zabalagoa delako. Esan beharra dago koherentzia eta isolamendua funtzio nahiko garestiak direla. Koordinazioa eskatzen dute eta datuen koherentziarako lehia areagotzen dute. Arazoaren konplexutasuna nabarmen handitzen da datu-basea horizontalki eskalatu behar denean hainbat datu-zentrotan (batez ere eskualde geografiko desberdinetan kokatzen badira). Koherentzia maila altua lortzea oso zaila da, erabilgarritasuna murrizten baitu eta sarearen segmentazioa areagotzen baitu. Fenomeno honi buruzko azalpen orokorrago bat lortzeko, jotzea gomendatzen dizut . Aipatzekoa da, halaber, aplikazioek inkoherentzia kopuru txikiak kudeatu ditzaketela, eta programatzaileek arazoaren Γ±abardurak nahikoa ondo uler ditzaketela aplikazioan logika gehigarria ezartzeko inkoherentzia kudeatzeko datu-basean asko fidatu gabe.
DBMSek isolamendu maila desberdinak eskaintzen dituzte askotan. Aplikazioen garatzaileek eraginkorrena aukeratu dezakete euren lehentasunen arabera. Isolamendu baxuak abiadura handitzea ahalbidetzen du, baina datu lasterketa baten arriskua ere areagotzen du. Isolamendu handiak probabilitate hori murrizten du, baina lana moteltzen du eta lehia ekar dezake, eta horrek hutsegiteak hasten diren oinarrian balaztak eragingo ditu.
Dauden aldiberekotasun ereduak eta haien arteko erlazioak berrikustea
SQL estandarrak lau isolamendu maila baino ez ditu definitzen, nahiz eta teorian eta praktikan askoz gehiago egon. dauden aldibereko ereduen ikuspegi bikaina eskaintzen du. Adibidez, Google Spanner-ek kanpoko serializagarritasuna bermatzen du erlojuaren sinkronizazioarekin, eta isolamendu-geruza zorrotzagoa den arren, ez dago isolamendu-geruza estandarretan definituta.
SQL estandarrak isolamendu maila hauek aipatzen ditu:
- Serializable (zorrotz eta garestiena): Serializatu daitekeen exekuzioak transakzio sekuentzial batzuen exekuzioen efektu bera du. Exekuzio sekuentzialak esan nahi du ondorengo transakzio bakoitza aurrekoa amaitu ondoren hasten dela. Kontuan izan behar da maila Serializable sarritan snapshot isolamendua deitzen den moduan inplementatzen da (adibidez, Oracle-n), interpretazio ezberdinen ondorioz, nahiz eta argazkien isolamendua bera ez den irudikatzen SQL estandarrean.
- Irakurketa errepikagarriak: uneko transakzioko konprometitu gabeko erregistroak uneko transakziorako erabilgarri daude, baina beste transakzio batzuek egindako aldaketak (errenkada berriak adibidez) .
- Irakurri konprometituta: Konprometitu gabeko datuak ez daude transakzioetarako erabilgarri. Kasu honetan, transakzioek konprometitutako datuak soilik ikus ditzakete, eta irakurketa fantastikoak gerta daitezke. Transakzio batek errenkada berriak txertatzen eta konprometitzen baditu, uneko transakzioak haiek ikusi ahal izango ditu galdetzean.
- Irakurri konpromisorik gabe (maila zorrotz eta garestia txikiena): irakurketa zikinak onartzen dira, transakzioek beste transakzio batzuek egindako konpromisorik gabeko aldaketak ikus ditzakete. Praktikan, maila hau baliagarria izan daiteke gutxi gorabeherako estimazioetarako, esate baterako, kontsultak egiteko
COUNT(*)mahai gainean.
Maila Serializable datu-lasterketen arriskua minimizatzen du, inplementatzeko garestiena izanik eta sistemaren karga lehiakor handiena eragiten duena. Beste isolamendu-mailak errazago inplementatzen dira, baina datu-lasterketen probabilitatea areagotzen dute. DBMS batzuek isolamendu maila pertsonalizatu bat ezartzeko aukera ematen dute, beste batzuek hobespen sendoak dituzte eta maila guztiak ez dira onartzen.
Isolamendu-mailen euskarria DBMS jakin batean iragartzen da sarri, baina bere portaeraren azterketa arretatsu batek soilik agerian uzten du benetan gertatzen ari dena.
DBMS desberdinetarako isolamendu-maila desberdinetako aldibereko anomaliak berrikustea
Martin Kleppmann bere proiektuan Isolamendu-maila desberdinak alderatzen ditu, aldibereko anomaliei buruz hitz egiten du eta datu-basea isolamendu-maila jakin bati atxikitzeko gai den ala ez. Kleppmann-en ikerketek erakusten dute datu-baseen garatzaileek nola pentsatzen duten modu ezberdinean isolamendu-mailei buruz.
Blokeo baikorra erreskatatu egiten da ohikoa mantentzea zaila denean.
Blokeatzea oso garestia izan daiteke, ez bakarrik datu-basean lehia areagotzen duelako, baita aplikazioen zerbitzariak datu basera etengabe konektatzea eskatzen duelako ere. Sare-segmentazioak blokeo-egoera esklusiboak areagotu ditzake eta identifikatzen eta konpontzen zailak diren blokeo-blokeoak sor ditzake. Blokeo esklusiboa egokia ez den kasuetan, blokeo baikorrak laguntzen du.
kate bat irakurtzerakoan bere bertsioa, checksuma edo azken aldaketaren ordua kontuan hartzen dituen metodo bat da. Honek, sarrera bat aldatu aurretik bertsio atomikorik ez dagoela ziurtatzeko aukera ematen du:
UPDATE products
SET name = 'Telegraph receiver', version = 2
WHERE id = 1 AND version = 1
Kasu honetan, taula eguneratzea products ez da burutuko aurretik beste eragiketa batek errenkada honetan aldaketak egin baditu. Errenkada honetan beste eragiketarik egin ez bada, errenkada baterako aldaketa gertatuko da eta eguneratzea arrakastatsua izan dela esan dezakegu.
Irakurketa zikinak eta datuak galtzeaz gain, beste anomalia batzuk daude
Datuen koherentziari dagokionez, irakurketa zikinak eta datuak galtzea ekar dezaketen lasterketa-baldintzen potentziala da arreta. Hala ere, datuen anomaliak ez dira hor gelditzen.
Anomalien adibide bat grabaketa distortsioa da (okerrak idatzi). Distortsioak detektatzen zailak dira, normalean ez direlako aktiboki bilatzen. Ez dira irakurketa zikinengatik edo datuak galtzeagatik, datuei jarritako muga logikoen urratzeengatik baizik.
Adibidez, har dezagun kontrol-aplikazio bat, operadore bat uneoro deia egotea eskatzen duena:
BEGIN tx1; BEGIN tx2;
SELECT COUNT(*)
FROM operators
WHERE oncall = true;
0 SELECT COUNT(*)
FROM operators
WHERE oncall = TRUE;
0
UPDATE operators UPDATE operators
SET oncall = TRUE SET oncall = TRUE
WHERE userId = 4; WHERE userId = 2;
COMMIT tx1; COMMIT tx2;Goiko egoeran, erregistro ustelkeria gertatuko da bi transakzioak arrakastaz egiten badira. Irakurketa zikinik edo datu-galerarik egon ez bazen ere, datuen osotasuna arriskuan zegoen: orain bi pertsona aldi berean deitzen dira.
Isolamendu serializagarriak, eskema diseinuak edo datu-basearen murrizketek idazketaren ustelkeria ezabatzen lagun dezakete. Garatzaileek gai izan behar dute garapenean horrelako anomaliak identifikatu behar dituzte ekoizpenean saihesteko. Aldi berean, grabaketa-distortsioak oso zailak dira kodearen oinarrian bilatzea. Batez ere sistema handietan, garapen-talde desberdinak taula berdinetan oinarritutako funtzioak ezartzeaz arduratzen direnean eta datuen sarbidearen berezitasunetan ados ez daudenean.
Datu-basea eta erabiltzailea ez dira beti ados jartzen zer egin behar den
Datu-baseen ezaugarri nagusietako bat exekuzio-aginduaren bermea da, baina baliteke ordena hori bera ez izatea software-garatzailearentzat gardena. Datu-baseek transakzioak jasotzen diren ordenan exekutatzen dituzte, ez programatzaileek nahi duten ordenan. Transakzioen ordena aurreikustea zaila da, batez ere oso kargatutako sistema paraleloetan.
Garapenean, batez ere blokeatzen ez diren liburutegiekin lan egiten denean, estilo eskasak eta irakurgarritasun baxuak transakzioak sekuentzialki exekutatzen direla sinestea eragin diezaieke erabiltzaileei, datu-basera edozein ordenatan irits litezkeenean.
Lehen begiratuan, beheko programan, T1 eta T2 sekuentzialki deitzen dira, baina funtzio hauek blokeagarriak ez badira eta berehala itzultzen dute emaitza formularioan , orduan deien ordena datu-basean sartu ziren uneen arabera zehaztuko da:
emaitza1 = T1() // emaitza errealak promesak dira
emaitza2 = T2()
Atomikotasuna behar bada (hau da, eragiketa guztiak amaitu edo bertan behera utzi behar dira) eta sekuentziari garrantzia ematen badiote, orduan T1 eta T2 eragiketak transakzio bakar baten barruan egin behar dira.
Aplikazio-mailako zatiketak aplikaziotik kanpo eraman daitezke
Sharding datu-base bat horizontalki partizionatzeko metodo bat da. Datu-base batzuek automatikoki zatitu ditzakete datuak horizontalean, eta beste batzuk ezin dira, edo ez dira oso onak. Datu-arkitektuek/garatzaileek datuak zehatz-mehatz nola sartuko diren aurreikusteko gai direnean, erabiltzailearen espazioan partizio horizontalak sor ditzakete lan hori datu-basean eskuordetu beharrean. Prozesu honi "aplikazio-mailako zatiketa" deitzen zaio (aplikazio-mailako zatiketa).
Zoritxarrez, izen honek sarritan sharding aplikazio zerbitzuetan bizi dela uste okerra sortzen du. Izan ere, datu-basearen aurrean geruza bereizi gisa inplementa daiteke. Datuen hazkundearen eta eskemaren iterazioaren arabera, zatiketa-eskakizunak nahiko konplexuak izan daitezke. Estrategia batzuek aplikazio-zerbitzariak berriro zabaldu beharrik gabe errepikatzeko gaitasunaren onura izan dezakete.
Aplikazio-zerbitzariak sharding zerbitzutik bereizten diren arkitektura baten adibidea
Sharding zerbitzu bereizi batera eramateak zatiketa estrategia desberdinak erabiltzeko gaitasuna zabaltzen du aplikazioak berriro zabaldu beharrik gabe. aplikazio mailan zatiketa sistema baten adibidea da. Vitessek MySQLrako zatiketa horizontala eskaintzen du eta bezeroei MySQL protokoloaren bidez konektatzeko aukera ematen die. Sistemak datuak elkarri buruz ezer ez dakiten MySQL nodo desberdinetan banatzen ditu.
Autoincrementing arriskutsua izan daiteke
AUTOINCREMENT gako nagusiak sortzeko modu arrunta da. Askotan datu-baseak ID-sorgailu gisa erabiltzen diren kasuak daude, eta datu-baseak identifikatzaileak sortzeko diseinatutako taulak ditu. Hainbat arrazoi daude gehikuntza automatikoa erabiliz lehen gakoak sortzea ezin hobea izatetik:
- Banatutako datu-base batean, automatikoki gehitzea arazo larria da. IDa sortzeko, blokeo globala behar da. Horren ordez, UUID bat sor dezakezu: honek ez du datu-baseko nodo ezberdinen arteko elkarrekintzarik behar. Blokeoekin automatikoki gehitzeak gatazkak eragin ditzake eta txertaketen errendimendua nabarmen murrizten du banatutako egoeretan. DBMS batzuek (adibidez, MySQL) konfigurazio berezia eta arreta gehiago behar dute master-master erreplikazioa behar bezala antolatzeko. Eta erraza da akatsak egitea konfiguratzean, eta horrek grabaketa akatsak ekarriko ditu.
- Datu-base batzuek gako nagusietan oinarritutako zatiketa algoritmoak dituzte. ID segidakoek ezusteko puntu beroak eta partizio batzuetan karga areagotu ditzakete beste batzuk inaktibo geratzen diren bitartean.
- Lehen gakoa datu-base bateko errenkada batera sartzeko modurik azkarrena da. Erregistroak identifikatzeko modu hobeekin, ID sekuentzialek tauletako zutabe garrantzitsuena baliorik gabeko balioez betetako zutabe alferrikako bihur dezakete. Hori dela eta, posible den guztietan, mesedez, aukeratu mundu osoan gako bakarra eta naturala (adibidez, erabiltzaile-izena).
Planteamendu bat erabaki aurretik, kontuan hartu IDak eta UUID automatikoki gehitzeak duten eragina indexatzean, zatikatzean eta zatikatzean.
Datu zaharkituak erabilgarriak izan daitezke eta ez dute blokeatu behar
Multiversion Concurrency Control (MVCC) goian laburki eztabaidatu ziren koherentzia-eskakizun asko ezartzen ditu. Datu-base batzuek (adibidez, Postgres, Spanner) MVCC erabiltzen dute transakzioak argazkiekin, datu-basearen bertsio zaharragoekin "elikatzeko". Snapshot transakzioak ere seriatu daitezke koherentzia bermatzeko. Argazki zahar batetik irakurtzean, zaharkitutako datuak irakurtzen dira.
Datu zaharkituak irakurtzea erabilgarria izan daiteke, adibidez, datuetatik analitikoak sortzean edo gutxi gorabeherako balio agregatuak kalkulatzean.
Oinarrizko datuekin lan egitearen lehen abantaila latentzia txikia da (batez ere datu-basea geografia ezberdinetan banatuta badago). Bigarrena, irakurtzeko soilik diren transakzioak blokeorik gabekoak dira. Abantaila nabarmena da asko irakurtzen duten aplikazioentzat, beti ere datu zaharkituak kudeatzen badituzte.
Aplikazio zerbitzariak 5 segundo zaharkituta dauden tokiko erreplikaren datuak irakurtzen ditu, nahiz eta azken bertsioa Ozeano Bareko beste aldean eskuragarri egon.
DBMSek bertsio zaharragoak automatikoki garbitzen dituzte eta, kasu batzuetan, hori egiteko aukera ematen dute eskatuz gero. Adibidez, Postgres-ek erabiltzaileei egiteko aukera ematen die VACUUM eskatuz gero, eta, gainera, eragiketa hori automatikoki egiten du aldian-aldian. Spanner-ek zabor-biltzaile bat zuzentzen du ordubete baino zaharragoak diren argazkiak kentzeko.
Edozein momentutan iturriak distortsionatu egiten dira
Informatikan ondoen gordetako sekretua denboraren API guztiek gezurra dutela da. Izan ere, gure makinek ez dakite uneko ordu zehatza. Ordenagailuek denbora mantentzeko erabiltzen diren bibrazioak sortzen dituzten kuartzozko kristalak dituzte. Hala ere, ez dira nahikoa zehatzak eta baliteke denbora zehatzaren aurretik/atzeratuta egotea. Txanda eguneko 20 segundora irits daiteke. Horregatik, gure ordenagailuetako ordua sarekoarekin sinkronizatu behar da aldian-aldian.
Sinkronizaziorako NTP zerbitzariak erabiltzen dira, baina sinkronizazio prozesua bera sareko atzerapenak jasaten ditu. Datu-zentro berean NTP zerbitzari batekin sinkronizatzeak denbora pixka bat behar du. Argi dago NTP zerbitzari publiko batekin lan egiteak are distortsio handiagoa ekar dezakeela.
Erloju atomikoak eta haien GPS parekoak hobeak dira uneko ordua zehazteko, baina garestiak dira eta konfigurazio konplexua behar dute, beraz, ezin dira auto guztietan instalatu. Hori dela eta, datu-zentroek mailakako ikuspegia erabiltzen dute. Erloju atomikoek eta/edo GPSek ordu zehatza erakusten dute, eta, ondoren, beste makina batzuetara igortzen da bigarren mailako zerbitzarien bidez. Horrek esan nahi du makina bakoitzak denbora zehatzarekiko desplazamendu jakin bat izango duela.
Egoera larriagotu egiten da aplikazioak eta datu-baseak askotan makina ezberdinetan (datu zentro ezberdinetan ez bada) kokatuta egoteak. Horrela, denbora desberdina izango da makina ezberdinetan banatutako DB nodoetan ez ezik. Aplikazio zerbitzarian ere ezberdina izango da.
Google TrueTime-k ikuspegi guztiz ezberdina hartzen du. Jende gehienak uste du Google-k norabide horretan egiten duen aurrerapena erloju atomiko eta GPSrako trantsizio hutsalarekin azaltzen dela, baina hau irudi handiaren zati bat baino ez da. Hona hemen TrueTime-k nola funtzionatzen duen:
- TrueTimek bi iturri ezberdin erabiltzen ditu: GPSa eta erloju atomikoak. Erloju hauek erlazionatu gabeko hutsegite moduak dituzte. [ikus 5. orrialdea xehetasunetarako - gutxi gorabehera. itzul.), beraz, elkarrekin erabiltzeak fidagarritasuna areagotzen du.
- TrueTimek ezohiko API bat du. Denbora itzultzen du neurketa-errorea eta ziurgabetasuna barne hartutako tarte gisa. Benetako unea tartearen goiko eta beheko mugen artean dago. Spanner, Google-ren datu-base banatua, uneko ordua tartetik kanpo dagoela esan arte itxaroten du. Metodo honek latentziaren bat sartzen du sisteman, batez ere masterraren ziurgabetasuna handia bada, baina zuzentasuna bermatzen du mundu mailan banatutako egoera batean ere.
Spanner osagaiek TrueTime erabiltzen dute, non TT.now() tarte bat itzultzen duen, beraz Spanner-ak lo egiten du uneko orduak puntu jakin bat gainditu duela ziur egon daitekeen puntura arte.
Uneko ordua zehazteko zehaztasun murriztuak Spanner-en eragiketen iraupena handitzea eta errendimendua gutxitzea dakar. Horregatik, garrantzitsua da ahalik eta zehaztasun handiena mantentzea erloju guztiz zehatza lortzea ezinezkoa den arren.
Atzeratzeak esanahi asko ditu
Dozena bat adituri atzerapena zer den galdetzen badiozu, ziurrenik erantzun desberdinak jasoko dituzu. DBMSn latentzia "datu-basearen latentzia" deitzen zaio askotan eta bezeroak hautematen duenaren desberdina da. Kontua da bezeroak sareko atzerapenaren eta datu-basearen atzerapenaren batura behatzen duela. Latentzia mota isolatzeko gaitasuna funtsezkoa da gero eta arazo gehiago arazketan. Neurri bilketa eta bistaratzean, saiatu beti bi motak erreparatzen.
Errendimendu-eskakizunak transakzio zehatz baterako ebaluatu behar dira
Batzuetan, DBMS baten errendimendu-ezaugarriak eta haren mugak idazketa/irakurketa-bideari eta latentziari dagokionez zehazten dira. Honek sistemaren funtsezko parametroen ikuspegi orokorra eskaintzen du, baina DBMS berri baten errendimendua ebaluatzen denean, ikuspegi askoz ere zabalagoa da eragiketa kritikoak bereizita ebaluatzea (kontsulta eta/edo transakzio bakoitzeko). Adibideak:
- Idatzi errendimendua eta latentzia X taulan errenkada berri bat txertatzean (50 milioi errenkadarekin) zehaztutako murrizketekin eta erlazionatutako tauletan errenkaden betegarriarekin.
- Erabiltzaile jakin baten lagunen lagunak bistaratzeko atzerapena, batez besteko lagun kopurua 500 denean.
- Erabiltzaile baten historiako 100 sarrera nagusiak berreskuratzeko latentzia, erabiltzaileak beste 500 erabiltzaileri jarraitzen dionean X sarrerarekin orduko.
Ebaluazioak eta esperimentazioak kasu kritikoak barne har ditzake datu-baseak errendimendu-baldintzak betetzen dituela ziur egon arte. Antzeko arau bat ere kontuan hartzen du matxura hori latentzia-neurriak biltzean eta SLOak zehazten direnean.
Kontuan izan kardinaltasun handiaz eragiketa bakoitzeko metrikak biltzean. Erabili erregistroak, gertaeren bilketa edo banatutako trazadura potentzia handiko arazketa-datuak lortzeko. artikuluan "Β» atzerapen arazketa metodologiekin ezagut dezakezu.
Habiaratutako transakzioak arriskutsuak izan daitezke
DBMS guztiek ez dituzte habiatutako transakzioak onartzen, baina hala egiten dutenean, horrelako transakzioek ustekabeko akatsak sor ditzakete, beti erraz hautematen ez direnak (hau da, nabaria izan behar da nolabaiteko anomalia bat dagoela).
Habiaratutako transakzioak erabiltzea saihestu dezakezu haiek detektatu eta saihestu ditzaketen bezero liburutegiak erabiliz. Habiaraturiko transakzioak ezin badira bertan behera utzi, zaindu arreta berezia inplementazioan, habiaratu diren transakzioak ustekabean bertan behera uzten diren ustekabeko egoerak saihesteko.
Transakzioak geruza ezberdinetan kapsulatzeak ustekabeko transakzio habiaratuak sor ditzake, eta kodearen irakurgarritasunaren ikuspuntutik, egilearen asmoak ulertzea zaildu dezake. Begiratu hurrengo programari:
with newTransaction():
Accounts.create("609-543-222")
with newTransaction():
Accounts.create("775-988-322")
throw Rollback();Zein izango da goiko kodearen irteera? Atzera egingo al ditu bi transakzioak, edo barrukoa bakarrik? Zer gertatzen da transakzioen sorrera biltzen diguten liburutegi-geruza anitzetan oinarritzen bagara? Gai izango al gara horrelako kasuak identifikatu eta hobetzeko?
Imajinatu hainbat eragiketa dituen datu-geruza bat (adibidez. newAccount) dagoeneko ezarrita dago bere transakzioetan. Zer gertatzen da bere transakzio propioan exekutatzen den goi-mailako negozio-logikaren parte gisa exekutatzen badituzu? Zein izango litzateke isolamendua eta koherentzia kasu honetan?
function newAccount(id string) {
with newTransaction():
Accounts.create(id)
}Horrelako galdera amaigabeei erantzunak bilatu beharrean, hobe da transakzio habiaratuak saihestea. Azken finean, zure datu-geruzak erraz egin ditzake goi-mailako eragiketak bere transakziorik sortu gabe. Horrez gain, negozio-logika bera gai da transakzio bat abiarazteko, bertan eragiketak egiteko, transakzio bat egiteko edo bertan behera uzteko.
function newAccount(id string) {
Accounts.create(id)
}
// In main application:
with newTransaction():
// Read some data from database for configuration.
// Generate an ID from the ID service.
Accounts.create(id)
Uploads.create(id) // create upload queue for the user.Transakzioak ez dira aplikazioaren egoerarekin lotu behar
Batzuetan, tentagarria da aplikazioaren egoera transakzioetan erabiltzea balio batzuk aldatzeko edo kontsulta-parametroak doitzeko. Kontuan hartu beharreko Γ±abardura kritikoa aplikazio-esparru zuzena da. Bezeroek askotan berrabiarazi egiten dituzte transakzioak sareko arazoak daudenean. Transakzioa beste prozesuren batek aldatzen ari den egoera baten araberakoa bada, balio okerra hauta dezake datu-lasterketaren aukeraren arabera. Transakzioek datu-lasterketaren baldintzen arriskua kontuan hartu behar dute aplikazioan.
var seq int64
with newTransaction():
newSeq := atomic.Increment(&seq)
Entries.query(newSeq)
// Other operations...Goiko transakzioak sekuentzia-zenbakia handituko du exekutatzen den bakoitzean, azken emaitza edozein dela ere. Konpromisoak huts egiten badu sare-arazoengatik, eskaera beste sekuentzia-zenbaki batekin exekutatuko da berriro saiatzen zarenean.
Kontsulten planifikatzaileek datu-base bati buruz asko esan dezakete
Kontsulta-planifikatzaileek datu-base batean kontsulta nola gauzatuko den zehazten dute. Eskaerak ere aztertu eta optimizatzen dituzte bidali aurretik. Antolatzaileek eskura dituzten seinaleetan oinarritutako estimazio posible batzuk soilik eman ditzakete. Adibidez, zein da hurrengo kontsultarako bilaketa-metodorik onena?
SELECT * FROM articles where author = "rakyll" order by title;Emaitzak bi modutara jaso daitezke:
- Mahai osoa eskaneatzea: taulako sarrera bakoitza begiratu eta egile-izenarekin bat datozen artikuluak itzul ditzakezu, eta gero ordenatu.
- Indizea eskaneatzea: Indize bat erabil dezakezu bat datozen IDak aurkitzeko, errenkada horiek lortzeko eta gero ordenatzeko.
Kontsulten planifikatzailearen lana zein den estrategia onena zehaztea da. Kontuan izan behar da kontsulta-planifikatzaileek aurreikuspen-gaitasun mugatuak baino ez dituztela. Horrek erabaki txarrak ekar ditzake. DBA edo garatzaileek erabil ditzakete errendimendu gutxiko kontsultak diagnostikatzeko eta doitzeko. DBMSaren bertsio berriek kontsulta-planifikatzaileak konfigura ditzakete, eta autodiagnostikoak lagun dezake datu-basea eguneratzean, bertsio berriak errendimendu arazoak sortzen baditu. Kontsulten erregistro motelek, latentzia-arazoen txostenek edo exekuzio-denboraren estatistikek optimizatu behar duten kontsultak identifikatzen lagun dezakete.
Kontsulta-planifikatzaileak aurkezten dituen neurri batzuk zarata jasan dezakete (batez ere latentzia edo CPU-denbora kalkulatzerakoan). Antolatzaileen osagarri ona exekuzio-bidea trazatzeko eta jarraitzeko tresnak dira. Horrelako arazoak diagnostikatzeko aukera ematen dute (ai, DBMS guztiek ez dituzte horrelako tresnak eskaintzen).
Sareko migrazioa zaila baina posible da
Lineako migrazioak, zuzeneko migrazioak edo denbora errealeko migrazioak datu-base batetik bestera mugitzea esan nahi du, geldialdirik gabe edo datuak hondatu gabe. Zuzeneko migrazioa errazagoa da trantsizioa DBMS/motor beraren barruan gertatzen bada. Egoera zaildu egiten da errendimendu eta eskema eskakizun desberdinak dituen DBMS berri batera mugitu behar denean.
Lineako migrazio eredu desberdinak daude. Hona hemen horietako bat:
- Gaitu sarrera bikoitza bi datu-baseetan. Fase honetan datu-base berriak ez ditu datu guztiak, baina azken datuak soilik onartzen ditu. Honetaz ziur zaudenean, hurrengo urratsera pasa zaitezke.
- Gaitu bi datu-baseetatik irakurtzea.
- Konfiguratu sistema irakurketa eta idazketa datu-base berrian nagusiki egin daitezen.
- Utzi datu-base zaharrean idazteari bertako datuak irakurtzen jarraitzen duzun bitartean. Fase honetan, datu-base berriak datu batzuk ez ditu oraindik. Datu-base zaharretik kopiatu behar dira.
- Datu-base zaharra irakurtzeko soilik da. Kopiatu datu-base zaharretik falta diren datuak berrira. Migrazioa amaitutakoan, aldatu bideak datu-base berrira eta gelditu zaharra eta ezabatu sistematik.
Informazio gehiago lortzeko, harremanetan jartzea gomendatzen dut , eredu horretan oinarritutako Stripe-ren migrazio estrategia zehazten duena.
Datu-basea nabarmen handitzeak ezustekoa areagotzea dakar
Datu-basearen hazkundeak bere eskalarekin lotutako ezusteko arazoak ekartzen ditu. Zenbat eta gehiago jakin datu-base baten barne-egiturari buruz, orduan eta hobeto aurreikus dezakegu nola eskalatuko den. Hala ere, momentu batzuk oraindik ezinezkoak dira aurreikusi.
Oinarria hazten den heinean, datu-bolumenari eta sareko banda-zabalerari buruzko aurreko hipotesiak eta itxaropenak zaharkituta geratu daitezke. Orduan sortzen da diseinuaren berrikuspen handiak, eskala handiko hobekuntza operatiboak, inplementazioak birplanteatzea edo beste DBMS batzuetara migratzea arazo potentzialak saihesteko.
Baina ez pentsa lehendik dagoen datu-basearen barne-egituraren ezagutza bikaina denik beharrezkoa den gauza bakarra. Eskala berriek ezezagun berriak ekarriko dituzte berekin. Ezusteko minak, datu banaketa irregularrak, ustekabeko banda-zabalera eta hardware arazoak, trafiko gero eta handiagoak eta sare-segmentu berriek zure datu-basearen ikuspegia, datu-eredua, hedapen-eredua eta datu-basearen tamaina birpentsatzera behartuko zaituzte.
...
Artikulu hau argitaratzea pentsatzen hasi nintzen unean, dagoeneko beste bost elementu zeuden nire jatorrizko zerrendan. Gero, kopuru handi bat etorri zen zer gehiago estali daitekeen. Hori dela eta, arreta handiena eskatzen duten arazo agerikoenak ukitzen ditu artikuluak. Hala ere, horrek ez du esan nahi gaia agortu denik eta etorkizuneko materialetan ez naizela gehiago itzuliko eta oraingoan aldaketarik egingo ez dudala.
PS
Irakurri ere gure blogean:
- «»;
- «»;
- Β«'.
Iturria: www.habr.com