Menu Docs
Página inicial do Docs
/

Lista de verificação de desenvolvimento

A lista de verificação a seguir, juntamente com aLista de verificação de operações para implantações autogerenciadas , fornece recomendações para ajudá-lo a evitar problemas na implantação de produção do MongoDB .

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

Data in MongoDB has a dynamic schema. Collections do not enforce document structure. This facilitates iterative development and polymorphism. Nevertheless, collections often hold documents with highly homogeneous structures. For more information, see Data Modeling in 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.

  • Ensure that your schema design supports your deployment type: if you are planning to use sharded clusters for horizontal scaling, design your schema to include a strong shard key. While you can change your shard key later, it is important to carefully consider your shard key choice to avoid scalability and perfomance issues.

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

  • Use an odd number of voting members to ensure that elections proceed successfully. You can have up to 7 voting members. If you have an even number of voting members, and constraints, such as cost, prohibit adding another secondary to be a voting member, you can add an arbiter to ensure an odd number of votes. For additional considerations when using an arbiter for a 3-member replica set (P-S-A), see Replica Set Arbiter.

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

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

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

Voltar

Instalar libmongocrypt

Nesta página