none
Hospedar arquivos de aplicação no servidor de banco de dados RRS feed

  • Pergunta

  • Ola Prezados, boa tarde!

    Essa semana ocorreu uma situação um pouco inusitada aqui no meu trabalho. Dois analistas sugeriram hospedar os arquivos de uma aplicação WEB no servidor de banco de dados. Ou seja, todo o HTML, CSS, JavaScript e imagens ficam no servidor de banco de dados e é lido pelo servidor de aplicação. Questionei esta arquitetura, pois não me parece usual e nem muito menos eficiente. Acredito que isto pode comprometer o servidor de BD, haja visto frequentemente temos lentidão por causa do alto processamento.

    A justificativa dos analistas é de que no servidor BD possui um servidor de réplica com DFS. Eles alegam que os arquivos vão estar em alta disponibilidade e com balanceamento de acesso. 

    O servidor de aplicação WEB também possui um servidor de réplica.

    Eu argumentei que os arquivos de um  site WEB são estáticos. Uma vez que os arquivos são publicados nos dois servidores de aplicação, não haveria motivo para haver DFS.

    O que vocês pensam sobre esta situação? Meu ponto de vista está correto?

    Abraços,

    terça-feira, 15 de março de 2016 18:58

Respostas

  • Tudo vai depender do volume de dados e utilização de recursos de cada um. O banco de dados pode gerar alto consumo de processamento e de memória, caso seja um banco de dados grande e com consultas complexas. Já os arquivos estáticos, se em grande número (imagens pesadas), podem causar algum tipo de lentidão principalmente se houver pouca banda disponível.

    Réplica com DFS, alta disponibilidade e com balanceamento de acesso ajudam nessa tarefa, bem como implementação de Cache, compactação Gzip, Minify de arquivos CSS e JS, otimização de imagens, etc.

    Seria interessante avaliar este caso com dados de utilização de recursos, como processamento, memória e banda.

    Já trabalhei em aplicações onde só existia um server para banco de dados e dois para a aplicação (arquivos estáticos junto com a aplicação) e a aplicação ainda ficava lenta por ser muito complexa, enquanto que o banco de dados respondia bem mais rápido.

    quarta-feira, 16 de março de 2016 03:15
  • Max

    O ideal é que o servidor de banco de dado trate apenas dados. A leitura de disco e processamento de banco de dados é muito pesado, mesmo parecendo que não. 

    O servidor web é mais indicado ter os arquivos ou então ter um outro servidor (mesmo que virtual) para tratar arquivos e imagens. O problema é que se dividir muito e houver muitos pontos de falha, para descobrir a falha pode demorar mais do que o normal.

    A empresa que trabalhava dividiu em servidor web, servidor de dados e servidor de arquivos. Mas no meio disso tudo tinham roteadores ruins, para ler o arquivo no servidor de arquivos direto do servidor web era um custo muito maior do que estando no servidor web.

    Servidor web e arquivo podem ficar juntos (mesmo que virtualmente).

    Servidor de banco de dados melhor ficar separado de tudo além de ter acesso rápido.


    Espero ter ajudado. Se ajudei, favor marcar no fórum falando que foi útil.

    Mauricio Junior - Comunidade www.ecode10.com

    quarta-feira, 16 de março de 2016 14:07

Todas as Respostas

  • Tudo vai depender do volume de dados e utilização de recursos de cada um. O banco de dados pode gerar alto consumo de processamento e de memória, caso seja um banco de dados grande e com consultas complexas. Já os arquivos estáticos, se em grande número (imagens pesadas), podem causar algum tipo de lentidão principalmente se houver pouca banda disponível.

    Réplica com DFS, alta disponibilidade e com balanceamento de acesso ajudam nessa tarefa, bem como implementação de Cache, compactação Gzip, Minify de arquivos CSS e JS, otimização de imagens, etc.

    Seria interessante avaliar este caso com dados de utilização de recursos, como processamento, memória e banda.

    Já trabalhei em aplicações onde só existia um server para banco de dados e dois para a aplicação (arquivos estáticos junto com a aplicação) e a aplicação ainda ficava lenta por ser muito complexa, enquanto que o banco de dados respondia bem mais rápido.

    quarta-feira, 16 de março de 2016 03:15
  • Entendo.

    O problema é que o servidor de banco de dados está sobrecarregado. Trabalhando com 95% de utilização de memória e acima de 90% de leitura de disco. Os clientes reclamam constantemente de lentidão.

    Enquanto isso o servidor de aplicação está com 5% de leitura de disco e em torno de 40% de consumo de memória.

    Acredito neste caso, esta arquitetura está sendo mais prejudicial do que útil.

    Abraços,

    quarta-feira, 16 de março de 2016 11:12
  • Max

    O ideal é que o servidor de banco de dado trate apenas dados. A leitura de disco e processamento de banco de dados é muito pesado, mesmo parecendo que não. 

    O servidor web é mais indicado ter os arquivos ou então ter um outro servidor (mesmo que virtual) para tratar arquivos e imagens. O problema é que se dividir muito e houver muitos pontos de falha, para descobrir a falha pode demorar mais do que o normal.

    A empresa que trabalhava dividiu em servidor web, servidor de dados e servidor de arquivos. Mas no meio disso tudo tinham roteadores ruins, para ler o arquivo no servidor de arquivos direto do servidor web era um custo muito maior do que estando no servidor web.

    Servidor web e arquivo podem ficar juntos (mesmo que virtualmente).

    Servidor de banco de dados melhor ficar separado de tudo além de ter acesso rápido.


    Espero ter ajudado. Se ajudei, favor marcar no fórum falando que foi útil.

    Mauricio Junior - Comunidade www.ecode10.com

    quarta-feira, 16 de março de 2016 14:07
  • Neste caso realmente não parece uma decisão sábia adicionar mais responsabilidade à um servidor com recursos esgotados.

    quarta-feira, 16 de março de 2016 15:14