Mysql
 sql >> Base de Dados >  >> RDS >> Mysql

MySQL Cluster (NDB) vs MySQL Replication (InnoDB) para aplicativos Rails 3:prós/contras?


Há uma boa comparação do InnoDB e do MySQL Cluster (ndb) postado recentemente nos documentos... vale a pena dar uma olhada:http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster-compared.html

A arquitetura do Cluster consiste em um pool de MySQL Servers que são acessados ​​pelo(s) aplicativo(s); esses servidores MySQL não armazenam os dados do cluster, os dados são particionados sobre o conjunto de nós de dados abaixo. Cada servidor MySQL tem acesso aos dados em todos os nós de dados. Se um servidor MySQL altera um dado, ele fica instantaneamente visível para todos os outros servidores MySQL.

Obviamente, essa arquitetura torna extremamente fácil dimensionar o banco de dados. Ao contrário do sharding, o aplicativo não precisa saber onde os dados são mantidos - ele pode apenas balancear a carga em todos os servidores MySQL disponíveis. Ao contrário do dimensionamento horizontal com a replicação do MySQL, o Cluster permite dimensionar gravações tão bem quanto leituras. Novos nós de dados ou servidores MySQL podem ser adicionados a um cluster existente sem perda de serviço para o aplicativo.

A arquitetura de nada compartilhado do MySQL Cluster significa que ele pode fornecer disponibilidade extremamente alta (99,999%+). Toda vez que você altera os dados, eles são replicados de forma síncrona para um segundo nó de dados; se um nó de dados falhar, as solicitações de leitura e gravação dos aplicativos serão tratadas automaticamente pelo nó de dados de backup.

Devido à natureza distribuída do MySQL Cluster, algumas operações podem ser mais lentas (por exemplo, JOINs que têm milhares de resultados provisórios - embora haja uma solução protótipo disponível que trata disso), mas outras podem ser muito rápidas e podem ser dimensionadas extremamente bem (por exemplo, chave lê e escreve). Você tem a opção de armazenar tabelas (ou até colunas) na memória ou no disco e escolhendo a opção de memória (com as alterações marcadas para o disco no fundo) as transações podem ser muito rápido.

O MySQL Cluster pode ser mais complexo de configurar do que um único servidor MySQL, mas pode evitar que você tenha que implementar sharding ou divisão de leitura/gravação em seu aplicativo. Baloiços e rotundas.

Para obter o melhor desempenho e escalabilidade do MySQL Cluster, talvez seja necessário ajustar seu aplicativo (consulte o white paper de ajuste de desempenho do cluster:http://www.mysql.com/why-mysql/white-papers/mysql_wp_cluster_perfomance.php ). Se você possui o aplicativo, isso normalmente não é grande coisa, mas se você estiver usando o aplicativo de outra pessoa que não pode modificar, isso pode ser um problema.

Uma nota final é que não precisa ser tudo ou nada - você pode optar por armazenar algumas de suas tabelas no Cluster e algumas usando outros mecanismos de armazenamento, esta é uma opção por tabela. Além disso, você pode replicar entre o Cluster e outros mecanismos de armazenamento (por exemplo, use o Cluster para seu banco de dados em tempo de execução e, em seguida, replique para o InnoDB para gerar relatórios complexos).