Preguntas frecuentes: Almacenamiento 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 disminuir una vez que el número combinado de colecciones e índices supere 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 conjunto de réplicas autoadministradas a WiredTiger

• Cambiar un clúster fragmentado autoadministrado a WiredTiger

¿Cuánta compresión proporciona WiredTiger?

La proporción de datos comprimidos y sin comprimir depende de los datos y de la biblioteca de compresión utilizada. De forma predeterminada, los datos de colección en WiredTiger utilizan la compresión de bloques Snappy; también está disponible la compresiónzlib y zstd. Los datos de índice utilizan la compresión de prefijo de forma predeterminada.

¿A qué tamaño debo configurar el caché interno de WiredTiger?

Con WiredTiger, MongoDB utiliza tanto la caché interna de WiredTiger como la caché del sistema de archivos.

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 caché interna de WiredTiger asume que hay una sola mongod instancia por máquina. Si una sola máquina contiene varias instancias de MongoDB, debe reducir el valor para acomodar las otras instancias.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 utiliza hasta 1 megabytes de RAM.

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

• Supervise el número de conexiones abiertas a su implementación. Demasiadas conexiones abiertas resultan en un uso excesivo de RAM y reducen la memoria disponible para el conjunto de trabajo.

• Cierre los grupos de conexiones cuando ya no sean necesarios. Un grupo de conexiones es una caché de conexiones de base de datos abiertas y listas para usar, mantenida por el controlador. Cerrar los grupos innecesarios permite disponer de recursos de memoria adicionales.

• 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 maxPoolSize reducir el valor de, se 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 bajo db.collection.stats() el wiredTiger.block-manager.file bytes available for reuse encabezado.

Para que el motor de almacenamiento de WiredTiger libere este espacio vacío al sistema operativo, puede desfragmentar su archivo de datos. Esto se puede lograr resincronizando un miembro del conjunto de réplicas o usando el compact comando.

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

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

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 el tamaño del índice en bytes de la colección. Si un índice utiliza compresión de prefijo (que default for WiredTiger es), 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 para cada índice, utilice el método db.collection.stats() indexSizes y verifique el campo en el documento devuelto.

Si un índice utiliza compresión de prefijo (que default for WiredTiger es), 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".