HighLoad++, Mikhail Tyulenev (MongoDB): Orsakskonsistens: från teori till praktik

Nästa HighLoad++-konferens kommer att hållas den 6 och 7 april 2020 i St. Petersburg.
Detaljer och biljetter по ссылке. HighLoad++ Sibirien 2019. Hall "Krasnoyarsk". 25 juni, 12:00. Avhandlingar och presentation.

Det händer att praktiska krav kommer i konflikt med teori, där aspekter som är viktiga för en kommersiell produkt inte beaktas. Detta föredrag presenterar en process för att välja ut och kombinera olika tillvägagångssätt för att skapa orsakssammanhangskomponenter baserade på akademisk forskning baserad på kraven på en kommersiell produkt. Lyssnarna kommer att lära sig om befintliga teoretiska tillvägagångssätt för logiska klockor, beroendespårning, systemsäkerhet, klocksynkronisering och varför MongoDB bestämde sig för vissa lösningar.

Mikhail Tyulenev (nedan kallad MT): – Jag kommer att prata om orsakskonsistens - det här är en funktion som vi arbetade med i MongoDB. Jag arbetar i en grupp av distribuerade system, vi gjorde det för ungefär två år sedan.

I processen var jag tvungen att bekanta mig med mycket akademisk forskning, eftersom denna egenskap har studerats ganska väl. Det visade sig att inte en enda artikel passar in i vad som krävs i en produktionsdatabas på grund av mycket specifika krav som förmodligen finns i någon produktionsapplikation.

Jag kommer att prata om hur vi som konsumenter av akademisk forskning förbereder något av den som vi sedan kan presentera för våra användare som en färdigrätt som är bekväm och säker att använda.

Orsakskonsistens. Låt oss definiera begreppen

Till att börja med vill jag säga i allmänna termer vad kausal konsistens är. Det finns två karaktärer - Leonard och Penny (TV-serien "The Big Bang Theory"):

Låt oss säga att Penny är i Europa och Leonard vill ordna en överraskningsfest för henne. Och han kan inte tänka sig något bättre än att kasta bort henne från sin vänlista och skicka alla sina vänner en uppdatering om flödet: "Låt oss göra Penny glad!" (hon är i Europa, medan hon sover, hon ser inte allt detta och kan inte se det, för hon är inte där). I slutändan tar hon bort det här inlägget, raderar det från flödet och återställer åtkomsten så att hon inte märker något och det finns ingen skandal.
Det här är väl och bra, men låt oss anta att systemet är distribuerat och att det gick lite fel. Det kan till exempel hända att Pennys åtkomstbegränsning inträffade efter att detta inlägg dök upp, om händelserna inte är relaterade till orsak och verkan. Egentligen är detta ett exempel på när Causal konsekvens krävs för att utföra en affärsfunktion (i detta fall).

Faktum är att dessa är ganska icke-triviala egenskaper hos databasen - väldigt få människor stöder dem. Låt oss gå vidare till modellerna.

Konsistensmodeller

Vad är egentligen en konsistensmodell i databaser? Det är några av de garantier som ett distribuerat system ger om vilken data klienten kan ta emot och i vilken ordningsföljd.

I princip kommer alla konsistensmodeller ner på hur likt ett distribuerat system är ett system som körs till exempel på en nod på en bärbar dator. Och så liknar ett system som körs på tusentals geodistribuerade "noder" en bärbar dator, där alla dessa egenskaper i princip utförs automatiskt.

Därför tillämpas konsistensmodeller endast på distribuerade system. Alla system som tidigare funnits och fungerade i samma vertikala skala upplevde inte sådana problem. Det fanns en buffertcache, och allt lästes alltid från den.

Modell stark

Egentligen är den allra första modellen Strong (eller rise ability line, som den ofta kallas). Detta är en konsistensmodell som säkerställer att varje förändring, när den har bekräftats att den har skett, är synlig för alla användare av systemet.

Detta skapar en global ordning av alla händelser i databasen. Detta är en mycket stark konsistensegenskap, och den är i allmänhet mycket dyr. Det stöds dock väldigt bra. Det är bara väldigt dyrt och långsamt - det används bara sällan. Detta kallas höjningsförmåga.

Det finns en annan, starkare egenskap som stöds i Spanner - kallad External Consistency. Vi ska prata om det lite senare.

orsaks~~POS=TRUNC

Nästa är Causal, vilket är precis vad jag pratade om. Det finns flera undernivåer mellan Stark och Causal som jag inte kommer att prata om, men de kokar alla ner till Causal. Detta är en viktig modell eftersom den är den starkaste av alla modeller, den starkaste konsistensen i närvaro av ett nätverk eller partitioner.

Causals är faktiskt en situation där händelser är kopplade till ett orsak-verkan-samband. Mycket ofta uppfattas de som Läs dina rättigheter ur kundens synvinkel. Om klienten har observerat några värden kan han inte se värden som fanns i det förflutna. Han börjar redan se prefixavläsningar. Allt handlar om samma sak.
Causals som konsistensmodell är en partiell ordning av händelser på servern, där händelser från alla klienter observeras i samma sekvens. I det här fallet Leonard och Penny.

Eventuell

Den tredje modellen är Eventuell konsistens. Detta är vad absolut alla distribuerade system stödjer, den minimala modellen som överhuvudtaget är vettig. Det betyder följande: när vi har några förändringar i data, någon gång blir de konsekventa.

I ett sådant ögonblick säger hon ingenting, annars skulle hon förvandlas till Extern Konsistens - det skulle vara en helt annan historia. Ändå är detta en mycket populär modell, den vanligaste. Som standard använder alla användare av distribuerade system Eventuell konsistens.

Jag vill ge några jämförande exempel:

Vad betyder dessa pilar?

• Latens. När konsistensstyrkan ökar blir den större av förklarliga skäl: du behöver göra fler poster, få bekräftelse från alla värdar och noder som deltar i klustret att datan redan finns där. Följaktligen har Eventuell konsistens det snabbaste svaret, för där, som regel, kan du till och med förbinda det till minnet och det kommer i princip att räcka.
• Tillgänglighet. Om vi ​​förstår detta som systemets förmåga att reagera i närvaro av nätverksavbrott, partitioner eller någon form av fel, ökar feltoleransen när konsistensmodellen minskar, eftersom det räcker för oss att en värd lever och samtidigt tiden producerar vissa data. Eventuell konsistens garanterar inte någonting om uppgifterna alls - det kan vara vad som helst.
• Anomalier. Samtidigt ökar förstås antalet anomalier. I Strong Consistency borde de nästan inte existera alls, men i Eventual Consistency kan de vara vad som helst. Frågan uppstår: varför väljer människor Eventuell konsistens om den innehåller anomalier? Svaret är att Eventual Consistency-modeller är tillämpliga och anomalier finns till exempel under en kort tidsperiod; det är möjligt att använda guiden för att läsa och mer eller mindre läsa konsekventa data; Det är ofta möjligt att använda starka konsistensmodeller. I praktiken fungerar detta, och ofta är antalet anomalier tidsbegränsat.

CAP-sats

När du ser orden konsekvens, tillgänglighet – vad tänker du på? Det stämmer - CAP-teorem! Nu vill jag skingra myten... Det är inte jag - det är Martin Kleppmann, som skrev en underbar artikel, en underbar bok.

CAP-satsen är en princip som formulerades på 2000-talet att Konsistens, Tillgänglighet, Partitioner: ta vilka två som helst och du kan inte välja tre. Det var en viss princip. Det bevisades som ett teorem några år senare av Gilbert och Lynch. Sedan började detta användas som ett mantra - system började delas upp i CA, CP, AP och så vidare.

Denna sats bevisades faktiskt för följande fall... För det första ansågs tillgänglighet inte vara ett kontinuerligt värde från noll till hundratals (0 - systemet är "dött", 100 - svarar snabbt; vi är vana vid att betrakta det så) , men som en egenskap hos algoritmen , som garanterar att den returnerar data för alla dess exekveringar.

Det finns inte ett ord om svarstid alls! Det finns en algoritm som returnerar data efter 100 år – en helt underbar tillgänglig algoritm, som är en del av CAP-satsen.
För det andra: satsen bevisades för förändringar i värdena för samma nyckel, trots att dessa förändringar kan ändras i storlek. Detta betyder att de i verkligheten praktiskt taget inte används, eftersom modellerna är olika Eventuell konsistens, stark konsistens (kanske).

Vad är allt detta till för? Dessutom är CAP-satsen i exakt den form som den bevisades praktiskt taget inte tillämplig och används sällan. I teoretisk form begränsar det på något sätt allt. Det visar sig en viss princip som är intuitivt korrekt, men i allmänhet inte har bevisats.

Orsakskonsistens är den starkaste modellen

Vad som händer nu är att du kan få alla tre sakerna: Konsistens, Tillgänglighet med hjälp av partitioner. I synnerhet är orsakskonsistens den starkaste konsistensmodellen, som fortfarande fungerar i närvaro av partitioner (avbrott i nätverket). Det är därför det är av så stort intresse, och det är därför vi tog upp det.

För det första förenklar det arbetet för applikationsutvecklare. I synnerhet närvaron av bra stöd från servern: när alla poster som förekommer inuti en klient garanterat kommer fram i samma sekvens på en annan klient. För det andra tål den skiljeväggar.

MongoDB inre kök

När vi kommer ihåg att det är lunch flyttar vi till köket. Jag ska berätta om systemmodellen, nämligen vad MongoDB är för de som hör talas om en sådan databas för första gången.

MongoDB (hädanefter kallat "MongoDB") är ett distribuerat system som stöder horisontell skalning, det vill säga skärning; och inom varje skärva stöder den också dataredundans, det vill säga replikering.

Sharding i MongoDB (inte en relationsdatabas) utför automatisk balansering, det vill säga varje samling av dokument (eller "tabell" i termer av relationsdata) är uppdelad i bitar, och servern flyttar dem automatiskt mellan skärvor.

Frågeroutern, som distribuerar förfrågningar, för en klient är en klient genom vilken den fungerar. Den vet redan var och vilken data som finns och dirigerar alla förfrågningar till rätt skärva.

En annan viktig punkt: MongoDB är en enda master. Det finns en primär - den kan ta poster som stöder nycklarna som den innehåller. Du kan inte skriva Multi-master.

Vi gjorde release 4.2 - nya intressanta saker dök upp där. Framför allt infogade man Lucene - sök - nämligen körbar java direkt i Mongo och där blev det möjligt att utföra sökningar genom Lucene, samma som i Elastica.

Och de gjorde en ny produkt - Charts, den finns även på Atlas (Mongos egna moln). De har en gratis nivå - du kan leka med den. Jag gillade verkligen Charts - datavisualisering, väldigt intuitivt.

Ingredienser Orsakskonsistens

Jag räknade till cirka 230 artiklar som har publicerats i detta ämne – från Leslie Lampert. Nu från mitt minne kommer jag att förmedla några delar av detta material till dig.

Allt började med en artikel av Leslie Lampert, som skrevs på 1970-talet. Som du kan se pågår en del forskning om detta ämne fortfarande. Nu upplever Causal konsekvens intresse i samband med utveckling av distribuerade system.

Begränsningar

Vilka restriktioner finns det? Detta är faktiskt en av huvudpunkterna, eftersom de restriktioner som ett produktionssystem inför skiljer sig mycket från de restriktioner som finns i akademiska artiklar. De är ofta ganska konstgjorda.

• För det första är "MongoDB" en enda mästare, som jag redan sa (detta förenklar avsevärt).
• Vi anser att systemet bör stödja cirka 10 tusen skärvor. Vi kan inte fatta några arkitektoniska beslut som explicit begränsar detta värde.
• Vi har ett moln, men vi antar att en person fortfarande ska ha möjligheten när han laddar ner binär, startar den på sin bärbara dator och allt fungerar utmärkt.
• Vi utgår från något som Research sällan antar: externa kunder kan göra vad de vill. MongoDB är öppen källkod. Följaktligen kan klienter vara så smarta och arga - de kan vilja bryta allt. Vi spekulerar i att bysantinska felorer kan ha sitt ursprung.
• För externa klienter som är utanför omkretsen finns det en viktig begränsning: om den här funktionen är inaktiverad bör ingen prestandaförsämring observeras.
• En annan punkt är generellt anti-akademisk: kompatibiliteten mellan tidigare versioner och framtida. Gamla drivrutiner måste stödja nya uppdateringar, och databasen måste stödja gamla drivrutiner.

I allmänhet innebär allt detta restriktioner.

Orsakskonsistenskomponenter

Jag ska nu prata om några av komponenterna. Om vi ​​överväger kausal konsistens i allmänhet kan vi välja block. Vi valde bland verk som hör till ett visst block: Beroendespårning, val av klockor, hur dessa klockor kan synkroniseras med varandra och hur vi säkerställer säkerhet - det här är en grov översikt av vad jag kommer att prata om:

Fullständig spårning av beroende

Varför behövs det? Så att när data replikeras innehåller varje post, varje dataändring information om vilka förändringar den beror på. Den allra första och naiva förändringen är när varje meddelande som innehåller en post innehåller information om tidigare meddelanden:

I det här exemplet är numret inom parentes rekordsiffrorna. Ibland överförs dessa poster med värden till och med i sin helhet, ibland överförs vissa versioner. Summan av kardemumman är att varje förändring innehåller information om den föregående (uppenbarligen bär allt detta inom sig).

Varför valde vi att inte använda detta tillvägagångssätt (fullständig spårning)? Uppenbarligen, eftersom det här tillvägagångssättet är opraktiskt: varje förändring av ett socialt nätverk beror på alla tidigare förändringar i det sociala nätverket, överföring, säg, Facebook eller VKontakte i varje uppdatering. Ändå finns det mycket forskning om Full Dependency Tracking – det här är försociala nätverk; för vissa situationer fungerar det verkligen.

Spårning av explicit beroende

Nästa är mer begränsad. Även här beaktas överföring av information, men endast det som är klart beroende. Vad som beror på vad bestäms i regel av Ansökan. När data replikeras, returnerar frågan endast svar när tidigare beroenden har uppfyllts, det vill säga visas. Detta är kärnan i hur kausal konsistens fungerar.

Hon ser att post 5 beror på posterna 1, 2, 3, 4 - följaktligen väntar hon innan klienten har tillgång till ändringarna som gjorts av Pennys åtkomstbeslut, när alla tidigare ändringar redan har passerat databasen.

Det här passar inte oss heller, eftersom det fortfarande finns för mycket information, och det kommer att sakta ner. Det finns ett annat tillvägagångssätt...

Lamport klocka

De är väldigt gamla. Lamport Clock innebär att dessa beroenden vikas till en skalär funktion, som kallas Lamport Clock.

