Como você lida com lotes de pequenos arquivos?

https://stackoverflow.com/questions/115882

02-07-2019
|

Pergunta

Um produto que eu estou trabalhando em coleta vários milhares de leituras por dia e os armazena como 64k arquivos binários em uma partição NTFS (Windows XP). Depois de um ano em produção há mais de 300 mil arquivos em um único diretório eo número continua crescendo. Isso fez com que o acesso ao pai / ancestral diretórios do Windows Explorer muito demorado.

Eu tentei desligar o serviço de indexação, mas isso não fez diferença. Eu também contemplado mover o conteúdo do arquivo em um banco de dados / arquivos zip / tarballs mas é benéfico para nós para acessar os arquivos individualmente; Basicamente, os arquivos ainda são necessários para fins de pesquisa e os pesquisadores não estão dispostos a lidar com qualquer outra coisa.

Existe uma maneira de otimizar NTFS ou Windows para que ele possa trabalhar com todos estes pequenos arquivos?

Solução

desempenho NTFS severamente degrada após 10.000 arquivos em um diretório. O que você faz é criar um nível adicional na hierarquia do diretório, com cada subdiretório ter 10.000 arquivos.

Por que vale a pena, esta é a abordagem que as pessoas SVN levou em versão 1.5 . Eles usaram 1.000 arquivos como o limite padrão.

Outras dicas

NTFS realmente irá executar bem com muitos mais de 10.000 arquivos em um diretório, desde que você diga a ele para parar de criar nomes de arquivos alternativos compatíveis com 16 bits plataformas Windows. Por padrão NTFS cria automaticamente um nome de arquivo '8 DOT 3' para cada arquivo que é criado. Isso se torna um problema quando há muitos arquivos em um diretório porque o Windows olha para os arquivos no diretório para garantir que o nome que eles estão criando não estiver em uso. Você pode desativar '8 DOT 3' nomear, definindo o valor do Registro NtfsDisable8dot3NameCreation como 1. O valor é encontrado no caminho do Registro HKEY_LOCAL_MACHINE \ System \ CurrentControlSet \ Control \ FileSystem. É seguro fazer essa alteração como '8 DOT 3' arquivos de nomes só são obrigados por programas escritos para versões muito antigas do Windows.

A reinicialização é necessária antes que esta configuração terá efeito.

O problema de desempenho está sendo causada pela enorme quantidade de arquivos em um único diretório: uma vez que você eliminar esse, você deve ser fino. Este não é um problema específico do NTFS:. Na verdade, ele é comumente encontrado com arquivos de correio do usuário home / em grandes sistemas UNIX

Uma maneira óbvia para resolver este problema, está se movendo os arquivos em pastas com um nome baseado no nome do arquivo. Supondo que todos os seus arquivos têm nomes de comprimento semelhante, por exemplo de arquivo ABCDEFGHI.db, ABCEFGHIJ.db, etc, criar uma estrutura de diretórios como esta:

ABC\
    DEF\
        ABCDEFGHI.db
    EFG\
        ABCEFGHIJ.db

Usando essa estrutura, você pode localizar rapidamente um arquivo com base em seu nome. Se os nomes de arquivo têm comprimentos variáveis, escolher um comprimento máximo, e zeros preceder (ou qualquer outro caractere), a fim de determinar o diretório do arquivo pertence.

Eu tenho visto grandes melhorias no passado de dividir os arquivos acima em uma hierarquia aninhada de diretórios, por exemplo, em primeiro lugar, em seguida, segunda letra do nome de arquivo; em seguida, cada diretório não contém um número excessivo de arquivos. Manipulando todo o banco de dados ainda é lento, no entanto.

Você pode tentar usar algo como sólido do sistema de arquivos.

Isto dá-lhe um sistema de arquivos virtual que aplicações pode montar como se fosse um disco físico. Seu aplicativo vê lotes de arquivos pequenos, mas apenas um arquivo senta em seu disco rígido.

http://www.eldos.com/solfsdrv/

Se você pode calcular nomes de arquivos, você pode ser capaz de classificá-los em pastas por data, para que cada pasta só tem arquivos de uma data específica. Você também pode querer criar mês e ano hierarquias.

Além disso, você poderia mover arquivos mais velhos do que digamos, um ano, para um local diferente (mas ainda acessível)?

Finalmente, e mais uma vez, isto requer que você seja capaz de nomes de calcular, você verá que acessar diretamente um arquivo é muito mais rápido do que tentar abri-lo via explorador. Por exemplo, dizendo
notepad.exe "P: \ ath \ a \ o \ filen.ame"
a partir da linha de comando deve ser realmente muito rápido, supondo que você sabe o caminho do arquivo que você precisa sem ter que obter uma listagem de diretório.

Um truque comum é simplesmente criar um punhado de subdiretórios e dividir os arquivos.

Por exemplo, Doxygen, um programa de documentação de código automatizado que pode produzir toneladas de páginas html, tem uma opção para a criação de uma hierarquia de diretórios de profundidade de dois níveis. Os arquivos são distribuídos uniformemente entre os diretórios de fundo.

Tendo centenas de milhares de arquivos em um único diretório vai realmente prejudicar NTFS, e não há realmente muito que você pode fazer sobre isso. Você deveria reconsiderar armazenar os dados em um formato mais prático, como uma grande tarball ou em um banco de dados.

Se você realmente precisa de um arquivo separado para cada leitura, você deve classificá-los em vários sub-diretórios em vez de ter todos eles no mesmo diretório. Você pode fazer isso através da criação de uma hierarquia de diretórios e colocar os arquivos nos mais diferentes, dependendo do nome do arquivo. Desta forma, você ainda pode armazenar e carregar seus arquivos sabendo apenas o nome do arquivo.

O método que usamos é tomar as últimas letras do nome do arquivo, revertendo-os e criando um diretórios carta a partir daí. Considere os seguintes arquivos por exemplo:

1.xml
24.xml
12331.xml
2304252.xml

você pode classificá-los em diretórios como assim:

data/1.xml
data/24.xml
data/1/3/3/12331.xml
data/2/5/2/4/0/2304252.xml

Este esquema vai garantir que você nunca vai ter mais de 100 arquivos em cada diretório.

Eu executar para esse problema muitas vezes no passado. Nós tentamos armazenar por data, fechando arquivos abaixo a data para que você não tem um monte de arquivos pequenos, etc. Todos eles foram bandaids para o verdadeiro problema de armazenar os dados como lotes de pequenos arquivos em NTFS.

Você pode ir para ZFS ou algum outro sistema de arquivos que lida com arquivos pequenos melhor, mas ainda parar e perguntar se você precisa para armazenar os arquivos pequenos.

No nosso caso, acabou indo para um sistema foram todos os pequenos arquivos de uma determinada data para foram anexados em um tipo TAR da moda com delimitadores simples para analisá-los. Os arquivos do disco passou de 1,2 milhões para menos de alguns milhares. Eles realmente carregado mais rápido porque NTFS não consegue lidar com os pequenos arquivos muito bem, e a unidade era mais capaz de armazenar em cache um arquivo de 1 MB de qualquer maneira. Em nosso caso, o acesso e tempo de análise para encontrar a parte direita do arquivo era mínimo comparado ao armazenamento e manutenção de arquivos armazenados real.

Além de colocar os arquivos em sub-diretórios ..

Pessoalmente, gostaria de desenvolver um aplicativo que mantém a interface para essa pasta o mesmo, ou seja, todos os ficheiros são apresentados como sendo arquivos individuais. Então, no fundo aplicação realmente leva esses arquivos e combiná-los em um arquivos maiores (e desde que os tamanhos são sempre 64k recebendo os dados que você precisa deve ser relativamente fácil) Para se livrar da bagunça que você tem.

Então, você ainda pode tornar mais fácil para eles para acessar os arquivos que eles querem, mas também permite que você tenha mais controle como tudo está estruturado.

Considere a empurrá-los para outro servidor que usa um amigável sistema de arquivos para grandes quantidades de arquivos pequenos (Solaris w / ZFS, por exemplo)?

Se houver qualquer sentido, categórica, aspectos dos dados que você poderia ninho los em uma árvore de diretórios. Eu acredito que a desaceleração é devido ao número de arquivos em um diretório, não o número absoluto de si arquivos.

O agrupamento mais óbvio, geral é por data, e lhe dá uma estrutura de aninhamento de três camadas (ano, mês, dia) com um relativamente seguro ligado para o número de arquivos em cada diretório folha (1-3k).

Mesmo se você é capaz de melhorar o desempenho do navegador do sistema de arquivos / arquivo, parece que este é um problema que você vai correr em em mais 2 anos ou 3 anos ... apenas olhando para uma lista de arquivos 0.3-1mil é vai incorrer em um custo, por isso pode ser melhor a longo prazo para encontrar maneiras para procurar somente em subconjuntos menores dos arquivos.

Usando ferramentas como 'encontrar' (sob cygwin, ou mingw) pode fazer a presença da árvore subdiretório um não-problema quando se navega arquivos.

Mudar o nome da pasta de cada dia com um carimbo de tempo.

Se o pedido for salvar os arquivos em C:. \ Leituras, em seguida, criar uma tarefa agendada para renomear leitura à meia-noite e criar uma nova pasta vazia

Em seguida, você receberá uma pasta para cada dia, cada um contendo vários milhares de arquivos.

Você pode estender o método também agrupar por mês. Por exemplo, C: \ Leitura c tornar-se:. \ Archive \ setembro \ 22

Você tem que ter cuidado com o seu timing para garantir que você não está tentando mudar o nome da pasta enquanto o produto está salvando a ele.

Para criar uma estrutura de pastas que será ampliado para um grande número desconhecido de arquivos, eu como o seguinte sistema:

Dividir o nome do arquivo em pedaços de comprimento fixo, e em seguida, criar pastas aninhadas para cada peça, exceto a última.

A vantagem deste sistema é que a profundidade da estrutura da pasta só cresce tão profundo quanto o comprimento do nome do arquivo. Portanto, se seus arquivos são gerados automaticamente em uma sequência numérica, a estrutura é apenas profunda é que ele precisa ser.

12.jpg -> 12.jpg
123.jpg -> 12\123.jpg
123456.jpg -> 12\34\123456.jpg

Esta abordagem significa que pastas contêm arquivos e sub-pastas, mas eu acho que é um comércio razoável off.

E aqui está um bela PowerShell one-liner para você ir!

$s = '123456'

-join  (( $s -replace '(..)(?!$)', '$1\' -replace '[^\\]*$','' ), $s )

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow