Armazenamento de imagens em DB - sim ou não?

votos
415

Então, eu estou usando um aplicativo que armazena imagens pesadamente no DB. Qual é a sua visão sobre isso? Eu sou mais de um tipo para armazenar o local no sistema de arquivos, de armazená-lo diretamente no DB.

O que você acha que são as vantagens / desvantagens?

Publicado 06/08/2008 em 18:38
fonte usuário
Em outras línguas...                            


56 respostas

votos
350

Eu estou no comando de algumas aplicações que gerenciam muitos TB de imagens. Descobrimos que o armazenamento de caminhos de arquivos no banco de dados para ser melhor.

Há um par de questões:

  • armazenamento de dados é geralmente mais caro do que o armazenamento do sistema de arquivos
  • você pode super-acelerar o acesso do sistema de arquivos com o padrão fora dos produtos de prateleira
    • por exemplo, muitos servidores web usam o sistema operacional sendfile () chamada de sistema para enviar de forma assíncrona um arquivo diretamente do sistema de arquivos para a interface de rede. As imagens armazenadas em um banco de dados não beneficiar dessa otimização.
  • coisas como servidores web, etc, necessitam de nenhuma codificação ou processamento especial para acessar imagens no sistema de arquivos
  • bases de dados vencer onde a integridade transacional entre a imagem e os metadados são importantes.
    • é mais complexo para gerenciar a integridade entre metadados db e dados do sistema de arquivos
    • é difícil (dentro do contexto de uma aplicação web) para garantir dados foram liberadas para o disco do sistema de arquivos
Respondeu 06/08/2008 em 18:40
fonte usuário

votos
140

Tal como acontece com a maioria das questões, não é tão simples quanto parece. Há casos em que não faria sentido para armazenar as imagens no banco de dados.

  • Você está armazenando imagens que estão mudando de forma dinâmica, dizem faturas e você quisesse obter uma factura, uma vez que foi em 01 de janeiro de 2007?
  • O governo quer que você mantenha 6 anos de história
  • As imagens armazenadas no banco de dados não necessitam de uma estratégia de backup diferente. Imagens armazenadas no sistema de arquivos fazer
  • É mais fácil para controlar o acesso às imagens se eles estão em um banco de dados. admins ociosos pode acessar qualquer pasta no disco. É preciso uma administração realmente determinado a ir bisbilhotando em um banco de dados para extrair as imagens

Por outro lado, existem problemas associados

  • Requerem código adicional para extrair e transmitir as imagens
  • Latência pode ser mais lenta do que o acesso direto aos arquivos
  • Mais pesada carga sobre o servidor de banco de dados
Respondeu 22/08/2008 em 17:33
fonte usuário

votos
99

armazenamento de arquivos. engenheiros do Facebook tinha uma grande conversa sobre isso. Uma tira foi conhecer o limite prático de arquivos em um diretório.

Needle in a Haystack: armazenamento eficiente de Bilhões de Fotos

Respondeu 20/08/2008 em 19:35
fonte usuário

votos
56

Isso pode ser um pouco de um tiro longo, mas se você está usando (ou pensando em usar) SQL Server 2008 eu recomendo ter um olhar para o novo FileStream tipo de dados.

FileStream resolve a maioria dos problemas em torno armazenar os arquivos do DB:

  1. Os Blobs são realmente armazenados como arquivos em uma pasta.
  2. As bolhas podem ser acedidos utilizando quer uma ligação de base de dados ou ao longo do sistema de ficheiros.
  3. Backups são integrados.
  4. Migração "simplesmente funciona".

No entanto "Criptografia de Dados Transparente" do SQL não criptografa objetos FileStream, por isso, se que é uma consideração, você pode ser melhor fora apenas armazená-los como varbinary.

A partir do MSDN artigo:

Instruções Transact-SQL pode inserir, atualizar, consultar, pesquisar e fazer backup dos dados FILESTREAM. Interfaces de sistema de arquivo do Win32 oferecem streaming de acesso aos dados.
FILESTREAM usa o cache do sistema NT para o cache de dados do arquivo. Isso ajuda a reduzir qualquer efeito que os dados FILESTREAM pode ter no desempenho do Database Engine. O pool de buffer do SQL Server não é utilizado; portanto, esta memória está disponível para processamento de consultas.

Respondeu 06/08/2008 em 21:15
fonte usuário

votos
39

Caminhos de arquivos no DB é definitivamente o caminho a percorrer - Já ouvi muitas histórias de clientes com TB de imagens que se tornou um pesadelo tentando armazenar qualquer quantidade significativa de imagens em um DB - o desempenho atingido por si só é muito.

Respondeu 06/08/2008 em 19:07
fonte usuário

votos
35

Na minha experiência, por 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 particular, e vice-versa. Mas, ao mesmo tempo que você não está armazenando qualquer coisa sobre a imagem no banco de dados.

Respondeu 06/08/2008 em 18:59
fonte usuário

votos
31

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

