ApsaraDB for MongoDB:Introdução aos clusters sharded do MongoDB

Quando usar um cluster sharded?

Como determinar o número de shards e mongos?

Seleção da shard key

• Estratégias de sharding compatíveis com clusters sharded do MongoDB

  • O range sharding aceita consultas de intervalo baseadas na shard key.

  • O hash sharding distribui as gravações uniformemente entre os shards.

  • O tag aware sharding permite personalizar regras de distribuição de chunks.

    Nota

    • Como funciona

      1. Use sh.addShardTag() para definir a Tag A em um shard.

      2. Use sh.addTagRange() para definir a Tag A em um intervalo de chunks de uma coleção. O MongoDB garante então que o intervalo de chunks com a Tag A, ou um superconjunto desse intervalo, seja distribuído no shard com a Tag A.

    • Cenários

      • Defina tags de data center em shards implantados em diferentes data centers. Isso distribui dados de diferentes intervalos de chunks para os data centers especificados.

      • Defina tags de nível de service em shards com diferentes capacidades de service. Isso distribui mais chunks para shards com maior capacidade.

    • Observações

      O ApsaraDB for MongoDB não distribui chunks diretamente para nós de shard rotulados com as tags especificadas. Os chunks se distribuem gradualmente à medida que operações de inserção e atualização acionam frequentemente a divisão e migração de chunks. Certifique-se de que o balancer esteja ativado durante o processo de distribuição. Após adicionar tags aos intervalos de chunks, os dados gravados podem não ser distribuídos imediatamente para o nó de shard que possui as mesmas tags dos intervalos.

• Problemas que o range sharding e o hash sharding não resolvem

  • O intervalo de valores da shard key é muito pequeno. Por exemplo, se você usar um data center como shard key, o sharding não será eficaz porque geralmente há poucos data centers.

  • Um valor específico de shard key está presente em muitos documentos. Isso pode levar a um único chunk superdimensionado, conhecido como jumbo chunk, que afeta a migração de chunks e o balanceamento de carga.

  • Consultas e atualizações baseadas em um campo que não é shard key tornam-se consultas scatter-gather, que são ineficientes.

• Características de uma boa shard key

  • Cardinalidade suficiente

  • Gravações distribuídas uniformemente

  • Evite consultas scatter-gather (leituras direcionadas).

Exemplo:

Uma aplicação IoT usa uma instância de cluster sharded para armazenar logs de milhões de dispositivos. Cada dispositivo envia logs para a instância do cluster sharded uma vez a cada 10 segundos. Os logs contêm informações como IDs de dispositivos e timestamps. Os logs gerados para um dispositivo específico em um determinado intervalo de tempo são consultados frequentemente.

Requisição de consulta: Consulta logs de um dispositivo específico dentro de um intervalo de tempo especificado.

• (Recomendado) Método 1: Use uma shard key composta por ID do dispositivo e timestamp com range sharding.

  • As gravações se distribuem uniformemente entre vários shards.

  • Os dados do mesmo ID de dispositivo também se distribuem entre vários chunks com base no timestamp.

  • As consultas por intervalo de tempo e ID de dispositivo podem ser concluídas diretamente usando o índice composto (deviceId, timestamp).

• Método 2: Use o timestamp como shard key com range sharding.

  • Novas gravações possuem timestamps consecutivos e são todas enviadas para o mesmo shard, causando distribuição desigual de gravações.

  • Consultas por ID de dispositivo são dispersas para todos os shards, o que é ineficiente.

• Método 3: Use o timestamp como shard key com hash sharding.

  • As gravações se distribuem uniformemente entre vários shards.

  • Consultas por ID de dispositivo são dispersas para todos os shards, o que é ineficiente.

• Método 4: Use o ID do dispositivo como shard key com hash sharding.

  Nota

  Se o ID do dispositivo não tiver um padrão óbvio, use range sharding.

  • As gravações se distribuem uniformemente entre vários shards.

  • Os dados do mesmo ID de dispositivo não podem ser subdivididos e só podem ser distribuídos para um único chunk. Isso causa jumbo chunks. Consultas por ID de dispositivo são enviadas para um único shard. Depois que a requisição é roteada para esse shard, uma consulta de intervalo baseada no timestamp exige uma varredura completa da tabela e uma ordenação.

Jumbo chunk e tamanho por chunk

O tamanho padrão por chunk em uma instância de cluster sharded é de 64 MB. Se o tamanho de um chunk exceder 64 MB e o chunk não puder ser dividido, ele receberá o rótulo de jumbo chunk. Por exemplo, se todos os documentos tiverem o mesmo valor de shard key, esses documentos serão armazenados no mesmo chunk, que não poderá ser dividido. O balancer não consegue migrar jumbo chunks, o que pode causar desequilíbrio de carga. Recomendamos evitar a formação de jumbo chunks.

Sobre o balanceamento de carga

Um thread em segundo plano executado nos nós mongos da instância implementa o balanceamento automático de carga em uma instância de cluster sharded. Apenas uma tarefa de migração pode ser executada por coleção em um determinado momento. O balanceamento de carga é acionado com base no número de chunks por coleção em cada nó de shard. Se a diferença entre o número de chunks de uma coleção em um nó de shard e o número total de chunks da coleção atingir o limiar especificado, o ApsaraDB for MongoDB inicia a migração dos chunks da coleção desse nó de shard para outros nós. Defina um limiar com base no número total de chunks.

use config
                db.settings.update(
                { _id: "balancer" },
                { $set: { activeWindow : { start : "02:00", stop : "06:00" } } },
                { upsert: true }
                )
            

sh.stopBalancer()            

Configuração de arquivamento no comando moveChunk

Se uma instância de cluster sharded executar o MongoDB 3.0 ou anterior, o uso de espaço em disco no catálogo de dados pode continuar aumentando mesmo após a interrupção das gravações de dados.

Esse problema é causado pelo item de configuração sharding.archiveMovedChunks, cujo padrão é true no MongoDB 3.0 e anteriores. Essa configuração significa que, durante uma operação moveChunk, o shard de source arquiva os dados do chunk migrado para fins de recuperação. Como resultado, quando um chunk é migrado, o espaço em disco no nó de source não é liberado, enquanto o nó de destino utiliza novo espaço em disco.