Quelloffene NoSQL-Datenbank MongoDB 3.0 öffnet sich neuen Speicher-Engines

Das Team hinter MongoDB hat die Version 3.0 der quelloffenen Datenbank veröffentlicht. Wie Anfang Februar angekündigt enthält sie zahlreiche Neuerungen, die sich positiv auf Speicherverbrauch und Leistungsfähigkeit auswirken sollen. Besonders stellen die Entwickler die MongoDB Storage Engine API heraus, die es erleichtern soll, neue Speicher-Engines für spezielle Anwendungsfälle zu erstellen und sie in MongoDB einzubinden.

Im Auslieferungszustand enthält das neue Release zwei Engines. So steht mit MMAPv1 (Memory Mapped Version 1) eine verbesserte Variante der zuvor in MongoDB genutzten Engine bereit, während WiredTiger als Neuzugang mit besonderen Kompressionsmöglichkeiten und besseren Optionen für Nebenläufigkeit punkten soll. MongoDB hatte WiredTiger 2014 eingekauft. Die Engine wurde von den Architekten von Berkeley DB entwickelt und soll unter anderem durch den Einsatz nicht blockierender Algorithmen mehr Operationen pro CPU-Kern durchführen können als andere Produkte. Kompakte Dateiformate und Kompression nach Bedarf sollen zudem den Overhead auf der Festplatte und beim In- und Output reduzieren.

Automatisierung und Logging

In MongoDB Enterprise Advanced steht nun ein Ops Manager zur Verfügung. Er soll dabei helfen, manuelle Tätigkeiten in automatisierte Vorgänge umzuwandeln, damit beim Ausführen weniger Fehler auftreten können. Hierunter fallen etwa Deploys oder das Hinzufügen ergänzender Ressourcen (Scaling-Vorgänge), aber auch Überwachungsszenarien und Back-ups lassen sich wohl mit dem Manager realisieren. Die Komponente ist mit einer RESTful API versehen, sodass sich auch mit anderen Monitoring-Tools zusammenarbeiten lässt.

Was Überwachung beziehungsweise Kontrolle angeht, gibt es auch darüber hinaus einige Änderungen. Mit dem in MongoDB 2.6 eingeführten Auditing Framework lassen sich nun wohl auch lesend und schreibend zugreifende Operationen auf eine Datenbank loggen und ohne zusätzliche Tools Audit Trails erstellen und filtern. Administratoren sollen zudem in der Lage sein, alle Aktionen zu loggen oder Filter für bestimmte Aktionen, Nutzer oder Rollen zu erstellen. Auditing nach Rollen war zuvor nicht möglich. Beim Einsatz dieser Mechanismen ist zu bedenken, dass alle Aufzeichungsvorgänge Ressourcen benötigen und daher eine Beschränkung auf das Loggen wirklich notwendiger Vorgänge sinnvoll ist.

Weitere Neuerungen, zu denen etwa das Erhöhen der Nutzermenge auf Replica-Sets von 12 auf 50 und Ergänzungen in der Abfragesprache und den zugehörigen Tools gehören, lassen sich nach Registrierung in einem White Paper nachlesen. Im Blogeintrag zur Bekanntmachung sind außerdem die Gewinner des Bug-Hunt-Programms verzeichnet. (jul)