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

我开发了一个新网站,我想使用GridFS作为所有用户上传的存储,因为与普通的文件系统存储相比,它提供了很多优势.

由nginx提供服务的GridFS基准测试表明,它不如nginx提供的普通文件系统快.

使用nginx进行基准测试

有人在那里,谁已经在生产环境中使用GridFS,或者将它用于新项目？

1> Manu Eidenbe..：

---

我在我们的一台服务器上使用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.5克

指数:5

指数规模:849.65米

关于可靠性:这是非常可靠的.服务器没有加载,索引大小正常,查询速度很快

关于速度:当然,它是不是快速的本地文件存储,可能慢10%,但足够快,即使在需要处理图像时,实时使用,这在我们的情况下,非常依赖于PHP.维护和开发时间也减少了:删除单个或多个映像变得非常简单:只需使用简单的删除命令查询数据库.另一个有趣的事情是:当我们重新启动我们的旧服务器时,使用本地文件存储(数千个文件夹中有数百万个文件),它有时会挂起几个小时,因为系统正在执行文件完整性检查(这确实耗费了数小时......).我们不再使用gridfs这个问题,我们的图像现在存储在大mongodb块(2gb文件)中

所以...在我的脑海里......是的,gridfs快速可靠,足以用于生产.

---

我们使用raid 0,因为在我们的特定情况下,图像数据可能是易失性的.如果图像丢失并不重要,因为我们将再次从商家网站下载它.实际上,我们可以认为我们的服务器是一个简单的图像缓存服务器.

---

我很震惊,任何人都会使用raid 0作为生产网站上的主存储.即使有良好的备份,增加存储故障的可能性也是为了提高性能所付出的代价.

---

@ManuEidenberger为什么使用GridFS来存储宁可存储在MongoDB文档中的图像？我猜你没有达到16 MB的文件大小限制.将图像作为BLOB存储在MongoDB文档中会更有效,因为您不需要在MongoDB文档之上使用GridFS层.

2> Tom..：

---

如上所述,它可能没有普通文件系统那么快,但它提供了优于普通文件系统的优势,我认为值得放弃一点速度.

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

3> 小智..：

---

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

---

看来paint.ly不再可用了.:(

4> Nick..：

---

虽然我们正在开发一个新的系统,mongo没有干净地退出,修复7TB GridFS看起来需要130小时.

因此,我想我会考虑转向OpenStack Swift或Ceph.不过,在那之前一切都很好.nginx-gridfs模块很棒.