Darko Križić. NoSQL Datenbanken

Transkript

1 Darko Križić NoSQL Datenbanken

2 Ihr Referent Darko Križić Chief Technical Officer Enterprise Architecture Java Enterprise EdiCon High Availability ESB (Talend ESB) NoSQL (MongoDB, CouchDB)

3 NoSQL Datenbanken Prinzipien, Technologien und Produkte Darko Krizic

4 01 DefiniCon 02 Produkte und Kategorien 03 Verteiltes Rechnen (ACID/BASE/CAP/PATELC) 04 MapReduce 05 CouchDB

5 Szenario Kunde möchte Anwendung GünsCg Schnell fercg Muss performant sein Hochverfügbar Kunde hat ständig neue Anforderungen

6 Stand % aller Anwendungen nutzen Datenbanken 80% aller Anwendungen nutzen eine relaconale Datenbank Meist Oracle und MySQL JPA und Hibernate JDBC und SQL

7 Implizite Annahmen Daten müssen jederzeit sofort synchronisiert werden Die Datenstrukturen verändern sich nicht Die Hardware funkconiert immer und Netzwerke arbeiten perfekt Menschen machen immer das richcge Weder Upgrade noch Patches werden jemals benöcgt Geplante Ausfälle sind gut für die Seele

8 Was ist NoSQL? Üblicherweise Nicht- relaconal Verteilt Open Source Horizontal skalierbar In der Praxis geboren Häufig Schema- frei Einfach zu replizieren Einfache API Eventuell consistent/ BASE (stai ACID) Unterstützung grosser Datenmengen

9 Gewohnheiten Strikte Konsistenz TransakConen Ad- hoc queries Indexes Zerstört Verfürgbarkeit Deadlocks & nicht skalierbar Aka Dumbass queries Scumbag index covers every column; ignored by planner

10

11 Fakten nosql- database.org Core NoSQL Systems Wide Column Store/ Column Families Document Store Key Value/Tuple Store Graphendatenbanken MulCmodel Soq NoSQL Systems Objektdatenbanken Grid & Cloud Datenbanklösungen XML- Databases MulCvalue Datenbanken Other 150 ImplemenCerungen

12 Key/Value

13 Wide Column Stores

14 Dokumentenorientert

15 Graphendatenbanken

16 Irrtümer des verteilten Rechnens Das Netzwerk ist zuverlässig Es gibt keine Latenz Die Bandbreite ist unendlich Das Netzwerk ist sicher Die Topologie ändert sich nicht Es gibt nur einen Administrator Transportkosten sind kostenlos Das Netzwerk ist homogen

17 ACID Steht für Atomic Consistency IsolaCon Durability Locking à Flaschenhals

18 ACID ACID stellt Konsistenz sicher Auch bei mehreren Instanzen, sehr aufwändig Grenzen bei horizontaler Skalierung Grenzen bei verckaler Skalierung

19 BASE Basic Availability Das System ist quasi ständig verfügbar SoW- state Es ist nicht ständig konsistent Eventual consistency Wird früher oder später konsistent

20 ACID vs. BASE BASE Schwache Konsistenz (veraltete Daten ok) Verfügbarkeit vor allem anderen Best effort Ungefähre Antworten ok Agressiv (OpCmisCsch) Schneller/geringe Latenz ACID Strenge Konsistenz (stets aktuelle Daten) IsolaCon Rund um den commit Verfügbarkeit? KonservaCv (pessimiscsch) Sicherer

21 Anwendungsfälle Online- Shop (Warengruppen, Warenkorb) Check- out (Lagerstand) Chat Forum BASE ACID BASE BASE

22 Aussage zu CAP- Theorem Jeder Knoten in einem System sollte in der Lage sein Entscheidungen zu treffen, die ausschließlich auf dem lokalen Zustand basieren. Wenn man etwas unter großer Last machen muss während gleichzeicg Fehler auqreten und man muss auf die SynchronisaCon warten, hat man verloren. Wenn Skalierbarkeit wichcg ist, wird jeder Algorithmus, der eine Synchronisierung erzwingt, irgendwann zum Flaschenhals werden. Nimm das als gegeben an. Werner Vogels, Amazon CTO and Vice President

