CN106649462A - 一种针对海量数据全文检索场景的实现方法 - Google Patents
一种针对海量数据全文检索场景的实现方法 Download PDFInfo
- Publication number
- CN106649462A CN106649462A CN201610849788.2A CN201610849788A CN106649462A CN 106649462 A CN106649462 A CN 106649462A CN 201610849788 A CN201610849788 A CN 201610849788A CN 106649462 A CN106649462 A CN 106649462A
- Authority
- CN
- China
- Prior art keywords
- lucene
- node
- retrieval
- files
- data
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/30—Information retrieval; Database structures therefor; File system structures therefor of unstructured textual data
- G06F16/33—Querying
- G06F16/3331—Query processing
- G06F16/334—Query execution
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/30—Information retrieval; Database structures therefor; File system structures therefor of unstructured textual data
- G06F16/31—Indexing; Data structures therefor; Storage structures
- G06F16/313—Selection or weighting of terms for indexing
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Software Systems (AREA)
- Computational Linguistics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明提供了一种针对海量数据全文检索场景的实现方法,属于海量数据全文检索领域。本发明将Lucene引入检索引擎,对集群中已经存在的数据文件建立Lucene索引文件。在每个存储Lucene索引文件的节点上,设置有一个守护进程对该节点的Lucene索引文件进行维护。本发明优化协调器对fragment的调度机制,对每个执行节点进行计数判断,调整每个fragment的执行位置,以均衡节点资源。本发明还优化全文读取引擎机制,优先采用Lucene进行检索,当出现问题时调用RCFile检索,以保证检索的持续性和正确性。本发明提高了检索性能,可更加合理地利用集群的资源。
Description
技术领域
本发明涉及海量数据全文检索领域,具体涉及一种针对海量数据全文检索场景的实现方法。
背景技术
在当今信息爆炸的时代,每个单位或个人都在为信息的快速增长做出了各种贡献。信息的种类也在不断的扩展,越来越多的非结构化信息不断出现,包括企业的各种报表、帐单、电子文档、网站的各种元素、图片、传真、扫描影像,以及大量的多媒体的音频、视频信息等等。所有的存储数据中,有85%采用的是非结构化格式的,非结构化信息每三个月增长一倍。由于信息格式的差异很大,所以基本无法整合为统一的接口以方便使用。
而全文检索技术,就是以数据诸如文字,声音,图像等为主要内容,以检索文献资料的内容而不是外表特征的一种检索技术。
Lucene是开放源代码的全文搜索引擎工具包,凭借着其强劲的搜索功能和简单易用的实现,在国内外已经很普及,甚至一度出现了言搜索必称Lucene的盛景。但是任何一个软件,包括所有伟大的软件都有这样或者那样的“缺点”和各自适用的领域,Lucene也不例外。首先,Lucene的内建不支持群集,Lucene是作为嵌入式的工具包的形式出现的,在核心代码上没有提供对群集的支持。如何利用Lucene来进行全文检索以提高检索性能需要研究一种可行方案。
发明内容
本发明提供了一种可以在海量数据平台下实现全文检索的方法,基于Lucene来进行全文检索以提高检索性能。
本发明提供的针对海量数据全文检索场景的实现方法,在检索引擎对输入的SQL语句分析后形成执行计划树,将执行计划树切割成执行单元fragment,通过协调器分发到节点上执行并返回结果。本发明将Lucene引入检索引擎,对集群中已经存在的数据文件建立Lucene索引文件。一个数据文件对应有一个或多个Lucene索引文件,一个Lucene索引文件存储在一个节点上,在每个存储Lucene索引文件的节点上,设置有一个守护进程对该节点的Lucene索引文件进行维护,保持Lucene索引文件与RCFile文件的一致性。后面说明中,Lucene索引文件可简称为Lucene文件。具体地,本发明的检索通过如下几方面进行改进。
第一方面,优化协调器对fragment的调度机制。
在一个fragment中,有一个结构体range,range中记载有Lucene索引文件地址列表;
在检索时,遍历所有fragment中的range,对每个range,获取该range对应的Lucene索引文件地址列表。对列表中的每个Lucene索引文件地址,执行过程(1)和(2):(1)判断该地址是否位于所执行的fragment的本地节点上,若是,则设置该索引文件所在节点的预加值A为1,若不是,设置该索引文件所在节点的预加值A为设定的固定最大值;(2)将该索引文件所在节点的当前计数B,加上预加值A,得到新的计数值C。每个节点的计数值初始设置为0。在得到该range的每个Lucene索引文件所在节点的计数C后,选择其中计数C最小的节点,作为该range的执行节点,然后更新该节点的当前计数B为对应的计数值C,标记该range将最终在该节点上执行。
第二方面,优化全文读取引擎机制。
节点执行一个fragment时,若对应的Lucene索引文件在本地节点,直接通过JNI调用Lucene接口,获取检索结果集;若对应的Lucene索引文件在远程节点,调用socket接口通过远程tcp访问远程节点的Lucene接口,获取检索结果集;socket接口还用于RCFile与Lucene中元数据变化时的更新;JNI表示Java本地接口,tcp表示传输控制协议。
若调用访问Lucene接口时,对应节点上维护Lucene索引文件的守护进程已经挂掉,或远程tcp连接无法建立时,则执行节点直接选择读取RCFile文件;若读取Lucene索引文件出错时,执行节点重新调用该Lucene索引文件对应的RCFile文件,重新进行检索。
本发明的针对海量数据全文检索场景的实现方法,还包括如下方面:
第三方面,实现全文检索的相关度排序;相关度的排序通过设置权重实现。在检索某个字段时,给该字段设置权重,在Lucene检索时,将权重加入字段中,检索返回根据权值排序的结果数据,将各Lucene检索的结果数据汇总并根据权重再进行一次排序,最后将符合以相关度排序的数据结果集返回给用户。在检索时,若是分组数据,对分组数据的权重值先进行融合计算,再按照融合后的权重值,对分组数据进行相关度的排序。
本发明提供的针对海量数据全文检索场景的实现方法,其优点和积极效果在于:
(1)本发明实现在全文检索或条件字段检索时,使用Lucene文件进行数据读取,相对于现有检索采用的RCFile文件,不需遍历整个文件一次,极大地提升了检索性能。
(2)通过优化协调器中对fragment的调度机制,让某一个节点不会因为执行过多的range而过多地消耗资源,并尽可能保证执行本地读写,实现检索效率的保证,同时也能保证节点的负载相对比较均衡,同时能合理地利用集群的资源。
(3)本发明在进行全文检索时,首先调用Lucene进行检索,若访问Lucene出现问题时调用RCFile检索,保证检索的持续性和正确性。
附图说明
图1为本发明进行检索的整体流程示意图;
图2为本发明的协调器对fragment进行调度处理的流程示意图;
图3为本发明的全文读取引擎处理流程图;
图4为本发明的相关度排序处理流程图。
具体实施方式
为了使本发明的目的、技术方案及优点更加清楚明白,以下结合附图和实施例,对本发明的技术方案作进一步详细说明。
现有海量数据进行检索时,默认使用的是RCFile做为数据存储文件格式。RCFile是Hive推出的一种专门面向列的数据格式,是一种基于行列混合存储的优秀存储格式,满足了快速数据加载和动态负载高适应的需求。它遵循“先按列划分,再垂直划分”的设计理念。当查询过程中,针对它并不关心的列时,它会在IO上跳过这些列。需要说明的是,RCFile并不是真正直接跳过不需要的列,并跳到需要读取的列,而是通过扫描每一个row group的头部定义来实现的,在整个Block级别的头部并没有定义每个列从哪个row group起始到哪个row group结束。在读取RCFile文件时,若检索的只是部分数据时,也要遍历文件内容,然后才能根据相关算法得到相关数据。因此,在海量数据扫描时,由于RCFile文件检索是线性的,检索性能相对比较费时。而Lucene存储介质对文件按一定条件切割,Lucene文件是根据索引直接读取对应内容,不用遍历整体文件,从效率上来说,检索速率会有一定的提高,会高于直接线性读取文件。
性能提升场景有:
1.等值查询:类似select*from tbl where a=1;select*from tbl where a in(1,2,3);
2.模糊查询:类似select*from tbl where b like‘value%’;
3.正则查询:类似select*from tbl where b rlike‘/value[a]/’;
4.计数查询(count):类似select count(*)from tbl where a>1;
上面,tbl表示文件名称,a、b表示查询字段,value表示查询字符。
检索引擎进行检索的整体流程,如图1所示。检索引擎在用户输入相关查询语句后,使用基于SQL语言进行相关字段的检索。其次对SQL语句分析,分析语句词法语法,分析检索语义,根据对应文件信息的元数据和语法分析结果,形成执行计划树。然后,把执行计划树切割成具体的执行单元:fragment;通过协调器,把对应fragment分发到具体的节点上执行并返回结果。协调器会根据具体的文件分布情况及节点使用情况,动态分配执行节点,之后会把任务提交给每一个执行节点的读取引擎,读取对应的底层Lucene文件。最后把各个节点返回的结果汇总到协调器,返回最终结果给用户。所述的节点是指存储集群中的计算机、服务器等存储数据、处理数据的设备节点。
本发明提供的针对海量数据全文检索场景的实现方法,主要改进之处在于:(1)在协调阶段对调度机制的优化;(2)全文数据读取引擎部分的优化;(3)实现全文检索的结果数据的相关性排序。下面分别说明各改进方面。
本发明的第一方面,优化fragment的调度机制。在每一个fragment中,一个最小的文件读取单元用一个结构体range来描述,该range会记录该文件所在节点列表,因为复本的存在。基本的调度原则是,可以让每一个range尽可能平均地分布在不同的节点上,不会让某一个节点因为执行过多的range而过多地消耗资源。所以,在协调器阶段时,会根据所有range的总量,计算某一个节点已经执行的range的数目,每次选择节点时,会选择使用量最小的节点,作为执行节点。同时,为了执行的速度,若该节点一旦要远程访问时,则执行的节点计数会给一个很大的值,以保证尽可能执行本地读写。既保证了检索的效率,同时也能保证节点的负载相对比较均衡,同时能合理地利用集群的资源。
执行计划树是由一系列的fragment组成,每个fragment是执行计划树的最小执行单元,最后在每个节点上执行的就是一个或多个fragment。每个fragment有自己独立的处理数据的操作,如读取数据、执行对应函数,fragment之间是通过RPC(Remote ProcedureCall Protocol,远程过程调用协议)实现数据传输,最终汇总给用户。在读取文件的fragment中,会有一个结构体range描述一个数据文件的所有存储节点host、名字和读取大小,一个range对应一个数据文件。Range中记录有RCFile和Lucene文件的信息,RCFile的信息包括:文件名、文件地址列表、文件大小、是否创建Lucene文件、文件状态等;Lucene文件信息包括:文件名、文件地址列表、文件大小、文件状态等。原始流程中,因为复本的存在,所以一个数据文件可能会存在不同的节点上。而本发明对一个原始数据文件做Lucene索引操作时,会保证Lucene能均衡地分布在整个存储集群中,因为字段组合的不同,在对一个数据文件建立Lucene索引时,可能会生成含有检索字段的多个Lucene索引文件,而这些Lucene索引文件也会分布在多个节点上。所以,为了让检索能在保障效率的基础上最大化的使用集群,需要对检索的执行节点进行协调。所以,检索时,会遍历整个fragment中的range,调整每个fragment的执行位置,对每一个执行节点进行计数判断,选择一个计数最小的节点,作为该fragment的执行节点。
本发明的协调器对fragment的调度机制的流程如图2所示。在一次检索中,首先循环查找所有的fragment,找到一个range,获取该range对应的Lucene索引文件地址列表。根据该range中的Lucene索引文件地址列表,选择一个Lucene索引文件地址,先判定该索引文件地址是否在所执行的fragment的本地节点上,确定索引文件所在节点的预加值A。本地节点执行引擎在获取到执行任务后,将生成一个执行列表,若当前访问的文件存在该执行列表中,并且该文件存储在本地节点,即认为是本地访问模式,否则认为是远程访问。若不在本地节点,则在访问该索引时,会导致一次远程查询,无疑是比较费时的,所以该索引所在节点host的预设值A为一个设定的固定最大值,实际操作中该值可设置为max(int64)。若在本地节点,此时该索引的访问则是对本节点内部资源的访问,此时设置该索引文件所在节点host的预加值A为1。将该索引所在节点的当前计数B,加上设置的预加值A,得到新的计数值C。将该range的所有索引所在的节点都进行遍历,按照上面规则得到各索引所在节点的计数C后,选择其中一个计数C最小的节点,作为该range的执行节点,然后更新该节点的当前计数B为对应的计数值C,标记该range会最终在这个节点上执行。每一个节点的计数值初始均设为0。对所有的range都进行上面过程,使得协调器根据range中的计数采用最小先执行的原则,进行文件检索,最终可以保证每个节点的数据的均衡且保障效率。
本发明的协调器还采用最小先执行、单点多并发顺序控制的原则,进行实际文件查询的调度。最小先执行是指本次待查询的文件数最小的节点,优先执行。单点多并发顺序控制是指当一个节点内出现多个需要并发查询的文件时,将同一块磁盘上的文件由并发访问变成顺序访问。需要说明的是,此处的顺序访问也可以是并发的顺序访问,即一次并发访问2个或多个文件,该处并发访问的文件数受配置文件控制。
本发明的第二方面,是优化全文读取引擎机制。
Lucene本身就是一套用于全文检索和搜寻的开源程式库,由Apache软件基金会支持和提供,并且提供了一个简单却强大的应用程式接口,能够做全文索引和搜寻。同时Lucene也是当前以及最近几年最受欢迎的免费Java信息检索程序库。同时为了保障兼容性,检索也可以自由切换读取原始的RCFile文件数据。因为Lucene文件无复本机制,所以节点文件很可能会出现问题,所以当读取Lucene节点有故障时,会选择读取该Lucene文件对应的RCFile文件,以保障检索流程的正确性及可用性。同时,该读取引擎混合了Lucene读取(本地及远程)、RCFile读取,使该引擎有了一定的容错能力。
本地节点在执行一个fragment时,使用两种方式调用Lucene实现检索:
1.若对应的Lucene索引文件在本地节点时,直接通过JNI(Java本地接口)调用Lucene的接口进行检索,直接访问对应的数据文件,获取对应的结果集;
2.若对应的Lucene文件在远程节点时,此时每个节点有一个Lucene的socket接口,通过访问该socket接口,进行tcp远程访问Lucene进行检索,获取数据结果集。同时socke接口还实现RCFile与Lucene的元数据变化时的更新。调用Lucene的接口就是指访问对应节点上Lucene的守护进程。
执行节点调用访问Lucene接口时,出现错误:
1.若是对应节点上维护Lucene索引的守护进程已经挂掉,或远程tcp连接无法建立时,则执行节点直接选择读取RCFile文件;
2.若读取具体Lucene文件出错时,此时,执行节点重新调用该Lucene文件对应的RCFile文件,重新进行检索。
本发明的全文读取引擎机制如图3所示。每个range在执行时,读取的数据可能在本地或者远程的Lucene文件或RCFile文件中,在读取的时候,若是有Lucene文件,则先读取Lucene文件,否则读取RCFile文件,这样可以保证检索时,数据结果总能正确给出。该机制也可以手动声明只读取Lucene或只读取RCFile文件。每个存储Lucene文件的节点,都会有一个守护进程对该节点的Lucene文件进行相应的维护,主要是维护Lucene文件与RCFile文件中所管理的数据文件的一致性。
如图3所示,执行节点首先会取一个range,该range包含RCFile文件信息及对应的Lucene文件信息。首先判断该range是否要走Lucene流程,若是则根据Lucene文件的相关信息,确定要访问的Lucene文件是在本地还是远程,若是在本地,则初始化JNI接口并通过JNI接口直接访问对应的Lucene文件。若是远程,则初始化http接口,通过tcp访问远程节点的Lucene守护进程,通过该守护进程访问对应的Lucene文件,然后通过socket接口返回数据。若不走Lucene文件的访问流程时,则会直接通过对应的集群文件系统,直接访问对应的RCFile文件。因为Lucene是无复本机制的,所以一个Lucene的单点故障会相对比较高,所以,当访问一个Lucene文件出错时,会再次查找Lucene文件对应的RCFile文件,重新获取对应的数据,保证检索的持续性。
同时,为了保障检索过程的正确性,若某一个节点在出错时,该节点的数据会丢弃,重新分配检索节点重新执行检索。
本发明的第三方面,是全文检索的排序及分组。当使用全文检索时,可以对检索字段的相关度进行排序,或者按相关度分组后排序。
相关度的排序是通过权重实现。在检索语句中,可以对检索字段赋于权重,然后,当查询下发到Lucene时,Lucene会根据权重计算得分,根据得分返回初次排序的结果。每个节点获取到的值是已经排序完成的结果集,当每个节点的结果汇集到协调器时,会再次根据相关度进行排序,最后返回用户的就是全局对相关度的排序结果。
基本的语法如下:
select expression1[,expression2...]FROM table_reference[others][fulltext(expression1^weight[,expression2^weight…])]
其中,expression1、expression2表示待检检字段,table_reference表示待检索文件,weight表示权重,fulltext表示全文检索。
在生成执行计划树时,会多使用一个字段以保存每一条检索结果的权重计算值,此时,该节点返回的数据已经是排序完成的数据,而当这些数据再次汇总到上一层节点时,会根据这些权重值对所有汇总数据再进行一次排序。然后,返回给用户的就是所有符合以相关度排序的数据结果集。在检索时,若是分组数据,首先在各个执行引擎内部,将数据进行分组并打分,按照相关度排序;然后再在多个执行引擎之间,将分组数据两两合并,即进行融和操作,并按照融合后的权重值进行相关度排序;合并操作是递归的进行,直至完成最上层的合并,最终输出给用户。
本发明对全文检索的结果数据根据相关度进行排序,整体流程如图4所示。在检索某个字段时,可以给该字段设置权值,当该权值设置成功后,在下层的读取引擎会把该权重加入字段中,进而结果按权值进行排序,同时可以使用order by对排序的顺序进行指定,默认是升序,相关度高的会排序在前,若是desc则相反。Lucene语法已经实现了该功能,但是在集群环境中,还要对每一个节点返回的数据再进行一次排序。通过在检索时,每个节点在返回每一行检索结果时,会新增加一个字段存储该行的打分结果,该结果汇总到协调节点时,会根据该值,再进行一次排序,最终得到已经排序完成的检索结果。因为该打分的算法,在每个节点一样的,这样每一个节点在处理完成后的汇总结果也能直接使用该计算结果进行相应的排序。
同时也可以实现对于检索字段的排序,该功能通过使用group by方式,对检索的字段进行排序。可以结合相关度的排序算法,实现对分组数据根据相关度进行排序。分组时,会根据相关度排序算法,把符合分组的数据的打分值按照一定的算法,进行融合计算,再按照融合后的值,对分组数据进行相关度的排序。
本发明的几乎没有损失检索系统原本应该的性能,对于性能有一定程度的提升。
首先,当全文检索或条件字段检索时,才会使用Lucene文件进行数据读取,其余流程不变;其次,当使用Lucene文件进行数据读取时,若是网络原因则会直接选择原始流程,若对应的Lucene文件损坏时,也会使用原始的流程继续读取对应的RCFile,而该过程产生的性能损失很小。
原本流程中,使用的是RCFile文件格式,该文件格式在查询随机数据时,性能比较低下,因为每次都要遍历整个文件,才能找到符合要求的数据,虽然在集群的环境下,每个节点的数据量相对较少,但是正因为如此,每一个节点的性能提升,对于整体集群环境的性能的提升就会产生巨大的影响。
而当使用Lucene文件进行检索时,首先会对已经存在的文件建立索引,把原本的一整块数据再次切割成有意义的碎片。而当再次检索时,则可以直接定位到需要的块,而不用遍历整个文件一次,所以可以极大地提升性能。
应该注意到并理解,在不脱离后附的权利要求所要求的本发明的精神和范围的情况下,能够对上述详细描述的本发明做出各种修改和改进。因此,要求保护的技术方案的范围不受所给出的任何特定示范教导的限制。
Claims (2)
1.一种针对海量数据全文检索场景的实现方法,在检索引擎对输入的SQL语句分析后形成执行计划树,将执行计划树切割成执行单元fragment,通过协调器分发到节点上执行并返回结果;其特征在于,将Lucene引入检索引擎,对集群中已经存在的数据文件建立Lucene索引文件,一个数据文件对应一个或多个Lucene索引文件,一个Lucene索引文件存储在一个节点上,在每个存储Lucene索引文件的节点上,设置有一个守护进程对该节点的Lucene索引文件进行维护,保持Lucene索引文件与RCFile文件所管理的数据文件的一致性;每个节点设置有一个Lucene的socket接口;所述的全文检索场景的实现方法包含如下方面:
第一方面,优化协调器对fragment的调度机制;
在一个fragment中,有一个结构体range,range中记载有Lucene索引文件地址列表;
在检索时,遍历所有fragment中的range,对每个range,执行下面过程:
获取该range对应的Lucene索引文件地址列表;对列表中的每个Lucene索引文件地址,执行过程(1)和(2);(1)判断该地址是否位于所执行的fragment的本地节点上,若是,则设置该索引文件所在节点的预加值A为1,若不是,设置该索引文件所在节点的预加值A为设定的固定最大值;(2)将该索引文件所在节点的当前计数B,加上预加值A,得到新的计数值C;其中,每个节点的计数值初始设置为0;在得到该range的每个Lucene索引文件所在节点的计数C后,选择其中计数C最小的节点,作为该range的执行节点,然后更新该节点的当前计数B为对应的计数值C,标记该range将最终在该节点上执行;
第二方面,优化全文读取引擎机制;
节点执行一个fragment时,若对应的Lucene索引文件在本地节点,直接通过JNI调用Lucene接口,获取检索结果集;若对应的Lucene索引文件在远程节点,调用socket接口通过远程tcp访问远程节点的Lucene接口,获取检索结果集;socket接口还用于RCFile与Lucene中元数据变化时的更新;JNI表示Java本地接口,tcp表示传输控制协议;
若调用访问Lucene接口时,对应节点上维护Lucene索引文件的守护进程已经挂掉,或远程tcp连接无法建立时,则执行节点直接选择读取RCFile文件;若读取Lucene索引文件出错时,执行节点重新调用该Lucene索引文件对应的RCFile文件,重新进行检索。
2.根据权利要求1所述的一种针对海量数据全文检索场景的实现方法,其特征在于,所述的针对海量数据全文检索场景的实现方法,还包括如下方面:
第三方面,实现全文检索的相关度排序;相关度的排序通过设置权重实现;
在检索某个字段时,给该字段设置权重,在Lucene检索时,将权重加入字段中,检索返回根据权值排序的结果数据,将各Lucene检索的结果数据汇总并根据权重再进行一次排序,最后将符合以相关度排序的数据结果集返回给用户;
在检索时,若是分组数据,对分组数据的权重值先进行融合计算,再按照融合后的权重值,对分组数据进行相关度的排序。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201610849788.2A CN106649462B (zh) | 2016-09-26 | 2016-09-26 | 一种针对海量数据全文检索场景的实现方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201610849788.2A CN106649462B (zh) | 2016-09-26 | 2016-09-26 | 一种针对海量数据全文检索场景的实现方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN106649462A true CN106649462A (zh) | 2017-05-10 |
CN106649462B CN106649462B (zh) | 2019-11-08 |
Family
ID=58853968
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201610849788.2A Active CN106649462B (zh) | 2016-09-26 | 2016-09-26 | 一种针对海量数据全文检索场景的实现方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN106649462B (zh) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN108763310A (zh) * | 2018-04-25 | 2018-11-06 | 江苏鸣鹤云科技有限公司 | 一种高可用的大数据平台 |
CN111966979A (zh) * | 2020-08-26 | 2020-11-20 | 西安石油大学 | 一种基于http协议的井下数据搜索引擎及交互系统 |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102426609A (zh) * | 2011-12-28 | 2012-04-25 | 厦门市美亚柏科信息股份有限公司 | 一种基于MapReduce编程架构的索引生成方法和装置 |
CN106484815A (zh) * | 2016-09-26 | 2017-03-08 | 北京赛思信安技术股份有限公司 | 一种基于海量数据类sql检索场景的自动识别优化方法 |
-
2016
- 2016-09-26 CN CN201610849788.2A patent/CN106649462B/zh active Active
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102426609A (zh) * | 2011-12-28 | 2012-04-25 | 厦门市美亚柏科信息股份有限公司 | 一种基于MapReduce编程架构的索引生成方法和装置 |
CN106484815A (zh) * | 2016-09-26 | 2017-03-08 | 北京赛思信安技术股份有限公司 | 一种基于海量数据类sql检索场景的自动识别优化方法 |
Non-Patent Citations (1)
Title |
---|
张锡川: ""基于Lucene的云平台学术搜索引擎"", 《中国优秀硕士学位论文全文数据库 信息科技辑》 * |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN108763310A (zh) * | 2018-04-25 | 2018-11-06 | 江苏鸣鹤云科技有限公司 | 一种高可用的大数据平台 |
CN111966979A (zh) * | 2020-08-26 | 2020-11-20 | 西安石油大学 | 一种基于http协议的井下数据搜索引擎及交互系统 |
CN111966979B (zh) * | 2020-08-26 | 2023-02-28 | 西安石油大学 | 一种基于http协议的井下数据搜索引擎及交互系统 |
Also Published As
Publication number | Publication date |
---|---|
CN106649462B (zh) | 2019-11-08 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN107402988B (zh) | 一种分布式NewSQL数据库系统和半结构化数据查询方法 | |
CN103020204B (zh) | 一种对分布式顺序表进行多维区间查询的方法及其系统 | |
Cambazoglu et al. | Scalability challenges in web search engines | |
CN110362727B (zh) | 用于搜索系统的第三方搜索应用 | |
US6801904B2 (en) | System for keyword based searching over relational databases | |
US10162855B2 (en) | Systems and methods for optimizing data analysis | |
US7158996B2 (en) | Method, system, and program for managing database operations with respect to a database table | |
CN100535894C (zh) | 数据库对象脚本生成方法和系统 | |
CN107122443A (zh) | 一种基于Spark SQL的分布式全文检索系统及方法 | |
US8977625B2 (en) | Inference indexing | |
CN108073710B (zh) | 基于动态网络图挖掘的Github开源代码库推荐系统 | |
CN101271474A (zh) | 利用索引来搜索结构化文档的系统和方法 | |
CN107943952A (zh) | 一种基于Spark框架进行全文检索的实现方法 | |
CN104239377A (zh) | 跨平台的数据检索方法及装置 | |
CN104391908B (zh) | 一种图上基于局部敏感哈希的多关键字索引方法 | |
JP2008059557A (ja) | データベースインデクシング、サーチング、及びデータ検索のシステム及び方法 | |
US20240078234A1 (en) | Apparatus, method and storage medium for database pagination | |
Pirzadeh et al. | Bigfun: A performance study of big data management system functionality | |
Stefanidis et al. | A context‐aware preference database system | |
Xu et al. | Enhancing HDFS with a full-text search system for massive small files | |
CN106649462A (zh) | 一种针对海量数据全文检索场景的实现方法 | |
CN110781430A (zh) | 互联网新型虚拟数据中心系统及其构造方法 | |
Nie et al. | Effectively mining and using coverage and overlap statistics for data integration | |
Bugiotti et al. | A logical approach to nosql databases | |
US8745035B1 (en) | Multistage pipeline for feeding joined tables to a search system |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |