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 de transacciones (lectura y escritura)
A partir de la versión 7.0, MongoDB utiliza un algoritmo por defecto para ajustar dinámicamente el número máximo de transacciones concurrentes del motor de almacenamiento, o tickets de lectura y escritura. El algoritmo de transacciones del motor de almacenamiento concurrente dinámico optimiza el rendimiento de la base de datos durante la sobrecarga del clúster.
Nota
El algoritmo dinámico también resulta en un menor uso general de tickets, incluso en condiciones normales, porque el algoritmo comienza con un número base de tickets disponibles mucho más bajo. Como resultado, al actualizar a MongoDB 7.0, se puede observar una caída significativa en el uso de tickets, lo que es un comportamiento esperado.
El número máximo de transacciones concurrentes en el motor de almacenamiento, o tickets de lectura y escritura, nunca supera 128 tickets de lectura y 128 de escritura, y puede variar entre nodos dentro de un clúster. El número máximo de tickets de lectura y escritura dentro de un solo nodo siempre son iguales.
Para especificar un número máximo de transacciones de lectura y escritura, o de tickets de lectura y escritura, que el máximo dinámico no puede superar, se debe usar storageEngineConcurrentReadTransactions y storageEngineConcurrentWriteTransactions.
Si deseas deshabilitar el algoritmo de transacciones del motor de almacenamiento dinámico concurrente, presenta una solicitud de soporte para trabajar con un Ingeniero de Servicios Técnicos de MongoDB.
Para ver el número de transacciones de lectura concurrentes (tickets de lectura) y de escritura (tickets de escritura) permitidas en el motor de almacenamiento WiredTiger, usa el comando serverStatus y consulta el documento de respuesta queues.execution.
Nota
Un valor bajo de available en queues.execution no indica una sobrecarga del clúster. Usa el número de tickets de lectura y escritura en cola como indicador de la sobrecarga del clúster.
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.
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.
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.
Configuración de caché
El tamaño de caché interno por defecto de WiredTiger es el mayor de los siguientes:
50% de (RAM - 1GB), o
0.256 GB.
Por ejemplo, en un sistema con un total de 4GB de RAM, la caché de WiredTiger usa 1.5GB de RAM (0.5 * (4GB - 1GB) =
1.5 GB). Al proporcionar un tamaño de caché específico, asegúrese de que la RAM no supere los límites de 0.256GB a 10000GB.
Evite aumentar el tamaño de la caché interna de WiredTiger por encima de su valor predeterminado. Si su caso lo requiere, puede usar --wiredTigerCacheSizePct para tener en cuenta los cambios en la memoria debidos a la vertical. Debe especificar un porcentaje de hasta el 80% de la memoria disponible. Los valores calculados pueden variar entre 0.256GB y 10000GB. Por ejemplo, en un sistema con 2GB de RAM, --wiredTigerCacheSizePct no se puede establecer en 10 porque el 10% de 2GB es 0.2 GB, que es menor que 0.256GB.
Nota
En algunos casos, como al ejecutarse en un contenedor configurado para usar menos RAM que la memoria asignada al host, es necesario tener en cuenta los límites. Es posible que deba configurar la caché de WiredTiger con un valor adecuado, ya que WiredTiger podría no tener en cuenta los límites de memoria del contenedor específico en ciertos casos.
Para ver, el valor que WiredTiger utiliza como memory limit hostInfo la cantidad máxima de RAM disponible, utilice el comando.
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 --wiredTigerCacheSizeGB y storage.wiredTiger.engineConfig.cacheSizeGB. Se debe evitar aumentar el tamaño de la caché interna de WiredTiger por encima de su valor por defecto. Si el caso de uso requiere un aumento del tamaño de la caché interna, consulta --wiredTigerCacheSizePct y storage.wiredTiger.engineConfig.cacheSizePct.
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.
Nota
El --wiredTigerCacheSizeGB limita el tamaño de la caché interna de WiredTiger. El sistema operativo utiliza la memoria libre disponible para la caché del sistema de archivos, lo que permite que los archivos de datos comprimidos de MongoDB permanezcan en la memoria. Además, el sistema operativo utiliza cualquier RAM libre para almacenar en búfer los bloques del sistema de archivos y la caché del sistema de archivos.
Para acomodar a los consumidores adicionales de RAM, es posible que debas reducir el tamaño de la caché interna de WiredTiger.
El valor por defecto del tamaño de la caché interna de WiredTiger asume que hay una única instancia de mongod por máquina. Si una sola máquina contiene varias instancias de MongoDB, reduce la configuración para acomodar las otras instancias mongod.
Si ejecuta en un contenedor (por mongod ejemplo,,, lxc cgroupsDocker, etc.) que no tiene acceso a toda la RAM disponible en un sistema, debe establecer --wiredTigerCacheSizeGB o en un valor menor que la cantidad de RAM disponible en el contenedor. La cantidad exacta depende de los demás procesos que se ejecutan en el --wiredTigerCacheSizePct contenedor.memLimitMB Consulte.
Solo puedes proporcionar uno de --wiredTigerCacheSizeGB o --wiredTigerCacheSizePct.