异构图数据库的数据查询方法及其系统与流程

本说明书涉及数据库技术领域。

背景技术：

传统数据库很难处理关系运算(如社交、电商、金融、零售、物联网等行业)，于是图数据库应运而生，它是一种支持海量复杂数据关系运算的数据库。目前图数据库的发展正处于方兴未艾的阶段，已经出现了形形色色的图数据库，如neo4j、janusgraph、amazonneptune等，甚至还有通过关系型数据库来模拟图数据库的应用场景。在实际使用图数据时，可能会有跨图查询的场景(图数据可能存储在上面提及的不同的存储引擎中)，这就给获取图数据带来了困难。譬如，如果需要从商家图、用户图、商品图三个子图中获取用户的消费习惯，则需要同时请求这三个子图中的数据，然后处理不同的结果，然后进行结果合并。

可见，现有技术中，开发人员在开发图数据应用时，如果需要跨子图或跨引擎请求数据，则需要熟悉不同子图的定义和不同图执行引擎的细节，同时手动合并各个子图的数据。而图数据的获取过程非常繁琐，图数据的质量也不高。

技术实现要素：

本说明书提供了一种异构图数据库的数据查询方法及其系统，用户无需感知各个子图的细节，可以屏蔽异构图数据库的复杂度，返回统一的图数据查询结果。

本申请公开了一种异构图数据库的数据查询方法，包括：

预先设置统一视图中元数据与异构图数据库的多个子图中元数据之间的关联关系；

获取符合所述统一视图中元数据的统一查询请求，根据所述关联关系将所述统一查询请求分解为对应不同子图的多个子查询；

在所述多个子查询所对应的多个子图中分别执行所述多个子查询，得到多个子查询结果，其中所述子查询和子查询结果符合对应子图中元数据；

根据所述关联关系将所述多个子查询结果进行合并，得到符合所述统一视图中元数据的查询结果。

在一个优选例中，该方法还包括，预先设置所述多个子图中数据结构到统一图数据结构的适配规则；

所述根据所述关联关系将所述多个子查询结果进行合并之前，还包括：

根据所述适配规则将所述多个子查询结果转换为符合所述统一视图中元数据的统一图数据结构。

在一个优选例中，所述在所述多个子查询所对应的多个子图中分别执行所述多个子查询，进一步包括：

将不同的子查询分别路由到不同的执行引擎中执行查询操作。

在一个优选例中，所述执行引擎包括以下之一或其任意组合：

一个或多个图引擎，一个或多个关系数据库引擎，一个或多个图引擎之外的非关系数据库引擎。

在一个优选例中，所述元数据包括以下之一或其任意组合：图基础信息、点定义、边定义、属性定义。

在一个优选例中，所述根据所述关联关系将所述统一查询请求分解为对应不同子图的多个子查询，进一步包括：

通过对所述统一查询请求的语法分析和词法分析，得到该统一查询请求涉及的所述统一视图中的元数据；

根据所述关联关系得到所述统一视图中的元数据对应的各个子图中的元数据；

根据所述统一查询请求和所述各个子图中的元数据，构造用于各个子图的子查询。

在一个优选例中，所述根据所述关联关系将所述多个子查询结果进行合并，进一步包括：

对第一子查询结果中的各个节点进行遍历，如果遍历到的第一节点根据所述关联关系存在关联节点，则对该关联节点所在的第二子查询结果进行遍历；

如果所述第二子查询结果中遍历到的第二节点的类型与所述第一节点的类型相同，则进一步判断所述第一节点和所述第二节点中相应的属性是否相等，如果相等则将所述第一节点和所述第二节点融合。

在一个优选例中，所述将所述第一节点和所述第二节点融合，进一步包括：

将所述第二节点的出入边链接到所述第一节点；

将所述第二节点的属性信息添加到所述第一节点的属性中。

在一个优选例中，所述根据所述关联关系将所述多个子查询结果进行合并，进一步包括：

