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.

Im Video: Einführung in NoSQL-Datenbanken

Zum Video: NoSQL - die neue (alte) Datenbank-Generation?

NoSQL-Kriterien

Folgende Kriterien sind es, die NoSQL-Datenbanken von relationalen Systemen unterscheiden:

1. Datenbankmodell nicht relational: Dies ist der gemeinsame Nenner aller NoSQLs. Diese Datenbankmodelle bieten in bestimmten Anwendungsfällen eine bessere Performance.

2. Verteilte und horizontale Skalierbarkeit: Für die enormen Datenmengen, die im Web zu bewältigen sind, ist es von Vorteil, wenn das Datenhaltungssystem von Beginn an mit dem Ziel effektiver Skalierung und Verteilung entwickelt wurde.

3. Open Source: Das Kriterium "Open Source" ist kein technisches Kriterium und nicht unumstritten: Googles und Amazons Datenbanksysteme sind zum Beispiel bekannte NoSQL-Datenbanken ohne Open-Source-Lizenz. Dennoch wird gerade das populäre MySQL immer wieder als Maßstab zu Vergleichen herangezogen.

4. (Fast) Schemafrei: Web-2.0-Anwendungen verlangen häufig Flexibilität. Änderungen an den Datendefinitionen bedeuten jedoch in Relationalen Datenbanken eine Überarbeitung des Schemas, was unter Umständen zu längeren Betriebsunterbrechungen führen kann. NoSQL-Systeme arbeiten stattdessen mit einer Versionierung von Daten und Konvertierungen im Rahmen von Hintergrundprozessen.

5. Unterstützung verteilter Architekturen und einfache Replikation: Aus dem Ziel einer besseren Skalierbarkeit und Verteilung resultiert zudem die Forderung nach einer besseren Unterstützung von Replikationen. Einige NoSQL-Datenbanken können mit einem Befehl repliziert werden.

6. Einfache Programmierschnittstelle (API - Application Programming Interface): SQL, das ursprünglich nicht für relationale Datenbanken entwickelt worden war, ist heute als Datenbanksprache trotz oder gerade wegen weniger Befehle sehr komplex geworden. Viele "Joins", Unterabfragen, ineinandergeschachtelte "Selects", rekursive Selects, machen die Abfragen teilweise schwer überschaubar und überfordern manche Programmierer. Daraus ergibt sich die Forderung nach einfacheren Programmierschnittstellen. Manche NoSQL-Datenbanksysteme bieten einfache Schnittstellen, aber dafür weniger mächtige an. Andere setzen für komplexe Abfragen auf Map/Reduce-Techniken. Ob aber mit View-Funktionen in JavaScript oder selbst programmierten Map/Reduce-Funktionen in vorgegebenen Sprachen wirklich eine Vereinfachung aufwendiger Abfragen erzielt wird, ist eher fraglich.

7. Konsistenzmodell nicht ACID (Atomicity, Consistency, Isolation, Durability): Für relationale Datenbanksysteme gilt das strenge Konsistenzmodell ACID, das für kritische Anwendungen mit zum Beispiel Auftrags- oder Finanzdaten unverzichtbar ist. Für andere Anwendungen mit unkritischen Daten beispielsweise in Social-Web-Portalen reicht stattdessen BASE (Basically Available, Soft State, Eventually Consistent) aus. Mit BASE liegt der Schwerpunkt auf der Verfügbarkeit und weniger auf der Konsistenz der Daten. Die Daten sind eben nur vielleicht konsistent oder, optimistisch ausgedrückt, fast immer konsistent.

Nach dem CAP-Theorem (CAP - Consis-tency (Konsistenz), Availability (Verfügbarkeit) und Partition Tolerance (Ausfalltoleranz)) können Daten in verteilten Systemen nicht gleichzeitig konsistent, immer verfügbar und ausfalltolerant sein. Es können nur zwei der drei Kriterien erfüllt werden.

• Konsistenz: Alle Knoten sehen zur selben Zeit dieselben Daten.

• Verfügbarkeit: Knotenausfälle hindern die "Überlebenden" nicht daran weiterzuarbeiten.

• Partitionstoleranz: Das System arbeitet trotz willkürlicher Verluste von Nachrichten weiter.

Nicht alle NoSQL-Datenbanksysteme erfüllen sämtliche sieben Kriterien. Darüber hinaus verbessern die Anbieter von relationalen Systemen ihre Produkte laufend weiter, um Defizite auszugleichen.

