Problema trabalhando com milhares de arquivos

maschiojv não é solução mas eu criaria um processo para zipar as imagens de acordo com tempo delas, e veria bem como ficaria a estrutura da arvore, caso seja possivel na sua regra, é ?

ja pensou em distribuir estas imagens para varios servers?

zipei algumas imagens pra testar, mas a diferença de tamanho ou foi insignificante ou ficou na mesma… sei não, mas acho que esse não é o caminho

certamente isso resolveria, mas ai eu teria que convencer que não tem outra solução meeeeeeesmo e que eles (boss e cliente) vão ter que meter a mão no bolso pra comprar mais servidores (mais hospedagem, mais backup, etc)

Cara, segmenta essa budega em vários diretórios (por data/hora, numero de arquivos, whatever). O problema pode estar relacionado a você ter muitos arquivos no mesmo diretório.

realmente me disseram isso quando eu tava analizando a melhor forma de fazer isso. nesse sistema eu dividi de forma que ficam no máximo 30 imagens por diretório, ta dividido por ano, mes, ponto de venda, processo. apenas 4 subdiretorios.
ouvi uma conversa tamém que o numero mágico é 64, 64 pastas dentro de cada pasta, 64 arquivos dentro de cada pasta e 64 subdiretorios para cada subdiretorio raiz, mas não achei nenhum fundamento que justificasse isso… seria um processo foda, não posso fazer isso baseado num numero cabalistico eu provavelmente não tenha fundamento… por isso estou pedindo opiniões aqui no forum, onde tem mais chance de alguem ja ter passado por algma coisa parecida

realmente me disseram isso quando eu tava analizando a melhor forma de fazer isso. nesse sistema eu dividi de forma que ficam no máximo 30 imagens por diretório, ta dividido por ano, mes, ponto de venda, processo. apenas 4 subdiretorios.
ouvi uma conversa tamém que o numero mágico é 64, 64 pastas dentro de cada pasta, 64 arquivos dentro de cada pasta e 64 subdiretorios para cada subdiretorio raiz, mas não achei nenhum fundamento que justificasse isso… seria um processo foda, não posso fazer isso baseado num numero cabalistico que provavelmente não tenha fundamento… por isso estou pedindo opiniões aqui no forum, onde tem mais chance de alguem ja ter passado por algma coisa parecida

Nao entendi tua estrutura… seria assim?

2011
–> Jan
---->Pt Venda 1
------>Processo 1
------>Processo 2
---->Pt Venda 2
–> Fev
---->Pt Venda 1
------>Processo 1
------>Processo 2
---->Pt Venda 2

esmiralha:

Nao entendi tua estrutura… seria assim?

2011
–> Jan
---->Pt Venda 1
------>Processo 1
------>Processo 2
---->Pt Venda 2
–> Fev
---->Pt Venda 1
------>Processo 1
------>Processo 2
---->Pt Venda 2

isso ai. mais precisamente isso:

2011 (12 pastas dentro dessa)
–>1 (os meses estão em numeros, tem em média 140 pastas aqui dentro)
---->1000 (id do ponto de venda, ai varia entre 1 e 100 pastas)
-------> 12345 (id do processo com no máximo 30 imagens)

quando identificamos que essa estrutura estava dando problema, tiramos todas as pastas e arquivos de jan de 2011 pra tras, se tiver poucos meses não tem problema…

Qual o tamanho médio de cada imagem?

entre 150 e 300k

É necessário manter todas as informações (arquivos/pastas/subpastas) indefinidamente…??

Aqui na empresa passamos por um problema parecido com este…Tinhamos um FileServer onde o Tomcat armazenava fisicamente os arquivos e guardava um index para estes arquivos em Banco de Dados…A medida que o tamanho do fileserver foi crescendo tivemos que montar uma estrutura de expurgo e restore de arquivos antigos, por exemplo, mais que 6 meses, atualmente por volta de 3 meses fica armazenado 700 GB de imagens, e o restante é transferido para outro fileserver.

Basicamente tinhamos um processo batch que ao executar varria o fileserver ativo em busca dos arquivos antigos baseando-se nos index armazenados no DB, e os transportavam para outro fileserver, neste momento o batch ajustava as informações no DB para os indexs destes arquivos movidos…

Com isso conseguimos resolver um problema.

Uma outra opção é utilizar alguma API para tratamento de Arquivos/Imagens, como por exemplo, o Apache Jackrabbit, muito boa por sinal, com ela você pode indexar tanto em filesystem, banco de dados e/ou filesystem+DB…

joaosouza:

É necessário manter todas as informações (arquivos/pastas/subpastas) indefinidamente…??

Aqui na empresa passamos por um problema parecido com este…Tinhamos um FileServer onde o Tomcat armazenava fisicamente os arquivos e guardava um index para estes arquivos em Banco de Dados…A medida que o tamanho do fileserver foi crescendo tivemos que montar uma estrutura de expurgo e restore de arquivos antigos, por exemplo, mais que 6 meses, atualmente por volta de 3 meses fica armazenado 700 GB de imagens, e o restante é transferido para outro fileserver.

Basicamente tinhamos um processo batch que ao executar varria o fileserver ativo em busca dos arquivos antigos baseando-se nos index armazenados no DB, e os transportavam para outro fileserver, neste momento o batch ajustava as informações no DB para os indexs destes arquivos movidos…

Com isso conseguimos resolver um problema.

