Exibição de imagens do servidor SQL vs. sistema de arquivos vs. S3 etc.

Meu aplicativo (clássico asp yay!) Tem cerca de 2,1 milhões de imagens a 25 GB e isso representa apenas 90 dias de dados e eu gostaria de ter 365 no mínimo. Preciso controlá-las e estou considerando todas as opções. Como você pensa sobre os prós e os contras das seguintes práticas:

• Prós do SQL Server: Fácil de fazer backup Contras: Desempenho?
• Prós do sistema de arquivos: Velocidade Contras: Redundância, o backup é lento (atualmente pesquisando fazer backups sintéticos completos, o que pode melhorar isso)
• S3 e similares Prós: a largura de banda foi transferida do meu datacenter para a Amazon, armazenamento praticamente ilimitado. Contras: Custo, Análise de custo é complicado (estimar 80% da minha largura de banda é imagens para fins de ROI)

Alguém mais lida com o desafio de milhões de imagens e como você o enfrentou?

Não temos milhões de imagens, mas temos centenas de milhares e usamos a abordagem híbrida - mysql para metadados, imagens armazenadas no disco local para backup e enviadas para o Amazon s3, onde são servidas aos usuários. Não tivemos problemas com a Amazon e a disponibilidade. Mudar para o cloudfront está em nossos planos, basta encontrar o tempo.

Esta discussão pode ser útil para você na sua decisão:
http://ask.metafilter.com/59635/Millions-of-images

Eu iria com metadados no servidor SQL e arquivos no sistema de arquivos (ou s3 ou cloudfront). Mas a melhor resposta depende de alguns outros padrões de uso:

• as imagens mudam frequentemente
• você pode servir as imagens diretamente do sistema de arquivos (ou seja img src="...") ou precisa que elas sejam controladas por acesso. Nesse último caso, uma solução de banco de dados é melhor
• você está exibindo um pequeno número de imagens na maioria das vezes (os 10% mais recentes) ou a distribuição é relativamente ampla.

Os backups para milhões de imagens serão complicados, não importa como você os organize - são apenas muitos dados. Gostaria de encontrar um bom estudo de caso sobre o backup de blobs no SQL Server antes de me comprometer com essa solução. (Aqui está um artigo que pode ser útil: http://www.databasejournal.com/features/mssql/article.php/3738276/Storing-Images-and-BLOB-files-in-SQL-Server-Part-4.htm )

Se você decidir armazená-las no sistema de arquivos, talvez queira ler esta pergunta sobre ServerFault para algumas tarefas e não tarefas: Armazenando um milhão de imagens no sistema de arquivos .

Ignore as pessoas que dizem: " Não armazene imagens / dados binários no banco de dados ", pois elas baseiam suas respostas em informações antigas (supondo que você armazenará os dados em uma coluna do tipo VarBinary). As preocupações de desempenho usando o SQL Server para armazenar imagens agora podem ser atenuadas usando o tipo de dados FILESTREAM no SQL Server 2008. Em essência, o tipo de dados FILESTREAM permite combinar a facilidade de armazenamento de dados no banco de dados com o desempenho obtido na veiculação arquivos de um repositório de arquivos NTFS.

Para citar o SQL Mag :

"O novo suporte FILESTREAM do SQL Server 2008 combina o benefício de acessar LOBs diretamente do sistema de arquivos NTFS com a integridade referencial e a facilidade de acesso oferecida pelo mecanismo de banco de dados relacional do SQL Server".

Para mais informações, leia este blog de Ravi S.Maniam no MSDN .

Embora eu não lide com o desafio de milhões de imagens, eu usaria o Amazon CloudFront. Todos os arquivos são armazenados em um bucket S3, mas são servidores através do sistema de entrega de conteúdo da Amazon. Eu não usaria o S3 sozinho.

Minha segunda opção seria o sistema de arquivos. Simples e fácil, o único problema é que, se todos esses arquivos terminarem em um diretório, a coisa toda falhará.

SQL para mim não seria uma opção para um sistema como este. Você não apenas será cobrado pela transferência de largura de banda, mas também pelo processamento da consulta - isso dependerá muito da hospedagem, mas presumo que você esteja usando um servidor dedicado ou, pelo menos, um vps no qual será cobrado para ciclos. Em seguida, o site inteiro ficará mais lento se ele usar o mesmo banco de dados que o servidor de imagem. Caso contrário, você adiciona toda essa complexidade de ter que gerenciar duas conexões com o banco de dados.

Os bancos de dados são projetados para dados / consistência e segurança transacionais.

Arquivos de mídia (imagens, áudio, vídeo) tendem a ser criados e talvez excluídos, mas muito raramente atualizados. Portanto, geralmente não há necessidade de mantê-los transacionalmente consistentes com outros dados e um banco de dados não oferece nenhum benefício real lá. O conteúdo do texto talvez seja um assunto diferente.

Contanto que você não tenha nenhum problema com o conceito de alguém puxando seu arquivo diretamente se tiver o URL do arquivo, um sistema de arquivos estará correto. Se você estava executando algo como uma biblioteca de fotos, na qual espera cobrar antes que as pessoas baixem o arquivo, isso provavelmente é uma questão diferente. Ou seja, depois que o usuário paga, ele pode obter um URL específico ou válido por apenas um curto período de tempo, e o aplicativo manipula URLs múltiplos ou temporários apontando para a mesma imagem. Isso ainda pode ser tratado pelo aplicativo e um sistema de arquivos, mas você acaba servindo a mídia por meio do aplicativo, e não como um download direto de arquivo (o que descartaria principalmente os benefícios do S3) e há menos diferença entre o banco de dados e o sistema de arquivos .