1

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

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

但是我们发现集合统计中的集合大小是28.6 GB，太可怕了。谁能告诉这怎么可能，当我们在这个文档中只有 736 个文档时，我检查了一个骗子，当时它只消耗了 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
}

而且我使用的插入只是不更新​​而是非常频繁地查询。

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

  • 集合的模式是深度树结构（7级）
  • 为 mongodb 使用 Windows 服务器（但在 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"
      }
   ]
}
4

2 回答 2

2

但是，我将在这里做出一些假设，形成有根据的猜测，我会说它们是正确的。

您在那里显示的所有测量值都以字节为单位。

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

因此，您实际上正在使用：大约 28.4922 GB（该集合中有 31228 个对象）。无论如何，这就是 MongoDB 所说的。

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

这实际上是有道理的，因为预先分配了未来的范围（我认为在这种情况下，它会在这里预先分配一个新的 2GB 文件）和可能的碎片，但是你的碎片不是很高，可能是几个 MB，所以我不会说这是你的问题，但你可以在该集合上运行一个紧凑型，如果它导致问题则删除它。

我还要说1，考虑到碎片的数量，您的填充因子可能大约或略高一点，所以这不是太大的问题，它会分配比这里的对象大小更大的空间。

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

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

编辑

如果您经常更新（不插入）此集合，这可以解释 avgObjSize 和您的假设，在这种情况下，紧凑型应该使集合恢复到可驯服的大小。

于 2013-01-23T10:19:28.803 回答
1

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

从您的输出：

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

您可以做的是运行 compact 以压缩集合，然后检查由于填充因子分配了哪些空间。

于 2013-01-23T10:14:12.403 回答