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


3 comments:

luismottacampos said...

Bom, como qualquer banco de dados sério em que eu meto a mão tem mais de um TB de dados, eu mantenho o contra-ponto e digo sempre: MySQL é um brinquedo e não deveria ser utilizado para nada que uma empresa considere de importância para o seu negócio.

Anonymous said...

Bom, o 5.1 ainda não está estável, como admitiu o Monty, apesar de três anos de desenvolvimento, dois de β e um de RC. Aliás, nem a 5.0, que nem sei quantos anos ainda.

Ah, e creio que o que falei é que o NDB impõe ainda mais limites aos já absurdos do MySQL.

Mariolando A. Santos said...

Bom dia, uso o mysql 5.0 com replicação a 2 anos em uma rede de pizzarias com sucesso, gostaria de implementar o cluster pois assim os nós podem trabalhar independentes, gostaria de saber quais são estes limites absurdos ?, e se possível um tutorial para configuração do cluster pois estou tendo problemas para configurar.