Konferenca e radhës HighLoad++ do të mbahet më 6 dhe 7 prill 2020 në Shën Petersburg.
Detajet dhe biletat . HighLoad++ Siberia 2019. Salla "Krasnoyarsk". 25 qershor, ora 12:00. Tezat dhe .
Ndodh që kërkesat praktike bien ndesh me teorinë, ku nuk merren parasysh aspekte të rëndësishme për një produkt komercial. Ky fjalim paraqet një proces për përzgjedhjen dhe kombinimin e qasjeve të ndryshme për krijimin e komponentëve të konsistencës shkakësore bazuar në kërkimin akademik bazuar në kërkesat e një produkti komercial. Dëgjuesit do të mësojnë rreth qasjeve teorike ekzistuese për orët logjike, ndjekjen e varësisë, sigurinë e sistemit, sinkronizimin e orës dhe pse MongoDB u vendos në zgjidhje të caktuara.
Mikhail Tyulenev (në tekstin e mëtejmë MT): – Unë do të flas për konsistencën shkakësore - kjo është një veçori që kemi punuar në MongoDB. Unë punoj në një grup sistemesh të shpërndara, e bëmë atë rreth dy vjet më parë.
Në këtë proces, më është dashur të njihem me shumë kërkime akademike, sepse kjo veçori është studiuar mjaft mirë. Doli që asnjë artikull i vetëm nuk përshtatet me atë që kërkohet në një bazë të dhënash prodhimi për shkak të kërkesave shumë specifike që janë ndoshta të pranishme në çdo aplikim prodhimi.
Unë do të flas se si ne, si konsumatorë të Kërkimit akademik, përgatisim diçka prej tij që më pas mund t'ua paraqesim përdoruesve tanë si një pjatë të gatshme që është e përshtatshme dhe e sigurt për t'u përdorur.
Konsistenca shkakësore. Le të përcaktojmë konceptet
Për të filluar, dua të them në terma të përgjithshëm se çfarë është konsistenca shkakësore. Ka dy personazhe - Leonard dhe Penny (seriali televiziv "The Big Bang Theory"):
Le të themi se Penny është në Evropë dhe Leonard dëshiron t'i organizojë asaj një festë surprizë. Dhe ai nuk mund të mendojë për asgjë më të mirë sesa ta hedhë atë nga lista e miqve të tij, duke u dërguar të gjithë miqve të tij një përditësim në burim: "Le ta bëjmë Penny të lumtur!" (ajo është në Evropë, ndërsa fle, nuk i sheh të gjitha këto dhe nuk mund t'i shohë, sepse nuk është atje). Në fund të fundit, ajo e fshin këtë postim, e fshin atë nga Furnizimi dhe rikthen aksesin në mënyrë që të mos vërejë asgjë dhe të mos ketë skandal.
Kjo është e gjitha mirë dhe mirë, por le të supozojmë se sistemi është shpërndarë dhe gjërat shkuan pak keq. Për shembull, mund të ndodhë që kufizimi i hyrjes së Penny të ketë ndodhur pas shfaqjes së këtij postimi, nëse ngjarjet nuk janë të lidhura me shkak dhe pasojë. Në fakt, ky është një shembull kur kërkohet konsistenca shkakësore për të kryer një funksion biznesi (në këtë rast).
Në fakt, këto janë veti jo të parëndësishme të bazës së të dhënave - shumë pak njerëz i mbështesin ato. Le të kalojmë tek modelet.
Modelet e konsistencës
Çfarë është saktësisht një model konsistence në bazat e të dhënave? Këto janë disa nga garancitë që jep një sistem i shpërndarë se çfarë të dhënash mund të marrë klienti dhe në çfarë sekuence.
Në parim, të gjitha modelet e konsistencës zbresin në atë se sa i ngjashëm është një sistem i shpërndarë me një sistem që funksionon, për shembull, në një nyje në një laptop. Dhe kjo është se sa i ngjashëm është një sistem që funksionon në mijëra "Nyje" të shpërndara gjeografikisht me një laptop, në të cilin të gjitha këto veti kryhen automatikisht në parim.
Prandaj, modelet e konsistencës aplikohen vetëm për sistemet e shpërndara. Të gjitha sistemet që kanë ekzistuar më parë dhe kanë funksionuar në të njëjtin shkallë vertikale nuk kanë pasur probleme të tilla. Kishte një Buffer Cache dhe gjithçka lexohej gjithmonë prej saj.
Modeli i fortë
Në fakt, modeli i parë është i Fortë (ose linja e aftësisë së ngritjes, siç quhet shpesh). Ky është një model konsistence që siguron që çdo ndryshim, pasi të konfirmohet se ka ndodhur, të jetë i dukshëm për të gjithë përdoruesit e sistemit.
Kjo krijon një rend global të të gjitha ngjarjeve në bazën e të dhënave. Kjo është një pronë me konsistencë shumë të fortë dhe në përgjithësi është shumë e shtrenjtë. Megjithatë, ajo mbështetet shumë mirë. Është thjesht shumë i shtrenjtë dhe i ngadalshëm - thjesht përdoret rrallë. Kjo quhet aftësia e ngritjes.
Ekziston një pronë tjetër, më e fortë që mbështetet në Spanner - e quajtur Konsistenca e Jashtme. Ne do të flasim për të pak më vonë.
shkakor
Tjetri është Kauzal, për të cilin po flisja pikërisht. Ka disa nën-nivele të tjera midis Fortë dhe Kauzale për të cilat nuk do të flas, por të gjitha përfundojnë në Kauzal. Ky është një model i rëndësishëm sepse është më i forti nga të gjitha modelet, qëndrueshmëria më e fortë në prani të një rrjeti ose ndarjesh.
Shkaktarët janë në fakt një situatë në të cilën ngjarjet lidhen me një marrëdhënie shkak-pasojë. Shumë shpesh ato perceptohen si Lexoni të drejtat tuaja nga këndvështrimi i klientit. Nëse klienti ka vëzhguar disa vlera, ai nuk mund të shohë vlerat që ishin në të kaluarën. Ai tashmë ka filluar të shohë leximet e parashtesave. Gjithçka vjen në të njëjtën gjë.
Shkaktarët si model konsistence është një renditje e pjesshme e ngjarjeve në server, në të cilën ngjarjet nga të gjithë klientët vëzhgohen në të njëjtën sekuencë. Në këtë rast, Leonard dhe Penny.
përfundimtar
Modeli i tretë është Konsistenca eventuale. Kjo është ajo që absolutisht të gjitha sistemet e shpërndara mbështesin, modeli minimal që ka kuptim fare. Do të thotë si vijon: kur kemi disa ndryshime në të dhëna, në një moment ato bëhen të qëndrueshme.
Në një moment të tillë ajo nuk thotë asgjë, përndryshe do të shndërrohej në Konsistencë të Jashtme - do të ishte një histori krejtësisht tjetër. Sidoqoftë, ky është një model shumë i njohur, më i zakonshmi. Si parazgjedhje, të gjithë përdoruesit e sistemeve të shpërndara përdorin Konsistencën eventuale.
Dua të jap disa shembuj krahasues:
Çfarë kuptimi kanë këto shigjeta?
- Vonesa. Ndërsa forca e konsistencës rritet, ajo bëhet më e madhe për arsye të dukshme: duhet të bëni më shumë regjistrime, të merrni konfirmim nga të gjithë hostet dhe nyjet që marrin pjesë në grup që të dhënat janë tashmë atje. Prandaj, Konsistenca eventuale ka përgjigjen më të shpejtë, sepse atje, si rregull, mund ta angazhoni edhe në kujtesë dhe kjo, në parim, do të jetë e mjaftueshme.
- Disponueshmëria. Nëse e kuptojmë këtë si aftësinë e sistemit për t'u përgjigjur në prani të ndërprerjeve të rrjetit, ndarjeve ose një lloj dështimi, toleranca ndaj gabimeve rritet ndërsa modeli i konsistencës zvogëlohet, pasi na mjafton që një host të jetojë dhe në të njëjtën kohë. koha prodhon disa të dhëna. Konsistenca eventuale nuk garanton asgjë për të dhënat - mund të jetë çdo gjë.
- Anomalitë. Në të njëjtën kohë, natyrisht, numri i anomalive rritet. Në Konsistencën e Fortë ato pothuajse nuk duhet të ekzistojnë fare, por në Konsistencën eventuale ato mund të jenë çdo gjë. Shtrohet pyetja: pse njerëzit zgjedhin Konsistencën eventuale nëse ajo përmban anomali? Përgjigja është se modelet e Konsistencës eventuale janë të zbatueshme dhe anomalitë ekzistojnë, për shembull, në një periudhë të shkurtër kohore; është e mundur të përdoret magjistari për të lexuar dhe pak a shumë të dhëna të qëndrueshme; Shpesh është e mundur të përdoren modele të qëndrueshme të fortë. Në praktikë kjo funksionon, dhe shpesh numri i anomalive është i kufizuar në kohë.
Teorema CAP
Kur shihni fjalët qëndrueshmëri, disponueshmëri - çfarë ju vjen në mendje? Kjo është e drejtë - teorema CAP! Tani dua të shpërndaj mitin... Nuk jam unë - është Martin Kleppmann, i cili shkroi një artikull të mrekullueshëm, një libër të mrekullueshëm.
Teorema CAP është një parim i formuluar në vitet 2000 se Konsistenca, Disponueshmëria, Ndarjet: merrni çdo dy dhe nuk mund të zgjidhni tre. Ishte një parim i caktuar. Ajo u vërtetua si një teoremë disa vite më vonë nga Gilbert dhe Lynch. Pastaj kjo filloi të përdoret si një mantra - sistemet filluan të ndahen në CA, CP, AP dhe kështu me radhë.
Kjo teoremë u vërtetua në të vërtetë për rastet e mëposhtme... Së pari, Disponueshmëria u konsiderua jo si një vlerë e vazhdueshme nga zero në qindra (0 - sistemi është "i vdekur", 100 - përgjigjet shpejt; jemi mësuar ta konsiderojmë kështu) , por si veti e algoritmit , i cili garanton që për të gjitha ekzekutimet e tij të kthejë të dhëna.
Nuk flitet fare për kohën e përgjigjes! Ekziston një algoritëm që kthen të dhënat pas 100 vjetësh - një algoritëm absolutisht i mrekullueshëm i disponueshëm, i cili është pjesë e teoremës CAP.
Së dyti: teorema u vërtetua për ndryshime në vlerat e të njëjtit çelës, pavarësisht nga fakti se këto ndryshime janë të ridimensionueshme. Kjo do të thotë se në realitet ato praktikisht nuk përdoren, sepse modelet janë të ndryshme Konsistenca eventuale, Konsistenca e fortë (ndoshta).
Për çfarë është e gjithë kjo? Për më tepër, teorema CAP pikërisht në formën në të cilën u vërtetua praktikisht nuk është e zbatueshme dhe përdoret rrallë. Në formë teorike, ajo disi kufizon gjithçka. Rezulton një parim i caktuar që është intuitivisht i saktë, por në përgjithësi nuk është provuar.
Konsistenca shkakësore është modeli më i fortë
Ajo që po ndodh tani është se ju mund të merrni të tre gjërat: Konsistenca, Disponueshmëria duke përdorur Ndarjet. Në veçanti, konsistenca shkakësore është modeli më i fortë i qëndrueshmërisë, i cili ende funksionon në prani të ndarjeve (ndërprerjeve në rrjet). Kjo është arsyeja pse ajo ka një interes kaq të madh dhe kjo është arsyeja pse ne e morëm atë.
Së pari, thjeshton punën e zhvilluesve të aplikacioneve. Në veçanti, prania e një mbështetjeje të madhe nga serveri: kur të gjitha regjistrimet që ndodhin brenda një klienti garantohen të arrijnë në të njëjtën sekuencë në një klient tjetër. Së dyti, i reziston ndarjeve.
Kuzhina e brendshme MongoDB
Duke kujtuar se është drekë, shkojmë në kuzhinë. Unë do t'ju tregoj për modelin e sistemit, domethënë, çfarë është MongoDB për ata që po dëgjojnë për herë të parë për një bazë të dhënash të tillë.
MongoDB (në tekstin e mëtejmë "MongoDB") është një sistem i shpërndarë që mbështet shkallëzimin horizontal, domethënë ndarjen; dhe brenda çdo fragmenti ai gjithashtu mbështet tepricën e të dhënave, domethënë replikimin.
Sharding në MongoDB (jo një bazë të dhënash relacionale) kryen balancimin automatik, d.m.th., çdo koleksion dokumentesh (ose "tabelë" për sa i përket të dhënave relacionale) ndahet në copa, dhe serveri i zhvendos ato automatikisht midis copëzave.
Ruteri Query, i cili shpërndan kërkesat, për një klient është një klient përmes të cilit funksionon. Ai tashmë e di se ku dhe cilat të dhëna ndodhen dhe i drejton të gjitha kërkesat në copëzën e duhur.
Një pikë tjetër e rëndësishme: MongoDB është një mjeshtër i vetëm. Ekziston një Primar - mund të marrë regjistrime që mbështesin çelësat që përmban. Nuk mund të bësh shkrimin Multi-master.
Ne bëmë lëshimin 4.2 - gjëra të reja interesante u shfaqën atje. Në veçanti, ata futën Lucene - kërkim - përkatësisht java të ekzekutueshme direkt në Mongo, dhe atje u bë e mundur të kryheshin kërkime përmes Lucene, njësoj si në Elastica.
Dhe ata bënë një produkt të ri - Grafikët, ai është gjithashtu i disponueshëm në Atlas (Cloud i vetë Mongos). Ata kanë një nivel të lirë - ju mund të luani me të. Më pëlqeu shumë Grafikët - vizualizimi i të dhënave, shumë intuitiv.
Përbërësit Konsistenca shkakësore
Kam numëruar rreth 230 artikuj që janë botuar në këtë temë - nga Leslie Lampert. Tani nga kujtesa ime do t'ju përcjell disa pjesë nga këto materiale.
Gjithçka filloi me një artikull të Leslie Lampert, i cili u shkrua në vitet 1970. Siç mund ta shihni, disa kërkime mbi këtë temë janë ende në vazhdim. Tani konsistenca shkakësore po përjeton interes në lidhje me zhvillimin e sistemeve të shpërndara.
Kufizimet
Çfarë kufizimesh ka? Kjo është në fakt një nga pikat kryesore, sepse kufizimet që vendos një sistem prodhimi janë shumë të ndryshme nga kufizimet që ekzistojnë në artikujt akademikë. Shpesh ato janë mjaft artificiale.
- Së pari, "MongoDB" është një mjeshtër i vetëm, siç thashë tashmë (kjo thjeshton shumë).
- Ne besojmë se sistemi duhet të mbështesë rreth 10 mijë copëza. Ne nuk mund të marrim asnjë vendim arkitektonik që do ta kufizojë në mënyrë eksplicite këtë vlerë.
- Ne kemi një re, por supozojmë se një person duhet të ketë ende mundësinë kur shkarkon binare, e drejton atë në laptopin e tij dhe gjithçka funksionon shkëlqyeshëm.
- Ne supozojmë diçka që Research rrallë supozon: klientët e jashtëm mund të bëjnë çfarë të duan. MongoDB është me burim të hapur. Prandaj, klientët mund të jenë kaq të zgjuar dhe të zemëruar - ata mund të duan të thyejnë gjithçka. Ne spekulojmë se Feilors Bizantine mund të kenë origjinën.
- Për klientët e jashtëm që janë jashtë perimetrit, ekziston një kufizim i rëndësishëm: nëse kjo veçori është e çaktivizuar, atëherë nuk duhet të vërehet degradim i performancës.
- Një pikë tjetër është përgjithësisht anti-akademike: pajtueshmëria e versioneve të mëparshme dhe atyre të ardhshme. Drejtuesit e vjetër duhet të mbështesin përditësimet e reja, dhe baza e të dhënave duhet të mbështesë drejtuesit e vjetër.
Në përgjithësi, e gjithë kjo vendos kufizime.
Komponentët e konsistencës shkakësore
Tani do të flas për disa nga komponentët. Nëse marrim parasysh konsistencën shkakësore në përgjithësi, mund të zgjedhim blloqe. Ne zgjodhëm nga veprat që i përkasin një blloku të caktuar: Ndjekja e varësisë, zgjedhja e orëve, si mund të sinkronizohen këto orë me njëra-tjetrën dhe si garantojmë sigurinë - kjo është një përshkrim i përafërt i asaj për të cilën do të flas:
Ndjekja e plotë e varësisë
Pse është e nevojshme? Kështu që kur të dhënat replikohen, çdo rekord, çdo ndryshim i të dhënave përmban informacion se nga cilat ndryshime varet. Ndryshimi i parë dhe naiv është kur çdo mesazh që përmban një rekord përmban informacion për mesazhet e mëparshme:
Në këtë shembull, numri në kllapa kaçurrelë është numrat e rekordeve. Ndonjëherë këto regjistrime me vlera madje transferohen në tërësi, ndonjëherë disa versione transferohen. Në fund të fundit është se çdo ndryshim përmban informacione për atë të mëparshmin (natyrisht që e mbart të gjithë këtë brenda vetes).
Pse vendosëm të mos e përdorim këtë qasje (ndjekja e plotë)? Natyrisht, sepse kjo qasje është jopraktike: çdo ndryshim në një rrjet social varet nga të gjitha ndryshimet e mëparshme në atë rrjet social, duke transferuar, të themi, Facebook ose VKontakte në çdo përditësim. Sidoqoftë, ka shumë kërkime mbi gjurmimin e plotë të varësisë - këto janë rrjete parasociale; për disa situata funksionon vërtet.
Ndjekja e qartë e varësisë
Tjetri është më i kufizuar. Këtu merret parasysh edhe transferimi i informacionit, por vetëm ai që varet qartë. Çfarë varet nga ajo që, si rregull, përcaktohet nga Aplikacioni. Kur të dhënat përsëriten, pyetja kthen përgjigje vetëm kur varësitë e mëparshme janë plotësuar, domethënë janë treguar. Ky është thelbi i mënyrës se si funksionon konsistenca shkakësore.
Ajo sheh që rekordi 5 varet nga regjistrimet 1, 2, 3, 4 - në përputhje me rrethanat, ajo pret përpara se klienti të ketë akses në ndryshimet e bëra nga vendimi i hyrjes së Penny, kur të gjitha ndryshimet e mëparshme kanë kaluar tashmë në bazën e të dhënave.
Kjo nuk na përshtatet as neve, sepse ka ende shumë informacione dhe do të ngadalësojë gjërat. Ka një qasje tjetër ...
Ora Lamport
Ata janë shumë të vjetër. Ora Lamport do të thotë që këto varësi janë palosur në një funksion skalar, i cili quhet Ora Lamport.
Një funksion skalar është një numër abstrakt. Shpesh quhet kohë logjike. Me çdo ngjarje, ky numërues rritet. Counter, i cili aktualisht është i njohur për procesin, dërgon çdo mesazh. Është e qartë se proceset mund të jenë jashtë sinkronizimit, ato mund të kenë kohë krejtësisht të ndryshme. Sidoqoftë, sistemi balancon disi orën me mesazhe të tilla. Çfarë ndodh në këtë rast?
E ndava atë copë të madhe në dy për ta bërë të qartë: Miqtë mund të jetojnë në një nyje, e cila përmban një pjesë të koleksionit, dhe Feed mund të jetojnë në një nyje tjetër, e cila përmban një pjesë të këtij koleksioni. A është e qartë se si mund të dalin nga linja? Fillimi Feed do të thotë: "Replicated", dhe pastaj Friends. Nëse sistemi nuk jep një lloj garancie që Furnizimi nuk do të shfaqet derisa të dorëzohen edhe varësitë e Miqve në koleksionin Friends, atëherë do të kemi pikërisht situatën që përmenda.
Ju shikoni se si rritet logjikisht koha e numërimit në Feed:
Pra, vetia kryesore e kësaj ore Lamport dhe konsistencës shkakësore (shpjeguar përmes orës Lamport) është kjo: nëse kemi Ngjarjet A dhe B, dhe ngjarja B varet nga ngjarja A*, atëherë rrjedh se Koha Logjike e ngjarjes A është më e vogël se Koha Logjike nga Ngjarja B.
* Ndonjëherë ata thonë gjithashtu se A ka ndodhur para B, domethënë A ka ndodhur para B - kjo është një lidhje e caktuar që pjesërisht urdhëron të gjithë grupin e ngjarjeve që ndodhën në përgjithësi.
E kundërta është e gabuar. Ky është në fakt një nga disavantazhet kryesore të Lamport Clock - rendi i pjesshëm. Ekziston një koncept për ngjarje të njëkohshme, domethënë ngjarje në të cilat as (A ka ndodhur para B) dhe as (A ka ndodhur para B). Një shembull do të ishte shtimi paralel i Leonardit i dikujt tjetër si mik (as Leonard, por Sheldon, për shembull).
Kjo është vetia që përdoret shpesh kur punoni me orët Lamport: ata shikojnë në mënyrë specifike funksionin dhe nga kjo arrijnë në përfundimin se ndoshta këto ngjarje janë të varura. Sepse një mënyrë është e vërtetë: nëse Koha Logjike A është më e vogël se Koha Logjike B, atëherë B nuk mund të ndodhë përpara A; dhe nëse më shumë, atëherë ndoshta.
Ora vektoriale
Zhvillimi logjik i orës Lamport është Ora Vektoriale. Ato ndryshojnë në atë që çdo nyje që ndodhet këtu përmban orën e vet të veçantë dhe ato transmetohen si vektor.
Në këtë rast, shihni se indeksi zero i vektorit është përgjegjës për Feed, dhe indeksi i parë i vektorit është për Friends (secila prej këtyre nyjeve). Dhe tani ato do të rriten: indeksi zero i "Feed" rritet kur shkruani - 1, 2, 3:
Pse Ora Vektoriale është më e mirë? Sepse ato ju lejojnë të kuptoni se cilat ngjarje janë të njëkohshme dhe kur ndodhin në nyje të ndryshme. Kjo është shumë e rëndësishme për një sistem sharing si MongoDB. Megjithatë, ne nuk e zgjodhëm këtë, megjithëse është një gjë e mrekullueshme, dhe funksionon shkëlqyeshëm dhe ndoshta do të na përshtatej...
Nëse kemi 10 mijë copëza, nuk mund të transferojmë 10 mijë përbërës, edhe nëse i ngjeshim ose dalim me diçka tjetër - ngarkesa do të jetë akoma disa herë më e vogël se vëllimi i gjithë këtij vektori. Prandaj, duke shtrënguar zemrat dhe dhëmbët, ne e braktisëm këtë qasje dhe kaluam në një tjetër.
Çelësi TrueTime. Ora atomike
Thashë se do të kishte një histori për Spanner. Kjo është një gjë e lezetshme, direkt nga shekulli XNUMX: orë atomike, sinkronizimi GPS.
Cila është ideja? "Spanner" është një sistem i Google që kohët e fundit madje u bë i disponueshëm për njerëzit (ata shtuan SQL në të). Çdo transaksion atje ka një vulë kohore. Meqenëse koha është e sinkronizuar*, çdo ngjarje mund t'i caktohet një kohë specifike - orët atomike kanë një kohë pritjeje, pas së cilës garantohet të "ndodh" një kohë tjetër.
Kështu, thjesht duke shkruar në bazën e të dhënave dhe duke pritur për një periudhë kohe, Serializueshmëria e ngjarjes garantohet automatikisht. Ata kanë modelin më të fortë të Konsistencës që mund të imagjinohet në parim - është Konsistenca e Jashtme.
* Ky është problemi kryesor me orët Lampart - ato nuk janë kurrë sinkron në sistemet e shpërndara. Ata mund të ndryshojnë; edhe me NTP, ato ende nuk funksionojnë shumë mirë. "Spanner" ka një orë atomike dhe sinkronizimi, me sa duket, është mikrosekonda.
Pse nuk zgjodhëm? Ne nuk supozojmë se përdoruesit tanë kanë një orë atomike të integruar. Kur të shfaqen, duke u integruar në çdo laptop, do të ketë një lloj sinkronizimi GPS super të lezetshëm - atëherë po... Por tani për tani më e mira që është e mundur është Amazon, Stacionet Bazë - për fanatikët... Kështu që ne përdorëm orë të tjera .
Orë Hibride
Kjo është në të vërtetë ajo që shënon në MongoDB kur sigurohet konsistenca shkakësore. Si janë hibride? Hibridi është një vlerë skalare, por ka dy komponentë:
- E para është epoka Unix (sa sekonda kanë kaluar që nga "fillimi i botës kompjuterike").
- E dyta është një rritje, gjithashtu një int i panënshkruar 32-bit.
Kjo është e gjitha, në fakt. Ekziston kjo qasje: pjesa që është përgjegjëse për kohën sinkronizohet me orën gjatë gjithë kohës; sa herë që ndodh një përditësim, kjo pjesë sinkronizohet me orën dhe rezulton se ora është gjithmonë pak a shumë e saktë, dhe rritja ju lejon të bëni dallimin midis ngjarjeve që kanë ndodhur në të njëjtën pikë kohore.
Pse është kjo e rëndësishme për MongoDB? Sepse ju lejon të krijoni një lloj restorantesh rezervë në një moment të caktuar kohor, domethënë, ngjarja indeksohet sipas kohës. Kjo është e rëndësishme kur nevojiten ngjarje të caktuara; Për një bazë të dhënash, ngjarjet janë ndryshime në bazën e të dhënave që kanë ndodhur në intervale të caktuara në kohë.
Unë do t'ju tregoj arsyen më të rëndësishme vetëm për ju (ju lutem, mos i tregoni askujt)! Ne e bëmë këtë sepse kështu duken të dhënat e organizuara dhe të indeksuara në MongoDB OpLog. OpLog është një strukturë e të dhënave që përmban absolutisht të gjitha ndryshimet në bazën e të dhënave: ato fillimisht shkojnë në OpLog, dhe më pas ato aplikohen në vetë Storage në rastin kur është një datë ose copëza e përsëritur.
Kjo ishte arsyeja kryesore. Megjithatë, ka edhe kërkesa praktike për zhvillimin e një baze të dhënash, që do të thotë se ajo duhet të jetë e thjeshtë - pak kod, sa më pak gjëra të prishura që të jetë e mundur që duhet të rishkruhen dhe testohen. Fakti që oplogët tanë u indeksuan nga orët hibride na ndihmoi shumë dhe na lejoi të bënim zgjedhjen e duhur. Me të vërtetë u shpagua dhe funksionoi në mënyrë magjike në prototipin e parë. Ishte shumë e lezetshme!
Sinkronizimi i orës
Ekzistojnë disa metoda sinkronizimi të përshkruara në literaturën shkencore. E kam fjalën për sinkronizimin kur kemi dy copëza të ndryshme. Nëse ka një grup kopjesh, nuk ka nevojë për ndonjë sinkronizim: ky është një "mjeshtër i vetëm"; ne kemi një OpLog, në të cilin bien të gjitha ndryshimet - në këtë rast, gjithçka tashmë është renditur në mënyrë sekuenciale në vetë "Oplog". Por nëse kemi dy copëza të ndryshme, sinkronizimi i kohës është i rëndësishëm këtu. Këtu ndihmoi më shumë ora vektoriale! Por ne nuk i kemi ato.
E dyta është e përshtatshme - kjo është "Rrahjet e Zemrës". Është e mundur të shkëmbehen disa sinjale që ndodhin çdo njësi të kohës. Por rrahjet e zemrës janë shumë të ngadalta, ne nuk mund t'i ofrojmë latente klientit tonë.
Koha e vërtetë është, sigurisht, një gjë e mrekullueshme. Por, përsëri, kjo është ndoshta e ardhmja... Edhe pse tashmë mund të bëhet në Atlas, tashmë ka sinkronizues të shpejtë të kohës “Amazon”. Por nuk do të jetë i disponueshëm për të gjithë.
Thashethemet janë kur të gjitha mesazhet përfshijnë kohën. Kjo është përafërsisht ajo që ne përdorim. Çdo mesazh midis nyjeve, një drejtues, një ruter i nyjeve të të dhënave, absolutisht gjithçka për MongoDB është një lloj elementi, një komponent i bazës së të dhënave që përmban një orë që funksionon. Kudo kanë kuptimin e kohës hibride, transmetohet. 64 bit? Kjo lejon, kjo është e mundur.
Si funksionojnë të gjitha së bashku?
Këtu po shikoj një grup kopjesh për ta bërë pak më të lehtë. Ka fillore dhe sekondare. Sekondari bën replikim dhe nuk sinkronizohet gjithmonë plotësisht me Primar.
Ndodh një futje në "Primery" me një vlerë të caktuar kohore. Kjo futje rrit numrin e brendshëm me 11, nëse kjo është maksimumi. Ose do të kontrollojë vlerat e orës dhe do të sinkronizohet me orën nëse vlerat e orës janë më të mëdha. Kjo ju lejon të organizoni sipas kohës.
Pasi bën regjistrimin, ndodh një moment i rëndësishëm. Ora është në "MongoDB" dhe rritet vetëm në rast të shkrimit në "Oplog". Kjo është ngjarja që ndryshon gjendjen e sistemit. Absolutisht në të gjithë artikujt klasik, një ngjarje konsiderohet të jetë kur një mesazh godet një nyje: mesazhi ka mbërritur, që do të thotë se sistemi ka ndryshuar gjendjen e tij.
Kjo për faktin se gjatë hulumtimit nuk është plotësisht e qartë se si do të interpretohet ky mesazh. Ne e dimë me siguri se nëse nuk pasqyrohet në "Oplog", atëherë nuk do të interpretohet në asnjë mënyrë, dhe një ndryshim në gjendjen e sistemit është vetëm një hyrje në "Oplog". Kjo thjeshton gjithçka për ne: modeli e thjeshton atë dhe na lejon ta organizojmë atë brenda një grupi kopjesh dhe shumë gjëra të tjera të dobishme.
Vlera që është shkruar tashmë në "Oplog" kthehet - ne e dimë që "Oplog" tashmë e përmban këtë vlerë dhe koha e tij është 12. Tani, le të themi, leximi fillon nga një nyje tjetër (Secondary), dhe transmeton pasClusterTime në Mesazhi. Ai thotë: “Kam nevojë për gjithçka që ka ndodhur të paktën pas orës 12 ose gjatë dymbëdhjetëve” (shih figurën më lart).
Kjo është ajo që quhet Causal a Consistent (CAT). Ekziston një koncept i tillë në teori që kjo është një pjesë e kohës, e cila është e qëndrueshme në vetvete. Në këtë rast, mund të themi se kjo është gjendja e sistemit që u vu re në kohën 12.
Tani nuk ka asgjë këtu, sepse kjo lloj simulon situatën kur ju nevojitet Sekondari për të replikuar të dhënat nga Primar. Ai pret... Dhe tani të dhënat kanë ardhur - ai i kthen këto vlera.
Kështu funksionon e gjitha. Pothuajse.
Çfarë do të thotë "pothuajse"? Le të supozojmë se ka një person që ka lexuar dhe kuptuar se si funksionon e gjithë kjo. Kuptova se sa herë që ndodh ClusterTime, ai përditëson orën e brendshme logjike dhe më pas hyrja tjetër rritet me një. Ky funksion merr 20 rreshta. Le të themi se ky person transmeton numrin më të madh 64-bit, minus një.
Pse "minus një"? Për shkak se ora e brendshme do të zëvendësohet në këtë vlerë (natyrisht, kjo është më e madhja e mundshme dhe më e madhe se koha aktuale), atëherë do të ndodhë një hyrje në "Oplog" dhe ora do të rritet me një njësi tjetër - dhe tashmë do të të jetë një vlerë maksimale (thjesht janë të gjitha njësitë, nuk ka ku të shkosh tjetër) , ints unsaint).
Është e qartë se pas kësaj sistemi bëhet absolutisht i paarritshëm për asgjë. Mund të shkarkohet dhe pastrohet vetëm - shumë punë manuale. Disponueshmëria e plotë:
Për më tepër, nëse kjo përsëritet diku tjetër, atëherë i gjithë grupi thjesht bie poshtë. Një situatë absolutisht e papranueshme që çdokush mund ta organizojë shumë shpejt dhe lehtë! Prandaj, ne e konsideruam këtë moment si një nga më të rëndësishmit. Si ta parandaloni atë?
Mënyra jonë është të nënshkruajmë clusterTime
Kështu transmetohet në mesazh (para tekstit blu). Por ne gjithashtu filluam të gjeneronim një nënshkrim (tekst blu):
Nënshkrimi gjenerohet nga një çelës që ruhet brenda bazës së të dhënave, brenda një perimetri të sigurt; vetë gjenerohet dhe përditësohet (përdoruesit nuk shohin asgjë në lidhje me të). Krijohet një hash dhe çdo mesazh nënshkruhet kur krijohet dhe vërtetohet kur merret.
Ndoshta lind pyetja në mendjet e njerëzve: "Sa i ngadalëson kjo gjë gjërat?" Ju thashë që duhet të funksionojë shpejt, veçanërisht në mungesë të kësaj veçorie.
Çfarë do të thotë përdorimi i konsistencës shkakësore në këtë rast? Kjo është për të treguar parametrin afterClusterTime. Pa këtë, ai thjesht do të kalojë vlera gjithsesi. Thashethemet, duke filluar nga versioni 3.6, funksionojnë gjithmonë.
Nëse e lëmë gjenerimin e vazhdueshëm të nënshkrimeve, ai do të ngadalësojë sistemin edhe në mungesë të një veçorie, e cila nuk i plotëson qasjet dhe kërkesat tona. Pra, çfarë bëmë?
Bëje shpejt!
Është një gjë mjaft e thjeshtë, por truku është interesant - do ta ndaj, ndoshta dikush do të jetë i interesuar.
Ne kemi një hash që ruan të dhënat e nënshkruara. Të gjitha të dhënat kalojnë nëpër cache. Memoria e fshehtë nuk nënshkruan kohën specifike, por Gama. Kur arrin një vlerë, ne gjenerojmë një Range, maskojmë 16 bitet e fundit dhe nënshkruajmë këtë vlerë:
Duke marrë një nënshkrim të tillë, ne shpejtojmë sistemin (relativisht) 65 mijë herë. Funksionon shkëlqyeshëm: kur kryenim eksperimente, koha në fakt u ul me 10 mijë herë kur kishim një përditësim vijues. Është e qartë se kur ata janë në mosmarrëveshje, kjo nuk funksionon. Por në shumicën e rasteve praktike funksionon. Kombinimi i nënshkrimit Range së bashku me nënshkrimin zgjidhën problemin e sigurisë.
Çfarë kemi mësuar?
Mësimet që kemi nxjerrë nga kjo:
- Duhet të lexojmë materiale, tregime, artikuj, sepse kemi shumë gjëra interesante. Kur punojmë në ndonjë veçori (sidomos tani, kur kemi bërë transaksione, etj.), Ne duhet të lexojmë dhe kuptojmë. Duhet kohë, por në fakt është shumë e dobishme sepse e bën të qartë se ku jemi. Nuk dukej se dolëm me ndonjë gjë të re - thjesht morëm përbërësit.
Në përgjithësi, ka një ndryshim të caktuar në të menduarit kur ka një konferencë akademike (Sigmon, për shembull) - të gjithë përqendrohen në ide të reja. Çfarë ka të re në lidhje me algoritmin tonë? Këtu nuk ka ndonjë risi të veçantë. Risia më tepër qëndron në mënyrën se si kemi përzier së bashku qasjet ekzistuese. Prandaj, gjëja e parë është të lexoni klasikët, duke filluar me Lampart.
- Në prodhim, kërkesat janë krejtësisht të ndryshme. Jam i sigurt se shumë prej jush nuk janë përballur me baza të dhënash "sferike" në një vakum abstrakt, por me gjëra normale, reale që kanë probleme me disponueshmërinë, vonesën dhe tolerancën e gabimeve.
- Gjëja e fundit është se ne duhej të shikonim ide të ndryshme dhe të kombinonim disa artikuj krejtësisht të ndryshëm në një qasje, së bashku. Ideja për nënshkrimin, për shembull, në përgjithësi erdhi nga një artikull që merrte në konsideratë protokollin e Paxos, i cili për Failorët jobizantinë është brenda protokollit të autorizimit, për ata bizantinë - jashtë protokollit të autorizimit... Në përgjithësi, kjo është pikërisht ajo që ne. përfundoi duke bërë.
Nuk ka absolutisht asgjë të re këtu! Por sapo i përziejmë të gjitha bashkë... Është njësoj sikur të thuash që receta e sallatës Olivier është e pakuptimtë, sepse vezët, majoneza dhe kastravecat tashmë janë shpikur... Bëhet fjalë për të njëjtën histori.
Do të përfundoj me këtë. Faleminderit!
Pyetjet tuaja
Pyetje nga auditori (më tej referuar si B): – Faleminderit, Mikhail, për raportin! Tema për kohën është interesante. Ju jeni duke përdorur Thashethemet. Ata thanë se secili ka kohën e vet, të gjithë e dinë kohën e tyre lokale. Siç e kuptoj unë, ne kemi një shofer - mund të ketë shumë klientë me drejtues, gjithashtu planifikues pyetjesh, edhe copëza... Dhe në çfarë do të vijë sistemi nëse papritur kemi një mospërputhje: dikush vendos që është për një minutë përpara, dikush një minutë pas? Ku do të përfundojmë?
MT: – Vërtet pyetje e madhe! Doja të flisja vetëm për copëzat. Nëse e kuptoj saktë pyetjen, kemi situatën e mëposhtme: ka copëzën 1 dhe copëzën 2, leximi ndodh nga këto dy copëza - ato kanë një mospërputhje, nuk ndërveprojnë me njëra-tjetrën, sepse koha që ata dinë është e ndryshme, sidomos koha kur ato ekzistojnë në oplog.
Le të themi se copëza 1 bëri një milion regjistrime, copëza 2 nuk bëri asgjë fare dhe kërkesa arriti në dy copëza. Dhe i pari ka një afterClusterTime prej mbi një milion. Në një situatë të tillë, siç e shpjegova, copëza 2 nuk do të përgjigjet kurrë fare.
NË: – Doja të dija se si sinkronizohen dhe zgjedhin një kohë logjike?
MT: - Shumë e lehtë për t'u sinkronizuar. Shard, kur i vjen afterClusterTime dhe ai nuk gjen kohë në "Oplog", fillon asnjë miratim. Kjo do të thotë, ai e ngre kohën e tij me duart e tij në këtë vlerë. Kjo do të thotë se nuk ka ngjarje që përputhen me këtë kërkesë. Ai e krijon këtë ngjarje artificialisht dhe kështu bëhet Kauzal Konsistent.
NË: – Po sikur pas kësaj t’i vijnë disa ngjarje të tjera që kanë humbur diku në rrjet?
MT: – Shard është projektuar në atë mënyrë që të mos vijnë më, pasi është një mjeshtër i vetëm. Nëse ai tashmë është regjistruar, atëherë ata nuk do të vijnë, por do të vijnë më vonë. Nuk mund të ndodhë që diçka të ngecë diku, pastaj ai të mos shkruajë, dhe më pas të vijnë këto ngjarje - dhe konsistenca Kauzale të prishet. Kur ai nuk shkruan, duhet të vijnë të gjithë më pas (ai do t'i presë).
NË: – Kam disa pyetje në lidhje me radhët. Konsistenca shkakësore supozon se ekziston një radhë specifike veprimesh që duhet të kryhen. Çfarë ndodh nëse një nga paketat tona zhduket? Këtu vjen data 10, 11... e 12-ta është zhdukur dhe të gjithë presin që të realizohet. Dhe befas makina jonë vdiq, ne nuk mund të bëjmë asgjë. A ka një gjatësi maksimale të radhës që grumbullohet përpara se të ekzekutohet? Çfarë dështimi fatal ndodh kur humbet ndonjë gjendje? Për më tepër, nëse shkruajmë se ekziston një gjendje e mëparshme, atëherë duhet të fillojmë disi prej saj? Por ata nuk e larguan atë!
MT: – Gjithashtu një pyetje e mrekullueshme! Cfare po bejme? MongoDB ka konceptin e kuorumit shkruan, kuorum lexon. Në cilat raste mund të humbasë një mesazh? Kur një shkrim nuk është kuorum ose kur një lexim nuk është kuorum (mund të ngjitet edhe një lloj mbeturinash).
Për sa i përket konsistencës shkakësore, u krye një test i madh eksperimental, rezultati i të cilit ishte se në rastin kur shkrimet dhe leximet nuk janë kuorum, ndodhin shkelje të konsistencës Kauzale. Pikërisht ajo që thua!
Këshilla jonë: përdorni të paktën leximin e kuorumit kur përdorni konsistencën shkakësore. Në këtë rast, asgjë nuk do të humbasë, edhe nëse rekordi i kuorumit humbet... Kjo është një situatë ortogonale: nëse përdoruesi nuk dëshiron që të dhënat të humbasin, ai duhet të përdorë një rekord kuorum. Konsistenca shkakësore nuk garanton qëndrueshmëri. Qëndrueshmëria garantohet nga përsëritja dhe makineria e lidhur me riprodhimin.
NË: – Kur krijojmë një shembull që kryen sharding për ne (përkatësisht jo master, por skllav), ai mbështetet në kohën Unix të makinës së vet ose në kohën e "master"; A sinkronizohet për herë të parë apo periodikisht?
MT: – Do ta sqaroj tani. Shard (d.m.th. ndarje horizontale) - ka gjithmonë një Primar atje. Dhe një copëz mund të ketë një "mjeshtër" dhe mund të ketë kopje. Por copëza gjithmonë mbështet regjistrimin, sepse duhet të mbështesë disa domene (sharda ka Primar).
NË: – Pra, gjithçka varet thjesht nga “mjeshtri”? A përdoret gjithmonë koha master?
MT: - Po. Mund të thuash në mënyrë figurative: ora po troket kur ndodh një hyrje në "master", në "Oplog".
NË: – Kemi një klient që lidhet dhe nuk ka nevojë të dijë asgjë për kohën?
MT: – Nuk ke nevojë të dish asgjë! Nëse flasim për mënyrën se si funksionon tek klienti: kur klienti dëshiron të përdorë konsistencën shkakësore, ai duhet të hapë një seancë. Tani gjithçka është aty: transaksionet në sesion dhe rikthimi i të drejtave... Një seancë është renditja e ngjarjeve logjike që ndodhin me klientin.
Nëse ai hap këtë sesion dhe thotë atje se ai dëshiron konsistencën shkakësore (nëse sesioni mbështet konsistencën shkakësore si parazgjedhje), gjithçka funksionon automatikisht. Shoferi e kujton këtë kohë dhe e rrit atë kur merr një mesazh të ri. Ai kujton se çfarë përgjigje ktheu i mëparshmi nga serveri që ktheu të dhënat. Kërkesa tjetër do të përmbajë afterCluster ("kohë më e madhe se kjo").
Klienti nuk ka nevojë të dijë absolutisht asgjë! Kjo është krejtësisht e errët për të. Nëse njerëzit përdorin këto veçori, çfarë mund të bëjnë? Së pari, mund të lexoni me siguri sekondat: mund të shkruani në Primary dhe të lexoni nga sekondarë të përsëritur gjeografikisht dhe të jeni të sigurt që funksionon. Në të njëjtën kohë, seancat që janë regjistruar në Primar mund të transferohen edhe në Sekondar, d.m.th. ju mund të përdorni jo një sesion, por disa.
NË: – Një shtresë e re e shkencës kompjuterike – llojet e të dhënave CRDT (Llojet e të dhënave të përsëritura pa konflikt) – lidhet fort me temën e konsistencës eventuale. A keni menduar të integroni këto lloj të dhënash në bazën e të dhënave dhe çfarë mund të thoni për të?
MT: - Pyetje e mirë! CRDT ka kuptim për konfliktet e shkrimit: në MongoDB, master i vetëm.
NË: – Kam një pyetje nga devops. Në botën reale, ka situata të tilla jezuite kur ndodh Dështimi Bizantin, dhe njerëzit e këqij brenda perimetrit të mbrojtur fillojnë të futen në protokoll, të dërgojnë pako artizanale në një mënyrë të veçantë?
MT: – Njerëzit e këqij brenda perimetrit janë si kali i Trojës! Njerëzit e këqij brenda perimetrit mund të bëjnë shumë gjëra të këqija.
NË: – Është e qartë se lënia, thënë përafërsisht, një vrimë në server përmes së cilës mund të vendosësh një kopsht zoologjik elefantësh dhe të shembet përgjithmonë gjithë grupi... Do të duhet kohë për rikuperim manual... Kjo, për ta thënë butë, është gabim. Nga ana tjetër, kjo është interesante: në jetën reale, në praktikë, ka situata kur ndodhin sulme të brendshme natyrisht të ngjashme?
MT: – Meqenëse rrallë has në shkelje të sigurisë në jetën reale, nuk mund të them nëse ato ndodhin. Por nëse flasim për filozofinë e zhvillimit, mendojmë kështu: kemi një perimetër që u siguron djemve që bëjnë siguri - kjo është një kështjellë, një mur; dhe brenda perimetrit mund të bëni çfarë të doni. Është e qartë se ka përdorues me aftësinë për të parë vetëm, dhe ka përdorues me aftësinë për të fshirë drejtorinë.
Në varësi të të drejtave, dëmi që përdoruesit mund të bëjnë mund të jetë një mi, ose mund të jetë një elefant. Është e qartë se një përdorues me të drejta të plota mund të bëjë gjithçka fare. Një përdorues me të drejta të kufizuara mund të shkaktojë dukshëm më pak dëm. Në veçanti, nuk mund të prishë sistemin.
NË: – Në perimetrin e mbrojtur, dikush u përpoq të krijonte protokolle të papritura për serverin në mënyrë që të shkatërronte plotësisht serverin, dhe nëse jeni me fat, i gjithë grupi... A e merr ndonjëherë atë "mirë"?
MT: "Nuk kam dëgjuar kurrë për gjëra të tilla." Fakti që ju mund të prishni një server në këtë mënyrë nuk është sekret. Dështo brenda, të jesh nga protokolli, të jesh përdorues i autorizuar që mund të shkruaj diçka të tillë në mesazh... Në fakt, është e pamundur, sepse do të verifikohet akoma. Është e mundur të çaktivizohet ky vërtetim për përdoruesit që nuk e dëshirojnë atë - atëherë ky është problemi i tyre; ata, përafërsisht, i shkatërruan vetë muret dhe mund të futësh një elefant, i cili do të shkelë... Por në përgjithësi, mund të vishesh si riparues, hajde ta nxjerrësh!
NË: – Faleminderit për raportin. Sergej (Yandex). Ekziston një konstante në Mong që kufizon numrin e anëtarëve me votim në grupin e kopjeve, dhe kjo konstante është 7 (shtatë). Pse është kjo një konstante? Pse nuk është ky një lloj parametri?
MT: – Kemi Komplete Replica me 40 nyje. Ka gjithmonë një shumicë. Nuk e di cili version...
NË: – Në Replica Set mund të kandidoni anëtarë që nuk votojnë, por ka maksimumi 7 anëtarë me të drejtë vote. Si mund t'i mbijetojmë mbylljes në këtë rast nëse Seti ynë Replica është i shpërndarë në 3 qendra të dhënash? Një qendër e të dhënave mund të fiket lehtësisht dhe një makinë tjetër mund të bjerë jashtë.
MT: – Kjo tashmë është pak përtej qëllimit të raportit. Kjo është një pyetje e përgjithshme. Ndoshta mund t'ju tregoj për këtë më vonë.
Disa reklama 🙂
Faleminderit që qëndruat me ne. A ju pëlqejnë artikujt tanë? Dëshironi të shihni përmbajtje më interesante? Na mbështesni duke bërë një porosi ose duke rekomanduar miqve, , një analog unik i serverëve të nivelit të hyrjes, i cili u shpik nga ne për ju: (e disponueshme me RAID1 dhe RAID10, deri në 24 bërthama dhe deri në 40 GB DDR4).
Dell R730xd 2 herë më lirë në qendrën e të dhënave Equinix Tier IV në Amsterdam? Vetëm këtu në Holandë! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - nga 99 dollarë! Lexoni rreth
Burimi: www.habr.com