[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