Con el motor de almacenamiento MMAPv1, las actualizaciones en el lugar se destacan con frecuencia como una estrategia de optimización porque los índices de un documento apuntan directamente a las ubicaciones de los archivos y las compensaciones. Mover un documento a una nueva ubicación de almacenamiento (particularmente si hay muchas entradas de índice para actualizar) tiene más gastos generales para MMAPv1 que una actualización en el lugar que solo tiene que actualizar los campos modificados. Ver:Características de almacenamiento de registros en MMAPv1.
WiredTiger no admite actualizaciones en el lugar porque internamente usa MVCC (control de concurrencia de múltiples versiones), que es comúnmente utilizado por los sistemas de administración de bases de datos. Esta es una mejora técnica significativa con respecto a la vista simplista de MMAP y permite crear funciones más avanzadas, como niveles de aislamiento y transacciones. Los índices de WiredTiger tienen un nivel de direccionamiento indirecto (hacen referencia a un ID de registro interno en lugar de la ubicación y el desplazamiento del archivo), por lo que los movimientos de documentos en el nivel de almacenamiento no son un punto crítico significativo.
Sin embargo, este artículo también dice que "Aunque [WiredTiger] no permite actualizaciones en el lugar, aún podría funcionar mejor que MMAP para muchas cargas de trabajo".
Significa que aunque MMAPv1 puede tener una ruta más eficiente para las actualizaciones en el lugar, WiredTiger tiene otras ventajas, como la compresión y el control de concurrencia mejorado. Tal vez podría crear una carga de trabajo que consista solo en actualizaciones locales de algunos documentos que podrían funcionar mejor en MMAPv1, pero las cargas de trabajo reales suelen ser más variadas. La única forma de confirmar el impacto de una carga de trabajo determinada sería probar en un entorno representativo.
Sin embargo, la elección general de MMAPv1 frente a WiredTiger es discutible si desea planificar el futuro:WiredTiger ha sido el motor de almacenamiento predeterminado desde MongoDB 3.2 y MMAPv1 no admite algunas funciones de productos más nuevos. Por ejemplo, MMAPv1 no es compatible con Majority Read Concern, lo que a su vez significa que no se puede usar para servidores de configuración de conjunto de réplicas (requerido para la fragmentación en MongoDB 3.4+) o Change Streams (MongoDB 3.6+). MMAPv1 quedará obsoleto en la próxima versión principal de MongoDB (4.0) y actualmente está programado para eliminarse en MongoDB 4.2.
¿Cuáles son las implicaciones exactas que debo tener en cuenta cuando uso WiredTiger? Por ejemplo, sin actualizaciones en el lugar, ¿crecerá rápidamente el tamaño de la base de datos?
Los resultados del almacenamiento dependen de varios factores, incluido el diseño de su esquema, la carga de trabajo, la configuración y la versión del servidor MongoDB. MMAPv1 y WiredTiger usan diferentes estrategias de asignación de registros, pero ambos intentarán usar el espacio preasignado que está marcado como libre/reutilizable. En general, WiredTiger es más eficiente con el uso del espacio de almacenamiento y también tiene la ventaja de la compresión de datos e índices. MMAPv1 asigna espacio de almacenamiento adicional para intentar optimizar las actualizaciones en el lugar y evitar movimientos de documentos, aunque puede elegir una estrategia "sin relleno" para colecciones donde la carga de trabajo no cambia el tamaño del documento con el tiempo.
Ha habido una inversión significativa en mejorar y ajustar WiredTiger para diferentes cargas de trabajo desde que se introdujo por primera vez en MongoDB 3.0, por lo que recomendaría enfáticamente realizar pruebas con la última serie de versiones de producción para obtener el mejor resultado. Si tiene una pregunta específica sobre el diseño del esquema y el crecimiento del almacenamiento, le sugiero que publique los detalles en DBA StackExchange para su discusión.
También aprendí que WiredTiger en MongoDB 3.6 agregó la capacidad de almacenar deltas en lugar de volver a escribir todo el documento (https://jira.mongodb.org/browse/DOCS-11416). ¿Qué significa esto exactamente?
Este es un detalle de implementación que mejora las estructuras de datos internas de WiredTiger para algunos casos de uso. En particular, WiredTiger en MongoDB 3.6+ puede ser más eficiente al trabajar con pequeños cambios en documentos grandes (en comparación con versiones anteriores). La memoria caché de WiredTiger debe poder devolver varias versiones de los documentos siempre que los utilicen sesiones internas abiertas (MVCC, como se mencionó anteriormente), por lo que para documentos grandes con pequeñas actualizaciones podría ser más eficiente almacenar una lista de deltas. Sin embargo, si se acumulan demasiados deltas (o si los deltas cambian la mayoría de los campos de un documento), este enfoque podría ser menos eficaz que mantener varias copias del documento completo.
Cuando los datos se envían al disco a través de un punto de control, aún se debe escribir una versión completa del documento. Si desea obtener más información sobre algunas de las funciones internas, hay una serie de videos MongoDB Path To Transactions que siguen el desarrollo de funciones para admitir transacciones de documentos múltiples en MongoDB 4.0.
Además, lo que no entiendo es que hoy en día la mayoría (si no todos) los discos duros tienen un tamaño de sector de 4096 bytes, por lo que no puede escribir en el disco duro solo 4 bytes (por ejemplo), sino que debe escribir el bloque completo de 4096 bytes (así que léalo primero, actualice los 4 bytes y luego escríbalo). Como la mayoría de los documentos suelen tener menos de 4096 bytes, esto significa que es necesario volver a escribir todo el documento en cualquier caso (incluso con MMAP). ¿Qué me perdí?
Sin profundizar demasiado en los detalles de implementación y tratar de explicar todas las partes móviles involucradas, considere cómo se aplican los diferentes enfoques a las cargas de trabajo donde se actualizan muchos documentos (en lugar de a nivel de documento único), así como el impacto en el uso de la memoria (antes los documentos se escriben en el disco). Según factores como el tamaño y la compresión del documento, un solo bloque de E/S puede representar desde una fracción de un documento (tamaño máximo de 16 MB) hasta varios documentos.
En MongoDB, el flujo general es que los documentos se actualizan en una vista en memoria (por ejemplo, la memoria caché de WiredTiger) y los cambios se conservan en el disco en un formato de diario rápido de solo anexar antes de ser vaciados periódicamente a los archivos de datos. Si el sistema operativo solo tiene que escribir bloques de datos que han cambiado, tocar menos bloques de datos requiere menos E/S general.
