海量小文件存储有建议吗? - V2EX
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
Tianpu
V2EX    问与答

海量小文件存储有建议吗?

  •  
  •   Tianpu 2012-05-09 19:50:18 +08:00 16149 次点击
    这是一个创建于 4909 天前的主题,其中的信息可能已经有所发展或是发生改变。
    数据量约10亿 单个文件大小平均在16k 总数据量在16T左右 计划是每台机器挂2个3T的硬盘做RAID1 然后6台这样的机器就可以了

    比较中意的是tfs http://code.taobao.org/p/tfs/src/

    mogilefs口碑也不错 https://github.com/mogilefs/

    还有别的推荐的吗?
    21 条回复    1970-01-01 08:00:00 +08:00
    linlinqi
        1
    linlinqi  
       2012-05-09 20:19:51 +08:00   1
    likuku
        2
    likuku  
       2012-05-09 20:30:20 +08:00   1
    还有个fastDFS,C写,国内开发,维护活跃
    manhere
        3
    manhere  
       2012-05-09 20:34:25 +08:00
    难道是做地图?
    sinreal
        4
    sinreal  
       2012-05-09 21:19:58 +08:00   1
    muxi
        5
    muxi  
       2012-05-09 21:33:54 +08:00   2
    海量小文件估算体积容量是没有太多意义的,海量小文件主要的瓶颈在文件查找上和对文件树的维护上,其实Linux自带的文件系统XFS在这个量级也是可以用的

    TFS经过特别的优化,但是不是谁都能玩得转,没有太多的文档支持
    mogilefs我弄过,如果光存储可以的,如果读取比较频繁,最后的瓶颈在MySQL上
    fastDFS 是完全分布式的,没有集中的点,我个人更喜欢,在这个量级上应该没问题
    feiandxs
        6
    feiandxs  
       2012-05-09 21:42:16 +08:00
    beansdb~
    。。。好物
    notedit
        7
    notedit  
       2012-05-09 22:23:09 +08:00   2
    告诉你一个灰常简单的方法,10亿个文件每一个给一个自增的id,然后把id转为六位的36进制(不足六位的前面补零),然后可以根据六位的字串分三级目录,这样一共可以存 36*36 的三次方的文件也就是21亿多个文件, 三层目录查找起来很快。

    少于20亿的文件根本不需要那些开源的复杂的技术
    lfeng
        8
    lfeng  
       2012-05-09 22:36:33 +08:00   1
    mogilefs小文件性能不佳吧。。。。MySQL的压力也是个问题
    lfeng
        9
    lfeng  
       2012-05-09 22:38:07 +08:00   1
    @notedit 存储不是问题,问题在于小文件读写IO瓶颈
    Tianpu
        10
    Tianpu  
    OP
       2012-05-09 23:53:23 +08:00
    @notedit 原先一直是这么干的 不过文件量只到了数千万 字符串什么的分配的也比较均衡了 如果用数字ID则可以做的更加均衡

    现在有个新机会重头开始干 因此想测试下比较新的技术

    关注的方面主要是随机读 小文件比较大的压力看了好多说是硬盘寻道那部分 主要是文件小 碎 随机读写的问题了 或者说就是和淘宝一样的应用需求 只不过没他那么大
    likuku
        11
    likuku  
       2012-05-10 10:34:32 +08:00
    @lfeng mogilefs有单点故障危险,另外存储元数据是用mysql...这个也会是瓶颈。

    @muxi xfs我也用,处理大文件很快。但巨量小文件,小目录,还是reiserfs很快。电力有保证,别轻易断电的情况下,reiserfs没啥问题。
    likuku
        12
    likuku  
       2012-05-10 10:35:11 +08:00
    btrfs效能很糟糕,这个就不建议测了。
    lfeng
        13
    lfeng  
       2012-05-10 19:43:43 +08:00
    @sinreal 看了一下beansdb,底层存储采用的Bitcask,如果能换成Google的leveldb就好了。。。不过按照LZ的需求,beansdb应该也够用了,这里有人实际接触过么?
    Tianpu
        14
    Tianpu  
    OP
       2012-05-11 00:21:21 +08:00   1
    最终我使用fastdfs作为主要测试对象 顺利的部署上了

    一共部署了三台

    tracker一台
    t1.domain.com

    storage server两台
    s1.domain.com
    s2.domain.com

    各机器是独立的VPS,目前在linode测试,完全达到了预期

    我严肃的向各位推荐,我还会有进一步的测试,主要是同组内备份、恢复,以及存储服务器灾难自动切换,扩容等,测试结果我会进一步反馈
    lyxint
        15
    lyxint  
       2012-06-12 20:21:23 +08:00
    @Tianpu 结果如何? 分享分享?
    Tianpu
        16
    Tianpu  
    OP
       2012-06-12 21:50:39 +08:00   1
    @lyxint 还没有大规模部署 测试的话各种方便和好 这个方案就是部署比较简单些 其实和建三级目录差不多吧
    lyxint
        17
    lyxint  
       2012-06-12 22:10:56 +08:00
    @Tianpu 和三级目录区别很大吧, 三级目录有单点故障. fastdfs里面有分组, 相当于mongodb的shards
    Tianpu
        18
    Tianpu  
    OP
       2012-06-13 02:34:15 +08:00
    @lyxint 是的 可以存储多份 如果已经做raid1 就差不多嘛 部署上没难度 看着大致去中心化了 应该不存在太大的系统瓶颈 我的图片规模不大 最多7.5亿 应该足够了
    kernel1983
        19
    kernel1983  
       2012-06-13 11:03:58 +08:00
    文件无需做修改的话, 可以数据库索引文件名, 偏移量, 文件长度, 然后所有的图片文件内容写在一个文件里
    mingxing
        20
    mingxing  
       2012-06-13 11:43:08 +08:00   1
    海量小文件存储,如果是静态文件的话,可以考虑测试一下咱们又拍云存储~
    我们这个是基于静态文件的海量存储+CDN服务~
    Tianpu
        21
    Tianpu  
    OP
       2012-06-13 18:10:16 +08:00
    @mingxing 看了下 成本还是偏高了 一台渣滓服务器 配几个大硬盘 这就是我的预算 哈
    关于     帮助文档     自助推广系统     博客     API     FAQ     Solana     2645 人在线   最高记录 6679       Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 28ms UTC 12:20 PVG 20:20 LAX 05:20 JFK 08:20
    Do have faith in what you're doing.
    ubao msn snddm index pchome yahoo rakuten mypaper meadowduck bidyahoo youbao zxmzxm asda bnvcg cvbfg dfscv mmhjk xxddc yybgb zznbn ccubao uaitu acv GXCV ET GDG YH FG BCVB FJFH CBRE CBC GDG ET54 WRWR RWER WREW WRWER RWER SDG EW SF DSFSF fbbs ubao fhd dfg ewr dg df ewwr ewwr et ruyut utut dfg fgd gdfgt etg dfgt dfgd ert4 gd fgg wr 235 wer3 we vsdf sdf gdf ert xcv sdf rwer hfd dfg cvb rwf afb dfh jgh bmn lgh rty gfds cxv xcv xcs vdas fdf fgd cv sdf tert sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf shasha9178 shasha9178 shasha9178 shasha9178 shasha9178 liflif2 liflif2 liflif2 liflif2 liflif2 liblib3 liblib3 liblib3 liblib3 liblib3 zhazha444 zhazha444 zhazha444 zhazha444 zhazha444 dende5 dende denden denden2 denden21 fenfen9 fenf619 fen619 fenfe9 fe619 sdf sdf sdf sdf sdf zhazh90 zhazh0 zhaa50 zha90 zh590 zho zhoz zhozh zhozho zhozho2 lislis lls95 lili95 lils5 liss9 sdf0ty987 sdft876 sdft9876 sdf09876 sd0t9876 sdf0ty98 sdf0976 sdf0ty986 sdf0ty96 sdf0t76 sdf0876 df0ty98 sf0t876 sd0ty76 sdy76 sdf76 sdf0t76 sdf0ty9 sdf0ty98 sdf0ty987 sdf0ty98 sdf6676 sdf876 sd876 sd876 sdf6 sdf6 sdf9876 sdf0t sdf06 sdf0ty9776 sdf0ty9776 sdf0ty76 sdf8876 sdf0t sd6 sdf06 s688876 sd688 sdf86