Nosql Hintergrnde und Anwendungen

  • Published on
    12-Jun-2015

  • View
    1.099

  • Download
    0

DESCRIPTION

Vortrag zu NOSQL fr ein Uni Seminar Ausarbeitung: http://users.informatik.haw-hamburg.de/~ubicomp/projekte/master10-11-aw1/winschu/bericht.pdf

Transcript

  • 1. NoSQLHintergrnde und AnwendungenAndreas Winschu1

2. Inhalt 1. Motivation 2. RDBMS 3. CAP Theorem 4. NoSQL 5. NoSql Overview 6. NoSQl Praxis 7. Zusammenfassung und Ausblick 2 3. 1.MotivationDatenbanken Permanente Sicherung groer Datenmengen Effizientes Wiederfinden der Daten (Indexierung) Analytische Untersuchungen Gleichzeitiges Arbeiten von mehreren Benutzern Schutz vor unautorisiertem Zugriff 3 4. 1.MotivationGeschichte 60er Jahre Hierarchisch/Netzwerkartig Zeigerstrukturen zwischen Daten navigierende Anfragesprachen 70er JahreRelational Daten in Tabellenstruktur standardisierte Datenbanksprache(SQL)4 5. 1.MotivationGeschichte 60er Jahre Hierarchisch/Netzwerkartig Zeigerstrukturen zwischen Daten navigierende Anfragesprachen 70er JahreRelational 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 Daten6 7. 2.RDBMS Bcher BcherNutzer Nutzer7 8. 2.RDBMSScaling Enterprise Solutions + Keine Applikationslogik erforderlich - Teure Enterpriselsungen - Aufwendige JOIN Algorithmen,Eignung nur bei Einfachen JOINs.8 9. 2.RDBMSMaster Slave Replication+ Vergleichbar weniger Administration+ In den Basispacketen vorhanden- Keine Datenpartionierung- Schreibzugriffe skalieren nicht9 10. 2.RDBMSFunctional Partitioning (Sharding)- Immens hohe Verteilungslogik auf der Applikationsebene- Erfordert abgetrennte Datenbereiche- DenormalisierungVerwendung des RDBMS gegen eigentliches Funktionsdesign10 11. 2.RDBMSTransaktionenAtomicity (Atomaritt):Transaktion wird entweder ganz oder gar nichtausgefhrtConsistency (Konsistenz / Integrittserhaltung):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. 2.RDBMS Garantie der ACID Eigenschaften wirdkomplex Atomicity fordert Verteiltes CommitProtokoll (e.g. 2PC)Alle Nodes mssen sich einig sein Isolation fordert Erhaltung der Locksfr die gesamte Dauer des Protokollsdie gesamte Transaktion darf nicht gestrtwerden durch nebenlufige TransaktionenLeichtgewichtige Transaktionen, groe Netzwerk Roundtrips => Lockerhaltung lnger als Arbeitszeit Skyrocketing Lock Competitions Schwund des Transaktionsdurchsatzes 12 13. 2.RDBMSFeatures: Festes Datenmodell Redundanzvermeidung durch Fremdschlsselbeziehungen Starke Konsistenz Transaktionsmodell GarantienEignung: Finanzprozesse ERP Systeme Systeme mit wenigen BenutzernSchwierigkeiten: Horizontale Scalierung JOINs kosten CPU Power Datenmodel passt nicht immer ins relationale SchemaOne Size does NOT fit all! 13 14. 3.CAP TheoremErik Brewer berlegt 1997 ein Gegenmodel zu ACIDBASE Basically Available, Soft-state, Eventually consistent ACIDBASE 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, JOINs)14 15. 3.CAP TheoremErik Brewer sttzt notwendigkeit vonBASE durch ein TheoremLinear ConsitencyTotale Ordnung aller OperationenAvailibilityJeder Anfrage an einen intakten Node wirbearbeitetPartitiotolerenceFehler bei der Kommunikation im verteiltenSystem werden toleriertBehauptung: nur 2 der 3 Features gleichzeitig erfllbarBewiesen durch Gilbert und Lynch15 16. 3.CAP TheoremAP ClassEs gilt: a) Das System mchte Partiontoleranz erfllen b) Es treten Netzwekfehler auf.Wenn:Das System beantwortet zu diesem Zeitpunkt alle Anfragen (Availibility)Dann:Die Antworten knnen nicht konsistent sein, da keine Einigkeit herscht16 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. 3.CAP TheoremEs gilt: a) Das System mchte Partiontoleranz erfllen b) Es treten Netzwekfehler auf.Wenn:Alle Benutzer des Systems erhalten korrekte und gleiche DatenDann:Das System beantwortet Anfragen solange nicht bis es sich synchronisierthat18 19. 3.CAP TheoremCP ClassR1 W3A B C W2 R2MasterA B C W1 R3A 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 fr 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 APIs(meistens)Verizicht auf SQL, JavaScript, JSON, Views, REST Horizontal scalierbar (Shards) Map/Reduce Paradigma zu parallelen Verarbeitung Replikation zwischen den Schards Partition tolerantAP CPEventual Consistency Write/Read Availabillity BalanceMVCC Update in Place21 22. 4.NoSQL -OverviewKey/Value Store einfache Datenhalter Ein Key, Ein Value, Keine Duplikate Sehr Schnell Verteilter Hash Die Datenbank versteht die Values nichtBLOB Voldemort, Redis, Tokio Cabinet22 23. 5.NoSQL -Overview Key/Value Store key value 6a9b85fd1061e =>#name:#$$!!^^ #firstname:#$$!!^ #birthday:#$$!!^^ #adress:#$$!!^^ 23 24. 5.NoSQL -OverviewColumn-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 rowIDcolumn familyperson person person personperson title name firstname birthdayadressadress 11 12 34 1014 time value Doe John 12.Dec.19085 X-StreetY-Street25 26. 5.NoSQL -OverviewDocument Stores Key Value Store, aber das Value ist strukturiertund von der DB interpretierbar (Document) Datenanfragen nicht nur ber Keys, sondern ber alleDocumentfelder Indexes ber einzelne Documentfelder CouchDB, MongoDB 26 27. 5.NoSQL -OverviewDocument StoreDocumentkeys #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. 6.NoSQL PraxisSchema Design Relational 28 29. 6.NoSQL PraxisSchema Design Denormalisiert(NoSQL Way) Embed bevorzugt ber Reference29 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 fr fast alle Programmiersprachen Query Main und Embeded Objects Markups ($all, $or, $exists, $size, , ) Embeded Javascipt function (){return }30 31. 6.NoSQL PraxisMap/Reduce 31 32. 6.NoSQL PraxisMap/ReduceAlle Wrter in allen Dokumenten zhlenAnzahl pro Wort Ausgeben (e.g. und => 1590, oder => 17)Map FunctionDurchsuche alle Wrter im Dokumentmap = function() { und => {und => {und => {... for (var word in this.text) {count: 1count: 1count: 1 } } }... emit( word , {count : 1});... }}; oder => { oder => {count: 1count: 1 } }32 33. 6.NoSQL PraxisMap/ReduceReduce FunctionDie Ergebnisse aus der Suche Bearbeitenund => 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: 3count: 2 }}33 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 zugegriffenwerdenAP Class: Web 2.0 -Kollektives Blogging, Social Networking Sync Apps fr offline Gerte (Mobiles)- Mobiles Gert und Desktop mit jeweils einer DB Replica Beide: Real Time Analytics /Datawarehousing-Map/Reduce Power mehrer Rechner34 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 zugegriffenwerdenAP Class: Web 2.0 -Kollektives Blogging, Social Networking Sync Apps fr offline Gerte (Mobiles)- Mobiles Gert und Desktop mit jeweils einer DB Replica Beide: Real Time Analytics /Datawarehousing-Map/Reduce Power mehrer Rechner35 36. 6.Zusammenfassung und AusblickReal 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, OReilly, 2010[2]Chodorof, Dirolf, MongoDB: The Difinitive Guide, OReilly, 2010[3]Rick Cattell, Horizontally Scalable Data Stores, 2010[4]Eric Brewer, Cluster-Based Scalable Network Services, 1997[5]Gilber, Lynch, Brewers 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. Quellen[10]MongoDB, On distributed Consistency,http://blog.mongodb.org/post/475279604/on-distributed-consistency-part-1,2010[11]Hendersen, Building Scalable Websites, OReilly, 2006[12]Werner Vogels, Eventually Consistent,http://queue.acm.org/detail.cfm?id=1466448, 200838