Menu Docs
Página inicial do Docs
/ /

Recomendações para configurações de economia de custos do Atlas

Para melhor entender e simplificar seus gastos, especialmente à medida que seu uso se expande, o MongoDB Atlas oferece ferramentas para gerenciar e controlar os custos de banco de dados da sua organização.

As seguintes recomendações se aplicam a todos os paradigmas de implantação.

Considere estas estratégias para otimizar seus custos do Atlas .

Use o Performance Advisor e as métricas de cluster para identificar clusters superdimensionados. Procure por System Max: User CPU utilization consistentemente baixo (menos de 45% de RAM) ou excesso de RAM que nunca foi totalmente utilizado. Em seguida, reduza o tamanho para uma camada que melhor corresponda aos seus padrões reais de volume de trabalho.

Muitas equipes começam com clusters maiores e se esquecem de se ajustar à medida que descobrem seus padrões reais de uso. O Atlas oferece opções de baixa CPU para volumes de trabalho mais leves e dimensionamento flexível que permite combinar recursos com a Realidade em vez de suposições. O dimensionamento correto geralmente é a maior barra de custo que você pode puxar.

Para saber mais, consulte Reduzindo um cluster de forma reativa.

  • Habilitar dimensionamento automático na camada do cluster para ajustar ao seu uso e evitar o superdimensionamento.

    O dimensionamento para baixo ocorre uma vez a cada seis horas e deve atender a condições específicas. Para saber mais, veja Reduzindo uma camada do cluster.

    Você também pode mover manualmente para um nível inferior da camada do cluster monitorando regularmente a CPU, o cache do WireTiger, a memória e as IOPs durante um período contínuo de 30 dias de uso normal. Geralmente, se o uso estiver consistentemente abaixo de 45% dos recursos alocados, recomendamos que você reduza a escala.

  • Para clusters dedicados, considere reduzir a escala para um nível inferior ou pausar o cluster se não for usá-lo por um longo período.

    Recomendamos que você use clusters M10 ou M30 para ambientes de desenvolvimento e teste. Para aprender mais, consulte o Guia de tamanho do cluster do Atlas.

  • Para ambientes de desenvolvimento e teste, recomendamos que você:

Para clusters fragmentados, revise sua estratégia de dimensionamento para evitar fragmentos quentes. Um shard quente ocorre quando um shard em seu cluster recebe desproporcionalmente mais tráfego ou dados do que outros, forçando-o a ampliar todo o cluster quando apenas esse único shard precisa de mais recursos.

Verifique como suas collections estão distribuídas entre os shards para identificar essas situações desequilibradas. Procure coleções que ainda não foram fragmentadas. Distribua-os corretamente para que possa reduzir o tamanho geral do cluster. Você também pode configurar diferentes abordagens de fragmentação para diferentes coleções com base em como você realmente usa cada uma. Primeiro, tente reequilibrar o tráfego para que seja uniforme entre os fragmentos, mas se isso não for possível aproveitar o recurso de fragmento independente.

Quando você não usa o dimensionamento independente de shards, os shards quentes são caros porque você termina pagando para escalar recursos de que não precisa em todo o cluster. Ao distribuir a carga de forma mais uniforme por meio da fragmentação inteligente, você pode ajustar sua configuração e evitar custos desnecessários. A economia depende do seu volume de trabalho específico, mas essas abordagens ajudam você a crescer de forma estável e econômicas à medida que seus padrões de dados mudam.

Para aprender mais, consulte Orientações para escalabilidade do Atlas.

  • Osbackups contínuos são caros, mas oferecem a maior segurança para recuperar dados de qualquer ponto dentro da janela de backup em caso de desastre ou erro de lógica de código. Recomendamos que você habilite backups contínuos somente para aplicativos de produção na camada de dados mais crítica.

  • Reduza a frequência de backups para clusters que armazenam dados menos críticos. Considere encerrar totalmente esses clusters para ambientes de desenvolvimento.

Sempre que possível, opte pela transferência de dados do mesmo provedor e mesma região para minimizar os custos. Use transferências entre regiões ou pela Internet somente quando necessário, como em cenários de recuperação de desastres em que você precisa restaurar o aplicação em uma região diferente. Localizar seu cluster na mesma região que a maioria do seu tráfego — geralmente onde você hospeda seu aplicação — pode reduzir muito os custos de transferência de dados .

Observação

Para saber mais e obter orientações específicas para seu provedor de nuvem, consulte Como reduzir os custos de transferência de dados.

Habilite a compactação de rede no driver do cliente para compactar dados entre o cliente e o servidor. Por exemplo, você pode configurar a opção de compactação de rede para o driver nó.js. O Atlas sempre comprime a comunicação intra-cluster.

Para saber mais, consulte Como reduzir os custos de transferência de dados.

Revise as configurações do pool de conexões do seu aplicativo e dimensione-as corretamente para corresponder aos seus padrões reais de uso simultâneo. A maioria dos aplicativos pode reduzir com segurança o tamanho máximo do pool a partir das configurações padrão e, ao mesmo tempo, adicionar tempos limite de conexão e lógica de repetição adequadas.

Cada conexão de banco de dados consome recursos tanto do aplicação quanto do cluster. Pools de conexões provisionados em excesso criam sobrecarga desnecessária e podem, na verdade, prejudicar o desempenho por meio do intercâmbio de conexões.

Para saber mais, consulte Limites de conexão do MongoDB Atlas e camada do cluster

Verifique se há ineficiências em todos os aplicativos e processos que acessam os dados. Certifique-se de que as queries não:

  • Releia os dados que já existem no cliente.

  • Reescreva os dados existentes no seu cluster.

Para saber mais, consulte Como reduzir os custos de transferência de dados.

