General
我一直坚持这个观点：对于互联网应用，用通用文件系统，如mooseFS，clusterFS等，太废纸，也就是性价比不高。
互联网应用使用专用文件系统，更合适一些。
大文件分块这个特性，也是看你的应用场合的。比如HDFS，它的定位就是分布式计算，因此HDFS支持文件分块，是天经地义、顺理成章的事情。
如果你最大的文件也就100多MB，采用文件分块特性，就是自寻烦恼。
总结为一句话：只选择合适的系统。用个医学上的术语：对症下猛药！
|
| 40大小的文件 | 4k 大小的文件 | 40k大小的文件 |
| glusterfs | 3.9kb/s(97unit/s) | 205kb/s(50unit/s) | 1.5Mb/s(37unit/s) |
| nfs | 24kb/s(611unit/s) | 2.4Mb/s(583unit/s) | 16Mb/s(403unit/s) |
| moosefs | 14kb/s(345unit/s) | 1.3Mb/s(321unit/s) | 11Mb/s(262unit/s) |
1 FastDFS
简单，好用。
适合存储小文件。
无法自动均衡服务器的负载。例如，新增加机器后，其它机器的已有负载无法自动均衡到新机器上。
linux_shell
余大的 fdfs存储小图片非常适合，性能也非常不错。之前我公司业务主要做搜索引擎和爬虫图片搜索，日采集入库图片5千万张+都是用的余大的FastDFS，相当赞，比mfs glusterfs架构模式确实好很多。话说fdfs 在V4版本如果支持大文件存储的话，就更赞了，哈哈
大文件存储优化，主流做法就是分块存储吧，比如对大文件按64MB分块存储。
FastDFS本身是不需要文件索引的，可以根据文件ID直接定位到文件系统中的文件。
要对大文件分块存储，就会保存文件索引信息，势必对FastDFS架构造成非常大的调整。
因此FastDFS近期不考虑对大文件进行特殊支持。
fastDFS的部署非常的方便，而且日后的扩容 也简单，就是增加组而已
评论：
（1） 优点
简单易用，性能好。
无中心节点。
淘宝余庆开发。
（2）缺点
适宜小文件
新增节点（group）后，老数据无法均衡到新节点。
2 GlusterFS
yuhongchun
与Hadoop HDFS不同的是：GlusterFS使用了弹性哈希算法来定位文件存储的位置。 由于使用了弹性哈希算法，GlusterFS不需要专门的Meta-Data Server来保存元数据，因此可以避免因为元数据服务器宕机导致的整个集群不可用。也正是因为不需要元数据服务器，所以GlusterFS在多个挂载点同时进行数据读写的时候，其整体性能很突出。
这个优势也是MooseFS不具备的。
king_819
GlusterFS在处理大量小文件上优势不大，由于没有元数据服务器，因此增加了客户端的负载，占用相当的CPU和内存。（这能占多少cpu和内存？）
在遍历文件目录时，则实现较为复杂和低效，需要搜索所有的存储节点，因此不建议使用较深的路径。（如果只是读写文件，就没有这个问题吧。）
glusterfs 我们在一个节点上测试过，DELL r610 的，近200T 容量。小文件（16k以内）写在3.5M左右，读10M左右。300M 400M 500M 800M 1G 这种大文件做stripe模式的话读在270M 左右， replicate 模式在117M 左右。最后我们先上使用的是distributed+replicated分布式模式。主要存储视频大文件。ps ：gfs对网络要求很高，测试时网通机房的内网貌似不稳定socket通讯经常失败，导致多次重联。建议内网全部千兆线（至少H3C 交换机）。非常不适合web文件和小文件存储，当然你pv不高就几百万，淘汰nfs还是可行的。
不是说了么，小文件在3.5M/S 大文件问读都是 100多M/S。 写在50-70之间。 GFS越大越无压力，哈哈。 不适合做图片小文件存储
你想读在200多M/S的话 只能是单sprite模式，也就是类似“raid0” ，这样数据是没有冗余的，自己权衡吧。
glusterfs不适合做小文件存储，楼主可以找单个几百兆的文件测试一下，文件越大性能越好。
glusterfs可以设置多种数据存储模式的，除非你是默认的hash方式挂了才会丢数据的。
不止一次的有人说到这个问题，其实每个分布式文件系统都有一方面的特性。比如FastDFS 的产生就是配合小文件，图片存储的。
glusterfs适合大文件存储，其实学习的时候看下官方文档写的清清楚楚。这个只能说明你对每款软件的特性了解的不清楚。
T-Bagwell
比较赞同余总的说法
不过glusterfs其实还是有很多优势的
统一空间，内容统一管理，就像使用本地磁盘一样方便，大大节省了应用开发的时间
降低了应用部分的难度
至于说glusterfs不支持小文，其实可以考虑组合使用，还是不错的
比如大文件存储在gluster里，小文件单做一个其他的小文件系统有优势的文件系统上面，这样的话就会方便很多
扩容方面，glusterfs目前还不是很帅，做起来比较龌龊，尤其是在reblance的时候，非常耗时
如果用infiniband网也许好些，用tcp就太逊色了，如果每个节点上再搞个客户端，非常蛋疼，网络流量对穿导致整个内部流量非常大，大到想死
目前gluserfs还在进一步的开发中，还有很多比较有建设性的东西的
glusterfs的开发非常方便，加一个自己的模块也很方便，都是xlator管理的，挺爽的
而且都是posix接口，就像正常使用本地pc一样使用就可以了
只不过有些操作太耗时了，比如readdir
如果应用场景不复杂的话，可以考虑
如果能够自己改一下内部实现的话，应该会好更多
读，写有的时候会抢流量， 可以考虑做读写分离
glusterfs本身性能并不高，只做存储还是可以的，如果存web,估计需要自己搞个webcache
视频存储的话，够用了
glusterfs有一点处理的不好
就是节点端拔网线以后，处理会延时，延时很长时间
我们一直还是glusterfs， 一个是可以方便的进行mount，然后是容错机制比较好
3 MooseFS
king_819
MooseFS的master server 很耗内存，而且还存在单点故障，虽然有DRBD的解决方案
shine_forever：
MooseFS似乎只能存小文件，大文件存储读取十分有问题！！！
yuhongchun
我也准备在下一个项目中使用MooseFS，毕竟它还有元数据日志服务器
moosefs 的IO很让我蛋疼，加入新的存储节点会自动将文件复制到新节点，操作还可以，可以直接mfsmount，
不想fastdfs那样需要api，还有文件名可以放进去，
而fastdfs则返回一个经过计算后的文件名，这样迁移文件不太好用，不过fastdfs 的效率远非moosefs可以比，
现在用fastdfs来做web存储，moosefs 来做日志和文件备份
nfs现在也在用，只不过不是用在核心上，网络有故障，会带上CPU，load的飙升，
评论：
优点
（1）安装配置很方便。
系统本身安装配置很方便。
客户端更方便，mfsmount上之后，就跟本地文件一样了。
（2）横向动态扩展
（3）master没有单点问题
（4）提供监控系统
缺点
（1）master性能瓶颈
这个跟HDFS是类似的。
（2）
4 NFS
king_819
NFS的缺点：
1. 可扩展性差，难以应用于大量存储节点和客户端的集群式（cluster）系统；
2. 文件服务器的定位（location）对客户端非透明，维护困难；
3. 缓存管理机制采用定期刷新机制，可能会发生文件不一致性问题；
4. 不支持数据复制，负载均衡等分布式文件系统的高级特性，很容易出现系统的性能瓶颈；
5. NFS服务器的更换会迫使系统暂停服务
6. 对于异地服务的支持能力不强
总之，NFS太老了，对于追求海量数据吞吐量、存在成千上万个客户端和存储节点的互联网应用来说已经力不从心了，只适合小范围的应用了。
小系统还是考虑ngnix/squid吧。安装简单，有缓存。
NFS的好处就是方便，可以fopen, 但是消耗太大了。不适合劣质网络。
yuhongchun
NFS也有其好处，但对网络的依赖性太大了，上次因为网络故障，这边的Web服务器负载就一直上到300+!!
nfs能不用就尽量不要用！，因为要涉及到网络，网络出问题，就完蛋，另外速度问题也应该是考虑进去的
本地没有磁盘空间，只好用NFS挂载别的机器的磁盘分区了，我觉得这只是权宜之计。
5 mogileFS
yuhongchun
perl熟练的话，这个也非常好用
hadoop部署中，目前MFS。主要储存图片、视频。感觉MFS还不出，元数据服务器主备结合，读写都很快。单台28T。4台存储服务器，hadoop玩不转啊。。。
文件缓存
chenyx
分布式文件系统暂时还么有用到,个人倾向于是用Nginx/Varnish作为文件缓存来缓解文件服务器的压力.
yuhongchun
NFS(DRBD双机)+ varnish/Nginx 缓存 ， 一般来说，中型企业够用了，架构设计得好，也可以尝试用于大型网站
前端用nginx做调度，缓存，后端做memory cache，做动静分离，使用NFS共享数据，也是个不错的选择啊
665
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