对第三子查询结果中的各个节点进行遍历，如果遍历到的第三节点根据所述关联关系存在关联节点，则对该关联节点所在的第四子查询结果进行遍历；

如果所述第四子查询结果中遍历到的第四节点的类型与所述第三节点的类型相同，则进一步判断所述第三节点和所述第四节点中相应的属性是否相等，如果相等则在所述第三节点和所述第四节点之间构造一条对等边。

本申请还公开了一种异构图数据库的数据查询系统包括：

元数据中心，其中存储有统一视图中元数据与异构图数据库的多个子图中元数据之间的关联关系；

解析路由层，用于根据所述关联关系将符合所述统一视图中元数据的统一查询请求分解为对应不同子图的多个子查询，其中所述子查询符合对应子图中元数据；；

引擎执行层，用于在所述多个子查询所对应的多个子图中分别执行所述多个子查询，得到多个子查询结果，其中所述子查询结果符合对应子图中元数据；

数据组装层，用于根据所述关联关系将所述多个子查询结果进行合并，得到符合所述统一视图中元数据的查询结果。

在一个优选例中，所述元数据中心还存储有所述多个子图中数据结构到统一图数据结构的适配规则；

所述系统还包括数据适配层，用于根据所述适配规则将所述引擎执行层输出的多个子查询结果转换为符合所述统一视图中元数据的统一图数据结构，供所述数据组装层使用。

在一个优选例中，所述解析路由层将不同的子查询分别路由到所述引擎执行层的不同的执行引擎中执行查询操作。

在一个优选例中，所述执行引擎包括以下之一或其任意组合：

一个或多个图引擎，一个或多个关系数据库引擎，一个或多个图引擎之外的非关系数据库引擎。

在一个优选例中，所述元数据包括以下之一或其任意组合：图基础信息、点定义、边定义、属性定义。

在一个优选例中，所述解析路由层通过以下方式构造子查询：

通过对所述统一查询请求的语法分析和词法分析，得到该统一查询请求涉及的所述统一视图中的元数据；

根据所述关联关系得到所述统一视图中的元数据对应的各个子图中的元数据；

根据所述统一查询请求和所述各个子图中的元数据，构造用于各个子图的子查询。

在一个优选例中，所述数据组装层通过以下方式将所述多个子查询结果进行合并：

对第一子查询结果中的各个节点进行遍历，如果遍历到的第一节点根据所述关联关系存在关联节点，则对该关联节点所在的第二子查询结果进行遍历；

如果所述第二子查询结果中遍历到的第二节点的类型与所述第一节点的类型相同，则进一步判断所述第一节点和所述第二节点中相应的属性是否相等，如果相等则将所述第一节点和所述第二节点融合。

在一个优选例中，所述将所述第一节点和所述第二节点融合，进一步包括：

将所述第二节点的出入边链接到所述第一节点；

将所述第二节点的属性信息添加到所述第一节点的属性中。

在一个优选例中，所述数据组装层通过以下方式将所述多个子查询结果进行合并：

对第三子查询结果中的各个节点进行遍历，如果遍历到的第三节点根据所述关联关系存在关联节点，则对该关联节点所在的第四子查询结果进行遍历；

如果所述第四子查询结果中遍历到的第四节点的类型与所述第三节点的类型相同，则进一步判断所述第三节点和所述第四节点中相应的属性是否相等，如果相等则在所述第三节点和所述第四节点之间构造一条对等边。

本申请还公开了一种异构图数据库的数据查询系统包括：

存储器，用于存储计算机可执行指令；以及，

处理器，与所述存储器耦合，用于在执行所述计算机可执行指令时实现如前文描述的方法中的步骤。

本申请还公开了一种计算机可读存储介质所述计算机可读存储介质中存储有计算机可执行指令，所述计算机可执行指令被处理器执行时实现如前文描述的方法中的步骤。

本说明书实施方式中，通过统一的图数据视图定义各个子图信息，在图数据视图基础上进行数据查询，屏蔽了异构图数据库的复杂度，返回统一的图数据查询结果，用户无需感知各个子图的细节，查询数据的过程更简单、快捷，降低了数据库开发成本，提升了开发效率。

