IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Hibernate Java Discussion :

[hibernate 3.1] Les techniques de chargement ("lazy loading")


Sujet :

Hibernate Java

  1. #1
    Membre à l'essai
    Profil pro
    Inscrit en
    Novembre 2004
    Messages
    44
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2004
    Messages : 44
    Points : 24
    Points
    24
    Par défaut [hibernate 3.1] Les techniques de chargement ("lazy loading")
    Bonjour.

    J'ai lu beaucoup de documentation sur Hibernate, et notamment sur les diverses technique de chargement ou également appellé "lazy loading".

    J'ai pu lire beaucoup de chose sur les propriétés "lazy", "outer-join", "fecth" ou encore "batch-size" mais là où ca bloque, c'est que je n'ai pas réellement comment et à quel moment utiliser tout celà. Ma question est donc plus sur un principe d'utilisation. J'aimerais si possible que l'on me guide dans le mapping d'un exemple. J'aimerais mapper une base qui associe un fichier à plusieurs messages. A première vue j'ai réalisé un mapping de ce style (les propriétés sont là pour décorés :p) :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
     
    <class name="Flux" table="FLUX">
    	<id name="id" column="F_ID" type="string" length="32">
    		<generator class="uuid"/>
    	</id>
    	<property name="name" column="F_NAME" type="string" length="40" unique="true"/>
    	<property name="dateInsertion" column="F_DATE_INSERT" type="timestamp" update="false"/>	
    	<set name="messages" inverse="true">
    		<key column="MESSAGE_FLUX"/>
    		<one-to-many class="Message"/>
    	</set>
    </class>
     
    <class name="Message" table="MESSAGE">
    	<id name="id" column="M_ID" type="string" length="32">
    		<generator class="uuid"/>
    	</id>
    	<property name="etat" column="M_ETAT" type="long" length="1"/>
            <property name="offset" column="M_OFFSET" type="long"/>
    	<many-to-one name="fluxEntree" class="Flux" column="MESSAGE_FLUX"/>
    </class>
    Voilà, a partir de cet exemple "bateau" comment définir un paramétrage de chargement correct ? J'aimerais tenir compte de problème de performance et admettons que l'on peut avoir dans un flux, de 1 à 10.000 messages.


    Mon "idée" de solution :
    A priori dans hibernate 3.1 lazy est par défaut à false, donc pas besoin de le mettre. Maintenant je placerait peut être un batch_size sur la liste des messages dans la définition du flux ? Faut il poser un fetch="join" sur le "many-to-one" également ?

    Merci d'avance pour toute l'aide que vous pourrez m'apporter
    Et n'hésitez pas à partager vos propres exemples, mon but est d'essayer de comprendre le mécanisme des chargements qui me paraît important pour les grosses bases de données.


    EDIT : j'ai oublié de préciser que je voulais bien sur eviter les fameux N+1 select

  2. #2
    Membre confirmé
    Avatar de grishka
    Inscrit en
    Janvier 2003
    Messages
    285
    Détails du profil
    Informations forums :
    Inscription : Janvier 2003
    Messages : 285
    Points : 499
    Points
    499
    Par défaut
    fetch join : résoud le prbl du N+1 select, mais la taille du resultats transitant entre la base et l'application sera proportionnel au nombre de message.

    batch : effectue M select avec M = N/S +1, S étant la taille du batch, N le nombre de message.

    donc perso je choisirai :

    fetch join : si je suis sur d'avoir besoin de toutes les données pour faire un traitement. Même si le total des données transitant est plus faible dans le cas des batch (car aucune jointure n'est faite), dans la plupart des cas le fetch join sera plus performant


    batch : si je ne suis pas sur

    d'autres solutions plus fonctionnelles existent. Si ton besoin est d'afficher une liste de messages à l'utilisateur : utilise plutot un système de pagination avec fenêtre glissante

    Par contre le choix d'une méthode fixé dans le mapping est à mon avis une mauvaise idée. Je te conseille de faire ca via l'API
    "Les gens normaux croient que si ca marche, c'est qu'il n'y a rien à reparer. Les ingénieurs croient que si ca marche, c'est que ca ne fait pas encore assez de choses."
    --Scott Adams

  3. #3
    Membre à l'essai
    Profil pro
    Inscrit en
    Novembre 2004
    Messages
    44
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2004
    Messages : 44
    Points : 24
    Points
    24
    Par défaut
    Merci pour cette première réponse . J'avou que c'est difficille de voir ce qui doit être utilisé et a quel moment.

  4. #4
    Membre à l'essai
    Profil pro
    Inscrit en
    Novembre 2004
    Messages
    44
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2004
    Messages : 44
    Points : 24
    Points
    24
    Par défaut
    Grégory j'ai exploré tes solutions et réalisé quelques tests (sans grande prétention, il faudrait pousser beaucoup plus loin).

    Je suis tombé totalement d'accord avec toi sur le principe suivant :

    Le choix d'une méthode fixé dans le mapping est à mon avis une mauvaise idée. Je te conseille de faire ca via l'API
    J'ai remarqué qu'il fallait rester très général dans le mapping et être beaucoup plus précis lorsque l'on réalisait les requêtes, notamment en mettant des fetchs join et en réalisant un découpage très précis des requêtes.

    J'ai également tester avec la clé suivante : hibernate.jdbc.batch_size avec une valeur de 10. Je trouve cela très utile pour un mapping qui manipule beaucoup de collection. J'ai pu constater des améliorations.

    Tout cela nécessite apparemment un gros travail de réflexion sur le mapping et les requêtes nécessaires à l'application. On peu vite arriver à des temps d'exécution catastrophique.

    Comme je l'ai dit plus haut je penses que j'ai besoin de réalisé beaucoup plus de test pour me faire une idée de chaque "composante" existante. N'hésitez pas à partager votre expérience, ça m'interresse ^^.

Discussions similaires

  1. Réponses: 0
    Dernier message: 12/09/2010, 22h02
  2. [ HIBERNATE ] Question pour les doués
    Par Néo-Tony dans le forum Hibernate
    Réponses: 25
    Dernier message: 23/02/2006, 15h23
  3. [Hibernate] Comment ramener les valeurs des tables de ref ?
    Par PamelaGeek dans le forum Hibernate
    Réponses: 9
    Dernier message: 07/02/2006, 23h52
  4. LES TECHNIQUES DES SGBDR / MySQL rapide ???
    Par SQLpro dans le forum Langage SQL
    Réponses: 1
    Dernier message: 12/09/2003, 11h16

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo