分布式文件系统对比与选型参考

分布式文件系统（Distributed File System）是指文件系统管理的物理存储资源不一定直接连接在本地节点上，而是通过计算机网络与节点相连。分布式文件系统的设计基于客户机/服务器模式。一个典型的网络可能包括多个供多用户访问的服务器。另外，对等特性允许一些系统扮演客户机和服务器的双重角色。例如，用户可以"发表"一个允许其他客户机访问的目录，一旦被访问，这个目录对客户机来说就像使用本地驱动器一样。

一方面云原生架构提供了很多设计理念，一方面我们也更关注用户在自己的业务场景中遇到的痛点和对应的需求，比如希望存储系统服务化，可以弹性伸缩，在海量数据面前对人、对程序同样友好，如何支持 Hadoop 生态、OLAP 产品等实现存储计算分离。同时简单、可靠、高性能、低成本当然也是一个文件存储服务必须具备的。

判断一个分布式文件系统是否优秀，取决于以下三个因素：

++++数据的存储方式++++ ++++：++++

例如有1000万个数据文件，可以在一个节点存储全部数据文件，在其他N个节点上每个节点存储1000/N万个数据文件作为备份；或者平均分配到N个节点上存储，每个节点上存储1000/N万个数据文件。无论采取何种存储方式，目的都是为了保证数据的存储安全和方便获取。

++++数据的读取速率++++

包括响应用户读取数据文件的请求、定位数据文件所在的节点、读取实际硬盘中数据文件的时间、不同节点间的数据传输时间以及一部分处理器的处理时间等。各种因素决定了分布式文件系统的用户体验。即分布式文件系统中数据的读取速率不能与本地文件系统中数据的读取速率相差太大，否则在本地文件系统中打开一个文件需要2秒，而在分布式文件系统中各种因素的影响下用时超过10秒，就会严重影响用户的使用体验。

++++数据的安全机制++++

由于数据分散在各个节点中，必须要采取冗余、备份、镜像等方式保证节点出现故障的情况下，能够进行数据的恢复，确保数据安全。

二、主流分布式文件系统介绍

目前主流的分布式文件系统有：MinIO、GFS、Ceph、Lustre、TFS、HDFS、MooseF、MogileFS、FastDFS、GlusterFS、GridFS、JuiceFS、ChubaoFS、Ozone、PolarFS等。

GFS（Google File System）

Google公司为了满足本公司需求而开发的基于Linux的专有分布式文件系统。尽管Google公布了该系统的一些技术细节，但Google并没有将该系统的软件部分作为开源软件发布。

HDFS（Hadoop Distributed File System）

Hadoop 实现了一个分布式文件系统，简称HDFS。Hadoop是Apache Lucene创始人Doug Cutting开发的使用广泛的文本搜索库。它起源于Apache Nutch，后者是一个开源的网络搜索引擎，本身也是Luene项目的一部分。Aapche Hadoop架构是MapReduce算法的一种开源应用，是Google开创其帝国的重要基石。

Ceph

加州大学圣克鲁兹分校的Sage Weil攻读博士时开发的分布式文件系统。并使用Ceph完成了他的论文。

由于 ceph 使用 btrfs 文件系统，而btrfs 文件系统需要 Linux 2.6.34 以上的内核才支持。ceph目前还不足够成熟，它基于的btrfs本身也不成熟，它的++++官方网站上也明确指出不要把ceph用在生产环境中++++。

Lustre

Lustre是一个大规模的、安全可靠的，具备高可用性的集群文件系统，它是由SUN公司开发和维护的。该项目主要的目的就是开发下一代的集群文件系统，可以支持超过10000个节点，数以PB的数据量存储系统。目前Lustre已经运用在一些领域，例如HP SFS产品等。

MooseFS

支持FUSE，相对比较轻量级，对master服务器有单点依赖，用perl编写，性能相对较差，国内用的人比较多。

MogileFS

由memcahed的开发公司danga一款perl开发的产品，目前国内使用mogielFS的有图片托管网站yupoo等。MogileFS是一套高效的文件自动备份组件，由Six Apart开发，广泛应用在包括LiveJournal等web2.0站点上。

FastDFS

是一款类似Google FS的开源分布式文件系统，是纯C语言开发的。FastDFS是一个开源的轻量级分布式文件系统，它对文件进行管理，功能包括：文件存储、文件同步、文件访问（文件上传、文件下载）等，解决了大容量存储和负载均衡的问题。特别适合以文件为载体的在线服务，如相册网站、视频网站等等。

GlusterFS

开源分布式横向扩展文件系统，可以根据存储需求快速调配存储，内含丰富的自动故障转移功能，且摈弃集中元数据服务器的思想。适用于数据密集型任务的可扩展网络文件系统，具有可扩展性、高性能、高可用性等特点。gluster于2011年10月7日被red hat收购。

TFS（Taobao File System）

TFS是一个高可扩展、高可用、高性能、面向互联网服务的分布式文件系统，主要针对海量的非结构化数据，它构筑在普通的Linux机器集群上，可为外部提供高可靠和高并发的存储访问。TFS为淘宝提供海量小文件存储，通常文件大小不超过1M，满足了淘宝对小文件存储的需求，被广泛地应用在淘宝各项应用中。它采用了HA架构和平滑扩容，保证了整个文件系统的可用性和扩展性。同时扁平化的数据组织结构，可将文件名映射到文件的物理地址，简化了文件的访问流程，一定程度上为TFS提供了良好的读写性能。

GridFS

MongoDB是一种知名的NoSql数据库，GridFS是MongoDB的一个内置功能，它提供一组文件操作的API以利用MongoDB存储文件，GridFS的基本原理是将文件保存在两个Collection中，一个保存文件索引，一个保存文件内容，文件内容按一定大小分成若干块，每一块存在一个Document中，这种方法不仅提供了文件存储，还提供了对文件相关的一些附加属性（比如MD5值，文件名等等）的存储。文件在GridFS中会按4MB为单位进行分块存储。

11.MinIO

MinIO 是GlusterFS创始人之一Anand Babu Periasamy发布的开源项目，基于Apache V2 license 100% 开放源代码。MinIO采用Golang实现，客户端支持Java、Python、Javacript、Golang语言等。在中国，阿里巴巴、腾讯、百度、中国联通、华为、中国移动等等9000多家企业也都在使用MinIO产品。

设计的主要目标是作为私有云对象存储的标准方案。非常适合于存储大容量非结构化的数据，例如图片、视频、日志文件、备份数据、容器和虚拟机镜像等，而一个对象文件可以是任意大小，从几kb到最大5T。

12.JuiceFS

JuiceFS 是一款面向云原生设计的高性能分布式文件系统，在 Apache 2.0 开源协议下发布。提供完备的 POSIX 兼容性，可将几乎所有对象存储接入本地作为海量本地磁盘使用，亦可同时在跨平台、跨地区的不同主机上挂载读写。

采用「数据」与「元数据」分离存储的架构，从而实现文件系统的分布式设计。文件数据本身会被切分保存在对象存储（例如 Amazon S3），而元数据则可以保存在 Redis、MySQL、TiKV、SQLite 等多种数据库中，可以根据场景与性能要求进行选择。

13.ChubaoFS

CFS 支持顺序和随机文件访问，对大文件和小文件都进行了优化存储，并针对不同的写入场景采用不同的复制协议，以提高复制性能。它采用元数据子系统，根据内存使用情况在不同的存储节点上存储和分发文件的元数据。

14.Ozone

是Apache Hadoop项目的子项目，是一个基于对象存储的分布式文件系统。其主要目标是提供一个高可用性、可扩展性和高性能的存储解决方案，支持大数据分析和处理应用。

不仅能存储数十亿个不同大小的对象，还支持在容器化环境中运行。提供了一个类似于 POSIX 的文件系统接口，以方便应用程序进行文件读写操作。

15.PolarFS

PolarFS 是一个具有超低延迟和高可用性的分布式文件系统，专为 POLARDB 数据库服务而设计。PolarFS 在用户空间中利用了轻量级网络堆栈和 I/O 堆栈，充分利用了 RDMA、NVMe 和 SPDK 等新兴技术。通过这种方式，PolarFS 的端到端延迟大大降低，实验表明 PolarFS 的写入延迟与 SSD 上本地文件系统的写入延迟非常接近。为了在保证 PolarFS 的副本一致性的同时最大限度地提高 I/O 吞吐量，我们开发了 ParallelRaft 协议，它利用数据库的无序 I/O 完成容错能力，打破了 Raft 的严格串行化。

ParallelRaft 继承了 Raft 的可理解性和易于实现，同时为 PolarFS 提供了更好的 I/O 可伸缩性。

三、分布式文件系统的对比

补充：

MinIO中文文档，见：http://docs.MinIO.org.cn/

MinIO的优点：

安装部署（运维简单）

MinIO在安装过程是黑盒的，不用深入关注它的架构，也不需要进行零件组装，基本上可以做到开箱即用。普通的技术人员就能够参与后期的运维。

MinIO提供了两种部署方式：单机部署和分布式，两种部署方式都非常简单，其中分布式部署还提供了纠删码功能来降低数据丢失的风险。

UI界面

