Database Clustering – MySQL

icoDB_post

Introdução

O crescimento da audiência de um website obriga as equipes de manutenção evolutiva a buscarem constantemente formas de otimizar a aplicação e incrementar a capacidade de atender a demanda cada dia maior. Um dos pontos em que deve-se ter grande atenção é a capacidade da estrutura de banco de dados atender à demanda do dia-a-dia. Podem ser encontrados problemas de capacidade de leitura quando muitas requisições de consulta são feitas, e também problemas de gravação, quando é necessário gravar grandes volumes de dados.

Em certos momentos o grande vilão do banco de dados pode ser a grande quantidade de vezes que uma instrução simples é executada. Ou seja, apesar de uma consulta de forma individual ser realizada em tempo mínimo, praticamente instantâneo, em momentos de picos de acesso a mesma consulta pode ser realizada milhares de vezes, deteriorando assim o desempenho da aplicação como um todo.

Diante da necessidade de suprir a demanda crescente por acesso a dados e atender ao volume de gravações de registros no banco de dados de um cliente, iniciou-se uma busca por alternativas que tornassem viável atender à necessidade do cliente, tendo em mente um custo e um prazo razoáveis.  Abaixo são descritas as duas principais alternativas encontradas, considerando o cenário atual, que é de um banco de dados MySQL hospedado na estrutura de RDS da amazon.

1 – Réplica-Cópia

Esta abordagem é muito interessante para estruturas em que o volume de gravações é razoavelmente baixo e o volume de acesso a dados é grande. Neste tipo de abordagem podem ser configurados vários nós de leitura, o que torna a capacidade de resposta a consultas altamente escalável. Os dados ficam disponíveis em vários servidores diferentes, sendo replicados em poucos segundos do servidor master para os demais.  No entanto, a capacidade de gravação não é ampliada, pois continua a contar apenas com um servidor master em que são processadas todas as gravações de dados. Outro ponto desfavorável é a necessidade de alterações na aplicação, que deve, quando possível, ler os dados de um dos servidores de cópia e sempre gravar no servidor master.

Prós:

◆ Aumento da capacidade de leitura
◆ Aumenta a disponibilidade

Contras:

◆ Não incrementa a velocidade de leitura de forma considerável
◆ Não adiciona capacidade de gravação
◆ Obriga a alterar a aplicação

Figura 1 - Diagrama Réplica-cópia
Figura 1 – Diagrama Réplica-cópia

2 – Database Clustering (Data Partitioning)

Neste caso são adicionados diversos servidores onde os dados são consultados e gravados em paralelo. Além disso, é necessário adicionar um servidor que será responsável por controlar o fluxo de dados, distribuindo a carga entre servidores e sincronizando os dados entre todos os nós. Ele é usado também como ponto de conexão com a aplicação, tornando seu uso totalmente transparente para a aplicação, o que faz com que sua implementação não gere nenhuma mudança na forma da aplicação acessar os dados, seja para leitura ou gravação. Outro ganho possível é o aumento na velocidade das consultas, pois paralelamente as consultas são feitas nos vários servidores, dividindo o volume de dados consultados dentre as tabelas. Exemplo: numa tabela de 1 milhão de registros, caso tenhamos um banco simples, faremos a consulta de todas as tuplas.  Caso seja implementado um cluster com 5 servidores, essa consulta pode ser dividida em 5 consultas paralelas entre os servidores, ou seja, cada servidor analisa 200 mil tuplas, devolvendo o resultado para o servidor controlador que unifica os resultados e o devolve para aplicação.

Neste tipo de implementação cada um dos servidores possui todos os recursos reservados apenas para si, como memória e discos de forma individualizada. Assim não existe concorrência no acesso aos recursos entre servidores. Este tipo de arquitetura é conhecida como shared-nothing. Este isolamento garante que a falha de um nó não ocasione problemas para outro servidor, garantindo assim uma estrutura com alta disponibilidade.

Prós:
◆ Consultas paralelizadas, ao mesmo tempo cada servidor atende a uma requisição
◆ Incremento de capacidade de Leitura
◆ Aumento na velocidade de resposta a Consultas
◆ Adição de capacidade de Gravação
◆ Transparente para Aplicação

Contras:

◆ Necessário recriar Banco e tabelas no MySQL
◆ Não é suportado pela versão community do MySQL
◆ Necessário o uso de um servidor adicional para controle
◆ Custo elevado se comparado a implementações baseadas em apenas 1 servidor

Figura 2 - Clustering
Figura 2 – Clustering

Conclusão

Apesar do banco de dados MySQL ser considerado simples e indicado apenas para aplicação com pouca carga e pouco volume de acessos, é um banco de dados que oferece grandes possibilidades em sua versão licenciada, podendo ser implantado na maneira de cluster, sendo assim um banco altamente escalável e com um custo interessante se comparado aos grandes nomes do mercado como Oracle, DB2 ou MS SQL.

Referências

http://www.mysql.com/products/cluster/

http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster.html

http://www.howtoforge.com/loadbalanced_mysql_cluster_debian

Por LUIZ COUTO

Postado em: 25 de julho de 2013

Confira outros artigos do nosso blog

[Webinar] Profile de aplicações Java com Oracle Mission Control e Flight Recorder

24 de julho de 2017

Danival Calegari

Criando Mocks de serviços REST com SoapUI

27 de junho de 2017

Monise Costa

Three laws that enable agile software development

09 de março de 2017

Celso Gonçalves Junior

Medindo performance de uma API REST

21 de fevereiro de 2017

Monise Costa

Deixe seu comentário