持久内存退场之后：ZNS SSD 与下一代非易失内存

原文发布于 quant67.com，转载请保留出处。

这是【数据库研究前沿】系列的第 18 篇。前两篇讨论了 CXL 内存池化和近数据处理。这一篇处理一个更尴尬的话题：过去十年数据库学术界最热的"持久内存（Persistent Memory, PM）"方向，在 2022 年 7 月 Intel 宣布 Optane 产品线 EOL 后，何去何从？

一个冷静的答案是：三件事同时发生------PM 的理论成果被迁移到新的载体，新硬件 ZNS SSD 接棒"顺序写友好"的生态位，CXL memory 在"容量+可持久化"的维度试图重画边界。这一篇就讲这三件事怎么交叠，以及在 2026 年应该怎么做工程决策。

上半（60%）讲：Optane EOL 的教训、SOFORT / FPTree / RECIPE 这一批 PM 数据库论文的遗产、ZNS SSD（Zoned Namespace）的 FAST 2021 论文 ZNS+ 对 LSM-Tree 的意义、CXL memory 是否能成为新载体。下半（40%）讲：RocksDB 的 ZNS 适配经验、PMDK 兼容层的现状、从"PM 原生"到"persistent-where-you-can"的工程过渡。

版本说明 本文主要参考：Optane 产品线（2018--2022 年 DC Persistent Memory + P5800X）、ZNS SSD（NVMe 2.0 ZNS 规范）、RocksDB 9.x（含 zenfs 插件）、Linux 6.x 对 ZNS 的块层支持、PMDK 1.13（LTS 维护版本）。部分实验数据基于公开论文的实测表格，在 Optane 之后的新硬件上可能需要重新校准。

一、Optane 退场：一个"介质成功、市场失败"的故事

1.1 Optane 做对了什么

Intel 和 Micron 2015 年联合发布的 3D XPoint（商标 Optane）在技术特性上几乎是理想的：

字节寻址（byte-addressable），和 DRAM 一样可以 load / store；
非易失（non-volatile），掉电不丢；
延迟 150--300 ns，约为 DRAM 的 3× 而不是 SSD 的 10⁴×；
DIMM 封装（DC Persistent Memory Module, DCPMM）可以直插内存插槽。

这套特性是"数据库教科书改写机"。过去几十年基于"内存易失 + 存储持久"的所有协议（WAL、checkpoint、group commit、double write buffer）都可以重构，甚至取消。学术界 2016--2022 年围绕 PM 发了上千篇论文。

1.2 Optane 没做对什么

但 2022 年 7 月 Intel 官方宣布 Optane 业务线退出，2025 年停止所有供应。复盘失败的原因：

位成本从未打过 DRAM：DCPMM 每 GB 比 DRAM 贵 30%--50%，而不是便宜。"非易失"这一优势对多数负载不足以弥补；
只有 Intel 一家：没有第二供应商，AMD 平台不支持，云厂商不敢押注；
编程模型太重：PMDK 的 libpmemobj 引入了"持久指针（persistent pointer）"、事务组、flush barrier，真正用好它基本要重写存储引擎；
"一半用法"效果最差：把 PM 当快 SSD（block 模式）或慢 DRAM（Memory Mode）都有更便宜的替代品。

这个结局对数据库工程师的最大教训不是"PM 没用"，而是：任何依赖单一厂商、需要重写大量代码才能收益的硬件，都要当成高风险押注。这条教训后面看 CXL、ZNS 时仍然适用。

值得对照的另一例反面教材是 Intel SGX：同样单一厂商、同样需要应用深度改造、同样在 2020 年前后热度达到顶峰；SGX 目前在 CPU 侧仍然存在（转型为 TDX），但数据库应用的落地比预期少得多（参见 TEE 与机密数据库）。SGX 的迁移路径和 Optane 的迁移路径有很多可复用经验。

1.3 论文遗产：SOFORT、FPTree、RECIPE

Optane 时代留下的不是硬件，是一批依然有启发性的论文。值得记住三篇：

SOFORT （EDBT 2015 / VLDB Journal 2016，Oukid 等）。SOFORT 的核心贡献是"单级存储（Single-Level Store）"的事务模型：不再区分内存堆与磁盘表，所有状态直接存在 PM 里，事务通过"持久日志 + 版本链"实现。日志和 WAL 可以合并，在 PM 上一个 clflush + sfence 就完成了传统 group commit 的工作。

FPTree（SIGMOD 2016，Oukid 等）。FPTree 是一棵"混合 B+Tree"：内部节点在 DRAM、叶子节点在 PM，叶子用 fingerprint + 不排序槽位减少 PM 写入。这个"把指针放在快介质、数据放在慢但持久介质"的混合思路，在 Optane 走后依然适用------只要存在任何"异构内存层级"，就可能用上。

RECIPE（SOSP 2019，Lee 等）。RECIPE 给出一套"把已有的 DRAM 并发索引改造成 PM 版本"的方法学：只要原索引满足特定条件（lock-free 或者 persistence-friendly locking），通过添加 flush 和 fence 即可正确。这篇论文让许多不想从零写 PM 索引的团队受益。

这三篇论文在 Optane EOL 之后并未过时------它们描述的是"字节寻址非易失介质"上的一般工程方法，未来在 CXL memory + battery-backed DRAM、MRAM、ReRAM 上都可能重新适用。

1.4 一个更细节的问题：PM 编程为什么这么难

三篇论文共同指向一件事：在字节寻址非易失介质上写正确的代码，比写正确的事务代码还难。难点不在算法，而在两个底层细节：

持久化边界（durability boundary）不在存储、在 CPU ：store 指令执行后，数据只在 CPU store buffer 里；要到 L1、L2、L3 各级 cache；最后才进 PM 控制器。只有显式执行 clwb+sfence 才真正持久。忘记 fence 的 bug 在软件层几乎不会显现，掉电才会暴露。
崩溃一致性（crash consistency）无法通过单测：只有在"store A 已持久、store B 未持久"的精确瞬间掉电才能触发特定错误。业界的解决方案------PMFuzz、Yat、Witcher 等崩溃一致性测试工具（待核实完整清单），基本都是 2019 年后才成熟。

这两个细节决定了 PM 应用不是"加几个 flush 就行"，而是需要整套正确性工具链。Optane 退场让这套工具链失去了主要硬件目标，但方法学本身在未来新介质上仍然会被需要。

二、ZNS SSD：接过"顺序友好"的接力棒

Optane 退场的同时，另一个硬件形态在 2020 年后快速起势：ZNS SSD（Zoned Namespace SSD）。严格来说 ZNS 和 PM 解决的不是同一个问题，但它接住了 LSM-Tree 数据库的很多工程期待。

2.1 ZNS 要解决的问题：写放大与 GC 冲突

传统 NVMe SSD 在逻辑上暴露平坦地址空间，内部靠 FTL（Flash Translation Layer）把逻辑块映射到物理 NAND，并在后台做 GC。对 LSM-Tree 数据库这是双重浪费：

LSM 在应用层已经做"顺序追加 + compaction"，结果 FTL 又做一遍 GC；
两次 GC 互相不可见，写放大叠加，SSD 寿命折半。

ZNS 规范（NVMe 2.0 TP 4053）引入"分区（zone）"抽象：SSD 把物理空间切成一批 zone（典型 256 MB 一个），每个 zone 内部必须严格顺序写，只能整区重置。FTL 大幅简化，几乎不再做 GC------因为 LSM 已经替它做了。

2.2 ZNS 的 FAST 2021 关键论文

Stavrinos 等 FAST 2021 的 Don't Be a Blockhead: Zoned Namespaces, Key-Value Stores and the Storage Landscape 以及 Bjørling 等 ZNS: Avoiding the Block Interface Tax for Flash-based SSDs（USENIX ATC 2021）给出了关键实测：

