Neue Möglichkeiten im Umgang mit Big Data. Eine Kategorisierung von NoSQL-Datenbanksystemen

Inhaltsverzeichnis

Abstract

Abbildungsverzeichnis

Tabellenverzeichnis

Abkürzungsverzeichnis

1. Einleitung

2. Theoretischer Hintergrund

3. Methodisches Vorgehen

4. Literaturanalyse
4.1 Methoden der Kategorisierung von NoSQL-DBS
4.2 Key/Value Stores
4.3 Document Stores
4.4 Spaltenorientierte Datenbanksysteme/ Wide Column Stores
4.5 Graph Datenbanken

5. Ergebnisse

6. Diskussion

7. Zusammenfassung und Ausblick

Anhang

Abstract

Diese Arbeit beschäftigt sich mit der Kategorisierung von NoSQL-Datenbanksystemen. Ziel ist, die Auswahl eines passenden Systems für die jeweiligen Problemlösungsstrategien durch IT- und Business Entscheider zu erleichtern. Durch eine Literaturanalyse werden bereits vorhandene Erkenntnisse und Lösungsansätze gesammelt und verdichtet. Die Ergebnisse werden in Tabellenform gebracht, um die enorme Informationsmenge übersichtlich zu gestalten. Zusätzlich wird der Prozess des Auswahlverfahrens betrachtet und Anregungen zu dessen Methodik gegeben. Die Verknüpfung von wirtschaftswissenschaftlichen Methoden mit den Anforderungen der IT im Umgang mit Big Data wird dabei hervorgehoben.

Abbildungsverzeichnis

Abbildung 1: Big Data

Abbildung 2: CAP-Theorem

Abbildung 3: Consistent Hashing

Abbildung 4: MapReduce Verfahren

Abbildung 5: Gartner-Hype-Cycle 2014

Abbildung 6: vertikale Skalierung

Abbildung 7: horizontale Skalierung

Abbildung 8: Prozess Literaturrecherche

Abbildung 9: Key/Value Store

Abbildung 10: Datentypen in Redis

Abbildung 11: Document Stores

Abbildung 12: Struktur einer Spalte

Abbildung 13: Column Family

Abbildung 14: Wide Column Stores

Abbildung 15: Graphdatenbanken

Abbildung 16: Auswahlverfahren von NoSQL-DBS

Tabellenverzeichnis

Tabelle 1: Gegenüberstellung ACID vs. BASE

Tabelle 2: CAP-Theorem – Alternatives, Traits, Examples

Tabelle 3: NoSQL-DBS vs. SQL-DBS

Tabelle 4: Erkenntnis vs. Gestaltungsziele

Tabelle 5: NoSQL Kategorisierung nach Stephen Yen

Tabelle 6: NoSQL Kategorisierung nach Ken North

Tabelle 7: NoSQL-Kategorisierung nach Rick Cattell

Tabelle 8: Kategorisierung nach Edlich

Tabelle 9: nichtfunktionale NoSQL-Kategorisierung nach Scofield

Tabelle 10: alternative Kategorien nach Edlich

Tabelle 11: Kategorisierung nach Skalierbarkeit

Tabelle 12:Kategorisierung nach Daten- und Abfragemodell

Tabelle 13: Kategorisierung nach Persistenz

Tabelle 14: Kategorisierung nach Use Cases

Tabelle 15: Steckbrief Redis

Tabelle 17: Steckbrief Cassandra

Tabelle 19: SWOT-Analyse NoSQL-DBS

Tabelle 20: Ergebnisübersicht

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1. Einleitung

Motivation und Herleitung des Themas

Seit Jahrtausenden nutzen die Menschen bewusst oder unbewusst die Analyse von Daten zur Informationsbeschaffung. Der rege Austausch der Menschen über ihre Handelsbeziehungen und Gesandten brachte viele Daten über fremde Orte, Sprachen, Religionen, handwerklichen Fähigkeiten und Technologien. Diese galt es auszuwerten und zu analysieren, um daraus nützliche Informationen zu gewinnen. Nur so war es möglich, wichtige Innovationen zu übernehmen oder selbst zu entwickeln. Verbesserungen an Werkzeugen und Waffen, neue Techniken und Innovationen, neue Handelswaren oder Handelspartner, sowie neue Geschäftsmodelle wurden über die Analyse von gesammelten Daten zum Zweck der Informationsbeschaffung gewonnen und entwickelt. Datenanalyse ist also kein Phänomen der Neuzeit, welches in der heutigen, stark technisierten, Welt auftritt, sondern war schon immer ein Teil der menschlichen Entwicklung. Was sich im Laufe der Zeit dabei änderte, war die Anzahl der Arten, in denen Daten auftreten können, die Menge an Daten und die Geschwindigkeit, mit der neue Daten entstehen. Der Prozess der Datenanalyse war somit permanent starken Veränderungen unterworfen, an die man sich mit neuen Methoden und neuartigen Technologien anpasste.

