基于搜索引擎的慢查询优化系统

2017-04-22 10:11陈伦跃殷峰
现代计算机 2017年8期
关键词:搜索引擎检索数据库

陈伦跃,殷峰

(1.四川大学计算机学院,成都 610065;2.西南民族大学校园网络管理中心,成都 610064)

基于搜索引擎的慢查询优化系统

陈伦跃1,殷峰2

(1.四川大学计算机学院,成都 610065;2.西南民族大学校园网络管理中心,成都 610064)

信息系统一般需要一个数据持久层来对系统中的信息进行存储和查询,而数据持久层所面临的慢查询问题会极大地影响系统的用户体验。目前的研究可以较好地解决由于数据量的增长所带来的慢查询问题,而对由业务分化带来的慢查询问题无能为力。当业务分化后,数据源将处于不同的业务部门,甚至不同公司的管理下,数据查询时连接操作大大增加。分析在实际生产环境中所面对的慢查询问题,创造性地提出一种使用搜索引擎技术用于改善数据持久层查询性能的系统。该系统具有低侵入性、快速开发、性能优良等优点。

慢查询;搜索引擎;查询优化;系统设计

0 引言

信息系统一般需要一个数据持久层来对系统中的信息进行存储和查询。当信息系统所承担的业务快速扩展之后,其已有的数据持久层将面临诸多挑战。其中慢查询问题是很多系统都会面临的挑战,且会极大地影响系统的用户体验。当业务规模快速增长后,系统处理的数据规模快速增长,使得数据库的查询变慢。针对数据量增长带来的慢查询问题,已有相对充分的研究。但更严重的问题是随着新的业务不断扩展,老的业务不断分化,系统中会出现越来越多的独立子系统使得系统整体的数据模型越来越复杂。不同子系统的数据源往往处于不同业务部门甚至不同公司的管理之下,而一些业务需求常常横跨了多个独立的子业务,造成许多查询需要链接多张表,这也会带来慢查询问题。

针对慢查询问题,已有的方案主要着眼于对数据存储本身的优化,但在实际生产中,即使每个子系统的查询得到了充足的优化,跨多个子系统的业务的查询服务仍然会受制于连接的性能。由于业务的分化扩展,多个数据源的链接操作在实际生产中是无法避免的。为了解决业务分化带来的慢查询问题,需要一种可以独立于原有数据持久层之外,与业务架构无关的优化方案。

针对业务分化造成的慢查询问题及已有解决方案的不足,本文提出了基于搜索引擎的慢查询优化系统。该系统综合了许多现有方案的优点。首先,系统的侵入性低,可以独立于原有数据持久层提供服务,既不需要在系统初期做出特殊设计,也不需要对已有的业务代码进行大规模的修改,最重要的是可以解决由于业务分化带来的慢查询问题;其次,该系统具有良好的查询性能,系统使用搜索引擎集群提供查询服务的增强,可以从根本上缓解慢查询问题,当业务进一步发展时也可以弹性地对系统进行扩容;最后,搜索引擎有许多成熟的开源产品可以使用,对已有系统使用该解决方案进行改造需要的研发、资金、时间成本低。

1 相关工作

为了解决慢查询问题,已有3种传统解决方案。

第一种,进行数据库性能的调优,读写分离,分库分表等工作,如文献[1]讨论了在SQL Server上的调优问题。但是这种解决方案只能暂时缓解慢查询问题,随着业务的进一步发展,仍然会面临性能的瓶颈,因而这是一种治标不治本的解决方案;其次,该方案只能优化由数据量增加带来的查询性能瓶颈,不能改善由于业务分化,数据连接操作变多带来的性能瓶颈。

第二种,使用新的数据存储技术改写原有的数据持久层,例如文献[2][3]中提到的NoSQL数据库。这些新型存储技术已经在实践中证明了其具有良好的性能,可以有效地解决慢查询问题。但是使用这种方案将大规模地改造已有的数据持久层,面临着数据迁移,业务分流等问题,势必会影响已有系统的正常运行。同时,该解决方案也和第一种方案一样不能改善由于业务分化,数据连接操作变多带来的性能瓶颈。

第三种,为原有的系统增加分布式索引,如文献[4-5]中提到的解决方案便可以用于改善数据库的检索性能。这种解决方案具有系统侵入性小的优点,不会大规模影响到原有系统的运行;同时具有较好的性能,可以有效地解决慢查询问题;最后也能够较为有效地解决业务分化的问题。但是该解决方案较为复杂,没有成熟的开源产品可以使用,尚处于理论研究阶段,因而该方案在实际工程中的使用也较为困难。

