JuiceFS 元数据引擎选型：Redis、MySQL、TiKV 与 etcd 基准测试怎么解读

JuiceFS 元数据引擎选型Redis、MySQL、TiKV 与 etcd 基准测试怎么解读【免费下载链接】juicefsJuiceFS is a distributed POSIX file system built on top of Redis and S3.项目地址: https://gitcode.com/GitHub_Trending/ju/juicefs在为 JuiceFS 挑选元数据引擎时Redis、MySQL、TiKV、etcd 是常见的候选。JuiceFS 官方文档 Metadata Engines Benchmark 在同一套环境里对这几个引擎外加 PostgreSQL、FoundationDB做了同条件对比测试。这篇文章讲的是如何正确读取这份基准测试的三张结果表把测试条件、单位、倍数含义看清楚最后落到“哪种负载该选哪个引擎”的判断上并说明如何在你自己的环境里复测验证。先看测试条件确定数据适用范围解读结果之前先确认测试是在什么条件下跑的否则数字没法外推。这份基准测试的固定条件是所有测试使用同一套对象存储、同一批客户端和元数据主机只更换元数据引擎保证可比性客户端Amazon c5.xlarge4 vCPU、8 GiB 内存、最高 10Gbps 网络Ubuntu 20.04.1 LTS元数据主机Amazon c5d.xlarge4 vCPU、8 GiB 内存、100 GB SSD 本地盘SSD 格式化为 ext4 挂载在/dataUbuntu 20.04.1 LTSJuiceFS 版本1.1.0-beta12023-06-08.5ef17ba0被测引擎版本Redis 7.0.9、MySQL 8.0.25、PostgreSQL 15.3、TiKV 6.5.3、etcd 3.3.25、FoundationDB 6.3.23。其中 Redis 有两列结果Redis-Always和Redis-Everysec对应 AOF 的appendfsync配置取always或everysec。这个区别直接决定你怎么读整份报告everysec每秒 fsync写入性能更好但可能丢失最后一秒的写入文档原文提示这属于“性能提升但牺牲一点数据可靠性”always每次写都 fsync更保守是可靠性优先的基准线。文档同时指出Redis 和 MySQL 在本测试中只保存一个本地副本而 TiKV 和 etcd 通过 Raft 协议在三台主机上保存三个副本。也就是说TiKV/etcd 的延迟数字是带着三副本复制开销测出来的对比时要意识到两者的高可用代价不同。解读 Golang Benchmark 表纯元数据操作延迟这张表来自源码内的简单基准测试pkg/meta/benchmarks_test.go直接度量单个元数据操作在引擎侧的耗时是“纯元数据操作”层面的数据。读表规则单位是us/op微秒/次操作越小越好括号里的数字是相对于 Redis-Always 的倍数例如mkdir行中 MySQL 的2042 (3.7)表示约 2042 us是 Redis-Always 用时的 3.7 倍read相关行全部为 0小于 1us文档明确说明因为启用了元数据缓存这些结果目前不可比不要据此下结论。挑几行有代表性的看以下数值均引自文档操作Redis-AlwaysRedis-EverysecMySQLTiKVetcdmkdir558468 (0.8)2042 (3.7)1237 (2.2)1916 (3.4)create570455 (0.8)1570 (2.8)1209 (2.1)1849 (3.2)lookup173178 (1.0)557 (3.2)608 (3.5)1054 (6.1)getattr8786 (1.0)530 (6.1)306 (3.5)536 (6.2)readdir_1k14901547 (1.0)18779 (12.6)5834 (3.9)15809 (10.6)write553369 (0.7)2352 (4.3)1573 (2.8)1788 (3.2)能读出的规律常规操作mkdir、create、rename、unlink上MySQL 大约是 Redis 的 3 倍多TiKV 大约 2 倍etcd 大约 3 倍多与文档结论“MySQL 约为 Redis 的 2~4 倍、TiKV 与 MySQL 相近且多数场景略低、etcd 约为 TiKV 的 1.5 倍”一致批量读目录时差距急剧拉开readdir_1k读 1000 个条目的目录MySQL 是 Redis 的 12.6 倍、etcd 10.6 倍只有 TiKV 压到 3.9 倍如果你的业务大量扫大目录这张表里这一行比 mkdir/create 更值得参考getattr、access这类纯读操作上 MySQL 差距最大约 6 倍因为读操作没有写入路径上的优化空间。解读 JuiceFS Bench 表端到端的小文件吞吐第二张表来自juicefs bench命令官方命令为./juicefs bench /mnt/jfs -p 44 并发它经过 FUSE 层走完整链路度量的是整机端到端能力单位是 files/s、MiB/s 或 ms/op。项目Redis-AlwaysRedis-EverysecMySQLTiKVetcdWrite big file730.84 MiB/s731.93 MiB/s729.00 MiB/s730.01 MiB/s746.07 MiB/sRead big file923.98 MiB/s892.99 MiB/s905.93 MiB/s918.19 MiB/s939.63 MiB/sWrite small file95.20 files/s109.10 files/s82.30 files/s101.20 files/s95.80 files/sRead small file1242.80 files/s937.30 files/s752.40 files/s681.50 files/s1229.10 files/sStat file12313.80 files/s11989.50 files/s3583.10 files/s4211.20 files/s2836.60 files/sFUSE operation0.41 ms/op0.40 ms/op0.46 ms/op0.41 ms/op0.41 ms/opUpdate meta2.45 ms/op1.76 ms/op2.46 ms/op3.76 ms/op3.40 ms/op这张表的读法是分两半看大文件读写四列几乎一样729~746 MiB/s 写、892~940 MiB/s 读。原因是大 I/O 场景下对象存储成为瓶颈元数据引擎的差别被掩盖了。所以不能用这张表说明“某个引擎适合大文件”——它说明的是引擎不影响大文件。元数据密集项差异明显Stat file上 Redis约 12314 files/s是 MySQL约 3583的 3 倍多、etcd约 2837的 4 倍多Update meta上 TiKV3.76 ms/op和 etcd3.40 ms/op反而高于 Redis-Always2.45 ms/op与三副本复制开销的说明相符。解读 mdtest 表多客户端并发的元数据 IOPS第三张表用 mdtest版本 3.3.0在 3 台客户端节点上并行压测myhost主机文件内容为client1 slots4/client2 slots4/client3 slots4测试命令为# metadata only mpirun --use-hwthread-cpus --allow-run-as-root -np 12 --hostfile myhost --map-by slot /root/mdtest -b 3 -z 1 -I 100 -u -d /mnt/jfs # 12000 * 100KiB files mpirun --use-hwthread-cpus --allow-run-as-root -np 12 --hostfile myhost --map-by slot /root/mdtest -F -w 102400 -I 1000 -z 0 -u -d /mnt/jfsmdtest 表的单位是ops/sec越大越好。选几行看项目Redis-AlwaysRedis-EverysecMySQLTiKVetcdDirectory stat空文件组289992.466379692.5769359.27849465.2236500.178File stat空文件组288951.216253218.5589135.57150432.6586276.787File creation空文件组5472.6289984.8241326.6134053.6101801.956File read100KiB 小文件组62341.56857998.3984639.57123376.7335477.754File removal空文件组6084.79112221.0831073.0633742.2691648.734解读要点stat 类操作上 Redis 领先一到两个数量级约 29 万 ops/s 对 MySQL 的约 9 千这是纯元数据压力下的上限差距创建约 12000 个 100KiB 小文件时各引擎明显收敛263~312 files/s 量级这与文档结论“小 I/O约 100 KiB负载下MySQL 总耗时约为 Redis 的 1~3 倍TiKV 与 etcd 表现接近 MySQL”对应空文件组的Tree removal里 Redis-Always218.535显著高于 Redis-Everysec95.599和直觉相反说明单行数据不能脱离具体负载泛化只能当该特定场景的参考。fio 部分4 MiB 块、4G 顺序写fio --namebig-write --directory/mnt/jfs --rwwrite --refill_buffers --bs4M --size4G --numjobs4 --end_fsync1 --group_reporting各引擎写入带宽都在 729~768 MiB/s文档结论是大 I/O约 4 MiB负载下不同元数据引擎没有显著差异对象存储成为瓶颈。把三张表合成选型判断三张表回答的问题不同合成起来的判断逻辑是负载是纯元数据操作或大量小文件引擎选择影响最大。Redis 明显最快TiKV 次之约为 Redis 的 2 倍延迟且带三副本MySQL 约为 Redis 的 2~4 倍etcd 约为 TiKV 的 1.5 倍stat 密集型下与 MySQL 差距最大。负载以约 100 KiB 级别小文件读写为主引擎间差距缩小到 1~3 倍MySQL/TiKV/etcd 接近。负载以大文件顺序读写为主引擎选择不影响吞吐对象存储是瓶颈此时应转去看 Performance Evaluation Guide 里的对象存储侧测试juicefs objbench和 Redis 的可靠性配置。可靠性与副本Redis 和 MySQL 在测试里是单副本TiKV 和 etcd 是三副本 Raft。如果选型本身就要解决元数据高可用TiKV/etcd 的延迟数字是含副本开销的“真实代价”Redis 想降低丢失窗口则需要评估appendfsync从everysec换回always带来的延迟上升。容量规划选型时同步估算元数据存储空间。按 How to Set Up Metadata Engine 给出的近似值键值类引擎Redis、TiKV约 300 字节/文件关系型引擎MySQL、PostgreSQL 等约 600 字节/文件文件平均大于 64MB、碎片多、扩展属性多或文件名平均超过 50 字节时还需要更多空间。注意文档给出的结论边界这些倍数关系来自上述特定硬件与版本组合文档没有承诺其他规模或引擎版本下保持同样的倍数选型前建议按下一节在目标环境复测。在自己的环境复测验证选型结论是否成立文档没有要求完全复刻 3 节点 mdtest 集群最低成本的复测路径是juicefs bench用候选引擎分别format出文件系统并挂载。各引擎的 META-URL 格式见 How to Set Up Metadata Engine例如# Redis juicefs format --storage s3 ... redis://:mypassword192.168.1.6:6379/1 pics # TiKV juicefs format --storage s3 ... tikv://192.168.1.6:2379,192.168.1.7:2379,192.168.1.8:2379/jfs pics # etcd juicefs format etcd://user:password192.168.1.6:2379,192.168.1.7:2379,192.168.1.8:2379/jfs pics # MySQL juicefs format --storage s3 ... mysql://user:mypassword(192.168.1.6:3306)/juicefs pics其中 IP、密码、前缀需替换为你自己的值--storage s3 ...代表对象存储相关参数按实际填写。JuiceFS v1.0 默认开启 Trash基准测试会创建并删除临时文件最终落入.trash目录占用空间。测试前可用juicefs config META-URL --trash-days 0关闭 Trash测试完按需恢复该命令修改的是该文件系统的 Trash 保留天数配置。挂载到/mnt/jfs后执行juicefs bench /mnt/jfs -p 4文档建议-p设为服务器 CPU 核数。结果表格中VALUE为每秒处理能力COST为单文件/单操作耗时。判断标准对照官方表的量级而不是精确数值——如果你的环境里各候选引擎在Stat file、Update meta上的相对差距与官方表Redis 领先数倍、大文件各项接近方向一致说明官方倍数结论在你的环境成立若差距远小于官方数据优先怀疑网络、客户端规格或元数据主机磁盘与官方测试条件不一致。如果你的负载包含大量空目录/小文件创建再按文档中的 mdtest 命令mpirun ... /root/mdtest ...补充多客户端并发测试命令以文档为准/root/mdtest是文档中 mdtest 可执行文件的位置。限制该基准基于 JuiceFS 1.1.0-beta12023-06-08 及特定引擎版本文档未提供其他版本组合的结果golang benchmark 中read类行因元数据缓存不可比不要引用为读性能依据Redis 的两列结果对应不同的appendfsync设置比较时必须固定其中一列否则把可靠性差异误读为引擎差异大文件吞吐的引擎间差异不显著是“对象存储成为瓶颈”的结论不代表元数据引擎可以忽略——stat、小文件创建等元数据密集路径上引擎差异依然存在。【免费下载链接】juicefsJuiceFS is a distributed POSIX file system built on top of Redis and S3.项目地址: https://gitcode.com/GitHub_Trending/ju/juicefs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考