• 海量过车数据查询优化总结
    2014-07-04 10:15:05   来源:tranbbs.com   评论:0 点击:

    【摘要】

    随着各地智能交通信息系统工程的持续建设和投入,交通设施设备大量增加,尤其是卡口数量快速增长,导致接入系统的过车数据迅速膨胀。对于发达地区的中等城市而言,每天产生的过车记录有数百万之多,一年就能达到10亿量级,形成海量过车数据。

    此前的系统设计中,未曾考虑到海量数据情形,导致查询效率低下,严重影响用户体验。当查询涉及的记录数过亿时,查询时间长达几千秒,页面动辄超时,测试部对此问题进行了复现。

    过车查询的重要性不言而喻,在公安刑事侦查方面尤为有用,为了彻底解决海量数据查询问题,研究院组织人力对数据库和软件进行了深度优化,经过两天两夜的努力,取得了不俗的成绩,将海量数据查询时间从几千秒缩短到1秒左右。相关技术有望在类似产品中进行推广。

    【关键词】

    海量数据;查询;优化;索引;过车数据;卡口

    一、问题的提出

    卡口系统中,用户经常需要对车牌号进行精确和模糊查找,由于涉及上亿过车记录,查询时间非常长,页面频繁超时,用户投诉不断。鉴于此,系统开发部提供了一份数据库优化方案。该方案的思路是建立oracle双机模式,使用一套Dell的FC存储,包括6块2T硬盘,形成Raid5结构。

    测试部在新版本数据库(简称新库)上进行测试,并与老版本数据库(简称老库)进行对比,结果显示优化后查询效率并未得到提升,反而略有下降,所以新库仅测试了两组数据。对比结果如下:

    从表中还可以看出,无论是新库还是老库,在海量数据查询方面,其效率之低已经远远超出了用户能够接受的正常范围,改进已经刻不容缓。

    考虑到新库优化方向主要是系统稳定性及并发处理能力,未能缓解当前查询效率低下的问题,研究院决定组织人力,从大数据角度出发对系统进行整体优化,希望从根本上改善海量数据查询效率。

    在数据库找到期望的数据集后,如果数据集比较大,例如在几十万的量级(模糊查询),则前端展示时需要进行分页处理。按照现有分页算法,从过车表提取第100万行记录之前的20行记录,耗用时间长达700多秒:

    可见分页算法也存在缺陷,需要设计更为合理的分页算法。

    二、解决思路

    根据优化对象的不同,优化技术通常千差万别,但核心思想是一致的,那就是找到性能瓶颈,分析瓶颈产生的原因,利用合理的设计避开瓶颈,改善系统性能。

    我们知道,对于海量数据查询而言,查询效率严重依赖于查询时所使用的索引,而不同索引对海量数据查询的影响有天壤之别。要建立合适的索引,就必须对数据进行深度分析,结合数据特征,针对不同应用场景使用不同索引,才能实现快速高效的目标。

    对于我们的过车数据,其特征如下:

    每天产生的过车记录数为数百万至数千万量级,每年产生记录数为10亿至100亿量级;

    每条过车记录会存储过车时间、卡口ID、车牌号等信息;

    大型城市的卡口数量为几百、几千的量级;

    大型城市的车辆数量为几百万的量级。

    在决定使用哪一个索引最为合理时,有一条很重要的规则,那就是选定的索引要能够迅速缩小需要处理的数据集规模,例如从100亿或10亿量级快速收缩到100万或10万以里。只要数据规模缩小到100万或10万这样的量级上,数据库就能够从容应对。

    回到具体问题上,对于车牌号查询,此前使用了基于“过车时间”的索引,利用“过车时间”索引,数据库能够快速定位到符合指定时间范围的数据集,但是这个数据集太大了,仅一天的数据规模就超过了百万,一年的数据规模则数以亿计,在如此庞大的数据集中,数据库需要逐条扫描,以查看是否满足指定的车牌号条件,这就好比大海捞针,谈何容易。

       考虑到之前总结的数据特征,在一个大型城市中,虽然一年的过车数据规模高达10亿以至100亿量级,但真正的车辆数目,也就是几百万的量级。以天津为例,机动车保有量超过240万辆,在路面上经常行驶的车辆数量,可按100万辆计算,则每辆车一年内的平均过车记录数在1万量级。由此可见,如果我们能够使用车牌号上建立的索引,对车牌号精确查询而言,就能够迅速将数据规模缩小到一万量级,在这个很小的数据集上,再查看时间是否满足设定的条件,这样的计算量对数据库而言,尤其是性能优异的oracle,近乎于用导弹打蚊子,可在瞬息之间(秒级)得到期望的结果。在orcale中,可通过在查询语句中增加“提示(hint)”来告知oracle使用我们推荐的索引,而不是oracle自行采用的索引,即可实现上述目标,如图 2所示。

     

    相对而言,车牌号精确查询很容易,但模糊查询就复杂多了,用户的输入千差万别,导致普通索引无法正常使用,为此需要建立一些非常规索引,以应对各种复杂的模糊查询条件。

       对于分页查询,现有算法的缺陷较为明显,尤其是处理大数据量时,在多层次的查询语句中,对大数据量做了若干函数调用,其实最终只需要一页的数据,导致数据库做了很多无用功。改进措施也很简单:调整内层循环,通过rowid定位单页记录,只在最外层执行必须的函数计算。

    三、实践情况

    对于车牌号精确查询,通过在查询语句中强制使用车牌号字段上建立的索引,避免oracle采用“过车时间”索引,将数亿过车记录的查询时间从数千秒迅速缩短到秒级,大幅度提高了海量数据查询效率,有效改善了用户体验。在新版本数据库上,与原有软件的对比测试结果如下:

           表 2 优化前后车牌号精确查询效率对比

    对于车牌号模糊查询,我们建立了若干非常规索引,根据用户的输入情况,运行时决定使用哪一个索引,有效提高了查询效率。在新的设计中,当用户不确定的车牌号越少,查询时间就越短,反之则查询时间变长,这是由计算机原理决定的,也符合人类对现实的感受。在新版本数据库上,与原有软件的对比测试结果如下:

    表 3 优化前后车牌号模糊查询效率对比

    针对模糊查询优化时,引入了6个新索引,为了检查增加索引后对数据库的写入性能是否有影响,我们执行了大批量写入测试,结果显示新增索引对写入性能的影响很有限,几乎可以忽略。

    对于数据分页显示,经过优化后,抓取100万条记录前的20行记录,耗时降到1秒左右,如下所示:

    四、效果评价

    由查询结果对比可知:

    优化之后,车牌号精确查询速度得到了极大的提升。在2年1亿的数据集中执行精确查询,用时仅2s左右。

    优化之后,车牌号模糊查询速度也得到了大幅提升。仅在模糊4位车牌号(只知道3位连续车牌号)的情况下,才出现了查询时间过百秒的结果,而且还是在2年1亿的数据集中执行查询。

    关于oracle,有两种常见看法,一是认为oracle只有在数据集为千万级别时才能取得较好的查询效率;二是认为增加几个索引会导致数据库性能迅速下降。通过此次测试,证明了当前增加的索引对数据库性能几乎没有影响;从数据库原理出发,结合当前测试结果,经过简单推算,对于过车数据而言,事实上在100亿量级,oracle完全可以取得不错的效果。

    本文展示了在海量数据查询优化中使用的分析方法和优化技术,有助于今后遇到类似问题时,尽快完成性能优化,提升产品性能。

    本文优化的主导思想包括以下几点:分析数据集特征,建立恰当的索引;分析用户操作,针对不同操作采用不同索引,提升查询效率,改善用户体验。

    五、推广建议

    在给定条件下使用哪些技巧,对于一个应用程序的性能来说非常重要。一个错误的选择可能会引发数据库启动大海捞针式扫描,并导致数据库性能急剧下降。而如果做出正确的选择,就可以合理使用资源,使那些已经运行了几个小时,甚至几天的进程,在几分钟甚至几秒内得以迅速完成。

    产品性能是个永恒话题,好的产品质量,总是伴以优异的产品性能。设计产品时,应从用户角度出发,站在用户角度看待问题。只有过硬的产品性能,才能获得用户的青睐,才能在市场上占有一席之地。

    海量数据查询性能优化的方法很多,但都殊途同归,本文可以作为其它产品性能优化的参考,起到抛砖引玉的作用。


    中央研究院

    吴明远、李禹霆、曹海毛、李晓光

    责任编辑:佚名

    相关热词搜索: 数据查询

    上一篇:用发展的眼光看我们当下的程序员
    下一篇:企业知识产权风险管理及易华录知识产权工作启示

    [内刊文章:42 篇]刊物介绍
      中央研究院介绍:由易华录中央研究院负责建设、管理的自媒体运营项目——《易华录中央研究院》微信公众号,正式上线。利用新媒体网络传播平台,开展智能交通与智慧城市领域的技术、产品和方案交流与传播。
    联系方式
    • 白先生:010--53396817