在典型 RocksDB 负载下，ZNS SSD 相比传统 SSD：写放大降低 50%--70%，端到端吞吐提升 10%--30%，P99 延迟更稳定；
SSD 侧 DRAM 需求降低 4--8 倍（因为 FTL 映射表变小），单盘制造成本降低；
但对应用侧要求大：文件系统 / 数据库必须改造成"zone-aware"。

2.3 ZNS 对 LSM-Tree 的结构性意义

LSM-Tree 的核心机制是"按层合并"。每层的 SST 是一批只读 + 追加写 + 整文件删除的文件，和 ZNS 的 zone 语义几乎是同构：

一层可以用一个或一批 zone 承载；
compaction 完成后整 zone reset，不需要细粒度删除；
写只发生在 zone 尾部，和 LSM 的顺序追加完全对齐。

在传统 SSD 上，RocksDB 写一个 SST 会经过：文件系统 → FTL → NAND。文件系统可能把 SST 拆成几块、FTL 重新组织、NAND 最终顺序写。中间每一层都可能引入随机性。ZNS 把这一链路拉直：文件系统对 zone 透明映射、FTL 去掉 GC、NAND 按应用层序写。

这是近十年存储软硬件边界罕见的一次"语义对齐"。类似的"语义对齐"在过去还发生过两次：一次是 Linux direct I/O 把"应用自管缓冲"语义和块设备对齐；一次是 io_uring 把"异步批量提交"语义和内核调度对齐。每一次语义对齐都带来 1.5--3× 的性能收益，同时也带来"应用必须理解底层"的复杂度。ZNS 沿着同一条轨迹------便宜的性能红利从不是免费的，它要求应用接受更具体的硬件假设。

2.4 ZNS+ 与后续扩展

ZNS 规范出现之后，学术界持续提出改进方案。ZNS+（FAST 2021，Im 等）提出把 FTL 里残留的"间接写"（比如 inode 更新）也顺序化，进一步降低写放大；随后几年的工作（待核实具体文献）讨论了 zone 动态划分、跨 zone 事务、zone 内并行写等话题。这些都尚未成为 NVMe 主线规范，但决定了 ZNS 在 2027--2030 年的演化方向。对生产团队，关注 NVMe TP（Technical Proposal）发布是最低成本的跟踪方式。

三、RocksDB 的 ZNS 适配：zenfs

3.1 zenfs 是什么

Western Digital 团队给 RocksDB 贡献的 zenfs 是一个轻量级"文件系统实现"------它不是完整 POSIX 文件系统，而是通过 RocksDB 的 FileSystem 抽象暴露给引擎。zenfs 直接和 ZNS 块设备交互，把 SST 文件映射到 zone。

简化的代码路径（示意）：

bash 复制代码

# 编译 RocksDB + zenfs
git clone https://github.com/westerndigitalcorporation/zenfs
cd zenfs && make -C rocksdb db_bench

# 初始化 zenfs（在一块 ZNS 设备上）
./zenfs mkfs --zbd=nvme0n1 --aux_path=/var/lib/rocksdb/aux --force

# 使用 zenfs 跑 db_bench
./db_bench --fs_uri=zenfs://dev:nvme0n1 --benchmarks=fillrandom,overwrite

zenfs 做的关键事情：

把 WAL / SST / Manifest 分配到不同 zone：WAL 单独一批（频繁 reset）、SST 按 level 分组；
按 level 做垃圾回收：低层 compaction 完成后整 zone reset；
避免 write amplification 放大：不再经过通用文件系统（ext4、XFS）的 journal 和 allocator。

3.2 实测经验

根据 WD / Meta 几份公开材料（具体版本 2021--2023），zenfs + RocksDB 对比 ext4 + 普通 NVMe：

写放大：3.5× → 1.3×（接近 LSM 的理论下界）；
吞吐：提升 ~15%；
尾延迟：P99.9 下降 40% 以上（因为没有 FTL GC 卡顿）。

但有几个坑：

