CN113228001B - 消除复杂数据库查询中的查询片段重复 - Google Patents
消除复杂数据库查询中的查询片段重复 Download PDFInfo
- Publication number
- CN113228001B CN113228001B CN201980085284.XA CN201980085284A CN113228001B CN 113228001 B CN113228001 B CN 113228001B CN 201980085284 A CN201980085284 A CN 201980085284A CN 113228001 B CN113228001 B CN 113228001B
- Authority
- CN
- China
- Prior art keywords
- query
- operator
- query operator
- tree
- operators
- 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
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/24—Querying
- G06F16/245—Query processing
- G06F16/2453—Query optimisation
- G06F16/24534—Query rewriting; Transformation
- G06F16/24539—Query rewriting; Transformation using cached or materialised query results
-
- 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/2453—Query optimisation
- G06F16/24534—Query rewriting; Transformation
- G06F16/24537—Query rewriting; Transformation of operators
-
- 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/2454—Optimisation of common expressions
Abstract
数据库引擎从客户端接收数据库查询。数据库引擎解析数据库查询以构建包括多个查询运算符的查询运算符树。数据库引擎对查询运算符树执行包括重复数据删除优化进程的一个或更多个优化进程,以形成优化的执行计划。重复数据删除优化进程包括:经由查询运算符树的第一遍历创建查询运算符列表,经由查询运算符树的第二遍历基于散列图确定等价于第二查询运算符的第一查询运算符,以及经由查询运算符树的第三遍历用链接到第一查询运算符的树节点替换第二查询运算符。数据库引擎执行优化的执行计划以从数据库中检索结果集,并返回该结果集。
Description
技术领域
所公开的实施方式总体上涉及关系数据库系统,并且更具体地涉及提高查询执行性能的系统特征。
背景
数据库引擎接收查询,并从一个或更多个数据库表中检索数据以提供查询所请求的数据。数据库查询是用特定的查询语言(例如SQL)来表达的。通常,数据库查询指定所需的数据,而不指定关于如何检索数据的详细执行计划。例如,在SQL中,查询包括SELECT子句(clause)、FROM子句和WHERE子句,它们指定所需的数据列、包含所需列的表以及关于如何选择数据的条件。SQL查询还可以包含GROUP By子句、HAVING子句和/或ORDER BY子句。由数据库引擎决定来解析每个查询、构建执行计划并执行该计划以检索请求的结果。这给了数据库引擎很大的灵活性。然而,针对同一查询的不同执行计划可以具有截然不同的执行时间来检索结果。例如,一个执行计划可能在不到一秒钟的时间内检索结果,而第二计划可能需要几分钟来检索完全相同的结果。为了解决这个问题,数据库引擎通常包括一个或更多个优化层来提高执行性能。不幸的是,现有的数据库引擎很难优化某些类型的复杂查询。
概述
当数据库引擎接收到SQL查询时,该查询被解析并转换为抽象语法树。语义分析把语法树转变为运算符树(operator tree)。构建运算符树将语法树与模式信息(schemainformation)相结合,解析表名和列名,并解析查询内的内部引用。在逻辑优化期间,数据库引擎应用常量折叠(constant folding)、谓词下推(predicate pushdown)和连接再排序(join reordering)以及其他优化技术。本文描述的数据库引擎能够移除重复的子查询,从而避免执行冗余查询操作。
提供了一种通过消除复杂数据库查询中的重复查询片段(fragment)来增强实时数据探索的方法。根据一些实施方式,该方法在具有一个或更多个计算设备的数据库引擎处执行,每个计算设备具有一个或更多个处理器和存储器。存储器存储被配置用于由一个或更多个处理器执行的一个或更多个程序。一个或更多个程序执行以从数据库(例如,SQL数据库)中检索数据。数据库引擎从客户端接收数据库查询。数据库引擎解析数据库查询以构建包括多个查询运算符的查询运算符树。数据库引擎对查询运算符树执行包括重复数据删除优化进程(deduplication optimization pass)的一个或更多个优化进程,以形成优化的执行计划。重复数据删除优化进程包括(i)经由查询运算符树的第一遍历创建查询运算符列表,(ii)经由查询运算符树的第二遍历、基于散列图(hash map)确定第一查询运算符等价于第二查询运算符,以及(iii)经由查询运算符树的第三遍历,用链接到第一查询运算符的树节点来替换第二查询运算符。数据库引擎执行优化的执行计划以从数据库中检索结果集,并将结果集返回给客户端。
在一些实施方式中,数据库引擎计算查询运算符列表中的查询运算符之间的依赖关系列表。第二遍历是基于依赖关系列表的查询运算符树的广度优先后序遍历,使得在具有依赖关系的查询运算符之前访问不具有依赖关系的查询运算符。在一些实施方式中,当第三查询运算符没有等价的查询运算符时,依赖关系列表被更新以指定第三查询运算符具有依赖关系,使得第三查询运算符的父查询运算符(parent)在广度优先后序遍历期间不被选择。
在一些实施方式中,只有当第一查询运算符可以被物化(materialized)时,数据库引擎才用树节点来替换第二查询运算符。例如,数据库引擎采用启发式方法,即重新计算(或重新物化(re-materialization))可能比存储和检索先前计算的结果更好,因为相关的查询运算符(例如,连接运算符(join operator))产生大的结果,并且存储和检索大的结果将导致存储器和/或带宽相关的性能问题。在一些实施方式中,当第一查询运算符是GROUPBy运算符、GROUPJOIN运算符、SORT运算符、WINDOW运算符或TEMP运算符时,数据库引擎替换第二查询运算符。
在一些实施方式中,数据库引擎用来链接到第一查询运算符的树节点减少了对应于第二查询运算符的优化的执行计划的一部分的执行实例的数量。
在一些实施方式中,查询运算符的第一遍历和第三遍历是查询运算符树的深度优先前序遍历。
在一些实施方式中,数据库引擎在重复数据删除优化进程之前执行树重构优化进程以重构查询运算符树。这增加了查询运算符树中重复查询运算符的数量。换句话说,重构增加了重复数据删除优化进程移除重复或冗余查询运算符的机会。在一些实施方式中,数据库引擎关闭、抑制或不运行在重复数据删除优化进程之前的、将禁止重复数据删除优化进程的一个或更多个优化进程(例如,将减少查询运算符树中重复查询运算符的数量、减少机会或使查找重复变得困难的进程)。
在一些实施方式中,数据库引擎基于确定第一查询运算符的输入运算符和第二查询运算符的输入运算符是否等价,和/或确定第一查询运算符和第二查询运算符是否具有等价性质(例如,运算符是选择谓词、连接条件或扫描表),来确定第一查询运算符是否等价于第二查询运算符。在一些实施方式中,数据库引擎基于第一查询运算符的输入运算符和第二查询运算符的输入运算符的信息单元映射(有时称为IUMapping)来确定第一查询运算符和第二查询运算符具有等价性质。在一些实施方式中,数据库引擎在确定第一查询运算符是否等价于第二查询运算符时,考虑查询运算符的交换性(commutativity)、关联性和类似的代数性质。这样做时,数据库引擎忽略第一查询运算符的代数表示和第二查询运算符的代数表示之间的微小差异。在一些实施方式中,当确定第一查询运算符是否等价于第二查询运算符时,数据库引擎忽略对应于第一查询运算符和第二查询运算符的子树中的一个或更多个不匹配的查询运算符(有时称为“透明(transparent)”运算符)。
在一些实施方式中,通过查询运算符签名来对散列图进行索引。在一些实施方式中,当在查询运算符树的第二遍历期间访问查询运算符时,散列图被更新。
在一些实施方式中,数据库引擎通过构造包含第一查询运算符和第二查询运算符的第四查询运算符、和/或经由查询运算符树的第三遍历用第四查询运算符替换第一查询运算符和第二查询运算符,来合并查询片段。
在一些实施方式中,数据库引擎通过构造包含第一查询运算符和第二查询运算符的第五查询运算符、构造使用第五查询运算符的结果作为输入的第六查询运算符、和/或经由查询运算符树的第三遍历用第五查询运算符替换第一查询运算符、以及用第六查询运算符替换第二查询运算符,来优化查询运算符树中的聚合层次结构。
在一些实施方式中,数据库引擎移除冗余连接。例如,根据确定第一查询运算符和第二查询运算符是父连接查询运算符的输入运算符,数据库引擎移除查询运算符树中的父连接查询运算符,并用第一查询运算符替换它,并且从查询运算符树中删除第二查询运算符。
在一些实施方式中,数据库引擎通过使用缓存机制来缓存执行第一查询运算符的第一结果来回收(recycle)和/或缓存执行的中间结果。例如,数据库引擎使用将缓存命中率(cache hit rate)最大化的LRU或类似方案。在一些实施方式中,数据库引擎使用持久缓存(persistent cache)(例如,用于打包的工作簿(packed workbooks)),使得将来的加载或第一印象(first impression)是快速的。
在一些实施方式中,数据库引擎在批量查询(batch queries)中移除重复的查询操作。第一查询运算符和第二查询运算符属于查询批量(query batch)内的不同查询,并且查询运算符树包括一个或更多个查询运算符(例如,UNIONALL运算符),其组合查询批量内的不同查询。
根据一些实施方式,数据库引擎包括一个或更多个处理器、存储器以及存储在该存储器中的一个或更多个程序。程序被配置为由一个或更多个处理器执行。程序包括用于执行本文所述的任何方法的指令。
根据一些实施方式,非暂时性计算机可读存储介质存储被配置用于由具有一个或更多个处理器和存储器的计算机系统执行的一个或更多个程序。一个或更多个程序包括用于执行本文所述的任何方法的指令。
因此,公开了通过移除或消除复杂数据库查询中的查询片段重复来提供更有效处理的方法、系统和计算机可读介质。
前面的一般描述和下面的详细描述都是示例性和解释性的,并且旨在提供对所要求保护的本发明的进一步解释。
附图简述
为了更好地理解提供有效的数据库查询处理的上述系统和方法,应结合以下附图参考以下的实施方式的描述,其中,在整个附图中,相同的附图标记指代相应的部分。
图1示出了根据一些实施方式的数据库系统的环境(context)。
图2是根据一些实施方式的计算设备的框图。
图3A和图3B是根据一些实施方式的由计算机系统实现的查询执行系统的框图。图3C示出了根据一些实施方式的示例查询树,该示例查询树结合了在查询重复数据删除优化进程中使用的IUMapping的概念。
图4A-图4L示出了根据一些实施方式的查询运算符树以及如何通过消除重复片段来优化它们。
图5A-图5I提供了根据一些实施方式的用于构建、优化和执行查询运算符树的过程的流程图。
图6提供了根据一些实施方式的基于散列的重复数据删除过程的伪代码。
现在将参考其示例在附图中被示出的实施方式。在下面的描述中,阐述了许多具体细节以便提供对本发明的透彻理解。然而,对于本领域中的普通技术人员将明显的是本发明可被实践而不需要这些特定细节。
实施方式的描述
图1示出了一些实施方式在其中操作的环境。用户100与诸如台式计算机、膝上型计算机、平板计算机或移动计算设备的个人设备102交互。个人设备102是计算设备200的示例。术语“计算设备”还包括服务器计算机,服务器计算机可以比由单个用户使用的个人设备强大得多,并且通常用户仅间接访问。下面参考图2描述示例计算设备200,包括在设备200上执行的各种软件程序或模块。在一些实施方式中,个人设备102包括一个或更多个桌面数据源224(例如,CSV文件或电子表格(spreadsheet)文件)。在一些实施方式中,个人设备102包括数据库引擎120,该数据库引擎120提供对一个或更多个关系数据库122(例如,SQL数据库)的访问。在一些实施方式中,个人设备包括数据可视化应用222,用户100使用该数据可视化应用222以从桌面数据源224和/或关系数据库122创建数据可视化。以此方式,一些实施方式使用户能够可视化本地存储在个人设备102上的数据。
在一些情况下,个人设备102通过一个或更多个通信网络108连接到一个或更多个外部数据库服务器106和/或数据可视化服务器104。通信网络108可以包括局域网和/或广域网(例如互联网)。在一些实施方式中,数据可视化服务器104提供在个人设备102上的网络浏览器(web browser)220内运行的数据可视化网络应用(web application)。在一些实施方式中,数据可视化功能由本地应用222和数据可视化服务器104提供的某些功能提供。例如,数据可视化服务器104可以用于资源密集型操作。在一些实施方式中,一个或更多个数据库服务器106包括数据库引擎120,该数据库引擎120提供对存储在数据库服务器106处的一个或更多个数据库122的访问。如图1所示,数据库引擎120和相应的数据库122可以驻留在本地个人设备102上或数据库服务器106上。在一些实施方式中(这里未示出),数据可视化服务器104包括数据库引擎120和一个或更多个数据库122。
图2是根据一些实施方式的示出计算设备200的框图。如本文所使用的,术语“计算设备”包括个人设备102和服务器(例如数据库服务器106或数据可视化服务器104)。计算设备200通常包括用于执行被存储在存储器214中的模块、程序和/或指令并从而执行处理操作的一个或更多个处理单元/核(CPU)202;一个或更多个网络或其它通信接口204;存储器214;以及用于将这些部件互连的一个或更多个通信总线212。通信总线212可以包括在系统部件之间进行互连和控制在系统部件之间的通信的电路系统。计算设备200可以包括用户接口206,该用户接口206包括显示设备208和一个或更多个输入设备或机构210。在一些实施方式中,输入设备/机构210包括键盘。在一些实现方式中,输入设备/机构包括“软”键盘,其根据需要显示在显示设备208上,使用户能够“按下”出现在显示器208上的“键”。在一些实施方式中,显示器208和输入设备/机构210包括触摸屏显示器(也被称为触敏显示器)。在一些实施方式中,存储器214包括高速随机存取存储器,例如DRAM、SRAM、DDR RAM或其他随机存取固态存储器设备。在一些实施方式中,存储器214包括非易失性存储器,例如一个或更多个磁盘存储设备、光盘存储设备、闪存设备或其他非易失性固态存储设备。在一些实现方式中,存储器214包括远离CPU 202定位的一个或更多个存储设备。存储器214或可替代地在存储器214内的非易失性存储器设备包括非暂时性计算机可读存储介质。在一些实施方式中,存储器214或存储器214的计算机可读存储介质存储下面的程序、模块和数据结构或其子集:
·操作系统216,其包括用于处理各种基本系统服务和用于执行硬件相关的任务的过程;
·通信模块218,其用于经由一个或更多个(有线或无线)通信网络接口204和一个或更多个通信网络108(例如互联网、其它广域网、局域网、城域网等)来将计算设备200连接到其它计算机和设备;
·网络浏览器220(或其他客户端应用),其使得用户100能够通过网络与远程计算机或设备通信。在一些实施方式中,网络浏览器220执行从数据可视化服务器104下载的数据可视化网络应用(未示出)。在一些实施方式中,数据可视化网络应用(未示出)是本地存储数据可视化应用222的替代方案;
·数据可视化应用222,其使得用户能够从各种数据源构造数据可视化。数据可视化应用222从一个或更多个数据源(例如桌面数据源224(例如,CSV文件或平面文件(flatfile))、本地存储的关系数据库122或存储在另一设备(例如,数据库服务器106)上的桌面数据源或关系数据库122)检索数据。数据可视化应用然后在一个或更多个数据可视化中生成并显示检索到的信息;
·一个或更多个桌面数据源224,其具有可以由数据可视化应用222使用和显示的数据。数据源224可以以许多不同的方式(例如电子表格、XML文件、平面文件、CSV文件、文本文件、JSON文件或桌面数据库文件)格式化。典型地,桌面数据源224也被其他应用(例如,电子表格应用)使用;
·数据库引擎120,其接收数据库查询226(例如,来自数据可视化应用的查询)并返回相应的数据。数据库引擎120通常包括多个可执行模块;
·数据库引擎120调用查询解析器240,其解析每个接收的查询226(例如,SQL数据库查询)以形成查询运算符树228。运算符树有时被称为代数树(algebra tree)。在一些实施方式中,查询解析器240包含在查询编译器242中;
·数据库引擎120包括查询编译器242,其将每个查询运算符树228转换为可执行代码230。为了简洁起见,查询编译器242还被称为编译器。在一些实施方式中,编译器242包括优化器244,其修改查询运算符树228以产生有效的执行计划。优化器通常能够基于查询运算符树的结构和请求的数据标识多种类型的优化。例如,一些实施方式标识何时将子表达式(例如条件子表达式)提升(hoist)到条件表达式外部。当执行可执行代码时,为提升的表达式计算并保存一个值,并且在随后遇到子表达式时使用保存的值。以此方式,针对每行计算一次子表达式,当再次遇到同一子表达式时重复使用该计算值。在一些情况下,计算值存储在CPU 202的寄存器中。一些实施方式中,编译器242和/或优化器242在存储器214中存储数据结构(例如散列图和查询运算符228之间的依赖关系列表)以支持或指导优化进程;
·数据库引擎120包括查询执行模块250,其执行由查询编译器242生成的代码230(本文有时称为查询执行计划);和
·数据库引擎120还包括查询存储器管理器252,其跟踪每个过程的存储器使用情况,并根据需要动态分配存储器。在一些实施方式中,存储器管理器252在执行编译的代码时检测何时没有足够的存储器。在一些实施方式中,查询存储器管理器252与查询执行模块250通信。
上面识别的可执行模块、应用或过程集中的每一者可以被存储在前面提到的存储器设备中的一个或更多个中,并且对应于用于执行上述功能的指令集。上面标识的模块或程序(即,指令集)不需要被实现为独立的软件程序、过程或模块,并且因此这些模块的各种子集可以在各种实施方式中被组合或以其他方式重新布置。在一些实施方式中,存储器214存储上面识别的模块和数据结构的子集。此外,在一些实施方式中,存储器214存储上面未描述的附加模块或数据结构。
尽管图2示出了计算设备200,但是图2更多地预期作为可能存在的各种特征的功能描述,而不是作为本文所述的实施方式的结构示意图。在实践中且如本领域中的普通技术人员所认识到的,单独示出的项目可以组合并且一些项目可以被分离。
标准关系数据库查询引擎依赖关系代数树(例如,运算符树228)来评估逻辑优化的计划。典型的代数树228具有良好性质,即其叶节点对应于基本关系,并且树228中的每个节点可以仅基于其子树的节点来被评估。为了评估树中的节点,典型的“迭代器引擎”通过从与节点的子节点(children of node)对应的子树中提取(pull)中间结果来工作。
一些数据库引擎选择访问路径作为逻辑优化的一部分。连接列(joined column)上索引的存在可以使得能够使用索引嵌套循环连接(index-nested loop joins),从而影响不同连接顺序的最优性。因此,通常选择访问路径作为连接重新排序的一部分。接下来,数据库引擎为运算符树中的每个代数运算符选择物理实施方式。在一些实施方式中,在这个阶段期间,数据库引擎还选择适当的访问路径和索引来尽可能快地检索所请求的数据。根据一些实施方式,优化的运算符树被编译成本地(native)机器代码。这个编译的代码然后在运行时加载并与数据库引擎链接并被执行。因此,在一些实施方式中,数据库引擎本质上充当数据库查询的优化JIT编译器。
在一些实施方式中,为了实现高效的代码生成,实施方式使用生产-消费执行模型。在这个执行模型中,所有运算符的代码融合在一起,使系统能够一次将一个元组(tuple)推送通过整个运算符树直到下一个管道断路器(pipeline breaker)。
在一些实施方式中,数据库引擎使用“碎屑驱动型并行机制(Morsel-drivenparallelism)”。在这个并行化模型中,工作在工作线程(worker thread)之间动态平衡。元组以所谓的碎屑(morsel)形式分发给工作线程,碎屑是几千个元组的分块(chunk)。工作线程在拾取碎屑进行处理时会考虑线程局部性。
在一些实施方式中,数据库引擎的优化器和查询引擎与数据库储存层是分离的。这使得数据库引擎能够处理大量不同的储存格式。
图3A和图3B是根据一些实施方式的由计算机系统200实现的查询执行系统的框图。执行系统300包括查询解析器240,其接收数据库查询226(例如,SQL查询)。查询解析器240解析每个数据库查询226以形成查询运算符树228。根据一些实施方式,优化器244执行一个或更多个优化进程308(例如,进程308-1、308-D和308-N),以优化查询运算符树228,从而产生优化的查询运算符树。根据一些实施方式,重复数据删除优化进程308-D将由一个或更多个初始优化进程308-1输出的优化的查询运算符树作为输入,并移除一个或更多个重复的查询运算符。在一些实施方式中,重复数据删除优化进程308-D之后的一个或更多个最终优化进程308-N进一步优化查询运算符树输出,以产生优化的执行计划230。尽管在图3A中,包含优化进程308的块被示为产生优化的执行计划230,但是在一些实施方式中,编译器(例如,上面参考图2描述的查询编译器242)包括作为优化器(例如优化器244)的一部分的优化进程308,并且编译器产生优化的执行计划(本文有时称为查询执行计划或代码)。如上文参考图2所述,根据一些实施方式,执行模块(例如,模块250)执行代码或优化的执行计划230来产生查询结果314。
在一些实施方式中,中间编译器编译由优化进程308输出的查询运算符树以形成中间表示,该中间表示随后被编译成优化的执行计划230。该步骤通常还包括某个逻辑优化。在一些实施方式中,执行选择器耦合到中间编译器。执行选择器标识一个或更多个查询特征和一个或更多个数据库特征,以确定如何执行查询。在一些实施方式中,执行选择器选择多个执行选项之一来处理中间表示。在一些实施方式中,多个执行选项包括没有编译的直接解释、没有或很少有代码优化的编译(例如,“便宜的(cheap)”优化)以及具有更显著代码优化水平的编译。多个执行选项在查询编译时间和查询执行时间之间进行权衡。
在一些实施方式中,执行选择器实施启发式过程以从多个执行选项中选择执行计划。在一些实施方式中,启发式过程最小化查询编译时间和查询执行时间的总和。在一些实施方式中,查询编译时间是基于中间表示的大小来被估计的。在一些实施方式中,查询执行时间是基于将被访问或接触以检索对应于数据库查询226的结果集的元组(例如,数据库122中的行)的数量来被估计的。
在一些实施方式中,数据库查询226被分段为多个子查询,每个子查询被转换为执行块。在一些实施方式中,分段基于执行管道(execution pipeline)。在一些实施方式中,上述执行选择器单独处理对应于多个子查询之一的每个执行块。也就是说,执行选择器从中间编译器接收每个执行块,并标识对于相应执行块的一个或更多个查询特征。执行选择器估计对于相应执行块的查询执行时间和查询编译时间。然后,分析估计的查询执行时间和估计的查询编译时间,以确定它们是否满足解释标准、编译标准和优化的编译标准中的一个或更多个。执行选择器然后选择多个执行选项之一来处理对应于多个子查询之一的相应执行块。在一些实施方式中,即使当数据库查询226没有被分段时,中间表示也被分成多个执行块。执行选择器然后如上所述单独处理每个执行块。
在一些实施方式中,执行选择器当确定执行选项时使用相似性度量将新查询与先前执行的查询进行比较。在一些实施方式中,相似性度量使用时间估计数据。在一些实施方式中,相似性度量比较所访问的表的特征(例如表的同一性(identicality)、表的大小或索引的存在)。在一些实施方式中,相似性度量比较查询结构和/或复杂性。
图3B是示出根据一些实施方式的查询重复数据删除优化进程308-D的框图。查询重复数据删除优化进程308-D包括输入查询运算符树228的深度优先前序树遍历316,以产生查询运算符列表318(例如,输入查询运算符树228中所有查询运算符的列表)。随后,优化进程308-D在(例如,由查询运算符签名索引的)散列图324和/或依赖关系列表320的指导下,以广度优先后序322遍历查询运算符树228。在一些实施方式中,依赖关系列表320和/或散列图324在树遍历322的过程期间被更新。树遍历322产生等价查询运算符326的列表。根据一些实施方式,重复数据删除优化进程308-D随后以深度优先前序328遍历查询运算符树228,从查询运算符树228移除一个或更多个树等价或重复的查询运算符,以产生优化的查询运算符树330。
示例术语,表达式优化
作为以下讨论的背景信息,提供了示例术语的简短描述。术语“运算符”是指所有查询运算符(例如,SQL代数运算符),例如JOIN、SORT、SELECT、MAP和KMEANS。运算符对输入集进行操作,并产生输出集。相反,术语“表达式”是指标量表达式。表达式采用多个标量参数(argument)并返回另一个标量值,并包括常规表达式(例如“+”和“-”)。表达式还包括特殊SQL表达式(例如CaseExpressions)和实现特定的表达式(例如CachingExpressions)。此外,表达式还包括采用零参数的表达式,例如Constants和特殊函数(例如CURRENT_USER)。
以下描述中使用的其他术语包括“聚合(aggregates)”和“信息单元(IU)”。聚合用于(例如,在GROUPBy查询和Window查询中)将一组元组聚合成单个值。示例聚合包括SUM、MIN、MAX和AVG。描述中使用的另一个概念是IU的概念。在查询优化或代码生成时间期间,IU标识元组中的特定标量值。通过其身份(例如,通过其存储器地址)来标识IU。IU在其成员变量中存储类型信息。根据一些实施方式,IU只存在于优化或代码生成时间期间。在一些实施方式中,当将代数树转换为虚拟机或汇编代码时,IU抽象被移除,并且各个标量值由它们在查询执行的不同点所处的寄存器来标识。
一些实施方式应用公共子表达式消除(CSE)来优化表达式。在一些实施方式中,CSE使用getSignature函数,该函数返回表达式树的等价感知散列(equivalence-awarehash)。如果表达式树是等价的,则它们将具有相同的签名。例如,表达式树“a+b”和“b+a”返回相同的签名。在一些实施方式中,getSignature针对非等价表达式返回相同散列值的唯一情况是存在散列冲突时。CSE的一些实施方式还使用了检查两个表达式的等价的函数isEquivalent。使用此函数是因为由于散列冲突,getSignature可能针对非等价表达式返回相同的签名。
重复数据删除算法的设计
本文描述了重复数据删除算法的示例实施方式或设计选择。一些实施方式仅对无论如何都在物化的运算符进行重复数据删除,而不会引入临时运算符。一些实施方式通过多次扫描数据的物化表示(materialized representation)而不将子树的结果流式传输到多个上游消费者来重复使用查询运算符树的结果。在这样的情况下,对运算符(例如,JOIN运算符)进行重复数据删除将需要引入TEMP运算符来物化JOIN结果,使得它然后可以被多个EXPLICITSCAN运算符重复使用。引入这样的TEMP运算符虽然是可能的,但是会产生开销。例如,当JOIN产生大的结果集时,完整的结果集被物化并保存在存储器中。在一些情况下,仅仅重新计算JOIN结果比物化和读取JOIN结果要更便宜(例如,由于存储器带宽)。因此,一些实施方式不引入TEMP运算符,而只对那些无论如何都必须物化它们的完整结果的运算符(例如GROUPBy和GROUPJOIN)进行重复数据删除。在一些实施方式中,对GROUPBy运算符进行重复数据删除还会对该GROUPBy下的所有其他查询运算符(即,GROUPBy运算符的子运算符(child operator))(包括非物化运算符,例如JOIN)进行重复数据删除。如果在非物化重复运算符之上没有上游物化运算符,则一些实施方式重新执行非物化运算符(运行示例中的JOIN运算符)。在一些实施方式中,物化结果是可重复使用的,所以物化运算符的结果被直接重复使用,而不是必须将结果复制到TEMP运算符中。
考虑到各种因素(例如,查询运算符的数量),一些实施方式仅对如由预定阈值所定义的复杂查询应用重复数据删除优化进程。一些实施方式尽可能早地检测查询重复数据删除是否不适用于给定的查询,并且在这样的情况下,尽早退出(bail out)。
在一些实施方式中,重复数据删除优化是几个优化器进程之一。在一些实施方式中,重复数据删除优化进程在大多数其他优化(例如,连接重新排序进程)之后运行。
在一些实施方式中,查询片段重复数据删除(有时称为查询运算符重复数据删除或查询重复数据删除)包括检测给定两个查询片段的查询包含(query subsumption)(或等价),高效地遍历查询运算符树,以及对所有包含的查询片段进行重复数据删除。在通过用不同子树的结果替换子树来消除该子树之前,被消除的子树和替换子树被验证以产生等价结果。在一些实施方式中,建立两个运算符树的等价包括在代数级别上证明句法等价(syntactic equivalence)。一些实施方式认为两个运算符是等价的,当且仅当(i)输入运算符是等价的,并且(ii)运算符性质(例如,选择谓词、连接条件、扫描表)是等价的。
对于叶运算符(leaf operator),由于没有输入运算符,上面的条件(i)简单为真。条件(ii)不应仅仅因为在任何表达式中包含非常数值(non-constant value)而评估为假。一些实施方式通过IU引用所有非常数值,并且每个运算符在唯一的IU下产生其输出。这是为了例如针对同一表连接结果表扫描后,可以将来自不同连接端的列进行歧义消除。因为IU是唯一的,所以一些实施方式跟踪等价的IU,以便确定查询片段之间的等价。一些实施方式使用IUMapping,并使用上面指定的双重条件的修改形式,当且仅当(i)输入运算符是等价的,并且(ii)给定相关输入运算符的IUMapping的情况下,运算符性质(例如,选择谓词、连接条件、扫描表)是等价时,找到两个运算符是等价的。由于这个等价定义是递归的,所以每个运算符都提供了输出IUMapping,该输出IUMapping将其自己的输出IU映射到另一个等价运算符的输出IU。在一些实施方式中,每个运算符以某种依赖于运算符的方式组合其输入运算符的IUMapping,以提供输出IUMapping。
图3C示出了根据一些实施方式的示例查询树,该示例查询树结合了在查询重复数据删除优化进程中使用的IUMapping的概念。箭头332、334、336、338和340指示各种运算符的输出之间的IUMapping。在本示例中,关于T2的三个表扫描(运算符342、344和346)是等价的。一些实施方式只显式存储三个IUMapping中的两个,并通过传递性推断第三个映射。在图3C中,为了简洁起见,关于T1的扫描的映射(运算符350、354和358)和各自的父SELECT运算符(运算符352、356和360)被隐藏。另外,三个JOIN输出350、352和354是等价的。然而,第二GROUPBy运算符352计算相比于其他两个GROUPBy运算符350和354的不同聚合。因此,在顶层处,在第一GROUPBy运算符360和第三GROUPBy运算符362之间只存在IUMapping 332。一些实施方式将三个GROUPBy运算符360、362和364组合成公共GROUPBy运算符(使用查询片段合并来同时计算MIN和MAX)。
在一些实施方式中,IUMapping将IU从一个树片段映射到另一个树片段。从概念上来说,它们是无序映射,以IU(或指向IU的指针)为参数,并具有一些实用功能(utilityfunction)。
在一些实施方式中,函数(例如,getSignature C++函数)提供运算符子树的语义感知散列(semantic-aware hash),并使用基于散列的结构(无序图(unordered map))来索引运算符树。一些实施方式使用函数(例如,C++函数,其带有签名establishEquivalenceMapping(运算符和其他)),它在两个运算符(例如,C++示例中的“this”运算符和“other”运算符)的输出IU之间建立等价映射。一些实施方式基于运算符的特定语义和其输入运算符的IUMapping来建立等价。一些实施方式将空IUMapping与不存在的IUMapping区分开来。不存在的IUMapping意味着无法证明运算符树的等价。另一方面,空IUMapping意味着两个运算符树产生相同数量的元组,但是它们的IU都没有相互映射。一些实施方式还处理等价映射的传递性。
在一些实施方式中,用于获取签名和/或建立等价的函数(例如,上述的getSignature函数和establishEquivalenceMapping函数)忽略代数表示之间的微小差异。例如,在一些实施方式中,以下查询片段:
..(SELECT SUM(a)AS s1,MIN(b)AS m1 FROM t1)..
和
..(SELECT MIN(b)AS m2,SUM(a)AS s2 FROM t1)..
被检测为与映射s1->s2和m1->m2等价,即使产生的列名不同,并且聚合的顺序也不同。当在代数级别上GROUPBy运算符内的聚合的原始顺序未被保留时,一些实施方式使用这种等价。相反,在这样的情况下,代数树上聚合的顺序取决于内部不稳定的指针,并且即使原始查询以相同的顺序列出聚合,该聚合的顺序也可能不同。一些实施方式对其他运算符使用类似的等价概念。即使输入运算符被翻转(flip),一些实施方式也检测连接运算符的等价。一些实施方式检测集合操作UNION[ALL]、INTERSECT[ALL]和/或EXCEPT[ALL]的等价,而不考虑产生的列的顺序。一些实施方式检测TABLESCAN操作的等价,而不考虑单独的限制(对于操作)。
一些实施方式针对速度优化了getSignature或类似函数。例如,一些实施方式不包括运算符的所有部分,这些部分可能会影响该运算符与另一个运算符的等价。例如,TableScan的签名不包括残差和限制;它只包括扫描的关系id和谓词数量。虽然在一些情况下将会有散列冲突,但是散列冲突不影响算法的正确性,因为其他函数(例如,establishEquivalenceMapping函数)会过滤掉运算符。一些实施方式折衷散列冲突以换取散列速度。在一些实施方式中,对于大多数运算符树,“便宜”散列已经足以证明没有机会进行查询重复数据删除。因此,通过保持签名计算的便宜,一些实施方式使得早期退出的过程甚至比没有便宜散列的情况下更快。
在一些实施方式中,在getSignature函数或establishEquivalenceMapping函数中,诸如Map和Select的运算符检查包含的表达式是否等价。一些实施方式使用CSE算法使用的函数(例如,上面参考CSE描述的getSignature函数和isEquivalent函数)来检查等价。一些实施方式在重复使用扩展来检查等价之前,扩展了CSE中使用的功能以支持IUMapping。一些实施方式在检查等价时考虑运算符的交换性。例如,在给定映射{IU1->IU4,IU2->IU5,IU3->IU6},或者映射{IU1->IU5,IU2->IU4,IU3->IU6}的情况下,操作(IU1+IU2)-IU3等价于(IU4+IU5)-IU6,但两者在映射{IU1->IU6,IU2->IU5,IU3->IU4}或者{IU1->IU5,IU2->IU6,IU3->IU4}的情况下并不等价。由于“+”运算符的交换性,第二组映射导致等价。
示例重复数据删除算法
根据一些实施方式,在高级别处,重复数据删除算法包括三次树遍历。首先,查询运算符树的深度优先前序遍历收集查询运算符树中的运算符(例如,作为列表)以及运算符之间的依赖关系(例如,作为依赖关系列表)。其次,查询运算符树的依赖关系感知广度优先后序遍历通过利用由运算符签名索引的散列图来检测等价子树。最后,查询运算符树的第三深度优先前序遍历通过在物化运算符上引入引用节点(例如,EXPLICITSCAN)来移除在前一步骤中检测到的重复的查询片段,单独留下非物化运算符。
对于第一步骤,一些实施方式列举了查询内可能重复的子树。在一些实施方式中,子树以特定的列举顺序被访问:只有在其所有输入运算符的等价被建立之后才访问运算符。根据一些实施方式,每个可能被潜在地进行重复数据删除的运算符至少被访问一次。在一些实施方式中,每个可能被潜在地进行重复数据删除的运算符最多被访问一次。一些实施方式跳过尽可能多的不合格运算符(例如,不是重复数据删除优化进程的候选者的运算符)。一些实施方式尽可能早地检测到不太可能从查询重复数据删除优化进程中获益的查询运算符树,并中止搜索和替换过程。
一些实施方式在广度优先后序遍历中列举查询运算符树。通过使用后序遍历,一些实施方式确保运算符只有在其所有输入都被访问之后才被访问。例如,运算符输入的IUMapping在访问运算符本身之前可用。广度优先搜索优于深度优先搜索,因为广度优先搜索允许实现更早地停止对整个子树的探索。如果广度优先搜索没有为运算符的所有输入找到等价映射,那么访问运算符本身就没有意义。因此,在大多数查询中,如果无法为这些叶节点找到任何等价,则该算法可以在仅访问叶节点后就已经终止。
在一些实施方式中,广度优先遍历是通过跟踪对于每个运算符的一组显著依赖关系(outstanding dependency)来实现的。该算法从没有显著依赖关系的显著运算符列表中选择运算符,并访问该运算符。如果访问成功(即,如果算法找到与给定运算符等价的另一个运算符),则该算法将依赖关系标记为被满足,从而潜在地解除对依赖于当前运算符的运算符的阻止。如果访问不成功(即,如果没有其他等价运算符),则该算法保持阻止依赖关系。因此,没有任何父运算符被访问。使用这种方法,算法将不会为父运算符找到等价运算符,因为算法没有为父运算符的输入运算符找到等价。
在一些实施方式中,树的初始遍历考虑了运算符的附加依赖关系。例如,在访问相应的JOIN节点或运算符的左侧之前,不会访问EARLYPROBE树节点。一些实施方式通过在EARLYPROBE树节点和JOIN的左侧之间添加人工依赖关系来确保该遍历顺序。
在一些实施方式中,第一树遍历的功能被折叠为第二树遍历的一部分或者作为第二树遍历的一部分来执行。类似地,一些实施方式将第二树遍历和第三树遍历组合为单个步骤。根据树结构,组合树遍历仍然可以标识和替换一些或所有冗余重复查询运算符。一些实施方式使用启发式方法来基于查询运算符树类型(例如,经由模式匹配)和/或应用类型的初始标识来决定树遍历的类型。
基于散列的重复数据删除
当使用先前引入的依赖关系感知广度优先遍历自底向上遍历树时,一些实施方式保持包含所有被访问运算符的散列图。该散列图由运算符的签名(例如,Operator::getSignature)索引。通过在该散列图中查找当前运算符,该算法可以快速获得所有潜在的等价运算符。对于这些潜在的等价运算符中的每一个,算法检查它是否能够建立等价映射。根据一些实施方式,如果存在这样的映射,则算法记住该等价映射,并将广度优先遍历中的相应依赖关系标记为被满足。图6中提供了此过程的示例伪代码。
在图6的伪代码中,运算符只有在针对其存在等价的情况下才被解除阻止。否则,运算符将保持阻止状态,并且所有依赖的运算符都不会被访问,从而有效地删减(prune)遍历并提前中止算法。
替换重复的查询片段
在前一步骤之后,算法已经收集了等价运算符的列表(例如,图6伪代码中的“等价(equivalences)”)。一些实施方式随后执行查询运算符树的深度优先前序遍历。根据一些实施方式,在该遍历期间,该算法通过引入EXPLICITSCAN运算符来对该算法遇到的所有重复的运算符进行重复数据删除。一些实施方式通过使用在前一步骤中建立的“等价”来找到与当前访问的运算符等价的其他运算符。通过自顶向下消除等价,一些实施方式确保算法不会不必要地在子树内引入ExplicitScan运算符,这些运算符将在以后被移除,因为它们可以在树的更深一层进行重复数据删除。一些实施方式消除了使它们的整个结果物化的“物化”运算符(例如,GROUPBy、SORT、WINDOW和TEMP)。这些运算符的结果可以被扫描多次,而无需附加开销。另一方面,对于非物化运算符,引入了TEMP运算符,该运算符保留临时结果以供重复使用。当这对于性能来说是次佳的时候,一些实施方式避免保留临时结果以供重复使用。
在一些实施方式中,引入EXPLICITSCAN需要对相关的IU重定父级(re-parenting)。该步骤隐含地使由建立IUMapping的较早步骤(例如,在前一阶段中,Operator::establishIUMapping)建立的IUMapping无效。这种无效是一些实施方式为什么将重复查询片段的检测和消除分成两个独立阶段的另一个原因。
一些实施方式将重复数据删除优化进程集成到连接重新排序进程内,并且当重复数据删除进程被实现为独立进程时,检测到比可能更多的共享子树实例。
在一些情况下,相同的查询树通过选择下推(selection pushdown)/引入早期探针以使它们不再等价的方式进行修改。例如,对于查询
SELECT s1.sum,s2.sum
FROM(SELECT SUM(a)AS s FROM t1 GROUP BY k)s1
JOIN(SELECT SUM(a)AS s FROM t1 GROUP BY k)s2 ON s1.k=s2.kWHERE s1.k<>‘exclude’
s1.k上的限制首先被下推到s1中,并且在下推限制的情况下,对于s1和s2的树不再等价,从而阻止了重复数据删除。同样,EARLYPROBE运算符的引入可以干扰查询重复数据删除。在一些实施方式中,根据估计引入EARLYPROBE操作,因此对估计的看似无害的改变会禁止查询重复数据删除。一些实施方式通过调整相应的上游优化或者通过考虑性能折衷而关闭那些优化,来处理前述EARLYPROBE问题和类似的禁止上游转换/优化。
此处描述的算法和实施方式支持对于各种查询运算符类型的重复数据删除,各种查询运算符类型包括ASSERTSINGLE、EARLYPROBE、EXPLICITSCAN、EXTERNALFORMATSCAN(各种格式,还包括TDE)、GROUPBy、JOIN(包括所有内部/外部/单一变量)、MAP、SELECT、所有集合操作(UNION[ALL]、INTERSECT[ALL]和EXCEPT[ALL])、SORT(还包括LIMIT但没有ORDERBY子句)、TABLECONSTRUCTION、TABLESCAN、TEMP和VIRTUALTABLE。
示例查询图
图4A-图4L示出了根据一些实施方式的由本文描述的查询重复数据删除优化进程优化的查询运算符树(有时称为查询图(query graph))的几个示例。图4B是根据一些实施方式的图4A所示的查询运算符树400的优化版本。在图4A中,可以看到查询运算符402-2(GROUPBy运算符)与子查询运算符402-4(TABLESCAN运算符)重复多次(运算符402-6与子运算符402-8、运算符402-10与子运算符402-12、运算符402-14与子运算符402-16以及运算符402-18与子运算符402-20)。在图4B中,查询运算符402-2用新查询运算符404-2(EXPLICITSCAN运算符)替换,其中查询运算符402-2作为它的子运算符。其他重复的查询运算符(运算符402-6、402-10、402-14和402-18)用新“explicitscan”查询运算符404-4、404-6、404-8和404-10替换,这些运算符(如线所指示)指回第一运算符402-2。在一些实施方式中,引用是使用具有交叉引用的扩展查询图表示来实现的。交叉引用减少了受影响查询的编译时间和执行时间。
查询运算符树(例如图4A所示的树)在数据可视化应用222中的复杂工作簿中是常见的,并且由涉及细节级别计算或前N个过滤器的查询产生。根据一些实施方式,如上所述,在高级别处,重复查询(有时称为查询片段)的标识和替换或移除包括证明两个不同关系运算符树的等价(经由查询包含实现的过程)。在一些实施方式中,查询包含与其他优化进程共享(例如多查询优化),其优化对于仪表板(dashboard)的查询批量、跨查询的查询片段的缓存、存在物化视图的情况下的查询优化以及为物化视图生成最优更新计划。
图4C示出了根据一些实施方式的具有几个重复查询操作的示例查询运算符树。从查询运算符树右手侧的EXPLICITSCAN运算符到查询运算符树左手侧的虚线406-2、406-4和406-6指示右侧子树大部分是查询运算符树左侧子树的重复。如图4C所示,移除重复的运算并且用交叉引用(例如,EXPLICITSCAN运算符)替换这些运算,大大减少了编译时间以及查询执行时间。图4D示出了另一个示例查询运算符树,其中重复的GROUPBy运算符用EXPLICITSCAN运算符节点替换。节点408-4、408-6、408-8和408-10(最初是GROUPBy运算符)是引用GROUPBy运算符408-2的结果的EXPLICITSCAN运算符节点。类似地,节点410-4、410-6、410-8、410-10、410-12、410-14、410-16和410-18(最初是GROUPBy运算符)是引用GROUPBy运算符410-2的结果的EXPLICITSCAN运算符节点。该树可以进一步优化,但是由线412-2、412-4、412-6和412-8指示的EARLYPROBE运算符禁止相应片段中的查询片段重复数据删除。
图4E-图4K根据一些实施方式提供了查询片段重复数据删除的进一步说明性示例。图4F示出了运算符树,该运算符树是图4E所示的查询运算符树的优化版本。在图4E中,看到子树412-2(GROUPBy运算符)与子查询运算符(TABLESCAN运算符)重复多次(在子树412-4、412-6、412-8和412-10中)。在图4F中,参考子树412-2,子树412-4、412-6、412-8和412-10用EXPLICITSCAN运算符节点412-12、412-14、412-16和412-18替换。类似地,根据一些实施方式,图4H示出了图4G所示的查询运算符树的优化版本,而图4J示出了图4I所示的查询运算符树的优化版本。
图4K示出了根据一些实施方式的具有冗余连接的示例优化运算符树(子树中的线示出了已进行重复数据删除的运算符)。在图4K中,一个或更多个GROUPBY运算符与其自身连接,并且连接条件将这个连接转换为Key-Key-Join。由于JOIN运算符的两侧都是相同的,所以在一些实施方式中,该连接被完全移除。
查询片段合并
一些实施方式构造包含邻近的两个子查询的子查询,并用这个组合的查询替换两个扫描,而不是只对相同的子查询进行重复数据删除。例如,在下面的查询中
SELECT a,SUM(b),COUNT(b)FROM Extract GROUP BY a UNION ALL
SELECT a,SUM(b),AVG(b)FROM Extract GROUP BY a
两个GROUPBy运算符组合成一个GROUPBy运算符,如下所示:
WITH combined AS(SELECT a,SUM(b),COUNT(b),AVG(b)FROM Extract GROUP BYa)
SELECT a,sum,count FROM combined UNION ALL
SELECT a,sum,avg FROM combined
一些实施方式认识到,用一次表扫描计算多个聚合来代替使用多次表扫描分别计算它们是更便宜的。除了能够合并GROUPBy运算符的聚合列表之外,一些实施方式使用“透明”运算符,这些运算符对于树比较的目的来说是透明的(即,这些运算符的存在将不会导致树比较失败)。例如,对于查询:
SELECT a,SUM(calc)FROM(SELECT a,b+c AS calc FROM Extract)GROUP BY aUNION ALL
SELECT a,SUM(b),AVG(b)FROM Extract GROUP BY a
根据一些实施方式,查询计划具有如图4L所示的形式。注意,UNIONALL运算符442的左子树444和右子树446如何具有不同的形状。子树444包含附加的MAP运算符。这个运算符不应该禁止两个树的合并,因为它只添加了附加列,但是继续使所有其他的列不改变。同样,以下运算符具有相同的性质:
·WINDOW运算符:根据定义,它们仅在转发所有预先存在的列时添加列;
·Key-Foreign Key-Join:KFK-Join只添加列。它不会过滤掉或重复元组。特别地,用于LOD-calc(在数据可视化应用222中常见)的所有连接都是KFK连接。一些实施方式在优化器中跟踪外键(foreign-key)并检测KFK连接。
此外,一些实施方式调整树遍历,以便为查询片段合并和/或查询片段重复数据删除发现附加的机会(例如,以处理递归操作或嵌套的GROUPBy运算符)。
聚合层次结构
一些实施方式引入了聚合层次结构。例如,一些实施方式通过使用第一GROUPBy的结果重写了查询
SELECT a,b,SUM(c)FROM Extract GROUP BY a,b UNION ALL
SELECT a,NULL,SUM(c)FROM Extract GROUP BY a
以计算第二GROUPBy,如下所示:
WITH agg1 AS(SELECT a,b,SUM(c)FROM Extract GROUP BY a,b)
SELECT a,b,sum FROM agg1 UNION ALL
SELECT a,NULL,SUM(sum)FROM agg1 GROUP BY a
一些实施方式使用散列表来索引所有GROUPBy的输入,然后合并应用于等价输入之上的GROUPBy。
在一些实施方式中,聚合函数用关于如何组成/分解它们的信息来进行注释。例如,优化器知道可以在其他SUM之上计算SUM,但首先需要将AVG分解为SUM/COUNT。
回收和中间结果缓存
一些实施方式缓存中间结果(例如GROUPBy散列表和SORT堆(heap)),并在查询之间重复使用它们。一些实施方式会保留此缓存(例如,以容纳打包的工作簿,使得将来加载和第一印象快速)。一些实施方式将如何或在何处为HashTable或SORT运算符分配存储器与查询状态分开。一些实施方式使用缓存策略(例如LRU算法)来缓存中间结果。
一些实施方式使用临时表(Temp-Table)进行结果缓存。当临时表(例如,过滤器表、组表)是查询的一部分时,一些实施方式证明跨不同会话的两个临时表是等价的。一些实施方式没有证明这种等价,而是使用其他技术来提高缓存命中率,例如crossDB临时数据库或非持久化共享表(non-persisted shared table)。
查询间(Inter-Query)优化
一些实施方式在查询批量内跨查询对子查询进行重复数据删除。通过构造,查询批量往往包含大量重复。通过跨查询边界对查询片段进行重复数据删除和/或合并,一些实施方式避免了重复计算。一些实施方式将预定义的操作(例如,ExecutionTarget)转换为代数运算符,并使用顶级运算符(例如,UNIONALL运算符)组合各个查询。一些实施方式以这样的方式管理(例如,使用或类似的协议)查询批量的发送和结果的接收,以便启用这种查询间优化。一些实施方式为所有查询都可用的仪表板场景执行查询间优化。因为所有的查询都是同时可用的,所以一些实施方式合并GROUPBy运算符(参见上面关于“查询片段合并”的章节)。
一些实施方式避免了在合并但在别的方面却不相关的查询之间传播错误。例如,如果在仅由合并查询之一使用的子树内发生异常,则一些实施方式会继续执行可能仍成功完成的其他查询。当临时表(例如,过滤器表或组表)是查询的一部分时,一些实施方式证明跨不同会话的两个临时表是等价的,而其他实施方式则避免组合涉及跨会话的临时表的查询。
物化视图更新
类似于查询间优化,一些实施方式组合查询来更新物化视图。例如,在以下场景中:
CREATE MATERIALIZED VIEW viz1 AS(<query1>)WITH NO DATA;
CREATE MATERIALIZED VIEW viz2 AS(<query2>)WITH NO DATA;
CREATE MATERIALIZED VIEW viz3 AS(<query3>)WITH NO DATA;
REFRESH MATERIALIZED VIEW viz1,viz2,viz3;
一些实施方式将所有三个底层查询一起优化。
一些实施方式(例如Tableau应用)通过为仪表板中的每个可视化(有时称为“viz”)或过滤器声明一个物化视图来使用该特征。一旦所有视图都就位,所有视图都会立即刷新。因此,数据库服务器系统可以一次优化工作簿所需的所有查询。一些实施方式依赖表示来进行与物化视图相关的优化。在一些实施方式中,代数表示中的插入、删除或类似操作用于物化视图优化。一些实施方式使用临时表(“临时表(Temp Table)”)来实现这些特征。
SQL和数据库用户定义函数中的重复数据删除
用户定义的函数允许在一个函数内指定多个语句。考虑以下示例:
CREATE FUNCTION updateMaterializedData()AS$$
TRUNCATE tab1;
TRUNCATE tab2;
INSERT INTO tab1(<query1>);
INSERT INTO tab2(<query2>);
$$language sql;
一些实施方式跨单独的语句应用查询重复数据删除,从<query1>和<query2>中提取出(factor out)公共子查询。一些实施方式确定查询是引用tab1还是tab2,以确保两个查询都能看到处于正确状态的表。
图5A-图5I提供了根据一些实施方式的用于构建、优化和执行查询运算符树以从数据库中检索数据的过程500的流程图。过程500在具有一个或更多个计算设备的数据库引擎处执行,每个计算设备具有一个或更多个处理器和存储器。存储器存储被配置用于由一个或更多个处理器执行的一个或更多个程序。一个或更多个程序执行以从数据库(例如,SQL数据库)中检索数据。
数据库引擎120从客户端接收(502)数据库查询226。数据库引擎120(或数据库引擎内的查询解析器240)解析(504)数据库查询226,以构建包括多个查询运算符的查询运算符树228。数据库引擎对查询运算符树执行(506)一个或更多个优化进程308(包括执行重复数据删除优化进程308-D)以形成优化的执行计划230。
在一些实施方式中,重复数据删除优化进程包括经由查询运算符树228的第一遍历316创建(520)查询运算符列表318,经由查询运算符树228的第二遍历(例如,遍历322)基于散列图确定(524)等价于第二查询运算符的第一查询运算符,以及经由查询运算符树228的第三遍历(例如,遍历328)用链接到第一查询运算符的树节点(例如,EXPLICITSCAN运算符)替换(532)第二查询运算符。数据库引擎执行(514)优化的执行计划以从数据库中检索结果集,并将结果集返回(518)给客户端。
参考图5C,在一些实施方式中,数据库引擎120计算(536)查询运算符列表318中的查询运算符之间的依赖关系列表320。第二遍历包括基于依赖关系列表320的查询运算符树228的广度优先后序遍历(例如,遍历322),使得不具有依赖关系的查询运算符在具有依赖关系的查询运算符之前被访问。在一些实施方式中,根据确定第三查询运算符没有等价查询运算符,数据库引擎120更新(538)依赖关系列表320以指示第三查询运算符具有依赖关系。这样,在广度优先后序遍历期间,第三查询运算符的父查询运算符不会被选择。
参考图5E,在一些实施方式中,数据库引擎120仅当第一查询运算符可以被物化时才使用树节点来替换(548)第二查询运算符。例如,数据库引擎采用重新计算(或重新物化)比存储和检索先前计算的结果更好的启发式方法,因为相关的查询运算符(例如,连接运算符)产生大的结果并存储和检索该大的结果将导致存储器和带宽相关的性能问题。在一些实施方式中,当第一查询运算符是GROUPBy运算符、GROUPJOIN运算符、SORT运算符、WINDOW运算符或TEMP运算符时,数据库引擎替换(550)第二查询运算符。
参照图5F,根据一些实施方式,数据库引擎120用来链接到第一查询运算符的树节点(例如,EXPLICITSCAN运算符)减少(552)对应于第二查询运算符的优化的执行计划的一部分的执行实例的数量。
现在返回参考图5B,在一些实施方式中,查询运算符的第一遍历和第三遍历是(522,534)查询运算符树的深度优先前序遍历。
现在返回参考图5A,在一些实施方式中,数据库引擎120在重复数据删除优化进程之前执行(508)树重构优化进程,以重构查询运算符树,以便增加查询运算符树中重复查询运算符的数量。换句话说,重构增加了重复数据删除优化进程移除重复或冗余的查询运算符的机会。在一些实施方式中,数据库引擎关闭、抑制或不运行(510)在重复数据删除优化进程之前的一个或更多个优化进程,这些优化进程将禁止重复数据删除优化进程(例如,减少查询运算符树中重复的查询运算符的数量、减少机会或使找到重复变得困难)。
现在参考图5D,在一些实施方式中,数据库引擎120基于确定(540)第一查询运算符和第二查询运算符的相应输入运算符是否等价和/或确定(544)第一查询运算符和第二查询运算符是否具有等价性质(例如,运算符是选择谓词、连接条件或扫描表),来确定(524)第一查询运算符是否等价于第二查询运算符。在一些实施方式中,数据库引擎120至少基于第一查询运算符和第二查询运算符的输入运算符的信息单元映射(有时称为IUMapping),来确定(546)第一查询运算符具有与第二查询运算符的性质等价的性质。在一些实施方式中,数据库引擎考虑(542)查询运算符的交换性、关联性和类似的代数性质,以确定第一查询运算符是否等价于第二查询运算符。这样做时,数据库引擎忽略第一查询运算符的代数表示和第二查询运算符的代数表示之间的微小差异。
现在返回参考图5B,在一些实施方式中,当确定第一查询运算符是否等价于第二查询运算符时,数据库引擎忽略(528)对应于第一查询运算符和第二查询运算符的子树中的一个或更多个不匹配的查询运算符(有时称为“透明”运算符)。
在一些实施方式中,散列图324由查询运算符签名索引(例如,使用签名计算函数之一)。在一些实施方式中,在查询运算符树的第二遍历期间,在查询运算符被访问时,散列图被更新(526)。
接下来参考图5G,在一些实施方式中,数据库引擎120通过构造(554)包含第一查询运算符和第二查询运算符的第四查询运算符、和/或经由查询运算符树的第三遍历用第四查询运算符替换(556)第一查询运算符和第二查询运算符,来合并查询片段。
如图5H所示,在一些实施方式中,数据库引擎120通过构造(558)包含第一查询运算符和第二查询运算符的第五查询运算符、构造(560)使用第五查询运算符的结果作为输入的第六查询运算符,和/或经由查询运算符树的第三遍历用第五查询运算符替换(562)第一查询运算符和用第六查询运算符替换(562)第二查询运算符,来优化查询运算符树中的聚合层次结构。
在一些实施方式中,数据库引擎120移除冗余连接,如图5I所示。例如,根据第一查询运算符和第二查询运算符是父连接查询运算符的输入运算符的确定,数据库引擎120移除(564)查询运算符树中的父连接查询运算符,并且用第一查询运算符替换它,以及从查询运算符树中删除第二查询运算符。
返回参考图5A,在一些实施方式中,数据库引擎120通过使用缓存机制缓存(516)执行第一查询运算符的第一结果来回收和/或缓存中间执行结果。例如,数据库引擎使用使缓存命中率最大化的LRU或类似方案。在一些实施方式中,数据库引擎使用持久缓存(例如,在打包的工作簿中),使得将来加载或第一印象是快速的。
参考图5B,在一些实施方式中,数据库引擎120跨批量查询移除(530)重复的查询操作。第一查询运算符和第二查询运算符属于查询批量内的不同查询,并且查询运算符树包括一个或更多个查询运算符(例如,UNIONALL运算符),其组合查询批量内的不同查询。
在本发明的描述中使用的术语仅为了描述特定实施方式的目的,且并不意欲限制本发明。如在本发明的描述和所附权利要求中所使用的,除非上下文另外清楚地指示,否则单数形式“一个(a)”、“一个(an)”、和“该(the)”意欲也包括复数形式。还要理解的是,如在本文使用的术语“和/或”指相关联的所列出的项目中的一个或更多个的任何和所有可能的组合并包括这些组合。还要理解的是,术语“包括(comprises)”和/或“包括(comprising)”当在本说明书中使用时指定所陈述的特征、步骤、操作、元件和/或部件的存在,但不排除一个或更多个其它特征、步骤、操作、元件、部件和/或它们的组合的存在或添加。
为了解释的目的,前面的描述参考了特定的实施方式进行描述。然而,上面的说明性讨论并不旨在是无遗漏的或将本发明限制到所公开的精确形式。鉴于上面的教导,许多修改和变形是可能的。实施方式被选择和描述是为了最好地解释本发明的原理及其实际应用,从而使本领域中的技术人员能够以适合于所设想的特定用途的各种修改最好地利用本发明和各种实现方式。
Claims (20)
1.一种数据库引擎,包括:
一个或更多个计算设备,每个计算设备具有一个或更多个处理器和存储器,其中,所述存储器存储被配置用于由所述一个或更多个处理器执行的一个或更多个程序,并且所述一个或更多个程序包括用于以下项的指令:
从客户端接收数据库查询;
解析所述数据库查询以构建查询运算符树,所述查询运算符树包括多个查询运算符;
对所述查询运算符树执行包括重复数据删除优化进程的一个或更多个优化进程,以形成优化的执行计划,所述重复数据删除优化进程包括:
经由所述查询运算符树的第一遍历来创建查询运算符列表;
经由所述查询运算符树的第二遍历,基于散列图,确定等价于第二查询运算符的第一查询运算符;和
经由所述查询运算符树的第三遍历,用链接到所述第一查询运算符的树节点替换所述第二查询运算符;
执行所述优化的执行计划以从数据库中检索结果集;和
将所述结果集返回给所述客户端。
2.根据权利要求1所述的数据库引擎,还包括计算所述查询运算符列表中的查询运算符之间的依赖关系列表,其中,所述第二遍历包括基于所述依赖关系列表的所述查询运算符树的广度优先后序遍历,使得不具有依赖关系的查询运算符在具有依赖关系的查询运算符之前被访问。
3.根据权利要求2所述的数据库引擎,还包括:
根据确定第三查询运算符在所述查询运算符树中没有等价的查询运算符,更新所述依赖关系列表以指定所述第三查询运算符具有依赖关系,使得所述第三查询运算符的父查询运算符在广度优先后序遍历期间不被选择。
4.根据权利要求1所述的数据库引擎,还包括:
仅当所述第一查询运算符能够被物化时,用所述树节点替换所述第二查询运算符。
5.根据权利要求4所述的数据库引擎,其中,所述第一查询运算符是以下项中的一项:GROUPBy运算符、GROUPJOIN运算符、SORT运算符、WINDOW运算符或TEMP运算符。
6.根据权利要求1所述的数据库引擎,其中,链接到所述第一查询运算符的所述树节点减少对应于所述第二查询运算符的所述优化的执行计划的一部分的执行实例的计数。
7.根据权利要求1所述的数据库引擎,其中,所述第一遍历和所述第三遍历包括所述查询运算符树的深度优先前序遍历。
8.根据权利要求1所述的数据库引擎,还包括在所述重复数据删除优化进程之前执行树重构优化进程,以重构所述查询运算符树,以便增加所述查询运算符树中的重复查询运算符。
9.根据权利要求1所述的数据库引擎,还包括关闭在所述重复数据删除优化进程之前的、禁止所述重复数据删除优化进程的一个或更多个优化进程。
10.根据权利要求1所述的数据库引擎,其中,确定所述第一查询运算符是否等价于所述第二查询运算符包括:
确定所述第一查询运算符和所述第二查询运算符的输入运算符是否等价;和
确定所述第一查询运算符和所述第二查询运算符是否具有等价性质。
11.根据权利要求10所述的数据库引擎,其中,使用所述第一查询运算符和所述第二查询运算符的所述输入运算符的信息单元映射来确定所述第一查询运算符和所述第二查询运算符是否具有等价性质。
12.根据权利要求10所述的数据库引擎,其中,使用交换性和关联性规则来确定所述第一查询运算符是否等价于所述第二查询运算符。
13.根据权利要求1所述的数据库引擎,其中,当在所述查询运算符树的所述第二遍历期间访问新的查询运算符时,所述散列图被更新。
14.根据权利要求1所述的数据库引擎,其中,确定所述第一查询运算符是否等价于所述第二查询运算符忽略对应于所述第一查询运算符和所述第二查询运算符的子树中的一个或更多个不匹配的查询运算符。
15.根据权利要求1所述的数据库引擎,还包括:
构造包含所述第一查询运算符和所述第二查询运算符的第四查询运算符;和
经由所述查询运算符树的所述第三遍历,用所述第四查询运算符替换所述第一查询运算符和所述第二查询运算符。
16.根据权利要求1所述的数据库引擎,还包括:
构造包含所述第一查询运算符和所述第二查询运算符的第五查询运算符;
构造使用所述第五查询运算符的结果作为输入的第六查询运算符;和
经由所述查询运算符树的所述第三遍历,用所述第五查询运算符替换所述第一查询运算符,以及用所述第六查询运算符替换所述第二查询运算符。
17.根据权利要求1所述的数据库引擎,还包括:
根据确定所述第一查询运算符和所述第二查询运算符是父连接查询运算符的输入运算符,移除所述查询运算符树中的所述父连接查询运算符,用所述第一查询运算符替换所述父连接查询运算符,并从所述查询运算符树中删除所述第二查询运算符。
18.根据权利要求1所述的数据库引擎,其中,所述第一查询运算符和所述第二查询运算符属于查询批量内的不同查询,并且其中,所述查询运算符树包括组合所述查询批量内的不同查询的一个或更多个查询运算符。
19.一种非暂时性计算机可读存储介质,其存储被配置用于由具有一个或更多个处理器和存储器的计算机系统执行的一个或更多个程序,所述一个或更多个程序包括用于以下项的指令:
从客户端接收数据库查询;
解析所述数据库查询以构建查询运算符树,所述查询运算符树包括多个查询运算符;
对所述查询运算符树执行包括重复数据删除优化进程的一个或更多个优化进程,以形成优化的执行计划,所述重复数据删除优化进程包括:
经由所述查询运算符树的第一遍历来创建查询运算符列表;
经由所述查询运算符树的第二遍历,基于散列图,确定等价于第二查询运算符的第一查询运算符;和
经由所述查询运算符树的第三遍历,用链接到所述第一查询运算符的树节点替换所述第二查询运算符;
执行所述优化的执行计划以从数据库中检索结果集;和
将所述结果集返回给所述客户端。
20.一种从数据库中检索数据的方法,包括:
在具有一个或更多个计算设备的计算机系统处,每个计算设备具有一个或更多个处理器和存储一个或更多个程序的存储器,所述一个或更多个程序被配置用于由所述一个或更多个处理器执行:
从客户端接收数据库查询;
解析所述数据库查询以构建查询运算符树,所述查询运算符树包括多个查询运算符;
对所述查询运算符树执行包括重复数据删除优化进程的一个或更多个优化进程,以形成优化的执行计划,所述重复数据删除优化进程包括:
经由所述查询运算符树的第一遍历来创建查询运算符列表;
经由所述查询运算符树的第二遍历,基于散列图,确定等价于第二查询运算符的第一查询运算符;和
经由所述查询运算符树的第三遍历,用链接到所述第一查询运算符的树节点替换所述第二查询运算符;
执行所述优化的执行计划以从所述数据库中检索结果集;和
将所述结果集返回给所述客户端。
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US16/231,302 | 2018-12-21 | ||
US16/231,302 US10795888B2 (en) | 2018-12-21 | 2018-12-21 | Elimination of query fragment duplication in complex database queries |
PCT/US2019/060226 WO2020131243A2 (en) | 2018-12-21 | 2019-11-07 | Elimination of query fragment duplication in complex database queries |
Publications (2)
Publication Number | Publication Date |
---|---|
CN113228001A CN113228001A (zh) | 2021-08-06 |
CN113228001B true CN113228001B (zh) | 2022-07-19 |
Family
ID=69160069
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201980085284.XA Active CN113228001B (zh) | 2018-12-21 | 2019-11-07 | 消除复杂数据库查询中的查询片段重复 |
Country Status (8)
Country | Link |
---|---|
US (2) | US10795888B2 (zh) |
EP (1) | EP3899751B1 (zh) |
JP (1) | JP7079898B2 (zh) |
CN (1) | CN113228001B (zh) |
AU (2) | AU2019405137B2 (zh) |
BR (1) | BR112021010711A2 (zh) |
CA (1) | CA3120852C (zh) |
WO (1) | WO2020131243A2 (zh) |
Families Citing this family (25)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10255336B2 (en) | 2015-05-07 | 2019-04-09 | Datometry, Inc. | Method and system for transparent interoperability between applications and data management systems |
US10594779B2 (en) | 2015-08-27 | 2020-03-17 | Datometry, Inc. | Method and system for workload management for data management systems |
US11615083B1 (en) | 2017-11-22 | 2023-03-28 | Amazon Technologies, Inc. | Storage level parallel query processing |
US11475001B1 (en) | 2018-12-19 | 2022-10-18 | Datometry, Inc. | Quantifying complexity of a database query |
US11294869B1 (en) | 2018-12-19 | 2022-04-05 | Datometry, Inc. | Expressing complexity of migration to a database candidate |
US11403291B1 (en) | 2018-12-20 | 2022-08-02 | Datometry, Inc. | Static emulation of database queries for migration to a different database |
US11068558B2 (en) * | 2018-12-21 | 2021-07-20 | Business Objects Software Ltd | Managing data for rendering visualizations |
KR20210055761A (ko) * | 2019-02-14 | 2021-05-17 | 후아웨이 테크놀러지 컴퍼니 리미티드 | 소프트웨어 기반 근거리 데이터 처리(ndp) 기술로 관계형 데이터베이스에 대한 쿼리의 처리를 향상시키기 위한 시스템 및 방법 |
US11455305B1 (en) | 2019-06-28 | 2022-09-27 | Amazon Technologies, Inc. | Selecting alternate portions of a query plan for processing partial results generated separate from a query engine |
US11860869B1 (en) | 2019-06-28 | 2024-01-02 | Amazon Technologies, Inc. | Performing queries to a consistent view of a data set across query engine types |
US11068244B2 (en) * | 2019-10-01 | 2021-07-20 | Salesforce.Com, Inc. | Optimized transpilation |
US11281721B2 (en) * | 2019-11-22 | 2022-03-22 | International Business Machines Corporation | Augmenting relational database engines with graph query capability |
US11216462B1 (en) * | 2020-08-14 | 2022-01-04 | Snowflake Inc. | Transient materialized view rewrite |
US11641665B2 (en) | 2020-09-09 | 2023-05-02 | Self Financial, Inc. | Resource utilization retrieval and modification |
US11470037B2 (en) | 2020-09-09 | 2022-10-11 | Self Financial, Inc. | Navigation pathway generation |
US11475010B2 (en) * | 2020-09-09 | 2022-10-18 | Self Financial, Inc. | Asynchronous database caching |
US20220075877A1 (en) | 2020-09-09 | 2022-03-10 | Self Financial, Inc. | Interface and system for updating isolated repositories |
US11397826B2 (en) * | 2020-10-29 | 2022-07-26 | Snowflake Inc. | Row-level security |
US11562095B2 (en) * | 2021-01-28 | 2023-01-24 | International Business Machines Corporation | Reinforcing SQL transactions dynamically to prevent injection attacks |
US20240126754A1 (en) * | 2021-06-25 | 2024-04-18 | Microsoft Technology Licensing, Llc | Click-to-script reflection |
US20230048391A1 (en) * | 2021-08-11 | 2023-02-16 | Sap Se | Operator movement optimization technique for procedures |
WO2023127047A1 (ja) * | 2021-12-27 | 2023-07-06 | 日本電気株式会社 | コード変換装置、コード変換方法、及びコンピュータ読み取り可能な記録媒体 |
US11645231B1 (en) * | 2022-04-24 | 2023-05-09 | Morgan Stanley Services Group Inc. | Data indexing for distributed query execution and aggregation |
WO2024023892A1 (ja) * | 2022-07-25 | 2024-02-01 | 日本電気株式会社 | コード変換装置、コード変換方法、及びコンピュータ読み取り可能な記録媒体 |
CN116701429B (zh) * | 2023-05-19 | 2023-12-29 | 杭州云之重器科技有限公司 | 一种基于批量历史任务模糊化的公共查询方法 |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101620606A (zh) * | 2008-06-30 | 2010-01-06 | 国际商业机器公司 | 自动生成数据库查询的方法和系统 |
CN102880500A (zh) * | 2011-07-13 | 2013-01-16 | 阿里巴巴集团控股有限公司 | 一种任务树的优化方法和装置 |
CN108027838A (zh) * | 2015-09-24 | 2018-05-11 | 华为技术有限公司 | 数据库查询系统和方法 |
Family Cites Families (25)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5379422A (en) | 1992-01-16 | 1995-01-03 | Digital Equipment Corporation | Simple random sampling on pseudo-ranked hierarchical data structures in a data processing system |
US5819255A (en) * | 1996-08-23 | 1998-10-06 | Tandem Computers, Inc. | System and method for database query optimization |
US6275818B1 (en) * | 1997-11-06 | 2001-08-14 | International Business Machines Corporation | Cost based optimization of decision support queries using transient views |
US6341281B1 (en) * | 1998-04-14 | 2002-01-22 | Sybase, Inc. | Database system with methods for optimizing performance of correlated subqueries by reusing invariant results of operator tree |
US7574424B2 (en) * | 2004-10-13 | 2009-08-11 | Sybase, Inc. | Database system with methodology for parallel schedule generation in a query optimizer |
US7882100B2 (en) * | 2005-01-24 | 2011-02-01 | Sybase, Inc. | Database system with methodology for generating bushy nested loop join trees |
US8126870B2 (en) * | 2005-03-28 | 2012-02-28 | Sybase, Inc. | System and methodology for parallel query optimization using semantic-based partitioning |
US8055600B2 (en) | 2006-11-15 | 2011-11-08 | International Business Machines Corporation | Systems and methods for applying evolutionary search to generate robust search strategies |
US20100005077A1 (en) * | 2008-07-07 | 2010-01-07 | Kickfire, Inc. | Methods and systems for generating query plans that are compatible for execution in hardware |
US8898142B2 (en) | 2009-01-29 | 2014-11-25 | Hewlett-Packard Development Company, L.P. | Risk-premium-based database-query optimization |
US8239847B2 (en) * | 2009-03-18 | 2012-08-07 | Microsoft Corporation | General distributed reduction for data parallel computing |
US8332389B2 (en) | 2009-12-04 | 2012-12-11 | International Business Machines Corporation | Join order for a database query |
US10838957B2 (en) | 2010-06-17 | 2020-11-17 | Microsoft Technology Licensing, Llc | Slicing relational queries using spool operators |
US8306959B2 (en) * | 2010-08-06 | 2012-11-06 | Ianywhere Solutions, Inc. | Incremental maintenance of immediate materialized views with outerjoins |
US8818989B2 (en) | 2010-11-30 | 2014-08-26 | International Business Machines Corporation | Memory usage query governor |
US8898145B2 (en) * | 2011-06-15 | 2014-11-25 | Microsoft Corporation | Query optimization techniques for business intelligence systems |
EP2761510A4 (en) | 2011-09-29 | 2015-08-05 | Cirro Inc | UNIFORM QUESTION ENGINE TO ASSEMBLE DATA INTERROGATION BETWEEN STRUCTURED AND UNSTRUCTURED DATA |
WO2014052977A1 (en) | 2012-09-28 | 2014-04-03 | Oracle International Corporation | Adaptive query optimization |
US9773041B2 (en) * | 2013-03-06 | 2017-09-26 | Oracle International Corporation | Methods and apparatus of shared expression evaluation across RDBMS and storage layer |
US10025823B2 (en) | 2015-05-29 | 2018-07-17 | Oracle International Corporation | Techniques for evaluating query predicates during in-memory table scans |
US10204135B2 (en) | 2015-07-29 | 2019-02-12 | Oracle International Corporation | Materializing expressions within in-memory virtual column units to accelerate analytic queries |
US10783146B2 (en) | 2016-07-19 | 2020-09-22 | Sap Se | Join operations in hybrid main memory systems |
KR20180035035A (ko) * | 2016-09-28 | 2018-04-05 | 한국전자통신연구원 | 데이터 엔진에서의 질의 최적화 방법 및 장치 |
US10049133B2 (en) | 2016-10-27 | 2018-08-14 | International Business Machines Corporation | Query governor across queries |
US10956417B2 (en) * | 2017-04-28 | 2021-03-23 | Oracle International Corporation | Dynamic operation scheduling for distributed data processing |
-
2018
- 2018-12-21 US US16/231,302 patent/US10795888B2/en active Active
-
2019
- 2019-11-07 AU AU2019405137A patent/AU2019405137B2/en active Active
- 2019-11-07 CN CN201980085284.XA patent/CN113228001B/zh active Active
- 2019-11-07 EP EP19836031.5A patent/EP3899751B1/en active Active
- 2019-11-07 BR BR112021010711-8A patent/BR112021010711A2/pt unknown
- 2019-11-07 CA CA3120852A patent/CA3120852C/en active Active
- 2019-11-07 JP JP2021529388A patent/JP7079898B2/ja active Active
- 2019-11-07 WO PCT/US2019/060226 patent/WO2020131243A2/en unknown
-
2020
- 2020-10-06 US US17/064,490 patent/US11475005B2/en active Active
-
2022
- 2022-11-30 AU AU2022279452A patent/AU2022279452A1/en active Granted
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101620606A (zh) * | 2008-06-30 | 2010-01-06 | 国际商业机器公司 | 自动生成数据库查询的方法和系统 |
CN102880500A (zh) * | 2011-07-13 | 2013-01-16 | 阿里巴巴集团控股有限公司 | 一种任务树的优化方法和装置 |
CN108027838A (zh) * | 2015-09-24 | 2018-05-11 | 华为技术有限公司 | 数据库查询系统和方法 |
Also Published As
Publication number | Publication date |
---|---|
AU2019405137A1 (en) | 2021-06-24 |
US20210019319A1 (en) | 2021-01-21 |
WO2020131243A2 (en) | 2020-06-25 |
JP7079898B2 (ja) | 2022-06-02 |
BR112021010711A2 (pt) | 2021-08-31 |
EP3899751B1 (en) | 2023-05-31 |
AU2022279452A1 (en) | 2023-02-09 |
US11475005B2 (en) | 2022-10-18 |
JP2022507977A (ja) | 2022-01-18 |
CN113228001A (zh) | 2021-08-06 |
WO2020131243A3 (en) | 2020-08-06 |
CA3120852A1 (en) | 2020-06-25 |
AU2022279452B1 (en) | 2023-02-02 |
US10795888B2 (en) | 2020-10-06 |
EP3899751A2 (en) | 2021-10-27 |
CA3120852C (en) | 2023-09-26 |
AU2019405137B2 (en) | 2022-09-08 |
US20200201860A1 (en) | 2020-06-25 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN113228001B (zh) | 消除复杂数据库查询中的查询片段重复 | |
EP3028183B1 (en) | A generic sql enhancement to query any semi-structured data and techniques to efficiently support such enhancements | |
US10901990B1 (en) | Elimination of common subexpressions in complex database queries | |
EP1577796A1 (en) | Improved Query Optimizer Using Implied Predicates | |
US11314736B2 (en) | Group-by efficiency though functional dependencies and non-blocking aggregation functions | |
US20220083552A1 (en) | Query processing in a polystore | |
US20100036805A1 (en) | System Maintainable and Reusable I/O Value Caches | |
US20100030727A1 (en) | Technique For Using Occurrence Constraints To Optimize XML Index Access | |
Idris et al. | General dynamic Yannakakis: conjunctive queries with theta joins under updates | |
Fegaras et al. | Compile-time code generation for embedded data-intensive query languages | |
CN107818125B (zh) | 通过simd处理器寄存器对数据进行迭代评估 | |
US8312030B2 (en) | Efficient evaluation of XQuery and XPath full text extension | |
US20190340177A1 (en) | Transforming a scalar subquery | |
US11640380B2 (en) | Technique of comprehensively supporting multi-value, multi-field, multilevel, multi-position functional index over stored aggregately stored data in RDBMS | |
Dong et al. | An SQL Frontend on top of OCaml for Data Analysis | |
Fent | Low Latency Query Planning and Processing in Database Systems | |
Kader et al. | Overview of query optimization in XML database systems | |
Douglas | LittleD: A Relational Database Management System for Resource Constrained Computing Devices | |
CN116266195A (zh) | 在分布式图数据库中优化sparql查询 | |
Afonso | Towards an Efficient OLAP Engine based on Linear Algebra | |
Stanchev et al. | Programming Embedded Computing Systems Using Static Embedded SQL. |
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 |