StripeMerge: Efficient Wide-Stripe Generation for Large-Scale Erasure-Coded Storage
0.Abstract
极限存储-宽条带 带宽开销巨大
StripeMerge 宽条带生成机制
将窄条带变成宽条带，这个过程中是为了最小化宽条带生成带宽
本文工作证明了最优方案的存在，还有两个启发式算法，生成时间减小87.8%
1.INTRODUCTION
为了保证data durability提出复制，但是冗余开销太大
RS是一种替代方案，冗余开销很低，但是现在还在追求更低的存储开销
宽条带
极端的存储冗余
more on low-cost storage durability than high data access performance
重构的时候，带宽消耗很严重
应该根据年龄不同，做不同的参数化，分层处理
数据块在新写入时往往被访问得更频繁，但随着它们的年龄变得更少
随着数据的老化，窄条带被重新编码为宽条带
将窄条带重新编码为宽条带不可避免地会重新定位数据块并重新生成校验块，从而导致数据传输中巨大的带宽开销
主要观点
宽条带的生成发生在有大量节点和条带的大型存储系统
选择两个窄条带合并成一个
StripeMerge
2.BACKGROUND ANDMOTIVATION
A Erasure Coding
讲了纠删码的概念，MDS码
B Wide-Stripe Generation
宽条带的概念
假设
宽条带用于很少被访问的冷数据，比如备份和归档数据[1]、[6]或二进制大对象(blob)，它们的访问频率随着时间的推移而下降
宽条带有较高的修复代价，随着k增大而增大
宽条带生成问题
宽条带生成步骤（两个窄条带生成一个宽条带）
重新分配2k块，分布在不同的节点
将两个窄条带的一些数据和校验块迁移到一些负责生成宽条带的新校验块的节点上，它们的奇偶校验块稍后分布在不同的节点上。
数据块的重新分布，从窄条带重新生成校验块，存在明显的数据传输
目标最小化带宽
C Storage Scaling
增加新节点扩容，为了在现有和新增加的节点上重新分配擦除编码块，他们研究了如何将(k,m)条转换为(k+s,m)条，以最小化伸缩带宽(即伸缩期间传输的数据量)
NCScale的扩展方法
此时宽条带生成带宽依旧不为0，宽条带与存储扩展有所不同的是它不需要增加新的节点，这种差异导致它有不同的解决方案。
D Our Idea
Perfect merging
从当前存储的大量窄条带中，选择两条合适的窄条带，用来合并为宽条带，不需要生成带宽
例子如下
b和a的区别在于c ，d在单独的节点，并不需要再迁移，这个地方不消耗带宽
图示的两个条带有这样的特点，用来消除宽条带生成带宽
数据块在不同的节点
因为宽条带最后数据块分布在不同的节点，如果有在相同节点的，那么会导致数据块迁移到其他节点，有带宽开销
校验块有相同的编码系数，并驻留在相同的节点，这些可以用来生成新的校验块
例子如下
由上面两个式子可以看出来，新的校验块可以通过之前的校验块本地生成，不产生带宽消耗
Challenges：Perfect merging不产生带宽开销，但是如何在系统中应用Perfect merging生成多个宽条带。并且Perfect merging跟窄条带的放置方式有关。大规模存储系统中，搜索所有的窄条带会消耗大量时间。
3.ANALYSIS
SectionIII-A 我们将宽条带生成问题转换为bipartite graph model
SectionIII-B 证明在给定足够多的窄条带的情况下，总是存在一个可以生成所有宽条带而不需要任何宽条带生成带宽的最优方案。
A Bipartite Graph Model
n个节点，足够多的(k,m)narrow stripes，目标是选择所有符合Perfect merging的窄条带，合并成(2k,m)的宽条带，这样就不存在跨节点的生成带宽
（k,m）条带，随机分布在k+m节点上
总共排列方案，假设是每个都不同。但是实际上我们合并的时候，数据块顺序无所谓（我们计算的时候只用了校验块），校验块的顺序是重要的，对计算产生影响（主要是前面的系数）
这种被认为是同一种摆放方式。
所以总共可能性如上，被称为complete chunk placement set。
提出了 bipartite graph
为什么x和y之间的节点连接起来就是完美匹配？
B Existence
证明perfect merging的存在
证明没看懂
4.STRIPEMERGE
A Limitations of Optimal Scheme
带宽问题，转化为二部图的最大匹配问题
最大匹配算法时间复杂度高，形成一个二部图在时间和空间上都是昂贵的，并且实际中，块数不一定一样，不一定能形成完美匹配。
B Greedy Heuristic: StripeMerge-G
利用现有窄条纹的完美合并来生成尽可能多的宽条纹，而对于剩余的窄条纹，我们转移一些块使它们满足完美合并来生成剩余的宽条纹
merging cost
转移块的数量
例子
设计算法：
思路
stripemerg首先计算任意一对窄条纹的合并代价，并构造一个包含所有窄条纹对及其合并代价的集合(第1-7行)
根据代价排序，代价为0到k+m之间的整数，计数排序时间复杂度O(n2),n为窄条带数量，那么一共n(n-1)/2对，选择最小的合并，然后删除相关元素
时间复杂度为O((k+m)n2)并没有显著降低（主要是遍历求代价这部分）
C Parity-aligned Heuristic: StripeMerge-P
完美合并的条带有以下特点
parity-aligned
parity chunks have identical encoding coefficients and reside in identical nodes
目标是识别完全奇偶对齐的窄条纹对，从而快速获得满足完美合并的窄条纹对，显著减少了作为算法1输入的条纹数量，还识别partially parity-alignedpairs的条带块
构造一个集合校验块对齐的数量的集合，为了构造这个，将校验块的位置的元数据存储在哈希表中。
哈希表存储key-value，key指向奇偶块的具体拜访，value是具有相应奇偶块位置的条带的索引列表。O(1)时间查找到具有相同校验块位置的条带
对于任意条带，其校验块放置在m节点中，它可以为其所有奇偶校验块放置生成2m - 1个不同的键,这些会造成二外的内存开销，但是这个开销是有限的。
在StripeMerge-G基础上做了修改
具体算法
这种方法思想是找校验块对齐的条带，进行合并。但是他们的数据块可能在同一个节点，这样会造成数据迁移，cost增加
5.PERFORMANCE EVALUATION
Amazon EC2
StripeMerge VS NCScale
比较点，节省多少带宽
可以减少多少运行时间
A Simulations
not implement coding operations and data transfers（没有数据传输这个带宽咋来的？？？）
Intel Xeon Silver 4110 2.10 GHz CPU
256 GiB RAM
ST1000DM003 7200 RPM 1 TiB SATA hard disk
设N为2k+m的倍数
Experiment A.1 (Wide-stripe generation bandwidth)
10000个条带随机分布在N个节点，测试不同的N和（k，m）的组合
StripeMerge-P ,StripeMerge-G, NCScale
4≤k≤64,2≤m≤4 N=2(2k+m) and N=4(2k+m)
从图中可以看出来，带宽随着k和m的增加而增加，因为会使得完美匹配更加难满足
当k比较小时生成带宽随着N的增大而增大，k比较大时，随着N的增大而减小。
正面影响，N越大数据块越容易分布在不同的节点上，负面影响校验块越不容易驻留在相同节点。
k不大时，m和k差不都，负面影响大。k较大时，k远大于m，正面影响大，带宽减小。所以更大的k和N会受益（觉得缺乏说服力）
StripeMerge-P 和 StripeMerge-G性能差不多
Experiment A.2 (Running time versus(k,m))
StripeMerge-G and StripeMerge-P的运行时间对比（为啥不跟NCScale比，这个时间是0么）
StripeMerge-P比StripeMerge-G 快，说明parity-aligned有效的加快了速度，k较小时，基本上是0.
优化幅度随着k的增大而减小，k越大，更多的数据块有糟糕的数据块布局，parity-aligned不能加速算法。
Experiment A.3 (Running time versus the number of narrow stripes)
测试算法运行时间与窄条纹数量
固定(k,m) = (16,4)andN=2(2k+m) =72
StripeMerge-G 随着条带数量显著增加（O((k+m)n2 )），StripeMerge-P线性增加(O((k+m)mn))更适合大型系统
Experiment A.4 (Memory consumption of StripeMerge-P)
total memory usage
the memory usage of the hash table that stores parity-aligned metadata
fix(k,m) = (16,4) and N=2(2k+m) =72
(注意轴是指数型的)，由此可见哈希表的开销和总内存开销相比是有限的，处理10000条窄条带需要4.85GB的内存，哈希表本身只需要72.5MB的内存，StripeMerge-P产生的额外开销是可以接受的。
B Amazon EC2 Experiments
扩展了coding and data transfer功能，使用ISA-L实现编解码
N=2(2k+m) 个 m5.xlarge 实例 当存储节点，为了评估网络带宽的影响，专门配置了一个用作网关的专用实例。
来自实例的任何传输块都必须在到达另一个实例之前遍历网关。我们使用Linux流量控制命令来控制网关的输出带宽
实验中，将带宽从1Gb/s到8Gb/s变化，实验考虑不同的块大小 10,000 narrow
Experiment B.1 (Time breakdown)
时间分为3部分
-
算法运行时间，找到需要合并的窄条带
-
转移时间，指的是用于合并的块的转移
-
计算时间，是指将窄条带的校验块合并为宽条带的新校验块的本地计算
(k,m) = (16,4),N=2(2k+m) =72
chunk size of 64MiB
gateway bandwidth of 8Gb/s
由表格可知传输时间占主导地位
stripemerg的运行时间占用了10,000条条纹总时间的1.65%，但这个百分比将随着条纹数量的增加而急剧增加(实验A.3)。因此，对于具有大量分条的大型存储系统，stripemerg的运行时间会降低整体性能。相比之下，stripemerg - p的运行时间仅占10,000条带总时间的0.068%，而这一百分比只随着条带数量的增加而线性增加
Experiment B.2 (Wide-stripe generation time versus (k,m))
gateway bandwidth as 8 Gb/s and the chunk size as 64 MiB
k m 增加生成时间增加 ，完美匹配的少了，需要传输的数据多了，时间会变长
Experiment B.3 (Impact of gateway bandwidth)
(k,m) = (16,4),N=2(2k+m) =72
gateway bandwidth, from 1 Gb/s to 8 Gb/s
生成时间随着带宽增大而线性减小，并且StripeMerge 优于NCScale
Experiment B.4 (Impact of chunk size)
chunk sizes, from 8 MiB to 64 MiB
(k,m) = (16,4),N=2(2k+m) =72
gateway bandwidth of 8 Gb/s
生成时间随着块大小线性增加，而且StripeMerge性能仍然较好
6.RELATEDWORK
在repair和scaling roblem最小化带宽的研究
repair
locally repairable codes (LRC)
通过额外的存储减小修复I/O
regenerating codes(再生码)
通过额外的存储减小修复I/O
repair-efficient techniques
lazy recovery通过谨慎地延迟立即修复操作来减少修复流量
parallelizing and pipelining repair
减少修复时间
scheduling repair tasks in free timeslots
适应工作负载的动态变化
scaling problem
minimize the bandwidth
under RAID-0, RAID-5 (i.e., single fault tolerance) , or RS codes
code conversion
研究可转换的代码结构，以最小化代码转换中的I/O
本文研究的问题其实和上面的都不一样，研究如何最小化带宽并且减少宽条带生成问题的计算开销。
宽条带问题的相关研究
VAST
locally decodable codes提高宽条带的修复性能
Haddock et
general-purpose GPUs 提高宽条带的解码效率
ECWide
combined locality
系统的解决了修复带宽问题，提出了有效的编码和更新方案
本文关注点在于如何生成宽条带
7.CONCLUSIONS
StripeMerge生成宽条带
本文转换为bipartite graph modeling，证明了最优方案的存在。提出了两个算法，在有限带宽下生成（完美情况时间复杂度比较大），生成性能比现有性能好。
文章中提到的性质，是直接使用范德蒙矩阵的子矩阵，但是在k，m较大时，这种矩阵不一定有逆，所以业界现在用的范德蒙矩阵，上面化成单位阵，下面系数，已经不存在本文中的性质了。所以文章的理论出发点存疑，不过m=2时，感觉是成立的，但是文章是对任意m的。验证刚才提到的内容可以通过Jerasure输出编码矩阵，这个事情在Note Correction to the 1997 Tutorial on Reed-Solomon Coding有提到。
教训
浙公网安备 33010602011771号