Temos centenas de milhares de imagens jpg em uma estrutura de pastas do Windows como esta, mas é realmente difícil interagir e trabalhar com elas de maneira rápida (listar leva tempo, copiar leva tempo, etc.). Aqui está a estrutura:
images/
1/
10001/
10001-a.jpg
10001-b.jpg
...
10001-j.jpg (10 images in each XXXXX folder)
10002/
10003/
...
19999/
2/
20001/
20002/
20003/
...
29999/
3/
4/
5/
6/
7/
8/
9/
Agora, navegar nessas imagens é um pouco lento porque há aprox. 10.000 pastas em cada pasta X e listá-las simplesmente leva tempo.
Existe uma maneira melhor de organizar as imagens com menos subpastas/itens? Mudar a estrutura para isso teria algum efeito?
images/
1/
0/
0/
0/
0/
1/
2/
3/
4/
5/
6/
7/
8/
9/
10000/ (image folder, same as path)
10000-a.jpg
10000-b.jpg
...
10000-j.jpg (10 images in each image folder)
1/
2/
3/
4/
5/
6/
7/
8/
9/
1/
2/
3/
4/
5/
6/
7/
8/
9/
1/
2/
3/
4/
5/
6/
7/
8/
9/
2/
3/
4/
5/
6/
7/
8/
9/
Assim, localizar a imagem 48617-c.jpg seria igual ao caminho 4/8/6/1/7/48617/48617-c.jpg.
O motivo de ter uma pasta separada com o número de caminho completo 48617 é simplificar a cópia de um lote completo de 10 imagens (copiando a pasta inteira).
Agora... nenhuma pasta terá mais de 11 subpastas imediatas, mas haverá muitas pastas extras de um dígito para fins de separação. Essa configuração aceleraria a navegação e a interação com vários usuários adicionando/copiando/excluindo/etc imagens?
Responder1
O Windows é um pouco especial quando se trata de layout de pastas com milhões de arquivos. Principalmente imagens, já que o Windows Explorer as trata de maneira especial. Dito isto, existem algumas diretrizes a serem seguidas para evitar que as coisas fiquemtambémfora de controle:
- Se você pretende navegar na estrutura de diretórios do Windows Explorer por qualquer motivo, mantenha-a abaixo de 10.000 entradas em um diretório (arquivos e subdiretórios).
- Se você estiver interagindo com ele apenas a partir de utilitários CLI ou código, o limite de 10K é muito mais flexível.
- Não crie muitos subdiretórios, cada diretório que você cria é outra operação discreta que uma cópia deve fazer ao copiar.
- Se cada arquivo criar N diretórios, o número deobjetos do sistema de arquivoscriado por esse arquivo será 1+N, o que dimensiona linearmente seus tempos de cópia.
- Uma árvore curta e exponencial (ou seja, três camadas de diretórios, cada uma com 256 subdiretórios) pode escalar incrivelmente antes de atingir o limite de 10K/por diretório.
- Se você estiver acessando-o com código, opte por aberturas diretas em vez de analisar listagens de diretórios antes de abrir. Uma falha fopen() seguida por uma varredura de diretório é mais rápida do que uma varredura de diretório seguida por uma fopen() garantida em muitos casos.
Ressalvas:
- A contagem de arquivos é imutável, mas a contagem de diretórios depende de você. A SOMA dessas duas contagens afeta a rapidez com que as operações de cópia ocorrem.
- Tente, se possível, não navegar com o Windows Explorer, a menos que seja necessário. Ele não lida bem com diretórios grandes e não há muito que você possa fazer a respeito.
Responder2
Há muitas informações boas sobre matemática na minha resposta deComo a complexidade do diretório influencia os i-nodes?
Dito isto, diferentes sistemas de arquivos lidam com um grande número de arquivos em diretórios de várias maneiras. Alguns aceitam 10.000 entradas, outros cedem. Como regra prática rapidamente inventada, 1.000 é provavelmente um bom limite de meta se você tiver controle de design. As entradas em um diretório geralmente são armazenadas como uma espécie de lista e cabe ao aplicativo de leitura classificar sua ordem. Por exemplo, lsno mundo Unix, ele lê as coisas na memória em ordem de diretório e depois as imprime em ordem alfabética.
Dê uma olhada na matemática da outra pergunta. Considere também o que sysadmin1338 disse sobre o comportamento do Explorer de maneira diferente. O Explorer criará miniaturas de qualquer coisa que reconheça como imagem e depois lerá as miniaturas para exibi-las. É muita E/S de disco para examinar um diretório repleto de arquivos.
Responder3
Dependendo se você tem recursos para desenvolver tal sistema, este parece ser um bom candidato para um banco de dados SQL Server usandoFILESTREAMarmazenamento para os arquivos. Dessa forma, você deixa a organização dos diretórios para o SQL Server e só precisa se preocupar em como gerenciar os dados em si. Você provavelmente poderia usar o SQL Express, pois os dados do FILESTREAM não são levados em consideração ao calcular o tamanho do banco de dados.