the - store file on database




Armazenando Imagens no DB-Sim ou Não? (20)

A palavra na rua é que, a menos que você seja um fornecedor de banco de dados tentando provar que seu banco de dados pode fazê-lo (como, digamos, a Microsoft se vangloriando do Terraserver armazenando um bajilhão de imagens no SQL Server), não é uma idéia muito boa. Quando a alternativa - armazenar imagens em servidores de arquivos e caminhos no banco de dados é muito mais fácil, por que se preocupar? Os campos de blob são como os recursos off-road dos SUVs - a maioria das pessoas não os usa, aqueles que geralmente se metem em problemas e depois há quem o faça, mas apenas por diversão.

Então, eu estou usando um aplicativo que armazena imagens pesadamente no banco de dados. Qual a sua perspectiva sobre isso? Eu sou mais do tipo para armazenar a localização no sistema de arquivos, do que armazená-la diretamente no banco de dados.

O que você acha que são os prós / contras?


Algo que ninguém mencionou é que o DB garante ações atômicas, integridade transacional e lida com simultaneidade. Mesmo a integridade referencial está fora da janela com um sistema de arquivos - então como você sabe que seus nomes de arquivos ainda estão corretos?

Se você tem suas imagens em um sistema de arquivos e alguém está lendo o arquivo enquanto você está escrevendo uma nova versão ou mesmo excluindo o arquivo - o que acontece?

Usamos blobs porque são mais fáceis de gerenciar (backup, replicação, transferência). Eles funcionam bem para nós.



Armazenar uma imagem no banco de dados ainda significa que os dados da imagem acabam em algum lugar do sistema de arquivos, mas são obscurecidos, para que você não possa acessá-los diretamente.

+ ves:

  • integridade do banco de dados
  • é fácil de gerenciar, pois você não precisa se preocupar em manter o sistema de arquivos sincronizado quando uma imagem é adicionada ou excluída

-ves:

  • penalidade de desempenho - uma pesquisa no banco de dados geralmente é mais lenta que uma pesquisa no sistema de arquivos
  • você não pode editar a imagem diretamente (cortar, redimensionar)

Ambos os métodos são comuns e praticados. Veja as vantagens e desvantagens. De qualquer forma, você terá que pensar em como superar as desvantagens. Armazenar no banco de dados geralmente significa ajustar os parâmetros do banco de dados e implementar algum tipo de cache. O uso do sistema de arquivos requer que você encontre uma maneira de manter o sistema de arquivos + o banco de dados sincronizados.


Como já foi dito, o SQL 2008 vem com um tipo Filestream que permite armazenar um nome de arquivo ou identificador como um ponteiro no banco de dados e automaticamente armazena a imagem em seu sistema de arquivos, o que é um ótimo cenário.

Se você estiver em um banco de dados mais antigo, eu diria que, se você o estiver armazenando como dados de blob, você realmente não obterá nada do banco de dados na maneira de pesquisar recursos, por isso é provavelmente o melhor para armazenar um endereço em um sistema de arquivos e armazenar a imagem dessa maneira.

Dessa forma, você também economiza espaço no seu sistema de arquivos, pois economiza apenas a quantidade exata de espaço ou até o espaço compactado no sistema de arquivos.

Além disso, você pode optar por salvar com alguma estrutura ou elementos que permitam navegar pelas imagens brutas em seu sistema de arquivos sem acertos no banco de dados ou transferir os arquivos em massa para outro sistema, disco rígido, S3 ou outro cenário - atualizando o local em seu programa, mas mantenha a estrutura, novamente sem muito sucesso, tentando tirar as imagens do seu banco de dados ao tentar aumentar o armazenamento.

Provavelmente, isso também permitiria que você jogasse algum elemento de cache, com base em URLs de imagens comumente acessadas no seu mecanismo / programa da Web, para que você também esteja se salvando.


Como na maioria dos problemas, não é tão simples quanto parece. Há casos em que faria sentido armazenar as imagens no banco de dados.

  • Você está armazenando imagens que estão mudando dinamicamente, digamos, faturas e queria obter uma fatura como em 1 de janeiro de 2007?
  • O governo quer que você mantenha 6 anos de história
  • As imagens armazenadas no banco de dados não requerem uma estratégia de backup diferente. As imagens armazenadas no sistema de arquivos não
  • É mais fácil controlar o acesso às imagens se elas estiverem em um banco de dados. Administradores inativos podem acessar qualquer pasta no disco. É preciso um administrador realmente determinado para bisbilhotar em um banco de dados para extrair as imagens

