{"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\/nl\/blog\/administrirovanie\/highload-mihail-tyulenev-mongodb-causal-consistency-ot-teorii-k-praktike","title":{"rendered":"HighLoad++, Mikhail Tyulenev (MongoDB): Causale consistentie: van theorie naar praktijk","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

De volgende HighLoad++ conferentie vindt plaats op 6 en 7 april 2020 in Sint-Petersburg.
\nDetails en tickets via de link<\/a><\/noindex>. HighLoad++ Siberia 2019. Zaal \"Krasnojarsk\". 25 juni, 12:00. Samenvattingen en presentatie<\/a><\/noindex>.<\/p>\n

\"HighLoad++,
\n
\nSoms lopen praktische vereisten vooruit op de theorie, waarin belangrijke aspecten voor een commercieel product niet zijn meegenomen. In deze presentatie wordt het proces gepresenteerd van het kiezen en combineren van verschillende benaderingen voor het cre\u00ebren van componenten voor Causal consistency, gebaseerd op academisch onderzoek en de vereisten van commerci\u00eble producten. De luisteraars zullen leren over bestaande theoretische benaderingen van logical clocks, dependency tracking, system security, clock synchronization, en waarom MongoDB bepaalde oplossingen heeft gekozen.<\/a><\/noindex><\/p>\n

Mikhail Tyulenev (hierna - MT):<\/b> - Ik ga vertellen over Causal consistency \u2013 een functie waar we bij MongoDB aan hebben gewerkt. Ik werk in de groep voor gedistribueerde systemen, we hebben dit ongeveer twee jaar geleden gerealiseerd.<\/p>\n

\"HighLoad++,
\n
\nIn het proces moest ik veel academisch onderzoek bestuderen, omdat deze functie goed is bestudeerd. Het bleek dat geen enkele paper volledig voldoet aan wat er nodig is in productie, in een database, gezien de zeer specifieke vereisten die er waarschijnlijk zijn in elke productieapplicatie.<\/p>\n

Ik ga vertellen hoe we, als gebruikers van academisch onderzoek, daar iets van bereiden dat we vervolgens aan onze gebruikers kunnen presenteren als een kant-en-klaar gerecht, dat handig en veilig te gebruiken is.<\/p>\n

Causale consistentie (Causal consistency). Laten we de begrippen defini\u00ebren.<\/h3>\n

\nOm te beginnen wil ik in het algemeen zeggen wat Causal consistency is. Er zijn twee personages \u2013 Leonard en Penny (serie 'The Big Bang Theory'):<\/p>\n

\"HighLoad++,
\n
\nStel je voor dat Penny in Europa is, en Leonard een verrassing voor haar wil organiseren. En hij komt niet met iets beters dan haar uit zijn vriendenlijst te gooien, en alle vrienden een update op hun feed te sturen: \"Laten we Penny blij maken!\" (ze is in Europa, terwijl ze slaapt, kan dit allemaal niet zien en kan het niet zien omdat ze er niet is). Op een gegeven moment verwijdert hij deze post, wist het uit de \"feed\" en herstelt de toegang, zodat ze er niets van merkt en er geen rel ontstaat.
\nDit is allemaal geweldig, maar laten we aannemen dat het systeem gedistribueerd is en de gebeurtenissen niet helemaal zoals verwacht verlopen. Het kan bijvoorbeeld gebeuren dat de access beperking van Penny plaatsvond nadat deze post verschenen is, als de gebeurtenissen niet causaal met elkaar verbonden zijn. Dit is in feite een voorbeeld van wanneer Causal consistency nodig is om een zakelijke functie uit te voeren (in dit geval).<\/p>\n

Eigenlijk zijn dit best complexe eigenschappen van databases - heel weinig functies ondersteunen ze. Laten we verder gaan met de modellen.<\/p>\n

Consistentiemodellen<\/h3>\n

\nWat is een consistentiemodel in databases eigenlijk? Dit zijn bepaalde garanties die een gedistribueerd systeem biedt over welke gegevens en in welke volgorde een cli\u00ebnt kan ontvangen.<\/p>\n

In principe komen alle consistentiemodellen neer op de vraag in hoeverre een gedistribueerd systeem lijkt op een systeem dat bijvoorbeeld op \u00e9\u00e9n node op een laptop draait. En in hoeverre lijkt een systeem dat draait op duizenden geografisch verspreide 'nodes' op een laptop, waarin al deze eigenschappen in principe automatisch worden uitgevoerd.<\/p>\n

Daarom zijn consistentiemodellen alleen van toepassing op gedistribueerde systemen. Alle systemen die eerder bestonden en werkten met verticale schaalvergroting hebben dergelijke problemen niet ervaren. Daar was er \u00e9\u00e9n Buffer Cache, en daaruit werd altijd alles gelezen.<\/p>\n

Sterk model<\/h3>\n

\nEigenlijk is het eerste model - het Sterke model (of zoals het vaak wordt genoemd, de rise ability lijn). Dit is een consistentiemodel dat garandeert dat elke wijziging, zodra de bevestiging dat deze heeft plaatsgevonden is ontvangen, voor alle gebruikers van het systeem zichtbaar wordt.<\/p>\n

Dit cre\u00ebert een wereldwijde volgorde van alle gebeurtenissen in de database. Dit is een zeer sterke eigenschap van consistentie, en het is ook zeer kostbaar. Desondanks wordt het goed ondersteund. Het is gewoon heel duur en langzaam - men maakt er gewoon zelden gebruik van. Dit wordt rise ability genoemd.<\/p>\n

Er is nog een andere, sterkere eigenschap die wordt ondersteund in 'Spanner' - dit wordt externe consistentie genoemd. We zullen dit later bespreken.<\/p>\n

Causaal<\/h3>\n

\nHet volgende is Causal, precies waar ik het over had. Tussen Strong en Causal zijn er nog een aantal subniveaus waar ik niet over zal spreken, maar deze komen allemaal neer op Causal. Dit is een belangrijk model, omdat het het sterkste is van alle modellen, met de sterkste consistentie in het geval van een netwerk of partities.<\/p>\n

Causals zijn eigenlijk de situatie waarin gebeurtenissen causaal met elkaar verbonden zijn. Vaak worden ze gezien als Read your on rights vanuit het perspectief van de klant. Als een klant bepaalde waarden heeft waargenomen, kan hij de waarden van het verleden niet meer zien. Hij begint al prefix readings te zien. Dit komt allemaal op hetzelfde neer.
\nCausals als model van consistentie \u2013 een gedeeltelijke ordening van gebeurtenissen op de server, waarbij gebeurtenissen van alle klanten in dezelfde volgorde worden waargenomen. In dit geval \u2013 Leonard en Penny.<\/p>\n

Eventual<\/h3>\n

\nHet derde model is Eventual Consistency. Dit is wat absoluut alle gedistribueerde systemen ondersteunen, het minimale model dat \u00fcberhaupt zinvol is. Het betekent het volgende: wanneer we bepaalde wijzigingen in de gegevens aanbrengen, worden deze op een gegeven moment consistent.<\/p>\n

Op dat moment zegt het niets, anders zou het in External Consistency veranderen \u2013 dat zou een heel ander verhaal zijn. Toch is dit een zeer populair model, het meest voorkomende. Standaard gebruiken alle gebruikers van gedistribueerde systemen inderdaad Eventual Consistency.<\/p>\n

Ik wil een paar vergelijkende voorbeelden geven:<\/p>\n

\"HighLoad++,
\n
\nWat betekenen deze pijlen?<\/p>\n