各种分布式文件系统的比较

1，MooseFS

支持FUSE相对较轻，它对主服务器有单点依赖，是用perl编写的，并且性能相对较差. 中国有更多的人，这些人易于使用，稳定并且对小文件非常有效. +支持文件元信息+ mfsmount易于使用+较少的编译依赖关系，完整的文档，默认配置良好+ mfshdd.cfg加*项目将被转移到其他块服务器，以便块服务器安全退出+没有块服务器是必需的文件系统格式和容量必须一致+开发非常活跃+可以以非root用户身份运行+可以扩展+支持回收站+支持快照-主服务器有单点故障-主服务器消耗内存，测试性能还不错. 吞吐量高于15MB /秒

2. MogileFSKey-Value类型图元文件系统不支持FUSE. 应用程序需要API才能访问它. 它主要用于Web领域以处理大量的小图片. 效率远高于mooseFS. 很好. 不适合常规文件系统，适合存储小型静态只读文件. 例如，图片说这是最高的性能分布式文件存储系统，但这是由perl编写的代码，它提供了要使用的API. 构造相对更复杂，因为它需要安装很多依赖项. 第三方perl软件包还需要安装MySQL来支持. 安装完成后，服务器启动，客户端由Java，PHP，PERL，RUBY等开发. 我需要的是支持FUSE，但是此分布式文件系统对FUSE的支持需要安装PERL和C通讯模块，该模块最终无法编译，最终无法成功测试，只能有时间继续学习.

3. GlusterFS支持大于MooseFS的FUSE，并认为广告比产品本身更好. +没有单点故障问题+支持回收站+模块化堆叠体系结构-要求文件系统格式，正式支持ext3 / ext4 / zfs，可能会xfs / jfs，可以测试reiserfs-需要以root用户身份运行（使用受信任的xattr，在挂载时添加user_xattr选项是没有用的，官方说法是glusterfsd需要创建不同所有者的文件，因此需要root权限）-无法扩展（添加没有umount的存储节点），计划在3.1实现分布式存储基于文件. 条带化分布式存储还不成熟. Glusterfs在Internet上很好. 它稳定且适合应用. 关键是没有单点故障依赖关系. C语言代码支持FUSE，因此请下载并安装研究报告. 安装和配置非常简单，并且在启动后执行测试. 它开始感觉真的很酷. 后来，使用压力测试工具对吞吐量进行了测试，结果发现性能无法满足我们的生产需求，而且我不知道配置问题在哪里. 我们测试了大文件读取操作和大文件写入操作，吞吐量为5MB /安全地，显然无法满足要求. 但是没有发现具体的瓶颈. 毕竟，该程序是由其他人编写的. 检查瓶颈并不容易. 有关glusterfs的详细信息，您可以阅读此兄弟的文章，他对此进行了深入的研究.

4，GFS2http: //www.smop.co.uk/blog/index.php/2008/02/11/gfs-goodgrief-wheres-the-documentation-file-system/http: //longvnit.com / 博客 /？ p = 941（基于Red Hat RHEL5U2 GFS2 + ISCSI + XEN + Cluster的高可用性解决方案）（iscsi + clvm + gfs2 + xen + Cluster）不是分布式文件系统，而是共享磁盘群集文件系统，需要某种机制以便在机器之间共享磁盘和锁定机制，因此需要drbd / iscsi / clvm / ddraid / gnbd进行磁盘共享，而dlm进行锁定管理）-取决于Red Hat Cluster Suite（Debian: aptitude install redhat -cluster-suite，graphic）配置工具包system-config-cluster，system-config-lvm）-适用于不超过约30个节点的小型集群，其大小越大，dlm的成本就越大，默认配置是8个节点<

5. 据说Oracle版本的OCFS2GFS比GFS2更好（Debian: aptitude install ocfs2-tools，图形配置工具包ocfs2console），不支持ACL和flock，仅用于Oracle设计

6. OpenAFS / Coda是一件非常独特的事情. +成熟稳定+积极开发，支持Unix / Linux / MacOS X / Windows-性能不够好

7，ceph支持FUSE，客户端已进入Linux-2.6.34内核，这意味着像ext3 / rasierFS一样，可以选择ceph作为文件系统. 完全分布式，没有单点依赖，用C编写，性能更好. 基于不成熟的btrfs，它也非常不成熟. 我搜索了一些信息，说ceph的性能最高，用C ++编写的代码支持Fuse，并且没有单点故障依赖关系，因此请下载并安装，因为ceph使用btrfs文件系统，而btrfs文件系统需要Linux 2.6.34及更高版本的内核才能支持. 显然，我使用的RHEL5内核尚不支持btrfs文件系统，因此我下载了最新的内核进行升级. 在两天没有成功升级之后，花费了一个多小时才完成编译，最后花了一个多小时才完成编译，最后发现最新版本的ubuntu系统支持btrfs文件系统，因此安装了ubuntu虚拟机，即btrfs文件系统已完成，但是启动ceph的相关过程错误，无法成功启动. 因此，不可能对其进行测试. CEPH使用更高级的算法，即Crush算法. 根据翻译，可伸缩的伪随机数据分发功能被设计用于基于对象的分布式存储系统. 它可以有效地管理数据对象和存储设备，而无需传递中央目录. 由于大型系统是动态的分布式文件存储系统，因此CRUSH旨在轻松添加或删除存储设备，同时最大程度地减少不必要的数据迁移. 该算法提供了各种不同类型的数据复制和可靠性机制，以及根据用户定义的策略分配数据. 此策略强制将数据复制与故障域分开. 另外，CEPH使用的文件系统是btrfs，它具有许多高级功能，并且是用于下一代Linux的文件系统. BTRFS最终可能会给ZFS等带来更多威胁. 它具有联机碎片整理功能（仅固态磁盘具有此功能），写时复制技术，数据压缩，镜像，数据条带化和快照等. 此外，BTRFS是在数据存储方面比ext更完整. 它包括一些逻辑卷管理和RAID硬件功能，可以检查内部元数据和用户数据，并且还嵌入了快照功能. ext4也可以实现上述某些功能，但是它需要与文件系统和逻辑卷管理器进行通信.