Seit dem Beginn des Informationszeitalters hat sich die Anzahl neuer Datenarten, die Größe der Datenmengen und die Geschwindigkeit, in der sie erzeugt werden stark erhöht (Kaufmann and Barthen). So erhöht sich nach Einschätzung von IDC (2014a) und einem Speichersystem-Herstellers EMC der globale Datenbestand etwa alle zwei Jahre (Jüngling 2013). Daten werden nun nicht mehr allein durch Menschen erhoben, sondern werden spätestens mit dem Auftreten des Web 2.0 (Gabler Wirtschaftslexikon) und der Industrie 4.0 (Spath 2013) auch durch technische Geräte und deren Kommunikation untereinander erzeugt. Diese Daten entsprechen oft nicht mehr den üblichen Datenstandards und lassen sich nicht mehr so einfach in die traditionellen relationalen Datenbanksysteme (RDBS) integrieren (Baron 2012; IBM Corporation 2014; T-Systems 2013). Hier stößt die traditionelle Business Intelligence (BI) (Levitt and Whisler 1958; Morton and Rockart; Kemper et al. 2010) mit ihren bisherigen Methoden und Techniken an ihre Grenzen.

In jüngster Zeit werden vermehrt neue Möglichkeiten im Umgang mit großen Datenmengen (Big Data) gesucht und entwickelt (Rabl et al. 2012). Viele Methoden und Technologien abseits der etablierten SQL-Datenbanksysteme ermöglichen das Erfassen, Analysieren und Speichern von beliebig großen und unterschiedlich strukturierten Datenmengen. Die wirtschaftliche Bedeutung von Daten ist inzwischen als sehr groß anzusehen. Daten werden schon neben Arbeitskraft, Ressourcen und Kapital als vierter Produktionsfaktor angesehen. (Horvath 2013) Je nachdem, in welcher Form die Daten vorliegen, sind unterschiedliche Tools notwendig, um die gewünschten Informationen daraus zu extrahieren. Auch die Art der Speicherung und die Zugriffsgeschwindigkeit setzen verschiedene Anforderungen an Datenbanksysteme (DBS) (Düvel and Thieleke 2014). Neben den etablierten SQL-DBS haben sich NoSQL (für Not-Only-SQL)-Datenbanksysteme (NoSQL-DBS) etabliert, die für bestimmte Herausforderungen, wie gute Skalierbarkeit, vernetzte Informationen und die Speicherung unterschiedlich strukturierte Daten besser geeignet sind (Celko 2013).

Ziel der Arbeit

Ziel dieser Arbeit ist es, anhand einer Analyse der Primär- und Sekundärliteratur sowie von Informationen von Entwicklern und Angehörigen der NoSQL-Community, die unterschiedlichen Potenziale von NoSQL-DBS herauszuarbeiten und einander gegenüber zu stellen. Dadurch soll IT- und Business-Entscheidern die Möglichkeit gegeben werden, schneller passende Lösungen für ihre speziellen Probleme im Umgang mit Big Data zu finden.

Forschungsfrage

Es soll im Rahmen einer zusammenfassenden Arbeit (Becker et al. 2003; Roth and Heidenreich 1995; Schwaiger and Meyer 2009; Schultka 2012) die folgende Forschungsfrage beantwortet werden:

Kategorisierung und Beschreibung von Eigenschaften, sowie Vor- und Nachteilen von NoSQL-Datenbanksystemen.

Diese Forschungsfrage wird anhand folgender Leitfragen beantwortet:

- Welche NoSQL-DBS sind auf dem Markt zugänglich und relevant für die Studie?
- Welche Kategorisierungen werden in der Literatur genannt?
- Sind die Kategorien trennscharf?
- Lassen sich NoSQL-DBS eindeutig kategorisieren?
- Welche Eigenschaften definieren ein NoSQL-DBS?
- Welche Probleme können nicht durch relationale Datenbanken gelöst werden?
- Welche Chancen und Risiken ergeben sich durch den Einsatz von NoSQL-DBS?
- Was sind die Grenzen der Leistungsfähigkeit von NoSQL-DBS?

Aufbau der Arbeit

Zu Beginn der Arbeit werden wichtige Fachbegriffe erläutert und allgemein anerkannte Definitionen aufgeführt. Nachfolgend wird auf die Auswahl und Art der Forschungsmethode eingegangen. Darauf aufbauend erfolgt die Kategorisierung und nähere Beschreibung von NoSQL-DBS unter Zuhilfenahme der Leitfragen. Zudem wird je ein Vertreter der jeweiligen Kategorie vorgestellt und beschrieben. Die Ergebnisdarstellung der Arbeit erfolgt durch Gegenüberstellungen der NoSQL-DBS aufgrund ihrer Eigenschaften und Einsatzmöglichkeiten durch Tabellen und Grafiken. Eine kritische Würdigung des Forschungsdesigns, der Ergebnisse und die Erläuterungen zur Limitation der Arbeit werden im Diskussionsteil behandelt. Am Ende der Arbeit werden die Ergebnisse nochmals zusammengefasst und ein Ausblick auf weitere interessante Forschungsgebiete und Fragestellungen gegeben.

