As collections no mesmo conjunto de réplicas podem encontrar gargalos de desempenho ao competir por recursos. À medida que seus dados ultrapassam a memória disponível, o aumento da E/S de disco introduz latência e sobrecarrega os recursos do sistema, degradando o desempenho geral do aplicação . O isolamento de collections em shards dedicados em seu cluster reduz essas restrições de recursos e, ao mesmo tempo, mantém um único ponto de conexão para seu aplicação.
Benefícios do isolamento da collection:
Separação de carga de trabalho – Evite a contenção de recursos atribuindo coleções a shards específicos.
Otimização de hardware – Configure fragmentos assimétricos com hardware personalizado para requisitos específicos da coleção.
Dimensionamento independente – Dimensione as coleções individualmente com base no crescimento do volume de trabalho.
Resiliência aprimorada – Reduza o tempo de recuperação isolando possíveis falhas.
Quando usar moveCollection
A movimentação de collections em shards dedicados é particularmente benéfica quando os requisitos de collection variam das seguintes maneiras:
Requerimento | Descrição |
|---|---|
Padrões de acesso | Algumas de suas collections são muitas de leitura, enquanto outras são de escrita. |
Desempenho | Algumas collections exigem mais RAM, CPU ou taxa de transferência de disco do que outras. |
Demandas de escalabilidade | As collections que têm padrões de crescimento rápidos ou imprevisíveis exigem hardware dedicado. |
Atribuir collections a shards com o hardware necessário para atender a seus requisitos específicos otimiza o desempenho e, ao mesmo tempo, mantém a simplicidade operacional.
Quando mover coleções não fragmentadas
A partir do MongoDB 8.0, as collections móveis permitem colocar estrategicamente qualquer collection não fragmentada em qualquer shard dentro do cluster. Anteriormente, as collections não fragmentadas eram restritas ao fragmento primário de seu banco de dados, causando gargalos de recursos. A movimentação de uma collection simplifica o dimensionamento horizontal, permitindo que você realoque collections não fragmentadas sem interromper as cargas de trabalho.
Embora nem todas as collections precisem ser fragmentadas, a implantação de um cluster fragmentado oferece vantagens de dimensionamento horizontal, mesmo para collections não fragmentadas. Essa abordagem mantém um único ponto de conexão para todo o acesso a dados, simplificando a arquitetura do aplicação .
Os cenários a seguir se beneficiam da movimentação de collections não fragmentadas entre shards:
Isolamento da carga de trabalho
Quando várias collections atendem a diferentes volumes de trabalho dentro do mesmo cluster, a movimentação de collections não fragmentadas entre diferentes shards ajuda a evitar a contenção de recursos. Essa separação elimina problemas em que o desempenho de um volume de trabalho afeta negativamente outros.
Arquitetura Multi-Tenant
Em ambientes que hospedam collections para diferentes locatários, o comando moveCollection do MongoDB permite a distribuição perfeita de collections entre shards sem tempo de inatividade. Essa flexibilidade otimiza a alocação de recursos com base nas necessidades específicas de cada locatário.
Distribuição geográfica de dados
As organizações podem precisar armazenar dados do usuário em regiões geográficas específicas para cumprir as normas de soberania de dados. Com o moveCollection, você pode colocar collections não fragmentadas em shards em diferentes regiões e realocá-las à medida que os requisitos normativos evoluem.
Otimização de custos
Antes do MongoDB 8.0, todas as collections não fragmentadas dentro de um banco de dados eram restritas ao fragmento primário. Essa limitação geralmente forçava atualizações para camadas de instâncias maiores e mais caras. O MongoDB 8.0 remove essa restrição, permitindo a movimentação de collections não fragmentadas em todos os shards disponíveis no cluster.
A movimentação de collections não fragmentadas entre hardware de shard assimétrico oferece benefícios significativos para a otimização de recursos, permitindo que você coloque collections específicas em hardware personalizado de acordo com os requisitos deles. Ao combinar collections com recursos de hardware apropriados, você pode escalar diferentes volumes de trabalho de forma independente com base em suas solicitações reais. Essa abordagem direcionada melhora o desempenho e, ao mesmo tempo, evita o custo do provisionamento excessivo de recursos em todo o cluster.
Densidade de collection reduzida
Embora o MongoDB não tenha um limite rígido na contagem de collections por instância, o desempenho se degrada quando um nó gerencia muitas collections e índices. Para saber mais sobre esses limites, consulte Collection do MongoDB Atlas e Limites de índice.
Ao distribuir coleções não fragmentadas em diferentes fragmentos, você pode reduzir a densidade da coleção em qualquer nó e, ao mesmo tempo, manter um ponto de acesso unificado para os aplicativos.
Colocation estratégico
Considere a possibilidade de colocalizar collections não fragmentadas no mesmo shard para minimizar as operações distribuídas, como transações entre collections ou operações de junção ($lookup). Manter operações relacionadas confinadas a um único shard elimina a sobrecarga de rede, reduz a latência e melhora o desempenho geral. Essa abordagem é particularmente eficaz para collections que são frequentemente unidas ou acessadas juntas na mesma transação.
Sintaxe do comando
sh.moveCollection("database.collection", "shardName")
O exemplo a seguir move quatro collections não fragmentadas entre dois shards para distribuição igualitária das collections:
db.adminCommand({moveCollection:"E", toShard: "shard1"})
Quando evitar usar moveCollection
Embora o moveCollection ofereça flexibilidade significativa, há alguns cenários específicos em que ele pode não ser a solução ideal:
Coleções grandes
Não use moveCollection quando a collection for muito grande para um único shard. Considere fragmentar uma collection quando ela estiver se aproximando de 3 TB de tamanho.
Coleções com índices do Atlas Search
Se uma collection específica usar Atlas Search, esteja ciente de que moveCollection usa refragmentação para reescrever a collection em um shard diferente. Após mover a coleção, você precisará reconstruir manualmente seu índice de Atlas Search . Até que os índices sejam totalmente reconstruídos, a funcionalidade do Atlas Search não estará disponível para essa collection específica, embora o restante do aplicação funcione normalmente.
Antes de usar moveCollection, avalie estas limitações em relação aos requisitos do seu aplicação para determinar se é a solução apropriada.