Motor de almacenamiento en memoria para implementaciones autogestionadas

Especificar el motor de almacenamiento en memoria

Para seleccionar el motor de almacenamiento en memoria, especifique:

• inMemory por la la opción --storageEngine, o la storage.engine configuración si utiliza un archivo de configuración.

• --dbpatho storage.dbPath si 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 --dbpath pequeñ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>

Consulte las opciones de inMemory para conocer las 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 su uso con el motor de almacenamiento en memoria, excepto las relacionadas con la persistencia de datos, como el registro en diario o la configuración del cifrado en reposo.

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.

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,mongod el registro de operaciones si la instancia es parte de un conjunto de réplicas, etc.) se ajusten a la --inMemorySizeGB opción de línea de comandos especificada storage.inMemory.engineConfig.inMemorySizeGBo a la configuración en el 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, utilice la configuración en el storage.inMemory.engineConfig.inMemorySizeGB formatodel 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 del sistema, como usuarios, permisos, índices, configuración del conjunto de réplicas, configuración del 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 cualquier miembro votante de un conjunto de réplicas utiliza el motor de almacenamiento en memoria, debes configurar writeConcernMajorityJournalDefault en false.

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 principal utiliza el motor de almacenamiento WiredTiger y

• los miembros secundarios utilizan el motor de almacenamiento WiredTiger o los motores de almacenamiento in-memory.

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.

sh.addShardTag("shardC", "inmem")

sh.addShardTag("shardA", "persisted")
sh.addShardTag("shardB", "persisted")

sh.addTagRange("test.analytics", { shardKey: MinKey }, { shardKey: MaxKey }, "inmem")

sh.addTagRange("salesdb.orders", { shardKey: MinKey }, { shardKey: MaxKey }, "persisted")