MySQL NDB Cluster

Introdução:

É uma tecnologia que provê clustering de databases em principalmente memória RAM, e com persistência em disco, sobre ambiente "shared-nothing", esta arquitetura permite que um sistema trabalhe de uma maneira pouco onerosa para o hardware, apenas, com um mínimo de requisitos específicos.

MySQL Cluster é designado para eliminar os pontos únicos de falha. Por esta razão, de cada componente é esperado ter seus próprios elementos básicos (disco, memória, CPUs), ou seja, o uso de mecanismos para compartilhamento de informações como storages, NFSs, SANs, não são recomendados para este tipo de arquitetura.

O cluster consiste em uma série de computadores, cada um rodando um ou mais processos que podem ser um MySQL Server, "data node", um "management server" e possivelmente programas específicos para acesso aos dados do cluster. A relação entre estes componentes pode ser visto na figura abaixo:



Todos estes programas trabalham juntos para formar um MySQL Cluster. Quando os dados são guardados em um storage engine -- motor de armazenamento, se preferir -- NDBCLUSTER, as tabelas estão alocadas nos data nodes. Cada tabela é diretamente acessível de todos os outros servidores neste cluster, se uma aplicação alterar (INSERT, UPDATE, DELETE), todos os outros nós do cluster terão esta alteração imediatamente.

Os dados armazenados nos data nodes são "espelhados" pelos outros nodes; o cluster pode gerenciar falhas dos seus servidores sem impacto sobre a consistência dos dados, este é apenas sensível (depende também do seu setup) ao desempenho do cluster. Outro ponto que pode haver problemas são nas transações, pois, o node que falhou poderia estar gerenciando uma delas, porem, este não deve ser um ponto de extrama preocupação, porque a sua aplicação deverá tratar este tipo de situação adversa.

Casos de uso:

Esta solução não é simplesmente a melhor a ser aplicada para todos os casos. Temos que lembrar que a replicação no MySQL é algo muito simples e resolve quase muitos casos onde escalabilidade é a temática central. Veja onde o NDB Cluster é recomendado:

• Aplicações que terão crescimento horizontal, tanto para leitura como para escrita;
• Arquiteturas onde o tempo de downtime é crucial no servidor de escrita, ou seja, você não tem tempo para eleger um SLAVE como um novo MASTER, se uma "tragédia" acontecer;

Onde ele não é recomendado:

Sistemas onde o uso de chave estrageira não pode ser suprimido pela aplicação. Podemos imaginar que você usa um software de código-fonte fechado e não pode, simplesmente, implementar este recurso;

Devo lembrar também que subir uma estrutura com estas características não é algo trivial, existem muitos pequenos detalhes a considerar. Se para o seu caso isso é um problema, repense a idéia da replicação, apesar de simples, ela é muito flexível, existem "N" maneiras de replicar um banco de dados MySQL sem perder desempenho e com um tempo de resposta muito baixo.

Considerações a respeito de tecnologia:

MySQL é um banco de dados confiável e robusto, porem, quando nós queremos que ele seja solução para um ambiente de grande porte, nem sempre é simples cumprir esta tarefa, assim como não seria ao fazê-lo com um de seus concorrentes (Oracle, PostreSQL, etc).

Na sua concepção, ele foi criado para ser um banco de dados disponível e de manipulação fácil para todos os possíveis usuários, e por este motivo, ele não vem com um belo tuning para high-concurrency, todo este trabalho deve ser feito pelo seu DBA (Sim, senhor! Com o MySQL a figura do DBA é necessária também.).

Para ter uma solução eficiente, você deve considerar todos os fatores envolvidos e escolher a melhor ferramenta para o pior problema, lembrando que não existe bala-de-prata quando falamos de tecnologia.

Bibliografia:

http://forums.mysql.com/read.php?12,100670,100670
http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster-glossary.html

Acho este assunto polêmico? Espero seu comentário.