Milhões de (pequenos) arquivos de texto em uma pasta

Isso é perigosamente próximo a uma pergunta/resposta baseada em opinião, mas tentarei fornecer alguns fatos com minhas opiniões.

1. Se você tiver um número muito grande de arquivos em uma pasta, qualquer operação baseada em shell que tente enumerá-los (por exemplo mv * /somewhere/else, ) pode não conseguir expandir o curinga com êxito ou o resultado pode ser muito grande para ser usado.
2. lslevará mais tempo para enumerar um número muito grande de arquivos do que um pequeno número de arquivos.
3. O sistema de arquivos será capaz de lidar com milhões de arquivos em um único diretório, mas as pessoas provavelmente terão dificuldades.

Uma recomendação é dividir o nome do arquivo em dois, três ou quatro blocos de caracteres e usá-los como subdiretórios. Por exemplo, somefilename.txtpode ser armazenado como som/efi/somefilename.txt. Se você estiver usando nomes numéricos, divida da direita para a esquerda em vez da esquerda para a direita para que haja uma distribuição mais uniforme. Por exemplo 12345.txt, pode ser armazenado como 345/12/12345.txt.

Você pode usar o equivalente zip -j zipfile.zip path1/file1 path2/file2 ...a para evitar a inclusão de caminhos de subdiretórios intermediários no arquivo ZIP.

Se você estiver servindo esses arquivos de um servidor da Web (não tenho certeza se isso é relevante), é trivial ocultar essa estrutura em favor de um diretório virtual com regras de reescrita no Apache2. Eu diria que o mesmo é verdade para o Nginx.

O lscomando, ou mesmo TAB-completion ou expansão curinga pelo shell, normalmente apresentará seus resultados em ordem alfanumérica. Isso requer a leitura de toda a lista de diretórios e sua classificação. Com dez milhões de arquivos em um único diretório, essa operação de classificação levará um tempo não desprezível.

Se você puder resistir ao desejo de completar TAB e, por exemplo, escrever os nomes dos arquivos a serem compactados por completo, não haverá problemas.

Outro problema com curingas pode ser a expansão do curinga, possivelmente produzindo mais nomes de arquivos do que cabem em uma linha de comando de comprimento máximo. O comprimento máximo típico da linha de comando será mais do que adequado para a maioria das situações, mas quando estamos falando de milhões de arquivos em um único diretório, isso não é mais uma suposição segura. Quando um comprimento máximo da linha de comando é excedido na expansão curinga, a maioria dos shells simplesmente falhará em toda a linha de comando sem executá-la.

Isso pode ser resolvido fazendo suas operações curinga usando o findcomando:

find <directory> -name '<wildcard expression>' -exec <command> {} \+

ou uma sintaxe semelhante sempre que possível. O find ... -exec ... \+levará automaticamente em consideração o comprimento máximo da linha de comando e executará o comando quantas vezes for necessário, ajustando a quantidade máxima de nomes de arquivo a cada linha de comando.

Eu administro um site que lida com um banco de dados para filmes, TV e videogames. Para cada um deles, existem várias imagens com TV contendo dezenas de imagens por programa (ou seja, instantâneos de episódios, etc.).

Acaba havendo muitos arquivos de imagem. Em algum lugar na faixa de mais de 250.000. Todos eles são armazenados em um dispositivo de armazenamento de bloco montado, onde o tempo de acesso é razoável.

Minha primeira tentativa de armazenar as imagens foi em uma única pasta como/mnt/images/UUID.jpg

Encontrei os seguintes desafios.

• lsatravés de um terminal remoto iria simplesmente travar. O processo iria zumbi e CTRL+Cnão iria quebrá-lo.
• antes de chegar a esse ponto, qualquer lscomando preencheria rapidamente o buffer de saída e CTRL+Cnão interromperia a rolagem sem fim.
• A compactação de 250.000 arquivos de uma única pasta levou cerca de 2 horas. Você deve executar o comando zip desanexado do terminal, caso contrário, qualquer interrupção na conexão significa que você terá que começar de novo.
• Eu não arriscaria tentar usar o arquivo zip no Windows.
• A pasta rapidamente se tornou uma zona proibida para humanos .

Acabei tendo que armazenar os arquivos em subpastas usando o tempo de criação para criar o caminho. Tal como /mnt/images/YYYY/MM/DD/UUID.jpg. Isso resolveu todos os problemas acima e me permitiu criar arquivos zip direcionados a uma data.

Se o único identificador de um arquivo que você possui for um número numérico, esses números tendem a ser executados em sequência. Por que não agrupá-los por 100000e .100001000

Por exemplo, se você tiver um arquivo chamado 384295.txt, o caminho seria:

/mnt/file/300000/80000/4000/295.txt

Se você souber, chegará a alguns milhões. Use 0prefixos para 1.000.000

/mnt/file/000000/300000/80000/4000/295.txt

Em primeiro lugar: evite que 'ls' seja classificado com 'ls -U', talvez atualize seu ~/bashrc para ter 'alias ls="ls -U"' ou similar.

Para o seu grande conjunto de arquivos, você pode tentar desta forma:

• criar um conjunto de arquivos de teste

• veja se muitos nomes de arquivos causam problemas

• use xargs parmeter-batching e o comportamento do zip (padrão) de adicionar arquivos a um zip para evitar problemas.

Isso funcionou bem:

# create ~ 100k files
seq 1 99999 | sed "s/\(.*\)/a_somewhat_long_filename_as_a_prefix_to_exercise_zip_parameter_processing_\1.txt/" | xargs touch
# see if zip can handle such a list of names
zip -q /tmp/bar.zip ./*
    bash: /usr/bin/zip: Argument list too long
# use xargs to batch sets of filenames to zip
find . -type f | xargs zip -q /tmp/foo.zip
l /tmp/foo.zip
    28692 -rw-r--r-- 1 jmullee jmullee 29377592 2017-12-16 20:12 /tmp/foo.zip

Escreva o arquivo de texto do web scrape (não deve ser afetado pelo número de arquivos na pasta).

Para criar um novo arquivo, é necessário verificar o arquivo do diretório procurando por espaço vazio suficiente para a nova entrada do diretório. Se nenhum espaço localizado for grande o suficiente para armazenar a nova entrada de diretório, ele será colocado no final do arquivo de diretório. À medida que o número de arquivos em um diretório aumenta, o tempo para varrer o diretório também aumenta.

Contanto que os arquivos do diretório permaneçam no cache do sistema, o impacto no desempenho não será ruim, mas se os dados forem liberados, a leitura do arquivo do diretório (geralmente altamente fragmentado) do disco pode consumir um pouco de tempo. Um SSD melhora isso, mas para um diretório com milhões de arquivos, ainda pode haver um impacto perceptível no desempenho.

Compacte os arquivos selecionados, fornecidos pela lista de nomes de arquivos.

Isso provavelmente também exigirá tempo adicional em um diretório com milhões de arquivos. Em um sistema de arquivos com entradas de diretório com hash (como EXT4), essa diferença é mínima.

armazenar até dez milhões de arquivos em uma pasta afetará o desempenho das operações acima, ou o desempenho geral do sistema, de forma diferente de criar uma árvore de subpastas para os arquivos residirem?

Uma árvore de subpastas não tem nenhuma das desvantagens de desempenho acima. Além disso, se o sistema de arquivos subjacente for alterado para não ter nomes de arquivos com hash, a metodologia da árvore ainda funcionará bem.