如果你还没有听说，美光最近发布了它的 异构内存存储引擎 致开源社区. 我们的设计重点是提供一个解决方案，使存储类内存(SCM)和ssd性能更高, 通过减少写放大，增加了SSD的有效寿命, 所有这些都被大规模部署. 与传统存储引擎相比，HSE通常有利于雅虎等工作负载! 云服务基准测试(YCSB)多次.
什么是“异构内存”存储引擎(HSE)?
为什么异构? 美光拥有广泛的动态随机存取记忆体沙巴体育结算平台组合, SCM和ssd为我们提供了构建存储引擎的洞察力和专业知识，可以智能地管理跨不同内存和存储介质类型的数据放置. 与为硬盘驱动器编写的传统存储引擎不同, HSE的设计初衷是利用SCM和ssd的高吞吐量和低延迟.
实现
HSE利用离散介质类型的优势，支持两种介质类型进行数据存储:“分级”介质类和“容量”介质类. 登台媒体类通常配置为在高性能(IOPS和/或MB/s)上运行。, 低延迟和高写入持久性介质(例如, SCM或数据中心级ssd(带NVMe™). 热备数据, 短期访问在冷时分配给暂存媒体类, 长期数据通常被配置为以较低的成本运行, 容量介质类层中的较低写入持久性介质(如四级单元[QLC] ssd). 这使得HSE能够实现高吞吐量和低延迟，同时还可以节省低耐久性介质上的写入周期.
可配置的持久性层
HSE持久性层是驻留在暂存媒体类上的用户可配置逻辑构造. 持久性层提供用户可定义的数据持久性，其中用户可以指定在系统故障时可能丢失多少毫秒数据的上限, 比如功率损失.
数据最初从动态随机存取记忆体摄取到持久性层. 存储从更快的暂存媒体类分配，以满足低延迟, 耐久性层的高吞吐量要求. 与传统的预写日志(WAL)不同, 这个持久性层避免了传统日志中常见的“双重写入问题”，从而显著减少了写入放大.
数据老化
随着存储数据的增长, 数据在系统的多个层之间迁移，并作为垃圾收集的一部分进行重写，以优化查询性能(完成时间)。. 以下是高级流程:
- 当需要存储新数据时，首先将其写入持久性层.
- 随着数据的老化，它被重写为容量媒体类，作为后台维护操作.
- 当新数据到达时, 新数据可能使现有数据过时(通过更新或删除以前写入的记录). 维护操作定期扫描现有数据，进行空间回收. 如果大部分数据现在无效或过时, 这些操作通过重写仍然有效的数据来回收空间——释放旧数据占用的所有空间.e.、垃圾收集). 为了有效地服务查询，还安排了有效数据，以便可以轻松扫描.
- 有效的数据被重新组织到层中，以便更快地处理查询. 在整个过程中，键和值数据被隔离到单独的流中——键被写入暂存媒体类以促进更快的查找. 最后，底层的旧数据被写入指定容量的媒体类设备.
在处理查询和从两个媒体类读取数据时，索引被页面缓存到动态随机存取记忆体中. LRU(最近最少使用)算法对索引进行动态排序，以方便索引跟踪, 夹住最热的(i).e.(访问最频繁的索引)，假设系统动态随机存取记忆体可用.
媒体课表演
我们的测试设置使用了一个 带NVMe的美光9300固态硬盘作为分期媒体类设备和四个微米 5210 SATA QLC ssd盘 作为容量介质类设备. 我们使用 雅虎!®云服务基准(YCSB) 来比较每秒操作数和99.9%尾部延迟:
- 首次运行:配置为容量媒体类设备的4个微米 5210 QLC ssd
- 第二次运行:4块5210 SSD配置为容量媒体类设备，1块带NVMe的微米 9300 SSD配置为暂存媒体类设备
我们跑 YCSB工作负载A、B、C、D和F 两种配置的线程数相同.1 表1总结了几种YCSB工作负载组合, 应用程序示例取自YCSB文档. 表2到表4分享了沙巴体育安卓版下载硬件的其他测试细节, 软件和基准配置.
表1:工作负载
| YCSB工作量 | I / O操作 |
应用实例 |
|---|---|---|
| A | 50%读 50%的更新 |
会话存储记录用户会话活动 |
| B | 95%读 5%的更新 |
照片标记 |
| C | 100%读 |
用户配置文件缓存 |
| D | 95%读 5%的插入 |
用户状态更新 |
| F | 50%读 50%读-修改-写 |
用户数据库或记录用户活动 |
1 没有测试工作负载E，因为它没有得到普遍支持
表2:硬件细节
| 服务器平台 | |
|---|---|
| 服务器平台 | 服务器平台 基于Intel®(双插槽) |
| 处理器 |
2 Intel E5-2690 v4 |
| 内存 |
256 gb DDR4 |
| ssd |
暂存级介质:1x带NVMe的美光9300 SSD 容量级介质:4倍微米 5210.68TB SATA ssd |
| 介质配置 |
LVM分条逻辑卷 |
表3:软件细节
| 软件详细信息 | |
|---|---|
| 操作系统 | Red Hat Enterprise Linux 8.1 |
| HSE版本 |
1.7.0 |
| RocksDB版本 |
6.6.4 |
| YCSB版本 |
0.17.0 |
表4:基准2
| YCSB基准配置 | |
|---|---|
| 数据集 | 2TB(20亿个1000字节记录) |
| 客户端线程 |
96 |
| 操作 |
每个工作负载20亿美元 |
2 不同的配置可能显示不同的结果.
吞吐量
YCSB首先加载数据库. 这是一个100%的插入工作负载. 将9300添加到组合中可以将加载2TB数据库所需的时间减少四倍.
图1显示了五个YCSB工作负载的负载阶段和运行阶段的吞吐量. 对于写密集型工作负载，如工作负载A(50%更新)和工作负载F(50%插入), 添加微米 9300作为登台媒体类可以提高总体吞吐量2.3和2.分别为1次. 工作负载B和D(5%的更新/插入)在吞吐量方面的改善较为温和，因为这些工作负载中95%的读取几乎完全来自包含容量媒体类的5210块ssd.
图1:YCSB工作负载的吞吐量
延迟
图2显示了99.9%的读(尾)延迟. 添加9300后，除工作负载C外，所有工作负载的读尾延迟都得到了显著改善(2 ~ 3倍), 也就是100%读取). 回想一下，新到达的写操作首先被9300吸收，然后随着数据的增长在后台逐渐写入5210. 关键数据(索引)被写入9300，使得在第二个配置中查找更快. 一小部分读取由9300而不是5210提供服务(取决于正在读取的数据的查询分布和年龄)。.
另外, 通过减少对5210的写入次数, 即使是由5210提供服务的读也较少受到正在进行的写的争用, 所以尾部读延迟更低. 插入/更新延迟没有被描绘出来，因为它们在运行阶段的两种配置中是相似的.
图2:YCSB工作负载的延迟
字节写
最后, 我们测量了在执行每个工作负载的过程中写入5210的数据量. 添加9300作为暂存媒体类可以减少写入5210的字节数, 保持写周期并延长5210的写寿命. 在加载(仅插入阶段)期间, 写入5210的字节数减少了1 / 2.4，见表5.
表5:写减少
| 字节写 | ||
|---|---|---|
| 配置 | 4x 5210 | 9300 + 4x 5210 |
| GB写入5210(容量介质) |
7,260 |
2,978 |
| GB写入9300(暂存介质) |
N/A |
4,158 |
图3显示了在YCSB工作负载运行阶段写入的gb总数. 注意，这包括用户和后台写入. 除了工作负载C(100%读取), 其他工作负载显示，通过向配置中添加一个9300，写入5210的总字节数至少减少了两倍.
图3:写入数据的减少
未来的工作
作为未来工作的一部分, 我们正在寻求扩大HSE API的具体方面，以提高其使用, 比如自定义媒体类策略，它赋予应用程序更多的控制权. 例如, 如果应用程序创建了键值存储(KVS), (相当于关系数据库中的表)，仅用于索引, 它可以指定特定的KVS应该使用暂存媒体类来加速查找. 如果索引KVS的大小变得太大而无法在staging设备上容纳, 应用程序可以指定使用暂存媒体但退回到容量媒体的策略. 我们还可以引入预定义的媒体类策略模板，并扩展HSE API，以允许应用程序根据需要使用它们. 一定要保持联系，了解潜在的发展.
