RocksDB 与 ZenFS:原理、特性及在科研与工程中的应用初步探索

1、RocksDB 是什么?

RocksDB 是一个高性能的嵌入式键值数据库引擎,由 Facebook 开发,基于 Google 的 LevelDB 改进而来,专为高吞吐量、低延迟的存储场景设计。

  • 一个库(library),而不是独立的数据库服务(不像 MySQL)。
  • 被广泛用于日志存储、消息队列、区块链、搜索引擎、分布式存储系统等。
  • 使用 LSM-tree 结构优化写入,支持压缩、多个列族(column families)、事务等高级功能。

📌 总结一句话:

RocksDB 是一个嵌入式的数据库库,不依赖特定文件系统,数据会存储在你当前系统的 ext4、XFS 或 NTFS 等文件系统上;但要使用它,你需要自己安装并在代码中集成它。

2.、ZenFS 是什么?

🔷 ZenFS 是一个为 ZNS SSD 设计的用户态文件系统,专门服务于 RocksDB。


🌟 它的特点如下:

特性 描述
目标设备 只支持 ZNS SSD(Zoned Namespace)设备
部署方式 作为 RocksDB 的文件系统插件(通过 Env 接口)使用
写入模型 严格顺序写入,遵循 ZNS 的 zone 规则
区管理 管理 zone 的打开、关闭、reset、回收等操作
优势 减少写放大、提高顺序写入效率、延长 SSD 寿命

ZenFS 的唯一目标就是为 RocksDB 管理它的数据文件。不是一个通用文件系统!

✳️ 它只管理以下 RocksDB 文件:

  • SST 文件(主要的数据文件)
  • WAL 日志文件
  • Manifest 文件
  • 临时文件 / 压缩中间文件

ZenFS 并不是一个能被操作系统 mount 上的文件系统,比如你不能用 ls /mnt/zenfs 去访问它。它只在 RocksDB 内部"私有使用"。

3、QA1:RocksDB 是一个库,库里自带 ZenFS 吗?

不是,RocksDB 默认不包含 ZenFS。

✳️ 更具体解释如下:

  • RocksDB 是一个数据库引擎,它是一个 C++ 编写的开源库。
  • 默认情况下,RocksDB 使用的是 操作系统的普通文件系统接口(比如 ext4、XFS、NTFS)。
  • ZenFS 是一个额外的用户态文件系统插件 ,需要 你单独安装和集成 到 RocksDB 中,RocksDB 并不自带。

🔧 如果要使用 ZenFS:

你需要:

  1. 安装 RocksDB(从源码编译或库)
  2. 安装 ZenFS(Facebook 开源的插件,也在 GitHub)
  3. 把 ZenFS 通过 Env 接口注册到 RocksDB(比如运行时加参数 --env=zenfs

4、QA2:什么是"嵌入式数据库"?RocksDB 是嵌入到哪里?

🔷 ✅ 不是嵌入到系统,而是嵌入到你的应用程序里

"嵌入式数据库"指的是:

  • 它不像 MySQL、PostgreSQL 那样是一个独立的服务进程(你要先运行它,然后连接)。
  • 它是一个 库(library),像其他 C++/Java 库一样,你在你的代码中直接调用它的接口。
  • 数据库的生命周期完全由你的应用程序控制,而不是由系统管理

🌰 举个现实例子(工程开发):

假设你写一个搜索引擎模块:

cpp 复制代码
cpp复制编辑#include <rocksdb/db.h>

int main() {
    rocksdb::DB* db;
    rocksdb::Options options;
    options.create_if_missing = true;

    // 打开一个 RocksDB 数据库(这里路径是 ./mydata)
    rocksdb::Status s = rocksdb::DB::Open(options, "./mydata", &db);

    // 插入数据
    db->Put(rocksdb::WriteOptions(), "key1", "value1");

    // 查询数据
    std::string value;
    db->Get(rocksdb::ReadOptions(), "key1", &value);

    delete db;
    return 0;
}

你可以看到,RocksDB 是通过 #include 方式嵌入到程序里使用的。没有启动服务、没有连接数据库,一切都在你自己的程序里运行!

5、QA3: 为什么嵌入式数据库还需要 ZenFS?

默认情况下:

  • RocksDB 把数据写到 ext4、XFS 这些标准系统文件。
  • 但是这些文件系统不适合顺序写(比如 ZNS SSD 的 Zone Append 要求)。

这时候,ZenFS 就相当于帮 RocksDB 换了一个"文件写入后端",专门为 ZNS SSD 优化。

6、QA4:现实科研/工程中 RocksDB + ZenFS 是怎么一起用的?

🧪 举个科研例子:你在研究一块新型压缩写 SSD(比如 CCZNS)

  1. 你写了一个 ZNS SSD 的压缩增强模型(可能在 QEMU 中模拟,或者用 real ZNS SSD)。
  2. 为了测试实际性能,你选用 RocksDB 作为真实工作负载生成器
  3. 你部署 ZenFS 插件,让 RocksDB 可以顺利写入 ZNS SSD。
  4. 运行 db_bench,分析压缩写对:
    • 写放大(write amplification)
    • 吞吐(throughput)
    • 延迟(latency)
    • zone 使用率
      的影响。

这样你就有一整套上下贯通的实验平台。

✅ 小结:你现在应该清晰看到三层结构

角色 现实中是什么
应用层 你的系统模块 / benchmark 调用 RocksDB 接口(嵌入式用法)
存储引擎 RocksDB 嵌入到应用中,调用 ZenFS
文件后端 ZenFS 为 RocksDB 提供 ZNS SSD 顺序写接口
硬件 ZNS SSD / CCZNS SSD 模拟或真实设备

应用层就是你自己写的程序,或者系统中的其他模块,它需要用 RocksDB 来保存和查询数据。

📌 举几个具体的现实例子:

📍 工程场景:
  • 搜索引擎子模块:用 RocksDB 存储索引或缓存(比如 Elasticsearch 中可能使用类似 KV 引擎)。
  • 区块链节点程序:比特币核心(Bitcoin Core)就用 RocksDB 存储链数据。
  • 推荐系统/广告服务:在线系统中用 RocksDB 存储用户画像、点击日志等。
  • 嵌入式设备:比如 IoT 网关、边缘计算设备中使用 RocksDB 存储本地配置、历史数据。

你写的这些程序就叫"应用层"。


📍 科研场景:
  • 你写一个用来评估 CCZNS 的实验驱动程序
    • 比如一个 workload replay 工具。
    • 或者直接用 RocksDB 自带的 benchmark 工具 db_bench
    • 甚至你写个 Python → C++ 调用 RocksDB 的测试框架,也属于"应用层"。

这些实验程序,也都是应用层,它们负责调用 RocksDB 接口、触发实际存储行为。

✅ 总结一句:

RocksDB 是一个"写程序时直接用的数据库引擎",你像用字符串库一样把它放到自己系统中,用来保存和读取数据。而 ZenFS 是它的"专属硬盘写入助手",让 RocksDB 能在 ZNS SSD 上高效工作。

✅ 科研流程图:

复制代码
你写的应用层(比如 db_bench)
          ↓
调用 RocksDB 接口(嵌入式库)
          ↓
使用 ZenFS 作为文件系统插件
          ↓
ZenFS 接口调用 CCZNS 模拟器
(这里模拟 CW / DR)
          ↓
底层 ZNS SSD / 模拟器