Em Fri, 27 Nov 2009 10:05:22 -0200 "Fábio Jr." fjuniorlista@gmail.com, conhecido consumidor de drogas (BigMac's com Coke) escreveu:
Finalmente, o que venho pedir a lista seriam sugesto~es de como melhorar a indexaça~o/organizaça~o destes arquivos. Ja' pensei em utilizar armazenamento distribui'do (SAN, cloud, GlusterFS), organizaça~o por pastas com AliasMatch do apache para recupera'-las depois e armazenamento em banco de dados.
MySQL blobs??
http://www.google.com.br/search?q=using+mysql+blobs&ie=utf-8&oe=utf-...
Obrigado pelas respostas,
irado furioso com tudo escreveu:
MySQL blobs??
http://www.google.com.br/search?q=using+mysql+blobs&ie=utf-8&oe=utf-...
O que me preocupa em utilizar o banco é ao invés de resolver o problema, eu só mudar o gargalo. Saio do problema de organização e nfs e passo a ter problemas com quantidade de conexões.
Logicamente que o banco tem q ser tunado de uma maneira que ele consiga atender minhas necessidades, mas meu objetivo é uma solução que não seja paliativa no sentido de que daqui 6 meses eu tenha q procurar outra forma de armazenar os dados.
Por esse motivo que o armazenamento em cloud me atrai um pouco pois querendo ou não é uma tecnologia que ainda pode melhorar muito, e talvez valha a pena apostar algumas fichas nela.
Obg Irado.
Bruno L F Cabral escreveu:
um metodo usado em maildir, no postfix e no squid é separar em subdiretorios estilo
1/2/123456.jpg
ou mesmo
12/34/123456.jpg
assim reduz bastante a quantidade de arquivos por diretorio, acelerando o acesso
Essa é um método muito bom, que inclusive já fiz alguns testes. O problema que acabei tendo, talvez por falta de experiência e conhecimento, foi com as configurações do apache para que quando eu requisite a imagem http://meusite.com/imagens/123456.jpg, ele encontre a imagem que esta em /var/www/imagens/12/34/123456.jpg. A regra do AliasMatch que funciona para esta imagem por exemplo, não funciona para a imagem 123.jpg. Acredito que tenha solução para esse problema da regra.
Obrigado Bruno.
Outra limitação que talvez seja interessante citar é que alterar o nome destas imagens está fora de cogitação.
Outra coisa que me preocupa é o momento em que for decidido (mudança de pastas/inserção no banco/transferência de arquivos para cloud) e a ação tiver de ser feita. Na ultima vez que migramos estes dados para o novo servidor de storage, demorou 4 dias para passar todos os arquivos, e eram menos de 3,5 milhões.
[]s
O sistema do qual administro os servidores, possui uma funcionalidade que é exibição de imagens cadastradas pelos usuários. Estas imagens são armazenadas atualmente em um único diretório, e são gravadas com um número (ex.:123456.jpg)
um metodo usado em maildir, no postfix e no squid é separar em subdiretorios estilo
1/2/123456.jpg
ou mesmo
12/34/123456.jpg
assim reduz bastante a quantidade de arquivos por diretorio, acelerando o acesso
[]s, !3runo Cabral
Qual o filesystem q vc está usando?
acho que o Reiser seria uma boa pedida junto com o esquema de diretórios que o Bruno colocou. Em um servidor de emails parrudo, o reiserfs fez diferença na partição que eu usava pra spool.
Se vc chegar a uma conclusão, posta aqui pra gente.
Abs,
Skin
2009/11/27 Bruno L F Cabral bruno@openline.com.br:
O sistema do qual administro os servidores, possui uma funcionalidade que é exibição de imagens cadastradas pelos usuários. Estas imagens são armazenadas atualmente em um único diretório, e são gravadas com um número (ex.:123456.jpg)
um metodo usado em maildir, no postfix e no squid é separar em subdiretorios estilo
1/2/123456.jpg
ou mesmo
12/34/123456.jpg
assim reduz bastante a quantidade de arquivos por diretorio, acelerando o acesso
[]s, !3runo Cabral _______________________________________________ CentOS-pt-br mailing list CentOS-pt-br@centos.org http://lists.centos.org/mailman/listinfo/centos-pt-br
Alem do reiser agora o ext4 ja esta vindo "de fabrica" no centos5.4
Pode ser uma boa saida. O que o pessoal ja falou que pode ajudar muito eh procurar o que se usa em sistema de emails pois o normal sao milhoes de arquivos pequenos.
Outra ideia (ja falada) pode ser distribuir os arquivos em uma arvore de acordo com o nome deles e para busca-los voce usa algumas regras de rewrite no apache. Usamo isso aqui muito tempo, era um numero muito grande de arquivos e varios servidores montando o fs via nfs. Na epoca usavamos reiserfs hj em dia eu faria alguns testes em cima do ext4 antes de partir direto para o reiser.
-- Vini
2009/11/27 Leandro Cerqueira leandro.cerqueira@gmail.com
Qual o filesystem q vc está usando?
acho que o Reiser seria uma boa pedida junto com o esquema de diretórios que o Bruno colocou. Em um servidor de emails parrudo, o reiserfs fez diferença na partição que eu usava pra spool.
Se vc chegar a uma conclusão, posta aqui pra gente.
Abs,
Skin
2009/11/27 Bruno L F Cabral bruno@openline.com.br:
O sistema do qual administro os servidores, possui uma funcionalidade que é exibição de imagens cadastradas pelos usuários. Estas imagens são armazenadas atualmente em um único diretório, e são gravadas com um número (ex.:123456.jpg)
um metodo usado em maildir, no postfix e no squid é separar em subdiretorios estilo
1/2/123456.jpg
ou mesmo
12/34/123456.jpg
assim reduz bastante a quantidade de arquivos por diretorio, acelerando o acesso
[]s, !3runo Cabral _______________________________________________ CentOS-pt-br mailing list CentOS-pt-br@centos.org http://lists.centos.org/mailman/listinfo/centos-pt-br
CentOS-pt-br mailing list CentOS-pt-br@centos.org http://lists.centos.org/mailman/listinfo/centos-pt-br
olá Vinicius, obrigado pela resposta
Alem do reiser agora o ext4 ja esta vindo "de fabrica" no centos5.4
É, fiz alguns testes com o ext4, mas esperava mais dele. Novamente acredito que a forma q eu utilizei para testar tenha favorecido os outros filesystems, mas o desempenho do ext4 foi muito similar ao ext3 e inferior ao resierfs.
Pode ser uma boa saida. O que o pessoal ja falou que pode ajudar muito eh procurar o que se usa em sistema de emails pois o normal sao milhoes de arquivos pequenos.
É, tenho q aprofundar minhas pesquisas em maildir e mailbox pra entender um pouco melhor.
Outra ideia (ja falada) pode ser distribuir os arquivos em uma arvore de acordo com o nome deles e para busca-los voce usa algumas regras de rewrite no apache. Usamo isso aqui muito tempo, era um numero muito grande de arquivos e varios servidores montando o fs via nfs. Na epoca usavamos reiserfs hj em dia eu faria alguns testes em cima do ext4 antes de partir direto para o reiser.
Realmente, essa solução é a que me parece a mais viável. O problema foi nas configurações do Apache. Outro assunto que preciso me aprofundar mais, já que me bati um monte para testar, e mesmo assim não deu muito certo. Acho q antes de organizar a estrutura de diretórios, preciso organizar melhor meu tempo para aprofundamento nestes assuntos ( dias com 6 horas a mais resolveriam o problema quem sabe ;) )
[]s
Eu uso na minha partição spool o XFS. Nos testes que eu realizei ele foi o mais performático...
Maildir = cada e-mail em um arquivo Mailbox = todos os e-mails em um arquivo
Abs
2009/11/27 "Fábio Jr." fjuniorlista@gmail.com
olá Vinicius, obrigado pela resposta
Alem do reiser agora o ext4 ja esta vindo "de fabrica" no centos5.4
É, fiz alguns testes com o ext4, mas esperava mais dele. Novamente acredito que a forma q eu utilizei para testar tenha favorecido os outros filesystems, mas o desempenho do ext4 foi muito similar ao ext3 e inferior ao resierfs.
Pode ser uma boa saida. O que o pessoal ja falou que pode ajudar muito eh procurar o que se usa em sistema de emails pois o normal sao milhoes de arquivos pequenos.
É, tenho q aprofundar minhas pesquisas em maildir e mailbox pra entender um pouco melhor.
Outra ideia (ja falada) pode ser distribuir os arquivos em uma arvore de acordo com o nome deles e para busca-los voce usa algumas regras de rewrite no apache. Usamo isso aqui muito tempo, era um numero muito grande de arquivos e varios servidores montando o fs via nfs. Na epoca usavamos reiserfs hj em dia eu faria alguns testes em cima do ext4 antes de partir direto para o reiser.
Realmente, essa solução é a que me parece a mais viável. O problema foi nas configurações do Apache. Outro assunto que preciso me aprofundar mais, já que me bati um monte para testar, e mesmo assim não deu muito certo. Acho q antes de organizar a estrutura de diretórios, preciso organizar melhor meu tempo para aprofundamento nestes assuntos ( dias com 6 horas a mais resolveriam o problema quem sabe ;) )
[]s
-- Fábio da Silva Júnior - fjuniorlista@gmail.com ----- http://fabioojunior.wordpress.com -----
CentOS-pt-br mailing list CentOS-pt-br@centos.org http://lists.centos.org/mailman/listinfo/centos-pt-br
EXT4 pra mim é penteadeira de puta: Um EXT3 cheio de recursos - PRA MIM, DEIXO CLARO - desnecessários, enquanto conceitualmente continua sendo a mesma coisa que o EXT2...
Dos testes que já realizei, acredito que o JFS ou ReiserFS serviriam a sua necessidade muito bem. O XFS também é excelente, mas faz muito cache em memória. Se tu tem uma storage, provavelmente também tem um bom nobreak. As vezes convém tentar. :-)
Agora, o que eu faria é segundo a idéia do Irado: Colocaria tudo dentro do MySQL. Por que no caso, um banco de dados é bem maior e mais seguro (se houver backup, claro) do que 4 milhões de imagens nos seus HDs. Bem menos inodes, consultas mais organizadas, enfim.
Abraço, Lucas Timm.
2009/11/27 Fabio Rampazzo Mathias fmathias@gmail.com
Eu uso na minha partição spool o XFS. Nos testes que eu realizei ele foi o mais performático...
Maildir = cada e-mail em um arquivo Mailbox = todos os e-mails em um arquivo
Abs
2009/11/27 "Fábio Jr." fjuniorlista@gmail.com
olá Vinicius, obrigado pela resposta
Alem do reiser agora o ext4 ja esta vindo "de fabrica" no centos5.4
É, fiz alguns testes com o ext4, mas esperava mais dele. Novamente acredito que a forma q eu utilizei para testar tenha favorecido os outros filesystems, mas o desempenho do ext4 foi muito similar ao ext3 e inferior ao resierfs.
Pode ser uma boa saida. O que o pessoal ja falou que pode ajudar muito eh procurar o que se usa em sistema de emails pois o normal sao milhoes de arquivos pequenos.
É, tenho q aprofundar minhas pesquisas em maildir e mailbox pra entender um pouco melhor.
Outra ideia (ja falada) pode ser distribuir os arquivos em uma arvore de acordo com o nome deles e para busca-los voce usa algumas regras de rewrite no apache. Usamo isso aqui muito tempo, era um numero muito grande de arquivos e varios servidores montando o fs via nfs. Na epoca usavamos reiserfs hj em dia eu faria alguns testes em cima do ext4 antes de partir direto para o reiser.
Realmente, essa solução é a que me parece a mais viável. O problema foi nas configurações do Apache. Outro assunto que preciso me aprofundar mais, já que me bati um monte para testar, e mesmo assim não deu muito certo. Acho q antes de organizar a estrutura de diretórios, preciso organizar melhor meu tempo para aprofundamento nestes assuntos ( dias com 6 horas a mais resolveriam o problema quem sabe ;) )
[]s
-- Fábio da Silva Júnior - fjuniorlista@gmail.com ----- http://fabioojunior.wordpress.com -----
CentOS-pt-br mailing list CentOS-pt-br@centos.org http://lists.centos.org/mailman/listinfo/centos-pt-br
CentOS-pt-br mailing list CentOS-pt-br@centos.org http://lists.centos.org/mailman/listinfo/centos-pt-br
Bom artigo sobre FS's:
http://www.debian-administration.org/articles/388
2009/11/27 Lucas Timm LH linuxhelper@gmail.com:
EXT4 pra mim é penteadeira de puta: Um EXT3 cheio de recursos - PRA MIM, DEIXO CLARO - desnecessários, enquanto conceitualmente continua sendo a mesma coisa que o EXT2...
Dos testes que já realizei, acredito que o JFS ou ReiserFS serviriam a sua necessidade muito bem. O XFS também é excelente, mas faz muito cache em memória. Se tu tem uma storage, provavelmente também tem um bom nobreak. As vezes convém tentar. :-)
Agora, o que eu faria é segundo a idéia do Irado: Colocaria tudo dentro do MySQL. Por que no caso, um banco de dados é bem maior e mais seguro (se houver backup, claro) do que 4 milhões de imagens nos seus HDs. Bem menos inodes, consultas mais organizadas, enfim.
Abraço, Lucas Timm.
2009/11/27 Fabio Rampazzo Mathias fmathias@gmail.com
Eu uso na minha partição spool o XFS. Nos testes que eu realizei ele foi o mais performático... Maildir = cada e-mail em um arquivo Mailbox = todos os e-mails em um arquivo
Abs 2009/11/27 "Fábio Jr." fjuniorlista@gmail.com
olá Vinicius, obrigado pela resposta
Alem do reiser agora o ext4 ja esta vindo "de fabrica" no centos5.4
É, fiz alguns testes com o ext4, mas esperava mais dele. Novamente acredito que a forma q eu utilizei para testar tenha favorecido os outros filesystems, mas o desempenho do ext4 foi muito similar ao ext3 e inferior ao resierfs.
Pode ser uma boa saida. O que o pessoal ja falou que pode ajudar muito eh procurar o que se usa em sistema de emails pois o normal sao milhoes de arquivos pequenos.
É, tenho q aprofundar minhas pesquisas em maildir e mailbox pra entender um pouco melhor.
Outra ideia (ja falada) pode ser distribuir os arquivos em uma arvore de acordo com o nome deles e para busca-los voce usa algumas regras de rewrite no apache. Usamo isso aqui muito tempo, era um numero muito grande de arquivos e varios servidores montando o fs via nfs. Na epoca usavamos reiserfs hj em dia eu faria alguns testes em cima do ext4 antes de partir direto para o reiser.
Realmente, essa solução é a que me parece a mais viável. O problema foi nas configurações do Apache. Outro assunto que preciso me aprofundar mais, já que me bati um monte para testar, e mesmo assim não deu muito certo. Acho q antes de organizar a estrutura de diretórios, preciso organizar melhor meu tempo para aprofundamento nestes assuntos ( dias com 6 horas a mais resolveriam o problema quem sabe ;) )
[]s
-- Fábio da Silva Júnior - fjuniorlista@gmail.com ----- http://fabioojunior.wordpress.com -----
CentOS-pt-br mailing list CentOS-pt-br@centos.org http://lists.centos.org/mailman/listinfo/centos-pt-br
CentOS-pt-br mailing list CentOS-pt-br@centos.org http://lists.centos.org/mailman/listinfo/centos-pt-br
-- Lucas Timm, Goiânia/GO. http://timmerman.wordpress.com
(62) 9157-0789
CentOS-pt-br mailing list CentOS-pt-br@centos.org http://lists.centos.org/mailman/listinfo/centos-pt-br
Olá Lucas, obg pela resposta
Lucas Timm LH escreveu:
EXT4 pra mim é penteadeira de puta: Um EXT3 cheio de recursos - PRA MIM, DEIXO CLARO - desnecessários, enquanto conceitualmente continua sendo a mesma coisa que o EXT2...
Dos testes que já realizei, acredito que o JFS ou ReiserFS serviriam a sua necessidade muito bem. O XFS também é excelente, mas faz muito cache em memória. Se tu tem uma storage, provavelmente também tem um bom nobreak. As vezes convém tentar. :-)
Agora, o que eu faria é segundo a idéia do Irado: Colocaria tudo dentro do MySQL. Por que no caso, um banco de dados é bem maior e mais seguro (se houver backup, claro) do que 4 milhões de imagens nos seus HDs. Bem menos inodes, consultas mais organizadas, enfim.
Hmm.. vou incluir o JFS e o XFS nos meus testes. O storage é hospedado fora do pais em uma empresa de web hosting.
Obg a todos pelas dicas.
[]s
Olha, tenho que concordar com o Lucas (e com os outros que falaram)
Isso é trabalho de Banco de Dados. Coloca um Mysql com blob e indexado pelo nome. Isso, definitivamente resolverá o seu problema. 4 Milhoes de registros não é nada para o mysql. Utilize a configuração HUGE que vem nos exemplos.
Trabalho administrando servidores de bioinformática e sempre usamos XFS + MySQL para bilhões de dados. Funciona perfeitamente.
Qualquer dúvida ou outra solução posta aqui na e-mail list. Poderá ser útil para outros.
Abraços
2009/11/27 "Fábio Jr." fjuniorlista@gmail.com
Olá Lucas, obg pela resposta
Lucas Timm LH escreveu:
EXT4 pra mim é penteadeira de puta: Um EXT3 cheio de recursos - PRA MIM, DEIXO CLARO - desnecessários, enquanto conceitualmente continua sendo a mesma coisa que o EXT2...
Dos testes que já realizei, acredito que o JFS ou ReiserFS serviriam a sua necessidade muito bem. O XFS também é excelente, mas faz muito cache em memória. Se tu tem uma storage, provavelmente também tem um bom nobreak. As vezes convém tentar. :-)
Agora, o que eu faria é segundo a idéia do Irado: Colocaria tudo dentro do MySQL. Por que no caso, um banco de dados é bem maior e mais seguro (se houver backup, claro) do que 4 milhões de imagens nos seus HDs. Bem menos inodes, consultas mais organizadas, enfim.
Hmm.. vou incluir o JFS e o XFS nos meus testes. O storage é hospedado fora do pais em uma empresa de web hosting.
Obg a todos pelas dicas.
[]s
-- Fábio da Silva Júnior - fjuniorlista@gmail.com ----- http://fabioojunior.wordpress.com -----
CentOS-pt-br mailing list CentOS-pt-br@centos.org http://lists.centos.org/mailman/listinfo/centos-pt-br
Olá Fabio, obg pela resposta
Fabio Rampazzo Mathias escreveu:
Olha, tenho que concordar com o Lucas (e com os outros que falaram)
Isso é trabalho de Banco de Dados. Coloca um Mysql com blob e indexado pelo nome. Isso, definitivamente resolverá o seu problema. 4 Milhoes de registros não é nada para o mysql. Utilize a configuração HUGE que vem nos exemplos.
Trabalho administrando servidores de bioinformática e sempre usamos XFS + MySQL para bilhões de dados. Funciona perfeitamente.
Analizando as dicas de todo o pessoal, e reavaliando a situação dos meus dados, notei outro empecilho na utilização do MySQL. Eu acredito que seja um empecilho isso, e me corrijam se eu estiver erra por favor.
Estas imagens que eu tenho armazenadas, são muito acessadas, e eu explico como. Elas são exibidas em vários sites, que ficam hospedados no servidor de aplicação, que monta via nfs o storage com as imagens. Estes sites juntos tem algo em torno de 700 mil a 1 milhão de acessos por dia. Para cada página exibida, eu mostro uma média que varia de 7 a 10 imagens destas 4 milhões armazenadas.
Isso significa que eu teria em um dia de muito acesso, pelo menos 10 milhões de queries ao banco? Isso se a programação fizer um select para cada foto correto? Para poder atender essa demanda, precisaria de um cluster de mysql talvez... ou não?
Vlw pela dica Felipe, vou dar uma lida.
Filipe Rosset escreveu:
Vale a pena dar uma olhada nesse outra thread
http://groups.google.com/group/tchelinux/browse_thread/thread/65c2f4b30bf6e1...
Obrigado novamente a todos pelas dicas.
[]s
Fabio,
Vamos com calma....você não tem 4 milhões de figuras....você tem aprox. 1,34 milhão de figuras (4/3).... o resto é resize da mesma, que você pode armazenar no mesmo registro do MySQL. Só programar para trazer a figura conveniente. Depois, você está compartilhando um diretório via NFS. Eu diria que, o gargalo está no NFS, pois ele não é performático como o filesystem.
Outro ponto importante é a aplicação. Há a viabilidade de requisitar as 7 ou 10 figuras de uma vez só?
Acho que mesmo que a pergunta anterior não seja respondida de forma afirmativa, um banco de dados traria ganhos em termos de performance.
Você sabe qual é a média de acessos e o pico de acessos (em quantidade) ??? Quanto ao cluster, qual máquina que você possui para o servidor NFS ?
abraços
2009/11/27 "Fábio Jr." fjuniorlista@gmail.com
Olá Fabio, obg pela resposta
Fabio Rampazzo Mathias escreveu:
Olha, tenho que concordar com o Lucas (e com os outros que falaram)
Isso é trabalho de Banco de Dados. Coloca um Mysql com blob e indexado pelo nome. Isso, definitivamente resolverá o seu problema. 4 Milhoes de registros não é nada para o mysql. Utilize a configuração HUGE que vem nos exemplos.
Trabalho administrando servidores de bioinformática e sempre usamos XFS + MySQL para bilhões de dados. Funciona perfeitamente.
Analizando as dicas de todo o pessoal, e reavaliando a situação dos meus dados, notei outro empecilho na utilização do MySQL. Eu acredito que seja um empecilho isso, e me corrijam se eu estiver erra por favor.
Estas imagens que eu tenho armazenadas, são muito acessadas, e eu explico como. Elas são exibidas em vários sites, que ficam hospedados no servidor de aplicação, que monta via nfs o storage com as imagens. Estes sites juntos tem algo em torno de 700 mil a 1 milhão de acessos por dia. Para cada página exibida, eu mostro uma média que varia de 7 a 10 imagens destas 4 milhões armazenadas.
Isso significa que eu teria em um dia de muito acesso, pelo menos 10 milhões de queries ao banco? Isso se a programação fizer um select para cada foto correto? Para poder atender essa demanda, precisaria de um cluster de mysql talvez... ou não?
Vlw pela dica Felipe, vou dar uma lida.
Filipe Rosset escreveu:
Vale a pena dar uma olhada nesse outra thread
http://groups.google.com/group/tchelinux/browse_thread/thread/65c2f4b30bf6e1... \
Obrigado novamente a todos pelas dicas.
[]s
-- Fábio da Silva Júnior - fjuniorlista@gmail.com ----- http://fabioojunior.wordpress.com -----
CentOS-pt-br mailing list CentOS-pt-br@centos.org http://lists.centos.org/mailman/listinfo/centos-pt-br
Fabio Rampazzo Mathias escreveu:
Fabio,
Vamos com calma....você não tem 4 milhões de figuras....você tem aprox. 1,34 milhão de figuras (4/3).... o resto é resize da mesma, que você pode armazenar no mesmo registro do MySQL. Só programar para trazer a figura conveniente. Depois, você está compartilhando um diretório via NFS. Eu diria que, o gargalo está no NFS, pois ele não é performático como o filesystem.
Tenho 4 milhões de aquivos no total. Uma imagem tem 3 tamanho diferentes e são 3 arquivos diferentes. Ok, acho q foi isso q vc entendeu mesmo, só pra confirmar. Concordo com você ao dizer que nfs é gargalo, mas ele é um dos gargalos, já que a medida que eu aumento o numero de arquivos no mesmo diretório, o próprio filesystem começa a perder performance na hora de me retornar o arquivo. Pelo menos foi isso que eu percebi aqui.
Outro ponto importante é a aplicação. Há a viabilidade de requisitar as 7 ou 10 figuras de uma vez só?
Através de uma conexão ao banco sim, mas não através de uma consulta só. Eu posso abrir uma conexão, e fazer as minhas 7 ou 10 consultas nessa mesma conexão.
Acho que mesmo que a pergunta anterior não seja respondida de forma afirmativa, um banco de dados traria ganhos em termos de performance.
Você sabe qual é a média de acessos e o pico de acessos (em quantidade) ??? Quanto ao cluster, qual máquina que você possui para o servidor NFS ?
O pico é de 120 requisições por segundo, e a média do dia é 40 req/seg. Isso pq de madrugada a quantidade de requisições é muito baixa. A média de requisições em horário comercial é de 60 req/sec.
O servidor nfs é um Dual Xeon 5405 com 2 GB de memória com discos SAS de 15k RPM com espelhamento.
[]s
2009/11/27 "Fábio Jr." fjuniorlista@gmail.com:
Fabio Rampazzo Mathias escreveu:
Fabio,
Vamos com calma....você não tem 4 milhões de figuras....você tem aprox. 1,34 milhão de figuras (4/3).... o resto é resize da mesma, que você pode armazenar no mesmo registro do MySQL. Só programar para trazer a figura conveniente. Depois, você está compartilhando um diretório via NFS. Eu diria que, o gargalo está no NFS, pois ele não é performático como o filesystem.
Tenho 4 milhões de aquivos no total. Uma imagem tem 3 tamanho diferentes e são 3 arquivos diferentes. Ok, acho q foi isso q vc entendeu mesmo, só pra confirmar. Concordo com você ao dizer que nfs é gargalo, mas ele é um dos gargalos, já que a medida que eu aumento o numero de arquivos no mesmo diretório, o próprio filesystem começa a perder performance na hora de me retornar o arquivo. Pelo menos foi isso que eu percebi aqui.
Outro ponto importante é a aplicação. Há a viabilidade de requisitar as 7 ou 10 figuras de uma vez só?
Através de uma conexão ao banco sim, mas não através de uma consulta só. Eu posso abrir uma conexão, e fazer as minhas 7 ou 10 consultas nessa mesma conexão.
Acho que mesmo que a pergunta anterior não seja respondida de forma afirmativa, um banco de dados traria ganhos em termos de performance.
Você sabe qual é a média de acessos e o pico de acessos (em quantidade) ??? Quanto ao cluster, qual máquina que você possui para o servidor NFS ?
O pico é de 120 requisições por segundo, e a média do dia é 40 req/seg. Isso pq de madrugada a quantidade de requisições é muito baixa. A média de requisições em horário comercial é de 60 req/sec.
O servidor nfs é um Dual Xeon 5405 com 2 GB de memória com discos SAS de 15k RPM com espelhamento.
Todas as soluções apresentadas são ótimas do ponto de vista de cada um. Entretanto o seu maior problema, pelo que entendi, é o tempo que o fs demora para buscar o arquivo nesse diretório. Como já sugeriram, fazendo a simples mudança de criar mais diretórios irá resolver seu problema.
abcdef.jpg -> a/b/c/abcdef.jpg
Essa mudança na aplicação deve ser infinitamente mais fácil que colocar tudo em um banco de dados e mudar a lógica toda.
Tenho lá minha dúvidas se adicionar camada de abstração em cima de camada de abstração vai melhorar a performance. Como sempre, o melhor é montar um ambiente separado e testar para a sua situação.
A Internet está cheia de dicas de como otimizar o NFS.
Talvez mudar a aplicação para gravar em a/b/c/abcdef.jpg seja um problema.
Com mod_rewrite você consegue fazer com que um retrieve da image (abcdef.jpg) redirecione para um script em PHP que acessa o banco e obtém os dados....
Mas realmente, concordo que o problema não é tão simples devido ao volume de dados e acessos, e principalmente, pela importancia da aplicação....
Se puder simular um ambiente e fazer as comparações, você poderá tomar uma decisão mais segura e inteligente que os nossos "achismos" ;-)
boa sorte! =)
2009/11/27 Giovanni Tirloni tirloni@gmail.com
2009/11/27 "Fábio Jr." fjuniorlista@gmail.com:
Fabio Rampazzo Mathias escreveu:
Fabio,
Vamos com calma....você não tem 4 milhões de figuras....você tem aprox. 1,34 milhão de figuras (4/3).... o resto é resize da mesma, que você pode armazenar no mesmo registro do MySQL. Só programar para trazer a figura conveniente. Depois, você está compartilhando um diretório via NFS. Eu diria que, o gargalo está no NFS, pois ele não é performático como o filesystem.
Tenho 4 milhões de aquivos no total. Uma imagem tem 3 tamanho diferentes e são 3 arquivos diferentes. Ok, acho q foi isso q vc entendeu mesmo, só pra confirmar. Concordo com você ao dizer que nfs é gargalo, mas ele é um dos gargalos, já que a medida que eu aumento o numero de arquivos no mesmo diretório, o próprio filesystem começa a perder performance na hora de me retornar o arquivo. Pelo menos foi isso que eu percebi aqui.
Outro ponto importante é a aplicação. Há a viabilidade de requisitar as 7 ou 10 figuras de uma vez só?
Através de uma conexão ao banco sim, mas não através de uma consulta só. Eu posso abrir uma conexão, e fazer as minhas 7 ou 10 consultas nessa mesma conexão.
Acho que mesmo que a pergunta anterior não seja respondida de forma afirmativa, um banco de dados traria ganhos em termos de performance.
Você sabe qual é a média de acessos e o pico de acessos (em quantidade) ??? Quanto ao cluster, qual máquina que você possui para o servidor NFS ?
O pico é de 120 requisições por segundo, e a média do dia é 40 req/seg. Isso pq de madrugada a quantidade de requisições é muito baixa. A média de requisições em horário comercial é de 60 req/sec.
O servidor nfs é um Dual Xeon 5405 com 2 GB de memória com discos SAS de 15k RPM com espelhamento.
Todas as soluções apresentadas são ótimas do ponto de vista de cada um. Entretanto o seu maior problema, pelo que entendi, é o tempo que o fs demora para buscar o arquivo nesse diretório. Como já sugeriram, fazendo a simples mudança de criar mais diretórios irá resolver seu problema.
abcdef.jpg -> a/b/c/abcdef.jpg
Essa mudança na aplicação deve ser infinitamente mais fácil que colocar tudo em um banco de dados e mudar a lógica toda.
Tenho lá minha dúvidas se adicionar camada de abstração em cima de camada de abstração vai melhorar a performance. Como sempre, o melhor é montar um ambiente separado e testar para a sua situação.
A Internet está cheia de dicas de como otimizar o NFS.
-- Giovanni. _______________________________________________ CentOS-pt-br mailing list CentOS-pt-br@centos.org http://lists.centos.org/mailman/listinfo/centos-pt-br
No caso do desempenho do NFS existe a possibilidade de se utlizar várias interfaces de rede no servidor em trunking (802.3ad) com o apoio do switch. Isso te dará um throughput de acesso muito maior.
Para a manutenção dos arquivos a dsitribuição em diversos diretório acelara o desempenho, mas deixa o gerenciamento complexo. Assim, o gerenciamento deveria ser automatizado.
Na minha opinião, manter os dados em um banco de dados é a melhor solução, com a manutenção da base em um storage e com banco de dados em load-balance/failover. Aqui a combinação melhor vai depender de quanto você tem pra gastar e dos seus requisitos de desempenho. Podem variar de opções simples com mysql-cluster e storage NFS utilizando trunking até NAS fibre-channel com conexões de fibra com os servidores e Oracle como solução de banco de dados.
Enfim, a quantidade de fatores é enorme. Talvez seja melhor você fazer alguns benchmarks comparando várias situação para depois avaliação a infra-estrutura que você precisará e que melhor se adequa ao seu cenário.
2009/11/27 Giovanni Tirloni tirloni@gmail.com:
2009/11/27 "Fábio Jr." fjuniorlista@gmail.com:
Fabio Rampazzo Mathias escreveu:
Fabio,
Vamos com calma....você não tem 4 milhões de figuras....você tem aprox. 1,34 milhão de figuras (4/3).... o resto é resize da mesma, que você pode armazenar no mesmo registro do MySQL. Só programar para trazer a figura conveniente. Depois, você está compartilhando um diretório via NFS. Eu diria que, o gargalo está no NFS, pois ele não é performático como o filesystem.
Tenho 4 milhões de aquivos no total. Uma imagem tem 3 tamanho diferentes e são 3 arquivos diferentes. Ok, acho q foi isso q vc entendeu mesmo, só pra confirmar. Concordo com você ao dizer que nfs é gargalo, mas ele é um dos gargalos, já que a medida que eu aumento o numero de arquivos no mesmo diretório, o próprio filesystem começa a perder performance na hora de me retornar o arquivo. Pelo menos foi isso que eu percebi aqui.
Outro ponto importante é a aplicação. Há a viabilidade de requisitar as 7 ou 10 figuras de uma vez só?
Através de uma conexão ao banco sim, mas não através de uma consulta só. Eu posso abrir uma conexão, e fazer as minhas 7 ou 10 consultas nessa mesma conexão.
Acho que mesmo que a pergunta anterior não seja respondida de forma afirmativa, um banco de dados traria ganhos em termos de performance.
Você sabe qual é a média de acessos e o pico de acessos (em quantidade) ??? Quanto ao cluster, qual máquina que você possui para o servidor NFS ?
O pico é de 120 requisições por segundo, e a média do dia é 40 req/seg. Isso pq de madrugada a quantidade de requisições é muito baixa. A média de requisições em horário comercial é de 60 req/sec.
O servidor nfs é um Dual Xeon 5405 com 2 GB de memória com discos SAS de 15k RPM com espelhamento.
Todas as soluções apresentadas são ótimas do ponto de vista de cada um. Entretanto o seu maior problema, pelo que entendi, é o tempo que o fs demora para buscar o arquivo nesse diretório. Como já sugeriram, fazendo a simples mudança de criar mais diretórios irá resolver seu problema.
abcdef.jpg -> a/b/c/abcdef.jpg
Essa mudança na aplicação deve ser infinitamente mais fácil que colocar tudo em um banco de dados e mudar a lógica toda.
Tenho lá minha dúvidas se adicionar camada de abstração em cima de camada de abstração vai melhorar a performance. Como sempre, o melhor é montar um ambiente separado e testar para a sua situação.
A Internet está cheia de dicas de como otimizar o NFS.
-- Giovanni. _______________________________________________ CentOS-pt-br mailing list CentOS-pt-br@centos.org http://lists.centos.org/mailman/listinfo/centos-pt-br
Em 27-11-2009 14:15, "Fábio Jr." escreveu:
Olá Lucas, obg pela resposta
Lucas Timm LH escreveu:
EXT4 pra mim é penteadeira de puta: Um EXT3 cheio de recursos - PRA MIM, DEIXO CLARO - desnecessários, enquanto conceitualmente continua sendo a mesma coisa que o EXT2...
Dos testes que já realizei, acredito que o JFS ou ReiserFS serviriam a sua necessidade muito bem. O XFS também é excelente, mas faz muito cache em memória. Se tu tem uma storage, provavelmente também tem um bom nobreak. As vezes convém tentar. :-)
Agora, o que eu faria é segundo a idéia do Irado: Colocaria tudo dentro do MySQL. Por que no caso, um banco de dados é bem maior e mais seguro (se houver backup, claro) do que 4 milhões de imagens nos seus HDs. Bem menos inodes, consultas mais organizadas, enfim.
Hmm.. vou incluir o JFS e o XFS nos meus testes. O storage é hospedado fora do pais em uma empresa de web hosting.
Obg a todos pelas dicas.
[]s
Vale a pena dar uma olhada nesse outra thread
http://groups.google.com/group/tchelinux/browse_thread/thread/65c2f4b30bf6e1...
Olá Leandro, obg pelo reply.
Leandro Cerqueira escreveu:
Qual o filesystem q vc está usando?
acho que o Reiser seria uma boa pedida junto com o esquema de diretórios que o Bruno colocou. Em um servidor de emails parrudo, o reiserfs fez diferença na partição que eu usava pra spool.
Uso ext3. Realmente, o reiserfs se comporta muito melhor com o tipo de ambiente que eu tenho, que são grandes quantidades de arquivos, de tamanho pequeno. Com certeza o filesystem é um ponto chave na escolha da solução. Fiz alguns testes com ext3 x ext4 x reiserfs , mas quero testar ainda o ZFS, já que ele é tão bem falado. Fiz alguns testes com glusterfs também, mas os resultados não foram muito satisfatórios. Talvez o método que utilizei para os testes não seja o melhor.
[]s
discuss-pt-br@lists.centos.org
-
"Fábio Jr." -
Bruno L F Cabral -
Cleber Souza -
Fabio Rampazzo Mathias -
Filipe Rosset -
Gilberto Nunes -
Giovanni Tirloni -
irado furioso com tudo -
Leandro Cerqueira -
Lucas Timm LH -
Vinicius Lage