1

好吧，也许这应该从文档中清楚地看到，可悲的是，事实并非如此。我的猜测是，该紧凑型对集合进行了某种碎片整理 - 这样集合的填充因子将低于给定值。然而，这似乎不是真的：

> db.aaa.stats().paddingFactor
1.9980000000000002
> db.runCommand ( { compact: 'aaa', paddingFactor: 1.1 } )
{ "ok" : 1 }
> db.aaa.stats().paddingFactor
1.9980000000000002
> db.runCommand ( { compact: 'aaa', paddingFactor: 3 } )
{ "ok" : 1 }
> db.aaa.stats().paddingFactor
1.9980000000000002

如果这不是改变集合填充因子的方法，还有其他方法吗？

4

1 回答 1

5

我的猜测是，那个紧凑的作品对收藏进行了某种去碎片化

是的。它重写，对集合上的所有数据和索引进行去片段化。

这样集合的填充因子

不，它不会改变集合的填充因子。

从文档：

compact 压缩现有文档，但不会重置集合的 paddingFactor 统计信息。在为该集合中的文档分配新记录时，紧凑型 MongoDB 将使用现有的 paddingFactor。

因此，当您执行以下命令时，

db.runCommand ( { compact: 'aaa', paddingFactor: 1.1 } )

使用指定的填充因子更改集合中现有文档的记录大小。也就是说，所有现有记录现在都将具有10%它们document size的padding大小。

因此，在 DE-fragmentation 之后，所有现有记录的大小都会更改为，

record size = document size + (10% of document size)

它不会影响或更改整个集合的填充因子。

更改集合的填充因子的方法，还有其他方法吗？

不可以。您不能选择或更改集合的填充因子。从文档：

填充因子：一个自动校准的常数，用于确定 MongoDB 应该为磁盘上的每个文档容器分配多少额外空间。填充因子 1 意味着 MongoDB 将仅分配文档所需的空间量。填充因子 2 意味着 MongoDB 将分配文档所需空间量的两倍。

于 2014-11-29T01:10:13.537 回答