多流技术：不同寿命数据存在SSD的不同块

【概要】

根据数据的寿命将数据存放在SSD的不同块内可以显著提高SSD的GC效率、减少WAF、提高SSD的寿命和性能。多流技术（Multi-stream technology）可以设置数据放置策略从而减少WAF和数据碎片。本文提出了FileStream，利用聚类算法学习文件特征从而给文件分配数据流，使得相似寿命的数据存放在SSD的同一块内。最后作者测试了六个不同的benchmark，和baseline和两个自动流管理技术相比，分别平均减少了写放大34.5%和21.6%。

【背景与相关工作】

1. 多流技术

用户可以在写请求中传递一个hint（流ID，Stream ID），流ID不同的数据会被放在SSD的不同的地方（如不同的块内）。所以当主机根据数据的寿命分配不同的流ID时，寿命不同的数据将被分开存放，从而提高GC效率。

目前，NVMe已经添加了多流技术，而Linux 4.13内核也增加了“write lifetime hints”来携带流ID。同时，多流技术不仅仅可以用于多流SSD，还可以用于其他设备如OpenChannel SSD、Zoned Namespace SSD。

2. 流ID分配的相关工作

手动分流

在应用的代码中实现一个固定的流分配策略（基于文件类型和一些内部的机制）。缺点是无法适应多样的工作集和应对工作集的特征的改变。同时，把这些策略应用在生产中成本略高，因为需要修改应用代码或者内核代码。

表1 手动分流的相关论文

自动分流

不依赖于具体应用进行流分配。如下表，现存的自动分流策略无法直接用在某些通用的工作集中，而且比不过手动分流。

表2 各种自动分流策略一览

表3 自动分流的相关论文

FileStream——基于文件特征实现自动分流

1）动态适应多样的工作集

2）在Linux用户态实现，除了传递stream ID之外，不会影响应用和内核。

文件特征分析

只附加写的文件（Append-only File）

这类文件只会顺序写入，不允许修改旧数据，更新的数据会写入一个新文件，如日志结构的文件（例如RocksDB和Cassandra的写前日志和数据文件，它们使用LSM树进行管理）。

文件中的数据寿命很难通过LBA的访问次数得出。一个文件的数据的LBA可能不连续，而且数据可能被其他文件覆写。

文件中的数据的寿命和文件的类型有关，如下图，数据文件有多个等级（L0~L3），低等级的文件在合并入高等级文件后会被删除，所以它们的寿命更短。然而，文件的等级只能通过修改应用代码获得，所以这种分流思路只能适用于手动分流。

不过，从图中可以得到两个信息：

① 这类文件从创建到结束写入的时间很短，而且同时正写入的文件很少，而同一文件的数据的寿命通常类似。同时，根据经验，不同时间使用同一流ID写入SSD的数据通常不会写入同一块。

② 写前日志的寿命比数据文件短，不同类型文件的寿命不同。

综上，可以通过文件类型区分文件中的数据寿命。

图1 RocksDB 文件的操作

就地更新的文件（In-place Update File）

这类文件允许随机写，允许文件内更新数据，如关系数据库中的数据文件（例如MySQL和PostgreSQL中的表文件）。这类文件的存在时间通常比较长，它们随着表的创建和删除而创建或删除。

若对一个LBA的写很频繁，意味着大部分写入这个LBA的数据寿命较短。下图显示了同一个表文件中LBA的访问频率相似，而不同表文件中LBA的访问频率不同。为了从文件的角度看待LBA的访问频率，作者提出USM（unit-size-modification）——文件被修改的次数比上文件的大小。对于这类文件，可以通过USM区分文件中的数据寿命。

图2 在MySQL和PostgreSQL中的数据写入

【方法】

1. Mapper：初分流

因为append-only文件从打开到结束写入的时间很短，所以有必要在文件一打开就决定文件中数据的流ID，而此时我们并没有很多文件的修改信息。FileStream的设计思路为，最小化同一流内不同寿命的文件的写入量。设具有同一个父路径和扩展的文件为同类文件。

