[firebase-br] Melhor opção para Select

Carlos H. Cantu listas em warmboot.com.br
Qui Jan 10 16:36:38 -03 2019


EJ> (Estou meio sumido... mas lá vão meus 0.02C)

Bem vindo de volta :-)

[]s
Carlos H. Cantu
eBook Guia de Migração para o FB 3 - www.firebase.com.br/guiafb3.php
www.FireBase.com.br - www.firebirdnews.org - blog.firebase.com.br

EJ> (Estou meio sumido... mas lá vão meus 0.02C)


EJ> Existem muitas coisa em jogo nesta discussão... cache hit/miss,
EJ> velocidade e latência de rede, quantidade de memória tanto no
EJ> cliente quanto nos servidores de banco e aplicação... então nunca existe uma resposta fácil...



EJ> Mas algumas métricas ajudam... 

EJ> A pior coisa que existe é trafegar coisas numa rede lenta, depois
EJ> ler coisas do disco (especialmente quando os discos são lentos)...
EJ> então existem muitas aplicações com níveis (tamanhos/locais/
EJ> prioridades e técnicas diferentes) de cache... O protocolo/formato
EJ> utilizado para transportar os dados, muitas vezes pode ter um
EJ> impacto extremamente agressivo (seja positivo quanto negativo). 



EJ> Lembre-se que "geralmente" CPU é barato e abundante... 




EJ> Mas pense comigo...  


EJ> - Quanto menos dados sua consulta retornar, menos CPU e tráfego
EJ> de rede serão necessário entre o servidor de banco e o servidor de
EJ> aplicação, e menos memória será necessário em todos os locais.

EJ> - Quanto mais requisições buscarem o mesmo range de dados, maior será CACHE HIT.
EJ> - Requisições muito pequenas dificilmente terão um bom CACHE HIT
EJ> (exceto se sempre serão poucos usuários/processos concorrentes),
EJ> requisições muito grandes podem não compensar o OVERHEAT.
EJ> - Algumas consultas exigem dados de várias tabelas, com
EJ> diferentes níveis de dependência. fazer tudo numa única consulta
EJ> SQL pode "literalmente" deixar a performance do banco pobre. fazer
EJ> tudo no servidor de aplicação irá desperdiçar as maiores vantagens e recursos do SGDB.
EJ> - Views simples raramente representam ganhos perceptíveis na
EJ> performance... wheres complexas podem forçar um FULL-SCAN piorando a resposta...
EJ> - select from procedures para consultas extremamente simples 
EJ> podem não compensar o custo (da performance, mas talvez ajude na
EJ> padronização e qualidade)... mas talvez permitam consultas com índices ótimos pela segmentação.
EJ> - é relativamente mais fácil medir a performance do banco de
EJ> dados (e criar/dropar índices, refatorar tabelas e procedures) do
EJ> que monitorar gargalos num servidor de aplicação.



EJ> Se tudo (cliente, aplicação e banco de dados) estiver num único
EJ> computador, 80% destas considerações serão inúteis. Se forem web,
EJ> latência e banda contam muito, se for rede local é um pouco menos crítico.






EJ> ==========================
EJ> Eduardo Jedliczka
EJ> Curitiba - Pr
EJ> ==========================


EJ> Em qui, 10 de jan de 2019 às 11:18, Carlos H. Cantu
EJ> <listas em warmboot.com.br> escreveu:

EJ> Qualquer comando SQL será processado no servidor, e não no cliente.

EJ>  Opção 1) Somente 3 campos sendo trafegados entre servidor e cliente,
EJ>  quanto menos trafego, mais rapido obtem-se o retorno total dos dados
EJ>  no cliente.

EJ>  Opção 2) Também somente 3 campos sendo trafegados, mas nesse exemplo,
EJ>  vc colocou um WHERE que provavelmente restringirá o número de
EJ>  registros retornados, portanto, menos trafego.

EJ>  Opção 3) Se tivesse colocado o WHERE no select (como no exemplo 2), a
EJ>  performance seria um pouco pior, já que o Firebird não teria a
EJ>  capacidade de "enfiar" o WHERE no select que está dentro da procedure.
EJ>  Não vejo vantagem no uso de procedure nesse exemplo.

EJ>  Tem outras coisas a serem analisadas, e o exemplo usado nas 3 opções
EJ>  não é o mesmo... duas não tem where, uma tem... isso torna difícil
EJ>  fazer uma comparação justa. A decisão de usar procedures e views não
EJ>  deve ser tomada apenas se baseando em consumo de recursos... tem
EJ>  muitos outros fatores que podem influenciar mais essa decisão do que o
EJ>  próprio fator "consumo"... por exemplo, controle de acessos, etc.

EJ>  []s
EJ>  Carlos H. Cantu
EJ>  eBook Guia de Migração para o FB 3 - www.firebase.com.br/guiafb3.php
EJ> www.FireBase.com.br - www.firebirdnews.org - blog.firebase.com.br

 CA>> Olá a todos! Depois de umas aulas sobre administração de banco de dados
 CA>> na faculdade, surgiu a curiosidade em pesquisar mais sobre como melhorar
 CA>> a performance do Servidor durante as consultas ao Firebird. Minha dúvida
 CA>> é a seguinte: Qual é a forma mais apropriada e que utilize menos 
 CA>> recursos de processamento e memória ao realizar Select na aplicação da
 CA>> máquina cliente? O "Select" é melhor ficar na Aplicação, criar uma 
 CA>> "View" ou "Stored Procedure"? Das situações que tenho em mente e que 
 CA>> venho testando, qual destas seria a melhor opção?

 CA>> Opção 1:
 CA>> Na Aplicação: " select ID, NOME, CPF from TB_CLIENTES "
 CA>> (Neste caso, é verdade que o processamento é feito mais na máquina 
 CA>> cliente, economizando recursos no Servidor?)

 CA>> Opção 2:
 CA>> Na Aplicação: " select ID, NOME, CPF from VW_CLIENTES where (NOME 
 CA>> starting with 'CARLOS') "
 CA>> No Servidor: VW_CLIENTES  -> "select ID, NOME, DATA_NASC, SEXO, RG, CPF,
 CA>> FONE1, FONE2 from TB_CLIENTES"
 CA>> (Neste caso, o fato de que a View esteja selecionando 8 campos e na 
 CA>> Aplicação somente 3 campos e com filtro, haveria processamento 
 CA>> desnecessário no Servidor?)

 CA>> Opção 3:
 CA>> Na Aplicação: " select ID, NOME, CPF from SP_CLIENTES "
 CA>> No Servidor: SP_CLIENTES  -> "select ID, NOME, DATA_NASC, SEXO, RG, CPF,
 CA>> FONE1, FONE2 from TB_CLIENTES"
 CA>> (Neste caso, a SP utiliza mais, menos ou o mesmo recurso de 
 CA>> processamento que uma View? É mais adequado ou não?)

 CA>> Existe mais alguma opção que seria mais apropriado que essas três, 
 CA>> visando claro menos utilização de recurso e processamento do Servidor?


EJ>  ______________________________________________
EJ>  FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
EJ>  Para saber como gerenciar/excluir seu cadastro na lista, use:
EJ> http://www.firebase.com.br/fb/artigo.php?id=1107
EJ>  Para consultar mensagens antigas:
EJ> http://www.firebase.com.br/pesquisa_lista.html





Mais detalhes sobre a lista de discussão lista