利用关联关系通过点融合进行子图查询结果的合并，所得的结果与用户在统一视图上的查询完全匹配，用户完全感受不到异构图数据库的复杂度。

通过新建对等边进行子图查询结果的合并，可以高效率地实现合并，所需的数据操作最少。

本说明书中记载了大量的技术特征，分布在各个技术方案中，如果要罗列出本申请所有可能的技术特征的组合(即技术方案)的话，会使得说明书过于冗长。为了避免这个问题，本说明书上述发明内容中公开的各个技术特征、在下文各个实施方式和例子中公开的各技术特征、以及附图中公开的各个技术特征，都可以自由地互相组合，从而构成各种新的技术方案(这些技术方案均应该视为在本说明书中已经记载)，除非这种技术特征的组合在技术上是不可行的。例如，在一个例子中公开了特征a+b+c，在另一个例子中公开了特征a+b+d+e，而特征c和d是起到相同作用的等同技术手段，技术上只要择一使用即可，不可能同时采用，特征e技术上可以与特征c相组合，则，a+b+c+d的方案因技术不可行而应当不被视为已经记载，而a+b+c+e的方案应当视为已经被记载。

附图说明

图1是根据本说明书第一实施方式的异构图数据库的数据查询方法流程示意图；

图2是根据本说明书第二实施方式的异构图数据库的数据查询系统结构示意图；

图3是本说明书一个实施例中的异构图数据库的数据查询流程示意图；

图4是本说明书一个实施例中两张子图及其schema；

图5是本说明书一个实施例中融合节点合并子图的一个示例；

图6是本说明书一个实施例中建立对等边合并子图的一个示例。

具体实施方式

在以下的叙述中，为了使读者更好地理解本申请而提出了许多技术细节。但是，本领域的普通技术人员可以理解，即使没有这些技术细节和基于以下各实施方式的种种变化和修改，也可以实现本申请所要求保护的技术方案。

部分概念的说明：

schema：元数据，用于描述数据库对象的信息。

下面将结合附图对本说明书的实施方式作进一步地详细描述。

本说明书的第一实施方式涉及一种异构图数据库的数据查询方法，其流程如图1所示，该方法包括以下步骤：

在步骤102中，预先设置统一视图中元数据与异构图数据库的多个子图中元数据之间的关联关系。关联关系体现的是同一数据在子图和统一视图中关联关系。可选地，在一个实施例中，还可以预先设置多个子图中数据结构到统一图数据结构的适配规则。可选地，元数据包括以下之一或其任意组合：图基础信息、点定义、边定义、属性定义。

在步骤104中，获取符合统一视图中元数据的统一查询请求，根据关联关系将统一查询请求分解为对应不同子图的多个子查询。可选地，在一个实施例中，本步骤进一步包括：通过对统一查询请求的语法分析和词法分析，得到该统一查询请求涉及的统一视图中的元数据。根据关联关系得到统一视图中的元数据对应的各个子图中的元数据。根据统一查询请求和各个子图中的元数据，构造用于各个子图的子查询。

此后进入步骤106，在多个子查询所对应的多个子图中分别执行多个子查询，得到多个子查询结果，其中子查询和子查询结果符合对应子图中元数据。可选地，不同的子查询分别被路由到不同的执行引擎中执行查询操作。执行引擎可以是单一引擎，也可以是混合引擎。具体地说，执行引擎可以是一个或多个图引擎，或者一个或多个关系数据库引擎，或者一个或多个图引擎及一个或多个关系数据库引擎，或者一个或多个图引擎以及一个或多个除图引擎外其他的非关系数据库引擎，等等。各个独立的查询执行引擎应具备识别子查询分量、执行子查询分量、标识子查询分量结果的能力。

此后进入步骤108，根据适配规则将多个子查询结果转换为符合统一视图中元数据的统一图数据结构。本步骤是可选的。通过将子查询结果转换为符合统一视图中元数据的统一图数据结构，可以方便地进行后续的合并操作。