Im Video: NoSQL-Datenbanken - MongoDB

Zum Video: NoSQL - die neue (alte) Datenbank-Generation?

Datenbankmodelle für NoSQL

Trotz gleicher Zielkriterien unterscheiden sich die NoSQL-Systeme zum Teil erheblich in ihren theoretischen Grundlagen. Eine Möglichkeit, die große Familie der NoSQL-Datenbanken zu untergliedern, bietet die Unterteilung nach Datenbankmodellen. Dabei gilt es jedoch zu beachten, dass sich die verschiedenen Urheber solcher Unterteilungen nicht immer einig sind, welches Datenbankprodukt in welche Gruppe gehört. So findet man beispielsweise Amazons SimpleDB als spaltenorientierte wie auch als dokumentenbasierte Datenbank eingeordnet. Dazu kommt, dass einzelne Produkte verschiedene Konzepte miteinander kombinieren. OrientDB zum Beispiel verbindet dokumentenbasierte Technik mit Graphen-Datenbanktechnik und Objektorientierung. Von den Datenbankmodellen her lässt sich die Familie der NoSQL-Datenbanken folgendermaßen unterteilen:

1. Key/Value-Datenbanksysteme: Diese sind schon seit den 70er Jahren im Einsatz, zum Beispiel als eingebettete Datenbanken unter Unix wie "dbm", "gdbm" oder "Berkeley DB". Sie bedienen sich eines einfachen Schlüssel- und Wertschemas. Ein Wert ist immer einem bestimmten Schlüssel zugeordnet.
   Er kann aus einer strukturierten oder willkürlichen Zeichenkette bestehen. Der Zugriff auf einen Datensatz erfolgt nur über dessen Schlüssel. Moderne Vertreter der Key/Value-Systeme sind "Dynamo" oder "Redis". Unter den Key/Value-Datenbanksystemen gibt es auch einige In-Memory-Datenbanken (Hauptspeicherdatenbanken), die sich gut als Cache-Speichersysteme einsetzen lassen; Beispiele sind "Memcached" oder "Redis".

2. Spaltenorientierte Datenbanksysteme: Vertreter dieser Kategorie werden auch als Wide Column Stores bezeichnet. Sie speichern im Gegensatz zu den Relationalen Datenbanken Daten mehrerer Einträge in Spalten anstatt in Zeilen. Die Struktur einer Spalte besteht aus dem Namen der Spalte, den Daten und einem Zeitstempel. Leseprozesse funktionieren in so organisierten Systemen schnell, da keine unnötigen Daten wie bei zeilenorientierten Datenbanken gelesen werden müssen. Schreibprozesse sind aber nur dann ebenso schnell, wenn nur eine Spalte betroffen ist. Gut geeignete Einsatzbereiche für solche Datenbanken sind daher Reporting, Business Intelligence (BI) und Data-Mining. Die Idee der Spaltenorientierten Datenablage gibt es schon seit Ende der 80er Jahre. Über längere Zeit hat indes nur Sybase Entwicklungen in diese Richtung betrieben und in dem BI-Produkt "Sybase IQ" umgesetzt. Neuere Vertreter sind "SimpleDB", "Cassandra", "BigTable", "Hypertable" und "Hbase".

3. Dokumentenorientierte Datenbanksysteme: Dieser Typus von NoSQL-Datenbanksystemen speichert Daten nicht relational in Form von Tabellen, sondern in sogenannten Dokumenten ab. Ein Dokument ist dabei als eine mehr oder minder strukturierte Zusammenstellung bestimmter Daten ohne Schemavorgabe zu verstehen. Dokumente sind nicht normiert und besitzen keine Beziehungen (Relationen) zueinander. Jedes Dokument besitzt einen eindeutigen Schlüssel (Identifier - ID). Komplexere Abfragen werden durch selbst zu programmierende Map-Reduce-Funktionen unterstützt. Eines der ältesten Produkte dieser Kategorie ist "Lotus Notes". Neuere Systeme sind "CouchDB" oder "MongoDB".

