CN108205561A - 数据查询系统、方法及装置 - Google Patents
数据查询系统、方法及装置 Download PDFInfo
- Publication number
- CN108205561A CN108205561A CN201611178766.4A CN201611178766A CN108205561A CN 108205561 A CN108205561 A CN 108205561A CN 201611178766 A CN201611178766 A CN 201611178766A CN 108205561 A CN108205561 A CN 108205561A
- Authority
- CN
- China
- Prior art keywords
- node
- data
- inquiry request
- result
- query
- 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.)
- Pending
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/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/24—Querying
- G06F16/245—Query processing
- G06F16/2458—Special types of queries, e.g. statistical queries, fuzzy queries or distributed queries
- G06F16/2471—Distributed queries
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/90—Details of database functions independent of the retrieved data types
- G06F16/95—Retrieval from the web
- G06F16/951—Indexing; Web crawling techniques
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- Databases & Information Systems (AREA)
- Data Mining & Analysis (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Fuzzy Systems (AREA)
- Mathematical Physics (AREA)
- Probability & Statistics with Applications (AREA)
- Software Systems (AREA)
- Computational Linguistics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本申请公开了一种数据查询系统、方法及装置,所述数据查询系统中部署多个节点,节点间组成无中心分布式对等结构,所述节点分为:前端节点和后端节点,使得前端节点在接收到查询请求之后,能够在各个所述节点中均衡调度目标节点,实现数据查询。本申请通过所采用的分布式集群结构,能够支持集群中的成员节点动态加入和退出,易于扩展,而本申请中集群中利用前端节点接收查询请求并调度目标节点完成查询任务,从而使得查询任务能够在易于扩展的集群范围内进行均衡调度。
Description
技术领域
本申请涉及数据处理技术领域,特别涉及一种数据查询系统、方法及装置。
背景技术
在互联网时代,用户足不出户即可通过网络进行购物、视频观看等行为。因此对于电商而言,在获取基本访问量的基础上,进行数据的准确分析,清楚了解用户行为习惯、发现热点网页,可以实现精准的广告投放和推荐营销。同样地,在视频媒体行业,准确了解当前在线用户数、用户分布、播放时长等,有助于策划观众更感兴趣的节目、提高用户观看体验、优化播放系统。
因此,如何对数据进行查询,对采集到的实时数据流进行在线快速的统计分析和挖掘其中有用的信息和规律,不论对于电商还是媒体等都意义重大。
现有技术中常用的数据查询方案,通过对数据本身建立倒排、树形等结构以支持数据的快速查询,其中实时数据存储在内存中以支持快速查询,超过一定时间后的实时数据会导入到历史存储中。
但上述数据查询方案中,由于结构的特性,新的查询节点在插入倒排或树形等结构时,需要对插入位置的父节点及其子节点,以及子节点的子节点等进行变动工作量较大,使得倒排、树形等数据结构难于扩展,导致上述数据查询方案难以对多个查询进行动态关联,无法支持较为复杂的查询颈。
发明内容
鉴于上述问题,提出了本申请以便提供一种克服上述问题或者至少部分地解决上述问题的数据查询系统、方法及装置。
本申请提供了一种数据查询系统,所述数据查询系统中部署多个节点,节点间组成无中心分布式对等结构,所述节点分为:前端节点和后端节点,使得前端节点在接收到查询请求之后,能够在各个所述节点中均衡调度目标节点,实现数据查询。
上述数据查询系统,优选的,每个所述节点均配置有缓存节点,每个所述缓存节点之间组成无中心分布式对等结构,使得所述目标节点能够均衡调度每个所述缓存节点存储查询结果。
本申请还提供了一种数据查询方法,包括:
利用数据查询系统中的至少一个前端节点接收查询请求,其中所述数据查询系统中部署多个节点,节点间组成无中心分布式对等结构,所述节点分为:前端节点和后端节点;
基于前端节点和后端节点各自的当前负载状态,确定处理所述查询请求的目标节点,所述目标节点包括前端节点和/或后端节点;
利用所述目标节点基于所述查询请求执行查询任务,得到与所述查询请求相匹配的查询结果。
上述方法,优选的,利用所述目标节点基于所述查询请求执行查询任务,得到与所述查询请求相匹配的查询结果,包括:
利用所述目标节点以预设的计算周期,基于所述查询请求进行周期性的数据计算处理,得到计算结果;
在所述计算结果中,获得与所述查询请求相匹配的查询结果;
其中,所述方法还包括:
监测利用所述目标节点进行周期性的数据计算处理的持续时长是否超过预设的生存周期时长,如果是,删除利用所述目标节点进行周期性的数据计算处理所得到的计算结果并停止利用所述目标节点进行周期性的数据计算处理。
上述方法,优选的,每个所述节点均配置有缓存节点,每个所述缓存节点之间组成无中心分布式对等结构;所述方法还包括:
基于各个缓存节点的当前缓存状态,确定目标缓存节点;
将所述计算结果及所述目标节点的节点信息作为结果数据存储到所述目标缓存节点中。
上述方法,优选的,在利用前端节点接收到查询请求之后,所述方法还包括:
在已经存储于所述目标缓存节点中的结果数据中查找是否存在与所述查询请求相对应的历史计算结果及历史节点信息;
如果存在,则根据所述历史节点信息将所述查询请求路由到所述历史节点信息对应的节点上,并通过所述历史节点信息对应的节点返回所述历史计算结果。
上述方法,优选的,还包括:
监测所述前端节点和所述后端节点是否出现故障;
如果所述前端节点和/或所述后端节点出现查询任务的执行故障,触发出现执行故障的所述前端节点和/或所述后端节点重新执行查询任务;
如果所述前端节点和/或所述后端节点出现节点的运行故障,在其他节点中重新确定新的节点,将所述新的节点代替出现运行故障的所述前端节点和/或所述后端节点。
本申请还提供了一种数据查询装置,包括:
请求接收单元,用于利用数据查询系统中的至少一个前端节点接收查询请求,其中所述数据查询系统中部署多个节点,节点间组成无中心分布式对等结构,所述节点分为:前端节点和后端节点;
目标确定单元,用于基于前端节点和后端节点各自的当前负载状态,确定处理所述查询请求的目标节点,所述目标节点包括前端节点和/或后端节点;
任务执行单元,用于利用所述目标节点基于所述查询请求执行查询任务,得到与所述查询请求相匹配的查询结果。
上述装置,优选的,所述任务执行单元具体用于:利用所述目标节点以预设的计算周期,基于所述查询请求进行周期性的数据计算处理,得到计算结果,在所述计算结果中,获得与所述差请求相匹配的查询结果;
其中,所述装置还包括:
生存周期监测单元,用于监测利用所述目标节点进行周期性的数据计算的持续时长是否超过预设的生存周期时长,如果是,删除利用所述目标节点进行周期性的数据计算处理所得到的计算结果并停止利用所述目标节点进行周期性的数据计算处理。
上述装置,优选的,每个所述节点均配置有缓存节点,每个所述缓存节点之间组成无中心分布式对等结构;所述装置还包括:
数据缓存单元,用于基于各个缓存节点的当前缓存状态,确定目标缓存节点,将所述计算结果及所述目标节点的节点信息作为结果数据存储到所述目标缓存节点中。
上述装置,优选的,还包括:
历史查找单元,用于在所述请求接收单元利用前端节点接收查询请求之后,在已经存储于所述目标缓存节点中的结果数据中查找是否存在与所述查询请求相对应的历史计算结果及历史节点信息,如果存在,则根据所述历史节点信息将所述查询请求路由到所述历史节点信息对应的节点上,并通过所述历史节点信息对应的节点返回所述历史计算结果。
上述装置,优选的,还包括:
故障监测单元,用于监测所述前端节点和所述后端节点是否出现故障,如果所述前端节点和/或所述后端节点出现查询任务的执行故障,则触发出现执行故障的所述前端节点和/或所述后端节点重新执行查询任务,如果所述前端节点和/或所述后端节点出现节点的运行故障,则在其他节点中重新确定新的节点,将所述新的节点代替出现运行故障的所述前端节点和/或所述后端节点。
由上述技术方案可知,本申请提供的一种数据查询系统、方法及装置,通过将数据查询系统中的各个节点采用对等结构,即无中心分布式集群系统结构,进而在集群中的前端节点及后端节点中均衡调度目标节点实现数据查询。由此,本申请所采用的分布式集群结构,能够支持集群中的成员节点动态加入和退出,易于扩展,而本申请中集群中利用前端节点接收查询请求并调度目标节点完成查询任务,从而使得查询任务能够在易于扩展的集群范围内进行均衡调度。
上述说明仅是本申请技术方案的概述,为了能够更清楚了解本申请的技术手段,而可依照说明书的内容予以实施,并且为了让本申请的上述和其它目的、特征和优点能够更明显易懂,以下特举本申请的具体实施方式。
附图说明
通过阅读下文优选实施方式的详细描述,各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的,而并不认为是对本申请的限制。而且在整个附图中,用相同的参考符号表示相同的部件。在附图中:
图1为本申请实施例提供的一种数据查询系统的结构示意图;
图2为本申请实施例的应用示例图;
图3为本申请实施例提供的一种数据查询系统的部分结构示意图;
图4为本申请实施例的另一应用示例图;
图5为本申请实施例提供的一种数据查询方法的流程图;
图6~图8分别为本申请实施例提供的一种数据查询方法的另一流程图;
图9~图12分别为本申请实施例的其他应用示例图;
图13~图16分别为本申请实施例提供的一种数据查询装置的结构示意图。
具体实施方式
下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例,然而应当理解,可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反,提供这些实施例是为了能够更透彻地理解本公开,并且能够将本公开的范围完整的传达给本领域的技术人员。
参考图1,为本申请实施例提供的一种数据查询系统的结构示意图,用以实现数据查询。数据查询系统与查询客户端及存储系统相连接。
其中,查询客户端根据用户的操作生成查询请求,应用中,查询客户端可以利用REST接口向数据查询系统发送,查询客户端可以为各种电脑或服务器等设备。而存储系统作为数据查询系统的查询库,可以为各种后端数据存储系统,如分布式数据库、各种类SQL存储系统,典型的包括Druid、Geode、Apache Drill等,存储系统中的数据具有有限的存活时间,超过后从存储系统中自动删除。由此,本实施例中适配不同的后端存储,不受查询数据类型限制,能够进行查询库的快速替换。
数据查询系统中部署有多个节点,节点可以能够执行计算功能,如设置有CPU等部件的电脑或服务器等设备实现,节点根据功能类型分为两种类型,如前端节点及后端节点,前端节点作为查询引擎,其上可以创建前端执行模块,即master actor,查询请求可以被任意前端节点的master actor接收,例如查询请求同时出现多个时,多个前端节点上的master actor分别接收查询请求,实现查询请求的均衡负载,提供查询的HA(HighAvailable,高可用性)保证。后端节点作为统计分析模块,主要用于在前端节点接收到查询请求之后被调度并完成数据查询任务,而前端节点本身也可以被调度用来完成数据查询任务。
需要说明的是,在数据查询系统中,节点之间组成无中心分布式对等结构,如图1中所示,前端节点与前端节点之间为对等结构,没有父子或等级区别,后端节点与后端节点之间,以及前端节点与后端节点之间,同样均为对等结构,没有父子或等级区别,由此,在新的节点被添加到数据查询系统时,只需要将新的节点与数据查询系统中的某个节点或某几个节点之间建立对等关系,即可加入到分布式的节点集群中,由此,本申请中数据查询系统的集群结构易于扩展,进而前端节点在接收到查询请求之后能够在扩展后的整个集群的所有节点中均衡调度目标节点,由目标节点基于查询请求执行查询任务。
其中,前端节点在调度目标节点时,是通过基于数据查询系统中所有节点的当前负载状态来均衡调度目标节点,这里的目标节点中可以为接收到查询请求的前端节点本身,也可以为其他前端节点,也可以为后端节点,或者前三者的自由组合,被确定的目标节点上通过被创建执行模块即统计分析actor来基于数据查询请求执行查询任务,得到查询结果。
需要说明的是,数据查询系统中的后端节点不直接接收来自查询客户端的查询请求,只接收前端节点的master actor调度过来的查询请求,再通过创建的统计分析actor来执行查询任务。
如图2中所示,前端节点A接收到查询请求之后,在数据查询系统的所有节点中,找到当前负载最低的四个节点作为目标节点,如前端节点A、前端节点B、后端节点C和后端节点D,由这4个节点基于数据查询请求执行查询任务,得到查询结果。
为了实现查询结果的持久化存储,减少大数据情况下内存资源的消耗,避免内存瓶颈的问题,本实施例的数据查询系统中每个节点均配置有缓存节点,由于数据查询系统中的节点的分布式对等结构,每个缓存节点之间组成无中心分布式对等结构,使得目标节点能够均衡调度每个缓存节点来存储查询结果。
如图3中所示,数据查询系统中的每个节点均对应一个缓存节点,而缓存节点之间也同样形成无中心的分布式对等结构,目标节点在得到查询结果之后,在将查询结果进行存储时,可以根据每个缓存节点中的缓存进度或状态,均衡调度目标缓存节点,将查询结果缓存到目标缓存节点中。
其中,目标节点在缓存查询结果时,可以对查询结果进行备份缓存。
如图4中所示,节点之间组成对等结构,根据查询客户端中的查询请求实现缓存或非缓存查询,部署多个前端节点的master actor实现查询请求的负载均衡,后端节点与前端节点之间对等结构实现在线的线性扩容、动态负载均衡及容错等功能。也就是说,数据查询系统在部署节点时,可以根据业务需求也就是查询请求中的查询属性如业务量等来合理部署相应规模的前端节点和后端节点的数量。
参考图5,为本申请实施例提供的一种数据查询方法的流程图,适用于图1所示的本实施例提供的数据查询系统中,数据查询系统与查询客户端及存储系统相连接。
以下结合图1,对数据查询系统对查询请求进行响应,进行节点部署并完成查询任务的过程进行说明,如图5中步骤所示:
步骤501:利用数据查询系统中的至少一个前端节点接收查询请求,其中数据查询系统中部署多个节点,节点间组成无中心分布式对等结构,节点分为:前端节点和后端节点;。
其中,前端节点即为根据查询请求的查询属性均衡部署的前端节点,前端节点通过其自身的前端执行模块即master actor来接收查询请求。
例如,用户所在的客户端生成查询请求之后,向数据查询系统发送这一请求,所述数据查询系统在监测到查询请求的到来时,根据查询请求的查询属性如查询业务量通知合适的前端节点的master actor来接收查询请求,如一个前端节点或三个前端节点上的master actor来接收查询请求。
步骤502:基于前端节点和后端节点各自的当前负载状态,确定处理查询请求的目标节点。
本实施例中,需要对数据查询系统中所有的前端节点和所有的前端节点的当前负载状态进行实时监测,在需要调度目标节点时,根据所有节点的当前负载状态选择没有处理压力的节点作为目标节点。
其中,确定的目标节点中可以包括有至少一个后端节点,也可以包括有至少一个前端节点,或者既包括有后端节点也包括有前端节点,目标节点中的前端节点可以为接收到查询请求的前端节点本身。
在确定目标节点之后,可以在目标节点上创建统计分析actor,这个统计分析actor可以由接收到查询请求的前端节点中的master actor远程创建。
例如,master actor在确定目标节点时,可以根据查询请求的查询属性如查询业务量等在数据查询系统的节点集群中均衡调度,找到合适的节点作为目标节点。例如,找到任务负载值较低的节点后,在负载值较低的这些节点中,选择9个节点作为目标节点,之后,在这些目标节点上创建统计分析actor。
步骤503:利用目标节点基于查询请求执行查询任务,得到与查询请求相匹配的查询结果。
其中,在master actor确定目标节点并在目标节点上创建统计分析actor,且将查询请求发送到统计分析actor之后,统计分析actor开始基于查询请求在数据存储系统中执行查询任务,得到查询结果。
这里的查询任务可以为具有生存周期时长的周期性的查询工作,例如,持续1个小时的200次/秒的周期查询。
其中,这里的存储系统可以为各种后端数据存储系统,如分布式数据库、各种类SQL存储系统,典型的包括Druid、Geode、Apache Drill等,存储系统中的数据具有有限的存活时间,超过后从存储系统中自动删除。
需要说明的是,如图1中所示,数据查询系统中的master actor构成了查询引擎,统计分析actor形成统计分析模块,共同完成查询任务。
由上述技术方案,本申请实施例提供的一种数据查询方法,基于节点采用对等结构的数据查询系统,即无中心分布式集群系统结构,在集群中的前端节点及后端节点中均衡调度目标节点实现数据查询。本实施例所采用的分布式集群结构,能够支持集群中的成员节点动态加入和退出,易于扩展,而本申请集群中利用前端节点接收查询请求并调度目标节点完成查询任务,从而使得查询任务能够在易于扩展的集群范围内进行均衡调度。
在具体实现中,在利用目标节点基于查询请求执行查询任务,得到查询结果时,具体的实现过程为:
首先利用目标节点以预设的计算周期,基于查询请求进行周期性的数据计算处理,得到计算结果,这里的计算处理可以为在数据存储系统中,基于查询请求所进行的各种诸如合并、去冗余、搜索提取等计算操作。
其次,在所得到的计算结果中,获得与查询请求相匹配的查询结果。
需要说明的是,计算结果中可能包含计算过程所产生的数据及最终的计算数据,因此,目标节点可以直接将进行计算处理所得到的计算结果全部获取作为查询结果,也可以只提取计算结果中的最终计算数据作为查询结果。
在本实施例中,为了保证查询请求的时效性,对每个查询请求及其查询任务均设置有生存周期,在查询请求的被处理持续时长超过生成周期时长时,需要进行停止查询及删除查询结果的处理。如图6中所示,在目标节点开始执行查询任务之后,本实施例还可以包括以下步骤:
步骤504:监测利用目标节点进行周期性的数据计算处理的持续时长是否超过预设的生存周期时长,如果是,执行步骤505及步骤506。
其中,这里的生存周期时长可以根据需求进行设置,如1小时或30分钟,表明查询请求及其他查询任务的有效时长,在这个生存周期内,目标节点执行查询任务,如周期性的进行查询计算,得到查询结果。从目标节点开始进行计算处理,本实施例对持续时长进行监测,如果目标节点进行周期性的数据计算处理的持续时长超过这个生存周期时长,则表明当前的查询请求及查询任务已经到期,此时执行步骤505及步骤506。
步骤505:删除利用目标节点进行周期性的数据计算处理所得到的计算结果。
步骤506:停止利用目标节点进行周期性的数据计算处理。
例如,本实施例中的查询请求被配置有有效期,即生存周期,如1个小时或30分钟等,在这个生存周期内,目标节点中的统计分析actor周期性的执行查询任务,得到查询结果,如果从查询请求被接收之后统计分析actor开始执行查询任务开始的时间长超出这个生存周期,此时,就会监测到查询请求的存在时间长超过它预设的生存周期时间长,此时统计分析actor生成查询超过生存周期的通知消息,并将这个通知消息发送给master actor,而master actor在接收到这个通知消息之后,基于通知消息将与查询请求相对应的查询结果进行删除并关闭这个统计分析actor。
上述实施例中,所得到的查询结果可以进行释放或删除,不进行内存缓存,避免内存或磁盘空间的占用,降低内存资源的占用率。或者,本实施例中可以将查询结果进行持久化缓存,提供持久化,减少大数据情况下内存资源的消耗,避免内存瓶颈的情况。由此,本实施例中,在每个所述节点均配置有缓存节点,每个所述缓存节点之间组成无中心分布式对等结构;,这里的缓存节点可以为数据查询系统中节点的设备的内存和/或磁盘等空间区域形成的缓存节点,缓存节点之间组成数据缓存系统,如图3所示,数据缓存系统中的节点缓存区域基于节点的拓扑结构形成分布式缓存结构,且数据缓存系统配置有缓存系统的操作系统,能够对系统中各个节点的缓存区域进行同一均衡的调度控制。
如图7中所示,在所述步骤503之后,还可以有以下步骤:
步骤507:基于各个缓存节点的当前缓存状态,确定目标缓存节点。
其中,目标缓存节点的确定可以由前端节点中的master actor来实现,masteractor在确定目标缓存节点之后,在目标缓存节点中创建或规划出缓存区域。
步骤508:将计算结果及目标节点的节点信息作为结果数据存储到目标缓存节点中。
例如,前端节点的master actor将查询请求发送到目标节点的统计分析actor,由统计分析actor执行查询任务之后,统计分析actor将查询任务执行过程中所得到的计算结果存储到预先已经创建好的目标缓存节点的缓存区域中,用以后续获得计算结果中的查询结果返回给用户,完成查询任务。
而这里的目标节点的节点信息包括有目标节点的节点标识、地址信息等。
需要说明的是,master actor在确定目标缓存节点并创建缓存区域之后,也会将与查询请求相关的请求参数缓存到相应的节点的目标缓存节点中。查询请求的请求参数可以为请求时间、任务类型(SQL或其他类SQL命令)、生存周期、周期性执行间隔、容量(保存多少次最近执行的查询结果)、系统解析相关参数等参数。
也就是说,本实施例中,数据查询系统内嵌分布式缓存支持,数据缓存系统为分布式缓存结构,提供持久化功能、强一致性保证,用于存储数据查询系统所用到的元数据,也缓存周期性的查询结果,供客户端使用,减少查询对后端存储的压力。
需要说明的是,master actor即前端执行模块是否确定目标缓存节点并创建缓存区域,以及,统计分析actor即任务执行模块是否将得到的查询结果存储到目标缓存节点中,取决于查询请求的类型,如果查询请求的类型为缓存类查询的类型,则前端执行模块需要创建目标缓存,而任务执行模块在得到查询结果之后,需要将查询结果存储到目标缓存节点中,如果查询请求的类型是非缓存类查询的类型,则不需要执行这些操作。
基于此,前端执行模块在数据查询系统的节点中确定目标节点之前,可以首先判断查询请求的类型是否为预设的缓存类查询的类型还是非缓存类查询的类型,如果查询请求的类型属于缓存类查询的类型,则表明数据缓存系统中可能会有与查询请求相同的历史查询请求曾经存储的查询结果的历史结果数据,此时,前端执行模块可以首先在数据缓存系统中查询是否存在与查询请求相对应的结果数据,如果存在,则可以直接将找到的结果数据进行返回,如果不存在或者查询请求的类型为非缓存查询的类型,则需要继续进行目标节点的确定及任务执行模块的创建以及后续操作,如图8中所示,在步骤501之后,本实施例还可以包括以下步骤:
步骤509:在已经存储于目标缓存节点中的结果数据中查找是否存在与查询请求相对应的历史计算结果及历史节点信息,如果存在,则执行步骤510,如果不存在,执行步骤502;
步骤510:根据历史节点信息将查询请求路由到历史节点信息对应的节点上,并通过历史节点信息对应的节点返回历史计算结果。
需要说明的是,在将查询请求路由到历史节点信息对应的节点上之后,由路由到的节点继续执行查询任务,可以选择重新对节点执行查询任务的持续时长进行计时,以保证查询请求及查询任务的时效性。
也就是说,本实施例中,数据查询系统提供对查询请求的动态管控,支持对查询生存周期的管理。数据查询系统对相同的查询请求的多次提交和执行,都会路由到同一个节点,并从数据缓存系统中获取到该节点预计算即查询写入的查询结果。
例如,前端节点A的master actor接收到查询请求B之后,首先判断这个查询请求B是缓存类的查询类型还是非缓存类的查询类型,如果是非缓存类的查询类型,那么肯定没有历史数据与查询请求B对应,则需要master actor调度目标节点C并远程创建C上的统计分析actor,由统计分析actor执行查询任务得到查询结果,并由A上的master actor将查询结果返回;而如果是缓存类的查询类型,则需要A的master actor查找是否有与查询请求B相对应的历史计算结果数据及历史节点信息,如果查找到有与查询请求B相对应的历史计算结果,那么再判断历史计算结果及历史节点信息最初对应的历史查询请求D是否已经不在它的生存周期内,如果在生存周期内,那么D的历史计算结果及历史节点信息则是有效的,可以根据历史节点信息将新的这个查询请求B路由到D对应的节点的统计分析actor上,将历史计算结果进行返回;如果D不在生存周期内,那么D的历史计算结果及历史节点信息是无效的,或者,也可能已经无法找到历史计算结果了,那么此时仍然需要A的masteractor调度目标节点C并远程创建C上的统计分析actor,由统计分析actor执行查询任务得到查询结果,由A上的master actor将查询结果返回。
在一种实现中,本实施例中会实时监测各个节点是否出现故障,需要说明的是,本实施例是对所有的前端节点和所有的后端节点均会进行故障检测,如是否出现查询任务的执行故障以及是否出现节点的运行故障等,即actor执行查询任务的故障及节点的运行故障,在出现前端节点及后端节点中的任一节点或任意节点组合出现以上故障时,如只有前端节点出现故障、只有后端节点出现故障或者前端节点及后端节点均出现故障,可以采用以下方式进行响应:
在监测到前端节点和/或后端节点出现查询任务的执行故障时,如前端节点的master actor监测到目标节点的统计分析actor发生故障,或前端节点的master actor自身发生故障时,通常直接触发出现执行故障的前端节点和/或后端节点重新执行查询任务,即重新创建actor来执行任务。或者,也可以由出现故障的actor的节点的父节点上的actor首先判断出现故障的actor所执行的查询任务对应的查询请求是否在生存周期内,如果是,在出现故障的actor所在的节点上重新创建新的actor,否则,认为actor挂掉属于正常现象;例如,前端执行模块master actor监测到任务执行模块即统计分析actor发生故障,master actor在故障统计分析actor所在节点上重新创建统计分析actor,或者前端执行模块master actor所在前端节点重新被创建master actor。
而在监测到前端节点和/或后端节点出现节点的运行故障时,如节点宕机时,master actor在数据查询系统中重新确定新的节点,并将新的节点代替出现故障的节点。
例如,首先master actor在新的节点上创建与出现节点运行故障的节点相对应的新的任务执行模块。而出现故障的节点上可能存在多个任务执行模块,那么在确定新的节点时,节点数量可能与之前出现故障的节点数量不同,每个新的节点上所创建的任务执行模块的数量或组合也可能与出现故障的节点上的统计分析actor的数量或组合不同,具体创建的方式可以根据所确定的新的节点的负载情况而定。也就是说,数据查询系统在监测到节点故障信息,部署节点之外的其他节点中的一个节点或多个节点代替故障节点,并对故障节点对应的历史数据进行清理。
例如,当发生Actor挂掉这种情况时,Actor的父节点如前端节点等会收到Terminated信息,根据Actor是否到生成周期进行下一步的处理,如果Actor对应的查询请求超过了生存周期,则是正常的情况,否则就重新调度相应的查询任务,重建挂掉的Actor,如图9中所示;
当节点发生宕机时,其他节点会收到该节点的宕机时间信息,它们会竞争分布式锁,即代替发生宕机的节点,由获得锁的节点对宕机节点的stale数据进行清理(stale数据从分布式缓存中利用宕机节点的地址获得)。别的未获得锁的节点则等待锁的获得(在单线线程中),之后,他们获得锁时会检查宕机节点的stale数据是否已经清理完毕,这样放置之前获得锁的那个节点又宕机时,两个宕机节点累计的stale数据不会再有节点清理的问题,如图10中所示。
基于此,本实施例中不存在单点故障,宕机情况支持查询任务的自动迁移。
下面对数据查询系统在具体实现中的软件结构进行说明:
其中,数据查询系统从上到下分为:接口层、查询层、访问层、分布式存储系统层,其软件层次结果如图11中所示:
接口层提供HTTP RESTful风格的接口,包括:注册查询、持续查询、非持续查询、状态查询、性能展示;持续查询即缓存持续查询,非持续查询则包括缓存类非持续查询和缓存类非持续查询。
查询层由查询引擎构成,提供缓存和非缓存两类查询。
访问层以DAO(Data Access Object,数据访问对象)适配的方式提供对多种存储系统的访问和查询支持。
分布式存储层:提供持久数据存储,目前支持分布式数据和多种类SQL存储系统。
性能监控提供对整个系统性能的实时状态查询和错误通知。
在数据查询系统中,对于缓存类的查询请求,对每个查询请求均缓存相应的查询结果,只有在查询结果对应的查询请求超出生存周期后才会删除查询结果,或者,在查询系统中只缓存最近一次的查询请求对应的查询结果。这里的查询请求是指不同的查询请求。而对于非缓存类的查询请求,则不缓存查询结果。
也就是说,本实施例中的数据查询系统支持三类SQL查询,分别为:缓存类持续查询、缓存类非持续查询及非缓存类查询。
其中,缓存类持续查询针对每一个SLQ查询请求,都会在数据缓存系统中构建相应的缓存,预计算SQL查询结果,以Append追加的方式将查询结果添加到构建的缓存中,并且,支持过去一段时间内多次预计算结果的查询。这里的时间可以根据需求进行设置。
缓存类非持续查询同样是针对每一个SQL查询请求构建缓存,预计算SQL查询结果,但缓存中只存储最近一次的预计算结构。
非缓存类查询不构建缓存,每次提交的查询请求均为即时查询,类似传统的SQL执行方式,只不过非缓存查询时在整个集群范围内随机调度执行而不是总提交到一个节点上。
用户通过查询客户端提交查询请求时,对各种查询参数如生存周期(生存期)、周期性执行间隔、容量、查询的任务类型、系统解析相关参数等进行指定或设置,进而数据查询系统能够基于这些参数实现查询任务的全生存周期的管理,提供持久化机制保存查询结果,最大化数据的可用性。
上述方案中,每个前端节点有一个master Actor,在接收到查询请求之后,它会根据系统当前节点状态随机或根据需求选取一个节点,将任务调度到选择的那个节点上以Actor方式运行,对相同查询请求的多次提交和执行,都会路由到同一个Actor上,并从缓存中获取该Actor预计算写入的结果数据。如图12中所示,Master节点由RestInterface、QueryEngine、Actor Manager(nonCacheQueryRouter和CacheQueryEntranceActor)三层Actor构成,它们形成树状的Actor层次关系。
RestInterface负责接收HTTP查询请求、构造查询参数、接收查询响应、将查询结果转为HTTP响应返回给用户、处理超时异常等;
QueryEngine接收来自RestInterface转发的查询请求,根据请求类型的不同,将非缓存类查询转发给nonCacheQueryRouter,将缓存类查询转发给CacheQueryEntranceActor。
nonCacheQueryRouter对非缓存类查询Actor的生存周期进行管理,负责在集群范围内创建Actor、监控它们的健康状态、监控集群成员事件,将接收到的非缓存查询根据负载均衡的策略路由到某个Actor上进行执行。
每个缓存类查询Actor以SQL作为ID进行标识,司职负责对应SQL的预查询和周期更新查询结果。CacheQueryEntranceActor对缓存类查询Actor的生存周期进行管理,监控当前集群成员状态,对接收到的缓存查询请求,首先以随机的方式选取某个集群节点创建Actor,然后将缓存类查询转发到刚创建的Actor上执行。如果系统已经创建过对应的Actor,直接转发查询请求。CacheQueryEntranceActor在分布式缓存中维护SQL和Actor的对应关系,能以O(1)的时间复杂度快速找到某个SQL对应的Actor。
统计分析Actor(NonCacheWorkerActor和CacheWorkerActor)具体完成用户的查询统计工作。带缓存Actor用于需要多次调用的同一SQL查询,通过创建缓存,周期性预计算查询分析结果存入缓存,在用户下次查询时直接返回缓存数据,加快系统响应时间,减少前端查询延迟,实现对流数据的实时处理。
参考图13,为本申请实施例提供的一种数据查询装置的结构示意图,应用于图1所示的本实施例提供的数据查询系统中,所述数据查询装置可以设置在前端节点中,所述装置可以包括以下结构:
请求接收单元1301,用于利用数据查询系统中的至少一个前端节点接收查询请求,其中数据查询系统中部署多个节点,节点间组成无中心分布式对等结构,节点分为:前端节点和后端节点;
目标确定单元1302,用于基于前端节点和后端节点各自的当前负载状态,确定处理所述查询请求的目标节点,所述目标节点包括前端节点和/或后端节点;
任务执行单元1303,用于利用所述目标节点基于所述查询请求执行查询任务,得到与所述查询请求相匹配的查询结果。
由上述技术方案可知,本申请实施例提供的一种数据查询装置,通过将数据查询系统中的各个节点采用对等结构,即无中心分布式集群系统结构,进而在集群中的前端节点及后端节点中均衡调度目标节点实现数据查询。由此,本申请所采用的分布式集群结构,能够支持集群中的成员节点动态加入和退出,易于扩展,而本申请中集群中利用前端节点接收查询请求并调度目标节点完成查询任务,从而使得查询任务能够在易于扩展的集群范围内进行均衡调度。
在一种实现中,任务执行单元1303具体用于:利用所述目标节点以预设的计算周期,基于所述查询请求进行周期性的数据计算处理,得到计算结果,在所述计算结果中,获得与所述差请求相匹配的查询结果;
相应的,参考图14,所述装置还可以包括以下结构:
生存周期监测单元1304,用于监测利用所述目标节点进行周期性的数据计算的持续时长是否超过预设的生存周期时长,如果是,删除利用所述目标节点进行周期性的数据计算处理所得到的计算结果并停止利用所述目标节点进行周期性的数据计算处理。
参考图15,为本申请实施例提供的一种数据查询装置的结构示意图,基于前述实例,每个节点均配置有缓存节点,每个缓存节点之间组成无中心分布式对等结构;该装置还可以包括以下结构:
数据缓存单元1305,用于基于各个缓存节点的当前缓存状态,确定目标缓存节点,将所述计算结果及所述目标节点的节点信息作为结果数据存储到所述目标缓存节点中。
历史查找单元1306,用于在所述请求接收单元1301利用前端节点接收查询请求之后,在已经存储于所述目标缓存节点中的结果数据中查找是否存在与所述查询请求相对应的历史计算结果及历史节点信息,如果存在,则根据所述历史节点信息将所述查询请求路由到所述历史节点信息对应的节点上,并通过历史节点信息对应的节点返回所述历史计算结果,如果不存在,触发目标确定单元1302基于前端节点和后端节点各自的当前负载状态,确定处理所述查询请求的目标节点,并由任务执行单元1303利用所述目标节点基于所述查询请求执行查询任务,得到与所述查询请求相匹配的查询结果。
参考图16,为本申请实施例提供的一种数据查询装置的结构示意图,基于前述实例,该装置还可以包括以下结构:
故障监测单元1307,用于监测所述前端节点和所述后端节点是否出现故障,如果所述前端节点和/或所述后端节点出现查询任务的执行故障,则触发出现执行故障的所述前端节点和/或所述后端节点重新执行查询任务,如果所述前端节点和/或所述后端节点出现节点的运行故障,则在所述数据查询系统中的其他节点中重新确定新的节点,将所述新的节点代替出现运行故障的所述前端节点和/或所述后端节点。
以上结构的实现可以参考前文中方法实施例的相应技术实现的描述,此处不再详述。
需要说明的是,数据查询系统中的各个节点中具有处理器、存储器及磁盘,处理器执行查询任务等计算工作。
处理器中包含内核,由内核去存储器中调取相应的程序单元。内核可以设置一个或以上,通过调整内核参数来实现节点功能,如接收查询请求、转发查询请求、执行查询任务等。
存储器可能包括计算机可读介质中的非永久性存储器,随机存取存储器(RAM)和/或非易失性内存等形式,如只读存储器(ROM)或闪存(flash RAM),存储器包括至少一个存储芯片。
本申请还提供了一种计算机程序产品,设置在数据查询系统的节点上,当在节点如电脑或服务器上执行时,适于执行初始化有如下方法步骤的程序代码:
利用前端节点接收查询请求;基于前端节点和后端节点各自的当前负载状态,确定处理所述查询请求的目标节点,所述目标节点包括前端节点和/或后端节点;利用所述目标节点基于所述查询请求执行查询任务,得到与所述查询请求相匹配的查询结果。
由此,本实施例中通过将数据查询系统中的各个节点采用对等结构,即无中心分布式集群系统结构,进而在集群中部署的前端节点及后端节点上均衡调度目标节点对查询请求进行响应,完成查询任务并得到查询结果,其中,本申请中所采用的分布式集群结构,能够支持集群中的成员节点动态加入和退出,易于扩展,而本申请中集群中利用前端节点接收查询请求并利用目标节点完成查询任务,从而使得查询任务能够在易于扩展的集群范围内进行均衡调度。
本领域内的技术人员应明白,本申请的实施例可提供为方法、系统、或计算机程序产品。因此,本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
在一个典型的配置中,计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
存储器可能包括计算机可读介质中的非永久性存储器,随机存取存储器(RAM)和/或非易失性内存等形式,如只读存储器(ROM)或闪存(flash RAM)。存储器是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带,磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括暂存电脑可读媒体(transitory media),如调制的数据信号和载波。
以上仅为本申请的实施例而已,并不用于限制本申请。对于本领域技术人员来说,本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等,均应包含在本申请的权利要求范围之内。
Claims (10)
1.一种数据查询系统,其特征在于,所述数据查询系统中部署多个节点,节点间组成无中心分布式对等结构,所述节点分为:前端节点和后端节点,使得前端节点在接收到查询请求之后,能够在各个所述节点中均衡调度目标节点,实现数据查询。
2.根据权利要求1所述的数据查询系统,其特征在于,每个所述节点均配置有缓存节点,每个所述缓存节点之间组成无中心分布式对等结构,使得所述目标节点能够均衡调度每个所述缓存节点存储查询结果。
3.一种数据查询方法,其特征在于,包括:
利用数据查询系统中的至少一个前端节点接收查询请求,其中所述数据查询系统中部署多个节点,节点间组成无中心分布式对等结构,所述节点分为:前端节点和后端节点;
基于所述前端节点和所述后端节点各自的当前负载状态,确定处理所述查询请求的目标节点,所述目标节点包括所述前端节点和/或所述后端节点;
利用所述目标节点基于所述查询请求执行查询任务,得到与所述查询请求相匹配的查询结果。
4.根据权利要求3所述的方法,其特征在于,利用所述目标节点基于所述查询请求执行查询任务,得到与所述查询请求相匹配的查询结果,包括:
利用所述目标节点以预设的计算周期,基于所述查询请求进行周期性的数据计算处理,得到计算结果;
在所述计算结果中,获得与所述查询请求相匹配的查询结果;
其中,所述方法还包括:
监测利用所述目标节点进行周期性的数据计算处理的持续时长是否超过预设的生存周期时长,如果是,删除利用所述目标节点进行周期性的数据计算处理所得到的计算结果并停止利用所述目标节点进行周期性的数据计算处理。
5.根据权利要求4所述的方法,其特征在于,每个所述节点均配置有缓存节点,每个所述缓存节点之间组成无中心分布式对等结构;
所述方法还包括:
基于各个缓存节点的当前缓存状态,确定目标缓存节点;
将所述计算结果及所述目标节点的节点信息作为结果数据存储到所述目标缓存节点中。
6.根据权利要求5所述的方法,其特征在于,在利用前端节点接收到查询请求之后,所述方法还包括:
在已经存储于所述目标缓存节点中的结果数据中查找是否存在与所述查询请求相对应的历史计算结果及历史节点信息;
如果存在,则根据所述历史节点信息将所述查询请求路由到所述历史节点信息对应的节点上,并通过所述历史节点信息对应的节点返回所述历史计算结果。
7.根据权利要求3所述的方法,其特征在于,还包括:
监测所述前端节点和所述后端节点是否出现故障;
如果所述前端节点和/或所述后端节点出现查询任务的执行故障,触发出现执行故障的所述前端节点和/或所述后端节点重新执行查询任务;
如果所述前端节点和/或所述后端节点出现节点的运行故障,在其他节点中重新确定新的节点,将所述新的节点代替出现运行故障的所述前端节点和/或所述后端节点。
8.一种数据查询装置,其特征在于,包括:
请求接收单元,用于利用数据查询系统中的至少一个前端节点接收查询请求,其中所述数据查询系统中部署多个节点,节点间组成无中心分布式对等结构,所述节点分为:前端节点和后端节点;
目标确定单元,用于基于所述前端节点和所述后端节点各自的当前负载状态,确定处理所述查询请求的目标节点,所述目标节点包括所述前端节点和/或所述后端节点;
任务执行单元,用于利用所述目标节点基于所述查询请求执行查询任务,得到与所述查询请求相匹配的查询结果。
9.根据权利要求8所述的装置,其特征在于,所述任务执行单元具体用于:利用所述目标节点以预设的计算周期,基于所述查询请求进行周期性的数据计算处理,得到计算结果,在所述计算结果中,获得与所述差请求相匹配的查询结果;
其中,所述装置还包括:
生存周期监测单元,用于监测利用所述目标节点进行周期性的数据计算的持续时长是否超过预设的生存周期时长,如果是,删除利用所述目标节点进行周期性的数据计算处理所得到的计算结果并停止利用所述目标节点进行周期性的数据计算处理。
10.根据权利要求9所述的装置,其特征在于,每个所述节点均配置有缓存节点,每个所述缓存节点之间组成无中心分布式对等结构;所述装置还包括:
数据缓存单元,用于基于各个缓存节点的当前缓存状态,确定目标缓存节点,将所述计算结果及所述目标节点的节点信息作为结果数据存储到所述目标缓存节点中。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201611178766.4A CN108205561A (zh) | 2016-12-19 | 2016-12-19 | 数据查询系统、方法及装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201611178766.4A CN108205561A (zh) | 2016-12-19 | 2016-12-19 | 数据查询系统、方法及装置 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN108205561A true CN108205561A (zh) | 2018-06-26 |
Family
ID=62602067
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201611178766.4A Pending CN108205561A (zh) | 2016-12-19 | 2016-12-19 | 数据查询系统、方法及装置 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN108205561A (zh) |
Cited By (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN109783551A (zh) * | 2019-01-08 | 2019-05-21 | 上海上湖信息技术有限公司 | 数据展示方法及系统、可读存储介质 |
CN109922127A (zh) * | 2019-01-08 | 2019-06-21 | 博拉网络股份有限公司 | 一种云计算服务方法、装置和存储介质 |
CN110008257A (zh) * | 2019-04-10 | 2019-07-12 | 深圳市腾讯计算机系统有限公司 | 数据处理方法、装置、系统、计算机设备和存储介质 |
CN110471947A (zh) * | 2019-07-09 | 2019-11-19 | 广州视源电子科技股份有限公司 | 基于分布式搜索引擎的查询方法、服务器和存储介质 |
CN111046065A (zh) * | 2019-10-28 | 2020-04-21 | 北京大学 | 可扩展的高性能分布式查询处理方法及装置 |
CN111382183A (zh) * | 2018-12-29 | 2020-07-07 | 阿里巴巴集团控股有限公司 | 一种数据查询方法及装置 |
CN111400555A (zh) * | 2020-03-05 | 2020-07-10 | 湖南大学 | 图数据查询任务处理方法、装置、计算机设备和存储介质 |
CN112256437A (zh) * | 2020-11-10 | 2021-01-22 | 网易(杭州)网络有限公司 | 一种任务分发方法及装置 |
CN113032430A (zh) * | 2021-03-25 | 2021-06-25 | 网易(杭州)网络有限公司 | 一种数据处理方法、装置、介质和计算设备 |
CN113420052A (zh) * | 2021-07-08 | 2021-09-21 | 上海浦东发展银行股份有限公司 | 一种多级分布式缓存系统及方法 |
CN114911830A (zh) * | 2022-05-12 | 2022-08-16 | 平安科技(深圳)有限公司 | 基于时序数据库的索引缓存方法、装置、设备及存储介质 |
WO2024124641A1 (zh) * | 2022-12-13 | 2024-06-20 | 奇安信科技集团股份有限公司 | 一种集群负载均衡的方法和装置、电子设备和存储介质 |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101950300A (zh) * | 2010-09-20 | 2011-01-19 | 华南理工大学 | 一种分层结构、分布式搜索引擎系统及其实现方法 |
CN101969468A (zh) * | 2010-10-14 | 2011-02-09 | 广州从兴电子开发有限公司 | 查询服务器集群系统及查询方法 |
CN102891872A (zh) * | 2011-07-20 | 2013-01-23 | 中兴通讯股份有限公司 | 一种对等网络中数据存储和查询的方法及系统 |
CN103747060A (zh) * | 2013-12-26 | 2014-04-23 | 惠州华阳通用电子有限公司 | 一种基于流媒体服务集群的分布式监控系统及方法 |
US20160253422A1 (en) * | 2013-03-01 | 2016-09-01 | Quixey, Inc. | Providing Search Results based on Execution of Applications |
-
2016
- 2016-12-19 CN CN201611178766.4A patent/CN108205561A/zh active Pending
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101950300A (zh) * | 2010-09-20 | 2011-01-19 | 华南理工大学 | 一种分层结构、分布式搜索引擎系统及其实现方法 |
CN101969468A (zh) * | 2010-10-14 | 2011-02-09 | 广州从兴电子开发有限公司 | 查询服务器集群系统及查询方法 |
CN102891872A (zh) * | 2011-07-20 | 2013-01-23 | 中兴通讯股份有限公司 | 一种对等网络中数据存储和查询的方法及系统 |
US20160253422A1 (en) * | 2013-03-01 | 2016-09-01 | Quixey, Inc. | Providing Search Results based on Execution of Applications |
CN103747060A (zh) * | 2013-12-26 | 2014-04-23 | 惠州华阳通用电子有限公司 | 一种基于流媒体服务集群的分布式监控系统及方法 |
Non-Patent Citations (1)
Title |
---|
苏新宁 等: "《信息检索 理论与技术》", 30 September 2004, 科学技术文献出版社 * |
Cited By (20)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111382183B (zh) * | 2018-12-29 | 2023-06-27 | 阿里巴巴集团控股有限公司 | 一种数据查询方法及装置 |
CN111382183A (zh) * | 2018-12-29 | 2020-07-07 | 阿里巴巴集团控股有限公司 | 一种数据查询方法及装置 |
CN109922127A (zh) * | 2019-01-08 | 2019-06-21 | 博拉网络股份有限公司 | 一种云计算服务方法、装置和存储介质 |
CN109783551A (zh) * | 2019-01-08 | 2019-05-21 | 上海上湖信息技术有限公司 | 数据展示方法及系统、可读存储介质 |
CN110008257A (zh) * | 2019-04-10 | 2019-07-12 | 深圳市腾讯计算机系统有限公司 | 数据处理方法、装置、系统、计算机设备和存储介质 |
CN110008257B (zh) * | 2019-04-10 | 2024-04-16 | 深圳市腾讯计算机系统有限公司 | 数据处理方法、装置、系统、计算机设备和存储介质 |
CN110471947B (zh) * | 2019-07-09 | 2023-11-10 | 广州视源电子科技股份有限公司 | 基于分布式搜索引擎的查询方法、服务器和存储介质 |
CN110471947A (zh) * | 2019-07-09 | 2019-11-19 | 广州视源电子科技股份有限公司 | 基于分布式搜索引擎的查询方法、服务器和存储介质 |
CN111046065B (zh) * | 2019-10-28 | 2022-06-17 | 北京大学 | 可扩展的高性能分布式查询处理方法及装置 |
CN111046065A (zh) * | 2019-10-28 | 2020-04-21 | 北京大学 | 可扩展的高性能分布式查询处理方法及装置 |
CN111400555A (zh) * | 2020-03-05 | 2020-07-10 | 湖南大学 | 图数据查询任务处理方法、装置、计算机设备和存储介质 |
CN111400555B (zh) * | 2020-03-05 | 2023-09-26 | 湖南大学 | 图数据查询任务处理方法、装置、计算机设备和存储介质 |
CN112256437A (zh) * | 2020-11-10 | 2021-01-22 | 网易(杭州)网络有限公司 | 一种任务分发方法及装置 |
CN113032430B (zh) * | 2021-03-25 | 2023-12-19 | 杭州网易数之帆科技有限公司 | 一种数据处理方法、装置、介质和计算设备 |
CN113032430A (zh) * | 2021-03-25 | 2021-06-25 | 网易(杭州)网络有限公司 | 一种数据处理方法、装置、介质和计算设备 |
CN113420052B (zh) * | 2021-07-08 | 2023-02-17 | 上海浦东发展银行股份有限公司 | 一种多级分布式缓存系统及方法 |
CN113420052A (zh) * | 2021-07-08 | 2021-09-21 | 上海浦东发展银行股份有限公司 | 一种多级分布式缓存系统及方法 |
CN114911830A (zh) * | 2022-05-12 | 2022-08-16 | 平安科技(深圳)有限公司 | 基于时序数据库的索引缓存方法、装置、设备及存储介质 |
CN114911830B (zh) * | 2022-05-12 | 2024-04-05 | 平安科技(深圳)有限公司 | 基于时序数据库的索引缓存方法、装置、设备及存储介质 |
WO2024124641A1 (zh) * | 2022-12-13 | 2024-06-20 | 奇安信科技集团股份有限公司 | 一种集群负载均衡的方法和装置、电子设备和存储介质 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN108205561A (zh) | 数据查询系统、方法及装置 | |
JP6559215B2 (ja) | システム、データベースクエリを実行するための方法及びコンピュータに読み取り可能な記録媒体 | |
CN104541247B (zh) | 用于调整云计算系统的系统和方法 | |
CN104050250B (zh) | 一种分布式键-值查询方法和查询引擎系统 | |
CN104050249B (zh) | 分布式查询引擎系统和方法及元数据服务器 | |
US9424274B2 (en) | Management of intermediate data spills during the shuffle phase of a map-reduce job | |
US10324942B2 (en) | Segment data visibility and management in a distributed database of time stamped records | |
CN104903894B (zh) | 用于分布式数据库查询引擎的系统和方法 | |
US9208189B2 (en) | Distributed request processing | |
US8176256B2 (en) | Cache regions | |
Kamburugamuve et al. | Survey of distributed stream processing for large stream sources | |
US8775397B2 (en) | Database access acceleration | |
CN104025144B (zh) | 高吞吐量全球订单承诺系统 | |
CN107329982A (zh) | 一种基于分布式列式存储的大数据并行计算方法及系统 | |
EP2829976A1 (en) | Distributed storage system, storage control method and program | |
TW201619855A (zh) | 分散式環境下的服務定址方法及裝置 | |
CN107037985A (zh) | 一种超融合一体机系统及其横向和纵向扩容方法 | |
CN106233277A (zh) | 资源管理系统及方法 | |
JP5807777B2 (ja) | トランザクション処理装置、トランザクション処理方法およびトランザクション処理プログラム | |
CN103597503A (zh) | 用于具有提高的搜索效率的售前预订系统的方法和系统 | |
CA2861821A1 (en) | An inventory exchange for multiple sales channels | |
CN102053975A (zh) | 数据库系统和跨数据库查询优化方法 | |
US10812322B2 (en) | Systems and methods for real time streaming | |
CN108282522A (zh) | 基于动态路由的数据存储访问方法及系统 | |
RU2013140415A (ru) | Усовершенствованная система управления запасами и способ для ее осуществления |
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 | ||
CB02 | Change of applicant information |
Address after: 100080 No. 401, 4th Floor, Haitai Building, 229 North Fourth Ring Road, Haidian District, Beijing Applicant after: BEIJING GRIDSUM TECHNOLOGY Co.,Ltd. Address before: 100086 Cuigong Hotel, 76 Zhichun Road, Shuangyushu District, Haidian District, Beijing Applicant before: BEIJING GRIDSUM TECHNOLOGY Co.,Ltd. |
|
CB02 | Change of applicant information | ||
RJ01 | Rejection of invention patent application after publication |
Application publication date: 20180626 |
|
RJ01 | Rejection of invention patent application after publication |