1万属性,100亿数据,每秒10万吞吐,架构如何设计?

有一类业务场景,没有固定的schema存储,却有着海量的数据行数,架构上如何来实现这类业务的存储与检索呢?58最核心的数据“帖子”的架构实现技术细节,今天和大家聊一聊。

一、背景描述及业务介绍

什么是58最核心的数据?

58是一个信息平台,有很多垂直品类:招聘、房产、二手物品、二手车、黄页等等,每个品类又有很多子品类,不管哪个品类,最核心的数据都是“帖子信息”。

画外音:像不像一个大论坛?

各分类帖子的信息有什么特点?

逛过58的朋友很容易了解到,这里的帖子信息:

(1)各品类的属性千差万别,招聘帖子和二手帖子属性完全不同,二手手机和二手家电的属性又完全不同,目前恐怕有近万个属性;

(2)数据量巨大,100亿级别;

(3)每个属性上都有查询需求,各组合属性上都可能有组合查询需求,招聘要查职位/经验/薪酬范围,二手手机要查颜色/价格/型号,二手要查冰箱/洗衣机/空调;

(4)吞吐量很大,每秒几10万吞吐;

如何解决100亿数据量,1万属性,多属性组合查询,10万并发查询的技术难题呢?一步步来。

二、最容易想到的方案

每个公司的发展都是一个从小到大的过程,撇开并发量和数据量不谈,先看看

(1)如何实现属性扩展性需求;

(2)多属性组合查询需求;

画外音:公司初期并发量和数据量都不大,必须先解决业务问题。

如何满足业务的存储需求呢?

最开始,业务只有一个招聘品类,那帖子表可能是这么设计的:

tiezi(tid, uid, c1, c2, c3);

那如何满足各属性之间的组合查询需求呢?

最容易想到的是通过组合索引满足查询需求:

index_1(c1, c2)

index_2(c2, c3)

index_3(c1, c3)

随着业务的发展,又新增了一个房产类别,存储问题又该如何解决呢?

可以新增若干属性满足存储需求,于是帖子表变成了:

tiezi(tid, uid, c1, c2, c3, c10, c11, c12, c13); 

其中:

  • c1,c2,c3是招聘类别属性
  • c10,c11,c12,c13是房产类别属性

通过扩展属性,可以解决存储的问题。

查询需求,又该如何满足呢?

首先,跨业务属性一般没有组合查询需求。只能建立了若干组合索引,满足房产类别的查询需求。

画外音:不敢想有多少个索引能覆盖所有两属性查询,三属性查询。

当业务越来越多时,是不是发现玩不下去了?

三、垂直拆分是一个思路

新增属性是一种扩展方式,新增表也是一种方式,垂直拆分也是常见的存储扩展方案。

如何按照业务进行垂直拆分?

可以这么玩:

tiezi_zhaopin(tid, uid, c1, c2, c3);

tiezi_fangchan(tid, uid, c10, c11, c12, c13);

在业务各异,数据量和吞吐量都巨大的情况下,垂直拆分会遇到什么问题呢?

这些表,以及对应的服务维护在不同的部门,看上去各业务灵活性强,研发闭环,这恰恰是悲剧的开始:

(1)tid如何规范?

(2)属性如何规范?

(3)按照uid来查询怎么办(查询自己发布的所有帖子)?

(4)按照时间来查询怎么办(最新发布的帖子)?

(5)跨品类查询怎么办(例如首页搜索框)?

(6)技术范围的扩散,有的用mongo存储,有的用mysql存储,有的自研存储;

(7)重复开发了不少组件;

(8)维护成本过高;

(9)…

画外音:想想看,电商的商品表,不可能一个类目一个表的。

四、58的玩法:三大中心服务

第一:统一帖子中心服务

平台型创业型公司,可能有多个品类,各品类有很多异构数据的存储需求,到底是分还是合,无需纠结:基础数据基础服务的统一,是一个很好的实践。

画外音:这里说的是平台型业务。

如何将不同品类,异构的数据统一存储起来呢?

(1)全品类通用属性统一存储;

(2)单品类特有属性,品类类型与通用属性json来进行存储;

更具体的:

tiezi(tid, uid, time, title, cate, subcate, xxid, ext);

(1)一些通用的字段抽取出来单独存储;

(2)通过cate, subcate, xxid等来定义ext是何种含义;

(3)通过ext来存储不同业务线的个性化需求

例如:

招聘的帖子,ext为:

{“job”:”driver”,”salary”:8000,”location”:”bj”}

而二手的帖子,ext为:

{”type”:”iphone”,”money”:3500}

