Dimensionamento do cluster Atlas e seleção de níveis
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.
Escalonamento automático de cluster
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.
Memória
A memória refere-se ao total de RAM física disponível em cada nó 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.
Exemplo: conjuntos de dados de amostra do Atlas
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.
Exemplo: Aplicativo móvel
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 |
|
|
GCP |
|
|
Azure |
|
|
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.
Tráfego de rede
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.
Conexões
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.