Melhores práticas para o Amazon DocumentDB

Aprenda as práticas recomendadas para trabalhar com o Amazon DocumentDB (compatível com MongoDB). Essa seção é continuamente atualizada conforme novas melhores práticas são identificadas.

Diretrizes operacionais básicas

As diretrizes operacionais básicas a seguir devem ser seguidas por todos ao trabalhar com o Amazon DocumentDB. O Acordo de Nível de Serviço do Amazon DocumentDB exige que você siga essas diretrizes.

• Implante um cluster que consiste em duas ou mais instâncias do Amazon DocumentDB em duas zonas de AWS disponibilidade. Para workloads de produção, recomendamos implantar um cluster de três ou mais instâncias do Amazon DocumentDB em três zonas de disponibilidade.

• Use o serviço dentro dos limites de serviço indicados. Para obter mais informações, consulte Cotas e limites do Amazon DocumentDB.

• Monitore sua memóriaCPU, conexões e uso de armazenamento. Para ajudá-lo a manter o desempenho e a disponibilidade do sistema, configure CloudWatch a Amazon para notificá-lo quando os padrões de uso mudarem ou quando você se aproximar da capacidade de sua implantação.

• Escale suas instâncias quando estiver se aproximando dos limites de capacidade. Suas instâncias devem ser provisionadas com recursos computacionais suficientes (ou seja,RAM,CPU) para acomodar aumentos imprevistos na demanda de seus aplicativos.

• Defina seu período de retenção de backup para alinhar com seu objetivo de ponto de recuperação.

• Teste o failover de seu cluster para entender quanto tempo o processo leva para seu caso de uso. Para obter mais informações, consulte Failover do Amazon DocumentDB.

• Conecte-se ao cluster do Amazon DocumentDB com o endpoint do cluster (consulte Endpoints do Amazon DocumentDB) e no modo de conjunto de réplicas (consulte Conectando-se ao Amazon DocumentDB como um conjunto de réplicas) para minimizar o impacto de um failover em seu aplicativo.

• Escolha uma configuração de preferência de leitura do driver que maximize a escalabilidade de leitura, sem deixar de atender aos requisitos de consistência de leitura de seu aplicativo. A preferência de leitura secondaryPreferred permite leituras de réplica e libera a instância primária para trabalhar mais. Para obter mais informações, consulte Leia as opções de preferência.

• Projete seu aplicativo para ser resistente no caso de erros de rede e banco de dados. Use o mecanismo de erro do driver para distinguir entre erros transitórios e persistentes. Repita os erros transitórios usando um mecanismo de recuo exponencial quando for apropriado. Certifique-se de que o seu aplicativo considerará a consistência de dados ao implementar a lógica da nova tentativa.

• Habilite a proteção contra exclusão de todos os clusters de produção ou de qualquer cluster que tenha dados valiosos. Antes de excluir um cluster do Amazon DocumentDB, faça um snapshot final. Se você estiver implantando recursos com AWS CloudFormation, ative a proteção contra rescisão. Para obter mais informações, consulte Proteção contra rescisão e proteção contra exclusão.

• Ao criar um cluster do Amazon DocumentDB, a --engine-version é um parâmetro opcional que assume como padrão a versão mais recente do mecanismo principal. A versão atual do mecanismo principal é 4.0.0. Quando novas versões principais do mecanismo forem lançadas, a versão padrão do mecanismo para --engine-version será atualizada para refletir a última versão do mecanismo principal. Como resultado, para cargas de trabalho de produção, especialmente aquelas que dependem de scripts, automação ou AWS CloudFormation modelos, recomendamos que você especifique explicitamente a --engine-version para a versão principal pretendida.

Dimensionamento de instâncias

