Effiziente datenpersistierung mit JPA 2.1 und Hibernate

Effiziente Datenpersistierung
mit JPA 2.1
www.thoughts-on-java.org

Thorben Janssen
• Senior Entwickler und Architekt @ Qualitype GmbH
• CDI 2.0 (JSR 365) Expert Group Mitglied
• Twitter: @thjanssen123
• Blog: www.thoughts-on-java.org

Beispielanwendung

Anwendung

Was bedeutet Effizienz?

Performance
SpeicherplatzProduktivität
Xwww.thoughts-on-java.org
X
Effizienz

Performance

• Frühzeitiges Erkennen von Performanceproblemen
• Typische Ursachen von Performanceproblemen
• Performanceprobleme beheben und vermeiden
Performance

Auftreten von
Performanceproblemen

• Ein Kunde meldet ein langsames System
• Der DBA fragt nach dem Grund für sehr viele (ähnliche) Abfragen
• Schlechte Performance beim Test der Anwendung
• Entwickler sieht auffällige Statistiken im Log
Performanceprobleme

Hibernate Statistics

• Über Systemproperty aktivieren:
hibernate.generate_statistics = true
• Logging konfigurieren:
org.hibernate.stat = DEBUG
HibernateStatistics

Demo (Projekt Model)

Ursachen von
Performanceproblemen

• Langsame Select-Statements
• Falsche Fetch-Strategie
• Fehlendes Caching
• Laden nicht benötigter Daten
• Datensätze einzeln löschen oder ändern
• Logik in der Anwendung anstatt der Datenbank/Abfrage
HäufigeUrsachen

1. Langsame Select-Statements

• Meistens kein „echtes“ JPA- oder Hibernateproblem
• Erzeugtes SQL überprüfen
• Indexe überprüfen
• Ausführungsplan des Statements überprüfen
• Ggf. Ergebnismenge beschränken (paging)
• Statement optimieren
• Native SQL-Statements verwenden, wenn JPQL nicht ausreicht
LangsameSelects

• Schnellere Abfragen durch echtes SQL
• JPQL unterstützt nur ein Subset von SQL
• Datenbankspezifische SQL-Features
• Native Query liefert Object[] für jede Ergebniszeile
• Erfordert programmatisches oder deklaratives Mapping
NativeQuery

• Deklaratives Mapping für Abfrageergebnisse
• Unterstützte Zieltypen:
• Entities
• Value Objekte
• Skalare
ResultSetMapping

Demo (Projekt NativeQuery)

2. Fetch-Strategien

• Statische Definition im Mapping
• Fragestellungen
• Wann soll geladen werden?  FetchType
• Wie soll geladen werden?  FetchMode
Fetch-Stratgien

2.1 FetchType

• Lazy
• Relation wird bei erstem Zugriff geladen
• Default für to-many Relationen
• Verwendet Proxies für to-one Relationen
• Eager
• Relation wird sofort geladen
• Default für to-one Relationen
FetchType

• Hibernate erzeugt Proxy für lazy to-one-Relationen
• Proxy ist Subklasse der Entity
• Instanceof möglich
• Typecast auf Subklasse nicht möglich
• Alternative: bytecode enhancement ohne Proxy
To-onemitProxy

Demo (Projekt EagerLoading)

2.2 FetchMode

• Hibernate spezifisch
• Definiert wie Relationen geladen werden
• JOIN = im selben SELECT
• SELECT = 1 SELECT je Entity der Relation
• SUBSELECT = 1 SELECT für alle Entities der Relation
• BATCH = mehrere Entities der Relation je SELECT
FetchMode

• To-many-Relationen
• Default in Annotationen belassen (meist FetchType.LAZY)
• Eager fetching, wenn benötigt für Query definieren
• To-one-Relationen
• Einzeln prüfen, meist ist der default OK
Empfehlung

2.3 Queryspezifisches
Fetching

• Entsteht, wenn lazy Relationen beim Zugriff nachgeladen werden
List<Author> authors = this.em.createQuery("SELECT a FROM Author a",
Author.class).getResultList();
for (Author a : authors) {
System.out.println("Author " + a.getFirstName() + " " + a.getLastName() + "
wrote " + a.getBooks().stream().map(b -> b.getTitle()).collect(Collectors.joining(", ")));
}
N+1Selects

Demo (Projekt LazyLoading)

• Besser, benötigte Relationen direkt mit laden:
• (FetchType.EAGER)
• Fetch Join
• @NamedEntityGraph
• EntityGraph
N+1Selects

• Verwendung von JOIN FETCH anstatt JOIN in Abfrage
List<Author> authors = this.em.createQuery("SELECT DISTINCT a FROM Author a JOIN
FETCH a.books b", Author.class).getResultList();
for (Author a : authors) {
System.out.println("Author " + a.getFirstName() + " " + a.getLastName() + "
wrote " + a.getBooks().stream().map(b -> b.getTitle()).collect(Collectors.joining(", ")));
}
FetchJoin

• Vorteile:
• EntityManager lädt Relation in der selben Abfrage
• Nachteile:
• Spezielle Abfrage für jeden Use Case erforderlich
• Bildet kartesisches Produkt
FetchJoin

• Neu in JPA 2.1
• Definiert einen zu ladenden Entitätsgraphen
• @NamedEntityGraph
• @NamedAttributeNode
• @NamedSubGraph
NamedEntityGraph

• Fetchgraph
• Elemente des Graphen werden EAGER geladen
• Alle anderen werden LAZY geladen
• Loadgraph
• Elemente des Graphen werden EAGER geladen
• Alle anderen werden mit ihrem jeweiligen FetchType geladen
• ACHTUNG: Hibernate behandelt beides gleich!
• HHH-8776
NamedEntityGraph

• Vorteile:
• Queryspezifisches EAGER-loading
• Definition des Graphen unabhängig von der Abfrage
• Nachteile:
NamedEntityGraph

• Neu in JPA 2.1
• Dynamische Variante des @NamedEntityGraph
• Definition mittels Java API
• EntityManager.createEntityGraph(Class entity)
• EntityGraph
• SubGraph
EntityGraph

• Vorteile:
• Queryspezifisches EAGER-loading
• Definition des Graphen unabhängig von der Abfrage
• Graph kann zur Laufzeit definiert werden
• Nachteile:
EntityGraph

3. Caching

DB
2nd
Level
Cache
1st
Level
Cache
Hibernate
Session
Query
Cache
1st
Level
Cache
Hibernate
Session
Caches

• 1st Level Cache
• An Session gebunden
• Per default aktiviert
• 2nd Level Cache
• Sessionübergreifend
• Konfiguration erforderlich
• Query Cache
• Sessionübergreifend
• Konfiguration erforderlich
Caches

3.1 1st Level Cache

• Automatisch aktiviert
• Sessioninterner Speicher verwendeter Entities
• Zugriff erfolgt transparent
1stLevelCache

Demo (Projekt 1stLevelCaching)

3.2 2nd Level Cache

• Sessionübergreifender Speicher für Entities
• Im default deaktiviert
• persistence.xml oder EntityManagerFactory
• Zugriff erfolgt transparent
• Muss nicht durch den Persistence Provider bereitgestellt werden
• u.U. nicht portierbar
2ndLevelCache

• Shared Cache Mode
• ALL alle Entities werden gecached
• NONE keine Entities werden gecached
• ENABLE_SELECTIVE Caching muss für Entities aktiviert werden
• DISABLE_SELECTIVE Caching kann für Entities deaktiviert werden
• UNSPECIFIED Verwendet das default caching des
PersistenceProviders
2ndLevelCache

• Speichert die Entities in ‚dehydrated‘-Form
• Nur die Eigenschaften der Entity, nicht die Entity selbst
• 1  [„Joshua“, „Bloch“, 0]
• Relationen werden nicht mit gespeichert
• Caching mit @org.hibernate.annotations.Cache möglich
2ndLevelCache

Demo (Projekt 2ndLevelCaching)

• Verwendung des Cache konfigurieren
• Cache Retrieve Mode
• Definiert wie Daten aus dem Cache gelesen werden
• Cache Store Mode
• Definiert wie Daten in den Cache geschrieben werden
2ndLevelCache

• Cache Retrieve Mode
• CacheRetrieveMode.USE (default)
• Daten werden aus Cache gelesen
• CacheRetrieveMode.BYPASS
• Daten werden aus DB gelesen
2ndLevelCache

• Cache Store Mode
• CacheStoreMode.USE (default)
• Cache wird beim commit erzeugt oder aktualisiert
• Aktualisierung wird bei nur lesendem Zugriff nicht erzwungen
• CacheStoreMode.BYPASS
• Cache wird nur aktualisiert, nicht angelegt
• CacheStoreMode.REFRESH
• Cache wird beim commit erzeugt oder aktualisiert
• Aktualisierung wird bei nur lesendem Zugriff erzwungen
2ndLevelCache

• Concurrency Strategy
• JPA: Definition erfolgt global
• Hibernate: Definition erfolgt spezifisch für jede Entity
• @org.hibernate.annotations.Cache
2ndLevelCache

• Concurrency Strategy
• Read-only
• Read-write
• Nicht für serializable transaction isolation verwendbar
• Nonstrict-read-write
• Keine strict transaction isolation
• Transactional
• Benötigt JTA
• Z.B. Infinispan, EHCache
2ndLevelCache

3.3 Query Cache

• Hibernate spezifisch
• Sessionübergreifender Speicher von Abfrageergebnissen
• Im default deaktiviert
• persistence.xml: hibernate.cache.use_query_cache = true
• Caching muss für Query aktiviert werden
• org.hibernate.Query.setCacheable(true)
• @NamedQuery(… hints =
@QueryHint(name="org.hibernate.cacheable", value="true"))
QueryCache

• Speichert Ergebnis für Abfrage mit Parametern
• [„FROM Author WHERE id=?“, 1]  [1]
• Speichert nur Referenzen auf Entitäten oder Skalare
• Immer mit 2nd Level Cache kombinieren
QueryCache

Demo (Projekt QueryCaching)

• Nur Daten mit geringer Änderungsrate cachen
• Cache nicht ohne Benchmark einführen
• Query Cache und 2nd Level Cache gemeinsam nutzen
• Konfigurationen aufeinander abstimmen
Empfehlung

• JSR 338: JavaTM Persistence API, Version 2.1
http://download.oracle.com/otndocs/jcp/persistence-2_1-fr-eval-
spec/index.html
• Hibernate Reference Documentation
http://docs.jboss.org/hibernate/orm/4.3/manual/en-US/html/
• Hibernate Developer Guide
http://docs.jboss.org/hibernate/orm/4.3/devguide/en-US/html/
• Hibernate ORM: Tips, Tricks and Performance Techniques by Brett
Meyer http://de.slideshare.net/brmeyer/hibernate-orm-
performance-31550150
• Java Persistence with Hibernate Second Edition by Christian Bauer,
Gaving King, Gary Gregory
Quellen

• Java Platform, Enterprise Edition: The Java EE Tutorial
https://docs.oracle.com/javaee/7/tutorial/index.html
• Hibernate: Truly Understanding the Second-Level and Query Caches
http://www.javalobby.org/java/forums/t48846.html
Quellen

Noch Fragen?

Effiziente datenpersistierung mit JPA 2.1 und Hibernate

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (9)

Similaire à Effiziente datenpersistierung mit JPA 2.1 und Hibernate

Similaire à Effiziente datenpersistierung mit JPA 2.1 und Hibernate (20)

Effiziente datenpersistierung mit JPA 2.1 und Hibernate