Pergunta

Eu li alguns post a este respeito, mas eu ainda não entendo qual é a melhor solução no meu caso.
Eu estou começar a escrever uma nova webApp eo backend vai fornecer cerca de 1-10 milhões de imagens . (Tamanho médio 200-500kB para uma única imagem)

Meu site irá fornecer conteúdo e imagens para 100-1000 usuários ao mesmo tempo.

Eu gostaria também de manter os custos Provedor de tão baixo quanto possível (mas este é um requisito secundário). Estou pensando que File espaço do sistema é menos caro, se comparado com o custo do tamanho da DB.

Pessoalmente eu gosto da idéia de ter todas as minhas imagens no DB mas qualquer sugestão será muito apreciada :)

Você acha que, no meu caso, a abordagem DB é a escolha certa?

Foi útil?

Solução

Colocar todas essas imagens em seu banco de dados fará com que seja muito, muito grande. Isso significa que seu motor DB será ocupado cache todas as imagens (uma tarefa que não é realmente concebido para) quando poderia ser cache os dados de aplicativos quentes vez.

Deixe o arquivo cache até o sistema operacional e / ou o seu proxy reverso -. Que vai ser melhor para ele

Outras dicas

Algumas outras razões para armazenar imagens no sistema de arquivos:

  • Servidores imagens pode ser executado mesmo quando o banco de dados estiver ocupado ou para baixo.
  • Os sistemas de arquivos são feitas para armazenar arquivos e são muito eficientes nisso.
  • Dumping dados em seus meios de banco de dados backups mais lentas e outras operações.
  • No server-side código necessário para servir uma imagem, simplesmente IIS velho / Apache.
  • Você pode dimensionar-se mais rápido com servidores web baratíssimo, ou potencialmente a um CDN.
  • Você pode executar trabalhos relacionados (thumbnails geração, etc.) sem envolver o banco de dados.
  • O seu servidor de banco de dados pode manter mais dos dados da tabela "reais" na memória, que é onde você começa a sua velocidade de banco de dados para consultas. Se ele usa a sua memória preciosa para manter arquivos de imagem em cache, que não comprar-lhe quase nada velocidade-wise contra ter mais do índice de fotos na memória.

A maioria dos sites grandes usam o sistema de arquivos.

Armazene fotos como arquivos ou no banco de dados para um aplicativo web?

Quando se lida com objetos binários, seguir uma abordagem centrada no documento de arquitetura, e não armazenar documentos como pdf de e imagens no banco de dados, você eventualmente terá que refatorar-lo para fora quando você começar a ver todos os tipos de problemas de desempenho com o seu banco de dados. Apenas armazenar o arquivo no sistema de arquivos e ter o caminho dentro de uma tabela de sua databse. Há também uma limitação física do tamanho do tipo de dados que você irá usar para serializar e salvá-lo no banco de dados. Apenas armazená-lo no sistema de arquivos e acessá-lo.

Sua primeira frase diz que você já leu alguns posts sobre o assunto, por isso não vou incomodar colocar em links para artigos que cobrem isso. Na minha experiência, e com base no que você postou, tanto quanto o número de imagens e tamanhos das imagens, você vai pagar caro no desempenho DB se você armazená-las no DB. Eu armazená-los no sistema de arquivos.

O banco de dados você está usando? MS SQL Server 2008 fornece armazenamento FILESTREAM

permite o armazenamento eo acesso eficiente aos dados BLOB usando uma combinação de SQL Server 2008 eo sistema de arquivos NTFS. Abrange escolhas para o armazenamento BLOB, configurar o Windows e SQL Server para usar dados FILESTREAM, considerações para a combinação de FILESTREAM com outras características e detalhes de implementação, como particionamento e desempenho.

detalhes

Nós usamos FileNet, um servidor otimizado para imagens. Isso é muito caro. A solução mais barata é usar um servidor de arquivos.

Por favor, não consideram armazenar grandes arquivos em um servidor de banco de dados.

Como já foi mencionado, armazenar referências aos grandes arquivos no banco de dados.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top