minio 与其他（开源）分布式系统的异同点

关键信息总揽

文件系统	易用性	团队技术需求	存储利用率	推荐
MinIO	易	中	75%/87%	推荐
Ceph	中	高，尤其是初期	75%或87%或1/n	推荐
HDFS	难	中	1/n	不推荐
NFS+裸机	易	低	87%	推荐

整体对比

文件系统	开发者	开发语言	开源协议	易用性	适用场景	特性	缺点
MinIO	MinIO Inc	go	GNU AGPLv3	简单	混合云场景/裸机	云原生、有弹性、纠删码机制、加密、防篡改	存储利用率
GFS	Google		不开源	-	-	-	-
HDFS	Apache	Java	Apache	安装简单，官方文档专业化	存储非常大的文件	大数据批量读写，吞吐量高；一次写入，多次读取，顺序读写	难以满足毫秒级别的低延时数据访问；不支持多用户并发写相同文件；不适用于大量小文件
Ceph	加州大学圣克鲁兹分校Sage Weil	C++	LGPL	安装简单，官方文档专业化	单集群的大中小文件	分布式，没有单点依赖，用C编写，性能较好	基于不成熟的btrfs，自身也不够成熟稳定，不推荐在生产环境使用
TFS	Alibaba	C++	GPL V2	安装复杂，官方文档少	跨集群的小文件	针对小文件量身定做，随机IO性能比较高；实现了软RAID，增强系统的并发处理能力及数据容错恢复能力；支持主备热倒换，提升系统的可用性；支持主从集群部署，从集群主要提供读/备功能	不适合大文件的存储；不支持POSIX，通用性较低；不支持自定义目录结构与文件权限控制；通过API下载，存在单点的性能瓶颈；官方文档少，学习成本高
Lustre	SUN	C	GPL	复杂，而且严重依赖内核，需要重新编译内核	大文件读写	企业级产品，非常庞大，对内核和ext3深度依赖
MooseFS	Core Sp. z o.o.	C	GPL V3	安装简单，官方文档多，且提供Web界面的方式进行管理与监控	大量小文件读写	比较轻量级，用perl编写，国内用的人比较多	对master服务器有单点依赖，性能相对较差
MogileFS	Danga Interactive	Perl	GPL		主要用在web领域处理海量小图片	key-value型元文件系统；效率相比mooseFS高很多	不支持FUSE
FastDFS	国内开发者余庆	C	GPL V3	安装简单，社区相对活跃	单集群的中小文件	系统无需支持POSIX，降低了系统的复杂度，处理效率更高；实现了软RAID，增强系统的并发处理能力及数据容错恢复能力；支持主从文件，支持自定义扩展名；主备Tracker服务，增强系统的可用性	不支持断点续传，不适合大文件存储；不支持POSIX，通用性较低；对跨公网的文件同步，存在较大延迟，需要应用做相应的容错策略；同步机制不支持文件正确性校验；通过API下载，存在单点的性能瓶颈
GlusterFS	Z RESEARCH	C	GPL V3	安装简单，官方文档专业化	适合大文件，小文件性能还存在很大优化空间	无元数据服务器，堆栈式架构(基本功能模块可以进行堆栈式组合，实现强大功能)，具有线性横向扩展能力；比mooseFS庞大	由于没有元数据服务器，因此增加了客户端的负载，占用相当的CPU和内存；但遍历文件目录时，则实现较为复杂和低效，需要搜索所有的存储节点，不建议使用较深的路径
GridFS	MongoDB	C++		安装简单	通常用来处理大文件（超过16M）	可以访问部分文件，而不用向内存中加载全部文件，从而保持高性能；文件和元数据自动同步

选型参考

适合做通用文件系统的有：MinIO，Ceph，Lustre，MooseFS，GlusterFS；
适合做小文件存储的文件系统有：MinIO，Ceph，MooseFS，MogileFS，FastDFS，TFS；
适合做大文件存储的文件系统有：MinIO，HDFS，Ceph，Lustre，GlusterFS，GridFS；
轻量级文件系统有：MooseFS，FastDFS；
简单易用，用户数量活跃的文件系统有：MooseFS，MogileFS，FastDFS，GlusterFS；
支持FUSE挂载的文件系统有：HDFS，Ceph，Lustre，MooseFS，GlusterFS。

分布式实现方案

MinIO：纠删码机制
Ceph：RADOS，RADOS系统主要由两部分组成，分别是OSD和Monitor。
HDFS：master/slave架构，数据分块，添加副本