Por outro lado, existem problemas associados

  • Requer código adicional para extrair e transmitir as imagens
  • A latência pode ser mais lenta que o acesso direto a arquivos
  • Carga mais pesada no servidor de banco de dados

Em locais onde você DEVE garantir integridade referencial e conformidade com ACID, é necessário armazenar imagens no banco de dados.

Você não pode garantir transacionalmente que a imagem e os metadados sobre a imagem armazenada no banco de dados se refiram ao mesmo arquivo. Em outras palavras, é impossível garantir que o arquivo no sistema de arquivos seja alterado apenas ao mesmo tempo e na mesma transação que os metadados.


Em um projeto anterior, eu armazenei imagens no sistema de arquivos e isso causou muitas dores de cabeça com backups, replicação e sistema de arquivos ficando fora de sincronia com o banco de dados.

No meu projeto mais recente, estou armazenando imagens no banco de dados e armazenando em cache no sistema de arquivos, e funciona muito bem. Até agora não tive problemas.


Imagens estáticas pequenas (não mais que alguns megas) que não são editadas com frequência devem ser armazenadas no banco de dados. Esse método possui vários benefícios, incluindo portabilidade mais fácil (imagens são transferidas com o banco de dados), backup / restauração mais fácil (backup de imagens com o banco de dados) e melhor escalabilidade (uma pasta do sistema de arquivos com milhares de pequenos arquivos em miniatura parece um pesadelo de escalabilidade para mim).

É fácil exibir imagens de um banco de dados, basta implementar um manipulador http que serve a matriz de bytes retornada do servidor de banco de dados como um fluxo binário.


Implementamos um sistema de geração de imagens de documentos que armazena todas as suas imagens nos campos de blobs do SQL2005. Existem várias centenas de GB no momento e estamos vendo excelentes tempos de resposta e pouca ou nenhuma degradação de desempenho. Além disso, pela conformidade regulamentar, temos uma camada de middleware que arquiva documentos recém-publicados em um sistema de jukebox óptico que os expõe como um sistema de arquivos NTFS padrão.

Estamos muito satisfeitos com os resultados, principalmente com relação a:

  1. Facilidade de replicação e backup
  2. Capacidade de implementar facilmente um sistema de controle de versão de documentos

Não sei ao certo qual é o exemplo do "mundo real", mas atualmente tenho um aplicativo que armazena detalhes de um jogo de cartas, incluindo as imagens dos cartões. Concedido que a contagem de registros para o banco de dados é de apenas 2851 registros até a data, mas, como certos cartões foram liberados várias vezes e têm obras de arte alternativas, era realmente mais eficiente digitalizar o "quadrado principal" da arte e, em seguida, dinamicamente gere os efeitos de borda e diversos para o cartão quando solicitado.

O criador original dessa biblioteca de imagens criou uma classe de acesso a dados que renderiza a imagem com base na solicitação e é bastante rápida para visualização e cartão individual.

Isso também facilita a implantação / atualizações quando novos cartões são lançados, em vez de compactar uma pasta inteira de imagens e enviá-las para o canal e garantir a criação da estrutura de pastas adequada, basta atualizar o banco de dados e fazer com que o usuário faça o download novamente. Atualmente, esse tamanho é de até 56 MB, o que não é ótimo, mas estou trabalhando em um recurso de atualização incremental para versões futuras. Além disso, existe uma versão "sem imagens" do aplicativo que permite que os usuários discados obtenham o aplicativo sem o atraso do download.

Esta solução funcionou muito bem até o momento, pois o próprio aplicativo é direcionado como uma única instância na área de trabalho. Existe um site em que todos esses dados são arquivados para acesso on-line, mas eu não usaria a mesma solução para isso. Concordo que o acesso ao arquivo seria preferível, pois seria mais adequado à frequência e ao volume de solicitações feitas pelas imagens.

