NoSQL-Einsatzszenarien in der transaktionalen Enterprise-IT

Transkript

1 NoSQL-Einsatzszenarien in der transaktionalen Enterprise-IT Version: 1.1 Wir haben hier nur ein in Java implementierte Frontends vor einer hostbasierten Businesslogic, wir profitieren nicht von NoSQL in unserer Architektur.' - Falsch! Die Session demonstriert Szenarien in denen auch in klassischen transaktionalen(acid) Architekturen Bedarf und Platz für Optimierung durch nichtrelationale Storages mit Support für ACID-Transaktionen besteht. Caching, parallele Ausführung oder die Unterstützung von MapReduce- Algorithmen werden als komplementäre Konzepte von NoSQL-Storages gezeigt, die auch im relational dominierten transaktionalen Umfeld Orientation in Objects GmbH Optimierungsoptionen bieten. Weinheimer Str Mannheim info@oio.de Gliederung Transaktionale Storages, NoSQL und das CAP-Theorem Transaktionale NoSQL-Szenarien Fallstudien 2 1

2 Klassische Enterprise-Vertreter 3 Relationale Datenbanken (RDBMS) Organisation von Daten in zweidimensionalen Tabellen (Arrays) zeilenweise Speichern der Daten eindeutiger Primärschlüssel je Zeile einheitliche Datentypen in Zellen einer Spalte, jede Spalte hat eindeutigen Namen (Schema) Kontrollieren von parallelen Zugriffen über Transaktionen Standardisiert: Im Kern sind alle relationalen DBs sehr ähnlich SQL,... einer der Erfolgsgaranten Fremdschlüsselbeziehungen, referentielle Integrität, Joins, Indexierung, Trigger, Views,

3 Was sind mögliche Probleme von klassischen Enterprise-Storages? Big Data (Bewegungsdaten) Performance Skalierung Mobile Frontend-Anbindung 5 Scale-in vs. Scale-out!?!? Zisch... Vertikal skalieren Horizontal skalieren 6 3

4 These Relationale Datenbanken skalieren in OO- Entwicklungsszenarien nicht mehr ausreichend. Warum? Was tun? 7 NoSQL = kein SQL mehr? SQL 8 4

5 Nicht nur SQL! Not only NoSQL 9 NoSQL Datenbanken Dokumentenorientierte Datenbanken Graphendatenbanken Key-Value-Stores Diskbasiert RAM- Sortierte Key-Value-Stores Eventually Consistent Stores MultivalueDatenbanken Objektdatenbanken Spaltenorientierte Datenbank 10 5

6 NoSQL industrieerprobte Skalierbarkeit Dynamo BigTable 11 Nachteile Vielfalt, kein gemeinsamer Standard wie SQL Fehlendes Know-How Schwaches/spezifisches Tooling Im Gegensatz zu SQL Eingeschränkte Querying-Möglichkeiten (Ad-hoc fixing?) Spezifische Reporting-Möglichkeiten (Ad-hoc reporting?) Datenmigration kann schwieriger sein Unterschiedliche Technologien Unterschiedliche Konzepte Export-Funktionen unterschiedlich stark 12 6

7 Probleme mit NoSQL unübersichtlich, große Auswahl sehr anwendungsfall-spezifisch viel Bewegung im Markt Schemalosigkeit (In-) Konsistenz von Daten 13 CAP Theorem von Eric Brewer (2000) Consistency (Konsistenz) C A P Availability (Verfügbarkeit) Partition Tolerance (Partitionstoleranz) Nur zwei der Eigenschaften können gleichzeitig erfüllt sein, nicht alle drei! 14 7

8 Verfügbarkeit Client Client Client 1. write 2.read 3. read Storage Storage Storage 1.1synchronize 15 Konsistenz Client Client Client 1.write 3. read 2. write Storage Storage Storage 1.1 synchronize 2.1 synchronize 16 8

9 Partitionstoleranz Client Client Client 1.write 3. read 2. write Storage Storage Storage 1.1 synchronize 2.1 synchronize 17 Konsistenz C Alle Knoten sehen zur gleichen Zeit die gleichen Daten. A P Strikte Konsistenz, wenn sie sofort sichergestellt ist (ACID). Oder gewisses Zeitfenster der Inkonsistenz (BASE). 18 9