MinIO自带UI界面，且页面不需要你单独的部署，和服务端一并安装。开箱即用。

高性能

MinIO号称是世界上速度最快的对象存储服务器。在标准硬件上，对象存储的读/写速度最高可以达到183 GB/s和171 GB/s。对象存储可以充当主存储层，以处理Spark、Presto、TensorFlow、H2O.ai等各种复杂工作负载以及成为Hadoop HDFS的替代品。MinIO用作云原生应用程序的主要存储，与传统对象存储相比，云原生应用程序需要更高的吞吐量和更低的延迟。而这些都是MinIO能够达成的性能指标。

容器化支持

MinIO 符合一切原生云计算的架构和构建过程，并且包含最新的云计算的全新的技术和概念。其中包括支持Kubernetes 、Docker、微服和多租户的的容器技术。

丰富的SDK支持

MinIO几乎提供了所有主流开发语言的SDK以及文档。

AWS S3标准兼容

亚马逊云的 S3 API（接口协议）是在全球范围内达到共识的对象存储的协议，是全世界内大家都认可的标准。MinIO 在很早的时候就采用了 S3 兼容协议，并且MinIO 是第一个支持 S3 Select 的产品. MinIO对其兼容性的全面性感到自豪，并且得到了 750多个组织的认同, 包括Microsoft Azure使用MinIO的S3网关 - 这一指标超过其他同类产品的总和。

怎么理解呢？可以这么说你目前为了节约成本使用MinIO，等你的公司壮大了、有钱了。不想自己运维基础设施了，你就可以把对象存储放到云上，只要云厂商支持S3标准，你的应用程序是不需要重新开发的。

可扩展性

MinIO利用了Web缩放器的来之不易的知识，为对象存储带来了简单的缩放模型。这是我们坚定的理念 "简单可扩展." 在 MinIO, 扩展从单个群集开始，该群集可以与其他MinIO群集联合以创建全局名称空间, 并在需要时可以跨越多个不同的数据中心。通过添加更多集群可以扩展名称空间, 更多机架，直到实现目标。

2、老版本MinIO的缺点

局限1：MinIO不支持动态增加节点

MinIO创始人的++++设计理念就是动态增加节点太复杂++++ ，后续会采用其它方案来支持扩容。目前只能是++++新增节点后手动重启系统才生效++++，系统会自动平衡数据，这种设计到底对系统后续有什么影响，我觉得使用者需要考虑清楚点。

局限2：大集群最大节点数为32

MinIO实现了一个峰值锁叫DSync。它在节点数量少时，性能非常高；但节点数量过多时，性能就下降了。功能实现的最大节点就是32，所以导致MinIO单个集群的最大节点数也是32。

3、新版本MinIO的优点：

高可用性和强一致性

MinIO采用分布式架构，数据自动在多个节点之间进行复制，实现了高可用性和强一致性。++++即使部分节点故障，系统仍然能够正常工作，并且数据不会丢失++++。这使得企业能够安心地存储和访问重要的业务数据，同时提高了系统的可靠性。

自动扩展和无限容量

MinIO的分布式架构++++允许动态地添加或移除节点++++ ，从而实现自动扩展。当数据量增加时，只需简单地增加节点，系统即可平稳进行水平扩展，提供更大的存储容量。这种++++无限扩展的能力++++ 使得MinIO能够应对企业日益增长的数据需求，++++降低了存储成本和管理复杂性++++。

安全可靠和数据保护

MinIO提供了数据加密和访问控制等安全机制，保障企业数据的安全性。数据加密++++可以选择++++ 在客户端或服务端进行，确保数据在传输和存储过程中不会被非法获取。此外，MinIO还++++支持数据的备份和恢复++++，保证数据的完整性和可靠性。

4、GridFS的优点：

1）存储用户产生的文件内容

可以利用你的数据库备份来备份你的文件。而且由于MongoDB自身的复制技术，在MongoDB集群中的每一个副本处都有你的文件拷贝。删除文件跟删除数据库中的对象一样简单。

2）访问文件内容的分区

当把文件上传到GridFS后，文件会被分割成大小为256KB的块，并单独存放。因此当你需要读文件中的某个范围的字节时，只需把相应的文件块载入内存，而无需把整个文件加载到内存。这一点对于选择读或编辑尺寸很大的媒体内容文件时非常有用。

3）在MongoDB中存储16MB以上的文件

MongoDB默认的文件大小上限为16MB。所以，如果你的文件超过了16MB，那么你就应该使用GridFS。

4）克服文件系统的限制

如果你需要存储大量的文件，你就需要考虑文件系统自身的限制，因为文件系统对目录下的文件数量是有要求的。而使用GridFS后，你无需再担心这个问题。GridFS和MongoDB的分片使得你的文件可以分布到多个服务器上，而且没有增加操作的复杂性。

