[项目实践-实践系列] GaussDB(DWS) 实践系列 - 车辆检索与技战法浅析

举报
听风吹雪 发表于 2020/08/05 11:12:19 2020/08/05
【摘要】 随着时代的发展,三步走战略的逐渐实现。人们的生活越来越好,有车一族越来越多,为了更好的代步,有的家庭甚至是一人一车。那么随之而来造成的,就是愈加繁重的交管压力。 我在某局点测试了我们gaussDB与ISV视频监控平台的部分业务,其中包括车辆检索与车辆技战法。

随着时代的发展,三步走战略的逐渐实现。人们的生活越来越好,有车一族越来越多,为了更好的代步,有的家庭甚至是一人一车。那么随之而来造成的,就是愈加繁重的交管压力。

 

我在某局点测试了我们gaussDBISV视频监控平台的部分业务,其中包括车辆检索与车辆技战法。

 

一. 表介绍

1) 本次车辆场景使用了2张表 vehicle以及vehicle_extra,两张表皆为按天进行分区的分区表。


2) 两表通过info_id关联,info_id为唯一值可作为主键使用。针对同一个info_id, capture_time (抓拍时间) 一定在vehiclevehile_extra表中是相同的。

 

3) capture_time以时间撮形式记录在表中。


二. 使用列存表

车辆检索与技战法的语句中包含关联查询,区间范围选择,点查询等等场景,在实际测试中发现使用列存表的性能会稍强于行存表。

 

三. 车辆检索

自定义特征值搜车与以图搜车在业务上较为相似,区别是自定义特征搜车会圈出几个图片中的特殊地方与数据库中的记录比对。这里我们就以以图搜车为例进行介绍。以下语句通过前端搜索图片,后台获取。


select v.info_id,ve.feature,v.brand_id

from vehicle v

left join vehicle_extra ve

on v.info_id=ve.info_id

where (brand_id in (130)

and (v.capture_time >=1592755200 and v.capture_time <= 1592841355 )

and (license_plate1 <> ‘B123456’ or license_plate2 <> ‘B123456’) and source_id in(22,23))

and feature is not null and feature <> ‘\x’

order by v.capture_time desc limit 24;

 


PS: capture_time >=1592755200 and v.capture_time <= 1592841355 对应的时间范围是2020-06-22 00:00:00 - 2020-06-22 23:55:55。

 

对于这个业务场景我做了2个地方的优化。

1)    开启SMP 

        set query_dop=10


2)    根据业务逻辑修改语句如下

select  v.info_id,ve.feature,v.brand_id

from vehicle v

left join vehicle_extra ve

on v.info_id=ve.info_id

where (brand_id in (130)

and (v.capture_time >=1592755200 and v.capture_time <= 1592841355 )

and (ve.capture_time >=1592755200 and ve.capture_time <= 1592841355 )

and (license_plate1 <> ‘B123456’ or license_plate2 <> ‘B123456’) and source_id in(22,23))

and feature is not null and feature <> ‘\x’

order by v.capture_time desc limit 24;

 

 在以上场景中查询的是2020-6-22这天符合条件的车辆,原语句中限定了vehicle表的时间范围,却对vehicle_extra进行全表扫描。 根据第一部分表部分业务字段的解析,这里我们可以举个简单的例子。在vehicle表中我们查询到的2020-6-22日期里的某辆车的抓拍记录,所能关联到的vehicle_extra表记录绝对不会出现在vehicle_extra2020-6-22日期以外的区间里。

 

因此,修改原语句增加clause条件and (ve.capture_time >=1592755200 and ve.capture_time <= 1592841355 ) 可以将全表扫描改成分区扫描,大幅度降低扫描的数据量从而提升性能。

 

以下是修改语句的性能提升结果。

      

四. 车辆技战法

技战法中测试了四个场景(相似车牌串并,频繁过车,同行车辆以及多点碰撞)。 由于视频监控平台下发到后台的语句是拆分的、包含了大量点查or,不是很好归纳,所以这里就不具体列举业务对应的后台SQL有哪些。

 

1)  相似车牌串并

搜索车牌为XXXXXX (车牌为具体值) 车牌为数相差1位的结果。

 

2)  频繁过车完整车牌查询

   搜索在时间区间内,车牌为XXXXXX(车牌为具体值)过车次数大于等于2的结果。

      

   频繁过车模糊匹配

搜索在时间区间内,车牌为*AT* 过车次数大于等于2的结果。

       

3)  同行车辆

搜索在时间区间内,车牌为XXXXXX同行时间大于5分钟,同行次数大于等于5次的结果。(同行车辆的时间区间最大为三天)

       

4)  多点碰撞

搜索在时间区间内,选择的某个片区两种不同车牌的车辆运行情况。

       

 车辆技战法的场景多为简单基础查询SQL语句,我们的产品在本次测试中性能符合预期。


【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。