{"id":56365,"date":"2020-02-11T00:00:00","date_gmt":"2020-02-10T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/highload-mihail-tyulenev-mongodb-causal-consistency-ot-teorii-k-praktike"},"modified":"2020-02-18T14:04:37","modified_gmt":"2020-02-18T11:04:37","slug":"highload-mihail-tyulenev-mongodb-causal-consistency-ot-teorii-k-praktike","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/highload-mihail-tyulenev-mongodb-causal-consistency-ot-teorii-k-praktike","title":{"rendered":"HighLoad++, Mikhail Tyulenev (MongoDB): Kausal konsistens: fra teori til praksis","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Den n\u00e6ste HighLoad++ konference finder sted den 6. og 7. april 2020 i Sankt Petersborg.
\nDetaljer og billetter via linket<\/a><\/noindex>. HighLoad++ Siberia 2019. Sal \"Krasnoyarsk\". 25. juni, 12:00. Abstracts og pr\u00e6sentation<\/a><\/noindex>.<\/p>\n

\"HighLoad++,
\n
\nNogle gange kan praktiske krav komme i konflikt med teorien, hvor vigtige aspekter for et kommercielt produkt ikke er taget i betragtning. I dette foredrag pr\u00e6senteres processen med at v\u00e6lge og kombinere forskellige tilgange til at skabe komponenter til Causal consistency baseret p\u00e5 akademisk forskning i overensstemmelse med kravene til det kommercielle produkt. Lytterne vil blive informeret om de eksisterende teoretiske tilgange til logiske ure, afh\u00e6ngighedssporing, system sikkerhed, tids synkronisering, og hvorfor MongoDB valgte de specifikke l\u00f8sninger.<\/a><\/noindex><\/p>\n

Mikhail Tyulenev (herefter \u2013 MT):<\/b> \u2013 Jeg vil tale om Causal consistency \u2013 en funktion, vi har arbejdet p\u00e5 i MongoDB. Jeg arbejder i gruppen for distribuerede systemer, og vi udviklede den for cirka to \u00e5r siden.<\/p>\n

\"HighLoad++,
\n
\nI processen blev det n\u00f8dvendigt at s\u00e6tte sig ind i en stor m\u00e6ngde akademisk forskning, da denne funktion er temmelig velunders\u00f8gt. Det viste sig, at ingen af artiklerne passede ind i, hvad der kr\u00e6ves i produktionen, databasen taget i betragtning de ret specifikke krav, der findes i n\u00e6rmest alle produktionsapplikationer.<\/p>\n

Jeg vil tale om, hvordan vi, som forbrugere af akademisk forskning, forbereder noget, som vi senere kan pr\u00e6sentere for vores brugere som en f\u00e6rdigret, der er komfortabel og sikker at bruge.<\/p>\n

Causal consistency. Lad os definere begreberne<\/h3>\n

\nFor det f\u00f8rste vil jeg gerne overordnet sige, hvad Causal consistency er. Der er to karakterer \u2013 Leonard og Penny (fra serien \"The Big Bang Theory\"):<\/p>\n

\"HighLoad++,
\n
\nLad os antage, at Penny er i Europa, og Leonard \u00f8nsker at lave en overraskelse for hende, en fest. Og han kan ikke finde p\u00e5 bedre end at fjerne hende fra vennelisten og sende alle vennerne en opdatering p\u00e5 feedet: \"Lad os gl\u00e6de Penny!\" (Hun er i Europa, mens hun sover, ser ikke det hele og kan ikke se det, fordi hun ikke er der). I sidste ende sletter han dette indl\u00e6g, fjerner det fra \"Feedet\" og gendanner adgangen, s\u00e5 hun ikke bem\u00e6rker noget, og der ikke opst\u00e5r en skandale.
\nDet er alt sammen godt, men lad os antage, at systemet er distribueret, og begivenhederne forl\u00f8b ikke helt som forventet. For eksempel kan det ske, at adgangen til Penny blev begr\u00e6nset efter, at dette indl\u00e6g blev oprettet, hvis begivenhederne ikke er forbundet med \u00e5rsagssammenh\u00e6nge. Faktisk er dette et eksempel p\u00e5, hvorn\u00e5r der er brug for Causal consistency for at udf\u00f8re en forretningsfunktion (i dette tilf\u00e6lde).<\/p>\n

I virkeligheden er dette ret ikke-trivielle egenskaber ved databaser \u2013 meget f\u00e5 af dem underst\u00f8tter dem. Lad os g\u00e5 videre til modellerne.<\/p>\n

Konsistensmodeller (Consistency Models)<\/h3>\n

\nHvad er egentlig en konsistensmodel i databaser? Det er nogle garantier, som et distribueret system giver vedr\u00f8rende, hvilke data og i hvilken r\u00e6kkef\u00f8lge klienten kan f\u00e5 dem.<\/p>\n

Grundl\u00e6ggende set reduceres alle konsistensmodeller til, hvor meget et distribueret system ligner et system, der f.eks. k\u00f8rer p\u00e5 en enkelt node p\u00e5 en laptop. Og i hvor h\u00f8j grad et system, der k\u00f8rer p\u00e5 tusinder af geospatialt distribuerede 'noder', ligner en laptop, hvor alle disse egenskaber principielt udf\u00f8res automatisk.<\/p>\n

Derfor g\u00e6lder konsistensmodeller kun for distribuerede systemer. Alle systemer, der tidligere eksisterede og fungerede med vertikal skalering, oplevede ikke disse problemer. Der var \u00e9t Buffer Cache, og alt blev altid l\u00e6st derfra.<\/p>\n

Model Strong<\/h3>\n

\nDen allerf\u00f8rste model er Strong (eller line rise ability, som den ofte kaldes). Det er en konsistensmodel, der garanterer, at hver \u00e6ndring, s\u00e5 snart den bekr\u00e6ftes, bliver synlig for alle brugere af systemet.<\/p>\n

Dette skaber en global r\u00e6kkef\u00f8lge af alle begivenheder i databasen. Det er en meget st\u00e6rk konsistensegenskab, og den er overhovedet meget kostbar. Ikke desto mindre underst\u00f8ttes den rigtig godt. Det er bare meget dyrt og langsomt \u2013 derfor bruges den sj\u00e6ldent. Det kaldes rise ability.<\/p>\n

Der er ogs\u00e5 en anden, st\u00e6rkere egenskab, der underst\u00f8ttes i 'Spanner' \u2013 det kaldes External Consistency. Vi vil tale om det lidt senere.<\/p>\n

Causal<\/h3>\n

\nDet f\u00f8lgende er Causal, som jeg netop talte om. Mellem Strong og Causal findes der flere underniveauer, som jeg ikke vil tale om, men de handler alle om Causal. Dette er en vigtig model, fordi den er den st\u00e6rkeste af alle modeller, det er den mest robuste konsistens i tilf\u00e6lde af netv\u00e6rk eller partitioner.<\/p>\n

Causals er faktisk den situation, hvor begivenheder er forbundet med en \u00e5rsagssammenh\u00e6ng. De opfattes ofte som Read your on rights fra kundens synspunkt. Hvis kunden har observeret nogle v\u00e6rdier, kan han ikke se de v\u00e6rdier, som var i fortiden. Han begynder allerede at se pr\u00e6fiks-l\u00e6sninger. Det hele handler om det samme.
\nCausals som konsistensmodel er en delvis r\u00e6kkef\u00f8lge af begivenheder p\u00e5 serveren, hvor begivenheder fra alle klienter observeres i den samme sekvens. I dette tilf\u00e6lde - Leonard og Penny.<\/p>\n

Eventual<\/h3>\n

\nDen tredje model er Eventual Consistency. Dette er noget, som alle distribuerede systemer underst\u00f8tter, den minimale model, der overhovedet giver mening. Det betyder f\u00f8lgende: n\u00e5r vi foretager nogle \u00e6ndringer i dataene, bliver de p\u00e5 et tidspunkt konsistente.<\/p>\n

I det \u00f8jeblik siger den ikke noget, ellers ville den v\u00e6re blevet til External Consistency - det ville have v\u00e6ret en helt anden historie. Ikke desto mindre er dette en meget popul\u00e6r model, den mest almindelige. Som standard bruger alle brugere af distribuerede systemer faktisk Eventual Consistency.<\/p>\n

Jeg vil gerne give nogle sammenlignende eksempler:<\/p>\n

\"HighLoad++,
\n
\nHvad betyder disse pile?<\/p>\n