帖子数据,100亿的数据量,分256库,通过ext存储异构业务数据,使用mysql存储,上层架了一个帖子中心服务,使用memcache做缓存,就是这样一个并不复杂的架构,解决了业务的大问题。这是58最核心的帖子中心服务IMC(Info Management Center)。

画外音:该服务的底层存储在16年全面切换为了自研存储引擎,替换了mysql,但架构理念仍未变。

解决了海量异构数据的存储问题,遇到的新问题是:

(1)每条记录ext内key都需要重复存储,占据了大量的空间,能否压缩存储;

(2)cateid已经不足以描述ext内的内容,品类有层级,深度不确定,ext能否具备自描述性;

(3)随时可以增加属性,保证扩展性;

解决完海量异构数据的存储问题,接下来,要解决的是类目的扩展性问题。

第二:统一类目属性服务

每个业务有多少属性,这些属性是什么含义,值的约束等,耦合到帖子服务里显然是不合理的,那怎么办呢?

抽象出一个统一的类目、属性服务,单独来管理这些信息,而帖子库ext字段里json的key,统一由数字来表示,减少存储空间。

画外音:帖子表只存元信息,不管业务含义。

如上图所示,json里的key不再是”salary” ”location” ”money” 这样的长字符串了,取而代之的是数字1,2,3,4,这些数字是什么含义,属于哪个子分类,值的校验约束,统一都存储在类目、属性服务里。

画外音:类目表存业务信息,以及约束信息,与帖子表解耦。

这个表里对帖子中心服务里ext字段里的数字key进行了解释:

(1)1代表job,属于招聘品类下100子品类,其value必须是一个小于32的[a-z]字符;

(2)4代表type,属于二手品类下200子品类,其value必须是一个short;

这样就对原来帖子表ext扩展属性:

{“1”:”driver”,”2”:8000,”3”:”bj”}

{”4”:”iphone”,”5”:3500}

key和value都做了统一约束。

除此之外,如果ext里某个key的value不是正则校验的值,而是枚举值时,需要有一个对值进行限定的枚举表来进行校验:

这个枚举校验,说明key=4的属性(对应属性表里二手,手机类型字段),其值不只是要进行“short类型”校验,而是value必须是固定的枚举值。

{”4”:”iphone”,”5”:3500}

这个ext就是不合法的,key=4的value=iphone不合法,而应该是枚举属性,合法的应该为:

{”4”:”5”,”5”:3500}

此外,类目属性服务还能记录类目之间的层级关系:

(1)一级类目是招聘、房产、二手…

(2)二手下有二级类目二手家具、二手手机…

(3)二手手机下有三级类目二手iphone,二手小米,二手三星…

(4)…

类目服务解释了帖子数据,描述品类层级关系,保证各类目属性扩展性,保证各属性值合理性校验,就是58另一个统一的核心服务CMC(Category Management Center)。

画外音:类目、属性服务像不像电商系统里的SKU扩展服务?

(1)品类层级关系,对应电商里的类别层级体系;

(2)属性扩展,对应电商里各类别商品SKU的属性;

(3)枚举值校验,对应属性的枚举值,例如颜色:红,黄,蓝;

通过品类服务,解决了key压缩,key描述,key扩展,value校验,品类层级的问题,还有这样的一个问题没有解决:每个品类下帖子的属性各不相同,查询需求各不相同,如何解决100亿数据量,1万属性的检索与联合检索需求呢?

第三:统一检索服务

数据量很大的时候,不同属性上的查询需求,不可能通过组合索引来满足所有查询需求,“外置索引,统一检索服务”是一个很常用的实践:

(1)数据库提供“帖子id”的正排查询需求;

(2)所有非“帖子id”的个性化检索需求,统一走外置索引;

元数据与索引数据的操作遵循:

(1)对帖子进行tid正排查询,直接访问帖子服务;

(2)对帖子进行修改,帖子服务通知检索服务,同时对索引进行修改;

(3)对帖子进行复杂查询,通过检索服务满足需求;

画外音:这个检索服务,扛起了58同城80%的请求(不管来自PC还是APP,不管是主页、城市页、分类页、列表页、详情页,最终都会转化为一个检索请求),它就是58另一个统一的核心服务E-search,这个搜索引擎,是完全自研的。

对于这个内核自研服务的搜索引擎架构,简单说明一下:

为应对100亿级别数据量、几十万级别的吞吐量,业务线各种复杂的复杂检索查询,扩展性是设计重点:

(1)统一的代理层,作为入口,其无状态性能够保证增加机器就能扩充系统性能;

(2)统一的结果聚合层,其无状态性也能够保证增加机器就能扩充系统性能;

(3)搜索内核检索层,服务和索引数据部署在同一台机器上,服务启动时可以加载索引数据到内存,请求访问时从内存中load数据,访问速度很快:

  • 为了满足数据容量的扩展性,索引数据进行了水平切分,增加切分份数,就能够无限扩展性能
  • 为了满足一份数据的性能扩展性,同一份数据进行了冗余,理论上做到增加机器就无限扩展性能

系统时延,100亿级别帖子检索,包含请求分合,拉链求交集,从聚合层均可以做到10ms返回。

画外音:入口层是Java研发的,聚合层与检索层都是C语言研发的。

帖子业务,一致性不是主要矛盾,E-search会定期全量重建索引,以保证即使数据不一致,也不会持续很长的时间。

五、总结

文章写了很长,最后做一个简单总结,面对100亿数据量,1万列属性,10万吞吐量的业务需求,可以采用了元数据服务、属性服务、搜索服务来解决:

  • 一个解决存储问题
  • 一个解决品类解耦问题
  • 一个解决检索问题

任何复杂问题的解决,都是循序渐进的。

思路比结论重要,希望大家有收获。

Image placeholder
IT头条
未设置
  84人点赞

没有讨论,发表一下自己的看法吧

推荐文章
96秒100亿!如何抗住双11高并发流量?

今年双11全民购物狂欢节进入第十一个年头,1分36秒,交易额冲到100 亿 !比2018年快了近30 秒,比2017年快了近1分半!这个速度再次刷新天猫双11成交总额破100亿的纪录。那么如何抗住双1

阿里巴巴为什么能抗住90秒100亿?看完这篇你就明白了!

1、概述本文以淘宝作为例子,介绍从一百个并发到千万级并发情况下服务端的架构的演进过程,同时列举出每个演进阶段会遇到的相关技术,让大家对架构的演进有一个整体的认知,文章最后汇总了一些架构设计的原则。2、

从300万行到50万行代码,遗留系统的微服务改造

在传统企业甚至互联网企业中往往存在大量的遗留系统,这些遗留系统大多都能够正常工作,有的可能还运行着关键业务或者持有核心数据。但是,大部分遗留系统通常经常存在技术陈旧、代码复杂、难以修改等特点。笔者曾经

万字长文|1分36秒,100亿,支付宝技术双11答卷:没有不可能

2019年双11来了。1分36秒100亿,5分25秒超过300亿,12分49秒超500亿……如果没有双11,中国的互联网技术要发展到今天的水平,或许要再多花20年。从双11诞生至今的11年里,有一个场

MySQL 每秒 570000 的写入,如何实现?

来源:吴炳锡yq.aliyun.com/articles/278034一、需求一个朋友接到一个需求,从大数据平台收到一个数据写入在20亿+,需要快速地加载到MySQL中,供第二天业务展示使用。二、实现

一通骚操作,我把SQL执行效率提高了10000000倍!

场景我用的数据库是mysql5.6,下面简单的介绍下场景课程表:create table Course(c_id int PRIMARY KEY,name varchar(10))数据100条学生表:

1000亿文本信息,高并发MD5查询,这么大数据量的业务怎么弄?

==提问== 沈老师,你好,想请教一个身份证信息检索的问题。公司有一个每秒5万并发查询的业务,(假设)根据身份证MD5查询身份证信息,目前有1000亿条数据,纯文本存储,前几天看你写LevelDB,请

盗版12306骗3000万人下载,暴利高仿App是如何花式捞钱的?

眼看着春运一天一天临近,我按捺不住激动的心情,准备加入抢票大军。可是,当我在应用商城搜索12306时,却发现一大批“12306”。这些App下载量从几万到几千万(未标“官方版”的累计下载量超一千万),

到2025年,SDN市场将达到1000亿美元

虽然NFV不断发展,但软件定义网络(SDN)也在服务提供商的网络中蓬勃发展。根据GlobalMarketInsights的报告显示,到2025年,SDN市场将从去年的80多亿美元增加的1000亿美元。

数据泄露后,美国Web托管服务商Hostinger重置1400万用户密钥

导读:据外媒TheNextWeb报道,美国Web托管服务商Hostinger在日前发生了包含1400万用户信息的数据库被“未经授权的第三方”访问事件。随后,Hostinger决定采取“预防措施”——整

亚马逊将公布超过最大会话和知识数据集,超400万字

4月1日,亚马逊宣布:他们计划向公众公开“TopicalChat”数据集,超410万单词21万句子的语料库将于2019年9月17日发布。该数据集是为参加AlexaPrizeSocialbotGrand

Facebook数据再泄露 5.4亿数据曝光于AWS服务器

