Maneira ideal para servir 70.000 arquivos estáticos (jpg)?

Question

Eu preciso atender cerca de 70.000 arquivos estáticos (jpg) usando o nginx. Devo despejar todos eles em um único diretório ou existe uma maneira melhor (eficiente)? Como os nomes dos arquivos são numéricos, considerei ter uma estrutura de diretórios como:

xxx / xxxx / xxx

O sistema operacional é o CentOS 5.1

    

Answer 1

Benchmark, benchmark, benchmark! Você provavelmente encontrará nenhuma diferença significativa entre as duas opções, o que significa que seu tempo é melhor gasto em outros problemas. Se você fizer benchmark e não encontrar nenhuma diferença real, escolha o esquema mais fácil - o que é fácil de codificar se apenas os programas tiverem que acessar os arquivos, ou o que é fácil para os humanos trabalharem se as pessoas precisarem trabalhar com os arquivos frequentemente. / p>

Quanto ao que é mais rápido, o tempo de pesquisa de diretório é, acredito, proporcional ao logaritmo do número de arquivos no diretório. Assim, cada uma das três pesquisas para a estrutura aninhada será mais rápida do que uma grande pesquisa, mas o total das três provavelmente será maior.

Mas não confie em mim, eu não tenho ideia do que estou fazendo! Meça o desempenho quando for importante!

    

Answer 2

isso realmente depende do sistema de arquivos que você está usando para armazenar os arquivos.

alguns sistemas de arquivos (como o ext2 e, em menor grau, o ext3) são terrivelmente lentos quando você tem milhares de arquivos em um diretório, então usar subdiretórios é uma boa idéia.

outros sistemas de arquivos, como XFS ou reiserfs (*), não abrandam com milhares de arquivos em um diretório, então não importa se você tem um grande diretório ou muitos subdiretórios menores.

(*) O reiserfs tem alguns recursos interessantes, mas é um brinquedo experimental que tem um histórico de falhas catastróficas. não use em nada nem remotamente importante.

    

Answer 3

Como outros já disseram, o hash de diretórios provavelmente será o mais ideal.

O que eu sugiro que você faça é tornar seus URIs independentes de qualquer esquema de diretório que você usar, usando o módulo de reescrita do nginx, por exemplo. map example.com/123456.jpg para /path/12/34/123456.jpg

Em seguida, se a sua estrutura de diretórios precisar ser alterada por motivos de desempenho, você poderá alterar isso sem alterar seus URIs publicados.

    

Answer 4

Fazer um hashing de diretório básico geralmente é uma boa ideia. Mesmo que seu sistema de arquivos lide bem com arquivos de 70k; Dizer que milhões de arquivos em um diretório se tornariam incontroláveis. Além disso - como o seu software de backup, como muitos arquivos em um diretório, etc etc.

Dito isto: Para obter replicação (redundância) e escalabilidade mais fácil considere armazenar os arquivos no MogileFS em vez de apenas no sistema de arquivos. Se os arquivos são pequenos e alguns arquivos são muito mais populares do que outros, considere usar o Varnish (varnish-cache.org) para servi-los muito rapidamente.

Outra ideia: use um CDN - eles são surpreendentemente baratos. Usamos um que custa basicamente o mesmo que pagamos por "largura de banda regular"; mesmo em baixo uso (10-20Mbit / seg).

    

Answer 5

Você pode colocar um cache de squid na frente do seu servidor nginx. O Squid pode manter as imagens populares na memória ou usar seu próprio layout de arquivo para consultas rápidas.

Para o Squid, o padrão é 16 diretórios de nível um e 256 de nível dois. Estes são padrões razoáveis para meus sistemas de arquivos.

Se você não usar um produto como o Squid e criar sua própria estrutura de arquivos, precisará criar um algoritmo hash razoável para seus arquivos. Se os nomes dos arquivos forem gerados aleatoriamente, isso é fácil e você pode usar o próprio nome do arquivo para dividir em blocos. Se todos os seus arquivos se parecerem com IMG_xxxx, você precisará usar os dígitos menos significativos ou dividir o nome do arquivo e dividir com base nesse número de hash.

    

Answer 6

Como outros já mencionaram, é necessário testar para ver qual layout funciona melhor para você para seu padrão de configuração e uso.

No entanto, você também pode querer olhar para o parâmetro open_file_cache dentro do nginx. Veja o link

    

Answer 7

Por todos os meios de referência e usar essa informação para ajudá-lo a tomar uma decisão, mas se fosse o meu sistema, eu também estaria dando alguma consideração à manutenção a longo prazo. Dependendo do que você precisa fazer, pode ser mais fácil gerenciar as coisas se houver uma estrutura de diretório em vez de tudo em um diretório.

    

Answer 8

Dividi-los em diretórios parece uma boa ideia. Basicamente (como você deve saber), o motivo dessa abordagem é que ter muitos arquivos em um diretório torna o índice do diretório enorme e faz com que o SO leve muito tempo para pesquisá-lo; Inversamente, ter muitos níveis de (in) direção (desculpe, mau trocadilho) significa fazer um monte de pesquisas de disco para cada arquivo.

Sugiro dividir os arquivos em um ou dois níveis de diretórios. Execute alguns testes para ver o que funciona melhor. Se houver várias imagens entre as 70.000 que são significativamente mais populares que as outras, tente colocar todas elas em um diretório para que o sistema operacional possa usar um índice de diretório em cache para elas. Ou, na verdade, você poderia até colocar as imagens populares no diretório raiz, assim:

images/
  021398012.jpg
  379284790.jpg
  ...
  000/
    000/
      000000000.jpg
      000000001.jpg
      ...
    001/
      ...
    002/
      ...

... espero que você veja o padrão. No Linux, você pode usar hard links para as imagens populares (mas não links simbólicos, que diminuem a eficiência do AFAIK).

Pense também em como as pessoas farão o download das imagens. Algum cliente individual vai solicitar apenas algumas imagens ou o conjunto completo? Como no último caso, faz sentido criar um arquivo TAR ou ZIP (ou possivelmente vários arquivos) com as imagens neles, já que a transferência de alguns arquivos grandes é mais eficiente do que muitos arquivos menores.

P.S. Eu meio que me empolguei na teoria, mas kquinn está certo, você realmente precisa fazer alguns experimentos para ver o que funciona melhor para você, e é muito possível que a diferença seja insignificante.

    

Answer 9

Acho uma boa ideia dividir os arquivos em uma hierarquia, sem nenhum outro motivo que, se você precisar fazer uma pausa e fazer um ls no diretório, levará menos tempo.

    

Answer 10

Eu não conheço o aboutext4, mas o arquivo ext2 não suporta tantos arquivos em um diretório, o reiserfs (reiser3) foi projetado para lidar com isso (um ls ainda será feio).

    

Answer 11

A organização dos arquivos tem mais a ver com o desempenho e a estabilidade do sistema de arquivos do que com o desempenho da entrega. Eu evitaria ext2 / ext3 e continuaria com xfs ou reiser.

Você realmente vai querer olhar para o cache. Quer seja o armazenamento em cache do servidor da Web ou um cache de terceiros, como verniz.

Como mencionado por kquinn, o benchmarking será o indicador real de ganhos / perdas de desempenho.

    

Answer 12

Valeria a pena para você despejar esses arquivos em um amazon S3 bucket e servi-los de lá?

Deixe que eles se preocupem com a otimização.