各种资料已经很多了,各自也都有一些用户群。架构设计的什么的就不提了。主要从用户体验上来对比一下:

  1. 安装配置
    TFS体验不如FastDFS
    TFS稍显复杂,尤其是在稍微高版本gcc下就编译通不过,如centos 6下(需要稍微修改下源码)。对于一个大公司的产品实在是丢人。TFS nginx模块代码快2年没有更新,在稍微高点的nginx版本下编译报错(如nginx1.6),同样,丢人。
    FastDFS在新版本编译没有任何问题,包括gcc 4.8.2下,已在centos 7.0测试正常。
  2. 客户端API
    二者基本相当。都提供了比较多的客户端。
    TFS nginx模块提供REST API使用更方便。
    而FastDFS nginx模块写的比较简单,只支持http下载(get),上传需要用相应客户端。
  3. 资源消耗
    TFS比FastDFS多。
    TFS nameserver启动后,CPU使用率在35%左右(1core),居高不下,且启动时需要很多数百M内存,否则启动不起来;启动后内存占用降低,但CPU占用太高。
    FastDFS tracker需要资源很少,storage启动时候需要分配64M内存(内存占用大小可以设置max_connections*buff_size),启动后保持。
  4. fileId
    FastDFS 的fileID:组名(可选)+磁盘+二级目录+文件名
    如xxx.com/M00/00/00/aIOW-1RWQyuAfSjjAAvWFkcZHjA219_big.jpg
    TFS的fileID: v1/tfs/文件名。
    如xxx.com/v1/tfs/T11yDTByJT1RCvBVdK.PNG
    TFS的更简洁。

FastDFS的思路是给NameNode减压。减压方法是将NameNode的信息编码到key中。对于范例URL:group1/M00/00/00/rBAXr1AJGF_3rCZAAAAEc45MdM850_big.txt来说,NameNode只需要做一件事,将group1翻译成具体的机器名字,不用关心key的位置,只要关心组的信息所在的位置。

FastDFS的优点

1.结构简单,元数据节点压力低。

2.扩容简单,扩容后无需重新平衡。

FastDFS的缺点

1.不能自定义key,这对多租户是致命的打击,自己使用也会降低灵活性。除非自己维护映射关系。

2.修复速度:磁盘镜像分布,修复速度取决于磁盘写入速度,比如4TB的盘,100MB/s的写入速度,至少需要11个小时。

3.大文件冲击问题没有解决。首先,文件大小有限制(不能超过磁盘大小);其次,大文件没有分片,导致大文件的读写都由单块盘承担,所以对磁盘的网络冲击很大。
总结:
从功能讲TFS功能更多,角色更多,也更复杂,但在体验上还有不少进步空间。FastDFS则是轻便,但功能简单。
另外从开源推广及支持、社区活跃度方面,TFS不太活跃,代码放github上面一两年不更新,基本不投入,开源远远不仅仅是开放源码,要投入很大精力去与用户及社区交互。


ccj 于 13 天前 修改
2 回复
higkoo
#1 higkoo • 2015-06-10 18:03

讲得很中肯,还有其它存储类比的文章不?

ccj
#2 ccj • 2015-06-11 16:21

@higkoo 欢迎补充嘛,测试一下才有体会。

需要 登录 后方可回复, 如果你还没有账号你可以 注册 一个帐号。