我开发了一个新网站，我想使用 GridFS 作为所有用户上传的存储，因为与普通文件系统存储相比，它提供了很多优势。
nginx 服务的 GridFS 的基准测试表明，它不如 nginx 服务的普通文件系统快。
是否有人已经在生产环境中使用 GridFS，或者会将其用于新项目？
问问题
46448 次
5 回答
120
我在我们的一台服务器上使用 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 足够快速和可靠，可以用于生产。
于 2011-04-11T21:44:53.773 回答
12
如前所述，它可能不如普通文件系统快，但它为您提供了优于普通文件系统的优势，我认为值得放弃一点速度。
最终，通过分片，您可能会达到一个点，但是 GridFS 存储实际上成为比普通文件系统和单个节点更快的选择。
于 2010-09-05T14:09:09.023 回答
6
不过，请注意修复大型数据库 - 我们正在开发一个新系统，mongo 并没有完全退出，修复 7TB GridFS 看起来需要 130 小时。
因此，我想我会考虑切换到 OpenStack Swift 或 Ceph。不过，在那之前它还不错。nginx-gridfs 模块很贴心。
于 2014-02-24T23:00:36.357 回答
5
mdirolf 的 nginx-gridfs 模块非常棒，而且很容易设置。我们在paint.ly的生产中使用它来服务所有的画作，到目前为止没有任何问题。
于 2010-11-26T00:02:58.453 回答
2
除非您知道自己在做什么，否则我不建议使用 gridfs。GridFS 只是抽象层，它将文件拆分为块并将文件存储在两个集合中。更多文件 - 更多开销。如果您希望文件大小几乎相同，不超过 32M 左右 - 您是对的。不要尝试在 gridfs 上存储大文件。为什么？
- 不同语言的驱动程序在读取文件的一小部分时可能会读取整个文件（例如块）。
- 修改文件可能会影响所有块并增加数据库负载如果您的文件系统正在增长，您将不得不决定对 gridfs 进行分片。当心！分片初始化时不保证一致性！
如果您考虑读取加载项目 - 考虑将文件直接加载到文档中（如果大小为 16M 或更小）或选择另一个 clusterfs，并将文件名/inode 链接到您的逻辑。
希望这可以帮助。
于 2013-02-03T18:33:47.293 回答