MongoDB - mejores prácticas arquitectónicas

Estrategia de despliegue

Cuando planifique el despliegue de MongoDB, debe tener en cuenta varias áreas clave. La más importante es el tamaño del conjunto de datos actual y anticipado. Estas dos áreas son el controlador primario para su elección de necesidades de recursos de nodos físicos individuales y guía sus planes de fragmentación. También tiene que considerar la importancia de los datos y la tolerancia que tiene sobre la posibilidad de que los datos se pierdan o se retrasen (especialmente en casos de ejemplo replicados).

Tamaño de memoria

MongoDB (como muchas aplicaciones orientadas a datos) funciona mejor cuando el conjunto de datos permanece en la memoria. Nada funciona mejor que una instancia de MongoDB que no requiere E/S de disco. Siempre que sea posible, seleccione una plataforma que tenga más RAM disponible que el tamaño del conjunto de datos de trabajo. Si el conjunto de datos supera la RAM disponible para un único nodo, considere la posibilidad de aprovechar su fragmentación. Fragmentación aumenta la cantidad de RAM disponible en un clúster para acomodar el conjunto de datos más grande. Así, maximiza el rendimiento general del despliegue. Los errores de página pueden indicar que puede estar superando la RAM disponible en su despliegue. Debe considerar aumentar la RAM disponible.

Tipo de disco

Si la velocidad no es un problema, o si tiene un conjunto de datos mayor que la que puede soportar la estrategia de memoria disponible, es importante un tipo de disco apropiado para el despliegue. IOPS es clave en la selección del tipo de disco. Cuando mayor sea IOPS, mejor será el rendimiento de MongoDB. Los discos locales deben utilizarse, si es posible, porque el almacenamiento en red puede causar una latencia alta y un rendimiento deficiente para el despliegue. Se aconseja que utilice RAID 10 para matrices de discos.

CPU

La velocidad de reloj y el número de procesadores disponibles se convierte en un tema en el que pensar si desea utilizar map-reduce. Sin embargo, al ejecutar una instancia de MongoDB con la mayoría de los datos en memoria, la velocidad de reloj puede repercutir en el rendimiento. Si el sistema se ejecuta bajo estas circunstancias y desea maximizar sus operaciones por segundo, considere una estrategia de despliegue que incluya una CPU con una velocidad de bus de reloj alta.

Réplica

La réplica proporciona alta disponibilidad de los datos si falla un nodo en el clúster. Para obtener mejores resultados, replique con al menos tres nodos en cualquier despliegue de MongoDB. La configuración más común para la réplica con tres nodos es un despliegue 2x1 que tenga dos nodos primarios en un único centro de datos con un servidor de seguridad en un centro de datos secundario.

Fragmentación