Dica

Use a projeção para selecionar quais campos de documento retornar de uma query. Por padrão, as queries retornam todos os campos em documentos correspondentes. Para limitar a quantidade de dados que o Atlas envia para aplicativos, você pode incluir um documento de projeção para especificar ou restringir campos para retornar.

As queries que levam muito tempo para serem executadas podem aumentar o uso de recursos, exigindo clusters de nível superior. Otimize essas queries para reduzir o consumo de recursos e, como resultado, reduzir os custos.

Agende ajustes de query trimestrais com sua equipe para revisar suas queries mais lentas e auditar sua cobertura de índice. Use o Performance Advisor para identificar índices ausentes e o Query Profiler para detectar operações dispendiosas. Crie uma planilha simples para acompanhar suas queries mais caras 10 e seu status de otimização.

As queries se degradam à medida que os dados crescem. Uma query com bom desempenho em 1GB pode facilmente ultrapassar seu orçamento em 100GB. Enquanto isso, índices não utilizados consomem armazenamento e desaceleram as gravações sem agregar valor. Revisões regulares detectam o desvio de desempenho antecipadamente e mantêm sua estratégia de indexação simples e significativa.

Para saber mais,consulte Analisar queries lentas.

Um índice do Atlas Search pode estar obsoleto devido a qualquer um dos seguintes motivos:

  • A replicação foi interrompida devido à alta utilização do disco.

    Para nós dedicados do Atlas Search , o limite de replicação de pausa é 90% e o limite de retomada da replicação é 85% de utilização do disco para todas as gravações no cluster. Sem nós dedicados do Atlas Search , o limite de replicação de pausa é 96% e o limite de retomada da replicação é 94% de utilização do disco para todas as gravações no cluster.

  • Se a replicação parar por um período maior do que a oplog window, o processo Atlas Search mongot cairá do oplog e deverá ser sincronizado novamente.

    Esse estado geralmente ocorre quando o ponto de replicação atual não está mais disponível no oplog. O Atlas reconstrói o índice se mongod o mongot processo cair do oplog, o que pode consumir muitos recursos e levar um tempo notável.

  • O índice atingiu o limite de dois bilhões de documentos.

  • A replicação falhou devido a um erro.

Você ainda pode consultar o índice existente. No entanto, os resultados das consultas em relação a um índice obsoleto podem conter dados obsoletos. Você pode atualizar seus nós de pesquisa para obter mais espaço em disco e, se não estiver atualmente acima do limite de bloqueio, excluir índices existentes para liberar espaço em disco. Como alternativa, use o erro na janela modal View status details para solucionar o problema.

Para saber mais,consulte Corrigir problemas de pesquisa do MongoDB .

Trabalhe com sua equipe do Atlas para revisar suas coleções em busca de padrões de alto custo, como documentos superdimensionados, arrays ilimitadas ou esquemas que forçam operações dispendiosas. Procure oportunidades para incorporar dados relacionados que são acessados juntos, mantendo documentos individuais em tamanhos razoáveis. Concentre-se na eliminação de padrões que exigem agregações complexas ou pesquisas entre coleções quando estruturas de documento mais simples podem funcionar.

Um design de esquema ruim aumenta silenciosamente os custos por meio de queries ineficientes e aumento de armazenamento. O modelo de documento do Atlas elimina naturalmente as operações relacionais dispendiosas quando projetado corretamente. Collections bem projetadas reduzem a sobrecarga de computação, minimizam os requisitos de índice e melhoram o desempenho da query, todos os quais impacto diretamente sua fatura mensal.

Para saber mais,consulte Design de esquema.

Utilize recursos como arquivo online ou índices TTL para transferir dados mais antigos do armazenamento ativo, mais caro, para o armazenamento passivo, mais barato, ou para excluir dados que não são mais necessários. Após arquivar os dados, você pode acessá-los por meio do Atlas Data Federation.

Use regularmente a ferramenta Visualizador de custos para monitorar padrões de gastos nos níveis de organização, projeto, cluster e serviço. Defina uma frequência que funcione para suas necessidades.

Configure alertas de cobrança para os principais limites, como quando seus custos mensais excedem um determinado valor. Por exemplo, defina um alerta quando os custos excederem US$100. Essa abordagem proativa ajuda você a evitar surpreendentes.

A cada mês, revise sua fatura para avaliar os serviços de maior custo usando as sugestões anteriores de otimização de faturamento. Esta é uma prática recomendada para identificar oportunidades de redução de custos.

Se você observar alterações inesperadas em sua fatura, verifique seus custos de computação em nuvem, que geralmente são a maior parte de sua conta. Você pode revisar os custos de computação em nuvem no cartão Summary By Service de qualquer fatura na seção Billing do Atlas . A visualização Summary By Service mostra os custos de todos os clusters por provedor, nível e região.

O paradigma de implantação e a topologia que você escolher podem alterar os custos do Atlas.

Para aprender mais sobre economia de custos para diferentes topologias, veja Orientações para alta disponibilidade do Atlas.

Aplique tags consistentes aos seus projetos e clusters do Atlas por equipe, ambiente ou centro de custo. Use tags descritivas como "team-group", "env-production" ou "project- mobile-app" para criar uma visão clara de propriedade e gasto em toda a organização.

Sem a marcação adequada, sua conta do Atlas fica ofuscada onde é impossível rastrear quais equipes ou projetos estão gerando custos. A marcação de recursos transforma seu Visualizador de custos em uma poderosa ferramenta de responsabilidade, facilitando a identificação de tendências de custo, alocação de despesas com precisão e localização de oportunidades de otimização por departamento ou tipo de volume de trabalho.

Para saber mais,consulte Marcações de recursos.

Voltar

Otimização de custos