MongoDB
 sql >> Base de Dados >  >> NoSQL >> MongoDB

Armazenamento para milhões de imagens


Eu tenho, na minha vida, feito distribuição de vídeo com S3 (arquivos de nuvem Rackspace incluídos) e MongoDB.

A maioria das pessoas, sem uma segunda olhada, iria para o S3, mas descobri que ambos têm suas desvantagens. Um dos grandes problemas é que o S3 não é um CDN, na verdade é um armazenamento redundante dentro de uma região específica que não é replicado para outras regiões do S3, isso significa que você precisará usar algo como cloudfront em cima do S3 para pingar suas imagens para uma espécie de cache se você receber uma carga séria em seu site.

O S3 também possui outros recursos que o tornam menos CDN e mais um armazém de armazenamento. Dito isto, para arquivos acessados ​​com pouca frequência, o S3 é incrivelmente rápido.

Essa camada dupla, é claro, cria complexidades como manutenção. Não apenas isso, mas um CDN funcionará em TTLs e, embora muitos CDNs hoje em dia tenham recursos de limpeza de borda, eles ainda não são uma maneira 100% segura de garantir que seus arquivos não sejam acessíveis.

Portanto, devido à configuração e aos acessos (possíveis acessos de arquivos que também devem ser excluídos), isso pode ficar bastante caro rapidamente.

É aqui que o MongoDB poderia ganhar. O MongoDB pode, dependendo do seu cenário, realmente ser mais barato aqui devido ao fato de que você pode usar um monte de microinstâncias na AWS para realmente manter suas informações, adicionando reserva de instância local a essas instâncias (barato sujo) e tudo o que você precisa é um grande disco em uma única máquina.

Inferno, você pode até usar o S3 para armazenar as imagens e depois o MongoDB como um substituto do cloudfront.

Quando você deseja pingar imagens para diferentes regiões, basta criar algumas instâncias pontuais nessa região de destino e fazer com que o MongoDB replique seus dados. Você também pode fazer algumas coisas legais com a replicação para garantir que apenas os arquivos acessados ​​com frequência dessa região sejam colocados nessa região.

Então eu não jogaria fora o MongoDB (ou mesmo Cassandra), mas faria um teste de meios entre os dois.

Editar


Como uma nota adicional sobre os preços do S3, se você armazenar seus arquivos em RR (redundância reduzida), o preço será reduzido pela metade (aproximadamente), o que torna o S3 muito barato, no entanto, você ainda tem o problema de que o S3 não é um CDN.

Edição adicional


Como eu realmente continuei com a resposta de @cirrus, vou reavaliar sua pergunta, que foi respondida acima.

Como exemplo, o Youtube realmente armazena todas as suas imagens em computadores únicos que são então distribuídos, para que eles possam gerenciar facilmente 200 milhões de miniaturas e... bem... muitas visualizações todos os dias facilmente a partir do sistema de arquivos. Então, acho que sua preocupação com o sistema de arquivos é superestimada.

Quanto a qual banco de dados é melhor... não sei, isso se resume ao seu teste.

Quero dizer, a resposta para o seu problema depende do seu cenário, do seu orçamento, do seu hardware e dos seus recursos, ou seja, se você tiver servidores da AWS, essa seria uma resposta totalmente diferente dos servidores dedicados internos.