Menu Docs

Página inicial do DocsDesenvolver aplicaçõesManual do MongoDB

Partição de dados com blocos

Nesta página

  • Blocos Iniciais
  • Tamanho da parte
  • Divisão de partes
  • Migração de partes
  • Blocos Indivisíveis/Jumbo
  • moveChunk Diretório

O MongoDB utiliza a chave de shard associada à collection para particionar os dados em parte. Um parte consiste em um subconjunto de dados fragmentados. Cada parte tem uma faixa inferior inclusiva e uma faixa superior exclusiva com base na chave do shard.

Diagrama do espaço de valor da chave de fragmentação segmentado em intervalos ou blocos.

O MongoDB divide os chunks quando eles ultrapassam o tamanho de chunk configurado. Tanto as inserções quanto as atualizações podem desencadear uma divisão de chunk.

O menor intervalo que um chunk pode representar é um único valor de chave de shard exclusivo. Um chunk que contém apenas documentos com um único valor de chave de shard não pode ser dividido.

  • A operação de fragmentação cria o(s) chunk(s) inicial(s) para cobrir todo o intervalo dos valores da chave de shard. O número de blocos criados depende do tamanho do bloco configurado.

  • Após a criação inicial da parte, o balanceador migra essas partes iniciais através dos shards, conforme apropriado, bem como managed a distribuição da parte daqui para frente.

  • Se você tiver zonas e faixas de zona definidas para uma collection vazia ou não existente.

    • A operação de fragmentação cria chunks vazios para as faixas de zonas definidas e chunks adicionais para cobrir toda a faixa de valores das chaves de shard e executa uma distribuição inicial de chunks com base nas faixas de zonas. A criação e distribuição inicial de chunks agiliza a configuração da fragmentação por zonas.

    • Após a distribuição inicial, o balancer passa a gerenciar a distribuição de chunks.

  • Se você não tiver zonas e intervalos de zonas definidos para uma collection vazia ou inexistente:

    • Para fragmentação com hash:

      • A operação de fragmentação cria chunks vazios para cobrir todo o intervalo dos valores de chave de fragmentação e executa uma distribuição inicial de chunk. Por padrão, a operação cria dois chunks por shard e migra pelo cluster. Você pode utilizar a opção numInitialChunks para especificar um número diferente de chunks iniciais. Esta criação e distribuição inicial de chunks permite uma configuração mais rápida de fragmentação.

      • Após a distribuição inicial, o balancer passa a gerenciar a distribuição de chunks.

    • Para fragmentação à distância:

      • A operação de fragmentação cria um único chunk vazio para cobrir todo o intervalo dos valores de chave de shard.

      • Após a criação inicial do chunk, o balanceador migra o chunk inicial através dos shards, conforme apropriado, bem como gerencia a distribuição do chunk daqui para frente.

Dica

Veja também:

O tamanho padrão do bloco no MongoDB é de 64 megabytes. Você pode aumentar ou reduzir o tamanho da parte. Considere as implicações de alterar o tamanho padrão da parte:

  1. Pequenas partes levam a uma distribuição mais uniforme de dados às custas de migrações mais frequentes. Isso cria despesas na camada de roteamento de query (mongos).

  2. Grandes partes levam a menos migrações. Isso é mais eficiente tanto da perspectiva de rede quanto em termos de sobrecarga interna na camada de roteamento de query. Mas, estas eficiências ocorrem à custa de uma distribuição potencialmente desigual de dados.

  3. O tamanho da parte afeta o número máximo de documento por parte para migração.

  4. O tamanho do chunk afeta o tamanho máximo da collection ao fragmentar uma collection existente. Após a fragmentação, o tamanho da parte não limita o tamanho da collection.

Para muitos sistemas, faz sentido evitar migrações frequentes e potencialmente espúrias às custas de um definir um pouco menos uniformemente distribuído.

Alterar o tamanho da parte afeta quando as partes são feitas a divisão, mas há algumas limitações para seus efeitos.

  • A divisão automática ocorre somente durante inserções ou atualizações. Se você reduzir o tamanho da parte, pode levar algum tempo para que todas as partes façam a divisão para o novo tamanho.

  • As divisões não podem ser "dessucedidas". Se você aumentar o tamanho da parte, as partes existentes deverão crescer por meio de inserções ou atualizações até que atinjam o novo tamanho.

