Servir grande número de pequenas imagens no ext4

2

Eu li alguma questão semelhante, mas ainda tenho alguns confusos sobre a minha situação.

Meu site permite que o usuário envie um grande número de imagens grandes (digitalizar páginas do livro). Meu servidor irá organizar automaticamente e salvar essas imagens. Assim, cada página se tornará 10 milhares de pequenos ladrilhadores (cada imagem tem 128px * 128px, ocupa 2k de espaço). Eu tenho cerca de 100GB de imagens, e agora elas já preenchem toda a tabela de inode.

Aqui está um par do meu pensamento e compreensão, por favor, corrija-me se eu estiver errado.

  1. mysql blob

    de cabeça: não precisa mais se preocupar com inode / estrutura de diretórios.

    desvantagem: exibição de imagem lenta e pode tornar o banco de dados inteiro mais lento

  2. sistema de arquivos

    de cabeça: veiculação de imagem mais rápida

    desvantagem: velocidade de backup lenta, design de diretório extra, precisa de tamanho inode grande (isso também significa que eu tenho que reformatar meu disco de servidor)

  3. mongoDB BinData com base64 (não estou familiarizado com isso, mas parece ser uma boa opção)

  4. Amazon S3

    de cabeça: eles cuidam de tudo

    desvantagem: precisa causar dinheiro e perdeu o controle total dessas imagens.

    (ATUALIZAÇÃO: Posso não permitir o uso de terceiros, mas ainda vou viver isso aqui, pois pode ser uma boa solução para outras pessoas, de acordo com a sugestão do @Niels.)

  5. Outra ótima solução mágica.

Então, eu me pergunto qual é a melhor na minha situação e por quê. Obrigado pela ajuda

    
por xzhang 17.04.2013 / 00:46

2 respostas

1

Eu definitivamente escolheria o S3, a menos que você tenha milhares de usuários muito ativos ... E mesmo que você faça algumas doações ou publicidade, deve cobrir o custo. O armazenamento do S3 é muito, muito barato comparado ao seu próprio servidor. Armazenar 100 GB de dados custaria cerca de 9USD por mês, com alto nível de redundância. Isso significa espelhar para pelo menos 4 locais de armazenamento, com durabilidade garantida transacional de 99,9999%, por um custo que não lhe custaria, de forma realista, um único servidor em 3 anos. O tráfego pode ser caro, mas você está pagando isso com todos os provedores de colocações, então não há diferença real a menos que você consiga grandes números.

O S3 é internamente um dicionário de strings altamente otimizado, capaz de armazenar milhões, se não bilhões, de arquivos relacionados.

Honestamente, salve-se da frustração e vá embora com todos os problemas de backup, redundância e administração do servidor por um pequeno preço, então foque em manter o desempenho do site ao redor. Muito mais divertido também.

Além disso, se o uso da largura de banda for realmente astronômico, considere usar seu servidor da Web como um servidor 'de borda'. Na maioria dos cenários de armazenamento em massa, 1% do conteúdo é solicitado 99% do tempo (pense nas fotos do Facebook). Alguns scripts que espelham localmente 1 GB das imagens solicitadas recentemente e são eliminados pelo último acesso, devem ser fáceis de fazer e manter os custos de largura de banda do S3 no nível gratuito, provavelmente.

    
por 17.04.2013 / 01:06
1

Tanto quanto eu saiba, não há como ajustar o número de inodes em um sistema de arquivos existente.

Se você puder recriar o sistema de arquivos, poderá usar a opção -N para especificar um número maior de inodes para o novo FS

    
por 17.04.2013 / 06:29