文件系统是我们常见的存储形式,内部主要由数据和元数据两部分组成。其中数据是文件的具体内容,通常会直接展现给用户;而元数据是描述数据的数据,用来记录文件属性、目录结构、数据存储位置等。一般来说,元数据有非常鲜明的特点,即占用空间较小,但访问非常频繁。
当今的分布式文件系统中,有的(如 S3FS)会将元数据和数据统一管理,以简化系统设计,不过这样的弊端是某些元数据操作会让用户感受到明显的卡顿,如 ls
大目录,重命名大文件等。更多的文件系统会选择将这两者分开管理,并根据元数据的特点进行针对性优化。JuiceFS 采用的就是这种设计,其架构图如下:
其中,元数据引擎需要是能够支持事务操作的数据库,而数据引擎一般是用对象存储。目前为止,JuiceFS 已经支持 10 种以上元数据引擎和 30 种以上数据引擎。
用户在使用 JuiceFS 时可以*地选择成熟组件来充当这两个引擎,以应对丰富多变的企业环境和数据存储需求。然而对于新用户来说,当面对更多选择时,也带来了一个问题:在我的场景中究竟选择哪一款数据库作为元数据引擎比较合适?这篇文章将从产品设计角度,为大家介绍 JuiceFS 可使用的元数据引擎类型,以及他们的优劣势。
01-JuiceFS 元数据引擎类型
JuiceFS 现在支持的元数据引擎总共有有三大类。
第一个是 Redis。Redis 是 JuiceFS 开源后最早支持的元数据引擎。首先 Redis 速度够快,这是元数据引擎需要具备的重要能力之一;其次,Redis 受众面广,大部分用户对 Redis 都有实践经验。JuiceFS 对兼容 Redis 协议的数据库也都实现了支持,比如 KeyDB、Amazon MemoryDB 等。
然而,Redis 的可靠性和扩展性容易受限,在一些数据安全性要求较高或规模较大的场景中表现乏善可陈,因此我们又开发支持了另外两类引擎。
第二个是 SQL 类。如 MySQL、MariaDB、PostgreSQL 等,它们的特点是流行度较高,且通常具有不错的可靠性与扩展性。另外,还支持了嵌入式数据库 SQLite。
最后一个是 TKV(Transactional Key-Value Database)类。它们的原生接口比较简单,因此在 JuiceFS 中的定制性更好,相较于 SQL 类一般也能有更高的性能。目前这一类支持的有 TiKV、etcd 和嵌入式的 BadgerDB 等,对 FoundationDB 的支持也在紧锣密鼓地开发中。
以上是根据 JuiceFS 在对接数据库时的协议接口进行的分类。每个大类里面有各种不同的数据库,每种数据库又有其自身的特点,以下根据这些特点对用户常用的几个选项进行比较。
元数据引擎比较
Redis | MySQL/PostgreSQL | TiKV | etcd | SQLite/BadgerDB | |
---|---|---|---|---|---|
性能 | 高 | 低 | 中 | 低 | 中 |
扩展性 | 低 | 中 | 高 | 低 | 低 |
可靠性 | 低 | 高 | 高 | 高 | 中 |
可用性 | 中 | 高 | 高 | 高 | 低 |
流行度 | 高 | 高 | 中 | 高 | 中 |
如上文中提到的,Redis 的最大优势是性能高,因为它是全内存的数据库。其他几方面它就表现平平。
从扩展性上说,通常单机 Redis 可以支持 1 亿文件左右,超过 1 亿时,Redis 单进程的内存使用量会比较大,管理性能上也会有所下降。开源版 Redis 支持以集群模式来扩展其可管理的数据总量,但由于集群模式下 Redis 并不支持分布式事务,因此作为 JuiceFS 元数据引擎时,每个 JuiceFS volume 能用的 Redis 进程还是只有一个,单 volume 的扩展性相较于单机 Redis 并没有太大提升。
从可靠性来看,Redis 默认每秒将数据刷盘,在异常时可能导致小部分数据丢失。通过将配置 appendfsync 改为 always,可以让 Redis 在每个写请求后都刷盘,这样数据可靠性能提高,但是性能却会下降。
从可用性来说,部署 Redis 哨兵监控节点和备用节点,可以在主 Redis 节点挂掉后选择一个备份节点来重新提供服务,一定程度上提高可用性。然而,Redis 本身并不支持分布式的一致性协议,其备用节点采用的是异步备份,所以虽然新的节点起来了,但是中间可能会有数据差,导致新起来的数据并不是那么的完整。
MySQL 和 PostgreSQL 的整体表现比较类似。它们都是经过大量用户多年时间验证过的数据库产品,可靠性和可用性都不错,流行度也很高。只是相较于其余元数据引擎,它们的性能一般。
TiKV 原本是 PingCAP TiDB 的底层存储,现在已经分离出来,成为一个独立的 KV 数据库组件。从我们的测试结果来看,它用来作为 JuiceFS 的元数据引擎是一个非常出色的选择。其本身就有不弱于 MySQL 的数据可靠性和服务可用性,而且在性能与扩展性上表现更好。只是在流行度上,它和 MySQL 还有差距。从我们与用户交流来看,如果他们已经是 TiKV 或 TiDB 的用户,那最后通常都会偏向使用 TiKV 来做 JuiceFS 的元数据引擎。但如果他们之前对 TiKV 并不熟悉,那要再接受这样一个新的组件就会慎重许多。
etcd 是另一个 TKV 类的数据库。支持 etcd 的原因是因为它在容器化场景中流行度非常高,基本上 k8s 都是用 etcd 来管理它的配置。使用 etcd 作为 JuiceFS 的元数据引擎,并不是一个特别适配的场景。一方面是它的性能一般,另一方面是它有容量限制(默认 2G,最大 8G),之后就难以扩容。但是它的可靠性和可用性都非常高,而且容器化场景中也很容易部署,因此如果用户只需要一个规模在百万文件级别的文件系统,etcd 依然是一个不错的选择。
最后是 SQLite 和 BadgerDB,它们分别属于 SQL 类和 TKV 类,但使用起来体验却非常类似,因为它们都是单机版的嵌入式数据库。这类数据库的特点是性能中等,但扩展性和可用性都比较差,因为其数据其实就存放在本地系统中。它们的优势在于非常易用,只需要 JuiceFS 自己的二进制文件,不需要任何额外组件。用户在某些特定场景或者进行一些简单功能测试时,可以使用这两个数据库。
02- 典型引擎的性能测试结果
我们做过一些典型引擎的性能测试,并将其结果记录在这个文档中。其中一份从源码接口处测试的最直接结果大致为:Redis > TiKV(3 副本)> MySQL(本地)~= etcd(3 副本),具体如下:
Redis-Always | Redis-Everysec | TiKV | MySQL | etcd | |
---|---|---|---|---|---|
mkdir | 600 | 471 (0.8) | 1614 (2.7) | 2121 (3.5) | 2203 (3.7) |
mvdir | 878 | 756 (0.9) | 1854 (2.1) | 3372 (3.8) | 3000 (3.4) |
rmdir | 785 | 673 (0.9) | 2097 (2.7) | 3065 (3.9) | 3634 (4.6) |
readdir_10 | 302 | 303 (1.0) | 1232 (4.1) | 1011 (3.3) | 2171 (7.2) |
readdir_1k | 1668 | 1838 (1.1) | 6682 (4.0) | 16824 (10.1) | 17470 (10.5) |
mknod | 584 | 498 (0.9) | 1561 (2.7) | 2117 (3.6) | 2232 (3.8) |
create | 591 | 468 (0.8) | 1565 (2.6) | 2120 (3.6) | 2206 (3.7) |
rename | 860 | 736 (0.9) | 1799 (2.1) | 3391 (3.9) | 2941 (3.4) |
unlink | 709 | 580 (0.8) | 1881 (2.7) | 3052 (4.3) | 3080 (4.3) |
lookup | 99 | 97 (1.0) | 731 (7.4) | 423 (4.3) | 1286 (13.0) |
getattr | 91 | 89 (1.0) | 371 (4.1) | 343 (3.8) | 661 (7.3) |
setattr | 501 | 357 (0.7) | 1358 (2.7) | 1258 (2.5) | 1480 (3.0) |
access | 90 | 89 (1.0) | 370 (4.1) | 348 (3.9) | 646 (7.2) |
setxattr | 404 | 270 (0.7) | 1116 (2.8) | 1152 (2.9) | 757 (1.9) |
getxattr | 91 | 89 (1.0) | 365 (4.0) | 298 (3.3) | 655 (7.2) |
removexattr | 219 | 95 (0.4) | 1554 (7.1) | 882 (4.0) | 1461 (6.7) |
listxattr_1 | 88 | 88 (1.0) | 374 (4.2) | 312 (3.5) | 658 (7.5) |
listxattr_10 | 94 | 91 (1.0) | 390 (4.1) | 397 (4.2) | 694 (7.4) |
link | 605 | 461 (0.8) | 1627 (2.7) | 2436 (4.0) | 2237 (3.7) |
symlink | 602 | 465 (0.8) | 1633 (2.7) | 2394 (4.0) | 2244 (3.7) |
write | 613 | 371 (0.6) | 1905 (3.1) | 2565 (4.2) | 2350 (3.8) |
read_1 | 0 | 0 (0.0) | 0 (0.0) | 0 (0.0) | 0 (0.0) |
read_10 | 0 | 0 (0.0) | 0 (0.0) | 0 (0.0) | 0 (0.0) |
- 上表中记录的是每一个操作的耗时,数值越小越好;括号内数字是该指标对比 Redis-always 的倍数,数值也是越小越好
- Always 和 Everysec 是 Redis 配置项 appendfsync 的可选值,分别表示每个请求都刷盘和每秒刷一次盘
- 可以看到,Redis 在使用 everysec 的时候,性能更好,但与 always 相差的并不大;这是因为测试用的 AWS 机器上的本地 SSD 盘本身 IOPS 性能就比较高
- TiKV 和 etcd 都使用了三副本,而 MySQL 是单机部署的。即使这样,TiKV 的性能表现还是高于 MySQL,而 etcd 与 MySQL 接近。
值得一提的是,上文中的测试使用的都是默认配置,并没有对各个元数据引擎去做特定的调优。用户在使用时可以根据自己的需求和实践经验进行配置调整,可能会有不一样的结果。
另一份测试是通过 JuiceFS 自带的 bench 工具跑的,其运行的是操作系统读写文件的接口,具体结果如下:
Redis-Always | Redis-Everysec | TiKV | MySQL | etcd | |
---|---|---|---|---|---|
Write big file | 565.07 MiB/s | 556.92 MiB/s | 553.58 MiB/s | 557.93 MiB/s | 542.93 MiB/s |
Read big file | 664.82 MiB/s | 652.18 MiB/s | 679.07 MiB/s | 673.55 MiB/s | 672.91 MiB/s |
Write small file | 102.30 files/s | 105.80 files/s | 95.00 files/s | 87.20 files/s | 95.75 files/s |
Read small file | 2200.30 files/s | 1894.45 files/s | 1394.90 files/s | 1360.85 files/s | 1017.30 files/s |
Stat file | 11607.40 files/s | 15032.90 files/s | 3283.20 files/s | 5470.05 files/s | 2827.80 files/s |
FUSE operation | 0.41 ms/op | 0.42 ms/op | 0.45 ms/op | 0.46 ms/op | 0.42 ms/op |
Update meta | 3.63 ms/op | 3.19 ms/op | 7.04 ms/op | 8.91 ms/op | 4.46 ms/op |
从上表可以看到,读写大文件时使用不同的元数据引擎最后性能是差不多的。这是因为此时性能瓶颈主要在对象存储的数据读写上,元数据引擎之间虽然时延有点差异,但是放到整个业务读写的消耗上,这点差异几乎可以忽略不计。当然,如果对象存储变得非常快(比如都用本地全闪部署),那么元数据引擎的性能差异可能又会体现出来。另外,对于一些纯元数据操作(比如 ls,创建空文件等),不同元数据引擎的性能差别也会表现的比较明显。
03-引擎选型的考虑要素
根据上文介绍的各引擎特点,用户可以根据自己的情况去选择合适的引擎。以下简单分享下我们在做推荐时会建议用户考虑的几个要素。
评估需求:比如想使用 Redis,需要先评估能否接受少量的数据丢失,短期的服务中断等。如果是存储一些临时数据或者中间数据的场景,那么用 Redis 确实是不错的选择,因为它性能够好,即使有少量的数据丢失,也不会造成很大的影响。但如果是要存储一些关键数据, Redis 就不适用了。另外还得评估预期数据的规模,如果在 1 亿文件左右, Redis 可以承受;如果预期会有 10 亿文件,那么显然单机 Redis 是难以承载的。
评估硬件:比如能否连通外网,是使用托管的云服务,还是在自己机房内私有部署。如果是私有部署,需要评估是否有足够的硬件资源去部署一些相关的组件。无论是用哪一种元数据引擎,基本上都要求有高速的 SSD 盘去运行,不然会对其性能有比较大的影响。
评估运维能力,这是很多人会忽视的,但是在我们来看这应该是最关键的因素之一。对于存储系统来说,稳定性往往才是其上生产后的第一重点。用户在选择元数据引擎的时候,应该先想想自己对它是不是熟悉,在出现问题时,能否快速定位解决;团队内是否有足够的经验或精力去把控好这个组件。通常来说,我们会建议用户在开始时选择一个自己熟悉的数据库是比较合适的。如果运维人员不足,那么选择 JuiceFS 公有云服务也确实是个省心的选项。
最后,分享下社区在使用元数据引擎方面的一些统计数据。
- 目前为止, Redis 的使用者依然占了一半以上,其次是 TiKV 和 MySQL,这两类的使用者的数量占比在逐步增长。
- 在运行的 Redis 集群的最大文件数大概是在 1.5 亿,而且运行情况是比较稳定的,上文提到的推荐的 1 亿文件是建议值,并不是说无法超过 1 亿。
- 整体数量规模 Top3,都是使用的 TiKV 而且都超过了 10 亿文件数量。现在最大的文件系统的文件数量是超了 70 亿文件,总容量超过了 15 PiB,这也从侧面证明了 TiKV 在作为元数据引擎时的扩展能力。我们自己内部测过使用 TiKV 作为元数据引擎存储 100 亿文件,系统仍能稳定地运行。所以如果你的整个集群预期的规模会非常大,那么TiKV 确实是一个很好的选择。
04- 元数引擎迁移
文章的最后,为大家介绍元数据引擎迁移。 随着用户业务的发展,企业对元数据引擎的需求会发生变化,当用户发现现有的元数据引擎不合适了,可以考虑将元数据迁移到另一个引擎中。 我们为用户提供了完整的迁移方法,具体可以参考这个文档。
这个迁移方法有一定的限制,首先只能迁移到空数据库,暂时无法将两个文件系统直接合在一起;其次,需要停写,因为数据量会比较大的情况下,很难在线将元数据完整的迁移过来。要做到这点需要加许多限制,从实测来看速度会非常慢。因此,把整个文件系统停掉再去做迁移是最稳妥的。如果说实在需要有一定的服务提供,可以保留只读挂载,用户读数据并不会影响整个元数据引擎迁移的动作。
虽然社区提供了全套的迁移方法,但是还是需要提醒用户,尽量提前对数据量的增长做好规划,尽量不做迁移或尽早迁移。当要迁移的数据规模很大时,耗时也会变长,期间出问题的概率也会变大。
如有帮助的话欢迎关注我们项目 Juicedata/JuiceFS 哟! (0ᴗ0✿)