NoSQL Datenbanken

LV Datenorientierte Systemanalyse, WS 2014/15

Dr. Walter Ebner, <walter.ebner@wu.ac.at>

Institut für Informationswirtschaft

Wirtschaftsuniversität Wien

Date

norientiert

e S

yste

manaly

se –

NoS

QL

5

Überblick

Abgrenzung zu relationalen Datenbanksystemen

NoSQL Features

CAP-Theorem

ACID versus BASE

Die vier NoSQL Produktkategorien

• Key-Value Stores

• Column-based Stores

• Document Stores

• Graph Databases

Date

norientiert

e S

yste

manaly

se –

NoS

QL

6

Relationale Datenbanksysteme

Grundlage ist die Relation

wird bei relationalen DBMS als Tabelle bezeichnet

Es gibt das Konzept eines Schemas:

• Tabellen (Spalten haben eine definierten Datentyp

und eine bestimmte Genauigkeit bzw. Länge)

• Definierte Primär- und Fremdschlüssel

Alle Daten sind in Tabellen abgelegt

Abfragen basieren auf der relationalen Algebra

• Selection, Projektion, Mengenoperationen, Joins

Die Standard-Abfragesprache heißt SQL

Date

norientiert

e S

yste

manaly

se –

NoS

QL

7

Relationale Datenbanksysteme

Relationale Datenbankmanagementsysteme:

• Neben SQL bieten einige DBMS noch mächtige

Programmiersprachen an: PL/SQL (Oracle),

PL/pgSQL (PostgreSQL), Transact-SQL (MSSQL)

• Relationale Datenbankmanagementsysteme setzen

die ACID Anforderungen um.

Date

norientiert

e S

yste

manaly

se –

NoS

QL

8

ACID

• Atomic: All operations in a transaction succeed or every

operation is rolled back.

• Consistent: On transaction completion, the database is

structurally sound.

• Isolated: Transactions do not contend with one another.

Contentious access to state is moderated by the database so

that transactions appear to run sequentially.

• Durable: The results of applying a transaction are permanent,

even in the presence of failures.

Unter dem Begriff ACID werden die Garantien für Datenbank-

transaktionen zusammengefasst. Eine Transaktion ist eine

einzelne logische Operation, die auf die Daten angewendet wird.

Date

norientiert

e S

yste

manaly

se –

NoS

QL

9

NoSQL?

• NoSQL steht nicht für „Nein zu SQL“ sondern für:

• Der Begriff NoSQL wurde 2009 von Eric Evans, einem Software

Entwickler bei der Apache Software Foundation, geprägt.

• Klasse von nicht-relationalen Datenspeicherungssystemen

• Haben normalerweise kein fixes Schema

• Viele NoSQL Lösungen weichen eine oder mehrere ACID

Anforderungen auf.

Date

norientiert

e S

yste

manaly

se –

NoS

QL

NoSQL – Der Anfang

• Die folgenden wissenschaftlichen Artikel bilden die Grundlage

für die NoSQL Bewegung:

• CAP Theorem (2000 von Eric Brewer)

• MapReduce (2004 von Google)http://research.google.com/archive/mapreduce.html

• BigTable (2006 von Google)http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/de//archi

ve/bigtable-osdi06.pdf

• Dynamo (2007 von Amazon)http://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf

• Die folgenden Bereiche können von relationalen DBMS nur

schwer modelliert werden:

• Document Storage and Indexing

• Recursive Data and Graphs (Netzwerke)

• Time Series Data

Date

norientiert

e S

yste

manaly

se –

NoS

QL

Entstehungsgeschichte

http://www.benstopford.com/2012/06/30/thoughts-on-big-data-technologies-part-1/

Date

norientiert

e S

yste

manaly

se –

NoS

QL

12

Wer verwendet NoSQL?

Date

norientiert

e S

yste

manaly

se –

NoS

QL

13

NoSQL?

Jeder NoSQL Ansatz versucht einige der Unzulänglichkeiten von

relationalen Datenbanken zu lösen:

• horizontal scalability

• read/write performance

• schema limitations

• difficult query patterns

• parallel data processing

• etc.

Date

norientiert

e S

yste

manaly

se –

NoS

QL

NoSQL Features

Gewaltige read/write Performance

Normalerweise mit schnellen key-value Zugriff

High Availability

Daten werden auf mehreren Nodes gespeichert

Partitioning and Sharding

Fehlertolerant

Shardingkonzept in Riak:

http://docs.basho.com/riak/latest/references/appendices/concepts/

Date

norientiert

e S

yste

manaly

se –

NoS

QL

NoSQL Features

Unterstützung riesiger Datenmengen

leichte Skalierbarkeit (horizontal scaling). Wenn die

Kapazitäten knapp werden, kann man mit minimalen Aufwand

weiter Daten-Nodes hinzufügen.

