GridFS是否足够快速可靠地进行生产？

Question

我开发了一个新网站，我希望将GridFS用作所有用户上传的存储空间，因为与普通文件系统存储相比，它提供了许多优势。

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

Benchmark with nginx

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

Answer 1

我在我们的一台服务器上使用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快速可靠，足以用于制作。

Answer 2

如前所述，它可能没有普通文件系统那么快，但它会为你提供优于ordinary filesystems的优势，我认为值得放弃一点速度。

最终，通过分片，您可能会达到一个点，然而GridFS存储实际上变得更快，而不是普通的文件系统和单个节点。

Answer 3

mdirolf的nginx-gridfs模块很棒，很容易安装。我们在paint.ly的制作中使用它来为所有画作提供服务，到目前为止没有任何问题。

Answer 4

虽然我们正在开发一个新的系统，mongo并没有干净地退出，修复7TB GridFS看起来需要130小时才能解决大型数据库的维修问题。

因此，我想我会考虑转向OpenStack Swift或Ceph。 不过，在那之前一切都很好。而且nginx-gridfs模块很可爱。

Answer 5

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

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

如果您考虑读取已加载的项目 - 请考虑直接将文件加载到文档中（如果大小为16M或更小）或选择其他clusterfs，并将filename / inode链接到您的逻辑。

希望这有帮助。