Solução de design para armazenamento e busca de imagens

StackOverflow https://stackoverflow.com/questions/2835301

Pergunta

Essa é uma dúvida de design que estou enfrentando, tenho uma coleção de 1500 imagens que devem ser exibidas em uma página asp.net, as imagens a serem exibidas diferem de uma página para outra, a contagem dessas imagens aumentará com o tempo vir,

a.) é uma boa ideia ter as imagens no banco de dados, mas o tempo de ida e volta para buscar as imagens no banco de dados pode ser alto.

b.) é bom ter todas as imagens em um diretório e ter um sistema de arquivos virtual sobre ele, e o aplicativo acessará as imagens do diretório

Temos em particular alguma estratégia de design em um banco de dados tradicional para buscar imagens com o menor tempo de ida e volta? Existe alguma solução além do uso de um banco de dados tradicional?

Editar 1:Cada imagem é substituída por sua nova entrada a cada 12 horas, portanto, tê-las no banco de dados pode não ser uma boa ideia, mas quão melhor será usar um armazenamento de dados e indexar essas imagens?

Editar 2:Sim, estamos planejando executar o aplicativo em um cluster.E se tentarmos usar um armazenamento de dados (se for uma boa opção), ele será compatível com C# e ASP.NET?

obs:Eu uso o SQL Server para armazenar essas imagens.

Foi útil?

Solução

Todos os comentários anteriores são muito bons...Na ausência de requisitos muito específicos, temos de fazer generalizações amplas para ilustrar as suas opções.Aqui estão alguns exemplos.

  • Se velocidade bruta é o que você precisa, então os arquivos simples são um claro vencedor.Quer você esteja usando Apache ou IIS, ambos são otimizados para fornecer conteúdo estático baseado em arquivo com muita rapidez.Todos os sites de alto desempenho sabem disso e armazenarão grande parte de seu conteúdo com o tratamento dinâmico em mente, mas então “publicarão” partes selecionadas de seu conteúdo dinâmico;em versões estáticas;ao seu web farm periodicamente ou baseado em eventos.Embora exija um pouco de orquestração, isso pode ser feito de forma barata e pode realmente reduzir a carga do seu servidor de banco de dados, rede backend, etc.Como exemplo simples, publique em uma pasta com a raiz dessa estrutura sendo avaliada dinamicamente.quando estiver pronto para publicar atualizações, escreva uma nova pasta e altere o caminho raiz.Sem tempo de inatividade, barato e fácil.Por falar nisso, extrair todas essas informações de um armazenamento de back-end exigirá que você carregue essas coisas na memória.Em última análise, isso se traduzirá em mais tempo na coleta de lixo e, consequentemente, significará que seu aplicativo será mais lento, mesmo se você estiver usando jardinagem com vários processadores/núcleos.

  • Se você precisar controle refinado sobre como as imagens são organizadas/expostas, então as pastas podem não ser as mais apropriadas.Se, por exemplo, você precisar organizar imagens de usuários individuais e rastrear muitos metadados em torno das imagens, um banco de dados pode ser uma boa opção.Dito isso, sua equipe de banco de dados provavelmente irá odiá-lo por isso, porque isso apresenta uma série de desafios do ponto de vista do gerenciamento de banco de dados.Além disso, se você estiver usando um ORM, poderá ter problemas para fazer isso funcionar e descobrir que o consumo de memória aumenta para níveis inaceitáveis ​​devido a objetos proxy ocultos, cache de segundo nível, etc.Tudo isso pode ser mitigado, portanto, tome cuidado e certifique-se de criar o perfil de seu aplicativo.Dito isso, uma loja estruturada (como um banco de dados) é mais ideal para este caso de uso.

  • Considerando segurança...Dependendo do que essas imagens representam, os arquivos simples inevitavelmente levam a preocupações sobre ataques de canonização, enumeração de força bruta de estruturas de pastas navegáveis, repetição de cookies, URLs, estado de visualização, etc.Se você estiver usando um modelo de segurança personalizado baseado em funções ou em declarações, poderá achar que o uso de arquivos simples se torna um tanto doloroso, pois você terá que mapear restrições de segurança do sistema de arquivos para restrições de segurança lógicas/contextuais.Questões como essas muitas vezes me levam a preferir uma loja estruturada.