Um dos aspectos mais importantes da escolha de um tamanho de instância no Amazon DocumentDB é a quantidade do seu RAM cache. O Amazon DocumentDB reserva um terço do RAM para seus próprios serviços, o que significa que apenas dois terços da instância estão disponíveis para RAM o cache. Portanto, é uma prática recomendada do Amazon DocumentDB escolher um tipo de instância suficiente RAM para caber no seu conjunto de trabalho (ou seja, dados e índices) na memória. Ter instâncias adequadamente dimensionadas ajuda a otimizar o desempenho geral e, potencialmente, minimizar o custo de E/S. É possível usar a calculadora de dimensionamento terceirizada do Amazon DocumentDB para estimar o tamanho da instância para um workload específico.

Para determinar se o conjunto de trabalho do seu aplicativo cabe na memória, monitore o BufferCacheHitRatio uso da Amazon CloudWatch para cada instância em um cluster que esteja sob carga.

A BufferCacheHitRatio CloudWatch métrica mede a porcentagem de dados e índices fornecidos pelo cache de memória de uma instância (versus o volume de armazenamento). De modo geral, o valor de BufferCacheHitRatio deve ser o mais alto possível, pois a leitura de dados da memória do conjunto de trabalho é mais rápida e econômica do que a leitura do volume de armazenamento. Embora seja desejável manter a BufferCacheHitRatio mais próxima de 100%, o melhor valor possível dependerá dos padrões de acesso e dos requisitos de desempenho do aplicativo. Para manter o máximo possívelBufferCacheHitRatio, é recomendável que as instâncias em seu cluster sejam provisionadas com o suficiente RAM para que possam ajustar seus índices e conjuntos de dados de trabalho na memória.

Se seus índices não couberem na memória, você verá uma BufferCacheHitRatio menor. A leitura contínua do disco gera custos adicionais de E/S e não é melhor do que a leitura da memória. Se sua BufferCacheHitRatio proporção for menor do que a esperada, aumente o tamanho da instância do seu cluster para fornecer mais RAM dados do conjunto de trabalho na memória. Se a ampliação da classe de instância resultar em um aumento drástico na BufferCacheHitRatio, o conjunto de trabalho do aplicativo não coube na memória. Continue a expansão até que BufferCacheHitRatio não aumente mais consideravelmente após uma operação de escalabilidade. Para obter informações sobre como monitorar as métricas de instância, consulte Métricas do Amazon DocumentDB.

Dependendo dos requisitos de carga de trabalho e latência, pode ser aceitável que o aplicativo tenha valores de BufferCacheHitRatio mais altos durante o uso em estado estável, mas que BufferCacheHitRatio tenha períodos de queda periodicamente, pois consultas de análise que precisam verificar uma coleção inteira são executadas em uma instância. Esses períodos de queda na BufferCacheHitRatio podem se manifestar como latência maior para consultas subsequentes que precisam preencher novamente os dados do conjunto de trabalho do volume de armazenamento de volta para o cache de buffer. Recomendamos testar primeiro as cargas de trabalho em um ambiente de pré-produção com um workload de produção representativa para entender as características de desempenho e BufferCacheHitRatio antes de implantar o workload na produção.

A BufferCacheHitRatio é uma métrica específica da instância, portanto instâncias diferentes dentro do mesmo cluster podem ter valores de BufferCacheHitRatio diferentes dependendo de como as leituras são distribuídas entre as instâncias principal e de réplica. Se o workload operacional não puder lidar com aumentos periódicos de latência de preencher o cache do conjunto de trabalho novamente após a execução de consultas de análise, tente isolar o cache de buffer do workload regular em relação ao das consultas de análise. O isolamento completo da BufferCacheHitRatio pode ser obtido direcionando consultas operacionais para a instância principal e consultas de análise somente para as instâncias de réplica. Também é possível obter isolamento parcial direcionando consultas de análise para uma instância de réplica específica, entendendo que um percentual de consultas regulares também será executado nessa réplica, podendo ser afetada.

Os valores de BufferCacheHitRatio adequados dependem do seu caso de uso e dos requisitos do aplicativo. Não há nenhum valor melhor ou mínimo para essa métrica; somente é possível decidir se a compensação de uma BufferCacheHitRatio temporariamente mais baixa é aceitável de uma perspectiva de custo e desempenho.

