SlideShare ist ein Scribd-Unternehmen logo
NoSQL
Hintergründe und Anwendungen




Andreas Winschu                1
Inhalt

 1. Motivation

 2. RDBMS

 3. CAP Theorem

 4. NoSQL

 5. NoSql Overview

 6. NoSQl Praxis

 7. Zusammenfassung und Ausblick



                                   2
1.Motivation
Datenbanken



  • Permanente Sicherung großer Datenmengen

  • Effizientes Wiederfinden der Daten (Indexierung)

  • Analytische Untersuchungen

  • Gleichzeitiges Arbeiten von mehreren Benutzern

  • Schutz vor unautorisiertem Zugriff




                                                       3
1.Motivation
Geschichte

       60er Jahre
       Hierarchisch/Netzwerkartig
       • Zeigerstrukturen zwischen Daten
       • navigierende Anfragesprachen



       70er Jahre
            Relational
       •          Daten in Tabellenstruktur
       •          standardisierte Datenbanksprache(SQL)




                                                          4
1.Motivation
Geschichte

       60er Jahre
       Hierarchisch/Netzwerkartig
       • Zeigerstrukturen zwischen Daten
       • navigierende Anfragesprachen



       70er Jahre
            Relational
       •          Daten in Tabellenstruktur
       •          standardisierte Datenbanksprache(SQL)




                                                          5
1.Motivation

 • Relationale Datenbanken sind 40 Jahre alt

 • One Size fitts all
   auf alle Probleme angewendet

 • Applikationen benutzen ein anderes Datenmodell

 • Einige Applikationen haben weniger strikte
   Anforderungen an Daten




                                                    6
2.RDBMS
   Bücher




   BücherNutzer




       Nutzer



                  7
2.RDBMS
Scaling

 „Enterprise“ Solutions




 + Keine Applikationslogik erforderlich

 - Teure „Enterpriselösungen“
 - Aufwendige JOIN Algorithmen,
    Eignung nur bei „Einfachen JOINs“.
                                          8
2.RDBMS
Master Slave Replication




+ Vergleichbar weniger Administration
+ In den Basispacketen vorhanden

- Keine Datenpartionierung
- Schreibzugriffe skalieren nicht

                                        9
2.RDBMS
Functional Partitioning (Sharding)




- Immens hohe Verteilungslogik auf der Applikationsebene

- Erfordert abgetrennte Datenbereiche

- Denormalisierung
  Verwendung des RDBMS gegen eigentliches Funktionsdesign
                                                            10
2.RDBMS
Transaktionen
Atomicity (Atomarität):
Transaktion wird entweder ganz oder gar nicht
ausgeführt

Consistency (Konsistenz / Integritätserhaltung):
Datenbank ist vor Beginn und nach Beendigung einer
Transaktion jeweils in einem konsistenten Zustand

Isolation (Isolation):
Nutzer, der mit einer Datenbank arbeitet, sollte den
Eindruck haben, dass er mit dieser Datenbank alleine
Arbeitet

Durability (Dauerhaftigkeit / Persistenz):
nach erfolgreichem Abschluss einer Transaktion muss
das Ergebnis dieser Transaktion „dauerhaft“ in der
Datenbank gespeichert werden


                                                       11
2.RDBMS
• Garantie der ACID Eigenschaften wird
  komplex

• Atomicity fordert Verteiltes Commit
  Protokoll (e.g. 2PC)
  Alle Nodes müssen sich einig sein

• Isolation fordert Erhaltung der Locks
  für die gesamte Dauer des Protokolls
  die gesamte Transaktion darf nicht gestört
  werden durch nebenläufige Transaktionen


  Leichtgewichtige Transaktionen, große Netzwerk Roundtrips =>

  •   Lockerhaltung länger als Arbeitszeit

  •   „Skyrocketing Lock Competitions“

  •   Schwund des Transaktionsdurchsatzes
                                                                 12
2.RDBMS
Features:
 •   Festes Datenmodell
 •   Redundanzvermeidung durch Fremdschlüsselbeziehungen
 •   Starke Konsistenz
 •   Transaktionsmodell Garantien

Eignung:
 •   Finanzprozesse
 •   ERP Systeme
 •   Systeme mit wenigen Benutzern



Schwierigkeiten:
 •   Horizontale Scalierung
 •   JOIN‘s kosten CPU Power
 •   Datenmodel passt nicht immer ins relationale Schema


                      One Size does NOT fit all!
                                                           13
3.CAP Theorem
Erik Brewer überlegt 1997 ein Gegenmodel zu ACID
BASE – Basically Available, Soft-state, Eventually consistent


   ACID                                      BASE

   •   Starke Konsistenz                     •   Schwache Konsistenz
                                                  – altes data OK
   •   Isolation                             •   Availability zuerst
                                     vs
   •   Fokus auf Commit                      •   Versuch dein Bestes

   •   Geschachtelte                         •   Aggresiv (optimisticsch)
       Transaktionen
                                             •   Leichter!
   •   Konservativ (pessimistisch)
                                             •   Schneller
   •   Schwierige Umsetzung
                                             •   Einfacher Umsetzbar
   •   (e.g. Schema,
       Normalesierung, JOIN‘s)
                                                                            14
3.CAP Theorem
                            Erik Brewer stützt notwendigkeit von
                            BASE durch ein Theorem

                            Linear Consitency
                            Totale Ordnung aller Operationen

                            Availibility
                            Jeder Anfrage an einen intakten Node wir
                            bearbeitet

                            Partitiotolerence
                            Fehler bei der Kommunikation im verteilten
                            System werden toleriert




  Behauptung: nur 2 der 3 Features gleichzeitig erfüllbar
            Bewiesen durch Gilbert und Lynch


                                                                  15
3.CAP Theorem
AP Class




Es gilt:
 a) Das System möchte Partiontoleranz erfüllen
 b) Es treten Netzwekfehler auf.

Wenn:
Das System beantwortet zu diesem Zeitpunkt alle Anfragen (Availibility)

Dann:
Die Antworten können nicht konsistent sein, da keine Einigkeit herscht
                                                                          16
3.CAP Theorem
AP Class
Eventual Consistency
Wenn keine neuen Updates auftreten liefert jeder Zugriff eventuell den aktuellen Wert

•   Keine Locks
•   Local Consistency
•   „Read your own Writes“
•   Multi Version Concurency Control (MVCC)




                                                                                        17
3.CAP Theorem




Es gilt:
 a) Das System möchte Partiontoleranz erfüllen
 b) Es treten Netzwekfehler auf.

Wenn:
Alle Benutzer des Systems erhalten korrekte und gleiche Daten

Dann:
Das System beantwortet Anfragen solange nicht bis es sich synchronisiert
hat                                                                        18
3.CAP Theorem
CP Class
                            R1
           W3
                A   B   C




           W2               R2
Master          A   B   C




           W1               R3
                A   B   C




                                 19
4.NoSQL
•   Begriff als erstes 1998 durch Carlo Strozzi verwendet
     • relationale Datnabank, die explizit auf SQL verzichtet
     • No to SQL


• 2009 durch Johan Oskarsson aufgegriffen
     •   Last.fm Tagung
     •   Techniken für nicht-relationale verteilte Datenbanken
     •   Keine neue Technologie
     •   Aufleben bekannter BASE Konzepte gemäß aktuellen
         Anfordrerungen


• NoSQL Bewegung ensteht
     • NoSQL = Not only SQL




                                                                 20
4.NoSQL
•   Nicht relational

•   Schemafrei

•   Einfache API‘s
    (meistens)Verizicht auf SQL, JavaScript, JSON, Views, REST

•   Horizontal scalierbar (Shards)

•   Map/Reduce Paradigma zu parallelen Verarbeitung

•   Replikation zwischen den Schards

•   Partition tolerant


    AP                                 CP
    Eventual Consistency               Write/Read Availabillity Balance
    MVCC                               Update in Place
                                                                      21
4.NoSQL -              Overview

          Key/Value Store

  • einfache Datenhalter

  • Ein Key, Ein Value, Keine Duplikate

  • Sehr Schnell

  • Verteilter Hash

  • Die Datenbank versteht die Values nicht
    BLOB

  • Voldemort, Redis, Tokio Cabinet


                                              22
5.NoSQL -            Overview

           Key/Value Store

     key                     value


   „6a9b85fd1061e“     =>    #name:#$$!!^^
                             #firstname:#$$!!^
                             #birthday:#$$!!^^
                             #adress:#$$!!^^




                                                 23
5.NoSQL -              Overview

          Column-based Store


  • Spalten als einfachste Datenhalter

  • Verteilte, multidimensonale, sortierte Map

  • GoogleBigTable Clones

  • GoogleBigTable, Cassandra (Facebook), Apache Hbase

  • Angeblich besser bei Analytical Processing,
    Datawarehouse




                                                         24
4.NoSQL -                            Overview
                           Column Store
           rowID




column family      person   person     person           person      person
   title           name     firstname birthday          adress      adress
                   11       12         34               10          14
   time




   value           „Doe“     „John“   „12.Dec.19085“   „X-Street“        „Y-Street“


                                                                                      25
5.NoSQL -              Overview

          Document Stores

  • Key Value Store, aber das Value ist strukturiert
    und von der DB interpretierbar (Document)

  • Datenanfragen nicht nur über Keys, sondern über alle
    Documentfelder

  • Indexes über einzelne Documentfelder

  • CouchDB, MongoDB




                                                           26
5.NoSQL -                Overview
Document Store              Document
keys
                             #Person{
                               name: "Doe",
 „Person_23 “
                               firstname: "John",
                               birthday: "12.Dec.1985",
                               adresses: [

                                 #Adress{
                                  street: "..." ,
          „Adress_47 “            city: "...",
                                  ....
                                  type:"delivery",
                                 }

                                 #Adress{
          „Adress_11 “              street: "...",
                                    city: "...",

                                         type: "standard",
                                     }
                                 ]
                             }



                                                             27
6.NoSQL Praxis
Schema Design
   Relational




                 28
6.NoSQL Praxis
Schema Design
   Denormalisiert(„NoSQL Way“)




   Embed bevorzugt über Reference
                                    29
