Nuxeo und MongoDBIn Paris hat vor Kurzem eine MongoDB-Entwicklerkonferenz an einem schönen Veranstaltungsort auf den Champs Elysees stattgefunden. Es war eine gute Gelegenheit viele MongoDB-Fans und Personen zu treffen, die daran interessiert waren, was NoSQL und MongoDB leisten können. Während der 9-stündigen Konferenz wurde einem vollen Haus eine Menge toller Content präsentiert.

Hier einige Eindrücke vom MongoDB-Tag in Paris.

WiredTiger


Einer der Vorträge befasste sich mit dem WiredTiger-Speichermodul, das in MongoDB 3.0 noch optional ist, ab Version 3.2 Standard jedoch werden soll. Der größte Vorteil von WiredTiger gegenüber dem MMAPV1-Speicher scheint in der besseren gleichzeitigen Verwaltungsstrategie zu liegen (Dokumentebene), die eine bessere Leistung für Schreibvorgänge ermöglicht.

Kürzlich haben wir mithilfe der Nuxeo Platform und MongoDB Vergleichswerte eingerichtet.

Nuxeo/MongoDB-Vergleichswerte

Mit diesen neuen Vergleichswerten haben wir einige Tests durchgeführt, um die beiden Speichermodule MMAPv1 und WiredTiger zu vergleichen.

Die Ergebnisse:


  • Die Leseleistung ist ungefähr gleich.

  • Bei Schreibvorgängen ist WiredTiger bis zu 2,5-mal schneller als MMAPV1 (und 5-mal schneller als SQL).


Vergleichswerte Massenimport

Operations Manager


Der Großteil der Konfigurationen und der Verwaltung von MongoDB wird durch die Befehlszeilen-Shell durchgeführt. Als Entwickler finde ich das sehr praktisch und ich denke, einem DevOps würde es genauso gehen. Wenn es jedoch um die Verwaltung eines großen Clusters geht, kann dies schnell zu einem Problem werden.

Es sieht so aus, als wäre Ops Manager eine tolle Lösung für eine Oberfläche für die Webverwaltung und um zu vermeiden, dass Hunderte von Befehlszeilen in 10 verschiedenen Shells in der richtigen Reihenfolge ausgeführt werden müssen. Diese Präsentation hat gut erklärt, wie nützlich Ops Manager sein kann, wenn Sie für die Knoten in einem Cluster ein paralleles Upgrade durchführen möchten.

In Nuxeo haben wir ein ähnliches Problem: mithilfe von nuxeoctl und der Nuxeo-Shell kann viel ausgeführt werden, bei der Verwaltung eines Clusters fehlt jedoch eine zentrale Web-Oberfläche für die Verwaltung, um die verschiedenen Knoten zu koordinieren.

Die Designprinzipien von Ops Manager sind einfach, aber ansprechend. Aus diesem Grund ziehen wir eine ähnliche Architektur für die Bereitstellung eines Nuxeo-Clustermanagers in Betracht.

Nuxeo und MongoDB


Wir haben eine kleine Präsentation gemacht, in der wir erklären, warum wir MongoDB in die Nuxeo Platform integriert haben, wie wir diese Integration geschafft haben und welche Vorteile diese Integration bietet. Die Folien sind online verfügbar. An anderen Events zu MongoDB werden wir eine gekürzte Version dieser Präsentation vorstellen:

Über MongoDB 3.2


Es sieht so aus, als würden in MongoDB 3.2 viele neue Funktionen eingeführt werden. Dies sind meiner Meinung nach die interessantesten Punkte:

Validierung von Dokumenten


Ich weiß, dass vielen die Schemalosigkeit von MongoDB gefällt. Sogar ich kann die Freude an der Unabhängigkeit verstehen, habe jedoch meine Bedenken, ob Ops-Anhänger damit glücklich sind.

Die Tatsache, dass die Enterprise Toolbox Tools wie MongoDB Compass bereitstellt, um die Schemen im Grunde zurückzuentwickeln, ist der Beweis dafür, dass echte Schemadefinitionen auf Anwendungsebene zumindest für Operationen Sinn ergeben. Wenn Sie einmal das Schema durchschaut haben, ergibt es außerdem Sinn, einige Einschränkungen auf Speicherebene definieren zu können. Es sieht so aus, als wäre die "Validierung von Dokumenten" so etwas.

Für diejenigen, die MongoDB über die Nuxeo Platform verwenden, wirkt es sich nicht so sehr aus, da die Repository-Ebene auf MongoDB diese Validierungslogik schon bearbeitet, die die Oberfläche schön zum Vorschein bringen. Der interne Standpunkt von Nuxeo DBS ist möglicherweise etwas, das wir haben wollen, um Schemen in der schemalosen Datenbank besser verwalten zu können.
<!--

In-Memory-Speichermodul


Ein echtes In-Memory-Speichermodul bietet sehr wahrscheinlich eine erstklassige Leistung. Wenn es jedoch keine Datendauerhaftigkeit gibt, sind die Anwendungsfälle eingeschränkt. Hoffentlich liegt das Highlight der Modularität der Storage-Engine in der Möglichkeit, im selben Replikatsatz unterschiedliche Storage-Engines zu haben. Das bedeutet, dass der Master "In-Memory"-Speicher für eine rasend schnelle Leistung verwenden kann, während die anderen Member des Replikatsatzes WiredTiger für eine "mögliche Persistenz" verwenden können..

Auf gewisse Weise ist dies nah dran an dem, was wir mit Redis machen: Wir verwenden In-Memory-Redis zum Speichern der Caches und zur Verarbeitung der Warteschlangen, haben aber Redis-Persistenz, um zu "sichern, was sich im Speicher befindet".
-->

BI-Connector&-Suche


Schon in der Entwicklerdokumentation war ersichtlich, dass MongoDB einen neuen $lookup integriert hat. Dabei handelt es sich um eine einfache Verknüpfung zwischen Sammlungen und wahrscheinlich um den Grundstein für den BI-Connector, der SQL im MongoDB-Abfrage- und Aggregations-Framework übersetzt.

Auf Seite von Nuxeo brauchen wir diese Verknüpfung nicht wirklich, da alle Daten für ein Repository in einer Kollektion verfügbar sind. Aber:


  • Der SQL-Zugriff auf in MongoDB gespeicherte Daten von Nuxeo ist wirklich sinnvoll.

  • Über einfache Verknüpfungen zwischen Kollektionen könnte die Nuxeo Platform Auditdaten in MongoDB speichern, während gleichzeitig Analysen basierend auf Repository- und Auditdaten ausgeführt werden können.


Es sieht also so aus, als müssten wir bald MongoDB 3.2 mit der Nuxeo Platform testen!