Parallel Computing

Extrem performant! MapReduce Ansatz

Semi-structured and schemaless

mit JSON/XML lassen sich Daten semistrukturiert abbilden

in Key-Value Stores lassen sich alle Arten von Objekten

ablegen

Normalerweise kein fixes Schema

Auch keine Datentypen

Date

norientiert

e S

yste

manaly

se –

NoS

QL

NoSQL Features

Leichte Anwendungsentwicklung

Oft moderne Web-API mittels RESTful Services

Setzen auf bekannte Technologien: z.B: Javascript, HTTP,

XML, JSON

Leichte Wartbarkeit und Administration

Minimale Administration und automatisierter Betrieb haben

hohen Stellenwert bei der Entwicklung

Open-Source

Viele Lösungen sind open-source und haben eine aktive

Community.

Duales Lizensierungsmodell

Bei vielen Lösungen gibt es sowohl eine freie Variante als

auch eine mit kommerziellen Support.

Date

norientiert

e S

yste

manaly

se –

NoS

QL

Nachteile von NoSQL

Auf was muss man verzichten?

Joins

Group By

Order By

Indexes

ACID transactions

Complex relationships

Powerful and standard query language (SQL)

Maturity (Reifegrad)

Einige NoSQL Ansätze bieten einige (aber nicht alle) dieser Features.

http://blog.chariotsolutions.com/2010/01/why-you-need-nosql-in-your-toolbox.html

Date

norientiert

e S

yste

manaly

se –

NoS

QL

CAP Theorem

Das CAP Theorem wurde im Jahr 2000 von Eric Brewer formuliert:

“It is impossible for a distributed computer system to

simultaneously provide all three of the following guarantees:

• Consistency (all nodes see the same data at the same time)

• Availability (a guarantee that every request receives a

response about whether it was successful or failed)

• Partition tolerance (the system continues to operate despite

arbitrary message loss or failure of part of the system)”

Date

norientiert

e S

yste

manaly

se –

NoS

QL

19

CAP-Theorem – Two out of three

• Um hoch zu skalieren muss man Partitionieren man muss

zwischen Konsistenz und Verfügbarkeit wählen

Date

norientiert

e S

yste

manaly

se –

NoS

QL

20

BASE Consistency Model

http://www.ivanomalavolta.com/diving-into-nosql/

Date

norientiert

e S

yste

manaly

se –

NoS

QL

21

MapReduce

Ein von Google entwickeltes Programmiermodell um

Berechnungen über riesige Datenmengen über Clusternodes

verteilt parallel durchzuführen.

Dabei werden Probleme zur Problemlösung in zwei Teile geteilt:

• Map

Der erste Schritt des MapReduce-Verfahrens ist das Mapping.

Dabei werden alle in Frage kommenden Datensätze an eine

Mapping-Funktion übergeben, welche dann entscheidet, was

mit diesem Datensatz geschehen soll. Die Ergebnisse solch

eines Mapping-Vorgangs landen in einem Zwischenspeicher.

• Reduce

Mit einem anschließenden Reduce-Schritt können die

Ergebnisse gruppiert werden. Reduce gibt nur einen Datensatz

als Ergebnis zurück (es reduziert die Eingabemenge auf ein

Ergebnis)

http://research.google.com/archive/mapreduce.html

Date

norientiert

e S

yste

manaly

se –

NoS

QL

22

Einige NoSQL Datenbanklösungen

Date

norientiert

e S

yste

manaly

se –

NoS

QL

23

NoSQL – Einteilung in Quadranten

http://graphdatabases.com/

Date

norientiert

e S

yste

manaly

se –

NoS

QL

24

Einordnung nach CAP

http://t3n.de/news/visual-guide-nosql-systems-269025/

Date

norientiert

e S

yste

manaly

se –

NoS

QL

25

Key-Value Stores

• Der Fokus liegt auf Skalierbarkeit

entworfen für extrem hohe Lasten

• Es werden Collections von Key-Value Paaren gespeichert

vergleichbar mit Maps oder assoziativen Array in klassischen

Programmiersprachen.

• KEY=string value

• VALUE=irgendeine Art von Element (Strings, XML, JSON, mp3-

Dateien)

• Key Namespaces werden verwendet um Kollisionen beim Key

zu vermeiden.

Date

norientiert

e S

yste

manaly

se –

NoS

QL

26

Key-Value Stores

Vorteile

• leicht zu verwenden

• extrem gute Performance

• keine Notwendigkeit Indizes zu pflegen

• Daten horizontal verteilbar

Nachteile

• keine komplexen Abfragen möglich (kein SQL)

• keine Transaktionen

• Viele Datenstrukturen können nicht so leicht als Key-Value Pairs

modelliert werden.

• Keys müssen in den Arbeitsspeicher passen

Date

