NoSQL in transaktionalen Enterprisesystemen · 02.02.2015 1 Orientation in Objects GmbH Weinheimer Str. 68 68309 Mannheim Version: [email protected] NoSQL in transaktionalen Enterprisesystemen

02.02.2015

1

Orientation in Objects GmbH

Weinheimer Str. 6868309 Mannheim

[email protected]:

NoSQL in transaktionalen

Enterprisesystemen

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

1.1

NoSQL in transaktionalen Enterprisesystemen© 2015 Orientation in Objects GmbH

Gliederung

• Transaktionale Storages, NoSQL und das CAP-Theorem

• Transaktionale NoSQL-Szenarien

• Fallstudien

2

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

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

02.02.2015

4


These

7

Relationale Datenbanken skalieren in OO-Entwicklungsszenarien nicht mehr ausreichend.

Warum?

Was tun ?


SQL

NoSQL = kein SQL mehr?

8

02.02.2015

5


Nicht nur SQL!

9

NoSQLNot only SQLNot only SQL


Einfache Formel

NoSQL

= Relationale Datenbank

- Transaktionen - Normalisierung - Joins - Konsistenz - hartes Schema

(+) Skalierung(+) Performance

10

02.02.2015

6


NoSQL Datenbanken

• Dokumentenorientierte Datenbanken

• Graphendatenbanken

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

• Eventually Consistent Stores

• MultivalueDatenbanken

• Objektdatenbanken

• Spaltenorientierte Datenbank

11


NoSQL – industrieerprobte Skalierbarkeit

12

Dynamo

BigTable

02.02.2015

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

02.02.2015

8


CAP Theorem von Eric Brewer (2000)

15

C

A P

Consistency(Konsistenz)

Availability(Verfügbarkeit)

Partition Tolerance(Partitionstoleranz)

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


Verfügbarkeit

16

Client

Storage

1. write

Client

Storage

2.read

Client

Storage

3. read

1.1synchronize

02.02.2015

9


Konsistenz

17

Client

Storage

1.write

Client

Storage

3. read

Client

Storage

2. write

1.1 synchronize 2.1 synchronize


Partitionstoleranz

18

Client

Storage

1.write

Client

Storage

3. read

Client

Storage

2. write

1.1 synchronize 2.1 synchronize

02.02.2015

10


Konsistenz

19

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.


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)

20

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

02.02.2015

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



• Fallstudien

22

02.02.2015

12


These

23

Datenm

enge

Durchsatz/Verfügbarkeit

NOSQLBASE- Storages

NOSQLCA-StoragesScale in

klassischeCA-Storages


These

24


Warum?

02.02.2015

13


Objektrelationale Unverträglichkeit (ImpedanceMismatch)

25

ObjektorientierteSicht

RelationaleSicht

JDBC

JDO

EJB (<= 2.1)

HibernateJPA

ObjektrelationalesMapping (ORM)


Aufspalten des Aggregats auf Zeilen von Tabellen

26

orders

addresses

order lines

02.02.2015

14


These

27


Warum?Impedanzmismatch => Joins, viele lesende Transaktionen


Große Clientanzahl/Verteilte Transaktionen

28

EIS EIS

02.02.2015

15


Große Clientanzahl/Verteilte Transaktionen

29

EIS EIS


These

30


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

02.02.2015

16


Applicationserver (not dead)

31

Applicationserver

EIS EIS


Gliederung



• Fallstudien

32

02.02.2015

17


NoSQL CA-Datenbanken

• Dokumentenorientierte Datenbanken

• Graphendatenbanken• Key-Value-Stores

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

• Eventually Consistent Stores

• MultivalueDatenbanken

• Objektdatenbanken

• Spaltenorientierte Datenbank

33


Node

Graph-DB Konzept

34

ID 12

username jdoe

birthday 1975 011975-08-01

Node

ID 47

username smith

Node

ID 123

02.02.2015

18


Kernelemente

• Fokussiert auf Beziehungen

• verschiedene Abfragemöglichkeiten

• verwendet ACID

• Skalierung begrenzt

35


Die beliebtesten Graph-Datenbanken

77%

9%

7%

7%

Neo4j OrientDB Titan Sonstige

36

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

02.02.2015

19


Graphen bestehen aus

• Knoten

• Beziehungen

• Eigenschaften

• Labels

37

DieterDevelop

BerndBoss

OIO

hat angestellt

arbeitet bei

gehört Firma

Person

Person

alter:48geschlecht: M

gehalt: 1000steuer: IV

gegründet: 1998Sitz: Mannheim

am: 01.01.99

seit: 01.01.99

geführt


Suchen von Mustern

38

02.02.2015

20


Key-Value Systeme - Vertreter

• Redis

• Amazon Dynamo und S3

• Voldemort

• Riak

• Berkeley DB

• MemcacheDB

39


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

40

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

02.02.2015

21


Java EE 7 Services

41

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

42

02.02.2015

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)

43

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


JCACHE und Java EE Clustering

44

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

02.02.2015

23


Architektur by Peer to Peer

45

• 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


Architektur by Client Server

Ehcache Hazelcast Infinispan

HardwareKonfiguration in Client-Server Mode

x - -

Elasticdeployment in Client-Server Mode

- x x

46

02.02.2015

24


Zusätzliche Features …

47

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

48

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

02.02.2015

25


Caching – Second Level Cache

49

Cache Concurrency Strategie Query cache

Cache Provider

Class Cache Region

Collection Cache Region

„ „ UpdateTimestamp

Query Cache Region

Physical Cache

Second-Level Cache


Caching – Second Level Cache

50

EntityManager

EntityManager

1Lvl Cache

1Lvl Cache

• Applikationsweiter Cache

• Provider spezifische Implementierung

• clusterfähig

• Evt. Dateiauslagerung

2nd Level Cache

Datenbank

Filesystem

02.02.2015

26


Query Cache

51

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

52

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

02.02.2015

27


Functional Caching

53

Function Modul

2. call

JEE

Application

CacheCache

Data Access

UI

1. get6. get

0./5. call


Functional Caching

54

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

02.02.2015

28


Functional Caching

55

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

56

JEE

Application

CacheCache

Data Access

UI

2. get5. put

0./4. Query

JEE

CacheCache

• Secondary Store

3./6. load/Store

JEE

CacheCache

02.02.2015

29


JVM

CacheCache

Distributed Cache II

57

Load/Store

JVM

CacheCache

• Secondary Store

JVMApplication

Data Access


Distributed Cache – Data Grid

58

• Secondary Store

JVM

CacheCache

JVM

CacheCache

JVM

ApplicationApplication

Data Access

JVM

CacheCache

JVM

CacheCache

02.02.2015

30


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

59


Hashing Algorithmus

60

02.02.2015

31


Distributed Cache Execution Konzept

61

Load/Store

JVM

CacheCache

• Secondary Store

JVM

CacheCache

JVMApplication

Data Access

queryupdate


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

62

02.02.2015

32


Execution on Key Owner example(Hazelcast)

63

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

64

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

02.02.2015

33


Distributed Execution Webscaling – key = SessionID

65

• 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


Distributed Execution Layered Update – key = SessionID

66

• 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

02.02.2015

34


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

67



[email protected]

??

? ?

????

Fragen ?

68

02.02.2015

35



[email protected]

Vielen Dank für ihre Aufmerksamkeit !

Documents

NoSQL in transaktionalen Enterprisesystemen · 02.02.2015 1 Orientation in Objects GmbH Weinheimer Str. 68 68309 Mannheim Version: [email protected] NoSQL in transaktionalen Enterprisesystemen