| NoSQL - die neue (alte) Datenbank-Generation? | |
| NoSQL-Kriterien | |
| Datenbankmodelle für NoSQL | |
| Core NoSQL - Soft NoSQL | |
| In-Memory-Computing | |
| Schwächen und Stärken | |
| Fazit |
Rasant wachsende Datenmengen und steigende Anforderungen im Umfeld von Business Intelligence lassen den Ruf nach neuen Datenbanktechniken lauter werden. Die NoSQL-Bewegung will davon profitieren und hofft, den etablierten Datenbankanbietern ihren Markt streitig machen zu können. Dabei sind viele Ideen und Techniken rund um NoSQL gar nicht so neu.
Im Grunde ist "NoSQL" eigentlich falsch. Der Begriff steht heute eher für "Not Only SQL" statt für ein striktes "No SQL". Unter NoSQL fasst man verschiedene Datenbankmodelle zusammen - auch solche, die keineswegs neu sind. Mit der NoSQL-Bewegung werden zudem nicht zum ersten Mal relationale Datenbanken infrage gestellt. Beispielsweise haben dies schon vor Jahren Anbieter von objektorientierten Datenbanken versucht, konnten sich allerdings bis dato nicht ebenbürtig neben den relationalen Modellen etablieren.
Bereits vor den Relationalen Datenbank-Management-Systemen (RDBMS) gab es Datenbanken mit anderen Speichermodellen auf dem Markt. So waren beispielsweise hierarchisch strukturierte Systeme wie "Total" oder "IMS" und Netzsysteme nach "Codasyl"-Norm wie "IDMS" oder "DMS-1100" im Einsatz. Außerdem arbeiteten in den Unternehmen Listensysteme wie "Adabas". Dokumente wurden in Information-Retrieval-Systemen wie "Stairs" von IBM oder "Golem" von Siemens gespeichert. Das Relationenmodell bildete jedoch in der Folge das erste mathematisch fundierte Datenbankmodell. Die darauf basierenden Produkte haben sich seit Anfang der 1980er Jahre weitgehend durchgesetzt.
Was zeichnet aber nun NoSQL-Datenbankmodelle heute aus, wenn die nicht-relationalen Konzepte im Grunde nicht unbedingt neu sind? Schübe für alternative Datenbankentwicklungen gab es ab dem Jahr 2000 mit dem Aufkommen des Web 2.0 und aktuell im Zuge des wachsenden Interesses an Cloud Computing. Die exponenziell wachsenden Datenmengen verlangen nach schnelleren Speichertechniken und leistungsfähigerer Unterstützung verteilter Architekturen.
Die Forderungen für Web-2.0- und Cloud-Datenbanken lauten:
Vermeidung unnötiger Komplexität,
hoher Durchsatz,
horizontale Skalierbarkeit,
lauffähig auf gebräuchlicher Hardware,
Vermeidung von objekt-relationalem Mapping,
einfaches Aufsetzen von Datenbank-Clus-tern zu geringen Kosten und
Berücksichtigung des aktuellen Stands der Technik (Hardware).
Diese Anforderungen sahen einige Unternehmen weder bei Open Source RDBMS noch bei kommerziellen RDBMS ausreichend erfüllt. So entwickelte zum Beispiel Google als Vorreiter der NoSQL-Bewegung proprietäre Lösungen auf Basis seines verteilten File-Systems GFS (Google File System), dem darauf aufbauenden Datenbanksystem "BigTable" und dem Map/Reduce-Framework. MapReduce ist ein von Google eingeführtes Framework für nebenläufige Berechnungen über sehr große Datenmengen auf Computer-Clustern. Nebenläufigkeit bedeutet, dass mehrere Ereignisse in keiner kausalen Beziehung zueinander stehen, sich also nicht beeinflussen. Nutzer spezifizieren eine Map-Funktion, die ein Schlüssel/Wert-Paar (key/value) verarbeitet und Zwischenergebnisse in Form von Schlüssel/Wert-Paaren erzeugt. Eine Reduce-Funktion erstellt aus den Zwischenergebnissen die Ausgabedaten.
Ein anderes Beispiel ist Amazon mit "Dynamo" und "SimpleDB": Dynamo ist ein sogenanntes Key/Value-Datenbanksystem und wird von Amazon für seine Kerndienste eingesetzt. SimpleDB stellt einen Web-Service dar, der die Datenbank-Kernfunktionen für Indizierung und Abfragen bietet.