En skalär funktion är ett abstrakt tal. Det kallas ofta för logisk tid. Med varje händelse ökar denna räknare. Räknaren, som för närvarande är känd för processen, skickar varje meddelande. Det är klart att processer kan vara osynkroniserade, de kan ha helt andra tider. Ändå balanserar systemet på något sätt klockan med sådana meddelanden. Vad händer i det här fallet?

Jag delar den stora skärvan i två för att göra det tydligt: ​​Vänner kan bo i en nod, som innehåller en del av samlingen, och Feed kan bo i en annan nod, som innehåller en del av den här samlingen. Är det tydligt hur de kan komma ur linjen? First Feed kommer att säga: "Replicated" och sedan Friends. Om systemet inte ger någon form av garanti för att flödet inte kommer att visas förrän även Friends-beroendena i Friends-samlingen har levererats, så kommer vi att ha exakt den situation som jag nämnde.

Du ser hur räknartiden på Feed logiskt ökar:

Så huvudegenskapen för denna Lamport-klocka och orsakskonsistens (förklarad genom Lamport-klocka) är denna: om vi har händelser A och B, och händelse B beror på händelse A*, så följer det att den logiska tiden för händelse A är mindre än än LogicalTime från händelse B.

* Ibland säger de också att A hände före B, det vill säga A hände före B - detta är en viss relation som delvis ordnar hela uppsättningen av händelser som hände i allmänhet.

Motsatsen är felaktig. Detta är faktiskt en av de största nackdelarna med Lamport Clock - delordning. Det finns ett koncept om samtidiga händelser, det vill säga händelser där varken (A hände före B) eller (A hände före B). Ett exempel skulle vara Leonards parallella tillägg av någon annan som vän (inte ens Leonard, utan Sheldon, till exempel).
Det här är egenskapen som ofta används när man arbetar med Lamport-klockor: de tittar specifikt på funktionen och från detta drar de slutsatsen att dessa händelser kanske är beroende. Eftersom ett sätt är sant: om LogicalTime A är mindre än LogicalTime B, kan B inte hända före A; och om mer, så kanske.

Vektor klocka

Den logiska utvecklingen av Lamport-klockan är Vector Clock. De skiljer sig åt genom att varje nod som finns här innehåller sin egen separata klocka, och de sänds som en vektor.
I det här fallet ser du att det nollte indexet för vektorn är ansvarigt för Feed, och det första indexet för vektorn är för Friends (var och en av dessa noder). Och nu kommer de att öka: nollindexet för "Feed" ökar när du skriver - 1, 2, 3:

Varför är Vector Clock bättre? Eftersom de låter dig ta reda på vilka händelser som är samtidiga och när de inträffar på olika noder. Detta är mycket viktigt för ett skärningssystem som MongoDB. Vi valde dock inte detta, även om det är en underbar grej, och det fungerar utmärkt, och det skulle nog passa oss...

Om vi ​​har 10 tusen skärvor kan vi inte överföra 10 tusen komponenter, även om vi komprimerar det eller kommer på något annat - nyttolasten kommer fortfarande att vara flera gånger mindre än volymen för hela denna vektor. Därför, med att bita ihop våra hjärtan och tänder, övergav vi detta tillvägagångssätt och gick vidare till ett annat.

Nyckel TrueTime. Atomklocka

Jag sa att det skulle finnas en historia om Spanner. Det här är en cool sak, direkt från XNUMX-talet: atomur, GPS-synkronisering.

Vad är tanken? "Spanner" är ett Google-system som nyligen till och med blev tillgängligt för människor (de lade till SQL till det). Varje transaktion där har en tidsstämpel. Eftersom tiden är synkroniserad* kan varje händelse tilldelas en specifik tid - atomklockor har en väntetid, varefter en annan tid garanteras "hände".

Således, genom att helt enkelt skriva till databasen och vänta en viss tid, garanteras evenemangets serialiseringsbarhet automatiskt. De har den starkaste Konsistensmodellen man kan tänka sig i princip – det är Extern Konsistens.

* Detta är huvudproblemet med Lampart-klockor - de är aldrig synkrona på distribuerade system. De kan skilja sig åt; även med NTP fungerar de fortfarande inte särskilt bra. "Spanner" har en atomklocka och synkroniseringen verkar vara mikrosekunder.

Varför valde vi inte? Vi utgår inte från att våra användare har en inbyggd atomklocka. När de dyker upp, som är inbyggda i varje bärbar dator, kommer det att finnas någon sorts supercool GPS-synkronisering - då ja... Men för tillfället är det bästa som är möjligt Amazon, Base Stations - för fanatiker... Så vi använde andra klockor .

Hybrid klocka

Detta är faktiskt vad som tickar i MongoDB när man säkerställer orsakskonsistens. Hur är de hybrider? Hybrid är ett skalärt värde, men det har två komponenter:

• Den första är Unix-epoken (hur många sekunder har gått sedan "datorvärldens början").
• Det andra är ett steg, också en 32-bitars osignerad int.

