El motor de almacenamiento en memoria forma parte de la disponibilidad general (GA) en compilaciones de 64bits. A excepción de algunos metadatos y datos de diagnóstico, el motor de almacenamiento en memoria no mantiene datos en disco, incluidos datos de configuración, índices, credenciales de usuarios, etc.
Al evitar la E/S de disco, el motor de almacenamiento en memoria permite una latencia más predecible en las operaciones de la base de datos.
Especifique el motor de almacenamiento en memoria
Para seleccionar el motor de almacenamiento en memoria, especifique:
inMemorypor la la opción--storageEngine, o lastorage.engineconfiguración si utiliza un archivo de configuración.--dbpathostorage.dbPathsi se utiliza un archivo de configuración. Aunque el motor de almacenamiento en memoria no graba datos en el sistema de archivos, mantiene en el--dbpathpequeños archivos de metadatos y datos de diagnóstico, así como archivos temporales para la creación de grandes índices.
Por ejemplo, desde la línea de comandos:
mongod --storageEngine inMemory --dbpath <path>
O bien, si utiliza el formato de archivo de configuración YAML:
storage: engine: inMemory dbPath: <path>
Consultá Opciones inMemory para opciones de configuración específicas de este motor de almacenamiento. La mayoría de las mongod opciones de configuración están disponibles para usarse con el motor de almacenamiento en memoria, excepto aquellas opciones que están relacionadas con la persistencia de datos, como la configuración de registrar en la bitácora o cifrado en reposo.
Advertencia
El motor de almacenamiento en memoria no conserva los datos después de que se apaga el proceso.
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.
Concurrencia a nivel de documento
El motor de almacenamiento en memoria utiliza control de concurrencia a nivel de documento para las operaciones de escritura. Como resultado, varios clientes pueden modificar diferentes documentos de una colección al mismo tiempo.
Uso de memoria
El motor de almacenamiento en memoria requiere que todos sus datos (incluidos los índices, el oplog si la instancia de mongod es parte de un set de réplicas, etc.) quepan en la opción de línea de comandos --inMemorySizeGB especificada o en la configuración storage.inMemory.engineConfig.inMemorySizeGB del archivo de configuración YAML.
Por defecto, el motor de almacenamiento en memoria utiliza el 50% de la RAM física menos 1 GB.
Si una operación de guardar hiciera que los datos superaran el tamaño de memoria especificado, MongoDB devolverá el siguiente error:
"WT_CACHE_FULL: operation would overflow cache"
Para especificar un nuevo tamaño, utiliza la configuración storage.inMemory.engineConfig.inMemorySizeGB en el formato de archivo de configuración YAML:
storage: engine: inMemory dbPath: <path> inMemory: engineConfig: inMemorySizeGB: <newSize>
O utiliza la opción de línea de comandos --inMemorySizeGB:
mongod --storageEngine inMemory --dbpath <path> --inMemorySizeGB <newSize>
Durabilidad
El motor de almacenamiento en memoria no es persistente y no escribe datos en un almacenamiento persistente. Los datos no persistentes incluyen datos de aplicaciones y datos del sistema, como usuarios, permisos, índices, configuración del set de réplicas, configuración de clúster fragmentado, etc.
Por lo tanto, el concepto de journal o esperar a que los datos se vuelvan duraderos no se aplica al motor de almacenamiento en memoria.
Si algún nodo con derecho a voto de un set de réplicas utiliza el motor de almacenamiento en memoria, debes configurar writeConcernMajorityJournalDefault en false.
Nota
A partir de la versión 4.2 (y 4.0.13 y 3.6.14 ), si un miembro del conjunto de réplicas utiliza el motor de almacenamiento en memoria (con o sin voto), pero el conjunto de réplicas tiene writeConcernMajorityJournalDefault configurado en verdadero, el miembro del conjunto de réplicas registra una advertencia de inicio.
Con writeConcernMajorityJournalDefault configurado en false, MongoDB no espera a que las escrituras w: "majority" se registren en la bitácora en disco antes de confirmar las escrituras. Por lo tanto, "majority" las operaciones de escritura podrían revertirse en caso de una pérdida transitoria (p. ej., caída y reinicio) de la mayoría de los nodos en un set de réplicas determinado.
Las operaciones de escritura que especifican un journaled nivel de confirmación de escritura (write concern) se reconocen de inmediato. Cuando una instancia mongod se apaga, ya sea como resultado del comando shutdown o debido a un error del sistema, la recuperación de los datos en memoria es imposible.
Transacciones
Las transacciones son compatibles en conjuntos de réplicas y clústeres fragmentados en los que:
el primario utiliza el motor de almacenamiento WiredTiger y
los miembros secundarios utilizan el motor de almacenamiento WiredTiger o los motores de almacenamiento in-memory.
Nota
No puedes ejecutar transacciones en un clúster particionado que tiene una partición con writeConcernMajorityJournalDefault configurada en false, como una partición con un nodo con derecho a voto que utiliza el motor de almacenamiento en memoria.
Arquitecturas de implementación
Además de ejecutarse como autónomos, las mongod instancias que utilizan el motor de almacenamiento en memoria pueden ejecutarse como parte de un set de réplicas o de un clúster.
Set de réplicas
Se pueden implementar mongod instancias que utilizan el motor de almacenamiento en memoria como parte de un set de réplicas. Por ejemplo, como parte de un set de réplicas de tres nodos, podrías tener:
dos instancias de
mongodse ejecutan con el motor de almacenamiento en memoria.una
mongodinstancia ejecutándose con el motor de almacenamiento WiredTiger. Configure el miembro WiredTiger como un miembro oculto (es decir,hidden: trueypriority: 0).
Con este modelo de implementación, solo las instancias mongod que se ejecutan con el motor de almacenamiento en memoria pueden convertirse en primarias. Los clientes se conectan solo a las instancias del motor de almacenamiento en memoria mongod . Incluso si ambas instancias de mongod, que ejecutan un motor de almacenamiento en memoria, fallan y reinician, pueden sincronizarse desde el nodo que ejecuta WiredTiger. La instancia oculta mongod que se ejecuta con WiredTiger guarda los datos en el disco, incluyendo los datos de usuario, índices, e información de configuración de replicación.
Nota
El motor de almacenamiento en memoria requiere que todos sus datos (incluyendo el oplog si mongod forma parte del set de réplicas, etc.) quepan en la opción de línea de comandos --inMemorySizeGB especificada o en la configuración storage.inMemory.engineConfig.inMemorySizeGB. Consulta Uso de memoria.
Clúster fragmentado
Puedes implementar instancias de mongod que utilizan un motor de almacenamiento en memoria como parte de un clúster. El motor de almacenamiento en memoria evita la E/S de disco para permitir una latencia de operación de base de datos más predecible. En un clúster fragmentado, una partición puede estar compuesto por una sola instancia de mongod o un conjunto de réplicas. Por ejemplo, podrías tener una partición que consista en el siguiente set de réplicas:
dos instancias de
mongodse ejecutan con el motor de almacenamiento en memoriauna
mongodinstancia ejecutándose con el motor de almacenamiento WiredTiger. Configure el miembro WiredTiger como un miembro oculto (es decir,hidden: trueypriority: 0).
A esta partición, añada el tag inmem. Por ejemplo, si esta partición tiene el nombre shardC, conéctate a mongos y ejecuta sh.addShardTag().
Por ejemplo,
sh.addShardTag("shardC", "inmem")
En las otras particiones, añade una etiqueta persisted por separado.
sh.addShardTag("shardA", "persisted") sh.addShardTag("shardB", "persisted")
Para cada colección particionada que debe residir en la partición inmem, assign to the entire chunk range la etiqueta inmem:
sh.addTagRange("test.analytics", { shardKey: MinKey }, { shardKey: MaxKey }, "inmem")
Para cada colección particionada que deba residir entre las persisted particiones, assign to the entire chunk range la etiqueta persisted:
sh.addTagRange("salesdb.orders", { shardKey: MinKey }, { shardKey: MaxKey }, "persisted")
Para la partición inmem, crea una base de datos o mueve la base de datos.
Nota
El nivel de consistencia de lectura "snapshot" no es oficialmente compatible con el motor de almacenamiento en memoria.