• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Datenbankoptimierung
 

Datenbankoptimierung

on

  • 790 views

Präsentation zum Thema Datenbankoptimierung: Effektiver Einsatz von EHCache, etc. "Ein typisches Szenario bei Enterprise-Applications ist folgendes: mehrere Application-Server greifen auf eine ...

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

Statistics

Views

Total Views
790
Views on SlideShare
542
Embed Views
248

Actions

Likes
0
Downloads
1
Comments
0

7 Embeds 248

http://www.cenarion.com 151
http://cenarion.com 82
http://www.cenarion.at 5
http://www.cenarion.net 5
http://webpage-ts.cenarion.com 3
http://webpage-qs.cenarion.com 1
http://192.158.30.250 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Datenbankoptimierung Datenbankoptimierung Presentation Transcript

    • DB-Caching Optimierung des Datenbankzugriffsandreas.hubmer@cenarion.com 15.04.2013
    • InhaltProblemstellung1st-Level Cache JPA2nd-Level Cache Hibernate Ehcache Query Cache Tipps 2
    • ProblemstellungApplication- Application- Application- Server Server Server DB 3
    • Lösung 1: Datenbank skalieren Application- Application- Application- Server Server Server • Synchronisation DB DB • Lizenzen 4
    • Lösung 2: CachingApplication- Application- Application- Server Server Server DB-Cache DB-Cache DB-Cache • Entlastet DB DB-Server • Beschleunigt Zugriff 5
    • 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 Application ServerTransaktion 1st-Level-Cache DB-Server 8
    • 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: BeispielApplikations-Code Was tatsächlich geschiehtBEGIN TX BEGIN TXSELECT p FROM person AS p p = SELECT * FROM person WHERE p.id=1 WHERE id=1 personCache.put(1, p)SELECT p FROM person AS p personCache.get(1) WHERE p.id=1p.setFirma(“Cenarion“)END TX UPDATE person SET firma=… END TX 10
    • 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@Statelesspublic 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 Application ServerTransaktion 1st-Level 2nd- Level DB-ServerTransaktion 1st-Level CacheTransaktion 1st-Level 13
    • 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: KonsistenzStrategien:• Read-Only• Nonstrict Read-Write• Read-Write: ohne serialisierbare Transaktionen• Transaktional: 2PC (teuer) 15
    • 2nd-Level-Cache: KonsistenzMehrere Application-Server:• Synchronisation wie bei verteilter DB (außer Read-Only)• Veraltete Daten, TTL setzen 16
    • Wie einrichten (JPA)?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 { ….} 17
    • JPA im Rückstand 18
    • Wie einrichten (Hibernate)?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 {} 19
    • Wie einrichten (Ehcache)?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> 20
    • Cache APICache c = entityManager.getEntityManagerFactory().getCache()javax.persistence. evict(clazz) Cache 21
    • Query Cache Application ServerTransaktion 1st-Level 2nd- Level Cache DB-ServerTransaktion 1st-Level Query- CacheTransaktion 1st-Level 22
    • Query Cache• ID notwendig für 1st/2nd Level Cache SELECT … WHERE nonId=‘value‘• Schlüssel: Query• Werte: Objekt-IDs – Mit diesen wird der 1st/2nd-Level-Cache befragt 23
    • 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) SELECT p FROM Person p WHERE plz=‘1041 ‘ 4 3 2nd- Level 2 CacheTransaktion 1st-Level DB-Server Query- Cache 1 25
    • Beispiel (2) p.setPLZ(‘1040‘) 2nd- Level 1 CacheTransaktion 1st-Level DB-Server Query- Cache 26
    • Beispiel (3) COMMIT 2 3 2nd- Level 1 CacheTransaktion 1st-Level DB-Server Query- Cache 27
    • Query Cache: Configehcache.xml<cache name="org.hibernate.cache.StandardQueryCache" maxElementsInMemory="200" … /><cache name="org.hibernate.cache.UpdateTimestampsCache" maxElementsInMemory="1000" eternal="true" overflowToDisk="false"/> 28
    • 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
    • Application Server 2nd-Level Cache | Query CacheApplication Server Sync Transaktion 1st-Level 2nd- Level Cache DB-Server Transaktion 1st-Level Query- Cache Transaktion 1st-Level 33
    • 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
    • Links• JPA offiziell: http://docs.oracle.com/javaee/6/tutorial/doc/bnbpy.html• JPA Tutorial: http://en.wikibooks.org/wiki/Java_Persistence• JPA: https://blogs.oracle.com/carolmcdonald/entry/jpa_caching• Hibernate: http://docs.jboss.org/hibernate/orm/3.6/reference/en-US/html/performance.html• Hibernate, alt, aber gut: http://www.javalobby.org/java/forums/t48846.html 35