4. Graphendatenbanken: In einer Graphendatenbank werden die Informationen als Knoten oder Kanten (Beziehungen zwischen den Knoten) und deren Eigenschaften abgebildet. Ihr Vorteil liegt in einem einfachen und effizienten Durchlauf (Traversierung) durch ein solches Netz, was sich mit relationalen Datenbanken nur mühselig abbilden lässt. Traversierung eines Graphen bedeutet, dass der Graph beginnend von einem Startknoten durchlaufen wird. Dies stellt eine der wichtigsten Operationen in diesem Modell dar. So können aufwendige Datenbankabfragen wie mehrere rekursiv verschachtelte Joins vermieden werden. Das Graphenmodell bietet eine bessere Performance als SQL.

Folgende Anwendungen lassen sich auf Graphen zurückführen:

• Fahr- oder Flugplanoptimierung,

• Verkehrsleitsysteme,

• Geoinformationssysteme,

• Hyperlink-Struktur des WWW,

• Bedeutung von Seiten für Suchmaschinen (PageRank) und

• "Wer kennt wen"-Beziehungen in sozialen Netzen.

Bekannter Vertreter dieser Kategorie ist Neo4j. Das System ist im Übrigen transaktionsorientiert mit ACID-Konsistenz, erfüllt also eines der als typisch geltenden Kriterien für NoSQL nicht.

Im Video: NoSQL-Datenbanken - Redis

Zum Video: NoSQL - die neue (alte) Datenbank-Generation?

Core NoSQL - Soft NoSQL