不是所有工作负载都收益：读密集、工作集全在 block cache 内的负载，收益接近零；
备份/快照工具链不成熟 ：ZNS 上没有 ext4 的 dump / snapshot，需要走 RocksDB checkpoint 或 backup 层；
容量规划变硬：zone 大小固定（如 256 MB），小文件（manifest、log）浪费明显；
生态依赖：zenfs 基本只对 RocksDB 友好，MySQL / PostgreSQL 直接用 ZNS 仍是开放问题。

3.3 zenfs 的一个配置样板

对准备试点的团队，下面是一个精简但可运行的 RocksDB + zenfs 最小脚本（基于 RocksDB 8.x）的要点：

cpp 复制代码

rocksdb::Options opts;
opts.create_if_missing = true;
opts.level_compaction_dynamic_level_bytes = true;

std::shared_ptr<rocksdb::FileSystem> fs;
rocksdb::FileSystem::Load("zenfs://dev:nvme0n1", &fs);
opts.env = rocksdb::NewCompositeEnv(fs).release();

关键点是通过 FileSystem::Load 从 URI 加载 zenfs 插件，RocksDB 其余代码无需修改。生产使用时还要关注：

auxiliary 目录：zenfs 需要一个常规文件系统路径放 metadata（LOCK、manifest 引用等），不能全部放在 ZNS 上；
容量规划：zone 大小固定，L0 数量、SST target size 建议按 zone 边界对齐；
并发写 ：ZNS 允许同时打开的 zone 数量有上限（通常 14--32），max_background_compactions 不能超过这个限制。

3.4 其它数据库的 ZNS 适配

TerarkDB、ToplingDB：从 RocksDB fork，ZNS 适配和 zenfs 路径类似；
Ceph BlueStore：2022 年前后合入 ZNS 支持，适合对象存储层；
TiKV：有 zenfs + Titan blob storage 的实验项目（待核实当前状态）；
MySQL InnoDB ：原生暂不支持 ZNS。路径上需要先改 fil 层和 redo log，工作量大；
PostgreSQL：heap 的随机更新语义和 zone 顺序写冲突，短期不看好直接 ZNS。

这个名单说明一件事：ZNS 到 2026 年的主要受益者是 LSM-based 系统。行/页式引擎短期难以直接适配。

四、CXL Memory 能否成为下一代持久载体

4.1 CXL 不是非易失的，但可以"工程化非易失"

CXL memory 本身（无论 DDR5 还是未来的 MRAM、STT-RAM、ReRAM 型 CXL 设备）是否非易失，取决于载体。2025 年市面上主流 CXL Type 3 设备是 DDR5 + CXL 控制器，本身易失。但以下几种设计都能让 CXL 区域"表现为"非易失：

电池/超电容备份（battery-backed DRAM, BBRAM）：掉电时将 DRAM 内容刷到板载 NAND。传统服务器上 NVDIMM-N 就是这个思路；
CXL 内存 + 持久控制器：一些早期厂商样品（Samsung CMM-D、Astera Labs 等）有 NV 变种；
新介质的 CXL 封装：MRAM / ReRAM 如果通过 CXL 暴露，会原生非易失，但当前没有主流商用产品。

从数据库角度看，只要"硬件 + 软件"合起来能保证 store-level 持久 ，上层语义就和 Optane 相同。PMDK 的 libpmemobj API 本质是不关心介质的------只要 pmem_persist() 能保证落盘，它就能工作。

4.2 PMDK 的"兼容层"角色

PMDK 2022 年之后进入维护模式（Intel 不再主推）。但社区版本继续存活，被 Linux 发行版（Fedora、Ubuntu）继续打包。对已经用 PMDK 写的项目，PMDK 可以作为"面向 Optane 的代码迁到 CXL 或 NVDIMM 的兼容层"，具体三条路径：

保留 libpmemobj 代码，把后端换成 DAX-enabled CXL 内存：理论可行，但需要硬件确保持久语义；
用 libpmem2 封装，运行时决定持久策略 ：允许同一份代码在有 NVDIMM 时走硬件持久、无 NVDIMM 时走 fsync + mmap 模拟；
只用 PMDK 的 concurrency / allocator 部分 ：例如 libvmem / libvmmalloc 的内存分配器在纯 DRAM 上也是稳定的 NUMA-aware 分配器。

