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

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 4579 天前的主题，其中的信息可能已经有所发展或是发生改变。

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

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

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

还有别的推荐的吗？

数据量

mogilefs

文件大小

21 条回复 • 1970-01-01 08:00:00 +08:00

linlinqi

2012-05-09 20:19:51 +08:00

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

likuku

2012-05-09 20:30:20 +08:00

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

manhere

2012-05-09 20:34:25 +08:00

难道是做地图？

sinreal

2012-05-09 21:19:58 +08:00

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

muxi

2012-05-09 21:33:54 +08:00

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

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

feiandxs

2012-05-09 21:42:16 +08:00

beansdb~
。。。好物

notedit

2012-05-09 22:23:09 +08:00

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

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

lfeng

2012-05-09 22:36:33 +08:00

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

lfeng

2012-05-09 22:38:07 +08:00

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

Tianpu

2012-05-09 23:53:23 +08:00

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

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

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

likuku

2012-05-10 10:34:32 +08:00

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

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

likuku

2012-05-10 10:35:11 +08:00

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

lfeng

2012-05-10 19:43:43 +08:00

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

Tianpu

2012-05-11 00:21:21 +08:00

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

一共部署了三台

tracker一台
t1.domain.com

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

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

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

lyxint

2012-06-12 20:21:23 +08:00

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

Tianpu

2012-06-12 21:50:39 +08:00

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

lyxint

2012-06-12 22:10:56 +08:00

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

Tianpu

2012-06-13 02:34:15 +08:00

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

kernel1983

2012-06-13 11:03:58 +08:00

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

mingxing

2012-06-13 11:43:08 +08:00

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

Tianpu

2012-06-13 18:10:16 +08:00

@mingxing 看了下成本还是偏高了一台渣滓服务器配几个大硬盘这就是我的预算哈