Seuraava HighLoad++-konferenssi järjestetään 6. ja 7 Pietarissa.
Lisätiedot ja liput . HighLoad++ Siperia 2019. Hall "Krasnojarsk". 25. kesäkuuta klo 12. Opinnäytetyöt ja .
Käytännön vaatimukset ovat ristiriidassa teorian kanssa, jolloin kaupallisen tuotteen kannalta tärkeitä näkökohtia ei oteta huomioon. Tämä puhe esittelee prosessin erilaisten lähestymistapojen valitsemiseksi ja yhdistämiseksi kausaalisen johdonmukaisuuden komponenttien luomiseksi kaupallisen tuotteen vaatimuksiin perustuvan akateemisen tutkimuksen perusteella. Kuuntelijat oppivat olemassa olevista teoreettisista lähestymistavoista loogisiin kelloihin, riippuvuuden seurantaan, järjestelmän turvallisuuteen, kellon synkronointiin ja miksi MongoDB päätyi tiettyihin ratkaisuihin.
Mihail Tyulenev (jäljempänä MT): – Puhun kausaalista johdonmukaisuudesta – tämä on ominaisuus, jota olemme työstäneet MongoDB:ssä. Työskentelen hajautettujen järjestelmien ryhmässä, teimme sen noin kaksi vuotta sitten.
Tässä prosessissa jouduin tutustumaan paljon akateemiseen tutkimukseen, koska tätä ominaisuutta on tutkittu melko hyvin. Kävi ilmi, että yksikään artikkeli ei mahdu siihen, mitä tuotantotietokannassa vaaditaan, johtuen hyvin erityisistä vaatimuksista, joita todennäköisesti esiintyy missä tahansa tuotantosovelluksessa.
Puhun siitä, kuinka me akateemisen tutkimuksen kuluttajina valmistamme siitä jotain, jonka voimme sitten esittää käyttäjillemme valmiina, kätevänä ja turvallisena annoksena.
Kausaalinen johdonmukaisuus. Määrittelemme käsitteet
Aluksi haluan sanoa yleisesti, mitä kausaalinen johdonmukaisuus on. Siinä on kaksi hahmoa - Leonard ja Penny (TV-sarja "The Big Bang Theory"):
Oletetaan, että Penny on Euroopassa ja Leonard haluaa järjestää hänelle yllätysjuhlat. Ja hän ei voi ajatella mitään parempaa kuin heittää hänet pois ystävälistaltaan ja lähettää kaikille ystävilleen syötepäivityksen: "Tehdään Penny onnelliseksi!" (hän on Euroopassa, kun hän nukkuu, hän ei näe kaikkea tätä eikä voi nähdä sitä, koska hän ei ole siellä). Lopulta hän poistaa tämän viestin, poistaa sen syötteestä ja palauttaa pääsyn, jotta hän ei huomaa mitään ja ettei synny skandaalia.
Tämä on kaikki hyvin, mutta oletetaan, että järjestelmä on hajautettu ja asiat menivät hieman pieleen. Saattaa esimerkiksi käydä niin, että Pennyn pääsyrajoitus tapahtui tämän postauksen ilmestymisen jälkeen, jos tapahtumat eivät liity toisiinsa syyn ja seurauksen perusteella. Itse asiassa tämä on esimerkki siitä, kun kausaalista johdonmukaisuutta vaaditaan liiketoimintatoiminnon suorittamiseksi (tässä tapauksessa).
Itse asiassa nämä ovat melko ei-triviaaleja tietokannan ominaisuuksia - hyvin harvat ihmiset tukevat niitä. Siirrytään malleihin.
Johdonmukaisuusmallit
Mikä tietokantojen johdonmukaisuusmalli oikein on? Nämä ovat joitain takuita, jotka hajautettu järjestelmä antaa siitä, mitä dataa asiakas voi vastaanottaa ja missä järjestyksessä.
Periaatteessa kaikki johdonmukaisuusmallit menevät siihen, kuinka samanlainen hajautettu järjestelmä on järjestelmälle, joka toimii esimerkiksi kannettavan tietokoneen yhdessä solmussa. Ja näin samanlainen järjestelmä, joka toimii tuhansilla maantieteellisesti hajautetuilla "solmuilla", on kannettava tietokone, jossa kaikki nämä ominaisuudet suoritetaan periaatteessa automaattisesti.
Siksi johdonmukaisuusmalleja sovelletaan vain hajautetuissa järjestelmissä. Kaikissa järjestelmissä, jotka olivat aiemmin olemassa ja toimivat samalla pystyskaalalla, ei esiintynyt tällaisia ongelmia. Siellä oli yksi puskurivälimuisti, ja kaikki luettiin aina siitä.
Malli Vahva
Itse asiassa aivan ensimmäinen malli on Strong (tai nousukykylinja, kuten sitä usein kutsutaan). Tämä on johdonmukaisuusmalli, joka varmistaa, että jokainen muutos, kun se on vahvistettu, näkyy kaikille järjestelmän käyttäjille.
Tämä luo globaalin järjestyksen kaikista tietokannan tapahtumista. Tämä on erittäin vahva johdonmukaisuusominaisuus, ja se on yleensä erittäin kallis. Se on kuitenkin erittäin hyvin tuettu. Se on vain erittäin kallis ja hidas - sitä käytetään vain harvoin. Tätä kutsutaan nousukyvyksi.
On toinen, vahvempi ominaisuus, jota tuetaan Spannerissa - nimeltään Ulkoinen johdonmukaisuus. Puhumme siitä hieman myöhemmin.
kausaalinen
Seuraava on Causal, josta juuri puhuin. Vahvan ja kausaalin välillä on useita muita alatasoja, joista en puhu, mutta ne kaikki tiivistyvät kausaaliin. Tämä on tärkeä malli, koska se on vahvin kaikista malleista, vahvin johdonmukaisuus verkon tai osioiden läsnä ollessa.
Syy-seuraus on itse asiassa tilanne, jossa tapahtumia yhdistää syy-seuraus-suhde. Hyvin usein ne nähdään "lue oikeuksiasi" asiakkaan näkökulmasta. Jos asiakas on havainnut joitain arvoja, hän ei voi nähdä arvoja, jotka olivat menneisyydessä. Hän alkaa jo nähdä etuliitteen lukemat. Kaikki johtuu samasta asiasta.
Kausaalit johdonmukaisuusmallina on tapahtumien osittainen järjestys palvelimella, jossa kaikkien asiakkaiden tapahtumia havaitaan samassa järjestyksessä. Tässä tapauksessa Leonard ja Penny.
lopullinen
Kolmas malli on lopullinen johdonmukaisuus. Tätä ehdottomasti kaikki hajautetut järjestelmät tukevat, minimaalinen malli, joka on ylipäätään järkevä. Se tarkoittaa seuraavaa: kun meillä on joitain muutoksia tiedoissa, ne jossain vaiheessa muuttuvat johdonmukaisiksi.
Sillä hetkellä hän ei sano mitään, muuten hän muuttuisi ulkoiseksi johdonmukaisuudeksi - se olisi täysin erilainen tarina. Siitä huolimatta tämä on erittäin suosittu malli, yleisin. Oletuksena kaikki hajautettujen järjestelmien käyttäjät käyttävät Eventual Consistency -toimintoa.
Haluan antaa muutamia vertailevia esimerkkejä:
Mitä nämä nuolet tarkoittavat?
- Viive. Kun johdonmukaisuuden vahvuus kasvaa, se kasvaa ilmeisistä syistä: sinun täytyy tehdä enemmän tietueita, saada vahvistus kaikilta klusteriin osallistuvilta isänniltä ja solmuilta, että data on jo olemassa. Näin ollen Eventual Consistencylla on nopein vastaus, koska siellä sen voi pääsääntöisesti jopa tallentaa muistiin ja tämä periaatteessa riittää.
- Saatavuus. Jos ymmärrämme tämän järjestelmän kyvynä reagoida verkkokatkosten, osioiden tai jonkinlaisen vian esiintyessä, vikasietokyky kasvaa johdonmukaisuusmallin heikkeneessä, koska meille riittää, että yksi isäntä elää ja samalla. aika tuottaa jotain dataa. Lopullinen johdonmukaisuus ei takaa tiedoista mitään – se voi olla mitä tahansa.
- Anomaliat. Samalla tietysti poikkeamien määrä kasvaa. Strong Consistenssissa niitä ei melkein pitäisi olla ollenkaan, mutta Lopullisessa johdonmukaisuudessa ne voivat olla mitä tahansa. Herää kysymys: miksi ihmiset valitsevat Lopullisen johdonmukaisuuden, jos se sisältää poikkeavuuksia? Vastaus on, että Lopullisen johdonmukaisuuden mallit ovat sovellettavissa ja poikkeavuuksia esiintyy esimerkiksi lyhyessä ajassa; ohjattua toimintoa voidaan käyttää johdonmukaisten tietojen lukemiseen ja enemmän tai vähemmän lukemiseen; Usein on mahdollista käyttää vahvan johdonmukaisuuden malleja. Käytännössä tämä toimii, ja usein poikkeamien määrä on ajallisesti rajoitettu.
CAP-lause
Kun näet sanat johdonmukaisuus, saatavuus – mitä sinulle tulee mieleen? Aivan oikein - CAP-lause! Nyt haluan hälventää myytin... Se en ole minä - se on Martin Kleppmann, joka kirjoitti upean artikkelin, upean kirjan.
CAP-lause on 2000-luvulla muotoiltu periaate, että johdonmukaisuus, saatavuus, osiot: ota mitkä tahansa kaksi, etkä voi valita kolmea. Se oli tietty periaate. Gilbert ja Lynch osoittivat sen lauseeksi muutamaa vuotta myöhemmin. Sitten tätä alettiin käyttää mantrana - järjestelmät alkoivat jakaa CA: ksi, CP: ksi, AP: ksi ja niin edelleen.
Tämä lause itse asiassa todistettiin seuraaviin tapauksiin... Ensinnäkin käytettävyyttä ei pidetty jatkuvana arvona nollasta satoihin (0 - järjestelmä on "kuollut", 100 - reagoi nopeasti; olemme tottuneet ajattelemaan sitä niin) , mutta algoritmin ominaisuutena, joka takaa, että se palauttaa tiedot kaikista suorituksistaan.
Vastausajasta ei puhuta sanaakaan! On olemassa algoritmi, joka palauttaa tiedot 100 vuoden kuluttua - aivan loistava käytettävissä oleva algoritmi, joka on osa CAP-lausetta.
Toiseksi: lause todistettiin saman avaimen arvojen muutoksille huolimatta siitä, että näiden muutosten kokoa voidaan muuttaa. Tämä tarkoittaa, että todellisuudessa niitä ei käytännössä käytetä, koska mallit ovat erilaisia Lopullinen johdonmukaisuus, Vahva johdonmukaisuus (ehkä).
Mitä varten tämä kaikki on? Lisäksi CAP-lause täsmälleen siinä muodossa, jossa se todistettiin, ei käytännössä sovellu ja sitä käytetään harvoin. Teoreettisessa muodossa se jotenkin rajoittaa kaikkea. Osoittautuu tietty periaate, joka on intuitiivisesti oikea, mutta yleisesti sitä ei ole todistettu.
Kausaalinen johdonmukaisuus on vahvin malli
Nyt tapahtuu, että voit saada kaikki kolme asiaa: johdonmukaisuus, saatavuus osioiden avulla. Erityisesti kausaalinen johdonmukaisuus on vahvin johdonmukaisuusmalli, joka toimii edelleen osioiden (verkon katkosten) läsnä ollessa. Siksi se kiinnostaa niin paljon, ja siksi otimme sen käyttöön.
Ensinnäkin se yksinkertaistaa sovelluskehittäjien työtä. Erityisesti palvelimen suuri tuki: kun kaikki yhden asiakkaan sisällä esiintyvät tietueet saapuvat taatusti samassa järjestyksessä toiselle asiakkaalle. Toiseksi se kestää osioita.
MongoDB sisäinen keittiö
Muistaen, että on lounas, siirrymme keittiöön. Kerron sinulle järjestelmämallista, eli mitä MongoDB on niille, jotka kuulevat tällaisesta tietokannasta ensimmäistä kertaa.
MongoDB (jäljempänä "MongoDB") on hajautettu järjestelmä, joka tukee vaakasuuntaista skaalausta eli sirpalointia; ja jokaisessa sirpaleessa se tukee myös tietojen redundanssia eli replikointia.
Jakaminen MongoDB:ssä (ei relaatiotietokanta) suorittaa automaattisen tasapainotuksen, eli jokainen dokumenttikokoelma (tai "taulukko" relaatiotietojen suhteen) jaetaan osiin, ja palvelin siirtää ne automaattisesti sirpaleiden välillä.
Kyselyreititin, joka jakaa pyyntöjä asiakkaalle, on asiakas, jonka kautta se toimii. Se tietää jo missä ja mitä tietoja sijaitsee ja ohjaa kaikki pyynnöt oikeaan sirpaleeseen.
Toinen tärkeä kohta: MongoDB on yksi mestari. On yksi ensisijainen - se voi ottaa tietueita, jotka tukevat sen sisältämiä avaimia. Et voi kirjoittaa Multi-master-kirjoitusta.
Teimme julkaisun 4.2 - siellä ilmestyi uusia mielenkiintoisia asioita. Erityisesti he lisäsivät Lucenen - haun - eli suoritettavan javan suoraan Mongoon, ja siellä tuli mahdolliseksi tehdä hakuja Lucenen kautta, samoin kuin Elasticassa.
Ja he tekivät uuden tuotteen - Charts, se on saatavilla myös Atlasissa (Mongon oma pilvi). Heillä on ilmainen taso - voit leikkiä sen kanssa. Pidin todella kaavioista - tietojen visualisointi, erittäin intuitiivinen.
Ainesosat Kausaalinen johdonmukaisuus
Laskin noin 230 artikkelia, jotka on julkaistu tästä aiheesta - Leslie Lampertilta. Nyt välitän teille muististani joitakin osia näistä materiaaleista.
Kaikki alkoi Leslie Lampertin artikkelista, joka kirjoitettiin 1970-luvulla. Kuten näette, tutkimusta aiheesta on edelleen käynnissä. Nyt Causal johdonmukaisuus herättää kiinnostusta hajautettujen järjestelmien kehityksen yhteydessä.
Rajoitukset
Mitä rajoituksia on? Tämä on itse asiassa yksi pääkohdista, koska tuotantojärjestelmän asettamat rajoitukset ovat hyvin erilaisia kuin akateemisissa artikkeleissa esiintyvät rajoitukset. Ne ovat usein melko keinotekoisia.
- Ensinnäkin "MongoDB" on yksi mestari, kuten jo sanoin (tämä yksinkertaistaa huomattavasti).
- Uskomme, että järjestelmän pitäisi tukea noin 10 tuhatta sirpaleita. Emme voi tehdä arkkitehtonisia päätöksiä, jotka nimenomaisesti rajoittavat tätä arvoa.
- Meillä on pilvi, mutta oletamme, että ihmisellä pitäisi silti olla mahdollisuus, kun hän lataa binaaritiedostoa, käyttää sitä kannettavassa tietokoneessaan ja kaikki toimii hyvin.
- Oletamme jotain, mitä Research harvoin olettaa: ulkopuoliset asiakkaat voivat tehdä mitä haluavat. MongoDB on avoin lähdekoodi. Näin ollen asiakkaat voivat olla niin älykkäitä ja vihaisia - he voivat haluta rikkoa kaiken. Arvelemme, että bysanttilaiset feilorit voivat olla peräisin.
- Ulkoisille asiakkaille, jotka ovat kehän ulkopuolella, on tärkeä rajoitus: jos tämä ominaisuus on poistettu käytöstä, suorituskyvyn heikkenemistä ei pitäisi havaita.
- Toinen seikka on yleisesti antiakateeminen: aikaisempien ja tulevien versioiden yhteensopivuus. Vanhojen ohjainten on tuettava uusia päivityksiä ja tietokannan on tuettava vanhoja ohjaimia.
Yleensä kaikki tämä asettaa rajoituksia.
Kausaalisen johdonmukaisuuden komponentit
Puhun nyt joistakin komponenteista. Jos tarkastelemme kausaalista johdonmukaisuutta yleisesti, voimme valita lohkoja. Valitsimme teoksista, jotka kuuluvat tiettyyn lohkoon: Riippuvuusseuranta, kellojen valinta, kuinka nämä kellot voidaan synkronoida keskenään ja kuinka varmistamme turvallisuuden - tämä on karkea hahmotelma siitä, mistä puhun:
Täysi riippuvuuden seuranta
Miksi sitä tarvitaan? Joten kun tietoja replikoidaan, jokainen tietue, jokainen datamuutos sisältää tietoa siitä, mistä muutoksista se riippuu. Aivan ensimmäinen ja naiivi muutos on, kun jokainen tietueen sisältävä viesti sisältää tietoja aiemmista viesteistä:
Tässä esimerkissä suluissa oleva numero on tietuenumerot. Joskus nämä tietueet arvoineen siirretään jopa kokonaisuudessaan, joskus joitain versioita siirretään. Tärkeintä on, että jokainen muutos sisältää tietoa edellisestä (ilmeisesti kantaa kaiken tämän sisällään).
Miksi päätimme olla käyttämättä tätä lähestymistapaa (täysi seuranta)? Ilmeisesti, koska tämä lähestymistapa on epäkäytännöllinen: kaikki sosiaaliseen verkostoon tehtävät muutokset riippuvat kaikista aiemmista muutoksista kyseiseen sosiaaliseen verkostoon, jolloin esimerkiksi Facebook tai VKontakte siirretään jokaisessa päivityksessä. Siitä huolimatta täyden riippuvuuden seurannasta on tehty paljon tutkimusta – nämä ovat esisosiaalisia verkostoja; joissakin tilanteissa se todella toimii.
Selkeä riippuvuuden seuranta
Seuraava on rajoitetumpi. Tässä huomioidaan myös tiedon siirto, mutta vain se, mikä on selvästi riippuvaista. Mikä riippuu siitä, mitä pääsääntöisesti määrittää Sovellus. Kun tietoja replikoidaan, kysely palauttaa vastaukset vain, kun aiemmat riippuvuudet on täytetty, eli näytetään. Tämä on kausaalisen johdonmukaisuuden toiminnan ydin.
Hän näkee, että tietue 5 riippuu tietueista 1, 2, 3, 4 - vastaavasti hän odottaa ennen kuin asiakas pääsee käsiksi Pennyn pääsypäätöksellä tehtyihin muutoksiin, kun kaikki aiemmat muutokset ovat jo kulkeneet tietokannan läpi.
Tämä ei myöskään sovi meille, koska tietoa on vielä liikaa ja se hidastaa toimintaa. On toinenkin lähestymistapa...
Lamportin kello
He ovat hyvin vanhoja. Lamport-kello tarkoittaa, että nämä riippuvuudet taitetaan skalaarifunktioksi, jota kutsutaan Lamport-kelloksi.
Skalaarifunktio on jokin abstrakti luku. Sitä kutsutaan usein loogiseksi ajaksi. Jokaisella tapahtumalla tämä laskuri kasvaa. Laskuri, joka on tällä hetkellä prosessin tiedossa, lähettää jokaisen viestin. On selvää, että prosessit voivat olla eri tahdissa, niillä voi olla täysin eri ajat. Siitä huolimatta järjestelmä jollakin tavalla tasapainottaa kellon tällaisella viestillä. Mitä tässä tapauksessa tapahtuu?
Jaoin tuon suuren sirpaleen kahteen selvemmäksi: Ystävät voivat asua yhdessä solmussa, joka sisältää osan kokoelmasta, ja Feed voi asua toisessa solmussa, joka sisältää osan tästä kokoelmasta. Onko selvää, kuinka he voivat erota rivistä? Ensimmäisessä syötteessä lukee "Replicated" ja sitten Ystävät. Jos järjestelmä ei anna jonkinlaista takuuta siitä, että syötettä ei näytetä ennen kuin myös Friends-kokoelman Friends-riippuvuudet on toimitettu, niin meillä on juuri mainitsemani tilanne.
Näet kuinka syötteen laskuriaika kasvaa loogisesti:
Joten tämän Lamport-kellon ja kausaalin johdonmukaisuuden pääominaisuus (selitetty Lamport-kellon kautta) on tämä: jos meillä on tapahtumat A ja B ja tapahtuma B riippuu tapahtumasta A*, niin tapahtuman A looginen aika on pienempi kuin Looginen aika tapahtumasta B.
* Joskus he myös sanovat, että A tapahtui ennen B:tä, eli A tapahtui ennen B:tä - tämä on tietty suhde, joka järjestää osittain koko tapahtumajoukon, joka tapahtui yleisesti.
Päinvastoin on väärin. Tämä on itse asiassa yksi Lamport Clockin suurimmista haitoista - osittainen tilaus. On olemassa käsite samanaikaisista tapahtumista, eli tapahtumista, joissa (A ei tapahtunut ennen B:tä) eikä (A tapahtunut ennen B:tä). Esimerkki olisi Leonardin rinnakkainen lisäys jonkun muun ystäväksi (ei edes Leonardia, vaan esimerkiksi Sheldonia).
Tätä ominaisuutta käytetään usein Lamport-kellojen kanssa työskennellessä: ne katsovat erityisesti toimintoa ja päättelevät tästä, että nämä tapahtumat ovat ehkä riippuvaisia. Koska yksi tapa on totta: jos LooginenAika A on pienempi kuin LooginenAika B, niin B ei voi tapahtua ennen A:ta; ja jos enemmän, niin ehkä.
Vector kello
Lamport-kellon looginen kehitys on Vector Clock. Ne eroavat toisistaan siinä, että jokainen tässä oleva solmu sisältää oman erillisen kellonsa ja ne lähetetään vektorina.
Tässä tapauksessa näet, että vektorin nollaindeksi on vastuussa syötteestä ja vektorin ensimmäinen indeksi on ystäville (jokainen näistä solmuista). Ja nyt ne kasvavat: "Syötteen" nollaindeksi kasvaa kirjoitettaessa - 1, 2, 3:
Miksi Vector Clock on parempi? Koska niiden avulla voit selvittää, mitkä tapahtumat ovat samanaikaisia ja milloin ne tapahtuvat eri solmuissa. Tämä on erittäin tärkeää MongoDB:n kaltaiselle jakojärjestelmälle. Emme kuitenkaan valinneet tätä, vaikka se on ihana asia, ja se toimii loistavasti, ja se varmaan sopisi meille...
Jos meillä on 10 tuhatta sirpaleita, emme voi siirtää 10 tuhatta komponenttia, vaikka pakkaamme sen tai keksimme jotain muuta - hyötykuorma on silti useita kertoja pienempi kuin tämän koko vektorin tilavuus. Siksi hylkäsimme tämän lähestymistavan, puristaen sydäntämme ja hampaitamme, ja siirryimme toiseen.
Jakoavain TrueTime. Atomi kello
Sanoin, että siellä olisi tarina Spannerista. Tämä on hieno asia, suoraan XNUMX-luvulta: atomikellot, GPS-synkronointi.
Mikä on idea? "Spanner" on Googlen järjestelmä, joka tuli hiljattain jopa ihmisten saataville (he lisäsivät siihen SQL:n). Jokaisella tapahtumalla on aikaleima. Koska aika on synkronoitu*, jokaiselle tapahtumalle voidaan määrittää tietty aika - atomikelloilla on odotusaika, jonka jälkeen "tapahtuu" taatusti eri aika.
Näin ollen yksinkertaisesti kirjoittamalla tietokantaan ja odottamalla jonkin aikaa, tapahtuman serialoitavuus taataan automaattisesti. Heillä on vahvin periaatteessa kuviteltavissa oleva johdonmukaisuusmalli - se on ulkoinen johdonmukaisuus.
* Tämä on Lampart-kellojen suurin ongelma - ne eivät ole koskaan synkronisia hajautetuissa järjestelmissä. Ne voivat poiketa toisistaan; edes NTP:n kanssa ne eivät silti toimi kovin hyvin. "Spannerissa" on atomikello ja synkronointi näyttää olevan mikrosekuntia.
Miksi emme valinneet? Emme oleta, että käyttäjillämme on sisäänrakennettu atomikello. Kun ne ilmestyvät jokaiseen kannettavaan tietokoneeseen sisäänrakennettuna, tulee jonkinlainen superhieno GPS-synkronointi - sitten kyllä... Mutta toistaiseksi paras mahdollinen on Amazon, tukiasemat - fanaatikkoille... Käytimme siis muita kelloja .
Hybridikello
Tämä on itse asiassa se, mikä tikittää MongoDB:ssä, kun varmistetaan kausaalisen johdonmukaisuus. Miten ne ovat hybridejä? Hybridi on skalaariarvo, mutta siinä on kaksi osaa:
- Ensimmäinen on Unix-aikakausi (kuinka monta sekuntia on kulunut "tietokonemaailman alusta").
- Toinen on jonkin verran lisäystä, myös 32-bittinen allekirjoittamaton int.
Siinä kaikki, oikeastaan. On tämä lähestymistapa: ajasta vastaava osa on synkronoitu kellon kanssa koko ajan; aina kun päivitys tapahtuu, tämä osa synkronoidaan kellon kanssa ja käy ilmi, että aika on aina enemmän tai vähemmän oikea, ja lisäyksen avulla voit erottaa tapahtumat, jotka tapahtuivat samaan aikaan.
Miksi tämä on tärkeää MongoDB:lle? Koska sen avulla voit tehdä jonkinlaisia vararavintoloita tietyllä hetkellä, eli tapahtuma indeksoidaan ajan mukaan. Tämä on tärkeää, kun tiettyjä tapahtumia tarvitaan; Tietokannassa tapahtumat ovat muutoksia tietokannassa, jotka tapahtuivat tietyin aikavälein.
Kerron sinulle tärkeimmän syyn vain sinulle (älä kerro kenellekään)! Teimme tämän, koska tältä organisoitu, indeksoitu data näyttää MongoDB OpLogissa. OpLog on tietorakenne, joka sisältää ehdottoman kaikki tietokannan muutokset: ne menevät ensin OpLogiin ja sitten niitä sovelletaan itse tallennustilaan, jos kyseessä on replikoitu päivämäärä tai sirpale.
Tämä oli tärkein syy. Tietokannan kehittämiseen liittyy kuitenkin myös käytännön vaatimuksia, mikä tarkoittaa, että sen tulee olla yksinkertainen - vähän koodia, mahdollisimman vähän rikkinäisiä asioita, joita pitää kirjoittaa ja testata. Se, että oplogimme indeksoitiin hybridikelloilla, auttoi paljon ja antoi meille mahdollisuuden tehdä oikean valinnan. Se todella kannatti ja toimi jotenkin maagisesti aivan ensimmäisen prototyypin kanssa. Se oli erittäin siistiä!
Kellon synkronointi
Tieteellisessä kirjallisuudessa on kuvattu useita synkronointimenetelmiä. Puhun synkronoinnista, kun meillä on kaksi erilaista sirpaletta. Jos kopiojoukkoa on yksi, synkronointia ei tarvita: tämä on "yksi isäntä"; meillä on OpLog, johon kaikki muutokset kuuluvat - tässä tapauksessa kaikki on jo järjestetty peräkkäin itse "Oplogissa". Mutta jos meillä on kaksi erilaista sirpaletta, ajan synkronointi on tärkeää. Tässä vektorikello auttoi enemmän! Mutta meillä ei ole niitä.
Toinen sopii - tämä on "Heartbeats". On mahdollista vaihtaa joitain signaaleja, jotka esiintyvät joka aikayksikössä. Mutta Heartbeats ovat liian hitaita, emme voi tarjota viivettä asiakkaallemme.
Todellinen aika on tietysti hieno asia. Mutta jälleen kerran, tämä on luultavasti tulevaisuutta... Vaikka se voidaan tehdä jo Atlasissa, on jo olemassa nopeita "Amazon" -aikasynkronoijia. Mutta se ei ole kaikkien saatavilla.
Juoruilu on sitä, kun kaikki viestit sisältävät aikaa. Tämä on suunnilleen mitä käytämme. Jokainen viesti solmujen välillä, ohjain, datasolmureititin, ehdottomasti kaikki MongoDB:lle on jonkinlainen elementti, tietokantakomponentti, joka sisältää kellon, joka toimii. Niillä on hybridiajan merkitys kaikkialla, se välittyy. 64 bittiä? Tämä mahdollistaa, tämä on mahdollista.
Miten se kaikki toimii yhdessä?
Tässä katson yhtä kopiosarjaa helpottaakseni sitä. On ensisijainen ja toissijainen. Toissijainen replikoi, eikä sitä ole aina täysin synkronoitu ensisijaisen kanssa.
Lisäys tapahtuu "Primery"-tilaan tietyllä aika-arvolla. Tämä lisäys lisää sisäistä määrää 11:llä, jos tämä on maksimi. Tai se tarkistaa kellon arvot ja synkronoi kellon, jos kelloarvot ovat suurempia. Näin voit järjestää ajan mukaan.
Kun hän on tehnyt äänityksen, tapahtuu tärkeä hetki. Kello on "MongoDB":ssä ja sitä kasvatetaan vain, jos kirjoitetaan "Oplogiin". Tämä on tapahtuma, joka muuttaa järjestelmän tilaa. Ehdottomasti kaikissa klassisissa artikkeleissa tapahtumaksi katsotaan viestin osuminen solmuun: viesti on saapunut, mikä tarkoittaa, että järjestelmä on muuttanut tilaansa.
Tämä johtuu siitä, että tutkimuksen aikana ei ole täysin selvää, miten tätä viestiä tulkitaan. Tiedämme varmasti, että jos se ei näy "Oplogissa", sitä ei tulkita millään tavalla, ja järjestelmän tilan muutos on vain merkintä "Oplogissa". Tämä yksinkertaistaa meille kaikkea: malli yksinkertaistaa sitä ja antaa meille mahdollisuuden järjestää sen yhteen kopiosarjaan ja monia muita hyödyllisiä asioita.
Palautetaan arvo, joka on jo kirjoitettu “Oplogiin” – tiedämme, että “Oplog” sisältää jo tämän arvon ja sen aika on 12. Nyt esimerkiksi lukeminen alkaa toisesta solmusta (Secondary), ja se lähettää afterClusterTimen viesti. Hän sanoo: "Tarvitsen kaiken, mitä tapahtui vähintään 12 jälkeen tai kahdentoista" (katso kuva yllä).
Tätä kutsutaan kausaaliksi johdonmukaiseksi (CAT). Teoriassa on sellainen käsite, että tämä on jokin viipale aikaa, joka on sinänsä johdonmukainen. Tässä tapauksessa voimme sanoa, että tämä on järjestelmän tila, joka havaittiin hetkellä 12.
Nyt täällä ei ole vielä mitään, koska tämä simuloi tilannetta, kun tarvitset Toissijaista kopioimaan tietoja ensisijaisesta. Hän odottaa... Ja nyt tiedot ovat saapuneet - hän palauttaa nämä arvot takaisin.
Suunnilleen näin kaikki toimii. Melkein.
Mitä "melkein" tarkoittaa? Oletetaan, että joku on lukenut ja ymmärtänyt, kuinka tämä kaikki toimii. Ymmärsin, että joka kerta kun ClusterTime esiintyy, se päivittää sisäisen loogisen kellon, ja sitten seuraava merkintä kasvaa yhdellä. Tämä toiminto kestää 20 riviä. Oletetaan, että tämä henkilö lähettää suurimman 64-bittisen luvun, josta on vähennetty yksi.
Miksi "miinus yksi"? Koska sisäinen kello korvataan tähän arvoon (ilmeisesti tämä on suurin mahdollinen ja suurempi kuin nykyinen aika), niin "Oplogissa" tapahtuu merkintä ja kelloa kasvatetaan toisella yksiköllä - ja siellä on jo olla maksimiarvo (kaikki yksiköt ovat yksinkertaisesti olemassa, ei ole minnekään muualle mennä) , unsaint ints).
On selvää, että tämän jälkeen järjestelmästä tulee täysin käyttökelvoton millekään. Se voidaan vain purkaa ja puhdistaa - paljon manuaalista työtä. Täysi saatavuus:
Lisäksi, jos tämä kopioidaan jonnekin muualle, koko klusteri yksinkertaisesti putoaa. Täysin mahdoton hyväksyä tilanne, jonka kuka tahansa voi järjestää erittäin nopeasti ja helposti! Siksi pidimme tätä hetkeä yhtenä tärkeimmistä. Kuinka estää se?
Meidän tapamme on allekirjoittaa clusterTime
Näin se välitetään viestissä (ennen sinistä tekstiä). Mutta aloimme myös luoda allekirjoitusta (sininen teksti):
Allekirjoitus luodaan avaimella, joka on tallennettu tietokantaan suojatun kehyksen sisään; itse luodaan ja päivitetään (käyttäjät eivät näe siitä mitään). Hajautus luodaan, ja jokainen viesti allekirjoitetaan, kun se luodaan, ja vahvistetaan vastaanotettaessa.
Ihmisten mielessä todennäköisesti herää kysymys: "Kuinka paljon tämä hidastaa asioita?" Sanoin, että sen pitäisi toimia nopeasti, varsinkin kun tätä ominaisuutta ei ole.
Mitä kausaalisen johdonmukaisuuden käyttäminen tässä tapauksessa tarkoittaa? Tämä näyttää afterClusterTime-parametrin. Ilman tätä se yksinkertaisesti välittää arvot joka tapauksessa. Juoruilu versiosta 3.6 alkaen toimii aina.
Jos jätämme jatkuvan allekirjoitusten luomisen, se hidastaa järjestelmää, vaikka toimintoa ei olisikaan, mikä ei täytä lähestymistapojamme ja vaatimuksiamme. Mitä teimme?
Tee se nopeasti!
Se on melko yksinkertainen asia, mutta temppu on mielenkiintoinen - jaan sen, ehkä joku on kiinnostunut.
Meillä on tiiviste, joka tallentaa allekirjoitetut tiedot. Kaikki tiedot kulkevat välimuistin läpi. Välimuisti ei allekirjoita tiettyä aikaa, vaan alueen. Kun jokin arvo saapuu, luomme alueen, peitämme viimeiset 16 bittiä ja allekirjoitamme tämän arvon:
Vastaanottamalla tällaisen allekirjoituksen nopeuttamme järjestelmää (suhteellisesti) 65 tuhatta kertaa. Se toimii hienosti: kun teimme kokeita, aika itse asiassa lyheni 10 tuhatta kertaa, kun meillä oli peräkkäinen päivitys. On selvää, että kun ne ovat ristiriidassa, tämä ei toimi. Mutta useimmissa käytännön tapauksissa se toimii. Range-allekirjoituksen ja allekirjoituksen yhdistelmä ratkaisi tietoturvaongelman.
Mitä olemme oppineet?
Tästä opimme:
- Meidän on luettava materiaaleja, tarinoita, artikkeleita, koska meillä on paljon mielenkiintoisia asioita. Kun työskentelemme jonkin ominaisuuden parissa (etenkin nyt, kun teimme tapahtumia jne.), meidän on luettava ja ymmärrettävä. Se vie aikaa, mutta se on itse asiassa erittäin hyödyllistä, koska se tekee selväksi, missä olemme. Emme näyttäneet keksivän mitään uutta – otimme vain ainekset.
Yleisesti ottaen ajattelussa on tietty ero, kun on akateeminen konferenssi (esim. Sigmon) - kaikki keskittyvät uusiin ideoihin. Mitä uutta algoritmissamme on? Tässä ei ole mitään erityisen uutta. Uutuus piilee pikemminkin tavassa, jolla sekoitimme olemassa olevia lähestymistapoja. Siksi ensimmäinen asia on lukea klassikot, alkaen Lampartista.
- Tuotannossa vaatimukset ovat täysin erilaiset. Olen varma, että monet teistä eivät kohtaa "pallomaisia" tietokantoja abstraktissa tyhjiössä, vaan normaaleja, todellisia asioita, joilla on ongelmia saatavuuden, latenssin ja vikasietoisuuden kanssa.
- Viimeinen asia on, että meidän piti tarkastella eri ideoita ja yhdistää useita täysin erilaisia artikkeleita yhdeksi lähestymistavaksi, yhdessä. Ajatus esimerkiksi allekirjoittamisesta tuli yleensä artikkelista, jossa käsiteltiin Paxos-protokollaa, joka ei-bysanttilaisille on valtuutusprotokollan sisällä, bysanttilaisille - valtuutusprotokollan ulkopuolella... Yleisesti ottaen tämä on juuri se, mitä me päätyi tekemään.
Tässä ei todellakaan ole mitään uutta! Mutta heti kun sekoitimme kaikki yhteen... Se on sama kuin sanoisi, että Olivier-salaattiresepti on hölynpölyä, koska munat, majoneesi ja kurkut on jo keksitty... Se on sama tarina.
Lopetan tähän. Kiitos!
kysymykset
Kysymys yleisöltä (jäljempänä B): – Kiitos, Mikhail, raportista! Aihe on mielenkiintoinen. Käytät Gossipingia. He sanoivat, että jokaisella on oma aika, jokainen tietää paikallisen aikansa. Ymmärtääkseni meillä on kuljettaja - asiakkaita, joilla on ohjaimia, voi olla monia, kyselysuunnittelijoita myös, sirpaleita myös... Ja mihin järjestelmä johtaa, jos meillä on yhtäkkiä ristiriita: joku päättää, että se on tarkoitettu minuutin edellä, joku minuutin jäljessä? Mihin päädymme?
MT: – Todella hieno kysymys! Halusin vain puhua sirpaleista. Jos ymmärsin kysymyksen oikein, tilanne on seuraava: on sirpale 1 ja sirpale 2, lukeminen tapahtuu näistä kahdesta sirpaleesta - niissä on ristiriita, ne eivät ole vuorovaikutuksessa keskenään, koska heidän tuntemansa aika on erilainen, varsinkin aika, jolloin ne ovat olemassa oplogeissa.
Oletetaan, että shard 1 teki miljoona levyä, shard 2 ei tehnyt yhtään mitään ja pyyntö tuli kahdelle sirpaleelle. Ja ensimmäisellä on yli miljoonan afterClusterTime. Tällaisessa tilanteessa, kuten selitin, shard 2 ei koskaan vastaa ollenkaan.
in: – Halusin tietää, miten ne synkronoituvat ja valitsevat yhden loogisen ajan?
MT: - Erittäin helppo synkronoida. Sirpale, kun afterClusterTime tulee hänen luokseen ja hän ei löydä aikaa "Oplogista", ei aloita hyväksyttyä. Eli hän nostaa aikansa käsillään tähän arvoon. Tämä tarkoittaa, että sillä ei ole tätä pyyntöä vastaavia tapahtumia. Hän luo tämän tapahtuman keinotekoisesti ja siitä tulee siten johdonmukainen syy.
in: – Entä jos tämän jälkeen hänelle tulee muita tapahtumia, jotka ovat kadonneet jonnekin verkkoon?
MT: – Shard on suunniteltu niin, etteivät ne tule uudestaan, koska se on yksi mestari. Jos hän on jo ilmoittautunut, he eivät tule, vaan tulevat myöhemmin. Ei voi tapahtua, että jokin jää jumiin jonnekin, hän ei kirjoita, ja sitten nämä tapahtumat saapuvat - ja kausaalinen johdonmukaisuus katkeaa. Kun hän ei kirjoita, heidän kaikkien tulisi tulla seuraavaksi (hän odottaa niitä).
in: – Minulla on useita kysymyksiä jonoista. Syy-yhteensopivuus olettaa, että on olemassa tietty jono toimintoja, jotka on suoritettava. Mitä tapahtuu, jos jokin paketeistamme katoaa? Tästä tulee 10., 11.... 12. on kadonnut, ja kaikki muut odottavat sen toteutumista. Ja yhtäkkiä automme kuoli, emme voi tehdä mitään. Onko jonolla maksimipituus, joka kerääntyy ennen suorittamista? Mikä kohtalokas epäonnistuminen tapahtuu, kun jokin tila menetetään? Lisäksi, jos kirjoitamme muistiin, että on olemassa jokin aikaisempi tila, meidän pitäisi jotenkin aloittaa siitä? Mutta he eivät työntäneet häntä pois!
MT: – Myös hyvä kysymys! Mitä olemme tekemässä? MongoDB:ssä on käsite quorum writes, quorum reads. Missä tapauksissa viesti voi kadota? Kun kirjoitus ei ole päätösvaltainen tai kun luku ei ole päätösvaltainen (jokin roska saattaa myös tarttua).
Syy-yhteensopivuuden osalta tehtiin laaja kokeellinen testi, jonka tuloksena oli, että siinä tapauksessa, että kirjoitukset ja lukemat eivät ole päätösvaltaisia, tapahtuu kausaalisen johdonmukaisuuden rikkomuksia. Juuri niin kuin sanot!
Neuvomme: käytä vähintään päätösvaltaisuutta käyttäessäsi kausaalista johdonmukaisuutta. Tässä tapauksessa mitään ei menetetä, vaikka koorumitietue katoaisi... Tämä on ortogonaalinen tilanne: jos käyttäjä ei halua tietojen katoavan, hänen on käytettävä koorumitietuetta. Kausaalinen johdonmukaisuus ei takaa kestävyyttä. Kestävyyden takaavat replikointi ja replikointiin liittyvät koneet.
in: – Kun luomme ilmentymän, joka suorittaa sirpaloinnin meille (ei isäntä, vaan orja, vastaavasti), se luottaa oman koneensa Unix-aikaan tai "isäntä"-aikaan; Synkronoidaanko se ensimmäistä kertaa vai säännöllisesti?
MT: – Selvennetään nyt. Sirpale (eli vaakasuora osio) – siellä on aina ensisijainen. Ja sirpaleella voi olla "isäntä" ja siitä voi olla jäljennöksiä. Mutta sirpale tukee aina tallennusta, koska sen on tuettava jotakin toimialuetta (sirpaleella on ensisijainen).
in: – Kaikki riippuu siis puhtaasti "isännästä"? Käytetäänkö mestariaikaa aina?
MT: - Joo. Voidaan kuvainnollisesti sanoa: kello tikittää, kun tapahtuu pääsy "isäntään", "Oplogiin".
in: – Meillä on asiakas, joka yhdistää, eikä hänen tarvitse tietää ajasta mitään?
MT: – Sinun ei tarvitse tietää yhtään mitään! Jos puhumme siitä, kuinka se toimii asiakkaalla: kun asiakas haluaa käyttää kausaalista johdonmukaisuutta, hänen on avattava istunto. Nyt kaikki on siellä: tapahtumat istunnossa ja noutaa oikeudet... Istunto on asiakkaan kanssa tapahtuvien loogisten tapahtumien järjestystä.
Jos hän avaa tämän istunnon ja sanoo siellä haluavansa kausaalisen johdonmukaisuuden (jos istunto tukee oletuksena kausaalista johdonmukaisuutta), kaikki toimii automaattisesti. Kuljettaja muistaa tämän ajan ja lisää sitä, kun se saa uuden viestin. Se muistaa, minkä vastauksen edellinen palautti palvelimelta, joka palautti tiedot. Seuraava pyyntö sisältää afterCluster("aika suurempi kuin tämä").
Asiakkaan ei tarvitse tietää yhtään mitään! Tämä on hänelle täysin läpinäkymätöntä. Jos ihmiset käyttävät näitä ominaisuuksia, mitä he voivat tehdä? Ensinnäkin voit turvallisesti lukea toissijaisia: voit kirjoittaa ensisijaiseen ja lukea maantieteellisesti replikoiduista toissijaisista ja olla varma, että se toimii. Samalla Primary-tilassa tallennetut istunnot voidaan jopa siirtää toissijaiseen eli et voi käyttää yhtä istuntoa, vaan useita.
in: – Tietojenkäsittelytieteen uusi kerros – CRDT (Conflict-free Replicated Data Types) -tietotyypit – liittyy vahvasti mahdollisen johdonmukaisuuden aiheeseen. Oletko harkinnut tämäntyyppisten tietojen integroimista tietokantaan ja mitä voit sanoa siitä?
MT: - Hyvä kysymys! CRDT on järkevä kirjoitusristiriidoissa: MongoDB:ssä yksi isäntä.
in: – Minulla on kysymys devopsilta. Todellisessa maailmassa on sellaisia jesuiittisia tilanteita, kun tapahtuu Bysantin epäonnistuminen ja suojatun alueen sisällä olevat pahat ihmiset alkavat tunkeutua protokollaan, lähettää askartelupaketteja erityisellä tavalla?
MT: – Pahat ihmiset kehän sisällä ovat kuin Troijan hevonen! Pahat ihmiset alueen sisällä voivat tehdä paljon pahaa.
in: – On selvää, että jättämällä palvelimeen karkeasti sanottuna reikä, jonka läpi voi laittaa norsueläintarhan ja koko klusterin romahtaa ikuisiksi ajoiksi... Käsin palautuminen vie aikaa... Tämä lievästi sanottuna on väärä. Toisaalta tämä on mielenkiintoista: tosielämässä, käytännössä, on tilanteita, joissa tapahtuu luonnostaan samanlaisia sisäisiä hyökkäyksiä?
MT: – Koska törmään tietoturvaloukkauksiin tosielämässä harvoin, en osaa sanoa tapahtuuko niitä. Mutta jos puhumme kehitysfilosofiasta, ajattelemme näin: meillä on kehä, joka tarjoaa turvaa tekeville kavereille - tämä on linna, muuri; ja kehän sisällä voit tehdä mitä haluat. On selvää, että on käyttäjiä, joilla on mahdollisuus vain katsella, ja on käyttäjiä, joilla on mahdollisuus tyhjentää hakemisto.
Oikeuksista riippuen käyttäjien aiheuttama vahinko voi olla hiiri tai norsu. On selvää, että käyttäjä, jolla on täydet oikeudet, voi tehdä mitä tahansa. Käyttäjä, jolla on rajoitetut oikeudet, voi aiheuttaa huomattavasti vähemmän haittaa. Erityisesti se ei voi rikkoa järjestelmää.
in: – Suojatulla alueella joku yritti luoda palvelimelle odottamattomia protokollia tuhotakseen palvelimen kokonaan, ja jos olet onnekas, koko klusterin... Meneekö se koskaan niin "hyväksi"?
MT: "En ole koskaan kuullut sellaisista." Se, että voit kaataa palvelimen tällä tavalla, ei ole mikään salaisuus. Epäonnistunut sisällä, olla protokollasta, olla valtuutettu käyttäjä, joka voi kirjoittaa jotain tällaista viestiin... Itse asiassa se on mahdotonta, koska se vielä tarkistetaan. On mahdollista poistaa tämä todennus käytöstä käyttäjiltä, jotka eivät halua sitä - silloin se on heidän ongelmansa; he karkeasti sanottuna tuhosivat seinät itse ja sinne voi työntää norsun, joka tallaa... Mutta ylipäätään voit pukeutua korjaajaksi, tule ja vedä se ulos!
in: – Kiitos raportista. Sergei (Yandex). Mongissa on vakio, joka rajoittaa äänestävien jäsenten lukumäärää replikajoukossa, ja tämä vakio on 7 (seitsemän). Miksi tämä on vakio? Miksi tämä ei ole jonkinlainen parametri?
MT: – Meillä on kopiosarjoja, joissa on 40 solmua. Aina on enemmistö. En tiedä mikä versio...
in: – Replica Setissä voit ajaa äänivallattomia jäseniä, mutta äänivaltaisia jäseniä on korkeintaan 7. Kuinka voimme selviytyä sulkemisesta tässä tapauksessa, jos Replica Set on hajallaan kolmeen palvelinkeskukseen? Yksi palvelinkeskus voi helposti sammua, ja toinen kone voi pudota.
MT: – Tämä on jo hieman mietinnön ulottumattomissa. Tämä on yleinen kysymys. Ehkä voin kertoa siitä sinulle myöhemmin.
Muutamia mainoksia 🙂
Kiitos, että pysyt kanssamme. Pidätkö artikkeleistamme? Haluatko nähdä mielenkiintoisempaa sisältöä? Tue meitä tekemällä tilauksen tai suosittelemalla ystäville, , ainutlaatuinen lähtötason palvelimien analogi, jonka me keksimme sinulle: (saatavana RAID1:n ja RAID10:n kanssa, jopa 24 ydintä ja jopa 40 Gt DDR4-muistia).
Dell R730xd 2 kertaa halvempi Equinix Tier IV -palvelinkeskuksessa Amsterdamissa? Vain täällä Alankomaissa! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - alkaen 99 dollaria! Lukea
Lähde: will.com