2. Theoretischer Hintergrund

Um einen ausreichenden theoretischen Hintergrund für diese Arbeit zu schaffen, werden die wichtigsten Begriffe, welche in dieser Arbeit benutzt werden, beschrieben und Definitionen aus Lehrbüchern und dem Internet, sowie der NoSQL-Community aufgeführt.

API

Die Kurzform API steht für „Application-Programming-Interface“ aus dem Englischen, was ins Deutsche übersetzt in etwa Schnittstelle zur Anwendungsprogrammierung“ bedeutet. Umgangssprachlich hat sich der Begriff Programmierschnittstelle durchgesetzt (Vertical Media GmbH). Charakterisierende Merkmale von Programmierschnittstellen sind die Programmiersprache, der Funktionsumfang, sowie die Komplexität. Aufgrund der verschiedensten Anwendungsbereiche unterscheidet man zwischen funktions-, protokoll-, datei- und objektorientierten Schnittstellen. Genutzt werden sie für Dienste und Netzwerke, Anwendungsprogramme und Datenbanken, Telekommunikationsdienste, Webservices und Programmiersprachen (Lipinski, Klaus et al. 2013; Dig and Johnson 2006; Gamma et al. 2011).

ACID (Transaktionskonzept)

Ein Datenbankmanagementsystem (DBMS) hat unter Berücksichtigung der Möglichkeit des Auftretens von Fehlern folgende Bedingungen zu gewährleisten, die einen konsistenten Zustand der Daten über eine korrekte Ausführung von Transaktionen garantieren (ACID-Prinzip) (Fink et al. 2005; Klug 2008):

Atomarität (Atomarity):

Transaktionen werden entweder vollständig oder gar nicht durchgeführt. Die kleinste Transaktion enthält eine einzige SQL-Anweisung.

Konsistenz (Consistency):

Alle Integritätsbedingungen der Datenbank werden nach der Ausführung einer Transaktion eingehalten. Beispielsweise ist eine doppelte Vergabe von Schlüsselattributen nicht möglich.

Isolation:

Transaktionen laufen isoliert von anderen (potenziell parallelen) Transaktionen ab. Sie beeinflussen sich nicht gegenseitig.

Persistenz (Durability):

Abgeschlossene Transaktionen müssen alle nachfolgenden Fehler überleben (auch wenn die Daten nur in einem Zwischenpuffer (Cache) liegen (vgl. Fink et. Al. 2005).

BASE

Dateninkonsistenz in hochskalierten, verteilten Systemen muss aus zwei Gründen toleriert werden. Zum Ersten wegen der erhöhten Schreib-/Lesegeschwindigkeit bei gleichzeitigen Zugriffen auf den Datenbestand und zum Zweiten um den Zugriff auf Partitionen zu erlauben, noch bevor sie mit den neuesten Daten beschrieben wurden (Vogels 2009).

BASE ist also diametral entgegengesetzt zu ACID. Dort, wo ACID pessimistisch ist und die Konsistenz der Daten nach jeder Operation fordert, ist BASE optimistisch und akzeptiert, dass sich die Datenbankkonsistenz in einem Zustand des Fließens befindet. Obwohl dies unrealistisch erscheint, ist es in Wirklichkeit einfach zu bewerkstelligen und führt zu Größenordnungen der Skalierbarkeit, die mit dem ACID-Prinzip nie erreicht werden können. Die Verfügbarkeit von BASE wird erreicht durch die Tolerierung partialer Fehler, die somit nicht zum totalen Systemausfall führen. Wenn z.B. Nutzerdaten auf fünf Datenbanken verteilt sind, führt das BASE-Design dazu, dass ein Ausfall einer Datenbank nur die 20% der Nutzerdaten betrifft, welche auf dem betroffenen Host liegen (Pritchett 2008).

Bei BASE steht die Verfügbarkeit an erster Stelle (Basic Availability). Die Konsistenz wird nachrangig behandelt und ggf. den Applikationen übertragen (Soft State). Nach Beendigung einer Transaktion sind nicht immer alle Datenbanken konsistent, werden jedoch schnellstmöglich auf den neuesten Stand gebracht(Eventually Consistent). „ACID und BASE kann man sich als zwei Endpunkte einer Dimension denken, auf der sich die verschiedenen Datenbanken verorten lassen. Die bekannten RDBS sind dabei eher an ACID gelagert, während viele NoSQL-DB näher an BASE liegen“ (Düvel and Thielecke, p.3).

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 1: Gegenüberstellung ACID vs. BASE

Quelle: angelehnt an (Brewer 2000a; Strauch 2011)

BI (Business Intelligence)

Business Intelligence ist die IT-basierte Managementunterstützung (Kemper et al. 2010; Morton and Rockart). Bereits in den 1960er Jahren wurden erste Versuche unternommen, Führungskräfte mit der Hilfe von Informationssystemen zu unterstützen. Durch zu enthusiastische Technikgläubigkeit und eines zuvorderst mechanistisch ausgerichteten Organisationsgedankens entstanden umfassende Ansätze, die jedoch alle scheiterten (Kemper et al. 2010). Später gelang es, auf Benutzergruppen spezifizierte und aufgabenorientierte Einzelfalllösungen zu entwickeln, die erfolgreich als Managementunterstützung eingesetzt werden konnten. In den 1980er Jahren wurde für diese Sammlung von Informations- und Kommunikationssystemen (IKS) der Sammelbegriff Management Support System (MSS) eingeführt, der im Deutschen als „Managementunterstützung“ bekannt geworden ist (Morton and Rockart). Protagonisten dieses Ansatzes, definierten den Begriff Management Support Systems als „the use of computers and related information technologies to support managers“ (Morton and Rockart), p. 5). Bereits vor Jahrzehnten wurde deutlich, dass die Unterstützung des Managements nicht auf den Computer begrenzt bleibt, sondern die gesamte Informations- und Kommunikationstechnologie erfassen wird. Scott Morton konstatierte zu dieser Zeit bereits treffend, dass Telefonkonferenzen, elektronische Datenbanken und grafische Workstations wichtige Werkzeuge für Business Intelligence sein werden (Kemper et al. 2010; Morton and Rockart). Das Gartner IT Glosary beschreibt BI als: „Business intelligence (BI) is an umbrella term that includes the applications, infrastructure and tools, and best practices that enable access to and analysis of information to improve and optimize decisions and performance.“ (Gartner IT Glosary 2013)

