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

Sex Jan 11 17:54:31 -03 2019

Boa tarde Cantu!

Gostei da sua análise, mas fiquei com uma dúvida: você mencionou que o
Firebird não tem como "enfiar" o where na procedure; Quando estamos falando
de views, isso é possível?

Exemplo: digamos que o select da view "crua" (sem where) retorne 1.000
registros, e o where adicionado externamente limite o resultado a 10
registros; A performance será a mesma se eu copiar o select que está
contido na view e adicionar o where ao mesmo?

Abraço.

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

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