网络安全公司UpGuard最近的一份报告显示,两家第三方Facebook应用程序开发商被发现以公开的方式将用户数据存储在亚马逊的云服务器上。据UpGuard称,其中一家公司CulturaColecti

价值100亿美元!微软刚刚击败亚马逊,拿下美国国防部十年云计算基建订单

大数据文摘授权编译自《纽约时报》编译:李雷、曹培信、刘俊寰为期10年,价值100亿美元。经过长达一年的竞标,微软接连击败了谷歌、IBM、Oracle和亚马逊,拿下了美国国防部云计算这宝贵的一单。上周五

100%数据可用性承诺 VSP 5000系列如何改变存储行业规则

上个月,HitachiVantara在于拉斯维加斯举行的NEXT2019大会上,发布了其最新的企业级高端存储系统VSP5000系列产品。通过这款全面提升的企业级闪存阵列,致力于提供业界领先的性能和弹性

揭秘|每秒千万级的实时数据处理是怎么实现的?

01背景闲鱼目前实际生产部署环境越来越复杂,横向依赖各种服务盘宗错节,纵向依赖的运行环境也越来越复杂。当服务出现问题的时候,能否及时在海量的数据中定位到问题根因,成为考验闲鱼服务能力的一个严峻挑战。线

如何设计 QQ、微信、微博、Github 等等,第三方账号登陆 ?(附表设计)

前言:多账户登陆1.创业初期用户名密码注册登陆手机号注册登陆2.数据库设计3.引入第三方账户方案4.数据库设计5.总结前言:多账户登陆互联网应用当中,我们的应用会使用多个第三方账号进行登录,比如:网易

任正非对话美国思想巨头:短期预计营收下降300亿美元,但2021年华为将重焕生机

大数据文摘编辑部出品6月17日,华为创始人任正非在华为深圳总部,与数字时代三大思想家的其中两位,《福布斯》著名撰稿人乔治·吉尔德和美国《连线》杂志专栏作家尼古拉斯·尼葛洛庞帝,进行了一场长达100分钟

Stack Overflow 上 370万浏览量的一个问题:如何比较 Java 的字符串?

在逛StackOverflow的时候,发现了一些访问量像喜马拉雅山一样高的问题,比如说这个:如何比较Java的字符串?访问量足足有370万+,这不得了啊!说明有很多很多的程序员被这个问题困扰过。PS:

css图片属性如何设置?

css图片属性如何设置?首先新建一个style标签;然后在style标签内使用语法img{属性:值}即可,比如设置图片边框属性img{border:1pxsolidred}。语法:img{ 属性:值;

付费客户突破10000家 帆软的不凡

在笔者眼中,帆软一直是一家”特立独行”的ToB公司,但活的很滋润。其与众不同之处有很多:2018年销售额超过4.6亿,早已达到了上市标准,却效仿华为并未上市。坚持不融资,在如今的市场环境下看,似乎很难

代码传奇 | 身价10亿的程序员 雷军当年也为他打工——WPS之父 求伯君

他的前半生,值得我们每一个人深思。在普通人眼里,他寂寂无名,只有年岁稍长的文化人,才听说过他传奇般的存在。在IT人眼里,他是块活化石,中国第一的大旗除了他,没人敢抗!他是求伯君,从一个浙江穷山村走出来

10亿美元!苹果收购Intel大部分芯片业务,晚半步布局5G芯片能赶上华为高通么?

大数据文摘出品作者:易琬玉、曹培信2200名英特尔员工,17000项无线技术专利,伴随着苹果在今天凌晨官宣收购英特尔大部分5G基带业务,都将逐渐流向苹果。这也意味着,继高通、华为、三星、联发科、紫光展

到2022年,全球客户体验的支出将达到6410亿美元

根据IDC最新发布的《全球半年度客户体验支出指南》报告显示,2019年全球客户体验(CX)技术支出总额将达到5080亿美元,比2018年增长了7.9%。由于公司专注于满足客户的期望并提供差异化的客户体

20万DBA最关注的11个问题

问答集萃接下来,我们分享本期DBASK小程序整理出的问题和诊断总结,供大家参考学习。问题一、对于temp表空间爆满情况,怎么处理?undotemp表空间很大,我的思路是增大表空间大小或者,新建个tem

30万微博评论看翟天临与毕业生的爱恨情仇

作者:朱小五&王小九 来源:凹凸数读我将带着北京电影学院表演系的精神伴随我一生的演艺事业!——翟天临硕士论文致谢辞2019年5月27日凌晨,翟天临又上了热搜。这次的热搜绝对不是买的,因为实时搜索微博“