Quais tamanhos de bloco para milhões de arquivos pequenos

Eu tenho 2x discos de 4 TB no hardware RAID1 (pode ser um LSI MegaRaid) no Debian Wheezy. O tamanho do bloco físico é 4kB. Vou armazenar 150-200 milhões de arquivos pequenos (entre 3 e 10kB). Não estou pedindo desempenho, mas o melhor sistema de arquivos e tamanhos de bloco para economizar armazenamento. Copiei um arquivo de 8200 bytes para um ext4 com tamanho de bloco de 4kB. Isso levou 32kB de disco !? O diário é o motivo disso? Então, quais opções existem para economizar mais armazenamento para esses arquivos pequenos?

— rabudde
fonte

Consulte também: Como determino o tamanho do bloco de uma partição ext3 no Linux?

— Chris S

Se eu estivesse nessa situação, procuraria um banco de dados que possa armazenar todos os dados em um único arquivo com um índice compacto e baseado em deslocamento, em vez de arquivos separados. Talvez um banco de dados que possua um driver FUSE disponível para interagir com ele como arquivos quando necessário, sem que todos estejam sendo arquivos separados.

Como alternativa, você pode considerar o percentil 60 a 70 do tamanho dos arquivos e tentar ajustar esse tamanho de arquivo diretamente nos nós da árvore do sistema de arquivos, em vez de blocos separados no disco. Armazenar 10k em cada nó é provavelmente uma grande pergunta, mas se você conseguir 60% a 70% dos arquivos lá, isso provavelmente será uma grande vitória.

Somente certos sistemas de arquivos podem fazer isso (reiserfs é um), e acho que tudo depende do tamanho desse percentil, se ele se encaixará na árvore. Você pode ajustá-lo. Acho que tente encaixar o resto em um único bloco.

E não se preocupe com periódicos; eles têm um limite de tamanho superior de qualquer maneira.

Não não não não não não não não apenas ... não ao seu primeiro parágrafo. Cometi esse erro anos atrás e tinha que ser desfeito mais tarde. Também herdei sistemas que usam esse padrão de design. Os arquivos pertencem ao sistema de arquivos, ou como um comprometimento, a um objeto FileStream do SQL Server, se for necessário combiná-los (talvez seu driver do FUSE, mas ainda assim não). Existem outras considerações ao trabalhar no sistema de arquivos, como não colocar 4 milhões de arquivos em uma pasta (eu também cometi esse erro).

— Mark Henderson

@ MarkHenderson, mas o problema é definir o que DEVE ser um arquivo e o que deve ser um registro. Sem mais detalhes, centenas de milhões de pequenas coisas parecem-me muito mais com discos. Só porque ele os possui atualmente como arquivos, isso não significa que eles precisam permanecer assim, ou deveriam ter sido assim. Além disso, eu nunca para um segundo sugeriu o uso do SQL Server para o trabalho;)

Há cinco anos, herdei um sistema com 1 milhão de arquivos em uma única pasta e cerca de 10.000 novos arquivos de 1 a 4 KB todos os dias. Eu decidi jogá-los todos em uma tabela ISAM porque "Ei, eles são apenas texto simples para análise!" e isso acabou sendo um grande erro, porque agora eu tinha uma única tabela de 12 GB com um milhão de linhas que quase nada fazia depois de processadas. Então, voltei a colocá-los em um sistema de arquivos com pastas heiráquicas com base no GUID do nome do arquivo.

— Mark Henderson

(por uma única tabela 12GB com linhas squllion foi um problema foi uma questão diferente que eu não vou entrar aqui)

— Mark Henderson

@ MarkHenderson: Não é um problema diferente, é por isso que você disse que era a solução errada ("... erro enorme, porque agora eu tinha uma única tabela de 12 GB com um milhão de linhas ..."). Você escolhe o mecanismo errado do banco de dados / formato de tabela, mas o conceito de colocar muitas coisas pequenas em um único arquivo com um INDEX é válido, desde que você faça o que é certo. O que você deseja é um banco de dados que se destaque em armazenamentos de chave / valor para milhões de objetos pequenos, com compartilhamento automático. Observe também que ele nem sequer se importa com desempenho, apenas espaço.