HighLoad++, Mihhail Tjulenev (MongoDB): Kausalne järjepidevus: teooriast praktikani

järgmine HighLoad++ konverents toimub 6. ja 7. aprillil 2020 Peterburis.
Üksikasjad ja piletid lingi kaudu. HighLoad++ Siberia 2019. Saal «Krasnojarsk». 25. juuni, 12:00. Teesid ja esitlus.

Kui praktilised nõudmised ja teooria ei ühti, unustades kaubanduse jaoks olulised aspektid. Selles ettekandes tutvustatakse erinevate lähenemisviiside valiku ja kombineerimise protsessi Causal consistency komponentide loomisel akadeemiliste uurimuste põhjal, arvestades kaubanduse vajadusi. Kuulajad saavad teada olemasolevatest teoreetilistest lähenemisviisidest, nagu loogilised kellad, sõltuvuse jälgimine, süsteemi turvalisus, kella sünkroniseerimine, ja miks MongoDB valis teatud lahendused.

Mikhail Tyulenev (edaspidi - MT): – Räägin Causal consistency'st – funktsioonist, millega töötasime MongoDB-s. Töötan jaotatud süsteemide grupis, me valmistasime selle toodanguks umbes kaks aastat tagasi.

Protsessis tuli tutvuda suure hulga akadeemilise uurimistööga, kuna see funktsioon on piisavalt hästi uuritud. Selgus, et ükski artikkel ei vasta sellele, mida produktsioonis vaja, andmebaasi arvestades erilisi nõudeid, mis on tõenäoliselt igas produktsioonirakenduses.

Ma räägin sellest, kuidas meie, olles akadeemilise uurimistöö tarbija, valmistame sellest midagi, mida saame hiljem esitada oma kasutajatele valmistoiduna, millega on mugav ja ohutu töötada.

Kausaalne ühtsus (Causal consistency). Määratleme mõisted

Esiteks tahan ma üldiselt öelda, mis on kausaalne ühtsus. On kaks tegelast – Leonard ja Penny (sarjast „Suure Päikese Teooria“):

Kujutage ette, et Penny on Euroopas ja Leonard soovib talle üllatust korraldada, näiteks pidu. Ta ei tule aga midagi paremat pähe, kui kustutada Penny sõbralistist, saata kõigile sõpradele uuendus feedis: "Naeratame Penny!" (ta on Euroopas, magab, ei näe seda kõike ja ei saa seda haarata, sest ta ei ole seal). Lõpuks eemaldab ta selle postituse, kustutab selle "Feedist" ja taastab accessi, et ta ei märkaks midagi ja skandaali ei tekiks.
See kõik on tore, aga oletame, et süsteem on jaotatud ja asjad ei lähe päris nii. Näiteks võib juhtuda, et Penny accessi piiramine toimus pärast seda, kui postitus ilmus, kui sündmused ei ole omavahel otseselt seotud. Tegelikult on see näide, kus on vajalik Kausaalne kooskõla, et täita äriülesanne (antud juhul).

Tegelikult on need üsna mittetriviaalne omadus andmebaasides – väga vähesed toetavad neid. Liigume nüüd mudelite juurde.

Kooskõla mudelid (Consistency Models)

Mis on konsistentsi mudel andmebaasides? Need on teatud garantiid, mida jaotussüsteem annab seoses sellega, milliseid andmeid ja millises järjekorras klient saab.

Põhimõtteliselt põhinevad kõik konsistentsimudelid sellele, kui sarnane jaotussüsteem on süsteemile, mis töötab näiteks ühel madala taseme seadmel. Ja kui sarnane on süsteem, mis töötab tuhandetel geograafiliselt jaotatud nod’del, sülearvutile, kus kõik need omadused toimivad põhimõtteliselt automaatsetena.

Seetõttu rakendatakse konsistentsimudeleid ainult jaotussüsteemide puhul. Kõik süsteemid, mis varem eksisteerisid ja töötasid ühel vertikaalsel skaleerimisel, selliseid probleeme ei kogenud. Seal oli üks Buffer Cache ja sealt luges kõik alati välja.

Mudel Strong

Esimene mudel on Strong (või järjepidevuse mudel, nagu seda sageli nimetatakse). See on konsistentsimudel, mis garanteerib, et iga muudatus, kui selle toimumise kohta on saadud kinnitus, muutub nähtavaks kõigile süsteemi kasutajatele.

See loob globaalne järjestus kõigile sündmustele andmebaasis. See on väga tugev järjepidevuse omadus ja üldiselt on see väga kulukas. Siiski on see hästi toetatud. See on lihtsalt väga kallis ja aeglane – seda kasutatakse harva. Seda nimetatakse rise ability.

On veel üks, tugevam omadus, mida toetab «Spanner» – seda nimetatakse väliseks järjepidevuseks. Räägime sellest natuke hiljem.

Causal

Järgmine on Causal, just see, mille üle ma rääkisin. Tugeva ja Causal vahel on veel mitmeid alaliike, millest ma ei hakka rääkima, kuid need kõik viivad Causal’i. See on oluline mudel, kuna see on kõige tugevam kõigist mudelitest, kõige tugevam järjepidevus võrgu või jagunemiste korral.

Causals – see tähendab olukorda, kus sündmused on omavahel seotud põhjuslikus seoses. Sageli tõlgendatakse neid kui oma õigusi kliendi vaatenurgast. Kui klient on näinud mõningaid väärtusi, ei saa ta näha minevikus olnud väärtusi. Ta hakkab juba nägema prefikskohaseid lugemisi. See kõik viib ikkagi samasse kohta.
Causals nagu kooskõla mudel – osaline sündmuste järjestamine serveris, kus kõik kliendi sündmused jälgitakse samas järjestuses. Antud juhul – Leonard ja Penny.

