元数据性能大比拼：HDFS vs S3 vs JuiceFS

元数据是存储系统的核心大脑大数据数量级，元数据性能对整个大数据平台的性能和扩展能力至关重要。尤其在处理海量文件的时候。在平台任务创建、运行和结束提交阶段，会存在大量的元数据 create，open，rename 和 delete 操作。因此，在进行文件系统选型时，元数据性能可谓是首当其冲需要考量的一个因素。

目前主流的大数据存储方案中， HDFS 是使用最为广泛的方案，已经过十几年的沉淀和积累；以 Amazon S3 为代表的对象存储是近年来云上大数据存储的热门方案；JuiceFS 是大数据圈的新秀，专为云上大数据打造，基于对象存储来进行大数据存储。因此，我们选取了这 3 个典型的存储方案 HDFS、Amazon S3 与 JuiceFS 社区版 进行元数据的性能测试。

测试方法

NNBench 是Hadoop 中有一个专门压测文件系统元数据性能的组件，本次测试就是使用它来进行的。

原版的 NNBench 有一些局限性，我们做了调整：

原版 NNBench 的单个测试任务是单线程的，资源利用率低，我们将它改成多线程，便于增加并发压力。原版 NNBench 使用 hostname 作为路径名的一部分，没有考虑同一个主机里多个并发任务的冲突问题，会导致多个测试任务重复创建和删除文件，不太符合大数据工作负载的实际情况，我们改成使用 Map 的顺序号来生成路径名，避免的一个主机上多个测试任务的产生冲突。 测试环境

测试区域：us-east-1

测试软件：

JuiceFS 社区版本：v1.0.0

JuiceFS 元数据引擎：，6.2.6，cache.r5.large

性能表现

先来看看大家都熟悉的 HDFS 的性能表现：

此图描述的是 HDFS 每秒处理的请求数（TPS）随着并发数增长的曲线，随着并发的增加，TPS基本呈现线性增长。

性能对比

为了更直观的看出这三者的性能差异，我们直接把 HDFS、AWS S3 和 JuiceFS 放在一起比较：

总结

一般我们在看一个系统的性能时，主要关注它的操作时延（单个操作所消耗的时间）和吞吐量（满负载下的处理能力），我们把这两个指标再汇总一下：

上图是 20 个并发下的各操作的时延（未跑满负载），可以发现：

S3 非常慢，尤其是 Rename 操作，因为它是通过 Copy + Delete 实现的。本文测试的还只是单个空文件的 Rename，而大数据场景常用的是对整个目录的 Rename，差距会更大。JuiceFS 的速度比 HDFS 更快。

上图是 100 个并发时的吞吐量对比，可以发现：

S3 的吞吐量非常低，和其它两个产品有一到两个数量级的差距，意味着它需要使用更多的计算资源，产生更高的并发，才能获得同等的处理能力。JuiceFS 比 HDFS 的处理能力基本和 HDFS 持平，部分操作性能高于 HDFS。随着并发的持续升高，HDFS 的性能仍然可以继续提升，但 JuiceFS 受制于元数据引擎本身的性能，到达瓶颈。如果需要高吞吐，可以使用 TiKV 作为元数据引擎。

JuiceFS 社区版可以适配各种成熟的元数据引擎，各种元数据引擎性能都有其相应的特点。比如 Redis 的低时延迟，MySQL 的可靠性，TiKV 的高吞吐。更多测试详见：元数据引擎性能对比测试 | JuiceFS Document Center

如有帮助的话欢迎关注我们项目 Juicedata/JuiceFS 哟！ (0?0?)

（编辑：南平站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!