Vários acessos ao banco de dados ou um acesso massivo?

25

O que é uma abordagem melhor quando se trata de desempenho e utilização óptima dos recursos: acessando um múltiplo banco de dados vezes através de AJAX para só obter a informação exata necessária quando é necessário, ou executar um acesso para recuperar um objeto que contém todas as informações que possam ser necessárias , com uma alta probabilidade de que nem tudo seja realmente necessário?

Eu sei como comparar as consultas reais, mas não sei como testar o que é melhor quando se trata de desempenho do banco de dados quando milhares de usuários estão acessando o banco de dados simultaneamente e como o pool de conexões entra em jogo.

performance sql

— DudeOnRock
fonte

qual plataforma você está usando? se LAMP u CUD usar memcaching

— ravi404

Assim como qualquer outra otimização de desempenho, você a mede.

— Telastyn 18/12/12

2

@Telastyn: Estou fazendo algumas decisões fundamentais sobre o design e não tenho um servidor de teste. Todas as minhas chamadas de db são para aa db que reside na mesma máquina em que o php é executado. Eu esperava aprender com a experiência de outras pessoas a esse respeito, antes de perceber que o caminho que decidi seguir era ótimo quando tudo era local, mas sub-ideal quando levado ao vivo.

— DudeOnRock

1

@DudeOnRock - aceno , em geral, depende de seus padrões de uso e como as alterações de dados. Se uma consulta fornecer 80% do que as pessoas precisam e os dados não forem alterados com frequência, siga com isso. Fácil de armazenar em cache, fácil de otimizar. Se uma consulta retornar como 5% do que os usuários geralmente precisam, talvez não. Eu tenderia a mais consultas do que menos. Você sempre pode cortá-los no servidor antes que ele chegue ao banco de dados. Mais difícil de desfazer 'tudo faz uma consulta'.

— Telastyn

@ravz: parece interessante!

— DudeOnRock

27

Não há uma resposta correta para isso; como qualquer otimização, depende muito do contexto / uso.

No entanto, considere o seguinte como regra geral:

x
+: Data is stable / static
-: Data is dynamic / volatile

y
+: Data is frequently used
-: Data is infrequently used

++: fetch large chunks in the fewest number of fetches 
    and persist the data as long as possible within tolerances for staleness.

+-: do what is expedient to the logic & usage; if it is convenient to 
    fetch / calc as needed do so, if it is convenient to pre-fetch and 
    persist then do so. Seek to optimize only if absolutely necessary.

-+: fetch / calc as needed; but if optimization is required consider 
    pre-fetching or pre-calculating if possible, or negotiate a tolerance 
    for less than real time accuracy to reduce volatility.

--: fetch / calc as needed and don't worry about it further unless a 
    specific case is unacceptably expensive; if so see -+.

— Ed Hastings
fonte

24

Lembre-se da primeira regra de otimização: meça, não adivinhe . Experimente os dois, instrumente-os com algum tipo de código de cronômetro e veja o que leva mais tempo.

E também lembre-se da velha piada de que "existem apenas dois problemas difíceis na ciência da computação: invalidar cache e nomear bem as coisas". Se você extrair tudo do banco de dados de uma só vez e mantê-lo na memória, terá um cache. E agora você tem um novo problema: sempre que algo muda em qualquer lugar do sistema , ele precisa fazer a mesma alteração em dois locais: o banco de dados e o cache. Se você tiver mais de um servidor conversando com o banco de dados ou várias APIs para fazer o servidor modificar dados, isso pode se tornar muito complicado muito rapidamente.

— Mason Wheeler
fonte

E tenha certeza do que você mede. Por exemplo, os resultados podem variar dependendo da largura de banda e latência da conexão com o banco de dados.

— precisa saber é o seguinte

4

Não há solução de bala de prata para esta pergunta. Eu acho que você precisa TENTAR as possíveis compensações e ajustar o (s) servidor (es) para obter o melhor dele.

Primeiro ponto: antes de começar a fazer melhorias, você precisa definir seu benchmark de desempenho atual , medi-lo e tomar uma linha de base na comparação de possíveis soluções para melhorá-lo.

A segunda coisa é que o uso do aplicativo precisa ser rastreado. A maneira como o aplicativo é utilizado pelos usuários finais. Reduzir os números brutos de dados retornados que não são necessários para o (s) usuário (s) final (is) pode economizar muito recursos preciosos do servidor . Por exemplo: não faz sentido retornar 5000 registros enquanto os usuários estão interessados nos 50 primeiros.

Terceiro ponto: você precisa entender a frequência das chamadas e possíveis implicações. Por exemplo: se a maioria das chamadas são consultas de tabela de valores de pesquisa, você provavelmente criaria uma infraestrutura para armazenar em cache essas chamadas . Em outras palavras, se seus dados não estiverem sendo alterados com frequência, considere a opção de cache. E, é claro, minimizar o número de chamadas sempre deve ajudar a aumentar o desempenho.

— EL Yusubov
fonte

2

Obter tudo de uma vez dará a você um melhor desempenho, a menos que "tudo" inclua itens como BLOBs ou objetos de dados igualmente grandes. A sobrecarga de desempenho para serializar tudo, movê-lo pela conexão e desserializar na outra extremidade é bastante significativa, com a latência da rede sendo uma grande parte dele. A memória é mais barata que a largura de banda da rede e provavelmente permanecerá assim por algum tempo ainda. Sua única resposta real virá de uma referência, mas se você está apenas tentando avaliar uma sobre a outra, é assim que eu me inclino.

— TMN
fonte

De acordo com os comentários, isso está usando um banco de dados local, então não há latência "over the wire" aqui.

— Mason Wheeler

1

De acordo com os comentários, ele estava procurando estratégias que não seriam "ótimas quando tudo era local, mas sub-ideal quando levadas ao vivo".

— TMN

1

Se você estiver tomando uma decisão arquitetônica, o REST é uma opção. Com o REST, você sempre solicita um recurso várias vezes, ou seja, não envia uma solicitação para obter 2 objetos porque cada objeto tem seu próprio URL. A preocupação com o desempenho desse estilo provavelmente será resolvida quando o HTTP / 2.0 for lançado. Caso contrário, você apenas otimiza para torná-lo o mais rápido possível. Muitas empresas estão fazendo dessa maneira.

— imel96
fonte