此后进入步骤110，根据关联关系将多个子查询结果进行合并，得到符合统一视图中元数据的查询结果。

步骤104-110是收到一个图查询请求时的处理，步骤102是预先的设置，步骤102并不需要在每一次收到图查询请求时操作。

通过建立不同子图之间的关联关系，定义统一的图数据视图，从而屏蔽底层图数据分布在不同子图、不同图存储引擎的细节，实现统一图数据查询的目的。

有多种方式可以实现步骤110中的子查询结果的合并。

在一个实施例中，采用点融合的方式。具体地说，步骤110进一步包括：对第一子查询结果(即多个子查询结果中的一个)中的各个节点进行遍历，如果遍历到的第一节点根据关联关系存在关联节点，则对该关联节点所在的第二子查询结果进行遍历。如果第二子查询结果中遍历到的第二节点的类型与第一节点的类型相同，则进一步判断第一节点和第二节点中相应的属性是否相等，如果相等则将第一节点和第二节点融合。其中，将第一节点和第二节点融合，进一步包括：将第二节点的出入边链接到第一节点(即关系融合)，以及将第二节点的属性信息添加到第一节点的属性中(即属性融合)。

在另一个实施例中，采用添加对等边的方式。具体地说，步骤110进一步包括：对第三子查询结果(即多个子查询结果中的一个)中的各个节点进行遍历，如果遍历到的第三节点根据关联关系存在关联节点，则对该关联节点所在的第四子查询结果进行遍历。如果第四子查询结果中遍历到的第四节点的类型与第三节点的类型相同，则进一步判断第三节点和第四节点中相应的属性是否相等，如果相等则在第三节点和第四节点之间构造一条对等边。

统一视图可以有不同的实现方式。例如，可以将所有子图中的各个元数据汇总在一起，对于不同子图中等同的元数据中只保留其中一个，然后在关联关系中设置被删除的元数据与被保留的元数据之间的对应关系。又如，可以完全独立的定义统一视图中的各个元数据，然后将统一视图中的元数据与各个子图中的元数据通过关联关系建立对应关系。

本说明书的第二实施方式涉及一种异构图数据库的数据查询系统，其结构如图2所示，该异构图数据库的数据查询系统包括：

元数据中心，其中存储有统一视图中元数据与异构图数据库的多个子图中元数据之间的关联关系。可选地，元数据包括以下之一或其任意组合：图基础信息、点定义、边定义、属性定义。可选地，元数据中心还存储有多个子图中数据结构到统一图数据结构的适配规则。

解析路由层，用于根据关联关系将符合统一视图中元数据的统一查询请求分解为对应不同子图的多个子查询，其中子查询符合对应子图中元数据。可选地，解析路由层将不同的子查询分别路由到引擎执行层的不同的执行引擎中执行查询操作。

引擎执行层，用于在多个子查询所对应的多个子图中分别执行多个子查询，得到多个子查询结果，其中子查询结果符合对应子图中元数据。可选地，执行引擎包括以下之一或其任意组合：一个或多个图引擎，一个或多个关系数据库引擎，一个或多个图引擎之外的非关系数据库引擎。

数据适配层，用于根据适配规则将引擎执行层输出的多个子查询结果转换为符合统一视图中元数据的统一图数据结构，供数据组装层使用。该数据适配层是可选的。

数据组装层，用于根据关联关系将多个子查询结果进行合并，得到符合统一视图中元数据的查询结果。

可选地，在一个实施例中，解析路由层通过以下方式构造子查询：通过对统一查询请求的语法分析和词法分析，得到该统一查询请求涉及的统一视图中的元数据。根据关联关系得到统一视图中的元数据对应的各个子图中的元数据。根据统一查询请求和各个子图中的元数据，构造用于各个子图的子查询。

数据组装层将多个子查询结果进行合并的方式有多种。