Lõplik

Kolmas mudel on Lõplik Kooskõla. See on see, mida toetavad kõik jaotatud süsteemid, minimaalne mudel, mis mõistuse poolest üldse olemas on. See tähendab järgmist: kui andmetes toimuvad mingid muutused, siis mingil hetkel muutuvad nad kooskõlaliseks.

Selle hetke kohta ei öelda midagi muud, muidu muutuks see Väliseks Kooskõlaks – see oleks hoopis teine lugu. Sellegipoolest on see väga populaarne mudel, kõige levinum. Vaikimisi kasutavad kõik jaotatud süsteemide kasutajad just Lõplikku Kooskõla.

Tahaksin tuua mõned võrdlevad näited:

Mida need nooled tähendavad?

• Latentsus. Konsistentsuse tugevuse suurenedes muutub see arusaadavatel põhjustel suuremaks: tuleb teha rohkem kirjeid, saada kinnitust kõigilt hostidelt ja sõlmedelt, mis osalevad klastris, et andmed seal juba olemas on. Seega on Eventual Consistency kõige kiirem vastus, kuna seal on tavaliselt võimalik isegi mälus kinnitada ja sellest piisab.
• Saadavus. Kui seda mõista kui süsteemi võimet vastata, kui esinevad võrgu katkestused, jaotused või mingid tõrked – vigadetaluvus suureneb konsistentsimudeli vähenedes, kuna piisab sellest, et üks host püsiks elus ja samal ajal edastaks mõningaid andmeid. Eventual Consistency ei garanteeri andmete osas üldse mitte midagi – see võib olla mis tahes.
• Anomaaliad. Samas, loomulikult suureneb anomaaliate arv. Strong Consistency puhul ei tohiks neid peaaegu üldse olla, samas kui Eventual Consistency puhul võivad need olla igasugused. Tekib küsimus: miks inimesed valivad Eventual Consistency, kui see sisaldab anomaaliaid? Vastus peitub selles, et Eventual Consistency mudelid on rakendatavad ning anomaaliad eksisteerivad näiteks lühikese aja jooksul; on võimalik kasutada peamudi lugemiseks ja enam-vähem järjepidevaid andmeid lugeda; sageli on võimalus kasutada tugevaid järjepidevuse mudeleid. Praktikas toimib see ning sageli on anomaaliate arv ajaliselt piiratud.

CAP teoreem

Kui näete sõnu järjepidevus, kätte saadavus – mis teile pähe tuleb? Õige – CAP teoreem! Soovin nüüd müüti hajutada… See ei ole minu teema – on Martin Kleppmann, kes on kirjutanud suurepärase artikli, suurepärase raamatu.

CAP-teoreem on 2000-ndatel formuleeritud põhimõte, mis käsitleb järjepidevust, kättesaadavust ja jagunemisi: võtke ükskõik millised kaks, kolmandat ei saa valida. See oli teatud põhimõte, mis tõestati teoreemina mõned aastat hiljem, seda tegid Gilbert ja Lynch. Seejärel hakkas seda kasutama kui mantrana - süsteemid jagunesid CA, CP, AP jne.

Tegelikult tõestati see teoreem järgmiste olukordade jaoks... Esiteks käsitleti kättesaadavust mitte kui pidevat väärtust nullist sajani (0 - süsteem on 'surnud', 100 - reageerib kiiresti; me oleme harjunud seda nii vaatama), vaid kui algoritmi omadust, mis tagab, et kõikide selle käivitamiste käigus tagastatakse andmed.

Käivitamise ajast ei räägita üldse midagi! On olemas algoritm, mis tagastab andmed 100 aasta pärast - täiesti hea kättesaadavus-algoritm, mis on osa CAP-teoreemist.
Teiseks: teoreemi tõestamine toimus ühe ja sama võtme väärtuste muutuste puhul, kusjuures need muutused on resizable rida. See tähendab, et neid ei kasutata praktiliselt, kuna mudelid on muud Eventual Consistency, Strong Consistency (võib-olla).

Mille see kõik on? Ajavahemik CAP teoreemina, nagu see tõestatud on, ei ole praktiliselt kasutatav, harva kasutatakse. Teoreetilises vormis piirab see mingil moel kõike. Tekib mingi põhimõte, mis on intuitiivselt õige, kuid ei ole tõestatud.

Kaasne konsistents – kõige tugevam mudel

See, mis praegu toimub – on võimalik saada kõik kolm asja: Konsistents, Saadavus, kasutada Partitions. Eelkõige kaasne konsistents – kõige tugevam konsistentsi mudel, mis töötas isegi Partitions (süsteemi katkestuste) olemasolul. Seetõttu on see nii suur huvi ja me hakkasime sellega tegelema.

Esiteks lihtsustab see rakenduste arendajate tööd. Eelkõige on serveri suur toetus: kui kõik kirjed, mis toimuvad ühe kliendi sees, garanteeritult jõuavad teise kliendi juurde õiges järjekorras. Teiseks talub see partitions.

MongoDB sisemised protsessid

Kuna on aeg lõunat, liigume kööki. Räägin süsteemi mudelist, nimelt – mis on MongoDB neile, kes kuulevad sellisest andmebaasist esmakordselt.

MongoDB (edasi – «MongoDB») on jaotatud süsteem, mis toetab horisontaalset skaleerimist, st sharding'i; ja iga shard'i sees toetab ta ka andmete ülemäärasust, st replikatsiooni.

