数据统计时间为2022年3月
Minio作为分布式存储新秀,从2016年发布第一个版本到现在短短6年时间，github start已达到31.9K, 远超2015年发布的另一款分布式存储 seaweedfs 13.9k、及2010年的Ceph 10.2k，一时风头无二；但贡献者Ceph 1172人，而Minio只有337，sweedfs只有146, 社区活跃度来讲离Ceph有不小的差距。国内生产真正大规模使用Minio的比较少见，跟当前License有不小的关系。
从三个维度来对比Ceph和Minio:
| Project | Ceph | Minio |
|---|---|---|
| 语言 | C++ | Go |
| 代码量(行) | 1147695 | 43818 |
| License | LGPL | AGPLv3 |
| 提供的API | librados (C, C++, Python, Ruby, PHP, C#, Perl), S3, Swift, FUSE | AWS S3 API (Go, Java, Python, .NET, Javascript, Haskell…) |
| 高可用 | Yes | Yes |
| Shared | Yes | Yes |
| 数据冗余方式 | 副本/纠删码 | 纠删码 |
| 纠删码算法算法 | Pluggable erasure codes(RS/LRC/SHEC) | Reed-Solomon |
| 纠删码作用单位 | Pool | Object |
| 初始版本发布时间 | 2010 | 2014 |
| 部署内存需求 | 1 per 1TB of storage | 无限制 |
| 部署方式 | k8s operator(rook)/裸机(ansible/cephadm/ceph-volume/binary) | k8s operator/裸机(docker-compose/ansible/binary/) |
| 平台支持 | Linux/ | Linux/Windows/MacOS |
| K8S存储支持 | CSI/COSI(NAS) | DirectPV(DAS)4 |
| 数据一致性 | 强 | 强 |
| 文档支持 | 强 | 弱 |
| 社区支持 | 邮件列表 | slack |
Ceph使用C++开发，功能多、性能好、但代码复杂，功能繁多、涉及技术栈太多
Minio 使用Go开发，代码精简易读
最初是Apache License 2.0，商业友好
修改库代码之后必须开源且协议为LGPL，主要针对库类使用，调用不受限制
只要调用到，调用项目项目协议需要使用AGPL，并且对使用该软件的用户提供源码，软件本身提供了商业授权。不能基于该软件做开发或者对软件本身进行修改而用于商用
Ceph各类架构文档、维护文档齐全，Minio文档缺失严重，例如纠删码块是怎么分布以及组装的、数据如何落盘的流程等等
Ceph主要使用邮件列表，Minio使用slack，slack实时性更强、效率更高，设置直接可以对其他人进行实时会话
| 项目 | Ceph | Minio |
|---|---|---|
| 容灾备份 | AA/AP | AA/AP |
| 认证/访问控制 | 支持插件(Active Directory/OpenLDAP/OpenID)/IAM | 支持插件(KEYCLOAK/facebook/Google/Okata/Active Directory/OpenLDAP)/IAM |
| TLS加密 | Yes | Yes |
| 客户端加密 | Yes | Yes |
| 服务端加密 | Yes | Yes |
| 对象锁定(WORM)5 | Yes(nautilus)6 | Yes |
| 版本管理 | Yes | Yes |
| 生命周期管理 | Yes | Yes |
| 数据分层 | Yes | Yes |
| 管理接口 | Dashboard/API/CLI | Console/API/CLI |
| 监控告警 | Prometheus | Prometheus |
| 事件通知 | Yes | Yes |
| 可扩展性 | Yes | Yes |
| AWS兼容 | Yes(不完全兼容) | Yes |
| S3 Select | Yes | Yes |
| 云网关模式 | 无 | Google Azure/NAS/S3/HDFS |
| 导出为文件系统 | nfs | minfs7 |
| 数据存储 | (bluestore)/Linux文件系统(filestore) | linux文件系统 |
| 元数据存储 | kv数据库/(rockdb/leveldb/other) | linux文件系统 |
xl.meta纠删码分布存储, 大文件数据与与元数据分开存储， 没有集中的元数据服务器，理论上集群规模不受中心化有状态组件的影响，可以无限横向扩容，带来的问题是每次io都要从磁盘上拉取到元数据计算组装，然后再操作，好处是对象存储没有修改操作，计算压力就少了很多| 项目 | Ceph | Minio |
|---|---|---|
| 单盘极端情况下影响整集群 | Yes | Yes |
| 元数据过大导致数据IO卡住 | Yes | No(元数据在本地磁盘一个块一个元数据) |
| 扩缩容性能损耗 | High | No(Server Pool)、单Set会有重平衡的问题 |
| 单集群规模受限 | 单盘性能(水桶效应) | **横向无限扩容(server pool) 8 |
| 集群联邦 | No | No^9 |
当分布式存储系统中一块磁盘时延忽高忽低时，无法触发集群故障处理机制，导致落到这快盘的io在时延高的情况下卡住，这类问题在架构复杂的系统不好定位，造成影响也比较大，Ceph和Minio都存在这样的问题。
Ceph的元数据存储在KV数据库，对象存储对象寻址是通过bucket index，如果一个bucket里面文件过多，这个index会非常大，例如有5000w个对象时，没有分片情况下这个index的大小会达到40G，静默校验过不去导致整个集群的IO卡住，且处理需要花费小时级的事件
Minio元数据以Linux文件的方式存储，每个数据块一个元数据文件，一般情况元数据不会太大，当启用多版本的时候，极端情况，元数据每个版本追加一条，追加到几十万几百万的量级也是会影响到正常IO的，这种情况在正常的使用中不会见到
同样的一个功能
存储系统主要需要关注的是拓展性、易维护性，指标可观测、事件可自动告警
对一个系统的了解必须是在大规模、高负载、有过整机房掉电损坏数据之后才能提出深入的、准确的评估，对minio使用较少，可能一些对比与实际表现存在偏差
只使用对象存储功能，且不做调用开发和二次开发，Minio好用不折腾。
如果有Iaas平台、块存储、文件系统需求，需要做商业化的存储产品、团队处于初期，则Ceph无可比拟。
https://en.wikipedia.org/wiki/Comparison_of_distributed_file_systems ↩︎ ↩︎
https://github.com/orgs/minio/repositories?page=1&type=all ↩︎ ↩︎
https://github.com/minio/directpv?utm_campaign=COSI&utm_source=minio&utm_medium=blog&utm_content=cosi-091621 ↩︎
https://docs.amazonaws.cn/AmazonS3/latest/userguide/object-lock-overview.html#object-lock-bucket-config ↩︎
https://tracker.ceph.com/issues/37763 ↩︎
https://github.com/minio/minfs ↩︎
https://docs.min.io/minio/baremetal/installation/expand-minio-distributed.html#install-the-minio-binary-on-each-node-in-the-new-server-pool ↩︎
https://blog.min.io/the-architects-guide-to-edge-storage/ ↩︎