专栏首页架构师之路100亿数据1万属性数据架构设计

100亿数据1万属性数据架构设计

一分钟系列之《啥,又要为表增加一列属性?》分享了两种数据库属性扩展思路,被喷得厉害。第二天补充了一篇《这才是真正的表扩展方案》,分享了互联网大数据高并发情况下,数据库属性扩容的成熟工具及思路。

对于version + ext方案,还是有很多朋友质疑“线上不可能这么用”。本篇将讲述一下58同城最核心的数据“帖子”的架构实现技术细节,说明不仅不是“不可能这么用”,而是大数据,可变属性,高吞吐场景下的“常用手段”。

一、背景描述及业务介绍

问:什么是数据库扩展的version + ext方案?

使用ext来承载不同业务需求的个性化属性,使用version来标识ext里各个字段的含义。

例如上述user表:

verion=0表示ext里是passwd/nick

version=1表示ext里是passwd/nick/age/sex

优点?

(1)可以随时动态扩展属性,扩展性好

(2)新旧两种数据可以同时存在,兼容性好

不足?

(1)ext里的字段无法建立索引

(2)ext里的key值有大量冗余,建议key短一些

问:什么是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同城的玩法

【统一帖子中心服务】

平台型创业型公司,可能有多个品类,例如58同城的招聘房产二手,很多异构数据的存储需求,到底是分还是合,无需纠结:基础数据基础服务的统一,无疑是58同城技术路线发展roadmap上最正确的决策之一,把这个方针坚持下来,@老崔 @晓飞 这些高瞻远瞩的先贤功不可没,业务线会有“扩展性”“灵活性”上的微词,后文看看先贤们如何通过一些巧妙的技术方案来解决的。

如何将不同品类,异构的数据统一存储起来,采用的就是类似version+ext的方式:

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

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

(2)通过cate, subcate, xxid等来定义ext是何种含义(和version有点像?)

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

例如招聘的帖子:

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

而二手的帖子:

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

58同城最核心的帖子数据,100亿的数据量,分256库,异构数据mysql存储,上层架了一个服务,使用memcache做缓存,就是这样一个简单的架构,一直坚持这这么多年。上层的这个服务,就是58同城最核心的统一服务IMC(Imformation Management Center),注意这个最核心,是没有之一。

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

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

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

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

【统一类目属性服务】

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

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

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

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

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

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

这样就对原来帖子表ext里的

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

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

key和value都做了统一约束。

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

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

ext : {”4”:”iphone”,”5”:3500}这个ext就是不合法的(key=4的value=iphone不合法),合法的应该为

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

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

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

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

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

(4)…

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

多提一句,类目、属性服务像不像电商系统里的SKU扩展服务?

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

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

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

解决了key压缩,key描述,key扩展,value校验,品类层级的问题,还有这样的一个问题没有解决:每个品类下帖子的属性各不相同,查询需求各不相同,如何解决100亿数据量,1万属性的查询需求,是58同城面临的新问题。

【统一检索服务】

数据量很大的时候,不同属性上的查询需求,不可能通过组合索引来满足所有查询需求,怎么办呢?

58同城的先贤们,从一早就确定了“外置索引,统一检索服务”的技术路线:

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

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

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

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

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

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

这个扛起58同城80%终端请求(不管来自PC还是APP,不管是主页、城市页、分类页、列表页、详情页,很可能这个请求最终会是一个检索请求)的服务,就是58同城另一个统一的核心服务E-search,这个搜索引擎的每一行代码都来自58同城@老崔 @老龚 等先贤们,目前系统维护者,就是“架构师之路”里屡次提到的@龙神 。

对于这个服务的架构,简单展开说明一下:

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

(1)统一的Java代理层集群,其无状态性能够保证增加机器就能扩充系统性能

(2)统一的合并层C服务集群,其无状态性也能够保证增加机器就能扩充系统性能

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

(3.1)为了满足数据容量的扩展性,索引数据进行了水平切分,增加切分份数,就能够无限扩展性能

(3.2)为了满足一份数据的性能扩展性,同一份数据进行了冗余,理论上做到增加机器就无限扩展性能

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

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

五、总结

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

本文分享自微信公众号 - 架构师之路(road5858),作者:58沈剑

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2017-01-18

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

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

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

    Java高级攻城狮
  • 用户中心,1亿数据,架构如何设计?

    用户中心,几乎是所有互联网公司,必备的子系统。随着数据量不断增加,吞吐量不断增大,用户中心的架构,该如何演进呢。

    架构师之路
  • 帖子中心,1亿数据,架构如何设计?

    帖子中心,是互联网业务中,一类典型的“1对多”业务,即:一个用户能发布多个帖子,一个帖子只有一个发布者。

    架构师之路
  • [原创]-数据仓库架构的设计

    架构是数据仓库建设的总体规划,从整体视角描述了解决方案的高层模型,描述了各个子系统的功能以及关系,描述了数据从源系统到决策系统的数据流程。业务需求回答了要做什么...

    DataScience
  • 微服务开发中的数据架构设计前言微服务架构中的多层数据架构设计数据架构设计中的要点

    本文来自作者 陈伟荣 在 GitChat 分享的文章【微服务开发中的数据架构设计】 前言 微服务是当前非常流行的技术框架,通过服务的小型化、原子化以及分布...

    Java架构
  • SOA架构设计经验分享—架构、职责、数据一致性

    阅读目录: 1.背景介绍 2.SOA的架构层次 2.1.应用服务(原子服务) 2.2.组合服务 2.3.业务服务(编排服务) 3.SOA化的重构 3....

    王清培
  • SOA架构设计经验分享—架构、职责、数据一致性

    1. 背景介绍 最近一段时间都在做系统分析和设计工作,面对的业务是典型的重量级企业应用方向。突然发现很多以往觉得很简单的问题变得没有想象的那么容易,最大的问题就...

    CSDN技术头条
  • 支撑百万并发的数据库架构如何设计?

    这篇文章,我们来聊一下对于一个支撑日活百万用户的高并系统,他的数据库架构应该如何设计?

    良月柒
  • 支撑百万并发的数据库架构如何设计?

    作为一个全球人数最多的国家,一个再怎么凄惨的行业,都能找出很多的人为之付出。而在这个互联网的时代,IT公司绝对比牛毛还多很多。但是大多数都是创业...

    田维常
  • MySQL性能管理及架构设计(二):数据库结构优化、高可用架构设计、数据库索引优化

    1. 减少数据冗余:(数据冗余是指在数据库中存在相同的数据,或者某些数据可以由其他数据计算得到),注意,尽量减少不代表完全避免数据冗余;

    用户5546570
  • 订单中心,1亿数据架构,这次服了

    订单中心,是互联网业务中,一个典型的“多key”业务,即:用户ID,商家ID,订单ID等多个key上都有业务查询需求。

    架构师之路
  • App架构设计经验谈:数据层的设计

    一个App,从根本上来说,就是对数据的处理,包括数据从哪里来、数据如何组织、数据怎么展示,从职责上划分就是:数据管理、数据加工、数据展示。相对应的也就有了三层架...

    Keegan小钢
  • 支撑百万并发的数据库架构如何设计? 顶

            作为一个全球人数最多的国家,一个再怎么凄惨的行业,都能找出很多的人为之付出。而在这个互联网的时代,IT公司绝对比牛毛还多很多。但是大多数都是创业...

    kinbug [进阶者]
  • Facebook、亚马逊是如何构建超集群数据库的

    我们建立了Keen IO,是为了以让大多数软件工程团队无需从头架设所有内容,就可以利用最新的大型事件数据技术。但是,如果您对如何成为巨头公司感到...

    BestSDK
  • 支撑海量数据的数据库架构如何设计?

    作为一个全球人数最多的国家,一个再怎么凄惨的行业,都能找出很多的人为之付出。而在这个互联网的时代,IT公司绝对比牛毛还多很多。但是大多数都是创业...

    JavaQ
  • 数据密集型系统架构设计

    按照使用的资源类型划分,我们可以把系统分为三大类型:IO密集型、计算密集型,数据密集型。系统的类型反映了系统的主要瓶颈。现实情况中,大部分系统在由小变大的过程中...

    CSDN技术头条
  • 无限容量数据库架构设计

    花了不少时间,把自己曾经做过的系统,曾经遇到到的问题,曾经实践过的架构方案,梳理总结和沉淀,尽量“系统的”记录成文字,和大家一起讨论。

    Java知音
  • 大数据平台架构设计探究

    近年来,随着IT技术与大数据、机器学习、算法方向的不断发展,越来越多的企业都意识到了数据存在的价值,将数据作为自身宝贵的资产进行管理,利用大数据和机器学习能力去...

    2020labs小助手
  • 大数据平台架构设计探究

    大数据整体流程涉及很多模块,每一个模块都比较复杂,下图列出这些模块和组件以及他们的功能特性,后续会有专题去详细介绍相关模块领域知识,例如数据采集、数据传输、实时...

    大数据学习与分享

扫码关注云+社区

领取腾讯云代金券