Shardimine «MongoDB's» (mitte-relationaalne andmebaas) teostab automaatset tasakaalustamist, st iga dokumendi kogu (või «tabel» relationaalsete andmete terminoloogias) jagatakse tükkideks, ja server liigub need automaatselt shardi vahel.

Küsimuste marsruuter, mis jaotab päringud, on kliendi jaoks teatud klient, mille kaudu ta töötab. Ta juba teab, kus ja millised andmed asuvad ning suunab kõik päringud õigesse shardi.

Veel üks oluline punkt: MongoDB on single master. On üks Primaarne – ta võib võtta kirjeid, säilitades need võtmed, mis tal endas on. Multi-master kirjutamist teha ei saa.

Oleme välja andnud versiooni 4.2 – seal on ilmunud uusi huvitavaid asju. Esiteks, oleme lisanud Lucene – otsing – nimelt executable java otse «Mongo's», ja seal on nüüd võimalik teha otsingut läbi Lucene, sama nagu «Elasticsearchis».

Ja tegime uue toote – Charts, mis on samuti saadaval „Atlasel” (meie enda Cloud „Mongo”). Neil on Free Tier – saad sellega mängida. Charts meeldis mulle väga – andmete visualiseerimine on väga intuitiivne.

Koosseis Causal consistency

Olen kokku lugenud umbes 230 artiklit, mis on selles küsimuses avaldatud – Leslie Lampertilt. Praegu jagan teiega oma mälust mõningaid neist materjalidest.

Kõik algas Leslie Lamperti artiklist, mis ilmus 1970. aastatel. Nagu näete, jätkatakse selle teema uurimist siiani. Praegu on Causal consistency taas tähelepanu keskmes seoses jaotatud süsteemide arenguga.

Piirangud

Millised piirangud on olemas? See on tegelikult üks peamisi punkte, sest tootmissüsteemide kehtestatud piirangud erinevad oluliselt akadeemilistes artiklites esitatud piirangutest. Need on sageli üsna kunstlikud.

• Esiteks, „MongoDB” – see on single master, nagu ma juba ütlesin (see lihtsustab asju oluliselt).
• Arvame, et süsteem peaks toetama umbes 10 000 shard'i. Me ei saa teha mõningaid arhitektuurilisi otsuseid, mis selgelt piiraksid seda väärtust.
• Meil on pilv, kuid me arvame, et inimesel peaks olema võimalus, kui ta laadib alla binaarfaili, käivitab selle oma sülearvutis ja kõik töötab suurepäraselt.
• Me arvame, et Researchis kasutatakse harva: välised kliendid võivad teha, mida iganes tahavad. «MongoDB» on avatud lähtekoodiga. Seega võivad kliendid olla sedavõrd nutikad, halvad – võivad soovida kõike purustada. Me arvame, et võib esineda byzantilisi vigu.
• Väliste klientide jaoks, kes on väljaspool perimeetrit – oluline piirang: kui see funktsioon on välja lülitatud, siis ei tohiks esineda mingeid jõudluse langusi.
• Veel üks punkt – täiesti antiakadeemiline: varasemate ja tulevaste versioonide ühilduvus. Vanad draiverid peavad toetama uusi uuendusi ning andmebaas peab toetama vanu draivereid.

Üldiselt seab see kõik piiranguid.

Causal consistency komponendid

Kannan räägin mõnest komponendist. Kui vaadata üldiselt Causal consistency, võib eristada plokke. Valisime välja tööd, mis kuuluvad teatud plokkidesse: Dependency Tracking, kellade valimine, kuidas neid kellasid omavahel sünkroonida ja kuidas me tagame turvalisuse – see on ligikaudne plaan, millest ma räägin:

Täielik sõltuvuste jälgimine (Full Dependency Tracking)

Miks see vajalik on? Selleks, et kui andmed replitseeritakse – igal kirjal, igal andme muutmisel oleks teave selle kohta, milliseid muudatusi need sõltuvad. Kõige esmane ja naiivsem muudatus on see, et iga sõnum, mis sisaldab kirja, sisaldab teavet eelnevate sõnumite kohta:

Selles näites on sulgudes number kirje number. Mõnikord edastatakse need kirjed väärtustega isegi täielikult, mõnikord edastatakse mingid versioonid. Oluline on see, et iga muudatus sisaldab teavet eelneva kohta (ilmselt kannab seda endas).

Miks me otsustasime mitte kasutada sellist lähenemist (täielik jälgimine)? Ilmselgelt, sest see lähenemine pole praktiline: iga muutus sotsiaalvõrgustikus sõltub kõigist varasematest muudatustest selles sotsiaalvõrgustikus, edastades näiteks "Facebooki" või "VKontakte" igas uuenduses. Siiski on palju uuringuid, mis käsitlevad just Full Dependency Tracking – see on ennetav sõltuvuste jälgimine, mis mõnes olukorras tõesti toimib.

Selge sõltuvuste jälgimine (Explicit Dependency Tracking)

Järgmine on piiratum. Siin käsitletakse samuti informatsiooni edastamist, kuid ainult seda, mis on selgelt sõltuv. Mida miski sõltub, määrab tavaliselt rakendus. Andmeid replikatsiooni käigus väljastatakse ainult vastuseid, kui eelnevad sõltuvused on rahuldatud, st nähtavaks tehtud. Just nii töötab Causal consistency.

See näeb, et sissekanne 5 sõltub sissekanne 1, 2, 3, 4 – seetõttu ootab ta, kuni klient pääseb juurde nendele muudatustele, mida Penny juurdepääsu määruse alusel tehti, kui kõik eelnevad muudatused on juba andmebaasis läbitud.

