Las implementaciones de MongoDB pueden soportar bases de datos a gran escala con altos volúmenes de transacciones, lo que hace que el ajuste del rendimiento sea esencial. La optimización regular ayuda a identificar problemas dentro del clúster de forma temprana, permitiendo abordarlos antes de que afecten la capacidad de respuesta o la estabilidad del sistema.
Este documento aborda algunos métodos comunes para optimizar el rendimiento de su implementación mediante el ajuste del rendimiento y métricas útiles. Estos métodos se aplican tanto a clústeres de MongoDB Atlas como a implementaciones autogestionadas. Sin embargo, el proceso de ajuste es mucho más sencillo con MongoDB Atlas, que automatiza numerosas tareas y optimiza la eficiencia. Para más información sobre el rendimiento, consulte Rendimiento de MongoDB.
Ejecute sus consultas a máxima velocidad
Para garantizar un rendimiento óptimo de las queries, puedes utilizar métricas que revelen problemas de rendimiento y te indiquen qué hacer si encuentras queries lentas.
Los archivos de registro de MongoDB registran el tiempo y el método de ejecución de cada consulta, lo que permite detectar consultas lentas. El generador de perfiles de base de datos registra las consultas que superan un umbral especificado.
Si un query es lento, primero accede a tus planes del query. Para obtener más información sobre cómo encontrar datos del plan del query, consulta Explicar resultados.
Asegúrate de que la query haya realizado un escaneo de índice en lugar de un escaneo de colección.
Un escaneo de índice limita la cantidad de documentos que MongoDB inspecciona, mientras que un escaneo de colección requiere que MongoDB lea todos los documentos en una colección. Para obtener más información sobre cómo interpretar los resultados del plan, consulte Interpretar los resultados del plan explicativo.
Si ves muchos escaneos de colecciones en tus resultados del plan de explicación, considera agregar un índice.
Nota
Los índices pueden ralentizar las operaciones de guardar y actualizar, por lo que tener demasiados índices infrautilizados puede dificultar las modificaciones o inserciones de documentos, dependiendo de tu carga de trabajo.
Query Metrics
También puedes utilizar las siguientes query metrics para asegurarte de que tu query se ejecute a la máxima velocidad:
metrics.queryExecutor.scannedte indica la cantidad de documentos que se escanearon para entregar los resultados de tu query.Idealmente, la ratio de documentos escaneados frente a documentos devueltos es 1:1, lo que significa que MongoDB devuelve todos los documentos. Normalmente, la relación es mayor que 1, lo que indica que MongoDB no devuelve algunos documentos escaneados.
La razón puede ser menor que 1 o incluso 0, lo que indica una consulta cubierta donde el índice contiene todos los datos necesarios.
Si MongoDB está escaneando grandes cantidades de documentos para responder a su query, es posible que falten índices o que necesite optimizar su query.
metrics.operation.scanAndOrderindica el esfuerzo del servidor por ordenar los resultados de la query.Un número alto de escaneo y orden, como 20 o más, indica que el servidor tiene que clasificar los resultados, lo que incrementa el tiempo de resultados de query y la carga de memoria del servidor.
Para corregir un número alto de escaneo y orden, ordene los índices según los requisitos de la consulta o agregue los índices faltantes. Generalmente, ordene los índices de árbol b en orden ascendente desde el campo principal del índice, si se trata de un índice compuesto.
La métrica Número de ticket de WiredTiger refleja el rendimiento del motor de almacenamiento de WiredTiger.
Los tickets de lectura y escritura de WiredTiger son el mecanismo de control de concurrencia del motor de almacenamiento WiredTiger para gestionar el número de transacciones concurrentes. A partir de la versión 7.0, MongoDB utiliza un algoritmo dinámico para ajustar el número máximo de transacciones concurrentes del motor de almacenamiento, optimizando el rendimiento de la base de datos durante la sobrecarga del clúster.
Los tickets de lectura y escritura controlan el número máximo de transacciones simultáneas. El número de ticket de WiredTiger siempre debe ser 128. Valores persistentes inferiores a 128 indican un retraso en el servidor y posibles problemas.
Puedes usar el comando
serverStatuspara comprobar el número actual de tickets de lectura y guardar y su uso. Consulte la secciónqueues.executionpara comprender la carga actual y la disponibilidad de tickets.Para solucionar un número bajo de tickets de WiredTiger:
Asegúrese de que la funcionalidad de Ajuste Dinámico esté habilitada para gestionar la asignación de tickets automáticamente.
Asegúrate de que tu clúster tenga recursos suficientes, como CPU y memoria, para gestionar la carga de trabajo.
Si está usando MongoDB 3.2 o una versión anterior, actualícese a una versión posterior que use WiredTiger.
Si necesita ajustar manualmente el número máximo de transacciones simultáneas, puede modificar los parámetros
storageEngineConcurrentReadTransactionsstorageEngineConcurrentWriteTransactionsy.
Nota
Ten precaución al modificar storageEngineConcurrentReadTransactions y storageEngineConcurrentWriteTransactions, ya que cambiar estos ajustes puede causar problemas de rendimiento o errores. Recomendamos consultar con el soporte de MongoDB antes de cambiar estos parámetros.
Antipatrones de estructura de documentos
El plan del query no contiene ninguna métrica para revelar la estructura del documento antipatterns, pero puedes buscar antipatterns cuando depures queries lentas. Ten cuidado con las siguientes prácticas más comunes de query incorrectas que afectan el rendimiento:
Arreglos no limitados: Los arreglos en un documento que pueden crecer sin un límite de tamaño causan problemas de rendimiento, porque cada vez que se actualiza el arreglo, MongoDB debe reescribir el arreglo en el documento. Para más información, consulte Evite los arreglos ilimitados.
Documentos incrustados sin límites: MongoDB permite insertar documentos dentro de otros documentos, con hasta 128 niveles de anidamiento. Cada documento de MongoDB, incluidos los documentos incrustados, tiene un límite de tamaño de 16MB. Un número excesivo de documentos incrustados puede derivar en problemas de rendimiento.
Para mitigar el exceso de documentos incrustados, traslade los documentos incrustados a colecciones separadas y haga referencia a ellos desde el documento original. Para más información consulta Documentos hinchados.
Asegúrate de tener una base de datos TopSpeed
MongoDB cuenta con miles de métricas que rastrean todos los aspectos del rendimiento de la base de datos, incluidas la lectura, la escritura y las consultas en la base de datos, así como garantizar que tareas de mantenimiento en segundo plano, como copias de seguridad, no obstaculicen el rendimiento. Las siguientes métricas ayudan a indicar problemas con tu base de datos para que puedas asegurar su rendimiento óptimo.
atraso de la replicación
El retraso en la replicación se produce cuando un miembro secundario de un conjunto de réplicas se queda atrás del principal. Para comprender la causa del retraso, puede examinar las métricas relacionadas con el registro de operaciones. Sin embargo, los siguientes problemas son las causas más comunes del retraso en la replicación:
Un problema de red entre el primario y el secundario, que hace que los nodos sean inaccesibles
Un nodo secundario que aplica datos más lentamente que el nodo principal
Capacidad de escritura insuficiente, en cuyo caso deberías añadir más particiones
Operaciones lentas en el nodo primario, bloqueando la replicación
Problemas de rendimiento de bloqueo
El sistema de bloqueo interno de MongoDB se utiliza para admitir consultas simultáneas y evitar conflictos de escritura y lecturas inconsistentes. Los problemas de rendimiento que son el resultado de bloqueo ocurren cuando el número restante de tickets disponibles de lectura o guardado llega a cero, lo que significa que cualquier nueva solicitud de lectura o guardado será puesta en cola hasta que haya disponible un nuevo ticket de lectura o guardado.
Los problemas de rendimiento de bloqueo pueden indicar índices subóptimos y patrones de diseño de esquemas deficientes, lo que puede llevar a que los bloqueos se mantengan por más tiempo del necesario.
Abrir cursores
Si el número de cursores abiertos aumenta sin un crecimiento correspondiente del tráfico, esto podría ser el resultado de consultas mal indexadas o consultas de larga duración debido a grandes conjuntos de resultados.
Clústeres sobrecargados
Durante la optimización del rendimiento, es importante identificar cuándo el tráfico total, o el rendimiento de transacciones a través del sistema, supera la capacidad planificada del clúster. Al rastrear el crecimiento en el rendimiento, puedes ampliar la capacidad de tu clúster de manera eficiente.
Las siguientes métricas pueden ayudarte a rastrear el rendimiento de tu clúster. Para encontrar estas métricas, ejecute el comando serverStatus y examine los campos especificados a continuación.
Operaciones de lectura y escritura
Las métricas de Operaciones de Lectura y Guardar indican cuánta carga de trabajo realiza el clúster. Puedes encontrar operaciones de lectura a través del campo opcounters.query y operaciones de guardar a través de opcounters.insert, opcounters.update y opcounters.delete, que cuentan el número total de operaciones de inserción, actualizar y borrar, respectivamente.
La proporción de lecturas a escrituras depende de la naturaleza de las cargas de trabajo que se ejecutan en el clúster.
La monitorización de las operaciones de lectura y escritura a lo largo del tiempo permite establecer rangos y umbrales normales.
A medida que las tendencias en las operaciones de lectura y escritura muestran un crecimiento en el rendimiento, puedes aumentar gradualmente la capacidad.
Métricas de documentos y ejecutor de consultas
métricas de documento y query Executor indican si el clúster está demasiado ocupado. De manera similar al indicador de métricas de operaciones de lectura y guardado, no existe un número correcto o incorrecto para estas métricas, pero tener una buena idea de lo que es normal te ayuda a discernir si el bajo rendimiento se debe a un gran tamaño de carga de trabajo o a otras causas.
Para recuperar las métricas de documentos, acceda a los campos metrics.keysExamined y metrics.totalExecMicros. Para recuperar métricas de Query Executor, examine el campo metrics.fromPlanCache. Puede encontrar todos estos campos utilizando la etapa de agregación $queryStats.
MongoDB actualiza las métricas de documentos cada vez que encuentras o insertas un documento. Cuantos más documentos se encuentren, inserten, actualicen o borren, más ocupado estará el clúster.
El bajo rendimiento en un clúster que tiene capacidad suficiente suele indicar problemas de consultas.
El ejecutor de consultas te indica cuántas consultas se están procesando utilizando dos datos clave:
Escaneado: La tasa promedio por segundo durante el período de muestra seleccionado de ítems del índice escaneados durante las queries y la evaluación de planes del query.
Objetos escaneados: La tasa promedio por segundo durante el período de muestra seleccionado de documentos escaneados durante la evaluación de queries y planes del query.
Métricas de hardware y redes
Las métricas de hardware y red pueden indicar que el rendimiento está aumentando y que superará la capacidad de la infraestructura de cómputo. Estas métricas se recopilan del sistema operativo y de la infraestructura de redes. Para que estas métricas sean útiles con fines de diagnóstico, debes tener una noción de qué es lo normal.
Si está ejecutando MongoDB on-premises, podría ver métricas de hardware y de red usando Ops Manager, según su sistema operativo.
Mientras que hay muchas métricas a rastrear, algunas métricas importantes para las que conviene tener un rango básico son:
Latencia del disco
IOPS de disco
Número de conexiones
Recursos de Clúster y Clave
Un clúster de MongoDB utiliza una variedad de recursos que proporciona la infraestructura informática y de red subyacente.
Número de conexiones de clientes
La métrica de número actual de conexiones de cliente, ubicada en el campo connections.current del documento serverStatus, puede indicar la carga total de un sistema. Rastrear los rangos normales en varios momentos del día o de la semana puede ayudarte a identificar rápidamente picos en el tráfico.
Una métrica relacionada, el porcentaje de conexiones utilizadas, puede indicar cuándo MongoDB está cerca de quedarse sin conexiones disponibles.
Métricas de almacenamiento
Las métricas de almacenamiento rastrean cómo MongoDB utiliza el almacenamiento persistente. En el motor de almacenamiento WiredTiger, cada colección y cada índice son archivos individuales. Cuando actualiza un documento en una colección, MongoDB reescribe todo el documento.
Si las métricas de espacio de memoria
dbStats.dataSizecomo,,dbStats.indexSizedbStats.storageSizeo la cantidad de documentos en la base de datos muestran un cambio inesperado significativo mientras el tráfico de la base de datos permanece dentro de rangos normales, puede indicar problemas como eliminación o corrupción de datos, crecimiento inesperado de datos o cambios de índice.Una caída repentina en
dbStats.dataSizepuede indicar una gran cantidad de eliminación de datos. Si esta caída es inesperada, debe investigarla rápidamente.
Métricas de memoria
Las métricas de memoria muestran cómo MongoDB utiliza la memoria virtual de la infraestructura computacional que alberga el clúster. Puedes encontrar las métricas de memoria en el documento mem en los resultados de serverStatus.
Un número creciente de fallas de página o una cantidad creciente de datos modificados pero aún no escritos en el disco pueden indicar problemas relacionados con la cantidad de memoria disponible para el clúster.
Las métricas de caché pueden ayudar a determinar si el conjunto de trabajo está superando la caché disponible.
Errores Críticos
MongoDB crea afirmaciones principalmente a través de los errores que MongoDB captura como parte de su proceso de registro.
La supervisión del número de aserciones creadas en varios niveles de gravedad puede proporcionar una indicación inicial de problemas inesperados. Las afirmaciones pueden ser afirmaciones de mensajes, el tipo más serio, o activos de advertencia, afirmaciones regulares y afirmaciones de usuario.