NoSQL-Einsatzszenarien in der transaktionalen Enterprise-IT · Caching, parallele Ausführung oder die Unterstützung von MapReduce- ... JCACHE und Java EE Clustering 38 JEE Application

26.05.2015

1

Orientation in Objects GmbH

Weinheimer Str. 6868309 Mannheim

[email protected]:

NoSQL-Einsatzszenarien in der transaktionalen

Enterprise-IT

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 Optimierungsoptionen bieten.

1.1

NoSQL in transaktionalen Enterprisesystemen© 2015 Orientation in Objects GmbH

Gliederung

• Transaktionale Storages, NoSQL und das CAP-Theorem

• Transaktionale NoSQL-Szenarien

• Fallstudien

2

26.05.2015

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 Transak tionen

• Standardisiert: Im Kern sind alle relationalen DBs sehr ähnlich– SQL, ...– einer der Erfolgsgaranten

• Fremdschlüsselbeziehungen, referentielle Integrität, Joins, Indexierung, Trigger, Views, ...

4

26.05.2015

3


Was sind mögliche Probleme von klassischen Enterprise-Storages?

5

Big Data (Bewegungsdaten)

Mobile Frontend-Anbindung

Performance

Skalierung


Scale-in vs. Scale-out

6

!?!?

Zisch ...

Vertikal skalieren Horizontal skalieren

26.05.2015

4


These

7

Relationale Datenbanken skalieren in OO-Entwicklungsszenarien nicht mehr ausreichend.

Warum?

Was tun ?


SQL

NoSQL = kein SQL mehr?

8

26.05.2015

5


Nicht nur SQL!

9

NoSQLNot only SQLNot only SQL


NoSQL Datenbanken

• Dokumentenorientierte Datenbanken

• Graphendatenbanken

• Key-Value-Stores– Diskbasiert– RAM-Cache– Sortierte Key-Value-Stores

• Eventually Consistent Stores

• MultivalueDatenbanken

• Objektdatenbanken

• Spaltenorientierte Datenbank

10

26.05.2015

6


NoSQL – industrieerprobte Skalierbarkeit

11

Dynamo

BigTable


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

26.05.2015

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)

14

C

A P

Consistency(Konsistenz)

Availability(Verfügbarkeit)

Partition Tolerance(Partitionstoleranz)

Nur zwei der Eigenschaften können gleichzeitig erfü llt sein, nicht alle drei!

26.05.2015

8


Verfügbarkeit

15

Client

Storage

1. write

Client

Storage

2.read

Client

Storage

3. read

1.1synchronize


Konsistenz

16

Client

Storage

1.write

Client

Storage

3. read

Client

Storage

2. write

1.1 synchronize 2.1 synchronize

26.05.2015

9


Partitionstoleranz

17

Client

Storage

1.write

Client

Storage

3. read

Client

Storage

2. write

1.1 synchronize 2.1 synchronize


Konsistenz

18

C

A P

Strikte Konsistenz, wenn sie sofort

sichergestellt ist (ACID).

Oder gewisses Zeitfenster der

Inkonsistenz (BASE).

Alle Knoten sehen zur gleichen Zeit die gleichen Daten.

26.05.2015

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)

19

Message,12:07Message,13:12

Message,12:07Message,13:12

Message,12:07

Neue Nachricht wird um 13:12 geschrieben

Lesezugriff Client 1 Client 2 Client 3

Knoten 1-3


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

26.05.2015

11


Gliederung



• Fallstudien

21


These

22

Datenm

enge

Durchsatz/Verfügbarkeit

NOSQLBASE- Storages

NOSQLCA-StoragesScale in

klassischeCA-Storages

26.05.2015

12


These

23


Warum?


Objektrelationale Unverträglichkeit (ImpedanceMismatch)

24

ObjektorientierteSicht

RelationaleSicht

JDBC

JDO

EJB (<= 2.1)

HibernateJPA

ObjektrelationalesMapping (ORM)

26.05.2015

13


Aufspalten des Aggregats auf Zeilen von Tabellen

25

orders

addresses

order lines


These

26


Warum?Impedanzmismatch => Joins, viele lesende Transaktionen

26.05.2015

14


Große Clientanzahl/Verteilte Transaktionen

27

EIS EIS


Große Clientanzahl/Verteilte Transaktionen

28

EIS EIS

26.05.2015

15


These

29


Warum?Impedanzmismatch => Joins, viele lesende TransaktionenGroße Anzahl von ClientsLange (verteilte) Transaktionen


Applicationserver (not dead)

30

Applicationserver

EIS EIS

26.05.2015

16


NoSQL Datenbanken

• Dokumentenorientierte Datenbanken

• Graphendatenbanken

• Key-Value-Stores– Diskbasiert– RAM-Cache– 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

26.05.2015

17


Die beliebtesten Key-Value-Stores

38%

26%

8%

6%

5%

3%

3% 2%2% 1% 1%

5% Redis Memcached Riak Ehcache DynamoDB Berkeley DB SimpleDB Hazelcast Coherence Oracle NoSQL Infinispan Sonstige

33

Quelle: http://db-engines.com, Stand: Januar 2014


Java EE 7 Services

34

Java EE

JTA/JTS/JCA

CDI/Beanvalidation

Java Mail ConcurrencyUtils

JAX-RS

JPA

JMS

JNDI

JAXP

Websocket

JBatch

JDBC

JAFJAX-WSSAAJ CommonAnnotations

JAXB

JAAS/JACC/JSR196

EnterpriseApplication

26.05.2015

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 d es 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)

36

Servlet

Node 1

JSF

Node 3

EJB

Node 2

AppserverAppserverJSR 107

Node 1

JSR 107

Node 3

JSR 107

Node 2

Data GridData Grid

RDBMS

26.05.2015

19


Gliederung



• Fallstudien

37


JCACHE und Java EE Clustering

38

JEE

Application

CacheCache

Data Access

UI

1. get5. get

0./4. Query

JEE

Application

CacheCache

Data Access

UI

1.x Store A1 2. Read A

0. Update

• Secondary Store

26.05.2015

20


Architektur by Peer to Peer

39

• Netzwerkprotokolle– JGroups: Infinispan, Ehcache– UDP Multicast: bestandteil von Jgroups, standalone in Hazelcast– RMI: Ehcache– JMS: Ehcahe, Infinispan Near cache Invalidation

Vollst. Replikation

Distributed Hash Table

Ehcache x -

Hazelcast - x

Infinispan x x


Architektur by Client Server

Ehcache Hazelcast Infinispan

HardwareKonfiguration in Client-Server Mode

x - -

Elasticdeployment in Client-Server Mode

- x x

40

26.05.2015

21


Zusätzliche Features …

41

Ehcache Hazelcast Infinispan

Off-Heap Memory x x -

Persistent Caches x - -

Full-Text Search x - x

WAN Replication x x ???

GUI Tools x x -

JMX Management x x x

Messaging andProcessing

- x -


OR/M Integration

42

Java Virtual Machine

Anwendung

Transient

Transient

TransientTransient

Transient

PersistenceManager

1.Level Cache

Connection

DB

InstanzInstanz

Instanz

2.Level Cache

Entity Cache

InstanzInstanz

InstanzInstanz

QueryFacility

Transaction

QueryCache

TimestampCache

26.05.2015

22


Query Cache

43

Query Cache

TimestampID VORNAME NAME

1 Thorsten Maier

2 Ben Bartho

25 Tobias Maier

Applikation

Key:select * from Person where NAME= ‚MAIER‘

Value: 1, 25 - 18:12.2014 15:14:45:01

from Person p where p.name = :name


Query Cache

44

Query Cache

TimestampID VORNAME NAME

1 Thorsten Maier

2 Ben Bartho

25 Tobias Maier

Applikation

Key:select * from Person where NAME= ‚MAIER‘

Value: 1, 25 - 18:12.2014 15:14:45:01

from Person p where p.name = :name

18:12:2014 15:45:54:13 - Person

Update Person

Check for updates

ID VORNAME NAME

1 Thorsten Maier

2 Ben Bartho

