我的工作是为静态图像/视频文件设计一个分布式系统。数据的大小大约是几十太字节。它主要用于HTTP访问(因此没有对数据进行处理;或者只是简单的处理，比如调整大小(不过这并不重要，因为它可以直接在应用程序中完成)。
为了更清楚一点，这是一个系统:
- 必须是分布式的(水平尺度)，因为数据的总大小非常大。
- 主要通过HTTP提供小的静态文件(如图像，缩略图，短视频)。
- 一般不需要处理数据(因此不需要MapReduce)
- 对数据设置HTTP访问可以很容易地完成。
- (应该有)良好的吞吐量。
我正在考虑:
-
本地网络文件系统:但由于一台机器无法容纳数据，因此似乎不可行
-
Hadoop文件系统。我以前使用过Hadoop mapreduce，但是我没有使用Hadoop作为HTTP请求的静态文件存储库的经验。所以我不知道这是否可行，或者是否是一种推荐的方法。
-
MogileFS。它看起来很有前途，但是我觉得使用MySQL来管理本地文件(在一台机器上)会产生太多的开销。
有什么建议吗?
我是Weed-FS的作者。对于您的需求，WeedFS是理想的选择。Hadoop不能处理很多小文件，除了你的原因外，每个文件都需要在master中有一个入口。如果文件数量太大，hdfs主节点无法扩展
当使用最新的Golang版本编译时，Weed-FS变得更快了。
最近在Weed-FS上做了许多新的改进。现在，您可以很容易地使用内置的上传工具进行测试和比较。这是在一个目录下递归地上传所有文件。
weed upload -dir=/some/directory
现在你可以通过"du -k/some/directory"one_answers"ls -l/your/weed/volume/directory"来比较weed - fs的磁盘使用情况。
我猜你会需要复制数据中心，机架感知等。他们现在进来了!
Hadoop针对大文件进行了优化，例如，它的默认块大小为64M。在Hadoop上，很多小文件既浪费又难以管理。
您可以看看其他分布式文件系统，例如GlusterFS
Hadoop有一个rest API来访问文件。请参阅文档中的此条目。我觉得Hadoop并不适合存储大量的小文件。
- HDFS并不能有效地访问小文件:它主要是为大文件的流式访问而设计的。读取小文件通常会导致大量的查找和从一个datanode跳到另一个datanode以检索每个小文件，所有这些都是一种低效的数据访问模式。
- HDFS中的每个文件、目录和块在namenode的内存中表示为一个对象，每个对象占用150字节。块大小为64mb，所以即使文件大小为10kb，也会分配整个64mb的块，这是浪费磁盘空间。
- 如果文件非常小，并且有很多文件，那么每个地图任务处理的输入很少，并且有更多的地图任务，每个任务都强加了额外的记账开销。比较一个1GB的文件分成16个64MB块的文件和10000个左右100KB的文件。这10,000个文件每个使用一个映射，并且作业时间可能比使用单个输入文件的等效作业慢数十倍或数百倍。
在"Hadoop Summit 2011"中，Karthik Ranganathan发表了一篇关于Facebook Messaging的演讲，他在演讲中透露了这一点:Facebook通过HDFS存储数据(个人资料，消息等)，但他们不使用相同的基础设施来存储图像和视频。他们有自己的名为Haystack的图像系统。它不是开源的，但是他们分享了抽象设计层面的细节。
这让我想到了weed-fs:一个受Haystacks设计启发的开源项目。它是为储存文件而量身定做的。
如果您能够批处理文件，并且在添加到HDFS后不需要更新批处理文件，那么您可以将多个小文件编译成一个更大的二进制序列文件。这是在HDFS中存储小文件的一种更有效的方式(正如Arnon上面指出的，HDFS是为大文件设计的，当处理小文件时效率非常低)。
这是我使用Hadoop处理CT图像时采用的方法(详细信息请参见Hadoop中的图像处理)。在这里，225个CT扫描切片(每个单独的图像)被编译成一个更大的二进制序列文件，用于长流式读取Hadoop进行处理。
希望这对你有帮助!
G