我正在尝试将我的应用程序结果存储在mongo数据库中。这有一些问题，首先我们生成大量数据，因为它是原始图像文件，每条记录高达50MB，全速每秒5条记录，这是最糟糕的情况，尽管不是典型的。这不是使用gridFS的问题。在mongod.cfg中，我们使用的是directoryPerDB：true，我将Results数据库文件夹的符号链接创建到专用SSD，其中保留了所有结果数据库。所有设置数据都保存在OS驱动器上的几个不同数据库中，结果数据具有专用驱动器。这对我们的应用来说非常有用。
我的问题是填满结果磁盘。我需要基本上有一个最大大小的上限集合，然后只删除最旧的文件。但我没有看到使用gridFS做到这一点的方法？是否有一个设置或我遗漏的东西可以限制这个？
我找到了这个答案GridFS disk management，但这似乎适用于mongod，我认为你不能为每个数据库设置一个配额，因为结果数据库是我唯一需要限制的数据库。
此时我想我会编写一个任务，如果总数超过阈值限制，会定期清理最旧的文件，我只是担心这不会非常有效。有没有关于处理这个问题的最佳方法的建议？
答案 0 :(得分：3)
总而言之：您无法以有用的方式限制GridFS。原因如下：
当您在GridFS中存储文件时，默认情况下会将其拆分为255kB的块，这个集合名为fs.chunks，绝对可以通过执行
db.createCollection("fs.chunks",{capped:true, size:52428800})
封顶适用于那些单独文件的块。因此，当您添加一个使fs.chunks超过其上限的文件时，只会移除最旧文件的块。另一个问题是，默认情况下存储在fs.files中的文件元数据不会被更新，而fs.files中的陈旧条目不再存在fs.chunks中的条目，或者 - 更糟糕 - 只有一小部分仍然存在。
有一些方法可以克服这个问题（例如，检查块组合的字节大小是否等于相应文件的fs.files文档的长度字段），但它们至少同样复杂（并且更慢！）当进行检查预插入时，使用集合统计数据收集将超过阈值，并删除尽可能多的最旧文件以适应新文件而不超过阈值。
顺便说一下，后者是我对如何解决问题的建议。
另一个解决方案是使用一个专用实例，并在我对你提到的问题的回答中应用了限制。