norientiert

e S

yste

manaly

se –

NoS

QL

27

Key-Value Stores

Einige Lösungen

• Redis

• Dynamo

• MemcacheDB

Anwendungsgebiete

• Aktienkurse

• Real-Time Data Collection

• Real-Time Communication

• User Session Storage

• Datencache für Datenbanken

Date

norientiert

e S

yste

manaly

se –

NoS

QL

28

Column-oriented Stores

• Liegen zwischen relationalen DBMS und Key-Value Stores.

• Sind nach dem BigTable paper von Google modelliert:

The data model is based on a sparsely populated table whose

rows can contain arbitrary columns, the keys for which provide

natural indexing.

• Im Gegensatz zu relationalen Datenbanken, werden die Daten

der Spalten beieinander gespeichert und nicht die von Zeilen.

• Jede Zeile kann eine unter-

schiedliche Menge von

Spalten haben

(Keine Storage Kosten für

NULL Werte)

Date

norientiert

e S

yste

manaly

se –

NoS

QL

29

Column-oriented Stores

Vorteile

• leicht Tasks zu verteilen

• Zur Lösung von „Big Data“ Problemen

• High Availability

• Garbage Collection für expired data

Nachteile

• Denormalisierung der Daten nötig

• Einfügevorgänge sind resourcenaufwändig

• Die benötigten Abfragen müssen frühzeitig in der Planung

berücksichtigt werden.

Date

norientiert

e S

yste

manaly

se –

NoS

QL

30

Column-oriented Stores

Einige Lösungen

• HBase

• BigTable

• Cassandra

Anwendungsgebiete

• Suchmaschinen

• Logging

• Analysing Log Data

• Wenn man riesige zwei-dimensionale Tabellen (ohne Join) lesen

muss.

• Viele Lösungen bieten Versionierung an

• In Cassandra ist das Schreiben schneller als Werte zu lesen

Date

norientiert

e S

yste

manaly

se –

NoS

QL

31

Document Stores

• Übermenge zu den Key-Value Stores. Man kann auch innerhalb

des VALUE Teils Abfragen machen (nicht nur im Key).

Der Dokument-Teil ist strukturiert.

• Dokumente kann man sich als Tupel mit einer beliebigen

Anzahl von Felder vorstellen (JSON)

• Dokumente können

verschachtelte Struk-

turen beinhalten

• Dokumente sind auch

oft versioniert

Date

norientiert

e S

yste

manaly

se –

NoS

QL

32

Document Stores

Vorteile

• Variable Daten (in Bezug auf die Struktur) speicherbar

• Object-orientierter Ansatz

• Funktioniert gut mit denormalisierten Daten

Nachteile

• Schwierig komplexe Abfragen zu machen

• Keine Joins zwischen den Dokumenten möglich

• Daten müssen strukturiert sein

Date

norientiert

e S

yste

manaly

se –

NoS

QL

33

Document Stores

Einige Lösungen

• MongoDB bzw. CouchDB für JSON Daten

• BaseX für XML Daten

• Riak für alle möglichen Daten

Anwendungsgebiete

• Wenn man im Voraus noch nicht weiß, wie die Daten

ausschauen werden bzw.

• wenn zu erwarten ist, dass immer wieder neue Datenfelder

hinzukommen.

• Für vordefinierte Reports über akkumulierte Daten, die sich nur

gelegentlich ändern.

• Anwendungsgebiete, bei denen Versionierung wichtig ist.

Date

norientiert

e S

yste

manaly

se –

NoS

QL

34

Graph Databases

• Fokussiert auf die Modellierung von Datenstrukturen und deren

Beziehungen

• Von der Graphentheorie der Mathematik inspiriert.

• Als Datenmodell wird der Property Graph verwendet:

• Entities sind Knoten

• Beziehungen sind die Kanten zwischen den Knoten

• Key-Value Pairs können sowohl bei Knoten als auch bei

Kanten gespeichert werden.

• Graph Datenbanken beeindrucken besonders bei Daten, die viele

Verbindungen untereinander aufweisen. (Relationale Datenbanken können Graphen modellieren, aber jede

Kante benötigt einen kostspieligen Join)

Date

norientiert

e S

yste

manaly

se –

NoS

QL

35

Property Graph - Beispiel

http://blog.neo4j.org/2010/02/top-10-ways-to-get-to-know-neo4j.html

Date

norientiert

e S

yste

manaly

se –

NoS

QL

36

Graph Databases

Vorteile

• Leichte Modellierung da Whiteboard friendly (alles was man auf

eine Tafel zeichnen kann, kann man auch so umsetzen)

• Das Traversieren zwischen Knoten entlang der Kanten ist extrem

schnell. Für die Abfragen an Graphen können Graphen-Algorith-

men verwendet werden (z.B.: Dijkstra für den kürzesten Weg)

• Passt gut zu objekt-orientierten Ansätzen

• Neo4J ist ACID-compliant

Nachteile

• Nicht horizontal skalierbar, da die Daten nicht partitioniert werden

können.

• Keine Joins (dafür jedoch traversieren)

• Daten müssen strukturiert sein

Date

norientiert

e S

yste

manaly

se –

NoS

QL

37

Graph Databases

Einige Lösungen

• Neo4J

• OrientDB

• AllegroGraph

Anwendungsgebiete

• Soziale Netzwerke

• Recommendation Engines

• Geographische Daten

• Transportnetzwerke

• Netzwerktopologien

• Berechtigungssysteme (verschachtelte Gruppen)

Date

norientiert

e S

yste

manaly

se –

NoS

QL

38

Einige Open Source Lösungen

• Redis – http://code.google.com/p/redis (Key-Value)

• MemcacheDB - http://memcachedb.org/ (Key-Value)

• Hbase – http://hbase.apache.org (Column-oriented)

• Cassandra – http://cassandra.apache.org (Column-oriented)

• Riak – http://www.basho.com (Key-Value bzw. Document)

• MongoDB – http://www.mongodb.org (Document)

• CouchDB - http://couchdb.apache.org (Document) AP

• Couchbase – http://www.couchbase.com (Document) CP

• Neo4J – http://neo4j.org (Graph)

• OrientDB – http://www.orientdb.org (Graph)

• FlockDB – http://github.com/twitter/flockdb (distributed Graph)

Date

norientiert

e S

yste

manaly

se –

NoS

QL

Datenbankfeatures im Vergleich

Date

norientiert

e S

yste

manaly

se –

NoS

QL

• Es geht um „Big-Data“ Probleme

• SKALIERBARKEIT (scale out statt scale up) aber meistens auf

Kosten der Konsistenz

• NoSQL ist keine eierlegende Wollmilchsau

NoSQL ≠

• Der neue Trend ist Polyglot Persistence

Der kombinierte Einsatz von relationalen Datenbanksys-

temen und NoSQL Datenbanken

Zusammenfassung

VERTEILTE SUCHMASCHINENAnhang

Date

norientiert

e S

yste

manaly

se –

NoS

QL

• Die zwei bedeutendsten Open Source Projekte bei den verteilten

Suchmaschinen sind:

• Ihr Funktionsumfang ist ähnlich.

• Beide sind in Java programmiert und bauen auf der Java

Bibliothek Lucene auf.

• Das ältere Projekt ist Apache Solr, jedoch gewinnt elasticsearch

rasch an Bedeutung.

Suchmaschinen

Date

norientiert

e S

yste

manaly

se –

NoS

QL

Lucene ist eine in Java geschriebene Bibliothek zur Volltextsuche.

Lucene bietet:

• High Performance Indizierung von Dokumenten (150GB/Stunde)

• Mächtige und effiziente Suchalgorithmen:

– ranked searching - best results returned first

– many powerful query types: phrase queries, wildcard queries, proximity queries, range

queries and more

– fielded searching (e.g. title, author, contents)

– sorting by any field

– multiple-index searching with merged results

– allows simultaneous update and searching

– flexible faceting, highlighting, joins and result grouping

– fast, memory-efficient and typo-tolerant suggesters

– pluggable ranking models

– configurable storage engine (codecs)

Apache Lucene

Date

norientiert

e S

yste

manaly

se –

NoS

QL

„Solr is a standalone enterprise search server with a REST-like API“:

Dokumente können in Form von XML, JSON, CSV oder binär über

HTTP importiert (indiziert) werden. Abgefragt wird über HTTP GET

und man erhält XML, JSON, CSV oder binäre Ergebnisse.

Eigenschaften:

• Advanced Full-Text Search Capabilities (basiert auf Lucene)

• Optimiert für High Volume Web Traffic

• Standards Based Open Interfaces - XML, JSON and HTTP

• Linearly scalable, auto index replication, auto failover and

recovery

• Near Real-time indexing

Apache Solr

Date

norientiert

e S

yste

manaly

se –

NoS

QL

• Elasticsearch is a distributed, RESTful, free/open source

search server based on Lucene.

• Eigenschaften:

• Fulltext Suchmaschine

• Optimiert für Real time data indexing and analytics

• Linier skalierbar (Cluster ist verteilt High Availability)

• Mandantenfähigkeit

• Dokumentenorientiert (JSON documents)

• Schema-Free (im Gegensatz zu Solr ist nicht zwingend ein

Mapping File erforderlich)

• RESTful API

Elasticsearch

Date

norientiert

e S

yste

manaly

se –

NoS

QL

Übungen

Nun zu den praktischen Übungsbeispielen…

Date

norientiert

e S

yste

manaly

se –

NoS

QL

47

ENDE