See, we are not satisfied with this either, because there is still too much information, and it will slow things down. There is another approach…

Lamporti kella (Lamport Clock)

Needless to say, they are very old. Lamport Clock implies that these dependencies are compressed into a scalar function known as Lamport Clock.

A scalar function is an abstract number. It is often referred to as logical time. With each event, this counter increases. The counter known to the process sends every message. It is clear that the processes can be desynchronized, having completely different times. Nevertheless, this message exchange somehow balances the clocks. What happens in this case?

Ma jagasin selle suure shard'i kahte ossa, et oleks selge: Friends võivad elada ühes sõlmes, mis sisaldab osa kollektsioonist, samas kui Feed – teises sõlmes, kus hoitakse samuti osa sellest kollektsioonist. Kuidas nad siis järjekorda ei satu? Esiteks ütleb Feed: „Replitseeriti”, ja seejärel – Friends. Kui süsteem ei tagada, et Feed ei kuvata, kuni Friends kollektsioonis olevad sõltuvused on samuti esitatud, tekib meil just see olukord, millest ma rääkisin.

Te näete, kuidas Feed'i loogiline loendur tõuseb:

Seega on selle Lamport Clock'i ja Causal consistency (Lamport Clock'i kaudu seletatud) peamine omadus järgmine: kui meil on sündmused A ja B, ja sündmus B sõltub sündmusest A *, siis järeldub, et Event A loogiline aeg on väiksem kui Event B loogiline aeg.

* Mõnikord öeldakse ka, et A juhtus enne B, st A juhtus enne B – see on suhe, mis osaliselt järjestab kogu sündmuste kogumi, mis kunagi toimus.

Vale suunas on vale. See on tegelikult üks peamisi Lamporti kella miinuseid – osaline järjestus. Seal on mõisted samasuguste sündmuste kohta, mis tähendab, et ei (A juhtus enne B), ega (A juhtus pärast B). Näiteks võib tuua paralleelse sõbra lisamise, näiteks Leonard lisab Sheldonit sõbraks.
See ongi omadus, millega sageli töödelda Lamporti kelladega: vaadatakse just funktsiooni ja sellest tehakse järeldus – võib-olla on need sündmused omavahel seotud. Sest ühes suunas on see tõsi: kui LogicalTime A on väiksem kui LogicalTime B, siis B ei saa juhtuda enne A; aga kui on suurem, siis võib juhtuda.

Vektorkellad (Vector Clock)

Lamporti kella loogiline areng on Vektorkellad. Need erinevad seetõttu, et igas siin olevas sõlmes on oma, eraldi kell, ja need edastatakse vektorina.
Antud juhul näete, et vektori nullindeks vastab Feedile ja vektori esimene indeks sõpradele (igaühe jaoks nendes sõlmedes). Ja nüüd hakkavad need suurenema: nullindeksi "Feed" väärtus suureneb kirjutades – 1, 2, 3:

Miks on vektorkellad paremad? Sest need aitavad mõista, millised sündmused toimuvad samaaegselt ja millal need eri noodides aset leiavad. See on väga oluline sharding-süsteemi, nagu "MongoDB", jaoks. Siiski ei valinud me seda, kuigi see oleks olnud suurepärane lahendus ja toimib suurepäraselt, oleks see meile tõenäoliselt sobinud…

Kui meil on 10 tuhat shard'i, ei saa me edastada 10 tuhat komponenti, isegi kui me tihendame või leiutame midagi muud – kasulik koormus on siiski mitu korda väiksem kui kogu selle vektori maht. Seetõttu, südamevaluga ja hambaid peedes, loobusime sellest lähenemisviisist ja läksime edasi teise juurde.

Spanner TrueTime. Aatomikellad

Ma ütlesin, et tuleb jutt "Spannerist". See on äge asi, otse 21. sajandist: aatomikellad, GPS-sünkroniseerimine.

Milline on idee? "Spanner" on Google'i süsteem, mis hiljuti sai isegi inimestele kättesaadavaks (nad lisasid sellele SQL-i). Igal tehingul on seal mingi aja märgistus. Kuna aeg on sünkroniseeritud*, saab igale sündmusele määrata kindla aja – aatomikelladel on ooteaeg, pärast mida toimub kindel muudatus ajas.

Seega tagab lihtsalt andmebaasi kirjutamine ja teatud aja ootamine automaatselt sündmuse serialiseeritavuse. Neil on kõige tugevam järjepidevuse mudel, mida üldse kujutada võib – see on väline järjepidevus.

* See on põhiprobleem Lamporti kellade puhul – need ei ole kunagi sünkroonitud jaotatud süsteemides. Need võivad erineda isegi NTP olemasolul, töötavad endiselt mitte eriti hästi. "Spanner" omab aatomikellasid ja sünkroniseerimist, tundub, et mikrosekundite täpsusega.

Miks me ei valinud? Me ei eelda, et meie kasutajatel on sisseehitatud aatomikellad. Kui need kunagi tulevad, olles sisseehitatud igasse sülearvutisse, on olemas mingi superäge GPS-sünkroniseerimine – siis jah... Praegu on parim, mis võimalik – "Amazon", baasjaamad – fännide jaoks... Seega kasutasime teisi kellasid.

Hübriidkell (Hybrid Clock)

See on tegelikult see, mis tiksub "MongoDB"-s, pakkudes kausaalset järjepidevust. Miks nad on hübriidsed? Hübriid on skalaarsed väärtused, kuid koosneb kahest komponendist:

• Esimene on unix’i ajastu (kui palju sekundeid on möödunud "arvutimaailma algusest").
• Teiseks – teatav inkrement, samuti 32-bitine unsigned int.

See ongi kõik. On olemas lähenemine: osa, mis vastutab aja eest, sünkroonib pidevalt kelladega; iga kord, kui toimub uuendus, sünkroonitakse see osa kelladega ja tulemuseks on, et aeg on enam-vähem õige, samas kui inkrement võimaldab eristada sündmusi, mis toimusid samal hetkel.

Miks on see oluline 'MongoDB'-le? Sest see võimaldab teha mingit tüüpi varukoopiaid kindlal ajahetkel, st sündmus indekseeritakse ajaga. See on oluline, kui on vaja teatud sündmusi; andmebaasi jaoks on sündmused andmebaasis toimunud muudatused, mis on toimunud teatud aja jooksul.

Ma ütlen teile vaid kõige olulisema põhjuse (palun, ärge öelge seda kellelegi)! Me tegime seda, kuna just niimoodi näevad välja järjestatud, indekseeritud andmed MongoDB OpLog-is. OpLog on andmestruktuur, mis sisaldab kõiki muudatusi andmebaasis: need lähevad esmalt OpLog-i ja seejärel rakendatakse neid juba Storage'ile, kui tegemist on replikatsioonitud andmete või sharding'iga.

See oli peamine põhjus. On olemas ka praktilised nõuded andmebaasi arendusele, mis tähendab, et see peab olema lihtne – võimalikult vähe koodi ja võimalikult vähe katki minevaid asju, mida tuleb ümber kirjutada ja testida. Et meie OpLogid osutusid hübriidhäälte poolt indekseerituks, aitas see palju ja võimaldas teha õiged valikud. See tõeliselt tasus end ära ja töötas kuidagi maagiliselt, juba esimesel prototüübil. Oli tõeliselt äge!

Kellade sünkroniseerimine

Teaduslikus kirjanduses on kirjeldatud mitmeid kellade sünkroniseerimise meetodeid. Räägin sünkroniseerimisest siis, kui meil on kaks erinevat shard'i. Kui on üks replika komplekt – ei ole mingit sünkroniseerimist vaja: see on 'ühe meistri' situatsioon; meil on OpLog, kuhu kõik muudatused satuvad – sel juhul on kõik juba järjestatud 'OpLog'is'. Kuid kui meil on kaks erinevat shard'i, on siin aja sünkroniseerimine oluline. Siin aitasid meile vektorkellad rohkem! Kuid meil neid ei ole.

Teine sobiv variant on „Südamelöögid“ (Heartbeats). Sa saad jagada teatud signaale, mis toimuvad igas ajaühikus. Kuid „Südamelöögid“ on liiga aeglased, me ei saa oma kliendile latentsust tagada.

Tõeline aeg on loomulikult imeasi. Kuid see on tõenäoliselt tulevik… Kuigi „Atlases“ on juba võimalik kasutada kiireid „Amazoni“ ajasünkronisaatoreid. Kuid see ei ole kõigile kergesti kättesaadav.

Kahese suhtlemine tähendab, et kõik sõnumid sisaldavad aega. See on umbes see, mida me kasutame. Iga sõnum node'ide vahel, draiver, router, andme-node, absoluutselt kõik MongoDB jaoks – need on mingid elemendid, andmebaasi komponendid, mis sisaldavad endas kellasid, mis kulgevad. Igal pool on hübriidaja väärtus, see edastatakse. 64 bitti? See on võimalik, see töötab.

Kuidas see kõik koos töötab?

Siin arenen lihtsustatult ühte replikatsioonisetti. On olemas Primary ja Secondary. Secondary teeb replikatsiooni ja ei ole alati täielikult sünkroonitud Primaryga.

Tegemist on aja väärtuse sisestamisega 'Prymerys'. See sisestamine suurendab sisemist loendurit kuni 11, kui see on maksimaalne. Vastasel juhul kontrollib see tunni väärtusi ja sünkroniseerib need, kui tunni väärtused on suuremad. See võimaldab korraldada ajaliselt.

Pärast salvestamist toimub oluline hetk. Tunnid 'MongoDBs' suurenevad ainult siis, kui salvestus toimub 'OpLogis'. Just see on sündmus, mis muudab süsteemi seisundit. Kõikides klassikalistes artiklites loetakse sündmuseks sõnumi jõudmist nodi: sõnum on saabunud – see tähendab, et süsteem on muutnud oma seisundit.

See tuleneb sellest, et uurimise käigus ei saa alati aru, kuidas seda sõnumit tõlgendatakse. Me teame täpselt, et kui see ei ole 'OpLogis' kajastatud, siis seda ei tõlgendata kuidagi, ja süsteemi seisundi muutmine on ainult salvestamine 'OpLogisse'. See lihtsustab meie jaoks kõike: nii mudelit kui ka võimalust korraldada ühes replikas komplektis, ja palju muud kasulikku.

Tagastatakse väärtus, mis on juba salvestatud "Oplogi" – me teame, et "Oplogis" on see väärtus olemas ja selle aeg on 12. Nüüd, ütleme, et lugemine algab teiselt sõlmpunktilt (Secondary) ja ta edastab juba afterClusterTime sõnumis. Ta ütleb: "Mul on vaja kõike, mis toimus vähemalt pärast 12 või täpselt kell kaksteist" (vt ülalolevat joonist).

See on see, mida nimetatakse Causal a consistent (CAT). On selline mõisted teoorias, et see on mingi ajas lõige, mis on enda jaoks järjepidev. Antud juhul võib öelda, et see on süsteemi olek, mida jälgiti ajahetkel 12.