Big Data

Bei Big Data geht es nicht um eine einzelne neue Technologie. Vielmehr bezeichnet Big Data ein Bündel neu entwickelter Methoden und Technologien, die die Erfassung, Speicherung und Analyse eines großen und beliebig erweiterbaren Volumens unterschiedlich strukturierter Daten ermöglicht(Horvath 2013). „Die Menge an Daten, die erstellt, vervielfältigt und konsumiert werden, wird 2020 bei etwa 40 Zettabytes liegen und damit 50-mal so hoch sein, wie noch vor drei Jahren (somit in 2010, der Autor), schätzen die Marktbeobachter von IDC und des Speichersystem-Herstellers EMC. Hinter einem Zettabyte stehen schon 21 Nullen“ (Jüngling 2013).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Big Data

Quelle: (Connolly 2012)

Unter Big Data versteht man unterschiedliche Arten zur Nutzung von Business Analytics. Technologisch bietet Big Data neue technologische Ansätze wie Hadoop, hochskalierbare Datenbanken, optimierte Visualisierungs-Tools, High-Performance-Suchmaschinen und ausgereifte Technologien (Event-getriebenes Processing, Business Intelligence und Data Mining), mit dem Schwerpunkt große Datenmengen (Zacher 2013). Big-Data-Technologien sind Techniken zur Verarbeitung großer Datenmengen (Volume), zur Nutzung und Speicherung semi-strukturierter Daten (Variety) und deren permanente Veränderung (Velocity)(Kaufmann and Barthen). „Die bisher gängigste Big-Data-Definition liefert Russom mit Verweis auf Gartner mit dem 3V-Modell: „Size matters, but there are other important attributes of big data, namely data variety and data velocity“. (Kaufmann and Barthen, p.146)

BigTable

Ein Entwicklerteam von Google um Fay Chang und Jeffrey Dean, der schon an der Entwicklung von MapReduce beteiligt war, veröffentlichte 2006 einen Artikel über BigTable als verteiltes System zum Speichern strukturierter Daten bei Google (Chang et al. 2006). Da BigTable ein geschlossenes System von Google ist wurden Open Source Implementierungen entwickelt die sich an die BigTable Architektur anlehnen. Ein Beispiel hierfür ist HBase (Erklärung nachfolgend im Theorieteil unter HBase).

BSON

BSON ist eine Weiterentwicklung des Datenaustauschformates JSON der Firma 10gen und ist unter anderem ein fester Bestandteil von MongoDB. Die Libraries sind für viele Programmiersprachen bereits vorhanden. Da die BSON-Spezifikation öffentlich ist, kann BSON auch für andere Projekte genutzt werden (FH Köln; Edlich 2011).

CAP-Theorem

Eric Brewer, ein Professor an der Universität von Kalifornien in Berkley, und Mitgründer sowie leitender Wissenschaftler der Firma Inktomi machte 2000 mit einem Vortrag auf sich aufmerksam, in welchem er logisch schlussfolgerte, dass ein Webdienst nicht alle drei folgenden Aufgaben gleichzeitig erfüllen kann (bekannt durch das Akronym CAP):

Consistency (Konsistenz): Der Client erkennt, dass eine Reihe von Operationen auf einmal aufgetreten ist.

Availability (Verfügbarkeit): Jede Operation muss mit einer beabsichtigten Antwort enden.

Partition tolerance: Operationen werden vollendet, selbst wenn individuelle Bestandteile nicht verfügbar sind.

Eine Web-Applikation nur höchstens zwei der genannten Zustände mit jedem existierenden Datenbankdesign unterstützen. Da aber die horizontale Skalierung auf Datenpartitionierung basiert, sind Datenbankentwickler gezwungen, sich zwischen Konsistenz und Verfügbarkeit zu entscheiden (Pritchett 2008; Brewer 2000a, 2012).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: CAP-Theorem

Quelle: (googleusercontent)

Tabelle 2: CAP-Theorem – Alternatives, Traits, Examples zeigt die verschiedenen Wahlmöglichkeiten laut Brewer, die damit verbundenen Probleme und zugehörige Einsatzbeispiele.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2: CAP-Theorem – Alternatives, Traits, Examples

Quelle: angelehnt an (Brewer 2000a; Strauch 2011)

Cloud Computing

Münzel beschreibt in seinem Buch von 2009 Cloud Computing als Business Innovator und große Hoffnung der IT-Industrie. „Cloud Computing ist eine Form der bedarfsgerechten und flexiblen Nutzung von IT-Leistungen. Diese werden in Echtzeit als Service über das Internet bereitgestellt und nach Nutzung abgerechnet. Damit ermöglicht Cloud Computing den Nutzern eine Umverteilung von Investitions- zu Betriebsaufwand“(Münzl et al. 2009, p.9). Jedoch wird Cloud Computing sehr unterschiedlich definiert. Beispielsweise bezeichnet IBM Cloud Computing als neues Paradigma der IT nach den Evolutionsschritten des Zentralcomputers (1960) und dem Client/Server-Modell (1985) (MKWI 2012; Pelzl 2012; Münzl et al. 2009)

Consistent Hashing

Zur Flexibilisierung der herkömmlichen HASH-Funktionen, die bei RDBS genutzt werden, wird Consistent Hashing verwendet. Es stellt ein zentrales Konzept von NoSQL-Systemen dar. Der Speicherplatz einer NoSQL-DB ist meist auf vielen hundert bis tausenden von Servern verteilt. Bei Serverausfällen müssen diese Daten redundant auf anderen Servern vorliegen. Dafür wird auf den Servern, die dem ausgefallenen im Uhrzeigersinn folgen, der redundante Datenbestand abgelegt. Wird ein neuer Server in das bestehende System eingefügt, werden Daten des Servers, der im Uhrzeigersinn vor dem neuen Server liegt, auf dem neuen Server gespeichert (Abbildung 3: Consistent Hashing).

DBS

Datenbanksysteme bilden einen zentralen Bestandteil typischer betrieblicher Anwendungssysteme. Ein Datenbanksystem besteht aus einem einheitlich definierten Datenbestand (Datenbank) und einem DBMS, das diesen Datenbestand verwaltet. Ein Zugriff auf die Daten ist nur über das DBMS nach dessen Kriterien (hinsichtlich Datenintegrität und -Sicherheit, Synchronisation usw.) möglich (Fink et al. 2005).

Eventually consistent

Eventually Consistency ist eine Form der schwachen Konsistenz. Dabei können Daten innerhalb einer bestimmten Zeit inkonsistent sein, was viele Web-Applikationen, von Finanztransaktionen abgesehen, ohne Probleme erlauben können. Dadurch wird eine erhebliche Verbesserung bei der Performance von Lese- und Schreibeoperationen erreicht. Zusätzlich wird die Partitionstoleranz verbessert, da das System auf Anfragen reagieren kann, selbst wenn die Mehrheit der Server nicht erreichbar ist. Das Eventually Consistent-Konzept ist eine neue Antwort auf die Probleme im Umgang mit großen Datenmengen, Nutzerzahlen und den extrem angestiegenen Anforderungen an Antwortzeiten, da diese mit den strikten Transaktions- und Konsistenzbegriffen, wie sie von den RDBS her bekannt sind, nicht mehr gelöst werden konnten. Die zentrale Technik dieses Ansatzes ist der Einsatz verteilter Datenbanksysteme, welche wiederum die Probleme des CAP-Theorems beinhalten. Daraus entwickelt sich ein ganz neues Verständnis von Konsistenz, als Zustand der irgendwann erreicht wird. Deshalb wurde alternativ zu den ACID-Eigenschaften mit BASE ein alternatives Konzept entwickelt (Edlich 2011; FH Köln). Brewer hat sich 2012 in einem neuen Artikel dahingehend geäußert, dass das CAP Theorem nicht als so starr zu betrachten ist, wie bisher angenommen. Es muss, durch geschickte Datenbankstrukturierung, nicht mehr vollständig von der Anwendungsart abhängig sein, ob Consistency oder Availability bevorzugt wird (Brewer 2012).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Consistent Hashing