在搜索引擎应用的研究上,目前主要着眼于在垂直检索领域,利用搜索引擎信息检索的能力为相应的专业领域提供参考建议与决策支持,如文献[6][7]分别研究了搜索引擎在图书馆情报学和农业上的应用。而很少有将搜索引擎用于提供信息系统底层服务的研究。

基于对慢查询问题及已有解决方案不足的分析,本文创造性地提出了使用搜索引擎优化慢查询问题,开阔了搜索引擎应用的研究范围,也为解决慢查询问题提供了思路。

2 理论分析

为了优化查询性能,无论关系型数据库、NoSQL数据库,还是搜索引擎,都有相应的索引机制。不同的索引机制决定了不同系统在性能上的差别。本节将对数据库索引与搜索引擎索引的异同进行讨论。

传统的关系型数据库与NoSQL数据库多使用树形结构的正排索引,如关系型数据库中常使用B+树,NoSQL数据库中常使用LSM树。这些树形结构的索引读写性能平衡。当这些数据库进行查询时,将从根节点开始,自顶向下访问索引文件,其时间代价为O(logn),其中的n为数据的规模。与数据库不同,搜索引擎主要使用倒排索引技术。以开源搜索工具包Lucene的索引为例,为一组单词建立索引时,其结构如图1所示:

图1 搜索引擎索引结构

搜索引擎的倒排索引由3部分组成,分别是词典索引(Term Index)、词典(Term Dictionary)、文档位图(Position Graph)组成。词典索引使用前缀树进行组织,对关键字前缀建立了索引。词典中包含了所有的关键字,并指向相应的文档位图。文档位图中记录了每个关键字在哪些文档中出现过,及指向这些文档的指针。当搜索引擎进行检索时,它先使用词典索引对检索的关键字进行查询,当在词典中查到相应的关键字之后,直接从文档位图中读出所有待检索文档的位置信息。可见,搜索引擎在查询时主要的性能开销为对词典索引和词典的访问,其时间代价为O(loglen),其中的len为关键字长度的规模。

从上述分析中可以发现,相较于数据库的索引,搜索引擎使用的倒排索引在检索时具有以下的优点:首先,当数据量较大时,数据的规模n远远大于关键字长度len的规模,在对一张长表进行检索时,搜索引擎检索的时间代价O(loglen)远小于数据库检索的时间代价O(logn);其次,搜索引擎的词典索引文件及词典只对关键字的种类进行索引,体积更小,可以在内存中保存,而数据库的索引只能保存在磁盘中,因而对搜索引擎索引文件的访问速度更快;再而,通用信息检索引擎对不同的数据类型采用了不同的索引方式,上面分析是针字符串的,例如针对整数,有TrieIntField类型,针对经纬度,就可以用GeoHash编码,检索引擎几乎可以为文件中的任意字段建立索引,而数据库的索引对某些字段的索引效率较低,如数据重复且分布平均的表字段;最后,在数据库中给两个字段独立建立的索引无法联合起来使用,必须对联合查询的场景建立复合索引,而通用信息检索引擎可以使用AND或者OR组合使用索引进行检索。需要指出的是,在由于业务分化造成的慢查询问题中,数据库分别属于不同的业务部门,甚至不同的公司管理,它们无法建立复合索引,也无法使用NoSQL技术构建一张公用的大表,这时搜索引擎对多表联合进行检索的能力更显得重要。

综上所述,虽然数据库的搜索结构具有读写平衡的优点,但在进行查询操作时,搜索引擎的效率将明显高于数据库,特别是当检索数据量较大时,检索一些不适合建立数据库索引的字段时,或者需要对多个字段进行检索时,这种性能差距将更为巨大。

3 实验验证

为了验证两种解决方案在实际生产中慢查询的性能差距,本文使用MySQL数据库及OpenSearch搜索引擎进行了实验对比。实验平台配置如下:操作系统:Win7sp1,处理器:i5-3470,内存:12GB,MySQL数据库与OpenSearch搜索引擎分别使用最新(2016年8月)的免费版,实验中禁用了各自的缓存。实验数据使用MovieLens数据集[8],该数据集包含了:由260000个用户针对40000部电影打出的24000000个电影评分。实验中为搜索引擎和数据库分别建立了合适的索引结构。实验数据集的数据模型如图2所示:

图2 实验数据集数据模型

实验中设计了三种查询场景来对比数据库查询速度与搜索引擎查询速度之间的区别。这三个实验分别是:查找2016年所有的动作电影;查找2016年前1000条用户为电影打出的满分;查找2016年所有被用户打过满分的动作电影。这三个实验分别包含了对小表的查询,对大表的查询,对大表的连接操作三种代表性情形。实验对每种查询场景分别重复了1000次,并取得了查询时间的平均值。实验结果如图3所示:

图3 实验结果

三个实验展现了使用搜索引擎替代数据库执行某些慢查询语句时的性能优势。当涉及到全文检索(如实验中的genres字段),超长表(如实验中的ratings表),多表链接(如实验三中设计的场景)时,搜索引擎执行相同的查询的速度远快于数据库,这验证了上文理论分析的正确性。而当只是对一张较小的表(如实验一中的场景)进行查询时,这种优势便不明显了,这是由于当问题规模较小时,搜索引擎的检索速度反而会由于更复杂的计算而慢于数据库。同时,实验证明了,在慢查询问题中,连接操作才是最为消耗性能的,在使用数据库进行执行时,实验三的执行时间是实验一和实验二执行时间之和的5.1倍。可见,优化单表的查询速度并不是解决慢查询问题的核心途径,优化连接性能甚至避免过多的连接才是解决慢查询问题的方法。

4 基于搜索引擎的慢查询优化系统

基于上述理论分析及实验结果,本文提出了一种基于搜索引擎的慢查询优化系统。该系统遵循CAP理论[9]和BASE原则[10]进行设计,其核心思路是:读写分离,主要使用搜索引擎提供读服务,保障核心查询服务的高可用性,主要使用原有数据持久层提供写服务,保障写入性能不下降;写入数据与搜索引擎进行异步的数据同步,保障数据的最终一致性;搜索引擎独立于数据库进行集群部署,保障系统的容错性,弹性扩容性与低侵入性。下面将具体描述该系统。

在数据写入时,由于数据库在写入时的性能、可靠性优于搜索引擎,所以系统对数据库进行同步的写入。对搜索引擎文档的写入操作为:先写入缓存并加以持久化,缓存记录的信息为预写式日志。当缓存中仍然有数据没有写入搜索引擎的文档库中时,便持续异步向搜索引擎中写入数据。最后,系统定期对比数据库的日志信息与缓存信息,重做缓存或搜索引擎中的写入失败。这样的写入方案一方面利用了数据库的事务性保证数据不会丢失,另一方面用缓存机制与异步写入解决了搜索引擎文档写入性能瓶颈,定时的数据校正保证了数据的最终一致性。写入的系统流程如图4所示:

图4 数据的写入流程

在数据进行查询时,系统先对查询的复杂程度进行判断。当查询所涉及到的表规模小于10万、不涉及到1个以上的链接操作、不涉及到对数据库未建立索引的字段进行查询,系统判定为简单查询。执行简单查询时,搜索引擎的性能优势并不明显,因而直接使用数据库进行查询并输出。而当执行复杂的查询时,系统首先使用搜索引擎进行查询。当搜索引擎搜索失败时,失败可能是由于搜索引擎中相应的数据尚未同步造成的,因而此时系统继续使用数据库进行搜索并输出。这样的设计保障了该系统中查询操作的高可用性。查询的系统流程如图5所示:

图5 数据的查询流程

基于上面对读写流程的讨论,从整个信息系统的层次架构上来看,该系统中除数据库为原有的以外,其余部分皆是新增至原始的数据持久层之上的,搜索引擎只提供查询加速的服务,最终的数据仍然以原有的数据源层为准,搜索引擎不直接与数据源层进行交互,因而本文提出的系统可以看作增强数据库查询性能的中间件。系统架构如图6所示:

图6 系统层次结构

该系统架构有以下优点。首先,该系统作为独立的一层,可以单独选取工程方案,有许多实用的开源产品可供使用,节约了研发成本与时间;其次,系统支持弹性扩展,当查询性能再次遭遇瓶颈时可以继续扩展性能,而不需要对其他层做出修改;其次,系统对原有系统的侵入性小,原有的业务层和数据持久层可以不做改变,这有利于系统的稳定性;最重要的是,该系统作为中间件可以横跨多个子业务为高层业务提供统一的分布式索引,无论数据持久层分裂成了多少个单独管理的数据源,该系统都只对应着同一个搜索引擎,并一同建立索引,这相当于在写入搜索引擎时便已经对所有的表的字段进行了连接操作,这解决了由于业务分化造成的慢查询问题。

综上所述,基于本文提出的慢查询优化系统具有以下一些优点:首先,可以有效解决由于业务分化带来的慢查询问题;其次,该解决方案有着优良的性能,在性能不足时还可以继续弹性扩容而不影响其他层的业务;最后,该解决方案有着成熟的开源搜索工具可以使用,稍加开发便可以成为查询优化中间件,具有极低的时间、资金成本。

5 结语

本文分析了生产环境所面临的慢查询问题,查询会极大地影响系统的用户体验。本文指出了业务的分化是造成这类问题的主要原因。针对该问题,已有三种解决方案,分别是:针对慢查询语句进行调优,使用NoSQL技术重构系统数据持久层,设计并架设合适的分布式索引。这三种解决方案都有着明显的缺点,因而较难满足实际应用中的需求。基于实际生产中的需求及已有方案的缺点,并结合对数据库及搜索引擎索引原理的分析,本文提出了基于搜索引擎的慢查询优化系统,该系统能够有效解决实际生产中面临的慢查询问题,同时具有低侵入性、快速开发、性能优良等优点。本文对信息系统解决慢查询问题有着实际的参考意义。基于该系统和已有的开源搜索工具可以进一步开发出专用的查询优化分布式中间件,有着进一步研究的价值。

[1]朱喜梅.基于SQL Server数据库的性能调优策略与研究[D].哈尔滨理工大学,2009.

[2]覃雄派,王会举,李芙蓉,等.数据管理技术的新格局[J].软件学报,2013(2):175-197.

[3]申德荣,于戈,王习特,等.支持大数据管理的NoSQL系统研究综述[J].软件学报,2013(8):1786-1803.

[4]吴炜,苏永红,李瑞轩,等.基于DHT的分布式索引技术研究与实现[J].计算机科学,2010,37(2):65-70.

[5]隆飞,翁海星,高明,等.基于LSM Tree的分布式索引实现[J].华东师范大学学报自然科学版,2016(5).

[6]周威.知识搜索引擎在图书馆参考咨询中的应用研究[D].东北师范大学,2010.

[7]刘艳华,徐勇.不同搜索引擎在农业领域的应用效果对比[J].农业网络信息,2009(8):25-29.

[8]MovieLens.http://grouplens.org/datasets/movielens/

[9]Gilbert S,Lynch N.Brewer's Conjecture and the Feasibility of Consistent,Available,Partition-Tolerant Web Services[J].Acm Sigact News,2002,33(2):51-59.

[10]Pritchett D.BASE:An Acid Alternative[J].Queue,2008,6(3):48-55.

The Slow Query Optimization System Based on Search Engine

CHEN Lun-yue1,YIN Feng2
(1.College of Computer Science,Sichuan University,Chengdu 610065; 2.The Campus Network Management Center,Southwest University for Nationalities,Chengdu 610064)

Generally,there is a data persistence layer to store and query the information in any information system.The often faced slow-query problem will greatly affect the system's user experience.Present studies can solve some problems caused by the growth of the data quite well.But when facing the problem caused by the business differentiation,the present studies work bad.Usually,the data source will be under the management of different business divisions,even different companies,which caused the increase of join operations in data querying.Analyzes the slow-query problem faced in real production environment,and creatively puts forward a system using the search engine technology to improve query performance.The system has several advantages including:low invasive,agile development,good performance,etc.

Slow Query;Search Engine;Query Optimization;System Design

1007-1423(2017)08-0026-05

10.3969/j.issn.1007-1423.2017.08.006

殷锋(1972-),男,贵州榕江人,教授,研究方向为数据挖掘、中间件、分布式计算、软件测试陈伦跃(1992-),男,四川成都人,硕士研究生,研究方向为态势感知、民航大数据

2016-12-15

2017-02-20

猜你喜欢
搜索引擎检索数据库
Chrome 99 Canary恢复可移除预置搜索引擎选项
世界表情符号日
瑞典专利数据库的检索技巧
在IEEE 数据库中检索的一点经验
一种基于Python的音乐检索方法的研究
数据库
数据库
数据库
数据库
基于Lucene搜索引擎的研究