在一个实施例中，采用点融合的方式。具体地说，步骤110进一步包括：对第一子查询结果中的各个节点进行遍历，如果遍历到的第一节点根据关联关系存在关联节点，则对该关联节点所在的第二子查询结果进行遍历。如果第二子查询结果中遍历到的第二节点的类型与第一节点的类型相同，则进一步判断第一节点和第二节点中相应的属性是否相等，如果相等则将第一节点和第二节点融合。其中，将第一节点和第二节点融合，进一步包括：将第二节点的出入边链接到第一节点(即关系融合)，以及将第二节点的属性信息添加到第一节点的属性中(即属性融合)。

在另一个实施例中，采用添加对等边的方式。具体地说，步骤110进一步包括：对第三子查询结果中的各个节点进行遍历，如果遍历到的第三节点根据关联关系存在关联节点，则对该关联节点所在的第四子查询结果进行遍历。如果第四子查询结果中遍历到的第四节点的类型与第三节点的类型相同，则进一步判断第三节点和第四节点中相应的属性是否相等，如果相等则在第三节点和第四节点之间构造一条对等边。

第一实施方式是与本实施方式相对应的方法实施方式，第一实施方式中的技术细节可以应用于本实施方式，本实施方式中的技术细节也可以应用于第一实施方式。

为了能够更好地理解本说明书的技术方案，下面结合一个具体的例子来进行说明，该例子中罗列的细节主要是为了便于理解，不作为对本申请保护范围的限制。

图3示出了一个实施例中的异构图数据库的数据查询流程。

首先，用户通过图形化界面，发起图数据查询请求。请求中的图数据字段、过滤条件、返回结果，应满足统一的图数据视图(简称“统一视图”)中的schema(元数据)定义。

此后，解析路由层接受图查询请求后，根据查询请求，通过词法分析和语法分析，结合从元数据中心获取的schema关联关系(例如包括图数据schema定义)，将查询请求分解为多个子查询分量。根据子查询分量的类型，将不同的子查询分量路由到不同的执行引擎。执行引擎可以是单一引擎，也可以是混合引擎。

此后，执行引擎层中收到子查询分量的执行引擎分别在自身对应的子图中进行查询，输出各个子查询分量的查询结果。

此后，数据适配层接受各个子查询分量的查询结果，解析原始结果，并通过从元数据中心获取的schema适配规则，将原始请求结果转换为统一的图数据结构。

此后，数据组装层接受数据适配层输出的子查询适配结果，结合从元数据中心获取的schema关联关系，开始进行统一结果的组装。譬如将多个子图进行融合、重复点/重复点的去重、建立新的图关联关系等。最终返回统一的图查询结果。

下面对图3中各个模块进行说明。

元数据中心，用于统一的图视图管理，提供不同子图的schema定义、不同子图之间的关联关系、不同子图到统一结果层的适配规则等。

元数据中心存储统一图查询各个步骤中的配置信息。主要的配置信息有：

a)子图的schema信息，包括图基础信息、点/边定义、属性定义等；

b)子图返回结果转为标准schema的适配规则；

c)不同子图之间的关联关系。

为了帮助理解，图4示出了一个简化的例子，其中有两张子图grapha、graphb，图grapha包含两类节点person、card，一类边has_card；图graphb包含三类节点user、food、book，两类边like、has_read。子图的schema信息应该包括：节点类型、点属性信息、边的起始节点类型、边的目标节点类型、边类型等。has_card这条边的schema信息可以用json格式定义如下，其他的点/边schema定义与之类似。

本例中grapha中的person节点与graphb中的user节点是同一类节点，都表示“用户”，则可定义两张子图直接的关联关系为：

grapha.person＝graphb.user

grapha.person.name＝graphb.user.name

上面的关联关系的含义：若grapha中的某个person节点与graphb中的某个user节点的name属性的值相等，则这两个点可视为同一个节点。关联关系主要由类型映射和属性映射两部分组成，在上面的在例子里，为了简化，只定义了一个属性映射name，更多的映射属性也是可以的。定义这种关联关系后，意味着graha和graphb的拓扑结构进行了融合，形成了一张更大的网络拓扑结构，图数据的关系更加丰富。

