Menu Docs
Página inicial do Docs
/
MongoDB Atlas
/

Dimensionamento do cluster Atlas e seleção de níveis

Nesta página

  • Escalonamento automático de cluster
  • Memória
  • Tráfego de rede

Importante

Recurso Indisponível em Instâncias sem Servidor

Neste momento, as instâncias sem servidor não permitem essa funcionalidade. Para saber mais, consulte Limitações de instâncias sem servidor.

A escolha da camada e da configuração corretas do cluster do Atlas é uma etapa importante na configuração de uma implantação bem-sucedida do MongoDB deployment. É possível modificar um cluster posteriormente, mas só é possível começar a configuração correta com alguns cálculos baseados no tamanho do conjunto de dados e nos requisitos de rede.

Você também pode configurar seu cluster para dimensionar automaticamente sua camada do cluster, sua capacidade de armazenamento ou ambas em resposta ao uso do cluster, reduzindo assim a manutenção manual necessária para seu cluster. Para saber mais, consulte Dimensionamento automático do cluster.

Observação

Recomendar clusters M30 ou maiores para uso em produção

Grupos M30 e superiores são recomendados para ambientes de produção. Você pode usar clusters M10 e M20 como ambientes de produção para aplicativos de baixo tráfego. Clusters com cargas sustentadas nas camadas M10 e M20 podem apresentar desempenho degradado ao longo do tempo.

Os clusters dedicados oferecem suporte ao escalonamento automático de clusters. O escalonamento automático da camada de cluster é ativado por padrão quando você cria novos clusters na interface do usuário. Ele é desativado por padrão se você criar novos clusters na API. Com o escalonamento automático ativado, o Atlas dimensiona automaticamente o camada do cluster, a capacidade de armazenamento ou ambos em resposta ao uso do cluster. O auto-scaling permite que seu cluster se adapte ao seu volume de trabalho atual e reduza a necessidade otimizações manuais.

  • O dimensionamento do armazenamento do cluster aumenta automaticamente a capacidade de armazenamento do cluster quando 90% da capacidade do disco é usada. Essa configuração é habilitada por padrão para ajudar a garantir que seu cluster sempre possa oferecer suporte a influxos repentinos de dados. Para desativar o dimensionamento do armazenamento em cluster, desmarque a caixa de seleção Storage Scaling na seção Auto-scale.

  • O auto-scaling da camada do cluster aumenta ou diminui automaticamente a camada do cluster em resposta a várias métricas do cluster. Para desativar o auto-scaling da camada do cluster, desmarque a caixa de seleção Cluster Tier Scaling na seção Auto-scale .

    Para controlar o auto-scaling do Atlas cluster, você deve definir:

    • A camada máxima de cluster para o qual seu cluster pode escalar verticalmente automaticamente. Por padrão, essa configuração é definida para a próxima camada de cluster em comparação à sua camada de cluster atual.

    • A camada mínima de cluster para o qual seu cluster pode ser reduzido. Por padrão, essa configuração é definida para a camada atual do cluster.

A memória refere-se ao total de RAM física disponível em cada de suporte de dados de seu cluster Atlas . Por exemplo, um conjunto de réplicas padrão do M30 é configurado com 8 GB de RAM em cada um dos nós de suporte de dados do 3.

O Atlas utiliza o mecanismo de armazenamento WiredTiger.

  • Por padrão, para clusters M40 ou maiores, o WiredTiger dedica 50% ou mais de RAM física para o cache do WiredTiger. A memória restante é reservada para os seguintes usos:

    • Operações na memória, como classificações e cálculos

    • Sistema operacional subjacente e outros serviços do sistema

  • Por padrão, para clusters M30 ou menores, o WiredTiger dedica 25% da RAM física para o cache do WiredTiger.

Para saber mais sobre o uso da memória, consulte WiredTiger e Uso de Memória.

O MongoDB utiliza o cache do WiredTiger para manter os dados e índices usados mais recentemente. O conjunto de trabalho é a soma de todos os índices mais o conjunto de documentos que são acessados com frequência. Se o seu conjunto de trabalho couber na RAM, o MongoDB poderá atender consultas da memória, o que fornece os tempos de resposta de consulta mais rápidos.

Para estimar o tamanho do conjunto de trabalho, você pode fazer um cálculo usando as informações obtidas de db.stats() para saber o espaço total do índice e presumir que uma porcentagem do espaço de dados será acessada com frequência, ou pode estimar os requisitos de memória com base em suposições fundamentadas.

Utilizando os conjuntos de dados de amostra do Atlas, calcularemos os requisitos de memória para executar todos estes bancos de dados em um único Atlas cluster. O seguinte programa JavaScript retorna informações do banco de dados para seu cluster:

var totalIndexSize = 0;
var totalDataSize = 0;
var reservedDBs = ["admin","config","local"];
// Switch to admin database and get list of databases.
db = db.getSiblingDB("admin");
dbs = db.runCommand({ "listDatabases": 1 }).databases;
// Iterate through each database and get its stats.
dbs.forEach(function(database) {
if (reservedDBs.includes(database.name))
return;
db = db.getSiblingDB(database.name);
print("Obtaining stats for " + database.name);
var stats = db.stats();
totalIndexSize += (stats.indexSize / (1024*1024*1024)) ;
totalDataSize += (stats.dataSize / (1024*1024*1024)) ;
});
print ("Total data size in GB: " + totalDataSize.toFixed(2));
print ("Total index size in GB: " + totalIndexSize.toFixed(2));

Este programa retorna os seguintes resultados:

Obtaining stats for sample_airbnb
Obtaining stats for sample_geospatial
Obtaining stats for sample_mflix
Obtaining stats for sample_supplies
Obtaining stats for sample_training
Obtaining stats for sample_weatherdata
Total data size in GB: 0.32
Total index size in GB: 0.02

Para executar esses bancos de dados completamente na memória, você precisaria de um mínimo de 0,68 GB de RAM física, já que o WiredTiger usa 50% da RAM física e precisamos de pelo menos 0,34 GB para caber o definir na memória.

Um cluster de produção realista teria um tamanho de dados e índice muito maior e pode não ser prático, ou não ser um requisito comercial ou de desempenho, executar definir e os índices completos na memória. Vamos dar uma olhada em outro cenário.

Um jogo móvel popular tem 512 GB de dados e 32 GB de índices. Os dados internos do sistema do jogo ocupam 16 GB, e o resto são dados do perfil do jogador. O perfil de um jogador deve estar na memória enquanto o jogador estiver ativo no jogo. Cerca de 25% de todos os jogadores estão ativos a qualquer momento. Os dados do sistema são usados constantemente e devem caber completamente na RAM para um desempenho ideal do jogo. Todos os índices também devem caber na RAM para o tempo de resposta da consulta mais rápido. O dimensionamento da memória é o seguinte:

Dados
Requisitos de RAM
RAM para cache WiredTiger

Sistema: 16 GB

100% em RAM

16 GB

Index: 32 GB

100% em RAM

32 GB

Perfis do reprodutor: 496 GB

25% em RAM

124 GB

Considerando esses requisitos, você pode esperar que um conjunto de trabalho médio exija 172 GB de RAM.

A WiredTiger dedica 50% da RAM física ao cache WiredTiger, portanto, o total mínimo de RAM física necessária para acomodar seu conjunto de trabalho é o dobro do conjunto de trabalho.

Neste exemplo, você precisa de pelo menos 344 GB de RAM física para acomodar o cache do WiredTiger e um conjunto de trabalho de 172 GB. A tabela a seguir lista as camadas do Atlas cluster adequados:

Provedor de serviços
Possíveis camadas do cluster
Notas

AWS

  • M300 384 GB DE RAM

  • M400 488 GB DE RAM

  • M700 768 GB DE RAM

M300 tem RAM suficiente e há espaço para escalar verticalmente para camadas do cluster mais altas.

GCP

  • M300 360 GB de RAM

M300 tem RAM suficiente, mas não há níveis superiores disponíveis se o escalonamento vertical for necessário.

Azure

  • M300 384 GB DE RAM

  • M400 432 GB de RAM

M300 tem RAM suficiente e há espaço para escalar verticalmente para uma camada do cluster mais alta.

Observação

Se você selecionar uma camada do cluster sem RAM suficiente, como um Azure M200 com 256 GB de RAM, será necessário fazer fragmentação.

Todo o tráfego de rede entre os nós do cluster e entre os clientes que consomem dados do Atlas cluster impacta a largura de banda da rede. Para fins de dimensionamento de cluster, considere o tráfego máximo que qualquer nó em seu cluster suportará e use isso como base para selecionar uma camada de Atlas cluster adequada.

As taxas de transferência de dados downstream do seu cluster para os aplicativos de clientes podem ser calculadas como a soma do total de documentos retornados em um período de tempo. Se estiver lendo apenas do nó primário, esse é o único cálculo que precisa ser feito. Se seus aplicativos também lerem de nós secundários, você poderá dividir esse número pelo número de nós que podem atender a operações de leitura.

Você pode encontrar o tamanho médio do documento de um banco de dados com o método db.stats(). Multiplique o tamanho médio do documento (avgObjSize) pelo número de documentos atendidos por segundo para estimar seus requisitos de largura de banda.

Exemplo

Tamanho médio do documento de 10 KB

100.000 documentos por segundo atendidos

10 KB * 100.000 = 1 GB por segundo

As instâncias do Atlas fornecem velocidades de largura de banda mais rápidas nos níveis mais altos. As instâncias que são apoiadas pela AWS fornecem até 10 gigabits por segundo no nível M30 , enquanto o nível M200 fornece até 25 gigabits por segundo.

Um Atlas cluster pode permitir uma série de conexões de cliente que são determinadas pela camada do cluster. Por exemplo, os clusters M30 suportam até 3000 conexões simultâneas e os clusters M200 suportam até 128,000 conexões simultâneas. Para saber mais, consulte Limites de conexão e camada do cluster.

Voltar

Notas de produção