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 que contêm dados e que suas operações de gravação usem a preocupação de gravação w: majority. Três membros de votação com 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 obter mais informações, consulte Modelagem de dados no MongoDB.

• 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 escalar a taxa de transferência geral de leitura. Consulte: Posso usar mais nós de réplica para escalar para uma visão geral da escala 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.

• Os secundários não retornam mais dados órfãos, a menos que usem preocupação de leitura "available" (que é o preocupação de leitura padrão para leituras em relação aos secundários quando não está associado a sessões causalmente consistentes).

  Todos os membros do conjunto de réplicas de shards mantêm metadados de chunk, permitindo que eles filtrem os órfãos quando não estiverem usando "available". Como tal, queriesnão direcionadas ou transmitidas que não estão usando podem ser executadas com segurança em qualquer membro e não retornarão dados "available" ó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 parte atualizados. No entanto, se o retorno de documentos órfãos for irrelevante para um aplicativo, a preocupação de leitura "available" fornece a menor latência de leitura possível entre as várias preocupações de leitura.

• 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.