Actualización (marzo de 2015): A partir de la versión 3.0, hay varios motores de almacenamiento disponibles en MongoDB. Esta respuesta se aplica al motor de almacenamiento MMAP (todavía el predeterminado en MongoDB 3.0), la respuesta para otros motores (por ejemplo, WiredTiger) es bastante diferente y bien puede ajustarse. Por lo tanto, si está utilizando otro motor, lea los documentos relevantes para ese motor de almacenamiento para determinar cuáles son sus opciones y valores predeterminados de reutilización de espacio.
Con el motor de almacenamiento MMAP, cuando se eliminan los documentos, el espacio que queda se coloca en una lista libre. Sin embargo, para usar el espacio, será necesario que se inserten documentos de tamaño similar más adelante, y MongoDB deberá encontrar un espacio apropiado para ese documento dentro de un cierto período de tiempo (una vez que se agote el tiempo de mirar la lista, simplemente se agregará) de lo contrario la reutilización del espacio no va a ocurrir muy a menudo. Esta eliminación se realiza dentro de los archivos de datos, por lo que aquí no se recupera espacio en disco; todo esto se realiza internamente dentro de los archivos de datos existentes.
Si posteriormente realiza una reparación o resincroniza una secundaria desde cero, los archivos de datos se reescriben y se recupera el espacio en el disco (también se elimina cualquier relleno en los documentos). Aquí es donde verá la recuperación de espacio real en el disco. Para cualquier otra acción (compacto incluido), el uso del disco no cambiará e incluso puede aumentar.
Con 2.2+ ahora puede usar el comando collMod y la opción usePowersOf2Sizes para hacer más probable la reutilización del espacio eliminado (tenga en cuenta que este es el valor predeterminado en 2.6+). Esto significa que la asignación de espacio inicial para un documento es un poco menos eficiente (512 bytes para un documento de 400 bytes, por ejemplo), pero significa que cuando se inserta un documento nuevo, es más probable que pueda reutilizar ese espacio. Si está eliminando (o aumentando y, por lo tanto, moviendo) muchos documentos, esto será más eficiente a largo plazo.
Para cualquiera que esté interesado, una de las personas que escribió gran parte del código de almacenamiento (Mathias Stearn) tiene una gran presentación sobre las partes internas del almacenamiento, que se puede encontrar aquí
