Eu gerencio um aplicativo que contém um armazenamento de arquivos no qual todos os arquivos são armazenados com os nomes dos arquivos iguais às suas somas md5. Todos os arquivos são armazenados em um diretório. Atualmente existem milhares, mas logo devem ser milhões de arquivos no servidor. O servidor atual está executando o Ubuntu 11.10 em um sistema de arquivos ext4.
Alguém me disse que não é aconselhável colocar muitos arquivos em um diretório, pois isso aumentaria significativamente o tempo de pesquisa e a confiabilidade (ele tinha uma história sobre os arquivos máximos que um único diretório poderia apontar, resultando em um grande link Lista). Em vez disso, ele sugeriu criar subdiretórios com, e. substrings do nome do arquivo. No entanto, isso tornará algumas coisas na minha aplicação muito mais complicadas.
Isso ainda é verdade ou os sistemas de arquivos modernos (por exemplo, ext4) têm maneiras mais eficientes de lidar com isso e escalar naturalmente? A Wikipedia tem alguns detalhes sobre sistemas de arquivos, mas na verdade não diz nada sobre arquivos máximos por diretório ou tempos de pesquisa.
Os sistemas de arquivos ext3 e posteriores suportam a indexação de diretório B-tree com hash . Isso se adapta muito bem, desde que as únicas operações que você faz sejam adicionar, excluir e acessar pelo nome. No entanto, eu ainda recomendaria quebrar os diretórios. Caso contrário, você cria uma armadilha perigosa para ferramentas ( updatedb , ls , du e assim por diante) que executam outras operações em diretórios que podem explodir se o diretório tiver muitas entradas.
O núcleo do problema é cavar através do diretório inode para o arquivo que você deseja. Alguns sistemas de arquivos fazem isso melhor que outros. Alguns escalam perto dos bilhões, mas se você só tem ... 20K arquivos chegando a esses arquivos são marcadamente mais rápidos. Além disso, grandes contagens de arquivos criam problemas para determinadas ferramentas e podem fazer com que o backup / restauração seja um problema muito mais difícil.
Por acaso, encontrei exatamente o mesmo problema em nosso próprio desenvolvimento (md5sum como nome de arquivo, dimensionamento do mesmo). O que eu recomendei aos nossos desenvolvedores é cortar a corda em pedaços. Eles foram com grupos de 4, mas no sistema de arquivos em que estávamos na época, mesmo que muitos se mostraram problemáticos do ponto de vista de desempenho, eles acabaram dividindo um grupo de 3 para os primeiros 6 trios e deixando o resto como o nome do arquivo no diretório do terminal.
Grupo de 4: 4976/d70b/180c/6142/c617/d0c8/9d0b/bd2b.txt
Grupo de 3: 497/6d7/0b1/80c/614/2c6/17d0c89d0bbd2b.txt
Isso tem a vantagem de manter os tamanhos de diretório pequenos e, como o MD5sum é bastante aleatório, ele cria árvores de diretórios balanceadas. É improvável que esse último diretório obtenha mais do que alguns arquivos. E não foi tão difícil trabalhar em nosso código. Trabalhamos com projetos de vários milhões de arquivos, então o dimensionamento foi muito importante para nós.
Sistemas de arquivos modernos lidam muito bem com diretórios muito grandes, até mesmo para milhões de arquivos. Mas as ferramentas convencionais não. Por exemplo, listar um diretório grande como "ls" levaria muito tempo, já que ele normalmente leria o diretório inteiro e o classificaria (embora você possa usar ls -f para evitar a classificação). Não iria começar a mostrar arquivos até que todos sejam lidos. A divisão dos nomes ajuda em alguns casos, mas não em todos (por exemplo, a replicação rsync ainda pode precisar coletar a árvore inteira de nomes).
Posso sugerir o uso de um banco de dados SQL? Isso provavelmente transformaria essa fraqueza percebida em sua aplicação em uma força.
Tags ext4 linux filesystems ubuntu