s3fs、goofys、juicefs对比

 

性能方面， s3fs 和 goofys 在 read 和 write 方面没有本地缓存，其性能是依靠 s3 的性能来支撑的，这两个文件系统整体的性能相比JuiceFS 会低一些。

最明显的是 mv，对象存储没有 rename 操作，在对象存储中进行 rename 操作就是一个 copy 加 delete，性能代价是非常大的。

ls 方面，对象存储的存储类型是 kv 存储，不具备目录语义，所以 ls 整个目录结构对于 s3 来说，其实是对整个元数据的遍历，调用代价非常大。在大数据的场景下，性能是非常低的，并且有一些特性功能是不支持的。

元数据方面，s3fs 和 goofys 没有自己独立的元数据，所有的元数据都是依赖于s3的，JuiceFS 有自己的独立的元数据存储，

易用性方面，这几个产品都是非常简单易用，通过一个简单的命令就可以实现 s3的挂载；从可维护性来说，JuiceFS 有自己的独立的元数据引擎，我们需要对元数据服务进行运维；从社区的角度来说，JuiceFS 的社区活跃度是最高的。基于以上综合考虑，金山云选择了JuiceFS。

基于 JuiceFS 的测试

 

JuiceFS 产品介绍中第一句话就是 “像本地盘一样使用对象存储”，恰恰是我们做 ES 时所需要的功能。JuiceFS 已经集成了很多种对象存储，金山云的 KS3 也已经完整兼容，只需要再选一个元数据库即可。

第二功能验证。元数据库常用的有 Redis，关系型据库、 KV 数据库等。我们从这三个层面，元数据库支撑的数据量、响应速度、可运维性来做判断。

 

从数据量上来说，TiKV 无疑是最高的，但是我们的设计初衷是让每套 ES 集群独立一个元数据库实例，因此不同集群之间的元数据是不进行共享的，为了高可用彼此间需要互相隔离。

其次在响应速度方面， ES 把 JuiceFS 作为冷节点存储，冷节点存储的数据 IO 要比元数据的调用性能损耗更大，所以我们认为元数据的调用性能不是核心考虑的点。

从运维的角度来说，关系型数据库大家都比较熟，开发人员都可以很轻松的上手，其次公司是有公司有 RDS For MySQL 产品，有专业的 DBA 团队来负责运维，所以最终是选择了MySQL 作为的元数据引擎。