NoSQL Datenbanken - ein Einstieg

Seit ich das erste Mal auf der Internationalen PHP Konferenz 2009 mit dem Schlagwort NoSQL in Berührung kam, hat mich das Thema immer wieder begleitet. Um jedoch beurteilen zu können, ob eine der unzähligen NoSQL Datenbanken für das nächste Projekt Sinn macht, sollte man sich genauer mit der Thematik beschäftigen.

NoSQL steht nicht wie viele denken für „No SQL“, sondern für „Not only SQL“ und ist mehr eine Bewegung als eine genaue Definition.

Was alle NoSQL Datenbanken gemeinsam haben, ist der nicht-relationale Ansatz. Sie reihen sich also nicht in die lange Geschichte der relationalen Datenbank-Managementsysteme (RDBMS) ein:

Daten werden nicht mehr normalisiert und in der Regel wird auf ein starres Datenbankschema verzichtet. 

Weiters ist die Architektur vieler NoSQL Datenbanken auf Skalierbarkeit und hohe Performance ausgelegt, was zur Folge hat, dass teilweise die Konsistenz der Daten nicht garantiert werden kann, Transaktionen werden nur eingeschränkt oder überhaupt nicht unterstützt.  

NoSQL Datenbanken lassen sich grob in 3 Kategorien einteilen: dokumentenorientierte Datenbanken, Key-Value-Datenbanken und Graph-Datenbanken. Welcher NoSQL Datenbanktyp bzw. welche NoSQL Datenbank für welches Problem herangezogen werden kann, lässt sich mittels der Entscheidungspyramide von Nathan Hurst vielleicht einfacher einschätzen.

In meinem Alltag bei Massive Art kommen zum Grossteil Problemstellungen auf mich zu, die sich mittels einer dokumentenorientierten Datenbank abdecken lassen würden. Oft sogar eleganter als mit einer herkömmlichen relationalen Datenbank. Aus diesem Grund habe ich diesen Typ der NoSQL Datenbanken etwas genauer unter die Lupe genommen.

Dokumentenorientierte Datenbanken

Dokumentenorientierte Datenbanken speichern, wie der Name schon erahnen lässt, Daten in einem gekapselt, oft unstrukturiertem Dokument, innerhalb eines bestimmten Bereiches ab. Suchen bzw. Abfragen sind auf Basis von Dokumentinhalten möglich.

Ein solches Dokument könnte folgendermassen aussehen:

var blog = {
  "title":"NoSQL Datenbanken - ein Einstieg",
  "author":"Thomas Schedler",
  "date":"2011-05-16 09:56:24",
  "content":"Seit ich das erste Mal auf der ...",
  "tags":["NoSQL","Dokumentenorientierte Datenbanken","MongoDB"]
};

Wann macht es aber Sinn, eine solche dokumentenorientierte Datenbank zu verwenden und nicht wie gewohnt die anfallenden Daten zu normalisieren und in einer relationalen Datenbank abzulegen?

Meiner Meinung nach ist die Antwort relativ einfach: Wenn es sich um Dokumente handelt.

Ein Blog besteht aus einzelnen Beiträgen mit Kommentaren, die für sich als einzelne Dokumente gesehen werden können. 

Bei einer Webseite ist jede Seite für sich ein eigenständiges Dokument. Hier wir dann die Strukturierung in einem Baum vielleicht eine kleine Herausforderung. Aber einen Baum in einem relationalen System abzulegen, ist auch nicht gerade einfacher.

Hingegen handelt es sich bei einem Buchungssystem für mich nicht mehr um Dokumente und ist klar ein Fall für eine relationale Datenbank.

Dies waren jetzt natürlich sehr einfache und klare zuordenbare Beispiele. Man muss vor jeder Problemstellung die anfallenden Daten genau analysieren um dann wirklich entscheiden zu können, ob eine NoSQL Datenbank den Ansprüchen besser gerecht wird als eine relationale Datenbank.

Bei MASSIVE ART haben wir uns nach Abwägen der Vor- und Nachteile dazu entschieden, bei einem sehr spannenden Projekt auf MongoDB, einen Vertreter der dokumentenorientierten Datenbanken, in Kombination mit MySql zu setzen. Auf die Frage, wieso wir uns für MongoDB entschieden haben, werde ich in einem meiner nächsten Blogs genauer eingehen.

Mein Fazit nach den Erfahrungen, die ich bisher gemacht habe, lautet also: NoSQL ist kein Allheilmittel, sondern sollte nur gezielt dort eingesetzt werden, wo es auch Sinn macht. Nur um „cool“ zu sein sollte man nicht auf eine neue Technologie setzten!