各个子图之间通过定义各自之间的关联关系，形成统一的图数据视图(即统一视图)，用户的查询请求可以基于这张逻辑上的大视图展开。

解析路由层，用于通过语法分析、词法分析，结合元数据中心的配置信息(包括关联关系)，将统一查询语句解析为多个子查询分量，并将子查询分量路由到不同的图查询引擎中。例如，若通过语法分析后发现请求中涉及到person这个节点，则我们需要根据“元数据中心”中的配置信息，将请求分解为包含person和user两个子查询分量。对于原始图查询请求rawrequest，分解为了子查询分量的详细过程如下：

1.对原始图查询请求进行解析，得到查询请求涉及到的节点类型vertextypea，解析过程可能会涉及到语法分析和词法分析；

2.请求元数据配置中心，获取子图之间的关联配置信息subgraphconfig；

3.通过subgraphconfig得到vertextypea的关联节点vertextypeb；

a)如果vertextypeb存在：则根据vertextypea、vertextypeb的配置信息和原始请求rawrequest中的条件信息，构造子查询请求requesta和requestb，这两个请求为最终的查询请求；

b)如果vertextypeb不存在，则最终的查询请求为rawrequest；

4.将上一步中生成的请求作为结果，交由下一个模块进行处理。

以上面定义的两子图grapha和graphb为例子，如需要查询user节点的一度关系，原始请求内容为：request(vertextype＝user,querytypye＝navigation,degree＝1，conditon＝…)。首先解析路由层会解析得到查询中的节点类型为user，然后根据子图之间的关联关系：grapha.person＝graphb.user得到关联节点为person。最终构造的子查询分量为:

1.request(vertextype＝user,querytypye＝navigation,degree＝1，conditon＝…)

2.request(vertextype＝person,querytypye＝navigation,degree＝1，conditon＝…)

解析路由层将查询请求分解后，还需要在每个子查询分量中标识该子查询分量对应的图执行引擎，以便从不同的图执行引擎中获取子查询分量的执行结果。

引擎执行层，用于执行解析路由层传入的子查询分量，并将子查询分量的查询结果返回。引擎执行层由一系列查询执行引擎组成，它可以是：一个或多个图引擎，或者一个或多个关系数据库引擎，或者一个或多个图引擎及一个或多个关系数据库引擎，或者一个或多个图引擎以及一个或多个除图引擎外其他的非关系数据库引擎。各个独立的查询执行引擎应具备识别子查询分量、执行子查询分量、标识子查询分量结果的能力。

数据适配层，用于解析子查询分量的查询结果，同时结合元数据中心中的配置信息，将子查询结果转为标准的图数据schema。数据适配层主要解决不同查询执行引擎返回结果不统一的情况。首先，数据适配层接受子查询分量的查询结果，解析原始结果信息，然后，从元数据中心获取数据适配规则；最后，基于数据适配规则，将解析后的原始结果信息，转换为标准的点、边、路径、属性领域模型。

数据组装层，用于根据元数据中心里面子图之间的关联关系，把不同子查询的适配结果进行组合、融合，最终返回统一的图查询结果。数据组装层接受适配后的子查询分量结果，根据视图下各个子图间的关联关系，将子查询分量结果进行去重(去除重复的点、边)、融合(合并同一类型上的点/边边)、重建(新建点、边关系)。

通过元数据中心定义的子图关联关系，将不同子图合并成一张图，即为「融合」，主要分为点融合和建立对等边两种方式：

点融合过程过程如下：

1.对于子图a中的每个节点进行遍历，当前遍历的点类型为vertexa，类型为vertextypea；

2.如果遍历到的点vertexa存在关联节点(关联关系从元数据中心获取)，则开始遍历子图b中的所有节点，子图b中当前遍历到的节点为vertexb

2.1如果vertexb的类型vertextypeb不等于vertextypea，继续迭代过程，否则继续执行以下步骤；