Uma coisa a notar aqui é que ninguém no campo pró sistema de arquivos listou um sistema de arquivos particular. Quer isto dizer que tudo de FAT16 para ZFS com folga bate cada banco de dados?

Não.

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

O curso correto de ação é tomar a decisão certa para o seu cenário mais preciso, e para fazer isso, você vai precisar de alguns números e algumas estimativas de casos de uso.

Respondeu 31/08/2008 em 18:54
fonte usuário

votos
30

Em lugares onde você deve garantir a integridade referencial e conformidade ACID, o armazenamento de imagens no banco de dados é necessária.

Você não pode transactionaly garantir que a imagem ea meta-dados sobre essa imagem armazenada no banco de dados referem-se ao mesmo arquivo. Em outras palavras, é impossível garantir que o arquivo no sistema de arquivos só é sempre alterada ao mesmo tempo e na mesma transação como os metadados.

Respondeu 19/02/2009 em 22:28
fonte usuário

votos
28

Como já foi dito SQL 2008 vem com um tipo Filestream que permite que você armazene um nome ou identificador como um ponteiro no db e automaticamente armazena a imagem no seu sistema de arquivos que é um grande cenário.

Se você estiver em um banco de dados mais velho, então eu diria que se você está armazenando-o como dados blob, então você está realmente não vai conseguir nada fora do banco de dados na forma de funções de busca, por isso é provavelmente melhor para armazenar um endereço em um sistema de arquivos, e armazenar a imagem dessa forma.

Dessa forma, você também economizar espaço em seu sistema de arquivos, como você está indo só para salvar a quantidade exata de espaço, ou espaço, mesmo compactado no sistema de arquivos.

Além disso, você pode decidir economizar com alguma estrutura ou elementos que lhe permitem navegar pelas imagens matérias em seu sistema de arquivos, sem qualquer hits db, ou transferir os arquivos em massa para outro sistema, disco rígido, S3 ou outro cenário - atualizando o local em o seu programa, mas manter a estrutura, mais uma vez sem muito sucesso tentando trazer as imagens fora de seu db ao tentar aumentar o armazenamento.

Provavelmente, seria também permitem que você jogue algum elemento caching, baseado em URLs de imagem comumente atingidas em seu mecanismo de web / programa, de modo que você está salvando-se lá também.

Respondeu 30/08/2008 em 10:50
fonte usuário

votos
27

Pequenas imagens estáticas (não mais do que um par de megas) que não são frequentemente editados, devem ser armazenados no banco de dados. Este método tem várias vantagens, incluindo portabilidade mais fácil (as imagens são transferidas com o banco de dados), backup mais fácil / restore (imagens são apoiados com o banco de dados) e melhor escalabilidade (a pasta do sistema de arquivos com milhares de pequenos arquivos em miniatura soa como um pesadelo escalabilidade para mim).

Servindo-se imagens a partir de um banco de dados é fácil, basta implementar um manipulador http que serve a matriz de bytes retornado do servidor DB como um fluxo binário.

Respondeu 06/08/2008 em 19:46
fonte usuário

votos
26

Aqui está um papel branco interessante sobre o tema.

Para BLOB ou não a BLOB: armazenamento de objetos grandes em um banco de dados ou um sistema de arquivos

A resposta é "depende". Certamente iria depender o servidor de banco de dados e sua abordagem para armazenamento de blob. Ele também depende do tipo de dados que estão sendo armazenados em blobs, bem como a forma que os dados estão a ser acessado.

arquivos de menor tamanho podem ser eficientemente armazenado e entregue usando o banco de dados como o mecanismo de armazenamento. Arquivos maiores provavelmente seria melhor armazenados usando o sistema de arquivos, especialmente se eles serão modificados / atualizados frequentemente. (Blob fragmentação torna-se um problema em relação ao desempenho.)

Aqui está um ponto adicional a ter em mente. Uma das razões que suportam o uso de um banco de dados para armazenar as bolhas é o cumprimento ACID. No entanto, a abordagem que os testadores utilizado no papel branco, (massa arquivado opção de SQL Server,) que duplicou o rendimento SQL Server, efectivamente alterou a 'D' em ácido para um 'd', como os dados de blob não foi registado com a inicial escreve para a transação. Portanto, se o cumprimento ACID integral é um requisito importante para o seu sistema, reduzir pela metade os números de rendimento do SQL Server para o banco de dados grava quando se comparam arquivo I / O para blob banco de dados de I / O.

Respondeu 16/09/2008 em 21:28
fonte usuário

votos
25

Uma coisa que eu não vi ninguém falar ainda, mas é definitivamente digno de nota é que há problemas associados com o armazenamento de grandes quantidades de imagens na maioria dos sistemas de arquivos também. Por exemplo, se você tomar a abordagem mencionada acima e nomear cada arquivo de imagem após a chave primária, na maioria dos sistemas de arquivos que você vai ter problemas se você tentar colocar todas as imagens em um diretório grande uma vez que você chegar a um número muito grande de imagens ( por exemplo, na ordem das centenas de milhares ou milhões).

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

