Das zunehmende Datenvolumen, kurze Auswertungszeiträume und sich verändernde Daten sowie zunehmende Anforderungen von Business Intelligence liefern Anwendungsfälle für unterschiedliche Datenbanktechnologien (DB). Die NoSQL Bewegung bietet für ausgewählte Anwendungsfälle spezialisierte Eigenschaften, die in Relationalen Datenbanken (RDB) bislang vermisst werden. Ideen und Techniken rund um NoSQL sind nicht neu. Die NoSQL Bewegung umschließt unterschiedliche Datenbank-Arten, deren Eignung für den jeweiligen analytischen Anwendungsfall zu prüfen ist.
Themen des Artikels:

• Was sind NoSQL Datenbanken
• Wesentliche NoSQL Datenbank Arten
• Anwendungsfälle für Business Intelligence
• Erweiterungen etablierter Relationaler Datenbankanbieter
• Modellierung in NoSQL Datenbanken
• Integration von NoSQL Datenbanken in bestehende Data Warehouse Infrastrukture
  
  

Was sind NoSQL Datenbanken?

Vor der Einführung Relationaler Datenbanken wurden bereits nicht-relationale Datenbanken eingesetzt zu den älteste bekannten Datenbanktechnologien gehören Hierarchische Datenbanken. Relationale Datenbanken (RDB) wurden in den 70er Jahren eingeführt, um Daten redundanzfrei, konsistent und transaktionssicher zu speichern. RDB zeichnen sich dadurch aus, dass Daten in zweidimensionalen Gebilden (Tabellen mit Zeilen/Spalten) organisiert werden und alle Einträge einer Spalte die gleiche Bedeutung aufweisen. Diese zweidimensionalen Gebilde können über Fremdschlüssel mit einander in Beziehung gebracht werden. Ein Primärer Schlüssel muss in diesen zweidimensionalen Gebilden nicht vorhanden sein. Die meisten RDB speichern Daten zeilenbasiert. Es gibt jedoch auch spaltenbasierte RDB, die in Buisiness Intelligence Anforderungen beim Lesen weniger Spalten mit großen Datenmengen Vorteile gegenüber zeilenbasierten Datenspeichern aufweisen. Eine Übersicht der historischen Entwicklung RDB findet sich unter:

http://hpi.de/fileadmin/user_upload/fachgebiete/naumann/projekte/RDBMSGenealogy/RDBMS_Genealogy_V5.pdf

Die Entkopplung von Benutzer- und Implementierungsschicht in der Architektur der RDB die Einführung standardisierter Schnittstellen durch Trennung der physischen Datenspeicherung von der logischen Datenspeicherung (ANSI-SPARC-Architektur) hat zur Verbreitung der der RDB beigetragen. Die einheitliche Datenbanksprache (SQL:= Structured Query Language) wurde zum am weitesten verbreiteten Sprache für diese Databanktechnologie und ein wichtiges Element in der Entwicklung datenbankgestützter Programme. Es wurden BI Frontendwerkzeuge entwickelt, die SQL Abfragen auf RDB aus Metadaten heraus generieren. Zur Steigerung der Performance und zur Einführung neuer Eigenschaften haben die Anbieter großer RDB ihre SQL Implementierungen in den letzten Jahren stark erweitert.  Die meisten RDB unterstützen jedoch einen ANSI SQL zum Zugriff und zur Verwaltung von Daten.

Die zunehmende Datenmenge, die Variation der zu verarbeitenden Daten und die Zeit, in der Daten zu verarbeiten sind, stellen RDB vor Herausforderungen.  Genauer: Die Datenspeicherung, Geschwindigkeit von Lese/Schreibzugriffen, Flexibilität in der Tabellendefinition und die horizontalen Skalierbarkeit (Erhöhung Rechnerzahl). Der Begriff NoSQL fasst eine heterogene Menge von Datenbanktechnologien mit unterschiedlichen Funktionalitäten zusammen. „SQL“ steht stellvertretend für RDB und unter „NoSQL“  werden nicht-relationale Datenbanken zusammengefasst. Es gibt derzeit ca. 250 NoSQL Datenbanken, die funktional unterschiedliche Ansätze verfolgen. Eine Übersicht findet sich unter:

http://nosql-database.org/