5、GridFS的缺点：

1）工作集

伴随数据库内容的GridFS文件会显著地搅动MongoDB的内存工作集。如果你不想让GridFS的文件影响到你的内存工作集，那么可以把GridFS的文件存储到不同的MongoDB服务器上。

2）性能

文件服务性能会慢于从Web服务器或文件系统中提供本地文件服务的性能。但是这个性能的损失换来的是管理上的优势。

3）原子更新

GridFS没有提供对文件的原子更新方式。如果你需要满足这种需求，那么你需要维护文件的多个版本，并选择正确的版本。

6.、分布式文件系统特性对比

什么是POSIX？

POSIX表示可移植操作系统接口（Portable Operating System Interface of UNIX，缩写为 POSIX ），也就是Unix下应用程序共同遵循的一种规范。支持POSIX的应用程序意味着在各个Unix系统间提供了跨平台运行的支持。

四、选型参考

MinIO、GFS、Ceph、Lustre、TFS、HDFS、MooseF、MogileFS、FastDFS、GlusterFS、GridFS、JuiceFS、ChubaoFS、Ozone、PolarFS

按特性分类

适合做通用文件系统的有：MinIO，Ceph，Lustre，MooseFS，GlusterFS；

适合做小文件存储的文件系统有：Ceph，MooseFS，MogileFS，FastDFS，TFS；

适合做大文件存储的文件系统有：MinIO，HDFS，Ceph，Lustre，GlusterFS，GridFS、ChubaoFS、Ozone、PolarFS；

轻量级文件系统有：MinIO，MooseFS，FastDFS；

简单易用，用户数量活跃的文件系统有：MinIO，MooseFS，MogileFS，FastDFS，GlusterFS；

支持FUSE挂载的文件系统有：MinIO，HDFS，Ceph，Lustre，MooseFS，GlusterFS。

根据需求分析进一步筛选

GFS：不开源，学习成本高，且相关特性资料不全。暂时排除；

Ceph：目前不够成熟稳定。系统稳定性有待考究。很少有使用在生产环境的案例。暂时排除；

Lustre：对内核依赖程度过重，且不易安装使用。暂时排除；

TFS：安装复杂，且官方文档少，不利于以后的学习使用。适合小于1M的文件。暂时先排除；

HDFS：存在单点故障。交互式应用，低延迟很难知足。设计中没有考虑修改写、截断写、稀疏写等复杂的posix语义，目的并不是通用的文件系统，一般作为hadoop ecosystem的存储引擎。不支持多用户并发写相同文件。暂时排除；

MooseF：不支持跨集群数据同步，主从复制有性能瓶颈，从可扩展，主不易扩展，社区不活跃。暂时排除；

MogileFS：Perl语言编写，维护性差。节点之间Http通信，性能不足。易用性差。暂时排除；

FastDFS：当一个storage中的某一目录挂载的磁盘损坏的话，不能进行自动恢复，需要手动恢复比较麻烦。不支持FUSE、POSIX。不支持断点续传。对跨公网的文件同步，存在较大延迟，需要应用做相应的容错策略。同步机制不支持文件正确性校验，降低了系统的可用性。暂时排除；

GlusterFS：通用性越强，其跨越的层次就越多，影响其IO处理效率。频繁读写下，会产生垃圾文件，占用磁盘空间。暂时排除；

GridFS：性能较低，不如直接访问文件系统快。无法修改文档。如果要修改GridFS里面的文档，只能是先删除再添加。暂时排除；

JuiceFS：元数据存储依赖Redis，数据安全是一个问题。严重依赖云厂商的存储可靠性。暂时排除；

ChubaoFS：Posix支持不全，rename还有问题，常用的文件锁需要支持。目前CFS的元数据都缓存在内存中，而CFS的inode由于包含了大量layout信息。元数据比较大，会占大量的内存。这也可以通过增加元数据服务器的内存和节点数量来缓解。没有数据迁移。新加节点会产生负责均衡。这对于大多数文件系统写少读多的情况也没太大问题。社区活跃度不够，产品比较新，稳定性需要加强。暂时排除；

Ozone：不支持 Append、truncate 的操作。另外一个就是 Ozone 目前还没有像文件夹的这样的一个 metadata，因此他就没办法去获得文件夹的 owner、modificationTime 等信息。还缺少一个 container balancer 这样的功能，用它来均衡存储，使集群的存储能分布均匀。底层写数据是基于 ratis，而目前 ratis 写也只支持一副本和三副本，腾讯正在向开源社区去贡献都基于的 Strorage cluster 框架的任意副本的支持。目前还缺少 DataNode 磁盘预留功能。暂时排除；

