NoSQL Datenbanken
LV Datenorientierte Systemanalyse, WS 2014/15
Dr. Walter Ebner, <[email protected]>
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