常见分布式系统数据分布解析
| 数据库 | 优点 | 缺点 | ||
| mongodb | ||||
| hdfs(hbase) |
借助hadoop这个生态系统得以比较稳定。另外还有一个优势就是他是用
java写的，这样一帮java程序员也可以号称自己在搞文件系统了,
1、大数据批量读写，吞吐量高； 2、一次写入，多次读取，顺序读写 |
实在太简单，太粗糙。甚至连搞个append接口都搞了老半天，到现在应该还不支持随机读写之类的文件系统最基本的功能,
1、交互式应用，低延迟很难满足； 2、不支持多用户并发写相同文件。 |
||
| mysql | ||||
| lustre |
Oracle公司的企业级产品，非常庞大，对内核和ext3深度依赖，
1、 开源 2、 支持POSIX 3、 文件被分割成若干的Chunk，每个chunk是一般为1MB－4MB |
|||
| moosefs | 支持FUSE，相对比较轻量级，对master服务器有单点依赖，用perl编写，性能相对较差，国内用的人比较多 | |||
| glusterfs | 支持FUSE，比mooseFS庞大 | |||
| Katta | ||||
| CEPH | 支持FUSE，客户端已经进入了linux-2.6.34内核，也就是说可以像ext3/rasierFS一样，选择ceph为文件系统。彻底的分布式，没有单点依赖，用C编写，性能较好。基于不成熟的btrfs，其本身也非常不成熟 | |||
| mogilefs | Key-Value型元文件系统，不支持FUSE，应用程序访问它时需要API，主要用在web领域处理海量小图片，效率相比mooseFS高很多 |
|
||
| fastdfs |
国人在mogileFS的基础上进行改进的key-value型文件系统，同样不支持FUSE，提供比mogileFS更好的性能,
1、 开源 2、 适合以文件为载体的在线服务 3、 FastDFS没有对文件做分块存储 4、 不需要二次开发即可直接使用 5、 比mogileFS更易维护和使用 6、 直接使用socket通信方式，相对于MogileFS的HTTP方式，效率更高。 |
|
||
| tfs | 开源，
|
1、小于1M的文件 2、TFS内部是没有任何数据的内存缓冲的 |
||
| Swift | 流行得益于openstack，它应该是目前最流行的对象存储系统，印象中有在生产环节跑到上百PB的case。但总感觉这玩意用python写的，有点粗糙，似乎就是一堆脚本的拼凑 | |||
| GridFS | ||||
SurFS |
||||
| GFS |
|
|||
系统整体对比
|
对比说明 /文件系统 |
TFS |
FastDFS |
MogileFS |
MooseFS |
GlusterFS |
Ceph |
|
开发语言 |
C++ |
C |
Perl |
C |
C |
C++ |
|
开源协议 |
GPL V2 |
GPL V3 |
GPL |
GPL V3 |
GPL V3 |
LGPL |
|
数据存储方式 |
块 |
文件/Trunk |
文件 |
块 |
文件/块 |
对象/文件/块 |
|
集群节点通信协议 |
私有协议（TCP） |
私有协议（TCP） |
HTTP |
私有协议（TCP） |
私有协议（TCP）/ RDAM(远程直接访问内存) |
私有协议（TCP） |
|
专用元数据存储点 |
占用NS |
无 |
占用DB |
占用MFS |
无 |
占用MDS |
|
在线扩容 |
支持 |
支持 |
支持 |
支持 |
支持 |
支持 |
|
冗余备份 |
支持 |
支持 |
- |
支持 |
支持 |
支持 |
|
单点故障 |
存在 |
不存在 |
存在 |
存在 |
不存在 |
存在 |
|
跨集群同步 |
支持 |
部分支持 |
- |
- |
支持 |
不适用 |
|
易用性 |
安装复杂，官方文档少 |
安装简单，社区相对活跃 |
- |
安装简单，官方文档多 |
安装简单，官方文档专业化 |
安装简单，官方文档专业化 |
|
适用场景 |
跨集群的小文件 |
单集群的中小文件 |
- |
单集群的大中文件 |
跨集群云存储 |
单集群的大中小文件 |
开源协议说明
GPL:不允许修改后和衍生的代码做为闭源的商业软件发布和销售，修改后该软件产品必须也采用GPL协议；
GPLV2：修改文本的整体就必须按照GPL流通，不仅该修改文本的源码必须向社 会公开，而且对于这种修改文本的流通不准许附加修改者自己作出的限制;
GPLV3：要求用户公布修改的源代码，还要求公布相关硬件;LGPL：更宽松的GPL
TFS
TFS（Taobao File System）是由淘宝开发的一个分布式文件系统，其内部经过特殊的优化处理，适用于海量的小文件存储，目前已经对外开源；
TFS采用自有的文件系统格式存储，因此需要专用的API接口去访问，目前官方提供的客户端版本有：C++/JAVA/PHP。
§ 特性
1）在TFS文件系统中，NameServer负责管理文件元数据，通过HA机制实现主备热切换，由于所有元数据都是在内存中，其处理效率非常高效，系统架构也非常简单，管理也很方便；
2）TFS的DataServer作为分部署数据存储节点，同时也具备负载均衡和冗余备份的功能，由于采用自有的文件系统，对小文件会采取合并策略，减少数据碎片，从而提升IO性能；
3）TFS将元数据信息（BlockID、FileID）直接映射至文件名中，这一设计大大降低了存储元数据的内存空间；
§ 优点
1）针对小文件量身定做，随机IO性能比较高；
2）支持在线扩容机制，增强系统的可扩展性；
3）实现了软RAID，增强系统的并发处理能力及数据容错恢复能力；
4）支持主备热倒换，提升系统的可用性；
5）支持主从集群部署，其中从集群主要提供读/备功能；
§ 缺点
1）TFS只对小文件做优化，不适合大文件的存储；
2）不支持POSIX通用接口访问，通用性较低；
3）不支持自定义目录结构，及文件权限控制；
4）通过API下载，存在单点的性能瓶颈；
5）官方文档非常少，学习成本高；
§ 应用场景
1）多集群部署的应用
2）存储后基本不做改动
3）海量小型文件
根据目前官方提供的材料，对单个集群节点，存储节点在1000台以内可以良好工作，如存储节点扩大可能会出现NameServer的性能瓶颈，目前淘宝线上部署容量已达到1800TB规模（2009年数据）
§ 安装及使用
· 安装指导
· TFS_配置使用
源代码路径：http://code.taobao.org/p/tfs/src/
参考
http://rdc.taobao.com/blog/cs/?p=128
http://elf8848.iteye.com/blog/1724423
http://baike.baidu.com/view/1030880.htm
http://blog.yunnotes.net/index.php/install_document_for_tfs/
FastDFS
FastDFS是国人开发的一款分布式文件系统，目前社区比较活跃。如上图所示系统中存在三种节点：Client、Tracker、Storage，在底层存储上通过逻辑的分组概念，使得通过在同组内配置多个Storage，从而实现软RAID10,提升并发IO的性能、简单负载均衡及数据的冗余备份；同时通过线性的添加新的逻辑存储组，从容实现存储容量的线性扩容。
文件下载上，除了支持通过API方式，目前还提供了apache和nginx的插件支持，同时也可以不使用对应的插件，直接以Web静态资源方式对外提供下载。
目前FastDFS(V4.x)代码量大概6w多行，内部的网络模型使用比较成熟的libevent三方库，具备高并发的处理能力。
§特性
1）在上述介绍中Tracker服务器是整个系统的核心枢纽，其完成了访问调度（负载均衡），监控管理Storage服务器，由此可见Tracker的作用至关重要，也就增加了系统的单点故障，为此FastDFS支持多个备用的Tracker，虽然实际测试发现备用Tracker运行不是非常完美，但还是能保证系统可用。
2）在文件同步上，只有同组的Storage才做同步，由文件所在的源Storage服务器push至其它Storage服务器，目前同步是采用Binlog方式实现，由于目前底层对同步后的文件不做正确性校验，因此这种同步方式仅适用单个集群点的局部内部网络，如果在公网上使用，肯定会出现损坏文件的情况，需要自行添加文件校验机制。
3）支持主从文件，非常适合存在关联关系的图片，在存储方式上，FastDFS在主从文件ID上做取巧，完成了关联关系的存储。
§优点
1）系统无需支持POSIX(可移植操作系统)，降低了系统的复杂度，处理效率更高
2）支持在线扩容机制，增强系统的可扩展性
3）实现了软RAID，增强系统的并发处理能力及数据容错恢复能力
4）支持主从文件，支持自定义扩展名
5）主备Tracker服务，增强系统的可用性
§缺点
1）不支持断点续传，对大文件将是噩梦（FastDFS不适合大文件存储）
2）不支持POSIX通用接口访问，通用性较低
3）对跨公网的文件同步，存在较大延迟，需要应用做相应的容错策略
4）同步机制不支持文件正确性校验，降低了系统的可用性
5）通过API下载，存在单点的性能瓶颈
§应用场景
1）单集群部署的应用
2）存储后基本不做改动
3）小中型文件根据
目前官方提供的材料，现有的使用FastDFS系统存储容量已经达到900T，物理机器已经达到100台（50个组）
源码路径：https://github.com/happyfish100/fastdfs
§参考
https://code.google.com/p/fastdfs/
http://bbs.chinaunix.net/forum-240-1.html
http://portal.ucweb.local/docz/spec/platform/datastore/fastdfs
MooseFS
MooseFS是一个高可用的故障容错分布式文件系统，它支持通过FUSE方式将文件挂载操作，同时其提供的web管理界面非常方便查看当前的文件存储状态。
§特性
1）从下图中我们可以看到MooseFS文件系统由四部分组成：Managing Server 、Data Server 、Metadata Backup Server 及Client
2）其中所有的元数据都是由Managing Server管理，为了提高整个系统的可用性，MetadataBackup Server记录文件元数据操作日志，用于数据的及时恢复
3）Data Server可以分布式部署，存储的数据是以块的方式分布至各存储节点的，因此提升了系统的整体性能，同时Data Server提供了冗余备份的能力，提升系统的可靠性
4）Client通过FUSE方式挂载，提供了类似POSIX的访问方式，从而降低了Client端的开发难度，增强系统的通用性
§元数据服务器（master）:负责各个数据存储服务器的管理，文件读写调度，文件空间回收以及恢复
§元数据日志服务器（metalogger）:负责备份master服务器的变化日志文件，以便于在master server出问题的时候接替其进行工作
§数据存储服务器（chunkserver）:数据实际存储的地方，由多个物理服务器组成，负责连接管理服务器，听从管理服务器调度，提供存储空间，并为客户提供数据传输；多节点拷贝;在数据存储目录，看不见实际的数据
§优点
1）部署安装非常简单，管理方便
2）支持在线扩容机制，增强系统的可扩展性
3）实现了软RAID，增强系统的 并发处理能力及数据容错恢复能力
4）数据恢复比较容易，增强系统的可用性5）有回收站功能，方便业务定制
§缺点
1）存在单点性能瓶颈及单点故障
2）MFS Master节点很消耗内存
3）对于小于64KB的文件，存储利用率较低
§应用场景
1）单集群部署的应用
2）中、大型文件
§参考
http://portal.ucweb.local/docz/spec/platform/datastore/moosefsh
http://sourceforge.net/projects/moosefs/?source=directory
GlusterFS
GlusterFS是Red Hat旗下的一款开源分布式文件系统，它具备高扩展、高可用及高性能等特性，由于其无元数据服务器的设计，使其真正实现了线性的扩展能力，使存储总容量可轻松达到PB级别，支持数千客户端并发访问；对跨集群，其强大的Geo-Replication可以实现集群间数据镜像，而且是支持链式复制，这非常适用于垮集群的应用场景
§特性
1）目前GlusterFS支持FUSE方式挂载，可以通过标准的NFS/SMB/CIFS协议像访问本体文件一样访问文件系统，同时其也支持HTTP/FTP/GlusterFS访问，同时最新版本支持接入Amazon的AWS系统
2）GlusterFS系统通过基于SSH的命令行管理界面，可以远程添加、删除存储节点，也可以监控当前存储节点的使用状态
3）GlusterFS支持集群节点中存储虚拟卷的扩容动态扩容；同时在分布式冗余模式下，具备自愈管理功能，在Geo冗余模式下，文件支持断点续传、异步传输及增量传送等特点
§优点
1）系统支持POSIX(可移植操作系统)，支持FUSE挂载通过多种协议访问，通用性比较高
2）支持在线扩容机制，增强系统的可扩展性
3）实现了软RAID，增强系统的 并发处理能力及数据容错恢复能力
4）强大的命令行管理，降低学习、部署成本
5）支持整个集群镜像拷贝，方便根据业务压力，增加集群节点
6）官方资料文档专业化，该文件系统由Red Hat企业级做维护，版本质量有保障
§缺点
1）通用性越强，其跨越的层次就越多，影响其IO处理效率
2）频繁读写下，会产生垃圾文件，占用磁盘空间
§应用场景
1）多集群部署的应用
2）中大型文件根据目前官方提供的材料，现有的使用GlusterFS系统存储容量可轻松达到PB
§术语：
brick：分配到卷上的文件系统块；
client：挂载卷，并对外提供服务；
server：实际文件存储的地方；
subvolume：被转换过的文件系统块；
volume：最终转换后的文件系统卷。
§参考
http://blog.****.net/liuben/article/details/6284551
Ceph
Ceph是一个可以按对象/块/文件方式存储的开源分布式文件系统，其设计之初，就将单点故障作为首先要解决的问题，因此该系统具备高可用性、高性能及可扩展等特点。该文件系统支持目前还处于试验阶段的高性能文件系统BTRFS(B-Tree文件系统)，同时支持按OSD方式存储，因此其性能是很卓越的， 因为该系统处于试商用阶段，需谨慎引入到生产环境
§特性
1）Ceph底层存储是基于RADOS（可靠的、自动的分布式对象存储），它提供了LIBRADOS/RADOSGW/RBD/CEPHFS方式访问底层的存储系统，如下图所示
2）通过FUSE，Ceph支持类似的POSIX访问方式；Ceph分布式系统中最关键的MDS节点是可以部署多台，无单点故障的问题，且处理性能大大提升
3）Ceph通过使用CRUSH算法动态完成文件inode number到object number的转换，从而避免再存储文件metadata信息，增强系统的灵活性
§优点
1）支持对象存储（OSD）集群，通过CRUSH算法，完成文件动态定位， 处理效率更高
2）支持通过FUSE方式挂载，降低客户端的开发成本，通用性高
3）支持分布式的MDS/MON，无单点故障
4）强大的容错处理和自愈能力5）支持在线扩容和冗余备份，增强系统的可靠性
§缺点
1）目前处于试验阶段，系统稳定性有待考究
§应用场景
1）全网分布式部署的应用
2）对实时性、可靠性要求比较高官方宣传，存储容量可轻松达到PB级别
源码路径：https://github.com/ceph/ceph
§参考
MogileFS
§开发语言：perl
§开源协议：GPL
§依赖数据库
§Trackers(控制中心):负责读写数据库，作为代理复制storage间同步的数据
§Database:存储源数据（默认mysql）
§Storage:文件存储
§除了API，可以通过与nginx集成，对外提供下载服务
源码路径：https://github.com/mogilefs
§参考
https://code.google.com/p/mogilefs/wiki/Start?tm=6
其它参考
http://blog.****.net/qiangweiloveforever/ariticle/details/7566779
http://weiruoyu.blog.51cto.com/951650/786607
http://m.blog.****.net/blog/junefsh/18079733
1 文档说明
研究分布式文件系统时间也不短了，接触过的文件系统也不少，花点时间用来总结总结。
接触过的文件系统有glusterfs、moosefs、lustre及hdfs等，其架构简单顺带解说一点，总体来说分为元数据中心式及去中心式。其实除了glusterfs，其他的都是元数据中心式的分布式文件系统。
对于文件系统的架构只进行简单的解说，现在主要对以上各种文件系统的数据分布方式进行总结分析，顺便从其数据分布方式中分析其性能，可用性，适用性等等。
2 典型DFS及其数据分布
2.1 Lustre
2.1.1系统架构
Lustre是个人最早接触的一个分布式文件系统，其给我留下最深刻的映象就是“无与伦比”的快，其存储速度是我见过用过的分布式文件系统中最快的。
先来张Lustre文件系统的架构图：
图2.1.1 Lustre架构图
从架构图中，我们可以看出Lustre是典型的元数据中心式的分布式文件系统，其元数据服务器为MDS，用于存储文件的元数据信息，OSS服务器用于存储实际的文件数据。Lustre支持常规以太网，也支持快速的IB网络。
从结构上看，MDS支持active-standy支持主备切换，OSS也支持failover，但实际上MDS的主备配置及OSS的故障恢复远没有想象中的好用。其主备配置也好，failover也好只是支持服务器级别的切换，其底层真正用于存储对象结构MDT及OST是不支持主备及故障恢复的。一般底层对象存储会采用共享存储的方式来支持MDS的active-standy、OSS的failover。但是这种配置不但会影响性能，配置起来复杂，安全性也没有想象中高，只要共享存储层出现故障，整个系统将无法正常使用。
2.1.2数据分布方式
Lustre支持两种数据分布方式，文件单个整体存储及文件分片(stripe)存储两种方式。
首先是文件整体存储，文件以单个文件的形式存储在OST中，不进行任何的数据分片、纠删码设置及checksum(校验)设置等操作，这是一种比较常见的数据分布方式。
Lustre还支持文件分片存储，也就是常说的stripe方式，很多DFS会提供这么一种数据分布方式。
Lustre支持目录级的Stripe存储，即可以通过设置指定某个子目录的Stripe相关设置，包括Stripe_count、Stripe_size、Stripe_ost。Stripe_size指定子目录下的文件分片大小；Stripe_count指定选择OST个数，即分片分布在多少个OST上；Stripe_ost指定起始存储OST位置，系统默认为-1,即由MDS根据剩余容量及负载选择初始OST，否则从指定的OST开始分片存储。
具体设置如下：
|
1
|
lfs setstripe -s Stripe_sizeM -c Stripe_count /mnt/SubDir
|
//Stripe_size必须为page_size的整数据倍X*64KB
//Stripe_count小于等于OST数
图2.1.2 Lustre Stripe数据分布示意图
如图示例：Lustre存储由6个OST提供对象存储空间。/mnt/SubDir1目录未进行Stripe处理，该目录下file1以文件的形式存储在单个OST中，例如存储在OST0中；/mnt/SubDir2目录设置Stripe_count=6，则如图所示，Stripe_size大小的数据分别在6个OST中分布，且按照数据顺序轮询合并；/mnt/SubDir3与SubDir2情形相似，Stripe_count=5。
2.1.3系统优缺点
Lustre可以设置具体子目录的Stripe参数，这种方式比较灵活，可以根据文件大小进行合适的Stripe目录设置。并且Stripe的数据分布方式比文件整体存储高效，无论是文件读还是写。
Lustre是基于内核级的分布式文件系统。其文件的读写性能在分布式文件系统是比较快的(目前个人使用过，测试过的DFS中是最快的，其他分布式文件系统拍马难及)。鉴于其性能及其强悍的扩展性，多数用于高性能计算中。高性能，这正是Lustre最大的亮点。
在某种角度上说，Lustre基本不提供数据的保护，无论是数据冗余保护，还是数据的纠删保护，还是数据校验保护等等；当然，同样，其元数据也存在单点问题。这是Lustre的一大弱点。
2.2 HDFS
2.2.1系统架构
HDFS，或者说Hadoop大家会了解多些。其实对于hadoop，个人了解的并不是很多，只是接触过一些相关的培训及进行过相关的了解使用，并不是特别的熟悉(正在一步一步的研究他呢)。所以，要是有不对的地方，欢迎大家指正。
先给大家上个架构图：
图2.2.1 HDFS架构图
相信很多人会很熟悉这张hdfs的架构图。如图所示，HDFS由两部分组成，一部分是负责元数据存储的Namenode，一部分是负责实际存储数据的Datanodes。Namenode是一个中心服务器，负责管理文件系统的名字空间、负责文件数据块的组织及处理客户端对数据的访问；而Datanode则是一般是一个节点一个，负责管理其所在节点的数据存储。
最新版本的HDFS会支持一个备用的Namenode，负责定时的备份Namenode上的持久化的元数据信息，但实际上HDFS依然存在单点问题(熟悉MFS架构的朋友会发现，这种架构方式与MFS是如此的相似，又是如此的没用)。
2.2.2数据分布方式
HDFS只支持数据分块的方式存储，默认的数据块大小为64MB。其与一般的Stripe存储方式不同(参考Lustre Stripe存储)，其会把文件分成一个个64MB大小的数据块，在Datanodes存储着一个个的64MB大小的数据块而不是数据块的集合。
HDFS支持文件存储时创建副本，用于保证数据的安全性。并且系统保证文件的数据块的副本块不会出现在同一个Datanode上，避免某个Datanode失效时，文件无法访问。并且HDFS可以支持多个副本。
如下图所示：
图2.2.2 HDFS数据分布图
副本数据块与原数据块不在同一个datanode中，这种方式保证了任何一个datanode失效，都有其他datanode上的副本数据块进行替换，从而保证了数据的安全性。
在HDFS的文件实际存储节点Datanodes中，数据块是以单独的文件块存在，而不是与Lustre那样将数据块轮询合并(对比Lustre数据分布图)。
HDFS在数据分布中，最特别的是其对数据的校验。在存储文件时，HDFS会为每一个64MB的数据块创建一个对应的checksum，用于文件访问时对数据块的校验。这在分布式文件系统中是很不常见的。
文件在HDFS中是以私有格式存储的，只能通过系统的API进行访问。
2.2.3系统优缺点
HDFS作为存储本身来说，没有多少存储优势。例如其系统本身并不支持标准的POSIX接口，文件需要以专门的数据操作API进行文件数据操作，这在通用存储中是很不方便的方式；在性能上，其存储并没有显著的优势，其为每一个数据块创建一个checksum，虽然在数据安全性上提高了，在某种程度上说会降低其存储效率；其元数据处理方式，即将元数据加载在内存中，这种方式可以说是优点，即提高了客户端与元数据及存储节点与元数据的交互效率，但是由于内存的扩充限制，这会导致其规模扩充受阻(这点与MFS又是极其相似)。所以就目前来说，很少人会将HDFS单纯用于存储的。
然而，就目前研究热度来说，hadooop绝对是首屈一指的。HDFS其优势在于以其为基础的一系列衍生架构，就是大家所说的hadoop生态环境，包括Nosql数据库系统HBase，Sql操作化的Hive，及数据仓库Pig等等。Hadoop在批处理上有着无与伦比的优势，所以，配合其衍生架构，大多数人将其用于数据挖掘数据分析等。
2.3 MooseFS
2.3.1系统架构
MFS主要由四部分组成，元数据服务器Master、元数据日志服务器Metalogger、数据存储服务器chunkservers、及挂载客户端client。
图2.3.1 MFS架构图
如图所示，其架构与一般的元数据中心化的分布式文件系统架构相似，多出来不同之处在于Metalogger即元数据日志服务器的增加(这是1.5.X版本之后添加的组件)。该部分组件用于定时备份Master上的元数据文件及Master使用期间产生的changelog文件。在元数据服务器当机的情况下，可以通过Metalogger上的元数据文件及changelog文件来恢复元数据，并且可以通过修复元数据及修改Metalogger的IP方式来替换当机的Master。
2.3.2数据分布方式
MFS支持两种数据分布方式，一种是常规的以文件为单位的存储；另一种就是分块存储。
MFS的分块存储与HDFS的分块相似，以64MB的数据块分别存储在不同的chunkserver中，并且不进行数据块再次合并存储。其实MFS与HDFS有很多相似的地方，之前所说的文件分块方式，其元数据在系统启动时置于内存的方式及添加日志服务器来备份元数据的方式等。但HDFS的数据是以私有格式存储，不支持POSIX标准协议的访问，这点是不同的，其次MFS的数据块不进行创建校验值(checksum)，这样做，降低了一定的数据安全性，但是提高了副本方式的存储效率。
图2.3.2 MFS数据分布图
如图所示，可以看出MFS的两种数据存储方式，此外，MFS还支持多数据副本，其副本的设置是是根据目录进行设置的，即设置目录内的文件为副本方式存储。以目录为单位，设置比较灵活。单文件存储方式的副本存储在另一个chunkserver中，而以数据块存储的方式，在保证副本块不在同一个chunkserver中，如此，则能保证chunkserver不会出现单点问题。
2.3.3系统优缺点
由于MFS机制中，在系统启动时会将元数据缓存在内存中，这种方式在某种程度上提高了chunkserver与master的交互效率，但是，同样，由于内存扩充的局限性，这会导致MFS的扩展容易出现限制。根据官方说法，8G的内存能够存储2500KW的文件元数据信息，这样的话，存储海量的小文件就很容易达到文件个数的限制，而不是chunkserver的容量限制。其实HDFS也会面临同样的问题，只是HDFS在元数据结构进行了优化，减少了单个文件的元数据SIZE。
此外，就目前版本的MFS，依然存在单点问题，虽然1.6版本之后添加了Metalogger组件，但是并不能很好的解决元数据的单点问题。实际上，系统至今仍然无法达到故障切换的目的，添加了日志服务器之后，只是在某些情况下出现故障后能够根据日志服务器进行元数据恢复。
在小规模存储上MFS还是比较有优势的，目前已经有不少公司在使用他进行相关的存储业务，或者在此基础上进行相关的二次开发。
2.4 GlusterFS
2.4.1系统架构
GlusterFS是个人研究时间最长一个分布式文件系统，总体来说对其还是比较熟悉，无论是从架构还是从他的一些系统机制来说。
GlusterFS架构相对于其他分布式文件系统是最简单的架构，如图所示，除去网络层、外挂Samba及NFS相关东西，就只剩下client及Storage Brick，其实真正的存储核心就是Storage Brick。
图2.4.1 GlusterFS架构图
GlusterFS的架构是去中心式架构，即没有元数据中心结构，也就意味着其没有存储元数据的结构，这正是其异于Lustre、HDFS及MooseFS的地方，这也是其架构的最大特色。
那么其究竟是如何完成文件数据读写定位的呢？这就是去中心式的分布式文件系统的特色，GlusterFS通过内部的hash算法实现文件的定位，通过这种方法代替元数据组件产生的作用。就目前来说，去中心式的分布式文件系统就个人所知，只有GlusterFS。
2.4.2数据分布方式
GlusterFS是一个比较全面的分布式文件系统，包括其数据的分布方式。GlusterFS支持三种数据分布，即其可以创建三种卷：分布式卷(Distributed)、条带卷(Stripe)及副本卷(Replicated)。
分布式卷(Distributed)，系统在存储文件时，根据文件路径及brick进行hash计算，根据计算结果决定其将存储于哪个brick之上，并且在brick中是以单个文件的形式而存在的。这种hash计算会做到尽可能的负载均衡。同样，在读取文件时，也会根据hash计算定位文件的位置。
条带卷(Stripe)，这种数据分布方式是大部分常见的分布式文件系统所支持的。GlusterFS的条带化数据分布与Lustre的条带化数据分布很相似。系统根据Stripe count进行轮询分块，并且在单个brick中再进行数据块合并。并且其Stripe size大小默认为128KB。
副本卷(Replicated)，文件在brick中会存储文件副本，并且副本数可以自由设置，但是会根据brick数进行相关的限制。系统还针对副本卷设计了文件自动修复机制，以保持副本文件的正确性。
GlusterFS是数据分布最灵活的分布式文件系统，以上三种数据分布方式可以任意的搭配使用。
图2.4.2-1 GlusterFS Distributed-Striped Volume
图2.4.2-2 GlusterFS Distributed-Replicated Volume
图2.4.2-3 GlusterFS Replicated-Striped Volume
如图2.4.2-1所示，底层一共两个server，每个server上做两个brick，供四个brick做成2x2的Distributed-Striped卷。File1/2是以分布式方式，即hash方式存储在不同的brick上；而从单个文件的角度看，如File1，其内部是通过Stripe的方式进行条带化存储的，其Stripe count为2，通过文件分块编号，可以看出其数据是Stripe之后再组合成两个文件存储在两个brick上。
如图2.4.2-2所示，同样是4个brick，做成2x2的Distributed-Replicated卷。File1/2分别以单个文件为单位hash存储在不同的brick上，并且保证每个文件都会一个副本文件在其brick之外，从而保证了数据的安全。
如图2.4.2-3所示，系统是2x2的Replicated-Striped卷。File在两个brick上Stripe切片存储，且在另外两个brick上保存了所有切片的对应副本。
在最新的GlusterFS3.3.X上，系统还是支持Distributed-Replicated-Stripe卷，即三种数据分布方式组成的系统卷，其数据具体分布方式由上面三个图就很容易推断出来了。GlusterFS其卷的数据分布设置与其brick数目有很大的关系。
就目前所知的情况，Stripe卷一般较少的人使用，其性能有待于提高，而最常使用的数据分布组合方式就是Distributed-Replicated。总体上说，GlusterFS提供了多种数据分布方式，并提供了灵活多变的组合方式，让我们在使用方便了许多。
2.4.3系统优缺点
GlusterFS最大的特点在于其无元数据的整体架构，但这只能说是他的一大特色，算不上其优点。据其官网上所说的无中心结构使其存储扩展近似线性，这也只是理论上的线性扩展，实际上GlusterFS的扩展性能比能达到70%-80%就很不错了。这可能会比其他分布式文件系统扩展性能损耗上好一点点(中心化的分布式文件系统随着存储节点的增加，并行量上升，元数据负载会越来越大，导致其性能会损耗很大)，但随之而来的问题是，文件遍历时的效率呈直线下降，特别是在存储了大批量文件时。由于其是无元数据结构，导致文件遍历需要遍历需要实际遍历整个系统卷，而不是如其他分布式文件系统那样直接从元数据服务器中获取。这是其一大缺点。
GlusterFS提供了比较多的功能，其多种卷的组合是一个，他还提供了文件修复机制、远程地域备份、在线扩容缩容、存储节点在线替换等等。此外，个人认为其最大的优点在于其具有一个完善的命令行管理接口，在众多分布式文件系统中，GlusterFS管理起来是最方便的，所有操作都可以通过命令行工具进行管理，而不是像很多文件系统那样通过修改配置文件进行操作等等。
3 总结
从数据基本分布方式来看，目前开源的总体就分为单个文件存储、副本或者是镜像文件存储、及数据分块存储。在数据分块存储中，有典型的条带化Stripe存储，如lustre及gluster的stripe存储方式，以及HDFS、MFS文件真正分块(chunk)存储的方式。
分块存储在大多数情况下并不能提升文件写效率，当然这也和系统机制有关，如lustre的stripe存储就比文件单独存储的方式效率要高，但其他的分布式文件系统没有如此明显的差异，glusterfs的stripe存储效率还极其的低，很少人会使用它。但分块存储在读效率上会有明显的提升，特别是针对大文件读时。
副本存储或者镜像存储的数据存储方式是一种比较普遍的数据安全保证的数据分布。实现起来也比较容易。还有一种提供数据保护的数据分布方式就是纠删码。目前在开源分布式文件系统中好像没有看到有人将其实现，但在一些商业分布式文件系统中能看到它的身影，其实现难度也比副本存储的难度大。一些国内的分布式文件系统研发公司将其作为开源分布式文件系统二次开发目标。这种数据存储方式类似于RAID5，不仅能够提供数据保护，还节约了硬件成本。
在技术群中不少人都会问一个相类似的问题“大家认为哪个开源分布式文件系统最好？”其实这个问题是很难回答的。就目前这些开源的文件系统中，各有各的特色，但同样他们都存在一定缺陷或者说是不足之处。哪怕是商业分布式文件系统，同样也会存在这个问题。没有最好，只有最合适！
如果你追求的高效，并且在一定程度上可以容忍少量数据的丢失，那么lustre将会是你的不二选择，至于数据的安全性，你可以使用第三方的软件或者系统来实现，或者说直接就忽略之；如果你的业务需求是做数据挖掘数据分析，那么不用多想了，没有人不选择HDFS而去选择其他的；如果你想使用起来功能比较完善，并且管理起来比较方便，那么GlusterFS会是不错的选择；如果你想使用它来存储小文件，好吧，以上那些除了MFS适合一点点(不少公司使用MFS进行小规模存储小文件)，其他的也都是扯犊子的；当然，如果确实需要存储海量小文件，也是有专门为小文件设计的开源分布式文件系统，例如国人开发的FastDFS、MogileFS以及淘宝开源的TFS，只是对于这些分布式文件系统个人就不是很熟悉了，也只是知道个大概而已。