V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX 提问指南
Tianpu
V2EX  ›  问与答

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

  •  
  •   Tianpu · 2012-05-09 19:50:18 +08:00 · 15691 次点击
    这是一个创建于 4566 天前的主题,其中的信息可能已经有所发展或是发生改变。
    数据量约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   ·   实用小工具   ·   2861 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 23ms · UTC 02:24 · PVG 10:24 · LAX 18:24 · JFK 21:24
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.