El almacenamiento en disco es un recurso crítico para cualquier sistema de base de datos escalable. El rendimiento de sus bases de datos basadas en disco dependerá de cómo se gestionen los datos en el disco. Su servidor MongoDB admite varios motores de almacenamiento conectables que manejan la administración del almacenamiento e inicialmente almacenan todos los documentos secuencialmente. A medida que la base de datos crece y se ejecutan varias operaciones de escritura, este espacio contiguo se fragmenta en bloques más pequeños con trozos de espacio libre en el medio. La solución típica es aumentar el tamaño del disco, sin embargo, existen alternativas que pueden ayudarlo a recuperar el espacio libre sin tener que escalar el tamaño de su disco. Una cosa importante a tener en cuenta son las estadísticas de almacenamiento de MongoDB y cómo puede compactar o reparar la base de datos para manejar la fragmentación.
¿Qué tamaño tiene realmente su base de datos?
Siempre debe vigilar la cantidad de espacio libre en disco en su servidor de producción, y también debe ser prudente para conocer el tamaño de su base de datos cuando paga por ella en una plataforma en la nube. MongoDB tiene un comando db.stats() que puede proporcionar información sobre las estadísticas de almacenamiento de una instancia de MongoDB.
>db.stats()
{
"db" : "test",
"collections" : 5,
"views" : 0,
"objects" : 53829,
"avgObjSize" : 43.555,
"dataSize" : 2344556121,
"storageSize" :3124416336,
"numExtents" : 0,
"indexes" : 7,
"indexSize" : 8096876,
"ok" : 1
}
tamaño de datos
El tamaño total en bytes de los datos sin comprimir contenida en esta base de datos.
tamaño de almacenamiento
La cantidad total de espacio en disco asignado a todas las colecciones en la base de datos.
La respuesta de db.stats() depende del tipo de motor MongoDB. Puede encontrar su descripción dependiente de la versión de las métricas anteriores en la documentación de MongoDB.
Por qué la gran diferencia entre storageSize y tamaño de datos ? Esto se debe a la fragmentación de los archivos de datos explicada anteriormente. MongoDB intenta reutilizar el espacio libre entre los datos fragmentados siempre que sea posible y no lo libera al sistema operativo. Sin embargo, en WiredTiger, el tamaño de almacenamiento puede ser más pequeño que el tamaño de datos si la compresión está habilitada.
En el caso de que se elimine una gran cantidad de datos de una colección y la colección nunca use el espacio eliminado para nuevos documentos, este espacio debe devolverse al sistema operativo para que pueda ser utilizado por sus otras bases de datos o colecciones. Deberá ejecutar un compacto o reparar operación para desfragmentar el espacio en disco y recuperar el espacio libre utilizable.
Compactación de MongoDB
La operación compacta de MongoDB reescribe todos los documentos e índices de una colección en bloques contiguos de espacio en disco. Sin embargo, esta operación bloquea todas las demás operaciones en la base de datos a la que pertenece la colección. Por lo tanto, para un servidor independiente, se recomienda ejecutarlo durante una ventana de mantenimiento, y para conjuntos de réplicas, debe ejecutarlo de manera continua para cada fragmento. Esto significa compactar todos los secundarios primero y finalmente el principal para que la disponibilidad de la base de datos no se vea afectada. La sintaxis del comando es:
db.runCommand({compact: collection-name }) 1. MMAPv1
- La operación de compactación desfragmenta los archivos de datos y los índices. Sin embargo, tenga en cuenta que no libera espacio para el sistema operativo. La operación sigue siendo útil para desfragmentar y crear más espacio contiguo para que MongoDB lo reutilice, pero no sirve de nada cuando el espacio libre en disco es muy bajo.
- Se requiere un espacio en disco adicional de hasta 2 GB durante la operación de compactación.
- Se mantiene un bloqueo a nivel de la base de datos durante la operación de compactación.
2. Tigre cableado
El motor WiredTiger proporciona compresión de forma predeterminada, lo que consume menos espacio en disco que MMAPv1.
- El proceso compacto libera el espacio libre para el sistema operativo.
- Se requiere un espacio mínimo en disco para ejecutar la operación compacta.
- WiredTiger también bloquea todas las operaciones en la base de datos, ya que necesita un bloqueo de nivel de base de datos.
Si está ejecutando WiredTiger, le recomendamos que ejecute la operación compacta cuando el almacenamiento haya alcanzado el 80 % del tamaño del disco. Puede hacerlo activando la operación 'Compacta' desde nuestra página de detalles.
Reparar MongoDB
MongoDB reparación La operación repara todos los errores e inconsistencias en el almacenamiento de datos, similar al comando fcsk para un sistema de archivos. Este comando garantiza la integridad de los datos después de un apagado o bloqueo inesperado. Sin embargo, si el diario está habilitado en el servidor, entonces no hay necesidad de reparación ya que el servidor usa el diario para entrar en estado limpio automáticamente después de reiniciar. Si su base de datos se ha dañado, entonces una reparación de base de datos no guardaría los datos dañados, por lo que no se recomienda utilizar esta operación para recuperación de datos cuando tienes otras opciones.
Para MMAPv1, reparar base de datos es la única forma de recuperar espacio en disco si cree que su base de datos no se ha dañado y tiene suficiente espacio requerido por la operación de reparación. La sintaxis del comando es:
db.runCommand({repairDatabase: 1}) - Este comando compacta todas las colecciones en la base de datos y recrea todos los índices.
- El trabajo requiere espacio libre en disco igual al tamaño de su conjunto de datos actual más 2 gigabytes.
En ScaleGrid, usamos la repairDatabase operación para recuperar espacio libre para MMAPv1 grupos de motores.
