CN113111083A - 数据查询的方法、装置、设备、存储介质和程序产品 - Google Patents

数据查询的方法、装置、设备、存储介质和程序产品 Download PDF

Info

Publication number
CN113111083A
CN113111083A CN202110348279.2A CN202110348279A CN113111083A CN 113111083 A CN113111083 A CN 113111083A CN 202110348279 A CN202110348279 A CN 202110348279A CN 113111083 A CN113111083 A CN 113111083A
Authority
CN
China
Prior art keywords
query
data
priority
request
requests
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
Application number
CN202110348279.2A
Other languages
English (en)
Inventor
陈洪健
屠志强
钱叶
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Jingdong Century Trading Co Ltd
Beijing Wodong Tianjun Information Technology Co Ltd
Original Assignee
Beijing Jingdong Century Trading Co Ltd
Beijing Wodong Tianjun Information Technology Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Beijing Jingdong Century Trading Co Ltd, Beijing Wodong Tianjun Information Technology Co Ltd filed Critical Beijing Jingdong Century Trading Co Ltd
Priority to CN202110348279.2A priority Critical patent/CN113111083A/zh
Publication of CN113111083A publication Critical patent/CN113111083A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24Querying
    • G06F16/245Query processing
    • G06F16/2455Query execution
    • G06F16/24568Data stream processing; Continuous queries

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computational Linguistics (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本申请提供一种数据查询的方法、装置、设备、存储介质和程序产品。本申请的方法,通过根据所述查询请求的业务优先级、查询属性信息、消耗资源类型信息,确定所述查询请求对应的优先级;根据所述查询请求对应的优先级,将所述查询请求插入查询队列,所述查询队列中的查询请求按照对应的优先级排序;根据查询请求对应的优先级,对所述查询队列中的查询请求进行查询处理,能够优先处理消耗资源少、业务优先级高的快查询,能够保证核心业务优先处理的同时,提高查询响应时间,减少高并发对集群的影响,提高集群稳定性。

Description

数据查询的方法、装置、设备、存储介质和程序产品
技术领域
本申请涉及计算机技术,尤其涉及一种数据查询的方法、装置、设备、存储介质和程序产品。
背景技术
Clickhouse是一个用于联机分析的列式数据库管理系统,通常部署在集群上,应用范围非常广。高吞吐高并发查询是Clickhouse的性能瓶颈,为了解决这个问题,根据业务需求对业务数据的明细数据表进行预计算处理生成预计算表,同时对已查询过的数据进行缓存。当新的查询请求下发时,集群会优先查询缓存,然后查询预计算表,最后查询明细数据表,以此来减少大量查询对集群造成的压力。
在实现本申请过程中,发明人发现现有技术中至少存在如下问题:在高吞吐高并发的查询场景下,仍然存在查询响应时间长、集群稳定性差的问题。
发明内容
本申请提供一种数据查询的方法、装置、设备、存储介质和程序产品,用以解决在高吞吐高并发的查询场景下,仍然存在查询响应时间长、集群稳定性差的问题。
一方面,本申请提供一种数据查询的方法,应用于数据查询系统的服务器,包括:
响应于查询请求,根据所述查询请求的业务优先级、查询属性信息、消耗资源类型信息,确定所述查询请求对应的优先级;
根据所述查询请求对应的优先级,将所述查询请求插入查询队列,所述查询队列中的查询请求按照对应的优先级排序;
根据查询请求对应的优先级,对所述查询队列中的查询请求进行查询处理。
另一方面,本申请提供一种数据查询的装置,包括:
优先级确定单元,用于响应于查询请求,根据所述查询请求的属性信息,确定所述查询请求对应的优先级;
查询队列管理单元,用于根据所述查询请求对应的优先级,将所述查询请求插入查询队列,所述查询队列中的查询请求按照对应的优先级排序;
查询处理单元,用于根据查询请求对应的优先级,对所述查询队列中的查询请求进行查询处理。
另一方面,本申请提供一种服务器,应用于数据查询系统,包括:
处理器,存储器,以及存储在所述存储器上并可在所述处理器上运行的计算机程序;
其中,所述处理器运行所述计算机程序时实现上述所述的方法。
另一方面,本申请一种计算机可读存储介质,所述计算机可读存储介质中存储有计算机程序,所述计算机程序被处理器执行时实现上述所述的方法。
另一方面,本申请一种计算机程序产品,包括计算机程序,该计算机程序被处理器执行时实现上述所述的方法。
本申请提供的数据查询的方法、装置、设备、存储介质和程序产品,通过根据所述查询请求的业务优先级、查询属性信息、消耗资源类型信息,确定所述查询请求对应的优先级;根据所述查询请求对应的优先级,将所述查询请求插入查询队列,所述查询队列中的查询请求按照对应的优先级排序;根据查询请求对应的优先级,对所述查询队列中的查询请求进行查询处理,能够优先处理消耗资源少、业务优先级高的快查询,能够保证核心业务优先处理的同时,提高查询响应时间,减少高并发对集群的影响,提高集群稳定性。
附图说明
此处的附图被并入说明书中并构成本说明书的一部分,示出了符合本申请的实施例,并与说明书一起用于解释本申请的原理。
图1为本申请实施例提供的数据查询系统架构示意图;
图2为本申请实施例提供的数据查询的方法流程图;
图3为本申请另一实施例提供的数据查询的方法流程图;
图4为本申请实施例提供的多级缓存模型架构的示意图;
图5为本申请实施例提供的多集群协作联合查询的架构示意图;
图6为本申请另一实施例提供的数据查询的方法流程图;
图7为本申请实施例提供的数据查询的装置的结构示意图;
图8为本申请另一实施例提供的数据查询的装置的结构示意图;
图9为本申请实施例提供的服务器的结构示意图。
通过上述附图,已示出本申请明确的实施例,后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本申请构思的范围,而是通过参考特定实施例为本领域技术人员说明本申请的概念。
具体实施方式
这里将详细地对示例性实施例进行说明,其示例表示在附图中。下面的描述涉及附图时,除非另有表示,不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反,它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。
首先对本申请所涉及的名词进行解释:
Clickhouse是一个用于联机分析的列式数据库管理系统。
peak_mem:查询的峰值内存,单位为byte,可用于判断消耗内存资源较多的查询请求/查询语句。
scan_rows:从数据源表扫描的行数,可用于判断某一查询请求/查询语句是否扫描了大量数据。
scan_size:从数据源表扫描的数据量,单位为byte。
scan_time:从数据源表扫描数据消耗的时间累加值,单位为毫秒,可用于初步判断过滤条件是否合适、过滤条件是否下推、索引是否生效等。
operator_cost:查询语句执行的CPU消耗,单位为byte,可用于判断消耗CPU资源较多的查询请求/查询语句。
本申请提供的数据查询的方法,具体可以应用于如图1所示的数据查询系统架构,如图1所示,数据查询系统包括服务器10和一个或者多个集群11,(图1中以多个Clickhouse集群为例进行示例性地说明),通过根据业务优先级和消耗资源类型的不同,将所有的查询进行了优先级划分,查询队列中的查询请求按照优先级排序,在进行查询处理时,按照查询请求的优先级先后处理各个查询请求,能够优先处理消耗资源少、业务优先级高的快查询,能够保证核心业务优先处理的同时,提高查询响应时间,减少高并发对集群的影响,提高集群稳定性。
另外,当单一集群的性能瓶颈达不到业务要求时,目前通过增加集群的硬件设备和限制查询量来增加集群可以承受的峰值查询数量。单个集群的性能有限,如果一味的提升单个集群的查询性能,会增加集群崩溃的风险,限制查询量则会影响数据的展示和用户使用。因此,目前基于单一Clickhouse集群的数据查询系统存在查询效率低、可靠性差的问题。
本申请中数据查询系统可以包括多个集群,将相同的数据同步存储到多个集群中,服务器10上包括查询消费模块、集群资源监控模块、集群资源提供模块、集群资源注册模块,通过这些模块实现基于多个集群11的联合数据查询和负载均衡,能够提高多集群的数据查询系统整体的并发能力,大大提高了数据查询的效率。
下面以具体地实施例对本申请的技术方案以及本申请的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合,对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图,对本申请的实施例进行描述。
图2为本申请实施例提供的数据查询的方法流程图。本申请实施例提供的数据查询的方法,可以应用于数据查询系统的服务器,在其他实施例中,该方法还可应用于其他设备,本实施例以服务器为例进行示意性说明。如图2所示,该方法具体步骤如下:
步骤S101、响应于查询请求,根据查询请求的业务优先级、查询属性信息、消耗资源类型信息,确定查询请求对应的优先级。
本实施例中,为了提升基于Clickhouse集群的查询系统的查询响应时间,减少高并发对集群的影响,将所有的查询请求根据业务优先级和消耗资源类型的不同进行了划分。
其中,查询请求的查询属性信息包括:查询的峰值内存(peak_mem)、从数据源表扫描的行数(scan_rows)、从数据源表扫描的数据量(scan_size)、从数据表扫描数据消耗的时间累加值(scan_time)。
该步骤中,响应于查询请求,根据查询请求的业务优先级、查询属性信息、消耗资源类型信息,以及查询的优先级划分规则,确定查询请求对应的优先级
步骤S102、根据查询请求对应的优先级,将查询请求插入查询队列,查询队列中的查询请求按照对应的优先级排序。
在确定查询请求对应的优先级之后,可以根据队列分配规则,将查询请求插入一个或者多个查询队列,每个查询队列中的查询请求按照对应的优先级排序。
步骤S103、根据查询请求对应的优先级,对查询队列中的查询请求进行查询处理。
该步骤中,对于查询队列中的查询请求,根据查询请求对应的优先级先后进行查询处理。
本申请实施例通过根据查询请求的业务优先级、查询属性信息、消耗资源类型信息,确定查询请求对应的优先级;根据查询请求对应的优先级,将查询请求插入查询队列,查询队列中的查询请求按照对应的优先级排序;根据查询请求对应的优先级,对查询队列中的查询请求进行查询处理,能够优先处理消耗资源少、业务优先级高的快查询,能够保证核心业务优先处理的同时,提高查询响应时间,减少高并发对集群的影响,提高集群稳定性。
图3为本申请另一实施例提供的数据查询的方法流程图,图4为本申请实施例提供的多级缓存模型架构的示意图,图5为本申请实施例提供的多集群协作联合查询的架构示意图。在上述实施例一的基础上,本实施例中,对根据查询请求的业务优先级、查询属性信息、消耗资源类型信息,确定查询请求对应的优先级的具体实施方式进行详细地说明。
如图4所示,总体架构包括业务侧、查询请求、查询优先级划分规则、查表策略、集群监控、集群路由、Clickhouse集群等模块。其中,查询优先级划分规则模块用于对查询请求的查询类型和优先级进行划分。查表策略用于进行表优先级划分,建立多个优先级的数据表,建立各数据表的Key-Value格式的倒排索引,基于表的与那数据匹配最小表(也即是列数最少的数据表)。集群监控模块用于对集群的内存、CPU、I/O的资源情况进行监控。集群路由模块用于根据查询请求对应的优先级,将查询请求路由(分配)到对应的集群,实现对查询请求的查询处理。
如图3所示,该方法具体步骤如下:
步骤S201、响应于查询请求,根据查询请求的查询属性信息和消耗资源类型信息,确定查询请求的查询类型。
本实施例中,为了提升基于Clickhouse集群的查询系统的查询响应时间,减少高并发对集群的影响,将所有的查询请求根据业务优先级和消耗资源类型的不同进行了划分。在下发查询请求时,可以根据各个集群的资源性能特点,将不同优先级的查询请求下发到对应资源最匹配的集群。
具体地,根据查询请求的查询属性信息,确定查询请求的一级查询类型,一级查询类型包括快查询和慢查询;若查询请求为慢查询,则根据查询请求的消耗资源类型信息,确定查询请求的二级查询类型,二级查询类型包括内存型慢查询、CPU型慢查询、I/O型慢查询。
其中,快查询的优先级高于慢查询,慢查询中各二级查询类型的优先级由高到底依次为:内存型慢查询、CPU型慢查询、I/O型慢查询。
进一步地,查询请求的查询属性信息包括:查询的峰值内存(peak_mem)、从数据源表扫描的行数(scan_rows)、从数据源表扫描的数据量(scan_size)、从数据表扫描数据消耗的时间累加值(scan_time)。
如果查询请求的各项属性信息的值均小于对应的阈值,则确定查询请求的一级查询类型为快查询;如果查询请求的任意一项属性信息的值均大于或等于对应的阈值,则确定查询请求的一级查询类型为慢查询。其中快查询的优先级高于慢查询。
其中,各项属性信息的值对应的阈值可以根据实际应用场景的需要进行设置和调整,本实施例此处不做具体限定。
例如,查询的峰值内存对应的阈值可以为1G,从数据源表扫描的行数对应的阈值可以为1000万行、从数据源表扫描的数据量对应的阈值可以为2G、从数据表扫描数据消耗的时间累加值对应的阈值可以为1000毫秒。
进一步地,对于慢查询,如果查询请求的查询的峰值内存大于或等于对应阈值,则确定慢查询为内存型慢查询。如果查询请求的查询语句执行的CPU消耗大于对应的阈值,则确定慢查询为CPU型慢查询。如果查询请求的从数据表扫描数据消耗的时间累加值大于对应阈值,则确定慢查询为I/O型慢查询。其中,各二级查询类型按照优先级又高到底的顺序依次为内存型慢查询、CPU型慢查询、I/O型慢查询。如果确定某一慢查询对应多个二级查询类型,则将其中优先级最高的二级查询类型作为慢查询的二级查询类型。
步骤S202、根据查询请求的查询类型和业务优先级,确定查询请求的优先级。
本实施例中,对于同一查询类型内的查询请求,根据业务优先级确定查询请求的优先级,也就是根据业务优先级对个查询类型进一步进行优先级划分。
示例性地,业务优先级由高至低分别为P0,P1和P2,那么可以将快查询按照对应业务优先级进一步分为P0级快查询、P1级快查询和P2级快查询这三个优先级;可以将每一个二级查询类型按照对应业务优先级进一步分为三个优先级。这样,综合一级查询类型、二级查询类型和业务优先级,分成多个优先级。
示例性地,业务优先级由高至低分别为P0,P1和P2,可以根据业务优先级,将P0级的快查询作为高优先级快查询,将P1和P2级快查询作为低优先级快查询;将慢查询根据二级查询类型和业务优先级,分成高优先级慢查询和低优先级慢查询。这样,可以将所有查询请求分成四个优先级,按照优先级由高到低的顺序依次为:高优先级快查询、低优先级快查询、高优先级慢查询、低优先级慢查询(如图4中所示的查询优先级划分规则)。
例如,将内存型慢查询和CPU型慢查询作为高优先级慢查询,将I/O型慢查询作为低优先级慢查询,或者将内存型慢查询和CPU型慢查询作为高优先级慢查询,将CPU型慢查询和I/O型慢查询作为低优先级慢查询,或者还可以按照业务优先级划分高优先级慢查询和低优先级慢查询,此处对于各个优先等级的具体划分规则不做具体限定。
步骤S203、根据查询请求对应的优先级,将查询请求插入查询队列,查询队列中的查询请求按照对应的优先级排序。
本实施例中,可以根据预先设置的查询请求所有的查询类型和优先级,创建多个查询队列,其中不同查询队列对应的查询类型与优先级的组合信息不同。
示例性地,按照如图4中所示的查询优先级划分规则,将所有查询请求分成四个优先级,按照优先级由高到低的顺序依次为:高优先级快查询、低优先级快查询、高优先级慢查询、低优先级慢查询。那么,可以针对每一优先级创建对应的查询队列,高优先级快查询、低优先级快查询、高优先级慢查询、低优先级慢查询对应查询队列分别为如图5中所示资源池中的高优先级快查询队列、快查询队列、高优先级慢查询队列、慢查询队列。
该步骤中,根据查询请求的查询类型和优先级,确定查询请求对应的查询队列;将查询请求插入对应的查询队列中。
步骤S204、根据查询请求对应的优先级,对查询队列中的查询请求进行查询处理。
该步骤中,可以根据查询请求对应的优先级,并行地对多个查询队列中的查询请求进行查询处理。对于同一查询队列中的多个查询请求,按照查询请求对应的优先级由高到低的顺序先后进行查询处理。
本实施例中,通过将查询请求划分为快查询和慢查询,并对快查询和慢查询进行进一步地优先级划分,这样可以有效地对进入查询队列的查询请求进行排序,在保证核心业务优先查询的同时尽可能保持集群的稳定。
一种可选的实施方式中,还可以根据业务数据的数据明细表,生成预计算表、单指标聚合表、物化视图表和缓存表。其中,单指标聚合表中存储有对数据明细表中的单一字段的数据进行聚合处理的结果,物化视图表为单指标聚合表对应的视图,数据明细表、预计算表、单指标聚合表、物化视图表和缓存表的优先级依次升高。
在现有的数据表分级基础上,增加单指标聚合表和物化视图表,也就是在预计算的基础上建立多个单指标聚合表,基于这些单指标聚合表生成对应的视图,得到聚合表的物化视图表,并将所有查询请求的查询结果以缓存的形式存储到Redis等内存式数据库中,得到缓存表。由此,本申请在集群中根据优先级由低至高依次建立了数据明细表、预计算表、单指标聚合表、物化视图表和缓存表,能够进一步可以减少高并发查询请求对集群造成的压力。
进一步地,根据查询请求对应的优先级,对查询队列中的查询请求进行查询处理,可以采用以下方式实现:
分别建立各数据表的对应的倒排索引信息,数据表包括数据明细表、预计算表、单指标聚合表、物化视图表和缓存表;按照查询请求的优先级由高到低的顺序,分别针对每个查询请求,根据各数据表的对应的倒排索引信息,确定查询请求匹配的数据表;确定查询请求匹配的数据表中包含的列数最少的数据表;若包含的列数最少的数据表有多个,则查询包含的列数最少的数据表中优先级最高的数据表,得到查询请求对应的查询结果。这样,能够避免按照优先级由高到低逐级进行搜索造成的长时间延迟,能够提高数据查询的效率。
为了在不同的优先级的数据表搜索出结果,并提高数据查询系统的查询并发量,本申请基于倒排索引的思想,分别为每一优先级的数据表建立倒排索引信息。示例性地,可以提取每一优先级的数据表的元数据信息,根据数据表的元数据信息生成倒排索引信息。其中,倒排索引信息可以是key-value结构的信息,其中key包含数据表的字段信息(列信息),value包含数据表的名称、列数、索引信息等。在匹配查询请求对应的数据表时,将查询请求的过滤条件中涉及的字段信息与倒排索引信息中的key匹配,确定查询请求匹配的数据表,如果匹配到多个数据表,则确定匹配到的数据表中列数最少的数据表;如果列数最少的数据表为多个(多个数据表的列数相同),获取其中优先级最高的数据表,从该优先级最高的数据表中查询得到查询结果。
本申请实施例的方案,基于以上分层级的数据表和倒排索引的方法,可以在最短的时间里路由到查询请求对应的具体的数据表层级和具体的数据表,以此达到覆盖全部场景和缩短匹配时间的目的。
本实施例提出了多级缓存模型路由策略,将查询请求根据优先级进行了划分,在此基础上对数据表进行了进一步的扩展,增加了单指标聚合表和物化视图表,并采用倒排索引的思想对查询对应数据表的策略进行了优化,在保证业务场景全覆盖的同时提升了查询效率。
图6为本申请另一实施例提供的数据查询的方法流程图。在上述实施例一或者实施例二的基础上,本实施例中,数据查询系统包括多个集群,多个集群同步存储数据。服务器包括查询消费模块(也可以称为查询Consumer)、集群资源监控模块(也可以称为资源Monitor,或者Clickhouse资源Monitor)、集群资源提供模块(也可以称为资源Provider,或者Clickhouse资源Provider)、集群资源注册模块(也可以称为资源Register,或者Clickhouse资源Register),通过这些模块实现基于多个集群的联合数据查询和负载均衡,能够提高多集群的数据查询系统整体的并发能力,大大提高了数据查询的效率。其中,这些模块可以分别是一个服务,统称为Clickhouse协作路由服务。
其中,资源Provider用于在新集群上线时,向资源Register注册集群的信息。查询Consumer用于订阅资源Register中注册的资源,如果没有订阅到自己想获得的资源,可以不断的尝试订阅,直到新的资源注册到资源Register时,资源Register会将这些资源信息反馈给查询Consumer。查询Consumer和资源Register可以分别将请求信息和资源信息存放在本地磁盘。资源Monitor是一个监控服务,图5中的虚线表明查询Consumer和资源Provider可以异步地以短连接的方式发送消息至资源Monitor,例如,可以每间隔一段时间(如1分钟、30秒等)发送一次信息。资源Monitor可以对传入每个集群的查询请求和集群状态进行实时监控。
下面结合图5和图6所示,根据查询请求对应的优先级,对查询队列中的查询请求进行查询处理,可以采用如下步骤实现:
步骤S300、获取查询请求的过滤条件和历史查询数据。
其中,查询请求的过滤条件是指查询语句中的条件,例如SQL语句中的where条件。
步骤S301、确定历史查询数据中是否存在与过滤条件匹配的历史查询记录。
其中,历史查询数据包括一条或多条历史查询记录,历史查询记录包含过滤条件和过滤条件对应的集群信息。
本实施例中,可以建立查询历史服务器的机制来记录每一个传入的查询请求中的过滤条件(查询语句的where条件)和与之适配的集群信息。
在每次将查询请求发送至对应集群,也即将查询请求适配到对应集群之后,记录该查询请求的过滤条件和与之适配的集群信息,形成历史查询数据。历史查询数据会随着查询请求的传入不断更新。其中,历史查询数据可以存储在历史服务器上。
当传入查询请求时,响应于查询请求,查询Consumer可以优先在历史查询数据中对过滤条件进行检索,确定是否存在与过滤条件匹配的历史查询记录。其中,与过滤条件匹配的历史查询记录也就是包含该过滤条件的历史查询记录。
如果查询到了包含该过滤条件的历史查询记录,则执行步骤S302,为查询请求分配过滤条件对应的集群,并直接将查询请求下发到历史查询记录中与该过滤条件对应的集群,这一可以利用Clickhouse自身的缓存机制快速得到查询结果,提高查询响应速度。
如果没有查询到包含该过滤条件的历史查询记录,则执行步骤S302及后续步骤,根据集群资源量化信息,确定查询请求对应的集群。
步骤S302、若存在与过滤条件匹配的历史查询记录,则根据历史查询记录,为查询请求分配过滤条件对应的集群。
步骤S303、若不存在与过滤条件匹配的历史查询记录,根据每个集群当前的资源量化信息,为查询队列中的查询请求分配对应的集群。
本实施例中,可以通过资源Monitor服务,实时地监控集群的资源状态信息和查询负载信息;根据集群的资源状态信息和查询负载信息,更新集群的资源量化信息。其中,资源量化信息为允许承接的各优先级查询请求的数量。
在实际应用中,由于每个集群的性能不同,能够承受的快查询和慢查询的数量也不一致。为了便于集群查询资源的分配,本实施例中,在集群之上建立了资源量化信息,对每一个集群实时可以承受的各类查询的数量进行量化统计,得到集群的资源量化信息。
示例性地,量化标准以查询使用内存0.5G和扫描1000w行数据为基本资源单位,快查询使用1个资源单位,慢查询异步读取集群信息统计出需要资源单位量,以2个资源单位为基准。通过对各集群压测,确定出各集群可承接多少个资源单位,即多少个快查询和/或慢查询。进一步可以建立针对每个集群的集群资源量化信息。
例如,查询请求的优先级包括:高优先级快查询、快查询、高优先级慢查询和慢查询,优先级依次降低。集群A可以承受的查询为13个单位量,其中高优先级快查询、快查询、高优先级慢查询和慢查询数量最多分别:4,3,2,1。13个单位量=(4个高优先级快查询*1个快查询基准单位)+(3个快查询*1个快查询基准单位)+(2个高优先级慢查询*2个慢查询基准单位)+(1个慢查询*2个慢查询基准)。
根据集群中查询所消耗的资源,以及集群的配置信息,可以进一步地建立针对每个集群的资源量化信息,也就是每个集群实时可以承受的最优查询方案。
结合上述实施例中,查询请求确定查询类型和优先级后,会将同一优先级的查询请求放入同一个查询队列中,对外表现是多个集群能力统一注册在资源Register中,在同一查询队列中,查询请求所消耗的资源类似,结合资源量化信息就可以对下发到集群的查询进行限制,在充分利用每个集群的资源的同时保证了集群的稳定。
步骤S304、将查询队列中的查询请求发送至对应的集群,并接受集群返回的查询结果。
在确定查询请求对应的集群之后,将查询请求传入对应的集群,从而在对应集群上查询得到查询结果,并返回查询结果。
另外,根据集群的资源量化信息和分配规则,可能会出现大部分查询请求集中在其中几个集群的情况,此时对于其他集群的资源是一种浪费。因此可以利用资源Monitor对空闲的集群资源进行监测,例如,传入查询请求是对内存有较高消耗的,则此时需要对内存低负载情况下的集群通过轮询算法下发请求,以充分利用整个集群的资源。
一种可选的实施方式中,若确定数据查询系统中集群的使用率低于预设阈值,则为查询请求分配空闲的集群,可以减少为查询请求匹配对应集群的时间延迟,提高数据查询的效率。
例如,预设阈值可以为25%,如果数据查询系统中集群的资源使用率低于25%,则采用随机访问的方式向空闲的集群下发查询。
另外,还可以建立失败重试以及限制重试次数的机制来保证查询的高效进行。
在实际应用中,由于各个集群的性能瓶颈和实时状态不同,如果在接受到查询请求时采用随机、轮询等算法来对不同集群下发查询请求,则无法在最大程度上利用各集群的最大性能,对于集群的资源是一种浪费。
本申请提供了一种多集群协作路由策略,将集群资源依据资源量化信息和分配规则对查询请求进行路由分配,实现了多集群之间的协作查询的方案,在尽可能多的利用集群性能的同时,解决了单集群性能提升难、多集群无法充分利用资源的问题,进一步缩短了查询响应时间,提高了查询效率。
图7为本申请实施例提供的数据查询的装置的结构示意图。本申请实施例提供的数据查询的装置可以执行数据查询的方法实施例提供的处理流程。如图7所示,该数据查询的装置40包括:优先级确定单元401,查询队列管理单元402和查询处理单元403。
具体地,优先级确定单元401用于响应于查询请求,根据查询请求的属性信息,确定查询请求对应的优先级。
查询队列管理单元402用于根据查询请求对应的优先级,将查询请求插入查询队列,查询队列中的查询请求按照对应的优先级排序。
查询处理单元403用于根据查询请求对应的优先级,对查询队列中的查询请求进行查询处理。
本申请实施例提供的装置可以具体用于执行上述实施例一所提供的方法实施例,具体功能此处不再赘述。
本申请实施例通过根据查询请求的业务优先级、查询属性信息、消耗资源类型信息,确定查询请求对应的优先级;根据查询请求对应的优先级,将查询请求插入查询队列,查询队列中的查询请求按照对应的优先级排序;根据查询请求对应的优先级,对查询队列中的查询请求进行查询处理,能够优先处理消耗资源少、业务优先级高的快查询,能够保证核心业务优先处理的同时,提高查询响应时间,减少高并发对集群的影响,提高集群稳定性。
图8为本申请另一实施例提供的数据查询的装置的结构示意图。在上述图7对应实施例的基础上,一种可选的实施方式中,优先级确定单元还用于:
根据查询请求的查询属性信息和消耗资源类型信息,确定查询请求的查询类型;根据查询请求的查询类型和业务优先级,确定查询请求的优先级。
一种可选的实施方式中,优先级确定单元还用于:
根据查询请求的查询属性信息,确定查询请求的一级查询类型,一级查询类型包括快查询和慢查询;若查询请求为慢查询,则根据查询请求的消耗资源类型信息,确定查询请求的二级查询类型,二级查询类型包括内存型慢查询、CPU型慢查询、I/O型慢查询。
其中,快查询的优先级高于慢查询,慢查询中各二级查询类型的优先级由高到底依次为:内存型慢查询、CPU型慢查询、I/O型慢查询。
一种可选的实施方式中,如图8所示,数据查询的装置40还包括:
数据表管理单元404,用于:
根据业务数据的数据明细表,生成预计算表、单指标聚合表、物化视图表和缓存表;其中,单指标聚合表中存储有对数据明细表中的单一字段的数据进行聚合处理的结果,物化视图表为单指标聚合表对应的视图,数据明细表、预计算表、单指标聚合表、物化视图表和缓存表的优先级依次升高。
一种可选的实施方式中,查询处理单元还用于:
分别建立各数据表的对应的倒排索引信息,数据表包括数据明细表、预计算表、单指标聚合表、物化视图表和缓存表;按照查询请求的优先级由高到低的顺序,分别针对每个查询请求,根据各数据表的对应的倒排索引信息,确定查询请求匹配的数据表;确定查询请求匹配的数据表中包含的列数最少的数据表;若包含的列数最少的数据表有多个,则查询包含的列数最少的数据表中优先级最高的数据表,得到查询请求对应的查询结果。
一种可选的实施方式中,查询队列管理单元,还用于:
根据查询请求的查询类型和优先级,确定查询请求对应的查询队列;将查询请求插入对应的查询队列中。
一种可选的实施方式中,查询队列管理单元,还用于:根据查询请求的查询类型和优先级,确定查询请求对应的查询队列之前,根据预先设置的查询请求所有的查询类型和优先级,创建多个查询队列,其中不同查询队列对应的查询类型与优先级的组合信息不同。
一种可选的实施方式中,查询处理单元还用于:
根据查询请求对应的优先级,并行地对多个查询队列中的查询请求进行查询处理。
一种可选的实施方式中,数据查询系统包括多个集群,多个集群同步存储数据。
查询处理单元还用于:
根据每个集群当前的资源量化信息,为查询队列中的查询请求分配对应的集群;将查询队列中的查询请求发送至对应的集群,并接受集群返回的查询结果。
一种可选的实施方式中,如图8所示,数据查询的装置40还包括:
监控单元405,用于:
实时地监控集群的资源状态信息和查询负载信息;根据集群的资源状态信息和查询负载信息,更新集群的资源量化信息;
其中,资源量化信息为允许承接的各优先级查询请求的数量。
一种可选的实施方式中,如图8所示,数据查询的装置40还包括:
资源注册单元406,用于:
响应于任一集群启动消息,获取集群的资源状态信息和查询负载信息;存储集群的资源状态信息和查询负载信息。
一种可选的实施方式中,查询处理单元还用于:
根据每个集群当前的资源量化信息,为查询队列中的查询请求分配对应的集群之前,根据查询请求的过滤条件,查询历史查询数据,确定是否存在与过滤条件匹配的历史查询记录,其中历史查询数据包括一条或多条历史查询记录,历史查询记录包含过滤条件和过滤条件对应的集群信息;若存在与过滤条件匹配的历史查询记录,则根据历史查询记录,为查询请求分配过滤条件对应的集群;若不存在与过滤条件匹配的历史查询记录,执行根据每个集群当前的资源量化信息,为查询队列中的查询请求分配对应的集群的步骤。
一种可选的实施方式中,查询处理单元还用于:
根据查询请求对应的优先级,对查询队列中的查询请求进行查询处理之前,若确定数据查询系统中集群的使用率低于预设阈值,则为查询请求分配空闲的集群。
本申请实施例提供的装置可以具体用于执行上述任意方法实施例所提供的方法实施例,具体功能此处不再赘述。
本实施例提出了多级缓存模型路由策略,将查询请求根据优先级进行了划分,在此基础上对数据表进行了进一步的扩展,增加了单指标聚合表和物化视图表,并采用倒排索引的思想对查询对应数据表的策略进行了优化,在保证业务场景全覆盖的同时提升了查询效率。
本申请提供了一种多集群协作路由策略,将集群资源依据资源量化信息和分配规则对查询请求进行路由分配,实现了多集群之间的协作查询的方案,在尽可能多的利用集群性能的同时,解决了单集群性能提升难、多集群无法充分利用资源的问题,进一步缩短了查询响应时间,提高了查询效率。
图9为本申请实施例提供的服务器的结构示意图。如图9所示,该设备100包括:处理器1001,存储器1002,以及存储在存储器1002上并可在处理器1001上运行的计算机程序。
其中,处理器1001运行计算机程序时实现上述任一方法实施例提供的数据查询的方法。
本申请实施例通过根据查询请求的业务优先级、查询属性信息、消耗资源类型信息,确定查询请求对应的优先级;根据查询请求对应的优先级,将查询请求插入查询队列,查询队列中的查询请求按照对应的优先级排序;根据查询请求对应的优先级,对查询队列中的查询请求进行查询处理,能够优先处理消耗资源少、业务优先级高的快查询,能够保证核心业务优先处理的同时,提高查询响应时间,减少高并发对集群的影响,提高集群稳定性。
另外,本申请还提供一种计算机可读存储介质,计算机可读存储介质中存储有计算机程序,计算机程序被处理器执行时实现上述任一方法实施例提供的数据查询的方法。
本申请还提供了一种计算机程序产品,计算机程序产品包括:计算机程序,计算机程序存储在可读存储介质中,服务器的至少一个处理器可以从可读存储介质读取计算机程序,至少一个处理器执行计算机程序使得服务器执行上述任一实施例提供的方案。
本领域技术人员可以清楚地了解到,为描述的方便和简洁,仅以上述各功能模块的划分进行举例说明,实际应用中,可以根据需要而将上述功能分配由不同的功能模块完成,即将装置的内部结构划分成不同的功能模块,以完成以上描述的全部或者部分功能。上述描述的装置的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。
本领域技术人员在考虑说明书及实践这里公开的发明后,将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化,这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的,本申请的真正范围和精神由下面的权利要求书指出。
应当理解的是,本申请并不局限于上面已经描述并在附图中示出的精确结构,并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求书来限制。

Claims (17)

1.一种数据查询的方法,其特征在于,应用于数据查询系统的服务器,包括:
响应于查询请求,根据所述查询请求的业务优先级、查询属性信息、消耗资源类型信息,确定所述查询请求对应的优先级;
根据所述查询请求对应的优先级,将所述查询请求插入查询队列,所述查询队列中的查询请求按照对应的优先级排序;
根据查询请求对应的优先级,对所述查询队列中的查询请求进行查询处理。
2.根据权利要求1所述的方法,其特征在于,所述响应于查询请求,根据所述查询请求的业务优先级、查询属性信息、消耗资源类型信息,确定所述查询请求对应的优先级,包括:
根据所述查询请求的查询属性信息和消耗资源类型信息,确定所述查询请求的查询类型;
根据所述查询请求的查询类型和业务优先级,确定所述查询请求的优先级。
3.根据权利要求2所述的方法,其特征在于,所述根据所述查询请求的查询属性信息和消耗资源类型信息,确定所述查询请求的查询类型,包括:
根据所述查询请求的查询属性信息,确定所述查询请求的一级查询类型,所述一级查询类型包括快查询和慢查询;
若所述查询请求为慢查询,则根据所述查询请求的消耗资源类型信息,确定所述查询请求的二级查询类型,所述二级查询类型包括内存型慢查询、CPU型慢查询、I/O型慢查询;
其中,快查询的优先级高于慢查询,慢查询中各二级查询类型的优先级由高到底依次为:内存型慢查询、CPU型慢查询、I/O型慢查询。
4.根据权利要求1所述的方法,其特征在于,所述方法还包括:
根据业务数据的数据明细表,生成预计算表、单指标聚合表、物化视图表和缓存表;
其中,所述单指标聚合表中存储有对所述数据明细表中的单一字段的数据进行聚合处理的结果,所述物化视图表为所述单指标聚合表对应的视图,所述数据明细表、预计算表、单指标聚合表、物化视图表和缓存表的优先级依次升高。
5.根据权利要求4所述的方法,其特征在于,所述根据查询请求对应的优先级,对所述查询队列中的查询请求进行查询处理,包括:
分别建立各数据表的对应的倒排索引信息,所述数据表包括数据明细表、预计算表、单指标聚合表、物化视图表和缓存表;
按照所述查询请求的优先级由高到低的顺序,分别针对每个所述查询请求,根据所述各数据表的对应的倒排索引信息,确定所述查询请求匹配的数据表;
确定所述查询请求匹配的数据表中包含的列数最少的数据表;
若所述包含的列数最少的数据表有多个,则查询所述包含的列数最少的数据表中优先级最高的数据表,得到所述查询请求对应的查询结果。
6.根据权利要求3所述的方法,其特征在于,所述根据所述查询请求对应的优先级,将所述查询请求插入查询队列,所述查询队列中的查询请求按照对应的优先级排序,包括:
根据所述查询请求的查询类型和优先级,确定所述查询请求对应的查询队列;
将所述查询请求插入对应的查询队列中。
7.根据权利要求6所述的方法,其特征在于,所述根据所述查询请求的查询类型和优先级,确定所述查询请求对应的查询队列之前,还包括:
根据预先设置的查询请求所有的查询类型和优先级,创建多个查询队列,其中不同查询队列对应的查询类型与优先级的组合信息不同。
8.根据权利要求7所述的方法,其特征在于,所述根据查询请求对应的优先级,对所述查询队列中的查询请求进行查询处理,包括:
根据查询请求对应的优先级,并行地对所述多个查询队列中的查询请求进行查询处理。
9.根据权利要求1-8中任一项所述的方法,其特征在于,所述数据查询系统包括多个集群,所述多个集群同步存储数据,
所述根据查询请求对应的优先级,对所述查询队列中的查询请求进行查询处理,包括:
根据每个集群当前的资源量化信息,为所述查询队列中的查询请求分配对应的集群;
将所述查询队列中的查询请求发送至对应的集群,并接受集群返回的查询结果。
10.根据权利要求9所述的方法,其特征在于,还包括:
实时地监控所述集群的资源状态信息和查询负载信息;
根据所述集群的资源状态信息和查询负载信息,更新所述集群的资源量化信息;
其中,所述资源量化信息为允许承接的各优先级查询请求的数量。
11.根据权利要求10所述的方法,其特征在于,还包括:
响应于任一集群启动消息,获取所述集群的资源状态信息和查询负载信息;
存储所述集群的资源状态信息和查询负载信息。
12.根据权利要求9所述的方法,其特征在于,所述根据每个集群当前的资源量化信息,为所述查询队列中的查询请求分配对应的集群之前,还包括:
根据所述查询请求的过滤条件,查询历史查询数据,确定是否存在与所述过滤条件匹配的历史查询记录,其中所述历史查询数据包括一条或多条历史查询记录,所述历史查询记录包含所述过滤条件和所述过滤条件对应的集群信息;
若存在与所述过滤条件匹配的历史查询记录,则根据所述历史查询记录,为所述查询请求分配所述过滤条件对应的集群;
若不存在与所述过滤条件匹配的历史查询记录,执行所述根据每个集群当前的资源量化信息,为所述查询队列中的查询请求分配对应的集群的步骤。
13.根据权利要求9所述的方法,其特征在于,所述根据查询请求对应的优先级,对所述查询队列中的查询请求进行查询处理之前,还包括:
若确定所述数据查询系统中集群的使用率低于预设阈值,则为所述查询请求分配空闲的集群。
14.一种数据查询的装置,其特征在于,包括:
优先级确定单元,用于响应于查询请求,根据所述查询请求的属性信息,确定所述查询请求对应的优先级;
查询队列管理单元,用于根据所述查询请求对应的优先级,将所述查询请求插入查询队列,所述查询队列中的查询请求按照对应的优先级排序;
查询处理单元,用于根据查询请求对应的优先级,对所述查询队列中的查询请求进行查询处理。
15.一种服务器,其特征在于,应用于数据查询系统,包括:
处理器,存储器,以及存储在所述存储器上并可在所述处理器上运行的计算机程序;
其中,所述处理器运行所述计算机程序时实现如权利要求1-13中任一项所述的方法。
16.一种计算机可读存储介质,其特征在于,所述计算机可读存储介质中存储有计算机程序,所述计算机程序被处理器执行时实现如权利要求1-13中任一项所述的方法。
17.一种计算机程序产品,其特征在于,包括计算机程序,该计算机程序被处理器执行时实现权利要求1-13中任一项所述的方法。
CN202110348279.2A 2021-03-31 2021-03-31 数据查询的方法、装置、设备、存储介质和程序产品 Pending CN113111083A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202110348279.2A CN113111083A (zh) 2021-03-31 2021-03-31 数据查询的方法、装置、设备、存储介质和程序产品

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202110348279.2A CN113111083A (zh) 2021-03-31 2021-03-31 数据查询的方法、装置、设备、存储介质和程序产品

Publications (1)

Publication Number Publication Date
CN113111083A true CN113111083A (zh) 2021-07-13

Family

ID=76713164

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202110348279.2A Pending CN113111083A (zh) 2021-03-31 2021-03-31 数据查询的方法、装置、设备、存储介质和程序产品

Country Status (1)

Country Link
CN (1) CN113111083A (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115334010A (zh) * 2022-08-08 2022-11-11 浙江大华技术股份有限公司 查询信息的处理方法和装置、存储介质及电子装置

Citations (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020143661A1 (en) * 2001-03-30 2002-10-03 Tumulty William J. System and method for prioritizing customer inquiries
US20120151063A1 (en) * 2010-12-10 2012-06-14 Salesforce.Com, Inc. Systems and techniques for utilizing resource aware queues and/or service sharing in a multi-server environment
CN103177035A (zh) * 2011-12-26 2013-06-26 中国银联股份有限公司 一种在数据库中查询数据的装置及方法
US20150234831A1 (en) * 2012-10-19 2015-08-20 Telefonaktiebolaget L M Ericsson (Publ) Federated database system
US20160147888A1 (en) * 2014-11-21 2016-05-26 Red Hat, Inc. Federation optimization using ordered queues
CN106294472A (zh) * 2015-06-03 2017-01-04 中国移动通信集团广东有限公司 一种Hadoop数据库HBase的查询方法及装置
CN108595254A (zh) * 2018-03-09 2018-09-28 北京永洪商智科技有限公司 一种查询调度方法
CN109361750A (zh) * 2018-10-24 2019-02-19 上海精数信息科技有限公司 资源分配方法、装置、电子设备、存储介质
US10318346B1 (en) * 2016-09-23 2019-06-11 Amazon Technologies, Inc. Prioritized scheduling of data store access requests
CN110166282A (zh) * 2019-04-16 2019-08-23 苏宁易购集团股份有限公司 资源分配方法、装置、计算机设备和存储介质
CN110609742A (zh) * 2019-09-25 2019-12-24 苏州浪潮智能科技有限公司 一种Kubernetes调度器的队列的配置方法和装置
CN112308457A (zh) * 2020-11-23 2021-02-02 Oppo(重庆)智能科技有限公司 一种资源分配方法、装置及计算机可读存储介质

Patent Citations (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020143661A1 (en) * 2001-03-30 2002-10-03 Tumulty William J. System and method for prioritizing customer inquiries
US20120151063A1 (en) * 2010-12-10 2012-06-14 Salesforce.Com, Inc. Systems and techniques for utilizing resource aware queues and/or service sharing in a multi-server environment
CN103177035A (zh) * 2011-12-26 2013-06-26 中国银联股份有限公司 一种在数据库中查询数据的装置及方法
US20150234831A1 (en) * 2012-10-19 2015-08-20 Telefonaktiebolaget L M Ericsson (Publ) Federated database system
US20160147888A1 (en) * 2014-11-21 2016-05-26 Red Hat, Inc. Federation optimization using ordered queues
CN106294472A (zh) * 2015-06-03 2017-01-04 中国移动通信集团广东有限公司 一种Hadoop数据库HBase的查询方法及装置
US10318346B1 (en) * 2016-09-23 2019-06-11 Amazon Technologies, Inc. Prioritized scheduling of data store access requests
CN108595254A (zh) * 2018-03-09 2018-09-28 北京永洪商智科技有限公司 一种查询调度方法
CN109361750A (zh) * 2018-10-24 2019-02-19 上海精数信息科技有限公司 资源分配方法、装置、电子设备、存储介质
CN110166282A (zh) * 2019-04-16 2019-08-23 苏宁易购集团股份有限公司 资源分配方法、装置、计算机设备和存储介质
CN110609742A (zh) * 2019-09-25 2019-12-24 苏州浪潮智能科技有限公司 一种Kubernetes调度器的队列的配置方法和装置
CN112308457A (zh) * 2020-11-23 2021-02-02 Oppo(重庆)智能科技有限公司 一种资源分配方法、装置及计算机可读存储介质

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
刘希伟;叶蕾;于明远;梁荣华;黄庆藏;: "面向异构集群的作业调度与资源分配研究", 华中科技大学学报(自然科学版), no. 1, pages 182 - 185 *
赵姗, 周兴社, 王云岚: "基于多维QoS的集群作业调度算法", 计算机工程, no. 22, pages 80 - 82 *
郑伟;周喜超;马超;智勇;: "支持分级服务的电能质量数据库查询处理模型", 电力科学与工程, no. 11, pages 22 - 27 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115334010A (zh) * 2022-08-08 2022-11-11 浙江大华技术股份有限公司 查询信息的处理方法和装置、存储介质及电子装置
CN115334010B (zh) * 2022-08-08 2023-08-29 浙江大华技术股份有限公司 查询信息的处理方法和装置、存储介质及电子装置

Similar Documents

Publication Publication Date Title
CN108009236B (zh) 一种大数据查询方法、系统、计算机及存储介质
US11734271B2 (en) Data query method, apparatus and device
CN110166282B (zh) 资源分配方法、装置、计算机设备和存储介质
US20180285167A1 (en) Database management system providing local balancing within individual cluster node
US10216799B2 (en) Federated database system
US9223875B2 (en) Real-time distributed in memory search architecture
US9870269B1 (en) Job allocation in a clustered environment
WO2021258753A1 (zh) 一种业务处理方法、装置及电子设备和存储介质
CN107229623B (zh) 数据查询处理方法及装置
CN110058940B (zh) 一种多线程环境下的数据处理方法及装置
CN108228322B (zh) 一种分布式链路跟踪、分析方法及服务器、全局调度器
US9817698B2 (en) Scheduling execution requests to allow partial results
CN110807145A (zh) 查询引擎获取方法、设备和计算机可读存储介质
CN114090580A (zh) 数据处理方法、装置、设备、存储介质及产品
CN104102646B (zh) 数据处理的方法、装置及系统
CN112115160B (zh) 一种查询请求的调度方法、装置及计算机系统
CN113111083A (zh) 数据查询的方法、装置、设备、存储介质和程序产品
CN110209693A (zh) 高并发数据查询方法、装置、系统、设备及可读存储介质
CN113779084A (zh) 基于分布式的时序数据查询方法、设备、介质及产品
CN107911484B (zh) 一种消息处理的方法及装置
Gao et al. Compact, popularity-aware and adaptive hybrid data placement schemes for heterogeneous cloud storage
CN115658292A (zh) 资源调度方法、装置、计算机设备和存储介质
CN108595367B (zh) 一种基于局域网内计算机集群的服务器系统
CN112835873A (zh) 电网调控异构系统服务化访问方法、系统、设备及介质
CN113485800B (zh) 基于中心节点的自动派单方法、系统、设备及存储介质

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