PolarFS：依赖硬件RDMA， PCIe SSD。不支持标准的文件接口。暂时排除；

MinIO：由于MinIO是一个基于S3协议的对象存储系统，它在存储大量小文件方面的表现可能不如FastDFS。由于MinIO的高可用性和可扩展性，它可能需要更多的配置和管理，需要更多的学习和技术支持。

经初步筛选剩下的文件系统有：MinIO。

五、硬件条件对比

|-----------|-----------------------------------------------------------------------------------------------------|-------|
| 文件系统 | 部署条件 | 服务器数量 |
| MinIO | 至少需要4台服务器 | 4 |
| MinIO | 每台服务器需要添加1块磁盘，大小随意。 | 4 |
| MinIO | 使用分布式MinIO自动引入了纠删码功能，如果是一个有N块硬盘的分布式MinIO，只要有N/2硬盘在线，数据就是安全的、可读的。不过需要至少有N/2+1个硬盘在线，才能创建新的对象。 | 4 |
| HDFS | 至少需要3台服务器 | 3 |
| HDFS | 准备节点服务器。 HDFS需要NameNode（管理节点）和DataNode（存储节点）两种节点。一台NameNode，两台DataNode。 | 3 |
| HDFS | 安装Java并配置JDK环境变量。 HDFS是基于Java开发的，所以首先需要在每台服务器上安装JDK。 | 3 |
| HDFS | 配置SSH免密登录。不同节点间需要免密SSH登录，以方便HDFS进程间通信。 | 3 |
| HDFS | 在每台节点上安装HDFS。可以下载HDFS的发行包，然后进行解压、配置、编译安装。首先启动NameNode，再启动所有的DataNode。 | 3 |
| Ceph | 至少3台机器 | 3 |
| Ceph | 充当部署节点和客户端，可以与ceph节点共用。 | 3 |
| Ceph | 1台部署节点（配一块硬盘，运行ceph-depoly）。 | 3 |
| Ceph | 1台ceph节点（配两块硬盘，第一块为系统盘并运行mon，第二块作为osd数据盘）。 | 3 |
| Ceph | 1台客户端（可以使用ceph提供的文件系统，块存储，对象存储）。 | 3 |
| Lustre | 至少需要4台服务器 | 4 |
| Lustre | 每台服务器至少需要两块硬盘。 | 4 |
| Lustre | 其中，1台作为文件元数据服务器，1台作为文件数据服务器，1台作为文件数据服务器兼备份服务器，还有1台作为客户端。 | 4 |
| Master | 至少需要4台服务器 | 4 |
| Master | Master服务器需要稳定，并有一定的可用内存。 | 4 |
| Master | Metalogger服务器用于元数据备份，必要时可以恢复数据。 | 4 |
| Master | Chunkservers用于文件块的存储服务，推荐至少有两台服务。 | 4 |
| Master | 其中，1台作为Master服务器，1台作为Metalogger服务器，2台作为Chunkservers服务器。 | 4 |
| MogileFS | 至少3台服务器 | 3 |
| MogileFS | 分别作为存储节点（Storage Node）、跟踪器（Tracker Node）和数据库（Database Node） | 3 |
| MogileFS | 存储节点（Storage Node）：负责存储实际的数据文件，可以进行扩展以增加存储能力。 | 3 |
| MogileFS | 跟踪器（Tracker Node）：负责跟踪所有的存储节点，处理客户端的请求并协调存储节点的操作。跟踪器可以与存储节点运行在相同的服务器上。 | 3 |
| MogileFS | 数据库（Database Node）：负责存储和管理MogileFS的文件信息，可以使用诸如MySQL等关系型数据库。 | 3 |
| FastDFS | 至少部署6台服务器 | 6 |
| FastDFS | 每台服务器至少两块硬盘，每块硬盘至少100G。 | 6 |
| FastDFS | 操作系统：FastDFS推荐使用CentOS 7.x或CentOS 8.x。 | 6 |
| FastDFS | 其他工具：还需要安装nginx及FastDFS需要的库依赖。 | 6 |
| GlusterFS | 至少需要5台服务器。 | 5 |
| GlusterFS | 其中4台服务器，每台服务器至少配置2块硬盘，其中一块是系统盘，另一块是存放数据。 | 5 |
| GlusterFS | 最后1台为客户端服务器。 | 5 |
| TFS | 至少2台服务器 | 2 |
| TFS | 至少1台NameServer，建议2台，配置至少8核16G，最好配上1T SAS 7200转企业级硬盘，双网卡，最好配上RAID。 | 2 |
| TFS | 至少1台ChunkServer，建议6台，配置至少12核24G，最好配上1T SAS 7200转企业级硬盘，双网卡，最好配上RAID。 | 2 |
| TFS | TFS可以支持平滑扩容，所以当存储容量不够时，可以增加ChunkServer来扩容。具体需要几台服务器可以根据自己的需求来配置。 | 2 |
| GridFS | 至少4台服务器 | 4 |
| GridFS | 主服务器：作为MongoDB的主服务器，负责存储GridFS文件的数据和元数据。为了确保数据的安全性，建议使用多台服务器作为主服务器，实施主从复制或分片集群等高可用性（HA）方案。 | 4 |
| GridFS | 从服务器：作为MongoDB的从服务器，负责存储主服务器的副本数据，提供备份和恢复功能。同样，建议使用多台从服务器，以实现HA和高性能。 | 4 |
| GridFS | Chunk服务器：这些服务器负责存储GridFS文件的分片（chunks）。每个文件被分成多个块（chunks），然后这些块被分散存储在多个chunk服务器上。这有助于提高文件存储的效率和可扩展性。 | 4 |
| GridFS | 客户端服务器：这些服务器提供客户端访问接口，处理客户端的请求并协调与数据库服务器和Chunk服务器的交互。 | 4 |
| JuiceFS | 至少2台服务器 | 2 |
| JuiceFS | 硬盘空间：每个节点硬盘空间不小于100GB。 | 2 |
| JuiceFS | CPU：每个节点CPU核数不小于4核。 | 2 |
| JuiceFS | 内存：每个节点内存不小于8GB。 | 2 |
| JuiceFS | 网络带宽：每个节点网络带宽不小于100Mbps。 | 2 |
| ChubaoFS | 至少3台服务器 | 3 |
| ChubaoFS | Master节点：负责管理和协调整个ChubaoFS集群。 | 3 |
| ChubaoFS | 它存储元数据，包括文件系统的结构、权限和数据位置。 | 3 |
| ChubaoFS | Master节点通常需要更多的内存和计算资源，以处理元数据操作和管理任务。Master节点应该是高可用的，通常通过在多个服务器上运行多个Master节点来实现冗余性。 | 3 |
| ChubaoFS | Chunk节点：存储实际的数据块，它们分散在整个集群中。这些节点需要大容量的硬盘来存储数据。 | 3 |
| ChubaoFS | Chunk节点负责数据的读取、写入和复制，以确保数据的冗余性和可用性。通常，Chunk节点需要足够的网络带宽来处理数据传输。 | 3 |
| ChubaoFS | Proxy节点：Proxy节点是客户端与ChubaoFS集群之间的接口。客户端通过Proxy节点访问文件和数据。 | 3 |
| ChubaoFS | Proxy节点负责将客户端请求转发给Master节点和Chunk节点，以执行文件系统操作。它们通常需要快速的网络连接，以处理客户端的请求。 | 3 |
| Ozone | 至少4台服务器 | 3 |
| Ozone | Ozone Manager节点： | 3 |
| Ozone | Ozone Manager节点负责管理Ozone集群的元数据和协调工作。 | 3 |
| Ozone | 它们存储关于对象存储桶、对象键、权限等元数据信息，以便客户端可以检索对象和执行操作。 | 3 |
| Ozone | 在高可用性设置中，通常有多个Ozone Manager节点，使用Raft协议来保持元数据的一致性和冗余。 | 3 |
| Ozone | Ozone Manager节点需要相对较大的内存和处理能力，因为它们处理元数据操作。 | 3 |
| Ozone | DataNode节点： | 3 |
| Ozone | DataNode节点负责存储实际的对象数据。 | 3 |
| Ozone | 它们管理对象数据的分布和复制，以确保数据的冗余和可用性。 | 3 |
| Ozone | DataNode节点通常需要大容量的硬盘，因为它们存储对象数据。 | 3 |
| Ozone | 数据节点也需要足够的内存和处理能力来处理数据的读写请求。 | 3 |
| Ozone | ContainerManager节点： | 3 |
| Ozone | ContainerManager节点管理Ozone集群中的容器，容器是对象数据的逻辑分组。 | 3 |
| Ozone | 它们处理容器的创建、删除和复制等操作。 | 3 |
| Ozone | ContainerManager节点通常需要相对较少的硬盘和内存资源，但仍然需要足够的计算能力来管理容器。 | 3 |
| PolarFS | 至少3台服务器 | 3 |
| PolarFS | Master节点： | 3 |
| PolarFS | Master节点是PolarFS集群的管理和协调中心。 | 3 |
| PolarFS | 它们负责元数据管理，包括文件系统的结构、权限、文件位置等信息。 | 3 |
| PolarFS | Master节点通常需要更多的内存和计算资源，以处理元数据操作和管理任务。 | 3 |
| PolarFS | Master节点通常以多副本方式部署，以实现高可用性和容错性。 | 3 |
| PolarFS | Chunk节点： | 3 |
| PolarFS | Chunk节点负责存储实际的数据块，这些数据块组成了文件内容。 | 3 |
| PolarFS | 这些节点需要大容量的硬盘来存储文件数据。 | 3 |
| PolarFS | Chunk节点负责数据的读取、写入和复制，以确保数据的冗余性和可用性。 | 3 |
| PolarFS | 通常，Chunk节点需要足够的网络带宽来处理数据传输。 | 3 |
| PolarFS | Client节点： | 3 |
| PolarFS | Client节点是与PolarFS集群交互的终端用户或应用程序的接口。 | 3 |
| PolarFS | 客户端通过Client节点来访问文件和数据。 | 3 |
| PolarFS | Client节点负责将客户端请求转发给Master节点和Chunk节点，以执行文件系统操作。 | 3 |

