CN116266195A - 在分布式图数据库中优化sparql查询 - Google Patents

在分布式图数据库中优化sparql查询 Download PDF

Info

Publication number
CN116266195A
CN116266195A CN202211631110.9A CN202211631110A CN116266195A CN 116266195 A CN116266195 A CN 116266195A CN 202211631110 A CN202211631110 A CN 202211631110A CN 116266195 A CN116266195 A CN 116266195A
Authority
CN
China
Prior art keywords
operator
graph
operators
rdf
type
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
CN202211631110.9A
Other languages
English (en)
Inventor
F·拉贝特
J-P·萨胡特·迪扎恩
A·鲁利尔
D·E·图克斯巴里
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.)
Dassault Systemes SE
Original Assignee
Dassault Systemes SE
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 Dassault Systemes SE filed Critical Dassault Systemes SE
Publication of CN116266195A publication Critical patent/CN116266195A/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/90Details of database functions independent of the retrieved data types
    • G06F16/903Querying
    • G06F16/9032Query formulation
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/80Information retrieval; Database structures therefor; File system structures therefor of semi-structured data, e.g. markup language structured data such as SGML, XML or HTML
    • 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/2453Query optimisation
    • G06F16/24534Query rewriting; Transformation
    • G06F16/24537Query rewriting; Transformation of operators
    • 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/2452Query translation
    • 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/2453Query optimisation
    • 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/24564Applying rules; Deductive queries
    • G06F16/24565Triggers; Constraints
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90Details of database functions independent of the retrieved data types
    • G06F16/901Indexing; Data structures therefor; Storage structures
    • G06F16/9024Graphs; Linked lists

Landscapes

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

Abstract

本公开内容特别涉及一种用于由查询引擎生成用于在RDF图上的SPARQL查询的运算符图的计算机实现的方法。该方法包括提供可由查询引擎执行的运算符图,该图包括多个基本运算符,所述运算符中的至少两个运算符具有第一类型,至少两个运算符各自被配置为找到RDF图中的与相应的基本图模式匹配的RDF三元组。该方法还包括识别该图的具有第一类型的至少两个基本运算符中的一组运算符。该组运算符的相应的基本图模式具有相同的主语和/或谓语和/或宾语,并且所识别的一组运算符在该图中被等效运算符替换,该等效运算符被配置为找到RDF图中的与该组运算符的相应的基本图模式匹配的RDF三元组。

Description

在分布式图数据库中优化SPARQL查询
技术领域
本公开内容涉及计算机程序和系统领域,并且更具体而言,本公开内容涉及用于由查询引擎生成用于在RDF图上的SPARQL查询的运算符图(DAG)的方法、系统和程序。
背景技术
市场上提供了多种用于设计、工程化和制造对象的系统和程序。CAD是计算机辅助设计的首字母缩略词,例如,其涉及用于设计对象的软件解决方案。CAE是计算机辅助工程的首字母缩略词,例如,其涉及用于模拟未来产品的物理行为的软件解决方案。CAM是计算机辅助制造的首字母缩略词,例如,其涉及用于定义制造过程和操作的软件解决方案。在这样的计算机辅助设计系统中,图形用户界面在技术的效率方面起着重要作用。这些技术可以嵌入在产品生命周期管理(PLM)系统内。PLM是指一种业务策略,其帮助公司在扩展企业的概念中共享产品数据,应用公共过程,并且利用企业知识来开发从概念到其生命的结束的产品。由Dassault Systèmes(依据商标CATIA、ENOVIA和DELMIA)提供的PLM解决方案提供了组织产品工程知识的工程中心、管理制造工程知识的制造中心以及实现到工程中心和制造中心两者的企业集成和连接的企业中心。总之,该系统提供了链接产品、过程、资源的开放对象模型,以实现动态的、基于知识的产品创建和决策支持,这驱动优化的产品定义、制造准备、生产和服务。
与在磁盘或SSD上存储数据的数据库相比,图数据库特别适于存储器内数据库(即,主要依赖于存储器进行数据存储的专用数据库)中的应用。
由于RDF图数据库面临非常大的数据集的问题,并且为了保持这种数据库的性能和可扩展性,需要跨不同物理位置存储数据的分布式方法。数据在物理位置上的分布可以是为了优化数据库的一些方面,或者对所接收的查询(例如,写入或读取)的响应。该分布不一定是已知的或不能被实施。
已经提出了三类分布式方法:
1.基于云的方法,其中使用现有云计算平台(比如基于小文件的HDFS)来分布大型RDF图。这些方法采用基于三元组模式的连接处理,其最常使用MapReduce技术(并行、分布式计算)或从其获得启发(例如,利用Spark(其是用于大规模数据处理的统一分析引擎))。基于云的方法在将类似MapReduce计算适应到图计算方面存在困难。MapReduce基本上是拆分-应用-组合策略,而SPARQL的图同态具有高得多的语义。
2.基于分区的方法将RDF图划分为子图集合,并且将SPARQL查询分解为子查询。使用类似于关系分布式数据库的技术在被分区的数据上执行子查询(关于利用关系数据库的这种方法的细节,参见[2])。RDF中缺少纲要(schema)(例如开放世界假设)使得难以使SQL策略适应SPARQL查询处理。与关系数据库相反,这种方法由于在RDF中没有纲要而难以实施分区策略。具体地,可能已经出于另一目的(例如,写入吞吐量)选择了分区策略。
这两种方法都导致网络干扰,即增加中间结果的数量,这降低了性能。
3.联合SPARQL处理系统评估多个SPARQL端点上的查询,通常是链接的开放数据目标。那么,其是一种数据集成方法(即,通过组合驻留在不同源中的数据并且向用户提供它们的统一视图)。
以下文献提出了用于在分布式环境中在大型RDF图上处理SPARQL查询的技术,并且采用部分评估和组装框架:Peng等人,“Processing SPARQL queries over distributedRDF graphs”,The VLDB Journal 25.2(2016):243-268。该文献提出了一种基于仅对数据图进行分区而不对查询进行分解的策略,其中使用一些图分区算法将RDF图分区为顶点不相交的片段。因此,该方法需要对图进行分区,并且不能应用于未知的分区。
在这种背景下,仍然需要一种用于由查询引擎生成用于在RDF图上的SPARQL查询的运算符图(DAG)的改进方法。
发明内容
因此,提供了一种用于由查询引擎生成用于在RDF图上的SPARQL查询的运算符图的计算机实现的方法,该方法包括通过对存储引擎进行查询来提供可由查询引擎执行的运算符图;所提供的图包括多个基本运算符,所提供的图的基本运算符中的至少两个基本运算符具有第一类型,所述至少两个基本运算符各自被配置为找到RDF图中的与相应的基本图模式匹配的RDF三元组;以及识别所提供的图的具有第一类型的至少两个基本运算符当中的一组运算符,使得该组运算符的相应的基本图模式具有相同的主语和/或谓语和/或宾语,所识别的该组运算符在所提供的图中被等效运算符替换,该等效运算符被配置为在对存储引擎进行查询时找到RDF图中的与该组运算符的相应的基本图模式匹配的RDF三元组。
该方法可以包括以下各项中的一项或多项:
-该组运算符的相应的基本图模式具有常量谓语;
-该组运算符的相应的基本图模式具有常量宾语;
-该组运算符的相应的基本图模式具有相同的主语;
-所提供的图还包括第二类型的至少一个基本运算符,所述第二类型的至少一个基本运算符被配置为接受一个或多个RDF三元组和布尔表达式并作为输入,并且输出一个或多个RDF三元组的子集,该布尔表达式在该子集中的每个RDF三元组的一部分上三元组的应用为真,该方法还包括:在识别所提供的图的至少两个第一类型基本运算符当中的一组运算符之前,将第二类型的至少一个基本运算符中的每个基本运算符移动到紧接在第一类型的相应基本运算符之后,第一类型的相应基本运算符能够找到第二类型的至少一个基本运算符被配置为接受的RDF三元组;其中,等效运算符还被配置为接受约束作为输入,并且该方法还包括:对于第二类型的至少一个基本运算符中的每个基本运算符:将第二类型的运算符拆分为至少部分地能够被转换为约束集合的表达式;以及从该图中去除第二类型的基本运算符,并且将约束集合输入到相应的等效运算符中,该相应的等效运算符至少替换紧接在第二类型的基本运算符之前的第一类型的相应基本运算符。
-约束中的每个约束由存储引擎进行验证,并且约束集合包括以下各项中的至少一项或多项:数值约束、对值或语言的类型的约束、以及针对字符串的约束;
-该子集中的每个RDF三元组的该部分三元组包括相应RDF三元组的主语和/或宾语;
-在移动第二类型的至少一个基本运算符中的每个基本运算符之后并且在拆分运算符之前,对于第二类型的每个基本运算符:将第二类型的基本运算符归一化为合取形式;
-所提供的图还包括第三类型的至少一个基本运算符,其被配置为:接受一个或多个索引作为输入,每个索引对应于RDF图中的RDF三元组的变量的元素的值;以及输出针对索引的相应值;其中,等效运算符还接受第一标签作为输入,并且该方法还包括:对于第三类型的至少一个基本运算符中的每个基本运算符:识别运算符图中的能够找到第三类型的运算符的对应RDF三元组的等效运算符;以及将所识别的等效运算符的第一标签的值设置为预定义值,并且从所提供的图中去除第三类型的运算符;
-该组运算符中的至少一个运算符具有用于基本图模式的第二标签,等效运算符还接受第二标签作为输入,等效运算符至少找到RDF图中的与该组运算符中的不具有第二标签的至少运算符的相应的基本图模式匹配的任何RDF三元组;
-识别运算符图中的具有相同主语和/或相同宾语的至少两个等效运算符;以及在对存储引擎进行查询时,用能够找到RDF图中的与两个所识别的等效运算符的相应的所识别的基本图模式匹配的RDF三元组的等效运算符来替换两个所识别的等效运算符;和/或
-RDF图是具有到两个或更多个子图的未知分区的分布式RDF图。
还提供了一种包括用于执行该方法的指令的计算机程序。
还提供了一种具有记录在其上的计算机程序的计算机可读存储介质。
还提供了一种系统,包括耦合到存储器和图形用户界面的处理器,所述存储器具有记录在其上的计算机程序。
附图说明
现在将参考附图描述非限制性示例,其中:
-图1示出了方法的示例的流程图;
-图2示出了在SPARQL核心内执行SPARQL查询的示例工作流程;
-图3示出了运算符DAG的示例;
-图4示出了运算符DAG的另一示例;
-图5示出了由该方法生成的运算符DAG的示例;以及
-图6示出了系统的示例。
具体实施方式
参考图1的流程图,提出了一种用于由查询引擎生成用于在RDF图上的SPARQL查询的运算符图(即,有向无环图或DAG)的计算机实现的方法。该方法包括通过对存储引擎进行查询来提供可由查询引擎执行的运算符图。所提供的图包括多个基本运算符。所提供的图的基本运算符中的至少两个基本运算符具有第一类型,这至少两个基本运算符各自被配置为找到RDF图中的与相应的基本图模式匹配的RDF三元组。该方法还包括识别所提供的图的具有第一类型的至少两个基本运算符当中的一组运算符,使得该组运算符的相应的基本图模式具有相同的主语和/或谓语和/或宾语。所识别的一组运算符在所提供的图中被等效运算符替换,该等效运算符被配置为在对存储引擎进行查询时找到RDF图中的与该组运算符的相应的基本图模式匹配的RDF三元组。
这样的方法构成了通过优化来在RDF图上引擎化用于SPARQL查询的运算符图的改进的解决方案。这种优化通过以下方式来实现:在对存储引擎进行查询时用能够找到RDF图中的与一组运算符的相应的基本图模式匹配的RDF三元组的等效运算符替换查询的所提供的图中的一组若干运算符。这种替换通过减少调用分布式存储引擎的开销来显著地降低通信成本。
值得注意的是,该方法实现了这样的优化,而无需关于RDF图(即,数据的集合)如何跨不同的物理位置分布(即,关于数据的分布)的任何前提。该方法仅要求存储引擎能够通过找到RDF图中的与相应的基本图模式匹配的RDF三元组来对查询进行应答,并且分区策略被认为是未知的。
就“数据库”而言,其意指被组织用于搜索和检索的数据(即,信息)的任何集合(例如,面向图的数据库)。如本领域中已知的,面向图的数据库是使用图论的面向对象的数据库,因此具有节点和弧,从而允许表示和存储数据。该图将存储库(store)中的数据项与节点和边的集合相关联,边表示节点之间的关系。所述关系允许存储库中的数据直接链接在一起,并且在许多情况下,利用一个操作来检索。图数据库优先保存数据之间的关系;与通过隐式连接来链接数据的其他数据库模型(例如,关系数据库)相反。当存储在存储器上时,图数据库允许计算机进行快速搜索和检索。特别地,图数据库被构造用于结合各种数据处理操作对关系的快速检索、修改和删除。面向图的数据库也称为图数据库;表述“面向图的数据库”和“图数据库”是同义的。
在各示例中,图数据库可以是RDF图数据库。RDF图是用于图的存储和检索的传统数据模型。RDF图是一种有向标记图数据格式。这种格式广泛用于表示Web(网页)中的信息。W3C已经发布了标准规范以将信息的RDF表示指定为图,参见例如“RDF 1.1Concepts andAbstract Syntax”,W3CRecommendation(W3C推荐),2014年2月25日(或另外的草案版本RDF-Star)。所使用的抽象语法的核心结构是元组集合,每个元组包括谓语。这样的RDF元组集合被称为RDF图。
在各示例中,RDF元组可以包括三个或四个元素,元素包括节点和边。在各示例中,每个RDF元组(或每个RDF元组的元素)可以是包括主语、谓语和宾语的三元组。在这样的示例中,RDF图可以被可视化为节点和有向弧图,其中每个三元组被表示为节点-弧-节点链接。替代地,RDF三元组可以通过两个节点(其是主语和宾语)以及连接它们的弧(其是谓语)来可视化。
在各示例中,RDF元组可以是RDF四元组。可以通过将图标记添加到RDF三元组来获得RDF四元组。在这样的示例中,RDF元组包括RDF图。W3C已经发布了标准规范以指定RDF四元组(也称为N-四元组),参见例如“RDF 1.1N-Quads,A line-based syntax for RDFdatasets”,W3CRecommendation,2014年2月25日。可以通过将图名称添加到RDF三元组来获得RDF四元组。图名称可以是空的(即,对于默认或未命名的图)或IRI(例如,谓语)。每个四元组的图名称是四元组是数据集中的一部分的图。在下文中,术语RDF元组(或元组)无差别地指代RDF三元组或RDF四元组,除非明确提及使用一者或另一者。
RDF图数据库可以具有数十亿元组;例如,Uniprot数据集是蛋白质序列和功能信息的资源。
用于图数据库的查询引擎的可能优化受到关于图数据库与开放世界或封闭世界进行交互的假设的影响。如本身已知的,在用于知识表示的正式逻辑系统中,开放世界假设(OWA)是关于陈述的真值可以为真的假设,而不管是否已知其为真。这与封闭世界假设相反,封闭世界假设认为任何为真的陈述也是已知为真的。另一方面,封闭世界系统需要放置一切的地方(例如,帧上的时隙、OO类上的字段或DB中的列)。OWA默认假设不完整的信息,这有意地欠指定并且允许其他信息重用和扩展。语义Web是计算机可理解的Web的视图,其是以可重用形式分布的知识和数据,并且RDF(针对语义Web的W3C推荐)遵循开放世界假设。其允许数据建模和数据存储的更大灵活性。然而,如在具有SQL的关系模型中,封闭世界假设的约束对于查询优化是有用的,因为它们提供了关于如何存储数据的更多信息。
就“生成用于在RDF图上的SPARQL查询的运算符图”而言,其意指生成与SPARQL查询的查询计划相对应的运算符图。就“查询计划”或“查询执行计划”而言,其意指用于访问SQL关系数据库管理系统中的数据的一系列步骤。如本身已知的,运算符图包括节点(即,顶点)和边,每个节点对应于运算符序列中的运算符,并且每条边定义由所述边连接的两个运算符之间的关系。运算符图是有向无环图(DAG)。在下文中,当应用于运算符时,词语DAG和图可以互换使用。如本身已知的,这种运算符图由查询引擎生成。
在各示例中,查询是SPARQL查询。SPARQL是用于查询RDF数据的W3C推荐,并且是建立在RDF三元组的三元组模式之上的图匹配语言。SPARQL是用于RDF数据的查询语言,其能够跨不同的数据源表达查询,无论数据是原本存储为RDF还是经由中间件被视为RDF。SPARQL主要是基于图同态的。图同态是在两个图之间遵守其结构的映射。更具体地,其是在两个图的顶点集合之间的将相邻顶点映射到相邻顶点的函数。
SPARQL包含用于查询所需和可选的图模式以及它们的合取和析取的能力。SPARQL还支持聚合、子查询、否定、通过表达式创建值、可扩展值测试以及通过源RDF图的约束查询。就RDF三元组的三元组模式而言,其意指其中每个主语、谓语或宾语可以是(查询的)变量的RDF三元组。这意味着SPARQL查询需要应答在SPARQL中可能的八个不同的三元组模式。这样的八个三元组模式包括(S,P,O)、(S,?P,O)、(S,P,?O)、(S,?P,?O)、(?S,P,O)、(?S,?P,O)、(?S,P,?O)和(?S,?P,?O),其中变量在模式中之前是符号“?”。变量是三元组模式的输出,并且可以是SPARQL查询的输出。在一些示例中,变量可以是SELECT查询的输出。可以使用变量(例如,比如求和的聚合器)来构建SPARQL查询的输出。查询中的变量可以用于构建图同态(即,取得查询的结果所必要的中间节点)。在一些示例中,查询中的变量可以既不用于输出也不用于中间结果。基本图模式(BGP)可以是八个三元组模式中的一者。SPARQL可以通过连接若干BGP和可能的其他运算符的结果来构建更复杂的查询。因此,有竞争力的SPARQL引擎至少需要快速三元组模式解决方案和高效的连接方法。另外,需要查询优化器来构建使要在BGP中连接的中间结果的量最小化的高效执行计划。
在各示例中,图数据库具有现有的三元组存储库。三元组存储库(也称为RDF存储库)是用于通过语义查询存储和检索三元组的专用数据库,如本领域中已知的。三元组存储库可以至少对上述SPARQL的八个基本三元组模式进行应答。其还可以对过滤约束(例如,“x>5”)以及三元组模式进行应答。这样的三元组存储库被认为是由查询引擎在其上执行SPARQL查询的存储引擎。存储引擎(也称为“数据库引擎”)是数据库管理系统(DBMS)用于从数据库创建、读取、更新和删除(CRUD)数据的底层软件组件,如本领域中已知的。另外,在各示例中,三元组存储库是分布式数据库。就“分布式数据库”而言,其意指其中数据例如由系统管理员跨不同的物理位置进行存储的数据库。
回到图1,在步骤S10中,该方法包括通过对存储引擎进行查询来提供可由查询引擎执行的运算符图。就“运算符图”而言,其意指获得运算符图。在各示例中,提供运算符图(DAG)可以包括提供查询计划作为输入并且将查询计划转换为运算符的DAG。输入查询计划可以是通过用于查询计划优化的任何已知方法而优化的查询计划。在这样的示例中,输入查询计划被转换为中间表示(此后称为“IR”),其是运算符的DAG。提供图可以通过本领域的任何标准方法来获得。在各示例中,RDF图是具有到两个或更多个子图的未知分区的分布式RDF图。一个或多个子图中的每个子图可以存储在不同的存储器上。就“未知分区”而言,其意指一个或多个子图的分布对于该方法不可用并且不能被实施。这构成了一种改进的解决方案,其使得该方法能够在分布式方法中以可缩放的方式并且通过生成运算符的DAG来优化查询,而无需知道或强加分布中的分区。例如,这样的解决方案非常适合于在分布式RDF图上优化查询(即,读取),其中分区策略被设置为优化其他方面,例如写入。
运算符的DAG包括多个基本运算符,所提供的图的基本运算符中的至少两个基本运算符具有第一类型。就“基本图模式”而言,其意指从W3C形式定义本身已知的三元组模式的集合。大多数基本运算符(诸如“Filter”)与基本SPARQL模式(诸如FILTER子句)一对一匹配,并且可以直接从查询计划生成。第一类型的运算符被配置为找到RDF图中的与相应的基本图模式匹配的RDF三元组(即,“Find”运算符)。基本图模式对应于查询的相应基本运算符;换句话说,一个或多个基本运算符中的每个基本运算符被配置为执行基本图模式。
DAG的每个基本运算符可以在由查询引擎进行一次或多次调用时执行,并且因此可以产生元组流,通常成批分组(被称为缓冲区)。然后,缓冲区可以被DAG中的接下来的运算符消耗。
回到图1,在步骤S20中,该方法识别所提供的图的具有第一类型的至少两个基本运算符当中的一组运算符,使得该组运算符的相应基本图模式具有相同的主语和/或谓语和/或宾语。换句话说,该方法识别所提供的运算符图中的特定模式。
在各示例中,该组运算符的相应基本图模式具有常量谓语。替代地或另外,该组运算符的相应基本图模式具有常量宾语。就“常量谓语/宾语”而言,其意指该组运算符共享具有基础值(ground value)的谓语/宾语,即,谓语/宾语不是查询的变量并且具有由查询指定的值。然而,替代地或另外,该组运算符的相应基本图模式可以具有相同的主语。应理解,该组运算符的相应基本图模式可以包括常量谓语或常量宾语或相同主语、或者常量谓语和常量宾语、或者常量谓语和相同主语、或者常量宾语和相同主语、或者常量谓语和常量宾语和相同主语。将该组运算符的相应基本图模式限制到上述情况中的每一种(即,常量谓语和/或常量宾语和/或相同主语)保持等效运算符易于实现,同时在存储引擎上高效。该方法进一步减少了对于实现已知在SPARQL查询中频繁出现的各种特定模式所需的运算符的数量。在网络成本、发送到查询引擎的较少数据方面实现针对每种情况的优化。
回到图1,在步骤S30处,在所提供的图中用等效运算符替换所识别的一组运算符,该等效运算符被配置为在对存储引擎进行查询时找到RDF图中的与该组运算符的相应基本图模式匹配的RDF三元组。就用等效运算符“替换”所识别的一组运算符而言,其意指该方法通过从运算符图中去除属于该组的运算符并且在运算符图中添加等效运算符来“更新”运算符图。可以添加等效运算符来代替该组运算符中的一个运算符,例如该组中的第一运算符出现在所提供的运算符的DAG中。
在各示例中,所提供的图还包括第二类型的至少一个基本运算符。第二类型的运算符可以被配置为接受一个或多个RDF三元组和布尔表达式并且作为输入,并且输出一个或多个RDF三元组的子集,使得布尔表达式在子集中的每个RDF三元组的一部分三元组上的应用为真。换句话说,第二类型的运算符是“Filter”类型的运算符,并且基于作为过滤约束的布尔表达式来过滤输入RDF三元组(其可以是DAG中的另一运算符的输出)。
在各示例中,子集中的每个RDF三元组的该部分三元组包括相应RDF三元组的主语和/或宾语。换句话说,当等效运算符之后是对其输入(即,包括RDF三元组之一的主语和/或宾语)的主语和/或宾语进行操作的“Filter”类型运算符的运算符时,检查“Filter”类型运算符中的表达式,并且如果可能的话,将其转换为等效运算符内的约束。
在各示例中,该方法还包括:在识别所提供的图的至少两个第一类型基本运算符当中的一组运算符之前,将第二类型的至少一个基本运算符中的每个基本运算符移动到紧接在第一类型的相应基本运算符之后。第一类型的相应基本运算符能够找到第二类型的至少一个基本运算符被配置为接受的RDF三元组。换句话说,在这样的示例中,该方法将“Filter”运算符移动到可以支持它们作为约束的“Find”运算符旁边。
在这样的示例中,所识别的等效运算符还可以被配置为接受约束作为输入,并且该方法还包括对于第二类型的至少一个基本运算符中的每个基本运算符,将第二类型的运算符拆分成至少部分地能够被转换为约束集合的表达式。就“拆分运算符”而言,其意指变换运算符。拆分可以将包含复杂约束的单个运算符变换为各自包含更简单约束的若干运算符(全部为相同的“第二类型”)。该方法还可以包括从运算符图中去除第二类型的基本运算符,并且将约束集合输入到相应的等效运算符中,该等效运算符至少替换紧接在第二类型的基本运算符之前的第一类型的相应基本运算符。这种替换通过经由组合DAG的运算符减少调用分布式存储引擎的开销来进一步减少通信成本。
这些约束中的每个约束可以由存储引擎进行验证。等效运算符可以对每个RDF三元组的主语和/或宾语施加约束。约束集合包括以下各项中的至少一项或多项:数值约束(例如,“相等”、“不同”、“大于”、“小于”)、对值或语言的类型的约束(例如,英语、法语等)、以及针对字符串的约束(例如,正则表达式(regex)约束)。另外或替代地,约束集合可以包括其他约束(例如,对日期的约束等)。这减少了在存储引擎和查询引擎之间发送的数据量,因为这些约束由存储引擎检查,并且不符合的输出被立即消除(即,在被发送到查询引擎之前)。
该方法还可以包括在移动第二类型的至少一个基本运算符中的每个基本运算符之后并且在拆分运算符(如上所讨论的)之前,并且对于第二类型的每个基本运算符,将第二类型的基本运算符归一化为合取形式。就“合取形式”而言,其意指在布尔逻辑领域中已知的合取范式。就“归一化基本运算符”而言,其意指如果运算符包含含有AND、OR和NOTSPARQL运算符的表达式,则该表达式被重写为简单表达式(其中一些可以被NOT否定)的析取的合取。在归一化的示例中,该方法将形状“(C1 AND C2)OR C3”的约束变换为“(C1 ORC3)AND(C2 OR C3)”。该方法可以修改包含布尔表达式的所有约束,使得AND运算符被带到约束的第一级(这在文献中被称为“合取形式”)。效果是将复杂约束拆分成简单约束更加简单,因为OR表达式不能拆分成若干运算符,而AND表达式可以拆分成若干运算符。在各示例中,所提供的图(即,DAG)还包括第三类型的至少一个基本运算符。第三类型的基本运算符可以被配置为接受一个或多个索引作为输入,每个索引对应于RDF图中的RDF三元组的元素的值,并且输出针对索引的相应值。RDF三元组的元素可以是所述RDF三元组的主语、宾语或谓语中的任何一项。通常,每个索引可以对应于RDF图中的顶点的值,并且更具体地对应于字典中的值,或者更具体地对应于来自RDF图的URI或RDF文本(literal)。换句话说,第三类型的基本运算符可以是如稍后详述的“GetValues”类型的运算符。每一者对应于RDF图中的顶点的值,或每一者对应于字典中的值。如本身已知的,就“字典”而言,其意指关联数组、映射、符号表,或者字典是由(键,值)对的集合组成的抽象数据类型,使得每个可能的键在集合中最多出现一次。
在这样的示例中,等效运算符可以进一步接受第一标签作为输入。另外,该方法还可以包括:对于第三类型的至少一个基本运算符中的每个基本运算符,识别运算符图中的能够找到第三类型的运算符的对应RDF三元组的等效运算符,并且将所识别的等效运算符的第一标签的值设置为预定义值,并且从所提供的图中去除第三类型的运算符。这使得该方法能够通过将所提供的DAG的“GetValues”类型运算符进一步组合成等效运算符来进一步减少调用的开销。
在各示例中,该组运算符中的至少一个运算符具有用于基本图模式的第二标签。第二标签可以是如在SPARQL中已知的“OPTIONAL”标签。等效运算符然后可以进一步接受第二标签作为输入。在这样的示例中,等效运算符至少可以找到RDF图中的与该组运算符中不具有第二标签的至少运算符的相应基本图模式匹配的任何RDF三元组。在各示例中,如果模式被标记为“OPTIONAL”,则存储引擎返回与非可选模式匹配的第一三元组集合,即使其与可选模式不匹配。另外,存储引擎返回与可选模式匹配并且其主语也是来自第一集合的三元组的主语的三元组。这在通过等效运算符应答查询方面改进了该方法,因为在RDF中缺少任何纲要(schema)的情况下,模型可能不能保证对于给定模式,对于每个期望的谓语都存在三元组,这需要包括OPTIONAL子句。
该方法还可以包括识别运算符图中的具有相同主语和/或相同宾语的至少两个等效运算符,并且在对存储引擎进行查询时,用能够找到RDF图中的与两个所识别的等效运算符的相应的所识别的基本图模式匹配的RDF三元组的等效运算符替换两个所识别的等效运算符。换句话说,该方法可以组合两个已经识别的等效运算符。通过进一步组合运算符的DAG的运算符,这进一步减少了调用的开销。
该方法是计算机实现的。这意味着该方法的步骤(或基本上所有步骤)由至少一个计算机或任何类似系统来执行。因此,该方法的步骤由计算机来执行,可能完全自动地或半自动地执行。在各示例中,可以通过用户-计算机交互来执行该方法的至少一些步骤的触发。所需的用户-计算机交互的级别可以取决于预见的自动化级别,并且与实现用户愿望的需求相平衡。在各示例中,该级别可以是用户定义的和/或预定义的。
方法的计算机实现方式的典型示例是利用适于该目的的系统来执行该方法。该系统可以包括耦合到存储器和图形用户界面(GUI)的处理器;存储器具有记录在其上的计算机程序,计算机程序包括用于执行方法的指令。存储器还可以存储数据库。存储器是适于这种存储的任何硬件,可能包括若干物理上不同的部分(例如,一者用于程序,并且可能一者用于数据库)。
图6示出了系统的示例,其中该系统是客户端计算机系统,例如用户的工作站。
该示例的客户端计算机包括连接到内部通信总线1000的中央处理单元(CPU)1010、也连接到总线的随机存取存储器(RAM)1070。客户端计算机还设置有图形处理单元(GPU)1110,其与连接到总线的视频随机存取存储器1100相关联。视频RAM 1100在本领域中也称为帧缓冲区。大容量存储设备控制器1020管理对诸如硬盘驱动器1030之类的大容量存储器设备的访问。适合于有形地体现计算机程序指令和数据的大容量存储器设备包括所有形式的非易失性存储器,举例而言,其包括半导体存储器设备,诸如EPROM、EEPROM和闪存设备;磁盘,诸如内部硬盘和可移动盘;磁光盘;以及CD-ROM盘1040。任何前述内容可以由专门设计的ASIC(专用集成电路)补充或并入其中。网络适配器1050管理对网络1060的访问。客户端计算机还可以包括触觉设备1090,诸如光标控制设备、键盘等。在客户计算机中使用光标控制设备,以允许用户选择性地将光标定位在显示器1080上的任何期望位置。此外,光标控制设备允许用户选择各种命令,并且输入控制信号。光标控制设备包括用于向系统输入控制信号的多个信号生成设备。通常,光标控制设备可以是鼠标,鼠标的按钮用于生成信号。替代地或另外,客户端计算机系统可以包括触敏板和/或触敏屏幕。
计算机程序可以包括可由计算机执行的指令,指令包括用于使得上述系统执行方法的单元。该程序可以是可记录在任何数据存储介质上的,包括系统的存储器。程序可以例如在数字电子电路中实现,或者在计算机硬件、固件、软件或它们的组合中实现。程序可以被实现为装置,例如有形地体现在机器可读存储设备中以供可编程处理器执行的产品。方法步骤可以由执行指令程序的可编程处理器来执行,以通过对输入数据进行操作并且生成输出来执行该方法的功能。因此,处理器可以是可编程的并且被耦合以从数据存储系统、至少一个输入设备和至少一个输出设备接收数据和指令,以及将数据和指令发送到数据存储系统、至少一个输入设备和至少一个输出设备。应用程序可以用高级过程或面向对象的编程语言来实现,或者如果需要,可以用汇编或机器语言来实现。在任何情况下,语言可以是编译或解释语言。程序可以是完全安装程序或更新程序。程序在系统上的应用在任何情况下都产生用于执行该方法的指令。
现在讨论上文讨论的方法的示例的实现方式的示例。
实现方式的示例涉及SPARQL查询优化器领域,目的是使要连接的中间结果的数量最少化。实现方式的示例考虑存在如上所讨论的现有三元组存储库,其是分布式数据库。这种查询优化器的目的是通过降低与底层三元组存储库的通信成本来优化查询,而无需关于数据集合如何跨不同的物理位置分布(即,关于数据的分布)的任何前提。下面稍后讨论针对底层三元组存储库不是分布式数据库的情况的考虑。
实现方式的示例涉及利用具有底层三元组存储库的分布式数据库优化SPARQL查询(的性能),该底层三元组存储库具有无法实施的未知分区。换句话说,实现方式的示例在分布式RDF存储引擎上优化SPARQL查询的性能,对其唯一要求是应答在SPARQL中可能的八个不同的三元组模式。分区策略被认为是未知的。实现方式的示例处理被称为“SPARQLCore(核心)”的查询引擎内的SPARQL查询的优化。换句话说,实现方式的示例涉及对具有上述三元组存储库的SPARQL核心查询引擎内的SPARQL查询的优化。
在分布式RDF图上,在分区上寻找三元组匹配而未找到可以被视为等同于高速缓存未命中。代替MapReduce或查询分区,实现方式的示例创建将操作分组在一起以将它们应用于三元组块而不是单个三元组的查询计划。例如,在主语和/或谓语和/或宾语的向量上完成图模式匹配(其也可以扩展为包括图)。约束(例如,过滤器)可以与这些向量一起下推,如在经典优化中那样(在SQL中的表扫描上将约束下推)。这导致网络上更少的干扰,即,网络被认为是要优化的资源,在主存储器向量化中的CPU也是如此。换句话说,在实现方式的示例中,在分区上未找到三元组被认为是要隐藏的缺陷,在主存储器向量化中的高速缓存未命中也是如此。实现方式的示例对分区策略没有要求,并且不会将不必要的数据上拉到查询引擎。其是一种针对图计算完全优化的基于云的方法,而没有类似MapReduce的方法的缺点。因此,实现方式的示例在分布式环境中通过网络发送的SPARQL查询的数据方面优化查询,而无需对底层三元组存储库的数据或图分区的任何要求。
在图2中描绘了在SPARQL内部执行SPARQL查询的示例工作流程。实现方式的示例优化了从步骤“queryPlanToIR”到“OptimisedIR”的这种执行。术语“IR”代表“中间表示”,并且受到以下事实的启发:一些查询引擎能够生成编译代码作为LLVM中的中间表示。代码生成可以通过具有主存储器单节点优化的与向量化相同的精神的任何已知方法来执行。
现在讨论这种主存储器优化。
实现方式的示例受到用于在主存储器数据库上执行查询(或子查询)的查询优化技术的启发。存储器内数据库(IMDB,也称为主存储器数据库系统或MMDB或存储器驻留数据库)是主要依赖于主存储器进行计算机数据存储的数据库管理系统。其与采用磁盘存储机制的数据库管理系统形成对比。存储器内数据库比磁盘优化的数据库更快,因为磁盘访问比存储器访问慢,内部优化算法更简单,并且执行更少的CPU指令。分布式数据库也可以是主存储器数据库(例如,NuoDB)。
用于主存储器查询处理的现有技术是由于被称为向量化的技术而执行尽可能少的CPU指令(例如,最新版本的NuoDB查询引擎就是这种情况)。总之,向量化包括通过对元组块而不是仅对一个元组执行操作来优化CPU和隐藏高速缓存未命中。
在大多数查询引擎中,每个关系运算符使用Volcano式迭代来实现。虽然这种模型在过去当磁盘是主要瓶颈时工作良好,但是它在用于存储器内数据库管理系统(DBMS)的现代CPU上是低效的。因此,大多数现代查询引擎使用向量化(例如,VectorWise)或以数据为中心的代码生成(例如,HyPer)。与Volcano式迭代模型一样,向量化使用基于拉取的迭代,其中每个运算符具有产生结果元组的下一方法。然而,每个下一调用取回元组块而不是仅一个元组,这分摊了迭代器调用开销。实际的查询处理工作是由对一个或多个类型专用列执行简单操作(例如,计算针对整数向量的哈希结果)的原语来执行。分摊和类型专用化一起消除了传统引擎的大部分开销。
主存储器向量化查询处理具有一些缺点,因为其需要在单个机器上的主存储器中具有所有数据。因此,这不是可扩展的解决方案,因为在RDF图上对分布式查询使用这种处理(其中查询引擎和数据在同一机器上不是必需的)将需要在单个机器上的高速缓存中具有所有数据。该方法有可能仅在查询的仅在一个物理位置上执行的子部分上使用。
实现方式的示例可以具有查询计划作为输入。可以根据用于查询计划优化的任何已知方法来优化输入查询计划,即“经优化的查询计划”。实现方式的示例将输入查询计划转换为作为运算符的有向无环图(DAG)的IR。替代地,在一些变型中,实现方式的示例可以具有运算符的DAG作为输入。
运算符的DAG中的运算符对应于查询执行的基本元素,即,每个运算符产生元组流,通常成批分组,其被称为缓冲区。然后,每个运算符的缓冲区被DAG中的接下来的运算符消耗。运算符执行对应于对底层三元组存储库的调用,对RDF项的一般计算(即算术、字符串变换等)。RDF项在以下文献中给出:RDF 1.1Semantics,2014年2月25日的W3C推荐。
运算符的DAG可由查询引擎通过对存储引擎进行查询来执行。执行通常是多线程的。换句话说,元组缓冲区可以被接下来的运算符立即消耗,或者排队等待稍后执行,并且还可以被另一个空闲线程“窃取”(即,接管),该另一个空闲线程然后执行对应的运算符。
实现方式的示例可以具有迭代性质,并且将若干“变换通路”应用于IR以使其更高效,即,特别是通过去除冗余计算、传播常量、消除IR生成的伪影并且减少运算符的数量来获得“经优化的IR”。例如,实现方式的示例可以将基本三元组模式运算符组合成具有多个谓语的单个运算符。实现方式的示例可以执行运算符数量的这种减少,以便优化与底层三元组存储库的通信成本。
此后,运算符要么由IR执行器(多线程“执行引擎”)解码和执行,要么变换为生成的代码。“执行器上下文”或“生成的代码”输出“查询记录”的列表,然后将其传递到SPARQL核心的查询记录处理器。
根据各实现方式,中间表示或IR由以下元素构成:(i)运算符DAG(有向无环图),其将在下面详细讨论。(ii)常量表,其包含在IR中包含的所有常量值和索引,使得IR可以通过简单的整数来引用它们。在下文中,就“运算符包含常量”而言,其意指所述运算符包含常量id,使得能够在常量表中查找对应的常量。实现方式的示例使用常量表来避免在IR DAG本身中多次存储值,这可能在计算上是昂贵的。这通过在单个调用中取回与常量表中的每个值相对应的每个索引(反之亦然)来改进实现方式的示例。(iii)与SPARQL中的SELECT子句以及ORDER BY、LIMIT和DISTINCT子句的内容相对应的后处理器参数。SELECT、ORDERBY、LIMIT和DISTINCT在SPARQL中是众所周知的。
根据实现方式的示例,运算符DAG是运算符图,其节点(称为“运算符”)表示执行器的基本操作。运算符DAG可以具有单个根(即,图的开始)和单个叶(即,图的结束)。该单个叶是emit运算符。
DAG中的运算符可以操纵三种类型的数据:索引、值和/或标志。
索引对应于存储引擎中的索引,并且主要用作对“IStorageEngine:find”的调用的主要输入和输出。在各示例中,存在“未定义的”索引。值是任何RDF值,即空白节点、URI和文本(literal)(类型化文本和具有lang标签的文本两者),以及两个特殊值:“unevaluable”(其表示评估错误)和“undef”(其表示尚未绑定到任何值的变量)。在各示例中,大多数表达式评估是对值进行的,并且查询的最终结果是值列表。在实现方式的示例中,存储引擎提供从索引获得值的方法,反之亦然,以获得与特定值相对应的索引。执行引擎使用标志来实现同步屏障。
任何查询执行的最终结果是值的元组的列表。如果没有与查询匹配的元组,则列表可以为空。每个运算符的输入和输出是元组列表。这些元组可以包含零个或更多个索引、值和标志。元组列表被称为缓冲区,并且索引、值和标志被称为缓冲区的“列”,而缓冲区的各个元组被称为缓冲区的“行”。列由它们的索引和它们的类型(索引、值或标志)来定义。列的索引是逻辑值:其是标识符而不是输入缓冲区内的位置。实现方式的示例中的执行引擎的任务是将逻辑值与缓冲区内的位置进行映射。索引和值列可以对应于原始查询中的变量,或者对应于在IR生成或变换通路期间创建的临时变量。具有相同标识符的索引和值列可以对应于相同的逻辑变量。具有相同标识符的标志列和索引/值列之间可以不存在相关性。
实现方式的示例可以将每个运算符执行若干次,每次在不同的缓冲区上。实现方式的示例还可以使用“向量化”执行引擎,并且可以在包含若干行的缓冲区上执行每个运算符。这通过减少各个运算符执行的每次调用开销并且减少对存储引擎的调用总数来构成优化的执行。
任何运算符的输出是所述运算符的每个子运算符在DAG中的输入(如果有的话)。根运算符的输入是具有零列且具有单行的缓冲区,并且叶运算符的输出是具有通常都是值的列的缓冲区。实现方式的示例可以在元组被变换为“QueryRecords”并且被发送到“QueryRecordProcesor”之前对叶运算符的输出缓冲区进行后处理。实现方式可以通过本领域中的任何已知方法来执行后处理。
现在参考图3讨论基本示例。
以下查询:
SELECT?a?c{
?a<p>?b.
?b<q>?c
}
被转换为根据图3的DAG,其中i0、i1、...对应于索引列0、1、...,并且类似地,v0、v1、...对应于值列0、1、...。
图3中的每个箭头显示作为前一个节点的输出的列集合(其是接下来的运算符或子运算符的输入)。根据定义,第一节点的输入列301的集合为空。第一个“Find”节点生成两个索引列i0和i1(其对应于原始查询中的变量?a和?b),并且它们出现在其输出中。第二个“Find”节点生成第三索引列i2。其还将列i0保持在其输出中,因为稍后将需要其;然而,列i1在该“Find”之后不是必需的,并且因此被丢弃。
“Find”节点对应于原始查询中的各个BGP,并且它们的执行是对“IStorageEngine::find”的调用。每个“Find”节点都有确定其行为的模式。例如,第一个节点找到可以适配模式“*<p>*”的所有主语和宾语的索引,并且将它们映射到索引列i0和i1。第二个“Find”节点使用列i1作为输入,换句话说,对于其每个输入行,其找到匹配“i1<q>*”的每个索引,并且对于每个答案(如果有的话),输出包含原始元组的i0和答案的行。
“GetValues”从存储中获得对应于列i0和i1的值,即v0和v1,并将它们输出为值列。在图3的示例中,“GetValues”丢弃之后不需要的i0和i1,但是如果稍后在查询中需要它们,则其保留它们。
“Emit”节点始终是DAG的叶节点。其将其输出转发到后处理器。在图3的示例中,后处理器将“Emit”节点的输出转换为“QueryRecords”的列表。
如本身已知的,在SPARQL中存在“OPTIONAL”模式,其是组合两个图模式的二进制运算符。“OPTIONAL”模式是任何组模式,并且可以涉及任何SPARQL模式类型。如果组匹配,则扩展解,如果不匹配,则给出原始解。SPARQL中的OPTIONAL需要IR中的特定对待。
现在讨论实现方式的示例中的基本运算符。
·“Find”(找到):该运算符具有带有三个参数(主语、谓语和宾语)的“模式”,每个参数可以是常量、(类型为索引的)输入列或(也是类型为索引的)输出列。输入列(如果有的话)不能包含“undef”索引。该运算符对应于对“IStorageEngine::find”的调用,并且可以为每行输入生成零行、一行或多行输出。
·“GetValues”(取得值):给定一个或多个索引列,该运算符将对应的值列添加到输出。其接受具有未定义的索引的输入列(并在这种情况下返回未定义的值)。
·“GetIndex”(取得索引):该运算符是“GetValues”的成对项,即,给定值列,其生成对应的索引列。
·“Emit”:DAG的叶节点,将其输入传递到后处理器。
·“Filter”:给定生成类型为布尔的值的表达式,“Filter”在每一行上执行该表达式,并且当且仅当表达式的有效布尔值等于真时将该行复制到其输出。一些表达式可以进一步返回错误而不是布尔值作为值。错误值不会通过过滤器。
·“CompareIndex”(比较索引):该运算符可以具有布尔标志“equal”,并且给定两个索引列,当且仅当两列相等(即,如果“equal”为真)或不同(即,如果“equal”为假)时,将行复制到输出。
实现方式的示例可以包括另一运算符,如下所述的所谓的“StarFind”(开始找)。“StarFind”运算符是一种新运算符,其具有与“Find”类似的基本前提(其中给定一些输入和模式,“Find(找到)”与模式匹配的输出),但具有更复杂的结构和行为。在实现方式的示例中,“StarFind”运算符可以包括类似于“Find”的模式的一个或多个模式,具有以下属性:
-如果一个或多个模式包括多于一个模式,则所有模式具有相同的主语;
-一个或多个模式中的每个模式的谓语是常量(即,不是变量);和/或
-一个或多个模式中的每个模式的宾语必须是常量或输出列。
除了提到的属性之外,任何模式中的每个主语、谓语或宾语可以被标记为需要值和/或索引。替代地或另外,“StarFind”运算符支持限制其可以生成的输出的约束集合(即,“Filter”)。
在语义上,根据实现方式的示例的单个“StarFind”运算符对应于若干基本运算符的组合:
-每个模式对应于Find运算符;
-被标记为需要值的主语、谓语或宾语对应于“GetValues”运算符;和/或
-每个约束对应于“Filter”运算符。“StarFind”运算符由存储引擎来实现。
在实现方式的示例中,“StarFind”运算符在批次(即,缓冲区)上的每次执行因此是对存储引擎的单个调用,其等同于利用基本运算符的若干调用。
实现方式的示例可以使用具有多个模式的“StarFind”运算符。RDF建模中的循环和规则模式是类似于表的情况,其中对应于SQL表中的各个行的多个主语在三元组中出现,其中受限的谓语集合对应于SQL表中的列。由于开放世界假设,不能假设数据被物理地划分为表;尽管如此,SPARQL查询经常包含共享相同主语并且具有常量谓语的若干三元组。对于具有这样的多个模式的每个查询,可以使用单个“StarFind”运算符而不是若干Find运算符。
“StarFind”运算符的实现方式的示例可以使用“value”标签。如本身已知的,Find运算符从数据库中找到索引。每当预期SPARQL查询中的变量作为结果返回或在FILTER或BIND子句(以及其他)中使用时,Find运算符之后必须跟随针对该变量的“GetValues”运算符。实际上,几乎每个查询在Emit运算符之前以至少一个“GetValues”运算符结束。在实现方式的示例中,每当可以使用StarFind而不是Find时,“StarFind”运算符的“return valueas well as index”(返回值以及索引)标签使得“GetValues”运算符变得不必要。对于许多查询,可以完全消除GetValues运算符。
“StarFind”运算符的实现方式的示例可以支持可以应用于其模式的主语和宾语的约束集合,诸如数值约束(例如,“相等”、“不同”、“大于”、“小于”)、对值或语言的类型的约束和/或针对字符串的特定约束(例如,正则表达式(regex)约束)。实现方式的示例可以通过存储引擎检查这些约束,并且不符合的输出被立即消除(即,在被发送到查询引擎之前)。这通常显著地减少了在存储引擎和查询引擎之间发送的数据量。另外,实现方式的示例可以利用存储引擎的约束来优化数据遍历,与例如可以利用SQL纲要来优化封闭世界配置中的数据遍历的方式相同。
在实现方式的示例中,“StarFind”运算符支持对主语和/或宾语具有多于一个约束。在这样的示例中,主语和/或宾语可以匹配每个约束。这对于将宾语约束到值的范围是有用的。此外,“StarFind”运算符可以支持否定约束,在这种情况下,仅保留与约束不匹配的宾语。
实现方式的示例可以通过允许“optional”标签来进一步优化“StarFind”运算符。在RDF中缺少任何纲要的情况下,模型通常不保证对于给定的主语,对于每个预期谓语存在三元组。因此,即使对于类似“面向对象”的模型,也经常将一些或所有BGP放置在OPTIONAL子句内。在实现方式的示例中,“StarFind”允许每个模式上的“optional”标签。在这种实现方式的示例中,如果模式被标记为“optional”,则存储引擎返回与非可选模式匹配的任何主语,即使其与可选模式不匹配;并且如果存在与可选模式匹配的三元组,则其也必须返回它。换句话说,“StarFind”支持包含单个BGP的OPTIONAL子句的等效项。
“StarFind”的实现方式的示例可以在所支持的模式中应用一些约束。换句话说,“StarFind”可能不支持在查询中可以找到的每个模式。具体地,如上所述,“StarFind”可能要求其模式内的每个谓语都是常量。这样的限制使“StarFind”保持足够简单以在存储引擎上高效地实现。StarFind的目的不是在存储引擎上执行完整的查询,而是减少对于实现已知在SPARQL查询中频繁出现的非常特定的模式所需的运算符的数量。
因此,实现方式的示例在不能实施分区策略的分布式RDF图上优化SPARQL查询的性能,例如当已经选择分区策略来优化写入性能并且分区策略经受改变时。实现方式的示例将分区策略视为未知的。具体地,实现方式的示例优化对IR的生成以使分布式存储引擎的成本最小化,而无需实施任何分区策略。
为了获得这样的优化,实现方式定义了能够替换若干基本运算符的新的“StarFind”运算符。实现方式进一步优化对IR的生成,以利用主语和/或谓语和/或宾语的向量尽可能多地创建“StarFind”运算符。另外,实现方式的示例将约束和/或GetValues附加到StarFind运算符。
现在讨论根据实现方式的示例的用于SPARQL查询的优化IR生成的示例。
IR可以首先以仅包含基本运算符的非优化形式来生成。可以首先将查询解析为抽象语法树,抽象语法树可以可选地通过重新排序其元素中的一些元素或消除非常无用的构造(诸如查询中FILTER(TRUE)子句)来优化。这种可能优化的语法树被称为查询计划。
大多数基本运算符(诸如“Filter”)与基本SPARQL模式(诸如FILTER子句)一对一匹配,并且可以直接从查询计划生成。然而,IR可以具有两个额外约束(与SPARQL模式相比):
-IR中的“Find”运算符可以将作为运算符的输出(即,未在查询计划中较早出现的)的变量与作为输入(即,运算符中的在查询计划中较早出现的输出)的变量区分开。这与SPARQL中(以及查询计划中)的图模式不同,SPARQL中(以及查询计划中)的图模式可以接受可能已经或可能没有从先前运算符接收到值的变量。在这种情况下,运算符图可以包含两个分支,一个分支用于变量是输入的情况,一个分支用于变量是输出的情况。
-IR中的“Find”运算符可以仅从字典中检索索引,并且如果后续运算符需要对应的值(对于检索到的索引),则可以在该运算符之前插入“GetValues”运算符(以获得对应的值)。另外,对于出现在SPARQL查询的SELECT子句中的任何变量,“GetValues”运算符可能是必需的。
在实现方式的示例中,查询计划的单个分支可以对应于IR中的若干分支。例如,给定具有UNION节点的查询在一个分支中而不在另一个分支中生成变量?a,并且然后生成出现相同变量?a的BGP,则IR可以包含用于该单个BGP的两个“Find”运算符:一个对应于UNION的第一分支,其中变量?a是输入;另一个对应于UNION的第二分支,其中变量?a是输出。
实现方式的示例包括由SPARQLCore实现的算法,以尽可能多地使重复模式的数量最少化,同时保持查询计划的遍历节点的数量的O(n)复杂度。实现方式的示例仅需要生成算法来生成遵守以下两个约束的IR:
-如果若干分支通向包含变量?x的“Find”运算符,则所有这些路径都生成该变量?x,或者没有路径生成该变量?x;以及
-如果任何运算符(比如“Filter”)需要读取变量的值,则“GetValues”节点出现在该运算符之前,以从由“Find”运算符提供的索引生成值。
从查询计划生成IR的算法可以是本领域已知的任何算法。在现有技术中可获得若干这样的算法,其中在所生成的IR的质量、算法的简单性和算法的执行时间之间具有各种权衡。
现在讨论SPARQLCore的IR生成算法的示例。
如上所讨论的,可以通过函数queryPlanToIR从查询计划生成IR,该查询计划是经修改的语法树。查询计划中的节点被称为图模式。为了在遵守DAG规则的同时生成具有尽可能少的节点的DAG,queryPlanToIR可以实现基于边界的算法。
如上所讨论的,“列”可以是变量的索引或变量的值。“Find”运算符生成针对变量的索引列,而“GetValues”运算符从索引列生成值列。“queryPlanToIR”可以通过本身已知的深度优先搜索算法遍历查询计划。在遍历的任何步骤,其可以维护当前正在DAG中生成的所有分支的列表,并且对于每个分支,维护已经由该分支中的运算符生成的所有列的集合。这种分支的列表被称为边界。然后,该算法分析其正在遍历的图模式,将一些运算符附加到分支,并且从所附加的运算符生成新的边界。
如果边界中的两个分支具有相同的定义的列集合,则该算法的下一步骤将向它们附加相同的运算符,并且因此有可能合并两个分支。更大程度上,对于在两个分支中的任一分支中存在的每一列,如果存在以下情况,则可以合并两个分支:
·该列稍后在查询中不被任何TriplePattern读取;或者
·该列在两个分支中被定义,或者在两个分支中均未被定义。
在查询中“稍后”读取的列被称为决定性列。可以在queryPlanToIR的开始之前在单个通路中计算针对每个图模式的决定性列的集合,从而保持O(n)复杂度。
因此,遍历图模式的完整算法如下:
·获得针对当前图模式的决定性变量集合;
·通过计算描述每个决定性列是否存在于分支中的位图,并且使用该位图作为哈希表中的键,来找到在边界中具有相同的决定性列集合的每个分支;以及
·对于具有给定的决定性列集合的每个分支集合:
ο生成与图模式和该决定性列集合相对应的新的运算符列表,
ο将该运算符列表的头部附加到这些分支中的每个分支,以及
ο将列表的尾部添加到新边界。
现在讨论将图模式到运算符的映射的示例。
对于TriplePattern,实现方式的示例可以生成单个“Find”运算符,其中如果在GenerationContext中定义了TriplePattern的每个变量,则TriplePattern的每个变量变为输入,否则变为输出。
对于FilterPattern,如果在过滤表达式中出现的任何变量在GenerationContext中具有对应的索引列但没有值列,则实现方式的示例可以生成“GetValues”运算符,并且然后生成包含字节码形式的表达式的“Filter”运算符。
对于OptionalPattern,实现方式的示例可以生成具有新标志的“Optional”运算符,生成具有当前GenerationContext的optional子句(对应于“Optional”运算符)的内容,并且附加“SetFlag”运算符。实现方式的示例还可以将该分支的尾部添加到新边界,并且将“Optional”运算符的第二子运算符添加到具有OptionalPattern的原始GenerationContext的边界。
一些类型的运算符(例如,如上所讨论的“StarFind”)不是从图模式生成的,而是由简化和优化IRDAG的变换通路生成的。
现在讨论变换通路和优化的示例。
在实现方式的示例中,IRDAG数据结构提供帮助遍历和修改DAG的函数。这些函数可以用于实现若干变换或检查通路。另外,变换通路可以是“StarFind”运算符生成通路。
在实现方式的示例中,“StarFind”运算符的生成以若干通路进行。首先,如果可能的话,重新排序(即,移动)通路将每个“Filter”运算符移动到紧接在最后的“Find”运算符之后,该“Find”运算符生成包含在该“Filter”运算符中的变量。换句话说,该步骤将“Filter”运算符带到可以支持它们作为约束的“Find”运算符旁边。接下来,将每个“Filter”运算符归一化为合取形式;换句话说,如果“Filter”包含含有AND、OR和NOTSPARQL运算符的表达式,则“Filter”的对应表达式被重写为简单表达式(其中一些可以被NOT否定)的析取的合取。然后将“Filter”运算符拆分(即,变换)为可以转换为约束的表达式和不能转换为约束的表达式。如果“Filter”运算符已经是能够在不拆分的情况下转换为约束的简单表达式,则其可以不被拆分。
接下来,具有常量谓语和输出或常量宾语的“Find”运算符被转换为具有单个模式的“StarFind”运算符。如果新的“StarFind”后面跟着对其主语或宾语进行操作的Filter,则检查Filter中的表达式,并且如果可能的话,将其转换为“StarFind”内的约束。同样,如果“StarFind”运算符出现在对应于Optional子句的节点内,则去除那些节点,并且将StarFind中的模式标记为“optional”。然后,检查运算符图中的连续“StarFind”运算符。如果它们具有相同的主语,则通过组合它们的模式和对它们的主语的约束来合并它们。最后,另一通路找到每个“GetValues”运算符并且沿图向上移动以确定“GetValues”运算符内的变量是否是由“StarFind”运算符生成的。在这种情况下,从“GetValues”运算符中消除变量,并且将标签添加到“StarFind”运算符以指示其应该返回对应变量的值以及索引。
IRExecutor是用于在执行引擎中实现向量化的解释器。换句话说,给定IR,IRExecutor在多个线程上解释和执行IR,并且以QueryRecords.5.6.13的形式生成查询响应。IRExecutor可以根据本领域中任何已知的方法。
现在参考图4和5讨论实现方式的示例对查询的示例应用。
让我们以以下查询为例:
Figure BDA0004005733060000141
根据现有技术的查询的运算符图如图4所示,其中每个“Find”和“GetValues”运算符对应于对存储引擎的每批次的一次调用。假设查询足够短而仅需要一个批次,这意味着对存储引擎的5次调用。
利用本发明,运算符图如下:
根据实现方式的示例的运算符图如图5所示。从该图中可以看出,需要单独调用存储引擎的运算符的数量已经减少到1,因此显著减少了调用分布式存储引擎的开销。此外,由于在实现方式的示例中定义的“StarFind”运算符,将在每个运算符和查询引擎之间往返的中间数据不需要通过查询引擎传送。这显著降低了查询的网络成本。

Claims (15)

1.一种用于由查询引擎生成用于在RDF图上的SPARQL查询的运算符图(DAG)的计算机实现的方法,所述方法包括:
-通过对存储引擎进行查询来提供(S10)可由所述查询引擎执行的运算符图;所提供的图包括多个基本运算符,所提供的图的所述基本运算符中的至少两个基本运算符具有第一类型(FIND),所述至少两个基本运算符各自被配置为找到所述RDF图中的与相应的基本图模式匹配的RDF三元组;以及
-识别(S20)所提供的图的具有第一类型的所述至少两个基本运算符当中的一组运算符,使得所述一组运算符的所述相应的基本图模式具有相同的主语和/或谓语和/或宾语,所识别的一组运算符在所提供的图中被等效运算符替换(S30),所述等效运算符被配置为在对所述存储引擎进行查询时找到所述RDF图中的与所述一组运算符的所述相应的基本图模式匹配的RDF三元组。
2.根据权利要求1所述的方法,其中,所述一组运算符的所述相应的基本图模式具有常量谓语。
3.根据权利要求1至2中任一项所述的方法,其中,所述一组运算符的所述相应的基本图模式具有常量宾语。
4.根据权利要求1至3中任一项所述的方法,其中,所述一组运算符的所述相应的基本图模式具有相同的主语。
5.根据权利要求1至4所述的方法,其中,所提供的图还包括第二类型的至少一个基本运算符(FILTER),所述第二类型的至少一个基本运算符被配置为接受一个或多个RDF三元组和布尔表达式并作为输入,并且输出所述一个或多个RDF三元组的子集,所述布尔表达式在所述子集中的RDF三元组中的每个RDF三元组的一部分三元组上的应用为真,所述方法还包括:
-在所述识别所提供的图的至少两个第一类型基本运算符当中的一组运算符之前,将所述第二类型的至少一个基本运算符中的每个基本运算符移动到紧接在所述第一类型的相应基本运算符之后,所述第一类型的相应基本运算符能够找到所述第二类型的至少一个基本运算符被配置为接受的RDF三元组;
其中,所述等效运算符还被配置为接受约束作为输入,并且所述方法还包括:对于所述第二类型的至少一个基本运算符中的每个基本运算符:
-将所述第二类型的运算符拆分为至少部分地能够被转换为约束集合的表达式;以及
-从所述图中去除所述第二类型的基本运算符,并且将所述约束集合输入到相应的等效运算符中,所述相应的等效运算符至少替换紧接在所述第二类型的基本运算符之前的所述第一类型的相应基本运算符。
6.根据权利要求5所述的方法,其中,所述约束中的每个约束是由所述存储引擎进行验证的,并且所述约束集合包括以下各项中的至少一项或多项:
-数值约束,
-对值或语言的类型的约束,以及
-针对字符串的约束。
7.根据权利要求5或6中任一项所述的方法,其中,所述子集中的RDF三元组中的每个RDF三元组的所述一部分三元组包括相应RDF三元组的主语和/或宾语。
8.根据权利要求5至7中任一项所述的方法,还包括:在所述移动所述第二类型的至少一个基本运算符中的每个基本运算符之后并且在所述拆分运算符之前,对于所述第二类型的每个基本运算符:
-将所述第二类型的基本运算符归一化为合取形式。
9.根据权利要求1至8所述的方法,其中,所提供的图还包括第三类型的至少一个基本运算符(GetValues),所述第三类型的至少一个基本运算符被配置为:
-接受一个或多个索引作为输入,所述一个或多个索引各自对应于所述RDF图中的RDF三元组的变量的元素的值;以及
-输出针对所述索引的相应值;
其中,所述等效运算符还接受第一标签作为输入,并且所述方法还包括:对于所述第三类型的至少一个基本运算符中的每个基本运算符:
-识别在所述运算符图中的能够找到所述第三类型的运算符的对应RDF三元组的等效运算符;以及
-将所识别的等效运算符的第一标签的值设置为预定义值,并且从所提供的图中去除所述第三类型的运算符。
10.根据权利要求1至9中任一项所述的方法,其中,所述一组运算符中的至少一个运算符具有用于基本图模式的第二标签(OPTIONAL),所述等效运算符还接受所述第二标签(OPTIONAL)作为输入,所述等效运算符至少找到所述RDF图中的与所述一组运算符中的不具有所述第二标签的至少运算符的相应的基本图模式匹配的任何RDF三元组。
11.根据权利要求1至10中任一项所述的方法,还包括:
-识别所述运算符图中的具有相同主语和/或相同宾语的至少两个等效运算符;以及
-在对所述存储引擎进行查询时,用能够找到所述RDF图中的与两个所识别的等效运算符的相应的所识别的基本图模式匹配的RDF三元组的等效运算符来替换所述两个所识别的等效运算符。
12.根据权利要求1至11中任一项所述的方法,其中,所述RDF图是具有到两个或更多个子图的未知分区的分布式RDF图。
13.一种计算机程序,包括用于执行根据权利要求1至12中任一项所述的方法的指令。
14.一种计算机可读存储介质,其具有记录在其上的根据权利要求13所述的计算机程序。
15.一种系统,包括耦合到存储器的处理器,所述存储器具有记录在其上的根据权利要求13所述的计算机程序。
CN202211631110.9A 2021-12-17 2022-12-19 在分布式图数据库中优化sparql查询 Pending CN116266195A (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP21306834.9 2021-12-17
EP21306834.9A EP4198763A1 (en) 2021-12-17 2021-12-17 Optimizing sparql queries in a distributed graph database

Publications (1)

Publication Number Publication Date
CN116266195A true CN116266195A (zh) 2023-06-20

Family

ID=80034960

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202211631110.9A Pending CN116266195A (zh) 2021-12-17 2022-12-19 在分布式图数据库中优化sparql查询

Country Status (4)

Country Link
US (1) US20230195725A1 (zh)
EP (1) EP4198763A1 (zh)
JP (1) JP2023090684A (zh)
CN (1) CN116266195A (zh)

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10346401B2 (en) * 2016-07-07 2019-07-09 Accenture Global Solutions Limited Query rewriting in a relational data harmonization framework
CN109710638A (zh) * 2019-01-01 2019-05-03 湖南大学 一种联邦型分布式rdf数据库上的多查询优化方法
CN110825738B (zh) * 2019-10-22 2023-04-25 天津大学 一种基于分布式rdf的数据存储、查询方法及装置

Also Published As

Publication number Publication date
JP2023090684A (ja) 2023-06-29
US20230195725A1 (en) 2023-06-22
EP4198763A1 (en) 2023-06-21

Similar Documents

Publication Publication Date Title
CN113228001B (zh) 消除复杂数据库查询中的查询片段重复
US8332389B2 (en) Join order for a database query
US7693812B2 (en) Querying data and an associated ontology in a database management system
US10380269B2 (en) Sideways information passing
Huang et al. Orpheusdb: Bolt-on versioning for relational databases
US20080172360A1 (en) Querying data and an associated ontology in a database management system
US11132366B2 (en) Transforming directed acyclic graph shaped sub plans to enable late materialization
US11693856B2 (en) Query processing in a polystore
US9183253B2 (en) System for evolutionary analytics
Petersohn et al. Flexible rule-based decomposition and metadata independence in modin: a parallel dataframe system
US10733187B2 (en) Transforming a scalar subquery
US11640380B2 (en) Technique of comprehensively supporting multi-value, multi-field, multilevel, multi-position functional index over stored aggregately stored data in RDBMS
Zhu et al. High-performance row pattern recognition using joins
Gao et al. Declarative parameterizations of user-defined functions for large-scale machine learning and optimization
US20230195725A1 (en) Optimizing sparql queries in a distributed graph database
Xirogiannopoulos Enabling graph analysis over relational databases
US20240184827A1 (en) Summary generation for a distributed graph database
US20240202191A1 (en) Unified query engine for graph and relational data
Aichinger Structure-Guided Query Optimization in Column-Stores
Qiu et al. Efficient Regular Path Query Evaluation with Structural Path Constraints
Schäfer On Enabling Efficient and Scalable Processing of Semi-Structured Data
CN116257555A (zh) 在sparql查询引擎中处理逻辑规则
Liagouris et al. Efficient identification of implicit facts in incomplete OWL2-EL knowledge bases
Farid Query optimization for on-demand information extraction tasks over text databases
Krajca et al. Query optimization strategies in similarity-based databases

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication