Datenbankoptimierung

Post on 05-Jul-2015

907 views 0 download

description

Präsentation zum Thema Datenbankoptimierung: Effektiver Einsatz von EHCache, etc. "Ein typisches Szenario bei Enterprise-Applications ist folgendes: mehrere Application-Server greifen auf eine Datenbank zu. Schnell wird dabei der Zugriff auf die Datenbank zum Performance-Engpass. Im Vortrag wird das Caching von Query-Ergebnissen auf den Application-Servern mit Hilfe der JPA erklärt."

Transcript of Datenbankoptimierung

DB-Caching

Optimierung des

Datenbankzugriffs

andreas.hubmer@cenarion.com 15.04.2013

Inhalt

Problemstellung

1st-Level Cache

2nd-Level Cache

Query Cache

Tipps

2

JPA Hibernate Ehcache

Problemstellung

3

DB

Application- Server

Application- Server

Application- Server

DB

Lösung 1: Datenbank skalieren

4

DB

Application- Server

Application- Server

Application- Server

DB • Synchronisation • Lizenzen

DB-Cache

DB-Cache

DB-Cache

Lösung 2: Caching

5

DB-Server

Application- Server

Application- Server

Application- Server

• Entlastet DB • Beschleunigt Zugriff

Ziele

• Hohe Cache-Hit-Rate

• Konsistenz

• Self-Management?

6

Objekt-Cache

• Objektrelationaler Mapper (ORM)

– Entity

• Transaktion pro Anwendungsfall

• RAM oder Festplatte

• Wichtig: Jeder DB-Zugriff geht über den

ORM

7

1st-Level-Cache

8

DB-Server

Application Server

Transaktion 1st-Level-Cache

1st-Level-Cache

• Hash-Tabelle pro Entity-Klasse

• Schlüssel: Objekt-ID = Primary Keys

• Werte: Objektinstanzen

• Im Rahmen einer Transaktion

– Kein Synchronisationsbedarf zu anderen

Application-Servern

9

1st-Level-Cache: Beispiel Applikations-Code

BEGIN TX

SELECT p FROM person AS p

WHERE p.id=1

SELECT p FROM person AS p

WHERE p.id=1

p.setFirma(“Cenarion“)

END TX

10

Was tatsächlich geschieht

BEGIN TX

p = SELECT * FROM person

WHERE id=1

personCache.put(1, p)

personCache.get(1)

UPDATE person SET firma=…

END TX

Puffer für Schreibzugriffe

• Update, Insert, Delete erst mit

Transaktionsende

• Ausnahmen:

– Manueller Flush

– Objekt vom Typ A wurde verändert: Vor einer

DB-Query über A müssen die Änderungen an

A persistiert werden

11

Mit der JPA

@Stateless

public class MyEjb {

@PersistenceContext

private EntityManager entityManager;

@TransactionAttribute(TransactionAttributeType.REQUIRED)

public void businessMethod() throws Exception {

Person p = entityManager.find(Person.class, 1);

p.setFirma(“Cenarion“);

}

}

12

2nd-Level-Cache

13

DB-Server

Application Server

Transaktion

2nd- Level Cache

1st-Level

Transaktion 1st-Level

Transaktion 1st-Level

2nd-Level-Cache

• Pro Application Server einer

– für alle Transaktionen gemeinsam

• Cache über Objekt-Ids

• Werte statt Objekte

• Wird befüllt beim Lesen (SELECT) und

Commit (UPDATE, INSERT, DELETE)

14

2nd-Level-Cache: Konsistenz

Strategien:

• Read-Only

• Nonstrict Read-Write

• Read-Write: ohne serialisierbare

Transaktionen

• Transaktional: 2PC (teuer)

15

2nd-Level-Cache: Konsistenz

Mehrere Application-Server:

• Synchronisation wie bei verteilter DB

(außer Read-Only)

• Veraltete Daten, TTL setzen

16

Wie einrichten (JPA)?

17

