Imagens no banco de dados versus sistema de arquivos

Question

Temos um projeto em andamento no qual construiremos um sistema CMS de back-end completo que alimentará toda a nossa extranet e intranet com um único pacote.A pergunta para a qual tenho tentado encontrar uma resposta é qual é melhor:armazenar imagens no banco de dados (SQL Server 2005) para que possamos ter integridade, plano de replicação único, etc. OU armazenar no sistema de arquivos?

Um problema que temos é que temos vários servidores com balanceamento de carga que exigem os mesmos dados o tempo todo.A partir de agora temos a replicação SQL cuidando disso, mas a replicação de arquivos parece ser um pouco mais difícil.Outra preocupação que temos é que gostaríamos de ter múltiplas resoluções da mesma imagem, não temos certeza se seria melhor criar e armazenar cada versão no sistema de arquivos ou talvez extrair e criar dinamicamente a imagem de resolução que gostaríamos mediante solicitação.

Nossas preocupações são as seguintes:

• Integridade de dados
• Replicação de dados
• Múltiplas resoluções
• Velocidade do banco de dados versus sistema de arquivos
• Carga indireta do banco de dados versus sistema de arquivos
• Gerenciamento e backup de dados

Alguém tem uma situação semelhante ou tem alguma opinião sobre o que seria recomendado?Obrigado antecipadamente pela ajuda!

Answer 1

Houve um belo artigo de pesquisa publicado pela Microsoft Research chamado Blob ou não Blob onde analisaram todos os tipos de variáveis ​​e impactos.

A descoberta deles no final:

• até 256 KB de tamanho, os blobs são armazenados no banco de dados com mais eficiência do que no sistema de arquivos
• para 1 MB e maiores, o sistema de arquivos é mais eficiente
• no meio é uma disputa

Desde que esse artigo foi publicado, o SQL Server 2008 também adicionou o atributo FILESTREAM, que torna o armazenamento de coisas no sistema de arquivos, mas sob controle transacional, uma realidade.Altamente recomendado que você verifique isso!

Answer 2

Esta pergunta surge com frequência - veja isto Então, resultado da pesquisa.

Não há uma resposta certa - depende das circunstâncias.

Pessoalmente - mantenha um caminho de arquivo no banco de dados e no arquivo no sistema de arquivos. Cada um tem seus próprios pontos fortes. Você pode fazer backup de arquivos, bem como bancos de dados. Esta também é a conclusão de esse cara, que gerencia TBS de dados.

Answer 3

A replicação de arquivos estáticos, especialmente em vários servidores, pode ser difícil de gerenciar. Realmente se resume a uma troca entre gerenciar, monitorar e depurar problemas de replicação versus tamanho e carga do banco de dados.

Acho que provavelmente escolheria a abordagem do banco de dados e, se a carga se tornar um problema de colocar algum tipo de camada de cache em torno das chamadas de imagem.

Sugestões para armazenar um caminho no banco de dados estão faltando o problema real, que está replicando isso em várias máquinas.

Answer 4

Suas preocupações se dividem em dois campos. As preocupações a seguir preferem armazenar documentos no banco de dados:

• Integridade de dados
• Replicação de dados
• Múltiplas resoluções
• Gerenciamento de dados e backup

Essas preocupações (provavelmente) favorecem o armazenamento de documentos no sistema de arquivos:

• Velocidade de banco de dados vs sistema de arquivos
• Carga aérea de banco de dados vs sistema de arquivos

Portanto, decida o que mais importa e escolha de acordo.

Answer 5

Bem, se suas duas principais necessidades forem integridade e replicação, a resposta é definitivamente o banco de dados.

Vocês outros pontos: embora:

• Integridade - DB, é por isso que existem bancos de dados vs. sistemas de arquivos planos.

• Replicação - Não tenho certeza se você quer dizer replicação da imagem, mas, se sim, obviamente, o DB, pois você não será o equilíbrio de carga, certamente.

• Várias resoluções podem ser executadas a partir da imagem do banco de dados, no entanto, isso adiciona custos de processamento. Além disso, quanto maior a resolução, maior o tamanho, mais tempo a rede espera. Múltiplas resoluções de resoluções Negocia espaço para velocidade.

• Velocidade - Dependendo do acesso às imagens, pode ser insignificante. Se você estiver tirando imagens em um compartilhamento de arquivos, terá que esperar na rede em qualquer caso e a rede é sempre o gargalo.

• Despesas - Francamente, depende da sua definição de sobrecarga e de como você acessa as imagens.

• Gerenciamento, DB, mãos para baixo. Armazenamento singular = menos preocupação, e você deve sempre executar backups no banco de dados em qualquer caso. Os backups do sistema de arquivos em vários servidores são caros de várias maneiras.

Answer 6

Existem preocupações válidas em ambos os lados do debate; portanto, sempre dê seus requisitos. Quantos dados, quantas imagens, quão grande?