4.3 何时考虑 PMDK 的兼容层

实用判断：

遗留代码库已经在用 PMDK：继续用，直到整体重写；
新项目，目标是 CXL / NVDIMM ：不要再写 PMDK 代码。优先用 OS / 文件系统提供的 DAX + mmap + msync 路径，或选择一个非 PMDK 原生的持久库（比如 RocksDB 自己的 WAL）；
科研复现：如果要复现 SOFORT / FPTree / RECIPE 的结果，PMDK 仍是最近似的实验平台。

4.4 理论上的新组合

一张 2026 年"异构持久层"的典型图景：

复制代码

┌────────────────────────┐
│     应用 / DBMS        │
├────────────────────────┤
│  本地 DRAM   ← 热数据  │ 80--100 ns，易失
│  CXL DRAM    ← 温数据  │ 200--400 ns，易失或 BBRAM
│  ZNS SSD     ← 冷数据  │ 10--80 μs，非易失、顺序友好
│  对象存储    ← 归档    │ 10--100 ms，极冷
└────────────────────────┘

这张图没有 Optane 的位置------因为不再需要。"字节寻址 + 非易失 + DRAM 级延迟"这个三角形中的任意两个，都已有更便宜的替代品：

字节寻址 + DRAM 级延迟 = CXL DRAM（放弃非易失，或靠电池补回来）；
字节寻址 + 非易失 = NVDIMM / BBRAM（小容量）；
非易失 + 高带宽 = ZNS SSD（放弃字节寻址）。

对绝大多数数据库工作负载，上面任意两条的组合都够用。这也是 Optane 在商业上失败的结构性原因。

一个相关的经济判断：硬件创新的成败，很少取决于"它能做什么"，更多取决于"它能便宜到什么程度"。Optane 在技术维度胜过 DRAM，但价格从未低于 DRAM；CXL 在技术维度不如 DDR5 直连，但它的价格曲线跟着 PCIe 的规模生产走。前者是"更好但更贵"，后者是"次好但更便宜"。后者赢下市场是常态而非意外。

4.5 用 CXL 模拟 PM：一套新的编程模型

把"CXL memory + 软件层持久保证"作为 PM 替身，是未来 1--2 年值得关注的工程路径。一种可行的组合：

text 复制代码

应用（DBMS）
   │
   ├─ WAL 写入 CXL 区域（DAX mmap）
   │       │
   │       ├─ CPU clwb + sfence 保证 cache flush
   │       └─ 等待 peer 副本 ACK（跨主机 CXL 3.0 一致性 或 RDMA）
   │
   └─ 周期性 checkpoint 到 ZNS SSD

这套模型的持久性边界由"两个副本 + 跨机器一致性"共同保证：单台 crash 丢失 CXL 易失内容也不影响正确性，因为另一台副本尚持有。语义上等价于 Optane，性能上接近（甚至优于，因为 DDR5 速度快于 Optane）。风险是编程复杂度更高------需要在 CXL 错误、副本失联、时钟偏差上做细致处理。

这不是 2026 年就能大规模部署的方案，但值得架构师在设计新一代存储引擎时把它纳入"未来 3 年可能成为默认"的路径清单。

5.1 如果你还在维护 PM 代码

把 PMDK 依赖封装成一层薄 shim，之后介质换掉时只改 shim；
跑 libpmem2 + DAX on CXL 的回归测试，确认持久语义保持；
放弃"libpmemobj 大事务"的设计，回归到"手写 WAL + 定期 snapshot"------后者移植性远好。

5.2 如果你在做 LSM 引擎

评估 ZNS 盘的试点：从 8 块 pilot 开始，跑 RocksDB + zenfs 做 A/B；
关注工作负载匹配：写密集、compaction 占比高的受益最大；
运维检查：备份、快照、监控一整套工具链是否支持 zone 设备；
和 LSM-Tree 工程实践、RocksDB 实战对照，先把软件层调到最优，再上 ZNS 才能分清到底是谁在提升。

