it-swarm-eu.dev

Critères d'hibernation vs HQL: quel est le plus rapide?

J'ai lu quelques réponses, mais je suis toujours confus. Pourquoi? car les différences que vous avez mentionnées ne sont pas liées aux performances. ils sont liés à une utilisation facile (Objetc (critères) et SQL (hql)). Mais je voudrais savoir si les "critères" sont plus lents que hql pour une raison quelconque.

J'ai lu ça dans une autre réponse

"Il existe une différence en termes de performances entre HQL et critèresQuery, chaque fois que vous lancez une requête à l'aide de critèresQuery, il crée un nouvel alias pour le nom de table qui ne reflète pas dans le dernier cache interrogé pour n'importe quelle base de données. Cela conduit à une surcharge de la compilation du SQL généré, ce qui prend plus de temps à exécuter. " par Varun Mehta.

C'est très proche MAIS! j'ai lu sur un autre site Web (http://gary-rowe.com/agilestack/tag/hibernate/) Ce n'est plus le cas avec Hibernate 3.3 et supérieur (veuillez lire ceci: 9) Hibernate est lent car le SQL généré par le L'interface des critères n'est pas cohérente)

J'ai fait un test en essayant de trouver les différences, mais les deux génèrent des qry et cela ne change pas l'alias de la table.

Je suis très confus. Si quelqu'un connaît la raison principale, pourriez-vous nous aider. Merci

63
kcobuntu

Je suis le gars qui a écrit le traducteur de requêtes Hibernate 3 en 2004, donc je sais quelque chose sur son fonctionnement.

Les critères, en théorie, devraient avoir moins de frais généraux qu'une requête HQL (sauf pour les requêtes nommées, que j'aborderai). C'est parce que les critères n'ont besoin d'analyser rien. Les requêtes HQL sont analysées avec un analyseur basé sur ANTLR, puis le résultat AST est transformé en SQL. Cependant, avec HQL/JPAQL, vous pouvez définir des requêtes nommées, où le SQL est généré au démarrage de SessionFactory. En théorie, les requêtes nommées ont moins de frais généraux que les critères.

Ainsi, en termes de surcharge de génération SQL, nous avons:

  1. Requête HQL/JPAQL nommée - La génération SQL ne se produit qu'une seule fois.
  2. Critères - Pas besoin d'analyser avant de générer.
  3. (non nommé) Requête HQL/JPAQL - Analyser, puis générer.

Cela dit, choisir une technique de requête basée sur la surcharge d'analyse et de génération SQL est probablement une erreur à mon avis. Cette surcharge est généralement très faible par rapport à l'exécution d'une requête réelle sur un serveur de base de données réel avec des données réelles. Si cette surcharge apparaît réellement lors du profilage de l'application, alors peut-être vous devriez passer à une requête nommée.

Voici les éléments que je considère lors du choix entre les critères et HQL/JPAQL:

  • Tout d'abord, vous devez décider si vous êtes [~ # ~] ok [~ # ~] avec un dépendance à Hibernate- API propriétaire dans votre code. JPA n'a pas de critères.
  • Les critères sont vraiment bons pour gérer de nombreux paramètres de recherche facultatifs comme vous pouvez le trouver sur une page Web typique avec un "formulaire de recherche" multi-paramètres. Avec HQL, les développeurs ont tendance à s'attaquer aux expressions de clause where avec StringBuilder (éviter cela!). Avec Criteria, vous n'avez pas besoin de le faire. Hardik a publié des opinions similaires.
  • HQL/JPAQL peut être utilisé pour la plupart des autres choses, car le code a tendance à être plus petit et plus facile à comprendre pour les développeurs.
  • Les requêtes très fréquentes peuvent être transformées en requêtes nommées si vous utilisez HQL. Je préfère le faire plus tard, après quelques profils.
141
Joshua Davis

Je travaille sur des millions d'enregistrements. J'ai trouvé que HQL est beaucoup plus rapide que Criteria. Les critères accusent beaucoup de retard dans les performances.

Si vous traitez beaucoup de données, optez pour HQL.

9
Rajeev

Autres avantages je pense pour les critères sur HQL:

L'écriture de HQL rend le code désordonné. Cela ne ressemble plus à l'écriture de code orienté objet propre.

Lors de l'écriture de requêtes de critères, IDE nous suggère avec Intellisense, donc il y a moins de chance de commettre des erreurs sauf lorsque nous écrivons quelque chose comme des noms de variables entre guillemets.

5
omkar sirra

Je préfère principalement les requêtes de critères pour les requêtes dynamiques. Par exemple, il est beaucoup plus facile d'ajouter dynamiquement de la commande ou de laisser certaines parties (par exemple des restrictions) en fonction de certains paramètres.

D'un autre côté, j'utilise HQL pour des requêtes statiques et complexes, car il est beaucoup plus facile de comprendre/lire HQL. En outre, HQL est un peu plus puissant, je pense, par exemple pour différents types de jointures.

JPA et Hibernate - Critères vs JPQL ou HQL

5
Hardik Mishra

Vous avez raison et non. La liste des résultats est récupérée de la base de données ou du cache avec le org.hibernate.loader.Loader classe. Lorsque le cache n'est pas activé, l'instruction préparée est générée à l'aide de l'objet Dialect qui est créé dans SessionFactoryImp. Ainsi, les instructions sont soit initialisées par appel de liste. De plus, une requête de bas niveau est générée automatiquement. Fondamentalement, c'est une aide, mais il peut y avoir un cas où une requête spécifique sera plus efficace lorsqu'elle sera écrite manuellement.

3
Simon