JuiceFS 元数据引擎选型指南

文件系统是我们常见的存储形式,内部主要由数据和元数据两部分组成 。其中数据是文件的具体内容,通常会直接展现给用户;而元数据是描述数据的数据 , 用来记录文件属性、目录结构、数据存储位置等 。一般来说,元数据有非常鲜明的特点,即占用空间较?。梦史浅F捣?。
当今的分布式文件系统中,有的(如 S3FS)会将元数据和数据统一管理,以简化系统设计,不过这样的弊端是某些元数据操作会让用户感受到明显的卡顿,如 ls 大目录 , 重命名大文件等 。更多的文件系统会选择将这两者分开管理,并根据元数据的特点进行针对性优化 。JuiceFS 采用的就是这种设计,其架构图如下:

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 的整体表现比较类似 。它们都是经过大量用户多年时间验证过的数据库产品,可靠性和可用性都不错 , 流行度也很高 。只是相较于其余元数据引擎,它们的性能一般 。
【JuiceFS 元数据引擎选型指南】TiKV 原本是 PingCAP TiDB 的底层存储,现在已经分离出来,成为一个独立的 KV 数据库组件 。从我们的测试结果来看,它用来作为 JuiceFS 的元数据引擎是一个非常出色的选择 。其本身就有不弱于 MySQL 的数据可靠性和服务可用性,而且在性能与扩展性上表现更好 。只是在流行度上,它和 MySQL 还有差距 。从我们与用户交流来看 , 如果他们已经是 TiKV 或 TiDB 的用户,那最后通常都会偏向使用 TiKV 来做 JuiceFS 的元数据引擎 。但如果他们之前对 TiKV 并不熟悉,那要再接受这样一个新的组件就会慎重许多 。

推荐阅读