X-Engine: An Optimized Storage Engine for Large-scale E-commerce Transaction Processing

SIGMOD'19

Gui Huang, Xuntao Cheng, Jianying Wang, Yujie Wang, Dengcheng He, Tieying Zhang, Feifei Li, Sheng Wang, Wei Cao, and Qiang Li {qushan,xuntao.cxt,beilou.wjy,zhencheng.wyj,dengcheng.hedc, tieying.zhang,lifeifei,sh.wang,mingsong.cw,junyu}@alibaba-inc.com Alibaba Group

本文介绍了阿里为了应对电商平台workload而开发的一个KV存储引擎X-Engine,X-Engine结构上选取了比较流行的LSM-Tree结构,很多地方看起来和RocksDB有一些相似的地方,但是设计上根据电商平台的负载特征做了许多的优化,用到了诸如多线程、异步、流水线以及专有硬件(指FPGA)等新技术。X-Engine已经被运用到阿里的实际生产环境中,并且通过了双十一活动的检验,并表现出了良好且稳定的性能。

E-Commerce的特征以及主要问题

X-Engine主要针对电子商务平台开发,阿里结合其双十一活动的经验,总结了电商平台workload的几个主要特征:

活动开始时TPS激增

诸如双十一这样的大型电商活动,在11日0点这样的活动开始时间,大量用户创建大量的订单,使得存储引擎的TPS(Transaction Per Seconds)急剧升高。这就造成了一个“海啸”的问题(tsunami problem),下图为阿里的2018年双十一活动开始前后的TPS变化,可以看到在0点的时候系统TPS增加到原来的122倍(此时X-Engine依旧维持了相对稳定的TPS)。一般解决这样的“海啸”问题的方法是增加服务器数量,实现集群的横向扩展,但是这样的缺点是成本高。

双十一0点的TPS变化

buffer很快被大量数据填满

由于访问量的增加,使得存储引擎的内存缓存被大量数据迅速填满,即使现在内存可以上升到几百G,但这对现在电商平台的数据量来说还是十分不够的,这就需要对系统进行“泄洪”(flood discharge problem),也就是将数据从memory转移到storage中。存储引擎则需要尽可能高效地将数据进行转移。

随着促销活动的改变,数据的冷热会发生迅速的切换

电商平台会有各种促销活动,这种促销活动会吸引大量用户对商品数据进行访问,从而形成热点数据。而当促销活动发生切换的时候,访问热点迅速发生变化(fast-moving current problem)。此时存储引擎需要及时对数据热点的变更作出反应,从storage中取出新的热点数据并缓存。

X-Engine Design

针对上面提到的主要特征和问题,阿里设计开发了X-Engine。X-engine总体结构采用了LSM-Tree的结构,并基于不同的存储设备(NVM/SSD/HDD)实现了分层存储(tier storage),支持事务,并在读写事务处理以及compaction处理上做了多种优化,以应对电商平台的workload特征。

总体结构

Overview

X-Engine基于PolarFS构建,可以作为PolarDB的一个组件。总体可以分为memory的热数据层和storage的温/冷数据层,memory中有Active memtable和多个Immutable memtable,以及Read cache和Index。storage中数据分为多层,不同层的数据通过不同的存储设备存储,每一层数据以extent为单位组织(类似RocksDB的SSTable)。下面详细介绍X-Engine在各个部分以及优化措施。

Read Path

Extent

X-Engine的Extent类似于RocksDB的SSTable,用来持久化存储数据,下图是Extent的基本结构。

Extent

Data Block和Index Block部分和SSTable类似,区别在于Extent的元数据部分主要是Schema,X-Engine是以Row为形式存储一个table,Schema中存储的就是一个Table的各个column的属性。Schema带有一个version,是为了在更新schema的时候不需要去修改旧的数据。

Cache

cache

X-Engine的cache比起RocksDB多了一个Row Cache(但是RocksDB其实也有一个Row cache,好像实现不一样)。Row Cache用于缓存最近访问的记录,通过哈希组织数据,并通过LRU进行数据淘汰。另一个Block Cache就和RocksDB基本一样,都是以data block为粒度对数据进行缓存。

Meta Index

X-Engine的Meta Index用来记录LSM-Tree结构的变化,类似Manifest(这一部分有点没理解),结构如下:

image.png

LSM-Tree中每个subtable都有其meta index,meta index起始于一个根节点,并在每次更新之后创建新的节点。如上面的L0的extent-i,它对应meta snapshot v,当extent-i被compaction之后创建新的meta snapshot v+1,v+1只需要指向原来的extent-i而不需要产生实际的IO,同时cache的数据也不需要变化。同时这样的CoW的结构使得事务可以访问任意版本的数据,避免了锁的开销。X-Engine中有GC机制来清理过期的snapshot。

Incremental Cache Replacement

这一项是针对compaction对cache的影响进行的优化,原来的LSM-Tree实现中,当SST被compact,则对应的内存中的数据会被evict,造成突然的cache miss,这个问题在前些年的一篇论文LSbM-Tree中也有被提到。X-Engine的这个Incremental Cache Replacement的原理就是在compaction的时候检查一个block是否被cache,如果是,则将cache中的内容替换为merge之后的block,再结合后面的reuse机制,可以有效地缓解compaction对cache命中率带来的影响。

Write Path

X-Engine的写优化主要是memtable的优化以及写Redo log上的优化。

Multi-Version Memtable

