为什么一个空的MongoDB数据库如此之大？

Question

当我使用该命令创建新的mongoDB数据库实例时

mongod --dbpath db

db我在调用命令的目录中创建的文件夹在哪里.运行它并检查目录的大小后,我看到它的大小超过300MB - 当时没有数据.

这里发生了什么？

谢谢你的帮助!

---

编辑

感谢人们谈论预先分配的大小journal.

下面是数据库目录中的文件/文件夹列表,按顺序排序(现在数据库中有一点数据,但这里的大小可以忽略不计):

$du -ha | sort -n
4.0K    ./WiredTiger
4.0K    ./WiredTiger.lock
4.0K    ./WiredTiger.turtle
4.0K    ./WiredTigerLAS.wt
4.0K    ./mongod.lock
4.0K    ./storage.bson
8.0K    ./.DS_Store
8.0K    ./diagnostic.data/metrics.2016-06-10T11-07-50Z-00000
8.0K    ./diagnostic.data/metrics.interim
 16K    ./_mdb_catalog.wt
 16K    ./index-3-3697658674625742251.wt
 36K    ./collection-0-3697658674625742251.wt
 36K    ./index-1-3697658674625742251.wt
 36K    ./sizeStorer.wt
 44K    ./WiredTiger.wt
 60K    ./collection-2-3697658674625742251.wt
 72K    ./diagnostic.data/metrics.2016-06-10T10-19-31Z-00000
100M    ./journal/WiredTigerLog.0000000003
100M    ./journal/WiredTigerPreplog.0000000001
100M    ./journal/WiredTigerPreplog.0000000002
168K    ./diagnostic.data/metrics.2016-06-10T11-17-58Z-00000
256K    ./diagnostic.data
300M    ./journal
301M    .

如您所见,日志目录几乎占据了所有空间.

Answer 1

根据您的MongoDB版本和配置的存储引擎,将在启动时预先分配多个数据和元数据文件.这是预期的行为:"空"部署仍会导致内务和诊断数据.

根据您的目录列表,您运行MongoDB 3.2,默认使用WiredTiger存储引擎.WiredTiger每个日志文件最多分配100MB,因此您的新部署有大约300MB的预分配日志文件:

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

除了日志文件之外,您将创建的其他元数据dbpath(尚未明确创建数据库)将包括:

• 一个local与所谓的封顶收集数据库startup_log有关的这个实例每次启动调用一些诊断信息mongod.将有一个关联的集合和索引文件local.startup_log; 文件名是不透明的但是作为创建的第一个文件,我猜测你的例子可能是:

   36K    ./collection-0-3697658674625742251.wt
   36K    ./index-1-3697658674625742251.wt
  

• 多个WiredTiger元数据文件.由于local默认情况下为以下项创建数据库,因此部署中始终至少有一个数据库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
  

• 一个diagnostic.data目录; 这是针对服务器状态指标的定期采样:

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