Onde devo armazenar fotos? Sistema de arquivos ou o banco de dados? [duplicado

Question

Possível duplicata:
Armazenamento de fotos e documentos enviados - FileSystem vs Database Blob

Estou começando a desenvolver um aplicativo da web, cujo objetivo principal é exibir fotos. Os usuários também poderão fazer upload de fotos.

A primeira pergunta que surgiu foi onde armazenar as fotos: no sistema de arquivos ou no banco de dados.

Vou usar uma caixa do Windows para hospedar o site. O banco de dados é MySQL e o código de back -end está no C# utilizando asp.net MVC.

Answer 1

O FileSystem, é claro, a menos que você esteja buscando uma história no TheDailyWTF. A maneira mais fácil é ter as fotos organizadas por uma propriedade que você pode derivar do próprio arquivo, como seu hash sha-1. Em seguida, basta armazenar o hash no banco de dados, anexado à chave primária da foto e outros atributos (que o carregaram, fazer o upload da data, etc.).

Também é uma boa idéia dividir as fotos no sistema de arquivos, para que você não termine com milhões de arquivos em um único diretório. Então você terá algo assim:

storage/00/e4/f56c0de1c61fdb926e79e8a0a65bd12930c9.jpg
storage/25/9a/ec1c55bfb660548a6770238668c4b117d92f.jpg
storage/5d/d5/4b01d98f17a9ad9dd1526b49ba39b5aa37a1.jpg
storage/63/49/6f740b6c284ce6685dc17d473a7360ace249.jpg
storage/b1/75/066d178188dde110149a8422ab651b0ee615.jpg
storage/b1/20/a2b7d02b7b0c43530677ab06235382a37e20.jpg
storage/da/39/a3ee5e6b4b0d3255bfef95601890afd80709.jpg

Isso também é fácil de portar se você se mudar para o armazenamento franco.

Answer 2

Se você estiver usando o SQL Server 2008, houver um tipo de dados do FileStream que lida com a maioria dos problemas mencionados sobre o DB ficando maior. Ele lida com todos os detalhes irritantes da sincronização entre o sistema de arquivos e a tabela.

Procure aqui um post sobre o tópico: Armazene quaisquer dados no SQL Server 2008 (Katmai)

Answer 3

Se você estiver construindo um site em torno das fotos, esqueça o banco de dados. Se se tornará popular, seu banco de dados será atingido com força e a maior parte do tempo será gasta entregando fotos. Além disso, os bancos de dados não são muito bem. Existem muito mais vantagens para mantê -los no sistema de arquivos. E você pode escalar muito bem, com servidores de conteúdo estático, usando serviços para entrega de conteúdo.

Além disso, o Amazon S3 ou outros provedores de nuvem têm suas vantagens. Por exemplo, S3 + Amazon CloudFront fornecerá um bom desempenho. O CloudFront cache seus arquivos em servidores em todo o mundo, para que sejam acessíveis com muita facilidade/Fast de qualquer lugar. Mas se estamos falando de fotos e o site se torna popular, suas contas podem ser bastante altas.

Para S3 Amazon cobra por armazenamento e por transferência dentro/fora da nuvem. Por CloudFront por transferência.

Answer 4

Geralmente, as pessoas armazenam dados binários, como imagens no sistema de arquivos, não no banco de dados. Eles fazem referência ao caminho do sistema de arquivos no banco de dados. A recuperação de blobs (objetos grandes binários) do banco de dados é mais lenta do que permitir que o servidor da Web sirva arquivos estáticos do sistema de arquivos.

Answer 5

Eu usaria algo como Amazon S3.

Mas, se a opção for entre o sistema de arquivos e o banco de dados, eu escolheria o sistema de arquivos porque é mais rápido para o servidor imagens de um sistema de arquivos do que um banco de dados.

Answer 6

A única razão pela qual eu colocaria fotos como blobs em um banco de dados seria se tivesse um cluster de servidores, e estava usando a replicação do banco de dados para copiar automaticamente as fotos para todas as máquinas do cluster.

A vida é muito mais simples se você apenas armazenar as fotos como arquivos e armazenar os nomes de arquivos das fotos no banco de dados. Se você precisar criar nomes de arquivos exclusivos para as fotos, poderá usar um número inteiro principal do banco de dados como parte do nome do arquivo. Mas você também pode usar um hash da própria foto, como sugerido por John Milliken. Isso é simples e simples é melhor.

Answer 7

Algumas pessoas apontam que é mais fácil gerenciar se tudo estiver no banco de dados: incluindo fazer backups e preservar a integridade referencial.

Answer 8

Se você o armazenar em DB, o banco de dados crescerá rapidamente e será muito, muito maior. É apenas um toque mais complicado para obter uma imagem do banco de dados para exibição do que é obtê -lo de um sistema de arquivos. Por outro lado, é melhor você garantir que os nomes e caminhos de arquivos não fiquem fora de sincronia com o que é armazenado no banco de dados. No passado, escolhi armazenar em disco em vez de db. Isso facilitou para mim mover o banco de dados para caixas diferentes. Funcionou bem.

Answer 9

Tivemos uma decisão semelhante a tomar um projeto em que estou. A coisa atraente sobre tocar coisas (imagens e outras coisas em bloby) no banco de dados é que é menos provável que alguém possa excluir/alterar algo (intencional ou não intencionalmente). Mas essa não é a escolha que fizemos. Em vez disso, temos as informações do caminho armazenadas no banco de dados e usamos isso para fazer referência aos dados via caminho UNC. Os caminhos de dados são armazenados em duas partes - uma parte que faz referência à localização dos dados em relação a qual máquina reside e uma parte que aponta para a qual o grupo de dados está. Quando precisamos mover dados, podemos atualizar as informações de caminho apropriadas.

Certamente é rápido obter os dados sem sair do banco de dados. Em última análise, esse foi um grande fator decisivo.

Answer 10

Isso torna a vida tão fácil quando você tem um banco de dados BLOB. Você deve esquecer o pesadelo que é o gerenciamento do sistema de arquivos.

EDITAR

EU IRIA
Varbinário

Da experiência, essa é uma maneira eficiente de gerenciar arquivos binários. Você tem um banco de dados que possui apenas arquivos binários. Como isso pode ser mais difícil de fazer backup?