具体 pilot 指标建议至少覆盖以下几项，并和传统 SSD baseline 做 A/B：

Write Amplification Factor (WAF) ：RocksDB 自报告 + SSD 内部 NAND 写放大（通过 nvme-cli 读取）；
Compaction 停顿时长：P99、P99.9；
SSD 寿命指标：剩余寿命百分比、已写入字节数；
端到端 fillrandom / readwhilewriting 吞吐：db_bench 标准负载；
崩溃恢复时间：kill -9 + 重启后到达 consistent 状态的时间。

只有这五项都不劣于 baseline，才值得把 pilot 扩到更大规模。

5.3 如果你在做 B-Tree / 行存引擎

短期（1--2 年）不建议上 ZNS，因为随机更新和顺序写原则冲突。可以：

关注 CXL memory + 扩展 buffer pool 的路径；
在 WAL 层上尝试 ZNS（WAL 天然顺序、适合 zone）；
避免在关键路径上依赖 PM 语义。

5.4 如果你在做新数据库设计

假设你从 2026 年开始写一个新存储引擎，最合理的硬件假设是：

DRAM/CXL：大、分层、易失；
NVMe / ZNS：持久、顺序友好；
对象存储：近乎无限、高延迟。

把"字节寻址持久"从设计假设里拿掉。如果将来 MRAM / ReRAM 通过 CXL 重新登场，再用 shim 层补进来------代价远小于一开始就绑定 PM 语义。

5.5 监控与可观测性

任何新存储硬件的落地都依赖监控。ZNS / CXL-persistent 场景建议至少采集：

Zone 级指标 ：每个 zone 的写入位置、重置次数、错误率（通过 nvme zns 子命令）；
LSM 级指标：每层 SST 数量、compaction 字节数、写放大实测；
设备寿命 ：nvme smart-log 的 Percentage Used、Media and Data Integrity Errors；
崩溃恢复：每次重启到达 consistent 状态的耗时。

没有这些监控，"新硬件提升 15%"这类结论基本无法在生产中复现或证伪。

5.6 和其它主线的关系

与共享内存事务：ZNS 上的 WAL 是"大规模群组提交"的理想载体；
与 CXL 内存池化：CXL 承担易失大容量，ZNS 承担持久大容量，合起来形成新的三层结构；
与近数据处理：zone 天然适合"一个任务一个 zone"的批处理下推；
与仓库已有文章持久内存、SSD NAND 架构、NVMe 协议、WAL 与 ARIES、新硬件综述：基础设施层的补充。

六、从 Optane 代码迁出的实操步骤

很多团队在 2019--2021 年写了 PM 相关代码，现在面临"继续维护还是迁出"的现实选择。下面给出一个相对稳妥的迁出路线。

6.1 风险评估：哪些代码最棘手

使用 libpmemobj 的持久事务：最难迁，因为事务语义深度依赖 PM 语义；
使用 libpmem 的 raw store + flush ：相对容易，可以替换为 mmap + msync 或 WAL；
用 PM 作为 buffer pool 扩展：最容易，直接换成 DRAM 或 CXL 内存即可；
混合索引（DRAM 内部节点 + PM 叶子）：中等难度，叶子部分需要改回 block-based 存储。

6.2 推荐的迁移目标

对于 2026 年的新设计，三种替代方案的选择：

原 PM 用途	建议替代	理由
加速 WAL 写入	本地 NVMe + group commit	NVMe 延迟已足够
持久化索引叶子	LSM / B-tree on NVMe	无字节寻址需求
持久化缓存	DRAM/CXL + 定期 checkpoint	简单直接
跨节点共享持久状态	复制 + quorum 持久	放弃单机字节语义

6.3 代码层的渐进迁移

建议三步走：

先抽出接口 ：把所有 PM 调用封装在一个 PersistentRegion 抽象后，两种实现：PmemRegion（原实现）和 MmapRegion（fsync 模拟）；
回归测试双路运行：同一组测试跑两种实现，确保语义等价；
生产切换 ：默认切到 MmapRegion，保留 PmemRegion 直到所有旧部署下线。

