MongoDB作为文件存储

Question

我正在努力寻找为大文件创建可扩展存储的最佳解决方案.文件大小可以从1-2兆字节到500-600千兆字节不等.

我找到了一些关于Hadoop和它的HDFS的信息,但它看起来有点复杂,因为我不需要任何Map/Reduce作业和许多其他功能.现在我正在考虑使用MongoDB和它的GridFS作为文件存储解决方案.

现在的问题是:

1. 当我尝试同时写几个文件时,gridfs会发生什么.读/写操作会有锁定吗？(我将仅将其用作文件存储)
2. 来自gridfs的文件是否会在ram中缓存,以及它将如何影响读写性能？
3. 也许有一些其他解决方案可以更有效地解决我的问题？

谢谢.

Answer 1

我只能在这里回答MongoDB,我不会假装我对HDFS和其他类似技术有很多了解.

GridFs实现完全是驱动程序本身的客户端.这意味着MongoDB本身没有特殊的加载或理解文件服务的上下文,实际上MongoDB本身甚至不理解它们是文件(http://docs.mongodb.org/manual/applications/gridfs/).

这意味着查询files或chunks集合的任何部分将导致与任何其他查询相同的过程,从而将所需的数据加载到您的工作集中(http://en.wikipedia.org/wiki/Working_set)表示MongoDB在给定时间范围内所需的一组数据(或当时所有加载的数据),以保持最佳性能.它通过将其分配到RAM(技术上操作系统)来实现这一点.

需要考虑的另一点是,这是驱动程序实现的.这意味着规范可能会有所不同,但我不认为这样做.所有驱动程序都允许您从files集合中查询一组文档,这些文档仅包含文件元数据,允许您稍后chunks通过单个查询从集合中提供文件本身.

然而,这不重要,您希望为文件本身提供服务,包括其数据; 这意味着您将把files集合及其后续chunks集合加载到工作集中.

考虑到这一点,我们已经遇到了第一个障碍:

来自gridfs的文件是否会在ram中缓存,以及它将如何影响读写性能？

小文件的读取性能可能非常棒,直接来自RAM; 写作也一样好.

对于较大的文件,不是这样.大多数计算机都没有600 GB的RAM,事实上,在单个mongod实例上容纳单个文件的600 GB分区是非常正常的.这会产生一个问题,因为为了提供服务,该文件需要适合您的工作集,但它不可能大于您的RAM; 在这一点上你可能有页面颠簸(http://en.wikipedia.org/wiki/Thrashing_%28computer_science%29),服务器只是试图加载文件24/7页面错误.这里的写作也不是更好.

解决这个问题的唯一方法是开始在多个分片中放置一个文件:\.

注意:还需要考虑的另一件事是chunks"块" 的默认平均大小是256KB,因此600GB文件的文档很多.此设置在大多数驱动程序中是可操作的.

当我尝试同时写几个文件时,gridfs会发生什么.读/写操作会有锁定吗？(我将仅将其用作文件存储)

GridFS只是一个规范,使用与任何其他集合相同的锁,数据库级别(2.2+)或全局级别(2.2之前)的读写锁定.这两者确实相互干扰,即如何确保对正在写入的文档的一致读取？

据说存在争用的可能性取决于您的方案细节,流量,并发写入/读取的数量以及我们不知道的许多其他事情.

也许有一些其他解决方案可以更有效地解决我的问题？

我个人已经发现S3(如@mluggy所说)减少冗余格式最好在MongoDB中存储关于文件的元数据的一部分,就像使用GridFS但没有块集合,让S3处理所有的分发,备份和其他的东西给你.

希望我一直很清楚,希望它有所帮助.

编辑:与我意外说的不同,MongoDB没有集合级锁,它是一个数据库级锁.

Answer 2

您是否考虑过将元数据保存到 MongoDB 并将实际文件写入 Amazon S3？两者都有出色的驱动程序，后者是高度冗余的、云/cdn 就绪的文件存储。我想试一试。