Teste de gravação em disco

Question

Estou escrevendo um aplicativo para armazenar muitas imagens (tamanho < 5MB) em um sistema de arquivos ext3, isso é o que tenho por enquanto. Depois de algumas pesquisas aqui no serverfault eu decidi por uma estrutura de diretórios como esta:

000/000/000000001.jpg
...
236/519/236519107.jpg

Essa estrutura permitirá que eu salve até 1'000'000'000 imagens, pois armazenarei um máximo de 1'000 imagens em cada folha.

Eu o criei, do ponto de vista teórico parece ok para mim (embora eu não tenha experiência nisso), mas eu quero descobrir o que acontecerá quando houver diretórios cheios de arquivos lá dentro.

Uma pergunta sobre como criar essa estrutura: é melhor criar tudo de uma vez (leva aproximadamente 50 minutos no meu pc) ou devo criar diretórios conforme necessário? Do ponto de vista do desenvolvedor, eu acho que a primeira opção é melhor (sem tempo extra de espera para o usuário), mas do ponto de vista do administrador de sistema, tudo bem?

Eu pensei que poderia fazer como se o sistema de arquivos já estivesse sob o aplicativo em execução, criarei um script que salvará as imagens o mais rápido possível, monitorando as coisas da seguinte forma:

• Quanto tempo leva para uma imagem ser salva quando não há pouco ou pouco espaço?
• como isso muda quando o espaço começa a ser usado?
• quanto tempo leva para uma imagem ser lida de uma folha aleatória? Isso muda muito quando há muitos arquivos?

O lançamento deste comando

sync; echo 3 | sudo tee /proc/sys/vm/drop_caches

tem algum sentido? Esta é a única coisa que eu tenho que fazer para ter um começo limpo se eu quiser começar tudo de novo com meus testes?

Você tem alguma sugestão ou correção?

EDIT: Eu fiz a escolha do sistema de arquivos, em oposição ao banco de dados, por causa dessas duas questões:

• Armazenando um milhão de imagens no sistema de arquivos
• link

Answer 1

Pehrs levanta um ponto muito bom sobre sistemas de arquivos com muitos arquivos. Quando chega a hora de fazer o backup desse sistema de arquivos, leva muito tempo. A passagem de arquivos é uma das maiores perdas de tempo durante um processo de backup, ao longo de todas as solicitações de abertura de arquivos / fechamento de arquivos. A questão, " quanto tempo leva para uma imagem ser salva quando não há ou pouco espaço usado? " sugere que esses arquivos serão bem pequenos, então um sistema de arquivos deste tipo é quase texto -book para cenários de backup de pior caso (um caso é pior: todos esses arquivos em um único diretório).

Compare isso com um banco de dados verdadeiro, em que descarregar o banco de dados no backup é uma operação muito rápida e eficiente. Sim, esse banco de dados pode ser muito grande, mas vai fazer backup muito mais rápido, e pode até servir dados mais rapidamente à medida que a contagem de arquivos cresce. Ele pode depender de qual DB você usa e de como ele é bem gerenciado, mas, geralmente, usar um armazenamento de banco de dados em vez de um armazenamento de FS nesse caso fornecerá melhor resiliência a desastres.

Se um DB não é uma opção, então sim, pré-criar a estrutura de diretórios é sua melhor aposta. O que também ajudará é balancear a carga de criações de arquivos em toda a estrutura e não apenas ir até / 000/000 / ser preenchido antes de passar para / 000/001 /. Isso deve garantir que as contagens de arquivos por diretório permaneçam baixas por algum tempo.

    

Answer 2

Antes de mais nada, tenha cuidado com as limitações do sistema de arquivos. Você nunca armazenará mais de 2 ^ 32 arquivos em um sistema de arquivos EXT3 vanilla, pois há um limite no número máximo de inodes (verifique df -i). Além disso, existem limites máximos de tamanho de FS e tal a considerar.

Em segundo lugar: Você realmente precisa ter os arquivos no sistema de arquivos? Dependendo de como os arquivos são acessados, você pode perceber que obtém um desempenho melhor (e muito mais previsível) colocando os arquivos em um banco de dados. Além disso, os bancos de dados são muito mais fáceis de manipular, fazer backup, mover, etc. Qualquer design de aplicativo que envolva milhões de arquivos é falho e voltará a incomodá-lo no futuro.

    

Answer 3

Não crie todos na inicialização.

Crie os dirs de nível 1k, se quiser, mas além disso, faça-os sob demanda. Caso contrário, criá-los todos irá ingerir vários inodes do seu sistema de arquivos que provavelmente nunca serão usados.

Considere: 1 inode é consumido por diretório criado (permissões de retenção de inodes e informações de propriedade, para arquivos e diretórios). Portanto, os diretórios do nível superior 1000 são ... 1000 inodes. O próximo nível abaixo é de 1000 * 1000 ou 1000000 inodes. Um milhão, que mesmo nos grandes discos de hoje é uma quantia não desprezível. Se você preencher uma unidade de 1TB com 5MB de arquivos, isso significa ... 200k arquivos. Você gastará mais inodes na estrutura de diretórios do que nos próprios arquivos. Heck, você terá mais diretórios do que arquivos!