Preguntas frecuentes: Almacenamiento de MongoDB para implementaciones autogestionadas

¿Qué es un motor de almacenamiento?

Un motor de almacenamiento es la parte de una base de datos responsable de gestionar el almacenamiento de los datos, tanto en memoria como en disco. Muchas bases de datos admiten varios motores de almacenamiento, y cada uno ofrece un mejor rendimiento para cargas de trabajo específicas. Por ejemplo, un motor de almacenamiento podría ofrecer un mejor rendimiento para cargas de trabajo con mucha lectura, mientras que otro podría ofrecer un mayor rendimiento para operaciones de escritura.

¿Cuántas colecciones e índices puede haber en un clúster?

El rendimiento del clúster podría degradarse una vez que el número combinado de colecciones e índices supere los 100,000. Además, muchas colecciones grandes tienen un mayor impacto en el rendimiento que las colecciones más pequeñas.

¿Puedo actualizar una implementación existente a WiredTiger?

Sí. Ver:

• Cambia un sistema autónomo autogestionado a WiredTiger

• Cambiar un set de réplicas autogestionado a WiredTiger

• Cambiar un clúster fragmentado autoadministrado a WiredTiger

¿Cuánta compresión proporciona WiredTiger?

La relación de datos comprimidos a datos no comprimidos depende de tus datos y de la librería de compresión utilizada. Por defecto, los datos de la colección en WiredTiger utilizan compresión de bloques Snappy; también están disponibles las compresiones zlib y zstd. El uso de índices de datos utiliza la reducción de prefijo por defecto.

¿A qué tamaño debo ajustar la caché interna de WiredTiger?

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é 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).

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.

El valor predeterminado del tamaño de la memoria caché interna de WiredTiger asume que hay una única instancia de mongod por máquina. Si una sola máquina contiene múltiples instancias de MongoDB, entonces debes disminuir la configuración para alojar las otras instancias de mongod.

Si se ejecuta mongod en un contenedor (por ejemplo, lxc, cgroups, Docker, etc.) que no tiene acceso a toda la RAM disponible en un sistema, se debe establecer storage.wiredTiger.engineConfig.cacheSizeGB en un valor inferior a la cantidad de RAM disponible en el contenedor. La cantidad exacta depende de los otros procesos que se ejecutan en el contenedor. Ver memLimitMB.

Para ver las estadísticas sobre la caché y la tasa de desalojos, consultar el campo wiredTiger.cache devuelto por el comando serverStatus.

¿Cuánta memoria asigna MongoDB por conexión?

Cada conexión usa hasta 1 megabyte de RAM.

Para optimizar el uso de memoria para las conexiones, asegúrate de:

• Supervise the number of open connections to your implementación. Demasiadas conexiones abiertas provocan un uso excesivo de la RAM y reducen la memoria disponible para el conjunto de trabajo.

• Cierra pool de conexiones cuando ya no sean necesarios. Un pool de conexiones es una caché de conexiones de base de datos abiertas y listas para usar, mantenida por el controlador. Cerrar los grupos innecesarios hace que haya recursos de memoria adicionales disponibles.

• Administre el tamaño de su grupo de conexiones. La maxPoolSize opción de cadena de conexión especifica el número máximo de conexiones abiertas en el grupo. De forma predeterminada, puede tener hasta 100 conexiones abiertas en el grupo. Al reducir el valor de, se maxPoolSize reduce la cantidad máxima de RAM utilizada para las conexiones.

  Tip

  Para configurar tu pool de conexiones, consulta Ajustes de configuración del pool de conexiones.

¿Con qué frecuencia WiredTiger escribe en el disco?

Puntos de control

MongoDB configura WiredTiger para crear puntos de control, específicamente, escribiendo los datos del snapshot en el disco a intervalos de 60 segundos.

Journal Data

WiredTiger sincroniza los registros de bitácora almacenados en búfer con el disco bajo cualquiera de las siguientes condiciones:

• Para los miembros del set de réplicas (miembros primarios y secundarios):

  • Si una operación de guardar incluye o implica un nivel de confirmación de escritura (write concern) de j: true.

  • Adicionalmente para los miembros secundarios, después de cada aplicación en lotes de las entradas del oplog.

  Nota

  El nivel de confirmación de escritura (write concern) "majority" implica j: true si el writeConcernMajorityJournalDefault es verdadero.

• Cada 100 milisegundos (ver storage.journal.commitIntervalMs).

• Cuando WiredTiger crea un nuevo archivo de diario. Puesto que MongoDB utiliza un límite de tamaño de archivo de diario de 100 MB, WiredTiger crea un nuevo archivo de diario aproximadamente cada 100 MB de datos.

¿Cómo recupero espacio en disco en WiredTiger?

El motor de almacenamiento de WiredTiger mantiene listas de registros vacíos en los archivos de datos a medida que elimina documentos. WiredTiger puede reutilizar este espacio, pero no se devolverá al sistema operativo a menos que se den circunstancias muy específicas.

La cantidad de espacio vacío disponible para reutilización por WiredTiger se refleja en la salida de db.collection.stats() bajo el encabezado wiredTiger.block-manager.file bytes available for reuse.

Para permitir que el motor de almacenamiento WiredTiger libere este espacio vacío al sistema operativo, puedes desfragmentar tu archivo de datos. Esto puede lograrse resincronizando un miembro del set de réplicas o usando el comando compact.

¿Cómo puede comprobar el tamaño de una colección?

Para ver las estadísticas de una colección, incluido el tamaño de los datos, utiliza el método db.collection.stats() desde mongosh. El siguiente ejemplo emite db.collection.stats() para la colección orders:

db.orders.stats();

MongoDB también proporciona los siguientes métodos para devolver tamaños específicos para la colección:

• db.collection.dataSize() para devolver el tamaño de los datos sin comprimir en bytes para la colección.

• db.collection.storageSize() devuelve el tamaño en bytes de la colección en el almacenamiento en disco. Si los datos de la colección están comprimidos (que es el caso default for WiredTiger de), el tamaño de almacenamiento refleja el tamaño comprimido y puede ser menor que el valor devuelto db.collection.dataSize() por.

• db.collection.totalIndexSize() para devolver los tamaños de índice en bytes para la colección. Si un índice utiliza reducción de prefijo (que es el default for WiredTiger), el tamaño devuelto refleja el tamaño comprimido.

El siguiente script imprime las estadísticas de cada base de datos:

db.adminCommand("listDatabases").databases.forEach(function (d) {
   mdb = db.getSiblingDB(d.name);
   printjson(mdb.stats());
})

El siguiente script imprime las estadísticas de cada colección en cada base de datos:

db.adminCommand("listDatabases").databases.forEach(function (d) {
   mdb = db.getSiblingDB(d.name);
   mdb.getCollectionNames().forEach(function(c) {
      s = mdb[c].stats();
      printjson(s);
   })
})

¿Cómo puedo comprobar el tamaño de los índices individuales de una colección?

Para ver el tamaño de los datos asignados a cada índice, usa el db.collection.stats() método y revisa el campo indexSizes en el documento devuelto.

Si un índice utiliza reducción de prefijo (que es el default for WiredTiger), el tamaño devuelto para ese índice refleja el tamaño comprimido.

¿Cómo puedo obtener información sobre el uso de almacenamiento de una base de datos?

El db.stats() método en devuelve el estado actual de la base de datos activa. Para obtener la descripción de los campos devueltos, consulte la sección "Salida mongosh de dbStats".