NoSQL – Please! - Bildungsportal Sachsen

A Database Administrator walks into a NoSQL bar, but turns and leaves
because he cannot find a table.“ 
NoSQL – Please!
Wie Web2.0, Big Data und die Cloud neue Datenbanksysteme erfordern
und hervorbringen.
Prof. Dr. Frank Schönefeld, Geschäftsleitung,
T-Systems Multimedia Solutions GmbH
Prolog
CAP-Theorem
NoSQL Datenmodelle
Fazit
Facebook trapped in MySQL, fate worse than death‘.
„The only way out is … bite the bullet und rewrite everything.“
(Facebook runs approx. 4000 MySQL Server instances
and > 1000 memcaches.)
Quelle: http://gigaom.com/cloud/facebook-trapped-in-mysql-fate-worse-than-death/
Michael Stonebraker
„800M active monthly users, 500M active daily users; 350M
mobile users; 7M apps and web sites integrated via platform;
60M queries per second; 4M row changes per second”
Quelle: http://blogs.oracle.com/MySQL/entry/facebook_tech_talk_mysql_at
Domas Mituzas
(Facebook database performance team)
– NoSQL – Please –
Prof. Dr. Frank Schönefeld/ T-Systems Multimedia Solutions GmbH
20. Januar 2012
2
Prolog
CAP-Theorem
NoSQL Datenmodelle
Fazit
…und dennoch: NoSQL greift um sich – auch in Facebook.
NoSQL: Bedeutungswandel des Begriffs von NoSQL (API) zu Not only SQL.
Amazon setzt auf Dynamo, ein
verteiltes Dateisystem (Ring mit
Consistent Hashing) zur
Speicherung von Key/ Value Paaren.
Google verwendet Big Table
(eine dreidimensionale,
dünnbesetzte KeyValue Map)
für Google Earth, Maps,
Analytics, Orkut.
Facebook nutzt neben MySQL auch die
HBase für die Verwaltung ihrer Messages als
auch die kontextsensitive Ad-Verwaltung und
Einspielung. HBase basiert auf Hadoop
Distributed File System und implementiert die
„Big Table“ Features für Hadoop.
Linkedin verwendet Voldemort
(Big Table x Dynamo Ansatz)
für spezielle Speicheranforderungen ihrer Profile.
– NoSQL – Please –
Twitter Nutzer produzieren ca. 4 PByte/a. Scribe
schreibt Logs zu Hadoop. Zur People Search
wird HBase verwendet.
Quelle: http://www.readwriteweb.com/cloud/2011/01/
how-twitter-uses-nosql.php
Prof. Dr. Frank Schönefeld/ T-Systems Multimedia Solutions GmbH
20. Januar 2012
3
Prolog
CAP-Theorem
NoSQL Datenmodelle
Fazit
Big Data – The Next Big Thing.
Ist das das Web 3.0?
Quelle: http://www.go-gulf.com/blog/60-seconds
– NoSQL – Please –
Prof. Dr. Frank Schönefeld/ T-Systems Multimedia Solutions GmbH
20. Januar 2012
4
Prolog
CAP-Theorem
NoSQL Datenmodelle
Fazit
Big Data – The Next Big Thing?
Wir betreten die ExaByte Ära (1 ExaByte = 1.152.921.504.606.846.976 oder 260 = 1018 Bytes)
A decade of digital universe growth
7910
Exabytes
1227
130
2005
2010
2015
– NoSQL – Please –
Prof. Dr. Frank Schönefeld/ T-Systems Multimedia Solutions GmbH
20. Januar 2012
5
Prolog
CAP-Theorem
NoSQL Datenmodelle
Fazit
Big Data – The Next Big Thing?
Wir betreten die ExaByte Ära (1 ExaByte = 1.152.921.504.606.846.976 oder 260 = 1018 Bytes)
A decade of digital universe growth
7910
Over the next decade, the number of servers (virtual
and physical) worldwide will grow by 10 times.
The amount of information managed by
enterprise datacenters will grow by 50 times.
Exabytes
The number of files the datacenter will have to deal with
will grow by 75 times at least.
1227
130
2005
Meanwhile, the number of IT professionals in the
2010
2015
world will grow by less than 1.5 times.
There were 5 exabytes of information created between the dawn of civilization through 2003, but that
much information is now created every 2 days, and the pace is increasing. (Eric Schmidt Google 2010)
Quelle: IDC Digital Universe 2011 http://germany.emc.com/leadership/programs/digital-universe.htm
– NoSQL – Please –
Prof. Dr. Frank Schönefeld/ T-Systems Multimedia Solutions GmbH
20. Januar 2012
6
Prolog
CAP-Theorem
NoSQL Datenmodelle
Fazit
Probleme und Limitationen von RDBMS.
Datenmodell: Die Welt ist keine Tabelle …
– NoSQL – Please –
Prof. Dr. Frank Schönefeld/ T-Systems Multimedia Solutions GmbH
20. Januar 2012
7
Prolog
CAP-Theorem
NoSQL Datenmodelle
Fazit
Probleme und Limitationen von RDBMS.
Datenmodell: Die Welt ist keine Tabelle …
– NoSQL – Please –
Skalierung: … und passt auch schlecht
in eine hinein… (Scale up vs. Scale out).
Prof. Dr. Frank Schönefeld/ T-Systems Multimedia Solutions GmbH
20. Januar 2012
8
Prolog
CAP-Theorem
NoSQL Datenmodelle
Fazit
Lösungsansätze von NoSQL:
Skalierung
Datenmodell
Consistency
Key/Value
Systeme
Datenmodell
Columm Family
Systeme
Map-Reduce
Algorithmus
Availability
Von Locks zu
MVCC
Von 2PC zu
PAXOS
Skalierung
Document
Stores
Graph
Datenbanken
Von AICD zu BASE
Von Master-Slave
zu Gossip
Partition
Tolerance
Sharding
Consistent
Hashing
– NoSQL – Please –
Prof. Dr. Frank Schönefeld/ T-Systems Multimedia Solutions GmbH
20. Januar 2012
9
Prolog
CAP-Theorem
NoSQL Datenmodelle
Fazit
Gute Links und Literatur:
 Edlich et.al: NoSQL. Einstieg in die Welt Nichtrelationaler Web 2.0 DB. Hanser 2011.
 Marc Boeker: MongoDB. Sag ja zu NoSQL. entwickler.press 2010.
 http://wikis.gm.fh-koeln.de/wiki_db/Category/NoSQL Wiki der FH Köln/Campus