Respondeu 20/08/2008 em 19:25
fonte usuário

votos
22

Algo que ninguém tenha mencionado é que o DB garante ações atômicas, integridade transacional e lida com concorrência. Mesmo referencialmente integridade está fora da janela com um sistema de arquivos - assim como você sabe seus nomes de arquivo são realmente ainda correto?

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

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

Respondeu 28/11/2008 em 07:33
fonte usuário

votos
20

O problema com o armazenamento única filepaths a imagens em um banco de dados é que a integridade do banco de dados não pode ser forçado.

Se a imagem real apontado pelo caminho de arquivo se torna indisponível, o banco de dados inadvertidamente tem um erro de integridade.

Tendo em conta que as imagens são os dados reais que está sendo procurado, e que eles podem ser gerenciados mais fácil (as imagens não vai desaparecer de repente) em um banco de dados integrado ao invés de ter a interface com algum tipo de sistema de arquivos (se o sistema de arquivos é acessado de forma independente, as imagens podem de repente "desaparecer"), eu iria para armazená-los diretamente como um BLOB ou tal.

Respondeu 08/04/2009 em 17:35
fonte usuário

votos
17

Em uma empresa onde eu costumava trabalhar nós armazenados 155 milhões de imagens em um 8i Oracle (9i seguida) banco de dados. vale a pena 7,5 TB.

Respondeu 06/08/2008 em 19:37
fonte usuário

votos
14

Normalmente, eu sou storngly contra tomando a parte mais cara e mais difícil de escala de sua infra-estrutura (base de dados) e colocar toda a carga para ele. Por outro lado: Ele simplifica muito a estratégia de backup, especialmente quando você tem vários servidores web e precisa de alguma forma manter os dados sincronizados.

Como a maioria das outras coisas, depende do tamanho esperado e Orçamento.

Respondeu 06/08/2008 em 18:42
fonte usuário

votos
13

Temos implementado um sistema de imagens de documentos que armazena tudo que é imagens em campos SQL2005 blob. Existem várias centenas de GB no momento e estamos vendo os tempos de resposta excelentes e pouca ou nenhuma degradação de desempenho. Além disso, a conformidade regulamentar fr, temos uma camada de middleware que arquiva documentos recém-lançada para um sistema de jukebox óptico que os expõe como um sistema de arquivos NTFS padrão.

Estamos muito satisfeitos com os resultados, particularmente com respeito a:

  1. Facilidade de replicação e backup
  2. Capacidade de implementar facilmente um sistema de versões de documentos
Respondeu 26/10/2008 em 18:55
fonte usuário

votos
11

Assunção: Application é baseado na web habilitado / web

Estou surpreso que ninguém tenha realmente mencionou isso ... delegá-la aos outros que são especialistas -> usar um terceiro fornecedor de imagens do partido / arquivo hospedagem .

Armazene seus arquivos em um serviço on-line pago como

Outra tópicos StackOverflow falando sobre isso aqui .

Esta discussão explica por que você deve usar um terceiro provedor de partido de hospedagem.

É assim vale a pena. Eles armazená-lo de forma eficiente. Sem largura de banda ficando carregado a partir de seus servidores às solicitações do cliente, etc.

Respondeu 18/05/2009 em 14:18
fonte usuário

votos
11

Se este é um aplicativo baseado na web, em seguida, pode haver vantagens para armazenar as imagens em uma rede de distribuição de armazenamento de terceiros, como o S3 da Amazon ou a plataforma Nirvanix.

Respondeu 06/08/2008 em 18:52
fonte usuário

votos
10

Se você não está no SQL Server 2008 e você tem algumas razões sólidas para colocar arquivos de imagem específicos no banco de dados, então você pode tomar a abordagem "ambos" e usar o sistema de arquivos como um cache temporário e usar o banco de dados como o repositório mestre .

Por exemplo, sua lógica de negócios pode verificar se um arquivo de imagem existente no disco antes de servir-se, recuperando a partir do banco de dados quando necessário. Esta compra-lhe a capacidade de vários servidores web e menos problemas de sincronização.

Respondeu 02/09/2008 em 15:01
fonte usuário

votos
7

Eu criei recentemente um aplicativo PHP / MySQL que armazena PDFs / arquivos do Word em uma tabela MySQL (tão grande como 40MB por arquivo até agora).

prós:

  • Arquivos enviados são replicados para o servidor de backup juntamente com tudo o resto, nenhuma estratégia de backup separado é necessário (paz de espírito).
  • Configurar o servidor web é um pouco mais simples, porque eu não precisa ter uma pasta / uploads e contar todos os meus aplicações onde é.
  • Eu começar a usar transações para edições para melhorar a integridade dos dados - Eu não precisa se preocupar com arquivos órfãos e desaparecidos