Da NoSQL weniger einen technischen Begriff oder eine Kategorie darstellt, sondern eher eine Bewegung bezeichnet, haben über 120 Anbieter nicht-relationaler Datenbanksysteme ihre Aufnahme in das NoSQL-Archiv (http://nosql-database.org/) beantragt. Daher wird dort mittlerweile unterschieden zwischen NoSQL-Kernsystemen (Core NoSQL Systems) und "weichen" NoSQL-Systemen (Soft NoSQL Systems), die weniger auf die Anforderungen von Web 2.0 ausgerichtet sind.

NoSQL-Kernsysteme werden - wie bereits vorgestellt - unterteilt in:

• Key Value Stores,

• Wide Column Stores,

• Document Stores und

• Graph-Datenbanken.

Soft NoSQL-Systeme sind eingeteilt in

• objektorientierte Datenbanken,

• XML-Datenbanken,

• Grid-Datenbanken und

• andere nicht-relationale Datenbanken.Hier finden sich beispielsweise Systeme wie U2, Lotus Domino, Btrieve, Adabas.

Im Video: NoSQL-Datenbanken - CouchDB

Zum Video: NoSQL - die neue (alte) Datenbank-Generation?

In-Memory-Computing

Das Stichwort für einen weiteren Trend im Datenbankumfeld ist schon unter den Key/Value-Datenbanksystemen gefallen: die Hauptspeicherdatenbanken.

Mit den dramatisch gesunkenen Hardwarekosten und den erweiterten Adressierungsmöglichkeiten der 64-Bit-Technologie hat sich das Caching der Daten im Hauptspeicher der Server zu einem beliebten Mittel der Performance-Steigerung entwickelt. Die im Verhältnis langsamen Zugriffe auf Festplattenlaufwerke und die aufwendigeren Techniken zum Auffinden der Daten auf den Harddisks haben in der Vergangenheit die Verarbeitungsgeschwindigkeit teilweise stark beeinträchtigt.

Neben dem Caching im Hauptspeicher gibt es auch Datenbanksysteme, die als reine In-Memory-Datenbanken betrieben werden können, ohne eine Datenbank auf Festplatten im Hintergrund. Seit langem werden In-Memory-Datenbanken als integrierte Datenhaltungssysteme in Echtzeitsystemen wie zum Beispiel in industriellen Steuerungen oder Netzwerk-Routern eingesetzt. Allerdings sind auch In-Memory-Datenbanken keine Erfindung der NoSQL-Bewegung. Relationale Datenbanken wie SolidDB, Apache Derby, MySQL und andere können in-memory betrieben werden. NoSQL-Lösungen, die in-memory laufen, sind die erwähnten Key/Value-Datenbanken wie Redis, Memcached oder MemcacheDB.

Gern wird In-Memory-Computing für Business-Intelligence-Werkzeuge und -Anwendungen genutzt. Bekannte Produkte sind beispielsweise der "Analytic Server" von SAND Technologies, "Cognos TM1" von IBM oder "SAS In-Memory Analytics".

Einige Hersteller setzen auf In-Memory-Computing, um hohe Leistung zu erzielen, ohne jedoch mit der bewährten relationalen Technik zu brechen. In-Memory-Datenhaltung oder Caching, massiv parallele Verarbeitung, spaltenorientierte Datenspeicherung und Datenkompression ermöglichen Geschwindigkeitsvorteile, ohne dafür die Grundlagen bisheriger Datenbanktechnik über Bord werfen zu müssen. Beispielsweise lässt sich sehr wohl eine spaltenorientierte Datenhaltung mit der Datenbanksprache SQL verbinden.

Ein bekannter Vertreter von In-Memory-Computing mit spaltenbasierter Datenhaltung und SQL ist zum Beispiel "EXASolution" des Anbieters Exasol, eine Datenbank für Business Intelligence, Data Warehouses und Data Mining. Bekannter Exasol-Kunde ist das Business Netzwerk Xing. Ein Open-Source-Produkt, das relationale Technologie mit Memory-Caching verbindet, ist "HSQLDB" (HyperSQL Data Base).

Ein Softwarehersteller, der seine Zukunft im In-Memory-Computing sieht, ist SAP. Die Walldorfer kündigten an, dass ihre proprietäre In-Memory-Technik künftig traditionelle Datenbanken ersetzen soll. Der Hersteller hat mit SAP HANA, einer In-Memory Appliance, bestehend aus einem Paket aus Hard- und Softwarekomponenten, ein Analysewerkzeug auf Basis einer In-Memory-Datenbank vorgestellt. HANA kann laut Herstellerangaben externe Datenquellen in seine In-Memory-Datenbank mit Hilfe des Sybase Replication Server integrieren und so schneller auswerten. Die In-Memory Database ist spalten- und zeilenorientiert ausgelegt und nutzt SQL als Datenbanksprache. Sie besitzt eine Relational Engine für die Datenhaltung und einen Optimizer.

Schwächen und Stärken

Das Problem von In-Memory-Datenbanken bilden Ausfälle der Server. Dabei geht der Inhalt des Hauptspeichers verloren. Die Hersteller müssen also vorsorgen, damit Änderungen nicht verschwinden:

• Hybrid-Datenbanken führen die Datenbestände parallel auch auf Plattenspeichern.

• Logdateien zeichnen alle Änderungen auf geeigneten Medien auf.

• Snapshots duplizieren alle Daten zu bestimmten Zeitpunkten auf geeignete Medien. Hierbei ist aber mit einem Datenverlust seit dem letzten Snapshot zu rechnen.

• Hochverfügbarkeits-Cluster halten synchrone Kopien der Datenbanken durch Replikation oder ähnliche Protokolle vor und ermöglichen im Fehlerfall das Umschalten auf andere Server.

Die Stärken von In-Memory-Datenbanken liegen vor allem in abfrageintensiven Anwendungsbereichen wie zum Beispiel Data Warehouse oder Business Intelligence. Die hohe Arbeitsgeschwindigkeit von In-Memory-Datenbanken erlaubt den Verzicht auf Hilfskonstruktionen wie Aggregat-Tabellen oder materialisierte Views.

Fazit

NoSQL ist der Sammelbegriff für nicht-relationale Datenbanksysteme und zugleich der Name einer Bewegung weg von den Relationalen Datenbanken hin zu neuen beziehungsweise vergessenen Datenbankmodellen. Typische Vertreter der Kern-NoSQL-Datenbanken lösen eine bestimmte Aufgabe, auf die sie optimal hinentwickelt wurden. Im Hinblick auf andere Aspekte des Datenbankeinsatzes gilt es dagegen Restriktionen zu beachten, die man je nach Anwendung in Kauf nehmen muss. Weil der Begriff NoSQL so vielfältig ist, wird er auch immer wieder unterschiedlich interpretiert. Gerade in Verbindung mit "Open Source" kokettiert die NoSQL-Bewegung mit dem Image einer Subkultur, die bewusst Abstand von den etablierten Datenbankprodukten und ihren Herstellern hält. Doch die bedeutendsten NoSQL-Vertreter von Google oder Amazon sind proprietär.

NoSQL wird die IT-Welt weiter beschäftigen. Es gibt durchaus noch Verbesserungsbedarf an der einen oder anderen Stelle. Viele NoSQL-Datenbanken stehen im Vergleich mit den relationalen Systemen, besonders auch mit den spaltenorientierten, nicht so gut da, wie die Bewegung der IT-Welt weismachen will. Besonders bei der Entwicklung neuer Programmierschnittstellen (API) gibt es noch einigen Optimierungsbedarf. (ba)