MongoDB (eBook)

1 Einleitung

1.1 Big Data

Sie wollen ein Buch über MongoDB lesen und werden als Erstes mit dem Begriff Big Data konfrontiert. Was hat MongoDB mit Big Data zu tun, werden Sie sich fragen. Was ist Big Data überhaupt genau? Um die Motivation zu verstehen, die zur Entstehung von MongoDB (und anderen nichtrelationalen Datenbanken) führte, will ich Ihnen zunächst eine Begriffsdefinition von Big Data geben.

Die grundlegenden technischen Herausforderungen im Big-Data-Umfeld wurden bereits 2001 von Doug Laney (heute Analyst bei Gartner) formuliert1 und sind heute unter der Abkürzung 3V bekannt. Dabei handelt es sich um die Aspekte:

• Volume
• Velocity
• Variety

Bei Volume geht es um die schiere Menge an Daten, die pro Zeiteinheit gespeichert werden muss.

Velocity adressiert die Geschwindigkeit, mit der die Daten persistiert, aber auch verarbeitet werden. Die Verarbeitung kann dabei im Batch oder aber auch in (Fast-)Echtzeit gewünscht sein.

Der Aspekt Variety bezieht sich auf die unterschiedlichen Grade von Strukturiertheit der Daten, das reicht von völlig unstrukturiert über semistrukturiert bis hin zu stark strukturiert.

Daneben machen zwei weitere Dinge den Begriff Big Data aus: Kostenersparnis durch elastische Skalierung und die Gewinnung neuer Informationen aus den Daten.

Ich möchte Ihnen folgende Fragen in Bezug auf Ihr relationales Datenbanksystem stellen. Haben Sie Probleme mit der Anzahl an schreibenden Operationen pro Sekunde? Wie schnell bzw. wie oft können und wollen Sie Ihre Reports erstellen? Wie gut passt Ihr logisches Datenmodell wirklich zum relationalen Modell?

Wenn Sie mit keinem dieser Aspekte oder ähnlich gelagerten Fragestellungen Probleme haben, dann haben Sie wahrscheinlich auch kein Big-Data-Problem. Stehen Sie aber vor einer oder allen diesen Herausforderungen, dann Sie sind sicherlich schon über den Begriff NoSQL gestolpert.

1.2 NoSQL

Der Begriff NoSQL2 ist keineswegs ein Imperativ, der zum vollständigen Boykott relationaler Datenbanksysteme aufruft. Er leitet sich ab von not only SQL, wobei SQL als Synonym für relationale Datenbankensysteme verwendet wird.

Die Grundidee ist die, dass man sich beim Umsetzen seiner konkreten Anforderungen (ob nun Big Data oder nicht) nicht im Vorhinein auf relationale Datenbanksysteme (RDBMS) beschränkt, nur weil man dies bei der Datenhaltung in den letzten Dekaden immer so getan hat. Riskieren Sie ruhig mal den Blick über den Tellerrand und setzen Sie das Datenbanksystem ein, das Ihr Problem optimal löst. Können Sie Ihr Problem am besten mit einer relationalen Datenbank lösen, dann tun Sie das auch und laufen nicht dem Hype hinterher.

Denn zum Einsatz von NoSQL-Technologien gehört Mut: Datenbankadministratoren haben wenig bis keine Erfahrung mit diesen neuartigen Technologien, Entwickler kennen die meist nichtstandardisierten APIs (noch) nicht. Das möchte ich mit diesem Buch in Bezug auf MongoDB ändern.

Entstanden sind die NoSQL-Datenbanken in der Web-2.0-Welt. Soziale Netzwerke wie Facebook, Twitter und Co. haben mit vielen Millionen, über den ganzen Globus verteilten Benutzern ganz andere Anforderungen an die Datenhaltung als das Bestandsführungssystem eines Versicherungsunternehmens. Es müssen sehr viele Daten sehr schnell gespeichert und abgerufen können. Dabei stoßen relationale Datenbanksysteme durchaus an ihre Grenzen, sowohl technologisch als auch vom Lizenzmodell her. Um eine fundierte Entscheidung bei der Auswahl der passenden NoSQL-Datenbank treffen zu können, ist natürlich – wie immer – Know-how gefragt, zumal sich in diesem Umfeld sehr viele Anbieter und auch Konzepte tummeln. Die wichtigsten Kategorien von NoSQL-Datenbanken3 sind:

• Key-Value-Datenbanken verwalten Tupel bestehend aus einem Schlüssel und einem Wert. Abfragen sind nur über den einen Schlüssel möglich. Der Wert des Datensatzes ist in der Regel ein Byte-Array, ist also im Sinne des Variety-Aspekts völlig unstrukturiert.
• Spaltenorientierte Datenbanken, im Englischen Wide Column Stores, verwenden Tabellen, bei denen ein Datensatz allerdings eine dynamische Anzahl an Spalten haben kann. Sie können damit als eine Verallgemeinerung von Key-Value-Datenbanken angesehen werden. Indizes sind frei definierbar und ermöglichen die Abfrage über beliebige Spalten.
• Graphen-Datenbanken spezialisieren sich auf die Verwaltung von Knoten und Kanten zwischen diesen Knoten. Abfragen ermöglichen u. a. das Traversieren des Graphen.
• Dokumentenorientierte Datenbanken werde ich im Folgenden noch näher erklären.

Abbildung 1–1 zeigt einige der populärsten Vertreter:

Abb. 1–1 NoSQL-Datenbanken im Überblick

Relationale Datenbanksysteme sind Allzweckwaffen, die sich in der Regel auf eine große Menge von Problemen anwenden lassen. Im Gegensatz dazu stellen NoSQL-Datenbanken tendenziell eher Nischenlösungen dar, die bestimmte Probleme allerdings sehr viel besser lösen können.

1.3 Dokumentenorientierte Datenbanken

MongoDB gehört zur Kategorie der sogenannten dokumentenorientierten Datenbanken. Damit werden wir uns im weiteren Verlauf dieses Buches sehr detailliert auseinandersetzen. Ein Dokument ist ein einzelner Datensatz, der im Prinzip aus einer geordneten Liste von Key-Value-Paaren besteht und als Werte auch Arrays und eingebettete Dokumente zulässt. Ein Dokument kann man gut im JSON-Format darstellen, z. B. so:

Zur Speicherung verwendet MongoDB intern allerdings nicht das JSON-Format, sondern eine Abwandlung davon. Dazu aber später mehr. Mit diesem Datenformat adressiert MongoDB den Big-Data-Aspekt Variety: Ein Dokument eignet sich hervorragend zum Umgang mit semistrukturierten Daten, z. B. komplexen Vererbungshierarchien in OO-Sprachen. Aber auch für Volume und Velocity bietet MongoDB Lösungen an, auf die ich in den folgenden Kapiteln noch eingehen werde.

a. http://www.kchodorow.com/blog/2010/08/23/history-of-mongodb/

1.4 Verteilte Systeme und das CAP-Theorem

Den Big-Data-Aspekten Volume und Velocity ist in der Regel nur mit dem Einsatz von verteilten Systemen4 zu begegnen, in denen die Last und die Daten auf viele einzelne Rechnerknoten verteilt werden.

Aus dem CAP-Theorem (s. Kasten) folgt allerdings, dass man bei der Implementierung eines verteilten (Datenbank-)Systems nicht alle der Anforderungen an Konsistenz, Verfügbarkeit und Toleranz gegenüber Ausfällen gleichzeitig in vollem Maße erreichen kann.

Abb. 1–2 Veranschaulichung des CAP-Theorems

a. http://www.cs.berkeley.edu/~brewer/cs262b-2004/PODC-keynote.pdf

Die Auswirkungen des CAP-Theorems lassen sich gut an einem System veranschaulichen, das aus zwei Knoten besteht (s. Abb. 1–2). Das Netzwerk zwischen diesen Knoten soll gestört sein, sodass eine Partition des Systems in zwei Teile vorliegt, die sich gegenseitig nicht mehr erreichen können.

Erlaubt man nun einem der Knoten, seinen Zustand zu ändern (also im Falle eines Datenbanksystems schreibende Operationen auszuführen), wird das Gesamtsystem inkonsistent, man...