contras:

  • mysqldump agora leva um tempo looooong porque há 500MB de dados de arquivo em uma das mesas.
  • Em geral, não muito memória / CPU eficiente quando comparado ao sistema de arquivos

Eu chamaria minha implementação um sucesso, ele cuida de requisitos de backup e simplifica o layout do projeto. O desempenho é bom para os 20-30 pessoas que usam o aplicativo.

Respondeu 08/12/2008 em 05:31
fonte usuário

votos
7

Depende do número de imagens que você está indo para armazenar e também seus tamanhos. Eu tenho usado bancos de dados para armazenar imagens no passado e minha experiência tem sido bastante boa.

IMO, profissionais de usar banco de dados para armazenar as imagens são,

A. Você não precisa de estrutura FS para manter suas imagens
B. índices de banco de dados têm melhor desempenho do que as árvores FS quando mais número de itens devem ser armazenados
C. Smartly banco de dados sintonizado realizar bom trabalho em cache os resultados da consulta
D. Backups são simples. Ele também funciona bem se você tiver replicação configurar e conteúdo é entregue a partir de um servidor próximo ao usuário. Em tais casos, a sincronização explícita não é necessária.

Se as imagens vão ser pequena (digamos <64k) e o mecanismo de armazenamento de sua db suporta inline (no registro) BLOBs, ele melhora o desempenho ainda mais como não é necessária qualquer engano (localidade de referência é alcançada).

Armazenamento de imagens pode ser uma má idéia quando você está lidando com um pequeno número de grandes imagens de tamanho. Outro problema com o armazenamento de imagens em db é que, metadados, como criação, datas de modificação deve manipulados por sua aplicação.

Respondeu 05/09/2008 em 11:54
fonte usuário

votos
7

SQL Server 2008 oferece uma solução que tem o melhor dos dois mundos: O tipo de dados filestream .

Gerenciá-lo como uma tabela regular e têm o desempenho do sistema de arquivos.

Respondeu 28/08/2008 em 22:37
fonte usuário

votos
7

Eu não tenho certeza quanto de um exemplo "mundo real" este é, mas eu tenho atualmente uma aplicação lá fora, que armazena detalhes de um jogo de cartas, incluindo as imagens para os cartões. Concedida a contagem de registros do banco de dados é de apenas 2.851 registros até o momento, mas dado o fato de que certos cartões têm são libertados várias vezes e têm obras de arte alternativo, foi sizewise realmente mais eficiente para digitalizar o "quadrado principal" da obra de arte e, em seguida, dinamicamente gerar os efeitos de borda e diversos para o cartão quando solicitado.

O criador original desta biblioteca imagem criada uma classe de acesso de dados que processa a imagem com base no pedido, e ele faz isso muito rápido para visualização e cartão individual.

Isso também facilita a implantação / atualizações quando novos cartões são liberados, em vez de fechar-se uma pasta inteira de imagens e enviar aqueles para baixo o tubo e garantir a estrutura da pasta adequada é criado, eu simplesmente atualizar o banco de dados e têm o usuário fazer o download novamente. Este tamanhos atualmente até 56MB, o que não é grande, mas eu estou trabalhando em um recurso de atualização incremental para versões futuras. Além disso, há um "sem imagens" versão do aplicativo que permite que aqueles com mais de dial-up para obter a aplicação sem demora download.

Esta solução tem funcionado muito bem até agora, desde a aplicação em si é apontado como uma única instância no ambiente de trabalho. Existe um site onde todos os dados são arquivados para acesso on-line, mas eu gostaria de modo algum usar a mesma solução para isso. Concordo o acesso a arquivos seria preferível porque iria escalar melhor a frequência e volume de solicitações que estão sendo feitas para as imagens.

Esperemos que este não é muito murmúrio, mas eu vi o tema e quis fornecer alguns meus insights de uma aplicação / small relativamente bem sucedida média escala.

Respondeu 20/08/2008 em 19:42
fonte usuário

votos
6

Im minha experiência que eu tinha para gerenciar ambas as situações: imagens armazenadas no banco de dados e imagens no sistema de arquivos com caminho armazenado em db.

A primeira solução, imagens em banco de dados, é um pouco mais "limpo", como sua camada de acesso a dados terá que lidar apenas com objetos de banco de dados; mas isso só é boa quando você tem que lidar com números baixos.

Obviamente, o desempenho de acesso de banco de dados quando você lida com grandes objetos binários é degradante, e as dimensões do banco de dados vai crescer muito, causando novamente perda de desempenho ... e, normalmente, o espaço de banco de dados é muito mais caro do que o espaço do sistema de arquivos.

Por outro lado ter grandes objetos binários armazenados no sistema de arquivos fará com que você tem planos de backup que tem que considerar tanto o sistema de banco de dados e arquivo, e isso pode ser um problema para alguns sistemas.

