Escalando o MySQL em projetos de sistemas

[Mário Monteiro 179]

Escalando o MySQL em projetos de sistemas

 

Autor: Wagner Bianchi

 

Após algum tempo pesquisando sobre o assunto e participando de muitas consultorias para empresas cujo ambientes apresentam problemas graves referentes à escalabilidade e à alta-disponibilidade, conceitos conhecidos respectivamente por scalable ou scale-out e high-available ou high-availability, decidi iniciar a escrita de alguns artigos que tratarão desde de assuntos relacionados à maior disponibilidade dos dados para aplicações até os problemas de performance mais conhecidos e mais encontrados que, mesmo que o time já saiba que serão vistos no futuro, não se importa em evitá-los.

 

Escalabilidade é o suporte e a capacidade que é atribuída a um sistema de crescer de acordo com a expansão dos negócios, ou seja, ele é implementado já visando os possíveis problemas e antevendo suas resoluções imediatas e ágeis. Dar ao sistema a possibilidade de acompanhar o crescimento dos negócios, além de ser uma estratégia de alinhamento, é dar escalabilidade ao ambiente (BIANCHI, 2007).

 

Desde muito tempo a informação transacionada (toda a informação que é manipulada para produzir resultados em um sistema de informação, seja ele ERP, CRM, BPM, EDI...) que se apresenta em forma de input e outpt em sistemas de informações, estes que estão localizados no lado interno e externo atrelado às empresas, tem despertado grande atenção, direcionando sobre estes os principais holofotes de toda a cadeia de produção e geração de receita de uma organização, esta que, por sua vez, direcionará suas principais estratégias apoiadas em um alinhamento pré-existente entre estes sistema de TI ou TIC com os negócios. Existem sistemas que possuem sua abrangência restrita a um controle de estoque fracionado, por exemplo, ou mesmo aqueles que têm seu foco voltado para operações globais, geralmente sendo executado na web - que podem ser sistemas participantes da onda chamada cloud computing.

 

Imagine um sistema sendo acessado por todo o território nacional (o que é um exemplo hipotético, pois poderá ser acessado por qualquer lugar do mundo, sendo este na web), executando vários processos entre o servidor de bancos de dados e o sistema operacional. No início tudo são flores, pois, ainda que eu já tenha algum movimento, o sistema ainda está pequeno, com poucas funcionalidades e gerando pouco resultado. Como sabemos, os administradores e pessoas interessadas no projeto (que são os stakeholders) sempre visarão o crescimento econômico e, por consequência, um aumento significativo de tempos em tempos das funcionalidades dos sistemas que atendem a esta demanda. Resultado: caso o time não esteja alinhado com as propostas e os desejos da alta diretoria e com o staff, quando o resultado esperado chegar, é hora de mais um desafio: escalar o servidor de bancos de dados para que este suporte um grande volume de transações e requisições sem que isto esteja previsto. Tenho um grande amigo que diria nesse momento que "passaremos a contar com magia negra", devido à complexidade de se concretizar feitos não planejados de forma pontual.

 

Atualmente as empresas têm se comportado de maneira a visar mais o lucro do que "time especializado"; não são todas elas que possuem esse comportamento ou perfil, mas a grande maioria. O que seria um time especializado? Conheço empresas que estão atualmente operando com 1 (um) DBA e vários desenvolvedores e, assim, estão passando por vários problemas, a começar pela comunicação, passando pela falta de liderança e finalizando na falta de experiência no assunto ou mesmo competência e habilidades técnicas. Como o foco desse artigo é mesmo o banco de dados MySQL, vamos aos problemas encontrados e comentários sobre os mesmos.

 

O profissional que trabalha com servidores de bancos de dados precisa conhecer muito sobre os processos de software do seu cliente a ponto de sugerir melhorias e dar mais foco aos processos de fluxo e manipulação da informação. As decisões são muito pontuais e requerem conhecimento amplo sobre a tecnologia que é aplicada e, também, no caso de planejar novos projetos.

 

Voltando à concepção dos sistema, um projeto de sistema que é iniciado atualmente necessita ter um projeto que contemple situações de escalabilidade do servidor de bancos de dados (crescimento com boa performance, dando suporte ao crescimento do negócio), este que com o passar do tempo poderá contar com vários problemas relacionados com performance (fragmentação dos dados, acumulo de dados e por consequência reposicionamento de índices em consultas, estatísticas de objetos e linhas desatualizadas e falta de várias configurações pontuais), assim como problemas relacionados à falta de escala.

 

Ao iniciar a escrita de um sistema, você deverá prever os seguintes pontos:

 

* Qual será o perfil da aplicação?

* Mais leituras, mais escritas, misto?

* Quais são os métodos ou motores de armazenamento (Storage Engines - MySQL)?

* Suas operações prevêem uma movimentação muito grande?

* Suas classes (código PHP, JAVA ou .NET) suportam ler dados em um servidor B e escrever dados em um servidor A?

* Existe um padrão de boas práticas para a escrita de consultas SQL?

* Existe um padrão de nomenclatura para colunas, tabelas e procedimentos armazenados (Stored Routines, no MySQL)?

 

