NoSQL Please! Wie Web2.0, Big Data und die Cloud neue Datenbanksysteme erfordern und hervorbringen. Datenbank-Stammtisch, 8.

Transkript

1 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. Datenbank-Stammtisch, Prof. Dr. Frank Schönefeld, Geschäftsleitung, T-Systems Multimedia Solutions GmbH

2 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 MySQL Server instances and > 1000 memcaches.) Quelle: 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: Domas Mituzas (Facebook database performance team) 2

3 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. 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. Google verwendet Big Table (eine dreidimensionale, dünnbesetzte KeyValue Map) für Google Earth, Maps, Analytics, Orkut. Linkedin verwendet Voldemort (Big Table x Dynamo Ansatz) für spezielle Speicheranforderungen ihrer Profile. Twitter Nutzer produzieren ca. 4 PByte/a. Scribe schreibt Logs zu Hadoop. Zur People Search wird HBase verwendet. Quelle: how-twitter-uses-nosql.php 3

4 Prolog CAP-Theorem NoSQL Datenmodelle Fazit Big Data The Next Big Thing. Ist das das Web 3.0? Quelle: 4

5 Prolog CAP-Theorem NoSQL Datenmodelle Fazit Big Data The Next Big Thing? Wir betreten die ExaByte Ära (1 ExaByte = oder 2 60 = Bytes) A decade of digital universe growth 7910 Exabytes

6 Prolog CAP-Theorem NoSQL Datenmodelle Fazit Big Data The Next Big Thing? Wir betreten die ExaByte Ära (1 ExaByte = oder 2 60 = 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. Meanwhile, the number of IT professionals in the 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

7 Prolog CAP-Theorem NoSQL Datenmodelle Fazit Probleme und Limitationen von RDBMS. Datenmodell: Die Welt ist keine Tabelle 7

8 Prolog CAP-Theorem NoSQL Datenmodelle Fazit Probleme und Limitationen von RDBMS. Datenmodell: Die Welt ist keine Tabelle Skalierung: und passt auch schlecht in eine hinein (Scale up vs. Scale out). 8

9 Prolog CAP-Theorem NoSQL Datenmodelle Fazit Lösungsansätze von NoSQL: Datenmodell Skalierung Datenmodell Key/Value Systeme Columm Family Systeme Document Stores Map-Reduce Algorithmus Skalierung Consistency Availability Von AICD zu BASE Von Locks zu MVCC Von 2PC zu PAXOS Von Master-Slave zu Gossip Graph Datenbanken Partition Tolerance Sharding Consistent Hashing 9

10 Prolog CAP-Theorem NoSQL Datenmodelle Fazit Gute Links und Literatur: Edlich et.al: NoSQL. Einstieg in die Welt Nichtrelationaler Web 2.0 DB. Hanser Marc Boeker: MongoDB. Sag ja zu NoSQL. entwickler.press Wiki der FH Köln/Campus Gummersbach zu NoSQL Sammlung von Infos zu NoSQL DB. Fundierter Lehrstoff zu Mehrrechner-DB Systemen. CouchDB Einführung 10

11 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. 11

12 Prolog CAP-Theorem NoSQL Datenmodelle Fazit Historie der Datenbanksysteme. Bibliothek von Alexandria. Ca. 300 vor Christus bis ca. 391 nach Christus 12

13 Prolog CAP-Theorem NoSQL Datenmodelle Fazit Historie der Datenbanksysteme. Datenbankenprodukte und Generationen. Hierarchische DBS Netzwerk DBS Relationale DBS OO DBS Dynamo NoSQL DB ORM Objectstore Poet BigTable IMS UDS Codasyl DB Oracle 1977 System/R IBM DB2 MS SQL Server mysql

14 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 Teil 4 Einsatz von Webmedien & Technologien in Unternehmen NoSQL 2.0 Please - Dr. Frank Schönefeld - Prof. Dr. Frank Schönefeld/ T-Systems Multimedia Solutions GmbH

15 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. 15

16 Prolog Das CAP-Theorem NoSQL-Datenmodelle Fazit Das CAP Theorem. Consensus protocols for HA consistency Consistency Enforced consistency Paxos Availability Partition Tolerance Eventual consistency Quelle: J. Chris Anderson/Jan Lehnardt/ Noah Slater: Couch DB The Definitive Guide 16

17 Prolog Das CAP-Theorem NoSQL-Datenmodelle Fazit Lösungen für das Availability Problem. Multiversion Concurrency Control MVCC. WTS RTS WTS: Write Time Stamp 0 Joseph 0 0 Joseph 2 RTS: Read Time Stamp Vorteil: keine Lesesperren T4 Read Joseph = da (max(wts)=0) < 4 Write Maria = Ok, da (max(rts)=2) < 4 0 Joseph 2 4 Maria 4 Im Einsatz bei: CouchDB MySQL (mit InnoDB) T3 Read = Ok, liefert Joseph da (max(wts) < 3) = 0 Write Jesus T3 wird abgebrochen, und neu gestartet, da 3 < max (RTS) = 4 17

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 S3 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. Gossip: Topologieinformationsaustausch ohne Master Im Einsatz bei: Amazon Dynamo weiteren distributierten Filesystemen (GFS, ) 18

19 Prolog Das CAP-Theorem NoSQL-Datenmodelle Fazit Lösungen für das Partition Tolerance Problem. Consistent Hashing mit Hinted Handoff. S5 S4 X X S1 S2 S3 Replikation Ausfall 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. Gossip: Topologieinformationsaustausch ohne Master Im Einsatz bei: Amazon Dynamo weiteren distributierten Filesystemen (GFS, ) 19

20 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: C onsistency: I solation: D urability: B asically available: S oft State: E ventually Consistent:. Atomare Transaktionen Ganz oder gar nicht. Die DB geht von einem konsistenten Zustand in einen anderen konsistenten Zustand über. (Auch: Alle Clients lesen den gleichen, konsistenten Zustand). Eine Transaktion hat den Eindruck, dass ihr die DB alleine gehört (sie nicht durch andere Transaktionen beeinflusst wird). Das Ergebnis einer Transaktion wird unter allen Umständen verteidigt. Mindestens eine Kopie (Replika) stellt den gültigen Zustand dar. Alles fließt. Nach genügend langer Wartezeit, hat sich der konsistente Zustand repliziert. 20

21 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>, } key value Set oder Liste key value Hash (Person) key Name: Marie Datenmanipulation: CRUD Beispiel MapReduce ff. Slides CQL Cassandra Query Language (SQL-like) jedes DBS mit eigener Sprache, kein Standard value value Alter: 34 Vertreter: Redis, Dynamo (eventually consistent) BigTable, Voldemort, Cassandra Memcached (HS-orientierte DB) Im Einsatz bei: Dynamo BigTable Memcached 21

