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

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在淘宝交易库的应用。