这一过程对一个中等规模的 PM 代码库（10--20 万行）通常需要 3--6 人月。听起来不小，但比起"硬件采购后几年内无货"的风险，早做早安心。

6.4 把迁移结果文档化

Optane 退场是业界 2022 年的一记警钟。把你的迁移经验写出来------哪些代码简单、哪些代码顽固、哪些选择事后证明正确------不仅对自己团队有价值，对社区（以及将来可能再出现的"下一代 Optane"）也是重要参考。数据库行业的集体经验很大程度上来自这类事后复盘。

七、开放问题与长期观察

非易失 CXL 的商业路径：是通过电池备份（NVDIMM-style 上云）、新介质（MRAM、ReRAM），还是软件层模拟（跨副本保证持久）？不同路径对应完全不同的编程模型。
ZNS 与文件系统：f2fs、btrfs（COW 结构）、未来可能的新 FS 如何争夺 ZNS 市场？数据库能否绕过 FS 直接使用 zone？
"非易失性"作为语义而非硬件特性：是否存在一套通用 API，让上层只声明"这段数据要可恢复"，底层根据硬件选择 battery-backed / replication / NVM 中最合适的？
Optane 教训的普适化：单厂商 + 高成本 + 高重写负担，是硬件失败的三因素公式。CXL 也有类似风险（虽然多厂商参与，但初期溢价明显），值得长期盯。

这些问题没有现成答案。本系列会在未来的修订中补充 2026 年 Q3 / Q4 的新进展。

回到本文开头的那个问题："持久内存退场之后，我们处在什么位置？" 一个诚实的回答：处在一个"理论上丰富、产品上分裂、工程上过渡"的阶段。Optane 走了，MRAM / ReRAM 尚未商用成熟，CXL memory 的非易失变种还在路线图上。从现在到下一个"明确替代品"的窗口期，可能要持续 2--4 年。

这不是坏事。真正好的存储架构决策，常常是在"硬件选项受限"的阶段做出的------没有选择余地，反而容易聚焦在真正重要的工程权衡上。Optane 时代的许多 PM 论文因为选项太多而陷入细节纠结；后 Optane 时代的数据库设计，或许正好可以回到"最基本的持久性语义 + 最直接的硬件映射"这种朴素思路上。

参考文献

I. Oukid et al. SOFORT: A Hybrid SCM-DRAM Storage Engine for Fast Data Recovery. DaMoN 2014 / VLDB Journal 2016.
I. Oukid et al. FPTree: A Hybrid SCM-DRAM Persistent and Concurrent B-Tree for Storage Class Memory . SIGMOD 2016. dl.acm.org/doi/10.1145...
S. K. Lee et al. Recipe: Converting Concurrent DRAM Indexes to Persistent-Memory Indexes . SOSP 2019. dl.acm.org/doi/10.1145...
M. Bjørling et al. ZNS: Avoiding the Block Interface Tax for Flash-based SSDs . USENIX ATC 2021. www.usenix.org/conference/...
N. Stavrinos et al. Don't Be a Blockhead: Zoned Namespaces, Key-Value Stores and the Storage Landscape. FAST 2021.（待核实具体标题与作者列表）
J. Yang et al. An Empirical Guide to the Behavior and Use of Scalable Persistent Memory . FAST 2020. www.usenix.org/conference/...
Intel. Optane Persistent Memory: Product Brief & EOL Announcement . 2022. www.intel.com/content/www...
Western Digital. ZenFS: A RocksDB FileSystem Plugin for Zoned Storage . github.com/westerndigi...
NVM Express. Zoned Namespace Command Set, NVMe 2.0 . 2021. nvmexpress.org/specificati...
PMDK. Persistent Memory Development Kit Documentation . pmem.io/pmdk/

上一篇 ：【数据库研究前沿】近数据处理与计算下推：Smart SSD 到 DPU Offload

下一篇 ：【数据库研究前沿】可信执行环境与机密数据库