Die Suche nach alternativen Speichersystemen ist nichts Neues: Mit der Verbreitung der Objektorientierung wurde bereits Ende der 80er Jahre nach neuen Speichermöglichkeiten gesucht. Daraus entstanden objektorientierte Datenbanksysteme (ODBMS) als Alternative zu traditionellen relationalen Datenbanken (RDBMS). Die meisten Anwendungen nutzen heutzutage RDBMS, da diese Systeme komfortable Vorteile wie Constraints, Transaktionen, Locking sowie Abfragemöglichkeiten wie SQL bieten.
Web-2.0-Zeitalter
Im Zeitalter von Web 2.0 sind schreibende Zugriffe mindestens genauso wichtig wie lesende. Anwendungen wie StudiVZ, Twitter oder Facebook leben davon, dass die Nutzer massenhaft Daten einstellen (z. B. ihren Facebook-Status). Allerdings scheinen RDBMS-Systeme Probleme mit der Verarbeitung und Skalierung großer Datenmengen zu haben.
Die alternativen Speichersysteme der NoSQL-Bewegung verzichten bewusst auf einige Vorteile moderner RDBMS, um eine bessere Performance zu erreichen. Am Beispiel von Twitter wird deutlich, dass die "Timeline" zwar (fast) immer verfügbar ist, diese allerdings nicht unmittelbar konsistent ist. Die endgültige Konsistenz der Daten wird hingegen gewährleistet. Ein weiteres Beispiel sind Content-Management-Systeme (CMS), die zwar Persistenz für die Dokumentenverwaltung benötigen, dafür aber nicht zwangsläufig auf komplexe Abfragemöglichkeiten wie SQL zurückgreifen müssen. Da die Struktur häufig bekannt ist, kann hier auf flexible Abfragemöglichkeiten zugunsten hoher Performance verzichtet werden.
Not only SQL
Wie bereits angedeutet, entstehen unterschiedlichste Systeme innerhalb der NoSQL-Bewegung. Stellt sich letztendlich die Frage: Was bedeutet NoSQL? Oft wird vermutet, dass sich hinter dem Ausdruck ein "No to SQL at all" verbirgt. Vielmehr ist NoSQL als "Not only SQL" zu verstehen. Unterschiedliche Probleme erfordern unterschiedliche Lösungen. Daher ist es konsequent, dass eine breite Menge von unterschiedlichen "Not only SQL"-Systemen existiert. Das wiederrum unterstreicht den Innovationsgeist der Community. Ebenfalls ist festzustellen, dass traditionelle Datenbanksysteme (RDBMS) nicht nur heute, sondern auch in Zukunft eine hohe Bedeutung haben werden.
Choice is good
Auf dem Markt existieren diverse NoSQL-Speichersysteme. Der Wikipedia-Eintrag zur NoSQL-Bewegung listet bereits mehr als 20 dieser Systeme auf. Ihr (theoretischer) Hintergrund ist ebenfalls unterschiedlich. Einige Systeme sind in Anlehnung an Googles Bigtable implementiert, z. B. Apache HBase oder Hypertable. Andere Systeme wie Riak realisieren das Dynamo-Paper von Amazon.com. Beide Ansätze werden durch hybride Systeme, die "das Beste" aus beiden Welten vereinen, repräsentiert. Daneben existieren Systeme, die spezifischere Einflüsse haben, z. B. Apache Jackrabbit, das aus dem CMS-Bereich kommt. Ein weiteres Produkt ist Oracles Berkeley DB.
Ein Hase als Dokumentenwächter
Das Apache-Jackrabbit-Projekt implementiert die JSRs 170 und 283. Bei diesen Standards handelt es sich um das Java Content Repository API (JCR) in den Versionen 1.0 und 2.0. Da die Dokumente nicht via SQL aus dem Repository geladen werden, sondern mittels JCR, versteht sich das Projekt als vollwertiges Mitglied der NoSQL-Bewegung. Die Installation von Jackrabbit ist einfach und wird ausführlich auf der Website des Projekts beschrieben. Das Arbeiten mit dem JCR erinnert stark an ein hierarchisches System:
...Repository rep = ...Session session = rep.login(...);Node root = session.getRootNode();root.addNode(“foo”).addNode(“bar”);...
Der obige Code legt einen bar-Zweig unterhalb von foo ab. Innerhalb eines Unix-Verzeichnisbaums wäre dies das Äquivalent zu /foo/bar. Einem Node können Eigenschaften (als Key/Value Pairs) hinzugefügt werden. Die Abfrage des oben genannten Nodes sieht wie folgt aus: Node fooBar = session.getNode(„foo/bar“);. Das Sessionobjekt navigiert zur gewünschten Stelle der Dokumentenhierarchie und lädt den entsprechenden Node.
