Si bien este motor de almacenamiento ha quedado obsoleto desde la versión 4.0 de MongoDB, tiene algunas características importantes. MMAPv1 es el motor de almacenamiento original en MongoDB y se basa en archivos mapeados. Solo la arquitectura Intel de 64 bits (x86_64) es compatible con este motor de almacenamiento.
MMAPv1 impulsa un excelente rendimiento en cargas de trabajo con...
- Grandes actualizaciones
- Lecturas de alto volumen
- Inserciones de alto volumen
- Alta utilización de la memoria del sistema
Arquitectura MMAPv1
MMAPv1 es un sistema basado en árbol B que potencia muchas de las funciones, como la interacción de almacenamiento y la gestión de memoria del sistema operativo.
Era la base de datos predeterminada de MongoDB para versiones anteriores a la 3.2 hasta la introducción del motor de almacenamiento WiredTiger. Su nombre proviene del hecho de que utiliza archivos mapeados en memoria para acceder a los datos. Lo hace cargando y modificando directamente el contenido del archivo, que se encuentra en una memoria virtual a través de una metodología de llamada al sistema mmap().
Todos los registros están ubicados de forma contigua en el disco y, en el caso de que un documento sea más grande que el tamaño de registro asignado, MongoDB asigna un nuevo registro. Para MMAPv1, esto es ventajoso para el acceso secuencial a datos, pero al mismo tiempo es una limitación, ya que conlleva un costo de tiempo, ya que todos los índices de los documentos deben actualizarse y esto puede provocar la fragmentación del almacenamiento.
La arquitectura básica del motor de almacenamiento MMAPv1 se muestra a continuación.
Como se mencionó anteriormente, si el tamaño de un documento supera el tamaño de registro asignado, dará como resultado una reasignación que no es algo bueno. Para evitar esto, el motor MMAPv1 utiliza una asignación de potencia de 2 tamaños para que cada documento se almacene en un registro que contiene el documento en sí (incluido un espacio adicional conocido como relleno). Luego, el relleno se usa para permitir cualquier crecimiento del documento que pueda resultar de las actualizaciones mientras reduce las posibilidades de reasignaciones. De lo contrario, si se producen reasignaciones, es posible que termine teniendo una fragmentación del almacenamiento. El relleno intercambia espacio adicional para mejorar la eficiencia y, por lo tanto, reduce la fragmentación. Para cargas de trabajo con grandes volúmenes de inserciones, actualizaciones o eliminaciones, la asignación de potencia de 2 debe ser la más preferida, mientras que la asignación de ajuste exacto es ideal para recopilaciones que no implican ninguna carga de trabajo de actualización o eliminación.
Potencia de asignación de tamaño 2
Para un crecimiento fluido de los documentos, esta estrategia se emplea en el motor de almacenamiento MMAPv1. Cada registro tiene un tamaño en bytes que es una potencia de 2, es decir (32, 64, 128, 256, 512...2MB). Siendo 2 MB el límite superior predeterminado, cualquier documento que supere este límite, su memoria se redondeará al múltiplo más cercano de 2 MB. Por ejemplo, si un documento tiene 200 MB, este tamaño se redondeará a 256 MB y 56 MB de espacio comercial estarán disponibles para cualquier crecimiento adicional. Esto permite que los documentos crezcan en lugar de desencadenar una reasignación que el sistema deberá realizar cuando los documentos alcancen su límites de espacio disponible.
Méritos de las asignaciones de tamaño de poder 2
- Reutilización de registros liberados para reducir la fragmentación: Con este concepto, los registros se cuantifican en memoria para tener un tamaño fijo que sea lo suficientemente grande como para acomodar nuevos documentos que encajarían en el espacio asignado creado por la eliminación o reubicación de un documento anterior.
- Reduce los movimientos de documentos: Como se mencionó anteriormente, de forma predeterminada, las inserciones y actualizaciones de MongoDB que hacen que el tamaño del documento sea mayor que el tamaño del registro establecido también darán como resultado la actualización de los índices. Esto simplemente significa que los documentos se han movido. Sin embargo, cuando hay suficiente espacio para crecer dentro de un documento, el documento no se moverá, por lo tanto, habrá menos actualizaciones en los índices.
Uso de memoria
Toda la memoria libre en la máquina en el motor de almacenamiento MMAPv1 se usa como caché. Los conjuntos de trabajo del tamaño correcto y el rendimiento óptimo se logran a través de un conjunto de trabajo que se ajusta a la memoria. Además, cada 60 segundos, el MMAPv1 descarga los cambios de los datos en el disco y, por lo tanto, los guarda en la memoria caché. Este valor se puede cambiar de modo que el lavado se realice con frecuencia. Debido a que toda la memoria libre se usa como caché, no se sorprenda de que las herramientas de monitoreo de recursos del sistema indiquen que MongoDB usa mucha memoria ya que este uso es dinámico.
Méritos del motor de almacenamiento MMAPv1
- Reducción de la fragmentación en disco cuando se utiliza la estrategia de preasignación.
- Lecturas muy eficientes cuando el conjunto de trabajo se ha configurado para caber en la memoria.
- Actualizaciones en el lugar, es decir, las actualizaciones de campos individuales pueden dar como resultado que se almacenen más datos y, por lo tanto, mejorar la actualización de documentos grandes con un mínimo de escritores simultáneos.
- Con una cantidad baja de escritores simultáneos, el rendimiento de escritura se puede mejorar a través del concepto de vaciado de datos al disco con frecuencia.
- El bloqueo a nivel de colección facilita las operaciones de escritura. El esquema de bloqueo es uno de los factores más importantes en el rendimiento de la base de datos. En este caso, solo 1 cliente puede acceder a la base de datos a la vez. Esto crea un escenario en el que las operaciones fluyen más rápido que cuando el motor de almacenamiento las presenta de manera serial.
Limitaciones del motor de almacenamiento MMAPv1
- Alta utilización del espacio al realizar iteraciones. MMAPv1 carece de una estrategia de compresión para el sistema de archivos, por lo que hace una asignación excesiva de espacio de registro.
- Restricción de acceso a la colección para muchos clientes al realizar una operación de escritura. MMAPv1 utiliza una estrategia de bloqueo de nivel de colección, lo que significa que 2 o más clientes no pueden acceder a la misma colección al mismo tiempo, por lo que una escritura bloquea todas las lecturas de esta colección. Esto conduce a una concurrencia aproximada que hace que sea imposible escalar el motor MMAPv1.
- El bloqueo del sistema puede provocar la pérdida de datos si la opción de registro en diario no está habilitada. Sin embargo, incluso si lo es, la ventana es demasiado pequeña pero al menos puede protegerlo de un gran escenario de pérdida de datos.
- Utilización ineficiente del almacenamiento. Al utilizar la estrategia de asignación previa, algunos documentos ocuparán más espacio en el disco que los datos mismos.
- Si el tamaño del conjunto de trabajo supera la memoria asignada, el rendimiento se reduce en gran medida. Además, documentar un crecimiento significativo después del almacenamiento inicial puede desencadenar E/S adicionales y, por lo tanto, causar problemas de rendimiento.
Comparación de motores de almacenamiento MMAPv1 y WiredTiger
| Característica clave | MMAPv1 | Tigre cableado |
|---|---|---|
| Rendimiento de la CPU | Desafortunadamente, agregar más núcleos de CPU no aumenta el rendimiento | El rendimiento mejora con los sistemas multinúcleo |
| Cifrado | Debido a que se utilizan archivos mapeados en memoria, no admite ningún cifrado | El cifrado de los datos en tránsito y el resto está disponible tanto en MongoDB Enterprise como en la instalación Beta |
| Escalabilidad | Las escrituras simultáneas que resultan del bloqueo a nivel de colección hacen que sea imposible escalar horizontalmente. | Altas posibilidades de escalar horizontalmente, ya que el nivel de bloqueo mínimo es el documento en sí. |
| Afinación | Muy pocas posibilidades de ajustar este motor de almacenamiento | Se pueden realizar muchos ajustes en torno a variables como el tamaño de la memoria caché, los intervalos de los puntos de control y los tickets de lectura/escritura |
| Compresión de datos | Sin compresión de datos, por lo tanto, se puede usar más espacio | Métodos de compresión Snappy y zlib disponibles, por lo que los documentos pueden ocupar menos espacio que en MMAPv1 |
| Transacciones atómicas | Solo aplicable para un único documento | A partir de la versión 4.0, se admite la transacción atómica en varios documentos. |
| Memoria | Toda la memoria libre en la máquina se usa como caché | Se utiliza el caché del sistema de archivos y el caché interno |
| Actualizaciones | Admite actualizaciones en el lugar, por lo que se destaca en cargas de trabajo con inserciones de gran volumen, lecturas y actualizaciones en el lugar | No admite actualizaciones en el lugar. Se debe reescribir todo el documento. |
Conclusión
Al llegar a la selección del motor de almacenamiento para una base de datos, muchas personas no saben cuál elegir. La elección normalmente se basa en la carga de trabajo a la que estará sujeto. En un indicador general, el MMAPv1 sería una mala elección y es por eso que MongoDB hizo muchos avances en la opción WiredTiger. Sin embargo, aún puede superar a otros motores de almacenamiento según el caso de uso, por ejemplo, cuando solo necesita realizar cargas de trabajo de lectura o necesita almacenar muchas colecciones separadas con documentos grandes en los que 1 o 2 campos se actualizan con frecuencia.
