¿Por qué es tan grande una base de datos MongoDB vacía?

Según su versión de MongoDB y el motor de almacenamiento configurado, varios archivos de datos y metadatos se preasignarán al inicio. Este es el comportamiento esperado:una implementación "vacía" aún genera datos de limpieza y diagnóstico.

Según su lista de directorios, está ejecutando MongoDB 3.2, que por defecto usa el motor de almacenamiento WiredTiger. WiredTiger asigna hasta 100 MB por archivo de diario, por lo que su nueva implementación tiene ~300 MB de archivos de diario preasignados :

     100M    ./journal/WiredTigerLog.0000000003
     100M    ./journal/WiredTigerPreplog.0000000001
     100M    ./journal/WiredTigerPreplog.0000000002

Aparte de los archivos de diario, otros metadatos que se crearán en su dbpath (sin que haya creado bases de datos explícitamente todavía) incluirá:

Un local base de datos con una colección limitada llamada startup_log con información de diagnóstico sobre cada invocación de inicio de esta instancia de mongod . Habrá una colección asociada y un archivo de índice para local.startup_log; los nombres de los archivos son opacos, pero como los primeros archivos creados, supongo que en su ejemplo estos podrían ser:
```
 36K    ./collection-0-3697658674625742251.wt
 36K    ./index-1-3697658674625742251.wt
```
Múltiples archivos de metadatos de WiredTiger. Siempre habrá al menos una base de datos en una implementación desde el local la base de datos se crea de forma predeterminada para el startup_log :
```
4.0K    ./WiredTiger
4.0K    ./WiredTiger.lock
4.0K    ./WiredTiger.turtle
4.0K    ./WiredTigerLAS.wt
 16K    ./_mdb_catalog.wt
 36K    ./sizeStorer.wt
 44K    ./WiredTiger.wt
```

Un diagnostic.data directorio; esto es para el muestreo periódico de las métricas de estado del servidor:

168K    ./diagnostic.data/metrics.2016-06-10T11-17-58Z-00000
72K    ./diagnostic.data/metrics.2016-06-10T10-19-31Z-00000