NoSQL in transaktionalen Enterprisesystemen

Transkript

1 NoSQL in transaktionalen Enterprisesystemen Version: 1.1 Orientation in Objects GmbH Weinheimer Str Mannheim Wir haben hier nur ein paar Java Clients vor einem Host, wir profitieren nicht von NoSQL in unserer Architektur.. Falsch! Der Vortrag zeigt, dass es auch in klassischen transaktionalen(acid) Architekturszenarien Bedarf und Platz für Optimierung durch nichtrelationale Storages mit Support für ACID- Transaktionen gibt. Konzepte wie Caching, parallele Ausführung oder die Unterstützung von MapReduce-Algorithmen können komplementäre Ansätze von NoSQL-Storages sein, die auch im relational dominierten transaktionalen Umfeld Vorteile erbringen. 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 Einfache Formel NoSQL = Relationale Datenbank - Transaktionen - Normalisierung - Joins - Konsistenz - hartes Schema (+) Skalierung (+) Performance 10 5

6 NoSQL Datenbanken Dokumentenorientierte Datenbanken Graphendatenbanken Key-Value-Stores Diskbasiert RAM- Sortierte Key-Value-Stores Eventually Consistent Stores MultivalueDatenbanken Objektdatenbanken Spaltenorientierte Datenbank 11 NoSQL industrieerprobte Skalierbarkeit Dynamo BigTable 12 6

7 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 13 Probleme mit NoSQL unübersichtlich, große Auswahl sehr anwendungsfall-spezifisch viel Bewegung im Markt Schemalosigkeit (In-) Konsistenz von Daten 14 7

8 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! 15 Verfügbarkeit Client Client Client 1. write 2.read 3. read Storage Storage Storage 1.1synchronize 16 8

9 Konsistenz Client Client Client 1.write 3. read 2. write Storage Storage Storage 1.1 synchronize 2.1 synchronize 17 Partitionstoleranz Client Client Client 1.write 3. read 2. write Storage Storage Storage 1.1 synchronize 2.1 synchronize 18 9

10 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). 19 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

11 Eventually Consistent Konsequenzen? Strong consistency: ACID (Atomicity, Consistency, Isolation, Durability) Weak consistency: BASE (Basically Available, Soft-state, Eventual consistency) Availability first = BASE vs. ACID? 21 Gliederung Transaktionale Storages, NoSQL und das CAP-Theorem Transaktionale NoSQL-Szenarien Fallstudien 22 11

12 These NOSQL BASE- Storages Datenmenge Scale in NOSQL CA-Storages klassische CA-Storages Durchsatz/Verfügbarkeit 23 These Relationale Datenbanken skalieren in OO- Entwicklungsszenarien nicht mehr ausreichend. Warum? 24 12

13 Objektrelationale Unverträglichkeit (Impedance Mismatch) Objektorientierte Sicht JDO Objektrelationales Mapping (ORM) EJB (<= 2.1) Hibernate JPA JDBC Relationale Sicht 25 Aufspalten des Aggregats auf Zeilen von Tabellen orders addresses order lines 26 13

14 These Relationale Datenbanken skalieren in OO- Entwicklungsszenarien nicht mehr ausreichend. Warum? Impedanzmismatch => Joins, viele lesende Transaktionen 27 Große Clientanzahl/Verteilte Transaktionen EIS EIS 28 14

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

16 server (not dead) server EIS EIS 31 Gliederung Transaktionale Storages, NoSQL und das CAP-Theorem Transaktionale NoSQL-Szenarien Fallstudien 32 16

17 NoSQL CA-Datenbanken Dokumentenorientierte Datenbanken Graphendatenbanken Key-Value-Stores Diskbasiert RAM- Sortierte Key-Value-Stores Eventually Consistent Stores MultivalueDatenbanken Objektdatenbanken Spaltenorientierte Datenbank 33 Graph-DB Konzept Node ID 12 Node ID 47 username jdoe username smith birthday Node ID

18 Kernelemente Fokussiert auf Beziehungen verschiedene Abfragemöglichkeiten verwendet ACID Skalierung begrenzt 35 Die beliebtesten Graph-Datenbanken 7% 7% 9% Neo4j OrientDB Titan Sonstige 77% Quelle: Stand: Januar

19 Graphen bestehen aus Knoten Beziehungen Eigenschaften hat angestellt am: Dieter Develop Person gehalt: 1000 steuer: IV Labels alter:48 geschlecht: M Bernd Boss Person gehört geführt gegründet: 1998 Sitz: Mannheim arbeitet bei seit: OIO Firma 37 Suchen von Mustern 38 19

20 Key-Value Systeme - Vertreter Redis Amazon Dynamo und S3 Voldemort Riak Berkeley DB MemcacheDB 39 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

21 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 41 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 42 21

22 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 3 43 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 44 22

23 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 45 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 46 23

24 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 47 Functional Caching UI 0./5. call 6. get 1. get 2. call Function Modul 48 24

25 Functional Caching 6. get UI 0./5. call 1. get 2. call 4.1 invalidate Function Modul 4. update Secondary Storage Function Modul 2.X query 49 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 50 25

26 Distributed I UI 0./4. Query 5. put 2. get 3./6. load/store Secondary Store 51 Distributed II Load/Store Secondary Store 52 26

27 Distributed Data Grid Secondary Store 53 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 54 27

28 Hashing Algorithmus 55 Distributed Execution Konzept update query Load/Store Secondary Store 56 28

29 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 57 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(); 58 29

30 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 59 Distributed Execution Webscaling key = SessionID Secondary Store 60 30

31 Distributed Execution Layered Update key = SessionID V2 V2 V2 V2 V2 V2 Secondary Store 61?? Fragen??? Orientation Objects GmbH Weinheimer Str Mannheim info@oio.de?? 31

32 Folien zum Vortrag Die Folien werden auf unserer Website veröffentlicht 63 Kommende Orientierungspunkte Spring Boot Freitag, 27. März :00-18:00 Uhr Pipelines zeichnen ist nicht schwer, Pipelines bauen dagegen... Freitag, 24. April :00-18:00 Uhr 32

33 Vielen Dank für ihre Aufmerksamkeit! Orientation in Objects GmbH Weinheimer Str Mannheim TODO Wrap up Impedanz mistmatch - Graphendatenbanken? - Neu (Query alngugage) - wenig anbieter - + Modellierung - Aldtanbestände 2nd level - Naiver Ansatz - Begrenzter Nutzen - 3 Probleme - Functional - Distributed Execution 66 33