Divulgação: Eu sou um funcionário do MySQL, trabalhando no MySQL Cluster.
Eu diria que o MySQL Cluster poderia alcançar maior taxa de transferência / host do que o MySQL + InnoDB fragmentado, desde que:
- As consultas são simples
- Todos os dados cabem na memória
Em termos de latência, o MySQL Cluster deve ter uma latência mais estável do que o MySQL fragmentado. A latência real para dados puramente na memória pode ser semelhante.
À medida que as consultas se tornam mais complexas e os dados são armazenados no disco, a comparação de desempenho se torna mais confusa. Para obter uma resposta mais específica, é necessário descrever mais sobre seu aplicativo e as consultas que você executa, bem como o número de hosts e o volume de dados. O MySQL Cluster ganhou recentemente a execução de consultas localizadas paralelas (AQL), o que significa que pode ser competitivo com o MySQLD independente, apesar de ter dados distribuídos por vários hosts.
O MySQL Cluster está atualmente limitado a 'sharding' em mais de 48 hosts. O MySQL fragmentado em teoria não tem limite. No entanto, para uma determinada taxa de transferência de destino, menos hosts do MySQL Cluster podem ser necessários que os hosts do MySQL fragmentados.
As diferenças mais interessantes são quando você olha para outras áreas além do desempenho:
- O MySQL Cluster suporta consultas arbitrárias em todos os shards
- O MySQL Cluster suporta transações arbitrárias em todos os shards
- O MySQL Cluster suporta replicação síncrona de shards com failover e recuperação automáticos
- O MySQL Cluster suporta adicionar nó online (expansão de cluster)
- MySQL Sharded é mais 'faça você mesmo'
Tendo o sharding incorporado no seu aplicativo, você oferece o potencial máximo de dimensionamento, mas adiciona complexidade e limita sua flexibilidade em termos de consultas e operações entre shard. Se o seu sharding for prematuro, pode ser a raiz de alguns problemas para você. O MySQL Cluster permite que você obtenha alguns dos benefícios do sharding sem precisar restringir seu aplicativo a ser shard único.
Em relação à resposta anterior, alguns esclarecimentos:
"Embora o MySQL Cluster seja uma reclamação contra ACID, ele não fornece um mecanismo de armazenamento adequado para dados com chaves compostas."
O MySQL Cluster suporta chaves primárias e secundárias compostas. Não tenho certeza do que não é 'adequado'. Talvez o pôster anterior possa explicar?
"Para ter dados com as mesmas características principais armazenadas em um conjunto específico de nós de dados, você pode fazer o seguinte:
- Coloque todos os nós de dados offline, deixando apenas os nós de dados que você deseja hospedar dados com as mesmas características principais.
- Carregue seus dados no MySQL Cluster, que preenche apenas os nós de dados selecionados
- Coloque todos os nós de dados online novamente "
Isto está incorreto. A distribuição de dados é independente de quais nós estejam online a qualquer momento. O MySQL Cluster suporta vários esquemas de distribuição de dados para suportar as otimizações que você descreve. Descrevo a distribuição de dados no MySQL Cluster em um post do blog aqui: Distribuição de dados no MySQL Cluster