[: #dbt-sharding]

Si anticipa un conjunto de datos grande, se recomienda desplegar un despliegue fragmentado de MongoDB. Puede utilizar la fragmentación para particionar el conjunto de datos en varios nodos. MongoDB puede distribuir automáticamente los datos entre los nodos del clúster. O bien, puede definir una clave fragmentada y crear la fragmentación basada en rango para dicha clave. La fragmentación puede ayudar a escribir el rendimiento, por lo que es posible que pueda fragmentar incluso si el conjunto de datos es pequeño pero necesita un número alto de actualizaciones o inserciones. Al desplegar un conjunto fragmentado, MongoDB solo requiere tres instancias de servidor de configuración que sean tiempos de ejecución de Mongo especializados para realizar el seguimiento de la configuración fragmentada actual. La pérdida de uno de estos nodos provoca que el clúster pase a un modo de sólo lectura para la configuración y requiere que todos los nodos vuelvan a estar en línea antes de poder realizar cualquier cambio en la configuración.

Modalidad de grabación segura

Tiene varias opciones para escribir modalidades de seguridad que controlan la forma en que MongoDB maneja la persistencia de los datos en el disco. Es importante considerar qué estrategia se adapta mejor a sus necesidades para la integridad de datos y su rendimiento. Tiene disponibles las siguientes modalidades de seguridad de escritura:

• Ninguno- Proporciona una estrategia de escritura diferida no bloqueante que ayuda al alto rendimiento. Sin embargo, el fallo de un nodo y la pérdida de datos son una pequeña posibilidad. También es posible que los datos que se escriben en un nodo de un clúster no estén disponibles inmediatamente en todos los nodos de dicho clúster para la coherencia de lectura. La modalidad Ninguno no proporciona ninguna protección de datos para los errores de red. Esta modalidad no es en absoluto fiable y solo se utiliza cuando el rendimiento es una prioridad y la integridad de datos no es un problema.
• Normal: Es el valor predeterminado para MongoDB. El modo normal también es una estrategia de escritura diferida no bloqueante.
• Seguro - Bloquea hasta que MongoDB reconoce que ha recibido la solicitud de escritura, pero bloquea hasta que se completado la escritura. La modalidad Seguro proporciona un mejor nivel de integridad de datos y de coherencia de lectura dentro de un clúster.
• Diario seguro: Proporciona una opción de recuperación para MongoDB. La modalidad de diario seguro se asegura de que se reconocen los datos y de que se ha completado una actualización de diario antes de que se devuelva.
• Fsync: Proporciona el nivel más alto de integridad de datos y bloquea hasta que se produce una escritura física de los datos. El uso de Fsync viene con una degradación en el rendimiento y solo lo utiliza si la integridad de datos es el problema principal para su aplicación.

Probar el despliegue

10gen tiene varias herramientas para ayudarle a cargar la prueba del despliegue. Una herramienta de consola, benchRun, puede ejecutar operaciones desde una prueba de JavaScript. benchRun devuelve información de operación y números de latencia para cada operación. Si se necesita información más detallada sobre la instancia de MongoDB, considere la posibilidad de ejecutar el mandato mongostat o MMS para supervisar el despliegue durante la prueba.

Instalación

Hay varias consideraciones a tener en cuenta cuando instale MongoDB que le pueden ayudar a crear una solución estable y orientada al rendimiento. 10gen recomienda utilizar CentOS (64 bits) si es posible. Evite desplegar en sistemas operativos de 32 bits y en sistemas operativos Windows. Estos sistemas proporcionan una plataforma de despliegue deficiente. Los sistemas operativos de 32 bits tienen límites de tamaño de archivo que causan problemas y Windows puede ocasionar problemas de rendimiento si el sistema operativo utiliza la memoria virtual para compensar la falta de RAM en el despliegue. De forma predeterminada, IBM Cloud proporciona sistemas operativos CentOS de 64 bits para todos los despliegues de servidor diseñados.

Además, asegúrese de hacer la siguiente modificación a la instalación del sistema operativo base para maximizar el rendimiento:

• Establezca los valores predeterminados de lectura anticipada de SSD en 16 bloques: Las unidades SSD tienen tiempos de búsqueda excelentes que permiten reducir la Lectura anticipada a 16 bloques. Los discos giratorios pueden requerir un ligero almacenamiento intermedio, por lo que estos discos se establecen en 32 bloques.
• noatime: Noatime elimina la necesidad de que el sistema escriba en el sistema de archivos para los archivos que se van a leer. Esto significa que el acceso a los archivos es más rápido y el disco se desgasta menos.
• Desactivar NUMA en BIOS Linux, NUMA y MongoDB generalmente no funcionan juntos. Si está ejecutando MongoDB en hardware NUMA, se recomienda que lo desactive (en ejecución con una política de memoria de intercalación). Si no lo hace, se pueden dar problemas como ralentizaciones masivas o tiempo de CPU de sistema alto.
• Establezca ulimit: El ulimit se establece en 64000 para archivos abiertos y 32000 para procesos de usuario. Estos ulimits evitan anomalías debido a una pérdida de descriptores de archivos o de procesos de usuarios disponibles.
• Utilice ext4: Ext3 es lento en la asignación de archivos (o en su eliminación). Además, el acceso dentro de los archivos grandes es deficiente con ext3.

Por defecto, estas alteraciones se establecen en todos los servidores IBM Cloud.

También se recomienda que los volúmenes de Diario y de Datos sean volúmenes físicos distintos. Si los directorios de Diario y de Datos residen en un único volumen físico, los vaciados del Diario interrumpen el acceso de los datos y proporcionan picos de alta latencia dentro del despliegue de MongoDB.

Operaciones

Después de que se promocione un despliegue de MongoDB a producción, tenga en cuenta las siguientes recomendaciones para la supervisión y la optimización del rendimiento.

• Asegúrese de que el agente MMS se está ejecutando en todas las instancias de MongoDB, lo que ayuda a supervisar el estado y el rendimiento del despliegue. El agente MMS proporciona datos de depuración útiles a 10gen durante las interacciones de soporte.
• El mandato mongostat también proporciona información de tiempo de ejecución sobre el rendimiento de un nodo MongoDB.

Si cualquiera de estas herramientas descubre problemas de rendimiento, la fragmentación o el indexado puede ayudar a corregir estos problemas.

• Cree índices para una implantación de MongoDB si las herramientas de supervisión indican que las consultas basadas en campos funcionan mal. Para ayudar a mejorar el rendimiento, utilice siempre índices al consultar datos basados en campos distintos.
• Utilice la fragmentación cuando el rendimiento global del nodo sufra debido a un conjunto de datos de funcionamiento grande. Asegúrese de fragmentar antes de llegar al color rojo. El sistema divide bloques solo para fragmentar al insertar o al actualizar. Si espera demasiado tiempo para fragmentar, puede tener una distribución desigual.