Det är allt, faktiskt. Det finns detta tillvägagångssätt: den del som är ansvarig för tiden synkroniseras med klockan hela tiden; varje gång en uppdatering sker synkroniseras denna del med klockan och det visar sig att tiden alltid är mer eller mindre korrekt, och inkrement gör att du kan skilja mellan händelser som inträffade vid samma tidpunkt.

Varför är detta viktigt för MongoDB? Eftersom det låter dig göra någon form av reservrestauranger vid en viss tidpunkt, det vill säga att händelsen indexeras efter tid. Detta är viktigt när vissa händelser behövs; För en databas är händelser ändringar i databasen som inträffade med vissa tidsintervall.

Jag kommer bara att berätta den viktigaste anledningen för dig (snälla, berätta inte för någon)! Vi gjorde detta eftersom det är så organiserad, indexerad data ser ut i MongoDB OpLog. OpLog är en datastruktur som innehåller absolut alla ändringar i databasen: de går först till OpLog, och sedan appliceras de på själva lagringen i fallet när det är ett replikerat datum eller fragment.

Detta var huvudorsaken. Ändå finns det också praktiska krav för att utveckla en databas, vilket gör att den ska vara enkel – lite kod, så få trasiga saker som möjligt som behöver skrivas om och testas. Det faktum att våra oploggar indexerades av hybridklockor hjälpte mycket och gjorde att vi kunde göra rätt val. Det lönade sig verkligen och på något magiskt sätt fungerade det på den allra första prototypen. Det var väldigt coolt!

Klocksynkronisering

Det finns flera synkroniseringsmetoder som beskrivs i den vetenskapliga litteraturen. Jag pratar om synkronisering när vi har två olika skärvor. Om det finns en replikuppsättning finns det inget behov av någon synkronisering: detta är en "single master"; vi har en OpLog, i vilken alla ändringar faller - i det här fallet är allt redan sekventiellt beställt i själva "Oplog". Men om vi har två olika skärvor är tidssynkronisering viktig här. Det var här vektorklockan hjälpte mer! Men vi har dem inte.

Den andra är lämplig - det här är "Heartbeats". Det är möjligt att utbyta några signaler som uppstår varje tidsenhet. Men hjärtslagen är för långsamma, vi kan inte tillhandahålla latens till vår klient.

Sann tid är naturligtvis en underbar sak. Men återigen, det här är förmodligen framtiden... Även om det redan kan göras i Atlas, finns det redan snabba "Amazon"-tidssynkroniserare. Men det kommer inte att vara tillgängligt för alla.

Skvaller är när alla meddelanden inkluderar tid. Detta är ungefär vad vi använder. Varje meddelande mellan noder, en drivrutin, en datanod-router, absolut allt för MongoDB är något slags element, en databaskomponent som innehåller en klocka som körs. De har betydelsen av hybridtid överallt, den överförs. 64 bitar? Detta tillåter, detta är möjligt.

Hur fungerar det hela ihop?

Här tittar jag på en replikuppsättning för att göra det lite enklare. Det finns primära och sekundära. Sekundär replikerar och är inte alltid helt synkroniserad med primär.

En infogning sker i "Primery" med ett visst tidsvärde. Denna infogning ökar det interna antalet med 11, om detta är max. Eller så kommer den att kontrollera klockvärdena och synkronisera med klockan om klockvärdena är högre. Detta gör att du kan organisera efter tid.

Efter att han gjort inspelningen inträffar ett viktigt ögonblick. Klockan är i "MongoDB" och ökas endast vid skrivning till "Oplog". Detta är den händelse som ändrar systemets tillstånd. I absolut alla klassiska artiklar anses en händelse vara när ett meddelande träffar en nod: meddelandet har kommit, vilket betyder att systemet har ändrat tillstånd.

Detta beror på att det under forskning inte är helt klart hur detta budskap kommer att tolkas. Vi vet med säkerhet att om det inte återspeglas i "Oplog", så kommer det inte att tolkas på något sätt, och en förändring i systemets tillstånd är bara en post i "Oplog". Detta förenklar allt för oss: modellen förenklar det och låter oss organisera det i en replikuppsättning och många andra användbara saker.

Värdet som redan är skrivet till "Oplog" returneras - vi vet att "Oplog" redan innehåller detta värde, och dess tid är 12. Nu börjar säg att läsa från en annan nod (Sekundär), och den sänder afterClusterTime i budskapet. Han säger: "Jag behöver allt som hände åtminstone efter 12 eller under tolv" (se bilden ovan).

Detta är vad som kallas Causal a consistent (CAT). Det finns ett sådant koncept i teorin att detta är en del av tiden, vilket är konsekvent i sig. I det här fallet kan vi säga att detta är tillståndet för systemet som observerades vid tidpunkten 12.

Nu finns det inget här ännu, eftersom den här typen av simulerar situationen när du behöver sekundären för att replikera data från primären. Han väntar... Och nu har uppgifterna kommit - han returnerar dessa värden tillbaka.

