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