MongoDB 4.0 Non-Blocking Secondary Reads im Replica Set

by Marc-David Militz Forum: Neuigkeiten

MongoDB 4.0 bringt als neues Feature das Lesen von einem Secondary, während die Replikation gleichzeitig Schreiboperation ausführt. Um zu verstehen warum das Wichtig ist muß man sich die Funktion der Secondaries in den Vorgängerversionen ansehen.

• Hintergrund

MongoDB wurde so designed, daß jede Sequenz von Schreiboperationen auf dem Primary, von jedem Secondary in der gleichen Reihenfolge ausgeführt werden muß. Wenn man also erst Feld A in einem Dokument ändert und dann Feld B, ist es nicht möglich das Dokument mit geändertem Feld B, aber nicht geändertem Feld A abzurufen. Die "eventuall consitency" würde das zwar zulassen, aber MongoDB hat das nie getan und wird das auch nie tun.

Auf den Secondary Nodes werden die Schreiboperationen in Batches abgearbeitet, denn eine sequentielle Abarbeitung würde dazu führen, daß der Secondary zurückfällt. Um die Änderungen durchzuführen müssen, vorübergehend, die lesenden Zugriffe geblockt werden. Andernfalls würden partielle Änderungen sichtbar werden. Lesende Zugriffe auf Secondaries müssen als immer wieder auf die Batch-Updates warten. Je Größer dabei die Schreiblast, desto größer die Wahrscheinlichkeit, daß ein Secondary eine solche "Pause" einlegt, was sich natürlich auf die Antwortzeiten auswirkt.

Auf der anderen Seite braucht es auch für den Schreibzugriff einen Lock, um lesende Zugriffe zu verhindern, bevor die Schreiboperationen ausgeführt werden können.


• Das Ziel für MongoDB 4.0

Das Ziel für das kommende Release war es nun, Leseoperationen zuzulassen während das replizierte Oplog auf dem Secondary angewendet wird und damit dem maximalen Durchsatz des Replica Sets zu erhöhen. Bei Installationen mit einer hohen Schreiblast sollte man nicht länger auf lesende Zugriffe warten müssen und auf diese Weise eine schnellere Bestätigung des Schreibvorgangs erreichen. Was sich am Ende in einem geringen Druck auf den Primary und einer verbesserten Gesamtperformance wiederspiegelt.

Diese Änderung zu implementieren wurde interessanter Weise durch die Unterstützung von Timestamps in der Storage Engine ermöglicht. Diese werden benötigt um den Transaktionen einen konsistenten Ausschnitt der Daten zu ermöglichen. Eine detailliertere Erklärung zu der Implementierung findet sich hier:
https://www.mongodb.com/presentations/wiredtiger-timestamps-enforcing-correctness-in-operation-ordering-across-the-distributed-storage-layer

Ganz einfach Formuliert kann man sagen, durch die Transaktionen entstehen "Snapshots" der Daten und durch den Zugriff auf diese Snapshots greift man immer auf einen konsistenten Datenbestand zu.


• Wie viel Unterschied macht das?

Kurz gesagt, eine Menge! Der Umfang der Performanceverbesserungen für den Durchsatz beginnt bei Null, wenn eine Applikation gar nicht vom Replikations-Lock betroffen ist bis hin zu Secondaries, auf die mit der read-preference "nearest" zugegriffen wird. Damit soll ja die Latenz zwischen der Applikation und der Datenbank gesenkt werden, deshalb sollte auch die Latenz innerhalb der Datenbank so gering wie möglich sein. MongoDB selbst gibt für diese Fälle eine Verbesserung zwischen 95% und 99% an. Das Beste an diesem Feature ist daß man überhaupt nichts tun muß um es zu aktivieren, denn es ist das Standardverhalten für Secondaries in der Version 4.0.

Weitere Interessante Neuerungen und Vorteile beim Einsatz von MongoDB erfahren sie beim eintägigen Qualiero Entscheider Workshop zu MongoDB
https://www.qualiero.com/lerninhalte/classroom-trainings/mongodb-entscheider-workshop.html