Det är ungefär så det hela fungerar. Nästan.

Vad betyder "nästan"? Låt oss anta att det finns någon person som har läst och förstått hur allt detta fungerar. Jag insåg att varje gång ClusterTime inträffar uppdaterar den den interna logiska klockan, och sedan ökar nästa post med en. Denna funktion tar 20 rader. Låt oss säga att den här personen sänder det största 64-bitarsnumret, minus ett.

Varför "minus ett"? Eftersom den interna klockan kommer att ersättas med detta värde (uppenbarligen är detta den största möjliga och större än den aktuella tiden), då kommer en ingång att ske i "Oplog", och klockan kommer att ökas med en annan enhet - och det kommer redan vara ett maximalt värde (det finns helt enkelt alla enheter, det finns ingen annanstans att ta vägen), ohelgon ints).

Det är tydligt att systemet efter detta blir absolut otillgängligt för någonting. Den kan bara lastas av och rengöras - mycket manuellt arbete. Full tillgänglighet:

Dessutom, om detta replikeras någon annanstans, faller hela klustret helt enkelt ner. En absolut oacceptabel situation som vem som helst kan organisera mycket snabbt och enkelt! Därför ansåg vi detta ögonblick som ett av de viktigaste. Hur kan man förhindra det?

Vårt sätt är att signera clusterTime

Så här sänds det i meddelandet (före den blå texten). Men vi började också skapa en signatur (blå text):

Signaturen genereras av en nyckel som lagras inuti databasen, inom en säker omkrets; själv genereras och uppdateras (användarna ser inget om det). En hash genereras och varje meddelande signeras när det skapas och valideras när det tas emot.
Frågan uppstår förmodligen i människors medvetande: "Hur mycket saktar detta upp saker?" Jag sa till dig att det borde fungera snabbt, särskilt i frånvaro av denna funktion.

Vad innebär det att använda orsakskonsistens i det här fallet? Detta är för att visa afterClusterTime-parametern. Utan detta kommer det helt enkelt att passera värden ändå. Skvaller, från och med version 3.6, fungerar alltid.

Om vi ​​lämnar den ständiga genereringen av signaturer kommer det att bromsa systemet även i frånvaro av en funktion, som inte uppfyller våra tillvägagångssätt och krav. Så vad gjorde vi?

Gör det snabbt!

Det är en ganska enkel sak, men tricket är intressant – jag delar det, kanske någon är intresserad.
Vi har en hash som lagrar den signerade datan. All data går genom cachen. Cachen anger inte den specifika tiden, utan Range. När något värde anländer genererar vi ett intervall, maskerar de sista 16 bitarna, och vi signerar detta värde:

Genom att ta emot en sådan signatur snabbar vi upp systemet (relativt) 65 tusen gånger. Det fungerar utmärkt: när vi utförde experiment minskade tiden faktiskt med 10 tusen gånger när vi hade en sekventiell uppdatering. Det är klart att när de är osams så fungerar inte detta. Men i de flesta praktiska fall fungerar det. Kombinationen av Range-signaturen tillsammans med signaturen löste säkerhetsproblemet.

Vad har vi lärt oss?

Lärdomar vi lärde oss av detta:

• Vi behöver läsa material, berättelser, artiklar, för vi har många intressanta saker. När vi arbetar med någon funktion (särskilt nu, när vi gjorde transaktioner, etc.), måste vi läsa och förstå. Det tar tid, men det är faktiskt väldigt användbart eftersom det gör det tydligt var vi är. Vi verkade inte komma på något nytt – vi tog bara ingredienserna.

  Generellt är det en viss skillnad i tänkandet när det är en akademisk konferens (Sigmon till exempel) – alla fokuserar på nya idéer. Vad är nytt med vår algoritm? Det finns ingen speciell nyhet här. Nyheten ligger snarare i hur vi kombinerade befintliga tillvägagångssätt. Därför är det första att läsa klassikerna, börja med Lampart.

• I produktionen är kraven helt andra. Jag är säker på att många av er inte står inför "sfäriska" databaser i ett abstrakt vakuum, utan med normala, verkliga saker som har problem med tillgänglighet, latens och feltolerans.
• Det sista är att vi var tvungna att titta på olika idéer och kombinera flera helt olika artiklar till ett tillvägagångssätt, tillsammans. Idén om att skriva på kom till exempel generellt från en artikel som övervägde Paxos-protokollet, som för icke-bysantinska misslyckanden är inom auktoriseringsprotokollet, för bysantinska - utanför auktorisationsprotokollet... Generellt sett är det precis vad vi slutade göra.

  Det är absolut inget nytt här! Men så fort vi blandat ihop allt... Det är samma sak som att säga att Olivier-salladsreceptet är nonsens, för ägg, majonnäs och gurka har redan uppfunnits... Det är ungefär samma historia.

Jag avslutar med det här. Tack!

frågor