Quelle: (FH Köln)

HBase

HBase ist eine auf Open Source basierende, in Java geschriebene, nicht-relationale, verteilte Datenbank, die nach dem Vorbild von Google´s BigTable modelliert wurde. Sie wurde als Teil des Apache Hadoop Projektes der Apache Software Foundation entwickelt und läuft auf dem Hadoop Distributed File System (HDFS), um BigTable-ähnliche Eigenschaften für Hadoop zur Verfügung zu stellen. Zusammengefasst stellt es einen fehlertoleranten Weg zur Verfügung, eine große Anzahl an “sparse”-Daten zu speichern. Das sind kleine Mengen an Informationen, welche innerhalb großer leerer oder unwichtiger Datenmengen liegen. Es ähnelt der Suche nach der Stecknadel im Heuhaufen, bspw. die 50 größten Dateneinheiten in einer Gruppe von 2 Mrd. Einträgen zu finden, oder Einträge ungleich Null zu finden, die weniger als 0,1% eines riesigen Datenbestandes ausmachen (George 2011). HBase stellt Kompressionsalgorithmen, in-Memory-Operationen und Bloom Filter auf Basis von spaltenorientierter Verarbeitung bereit, wie es im originalen BigTable-Aufsatz beschrieben wird (Chang et al. 2006). Tabellen in HBase können als Ein- und Ausgabequellen für MapReduce Aufträge dienen, welche in Hadoop laufen und durch die Java API oder auch durch REST-, Avro- oder Thrift-API´s angesprochen werden. HBase ist kein direkter Ersatz für ein klassisches RDBS, aber die Performance ist verbessert und sie unterstützt mehrere datenintensive Websites, inklusive Facebook´s Messaging Plattform (Apache Software Foundation 2014a). Nach der Definition von Eric Brewer´s CAP-Theorem ist HBASE ein CP-Type. Es wird also der Schwerpunkt auf Konsistenz, statt auf Verfügbarkeit gelegt.

Hadoop

Hadoop ist ein in Java geschriebenes Framework für verteilte und skalierbare Software (Apache Software Foundation 2014b). Stärken sind die Schnittstellen, Verarbeitung der Rohdokumente und Skalierbarkeit. Zusätzlich die kostenlose Verfügbarkeit, eine einfache Integration in analytische Informationssysteme, die Plattformunabhängigkeit und die Möglichkeit, eine Vielzahl von verschiedenen Daten auszuwerten (Kaufmann and Barthen).

Industrie 4.0

Darunter wird die beginnende vierte industrielle Revolution nach Mechanisierung, Industrialisierung und Automatisierung verstanden. Das zentrale Element sind vernetzte Cyber-Physische Systeme (CPS) (Spath et al.). Sie ist ein Zukunftsprojekt in der Hightech-Strategie der Bundesregierung. Das Ziel ist die intelligente Fabrik (Smart Factory), in der Ressourceneffizienz, Ergonomie sowie die Einbindung von Stakeholdern in die Geschäfts- und Wertschöpfungsprozesse optimiert wird. „Technologische Grundlage sind Cyber-physische Systeme und das Internet der Dinge.“ (Wikipedia 2014)

Javascript Object Notation (JSON)

JSON ist ein kompaktes Datenaustauschformat. Es ist für Menschen leicht zu lesen und zu schreiben, für Maschinen leicht zu analysieren und zu erzeugen. Es basiert auf einer Teilmenge der Programmiersprache von JavaScript, Standard ECMA-262 3. Ausgabe - Dezember 1999. JSON ist ein Textformat, das völlig sprachenunabhängig ist, aber Vereinbarungen verwendet, die für Programmierer der C-Sprachfamilie, einschließlich C, C ++, C#, Java, JavaScript, Perl, Python und vielen anderen vertraut ist. Diese Eigenschaften machen JSON zu einer idealen Datenaustauschsprache (2014b).

MapReduce

MapReduce (Dean and Ghemawat 2004) ist ein von Google Inc. 2004 eingeführtes Framework für nebenläufige Berechnungen über enorm große (mehrere Petabyte) Datenmengen auf Computerclustern. Dieses Framework wurde durch die in der funktionalen Programmierung häufig verwendeten Funktionen „map” und „reduce” inspiriert, auch wenn die Semantik des Frameworks von diesen etwas abweicht. 2010 wurde für MapReduce ein US-Patent erteilt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: MapReduce Verfahren

Quelle: (FH Köln)