六、总结

MinIO在技术架构上注重创新，借鉴了分布式文件系统的设计思想，将客户端请求分散到各个节点上进行处理，大大提升了系统的并发性和容错性。与传统的集中式存储系统相比，MinIO以其分布式、去中心化的特点，极大地提高了数据的可用性和可靠性，确保了数据的安全性。

其次，MinIO在性能优化上取得了突破性的创新成果。相比于传统存储系统，MinIO采用了多线程的处理方式，充分利用多核处理器的优势，大幅提升了数据的读写速度。此外，MinIO还引入了分层存储技术，根据数据的热度将其存储在不同层级的存储介质上，从而进一步提高数据的访问速度。这些性能优化的创新，使得MinIO成为了云存储领域的性能之王。

再次，MinIO在用户体验上也有着独到的创新之处。作为一个开源项目，MinIO提供了丰富而易用的API接口，方便开发者进行二次开发和定制化。此外，MinIO还支持与主流云平台的无缝集成，可以与各种应用和工具进行无缝对接，大大提升了用户的便捷性和灵活性。这种用户体验的创新，使得MinIO在开源社区中获得了广泛的认可和支持。

最后，MinIO在可扩展性上也展现出了强大的创新力量。通过采用"水平扩展"技术，MinIO可以轻松地扩展存储容量和计算能力，从而适应不断增长的数据需求。无论是个人用户还是大型企业，都可以根据自身需求进行灵活的部署和扩展，实现对存储资源的有效管理和利用。这种可扩展性的创新，使得MinIO成为了云存储领域的翘楚。