Trabalhar com índices

Criação de índices

Ao importar dados para o Amazon DocumentDB, você deve criar seus índices antes de importar grandes conjuntos de dados. É possível usar a ferramenta de índice do Amazon DocumentDB para extrair índices de uma instância do MongoDB ou de um diretório mongodump em execução e criar esses índices em um cluster do Amazon DocumentDB. Para obter mais orientações sobre migrações, consulte Migrar para o Amazon DocumentDB.

Seletividade do índice

Recomendamos que você limite a criação de índices a campos em que o número de valores duplicados é inferior a 1% do número total de documentos na coleção. Por exemplo, se sua coleção contiver 100.000 documentos, crie índices somente em campos em que o mesmo valor ocorrer 1000 vezes ou menos.

Escolher um índice com um alto número de valores exclusivos (ou seja, uma alta cardinalidade) garante que as operações de filtro retornem um pequeno número de documentos, gerando assim um bom desempenho durante as verificações de índice. Um exemplo de índice de alta cardinalidade é um índice exclusivo, que garante que predicados de igualdade retornem, no máximo, um documento. Exemplos de baixa cardinalidade incluem um índice sobre um campo booliano e um índice sobre o dia da semana. Devido a um desempenho insatisfatório, é improvável que índices de baixa cardinalidade sejam escolhidos pelo otimizador de consultas do banco de dados. Ao mesmo tempo, índices de baixa cardinalidade continuam a consumir recursos como espaço em disco e E/S. Como regra geral, você deve direcionar índices a campos em que a frequência típica do valor é de 1%, ou menos, do tamanho total da coleção.

Além disso, é recomendável criar apenas índices em campos comumente usados como filtro e procurar regularmente índices não usados. Para obter mais informações, consulte Como analiso o uso do índice e identifico índices não utilizados?.

Impacto dos índices na gravação de dados

Embora os índices possam melhorar o desempenho da consulta evitando a necessidade de digitalizar todos os documentos em uma coleção, essa melhoria tem com uma compensação. Para cada índice em uma coleção, sempre que um documento é inserido, atualizado ou excluído, o banco de dados deve atualizar a coleção e gravar os campos em cada um dos índices da coleção. Por exemplo, se uma coleção tiver nove índices, o banco de dados deverá executar dez gravações antes de confirmar a operação para o cliente. Assim, cada índice adicional incorre em latência de gravação adicional, E/S e aumento no armazenamento geral utilizado.

As instâncias de cluster precisam ser dimensionadas adequadamente para manter toda a memória do conjunto de trabalho. Isso evita a necessidade de ler continuamente páginas de índice do volume de armazenamento, o que afeta negativamente o desempenho e gera custos de E/S mais altos. Para obter mais informações, consulte Dimensionamento de instâncias.

Para obter um melhor desempenho, minimize o número de índices em suas coleções, adicionando apenas os índices necessários para melhorar o desempenho de consultas comuns. Embora as cargas de trabalho variem, uma boa orientação é manter cada coleção com cinco índices ou menos.

Identificação de índices ausentes

Identificar índices ausentes é uma prática recomendada que deve ser realizada regularmente. Para obter mais informações, consulte Como identifico índices ausentes?.

Identificação de índices não utilizados

Identificar e remover índices não utilizados é uma prática recomendada que deve ser realizada regularmente. Para obter mais informações, consulte Como analiso o uso do índice e identifico índices não utilizados?.

Melhores práticas de segurança

Para obter as melhores práticas de segurança, você deve usar contas AWS Identity and Access Management (IAM) para controlar o acesso às operações do Amazon DocumentDB, especialmente API operações que criam, modificam ou excluem recursos do Amazon DocumentDB. Esses recursos incluem clusters, grupos de segurança e grupos de parâmetros. Você também deve usar IAM para controlar ações que executam ações administrativas comuns, como fazer backup e restaurar clusters. Ao criar IAM funções, use o princípio do menor privilégio.