Fråga från publiken (nedan kallad B): – Tack, Mikhail, för rapporten! Ämnet om tid är intressant. Du använder Gossiping. De sa att alla har sin egen tid, alla känner sin lokala tid. Som jag förstår det har vi en drivrutin - det kan finnas många klienter med drivrutiner, frågeplanerare också, skärvor också... Och vad kommer systemet till om vi plötsligt har en diskrepans: någon bestämmer att det är för en minut före, någon minut efter? Var hamnar vi?

MT: – Verkligen bra fråga! Jag ville bara prata om skärvor. Om jag förstår frågan rätt har vi följande situation: det finns skärva 1 och skärva 2, läsning sker från dessa två skärvor - de har en diskrepans, de interagerar inte med varandra, eftersom tiden som de känner till är olika, speciellt den tid som de finns i oplogs.
Låt oss säga att shard 1 gjorde en miljon rekord, shard 2 gjorde ingenting alls, och begäran kom till två shards. Och den första har en afterClusterTime på över en miljon. I en sådan situation, som jag förklarade, kommer shard 2 aldrig att svara alls.

PÅ: – Jag ville veta hur de synkroniserar och väljer en logisk tidpunkt?

MT: - Mycket lätt att synkronisera. Shard, när afterClusterTime kommer till honom och han inte hittar tid i "Oploggen", initierar ingen godkänd. Det vill säga, han höjer sin tid med händerna till detta värde. Det betyder att det inte har några händelser som matchar denna begäran. Han skapar denna händelse artificiellt och blir därmed kausalkonsistent.

PÅ: – Tänk om efter detta kommer några andra händelser till honom som gått förlorade någonstans i nätverket?

MT: – Shard är designad på ett sådant sätt att de inte kommer igen, eftersom det är en enda mästare. Har han redan anmält sig så kommer de inte utan kommer senare. Det kan inte hända att något fastnar någonstans, då skriver han inget, och sedan kommer dessa händelser - och den kausala konsistensen bryts. När han inte skriver, bör de alla komma härnäst (han väntar på dem).

PÅ: – Jag har flera frågor angående köerna. Orsaksöverensstämmelse förutsätter att det finns en specifik kö av åtgärder som måste utföras. Vad händer om ett av våra paket försvinner? Här kommer den 10:e, 11:e... den 12:e har försvunnit, och alla andra väntar på att det ska bli verklighet. Och plötsligt dog vår bil, vi kan inte göra någonting. Finns det en maximal längd på kön som ackumuleras innan den exekveras? Vilket dödligt misslyckande inträffar när någon stat går förlorad? Dessutom, om vi skriver ner att det finns något tidigare tillstånd, borde vi på något sätt utgå från det? Men de knuffade honom inte!

MT: – Också en bra fråga! Vad gör vi? MongoDB har begreppet kvorum skriver, kvorum läser. I vilka fall kan ett meddelande gå förlorat? När en skrivning inte är beslutför eller när en läsning inte är beslutför (någon sorts skräp kan också fastna).
När det gäller kausal överensstämmelse genomfördes ett stort experimentellt test, vars resultat var att i fallet när skrivningar och läsningar är icke-quorum, inträffar kränkningar av kausal konsistens. Precis vad du säger!

Vårt råd: använd åtminstone kvorumläsning när du använder kausal konsistens. I det här fallet kommer ingenting att gå förlorat, även om kvorumposten går förlorad... Detta är en ortogonal situation: om användaren inte vill att data ska gå förlorade måste han använda en kvorumpost. Orsakskonsistens garanterar inte hållbarhet. Hållbarhet garanteras av replikering och maskineriet i samband med replikering.

PÅ: – När vi skapar en instans som utför sharding åt oss (inte master, men slav, respektive), förlitar den sig på Unix-tiden för sin egen maskin eller på tiden för "mästaren"; Synkas den för första gången eller periodvis?

MT: – Jag ska förtydliga nu. Shard (dvs horisontell partition) – det finns alltid en primär där. Och en skärva kan ha en "mästare" och det kan finnas repliker. Men skärvan stöder alltid inspelning, eftersom den måste stödja någon domän (skärvan har Primär).

PÅ: – Så allt beror enbart på "mästaren"? Används alltid mästartid?

MT: - Ja. Du kan bildligt talat säga: klockan tickar när ett inträde i "master", i "Oplog" inträffar.

PÅ: – Vi har en kund som ansluter och inte behöver veta något om tiden?

MT: – Du behöver inte veta något alls! Om vi ​​pratar om hur det fungerar på klienten: när klienten vill använda Causal konsekvens måste han öppna en session. Nu finns allt där: transaktioner i sessionen, och hämta en rättighet... En session är beställningen av logiska händelser som inträffar med klienten.

Om han öppnar den här sessionen och där säger att han vill ha orsakskonsistens (om sessionen stöder orsakskonsistens som standard), fungerar allt automatiskt. Föraren kommer ihåg denna tid och ökar den när den får ett nytt meddelande. Den kommer ihåg vilket svar den föregående returnerade från servern som returnerade data. Nästa begäran kommer att innehålla afterCluster("tid längre än detta").

