我正在尝试找到为大文件创建可扩展存储的最佳解决方案。文件大小可以从 1-2 兆字节到 500-600 兆字节不等。
我找到了一些关于 Hadoop 和它的 HDFS 的信息，但它看起来有点复杂，因为我不需要任何 Map/Reduce 作业和许多其他功能。现在我正在考虑使用 MongoDB，它是 GridFS 作为文件存储解决方案。
现在的问题是：
谢谢。
我在这里只能回答MongoDB，我不会假装我对HDFS和其他此类技术了解很多。
GridFs 实现完全是驱动程序本身的客户端。这意味着对 MongoDB 本身内文件服务的上下文没有特殊的加载或理解，实际上 MongoDB 本身甚至不理解它们是文件 ( http://docs.mongodb.org/manual/applications/gridfs/ )。
这意味着查询filesorchunks集合的任何部分将导致与任何其他查询相同的过程，从而将所需的数据加载到您的工作集中（http://en.wikipedia.org/wiki/Working_set ) 表示 MongoDB 在给定时间范围内保持最佳性能所需的一组数据（或当时所有加载的数据）。它通过将其分页到 RAM 中来做到这一点（从技术上讲，操作系统确实如此）。
要考虑的另一点是这是驱动程序实现的。这意味着规范可能会有所不同，但是，我认为不会。所有驱动程序都允许您从集合中查询一组文档，该files集合仅包含文件元数据，允许您稍后chunks通过单个查询从集合中提供文件本身。
然而，这不是重要的事情，你想提供文件本身，包括它的数据；这意味着您将把files集合及其后续chunks集合加载到您的工作集中。
考虑到这一点，我们已经遇到了第一个障碍：
来自gridfs的文件是否会缓存在ram中以及它将如何影响读写性能？
直接从 RAM 读取小文件的性能可能很棒；写的也一样好。
对于较大的文件，并非如此。mongod大多数计算机不会有 600 GB 的 RAM，实际上很可能在单个实例上容纳单个文件的 600 GB 分区。这会产生一个问题，因为该文件需要适合您的工作集才能提供服务，但它不可能比您的 RAM 大；此时，您可能会遇到页面抖动（http://en.wikipedia.org/wiki/Thrashing_%28computer_science%29），服务器只是在尝试加载文件时 24/7 出现页面错误。这里的写作也好不到哪里去。
解决此问题的唯一方法是开始将单个文件放在多个分片中:\。
注意：要考虑的另一件事是chunks“块”的默认平均大小为 256KB，因此对于 600GB 文件来说，这是很多文档。此设置在大多数驱动程序中都是可操作的。
当我尝试同时写入几个文件时，gridfs 会发生什么。读/写操作会有任何锁吗？（我只会将它用作文件存储）
GridFS 只是一个规范，它使用与任何其他集合相同的锁，包括数据库级别（2.2+）或全局级别（2.2 之前）的读写锁。两者也确实会相互干扰，即如何确保对正在写入的文档进行一致的读取？
话虽这么说，存在争用的可能性取决于您的场景细节、流量、并发写入/读取的数量以及我们不知道的许多其他事情。
也许还有其他一些解决方案可以更有效地解决我的问题？
我个人发现，减少冗余格式的 S3（如@muggy 所说）最适合在 MongoDB 中存储有关文件的元数据的一部分，就像使用 GridFS 但没有块收集一样，让 S3 处理所有分发、备份和给你的其他东西。
希望我已经清楚了，希望它有所帮助。
编辑：与我不小心说的不同，MongoDB 没有集合级锁，它是数据库级锁。
您是否考虑过将元数据保存到 MongoDB 并将实际文件写入 Amazon S3？两者都有出色的驱动程序，后者是高度冗余的云/cdn 就绪文件存储。我会试一试。
我将从回答前两个开始：
GridFS 可能不是您问题的最佳解决方案。当您处理这种情况时，写锁可能会变得很痛苦，特别是对于大文件。还有其他数据库可以为您解决这个问题。HDFS 是一个不错的选择，但正如你所说，它非常复杂。我建议考虑像 Riak 或 Amazon 的 S3 这样的存储机制。它们更倾向于存储文件，并且最终不会出现重大缺点。S3 和 Riak 都具有出色的管理设施，并且可以处理巨大的文件。虽然使用 Riak，但我知道，你必须做一些文件分块才能存储超过 100mb 的文件。尽管如此，通常最好的做法是对大文件进行一定程度的分块。