顶会论文:纠删码存储系统中的投机性部分写技术

本文已被USENIX'17年度技术大会录用,此处为中文简译版。

阅读英文论文完整版请点击:Speculative Partial Writes in Erasure-Coded Systems

前言

多副本和纠删码(EC,Erasure Code)是存储系统中常见的两种数据可靠性方法。与多副本冗余不同,EC将m个原始数据块编码生成k个检验块,形成一个EC组,之后系统可最多容忍任意k个原始数据块或校验块损坏,都不会产生数据丢失。纠删码可将数据存储的冗余度降低50%以上,大大降低了存储成本,在许多大规模分布式存储系统中已得到实际应用。

EC给写操作带来了很大的额外开销,包括编解码计算开销和流程性开销两部分。在向量指令集SSE、AVX等的帮助下,一个现代CPU核心的EC编解码能力就可以达到几GB到十几GB每秒,远远大于存储设备的I/O吞吐率。这使得流程性开销成为EC写入性能的最重要制约因素。若一次写操作的偏移和长度没有对齐EC组,就需要部分更新涉及的EC组,因而将此类操作称为部分写。部分写带来了大部分的流程性开销。

处理部分写的最直接办法是将不被写的数据块读出来,跟新数据组合在一起,然后再整体编码并写入。目前Ceph、Sheepdog等系统都采用了这种办法。一种简单有效的改进是将被覆盖数据的原始值读出来,然后根据新旧数据的差值来进行增量编码,得到各个校验块的差值,并“加”到各个校验块上。这种方法可以显著减少系统总体I/O次数,然而它需要对涉及的数据块和所有校验块进行原地读写(即在同一位置进行先读后写),在没有缓存的情况下(常态),HDD需要花费8.3毫秒(7200RPM)的时间旋转一周才能完成写入请求,跟一次随机I/O的平均寻道时间相当。这样的流程极大地影响了写入效率,即便应用层面发出的是顺序写操作,最终得到的性能也跟随机写差不多。

在实际应用当中,只有写操作的偏移和长度都恰好跟EC组对齐才可以避免部分写,然而应用往往无法照顾到底层存储的实现细节和参数,所以部分写构成了写操作的主体,决定了EC存储系统的实际写性能。EC模式的部分写性能大大低于三副本写,这使得EC尚不适用于写操作较多的场合,如云硬盘。

目前业内已有许多工作对这一问题进行改进,其中最具代表性的工作是2014年发表在FAST技术会议上的“Parity Logging with Reserved Space: Towards Efficient Updates and Recovery in Erasure-coded Clustered Storage”,它的核心思路是通过在校验块上记变更日志的方式来减少其上不必要的读操作,同时将随机写变成顺序追加写,以改善写入性能。然而它并不能改善原始数据块上的写流程,这构成了大多数的写操作,所以系统总体写性能改善有限。

投机性部分写:原理、设计与实现

现实当中的I/O负载也存在大块顺序的操作,这将产生整个EC组的全量写操作。对于这种操作,我们将直接计算出校验数据,并将其写入校验块,同时在变更日志中记录一个特殊操作I,表示将I之前的变更记录取消掉,因为最新的数据已经直接写到校验块内了。

根据上述原理,我们设计出如下图所示的部分写流程(以三个校验块为例):

我们基于美团云现有的分布式块存储系统(参见之前的博客文章“分布式块存储系统Ursa的设计与实现”)将这一设计实现出来,称为PBS,提供强一致性保障。系统的写操作流程整体如下图所示(以两个校验块为例):

实验

EC编解码性能

我们针对EC(4,2)、EC(6,3)、EC(8,4)、EC(10,4)等多种配置测试了编解码运算性能。如下图所示,在SSE、AVX等向量运算指令集的帮助下,现代CPU的1个核心每秒就能完成5~13GB数据量的编解码工作,远远大于同时期各种外部存储设备的吞吐率,所以编解码运算已不再成为EC存储系统的瓶颈。测试中所用CPU型号为Xeon E5-2650v3 @ 2.3GHz,图中encode表示编码,decode 1和2分别表示解码1个和2个数据块。

