Por que um banco de dados MongoDB vazio é tão grande?

Dependendo da sua versão do MongoDB e do mecanismo de armazenamento configurado, vários arquivos de dados e metadados serão pré-alocados na inicialização. Este é o comportamento esperado:uma implantação "vazia" ainda resulta em dados de limpeza e diagnóstico.

Com base em sua lista de diretórios, você está executando o MongoDB 3.2, que usa como padrão o mecanismo de armazenamento WiredTiger. O WiredTiger aloca até 100 MB por arquivo de diário, portanto, sua nova implantação tem aproximadamente 300 MB de arquivos de diário :

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

Além dos arquivos de diário, outros metadados que serão criados em seu dbpath (sem que você tenha explicitamente criado bancos de dados ainda) incluirá:

Um local banco de dados com uma coleção limitada chamada startup_log com algumas informações de diagnóstico sobre cada invocação de inicialização desta instância de mongod . Haverá uma coleção associada e um arquivo de índice para local.startup_log; os nomes dos arquivos são opacos, mas como os primeiros arquivos criados, acho que no seu exemplo podem ser:
```
 36K    ./collection-0-3697658674625742251.wt
 36K    ./index-1-3697658674625742251.wt
```

Vários arquivos de metadados do WiredTiger. Sempre haverá pelo menos um banco de dados em uma implantação desde o local banco de dados é criado por padrão para o 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

Um diagnostic.data diretório; isso é para amostragem periódica de métricas de status do servidor:

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