Lista de comprobación de desarrollo

Durabilidad de los datos

• Asegúrese de que su conjunto de réplicas incluya al menos tres miembros con derecho a voto que contengan datos y que sus operaciones de escritura utilicen w: majority Escribir preocupación. Se requieren tres miembros con derecho a voto para garantizar la durabilidad de los datos en todo el conjunto de réplicas.

• Asegúrese de que todas las instancias utilicen registro en diario.

Diseño de esquemas

Los datos en MongoDB tienen un esquema dinámico. Las colecciones no imponen la estructura del documento. Esto facilita el desarrollo iterativo y el polimorfismo. Sin embargo, las colecciones suelen contener documentos con estructuras muy homogéneas. Para más información, consulte Modelado de datos en MongoDB.

• Determine el conjunto de colecciones que necesitará y los índices necesarios para soportar las queries. Con la excepción del índice _id, debe crear todos los índices explícitamente: MongoDB no crea automáticamente ningún índice salvo _id.

• Asegúrese de que el diseño de su esquema sea compatible con su tipo de implementación: si planea usar clústeres fragmentados para escalamiento horizontal, diseñe su esquema para incluir una clave de partición segura. Si bien puede cambiar su clave de partición más adelante, es importante considerar cuidadosamente su elección para evitar problemas de escalabilidad y rendimiento.

• Asegúrese de que el diseño de su esquema no dependa de matrices indexadas cuya longitud crece sin límite. Normalmente, el mejor rendimiento se logra cuando dichas matrices indexadas tienen menos de 1000 elementos.

• Tenga en cuenta los límites de tamaño de los documentos al diseñar su esquema. El límite de tamaño de documento BSON es de 16MB por documento. Si necesita documentos más grandes, utilice GridFS.

Replicación

• Se debe utilizar un número impar de miembros votantes para asegurar que las elecciones se lleven a cabo exitosamente. Puede tener hasta 7 miembros votantes. Si tiene un número par de miembros votantes, y restricciones como el costo, impiden añadir otro secundario para que sea un miembro votante, puede añadir un árbitro para asegurar un número impar de votos. Para más consideraciones sobre el uso de un árbitro en un set de réplicas de 3nodos (P-S-A), consulte Árbitro del set de réplicas.

• Asegúrese de que sus archivos secundarios se mantengan actualizados mediante el uso de herramientas de monitoreo y especificando los problemas de escritura apropiados.

• No utilice lecturas secundarias para aumentar el rendimiento general de lectura. Consulte: ¿Puedo usar más nodos de réplica para escalar?Para obtener una descripción general del escalado de lecturas. Para obtener información sobre lecturas secundarias, consulte: Preferencia de lectura.

particionado

• Asegúrese de que su clave de fragmento distribuya la carga uniformemente entre sus fragmentos. ConsulteClaves de fragmento para obtener más información.

• Utilice operaciones específicas para cargas de trabajo que necesitan escalar con la cantidad de fragmentos.

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

• Pre-divida y equilibra manualmente los fragmentos al insertar conjuntos de datos grandes en una nueva colección particionada no encriptada. La predivisión y el equilibrio manual permiten que la carga de inserción se distribuya entre las particiones, aumentando así el rendimiento de la carga inicial.

Controladores

• Utilice la agrupación de conexiones. La mayoría de los controladores de MongoDB la admiten. Ajuste el tamaño de la agrupación de conexiones según su caso, comenzando con un 110-115% del número típico de solicitudes simultáneas a la base de datos.

• Asegúrese de que sus aplicaciones manejen errores transitorios de escritura y lectura durante las elecciones del conjunto de réplicas.

• Asegúrese de que sus aplicaciones gestionen las solicitudes fallidas y las reintenten si corresponde. Los controladores no reintentan automáticamente las solicitudes fallidas.

• Utilice la lógica de retroceso exponencial para los reintentos de solicitud de base de datos.

• Utilice para cursor.maxTimeMS() wtimeout lecturas y para escrituras si necesita limitar el tiempo de ejecución de las operaciones de la base de datos.