Kita HighLoad++ konferencija vyks 6 metų balandžio 7 ir 2020 dienomis Sankt Peterburge.
Išsami informacija ir bilietai . HighLoad++ Sibiras 2019. Salė "Krasnojarskas". Birželio 25 d., 12 val. Tezės ir .
Pasitaiko, kad praktiniai reikalavimai kertasi su teorija, kai neatsižvelgiama į komerciniam produktui svarbius aspektus. Šiame pokalbyje pristatomas skirtingų požiūrių, kaip sukurti priežastinio nuoseklumo komponentus, atrankos ir derinimo procesas, pagrįstas akademiniais tyrimais, pagrįstais komercinio produkto reikalavimais. Klausytojai sužinos apie esamus teorinius požiūrius į loginius laikrodžius, priklausomybės sekimą, sistemos saugumą, laikrodžio sinchronizavimą ir kodėl MongoDB pasirinko tam tikrus sprendimus.
Michailas Tyulenevas (toliau – MT): – Kalbėsiu apie priežastinį nuoseklumą – tai funkcija, su kuria dirbome MongoDB. Dirbu paskirstytų sistemų grupėje, tai darėme maždaug prieš dvejus metus.
Proceso metu turėjau susipažinti su daugybe akademinių tyrimų, nes ši savybė buvo gana gerai ištirta. Paaiškėjo, kad ne vienas gaminys netelpa į tai, ko reikalaujama gamybos duomenų bazėje dėl labai specifinių reikalavimų, kurie tikriausiai yra bet kurioje gamybos programoje.
Kalbėsiu apie tai, kaip mes, akademinių tyrimų vartotojai, iš jo ruošiame ką nors, ką vėliau galime pateikti savo vartotojams kaip paruoštą patiekalą, kurį patogu ir saugu naudoti.
Priežastinis nuoseklumas. Apibrėžkime sąvokas
Pirmiausia noriu bendrais bruožais pasakyti, kas yra priežastinis nuoseklumas. Yra du personažai – Leonardas ir Penny (TV serialas „Didžiojo sprogimo teorija“):
Tarkime, Penny yra Europoje ir Leonardas nori surengti jai staigmeną. Ir jis neįsivaizduoja nieko geresnio, kaip išmesti ją iš savo draugų sąrašo ir išsiųsti visiems draugams naujienas apie kanalą: „Padarykim Penny laimingą! (ji yra Europoje, kol miega, viso šito nemato ir nemato, nes jos ten nėra). Galiausiai ji ištrina šį įrašą, ištrina jį iš kanalo ir atkuria prieigą, kad nieko nepastebėtų ir nekiltų skandalas.
Viskas gerai, bet tarkime, kad sistema yra paskirstyta ir viskas įvyko šiek tiek blogai. Pavyzdžiui, gali atsitikti taip, kad Penny prieigos apribojimas įvyko po šio įrašo pasirodymo, jei įvykiai nėra susiję su priežastimi ir pasekmėmis. Tiesą sakant, tai yra pavyzdys, kai norint atlikti verslo funkciją (šiuo atveju) reikalingas priežastinis nuoseklumas.
Tiesą sakant, tai yra gana nereikšmingos duomenų bazės savybės – labai mažai žmonių jas palaiko. Pereikime prie modelių.
Nuoseklumo modeliai
Kas tiksliai yra nuoseklumo modelis duomenų bazėse? Tai yra keletas garantijų, kurias paskirstyta sistema suteikia apie tai, kokius duomenis klientas gali gauti ir kokia seka.
Iš esmės visi nuoseklumo modeliai priklauso nuo to, kaip paskirstyta sistema yra panaši į sistemą, kuri veikia, pavyzdžiui, viename nešiojamojo kompiuterio mazge. Štai kaip sistema, veikianti tūkstančiais geografiškai paskirstytų „mazgų“, yra panaši į nešiojamąjį kompiuterį, kuriame visos šios savybės iš esmės atliekamos automatiškai.
Todėl nuoseklumo modeliai taikomi tik paskirstytoms sistemoms. Visos sistemos, kurios anksčiau egzistavo ir veikė tuo pačiu vertikaliu masteliu, tokių problemų nepatyrė. Buvo viena buferinė talpykla, ir viskas visada buvo skaitoma iš jos.
Modelis Stiprus
Tiesą sakant, pats pirmasis modelis yra „Strong“ (arba „pakilimo gebėjimų linija“, kaip dažnai vadinama). Tai nuoseklumo modelis, užtikrinantis, kad kiekvienas pakeitimas, patvirtinus, kad jis įvyko, yra matomas visiems sistemos vartotojams.
Taip sukuriama visuotinė visų duomenų bazės įvykių tvarka. Tai labai stipri nuoseklumo savybė ir paprastai yra labai brangi. Tačiau tai labai gerai palaikoma. Jis tiesiog labai brangus ir lėtas – tiesiog retai naudojamas. Tai vadinama gebėjimu kilti.
Yra ir kita, stipresnė savybė, kurią palaiko veržliaraktis, vadinama išorine nuoseklumu. Apie tai pakalbėsime šiek tiek vėliau.
Priežastinis
Kitas yra priežastinis ryšys, apie kurį aš kalbėjau. Tarp stipraus ir priežastinio ryšio yra dar keli polygiai, apie kuriuos nekalbėsiu, bet jie visi susiveda į priežastinį ryšį. Tai svarbus modelis, nes jis yra stipriausias iš visų modelių, stipriausias nuoseklumas esant tinklui ar pertvaroms.
Priežastys iš tikrųjų yra situacija, kai įvykius sieja priežasties ir pasekmės ryšys. Labai dažnai jie suvokiami kaip „Perskaitykite savo teises“ kliento požiūriu. Jei klientas pastebėjo tam tikras vertybes, jis negali matyti vertybių, kurios buvo praeityje. Jis jau pradeda matyti priešdėlio rodmenis. Viskas susiveda į tą patį.
Priežastys kaip nuoseklumo modelis – tai dalinis įvykių išdėstymas serveryje, kai įvykiai iš visų klientų stebimi ta pačia seka. Šiuo atveju Leonardas ir Penny.
Galiausiai
Trečiasis modelis yra galutinis nuoseklumas. Tai palaiko absoliučiai visos paskirstytos sistemos, minimalus modelis, kuris apskritai yra prasmingas. Tai reiškia štai ką: kai turime tam tikrų duomenų pasikeitimų, tam tikru momentu jie tampa nuoseklūs.
Tokiu momentu ji nieko nesako, kitaip ji virstų Išoriniu nuoseklumu – būtų visai kita istorija. Nepaisant to, tai labai populiarus modelis, labiausiai paplitęs. Pagal numatytuosius nustatymus visi paskirstytų sistemų vartotojai naudoja galutinį suderinamumą.
Noriu pateikti keletą lyginamųjų pavyzdžių:
Ką reiškia šios rodyklės?
- Latencija. Didėjant nuoseklumo stiprumui, jis tampa didesnis dėl akivaizdžių priežasčių: reikia padaryti daugiau įrašų, gauti patvirtinimą iš visų klasteryje dalyvaujančių kompiuterių ir mazgų, kad duomenys jau yra. Atitinkamai „Galutinis nuoseklumas“ turi greičiausią atsakymą, nes ten, kaip taisyklė, netgi galite jį įrašyti į atmintį ir to iš esmės pakaks.
- Prieinamumas. Jei tai suprantame kaip sistemos gebėjimą reaguoti esant tinklo pertrūkiams, skaidiniams ar tam tikram gedimui, gedimų tolerancija didėja mažėjant nuoseklumo modeliui, nes mums pakanka, kad gyvena vienas pagrindinis kompiuteris. laikas sukuria tam tikrus duomenis. Galutinis nuoseklumas negarantuoja nieko apie duomenis – tai gali būti bet kas.
- Anomalijos. Kartu, žinoma, daugėja anomalijų. Stiprioje konsistencijoje jų beveik neturėtų išvis egzistuoti, tačiau galutinėje nuoseklumoje jie gali būti bet kokie. Kyla klausimas: kodėl žmonės renkasi Galutinį nuoseklumą, jei jame yra anomalijų? Atsakymas yra toks, kad galimo nuoseklumo modeliai yra taikomi, o anomalijos egzistuoja, pavyzdžiui, per trumpą laiką; galima naudoti vedlį skaityti ir daugiau ar mažiau nuskaityti nuoseklius duomenis; Dažnai galima naudoti stiprios konsistencijos modelius. Praktiškai tai veikia, ir dažnai anomalijų skaičius yra ribotas.
BŽŪP teorema
Kai matai žodžius nuoseklumas, prieinamumas – kas ateina į galvą? Teisingai – BŽŪP teorema! Dabar noriu išsklaidyti mitą... Tai ne aš – tai Martinas Kleppmannas, kuris parašė nuostabų straipsnį, nuostabią knygą.
BŽŪP teorema yra 2000-aisiais suformuluotas principas, kad nuoseklumas, prieinamumas, skaidiniai: imkite bet kokius du, o jūs negalite pasirinkti trijų. Tai buvo tam tikras principas. Po kelerių metų Gilbertas ir Lynchas tai įrodė kaip teoremą. Tada tai buvo pradėta naudoti kaip mantra – sistemos pradėtos skirstyti į CA, CP, AP ir pan.
Ši teorema iš tikrųjų buvo įrodyta šiais atvejais... Pirma, Prieinamumas buvo laikomas ne nuolatine verte nuo nulio iki šimtų (0 - sistema "negyva", 100 - greitai reaguoja; mes įpratę tai laikyti taip) , bet kaip algoritmo savybę, kuri garantuoja, kad visoms jo vykdymoms jis grąžins duomenis.
Apie reakcijos laiką nėra nė žodžio! Yra algoritmas, kuris grąžina duomenis po 100 metų – absoliučiai puikus prieinamas algoritmas, kuris yra BŽŪP teoremos dalis.
Antra: teorema buvo įrodyta dėl to paties rakto reikšmių pokyčių, nepaisant to, kad šiuos pakeitimus galima keisti. Tai reiškia, kad realiai jie praktiškai nenaudojami, nes modeliai skiriasi Galutinė konsistencija, Stipri konsistencija (galbūt).
Kam visa tai? Be to, BŽŪP teorema tiksliai tokia forma, kokia ji buvo įrodyta, praktiškai netaikoma ir naudojama retai. Teorine forma tai kažkaip viską apriboja. Pasirodo, tam tikras principas yra intuityviai teisingas, bet apskritai neįrodytas.
Priežastinis nuoseklumas yra stipriausias modelis
Tai, kas dabar vyksta, yra tai, kad galite gauti visus tris dalykus: nuoseklumą, prieinamumą naudodami skaidinius. Visų pirma, priežastinis nuoseklumas yra stipriausias nuoseklumo modelis, kuris vis dar veikia esant skaidiniams (tinklo pertraukoms). Štai kodėl tai labai domina, todėl mes jo ėmėmės.
Pirma, tai supaprastina programų kūrėjų darbą. Visų pirma, puikus serverio palaikymas: kai visi įrašai, esantys viename kliente, garantuojama, kad kitame kliente pateks ta pačia seka. Antra, jis atlaiko pertvaras.
MongoDB vidinė virtuvė
Prisiminę, kad pietūs, judame į virtuvę. Papasakosiu apie sistemos modelį, būtent, kas yra MongoDB tiems, kurie apie tokią duomenų bazę girdi pirmą kartą.
„MongoDB“ (toliau – „MongoDB“) yra paskirstyta sistema, palaikanti horizontalųjį mastelio keitimą, ty skilimą; ir kiekvienoje skiltyje jis taip pat palaiko duomenų perteklių, ty replikaciją.
Dalijimasis MongoDB (ne reliacinėje duomenų bazėje) atlieka automatinį balansavimą, tai yra, kiekvienas dokumentų rinkinys (arba „lentelė“ pagal reliacinius duomenis) yra padalintas į dalis, o serveris automatiškai perkelia juos tarp skeveldrų.
Užklausų maršrutizatorius, platinantis užklausas klientui, yra tam tikras klientas, per kurį jis veikia. Ji jau žino, kur ir kokie duomenys yra, ir nukreipia visas užklausas į tinkamą skeveldrą.
Kitas svarbus dalykas: MongoDB yra vienas meistras. Yra vienas pagrindinis – jis gali paimti įrašus, palaikančius jame esančius raktus. Negalite rašyti kelių pagrindų.
Sukūrėme 4.2 leidimą – ten atsirado naujų įdomių dalykų. Visų pirma, jie įterpė „Lucene“ – paiešką – būtent vykdomąją „Java“ programą tiesiai į „Mongo“, ir ten tapo įmanoma atlikti paieškas per „Lucene“, kaip ir „Elastica“.
Ir jie sukūrė naują produktą - Charts, jį taip pat galima rasti Atlas (paties Mongo debesyje). Jie turi laisvą pakopą – galite su ja žaisti. Labai patiko Charts – duomenų vizualizacija, labai intuityvi.
Ingredientai Priežastinis nuoseklumas
Suskaičiavau apie 230 straipsnių, kurie buvo paskelbti šia tema – iš Leslie Lampert. Dabar iš savo atminties perteiksiu jums kai kurias šių medžiagų dalis.
Viskas prasidėjo nuo Leslie Lampert straipsnio, kuris buvo parašytas aštuntajame dešimtmetyje. Kaip matote, kai kurie tyrimai šia tema vis dar vyksta. Dabar priežastinis nuoseklumas susidomi paskirstytų sistemų kūrimu.
Apribojimai
Kokie yra apribojimai? Tai iš tikrųjų yra vienas iš pagrindinių dalykų, nes apribojimai, kuriuos nustato gamybos sistema, labai skiriasi nuo apribojimų, esančių akademiniuose straipsniuose. Jie dažnai yra gana dirbtiniai.
- Pirma, „MongoDB“ yra vienas meistras, kaip jau sakiau (tai labai supaprastina).
- Manome, kad sistema turėtų palaikyti apie 10 tūkst. Negalime priimti jokių architektūrinių sprendimų, kurie aiškiai apribotų šią vertę.
- Mes turime debesį, bet manome, kad žmogus vis tiek turėtų turėti galimybę, kai atsisiunčia dvejetainį failą, paleidžia jį nešiojamajame kompiuteryje ir viskas veikia puikiai.
- Mes darome prielaidą, ką „Research“ daro retai: išoriniai klientai gali daryti ką nori. MongoDB yra atvirojo kodo. Atitinkamai klientai gali būti tokie protingi ir pikti – gali norėti viską sulaužyti. Spėjame, kad gali kilti Bizantijos Feilors.
- Išoriniams klientams, kurie yra už perimetro, yra svarbus apribojimas: jei ši funkcija išjungta, neturėtų būti stebimas joks našumo pablogėjimas.
- Kitas dalykas paprastai yra antiakademinis: ankstesnių ir būsimų versijų suderinamumas. Senos tvarkyklės turi palaikyti naujus naujinimus, o duomenų bazė turi palaikyti senas tvarkykles.
Apskritai visa tai nustato apribojimus.
Priežastinio nuoseklumo komponentai
Dabar pakalbėsiu apie kai kuriuos komponentus. Jei apsvarstysime priežastinį nuoseklumą apskritai, galime pasirinkti blokus. Pasirinkome iš kūrinių, kurie priklauso tam tikram blokui: Priklausomybių sekimas, laikrodžių pasirinkimas, kaip šie laikrodžiai gali būti sinchronizuojami tarpusavyje ir kaip užtikriname saugumą – tai apytikslis apybraižas, apie ką kalbėsiu:
Visiškas priklausomybės stebėjimas
Kodėl to reikia? Kad kai duomenys atkartojami, kiekviename įraše, kiekviename duomenų pakeitime būtų informacijos apie tai, nuo kokių pakeitimų jie priklauso. Pats pirmasis ir naivus pakeitimas yra tada, kai kiekviename pranešime, kuriame yra įrašas, yra informacija apie ankstesnius pranešimus:
Šiame pavyzdyje skaičius skliausteliuose yra įrašų skaičiai. Kartais šie įrašai su reikšmėmis netgi perduodami visi, kartais perkeliamos kai kurios versijos. Esmė ta, kad kiekviename pakeitime yra informacijos apie ankstesnįjį (akivaizdu, kad visa tai yra savyje).
Kodėl nusprendėme nenaudoti šio metodo (visiškas stebėjimas)? Akivaizdu, kad toks požiūris yra nepraktiškas: bet koks socialinio tinklo pakeitimas priklauso nuo visų ankstesnių to socialinio tinklo pakeitimų, perkeliant, tarkime, „Facebook“ ar „VKontakte“ kiekviename atnaujinime. Nepaisant to, yra daug tyrimų apie visišką priklausomybės stebėjimą – tai ikisocialiniai tinklai; kai kuriose situacijose tai tikrai veikia.
Aiškus priklausomybės stebėjimas
Kitas yra labiau ribotas. Čia taip pat atsižvelgiama į informacijos perdavimą, bet tik tai, kas aiškiai priklauso. Kas priklauso nuo to, kaip taisyklė, nustatoma Paraiškoje. Kai duomenys atkartojami, užklausa pateikia atsakymus tik tada, kai patenkinamos ankstesnės priklausomybės, ty parodomos. Tai yra priežastinio nuoseklumo veikimo esmė.
Ji mato, kad 5 įrašas priklauso nuo 1, 2, 3, 4 įrašų – atitinkamai ji laukia, kol klientas turės prieigą prie Penny prieigos sprendimu padarytų pakeitimų, kai visi ankstesni pakeitimai jau praėjo per duomenų bazę.
Tai mums taip pat netinka, nes informacijos vis dar yra per daug ir tai sulėtės. Yra ir kitas požiūris...
Lamporto laikrodis
Jie labai seni. Lamporto laikrodis reiškia, kad šios priklausomybės yra sujungtos į skaliarinę funkciją, kuri vadinama Lamporto laikrodžiu.
Skaliarinė funkcija yra tam tikras abstraktus skaičius. Jis dažnai vadinamas loginiu laiku. Su kiekvienu įvykiu šis skaitiklis didėja. Skaitiklis, kuris šiuo metu yra žinomas procesui, siunčia kiekvieną pranešimą. Aišku, kad procesai gali būti nesinchronizuoti, gali turėti visiškai skirtingus laikus. Nepaisant to, sistema kažkaip subalansuoja laikrodį su tokiais pranešimais. Kas atsitinka šiuo atveju?
Tą didelę skeveldrą padalinau į dvi dalis, kad būtų aišku: draugai gali gyventi viename mazge, kuriame yra kolekcijos dalis, o kanalas – kitame mazge, kuriame yra šios kolekcijos dalis. Ar aišku, kaip jie gali išeiti iš rikiuotės? Pirmas sklaidos kanalas sakys: „Atkartotas“, o tada „Draugai“. Jei sistema nesuteiks kažkokios garantijos, kad tiekimas nebus rodomas tol, kol nebus pristatytos ir Draugų kolekcijoje esančios Friends priklausomybės, tuomet turėsime būtent tokią situaciją, kurią minėjau.
Matote, kaip logiškai didėja skaitiklio laikas sklaidos kanale:
Taigi pagrindinė šio Lamporto laikrodžio ir priežastinio ryšio nuoseklumo savybė (paaiškinta naudojant Lamporto laikrodį) yra tokia: jei turime įvykius A ir B, o įvykis B priklauso nuo įvykio A*, tai reiškia, kad įvykio A loginis laikas yra mažesnis nei LogicalTime iš įvykio B.
* Kartais jie taip pat sako, kad A įvyko prieš B, tai yra, A įvyko prieš B - tai yra tam tikras santykis, kuris iš dalies sutvarko visą įvykių, kurie apskritai įvyko, rinkinį.
Priešingai yra neteisinga. Tai iš tikrųjų yra vienas pagrindinių Lamport Clock trūkumų – dalinė tvarka. Yra samprata apie vienalaikius įvykius, tai yra įvykius, kuriuose nei (A neįvyko prieš B), nei (A neįvyko prieš B). Pavyzdys galėtų būti, kad Leonardas lygiagrečiai pridėjo ką nors kitą kaip draugą (pavyzdžiui, net ne Leonardą, o Sheldoną).
Tai yra savybė, kuri dažnai naudojama dirbant su Lamport laikrodžiais: jie žiūri konkrečiai į funkciją ir iš to daro išvadą, kad galbūt šie įvykiai yra priklausomi. Nes vienas būdas yra teisingas: jei loginis laikas A yra mažesnis už loginį laiką B, tai B negali įvykti anksčiau nei A; o jei daugiau, tai gal.
Vektorinis laikrodis
Loginis Lamport laikrodžio vystymasis yra vektorinis laikrodis. Jie skiriasi tuo, kad kiekvienas čia esantis mazgas turi savo atskirą laikrodį ir yra perduodamas kaip vektorius.
Šiuo atveju matote, kad nulinis vektoriaus indeksas yra atsakingas už tiekimą, o pirmasis vektoriaus indeksas yra skirtas draugams (kiekvienam iš šių mazgų). O dabar jų padidės: rašant didėja nulinis „Paslaugos“ indeksas – 1, 2, 3:
Kodėl vektorinis laikrodis yra geresnis? Nes jie leidžia išsiaiškinti, kurie įvykiai vyksta vienu metu ir kada jie įvyksta skirtinguose mazguose. Tai labai svarbu tokiai dalijimo sistemai kaip MongoDB. Tačiau šito nepasirinkome, nors tai nuostabus dalykas, ir puikiai veikia, ir mums tikriausiai tiktų...
Jei turime 10 tūkstančių skeveldrų, negalime perkelti 10 tūkstančių komponentų, net jei juos suspaudžiame ar sugalvosime ką nors kita - naudingoji apkrova vis tiek bus kelis kartus mažesnė už viso šio vektoriaus tūrį. Todėl sukandę širdį ir dantis atsisakėme šio požiūrio ir perėjome prie kito.
Veržliaraktis TrueTime. Atominis laikrodis
Sakiau, kad bus istorija apie Spannerį. Tai šaunus dalykas, tiesiai iš XXI amžiaus: atominiai laikrodžiai, GPS sinchronizacija.
Kokia idėja? „Spanner“ yra „Google“ sistema, kuri neseniai netgi tapo prieinama žmonėms (jie pridėjo prie jos SQL). Kiekviena operacija turi tam tikrą laiko žymą. Kadangi laikas sinchronizuojamas*, kiekvienam įvykiui galima priskirti tam tikrą laiką – atominiai laikrodžiai turi laukimo laiką, po kurio garantuotai „įvyks“ kitoks laikas.
Taigi, tiesiog rašant į duomenų bazę ir laukiant tam tikrą laiką, automatiškai garantuojamas įvykio serializavimas. Jie turi stipriausią nuoseklumo modelį, kokį iš principo galima įsivaizduoti – tai Išorinis nuoseklumas.
* Tai yra pagrindinė „Lampart“ laikrodžių problema – paskirstytose sistemose jie niekada nėra sinchroniški. Jie gali skirtis; net naudojant NTP, jie vis tiek neveikia labai gerai. „Spanner“ turi atominį laikrodį, o sinchronizacija, regis, yra mikrosekundės.
Kodėl nepasirinkome? Nemanome, kad mūsų vartotojai turi įmontuotą atominį laikrodį. Kai jie atsiras, įmontuoti į kiekvieną nešiojamąjį kompiuterį, bus kažkoks super šaunus GPS sinchronizavimas - tada taip... Bet kol kas geriausia, kas įmanoma yra Amazon, Base Stations - fanatikams... Taigi naudojome kitus laikrodžius .
Hibridinis laikrodis
Tai iš tikrųjų pastebima MongoDB užtikrinant priežastinį nuoseklumą. Kaip jie hibridai? Hibridas yra skaliarinė vertė, tačiau ją sudaro du komponentai:
- Pirmoji – Unix epocha (kiek sekundžių praėjo nuo „kompiuterių pasaulio pradžios“).
- Antrasis yra tam tikras prieaugis, taip pat 32 bitų nepasirašytas int.
Tai viskas, iš tikrųjų. Yra toks požiūris: dalis, kuri atsakinga už laiką, visą laiką sinchronizuojama su laikrodžiu; kiekvieną kartą, kai įvyksta atnaujinimas, ši dalis yra sinchronizuojama su laikrodžiu ir paaiškėja, kad laikas visada yra daugiau ar mažiau teisingas, o padidėjimas leidžia atskirti įvykius, kurie įvyko tuo pačiu metu.
Kodėl tai svarbu MongoDB? Nes tai leidžia tam tikru momentu sukurti tam tikrus atsarginius restoranus, tai yra, įvykis indeksuojamas pagal laiką. Tai svarbu, kai reikia tam tikrų įvykių; Duomenų bazės atveju įvykiai yra duomenų bazės pokyčiai, įvykę tam tikrais laiko intervalais.
Svarbiausią priežastį pasakysiu tik tau (prašau, niekam nesakyk)! Tai padarėme, nes taip atrodo organizuoti, indeksuoti duomenys MongoDB OpLog. „OpLog“ yra duomenų struktūra, kurioje yra absoliučiai visi duomenų bazės pakeitimai: jie pirmiausia patenka į „OpLog“, o tada pritaikomi pačiai saugyklai, jei tai yra pakartota data arba fragmentas.
Tai buvo pagrindinė priežastis. Visgi duomenų bazės kūrimui keliami ir praktiniai reikalavimai, o tai reiškia, kad ji turi būti paprasta – mažai kodo, kuo mažiau sugedusių dalykų, kuriuos reikia perrašyti ir išbandyti. Tai, kad mūsų oplogai buvo indeksuojami hibridiniais laikrodžiais, labai padėjo ir leido mums padaryti teisingą pasirinkimą. Tai tikrai pasiteisino ir kažkaip stebuklingai suveikė patį pirmąjį prototipą. Buvo labai šaunu!
Laikrodžio sinchronizavimas
Mokslinėje literatūroje aprašyti keli sinchronizavimo būdai. Aš kalbu apie sinchronizavimą, kai turime dvi skirtingas šukes. Jei yra vienas kopijų rinkinys, sinchronizuoti nereikia: tai yra „vienas pagrindinis“; mes turime „OpLog“, į kurį patenka visi pakeitimai - šiuo atveju viskas jau sutvarkyta iš eilės pačiame „Oplog“. Bet jei turime dvi skirtingas skeveldras, laiko sinchronizavimas čia yra svarbus. Čia vektorinis laikrodis padėjo daugiau! Bet mes jų neturime.
Tinka antrasis - tai „Širdies dūžiai“. Galima keistis kai kuriais signalais, kurie atsiranda kiekvieną laiko vienetą. Tačiau širdies plakimas per lėtas, todėl klientui negalime suteikti delsos.
Tikras laikas, žinoma, yra nuostabus dalykas. Bet, vėlgi, tai turbūt ateitis... Nors Atlas tai jau galima padaryti, bet jau yra greiti „Amazon“ laiko sinchronizatoriai. Tačiau jis nebus prieinamas visiems.
Apkalbos yra tada, kai visose žinutėse yra laikas. Maždaug tai mes naudojame. Kiekvienas pranešimas tarp mazgų, tvarkyklė, duomenų mazgo maršrutizatorius, absoliučiai viskas MongoDB yra tam tikras elementas, duomenų bazės komponentas, kuriame yra veikiantis laikrodis. Jie visur turi hibridinio laiko reikšmę, jis perduodamas. 64 bitai? Tai leidžia, tai įmanoma.
Kaip visa tai veikia kartu?
Čia aš žiūriu į vieną kopijų rinkinį, kad būtų šiek tiek lengviau. Yra pradinis ir antrinis. Antrinė atlieka replikaciją ir ne visada visiškai sinchronizuojama su pirminiu.
Į „Pagrindinį“ įterpimą įvyksta tam tikra laiko reikšmė. Šis įdėklas padidina vidinį skaičių 11, jei tai yra didžiausia. Arba jis patikrins laikrodžio reikšmes ir sinchronizuos su laikrodžiu, jei laikrodžio reikšmės yra didesnės. Tai leidžia organizuoti pagal laiką.
Po to, kai jis padaro įrašą, įvyksta svarbus momentas. Laikrodis yra "MongoDB" ir padidinamas tik tuo atveju, kai rašoma į "Oplog". Tai įvykis, pakeičiantis sistemos būseną. Absoliučiai visuose klasikiniuose straipsniuose įvykiu laikomas pranešimo patekimas į mazgą: pranešimas atkeliavo, vadinasi, sistema pakeitė savo būseną.
Taip yra dėl to, kad atliekant tyrimus nėra iki galo aišku, kaip ši žinia bus interpretuojama. Mes tikrai žinome, kad jei tai neatsispindi „Oplog“, tai jokiu būdu nebus interpretuojama, o sistemos būklės pasikeitimas yra tik įrašas „Oplog“. Tai mums supaprastina viską: modelis jį supaprastina ir leidžia sutvarkyti viename kopijų rinkinyje bei daug kitų naudingų dalykų.
Grąžinama reikšmė, kuri jau buvo įrašyta į „Oplog“ – mes žinome, kad „Oplog“ jau turi šią reikšmę, o jos laikas yra 12. Dabar, tarkime, skaitymas pradedamas nuo kito mazgo (antrinio), o pats perduoda afterClusterTime. žinutę. Jis sako: „Man reikia visko, kas įvyko bent po 12 ar per dvylika“ (žr. paveikslėlį aukščiau).
Tai vadinama priežastiniu nuoseklumu (CAT). Teoriškai yra tokia koncepcija, kad tai yra tam tikra laiko dalis, kuri savaime yra nuosekli. Šiuo atveju galime pasakyti, kad tai yra sistemos būklė, kuri buvo stebima 12 metu.
Dabar čia dar nieko nėra, nes tai imituoja situaciją, kai jums reikia antrinio, kad galėtumėte kopijuoti duomenis iš pirminio. Jis laukia... Ir dabar duomenys atkeliavo - jis grąžina šias reikšmes atgal.
Beveik taip viskas veikia. Beveik.
Ką reiškia "beveik"? Tarkime, kad yra kažkas, kas perskaitė ir suprato, kaip visa tai veikia. Supratau, kad kiekvieną kartą, kai atsiranda ClusterTime, jis atnaujina vidinį loginį laikrodį, o tada kitas įrašas padidėja vienu. Ši funkcija užima 20 eilučių. Tarkime, kad šis asmuo perduoda didžiausią 64 bitų skaičių, atėmus vieną.
Kodėl „minus vienas“? Kadangi vidinis laikrodis bus pakeistas šia verte (akivaizdu, kad tai didžiausia įmanoma ir didesnė už dabartinį laiką), tada „Oplog“ įvyks įrašas, o laikrodis bus padidintas kitu vienetu - ir jau bus būti maksimali reikšmė (yra tiesiog visi vienetai, niekur kitur eiti) , unsaint ints).
Akivaizdu, kad po to sistema tampa absoliučiai niekam neprieinama. Jį galima tik iškrauti ir išvalyti – daug rankų darbo. Visas prieinamumas:
Be to, jei tai atkartojama kur nors kitur, tada visas klasteris tiesiog nukrenta. Visiškai nepriimtina situacija, kurią bet kas gali suorganizuoti labai greitai ir lengvai! Todėl šį momentą laikėme vienu svarbiausių. Kaip to išvengti?
Mūsų būdas yra pasirašyti clusterTime
Taip jis perduodamas žinutėje (prieš mėlyną tekstą). Bet mes taip pat pradėjome generuoti parašą (mėlynas tekstas):
Parašas generuojamas raktu, kuris saugomas duomenų bazėje, saugiame perimetro viduje; sugeneruojamas ir atnaujinamas (vartotojai nieko apie tai nemato). Sugeneruojama maiša, kiekvienas pranešimas pasirašomas, kai sukuriamas, ir patvirtinamas, kai gaunamas.
Tikriausiai žmonėms kyla klausimas: „Kiek tai sulėtėja? Sakiau, kad ji turėtų veikti greitai, ypač jei šios funkcijos nėra.
Ką šiuo atveju reiškia naudoti priežastinį nuoseklumą? Tai rodo parametrą afterClusterTime. Be to jis tiesiog perduos vertybes. Apkalbos, pradedant nuo 3.6 versijos, visada veikia.
Jei paliksime nuolatinį parašų generavimą, tai sulėtins sistemą net ir nesant funkcijos, kuri neatitinka mūsų požiūrių ir reikalavimų. Taigi, ką mes padarėme?
Padarykite tai greitai!
Gana paprastas dalykas, bet gudrybė įdomi – pasidalinsiu, gal kam bus įdomu.
Turime maišą, kuri saugo pasirašytus duomenis. Visi duomenys eina per talpyklą. Talpykloje pasirašomas ne konkretus laikas, o diapazonas. Kai gaunama tam tikra reikšmė, sugeneruojame diapazoną, užmaskuojame paskutinius 16 bitų ir pasirašome šią reikšmę:
Gavę tokį parašą, sistemą pagreitiname (santykinai) 65 tūkst. Tai veikia puikiai: kai atlikome eksperimentus, laikas iš tikrųjų sumažėjo 10 tūkstančių kartų, kai turėjome nuoseklų atnaujinimą. Akivaizdu, kad kai jie nesutaria, tai neveikia. Tačiau daugeliu praktinių atvejų tai veikia. Diapazono parašo derinys su parašu išsprendė saugumo problemą.
Ko mes išmokome?
Pamokos, kurias išmokome iš to:
- Reikia skaityti medžiagą, istorijas, straipsnius, nes turime daug įdomių dalykų. Kai dirbame su kokia nors funkcija (ypač dabar, kai atlikome operacijas ir pan.), turime perskaityti ir suprasti. Tai užtrunka, bet iš tikrųjų labai naudinga, nes leidžia suprasti, kur esame. Atrodė, kad nieko naujo nesugalvojome – tiesiog paėmėme ingredientus.
Apskritai, kai vyksta akademinė konferencija (pavyzdžiui, Sigmonas) yra tam tikras mąstymo skirtumas – visi susitelkia į naujas idėjas. Kas naujo mūsų algoritme? Čia nėra ypatingos naujovės. Naujovė veikiau slypi tame, kaip sumaišėme esamus požiūrius. Todėl pirmas dalykas yra perskaityti klasiką, pradedant nuo Lampart.
- Gamyboje reikalavimai visai kitokie. Esu tikras, kad daugelis iš jūsų susiduria ne su „sferinėmis“ duomenų bazėmis abstrakčiame vakuume, o su įprastais, tikrais dalykais, kurie turi problemų dėl pasiekiamumo, delsos ir atsparumo gedimams.
- Paskutinis dalykas yra tai, kad turėjome pažvelgti į skirtingas idėjas ir kartu sujungti kelis visiškai skirtingus straipsnius į vieną požiūrį. Idėja apie pasirašymą, pavyzdžiui, apskritai kilo iš straipsnio, kuriame buvo svarstomas Paxos protokolas, kuris ne Bizantijos nevykėliams yra autorizavimo protokole, bizantiškiems - už įgaliojimo protokolo ribų... Apskritai mes būtent tai ir yra baigė daryti.
Čia visiškai nieko naujo! Bet kai tik viską sumaišome... Tai tas pats, kas sakyti, kad Olivier salotų receptas yra nesąmonė, nes kiaušiniai, majonezas ir agurkai jau sugalvoti... Apie tą pačią istoriją.
Aš baigsiu tuo. Ačiū!
Klausimai
Klausimas iš auditorijos (toliau – B): – Ačiū, Michailai, už pranešimą! Tema apie laiką įdomi. Jūs naudojate Gossiping. Jie sakė, kad kiekvienas turi savo laiką, visi žino savo vietos laiką. Kaip suprantu, mes turime vairuotoją - gali būti daug klientų su vairuotojais, užklausų planuotojai irgi, skeveldros irgi... O prie ko ta sistema susiveda, jei staiga atsiranda neatitikimas: kažkas nusprendžia, kad jis skirtas minute į priekį, kažkas minute atsilieka? Kur mes atsidursime?
MT: – Tikrai puikus klausimas! Aš tik norėjau pakalbėti apie šukes. Jei teisingai suprantu klausimą, turime tokią situaciją: yra 1 ir 2 skeveldros, skaitoma iš šių dviejų skeveldrų - jie nesutampa, jie nebendrauja vienas su kitu, nes laikas, kurį jie žino, yra skirtingas, ypač laikas, kai jie egzistuoja oploguose.
Tarkime, kad 1 skeveldra padarė milijoną įrašų, 2 skeveldra nieko nepadarė, o prašymas sulaukė dviejų skeveldrų. Pirmojo pogrupio laikas viršija milijoną. Tokioje situacijoje, kaip paaiškinau, shard 2 niekada nereaguos.
In: – Norėjau sužinoti, kaip jie sinchronizuojasi ir pasirenka vieną loginį laiką?
MT: - Labai lengva sinchronizuoti. Šardas, kai pas jį ateina afterClusterTime ir jis neranda laiko „Oplog“, inicijuoja nepatvirtintą. Tai yra, jis savo laiką pakelia rankomis iki šios vertės. Tai reiškia, kad jame nėra įvykių, atitinkančių šią užklausą. Jis sukuria šį įvykį dirbtinai ir taip tampa priežastiniu nuoseklumu.
In: – O jeigu po to jam ateis kiti įvykiai, kurie pasiklydo kažkur tinkle?
MT: – „Shard“ sukurtas taip, kad daugiau jų nebeliktų, nes tai vienas meistras. Jei jau užsiregistravo, tai jie neateis, o ateis vėliau. Negali atsitikti taip, kad kažkas kažkur užstringa, tada jis nerašo, o tada ateina šie įvykiai - ir priežastinis nuoseklumas sugenda. Kai jis nerašo, jie visi turėtų ateiti paskui (jis jų lauks).
In: – Turiu keletą klausimų dėl eilių. Priežastinis nuoseklumas daro prielaidą, kad yra tam tikra veiksmų, kuriuos reikia atlikti, eilė. Kas nutiks, jei viena iš mūsų pakuočių dings? Štai ateina 10, 11... 12 dingo, o visi kiti laukia, kol tai išsipildys. Ir staiga mūsų automobilis mirė, mes nieko negalime padaryti. Ar yra maksimalus eilės, kuri kaupiasi prieš vykdant, ilgis? Kokia mirtina nesėkmė įvyksta, kai prarandama viena būsena? Be to, jei užrašytume, kad yra kažkokia ankstesnė būsena, tai turėtume nuo jos kažkaip pradėti? Bet jie jo neatstūmė!
MT: – Taip pat puikus klausimas! Ką mes darome? MongoDB turi kvorumo rašymo, kvorumo skaitymo koncepciją. Kokiais atvejais žinutė gali būti prarasta? Kai rašymas nėra kvorumas arba kai skaitymas nėra kvorumas (taip pat gali prilipti kažkokios šiukšlės).
Dėl priežastinio nuoseklumo buvo atliktas didelis eksperimentinis testas, kurio rezultatas – tuo atveju, kai rašoma ir skaitoma nekvorumu, atsiranda priežastinio nuoseklumo pažeidimų. Būtent tai, ką tu sakai!
Mūsų patarimas: naudokite bent kvorumo skaitymą, kai naudojate priežastinį nuoseklumą. Tokiu atveju nieko nebus prarasta, net jei kvorumo įrašas bus prarastas... Tai ortogonali situacija: jei vartotojas nenori, kad duomenys būtų prarasti, jam reikia naudoti kvorumo įrašą. Priežastinis nuoseklumas negarantuoja ilgaamžiškumo. Patvarumą garantuoja replikacija ir su replikacija susijusi įranga.
In: – Kai sukuriame egzempliorių, kuris atlieka sharding už mus (atitinkamai ne pagrindinį, o vergą), jis remiasi savo mašinos Unix laiku arba „master“ laiku; Ar jis sinchronizuojamas pirmą kartą ar periodiškai?
MT: – Dabar patikslinsiu. Šerdis (t. y. horizontali pertvara) – ten visada yra pirminis. O skeveldra gali turėti „šeimininką“ ir gali būti kopijos. Bet shard visada palaiko įrašymą, nes turi palaikyti tam tikrą domeną (shard turi pagrindinį).
In: – Vadinasi, viskas priklauso tik nuo „šeimininko“? Ar visada naudojamas meistro laikas?
MT: – Taip. Galima vaizdžiai pasakyti: laikrodis tiksi, kai įvyksta įėjimas į „šeimininką“, į „Oplog“.
In: – Turime klientą, kuris jungiasi ir jam nieko nereikia žinoti apie laiką?
MT: - Tau visai nieko nereikia žinoti! Jei kalbėsime apie tai, kaip tai veikia klientą: kai klientas nori naudoti priežastinį nuoseklumą, jam reikia pradėti seansą. Dabar viskas yra: ir operacijos sesijoje, ir teisių atgavimas... Sesija – tai loginių įvykių, vykstančių su klientu, išdėstymas.
Jei jis atidaro šią sesiją ir sako, kad nori priežastinio nuoseklumo (jei seansas palaiko priežastinį nuoseklumą pagal numatytuosius nustatymus), viskas veikia automatiškai. Vairuotojas įsimena šį laiką ir padidina jį, kai gauna naują pranešimą. Jis prisimena, kokį atsakymą grąžino ankstesnis iš serverio, kuris grąžino duomenis. Kitoje užklausoje bus afterCluster ("laikas didesnis nei šis").
Klientui nereikia absoliučiai nieko žinoti! Tai jam visiškai neskaidru. Jei žmonės naudojasi šiomis funkcijomis, ką jie gali padaryti? Pirma, galite saugiai skaityti antrinius: galite rašyti į pagrindinį ir skaityti iš geografiškai atkartotų antrinių ir būti tikri, kad tai veikia. Tuo pačiu metu seansus, kurie buvo įrašyti pirminėje, netgi galima perkelti į antrinį, t. y. galite naudoti ne vieną seansą, o keletą.
In: – Naujas skaičiavimo mokslo lygmuo – CRDT (angl. Conflict-free Replicated Data Types) duomenų tipai – yra glaudžiai susijęs su galutinio nuoseklumo tema. Ar svarstėte integruoti tokio tipo duomenis į duomenų bazę ir ką apie tai galite pasakyti?
MT: - Geras klausimas! CRDT yra prasminga rašymo konfliktams: „MongoDB“ – vienas valdiklis.
In: – Turiu klausimą iš devopso. Realiame pasaulyje būna tokių jėzuitiškų situacijų, kai įvyksta Bizantijos nesėkmė, o pikti žmonės saugomo perimetro viduje pradeda kištis į protokolą, ypatingu būdu siųsti amatų paketus?
MT: – Piktieji žmonės perimetro viduje yra kaip Trojos arklys! Blogi žmonės perimetro viduje gali padaryti daug blogų dalykų.
In: – Aišku, kad paliekant, grubiai tariant, skylę serveryje, pro kurią galima įdėti dramblių zoologijos sodą ir visam laikui sugriauti visą klasterį... Rankiniu būdu atkūrimas užtruks... Tai, švelniai tariant, yra negerai. Kita vertus, tai įdomu: realiame gyvenime, praktikoje, pasitaiko situacijų, kai ištinka natūraliai panašūs vidiniai priepuoliai?
MT: – Kadangi realiame gyvenime su saugumo pažeidimais susiduriu retai, negaliu pasakyti, ar jų pasitaiko. Bet jei mes kalbame apie plėtros filosofiją, mes galvojame taip: mes turime perimetrą, kuris suteikia vaikinams, kurie atlieka saugumą - tai yra pilis, siena; o perimetro viduje gali daryti ką nori. Akivaizdu, kad yra vartotojų, turinčių galimybę tik peržiūrėti, ir yra vartotojų, turinčių galimybę ištrinti katalogą.
Priklausomai nuo teisių, žalą, kurią gali padaryti vartotojai, gali padaryti pelė arba dramblys. Akivaizdu, kad visas teises turintis vartotojas gali daryti bet ką. Ribotas teises turintis vartotojas gali padaryti žymiai mažiau žalos. Visų pirma, jis negali pažeisti sistemos.
In: – Saugomame perimetre kažkas bandė sukurti serveriui netikėtus protokolus, kad visiškai sugadintų serverį, o jei pasiseks, tada visą klasterį... Ar kada nors taip „gerai“ gaunasi?
MT: "Aš niekada negirdėjau apie tokius dalykus". Tai, kad tokiu būdu galite sugadinti serverį, nėra paslaptis. Fail inside, būdamas iš protokolo, būdamas autorizuotas vartotojas, galintis kažką panašaus į žinutę parašyti... Tiesą sakant, tai neįmanoma, nes vis tiek bus patikrinta. Šį autentifikavimą galima išjungti vartotojams, kurie to nenori – tada tai yra jų problema; jie, grubiai tariant, patys sugriovė sienas ir ten gali įstumti dramblį, kuris sutryps... Bet apskritai gali apsirengti remontininku, ateik ir ištrauk!
In: – Ačiū už pranešimą. Sergejus („Yandex“). Mong yra konstanta, kuri riboja balsuojančių narių skaičių replikų rinkinyje, ir ši konstanta yra 7 (septynios). Kodėl tai yra konstanta? Kodėl tai nėra kažkoks parametras?
MT: – Turime replikų rinkinius su 40 mazgų. Visada yra dauguma. nezinau kuri versija...
In: – „Replica Set“ galite paleisti balsavimo teisę neturinčius narius, tačiau balsavimo teisę turinčių narių skaičius yra daugiausia 7. Kaip tokiu atveju galime išgyventi po išjungimo, jei mūsų kopijų rinkinys yra paskirstytas 3 duomenų centruose? Vienas duomenų centras gali lengvai išsijungti, o kita mašina gali iškristi.
MT: – Tai jau šiek tiek nepatenka į pranešimo sritį. Tai bendras klausimas. Galbūt vėliau papasakosiu apie tai.
Kai kurie skelbimai 🙂
Dėkojame, kad likote su mumis. Ar jums patinka mūsų straipsniai? Norite pamatyti įdomesnio turinio? Palaikykite mus pateikdami užsakymą ar rekomenduodami draugams, , unikalus pradinio lygio serverių analogas, kurį mes sugalvojome jums: (galima su RAID1 ir RAID10, iki 24 branduolių ir iki 40 GB DDR4).
„Dell R730xd“ 2 kartus pigiau „Equinix Tier IV“ duomenų centre Amsterdame? Tik čia Olandijoje! „Dell R420“ – 2 x E5-2430 2.2 GHz 6C 128 GB DDR3 2 x 960 GB SSD 1 Gbps 100 TB – nuo 99 USD! Skaityti apie
Šaltinis: www.habr.com