10 Eventually Consistence Daten sind irgendwann konsistent geschrieben Bis dahin liefern Lesezugriffe nur eventuell konsistente Daten Verwendung in NoSQL Datenbanken Absichtlicher Verstoss gegen ACID (Atomarität, Konsistenz, Isoliertheit und Dauerhaftigkeit) Neue Nachricht wird um 13:12 geschrieben Knoten 1-3 Message,12:07 Message,12:07 Message,13:12 Message,12:07 Message,13:12 Lesezugriff Client 1 Client 2 Client 3 19 Eventually Consistent Konsequenzen? Strong consistency: ACID (Atomicity, Consistency, Isolation, Durability) Weak consistency: BASE (Basically Available, Soft-state, Eventual consistency) Availability first = BASE vs. ACID? 20 10

11 Gliederung Transaktionale Storages, NoSQL und das CAP-Theorem Transaktionale NoSQL-Szenarien Fallstudien 21 These NOSQL BASE- Storages Datenmenge Scale in NOSQL CA-Storages klassische CA-Storages Durchsatz/Verfügbarkeit 22 11

12 These Relationale Datenbanken skalieren in OO- Entwicklungsszenarien nicht mehr ausreichend. Warum? 23 Objektrelationale Unverträglichkeit (Impedance Mismatch) Objektorientierte Sicht JDO Objektrelationales Mapping (ORM) EJB (<= 2.1) Hibernate JPA JDBC Relationale Sicht 24 12

13 Aufspalten des Aggregats auf Zeilen von Tabellen orders addresses order lines 25 These Relationale Datenbanken skalieren in OO- Entwicklungsszenarien nicht mehr ausreichend. Warum? Impedanzmismatch => Joins, viele lesende Transaktionen 26 13

14 Große Clientanzahl/Verteilte Transaktionen EIS EIS 27 Große Clientanzahl/Verteilte Transaktionen EIS EIS 28 14

15 These Relationale Datenbanken skalieren in OO- Entwicklungsszenarien nicht mehr ausreichend. Warum? Impedanzmismatch => Joins, viele lesende Transaktionen Große Anzahl von Clients Lange (verteilte) Transaktionen 29 server (not dead) server EIS EIS 30 15

16 NoSQL Datenbanken Dokumentenorientierte Datenbanken Graphendatenbanken Key-Value-Stores Diskbasiert RAM- Sortierte Key-Value-Stores Eventually Consistent Stores MultivalueDatenbanken Objektdatenbanken Spaltenorientierte Datenbank 31 Key-Value Systeme - Vertreter Redis Amazon Dynamo und S3 Voldemort Riak Berkeley DB MemcacheDB 32 16

17 Die beliebtesten Key-Value-Stores 2% 1% 1% 3% 2% 3% 5% Redis Memcached Riak 5% 38% Ehcache DynamoDB 6% 8% Berkeley DB SimpleDB Hazelcast Coherence Oracle NoSQL Infinispan 26% Sonstige Quelle: Stand: Januar Java EE 7 Services Java EE JTA/JTS/ JCA CDI/ Beanvalidation Java Mail Concurrency Utils JAX-RS JPA JBatch JMS Websocket JNDI Enterprise JAAS/JACC /JSR196 JAXP JDBC SAAJ Common Annotations JAX-WS JAXB JAF 34 17

18 Java EE Middleware strenge Spezifikation einer Softwarearchitektur transaktionsbasierte Ausführung von Java-Komponenten auf transkaktionsbasiertem Konzept beruhende Teilstandards JTA/JCA/JPA/JMS/JDBC Horizontale Skalierbarkeit der Anfragen innerhalb des Lösungskonzepts für High Availability garantierte Antwortzeiten machbar Ausfall von Knoten kompensierbar (insbesondere gedacht für Web-Anwendungen) Skalierung der Datenmenge problematisch 35 Elastic Data Grid für Java EE Niedrige Latenzzeit RAM 100fach schneller als Disk Horizontal skalierbar Elastisch Knoten können kontrolliert ein/ausgeschaltet werden optionaler ACID Support Read Commited/Repeatable Read Standardisiertes API JSR 107(347) Appserver Servlet Data Grid JSR 107 EJB Node 1 JSR 107 Node 1 Node 2 JSF Node 2 Node 3 JSR 107 RDBMS Node

19 Gliederung Transaktionale Storages, NoSQL und das CAP-Theorem Transaktionale NoSQL-Szenarien Fallstudien 37 JCACHE und Java EE Clustering UI 0./4. Query UI 0. Update 5. get 1. get 2. Read A 1.x Store A1 Secondary Store 38 19

