Comparando Alocação de Recursos para Membros de Conjunto de Réplicas vs. Nós de Fragmentação

O planejamento de recursos do MongoDB muda drasticamente quando você passa de um conjunto de réplicas para um cluster fragmentado. Duas arquiteturas principais facilitam esses objetivos: Conjuntos de Réplicas e Clusters Fragmentados. Embora ambos sejam fundamentais para implantações do MongoDB em nível de produção, suas estratégias subjacentes de alocação de recursos diferem significativamente, impactando diretamente o design da infraestrutura e o custo.

Um conjunto de réplicas concentra o conjunto de dados completo e a maior parte da pressão de gravação em um primário. Um cluster fragmentado distribui os dados entre conjuntos de réplicas de fragmentos, mas adiciona roteadores mongos e servidores de configuração que também precisam de capacidade e monitoramento.

Entendendo as Estratégias de Implantação do MongoDB

Antes de mergulhar na alocação de recursos, vamos recapitular brevemente as funções de cada componente em um Conjunto de Réplicas e um Cluster Fragmentado.

Conjuntos de Réplicas: Alta Disponibilidade e Redundância de Dados

Um conjunto de réplicas do MongoDB é um grupo de instâncias mongod que mantêm o mesmo conjunto de dados. Isso fornece alta disponibilidade e redundância de dados. Um conjunto de réplicas normalmente consiste em:

Nó Primário: O único nó que recebe todas as operações de gravação. Ele registra todas as alterações em seu log de operações (oplog). Pode haver apenas um primário em um conjunto de réplicas a qualquer momento.
Nós Secundários: Replicam o oplog do primário e aplicam essas alterações em seus próprios conjuntos de dados, garantindo a consistência dos dados. Os nós secundários podem servir operações de leitura, dependendo das configurações de preferência de leitura, e podem ser eleitos como primários se o primário atual ficar indisponível.
Nó Árbitro: Participa de eleições para determinar o primário, mas não armazena dados. Os árbitros consomem recursos mínimos e podem ser usados para adicionar um voto quando você não puder implantar outro membro que armazene dados. Eles não previnem todos os problemas de eleição e devem ser usados com moderação.

Clusters Fragmentados: Escalabilidade Horizontal

Fragmentação é o método do MongoDB para distribuir dados entre várias máquinas. Isso permite a escalabilidade horizontal para lidar com grandes conjuntos de dados e operações de alta taxa de transferência que um único conjunto de réplicas não pode gerenciar. Um cluster fragmentado compreende vários componentes-chave:

Mongos (Roteadores de Consulta): Atuam como uma interface entre os aplicativos cliente e o cluster fragmentado. Eles roteiam consultas para os fragmentos apropriados, agregam resultados e gerenciam conexões.
Servidores de Configuração (CSRS): Armazenam os metadados do cluster, incluindo quais intervalos de dados residem em quais fragmentos (o 'mapa de fragmentos'). Os servidores de configuração são implantados como um conjunto de réplicas (Conjunto de Réplicas de Servidores de Configuração - CSRS) para alta disponibilidade.
Fragmentos: Cada fragmento é ele próprio um conjunto de réplicas que contém um subconjunto dos dados do cluster. Os dados são distribuídos entre esses fragmentos com base em uma chave de fragmento.

Alocação de Recursos para Membros do Conjunto de Réplicas

Os requisitos de recursos para membros do conjunto de réplicas variam significativamente com base em sua função e na carga de trabalho geral.

Nó Primário

O nó primário é o membro mais crítico e intensivo em recursos de um conjunto de réplicas, pois lida com todas as operações de gravação e normalmente a maioria das operações de leitura.

CPU: Alta. Cargas de trabalho pesadas de gravação, pipelines de agregação complexos, operações de indexação e lidar com muitas conexões simultâneas exigem poder de CPU significativo. Se seu aplicativo atualiza documentos com frequência ou realiza consultas intensivas, a CPU do primário pode rapidamente se tornar um gargalo.
RAM: Crítica. O mecanismo de armazenamento WiredTiger do MongoDB depende fortemente da RAM para seu cache. O primário precisa de RAM suficiente para manter dados e índices acessados com frequência na memória para minimizar a E/S de disco. Uma recomendação comum é alocar RAM suficiente para conter seu conjunto de trabalho (os dados e índices ativamente usados por seus aplicativos) mais algum buffer.
Armazenamento: Alto IOPS e taxa de transferência. Todas as operações de gravação atingem o disco do primário, incluindo o journaling. Armazenamento rápido (SSDs/NVMe) com alto IOPS (Operações de Entrada/Saída por Segundo) é essencial para evitar que a latência de gravação se torne um gargalo. A capacidade deve ser suficiente para o conjunto de dados completo e seu crescimento, mais espaço para o oplog.

Nós Secundários

Os nós secundários replicam dados do primário e podem servir solicitações de leitura, aliviando o primário. Suas necessidades de recursos são frequentemente semelhantes às do primário, especialmente se eles lidam com leituras.

