Infraestrutura para banco de dados altamente simultâneo e de alta gravação

Meus requisitos são:

• 3000 Conexões
• 70-85% de gravação versus leitura

Atualmente, estamos maximizando uma instância extra grande de alta CPU com 700 conexões. Todos os 8 núcleos são maximizados. Achamos que é o número de conexões simultâneas, pois a memória está boa. A gravação em si é muito simples (validações tornam as coisas lentas). Para escalar para 3000, precisamos acessar vários servidores, opções atuais:

• Sharding do MySQL
• Cluster do MongoDB
• Cassandra
• Hadoop e MySQL (caches do Hadoop, despejo único para o MySQL)
• MongoDB e MySQL (em vez do Hadoop, usamos o mongo para cache)

Para lidar com esse número de conexões, várias perguntas:

1. O MySQL Sharding pode lidar com as conexões simultâneas?
2. Qualquer mestre único pode lidar com essas conexões simultâneas ou um cabeçote múltiplo como o Mongo é uma opção melhor?

Peço desculpas se não estou descrevendo bem o meu problema. Por favor, faça perguntas.

Se você estiver usando o MySQL como o banco de dados principal, convém considerar o uso de uma topologia em estrela via replicação do MySQL.

Agora, antes que você diga UGHHH, ROFL e OMG para replicação do MySQL, ouça.

Uma topologia em estrela permite gravar em um servidor de banco de dados (chamado Distribution Mster [DM]) e enviar os comandos SQL para vários servidores de banco de dados. Como você configura essa infraestrutura de banco de dados?

Aqui está a descrição

Você possui 5 servidores de banco de dados (servidor A, B, C, D, E)

Servidor A

• Na configuração de replicação do MySQL, será o mestre
• Desempenha um papel especial como o Mestre
• Mestre dos servidores B, C, D, E
• Todas as tabelas usam o mecanismo de armazenamento BLACKHOLE (/ dev / null)
• Armazena apenas logs binários
• Máquina de metal nua
• Benefícios
  • Gravações muito rápidas, pois todas as tabelas no DM usam BLACKHOLE
  • A latência da rede é um problema menor, pois as leituras representam de 15 a 30% da atividade do banco de dados
  • Todos os escravos são atualizados estritamente a partir do DM

Servidores B, C, D, E

• Escravo de A
• Servidor base para SELECTs pesados
• O servidor pode ser virtual ou bare metal
• Para todos os servidores cujas tabelas de usuários usam o mecanismo de armazenamento InnoDB
  • Pode ser um servidor como um DB Server em espera quente
  • Backups não intrusivos podem ser executados contra ele
• Para todos os servidores cujas tabelas de usuários usam o mecanismo de armazenamento MyISAM
  • Configurar com oprion somente leitura
  • As tabelas podem ter seus formatos de linha refeitos para acelerar leituras

Já escrevi posts sobre isso antes

• /server/264374/mysql-in-star-topology/264444#264444
• /programming/5273043/mysql-in-star-topology/5781504#5781504

Para manter a replicação do MySQL na melhor forma

• Use o MySQL 5.5
• Usar replicação semissíncrona
• Ajuste o InnoDB para envolver mais CPUs

O MySQL Cluster pode ser outra abordagem para sharding. Confira o post aqui .

Também sou um grande fã de Cassandra, mas isso depende muito do seu modelo de dados e das consultas que você deseja executar. Cassandra é rápida em gravações, porque elas são sempre seqüenciais no disco.

Se você estiver indo para várias cabeças (o que você provavelmente precisará se realmente precisar de conexões ativas em 3K), provavelmente eu olharia para Riak ou talvez Cassandra. Depende realmente do que o seu aplicativo faz e do quanto eles se encaixam, mas pelo que você descreveu, acho que ele se encaixaria em algo como o Riak.

Dito isto, uma abordagem fragmentada parece bastante factível, se você puder encontrar uma boa maneira de segmentar os dados e minimizar qualquer necessidade de coisas com shard cross. Eu ficaria longe de qualquer coisa de anel / estrela / mmm no mysql e me ateria ao sharding direto. Na verdade, se você estiver disposto a usar o Postgres, poderá criar protótipos com bastante facilidade usando esquemas em algo como heroku e, em seguida, dividir e dividir os bancos de dados quando eles começarem a superar os nós individuais.

Ah, e embora eu ache que você possa tentar escalar algo assim verticalmente (nó único manipulando todos os conectores 3K), acho que não é possível fazê-lo na nuvem.

Se for uma opção para seu aplicativo específico, talvez você possa usar alguma maneira assíncrona para gravar dados no banco de dados (fila de trabalho, inserções em lote ...) e / ou mudar as muitas conexões de clientes do banco de dados com algum proxy à frente. .

Com o sharding, você pode escalar bem (2x db-servers == 2x conexões), mas isso depende muito da natureza do seu conjunto de dados e de como você pode dividi-lo entre os shards.

Pessoalmente, prefiro o MongoDB por sua facilidade de administração, escalabilidade e facilidade de uso geral. Além disso, a menos que eu realmente precise de um RDBMS, vou usar um no-SQL.

Com isso dito, escolha o banco de dados que faz mais sentido para o seu aplicativo. Se você precisar de Transações ou não puder criar seu aplicativo sem Junções (ou simplesmente faz mais sentido com elas), use um RDBMS (MySQL, PostGres, etc.)

Embora eu pessoalmente prefira o MongoDB, a idéia de que o MySQL não dimensiona ou não pode lidar com uma alta taxa de transações é puramente falsa. A equipe de engenharia do Facebook (e a equipe do MySQL dentro dela) entra em grandes detalhes. Verifique também o blog da equipe do Etsy Ops; eles também amam o MySQL.

Finalmente, eu não usaria o MongoDB para um cache do MySQL; use o Memcached para isso.

O Redis também é um armazenamento de valores-chave na RAM, bom para lidar com certos casos de uso. Existem algumas entradas de blog no blog.agoragames.com que descrevem alguns casos de uso.

Você também deve verificar o CouchDB se estiver pensando em No-SQL. Esteja ciente de que requer manutenção regular para manter a utilização do disco baixa. (Ele comercializa velocidade e conveniência para os utilitários de disco ...)

Finalmente, não é fácil prever o planejamento da capacidade. Você precisa testar o mais realista possível e estar preparado para remediar com base no que vê. Infelizmente "Ciência da Computação" é tanto arte quanto ciência.