如果你还没有听说，美光最近发布了它的 异构内存存储引擎 to the open source community. 我们的设计重点是提供一个解决方案，使存储类内存(SCM)和ssd性能更高, 通过减少写放大，增加了SSD的有效寿命, 所有这些都被大规模部署. 与传统存储引擎相比，HSE通常有利于Yahoo等工作负载! 云服务基准测试(YCSB)多次.
什么是“异构内存”存储引擎(HSE)?
Why heterogeneous? 美光拥有广泛的DRAM沙巴体育结算平台组合, SCM和ssd为我们提供了构建存储引擎的洞察力和专业知识，可以智能地管理跨不同内存和存储介质类型的数据放置. 与为硬盘驱动器编写的传统存储引擎不同, HSE的设计初衷是利用SCM和ssd的高吞吐量和低延迟.
Implementation
HSE利用离散介质类型的优势，支持两种介质类型进行数据存储:“分级”介质类和“容量”介质类. 登台媒体类通常配置为在高性能(IOPS和/或MB/s)上运行。, 低延迟和高写入持久性介质(例如, SCM或数据中心级ssd(带NVMe™). Data intended for hot, 短期访问在冷时分配给暂存媒体类, 长期数据通常被配置为以较低的成本运行, 容量介质类层中的较低写入持久性介质(如四级单元[QLC] ssd). 这使得HSE能够实现高吞吐量和低延迟，同时还可以节省低耐久性介质上的写入周期.
Configurable Durability Layer
HSE持久性层是驻留在暂存媒体类上的用户可配置逻辑构造. 持久性层提供用户可定义的数据持久性，其中用户可以指定在系统故障时可能丢失多少毫秒数据的上限, like power loss.
数据最初从DRAM摄取到持久性层. 存储从更快的暂存媒体类分配，以满足低延迟, 耐久性层的高吞吐量要求. 与传统的预写日志(WAL)不同, 这个持久性层避免了传统日志中常见的“双重写入问题”，从而显著减少了写入放大.
Data Aging
As stored data ages, 数据在系统的多个层之间迁移，并作为垃圾收集的一部分进行重写，以优化查询性能(完成时间)。. Here’s the high-level process:
- 当需要存储新数据时，首先将其写入持久性层.
- 随着数据的老化，它被重写为容量媒体类，作为后台维护操作.
- As new data arrives, 新数据可能使现有数据过时(通过更新或删除以前写入的记录). 维护操作定期扫描现有数据，进行空间回收. 如果大部分数据现在无效或过时, 这些操作通过重写仍然有效的数据来回收空间——释放旧数据占用的所有空间.e., garbage collection). 为了有效地服务查询，还安排了有效数据，以便可以轻松扫描.
- 有效的数据被重新组织到层中，以便更快地处理查询. 在整个过程中，键和值数据被隔离到单独的流中——键被写入暂存媒体类以促进更快的查找. 最后，底层的旧数据被写入指定容量的媒体类设备.
在处理查询和从两个媒体类读取数据时，索引被页面缓存到DRAM中. LRU(最近最少使用)算法对索引进行动态排序，以方便索引跟踪, pinning the hottest (i.e.(访问最频繁的索引)，假设系统DRAM可用.
Media Class Performance
Our test setup used one Micron 9300 SSD with NVMe作为分期媒体类设备和四个Micron 5210 SATA QLC SSDs as the capacity media class devices. We used the Yahoo!® Cloud Serving Benchmark (YCSB) 来比较每秒操作数和99.9% tail latencies:
- 首次运行:配置为容量媒体类设备的4个Micron 5210 QLC ssd
- 第二次运行:4块5210 SSD配置为容量媒体类设备，1块带NVMe的Micron 9300 SSD配置为暂存媒体类设备
We ran YCSB workloads A, B, C, D and F 两种配置的线程数相同.1 表1总结了几种YCSB工作负载组合, 应用程序示例取自YCSB文档. 表2到表4分享了沙巴体育安卓版下载硬件的其他测试细节, 软件和基准配置.
Table 1: Workloads
| YCSB Workload | I/O Operations |
Application Example |
|---|---|---|
| A | 50% Read 50% Update |
会话存储记录用户会话活动 |
| B | 95% Read 5% Update |
Photo tagging |
| C | 100% Read |
User profile cache |
| D | 95% Read 5% Insert |
User status updates |
| F | 50% Read 50% Read-Modify-Write |
用户数据库或记录用户活动 |
1 没有测试工作负载E，因为它没有得到普遍支持
Table 2: Hardware Details
| Server Platforms | |
|---|---|
| Server Platforms | Server Platform Intel® based (dual-socket) |
| Processors |
2x Intel E5-2690 v4 |
| Memory |
256GB DDR4 |
| SSDs |
暂存级介质:1x带NVMe的美光9300 SSD 容量级介质:4倍Micron 5210.68TB SATA SSDs |
| Capacity Class Media Configuration |
LVM striped logical volume |
Table 3: Software Details
| Software Details | |
|---|---|
| Operating System | Red Hat Enterprise Linux 8.1 |
| HSE Version |
1.7.0 |
| RocksDB Version |
6.6.4 |
| YCSB Version |
0.17.0 |
Table 4: Benchmark2
| YCSB Benchmark Configuration | |
|---|---|
| Dataset | 2TB (2 billion 1,000-byte records) |
| Client Threads |
96 |
| Operations |
2 billion per workload |
2 不同的配置可能显示不同的结果.
Throughput
YCSB starts by loading the database. This is a 100% insert workload. 将9300添加到组合中可以将加载2TB数据库所需的时间减少四倍.
图1显示了五个YCSB工作负载的负载阶段和运行阶段的吞吐量. 对于写密集型工作负载，如工作负载A(50%更新)和工作负载F(50%插入), 添加Micron 9300作为登台媒体类可以提高总体吞吐量2.3 and 2.1 times, respectively. 工作负载B和D(5%的更新/插入)在吞吐量方面的改善较为温和，因为这些工作负载中95%的读取几乎完全来自包含容量媒体类的5210块ssd.
图1:YCSB工作负载的吞吐量
Latencies
Figure 2 shows the 99.9% read (tail) latencies. 添加9300后，除工作负载C外，所有工作负载的读尾延迟都得到了显著改善(2 ~ 3倍), which is 100% reads). 回想一下，新到达的写操作首先被9300吸收，然后随着数据的增长在后台逐渐写入5210. 关键数据(索引)被写入9300，使得在第二个配置中查找更快. 一小部分读取由9300而不是5210提供服务(取决于正在读取的数据的查询分布和年龄)。.
Additionally, 通过减少对5210的写入次数, 即使是由5210提供服务的读也较少受到正在进行的写的争用, so tail read latencies are lower. 插入/更新延迟没有被描绘出来，因为它们在运行阶段的两种配置中是相似的.
图2:YCSB工作负载的延迟
Bytes Written
Finally, 我们测量了在执行每个工作负载的过程中写入5210的数据量. 添加9300作为暂存媒体类可以减少写入5210的字节数, 保持写周期并延长5210的写寿命. During the load (insert-only phase), 写入5210的字节数减少了1 / 2.4 as seen in Table 5.
Table 5: Write Reduction
| Bytes Written | ||
|---|---|---|
| Configuration | 4x 5210 | 9300 + 4x 5210 |
| GB写入5210(容量介质) |
7,260 |
2,978 |
| GB written to 9300 (staging media) |
N/A |
4,158 |
图3显示了在YCSB工作负载运行阶段写入的gb总数. 注意，这包括用户和后台写入. 除了工作负载C(100%读取), 其他工作负载显示，通过向配置中添加一个9300，写入5210的总字节数至少减少了两倍.
图3:写入数据的减少
Future Work
As part of future work, 我们正在寻求扩大HSE API的具体方面，以提高其使用, 比如自定义媒体类策略，它赋予应用程序更多的控制权. For example, 如果应用程序创建了键值存储(KVS), (相当于关系数据库中的表)，仅用于索引, 它可以指定特定的KVS应该使用暂存媒体类来加速查找. 如果索引KVS的大小变得太大而无法在staging设备上容纳, 应用程序可以指定使用暂存媒体但退回到容量媒体的策略. 我们还可以引入预定义的媒体类策略模板，并扩展HSE API，以允许应用程序根据需要使用它们. 一定要保持联系，了解潜在的发展.
