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

[Carlos Andrade]

Muito obrigado pela explicação.

Em Thu, 10 Jan 2019 14:54:22 -02000, Eduardo Jedliczka 
<edujed em gmail.com> escreveu:
> (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
> ==========================