A ideia de cache mencionada é boa e pode ajudar a criar um meio-termo em relação à frequência com que você realmente acessa seu banco de dados, embora não ajude com preocupações relacionadas ao consumo de memória, GC, etc.Você poderia empregar mecanismos de cache integrados, embora um Cache/Grid que suporte armazenamentos de apoio seria muito melhor se você puder pagar (Ex.NCache, ScaleOut, etc.).Eles fornecem boa escalabilidade/redundância e também podem ser usados ​​para descarregar o armazenamento do estado da sessão, estado de visualização e muito mais.

Espero que isto ajude.

Outras dicas

Você basicamente tem 2 opções

1) Armazene o binário no banco de dados. O campo varbinário (max) será uma boa opção de tipo de dados. 2) Armazene o caminho para a imagem armazenada no disco no banco de dados. Nvarchar (Max) será uma boa opção para o Datatype.

É claro que existem profissionais e vigaristas de ambas as soluções. Sem saber mais sobre seus requisitos, é difícil aconselhar qual é a melhor maneira.

Prefiro não armazenar imagens no banco de dados - em vez disso, basta armazenar um link (caminho/nome do arquivo/id etc) na imagem correta.

Então, se você implementar um httphandler para servir as imagens, poderá armazená -las em qualquer local que desejar. Aqui está uma implementação muito básica:

public class myPhototHandler: IHttpHandler
{    

    public bool IsReusable {
        get { return true; }
    }

    public void ProcessRequest(System.Web.HttpContext context)
    {

            if (Context.User.Identity.IsAuthenticated) {
                var filename = context.Request.QueryString("f") ?? String.Empty;
                string completePath = context.Server.MapPath(string.Format("~/App_Data/Photos/{0}", filename));
                context.Response.ContentType = "image/jpeg";
                context.Response.WriteFile(completePath);             
            }

    }

}

Para um ótimo recurso na configuração de um confinador, check -out esta postagem do blog e os outros posts relacionados.

Eu não complicaria demais sua solução. A desvantagem para armazenar imagens em um banco de dados é o banco de dados e os requisitos de armazenamento para backups, especialmente se as imagens forem boas apenas para 12 horas. Em caso de dúvida, mantenha -o simples; portanto, quando os requisitos mudarem, você não investiu tanto tempo.

Foi assim que fiz no meu site.

  • Armazene as imagens em uma pasta.
  • Se você deseja controle sobre o nome do arquivo que o usuário vê ou emprega lógica condicional, use um httphandler para servir a imagem; caso contrário, basta usar seu caminho completo e nome do arquivo em uma tag IMG.
  • Se você está falando de um mega site de alto volume, talvez considere usar uma rede de entrega de conteúdo.

Você já considerou o armazenamento em cache de suas imagens para mitigar o tempo de ida e volta para o SQL Server? O cache pode ser apropriado no navegador (via Cabeçalhos HTTP) e/ou o manipulador HTTP que serve a imagem (via System.web.caching).

O armazenamento de imagens no SQL Server pode ser conveniente, porque você não precisa se preocupar em manter as dicas no sistema de arquivos. No entanto, o tamanho do seu banco de dados será obviamente muito maior, o que pode tornar os backups e a manutenção mais complexos. Você pode considerar o uso de um grupo de arquivos diferente no seu banco de dados para suas tabelas de imagem ou um banco de dados separado, para que você possa manter dados de linha separados dos dados da imagem.

Usando o SQL Server também significa que você terá opções fáceis para controle de simultaneidade, particionamento e replicação, caso seja apropriado para o seu aplicativo.

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