七、知识拓展：

1、块存储、文件存储、对象存储三者有何区别？

其实，存储的目的就是为数据提供空间。硬盘/固态硬盘是存储最终的载体，之所以有块存储、文件存储和对象存储不同类型的存储设备，主要是由于使用介质存储数据的手段或方法不同来划分的。

块存储

块存储提供的是不带文件系统裸磁盘，使用之前需先进行初始化。

通俗的来说，数据就像每个瓜子一样，堆放在存储仓里。瓜子就是每个数据块，这个存储舱就是磁盘。块存储只关心瓜子的进来和出去，不关心瓜子粒之间的关系和用途。

由于块存储只负责数据读取和写入，因此具有有高带宽、低延迟的优势，但是扩展能力有限，适用于对响应时间要求高的系统。比如数据库、ERP等企业核心应用的存储等。

文件存储

文件存储的存储端带有文件系统，我们常见的NAS存储都是文件存储设备。这些文件存储设备除了磁盘外还带有文件系统，用户直接通过存储端的文件系统就能调用存储资源。

数据像瓜子一样在一起组成了向日葵，再对应到不同的向日葵杆，要找到某个向日葵籽，先找到这个对应的向日葵杆，再找到这个向日葵，然后根据在这个向日葵上对应的位置找到这个瓜子。

相比于块存储，文件存储由于有自己的文件系统，可以实现更高级的管理，可以很方便的共享，因此用途非常广泛。比如常用的NFS、CIFS、ftp等都是基于文件存储的。但相比于块存储，文件存储读写速度相对于块存储要慢一点。

对象存储

块存储性能出色但是不能共享，文件存储可以共享但是速度又总是不让人满意；做为不会做选择题的成年人既想性能，还要实现共享，同时还要满足大规模扩展需求，所有就有了对象存储。

数据和元数据打包在一起作为一个整体对象存在一个超大池子里。用户想访问，只需能通过它的UUID，才能找到它。