• Aplique o menor privilégio com o controle de acesso baseado em função.

• Atribua uma IAM conta individual a cada pessoa que gerencia os recursos do Amazon DocumentDB. Não use o usuário Conta da AWS raiz para gerenciar os recursos do Amazon DocumentDB. Crie um IAM usuário para todos, inclusive para você.

• Conceda a cada IAM usuário o conjunto mínimo de permissões necessárias para realizar suas tarefas.

• Use IAM grupos para gerenciar com eficiência as permissões de vários usuários. Para obter mais informações sobreIAM, consulte o Guia IAM do usuário. Para obter informações sobre as IAM melhores práticas, consulte IAMMelhores práticas.

• Mudar regularmente suas credencias do IAM.

• Configure o AWS Secrets Manager para alternar automaticamente os segredos para o Amazon DocumentDB. Para obter mais informações, consulte Rotating Your AWS Secrets Manager Secrets e Rotating Secrets for Amazon DocumentDB no Guia do usuário do Secrets AWS Manager.

• Conceda a cada usuário do Amazon DocumentDB o conjunto mínimo de permissões necessárias para realizar suas funções. Para obter mais informações, consulte Acesso ao banco de dados usando controle de acesso baseado em funções.

• Use Transport Layer Security (TLS) para criptografar seus dados em trânsito e AWS KMS criptografar seus dados em repouso.

Otimização de custo

As melhores práticas a seguir podem ajudar você a gerenciar e minimizar os custos ao usar o Amazon DocumentDB. Para obter informações sobre preços, consulte os preços do Amazon DocumentDB (com compatibilidade com o MongoDB) e os preços do Amazon DocumentDB (com compatibilidade com o MongoDB). FAQs

• Crie alertas de faturamento em limites de 50% e 75% de sua fatura esperada para o mês. Para obter mais informações sobre como criar alertas de faturamento, consulte Criar um alarme de faturamento.

• A arquitetura do Amazon DocumentDB separa armazenamento e computação, portanto, até mesmo um cluster de instância única é resiliente. O volume de armazenamento do cluster replica os dados de seis maneiras por três zonas de disponibilidade, proporcionando alta resiliência independentemente da quantidade de instâncias no cluster. Um cluster de produção típico tem três ou mais instâncias para fornecer alta disponibilidade. No entanto, é possível otimizar os custos usando um cluster de desenvolvimento de instância única quando a alta disponibilidade não é necessária.

• Para cenários de desenvolvimento e teste, interrompa um cluster quando ele não for mais necessário e inicie o cluster quando o desenvolvimento for retomado. Para obter mais informações, consulte Interrompendo e iniciando um cluster Amazon DocumentDB.

• TTLTanto os fluxos de mudança quanto os fluxos incorrem em E/S quando os dados são gravados, lidos e excluídos. Se você tiver habilitado esses recursos, mas não os estiver utilizando em seu aplicativo, desabilitar os recursos pode ajudar a reduzir custos.

Uso de métricas para identificar problemas de performance

Para identificar problemas de desempenho causados por recursos insuficientes e outros gargalos comuns, é possível monitorar as métricas disponíveis para o seu cluster do Amazon DocumentDB.

Visualização de métricas de performance

É necessário monitorar as métricas de desempenho regularmente para ver os valores médio, máximo e mínimo de uma série de intervalos de tempo. Isso ajuda a identificar quando o desempenho está degradado. Você também pode definir CloudWatch alarmes da Amazon para limites métricos específicos para que você seja alertado se eles forem atingidos.

Para solucionar problemas de desempenho, é importante entender o desempenho de linha de base do sistema. Depois de configurar um novo cluster e executá-lo com um workload típica, capture os valores médio, máximo e mínimo de todas as métricas de desempenho em diferentes intervalos (por exemplo, uma hora, 24 horas, 1 semana, 2 semanas). Isso dá a você uma ideia do que é normal. Isso ajuda a obter comparações para as horas de operação de pico e fora de pico. É possível usar essas informações para identificar quando a performance está ficando abaixo dos níveis padrão.