对于选定时刻的选定流内的选定文件fi将来要写入的数据量的计算方式如下：

设m(fi)是fi每秒的修改量，cd(fi)是fi的当前已持续写入的时间，wd(fi)是fi这类文件平均写持续时间，amount(fi)是fi将来要写入的数据量。则：

对于fi和新打开的文件fo之间的寿命差异计算如下：

设Fi是和fi同类型的文件，Ni是这类文件的数量，l(fa)是Fi中的文件的寿命。Fo、No和l(fb)的定义同理。dif(fi,fo)是fi和fo的寿命差异（最大值为1）。则：

综上，设Fs为流s中正在写入的文件集，对某一流s的评分如下：

在分配时选择评分低的s分配给fo。其中，流编号为1到d。

2. Remapper：再分流

如果一个文件打开了T秒，则启动remapper来根据文件的访问情况分配新的流ID。此时可以认为该文件是就地更新的文件，文件中的数据寿命可以根据USM决定。

作者每T秒启动一个聚类算法（Kmeans++），为这类文件分配编号为d+1到N的流。（N是SSD允许的最大流编号）

3. Devider：决定mapper和remapper映射的流ID区间

divider每T秒调节d的大小。若mapper中处理的文件较多、更新较频繁，则d更大。调节方式如下：

设FNm和FNr分别表示mapper和remapper管理的文件数量，MNm和MNr分别表示它们的文件修改总次数。首先计算一个系数proportion：

随后计算d为：

【实验】

1.实验设置

本文在真实的多流SSD——SAMSUNG PM963 SSD（支持8流）上进行了测试。内核4.13不支持传入流ID信息，所以作者在内核上打了补丁。

实验测试了6个工作集，具体信息如下表：

实验比较了FileStream和四个方案的性能差异：

①baseline：没有多流技术

②AutoStream：根据LBA的访问情况（连续性、更新频次、时间）自动分流

③LKStream：通过相关的数据集的特点（I/O大小、I/O数目和带宽），预测数据的温度来进行分流

④ManualStream：手动分流。数据先根据文件类型区分，然后对于数据文件，根据文件的等级（对于RocksDB和Cassandra）或者更新频次（对于MySQL、PostgreSQL和MongoDB）分流。

T被设置为60s。

2.结果分析

WAF

在几乎所有策略中，FileStream表现最好，甚至比手动分流还要好。和baseline、AutoStream和LKStream相比，FileStream平均减少了WAF34.5%、22.3%和20.8%。Docker是一个混合了多类工作集的复杂工作集，FileStream可以很好地区分不同的数据寿命，所以它的表现比其他策略更好。

Throughput

注：对于MySQL和PostgreSQL，使用每分钟的事务数表示带宽；对于RocksDB、Cassandra、MongoDB，使用每秒钟操作数表示带宽；对于Docker，使用IOPS表示带宽。

FileStream和其他策略相比，带宽明显更高。和AutoStream和LKStream相比，带宽分别平均提高了21.9%和25.8%。因为mapper把append-only文件的数据分到不同的流中，比手动分流分得更加彻底，所以FileStream的带宽更好。

不同模块的分析

图中mapper+remapper表示mapper和remapper平均分配N流，从图中可以看出来，此时并不能达到最优，所以divider是很有必要的。

T的分析

从图可知，60s并没有达到最优，后续或许可以进行动态调整。然而，WAF对T的变化并不敏感。

资源消耗分析

因为聚类只使用USM，所以对CPU的占用只有微弱的提升。同时内存消耗不会超过50MB。

【总结与未来的工作】

FileStream总结

（1）使用mapper，基于流的使用情况和文件类型把新打开的文件分到不同的流中

（2）使用remapper，利用Kmeans++聚类，把文件分到不同类中

实验显示FileStream可以减少WAF、提高带宽。

未来工作

（1）将FileStream扩展到更多的设备上，如Zoned Namespace SSD。

（2）当文件内的数据寿命不一致时，结合文件信息和LBA相关的信息进行进一步决策。

致谢

感谢本次论文解读者，来自华东师范大学的硕士生俞丁翠，主要研究方向为智能存储。