Monday, April 13, 2009

NDB Cluster: não existe milagre


Há algum tempo atrás eu estava comentando sobre o NDB Cluster no Twitter e o meu amigo @leandrod (referência em PostreSQL no Brasil) comentou que a persistência em disco do MySQL NDB Cluter é ruim. Eu discordo deste ponto de vista, acredito que ela é exatamente o que precisa ser para suprir a solução proposta. Claro que sim, tudo em tecnologia pode ser melhorado, mas do que jeito que este cluster se encontra, já pode ser utilizado em produção tranqüilamente (desde que, a sua necessidade se encaixe com o perfil de banco de dados MySQL, e com o NDB Cluster -- acho que não era necessário citar isso).

Na versão 5.0 e ancessores, a persistência do banco de dados era totalmente feita em RAM, indicando que este tipo de cluster não era confiável para dados importantes, poderia ser utilizado algo como um cache, talvez. Porem, a partir da versão 6.x isso mudou, além de todo o seu banco de dados (sim todo ele) ficar sempre disponível na RAM, ele também ganha persistência em disco.

Vamos raciocinar um pouco. Se todo o meu DB ficar disponível em RAM, quer dizer, que os meu servidores de NDB Cluster precisam ter memória o suficente para alocar tudo isso, porem, atente que não é cada servidor precisa de 10G (se o meu DB tem este tamanho). A RAM de cada servidor pode ser determinada por esta formula simples:

( ( Tamanho do DB × Número de Réplicas × 1.3 ) / Nós do cluster )

Então, vamos aos calculos (exemplo):

Tamanho da minha base de dados: 10G
Número de réplicas: 1
Quantidade de nós (nodes): 6

Portanto:

( 10 x 1 x 1.3 ) / 6 == 2.16G RAM

Agora já sabemos que o nossos servidores não vão consumir um absurdo de RAM, apenas o necessário.

Persistência em disco:

O NDB Cluster divide as requisições através dos seus nodes, onde cada um deles replica informações para os outros utilizando o daemon "ndbd". Cada um destes nós faz persistência em disco local periodicamente e, principalmente, quando o servidor estiver "idle", ou seja, sempre haverá disponibilidade para processar as chamadas da sua aplicação. O fato de fazer a persistência enquanto "idle" não indica falta de segurança neste processo, pelo contrário, o "ndbd" é capaz de detectar que um dos nós do cluster não está mais diponsível (através do controlador deste cluster e do processo de replicação) e assim ele forçar uma persistência regular (constante) dos dados.
Cálculos apontam que o NDB Cluster pode ficar até sem 40% de suas máquinas, mantendo a confiabilidade perfeita dos dados (mas este cálculo fica para um próximo post).

Bibliografia:

http://dev.mysql.com/doc/refman/5.1/en/faqs-mysql-cluster.html#qandaitem-23-10-1-11
http://dev.mysql.com/doc/refman/5.1/en/storage-requirements.html


Saturday, April 11, 2009

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.