好比数据的葵花籽被做成了包装袋，每个包装袋都有一个唯一出厂条形码，但是找对应的对应的瓜子袋，只能通过唯一条形码找到对应的瓜子袋，但每一次都只能是一袋为单位。

对象存储端的文件系统就是采用这种哈希表-键值（可以理解为查字典，最多两层目录）这种方式来提高读写速度的。对象存储就可以非常简单的扩展到超大规模，因此非常适合数据量大、增速又很快的视频、图像等，例如百度网盘、大数据存储；

2、MinIO文件上传流程：

3.块存储、文件存储、对象存储，哪个快，有什么优劣势？

块存储：通常是以太网磁盘阵列（如RAID）的形式，将数据存储在固定大小的块中。这种类型的存储速度快，适用于需要共享访问、持久化存储的系统。

优势：

高并发访问：支持多个主机并发访问，适用于高并发的场景。

数据安全性：可以实现数据冗余和容错，提高数据安全性。

持久化存储：数据可以持久化存储，断电后数据不会丢失。

劣势：

维护成本高：需要专业的存储管理员进行维护和管理。

扩展性有限：扩展存储空间时需要增加更多的磁盘阵列，可能受限于厂商的设备类型和数量。

共享访问：虽然支持多个主机并发访问，但需要特定的文件系统支持，且不同操作系统的访问方式可能不同。

文件存储：通常是将数据存储在文件系统中的磁盘上。这种类型的存储适合共享访问，可以实现文件的索引、权限管理、安全性和持久化。

优势：

共享访问：支持多个用户和进程共享访问，适合办公、数据库等场景。

权限管理：可以实现文件的权限管理，保证数据的安全性。

持久化存储：数据可以持久化存储，断电后数据不会丢失。

劣势：

性能瓶颈：文件系统存在性能瓶颈，如元数据检索、并发访问等。

数据冗余：需要占用额外的存储空间来保存文件的元数据信息。

维护成本高：需要专业的文件管理员进行维护和管理。

对象存储：是将数据存储为不可变的大型数据块（对象）。这种类型的存储适合共享访问、持久化存储和共享访问。

优势：

高并发访问：支持多个主机并发访问，适用于高并发的场景。

数据安全性：可以实现数据冗余和容错，提高数据安全性。

持久化存储：数据可以持久化存储，断电后数据不会丢失。

可扩展性强：可以轻松扩展存储空间，不受设备类型和数量的限制。

低成本：由于其简单的架构和易于扩展的特性，通常具有较低的维护成本和较高的性价比。

劣势：

数据完整性：在多副本冗余的情况下，如果发生多个副本之间的数据不一致，需要通过特定的方式进行修复。

共享访问：虽然支持多个主机并发访问，但需要特定的文件系统支持，且不同操作系统的访问方式可能不同。

4.MinIO对于其他协议的支持有哪些？

MinIO支持S3协议。对于其他协议的支持，MinIO还支持与Spark和Flink等技术方案进行整合，通过S3 Select实现数据查询的下沉，这为大数据的存储与查询分离提供了事实依据，也为数据湖的构建打下了坚实的基础。

5.在分布式文件系统MinIO、GFS、Ceph、Lustre、TFS、HDFS、MooseF、MogileFS、FastDFS、GlusterFS、GridFS、JuiceFS、ChubaoFS、Ozone、PolarFS中，哪些是块存储、文件存储、对象存储？

所列举的分布式文件系统具有多种存储方式，例如MinIO既可以作为文件存储也可以作为对象存储，具体使用哪种方式视情况而定。

块存储：

HDFS
FastDFS
GlusterFS

文件存储：

MinIO
GFS
Ceph
Lustre
TFS
GridFS
JuiceFS
ChubaoFS
Ozone

对象存储：

MinIO
Ceph
GridFS

6.MinIO既可以作为文件存储也可以作为对象存储，是如何选择的？

MinIO作为文件存储和对象存储的选择，取决于上传的文件类型和大小。

MinIO适合存储大容量非结构化的数据，如：图片、视频、容器、镜像等，但它也可以存储结构化的数据，如文档、CSV文件等。

MinIO是基于Apache license开原协议的对象存储服务，兼容亚马逊S3云存储服务接口，它可以作为文件存储使用，也可以作为对象存储使用，但需要注意的是，MinIO作为文件存储时，只支持小于16GB的文件。

如果需要配置MinIO作为文件存储或对象存储，可以参考MinIO官方文档进行配置。

。。。后续补充

分布式文件系统对比与选型参考

一、分布式文件系统

二、主流分布式文件系统介绍

三、分布式文件系统的对比

四、 选型参考

五、硬件条件对比

六、总结

七、知识拓展：

四、选型参考