我很好奇为什么自从我升级到 Mongo 3.0（Wired Tiger 存储引擎）后，我的 MMS 突然显示出快速的数据增长。过去几周新增长的斜率与升级直接相关。这个数据库中只有几个集合拥有超过 500 个文档……虽然这些都是巨大的集合，但文档结构在升级之前和之后保持不变。此外，在这些集合上运行聚合表明插入的数量在升级之前/之后平均没有变化。这让我质疑新的 WiredTiger 引擎是否以不同的方式计算数据大小或类似的东西。有人有这方面的信息吗？这是我的彩信数据的图像。
有几件事，大小有 2 次跳跃……这是我将集合从另一个数据库迁移到 mongo 的时候。尽管如此，在这两者之后，增长率仍然保持一致，并且在升级后才增加。数据大小在升级时减小（与他们假设 Wired Tiger 具有压缩功能一致）但增长如此之快以至于几乎达到其原始大小。甚至存储大小的增长速度也比原来快得多，尽管这张图片并不公平。
WiredTiger 和 MMapV1 中的数据大小将大致相同，或者至少非常相似。您的文档大小仍然相同（mmapv1 可能会报告一些额外的填充，但wiredtiger 只会报告实际数据大小）。
由于 Wired Tiger 压缩磁盘上的数据，显着不同的是“storageSize”。如果数据大小在增长，那是因为您的实际数据在增长——这可以从“平均对象大小”的增长中看出。
进一步看，我认为这与 PHP Mongo Driver 1.5.0 更新有关，特别是 mongo.native_long 设置在此版本及更高版本中默认为 TRUE。因为 Mongo 3.0 需要高于 1.4 版（我正在运行），所以我不得不同时升级驱动程序。这样做会导致新文档中的所有整数都存储为 LONG 类型，该类型是大小的两倍。我没有理由以这种方式存储我的所有整数，尤其是当许多整数是个位数时。
我已将 native_long 设置更改为 0，并确认默认情况下再次将所有内容存储为 32 位整数。我假设在接下来的几天里，我会看到增长率下降。几天后我会用结果更新这个。
更新：
数据库大小增加的原因仅仅是因为它实际上在增加。我在一周的时间里逐案审查了所有 100 个集合，找到了导致增长的那个，并检查了它，发现有大量行被添加，这与升级无关到 3.0。这个问题纯属巧合，在这篇文章发布 7 个月后，我没有理由相信 3.0 会错误地向 MMS 报告大小。此外，没有理由相信指数增长是由于整数大小为 64 位造成的。