fs	CPU	memory	network	drives
MinIO	Dual Intel® Xeon® Scalable GoId CPUs (minimum 8 cores per socket).	128GB RAM	25GbE for high-density and 100GbE NICs for high-performance.	SATA/SAS HDDs for high-density and NVMe SSDs for high-performance (minimum of 8 drives per server).
HDFS-NameNode	2 个 4/8/16 核心处理器，主频至少为 2-2.5GHz	64 - 128G 内存	千兆网卡或万兆网卡	4-6块 1TB 硬盘（1块给操作系统，2块给FS image [RAID 1]，1块给Zookeeper , 一块给Journal Node）
HDFS-DataNode	2个 4/8/16核心处理器，主频至少2-2.5GHz	64-512BG 内存	千兆或万兆网卡（存储密度越高，需要的网络网络吞吐越高）	12-24块1-4TB硬盘
Ceph-MDS	4 核或更强悍的 CPU	至少每进程 1GB	双千兆	ssd
Ceph-Monitor	单核/双核CPU	至少每进程 1GB	双千兆	ssd
Ceph-OSD	双核 CPU	1GB/TB，存储多大，内存需求多大	双万兆	日志写入ssd，数据写入hdd，hdd可以很大

存储利用率以及可用性

先做一个基于NFS的基准数据。单盘16TB，单节点36盘，双raid5方案，对于单机来说，利用率为：(16*(36/2-1-1)*2)/(16*36) *100 = 88.89%。相对的，在双GHS情况下，36块盘允许2块盘故障，双DHS下，36块盘分成的2个raid各允许1块盘故障。

MinIO 下，参考 Erasure Code Calculator 计算器下，按照8台机器，单机36盘，单盘16TB，纠删码条块16，纠删码奇偶校验4，存储可用率为 75%。允许72块盘出现故障，2台机器挂掉。
MinIO 下，参考 Erasure Code Calculator 计算器下，按照8台机器，单机36盘，单盘16TB，纠删码条块16，纠删码奇偶校验2，存储可用率为 87%。允许36块盘出现故障，1台机器挂掉。
Ceph两种模式，多副本模式的存储利用率必定会低，纠删码模式下，存储空间利用率和MinIO一致。
HDFS 默认使用多副本模式，存储利用率约为 1/n

存储性能

存储性能方向太多了，软硬件的原因都有。我们需要先做一些假定：

写入：100台算力机，假设一天输出3TB，就是300TB，平均折算为3.5GB/s
读取：

特性差别

MinIO

双活跨区域复制
WORM机制，实现数据不变性，指定期间的对象保留，防止篡改
Bitrot保护，防止比特反转
云原生支持性高
监控容易

Ceph

CRUSH算法：Crush算法是ceph的两大创新之一，简单来说，Ceph摒弃了传统的集中式存储元数据寻址的方案，转而使用CRUSH算法完成数据的寻址操作。CRUSH在一致性哈希基础上很好的考虑了容灾域的隔离，能够实现各类负载的副本放置规则，例如跨机房、机架感知等。Crush算法有相当强大的扩展性，理论上支持数千个存储节点。
高可用：Ceph中的数据副本数量可以由管理员自行定义，并可以通过CRUSH算法指定副本的物理存储位置以分隔故障域，支持数据强一致性； Ceph可以忍受多种故障场景并自动尝试并行修复；Ceph支持多份强一致性副本，副本能够垮主机、机架、机房、数据中心存放。所以安全可靠。Ceph存储节点可以自管理、自动修复。无单点故障，容错性强。
高性能：因为是多个副本，因此在读写操作时候能够做到高度并行化。理论上，节点越多，整个集群的IOPS和吞吐量越高。另外一点Ceph客户端读写数据直接与存储设备(osd) 交互。在块存储和对象存储中无需元数据服务器。
高扩展性：Ceph不同于Swift，客户端所有的读写操作都要经过代理节点。一旦集群并发量增大时，代理节点很容易成为单点瓶颈。Ceph本身并没有主控节点，扩展起来比较容易，并且理论上，它的性能会随着磁盘数量的增加而线性增长。Ceph扩容方便、容量大。能够管理上千台服务器、EB级的容量。
特性丰富：Ceph支持三种调用接口：对象存储，块存储，文件系统挂载。三种方式可以一同使用。在国内一些公司的云环境中，通常会采用Ceph作为openstack的唯一后端存储来提升数据转发效率。Ceph是统一存储，虽然它底层是一个分布式文件系统，但由于在上层开发了支持对象和块的接口，所以在开源存储软件中，优势很明显。

安全性

安全性主要是出于多用户多租户情况下需要考虑。目前分布式存储基本都会考虑到多用户多租户模式，只是配置的难度不同而已。只是为了lotus项目使用，可以暂时不考虑安全性（数据安全性更多的是数据完整性）。

A/B

Minio 与其他分布式系统的异同点