1
linlinqi 2012-05-09 20:19:51 +08:00 1
GridFS, MongoDB的旁支 http://www.mongodb.org/display/DOCS/GridFS
|
2
likuku 2012-05-09 20:30:20 +08:00 1
还有个fastDFS,C写,国内开发,维护活跃
|
3
manhere 2012-05-09 20:34:25 +08:00
难道是做地图?
|
4
sinreal 2012-05-09 21:19:58 +08:00 1
豆瓣的beandb http://code.google.com/p/beansdb/
|
5
muxi 2012-05-09 21:33:54 +08:00 2
海量小文件估算体积容量是没有太多意义的,海量小文件主要的瓶颈在文件查找上和对文件树的维护上,其实Linux自带的文件系统XFS在这个量级也是可以用的
TFS经过特别的优化,但是不是谁都能玩得转,没有太多的文档支持 mogilefs我弄过,如果光存储可以的,如果读取比较频繁,最后的瓶颈在MySQL上 fastDFS 是完全分布式的,没有集中的点,我个人更喜欢,在这个量级上应该没问题 |
6
feiandxs 2012-05-09 21:42:16 +08:00
beansdb~
。。。好物 |
7
notedit 2012-05-09 22:23:09 +08:00 2
告诉你一个灰常简单的方法,10亿个文件每一个给一个自增的id,然后把id转为六位的36进制(不足六位的前面补零),然后可以根据六位的字串分三级目录,这样一共可以存 36*36 的三次方的文件也就是21亿多个文件, 三层目录查找起来很快。
少于20亿的文件根本不需要那些开源的复杂的技术 |
8
lfeng 2012-05-09 22:36:33 +08:00 1
mogilefs小文件性能不佳吧。。。。MySQL的压力也是个问题
|
10
Tianpu OP @notedit 原先一直是这么干的 不过文件量只到了数千万 字符串什么的分配的也比较均衡了 如果用数字ID则可以做的更加均衡
现在有个新机会重头开始干 因此想测试下比较新的技术 关注的方面主要是随机读 小文件比较大的压力看了好多说是硬盘寻道那部分 主要是文件小 碎 随机读写的问题了 或者说就是和淘宝一样的应用需求 只不过没他那么大 |
11
likuku 2012-05-10 10:34:32 +08:00
|
12
likuku 2012-05-10 10:35:11 +08:00
btrfs效能很糟糕,这个就不建议测了。
|
13
lfeng 2012-05-10 19:43:43 +08:00
@sinreal 看了一下beansdb,底层存储采用的Bitcask,如果能换成Google的leveldb就好了。。。不过按照LZ的需求,beansdb应该也够用了,这里有人实际接触过么?
|
14
Tianpu OP 最终我使用fastdfs作为主要测试对象 顺利的部署上了
一共部署了三台 tracker一台 t1.domain.com storage server两台 s1.domain.com s2.domain.com 各机器是独立的VPS,目前在linode测试,完全达到了预期 我严肃的向各位推荐,我还会有进一步的测试,主要是同组内备份、恢复,以及存储服务器灾难自动切换,扩容等,测试结果我会进一步反馈 |
18
Tianpu OP @lyxint 是的 可以存储多份 如果已经做raid1 就差不多嘛 部署上没难度 看着大致去中心化了 应该不存在太大的系统瓶颈 我的图片规模不大 最多7.5亿 应该足够了
|
19
kernel1983 2012-06-13 11:03:58 +08:00
文件无需做修改的话, 可以数据库索引文件名, 偏移量, 文件长度, 然后所有的图片文件内容写在一个文件里
|
20
mingxing 2012-06-13 11:43:08 +08:00 1
海量小文件存储,如果是静态文件的话,可以考虑测试一下咱们又拍云存储~
我们这个是基于静态文件的海量存储+CDN服务~ |