Você pode visualizar as métricas de desempenho usando o AWS Management Console ou AWS CLI. Para obter mais informações, consulte Visualizando CloudWatch dados.

Configurando um CloudWatch alarme

Para definir um CloudWatch alarme, consulte Usando CloudWatch alarmes da Amazon no Guia do CloudWatch usuário da Amazon.

Avaliação de métricas de performance

Uma instância tem várias categorias diferentes de métricas. Como você determina valores aceitáveis depende dessa métrica.

CPU

• CPUUtilização — A porcentagem da capacidade de processamento do computador usada.

Memória

• Memória liberável — quanto RAM está disponível na instância.

• Uso de troca - Quanto espaço de troca é usado pela instância, em megabytes.

Operações de entrada/saída

• Leitura IOPS, gravação IOPS — O número médio de operações de leitura ou gravação em disco por segundo.

• Latência de leitura, Latência de gravação – o tempo médio de uma operação de leitura ou gravação em milissegundos.

• Throughput de leitura, Throughput de gravação – o número médio de megabytes lido ou gravado no disco por segundo.

• Profundidade da fila de disco - o número de operações de E/S que aguarda pela gravação ou leitura no disco.

Tráfego de rede

• Throughput de recepção de rede, Throughput de transmissão de rede - A taxa de tráfego de rede para e a partir da instância em megabytes por segundo.

Conexões de banco de dados

• Conexões de banco de dados - O número de sessões do cliente que estão conectadas à instância do banco de dados.

De um modo geral, os valores aceitáveis para as métricas de performance dependem do aspecto da linha de base e do que o aplicativo está fazendo. Investigue variações consistentes ou tendenciais de sua linha de base.

Veja a seguir recomendações e instruções sobre os tipos específicos de métricas:

• Alto CPU consumo — Valores altos de CPU consumo podem ser apropriados, desde que estejam de acordo com suas metas para seu aplicativo (como taxa de transferência ou simultaneidade) e sejam esperados. Se seu CPU consumo for consistentemente superior a 80%, considere escalar suas instâncias.

• Alto RAM consumo — Se sua FreeableMemory métrica frequentemente fica abaixo de 10% da memória total da instância, considere escalar suas instâncias. Para obter mais informações sobre o que acontece quando sua instância do DocumentDB está com alta pressão de memória, consulte Amazon DocumentDB Resource Governance.

• Uso de troca - esta métrica deve permanecer em ou perto de zero. Se o uso de troca for significativo, considere dimensionar suas instâncias.

• Tráfego de rede - em relação ao tráfego de rede, fale com o administrador do sistema para entender qual throughput é esperado para sua rede de domínio e conexão com a Internet. Inspecione o tráfego de rede caso o throughput seja consistentemente menor do que a esperada.

• Conexões do banco de dados - considere restringir as conexões do banco de dados caso perceba um alto número de conexões de usuários em conjunto com uma diminuição no desempenho da instância e no tempo de resposta. O melhor número de conexões de usuários para sua instância varia conforme a classe da instância e a complexidade das operações em execução. Para problemas com qualquer métrica de performance, uma das primeiras coisas que é possível fazer para melhorar a performance é ajustar as consultas mais utilizadas e mais caras para ver se isso reduz a pressão sobre os recursos do sistema.

Se suas consultas forem ajustadas e o problema persistir, considere atualizar sua classe de instância do Amazon DocumentDB para uma com mais recursos (CPU,, espaço em disco, RAM largura de banda de rede, capacidade de E/S) relacionados ao problema que você está enfrentando.

Ajuste das consultas

Um dos melhores jeitos de melhorar o desempenho do cluster é ajustar as consultas mais utilizadas e que requerem mais recursos para baixar o custo de operação delas.

É possível usar o profiler (consulte Definindo o perfil das operações do Amazon DocumentDB) para registrar o tempo de execução e detalhes das operações executadas em seu cluster. O Profiler é útil para monitorar as operações mais lentas em seu cluster para ajudá-lo a melhorar o desempenho de consultas individuais e o desempenho geral do cluster.

