京东评价系统海量数据存储设计

《京东评价系统海量数据存储设计》要点：
本文介绍了京东评价系统海量数据存储设计，希望对您有用。如果有疑问，可以联系我们。

作者：韦仕,京东商城交易平台评价社区负责人,2010年加入京东,先后参与了用户、商品、评论等系统的架构升级工作.

京东的商品评论目前已达到数十亿条,每天提供的服务调用也有数十亿次,而这些数据每年还在成倍增长,而数据存储是其中最重要的部分之一,接下来就介绍下京东评论系统的数据存储是如何设计的.

整体数据存储包括基础数据存储、文本存储、数据索引、数据缓存几个部分.

基础数据存储

基础数据存储使用mysql,因用户评论为文本信息,通常包含文字、字符等,占用的存储空间比较大,为此mysql作为基础数据库只存储非文本的评论基础信息,包括评论状态、用户、时间等基础数据,以及图片、标签、点赞等附加数据.而不同的数据又可选择不同的库表拆分方案,参考如下：

• 评论基础数据按用户ID进行拆库并拆表；
• 图片及标签处于同一数据库下,根据商品编号分别进行拆表；
• 其它的扩展信息数据,因数据量不大、访问量不高,处理于同一库下且不做分表即可.

因人而异、因系统而异,根据不同的数据场景选择不同存储方案,有效利用资源的同时还能解决数据存储问题,为高性能、高可用服务打下坚实基础.

文本存储

文本存储使用了mongodb、hbase,选择nosql而非mysql,一是减轻了mysql存储压力,释放msyql,庞大的存储也有了可靠的保障；二是nosql的高性能读写大大提升了系统的吞吐量并降低了延迟.存储的升级过程尝试了cassandra、mongodb等分布式的nosql存储,cassandra适用于写多读少的情况,而 mongodb也是基于分布式文件存储的数据库,介于关系型数据库与非关系型数据库之间,同时也是内存级数据库,mongo写性能不及 cassandra,但读写分离情况下读性能相当不错,因此从应用场景上我们选择了mongodb.mongodb确实不错,也支持了系统稳定运行了好几年.

但从今后的数据增长、业务扩增、应用扩展等多方面考虑,hbase才是最好的选择,它的存储能力、可靠性、可扩展性都是毋庸置疑的.选择了 hbase,只需要根据评论ID构建Rowkey,然后将评论文本信息进行存储,查询时只需要根据ID便能快速读取评论的文本内容,当然也可将评论的其它字段信息进行冗余存储,这样根据评论ID读取评论信息后不用再从mysql进行读取,减少数据操作,提升查询性能.

数据索引

京东的评论是以用户和商品两个维度进行划分的.对于用户而言,用户需要发表评论、上传晒图、查看自己的评论等,因此mysql数据库中只要根据用户ID对评论数据进行拆库拆表进行存储,便能解决用户数据读写问题.而对于商品而言,前台需要将统计商品的评论数并将所有评论展示出来,后台需根据评论的全字段进行检索同时还带模糊查询,而评论数据是按userId进行库表拆分的,现在要按商品去获取评论,显然当前的拆分库是无法实现的.起初考虑过根据商品编号再进行拆库拆表,但经过多层分析后发现行不通,因为再按商品编号进行拆分,得再多加一倍机器,硬件成本非常高,同时要保持用户及商品两维度的分库数据高度一致,不仅增加了系统维护成本及业务复杂度,同时也无法解决评论的数据统计、列表筛选、模糊查询等问题,为此引入了全文检索框架solr(前台)/elasticsearch(后台)进行数据索引.

数据索引其实就是将评论数据构建成索引存储于索引服务中,便于进行评论数据的模糊查询、条件筛选及切面统计等,以弥补以上数据存储无法完成的功能.京东评论系统为此使用了solr/elasticsearch搜索服务,它们都是基于Lucene的全文检索框架,也是分布式的搜索框架(solr4.0后增加了solr cloud以支持分布式),支持数据分片、切面统计、高亮显示、分词检索等功能,利用搜索框架能有效解决前台评论数据统计、列表筛选问题,也能支持后台系统中的关键词显示、多字段检索及模糊查询,可谓是一举多得.

搜索在构建索引时,属性字段可分为存储字段与索引字段,存储字段在创建索引后会将内容存储于索引文档中,同时也会占用相应的索引空间,查询后可返回原始内容,而索引字段创建索引后不占用索引空间也无法返回原始内容,只能用于查询,因此对于较长的内容建议不进行存储索引.

评论搜索在构建索引时,主键评论ID的索引方式设置为存储,其它字段设置为索引,这样不仅减少索引文件的存储空间,也大大提升了索引的构建效率与查询性能.当然,在使用搜索框架时,业务数据量比较小的也可选择将所有字段进行存储,这样在搜索中查询出结果后将不需要从数据库上查询其它信息,也减轻了数据库的压力.

为了更好地应对前后台不同的业务场景,搜索集群被划分为前台搜索集群和后台搜索集群.

前台搜索集群根据商品编号进行索引数据分片,用于解决评论前台的评论数统计、评论列表筛选功能.评论数统计,如果使用常规数据库进行统计时,需要进行sql上的group分组统计,如果只有单个分组统计性能上还能接受,但京东的评论数统计则需要对1到5分的评论分别进行统计,分组增加的同时随着统计量的增加数据库的压力也会增加,因此在mysql上通过group方式进行统计是行不通的.而使用solr的切面统计,只需要一次查询便能轻松地统计出商品每个分级的评论数,而且查询性能也是毫秒级的.切面统计用法如下：

评论列表,只需根据条件从搜索中查询出评论ID集合,再根据评论ID到mysql、Hbase中查询出评论的其它字段信息,经过数据组装后便可返回前台进行展示.

后台搜索集群,评论后台系统需要对评论进行查询,其中包括关键词高亮显示、全字段检索、模糊查询等,为此solr/elasticsearch都是个很好的选择,目前使用elasticsearch.

未来也计划将前台搜索集群切换为elasticsearch.

数据缓存

面对数十亿的数据请求,直接击穿到mysql、搜索服务上都是无法承受的,所以需要对评论数据进行缓存,在此选择了高性能缓存redis,根据不同的业务数据进行集群划分,同时采用多机房主从方式部署解决单点问题,这样只需要对不同的缓存集群进行相应的水平扩展便能快速提升数据吞吐能力,也有效地保证了服务的高性能、高可用.

（编辑：济源站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!