NoSQLHintergründe und AnwendungenAndreas Winschu                1
Inhalt 1. Motivation 2. RDBMS 3. CAP Theorem 4. NoSQL 5. NoSql Overview 6. NoSQl Praxis 7. Zusammenfassung und Ausblick   ...
1.MotivationDatenbanken  • Permanente Sicherung großer Datenmengen  • Effizientes Wiederfinden der Daten (Indexierung)  • ...
1.MotivationGeschichte       60er Jahre       Hierarchisch/Netzwerkartig       • Zeigerstrukturen zwischen Daten       • n...
1.MotivationGeschichte       60er Jahre       Hierarchisch/Netzwerkartig       • Zeigerstrukturen zwischen Daten       • n...
1.Motivation • Relationale Datenbanken sind 40 Jahre alt • One Size fitts all   auf alle Probleme angewendet • Applikation...
2.RDBMS   Bücher   BücherNutzer       Nutzer                  7
2.RDBMSScaling „Enterprise“ Solutions + Keine Applikationslogik erforderlich - Teure „Enterpriselösungen“ - Aufwendige JOI...
2.RDBMSMaster Slave Replication+ Vergleichbar weniger Administration+ In den Basispacketen vorhanden- Keine Datenpartionie...
2.RDBMSFunctional Partitioning (Sharding)- Immens hohe Verteilungslogik auf der Applikationsebene- Erfordert abgetrennte D...
2.RDBMSTransaktionenAtomicity (Atomarität):Transaktion wird entweder ganz oder gar nichtausgeführtConsistency (Konsistenz ...
2.RDBMS• Garantie der ACID Eigenschaften wird  komplex• Atomicity fordert Verteiltes Commit  Protokoll (e.g. 2PC)  Alle No...
2.RDBMSFeatures: •   Festes Datenmodell •   Redundanzvermeidung durch Fremdschlüsselbeziehungen •   Starke Konsistenz •   ...
3.CAP TheoremErik Brewer überlegt 1997 ein Gegenmodel zu ACIDBASE – Basically Available, Soft-state, Eventually consistent...
3.CAP Theorem                            Erik Brewer stützt notwendigkeit von                            BASE durch ein Th...
3.CAP TheoremAP ClassEs gilt: a) Das System möchte Partiontoleranz erfüllen b) Es treten Netzwekfehler auf.Wenn:Das System...
3.CAP TheoremAP ClassEventual ConsistencyWenn keine neuen Updates auftreten liefert jeder Zugriff eventuell den aktuellen ...
3.CAP TheoremEs gilt: a) Das System möchte Partiontoleranz erfüllen b) Es treten Netzwekfehler auf.Wenn:Alle Benutzer des ...
3.CAP TheoremCP Class                            R1           W3                A   B   C           W2               R2Mas...
4.NoSQL•   Begriff als erstes 1998 durch Carlo Strozzi verwendet     • relationale Datnabank, die explizit auf SQL verzich...
4.NoSQL•   Nicht relational•   Schemafrei•   Einfache API‘s    (meistens)Verizicht auf SQL, JavaScript, JSON, Views, REST•...
4.NoSQL -              Overview          Key/Value Store  • einfache Datenhalter  • Ein Key, Ein Value, Keine Duplikate  •...
5.NoSQL -            Overview           Key/Value Store     key                     value   „6a9b85fd1061e“     =>    #nam...
5.NoSQL -              Overview          Column-based Store  • Spalten als einfachste Datenhalter  • Verteilte, multidimen...
4.NoSQL -                            Overview                           Column Store           rowIDcolumn family      per...
5.NoSQL -              Overview          Document Stores  • Key Value Store, aber das Value ist strukturiert    und von de...
5.NoSQL -                OverviewDocument Store              Documentkeys                             #Person{            ...
6.NoSQL PraxisSchema Design   Relational                 28
6.NoSQL PraxisSchema Design   Denormalisiert(„NoSQL Way“)   Embed bevorzugt über Reference                                ...
6.NoSQL PraxisQueries REST http://127.0.0.1:5984/mydb/_design/blog GET, PUT, POST, DELETE API   db.blogs.find({„author" : ...
6.NoSQL PraxisMap/Reduce                 31
6.NoSQL PraxisMap/Reduce  Alle Wörter in allen Dokumenten zählen  Anzahl pro Wort Ausgeben (e.g. „und“ => 1590, „oder“ => ...
6.NoSQL Praxis    Map/Reduce    Reduce Function    Die Ergebnisse aus der Suche Bearbeiten                                ...
6.Zusammenfassung und AusblickCP Class:  verteilte nicht 100% replizierte Datenbanken - Filialnetz - lokale Daten in der F...
6.Zusammenfassung und AusblickCP Class:  verteilte nicht 100% replizierte Datenbanken - Filialnetz - lokale Daten in der F...
6.Zusammenfassung und Ausblick    Real Time E-Commerce Analytics     - Hoher Traffic     - Daten in werden in MongoDB geca...
Quellen[1]Andersen Lehnard, Slater, CouchDB: The Definitive Guide, O‘Reilly, 2010[2]Chodorof, Dirolf, MongoDB: The Difinit...
Quellen[10]MongoDB, On distributed Consistency,http://blog.mongodb.org/post/475279604/on-distributed-consistency-part-1,20...
Nächste SlideShare
Wird geladen in …5
×

Nosql Hintergründe und Anwendungen

1.415 Aufrufe

Veröffentlicht am

Vortrag zu NOSQL für ein Uni Seminar

Ausarbeitung:
http://users.informatik.haw-hamburg.de/~ubicomp/projekte/master10-11-aw1/winschu/bericht.pdf

Veröffentlicht in: Technologie
1 Kommentar
0 Gefällt mir
Statistik
Notizen
  • Ausarbeitung unter:
    http://users.informatik.haw-hamburg.de/~ubicomp/projekte/master10-11-aw1/winschu/bericht.pdf
       Antworten 
    Sind Sie sicher, dass Sie …  Ja  Nein
    Ihre Nachricht erscheint hier
  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
1.415
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
1
Aktionen
Geteilt
0
Downloads
18
Kommentare
1
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Nosql Hintergründe und Anwendungen

  1. 1. NoSQLHintergründe und AnwendungenAndreas Winschu 1
  2. 2. Inhalt 1. Motivation 2. RDBMS 3. CAP Theorem 4. NoSQL 5. NoSql Overview 6. NoSQl Praxis 7. Zusammenfassung und Ausblick 2
  3. 3. 1.MotivationDatenbanken • Permanente Sicherung großer Datenmengen • Effizientes Wiederfinden der Daten (Indexierung) • Analytische Untersuchungen • Gleichzeitiges Arbeiten von mehreren Benutzern • Schutz vor unautorisiertem Zugriff 3
  4. 4. 1.MotivationGeschichte 60er Jahre Hierarchisch/Netzwerkartig • Zeigerstrukturen zwischen Daten • navigierende Anfragesprachen 70er Jahre Relational • Daten in Tabellenstruktur • standardisierte Datenbanksprache(SQL) 4
  5. 5. 1.MotivationGeschichte 60er Jahre Hierarchisch/Netzwerkartig • Zeigerstrukturen zwischen Daten • navigierende Anfragesprachen 70er Jahre Relational • Daten in Tabellenstruktur • standardisierte Datenbanksprache(SQL) 5
  6. 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. 7. 2.RDBMS Bücher BücherNutzer Nutzer 7
  8. 8. 2.RDBMSScaling „Enterprise“ Solutions + Keine Applikationslogik erforderlich - Teure „Enterpriselösungen“ - Aufwendige JOIN Algorithmen, Eignung nur bei „Einfachen JOINs“. 8
  9. 9. 2.RDBMSMaster Slave Replication+ Vergleichbar weniger Administration+ In den Basispacketen vorhanden- Keine Datenpartionierung- Schreibzugriffe skalieren nicht 9
  10. 10. 2.RDBMSFunctional Partitioning (Sharding)- Immens hohe Verteilungslogik auf der Applikationsebene- Erfordert abgetrennte Datenbereiche- Denormalisierung Verwendung des RDBMS gegen eigentliches Funktionsdesign 10
  11. 11. 2.RDBMSTransaktionenAtomicity (Atomarität):Transaktion wird entweder ganz oder gar nichtausgeführtConsistency (Konsistenz / Integritätserhaltung):Datenbank ist vor Beginn und nach Beendigung einerTransaktion jeweils in einem konsistenten ZustandIsolation (Isolation):Nutzer, der mit einer Datenbank arbeitet, sollte denEindruck haben, dass er mit dieser Datenbank alleineArbeitetDurability (Dauerhaftigkeit / Persistenz):nach erfolgreichem Abschluss einer Transaktion mussdas Ergebnis dieser Transaktion „dauerhaft“ in derDatenbank gespeichert werden 11
  12. 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. 13. 2.RDBMSFeatures: • Festes Datenmodell • Redundanzvermeidung durch Fremdschlüsselbeziehungen • Starke Konsistenz • Transaktionsmodell GarantienEignung: • Finanzprozesse • ERP Systeme • Systeme mit wenigen BenutzernSchwierigkeiten: • Horizontale Scalierung • JOIN‘s kosten CPU Power • Datenmodel passt nicht immer ins relationale Schema One Size does NOT fit all! 13
  14. 14. 3.CAP TheoremErik Brewer überlegt 1997 ein Gegenmodel zu ACIDBASE – 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. 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. 16. 3.CAP TheoremAP ClassEs 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. 17. 3.CAP TheoremAP ClassEventual ConsistencyWenn 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. 18. 3.CAP TheoremEs gilt: a) Das System möchte Partiontoleranz erfüllen b) Es treten Netzwekfehler auf.Wenn:Alle Benutzer des Systems erhalten korrekte und gleiche DatenDann:Das System beantwortet Anfragen solange nicht bis es sich synchronisierthat 18
  19. 19. 3.CAP TheoremCP Class R1 W3 A B C W2 R2Master A B C W1 R3 A B C 19
  20. 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. 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. 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. 23. 5.NoSQL - Overview Key/Value Store key value „6a9b85fd1061e“ => #name:#$$!!^^ #firstname:#$$!!^ #birthday:#$$!!^^ #adress:#$$!!^^ 23
  24. 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. 25. 4.NoSQL - Overview Column Store rowIDcolumn 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. 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. 27. 5.NoSQL - OverviewDocument Store Documentkeys #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
  28. 28. 6.NoSQL PraxisSchema Design Relational 28
  29. 29. 6.NoSQL PraxisSchema Design Denormalisiert(„NoSQL Way“) Embed bevorzugt über Reference 29
  30. 30. 6.NoSQL PraxisQueries 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
  31. 31. 6.NoSQL PraxisMap/Reduce 31
  32. 32. 6.NoSQL PraxisMap/Reduce Alle Wörter in allen Dokumenten zählen Anzahl pro Wort Ausgeben (e.g. „und“ => 1590, „oder“ => 17)Map FunctionDurchsuche alle Wörter im Dokumentmap = 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. 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. 34. 6.Zusammenfassung und AusblickCP 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 werdenAP 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. 35. 6.Zusammenfassung und AusblickCP 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 werdenAP 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. 36. 6.Zusammenfassung und Ausblick Real Time E-Commerce Analytics - Hoher Traffic - Daten in werden in MongoDB gecaptured - Analyse mit Map/Reduce 36
  37. 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 onLarge 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. 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

×