Espero que isso não seja muito tagarelar, mas eu vi o tópico e queria fornecer algumas idéias de um aplicativo de pequena / média escala relativamente bem-sucedido.


Na minha experiência, às vezes a solução mais simples é nomear as imagens de acordo com a chave primária . Portanto, é fácil encontrar a imagem que pertence a um registro específico e vice-versa. Mas, ao mesmo tempo, você não está armazenando nada sobre a imagem no banco de dados.


Normalmente, sou cauteloso em pegar a parte mais cara e mais difícil de dimensionar sua infraestrutura (o banco de dados) e colocar toda a carga nela. Por outro lado: simplifica bastante a estratégia de backup, especialmente quando você possui vários servidores da Web e precisa, de alguma forma, manter os dados sincronizados.

Como a maioria das outras coisas, depende do tamanho e do orçamento esperados.


O SQL Server 2008 oferece uma solução com o melhor dos dois mundos: o tipo de dados de fluxo de arquivos .

Gerencie-o como uma tabela regular e tenha o desempenho do sistema de arquivos.


O truque aqui é não se tornar um fanático.

Uma coisa a observar aqui é que ninguém no campo do sistema de arquivos profissional listou um sistema de arquivos específico. Isso significa que tudo, do FAT16 ao ZFS, supera facilmente todos os bancos de dados?

Não.

A verdade é que muitos bancos de dados superam muitos sistemas de arquivos, mesmo quando estamos falando apenas de velocidade bruta.

O curso de ação correto é tomar a decisão certa para o seu cenário preciso e, para isso, serão necessários alguns números e algumas estimativas de casos de uso.


Os caminhos de arquivo no banco de dados são definitivamente o caminho a percorrer - ouvi histórias e histórias de clientes com TB de imagens de que se tornou um pesadelo tentar armazenar uma quantidade significativa de imagens em um banco de dados - apenas o desempenho atingido é demais.


Se esse for um aplicativo baseado na Web, poderá haver vantagens em armazenar as imagens em uma rede de entrega de armazenamento de terceiros, como o S3 da Amazon ou a plataforma Nirvanix.


Se você não estiver no SQL Server 2008 e tiver razões sólidas para colocar arquivos de imagem específicos no banco de dados, poderá adotar a abordagem "ambos" e usar o sistema de arquivos como cache temporário e usar o banco de dados como repositório principal .

Por exemplo, sua lógica de negócios pode verificar se existe um arquivo de imagem no disco antes de servi-lo, recuperando-o do banco de dados quando necessário. Isso oferece a capacidade de vários servidores Web e menos problemas de sincronização.


Sou responsável por alguns aplicativos que gerenciam muitos TB de imagens. Descobrimos que armazenar os caminhos de arquivos no banco de dados é o melhor.

Existem alguns problemas:

  • o armazenamento do banco de dados geralmente é mais caro que o armazenamento do sistema de arquivos
  • você pode acelerar o acesso ao sistema de arquivos com produtos de prateleira padrão
    • por exemplo, muitos servidores da Web usam a chamada do sistema sendfile () do sistema operacional para enviar assincronamente um arquivo diretamente do sistema de arquivos para a interface de rede. As imagens armazenadas em um banco de dados não se beneficiam dessa otimização.
  • coisas como servidores da web etc. não precisam de codificação ou processamento especial para acessar imagens no sistema de arquivos
  • os bancos de dados vencem onde a integridade transacional entre a imagem e os metadados é importante.
    • é mais complexo gerenciar a integridade entre os metadados db e os dados do sistema de arquivos
    • é difícil (no contexto de um aplicativo da web) garantir que os dados foram liberados para o disco no sistema de arquivos

Uma coisa que eu não vi ninguém mencionar ainda, mas definitivamente vale a pena notar, é que também há problemas associados ao armazenamento de grandes quantidades de imagens na maioria dos sistemas de arquivos. Por exemplo, se você seguir a abordagem mencionada acima e nomear cada arquivo de imagem após a chave primária, na maioria dos sistemas de arquivos você terá problemas se tentar colocar todas as imagens em um diretório grande assim que atingir um número muito grande de imagens ( por exemplo, nas centenas de milhares ou milhões).

Uma vez que a solução comum para isso é misturá-los em uma árvore equilibrada de subdiretórios.





blob