Performance requete hibernate

bonjour,

Je dois recuperer des données d'une table assez grande qui peut contenir quelques millions d'enregistrements (la table contient actuellement environ 250.000).

Pour améliorer les performances de cette récuperation, j'ai rajouté les champs figurant dans le where comme indexes et j'ai procédé à une récupération par bloc

Je récupére environ 20.000 enregistrements à chaque requête.

Chaque requete prend environ 10s en moyenne, je dois absolument arriver à améliorer ça !!! Car si je dois récupérer 1.000.000 d'enregistrements cela prend pas mal de temps comme meme, car je recupere à chaque fois que 20.000 enregistrements, imaginez 10s* 1.000.000/20.000, si je me suis pas trompé ds mon calcul ca fait presque 500ms !!!! ce qui énorme je pense.

Ce qui le faut savoir par rapport à mon environement :

Environement de dev normal avec 2GO en mémoire super utilisé par plein de programmes.

J'utilise mysql, oui je suis daccord que c'est pas le meilleur choix pour les "grosses bases" mais c'est soit lui soit postgres, a priori postgres est meilleur en perf mais j'ai pas trouvé de benchmarks exacte qui parle de ça.

Le programme est lancé depuis Eclipse et c'est executé dans le coontexte d'une application web JSF

et enfin voila ma requete

Code:

---

1 2 3 4 5

request = from XXXX where (clientid= 'XXX' or clientid = 'YYY' or clientid = 'ZZZ') order by clientid,timecreation DESC Query query = session.createQuery(request); query.setFirstResult(firstIndex); query.setMaxResults(maxResult); List<XObjet> tmp = query.list();

---

voila je pense que vous avez tout :)

Pourriez vous m'aider à améliorer cela,

Merci pour vos retours

L'astuce consiste 90% du temps à ne charger que ce dont on a besoin. Hibernate est à double tranchant : facile d'utilisation mais il est tentant de se laisser emporter et ne plus maitriser entièrement ce que l'on fait.

Moi, à ta place, je regarderais si dans mes objets "client" il n'y a pas des données membres qu'il n'est pas nécessaire de charger, au moins dans un premier temps. Si après en avoir récupérer 1M on n'en traite que 1000, il sera intéressant de ne charger entièrement que ces 1000 clients...

Et si il faut tout charger, après tout, ça s'appelle un export de données, et ça c'est normal que ça prenne du temps...

Que fais tu des résultats que tu extrais ?

Combien de temps prend la requête traduite en SQL quand tu l'exécutes directement dans ton SGBD ?

Citation:

---

Envoyé par fr1man

Combien de temps prend la requête traduite en SQL quand tu l'exécutes directement dans ton SGBD ?

---

Et même, combien de temps sur le serveur de BDD et depuis ta machine ? Attention au transfert au niveau réseau d'un gros volume de données.

Merci pour vos reponses,

La requête si on l'execute directement sur MySql (base locale) ça prend 2.7705 sec et elle recupere 82 212 enregistrements.

Pour répondre à l'autre question, si je suis obligé de récupérer tout ces enregistrements.

J'ai deux raisons pour cela :

La premiére, je suis obligé dans la mesure où ces enregistrements sont affichés dans une table (constituée de n pages) et qu'il y a une option de recherche de type autocomplete qui permet de proposer des enregistrements en fonction de ce qui est tapé. Si javais pas cette option, j'aurai effectivement pu faire un chargement page par page.

La deuxième qui est la plus importante, c'est pour des raisons de performance. Ces données sont chargés dans des hashTable, ce qui me permet de les updater en temps record, si j'avais à consulter la base à chaque fois pour effectuer cela, ça aurait était très très long, surtout pour le type d'application que je developpe, qui reçoit sans arret des notifications d'update et d'ajout à des intervalles en millisecondes.


Par contre, j'ai remarqué que ce qui ralenti autant cette recherche c'était l'order by et surtout car je trier avec deux champs. J'ai remarqué aussi et j'ai trouvé bizar que la recuperation de 20.000 ce fait en moyenne en 10ms et que la récupération de 200.000 faisait en 14s. J'ai opté donc pour une grosse récupération à chaque fois, comme ça j'aurai moins de requête à effectuer.

Donc pour l'instant, le chargement est un peu long, en moyenne de 15s à 16s pour récupérer environ 100.000 champs. Ca reste long mais un peu "acceptable". Je voudrais vraiment le réduire pour descendre au dessous de 5s

Merci encore

D'après ce que tu nous dis, c'est surtout la quantité de données que tu extrais qui te donne ce temps de réponse si long.
Tu as des contraintes, mais à mon avis, retourner autant de données n'est pas la bonne solution.
Il vaut souvent mieux faire beaucoup de petites requêtes rapides qu'une grosse.
A mon avis il faudra repenser la conception pour éviter de remonter tous ces enregistrements.

Moi ce que j'ai remarqué c'est que de toute façon la requête prend beaucoup de temps même si on récupère peu d'enregistrements (20.000 c'est rien normalement), Ce que j'arrive pas à expliquer, car j'ai une table normale avec des string qui a aucune liaison, aucune clé étrangère, set ... C'est pour ça je trouve bizarre ce temps de réponse.

Pour la conception, je pense qu'on a fait le meilleure choix, car on avait à un moment du choisir entre performance de mise à jour ou la mémoire. Puisque notre appli est une appli web qui se met à jour en temps réel, c'était évident de pencher vers les prefs de maj, on a crée donc des hashTable pour remplacer en quelque sorte la BD, même si ça prend assez de mémoire. Le seul moment ou on a une interaction avec la base c'est pour remplir ces hashtable est là malheureusement c'est pas performant ):

Dans notre cas donc autant attendre un peu pour le chargement et avoir par la suite une maj en temps réel, que d'avoir un chargement rapide et du pseudo TR. Maintenant si je peux gagner encore quelques secondes pour le chargement ça serait super, sinon je ferai avec ...

merci bien