8. LustreOracle的企业级产品非常庞大，严重依赖于内核和ext3，它们复杂，高效且适用于大型集群. *适用于大型集群+极高的性能+支持动态扩展-需要修补内核，深度依赖Linux内核和ext3文件系统，甚至下载地址也已消失. . . .

9. PVFS2将与定制应用程序很好地配合. 据说Dawning的并行文件系统基于PVFS.

10. fastDFS: FUSE也不支持基于mogileFS的改进的键值文件系统，它提供的性能优于mogileFS. *高性能-无锁定机制，不符合POSIX语义，需要应用程序合作，并且不适合常规文件系统（请参阅pvfs2-guide第5章: PVFS2用户API和语义）-静态配置，无法动态扩展在网上说: “中文基于mogileFS的改进的键值文件系统还不支持FUSE，并且比mogileFS提供更好的性能. ”这不是胡说吗？ Mogilefs由perl撰写. 如果在mogilefs的基础上对fastDFS进行了改进，它也应该由perl编写. 但是下载fastDFS的代码后，每个人都是C代码. 在mogilefs的基础上如何加以改进？从fastDFS的特定结构来看，应该准确地说它应该“从MogileFS的思想中学习”，而不是“在MogileFS的基础上进行改进”.

我安装了它. 安装非常简单，不支持保险丝. 上传文件后，将生成一个http下载地址，并通过http下载. 这种方法显然不适合我想要的生产环境.

以下为网友撰写的FastFDS与MogileFS之间的比较文章. 感觉更客观和真实，因此我将在此处重新发布. FastDFS的设计借鉴了MogileFS的一些思想. FastDFS是一个完整的分布式文件存储系统，可通过客户端API读写文件. 可以说，MogileFS的所有功能都可以在MogileFS网站的FastDFS中找到. 另外，与MogileFS相比，FastDFS具有以下特征和优点: FastDFS具有高度的完善性，无需二次开发即可直接使用； b. 与MogileFS相比，FastDFS减少了跟踪，并且仅具有两个角色: 跟踪器和存储. FastDFS的体系结构不仅简化了系统，而且消除了性能瓶颈. C. 向系统添加任何角色服务器很容易: 添加跟踪服务器时，只需修改存储和客户端配置文件（添加一行跟踪器配置）；添加存储服务器时，通常无需修改任何配置文件，系统会自动将卷中的文件复制到服务器； d. FastDFS比MogileFS更有效率. 其性能如下: 1）参见上面的第2点. 与MogileFS相比，FastDFS没有文件索引，FastDFS的整体性能更高. 2）从使用的开发语言的角度来看，FastDFS比MogileFS Efficient更底层和更强大. FastDFS用C编写，代码量少于20,000行，并且它不依赖于其他开源软件或软件包. 安装和部署特别简单； MogileFS是用perl编写的； 3）FastDFS直接使用套接字通信，与MogileFS的HTTP相反，效率更高. 而FastDFS使用sendfile传输文件，采用零内存复制，系统开销较小，文件传输效率较高. e. FastDFS具有详细的设计和使用文档，但是相对缺乏MogileFS文档. F. FastDFS的日志记录非常详细. 系统操作期间发生的任何错误信息都将记录在日志文件中，以便管理员在出现问题时方便地查找错误. G. FastDFS还访问其他文件属性（即，元数据，例如文件大小，图片宽度，高度等），并且应用程序不需要使用来存储此信息. H. FastDFS仅支持V1.14中相同文件内容的一个副本，可以节省存储空间并提高文件访问性能.

11，Coda *将文件从服务器复制到本地，文件读写是本地操作，因此非常高效*将文件关闭后发送到服务器+支持脱机操作，并且连接后同步到服务器-缓存基于文件而不是基于数据块，打开文件时您需要等待服务器缓存完成-并发写入存在版本冲突-并发读取有很大的延迟，您需要等待客户端关闭文件，例如不适合tail -f some.log-研究项目，不够成熟，使用不广泛

12. Hadoop HDFS本地写缓存，当它具有一定大小（64 MB）时传递给服务器，不适合常规文件系统

13. FastDFS-只能通过API使用，不能融合

14. 我不了解旧的NFS网络文件系统. 无论如何，NFS近年来没有发展，并且绝对不可用.

15，dCache取决于PostgreSQL

16. xtreemfs *服务器是用Java实现的，性能不高

17. Hadoop使用CloudStore（KosmosFS）+作为分布式文件系统的后端之一-不支持文件元信息-kfs_fuse太慢且不可用-许多编译依赖项，落后的文档，不良的脚本，不活跃的开发

18，NFSv4引荐+简单无负载平衡，容错

19，NFSv4.1 pNFS-不受欢迎

20，spNFS * pNFS在Linux Ceph（）上的实现-初始开发，不稳定，取决于btrf

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-192824-1.html