Outra razão para ir para o sistema de arquivos é quando você tem que compartilhar suas imagens de dados (ou sons, vídeo, seja qual for) com acesso de terceiros: Neste dias que estou desenvolvendo uma aplicação web que usa imagens que têm de ser acessado a partir de "fora "minha fazenda web de tal forma que um acesso de banco de dados para recuperar dados binário é simplesmente impossível. Então, às vezes há também projetar considerações que irá levá-lo para uma escolha.

Considere também, ao fazer esta escolha, se você tem que lidar com a permissão e autenticação ao acessar objetos binários: esses requisitos normalmente pode ser resolvido de uma maneira mais fácil quando os dados são armazenados no db.

Respondeu 02/09/2008 em 08:20
fonte usuário

votos
4

Em um projeto anterior i imagens armazenadas no sistema de arquivos, e que causou muita dor de cabeça com backups, replicação e o sistema de arquivos ficar fora de sincronia com o banco de dados.

Na minha mais recente projeto que estou armazenar imagens no banco de dados e cache-los no sistema de arquivos, e ele funciona muito bem. Eu não tive nenhum problema até agora.

Respondeu 16/12/2009 em 15:29
fonte usuário

votos
4

Certa vez, trabalhei em um aplicativo de processamento de imagem. Nós armazenadas as imagens carregadas em um diretório que era algo como / images / [data de hoje] / [número de identificação]. Mas também extraídos os metadados (dados EXIF) a partir das imagens e armazenado que no banco de dados, juntamente com um timestamp e tal.

Respondeu 20/08/2008 em 19:51
fonte usuário

votos
3

Armazenar uma imagem no banco de dados ainda significa que os dados da imagem acaba em algum lugar do sistema de arquivos, mas obscurecida por isso que você não pode acessá-lo diretamente.

+ Ves:

  • integridade de dados
  • é fácil de gerir desde que você não tem que se preocupar em manter o sistema de arquivos em sincronia quando uma imagem é adicionada ou excluída

-ves:

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

Ambos os métodos são comuns e praticada. Ter um olhar para as vantagens e desvantagens. De qualquer maneira, você tem que pensar sobre como superar as desvantagens. Armazenar em banco de dados geralmente significa ajustar parâmetros de banco de dados e implementar algum tipo de cache. Usando sistema de arquivos requer que você encontrar alguma maneira de manter sistema de arquivos + banco de dados em sincronia.

Respondeu 18/05/2009 em 07:36
fonte usuário

votos
3

A palavra na rua é que a menos que você é um fornecedor de banco de dados tentando provar que seu banco de dados pode fazê-lo (como, digamos Microsoft gabando TerraServer armazenar imagens de um bajillion em SQL Server) não é uma idéia muito boa. Quando a alternativa - o armazenamento de imagens em servidores de arquivos e caminhos no banco de dados é muito mais fácil, por que se preocupar? campos Blob é tipo como as capacidades off-road de SUVs - a maioria das pessoas não usá-los, aqueles que costumam ficar em apuros, e depois há aqueles que o fazem, mas apenas para a diversão.

Respondeu 06/08/2008 em 22:19
fonte usuário

votos
3

Segundo a recomendação sobre os caminhos de arquivo. Eu trabalhei em um par de projetos que precisavam gerenciar coleções de ativos grandes-ish, e qualquer tentativa de guardar as coisas diretamente no DB resultou em dor e frustração a longo prazo.

A única real "pro" eu posso pensar sobre armazená-los no DB é o potencial para fácil de ativos de imagem individuais. Se não existirem caminhos de arquivo para usar, e todas as imagens são transmitidos diretamente para fora do DB, não há perigo de um encontrando usuário arquivos que não deveriam ter acesso.

Isso parece que seria melhor resolvido com um script intermediário puxando dados de um armazenamento de arquivos web-inacessível, apesar de tudo. Assim, o armazenamento DB não é realmente necessário.

Respondeu 06/08/2008 em 18:51
fonte usuário

votos
2

Eu sou o desenvolvedor líder em um sistema de gerenciamento de documentos da empresa em que alguns clientes armazenar centenas de gigabytes de documentos. Terabytes em um futuro não muito distante. Usamos o sistema de arquivos abordagem para muitos dos motivos mencionados nesta página mais outra: arquivamento.

Muitos de nossos clientes devem estar em conformidade com as regras de arquivamento específicos da indústria, como o armazenamento em disco ou armazenamento óptico em um formato não-proprietário. Além disso, você tem a flexibilidade de simplesmente adicionar mais discos para um dispositivo NAS. Se você tem seus arquivos armazenados em seu banco de dados, mesmo com tipo de dados fluxo de arquivos SQL Server 2008, suas opções de arquivamento só se tornou muito mais estreito.

Respondeu 30/08/2008 em 11:15
fonte usuário

votos
1

Como alguém já mencionado, "depende". Se o armazenamento em um banco de dados é suposto ser um substituto 1-to-1 fantasia para sistema de arquivos, não pode ser completamente uma melhor opção.

No entanto, se um banco de dados backend irá fornecer valores adicionais, não apenas uma serialização e armazenamento de uma bolha, então ele pode fazer um sentido real.

