CN113946600A - 数据查询方法、装置、计算机设备和介质 - Google Patents

数据查询方法、装置、计算机设备和介质 Download PDF

Info

Publication number
CN113946600A
CN113946600A CN202111227659.7A CN202111227659A CN113946600A CN 113946600 A CN113946600 A CN 113946600A CN 202111227659 A CN202111227659 A CN 202111227659A CN 113946600 A CN113946600 A CN 113946600A
Authority
CN
China
Prior art keywords
query
target
sub
query command
command
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
CN202111227659.7A
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 Kingbase Information Technologies Co Ltd
Original Assignee
Beijing Kingbase Information Technologies 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 Kingbase Information Technologies Co Ltd filed Critical Beijing Kingbase Information Technologies Co Ltd
Priority to CN202111227659.7A priority Critical patent/CN113946600A/zh
Publication of CN113946600A publication Critical patent/CN113946600A/zh
Pending legal-status Critical Current

Links

Images

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/2455—Query execution
    • G06F16/24564—Applying rules; Deductive 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/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/242—Query formulation
    • G06F16/2433—Query languages
    • 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/2453—Query optimisation

Landscapes

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

Abstract

本公开涉及一种数据查询方法、装置、计算机设备和介质；其中，该方法包括：获取目标查询命令，并根据分解算法将目标查询命令分解为多个子查询命令；根据预设策略对每个子查询命令进行处理，确定对应的逻辑查询计划；对逻辑查询计划进行物理优化，得到每个子查询命令对应的目标引擎，以使目标引擎执行对应的子查询命令，得到执行结果；接收目标引擎发送的执行结果。本公开实施例通过对目标查询命令进行分解，为每个子查询命令确定合适的目标引擎，能够进行高效的数据查询，避免出现查询失败的情况。

Description