Armazenamento embutido / blob

Parte de cima: Simplifica a arquitetura e a implementação, simplifica o backup e a recuperação ou a migração do sistema; Basta fazer um despejo, backup, exportar (qualquer que seja o termo para o seu sabor de banco de dados) e movê -lo para o novo banco de dados. O controle / consistência da versão é tratado pelo banco de dados, portanto, permite a recuperação pontual. O controle de segurança / acesso também é mais limpo, uma vez que o acesso a um blob de imagem é intrínseco ao acesso à linha geral. Mover a imagem para fora do banco de dados e deixar o servidor HTTP buscá -la, embora melhor para simultaneidade e escalabilidade, pode ter problemas para garantir que as pessoas não possam invadir URLs e solicitar imagens que não possuem. Se você abri -los fora do banco de dados, verifique se sua política de segurança cobre o controle de acesso das imagens entre os usuários. A autenticação do servidor HTTP deve se integrar à autenticação geral do sistema ou ao seu programa de servidor HTTP que serve as imagens usa algum tipo de mecanismo de sessão para garantir que a solicitação HTTP seja válida. Essa é uma grande preocupação nos bancos de dados de vários inquilinos. Menos preocupação em sistemas únicos, sistemas de inquilino único, com autenticação simples.

Desvantagem: Para bancos de dados realmente realmente grandes, o backup e a recuperação ficam frustrantes ou até problemáticos e caros, porque onde você pode ter um pequeno conjunto de dados principal, caso contrário, pode ter muitos GB ou TB de dados de imagem. Tratar tudo isso como um banco de dados consistente é bom do ponto de vista da integridade, mas ruim para backups, a menos que você use DBMES com qualidade corporativa, backup e recuperação sintonizados do Data Warehouse (o exemplo é o Oracle RMAN e os backups rolantes).

Sempre considere tempo para recuperação em qualquer sistema. Se seus requisitos de armazenamento forem <alguns gigabytes, digamos 50-100 GB e você terá muito espaço de backup planejado, o armazenamento em linha é mais limpo. Acima disso, a separação de preocupações e a localização do sistema de arquivos fazem seu trabalho se tornam uma vantagem fundamental. Nada é pior do que tentar restaurar, recuperar e abrir um grande banco de dados em prol de um pequeno erro de dados. O tempo de recuperação seria minha maior preocupação.

Answer 7

Geralmente, os dados de imagem persistentes no banco de dados podem não ser tão eficientes quanto o sistema de arquivos, no que diz respeito a um CMS. Ao mesmo tempo, você provavelmente só quer exibir a imagem estaticamente, outras vezes deseja que essa imagem esteja disponível para seus designers gráficos para atualizações etc.

Considere a sobrecarga de processamento associada à recuperação da imagem cada vez que você deseja trabalhar com ela.

Alguns pontos por que você deve considerar o sistema de arquivos

1. O navegador faz todo o trabalho, e você se beneficia do cache de proxy de imagens etc.
2. Como uma ramificação acima, você pode usar facilmente redes de entrega de conteúdo (CDN)
3. A replicação dos dados da imagem é fácil com ferramentas como RSYNC etc
4. O tempo de processamento (IE CPU) é drasticamente otimizado

Answer 8

Supondo que você esteja em um ambiente do Windows, não há uma grande razão para usar o sistema de arquivos. Você pode ter cuidado para o que você armazena as imagens nas mesas para evitar divisões de página indesejadas, mas isso é um ajuste de desempenho, não um problema enorme.

Desvantagens do sistema de arquivos

-Não replicados automaticamente

-I -me complicar sua replicação tendo diferentes locais físicos para cada instância

-Low com um número muito grande de arquivos

Vantagem para o sistema de arquivos

-Se você estiver armazenando alguns arquivos muito grandes, ele terá um desempenho um pouco melhor.

Answer 9

Eu poderia;

1) Atribua identificador exclusivo (GUID) a cada imagem 2) Tag/nomeie a imagem com esse Guid 3) Armazene GUID no SO (sistema de arquivo) 4) Armazene o ponteiro de nome do arquivo (FQN) totalmente qualificado (FQN) no banco de dados.

O armazenamento de imagens no banco de dados é muito caro em termos de armazenamento e manutenção. Armazenar apenas o ponteiro FQN forneceria melhor solução. Você também pode criar a verificação de integridade de back-end através de gatilhos e alguns procedimentos armazenados.

Answer 10

Eu não armazenaria imagens no banco de dados por um motivo (minha resposta vem do SQL Server):

Eu não gostaria que o cache de dados dos servidores SQL preenchida por imagens simples para o site. Eu quero que o cache de dados realmente tenha dados nele. Além disso, se você possui uma arquitetura de várias camadas, é muito mais fácil passar um URL para uma imagem do que uma bolha de dados binários. Onde você encontra problemas, se você deseja que certas pessoas vejam as imagens (segurança).