Você pode dar uma olhada em WKT Raster que é um projeto que visa desenvolver o apoio raster no PostGIS que por sua vez serve como uma extensão geoespacial para PostgreSQL sistema de banco de dados. Idéia por trás do WKT Raster não é apenas para definir um formato para serialização raster e armazenamento (usando o sistema PostgreSQL), mas, o que é muito mais importante do que o armazenamento, é especificar do lado do banco de dados de processamento de imagem eficiente acessível a partir de SQL. Para encurtar a história, a idéia é mover o peso operacional do cliente para o back-end de banco de dados, por isso demorar lugares tão perto de armazenamento em si quanto possível. O WKT quadriculação, como PostGIS, é dedicar para aplicações de domínio específico, SIG .

Para panorama mais completo, verificar o website e apresentação (PDF) do sistema.

Respondeu 03/02/2010 em 21:39
fonte usuário

votos
1

Se você precisa armazenar muitas imagens no sistema de arquivos de um par de coisas para pensar incluem:

  • Backup e restauração. Como você mantém as imagens em sincronia.
  • desempenho do sistema de arquivos. Depende do que você está fazendo e o sistema de arquivos, mas você pode querer implementar um mecanismo de hashing para que você não tem um único diretório com bilhões de arquivos.
  • Replicação. Você precisa manter os arquivos sincronizados entre vários servidores?
Respondeu 22/08/2008 em 16:49
fonte usuário

votos
1

A única razão que nós armazenar imagens em nossas mesas é porque cada tabela (ou conjunto de tabelas por faixa de trabalho) é temporária e caiu no final do fluxo de trabalho. Se houvesse qualquer tipo de armazenamento a longo prazo nós definitivamente optar por armazenar os caminhos de arquivo.

Também deve-se notar que nós trabalhamos com uma aplicação cliente / servidor internamente então não há nenhuma interface web para se preocupar.

Respondeu 20/08/2008 em 19:49
fonte usuário

votos
1

Eu pessoalmente armazenar os grandes volumes de dados fora do banco de dados.

Prós: armazena tudo em um, por favor, fácil acesso a arquivos de dados, fácil Contras baskup: Diminui o desempenho do banco de dados, muitas página splits, possível coruption banco de dados

Respondeu 06/08/2008 em 18:41
fonte usuário

votos
1

O seu web-servidor (eu estou supondo que você está usando um) é projetado para lidar com imagens, enquanto um banco de dados não é. Assim, eu iria votar pesadamente no lado nay.

Armazenar apenas o caminho (e talvez Informações do arquivo também) no banco de dados.

Respondeu 06/08/2008 em 18:40
fonte usuário

votos
0

Irei para ambos solução, eu quero dizer ... Eu vou desenvolver um componente do litle (EJB) que armazenar as imagens em um banco de dados mais o caminho desta imagem para o servidor. Este DB só será atualizado se temos uma nova imagem ou a imagem original é atualizado. Então eu também irá armazenar o caminho no DB negócio.

Do ponto de vista da aplicação, sempre vou usuário do sistema de arquivos (recuperando o caminho de th DB negócios) e por este caminho, vamos resolver o problema de backup, e também evitar possíveis problemas de desempenho.

A única fraqueza é que vamos armazenar a mesma imagem 2 vezes ... o bom ponto é que a memória é barato, vamos lá !.

Respondeu 26/01/2012 em 17:05
fonte usuário

votos
0

Se você estiver em Teradata, então Teradata desenvolvedor Exchange tem um artigo detalhado sobre a carga e recuperação de lobs e bolhas ..

http://developer.teradata.com/applications/articles/large-objects-part-1-loading

Respondeu 27/09/2011 em 12:34
fonte usuário

votos
0

Para um grande número de pequenas imagens , o banco de dados pode ser melhor.

Eu tive uma aplicação com muitas miniaturas pequenas (2Kb cada). Quando eu colocá-los no sistema de arquivos, cada um deles consumiu 8kb, devido ao tamanho de bloco do sistema de arquivos. Um aumento de 400% no espaço!

Veja este post para mais informações sobre o tamanho do bloco: Qual é o tamanho do bloco do sistema de arquivos iphone?

Respondeu 17/05/2011 em 10:15
fonte usuário

votos
0

Eu tenho trabalhado com muitos sistemas de armazenamento digital e todos eles armazenar objetos digitais no sistema de arquivos. Eles tendem a usar uma abordagem ramo, de modo que haverá uma árvore de arquivo no sistema de arquivos, muitas vezes começando com o ano de entrada por exemplo, 2009, subdiretório será mês eg 8 para agosto, próximo diretório será dia eg 11 e às vezes eles vão usar hora, bem como, o arquivo será então chamado com os registros persistente identificação. Usando BLOBS tem suas vantagens e eu ouvi de ser utilizado frequentemente nas partes de TI da indústria química para armazenar milhares ou milhões de fotografias e diagramas. Ele pode fornecer uma segurança mais granular, um único método de backup, potencialmente melhor a integridade dos dados e melhorou pesquisa entre media, a Oracle tem muitos recursos para isso dentro do pacote que eles costumavam chamar Intermedia (acho que é chamado de outra coisa agora). O sistema de arquivos também podem ter segurança granular através de um regime como o XACML ou outro objeto de segurança tipo XML. Veja D Espaço do Fedora Object Store para exemplos.