Praegu pole siin veel midagi, sest see simuleerib olukorda, kus on vajalik, et Secondary kopeeriks andmeid Primarylt. Ta ootab... Ja nüüd on andmed saabunud – tagastab tagasi need väärtused.

Nii umbes kõik töötab. Peaaegu.

Mis tähendab «peaaegu»? Oletame, et on mingisugune inimene, kes on lugenud ja aru saanud, kuidas see kõik töötab. Ta mõistab, et iga kord toimub ClusterTime, see uuendab sisemisi loogilisi kelli, ja siis järgmine kirje suurendab seda ühe võrra. See funktsioon koosneb 20 reast. Oletame, et see inimene edastab maksimaalselt suure 64-bitise arvu, miinus üks.

Miks «miinus üks»? Sest et sisemised kellad seadistatakse sellele väärtusele (ilmne, et see on kõige suurem võimalik ja suurem praegusest ajast), siis toimub kirje «Opilogisse», ja kellad suurenevad veel ühe võrra – ning seal on juba maksimaalne väärtus (seal on lihtsalt kõik ühed, enam ei ole kuhugi minna, unsaint int’id).

Selge, et pärast seda muutub süsteem täiesti kättesaamatuks. Seda saab ainult väljastada, puhastada – palju käsitööd. Täielik availability:

Ja kui see veel kuhugi replitseeritakse, siis kukub kogu klaster lihtsalt kokku. Absoluutselt vastuvõetamatu olukord, mille iga inimene saab väga kiiresti ja lihtsalt korraldada! Seetõttu pidasime seda momenti üheks kõige olulisemaks. Kuidas seda ära hoida?

Meie tee on allkirjastada clusterTime

Nii see edastatakse sõnumis (kuni sinise tekstini). Kuid me hakkasime ka allkirja genereerima (sinine tekst):

Allkiri genereeritakse võtme abil, mis hoitakse andmebaasis, kaitstud perimeetriga; see genereeritakse ja uuendatakse (kasutajad ei näe seda). Genereeritakse hash ning iga sõnum allkirjastatakse loomise hetkel ja valideeritakse vastuvõtmise hetkel.
Inimestel võib tekkida küsimus: „Kui palju see kõik aeglustab?” Ma ütlesin, et see peab kiiresti töötama, eriti kui seda omadust pole.

Mida tähendab Causal consistency kasutamine antud juhul? See näitab afterClusterTime parameetrit. Ilma selleta edastatakse väärtusi igal juhul. Gossiping, alates versioonist 3.6, töötab alati.

Kui me jätame pideva allkirjade genereerimise, siis see aeglustab süsteemi isegi omaduse puudumisel, mis ei vasta meie lähenemistele ja nõudmistele. Ja mida me tegime?

Tee seda kiiresti!

Piisavalt lihtne asi, kuid trikk on huvitav – jagan, võib-olla on kellelegi huvitav.
Meil on hash, kus salvestatakse allkirjastatud andmed. Kõik andmed lähevad läbi cache'i. Cache ei allkirjasta mitte kindlat aega, vaid Range'i. Kui tuleb mingi väärtus, genereerime Range'i, varjame viimased 16 bitti ja allkirjastame selle väärtuse:

Saades sellise allkirja, kiirendame süsteemi (tinglikult) 65 000 korda. See töötab suurepäraselt: kui katseid tehti – siis kahanes aeg tõeliselt 10 000 korda, kui meil oli järjestikune uuendus. Selge on, et kui nad on erinevas järjekorras, siis see ei toimi. Kuid enamikus praktilistes juhtumites töötab see. Range'i allkirja kombinatsioon koos allkirjaga aitas lahendada turvalisuse probleemi.

Mida me õppisime?

Õppetunnid, mille me sellest saime:

• Tuleb lugeda materjale, lugusid, artikleid, sest meil on palju huvitavat. Kui töötame mingi funktsiooni kallal (eriti nüüd, kui me tegime tehinguid jne), tuleb lugeda, aru saada. See võtab aega, kuid see on tegelikult väga kasulik, sest saab aru, kus me oleme. Me ei ole nagu midagi uut välja mõelnud – lihtsalt võtsime koostisosad.

  Küsimus on üldiselt mõtteviisi erinevuses, kui tegemist on akadeemilise konverentsiga (näiteks 'Sigmon') – seal keskendutakse uutele ideedele. Mis on meie algoritmi uuenduslik? Siin ei ole suurt uudset. Uudsus seisneb pigem selles, kuidas me kokku segasime olemasolevaid lähenemisviise. Seetõttu tuleb esmalt lugeda klassikuid, alustades Lampardist.

• Tootmisprotsessis on täiesti teised nõudmised. Olen kindel, et paljud teist ei tegele mitte "sfääriliste" andmebaasidega abstraktses vaakumis, vaid tõeliste, normaalse elu probleemidega, kus esinevad availability, latency ja talitlushäired.
• Viimane – see, et pidime arvesse võtma erinevaid ideid ja kombineerima mitmeid täiesti erinevaid artikleid ühte lähenemisviisi. Näiteks allkirjastamise idee pärineb artiklist, mis käsitles Paxos protokolli, mis on mõeldud mitte-bütsantslike veakindlate süsteemide jaoks autoriseerimisprotokollis, bütsantslike jaoks aga autoriseerimisprotokollist väljaspool… Ühesõnaga, just seda me lõpuks ka tegime.

  Siin pole tõesti midagi uut! Aga kui me kõike koos segame... See on umbes sama, nagu öelda, et Olivier salati retsept on mõttetu, kuna munad, majonees ja kurgid on juba välja mõeldud... See on umbes sama lugu.

