对MongoDB 3.0 Wired Tiger的升级是否仍能正确地向MMS报告数据大小？

Question

我很好奇为什么自从我升级到Mongo 3.0（有线老虎存储引擎）后，我的MMS突然显示出快速的数据增长。过去几周新增长的斜率与升级直接相关。此数据库中只有几个集合有500多个文档......虽然这些集合都是大集合，但文档结构在升级之后仍然保持不变。此外，在这些集合上运行聚合表示插入的数量在升级之前/之后平均没有变化。这让我质疑数据大小是否与新的WiredTiger引擎或其他相关事物的计算方式不同。有没有人有这方面的任何信息？这是我的彩信数据的图像。

有几件事，大小有2次跳转......这些是我将一个集合从另一个数据库迁移到mongo的时候。在这两者之后，增长率仍保持一致，并且仅在升级后增加。数据大小在升级时降低（与他们假设有线老虎已经压缩一致）但是增长如此之快以至于几乎达到了它的原始大小。即使存储大小开始增长的速度也比原来快得多，尽管这种形象并不公平。

Answer 1

WiredTiger和MMapV1中的数据大小将大致相同，或者至少非常相似。您的文档大小仍然相同（mmapv1可能会报告一些额外的填充，但有线网格只会报告实际的数据大小）。

由于有线Tiger对磁盘上的数据进行压缩会有什么显着不同，这就是＆＃34; storageSize＆＃34;。如果数据量正在增长，那是因为您的实际数据正在增长 - 这可以在＆＃34;平均对象大小＆＃34;也在增加。

Answer 2

进一步看，我认为这与PHP Mongo Driver 1.5.0更新有关，特别是mongo.native_long设置在此版本中默认为TRUE以及更高版本。因为Mongo 3.0需要大于1.4版（我正在运行），所以我必须同时升级驱动程序。这样做会导致新文档中的所有整数都存储为LONG类型，这是两倍大小。我没有理由以这种方式存储我的所有内容，特别是当许多是单个数字时。

我已将native_long设置更改为0并确认默认情况下再次将所有内容存储为32位整数。我假设在接下来的几天里我会看到增长率下降。我会在几天后对结果进行更新。

更新

db的大小增加的原因仅仅是因为它实际上正在增加。我在一周的时间内逐个审核了所有100个集合，找到了导致增长的集合并检查了它，发现有大量行被添加，这与升级无关到3.0。这个问题仅仅是巧合，自本篇帖子发布7个月后，我没有理由相信3.0报告的大小不正确。此外，没有理由相信指数增长是由整数的大小导致的64位。