Question

我们有一个使用GridFS的MongoDB群集。 gridfs的fs.chunks表在两个replicasets上分片。磁盘空间的使用率非常高。对于90GB的数据，我们需要超过130GB的磁盘空间。

似乎fs.chunks表需要空间。我总结了fs.files的“length”字段，显示了90GB的空间。两个分片的“大小”字段的总和是130GB。这是集合中包含的有效负载数据的实际大小，对吗？

这意味着它有40GB的开销吗？它是否正确？它来自哪里？它是BSON编码吗？有没有办法减少开销？

mongos> db.fs.chunks.stats()
{
    "sharded" : true,
    "ns" : "ub_datastore_preview.fs.chunks",
    "count" : 1012180,
    "numExtents" : 106,
    "size" : 140515231376,
    "storageSize" : 144448592944,
    "totalIndexSize" : 99869840,
    "indexSizes" : {
            "_id_" : 43103872,
            "files_id_1_n_1" : 56765968
    },
    "avgObjSize" : 138824.35078345748,
    "nindexes" : 2,
    "nchunks" : 2400,
    "shards" : {
            "ub_datastore_qa_group1" : {
                    "ns" : "ub_datastore_preview.fs.chunks",
                    "count" : 554087,
                    "size" : 69448405120,
                    "avgObjSize" : 125338.44887174758,
                    "storageSize" : 71364832800,
                    "numExtents" : 52,
                    "nindexes" : 2,
                    "lastExtentSize" : 2146426864,
                    "paddingFactor" : 1,
                    "systemFlags" : 1,
                    "userFlags" : 0,
                    "totalIndexSize" : 55269760,
                    "indexSizes" : {
                            "_id_" : 23808512,
                            "files_id_1_n_1" : 31461248
                    },
                    "ok" : 1
            },
            "ub_datastore_qa_group2" : {
                    "ns" : "ub_datastore_preview.fs.chunks",
                    "count" : 458093,
                    "size" : 71066826256,
                    "avgObjSize" : 155136.2414531547,
                    "storageSize" : 73083760144,
                    "numExtents" : 54,
                    "nindexes" : 2,
                    "lastExtentSize" : 2146426864,
                    "paddingFactor" : 1,
                    "systemFlags" : 1,
                    "userFlags" : 0,
                    "totalIndexSize" : 44600080,
                    "indexSizes" : {
                            "_id_" : 19295360,
                            "files_id_1_n_1" : 25304720
                    },
                    "ok" : 1
            }
    },
    "ok" : 1
}

Answer 1

这是集合中包含的有效负载数据的实际大小，对吗？

是

这意味着它有40GB的开销吗？这是对的吗？

有点儿。但它看起来异常大。

它来自哪里？它是BSON编码吗？

不，BSON数据编码没有那么大的开销。但有时会添加元数据。

在mongo中，开销的主要来源通常是元数据，但是如果使用参考网格规范 - 它应该不会那么大。

例如，在我们的存储空间中，我们有：

db.fs.files.aggregate([{$group: {_id: null, total: { $sum: "$length"}}}])
{
    "result" : [
        {
            "_id" : null,
            "total" : NumberLong("4631125908060")
        }
    ],
    "ok" : 1
}

并且

db.fs.chunks.stats()
{
    "ns" : "grid_fs.fs.chunks",
    "count" : 26538434,
    "size" : NumberLong("4980751887148"),
    "avgObjSize" : 187680.70064526037,
    "storageSize" : NumberLong("4981961457440"),
    "numExtents" : 2342,
    "nindexes" : 2,
    "lastExtentSize" : 2146426864,
    "paddingFactor" : 1,
    "systemFlags" : 1,
    "userFlags" : 0,
    "totalIndexSize" : 2405207504,
    "indexSizes" : {
        "_id_" : 1024109408,
        "files_id_1_n_1" : 1381098096
    },
    "ok" : 1
}

因此，4.8 tb数据的开销约为300 gb。

Answer 2

问题一直是来自GridFS的“孤立的块”。 GridFS首先写入块然后是元数据，如果出现问题，已经写入的块保持为“孤立的块”并且必须手动清理。

Answer 3

您节省了90 GB的数据，但却消耗了130 GB的磁盘空间。

这意味着大约44％的开销。

如本blog post所述，GridFS的存储开销约为45％，在您的情况下几乎相同。

GridFS的存储开销

3 个答案: