文件系统是我们常见的存储形式，内部主要由数据和元数据两部分组成 。其中数据是文件的具体内容，通常会直接展现给用户；而元数据是描述数据的数据，用来记录文件属性、目录结构、数据存储位置等 。一般来说，元数据有非常鲜明的特点，即占用空间较小，但访问非常频繁 。
当今的分布式文件系统中，有的（如 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 在每个写请求后都刷盘，这样数据可靠性能提高，但是性能却会下降 。
经验总结扩展阅读
- 原神元能尖碑都在哪些地方
- 碧蓝航线核心数据怎么得
- 元素地牢全人物解锁方法
- 可控硅的关断方法
- 原神主角怎么换元素
- Docker | 容器数据卷详解
- 如何优雅的备份MySQL数据？看这篇文章就够了
- 开心消消乐重新安装数据会恢复吗
- 大数据技术之HBase原理与实战归纳分享-上
- 移动免费宽带要什么条件