Respondeu 11/08/2009 em 12:27
fonte usuário

votos
0

Eu quase nunca armazená-las no DB. A melhor abordagem é geralmente para armazenar suas imagens em um caminho controlado por uma variável de configuração central e nomear as imagens de acordo com a tabela de banco de dados e chave primária (se possível). Isto dá-lhe as seguintes vantagens:

  • Mover suas imagens para outra partição ou servidor apenas atualizando a configuração global.
  • Encontrar o registro através de pesquisa na sua chave primária corresponde à imagem.
  • Suas imagens são acessíveis a ferramentas de processamento como imagemagick.
  • Na web-apps suas imagens podem ser manipulados pelo seu servidor web diretamente (processamento de poupança).
  • ferramentas CMS e linguagens web como Coldfusion pode lidar com upload nativamente.
Respondeu 18/05/2009 em 14:36
fonte usuário

votos
0

Banco de dados para dados

Sistema de arquivos para arquivos

Respondeu 02/03/2009 em 08:14
fonte usuário

votos
0

Eu iria com a abordagem do sistema de arquivos, principalmente devido à sua maior flexibilidade. Considere que se o número de imagens fica enorme, um banco de dados pode não ser capaz de lidar com isso. Com sistema de arquivos, você pode simples adicionar mais servidores de arquivo, assumindo que você está usando NFS ou tipo.

Outra vantagem da abordagem do sistema de arquivos tem é o de ser capaz de fazer alguns animais de fantasia, como você pode usar o Amazon S3 como o armazenamento primário (salvar a url no banco de dados em vez de caminho do arquivo). Em caso de falta de acontecer a S3, você cair de volta para o servidor de arquivos (pode ser outra entrada do banco de dados que contém o caminho do arquivo). Alguns vodu para aplicar a Apache ou qualquer servidor web que você está usando.

Respondeu 09/12/2008 em 20:51
fonte usuário

votos
0

Eu iria com a abordagem do sistema de arquivos. Não há necessidade de criar ou manter um banco de dados com imagens, você vai economizar alguns grandes dores de cabeça a longo prazo.

Respondeu 02/09/2008 em 20:33
fonte usuário

votos
0

Eu prefiro guardar caminhos de imagem no DB e imagens no sistema de arquivos (com rsync entre os servidores para manter tudo razoavelmente atual).

No entanto, algumas das coisas de gerenciamento do sistema de conteúdo eu faço precisa as imagens na CMS para vários controle de visibilidade razões- (de modo que o ativo é retido até que o comunicado de imprensa sai), controle de versão, a reformatação (alguns CMS irá redimensionar dinamicamente para thumbnails) e facilidade de uso para ligar as imagens nas páginas WYSIWYG.

Assim, a regra de ouro para mim é sempre coisas aplicação esconderijo no sistema de arquivos, a menos que seja CMS conduzido.

Respondeu 02/09/2008 em 17:15
fonte usuário

votos
0

Outra vantagem de armazenar as imagens no sistema de arquivos é que você não tem que fazer nada especial para ter o cache do cliente deles ...

... a não ser, claro, a imagem não é acessível através da raiz do documento (por exemplo, barreiras de autenticação), caso em que você vai precisar para verificar os cabeçalhos de controle de cache de seu código está enviando.

Respondeu 30/08/2008 em 05:27
fonte usuário

votos
0

Uma coisa que você precisa ter em mente é o tamanho do seu conjunto de dados. Acredito que Dillie-O foi o único que até mesmo bater remotamente o ponto.

Se você tem um pequeno, único usuário, app consumidor, então eu diria DB. Eu tenho um aplicativo de gerenciamento de DVD que usa o sistema de arquivos (em Arquivos de Programas em que) e é um PIA para backup. Eu desejo que cada vez que eles armazená-los em um db, e deixe-me escolher onde deseja salvar o arquivo.

Para uma aplicação comercial maior, então eu ia começar a mudar o meu pensamento. Eu costumava trabalhar para uma empresa que desenvolveu o aplicativo de gerenciamento de informações funcionários do condado. Gostaríamos de armazenar as imagens em disco, em um formato codificado [para lidar com problemas FS com grande número de arquivos] com base no número instrumento condado atribuído. Este foi útil em outra frente como a imagem poderia existir antes que o registro DB (devido ao seu fluxo de trabalho).

Tal como acontece com a maioria das coisas: 'Depende do que você está fazendo'

Respondeu 30/08/2008 em 00:04
fonte usuário

votos
0

