Lista de verificação de desenvolvimento

Durabilidade dos dados

• Certifique-se de que seu conjunto de réplicas inclua pelo menos três membros votantes com dados e que suas operações de gravação usem w: majority referência de escrita. Três membros votantes portadores de dados são necessários para a durabilidade dos dados em todo o conjunto de réplicas.

• Certifique-se de que todas as instâncias usem o registro no diário.

Design de esquema

Os dados no MongoDB têm um esquema dinâmico. As coleções não impõem a estrutura do documento . Isso facilita o desenvolvimento iterativo e o polimorfismo. No entanto, as coleções geralmente contêm documentos com estruturas altamente homogêneas. Para mais informações, consulte Modelagem de Dados.

• Determine o conjunto de coleções que você precisará e os índices necessários para suportar suas queries. Com exceção do índice _id , você deve criar todos os índices explicitamente: o MongoDB não cria automaticamente nenhum índice diferente de _id.

• Certifique-se de que o design do esquema ofereça suporte ao seu tipo de sistema: se você estiver planejando usar clusters fragmentados para dimensionamento horizontal, crie seu esquema para incluir uma chave de shard forte. Embora você possa alterar sua chave de shard posteriormente, é importante considerar cuidadosamente sua escolha de chave de shard para evitar problemas de escalabilidade e desempenho.

• Certifique-se de que o design do esquema não dependa de arrays indexadas que crescem em comprimento sem limites. Normalmente, o melhor desempenho pode ser alcançado quando essas arrays indexadas têm menos de 1000 elementos.

• Considere os limites de tamanho do documento ao projetar seu esquema. O limite de tamanho do documento BSON é 16MB por documento. Se você precisar de documentos maiores, use o GridFS.

Replicação

• Use um número ímpar de membros votantes para garantir que as eleições prossigam com sucesso. Você pode ter até 7 membros votantes. Se você tiver um número par de membros votantes e restrições, como custo, proíbem a adição de outro secundário para ser um membro votante, você poderá adicionar um árbitro para garantir um número ímpar de votos. Para considerações adicionais ao usar um árbitro para um conjunto de réplicas 3membros (PSA), consulte Conjunto de Réplicas de Árbitro.

  Observação

  Para as seguintes versões do MongoDB, o pv1 aumenta a probabilidade de reversões do w:1 em comparação com o pv0 (não mais suportado no MongoDB 4,0+) para conjuntos de réplicas com árbitros:

  • MongoDB 3.4.1

  • MongoDB 3,4,0

  • MongoDB 3.2.11 Ou anterior

  Consulte Versão do protocolo de conjunto de réplicas

• Certifique-se de que seus secundários permaneçam atualizados usando ferramentas de monitoramento e especificando a write concern apropriada.

• Não use leituras secundárias para dimensionar a taxa de transferência geralda leitura. Consulte: Posso usar mais nós de réplica para dimensionar para obter uma visão geral do dimensionamento de leitura. Para obter informações sobre leituras secundárias, consulte: Preferência de leitura.

Fragmentação

• Certifique-se de que sua chave de fragmento distribua a carga uniformemente em seus fragmentos. Consulte: Chaves de fragmento para obter mais informações.

• Use operações direcionadas para volumes de trabalho que precisam ser dimensionados de acordo com o número de shards.

• Para MongoDB 3.4 e versões anteriores, leia a partir dos nós primários para queries não direcionadas ou de transmissão , pois essas queries podem ser sensíveis a dados obsoletos ou órfãos.

• Para MongoDB 3.6 e posterior, os secundários não retornam mais dados órfãos, a menos que usem read concern "available" (que é o read concern padrão para leituras contra secundários quando não associado a sessões causalmente consistentes).
  A partir do MongoDB 3.6, todos os membros do conjunto de réplicas de shards mantêm metadados de chunk, permitindo-os filtrar órfãos quando não estiverem usando "available". Como tal, queries não direcionadas ou transmitidas que não estão usando "available" podem ser executadas com segurança em qualquer membro e não retornarão dados órfãos.
  A preocupação de leitura "available" pode retornar documentos órfãos de nós secundários, uma vez que não verifica se há metadados de chunk atualizados. No entanto, se o retorno de documentos órfãos for irrelevante para um aplicativo, a read concern "available" fornece a menor latência de leitura possível entre as várias read concerns.

• Faça a pré-divisão e equilibre manualmente os chunks ao inserir grandes conjuntos de dados em uma nova collection fragmentada sem hash. A pré-divisão e o balanceamento manual permitem que a carga de inserção seja distribuída entre os fragmentos, aumentando o desempenho da carga inicial.

Drivers

• Faça uso do pool de conexões. A maioria dos drivers do MongoDB suporta pool de conexões. Ajuste o tamanho do pool de conexões para se adequar ao seu caso de uso, começando com 110-115% do número típico de solicitações simultâneas de banco de dados.

• Certifique-se de que seus aplicativos lidem com erros transitórios de gravação e leitura durante as eleições do conjunto de réplicas.

• Certifique-se de que seus aplicativos lidem com solicitações com falha e tente novamente, se aplicável. Os drivers não repetem automaticamente as solicitações com falha.

• Use a lógica de backoff exponencial para novas tentativas de solicitação de banco de dados.

• Use cursor.maxTimeMS() para leituras e wtimeout para gravações se precisar limitar o tempo de execução das operações de banco de dados.