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
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
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
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
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.
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
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
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.