Lista de comprobación de desarrollo

Durabilidad de los datos

• Asegúrate de que tu set de réplicas incluya al menos tres nodos votantes con datos y que tus operaciones de guardar utilicen w: majority nivel de confirmación de escritura (write concern). Se requieren tres nodos con votación de datos para lograr una durabilidad de datos a nivel de set de réplicas.

• Asegúrate de que todas las instancias utilicen registrar en la bitácora.

Diseño de esquemas

Los datos en MongoDB tienen un esquema dinámico. Las colecciones no aplican la estructura del documento. Esto facilita el desarrollo iterativo y el polimorfismo. No obstante, las colecciones suelen contener documentos con estructuras altamente homogéneas. Consulta Conceptos de Modelado de Datos para obtener más información.

• 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úrate de que el diseño del esquema sea compatible con tu tipo de implementación: si planeas usar clústeres fragmentados para la escalabilidad horizontal, diseña tu esquema para incluir una clave de partición robusta. Si bien puedes cambiar tu clave de partición más adelante, es importante considerar cuidadosamente tu elección de clave de partición para evitar problemas de escalabilidad y rendimiento.

• Asegúrate de que el diseño de esquema no dependa de arreglos indexados que puedan crecer sin límite. Por lo general, se puede lograr el mejor rendimiento cuando dichos arreglos indexados tienen menos de 1000 elementos.

• Ten en cuenta los límites de tamaño del documento al diseñar el esquema. El límite de Tamaño de documento BSON es de 16MB por documento. Si necesita documentos más grandes, use 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 utilices lecturas secundarias para escalar el rendimiento general de lectura. Consulta: ¿Puedo utilizar más nodos réplica para escalar? para obtener una visión general del escalado de lecturas. Para 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.

• Usar operaciones dirigidas para cargas de trabajo que necesitan escalar con el número de particiones.

• 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

• Aprovechar el agrupamiento de conexiones. La mayoría de los controladores de MongoDB admiten el agrupamiento de conexiones. Ajustar el tamaño del pool de conexiones para adaptarse a su caso de uso, comenzando en el 110-115% del número promedio 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úrate de que tus aplicaciones gestionen las solicitudes fallidas y las reintenten si es aplicable. Los drivers no reintentan automáticamente las solicitudes que han fallado.

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