Question

我们是一个集合，其中每个文档的平均大小为16 KB，文档计数为30,000，这意味着总空间应为

(30,000 * 16) / 1024 * 2024 = 1.71 GB

但是我们发现收集统计信息中的集合大小为28.6 GB，非常糟糕。任何人都可以告诉我这怎么可能，当我们在这个文档中只有736个文件的时候，我已经检查过ea liar，那时它只消耗18.5 MB。我这个集合只存储数字数据而不是任何文本或大字符串。

Mongo db是否有额外的空间用于收集或其他什么？

这是统计信息。

> db.MyCollection.stats()
{
        "ns" : "DB.MyCollection",
        "count" : 31228,
        "size" : 30593236376,
        "avgObjSize" : 979673.254002818,
        "storageSize" : 31878659904,
        "numExtents" : 33,
        "nindexes" : 1,
        "lastExtentSize" : 2146426864,
        "paddingFactor" : 1,
        "systemFlags" : 1,
        "userFlags" : 0,
        "totalIndexSize" : 923888,
        "indexSizes" : {
                "_id_" : 923888
        },
        "ok" : 1
}

修改

这是我之前捕获的统计数据（当记录数为736时）

> db.MyCollection.stats()
{
        "ns" : "DB.MyCollection",
        "count" : 736,
        "size" : 18985944,
        "avgObjSize" : 25796.119565217392,
        "storageSize" : 23035904,
        "numExtents" : 4,
        "nindexes" : 1,
        "lastExtentSize" : 11681792,
        "paddingFactor" : 1,
        "systemFlags" : 1,
        "userFlags" : 0,
        "totalIndexSize" : 32704,
        "indexSizes" : {
                "_id_" : 32704
        },
        "ok" : 1
}

我使用Insertion只是不更新，但经常查询。

某些信息可能有助于确定情况：

集合的模式是深树结构（7级）
将Windows服务器用于mongodb（但在MongoLab（亚马逊托管）实例上也遇到同样的问题）
将集合移动到另一个数据库（在另一台服务器上），也只使用插入语句，但BulkInsertion也使用相同的大小。

示例数据：我已重命名字段名称

{
   "_id":ObjectId("50ff7614c9145359648cc017"),
   "gtrtt":2,
   "XYZ":2,
   "Namecount":2,
   "ABC":0,
   "123":0,
   "IDD":793,
   "date":   ISODate("2012-04-22T00:00:00   Z"),
   "network":[
      {
         "gtrtt":2,
         "XYZ":2,
         "Namecount":2,
         "ABC":0,
         "123":0,
         "type":"facebook",
         "safasfasf":[
            {
               "gtrtt":2,
               "XYZ":2,
               "Namecount":2,
               "ABC":0,
               "123":0,
               "type":0,
               "sassasas":[
                  {
                     "gtrtt":2,
                     "XYZ":2,
                     "Namecount":2,
                     "ABC":0,
                     "123":0,
                     "type":2,
                     "asfasffasfsafas":[
                        {
                           "gtrtt":2,
                           "XYZ":2,
                           "Namecount":2,
                           "ABC":0,
                           "123":0,
                           "type":5,
                           "435435345":[
                              {
                                 "gtrtt":2,
                                 "XYZ":2,
                                 "Namecount":2,
                                 "ABC":0,
                                 "123":0,
                                 "type":"Egypt",
                                 "34534534435345":[
                                    {
                                       "gtrtt":1,
                                       "XYZ":1,
                                       "Namecount":1,
                                       "ABC":0,
                                       "123":0,
                                       "type":"Cairo"
                                    },
                                    {
                                       "gtrtt":1,
                                       "XYZ":1,
                                       "Namecount":1,
                                       "ABC":0,
                                       "123":0,
                                       "type":null
                                    }
                                 ]
                              }
                           ]
                        }
                     ]
                  }
               ]
            }
         ]
      }
   ],
   "OS":[
      {
         "gtrtt":1,
         "XYZ":1,
         "Namecount":1,
         "ABC":0,
         "123":0,
         "type":"Windows7"
      },
      {
         "gtrtt":1,
         "XYZ":1,
         "Namecount":1,
         "ABC":0,
         "123":0,
         "type":"WindowsXP"
      }
   ],
   "Browser":[
      {
         "gtrtt":1,
         "XYZ":1,
         "Namecount":1,
         "ABC":0,
         "123":0,
         "type":"IE"
      },
      {
         "gtrtt":1,
         "XYZ":1,
         "Namecount":1,
         "ABC":0,
         "123":0,
         "type":"Firefox"
      }
   ],
   "Device":[
      {
         "gtrtt":2,
         "XYZ":2,
         "Namecount":2,
         "ABC":0,
         "123":0,
         "type":"PC"
      }
   ]
}

Answer 1

我会在这里做一些假设，形成一个有根据的猜测，我会说它们是真的。

您显示的所有测量均以字节为单位。

您的平均对象大小（文档）实际上是0.9兆不是16KB。

所以你实际上正在使用：28.4922 GB左右（你在该集合中有31228个对象）。这就是MongoDB无论如何都说的。

您实际上正在使用29.6893 GB的存储空间。

这实际上是有道理的，因为预先分配了未来的扩展区（我认为在这种情况下它会预先分配一个新的2GB文件）和可能的碎片，但是你的碎片不是很高，可能是几个MB所以我不会说这是你的问题，但你可以在该集合上运行一个压缩，无论如何它都会导致问题。

我还会说你的填充因子可能大约是1，或者考虑到碎片的数量，所以这不是太大的问题，它将分配比这里的对象大小更大

索引是一个单独的命名空间，因此它们不应该过多地影响您的集合命名空间范围（如果有的话）。

我认为您的主要问题是您误读并误解了数据集的输出和真实大小。

修改

如果您经常更新（不插入）此集合，可以解释avgObjSize和您的假设，在这种情况下，契约应该将集合恢复到可控制的大小。

Answer 2

您需要考虑索引也会增加集合大小。另外mongodb有一些paddingfactor应用于文档。这允许文档的大小可以增加，而不需要总是移动文档，即使它只是一个字节。填充因子非常不稳定并且变化很大。因此，使用paddingfactor，您的收藏也会增加。见stats()

从你的输出：

索引似乎没问题，只是你的_id索引。填充因子似乎也没有问题，但这没有任何说明，因为这只是应用于新写入的实际填充因子。但看起来有问题的是mongodb报告你的avgObjSize大约956kB而不是你怀疑的16kB。因此，您要么查看错误的集合，要么保存与您预期保存的不同的内容（不确定您的16kB来自哪里）。

你可以做的是运行compact到compact集合，然后检查由于填充因子而分配的空间。

Mongodb光盘空间

2 个答案:

修改