何为异构内存存储引擎？

听说了吗？美光最近向其开源社区发布了异构内存存储引擎 (HSE)。这项设计焦点在于精心打造一种解决方案，显著提升存储类内存 (SCM) 与固态硬盘 (SSD) 性能，并通过有效降低写入放大效应，延长固态硬盘的实际使用寿命，同时还能实现大规模部署。相较于传统的存储引擎，HSE 在处理如 Yahoo! 云服务基准测试 (YCSB) 等工作负载时，往往能够展现出数倍的性能优势。

何为异构内存存储引擎 (HSE)？

为何是异构的？ 美光凭借其广泛的 DRAM、SCM 及SSD 产品组合，积累了深厚的行业洞察与专业知识，能够构建一种跨不同内存与存储介质类型智能管理数据放置的存储引擎。与专门针对机械硬盘编写的传统存储引擎不同，HSE 在设计之初便明确地将重点放在如何利用 SCM 和 SSD 的高吞吐量和低延迟特性上。

实施

HSE 利用不同离散介质类型的优势，支持两种数据存储介质类别：一种是“暂存”介质类，另一种是“容量”介质类。暂存介质类通常配置为在高性能（IOPS 和/或 MB/s）、低延迟和高写入耐用度介质（例如，SCM 或采用 NVMe™ 的数据中心类 SSD）上运行。用于短期访问的热数据被分配给暂存介质类，而长期保存的冷数据通常配置为在容量介质类层中的低成本、低写入耐用度介质（如四层单元 (QLC) SSD）上运行。这使得 HSE 能够同时实现高吞吐量和低延迟，并在低耐用度介质上减少写入周期。

可配置耐久性层

HSE 耐久性层是用户可配置的逻辑架构，部署在暂存介质类上。耐久性层实现用户可定义的数据持久性，其中用户可指定在系统故障（如断电）的情况下可能丢失数据的毫秒数上限。

最初将数据从动态随机存取存储器 (DRAM) 传送到耐久性层中。存储从速度更快的暂存介质类分配，以满足耐久性层的低延迟、高吞吐量要求。与传统的预写式日志 (WAL) 不同，这种耐久性层避免了典型日志记录常见的“双重写入问题”，从而大大降低了写入放大。

数据老化

随着存储数据的老化，数据会通过系统的多个层进行迁移，并在垃圾收集过程中被重写，以优化查询性能（完成时间）。以下是概略流程：

当需要存储新数据时，首先将其写入耐久性层。

随着数据的逐渐老化，系统会将其作为后台维护操作，将数据重新写入到容量介质类。

当新数据到来后，新数据可能会使现有数据过时（通过更新或删除之前写入的记录）。维护操作定期扫描现有数据，以实现空间回收。如果大部分数据现在无效或过时，这些操作通过仅重写仍然有效的数据来回收空间，从而释放旧数据占用的所有空间（即垃圾收集）。为了有效地服务查询，还会排列整理有效数据，以便轻松扫描。

有效数据被重新组织成多个层级，加快了查询处理的速度。在整个过程中，键值数据被隔离到单独的数据流中 —— 键数据被写入暂存媒体类，以方便快速查找。最终，底层的旧数据被写入指定的容量介质类设备。

在处理查询请求并从两个介质类中读取数据时，索引会以页面为单位被缓存到 DRAM 中。假设系统 DRAM 可用，LRU（最近使用最少）算法对索引进行动态排序，以方便索引跟踪，从而将最热的数据（即最频繁访问的索引）固定在内存中。

介质类性能

我们的测试设置使用一个采用 NVMe™ 技术的美光 9300 SSD 作为暂存介质类设备，四个美光 5210 SATA QLC SSD 作为容量介质类设备。另外，使用 Yahoo!® 云服务基准测试 (YCSB) 比较每秒操作数和 99.9% 的尾延迟：

• 首次运行：四个美光 5210 QLC SSD 配置为容量介质类设备
• 第二次运行：四个 5210 SSD 配置为容量介质类设备，一个采用 NVMe 技术的美光 9300 SSD 配置为暂存介质类设备

在两种配置下，我们使用相同的线程数运行了 YCSB 的 A、B、C、D、F 这五个工作负载¹。表 1 概述了 YCSB 的几种工作负载组合，其中应用示例取自 YCSB 文档。表 2 至表 4 列出了有关硬件、软件和基准配置的其他测试详情。

1. 未测试工作负载 E，因为其未获得普遍支持

2. 不同的配置可能会显示不同的结果。

吞吐量

YCSB 从加载数据库开始。这是一个 100% 的插入工作负载。添加 9300 后，加载 2TB 数据库所需的时间缩短至原来的四分之一。

图 1 显示了五个 YCSB 工作负载加载阶段和运行阶段的吞吐量。对于工作负载 A（50% 更新）和工作负载 F（50% 插入）等写入密集型工作负载，添加美光 9300 作为暂存介质类将总体吞吐量分别提高 2.3 和 2.1 倍。工作负载 B 和 D（5% 更新/插入）的吞吐量提升幅度较小，因为这些工作负载中 95% 的读取操作几乎完全来自构成容量介质类的 5210 SSD。

延迟

图 2 显示了 99.9% 的读取（尾）延迟。添加 9300 后，所有工作负载的读取尾延迟都有极大改善（2 到 3 倍）（除了 100% 为读取操作的工作负载 C 之外）。回想一下，新到的写入数据首先由 9300 处理，随着数据的老化，在后台逐渐写入到 5210 中。键数据（索引）被写入到 9300 中，使第二种配置的查找速度更快。部分读取由 9300 而不是 5210 处理（取决于查询分布和被读取数据的老化程度）。

此外，通过减轻对 5210 的写入负担，甚至减少了同时进行中的写入对 5210 处理的读取所受到的争用，从而进一步降低了尾延迟，由于两种配置在运行阶段的插入/更新延迟相似，因此未在图中显示。

写入字节数

最后，我们测量了在执行每个工作负载的过程中写入 5210 的数据量。添加 9300 作为暂存介质类可减少写入 5210 的字节数，从而保持写入周期并延长 5210 的写入寿命。在负载（仅插入阶段）期间，写入 5210 的字节数减少了 2.4 倍，如表 5 所示。

图 3 显示了 YCSB 工作负载在运行阶段写入的千兆字节总数。请注意，这既包括用户写入，也包括后台写入。除工作负载 C（100% 读取）外，其他工作负载显示，在配置中添加一个 9300 后，写入 5210 的字节总数至少减少了两倍。

未来工作

在未来工作规划中，我们希望拓宽 HSE API 的特定功能领域，以提高其使用率，例如为应用程序提供更多控制权的自定义介质类策略。举例而言，如果应用程序创建了一个仅用于编制索引的键值存储（KVS，相当于关系数据库中的表格），则其可以指定特定的 KVS 应使用暂存介质类来加快查找速度。如果索引 KVS 占用的内存过大，暂存设备无法容纳，则应用程序可以指定一个策略，使用暂存介质，但回退到容量介质。我们还可能引入预定义的介质类策略模板，并扩展 HSE API，使应用程序可以根据自身需要使用这些模板。请务必与我们保持联系，以了解潜在的发展动态。