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 forçam 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 obter mais informações, consulte Modelagem de dados.

• Determine o conjunto de coleções necessárias e os índices necessários para dar suporte às suas queries. Com exceção do índice _id, você deve criar todos os índices explicitamente: o MongoDB não cria automaticamente nenhum índice além do _id.

• Garanta que o design do seu esquema suporte o tipo de implementação: se você planeja utilizar clusters fragmentados para possibilitar dimensionamento horizontal, projete o seu esquema para incluir uma chave de fragmento forte. Embora você possa alterar sua chave de fragmento posteriormente, é importante pensar com cuidado na escolha da chave de fragmento para evitar problemas de escalabilidade e desempenho.

• Certifique-se de que o design do esquema não dependa de matrizes indexadas que crescem em comprimento sem limite. Normalmente, o melhor desempenho pode ser alcançado quando essas matrizes 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 é de 16 MB por documento. Se você precisar de documentos maiores, use GridFS.

Replicação

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

• Certifique-se de que seus secundários permaneçam atualizados usando ferramentas de monitoramento e especificando a preocupação de gravação apropriada.

• Não use leituras secundárias para dimensionar a taxa de transferência geral da 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 cargas de trabalho que precisam ser dimensionadas com o número de estilhaços.

• Secondaries no longer return orphaned data unless using read concern "available" (which is the default read concern for reads against secondaries when not associated with causally consistent sessions).
  All members of the shard replica set maintain chunk metadata, allowing them to filter out orphans when not using "available". As such, non-targeted or broadcast queries that are not using "available" can be safely run on any member and will not return orphaned data.
  The "available" read concern can return orphaned documents from secondary members since it does not check for updated chunk metadata. However, if the return of orphaned documents is immaterial to an application, the "available" read concern provides the lowest latency reads possible among the various read concerns.

• Pré-dividir e balancear manualmente partes ao inserir grandes conjuntos de dados em uma nova coleção fragmentada sem hash. A pré-divisão e o balanceamento manual permitem que a carga da 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 é compatível com pool de conexões. Ajuste o tamanho do pool de conexões para se adequar ao seu caso de uso, começando em 110-115% do número típico de solicitações de banco de dados simultâneas.

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

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

• Use a lógica de recuo 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 para operações de banco de dados.