分享

hdfs上传、下载小文件速度的问题

leo_1989 发表于 2013-10-25 10:42:33 [显示全部楼层] 回帖奖励 阅读模式 关闭右栏 9 21254
测试环境:1个namenode+2个datanode,百兆网络(上限12M左右)
测试文件 1520张照片(每张不到1M,共1.01G)
在相同时间段内测试上传、下载多次,上传花费126秒,下载花费264秒,下载速度居然低于上传速度吗?
哪位大侠能分析下原因啊吗?多谢!

已有(9)人评论

跳转到指定楼层
yunjisuanxue 发表于 2013-10-25 10:42:33
LZ用的什么方式上传,API还是吗?
回复

使用道具 举报

when30 发表于 2013-10-25 10:42:33
调API
反复测试发现:
1、单次上传、下载,下载速度慢于上传速度
2、跑10个线程(每个都是先上传后下载),下载速度快于上传速度
3、下载同一内容多次,后面几次比第一次快,难道有缓存机制吗?
以上现象是否跟寻址时间大于读写时间有关吗?
回复

使用道具 举报

cryst2l 发表于 2013-10-25 10:42:33
为什么要用hdfs存小文件吗?
回复

使用道具 举报

bob007 发表于 2013-10-25 10:42:33
请问一下hdfs上传、下载文件 你是通过什么实现的 jsp页面吗
回复

使用道具 举报

kaif22 发表于 2013-10-25 10:42:33
@js728824 HDFS不适合存储小文件,参见FastDFS TFS 等开源小对象分布式文件系统
回复

使用道具 举报

leo_1989 发表于 2013-10-25 10:42:33
回复 6# alexanderdai
HDFS是为什么不适合存储小文件,我知道对大量小文件进行处理的时候,最好将这些小文件先合并为一个大文件。这样有助于提高hadoop的处理效率。
回复

使用道具 举报

datong838 发表于 2013-10-25 10:42:33
回复 7# hipilee
  • 元数据结构复杂,存储小文见对元数据压力颇大。
  • 并发能力不行
  • 响应时效性较差
    小文件的应用要满足,实时性好延时低,文件数量庞大,并发能力强,所以HDFS并不适合存储小文件,除非你无所谓这些细节,并不注重工程质量。
    FastDFS、TFS、Haystack  很好的解决了这些,是特意真对小文件设计的分布式文件系统,包括百度、腾讯、网易都有没开源的类似系统。
  • 回复

    使用道具 举报

    yuanqingyu0123 发表于 2013-10-25 10:42:33
    回复 8# alexanderdai
    呵呵!谢谢解答!
    对于3点理由,第一点我觉得很好理解!2,3点不能很好的理解!并发是指mr在多节点的处理上不好并发吗?我觉得好像没关系啊!
    回复

    使用道具 举报

    shihailong123 发表于 2013-10-25 10:42:33
    你理解的2应该是吞吐率,我指的并发是指随机访问
    至于3这个系统设计的时候就没过多考虑延时,更多的是扩展性,用分布式的优势来拓展性能,局部优化不够
    回复

    使用道具 举报

    您需要登录后才可以回帖 登录 | 立即注册

    本版积分规则

    关闭

    推荐上一条 /2 下一条