El motor de almacenamiento WiredTiger es el predeterminado. Para implementaciones existentes, si no especifica el... --storageEngine o el
storage.engine configuración, la instancia puede determinar automáticamente el motor de almacenamiento utilizado para crear los archivos de datos mongod en --dbpath storage.dbPatho.
Las implementaciones alojadas en los siguientes entornos pueden utilizar el motor de almacenamiento WiredTiger:
MongoDB Atlas: El servicio totalmente gestionado para implementaciones de MongoDB en la nube
Nota
Todas las implementaciones de MongoDB Atlas utilizan el motor de almacenamiento WiredTiger.
MongoDB Enterprise: La versión basada en suscripción y autogestionada de MongoDB
MongoDB Community: La versión de MongoDB con código fuente disponible, de uso gratuito y autogestionada.
Para aprender más sobre el uso de la memoria de WiredTiger para implementaciones alojadas en MongoDB Atlas, consulta Memoria.
Operación y limitaciones
Las siguientes notas operativas y limitaciones se aplican al motor WiredTiger:
No puede fijar documentos a la caché de WiredTiger.
WiredTiger no reserva una parte de la caché para lecturas y otra para escrituras.
WiredTiger asigna su caché a toda la instancia de
mongod. WiredTiger no asigna caché a nivel de base de datos ni a nivel de colección.
Concurrencia a nivel de documento
WiredTiger utiliza control de concurrencia a nivel de documento para las operaciones de guardar. Como resultado, múltiples clientes pueden modificar diferentes documentos de una colección simultáneamente.
Para la mayoría de las operaciones de lectura y escritura, WiredTiger usa un control de concurrencia optimista. WiredTiger usa únicamente bloqueos de intención a nivel global, de base de datos y de colección. Cuando el motor de almacenamiento detecta conflictos entre dos operaciones, una de ellas incurrirá en un conflicto de escritura, lo que hará que MongoDB reintente esa operación de manera transparente.
Algunas operaciones globales, típicamente operaciones de corta duración que involucran múltiples bases de datos, todavía requieren un bloqueo global "a nivel de instancia". Algunas otras operaciones, como renameCollection, todavía requieren un bloqueo exclusivo de la base de datos en ciertas circunstancias.
Snapshots y puntos de control
WiredTiger utiliza el Control de Concurrencia Multiversión (MVCC). Al inicio de una operación, WiredTiger proporciona una snapshot de los datos en un punto en el tiempo a la operación. Una snapshot presenta una vista coherente de los datos en memoria.
Al guardar en el disco, WiredTiger guarda todos los datos de un snapshot en el disco de manera coherente en todos los archivos de datos. Los datosahora duraderos actúan como un punto de control en los archivos de datos. El punto de control garantiza que los archivos de datos sean coherentes hasta e incluyendo el último punto de control; es decir, los puntos de control pueden actuar como puntos de recuperación.
MongoDB configura WiredTiger para crear puntos de control, específicamente, escribiendo los datos del snapshot en el disco a intervalos de 60 segundos.
Durante el guardado de un nuevo punto de control, el punto de control anterior sigue siendo válido. Por lo tanto, incluso si MongoDB se detiene o encuentra un error al escribir un nuevo punto de control, al reiniciar, MongoDB puede recuperarse del último punto de control válido.
El nuevo punto de control se vuelve accesible y permanente cuando la tabla de metadatos de WiredTiger se actualiza de manera atómica para referenciar el nuevo punto de control. Una vez que el nuevo punto de control es accesible, WiredTiger libera las páginas de los puntos de control antiguos.
Usando WiredTiger, incluso sin registro en diario, MongoDB puede recuperarse desde el último punto de control; sin embargo, para recuperar los cambios realizados después del último punto de control, ejecute con registro en diario.
Nota
No se puede especificar la opción --nojournal o storage.journal.enabled: false para los miembros del conjunto de réplicas que utilizan el motor de almacenamiento WiredTiger.
Retención del historial de snapshot
A partir de MongoDB 5.0, puedes usar el parámetro minSnapshotHistoryWindowInSeconds para especificar cuánto tiempo WiredTiger conserva el historial de snapshot.
Incrementar el valor de minSnapshotHistoryWindowInSeconds incrementa el uso del disco porque el servidor debe mantener el historial de valores modificados anteriores dentro de la ventana de tiempo especificada. La cantidad de espacio en disco utilizado depende de la carga de trabajo, y las cargas de trabajo de mayor volumen requieren más espacio en disco.
MongoDB mantiene el historial de snapshot en el archivo WiredTigerHS.wt, ubicado en su dbPath especificado.
Journal
WiredTiger utiliza un registro de escritura anticipada (es decir, bitácora) en combinación con puntos de control para garantizar la durabilidad de los datos.
El diario WiredTiger persiste todas las modificaciones de datos entre puntos de control. Si MongoDB se cierra entre puntos de control, utiliza la bitácora para reproducir todos los datos modificados desde el último punto de control. Para obtener información sobre la frecuencia con la que MongoDB escribe los datos del diario en el disco, consulta Proceso de registro en la bitácora.
El diario WiredTiger se comprime utilizando la biblioteca de compresión snappy. Para especificar un algoritmo de compresión diferente o sin compresión, utilice la configuración storage.wiredTiger.engineConfig.journalCompressor. Para obtener detalles sobre cómo cambiar el compresor del diario, consulta Cambiar el compresor del diario WiredTiger.
Nota
Si un registro de registro es menor o igual a 128 bytes, que es el tamaño mínimo de registro de registro para WiredTiger, WiredTiger no comprimirá ese registro.
Puede deshabilitar el registro en las instancias independientes storage.journal.enabled configurando false en, lo que reduce la sobrecarga de mantenimiento. En las instancias independientes, no usar el registro implica que, si MongoDB sale inesperadamente, perderá todas las modificaciones de datos posteriores al último punto de control.
Nota
No se puede especificar la opción --nojournal o storage.journal.enabled: false para los miembros del conjunto de réplicas que utilizan el motor de almacenamiento WiredTiger.
Compresión
Con WiredTiger, MongoDB admite la compresión para todas las colecciones e índices. La compresión minimiza el uso del almacenamiento a costa de un mayor uso de CPU.
Por defecto, WiredTiger utiliza la compresión por bloques con la biblioteca de compresión snappy para la mayoría de las colecciones y la reducción de prefijo para todos los índices. Sin embargo, la compresión de bloques por defecto para las colecciones de series de tiempo es zstd.
Para las colecciones, también están disponibles las siguientes bibliotecas de compresión de bloques:
Para especificar un algoritmo de compresión alternativo o sin compresión, utiliza la opción storage.wiredTiger.collectionConfig.blockCompressor.
Para los índices, para desactivar la reducción de prefijo, usa la configuración storage.wiredTiger.indexConfig.prefixCompression.
Los ajustes de compresión también son configurables por colección y por índice durante la creación de colecciones e índices. Consulta Especificar opciones del motor de almacenamiento y la opción storageEngine de db.colección.createIndex().
Para la mayoría de las cargas de trabajo, la configuración predeterminada de compresión equilibra la eficiencia del almacenamiento y los requisitos de procesamiento.
La bitácora de WiredTiger también está comprimida por defecto. Para obtener información sobre la compresión del journal, consulta Bitácora.
Uso de memoria
Con WiredTiger, MongoDB utiliza tanto la caché interna de WiredTiger como la caché del sistema de archivos.
El tamaño de caché interno por defecto de WiredTiger es el mayor de los siguientes:
50 % de (RAM - 1 GB), o
256 MB.
Por ejemplo, en un sistema con un total de 4GB de RAM, la caché de WiredTiger utiliza 1.5GB de RAM (0.5 * (4 GB - 1 GB) =
1.5 GB). Por el contrario, en un sistema con un total de 1.25 GB de RAM, WiredTiger asigna 256 MB a la caché de WiredTiger porque eso es más de la mitad de la RAM total menos un gigabyte (0.5 * (1.25 GB - 1 GB) = 128 MB < 256 MB).
Nota
En algunas instancias, como cuando se ejecuta en un contenedor, la base de datos puede tener restricciones de memoria que son menores que la memoria total del sistema. En tales instancias, este límite de memoria, en lugar de la memoria total del sistema, se utiliza como la RAM máxima disponible.
Para ver el límite de memoria, consulta hostInfo.system.memLimitMB.
Por defecto, WiredTiger utiliza la compresión de bloques Snappy para todas las colecciones y la reducción de prefijo para todos los índices. Los valores de compresión por defecto son configurables a nivel global y también pueden establecerse por colección y por índice durante la creación de colecciones e índices.
Se utilizan diferentes representaciones para los datos en la caché interna de WiredTiger frente al formato en disco:
Los datos en la caché del sistema de archivos son idénticos al formato en disco, incluidos los beneficios de cualquier compresión para los archivos de datos. La caché del sistema de archivos es utilizada por el sistema operativo para reducir la E/S del disco.
Los índices cargados en la caché interna de WiredTiger tienen una representación de datos diferente al formato en disco, pero aún pueden aprovechar la reducción de prefijo de índice para reducir el uso de RAM. La reducción de prefijo de índice elimina duplicados de los prefijos comunes de los campos indexados.
Los datos de la colección en la caché interna de WiredTiger están sin comprimir y utilizan una representación diferente al formato en disco. La compresión de bloques puede proporcionar un ahorro significativo de almacenamiento en disco, pero los datos deben ser descomprimidos para que el servidor los manipule.
Con la caché del sistema de archivos, MongoDB utiliza automáticamente toda la memoria libre que no está siendo utilizada por la caché de WiredTiger ni por otros procesos.
Para ajustar el tamaño de la caché interna de WiredTiger, consulta storage.wiredTiger.engineConfig.cacheSizeGB y --wiredTigerCacheSizeGB. Se debe evitar aumentar el tamaño de la caché interna de WiredTiger por encima de su valor por defecto.