我开发了一个新网站，我想使用 GridFS 作为所有用户上传的存储，因为与普通文件系统存储相比，它提供了很多优势。
nginx 服务的 GridFS 的基准表明，它不如 nginx 服务的普通文件系统快。
是否有人已经在生产环境中使用 GridFS，或者会将其用于新项目？
【问题讨论】：
我在我们的一台服务器上使用 gridfs，该服务器是价格比较网站的一部分，具有可观的流量统计数据（每天约有 25,000 名访问者）。服务器没有太多 ram，2gigs，甚至 cpu 也不是很快（Core 2 duo 1.8Ghz），但服务器有足够的存储空间：raid 0 配置中的 10Tb（sata）。服务器所做的工作很简单：
我们的比价器上的每个产品都有一个图像（根据我们的产品数据库，大约有 1000 万个产品），服务器的工作是下载图像，调整它的大小，将其存储在 gridfs 上，然后将其交付给访问者浏览器...如果它不存在于网格中...或者...如果它已经存储在网格中，则将其传递给访问者浏览器。因此，这可以称为“传统 cdn 架构”。
自该服务器启动并运行以来，我们已在该服务器上存储和处理了 400 万张图像。调整大小和存储的东西是由一个简单的 php 脚本完成的……但可以肯定的是，python 脚本或类似 java 的东西可能会更快。
当前数据大小：11.23g
当前存储大小：12.5g
指数：5
索引大小：849.65m
关于可靠性：这是非常可靠的。服务器不加载，索引大小还可以，查询很快
关于速度：当然，它不如本地文件存储快，可能慢 10%，但足够快，即使在需要处理图像时也可以实时使用，在我们的例子中，非常依赖于 php .维护和开发时间也减少了：删除单个或多个图像变得如此简单：只需使用简单的删除命令查询数据库。另一个有趣的事情：当我们重新启动我们的旧服务器时，使用本地文件存储（数千个文件夹中的数百万个文件），它有时会挂起几个小时，因为系统正在执行文件完整性检查（这真的需要几个小时......）。 gridfs 不再有这个问题，我们的图像现在存储在大 mongodb 块中（2gb 文件）
所以...在我看来...是的，gridfs 足够快速和可靠，可以用于生产。
【讨论】：
但请注意修复大型数据库 - 我们正在开发一个新系统，mongo 并没有完全退出，修复 7TB GridFS 看起来需要 130 小时。
因此，我想我会考虑切换到 OpenStack Swift 或 Ceph。 不过，在那之前它还不错。并且 nginx-gridfs 模块很贴心。
【讨论】：
如前所述，它可能不如普通文件系统快，但与 ordinary filesystems 相比，它为您提供了优势，我认为值得放弃一点速度。
最终，通过分片，您可能会达到一个点，但是 GridFS 存储实际上成为比普通文件系统和单个节点更快的选择。
【讨论】：
除非您知道自己在做什么，否则我不建议您使用 gridfs。 GridFS 只是抽象层，它将文件拆分为块并将文件存储在两个集合中。更多文件 - 更多开销。如果您希望文件大小几乎相同，不超过 32M 左右 - 您是对的。 不要尝试在 gridfs 上存储大文件。为什么？
如果您考虑读取加载项目 - 考虑将文件直接加载到文档中（如果大小为 16M 或更小）或选择另一个 clusterfs，并将文件名/inode 链接到您的逻辑。
希望这会有所帮助。
【讨论】：
mdirolf 的 nginx-gridfs 模块非常棒，而且设置起来相当容易。我们在paint.ly 的生产中使用它来服务所有的画，到目前为止没有任何问题。
【讨论】：