天猫淘宝海量图片元信息存储在哪？

简介：做者：旺德/志歉

1.图片空间数据库存储成本暴涨

图片空间是淘宝智能图片中心面向商家提供的免费图片存储管理服务，因为淘宝、天猫主站上累积的用户图片数据量很是大（想一想淘宝/天猫的商家和消费者天天要上传多少图片！），而且增加量惊人，图片空间业务面临着很是巨大的存储空间和写入性能压力。尤为每一年双11以前，商家大量更新商品库存保有单位SKU（Stock keeping Unit），此时数据会急剧增加。

淘宝/天猫每日新增大量商品、评论图片
某年双十一前夕，当时阿里大部分数据库系统还使用的是InnoDB存储引擎，图片空间的研发同窗梳理双十一线上风险时，咨询到DB磁盘及水位的容量是否足够，咱们曾信誓旦旦地说：“没有问题，四个月前咱们刚扩了一倍机器”。但是没过多久就被现实打脸了：不到5个月的时间，业务数据累积了过去6-7年的量，每日增量急剧上升，扩容的磁盘很快也将不够了。

2.解决方案，扩容仍是换引擎？

为何选择新引擎

最简单粗暴的方法固然是扩容，这样作风险最小，但却只能解决眼前的问题。以如今数据的膨胀速度，将来不免屡次扩容。仅仅由于空间不足的问题，致使成本翻好几倍，这是难以接受的。
另一个方法是换引擎，当时阿里主打高性能低成本的自研存储引擎X-Engine刚刚成熟（TODO：X-ENGINE架构超连接），相较于基于B+-Tree的存储引擎（例如InnoDB）数据页存在较多空间浪费，基于LSM-Tree的X-Engine数据彻底紧凑排列，空间利用率更高。而紧凑排列的数据施之前缀压缩技术，空间使用进一步减小。

X-Engine的Data Block无需原地更新，能够方便使用通用压缩算法(zlib,zstd,snapy等)压缩。全部位于LSM-tree低层次的数据都会默认压缩。通过大量对比测试，X-Engine默认选用了ZSTD压缩算法，但同时也保留了对其余算法的支持。此外后台compaction会持续删除无效记录（LSM-Tree更新和删除都是写入新记录，旧版本记录再也不被须要时，视为无效），持续释放冗余的空间。
由于上述技术特色，X-Engine对存储空间的节省几乎到达了“变态”的程度，以致于当图片空间库的数据所有从InnoDB转移到X-Engine后，空间节省了7倍，以下图所示

如何作到下降7倍成本

为何数据从InnoDB迁移至X-Engine后，取得了如此巨大的成本收益？

• 首先，InnoDB采用B+-Tree索引数据，伴随着数据写入，树的节点不停地分裂合并，致使定长的数据页长期处于“半满”状态，空间存在浪费。而X-Engine的更新删除操做，都是追加写到内存memtable，不会更改磁盘上的数据，所以这些静态数据能够紧凑的排列，不用为将来的写入预留空间，空间利用率很高。虽然追加写会产生冗余的多版本数据，X-Engine后台Compaction操做每每能够及时地清理无用的多版本数据。
• 其次，图片空间库存储了大量的图片元信息（例如user_id、图片地址URL等），这些信息有一个特色：相邻数据之间类似度很是高，例如同一个user_id每每对应多个图片地址，图片地址URL之间的前缀十分类似。X-Engine的前缀压缩机制保证：相邻key的相同前缀，尽可能只存储一次。所以包含图片元信息的二级索引，通过前缀压缩，所占空间不多。
• 最后，主表的key虽然不能使用前缀压缩，但通用压缩算法，面对图片元信息记录中大量类似的文本字符（URL等），也能大显身手，取得理想的压缩比率。InnoDB虽然也支持数据页压缩，且对静态数据有较好的压缩比率，可是随着数据写入，B+-Tree持续分裂合并，空间很快就会膨胀起来。X-Engine静态的数据页，不存在这个问题。

性能表现依然优异

此外，因为图片空间是一个高频使用的应用，若是X-Engine的性能不知足要求，也没法落地。得益于LSM轻量化写机制，X-Engine写入操做本就是优点，况且还引入了group commit和事务处理流水线机制，大大增长了写入处理的并发度。读请求本是LSM的弱项，分层的结构和追加写产生的多版本数据，会增长读请求查询路径的长度，X-Engine为此作了大量的优化，诸如：多粒度Cache（memtable，Block Cache和Row Cache）、bloomfilter和range scan filter（Surf, SIGMOD'18）有效减小点查询和范围扫描的次数、异步I/O预取等，尽力把它打形成读写性能均衡，成本优点突出的存储引擎。关于X-Engine读写优化，能够参考这篇文章（TODO:超连接）。

通过DBA和业务开发同窗的验证，X-Engine的读写性能及延时彻底知足业务需求。很快，淘宝图片空间库所有切换为X-Engine引擎，节省了大量的存储成本。

3.X-Engine适合什么样的业务

X-Engine分层存储的架构，特别适合具备以下业务负载特征的业务：

• 库表数据量特别大，对成本敏感的业务。传统InnoDB引擎迁移到X-Engine后，依据数据特征不一样，存储空间可下降2倍~10倍。迁移到X-Engine以后，不少业务能够免除分库分表的需求，使用单库便可承载近10TB的数据存储服务。例如：X-Engine在钉钉的应用。
• 数据访问具备鲜明的时间特征。例如大部分读取及修改操做集中在最近写入的数据上，而历史数据较少被访问（例如淘宝交易库（超连接））。X-Engine新写入的数据经过高效的内存索引缓存，访问性能极高，而较少访问的历史数据保存在磁盘，提供稍逊的读写性能。例如：X-Engine在淘宝交易库的应用。