GridFS是否足够快速，可靠地用于生产？

我开发了一个新网站，并希望将GridFS用作所有用户上载的存储，因为与常规文件系统存储相比，它提供了很多优势。

nginx服务的GridFS的基准测试表明，它不如nginx服务的普通文件系统快。

Nginx基准

有没有人在生产环境中使用GridFS，或者将其用于新项目？

我在其中一台服务器上使用gridfs，该服务器是价格比较网站的一部分，具有可观的流量统计信息（每天约有25k访客）。服务器没有太多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。维护和开发时间也减少了：删除单个或多个图像变得如此简单：只需使用简单的delete命令查询数据库。另一个有趣的事情是：当我们使用本地文件存储重新启动旧服务器时（成千上万个文件夹中有数百万个文件），由于系统正在执行文件完整性检查（有时要花费数小时……），有时它挂起了几个小时。gridfs不再存在此问题，我们的图像现在存储在较大的mongodb块中（2gb文件）

所以...在我看来...是的，gridfs足够快速，可靠，可以用于生产。

如前所述，它可能没有普通文件系统那么快，但是它给您带来了优于普通文件系统的优势，我认为值得放弃一点速度。

最终，通过分片，您可能会达到一个点，在该点上，与普通文件系统和单个节点相比，GridFS存储实际上成为更快的选择。

但是，要对大型数据库进行维修，请注意-我们正在开发一个新系统，mongo并未干净退出，并且维修7TB GridFS看起来将需要130个小时。

因此，我想我将考虑切换到OpenStack Swift或Ceph。尽管如此，直到那时还是不错的。而且nginx-gridfs模块很不错。

mdirolf的nginx-gridfs模块非常棒，并且很容易设置。我们正在paint.ly的生产中使用它来为所有画作服务，到目前为止没有任何问题。

我不建议您使用gridfs，除非您知道自己在做什么。GridFS只是抽象层，它将文件分成多个块并将文件存储在两个集合中。更多文件-更多开销。如果您希望文件大小大致相同，不超过32M左右-则使用正确的方法。不要尝试在gridfs上存储大文件。为什么？

1. 使用不同语言的驱动程序可以在读取文件的一小部分时读取整个文件（例如，块）。
2. 修改文件可能会影响所有块并增加数据库负载如果文件系统正在增长，则必须决定分片gridfs。小心！分片初始化时不能保证一致性！

如果您考虑读取已加载的项目，请考虑将文件直接加载到文档中（如果大小为16M或更小），或者选择另一个clusterfs，然后将文件名/索引节点链接到您的逻辑。

希望这可以帮助。