MapReduce-Implementierungen wurden in C++, Erlang, Java, Python und vielen anderen Programmiersprachen realisiert. Das Konzept Map/Reduce stammt aus dem Bereich der funktionalen Programmiersprachen wie LISP (List P rocessing) und ML (Meta L anguage), was auf die Vorteile funktionaler Sprachen im Umgang mit der Parallelisierung zurückzuführen ist. Da dort nur auf neu erstellten Kopien der Daten, nicht aber auf den vorhanden Datenstrukturen, also dem Originaldatensatz, gearbeitet wird, kann es weder zu Verklemmungen (deadlock), noch zu Wettlaufbedingungen (race conditions) kommen: zwei sehr ernst zu nehmenden Problemen in der nebenläufigen Programmierung. Ohne diese Seiteneffekte spielt die Ausführungsreihenfolge keine Rolle und man kann von einer "echten Parallelisierung" sprechen. Der Grundgedanke dabei ist, eine Funktion sukzessiv auf Listen anzuwenden (FH Köln; Edlich 2011).

Normalisierung

Ein Hauptziel des relationalen Datenmodells liegt in der Vermeidung von Redundanzen, also dem mehrfachen Vorkommen eines Inhaltes. Um dies zu erreichen wird ein Datenschema normalisiert, indem die Tabellenstruktur der Datenbank daraufhin optimiert wird, dass jede Information nur einmal auftaucht. Aus Redundanzen resultieren ein höherer Wartungsaufwand und die Fehleranfälligkeit der Datenbank. Bei Änderungen eines Datensatzes müssen sonst an mehreren Stellen Änderungen vorgenommen werden. Dies birgt die Gefahr, dass nicht alle benötigten Änderungen berücksichtigt werden und so Anomalien im Datenbestand auftreten können. Jedoch bringt die Normalisierung auch Nachteile mit sich. Das Datenschema wird komplexer und damit auch das Abfragen der gespeicherten Daten. Da die zusammengehörenden Inhalte auf mehrere Tabellen verteilt abgelegt wurden, müssen diese bei einer Abfrage wieder verbunden werden. Dies geschieht durch Joins. Bei Datenbanken mit hohem Datenaufkommen, was bei Webanwendungen immer häufiger der Fall ist, führt dies zu inakzeptabel hohen Reaktionszeiten. In der Praxis wird daher oft gezielt denormalisiert, also bewusst Redundanz hinzugefügt, um performantere Abfragen zu ermöglichen. NoSQL-DBS nutzten dieses Denormalisieren für den Performancegewinn unter Weglassen von Join-Abfragen aus (Hofstetter 2012; Geisler and Geisler 2011).

NoSQL

Der Begriff NoSQL wurde erstmals 1998 von Carlo Strozzi für eine Datenbanksoftware verwendet, die auf dem Relationenmodell basierte, aber nicht SQL nutzte. 2009 tauchte der Begriff dann in einem Weblog von Eric Evans auf und wurde von Johan Oskarsson für das NoSQL Meetup am 11.6.2009 in San Francisco genutzt. Carlo Strozzi, der "Vater" jener NoSQL-Datenbank, schlug übrigens "NoREL" als Bezeichnung vor, ein besser treffender Begriff, weil SQL nur die Sprache für relationale Datenbankoperationen bezeichnet und ursprünglich unter anderer Zielsetzung als SEQUEL durch Boyce & Chamberlin bei IBM entwickelt worden war (FH Köln). 2011 waren schon über 120 verschiedene NoSQL-DBS bekannt (Tudorica and Bucur).

Die folgenden Bereiche können von RDBS nur schwer modelliert werden: (Ebner WS 2013/14)

- Document Storage and Indexing
- Recursive Data and Graphs (Netzwerke)
- Time Series Data

Daher hat das vermehrte Auftauchen von NoSQL-Datenbanksystemen einen direkten Zusammenhang mit den Restriktionen von RDBS beim Umgang mit großen und unstrukturierten Datenmengen (Sverchkov 2014).

Historie (FH Köln)

- 1979 Ken Thompson entwickelte DBM, eine erste Key/Value-DB.
- 80er Heute noch beliebte Vorreiter sind Lotus Notes, BerkleyDB, GT.M, die sich jedoch noch durch die Verarbeitung geringer Datenmengen auszeichnen.
- 1998 Carlo Strozzi (IBM) prägte den Begriff „NoSQL“ im Sinne von "no SQL" für seine zwar relationale Datenbank aber ohne SQL-API.
- 2000 Zusammen mit Web2.0 kam der Wunsch sehr viel größere Datenmengen zu verarbeiten.
- Google war Vorreiter mit der Entwicklung solcher grundlegender Technologien wie Map/Reduce-Framework (2004), BigTable-DBS (2004), Google File System, dem eigenen Hochgeschwindigkeits-Dateisystem.
- Alle übrigen Internet-Größen zogen nach: Yahoo, Amazon, MySpace, Facebook, LinkedIn
- 2006-2009 In dem Zeitraum entstanden alle klassischen NoSQL-Systeme wie z.B. Cassandra, CouchDB, Dynamo/Dynamite, Hbase, Hypertable, Neo4j, MongoDB, Redis, Riak, S3, Scalaris, SonesDB, Voldemort
- 2009: NoSQL wird zum gemeinsamen Schlagwort immer mehr im Sinne von "Not Only SQL" und damit treten die Systeme stärker in die öffentliche Wahrnehmung, weg von Image der speziellen Internet-Datenbanken hin zu passenden Lösungen für Probleme auch von Nicht-Internet-Firmen und -Organisationen.