23 CAP- Theorem Consistency Alle Clients sehen dieselben Daten Availability Alle Clients sehen alle Daten Par[[on Tolerance Jede ParCCon hat vollständige Daten Wähle 2!

24 Kompromisse bei CAP CA ohne P: Datenbanken mit verteilten TransakConen funkconieren nur, wenn das Netzwerk verfügbar ist CP ohne A: Verfügbarkeit ist keine OpCon! AP ohne C: ReplikaCon kompensiert Ausfälle von Instanzen, Instanzen wissen nicht, ob sie aktuell sind.

25 Erfahrungen mit Amazon Dynamo Daten im Warenkorb (innerhalb 24h) 0,00057% der Zugriffe sahen 2 Versionen 0,00047% der Zugriffe sahen 3 Versionen 0,00009% der Zugriffe sahen 4 Versionen 99,9995% aller Zugriffe erfolgreich (2 Jahre Betrieb) Es gab keine Datenverluste

26 PACELC AlternaCver Ansatz zu CAP PA/EL In case of parccon (P), does the system choose availability (A) or consistency (C) Else (E), does the system choose latency (L) or consistency (C) PC/EC (ACID) PA/EC

27 Cassandra Steckbrief Wide Column Database API: viele Sprachen Query- Methode: Map Reduce Entwickelt in Java Concurrency: Eventuell consistent IniCiert von Facebook Apache Top Level Project hip://cassandra.apache.org

28 Neo4j Steckbrief Graphendatenbank API: Viele Programmiersprachen Protokoll: Java embedded / REST Query Method: SparQL, nacve Java, JRuby ReplikaCon: Master/slave Geschrieben in Java Concurrency: non- block reads, writes locks involved nodes/ relaconships uncl commit ACID möglich

29 Neo4j Beispiel

30 CouchDB Steckbrief DokumentenorienCert API: JSON Zugriff: REST Query Method: Map Reduce ReplikaCon: Master/Master Geschrieben in Erlang Concurrency: MVCC

31 Zusammenfassung Grosse ApplikaConen arbeiten (hauptsächlich) auf BASE- Datenbanken

32 CouchDB Highly concurrent database server Schemafrei, dokumentenoriencert RESTful API Views auf Basis von MapReduce Views generacon Einfache ReplicaCon Unterstützung von BLOBs Couch = Cluster Of Unreliable Commodity Hardware

33 CouchDB Architektur

34 CouchDB Geschichte Damien Katz (Lotus Notes developer bei IBM) MoCvaCon: storage system for large scale object system Bei IBM gekündigt, um CouchDB zu schreiben 2005 begonnen im C++, verworfen und in Erlang Februar 2008: Apache Incubator November 2008: Apache Top Level Januar 2012: Damian Katz verlässt CouchDB Community- basierter Ansatz spricht gegen dynamische Entwicklung CouchDB à CouchBase

35 CouchDB Dokumetenorien[ert DicConary von Daten JSON- Objekte Ein Dokument kann Aiachments haben AutomaCsche Vergabe von IDs Revisionen von Dokumenten

36 CouchDB CRUD Create Retrieve Update Delete à POST /db à GET /db/docid à PUT /db/docid à DELETE /db/docid

37

38

39 Futon

40

41

42

43 MapReduce Entwickelt und patencert von Google Map- FunkCon Reduce- FunkCon

44 Sum(checkout)?

45 Map: emit(checkouts)

46 Sum(checkout)

47 Sum(checkouts)

48 Reduce muss assozia[v sein muss idencsch sein zu

49 Verteilt!

50 Logarithmisches Update

51 Logarithmic update

52

53

54

55

56

57 CouchDB Zugriff aus Java

58

59 Replicator [cket [cketrep

60

61 Fazit CouchDB REST Squid oder Apache als Cache und Load Balancer! Quasi mit jeder Programmiersprache nutzbar Beliebig skalierbar AP nach CAP, mostly consistent Grosse Community

62 MongoDB Steckbrief DokumentenorienCert API: JSON Zugriff: Diverse APIs Query Method: Map Reduce & query language ReplikaCon: Master, Slave & Auto- Sharding Geschrieben in Erlang Concurrency: MVCC

63

64

65

66

67 Fazit Was ist NoSQL Sinnvolle Ergänzung zu klassischen relaconalen Datenbanken Kein Ersatz! Viele ausgereiqe und mächcge Lösungen Geboren in der Praxis Sehr dynamische Landschaq Kein Standard für NoSQL Basiert aber auf Standards, z.b. REST Basiert auf Paiern, z.b. MapReduce Gefahr von Lock- In Unterstützung agile Soqware- Entwicklung

68 Fazit Empfehlung Bewusstsein für CAP- Theorem Prüfen, wo ACID wirklich gebraucht wird z.b. Lagerbestand Alles andere BASE NoSQL- Markt beobachten Verschiedene Kategorien beachten (z.b. Column DB) Stärken erkennen Best- PracCces entwickeln

69 NoSQL Vielen Dank für Ihre Aufmerksamkeit. Ihr Ansprechpartner: Darko Križić Chief Technical Officer Telefon: