NHibernate HQL vs CriteriaAPI vs QueryOver vs Linq.Desempenho

Question

O que são as desempenho diferenças entre o hql e critériosApi e QueryOver?Existem situações em que um é mais rápido ou mais lento que o outro?

Editar:Estendi a questão com QueryOver e Linq.

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

Bem, não tenho certeza de qual resposta marcar como resposta, então marcarei as postagens com mais VoteUp.Não sei.Na verdade, isso é mais uma discussão do que uma pergunta.

Answer 1

As características de desempenho entre ICriteria e HQL variam pouco (não sei sobre QueryOver) por um motivo simples.

As consultas ICriteria tentarão, por padrão, implementar suas estratégias de busca conforme definido em seu mapeamento, enquanto o HQL, por padrão, considera tudo Preguiçoso e depende de suas declarações de junção dentro de sua consulta para definir o que é buscado com entusiasmo ou não.

Além disso, o ICriteria depende do mapeamento para passagem de parâmetros, enquanto o HQL permite tipos de parâmetros explícitos, por exemplo.IQuery.SetInt32("fooParam", 5);

O que realmente importa é a capacidade de conexão das consultas ICriteria (consulte ICriteria.CreateCriteria().CreateCriteria() etc), onde o mecanismo NH terá que resolver o ICriteria e tentar gerar o SQL mais válido.

Por outro lado, provavelmente é mais fácil prever se uma consulta HQL produzirá resultados consistentes e, como tal, facilita o uso do QueryCache.

De qualquer forma, a configuração é gerada uma vez com as definições de criação e mapeamento do ISessionFactory e outras coisas estão na memória, portanto, o desempenho é bom.

A geração real do SQL é feita de forma diferente entre os dois e é por isso que não existe um utilitário para ICriteria -> HQL.

No final, minha experiência me mostrou que o desempenho entre os 2 é provavelmente o mesmo, mais ou menos alguns milissegundos.

Como observação lateral, declarar o máximo possível no mapeamento resultará em uma geração de SQL mais concisa, bem como na operação do NHibernate, por exemplo, para propriedades de string mapeando o Length no .hbm.xml resultará na verificação do comprimento das strings pelo NHibernate antes de ir para o banco de dados.

Answer 2

No que diz respeito ao Queryover, esperaria que o desempenho seja idêntico à API de critérios, uma vez que é construída como uma extensão dessa API.Portanto, para consultas equivalentes nas duas APIs, eu esperaria que a mesma consulta de banco de dados seja gerada.A única diferença que anúncio entre as interfaces de Queryover e Critérios é que eu acho que a interface Queryover ser "limpo" e mais agradável para trabalhar.

Na minha experiência, a API de critérios recebeu mais "amor" do que a interface do HQL.Eu corri para os casos em que eu poderia expressar certas consultas com a interface de critérios que não consegui encontrar uma maneira equivalente de expressar na interface HQL.

Com relação ao desempenho, encontro a maneira como a consulta é "perguntada" tem mais rolamento no desempenho do que a seleção de critérios API versus HQL veryOver.Eu usaria a interface que lhe proporciona o ajuste mais natural ao seu pensamento.

Answer 3

Queryover é um substituto muito bom para critérios na maioria dos aspectos devido à melhora da sintaxe e da segurança do tipo. No entanto, deve-se notar que o processamento das expressões lambda no Queryover pode ser caro (e eu acho que o mesmo se candidataria às consultas do LINQ). Então, ao mesmo tempo em execução, a consulta do SQL End não é mais longa do que outros métodos (ICRiteria, HQL), a conversão do objeto de consulta para a consulta SQL apropriada demora mais.

Como um exemplo, estamos desenvolvendo um aplicativo que executava centenas de consultas de Queryover um segundo (usando o suporte de lote do ADO.NET) e encontramos a conversão das consultas para o ICRITITYIA quase dobrou nossa capacidade de executar consultas e despedir-se pela metade da CPU . Eu acho que a sobrecarga envolvida no processamento da expressão lambda pode ser muito reduzida se você usar o cache de cache e consulta de segundo nível; Mas como isso não é adequado para a nossa aplicação, eu não fiz isso sozinho.

Quanto à sua pergunta mais geral sobre a qual é mais rápido: isso realmente depende. A única maneira segura de dizer é executando uma ferramenta de perfil (NHProf Works Wonders para cenários como este). Mas geralmente falando, o HQL é o mais próximo do SQL e, portanto, o mais flexível, permitindo-lhe um pouco mais de escopo para otimizar suas dúvidas. No entanto, para a grande maioria das consultas de complexidade simples de intermediárias, há pouca ou nenhuma diferença entre o ICiteria e o HQL. E as consultas do ICRITERIA são muito mais fáceis de trabalhar se suas dúvidas forem construídas dinamicamente.

Answer 4

Ainda tenho que encontrar qualquer diferença entre os dois.Que é dito - o HQL tem funcionalidade que não está disponível na API de critérios.

Principalmente é uma questão de estilo e preferência pessoal se você usar o primeiro ou o último.E a tradução de sua consulta para o SQL não conta muito quando se trata de consultar.

das pessoas que sabem mais do que i: http://ayende.com/blog/archive/2009/06/01/nhibernate-queries-ndash-should-i-us-hql-or-citeria.aspx