Esses são alguns dos pontos que precisamos nos atentar para iniciar a escrita de uma aplicação que se conectará à servidores de bancos de dados, não só MySQL.

 

Estudo de Caso

 

Atualmente, estou atuando em uma consultoria como especialista em servidores de bancos de dados MySQL em uma instituição muito conservadora, que tem suas operações e processos voltados para o mercado financeiro. A aplicação foi escrita há algum tempo e, por coincidência, nenhum dos pontos acima foram previstos aos iniciar o projeto. Hoje em dia, o servidor de bancos de dados MySQL tem sofrido muito por falta de planejamento no design do modelo de dados até a falta de padrões da aplicação. Aí, gráfico pra lá, gráfico pra cá e nada de encontrar o gargalo do ambiente de tecnologia. Além disso, ainda rodam uma versão mais antiga do SGBD Open Source mais utilizado do mundo que não provê tanto controle do comportamento do mesmo.

 

Um dos pontos identificados e aconselhado ao cliente foi a migração para uma versão mais atual do MySQL e a busca da divisão de leituras e escritas, implementando dois servidores de bancos de dados - um deles seria o MASTER e outro seria o servidor SLAVE, mantendo tais servidores em replicação através dos recursos do próprio MySQL. O motivo pelo qual nos leva a dividir leituras e escritas é que, nesse caso especial, existem consultas de leitura de dados que recuperam dados para fomentar relatórios que manipulam cerca de 100.000.000 linhas distribuídas por várias tabelas, processo este que consome grande parte dos recursos da máquina trazendo grande lentidão ao executar outras queries que têm mais importância para o negócio, como, por exemplo, a aprovação de um contrato.

 

Tal divisão de leituras e escritas não foi prevista anteriormente (a replicação entre servidores de bancos de dados MySQL pode ser implementada desde a versão 3.23 do MySQL). Resultado, um projeto interno à organização de reescrita da classe que trata da abstração com o banco de dados e outros pontos da aplicação terá que ser iniciado para atender a estas expectativas de escala para que o ambiente possa começar a crescer horizontalmente, este que eu particularmente acho bem mais interessante. O crescimento vertical somente faz adiar o problema, já que o negócio não para de crescer e já já não se terá mais espaço para tanto hardware.

 

Questões relacionadas com a implantação do MySQL Cluster em substituição ao modelo de replicação direta foram analisadas, mas a migração de versão do MySQL não é possível devido à disponibilidade da aplicação para os vários pontos de acesso mundo afora (deve ser 24/7), por se tratar de um projeto de longo prazo e de problemas com a reescrita de consultas com JOIN na aplicação, estas que não são compatíveis com versões mais recentes do MySQL.

 

Join sendo executada no MySQL 4.1:

mysql> select * from a, b left join c on a.a=c.c;
Empty set (0.00 sec)

Join sendo executada mo MySQL 5.0:

 

mysql> select * from a, b left join c on a.a=c.c;
ERROR 1054 (42S22): Unknown column 'a.a' in 'on clause'

Obs.: o problema acima poderá ser resolvido para gerar compatibilidade colocando um parênteses entre as tabelas que estão participando do INNER JOIN representado pela "," (vírgula). O resultado da consulta poderá variar e o seu plano de execução também (aquele que é visto através do EXPLAIN ou com o MaatKit). Recomendo a reescrita da consulta com base nos objetivos da mesma.

 

Entrando mais ainda no assunto técnico, quando encaramos o servidor de bancos de dados MySQL, acessando o mesmo através do MySQL Enterprise Monitor, que é a versão comercializada do MySQL, podemos visualizar o tamanho do sofrimento do mesmo em conjunto com os recursos da máquina (que digamos de passagem, são medianos se analisarmos proporcionalmente a quantidade de transações) e do sistema operacional. O MySQL possui uma dificuldade para as trocas de contexto ou mesmo, a recriação de threads em sistemas operacionais Linux, processo este que é muito caro e é efetuado com a troca constante de mensagens entre o processo pai do servidor de bancos de dados (mysqld) e o kernel do sistema operacional. Esse é um dos problemas que podem agravar e muito os problemas relacionados com a falta de um profissional realmente gabaritado na equipe. Falaremos em outro artigo como efetuar a configuração da criação de threads e como o MySQL as utiliza para dar suporte às suas operações internas.

 

 

Conclusão

 

No próximo artigo, mostrarei como pensar a aplicação para a escalabilidade logo no início do projeto, com a linguagem PHP e servidores de bancos de dados MySQL. Por enquanto, pense que todo sistema que é planejado deve ser pensado como um ativo que crescerá bastante em relação às suas funcionalidades e armazenamento de informação. Aqui estamos pensando o banco de dados, que é o MySQL, mas que tal pensarmos também no todo?

 

E, você, qual seria sua orientação para iniciar um projeto de sistema para grande movimentação? Quando o sistema virar um emaranhado de linhas em um carretel super embolado, a culpa será sua. Por outro lado, o sucesso da sua organização/empresa em atender os seus clientes de forma ótima, como boas práticas em TI, gerando riqueza, também será culpa sua.

 

De que lado você quer ficar?

 

Até a próxima.

 

Fonte: iMasters