NHibernate HQL vs CriteriaAPI vs QueryOver vs Linq. Rendimiento

Question

¿Cuáles son las diferencias de rendimiento entre hql y criteriaApi y QueryOver? ¿Hay alguna situación donde uno es más rápido o más lento que el otro?

Editar: He extendido la pregunta con QueryOver y Linq.

====================================

Bueno, no estoy seguro de qué respuesta marcar como respuesta, así que marcaré las publicaciones con la mayoría de los votos. No lo sé. Esto es realmente más discusión que una pregunta.

Answer 1

Las características de rendimiento entre ICriteria y HQL puede variar a poco (no sé acerca QueryOver) por una sencilla razón.

Las consultas de ICriteria intentarán implementar sus estrategias de recuperación según lo definido en su asignación, mientras que HQL considera por defecto Lazy y depende de sus declaraciones de unión dentro de su consulta para definir lo que se busca con impaciencia o no.

Además, ICriteria depende del mapeo para el paso de parámetros, mientras que HQL permite tipos de parámetros explícitos, p. IQuery.SetInt32 ("fooParam", 5);

Lo que realmente importa es la enchufabilidad de consultas ICriteria (ver ICriteria.CreateCriteria(). CreateCriteria(), etc.) donde el motor NH tendrá que resolver el ICriteria y tratar de generar el SQL más válida.

En el lado opuesto es probablemente más fácil de predecir si una consulta HQL producirá resultados consistentes y, por lo tanto, facilita el uso de QueryCache.

De cualquier forma, la configuración se genera una vez con la creación de ISessionFactory y las definiciones de asignación y lo que no está en la memoria, por lo que el rendimiento es bueno.

La generación de SQL real se realiza de forma diferente entre los dos y esa es la razón por la que una utilidad para ICriteria -> HQL no existe.

Al final, mi experiencia me ha demostrado que el rendimiento entre los 2 es probablemente el mismo dar o tomar algunos milisegundos.

Como nota al margen, declarar tanto como sea posible en la asignación dará como resultado una generación sql más concisa así como la operación NHibernate, por ejemplo, para la asignación de propiedades de cadena Length en .hbm.xml resultará en una cadena de comprobación NHibernate longitudes antes de ir a la base de datos.

Answer 2

Todavía no he encontrado ninguna diferencia entre los dos. Dicho esto: hql tiene una funcionalidad que no está disponible en Criteria-API.

Principalmente es una cuestión de estilo y preferencia personal si utiliza el primero o el último. Y la traducción de su consulta a SQL no representa mucho cuando se trata de consultas.

De las personas que saben más que yo: http://ayende.com/Blog/archive/2009/06/01/nhibernate-queries-ndash-should-i-use-hql-or-criteria.aspx

Answer 3

En lo que respecta a QueryOver, espero que el rendimiento sea idéntico al API de Criteria, ya que está construido como una extensión de esa API. Por lo tanto, para consultas equivalentes en las dos API esperaría que se genere la misma consulta de base de datos. La única diferencia que he notado entre las interfaces QueryOver y Criteria es que encuentro que la interfaz QueryOver es más "limpia" y más agradable de trabajar.

En mi experiencia, la API Criteria ha recibido más "amor" que la interfaz HQL. Me he encontrado con casos en los que podía expresar ciertas consultas con la interfaz de criterios que no pude encontrar de manera equivalente para expresar en la interfaz HQL.

En cuanto al rendimiento, encuentro que la forma en que se "pregunta" la consulta tiene más relación con el rendimiento que con la selección de Criteria API versus HQL versus QueryOver. Usaría la interfaz que le proporciona el ajuste más natural a su pensamiento.

Answer 4

QueryOver es un muy buen reemplazo para Criteria en la mayoría de los aspectos debido a la sintaxis mejorada y la seguridad de tipo. Sin embargo, debe tenerse en cuenta que el procesamiento de las expresiones lambda en QueryOver puede ser costoso (y supongo que lo mismo se aplicaría a las consultas LINQ). Por lo tanto, aunque la ejecución de la consulta SQL final no lleva más tiempo que otros métodos (ICriteria, HQL), la conversión del objeto de consulta a la consulta SQL apropiada lleva más tiempo.

Como ejemplo, hemos estado desarrollando una aplicación que ejecutaba cientos de consultas QueryOver por segundo (utilizando el soporte de procesamiento por lotes ADO.NET) y descubrimos que convertir las consultas a ICriteria casi duplicaba nuestra capacidad de ejecutar consultas Y dividíamos a la mitad uso. Supongo que la sobrecarga involucrada en el procesamiento de la expresión lambda puede reducirse en gran medida si utiliza el caché de segundo nivel y el caché de consultas; pero como esto no es adecuado para nuestra aplicación, no lo hice yo mismo.

En cuanto a su pregunta más general sobre cuál es más rápido: realmente depende. La única forma segura de contar es ejecutando una herramienta de creación de perfiles (NHProf funciona de maravilla para escenarios como este). Pero en términos generales, HQL es el más cercano a SQL y, por lo tanto, es el más flexible, lo que le permite un alcance un poco mayor para optimizar sus consultas. Sin embargo, para la gran mayoría de las consultas de complejidad simple a intermedia, hay poca o ninguna diferencia entre ICriteria y HQL. Y las consultas de ICriteria son mucho más fáciles de utilizar si sus consultas se generan dinámicamente.