Dokument orientierte Datenbanksysteme - MySQL auf dem Abstieg?

Nachdem im HTML die Tabellen von den DIVs verdrängt wurden, geht es nun den Datenbank Tabellen an den Kragen. Es zeigt sich momentan ein kleiner wachsender Trend, weg von den relationalen Datenbanken, hin zu den Dokument orientierten Datenbanken. Um was es dabei genau geht, möchte ich hier ein bisschen versuchen zu erörtern.

Vor der Lösung steht das Problem

Wer schon öfters einmal größere Applikationen mit MySQL realisiert hat, weiß wie wichtig es ist, vor dem Start zu wissen, wie am Ende die Datenbankstruktur auszusehen hat. Jede spätere Änderung wirft Probleme auf oder lässt den Wunsch aufkommen noch einmal von Vorn zu starten und das ganze optimaler zu gestalten.

Jeder der mit MySQL zu tun hat kennt die umfangreiche SQL Abfragesprache, die einen bei komplexen Joins oder Selects in den Wahnsinn treiben kann.

Jeder der mit MySQL schon einmal viele Datenberge zu bewegen hatte, wird sich vor dem Tag grausen, wenn er selbige auf mehrere Rechner splitten muß.

Seien wir ehrlich, oft müssen wir aus einer Gießkanne ein Elefanten programmieren und Daten in das starre relationale Datenbanksystem pressen. Eine Tabelle für die User, eine Tabelle für die User Gruppen und eine für Profil Informationen. Alles per Insert in die entsprechenden Tabellen aufgeteilt. Und hinterher alles wieder schön mit Joins zusammen knoten. Nur warum? Warum nicht gleich alles so speichern wie es zusammengehört?

Klar, manche User gehören ein und derselben Gruppe an und Gruppen muß man extra erfassen können um nicht alle Datensätze bei Änderungen anfassen zu müssen. Aber trotzdem hat man das Gefühl, das MySQL oder relationale Datenbanksysteme für heutige Web Applikationen nicht wirklich geschaffen sind.

Lösungsansatz

Neben relationalen, hierarchischen und objektorientierten Datenbanksystemen gibt es eben noch die Dokument orientierten Datenbanksysteme. Ableger sind unter anderem Amazon SimpleDB, Apache CouchDB, FeatherDB oder MongoDB. Im Kern machen Sie aber alle das gleiche.

Hier gibt es nun keine Datensätze mehr, sondern Dokumente. Jedes Dokument hat eine einmalige ID die dieses benennt. Diese wird vom Datenbanksystem generiert und ermöglicht es Dokumente zu adressieren und auf sie zu zugreifen.

In diesem Dokument kann man nun Daten in der Form "Schlüssel : Wert" abspeichern und auch genau so wieder abrufen. Das lustige daran ist, das jedes Dokument nun unterschiedliche Schlüssel/Werte Paare enthalten kann. Wer weiß wie ein JSON Dokument aussieht, kann sich so ungefähr auch dieses Dokument vorstellen.

Man kann die Daten also jederzeit erweitern oder verkleinern, da es keine Tabelle mehr gibt, die einen über die Spalten Schlüssel vorgibt.

Beginnt man mit einem Projekt, ist das Aussehen der Datenbank also völlig egal. Man speichert erst einmal ab. Die Datenbank wächst dann mit der Applikation mit, ohne das man Kompromisse eingehen müsste.

Zugriffsbonus mit CouchDB

Während MySQL noch PHP oder eine andere serverseitige Sprache voraussetzte, benutzt CouchDB z.B. eine RESTful JSON API. Das heisst, wenn man mit APIs von Flickr, Twitter oder Facebook umgehen kann, dann gestaltet sich das hier bei dieser Datenbank ähnlich. Man kann Datenbank abfragen direkt von Javascript aus starten und bekommt direkt JSON Dokumente zurück, die sofort weiter verarbeitet werden können.

Ein wichtiger Performance Sprung. Heute üblich, müssen Daten per JS erfasst, per JSON an PHP übermittelt, in PHP in Arrays oder Objekte umgewandelt und von dort in SQL auf dem MySQL Server gespeichert werden. Und das oft mehrmals hintereinander in beiden Richtungen, man denke da an Chat Applikationen. Eine ziemlich lange Kette also, die viele Gefahren und Fehler bürgen kann. Direkter und besser gehts hier eben im Beispiel mit CouchDB.

Weitere Linktipps und Dokumente

• Forum Diskussion über CouchDB
• CouchDB Projekt Webseite
• MongoDB Projekt Webseite
• PHPillow CouchDB Wrapper für PHP
• CloudKit Cloud Datenbank
• CouchDB A use case Beispiele