关于云存储:JuiceFS-元数据引擎选型指南

43次阅读

共计 5974 个字符,预计需要花费 15 分钟才能阅读完成。

文件系统是咱们常见的存储模式,外部次要由数据和元数据两局部组成。其中数据是文件的具体内容,通常会间接展示给用户;而元数据是形容数据的数据,用来记录文件属性、目录构造、数据存储地位等。一般来说,元数据有十分显明的特点,即占用空间较小,但拜访十分频繁。

当今的分布式文件系统中,有的(如 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 在对接数据库时的协定接口进行的分类。每个大类外面有各种不同的数据库,每种数据库又有其本身的特点,以下依据这些特点对用户罕用的几个选项进行比拟。

元数据引擎比拟

RedisMySQL/PostgreSQLTiKVetcdSQLite/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-AlwaysRedis-EverysecTiKVMySQLetcd
mkdir600471 (0.8)1614 (2.7)2121 (3.5)2203 (3.7)
mvdir878756 (0.9)1854 (2.1)3372 (3.8)3000 (3.4)
rmdir785673 (0.9)2097 (2.7)3065 (3.9)3634 (4.6)
readdir_10302303 (1.0)1232 (4.1)1011 (3.3)2171 (7.2)
readdir_1k16681838 (1.1)6682 (4.0)16824 (10.1)17470 (10.5)
mknod584498 (0.9)1561 (2.7)2117 (3.6)2232 (3.8)
create591468 (0.8)1565 (2.6)2120 (3.6)2206 (3.7)
rename860736 (0.9)1799 (2.1)3391 (3.9)2941 (3.4)
unlink709580 (0.8)1881 (2.7)3052 (4.3)3080 (4.3)
lookup9997 (1.0)731 (7.4)423 (4.3)1286 (13.0)
getattr9189 (1.0)371 (4.1)343 (3.8)661 (7.3)
setattr501357 (0.7)1358 (2.7)1258 (2.5)1480 (3.0)
access9089 (1.0)370 (4.1)348 (3.9)646 (7.2)
setxattr404270 (0.7)1116 (2.8)1152 (2.9)757 (1.9)
getxattr9189 (1.0)365 (4.0)298 (3.3)655 (7.2)
removexattr21995 (0.4)1554 (7.1)882 (4.0)1461 (6.7)
listxattr_18888 (1.0)374 (4.2)312 (3.5)658 (7.5)
listxattr_109491 (1.0)390 (4.1)397 (4.2)694 (7.4)
link605461 (0.8)1627 (2.7)2436 (4.0)2237 (3.7)
symlink602465 (0.8)1633 (2.7)2394 (4.0)2244 (3.7)
write613371 (0.6)1905 (3.1)2565 (4.2)2350 (3.8)
read_100 (0.0)0 (0.0)0 (0.0)0 (0.0)
read_1000 (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-AlwaysRedis-EverysecTiKVMySQLetcd
Write big file565.07 MiB/s556.92 MiB/s553.58 MiB/s557.93 MiB/s542.93 MiB/s
Read big file664.82 MiB/s652.18 MiB/s679.07 MiB/s673.55 MiB/s672.91 MiB/s
Write small file102.30 files/s105.80 files/s95.00 files/s87.20 files/s95.75 files/s
Read small file2200.30 files/s1894.45 files/s1394.90 files/s1360.85 files/s1017.30 files/s
Stat file11607.40 files/s15032.90 files/s3283.20 files/s5470.05 files/s2827.80 files/s
FUSE operation0.41 ms/op0.42 ms/op0.45 ms/op0.46 ms/op0.42 ms/op
Update meta3.63 ms/op3.19 ms/op7.04 ms/op8.91 ms/op4.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✿)

正文完
 0