Hurrengo HighLoad++ konferentzia 6ko apirilaren 7an eta 2020an ospatuko da San Petersburgon.
Xehetasunak eta sarrerak . HighLoad++ Siberia 2019. Aretoa "Krasnoyarsk". Ekainak 25, 12:00. Tesiak eta .
Gertatzen da eskakizun praktikoak teoriarekin bat egiten duela, non produktu komertzial baterako garrantzitsuak diren alderdiak kontuan hartzen ez diren. Hitzaldi honek produktu komertzial baten eskakizunetan oinarritutako ikerketa akademikoan oinarritutako Kausazko koherentzia osagaiak sortzeko planteamendu desberdinak aukeratzeko eta konbinatzeko prozesu bat aurkezten du. Entzuleek erloju logikoei, menpekotasunen jarraipenari, sistemaren segurtasunari, erlojuaren sinkronizazioari eta zergatik MongoDB-k konponbide jakin batzuei buruz finkatu zeneko planteamendu teorikoei buruz ikasiko dute.
Mikhail Tyulenev (aurrerantzean MT deitzen zaio): – Kausazko koherentziari buruz hitz egingo dut - MongoDBn landu genuen funtzio bat da. Sistema banatuen talde batean lan egiten dut, duela bi urte inguru egin genuen.
Prozesu horretan, ikerketa akademiko asko ezagutu behar izan ditut, ezaugarri hau nahiko ondo aztertu delako. Kontuan izan da artikulu bakar bat ere ez dela sartzen ekoizpen-datu-base batean behar denaren barruan, ziurrenik edozein produkzio-aplikaziotan dauden baldintza oso zehatzengatik.
Guk, Ikerkuntza akademikoaren kontsumitzaile gisa, nola prestatzen dugun bertatik zerbait prestatzen dugu, gero gure erabiltzaileei aurkez diezaiekegun plater prest, erabiltzeko erosoa eta segurua.
Kausazko koherentzia. Definitu ditzagun kontzeptuak
Hasteko, orokorrean esan nahi dut zer den Kausazko koherentzia. Bi pertsonaia daude - Leonard eta Penny ("The Big Bang Theory" telesaila):
Demagun Penny Europan dagoela eta Leonardek ezusteko festa bat egin nahi diola. Eta ezin du bururatu bere lagunen zerrendatik botatzea baino ezer hoberik, bere lagun guztiei jarioari buruzko eguneraketa bat bidaliz: "Poztu dezagun Penny!" (Europan dago, lo egiten duen bitartean, ez du hau guztia ikusten eta ezin du ikusi, ez dagoelako). Azken batean, argitalpen hau ezabatzen du, Jariotik ezabatu eta sarbidea berrezartzen du, ezer nabaritu ez dezan eta eskandalurik egon ez dadin.
Hau guztia ondo dago, baina demagun sistema banatuta dagoela eta gauzak apur bat gaizki joan direla. Gerta daiteke, adibidez, Penny-ren sarbide-murrizketa argitalpen hau agertu ondoren gertatu izana, gertaerak kausa eta efektuaren arabera erlazionatuta ez badaude. Egia esan, negozio-funtzio bat betetzeko Kausazko koherentzia behar den adibide bat da (kasu honetan).
Izan ere, datu-basearen propietate ez-hutsak dira - oso jende gutxik onartzen ditu. Goazen ereduetara.
Koherentzia-ereduak
Zer da zehazki datu-baseetan koherentzia-eredu bat? Hauek dira sistema banatu batek bezeroak zein datu jaso ditzakeen eta zein sekuentzian ematen dituen bermeetako batzuk.
Printzipioz, koherentzia-eredu guztiak sistema banatu batek ordenagailu eramangarri bateko nodo batean exekutatzen duen sistemaren antzekoa den adierazten dute. Eta horren antzekoa da geobanatutako milaka "Nodo"tan exekutatzen den sistema ordenagailu eramangarri batekin, zeinetan propietate horiek guztiak automatikoki egiten diren printzipioz.
Beraz, koherentzia-ereduak sistema banatuetan soilik aplikatzen dira. Lehen existitzen ziren eta eskalatze bertikal berean funtzionatzen zuten sistema guztiek ez zuten halako arazorik izan. Buffer Cache bat zegoen, eta dena beti irakurtzen zen bertatik.
Eredu Indartsua
Egia esan, lehenengo eredua Strong da (edo igoera gaitasun-lerroa, askotan esaten den bezala). Hau koherentzia-eredu bat da, aldaketa bakoitza gertatu dela baieztatu ondoren sistemaren erabiltzaile guztientzat ikusgai egongo dela ziurtatzen duena.
Horrek datu-baseko gertaera guztien ordena globala sortzen du. Hau oso koherentzia propietate sendoa da, eta, oro har, oso garestia da. Hala ere, oso ondo onartzen da. Oso garestia eta motela da - gutxitan erabiltzen da. Honi igoera gaitasuna deitzen zaio.
Spanner-en onartzen den beste propietate sendoagoa dago - Kanpoko koherentzia izenekoa. Geroxeago hitz egingo dugu horretaz.
kausal
Hurrengoa Kausazkoa da, eta horixe da, hain zuzen, hitz egiten ari nintzenaz. Indartsuaren eta Kausalaren artean beste hainbat azpi-maila daude hitz egingo ez ditudanak, baina denak Kausazkora laburtzen dira. Eredu garrantzitsu bat da, eredu guztien artean indartsuena delako, sare edo partizioen presentzian koherentziarik sendoena delako.
Kausalak gertakariak kausa-ondorio erlazio baten bidez lotzen diren egoera bat dira. Askotan, bezeroaren ikuspuntutik irakurri zure eskubideak bezala hautematen dira. Bezeroak balio batzuk behatu baditu, ezin ditu iraganean zeuden balioak ikusi. Dagoeneko hasi da aurrizkiaren irakurketak ikusten. Dena gauza berdinera dator.
Kausalak koherentzia-eredu gisa zerbitzariko gertaeren ordena partziala da, non bezero guztien gertaerak sekuentzia berean behatzen diren. Kasu honetan, Leonard eta Penny.
balizko
Hirugarren eredua Behin-behineko koherentzia da. Hau da sistema banatu guztiek onartzen dutena, zentzuzkoa den eredu minimoa. Honakoa esan nahi du: datuetan aldaketa batzuk ditugunean, noizbait koherente bihurtzen dira.
Momentu horretan ez du ezer esaten, bestela Kanpoko koherentzia bihurtuko litzateke - guztiz bestelako istorio bat izango litzateke. Hala ere, oso eredu ezaguna da, ohikoena. Lehenespenez, sistema banatuen erabiltzaile guztiek Eventual Consistency erabiltzen dute.
Adibide konparatibo batzuk jarri nahi ditut:
Zer esan nahi dute gezi hauek?
- Latentzia. Koherentzia-indarra handitzen den heinean, handiago bihurtzen da ageriko arrazoiengatik: erregistro gehiago egin behar dituzu, klusterrean parte hartzen duten ostalari eta nodo guztiengandik datuak dagoeneko hor daudela baieztatu behar duzu. Ondorioz, Evenual Consistency-k du erantzunik azkarrena, izan ere, oro har, oroimenean ere konprometitu dezakezu eta hori, printzipioz, nahikoa izango da.
- Erabilgarritasuna. Hau ulertzen badugu sistemak sare-hausteen, partizioen edo nolabaiteko hutsegiteen aurrean erantzuteko duen gaitasuna bezala, akatsen tolerantzia handitu egiten da koherentzia-eredua txikitu ahala, nahikoa baita guretzat ostalari bat bizitzea eta aldi berean. denborak datu batzuk sortzen ditu. Behin-behineko koherentziak ez du datuei buruzko ezer bermatzen; edozer izan daiteke.
- Anomaliak. Aldi berean, noski, anomalien kopurua handitzen da. Strong Consistency-n ia ez lukete batere existitu behar, baina Eventual Consistency-n edozer izan daitezke. Galdera sortzen da: zergatik aukeratzen du jendeak Eventual Consistency anomaliak baditu? Erantzuna da Behin-behineko koherentzia ereduak aplikagarriak direla eta anomaliak existitzen direla, adibidez, denbora laburrean; morroia erabil daiteke datu koherenteak irakurtzeko eta irakurtzeko; Askotan koherentzia sendoko ereduak erabiltzea posible da. Praktikan honek funtzionatzen du, eta askotan anomalien kopurua denboran mugatua da.
CAP teorema
Koherentzia, erabilgarritasuna hitzak ikusten dituzunean, zer datorkizu burura? Hori bai - CAP teorema! Orain mitoa uxatu nahi dut... Ez naiz ni - Martin Kleppmann da, artikulu zoragarri bat idatzi zuena, liburu zoragarri bat.
CAP teorema 2000ko hamarkadan koherentzia, erabilgarritasuna, partizioak: hartu bi, eta ezin dituzu hiru aukeratu. Printzipio jakin bat zen. Urte batzuk geroago teorema gisa frogatu zuten Gilbertek eta Lynchek. Ondoren, hau mantra gisa erabiltzen hasi zen - sistemak CA, CP, AP eta abarretan banatzen hasi ziren.
Teorema hau ondoko kasuetarako frogatu zen... Lehenik eta behin, Erabilgarritasuna ez zen zerotik ehundara arteko balio etengabetzat hartu (0 - sistema "hilda dago", 100 - azkar erantzuten du; horrela kontsideratzera ohituta gaude) , baina algoritmoaren propietate gisa, bere exekuzio guztietan datuak itzultzen dituela bermatzen duena.
Ez dago erantzun denborari buruz hitzik! Badago 100 urteren buruan datuak itzultzen dituen algoritmo bat; erabilgarri dagoen algoritmo guztiz zoragarria, CAP teoremaren parte dena.
Bigarrena: teorema gako bereko balioen aldaketetarako frogatu zen, aldaketa horiek tamainaz alda daitezkeen arren. Horrek esan nahi du errealitatean ia ez direla erabiltzen, ereduak desberdinak direlako.
Zertarako da hau guztia? Gainera, CAP teorema frogatu zen moduan ia ez da aplikagarria eta oso gutxitan erabiltzen da. Forma teorikoan, nolabait dena mugatzen du. Intuitiboki zuzena den printzipio jakin bat bihurtzen da, baina, oro har, ez da frogatu.
Koherentzia kausala da eredurik indartsuena
Orain gertatzen ari dena da hiru gauza lor ditzakezula: koherentzia, erabilgarritasuna partizioak erabiliz. Bereziki, Kausazko koherentzia da koherentzia-eredurik indartsuena, oraindik ere Partizioen aurrean funtzionatzen duena (sarean etenaldiak). Horregatik du hain interes handia, eta horregatik hartu genuen.
Lehenik eta behin, aplikazioen garatzaileen lana errazten du. Bereziki, zerbitzariaren laguntza handia egotea: bezero baten barruan gertatzen diren erregistro guztiak beste bezero batera sekuentzia berean iristea bermatzen denean. Bigarrenik, partizioak jasaten ditu.
MongoDB barne sukaldea
Bazkaria dela gogoratuz, sukaldera mugitzen gara. Sistemaren ereduaren berri emango dizut, hots, MongoDB zer den horrelako datu-base baten berri lehen aldiz entzuten dutenentzat.
MongoDB (aurrerantzean "MongoDB" deitzen zaio) eskala horizontala onartzen duen sistema banatua da, hau da, zatiketa; eta zati bakoitzaren barruan datuen erredundantzia ere onartzen du, hau da, erreplikazioa.
MongoDB-n (ez da datu-base erlazional bat) zatiketak oreka automatikoa egiten du, hau da, dokumentu-bilduma bakoitza (edo "taula" datu erlazionaletan) zatitan banatzen da, eta zerbitzariak automatikoki mugitzen ditu zatien artean.
Bezero baten eskaerak banatzen dituen Query Router-a lan egiten duen bezero bat da. Dagoeneko badaki non eta zer datu dauden eta eskaera guztiak zati zuzenera bideratzen ditu.
Beste puntu garrantzitsu bat: MongoDB maisu bakarra da. Lehen mailako bat dago: dituen gakoak onartzen dituzten erregistroak har ditzake. Ezin duzu idatzi multimasterrik egin.
4.2 bertsioa egin genuen - gauza interesgarri berriak agertu ziren bertan. Bereziki, Lucene - search - hots, java exekutagarria txertatu zuten zuzenean Mongo-n, eta han Lucene bidez bilaketak egiteko aukera izan zen, Elastican bezala.
Eta produktu berri bat egin zuten - Charts, Atlas-en ere eskuragarri dago (Mongoren hodeia). Doako maila bat dute; horrekin jolastu dezakezu. Asko gustatu zait Charts - datuen bistaratzea, oso intuitiboa.
Osagaiak Kausazko koherentzia
Gai honi buruz argitaratu diren 230 artikulu inguru zenbatu ditut - Leslie Lampert-enak. Orain nire memoriatik material hauen zati batzuk helaraziko dizkizut.
1970eko hamarkadan idatzitako Leslie Lampert-en artikulu batekin hasi zen dena. Ikus dezakezunez, gai honi buruzko ikerketa batzuk abian dira oraindik. Orain Kausazko koherentziak interesa izaten ari da sistema banatuen garapenarekin lotuta.
Murrizketak
Zein muga daude? Hori da, hain zuzen ere, puntu nagusietako bat, ekoizpen-sistema batek ezartzen dituen murrizketak artikulu akademikoetan dauden murrizketak oso desberdinak direlako. Askotan nahiko artifizialak dira.
- Lehenik eta behin, "MongoDB" maisu bakarra da, lehen esan dudan bezala (hau asko errazten da).
- Sistemak 10 mila zati inguru onartu behar dituela uste dugu. Ezin dugu balio hori esplizituki mugatuko duen erabaki arkitektonikorik hartu.
- Hodei bat dugu, baina suposatzen dugu pertsona batek oraindik aukera izan behar duela bitarra deskargatzen duenean, ordenagailu eramangarrian exekutatzen duenean eta dena ondo funtzionatzen duenean.
- Ikerketak oso gutxitan suposatzen duen zerbait suposatzen dugu: kanpoko bezeroek nahi dutena egin dezakete. MongoDB kode irekia da. Horren arabera, bezeroak hain adimentsuak eta haserreak izan daitezke - dena hautsi nahi dezakete. Bizantziar Feilors sor daitezkeela uste dugu.
- Perimetrotik kanpo dauden kanpoko bezeroentzat, muga garrantzitsu bat dago: funtzio hau desgaituta badago, ez da errendimenduaren hondatzerik ikusi behar.
- Beste puntu bat, oro har, antiakademikoa da: aurreko bertsioen eta etorkizunekoen bateragarritasuna. Gidari zaharrek eguneratze berriak onartu behar dituzte, eta datu-baseak kontrolatzaile zaharrak onartu behar ditu.
Oro har, horrek guztiak murrizketak ezartzen ditu.
Kausazko koherentzia osagaiak
Orain osagai batzuei buruz hitz egingo dut. Kausazko koherentzia orokorrean kontuan hartzen badugu, blokeak hauta ditzakegu. Bloke jakin bati dagozkion lanen artean aukeratu dugu: mendekotasunaren jarraipena, erlojuak aukeratzea, erloju hauek nola sinkroniza daitezkeen elkarren artean eta nola bermatzen dugun segurtasuna - hau da hitz egingo dudanaren laburpena:
Mendekotasunen jarraipena osoa
Zergatik behar da? Beraz, datuak errepikatzen direnean, erregistro bakoitzak, datu-aldaketa bakoitzak zer-nolako aldaketen araberakoak diren informazioa dauka. Lehen eta inozoa den aldaketa erregistro bat daukan mezu bakoitzak aurreko mezuei buruzko informazioa jasotzen duenean gertatzen da:
Adibide honetan, parentesi artean dagoen zenbakia erregistro-zenbakiak dira. Batzuetan balioak dituzten erregistro hauek osorik transferitzen dira, batzuetan bertsio batzuk transferitzen dira. Oinarrian aldaketa bakoitzak aurrekoari buruzko informazioa dauka (jakina da hori guztia bere baitan darama).
Zergatik erabaki genuen ikuspegi hau ez erabiltzea (jarraipen osoa)? Jakina, ikuspegi hori ez baita praktikoa: sare sozial batean egindako edozein aldaketa sare sozial horretan aurreko aldaketa guztien araberakoa da, eguneratze bakoitzean Facebook edo VKontakte transferituz. Hala ere, ikerketa asko dago Mendekotasun Osoaren Jarraipenari buruz - sare sozialen aurrekoak dira; egoera batzuetan benetan funtzionatzen du.
Menpekotasunen jarraipena esplizitua
Hurrengoa mugatuagoa da. Informazioaren transferentzia ere kontuan hartzen da hemen, baina argi eta garbi menpe dagoena bakarrik. Zerren araberakoa da, oro har, Aplikazioak zehazten duena. Datuak errepikatzen direnean, kontsultak erantzunak itzultzen ditu aurreko mendekotasunak betetzen direnean, hau da, erakusten direnean. Hau da Kausazko koherentziaren funtzionamenduaren funtsa.
5. erregistroa 1, 2, 3, 4 erregistroen araberakoa dela ikusten du - horren arabera, bezeroak Penny-ren sarbide-erabakiak egindako aldaketetarako sarbidea izan baino lehen itxaroten du, aurreko aldaketa guztiak datu-basetik igaro direnean.
Hau ere ez zaigu egokitzen, oraindik informazio gehiegi dagoelako, eta gauzak motelduko dituelako. Bada beste ikuspegi bat...
Lampport erlojua
Oso zaharrak dira. Lamport Clock-ek esan nahi du menpekotasun horiek funtzio eskalar batean tolestuta daudela, hau da, Lamport Clock izenekoa.
Funtzio eskalar bat zenbaki abstraktu bat da. Askotan denbora logikoa deitzen zaio. Gertaera bakoitzarekin, kontagailu hau handitzen da. Gaur egun prozesuak ezagutzen duen Counter-ek mezu bakoitza bidaltzen du. Argi dago prozesuak sinkronizatuta egon daitezkeela, garai guztiz desberdinak izan ditzaketela. Hala ere, sistemak nolabait orekatzen du erlojua horrelako mezuekin. Zer gertatzen da kasu honetan?
Bitan zatitu nuen zati handi hori argi uzteko: Lagunak nodo batean bizi daitezke, bildumaren zati bat daukana, eta Feed beste nodo batean bizi daiteke, bilduma honen zati bat daukana. Argi al dago nola atera daitezkeen lerrotik? Lehenengo jarioak: "Erreplikatua" esango du eta gero Lagunak. Sistemak ez badu nolabaiteko bermerik ematen Jarioa ez dela erakutsiko Lagunen bildumako Lagunen menpekotasunak ere entregatu arte, orduan aipatu dudan egoera izango dugu.
Ikusten duzu Feed-en kontagailu-denbora nola handitzen den logikoki:
Beraz, Lamport Clock eta Kausazko koherentzia honen propietate nagusia (Lamport Clock bidez azaldua) hau da: A eta B Gertaerak baditugu eta B Gertaera A* Gertaeraren araberakoa bada, orduan A Gertaeraren Denbora Logikoa baino txikiagoa da. LogicalTime B gertaeratik.
* Batzuetan, A B baino lehen gertatu zela ere esaten dute, hau da, A B baino lehen gertatu zela - orokorrean gertatutako gertakari multzo osoa partzialki ordenatzen duen erlazio jakin bat da.
Kontrakoa ez da zuzena. Hau da benetan Lamport Clock-en desabantaila nagusietako bat - ordena partziala. Bada aldibereko gertaerei buruzko kontzeptu bat, hau da, ez (A B baino lehenago gertatu) ez (A B baino lehen gertatu ez den gertakariak). Adibide bat Leonardek beste norbait lagun gisa gehitzea litzateke (ez Leonard ere, baina Sheldon, adibidez).
Hau da Lamport-eko erlojuekin lan egitean sarri erabiltzen den propietatea: funtzioari berariaz begiratzen diote eta hortik ondorioztatzen dute agian gertaera horiek menpekoak direla. Modu bat egia delako: LogicalTime A LogicalTime B baino txikiagoa bada, orduan B ezin da A baino lehen gertatu; eta gehiago bada, agian.
Erloju bektoriala
Lamport erlojuaren garapen logikoa erloju bektoriala da. Ezberdinak dira hemen dagoen nodo bakoitzak bere erloju propioa duela eta bektore gisa transmititzen direlako.
Kasu honetan, bektorearen zerogarren indizea Feed-en arduraduna dela ikusten duzu, eta bektorearen lehen indizea Lagunak (nodo horietako bakoitza) dela. Eta orain handituko dira: "Feed"-en zero indizea handitzen da idaztean - 1, 2, 3:
Zergatik da hobea Vector Clock? aldibereko zein gertakari diren eta nodo ezberdinetan noiz gertatzen diren jakiteko aukera ematen baitute. Hau oso garrantzitsua da MongoDB bezalako sharding sistema baterako. Hala ere, ez dugu hau aukeratu, nahiz eta gauza zoragarria den, eta oso ondo funtzionatzen duen, eta seguruenik egokituko litzaiguke...
10 mila zati baditugu, ezin ditugu 10 mila osagai transferitu, nahiz eta konprimitu edo beste zerbait asmatu - karga bektore honen bolumena baino hainbat aldiz txikiagoa izango da oraindik. Horregatik, bihotza eta hortzak estutuz, planteamendu hori alde batera utzi eta beste batera pasa ginen.
TrueTime giltza. Erloju atomikoa
Spanner-i buruzko istorio bat egongo zela esan nion. Hau gauza polita da, XXI. mendetik ateratakoa: erloju atomikoak, GPS sinkronizazioa.
Zein da ideia? "Spanner" Google sistema bat da, duela gutxi jendearentzat ere eskuragarri egon zen (SQL gehitu zioten). Bertan transakzio bakoitzak denbora-zigilu bat dauka. Ordua sinkronizatuta dagoenez*, gertaera bakoitzari ordu zehatz bat eslei dakioke - erloju atomikoek itxaron denbora dute, eta, ondoren, beste ordu bat "gertatuko dela" bermatzen da.
Horrela, datu-basean idatzi eta denbora tarte batean itxaronez gero, gertaeraren Serializazioa automatikoki bermatzen da. Printzipioz imajina daitekeen koherentzia-eredurik indartsuena dute - Kanpoko koherentzia da.
* Hau da Lampart erlojuen arazo nagusia - ez dira inoiz sinkronoak sistema banatuetan. Alde egin dezakete; NTPrekin ere, oraindik ez dute oso ondo funtzionatzen. "Spanner"-ek erloju atomikoa du eta sinkronizazioa, antza, mikrosegundokoa da.
Zergatik ez dugu aukeratu? Ez dugu suposatzen gure erabiltzaileek erloju atomiko bat dutenik. Agertzen direnean, ordenagailu eramangarri guztietan sartuta, GPS sinkronizazio super cool moduko bat egongo da - orduan bai... Baina oraingoz posible den onena Amazon da, Base Stations - fanatikoentzat... Beraz, beste erloju batzuk erabili ditugu. .
Erloju hibridoa
Hau da MongoDB-n kausazko koherentzia ziurtatzerakoan. Nola hibridoak dira? Hibridoa balio eskalar bat da, baina bi osagai ditu:
- Lehena Unix garaia da (zenbat segundo igaro diren “informatika munduaren hasieratik”).
- Bigarrena gehikuntzaren bat da, 32 biteko sinatu gabeko int bat ere.
Hori da guztia, egia esan. Badago planteamendu hau: denboraz arduratzen den zatia denbora guztian erlojuarekin sinkronizatuta dago; Eguneratze bat gertatzen den bakoitzean, zati hori erlojuarekin sinkronizatzen da eta ordua gutxi-asko zuzena dela ematen du, eta gehikuntzak denbora berean gertatutako gertaerak bereizteko aukera ematen du.
Zergatik da garrantzitsua MongoDBrentzat? Une jakin batean backup jatetxe mota batzuk egiteko aukera ematen duelako, hau da, gertaera denboraren arabera indexatzen da. Hau garrantzitsua da gertaera batzuk behar direnean; Datu-base baterako, gertaerak datu-basean denbora-tarte jakin batzuetan gertatutako aldaketak dira.
Arrazoi garrantzitsuena zuri bakarrik esango dizut (mesedez, ez esan inori)! Hau egin dugu MongoDB OpLog-en datu antolatu eta indexatuen itxura dutelako. OpLog datu-baseko aldaketa guztiak biltzen dituen datu-egitura bat da: lehenik OpLog-era joaten dira, eta gero Biltegiratze-ra aplikatzen dira erreplikatutako data edo zati bat denean.
Hau izan zen arrazoi nagusia. Hala ere, datu-base bat garatzeko baldintza praktikoak ere badaude, eta horrek esan nahi du sinplea izan beharko lukeela: kode txikia, berridatzi eta probatu beharreko gauza gutxien hondatuta. Gure oplogak erloju hibridoen bidez indexatu izanak asko lagundu zigun eta aukeraketa egokia egiteko aukera eman zigun. Benetan irabazi zuen eta nolabait magikoki funtzionatu zuen lehen prototipoan. Oso polita izan zen!
Erlojuaren sinkronizazioa
Literatura zientifikoan deskribatzen diren hainbat sinkronizazio metodo daude. Sinkronizazioaz ari naiz bi zati ezberdin ditugunean. Erreplika-multzo bat badago, ez dago inolako sinkronizazio beharrik: hau "maisu bakarra" da; OpLog bat dugu, eta bertan aldaketa guztiak sartzen dira - kasu honetan, dena dagoeneko sekuentzialki ordenatuta dago "Oplog"-en bertan. Baina bi zati ezberdin baditugu, denbora sinkronizazioa garrantzitsua da hemen. Hemen erloju bektorialak gehiago lagundu zuen! Baina ez ditugu.
Bigarrena egokia da - "Bihotz-taupadak" da. Denbora-unitate bakoitzean gertatzen diren seinale batzuk trukatzea posible da. Baina Bihotz-taupadak motelegiak dira, ezin diogu gure bezeroari latentzia eman.
Benetako denbora gauza zoragarria da, noski. Baina, berriro ere, hau da etorkizuna ziurrenik... Atlasen dagoeneko egin daitekeen arren, dagoeneko badaude “Amazon” ordu-sinkronizatzaile azkarrak. Baina ez da guztion eskura egongo.
Esamesak mezu guztiek denbora barne hartzen dutenean da. Hau da gutxi gorabehera erabiltzen duguna. Nodoen arteko mezu bakoitza, kontrolatzaile bat, datu-nodoen bideratzaile bat, MongoDB-rentzat dena elementu moduko bat da, exekutatzen den erloju bat duen datu-baseko osagaia. Denbora hibridoaren esanahia dute nonahi, transmititzen da. 64 bit? Horrek ahalbidetzen du, hau posible da.
Nola funtzionatzen du dena batera?
Hemen erreplika multzo bat ikusten ari naiz pixka bat errazteko. Lehen Hezkuntza eta Bigarren Hezkuntza daude. Bigarren mailakoak erreplikatzea egiten du eta ez dago beti Lehen mailakoarekin guztiz sinkronizatuta.
Txertaketa bat gertatzen da "Primary"-n denbora-balio jakin batekin. Txertatze honek barne-zenbaketa 11 handitzen du, hau gehienezkoa bada. Edo erlojuaren balioak egiaztatuko ditu eta erlojuarekin sinkronizatuko ditu erlojuaren balioak handiagoak badira. Horrek denboraren arabera antolatzeko aukera ematen du.
Grabaketa egin ondoren, momentu garrantzitsu bat gertatzen da. Erlojua "MongoDB"-en dago eta "Oplog"-en idazten denean bakarrik handitzen da. Hau da sistemaren egoera aldatzen duen gertaera. Artikulu klasiko guztietan, gertaeratzat hartzen da mezu batek nodo bat jotzen duenean: mezua iritsi da, hau da, sistemak egoera aldatu duela esan nahi du.
Ikerketan zehar ez dagoelako guztiz argi mezu hau nola interpretatuko den. Seguru dakigu “Oplog”-en islatzen ez bada, ez dela inola ere interpretatuko, eta sistemaren egoera aldatzea “Oplog”-en sarrera bat baino ez dela. Horrek dena sinplifikatzen digu: ereduak sinplifikatu egiten du, eta erreplika multzo baten barruan antolatzeko aukera ematen digu, eta beste hainbat gauza erabilgarriak.
Dagoeneko "Oplog"-i idatzita dagoen balioa itzultzen da - badakigu "Oplog"-ek balio hori duela jada, eta bere denbora 12 dela. Orain, demagun, irakurketa beste nodo batetik hasten da (Bigarren mailakoa), eta ClusterTime-n igortzen du. mezua. Berak dio: "Gutxienez 12 edo XNUMX bitartean gertatutako guztia behar dut" (ikus goiko irudia).
Hau da Causal a consistent (CAT) deitzen dena. Teorian badago halako kontzeptu bat non denbora zati bat dela, berez koherentea dena. Kasu honetan, 12. denboran ikusi zen sistemaren egoera dela esan dezakegu.
Orain ez dago ezer hemen oraindik, mota honek Bigarren Hezkuntzako datuak Erreplikatzeko Lehen mailako datuak errepikatzeko behar duzun egoera simulatzen duelako. Itxaroten du... Eta orain datuak iritsi dira - balio hauek itzultzen ditu.
Hori gutxi gorabehera denak funtzionatzen du. Ia.
Zer esan nahi du "ia"? Demagun badela pertsonaren bat hau guztia nola funtzionatzen duen irakurri eta ulertu duena. Konturatu nintzen ClusterTime gertatzen den bakoitzean barneko erloju logikoa eguneratzen duela eta, ondoren, hurrengo sarrera bat handitzen dela. Funtzio honek 20 lerro hartzen ditu. Demagun pertsona honek 64 biteko zenbaki handiena transmititzen duela, bat kenduta.
Zergatik "minus bat"? Barne erlojua balio honetan ordezkatuko denez (jakina, hau ahalik eta ordua baino handiagoa da), orduan sarrera bat gertatuko da "Oplog"-en, eta erlojua beste unitate batez handituko da - eta dagoeneko egongo da. balio maximoa izan (unitate guztiak daude besterik gabe, ez dago beste inora joan), unsaint ints).
Argi dago honen ondoren sistema erabat eskuraezin bihurtzen dela ezertarako. Deskargatu eta garbitu daiteke soilik - eskuzko lan asko. Erabilgarritasun osoa:
Gainera, hori beste nonbait errepikatzen bada, kluster osoa eroriko da. Egoera guztiz onartezina, edonork oso azkar eta erraz antola dezakeena! Hori dela eta, momentu hau garrantzitsuenetakotzat hartu dugu. Nola saihestu?
Gure bidea clusterTime sinatzea da
Horrela transmititzen da mezuan (testu urdinaren aurretik). Baina sinadura bat sortzen ere hasi ginen (testu urdina):
Sinadura datu-basearen barruan gordetzen den gako batek sortzen du, perimetro seguru baten barruan; bera sortu eta eguneratzen da (erabiltzaileek ez dute horri buruz ezer ikusten). Hash bat sortzen da, eta mezu bakoitza sortzen denean sinatzen da eta jasotzen denean baliozkotzen da.
Ziurrenik jendearen buruan sortzen da galdera: "Zenbat moteltzen ditu horrek gauzak?" Azkar funtzionatu beharko lukeela esan nizuen, batez ere funtzio hori ez badago.
Zer esan nahi du kasu honetan Kausazko koherentzia erabiltzeak? Hau afterClusterTime parametroa erakusteko da. Hori gabe, balioak pasako ditu hala ere. Gossiping, 3.6 bertsiotik hasita, beti funtzionatzen du.
Etengabeko sinadurak sortzeari uzten badiogu, sistema moteldu egingo du ezaugarririk ez badago ere, gure planteamendu eta eskakizunak betetzen ez dituena. Orduan, zer egin genuen?
Egin ezazu azkar!
Gauza nahiko sinplea da, baina trikimailua interesgarria da: partekatuko dut, agian norbait interesatuko zaio.
Sinatutako datuak gordetzen dituen hash bat dugu. Datu guztiak cachetik pasatzen dira. Cacheak ez du denbora zehatza sinatzen, Barrutia baizik. Balioren bat iristen denean, Range bat sortzen dugu, azken 16 bitak ezkutatzen ditugu eta balio hau sinatzen dugu:
Sinadura hori jasoz gero, sistema bizkortzen dugu (erlatiboki) 65 mila aldiz. Oso ondo funtzionatzen du: esperimentuak egin genituenean, denbora benetan 10 mila aldiz gutxitu zen eguneraketa sekuentziala izan genuenean. Argi dago kontraesanean daudenean, horrek ez duela funtzionatzen. Baina kasu praktiko gehienetan funtzionatzen du. Range sinadura sinadurarekin batera konbinatzeak segurtasun arazoa konpondu zuen.
Zer ikasi dugu?
Honetatik atera ditugun ikasgaiak:
- Materialak, ipuinak, artikuluak irakurri behar ditugu, gauza interesgarri asko ditugulako. Ezaugarriren bat lantzen dugunean (batez ere orain, transakzioak egiten genituenean, etab.), irakurri eta ulertu behar dugu. Denbora behar da, baina egia esan oso erabilgarria da non gauden argi uzten baitu. Ez zirudien ezer berririk atera, osagaiak besterik ez genituen hartu.
Orokorrean, konferentzia akademiko bat (Sigmon, adibidez) dagoenean pentsamoldearen nolabaiteko aldea dago -denak ideia berrietan zentratzen dira-. Zer da berria gure algoritmoak? Hemen ez dago ezer berezirik berririk. Berritasuna lehendik dauden planteamenduak elkarrekin nahasteko moduan datza. Horregatik, lehenengo gauza klasikoak irakurtzea da, Lampart-etik hasita.
- Ekoizpenean, baldintzak guztiz desberdinak dira. Ziur nago zuetako asko ez zaretela datu base "esferikoen" aurrean huts abstraktu batean, baizik eta erabilgarritasun, latentzia eta akatsen tolerantzia arazoak dituzten gauza normal eta errealen aurrean.
- Azken gauza da ideia desberdinak aztertu eta hainbat artikulu guztiz desberdinak planteamendu batean bateratu behar genituela, elkarrekin. Sinatzeari buruzko ideia, oro har, Paxos protokoloa kontuan hartzen zuen artikulu batetik sortu zen, bizantziar ez diren hutsalentzat baimen-protokoloaren barruan dagoena, bizantziarrentzat -baimen-protokolotik kanpo... Orokorrean, horixe da hain zuzen. egiten amaitu zuen.
Hemen ez dago ezer berririk! Baina dena nahastu bezain laster... Olivier entsalada errezeta zentzugabekeria dela esatearen berdina da, arrautzak, maionesa eta pepinoak asmatuak baitira... Istorio bera da.
Honekin amaituko dut. Eskerrik asko!
Zure galderak
Entzuleen galdera (aurrerantzean B deitzen da): – Eskerrik asko, Mikhail, erreportajeagatik! Denborari buruzko gaia interesgarria da. Gossiping erabiltzen ari zara. Bakoitzak bere ordua duela esan zuten, bakoitzak bere ordua ezagutzen duela. Ulertzen dudanez, gidari bat daukagu - bezero asko egon daitezke gidariak dituztenak, kontsulta-planifikatzaileak ere, zatiak ere... Eta zertara dator sistema bat-batean desadostasun bat baldin badugu: norbaitek erabakitzen du batentzat dela. minutu aurretik, norbait minutu bat atzerago? Non geratuko gara?
MT: – Galdera bikaina benetan! Apurrei buruz hitz egin nahi nuen. Galdera ondo ulertzen badut, egoera hau dugu: 1. zatia eta 2. zatia daude, irakurketa bi zati horietatik gertatzen da - desadostasun bat dute, ez dute elkarren artean elkarreragiten, ezagutzen duten denbora ezberdina delako, batez ere, oplogetan existitzen diren denbora.
Demagun 1. zatiak milioi bat erregistro egin zituela, 2. zatiak ez zuela ezer egin eta eskaera bi zatitara iritsi zela. Eta lehenengoak milioi bat baino gehiagoko afterClusterTime dauka. Egoera horretan, azaldu dudan bezala, 2. zatiak ez du inoiz erantzungo.
V: – Nola sinkronizatzen duten eta ordu logiko bat aukeratzen duten jakin nahi nuen?
MT: - Oso erraza sinkronizatzeko. Shard, afterClusterTime etortzen zaionean eta "Oplog"-en denborarik aurkitzen ez duenean, ez du onartzen. Hau da, bere denbora eskuekin balio horretara altxatzen du. Horrek esan nahi du ez duela eskaera honekin bat datorren gertaerarik. Gertaera hau artifizialki sortzen du eta horrela Kausazko Konsistentzia bihurtzen da.
V: – Eta honen ondoren sarean galduta zeuden beste gertaera batzuk etorriko balira?
MT: – Shard berriro etorriko ez diren moduan diseinatuta dago, maisu bakarra baita. Dagoeneko izena eman badu, ez dira etorriko, gero etorriko dira. Ezin da gertatu zerbait nonbait itsatsita egotea, gero ez du idazten, eta orduan gertaera hauek iristen dira, eta Kausazko koherentzia hautsi da. Idazten ez duenean, denak etorri behar dira hurrengo (itxaron egingo du).
V: – Hainbat galdera ditut ilarei buruz. Kausazko koherentziak egin beharreko ekintzen ilara zehatz bat dagoela suposatzen du. Zer gertatzen da gure paketeren bat desagertzen bada? Badator 10a, 11a... 12a desagertu da, eta gainontzeko guztiak egia bihurtzeko zain daude. Eta bat-batean gure autoa hil egin zen, ezin dugu ezer egin. Ba al dago exekutatu aurretik pilatzen den ilararen gehienezko luzerarik? Zein porrot larri gertatzen da edozein egoera galtzen denean? Gainera, aurreko egoeraren bat dagoela idazten badugu, hortik abiatu beharko genuke nolabait? Baina ez zuten urrundu!
MT: – Galdera bikaina ere bai! Zertan ari gara? MongoDB-k quorum idazketa kontzeptua du, quorum irakurketa. Zein kasutan gal daiteke mezu bat? Idazkera bat quoruma ez denean edo irakurketa bat quoruma ez denean (zaborren bat ere itsatsi daiteke).
Kausazko koherentziari dagokionez, proba esperimental handi bat egin zen, eta horren emaitza izan zen idazketak eta irakurketak quoruma ez direnean, Kausazko koherentziaren urraketak gertatzen direla. Zehazki esaten duzuna!
Gure aholkua: erabili gutxienez quorum irakurketa Kausazko koherentzia erabiltzean. Kasu honetan, ez da ezer galduko, nahiz eta quorum erregistroa galdu... Egoera ortogonala da: erabiltzaileak ez badu datuak galtzea nahi, quorum erregistroa erabili behar du. Kausazko koherentziak ez du iraunkortasuna bermatzen. Iraunkortasuna errepikapenarekin eta erreplikarekin lotutako makineriarekin bermatzen da.
V: – Guretzat sharding-a egiten duen instantzia bat sortzen dugunean (ez maisua, baina esklaboa, hurrenez hurren), bere makinaren Unix denboran edo “maisuaren” denboran oinarritzen da; Lehen aldiz sinkronizatzen da ala aldizka?
MT: —Orain argituko dut. Shard (hau da, partizio horizontala) - beti dago Primario bat. Eta zati batek "maisu" bat izan dezake eta erreplikak egon daitezke. Baina zatiak grabaketa onartzen du beti, domeinuren bat onartu behar duelako (zatiak Primarioa du).
V: – Beraz, dena “maisuaren” araberakoa da soilik? Denbora maisua erabiltzen al da beti?
MT: - Bai. Irudian esan dezakezu: erlojua markatzen ari da "master"-en, "Oplog"-en sarrera bat gertatzen denean.
V: – Lotzen den eta denborari buruz ezer jakin behar ez duen bezero bat dugu?
MT: - Ez duzu ezer jakin behar! Bezeroan nola funtzionatzen duen hitz egiten badugu: bezeroak Kausazko koherentzia erabili nahi duenean, saio bat ireki behar du. Orain dena dago: saioan transakzioak egitea, eta eskubide bat berreskuratzea... Saio bat bezeroarekin gertatzen diren gertaera logikoen ordenatzea da.
Saio hau irekitzen badu eta han esaten badu Kausazko koherentzia nahi duela (saioak lehenespenez Kausazko koherentzia onartzen badu), dena automatikoki funtzionatzen du. Gidariak denbora hau gogoratzen du eta handitu egiten du mezu berri bat jasotzen duenean. Datuak itzultzen zituen zerbitzaritik aurrekoak zer erantzun eman zuen gogoratzen du. Hurrengo eskaerak afterCluster ("denbora hau baino handiagoa") edukiko du.
Bezeroak ez du ezer jakin behar! Hau guztiz opakoa da berarentzat. Jendeak ezaugarri hauek erabiltzen baditu, zer egin dezake? Lehenik eta behin, bigarren mailakoak modu seguruan irakur ditzakezu: Primariora idatz dezakezu eta geografikoki errepikatutako bigarren mailakoetatik irakurri eta funtzionatzen duela ziurtatu. Aldi berean, Lehen Hezkuntzan grabatutako saioak Bigarren Hezkuntzara ere transferi daitezke, hau da, saio bat ez, hainbat erabil ditzakezu.
V: – Konputazio zientziaren geruza berri bat – CRDT (Conflict-free Replicated Data Types) datu-motak– oso lotuta dago Eventual koherentziaren gaiarekin. Datu mota hauek datu basean integratzea pentsatu al duzu eta zer esan dezakezu horri buruz?
MT: - Galdera ona! CRDTk zentzua du idazketa-gatazkak egiteko: MongoDB-n, maisu bakarra.
V: – Devops-en galdera bat daukat. Mundu errealean, horrelako egoera jesuitikoak daude Bizantziar Porrota gertatzen denean eta babestutako perimetroaren barruko pertsona gaiztoak protokoloan sartzen hasten direnean, artisautza paketeak modu berezi batean bidaltzen dituztenean?
MT: - Perimetroaren barruko pertsona gaiztoak Troiako zaldi bat bezalakoak dira! Perimetro barruko jende gaiztoak gauza txar asko egin ditzake.
V: – Argi dago, gutxi gorabehera, zerbitzarian zulo bat utziz, elefanteen zoo bat jarri eta kluster osoa betiko kolapsatu dezakezula... Eskuzko berreskurapenerako denbora beharko da... Hau, emeki esanda, da. gaizki. Bestalde, hau interesgarria da: bizitza errealean, praktikan, badira egoerak naturalki antzeko barne erasoak gertatzen direnean?
MT: - Bizitza errealean oso gutxitan aurkitzen ditudanez segurtasun-urraketak, ezin dut esan gertatzen diren ala ez. Baina garapenaren filosofiaz hitz egiten badugu, honela pentsatzen dugu: segurtasuna egiten duten mutilei eskaintzen dien perimetro bat dugu, hau gaztelu bat da, harresia; eta perimetroaren barruan nahi duzuna egin dezakezu. Argi dago badirela soilik ikusteko gaitasuna duten erabiltzaileak, eta direktorioa ezabatzeko gaitasuna duten erabiltzaileak daudela.
Eskubideen arabera, erabiltzaileek egin dezaketen kaltea sagua izan daiteke, edo elefantea. Argi dago eskubide osoak dituen erabiltzaileak edozer gauza egin dezakeela. Eskubide mugatuak dituen erabiltzaileak kalte txikiagoa eragin dezake. Bereziki, ezin du sistema hautsi.
V: – Babestutako perimetroan, norbaitek zerbitzariarentzat ustekabeko protokoloak sortzen saiatu zen zerbitzaria guztiz suntsitzeko, eta zorterik baduzu, kluster osoa... Inoiz lortzen al du hori “ongi”?
MT: "Inoiz ez dut horrelako gauzarik entzun". Zerbitzari bat horrela huts egin dezakezula ez da sekretua. Barruan huts egitea, protokolokoa izatea, mezuan horrelako zerbait idatz dezakeen baimendutako erabiltzailea izatea... Izan ere, ezinezkoa da, oraindik egiaztatuko delako. Posible da autentifikazio hau desgaitzea nahi ez duten erabiltzaileentzat - orduan hori da haien arazoa; haiek, gutxi gorabehera, hormak eurek suntsitu zituzten eta han sartu dezakezu elefante bat, zapalduko duena... Baina orokorrean, konpontzailez mozorro zaitezke, zatoz atera!
V: - Eskerrik asko txostenagatik. Sergey (Yandex). Mong-en konstante bat dago Erreplika multzoan botoa ematen duten kideen kopurua mugatzen duena, eta konstante hori 7 (zazpi) da. Zergatik da hau konstante bat? Zergatik ez da hau parametro bat?
MT: – 40 nodo dituzten Erreplika Multzoak ditugu. Beti dago gehiengoa. Ez dakit zein bertsio...
V: – Erreplika multzoan botorik gabeko kideak exekutatu ditzakezu, baina botoa ematen duten 7 kide daude gehienez. Nola iraun dezakegu kasu honetan itzalalditik gure Erreplika multzoa 3 datu-zentrotan banatuta badago? Datu-zentro bat erraz itzal daiteke eta beste makina bat eror daiteke.
MT: – Txostenaren esparrutik apur bat kanpo dago jada. Hau galdera orokorra da. Agian geroago kontatu ahal dizut.
Iragarki batzuk 🙂
Eskerrik asko gurekin geratzeagatik. Gustuko dituzu gure artikuluak? Eduki interesgarri gehiago ikusi nahi? Lagun iezaguzu eskaera bat eginez edo lagunei gomendatuz, , sarrera-mailako zerbitzarien analogo paregabea, guk zuretzat asmatu duguna: (RAID1 eta RAID10-ekin erabilgarri, 24 nukleoraino eta 40 GB DDR4 arte).
Dell R730xd 2 aldiz merkeagoa Amsterdameko Equinix Tier IV datu-zentroan? Hemen bakarrik Herbehereetan! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 $-tik aurrera! Irakurri buruz
Iturria: www.habr.com