Gummersbach zu NoSQL
 http://nosql-database.org/ Sammlung von Infos zu NoSQL DB.
 http://dbs.uni-leipzig.de/buecher/mrdbs/index.html Fundierter Lehrstoff zu
Mehrrechner-DB Systemen.
 http://guide.couchdb.org/editions/1/de/index.html CouchDB Einführung
– NoSQL – Please –
Prof. Dr. Frank Schönefeld/ T-Systems Multimedia Solutions GmbH
20. Januar 2012
10
Prolog
CAP-Theorem
NoSQL Datenmodelle
Fazit
Definition von NoSQL (Arbeitsversion).
NoSQL:
Nichtrelationale (schemafreie) verteilbare Datenverwaltungs- und Speicherungssysteme, die den Skalierungsanforderungen globaler 24/7-Web-Anwendungen
durch modifizierte Konsistenzmodelle gerecht werden und über einfache APIs
(CRUD, REST) angesprochen werden.
– NoSQL – Please –
Prof. Dr. Frank Schönefeld/ T-Systems Multimedia Solutions GmbH
20. Januar 2012
11
Prolog
CAP-Theorem
NoSQL Datenmodelle
Fazit
Historie der Datenbanksysteme.
Bibliothek von Alexandria.
Ca. 300 vor Christus bis ca. 391 nach Christus
– NoSQL – Please –
Prof. Dr. Frank Schönefeld/ T-Systems Multimedia Solutions GmbH
20. Januar 2012
12
Prolog
CAP-Theorem
NoSQL Datenmodelle
Fazit
Historie der Datenbanksysteme.
Datenbankenprodukte und Generationen.
Hierarchische DBS
Netzwerk DBS
OO DBS
Dynamo
NoSQL DB
Relationale DBS
ORM
Poet
BigTable
Objectstore
UDS Codasyl DB
System/R
IMS
1960
1970
1980
– NoSQL – Please –
mySQL
Oracle 1977
IBM DB2
MS SQL Server
1990
2000
Prof. Dr. Frank Schönefeld/ T-Systems Multimedia Solutions GmbH
2004
2012
20. Januar 2012
13
Agenda.
Prolog
Teil 1
CAP-Theorem
Teil 2
NoSQL-Datenmodelle
Teil 3
NoSQL-Datenmodelle – Key/Value Stores
Teil 3a
NoSQL-Datenmodelle – Columm-Family Systeme
Teil 3b
NoSQL-Datenmodelle – Document Store
Teil 3c
NoSQL-Datenmodelle – Graph-Datenbanken
Teil 3d
Fazit
– NoSQL
Einsatz von Webmedien & Technologien in Unternehmen
2.0 Please –
Teil 4
- Dr. Frank Schönefeld -
Prof. Dr. Frank Schönefeld/ T-Systems Multimedia Solutions GmbH
20. Januar 2012
14
16.06.2011
14
Prolog
Das CAP-Theorem
NoSQL-Datenmodelle
Fazit
Das CAP Theorem.
Consistency. Availability. Partition Tolerance.
Consistency:
Availability:
Partition Tolerance:
In verteilten DB-Systemen müssen bei Änderungen an Daten auch deren
Replikate auf den aktuellen Stand gebracht werden (wo liegen die
Replikate, was mache ich, wenn ein Replikatserver nicht erreichbar ist).
Verfügbarkeit von Daten innerhalb akzeptabler Antwortzeiten (oder
Schreibzeiten).
Ausfalltoleranz des Gesamtsystems bzgl. Knoten (Server) und
Verbindungen (Netzwerk, Latenz).
Brewers Vermutung von 2000, dass nur 2 der 3 Eigenschaften gemeinsam realisiert werden
können, wurde 2002 durch Gilbert und Lynch bewiesen.
– NoSQL – Please –
Prof. Dr. Frank Schönefeld/ T-Systems Multimedia Solutions GmbH
20. Januar 2012
15
Prolog
Das CAP-Theorem
NoSQL-Datenmodelle
Fazit
Das CAP Theorem.
Consensus protocols for HA consistency
Consistency
Availability
Enforced consistency
Paxos
Partition
Tolerance
Eventual consistency
Quelle: J. Chris Anderson/Jan Lehnardt/ Noah Slater: Couch DB – The Definitive Guide
– NoSQL – Please –
Prof. Dr. Frank Schönefeld/ T-Systems Multimedia Solutions GmbH
20. Januar 2012
16
Prolog
Das CAP-Theorem
NoSQL-Datenmodelle
Fazit
Lösungen für das Availability Problem.
Multiversion Concurrency Control – MVCC.
WTS
0
„Joseph“
„Joseph“
0
0
2
Write „Maria“= Ok, da (max(RTS)=2) < 4
0
„Joseph“
„Maria“
4
Read
2
4
WTS:
Write Time Stamp
RTS:
Read Time Stamp
Vorteil: keine Lesesperren
Read“Joseph“ = da (max(WTS)=0) < 4
T4
T3
RTS
Im Einsatz bei:
•
CouchDB
•
MySQL (mit InnoDB)
•
…
= Ok, liefert „Joseph“ da (max(WTS) < 3) = 0
Write „Jesus“  T3 wird abgebrochen, und neu gestartet, da 3 < max (RTS) = 4
– NoSQL – Please –
Prof. Dr. Frank Schönefeld/ T-Systems Multimedia Solutions GmbH
20. Januar 2012
17
Prolog
Das CAP-Theorem
NoSQL-Datenmodelle
Fazit
Lösungen für das Partition Tolerance Problem.
Consistent Hashing mit Hinted Handoff.
S1
S2
S5
Consistent Hashing:
Verfahren, um die Daten einem Knoten (S1-S5
zuzuweisen). Bei Ausfall eines Knotens, werden
diese Daten auf die anderen verteilt, ohne die
anderen Zuweisungen zu verändern.
Hinted Handoff:
Wenn 3 (allg. n) Replika gehalten werden und der
Master-Knoten ist nicht erreichbar, merkt sich der
1. Replikaknoten die Daten mit Vermerk und
versucht bei Wiederverfügbarkeit die Daten zu
verschieben.
S4
S3
Gossip:
Topologieinformationsaustausch ohne Master
Im Einsatz bei:
– NoSQL – Please –
•
Amazon Dynamo
•
weiteren distributierten Filesystemen (GFS,…)
•
…
Prof. Dr. Frank Schönefeld/ T-Systems Multimedia Solutions GmbH
20. Januar 2012
18
Prolog
Das CAP-Theorem
NoSQL-Datenmodelle
Fazit
Lösungen für das Partition Tolerance Problem.
Consistent Hashing mit Hinted Handoff.
S1
S2
S5
S4
Consistent Hashing:
Verfahren, um die Daten einem Knoten (S1-S5
zuzuweisen). Bei Ausfall eines Knotens, werden
diese Daten auf die anderen verteilt, ohne die
anderen Zuweisungen zu verändern.
Hinted Handoff:
Wenn 3 (allg. n) Replika gehalten werden und der
Master-Knoten ist nicht erreichbar, merkt sich der
1. Replikaknoten die Daten mit Vermerk und
versucht bei Wiederverfügbarkeit die Daten zu
verschieben.
X
S3
Gossip:
Topologieinformationsaustausch ohne Master
Im Einsatz bei:
X
Replikation
Ausfall
– NoSQL – Please –
•
Amazon Dynamo
•
weiteren distributierten Filesystemen (GFS,…)
•
…
Prof. Dr. Frank Schönefeld/ T-Systems Multimedia Solutions GmbH
20. Januar 2012
19
Prolog
Das CAP-Theorem
NoSQL-Datenmodelle
Fazit
Das CAP Theorem – Von ACID zu BASE. (Wortspiel!)
Eine Reise durch das (Dis-)Continuum der Konsistenz.
A tomicity:
Atomare Transaktionen – Ganz oder gar nicht.
C onsistency:
Die DB geht von einem konsistenten Zustand in einen anderen
konsistenten Zustand über.
(Auch: Alle Clients lesen den gleichen, konsistenten Zustand).
I solation:
Eine Transaktion hat den Eindruck, dass ihr die DB alleine gehört
(sie nicht durch andere Transaktionen beeinflusst wird).
D urability:
Das Ergebnis einer Transaktion wird unter allen Umständen verteidigt.
B asically available:
Mindestens eine Kopie (Replika) stellt den gültigen Zustand dar.
S oft State:
Alles fließt.
E ventually Consistent: Nach genügend langer Wartezeit, hat sich der konsistente Zustand
.
repliziert.
– NoSQL – Please –
Prof. Dr. Frank Schönefeld/ T-Systems Multimedia Solutions GmbH
20. Januar 2012
20
Prolog
Das CAP-Theorem
NoSQL Datenmodelle
Fazit
Key Value Stores.
Key Value Stores speichern Schlüssel und dazugehörige unstrukturierte oder strukturierte Werte.
Datenmodell: {< key, value>,…} oder
{< key, value, timestamp>,…}
Set oder Liste
key
key
value
value
value
Datenmanipulation: CRUD
 Beispiel MapReduce ff. Slides