persistence.xml <persistence-unit name="myUnit" transaction-type="JTA"> … <shared-cache-mode>ENABLE_SELECTIVE</shared-cache-mode> <!– NONE, DISABLE_SELECTIVE --> </persistence-unit>

@javax.persistence.Entity

@javax.persistence.Cacheable(true)

public class Person {

….

}

JPA im Rückstand

18

Wie einrichten (Hibernate)?

19

persistence.xml … <property name="hibernate.cache.use_second_level_cache" value="true" /> <property name="hibernate.cache.region.factory_class" value="net.sf.ehcache.hibernate.EhCacheRegionFactory" />

@javax.persistence.Entity

@org.hibernate.annotations.Cache(usage=

CacheConcurrencyStrategy.READ_WRITE)

public class Person {

}

Wie einrichten (Ehcache)?

20

ehcache.xml <ehcache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="../config/ehcache.xsd" updateCheck="false"> <cache name="com.cenarion.Person" maxElementsInMemory="200" eternal="false" timeToIdleSeconds="600" timeToLiveSeconds="3600" overflowToDisk="false" /> </ehcache>

Cache API

21

javax.persistence. Cache

evict(clazz)

Cache c = entityManager.getEntityManagerFactory().getCache()

Query Cache

22

DB-Server

Application Server

Transaktion

2nd- Level Cache

Query-Cache

1st-Level

Transaktion 1st-Level

Transaktion 1st-Level

Query Cache

• ID notwendig für 1st/2nd Level Cache

• Schlüssel: Query

• Werte: Objekt-IDs

– Mit diesen wird der 1st/2nd-Level-Cache

befragt

23

SELECT … WHERE nonId=‘value‘

Query Cache: Konsistenz

• Bei Änderungen an einer Tabelle A werden

alle gecachten Ergebnisse für Queries über A ungültig

• Mittels Timestamp

– Timestamp pro Tabelle und gecachter Query

– Locking notwendig

• Synchronisation der Tabellen-Timestamps

24

Beispiel (1)

25

SELECT p FROM Person p WHERE plz=‘1041 ‘

DB-Server

2nd- Level Cache

Query-Cache

Transaktion 1st-Level

1

2

3 4

Beispiel (2)

26

p.setPLZ(‘1040‘)

DB-Server

2nd- Level Cache

Query-Cache

Transaktion 1st-Level

1

Beispiel (3)

27

COMMIT

DB-Server

2nd- Level Cache

Query-Cache

Transaktion 1st-Level

2 3

1

Query Cache: Config

28

ehcache.xml <cache name="org.hibernate.cache.StandardQueryCache" maxElementsInMemory="200" … /> <cache name="org.hibernate.cache.UpdateTimestampsCache" maxElementsInMemory="1000" eternal="true" overflowToDisk="false"/>

Hibernate

• Cache Providers

• Collections (@Cache)

• Regions

29

Verwendungstipps (1)

• Zuerst andere Optimierungen (zB: Indizes)

• 1st-Level-Cache ist immer aktiv

• 2nd-Level-Cache:

– Wenn viele Lesezugriffe vorkommen

– Veraltete Daten ohne

Transaktionsunterstützung kein Problem

– Pro Entity entscheiden

– Performance messen (#Hits, Beschleunigung,

Speicherbedarf, DB-Entlastung)

30

Verwendungstipps (2)

• Query-Cache:

– Für einzelne Queries per Hint aktivieren

– Nur mit 2nd-Level-Cache gemeinsam

– Tabellen mit (fast) nur Lesezugriff

– Bei natürlichen Schlüsseln (≠Primärschlüssel)

• Keine direkten DB-Manipulationen per

SQL/Native Query

31

32

33

DB-Server

Transaktion

2nd- Level Cache

Query-Cache

1st-Level

Transaktion 1st-Level

Transaktion 1st-Level

2nd-Level Cache | Query Cache

Sync

Application Server

Application Server

Zusammenfassung

• Problem: DB-Überlastung

• Lösung: Caching am Application-Server

• Herausforderung Synchronisierung

– Caching besonders sinnvoll bei weniger

strikten Anforderungen

• Self-Management ist eine Vision

34