performance - Criterios Hibernate vs HQL: ¿cuál es más rápido?

hibernate-criteria

Question

He estado leyendo algunos torres, pero todavía estoy confundido. ¿Por qué? porque las diferencias que has mencionado no se relacionan con el rendimiento. están relacionados con el uso fácil. (Objetc (criterios) y SQL (hql)). Pero me gustaría saber si los "criterios" son más lentos que hql por alguna razón.

Lo leí en otro torres

"Hay una diferencia en términos de rendimiento entre HQL y criteriaQuery, cada vez que ejecutas una consulta con criteriaQuery, crea un nuevo alias para el nombre de la tabla que no se refleja en el último caché consultado para ningún DB. Esto lleva a una sobrecarga de compilando el SQL generado, tomando más tiempo para ejecutar ". por Varun Mehta.

Esto está muy cerca ¡PERO! Lo leí en otro sitio web (http://gary-rowe.com/agilestack/tag/hibernate/) Este ya no es el caso con Hibernate 3.3 y versiones superiores (por favor, lea esto: 9) Hibernate es lento porque el SQL generado por el La interfaz de criterios no es consistente)

He hecho algunas pruebas tratando de descubrir las diferencias, pero ambas generan qry''s y no cambia el alias de la tabla.

Estoy muy confundido. Si alguien conoce el motivo principal, ¿podría ayudarnos? Gracias

Answer 1

Estoy trabajando en millones de discos. Descubrí que HQL es mucho más rápido que Criteria. Los criterios tienen un rendimiento mucho mayor.

Si está tratando con muchos datos, entonces vaya a HQL.

Answer 2

Principalmente prefiero Consultas de criterios para consultas dinámicas. Por ejemplo, es mucho más fácil agregar un poco de orden dinámicamente o dejar algunas partes (por ejemplo, restricciones) dependiendo de algún parámetro.

Por otro lado, estoy usando HQL para consultas estáticas y complejas, porque es mucho más fácil de entender / leer HQL. Además, HQL es un poco más potente, creo, por ejemplo, para diferentes tipos de unión.

JPA e Hibernate - Criterios contra JPQL o HQL

Answer 3

Soy el tipo que escribió el traductor de consultas Hibernate 3 en 2004, así que sé algo sobre cómo funciona.

Los criterios, en teoría, deberían tener menos sobrecarga que una consulta HQL (excepto para las consultas con nombre, a las que llegaré). Esto se debe a que Criteria no necesita analizar nada. Las consultas HQL se analizan con un analizador basado en ANTLR y luego el AST resultante se convierte en SQL. Sin embargo, con HQL / JPAQL puede definir consultas con nombre, donde el SQL se genera cuando se inicia SessionFactory. En teoría, las consultas con nombre tienen menos sobrecarga que Criteria.

Entonces, en términos de sobrecarga de generación SQL tenemos:

1. Llamada HQL / JPAQL con nombre: la generación de SQL ocurre solo una vez.
2. Criterios: no es necesario analizar antes de generar.
3. (sin nombre) HQL / JPAQL Query - Parse, luego genera.

Dicho esto, la elección de una técnica de consulta basada en la sobrecarga del análisis sintáctico y la generación de SQL es probablemente un error en mi opinión. Esta sobrecarga suele ser muy pequeña en comparación con la realización de una consulta real en un servidor de base de datos real con datos reales. Si esta sobrecarga realmente aparece al crear el perfil de la aplicación, entonces tal vez debería cambiar a una consulta con nombre.

Estas son las cosas que considero al decidir entre Criteria y HQL / JPAQL:

• En primer lugar, debe decidir si está de acuerdo con tener una dependencia de la API propietaria de Hibernate en su código. JPA no tiene Criteria.
• Los criterios son realmente buenos para manejar muchos parámetros de búsqueda opcionales , como los que puede encontrar en una página web típica con un "formulario de búsqueda" de parámetros múltiples. Con HQL, los desarrolladores tienden a abordar las expresiones de cláusulas where con StringBuilder (¡ evita esto! ). Con Criteria, no necesita hacer eso. Hardik publicó opiniones similares.
• HQL / JPAQL se puede usar para la mayoría de las otras cosas, porque el código tiende a ser más pequeño y más fácil de entender para los desarrolladores.
• Las consultas realmente frecuentes se pueden convertir en consultas con nombre si utiliza HQL. Prefiero hacer esto más tarde, después de algunos perfiles.

Answer 4

Tienes razón y no. La lista de resultados se recupera de la base de datos o el caché con la clase org.hibernate.loader.Loader . Cuando la memoria caché no está habilitada, la instrucción preparada se genera utilizando el objeto Dialect que se crea en SessionFactoryImp. Entonces, las declaraciones se inicializan por lista de llamadas. Además, la consulta de bajo nivel se genera automáticamente. Básicamente, es una ayuda, pero puede haber un caso en el que una consulta específica será más efectiva cuando se escriba manualmente.

Answer 5

Otras ventajas Creo que para Criteria sobre HQL :

Escribir HQL hace que el código sea complicado. Ya no parece escribir código limpio orientado a objetos.

Al escribir Consultas de criterios, IDE nos sugiere con Intellisense, por lo que hay menos posibilidades de cometer errores, excepto cuando escribimos algo así como nombres de variables entre comillas dobles.