Wesentliche NoSQL Datenbank Arten

Die einzelnen NoSQL Datenbanken unterschieden sich in den einzelnen Zielsetzungen und Einsatzgebieten. Eine übliche Methode der Einteilung ist eine Untergliederung nach Datenbankmodellen. NoSQL Datenbanken kombinieren wiederum unterschiedliche Datenbanktechniken.

• Key/Value Datenbanken: Diese Datenbanken sind seit den 70er Jahren im Einsatz, z.B. Unix-Datenbanken. Die Datenbanken bedienen sich Schlüssel / Werte Beziehungen. Ein Wert ist immer genau einem Schlüssel zugeordnet. Ein Schlüssel zeigt auf einen Wert, eine (willkürlich) strukturierte Zeichenkette enthalten kann. Es gibt In-Memory und On-Disk Varianten. Key/Value Datenbanken ermöglichen eine einfache horizontale Skalierung.
• Wide Column Datenbanken: Spaltenorientierte Datenbanken sind seit den 90er Jahren im Einsatz, z.B. Sybase IQ. In den Spalten werden der Spaltenname, die Daten und Zeitstempel gespeichert. Lesezugriffe auf einzelne Spalten sind daher sehr perfomant. Es gibt Datenbanken, die die Speicherung von Spalten-Gruppen (Column-Families) erlauben, die keine logische Struktur aufweisen müssen. Diese Spalten-Gruppen können tausende von Spalten enthalten deren Zugriff über Schlüssel erfolgt.  Einem Schlüssel können mehre Werte zugeordnet werden.
• Document Sore: Information Retrieval Systeme sind seit den 70er Jahren im Einsatz, z.B. "Stairs" von IBM oder "Golem" von Siemens. Aber auch Lotus Notes gehört zu solchen Datenbanktechnologien. Die Daten werden nicht in Tabellen, sondern in Dokumenten gespeichert. Ein Dokument ist eine Zusammenstellung von Daten ohne zwingende Schemavorgabe, welches über einen eindeutigen Schlüssel (ID) verfügt.
• XML-Database: XML ist eine Sprache zur Strukturierung textorientierter Informationen (semi-strukturierte Daten). Diese Datenbanken gehören zur Gruppe der „Document Stores“ und wurden Ende der 90er Jahre entwickelt. Die Umsetzung erfolgt auch mit relationalen und objektorientierten Datenbanken.
• Graph Database: Thematisiert wurden diese Datenbanken mit Analysen im Semantic Web Ende der 90er Jahre. Beziehungen zwischen Elementen sind mit relationen Datenbanken nur ressourcenintensiv zu lösen. Es handelt sich um Key/Value Stores, die um die Eigenschaft ergänzt wurden, Beziehungen zwischen Werten abzubilden. Informationen werden als Knoten / Eigenschaften und Kanten (Beziehungen zwischen) Knoten / Eigenschaften abgebildet. Der Graph wird an den Startkonten beginnend durchlaufen (Traversierung).  Gegenüber relationalen Datenbanken können rekursiv geschachtelte Joins vermieden werden.
• Object Databases: Objekt Datenbanken wurden in den 80er Jahren entwickelt. Performance Nachteile, insbesondere beim Schreiben von Daten (insbesondere wegen Locking), konnten gegenüber relationalen Datenbanken in der Vergangenheit nicht gelöst werden. Daten werden als Objekte in der Datenbank verwaltet. Daten (Eigenschaften) und Methoden (Aktionen) zum Zugriff auf die Daten werden in den Objekten zusammen abgelegt.
• Grid Databases: Verteilte Datenbanken und Rechenleistung wurden in den 90er Jahren von wissenschaftlichen und militärischen Einrichtungen eingeführt, um Forschern an unterschiedlichen Standorten durch Replikationen oder Federation Zugriff auf Daten zu gewähren und Rechenleistungen von einzelnen Servern zu Mega-Servern zu vereinen.
• Multidimensional Database:  Multidimensionale Datenbanken wurden in den 80er Jahren entwickelt, um strukturierte Daten in aggregierter Form auswerten zu können (Online Analytical Processing).  Im Gegensatz zum relationalen OLAP (ROLAP) werden im multidimensionalen OLAP (MOLAP) zumeist Daten in multidimensionalen Array gespeichert. Werte können nach Attributen gefiltert und entlang von Attributzusammenhängen aggregiert werden. Große Datenvolumen erhöhen die Laufzeit zur Vorberechnung von Aggregaten. Horizontale Skalierungen werden nur von wenigen Lösungen erreicht, z.B. Kylin basierend auf dem Hadoop-Ökosysem.
  
  

Erweiterungen etablierter Relationaler Datenbankanbieter

Anforderungen am Markt nach neuen Eigenschaften wurden von den etablierten relationalen Datenbankanbietern kontinuierlich durch Produkterweiterungen und Zukäufe begleitet. Datenbanken wurden um XML-Storages erweitert oder die Erstellung von Aggregationen für OLAP Lösungen werden neben In-Memory Funktionen unterstützt. Für relationale Datenbanksysteme wird das strenge ACID Konsistenzmodell (Atomicity, Consistency, Isolation, Durability) bei kritischen Transaktionsdaten notwendig. Für andere Anwendungen genügt das weniger strenge BASE Konsistenzmodell (Basically, Available, Soft State, Eventualle Consistent) aus. Nach dem CAP-Theorem können Daten nicht immer gleichzeitig konsistent, immer verfügbar und ausfalltolerant sein. Es können nur zwei der drei Kriterien erfüllt werden. Eine horizontale Skalierung ist für relationale Datenbanken mit dem ACID Konsistenzmodell schwierig. MPP (Massively Parallel Processing) Datenbanken bieten seit Jahren ACID Konsistenz. MPP Datenbanken verteilen komplexe, Jobs mit viel Datenvolumen auf mehrere Recheneinheiten, die über mehrere Datenbankknoten verteilt sind. MPP Datenbanken enthalten kostenbasierte Optimierer und Monitore zur Verteilung der Daten im System. Bei der Ausführung von SQL-Statements auf strukturierten Daten sind MPP Datenbanken häufig schneller als Hadoop mit Hive.

Die wesentlichen relationalen Datenbankanbieter haben Konnektoren zur Anbindung von Daten aus HDFS (Hadoop File System) an Ihre Datenbanken geschaffen, so dass strukturierte Daten direkt in die Datenbanken geladen werden können. Einige Anbieter wie Teradata unterstützen die Delegation der Berechnung/Aggregation/Filterung von Daten in Hadoop (QueryGrid), so dass Berechnungen dort vorgenommen werden wo die Daten physikalisch gespeichert sind und weniger Datenbewegungen zwischen Hadoop und der Datenbank notwendig werden.

Als Alternative zur rechenintensiven Implementierung von Graphen mit relationalen Join Techniken bieten die Relationalen Datenbankanbieter Lösungen an. IBM setzt dabei auf Apache TinkerPop 3 für seinen Bluemix Graph Data Store und erweitert die relationale Datenbank nicht.  Oracle bietet eine „Spatial and Graph“ Option an, die HBase und Oracle NoSQL Database unterstützt. Auch Teradata erweitert seine MPP Datenbank nicht, sondern erweitert seine Asta Discovery Plattform um Graphen Funktionalitäten, die in SQL und MapReduce Eigenschaften der Produkte integriert werden. Ergänzt werden diese Engines durch analytische Funktionen zur Graphen-Auswertung, z.B. für Social Network Analysis (SNA).

Für Analysen kann ein Zugriff auf heterogene Datenquellen wie Hadoop, z.B. HDFS, Relationale Datenbanken oder andere Datenquellen notwendig sein. Für Analysen ist es mitunter nicht zielführend große Datenmengen zwischen Plattformen für die Analyse zu transferieren. Datenbankanbieter beginnen Optionen für Ihre Plattformen anzubieten, mit denen Analysen auf verteilten Datenquellen durchgeführt werden.  Die Bruttodaten, die zwischen Systemkomponenten zu übertragen sind auf Zwischenergebnisse von Berechnungen beschränkt werden, welche für weitere Analyseschritte an anderer Stelle benötigt werden. Auch die Rechenleistung lässt sich auf diese Weise auf unterschiedliche Server eines analytischen Ökosystems verteilen und zu einem Mega-Analyse Server zu vereinen (Grid-Computing).
Die Relationalen Datenbankanbieter integrieren daher wesentliche Elemente von NoSQL Datenbanken in eigene Produktlinien. Die zugehörigen Funktionalitäten werden meistens außerhalb der Relationalen Datenbank angeboten.

Modellierung in NoSQL Datenbanken

Gegenüber der relationalen Modellierung, bei häufig die verfügbaren Informationen Ausgangspunkt für die Datenmodellierung darstellen, müssen bei der NoSQL Modellierung Anwendungsspezifische Anforderungen berücksichtigt werden. Gerade die Fragestellung der Analyse liefert einen Indikator für die zu nutzende NoSQL Datenbank. Aufgrund der fehlenden standardisierten Abfrage Sprache in NoSQL Datenbanken müssen auf Applikationsseite Datenstruktur und Algorithmen der verwendeten NoSQL Datanbank (detailliert) bekannt sein. Die für die jeweilige Fragestellung ideale NoSQL Datenbank hat Implikationen auf die Modellierung.

Fazit

NoSQL-Datenbanken helfen, die Probleme der relationalen Datenbanken zu vermeiden: RDB können in bestimmten Anwendungsszenarien (hohes Datenaufkommen unstrukturierter oder semi-strukturierter Daten) Schwierigkeiten mit der Performance bekommen. Die vertikale und horizontale Skalierung ist nur eingeschränkt möglich oder kostspielig. RDB sind weniger flexibel bei der Erweiterung des Schemas, z.B. das Hinzufügen einer Tabellenspalte in Kombination mit großen Datenmengen. Im Kontext von BigData werden NoSQL Datenbanken auch als Analytische Datenbanken bezeichnet.

Das Fehlen einer standardisierten Abfragesprache wie ANSI SQL bei RDB in NoSQL Datenbank macht diese als universalen Ersatz für RDB im Business Intelligence Umfeld gegenwärtig unbrauchbar, da zahlreiche Business Intelligence Werkzeuge SQL basierte Abfragen an Datenbanken stellen. Ferner unterstützen viele NoSQL Datenbanken nur das BASE Konsistenzmodell dass ungewisser ist, als das ACID Konsistenzmodell von RDB. NoSQL Datenbanken müssen gegenwärtig als Ergänzung zu traditionellen Data Warehouse Lösungen auf der Basis von RDB gesehen werden.

Das Hadoop Ökosystem stellt sowohl ein Datenarchiv als auch eine Plattform zur Datenanalyse und Aufbereitung bereit. Es bietet die Grundfunktionalitäten eines Data Warehouse, z.B. SQL-Abfragen, oder OLAP Auswertungen in Verbindung mit Reporting-Werkzeugen. In Verbindung mit Lösungen von etablierten Data Warehouse Anbietern ergeben sich vielfältige Möglichkeiten: Hadoop-Verarbeitung können im Data Warehouse oder Data Marts abgelegt werden, während die Rohdaten nur im Hadoop-System (HDFS) existieren. Kunden können Hadoop zum Bestandteil ihrer Buisness Intelligence Infrastruktur machen, ohne ihre existierende Data Warehouse Infrastruktur sofort transformieren zu müssen. Das von Hadoop unterstützte Hive ist nicht so leistungsfähig wie SQL in RDB. Der Umgang mit BigData wird gegenwärtig Data Warehouse Komponenten weiterhin enthalten.

Der Einsatz von NoSQL Datenbanken benötigt das Wissen über Algorithmen zur Abfrage von Daten, der Modellierung von spezifischen Use-Cases, der Installation, Integration in bestehende Umgebungen und dem Betrieb der jeweiligen NoSQL Datenbank. Es ist daher ein signifikanter Knowhow Aufbau bei der Einführung von NoSQL Datenbanken in traditionellen Data Warehouse Umgebungen mit klassischen RDB zu berücksichtigen. Erweiterungen der etablierten Data Warehouse Anbieter ihrer Produkte um NoSQL Komponenten/Optionen stellen einen mögliche Alternative dar, wenn auch hier Erweiterungen der Abfragesprache eingeführt werden und einzelne Komponenten betrieben werden müssen. Jedoch wird bei diesem Ansatz auch die Integration der einzelnen Komponenten durch den Data Warehouse Anbieter übernommen, so dass der Kunde ein abgestimmtes Zusammenspiel traditioneller RDB und NoSQL Komponenten erwarten darf.