我的物联网项目(二十二) 微服务分库查询优化

查询优化主要涉及到两块。

1.订单表数据查询优化

订单数据库是单独出来的,每一条记录记录显示都涉及到用户名称(微信号,昵称,app昵称),商家名称(商家名称,电话),设备名称(设备编号,车牌号)等。

99999.png

按照目前的表设计,订单库和用户库,商家库,设备库都独立,表都是通过主键ID进行关联,订单表存放的是userId,merchantId,deviceId等。这种设计方式带来一个瓶颈,就是订单记录显示的时候要通过ID关联查询显示出用户,商家,设备的信息并展示在前端页面。当初在开发过程中,由于时间比较赶,没有做过多的细节优化,都是通过后台订单微服务通过ID去循环查询去用户,商家以及设备的信息再到前端展示,刚开始还好,毕竟每页只显示10条数据,打开页面过程中3秒左右。后面页面调整到显示20条,结果打开这个页面订单微服务偶尔报超时现象。为了解决超时这个问题,将数据组装放到前端,由前端根据ID再请求具体的用户,商家,设备微服务展示相关信息,虽然解决了微服务超时问题,但是前端每次访问页面出现了大量的ajax请求,对前端性能造成非常大的体验影响。也曾经和业务有沟通过,就是这个订单页面显示的时候能不能不显示用户,商家,设备的信息,只显示订单记录相关,然后通过点订单详情进入详情页面再显示用户,商家,设备信息,但是业务这块产品体验又不太好,所以还是得想办法解决这个问题。其实这块订单表当初设计的时候太过于追求数据库的设计范式,导致查询起来关联的太多,其实订单表设计要考虑到第一时间的呈现方式,经过后面优化,其实最简单的方案就是在订单表冗余几个相关字段,用户名称,商家名称,设备名称即可。可能还涉及到一个数据更新的问题,一般的业务场景主键ID不可修改这个是肯定的,但是有些可以修改用户名称什么的,这个时候可能需要同步更新到订单表的那些冗余字段信息,注意这点就可以。

2.大数据单表多条件查询优化

88888.png

订单是按月物理分表的,如t_orderhistory201801,t_orderhistory201802,t_orderhistory201803等,查询条件上的查询时间也是控制了只能选择当月的第1天到当月最后一天,随着平台的业务量越来越大,现在又出现一个问题,当选择的查询条件过多,然后选择的时间区间较大比如选择1号到30号,结果查询速度巨慢等很久才出来结果,甚至也会出现查询异常超时现象。问题引起原因我们也清楚,是一个月的订单数据量太大,查询条件过多,区间过大,然后表又做全局扫描,所以导致慢和超时现象,这块要继续优化方案目前有二种。第一种是将月份表继续分表,比如按周,甚至按天尽量压缩查询的仓库。第二种是限制查询的时间区间,比如每次只能查三天的数据或者更小。另外查询条件较多的情况下要做联合索引(组合索引)。目前我们用最快的时间的时间解决暂时先限制查询的时间区间。

另外提下,数据库架构表设计其实和产品设计都密不可分,双方一定要结合起来做设计,有时候产品细节设计要倾向于数据库表设计。

posted @ 2018-09-01 18:18 心灵之火 阅读(...) 评论(...) 编辑 收藏