我的工作是为静态图像/视频文件设计一个分布式系统。数据的大小约为数十TB。它主要用于http访问（因此不处理数据；或者只是简单的处理，比如调整大小——但是这并不重要，因为它可以直接在应用程序中完成）。
更清楚一点，这是一个系统：
必须是分布的（水平尺度），因为数据的总大小非常大。
主要通过http提供小型静态文件（如图像、缩略图、短视频）。
一般不需要对数据进行处理（因此不需要mapreduce）
对数据设置http访问很容易。
（应该有）良好的吞吐量。
我正在考虑：
本机网络文件系统：但它似乎不可行，因为数据不能放入一台机器。
hadoop文件系统。我以前使用过hadoopmapreduce，但没有将hadoop用作http请求的静态文件存储库的经验。所以我不知道这是可能的还是一个推荐的方法。
莫吉列夫。这看起来很有希望，但我觉得使用mysql来管理本地文件（在一台机器上）会产生太多的开销。
有什么建议吗？
4条答案
按热度按时间nwwlzxa71#
hadoop针对大型文件进行了优化，例如，它的默认块大小为64m。很多小文件在hadoop上既浪费又难以管理。
您可以看看其他分布式文件系统，例如glusterfs
kpbwa7wx2#
hadoop有一个restapi来访问文件。请参阅文档中的此条目。我觉得hadoop不是用来存储大量小文件的。
hdfs不能有效地访问小文件：它主要是为大文件的流式访问而设计的。读取小文件通常会导致大量的查找和从datanode到datanode的大量跳跃来检索每个小文件，所有这些都是一种低效的数据访问模式。
hdfs中的每个文件、目录和块都表示为namenode内存中的一个对象，每个对象占用150字节。块大小为64 mb。因此，即使文件是10kb，它也会被分配一个64MB的整个块。那是浪费磁盘空间。
如果文件非常小并且有很多，那么每个map任务处理的输入非常少，并且有更多的map任务，每个map任务都会带来额外的簿记开销。将一个1gb的文件分为16个64mb块的文件和10000个左右100kb的文件进行比较。10000个文件每个使用一个Map，作业时间可能比使用单个输入文件的等效文件慢几十倍或几百倍。
在“hadoop summit 2011”中，karthik ranganathan谈到了facebook的消息传递，他在其中透露了一点：facebook通过HDF存储数据（个人资料、消息等），但它们不使用相同的infra来处理图像和视频。他们有自己的图像处理系统haystack。它不是开源的，但是他们分享了抽象设计层的细节。
这让我想到了weed fs：一个以haystacks的设计为灵感的开源项目。它是为存储文件量身定做的。我到现在还没用过，但似乎值得一试。
hjzp0vay3#
如果您能够批处理文件，并且在添加到hdfs后不需要更新批处理，那么您可以将多个小文件编译成一个较大的二进制序列文件。这是在hdfs中存储小文件的一种更有效的方法（正如arnon在上面指出的，hdfs是为大文件设计的，在处理小文件时效率非常低）。
这是我在使用hadoop处理ct图像时采用的方法（hadoop中的图像处理细节）。在这里，225个ct扫描切片（每个都是一个单独的图像）被编译成一个更大的二进制序列文件，用于长时间流式读取到hadoop中进行处理。
希望这有帮助！
克
vlju58qv4#
我是《野草》的作者。对于您的要求，weedfs是理想的。hadoop不能处理很多小文件，除了你的原因，每个文件都需要有一个主条目。如果文件数量很大，hdfs主节点就无法扩展。
当使用最新的golang版本进行编译时，weed fs的速度越来越快。
最近对除草机进行了许多新的改进。现在你可以测试和比较非常容易与内置上传工具。这一个在一个目录下递归地上传所有文件。
现在您可以通过“du-k/some/directory”查看磁盘使用情况，通过“ls-l/your/weed/volume/directory”查看weed fs磁盘使用情况。
我想你需要数据中心的复制，机架感知等，他们现在在！