MinIO与FastDFS对比

MinIO与FastDFS对比_第1张图片
MinIO与FastDFS对比_第2张图片
该思维导图地址 https://mm.edrawsoft.cn/template/199330

MinIO中文文档
MinIO中文官网
在开源中国的地址

目前可用于文件存储的网络服务选择有很多,比如阿里云OSS、七牛云、腾讯云等等,但是收费都有点小贵。为了帮公司节约成本,之前一直是使用fastDFS作为文件服务器,准确的说是图片服务器。直到我发现了MinIO,我决定放弃FastDFS。

关于MinIO的使用方法,我就不说了。大家去看MinIO官网地址:https://docs.min.io/docs/ ,非常详细。我就从对比的角度来说说我为什么果断的放弃了fastDFS,转而使用MinIO作为图片存储服务器。

理由一:安装部署(运维)复杂度

之前公司在使用fastDFS的时候,只有少数的几个人能够掌握fasdtDFS的部署结构。所以只要出现有点问题,能够顶上的只有这么几个人。如果将一个fastDFS分布式服务部署完成,需要具备以下的知识

linux基础的目录操作
常用的分布式主从原理
C语言代码的编译
nginx安装部署
nginx插件的使用(防盗链)

如果仅仅是上面的这些基础知识,安排几个程序员学一学还好说。主要是fastdfs的部署结构之复杂,如果我长时间不回顾,自己都会忘了这复杂的架构是怎么回事。

当我看到MinIO的安装过程之后,以及分布式的部署命令之后(分布式MinIO快速入门),放弃fastDFS的决心就已经做出了一大半。

说白了:FastDFS的部署不过是零件的组装过程,需要你去理解fastDFS的架构设计,才能够正确的安装部署。MinIO在安装的过程是黑盒的,你不用去深入关注它的架构,也不需要你进行零件组装,基本上可以做到开箱即用。普通的技术人员就能够参与后期运维。

理由二:文档

我觉得从我知道fastDFS开始,也有十年了。竟然没有官方文档,所有的文档全是某某公司的自己总结的文档,或者是某某网友自己总结的文档。

从这点上看fastDFS真的是一败涂地,当然阿里余庆大神在做这个项目的时候可能也没有考虑到后来会有这么多人用。即使用的人多了,在余庆大神眼里可能觉得这只是自己开发的一个小玩具,没有继续深入运营的必要。

理由三:开源项目运营组织

fastdfs是阿里余庆做的一个个人项目,在一些互联网创业公司中有应用,没有官网,不活跃,6个contributors。目前已经很少做更新。

MinIO目前是由2014年在硅谷创立的公司MinIO.Inc运营的开源项目,社区论坛的活跃度目前也非常的不错。

理由四:UI界面
我们都知道fastDFS默认是不带UI界面的,看看MinIO的界面吧。这个界面不需要你单独的部署,和服务端一并安装。开箱即用,爱了爱了。
MinIO与FastDFS对比_第3张图片

理由五:性能

MinIO号称是世界上速度最快的对象存储服务器。在标准硬件上,对象存储的读/写速度最高可以达到183 GB/s和171 GB/s。关于fastDFS我曾经单线程测试写了20万个文件,总共200G,大约用时10个小时。总体上是很难达到MinIO“号称的”以G为单位的每秒读写速度。
MinIO与FastDFS对比_第4张图片

理由六:容器化支持

MinIO提供了与k8s、etcd、docker等容器化技术深度集成方案,可以说就是为了云环境而生的。这点是FastDFS不具备的。
MinIO与FastDFS对比_第5张图片

理由七:丰富的SDK支持

fastDFS目前提供了 C 和 Java SDK ,以及 PHP 扩展 SDK。下图是MinIO提供的SDK支持,MinIO几乎提供了所有主流开发语言的SDK以及文档。同志们,重要的是文档。
MinIO与FastDFS对比_第6张图片

理由八:AWS S3标准兼容

Amazon的S3 API是对象存储领域的事实标准。MinIO是S3兼容性的事实上的标准,是第一个采用API和第一个添加对S3 Select支持的标准之一。包括微软Azure在内的750多家公司使用MinIO的S3网关,这一数字超过了业内其他公司的总和。
MinIO与FastDFS对比_第7张图片
什么意思?就是说你现在为了节约成本使用MinIO,等你的公司壮大了、有钱了。不想自己运维基础设施了,你就可以把对象存储放到云上,只要云厂商支持S3标准,你的应用程序是不需要重新开发的。

该篇文章原文地址 字母哥博客

其个人博客 字母哥博客

你可能感兴趣的:(java)