22 Prolog Das CAP-Theorem NoSQL Datenmodelle Fazit Key Value Stores - MapReduce. MapReduce ein einfaches Programmiermodell für verteilte Datenverarbeitung nach Saliya Ekanayake (map ( )) ( ) A list of values mapped into another list of values, which gets reduced into a single value (reduce ( )) Classical Notion of MapReduce in Functional Programming Quelle: 22

23 Prolog Das CAP-Theorem NoSQL Datenmodelle 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: 23

24 Prolog Das CAP-Theorem NoSQL Datenmodelle Fazit Key Value Stores - MapReduce. MapReduce ein einfaches Programmiermodell für verteilte Datenverarbeitung nach Saliya Ekanayake parallel Version 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 (<a, >, <o, >, <p, >, ) The idea of MapReduce in Data Intensive Computing Each input to a map is a list of <key, value> pairs (<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: 24

25 Prolog Das CAP-Theorem NoSQL Datenmodelle 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: 25

26 Prolog Das CAP-Theorem NoSQL Datenmodelle 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: 26

27 Prolog Das CAP-Theorem NoSQL Datenmodelle Fazit Column Family Systeme. Column Family Systeme speichern Sätze spaltenorientiert oder als Super Columns. Datenmodell: Column: Name, Daten, Timestamp SuperColumn: Name, {Column1, Column2, } Datenmanipulation: CRUD in Amazon Simple DB: key Domäne/Keyspace Create Domain key Name: Joseph Alter: 24 Item Name: Maria Alter: 20 Status: Single ColumnFamily: <Key, Column1, Column2, > SuperColumnFamily: <Key, SuperColumn1, > PutAttribute(attribute_name, value) Select target from domain_name where expression; Vertreter: Amazon Simple DB (eventually consistent) HBase, Hypertable Im Einsatz bei: Amazon Simple DB (AWS) HBase 27

28 Prolog Das CAP-Theorem NoSQL Datenmodelle Fazit Document Stores. Document Stores speichern Daten in Form von Dokumenten. key Datenmodell: Domäne/Keyspace Name: Joseph Alter: 24 Item Name: Maria Alter: 20 Status: Single Datenmanipulation: CRUD in MongoDB: db.<collection>.<action>(<parameters>); db.beisp.insert({name: frank, age: 49, hobbies: [ volleyball, beach, DB ]}); action: find, save, update, remove Vertreter: MongoDB CouchDB MongoDB im Einsatz bei: FourSquare (für Geolocation) bit.ly (Userhistory) NY Times (Bildupload, Forms) 28

29 Prolog Das CAP-Theorem NoSQL Datenmodelle Fazit Graph Datenbanken. Graph Datenbanken speichern Daten als Netzwerke verbundener Knoten. Datenmodell: Datenmanipulation: CRUD in neo4j mit dem REST API: POST /node { data} --Knoten anlegen GET /node/123 PUT /node/123/properties { data} DELETE /node/123 Vertreter: neo4j Im Einsatz bei: vorrangig für Geo-Informationssysteme Sones 29

30 Prolog Das CAP-Theorem NoSQL Datenmodelle 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

31 Prolog Das CAP-Theorem NoSQL Datenmodelle 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

32 Prolog Das CAP-Theorem NoSQL Datenmodelle Fazit NoSQL: Nathan Hursts Entscheidungspyramide für NoSQL-Datenbanken. Quelle: NoSQL Please! Prof. Dr. Frank Schönefeld/ T-Systems Multimedia Solutions GmbH 20. Januar

33 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 33

34 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. 34

35 Prolog Das CAP-Theorem NoSQL Datenmodelle Fazit Fazit SQL vs. NoSQL. Quelle: 35

36 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

37 Danke. NoSQL Please Prof. Dr. Frank Schönefeld/ T-Systems Multimedia Solutions GmbH 37

38 Dr. Frank Schönefeld Prokurist, Geschäftsleitung T-Systems Multimedia Solutions T-Systems Multimedia Solutions Riesaer Straße 5 D Dresden Telefon: Telefax: frank.schoenefeld@t-systems.com Web: Blog: Twitter: twitter.com/frank_open Bookmarks: delicious.com/frank_open../praxisleitfadene20 Xing: LinkedIn: Schoenefeld frage@t-systems-mms.com Xing Twitter Facebook Flickr Slideshare Youtube NoSQL Please Prof. Dr. Frank Schönefeld/ T-Systems Multimedia Solutions GmbH 38