MySQL Sharding vs MySQL Cluster

Considerando apenas o desempenho , um cluster do MySQL pode superar uma solução MySQL de fragmentação de dados personalizada? sharding = particionamento horizontal

Quando me refiro ao sharding, estou pensando em sharding feito na camada de aplicação, por exemplo, distribuindo registros igualmente entre instâncias independentes do MySQL. Para dois servidores, pode ser (chave mod 2).

mysql ndbcluster

— gsb
fonte

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

— Frazer Clement
fonte

Ei, Frazier. Eu li o link que você forneceu. Apenas para esclarecimento, meu comentário de 'chave composta' foi baseado em índices não exclusivos. A empresa de meu empregador testou o MySQL Cluster por volta do primeiro trimestre de 2007 e não gostou por causa do desempenho fraco. IMHO foram as más escolhas do cliente para chaves (pequenas cardinalidades) e suas consultas. O MySQL Cluster deve ter amadurecido mais desde então com base no seu link. Quanto à minha segunda declaração, é quantos usuários do MongoDB preenchem shards específicos. Alguns clientes do meu empregador fizeram isso com suas configurações personalizadas do MySQL.

— RolandoMySQLDBA

No seu link, ele mencionava 'uma verificação de índice ordenada' que não podia ser removida, pois não é garantido que as linhas correspondentes sejam armazenadas em um fragmento da tabela. É por isso que sugeri isolar os dados em fragmentos específicos (nós de dados) para minimizar os locais em que os dados se espalhariam. Como sua resposta traz o lado positivo do MySQL Cluster, ela se encaixa melhor na pergunta postada original. Minha resposta erra em favor de cautela, pessimismo e ser um pouco ingênua do poder do MySQL Cluster hoje.

— RolandoMySQLDBA

Em vez do meu delírio e delírio, +1 pela sua resposta !!!

— RolandoMySQLDBA

Olá Rolando, Obrigado por esclarecer suas declarações. É verdade que as verificações de índice ordenadas sem remoção são "caras" no Cluster, pois todos os nós de dados estão envolvidos. Parece que essas verificações com baixos índices de cardinalidade seriam caras em qualquer sistema, mas no Cluster elas se tornaram visivelmente caras. Sua cautela e pessimismo, sem dúvida, salvaram você mais de uma vez :) Obrigado pelo +1

— Frazer Clement.