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

[Tianpu]

数据量约10亿 单个文件大小平均在16k 总数据量在16T左右 计划是每台机器挂2个3T的硬盘做RAID1 然后6台这样的机器就可以了

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

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

还有别的推荐的吗？

[linlinqi]

GridFS, MongoDB的旁支 http://www.mongodb.org/display/DOCS/GridFS

[likuku]

还有个fastDFS，C写，国内开发，维护活跃

[manhere]

难道是做地图？

[sinreal]

豆瓣的beandb http://code.google.com/p/beansdb/

[muxi]

海量小文件估算体积容量是没有太多意义的，海量小文件主要的瓶颈在文件查找上和对文件树的维护上，其实Linux自带的文件系统XFS在这个量级也是可以用的

TFS经过特别的优化，但是不是谁都能玩得转，没有太多的文档支持
mogilefs我弄过，如果光存储可以的，如果读取比较频繁，最后的瓶颈在MySQL上
fastDFS 是完全分布式的，没有集中的点，我个人更喜欢，在这个量级上应该没问题

[feiandxs]

beansdb~
。。。好物

[notedit]

告诉你一个灰常简单的方法，10亿个文件每一个给一个自增的id，然后把id转为六位的36进制(不足六位的前面补零)，然后可以根据六位的字串分三级目录，这样一共可以存 36*36 的三次方的文件也就是21亿多个文件， 三层目录查找起来很快。

少于20亿的文件根本不需要那些开源的复杂的技术

[lfeng]

mogilefs小文件性能不佳吧。。。。MySQL的压力也是个问题

[lfeng]

@notedit 存储不是问题，问题在于小文件读写IO瓶颈

[Tianpu]

@notedit 原先一直是这么干的 不过文件量只到了数千万 字符串什么的分配的也比较均衡了 如果用数字ID则可以做的更加均衡

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

关注的方面主要是随机读 小文件比较大的压力看了好多说是硬盘寻道那部分 主要是文件小 碎 随机读写的问题了 或者说就是和淘宝一样的应用需求 只不过没他那么大

[likuku]

@lfeng mogilefs有单点故障危险，另外存储元数据是用mysql...这个也会是瓶颈。

@muxi xfs我也用，处理大文件很快。但巨量小文件，小目录，还是reiserfs很快。电力有保证，别轻易断电的情况下，reiserfs没啥问题。

[likuku]

btrfs效能很糟糕，这个就不建议测了。

[lfeng]

@sinreal 看了一下beansdb，底层存储采用的Bitcask，如果能换成Google的leveldb就好了。。。不过按照LZ的需求，beansdb应该也够用了，这里有人实际接触过么？

[Tianpu]

最终我使用fastdfs作为主要测试对象 顺利的部署上了

一共部署了三台

tracker一台
t1.domain.com

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

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

我严肃的向各位推荐，我还会有进一步的测试，主要是同组内备份、恢复，以及存储服务器灾难自动切换，扩容等，测试结果我会进一步反馈

[lyxint]

@Tianpu 结果如何? 分享分享?

[Tianpu]

@lyxint 还没有大规模部署 测试的话各种方便和好 这个方案就是部署比较简单些 其实和建三级目录差不多吧

[lyxint]

@Tianpu 和三级目录区别很大吧, 三级目录有单点故障. fastdfs里面有分组, 相当于mongodb的shards

[Tianpu]

@lyxint 是的 可以存储多份 如果已经做raid1 就差不多嘛 部署上没难度 看着大致去中心化了 应该不存在太大的系统瓶颈 我的图片规模不大 最多7.5亿 应该足够了

[kernel1983]

文件无需做修改的话, 可以数据库索引文件名, 偏移量, 文件长度, 然后所有的图片文件内容写在一个文件里

[mingxing]

海量小文件存储，如果是静态文件的话，可以考虑测试一下咱们又拍云存储~
我们这个是基于静态文件的海量存储+CDN服务~