{"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\/de\/blog\/administrirovanie\/highload-mihail-tyulenev-mongodb-causal-consistency-ot-teorii-k-praktike","title":{"rendered":"HighLoad++, Mikhail Tyulenev (MongoDB): Kausale Konsistenz: Von der Theorie zur Praxis","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Die n\u00e4chste Konferenz HighLoad++ findet am 6. und 7. April 2020 in Sankt Petersburg statt.
\nDetails und Tickets unter diesem Link<\/a><\/noindex>. HighLoad++ Sibirien 2019. Saal \u201eKrasnojarsk\u201c. 25. Juni, 12:00. Thesen und Pr\u00e4sentation<\/a><\/noindex>.<\/p>\n

\"HighLoad++,
\n
\nEs kommt vor, dass praktische Anforderungen mit der Theorie in Konflikt stehen, in der wichtige Aspekte f\u00fcr ein kommerzielles Produkt nicht ber\u00fccksichtigt werden. In diesem Vortrag wird der Prozess der Auswahl und Kombination verschiedener Ans\u00e4tze zur Erstellung von Komponenten f\u00fcr die kausale Konsistenz basierend auf akademischen Forschungsergebnissen beschrieben, die aus den Anforderungen eines kommerziellen Produkts abgeleitet sind. Die Zuh\u00f6rer erfahren von bestehenden theoretischen Ans\u00e4tzen zu logischen Uhren, Abh\u00e4ngigkeitsverfolgung, Systemsicherheit, Zeitsynchronisation und warum MongoDB sich f\u00fcr bestimmte L\u00f6sungen entschieden hat.<\/a><\/noindex><\/p>\n

Mikhail Tyulenev (im Folgenden \u2013 MT):<\/b> \u2013 Ich werde \u00fcber kausale Konsistenz sprechen \u2013 eine Funktion, an der wir bei MongoDB gearbeitet haben. Ich arbeite in der Gruppe f\u00fcr verteilte Systeme, wir haben sie vor etwa zwei Jahren entwickelt.<\/p>\n

\"HighLoad++,
\n
\nIm Verlauf musste ich mich mit einer Vielzahl akademischer Forschung auseinandersetzen, weil diese Funktion recht gut untersucht ist. Es stellte sich heraus, dass keine der Ver\u00f6ffentlichungen den Anforderungen im Produktionsumfeld entspricht, da die spezifischen Anforderungen, die in jeder Produktionsanwendung vorhanden sind, ber\u00fccksichtigt werden m\u00fcssen.<\/p>\n

Ich werde dar\u00fcber sprechen, wie wir, als Verbraucher akademischer Forschung, daraus etwas erstellen, das wir unseren Nutzern als fertiges Produkt anbieten k\u00f6nnen, das einfach und sicher zu verwenden ist.<\/p>\n

Kausale Konsistenz. Lassen Sie uns die Begriffe kl\u00e4ren<\/h3>\n

\nZun\u00e4chst m\u00f6chte ich in groben Z\u00fcgen erl\u00e4utern, was kausale Konsistenz ist. Es gibt zwei Charaktere \u2013 Leonard und Penny (aus der Serie \u201eThe Big Bang Theory\u201c):<\/p>\n

\"HighLoad++,
\n
\nAngenommen, Penny ist in Europa und Leonard m\u00f6chte ihr eine \u00dcberraschung, eine Party, machen. Und er denkt sich nichts Besseres aus, als sie aus seiner Freundesliste zu entfernen und allen Freunden ein Update im Feed zu schicken: \u201eLasst uns Penny erfreuen!\u201c (sie ist in Europa, w\u00e4hrend sie schl\u00e4ft, sieht sie das alles nicht und kann es nicht sehen, weil sie nicht dort ist). Schlie\u00dflich l\u00f6scht er diesen Beitrag, entfernt ihn aus dem Feed und stellt den Zugang wieder her, sodass sie nichts bemerkt und es keinen Skandal gibt.
\nDas ist alles wunderbar, aber nehmen wir an, das System ist verteilt und die Ereignisse laufen nicht ganz so ab. Es k\u00f6nnte zum Beispiel passieren, dass die Zugriffsbeschr\u00e4nkung von Penny eintrat, nachdem dieser Beitrag erschienen ist, wenn die Ereignisse nicht durch kausale Zusammenh\u00e4nge verbunden sind. Das ist ein Beispiel daf\u00fcr, wann kausale Konsistenz erforderlich ist, um eine Gesch\u00e4ftsanforderung zu erf\u00fcllen (in diesem Fall).<\/p>\n

Tats\u00e4chlich sind dies ziemlich nicht-triviale Eigenschaften von Datenbanken \u2013 nur sehr wenige unterst\u00fctzen sie. Lassen Sie uns zu den Modellen \u00fcbergehen.<\/p>\n

Konsistenzmodelle<\/h3>\n

\nWas ist \u00fcberhaupt ein Konsistenzmodell in Datenbanken? Es sind bestimmte Garantien, die ein verteiltes System bez\u00fcglich der Daten und der Reihenfolge, in der der Kunde sie erhalten kann, gibt.<\/p>\n

Im Grunde h\u00e4ngen alle Konsistenzmodelle davon ab, wie sehr ein verteiltes System einer solchen Architektur \u00e4hnelt, die beispielsweise auf einem einzigen Node auf einem Laptop l\u00e4uft. Und wie sehr sich ein System, das auf Tausenden von geografisch verteilten Nodes arbeitet, von einem Laptop unterscheidet, in dem all diese Eigenschaften prinzipiell automatisch erf\u00fcllt sind.<\/p>\n

Deshalb gelten Konsistenzmodelle nur f\u00fcr verteilte Systeme. Alle Systeme, die fr\u00fcher existierten und auf vertikaler Skalierung basierten, hatten solche Probleme nicht. Dort gab es einen Buffer Cache, aus dem alles stets abgerufen wurde.<\/p>\n

Starke Modell<\/h3>\n

\nDie tats\u00e4chlich erste Modell ist das Starke (oder auch Riseability, wie es oft genannt wird). Es handelt sich um ein Konsistenzmodell, das garantiert, dass jede \u00c4nderung, sobald die Best\u00e4tigung vorliegt, dass sie erfolgt ist, von allen Nutzern des Systems gesehen werden kann.<\/p>\n

Das schafft eine globale Reihenfolge aller Ereignisse in der Datenbank. Dies ist eine sehr starke Konsistenzeigenschaft und sie ist insgesamt sehr kostenintensiv. Dennoch wird sie sehr gut unterst\u00fctzt. Sie ist einfach sehr teuer und langsam \u2013 daher wird sie selten genutzt. Das nennt man Riseability.<\/p>\n

Es gibt eine weitere, st\u00e4rkere Eigenschaft, die im Spanner unterst\u00fctzt wird \u2013 sie wird externe Konsistenz genannt. Dar\u00fcber werden wir sp\u00e4ter sprechen.<\/p>\n

Kausal<\/h3>\n

\nDas N\u00e4chste ist Causal, genau das, wor\u00fcber ich gesprochen habe. Zwischen Strong und Causal gibt es noch einige Unterebenen, \u00fcber die ich nicht sprechen werde, aber sie alle reduzieren sich auf Causal. Dieses Modell ist wichtig, weil es das st\u00e4rkste von allen Modellen ist, die st\u00e4rkste Konsistenz bei Vorhandensein von Netzwerken oder Partitionen.<\/p>\n

Causals sind die Situation, in der Ereignisse durch eine kausale Beziehung verbunden sind. Sehr oft werden sie aus der Perspektive des Kunden als Read your own rights wahrgenommen. Wenn der Kunde bestimmte Werte beobachtet hat, kann er die Werte, die in der Vergangenheit waren, nicht sehen. Er beginnt bereits, pr\u00e4fixartige Lesevorg\u00e4nge zu sehen. Das alles l\u00e4uft auf dasselbe hinaus.
\nCausals als Konsistenzmodell bedeutet eine partielle Ordnung von Ereignissen auf dem Server, bei der die Ereignisse von allen Clients in derselben Reihenfolge beobachtet werden. In diesem Fall - Leonard und Penny.<\/p>\n

Eventual<\/h3>\n

\nDas dritte Modell ist die Eventual Consistency. Das ist das, was alle verteilten Systeme unterst\u00fctzen, das Mindestmodell, das \u00fcberhaupt sinnvoll ist. Es bedeutet Folgendes: Wenn wir \u00c4nderungen an den Daten vornehmen, werden sie irgendwann konsistent.<\/p>\n

In diesem Moment sagt es nichts, sonst w\u00fcrde es zur External Consistency werden - das w\u00e4re eine ganz andere Geschichte. Dennoch ist dies ein sehr beliebtes Modell, das am weitesten verbreitet ist. Standardm\u00e4\u00dfig verwenden alle Benutzer verteilter Systeme tats\u00e4chlich die Eventual Consistency.<\/p>\n

Ich m\u00f6chte einige vergleichende Beispiele anf\u00fchren:<\/p>\n

\"HighLoad++,
\n
\nWas bedeuten diese Pfeile?<\/p>\n