Uma outra opção é utilizar alguma API para tratamento de Arquivos/Imagens, como por exemplo, o Apache Jackrabbit, muito boa por sinal, com ela você pode indexar tanto em filesystem, banco de dados e/ou filesystem+DB…

Infelizmente sim, temos que manter por um bom tempo as informações…
quanto a transferir de um servidor para outro… acho que essa é a inevitavel solução, mas eu queria que pelo menos eu conseguisse utilizar totalmente o HD disponivel nesse servidor (que é de um tera), mas o problema começa com uns 250G só, se eu pelo menos conseguisse chegar nos 700G como você eu ficaria mais satisfeito. Qual é a estrutura de diretórios que vc está usando? quantoas subpastas e quantos arquivos por pasta em média?

Olá maschiojv,

Cara a estrutura de diretórios que usamos aqui é bem simples, fica no máximo em 4 a 5 níveis e não chega a ter 10 arquivos em cada nível…

Uma pergunta, esse disco de 1 Tera que você disse ter é um disco local no server ou um storage com uma LUN de 1 Tera ??

Aqui, por exemplo, temos um disco com 1 tera, mas quebramos ele em várias Luns de 250 GB, por exemplo. Com isso voce ganha em disponibilidade pq se um destes discos cair vc não perde tudo e indisponibiliza o sistema, e por outro lado você tem mais performance pois como os discos são menores a indexação é melhor…

Espero que tenha ajudado.

Bom…

Conversei sobre esse problema com o cara de fala rápida mais f%$# que conheço, e ele me deu as seguintes soluções:

• Obviamente dividir as imagens em várias pastas;
• Efetuar testes com outras versões do Apache caso não esteja com a última;
• Fazer raid do disco;
• Verificar o file system, alguns file systems trabalham melhor com imagens grandes, outros melhor com pequenas etc.
• Contratar alguma empresa de CDN.

joaosouza:

Olá maschiojv,

Cara a estrutura de diretórios que usamos aqui é bem simples, fica no máximo em 4 a 5 níveis e não chega a ter 10 arquivos em cada nível…

Uma pergunta, esse disco de 1 Tera que você disse ter é um disco local no server ou um storage com uma LUN de 1 Tera ??

Aqui, por exemplo, temos um disco com 1 tera, mas quebramos ele em várias Luns de 250 GB, por exemplo. Com isso voce ganha em disponibilidade pq se um destes discos cair vc não perde tudo e indisponibiliza o sistema, e por outro lado você tem mais performance pois como os discos são menores a indexação é melhor…

Espero que tenha ajudado.

são 4 HDs, um pro sistema operacional e os aplicativos, um para as imagens e mais dois que fazem raid 1 dos 2 primeiros. isso mata todos os slots, não tem como plugar mais HDs nesse servidor…

deniswsrosa:

Bom…

Conversei sobre esse problema com o cara de fala rápida mais f%$# que conheço, e ele me deu as seguintes soluções:

• Obviamente dividir as imagens em várias pastas;
• Efetuar testes com outras versões do Apache caso não esteja com a última;
• Fazer raid do disco;
• Verificar o file system, alguns file systems trabalham melhor com imagens grandes, outros melhor com pequenas etc.
• Contratar alguma empresa de CDN.

deniswsrosa , valeu pelo esforço e manda um fuckyou pro cara f%$#, mesmo ele dando uma boa resposta
mas acontece que:

• as imagens já está divididas em várias pastas;
• vou ver isso, mas não acredito que o problema seja expecífico do apache, já que até se dar um ls na pasta o servidor cai;
• o maudito do raid é que está me impedindo de colocar mais HDs e dividir o problema, já que todos os slots estão sendo ocupados;
• verificar o filesystem pode ser uma boa, contratamos um consultor linux que sugeriu fazer essa troca e analizar qual vai ser o mais adequado, tomara que isso resolva;
• sim sim, quando o dinheiro não é problema não ha problemas

maschiojv:

…

Opa! apenas complementando o tópico, hoje eu topei com o Pomegranate (https://github.com/macan/Pomegranate/wiki), e ele talves possa ser de grande ajuda para o seu problema, confira o post a seguir:
http://highscalability.com/blog/2010/8/30/pomegranate-storing-billions-and-billions-of-tiny-little-fil.html

Tenho uma idéia, mas não sei se é uma boa.

Seria usar o HDFS do projeto Hadoop da Apache para armazenar as imagens em SequenceFiles, e caso fique lenta a busca via MapReduce, usar Memcached para ter as imagens mais acessadas em cache ou algo parecido. O bacana é que fica tudo distribuído, com alta escalabilidade e disponibilidade. Mas a complexidade aumenta.

Pesquise sobre o MongoDB tbm. Ele é feito para consultas online, então talvez seja mais adequado.

[[]]'s

maschiojv, dá uma olhada em Content Addressable Storage. Não sei se tem alguma solução open source madura e fácil de usar, mas cheguei a usar na empresa em que trabalhei o CAStor, que resolveu bem o problema de repositórios de arquivos em grande quantidade, balanceamento de carga, disponibilidade, fora que gostei bastante da interface baseada em métodos e cabeçalhos HTTP.

“…armazena e exibe milhares de imagens por dia…” … má nem se fossem milhasres de arquivos ascii/txt filesystem daria conta.
Talvez dê com banco de dados. Mas se o volume é assim tão grande quanto vc dá a entender, aconcelho buscar alguma solução própria para armazenamento de imágens.