NoSQL-Einsatzszenarien in transaktionalen Enterprise-Systemen - OIO-Die Java … · 2020. 8....

11.05.2015

1

Orientation in Objects GmbH

Weinheimer Str. 6868309 Mannheim

[email protected]:

NoSQL-Einsatzszenarien in transaktionalen

Enterprise-Systemen

„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 nicht relationale 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.“

1.1

NoSQL in transaktionalen Enterprisesystemen© 2015 Orientation in Objects GmbH

Gliederung

• Transaktionale Storages, NoSQL und das CAP-Theorem

• Transaktionale NoSQL-Szenarien

• Fallstudien

2

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

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

11.05.2015

4


These

7

Relationale Datenbanken skalieren in OO-Entwicklungsszenarien nicht mehr ausreichend.

Warum?

Was tun ?


SQL

NoSQL = kein SQL mehr?

8

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

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

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

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

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

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

11.05.2015

11


Gliederung



• Fallstudien

21


These

22

Datenm

enge

Durchsatz/Verfügbarkeit

NOSQLBASE- Storages

NOSQLCA-StoragesScale in

klassischeCA-Storages

11.05.2015

12


These

23


Warum?


Objektrelationale Unverträglichkeit (ImpedanceMismatch)

24

ObjektorientierteSicht

RelationaleSicht

JDBC

JDO

EJB (<= 2.1)

HibernateJPA

ObjektrelationalesMapping (ORM)

11.05.2015

13


Aufspalten des Aggregats auf Zeilen von Tabellen

25

orders

addresses

order lines


These

26


Warum?Impedanzmismatch => Joins, viele lesende Transaktionen

11.05.2015

14


Große Clientanzahl/Verteilte Transaktionen

27

EIS EIS


Große Clientanzahl/Verteilte Transaktionen

28

EIS EIS

11.05.2015

15


These

29


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


Applicationserver (not dead)

30

Applicationserver

EIS EIS

11.05.2015

16


Key-Value Systeme - Vertreter

• Redis

• Amazon Dynamo und S3

• Voldemort

• Riak

• Berkeley DB

• MemcacheDB

31


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

32

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

11.05.2015

17


Java EE 7 Services

33

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


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

34

11.05.2015

18


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)

35

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


Gliederung



• Fallstudien

36

11.05.2015

19


JCACHE und Java EE Clustering

37

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


Architektur by Peer to Peer

38

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

Vollst. Replikation

Distibuted Hash Table

Ehcache x -

Hazelcast - x

Infinispan x x

11.05.2015

20


Architektur by Client Server

Ehcache Hazelcast Infinispan

HardwareKonfiguration in Client-Server Mode

x - -

Elasticdeployment in Client-Server Mode

- x x

39


Zusätzliche Features …

40

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 -

11.05.2015

21


OR/M Integration

41

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


Caching – Second Level Cache

42

Cache Concurrency Strategie Query cache

Cache Provider

Class Cache Region

Collection Cache Region

„ „ UpdateTimestamp

Query Cache Region

Physical Cache

Second-Level Cache

11.05.2015

22


Caching – Second Level Cache

43

EntityManager

EntityManager

1Lvl Cache

1Lvl Cache

• Applikationsweiter Cache

• Provider spezifische Implementierung

• clusterfähig

• Evt. Dateiauslagerung

2nd Level Cache

Datenbank

Filesystem


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

11.05.2015

23


Query Cache

45

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


Functional Caching

46

Function Modul

2. call

JEE

Application

CacheCache

Data Access

UI

1. get6. get

0./5. call

11.05.2015

24


Functional Caching

47

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


Functional Caching

48

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

11.05.2015

25


Distributed Cache I

49

JEE

Application

CacheCache

Data Access

UI

2. get5. put

0./4. Query

JEE

CacheCache

• Secondary Store

3./6. load/Store

JEE

CacheCache


JVM

CacheCache

Distributed Cache II

50

Load/Store

JVM

CacheCache

• Secondary Store

JVMApplication

Data Access

11.05.2015

26


Distributed Cache – Data Grid

51

• Secondary Store

JVM

CacheCache

JVM

CacheCache

JVM

ApplicationApplication

Data Access

JVM

CacheCache

JVM

CacheCache


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

52

11.05.2015

27


Hashing Algorithmus

53


Distributed Cache Execution Konzept

54

Load/Store

JVM

CacheCache

• Secondary Store

JVM

CacheCache

JVMApplication

Data Access

queryupdate

11.05.2015

28


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

55


Execution on Key Owner example(Hazelcast)

56

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

11.05.2015

29


Distributed Cache Execution als LB Strategy

57

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

58

• 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

11.05.2015

30


Distributed Execution Layered Update – key = SessionID

59

• 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

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

schulung.htm

• Schulung: Java im Web für Architekten• http://www.oio.de/seminar/entscheider/training-architekten-schulung-

java-seminar-web-kurs.htm

60

11.05.2015

31



[email protected]

??

? ?

????

Fragen ?

61



[email protected]

Vielen Dank für ihre Aufmerksamkeit !

NoSQL-Einsatzszenarien in transaktionalen Enterprise-Systemen - OIO-Die Java … · 2020. 8....

Documents

Transcript of NoSQL-Einsatzszenarien in transaktionalen Enterprise-Systemen - OIO-Die Java … · 2020. 8....