Sellega lõpetan. Aitäh!

Küsimused

Küsimus publikust (edasi – K): – Aitäh, Mihhail esitluse eest! Aeg teema on huvitav. Te kasutate Gossiping. Ütlesite, et kõigil on oma aeg, kõik tunnevad oma lokaalset aega. Ma sain aru, et meil on draiver – kliente koos draiveritega võib olla palju, ka query-planner’eid on palju, shard'eid on ka palju… Kuhu meie süsteem jõuab, kui äkki tekib lahknevus: keegi arvab, et ta on minut aega ees, keegi – minut aega taga? Kus me oleme?

MT: – Tegelikult väga hea küsimus! Ma tahtsin just shardeist rääkida. Kui ma õigesti aru saan küsimusest, siis meil on selline olukord: shard 1 ja shard 2, lugemine toimub nende kahe shard'i pealt – neil on lahknevus, nad ei suhtle omavahel, kuna aeg, mida nad tunnevad, on erinev, eriti aeg, mis nende logides eksisteerib.
Oletame, et shard 1 tegi miljon kirjet, shard 2 ei teinud üldse midagi, ja päring tuli kahele shardi. Ja esimesel on afterClusterTime üle miljoni. Sellises olukorras, nagu ma selgitasin, shard 2 ei vasta kunagi.

K: – Ma tahtsin teada, kuidas nad sünkroneeruvad ja valitakse üks loogiline aeg?

MT: – Väga lihtsalt sünkroneeritakse. Shard, kui sellele tuleb afterClusterTime ja ta ei leia aega 'Optlog'is – algatab no approved. See tähendab, et ta tõstab oma aega käsitsi sellele väärtusele. See näitab, et tal ei ole sündmusi, mis sellele päringule vastavad. Ta loob selle sündmuse kunstlikult ja muutub seeläbi Causal Consistent.

K: – Aga kui tema juurde pärast seda veel jõuavad mingid sündmused, mis kuskil võrgus kaduma läksid?

MT: – Shard on kujundatud nii, et need ei jõua enam, kuna see on single master. Kui ta on juba kirja pannud, siis need ei tule enam ja on pärast. Ei saa juhtuda nii, et kuskil midagi kinni jääb, siis ta teeb no write ja pärast jõuavad need sündmused – ja Causal consistency on rikutud. Kui ta teeb no write, siis kõik peavad edasi jõudma (ta ootab neid).

K: – Mul on mõned küsimused järjekordade kohta. Causal consistency eeldab, et on olemas teatud tegevuste järjekord, mida tuleb täita. Mis juhtub, kui meil kaob üks pakett? Siin tuli 10., 11.. 12. kaob ära, samas kui kõik teised ootavad, kuni see täidetakse. Ja äkki sureb meie masin, me ei saa midagi teha. Kas on olemas maksimaalne järjekorra pikkus, mis akumuleerub, enne kui see täidetakse? Milline fataalne viga toimub, kui mõni seisund kaob? Eriti kuna me salvestame, et on olemas mingi eelnevalt määratud seisund, millelt me peame kuidagi tuginema? Ja sellest ei saadudki tuge!

MT: – Samuti suurepärane küsimus! Mida me teeme? MongoDB-s on olemas kvoorumite kirjutamise ja lugemise kontseptsioon. Millal võib sõnum kaduma minna? Kui kirjutamine ei ole kvoorum või kui lugemine ei ole kvoorum (ka see võib osutuda mingiks prügiseks).
Seoses Causal consistency oleme läbi viinud ulatusliku eksperimentaalse kontrolli, mille tulemusena selgus, et juhul, kui kirjutamised ja lugemised on kvoorumita, tekivad Causal consistency rikkumised. Just nii, nagu te ütlete!

Meie soovitus: kasutada vähemalt kvoorumi lugemist, kui tegeletakse Causal consistency'ga. Sel juhul ei kao mitte midagi, isegi kui kvoorumi kirjutamine kaob... See on ortogonaalne olukord: kui kasutaja ei soovi, et andmed kaoksid, tuleb kasutada kvoorumi kirjutamist. Causal consistency ei anna püsivuse garantiid. Püsivuse garantii annab replikatsioon ja replikatsiooniga seotud masinavärk.

K: – Kui me loome instantsi, mida meie šardid teostavad (mitte master, vaid slave vastavalt), toetub see oma masina unix-ajale või «meistri» ajale; sünkroniseeritakse esmakordselt või perioodiliselt?

MT: – Praegu selgitan. Šard (tlk. horisontaalne partitsioon) – seal on alati Primaarne. Ja šardis võib olla «meister» ning võivad olla replikatsioonid. Kuid šard toetab alati kirjutamist, sest see peab toetama mingit domeeni (šardis on Primaarne).

K: – Nii et kõik sõltub täielikult «meistrist»? Kas alati kasutatakse «meistri» aega?

MT: – Jah. Võib öelda, et kell tiksub, kui toimub kirjutamine «meistrisse», «Oplogisse».

K: – Meil on klient, kellel on ühendus, ja tal ei ole vaja ajast midagi teada?

MT: – Ei ole vaja midagi teada! Kui rääkida, kuidas see kliendil töötab: kliendil, kui ta soovib kasutada Causal consistency, peab ta avama seansi. Praegu on seal kõik: ka tehingud seansis ja retrieve a rights... Seanss on loogiliste sündmuste järjestamine, mis toimub kliendiga.

Kui ta avab selle seansi ja ütleb, et soovib Causal consistency (kui seanss toetab Causal consistency vaikimisi), siis kõik töötab automaatselt. Juhtimisseade salvestab selle aja ja suurendab seda, kui saab uue sõnumi. Ta mäletab, millise vastuse eelmisel serverilt saadi, mis andmed tagastati. Järgmine päring sisaldab afterCluster ("aeg, mis on suurem kui see").

Kliendil ei ole vaja täiesti midagi teada! See on tema jaoks täiesti läbipaistmatu. Kui inimesed kasutavad neid funktsioone, mida see võimaldab? Esiteks, saab ohutult lugeda secondaries: saab kirjutada Primary'le ja lugeda geograafiliselt replitseeritud secondaries'ilt ning olla kindel, et see toimib. Samal ajal saab seanss, mis on salvestatud Primary'le, edastada isegi Secondary'le, st saab kasutada mitte ühte seanssi, vaid mitu.

K: – Teema Eventual consistency on tihedalt seotud uue taseme Compute science'iga – andmetüüpidega CRDT (Conflict-free Replicated Data Types). Kas olete kaalunud nende andmetüüpide integreerimist andmebaasi ja mida sellest arvate?

MT: – Hea küsimus! CRDT on mõistlik andmevahetuse konfliktide korral: MongoDB-s on see üksik meistreid.

K: – Mul on devopsidelt küsimus. Tõelises maailmas esinevad sellised jezuidlikud olukorrad, kus toimub byzantine failure ja kurjad inimesed kaitstud perimeetris hakkavad protokolli segama, saates spetsiaalselt koostatud pakette?

MT: – Kurjad inimesed perimeetris on nagu trooja hobune! Perimeetris olevad kurjad inimesed võivad teha palju halbu asju.

K: – Loomulikult on vale jätta serverisse, ütleme nii, auk, mille kaudu saab läbi lasta elevantide loomaaeda ja kogu klastrit igaveseks kokku varisemise… Käesolevaks taastamiseks on vajalik aeg… See on pehmelt öeldes vale. Teisest küljest, huvitav on, et päriselus, praktikas esinevad sarnased sisemised rünnakud?

MT: – Kuna ma ei puutu tihti kokku turvarikkumisega, ei saa ma öelda – võib-olla need tõesti juhtuvad. Aga kui rääkida arendajate filosoofiast, siis meie arvates on asi nii: meil on perimeeter, mis tagab turva, – see on lukud, sein; ja perimeetri sees võib teha kõike, mida soovid. Loomulikult on kasutajaid, kellel on vaid vaatamisõigus, ja on ka kasutajaid, kellel on õigus katalooge kustutada.

Sõltuvalt õigustest võib kasutaja tekitada kahju kas hiirega või isegi elevandiga. On selge, et kasutaja täieõiguslike õigustega saab teha kõik, mida soovib. Kasutaja, kelle õigused on piiratud, võib tekitada oluliselt vähem kahju. Eelkõige ei saa ta süsteemi purustada.

K: – Kaitstud perimeetri sees võib keegi hakata vormima ootamatuid protokolle serveri jaoks, et serverit nurka suruda, ja kui vedasi, siis võib kogu klaster… Kas selliseid olukordi ka juhtub?

MT: – Ma ei ole kunagi sellistest asjadest kuulnud. Et serverit saab niimoodi kokku kukutada – see ei ole saladus. Kukkuda seespool, olles protokollist, kui autoriseeritud kasutaja, kes saab sõnumisse midagi sellist kirjutada... Tegelikult ei saa, sest see peab ikkagi valideeruma. On võimalus keelata see autentimine kasutajatele, kes ei soovi – see siis on nende probleem; nad on, n-ö, ise seinad lõhkunud ja sinna saab sisestada elevandi, kes kõik tallab... Ja tegelikult, võib end remontijana riidesse panna, tulla ja välja võtta!

K: – Aitäh ettekande eest. Sergei („Yandex”). „Monges” on konstandina, mis piirab hääletavate liikmete arvu Replica Set’is, ja see konstant on 7 (seitsme). Miks see on konstant? Miks see ei ole mingi parameeter?

MT: – Replica Set on meil ka 40 noodiga. Seal on alati enamuse reegel. Ma ei tea, mis versioon see on…

K: – Replica Set’is võib olla ka hääletamata liikmeid, kuid hääletavate – maksimaalselt 7. Kuidas sel juhul taluda väljalülitamist, kui meil Replica Set on hajutatud kolme andmekeskuse peale? Üks andmekeskus võib lihtsalt välja lülituda ja üks masin veel välja langeda.

MT: – See on juba veidi väljaspool ettekannet. See on üldine küsimus. Võib-olla saan sellest hiljem rääkida.

Veidi reklaami 🙂

Aitäh, et olete meiega. Kas teile meeldivad meie artiklid? Kas soovite näha rohkem huvitavaid materjale? Toetage meid, tehes tellimuse või soovitades meid tuttavatele. pilve VPS arendajatele alates $4,99, ainulaadne sisenemise taseme serverite analoog, mille oleme teie jaoks välja mõelnud: Kogu tõde VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps alates $19 või kuidas õieti serverit jagada? (saadaval on RAID1 ja RAID10 variandid, kuni 24 südamikku ja kuni 40GB DDR4).

Kas Dell R730xd on kaks korda odavam Equinixi Tier IV andmete keskuses Amsterdamis? Ainult meie juures 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TB alates $199 Hollandi turul! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — alates $99! Lugege, kuidas Luua ettevõtte tasemel infrastruktuur Dell R730xd E5-2650 v4 serveritega, mille hind on 9000 eurot, madala hinnaga?

Allikas: habr.com