Pourquoi une base de données MongoDB vide est-elle si grosse ?

En fonction de votre version de MongoDB et du moteur de stockage configuré, plusieurs fichiers de données et de métadonnées seront préalloués au démarrage. C'est le comportement attendu :un déploiement "vide" génère toujours des données de maintenance et de diagnostic.

Sur la base de votre liste de répertoires, vous exécutez MongoDB 3.2 qui utilise par défaut le moteur de stockage WiredTiger. WiredTiger alloue jusqu'à 100 Mo par fichier journal, de sorte que votre nouveau déploiement dispose d'environ 300 Mo de fichiers journaux préalloués :

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

Outre les fichiers journaux, d'autres métadonnées seront créées dans votre dbpath (sans que vous ayez encore créé explicitement des bases de données) inclura :

Un local base de données avec une collection limitée appelée startup_log avec des informations de diagnostic sur chaque invocation de démarrage de cette instance de mongod . Il y aura une collection associée et un fichier d'index pour local.startup_log; les noms de fichiers sont opaques mais comme les premiers fichiers créés, je suppose que dans votre exemple, ceux-ci pourraient être :
```
 36K    ./collection-0-3697658674625742251.wt
 36K    ./index-1-3697658674625742251.wt
```
Plusieurs fichiers de métadonnées WiredTiger. Il y aura toujours au moins une base de données dans un déploiement depuis le local la base de données est créée par défaut pour le 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 annuaire; il s'agit d'un échantillonnage périodique des métriques d'état du serveur :

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