Kausale Garantien in verteilten Systemen

by Marc-David Militz Forum: MongoDB Theorie

Traditionelle, relationale Datenbanken, die aufgrund ihrer Natur nur auf einem einzelnen Knoten lesen und schreiben können eine sequentiell geordnete Abarbeitung aller Lese- und Schreiboperationen garantieren. Dieses Prinzip wird "causal consistency" oder "kausale Konsistenz" genannt. Auch ein verteiltes System ist in der Lage diese Garantien zu leisten. Allerdings muss es dazu alle relevanten Events über alle Knoten hinweg koordinieren, was im Gegenzug limitiert, wie schnell bestimmte Operationen abgeschlossen werden können. Diese "kausale Konsistenz" ist relativ einfach zu verstehen, solange die Reihenfolge aller Datenzugriffe garantiert werden kann. Im Gegenzug dazu haben alle vertikal skalierenden Systeme im Falle von Systemfehlern, wie abstürzenden Nodes oder Netzwerkpartitionen, eine ganze Reihe von berechtigten Konsistenz- und Haltbarkeits-Kompromissen zu machen.

MongoDB arbeitet seit Jahren mit Jepsen Tests, die die Datenbank auch regelmäßig besteht. Zuletzt arbeitete man direkt mit dem Jepsen Team zusammen um MongoDB auf "kausale Konsistenz" zu testen. Dabei wurde erst so richtig bewußt wie komplex die Fehlermodi einer Datenbank werden, wenn man Konsistenzgarantien gegen Datendurchsatz und Aktualität eintauscht.

Die einzelnen Testfälle und Testergebnisse lassen sich, im Original Blog-Eintrag, bei MongoDB nachlesen. Hier wird dann auch auf die verschiedenen Kombinationsmöglichkeiten von Read- und Write-Concerns eingegangen.
https://engineering.mongodb.com/post/ryp0ohr2w9pvv0fks88kq6qkz9k9p3

Zusammenfassend kann man jedoch sagen, daß jede Operation die in einem System ausgeführt wird - egal ob es ein verteiltes System ist oder nicht - eine Reihe von Kompromissen erfordert, die das Verhalten der Applikation beeinflußt. Durch die Arbeit mit dem Jepsen Team wurde man bei MongoDB sensibler für die Kompromisse von Read- und Write-Concerns kombiniert mit "kausale Konsistenz". Aus diesem Grund empfiehlt MongoDB jetzt immer den Read Concern "majority" und den Write Concern "majority" in Kombination zu verwenden um kausale Garantien und Beständigkeit, über alle Fehlerszenarien hinweg, zu erhalten. Trotzdem können andere Kombinationen, speziell der Read Concern "majority" mit dem Write Concern "1", für bestimmte Anwendungen angemessen sein.

Durch das Angebot an unterschiedlichen Read- und Write Concerns sind Entwickler in der Lage die Konsistenz, Beständigkeit und Performance ihrer Workloads präzise zu tunen. Die Arbeit des MongoDB- mit dem Jepsen Team hilft hoffentlich das Verhalten der Datenbank in bestimmten Fehlerszenarien besser zu charakterisieren, so daß Entwickler bessere Entscheidungen bezüglich von Garantien und Kompromissen treffen können.

Wer einen Einstieg in MongoDB Architekturen und die damit verbundenen Garantien und Kompromisse sucht, für den bietet Qualiero einen "Sharded Cluster Administrator-Kurs", der direkt auf den regulären MongoDB Administrator-Kurs aufbaut
https://www.qualiero.com/lerninhalte/classroom-trainings/mongodb-fuer-sharded-cluster-administrator-kurs.html