sistema de arquivos, com certeza. Então você começa a usar todas as funcionalidades do sistema operacional para lidar com essas imagens - cópias de segurança, servidor web, mesmo que apenas scripts mudanças lote usando ferramentas como ImageMagic. Se você armazená-las no DB então você precisa escrever seu próprio código para resolver estes problemas.

Respondeu 28/08/2008 em 21:12
fonte usuário

votos
0

Puxando cargas de dados binários fora de seu DB sobre o fio vai causar problemas de latência enormes e não escala bem.

caminhos loja no DB e deixe o seu servidor web levar a carga - é o que ele foi projetado para!

Respondeu 22/08/2008 em 17:08
fonte usuário

votos
0

A tentativa de imitar um sistema de arquivos usando SQL é geralmente um mau plano. Você finalmente escrever menos código com resultados iguais ou melhores se você ficar com o sistema de arquivos para armazenamento externo.

Respondeu 20/08/2008 em 19:15
fonte usuário

votos
-1

Se você está planejando um web site público enfrenta, então você não deve ir com qualquer opção. Seu deve usar um Content Delivery Network (CDN). Há preços, escalabilidade e velocidade vantagens a um CDN quando entregar uma grande quantidade de conteúdo estático através da internet.

Respondeu 04/11/2008 em 21:30
fonte usuário

votos
-1

Imagens de um armazenamento de arquivos são a melhor aposta, e complementar isso com armazenar os dados de meta em um banco de dados. De uma perspectiva de servidor web, a maneira mais rápida para servir o material acima é apontar diretamente para ele. Se é no banco de dados - ala Sharepoint - você tem a sobrecarga de ADO.Net para puxá-lo para fora, transmiti-lo, etc.

Documentum - enquanto inchado e complicado - tem direito, em que os arquivos estão fora na partilha e disponível para você determinar como armazená-los - em disco no servidor, SAN, NAS, seja qual for. A estratégia Documentum é armazenar os arquivos de uma estrutura de árvore por codificação de pastas e nomes de arquivo de acordo com sua chave primária na DB. O DB torna-se o recurso para saber quais arquivos são o que e para a segurança de execução. Para sistemas de alto volume deste tipo de abordagem é um bom caminho a percorrer.

Considere também este ao lidar com metadados: caso você tenha necessidade de atualizar os atributos do seu corpus de dados meta, o DB é seu amigo, como você pode executar rapidamente as atualizações com SQL. Com outros sistemas de marcação que você não tem as ferramentas de manipulação de dados fáceis na mão

Respondeu 03/10/2008 em 00:33
fonte usuário

votos
-1

No meu pequeno aplicativo que eu tenho pelo menos um milhão de arquivos pesando cerca de 200GB na última contagem. Todos os arquivos estão sentados em um sistema de arquivos XFS montado em um servidor linux em iSCSI. Os caminhos são armazenados na base de dados. usar algum tipo de convenção de nomeação inteligente para seus caminhos de arquivo e nomes de arquivo.

IMHO, use o sistema de arquivos para o que pretendia fazer - armazenar arquivos. Bancos de dados geralmente não oferecem qualquer vantagem sobre um sistema de arquivos padrão no armazenamento de dados binários.

Respondeu 15/09/2008 em 20:27
fonte usuário

votos
-1

Na minha aplicação atual, eu estou fazendo ambos. Quando o usuário identifica uma imagem para anexar a um registro, eu uso o ImageMagick para redimensioná-la para um tamanho adequado para exibição na tela (cerca de 300x300 para a minha candidatura) e armazenar que no banco de dados para facilitar o acesso, mas depois também copiar o usuário do arquivo original para um compartilhamento de rede para que ele está disponível para aplicações que requerem maior resolução (como impressão).

(Há um par de outros fatores envolvidos, bem como: Navision só irá mostrar BMPs, então quando eu redimensioná-la Eu também converter para BMP para o armazenamento eo banco de dados é replicado para locais remotos onde é útil para ser capaz de exibir a imagem de impressão. só é feito na sede, então eu não preciso replicar o arquivo original.)

Respondeu 08/09/2008 em 20:51
fonte usuário

votos
-1

Não, devido a divisões de página. Você está definindo essencialmente linhas que podem ser 1 KB - n MB para que o seu banco de dados terá um monte de espaços vazios em suas páginas o que é ruim para o desempenho.

Respondeu 22/08/2008 em 17:48
fonte usuário

votos
-1

Eu iria com a abordagem do sistema de arquivos. Como observado por alguns outros, a maioria dos servidores web são construídas para enviar imagens a partir de um caminho de arquivo. Você vai ter um desempenho muito superior se você não tem que escrever ou transmitir para fora campos BLOB do banco de dados. Tendo armazenamento do sistema de arquivos para as imagens faz com que seja mais fácil de páginas estáticas de configuração quando o conteúdo não está mudando ou se você quiser limitar a carga sobre o banco de dados.

Respondeu 06/08/2008 em 22:45
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more