A divisão é um processo que evita que os chunks fiquem grandes demais. Quando um chunk ultrapassa um tamanho de chunk especificado ou se o número de documentos no chunk excede o número máximo de documentos por chunk para migração, o MongoDB divide o chunk com base nos valores da chave de shard que o chunk representa. Um chunk pode ser dividido em vários chunks quando necessário. Inserções e atualizações podem desencadear divisões. As divisões são uma alteração de metadados eficiente. Para criar divisões, o MongoDB não migra nenhum dado nem afeta os shards.

Diagrama de um fragmento com uma parte que excede o tamanho padrão da parte de 64 MB e Atlas Triggers uma divisão da parte em duas partes.

A divisão pode levar a uma distribuição desigual das partes para uma collection entre os shards. Nesses casos, o balanceador redistribui as partes entre os shards. Consulte balanceador de Cluster para obter mais detalhes sobre como equilibrar parte entre fragmentos.

O MongoDB migra parte em um cluster fragmentado para distribuir os parte de uma collection fragmentada uniformemente entre os fragmentos. As migrações podem ser:

  • Manual. Utilize a migração manual apenas em casos limitados, como para distribuir dados durante inserções em massa. Consulte Migrando Blocos Manualmente para obter mais detalhes.

  • Automático. O processo do balanceador migra automaticamente os blocos quando há uma distribuição desigual dos blocos de uma coleção fragmentada entre os fragmentos. Consulte Limites de Migração para obter mais detalhes.

Para obter mais informações sobre o balanceador de cluster fragmentado, consulte Balanceador de cluster fragmentado.

O balanceador é um processo em segundo plano que managed migrações de parte. Se a diferença no número de parte entre o maior e o menor fragmento exceder os limites de migração, o balanceador começará a migrar parte pelo cluster para garantir uma distribuição uniforme de dados.

Diagrama de uma coleção distribuído em três fragmentos. Para esta coleção, a diferença no número de blocos entre os fragmentos atinge os *limites de migração* (neste caso, 2) e aciona a migração.

Você pode managed certos aspectos do balanceador. O balanceador também respeita quaisquer zonas criadas como parte da configuração de zonas em um cluster fragmentado.

Consulte Balanceador de Cluster Fragmentado para obter mais informações sobre o balanceador.

Em alguns casos, os chunks podem crescer além do tamanho especificado do chunk, mas não podem ser divididos. O cenário mais comum é quando um chunk representa um valor chave de shard único. Como o chunk não pode ser dividido, ele continua a crescer além do tamanho do chunk, tornando-se um jumbo chunk. Esses jumbo chunks podem se tornar um gargalo de desempenho à medida que continuam crescendo, especialmente se o valor da chave de shard ocorrer com alta frequência.

A partir do MongoDB 5.0, você pode fazer o reshard de uma collection alterando a chave de shard de um document.

O MongoDB fornece o comando refineCollectionShardKey. O refinamento da chave fragmentada de uma collection permite uma distribuição de dados mais refinada e pode resolver situações em que a cardinalidade insuficiente da chave existente leva a parte jumbo.

Para saber se você deve reestruturar sua collection ou refinar sua chave de shard, consulte Alterar uma chave de shard.

Para mais informações, veja:

No MongoDB 2.6 e MongoDB 3.0, o sharding.archiveMovedChunks está habilitado por padrão. Todas as outras versões do MongoDB têm isso desabilitado por padrão. Com o sharding.archiveMovedChunks habilitado, o fragmento de origem arquiva os documentos nos blocos migrados em um diretório com o mesmo nome do namespace da coleção no diretório moveChunk no storage.dbPath .

Se ocorrer algum erro durante a migração , esses arquivos poderão ser úteis na recuperação de documentos afetados durante a migração.

Depois que a migração for concluída com êxito e não houver necessidade de recuperar os documentos desses arquivos, você poderá excluir esses arquivos com segurança. Ou, se você tiver um backup existente do reconhecimento de data center que possa usar para recuperação, também poderá excluir esses arquivos após a migração.

Para determinar se todas as migrações foram concluídas, execute sh.isBalancerRunning() enquanto estiver conectado a uma instância do mongos .

← Distribuir coleções utilizando zonas