key
 CQL – Cassandra Query Language
(SQL-like)
Name: Marie
 jedes DBS mit eigener Sprache,
kein Standard
Hash (Person)
Alter: 34
value
Vertreter:
Im Einsatz bei:
 Redis, Dynamo (eventually consistent)
 Dynamo
 BigTable, Voldemort, Cassandra
 Memcached (HS-orientierte DB)
 BigTable
– NoSQL – Please –
 Memcached
Prof. Dr. Frank Schönefeld/ T-Systems Multimedia Solutions GmbH
20. Januar 2012
21
Prolog
NoSQL Datenmodelle
Das CAP-Theorem
Fazit
Key Value Stores - MapReduce.
MapReduce – ein einfaches Programmiermodell für verteilte Datenverarbeitung
nach Saliya Ekanayake

(map
‘(
))
(

(reduce
A list of values mapped into another list of
values, which gets reduced into a single value
)
‘(
))
Classical Notion of MapReduce in Functional
Programming
Quelle: http://www.slideshare.net/esaliya/mapreduce-in-simple-terms
– NoSQL – Please –
Prof. Dr. Frank Schönefeld/ T-Systems Multimedia Solutions GmbH
20. Januar 2012
22
Prolog
NoSQL Datenmodelle
Das CAP-Theorem
Fazit
Key Value Stores - MapReduce.
MapReduce – ein einfaches Programmiermodell für verteilte
Datenverarbeitung nach Saliya Ekanayake – parallel Version
Each input to a map is a list of <key, value> pairs
(<a, > , <o, > , <p,
(<a’, > , <o’,
> , <p’,
> , …)
> , …)
Grouped by key
Each input to a reduce is a <key, value-list> (possibly a list of
these, depending on the grouping/hashing mechanism)
e.g. <a’, (
…)>
Reduced into a list of values
Quelle: http://www.slideshare.net/esaliya/mapreduce-in-simple-terms
– NoSQL – Please –
Prof. Dr. Frank Schönefeld/ T-Systems Multimedia Solutions GmbH
20. Januar 2012
23
Prolog
NoSQL Datenmodelle
Das CAP-Theorem
Key Value Stores - MapReduce.
MapReduce – ein einfaches Programmiermodell für verteilte
Datenverarbeitung nach Saliya Ekanayake – parallel Version
Fazit
A list of <key, value> pairs mapped into another list of
<key, value> pairs which gets grouped by the key and
reduced into a list of values
The idea of MapReduce in Data Intensive Computing
Each input to a map is a list of <key, value> pairs
(<a, > , <o, > , <p,
(<a’, > , <o’,
> , <p’,
> , …)
> , …)
Grouped by key
Each input to a reduce is a <key, value-list> (possibly a list of
these, depending on the grouping/hashing mechanism)
e.g. <a’, (
…)>
Reduced into a list of values
Quelle: http://www.slideshare.net/esaliya/mapreduce-in-simple-terms
– NoSQL – Please –
Prof. Dr. Frank Schönefeld/ T-Systems Multimedia Solutions GmbH
20. Januar 2012
24
Prolog
NoSQL Datenmodelle
Das CAP-Theorem
Fazit
Key Value Stores – MapReduce in Pseudocode.