memtable上做了一点简单的优化,像RocksDB的memtable,如果多次更新同一个key,那么这个key会以<key, sequence_number>的形式在memtable中存储,如果要查找最新的key,则可能需要读多个旧值。X-Engine的Multi-Version Memtable对此的优化就是将同一个key的不同版本单独链起来。这样Skiplist中不会出现一个key的多个版本,同一个key的多版本中按照新旧组织顺序,最新的key可以最快被访问到。

multi-version memtable

Asynchronous & Pipeline

这一块是X-Engine优化比较多的,总体的结构如下:

Transaction

X-Engine通过MVCC以及two-phase-locking实现了SI(Snapshot Isolation)和RC(Read Committed)级别的隔离等级。读写事务被分成两个阶段,分别是Read/Write Phase和Commit Phase。在R/W Phase,读请求通过Read path处理,更新请求被缓存到Transaction Buffer中;在Commit Phase中数据从Transaction Buffer中被写到DB中。

传统的事物处理流程中,用户线程需要执行完整的R/W+commit之后才能返回,X-Engine使用异步的方式将commit解耦出来,Commit阶段线程只需要将请求添加到Task Queue中即可返回,再由系统线程处理Queue里面的请求,提升了用户线程请求效率。同时一个队列中的请求还能通过batch的方式提升IO性能。

在处理commit的时候X-Engine通过pipeline的方式优化的效率。具体的,commit可以分成三个阶段:

1)将txn从Transaction Bufer移动到Log Buffer,并计算校验和:内存访问 & 计算

2)将数据写到Disk:Disk IO

3)插入memtable:内存访问

4)commit: 内存访问

根据每个阶段请求的不同分成不同的线程来执行,以提升带宽(没看懂为啥)。同时每个stage的线程数不同,如stage1分配一个线程,而插入memtable分配了多个线程并行插入。

Flush & Compaction

intra-L0 Compaction

因为L0存储的数据是比其他层都新的,意味着被访问的概率最大,而L0是无序的,所以X-engine引入了Intra-L0 Compaction,本质上是一个L0层内的compaction,对L0的数据进行整理。(RocksDB也有)

Accelerating Compaction

对于其他层的compaction,X-Engine主要做了三个方面的优化:

1)Data Reuse:对于没有重叠的数据块,不进行merge而只改变meta

Reuse

其中reuse可以从三个粒度进行:没有overlap的extent可以reuse,没有overlap的data block可以reuse,data block可以被拆分(split)来促成reuse。这种方法在别的论文中也很常见。

2)Asynchronous IO:X-Engine将compaction分成Read-Merge-Write三个阶段,其中Merge阶段可以作为Read的回调函数执行,实现异步IO,提升Compaction的效率。

3)FPGA Offloading:将Compaction offload到FPGA上去执行,从而降低了Compaction对CPU资源的占用,具体的方法在FAST 20的那篇论文中有讲述。

Evaluation

测试部分主要是针对前面背景部分提出的三个问题进行测试,分别对比了InnoDB和RocksDB。

E-commerce Transaction

首先论文对比了电商平台workload下的三个DB的性能,下面的比例分别是lookup, range lookup, update, insert,可以看到在read intensive的workload中还是InnoDB表现稍好,这主要是因为LSM-Tree的结构如果在缓存未命中的时候,需要查找多层数据,而InnoDB是基于B+树,这方面X-Engine个RocksDB就有天然的劣势。

Transction Workload

Raw KV Performance

测试底层KV接口下的性能,由于InnoDB没有提供KV接口,所以这里只对比了X-Engine和RocksDB,可以看到无论是带宽还是延迟,X-Engine都要比RocksDB优秀不少。

Raw Performance

Write Path Optimization

为了验证Write Path中的异步写以及流水线的有效性,论文测试了不同队列数以及线程数的性能(1 queue = no pipeline),其中异步+8线程性能最好。

Write Path optimization

MySQL Performance

MySQL Performance
Range Lookup

单点操作基本还是X-Engine好,但是Range Scan性能跟InnoDB没法比,这也是来自B+树的天然优势。

验证Offload Compaction的有效性

FPGA Compaction

验证Reuse的有效性

Data Reuse

验证Incremental cache replacement的有效性

Cache Replacement
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 151,511评论 1 330
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 64,495评论 1 273
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 101,595评论 0 225
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 42,558评论 0 190
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 50,715评论 3 270
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 39,672评论 1 192
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,112评论 2 291
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 29,837评论 0 181
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 33,417评论 0 228
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 29,928评论 2 232
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 31,316评论 1 242
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 27,773评论 2 234
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 32,253评论 3 220
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 25,827评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,440评论 0 180
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 34,523评论 2 249
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 34,583评论 2 249

推荐阅读更多精彩内容

  • 前言 这篇从半个月前就开始写,断断续续写到现在,终于能发了(被简书吞了好几次),不容易。 最近笔者正在补习与Roc...
    LittleMagic阅读 12,474评论 13 28
  • 最近项目中用到这个nb的玩意,所以就花时间研究了下,同时整理下助自己记忆。这个猛虎上山的logo就是rocksdb...
    小东_16d3阅读 8,928评论 3 10
  • 通化1269盖云莉 听了王思思老师讲的跨学科视野下的自然笔记一课后让我对跨学科教学有了更近一步的了解...
    通化县1269盖云莉阅读 356评论 0 8
  • 又是十二点多 先生睡觉之前,到我跟前说:早点睡,不要天天这么晚。 我正在聚精会神画禅绕画之:十字菱格。我很投入,只...
    宇虎阅读 244评论 0 3
  • 人最大的运气是什么?不是捡钱,也不是中奖。而是有一天,遇到某一个人,打破你原有的思维,提高你的境界,可以带你走向更...
    豫豫妈阅读 90评论 0 1