GridFS磁盘管理

Question

在我的环境中，我可以拥有5-10 GB的DB或10 TB的DB (视频记录)。

关注5-10 GB:如果我保留prealloc的默认设置small-files，我实际上可以因为分配而释放20-40%的磁盘空间。

在我的生产环境中，磁盘大小可以是512 g，但是用户可以将DB分配限制为10G。

为了实现这一点，我有一个预定的任务，在DB dataSize达到某个阈值时从DB中删除旧文档。

我不能使用capped-collection (GridFS，切分限制，不能删除随机文档.)，我不能使用--no-prealloc/small-files标志，因为我需要插入的文件是有效的。

所以会发生这样的情况:如果dataSize达到10G，那么fileSize至少是12G，所以我需要考虑这一点，降低2GB的阈值(并且损失了大量的磁盘空间)。

我想要的是告诉蒙戈预先分配所有用户要求的10 GB，并进一步禁用预分配。

例如，使用--非预分配文件和--小文件运行mongod，但预先分配所有10 GB的内存。

我在这里得到的另一个保护是保护用户免受突然出现的磁盘满错误的影响.如果他经常下载“权力的游戏”剧集到同一个驱动器，他就不能从DB10G中获取空间，因为它已经预先分配了。

(使用C#驱动程序)

Answer 1

我想我找到了一个解决方案:您可能需要查看--quota和--quotafiles命令行opts。在您的示例中，您还可能希望添加--smalfiles选项。所以

mongod --smallfiles --quota --quotafiles 11

应该为数据提供精确的10224 MB大小，添加16 MB的默认命名空间文件大小等于目标大小10 MB(不包括索引)。

Answer 2

以下内容适用于根据文档进行的定期收集。但是，由于元数据可以附加到文件中，所以它很可能也适用于GridFS。

MongoDB使用所谓的用来存储数据的记录。记录由两部分组成:实际数据和称为“填充”的东西。填充基本上是未使用的数据，如果文档的大小增加，就会使用这些数据。其原因是，GridFS中的文档或文件块从未被分割以提高查询性能。因此，当文档或文件块的大小增加时，它必须在每次文件被修改时移动到数据文件中的不同位置，这在IO和时间方面可能是非常昂贵的操作。因此，对于默认设置，如果文档或文件块的大小增大，则使用填充而不是移动文件，从而减少了在数据文件中移动数据的需要，从而提高了性能。只有当数据增长超过预先分配的填充时，文档或文件块才会在数据文件中移动。

预分配填充空间的默认策略是"usePowerOf2Sizes“，它通过获取文档大小来确定填充大小，并使用下一个大小为两个大小的幂作为为文档预先分配的大小。假设我们有一个47字节的文档，usePowerOf2Sizes策略将为该文档预先分配64个字节，从而产生17个字节的填充。然而，还有另一种分配前战略。它被称为"exactFit“。它通过将文档大小乘以动态计算"paddingFactor“来确定填充空间。据我所知，填充因子取决于相应集合中文档的平均增长。由于在您的情况下我们讨论的是静态文件，填充因子应该始终为0，因此不应该再有任何“丢失”的空间。

因此，我认为一个可能的解决方案是将文件和块集合的分配策略更改为exactFit。你能试着和我们分享你的发现吗？