Die NoSQL-Datenbank wird erwachsen

MongoDB 3.0 – Was ist neu?
Kommentare

Mit dem neuen Major-Release 3.0 von MongoDB werden vor allem nicht-funktionale Anforderungen wie Performance und Storage adressiert. Die wesentlichen Neuerungen, die mit dieser Version auf Sie zukommen, möchte ich Ihnen im Folgenden vorstellen.

API für Storage In früheren Versionen war das Handling der persistenten Datenstrukturen (also der Dokumente und Indexe) eng mit dem Rest der Datenbank verknüpft, nennen wir es mal wohlwollend eine monolithische Architektur. Durch die Einführung eines Storage-APIs wurde eine Abstraktion geschaffen, die es ermöglicht, verschiedene Implementierungen verwenden zu können. Die bisherige Storage-Engine, die auf dem Betriebssystem-Dienst mmap basiert, bekommt den Namen MMap_v1 und bleibt zunächst auf noch der Default. Ein Blick in die Sourcen zeigt, dass nun verschiedene Implementierung wie In Memory, RocksDB oder Wired Tiger vorliegen. Die Storage-Engine Wired Tiger ist Teil des 3.0er Releases, der Hersteller wurde auch direkt Ende 2014 Teil der MongoDB-Familie. Um Wired Tiger als Storage-Engine zu nutzen, verwenden Sie folgende Kommandozeilenoption.

$ mongod --dbpath ... --storageEngine wiredTiger

Neue Storage-Engine Wired Tiger

Die zentralen Features der Wired Tiger-Engine sind Kompression und ein Lock-Level auf Dokumenten-Ebene.

Die bisherige Storage-Engine MMap hat die Dokumente und Indexe Byte für Byte vom RAM auf Disk geschrieben und dabei pro logischer Datenbank eine oder mehrere Dateien verwendet. Wir verwenden ein Beispiel mit einer Collection, die ca. 60K Datensätze mit einer Gesamtgröße von ca. 82 MB enthält. Mit der MMap-Engine sieht das in etwa so aus:

drwxr-xr-x 1 4.0k Nov 27 2014 .
drwxr-xr-x 7 4.0k Nov 27 10:08 ..
drwxr-xr-x 1 0 Nov 27 10:11 _tmp
drwxr-xr-x 1 0 Nov 27 10:11 journal
-rw-r--r-- 1 64M Nov 27 09:48 local.0
-rw-r--r-- 1 16M Nov 27 09:48 local.ns
-rw-r--r-- 1 5 Nov 27 09:48 mongod.lock
-rw-r--r-- 1 64M Nov 27 10:11 twitter.0
-rw-r--r-- 1 128M Nov 27 10:11 twitter.1
-rw-r--r-- 1 16M Nov 27 10:11 twitter.ns

Die Wired Tiger-Engine schreibt die Daten komprimiert auf die Platte, wobei verschiedene Kompressionslevel konfiguriert werden können (none, snappy, zlib). Siehe dazu auch hier. Insgesamt legt Wired Tiger auch mehr Dateien an, nämlich eine oder mehrere pro Collection und pro Index:

-rw-r--r-- 1 49 Nov 27 10:24 WiredTiger
-rw-r--r-- 1 494 Nov 27 10:24 WiredTiger.basecfg
-rw-r--r-- 1 21 Nov 27 10:24 WiredTiger.lock
-rw-r--r-- 1 789 Nov 27 10:37 WiredTiger.turtle
-rw-r--r-- 1 44k Nov 27 10:35 WiredTiger.wt
-rw-r--r-- 1 32k Nov 27 10:35 _mdb_catalog.wt
-rw-r--r-- 1 16k Nov 27 10:25 collection-0--5735593512862458467.wt
-rw-r--r-- 1 48M Nov 27 10:35 collection-2--5735593512862458467.wt
-rw-r--r-- 1 16k Nov 27 10:25 index-1--5735593512862458467.wt
-rw-r--r-- 1 1.5M Nov 27 10:35 index-3--5735593512862458467.wt
drwxr-xr-x 1 0 Nov 27 10:24 journal
-rw-r--r-- 1 36k Nov 27 10:36 sizeStorer.wt

