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

[Eduardo Jedliczka]

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

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

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

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

Mas pense comigo...

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

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



==========================
Eduardo Jedliczka
Curitiba - Pr
==========================


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

> Qualquer comando SQL será processado no servidor, e não no cliente.
>
> Opção 1) Somente 3 campos sendo trafegados entre servidor e cliente,
> quanto menos trafego, mais rapido obtem-se o retorno total dos dados
> no cliente.
>
> Opção 2) Também somente 3 campos sendo trafegados, mas nesse exemplo,
> vc colocou um WHERE que provavelmente restringirá o número de
> registros retornados, portanto, menos trafego.
>
> Opção 3) Se tivesse colocado o WHERE no select (como no exemplo 2), a
> performance seria um pouco pior, já que o Firebird não teria a
> capacidade de "enfiar" o WHERE no select que está dentro da procedure.
> Não vejo vantagem no uso de procedure nesse exemplo.
>
> Tem outras coisas a serem analisadas, e o exemplo usado nas 3 opções
> não é o mesmo... duas não tem where, uma tem... isso torna difícil
> fazer uma comparação justa. A decisão de usar procedures e views não
> deve ser tomada apenas se baseando em consumo de recursos... tem
> muitos outros fatores que podem influenciar mais essa decisão do que o
> próprio fator "consumo"... por exemplo, controle de acessos, etc.
>
> []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
>
> 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?
>
>
> ______________________________________________
> 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
>