CN110651264B - 具有时态关系数据库的关系数据库管理系统中的查询计划生成和执行 - Google Patents
具有时态关系数据库的关系数据库管理系统中的查询计划生成和执行 Download PDFInfo
- Publication number
- CN110651264B CN110651264B CN201880027557.0A CN201880027557A CN110651264B CN 110651264 B CN110651264 B CN 110651264B CN 201880027557 A CN201880027557 A CN 201880027557A CN 110651264 B CN110651264 B CN 110651264B
- Authority
- CN
- China
- Prior art keywords
- query
- node
- query plan
- nodes
- sql
- 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.)
- Active
Links
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/2453—Query optimisation
- G06F16/24534—Query rewriting; Transformation
- G06F16/24542—Plan optimisation
-
- 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/2452—Query translation
- G06F16/24524—Access plan code generation and invalidation; Reuse of access plans
-
- 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/28—Databases characterised by their database models, e.g. relational or object models
- G06F16/284—Relational databases
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/90—Details of database functions independent of the retrieved data types
- G06F16/901—Indexing; Data structures therefor; Storage structures
- G06F16/9024—Graphs; Linked lists
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Databases & Information Systems (AREA)
- Data Mining & Analysis (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computational Linguistics (AREA)
- Operations Research (AREA)
- Software Systems (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
根据一个方面,通过重新使用在执行之后被保留在存储器中的现有查询计划的至少一部分,来针对关系数据库管理系统接收到的新提交的结构化查询语言(SQL)查询生成查询计划。
Description
技术领域
本发明的实施例涉及数据库领域;并且更具体地涉及关系数据库管理系统。
背景技术
企业软件系统通常是复杂的大规模系统,其支持许多(例如,数十、数百或数千个)并发用户。企业软件系统的示例包括财务计划系统、预算计划系统、订单管理系统、库存管理系统、销售队伍管理系统、商业智能工具、企业报告工具、项目和资源管理系统以及其他企业软件系统。
对企业软件系统的一种方法是要在定制硬编码软件之上开发定制用户界面(例如,美国专利号8,191,052)。在这种方法中,定制用户界面在报告和数据浏览方面具有有限的灵活性,而定制硬编码软件在处理大量数据时具有不足的性能。
对企业软件系统的替代方法是对通用商业智能或BI工具的使用,以通过零个或多个软件层与多维的存储器中数据存储(“OLAP”立方体(cube))进行对接。BI前端“讲”MDX语言;即,它将MDX表达式传输到OLAP立方体,OLAP立方体解释MDX,并且将响应的查询结果提供给BI前端。通用BI工具可以用于通过对基础数据源执行查询来准备并汇总个体报告和分析,并且将这些报告和分析呈现成用户可访问的格式,诸如BI仪表板环境。然而,在处理大量数据时,使用通用BI工具不能提供“近实时”性能(其中“近实时”指代在事件发生与经处理的数据的使用(诸如用于显示)之间由数据处理和/或网络传输引入的时间延迟。
如本领域中已知的,关系数据库管理系统(RDBMS)是基于关系模型的数据库管理系统(DBMS)。RDBMS提供了集成的一组计算机软件,其允许用户与一个或多个数据库进行交互,并且提供了对数据库中包含的所有数据的访问(可能存在限制,其限制了对特定数据的访问)。RDBMS提供各种功能,这些功能允许输入、存储和检索大量信息,并且提供了用于对如何组织该信息进行管理的方式。RDBMS通常支持以结构化查询语言(SQL)表达的查询。在接收到SQL查询时,RDBMS在传统上会创建查询计划,以确定如何在一个或多个数据库表上执行SQL查询,以检索满足该查询的结果。查询计划标识需要被访问的一个或多个数据库表、需要被应用于数据库表(并且通常是其中的数据)的操作、以及操作必须以其发生的次序。可以针对某些参数来优化查询计划,通常以便最小化查询执行时间和/或访问的数据总量。执行查询计划以确定查询结果,其中“执行”在本文中被定义为包括用于根据查询计划来确定查询结果的各种形式(例如,由功能、方法或其他可执行代码实现的查询计划运算符被执行、解释等)。换言之,为关系数据库管理系统中的SQL查询生成的查询计划(或查询执行计划)是操作的有序集合,用以访问来自关系数据库管理系统管理的一个或多个数据库的表(并且通常是其中的数据)并且在该表上进行操作。
如本领域中已知的,时态(temporal)数据库包含时间参考的(time-referenced)、或带时间戳的数据记录。时态关系数据库包括时态表,其中每个这种时态表都要将数据存储在数据记录中。对于每个时态表,该时态表的数据记录均由许多字段组成,这些字段中的一个或多个存储数据,并且这些字段中的一个或多个存储针对该数据记录的(一个或多个)时间戳。时态表被设计成使得存储在该时态表中的数据记录不会被覆写。而是,通过下述方式来实行对时态表中的数据记录中的数据的改变:1)改变数据记录的时间戳,否则该数据记录将已被覆写或修改以反映改变的时间;以及2)创建反映该改变的附加数据记录。因为时态表捕获了其数据记录中随时间的改变,因此可以确定时态表在两个时间之间的“Δ”。时态表中存储的数据有时被称为时态表的内容,并且可与时态表的模式(schema)区分开。从逻辑视图,可以将时态表视为具有行和列的表,其中表的标题定义了表的模式,每一行(其存储时态表的内容)是数据记录,列和行的每个交点是数据记录中的一个的字段,并且一个或多个列存储上面讨论的(一个或多个)时间戳。然而,时态表的内容可以以不同的方式被存储(例如,模仿上面讨论的逻辑视图的“面向行”的组织)(有时被称为“面向行”的时态表)、“面向列”(也被称为“列式”)的组织(有时被称为“面向列”或“列式”的时态表)等)。在时态表上进行操作的典型关系数据库查询计划运算符(例如PROJECT(项目)、JOIN(加入)、SELECT(选择))的实现方式是本领域已知的(例如,D. Pfoser和C.S. Jensen,“Incremental Join of Time-Oriented Data”,In Proc. 11th Intl. Conf. Scientificand Statistical Database Management,第232-243页,1999年;Jun Yang和JenniferWidom,“Maintaining Temporal Views Over Non-Temporal Information Sources ForData Warehousing”,In EDBT '98 Proc. 6th Int. Conf. on Extending DatabaseTechnology:Advances in Database Technology,第389-403页,1998年)。当这种实现方式被应用于(一个或多个)输入时态表上时有时可以仅对“Δ”进行确定和操作,从而避免需要对(一个或多个)时态表中的数据记录的全体重新执行操作。在时态关系表的上下文中,由关系数据库管理系统针对SQL查询生成的查询计划(或查询执行计划)是时态关系操作的有序集合,其用于对由关系数据库管理系统管理的一个或多个时态关系数据库的一个或多个时态表(并且通常是其中的数据)进行访问和操作。
发明内容
描述了在具有时态关系数据库的关系数据库管理系统中的查询计划生成和执行。根据一个方面,通过合并在执行之后被保留在存储器中的现有查询计划的至少一部分,针对关系数据库管理系统接收到的新提交的结构化查询语言(SQL)查询生成查询计划。关系数据库管理系统管理包括时态表的时态关系数据库。现有查询计划包括通过边连接的节点的有向图,该有向图表示查询计划运算符的有序集合,该查询计划运算符在被执行时生成针对较早提交的SQL查询的查询结果,该较早提交的SQL查询需要从时态关系数据库访问数据。针对新提交的SQL查询的查询计划包括通过边连接的节点的有向图,该有向图表示查询计划运算符的有序集合,该查询计划运算符在被执行时将生成针对新提交的SQL查询的查询结果。针对新提交的SQL查询的有向图通过它的至少一个边连接到针对较早提交的SQL查询的有向图的至少一个节点,使得有向图共享至少一个节点。每一个有向图的节点中的至少一个标识时态关系数据库的时态表中的一个,并且每一个有向图的节点中的至少一个标识在执行之后被保留在存储器中并且被创建以存储执行由该节点表示的查询计划运算符的结果的时态表。
根据附加的方面,在修改了时态表中的作为时态关系数据库的部分并且至少现有的(或新提交的)SQL查询需要从其中访问数据的给定的一个时态表之后,增量式地更新时存储了执行查询计划运算符的结果的时态表,该查询计划运算符由节点中的如下那些节点所标识:那些节点属于现有查询计划(或针对新提交的SQL查询的查询计划)并且直接或间接取决于标识了时态表中的该给定的一个时态表的节点。然后,将标识了对由现有查询计划(或针对新提交的SQL查询的查询计划)的有向图的根节点标识的时态表的增量式更新的数据传输到提交了较早提交的(或新提交的)SQL查询的客户端。
根据另一方面,响应于在关系数据库管理系统处接收到将需要从关系数据库管理系统管理的时态关系数据库的时态表访问数据的多个结构化查询语言(SQL)查询,来执行多个SQL查询以生成针对每个查询的查询结果。多个SQL查询的执行包括:生成和执行在执行之后被保留在存储器中的多个查询计划,其中多个查询计划中的每一个包括通过边连接的节点的有向图。每一个有向图表示查询计划运算符的有序集合,该查询计划运算符在被执行时生成针对多个SQL查询中的一个的查询结果,并且有向图的每一个节点表示查询计划运算符中的一个。每一个有向图通过它的至少一个边连接到另一个有向图的至少一个节点,使得那些有向图共享至少一个节点,并且每一个有向图的节点中的至少一个标识时态关系数据库的时态表中的一个。由有向图共享的节点中的至少一个标识在执行之后被保留在存储器中并且被创建以存储执行由该节点表示的查询计划运算符的结果的时态表。多个SQL查询的执行还包括:将针对多个SQL查询中的每一个的查询结果传输到一个或多个客户端,该一个或多个客户端向关系数据库管理系统传输了该SQL查询。
附图说明
通过参考以下描述和用于图示本发明的实施例的附图,可以最好地理解本发明。在附图中:
图1是根据一个实施例的针对具有时态关系数据库的关系数据库管理系统(RDBMS)中的查询计划生成和执行的流程图。
图2是根据一个实施例的图示了关系数据库管理系统的框图。
图3A图示了根据一个实施例的在时间T=0处的名为“CUSTOMERS(客户)”的示例性时态表。
图3B图示了根据一个实施例的在时间T=0处的名为“ORDERS(订单)”的示例性时态表。
图3C图示了根据一个实施例的示例性SQL查询。
图4图示了根据一个实施例的示例性SQL查询310的不同部分经由示例性文本表示440与示例性逻辑查询计划464的关系。
图5A图示了根据一个实施例的示例性文本表示440的不同部分与示例性物理查询计划的关系。
图5B图示了根据一个实施例的示例性物理查询计划564的执行。
图6图示了根据一个实施例的示例性重叠物理查询计划。
图7A是图示了根据一个实施例的、响应于时态关系数据库的时态表中的至少一个的修改而增量式地更新时态表的流程图。
图7B图示了根据一个实施例的相对于示例性物理查询计划564和示例性物理查询计划628的增量式执行和增量式更新。
图8是图示了根据一个实施例的重叠查询计划和增量式执行的组合的流程图。
图9是图示了根据一个实施例的高速缓存234的框图。
图10是图示了根据某些实施例的可以以其填充基本时态表的数据的方式的框图。
图11图示了根据一个实施例的RDBMS 212的顶部上的用户界面层。
图12是根据一个实施例的DTTN类的框图。
图13是根据一个实施例的BTTN类的框图。
图14是根据一个实施例的TT类的框图。
图15是根据一个实施例的图2的非查询执行器228的流程图。
图16是根据一个实施例的图2的查询计划连接器232的流程图。
图17是根据一个实施例的查询执行器240的流程图。
图18是根据一个实施例的评估方法1212的流程图。
图19是根据一个实施例的(一个或多个)方法1322的流程图。
图20是根据一个实施例的通知脏(notify dirty)的方法1220的流程图。
图21是根据一个实施例的订阅SQL查询的流程图。
图22是图示了根据一个实施例的具有附加块以支持非订阅和订阅SQL查询两者的关系数据库管理系统212的框图。
图23是根据一个实施例的订阅方法2222的流程图。
图24A是根据实现了拉模型的实施例的增量式更新方法2224的流程图。
图24B是根据实现了推模型的实施例的增量式更新方法2224的流程图。
图25是根据一个实施例的订阅更新方法2238的流程图。
图26图示了根据一个实施例的电子设备2604。
具体实施方式
以下描述描述了用于在具有时态关系数据库的关系数据库管理系统中的查询计划生成和执行的方法和装置。在以下描述中,阐述了众多具体细节,诸如资源划分/共享/复制实现方式、系统组件的类型和相互关系以及逻辑划分/集成选择,以便提供对本发明的更透彻的理解。然而,本领域技术人员将领会的是,可以在没有这种具体细节的情况下实践本发明。在其他实例中,未详细示出控制结构、逻辑实现方式、操作码、用以指定操作数的手段以及完整的软件指令序列,以免使本发明晦涩难懂。利用所包括的描述,本领域普通技术人员将能够在没有过度实验的情况下实现本发明。
说明书中对“一个实施例”、“实施例”、“示例实施例”等的引用指示所描述的实施例可以包括特定特征、结构或特性,但是每个实施例可能不一定包括该特定特征、结构或特性。而且,这种短语不一定指代同一个实施例。另外,当与实施例结合地描述特定特征、结构或特性时,所主张的是,结合其他实施例来实现这种特征、结构或特性处于本领域技术人员的知识范围内,不论是否明确地描述。
在本文中可以使用带有虚线边框(例如,大虚线、小虚线、点划线和点)的带括号的文本和框,来图示向一些实施例添加附加特征的可选操作和/或结构。然而,这种标记不应该被视为意味着这些是仅有的选项或可选操作和/或在某些实施例中具有实线边框的框不是可选的。
在以下描述和权利要求中,可以使用术语“耦合的”连同其派生词。“耦合的”被用来指示两个或更多个元素彼此合作或交互,这些元素可以或可以不直接物理或电接触。
将参考其他图的示例性实施例来描述流程图中的操作。然而,流程图的操作可以由除了参考其他图讨论的那些实施例之外的实施例来实行,并且参考这些其他图讨论的实施例可以实行与参考流程图所讨论的那些操作不同的操作。
术语“客户端”在本文中被用在若干个上下文中,包括指代“数据库客户端”(也被称为RDBMS客户端)、“BI客户端”和“最终用户客户端”。数据库客户端是RDBMS的客户端,而BI客户端是BI服务的客户端。最终用户客户端可以是数据库客户端,最终用户客户端可以是BI客户端(其中BI服务是数据库客户端),或者最终用户客户端可以是数据库客户端和BI客户端两者(其中BI服务是数据库客户端)。
概览
图1是根据一个实施例的具有时态关系数据库的关系数据库管理系统(RDBMS)中的查询计划生成和执行的流程图。在框100处,关系数据库管理系统接收多个结构化查询语言(SQL)查询,这些查询将需要从关系数据库管理系统管理的时态数据库的时态表访问数据。如上文讨论的,虽然时态表在逻辑上可以被认为是具有行和列的表,但是时态表的内容可以以不同的方式存储在存储器中(即,在易失性存储器、非易失性存储器和/或其组合中)(例如,模仿上面讨论的逻辑视图的“面向行”的组织(有时被称为“面向行”的时态表),“面向列”(也被称为“列式”)的组织(有时被称为“面向列”的时态表)等)。在一个实施例中,存储在时态表中的每个数据记录与如下一对时间戳相关联:第一时间戳(例如,被存储在对应于“valid_from”列的valid_from字段中),其对应于该记录有效的最早时间;以及第二时间戳(例如,被存储在对应于“valid_to”列的valid_to字段中),其对应于该记录有效的最晚时间(并且如果该时间尚且未知,则被设置为无穷大或INF)。尽管本文中相对于上文讨论的逻辑视图并且使用术语valid_to和valid_from列描述了实施例(如本领域中有时所做的那样),但是替代实施例可以不同地实现时态表(例如,以不同的方式存储时态表的内容(例如,使用面向行的组织、使用面向列的组织、针对一个或多个时态表使用面向行和面向列的组织两者、针对一个或多个时态表使用面向行的组织并且针对一个或多个其他时态表使用面向列的组织等),以另一种方式(例如,使用更多或更少的字段)存储数据记录的时间戳信息,通过不同的术语来指代时间戳信息,等等)。应当注意的是,框100中的多个SQL查询不需要被同时接收。控制从框100传递到框110。
在框110中,执行多个SQL查询中的SQL查询来生成针对每个查询的查询结果。在一个实施例中,该执行包括框120,接着是框130。框120包括:生成和执行在执行之后被保留在存储器中(即,在易失性存储器、非易失性存储器和/或其组合中)的多个查询计划,其中多个查询计划中的每一个包括通过边连接的节点的有向图。每一个有向图表示查询计划运算符的有序集合,该查询计划运算符在被执行时生成针对多个SQL查询中的一个的查询结果(也被称为“结果集合”),并且有向图的每一个节点表示查询计划运算符中的一个。由有向图的节点表示的每一个查询计划运算符表示要作为查询计划的部分实行的一种类型的操作。因此,如在这里使用的,“查询计划运算符”表示要作为查询计划的部分实行的一种类型的操作(例如,一种类型的关系操作(例如,PROJECT、SELECT、JOIN、TABLE(表)等)或其他类型的操作(例如,RENAME(重命名)等。))。当这种查询计划运算符表示时态表上的关系操作时,该操作被称为时态关系操作。有向图是其中边具有与之相关联的方向的图。每一个有向图内的节点都具有父子关系;即,将节点中的一个连接到节点中的另一个的边表示它们分别是相对于彼此的父节点和子节点,并且子节点的结果可由父节点访问。应当注意的是,多个SQL查询不需要同时在框110中执行。
在图示的示例中,SQL查询使得每一个有向图与另一个有向图共享其节点中的至少一个(每一个有向图通过它的至少一个边连接到另一个有向图的至少一个节点,以使得那些有向图共享至少一个节点。换言之,每一个有向图包括连接到另一个有向图的节点的边,使得至少该节点由这些有向图共享。因此,查询计划被连接(也被称为“重叠”),这是因为它们共享至少一个节点。查询计划还可以共享多于一个节点(例如,两个或更多个节点和一个或多个边的子图)。为了要有一个或多个共享节点,至少一个查询计划操作必须在多于一个查询计划中相同。一个实施例支持在生成和执行查询计划中的另一个之前,生成和执行查询计划中的一个。例如,在一个实施例中,有向图中的一个的生成和执行包括:将所生成的有向图中的一个的边连接到有向图中的较早生成的一个的节点,以使得所生成的有向图中的一个通过重新使用(更具体地,通过合并)至少有向图中的较早生成的一个的节点来与有向图中的该较早生成的一个共享至少该节点。因此,在第一查询计划已经被生成并且在执行之后被保留在存储器中的情况下,则第二查询计划的生成不需要创建那些已经处于第一查询计划中并且可以被共享的一个或多个节点(以及可能地,节点和(一个或多个)边的一个或多个子图),这是因为它们是相同的;第二查询计划的生成将重新使用(更具体地,“合并”)来自第一查询计划的一个或多个节点(以及可能地,一个或多个子图)中的相同的那些。
在图1中,SQL查询使得每一个有向图通过它的至少一个边连接到另一个有向图的至少一个节点(例如,需要这种查询计划的SQL查询已经被提交,并且查询计划同时在存储器中)。换言之,图1图示了一种能力,其取决于共享某些特征和定时的SQL查询和所得到的查询计划(SQL查询可以同时或在不同时间处被提交,但是查询计划同时在存储器中),如稍后在本文中描述的。尽管实施例具有该能力,但是实施例还支持在不同的时间点处具有:1)存储器中没有查询计划;2)执行之后在存储器中有一个查询计划;3)执行之后在存储器中有多个查询计划,但是每个查询计划都是独立的,因为它不与存储器中的查询计划中的另一个相连接(共享任何节点);4)执行之后在存储器中有多个查询计划,其中一个或多个是独立的,并且一组被连接;5)执行之后在存储器中有多组查询计划,其中每个组中的查询计划被连接,但是其中,在给定组中没有任何查询计划连接到另一个组中的查询计划(不同的组是独立的);等等。
附加地或替代地,一个实施例支持包括根节点的每一个有向图、以及未被共享根节点的至少一些有向图(换言之,所得到的查询计划使得这些特定有向图中的每一个的根节点不与另一个有向图共享)。附加地或替代地,一个实施例支持至少两个有向图,每个有向图包括根节点、至少一个或多个叶节点以及一个或多个中间节点;其中中间节点是具有一个或多个父节点和一个或多个子节点的节点(根节点连接到(一个或多个)中间节点中的至少一个,并且每一个中间节点连接到中间节点中的至少另一个或叶节点中的一个);并且这两个有向图至少共享中间节点及其后代节点中的一个。换言之,一个实施例支持共享节点和(一个或多个)边的子图的查询计划中的至少两个。附加地或替代地,一个实施例支持至少两个有向图,每个有向图包括根节点和一个或多个叶节点;并且这两个有向图中的第一个是第二个的子图(换言之,第一个图的根节点和中间节点是第二个的中间节点,并且第一个图的叶节点还是第二个的叶节点)。
每一个有向图的节点中的至少一个标识了时态数据库的时态表中的一个,并且每一个有向图的节点中的至少另一个标识了在执行之后被保留在存储器中并且被创建以存储执行该节点表示的查询计划运算符的结果的时态表。附加地或替代地,在一个实施例中,有向图共享的节点中的至少一个标识了在执行之后被保留在存储器中并且被创建以存储执行该节点表示的查询计划运算符的结果的时态表。附加地或替代地,有向图中的每一个节点标识了时态关系数据库的时态表中的一个,或者标识了被创建以存储执行该节点表示的查询计划运算符的结果的时态表中的一个。附加地或替代地,存储执行查询计划运算符中的一个的结果的每一个时态表在执行之后被保留在存储器中达与标识该时态表的节点在执行之后被保留在存储器中至少一样长的时间。附加地或替代地,在一个实施例中,查询计划在执行之后被保留在存储器中,使得有向图的节点和子图可用于潜在的重新使用。附加地或替代地,在一个实施例中,被创建以存储执行该节点表示的查询计划运算符的结果的每一个时态表在执行之后被保留在存储器中,以供潜在的重新使用。附加地或替代地,在一个实施例中,在第二查询计划包括与已经被执行的第一查询计划相同的查询计划操作(即,在具有(一个或多个)相同参数的相同输入时态表上进行操作的相同查询计划运算符)中的一个或多个的情况下,第二查询计划可以重新使用(根据需要增量式地更新)与第一查询计划一样的(一个或多个)时态表。增量式地更新时态表指代通过改变现有数据记录的时间戳和/或创建新数据记录来反映改变的上文描述的方式(与仅编辑或删除现有记录相对)。增量式地更新由节点标识的时态表指代响应于该节点表示的查询计划运算符被执行(无论它是增量式执行还是完全执行)来增量式地更新该时态表。当执行由节点表示的查询计划运算符是不必要的时候(例如,当存在指示执行可以被避免的优化时),增量式地更新由该节点标识的时态表可能是不必要的。因此,根据需要增量式地更新由节点标识的时态表指代:当不存在指示执行可以被避免的优化时(并且因此包括没有实现这种优化的实施例,或者是在实现了这种优化但是情形使得该优化并不允许执行和增量式更新被避免的实施例中),执行(无论它是增量式执行还是完全执行)该节点表示的查询计划运算符,并且增量式地更新该时态表。附加地或替代地,在一些实施例中,如果没有发生改变,则与现有查询计划共享节点的新提交的查询计划可以重新使用由所共享的节点标识的时态表,而无需对该节点表示的查询计划运算符的任何重新执行。然而,对查询计划运算符的输入时态表的改变可能需要该查询计划运算符被执行(增量式地或完全地执行)。
查询计划对节点的共享、以及查询计划和时态表在执行之后在存储器中的保留(特别地,其中每一个有向图的节点中的至少一个标识了在执行之后被保留在存储器中并且被创建以存储执行由该节点表示的查询计划运算符的结果的时态表)允许一些实施例支持近实时流式传输性能,包括在处理大量数据时。这部分地是因为:1)在执行之后将查询计划保留在存储器中并且使它们共享节点(在可能的情况下),并且因此共享这些所共享的节点标识的时态表,减少所需的存储器、计算资源和计算时间;以及2)使用时态表并且在执行之后将它们保留在存储器中允许某些实施例实现查询计划运算符中的一个或多个以实行“增量式执行”(仅对“Δ”执行;也被称为“增量式查询处理”和“增量式重新计算”),以根据需要增量式地更新由表示那些查询计划运算符的节点所标识的时态表(与查询计划运算符在对那些查询计划运算符的每一个时态表输入的整体上的重新执行/重新计算(在本文中被称为“完全重新执行”)相比,增量式执行减少了所需的计算资源和计算时间)。因此,如果具有作为(一个或多个)输入的一组一个或多个时态表的查询计划运算符的执行包括从那些时态表中的至少一个访问仅被增量式地插入和删除的数据记录(Δ,与全部数据记录相对),则该执行是“增量式的执行”。相反地,如果具有作为(一个或多个)输入的一组一个或多个时态表的查询计划运算符的执行需要从该组中的所有时态表访问所有的有效数据记录,则该执行是“完全执行”。给定的查询计划运算符可以被实现成实行增量式执行、完全执行或两者(并且在两者的情况下,其在可能的时候实行增量式执行)。附加地或替代地,在一个实施例中,框120中的生成和执行包括增量式地执行由两个有向图共享的节点中的一个所表示的至少查询计划运算符。例如,在已经生成和执行了第一查询计划并且其节点以及它们标识的时态表在执行之后被保留在存储器中的情况下,第二查询计划的生成不需要创建第二查询计划所需的、已经处于第一查询计划中的那些一个或多个节点(并且可能地节点和(一个或多个)边的一个或多个子图),这是由于那些节点可以被共享,并且第二查询计划的执行可以包括在需要更新的时态表上增量式地执行由那些所共享的节点表示的查询计划运算符。
框130包括将针对多个SQL查询中的每一个的查询结果传输到(一个或多个)客户端,该客户端向关系数据库管理系统传输了该SQL查询。术语“客户端”在这里指代RDBMS的客户端,并且因此这种客户端也可以被称为“数据库客户端”或“RDBMS客户端”。
附加地或替代地,在一个实施例中,生成和执行可以包括:作为生成有向图中的一个的部分:1)标识节点中的至少一个,节点中的该至少一个是有向图中的较早生成的一个的部分并且可以被重新使用(更具体地,被合并);以及2)将连接到节点中的作为有向图中的较早生成的一个的部分的一个节点的边添加到有向图中的一个。附加地,在一个实施例中,所添加的边连接到的节点中的一个可以是标识被创建以存储执行由该节点表示的查询计划运算符的结果的时态表的节点中的一个,并且其中生成和执行可以包括:作为执行有向图中的一个的部分,重新使用(包括根据需要增量式地更新)由所添加的边连接到的节点中的一个所标识的时态表。这比重新创建该时态表更高效;并且进一步地,如果需要更新,则当由该节点表示的查询计划运算符可以被增量式地执行时存在进一步的效率增益(与在该节点的子节点标识的整个时态表上重新执行由该节点表示的查询计划运算符相对(即,与完全重新执行相对))。替代地,在一个实施例中,生成和执行可以包括:1)标识可以作为当前正在生成的其他有向图的部分来重新使用的有向图中的已生成的有向图的部分;以及2)在生成其他有向图时重新使用那些所标识的部分,而不是重新创建那些所标识的部分。附加地,在一个实施例中,重新使用的部分可以包括节点中的一个或多个,它们标识了均被创建以存储执行由该节点表示的查询计划运算符的结果的时态表,并且其中生成和执行可以包括:重新使用(包括根据需要增量式地更新)由重新使用的部分的一个或多个节点标识的时态表。这比重新创建由重新使用的部分的一个或多个节点标识的一个或多个时态表更高效;并且进一步地,如果需要更新,则当由重新使用的部分的一个或多个节点表示的一个或多个查询计划运算符可以被增量式地执行时存在进一步的效率增益(与在该节点的每个子节点标识的时态表的有效行上重新执行这种节点的查询计划运算符(完全重新执行)相对)。
不同的实施例可以使用不同的技术来确定查询计划的(一个或多个)任何部分(节点和连接到其的边中的一个或多个)或整个查询计划、以及对应的时态表(TT)在执行之后被保留在存储器中达多长时间。对于每一个查询计划,有向图(或其(一个或多个)部分)的节点和边、以及对应的TT在执行之后被保留在存储器中:1)以用于在仍然需要它们时(例如,当任一个客户端要接收对针对其生成了该查询计划的SQL查询的更新时)进行可能的重新使用;和/或2)用以在生成和执行一个或多个其他查询计划时提供重新使用的机会。在执行之后将查询计划或其(一个或多个)部分保留在存储器中以提供该机会的时间长度可以基于一时间段,在有可能另一个查询计划的生成和执行可以重新使用(一个或多个)部分或整个查询计划(和对应的TT)的情况下利用所需的存储器被认为是有价值的(例如,固定时间段;可编程时间段;基于下述各项的所计算的时间量:(i)重新使用该查询计划中的一些或全部的可能性,(ii)在执行之后被保留在存储器中的节点和边(例如,基于节点与其他节点的连接性(connectedness)、节点的类型、它们的历史使用等,以平衡存储器消耗和重新使用的机会),(iii)其他SQL查询的到达率,和/或(iv)可用资源(例如,当存储器中的查询计划和对应的TT超出了存储器的阈值量时))。附加地或替代地,在一个实施例中,针对每一个查询计划维持“活动的”或“非活动的”标识(例如,该标识与每一个查询计划的有向图的根节点相关联),并且不是“活动的”查询计划的部分的那些节点(以及它们标识的TT)是用于从被保留在存储器中移除的候选项。不同的实施例可以不同地确定何时使指示是“不活动的”(例如,与该SQL查询相对应的连接已被关闭;提交该SQL查询的客户端已指示该查询不再受关注;固定或可编程的时间段已经过去)。而且,不同的实施例可以在不同时间处实行实际的移除(例如,在固定或可编程的时间段之后、当存储器中的查询计划和TT超过存储器的阈值量时作为正常垃圾收集操作的部分立即进行)。替代实施例可以放弃“活动的”和“非活动的”指示,并且检查客户端连接是否被关闭以确定任何对应的查询计划是否是用于移除的候选项。
附加地或替代地,在一个实施例中,有向图中的至少两个可以以根节点开始,包括一个或多个中间节点,并且在一个或多个叶节点中结束,并且每个有向图的根节点和一个或多个中间节点均针对该节点将该有向图的一个或多个其他节点标识为子节点。进一步地,由根节点和中间节点中的每一个表示的每一个查询计划运算符在该节点的一个或多个子节点标识的一个或多个时态表(或其视图或副本)上进行操作。附加地或替代地,在一个实施例中,由一个或多个叶节点中的每一个表示的查询计划运算符的执行导致从时态关系数据库中的时态表中的一个检索数据(例如,返回对该时态表(或其视图或副本)的引用)。附加地,在一个实施例中,由节点(例如,根节点和中间节点)表示一个或多个查询计划运算符中的一个或多个可以实行时态关系代数运算(时态关系代数运算是对时态表实行的关系代数运算)。
附加地或替代地,在一个实施例中,RDBMS被设计成一次支持多个(实际上是许多个)“重叠”的查询计划。存在各种原因导致要有多个重叠的查询计划。例如,某些用例需要其查询计划具有相对大的“查询深度”的SQL查询,其中给定查询计划的查询深度由根节点与叶节点之间的路径上的连续节点之间的边的最大计数来测量。虽然在一个实施例中,具有大查询深度的查询计划是包括具有多于10个节点的路径的查询计划,但是替代实施例可以使用50-100个节点范围内的阈值。生成具有相对大的查询深度的查询计划会导致相对大量的节点,并且因此有更大的重叠机会。进一步地,由于需要具有大查询深度的查询计划的SQL查询可能需要大量处理以便从头开始重做,因此数据库增量式地执行查询计划运算符的能力具有进一步改进效率的优势(例如,减少生成查询结果所需的时间、以及减少处理资源的功率要求、使处理资源可用于其他任务、允许数据库同时支持更多查询、减少存储器读/写操作的数量等)。作为具体的示例,在一个实施例中,关系数据库管理系统可以被用于复杂的分析或分析处理;需要其查询计划具有相对大的查询深度的SQL查询的用例。
如本文中所描述,实施例可支持增量式更新、懒惰更新、跳过更新(skippingupdate)及其组合。在支持增量式更新的一个实施例中,响应于修改时态表中的作为时态关系数据库的部分并且SQL查询需要从其中访问数据的至少给定的一个时态表的内容而实行下述各项:1)增量式地至少更新(在可能的情况下通过增量式执行)由标识该经修改的时态关系数据库表的节点的祖先所标识的时态表(增量式地更新由节点中的如下那些节点所标识的时态表中的那些时态表:那些节点属于针对SQL查询的查询计划的有向图并且直接或间接取决于标识了时态表中的该给定的一个时态表的节点);以及2)向提交了SQL查询的客户端传输对SQL查询的查询结果(被称为“增量式查询结果”)的增量式更新。在支持懒惰更新的实施例中,响应于修改了时态关系数据库的时态表中的一个的内容(并且SQL查询中的至少一个需要从其中访问数据),没有立即更新被创建以存储执行查询计划运算符的结果的TT。而是,更新被延迟直到发生一个或多个事件(例如,向客户端发送查询结果(例如,初始的或增量式)的需要、固定的时间流逝量、可编程的时间流逝量、基于节点和边(例如,基于节点与其他节点的连接性、节点的类型、它们的历史使用等)的所计算的时间量流逝、其他SQL查询的到达率超出阈值、和/或可用的计算资源落在阈值以下)以允许进行批处理,如果接收到其他修改的话。当执行由节点表示的查询计划运算符是不必要的时候(例如,当存在指示执行可以被避免的优化(诸如跳过更新)时),由该节点标识的时态表的增量式更新可能是不必要的。存在不同类型的跳过更新,并且实施例可以支持没有任何、一个或多于一个。所以附加地或替代地,一些实施例支持跳过更新优化,这可以避免执行由如下节点表示的查询计划运算符:1)所述节点不直接或间接取决于标识了自从被修改以来的时态表的节点;和/或2)所述节点已经在足够近期被执行(在本文中被称为在足够近期“被刷新”)(例如,这可能在支持并行执行查询计划和/或支持“截至一过去日期(as of a past date)”的查询执行的实施例中发生)。例如,在支持跳过更新优化的一些实施例中,响应于修改时态表中的作为时态关系数据库的部分并且SQL查询中的至少一个需要从其中访问数据的至少给定的一个时态表的内容,跳过由节点中的如下那些节点所表示的查询计划操作的执行(无论它是增量式执行或完全重新执行):那些节点作为正在执行的查询计划的部分并且不直接或间接取决于标识了时态表中的被修改的给定的一个时态表的节点。作为另一示例,在支持跳过更新优化的一些实施例中,当执行查询计划时,避免由作为正在执行的查询计划的部分并且已经在足够近期被执行(在这里被称为足够近期被刷新)的节点所表示的查询计划运算符的执行。因此,根据需要增量式地更新由节点标识的时态表指代:当不存在指示执行可以被避免的优化时(并且因此包括没有实现这种优化的实施例,或者是在实现了这种优化但是情形使得该优化并不允许执行和增量式更新被避免的实施例中),执行(无论它是增量式执行还是完全执行)该节点表示的查询计划运算符,并且增量式地更新该时态表。
附加地或替代地,在一个实施例中,框110中的SQL查询可以包括由关系数据库管理系统接收到的第一SQL查询和第二SQL查询。进一步地,框120中的生成和执行包括:生成针对第一SQL查询的第一查询计划和针对第二SQL查询的第二查询计划,并且针对第二查询计划的有向图通过它的至少一个边连接到针对第一查询计划的有向图的至少一个节点,以使得那些有向图共享至少一个节点。附加地或替代地,在一个实施例中,由针对第一和第二查询计划的有向图共享的至少一个节点是被创建以存储执行由该节点表示的查询计划运算符的结果的节点。附加地或可替代地,在一个实施例中,第二查询计划的生成和执行包括:增量式地执行由针对第一和第二查询计划的有向图共享的至少一个节点所表示的至少查询计划运算符。附加地或替代地,第一SQL查询和第二SQL查询由关系数据库管理系统接收到,以分别填充第一仪表板内容元素和第二仪表板内容元素。附加地,在一个实施例中,第一和第二仪表板内容元素可以是要由不同最终用户客户端显示的不同仪表板的部分。替代地,在一个实施例中,第一和第二仪表板内容元素可以是要显示的相同仪表板的部分。
一些实施例附加地或替代地支持订阅SQL查询,该订阅SQL查询是客户端可以针对其接收对查询结果的更新的SQL查询。在一个实施例中,当客户端提交订阅SQL查询时,RDBMS最初向客户端传输表示当最初执行订阅SQL查询时的数据的初始查询结果。此后,RDBMS可以将对那些查询结果的任何更新传输到该客户端,这些更新是由于订阅SQL查询需要从其中访问数据的时态关系数据库的任何时态表的内容的(一个或多个)修改而引起的。在一个实施例中,针对订阅SQL查询的查询计划(以及由查询计划的节点标识的时态表)在执行之后被保留在存储器中,至少直到提交了该订阅SQL查询的客户端提交针对该订阅SQL查询的关闭订阅消息为止。由此,如果RDBMS接收另外的SQL查询,则订阅SQL查询的使用会增加对于存在多个重叠查询计划的机会(即,对于之后生成的查询计划与现有查询计划重叠的机会增加,现有查询计划在执行之后被保留在存储器中达更长时间)。在某些情况下,针对订阅SQL查询的查询计划的重新使用可以包括增量式地执行由该查询计划的一个或多个节点表示的查询计划运算符中的一个或多个,以增量式地更新那些一个或多个节点标识的现有时态表(与完全重新执行相对)。支持SQL查询和订阅SQL查询两者的不同实施例可以使用不同的技术来区分这两者(例如,订阅SQL查询之前可以加上短语/前缀,诸如“订阅”)。此外,在仅支持订阅SQL查询的一个实施例中,RDBMS将每个提交的SQL查询视为订阅SQL查询,并且不需要这种短语/前缀。在一个实施例中,框110中的SQL查询可以包括作为订阅SQL查询的第一SQL查询,并且框120包括生成针对第一SQL查询的第一查询计划。进一步地,框110中的SQL查询可以包括第二SQL查询,该第二SQL查询是在生成了第一SQL查询计划之后并且在第一查询计划由于其是订阅SQL查询而在执行之后被保留在存储器中时被接收到的。短语“用于可能的重新使用”意味着在执行之后将现有查询计划的节点(以及它们标识的时态表)保留在存储器中,使得实施例可以支持下述各项中的一项或多项:1)将那些(一个或多个)现有查询计划(或那些(一个或多个)现有查询计划中的一个或多个)的一个或多个部分(节点和/或子图)合并到当前正在生成的查询计划中;2)当节点中的至少一个已经被这样合并时,在可能的情况下按原样使用该节点标识的时态表(与要求对标识该时态表的节点所表示的查询计划操作进行任何重新执行相对);3)当节点中的至少一个已经被这样合并时,增量式地执行该节点表示的查询计划运算符,以增量式地更新该节点标识的现有时态表(与完全重新执行相对);4)当节点中的至少一个已经被这样合并时,完全重新执行该节点表示的查询计划运算符,以增量式地更新该节点标识的现有时态表;5)当针对订阅SQL查询的现有查询计划的叶节点表示的时态表的内容被更新时,重新使用该现有查询计划;和/或6)当针对订阅SQL查询的现有查询计划的叶节点表示的时态表的内容被更新时,增量式地执行该现有查询计划的节点表示的查询计划运算符中的至少一个,以增量式地更新存储了该查询计划运算符的结果的现有时态表(与完全重新执行相对)。
图2是图示了根据一个实施例的关系数据库管理系统的框图。图2被划分成客户端侧200和服务器侧210。客户端侧200包括一个或多个客户端(未示出),每个客户端包括(一个或多个)数据库驱动器204(也被称为远程过程调用(RPC)模块)中的一个、以及本领域已知的其他组件(未示出)。
服务器侧210包括关系数据库管理系统(RDBMS)212。RDBMS 212包括时态关系数据库262,客户端在其中存储数据并且客户端从其中检索数据。RDBMS 212包括根据在RDBMS中常见的组件命名的组件(例如,Joseph M. Hellerstein,Michael Stonebraker和JamesHamilton,“Architecture of a Database”,Foundations and Trends in Databases,第一卷1,第2号(2007),第141-259页;Joseph M. Hellerstein和Michael Stonebraker,“Anatomy of a Database”,Readings in Database Systems,第四版,MIT出版社(2005),第42-95页),诸如过程和客户端通信管理器(PCCM)214、解析器218、查询重写器224、查询优化器230和查询执行器240(也被称为执行器或查询计划执行器)。术语“查询处理器”有时被用来指代解析器218、查询重写器224、查询优化器230和查询执行器240的组合。关于图1,在一个实施例中,PCCM 214实行框100和130,并且查询处理器实行框110的其余部分(查询优化器230和查询执行器240的组合实行框120)。
过程和客户端通信管理器214(在一些实施例中,其被实现为单独的管理器;并且有时也仅被称为过程管理器)可以实行各种各样的任务,包括:1)建立和存储针对(一个或多个)客户端的连接状态,响应于以SQL语句216的形式的客户端请求,并且返回查询结果217;和/或2)封装和调度RDBMS 212的各种任务(包括实行准入控制)。在(一个或多个)客户端的(一个或多个)数据库驱动器204与过程和客户端通信管理器214之间建立连接。(一个或多个)数据库驱动器204将SQL语句216提交给PCCM 214。
PCCM 214将SQL语句216提供给解析器218。在一个实施例中,解析器218的任务包括:将SQL语句216转换成内部表示220(例如,抽象语法树(AST))。决策框222图示了将SQL语句216中的是SQL查询的那些与不是SQL查询的那些区分开。决策框222是虚线的,这是因为该决策可以在RDBMS 212中的一个或多个不同位置处(例如,在其图示的位置处、和/或在查询优化器230与查询执行器240之间、和/或作为查询执行器240的部分)进行。在所图示的位置处,内部表示220中的从作为SQL查询的SQL语句216生成的那些被提供给查询重写器224,而不是SQL查询的那些被提供给非查询执行器228。
查询重写器224将SQL查询的内部表示220简化和规范化,以产生被提供给查询优化器230的重写的内部表示226(例如,表示查询字符串的结构和内容的重写的AST)。尽管查询重写器224被图示为单独的组件,但是在一些实施例中,它是解析器218或查询优化器230的部分,如在某些商业RJDBMS中那样。
查询优化器230从重写的内部表示226生成查询计划(其可以包括实行查询计划优化)。在一些实施例中,对于重写的内部表示226中的每一个,查询优化器230在物理查询计划242中创建“物理查询计划”(也被称为“完全指定的查询计划”)之前首先创建“逻辑查询计划”(之后在本文中进一步描述)。不同的实施例可以以不同的方式生成逻辑查询计划,该不同的方式包括本领域中公知的那些方式(例如,Van den Bussche,J.,Vansummeren,S.,Translating SQL into the Relational Algebra,其在2016年10月检索的网址https://cs.ulb.ac.be/public/_media/teaching/infoh417/sql2alg_eng.pdf处可得;Kifer,M.等人,Database Systems:Application Oriented Approach,完整版本-第2版,ISBN-13:978-0321268457, 2005年3月26日)。例如,在一个实施例中,通过遍历AST并且从AST创建对应于查询计划运算符(例如,对于“select”语句为PROJECT,对于“where”子句(clause)为JOIN或SELECT等)的节点来从重写的内部表示创建逻辑查询计划。
查询执行器240执行与SQL查询相对应的物理查询计划242,这包括从时态关系数据库262中的指定时态表访问指定数据,实行由那些物理查询计划指定的查询计划操作,并且将结果提供给过程和客户端通信管理器214;客户端进而将那些结果(被示为查询结果217)提供给提交了相应SQL查询的客户端中的相应的一个。
每一个物理查询计划242包括通过边连接的节点的有向图,其中每一个有向图表示查询计划运算符的有序集合,该查询计划运算符在被执行时提供针对SQL查询的查询结果。查询优化器230包括查询计划连接器232。在一个实施例中,对于每一个逻辑查询计划,查询计划连接器232确定是否可以通过重新使用已经处于在执行之后当前被保留在存储器中(即,在易失性存储器、非易失性存储器和/或其组合中)的物理查询计划242中的节点和/或子图(以及在一些实施例中,整个有向图)中的一个或多个或者将其合并到所需的物理查询计划中来生成所需的物理查询计划。如果查询计划连接器232确定:对于给定的逻辑查询计划,重新使用或合并是可能的,则只有针对物理查询计划的(一个或多个)缺失部分(如果有的话)(无论它是一个或多个节点、边和/或子图)被添加到物理查询计划242,并且通过一个或多个边连接到被确定为可重新使用的一个或多个节点和/或子图(以及在一些实施例中,整个有向图)。查询计划连接器232的操作可以结合查询计划优化、在查询计划优化之后(在经优化的查询计划上)或两者来实行。
在一个实施例中,查询计划连接器232包括高速缓存234(也被称为节点密钥到节点高速缓存),以将节点密钥到对应节点的映射存储在物理查询计划242中。在一个实施例中,物理查询计划242中的每一个节点具有在高速缓存234中的条目,并且针对每一个节点的条目存储节点密钥以及被用来在物理查询计划242中定位该节点的引用。可以通过各种各样的方式(例如,指针、索引、句柄、密钥、标识符等)来实现被用来定位数据结构(例如,节点)的“引用”。节点密钥使得查询计划连接器232可以针对逻辑查询计划的每个节点做出上文讨论的确定(是否可以通过重新使用或合并已经处于在执行之后当前被保留在存储器中的物理查询计划242中的节点、子图和/或整个有向图中的一个或多个来生成所需的物理查询计划。附加地或替代地,在一个实施例中,不管高速缓存234中存储了什么,都创建逻辑查询计划,并且然后使用该逻辑查询计划来根据需要产生节点密钥,以用于与已经处于高速缓存234中的节点密钥进行比较;其中高速缓存命中意味着该条目中引用的节点可以被重新使用/合并。尽管描述了其中将图的边存储在图的节点内的实施例,但是替代实施例可以代替地将边存储在高速缓存234中。
在一个实施例中,查询优化器230还包括查询编译器236,查询编译器236将查询计划编译成机器代码或可解释的查询计划(以使得能够实现跨平台的可移植性,并且其可以是轻量级的(例如,带注释的关系代数表达式)或采用较低级别的语言(例如Java字节代码))。
物理查询计划242中的有向图的每一个节点表示物理查询计划242的查询计划运算符中的一个。物理查询计划242的节点可以被称为“节点”或“物理查询计划节点”(PQPN)。
进一步地,每一个有向图的节点中的至少一个标识了在执行之后被保留在存储器中(即,在易失性存储器、非易失性存储器和/或其组合中)并且被创建以存储执行由该节点表示的查询计划运算符的结果的时态表,并且每一个有向图的节点中的至少一个标识了时态关系数据库262中的时态表中的一个。附加地或替代地,在一个实施例中,有向图共享的节点中的至少一个标识了在执行之后被保留在存储器中并且被创建以存储执行该节点所表示的查询计划运算符的结果的时态表。附加地或替代地,在一个实施例中,物理查询计划在执行之后被保留在存储器中,使得有向图的节点和子图可用于潜在的重新使用。附加地或替代地,在一个实施例中,被创建以存储执行由该节点表示的查询计划运算符的结果的每一个时态表在执行之后被保留在存储器中,以供潜在的重新使用。附加地或替代地,在一个实施例中,在第二查询计划包括与已经被执行的第一查询计划相同的查询计划操作(即,在具有(一个或多个)相同参数的相同输入时态表上进行操作的相同查询计划运算符)中的一个或多个的情况下,第二查询计划可以重新使用(根据需要增量式地更新)与第一查询计划一样的(一个或多个)时态表。附加地或替代地,在一个实施例中,有向图中的一个的生成包括:1)标识节点中的至少一个,节点中的该至少一个是有向图中的较早生成的一个的部分并且可以被重新使用;以及2)将连接到节点中的作为有向图中的较早生成的一个的部分的一个节点的边添加到有向图中的一个。附加地,在一个实施例中,所添加的边连接到的节点中的一个可以是标识被创建以存储执行由该节点表示的查询计划运算符的结果的时态表的节点中的一个,并且其中有向图中的一个的执行可以包括:重新使用(包括根据需要增量式地更新)由所添加的边连接到的节点中的一个所标识的时态表。这比重新创建该时态表更高效;并且进一步地,如果需要更新,则当由该节点表示的查询计划运算符可以被增量式地执行时存在进一步的效率增益(与在该节点的每个子节点标识的时态表的有效行上重新执行由该节点表示的查询计划运算符(完全重新执行)相对)。替代地,在一个实施例中,生成可以包括:1)标识可以作为当前正在生成的其他有向图的部分来重新使用的有向图中的已生成的有向图的部分;以及2)在生成其他有向图时重新使用那些所标识的部分,而不是重新创建那些所标识的部分。附加地,在一个实施例中,重新使用的部分可以包括节点中的一个或多个,它们标识了被创建以存储执行由该节点表示的查询计划运算符的结果的时态表,并且其中执行可以包括:重新使用(包括根据需要增量式地更新)由重新使用的部分的一个或多个节点标识的时态表。这比重新创建由重新使用的部分的一个或多个节点标识的一个或多个时态表更高效。并且进一步地,如果需要更新,则当由重新使用的部分的一个或多个节点表示的一个或多个查询计划运算符可以被增量式地执行时存在进一步的效率增益(与在该节点的每个子节点标识的时态表的有效行上重新执行这种节点的查询计划运算符(完全重新执行)相对)。
附加地或替代地,在一个实施例中,有向图的每一个节点标识了时态关系数据库的时态表中的一个,或者标识了被创建以存储执行该节点表示的查询计划运算符的结果的时态表中的一个。附加地或替代地,在一个实施例中,每一个有向图以根节点开始,可以包括一个或多个中间节点,并且在一个或多个叶节点中结束,其中每个有向图的根节点和一个或多个中间节点中的每一个均针对该节点将该有向图的一个或多个其他节点标识为子节点。附加地或替代地,由根节点和中间节点中的每一个表示的每一个查询计划运算符在该节点的一个或多个子节点标识的一个或多个时态表(或其副本或视图)上进行操作。附加地或替代地,在一个实施例中,由一个或多个叶节点中的每一个表示的查询计划运算符的执行导致从时态关系数据库262中的时态表中的一个检索数据。附加地或替代地,在一个实施例中,针对物理查询计划242的每一个节点,在高速缓存234中维持的节点密钥基于该节点以及该节点的零个或多个所标识的子节点。在另一实施例中,针对物理查询计划242的根节点和中间节点中的每一个,在高速缓存234中维持的节点密钥基于该节点以及该节点的所标识的子节点。在又一实施例中,针对物理查询计划242的每一个节点,在高速缓存234中维持的节点密钥仅表示包括该节点及其后代(子节点、孙节点等)(如果有的话)的查询计划的那部分,但是不表示该节点的任何祖先节点(父节点、祖父节点等)表示的查询计划的任何部分。在一个实施例中,针对物理查询计划242的根节点和中间节点中的每一个,在高速缓存234中维持的节点密钥基于该节点以及该节点的所标识的子节点(如果有的话)的密钥。
在图2的实施例中,每一个时态表(TT)由一对象封装,并且这些对象被划分成:处于时态关系数据库262中的基本时态表(BTT)260、以及存储执行由每一个节点表示的查询计划运算符的结果的所导出的时态表(DTT)264。如上面讨论的,不同的实施例可以以不同的方式将TT的内容存储在存储器中(即,在易失性存储器、非易失性存储器和/或其组合中)(例如,可以使用列式(也被称为面向列的)组织、使用面向行的组织、针对一个或多个时态表使用面向行和面向列的组织两者、针对一个或多个时态表使用面向行的组织并且针对一个或多个其他时态表使用面向列的组织等来存储内容)。尽管在一个实施例中,BTT 260和DTT 264被保留在具有相对快的读写时间的存储器(例如,动态随机存取存储器(DRAM)、静态随机存取存储器(SRAM)和/或相变存储器)中(即,在易失性存储器、非易失性存储器和/或其组合中),在替代实施例中,BTT 260和/或DTT 264中的一些可以存储在具有相对较慢的读写时间的存储器(例如,闪存、SSD、磁盘)中。
在一些实施例中,物理查询计划242的物理查询计划节点(PQPN)被称为“时态表节点”(TTN),并且被划分成所导出的时态表节点(DTTN)244和基本时态表节点(BTTN)246。BTTN 246指代物理查询计划242的有向图的叶节点(并且因此指代“对数据库客户端可见”的时态表,这是因为它们可以在数据库客户端发布给系统的SQL查询中被引用),而DTTN244指代物理查询计划242的有向图的(一个或多个)根节点和(一个或多个)中间节点(并且因此指代“对数据库客户端不可见”的时态表)。尽管在一些实施例中,术语BTTN和DTTN仅仅将作为叶节点的PQPN与作为根节点或中间节点的PQPN区分开(例如,使用相同的面向对象的类来实现BTTN和DTTN),但是在其他实施例中,术语BTTN和DTTN还区分实现的方式(例如,针对BTTN和DTTN使用不同的面向对象的类)。尽管在一个实施例中,每一个PQPN包括被用来定位BTT 260中的对应的一个或DTT 264中的对应的一个的引用(例如,PQPN 252A-N中的每一个是BTTN,并且包括被用来定位BTT 254A-M中的对应的一个的引用,而PQPN 250A-R中的每一个是DTTN,并且包括被用来定位DTT 258A-R中的对应的一个的引用),替代实施例可以以另一方式存储这些对应关系(例如,使用一个或多个其他数据结构来存储这些对应关系)。如图2中的省略号所图示的那样,预计有时将会存在充当中间节点和根节点的许多DTTN 244(也被称为更高级别的DTTN)。因此,作为DTTN 244的每一个PQPN具有一个或多个边,这些边将其连接到作为子节点的相应的一个或多个其他PQPN;而在一个实施例中,作为DTTN 244的每一个PQPN包括被用来定位一个或多个其他PQPN的(一个或多个)引用(其中,每个这种引用形成了从PQPN到作为子节点的一个或多个其他PQPN中的相应的一个的边),替代实施例可以以另一方式存储这些边(例如,使用一个或多个其他数据结构来存储这些边)。典型地,PQPN 250A-R中的一些将具有将其连接到PQPN 252A-N(BTTN)中的对应的一个的边,而PQPN 250A-R中的一些将具有将其连接到一个或多个其他PQPN 250A-R(其他DTTN)的(一个或多个)边。某些实施例还支持具有作为子节点的一个或多个其他DTTN和一个或多个BTTN的DTTN。
非查询执行器228可以执行INSERT(插入)操作(即,将一个或多个数据记录插入在时态关系数据库的时态表中)、UPDATE(更新)操作(即,通过插入新数据记录并且改变经修改的数据记录的(一个或多个)时间戳(例如,将valid_to列值设置成更新时间)来改变时态关系数据库的一个或多个时态表中的一个或多个数据记录的内容)、DELETE(删除)操作(即,通过改变“已删除”的数据记录的(一个或多个)时间戳(例如,将valid_to列值设置成更新时间)来删除时态关系数据库的一个或多个时态表中的一个或多个数据记录)、以及可选地执行通过添加数据记录、删除数据记录和/或改变现有数据记录的内容来修改时态表的内容的其他操作;以及至少执行CREATE TABLE(创建表),以及可选地执行不改变时态表的内容而是改变时态表本身(例如,模式)的其他数据定义语言(DDL)操作。在具有BTTN 246的实施例中,非查询执行器228与BTTN 252A-N对接,BTTN 252A-N进而对它们在BTT 254A-M中的对应的一个实行这些操作。
如从BTT 254到PQPN 252的弯曲箭头所图示的,PQPN 252A-N中的每一个有权访问其在BTT 254A-M中的对应的一个。如从PQPN 252A-N到不同的PQPN 250A-R的弯曲箭头所图示的,PQPN 250A-R中的一些有权访问由PQPN 252A-N引用的BTT 254A-M(例如,PQPN 250A有权访问由PQPN 252A引用的BTT 254A)。PQPN 250A-R中的任何更高级别的一个有权访问由它们的子PQPN 250引用的DTT 264。因此,将节点中的一个连接到节点中的另一个的边表示它们分别是相对于彼此的父节点和子节点,并且子节点的结果可由父节点访问。尽管在一个实施例中,该访问以子节点的形式将对该子节点的DTT/BTT的只读视图或只读副本的引用传递给父节点,并且父节点然后使用该引用来访问从TT中需要的记录(在各情况下,是时态表中的仅一些而不是全部的数据记录;在其他情况下,是整个表);替代实施例可以被不同地实现(例如,它们可以传递整个TT)。
在一个实施例中,RDBMS操作在没有查询计划(逻辑或物理的)或TT被保留在存储器中(即,物理查询计划242、BTT 260和DTT 264为空或未被实例化)、以及高速缓存234为空或未被实例化的情况下开始。响应于SQL语句216中的一个或多个CREATE TABLE语句,创建一个或多个叶节点(例如,BTTN 246)和对应的TT(例如,BTT 260)。响应于接收到第一SQL查询,生成和执行第一物理查询计划,并且将查询结果返回到提交了第一SQL查询的客户端。第一物理查询计划的生成包括生成必要的有向图,这包括创建一个或多个必要的中间节点和根节点(例如,DTTN 244),并且添加必要的边(如上所描述,尽管在一个实施例中,可以通过将对该父节点的(一个或多个)子节点的(一个或多个)引用存储在充当父节点的每一个PQPN中来存储这些边,但是替代实施例可以以另一方式来存储这些边(例如,使用一个或多个其他数据结构来存储这些边))。该有向图在执行之后被保留在存储器中达至少一段时间,以供潜在的重新使用。进一步地,针对有向图中的每一个节点,利用节点密钥和节点引用对(其中节点密钥与节点引用相关联)来填充高速缓存234。第一物理查询计划的执行包括实行由有向图的每一个节点(DTTN 244)指定的查询计划操作,这包括访问任何(一个或多个)子节点的TT,实行查询计划操作、以及填充每个节点的对应TT(例如,DTT 264中的一个)。使用由有向图的根节点引用的TT(例如,DTT 264中的一个)来提供查询结果。
继续该示例,响应于接收到第二SQL查询,生成和执行第二物理查询计划,并且将查询结果返回到提交了第二SQL查询的客户端。然而,第二物理查询计划的生成不需要创建已经处于第一物理查询计划中并且可以被共享的那些一个或多个节点(以及可能地节点和(一个或多个)边的一个或多个子图),这是因为它们是相同的;第二查询计划的生成重新使用(也被称为“合并”)来自第一物理查询计划的一个或多个节点(以及可能地一个或多个子图)中的相同的那些。参考图2,查询计划连接器232确定是否可以通过重新使用/合并已经处于在执行之后当前被保留在存储器中的物理查询计划242中的节点和/或子图(以及在一些实施例中,整个有向图)中的一个或多个来生成所需的第二物理查询计划。如果查询计划连接器232确定重新使用/合并是可能的,则只有针对第二物理查询计划的(一个或多个)缺失部分(无论它是节点和边、子图等)被添加到物理查询计划242,并且通过一个或多个边连接到被确定为可重新使用的一个或多个节点和/或子图(以及在一些实施例中,整个有向图)。如上所描述,在一个实施例中,查询计划连接器232针对第二SQL查询和高速缓存234(其先前响应于生成第一物理查询计划而被填充)中的节点密钥来利用逻辑查询计划。在实行这种重新使用/合并的情况下,第一和第二SQL查询使得每一个有向图通过它的至少一个边连接到另一个有向图的至少一个节点,使得那些有向图共享至少一个节点。因此,查询计划被连接(也被称为“重叠”),这是因为它们共享至少一个节点,并且可以共享更多个(例如,两个或更多个节点和一个或多个边的子图)。在另一方面,如果查询计划连接器232确定重新使用/合并是不可能的,则针对第二物理查询计划的有向图的节点和边被添加到物理查询计划242。
如上文讨论的,物理查询计划对节点(包括中间节点以及可能地根节点)的共享、以及物理查询计划和时态表(特别是由执行查询计划运算符的每一个有向图中的那些节点填充的TT(例如,由DTTN 244引用的DTT 264))在存储器中的保留允许一些实施例支持近实时流式传输性能,包括在处理大量数据时。再次,这部分地是因为:1)在执行之后将物理查询计划保留在存储器中并且使它们共享节点(在可能的情况下),并且因此共享这些所共享的节点标识的时态表,减少所需的存储器、计算资源和计算时间;以及2)使用时态表并且将它们保留在存储器中允许某些实施例实现查询计划运算符中的一个或多个以实行“增量式执行”(仅对“△”执行;也被称为“增量式查询处理”和“增量式重新计算”),以根据需要增量式地更新表示那些查询计划运算符的节点所标识的时态表(与查询计划运算符在对那些查询计划运算符的每一个时态表输入的整体上的重新执行/重新计算(在本文中被称为“完全重新执行”)相比,增量式执行减少了所需的计算资源和计算时间。因此,附加地或替代地,在一个实施例中,第二查询计划的生成和执行可以包括:增量式执行由处于第一查询计划的有向图中并且与第二查询计划的有向图共享的节点中的一个表示的至少查询计划运算符。
图2中在PCCM 214、解析器218、查询重写器224、查询优化器230、查询执行器240和非查询执行器228之间的箭头线表示某种类型的耦合,诸如数据流和/或连接。例如,在一些实施例中,PCCM 214调用解析器218、查询重写器224、查询优化器230、查询执行器240和非查询执行器228中的每一个以协调SQL语句216的执行,并且因此箭头线表示与例如解析器218调用查询重写器224相反的次序。
如前所描述,不同的实施例可以使用不同的技术来确定查询计划的每一个节点和每一个TT在执行之后被保留在存储器中达多长时间。在一个实施例中,针对每一个查询计划维持“活动的”或“非活动的”标识(例如,该标识可以与每一个查询计划的有向图的根节点相关联),并且不是“有效”查询计划的部分的那些节点(以及它们引用的TT)是用于从被保留在存储器中移除的候选项。作为具体示例,Java开发工具包(“JDK”)提供了“弱引用”通用类型。与如果使用了默认Java引用(被称为“强引用”)的情况相比,这种类型的实例允许Java虚拟机垃圾收集器更积极地释放基础对象的存储器。在用Java实现的一个实施例中,高速缓存234中的对根节点和叶节点的引用属于强引用类型,而高速缓存234中的对中间节点的引用属于弱引用类型;并且一旦高速缓存234中的给定根节点被释放,Java虚拟机垃圾收集器就可以释放从该根节点延伸的有向图所消耗的存储器。因此,在高速缓存234中的针对根节点的强引用指示了从那些根节点开始的查询计划是“活动的”,并且当这种根节点被释放时,以该根节点开始的查询计划切换为“不活动的”。
示例
图3A图示了根据一个实施例的在时间T=0处的名为“CUSTOMERS(客户)”的示例性时态表。图3B图示了根据一个实施例的在时间T=0处的名为“ORDERS(订单)”的示例性时态表。图3A-B的时态表包括:valid_from列,其每个字段对应于对应数据记录有效的最早时间(也可被称为valid_from时间戳);以及valid_to列,其每个字段对应于数据记录有效的最晚时间(并且如果该时间尚且未知,则被设置为无穷大或INF)(也可被称为valid_to时间戳)。如先前描述的,尽管在本文中相对于上文讨论的逻辑视图并且使用术语valid_to和valid_from列描述了实施例(如本领域中有时所做的那样),但是替代实施例可以不同地实现时态表(例如,以不同的方式存储时态表的内容(例如,可以使用面向行的组织、使用面向列的组织、针对一个或多个时态表使用面向行和面向列的组织两者、针对一个或多个时态表使用面向行的组织并且针对一个或多个其他时态表使用面向列的组织等来存储内容),以另一方式(例如,使用更多或更少的字段)来存储数据记录的时间戳信息,通过不同的术语来指代时间戳信息等)。
在图3A中,其他列被命名为“客户ID”、“姓名”和“邮政编码”。在图3B中,其他列被命名为“订单ID”、“客户ID”、“价格”和“数量”。由于在两个时态表中都找到了“客户ID”,因此,它可以作为用于关联两个时态表的密钥来操作,如本领域中已知的那样。在时间T=0处,每一个时态表的内容包括两个数据记录。
图3C图示了根据一个实施例的示例性SQL查询。具体地,示例性SQL查询310是“从CUSTOMERS、ORDERS选择*,其中ORDERS.客户ID=CUSTOMERS.客户ID并且CUSTOMERS.邮政编码=10001并且ORDERS.数量>4”。
图4图示了根据一个实施例的示例性SQL查询310的不同部分经由示例性文本表示440与示例性逻辑查询计划464的关系。图4图示了作为单独元素的示例性SQL查询310如下:“选择”402;“*”404;“从”406;“CUSTOMERS”408;“ORDERS”410;“其中”412;“ORDERS.客户ID”414;“=”416;“CUSTOMERS.客户ID”418;“并且”420;“CUSTOMERS.邮政编码”422;“=”424;“10001”426;“并且”428;“ORDERS.数量”430;“>”432;以及“4”434。
如上所描述,一些实施例生成逻辑查询计划。在一个实施例中,针对SQL查询(例如,示例性SQL查询310)的逻辑查询计划(例如,示例性逻辑查询计划464)是由节点(在本文中被称为“逻辑查询计划节点”(LQPN))和连接那些节点的边)组成的有向图,如本领域中已知的那样。有向图以根逻辑查询计划节点(例如,根LQPN 470A)开始,包括零个或多个中间LQPN(例如,中间LQPN 470B-D),并且在一个或多个叶LQPN(例如,叶LQPN 470E-F)中结束。
示例性文本表示440(其是作为字符串被写出以形成示例性查询计划的人类可读版本的示例性SQL查询计划310的节点)是出于解释的目的,并且不需要由某些实施例生成。进一步地,替代实施例可以针对示例性SQL查询310生成与示例性文本表示440所表示的查询计划不同的查询计划。
示例性文本表示440包括多个类型的“查询计划运算符”(例如,PROJECT、SELECT、JOIN和TABLE)以及它们的“参数”。每个LQPN 470 A-F的“查询计划运算符类型”(或“运算符类型”)标识了LQPN可以标识的多个类型的查询计划运算符中的特定一个。对于查询计划运算符中的一个或多个,一些实施例具有多种不同的实现方式;并且一些这种实施例可以被配置成使得“运算符类型”标识查询计划运算符中的特定一个以及该查询计划运算符的实现方式中的特定一个,而其他这种实施例可以被配置成使得“运算符类型”在不参考特定实现方式的情况下标识查询计划运算符中的特定一个。PROJECT和TABLE查询计划运算符两者有效地返回它们在其上操作的时态表(输入时态表)的数据记录。
示例性SQL查询310的“从”406子句的时态表“CUSTOMERS”408和“ORDER”410分别被映射到LQPN 470F和LQPN 470E,它们分别表示示例性文本表示440中的“TABLE(CUSTOMERS)”456和“TABLE(ORDERS)”448。
比较谓词是对时态表的列的引用(例如,“ORDER.数量”430)、比较运算符(例如,=、>、<)、以及对表的列的另一引用、文字(literal)(例如,“4”434)或表达式(例如,“10001+1”)的组合。在一个实施例中,如果比较谓词具有形式“<column reference> <comparisonoperation> <literal>”,则将该比较谓词映射到SELECT。这将包括比较谓词“ORDERS.数量> 4”480和比较谓词“CUSTOMERS.邮政编码=10001”482,它们分别被映射到LQPN 470C和LQPN 470D,其中LQPN 470C表示关于其子LQPN 470E(其实行“TABLE(ORDERS)”448)的结果、以及比较谓词“,ORDERS.数量>4)”450的“SELECT(”446(操作490),并且其中LQPN 470D表示关于其子LQPN 470F(其实行“TABLE(CUSTOMERS)”456)的结果、以及比较谓词“,COSTOMERS.邮政编码=10001”458的“SELECT(”454(操作492)。
在一个实施例中,如果比较谓词具有形式“<column reference> = <columnreference>,则将该比较谓词映射到JOIN。这将包括比较谓词“ORDERS.客户ID =CUSTOMERS.客户ID”484,其被映射到LQPN 470B,LQPN 470B表示关于其子LQPN 470C和470D(它们分别实行“SELECT(TABLE(ORDERS),ORDERS.数量> 4),和SELECT(TABLE(CUSTOMERS),CUSTOMERS.邮政编码=10001)”)的结果、以及比较谓词460的“JOIN(”444(操作496,其完成被标记为486的“where”412子句)。尽管已对图示的示例进行了优化,以使得JOIN根据比较谓词“ORDERS.客户ID=CUSTOMERS.客户ID”460以及两个SELECT操作(490和492)的结果进行操作,但是替代实施例可以不同地进行优化或根本不优化。
SELECT语句(包括“选择”402和“*”404)被映射到LQPN 470A,LQPN 470A表示关于其子LQPN B(其实行“JOIN(SELECT(TABLE(ORDERS),ORDERS.数量>4,SELECT(TABLE(CUSTOMERS),CUSTOMERS.邮政编码=10001),ORDERS.客户ID = CUSTOMERS.客户ID)”)的结果、以及列的列表“CUSTOMERS.客户ID、CUSTOMERS.姓名、CUSTOMERS.邮政编码、ORDERS.订单ID、ORDERS.客户ID、ORDERS.价格、ORDERS.数量)”462的“PROJECT(”442(操作498)。
术语“参数”在本文中被用来指代用以实行与“运算符类型”(例如,比如“ORDERS”或“CUSTOMERS”的表引用、比如“ORDERS.数量> 4”、“CUSTOMERS.邮政编码=10001”或“ORDERS.客户ID=CUSTOMERS.客户ID”的比较谓词、比如“CUSTOMERS.客户ID、CUSTOMERS.姓名、CUSTOMERS.邮政编码、ORDERS.订单ID、ORDERS.客户ID、ORDERS.价格、ORDERS.数量”的列的列表;等等)相对应的操作所需的附加信息。
在一个实施例中,LQPN 470A-F中的每一个利用包括下述各项的数据结构来实现:1)“(一个或多个)子引用字段”,用以存储对任何子节点的(一个或多个)引用(例如,LQPN470B的子节点是LQPN 470C和LQPN 470D);以及2)一组一个或多个“描述符字段”,用以存储运算符类型及其一个或多个参数以用于操作。在一个实施例中,存在两个描述符字段:1)“运算符类型字段”,用以存储运算符类型的指示;以及2)“其他参数字段”,用以存储参数。在另一实施例中,LQPN 470A-F中的每一个实现描述符字段,该描述符字段存储包括运算符类型及其一个或多个参数的整个节点密钥。一些实施例将逻辑查询计划实现为“轻量图”(即,包括用以表示查询计划的最少信息的图),其中生成轻量图以便于物理查询计划的生成。替代实施例可以在逻辑查询计划中包括更多、更少和/或不同的信息,和/或放弃逻辑查询计划的生成。
图5A图示了根据一个实施例的示例性文本表示440的不同部分与示例性物理查询计划的关系。图5A再现了图2的物理查询计划242和基本时态表260,以及图4的示例性文本表示440和标识了操作490、492、496和498的标记。与图4一样,示例性文本表示440(其是作为字符串被写出以形成示例性查询计划的人类可读版本的示例性查询计划的节点)是出于解释的目的,并且不需要由某些实施例生成。进一步地,替代实施例可以针对示例性SQL查询310生成与示例性文本表示440所表示的查询计划不同的查询计划。图示了示例性文本表示440和不同的操作490、492和498,以标识PQPN 570A-F中的每一个在被执行时将实行的查询计划操作(包括运算符类型和(一个或多个)参数)。每个PQPN 570A-F的“运算符类型”标识了该PQPN实行的多种类型的查询计划运算符中的特定一个。再次,一些实施例对于查询计划运算符中的一个或多个具有不同的实现方式;并且一些这种实施例可以被配置成使得“运算符类型”标识了查询计划运算符中的特定一个以及该查询计划运算符的实现方式中的特定一个,而其他这种实施例可以被配置成使得“运算符类型”在不参考特定实现方式的情况下标识查询计划运算符中的特定一个。
如前所描述,操作在没有查询计划(逻辑或物理的)或TT被保留在存储器中(即,物理查询计划242、BTT 260和DTT 264为空)、以及高速缓存234为空的情况下的一个实施例中开始。作为示例,响应于SQL语句(包括两个CREATE TABLE SQL语句和两个INSERT SQL语句),BTT创建和填充502发生,并且导致:1)叶PQPN 570E和对应的BTT 554A被创建;以及2)叶PQPN 570F和对应的BTT 554B被创建。在图2的实施例中,针对高速缓存234中的PQPN570E和PQPN 570F中的每一个创建条目。
响应于示例性SQL查询310被接收到,在504处生成示例性物理查询计划564。生成示例性物理查询计划564包括:创建一个或多个必要的中间节点和根节点(PQPN 570A-D),并且添加必要的边以适当地连接那些节点从而形成有向图(包括将边添加至叶PQPN 570E-F)。在该示例中,所确定的是,PQPN 570E和PQPN 570F已经处于物理查询计划242中,并且可以被合并到物理查询计划564中;还确定的是,PQPN 570A-D必须被添加到物理查询计划242,并且通过一个或多个边连接到PQPN 570E和PQPN 570F以形成有向图。在图2的实施例中,通过确定在高速缓存234中是否存在高速缓存命中来做出这些确定。
在首先实现逻辑查询计划(例如,示例性逻辑查询计划464)的实施例中,逻辑查询计划可以表示要作为物理查询计划生成的有向图(例如,物理查询计划564具有相同数量的节点,这些节点负责相同的操作(运算符类型和(一个或多个)参数)并且由相同数量的边连接以形成与示例性逻辑查询计划464相同的形状,并且因此PQPN 570A-F的相同标有字母的节点对应于LQPN 470A-F的相同标有字母的节点),并且逻辑查询计划被用来确定是否可以是否可以通过重新使用或合并已经处于在执行之后当前被保留在存储器中的物理查询计划242中的节点和/或子图(以及在一些实施例中,整个有向图)中的一个或多个来生成所需的物理查询计划。在该示例中,所确定的是,LQPN 470E和LQPN 470F可以分别由已经处于物理查询计划242中的PQPN 570E和PQPN 570F来实行,并且因此可以被合并到物理查询计划564中;还确定的是,PQPN 570A-D必须被添加到物理查询计划242,并且通过边连接到被确定为可重新使用的PQPN 570E和PQPN 570F。在首先生成逻辑查询计划并使用高速缓存234的实施例中,这些确定是通过基于逻辑查询计划的有向图确定节点密钥是否针对节点和/或子图(以及在一些实施例中,整个有向图)中的一个或多个已经存在于高速缓存234中来做出的,并且仅创建尚未处于物理查询计划242中的那些(一个或多个)PQPN和边。
如本文中使用的,术语“查询计划”可以指代“逻辑查询计划”或“物理查询计划”,并且术语“节点”或“查询计划节点”(QPN)可以指代“LQPN”或“PQPN”。
图5B图示了根据一个实施例的示例性物理查询计划564的执行。图5B再现了图2的物理查询计划242、基本时态表260和所导出的时态表264,以及图5A的示例性物理查询计划564(包括由PQPN 570A-F组成的有向图)和BTT 554A-B。如先前所描述,针对每个唯一查询的查询计划由有向图组成,该有向图以根节点(例如,PQPN 570A)开始,包括零个或多个级别的中间节点(例如,PQPN 570B-D),并且在一个或多个叶节点(例如,PQPN 570E-F)中结束。在执行期间,递归调用从根节点向下进行到(一个或多个)叶节点,并且由于该执行而生成的数据从(一个或多个)叶节点经过中间节点向上流动到根节点(由弯曲箭头所图示);因此,执行导致了从叶到根的数据流动。在一个实施例中,对根节点(PQPN 570A)进行调用以实行其查询计划操作,这导致对根节点的(一个或多个)子节点(例如,PQPN 570B)的(一个或多个)调用等等,这些调用递归地向下至叶节点(例如,PQPN 570B调用PQPN 570C-D,PQPN570C调用PQPN 570E;以及PQPN 570D调用PQPN 570F);给定节点的执行的完成导致结果被提供给其父节点(如果有的话);当给定父节点的所有(一个或多个)子节点都已完成执行并且将其结果提供给该给定父节点时,则该父节点将进行执行并且将其结果提供给其父节点(如果有的话)。
根和中间PQPN 570A-D中的每一个标识在被保留以供潜在重新使用的所导出的时态表264中的DTT 558A-D。当执行根和中间PQPN 570A-D中的每一个时,其更新PQPN标识的DTT 558A-D中的对应的一个。从根PQPN 570A标识的DTT 588A产生查询结果。
在一个实施例中,BTT 260和DTT 264是TT类的对象,并且TT类的对象包括:1)时态表的数据记录的数据;以及2)从该TT访问数据记录的一个或多个方法。在一个实施例中,每个PQPN:1)标识时态表(例如,具有标识BTT或DTT的引用);以及2)包括评估方法,该方法实行由查询计划运算符及其一个或多个参数(例如,TABLE(ORDERS),其中TABLE是查询计划运算符,并且ORDERS是其参数)指定的查询计划操作,并且返回所标识的时态表的数据记录(例如,返回对所标识的BTT或DTT的引用,父节点可以使用该引用来访问所标识的时态表的数据记录)。由于制作副本可能是昂贵的(特别是对于大型表而言),因此对PQPN所标识的DTT/BTT的只读视图或只读副本的引用由该PQPN的评估方法返回,从而允许调用了该方法的调用者(例如,父节点)然后从返回的TT访问所需的记录(在一些情况下是仅增量,在其他情况下是整个表)。
在一个实施例中,其中物理查询计划242的节点被实现为“时态表节点”(TTN)并且可以被分类为所导出的时态表节点(DTTN)244和基本时态表节点(BTTN)246,如参考图2所描述的那样,PQPN 570A-D将被实现为DTTN 244,并且PQPN 570E-F将被实现为BTTN 246。换言之,DTTN 244包括物理查询计划242的有向图的根节点和中间节点,而BTTN 246包括物理查询计划242的有向图的叶节点。在一个实施例中,DTTN 244和BTTN 246分别是DTTN类和BTTN类的对象,并且两个类都包括:1)TT引用字段;以及2)评估方法(分别被称为DTTN.评估和BTTN.评估)。父节点调用子节点的评估方法,并且子节点的评估方法返回对该子节点所标识的DTT 264或BTT 260中的一个的只读视图或只读副本的引用;并且然后父节点可以调用该DTT或BTT的(一个或多个)方法来访问由该DTT或BTT封装的时态表的数据记录(其可以是针对某些查询计划操作的所有数据记录,或者是针对其他的自最后更新以来的△)。DTTN类的实例的DTTN.评估方法的执行实行了该节点的查询计划操作,将结果存储在该DTTN的TT引用字段所标识的DTT中的一个中,并且返回对该DTT的只读视图或只读副本的引用。BTTN类的实例的BTTN.评估方法的执行返回对该BTTN所引用的BTT 260中的一个的只读视图或只读副本的引用。因此,实现PQPN 570A的DTTN的DTTN.评估方法的执行包括:1)对子DTTN(PQPN 570B)的DTTN.评估方法的调用,该方法返回DTT 558B的只读视图或只读副本,以及然后对用以访问DTT 558B的数据记录作为对操作的输入的(一个或多个)方法的调用;2)实行适当的查询计划操作;3)将该查询计划操作的结果存储在由TT引用字段标识的DTT558A中;以及4)返回对DTT 558A的只读视图或只读副本的引用。实现PQPN 570B的DTTN的DTTN.评估方法的执行包括:1)对子DTTN(PQPN 570C-D)的DTTN.评估方法的调用,该方法返回DTT 558C-D的只读视图或只读副本,以及然后对用以访问那些DTT 558C-D的数据记录作为对操作的输入的(一个或多个)方法的调用;2)实行适当的查询计划操作;3)将该查询计划操作的结果存储在由TT引用字段标识的DTT 558B中;以及4)返回对DTT 558B的只读视图或只读副本的引用。最低级别DTTN(例如,PQPN 570C-D)中的每一个的DTTN.评估方法的执行包括:1)对该DTTN(例如,PQPN 570E)所引用的BTTN的BTTN.评估方法的调用,该方法返回该BTTN所引用的BTT(例如,BTT 554A)的只读视图或只读副本,以及然后对用以访问该BTT(例如,BTT 554A)的数据记录的(一个或多个)方法的调用;2)实行适当的查询计划操作;3)将该查询计划操作的结果存储在由TT引用字段标识的DTT 264(例如,DTT 558C)中的一个中;以及4)返回对该DTT(例如,DTT 558C)的只读视图或只读副本的引用。对于本领域的普通技术人员应该显而易见的是,有向图的结构指示哪些节点可以并行执行(例如,父节点的子节点)。尽管出于说明的目的描述了将物理查询计划242的节点实现为TTN(并且更具体地,DTTN 244和BTTN 246)的一个实施例,但是替代实施例可以不同地实现物理查询计划242的节点。
图6图示了根据一个实施例的示例性重叠物理查询计划。图6示出了示例性SQL查询310、示例性文本表示440、物理查询计划242中的物理查询计划564(包括PQPN 570A-F)以及基本时态表260中的BTT 554A-B。图6还示出了根据一个实施例的附加的示例性SQL查询、针对那些SQL查询的查询计划的示例性文本表示、以及针对那些SQL查询的示例性物理查询计划。对于附加的示例性SQL查询602、604、606和608中的每一个,图6示出了该SQL查询的与示例性SQL查询310相同的部分,并且省略了其有所不同的地方(例如,附加的示例性SQL查询602被示为“从...选择*,ORDERS,...其中...”)。此外,图6示出了针对附加的示例性SQL查询602、604、606和608的相应示例性文本表示612、614、616和618。对于示例性文本表示612、614、616和618中的每一个,图6示出了该文本表示的与示例性文本表示440相同的部分,并且省略了其有所不同的地方(例如,示例性文本表示612被示为“PROGECT(...TABLE(ORDERS)...)”)。
此外,图6图示了针对示例性文本表示612、614、616和618中的每一个的相应的物理查询计划622、624、626和628中的每一个的部分。所示出的相应的物理查询计划622、624、626和628中的每一个的部分包括:1)与物理查询计划564共享的第一子部分(节点或子图);以及2)没有被共享但是包括通过一个边连接到第一子部分的至少一个节点的第二子部分。因此,图6图示了物理查询计划564、622、624、626和628的有向图被连接(也被称为“重叠”),这是因为它们共享至少一个节点,并且在某些情况下还共享两个或更多个节点和一个或多个边的子图。例如,物理查询计划622包括:具有PQPN 570E作为子节点的PQPN 670A(未被共享)(存在将PQPN 670A连接到PQPN 570E的边),并且因此PQPN 570E是物理查询计划622与物理查询计划564之间的共享节点(叶节点)。物理查询计划628包括具有PQPN 570B(中间节点)作为子节点的PQPN 670F(没有被共享的根节点),并且因此PQPN 570B-F的子图(即,PQPN 570B的子图及其后代节点;即,PQPN 570B、PQPN 570C-D和PQPN 570E-F)是物理查询计划628与物理查询计划564之间的共享子图。物理查询计划624包括具有PQPN 670C(未被共享)和PQPN 570C(中间节点)作为子节点的PQPN 670B(未被共享),并且因此PQPN 570C-E的子图是物理查询计划624与物理查询计划564之间的共享子图。物理查询计划626包括具有PQPN 670E(未被共享)和PQPN 570B(中间节点)作为子节点的PQPN 670D(未被共享),并且因此PQPN 570B-F的子图是物理查询计划626与物理查询计划564之间的共享子图。
在图示的示例中,当查询计划操作在多于一个查询计划中相同时,节点被共享。换言之,如果查询计划操作在两个(或更多个)查询计划中是相同的,则表示该查询计划操作的节点(以及任何后代节点——即,可通过从父节点到子节点的重复进行而达到的(一个或多个)任何节点)可以被共享。
如先前所描述,在第一查询计划(例如,物理查询计划564)已经被生成并且在执行之后被保留在存储器中的情况下,则第二查询计划(例如,物理查询计划622、624、626和628中的任一个)的生成并不需要创建第二查询计划所需的、已经处于第一查询计划(例如,物理查询计划564)中并且可以被共享的那些一个或多个节点(以及可能地节点和边的一个或多个子图),这是因为它们与那些所需的节点相同;第二查询计划(例如,物理查询计划622、624、626和628中的任一个)的生成重新使用(也被称为“合并”)来自第一查询计划(例如,物理查询计划564)中的一个或多个节点(以及可能地一个或多个子图)中的与第二查询计划所需的那些相同的那些节点。此外,在第一物理查询计划(例如,物理查询计划564)已经被生成并且在执行之后被保留在存储器中的情况下,则与第一物理查询计划相对应的第二逻辑查询计划的生成不需要创建任何节点,这是因为可以重新使用第一物理查询计划(整个有向图,包括其节点和边)。
因此,在图示的示例中,共享的节点实现了示例性SQL查询的部分,其中SQL查询的子句或子句的部分是相同的;因此,SQL查询共享部分(也被称为“重叠”),以使得被生成以实现那些SQL查询的查询计划可以共享节点(也被称为“重叠”)。尽管图6图示了重叠的示例性SQL查询,但是应当理解的是,在一些实施例中,针对两个SQL查询的物理查询计划可以重叠而无需那些SQL查询重叠。附加地,在生成查询计划时应用的查询计划优化可能会在两个或更多个SQL查询的物理查询计划中导致更多、更少或没有重叠。
增量式更新和执行
图7A是图示了根据一个实施例的响应于时态关系数据库的时态表中的至少一个的修改而增量式地更新时态表的流程图。如先前所描述,在时态表上进行操作的典型关系数据库操作(例如,PROJECT、JOIN、SELECT、TABLE)的实现方式是本领域已知的(例如,D.Pfoser和C.S. Jensen,“Incremental Join of Time-Oriented Data”,In Proc. 11thIntl. Conf. Scientific and Statistical Database Management,第232-243页,1999年;Jun Yang和Jennifer Widom,“Maintaining Temporal Views Over Non-TemporalInformation Sources For Data Warehousing”,In EDBT '98 Proc. 6th Int. Conf. onExtending Database Technology:Advances in Database Technology,第389-403页,1998年)。在一个实施例中,查询计划运算符中的一个、一些、大多数或全部被实现为支持增量式执行以增量式地更新时态表,而不是完全重新执行/重新计算。图7A的流程图可以在图1中的流程图之后发生。
在图7A的框702处,修改时态表中的作为时态关系数据库的部分并且SQL查询中的至少一个需要从其中访问数据的至少给定的一个时态表的内容。例如,这可以响应于RDBMS接收到INSERT、UPDATE或DELETE SQL语句或其他类似的SQL语句而发生,这些语句通过添加数据记录、删除数据记录和/或改变现有数据记录的内容来修改时态表的内容。如先前所描述,这种操作可以被包括在SQL语句216中,并且由非查询执行器228执行以修改BTT 254中的一个。控制从框702传递到框704。
在框704中,更新由标识经修改的时态关系数据库表的节点的祖先所标识的时态表(由节点中的如下那些节点所标识的时态表中的那些时态表:那些节点属于针对SQL查询中的至少一个的查询计划的有向图并且直接或间接取决于标识了时态表中的给定的一个时态表的节点)。这些更新在可能的情况下(例如,在该实施例实现可以增量式地实行查询计划操作的评估方法的情况下)通过增量式执行来实行。在不同的实施例中可以不同地确定相对于框702实行框704的定时(例如,立即地;在支持懒惰更新的实施例中,它被延迟直到一个或多个事件发生(例如,向客户端发送查询结果的需要、固定的时间流逝量、可编程的时间流逝量、基于节点和边(例如,基于节点与其他节点的连接性、节点的类型、它们的历史使用等)的所计算的时间量流逝、其他SQL查询的到达率超出阈值、和/或可用的计算资源落在阈值以下),如先前所描述)。控制从框704传递到框706。
在支持跳过更新的一些实施例中,仅执行由节点中的直接或间接取决于标识了框702中修改的时态表的节点的那些节点所实行的查询计划操作中的那些查询计划操作(其他节点被跳过(例如,在一个实施例中,其他节点将使其评估方法被调用,但是将不执行查询计划操作,并且将不在其子节点(如果有的话)上调用评估),从而获得不执行对没有受修改影响的时态表的更新的进一步性能优势)。在替代实施例中,由属于针对多个SQL查询中的至少一个的查询计划的有向图的全部节点实行的查询计划操作被执行(在可能的情况下通过增量式执行,并且被实现)。
如框706中所示,将对针对多个SQL查询中的至少一个的查询结果的增量式更新传输给客户端中的提交了多个SQL查询中的至少一个的那些客户端。因此,一个实施例传输对查询结果的增量式更新(即,仅传输“△”,并且从而避免传输整个查询结果)。
例如,假设响应于客户端提交SQL查询,RDBMS生成了物理查询计划并且将查询结果传输给客户端,并且然后存在对有向图的叶节点标识的基本时态表的内容的修改(框702)。如果在执行之后查询计划和时态表仍被保留在存储器中以供潜在的重新使用,则RDBMS可以增量式地更新(框704)并且向客户端传输对先前传输的查询结果的增量式更新(即,向客户端传输数据,其中数据标识了对自该客户端最后发送了该查询结果以来满足该SQL查询的查询结果的改变,而不是重新传输已被传输给客户端的查询结果中的那部分)(框706)。当然,如果第二客户端提交相同的SQL查询,而查询计划和时态表在执行之后仍被保留在存储器中以供潜在的重新使用,则RDBMS可以增量式地更新(框704)并且向第二客户端传输完整的查询结果。
图7B图示了根据一个实施例的相对于示例性物理查询计划564和示例性物理查询计划628的增量式执行和增量式更新。图7B再现了:1)图2的物理查询计划242、基本时态表260和所导出的时态表264;2)图5A-B和6的示例性物理查询计划564(包括由PQPN 570A-F组成的有向图)和BTT 554A-B;3)如图5B中的由相应PQPN 570A-D标识的DTT 558A-D;以及4)物理查询计划628(包括由PQPN 670F和PQPN 570B-F组成的有向图)。图7B还图示了由PQPN670F标识的DTT 758A。假设物理查询计划564和628先前已经被执行,并且查询结果分别被提供给第一和第二客户端。在710处,BTT 554A的内容被修改(例如,框702)。在720处,响应于框710而增量式地执行(一个或多个)查询计划的节点(例如,参见框704对于可能定时的讨论)。假设仅物理查询计划564要被更新,第一实施例仅增量式地执行PQPN 570E、C、B和A,如弯曲箭头722、724和728图示的(并且仅DTT 558A-C被更新,并且仅被增量式地更新,如由增量式更新740所反映的)。第二实施例与第一实施例所做的相同,但是还增量式地执行PQPN 670F,因为它间接地取决于BTT 554A,如由虚线弯曲箭头730图示的(并且DTT 758A也被更新,并且仅被增量式地更新,如由增量式更新744所反映的)。第三实施例与第一实施例所做的相同,但是还增量式地执行PQPN 570D和F,如由虚线弯曲箭头736和732所图示,因为它们是示例性物理查询计划564的部分(但是DTT 558D没有被更新,这是因为尚未存在直接或间接影响它的改变)。第四实施例进行第一、第二和第三实施例的操作。在全部的这些实施例中,仅DTT被增量式地更新,并且因此具有上面关于增量式地更新时态表描述的益处。
在以上段落中,第一和第二实施例避免了执行(无论它是增量式执行还是完全重新执行)由PQPN 570D和F实行的查询计划操作(这在本文中被称为跳过更新);在不同的实施例中,这可以被不同地实现。在支持跳过更新的一个实施例中,每个查询计划被生成为双向图;意味着,每个父节点标识其(一个或多个)子节点(如果有的话),并且每个这种子节点标识该父节点。由于使用双向图和查询计划重叠/连接性(节点共享),另一个观点是每个叶节点(例如PQPN 570E-F)也是另一个有向图的根节点,该另一个有向图被称为“脏通知有向图”、“基本表有向图”或“BTTN有向图”。每个“脏通知有向图”以其根节点(例如,PQPN 570E)开始,包括一个或多个级别的中间节点(例如,PQPN 570C和B),并且在该“脏通知有向图”的一个或多个叶节点(例如,PQPN 570A和PQPN 670F)(它们均是查询计划——例如物理查询计划564和628的根节点)中结束。“脏通知有向图”可以用于通过从该脏通知有向图的根节点(例如,PQPN 570E)向上至该脏通知有向图的(一个或多个)叶节点(例如,PQPN 570A和PQPN 670F,它们是物理查询计划564和628的(一个或多个)根节点)做出递归调用,来跟踪受BTT中的改变影响的每个节点,从而允许脏指示从该脏通知有向图的根节点(例如,PQPN570E)向上流动通过中间节点(例如,PQPN 570C和B),并且至消耗该BTT的(一个或多个)查询计划的根节点(例如,PQPN 570A和PQPN 670F,它们是物理查询计划564和628的(一个或多个)根节点)。这些脏指示可以与懒惰更新结合使用,因为它们提供了跟踪已被延迟的更新的机制,并且这些脏指示可以被用于跳过更新,因为它们提供了对应该针对哪个节点执行(无论它是增量式执行还是完全重新执行)查询计划操作进行跟踪的机制。换言之,被标记为脏的全部那些节点要被包含在批处理中,该批处理要在受BTT的修改(直接或间接地)所影响的DTT的下一次更新中执行,并且针对仅被标记为脏的那些节点的查询计划操作要在受BTT的修改所影响(直接或间接地)的DTT的下一次更新中执行(无论它是增量式执行还是完全重新执行)(没有被标记为脏的那些节点的执行被跳过)。
重叠的查询计划和增量式执行
图8是图示了根据一个实施例的重叠查询计划和增量式执行的组合的流程图。框802图示了在关系数据库管理系统处接收新提交的结构化查询语言(SQL)查询,并且控制传递到框804。
框804示出了通过重新使用在执行之后被保留在存储器中(即,在易失性存储器、非易失性存储器和/或其组合中)的现有查询计划的至少一部分来生成针对新提交的SQL查询的查询计划。如以前,关系数据库管理系统管理包括时态表的时态关系数据库。现有查询计划包括:通过边连接的节点的有向图,该有向图表示查询计划运算符的有序集合,该查询计划运算符在被执行时生成了针对较早提交的SQL查询的查询结果,该查询需要从时态关系数据库访问数据。针对新提交的SQL查询的查询计划包括:通过边连接的节点的有向图,该有向图表示查询计划运算符的有序集合,该查询计划运算符在被执行时将生成针对新提交的SQL查询的查询结果。针对新提交的SQL查询的有向图通过它的至少一个边连接到针对较早提交的SQL查询的有向图的至少一个节点,以使得有向图共享至少一个节点,其中有向图的每一个节点表示查询计划运算符中的一个。进一步地,每一个有向图的节点中的至少一个标识了时态关系数据库的时态表中的一个,并且有向图共享的节点中的至少一个标识了在执行之后被保留在存储器中并且被创建以存储执行该节点表示的查询计划运算符的结果的时态表。控制从框804传递到框806。
虚线框806示出了:在修改时态表中的作为时态关系数据库的部分并且至少现有SQL查询需要从其中访问数据的给定的一个时态表的内容之后,增量式地更新由节点中的如下那些节点所标识的时态表中的那些时态表:那些节点存储执行查询计划运算符的结果并且直接或间接取决于标识了时态表中的该给定的一个时态表的节点。在如下实施例中存在进一步的效率增益:在该实施例中,该增量式地更新包括由现有查询计划的节点中的直接或间接取决于标识了时态表中的给定的一个的节点的那些节点中的一个或多个所表示的查询计划运算符中的一个或多个被增量式地执行(与在该节点的每个子节点标识的时态表的有效行上重新执行这种节点的查询计划运算符(完全重新执行)相对)。控制从框806传递到框808。
虚线框808图示了向提交了较早提交的SQL查询的客户端传输数据,该数据标识了对现有查询计划的有向图的节点中的根节点所标识的时态表的增量式更新。
除了框806和808之外或替代于框806和808,一个实施例实行下述各项:1)通过重新使用(包括根据需要增量式地更新)由有向图共享的至少一个节点所标识的时态表来执行针对新提交的SQL查询的查询计划;以及2)将针对新提交的SQL查询的查询结果传输到提交了该新提交的SQL查询的客户端。除了框806和808之外或替代于框806和808,一个实施例实行下述各项:1)增量式地执行由有向图共享的至少一个节点所表示的查询计划运算符,作为执行针对新提交的SQL查询的查询计划的部分;以及2)将针对新提交的SQL查询的查询结果传输到提交了该新提交的SQL查询的客户端。附加地或替代地,在一个实施例中,现有查询计划在执行之后被保留在存储器中,使得有向图的节点和子图可用于潜在的重新使用。附加地或替代地,在一个实施例中,被创建以存储执行由该节点表示的查询计划运算符的结果的每一个时态表在执行之后被保留在存储器中,以供潜在的重新使用。附加地或替代地,在一个实施例中,生成包括:1)标识现有查询计划的有向图的节点中的至少一个可以被重新使用;以及2)将连接到所标识的节点的边添加到针对新提交的SQL查询的查询计划的有向图。附加地或替代地,生成可以包括:1)标识存在可以被重新使用的现有查询计划的部分,其中所标识的部分包括将被共享的有向图的至少一个节点;以及2)重新使用针对新提交的SQL查询的查询计划中的所标识的部分,而不是重新创建所标识的部分。关系数据库管理系统还可以将针对新提交的SQL查询的查询结果传输到该相同的客户端和/或不同的客户端。附加地或替代地,在一个实施例中,查询计划运算符中的一个或多个实行时态关系代数运算。附加地或替代地,一个实施例支持有向图,每个有向图包括根节点、至少一个或多个叶节点以及至少一个或多个中间节点;其中中间节点是具有一个或多个父节点和一个或多个子节点两者的节点(根节点连接到(一个或多个)中间节点中的至少一个,并且每一个中间节点连接到中间节点中的至少另一个或叶节点中的一个);并且这两个有向图至少共享中间节点及其后代节点中的一个。附加地或替代地,一个实施例支持共享节点和(一个或多个)边的子图的查询计划。
附加地或替代地,在一个实施例中,较早提交的SQL查询由客户端作为订阅SQL查询而传输,并且在现有查询计划由于订阅SQL查询而在执行之后被保留在存储器中时,由关系数据库管理系统来接收新提交的SQL查询。而且,参考图1描述的各种实施例通常适用于图8。
节点密钥到节点高速缓存
图9是根据一个实施例的图示了高速缓存234的框图。图9重现了:1)图2的高速缓存234、物理查询计划242和基本时态表260;以及2)图5A-B、6和7B的示例性物理查询计划564(包括由PQPN 570A-F组成的有向图)和BTT 554A-B。图9还图示了具有包括节点密钥集合910和节点引用集合920的数据结构的高速缓存234。在图9中,物理查询计划564中的每一个节点具有在高速缓存234的数据结构中的条目,并且针对每一个节点的条目在集合910中存储该节点的节点密钥,并且在集合920中存储被用来在物理查询计划242中定位该节点的引用。具体地,图9示出了分别标识PQPN 570A-F的节点密钥912A-F和相应相关联的引用922A-F。尽管图9以表格的形式图示了数据结构,但是其他实施例可以使用不同的数据结构(例如,默认情况下创建被传递给它的每个密钥的散列的散列图、图形结构等)。
如先前所描述,将均表示正在生成的新查询计划的全部和/或部分的一个或多个节点密钥与高速缓存234中的节点密钥进行比较,以确定新物理查询计划的生成是否可以重新使用/合并一个或多个现有物理查询计划(例如,物理查询计划564)的一个或多个部分(每个部分是节点或者节点或(一个或多个)边的子图)。因此,存在针对每一个PQPN的节点密钥,并且从该意义上说,每个PQPN由节点密钥中的一个来表示。在首先在新物理查询计划之前生成逻辑查询计划的实施例中,逻辑查询计划可以被用来生成任何所需的节点密钥。进一步地,在生成逻辑查询计划的实施例中,从LQPN生成的节点密钥表示该LQPN,并且最终表示用于实现该LQPN的PQPN。
在一些实施例中,针对给定节点的节点密钥仅表示(一个或多个)查询计划中的包括该节点的那部分,而不表示(一个或多个)查询计划中的包括该节点的祖先(如果有的话)(父节点、祖父节点等)的任何部分。在一些这种实施例中,针对给定节点的节点密钥仅表示(一个或多个)查询计划中的包括该节点及其后代(子节点、孙节点等)(如果有的话)的那部分,而不表示(一个或多个)查询计划中的包括该节点的祖先(如果有的话)(父节点、祖父节点等)的任何部分。例如:1)在一个实施例中,针对每个节点的节点密钥基于该节点和该节点的后代(如果有的话)(例如,基于该节点的查询计划运算符和(一个或多个)参数、以及该节点的每一个后代,如果有的话);以及2)在另一个实施例中,针对每个节点的节点密钥基于该节点(例如,该节点的查询计划运算符类型和(一个或多个)参数)以及该节点的后代的密钥(如果有的话)(请注意:在该实施例中,某些信息是重复的,这是由于每个较低级别的密钥已经表示了其自己的所有后代)。因此,对于给定的查询计划:1)针对该查询计划的根节点的节点密钥表示整个查询计划;2)针对每个叶节点(例如,BTTN)的节点密钥仅表示查询计划中的标识了叶节点所引用的BTT的那部分;3)在查询计划中存在一个或多个中间节点的情况下,则:a)连接到叶节点的每一个节点(具有作为子节点的叶节点的节点)的节点密钥仅表示查询计划中的包括该节点(例如,查询计划运算符类型及其参数(例如,比较谓词))及其后代节点(例如,叶节点)的那部分;以及b)针对每个较高级别的节点(如果有的话)的节点密钥仅表示查询计划中的包括该较高级别的节点(例如,该节点要在由该节点的子节点提供的结果上实行的查询计划运算符及其参数(例如,比较谓词))及其后代节点(例如,(一个或多个)其他中间节点和(一个或多个)叶节点)的那部分。作为具体的实施例:1)叶节点表示在表引用上进行操作的TABLE查询计划运算符,并且其节点密钥基于TABLE查询计划运算符类型以及它在其上进行操作的表引用(例如,TABLE(CUSTOMERS));2)第二级别的节点表示在表查询计划运算符的结果上进行操作的查询计划运算符(例如,SELECT),并且其节点密钥基于该查询计划运算符类型、其参数(例如,针对该查询计划运算符的比较谓词)、以及它所取决于的叶节点(例如,表示TABLE(CUSTOMERS)的叶节点);3)较高级别的节点表示在其子节点的结果上进行操作的查询计划运算符(例如,JOIN),并且其节点密钥基于该查询计划运算符类型、其参数(例如,针对该查询计划运算符的比较谓词)、以及后代节点;以及4)根节点表示在其子节点的结果上进行操作的PROJECT查询计划运算符,并且其节点密钥表示整个查询计划,并且基于PROJECT查询计划运算符类型、其参数(例如,针对该PROJECT查询计划运算符的列名称的列表)及其后代节点。
在另一实施例中,针对每个节点的节点密钥基于该节点(例如,基于该节点的查询计划运算符类型和(一个或多个)参数)以及该节点的子节点(如果有的话)的密钥;该子节点密钥本身基于其子节点(如果有的话)的密钥等等(请注意:该实施例可以避免上面提及的重复)。在又一个实施例中,针对每个节点的节点密钥基于该节点(例如,基于该节点的查询计划运算符类型和(一个或多个)参数)以及该节点的零个或多个子节点(例如,基于(一个或多个)子节点(如果有的话)的查询计划运算符和(一个或多个)参数)。
作为具体示例,图9图示了一实施例,该实施例首先生成逻辑查询计划,从该逻辑查询计划生成节点密钥,并且针对每个节点的节点密钥基于该节点和该节点的后代(如果有的话)(例如,基于该节点的查询计划运算符和(一个或多个)参数、以及该节点的每一个后代,如果有的话)。因此,节点密钥912F是叶LQPN 470F(其不具有任何后代)的表示(例如,“TABLE(CUSTOMERS)”);节点密钥912E是叶LQPN 470E(其不具有任何后代)的表示(例如,“TABLE(ORDERS)”);节点密钥912D是中间LQPN 470D及其后代LQPN 470F的表示(例如,“SELECT(TABLE(ORDERS),ORDERS.数量>4)”);节点密钥912C是中间LQPN 470C及其后代LQPN 470E的表示(例如,“SELECT(TABLE(CUSTOMERS),CUSTOMERS.邮政编码 = 10001)”);节点密钥912B是中间LQPN 470C及其后代LQPN 470C-F的表示(例如,“JOIN(SELECT(TABLE(ORDERS),ORDERS.数量> 4),SELECT(TABLE(CUSTOMERS),CUSTOMERS.邮政编码= 10001),ORDERS.客户ID = CUSTOMERS.客户ID)”);以及节点密钥912A是根LQPN 470A及其所有后代LQPN 470B-F的表示(例如,“PROJECT(JOIN(SELECT(TABLE(ORDERS),ORDERS.数量> 4),SELECT(TABLE(CUSTOMERS),CUSTOMERS.邮政编码 = 10001),ORDERS.客户ID =CUSTOMERS.客户ID),CUSTOMERS.客户lD,CUSTOMERS.姓名,CUSTOMERS.邮政编码,ORDERS.订单ID,ORDERS.客户ID,ORDERS.价格,ORDERS.数量)”)。
虽然在以上示例中,节点密钥被描述为字符串,但是其他实施例可以使用不同的数据类型作为密钥(例如,在一个实施例中,密钥可以是非字符串对象,在另一实施例中,密钥被“散列化”并且使用所得到的散列值)。例如,在一些实施例中,美观打印机(可以被用来产生从特定节点开始并且包括其后代的子图的字符串表示的公知软件组件)的输出或其散列被用来创建密钥。作为另一示例,在一些实施例中,递归地使用来自LQPN的子节点的散列的信息、使用LQPN的运算符类型字段中的数据、以及使用LQPN的其他参数字段(如果有的话)中的数据来创建(例如,通过生成散列)针对给定LQPN的密钥。
如先前所描述,尽管描述了其中将图的边存储在图的节点内的实施例,但是替代实施例可以代替地将边存储在高速缓存234中。
如先前所描述,不同的实施例可以使用不同的技术来确定查询计划的每一个节点以及TT在执行之后被保留在存储器中达多长时间。在一个实施例中,针对每一个查询计划维持“活动的”或“非活动的”标识(例如,该标识可以与每一个查询计划的有向图的根节点相关联),并且不是“活动的”查询计划的部分的那些节点(以及它们引用的TT)是用于从在执行之后被保留在存储器中移除的候选项。如先前所描述,在用Java实现的一个实施例中,高速缓存234中的对根节点和叶节点的引用(例如,922A、E、F)属于强引用类型,而高速缓存234中的对中间节点的引用(例如,922B、C、D)属于弱引用类型;并且一旦高速缓存234中的给定根节点被释放,Java虚拟机垃圾收集器就可以释放从该根节点延伸的有向图所消耗的存储器。
加载基本时态表
图10是图示了根据某些实施例的可以以其填充基本时态表的数据的方式的框图。图10再现了来自图2的(一个或多个)数据库驱动器204和RDBMS 212的部分。在一个实施例中,数据从一个或多个其他源被加载到RDBMS 212中。例如,图10图示了虚线框1004,虚线框1004是源,诸如,实时流式传输源、第二RDBMS系统(诸如由加利福尼亚州红木海岸的Oracle公司制造的Oracle® RDBMS)、电子表格、计算服务器等。框1002表示对从源1004接收到的数据实行提取、转换和加载(ETL)操作并且将SQL语句(例如,CREATE TABLE和INSERT)提供给过程和客户端通信管理器214以加载经转换的数据的公知技术。响应于如先前所描述的那样创建并填充了必要的基本时态表260,这种语句被提供给解析器218并且以内部表示220的形式到达非查询执行器228。尽管在一个这种实施例中,RDBMS 212是在一个或多个源上操作的存储器中(in-memory)RDBMS,但是在其他这种实施例中,RDBMS 212是磁盘上(on-disk)系统或混合的存储器中和磁盘上系统。尽管在图示的实施例中,ETL 1002经由数据库驱动器与过程和客户端通信管理器214交互,但是替代实施例可以不同地操作(例如,代替ETL,生成或计算数据(与提取和转换相对)的客户端可以使用数据库驱动器以将SQL语句(例如,CREATE TABLE和INSERT)提供给过程和客户端通信管理器214以加载数据)。
在另一个实施例中,RDBMS 212是存储器中和磁盘上系统的组合,并且基本时态表存储对于最终用户可访问的数据(并且因此,该数据不需要从另一个源加载)。例如,在一个实施例中,作为存储器中和磁盘上系统的现有RDBMS被扩展成包括本发明的特征。如本文使用的,“存储器中”和“磁盘上”是公知的术语,其被用来将具有相对快的读/写时间的易失性主存储器(例如,动态随机存取存储器(DRAM))中的代码/数据的存储与具有较慢读/写时间的非易失性长期存储装置(例如,磁盘、闪速存储器、相变存储器、固态驱动器(SSD))中的存储区分开。然而,如本文中讨论的,随着采用具有更快的读/写时间的非易失性存储器(例如,相变存储器),易失性主存储器和非易失性长期存储装置的历史区分将变得过时。因此,术语“在存储器中(in memory)”(即,没有连字符)在本文中的使用指代存储在易失性存储器、非易失性存储器和/或其组合中。
用户界面
如先前所描述,出于各种原因将同时存在多个重叠查询。另一个这种原因是用户界面层的使用,该用户界面层通过在不同电子设备上运行的最终用户客户端而向多个(通常是许多个)最终用户提供共同的用户界面(例如,仪表板)。图11图示了根据一个实施例的在RDBMS 212的顶部上的用户界面层。图11重现了:1)图2的物理查询计划242、基本时态表260和所导出的时态表264;2)图5A-B和6的示例性物理查询计划564(包括由PQPN 570A-F组成的有向图)和BTT 554A-B;以及3)示例性物理查询计划622-628(包括PQPN 670A-F)。在图11中,用户界面层1100通过在不同的最终用户电子设备上运行的最终用户客户端(最终用户客户端1104A-N)向多个最终用户提供用户界面。在一个实施例中,用户界面层提供“仪表板”。例如,最终用户客户端1104A-M均显示相同仪表板的实例(被图示为所显示的仪表板1110A-M),而最终用户客户端1104N显示不同的仪表板1110N。尽管在图示的示例中,出于说明性目的仅示出了两个不同的仪表板(所显示的仪表板1110A-M与所显示的仪表板1110N),但是实施例可以支持更多或更少的仪表板。
仪表板典型地是通常适合于单个网页或应用窗口(也被称为画布(canvas))并且用于通过电子设备向最终用户显示的块(通常为矩形,并且被称为图块或面板)的集合;实际上,典型地,给定的仪表板用于通过多个电子设备向许多最终用户显示。仪表板的每个块包含内容元素(例如,图表、图形、图像(例如,颜色编码的地图)、电子表格、数据透视表、列表、表格、小部件;其中的一些有时被称为“视图”或“视觉”),该内容元素表示来自数据集(或基于数据集)的数据。仪表板和/或一个、多个或全部的块可以包括“菜单栏”或其他类型的显示项,“菜单栏”或其他类型的显示项允许用户与仪表板和/或块进行交互。数据集是被用来创建内容元素的数据的集合,并且它可以是来自单个数据源的一个数据点或数据(其可以被过滤),或者是来自多个源(例如,来自Excel工作簿的一个或多个表、一个或多个数据库(例如,SQL数据库)、网站、软件服务(例如,Salesforce)等)的数据(其可以被过滤)。在一个实施例中,用户界面层1100产生被提交给RDBMS 212的SQL查询,该RDBMS 212利用形成数据集的查询结果进行响应,内容元素是从该数据集被填充的。在图11的上下文中,最终用户客户端1104A-N传输SQL语句(包括SQL查询)以生成内容元素1112A-D的数据集(未示出),并且关系数据库管理系统212利用查询结果来响应于SQL查询,该查询结果是被提供给针对内容元素1112A-D的适当最终用户客户端的数据集。由此,最终用户客户端是RDBMS 212的客户端(并且可以被称为数据库客户端或RDBMS客户端),并且每个都包括一个或多个数据库驱动器204。在其他实施例中,用户界面层1100以公式或“BI查询语言”(例如,数据分析表达式(DAX)语言、多维表达式(MDX)语言、专有语言等)来产生请求,并且最终用户客户端1104A-N与RDBMS 212之间的BI服务1102:1)将来自最终用户客户端1104A-N的请求转换成它提供给RDBMS 212的SQL查询(以及在一些实施例中为订阅SQL查询);以及2)将来自RDBMS212的响应查询结果转换成数据集,用户界面层1100使用该数据集来填充内容元素。在图11的上下文中,在最终用户电子设备上运行的最终用户客户端1104A-N(包括与BI服务1102对接的软件(未示出)(例如,API、Web浏览器、本机客户端、BI门户、命令行界面等))传输请求(未示出),BI服务1102将这些请求转换成SQL语句(包括SQL查询),该SQL语句被设计成生成针对内容元素1112A-D的数据集(未示出);BI服务1102包括(一个或多个)数据库驱动器204,并且将这些SQL语句提交给RDBMS 212。RDBMS 212通过将查询结果发送给BI服务1102来响应于SQL查询,BI服务1102将该查询结果转换成被提供给针对内容元素1112A-D的适当最终用户客户端的数据集。由此,最终用户客户端1104A-N是BI服务1102的客户端(并且可以被称为BI客户端),而BI服务是RDBMS 212的客户端(并且可以被称为数据库客户端或RDBMS客户端)。还有其他实施例具有:这两种类型的最终用户客户端(例如,可能具有作为RDBMS客户端的最终用户客户端(并且因此具有(一个或多个)数据库驱动器204中的一个),以及作为BI客户端的其他最终用户客户端(并且因此具有用以与BI服务1102对接的软件(例如,API、Web浏览器、本机客户端、BI门户、命令行界面等),BI服务1102进而是RDBMS客户端并且包括(一个或多个)数据库驱动器204),或者甚至作为BI客户端和RDBMS客户端两者的最终用户客户端(并且因此包括用以与BI服务和(一个或多个)数据库驱动器204中的一个对接的两种软件)。
在图11中,内容元素1112A-B的数据集分别由来自物理查询计划622和564的查询结果提供,内容元素1112C的数据集由针对物理查询计划624和626的查询结果提供,并且内容元素1112D的数据集由针对物理查询计划628的查询结果提供。在图11中,针对内容元素1112A-D的数据集提供查询结果的查询计划全部重叠。提供了用于不同仪表板的不同内容元素的数据集的查询计划可以重叠(例如,物理查询计划628的有向图通过它的至少一个边连接到针对物理查询计划564的有向图的至少一个节点(PQPN 570B),以使得那些有向图共享至少一个节点(至少PQPN 570B),分别针对第一和第二SQL查询生成和执行了物理查询计划564和628,以分别填充第一仪表板内容元素(例如,内容元素1112B)和第二仪表板内容元素(例如,内容元素1112D),并且第一仪表板内容元素(例如,内容元素1112B)和第二仪表板内容元素(例如,内容元素1112D)是要由不同的最终用户客户端显示的不同仪表板的部分(要分别由最终用户客户端1104A和1104N显示的仪表板1110A和1110N)。因此,即使一个仪表板上的内容元素可能与另一仪表板上的内容元素不相同,但是针对那些内容元素提交的SQL查询可能导致重叠的查询计划。
进一步地,针对相同仪表板的不同内容元素提供数据集的查询计划可能会重叠(例如,物理查询计划622的有向图通过它的至少一个边连接到物理查询计划564的有向图的至少一个节点(PQPN 570E),以使得那些有向图共享至少一个节点,分别针对第一和第二SQL查询生成和执行了物理查询计划564和622,以分别填充第一仪表板内容元素(例如,内容元素1112B)和第二仪表板内容元素(例如,内容元素1112A),并且第一仪表板内容元素(例如,内容元素1112A)和第二仪表板内容元素(例如,内容元素1112B)是相同仪表板的部分,该相同仪表板的实例要由不同的最终用户客户端显示(例如,要分别由最终用户客户端1104A和1104M显示的仪表板1110A和1110M)。虽然图11中的示例图示了针对内容元素1112A-D的数据集提供查询结果的查询计划全部都重叠的时刻,但是这并非始终是必需的(可能存在其他单独的物理查询计划,彼此重叠的其他单独的物理查询计划集合等)。
在一些实施例中,由于仪表板通常显示长达某个时间,并且存在对于内容元素被几乎实时地更新的期望,因此可以将被传输到关系数据库管理系统212的SQL查询作为订阅SQL查询来传输。如先前所描述,一些实施例可以增量式地执行查询计划运算符,这相对于完全重新执行改进了效率。因此,与增量式执行相结合地使用订阅SQL查询来针对仪表板的内容元素提供查询结果提供了响应于该SQL查询结果所取决于的数据中的改变的更快的更新。
进一步地,在一些实施例中,由于针对订阅SQL查询的查询计划在执行之后被保留在存储器中达与客户端中的至少一个被订阅以接收对针对其生成了该查询计划的SQL查询的更新一样长的时间,因此第一客户端对订阅SQL查询的使用延长了时间窗口,在该时间窗口期间,针对该订阅SQL查询的查询计划(及其节点标识的时态表)将在执行之后被保留在存储器中以供潜在的重新使用,并且因此延长了如下时间窗口:在该时间窗口内,另一客户端可以提交重叠或相同的SQL查询(非订阅或订阅),并且RDBMS可以检测现有查询计划可以被重新使用(即,关系数据库管理系统212检测到由另一客户端提交的SQL查询的查询计划与由第一客户端提交的订阅SQL查询的在执行之后已被保留在存储器中的现有查询计划完全或部分重叠)。
不同的最终用户在不同的电子设备上同时使用相同仪表板会导致每个这种电子设备针对仪表板的每个内容元素发出相同的SQL查询以填充该内容元素。例如,如果给定的仪表板正在由X个电子设备显示,则被用来填充该仪表板的给定内容元素的SQL查询可以被发出X次(对于X个电子设备中的每一个而言都发出一次)。由于如先前所描述,实施例可以生成重叠的查询计划,因此多个客户端对相同SQL查询的传输可能会导致针对该相同SQL查询生成和共享的单个查询计划(这是查询计划完全重叠以使得仅单个查询计划在执行之后被保留在存储器中的情况)。因此,多个最终用户客户端同时使用共同的仪表板可能会导致针对该共同的仪表板的内容元素提交相同的一个或多个SQL查询(如果最终用户客户端是RDBMS客户端,则该提交是直接的,或者如果它们是用于BI服务(其是RDBMS客户端并且不解决查询重复本身)的客户端,则该提交是间接的),这将导致RDBMS重新使用针对该共同的仪表板的一个或多个完全重叠的查询计划。总之,在一个实施例中,同时使用相同仪表板的多个最终用户客户端可能导致(潜在地,在不同时间处)向RDBMS提交相同的订阅SQL查询集合,并且RDBMS生成针对订阅SQL查询的单个查询计划集合,并且将查询结果提供给每一个订阅的客户端(在每一个订阅的客户端被订阅时,将包括所有有效数据记录的初始查询结果和增量式查询结果两者(例如,以变更列表的形式)随时间提供给每一个订阅的客户端)。因此,与使用其仪表板中的相同内容元素的多个最终用户客户端相结合地使用订阅SQL查询来针对仪表板的内容元素提供查询结果提供了更大的时间窗口,在该更大的时间窗口内,针对该订阅SQL查询的查询计划将在执行之后被保留在存储器中以供潜在的重新使用,并且因此提供了如下时间窗口,在该时间窗口内,另一客户端可以提交相同的SQL查询,并且关系数据库管理系统可以检测现有查询计划可以被重新使用。
而且,在某些实施例中,用户界面允许最终用户与一个或多个内容元素进行交互,以使得对于不同的最终用户客户端,被发出以填充内容元素的SQL查询不是相同的,而是重叠的。例如,第一和第二最终用户的最终用户客户端可能正在显示相同内容元素,该相同内容元素依赖于针对其生成和执行了单个查询计划的相同SQL查询。然而,第一最终用户可以用以下方式与仪表板的内容元素进行交互:使基础SQL查询以需要不同的查询计划的方式来改变,但是该不同的查询计划仍与正在向第二最终用户显示的内容元素的查询计划部分地重叠。
而且,尽管在一些实施例中,提供仪表板的用户界面使得可用的仪表板是相对固定的,但是在其他实施例中,用户界面允许最终用户创建和编辑仪表板,以及与其他最终用户共享它们。存在允许这一点的现有用户界面(有时被称为商业智能工具)。创建和/或编辑仪表板的能力有时被称为自助式(self-service)或用户可定制的仪表板。该能力实现了公知的“数据发现”概念。数据发现是理解数据集的用户驱动过程,包括针对数据集中的模式或特定项进行搜索。数据发现应用通常使用可视化工具(例如,地图、数据透视表)来使查找模式或特定项的过程快速且直观。数据发现可以利用统计和数据挖掘技术来实现这些目标。当基础数据库更加响应灵敏时,使数据发现变得更加高效和实用;因此,支持增量式执行和查询计划重新使用的关系数据库管理系统212允许支持多个客户端和更高效的数据发现的更加响应灵敏的时态关系数据库。具体地,由于数据发现可能导致随着最终用户针对数据集中的模式和项进行搜索而发出一系列重叠的查询,关系数据库管理系统212实行增量式执行和查询计划重新使用的能力允许关系数据库管理系统212相对迅速地响应;从而实现更高效的数据发现。
总之,一些实施例在关系数据库管理系统212的顶部上具有用户界面层1100,其中:1)用户界面层提供了允许最终用户创建、编辑和共享仪表板的自助式最终用户仪表板,并且将所需的SQL查询(在适当时包括订阅SQL查询)传输到关系数据库管理系统;以及2)关系数据库管理系统,其管理时态关系数据库并支持同时SQL查询(包括订阅SQL查询):(a)支持重叠的查询计划,(b)在执行之后将查询计划保留在存储器中(即,在易失性存储器、非易失性存储器和/或其组合中),(c)在执行之后将那些查询计划的中间和根节点标识的时态表保留在存储器中,以及(d)实行增量式执行以增量式地更新那些时态表,以及最终更新针对所需SQL查询的查询结果。
示例性实现方式
现在将描述使用类的实例/对象的实施例,并且该实施例可选地生成双向查询计划图以生成脏通知有向图。
图12是根据一个实施例的DTTN类的框图。图12示出了DTTN类1202包括一个或多个描述符字段1204、TT引用字段1206、(一个或多个)子引用字段1208、最后刷新时间字段1210和评估方法1212的集合。(一个或多个)描述符字段集合1204可以以与针对图4中的LQPN描述的那些方式相同的方式来实现。如先前所描述,每个根节点和中间节点是DTTN类1202的实例/对象,并且TT引用字段1206要存储标识了所导出的时态表对象中的一个的引用,该所导出的时态表对象封装了存储由该节点实行的查询计划操作的结果的时态表。(一个或多个)子引用字段1208可以以与针对图4中的LQPN所描述的那些方式相同的方式来实现(例如,对(一个或多个)子节点(即,直接后代)的引用的列表)。最后刷新时间字段1210要存储截至查询计划操作最后被执行的时间(换言之,对于作为查询计划的节点的DTTN类1202的给定实例/对象,反映了被传递给评估方法1212并且被存储在最后刷新时间字段中的最后一个时间戳值的时间戳)。
执行评估方法1212以实行查询计划操作(其在(一个或多个)时态表上进行操作,并且在至少某些情况下,实行时态关系代数操作,因为它利用了表中的时态内容(例如,在某些实施例中,是valid_from和/或valid_to列的内容中的至少一些),该查询计划操作由DTTN类1202的给定实例/对象来表示(其中每个根节点和中间节点是DTTN类1202的实例/对象)。在一个实施例中,向评估方法1212传递评估开始时间,并且如果判定需要执行查询计划操作,则其:1)调用其(一个或多个)子节点的评估方法;2)在从这些(一个或多个)调用返回时,访问其(一个或多个)子节点的(一个或多个)BTT/DTT(或者,在一些实施例中,对这种(一个或多个)BTT/DTT的只读视图或副本的引用)以获得所需的数据记录;3)实行对利用其TT引用字段1206中的引用所标识的其自己的DTT的任何更新;以及4)返回对其DTT的只读视图或只读副本的引用。在某些编程语言(诸如Java)中,默认情况下通过引用来传递对象,并且因此不需要特殊的编程来通过引用传递对象。
此外,图12利用虚线框示出了DTTN类1202可以可选地包括(一个或多个)父引用字段1214、最后更新时间字段1216(也被称为脏时间戳字段)、添加父(Add Parent)方法1218、以及通知脏的方法1220。这些虚线框被用在生成了双向查询计划图以创建脏通知有向图的示例性实现方式中。(一个或多个)父引用字段1214要存储对任何(一个或多个)父节点(即,(一个或多个)直接祖先)的引用的列表。最后更新时间字段1216它要存储截至查询计划操作(直接或间接地)取决于的BTT最后被更新的时间(换言之,对于作为查询计划的节点的DTTN类1202的给定实例/对象,反应了该节点所依赖于的BTT何时变脏(被修改)的时间戳)。父节点(在该父节点的初始化期间)利用对该父节点的引用来调用添加父方法1218,并且该方法将对父节点的引用存储在(一个或多个)父引用字段1214中。因此,在父节点的初始化期间,每个子节点的该方法被调用,从而传递对父节点的引用,并且每个子节点的该方法在该子节点的(一个或多个)父引用字段1214中插入对该父节点的引用;这有助于制作双向查询计划图以及生成脏通知有向图。给定节点的通知脏的方法1220被子节点调用,并且其执行更新了该给定节点的最后更新时间字段1216,并且调用在给定节点的(一个或多个)父引用字段1214中列出的给定节点的父节点(如果有的话)的通知脏的方法1220。在操作中,当修改了BTT时,脏通知有向图用于通过从该脏通知有向图的根节点(例如,封装了经修改的BTT的BTTN)向上至该脏通知有向图的(一个或多个)叶节点(其是(一个或多个)查询计划的(一个或多个)根节点)做出递归调用来标识受改变影响的每个节点,从而允许脏指示向上流动通过(一个或多个)中间节点,并且至消耗该BTT的(一个或多个)查询计划的(一个或多个)根节点。
图13是根据一个实施例的BTTN类的框图。图13示出了BTTN类1302包括一个或多个描述符字段1304、TT引用字段1306、评估方法1312和(一个或多个)方法1322的集合。(一个或多个)描述符字段集合1304字段可以以与针对图4中的LQPN所描述的那些方式相同的方式来实现。如先前所描述,每个叶节点是BTTN类1302的实例/对象,并且TT引用字段1306要存储标识了基本时态表对象中的一个的引用,该基本时态表对象封装该叶节点的时态表(即,时态关系数据库的时态表)。
BTTN类1302的给定实例/对象的评估方法1312返回对在给定实例/对象的TT引用字段1306中标识的BTT的只读视图或只读副本的引用。
(一个或多个)方法1322包括:通过添加数据记录、删除数据记录和/或改变现有数据记录的内容(例如,INSERT、UPDATE、DELETE和可选地其他类似操作)来引起对该节点所标识的时态表的内容的修改的(一个或多个)方法(其中每个叶节点是BTTN类1302的实例/对象,该时态表由该叶节点的TT引用字段1306标识的基本时态表对象封装);以及创建表的(一个或多个)方法,以及可选地不改变表的内容而是改变表本身的其他数据定义语言(DDL)操作。
此外,图13示出了BTTN类1302可选地包括(一个或多个)父引用字段1314和添加父方法1318。(一个或多个)父引用字段1314要存储对任何(一个或多个)父节点(即,(一个或多个)直接祖先)的引用的列表。父节点(在该父节点的初始化期间)利用对该父节点的引用来调用添加父方法1318,并且该方法将对父节点的引用存储在(一个或多个)父引用字段1314中。因此,在父节点的初始化期间,每个子节点的该方法被调用,从而传递对父节点的引用,并且每个子节点的该方法在该子节点的(一个或多个)父引用字段1314中插入对该父节点的引用;这有助于制作双向查询计划图以及生成脏通知有向图。
图14是根据一个实施例的TT类的框图。图14示出了TT类1402包括TT字段1406、一个或多个获取行方法的集合(在图示的实施例中,包括获取有效行方法1424、获取插入行方法1426和获取删除行方法1428)以及(一个或多个)方法1422。在每个时态表由TT类1402的实例/对象封装的情况下(在本文中被称为所导出的时态表(DTT)或基本时态表(BTT)),TT字段1406要存储该时态表。“获取……行”方法被调用以访问TT字段1406的时态表中的数据。获取有效行方法1424被传递一时间戳,并且返回截至由该时间戳表示的时间有效的所有数据记录,并且用于提供初始查询结果。在支持增量式地执行查询计划操作和/或订阅SQL查询的一个实施例中,获取插入行方法1426和获取删除行方法1428被用来仅将改变返回给时态表(或“(一个或多个)△”)。在一个实施例中,这些方法中的每一个都被传递两个时间戳,并且返回分别在那些时间戳之间的一时间处插入或删除的数据记录。获取插入行方法1426被传递两个时间戳,并且返回在由该时间戳表示的两个时间之间插入的数据记录,而获取删除行方法1428被传递两个时间戳,并且返回在由该时间戳表示的两个时间之间删除的数据记录。尽管一个实施例实现了图示的三个“获取……行”方法,但是替代实施例可以实现更多、更少和/或不同的方法(例如,单个方法)。类似于上文valid_from和valid_to的概念,尽管参考逻辑视图和术语“一个或多个获取行方法的集合”(被图示为获取有效行方法1424、获取插入行方法1426和获取删除行方法1428)描述了实施例以简化理解,但是这些术语的使用不限于仅使用面向行的时态表的实施例,并且这些术语的同义词包括获取数据记录方法(例如,包括获取有效数据记录方法、获取插入数据记录方法以及获取删除数据记录方法)。
(一个或多个)方法1422包括:通过添加数据记录、删除数据记录和/或改变现有数据记录的内容(例如,INSERT、UPDATE、DELETE以及可选地其他类似操作)来修改TT字段1406中的时态表的内容的(一个或多个)方法;以及创建表的(一个或多个)方法,以及可选地不改变表的内容而是改变表本身的其他数据定义语言(DDL)操作。在一个实施例中,(一个或多个)方法1422由DTTN类1202的评估方法1212和/或BTTN类1302中的(一个或多个)方法1322来调用。
图15是根据一个实施例的图2的非查询执行器228的流程图。图15以框1502开始,其中区分了不同的非查询SQL语句类型。在具有CREATE TABLE的SQL语句的情况下,控制传递到框1504。相反地,对于通过添加数据记录、删除数据记录和/或改变现有数据记录的内容来修改表的内容的那些SQL语句,控制传递到框1510。本发明的实施例可以进一步区分框1504中的非查询SQL语句类型和/或支持附加的非查询SQL语句。
在框1504中,创建基本时态表,并且流程结束。在一个实施例中,框1504可选地被拆分成两个操作,并且在创建基本时态表节点之前创建基本时态表。具体地,在框1506中,创建基本时态表(例如,将TT类1402的实例/对象实例化),并且控制传递到框1508,在框1508中,创建基本时态表节点(BTTN)(例如,将BTTN类1302的实例/对象实例化,并且实行下述内容来初始化BTTN:1)填充(一个或多个)描述符字段1304;2)利用对在框1506中创建的BTT的引用来填充TT引用字段1306;以及3)在实现了(一个或多个)父引用字段1314的实施例中,将指示“空”的值存储在其中)。在替代实施例中,首先创建BTTN,并且它贪婪地(当BTTN被实例化时)或懒惰地(当需要经由例如INSERT来写入BTT时)创建其BTT。
在框1510中,实行通过添加数据记录、删除数据记录和/或改变现有数据记录的内容来修改表的内容的那些SQL语句,并且流程图结束。在实现了BTTN并且通过它们访问BTT的一个实施例中,框1510包括框1512,在框1512中,调用BTTN的(一个或多个)方法1322中的适当的一个,该方法调用BTT的(一个或多个)方法1422中的适当的一个。在实现了(一个或多个)父引用字段1314和通知脏的方法1220的一个实施例中,框1510包括调用在(一个或多个)父引用字段1314中列出的任何父节点的通知脏的方法1220。
在一个实施例中,应该提交SQL语句以在提交SQL查询之前创建该SQL查询所需的基本时态表(BTT)(例如,非查询执行器228创建(一个或多个)BTT以及针对那些(一个或多个)BTT的(一个或多个)BTTN);并且响应于包括这种SQL查询的SQL语句中的一个,解析器218的任务包括确认已经创建了所需的(一个或多个)BTT。
图16是根据一个实施例的图2的查询计划连接器232的流程图。如先前所描述,在一个实施例中,在针对该SQL查询生成物理查询计划之前,针对该SQL查询生成逻辑查询计划,并且该逻辑查询计划由查询计划连接器232利用。在这种实施例中,图16以框1602开始,在框1602处,从逻辑查询计划选择逻辑查询计划节点作为当前逻辑查询计划节点。
控制传递到框1604,在框1604中,确定针对所选逻辑查询计划节点的节点密钥是否在高速缓存234中。在一个实施例中,生成针对所选逻辑查询计划节点的节点密钥,并且然后确定该节点密钥是否在高速缓存234中(指示已经存在物理查询计划节点以及可能地子图,它们可以被重新使用/合并)。如果是,则控制传递到框1612,在框1612中,确定是否已经计及了全部逻辑查询计划节点。如果已经计及了它们,则控制传递到框1614,流程图在其中结束。如果未计及它们,则控制往回传递到框1602,在框1602中,将另一个逻辑查询计划节点选择为当前逻辑查询计划节点。不同的实施例可以以不同的次序选择逻辑查询计划节点。例如,一个实施例开始于选择逻辑查询计划的(一个或多个)叶节点的(一个或多个)父节点,并且然后选择所选逻辑查询计划节点的父节点,依此类推,直到到达逻辑查询计划的根节点为止。因此,该实施例“沿逻辑查询计划按其方式向上地进行工作”。另一个实施例开始于选择逻辑查询计划的根节点;并且如果该逻辑查询计划节点的节点密钥在高速缓存234中,则由于针对该SQL查询的物理查询计划已经在存储器中,因此不需要生成物理查询计划;但是,如果不是,则选择逻辑查询计划的(一个或多个)叶节点的(一个或多个)父节点,并且然后选择所选逻辑查询计划节点的父节点,依此类推,直到到达逻辑查询计划的根节点为止。因此,如果未找到逻辑查询计划的根节点,则该实施例还“沿逻辑查询计划按其方式向上地进行工作”。另一个实施例开始于选择逻辑查询计划的根节点;并且如果该逻辑查询计划节点的节点密钥在高速缓存234中,则由于针对该SQL查询的物理查询计划已经在存储器中,因此不需要生成物理查询计划;但是如果逻辑查询计划的根节点的节点密钥不在高速缓存234中,则选择当前逻辑查询计划节点的(一个或多个)子节点,依此类推,直到到达逻辑查询计划的叶节点为止;该实施例沿逻辑查询计划“按其方式向下地进行工作”。
如果在框1604中确定了针对所选逻辑查询计划节点的节点密钥不在高速缓存234中,则控制传递到框1606。在框1606中,将物理查询计划节点实例化,并且控制传递到框1608。在一个实施例中,这涉及DTTN类1202的对象的实例化。
在框1608中,初始化物理查询计划节点。关于DTTN类1202的实例/对象,实行下述内容:1)填充(一个或多个)描述符字段1204;2)利用指示空的值来填充TT引用字段1306;3)在实现了(一个或多个)父引用字段1214的实施例中,将指示空的值存储在其中;4)在沿逻辑查询计划的节点按其方式向上地进行工作的实施例中,使用针对所选逻辑查询计划节点的(一个或多个)子节点生成的(一个或多个)节点密钥、基于高速缓存234中的查找来填充(一个或多个)子引用字段1208;5)利用指示“从不”(例如,零)的值来填充最后刷新时间字段1210;6)在实现了最后更新时间字段1216的实施例中,其被填充有当前时间;以及7)在按其方式向上地进行工作并且实现添加父方法1280和1318的实施例中,利用对正在初始化的物理查询计划节点的引用来调用(一个或多个)子引用字段1208中的(一个或多个)子节点中的每一个的添加父方法1218或1318。尽管参考沿逻辑查询计划按其方式向上地进行工作的实施例描述了框1608,但是采用其他方法中的一个来选择逻辑查询计划节点的实施例将在另一时间处需要操作4和7。控制从框1608传递到框1610。
在框1610中,当前逻辑查询计划的节点密钥以及对在框1604中实例化的物理查询计划节点的引用被存储在高速缓存234的条目中。控制从框1610传递到框1612。
图17是根据一个实施例的查询执行器240的流程图。图17以框1702开始,在框1702中,对当前查询计划的根节点(根PQPN)的评估方法进行调用,其中评估开始时间被设置成当前SQL查询的时间(例如,SQL查询被客户端发送的时间(假设客户端具有传送该查询的方式)、RDBMS接收到SQL查询的时间、查询计划的执行开始的时间)。对物理查询计划的根节点(其是DTTN类1202的实例/对象)的评估方法1212的调用会引起对物理查询计划的PQPN进行向下递归调用(每个父节点调用其(一个或多个)子节点(如果有的话)的评估方法),直到到达叶PQPN(BTTN类1302的实例/对象)为止,其中这种调用返回对节点的DTT/BTT的只读视图或只读副本的引用,如先前所描述。因此,物理查询计划的根节点的评估方法1212将最终返回对该根节点的DTT的只读视图或只读副本的引用。控制从框1702传递到框1704。
在框1704中,对DTT的获取有效行方法1424(也可被称为获取有效数据记录方法)进行调用,针对DTT的引用是由当前查询计划的根节点的评估方法1212返回的,从而传递评估开始时间。控制从框1704传递到框1706,在框1706中,创建要发送到客户端的初始查询结果。在一个实施例中,框1706包括:从来自获取有效行方法(也可被称为获取有效数据记录方法)的数据记录中移除表的valid_from和valid_to列(即,移除valid_from和valid_to字段),以创建初始查询结果。
控制从框1706传递到框1708,在框1708中,提供对当前物理查询计划的根节点的引用以及初始查询结果,以用于发送到提交了SQL查询的客户端。在一个实施例中,查询执行器240是利用单个方法实现的,并且该单个方法返回对当前物理查询计划的根节点的引用以及初始查询结果。可以通过下述方式来调用该单个方法:1)在非订阅SQL查询的情况下的过程和客户端通信管理器(PCCM)214,以及所返回的对根节点的引用被忽略;以及2)在订阅SQL查询的情况下的订阅管理器(在本文中稍后描述)。在替代实施例中,查询执行器240可以使用多于单个方法来实现。例如,在一个这种实施例中,查询执行器240被实现为两个单独的方法:一个方法,其在非订阅SQL查询的情况下被PCCM 214调用并且返回初始查询结果而不是对当前物理查询计划的根节点的引用;以及另一个方法,其在订阅SQL查询的情况下被订阅管理器(在本文中稍后描述)调用并且返回对当前物理查询计划的根节点的引用以及初始查询结果。在另一个这种实施例中,查询执行器240被实现为两个单独的方法:一个方法,其返回初始查询结果并且被PCCM 214和订阅管理器(在本文中稍后描述)两者调用;以及另一个方法,其返回对当前物理查询计划的根节点的引用并且被订阅管理器(而不是PCCM 214)调用。
图18是根据一个实施例的评估方法1212的流程图。因此,调用物理查询计划的当前节点的DTTN.评估方法1212。如先前所描述,当评估方法1212被调用时向其传递评估开始时间。图18以判定框1802开始,在框1802中,判定是否需要计算。如果否,则控制传递到框1816;否则,控制传递到框1808。框1802是如果执行不被需要则避免执行(无论它是增量式执行还是完全重新执行)的优化(在上文被称为跳过更新)。
在一个实施例中,框1802包括框1804和1806。在框1804中,确定评估开始时间是否小于最后刷新时间(即,比最后刷新时间更早的时间)(将被传递给评估方法1212的评估开始时间与当前节点的最后刷新时间字段1210中的时间进行比较)。如果是这样,则控制传递到框1816;否则,控制传递到框1806。框1804是如下优化:该优化避免了如果当前节点在传递的评估开始时间之后被刷新则实行当前节点的查询计划操作、以及调用任何子节点的评估方法的情况。例如,这可能在支持并行执行查询计划和/或支持“截至一过去日期”的执行查询的实施例中发生。在框1806中,确定最后刷新时间是否小于最后更新时间(即,比最后更新时间更早的时间)(在实现最后更新时间字段1216的实施例中,确定当前节点的最后刷新时间字段1210中的时间是否小于最后更新时间字段1216中的时间)。如果是这样,则控制传递到框1808;否则,控制传递到框1816。框1806是如下优化:该优化确定在最后刷新之后是否已经发生了更新,并且因此确定是否需要刷新当前节点,这是因为它(直接或间接地)取决于脏BTT(即,已知该节点的输入已经改变)。
在框1808中,对当前节点的(一个或多个)子引用字段1208中的每个节点的评估方法执行调用,从而传递评估开始时间。控制从框1808传递到框1810。
如框1810中所示,对(一个或多个)TT对象的获取插入行和获取删除行方法(也可被称为获取插入数据记录方法和获取删除数据记录方法)进行一次或多次调用,针对(一个或多个)TT对象的(一个或多个)引用是由所调用的(一个或多个)子节点的(一个或多个)评估方法返回的,从而向那些方法传递以下任一项:1)来自当前节点的最后刷新时间字段1210的最后刷新时间和评估开始时间,以检索增量式地插入和删除的数据记录(如果当前节点支持查询计划操作的增量式执行的话);或者2)适当晚的时间(例如,MAX(评估开始时间,最后更新时间),无穷大)和适当早的时间(例如,0),以检索全部的所插入和删除的数据记录(如果当前节点不支持查询计划操作的增量式执行,或者如果节点支持查询计划操作的增量式执行但仍然要求全部的所插入和删除的数据记录以实行对应的查询计划操作(例如,增量式JOIN))。如上文讨论的,如果具有作为(一个或多个)输入的一个或多个时态表的集合的查询计划运算符的执行包括从那些时态表中的至少一个来访问仅增量式地插入和删除的数据记录(△,与全部数据记录相对),则该执行是“增量式执行”。相反地,如果具有作为(一个或多个)输入的一个或多个时态表的集合的查询计划运算符的执行需要从该集合中的全部时态表访问全部的所插入和删除的数据记录,则该执行是“完全执行”。给定查询计划运算符可以被实现成实行增量式执行、完全执行或两者(并且在两者的情况下,其在可能的时候实行增量式执行)。控制从框1810传递到框1812。
在框1812中,实行当前节点的查询计划操作,并且将结果合并到由当前节点所标识的(在TT引用字段1206中标识的)DTT中。在一个实施例中,通过调用由当前节点的TT引用字段1206所标识的DTT的(一个或多个)方法1322中的适当方法来合并该结果。控制从框1812传递到框1814。
在框1814中,设置当前节点的最后刷新时间[如果实现了最后更新时间字段1216,则设置成最后更新时间,或者如果没有实现,则设置成评估开始时间],并且控制传递到框1816。
在框1816中,返回对在当前节点的TT引用字段1206中标识的DTT的只读副本或只读视图的引用。
图19是根据一个实施例的(一个或多个)方法1322的流程图。在框1902中,通过修改时态表的内容来更新BTT。在一个实施例中,BTTN调用了在该BTTN的TT引用字段1306中标识的BTT的(一个或多个)方法1422中的(一个或多个)适当方法,并且响应于该(一个或多个)调用,BTT更新TT字段1406中的数据。控制从框1902传递到框1904。在框1904中,在实现了通知脏的方法1220的实施例中,对BTTN的(一个或多个)父引用字段1314中标识的(一个或多个)节点的通知脏的方法1220进行调用,从而传递最后更新时间。
图20是根据一个实施例的通知脏的方法1220的流程图。在框2002中,当前节点的最后更新时间字段1216被设置成被传递的最后更新时间。控制从框2002传递到框2004,在框2004中,对当前节点的(一个或多个)父引用字段1214中的(一个或多个)节点的通知脏的方法进行调用,从而传递最后更新时间。
订阅
图21是根据一个实施例的订阅SQL查询的流程图。在框2102中,响应于接收到订阅SQL查询,RDBMS生成和执行物理查询计划,并且在执行之后将该物理查询计划和所导出的时态表保留在存储器中(即,在易失性存储器、非易失性存储器和/或其组合中)。控制从框2102传递到框2104,在框2104中,初始查询结果被发送到提交了订阅SQL查询的客户端。可以以先前描述的方式实行框2102和2104。控制从框2104传递到框2106。
在框2106中,做出是时候进行订阅更新的确定。订阅更新的目的是要响应于时态表中的作为时态关系数据库的部分并且订阅SQL查询需要从其中访问数据的至少给定的一个时态表的内容的(一个或多个)修改来提供更新。然而,如先前所描述,不同的实施例可以利用不同的定时来响应于这种修改(例如,立即地;在支持懒惰更新的实施例中,它被延迟直到一个或多个事件发生(例如,向客户端发送查询结果(例如,初始或增量式)的需要、固定的时间流逝量、可编程的时间流逝量、基于节点和边(例如,基于节点与其他节点的连接性、节点的类型、它们的历史使用等)的所计算的时间量流逝、其他SQL查询的到达率超出阈值、和/或可用的计算资源落在阈值以下),如先前所描述)。进一步地,不同的实施例可以不同地分配对于实行框2106的责任。作为示例,在本文中稍后来描述推模型实施例和拉模型实施例。
控制从框2106传递到框2108,在框2108中,使用在执行之后被保留在存储器中的物理查询计划和所导出的时态表来生成增量式查询结果。如先前所描述,可以使用增量式执行来避免查询计划操作的完全重新执行,并且可以使用跳过更新来避免某些查询计划操作的执行。此外,在一个实施例中,要被发送给客户端的增量式查询结果仅包括对已经被发送给客户端的结果的改变(在本文中稍后描述示例性格式)。
控制从框2108传递到框2110,在框2110中,将订阅的增量式查询结果发送到被订阅至订阅SQL查询的客户端。在支持多个客户端同时被订阅至相同SQL查询的实施例中,来自订阅的增量式查询结果可以被发送到多个客户端。
图22是图示了根据一个实施例的具有附加框以支持非订阅和订阅SQL查询两者的关系数据库管理系统212的框图。图22重现了来自图2的下述内容:1)(一个或多个)数据库驱动器204;2)关系数据库管理系统212,包括过程和客户端通信管理器(PCCM)214、解析器218、查询执行器240、物理查询计划242、时态关系数据库262的基本时态表260、以及所导出的时态表264。图22还再现了SQL语句216,其可以包括订阅SQL查询。PCCM 214将这种订阅SQL查询2218路由到订阅管理器2220,该订阅管理器2220包括订阅方法2222和增量式更新方法2224。在一个实施例中,PCCM 214从正在发送订阅SQL查询的客户端的(一个或多个)数据库驱动器204中的一个接收“订阅”远程过程调用,并且PCCM 214调用订阅方法2222,从而传递订阅SQL查询。再次,箭头线表示某种类型的耦合,诸如数据流和/或连接。
订阅方法2222 1)将订阅SQL查询的SQL查询部分(2228)传输到解析器218,以使得将生成和执行物理查询计划,2)从查询执行器240接收所得到的初始查询结果,以及3)使初始查询结果连同订阅标识符(ID)被PCCM 214发送到提交了该订阅SQL查询的客户端(参见查询结果和订阅ID 2212)。在一些实施例中,订阅方法2222针对每个订阅SQL查询生成在当前订阅当中唯一的订阅ID,并且将该订阅ID(连同初始查询结果)返回给PCCM 214以返回到发送了订阅SQL查询的客户端的数据库驱动器204中的一个;以及数据库驱动器保留针对该客户端的订阅SQL查询的订阅ID。在替代实施例中,将标识通过其发送了订阅SQL查询的“唯一连接”的数据用作订阅ID(即,“唯一连接”唯一地标识客户端和订阅SQL查询的组合,诸如通过使用由(一个或多个)数据库驱动器204中的给定的一个提交的每个订阅SQL查询的唯一TCP连接)。进一步地,如由SQL语句2226图示的,PCCM 214像以前一样将全部其他的SQL语句216(不是订阅SQL查询2218的那些SQL语句)传输到解析器218。解析器218像以前一样生成内部表示226。
订阅方法2222还针对每个订阅SQL查询在(一个或多个)订阅对象2230中创建订阅对象。(一个或多个)订阅对象2230中的每一个包括:1)可选地,订阅ID(标识符)字段2232;2)根节点引用字段2234;3)最后订阅更新时间字段2236;4)订阅更新方法2238;以及5)在使用推模型(其需要脏通知图)的实施例中,为通知脏的方法2240。订阅ID字段2232要存储针对该订阅的订阅ID,订阅ID可以用于跟踪目的。根节点引用字段2234要存储对针对订阅SQL查询生成的物理查询计划的根PQPN(例如,DTTN)的物理查询计划242中的位置的引用。最后订阅更新时间字段2236要存储反映了当订阅最后被更新时的时间的时间戳。订阅更新方法2238在被执行时使得执行由根节点引用字段2234中的其根节点标识的物理查询计划。响应于来自根节点引用字段2234中标识的根节点的对通知脏的方法2240的调用来执行通知脏的方法2240,这表示已经对BTT做出了修改,从该BTT访问用于订阅SQL查询的数据。通知脏的方法2240的执行使得订阅更新方法2238被执行。当初始化订阅对象时,订阅对象利用对该订阅对象的引用来调用根节点引用字段2234中的根节点的添加父方法1218,并且该添加父方法1218将对订阅对象的引用存储在该根节点的(一个或多个)父引用字段1214中;这添加了订阅对象作为双向查询计划图的根节点中的适当根节点的父节点,以使得订阅对象是所生成的脏通知有向图的部分。在操作中,当修改BTT时,脏通知有向图被用来通过从该脏通知有向图的根节点(例如,封装了经修改的BTT的BTTN)向上至该脏通知有向图的(一个或多个)叶节点(它们均是查询计划的根节点或者是在该根节点的顶部上添加的订阅对象)做出递归调用来标识受修改影响的每个节点,从而允许脏指示流动通过(一个或多个)中间节点并且向上至消耗该BTT的(一个或多个)查询计划的(一个或多个)根节点和/或(一个或多个)订阅对象。
增量式更新方法2224便于确定对订阅SQL查询的增量式更新。(一个或多个)数据库驱动器204和增量式更新方法2224可以在实现了如稍后在本文中描述的推或拉模型的实施例中被不同地实现。例如,在实现了拉模型的实施例中,每次期望更新时,可以通过(一个或多个)数据库驱动器204的获取更多结果方法(未示出)经由远程过程调用来调用增量式更新方法2224,而在实现了推模型的实施例中,可以通过(一个或多个)数据库驱动器204的监听方法(未示出)来调用一次增量式更新方法2224。
如先前所描述,在一个实施例中,将针对订阅SQL查询的查询计划以及由该查询计划的节点标识的所导出的时态表在执行之后保留在存储器中,至少直到提交了该订阅SQL查询的客户端提交针对该订阅SQL查询的关闭订阅消息为止。这种关闭订阅消息可以包括例如:订阅ID,用以标识要关闭的订阅SQL查询。在一个实施例中,PCCM 214还向订阅管理器2220发送这种关闭订阅消息(未示出),该订阅管理器2220:1)确定物理查询计划的一个或多个节点是否不再需要在执行之后被保留在存储器中,并且采取必要的动作以允许它们的移除以及高速缓存234中的对应条目的移除(例如,从高速缓存234中移除对应条目);以及2)删除针对该订阅SQL查询的订阅对象。
图23是根据一个实施例的订阅方法2222的流程图。在框2302中,接收订阅SQL查询,并且控制传递到框2304。在框2304中,引起订阅SQL查询的SQL查询部分的执行。在一个实施例中,该执行包括:生成和执行针对SQL查询的物理查询计划(涉及解析器218、查询重写器224、查询优化器230(包括查询计划连接器232)、以及查询执行器240——并且因此,该生成可以包括先前描述的对现有节点和边的重新使用/合并,并且该执行可以包括增量式执行);例如,响应于来自订阅方法2222的调用,该方法协调订阅SQL查询的初始执行。控制从框2304传递到框2306。
在框2306中,响应于从查询执行器240接收到对订阅SQL查询的物理查询计划的根节点的引用,创建和初始化订阅对象。在一个实施例中,该初始化包括:1)将订阅ID存储在订阅ID字段2232中(如果被实现的话);2)将对物理查询计划的根节点的引用存储在根节点引用字段2234中;3)将足够早的时间存储在最后订阅更新时间字段2236中以确保在第一次订阅更新时捕获全部更新(例如,结果表中的valid_from和valid_to时间戳的最大值);以及4)在实现了添加父方法1280和1318的实施例中,利用对被初始化的订阅对象的引用来调用根节点引用字段2234中的根节点的添加父方法1218。
控制从框2306传递到框2308。在框2308中,响应于从查询执行器240接收到初始查询结果,将该初始查询结果提供给PCCM 214,以便发送至提交了订阅SQL查询的客户端。
图24A是根据实现了拉模型的实施例的增量式更新方法2224的流程图。在该实施例中,每次RDBMS客户端确定期望对先前提交的订阅SQL查询进行更新时,客户端就调用(一个或多个)数据库驱动器204中的获取更多结果方法。获取更多结果方法向RDBMS 212进行远程过程调用(RPC),以进行订阅SQL查询的增量式更新(在其中订阅ID是订阅方法2222生成的值的实施例中,由数据库驱动器发送订阅ID;在其中订阅ID数据标识了通过其发送了订阅SQL查询的唯一连接的实施例中,通过该唯一连接进行RPC,这是因为由于该连接先前已经关联于订阅SQL查询提交而在客户端与PCCM 214之间建立,因此该连接本身可以被用来标识订阅SQL查询)。响应于此,PCCM 214调用增量式更新方法2224,从而传递订阅ID。在框2402中,从PCCM 214接收这种调用,并且控制传递到框2404。
在框2404中,对由订阅ID标识的订阅对象的订阅更新方法2238进行调用。尽管在一个实施例中,订阅管理器2220维持将订阅ID映射到(一个或多个)订阅对象2230的数据结构(例如,表),但是替代实施例可以使用其他类型的公知机制来定位(一个或多个)订阅对象2230中的适当的一个。控制从框2404传递到框2406。
如框2406中所示,响应于从订阅对象的订阅更新方法2238接收到增量式查询结果,将增量式查询结果返回到PCCM 214,以便发送到期望对先前提交的订阅SQL查询的更新的客户端。尽管在一个实施例中,增量式查询结果由PCCM 214(其管理连接并由客户端调用)发送给客户端,但是在另一实施例中,增量式更新方法经由唯一连接将增量式查询结果发送给客户端,订阅SQL查询是通过该唯一连接来发送的(例如,在其中订阅ID是标识了通过其发送了订阅SQL查询的唯一连接的数据的实施例中,使用订阅ID)。
图24B是根据实现了推模型的实施例的增量式更新方法2224的流程图。在第一个这种实施例中,在提交订阅SQL查询之后,客户端代码调用一次(一个或多个)数据库驱动器204中的监听方法,以接收对订阅SQL查询的基于推的更新。监听方法针对特定的订阅SQL查询向RDBMS 212进行远程过程调用(RPC)(在其中订阅ID是由订阅方法2222生成的值的实施例中,订阅ID由(一个或多个)数据库驱动器204发送;在其中订阅ID是标识了通过其发送了订阅SQL查询的唯一连接的数据的实施例中,不需要发送订阅ID,这是因为由于该连接先前响应于订阅SQL查询提交而在客户端与PCCM 214之间建立,因此该连接本身标识了订阅SQL查询)。响应于此,PCCM 214调用增量式更新方法2224,包括标识通过其发送了订阅SQL查询的连接的数据(在如先前所描述的一些实施例中,该数据是订阅ID;在其中订阅ID是由订阅方法2222生成的值的实施例中,还发送订阅ID)。在框2412中,从PCCM 214接收这种调用,并且控制传递到框2414。尽管在本段中描述的第一实施例中,订阅ID是间接地通过客户端代码从订阅方法2222提供给增量式更新方法2224的,但是替代实施例不同地进行操作。例如,在一个这种替代实施例中,框2302包括标识数据库驱动器内的回调(call back)方法(诸如,“关于数据更新(On Data Update)”的方法等,其可以作为函数指针、函数对象等被传递给监听方法)的数据;框2308包括:将来自订阅方法2222的订阅ID在RDBMS 212内提供给增量式更新方法2224(例如,作为对增量式更新方法的论据(argument),经由共享存储器的区域,经由其他进程间通信机制等),与通过客户端代码相对;在这种情况下,框2412不涉及通过PCCM的调用以监听来自客户端代码的监听方法的RPC。
在框2414中,利用订阅对象和连接信息来创建订阅线程,并且该订阅线程:1)调用(一个或多个)订阅对象2230中的适当的一个的根节点引用字段2234中的根节点的添加父方法1218,从而传递对该订阅对象的引用;并且添加父方法1219(如先前所描述)将对订阅对象的引用存储在该根节点的(一个或多个)父引用字段1214中;以及2)进行休眠,等待订阅对象的通知脏的方法1220要被根节点的通知脏的方法调用。控制从框2414传递到框2416。
如框2416中所示,每次通过对来自根节点的通知脏的方法1220的订阅对象的通知脏的方法2240(其被传递最后更新时间)的调用来唤醒订阅线程时,该订阅线程调用订阅对象的订阅更新方法2238(向它传递最后更新时间,该最后更新时间是通过通知脏的方法2240传递给它的),并且然后响应于接收到来自订阅更新方法2238的增量式查询结果而使得增量式查询结果被推送到被订阅至SQL查询的客户端(例如,经由阻止来自数据库驱动器的调用(例如,RPC),经由通过与数据库驱动器建立的唯一连接发送数据(例如,经由RPC流式传输)等),并且然后回去休眠。尽管在一个实施例中,增量式查询结果由PCCM 214(其管理连接并且由客户端调用)发送给客户端,但是在另一实施例中,增量式更新方法2224经由在对增量式更新方法2224的调用中标识的唯一连接将增量式查询结果发送给客户端(例如,在其中订阅ID是标识了通过其发送了订阅SQL查询的唯一连接的数据的实施例中,使用订阅ID)。在其中框2302包括标识了数据库驱动器中的回调方法的数据的实施例中,数据库驱动器调用该回调方法以向这种方法提供增量式查询结果。
图25是根据一个实施例的订阅更新方法2238的流程图。该流程图可以被用在上述拉模型和推模型的实施例中。在框2502中,对订阅对象的根节点引用字段2234所标识的根节点的评估方法1212进行调用,从而传递评估开始时间。不同的实施例可以不同地设置评估开始时间(例如,在拉模型中,设置为当前时间(例如,截至调用该方法时的系统时间、客户端调用增量式更新方法的时间(如果它与方法调用一起发送的话)、接收到(例如,通过PCCM)对增量式更新方法的调用的时间),并且在推模型中,设置为最后更新时间)。控制从框2502传递到框2504。
在框2504中,对TT对象的获取插入行和获取删除行方法(也可被称为获取插入数据记录方法和获取删除数据记录方法)进行调用,针对该TT对象的引用或视图是通过被调用的根节点的评估方法返回的,从而向那些方法传递来自订阅对象的最后订阅更新时间字段2236的评估开始时间和最后订阅更新时间。控制从框2504传递到框2506。
在框2506中,创建增量式查询结果。在一个实施例中,增量式查询结果是要发送给客户端的改变列表。在一个实施例中,该改变列表针对每个改变(即,对表示先前计算的查询结果的时态表(由对应查询计划的根节点标识的时态表)的改变)包括:1)这种时态表的对应数据记录的每一列中的值;2)改变类型(例如,插入或删除);以及3)标识了改变的时间的时间戳。在一个实施例中,通过下述方式来从在框2504中返回的数据记录生成改变列表:1)移除“valid_from”和“valid_to”列;2)添加存储了改变类型的“改变类型”列(其指示针对每个数据记录,该数据记录被是插入还是删除);以及3)添加“改变的时间”列,该列存储标识了改变的时间的时间戳(其指示针对每个数据记录,该数据记录在何时被插入或删除)。控制从框2506传递到框2508。
在框2508中,更新订阅对象的最后订阅更新时间字段2236[在拉模型实施例中,更新成评估开始时间,或者在推模型实施例中,更新成最后更新时间]。控制从框2508传递到框2510。
在框2510中,使增量式查询结果被发送到被订阅至SQL查询的客户端。在使用拉模型的实施例中,订阅更新方法2238由订阅管理器2220的增量式更新方法2224调用,并且增量式查询结果通过订阅管理器2220往回发送到客户端(其可以通过PCCM 214将增量式查询结果发送到客户端,或者经由在对订阅管理器2220的调用中标识的唯一连接发送到客户端本身)。使用拉模型的替代实施例可以不同地进行操作(例如,订阅更新方法2238可以经由在对订阅更新方法2238的调用中标识的唯一连接将增量式查询结果发送到客户端本身)。类似地,在使用推模型的实施例中,对于向客户端发送增量式查询结果的责任可能有所不同(例如,订阅线程可以将其发送给PCCM 214,PCCM 214将其发送到客户端;订阅更新方法2238可以经由在对订阅更新方法2238的调用中标识的唯一连接将增量式查询结果发送到客户端本身)。
示例性用例
以上实施例中的各种实施例可以被组合以满足某些用例。作为示例,一个用例是金融市场的增量式风险汇总。该用例通常需要由使用仪表板的不同用户电子设备处的多个最终用户对近实时数据与大量历史数据(以提供长期视图)的组合进行复杂分析。某些实施例利用图11的用户界面层1100和关系数据库管理系统212来支持该用例。具体地,用户界面层1100支持仪表板的使用,该仪表板包括被同时呈现给不同的最终用户电子设备上的多个(实际上许多个)最终用户(从而,导致多个同时重叠的查询计划)的相同仪表板;并且在某些实施例中,是用于创建、编辑和共享仪表板并且启用数据发现的自助式最终用户仪表板。关系数据库管理系统212(其在某些实施例中是存储器中和分析型关系数据库管理系统)管理时态关系数据库、是同时支持多个客户端的服务器、同时支持多个SQL查询(包括订阅SQL查询)、在执行之后将查询计划保留在存储器中(包括根和中间PQPN)、在执行之后将那些查询计划的所导出的时态表保留在存储器中(包括针对根和中间PQPN)、支持重叠的查询计划(包括中间和叶PQPN的共享)、以及支持针对至少某些查询计划运算符的增量式查询计划执行。因此,在一些这种实施例中,(一个或多个)仪表板中的内容元素可以近实时地更新。这种近实时的性能(包括针对相对大的查询深度的SQL查询)特别适合于金融市场的增量式风险汇总。附加地或替代地,在一些实施例中,RDBMS 212是事务性RDBMS,并且使用面向列的组织在存储器中存储时态表(BTT和DTT)。
进一步地,在某些这种实施例中,用户界面层1100支持依赖于BI查询语言的自助式最终用户仪表板,并且BI服务1102在将这种语言传输到关系数据库管理系统212之前将这种语言转换成SQL语句(包括SQL查询)。在一个这种实施例中,BI查询语言和SQL两者都已被扩展成支持如本文中所述的订阅,以使得BI查询语言订阅被转换成被提交到关系数据库管理系统212的订阅SQL查询。
示例性电子设备
实施例的一个或多个部分可以使用软件、固件和/或硬件的不同组合来实现。电子设备使用机器可读介质(也称为计算机可读介质)来(内部地和/或通过网络与其他电子设备一起)存储和传输代码(其由软件指令组成,并且其有时被称为计算机程序代码或计算机程序)和/或数据,该机器可读介质诸如机器可读存储介质(例如,磁盘、光盘、只读存储器(ROM)、闪速存储器、相变存储器、固态驱动器(SSD))和机器可读传输介质(也称为载体)(例如,电学、光学、无线电、声学或其他形式的传播信号——诸如载波、红外信号)。因此,电子设备(例如,计算机)包括硬件和软件,诸如耦合到一个或多个机器可读存储介质的一组一个或多个处理器,以存储用于在该组处理器上执行的代码和/或以存储数据。例如,由于非易失性存储器可以在关闭电子设备时(在移除电源时)保存代码/数据,因此电子设备可以包括含有代码的非易失性存储器(具有较慢的读/写时间,例如磁盘、光盘、只读存储器(ROM)、闪速存储器、相变存储器、SSD),并且在打开电子设备时,要由该电子设备的(一个或多个)处理器执行的那部分代码从非易失性存储器被复制到该电子设备的易失性存储器(例如,动态随机存取存储器(DRAM)、静态随机存取存储器(SRAM))中,这是因为易失性存储器具有更快的读/写时间(并且要对其进行操作的全部数据中的一些也被存储在该易失性存储器中)。作为另一示例,电子设备可以包括非易失性存储器(例如,相变存储器)以在电子设备关闭时存储代码/数据,并且该相同的非易失性存储器具有足够快的读/写时间,使得可以将代码/数据直接提供给(一个或多个)处理器(例如,加载到(一个或多个)处理器的高速缓存中),而不是将要执行的那部分代码复制到易失性存储器中;换言之,该非易失性存储器作为长期存储装置和主存储器两者进行操作,并且因此电子设备可以不具有或仅具有少量的用于主存储器的DRAM。典型的电子设备还包括一组一个或多个物理网络接口,以与其他电子设备建立网络连接(以使用传播信号来传输和/或接收代码和/或数据)。
图26图示了根据一个实施例的电子设备2604。图26包括:硬件2640,其包括一组一个或多个处理器2642和一组或一个或多个网络接口2644(无线和/或有线)、以及其中存储有软件2650的非暂时性机器可读存储介质2648。先前描述的最终用户客户端、BI服务和关系数据库管理系统212中的每一个都可以在一个或多个电子设备2604中实现。在一个实施例中,每一个最终用户客户端在电子设备2604中的单独的一个中实现(例如,在由最终用户操作的最终用户电子设备中;在这种情况下,每个这种最终用户电子设备中的软件2650包括用以实现最终用户客户端中的一个的软件,包括(一个或多个)数据库驱动器204和/或与BI服务1102对接的软件(例如,API、Web浏览器、本机客户端、BI门户、命令行界面等)中的一个),并且关系数据库管理系统212在一个或多个电子设备2604的单独的一组中实现(在这种情况下,软件2650是用以实现关系数据库管理系统212的软件);在操作中,最终用户电子设备和实现了RDBMS的(一个或多个)电子设备将被交换地耦合(例如,通过网络),并且将在它们之间(或通过一个或多个其他层(例如,BI服务,其可以在一组一个或多个电子设备中实现,该一组一个或多个电子设备与在其上实现RDBMS的一组一个或多个电子设备分离、重叠或相同(在这种情况下,软件2650包括用以实现BI服务的软件)))建立上面讨论的连接,以用于向RDBMS 212提交SQL查询并且返回查询结果。电子设备的其他配置可以在其他实施例(例如,其中在单个电子设备上实现最终用户客户端、BI服务(如果使用的话)和RDBMS的实施例)中使用。
在使用计算虚拟化的电子设备中,(一个或多个)处理器2642通常执行软件以实例化虚拟化层2654和(一个或多个)软件容器2662A-R(例如,具有操作系统级的虚拟化,该虚拟化层2654表示允许创建多个软件容器2662A-R(表示单独的用户空间实例,并且也被称为虚拟化引擎、虚拟专用服务器或监狱(fail))的操作系统(或在基本操作系统上执行的填充码(shim))的内核,该多个软件容器均被用来执行一组一个或多个应用;在完全虚拟化的情况下,虚拟化层2654表示管理程序(有时被称为虚拟机监视器(VMM))或在主机操作系统之上执行的管理程序,并且软件容器2662A-R均表示由管理程序运行的被称为虚拟机的紧密隔离形式的软件容器,并且可以包括来宾操作系统;在半虚拟化的情况下,利用虚拟机运行的操作系统或应用可能会意识到出于优化目的的虚拟化的存在)。再次,在其中使用计算虚拟化的电子设备中,在操作期间,在虚拟化层2654上的软件容器2662A内执行软件2650的实例(被图示为实例2676A)。在其中不使用计算虚拟化的电子设备中,在“裸机(bare metal)”电子设备2604上执行主机操作系统之上的实例2676A。实例2676A以及虚拟化层2654和软件容器2662A-R(如果被实现的话)的实例化被统称为(一个或多个)软件实例2652。
电子设备的替代实施例可以具有来自上面描述的实施例的众多变化。例如,定制的硬件和/或加速器也可能被用在电子设备中。
替代实施例
尽管各图中的流程图示出了由某些实施例实行的操作的特定次序,但是这种次序是示例性的(例如,替代实施例可以按不同的次序来实行操作、组合某些操作、并行实行某些操作等)。
此外,虽然已经在若干个实施例的方面描述了本发明,但是本领域技术人员将认识到,本发明不限于所描述的实施例,并且可以利用在所附权利要求的精神和范围内的修改和变更来实践。本描述因此要被认为是说明性的而非限制性的。
Claims (51)
1.一种计算机实现的方法,其包括:
响应于在关系数据库管理系统处接收到将需要从关系数据库管理系统管理的时态关系数据库的时态表访问数据的多个结构化查询语言SQL查询,来执行所述多个SQL查询以生成针对每个查询的查询结果,执行所述多个SQL查询包括:
生成和执行在执行之后被保留在存储器中的多个查询计划,其中所述多个查询计划中的每一个包括通过边连接的节点的有向图,其中每一个有向图表示查询计划运算符的有序集合,所述查询计划运算符在被执行时生成针对所述多个SQL查询中的一个的查询结果,其中有向图的每一个节点表示查询计划运算符中的一个,其中每一个有向图通过它的至少一个边连接到另一个有向图的至少一个节点,以使得那些有向图共享至少一个节点,其中每一个有向图的节点中的至少一个标识时态关系数据库的时态表中的一个,并且其中每一个有向图的节点中的至少另一个标识在执行之后被保留在存储器中并且被创建以存储执行该节点所表示的查询计划运算符的结果的时态表;以及
将针对所述多个SQL查询中的每一个的查询结果传输到一个或多个客户端,所述一个或多个客户端向关系数据库管理系统传输了该SQL查询。
2.根据权利要求1所述的方法,其中,有向图的每一个节点标识时态关系数据库的时态表中的一个,或者标识被创建以存储执行该节点所表示的查询计划运算符的结果的时态表中的一个。
3.根据权利要求1所述的方法,其中,所述多个查询计划中的至少两个共享节点和至少一个边的子图。
4.根据权利要求1所述的方法,其中,在生成和执行所述多个查询计划中的另一个之前生成和执行所述多个查询计划中的一个。
5.根据权利要求1所述的方法,其中,被创建以存储执行查询计划运算符中的一个的结果的每一个时态表被保留在存储器中达与标识该时态表的节点在执行之后被保留在存储器中至少一样长的时间。
6.根据权利要求1所述的方法,其中,每一个有向图以根节点开始,包括一个或多个中间节点,并且在一个或多个叶节点中结束,其中每个有向图的根节点和一个或多个中间节点均针对该节点将该有向图的一个或多个其他节点标识为子节点,其中根节点和中间节点中的每一个所表示的每一个查询计划运算符在该节点的一个或多个子节点标识的时态表中的一个或多个上进行操作。
7.根据权利要求6所述的方法,其中,由一个或多个叶节点中的每一个所表示的查询计划运算符的执行导致从时态关系数据库中的时态表中的一个检索数据。
8.根据权利要求6所述的方法,其中,生成和执行所述多个查询计划包括:
针对查询计划的每一个节点来维持如下密钥:所述密钥基于该节点以及该节点的零个或多个所标识的子节点。
9.根据权利要求6所述的方法,其中,生成和执行所述多个查询计划包括:
针对查询计划的每一个节点来维持如下密钥:所述密钥仅表示包括该节点及其后代——如果有的话——的查询计划的那部分,而不表示由该节点的任何祖先节点表示的查询计划的任何部分。
10.根据权利要求1-6中任一项所述的方法,进一步包括:
响应于修改时态表中的作为时态关系数据库的部分并且所述多个SQL查询中的至少一个需要从其中访问数据的至少给定的一个时态表的内容,来实行以下各项:
增量式地更新由节点中的如下那些节点所标识的时态表中的那些时态表:所述那些节点属于针对所述多个SQL查询中的至少一个的查询计划的有向图并且直接或间接取决于标识了时态表中的所述给定的一个时态表的节点;以及
向客户端中的提交了所述多个SQL查询中的至少一个的那些客户端传输对所述多个SQL查询中的至少一个的查询结果的增量式更新。
11.根据权利要求1-9中任一项所述的方法,进一步包括:
针对所述多个SQL查询中的一个,向客户端中的将该SQL查询传输到关系数据库管理系统的一个客户端传输数据,所述数据标识了对自从向该客户端最后发送了该查询结果以来满足该SQL查询的查询结果的改变。
12.根据权利要求1-9中任一项所述的方法,其中,查询计划运算符中的一个或多个实行时态关系代数运算。
13.根据权利要求1-9中任一项所述的方法,其中,所述多个查询计划中的每一个在执行之后被保留在存储器中达与客户端中的至少一个要接收对针对其生成了该查询计划的所述多个SQL查询中的一个的更新至少一样长的时间。
14.根据权利要求1-3中任一项所述的方法,进一步包括:
响应于在关系数据库管理系统处接收到将需要从关系数据库管理系统管理的时态关系数据库访问数据的另一个SQL查询来生成和执行另一个查询计划,其中所述另一个查询计划包括通过边连接的节点的有向图,其中所述另一个查询计划的有向图表示查询计划运算符的有序集合,所述查询计划运算符在被执行时生成针对所述另一个查询计划的查询结果,其中针对所述另一个查询计划的有向图通过它的至少一个边连接到另一个有向图的至少一个节点,使得那些有向图共享至少一个节点,其中针对所述另一个查询计划的有向图的节点中的至少一个标识时态关系数据库的时态表中的一个,并且其中针对所述另一个查询的有向图的节点中的至少一个标识在执行之后被保留在存储器中并且被创建以存储执行该节点所表示的查询计划运算符的结果的时态表。
15.根据权利要求14所述的方法,其中:
每一个有向图以根节点开始,包括一个或多个中间节点,并且在一个或多个叶节点中结束,其中每个有向图的根节点和一个或多个中间节点均针对该节点将该有向图的一个或多个其他节点标识为子节点;
生成所述多个查询计划包括:
针对所述多个查询计划的每一个节点来维持如下密钥:所述密钥基于该节点以及该节点的一个或多个所标识的子节点;以及
生成和执行所述另一个查询计划包括:确定针对所述另一个查询计划的有向图可以基于所述密钥中的一个或多个、通过它的至少一个边连接到另一个有向图的至少一个节点。
16.根据权利要求1-9中任一项所述的方法,其中,所述多个SQL查询包括由关系数据库管理系统接收到的第一SQL查询和第二SQL查询,其中生成和执行所述多个查询计划包括:生成针对所述第一SQL查询的所述多个查询计划中的第一查询计划和针对所述第二SQL查询的所述多个查询计划中的第二查询计划,并且其中针对所述第二查询计划的有向图通过它的至少一个边连接到针对所述第一查询计划的有向图的至少一个节点,使得那些有向图共享至少一个节点。
17.根据权利要求16所述的方法,其中,由针对所述第一和第二查询计划的有向图共享的至少一个节点是被创建以存储执行由该节点所表示的查询计划运算符的结果的节点。
18.根据权利要求16所述的方法,其中,所述第二查询计划的生成和执行包括:增量式地执行由针对所述第一和第二查询计划的有向图共享的至少一个节点所表示的至少查询计划运算符。
19.根据权利要求16所述的方法,其中,所述第一SQL查询和所述第二SQL查询由关系数据库管理系统接收到,以分别填充第一仪表板内容元素和第二仪表板内容元素。
20.根据权利要求19所述的方法,其中,所述第一仪表板内容元素和所述第二仪表板内容元素是要由不同最终用户客户端显示的不同仪表板的部分。
21.根据权利要求19所述的方法,其中,所述第一仪表板内容元素和所述第二仪表板内容元素是要由相同最终用户客户端显示的相同仪表板的部分。
22.根据权利要求16所述的方法,其中,所述第一SQL查询是作为订阅SQL查询而传输的。
23.根据权利要求22所述的方法,其中,所述第二SQL查询是在生成了所述第一查询计划之后并且在所述第一查询计划由于是订阅SQL查询而在执行之后被保留在存储器中时被接收到的。
24.根据权利要求1-9中任一项所述的方法,其中,将节点中的一个连接到节点中的另一个的每一个边表示:它们分别是相对于彼此的父节点和子节点,并且子节点的结果可由父节点访问。
25.根据权利要求1-9中任一项所述的方法,其中,生成和执行包括:
作为生成有向图中的一个的部分,实行以下各项:
标识节点中的至少一个,节点中的所述至少一个是有向图中的较早生成的一个的部分并且可以被重新使用;以及
将连接到节点中的作为有向图中的较早生成的一个的部分的一个节点的边添加到有向图中的一个。
26.根据权利要求25所述的方法,其中,所添加的边连接到的节点中的一个是标识时态表的节点中的一个,所述时态表被创建以存储执行该节点所表示的查询计划运算符的结果,并且其中所述生成和执行包括:
作为执行有向图中的一个的部分,重新使用——包括根据需要增量式地更新——由所添加的边连接到的节点中的一个标识的时态表。
27.根据权利要求1-9中任一项所述的方法,其中,所述生成和执行包括:增量式地执行由有向图中的两个共享的节点中的一个所表示的至少查询计划运算符。
28.一种包括计算机程序代码的机器可读介质,所述计算机程序代码在由计算机执行时实施根据权利要求1-27中任一项所述的方法。
29.一种计算机实现的方法,其包括:
响应于关系数据库管理系统接收到的新提交的结构化查询语言SQL查询,来通过合并在执行之后被保留在存储器中的现有查询计划的至少一部分而生成针对所述新提交的SQL查询的查询计划,
其中,关系数据库管理系统管理包括时态表的时态关系数据库,
其中,现有查询计划包括通过边连接的节点的有向图,所述有向图表示查询计划运算符的有序集合,所述查询计划运算符在被执行时生成针对需要从时态关系数据库访问数据的较早提交的SQL查询的查询结果,
其中,针对所述新提交的SQL查询的查询计划包括通过边连接的有向图,所述有向图表示查询计划运算符的有序集合,所述查询计划运算符在被执行时将生成针对所述新提交的SQL查询的查询结果,
其中,针对所述新提交的SQL查询的有向图通过它的至少一个边连接到针对所述较早提交的SQL查询的有向图的至少一个节点,使得有向图共享至少一个节点,
其中,有向图的每一个节点表示查询计划运算符中的一个,
其中,每一个有向图的节点中的至少一个标识时态关系数据库的时态表中的一个,以及
其中,由有向图共享的节点中的至少一个标识在执行之后被保留在存储器中并且被创建以存储执行所表示的查询计划运算符的结果的时态表;
在修改了时态表中的作为时态关系数据库的部分并且至少现有SQL查询需要从其中访问数据的至少给定的一个时态表的内容之后,增量式地更新由现有查询计划的节点中的如下那些节点所标识的时态表中的那些时态表:所述那些节点存储执行查询计划运算符的结果并且直接或间接取决于标识时态表中的所述给定的一个时态表的节点;以及
向提交了所述较早提交的SQL查询的客户端传输数据,所述数据标识对由现有查询计划的有向图的节点中的根节点所标识的时态表的增量式更新。
30.根据权利要求29所述的方法,其中,被创建以存储执行查询计划运算符中的一个的结果的每一个时态表被保留在存储器中达与标识该时态表的节点在执行之后被保留在存储器中至少一样长的时间。
31.根据权利要求29或30所述的方法,其中,有向图的每一个节点标识时态关系数据库的时态表中的一个,或者标识被创建以存储执行该节点所表示的查询计划运算符的结果的时态表中的一个。
32.根据权利要求29或30所述的方法,其中,针对所述新提交的SQL查询的查询计划和现有查询计划共享节点和至少一个边的子图。
33.根据权利要求29或30所述的方法,其中,每一个有向图以根节点开始,包括一个或多个中间节点,并且在一个或多个叶节点中结束,其中每个有向图的根节点和一个或多个中间节点针对该节点将该有向图的一个或多个其他节点标识为子节点,其中由根节点和中间节点中的每一个表示的每一个查询计划运算符在该节点的一个或多个子节点所标识的时态表中的一个或多个上进行操作。
34.根据权利要求33所述的方法,其中由一个或多个叶节点中的每一个表示的查询计划运算符的执行导致了从时态关系数据库中的表中的一个检索数据。
35.根据权利要求33所述的方法,其中,生成针对所述新提交的SQL查询的查询计划包括:
针对每一个节点来维持如下密钥:所述密钥基于该节点以及该节点的零个或多个所标识的子节点。
36.根据权利要求33所述的方法,其中,生成针对所述新提交的SQL查询的查询计划包括:
针对每一个节点来维持如下密钥:所述密钥仅表示包括该节点及其后代——如果有的话——的查询计划的那部分,而不包括由该节点的任何祖先节点实行的查询计划的任何部分。
37.根据权利要求29或30所述的方法,其中,查询计划运算符中的一个或多个实行时态关系代数运算。
38.根据权利要求29或30所述的方法,其中,所述较早提交的SQL查询是订阅SQL查询,并且现有查询计划在执行之后被保留在存储器中达与客户端被订阅以接收对所述订阅SQL查询的更新至少一样长的时间。
39.根据权利要求29或30所述的方法,进一步包括:
从关系数据库管理系统向客户端传输针对所述新提交的SQL查询的查询结果。
40.根据权利要求29或30所述的方法,进一步包括:
从关系数据库管理系统向另一个客户端传输针对所述新提交的SQL查询的查询结果。
41.根据权利要求29或30所述的方法,其中:
每一个有向图以根节点开始,包括一个或多个中间节点,并且在一个或多个叶节点中结束,其中每个有向图的根节点和一个或多个中间节点均针对该节点将该有向图的一个或多个其他节点标识为子节点,其中针对每一个节点来维持如下密钥:所述密钥仅表示包括该节点及其后代——如果有的话——的查询计划的那部分,而不包括由该节点的任何祖先节点实行的查询计划的任何部分;以及
生成针对所述新提交的SQL查询的查询计划包括:确定针对所述新提交的SQL查询的查询计划的有向图可以基于所述密钥中的一个或多个、通过它的至少一个边连接到针对现有查询计划的有向图的节点中的至少一个。
42.根据权利要求29或30所述的方法,其中,所述较早提交的SQL查询和新提交的SQL查询由关系数据库管理系统接收到,以分别填充第一仪表板内容元素和第二仪表板内容元素。
43.根据权利要求42所述的方法,其中,所述第一仪表板内容元素和所述第二仪表板内容元素是要由不同最终用户客户端显示的不同仪表板的部分。
44.根据权利要求42所述的方法,其中,所述第一仪表板内容元素和所述第二仪表板内容元素是要由相同最终用户客户端显示的相同仪表板的部分。
45.根据权利要求29或30所述的方法,其中,所述新提交的SQL查询在现有查询计划在执行之后被保留在存储器中时由关系数据库管理系统接收到,这是因为所述较早提交的SQL查询是由客户端作为订阅SQL查询而传输的。
46.根据权利要求29或30所述的方法,其中,将节点中的一个连接到节点中的另一个的每一个边表示:它们分别是相对于彼此的父节点和子节点,并且子节点的结果可由父节点访问。
47.根据权利要求29或30所述的方法,其中所述生成包括:
标识现有查询计划的有向图的节点中的至少一个可以被重新使用;以及
将连接到所标识的节点的边添加到针对所述新提交的SQL查询的查询计划的有向图。
48.根据权利要求29或30所述的方法,进一步包括:
通过重新使用——包括根据需要增量式地更新——由有向图共享的至少一个节点标识的时态表来执行针对所述新提交的SQL查询的查询计划。
49.根据权利要求29或30所述的方法,进一步包括:
作为执行针对所述新提交的SQL查询的查询计划的部分,增量式地执行由有向图共享的至少一个节点所表示的查询计划运算符。
50.根据权利要求29或30所述的方法,其中,增量式地更新包括:增量式地执行由现有查询计划的节点中的如下那些节点中的一个或多个所表示的查询计划运算符中的一个或多个:所述那些节点直接或间接取决于标识时态表中的所述给定的一个时态表的节点。
51.一种包括计算机程序代码的机器可读介质,所述计算机程序代码在由计算机执行时实施根据权利要求29-50中任一项所述的方法。
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201762489935P | 2017-04-25 | 2017-04-25 | |
US62/489935 | 2017-04-25 | ||
PCT/EP2018/055503 WO2018197084A1 (en) | 2017-04-25 | 2018-03-06 | Query plan generation and execution in a relational database management system with a temporal-relational database |
Publications (2)
Publication Number | Publication Date |
---|---|
CN110651264A CN110651264A (zh) | 2020-01-03 |
CN110651264B true CN110651264B (zh) | 2023-08-08 |
Family
ID=61691455
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201880027557.0A Active CN110651264B (zh) | 2017-04-25 | 2018-03-06 | 具有时态关系数据库的关系数据库管理系统中的查询计划生成和执行 |
Country Status (5)
Country | Link |
---|---|
US (2) | US10496644B2 (zh) |
EP (1) | EP3446242B1 (zh) |
JP (1) | JP6850907B2 (zh) |
CN (1) | CN110651264B (zh) |
WO (1) | WO2018197084A1 (zh) |
Families Citing this family (33)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN108885634B (zh) * | 2016-10-24 | 2022-09-09 | 北京亚控科技发展有限公司 | 一种基于时空数据库的对数据对象的检索方法 |
US11093496B1 (en) * | 2017-11-22 | 2021-08-17 | Amazon Technologies, Inc. | Performance-based query plan caching |
US10803059B2 (en) * | 2018-01-30 | 2020-10-13 | Verizon Patent And Licensing Inc. | Searching using query graphs |
JP7006769B2 (ja) * | 2018-03-14 | 2022-01-24 | 日本電気株式会社 | 検索文活用装置および検索文活用方法 |
US11599539B2 (en) * | 2018-12-26 | 2023-03-07 | Palantir Technologies Inc. | Column lineage and metadata propagation |
US11734707B2 (en) * | 2019-01-17 | 2023-08-22 | Kleeberg Bank | Reward manager |
US11360977B2 (en) * | 2019-04-01 | 2022-06-14 | Sap Se | Selectively allowing query optimization in query processing |
EP3722966A1 (en) * | 2019-04-10 | 2020-10-14 | Ivalua Sas | Enterprise resource planning system and supervision method of sql queries in such a system |
US11663498B2 (en) | 2019-05-21 | 2023-05-30 | Sisense Ltd. | System and method for generating organizational memory using semantic knowledge graphs |
US11687553B2 (en) | 2019-05-21 | 2023-06-27 | Sisense Ltd. | System and method for generating analytical insights utilizing a semantic knowledge graph |
US20200409955A1 (en) * | 2019-05-21 | 2020-12-31 | Sisense Ltd. | System and method for improved cache utilization using an organizational memory to generate a dashboard |
US11698918B2 (en) | 2019-05-21 | 2023-07-11 | Sisense Ltd. | System and method for content-based data visualization using a universal knowledge graph |
US11216511B1 (en) | 2019-07-16 | 2022-01-04 | Splunk Inc. | Executing a child query based on results of a parent query |
US11604799B1 (en) * | 2019-07-16 | 2023-03-14 | Splunk Inc. | Performing panel-related actions based on user interaction with a graphical user interface |
US11644955B1 (en) | 2019-07-16 | 2023-05-09 | Splunk Inc. | Assigning a global parameter to queries in a graphical user interface |
US11269871B1 (en) | 2019-07-16 | 2022-03-08 | Splunk Inc. | Displaying multiple editable queries in a graphical user interface |
US11636128B1 (en) | 2019-07-16 | 2023-04-25 | Splunk Inc. | Displaying query results from a previous query when accessing a panel |
US11386158B1 (en) | 2019-07-16 | 2022-07-12 | Splunk Inc. | Recommending query parameters based on tenant information |
US11768833B2 (en) | 2019-07-24 | 2023-09-26 | International Business Machines Corporation | Optimizing relational online analytical processing sort operations |
WO2021028968A1 (ja) * | 2019-08-09 | 2021-02-18 | 日本電気株式会社 | 情報処理装置、情報処理システム、情報処理方法、及びコンピュータ可読媒体 |
US10949178B1 (en) * | 2019-12-13 | 2021-03-16 | Intuit Inc. | Method and system for decomposing a global application programming interface (API) graph into an application-specific API subgraph |
US11258669B2 (en) * | 2020-07-14 | 2022-02-22 | Vmware, Inc. | Differential dataflow approach for computing grouping membership in network controllers |
KR102202792B1 (ko) * | 2020-08-06 | 2021-01-15 | (주)시큐레이어 | 클러스터 기반 처리 시스템을 이용해 동종 및 이기종 데이터 소스에 대해 멀티 캐싱을 수행하는 방법 및 장치 |
CN112069201A (zh) * | 2020-09-04 | 2020-12-11 | 北京百度网讯科技有限公司 | 目标数据的获取方法和装置 |
US20220156163A1 (en) * | 2020-11-13 | 2022-05-19 | Oracle International Corporation | Fault tolerance in scale-out distributed query processing appliance |
CN112507199B (zh) * | 2020-12-22 | 2022-02-25 | 北京百度网讯科技有限公司 | 用于对搜索系统进行优化的方法和装置 |
US11573960B2 (en) * | 2021-03-18 | 2023-02-07 | International Business Machines Corporation | Application-based query transformations |
US11604789B1 (en) | 2021-04-30 | 2023-03-14 | Splunk Inc. | Bi-directional query updates in a user interface |
US11301473B1 (en) * | 2021-06-18 | 2022-04-12 | Sas Institute Inc. | Dataset overlap query system |
US12067008B1 (en) | 2022-01-06 | 2024-08-20 | Splunk Inc. | Display of log data and metric data from disparate data sources |
US11914655B2 (en) * | 2022-01-31 | 2024-02-27 | Crowdstrike, Inc. | Mutation-responsive documentation generation based on knowledge base |
US11762855B1 (en) * | 2022-06-10 | 2023-09-19 | Snowflake Inc. | Incremental maintenance of query results |
WO2024183900A1 (en) * | 2023-03-08 | 2024-09-12 | Huawei Technologies Co., Ltd. | Method and system of processing plurality of database queries at database query engine |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1786950A (zh) * | 2004-12-06 | 2006-06-14 | 国际商业机器公司 | 处理抽象查询的方法和系统 |
CN101479697A (zh) * | 2006-05-15 | 2009-07-08 | 克斯普拉达公司 | 用于数据存储和检索的系统和方法 |
CN104285222A (zh) * | 2012-05-07 | 2015-01-14 | 国际商业机器公司 | 使用谓词映射器优化查询 |
Family Cites Families (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5873075A (en) * | 1997-06-30 | 1999-02-16 | International Business Machines Corporation | Synchronization of SQL actions in a relational database system |
JP2001222452A (ja) * | 2000-02-10 | 2001-08-17 | Ricoh Co Ltd | リレーショナルデータベースシステムにおける問い合わせ処理最適化装置 |
WO2002071260A1 (en) * | 2001-03-01 | 2002-09-12 | Aalborg Universitet | Adaptable query optimization and evaluation in temporal middleware |
US7523462B1 (en) * | 2003-05-27 | 2009-04-21 | International Business Machines Corporation | Method for providing a real time view of heterogeneous enterprise data |
US11392588B2 (en) * | 2003-09-04 | 2022-07-19 | Oracle International Corporation | Active queries filter extraction |
US8191052B2 (en) | 2006-12-01 | 2012-05-29 | Murex S.A.S. | Producer graph oriented programming and execution |
US8880542B2 (en) * | 2008-03-28 | 2014-11-04 | Oracle International Corporation | Simply querying across time |
US8478743B2 (en) * | 2010-12-23 | 2013-07-02 | Microsoft Corporation | Asynchronous transfer of state information between continuous query plans |
US9563663B2 (en) * | 2012-09-28 | 2017-02-07 | Oracle International Corporation | Fast path evaluation of Boolean predicates |
US9507755B1 (en) * | 2012-11-20 | 2016-11-29 | Micro Strategy Incorporated | Selecting content for presentation |
US9697262B2 (en) | 2013-12-17 | 2017-07-04 | Microsoft Technology Licensing, Llc | Analytical data processing engine |
US10078556B2 (en) * | 2015-08-31 | 2018-09-18 | Paypal, Inc. | Data replication between databases with heterogenious data platforms |
US10565201B2 (en) * | 2016-11-04 | 2020-02-18 | International Business Machines Corporation | Query processing management in a database management system |
-
2018
- 2018-03-06 EP EP18711857.5A patent/EP3446242B1/en active Active
- 2018-03-06 WO PCT/EP2018/055503 patent/WO2018197084A1/en unknown
- 2018-03-06 CN CN201880027557.0A patent/CN110651264B/zh active Active
- 2018-03-06 JP JP2019558379A patent/JP6850907B2/ja active Active
- 2018-12-21 US US16/231,380 patent/US10496644B2/en active Active
-
2019
- 2019-10-08 US US16/596,520 patent/US10831753B2/en active Active
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1786950A (zh) * | 2004-12-06 | 2006-06-14 | 国际商业机器公司 | 处理抽象查询的方法和系统 |
CN101479697A (zh) * | 2006-05-15 | 2009-07-08 | 克斯普拉达公司 | 用于数据存储和检索的系统和方法 |
CN104285222A (zh) * | 2012-05-07 | 2015-01-14 | 国际商业机器公司 | 使用谓词映射器优化查询 |
Non-Patent Citations (1)
Title |
---|
Thomas Neumann.Efficient_Generation_and_Execution_of_DAG-Structur.《Efficient_Generation_and_Execution_of_DAG-Structure》.2005, * |
Also Published As
Publication number | Publication date |
---|---|
WO2018197084A1 (en) | 2018-11-01 |
US10831753B2 (en) | 2020-11-10 |
CN110651264A (zh) | 2020-01-03 |
EP3446242A1 (en) | 2019-02-27 |
EP3446242C0 (en) | 2024-04-17 |
JP2020518069A (ja) | 2020-06-18 |
EP3446242B1 (en) | 2024-04-17 |
US10496644B2 (en) | 2019-12-03 |
US20190146970A1 (en) | 2019-05-16 |
US20200034364A1 (en) | 2020-01-30 |
JP6850907B2 (ja) | 2021-03-31 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN110651264B (zh) | 具有时态关系数据库的关系数据库管理系统中的查询计划生成和执行 | |
US11157489B2 (en) | Data querying | |
US10983660B2 (en) | Software robots for programmatically controlling computer programs to perform tasks | |
US10108668B2 (en) | Column smart mechanism for column based database | |
US7792817B2 (en) | System and method for managing complex relationships over distributed heterogeneous data sources | |
US8650150B2 (en) | System and method of relating data and generating reports | |
US10467250B2 (en) | Data model design collaboration using semantically correct collaborative objects | |
US10552423B2 (en) | Semantic tagging of nodes | |
US10353879B2 (en) | Database catalog with metadata extensions | |
US8671121B2 (en) | Model augmentation in a model-driven application development environment | |
US11940951B2 (en) | Identification and import of metadata for extensions to database artefacts | |
US12093289B2 (en) | Relationship-based display of computer-implemented documents |
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 | ||
GR01 | Patent grant | ||
GR01 | Patent grant |