Die Entscheidung für Wired Tiger ist der Beobachtung geschuldet, dass sich auf einem einzelnen Knoten CPU-Leistung (Komprimierung benötigt natürlich zusätzliche Rechenpower) wesentlich besser skalieren lässt als IOPS, also der Durchsatz von Disk-Operationen. Man nimmt also den vergleichsweise geringen CPU-Overhead für die Komprimierung in Kauf, um einen höheren Durchsatz bei Schreib- und Leseoperationen zu erreichen und nicht zuletzt geringeren Plattenplatz zu benötigen. MongoDB Inc. wirbt plakativ mit einer Einsparnis von bis zu 80%. Solche Zahlen sind natürlich immer mit Vorsicht zu genießen, da sie stark von der Struktur der konkreten Datensätze abhängen.

Darüber hinaus war es möglich, den Lock-Level mit der neuen Storage-Engine wesentlich feingranularer zu implementieren. Bei konkurrierenden Zugriff ist das Lock jetzt von der Ebene einer logischen Datenbank auf ein einzelnes Dokument reduziert worden. Dies soll laut Aussagen des Herstellers bis zu 10% mehr Durchsatz bei Schreiboperationen bringen. Bei der bisherigen Storage-Engine MMap wird der Lock-Level immerhin bis auf Ebene einer Collection gedrückt.

Betrieb

Um den administrativen Overhead zu reduzieren, hat MongoDB Inc. ein neues Tool namens Ops Manager angekündigt. Dies soll die Verwaltung (d.h. Deployment, Sharding, Backup) Ihrer MongoDB-Instanzen wesentlich vereinfachen und sich durch ein einfaches API bequem in bestehende Automatisierungslösungen einbinden lassen. Bis auf ein für den 5. März 2015 angekündigtes Webinar sind dies allerdings die einzigen Informationen. Vermutlich handelt es sich beim Ops Manager um Teile des SaaS-Angebots, das MongoDB Inc. bereits jetzt unter dem Namen MMS (MongoDB Management Service) betreibt, die nun mit einem anderen Lizenzmodell angeboten werden.

Sicherheitslücke?

Anfang Februar 2015 hat eine Meldung einigen Staub aufgewirbelt. Ca. 40.000 MongoDB-Server wiesen vermeintlich Sicherlücken auf. Bei näherem Hinsehen handelte es sich allerdings nicht um einen Software-Fehler in der MongoDB-Datenbank. Die jeweiligen Betreiber hatten eine Fehlkonfiguration vorgenommen und ihre Server zusätzlich auch offen ins Internet gestellt, so dass ein Dienst zum Portscannen diese auffinden konnte. Ein offenes Scheunentor bleibt eben auch dann offen, wenn ein MongoDB-Server in der Scheune steht. MongoDB Inc. hat zeitnah mit einem Webinar zum Thema Sicherheit auf diesen Vorfall reagiert. Ansonsten bleibt an dieser Stelle zu sagen: RTFM!

Fazit

Nach Version 2.6 ist die aktuelle Version 3.0 schon das zweite Release in Folge, das sich im Wesentlichen auf Verbesserungen im Bereich von nicht-funktionalen Anforderungen wie Performance und Betriebsaspekten konzentriert. Das Entwickler-API scheint also im Großen und Ganzen ausgereift zu sein. Jetzt will MongoDB Inc. den Weg beschreiten hin zur zentralen Allzweck-Datenbank innerhalb des Unternehmens. Zumindest das Ranking auf DB Engines scheint diesen Trend zu bestätigen; hier liegt MongoDB im Februar 2015 mittlerweile auf Platz 4 noch vor Postgres. Ob der Ansatz, sich ähnlich wie etablierte RDBMS hin zu einer Allzweck-Datenbank zu entwickeln, sich noch mit dem Grundgedanken der NoSQL-Bewegung („use the right tool for the job“) vereinbaren lässt, sein an dieser Stelle mal dahingestellt.

Mit einem Locking auf Dokumenten-Ebene rückt jedenfalls die Entwicklung eines ACID-konformen Transaktionsmanagers in greifbare Nähe. Es wäre zumindest möglich, auf einer Single-Server-Umgebung Transaktionen, die von Teilen der Community schon lange gefordert werden, zu implementieren, wie bereits jetzt die MongoDB-Erweiterung TokuMX zeigt.

Darüber hinaus kann die Möglichkeit, über das Storage-API neue DB-Engines zu entwickeln, die Open Source-basierte Entwicklung beflügeln. Denkbar wären hier z.B. HDFS-basierte Engines oder solche, die Verschlüsselung der Datenbank-Dateien anbieten; ein wichtiger Aspekt beim Betrieb in der Cloud.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -