GridFS是否足够快速和可靠的生产？
我开发了一个新的网站，我想使用GridFS作为所有用户上传的存储，因为与普通的文件系统存储相比，它提供了很多优势。
Nginx提供的GridFS基准testing表明，它并不像nginx提供的正常文件系统那么快。
与nginx的基准
有没有人在生产环境中使用GridFS，或者将它用于新项目？
我使用gridfs在我们的服务器上工作，这是一个价格比较网站的一部分，光荣的stream量统计（每天约25k人次）。 服务器没有太多的内存，2gig，甚至CPU是不是真的很快（酷睿2双1.8Ghz），但服务器有足够的存储空间：RAID 10configuration10TB（SATA）。 服务器正在做的工作非常简单：
我们的价格比较器上的每个产品都有一个图像（根据我们的产品数据库，有大约1000万个产品），服务器的工作是下载图像，调整图像大小，将其存储在网格上，然后传递给访问者浏览器。 ..如果它不存在于网格中…或者…如果它已经存储在网格中，则将其传递给访问者浏览器。 所以这可以称为“传统的cdn模式”。
自服务器启动并运行以来，我们已经在该服务器上存储和处理了400万个图像。 resize和存储的东西是通过一个简单的PHP脚本来完成的……但是肯定的是，一个python脚本或类似java的东西可能会更快。
当前数据大小：11.23g
当前的存储大小：12.5克
指数：5
索引尺寸：849.65米
关于可靠性：这是非常可靠的。 服务器不加载，索引大小正常，查询速度快
关于速度：当然，速度不是本地文件存储，速度可能慢10％，但是即使在需要处理图像时也能够实时使用，这在我们的例子中非常依赖于php。 维护和开发时间也缩短了：删除单个或多个图像变得如此简单：只需使用简单的删除命令查询数据库即可。 另一个有趣的事情是：当我们用本地文件存储（数以千计的文件夹中的数百万个文件）重新启动旧服务器时，它有时会挂起几个小时，导致系统正在执行文件完整性检查（这真的花了几个小时…）。 我们没有这个问题与gridfs，我们的图像现在存储在大的mongodb块（2GB文件）
所以…在我看来…是的，gridfs是快速和可靠的，足以用于生产。
如前所述，它可能不如普通的文件系统那么快，但是它给了你比普通文件系统更多的优势，我认为这是值得放弃的。
最终，在分片的情况下，你可能会达到一个点，但是在GridFS存储实际上成为更快的选项，而不是普通的文件系统和单个节点。
mdirolf的nginx-gridfs模块非常好，相当容易安装。 我们在油漆生产中使用它来为所有的画作服务，到目前为止没有任何问题。
虽然我们正在开发一个新的系统，但是mongo并没有干净的退出，而修复7TB GridFS看起来好像需要130个小时。
正因为如此，我想我会考虑切换到OpenStack Swift或Ceph。 不过，在那之前，这样还不错。 而nginx-gridfs模块是甜蜜的。
除非你知道你在做什么，否则我不推荐使用gridfs。 GridFS只是抽象层，它将文件分块并将文件存储在两个集合中。 更多的文件 – 更多的开销。 如果你期望的文件大小相同，不超过32M左右 – 你是在正确的方式。 不要尝试在gridfs上存储大文件。 为什么？
- 当读取文件的小部分时，不同语言的驱动程序可能会读取整个文件（例如块）。
- 修改文件可能会影响所有块，并增加数据库负载如果您的文件系统正在成长，您将不得不决定分割网格。 小心！ 分片初始化时，不保证一致性！
如果你考虑读取加载的项目 – 考虑直接加载文件到文档（如果16M或更小的大小）或select另一个clusterfs，并链接文件名/ inode到你的逻辑。
希望这可以帮助。
