O que é o MongoDB Sharding e as melhores práticas?

Como escalar o MongoDB? Quais são as melhores práticas de sharding?


Embora o esquema flexível seja o modo como a maioria das pessoas se familiariza com o MongoDB, também é um dos melhores bancos de dados (talvez até o melhor quando se trata de aplicativos do cotidiano) para lidar com conjuntos de dados muito, muito grandes. Embora a justificativa desse argumento exija um artigo inteiro em si (espero encontrar um dia para ele algum dia!), A idéia geral é que as soluções baseadas em SQL não suportem sharding e desenvolvê-lo é uma porcaria..

O melhor que você pode esperar é criar um cluster (que não tem nada a ver com sharding fundamentalmente, por sinal) ou optar por uma solução gerenciada como o RDS da Amazon ou Cloud SQL do Google, que se tornam proibitivamente caros à medida que seus dados crescem.

Neste artigo, veremos uma das técnicas essenciais para dimensionamento horizontal do banco de dados: sharding, para MongoDB e recomende algumas práticas recomendadas para o mesmo. No entanto, acho melhor começar com o básico do sharding, porque muitas pessoas que desejam escalar o MongoDB podem não estar muito familiarizadas com ele.

Se você está ciente do sharding, sinta-se à vontade para percorrer a próxima seção.

Noções básicas de sharding

Você deve ter notado o uso da palavra “horizontal” no último parágrafo da seção anterior. Sem iniciar outro desvio maciço, quero abordar esse ponto rapidamente. O dimensionamento está considerando ser de dois tipos: você obtém uma máquina mais poderosa com maior capacidade de armazenamento (vertical) ou você conecta vários computadores menores e forma uma coleção (horizontal).

Agora, considerando que mesmo os melhores servidores atualmente não têm mais de 256 GB de RAM ou 16 TB de disco rígido, você atinge uma parede de tijolos logo ao tentar escalar verticalmente (ou “escalar”, conforme a terminologia). No entanto, você pode conectar tantas máquinas individuais (pelo menos teoricamente) e contornar essa limitação facilmente.

Obviamente, o desafio agora é coordenar todas essas máquinas.

Fragmento de banco de dados

O termo “sharding” geralmente se aplica aos bancos de dados, com a idéia de que uma única máquina nunca pode ser suficiente para armazenar todos os dados. Ao compartilhar, o banco de dados é “dividido” em partes separadas que residem em máquinas diferentes. Um exemplo simples pode ser: suponha que uma empresa tenha máquinas que podem armazenar até 2 milhões de itens de dados do cliente. Agora, o negócio está atingindo esse ponto de interrupção e provavelmente ultrapassará 2,5 milhões de usuários em breve. Então, eles decidem dividir seu banco de dados em dois:

E magicamente, a capacidade do sistema agora é duplicada!

Bem, se a vida fosse assim tão simples! ��

Desafios no sharding de banco de dados

Assim que você estava pensando um pouco profundamente sobre o sharding, alguns desafios nefastos erguem sua cabeça feia.

Nenhuma chave primária

Assim que você sai de um único banco de dados, as chaves primárias perdem o significado. Por exemplo, se suas chaves primárias estiverem definidas para incremento automático e você mover metade dos dados para outro banco de dados, agora você terá dois itens de dados diferentes para cada chave primária.

Nenhuma chave estrangeira

Como não há suporte nos bancos de dados para apontar para entidades fora do banco de dados atual (bem, mesmo um banco de dados diferente na mesma máquina não é suportado, então esqueça um banco de dados em uma máquina diferente), o conceito de chaves estrangeiras é descartado. bem. De repente, o banco de dados se torna “burro” e a integridade dos dados é seu problema.

Erros de dados estranhos

Se uma única máquina for desativada, o usuário final poderá receber uma mensagem “Opa, algo quebrou!” página, que sem dúvida irritará, mas a vida estará no caminho certo depois de algum tempo.

Agora considere o que acontece em um banco de dados fragmentado. Suponha que o banco de dados fragmentado em nosso exemplo anterior seja um banco de dados bancário e um cliente esteja enviando dinheiro para outro. Suponhamos também que os dados do primeiro cliente residam no primeiro fragmento, enquanto os dados do segundo cliente residem no segundo fragmento (você vê para onde estou indo com isso ?!). Se a máquina que contém o segundo fragmento falhar, você pode imaginar em que estado o sistema estará? Para onde vai o dinheiro da transação? O que o primeiro usuário verá? O que o segundo usuário verá? O que os dois verão quando os fragmentos estiverem novamente online?

Gerenciamento de transações

Vamos considerar também o caso sempre crítico do gerenciamento de transações. Desta vez, suponha que o sistema esteja funcionando 100% bem. Agora, duas pessoas (A e B) fazem um pagamento para uma terceira (C). É muito provável que ambas as transações leiam o saldo da conta de C simultaneamente, causando essa confusão:

  • Saldo da conta de C = US $ 100.
  • A transação de A lê o saldo de C: US ​​$ 100.
  • A transação de B indica o saldo de C: US ​​$ 100.
  • A transação da A adiciona US $ 50 e atualiza o saldo: US $ 100 + 50 = US $ 150.
  • A transação de B adiciona US $ 50 e atualiza o saldo: US $ 100 + 50 = US $ 150.

Droga! US $ 50 desapareceram no ar!

Os sistemas SQL tradicionais salvam você disso, fornecendo gerenciamento de transações embutido, mas assim que você sai de uma única máquina, você está brindando.

É importante ressaltar que, nesses sistemas, é fácil encontrar problemas de corrupção de dados dos quais é impossível recuperar. Puxar o cabelo também não vai ajudar! ��

Fragmento do MongoDB

Para os arquitetos de software, a empolgação com o MongoDB não era tanto em seu esquema flexível, como em seu suporte a sharding integrado. Com apenas algumas regras simples e máquinas conectadas, você estava pronto para executar um cluster MongoDB fragmentado rapidamente.

A imagem abaixo mostra como isso fica em uma implantação típica de aplicativo da web.

Crédito da imagem: mongodb.com

A melhor parte do shard do MongoDB é que mesmo o balanceamento de shards é automático. Ou seja, se você tiver cinco shards e dois deles estiverem quase vazios, poderá dizer ao MongoDB para reequilibrar as coisas de uma maneira que todos os shards estejam igualmente cheios.

Como desenvolvedor ou administrador, você não precisa se preocupar muito, pois o MongoDB nos bastidores faz a maior parte do trabalho pesado. O mesmo vale para falha parcial dos nós; se você tiver conjuntos de réplicas configurados corretamente e em execução no cluster, as interrupções parciais não afetarão o tempo de atividade do sistema.

Toda a explicação seria breve, então encerrarei esta seção dizendo que o MongoDB possui várias ferramentas internas para fragmentação, replicação e recuperação, tornando muito fácil para os desenvolvedores a criação de aplicativos em larga escala. Se você deseja um guia mais abrangente sobre os recursos de fragmentação do MongoDB, o documentos oficiais é o lugar para estar.

Você também pode estar interessado neste guia completo do desenvolvedor.

Melhores práticas de fragmentação do MongoDB

Enquanto o MongoDB “simplesmente funciona” fora da caixa para fragmentar, isso não significa que podemos descansar sobre os louros. O sharding pode criar ou interromper seu projeto para sempre, dependendo de quão bem ou mal foi feito.

Além disso, há muitos pequenos detalhes a serem considerados, na falta dos quais, não é incomum ver os projetos entrarem em colapso. A intenção não é assustar você, mas destacar a necessidade de planejamento e ser extremamente cuidadoso, mesmo com pequenas decisões.

A chave Sharding inevitavelmente controla a fragmentação no MongoDB, por isso é ideal começarmos nossa pesquisa com esse.

Alta cardinalidade

Cardinalidade significa a quantidade de variação. Por exemplo, uma coleção de um país favorito de 1 milhão de pessoas terá baixas variações (existem tantos países no mundo!), Enquanto uma coleção de seus endereços de email terá (perfeitamente) alta cardinalidade. Por que isso Importa? Suponha que você escolha um esquema ingênuo que compartilhe dados com base no primeiro nome do usuário.

Aqui temos um arranjo bastante simples; o documento recebido é digitalizado em busca de nome de usuário e, dependendo de onde a primeira letra está no alfabeto inglês, ele cai em um dos três fragmentos. Da mesma forma, é fácil procurar um documento: os detalhes de “Peter”, por exemplo, estarão no segundo fragmento, com certeza.

Tudo parece bom, mas o ponto é que não controlamos os nomes dos usuários de documentos recebidos. E se obtivermos nomes na faixa de B a F na maioria das vezes? Nesse caso, teremos o que é chamado de pedaço “jumbo” no shard1: a maioria dos dados do sistema estará lotada lá, transformando efetivamente a configuração em um único sistema de banco de dados.

A cura?

Escolha uma chave com alta cardinalidade – por exemplo, o endereço de email dos usuários, ou você pode até escolher uma chave de fragmento composta, que é uma combinação de vários campos.

Mudando monotonicamente

Um erro comum no shard do MongoDB é usar chaves de aumento monotônico (ou aumento automático, se você desejar) como a chave de shard.

Geralmente, a chave primária do documento é usada. A idéia aqui é bem-intencionada, a saber, à medida que novos documentos continuam sendo criados, eles caem igualmente em um dos fragmentos disponíveis. Infelizmente, essa configuração é um erro clássico. Isso ocorre porque, se a chave do shard está sempre aumentando, depois que um dado de ponto começa a se acumular no lado de alto valor dos shards, causando um desequilíbrio no sistema.

Crédito da imagem: mongodb.com

Como você pode ver na imagem, quando ultrapassamos o intervalo de 20, todos os documentos começam a ser coletados no Chunk C, causando um monólito. A solução é optar pelo esquema de chave de sharding sharding, que cria uma chave de sharding, hash em um dos campos fornecidos e usando-o para determinar o pedaço.

Crédito da imagem: Mongodb.com

Uma chave de fragmento de hash é assim:

{
"_Eu iria" :"6b85117af532da651cc912cd"
}

. . . e pode ser criado no shell do cliente Mongo usando:

db.collection.createIndex ({_id: hashedValue})

Shard Early

Um dos conselhos mais úteis, direto das trincheiras, é estilhaçar cedo, mesmo que você acabe com um cluster pequeno de duas partes. Depois que os dados ultrapassam 500 GB ou algo assim, o sharding se torna um processo confuso no MongoDB, e você deve estar pronto para surpresas desagradáveis. Além disso, o processo de reequilíbrio consome quantidades muito altas de largura de banda da rede, o que pode sufocar o sistema se você não tomar cuidado.

Nem todo mundo é pró-sharding. Como um exemplo interessante (o aprendizado está realmente nos comentários), veja este belo Percona blogue.

Executando o Balanceador

Outra boa idéia é monitorar seus padrões de tráfego e executar o balde de fragmentos apenas em horários de baixo tráfego. Como eu já mencionei, o reequilíbrio requer uma largura de banda considerável, o que poderia levar rapidamente todo o sistema a um rastreamento. Lembre-se de que os fragmentos desequilibrados não causam pânico imediato. Apenas deixe o uso normal persistir, aguarde oportunidades de baixo tráfego e deixe o balanceador fazer o resto!

Veja como você pode fazer isso (supondo que você tenha pouco tráfego das 3 às 5 da manhã):

use config
db.settings.update (
{ _Eu iria: "balanceador" },
{$ set: {activeWindow: {start: "03:00", Pare : "05:00" }}},
{upsert: true}
)

Conclusão

Compartilhar e escalar qualquer banco de dados é uma tarefa complicada, mas felizmente o MongoDB o torna mais gerenciável do que outros bancos de dados populares por aí..

Houve um tempo em que o MongoDB não era a escolha certa para nenhum projeto (graças a vários problemas críticos e comportamentos padrão), mas eles já se foram há muito tempo. Juntamente com sharding, reequilíbrio, compactação automática, bloqueio distribuído em nível agregado e muitos desses recursos, o MongoDB chegou milhas adiante é hoje a primeira escolha do arquiteto de software.

Espero que este artigo tenha sido capaz de esclarecer o que é sharding no MongoDB e o que o desenvolvedor deve cuidar quando for escalar. Para saber mais, você pode obter este curso on-line para dominar o MongoDB.

TAG:

  • Base de dados

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map