6.NoSQL Praxis
Queries
 REST
 http://127.0.0.1:5984/mydb/_design/blog
 GET, PUT, POST, DELETE

 API

   db.blogs.find({„author" : "joe"});
   db.blogs.find( $where: function() { return this.author == “joe” );

   • Driver für fast alle Programmiersprachen

   • Query Main und Embeded Objects

   • Markups ($all, $or, $exists, $size, <, >, …)

   • Embeded Javascipt
     function (){return …}
                                                                        30
6.NoSQL Praxis
Map/Reduce




                 31
6.NoSQL Praxis
Map/Reduce
  Alle Wörter in allen Dokumenten zählen
  Anzahl pro Wort Ausgeben (e.g. „und“ => 1590, „oder“ => 17)

Map Function
Durchsuche alle Wörter im Dokument



map = function() {                       „und“ => {    „und“ => {    „und“ => {
... for (var word in this.text) {          count: 1      count: 1      count: 1
                                         }             }             }
...         emit( word , {count : 1});
... }};
                                         „oder“ => {   „oder“ => {
                                            count: 1      count: 1
                                         }             }




                                                                            32
6.NoSQL Praxis
    Map/Reduce
    Reduce Function
    Die Ergebnisse aus der Suche Bearbeiten

                                              „und“ =>         „oder“ =>
reduce = function(key, emits) {
   total = 0;                                     {count: 1}      {count: 1}
   for (var i in emits) {
           total += emits[i].count;               {count: 1}       {count: 1}
    }

    return {"count" : total};                     {count: 1}
}

         Jede Node liefert ihr lokales Ergebnis

           „und“ => {           „oder“ => {
             count: 3              count: 2
           }                    }
                                                                                33
6.Zusammenfassung und Ausblick
CP Class:
  verteilte nicht 100% replizierte Datenbanken
 - Filialnetz
 - lokale Daten in der Filiale, andere Daten über Netzwerk erreichbar
 - Bei Partition(Netzwerkfehler) kann auf eigene Daten konsistent zugegriffen
    werden


AP Class:
 Web 2.0
 -Kollektives Blogging, Social Networking

 Sync Apps für offline Geräte (Mobiles)
  - Mobiles Gerät und Desktop mit jeweils einer DB Replica




 Beide:
   Real Time Analytics /Datawarehousing
    -Map/Reduce Power mehrer Rechner
                                                                                34
6.Zusammenfassung und Ausblick
CP Class:
  verteilte nicht 100% replizierte Datenbanken
 - Filialnetz
 - lokale Daten in der Filiale, andere Daten über Netzwerk erreichbar
 - Bei Partition(Netzwerkfehler) kann auf eigene Daten konsistent zugegriffen
    werden


AP Class:
 Web 2.0
 -Kollektives Blogging, Social Networking

 Sync Apps für offline Geräte (Mobiles)
  - Mobiles Gerät und Desktop mit jeweils einer DB Replica




 Beide:
   Real Time Analytics /Datawarehousing
    -Map/Reduce Power mehrer Rechner
                                                                                35
6.Zusammenfassung und Ausblick

    Real Time E-Commerce Analytics
     - Hoher Traffic
     - Daten in werden in MongoDB gecaptured
     - Analyse mit Map/Reduce




                                               36
Quellen
[1]Andersen Lehnard, Slater, CouchDB: The Definitive Guide, O‘Reilly, 2010

[2]Chodorof, Dirolf, MongoDB: The Difinitive Guide, O‘Reilly, 2010

[3]Rick Cattell, Horizontally Scalable Data Stores, 2010

[4]Eric Brewer, Cluster-Based Scalable Network Services, 1997

[5]Gilber, Lynch, Brewer’s Conjecture and the Feasibility of Consistent,
Available, Partition-Tolerant Web Services, 2002

[6]Jeffrey Dean, Sanjay Ghemawat, MapReduce: Simplied Data Processing on
Large Clusters, 2004

[7]Stonebarker, SQL Databases v.NoSQL Databases, 2010

[8]Stonebarker, Saying Good-bye to DBMSs, Designing Effective Interfaces,
2010

[9]Gary Anthes, Happy Birthday RDBMS!,
http://cacm.acm.org/magazines/2010/5/87252-happy-birthday-rdbms/fulltext,
2010
                                                                             37
Quellen
[10]MongoDB, On distributed Consistency,
http://blog.mongodb.org/post/475279604/on-distributed-consistency-part-1,
2010

[11]Hendersen, Building Scalable Websites, O‘Reilly, 2006

[12]Werner Vogels, Eventually Consistent,
http://queue.acm.org/detail.cfm?id=1466448, 2008




                                                                            38

Weitere ähnliche Inhalte

Andere mochten auch

Elvia velàzquez slidshare2.docx
Elvia velàzquez slidshare2.docxElvia velàzquez slidshare2.docx
Elvia velàzquez slidshare2.docx
Fernanda Velmar
 
Social Media im Hotel Seedamm Plaza
Social Media im Hotel Seedamm PlazaSocial Media im Hotel Seedamm Plaza
Social Media im Hotel Seedamm Plaza
Hotel SEEDAMM PLAZA
 
BusinessModelGeneration
BusinessModelGenerationBusinessModelGeneration
BusinessModelGeneration
Yeounjoon Kim
 
Niko y pipex
Niko y pipexNiko y pipex
Niko y pipex
Felipe Bugueño Ramos
 
Presentación www.kentiahoreca.com
Presentación www.kentiahoreca.comPresentación www.kentiahoreca.com
Presentación www.kentiahoreca.com
kentiahoreca
 
Materiales que utilizamos para el proyecto
Materiales que utilizamos para el proyectoMateriales que utilizamos para el proyecto
Materiales que utilizamos para el proyecto
Fernando Sanchez
 
JESSICA CISNEROS-Cátedra virtual de cultura ciudadana universidad del atlánti...
JESSICA CISNEROS-Cátedra virtual de cultura ciudadana universidad del atlánti...JESSICA CISNEROS-Cátedra virtual de cultura ciudadana universidad del atlánti...
JESSICA CISNEROS-Cátedra virtual de cultura ciudadana universidad del atlánti...
Jessica Cisneros Sandoval
 
Presentacio
PresentacioPresentacio
Presentacio
Núria Fabregat
 
Diapositiva jessik y leo
Diapositiva jessik y leoDiapositiva jessik y leo
Diapositiva jessik y leo
Nasleo
 
Reflexiones sobre EE
Reflexiones sobre EEReflexiones sobre EE
Reflexiones sobre EE
evi1971
 
Auszug Seminarunterlagen "Hibernate 3.x"
Auszug Seminarunterlagen "Hibernate 3.x"Auszug Seminarunterlagen "Hibernate 3.x"
Auszug Seminarunterlagen "Hibernate 3.x"
schellsoft
 
Sicopedagogia
SicopedagogiaSicopedagogia
Sicopedagogia
Kathy Michelle
 
Javiera Díaz - Recreos
Javiera Díaz - RecreosJaviera Díaz - Recreos
Javiera Díaz - Recreos
Javiera Diaz
 
Tics educacion industria y vida cotidiana
Tics educacion industria y vida cotidianaTics educacion industria y vida cotidiana
Tics educacion industria y vida cotidiana
ronaxel
 
Modalverben und ihr gebrauch im roman
Modalverben und ihr gebrauch im romanModalverben und ihr gebrauch im roman
Modalverben und ihr gebrauch im roman
yfka
 
La tricolor
La tricolorLa tricolor
La tricolor
sofiaa99
 
El poder de las palabras
El poder de las palabrasEl poder de las palabras
El poder de las palabras
jaravilla64
 
Algoritmo
AlgoritmoAlgoritmo
Algoritmo
Yanori Perez
 
Supervisory Framework 2019 - Overview
Supervisory Framework 2019 - OverviewSupervisory Framework 2019 - Overview
Supervisory Framework 2019 - Overview
RPS Recovery Portfolio Services Ltd.
 

Andere mochten auch (20)

Elvia velàzquez slidshare2.docx
Elvia velàzquez slidshare2.docxElvia velàzquez slidshare2.docx
Elvia velàzquez slidshare2.docx
 
Social Media im Hotel Seedamm Plaza
Social Media im Hotel Seedamm PlazaSocial Media im Hotel Seedamm Plaza
Social Media im Hotel Seedamm Plaza
 
BusinessModelGeneration
BusinessModelGenerationBusinessModelGeneration
BusinessModelGeneration
 
Niko y pipex
Niko y pipexNiko y pipex
Niko y pipex
 
Presentación www.kentiahoreca.com
Presentación www.kentiahoreca.comPresentación www.kentiahoreca.com
Presentación www.kentiahoreca.com
 
Materiales que utilizamos para el proyecto
Materiales que utilizamos para el proyectoMateriales que utilizamos para el proyecto
Materiales que utilizamos para el proyecto
 
JESSICA CISNEROS-Cátedra virtual de cultura ciudadana universidad del atlánti...
JESSICA CISNEROS-Cátedra virtual de cultura ciudadana universidad del atlánti...JESSICA CISNEROS-Cátedra virtual de cultura ciudadana universidad del atlánti...
JESSICA CISNEROS-Cátedra virtual de cultura ciudadana universidad del atlánti...
 
Presentacio
PresentacioPresentacio
Presentacio
 
Diapositiva jessik y leo
Diapositiva jessik y leoDiapositiva jessik y leo
Diapositiva jessik y leo
 
Reflexiones sobre EE
Reflexiones sobre EEReflexiones sobre EE
Reflexiones sobre EE
 
Auszug Seminarunterlagen "Hibernate 3.x"
Auszug Seminarunterlagen "Hibernate 3.x"Auszug Seminarunterlagen "Hibernate 3.x"
Auszug Seminarunterlagen "Hibernate 3.x"
 
Sicopedagogia
SicopedagogiaSicopedagogia
Sicopedagogia
 
Javiera Díaz - Recreos
Javiera Díaz - RecreosJaviera Díaz - Recreos
Javiera Díaz - Recreos
 
Tics educacion industria y vida cotidiana
Tics educacion industria y vida cotidianaTics educacion industria y vida cotidiana
Tics educacion industria y vida cotidiana
 
Modalverben und ihr gebrauch im roman
Modalverben und ihr gebrauch im romanModalverben und ihr gebrauch im roman
Modalverben und ihr gebrauch im roman
 
La tricolor
La tricolorLa tricolor
La tricolor
 
El poder de las palabras
El poder de las palabrasEl poder de las palabras
El poder de las palabras
 
Algoritmo
AlgoritmoAlgoritmo
Algoritmo
 
Kurskonzeption
KurskonzeptionKurskonzeption
Kurskonzeption
 
Supervisory Framework 2019 - Overview
Supervisory Framework 2019 - OverviewSupervisory Framework 2019 - Overview
Supervisory Framework 2019 - Overview
 

Ähnlich wie Nosql Hintergründe und Anwendungen

20171121_DOAGKonferenz_JSON_OracleNoSQL_KPatenge
20171121_DOAGKonferenz_JSON_OracleNoSQL_KPatenge20171121_DOAGKonferenz_JSON_OracleNoSQL_KPatenge
20171121_DOAGKonferenz_JSON_OracleNoSQL_KPatenge
Karin Patenge
 
OOP 2014 SQL oder NoSQL - die Auswahl der richtigen Datenbankplattform für di...
OOP 2014 SQL oder NoSQL - die Auswahl der richtigen Datenbankplattform für di...OOP 2014 SQL oder NoSQL - die Auswahl der richtigen Datenbankplattform für di...
OOP 2014 SQL oder NoSQL - die Auswahl der richtigen Datenbankplattform für di...
AWS Germany
 
SimpleDB - Chancen einer Cloud Datenbank
SimpleDB - Chancen einer Cloud DatenbankSimpleDB - Chancen einer Cloud Datenbank
SimpleDB - Chancen einer Cloud Datenbank
ONE Schweiz
 
Ruby on Rails in a metro session
Ruby on Rails in a metro sessionRuby on Rails in a metro session
Ruby on Rails in a metro session
Virttoo org
 
Oracle no sql-doag-datenbank_konferenz_juni_2014
Oracle no sql-doag-datenbank_konferenz_juni_2014Oracle no sql-doag-datenbank_konferenz_juni_2014
Oracle no sql-doag-datenbank_konferenz_juni_2014
Gunther Pippèrr
 
Service Orchestrierung mit Apache Mesos
Service Orchestrierung mit Apache MesosService Orchestrierung mit Apache Mesos
Service Orchestrierung mit Apache Mesos
Ralf Ernst
 
A NoSQL Summer - The Year After
A NoSQL Summer - The Year AfterA NoSQL Summer - The Year After
A NoSQL Summer - The Year After
MeMo News AG
 
Private Cloud mit Open Source
Private Cloud mit Open SourcePrivate Cloud mit Open Source
Private Cloud mit Open Source
Daniel Schneller
 
Das Repository-Pattern und der O/R-Mapper: Geniale Kombination oder vergebene...
Das Repository-Pattern und der O/R-Mapper: Geniale Kombination oder vergebene...Das Repository-Pattern und der O/R-Mapper: Geniale Kombination oder vergebene...
Das Repository-Pattern und der O/R-Mapper: Geniale Kombination oder vergebene...
André Krämer
 
Jug nbg containerplattform dcos
Jug nbg containerplattform dcosJug nbg containerplattform dcos
Jug nbg containerplattform dcos
Ralf Ernst
 
Where are all transactions gone? Was in_der_cloud_alles_verboten_ist
Where are all transactions gone? Was in_der_cloud_alles_verboten_istWhere are all transactions gone? Was in_der_cloud_alles_verboten_ist
Where are all transactions gone? Was in_der_cloud_alles_verboten_ist
Ramon Anger
 
Spezialitäten der Oracle Lizenzierung - DOAG Konferenz 2010 - OPITZ CONSULTI...
Spezialitäten der Oracle Lizenzierung -  DOAG Konferenz 2010 - OPITZ CONSULTI...Spezialitäten der Oracle Lizenzierung -  DOAG Konferenz 2010 - OPITZ CONSULTI...
Spezialitäten der Oracle Lizenzierung - DOAG Konferenz 2010 - OPITZ CONSULTI...
OPITZ CONSULTING Deutschland
 
Apache Cassandra - Einführung
Apache Cassandra - EinführungApache Cassandra - Einführung
Apache Cassandra - Einführung
Andreas Finke
 
20160310_ModernApplicationDevelopment_NoSQL_KPatenge
20160310_ModernApplicationDevelopment_NoSQL_KPatenge20160310_ModernApplicationDevelopment_NoSQL_KPatenge
20160310_ModernApplicationDevelopment_NoSQL_KPatenge
Karin Patenge
 
PostgreSQL News
PostgreSQL NewsPostgreSQL News
PostgreSQL News
Peter Eisentraut
 
Microservices and Container Management with Mesosphere DC/OS
Microservices and Container Management with Mesosphere DC/OSMicroservices and Container Management with Mesosphere DC/OS
Microservices and Container Management with Mesosphere DC/OS
Ralf Ernst
 
SQL oder NoSQL - Die Auswahl der richtigen Datenbankplattform für die Cloud
SQL oder NoSQL - Die Auswahl der richtigen Datenbankplattform für die CloudSQL oder NoSQL - Die Auswahl der richtigen Datenbankplattform für die Cloud
SQL oder NoSQL - Die Auswahl der richtigen Datenbankplattform für die Cloud
AWS Germany
 

Ähnlich wie Nosql Hintergründe und Anwendungen (20)

20171121_DOAGKonferenz_JSON_OracleNoSQL_KPatenge
20171121_DOAGKonferenz_JSON_OracleNoSQL_KPatenge20171121_DOAGKonferenz_JSON_OracleNoSQL_KPatenge
20171121_DOAGKonferenz_JSON_OracleNoSQL_KPatenge
 
Big Data & NoSQL
Big Data & NoSQLBig Data & NoSQL
Big Data & NoSQL
 
OOP 2014 SQL oder NoSQL - die Auswahl der richtigen Datenbankplattform für di...
OOP 2014 SQL oder NoSQL - die Auswahl der richtigen Datenbankplattform für di...OOP 2014 SQL oder NoSQL - die Auswahl der richtigen Datenbankplattform für di...
OOP 2014 SQL oder NoSQL - die Auswahl der richtigen Datenbankplattform für di...
 
Query Result Caching
Query Result CachingQuery Result Caching
Query Result Caching
 
SimpleDB - Chancen einer Cloud Datenbank
SimpleDB - Chancen einer Cloud DatenbankSimpleDB - Chancen einer Cloud Datenbank
SimpleDB - Chancen einer Cloud Datenbank
 
Ruby on Rails in a metro session
Ruby on Rails in a metro sessionRuby on Rails in a metro session
Ruby on Rails in a metro session
 
Oracle no sql-doag-datenbank_konferenz_juni_2014
Oracle no sql-doag-datenbank_konferenz_juni_2014Oracle no sql-doag-datenbank_konferenz_juni_2014
Oracle no sql-doag-datenbank_konferenz_juni_2014
 
Service Orchestrierung mit Apache Mesos
Service Orchestrierung mit Apache MesosService Orchestrierung mit Apache Mesos
Service Orchestrierung mit Apache Mesos
 
A NoSQL Summer - The Year After
A NoSQL Summer - The Year AfterA NoSQL Summer - The Year After
A NoSQL Summer - The Year After
 
in memory datenbanken
in memory datenbankenin memory datenbanken
in memory datenbanken
 
Private Cloud mit Open Source
Private Cloud mit Open SourcePrivate Cloud mit Open Source
Private Cloud mit Open Source
 
Das Repository-Pattern und der O/R-Mapper: Geniale Kombination oder vergebene...
Das Repository-Pattern und der O/R-Mapper: Geniale Kombination oder vergebene...Das Repository-Pattern und der O/R-Mapper: Geniale Kombination oder vergebene...
Das Repository-Pattern und der O/R-Mapper: Geniale Kombination oder vergebene...
 
Jug nbg containerplattform dcos
Jug nbg containerplattform dcosJug nbg containerplattform dcos
Jug nbg containerplattform dcos
 
Where are all transactions gone? Was in_der_cloud_alles_verboten_ist
Where are all transactions gone? Was in_der_cloud_alles_verboten_istWhere are all transactions gone? Was in_der_cloud_alles_verboten_ist
Where are all transactions gone? Was in_der_cloud_alles_verboten_ist
 
Spezialitäten der Oracle Lizenzierung - DOAG Konferenz 2010 - OPITZ CONSULTI...
Spezialitäten der Oracle Lizenzierung -  DOAG Konferenz 2010 - OPITZ CONSULTI...Spezialitäten der Oracle Lizenzierung -  DOAG Konferenz 2010 - OPITZ CONSULTI...
Spezialitäten der Oracle Lizenzierung - DOAG Konferenz 2010 - OPITZ CONSULTI...
 
Apache Cassandra - Einführung
Apache Cassandra - EinführungApache Cassandra - Einführung
Apache Cassandra - Einführung
 
20160310_ModernApplicationDevelopment_NoSQL_KPatenge
20160310_ModernApplicationDevelopment_NoSQL_KPatenge20160310_ModernApplicationDevelopment_NoSQL_KPatenge
20160310_ModernApplicationDevelopment_NoSQL_KPatenge
 
PostgreSQL News
PostgreSQL NewsPostgreSQL News
PostgreSQL News
 
Microservices and Container Management with Mesosphere DC/OS
Microservices and Container Management with Mesosphere DC/OSMicroservices and Container Management with Mesosphere DC/OS
Microservices and Container Management with Mesosphere DC/OS
 
SQL oder NoSQL - Die Auswahl der richtigen Datenbankplattform für die Cloud
SQL oder NoSQL - Die Auswahl der richtigen Datenbankplattform für die CloudSQL oder NoSQL - Die Auswahl der richtigen Datenbankplattform für die Cloud
SQL oder NoSQL - Die Auswahl der richtigen Datenbankplattform für die Cloud
 

Nosql Hintergründe und Anwendungen

  • 2. Inhalt 1. Motivation 2. RDBMS 3. CAP Theorem 4. NoSQL 5. NoSql Overview 6. NoSQl Praxis 7. Zusammenfassung und Ausblick 2
  • 3. 1.Motivation Datenbanken • Permanente Sicherung großer Datenmengen • Effizientes Wiederfinden der Daten (Indexierung) • Analytische Untersuchungen • Gleichzeitiges Arbeiten von mehreren Benutzern • Schutz vor unautorisiertem Zugriff 3
  • 4. 1.Motivation Geschichte 60er Jahre Hierarchisch/Netzwerkartig • Zeigerstrukturen zwischen Daten • navigierende Anfragesprachen 70er Jahre Relational • Daten in Tabellenstruktur • standardisierte Datenbanksprache(SQL) 4
  • 5. 1.Motivation Geschichte 60er Jahre Hierarchisch/Netzwerkartig • Zeigerstrukturen zwischen Daten • navigierende Anfragesprachen 70er Jahre Relational • Daten in Tabellenstruktur • standardisierte Datenbanksprache(SQL) 5
  • 6. 1.Motivation • Relationale Datenbanken sind 40 Jahre alt • One Size fitts all auf alle Probleme angewendet • Applikationen benutzen ein anderes Datenmodell • Einige Applikationen haben weniger strikte Anforderungen an Daten 6
  • 7. 2.RDBMS Bücher BücherNutzer Nutzer 7
  • 8. 2.RDBMS Scaling „Enterprise“ Solutions + Keine Applikationslogik erforderlich - Teure „Enterpriselösungen“ - Aufwendige JOIN Algorithmen, Eignung nur bei „Einfachen JOINs“. 8
  • 9. 2.RDBMS Master Slave Replication + Vergleichbar weniger Administration + In den Basispacketen vorhanden - Keine Datenpartionierung - Schreibzugriffe skalieren nicht 9
  • 10. 2.RDBMS Functional Partitioning (Sharding) - Immens hohe Verteilungslogik auf der Applikationsebene - Erfordert abgetrennte Datenbereiche - Denormalisierung Verwendung des RDBMS gegen eigentliches Funktionsdesign 10
  • 11. 2.RDBMS Transaktionen Atomicity (Atomarität): Transaktion wird entweder ganz oder gar nicht ausgeführt Consistency (Konsistenz / Integritätserhaltung): Datenbank ist vor Beginn und nach Beendigung einer Transaktion jeweils in einem konsistenten Zustand Isolation (Isolation): Nutzer, der mit einer Datenbank arbeitet, sollte den Eindruck haben, dass er mit dieser Datenbank alleine Arbeitet Durability (Dauerhaftigkeit / Persistenz): nach erfolgreichem Abschluss einer Transaktion muss das Ergebnis dieser Transaktion „dauerhaft“ in der Datenbank gespeichert werden 11
  • 12. 2.RDBMS • Garantie der ACID Eigenschaften wird komplex • Atomicity fordert Verteiltes Commit Protokoll (e.g. 2PC) Alle Nodes müssen sich einig sein • Isolation fordert Erhaltung der Locks für die gesamte Dauer des Protokolls die gesamte Transaktion darf nicht gestört werden durch nebenläufige Transaktionen Leichtgewichtige Transaktionen, große Netzwerk Roundtrips => • Lockerhaltung länger als Arbeitszeit • „Skyrocketing Lock Competitions“ • Schwund des Transaktionsdurchsatzes 12
  • 13. 2.RDBMS Features: • Festes Datenmodell • Redundanzvermeidung durch Fremdschlüsselbeziehungen • Starke Konsistenz • Transaktionsmodell Garantien Eignung: • Finanzprozesse • ERP Systeme • Systeme mit wenigen Benutzern Schwierigkeiten: • Horizontale Scalierung • JOIN‘s kosten CPU Power • Datenmodel passt nicht immer ins relationale Schema One Size does NOT fit all! 13
  • 14. 3.CAP Theorem Erik Brewer überlegt 1997 ein Gegenmodel zu ACID BASE – Basically Available, Soft-state, Eventually consistent ACID BASE • Starke Konsistenz • Schwache Konsistenz – altes data OK • Isolation • Availability zuerst vs • Fokus auf Commit • Versuch dein Bestes • Geschachtelte • Aggresiv (optimisticsch) Transaktionen • Leichter! • Konservativ (pessimistisch) • Schneller • Schwierige Umsetzung • Einfacher Umsetzbar • (e.g. Schema, Normalesierung, JOIN‘s) 14
  • 15. 3.CAP Theorem Erik Brewer stützt notwendigkeit von BASE durch ein Theorem Linear Consitency Totale Ordnung aller Operationen Availibility Jeder Anfrage an einen intakten Node wir bearbeitet Partitiotolerence Fehler bei der Kommunikation im verteilten System werden toleriert Behauptung: nur 2 der 3 Features gleichzeitig erfüllbar Bewiesen durch Gilbert und Lynch 15
  • 16. 3.CAP Theorem AP Class Es gilt: a) Das System möchte Partiontoleranz erfüllen b) Es treten Netzwekfehler auf. Wenn: Das System beantwortet zu diesem Zeitpunkt alle Anfragen (Availibility) Dann: Die Antworten können nicht konsistent sein, da keine Einigkeit herscht 16
  • 17. 3.CAP Theorem AP Class Eventual Consistency Wenn keine neuen Updates auftreten liefert jeder Zugriff eventuell den aktuellen Wert • Keine Locks • Local Consistency • „Read your own Writes“ • Multi Version Concurency Control (MVCC) 17
  • 18. 3.CAP Theorem Es gilt: a) Das System möchte Partiontoleranz erfüllen b) Es treten Netzwekfehler auf. Wenn: Alle Benutzer des Systems erhalten korrekte und gleiche Daten Dann: Das System beantwortet Anfragen solange nicht bis es sich synchronisiert hat 18
  • 19. 3.CAP Theorem CP Class R1 W3 A B C W2 R2 Master A B C W1 R3 A B C 19
  • 20. 4.NoSQL • Begriff als erstes 1998 durch Carlo Strozzi verwendet • relationale Datnabank, die explizit auf SQL verzichtet • No to SQL • 2009 durch Johan Oskarsson aufgegriffen • Last.fm Tagung • Techniken für nicht-relationale verteilte Datenbanken • Keine neue Technologie • Aufleben bekannter BASE Konzepte gemäß aktuellen Anfordrerungen • NoSQL Bewegung ensteht • NoSQL = Not only SQL 20
  • 21. 4.NoSQL • Nicht relational • Schemafrei • Einfache API‘s (meistens)Verizicht auf SQL, JavaScript, JSON, Views, REST • Horizontal scalierbar (Shards) • Map/Reduce Paradigma zu parallelen Verarbeitung • Replikation zwischen den Schards • Partition tolerant AP CP Eventual Consistency Write/Read Availabillity Balance MVCC Update in Place 21
  • 22. 4.NoSQL - Overview Key/Value Store • einfache Datenhalter • Ein Key, Ein Value, Keine Duplikate • Sehr Schnell • Verteilter Hash • Die Datenbank versteht die Values nicht BLOB • Voldemort, Redis, Tokio Cabinet 22
  • 23. 5.NoSQL - Overview Key/Value Store key value „6a9b85fd1061e“ => #name:#$$!!^^ #firstname:#$$!!^ #birthday:#$$!!^^ #adress:#$$!!^^ 23
  • 24. 5.NoSQL - Overview Column-based Store • Spalten als einfachste Datenhalter • Verteilte, multidimensonale, sortierte Map • GoogleBigTable Clones • GoogleBigTable, Cassandra (Facebook), Apache Hbase • Angeblich besser bei Analytical Processing, Datawarehouse 24
  • 25. 4.NoSQL - Overview Column Store rowID column family person person person person person title name firstname birthday adress adress 11 12 34 10 14 time value „Doe“ „John“ „12.Dec.19085“ „X-Street“ „Y-Street“ 25
  • 26. 5.NoSQL - Overview Document Stores • Key Value Store, aber das Value ist strukturiert und von der DB interpretierbar (Document) • Datenanfragen nicht nur über Keys, sondern über alle Documentfelder • Indexes über einzelne Documentfelder • CouchDB, MongoDB 26
  • 27. 5.NoSQL - Overview Document Store Document keys #Person{ name: "Doe", „Person_23 “ firstname: "John", birthday: "12.Dec.1985", adresses: [ #Adress{ street: "..." , „Adress_47 “ city: "...", .... type:"delivery", } #Adress{ „Adress_11 “ street: "...", city: "...", type: "standard", } ] } 27
  • 29. 6.NoSQL Praxis Schema Design Denormalisiert(„NoSQL Way“) Embed bevorzugt über Reference 29
  • 30. 6.NoSQL Praxis Queries REST http://127.0.0.1:5984/mydb/_design/blog GET, PUT, POST, DELETE API db.blogs.find({„author" : "joe"}); db.blogs.find( $where: function() { return this.author == “joe” ); • Driver für fast alle Programmiersprachen • Query Main und Embeded Objects • Markups ($all, $or, $exists, $size, <, >, …) • Embeded Javascipt function (){return …} 30
  • 32. 6.NoSQL Praxis Map/Reduce Alle Wörter in allen Dokumenten zählen Anzahl pro Wort Ausgeben (e.g. „und“ => 1590, „oder“ => 17) Map Function Durchsuche alle Wörter im Dokument map = function() { „und“ => { „und“ => { „und“ => { ... for (var word in this.text) { count: 1 count: 1 count: 1 } } } ... emit( word , {count : 1}); ... }}; „oder“ => { „oder“ => { count: 1 count: 1 } } 32
  • 33. 6.NoSQL Praxis Map/Reduce Reduce Function Die Ergebnisse aus der Suche Bearbeiten „und“ => „oder“ => reduce = function(key, emits) { total = 0; {count: 1} {count: 1} for (var i in emits) { total += emits[i].count; {count: 1} {count: 1} } return {"count" : total}; {count: 1} } Jede Node liefert ihr lokales Ergebnis „und“ => { „oder“ => { count: 3 count: 2 } } 33
  • 34. 6.Zusammenfassung und Ausblick CP Class: verteilte nicht 100% replizierte Datenbanken - Filialnetz - lokale Daten in der Filiale, andere Daten über Netzwerk erreichbar - Bei Partition(Netzwerkfehler) kann auf eigene Daten konsistent zugegriffen werden AP Class: Web 2.0 -Kollektives Blogging, Social Networking Sync Apps für offline Geräte (Mobiles) - Mobiles Gerät und Desktop mit jeweils einer DB Replica Beide: Real Time Analytics /Datawarehousing -Map/Reduce Power mehrer Rechner 34
  • 35. 6.Zusammenfassung und Ausblick CP Class: verteilte nicht 100% replizierte Datenbanken - Filialnetz - lokale Daten in der Filiale, andere Daten über Netzwerk erreichbar - Bei Partition(Netzwerkfehler) kann auf eigene Daten konsistent zugegriffen werden AP Class: Web 2.0 -Kollektives Blogging, Social Networking Sync Apps für offline Geräte (Mobiles) - Mobiles Gerät und Desktop mit jeweils einer DB Replica Beide: Real Time Analytics /Datawarehousing -Map/Reduce Power mehrer Rechner 35
  • 36. 6.Zusammenfassung und Ausblick Real Time E-Commerce Analytics - Hoher Traffic - Daten in werden in MongoDB gecaptured - Analyse mit Map/Reduce 36
  • 37. Quellen [1]Andersen Lehnard, Slater, CouchDB: The Definitive Guide, O‘Reilly, 2010 [2]Chodorof, Dirolf, MongoDB: The Difinitive Guide, O‘Reilly, 2010 [3]Rick Cattell, Horizontally Scalable Data Stores, 2010 [4]Eric Brewer, Cluster-Based Scalable Network Services, 1997 [5]Gilber, Lynch, Brewer’s Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services, 2002 [6]Jeffrey Dean, Sanjay Ghemawat, MapReduce: Simplied Data Processing on Large Clusters, 2004 [7]Stonebarker, SQL Databases v.NoSQL Databases, 2010 [8]Stonebarker, Saying Good-bye to DBMSs, Designing Effective Interfaces, 2010 [9]Gary Anthes, Happy Birthday RDBMS!, http://cacm.acm.org/magazines/2010/5/87252-happy-birthday-rdbms/fulltext, 2010 37
  • 38. Quellen [10]MongoDB, On distributed Consistency, http://blog.mongodb.org/post/475279604/on-distributed-consistency-part-1, 2010 [11]Hendersen, Building Scalable Websites, O‘Reilly, 2006 [12]Werner Vogels, Eventually Consistent, http://queue.acm.org/detail.cfm?id=1466448, 2008 38