Kunden behöver inte veta absolut någonting! Detta är helt ogenomskinligt för honom. Om människor använder dessa funktioner, vad kan de göra? För det första kan du säkert läsa sekundärer: du kan skriva till Primär och läsa från geografiskt replikerade sekundärer och vara säker på att det fungerar. Samtidigt kan sessioner som spelades in på Primary till och med överföras till Secondary, d.v.s. du kan använda inte en session, utan flera.

PÅ: – Ett nytt lager av beräkningsvetenskap – CRDT (Conflict-free Replicated Data Types) datatyper – är starkt relaterat till ämnet Eventuell konsekvens. Har du funderat på att integrera den här typen av data i databasen och vad kan du säga om det?

MT: - Bra fråga! CRDT är vettigt för skrivkonflikter: i MongoDB, single master.

PÅ: – Jag har en fråga från devops. I den verkliga världen finns det sådana jesuitiska situationer när det bysantinska misslyckandet inträffar, och onda människor innanför den skyddade omkretsen börjar peta in i protokollet, skicka hantverkspaket på ett speciellt sätt?

MT: – Onda människor innanför omkretsen är som en trojansk häst! Onda människor innanför omkretsen kan göra många dåliga saker.

PÅ: – Det är tydligt att lämna, grovt sett, ett hål i servern genom vilket man kan trycka en djurpark av elefanter och kollapsa hela klungan för alltid... Det kommer att ta tid för manuell återställning... Detta, milt uttryckt, är fel. Å andra sidan är detta intressant: i verkligheten, i praktiken, finns det situationer när naturligt liknande interna attacker inträffar?

MT: – Eftersom jag sällan stöter på säkerhetsintrång i verkliga livet kan jag inte säga om de inträffar. Men om vi pratar om utvecklingsfilosofin tänker vi så här: vi har en omkrets som ger killarna som gör säkerhet - det här är ett slott, en mur; och innanför omkretsen kan du göra vad du vill. Det är tydligt att det finns användare med möjligheten att bara visa, och det finns användare med möjlighet att radera katalogen.

Beroende på rättigheterna kan skadan som användare kan göra vara en mus, eller det kan vara en elefant. Det är tydligt att en användare med fullständiga rättigheter kan göra vad som helst. En användare med begränsade rättigheter kan orsaka betydligt mindre skada. I synnerhet kan det inte bryta systemet.

PÅ: – I den skyddade omkretsen försökte någon skapa oväntade protokoll för servern för att fullständigt förstöra servern, och om du har tur, hela klustret... Blir det någonsin så "bra"?

MT: "Jag har aldrig hört talas om sådana saker." Att du kan krascha en server på detta sätt är ingen hemlighet. Misslyckas inuti, är från protokollet, är en auktoriserad användare som kan skriva något liknande i meddelandet... Det är faktiskt omöjligt, eftersom det fortfarande kommer att verifieras. Det är möjligt att inaktivera denna autentisering för användare som inte vill ha den - då är det deras problem; de, grovt sett, förstörde själva väggarna och du kan trycka in en elefant där, som kommer att trampa... Men generellt sett kan du klä ut dig till en reparatör, kom och dra ut den!

PÅ: – Tack för rapporten. Sergey (Yandex). Det finns en konstant i Mong som begränsar antalet röstberättigade medlemmar i replikuppsättningen, och denna konstant är 7 (sju). Varför är detta en konstant? Varför är inte detta någon slags parameter?

MT: – Vi har Replica Sets med 40 noder. Det finns alltid en majoritet. Jag vet inte vilken version...

PÅ: – I Replica Set kan du köra medlemmar som inte har rösträtt, men det finns maximalt 7 röstberättigade medlemmar. Hur kan vi överleva avstängningen i det här fallet om vår Replica Set är spridd över 3 datacenter? Ett datacenter kan enkelt stängas av, och en annan maskin kan ramla ut.

MT: – Det här ligger redan lite utanför rapportens ram. Detta är en allmän fråga. Jag kanske kan berätta om det senare.

Några annonser 🙂

Tack för att du stannar hos oss. Gillar du våra artiklar? Vill du se mer intressant innehåll? Stöd oss ​​genom att lägga en beställning eller rekommendera till vänner, moln VPS för utvecklare från $4.99, en unik analog av ingångsservrar, som uppfanns av oss för dig: Hela sanningen om VPS (KVM) E5-2697 v3 (6 kärnor) 10GB DDR4 480GB SSD 1Gbps från $19 eller hur delar man en server? (tillgänglig med RAID1 och RAID10, upp till 24 kärnor och upp till 40 GB DDR4).

Dell R730xd 2 gånger billigare i Equinix Tier IV datacenter i Amsterdam? Bara här 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV från $199 i Nederländerna! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - från $99! Läs om Hur man bygger infrastructure corp. klass med användning av Dell R730xd E5-2650 v4-servrar värda 9000 XNUMX euro för en slant?

Källa: will.com