Mongodb磁盘空间

Question

我们是一个集合，每个文档的平均大小为16 KB，文档数量为30,000，这就是平均总空间应该是

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

但是我们发现收集数据的大小是28.6 GB，它太可怕了。谁能知道这怎么可能，我已经检查了ea说谎者，当我们只有736个文档在这个文档中，当时它只消耗18.5 MB。我这个集合，我们只存储数字数据，而不是任何文本或大字符串。

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

这是统计信息。

> 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
}

而且我只使用插入，而不是更新，而是经常查询。

一些信息可能有助于查明情况：

• 收集模式为深树结构(7层)
• 为mongodb使用Windows (但在MongoLab (亚马逊托管的)实例中也遇到了同样的问题)
• 将集合移动到另一个db (在另一个服务器上)，也只使用insertion语句，但是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.9Meg，而不是16 is。

因此，您实际上使用的是: 28.4922 GB约(该集合中有31228个对象)。MongoDB也是这么说的。

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

这实际上是有意义的，因为预先分配未来的范围(我认为在这种情况下，它会预先分配一个新的2GB文件在这里)和可能的碎片，但您的碎片不是很高，也许是几个MBs，所以我不会说这是你的问题，但你可以运行一个契约，不管它，无论是删除，如果它造成问题。

我还想说，您的填充因子可能是关于1的，或者只是考虑到了碎片的数量，所以这不是太大的问题，它将分配比这里的对象更大的空间。

索引是一个单独的名称空间，因此它们不应该对集合命名空间范围产生太大影响(如果有的话)。

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

编辑

如果您经常更新(而不是插入)这个集合，这可以解释avgObjSize和您的假设，在这种情况下，契约应该将集合降到可评定的大小。

Answer 2

您需要考虑索引也会增加集合大小。此外，mongodb还有一些用于文档的paddingfactor。这使得文档的大小可以增加，而不需要总是移动文档，即使文档多了一个字节。填充因素相当不稳定，变化很大。因此，随着paddingfactor的增加，您的集合也会增加。请参阅统计数据()

从您的输出：

索引似乎没有问题，只是您的_id索引。填充因子似乎也没有问题，但这并不能说明任何问题，因为这只是应用于新写的实际填充因子。但是看起来有问题的是mongodb使用大约956 is而不是可疑的16 is报告您的avgObjSize。所以，要么查看错误的集合，要么保存与预期不同的内容(不确定16 is来自何处)。

您可以做的是运行紧凑的紧凑集合，然后检查由于填充因素分配了什么空间。