NoSQL-Einsatzszenarien in der transaktionalen …...NoSQL-Einsatzszenarien in der transaktionalen Enterprise-IT Orientation in Objects GmbH Weinheimer Str. 68 68309 Mannheim Version:

NoSQL-Einsatzszenarien in der transaktionalen

Enterprise -IT

Orientation in Objects GmbH

Weinheimer Str. 6868309 Mannheim

[email protected]:

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

Gliederung

• Transaktionale Storages, NoSQL und das CAP-Theorem

• Transaktionale NoSQL-Szenarien

• Fallstudien

NoSQL in transaktionalen Enterprisesystemen© 2015 Orientation in Objects GmbH 2

„Klassische“ Enterprise-Vertreter


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

NoSQL in transaktionalen Enterprisesystemen© 2015 Orientation in Objects GmbH

• 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

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

Big Data (Bewegungsdaten)

Performance

Skalierung


Mobile Frontend-Anbindung

Skalierung

Scale-in vs. Scale-out

!?!?

Zisch ...


Vertikal skalieren Horizontal skalieren

These

Relationale Datenbanken skalieren in OO -Entwicklungsszenarien nicht mehr ausreichend.


ausreichend.

Warum?

Was tun ?

NoSQL = kein SQL mehr?


Nicht nur SQL!

NoSQLNot only SQLNot only SQL


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

NoSQL – industrieerprobte Skalierbarkeit

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?)


– Spezifische Reporting-Möglichkeiten (Ad-hoc reporting?)

• Datenmigration kann schwieriger sein– Unterschiedliche Technologien– Unterschiedliche Konzepte– Export-Funktionen unterschiedlich stark

12

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)

C

Consistency(Konsistenz)


A P

Availability(Verfügbarkeit)

Partition Tolerance(Partitionstoleranz)

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

Verfügbarkeit

Client

1. write

Client

2.read

Client

3. read


Storage Storage Storage

1.1synchronize

Konsistenz

Client

1.write

Client

3. read

Client

2. write



1.1 synchronize 2.1 synchronize

Partitionstoleranz

Client

1.write

Client

3. read

Client

2. write



1.1 synchronize 2.1 synchronize

Konsistenz

C

A P

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

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


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

Gliederung



• Fallstudien


These

Datenm

enge

NOSQLBASE- Storages


Datenm

enge

Durchsatz/Verfügbarkeit

NOSQLCA-StoragesScale in

klassischeCA-Storages

These



ausreichend.

Warum?

Objektrelationale Unverträglichkeit (ImpedanceMismatch)

ObjektorientierteSicht

RelationaleSicht

JDBCEJB (<= 2.1)

ObjektrelationalesMapping (ORM)


JDO

EJB (<= 2.1)

HibernateJPA

Aufspalten des Aggregats auf Zeilen von Tabellen

orders

addresses


order lines

These



ausreichend.

Warum?Impedanzmismatch => Joins, viele lesende Transaktionen

Große Clientanzahl/Verteilte Transaktionen


EIS EIS

Große Clientanzahl/Verteilte Transaktionen


EIS EIS

These



ausreichend.

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

Applicationserver (not dead)

Applicationserver


Applicationserver

EIS EIS

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

Die beliebtesten Key-Value-Stores

38%5%

3%

3% 2%2% 1% 1%

5% Redis Memcached Riak Ehcache DynamoDB Berkeley DB


26%

8%

6%Berkeley DB SimpleDB Hazelcast Coherence Oracle NoSQL Infinispan Sonstige

33

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

Java EE 7 Services

Java EE

JTA/JTS/JCA

CDI/Beanvalidation

Java Mail ConcurrencyUtils

JAX-RS

JPA

JMS Websocket

JBatch


JNDI

JAXP 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


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

Gliederung



• Fallstudien


JCACHE und Java EE Clustering

JEE

Application

Data Access

UI

0./4. Query

JEE

Application

Data Access

UI

0. Update


CacheCache

1. get5. get

CacheCache

1.x Store A1 2. Read A

• Secondary Store

Architektur by Peer to Peer

Vollst. Replikation

Distributed Hash Table

Ehcache x -

Hazelcast - x

Infinispan x x


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

Architektur by Client Server

Ehcache Hazelcast Infinispan

HardwareKonfiguration in Client-Server Mode

x - -

Elasticdeployment in

- x x


deployment in Client-Server Mode

40

Zusätzliche Features …

Ehcache Hazelcast Infinispan

Off-Heap Memory x x -

Persistent Caches x - -

Full-Text Search x - x

WAN Replication x x ???

GUI Tools x x -


GUI Tools x x -

JMX Management x x x

Messaging andProcessing

- x -

OR/M Integration

Java Virtual Machine

Anwendung

Transient

Transient

PersistenceManager

1.Level Cache

ConnectionInstanzInstanz

Instanz

QueryFacility

Transaction


TransientTransient

TransientDB

2.Level Cache

Entity Cache

InstanzInstanz

InstanzInstanz

QueryFacility

QueryCache

TimestampCache

Query Cache

Query Cache

Applikation

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

from Person p where p.name = :name


TimestampID VORNAME NAME

1 Thorsten Maier

2 Ben Bartho

25 Tobias Maier

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

Query Cache

Query Cache

Applikation

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

from Person p where p.name = :name

Update Person


TimestampID VORNAME NAME

1 Thorsten Maier

2 Ben Bartho

25 Tobias Maier

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

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

JEE

Application

Data Access

UI

0./5. call


Function Modul

2. callCacheCache

1. get6. get

Functional Caching

JEE

Application

Data Access

UI

0./5. call

Function Modul

4.1 invalidate


Function Modul

2. callCacheCache

1. get6. get

SecondaryStorage

Function Modul

4. update

2.X query

Functional Caching

0.1 /5.1 call

JEE

Application

Data Access

UI

0./5. call


Modul B

CacheCache

1. get6. get

SecondaryStorage

2.X query/update

Modul A

2.call

Distributed Cache I

JEE

Application

Data Access

UI

0./4. Query

JEE JEE


CacheCache

2. get5. put

CacheCache

• Secondary Store

3./6. load/Store

CacheCache

Distributed Cache II

JVMApplication

Data Access


JVM

CacheCache

49

Load/Store

JVM

CacheCache

• Secondary Store

Distributed Cache – Data Grid

JVM

ApplicationApplication

Data Access


• Secondary Store

JVM

CacheCache

JVM

CacheCache

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.


– 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

JVMApplication

Data Access

queryupdate


Load/Store

JVM

CacheCache

• Secondary Store

JVM

CacheCache

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


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


Distributed Cache Execution als LB Strategy

Distributed Cache

Node1

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

autodetection DB

Weblayer

command

submitToKeyOwner(lock 1)


Node 2

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

autodetection DB

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

Distributed Execution Webscaling – key = SessionID

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


• 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

Distributed Execution Layered Update – key = SessionID

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


• 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

? ??Fragen ?



[email protected]

??Fragen ?

58

Vielen Dank für ihre



[email protected]

Vielen Dank für ihre Aufmerksamkeit !

Documents

NoSQL-Einsatzszenarien in der transaktionalen …...NoSQL-Einsatzszenarien in der transaktionalen Enterprise-IT Orientation in Objects GmbH Weinheimer Str. 68 68309 Mannheim Version: