Dúvida sobre Performace

1 visualização
Pular para a primeira mensagem não lida

Marcel Araujo

não lida,
27 de nov. de 2009, 06:07:3227/11/2009
para list...@googlegroups.com, tche...@googlegroups.com
Galera, me deparei com uma questão esta semana sobre o que me proporcionaria uma melhor performace:

-Salvar os dados de uma imagem na base de dados ou salvar apenas em disco???

Na minha opinião em disco será mais rápido pois não necessitarei realizar uma consulta, criar uma variável temporária com o conteúdo do arquivo e exibir por exemplo, a imagem.

Qual opinião de vocês???

--
Abraços......

Marcel Araujo
System Analyst
Developer Java/PHP/RIA
Linux User #490101
http://www.kombo.com.br/meucurriculo/marcelaraujo
http://www.twitter/marcelaraujo

Sérgio

não lida,
27 de nov. de 2009, 08:19:0627/11/2009
para tche...@googlegroups.com
Certamente salvar em disco. Banco de dados não é feito para dados
binários e, ao menos que você tenha uma boa razão para isso, não deve
ser utilizado para gravar dados binários.

A princípio vejo dois problemas graves:
a) Gravando no banco de dados, você sempre terá a latência da rede
entre o banco e a aplicação para a resposta;
b) Ao utilizar banco, você sempre vai precisar tratar o dado na
aplicação para enviar ao navegador (setar headers para mime, cache,
tamanho, etc...);

Outra questão é que este conteúdo pode ser servido por um servidor
HTTP leve como o lighttpd ou o nginx, ampliando drasticamente a
performance da sua aplicação.

"MySQL is used to store image metadata only. This seems pretty
standard. Almost nobody seems to store important blobs in the database
because it slows down database operations."
http://highscalability.com/secrets-fotologs-scaling-success

Abraço,
Sérgio

2009/11/27 Marcel Araujo <cece...@gmail.com>:

Fabio Olive Leite

não lida,
27 de nov. de 2009, 08:37:2227/11/2009
para tche...@googlegroups.com
Olá!

On 2009-11-27 Sérgio wrote:
>
> Outra questão é que este conteúdo pode ser servido por um servidor
> HTTP leve como o lighttpd ou o nginx, ampliando drasticamente a
> performance da sua aplicação.

Realmente essa é uma ótima idéia... deixa um images.empresa.com.br
rodando um lighttpd ou thttpd só com arquivos estáticos e imagens
otimizadas para web, que todos saem ganhando. Este tipo de servidor
simples geralmente não dá nenhum problema de segurança e etc pra
incomodar, e permite que o servidor de verdade tenha apenas o que
importa mesmo, que será o conteúdo dinâmico e BD.

Abraços,
Fábio Olivé
--
ex sed lex awk yacc, e pluribus unix, amem
na matemática das idéias, permuta é igual a adição
e um debate inteligente implementa a multiplicação

Mauricio Mauad Menegaz Filho

não lida,
27 de nov. de 2009, 08:41:2827/11/2009
para tche...@googlegroups.com
Buenas!

2009/11/27 Sérgio <sur...@gmail.com>:


>
> Certamente salvar em disco. Banco de dados não é feito para dados
> binários e, ao menos que você tenha uma boa razão para isso, não deve
> ser utilizado para gravar dados binários.

Calma. Nem todo o banco, e nem toda a ocasião; ou seja, em geral, mas
nem sempre. No oracle, por exemplo, o BLOB pode ficar no cache, e daí
não tem disco que faça frente à velocidade de acesso à SGA. Assim,
para imagens que são escritas numa taxa muito menor do que são lidas,
pode até ser jogo partir pra um blob. Mas nem tudo são flores...

Blobs são bichos chatos, e podem te trazer problemas mesmo. Todo caso,
teu problema poderia ser descrito de forma mais detalhada (que banco,
qual a natureza do acesso às imagens), pois essa solução "geral" de
que o filesystem é mais rápido é referencial, é meramente acadêmica.


Abraço
Mauad

Eduardo Kienetz

não lida,
27 de nov. de 2009, 10:39:0027/11/2009
para tche...@googlegroups.com
2009/11/27 Mauricio Mauad Menegaz Filho <mma...@gmail.com>:
> Buenas!

>
> Calma. Nem todo o banco, e nem toda a ocasião; ou seja, em geral, mas
> nem sempre. No oracle, por exemplo, o BLOB pode ficar no cache, e daí
> não tem disco que faça frente à velocidade de acesso à SGA. Assim,
> para imagens que são escritas numa taxa muito menor do que são lidas,
> pode até ser jogo partir pra um blob. Mas nem tudo são flores...
>
> Blobs são bichos chatos, e podem te trazer problemas mesmo. Todo caso,
> teu problema poderia ser descrito de forma mais detalhada (que banco,
> qual a natureza do acesso às imagens), pois essa solução "geral" de
> que o filesystem é mais rápido é referencial, é meramente acadêmica.

Concordo. Eu por exemplo costumo definir um tamanho máximo de arquivo
que será armazenado num BLOB, passando do limite vai para filesystem e
só aponto o caminho. Assim tenho a praticidade, velocidade e possíveis
demais características que o BD me oferece.

[]s

--
Eduardo Bacchi Kienetz

Sérgio

não lida,
27 de nov. de 2009, 10:47:1027/11/2009
para tche...@googlegroups.com
>> Certamente salvar em disco. Banco de dados não é feito para dados
>> binários e, ao menos que você tenha uma boa razão para isso, não deve
>> ser utilizado para gravar dados binários.
>
> Calma. Nem todo o banco, e nem toda a ocasião; ou seja, em geral, mas
> nem sempre. No oracle, por exemplo, o BLOB pode ficar no cache, e daí
> não tem disco que faça frente à velocidade de acesso à SGA. Assim,
> para imagens que são escritas numa taxa muito menor do que são lidas,
> pode até ser jogo partir pra um blob. Mas nem tudo são flores...
>

O problema de salvar no banco é complementado pelo fato da aplicação
ter que tratar as imagens sempre que for requisitado. Isso gera um
overhead desnecessário, maiores possibilidades de problemas de
desempenho devido a problemas na aplicação, etc...

Como exemplo de problemas de desempenho podemos destacar:

* Erros na manipulação de headers; (não enviar informações de cache,
por exemplo)
* No caso de estar utilizando PHP, a configuração do servidor pode
iniciar a sessão automaticamente (a qual, por padrão, é salva em
disco), fora isso a sessão do PHP sempre envia os headers para que os
dados não sejam cacheados;
* Overhead de mais um processo (ou módulo) manipulando os dados e
trafego de rede do banco de dados para a aplicação;
* Maior consumo de memória, pois será necessário alocar o conteúdo
blob inteiro em memória (primeiro no banco e depois na aplicação); Em
contra-partida, no caso de arquivos, a maioria dos servidores web
entrega o arquivo em stream, utilizando muito menos recursos;

Se o caso é cache, acho mais negócio pensar em utilizar o squid (ou
algum outro servidor que suporte proxy e cache em memória) como
servidor proxy reverso, o qual também irá manter as imagens (e ainda
de brinde, javascript, css, imagens de template, etc...) em memória
reduzindo o estresse sobre os discos ;)

Acho que a única vantagem de se utilizar BLOB é que facilita o backup.

Abraço,
Sérgio

Rafael Jeffman

não lida,
27 de nov. de 2009, 11:38:0627/11/2009
para tche...@googlegroups.com
2009/11/27 Sérgio <sur...@gmail.com>:

>
> O problema de salvar no banco é complementado pelo fato da aplicação
> ter que tratar as imagens sempre que for requisitado. Isso gera um
> overhead desnecessário, maiores possibilidades de problemas de
> desempenho devido a problemas na aplicação, etc...
>

Estão muito focados em "desempenho".

Gravar no Banco de Dados aumenta a complexidade da aplicação. Quanto
mais complexa, mais chance de erros e maiores os custos de teste e
manutenção (que já são os mais altos do projeto).

Gostei da solução com um httpd leve.

Rafael
--
http://www.rafaelfoto.com
Fotografia de Casamentos, Aniversários, Formaturas, Shows, Eventos
Esportivos, e festas em geral.

Rudinei Dias

não lida,
27 de nov. de 2009, 07:36:0227/11/2009
para tche...@googlegroups.com

2009/11/27 Marcel Araujo <cece...@gmail.com>

Galera, me deparei com uma questão esta semana sobre o que me proporcionaria uma melhor performace:

-Salvar os dados de uma imagem na base de dados ou salvar apenas em disco???

Para performance em aplicações, no disco.
Quando faz o upload da imagem já ficará numa pasta e será acessada diretamente pelo servidor web ou no máximo será ocultada através de cópias e imagens temporárias.
Quando você salva no bd, toda vez que consulta precisa extrair o blob do banco, salvar em arquivo e transferir para o destino, só então disponibilizar para o servidor web. Leia-se muita I/O e processamento necessário.

Para questões de consistência e segurança, então armazene no banco de dados. Por exemplo se as imagens são de GED (documentos) não devem ficar disponíveis para qualquer um e serem facilmente acessadas. Então com o banco você terá controle sobre os acessos.

O que não vale a pena colocar no BD: imagens que serão acessadas com muita frequência, tipo imagens de sites, etc..
O que vale colocar no BD: imagens com pouco acesso e que necessitam de restrição de acesso.


