CDS – Performace de Consultas


Olá pessoal,

Desde o dia em que escrevi sobre consultar o CDS através do SQL, fiquei pensando em fazer um outro post que realize uma comparação com diversos de tipos de tecnologias que temos para fazer consultas no CDS. Pois bem, hora de colocar em prática a ideia!

 

Como podem ver na figura acima, existem diversas formas de realizar consultas no CDS, minha comparação em relação a performance, será utilizando os seguintes tipos:

  • FetchXML
  • QueryExpression
  • LINQ (Early Bound)
  • LINQ (Late Bound)
  • PFE Dynamics Core Library (third-party library)
  • SQL for CDS

*Existem ainda mais outras formas como através da classe ExecuteMultipleRequest, Parellel.For, dentre outras. Porém eu não obtive bons resultados, ou ainda, devido ao fato de que em nenhuma consulta eu estar limitando a quantidade de resultados retornados ou previamente determinando a quantidade de registros que será retornada, não foi possível realizar um teste que não favorecesse/desfavorecesse o resultado obtido. Por isso, optei por não utilizar.

Bom, por mais que ideia de fazer o post tenha aparecido nos últimos dias, há mais de três anos eu fiz um post parecido no qual comparava os tipos de consultas que tínhamos na época, CDS ainda era chamado de base de dados do Dynamics 365, .Net Framework era outra versão e o mais importante, não tínhamos a opção de acessar o SQL. Assim um novo post se faz necessário!

Cenário dos Testes

O cenário/contexto de todas as consultas consistiu em recuperar todos os registros de contas (accounts) de minha organização. Eu importei mais de 500 mil registros, 505.163 para ser mais exato. Meio milhão de registros é algo considerável para termos números confiáveis para avaliar.

Como falei anteriormente, em nenhuma consulta eu estou pre-determinando quando registros eu desejo recuperar. Sempre estou requisitando todos os registros de conta, retornando as colunas “accountid” e “name”.

Para garantir que os resultados retornados são bem confiáveis, eu executei cada tipo de consulta por 100 vezes, desta forma, a média é um número justo dada a quantidade de vezes que foi checado.

Outro ponto importante, é o fato que eu não utilizar a conexão da consulta A para a consulta B. Todas minhas conexões são criadas isoladamente e não existe consulta sendo executada enquanto outra está sendo.

Resultados

Após executar todas as consultas, recuperei os resultados, vejam abaixo o gráfico com o tempo médio (após 100 execuções) para recuperar 505.163 registros da entidade conta (account):

Sim! SQL for CDS destruiu seus desafiantes, com média de 21 segundos! É muito mais rápido que o segundo colocado LINQ (Late Bound) que registrou média de 53 segundos.

Fazendo as contas… SQL for CDS é 252% mais rápido que LINQ (Late Bound)!

Fazendo uma extrapolação com os números, conseguiriámos recuperar aproximadamente 1.5 milhões de registros em 1 minuto utilizando SQL for CDS contra menos de 600 mil registros no mesmo 1 minuto para o LINQ (Late Bound).

Um ponto curioso que este novo teste trouxe, foi de que a biblioteca PFE não foi mais rápida do que as consultas em LINQ, fato que não ocorreu no meu post de três anos atrás. Assim, ou a Microsoft conseguiu prover melhorias nas consultas usando LINQ, ou PFE perdeu seu potencial ao longo do tempo.

Falando ainda das consultas utilizando LINQ, vejam que a diferença é muito pequena dentre eles, apenas 2s na média. Desde modo, fica realmente ao seu critério selecionar o tipo que desejar utilizar.

QueryExpression e FetchXML mostraram mais uma vez que não devem ser utilizadas quando o volume de dados é grande. Ambos são bons para consultar entidades de baixo volume de dados, mas só.

Se desejar ver mais informações dos resultados, fiz este outro gráfico com mais detalhes:

Todo o código que utilizei para realizar estes testes, pode ser visualizado no meu GitHub.

Fique com essa dica em mente para seus próximos projetos, isso pode lhe ajudar a melhor escolher qual tecnologia utilizar!

[]’s,

Tiago

 

Deixe um comentário

Este site utiliza o Akismet para reduzir spam. Saiba como seus dados em comentários são processados.