CPU: Moderada a Alta. O uso da CPU depende da taxa de replicação e da carga de trabalho de leitura. Se os secundários lidam com uma parte significativa das leituras, seus requisitos de CPU podem se aproximar aos do primário. Se forem principalmente para replicação e failover, o uso da CPU será menor, mas ainda importante para aplicar entradas do oplog de forma eficiente.
RAM: Crítica. Semelhante ao primário, os secundários mantêm um cache do WiredTiger e precisam de RAM suficiente para conter o conjunto de trabalho para aplicar entradas do oplog de forma eficiente e servir leituras sem E/S de disco excessiva. O cache de um secundário deve idealmente espelhar o do primário para desempenho consistente durante o failover.
Armazenamento: Alto IOPS e taxa de transferência. Os secundários devem acompanhar as gravações do primário aplicando entradas do oplog. Isso também exige alto desempenho de E/S. A capacidade precisa ser idêntica à do primário, pois eles armazenam uma cópia completa dos dados.

Dica: Certifique-se de que os nós secundários sejam provisionados de forma semelhante ao primário. Isso garante um failover suave e desempenho consistente quando um secundário se torna primário.

Nó Árbitro

Os árbitros são nós leves exclusivamente para participar de eleições. Eles não armazenam dados nem servem operações de leitura/gravação.

CPU: Muito Baixa. Os árbitros realizam computação mínima relacionada aos protocolos de eleição.
RAM: Muito Baixa. Apenas requer memória suficiente para a sobrecarga básica do processo mongod e estado da eleição.
Armazenamento: Muito Baixo. Armazena apenas configuração mínima e arquivos de log, sem arquivos de dados.

Aviso: Nunca execute um aplicativo ou outros processos de banco de dados em um nó árbitro. Deve ser uma instância dedicada e mínima para garantir sua disponibilidade para eleições e evitar contenção de recursos.

Alocação de Recursos para Componentes de Fragmentação

Os clusters fragmentados introduzem componentes adicionais, cada um com perfis de recursos únicos, levando a uma estratégia de alocação de recursos mais distribuída e complexa.

Mongos (Roteadores de Consulta)

As instâncias mongos são processos de roteamento sem estado. Elas não armazenam dados, mas coordenam operações entre fragmentos.

CPU: Moderada a Alta. O uso da CPU escala com o número de conexões de cliente, trabalho de roteamento de consultas, consultas scatter-gather e trabalho de mesclagem de agregação que o mongos precisa coordenar. Mais instâncias mongos podem ser adicionadas para lidar com cargas mais altas.
RAM: Moderada. Usada principalmente para gerenciamento de conexões, cache de metadados dos servidores de configuração (mapa de fragmentos) e buffers temporários de agregação. Não é tão crítica quanto os nós que armazenam dados, mas RAM suficiente evita swapping e garante tempos de resposta rápidos.
Armazenamento: Muito Baixo. Apenas logs são armazenados. SSDs locais geralmente são mais que suficientes.

Dica: Para desempenho ideal, implante instâncias mongos próximas aos seus servidores de aplicação para minimizar a latência de rede.

Servidores de Configuração (Conjunto de Réplicas de Servidores de Configuração - CSRS)

Os servidores de configuração são cruciais para a operação do cluster fragmentado, armazenando metadados sobre o estado do cluster. Eles são sempre implantados como um conjunto de réplicas (CSRS).

CPU: Moderada. O uso da CPU pode aumentar durante migrações de chunks, rebalanceamento de fragmentos ou atualizações frequentes de metadados. Embora não seja tão alta quanto a de um primário que armazena dados, o desempenho consistente é vital.
RAM: Moderada a Alta. Precisa de RAM suficiente para manter os metadados críticos do cluster na memória. O tamanho dos metadados depende do número de fragmentos, chunks e bancos de dados. RAM insuficiente pode degradar severamente o desempenho e a estabilidade do cluster.
Armazenamento: IOPS e Capacidade Moderados. Embora o tamanho dos metadados seja geralmente menor que os dados do usuário, as atualizações no mapa de fragmentos e outras informações de estado do cluster podem ser frequentes, exigindo desempenho de E/S decente. A capacidade precisa acomodar o crescimento dos metadados e do oplog.

Aviso: O desempenho e a disponibilidade de seus servidores de configuração são primordiais. Qualquer degradação pode paralisar todo o seu cluster fragmentado. Provisione-os com infraestrutura altamente confiável e de alto desempenho.

Membros do Fragmento (Conjuntos de Réplicas que Armazenam Dados)

Cada fragmento é um conjunto de réplicas autocontido, armazenando um subconjunto dos dados totais do cluster. Portanto, os requisitos de recursos para os nós primário, secundário e árbitro dentro de cada fragmento são semelhantes em natureza a um conjunto de réplicas independente, mas dimensionados para a porção de dados que eles armazenam.