Aufgabe: WordCount in Dokumenten oder WebPages; Input: Key:
document URL; Value: Document Content.
Map (String input_key, String input_value)
// input_key: document name
// input value: document content
for each word w in input_value:
Emit Intermediate (w, “1”);
Reduce (String key, Iterator intermediate_values):
// Key: a word, same for input and output
// intermediate_value: a list of counts
Int result = 0;
for each v in intermediate_value:
result += ParseInt (v);
Emit (AsString (result));
Quelle: http://www.slideshare.net/rantav/introduction-to-map-reduce
– NoSQL – Please –
Prof. Dr. Frank Schönefeld/ T-Systems Multimedia Solutions GmbH
20. Januar 2012
25
Prolog
NoSQL Datenmodelle
Das CAP-Theorem
Fazit
Key Value Stores – MapReduce Performance.

MR_Grep: Scan von 1 Terabytes in 100 sec
MR_Sort: Sort von 1 Terabyte 100 Byte Records in 14 min (10 Mrd. Sätze!!!)

Unter Einsatz von 1800 Rechnern (fault-tolerant)

Typische Anwendungen bei Google:
 Language Statistics (finde alle Wortgruppen die aus 5 Wörtern bestehen und
mindestens 4 mal vorkommen)
 Dokument-Info kombiniert mit Host-Infos (eine Art Join)
 Google production index

Quelle: http://www.slideshare.net/rantav/introduction-to-map-reduce
– NoSQL – Please –
Prof. Dr. Frank Schönefeld/ T-Systems Multimedia Solutions GmbH
20. Januar 2012
26
Prolog
NoSQL Datenmodelle
Das CAP-Theorem
Fazit
Column Family Systeme.
Column Family Systeme speichern Sätze spaltenorientiert oder als Super Columns.
Datenmodell: Column: Name, Daten, Timestamp
SuperColumn: Name, {Column1, Column2,…}
Domäne/Keyspace
key
key
Name: Joseph
Alter: 24
Name: Maria
Alter: 20
Item
Status: Single
Datenmanipulation: CRUD in Amazon
Simple DB:
•
Create Domain
•
PutAttribute(attribute_name, value)
•
Select target from domain_name
where expression;
ColumnFamily: <Key, Column1, Column2,…>
SuperColumnFamily: <Key, SuperColumn1, …>
Vertreter:
Im Einsatz bei:
•
Amazon Simple DB (eventually consistent)
•
Amazon Simple DB (AWS)
•
HBase, Hypertable
•
HBase
– NoSQL – Please –
Prof. Dr. Frank Schönefeld/ T-Systems Multimedia Solutions GmbH
20. Januar 2012
27
Prolog
NoSQL Datenmodelle
Das CAP-Theorem
Fazit
Document Stores.
Document Stores speichern Daten in Form von Dokumenten.
Datenmodell: …
Datenmanipulation: CRUD in MongoDB:
Domäne/Keyspace
key
Name: Joseph
Alter: 24
Name: Maria
Alter: 20
•
db.<collection>.<action>(<parameters>);
•
db.beisp.insert({name: „frank“, age: 49,
hobbies: [„volleyball“, „beach“, „DB“]});
•
action: find, save, update, remove
Item
Status: Single
MongoDB im Einsatz bei:
Vertreter:
•
MongoDB
•
FourSquare (für Geolocation)
•
CouchDB
•
bit.ly (Userhistory)
•
NY Times (Bildupload, Forms)
– NoSQL – Please –
Prof. Dr. Frank Schönefeld/ T-Systems Multimedia Solutions GmbH
20. Januar 2012
28
Prolog
NoSQL Datenmodelle
Das CAP-Theorem
Fazit
Graph Datenbanken.
Graph Datenbanken speichern Daten als Netzwerke verbundener Knoten.
Datenmodell:
Datenmanipulation:
CRUD in neo4j mit dem REST API:
Vertreter:
•
neo4j
•
Sones
•
…
•
POST /node {…data} --Knoten anlegen
•
GET /node/123
•
PUT /node/123/properties {…data}
•
DELETE /node/123
Im Einsatz bei:
•
– NoSQL – Please –
vorrangig für Geo-Informationssysteme
Prof. Dr. Frank Schönefeld/ T-Systems Multimedia Solutions GmbH
20. Januar 2012
29
Prolog
NoSQL Datenmodelle
Das CAP-Theorem
Fazit
Klassifikation von NoSQL-Datenbankensystemen.
Size
Key-Value Stores
Columm Family Stores
Document Databases
Graph Databases
Complexity
– NoSQL Please! –
Prof. Dr. Frank Schönefeld/ T-Systems Multimedia Solutions GmbH
20. Januar 2012
30
Prolog
NoSQL Datenmodelle
Das CAP-Theorem
Fazit
Klassifikation von NoSQL-Datenbankensystemen.
Size
Key-Value Stores
Columm Family Stores
Document Databases
Graph Databases
> 90 % of the use cases
Complexity
– NoSQL Please! –
Prof. Dr. Frank Schönefeld/ T-Systems Multimedia Solutions GmbH
20. Januar 2012
31
Prolog
NoSQL Datenmodelle
Das CAP-Theorem
Fazit
NoSQL: Nathan Hursts Entscheidungspyramide für NoSQL-Datenbanken.
Quelle:http://t3n.de/news/visual-guide-nosql-systems-269025/
– NoSQL Please! –
Prof. Dr. Frank Schönefeld/ T-Systems Multimedia Solutions GmbH
20. Januar 2012
32
Prolog
Das CAP-Theorem
NoSQL Datenmodelle
Fazit
Anwendungsfälle für NoSQL.
Nach J. Hammerbacher (Cloudera).
1. Risikoanalysen (Kreditkartenbetrug)
2. Kundenanalysen (Kündigungsgründe)
3. Empfehlungssysteme
4. Ad Targeting
5. POS Transaction Analysen (Echtzeit)
6. Netzwerkanalysen
7. Bedrohungsanalysen
8. Überwachungsdatenanalyse
9. Suchqualitätsanalysen
10. Genom Datenanalysen
– NoSQL – Please –
Prof. Dr. Frank Schönefeld/ T-Systems Multimedia Solutions GmbH
20. Januar 2012
33
Prolog
Das CAP-Theorem
NoSQL Datenmodelle
Fazit
Fazit SQL vs. NoSQL.
Am Beispiel von MySQL.
•
•
•
•
•
•
•
•
•
•
•
•
MySQL
Datenmodell: spaltenorientiert
Untereinheit der DB: Tabelle
Primärschlüssel: Primary Key
Transaktionen: Ja
Stored Procedures: Ja
Trigger: Ja
Cursor: Ja
Views: Ja
Volltextsuche: Ja
Replikation: Master/Slave
Binärdaten: Ja, BLOB
Map/Reduce: Nein
•
•
•
•
•
•
•
•
•
•
•
•
NoSQL
Datenmodell: KeyValue, Dokument, Graph, …
Untereinheit der DB: Collection, ….
Primärschlüssel: Object ID, Key, …
Transaktionen: Meistens nein, …
Stored Procedures: nein
Trigger: nein
Cursor: Häufig ja
Views: selten
Volltextsuche: Nicht immer
Replikation: ja, verschiedene Verfahren
Binärdaten: Ja
Map/Reduce: Ja
Nach Marc Boeker. MongoDB.
– NoSQL – Please –
Prof. Dr. Frank Schönefeld/ T-Systems Multimedia Solutions GmbH
20. Januar 2012
34
Prolog
Das CAP-Theorem
NoSQL Datenmodelle
Fazit
Fazit SQL vs. NoSQL.
Quelle: http://geekandpoke.typepad.com/geekandpoke/2011/01/nosql.html
– NoSQL – Please –
Prof. Dr. Frank Schönefeld/ T-Systems Multimedia Solutions GmbH
20. Januar 2012
35
Prolog
Das CAP-Theorem
NoSQL Datenmodelle
Fazit
Fazit.
Web 2.0, Big Data und die Cloud haben völlig neue Typen von Datenbanken benötigt
und hervorgebracht.
Es ist wieder spannend, Datenbanker zu sein!!!
NoSQL (Not only SQL) ist z.Zt. ein dynamisches, inhomogenes noch nicht abgeschlossenes Wissensgebiet. Der Einsatz von NoSQL im “normalen” Unternehmensumfeld
kann bereits heute Sinn machen.
Deshalb in (vor) die Entwurfsphase von DB, die NoSQL-Betrachtung einbeziehen.
– NoSQL Please! –
Prof. Dr. Frank Schönefeld/ T-Systems Multimedia Solutions GmbH
20. Januar 2012
36
Danke.
– NoSQL Please –
Prof. Dr. Frank Schönefeld/ T-Systems Multimedia Solutions GmbH
20. Januar 2012
37
Dr. Frank Schönefeld
Prokurist, Geschäftsleitung
T-Systems Multimedia Solutions
E-Mail:
[email protected]
Web:
www.t-systems-mms.de
Blog:
www.rules-of-the-game.de
Twitter:
twitter.com/frank_open
Bookmarks: delicious.com/frank_open ../PraxisleitfadenE20
Xing:
www.xing.com/profile/Frank_Schoenefeld2
LinkedIn: www.linkedin.com/Frank Schoenefeld
– NoSQL Please –
T-Systems Multimedia Solutions
Riesaer Straße 5
D-01129 Dresden
Telefon: +49 351 2820 - 0
Telefax: +49 351 2820 - 5115
E-Mail: [email protected]
www.t-systems-mms.com
www.dresdner-zukunftsforum.de
www.webolution-das-buch.de
MMS @ Xing
MMS @ Twitter
MMS @ Facebook
MMS @ Flickr
MMS @ Slideshare
MMS @ Youtube
Prof. Dr. Frank Schönefeld/ T-Systems Multimedia Solutions GmbH
20. Januar 2012
38