PBS部分写的性能

所有的测试均在虚拟机内挂载PBS完成。我们的测试环境为3台服务器,每台配备10块硬盘,7200RPM。测试了随机写IOPS,以及随机写的延迟,来衡量部分写的性能,其中I/O大小为4KB,EC组的条带大小为16KB。测试结果分别如下图所示,其中HDD表示单块7200RPM的物理硬盘的基准性能,R3表示三副本模式,PBS-1和PBS-2分别表示PBS在投机失败(首次写)和投机成功(第二次及以后)的情况,EC表示增量编码方法,EC-PLog表示前文所述的在FAST'14技术大会发表的工作,代表了已有方法中的最好结果。

从结果可以看出,各种情况下的读性能大致相当,PBS-1(投机失败,小概率)比EC-PLog略低,PBS-2(投机成功,大概率)远远好于EC-PLog,甚至可以与三副本模式的性能相媲美。

故障恢复

我们在内存中为日志建立了索引,因而在(故障恢复中)读取日志时可以快速定位数据偏移。如下图所示,测试结果表明日志大小对故障恢复速度的影响有限。

原文发布于微信公众号 - 美团点评技术团队(meituantech)

原文发表时间:2017-05-19

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏CSDN技术头条

Spark SQL在100TB上的自适应执行实践

Spark SQL是Apache Spark最广泛使用的一个组件,它提供了非常友好的接口来分布式处理结构化数据,在很多应用领域都有成功的生产实践,但是在超大规模...

3596
来自专栏架构师之路

分布式ID生成器 | 架构师之路

一、需求缘起 几乎所有的业务系统,都有生成一个唯一记录标识的需求,例如: 消息标识:message-id 订单标识:order-id 帖子标识:tiezi-id...

4037
来自专栏美团技术团队

每天数百亿用户行为数据,美团点评怎么实现秒级转化分析?

导读 用户行为分析是数据分析中非常重要的一项内容,在统计活跃用户,分析留存和转化率,改进产品体验、推动用户增长等领域有重要作用。美团点评每天收集的用户行为日志达...

39610
来自专栏小狼的世界

[每天五分钟,备战架构师-4]操作系统之设备管理

设备管理是对计算机输入、输出系统的管理,这是操作系统最具有多样性和复杂性的部分,其主要任务是选择合适的设备进行数据传输,控制数据交换的过程,为用户提供透明的接口...

792
来自专栏蓝天

向量时钟解决数据一致性

向量时钟,最早是用于分布式系统中进程间的时间同步。由于在分布式系统中没有一个直接的全局逻辑时钟。在一个由n个并发进程构成的系统中,每个事件的逻辑时钟均由一个n...

771
来自专栏铭毅天下

Elasticsearch聚合优化 | 聚合速度提升5倍!

? 1、聚合为什么慢? 大多数时候对单个字段的聚合查询还是非常快的, 但是当需要同时聚合多个字段时,就可能会产生大量的分组,最终结果就是占用 Elastic...

4387
来自专栏数据和云

经典文档:Oracle Database 12.2新特性概览解读下载

在2017 OOW大会上,关于Oracle Database 12.2 数据库的新特性介绍仍然引人瞩目,会后公布了 Oracle VP Swonger的文档,我...

2957
来自专栏数据和云

深入并行:从生产者到消费者模型深度理解Oracle的并行

陈焕生 Oracle Real-World Performance Group 成员,senior performance engineer,专注于 OLTP...

2946
来自专栏加米谷大数据

Spark的性能调优

下面这些关于Spark的性能调优项,有的是来自官方的,有的是来自别的的工程师,有的则是我自己总结的。

982
来自专栏领域驱动设计DDD实战进阶

领域驱动设计之实体、值对象、领域服务

3759

扫码关注云+社区