Hibernate: Joins und Performance

[Babba_BLuBB]

Hallo zusammen,

ich hab hier mal eine grundsätzliche Frage zur Verwendung von Joins in Hibernate. Ich dachte immer, dass die Verwendung von Joins grundsätzlich immer zu einem Performancegewinn führt, wenn man mehrere zusammenhängende Sachen aus verschiedenen Tabellen laden will bzw. mehrere persistierte Instanzen, die in Beziehung zueinander stehen.

Jetzt hab ich heute mal bissel mit Hibernate rumgespielt und musste feststellen, dass Joins nicht immer zu einem Performancegewinn führen. Ich habe mir eine Klasse A gemacht, die beliebig viele Beziehungen zu einer Klasse B aufnehmen kann. Also eine unidirektionale 1:N Beziehung zwischen A und B.

Dann hab ich 100 Instanzen der Klasse A gemacht, jeder dieser Instanzen 500 Instanzen der Klasse B zugeordnet und den ganzen Krams in eine Datenbank gesichert. Danach wollte ich alles wieder auf zwei Arten aus der Datenbank laden und danach die Ladezeiten vergleichen: Einmal ohne HQL/Criteria und einmal mit HQL unter Verwendung eines Joins.

Ich hatte die Erwartung, dass die Variante mit dem Join eigentlich schneller sein müsste, weil ja nur ein SQL-Query an die Datenbank geht. Die Variante ohne Join muss ja 100 Queries für die A-Instanzen absetzen und dann je A-Instanz wieder 1 Query für die Liste von zugeordneten B-Instanzen.

Als ich das ganze dann laufen lies musste ich feststellen, dass beide Varianten genau gleich lang brauchen.

Jetzt bin ich bissel verdutzt... Gibt es dafür eine logische Erklärung?

Grüße und danke schon mal im Vorraus

 

[SlaterB]

> Gibt es dafür eine logische Erklärung?

falsche Messung/ Interpretation?
poste doch zumindest deine HQL/ SQL-Kommandos + was dich ungefähr zu deinen Aussagen kommen läßt

> Die Variante ohne Join muss ja 100 Queries für die A-Instanzen absetzen

eine reicht

----

allgemein kann ein Join auch zu Langsamkein führen, zumindest aufgrund der Datenmenge,
wenn Klasse A 10 Attribute hat + Liste von 500 B und Klasse B nur 2,
dann würde bei einem Join 500x Klasse A + B geladen werden, also 500x 12 = 6000 Werte,

lädt man dagegen erst das A-Objekt, dann sind das nur 10 Werte, und die 500 B-Objekte für sich auch nur 1000 Werte,
hier würde man durch zwei Query also massiv Datenmengen sparen,
ob das dann langsamer oder schneller ist hängt von diversen Faktoren ab

 

[byte]

Sicher, dass Du ein Fetch Join gemacht hast?

select distinct a from A a left join fetch a.b

Ohne das Fetch initialisiert Hibernate die Bs nicht. Sie werden dann beim ersten Zugriff per Select geladen.

 

[Babba_BLuBB]

Hallo und schon mal danke für die Antworten.
Anbei die Sachen, die ich bisher so habe.

Ich habe mir zwei Klassen zum Testen erstellt. Das angehängte Bild "005" enthält ein Klassendiagramm. Ich habe dann verschiedene Testläufe gemacht, in denen ich alle persistierten Instanzen auf unterschiedliche Arten wieder aus der Datenbank geladen habe.

Erster Test: In der Datenbank befinden sich 14000 Parent-Instanzen (siehe Klassendiagramm) mit je einer assoziierten Child-Instanz.

Über Parent-Instanzen die assoziierten Child-Instanzen laden
- ueber Getter: 10867 ms
- ueber HQL mit Join: 1088 ms (also: "from Parent p join fetch p.children")
- ueber Criteria API mit Join: 1248 ms

Über Child-Instanzen die assoziierten Parent-Insanzen laden
- ueber Getter: 3823 ms
- ueber HQL mit Join: 869 ms (also: "from Child c join fetch c.parent")
- ueber Criteria API mit Join: 731 ms

Diese Ergebnisse erscheinen mir teilweise logisch. Ohne Join muss Hibernate 14001 Selects an die Datenbank absetzen. Also im ersten Fall ein Select um alle Parent-Instanzen zu beziehen und dann für je dieser Instanzen 1 Select um an die Liste der zugehörigen Child-Instanzen zu kommen.

So weit so gut. Aber warum braucht man im ersten Fall über die Getter 10867ms und im zweiten Fall nur noch 3823ms, obwohl in beiden Fällen meiner Meinung nach 14001 Selects an die Datenbank gehen.

 

[SlaterB]

wenn die Childs geladen sind, dann sind auch die 14.000 Parent-Ids bekannt,
und die Parents werden standardmäißg gewiss nicht einzeln geladen, sondern immer eine gewisse Menge auf einmal,
jedenfalls ergeben sich einfache Queries
from Parent where id in (id-List)

andersrum siehts viel schwerer aus, man hat nur die Parents, aber keine Id-Listen für die Childs,
hier ist es viel fraglicher, ob gleich optimierend für mehrere Parents die Childs zusammen gelade werden können,
denn während es überschaubar ist, z.B. gleich zu 10 Childs 10 Parents in einer Query zu laden, können zu jedem Parent potentiell tausende Childs vorhanden sein,
wer will da gleich für 10 Parents anfragen?

selbst wenn man diese 'fetch-size' außer acht läßt,
sind die DB-Anfragen vom Parent aus immer noch komplizierter, da ja wie gesagt die Ids der Childs unbekannt sind,
die Querys lauten also
from Child where parentId = id
oder
from Child where parentId in (id-List)


hmm, ok, die beiden Queries sehen doch nicht so viel anders aus ,
und ein Index ist wohl für keine der Id-Spalten vorhanden

dann wäre nur noch die Frage der fetch-size,
teste doch mal mit einer DB, die Queries loggt, bzw. schalte in Hibernate das Log ein:

<hibernate-configuration>
    <session-factory>
    
[..]
		<!-- Miscellaneous Settings -->
		
		<!-- print all generated SQL to the console -->
		<property name="hibernate.show_sql">false</property>

[..]

		<!-- set the default batch size for batch fetching -->
		<property name="hibernate.default_batch_fetch_size">100</property>

oder es liegt an was ganz anderem

 

[byte]

So weit so gut. Aber warum braucht man im ersten Fall über die Getter 10867ms und im zweiten Fall nur noch 3823ms, obwohl in beiden Fällen meiner Meinung nach 14001 Selects an die Datenbank gehen.

Das lässt sich per Ferndiagnose schwer sagen. Am besten guckst Du Dir das erzeugte SQL an, dann bist Du schlauer.

Ich nehme an, Du hast eine gravierende Sache bei Deinem Test nicht beachtet: ManyToOne und OneToOne wird von Hibernate direkt mitgeladen. Lädst Du also alle Children, dann werden auch direkt alle Parents geladen. Hibernate lädt die dabei über zusätzliche Selects. Diese Selects gehen nicht erst raus, wenn Du den Getter aufrufst, sondern schon direkt beim Laden der Children.
Anders siehts aus, wenn Du die Parents lädst, die ja ein OneToMany oder ManyToMany auf Children haben. Die Collections werden nicht automatisch geladen (ausser Du machst ein Fetch Join). Die Collections werden dann initialisiert, wenn Du über die Collection iterierst.

 

[Babba_BLuBB]

DManyToOne und OneToOne wird von Hibernate direkt mitgeladen. Lädst Du also alle Children, dann werden auch direkt alle Parents geladen. Hibernate lädt die dabei über zusätzliche Selects.

Dazu muss Hibernate aber doch auch die vollen 14001 Selects an die Datenbank stellen, oder? Daher müsste doch dann auch die Laufzeit der ganzen Geschichte relativ unabhängig davon sein, ob Hibernate eine zu-1-Beziehung direkt mitläd oder eine zu-N-Beziehung mit nur einem Eintrag erst beim Aufruf des entsprechenden Getters läd.

Oder kann Hibernate beim direkten Laden von zu-1-Beziehungen noch irgendwie was rumoptimieren?

 

[SlaterB]

schalt doch einfach das Log ein und schau dir die Query an

 

[Babba_BLuBB]

Alles kloa, danke

 

[byte]

Dazu muss Hibernate aber doch auch die vollen 14001 Selects an die Datenbank stellen, oder? Daher müsste doch dann auch die Laufzeit der ganzen Geschichte relativ unabhängig davon sein, ob Hibernate eine zu-1-Beziehung direkt mitläd oder eine zu-N-Beziehung mit nur einem Eintrag erst beim Aufruf des entsprechenden Getters läd.

Oder kann Hibernate beim direkten Laden von zu-1-Beziehungen noch irgendwie was rumoptimieren?

Bin mir nicht sicher, was Hibernate daraus macht. Das weisst Du, wenn Du das SQL anschaust.
Könnte sein, dass SlaterB recht hat und Hibernate schlau genug ist, die Parents mit wenigen Selects zu holen, da die IDs der Parents ja bekannt sind.

Wäre nett, wenn Du das Ergebnis mal posten würdest. Für gewöhnlich joine ich solche Parents direkt rein, um die zusätzlichen Selects zu sparen. Aber es würde mich auch mal interessieren, was Hibernate daraus macht.

 

[Babba_BLuBB]

Hallo zusammen,

OK, ich schau mir das alles mal bissel genauer an und erstatte dann Bericht.