CPU: Alta para o primário, Moderada a Alta para secundários. O primário de cada fragmento lida com todas as gravações e potencialmente leituras para seu subconjunto de dados. As demandas são proporcionais à carga de trabalho roteada para esse fragmento específico.
RAM: Crítica para primário e secundários. O mongod de cada fragmento precisa de RAM suficiente para seu cache do WiredTiger, proporcional ao conjunto de trabalho dos dados que armazena. Isso é crucial para o desempenho dentro de seu segmento de dados.
Armazenamento: Alto IOPS e taxa de transferência para primário e secundários. Semelhante a um conjunto de réplicas independente, o armazenamento rápido é necessário para lidar com gravações, leituras e replicação para o subconjunto de dados do fragmento. A capacidade deve ser suficiente para a porção de dados do fragmento e seu crescimento.

Diferença Chave: Embora um conjunto de réplicas de fragmento individual tenha requisitos semelhantes a um conjunto de réplicas independente, o cluster fragmentado geral distribui os dados totais e a carga de trabalho entre vários desses conjuntos de réplicas. Isso significa que a soma de recursos em todos os fragmentos será significativamente maior do que um único conjunto de réplicas escalado verticalmente.

Comparando Alocação de Recursos: Conjunto de Réplicas vs. Cluster Fragmentado

Característica	Conjunto de Réplicas (Independente)	Cluster Fragmentado
Propósito	Alta Disponibilidade, Redundância de Dados, Escalabilidade Moderada	Escalabilidade Horizontal, Conjuntos de Dados Muito Grandes, Alta Taxa de Transferência
Total de Nós	Comumente 3 membros que armazenam dados; árbitros apenas quando necessário	3 Servidores de Configuração + N Conjuntos de Réplicas de Fragmentos (geralmente 3+ membros cada) + M instâncias Mongos
CPU	Primário lida com toda a CPU de gravação. Secundários lidam com CPU de leitura. Árbitro mínimo.	Distribuída entre `mongos`, Servidores de Configuração e múltiplos Primários de Fragmentos. CPU total geral maior.
RAM	Primário e Secundários precisam de RAM para o conjunto de trabalho inteiro.	Cada Primário/Secundário de Fragmento precisa de RAM para seu subconjunto do conjunto de trabalho. Servidores de configuração precisam de RAM para metadados. RAM total geral maior.
Armazenamento	Primário e Secundários precisam de capacidade e IOPS para o conjunto de dados inteiro.	Cada Primário/Secundário de Fragmento precisa de capacidade e IOPS para seu subconjunto do conjunto de dados. Servidores de configuração precisam de IOPS/capacidade moderados. Armazenamento total geral maior.
Gargalo	Nó primário para gravações; limites de recursos de uma única máquina.	Qualquer componente (`mongos`, servidores de configuração ou um fragmento individual) pode se tornar um gargalo se subdimensionado.
Complexidade	Relativamente mais simples de configurar e gerenciar.	Significativamente mais complexo de planejar, implantar e gerenciar.
Custo	Menor custo de infraestrutura para escala moderada.	Maior custo de infraestrutura devido a mais instâncias e natureza distribuída.

Considerações Práticas e Melhores Práticas

Análise de Carga de Trabalho: Entenda completamente os padrões de leitura/gravação do seu aplicativo, projeções de crescimento de dados e complexidade de consultas. Este é o fator mais importante no planejamento de recursos.
Monitoramento é Chave: Implemente monitoramento abrangente para todos os componentes do MongoDB (CPU, RAM, E/S de disco, rede, métricas de banco de dados como uso de cache do WiredTiger, lag do oplog, tempos de consulta). Isso ajuda a identificar gargalos e permite escalonamento proativo.
Desempenho de Rede: Para clusters fragmentados, a latência e a largura de banda da rede entre mongos, servidores de configuração e fragmentos são críticas. A comunicação entre fragmentos e as operações de balanceamento de dados podem ser fortemente impactadas por um desempenho de rede ruim.
Recursos Dedicados: Cada processo mongod, seja primário, secundário ou membro de fragmento, deve ser executado em hardware dedicado ou em uma máquina virtual dedicada. Evite co-localizar com servidores de aplicação ou outras instâncias de banco de dados para evitar contenção de recursos.
Nuvem vs. On-Premise: Provedores de nuvem oferecem flexibilidade para escalar recursos facilmente. No entanto, certifique-se de que os tipos de instância escolhidos atendam aos requisitos de IOPS e taxa de transferência, especialmente para operações intensivas de armazenamento.
Testes e Benchmarking: Sempre teste sua infraestrutura planejada com cargas de trabalho realistas antes de ir para produção. Isso ajuda a validar suas suposições de alocação de recursos.

Conclusão

Use um conjunto de réplicas quando seu conjunto de trabalho, taxa de gravação e armazenamento couberem confortavelmente em uma classe de nó que armazena dados. Mude para fragmentação quando precisar de escala horizontal, mas faça um orçamento para as peças extras: conjuntos de réplicas de fragmentos, servidores de configuração, roteadores, capacidade de rede e mais testes operacionais.