2.2根据关联关系中属性映射信息，继续判断vertexa和vertexb中相应的属性是否相等：

2.2.1如果不相等，则回到步骤2继续执行；

2.2.2如果相等，则开始vertexa和vertexb的融合，融合主要有属性融合和关系两步，其中关系融合指的是将vertexb的出入边链接到vertexa上，属性融合指的是将vertexb上的属性信息添加到vertexa的属性中。

2.3继续步骤2的迭代。

3.如果vertexa不存在关联节点，则继续步骤1的迭代。

如图5所示，对于图4中子图grapha、graphb中的两个节点person、user，存在关联关系，且属性name为均为xxx，则这两个可以进行节点融合，融合后子图a中的节点person的边关系会自动链接到子图b中的节点user上。

建立对等边融合两张子图的大体步骤与点融合的主要步骤一致，唯一区别在于：找到两个对等节点后，会通过新建一条虚拟边的方式链接子图，两个对等点会保留。

如图5所示，对于图4中子图grapha、graphb中的两个节点person、user，存在关联关系(属性name为均为xxx)，可以进行边重建，通过构造一条新的对等边，形成更大的拓扑结构。

需要说明的是，本领域技术人员应当理解，上述异构图数据库的数据查询系统的实施方式中所示的各模块的实现功能可参照前述异构图数据库的数据查询方法的相关描述而理解。上述异构图数据库的数据查询系统的实施方式中所示的各模块的功能可通过运行于处理器上的程序(可执行指令)而实现，也可通过具体的逻辑电路而实现。本说明书实施例上述异构图数据库的数据查询系统如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本说明书实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机、服务器、或者网络设备等)执行本说明书各个实施例所述方法的全部或部分。而前述的存储介质包括：u盘、移动硬盘、只读存储器(rom，readonlymemory)、磁碟或者光盘等各种可以存储程序代码的介质。这样，本说明书实施例不限制于任何特定的硬件和软件结合。

相应地，本说明书实施方式还提供一种计算机可读存储介质，其中存储有计算机可执行指令，该计算机可执行指令被处理器执行时实现本说明书的各方法实施方式。计算机可读存储介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括但不限于，相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读存储介质不包括暂存电脑可读媒体(transitorymedia)，如调制的数据信号和载波。

此外，本说明书实施方式还提供一种异构图数据库的数据查询系统，其中包括用于存储计算机可执行指令的存储器，以及，处理器；该处理器用于在执行该存储器中的计算机可执行指令时实现上述各方法实施方式中的步骤。

在一个实施例中，该处理器可以是中央处理单元(centralprocessingunit，简称“cpu”)，还可以是其他通用处理器、数字信号处理器(digitalsignalprocessor，简称“dsp”)、专用集成电路(applicationspecificintegratedcircuit，简称“asic”)等。前述的存储器可以是只读存储器(read-onlymemory，简称“rom”)、随机存取存储器(randomaccessmemory，简称“ram”)、快闪存储器(flash)、硬盘或者固态硬盘等。本发明各实施方式所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。在一个实施例中，该异构图数据库的数据查询系统还包括总线和通信接口。处理器、存储器和通信接口都通过总线相互连接。通信接口可以是无线通信接口也可以是有线通信接口，用于使得处理器能够与其他的装置通信。

需要说明的是，在本专利的申请文件中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。本专利的申请文件中，如果提到根据某要素执行某行为，则是指至少根据该要素执行该行为的意思，其中包括了两种情况：仅根据该要素执行该行为、和根据该要素和其它要素执行该行为。多个、多次、多种等表达包括2个、2次、2种以及2个以上、2次以上、2种以上。

在本说明书提及的所有文献都被认为是整体性地包括在本说明书的公开内容中，以便在必要时可以作为修改的依据。此外应理解，以上所述仅为本说明书的较佳实施例而已，并非用于限定本说明书的保护范围。凡在本说明书一个或多个实施例的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本说明书一个或多个实施例的保护范围之内。

在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描述的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。