Também é possível usar o comando explain para aprender a analisar um plano de consulta para uma consulta específica. É possível usar essas informações para modificar uma consulta ou uma coleção subjacente a fim de melhorar o desempenho da consulta (por exemplo, adicionar um índice).

TTLe cargas de trabalho de séries temporais

A exclusão de documentos resultante da expiração do TTL índice é o melhor processo. Não há garantia de que os documentos serão excluídos dentro de um período específico. Fatores como tamanho da instância, utilização de recursos da instância, tamanho do documento, taxa de transferência geral, número de índices e se os índices e o conjunto de trabalho cabem na memória podem afetar o momento em que os documentos expirados são excluídos pelo processo. TTL

Quando o TTL monitor exclui seus documentos, cada exclusão incorre em custos de E/S, o que aumenta sua fatura. Se as taxas de taxa de transferência e TTL exclusão aumentarem, você deve esperar uma fatura maior devido ao aumento do uso de E/S. No entanto, se você não criar um TTL índice para excluir documentos, mas sim segmentar documentos em coleções com base no tempo e simplesmente descartar essas coleções quando não forem mais necessárias, você não incorrerá em nenhum custo de E/S. Isso pode ser significativamente mais econômico do que usar um TTL índice.

Para cargas de trabalho de séries temporais, considere criar coleções contínuas em vez de um TTL índice, pois coleções contínuas podem ser a melhor maneira de excluir dados e consumir menos E/S. Se você tiver coleções grandes (especialmente coleções acima de 1 TB) ou se os custos de E/S de TTL exclusão forem uma preocupação, recomendamos que você particione os documentos em coleções com base no tempo e descarte as coleções quando os documentos não forem mais necessários. É possível criar uma coleção por dia ou uma por semana, dependendo da taxa de ingestão de dados. Embora os requisitos variem dependendo do aplicativo, uma boa regra é ter mais coleções menores em vez de algumas coleções grandes. Eliminar essas coleções não incorre em custos de E/S e pode ser mais rápido e econômico do que usar um índice. TTL

Migrações

Como prática recomendada, ao migrar dados para o Amazon DocumentDB, recomendamos que você crie seus índices no Amazon DocumentDB antes de migrá-los. Criar os índices primeiro pode reduzir o tempo geral e aumentar a velocidade da migração. Para fazer isso, é possível usar a Ferramenta de índice do Amazon DocumentDB. Para obter mais informações sobre migrações, consulte o Guia de migração do Amazon DocumentDB.

Também recomendamos que, antes de migrar seu banco de dados de produção, aplique uma prática recomendada de testar totalmente seu aplicativo no Amazon DocumentDB, levando em consideração a funcionalidade, o desempenho, as operações e o custo.

Trabalhando com grupos de parâmetros de cluster

Recomendamos que você experimente fazer mudanças de grupo de parâmetros do cluster em um cluster de teste antes de aplicar as alterações em seus clusters de produção. Para obter informações sobre o backup do cluster, consulte Backup e restauração no Amazon DocumentDB.

Consultas do pipeline de agregação

Ao criar uma consulta de pipeline de agregação com vários estágios e avaliar apenas um subconjunto de dados na consulta, use o estágio $match como o primeiro estágio ou no início do pipeline. Usar $match primeiro reduz o número de documentos que as etapas subsequentes dentro da consulta de pipeline de agregação precisarão processar, melhorando assim o desempenho da consulta.

batchInsert e batchUpdate

Ao realizar uma alta taxa de batchUpdate operações batchInsert e/ou simultâneas e a quantidade de FreeableMemory (CloudWatch métrica) chegar a zero em sua instância primária, você pode reduzir a simultaneidade da carga de trabalho de inserção ou atualização em lote ou, se a simultaneidade da carga de trabalho não puder ser reduzida, aumentar o tamanho da instância para aumentar a quantidade de. FreeableMemory