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

本文涉及的产品
云原生数据库 PolarDB MySQL 版,Serverless 5000PCU 100GB
云数据库 Redis 版,社区版 2GB
推荐场景:
搭建游戏排行榜
云数据库 RDS MySQL Serverless,0.5-2RCU 50GB
简介: 阿里巴巴旗下的淘宝和天猫作为国内最大在线购物平台,提供售卖的商品数目数以亿计,服务的商家的数量也在数千万量级。面对性能和成本的双重压力,阿里数据库内核团队如何应对

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

图片空间是淘宝智能图片中心面向商家提供的免费图片存储管理服务,由于淘宝、天猫主站上累积的用户图片数据量非常大(想想淘宝/天猫的商家和消费者每天要上传多少图片!),并且增长量惊人,图片空间业务面临着非常巨大的存储空间和写入性能压力。尤其每年双11之前,商家大量更新商品库存保有单位SKU(Stock keeping Unit),此时数据会急剧增长。
image.png

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

2.解决方案,扩容还是换引擎?

为什么选择新引擎

最简单粗暴的方法当然是扩容,这样做风险最小,但却只能解决眼前的问题。以现在数据的膨胀速度,未来难免多次扩容。仅仅因为空间不足的问题,导致成本翻好几倍,这是难以接受的
另外一个方法是换引擎,当时阿里主打高性能低成本的自研存储引擎X-Engine刚刚成熟,相较于基于B+-Tree的存储引擎(例如InnoDB)数据页存在较多空间浪费,基于LSM-Tree的X-Engine数据完全紧凑排列,空间利用率更高。而紧凑排列的数据施以前缀压缩技术,空间使用进一步减少。
image.png

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

如何做到降低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读写优化,可以参考这篇文章:X-Engine SIGMOD论文详解。

经过DBA和业务开发同学的验证,X-Engine的读写性能及延时完全满足业务需求。很快,淘宝图片空间库全部切换为X-Engine引擎,节省了大量的存储成本。

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

X-Engine分层存储的架构,特别适合具有如下业务负载特征的业务:

  • 库表数据量特别大,对成本敏感的业务。传统InnoDB引擎迁移到X-Engine后,依据数据特征不同,存储空间可降低2倍~10倍。迁移到X-Engine之后,很多业务可以免除分库分表的需求,使用单库即可承载近10TB的数据存储服务。例如:X-Engine在钉钉的应用。
  • 数据访问具有鲜明的时间特征。例如大部分读取及修改操作集中在最近写入的数据上,而历史数据较少被访问(例如淘宝交易库)。X-Engine新写入的数据通过高效的内存索引缓存,访问性能极高,而较少访问的历史数据保存在磁盘,提供稍逊的读写性能。例如:X-Engine在淘宝交易库的应用。

图片.gif

目录
相关文章
|
存储 缓存 Oracle
|
3月前
|
机器学习/深度学习 分布式计算 数据挖掘
淘宝/天猫店铺商品详情 API 实现实时数据获取:快速、稳定、高效
淘宝/天猫是中国最大的电商平台之一,拥有海量的商品数据。对于商家来说,了解店铺内所有商品的实时信息非常重要,可以帮助他们更好地管理商品、制定营销策略等。本文将介绍如何使用淘宝/天猫的API接口来获取店铺的所有商品信息,并实现实时数据获取。
《QQ 空间百亿级流量的社交广告系统海量实践》电子版地址
QQ 空间百亿级流量的社交广告系统海量实践
47 0
《QQ 空间百亿级流量的社交广告系统海量实践》电子版地址
《QQ空间平台百亿级流量广告系统海量服务实践》电子版地址
QQ空间平台百亿级流量广告系统海量服务实践
56 0
《QQ空间平台百亿级流量广告系统海量服务实践》电子版地址
|
数据采集 Python
Python爬虫系列14-采集JD商城百万商品数据详情
有时候不能什么都听别人的,更不能因为别人的意见而打乱了自己原有的计划。学习亦是如此。 自己要学会为自己负责,不要听别人说什么就是什么。如果真是那样,那么你自己的人生会过得非常的不好,会一团糟。别人的只是建议,最终还是由自己决定。
Python爬虫系列14-采集JD商城百万商品数据详情
|
SQL 运维 数据可视化
【技术干货】40页PPT分享万亿级交易量下的支付平台设计(4)
【技术干货】40页PPT分享万亿级交易量下的支付平台设计(4)
142 0
【技术干货】40页PPT分享万亿级交易量下的支付平台设计(4)
|
设计模式 数据可视化 测试技术
【技术干货】40页PPT分享万亿级交易量下的支付平台设计(3)
【技术干货】40页PPT分享万亿级交易量下的支付平台设计(3)
145 0
【技术干货】40页PPT分享万亿级交易量下的支付平台设计(3)
|
数据可视化 安全 容灾
【技术干货】40页PPT分享万亿级交易量下的支付平台设计(1)
【技术干货】40页PPT分享万亿级交易量下的支付平台设计(1)
137 0
【技术干货】40页PPT分享万亿级交易量下的支付平台设计(1)
|
运维 监控 数据可视化
【技术干货】40页PPT分享万亿级交易量下的支付平台设计(5)
【技术干货】40页PPT分享万亿级交易量下的支付平台设计(5)
178 0
【技术干货】40页PPT分享万亿级交易量下的支付平台设计(5)
|
设计模式 监控 搜索推荐
【技术干货】40页PPT分享万亿级交易量下的支付平台设计(2)
【技术干货】40页PPT分享万亿级交易量下的支付平台设计(2)
270 0
【技术干货】40页PPT分享万亿级交易量下的支付平台设计(2)