数据查询方法、装置、计算机设备和介质
技术领域
本公开涉及数据查询技术领域，尤其涉及一种数据查询方法、装置、计算机设备和介质。
背景技术
近几年随着入网终端数的不断增长以及服务提供商对收集用户数据的需求不断上涨，大数据时代的数据规模发生了本质的改变，在这个过程中，爆炸增长的不仅是数据量，还包括数据的种类。如何在众多的数据库中进行数据查询变得尤为重要。
传统的数据查询方案中，用户在查询前必须了解数据的存储位置并在构建查询时指明存储位置，并且在对多种数据源进行融合查询分析时，需要对存储在异构引擎中的数据进行查询，在这种多模型数据库并存的场景下，查询性能受制于查询引擎，而查询引擎通常由用户或者由数据所在的位置决定，从而导致了某些查询无法根据查询特征来决定最佳的执行引擎。
因此，上述技术方案给用户的查询操作带来诸多困难。
发明内容
为了解决上述技术问题或者至少部分地解决上述技术问题，本公开提供了一种数据查询方法、装置、计算机设备和介质。
第一方面，本公开提供了一种数据查询方法，包括：
获取目标查询命令，并根据分解算法将所述目标查询命令分解为多个子查询命令；
根据预设策略对每个子查询命令进行处理，确定对应的逻辑查询计划；
对所述逻辑查询计划进行物理优化，得到每个子查询命令对应的目标引擎，以使所述目标引擎执行对应的子查询命令，得到执行结果；
接收所述目标引擎发送的所述执行结果。
可选的，所述预设策略包括基于规则的第一策略；
相应的，所述根据预设策略对每个子查询命令进行处理，确定对应的逻辑查询计划，包括：
获取所述第一策略中包括的查询规则；
获取所述每个子查询命令对应的操作对象以及操作类型；
根据所述操作对象以及所述操作类型，确定所述查询规则中是否包含与所述每个子查询命令相匹配的目标规则；
若包含，则根据所述目标规则确定对应的逻辑查询计划。
可选的，所述预设策略包括基于代价的第二策略；
相应的，所述根据预设策略对每个子查询命令进行处理，确定对应的逻辑查询计划，包括：
根据所述基于代价的第二策略，确定所述每个子查询命令在不同的引擎下执行时，所花费的总执行代价；
将所有总执行代价中总执行代价最小时对应的目标引擎作为所述对应的逻辑查询计划。
可选的，所述总执行代价通过以下方式计算：
确定所述每个子查询命令在不同的引擎下执行时，对应的执行代价的类型；
根据所述执行代价的类型分别确定对应的目标执行代价；
汇总所有目标执行代价，得到所述总执行代价。
可选的，所述根据分解算法将所述目标查询命令分解为多个子查询命令，包括：
将所述目标查询命令输入至所述分解算法中；
通过对所述分解算法中的所有算子进行拓扑排序，得到对应的拓扑排序结果；
根据所述拓扑排序结果，对所有算子进行模式匹配，得到对应的模式匹配结果；
根据所述模式匹配结果确定所述目标查询命令分解后对应的子查询命令。
可选的，所述根据所述模式匹配结果确定所述目标查询命令分解后对应的子查询命令，包括：
若所述模式匹配结果为目标算子与对应的上游算子满足匹配规则，则将所述上游算子对应的子查询命令作为所述目标算子对应的子查询命令，其中，所述目标算子为所有算子中的任一算子；
若所述模式匹配结果为所述目标算子与对应的上游算子不满足匹配规则，则为所述目标算子新建子查询命令；
遍历所有算子，得到所述目标查询命令分解后对应的子查询命令。
可选的，所述获取目标查询命令，包括：
获取用户输入的初始查询命令，并对所述初始查询命令进行解析，生成语法树；
对所述语法树进行语义分析，得到所述语义分析的结果；
若所述结果为通过，则对所述语法树进行逻辑优化，得到所述目标查询命令。
第二方面，本公开提供了一种数据查询装置，包括：
分解模块，用于获取目标查询命令，并根据分解算法将所述目标查询命令分解为多个子查询命令；
确定模块，用于根据预设策略对每个子查询命令进行处理，确定对应的逻辑查询计划；
优化模块，用于对所述逻辑查询计划进行物理优化，得到每个子查询命令对应的目标引擎，以使所述目标引擎执行对应的子查询命令，得到执行结果；
接收模块，用于接收所述目标引擎发送的所述执行结果。
可选的，所述预设策略包括基于规则的第一策略；
相应的，确定模块，具体用于：
获取所述第一策略中包括的查询规则；
获取所述每个子查询命令对应的操作对象以及操作类型；
根据所述操作对象以及所述操作类型，确定所述查询规则中是否包含与所述每个子查询命令相匹配的目标规则；
若包含，则根据所述目标规则确定对应的逻辑查询计划。
可选的，所述预设策略包括基于代价的第二策略；
相应的，确定模块，具体用于：
根据所述基于代价的第二策略，确定所述每个子查询命令在不同的引擎下执行时，所花费的总执行代价；
将所有总执行代价中总执行代价最小时对应的目标引擎作为所述对应的逻辑查询计划。
可选的，所述总执行代价通过以下方式计算：
确定所述每个子查询命令在不同的引擎下执行时，对应的执行代价的类型；
根据所述执行代价的类型分别确定对应的目标执行代价；
汇总所有目标执行代价，得到所述总执行代价。
可选的，分解模块，包括：
获取单元，用于获取目标查询命令；
分解单元，用于根据分解算法将所述目标查询命令分解为多个子查询命令；
相应的，分解单元，包括：
输入子单元，用于获取目标查询命令，将所述目标查询命令输入至所述分解算法中；
排序结果获取子单元，用于通过对所述分解算法中的所有算子进行拓扑排序，得到对应的拓扑排序结果；
匹配结果获取子单元，用于根据所述拓扑排序结果，对所有算子进行模式匹配，得到对应的模式匹配结果；
命令确定子单元，用于根据所述模式匹配结果确定所述目标查询命令分解后对应的子查询命令。
可选的，命令确定子单元，具体用于：
若所述模式匹配结果为目标算子与对应的上游算子满足匹配规则，则将所述上游算子对应的子查询命令作为所述目标算子对应的子查询命令，其中，所述目标算子为所有算子中的任一算子；
若所述模式匹配结果为所述目标算子与对应的上游算子不满足匹配规则，则为所述目标算子新建子查询命令；
遍历所有算子，得到所述目标查询命令分解后对应的子查询命令。
可选的，获取单元，具体用于：
获取用户输入的初始查询命令，并对所述初始查询命令进行解析，生成语法树；
对所述语法树进行语义分析，得到所述语义分析的结果；
若所述结果为通过，则对所述语法树进行逻辑优化，得到所述目标查询命令。
第三方面，本公开还提供了一种计算机设备，包括：
一个或多个处理器；
存储装置，用于存储一个或多个程序，
当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现本公开实施例中的任一种所述的数据查询方法。
第四方面，本公开还提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现本公开实施例中的任一种所述的数据查询方法。
本公开实施例提供的技术方案与现有技术相比具有如下优点：首先获取目标查询命令，并根据分解算法将目标查询命令分解为多个子查询命令，接着根据预设策略对每个子查询命令进行处理，确定对应的逻辑查询计划，然后对逻辑查询计划进行物理优化，得到每个子查询命令对应的目标引擎，以使目标引擎执行对应的子查询命令，得到执行结果，最后接收目标引擎发送的执行结果，通过对目标查询命令进行分解，为每个子查询命令确定合适的目标引擎，能够进行高效的数据查询，避免出现查询失败的情况。
附图说明
此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。
为了更清楚地说明本公开实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，对于本领域普通技术人员而言，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
图1是本公开实施例提供的一种数据查询方法的流程示意图；
图2A是本公开实施例提供的另一种数据查询方法的流程示意图；
图2B是本公开实施例中分解算法的结构示意图；
图3是本公开实施例提供的一种数据查询装置的结构示意图；
图4是本公开实施例提供的一种计算机设备的结构示意图。
具体实施方式
为了能够更清楚地理解本公开的上述目的、特征和优点，下面将对本公开的方案进行进一步描述。需要说明的是，在不冲突的情况下，本公开的实施例及实施例中的特征可以相互组合。
在下面的描述中阐述了很多具体细节以便于充分理解本公开，但本公开还可以采用其他不同于在此描述的方式来实施；显然，说明书中的实施例只是本公开的一部分实施例，而不是全部的实施例。
图1是本公开实施例提供的一种数据查询方法的流程示意图。本实施例可适用于对数据，尤其是多模态数据进行自适应数据查询的情况。本实施例方法可由数据查询装置来执行，该装置可采用硬件/或软件的方式来实现，并可配置于计算机设备中。本实施例中的方法可以由中心引擎来执行，中心引擎可以理解为处理器。如图1所示，该方法具体包括如下：
S110，获取目标查询命令，并根据分解算法将目标查询命令分解为多个子查询命令。
其中，目标查询命令可以理解为对用户输入的初始查询命令进行处理后，得到的能够直接识别的查询命令。分解算法可以理解为基于移动计算的思想，提出的近数据计算的启发式规则算法，也可以是其他的分解算法，本实施例不做限制。引擎可以理解为数据库。
由于结构化查询语言(Structured Query Language，简称SQL)的流行，给数据查询带来了极大的便利，通常情况下主要是根据查询命令对数据库中以表为组织单位存储的数据进行查询，因此，在进行数据查询的过程中，需要获取目标查询命令。多模态数据查询在实际应用场景中主要体现在对海量多模型数据进行统一查询和分析，在分析过程中，单一引擎无法适用于对所有模型数据进行处理，因此为了更高效的进行查询，在获取到目标查询命令后，根据分解算法将目标查询命令分解为多个子查询命令，能够方便后续数据查询过程的顺利进行。
S120，根据预设策略对每个子查询命令进行处理，确定对应的逻辑查询计划。
其中，预设策略可以理解为预先设定的生成对应的逻辑查询计划的策略，该策略也可以根据实际情况确定，本实施例不做具体限制。逻辑查询计划可以理解为针对不同的子查询命令，应该用哪一类引擎来进行查询。引擎可以具体包括：文档引擎、分布式键值(Key-Value，简称KV)引擎、图引擎以及关系引擎等。
在将目标查询命令分解为多个子查询命令之后，需要根据预设策略对每个子查询命令进行处理，以确定应该用哪一类引擎来对不同子查询命令进行查询，具体可以通过子查询分配组件结合子查询命令的实际查询特征或者查询代价等为子查询命令选择合适的引擎类型来执行，从而得到对应的逻辑查询计划。
S130，对逻辑查询计划进行物理优化，得到每个子查询命令对应的目标引擎，以使目标引擎执行对应的子查询命令，得到执行结果。
其中，物理优化可以理解为通过选择高效合理的存取路径和底层操作算法来提高查询效率的方式，例如，逻辑运算符使用的物理算法或者Join顺序等。目标引擎可以理解为最终执行对应子查询命令的引擎。包装器可以理解为对异构数据或者不同访问接口数据进行接口转换的软件。
通过物理优化的方式对逻辑查询计划进行优化，能够确定出每个子查询命令对应的目标引擎，例如，假设逻辑查询计划中某子查询命令对应的执行引擎类型是文档引擎，而文档引擎可能有多个，此时根据物理优化的方式，能够确定出该子查询命令对应的目标引擎，即文档引擎类型中某个具体的文档引擎。在确定了每个子查询命令对应的目标引擎之后，中心引擎需要将将子查询命令下发至对应的目标引擎，以使目标引擎就执行对应的子查询命令，从而得到执行结果。在子查询命令下发过程中，中心引擎和目标引擎之间的任务翻译和数据格式统一可以通过二者之间的包装器来完成。
S140，接收目标引擎发送的执行结果。
目标引擎执行对应的子查询命令，得到执行结果之后，通过包装器能够将执行结果发送至中心引擎，中心引擎借助包装器能够接收到目标引擎发送的执行结果，即完成执行结果的收集。同时，中心引擎再结合自身本地数据的计算就可以完成全局的数据查询并将最终的结果返回给客户端，以供客户端使用。
在本实施例中，首先获取目标查询命令，并根据分解算法将目标查询命令分解为多个子查询命令，接着根据预设策略对每个子查询命令进行处理，确定对应的逻辑查询计划，然后对逻辑查询计划进行物理优化，得到每个子查询命令对应的目标引擎，以使目标引擎执行对应的子查询命令，得到执行结果，最后接收目标引擎发送的执行结果，通过对目标查询命令进行分解，为每个子查询命令确定合适的目标引擎，能够进行高效的数据查询，避免出现查询失败的情况。
在本实施例中，可选的，所述预设策略包括基于规则的第一策略；
相应的，所述根据预设策略对每个子查询命令进行处理，确定对应的逻辑查询计划，可以具体包括：
获取所述第一策略中包括的查询规则；
获取所述每个子查询命令对应的操作对象以及操作类型；
根据所述操作对象以及所述操作类型，确定所述查询规则中是否包含与所述每个子查询命令相匹配的目标规则；
若包含，则根据所述目标规则确定对应的逻辑查询计划。
其中，基于规则的第一策略可以理解为基于子查询命令的实际查询特征为子查询命令选择合适的引擎类型的方法。本实施例中针对每种引擎擅长的查询类型，对其进行归纳形成了自适应查询中可以直接使用的启发式子查询分配策略，即：基于规则的第一策略。操作对象可以理解为子查询命令中包含的相关查询操作的对象，例如文本字段、数组或者表等。操作类型可以理解为子查询命令中包含的相关查询操作的类型，例如对某一文本字段的匹配或者对某数组的检索等。
本实施例中，通过读取第一策略能够获取第一策略中包括的查询规则，根据子查询命令能够获取每个子查询命令对应的操作对象以及操作类型，然后确定查询规则中是否包含与每个子查询命令中的操作对象以及操作类型相匹配的目标规则，如果包含，则根据目标规则确定对应的逻辑查询计划；如果不包含，则根据其他的预设策略，例如基于代价的第二策略，确定对应的逻辑查询计划，上述方法中能够根据子查询命令的实际查询特征为子查询命令选择合适的引擎类型，有利于提高最终的查询效率。
在本实施例中，可选的，查询规则可以包括以下规则中的至少一种：
1、若某个子查询命令中包含对某一文本字段的模糊匹配、精确匹配或者正则匹配等匹配方式，则将文档引擎确定为该子查询命令的引擎类型。
全文检索场景主要应用是表中有一些字段用来存储大量的文本信息，并且用户在查询时需要针对这些文本信息匹配某些查找内容，文档引擎针对这种字段可以创建全文索引用于高效的检索。文档引擎的全文索引实现可以由分词组件、语言处理组件和索引组件组成，索引组件会将预处理之后的词组织成一个字典并按照词的维度进行排序，合并相同的词并组成倒排索引。通过这种倒排索引的建立可以快速、高效地从具体的词映射到对应的文档，此外因为在建立索引时引擎维护了上述的文档频次和词频，所以文档引擎可以借助这两个指标设计一些相关性计算的算法从而找到全文中和查询相关度最高的文档信息。因此，当在大量数据下对某一字段进行类似LIKE的模糊匹配、精确匹配以及正则匹配时，可以将这种子查询命令由文档引擎来处理，以通过文档引擎的全文检索能力进行计算。
2、若某个子查询命令中包含对数组或者嵌入文档的检索，则将文档引擎确定为该子查询命令的引擎类型。
数组是用来存储相同类型数据的集合，数据类型包括基本数据类型，例如整型数、字符串型以及由基本类型组合成的复合数据类型等，其中，复合数据类型可以为由整型数和字符串型组成的结构体。常见的查询包括对数组中元素的搜索，一般引擎对数组字段的查询是通过顺序扫描的方式进行筛选，但是文档引擎可以对这种数组类型建立索引，如果数组中元素是基本数据类型，索引的创建过程和传统的关系引擎类似，文档引擎会对所有数组中所有的元素为数据集去建立索引，此外当数组元素类型是复合类型，例如嵌套文档的结构时，文档引擎也可以对嵌套文档中的字段创建索引结构。
3、在某个子查询命令的所有操作中，如果涉及到某张表的列数与该表所有列的列数之间的比值到达预先设定的阈值α，则将KV引擎确定为该子查询命令的引擎类型。
在线联机查询处理(On Line Analysis Processing，简称OLAP)分析场景下，一个表可能有几十列甚至上百列，使用列式查询引擎不需要将无关列加载到内存中计算，因此可以节省内存资源并减少磁盘输入/输出(Input/Output，简称I/O)。此外，每列数据都有自己的数据类型，不同的数据类型需要使用不同的反序列化器，在行存储方式下对于每一列需要频繁切换反序列化器，会消耗很多中央处理器(Central Processing Unit，简称CPU)资源。相比行存储，列式存储的反序列化解析过程更方便。同时，列式存储相邻单位存储了相同类型的数据，所以可以使用更高效的压缩算法将数据块进行压缩，从而获得更小的磁盘空间。
4、在某个子查询命令中，对某张表进行过滤筛选的列如果和这张表在列式查询引擎中的行键(RowKey)相匹配，则将KV引擎确定为该子查询命令的引擎类型。
在KV查询引擎中，每行数据通常会设置一个RowKey来标识这行数据，为了保证大规模数据下的查询效率，引擎会将所有的数据按照RowKey进行排序并存储。RowKey的设计可以由用户指定，但是需要满足系统要求的长度，所以如果在设计表时可以将RowKey设计成特殊的格式，例如RowKey中包含查询频率较高的属性，就可以将Rowkey作为类似于索引的功能，并且RowKey有序存储的特点可以让类似的范围查询和点查询获得非常高的查询性能。在海量数据下，通过RowKey查询的效率高于传统关系引擎中的索引功能。KV引擎对RowKey的存储是按照字典序进行排列并且全局有序，所以如果用RowKey去存储某些属性，在对这个属性进行筛选时就可以利用这个特征构造开始行键(Start-RowKey)和结束行键(End-Rowkey)从而进行范围查询和点查询。
5、如果某个子查询命令中包含模式匹配(图相关的算法)相关的操作，则将图引擎确定为该子查询命令的引擎类型。
图模型通常会包含大规模数量的节点以及节点之间复杂的关系，节点和关系是图模型中的基本元素，模式指的是将节点和关系编排成任意复杂的想法。在关系模型中，每查询一个关系就意味着多一个关联的表，所以模式匹配类的查询在关系引擎的中的实现将十分困难。首先是语义表达的困难，对于复杂的模式匹配很难直接想到如何通过关联多个二维关系表进行表达，而使用图引擎的语言提供了便利；其次是对复杂模式计算效率的差异，关系引擎对此的实现是将多表做关联，并且随着模式的复杂，关联表的数量也会越来越大，这将会给关系引擎的查询优化带来不小的挑战。图引擎对这种模式匹配计算较快，因为其内部对节点和关系的存储和关系引擎不同，在初始化时就将节点和关系之间通过指针的方式进行连接，模式匹配的过程就相当于进行一次图的查找。
6、若某个子查询命令中涉及多表连接操作并且任意两表之间进行连接的条件与图引擎中两表建立的关系相匹配，便将图引擎确定为该子查询命令的引擎类型。
在传统的SQL查询中多个关系表进行连接的查询较难处理，关系引擎在解决这个问题时通常不是寻找最优的算法而是避免使用最差的算法。在选择了非最差的算法后，多表进行关联的代价也较大，不但需要不断从磁盘加载数据，而且还要在内存中不断使用连接算法对两表数据进行扫描，所以连接操作不但是I/O密集型操作而且是CPU密集型操作。当连接表的数量上升到一定级别后，即使使用了最佳的连接次序和最佳的连接算法，这种查询也要耗费很多系统资源。
在图引擎中，不同实体之间通过建立关系进行连接，而当对两个实体进行连接匹配时无需像关系引擎中一样进行大范围的扫描。在图引擎中，实体之间的关系类似于实体之间的指针来连接两条记录，并且通过图引擎中更为高效的图遍历算法能够让这种连接匹配更加高效。
本实施例中，通过上述查询规则，有利于确定每个子查询命令对应的逻辑查询计划，提高处理效率。
在本实施例中，可选的，所述预设策略包括基于代价的第二策略；
相应的，所述根据预设策略对每个子查询命令进行处理，确定对应的逻辑查询计划，可以具体包括：
根据所述基于代价的第二策略，确定所述每个子查询命令在不同的引擎下执行时，所花费的总执行代价；
将所有总执行代价中总执行代价最小时对应的目标引擎作为所述对应的逻辑查询计划。
其中，基于代价的第二策略可以理解为基于查询代价为子查询命令选择合适的引擎类型的方法。查询代价可以理解为子查询命令在不同的引擎下执行时，所花费的执行代价。
具体的，在实际的查询场景中受限于查询规则的数量和查询的复杂性，当基于规则的第一策略无法确定逻辑查询计划时可以使用基于代价的第二策略为子查询命令选择合适的引擎类型；也可以直接使用基于代价的第二策略为子查询命令选择合适的引擎类型；还可以使用将基于规则的第一策略和基于代价的第二策略相结合的方式为子查询命令选择合适的引擎类型。基于代价的第二策略主要是通过计算每个子查询命令在不同引擎中执行时所消耗资源的权重来决定合适的引擎类型。
本实施例中，根据基于代价的第二策略，分别计算每个子查询命令在不同的引擎下执行时，所花费的总执行代价，然后将所有总执行代价中总执行代价最小时对应的目标引擎作为对应的逻辑查询计划，能够为子查询命令确定合适的引擎类型，避免出现基于规则的第一策略失效，无法确定合适的引擎类型的情况。
在本实施例中，可选的，所述总执行代价可以具体通过以下方式计算：
确定所述每个子查询命令在不同的引擎下执行时，对应的执行代价的类型；
根据所述执行代价的类型分别确定对应的目标执行代价；
汇总所有目标执行代价，得到所述总执行代价。
具体的，总执行代价可以表示为所有影响查询时间的因素，即查询代价的总和。通常在分布式环境下影响查询时间的因素主要有CPU时间、I/O时间、网络传输时间三种，因此，先确定每个子查询命令在不同的引擎下执行时，对应的执行代价的类型，该类型可以包括CPU代价、I/O代价和网络传输代价，然后根据执行代价的类型分别确定对应的目标执行代价，最后汇总所有目标执行代价，就得到了总执行代价。
示例性的，上述总执行代价计算过程可以通过下式表示：
Cost＝WCPU×Ninst+WI/O×NI/O+WMSG×Nmsg+WTR×Nbyte (1)
其中，公式(1)的前两项是用来计算查询在本地的操作代价，Cost为总执行代价，WCPU是执行一条指令的CPU权重，Ninst是所有指令的总数，WI/O是进行一次磁盘I/O操作的权重，NI/O是所有磁盘I/O的操作总数。公式的后两项是计算两个站点之间传输数据的网络开销，WMSG是指发送和接收一条消息的权重，Nmsg是指发送和接收的消息总数，WTR是指网络传输的权重，Nbyte是指通过网络传输的字节总数，根据具体情况也可以简化为数据包或者其他单位。
本实施例中，上述总执行代价计算方式充分考虑了各种影响查询时间的因素，更为准确。
在本实施例中，可选的，总执行代价可以通过以下几种代价模型中的任一种进行计算，代价模型可以包括：过滤(Filter)算子的代价估算模型、投影(Project)算子的代价估算模型、扫描投影(Scan-Project)算子的代价估算模型、扫描过滤投影(Scan-Filter-Project)算子的代价估算模型和交换(Exchange)算子的代价估算模型。
以下对上述代价模型进行描述：
1、Filter算子的代价估算模型
Filter算子是用于对数据进行筛选的算子，可以在各种类型的查询引擎中执行，Filter操作主要是CPU密集型操作，因为其操作的数据都在内存中没有磁盘加载的I/O代价和网络通信代价。对于一个元组的Filter操作通常会包含一个或多个筛选条件，为了简化计算认为每个元组都需要执行所有的Filter计算，同时各种引擎对Filter操作的实现都是类似的，Filter算子的代价估算模型可以通过下式表示：
CostFilter＝CostCPU＝WCPU×|R|×Sum(#predicates) (2)
其中，CostFilter为Filter算子的总执行代价，CostCPU为CPU总代价，|R|为进行查询的某个表R中的元组总数，Sum(#predicates)为Filter算子中谓词条件的总数。
2、Project算子的代价估算模型
Project是一种投影操作，提取出每行数据的部分列再组成新的表。Project算子没有网络传输和磁盘I/O的代价。对于行式存储的引擎需要将一行数据读入内存再进行一次投影操作选择出所需要的表，而列式查询引擎对于同一行的数据并不会连续存储，所以投影操作需要多次CPU计算找到投影列，Project算子的代价估算模型可以通过下式表示，其中，公式(3)适用于KV引擎，公式(4)适用于其他引擎。
CostProject＝CostCPU＝WCPU×|R|×Sum(#projects) (3)
CostProject＝CostCPU＝WCPU×|R| (4)
其中，CostProject为Project算子的总执行代价，Sum(#projects)为Project算子中投影列的总数。
3、Scan-Project算子的代价估算模型
由于KV引擎是按照列为单位进行数据存储，所以其对一行数据进行投影时不需要将其他无关列加载进内存，这种特性可以大量减少磁盘I/O的代价。KV引擎在完成扫描-投影这种连续操作时可以仅加载投影的列，而其他行存储的引擎需要加载全部列再进行投影。扫描-投影这种组合操作中要同时考虑磁盘I/O代价和CPU代价，在考虑磁盘I/O传输代价时可以认为一行中每列的数据类型大小都相等，并以行为单位计算I/O代价，Scan-Project算子的代价估算模型可以通过下式表示，其中，公式(5)适用于KV引擎，公式(6)适用于其他引擎。
Figure BDA0003314765110000161
CostS-P＝CostI/O+CostCPU＝WI/O×|R|+WCPU×|R| (6)
其中，CostS-P为Scan-Projec算子的总执行代价，CostI/O为磁盘I/O传输总代价，Sum(#columns)为一行中所有列的总数。
4、Scan-Filter-Project算子的代价估算模型
对Scan-Filter-Project算子而言，KV引擎可以仅扫描Filter算子和Project算子涉及到的列而忽略其他无关列，通过这样的方式KV引擎在进行读取数据时可以减少磁盘I/O代价。Scan-Filter-Project算子的代价估算模型可以通过下式表示，其中，公式(7)适用于KV引擎，公式(8)适用于其他引擎。
Figure BDA0003314765110000162
Figure BDA0003314765110000163
其中，CostS-F-P为Scan-Filter-Project算子的总执行代价，Sum(#predicates)为Filter算子中谓词条件的总数。
5、Exchange算子的代价估算模型
在分布式系统下，一个目标查询命令分解成为的多个子查询命令是可能运行在不同的引擎中的，执行结果通过网络传输的方式发送到其他引擎节点上，为了在逻辑查询计划中表示这种分布在不同引擎上查询的关系，使用单独的Exchange算子来表示有上下游关系的子查询之间的数据交换。如果Exchange算子连接的两个查询是在不同站点执行的，Exchange算子就会产生中间结果网络传输的代价；如果Exchange算子连接的两个查询是在同一个站点，就忽略Exchange算子产生的本地传输数据代价。网络传输代价应该与传输的数据大小有关，在这里认为数据大小和数据的行数存在线性关系，即使用一个关系的行数来计算网络传输代价。Exchange算子的代价估算模型可以通过下式表示。
CostEX＝Costnetwork＝WNET×|R| (9)
其中，CostEX为Exchange算子的总执行代价，Costnetwork为网络传输总代价，WNET为传输一个元组的代价。
本实施例中，通过上述代价模型计算出的总执行代价更符合实际情况，也更准确。
图2A是本公开实施例提供的另一种数据查询方法的流程示意图。本实施例是在上述实施例的基础上进行优化。可选的，本实施例对将目标查询命令分解为多个子查询命令的过程进行详细的解释说明。如图2A所示，该方法具体包括如下：
S210，获取目标查询命令，将目标查询命令输入至所述分解算法中。
在进行数据查询的过程中，需要获取目标查询命令，在获取到目标查询命令后，为了更高效的进行查询，需要将目标查询命令进行分解，具体分解过程可以通过相应的分解算法实现，在进行分解时，要将目标查询命令输入至分解算法中，以便后续通过分解算法把目标查询命令进行分解，得到对应的子查询命令。
S220，通过对分解算法中的所有算子进行拓扑排序，得到对应的拓扑排序结果。
其中，拓扑排序可以理解为对有向图的顶点进行排序的过程。
分解算法中包括了多个算子，这些算子都与查询分解有关，例如扫描(Scan)算子和输出(Output)算子，在算子较多的情况下，为了避免分解过程中出错，需要对所有的算子根据上下游依赖关系进行拓扑排序，从而得到对应的拓扑排序结果，即：每个算子在分解算法中与其他算子的连接关系。
S230，根据拓扑排序结果，对所有算子进行模式匹配，得到对应的模式匹配结果。
其中，模式匹配为数据结构中字符串的一种基本运算，其目的是给定一个子串，在某个字符串中查找出与该子串相同的所有子串，具体查找时可以按照预设匹配规则进行查找。预设匹配规则可以是预先设定好的。
在得到拓扑排序结果之后，根据算子的拓扑排序结果，对所有算子按照预设匹配规则进行匹配，能够得到各算子对应的模式匹配结果。
S240，根据模式匹配结果确定目标查询命令分解后对应的子查询命令。
在得到模式匹配结果之后，由于模式匹配结果中包含了各算子是否满足预设匹配规则，因此根据模式匹配结果能够将目标查询命令分解为多个子查询命令，从而得到目标查询命令分解后对应的子查询命令。
S250，根据预设策略对每个子查询命令进行处理，确定对应的逻辑查询计划。
S260，对逻辑查询计划进行物理优化，得到每个子查询命令对应的目标引擎，以使目标引擎执行对应的子查询命令，得到执行结果。
S270，接收目标引擎发送的执行结果。
在本实施例中，首先获取目标查询命令，将目标查询命令输入至所述分解算法中，通过对分解算法中的所有算子进行拓扑排序，得到对应的拓扑排序结果，接着根据拓扑排序结果，对所有算子进行模式匹配，得到对应的模式匹配结果，然后根据模式匹配结果确定目标查询命令分解后对应的子查询命令，根据预设策略对每个子查询命令进行处理，确定对应的逻辑查询计划，最后对逻辑查询计划进行物理优化，得到每个子查询命令对应的目标引擎，以使目标引擎执行对应的子查询命令，得到执行结果，接收目标引擎发送的执行结果，上述方案中，通过将目标查询命令输入至分解算法中进行分解，得到对应的子查询命令，能够提高后续查询效率，便于根据每个子查询特点确定合适的目标引擎来进行查询，从而能够进行高效的数据查询，避免出现查询失败的情况。
在本实施例中，可选的，所述根据所述模式匹配结果确定所述目标查询命令分解后对应的子查询命令，可以具体包括：
若所述模式匹配结果为目标算子与对应的上游算子满足匹配规则，则将所述上游算子对应的子查询命令作为所述目标算子对应的子查询命令，其中，所述目标算子为所有算子中的任一算子；
若所述模式匹配结果为所述目标算子与对应的上游算子不满足匹配规则，则为所述目标算子新建子查询命令；
遍历所有算子，得到所述目标查询命令分解后对应的子查询命令。
其中，匹配规则可以为判断任一算子的支持站点和其上游算子的候选站点是否有交集。还可以是其他设置好的规则，本实施例不做限制。
具体的，模式匹配结果中分为目标算子与对应的上游算子满足匹配规则和目标算子与对应的上游算子不满足匹配规则，若模式匹配结果为目标算子与对应的上游算子满足匹配规则，即：将上游算子对应的子查询命令作为目标算子对应的子查询命令，即：目标算子的支持站点和其上游算子的候选站点有交集，则将目标算子加入上游算子的子查询命令中；若模式匹配结果为目标算子与对应的上游算子不满足匹配规则，即：目标算子的支持站点和其上游算子的候选站点没有交集，此时就为目标算子新建一个子查询命令，遍历所有算子之后，就能够得到目标查询命令分解后对应的子查询命令。
本实施例中，通过上述方法得到目标查询命令分解后对应的子查询命令，更为准确，有利于提高后续查询效率以及提升用户的使用体验。
示例性的，图2B是本公开实施例中分解算法的结构示意图，如图2B所示：该方法具体包括如下：
S2001，开始。
S2002，初始化算子。
在分解算法开始运行前，首先要对所有的算子进行初始化，主要是将所有算子和分解有关的属性设置为初始值。
S2003，算子拓扑排序。
S2004，按拓扑顺序检查每个算子。
S2005，目标算子的上游算子是否超过预设个数。
其中，预设个数可以预先设定，也可以根据实际情况确定，本实施例不做限制。
若是，执行S2006；若否，执行S2009。
S2006，目标算子的支持站点与上游算子的候选站点是否有交集。
若是，执行S2008；若否，执行S2007。
S2007，新建子查询命令。之后，执行S2011。
如果目标算子的上游算子超过预设个数，且目标算子的支持站点与上游算子的候选站点没有交集，则需要为目标算子新建子查询命令。
S2008，加入上游算子的子查询命令并合并所有上游子查询命令。之后，执行S2011。
如果目标算子的上游算子超过预设个数，且目标算子的支持站点与上游算子的候选站点有交集，则需要将目标算子加入上游算子的子查询命令并合并所有上游子查询命令，形成一个大的子查询命令。
S2009，目标算子的支持站点与上游算子的候选站点是否有交集。
若是，执行S2010；若否，执行S2007。
S2010，加入上游算子的子查询命令。之后，执行S2011。
如果目标算子的上游算子不超过预设个数，且目标算子的支持站点与上游算子的候选站点有交集，则需要将目标算子加入上游算子的子查询命令。
S2011，是否遍历完所有算子。
若是，执行S2012；若否，执行S2005。
S2012，结束。
需要说明的是，上述步骤的编号主要是为了对分解算法进行说明，不用于对具体的实施顺序进行限定。
在本实施例中，可选的，所述获取目标查询命令，可以具体包括：
获取用户输入的初始查询命令，并对所述初始查询命令进行解析，生成语法树；
对所述语法树进行语义分析，得到所述语义分析的结果；
若所述结果为通过，则对所述语法树进行逻辑优化，得到所述目标查询命令。
具体的，获取用户输入的初始查询命令，该初始查询命令可以为SQL语言，也可以为其他语言，由于初始查询命令无法直接进行识别，因此还需要对初始查询命令进行解析，具体可以通过词法和语法分析方法对初始查询命令进行解析，从而生成语法树。在得到语法树之后，还要对语法树进行语义分析，主要是对语法树中源程序进行上下文有关性质的审查以及类型审查，从而确定语义分析是否通过，得到语义分析的结果。若结果为通过，则再对语法树进行逻辑优化，即代码结构优化，最终得到目标查询命令；若结果为不通过，则需要提示用户重新输入正确的初始查询命令。
本实施例中，通过对初始查询命令进行分析，得到目标查询命令，提供了一种多模型数据统一查询访问方法，用户使用一种语言就能够对多模型数据进行统一访问，能够提高用户的使用体验和便捷性。
图3是本公开实施例提供的一种数据查询装置的结构示意图；该装置配置于计算机设备中，可实现本申请任意实施例所述的数据查询方法。该装置具体包括如下：
分解模块310，用于获取目标查询命令，并根据分解算法将所述目标查询命令分解为多个子查询命令；
确定模块320，用于根据预设策略对每个子查询命令进行处理，确定对应的逻辑查询计划；
优化模块330，用于对所述逻辑查询计划进行物理优化，得到每个子查询命令对应的目标引擎，以使所述目标引擎执行对应的子查询命令，得到执行结果；
接收模块340，用于接收所述目标引擎发送的所述执行结果。
在本实施例中，可选的，所述预设策略包括基于规则的第一策略；
相应的，确定模块，具体用于：
获取所述第一策略中包括的查询规则；
获取所述每个子查询命令对应的操作对象以及操作类型；
根据所述操作对象以及所述操作类型，确定所述查询规则中是否包含与所述每个子查询命令相匹配的目标规则；
若包含，则根据所述目标规则确定对应的逻辑查询计划。
在本实施例中，可选的，所述预设策略包括基于代价的第二策略；
相应的，确定模块，具体用于：
根据所述基于代价的第二策略，确定所述每个子查询命令在不同的引擎下执行时，所花费的总执行代价；
将所有总执行代价中总执行代价最小时对应的目标引擎作为所述对应的逻辑查询计划。
在本实施例中，可选的，所述总执行代价通过以下方式计算：
确定所述每个子查询命令在不同的引擎下执行时，对应的执行代价的类型；
根据所述执行代价的类型分别确定对应的目标执行代价；
汇总所有目标执行代价，得到所述总执行代价。
在本实施例中，可选的，分解模块，包括：
获取单元，用于获取目标查询命令；
分解单元，用于根据分解算法将所述目标查询命令分解为多个子查询命令；
相应的，分解单元，包括：
输入子单元，用于获取目标查询命令，将所述目标查询命令输入至所述分解算法中；
排序结果获取子单元，用于通过对所述分解算法中的所有算子进行拓扑排序，得到对应的拓扑排序结果；
匹配结果获取子单元，用于根据所述拓扑排序结果，对所有算子进行模式匹配，得到对应的模式匹配结果；
命令确定子单元，用于根据所述模式匹配结果确定所述目标查询命令分解后对应的子查询命令。
在本实施例中，可选的，命令确定子单元，具体用于：
若所述模式匹配结果为目标算子与对应的上游算子满足匹配规则，则将所述上游算子对应的子查询命令作为所述目标算子对应的子查询命令，其中，所述目标算子为所有算子中的任一算子；
若所述模式匹配结果为所述目标算子与对应的上游算子不满足匹配规则，则为所述目标算子新建子查询命令；
遍历所有算子，得到所述目标查询命令分解后对应的子查询命令。
在本实施例中，可选的，获取单元，具体用于：
获取用户输入的初始查询命令，并对所述初始查询命令进行解析，生成语法树；
对所述语法树进行语义分析，得到所述语义分析的结果；
若所述结果为通过，则对所述语法树进行逻辑优化，得到所述目标查询命令。
通过本公开实施例提供的数据查询装置，首先获取目标查询命令，并根据分解算法将目标查询命令分解为多个子查询命令，接着根据预设策略对每个子查询命令进行处理，确定对应的逻辑查询计划，然后对逻辑查询计划进行物理优化，得到每个子查询命令对应的目标引擎，以使目标引擎执行对应的子查询命令，得到执行结果，最后接收目标引擎发送的执行结果，通过对目标查询命令进行分解，为每个子查询命令确定合适的目标引擎，能够进行高效的数据查询，避免出现查询失败的情况。
本公开实施例所提供的数据查询装置可执行本公开任意实施例所提供的数据查询方法，具备执行方法相应的功能模块和有益效果。
图4是本公开实施例提供的一种计算机设备的结构示意图。如图4所示，该计算机设备包括处理器410和存储装置420；计算机设备中处理器410的数量可以是一个或多个，图4中以一个处理器410为例；计算机设备中的处理器410和存储装置420可以通过总线或其他方式连接，图4中以通过总线连接为例。
存储装置420作为一种计算机可读存储介质，可用于存储软件程序、计算机可执行程序以及模块，如本公开实施例中的数据查询方法对应的程序指令/模块。处理器410通过运行存储在存储装置420中的软件程序、指令以及模块，从而执行计算机设备的各种功能应用以及数据处理，即实现本公开实施例所提供的数据查询方法。
存储装置420可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序；存储数据区可存储根据终端的使用所创建的数据等。此外，存储装置420可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实例中，存储装置420可进一步包括相对于处理器410远程设置的存储器，这些远程存储器可以通过网络连接至计算机设备。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
本实施例提供的一种计算机设备可用于执行上述任意实施例提供的数据查询方法，具备相应的功能和有益效果。
本公开实施例还提供了一种包含计算机可执行指令的存储介质，所述计算机可执行指令在由计算机处理器执行时用于实现本公开实施例所提供的数据查询方法。
当然，本公开实施例所提供的一种包含计算机可执行指令的存储介质，其计算机可执行指令不限于如上所述的方法操作，还可以执行本公开任意实施例所提供的数据查询方法中的相关操作。
通过以上关于实施方式的描述，所属领域的技术人员可以清楚地了解到，本公开可借助软件及必需的通用硬件来实现，当然也可以通过硬件实现，但很多情况下前者是更佳的实施方式。基于这样的理解，本公开的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如计算机的软盘、只读存储器(Read-Only Memory,ROM)、随机存取存储器(RandomAccess Memory,RAM)、闪存(FLASH)、硬盘或光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本公开各个实施例所述的方法。
值得注意的是，上述数据查询装置的实施例中，所包括的各个单元和模块只是按照功能逻辑进行划分的，但并不局限于上述的划分，只要能够实现相应的功能即可；另外，各功能单元的具体名称也只是为了便于相互区分，并不用于限制本公开的保护范围。
需要说明的是，在本文中，诸如“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
以上所述仅是本公开的具体实施方式，使本领域技术人员能够理解或实现本公开。对这些实施例的多种修改对本领域的技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本公开的精神或范围的情况下，在其它实施例中实现。因此，本公开将不会被限制于本文所述的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (10)

1.一种数据查询方法，其特征在于，所述方法包括：
获取目标查询命令，并根据分解算法将所述目标查询命令分解为多个子查询命令；
根据预设策略对每个子查询命令进行处理，确定对应的逻辑查询计划；
对所述逻辑查询计划进行物理优化，得到每个子查询命令对应的目标引擎，以使所述目标引擎执行对应的子查询命令，得到执行结果；
接收所述目标引擎发送的所述执行结果。
2.根据权利要求1所述的方法，其特征在于，所述预设策略包括基于规则的第一策略；
相应的，所述根据预设策略对每个子查询命令进行处理，确定对应的逻辑查询计划，包括：
获取所述第一策略中包括的查询规则；
获取所述每个子查询命令对应的操作对象以及操作类型；
根据所述操作对象以及所述操作类型，确定所述查询规则中是否包含与所述每个子查询命令相匹配的目标规则；
若包含，则根据所述目标规则确定对应的逻辑查询计划。
3.根据权利要求1所述的方法，其特征在于，所述预设策略包括基于代价的第二策略；
相应的，所述根据预设策略对每个子查询命令进行处理，确定对应的逻辑查询计划，包括：
根据所述基于代价的第二策略，确定所述每个子查询命令在不同的引擎下执行时，所花费的总执行代价；
将所有总执行代价中总执行代价最小时对应的目标引擎作为所述对应的逻辑查询计划。
4.根据权利要求3所述的方法，其特征在于，所述总执行代价通过以下方式计算：
确定所述每个子查询命令在不同的引擎下执行时，对应的执行代价的类型；
根据所述执行代价的类型分别确定对应的目标执行代价；
汇总所有目标执行代价，得到所述总执行代价。
5.根据权利要求1所述的方法，其特征在于，所述根据分解算法将所述目标查询命令分解为多个子查询命令，包括：
将所述目标查询命令输入至所述分解算法中；
通过对所述分解算法中的所有算子进行拓扑排序，得到对应的拓扑排序结果；
根据所述拓扑排序结果，对所有算子进行模式匹配，得到对应的模式匹配结果；
根据所述模式匹配结果确定所述目标查询命令分解后对应的子查询命令。
6.根据权利要求5所述的方法，其特征在于，所述根据所述模式匹配结果确定所述目标查询命令分解后对应的子查询命令，包括：
若所述模式匹配结果为目标算子与对应的上游算子满足匹配规则，则将所述上游算子对应的子查询命令作为所述目标算子对应的子查询命令，其中，所述目标算子为所有算子中的任一算子；
若所述模式匹配结果为所述目标算子与对应的上游算子不满足匹配规则，则为所述目标算子新建子查询命令；
遍历所有算子，得到所述目标查询命令分解后对应的子查询命令。
7.根据权利要求1-6任一项所述的方法，其特征在于，所述获取目标查询命令，包括：
获取用户输入的初始查询命令，并对所述初始查询命令进行解析，生成语法树；
对所述语法树进行语义分析，得到所述语义分析的结果；
若所述结果为通过，则对所述语法树进行逻辑优化，得到所述目标查询命令。
8.一种数据查询装置，其特征在于，所述装置包括：
分解模块，用于获取目标查询命令，并根据分解算法将所述目标查询命令分解为多个子查询命令；
确定模块，用于根据预设策略对每个子查询命令进行处理，确定对应的逻辑查询计划；
优化模块，用于对所述逻辑查询计划进行物理优化，得到每个子查询命令对应的目标引擎，以使所述目标引擎执行对应的子查询命令，得到执行结果；
接收模块，用于接收所述目标引擎发送的所述执行结果。
9.一种计算机设备，其特征在于，包括：
一个或多个处理器；
存储装置，用于存储一个或多个程序，
当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如权利要求1-7中任一所述的方法。
10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行时实现如权利要求1-7中任一所述的方法。
CN202111227659.7A 2021-10-21 2021-10-21 数据查询方法、装置、计算机设备和介质 Pending CN113946600A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202111227659.7A CN113946600A (zh) 2021-10-21 2021-10-21 数据查询方法、装置、计算机设备和介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202111227659.7A CN113946600A (zh) 2021-10-21 2021-10-21 数据查询方法、装置、计算机设备和介质

Publications (1)

Publication Number Publication Date
CN113946600A true CN113946600A (zh) 2022-01-18

Family

ID=79331880

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202111227659.7A Pending CN113946600A (zh) 2021-10-21 2021-10-21 数据查询方法、装置、计算机设备和介质

Country Status (1)

Country Link
CN (1) CN113946600A (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114372081A (zh) * 2022-03-22 2022-04-19 广州思迈特软件有限公司 数据准备方法、装置和设备
CN115328541A (zh) * 2022-07-04 2022-11-11 北京中科思创云智能科技有限公司 不同框架下模型转换方法和装置、设备及存储介质

Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090271385A1 (en) * 2008-04-28 2009-10-29 Infosys Technologies Limited System and method for parallel query evaluation
US20110040749A1 (en) * 2009-08-13 2011-02-17 Politecnico Di Milano Method for extracting, merging and ranking search engine results
CN103324724A (zh) * 2013-06-26 2013-09-25 华为技术有限公司 数据处理方法及装置
CN105210058A (zh) * 2012-12-14 2015-12-30 微软技术许可有限责任公司 使用多个引擎来进行图查询处理
CN105824957A (zh) * 2016-03-30 2016-08-03 电子科技大学 分布式内存列式数据库的查询引擎系统及查询方法
US20170124151A1 (en) * 2015-11-03 2017-05-04 Sap Se Optimization of continuous queries in hybrid database and stream processing systems
CN107402926A (zh) * 2016-05-18 2017-11-28 华为技术有限公司 一种查询方法以及查询设备
CN110008244A (zh) * 2019-03-29 2019-07-12 国家计算机网络与信息安全管理中心 一种数据查询方法及数据查询装置
CN110059103A (zh) * 2019-04-28 2019-07-26 南京大学 一种跨平台统一的大数据sql查询方法
CN110825738A (zh) * 2019-10-22 2020-02-21 天津大学 一种基于分布式rdf的数据存储、查询方法及装置

Patent Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090271385A1 (en) * 2008-04-28 2009-10-29 Infosys Technologies Limited System and method for parallel query evaluation
US20110040749A1 (en) * 2009-08-13 2011-02-17 Politecnico Di Milano Method for extracting, merging and ranking search engine results
CN105210058A (zh) * 2012-12-14 2015-12-30 微软技术许可有限责任公司 使用多个引擎来进行图查询处理
CN103324724A (zh) * 2013-06-26 2013-09-25 华为技术有限公司 数据处理方法及装置
US20170124151A1 (en) * 2015-11-03 2017-05-04 Sap Se Optimization of continuous queries in hybrid database and stream processing systems
CN105824957A (zh) * 2016-03-30 2016-08-03 电子科技大学 分布式内存列式数据库的查询引擎系统及查询方法
CN107402926A (zh) * 2016-05-18 2017-11-28 华为技术有限公司 一种查询方法以及查询设备
CN110008244A (zh) * 2019-03-29 2019-07-12 国家计算机网络与信息安全管理中心 一种数据查询方法及数据查询装置
CN110059103A (zh) * 2019-04-28 2019-07-26 南京大学 一种跨平台统一的大数据sql查询方法
CN110825738A (zh) * 2019-10-22 2020-02-21 天津大学 一种基于分布式rdf的数据存储、查询方法及装置

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
徐晶;刘梦赤;: "基于信息网模型的分布并行多连接查询优化", 计算机应用与软件, no. 07, 15 July 2017 (2017-07-15), pages 73 - 80 *
陈荣鑫;: "结合重写与数据并行的XQuery查询优化", 陕西科技大学学报(自然科学版), no. 06, 25 December 2011 (2011-12-25), pages 78 - 82 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114372081A (zh) * 2022-03-22 2022-04-19 广州思迈特软件有限公司 数据准备方法、装置和设备
CN115328541A (zh) * 2022-07-04 2022-11-11 北京中科思创云智能科技有限公司 不同框架下模型转换方法和装置、设备及存储介质

Similar Documents

Publication Publication Date Title
Wylot et al. RDF data storage and query processing schemes: A survey
Freitag et al. Adopting worst-case optimal joins in relational database systems
Umbrich et al. Comparing data summaries for processing live queries over linked data
US5873079A (en) Filtered index apparatus and method
US5884304A (en) Alternate key index query apparatus and method
Hristidis et al. Discover: Keyword search in relational databases
US6167393A (en) Heterogeneous record search apparatus and method
US5870739A (en) Hybrid query apparatus and method
US20100299367A1 (en) Keyword Searching On Database Views
Meimaris et al. Extended characteristic sets: graph indexing for SPARQL query optimization
Song et al. Efficient discovery of similarity constraints for matching dependencies
Luo et al. Storing and indexing massive RDF datasets
Ciaccia et al. Processing complex similarity queries with distance-based access methods
CN113946600A (zh) 数据查询方法、装置、计算机设备和介质
Kim et al. Similarity query support in big data management systems
CN113553339A (zh) 数据查询方法、中间件、电子装置和存储介质
Ladwig et al. Index structures and top-k join algorithms for native keyword search databases
Fan et al. Linking entities across relations and graphs
Cappellari et al. A path-oriented rdf index for keyword search query processing
Álvarez-García et al. Compact and efficient representation of general graph databases
Minato et al. Frequent pattern mining and knowledge indexing based on zero-suppressed BDDs
CN108804580B (zh) 一种在联邦型rdf数据库中查询关键字的方法
Guo et al. Distributed processing of regular path queries in RDF graphs
Ghanbarpour et al. Efficient keyword search over graph-structured data based on minimal covered r-cliques
Krátký et al. Multidimensional term indexing for efficient processing of complex queries

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