Definition

Bislang gibt es keine einheitliche und streng abgrenzende Definition für NoSQL, dafür ist die Community noch viel zu sehr im Fluss. Hier ein Versuch einer Definition wie sie Edlich, Friedland, Hampe, Brauer in ihrem Buch (Edlich 2011), pp. 2-5) vorgenommen haben.

Kein relationales Datenmodell

Es gibt Vielfalt an Modellen, weil dass das relationale Modell nicht immer für jede Anforderung am besten passt. Ein typisches Beispiel dafür sind graphenbasierte Probleme wie Netzwerke und Topologien, die am besten mit Graphenmodellen und mit Graphendatenbanken gelöst werden. Man benötigt zur Auswahl eines geeigneten Datenmodelles z.B. die SWOT-Analyse (Strengths/Stärken, Weakness/Schwächen, Opportunities/Chancen, Threats/Bedrohungen), um herauszufinden, welches Modell bzw. DBS, relationale, objektrelationale, objektorientierte oder eine NoSQL-DBS am geeignetsten ist.

Eignung für Systeme mit verteilter und horizontaler Skalierbarkeit

Schnelle Reaktionszeiten auf Anfragen und Manipulationen erreicht man mit horizontaler Skalierung (Scale-out) durch dynamisches Einbinden/Löschen von Rechnerknoten (Nodes).Relationale Datenbanksysteme (RDBS) benutzen jedoch meistens die vertikale Skalierung (Scale-up), bei dem ein Rechner immer weiter aufgerüstet wird.

Da die Systeme fehlertolerant gegenüber Rechnerausfällen arbeiten müssen und können, dürfen Knoten (Rechner) aus einfacherer Hardware bestehen, dabei werden zusätzlich Investitionskosten eingespart.

Open Source

Dies ist sicherlich kein Ausschlusskriterium. Es gibt auch schon eine Reihe von lizensierten NoSQL-DBS, wie CouchDB, Neo4j und andere Lizenz- und Geschäftsmodelle. Bei der Auswahl eines passenden NoSQL-DBS sollte die Funktionalität vor der Frage geklärt werden, ob Open Source eingesetzt wird oder nicht.

Schemafrei oder nur schwächere Schemarestriktionen

Anwendungen für das Web2.0 müssen bei den Datenstrukturen beweglich sein. Informationen im Web, Dokumente, Video-/Audiodateien und soziale Netzwerke haben unterschiedlichste Strukturen. Das müssen Anwendungen und DB-Systeme verarbeiten können. Daher werden die Schemainformationen in die Anwendung (wieder zurück-) zu verlagert. Schnelle Reaktionszeiten bei Schemaänderungen sind unverzichtbar und dürfen Datenbanksysteme nicht, wie bei den RDBS, minuten- oder stundenlang lahm legen.

Einfache Datenreplikation zur Unterstützung der verteilten Architektur

Die Verteilung der Daten auf viele Knoten benötigt eine einfache und schnelle Replikation der Daten, damit Daten auch bei Kontenausfällen noch verfügbar sind. Bei den meisten NoSQL-Systemen ist dies durch Consistent Hashing gut gelungen. Ermöglicht wird dies durch die geänderten, „aufgeweichten“ Konsistenzanforderungen, wie sie die Annahmen des CAP-Theorems und des „eventually consistency“ beschreiben. In der Praxis umgesetzt werden sie durch das BASE-Konsistenzmodell.

Einfache API

SQL ist einfach und sehr ausdrucksstark, vor allem aber standardisiert. Eine einfache API ist bei den meisten NoSQL-Systemen noch nicht realisiert. Viele APIs sind zwar einfach, aber meistens nicht so ausdrucksstark (weniger Funktionalität). Dies muss dann die Anwendungsprogrammierung ausgleichen. Es werden aber viele neue API´s entwickelt, die gerade den Web2.0-Anforderungen gerecht werden sollen.

Kein ACID als Konsistenzmodell

Die Einhaltung von ACID-Eigenschaften ist bei verteilten DBS sehr kompliziert und verlangsamt die Reaktionszeiten enorm. Damit stellt die Skalierbarkeit in RDBS ein zentrales Problem dar. „Eventually consistency“ und optimistischer BASE-Ansatz beruhen jedoch auf der Annahme, dass Daten in verschiedenen Knoten vorübergehend inkonsistent sein dürfen. In vielen Internetanwendungen ist dies möglich. Wichtige Geschäftsdaten können trotzdem mit angebundenen RDBS und ACID-Eigenschaften betrieben werden. Es gibt auch Systeme, die mit ACID, mit BASE oder wahlweise mit beiden ausgeführt werden können.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 3: NoSQL-DBS vs. SQL-DBS

Quelle: selbst erstellt basierend auf (Edlich 2011)