25 Tobias KieningerUpdate

26.05.2015

23


Functional Caching

45

Function Modul

2. call

JEE

Application

CacheCache

Data Access

UI

1. get6. get

0./5. call


Functional Caching

46

Function Modul

2. call

JEE

Application

CacheCache

Data Access

UI

1. get6. get

0./5. call

SecondaryStorage

Function Modul

4. update

2.X query

4.1 invalidate

26.05.2015

24


Functional Caching

47

Modul B

0.1 /5.1 call

JEE

Application

CacheCache

Data Access

UI

1. get6. get

0./5. call

SecondaryStorage

2.X query/update

Modul A

2.call


Distributed Cache I

48

JEE

Application

CacheCache

Data Access

UI

2. get5. put

0./4. Query

JEE

CacheCache

• Secondary Store

3./6. load/Store

JEE

CacheCache

26.05.2015

25


JVM

CacheCache

Distributed Cache II

49

Load/Store

JVM

CacheCache

• Secondary Store

JVMApplication

Data Access


Distributed Cache – Data Grid

50

• Secondary Store

JVM

CacheCache

JVM

CacheCache

JVM

ApplicationApplication

Data Access

JVM

CacheCache

JVM

CacheCache

26.05.2015

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 Cache Execution Konzept

52

Load/Store

JVM

CacheCache

• Secondary Store

JVM

CacheCache

JVMApplication

Data Access

queryupdate

26.05.2015

27


Distributed Cache 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)

54

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();

26.05.2015

28


Distributed Cache Execution als LB Strategy

55

Distributed Cache

Node1

Node 2

lock 1 | lock 1 | lock 2 | lock 2 |

lock 3 | lock 3 | lock 4 | lock 4 | lock 5 | lock 5 |

autodetection DB

Weblayer

command

submitToKeyOwner(lock 1)

Die Ausführung erfolgt auf den Knoten welcher den Key hält


Distributed Execution Webscaling – key = SessionID

56

• Secondary Store

JVM

CacheCache

JVM

CacheCache

JVM

CacheCache

JVM

CacheCache

JEE

Application

Data Access

JEE

Application

Data Access

JEE

Application

Data Access

JEE

Application

Data Access

JEE

Application

Data Access

JEE

Application

Data Access

JEE

Application

Data Access

JEE

Application

Data Access

JEE

Application

Data Access

JEE

Application

Data Access

JEE

Application

Data Access

JEE

Application

Data Access

JEE

Application

Data Access

JEE

Application

Data Access

JEE

Application

Data Access

JEE

Application

Data Access

JEE

Application

Data Access

JEE

Application

Data Access

26.05.2015

29


Distributed Execution Layered Update – key = SessionID

57

• Secondary Store

JVM

CacheCache

JVM

CacheCache

JVM

CacheCache

JVM

CacheCache

JEE

Application

Data Access

JEE

Application

Data Access

JEE

Application

Data Access

JEE

Application

Data Access

JEE

Application

Data Access

JEE

Application

Data Access

JEEJEE


Data AccessData Access

JEEJEE



JEEJEE



JEEJEE



JEEJEE



JEEJEE



JEE

Application V2

Data Access

JEE

Application V2

Data Access

JEE

Application V2

Data Access

JEE

Application V2

Data Access

JEE

Application V2

Data Access

JEE

Application V2

Data Access


Mehr von OIO zum Thema…

• Schulung: NoSQL mit Java im Überblick – http://www.oio.de/seminar/entscheider/training-nosql-schulung-

datenbank-seminar-einfuehrung-kurs.htm

• Schulung: Java Persistence Performance Tuning (Datenbank Performance)– http://www.oio.de/seminar/java/training-datenbank-kurs-performance-

schulung.htm

58

26.05.2015

30



[email protected]

??

? ?

????

Fragen ?

59



[email protected]

Vielen Dank für ihre Aufmerksamkeit !

Documents

NoSQL-Einsatzszenarien in der transaktionalen Enterprise-IT · Caching, parallele Ausführung oder die Unterstützung von MapReduce- ... JCACHE und Java EE Clustering 38 JEE Application