Na minha opinião em disco será mais rápido pois não necessitarei realizar uma consulta, criar uma variável temporária com o conteúdo do arquivo e exibir por exemplo, a imagem.

Qual opinião de vocês???

--
Abraços......

Marcel Araujo
System Analyst

-------------------------------------------------------------
Rudinei Dias

Marcel Araujo

não lida,
27 de nov. de 2009, 08:35:4627/11/2009
para tche...@googlegroups.com
Obrigado Sérgio!!!

2009/11/27 Sérgio <sur...@gmail.com>

Marcel Araujo

não lida,
27 de nov. de 2009, 10:52:4127/11/2009
para tche...@googlegroups.com
Heheheh, de qualquer maneira, obtive ótimas visões! Obrigado a todos e vou continuar optando por salvar somente a referência do arquivo no banco e o conteúdo em disco. Até porque estava olhando o limite do tamanho da base de dados no Cpanel e não é muito grande não. Sai mais barato contratar mais MB em disco que na banco.

2009/11/27 Sérgio <sur...@gmail.com>

--
Abraços......

Marcel Araujo
System Analyst
Developer Java/PHP/RIA
Linux User #490101
http://br.linkedin.com/in/marcelaraujo
http://www.kombo.com.br/meucurriculo/marcelaraujo
http://www.twitter/marcelaraujo

Mauricio Mauad Menegaz Filho

não lida,
27 de nov. de 2009, 11:54:2927/11/2009
para tche...@googlegroups.com
2009/11/27 Sérgio <sur...@gmail.com>:

Tudo isso é verdade, mas nem sempre há falta de cpu/memória, e ainda
assim há gargalos de performance.

>
> Se o caso é cache, acho mais negócio pensar em utilizar o squid (ou
> algum outro servidor que suporte proxy e cache em memória) como
> servidor proxy reverso, o qual também irá manter as imagens (e ainda
> de brinde, javascript, css, imagens de template, etc...) em memória
> reduzindo o estresse sobre os discos ;)
>
> Acho que a única vantagem de se utilizar BLOB é que facilita o backup.
>

É vero, talvez seja a única vantagem "na lata", as demais são
totalmente condicionadas à arquitetura, e certamente a solução fica
mais sujeita a chuvas e trovoadas.

Todo caso, facilitar o backup (e nunca esquecer de verificar se o
restore pode ser feito!) é uma grande coisa em empresas onde grana pra
comprar memória e cpu é mato perto da grana em risco no caso de não se
conseguir um restore rápido. Vale aquela máxima do cobertor curto: se
cobre a cabeça, descobre os pés...

Ah, e como o jeffmann falou, estamos considerando a performance
solita, o que nem sempre é prudente, e na prática, vale sacrificar ela
em prol de manutenabilidade (eita palavra sacana!), extensibilidade e
certamente economia de mão-de-obra no ongoing!


Abraço
Mauad

Eduardo Kienetz

não lida,
27 de nov. de 2009, 13:03:5027/11/2009
para tche...@googlegroups.com
2009/11/27 Mauricio Mauad Menegaz Filho <mma...@gmail.com>:
> 2009/11/27 Sérgio <sur...@gmail.com>:

>> Se o caso é cache, acho mais negócio pensar em utilizar o squid (ou
>> algum outro servidor que suporte proxy e cache em memória) como
>> servidor proxy reverso, o qual também irá manter as imagens (e ainda
>> de brinde, javascript, css, imagens de template, etc...) em memória
>> reduzindo o estresse sobre os discos ;)
>>
>> Acho que a única vantagem de se utilizar BLOB é que facilita o backup.
>
> É vero, talvez seja a única vantagem "na lata", as demais são
> totalmente condicionadas à arquitetura, e certamente a solução fica
> mais sujeita a chuvas e trovoadas.
>
> Todo caso, facilitar o backup (e nunca esquecer de verificar se o
> restore pode ser feito!) é uma grande coisa em empresas onde grana pra
> comprar memória e cpu é mato perto da grana em risco no caso de não se
> conseguir um restore rápido. Vale aquela máxima do cobertor curto: se
> cobre a cabeça, descobre os pés...

Bom, vejo que o Sérgio está focando em arquivos simples como imagens e tal...
Eu uso primariamente para armazenamento de relatórios (aqueles gerados
pelo iReport) que sejam pequenos (como eu disse anteriormente, limito
pelo tamanho do arquivo o que vai pro banco ou disco), mas também
alguns documentos.
A grande vantagem é na parte de segurança, pois controlar no sistema
de arquivos (e aí consequentemente acessos remotos) é bem mais
complicado do que ter um usuário no banco com as permissões
apropriadas (e/ou um SQL bem feito). Outro ponto que acho interessante
é a melhor organização.

Responder a todos
Responder ao autor
Encaminhar
0 nova mensagem