Gente, estou com uma aplicação hoje que utiliza java/struts/mysql.
A versão do mysql que estamos usando é a antiga 4.1 com MyISAM ( ai começa os problemas ), temos ao todo umas 150 tabelas na aplicação e algumas tem mais de 200 megas ( + de 150.000 registros). Ao todo o BD tem uns 700megas.
A aplicação em si, quando foi feita, não foi utilizado nenhum framework de persistência, assim, ocasionalmente ocorre inconsistência dos dados…
O servidor que a gente utilizava era um P4 2.8 com 2Gb de Ram e um HD Sata de 80Gb…
Depois de passar uns sufocos com a aplicação lenta a gente começou a usar dois servidores, separando a aplicação do Banco.
Hoje o BD roda num P4 2.8 com 1Gb de Ram e um HD Sata de 80Gb e o TOMCAT ficou rodando na maquina antiga…
O interessante é que depois de separado em 2 servidores, a aplicação não apresentou grande melhora no desempenho…
Alguém ja teve algum problema parecido?
Num BD desse porte, qual seria a solução para a aplicação/servidor ideal?
Opa…
Kra, existem alguns itens a ser analizados nessa história;
O hardware pra comportar um Aplication Server e um Banco de Dados, razoavel, esta TOTALMENTE fora da jogada;
Analizar como está o desempenho do servidor de aplicação;
Analizar como está o banco de dados, se não me engano o MySQL tem o MySQL adminstrator que mostra isso.
Depois da analálise dessas duas coisas, se estivesse tudo normal, eu começaria testando a app e como está o gerenciamento da persistência dela.
Quanto a utilização de frameworks, vale apena um estudo para migração.
O servidor está se portando bem… não temos muito problema com ele…
Toda vez que é executado uma consulta pesada, o MySQL demora pra executar a consulta e como a gente usa MyISAM, o Mysql da locked nas tabelas e nas consultas, e não faz mais nada até que a primeira consulta seja executada.
Não existe nenhum framework de persistência… No sistema foi usado JDBC… sql mesmo… rsrs…
Não utilizamos tbm o padrão DAO… os SQLs foram colocados na grande maioria junto com as classes Forms… e algumas mais complexas ( como atualizações em grupos de tabelas, etc ) em um pacote Business…
Minha solução:
Compra um Servidor ‘SERVIDOR MESMO’;
Ai já dava pra juntar a APP + BD se for o caso dos custos;
E Sentaria com o chefe, e falaria como que tá a arquitetura da aplicação, e que ia necessitar repensar no sistema e aplicar os padrões.
OBS: Crerio que deve estar uma beleza pra dar manutenção nos sistemas em ?
mas… e o que é esse ‘SERVIDOR MESMO’ e é realmente melhor 1 servidor mesmo, ou 2 servidores ( 1 pra aplicação e outro pro BD)
outra coisa é a questão dos lockeds no MySQL… pois se continuar assim, não importa o quão bom seja o servidor, sempre vai ficar travando… entende? a tendência do BD é duplicar até ano que vem… e crescer cada vez mais… então se continuar assim daqui uns dias vai precisar de um prédio para os servidores… rsrsrs…
bom, vamos la ver se eu consigo ajudar, apenas conhecendo o q foi postado aqui…
eu acho a ideia de juntar o container e o sgbd equivocada…por uma serie de motivos, incluindo segurança, performance, etc…
vamos a solução do mundo ideial:
1 - ter um Servidor de verdade pro banco, esquece windows.
2 - ter um sgbd de verdade, o Oracle seria a melhor opção.
3 - fazer um trabalho de analise na arquitetura do sistema, e verificar a possibilidade de migração. Uma arquitetura J2EE de verdade pode ser uma possibilidade, aumentando a necessidade de um servidor melhor pro container.
4 - analisar o modelo do banco, verificar se ele esta ajudando na performance, poucas tabelas muito maiores q o resto me cheiram a desnormalização.
na real muito mais coisa tem q ser analizada…tem q ver ate q ponto isso esta realmnte prejudicando a empresa…pra poder convencer quem cuida da grana…q essas mudanças são necessárias…
A gente ta cogitando a idéia de migrar pra postgres…
mas ainda não é algo 100% certo… talvez a alternativa seja oracle mesmo…
[quote]3 - fazer um trabalho de analise na arquitetura do sistema, e verificar a possibilidade de migração. Uma arquitetura J2EE de verdade pode ser uma possibilidade, aumentando a necessidade de um servidor melhor pro container.
[/quote]
essa é a parte mais complicada…
porque pra gente fazer isso, nós pelo menos teríamos que ter o sistema “funcionando”, para que fosse possível ficarmos apenas voltados para desenvolver esse novo projeto…
e como o sistema é enorme, e surge coisas novas a serem feitas a cada dia, infelizmente creio q essa alternativa está longe pra acontecer…
mas é fato que uma hora a coisa vai tudo pro ar, a bomba estoura ai vai ter q ser feito por bem ou por mau… ( e quem cuida da grana não vai poder dizer que não foi avisado)
[quote]
4 - analisar o modelo do banco, verificar se ele esta ajudando na performance, poucas tabelas muito maiores q o resto me cheiram a desnormalização.[/quote]
isso tbm é preocupante, mas teremos que fazer tbm…
uma boa hora seria na migração do sgbd…
as alternativas que você passou foram ótimas grande…
tinhamos pensado algo parecido e tal há um tempo, mas fomos travados por uma série de motivos e serviços a serem feitos…
e mesmo agora o que querem da gente é arrumar uma solução “momentânea”… :???:
mas é bom estar ouvindo de você isso q a gente já tanto discutiu aqui…
Pedro, eu também acho a solução de juntar o BD + App num só, mas concordo contigo pela parte da segunrança.
Mas agora vamos ver pela realidade da empresa…
Pra empresa ter uma arquitetura dessas ai que o usuário está apresentando, você acha que eles “diretoria” tem interesse de documentar e estudar o que vai ser implementado?
Moro aqui na região, e geralmente quando chegam as DEMANDAS, (nem solicitação de alteração no projeto é) os clientes querem tudo pra ontem, e os patrões só repassam as pendências para os programadores e falam… isso é pra ontem…
Mas voltando a história da solução ideial…
Se a empresa não quis investir num Oracle, DB2, SQL Server da vida… e muito raro que eles vao querer investir agora, pq na mentalidade deles… “ta funcionando… entao ta bom”;
E pra finalizar nossa infeliz realidade…
– E por isso que cada dia mais os sistemas estao cada vez mais inseguros e lentos…
por isso q no meu post, a “solução” q eu propus, foi a do mundo ideal, por isso tb q no final eu disse q as reais necessidades da empresa teriam q ser avaliadas…
mas sendo um pouco mais realista, se hj eles ja tem 2 maquinas…a compra de um “servidor de verdade” na minha opinião, deveria ser feita apenas para abrigar o sgbd…SE eles mantivemrem o Tomcat, a maquina q ele descreveu no inicio suporta…
eh complicado esse tipo de situação, tentar equalizar as necessidades tecnicas com o budget disponivel, e ate conseguir convencer os executivos da necessidade do invenstimento em tecnologia…q tb tem q ser feito com muito cuidado…
agora meu caro Elison…acho q mudar para o PostgreSQL nao vai mudar muita coisa nao…dentro das dificuldades q vc passou…acho q a primeira melhoria, seria uma analise em cima do modelo do banco…tunning do modelo mesmo…talvez ate a contratação de um especialista seria indicada…depois disso, a aquisição de um bom servidor e do Oracle, acredito eu ser o próximo passo…por causa do cenario atual q pelo visto ja eh critico, e tb pela previsão de crescimento…
isso ja deve ajudar, mas a melhoria e modernização do sistema tb deve ser levado em conta…como vc mesmo disse, eh constante a manutenção desse sistema atual…um sistema com uma arquitetura consistente e atual, com certeza iria diminuir isso, baixando os custos…
agora conseguimos nos entender…
Esse é um problema sério e precisa ser conversado muito bem conversado com a diretoria… quanto ao tomcat… 60 acessos concorrentes eu acho tranquilo pra um P4 segurar…
Mas… acho que o estado d urgencia seria a app que teria que passar por uma reforma total, sendo testada de modulo em modulo ao processo de reorganização…
com certeza ajudou e muito esse bate-papo… o difícil agora é acertar a coisa toda…
mas valew pela ajuda…
mas tenho uma outra perguntinha ( não sei se vem ao caso ou se aqui é o lugar ideal)… rsrsrs…
tipo, no caso do BD em MyISAM, se for convertido pra InnoDB ( que segundo andei pesquisando é bem melhor) há o risco de perda de dados, ou incompatibilidade de tipos??
Creio eu que não… na verdade o MyISAM é uma estrutura otimizada para consultas, e InnoDB é pra o CRUD em geral, vai vc tem que ver como vai ficar as coisas ai, e adequar
também acredito que não haverá problemas…porém como qq processo de mudança deve ser feito com muito cuidado…com o banco parado, backup completo, etc…
na própria instalação do mySQL existe a opção de instalação, myISAM eh utilizado quando o mySQL eh usado como um datawarehouse…para aplicações de BI q efetuam praticamente só consultas pesadas…no seu caso a melhor opção eh innoDB mesmo…
