Mit Version 2.8 kommen wesentliche Neuerungen auf die Benutzer der NoSQL-Datenbank MongoDB zu. Eine davon ist die Einführung einer weiteren Storage Engine. Was es damit auf sich hat, werde ich in diesem Artikel erläutern.
Bis zur Version 2.6 hat MongoDB die persistenten Datenstrukturen (Dokumente, Indexe und Journal) mittels des betriebssystemnahen Dienstes mmap (Memory Mapped Files) auf Disk gespeichert. Dabei wird virtualisierter Speicher Byte für Byte auf Dateien abgebildet. Die MongoDB-spezifische Nutzung vom mmap wird sehr anschaulich in Kristina Chodorows Blog erklärt.
Nun wurde mit Version 2.8 zunächst erstmal durch massive Refactorings die Möglichkeit geschaffen, die Storage Engine auszutauschen. Vorher war die Architektur eher … sagen wir monolitisch, nun gibt es ein separates API für die Persistierung von Collections und Indexen. Neben der bisherigen Storage Engine, die den Namen mmapv1 bekommt und weiterhin der Default ist, wird eine neue Engine namens Wired Tiger ausgeliefert.
Ein wesentliches Features von Wired Tiger ist Komprimierung. Dokumente und Indexe werden damit nicht mehr Byte für Byte auf Disk persistiert, die Daten können komprimiert auf Platte gespeichert werden. 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.
MMap vs. Wired Tiger
Auf die Details bei den verschiedenen Kompressionsarten will ich an dieser Stelle gar nicht eingehen, das können Sie z.B. hier nachlesen.
Ich habe testweise ein paar Tweets (knapp 60K Stk., Nutzdaten als BSON-Dump ca. 82 MB) in die Collection tweets in die Datenbank twitter eingefügt. Mit der bisher verwendeten MMap Storage Engine sieht das Data-Verzeichnis dann 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
Pro Datenbank verwaltet MongoDB eine Reihe von Dateien mit den Endungen *.0, *.1 usw, die ihre Größe jeweils verdoppeln bis zum Maximum von 2 GB. Die Twitter-Datenbank belegt hier 192 MB ohne die Namespaces.
Wenn wir nun den MongoDB-Server mit der neuen Wired Tiger Storage Engine starten, müssen wir diese über eine neue Kommandozeilenoption angeben:
$ mongod --dbpath /data/db28 --storageEngine wiredtiger
Das Data-Verzeichnis sieht nach dem Import der Tweets dann so aus:
-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
Wie man sieht, arbeitet Wired Tiger wesentlich feingranular als MMap, insb. werden pro Collection und pro Index jeweils eigene Dateien angelegt, von deren Dateinamen man allerdings nicht auf die zugehörige Collection bzw. den zugehörigen Index schließen kann. (Die zweite Collection und zweite Index gehören im Übrigen zu der Collection local.startup_log).
Interessant ist hier die Größe der Datei collection-2-*.wt, die die Daten der Collection twitter.tweets enthält. Sie ist mit 48 MB kleiner als der importierte BSON-Dump und auch deutlich kleiner als die 192 MB in der MMap-Variante. Wie hoch der Kompressionsgrad im wirklichen Leben ist, hängt natürlich stark von den Daten ab. Dokumente, in denen viele Wiederholungen auftreten, lassen sich in der Regel gut komprimieren. Dies sollte z.B. immer dann der Fall sein, wenn sich Feldnamen wiederholen, was in der Regel oft auftritt.
Goodbye system.indexes!
Bei meinen ersten Experimenten ist mir aufgefallen, dass einige System-Collections beim Einsatz von Wired Tiger einfach nicht mehr da sind. Die Mongo-Shell liefert folgende Auskunft:
> use twitter
switched to db twitter
> show collections
tweets
Die bislang vorhandene System-Collection system.indexes gibt es nicht mehr. In ihr wurden mit der MMap Storage Engine alle Indexe aller Collections einer Datenbank verwaltet. Grundsätzlich nicht weiter schlimm, man kann ja weiterhin über alle Collections und damit auch über deren Indexe iterieren:
> for (i in db.getCollectionNames() ) {
db[db.getCollectionNames()[i]].getIndexes()
}
[
{
"v" : 1,
"key" : {
"_id" : 1
},
"name" : "_id_",
"ns" : "twitter.tweets"
}
]
Ggf. müssen aber Skripte und Tools entsprechend angepasst werden.
Auch die Collection system.namespaces gibt es nicht mehr. Natürlich führt aber auch die neue Storage Engine Buch über die Struktur der Datenbanken; diese Informationen liegen in den Dateien WiredTiger.wt und _mdb_catalog.wt.
In Zusammenhang mit der neuen Storage Engine wird auch der Granularität des bisherigen Locks bei Datenbank-Operation feiner. Wurde bislang die gesamte Datenbank gesperrt, konnte der Lock-Level nun auf die Ebene eines einzelnen Dokuments heruntergedrückt werden, was konkurrierende Zugriffe deutlich beschleunigen sollte. Doch darüber mehr ein anderes Mal …
Dieser Blog Post basiert auf dem RC-0 von Version 2.8. Bis zur finalen Version können sich durchaus noch eine Änderungen ergeben.
War dieser Beitrag hilfreich?
Weitere Beiträge
von Tobias Trelle
17.12.2018 Dein Job bei codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
Weitere Artikel in diesem Themenbereich
Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog-Autor*in
Tobias Trelle
Software Architect
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.