P)过滤条件、AtleastNode(PV，N，P)过滤条件、 AtmostNode(PV,N,P)过滤条件、A1INodes(PV,P)过滤条件、AtLeastEdge(PV,N,P)过滤条 件、AtMostEdge(PV，N，P)过滤条件和AllEdges(PV，P)过滤条件。现在将更详细地描述这 些过滤条件中的每一个。
[0078]Length(PV，P)过滤条件验证被绑定到变量PV的每一匹配路径的长度（例如，边 数）都满足谓语P，并过滤掉不满足谓语P的那些路径。作为示例而非限制，路径过滤条件 FilterPath(Length(??X，〈4))确保被绑定到路径变量？？X的每一路径的长度都小于四 个边。AtMostNode(PV，N，P)过滤条件确保被绑定到变量PV的每一路径上的最多N个节点 满足结构谓语/基于值的谓语P。AllNodes(PV，P)过滤条件确保被绑定到变量PV的每一 路径上的每一个节点都满足结构谓语/基于值的谓语P。
[0079]AtLeastNode(PV,N,P)过滤条件验证被绑定到变量PV的每一路径上的最少N个节 点满足谓语P，并过滤掉不满足谓语P的那些路径。应注意，该谓语可以是结构谓语或基于 值的谓语。作为示例而非限制，AtLeastNode(??X，2,liveslnSydney)过滤条件确保被 绑定到变量？？X的每一路径的至少两个节点满足被通过居住在（livesln)关系连接到标 记有具有值悉尼（Sydney)的属性的节点的结构谓语。AtLeastNode(??X，l，@affiliated UNSW)过滤条件确保被绑定到变量？？X的每一路径的至少一个节点满足具有值UNSW的隶 属于（affiliated)属性的基于值的谓语。
[0080]AtLeastEdge(PV，N，P)过滤条件确保在被绑定到变量PV的每一路径上有最少N 个边满足基于值的谓语P(应注意，结构谓语无法针对边来表示）。AtMostEdge(PV，N，P) 过滤条件确保在被绑定到变量PV的每一路径上有最多N个边满足基于值的谓语P。 AllEdges(PV，P)过滤条件确保被绑定到变量PV的每一路径上的每一边都满足基于值的谓 语Po
[0081] 将领会，前述过滤条件均是示例性的，并且各种其他过滤条件也是可能的。
[0082] 1.3查询执行引擎
[0083] 如数据库系统领域中所领会的，关系数据库系统在执行从索引（例如，B树）中获 益的查询以及查询优化技术（例如，选择性估计和联接排序）时一般是高效的。作为示例 而非限制，通过应用谓语，关系索引可以将需要被访问的数据限制为仅满足这些谓语的那 些行。此外，纯索引访问可用于评估并回答关系数据库查询，由此消除了通过提供查询处理 中涉及到的所有列来访问数据页的需要。然而，关系数据库系统在处理涉及通过执行多个 执行起来昂贵的联接运算符来循环或递归访问大量记录（这可导致很大的中间结果）的查 询时是低效的。因此，在存储在关系数据库系统中的图（或其一部分）上执行遍历操作可 能由于大量的潜在联接以及必须从图（或其一部分）被存储在其上的辅助存储设备中检索 目标节点的执行成本而是时间低效的。
[0084] -般来说并如图数据库和图查询处理领域中所领会的，存在用于执行图查询的各 种类型的引擎，其中每一不同类型的引擎都可用于执行某类图查询。作为示例而非限制，存 在可用于执行模式匹配图查询的各种关系数据库引擎（也被称为关系数据库管理系统）。 这样的关系数据库引擎通信是以SQL(结构化查询语言）服务器的形式来实现的。示例性 关系数据库引擎包括常规的SPARQL引擎、微软的SQL服务器? (微软公司的注册商标）、 国际商业机器的DB2和Oracle数据库系统等等。也存在可用于执行可达性和最短路径图 查询的各种图引擎。示例性图引擎包括常规的Ne〇4j图数据库、HyperGraphDB(超图数据 库）、Virtuoso、DEX和AllegroGraph等等。
[0085] 如此后将更详细描述的，本文中描述的图查询处理技术实施例可使用多个独立的 查询执行引擎来对由实体提交给由属性图来建模的图数据库的给定图查询作出响应。这些 查询执行引擎可包括一个或多个关系数据库引擎、或一个或多个图引擎、或一个或多个混 合引擎（此后将对其进行更详细的描述）。查询执行引擎还可包括关系数据库引擎、图引 擎和混合引擎的任何组合。更具体地并作为示例而非限制，查询执行引擎可包括一个或多 个关系数据库引擎和一个或多个图引擎。查询执行引擎还可包括一个或多个关系数据库引 擎和一个或多个混合引擎。查询执行引擎还可包括一个或多个图引擎和一个或多个混合引 擎。一般来说，图查询的不同部分被发送至一个不同的查询执行引擎进行处理。更具体地 并且作为示例而非限制，在图查询处理技术实施例的示例性实施例中，涉及属性图中的关 系的图查询分量（例如，模式匹配分量）被发送至关系数据库引擎或混合引擎的关系数据 库组件进行处理，并且涉及属性图的拓扑结构的图查询分量（例如，可达性分量和最短路 径分量）被发送至图引擎或混合引擎的基于存储器的组件进行处理。
[0086] 图3以简化形式示出了可用于执行图查询的一部分的查询执行引擎的混合引擎 实现的示例性实施例。如图3中所例示的，混合引擎300包括基于存储器的组件302和使用 辅助存储设备的关系数据库组件304。混合引擎300提供对属性图（或其一部分）的高效 混合表示，其中属性图（例如，其数据对象和其拓扑结构两者等等）（或其一部分）被相关 地存储在关系数据库组件304中，而图的一部分或整个图（例如，图拓扑结构）被本机地存 储在主存储器中。如此后将更详细描述的，每当针对给定图查询分量生成的给定子查询被 发送至给定混合引擎300进行处理时，仅与属性图的拓扑结构（或其一部分）相关联的数 据被从关系数据库系统304中检索并被存储在存储器302中。相应地，本文中描述的图查询 处理技术实施例可采用对基于存储器302的数据结构上执行的方法来评估并回答图查询 的涉及对属性图的拓扑结构的遍历操作的各部分。出于包括但不限于以下的各种原因，使 用关系数据库系统304来存储属性图（或其一部分）是有利的。几十年的研究和开发价值 已被投入到关系数据库系统中，这已导致各种各样关系数据库优化，诸如盘数据布局优化、 索引和存储优化、缓冲器管理优化和查询优化等等。各图查询处理技术实施例利用了这些 优化。此外，图的主存储器表示允许快速执行若干操作，诸如遍历操作等等。
[0087] 再次参考图3并如在数据库系统的领域中所领会的，各种方法可用于将属性图 (或其一部分）相关地存储在关系数据库组件304中。作为示例而非限制，常规的全分解存 储模型（DSM)可用于将属性图（或其一部分）存储在关系数据库组件304中。出于包括但 不限于以下的各种原因，这是有利的。DSM对属性图模式而言是不可知的，并因此可适用于 具有任何模式的任何属性图。DSM还通过显著地减少关系数据库访问来准许图查询处理期 间的高效属性检索，因为仅图查询中涉及到的特定属性/关系的表的记录将被处理。
[0088] 图4以简化形式示出图1所示的属性图的片段的关系表示的示例性实施例。如图 4中所例示的，节点标识符（ID)被分配给在节点标记表406中的图片段中的每一节点。节 点的属性被存储在M个两列表400中，其中M是图片段中的节点的不同属性的数目（在所 示的情况下M为七）。给定的两列节点属性表400的第一列（ID)存储标记有相关联的属性 的每一个节点的标识符，且该表的第二列（值）存储这些节点中的每一个的属性的值。作 为示例而非限制并且如图4所例示的，标记为"Alice"的图片段中的节点在节点标记表406 中被分配了ID3,并且该节点的年龄属性被存储在年龄表408的行（3, 42)中。没有标记有 特定属性的各节点将只是在与该属性相关联的节点属性表中没有代表性记录。具有多个值 的节点属性将用与该属性相关联的节点属性表中的多个行（各自具有相同的ID值）来表 示。M个两列表400中的每一个可被存储成关于ID列的群集索引，在必须检索到同一节点 的一个以上属性时，该群集索引允许对合并联接的快速执行。此外，可为M个两列表400中 的每一个创建关于值列的二级分区B树索引，该二级分区B树索引通过使访问关系数据库 以检索满足谓语条件的那些节点的执行成本最小化来允许对关于属性的基于值的谓语的 快速执行。
[0089] 再次参考图4,边标识符（elD)被分配给图1中示出的属性图的片段中的每一边。 边的属性被存储在N个两列表402中，其中N是图片段中的边的不同属性的数目（在所示 的情况下N为3)。给定的两列边属性表402的第一列（elD)存储标记有相关联的属性的每 一边的标识符，且该表的第二列（值）存储这些边中的每一个的属性的值。作为示例而非 限制并且如图4中所例示的，标记为"affiliated(隶属于）"的图片段中将标记为"John" 的节点连接到标记为"Microsoft(微软）"的节点的边被分配为3的elD，并且该边的头衔 属性被存储在头衔表410的行（3,SeniorResearcher(高级研究员））中。没有标记有特 定属性的各边将只是在与该属性相关联的边属性表中不具有代表性记录。具有多个值的边 属性将用与该属性相关联的边属性表中的多个行（各自具有相同的elD值）来表示。M个 两列表402中的每一个可被存储成关于elD列的群集索引，在必须检索到同一边的一个以 上属性时，该群集索引允许对合并联接的快速执行。此外，可为N个两列表402中的每一个 创建关于值列的二级分区B树索引，该二级分区B树索引通过使访问关系数据库以检索满 足谓语条件的那些节点的执行成本最小化来允许对关于属性的基于值的谓语的快速执行。
[0090] 再次参考图4,图1中示出的属性表的片段中的边被存储在P个三列表404中，其 中P是图片段中的各节点之间存在的不同关系的数目（在所示的情况下P为6)。这P个三 列表404按以下方式存储图片段的拓扑结构（例如，表示该图片段中的节点和边的结构的 数据）。这P个三列表404中的每一个都聚合了表示特定关系的所有边的数据。这些边中 的每一个均由三条数据来描述，即由边标识符（elD)、该边连接到的源节点的标识符（sID) 和该边连接到的目的地节点的标识符（dID)。
[0091] 参考图3和4,将领会，可按各种方式实现属性表302的拓扑结构的基于存储器的 表示。作为示例而非限制，可采用本机的基于指针的数据结构来表示存储器302中的属性 图的拓扑结构。更具体地，属性图302的拓扑结构的基于存储器的表示可对P个三列表404 中的数据进行编码，该数据尤其表示在处理可涉及关于图的拓扑结构的繁重遍历操作的图 查询的可达性分量和最短路径分量时使用的数据。如此后将更详细描述的，这样的遍历操 作可是使用各种方法来执行，诸如常规的用于获得两个节点之间的最短路径的Dijkstra 方法和常规的广度优先搜索（BFS)方法等。
[0092] 在给定前述的情况下，将领会，由混合引擎提供的属性图的混合关系表示按以下 方式显著减少了主存储器消耗。首先，不必将属性图中的节点和边的属性以及这些属性的 数据值加载到存储器中，除非查询中需要。第二，不必在混合引擎的关系数据库组件的外部 构建针对这些属性的额外的储存器索引，因为本文中描述的图查询处理技术实施例将对图 查询谓语的评估发送给关系数据库组件处理，并且关系数据库组件选择构建其自己的高效 索引来加速该查询评估。
[0093] 1.4图查询处理
[0094] 图5以简化形式示出用于实现本文描述的图查询处理技术实施例的体系结构框 架的示例性实施例。换言之，图5例示了用于对由实体向由属性图来建模的图数据库提交 的G-SPARQL查询作出响应。图5中例示的体系结构框架500包括查询编译器502、查询执 行管理器504、多个独立的查询执行引擎506/508/510和查询结果呈现器512。一般说来并 如此后将更详细描述的，查询编译器502将G-SPARQL查询分解成一个或多个查询分量，并 生成表示经分解的查询分量的一个或多个子查询，其中这些子查询可以由多个独立的查询 执行引擎506、508、510中的不同的查询执行引擎来处理。
[0095] 再次参考图5,将领会，查询编译器502可用各种方式来实现。作为示例而非限制 并如图5所例示的，查询编译器502可包括前端编译器514和后端编译器516。一般来说 并此后将更详细描述的，前端编译器514将G-SPARQL查询转换成包括多个代数运算符（诸 如，关系运算符和可达性运算符等等）的代数查询计划，并用作表示G-SPARQL查询的抽象 的中间语言。前端编译器514使用基于元组的代数方言来执行该转换。基于元组的代数包 括一组代数运算符，这些代数运算符中的每一个