performance - NHibernate HQL vs CriteriaAPI vs QueryOver vs Linq. Actuación
icriteria (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 procesar 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.
A modo de ejemplo, hemos estado desarrollando una aplicación que ejecutaba cientos de consultas QueryOver por segundo (usando el soporte de procesamiento por lotes ADO.NET) y descubrimos que convertir las consultas a ICriteria casi duplicaba nuestra capacidad de ejecutar consultas Y reducía a la mitad el uso de la CPU. 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 usar si sus consultas se generan dinámicamente.
¿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: amplié 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 VoteUp. No lo sé. Esto es realmente más discusión que una pregunta.
Aún no he encontrado ninguna diferencia entre los dos. Dicho esto: hql tiene una funcionalidad que no está disponible en Criteria-API.
En general, se trata de una cuestión de estilo y preferencia personal si utiliza el primero o el segundo. 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
Las características de rendimiento entre ICriteria y HQL varían poco (no sé sobre QueryOver) por una simple razón.
Las consultas de ICriteria tratarán por defecto de implementar sus estrategias de búsqueda como se define en su mapeo, mientras que HQL considera por defecto todo lo 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, por ejemplo, IQuery.SetInt32 ("fooParam", 5);
Lo que realmente importa es la capacidad de conexión de las consultas de ICriteria (ver ICriteria.CreateCriteria (). CreateCriteria () etc) donde el motor de NH tendrá que resolver el ICriteria e intentar generar el SQL más válido.
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 el mapeo dará como resultado una generación sql más concisa así como la operación NHibernate, por ejemplo, para mapear las propiedades de la cadena la Length en .hbm.xml dará como resultado que NHibernate verifique las longitudes de las cuerdas antes de ir a la base de datos.
En lo que respecta a QueryOver, espero que el rendimiento sea idéntico a la API de Criteria, ya que está construida 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 "formula" la consulta tiene más relación con el rendimiento que 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.