20 Architektur by Peer to Peer Vollst. Replikation Ehcache x - Hazelcast - x Infinispan x x Distributed Hash Table Netzwerkprotokolle JGroups: Infinispan, Ehcache UDP Multicast: bestandteil von Jgroups, standalone in Hazelcast RMI: Ehcache JMS: Ehcahe, Infinispan Near cache Invalidation 39 Architektur by Client Server Hardware Konfiguration in Client-Server Mode Elastic deployment in Client-Server Mode Ehcache Hazelcast Infinispan x x x 40 20

21 Zusätzliche Features Ehcache Hazelcast Infinispan Off-Heap Memory x x - Persistent s x - - Full-Text Search x - x WAN Replication x x??? GUI Tools x x - JMX Management x x x Messaging and Processing - x - 41 OR/M Integration Java Virtual Machine Anwendung Transient Transient Transient Transient Transient PersistenceManager 1.Level Transaction Instanz Instanz Instanz 2.Level Connection QueryFacility DB Entity Instanz Instanz Instanz Instanz Query Timestamp 42 21

22 Query Applikation from Person p where p.name = :name Query Key:select * from Person where NAME= MAIER Value: 1, 25-18: :14:45:01 ID VORNAME NAME 1 Thorsten Maier 2 Ben Bartho 25 Tobias Maier Timestamp 43 Query Applikation from Person p where p.name = :name Query Key:select * from Person where NAME= MAIER Update Person Value: 1, 25-18: :14:45:01 ID VORNAME NAME 1 Thorsten Maier 2 Ben Bartho 25 Tobias Maier Kieninger Update Check for updates Timestamp 18:12: :45:54:13 - Person 44 22

23 Functional Caching UI 0./5. call 6. get 1. get 2. call Function Modul 45 Functional Caching UI 0./5. call 4.1 invalidate 6. get 1. get 2. call Function Modul 4. update Secondary Storage Function Modul 2.X query 46 23

24 Functional Caching UI 0./5. call 0.1 /5.1 call 6. get 1. get 2.call Secondary Storage Modul A Modul B 2.X query/update 47 Distributed I UI 0./4. Query 5. put 2. get 3./6. load/store Secondary Store 48 24

25 Distributed II Load/Store Secondary Store 49 Distributed Data Grid Secondary Store 50 25

26 Hashing Algorithmus z.b. basierend auf consistent hashing /Amazon Dynamo Paper Key Space in mehreren Segmenten(Anzahl Segmente ist konfigurierbar) Jedes Hash Segment ist gemapped auf eine Menge von Knoten(owners) Reihenfolge ist wichtig. Primary owner hat spezielle Aufgaben bei vielen Operationen(z.B: Locking) Andere Knoten heißen backup owners Ausgleich der Anzahl Segmente auf den Knoten Minimierung der Anzahl der Segmente, die sich bewegen müssen falls: Neuer Knoten zum Cluster hinzukommt Bestehender Knoten Cluster verlässt 51 Distributed Execution Konzept update query Load/Store Secondary Store 52 26

27 Distributed Execution Konzept Execution Code (Callable). auf einem a spezifischen explizit gewählten cluster knoten Anwendungsspezifische Algorithmik auf dem cluster knoten dem der Key zugeordnet ist (with lockid) datenlokale Verarbeitung auf einem vom cache gewählten cluster knoten (without lockid) resourcenoptimale Verarbeitung auf allen Knoten bzw. einem Subset Massenverarbeitung 53 Execution on Key Owner example(hazelcast) Callable<String> task = new Command(input); HazelcastInstance hz = Hazelcast.newHazelcastInstance(); IExecutorService executorservice = hz.getexecutorservice("default"); Future<String> future = executorservice.submittokeyowner(task, key); String commandresult = future.get(); 54 27

28 Distributed Execution als LB Strategy Distributed Weblayer command submittokeyowner (lock 1) Node1 lock 1 lock 2 autodetection DB Die Ausführung erfolgt auf den Knoten welcher den Key hält Node 2 lock 3 lock 4 lock 5 55 Distributed Execution Webscaling key = SessionID Secondary Store 56 28

29 Distributed Execution Layered Update key = SessionID V2 V2 V2 V2 V2 V2 Secondary Store 57 Mehr von OIO zum Thema Schulung: NoSQL mit Java im Überblick Schulung: Java Persistence Performance Tuning (Datenbank Performance)

30 ?? Fragen??? Orientation Objects GmbH Weinheimer Str Mannheim 59 Vielen Dank für ihre Aufmerksamkeit! Orientation in Objects GmbH Weinheimer Str Mannheim 30