Question

我已经在其他地方发布了这个问题而没有回答，并决定在这里尝试。所以这就是：

我正在运行mongodb和grid.fs来存储小文件（小于20mbs）。这些是副本集的一部分。我目前存储的文件超过350000个。

我注意到这个块集占用了大约700GB的预分配空间，其中实际的块大约为40GB。尽管预先分配了700GB的数据，但随着时间的推移这种情况不断扩大。

请记住，每隔15分钟左右，我会删除超过5天的文件。所以理论上我的fs.chunks和fs.files大小应该随着时间的推移保持不变。

这是我的fs.chunks统计数据

rs0:PRIMARY> db.fs.chunks.stats()
{
    "ns" : "collection.fs.chunks",
    "count" : 470388,
    "size" : 43295062144,
    "avgObjSize" : 92041.17057407927,
    "storageSize" : 757794040352,
    "numExtents" : 373,
    "nindexes" : 2,
    "lastExtentSize" : 2146426864,
    "paddingFactor" : 1,
    "systemFlags" : 1,
    "userFlags" : 0,
    "totalIndexSize" : 40356736,
    "indexSizes" : {
        "_id_" : 17431232,
        "files_id_1_n_1" : 22925504
    },
    "ok" : 1
}

这种行为是正常的吗？我可以压缩（碎片整理吗？）块集合甚至声称预先分配的空间？如果我无法收回那个空间（我99％肯定能够这样做）是否有办法确保预先分配的空间最终会被使用而不是继续扩展？谢谢！

Answer 1

你有几个选择：

您可以在单个集合上运行compact命令，也可以在要缩小的所有集合中逐个运行。

http://www.mongodb.org/display/DOCS/Compact+Command

db.runCommand( { compact : 'mycollectionname' } )

如文档中所述，compact实际上并不回收磁盘空间，它只对整个集合和相关索引进行碎片整理和重建。

使用＆＃34; - 修复＆＃34;验证/重建数据文件的选项 - 如果数据库中存在任何损坏，则容易丢失数据。如果在同一个已安装的分区上没有足够的空间，则可以使用＆＃34; - repairpath＆＃34;指定另一个位置来构建压缩文件。

例如：

mongod --dbpath /data/db --repair --repairpath /data/db0

此处显示：http://docs.mongodb.org/manual/tutorial/recover-data-following-unexpected-shutdown/

如果这是一个副本集，如果从另一个副本重新同步该节点，则设置另一个选项 - 这实际上将从副本集的另一个副本节点构建整个数据库。您可以在http://docs.mongodb.org/manual/tutorial/resync-replica-set-member/找到有关此内容的更多详细信息。

mongodb的gridfs上的巨大尺寸。我应该紧凑吗？

1 个答案: