Armazenar imagens como arquivos ou no banco de dados para um aplicativo Web?


124

Minha pergunta é bastante genérica e sei que pode não haver uma resposta de 100% a ela. Estou construindo uma solução da web ASP .NET que incluirá muitas fotos e, com sorte, uma quantidade razoável de tráfego. Eu realmente quero alcançar desempenho.

Devo salvar as imagens no banco de dados ou no sistema de arquivos? E, independentemente da resposta, estou mais interessado em saber por que escolher uma maneira específica.

Muito obrigado, Stefan

DUPLICADO : Armazenando Imagens no DB - Sim ou Não? , Como armazenar imagens em seu sistema de arquivos , Armazenando um pequeno número de imagens: blob ou fs? e provavelmente alguns outros.


COMENTÁRIO: Obrigado por muitas boas respostas. Vou buscar uma solução baseada em arquivo, mesmo que eu goste da idéia de ter uma solução 100% orientada a banco de dados. Parece que hoje existem boas soluções para fazer o que eu quero com bancos de dados etc, mas tenho algumas razões para não fazê-lo.

  • Estarei em uma solução hospedada, tenho uma quantidade enorme de armazenamento (10gb), mas apenas 300mb para o banco de dados. Vai custar muito para armazenamento extra no banco de dados.

  • Eu não sou um especialista em banco de dados e também não estou no controle das configurações do banco de dados. Uma solução baseada em banco de dados pode precisar de configuração personalizada, como parece.

Se passarmos a executar o site em nosso próprio servidor, posso considerar uma solução baseada em banco de dados. obrigado Stefan


1
Especifique o banco de dados que você está usando.
Gerrie Schenck

1
Eu pretendo usar o MSSQL da versão posterior.
21413 StefanE

1
@StefanE, O sistema de arquivos é, para todos os efeitos, um banco de dados especializado e otimizado para armazenamento de arquivos.
21410 LukeH

Respostas:


175

Armazene as imagens no sistema de arquivos e os locais das imagens no banco de dados.

Por quê? Porque...

  1. Você poderá servir as imagens como arquivos estáticos.
  2. Nenhum acesso ao banco de dados ou código do aplicativo será necessário para buscar as imagens.
  3. As imagens podem ser exibidas em um servidor diferente para melhorar o desempenho.
  4. Isso reduzirá o gargalo do banco de dados.
  5. O banco de dados finalmente armazena seus dados no sistema de arquivos.
  6. As imagens podem ser facilmente armazenadas em cache quando armazenadas no sistema de arquivos.

1
Além disso, no SQL Server, quando você armazena a imagem como um campo "Imagem", isso é efetivamente o que o SQL está fazendo - armazenando um ponteiro para o arquivo no disco em algum lugar. É assim que ocorre o limite de páginas de 8 KB.
Zhaph - Ben Duguid 18/02/09

9
Na verdade, isso foi solucionado no SQL Server 2008. Foi introduzido um novo tipo de FILESTREAM technet.microsoft.com/en-us/library/bb895234.aspx, que permite tirar proveito do "desempenho do sistema de arquivos e, ao mesmo tempo, manter consistência transacional entre os dados não estruturados e os correspondentes dados estruturados"
kristof

Sim, você torce para a direita. minha pergunta é qual é o tamanho do blob? ou quanta memória ele pode armazenar?
Ameer

11

Nos meus projetos desenvolvidos recentemente, eu armazenei imagens (e todos os tipos de documentos binários) como colunas de imagens nas tabelas do banco de dados.

A vantagem de ter arquivos armazenados no banco de dados é obviamente que você não terá arquivos não referenciados no disco rígido se um registro for excluído, uma vez que a sincronização entre o banco de dados (= metadados) e o disco rígido (= armazenamento de arquivo) não está embutida. e deve ser programado manualmente.

Usando a tecnologia de hoje, sugiro que você armazene imagens nas colunas FILESTREAM do SQL Server 2008 (pelo menos é o que farei no meu próximo projeto), pois elas combinam a vantagem de armazenar dados no banco de dados E ter binários grandes em arquivos separados (em menos de acordo com a publicidade;))


Você já testou a funcionalidade Filestream?
21413 StefanE

1
Na verdade, ao excluir o registro do banco de dados, também pode ser codificado para excluir do sistema de arquivos. Então acho que é bom para armazenar em FS em vez de DB
kailash19

9

O ditado sempre foi "Arquivos no sistema de arquivos, metadados do arquivo no banco de dados"


6

Melhor armazenar arquivos como arquivos. Bancos de dados diferentes tratam os dados do Blob de maneira diferente; portanto, se você precisar migrar seu back-end, poderá ter problemas.

Ao veicular os impages, é provável que <img src = para um arquivo que já exista no servidor seja mais rápido do que criar um arquivo temporário no campo do banco de dados e apontar a tag <img para ele.

Encontrei esta resposta pesquisando sua pergunta no Google e lendo os comentários em http://databases.aspfaq.com/database/should-i-store-images-in-the-database-or-the-filesystem.html


1
A publicação referida parece um pouco desatualizada.
devio 18/02/09

6

Eu normalmente gosto de ter arquivos binários no banco de dados porque:

  • integridade dos dados: nenhum arquivo não referenciado, nenhum caminho no banco de dados sem nenhum arquivo associado
  • consistência dos dados: faça um despejo de banco de dados e é tudo. no "Esqueci de targz este diretório de dados."

4

O armazenamento de imagens no banco de dados adiciona uma sobrecarga de banco de dados para veicular imagens únicas e dificulta a transferência para armazenamento alternativo (S3, Akami) se você atingir esse nível. Armazená-los no banco de dados facilita a transferência do aplicativo para um servidor diferente, pois é apenas o banco de dados que precisa ser movido agora.

O armazenamento de imagens no disco facilita o descarregamento para armazenamento alternativo, torna os elementos estáticos para que você não precise mexer nos cabeçalhos HTTP no aplicativo da web para torná-las armazenáveis ​​em cache. A desvantagem é que, se você mover seu aplicativo para um servidor diferente, precisará lembrar também de mover as imagens; algo que é facilmente esquecido.


3

Para aplicativos baseados na Web, você obterá melhor desempenho ao usar o sistema de arquivos para armazenar suas imagens. Isso permitirá que você implemente facilmente o armazenamento em cache das imagens em vários níveis no seu aplicativo. Existem algumas vantagens em armazenar imagens em um banco de dados, mas na maioria das vezes essas vantagens vêm com aplicativos baseados no cliente.


0

Apenas para adicionar um pouco mais às já boas respostas até agora. Você ainda pode obter os benefícios do cache do nível da web, talvez e do banco de dados, se seguir a rota mantendo as imagens no banco de dados.

Eu acho que para o banco de dados você pode conseguir isso armazenando as imagens em relação aos dados textuais associados a elas e se você pode acessar as imagens em uma consulta específica para que o banco de dados possa armazenar em cache a consulta (apenas a teoria sinta-se livre para me matar nessa parte).

Com o lado da web, eu acho que, uma vez que sua pergunta está marcada com asp.net, você seguiria o caminho de usar um manipulador http para exibir as imagens. Então você tem todos os benefícios da estrutura à sua disposição e pode manter a lógica do domínio mais limpa, tendo apenas que passar a chave da sua imagem para o manipulador http.


-1

Por que não escolher um banco de dados NoSql individual para armazenar seus arquivos.

Ele traz integridade e consistência dos dados, como o @chburd mencionado.

Enquanto você rdbms ainda permanece pequeno.


-1
  1. Aqui está um exemplo passo a passo (abordagem geral, implementação do Spring Eclipse) de armazenamento de imagens no sistema de arquivos e manutenção de seus metadados no banco de dados - http://www.devmanuals.com/tutorials/java/spring/spring3/mvc /Spring3MVCImageUpload.html
  2. Aqui também está um exemplo - http://www.journaldev.com/2573/spring-mvc-file-upload-example-tutorial-single-and-multiple-files
  3. Além disso, você pode investigar uma base de código desse projeto - https://github.com/jdmr/fileUpload . Preste atenção neste controlador.
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.