元数据是存储系统的外围大脑，元数据性能对整个大数据平台的性能和扩大能力至关重要。尤其在解决海量文件的时候。在平台工作创立、运行和完结提交阶段，会存在大量的元数据 create，open，rename 和 delete 操作。因而，在进行文件系统选型时，元数据性能堪称是首当其冲须要考量的一个因素。
目前支流的大数据存储计划中，HDFS 是应用最为宽泛的计划，曾经过十几年的积淀和积攒；以 Amazon S3 为代表的对象存储是近年来云上大数据存储的热门计划；JuiceFS 是大数据圈的新秀，专为云上大数据打造，基于对象存储来进行大数据存储。因而，咱们选取了这 3 个典型的存储计划 HDFS、Amazon S3 与 JuiceFS 社区版 进行元数据的性能测试。
测试方法
NNBench 是 Hadoop 中有一个专门压测文件系统元数据性能的组件，本次测试就是应用它来进行的。
原版的 NNBench 有一些局限性，咱们做了调整：
- 原版 NNBench 的单个测试工作是单线程的，资源利用率低，咱们将它改成多线程，便于减少并发压力。
- 原版 NNBench 应用 hostname 作为路径名的一部分，没有思考同一个主机里多个并发工作的抵触问题，会导致多个测试工作反复创立和删除文件，不太合乎大数据工作负载的理论状况，咱们改成应用 Map 的顺序号来生成路径名，防止的一个主机上多个测试工作的产生抵触。
测试环境
测试区域：us-east-1
测试软件：
- emr-6.4.0，hadoop3.2.1，HA 部署
- master（3 台）：m5.xlarge, 4 vCore, 16 GiB
- core（3 台 ): m5.xlarge, 4 vCore, 16 GiB
JuiceFS 社区版本：v1.0.0
JuiceFS 元数据引擎：ElastiCache，6.2.6，cache.r5.large
性能体现
先来看看大家都相熟的 HDFS 的性能体现：
此图形容的是 HDFS 每秒解决的申请数（TPS）随着并发数增长的曲线，随着并发的减少，TPS 根本出现线性增长。
- S3 速度比 HDFS 慢了一个数量级，但它的各种操作的速度根本保持稳定，总的 TPS 随着并发数的增长而增长。
- 但 S3 性能不太稳固，能够看到 Delete 申请在 100 并发下反而呈现了降落的状况，猜想可能和 S3 自身的负载无关。
- 整体趋势和 HDFS 相似，Open 会比其余操作快很多。
- JuiceFS 的 TPS 也是在 20 个并发以内根本放弃线性增长，之后增长放缓，在 80 个并发左右达到下限
性能比照
为了更直观的看出这三者的性能差别，咱们间接把 HDFS、AWS S3 和 JuiceFS 放在一起比拟：
- JuiceFS 在所有元数据操作上均大幅当先于 S3。
- JuiceFS 在 Create 和 Open 操作上当先于 HDFS。
- 此次测试中应用的元数据引擎是 ElastiCache，各操作在 80 并发左右会达到性能瓶颈，体现比 HDFS 差。
总结
个别咱们在看一个零碎的性能时，次要关注它的操作时延（单个操作所耗费的工夫）和吞吐量（满负载下的解决能力），咱们把这两个指标再汇总一下：
上图是 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✿)