CN101908003B - 并行化查询的多核调度 - Google Patents

并行化查询的多核调度 Download PDF

Info

Publication number
CN101908003B
CN101908003B CN200910159572.3A CN200910159572A CN101908003B CN 101908003 B CN101908003 B CN 101908003B CN 200910159572 A CN200910159572 A CN 200910159572A CN 101908003 B CN101908003 B CN 101908003B
Authority
CN
China
Prior art keywords
core
operational character
inquiry
query
critical path
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
Application number
CN200910159572.3A
Other languages
English (en)
Other versions
CN101908003A (zh
Inventor
闫剑锋
许俭
黎文宪
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
SAP SE
Original Assignee
SAP SE
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by SAP SE filed Critical SAP SE
Priority to CN200910159572.3A priority Critical patent/CN101908003B/zh
Priority to US12/758,604 priority patent/US8219546B2/en
Priority to AT10005824T priority patent/ATE543137T1/de
Priority to EP10005824A priority patent/EP2259184B1/en
Publication of CN101908003A publication Critical patent/CN101908003A/zh
Application granted granted Critical
Publication of CN101908003B publication Critical patent/CN101908003B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/505—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the load
    • 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/24532—Query optimisation of parallel queries

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Computational Linguistics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Hardware Redundancy (AREA)
  • Game Rules And Presentations Of Slot Machines (AREA)
  • Devices For Executing Special Programs (AREA)

Abstract

本发明提供并行化查询的多核调度系统和方法。操作符管理器可以配置成确定可用核的数量并且在查询的多个操作符中分配核，该操作符包括操作符的运行中集合，存在通过该集合的多个查询路径。操作符管理器可以包括：状态监视器，配置成用于确定可用核的数量并且用于确定操作符的运行中集合；关键路径选择器，配置成用于从查询路径中确定查询的关键路径以及操作符的运行中集合；以及工作量管理器，配置成给运行中集合以及关键路径的运行中的操作符分配可用核的第一个核，并且此后从关键路径选择器接收新关键路径并且给新关键路径的运行中的操作符分配可用核的第二个核。

Description

并行化查询的多核调度
技术领域
本说明书涉及并行化查询执行的多核查询调度。
背景技术
大型数据库和其他软件应用的大小在该应用的使用上可能是一个限制因素，特别是当应用/数据的查询和其他操作本身很长并且很复杂时。例如，用户可能想要发布一个复杂的查询以便从具有成千上万个记录的相关数据库中获得结果，在这种情况下，提供相应查询结果的响应时间可能长得难以接受。此外，该情况可能促使可用计算资源的无效使用，例如，通过允许一个用户相对其他当前用户过度地消耗该资源。
作为减轻该问题的方法，多核(例如，多个CPU)计算系统的使用方便了并行查询执行的发展。例如，通过使用两个可用核，可以相互并行地计算多个查询(和/或它的多个部分)。从而，例如，两个等效的查询可以在小于执行其中之一应当花费的时间的双倍时间内执行。
然而，难以采用有效的或最佳的方式实现这样的并行查询的实施。例如，存在与多个核分摊/分配多个查询相关联的成本，以及与重新结合或合并查询结果相关联的成本。例如，根据讨论中的查询的性质以及并行化的程度，这些成本可能限制并且可能最终压制或掩没并行化的好处。
而且，一个或多个正在运行的查询的运行时环境的复杂性和不可预见性可能加剧多核并行查询处理的难度。例如，即使在讨论中的查询(或多个查询)的运行时之前将并列查询的可接受计划公式化，也可能发生以下情况：可能发生降低所计划的查询调度的功效或愿望的运行时事件(例如，当处理核具有远大于或远小于预期的运行时可用性时)。
因此，并行化查询(或它的部分)的多核处理的有效调度是一个困难以及重大挑战。在这点上的失败可能非常限制可用计算资源的效率以及可用人力资源的生产力。
发明内容
根据一个一般方面，包含记录在计算机可读介质上的指令的系统可以包括：操作符管理器，其被配置成用于确定可用核的数量并且在查询的多个操作符之间分配核，存在通过含有操作符的运行中集合的操作符的多个查询路径。操作符管理器可以包括：状态监视器，配置成用于确定可用核的数量并且确定操作符的运行中集合；关键路径选择器，配置成用于从查询路径以及操作符的运行中集合中确定查询的关键路径；以及工作量管理器，配置成给运行中集合以及关键路径的运行中的操作符分配可用核的第一个核，并且此后从关键路径选择器接收新关键路径并且给该新关键路径的运行中的操作符分配可用核的第二个核。
实施方式可以具有一个或多个以下特征。例如，关键路径选择器可以配置成确定关键路径，包括对每个查询路径的操作符的操作符执行时间总计以及之后选择具有最大的查询路径总计执行时间作为关键路径。关键路径选择器可以配置成通过在为运行中集合以及关键路径的运行中的操作符分配第一个核之后，为每个查询路径重新计算总计操作符执行时间并且选择具有最大的查询路径总计执行时间的新关键路径来确定新关键路径。关键路径选择器可以配置成确定新关键路径，包括在给运行中集合以及关键路径的运行中的操作符分配第一个核之后，为每个查询路径计算总计操作符执行时间；确定潜在的关键路径用于给运行中集合以及潜在的关键路径的运行中的操作符分配第二个核，该潜在的关键路径具有最大的查询路径总计执行时间；根据工作量管理器确定给运行中集合以及潜在的关键路径的运行中的操作符分配第二个核将不会提供它的执行时间上的净利益；并且确定具有第二大的查询路径总计执行时间的新关键路径。
工作量管理器可以配置成分配第一个核，包括确定运行中集合以及关键路径的运行中的操作符的减函数，第一个核的分配将导致它的执行时间的净减。操作符管理器可以配置成继续给查询路径的运行中的操作符分配可用的核，直到工作量管理器根据运行中的操作符的减函数确定给任何运行中的操作符分配任何可用核都不会导致它的执行时间的减少为止。状态监视器可以配置成检测状态的变化，包括新的可用或不可用核、查询的运行中的操作符的开始或完成，并且可以配置成根据状态的变化停止或开始操作符管理器的操作。
系统可以包括配置成确定包括所述查询的多个查询的查询管理器，其中该查询管理器包括：查询选择器，配置成确定可用核的总数量以及配置成给操作符管理器分配可用核的总数量的可用核用于通过所述核并行处理查询；以及查询监视器，配置成监视多个查询以便确定它们的状态。
在这种情况下，查询选择器可以配置成确定与多个查询相关联的树的形状并且根据树的形状和可用核的总数量确定多查询处理算法。查询选择器可以配置成实施包括剩余时间最短任务优先(SRJF)算法的多查询处理算法，根据该算法查询监视器从多个查询中选择用最短剩余时间来完成的查询，并且查询选择器给该查询分配可用核以便由操作符管理器在它的并行处理中使用。查询选择器可以配置成实施包括利益驱动平衡关键路径(BD-BCP)算法的多查询处理算法，根据该算法执行循环赛，在该循环赛中查询监视器从多个查询中根据向它分配核的经验选择具有最大利益的查询，并且查询选择器给该查询分配第一个核，随之继续该循环赛，查询监视器根据从多个可用核向它分配核的经验选择具有下一个最大利益的下一个查询。
根据另一个一般方面，一种计算机实现的方法可以包括：确定含有多个操作符的查询，该操作符包括操作符的运行中集合，存在通过该集合的多个查询路径；确定可用核的数量，根据多个查询路径的每一个的总计执行时间确定多个查询路径的关键路径；给运行中集合以及关键路径中的第一操作符分配第一个可用核；根据该分配确定通过多个查询路径的新关键路径；以及给运行中集合以及新关键路径中的第二操作符分配第二可用核。
实施方式可以具有一个或多个以下特征。例如，确定关键路径可以包括总计每个查询路径的操作符的操作符执行时间，并且选择具有最大的查询路径总计执行时间作为关键路径。分配第一个可用核可以包括确定与运行中集合以及关键路径中的第一操作符相关的减函数，该第一个可用核的分配将导致它的执行时间的减少。
确定新关键路径可以包括：在给运行中集合以及关键路径中的第一操作符分配了第一个可用核之后为每个查询路径计算总计操作符执行时间；确定潜在关键路径，用于给运行中集合以及潜在关键路径的运行中的操作符分配第二可用核，该潜在关键路径具有最大的查询路径总计执行时间；确定给运行中集合以及潜在关键路径的运行中的操作符分配第二可用核将不会提供它的执行时间的净利益；以及确定具有下一个最大的查询路径总计执行时间作为新关键路径。
确定查询可以包括：从多个查询中确定所述查询；确定核的总数量，以及确定多个查询中具有最短剩余时间来完成的查询；以及根据所确定的具有最短剩余时间来完成的查询，给该查询分配核总数量的可用核。确定查询可以包括：从多个查询中确定所述查询；确定核的总数量，为多个查询的每一个设计与查询执行时间的减少相关联的有益长度，该执行时间的减少是由于给每个查询分配核总数量的至少一个核以便通过所述核进行处理而引起的；根据该设计给查询分配核总数量的至少一个核；根据该分配为多个查询的每一个重新设计有益长度；以及根据该重新设计给查询分配核总数量的至少第二核，核总数量的第一个和第二核由此构成查询的可用核。
根据另一个一般方面，计算机程序产品可以有形地具体实施到计算机可读介质上并且可以包括指令，当执行时，该指令配置成：确定包括多个操作符的查询，该操作符包括操作符的运行中集合，存在通过该集合的多个查询路径；确定可用核的数量；根据多个查询路径的每一个的总计执行时间确定多个查询路径的关键路径，给运行中集合以及关键路径中的第一操作符分配第一个可用核；根据该分配确定通过多个查询路径的新关键路径；以及给运行中集合以及新关键路径中的第二操作符分配第二个可用核。
实施方式可以具有一个或多个以下特征。例如，可以通过对每个查询路径的操作符的操作符执行时间总计并且选择具有最大的查询路径总计执行时间的关键路径来确定关键路径。可以通过以下方式来分配第一个可用核：根据与运行中集合以及关键路径中的第一操作符相关的减函数确定给它分配第一个可用核将导致它的执行时间的减少。
在附图和下面的说明中阐述了一个或多个实施例的细节。根据说明书以及附图，并且根据权利要求，其它特征将是显而易见的。
附图说明
图1是用于调度并行化查询的多核查询调度系统的框图。
图2是由图1的系统执行的多个查询的框图。
图3是示出使用图1的系统、用于查询的操作符的示例性调度函数的框图。
图4是示出图1的系统的示例性操作的流程图。
图5是示出使用图1的系统执行图2的查询的示例性操作的流程图。
图6是示出使用图1的系统执行图3的查询的示例性操作的流程图。
图7A和7B是示出图5的操作的示例性结果的图表。
图8A和8B是示出图6的操作的示例性结果的图表。
具体实施方式
图1是用于调度并行查询的多核查询调度系统100的框图。系统100中，查询调度器102被配置成调度多个查询104、106、108以及每个单独查询的多个部分(例如，操作符)的并行执行。系统100能够在执行查询104、106、108的运行时期间以下面的方式提供这些并行执行：以最佳的并且动态的方式利用可用计算资源，同时最小化或避免这样的情况，其中与并行化相关联的开销压制或掩没了并行化的好处。
图1中，查询调度器102与计算设备110相关联(例如，可以在计算设备110上执行或者与之相关联)。计算设备110，其可以代表不止一个计算设备，将被理解成与公知的硬件和软件组件相关联，因此不需要在这里详细描述它们。为了理解图1的操作，计算设备110被图解为包含数据库应用112或者与之相关联，其可以被理解成代表，例如，任何相关的数据库和关联组件(例如，数据库管理系统(DBMS)、索引、图表和/或实际数据)。
因此，查询104、106、108可以被呈现给数据库应用112，以便从其获得查询结果。在本上下文中，可以理解的是，术语“查询”通常用于表示实际上可以由计算设备110使用数据库应用112或其他相应应用来并行执行的任何任务。例如，除了从数据库中检索数据，查询104、106、108还可以表示请求由应用执行计算的查询或其他任务，该应用之后应当返回它的结果。根据并行计算的领域，其他这样的使用和示例将是清楚的，并且不必在这里讨论，所以应当理解的是，所提供的示例仅仅是为了说明以及示例而被包括于此，并且因此不应当被认为是限定性的。
计算设备110被图示为包括多个核114、116、118。在这点上，术语“核”应当被理解为指代或包括多个计算平台，在这些平台中可以使用多个处理器、中央处理单元(CPU)或其他处理资源，包括网络/设备群。例如，并行查询处理被称为用于改善现有SMP/CMP(对称多处理/芯片级多处理)服务器的数据库性能的一个选项，特别是对于能够有效处理大量数据和复杂查询的高性能数据库系统。因此，在本说明书中，应当理解的是，术语“核”表示具有在其中多个处理选项可用的任意这种环境内的处理能力的单元。
在这样的环境中，已知的是，核114、116、118可以被动态地分配给多个应用或它们的任务。例如，在图1中，为了说明可以在应用112、120(或者它们的任务)内部以及之间分配核114、116、118这一点，示出了独立的应用120。例如，在给定的时间，核114、116可以被分配到数据库应用112，同时核118可以被分配到应用120。在这样的例子中，可以是这样：数据库应用112的任务被视为比应用120的那些任务更重要或更紧急，所以为了加快处理数据库应用112的任务(例如，处理查询104、106、108)，将两个核114、116分配到数据库应用112。
具体来说，每个查询104、106、108可以包括多个操作符，诸如查询104的操作符120-128。这些操作符可以表示与数据库应用112相关的各种查询操作(诸如，例如，用于从数据库应用112选择数据的“选择”操作，或者用于结合其数据的“结合”操作，下面提供了这些操作更加详细的例子和说明)。操作符可以形成具有反映查询的根本特性和结构的特征形状的树。下面提供了这些操作符树的更详细的例子和说明。
在上面的例子中，可以将核114、116中的一个或两个都分配给查询104(即，给它的操作符120-128)。一般而言，像刚才所描述的那样，可以预期的是，给特殊的操作符/任务诸如操作符120分配两个核114、116将导致该操作符比只分配给它核114或116中的一个完成得更快。例如，每个操作符120-128被示为具有这样的数字对：其代表核114、116中的一个或两个被分配给相应操作符这两种可能性。因此，操作符120被示为具有数字对4/3，该数字对表示仅用分配给它的一个核114用4个时间单位将它完成，而使用分配给它的两个核114、116用3个时间单位将它完成。类似地，操作符122、124、126的数字对4/3，8/5和3/2分别表示为每个操作符分配两个核114、116的好处。
然而，如上所述，分配越多的核将导致越快地处理任务这样的一般假定可能不总是正确的。例如，操作符128被示为具有数字对3/3，其表示操作符128花费了3个时间单位而无论是给它分配了核114、116中的一个还是两个。在这种情况下，明显可见，给操作符128分配第二个核最多是不好不坏，并且通常将表示对努力和计算资源的潜在浪费，这些努力和计算资源用到别处可能更好(例如，使用核之一来处理查询106或者应用120的任务)。
关于为什么操作符的执行时间一般不与分配给它的核的数量按正比或线性比例减少(例如，加倍所分配核的数量的结果不会导致执行时间的减半)，存在许多可能原因。下面详细地讨论了这些原因的示例。通常，一个可能的重要原因涉及与配置和执行讨论中的操作符的并行化处理相关的计算开销，讨论中的操作符例如操作符120。
在这点上，查询调度器102被示为包括开销管理器130，其被配置成使用例如核114、116配置并执行例如操作符120的并行化处理。例如，为了给操作符120分配两个核114、116，操作符120的某些操作或计算必须分配给核114，而其他的分配给核116。然而，由于在单个操作符120内，这些操作可以相互依赖，所以，例如，必须决定哪些操作分配给哪个核，和/或如何从操作符120中分离这些操作，以及最后如何合并回操作符120中。为了确保满意的结果，通常必须追踪(track)并管理这些划分。此外，可以根据相关系统结构(例如，计算设备110的)和/或根据讨论中的操作符120的特性有区别地产生并行操作的这些分离/追踪/合并。
为了给出一些具体的示例，公知的是，在相关数据库系统中存在用于数据处理的多个操作符，可以采用一种或多种方式并行化其中的每个操作符。例如，对于‘选择’操作符，数据表可以被划分成多个部分并且可以在这些部分上并行地处理选择。然后来自这些部分的结果可以被集中在一起用于输出。如果在选择条件下表格的属性是按区间划分的，则只需要处理这些部分的子集。对于‘排序(sort)’操作符，表格首先可以被简单划分并且局部地排序每个部分，然后可以应用合并排序(merge-sort)以便获得最终结果。这可能导致合并阶段相当大的开销。对于‘计划(project)’操作符，当并行地选择所有的数据时，可以执行不需要副本删除(duplicate elimination)的计划。如果需要副本删除，则一旦在并行排序中发现这些副本就可以删除它们。对于‘结合(join)’操作符，存在许多并行结合算法，其中许多算法共享这样的思想：持续划分两个结合表格然后并行地结合相应部分。作为最后一个示范性操作符，对于‘总计(aggregate)’操作符，也可以划分表格并且在每个部分上局部地计算该集合。然后，可以集中来自每个部分的结果以便计算最终结果。
如上述讨论所示，可以采用划分和合并(partition-and-merge)的方式并行化多数的数据库操作符。如上所述，虽然并行化执行一个操作符具有减少总体执行时间的潜在好处，但是当过多地并行化操作符时，由于并行化造成的开销可能抵消该好处。如由开销管理器130管理的开销，可能主要由以下原因造成：例如，(1)启动成本(即，开始并行操作所需的时间)，(2)终止成本(即，结束并行操作所需的时间，诸如合并结果)，以及(3)同步成本(即，每个并行处理相互同步所需的时间)。通常，并行化的程度越高可能导致越严重的资源竞争，严重地降低并行化效果。
在术语中，将多个核分配给单个操作符以及包括相关联开销管理的操作符的操作的最终并行化，是指操作符内部的并行化。该操作符内部的并行化可以与操作符之间的并行化相对照，其中，如下面详细描述的，可用核尽可能被分配给多个运行中的操作符。例如，不是将两个核114、116都分配给操作符120(操作符内部的并行化)，而是，查询调度器102可以将核114分配给操作符120，与此同时，将核116分配给操作符122(操作符之间的并行化)。
如下面详细说明的，查询调度器102被配置成确定是否、何时以及如何将核114、116、118中的一些或全部分配给一个或多个查询104、106、108，以及一旦分配完毕，则确定是否以及如何在单个查询(例如，查询104)内使用一个或两个操作符内部和/或操作符之间的并行化。也就是说，除了做出关于单个查询104的决定之外，查询调度器102可以配置成在查询104、106、108本身内部以及这些查询之间分配核114、116、118。在分离的查询中(与在单个查询的操作符中相对)分配核114、116、118在这里被称为查询之间的并行化。
因此，查询调度器102包括用于管理查询之间的并行化的查询管理器132以及用于管理查询内部的并行化的操作符管理器134(例如，操作符内部和/或操作符之间的并行化)。例如，查询管理器132可以负责确定应当将三个核114、116、118还是两个核114、116分配给查询104，剩余的一个核118分配给查询106，而没有核分配给查询108(直到至少完成了其他的查询104、106之一为止或者直到更多的核变得可用为止)。在另一个例子中，查询管理器132可以将全部三个核分配给查询104直到完成查询，然后可以将全部三个核分配给查询106直到完成查询，然后分配给查询108，直到该组查询104、106、108完成为止。
当然，除了这些组合之外的其他示范性组合也是可能的，但是通常如下所述，查询管理器132可以负责分配核114、116、118以便总体上最小化查询组104、106、108的平均响应时间(或者获得一些其他的性能度量)。因此，查询选择器136可以负责选择哪个查询104、106、108接收哪个(以及多少)核114、116、118。查询监视器138监视查询并且当需要附加的动作时，通知查询选择器136。例如，如果查询管理器132的查询计划是给查询104、106、108中具有最短剩余时间去完成的查询分配所有的核114、116、118，则可以首先将所有的核114、116、118分配给查询104。然后，查询监视器138监视查询104的执行，并且检测查询104何时完成，在该时间点核114、116、118可能是空闲的，并且查询选择器136可以确定之后查询108具有最短的剩余时间去完成，从而将核114、116、118分配给查询108。下面例如针对图2提供了查询管理器132的操作的进一步描述和例子。
在查询选择器136给给定查询(诸如查询104)分配了核114、116、118中的某些或全部的时间内，操作符管理器134负责在该查询的操作符(例如，查询104的操作符120-128)内部以及之间分配可用核。例如，如果查询选择器136给查询104分配核114、116，并且给查询106分配核118，则操作符管理器134可以被配置成在查询104的操作符120-128内部以及之间分配核114、116。
这种通过操作符管理器134在查询104的操作符120-128内部以及它们之间进行的分配核114、116(或者其他可用核)可能发生，诸如上面所述的操作符内部以及操作符之间并行化的组合。可以从上面的说明中看到，在该上下文中给操作符分配多个核可以相当可观地减少它的执行时间(例如，操作符124被示为当被分配第二个核116时，其执行时间从8个时间单位减少到5个时间单位)。另一方面，由于并行化开销以及其他可能的原因，这种逐渐增加或已增加的核的数量的分配可能不会导致该操作符的执行时间有任何相应减少(诸如操作符128，无论使用了一个还是两个核，其都花费3个时间单位来执行)。
扩展这个概念，显而易见的是，给单个操作符分配多个核在某种程度上实际上变得适得其反并且导致该操作符执行时间变得更长而不是更短。例如，还是关于操作符128，可以看到，分配第三个核118可能容易导致操作符128的执行时间增加到4个时间单位。再有，这可能是由于这样的事实，与并行化操作符128的并行化开销相关的计算考虑可能掩没了向它的处理贡献额外的核的所有好处。
在本说明书中，这种操作符的执行时间与分配给它的多个核之间的关系在这里被称为该操作符的减函数fop(n)，所以对于讨论中的操作符，对于给定数量“n”的核，估计执行时间EET＝[T][fop(n)]，其中T表示用n＝1的一个核执行操作符所需的时间。因此，操作符的执行时间的减少(或者缺少)被表示为分配给它的核的数量的函数。因此，对于操作符的三个因子，执行时间EET、核的数量‘n’以及减函数fop(n)，应当明显看到，可以使用这三个因子的任意两个来推导第三个。可以根据经验确定给定操作符的减函数，或者在某些情况下可以根据讨论中的操作符的知识、相关的系统结构以及影响减函数的其他特征来推导该函数。下面讨论这种减函数的特征和例子，并且图3中示出了不同的相应操作符的示例性减函数。
除了执行操作符内部并行化之外，核114、116、118以及查询调度器102可以用于执行操作符之间的并行化，如上所述。在这种情况下，多个核每次都被尽可能地分配给多个不同的(运行中的)操作符。因此，图1中，如上所述，给操作符120分配两个核114、116而不给操作符122分配(至少直到操作符120完成才分配给操作符122)是操作符内部并行化的一个例子。相反，通过给操作符120分配一个核而给操作符122分配另一个核来分配两个核114、116提供了操作符之间的并行化的例子。在两个例子中，两个核114、116被一起并行使用，但是在第一个(操作符内部)例子中，核114、116用于讨论中的单个操作符120，而在第二个(操作符之间)例子中，两个核114、116被分别并且单独应用到两个操作符120、122。
这两个不同类型的并行化具有不同的特征和优点/缺点，并且因此可以或多或少适合于最小化给定查询的(即，它的操作符的)执行时间。例如，通常，可以理解的是，操作符内部与操作符之间的并行化之间通常存在一个折衷。具体来说，操作符内部并行化通常是不受操作符之间的相关性限制的。然而，操作符内部并行化的开销可能随着并行化的程度增加而增长。与此同时，查询评估树(例如，线性树或浓密树(bushy tree)，如下面结合图5以及图7A/7B所述)的形状可能很大程度地影响操作符之间的并行化。例如，线性树可以为并行执行提供比浓密树更少的机会。另一方面，操作符之间的并行化不必要求频繁的划分和合并，这使得并行化的开销相对较小。
因此，操作符内部并行化可能遭受如上所述的并行化开销。与此同时，操作符之间的并行化可能遭受这样的事实：只可能尽可能快地以最慢的路径允许的速度那样执行通过操作符树的路径的查询。在说明这点的简单例子中，可以理解的是，如果给操作符树的三个主要并行分支中的每一个都分配核114、116、118中单独的一个，则最慢的分支将指示完成查询的总体时间，这是因为，即使快速地完成了其他两个分支(以及相应的核)，查询作为一个整体也将被迫等待其余的/最慢的路径。
图1的查询104的例子可以说明执行操作符内部和/或之间的并行化的某些不同特征。例如，如果给查询104分配两个核114、116，并且最大化操作符内部的并行化，则两个核114、116每次都将被正确地分配给一个就绪/运行中的操作符。例如，可以首先将核114、116分配给操作符120，在操作符120完成之后，可以将核114、116分配给操作符122，然后分配给操作符124，然后分配给操作符126，然后分配给操作符128。因此查询104的总执行时间(根据与各个相关联的数字对所确定的那样)是3+3+5+2+3＝16个时间单位。
相反，如果操作符之间的并行化被最大化，如上所述，则核114、116每次都将被尽可能分配给多个操作符。例如，首先将两个核114、116分别分配给操作符120和122，然后分别分配给操作符124和126。在这一点，只有操作符128会被剩下，因此将两个核分配给操作符128。因此在这种情况下，查询104的总执行时间将是4+8+3＝15(这里，在该计算中，操作符120、122花费相同的时间去完成，并且操作符126的执行时间被包含在操作符124的执行时间内，该执行时间更长)。
在最后一个例子中，可以以混合方式使用操作符内部以及操作符之间的并行化。例如，首先给操作符120、122分别分配两个核114、116，并且给操作符124分配两个核。在操作符124完成之后，可以将核114、116继续分配给操作符126和128。因此在该例子中，查询104的总执行时间是4+5+2+3＝14，它是三个例子中最好的。
因此，上面的例子说明，诸如查询104这样的查询最佳执行时间不但依赖于查询计划的特性(即，每个操作符的执行时间以及操作符之间的相关性)而且依赖于并行化执行具体的操作符的开销。即，如果操作符依赖于另一个操作符的完成，则相互依赖的操作符之间的核的分配将只是尽可能有助于最慢路径上的操作符的执行时间。然而，试图通过增加最慢路径上操作符的操作符内部并行化来减少最慢路径上操作符的执行时间，这可能与充足的并行化开销相关联，该开销抵消或掩没最慢路径的或者作为整体来说的查询的并行化的好处。
在这点上，上面提及的最慢路径是在这里被称为关键路径(或CP)的一个例子。更一般地，这样的查询的关键路径是查询内的一组操作符，形成一个从当前运行中的操作符之一到出口操作符的路径，该路径的计算成本的总和是最大的。这里可以使用查询的关键路径CP的长度(CPL)作为查询内CP的每个操作符的单独估计执行时间的总和。用于确定每个单独操作符的估计执行时间的某些技术是公知的，并且下面提供与本说明书有关的或对理解本说明书有用的具体例子。
在操作符管理器134的实践中，状态监视器140可以用于监视查询104的操作符120-128的当前状态和/或用于确定核114、116、118的当前状态(例如，在给定的时间所给的核是否可用)。因此，状态监视器140可以用于确定操作符120-128的当前运行中的集合(RS)。例如，在查询104中，可能发生的是，操作符120必须在任何其他操作符122-126可能开始之前完成，在这种情况下操作符120可能是运行中的集合的唯一成员。另一个例子中，可以并行执行操作符120和122，所以操作符120、122可以是当前运行中的集合(RS)的成员。当状态监视器140确定运行中的集合的操作符之一完成时，状态监视器140就可以确定一个新的运行中的集合，该集合减去了至少已完成的操作符并且可以增加任何新开始的操作符。
关键路径选择器142可以从状态监视器输入信息并且确定讨论中的查询的当前的关键路径。例如，如刚才所提及的，关键路径选择器142可以确定当前运行中的集合的每个操作符，并且可以使用每个路径的每个操作符的估计执行时间(EET)并且假设为每个非运行中的操作符(即，操作符的非运行中的集合的成员)分配/将分配一个核，来为每个这样的操作符计算用于完成(例如，用于操作符128的完成)的所有可能路径。因此，可以看到的是，在具有并行执行线程的查询中，在任意给定的时刻将会发生，在每个线程内将运行/执行零个或者一个操作符。从每个这样的运行中的操作符开始，查询路径从那开始到查询的结束一直存在。因此，这样的操作符的运行中的集合可以用于定义多个查询路径，从其中选择关键路径用于执行算法。
在图1中，操作符120、122可以构成操作符的运行中集合的成员，所以第一查询路径将从运行中的操作符120到结束操作符128一直存在，而第二查询路径将从运行中的操作符122到结束操作符128一直存在。因此，状态监视器140可以检测这些操作符120、122正在运行以及核114、116可用于在查询104内进行分配。然后，关键路径选择器142可以确定在运行中的操作符120开始的查询路径具有总计最高的估计执行时间并且因此是具有相关联的关键路径长度(CPL)的关键路径。
然后，工作量管理器146可以输入所确定的当前关键路径(包括关于操作符120、122的信息，该操作符是当前运行中集合的成员，以及关键路径的运行中的操作符120的标识)。然后，工作量管理器146负责确定是否给当前的关键路径(即，给它的当前运行中的操作符120)分配可用核，以便减少当前关键路径的长度(例如，总计的估计执行时间)。如上所述，减少关键路径的长度在某种意义上可以对减少整个查询104的执行时间具有最大的或者最可能的有益效果。
在给当前的关键路径分配核的过程中，工作量管理器146可以依赖关键路径的运行中的操作符的减函数。例如，工作量管理器146可以访问减函数的数据库148，该减函数包括关键路径的运行中的操作符120的减函数。因此，工作量管理器146可以确定给关键路径的运行中的操作符120分配可用核是否会提供运行中的操作符120的执行时间的减少。
如果会，则工作量管理器146可以给运行中的操作符120分配可用核。如果(如由状态监视器140所确定的那样)要分配剩余的其他核，则关键路径选择器142可以选择一个新关键路径。在某些情况下，之前计算的关键路径可以仍然是关键路径即使在新分配之前的可用核(以及操作符120的执行时间的相关联减少)的情况下，所以操作符120可以继续是新确定的(在这种情况下，同样的)关键路径的运行中的操作符。
然而，在其他情况下，给运行中的操作符120分配可用核的行为可以减少当前关键路径的长度，以使它变得更短，而通过查询104的操作符树的另一个查询路径成为关键路径(例如，从操作符122开始的查询路径)。在这两种情况下，工作量管理器146再次执行给新确定的(例如，相同或不同的)关键路径的运行中的操作符分配可用核的函数，如果相应的减函数指示：这样的分配将提供查询104的执行时间的减少的净利益。然而，如果减函数指示：给新的关键路径的运行中的操作符分配可用核将维持或增加运行中的操作符的执行时间，则关键路径选择器142可以确定次优关键路径并且重复相关运行中的操作符的处理。下面将例如针对图3提供操作符管理器134的操作的更详细的附加说明和例子。
因此，操作符管理器134的以上描述说明了这样的操作：其中确定关键路径并接收可用核，然后可以创建新的/不同的关键路径，然后向该路径本身可以分配一个可用核。例如，只要附加的核是可用的就重复该过程，或者重复该过程直到再没有将从附加的可用核获益的关键路径存在为止。因此，该过程被称为使用平衡的关键路径(BCP)，因为它通过讨论中的查询的操作符树而动态地平衡和最优化。
因此，本说明书提供了用于最优化多核系统上执行的并行化查询的查询调度结构的例子。如所述的，为了加速查询104、106、108的总体响应，查询调度器102可以用于在运行时调整操作符内部、操作符之间以及查询之间的并行化。查询调度器102可以被配置成确定应当并行化多少个查询和查询操作符，以及它们的执行顺序。查询调度器102可以在运行时调整操作符内部、操作符之间以及查询之间的并行化，以便最小化在线到达查询的总体平均响应时间。
为了达到这些目标，操作符管理器134可以用于执行所述的平衡关键路径(BCP)算法，以便调度单个查询并行执行来最小化它的响应时间。此外，可以由查询管理器132来实施用于调度多个查询的执行的策略，以便最小化它们的平均响应时间。如这里详细描述的，这里描述的算法和策略可以用于考虑运行时环境中可用核的数量以及其他因素，诸如查询/操作符树的形状以及并行化开销。
图2是由图1的系统执行的多个查询的框图。具体来说，图2示出了图1的三个查询104、106、108以及将由查询管理器132在查询104、106、108内部以及查询104、106、108之间分配的核114、116、118，如这里所述。
在图2中，查询104、106、108被示为分别具有用于完成标号为202、204、206的剩余时间。正如可以看到的那样，完成查询104的长度202的时间比完成查询108的长度206的时间短，完成查询108的长度206又比完成查询106的长度204的时间短。
还是在图2中，完成长度202、204、206的每个时间被示为分别与有益长度(benefit length)208、210、212相关联。即，完成查询104的长度202的时间具有有益长度208，该有益长度表示增加执行查询104的附加核将有益于(即，减少)完成查询104的时间的范围。换句话说，如可以从图1的上述讨论中理解的，有时给正在执行的查询(或它的操作符)增加一个核可以具有较大的有益效果，而在其他情况下这样的增加可能没有好处或者可能是有害的。因此，有益长度208、210、212表示给每个查询(例如，给特殊的查询操作符)增加一个或多个核的净效益。如可以看到的，有益长度212是最小的，而有益长度208较大，有益长度210最大，其再次表示这样的事实：给查询106增加一个核对于查询106的总完成时间将具有一个较大的净利益。
然后，在一个实施例中，查询选择器136可以使用剩余时间最短任务优先(shortest remaining job first，SRJF)算法给一个或多个查询分配核。在该算法中，一次将尽可能多的核分配给具有最短完成长度时间的查询，在这种情况下，该查询是查询104，如将核114、116、118连接到查询104的虚线所示。当最短的剩余任务(完成时间)完成时，查询监视器138就这样报告给查询选择器136，在此之后查询选择器136可以选择下一个剩余时间最短的任务，在这种情况下该查询可以是查询108。因此，查询选择器136可以给查询108分配所有三个核114、116、118(本例中为了简单，假设增加该数量的核继续减少讨论中的查询的执行时间并且不会被操作符内部的并行化开销的有害影响或者其他有害的并行化考虑因素所掩没)。
在其他实施例中，查询选择器136可以使用利益驱动平衡关键路径(BD-BCP)算法，在该算法中查询选择器136基于它在增加另一个核将有益于查询整体的程度进行决定，所以在当前的核分配时哪个查询最受益，就将接受可用核。如图2中显而易见的，查询106具有最长的有益长度210，因此在BD-BCP实施例中，查询106将接收核114。如果增加核114至少不会减少有益长度210比有益长度208小，则下一个核，即核116，也将会被分配给查询106，并且如果有益长度210保持最长并因此接收最后的核118，则在下文中将应用相同的注释(comment)，如将核114、116、118连接到查询106的直线所示。其他的例子中，如果它证明，在分配了核之后，有益长度208、212之一比(减少的)有益长度210长，则具有当前最长的有益长度的相应查询将接收可用核。
因此，对于多个查询，当查询调度器102使能查询之间的并行化时，查询调度器102可以考虑如何有效地调度查询并且因此可以至少在刚才描述的SRJF和BD-BCP的两个策略/算法之间进行选择。在这点上，SRJF策略可以通过给估计将在最短的时间内完成的查询(例如，查询104)供给尽可能多的可用核来最小化多个查询的总平均响应时间，如刚才所述的。另一方面，SRJF很可能导致高度的操作符内部并行化，由于可以利用更多的核来尽快地完成最短的剩余任务。此外，正如已经描述的，较高程度的操作符内部并行化通常表示(由开销管理器130执行的/管理的)较高的并行化开销。如所述的，如果并行化开销最后压制并行化的好处，则响应时间甚至比没有并行化执行还要长。因此，SRJF可能不总是最佳的选择。
然后，在当前描述的例子中，同时执行多个查询，例如，执行中的查询是相互部分重叠的。在这种情况下，可以使用多个不同的准则来判断调度或最优化算法的效率。在本例中，如已经提及的，使用平均响应时间(ART)。查询的平均响应时间通常可以包括或者涉及发布查询的时间与完成查询的时间之间的时间间隔。在本说明书中，参考ART的最小化描述了多查询选择，但是应当理解的是，所述技术也可以应用到其他适当的准则。
因此，图2示出了用于考虑查询之间的并行化的两个不同策略。当试图通过向其分配可用核而并行化执行重叠查询时，查询选择器136可以被配置成在这两个策略之间进行选择。通常，例如，这些技术可以涉及可能与讨论中的查询相关的并行化开销的范围，和/或查询树的形状可以指示哪个策略可能是最佳的。此外，多个可用核可以提供选择哪个策略的指示。下面参照图5、图7A和图7B更加详细地描述了这种用于在所描述的两个多查询选择策略SRJF与BD-BCP之间进行选择的选择准则的特性和使用。
图3是示出使用图1的系统的、用于查询的操作符的示范性调度函数的框图。对于图3的例子，详细说明了查询106，并且对于该例子假设六个核是可用的。即，假设计算设备110中至少6个核是可用的，以及如果存在其他查询(诸如查询104、108)，则假设查询选择器136(根据图2、图5、图7A/7B)已给所示的查询106分配至少6个核。然后，在查询106本身中，为了给查询106的不同操作符分配6个可用核，图1的操作符管理器134可以负责执行上述的平衡关键路径(Balanced Critical Path，BCP)算法。
更加具体来说，在图3中，控制操作符302和304管理任务操作符306、308和310的执行顺序，如所示的那样。操作符306与减函数312相关，操作符308与减函数314相关，而操作符310与减函数316相关。如所示的那样，减函数312说明每次给它分配第一、第二、第三、第四以及第五个核(如x轴的核所示)时操作符306经历执行时间的减少(如y轴的EET所示)，但是增加第六个核(由于并行化开销)会导致操作符306的执行时间的增加。与此同时，减函数314说明每次给它分配第一和第二个核时操作符308经历执行时间的减少，但是增加第三个核(由于并行化开销)会导致操作符308的执行时间的增加。另一方面，减函数316说明随着分配给它的核而稳定地减少操作符310的执行时间(表示最小并行化开销或不存在并行化开销)。
对于各种减函数312、314、316，并且通常来说，如上所述，减函数fop(n)在这里被提供为一个这样的系数：当在不同数量的核上运行时获取(capture)操作符执行时间中的差。即，操作符的减函数描述了通过不同程度的并行化将操作符并行化的好处。操作符的减函数的特征可以依赖于系统结构(即，CPU/核速度、存储器的大小和带宽、I/0速度或者是否共享了高速缓存)。这些因素以及相关的因素可以决定不同程度的并行化的潜在的竞争开销(contention overhead)。另一方面，当不同类型的操作符被并行化时它们还可以有区别地行为。这是由于以下的事实造成的：并行化操作符的开销还与操作符的特性密切相关。例如，并行排序可能需要预划分处理或者后合并排序(post-merge-sort)，以便获得正确的最终结果，其引入了比并行选择更多的启动开销和结束开销。即使在同一个操作符中，当选择性或谓词不同时，减函数都可能有所不同。例如，具有复杂谓词的选择是更加计算密集型(computational intensive)的，所以存储器的竞争被减轻。因此，通过没有任何谓词的不同减函数可以特征化这样的选择。
考虑以上以及相关的因素，可以看到的是，当执行之前编译了查询时，如果不同程度地并行化操作符，则可以根据系统结构、操作符的类型以及操作符的潜在资源利用率/竞争评估每个操作符的减函数。也可以通过其他方法确定该减函数。例如，一种策略可以包括适应性地根据配置信息(profilinginformation)适当关闭最佳数量的并行处理器。例如，如果试探性地尝试给一个并行化的操作符增加一些处理器可以提高它的性能，则可以永久地分配给它这些处理器。由于减函数只是理论上拥有一个极值，所以最佳数量的并行处理器的点也可以按经验理论上接近极值。
然后，在操作中，操作符管理器134可以如下分配核318-328。当状态监视器140确定操作符306、308、310处于准备运行的状态(假设全都可以一起开始并且并行化运行)时，关键路径选择器142可以根据通过控制操作符302的每个运行中的操作符306、308、310确定查询路径，然后可以从这些查询路径中选择一个关键路径。
如所示的那样，由在操作符306开始的关键路径330表示该第一关键路径。因此，工作量管理器146可以给关键路径330的运行中的操作符306分配第一核318。然后，可以确定新关键路径332具有一个运行中的操作符308，其可能导致给它分配核320。可以再次确定新关键路径，这次是再次具有运行中的操作符306的关键路径334，从而给它分配核322。
继续该例子，可能发生的是，所述核318-322的分配可以充分减少操作符306、308的执行时间，确定在操作符310开始的新关键路径336。因此，可以给操作符310分配核324。这导致关键路径338的存在以及给操作符308分配核326。
在图3中所示的最后一个例子中，可能发生的是，即使在给操作符308分配核326之后，也可能在操作符308继续引发最终关键路径。然而，在这种情况下，工作量管理器146可以根据减函数314确定给操作符308分配最后剩余的核328将导致向操作符308分配三个核320、326和328。然而，减函数314示出给操作符308分配第三个核将导致它的执行时间增加而非减少。
在这种情况下，工作量管理器146可以根据关键路径选择器确定下一个最好的关键路径，即，下一个最长的或者下一个最慢的关键路径，这种情况下其导致一个新关键路径340的确定。如所示的那样，这个新关键路径由操作符306发起并且因此操作符306接收第六个和最后一个核328。因此，根据这个例子以及这里的说明书可以理解的是，本说明书中术语“关键路径”可以指通过查询的现有查询路径的最长路径的实际关键路径或者字面上的关键路径，和/或可以包括当由于核的减函数而造成实际的关键路径被取消(rule out)分配可用核时被确定为新关键路径的有效关键路径，如刚才所给的例子那样。
图4是示出图1的系统的示例性操作的流程图400。具体来说，图4说明操作符管理器134的示例性操作，其可以由这里描述的(包括对于下面的图5和图7A/7B所述)查询管理器132的操作来补充。下面参照图6和8A/8B还提供了操作符管理器134的操作的另外的例子。
在图4中，可以确定包括多个操作符的查询，所述操作符包括运行中的操作符集合，存在通过该集合的多个查询路径(402)。例如，参照图1和图3的例子，操作符管理器134可以确定查询106。具体来说，操作符管理器134可以从查询管理器132接收正在被计算设备110和数据库应用112紧急处理或日常处理的查询106的标识。如图3中所示，查询106可以包括操作符302-310，其中的操作符306-310形成一个运行中集合(例如，任何或所有这些操作符正在运行或者可能正在运行，而不必等待前面操作符的完成)，所以存在通过查询106的示例性潜在查询路径330/334/340、332/338以及336。
可以确定多个可用核(404)。例如，操作符管理器134可以根据查询管理器132确定已经分配的用于处理查询106的核的某个子集。例如，如图3中，当六个核318-328可用时，可能发生的是，所有六个核或它的某个子集将可用于处理查询106。
可以理解的是，状态监视器140可以用于确定查询106和/或可用核的当前的状态或即将来临的状态。即，状态监视器140可以与查询管理器132通信以便确定该信息，和/或可以直接与计算设备110/数据库应用112以及查询106交互。
可以根据多个查询路径的每一个的总执行时间确定多个查询路径的关键路径(406)。例如，如所述的那样，关键路径选择器142可以选择查询路径330作为关键路径，因为该查询路径的个别操作符的总计/合计估计执行时间是所有查询路径中最大的/最长的。
第一个可用核可以分配给运行中集合中以及关键路径中的第一操作符(408)。例如，工作量管理器146可以给关键路径330中的操作符306、308、310的运行中集合的运行中/第一操作符306分配核318。正如可以理解的那样，在这样做时，工作量管理器146可以根据相关的减函数(例如，312)确保增加可用核将实际减少运行中/第一操作符306的执行时间。
可以根据该分配确定通过多个查询路径的新关键路径(410)。例如，由于先前可用核318的分配，查询路径332可以被确定为新关键路径，如由关键路径选择器142使用查询路径的最新估计的执行时间确定的那样，所述最新估计的执行时间包括现在使用核318的操作符306的减少的执行时间。
第二个可用核可以分配给运行中集合以及新关键路径中的第二操作符(412)。例如，工作量管理器146可以给新关键路径332中的操作符306、308、310的运行中集合的运行中/第二操作符308分配核320。正如可以理解的那样，在这样做时，工作量管理器146可以根据相关的减函数(例如，314)再次确保增加可用核将实际减少运行中/第二操作符308的执行时间。
正如可以理解的，该分配过程可以继续直到，例如，所有运行中的操作符都根据它们各自的减函数被分配了最大数量的核为止，或者直到所有可用核都被分配了为止。状态监视器140可以确定这些条件中的一个或两个，并且还可以确定可能影响操作符管理器的操作的其他状态变化。在后面的情况下，例如，状态监视器可以确定操作符306的完成(根据图4的操作，在这种情况下，分配给它的所有核变得可用于再分配)，或者可以确定新操作符已经开始执行(并且因此根据图4可以要求核被分配给新操作符)，或者可以确定新核在其它情况下变得可用(例如，诸如当先前提供给个别应用120的核完成了与之相关联的某些任务并且随后变得可用时)。
虽然图4不是明确地描述，但是可以理解的是，在给第一个操作符分配了第一个可用核后，关键路径选择器142可以确定潜在的关键路径以及运行中集合的相关联的潜在的运行中的操作符；即，可以确定实际上/字面上具有通过查询106的最长估计执行时间的查询路径。在这样的情况下，可能发生的是，例如，当给这样的潜在关键路径以及相关联的潜在运行中的操作符分配第二个可用核时，工作量管理器146可以根据相关减函数确定该分配实际上将不会导致运行中/潜在操作符的执行时间的减少(诸如上述图3的例子，其中核328将分配给潜在的关键路径332/338，但是由于减函数314而被禁止)。
因此，可能发生的是，只有在这样的确定之后，关键路径选择器142才可以选择新关键路径以及将实际接收可用核的分配的相关联的运行中的操作符(例如，诸如图3的新关键路径340以及核328向运行中的操作符306的分配)。因此，正如已经说明的那样，术语“(新)关键路径”可以指具有最长估计执行时间的查询路径，和/或也可以指或包括具有最长的估计执行时间的查询路径，该最长的估计执行时间也将由于给运行中的操作符分配可用核而受益。
图5是示出使用图1的系统执行图2的查询的示例性操作的流程图500。更具体来说，图5示出了接收多个重叠查询104、106、108的操作，同时多个核可用于处理查询104、106、108(例如，至少核114、116、118和/或在附加的或可替换的例子中，图3的核318-328)。因此，图5示出了接收多个查询104、106、108，确定首先处理哪个查询(或哪些查询)，往那里分配核用于使用查询内部处理技术(例如，这里描述的有关图1、3、4，6和8的平衡关键路径技术)进行处理的整个过程，并且根据需要重复该过程直到完成查询104、106、108为止。
因此，在图5中，可以确定查询104、106、108、查询特征以及可用核(例如，核114、116、118)的数量(502)。例如，查询管理器132，例如，查询监视器138，可用于确定某些或所有这些特征。在本上下文中，术语“查询特征”通常指查询104、106、108的属性，所述属性在决定使用哪个查询之间处理技术时可能是有用的(例如，诸如上述的在剩余时间最短任务优先(SRJF)算法和利益驱动平衡关键路径(BD-BCP)算法之间的选择)。
例如，讨论中的查询的查询/操作符树的形状在这方面可能是有用的。具体来说，如果查询具有包含若干串行连接的操作符的结构(因此可能形成冗长的关键路径)，则BD-BCP算法的应用由于受益于减少关键路径的机会而可能是有益的。在这点上，可以理解的是，在这种情况下，如上所述，从处理给定操作符的多个核的并行化开销可能减轻/掩没/胜于分配给操作符/查询的核的好处这一意义上来说，使用SRJF算法可能导致分配给查询额外数量的核。相反，如果查询具有没有这种串行连接的操作符的结构，则SRJF算法相对来说可能更有用，由于所分配的核可能分配给查询的不同操作符并且因此较不可能引起并行化开销。下面详细提供了诸如查询的数量、核的数量以及查询特征的因素如何影响该查询处理选择过程的更多细节。
因此，在图5中，可以根据之前确定的因素选择查询执行计划(504)，正如上面提及的那样。在本例中，两种可能的查询处理计划被描述为SRJF和BD-BCP算法，虽然也存在其他可能性。
根据所选择的查询处理计划(例如，SRJF或BD-BCP)，选择查询并分配核(506)。例如，如图2中所示，如果使用SRJF算法，则可以选择查询104，并且为了尽快完成查询104的处理可以将所有三个核114、116、118(或图3的例子中的所有6个核318-328)分配给查询104。另一方面，如图3中所示，如果选择了BD-BCP算法，则可用核被分配给查询106(如所说明的那样，由于查询106被示为具有最长的有益长度210)。查询管理器132可以负责做出这些决定并且给最终查询分配所确定的数量的核。下面针对图7A和7B提供了关于做出这样的决定的进一步的例子和讨论。虽然通常可以注意到，BD-BCP算法中核的分配按照相对较精细的间隔尺寸，其中每次考虑一个核并(不)分配到候选查询。相反，在SRJF算法中，在一个步骤中，尽可能多的所需核被大批分配到一个查询。
一旦给查询分配了多个核，则操作符管理器134就可以配置成在所选的查询之中(即，在它的操作符之中)分配核(508)。例如，如所描述的那样，操作符管理器134可以根据每个操作符各自的减函数执行图3和图4实施贪婪算法(greedy algorithm)的例子。下面参照图6和图8A/8B提供了操作符管理器134的操作的更多例子。
只要还没有完成讨论中的查询(510)并且还没有分配最大数量的核(512)，就可以继续在查询的操作符之中分配核的处理(508)。即，如果工作量管理器146确定查询的所有运行中的操作符已经达到了一个点，在该点处额外核的分配将不会减少(或者将增加)它的执行时间，则工作量管理器146就将确定已经分配给该查询的最大数量的核并且将至少暂时停止给它的操作符分配核(并且可以释放任何可用核以用于处理其他查询)。因此，如果达到了该条件(512)，则在继续前进之前状态监视器140将继续等待状态的改变(518)，诸如运行中的操作符或查询的完成，之前非运行中的操作符或查询的开始，或新的可用核。如果发生了这样的状态改变，则可以继续查询操作符之中的核分配处理，如所描述的那样(508)。
另一方面，一旦查询完成(510)，则如果不存在剩余的查询(514)，就可以再等待状态改变(518)。如果查询有剩余(514)但是没有核是可用的(516)，那就可以再等待状态改变(518)。然而，如果查询有剩余(514)并且核是可用的(516)，则可以继续处理之前(或新)选择的查询执行计划(例如，SRJF或BD-BCP)(504)。
图6是示出使用图1的系统执行图3的例子的场景中的查询106的示例性操作的流程图600。即，图6示出了图4的更具体的例子以及图5的操作508，以及与图5的操作510-518类似的或相似的例子。
然后，在图6中，假设已经选择了查询处理计划并且已经给查询106分配了最终数量的核，例如，图3的六个核318-328。然后，开始确定查询106的关键路径，通过讨论中的查询的运行中的操作符选择(第一)查询路径(602)。例如，关键路径选择器142可以选择运行中的操作符306。
然后，可以确定查询路径的(估计)执行时间(604)。例如，关键路径选择器可以使用为运行中的操作符306当前分配的核的数量来计算查询路径中每个操作符的估计执行时间，否则的话假设给当前查询路径的任意非运行中核分配单个核。
更具体来说，可以通过操作符的执行成本以及它们之间的相关性确定一个查询的执行时间。运行时期间可以用不同数量的核来执行操作符，从而使得可能难以确定这样的操作符的精确执行成本。响应时间估计是执行之前用于预计响应时间的一种技术。在本说明书和例子中，使用在这里被称为估计执行时间(Estimation Execution Time，EET)的估计。如刚才描述的那样，对于运行中集合(例如，实际运行或准备运行)中的操作符，EET可以根据减函数以及所占用核的数量计算EET。对于被堵塞的操作符，可以被估计为采用分配的一个核来运行这些操作符。因此，对于正在执行的查询Q中的每个操作符opi，运行中集合包含已经分配了核的所有操作符。下面是一个正式的定义，其中EETi＝fop(n)；如果opi在Q的运行中集合中，或者可替换地，EETi＝fop(1)；如果opi不在Q的运行中集合中。
因此，可以看到的是，如果不能相对精确地估计操作符的优先级，则分配算法可能为核生成无效率的安排。从而，如所述的那样，这里用于确定关键路径(CP)的操作符优先级的查询树的一个这样的属性形成从当前运行中的操作符之一到出口操作符的一条路径，该路径的计算成本的总和最大。CP的长度(CPL)被定义为每个操作符的EET的总和。由于查询始终是树结构并且查询执行从叶子操作符应用到出口操作符，所以从一个运行中的操作符opi到出口操作符的每个路径都是唯一的。假设变量opij表示从opi到出口操作符的路径中编号为j的操作符，而ni是它的路径中的操作符的数量，则CPL是运行中集合中的操作符从j＝0到ni求和后的EETif的最大值。
如果还没有到达最后的查询路径(606)，则继续选择查询路径(602)以及计算它们各自的执行时间(604)的处理过程。一旦到达了最后的查询路径(606)，就可以选择关键路径(608)，例如，具有最长总计/总执行时间的查询路径。
然后，工作量管理器146可以选择关键路径的运行中的操作符(610)，诸如运行中的操作符306。然后，工作量管理器146可以参考它的减函数(例如，减函数312)以便确定是否已经给它分配了最大数量的核(612)。如果没有，则可以给关键路径的运行中的操作符分配核(616)。
然而，如果已经分配了最大数量的核，则如果没有剩余查询路径(613)，则状态监视器140可以被分派为等待任何状态变化(622)，诸如完成/开始查询或操作符和/或新的可用核。如所示的，如果确实有查询路径剩余(613)，则可以选择新的关键路径(614)，诸如确定的查询路径下一个最长的查询路径。再有，工作量管理器146可以检查相应的减函数以便确定是否已经给它分配了最大数量的核(612)。一旦该分析的结果确定还没有达到最大数量(612)，则可以分配一个核(616)。
如果更多的核可用于分配(618)，则可以选择新的关键路径(620)，并且继续选择完全新计算的关键路径的过程(602-608)，该过程包括可用查询路径的重新计算。否则，再次地，状态监视器140可以等待状态改变(622)。
从而，工作量管理器146可以执行给关键路径的运行中的操作符分配核。为了提高一个运行中的查询的耗用时间，可以使用所述的技术，该技术给CP中的操作符分配更多的可用核。具体来说，通过缩短这个查询的CPL从而减少执行长度。换句话说，CP中的操作符被设置成保持相对于其他就绪的操作符最高的优先级。因此，所述的增量、贪婪算法可用于给相应查询树中的运行中的操作符以及就绪的操作符分配核。
由于在一个这样的分配之后CP可能改变，因此为了避免在重要的操作符之前给较为不重要的操作符分配核，在分配处理期间，例如在运行时期间，可以动态地确定操作符的优先级。具体来说，在已经给一个操作符分配了核之后重新计算操作符的优先级，所以，如上所述，重复执行以下的三个步骤。具体来说，确定运行中的查询的CP，给CP中的运行中的操作符分配一个核，并且从上方的操作符到根操作符重新计算执行长度。用于执行这些技术的相应算法是这里所述的平衡关键路径，其包含平衡位于每个潜在CP的顶部的每个操作符的执行成本。这里描述的特殊情况导致何时已经完全分配了CP中的一个运行中的操作符。然后，根据相应的减函数，给它分配的任何新核将仅仅减少消耗时间而没有任何好处。因此，不给它分配新核，并且该操作符所属的CP可能因此从BCP算法中排除。下面提供了有关算法3的BCP算法的具体例子。
图7A和7B是示出了图5的操作结果的例子的图表。如上所述，例如，对于图1、图2和图5(例如，操作504)，它们的查询管理器132可以被配置成选择查询执行计划，诸如SRJF或BD-BCP。
在这点上，如这里所述的，查询被表示成数据库操作符的一个树，其中每个边表示操作符之间的相关性。如图1和图3中所示，每个边表示两个操作符之间的相关性。例如，在图1中，在完成操作符120和操作符122的评估之前不能评估操作符124。形式上，查询Q＝(OP，D)被定义成具有一组操作符OP以及一组操作符之间的相关性D的一个树。查询可以被建模成具有无界的(查询、时间戳)对序列的在线到达查询，所以OAQ＝{(Q1，ts1)，(Q2，ts2)，...}。然后，假设N个核具有彼此相同的计算能力，则这N个核中使用的符号被表示为C＝{c1，c2...，cN}。
因此，如所述的以及其它可能的特征，给定N个核的集合C＝{c1，c2...，cN}、在线到达查询OAQ＝{(Q1，ts1)，(Q2，ts2)，...}、查询中每个操作符的减函数以及查询树的形状/特征，查询调度器102就可以确定如何给不同的查询以及查询中不同的操作符分配核，以及分配给单个操作符的核的数量，以使得查询的平均响应时间被最小化(或者其他适当的性能度量被最优化)。
为了说明图7A/7B和图8A/8B的例子，引用了两个具体类型的查询树结构，即，深树查询和二叉树查询。二叉树查询的例子被表示成图7A中的元素702。在二叉树查询中，通过结合操作符来组织查询树中的所有非叶子节点。由表格扫描操作符来表示每个叶子节点。二叉树查询的数量级可以被指定为[log2N]。这种类型的查询可以被视是浓密树查询的例子，有多个数据库管理系统支持该类型的查询并且该类型的查询为操作符之间并行化提供了机会。同时，在深树(deep-tree)查询中，它的一个例子如图7B中所示的元素704，由一个入口和一个出口将查询的主体组织为结合操作符的一个链。结合的其他入口是，例如，表格扫描操作符。深树查询的数量级被指定为[N/2]，其中在本上下文中N指查询树中操作符的数量。图7A和7B中，示例性的查询树表示其中N＝7的例子。
使用上面的符号和激励，可以理解的是，如上面针对图2所描述的那样，剩余时间最短任务优先(SRJF)算法的意图是为估计将在最短时间内完成的查询提供尽可能多的可用核。因此，在核分配开始时，对于每个查询，可以由它的CPL估计完成时间。然后，在选择了具有最短CPL的正确查询之后，为了尽可能多地减少这个查询的执行时间，查询调度器102可以尝试给它分配所有的可用核。如果仍然存在可用核，则将选择下一个最短查询以便将核分配给其。继续这个过程，直到核用完或者所有查询都被完全分配了核为止。当以后为单个查询分配核时，可以应用这里描述的BCP算法。
作为SRJF算法的预期结果，其试图通过给它分配更多核来最小化相对最短查询的执行时间，每个查询的等待时间的总和相对较短，并且，每个查询的响应时间(它是上面两个时间的总和)也变得很短。如果最短查询处于充分核分配状态，则仍然可以给除最短查询之外的查询分配核。
算法1描述了SRJF的伪代码。SRJF的输入包括运行中的查询的集合以及可用核的数量。由于每个查询是用它的时间戳在线到达的，如上所述，因而时间戳比当前的时间线(time line)长的查询不包括在运行中的查询内，并且在运行了一轮之后，同样应用到已经完成的一些查询。此外，可用核被定义为除了被其他应用以及运行中的查询中的某些专用操作符(exclusiveoperators)所占用的那些可用核之外的所有可用核。SRJF的输出是已经分配了一些可用核的运行中的查询的更新集合。
算法1
如基本上针对图5描述的那样，算法1中，第7行定义了返回条件，即，要么没有可用核、要么运行中的查询集合中的每个查询被完全分配，在该点处完成了一轮的动态调度过程。从第10行到第16行，识别出具有最短剩余时间的任务的查询。注意，这样的识别基于关键路径的合理估计，如这里所描述的那样。第17行试图使用BCP算法给相关的查询分配可用核。如果这样的分配是成功的，则可用核的数量因此被减少，并且可以用新的状态来更新被分配的查询(例如，用新的分配更新查询的运行中集合)。第18行使用函数来检查查询是否已经被完全分配。即，如果相关查询的运行中集合中的每个操作符都处于完全分配的状态，则状态被设置为真，否则状态被设置为假。从第19到22行的区域表示这样的查询：如果该查询已经被完全分配，则应当将其从输入的运行中查询集合(QS)移动到已完全分配的查询集合(FQS)。在完成了分配过程之后，QS和FQS中的所有运行中的查询在第24行中应当被组合，然后在第25行中返回一个更新的运行中的查询。
由于SRJF优选给一个查询分配最大数量的核，所以尽可能多地鼓励操作符内部以及操作符之间(一个查询内的)的并行化。然而，该倾向可能引发更多的操作符内部并行化开销，并且，结果，例如，有关同步、通信以及竞争可能消耗系统的计算资源。于是，为了结合SRJF使用，可以使用BD-BCP算法。
BD-BCP的意图在于最大化查询层次中的每个核分配的利益。即，算法选择具有最多CPL减少量(最大利益)的查询来分配核，如上面针对图2的描述。在分配一个核的每个步骤中，可以通过模拟已经分配了该核而预先计算查询的所有减数据。然后，选择带来最大利益的操作符进行实际分配。
如针对图5已经描述的那样，继续该过程直到用完所有的可用核或者所有的查询变成完全分配为止。形式上，可以为查询集合OAQ中的查询Qi定义利益增量Δi。然后，如果关键路径CPi中运行中的操作符op被完全分配，则Δi是0。否则，如果op已经被分配了m个核并且还没有完全分配，则Δi＝(fop(m)-fop(m+1))。。
在一种特殊的情况下，可能发生的是，OAQ中的查询的所有利益增量都是零，即，每个CPi中的操作符op处于完全分配的状态。为了打破这个束缚，可以选择占用的长度比CP短但是比其他路径长的路径作为新CP。可以循环地应用这个规则直到达到了分配的完成条件为止。
下面的算法2描述了BD-BCP的示例性伪代码。输入和输出包括运行中的查询的集合以及可用核的数量，正如SRJF算法中的那样。主要的差别位于第10行到第19行，其中，BD-BCP策略中，通过关键路径上的利益增量的差而不是像SRJF中那样关键路径的长度来选择候选查询。
此外，两个算法1和2之间的分配粒度(granularity)是不同的。具体来说，例如，第20行描述了BD-BCP中的分配处于精细粒度，该粒度获得一个核并且分配给候选查询。但是，在SRJF中，在一步中将所需要的那么多的核分配给一个查询。
然后，如算法1的SRJF算法中，从第21到25行，检查完全分配的查询并且从输入的运行中查询集合(QS)移动到完全分配的查询集合(FQS)。然后，在完成了分配处理之后，可以将所有运行中的查询组合为更新的运行中查询集合。
在分配的每个步骤中，BD-BCP试图将核应用到能够最大地减少执行时间的查询。例如，该分配可以通过减少并行化开销来达到最大的利益。因此，算法2的BD-BCP算法不优选操作符内部、操作符之间的并行化，也不优选查询之间的并行化。但是，可以看到的是，与SRJF算法相比，BD-BCP算法对于查询之间的情况投入了更多的关注，这是由于每个查询都有在每一步中分配核的机会。
算法2
通过上面的讨论，可以看到的是，许多因素(为了列举一些，例如，可用核的数量、查询的数量、或者查询内操作符的数量)可能影响SRJF和BD-BCP算法的性能。特别对于在线到达查询，这些因素可能随着时间快速并且连续变化。因此，由于不同的查询形状以及系统快照(system snapshot)，可以最有利地应用不同的并行调度策略。
下面，提供了复杂的并行多查询调度的分析与讨论。具体来说，讨论了因素影响SRJF算法的性能的一种方式。在在线到达的情况下，SRJF算法的思想包括选择“剩余时间最短”查询，而之后尽可能多地分配核使得这个查询尽可能早地完成。
至少两个因素影响它的性能：核的数量以及查询/操作符的数量。关于核的数量，可以理解的是，SRJF算法通常目的在于为查询安排执行顺序以便总体上最小化查询的平均响应时间。当核的数量相对较小时，这一般是正确的，这是由于，例如，如果给最短的查询分配了所有可用核则核的数量越少意味着开销越少。这种情况下极端的情况是，当核的数量＝1时，在这种情况中没有并行化可以被平衡(leverage)并且SRJF一般比BD-BCP算法执行得更好。另一方面，如果核的数量相当大，那么由于SRJF算法选择最短的查询并且给那个查询分配尽可能多的核，所以那个查询的并行化开销可能掩没这样的调度的好处。此外，该策略还忽略了一个事实：如果将分配给最短查询的一些核分配给查询之间并行化的其他查询，则这些核可能获得更多的利益。
关于查询/操作符的数量，可以看到的是，SRJF算法的性能的关键考虑因素是由给最短的查询分配太多的核而引发的并行化开销。开销一般来自于过度并行化(over-parallelize)查询中的操作符。因此，如果查询中操作符的数量非常小，则平均下来，每个操作符将分配较多的核，并且这可能导致操作符内部的过度并行化。另一方面，如果最短的查询中的操作符的数量很大，则通过SRJF算法分配给查询的那些核很可能被分配给查询中的不同操作符(注意，如果将多个核分配给单个操作符将引起过多的操作符内部并行化开销，则单个查询中实现的BCP算法倾向于将它们分配给查询中的不同操作符)。在这种情况下，可以避免操作符内部的过度并行化。
总之，上面的两个因素都可能影响SRJF算法的性能。因此，固定核的数量，并且改变每个查询的操作符的数量将引起SRJF算法性能的改变。类似地，当固定查询中操作符的数量时，不同数量的核可能对性能有影响。
通过比较，BD-BCP算法可能受相同因素或不同因素的不同影响。例如，如上所述，每次分配核时，BD-BCP算法都选择可能导致最大的响应时间减少的查询并且将核分配给该查询。
因此，关于可用核的数量，与SRJF策略不同，BD-BCP策略的本质是关于在当前的步骤选择可以最大化响应时间减少量的查询，该最大化是局部最优化的。之后的状态可能变得与当前的估计非常不同。如果可用核的数量存在限制则这种情况可能变得更糟，因为当核的数量相对较小时，BCP算法本身中关键路径长度的估计(如上所述，并且下面针对算法3进行具体说明)可能是不准确的。因此，对于较小数量的核，由于不准确的估计，BD-BCP算法的性能可能降低。此外，如与SRJF算法相比较的那样，BD-BCP算法倾向于给不同的查询分配核，以使得已被分配的查询可以执行相对较长的时间。当核的数量较小时，许多其他的查询可能等待这些非常持久的查询，所以全部查询的平均响应时间可能变得相对较长。另一方面，如果核的数量是充足的(不是太少也不是太多)，则BCP算法的关键路径的估计可能是更准确并且更稳定的，其将从整体上提供BD-BCP算法的稳定性。
对于操作符的数量，可以看到的是，BD-BCP算法将所有的就绪操作符一起考虑，并且从所有查询中选择(使用BCP算法)能够最大化响应时间减少量的操作符。如果可用核的数量是固定的，则改变当前就绪操作符的数量也可以影响BD-BCP算法的整体上的性能。即，这里较大数量的操作符可以暗示BCP算法以及BD-BCP算法本身的较低的稳定性。
下面的表1总结了基于对多查询调度的上述分析的一个策略。表1示出了BD-BCP算法适用于倾向于生成深树查询的数据库管理系统。推荐SRJF算法用于倾向于生成二叉树查询的数据库管理系统。
通常，如表1中所示，当使用具有较少核以及较低并行化开销的深树查询时，或者当使用具有较多(即，充足的)核以及较高的并行化开销的二叉树时，BD-BCP与SRJF之间的性能是不相上下的。对于所有的多查询调度，通过充足的核，所有所描述的技术的性能变得非常相似，因为，通过较大数量的核，所有可用操作符被分配了足够的核并且在完全并行化条件下运行。对于多查询调度，SRJF和BD-BCP的性能显著地受多种因素的影响。因此，可以看到的是，对于一个这样的策略难以在所有环境下提供最好的性能。反而，对于二叉树查询，SRJF表现出较好的性能，这是由于例如消耗较小的开销。同时，由于它的查询之间的并行化不需要消耗更多的开销，所以BD-BCP更适合深树查询。
表1
结合图7A和7B示出了上面讨论的例子。具体来说，图7A示出了二叉类型的树702，SRJF算法对于减少平均响应时间提供了较好的结果，特别是当核的数量较小时，相对于BD-BCP算法或连续并均匀地给查询分配核的传统循环赛方法更是如此。另一方面，图7B示出了深树类型的查询704，与SRJF算法以及传统的循环赛方法相比，BD-BCP算法在减少平均响应时间上是优秀的。根据上面的讨论，可以构建类似的图表以便说明对于每个算法以及查询树类型，较大或较小数量的查询/操作符对减少平均响应时间的影响。
图8A和图8B是示出图6的操作的示例性结果的图表。即，图8A和图8B示出了上面结合图1、图3、图4和图6描述的BCP算法的例子，下面的算法3提供了它的伪代码的例子。
如上面的详细说明，BCP算法依赖以下的事实，通过它的连续部分可能确定并行化执行中一个查询的最大加速，以使得可以给该连续部分分配较多的核，以便减少它的执行时间。在这点上，一个查询中的连续部分以及它的执行时间的估计二者都可以被确定为BCP算法的一部分。
在算法3中，BCP的输入包括运行中的查询以及可用核的数量。在查询运行期间，当任何状态被更新时，可以通过该算法重新调度输入查询，如所描述的那样，这些状态更新可以指查询内部的状态(例如，某些运行中的操作符完成并唤醒其他的操作符)以及查询外部的状态(例如，由于其他应用释放某些核，因此这些核变得可用)。BCP算法的输出是已经分配了一些可用核的更新了的运行中的查询。
第8行定义了完成条件是要么分配了所有的可用核，要么给每个操作符分配了最大数量的核。从第11行到第17行，选择了位于关键路经上的操作符。第18行试图在所选择的操作符上应用一个核。如果操作符符合最大数量核的条件，则分配返回假，否则返回真。并且，在这个函数内部，如果分配成功，则根据它的减函数更新这个操作符的EET。
分配的结果是，将操作符从候选运行中集合(RS)移动到完全分配运行中集合(FRS)，如第22、23行中所述，或者它消耗一个核，如第20行中所描述的那样。在结束了分配算法之后，在第26行中可以组合RS和FRS中的所有操作符，然后，在第27行中返回至一个运行中的查询。对于可用核的每个分配，根据运行中集合中每个操作符的EET计算CPL。
算法3
这里描述的各种技术的实现方式可以被实施在数字电子电路中，或者实施在计算机硬件、固件、软件，或者它们的组合中。实现方式可以实施为计算机程序产品，即实实在在地具体实施在信息载体中的计算机程序，信息载体例如在机器可读存储设备中或者在传播的信号中，以供数据处理装置执行，或者控制数据处理装置的操作，所述数据处理装置例如可编程处理器、计算机、多个计算机。计算机程序，诸如上面描述的计算机程序，可以用任何形式的编程语言编写，包括汇编语言或解释语言，并且，它可以被以任何形式部署，包括作为独立的程序或者作为模块、组件、子程序或其他适于在计算环境中使用的单元。计算机程序可以被部署为在一个计算机上执行或在位于一个地点或跨过多个地点分布并被通信网络互连起来的多个计算机上执行。
方法步骤可以被一个或多个可编程处理器执行，所述可编程处理器执行计算机程序，以便通过对输入数据操作和产生输出来执行功能。方法步骤还可以被专用逻辑电路执行，或者装置可以被实施为专用逻辑电路，所述专用逻辑电路例如FPGA(现场可编程门阵列)或ASIC(专用集成电路)。
作为例子，适于执行计算机程序的处理器包括通用和专用微处理器，以及任何类型的数字计算机的任意一个或多个处理器。一般来说，处理器将从只读存储器或随机存取存储器接收指令和数据，或者从两者都接收指令和数据。计算机的元件可以包括至少一个用于执行指令的处理器，和用于存储指令和数据的一个或多个存储器设备。一般来说，计算机还可以包括，或者被可操作地连接，以从一个或多个用于存储数据的海量储存设备接收数据，或把数据传送到海量储存设备，或者二者皆有，所述海量储存设备例如：磁盘、磁光盘或光盘。适于具体实施计算机程序指令和数据的信息载体包括所有形式的非易失性存储器，作为例子，包括半导体存储器器件，例如：EPROM、EEPROM和闪存设备、磁盘，例如内置硬盘或可移动磁盘、磁光盘和CD-ROM以及DVD-ROM盘。处理器和存储器可以以专用逻辑电路补充，或者被包含在专用逻辑电路中。
为了提供和用户的交互，实现方式可以在具有显示设备和键盘以及定点设备的计算机上实施，显示设备例如阴极射线管(CRT)或液晶显示器(LCD)监视器，用于向用户显示信息，键盘和指示设备例如鼠标或轨迹球，用户利用它们可以提供到计算机的输入。其他种类的设备也可以被用来提供和用户的交互；例如，提供给用户的反馈可以是任何形式的感觉反馈，例如视觉反馈、听觉反馈或触觉反馈，并且，来自用户的输入可以被以任何形式接收，包括声音、语音或触觉输入。
实现方式可以被在包括后端组件或包括中间件组件或包括前端组件的计算系统中实施，或者在这些后端、中间件、前端组件的任意组合中实施，后端组件例如数据服务器，中间件组件例如应用服务器，前端组件例如具有图形用户界面，或Web浏览器的客户端计算机，通过图形用户界面或Web浏览器，用户可以和实现方式进行交互。可以利用数字数据通信的任何形式或介质互连组件，数字数据通信介质例如通信网络。通信网络的例子包括：局域网(LAN)和广域网(WAN)，例如因特网。
虽然如这里所描述的那样已经示出了所描述的实现方式的某些特征，但是本领域普通技术人员现在应当想到很多修改、替换，变化或等同物。因此应当理解，所附权利要求旨在覆盖所有这些修改和变化。

Claims (18)

1.一种多核查询调度系统，该系统包括：
操作符管理器，配置成用于确定可用核的数量并且在查询的多个操作符之中分配核，所述操作符包括操作符的运行中集合，存在通过该集合的多个查询路径，该操作符管理器包括
状态监视器，配置成用于确定可用核的数量并且用于确定操作符的运行中集合，
关键路径选择器，配置成用于从查询路径以及操作符的运行中集合中确定查询的关键路径，以及
工作量管理器，配置成给运行中集合以及关键路径的运行中的操作符分配可用核的第一个核，并且此后从关键路径选择器接收新关键路径并且给新关键路径的运行中的操作符分配可用核的第二个核。
2.如权利要求1所述的多核查询调度系统，其中，所述关键路径选择器配置成用于确定关键路径，包括总计每个查询路径的操作符的操作符执行时间，并且此后选择具有最大的查询路径总计执行时间的关键路径。
3.如权利要求2所述的多核查询调度系统，其中，所述关键路径选择器配置成用于在给运行中集合以及关键路径的运行中的操作符分配了第一个核之后，通过为每个查询路径重新计算总计操作符执行时间并且选择具有最大的查询路径总计执行时间的新关键路径，来确定新关键路径。
4.如权利要求1所述的多核查询调度系统，其中，所述关键路径选择器配置成用于确定新关键路径，包括：
在给运行中集合以及关键路径的运行中的操作符分配了第一个核之后，为每个查询路径计算总计操作符执行时间；
确定潜在的关键路径，用于给运行中集合以及潜在的关键路径的运行中的操作符分配第二个核，该潜在的关键路径具有最大的查询路径总计执行时间；
根据工作量管理器确定给运行中集合以及潜在的关键路径的运行中的操作符分配第二个核将不会带来它的执行时间的净利益；以及
确定具有第二大的查询路径总计执行时间为新关键路径。
5.如权利要求1所述的多核查询调度系统，其中，所述工作量管理器配置成分配第一个核，包括根据运行中集合以及关键路径的运行中的操作符的减函数确定第一个核的分配将导致它的执行时间的净减。
6.如权利要求1所述的多核查询调度系统，其中，所述操作符管理器配置成继续给查询路径的运行中的操作符分配可用核，直到所述工作量管理器根据运行中的操作符的减函数确定给任何运行中的操作符分配任何可用核都将不会导致它的执行时间的减少为止。
7.如权利要求1所述的多核查询调度系统，其中，所述状态监视器配置成检测包括新的可用或不可用核的状态变化、查询的运行中的操作符的开始或完成，并且配置成根据该状态变化停止或开始所述操作符管理器的操作。
8.如权利要求1所述的多核查询调度系统，该系统还包括：
查询管理器，配置成用于确定多个查询，包括所述查询，其中该查询管理器包括
查询选择器，配置成用于确定可用核的总数量并配置成给所述操作符管理器分配可用核总数量的可用核，以便通过所述可用核进行查询的并行处理；以及
查询监视器，配置成监视多个查询以便确定它们的状态。
9.如权利要求8所述的多核查询调度系统，其中，所述查询选择器配置成用于确定与多个查询相关联的树的形状并且用于根据树的形状以及可用核的总数量确定多查询处理算法。
10.如权利要求9所述的多核查询调度系统，其中，所述查询选择器配置成执行包括剩余时间最短任务优先SRJF算法的多查询处理算法，根据该算法，所述查询监视器从多个查询中选择用最短剩余时间来完成的查询，并且所述查询选择器给该查询分配可用核，以便由所述操作符管理器在它的并行处理中使用。
11.如权利要求9所述的多核查询调度系统，其中，所述查询选择器配置成执行包括利益驱动平衡关键路径BD-BCP算法的多查询处理算法，根据该算法执行循环，在该循环中所述查询监视器从多个查询中选择具有向其分配核获得最大利益的查询，并且该查询选择器给该查询分配第一个核，随之继续该循环，查询监视器根据从多个可用核中选择具有向其分配核获得下一个最大利益的下一个查询。
12.如权利要求1所述的多核查询调度系统，其中，所述操作符的运行中集合包括查询的每个并行线程中的查询的每个运行中的操作符，其中多个查询路径中包括从每个这样的运行中的操作符到查询的结束的路径。
13.一种计算机可执行的方法，包括：
确定包括多个操作符的查询，该操作符包括操作符的运行中集合，存在通过该集合的多个查询路径；
确定可用核的数量；
根据多个查询路径的每一个的总执行时间确定多个查询路径的关键路径；
给运行中集合以及关键路径中的第一操作符分配第一个可用核；
根据该分配确定通过多个查询路径的新关键路径；以及
给运行中集合以及新关键路径中的第二操作符分配第二个可用核。
14.如权利要求13所述的方法，其中，确定关键路径包括：
对每个查询路径的操作符的操作符执行时间进行总计；以及
选择具有最大的查询路径总计执行时间的关键路径。
15.如权利要求13所述的方法，其中，分配第一个可用核包括根据与运行中集合以及关键路径中的第一操作符相关的减函数，确定给它分配第一个可用核将导致它的执行时间减少。
16.如权利要求13所述的方法，其中，确定新关键路径包括：
在给运行中集合以及关键路径中的第一操作符分配了第一个可用核之后，为每个查询路径计算总计操作符执行时间；
确定潜在的关键路径，用于给运行中集合以及潜在的关键路径的运行中的操作符分配第二个可用核，该潜在的关键路径具有最大的查询路径总计执行时间；
确定给运行中集合以及潜在的关键路径的运行中的操作符分配第二个可用核将不会提供它的执行时间的净利益；以及
确定具有下一个最大的查询路径总执行时间的新关键路径。
17.如权利要求13所述的方法，其中，确定查询包括：
从多个查询中确定查询；
确定核的总数量；以及
确定多个查询中用最短剩余时间来完成的查询；以及
根据所确定的用最短剩余时间来完成的查询，给该查询分配核总数量的可用核。
18.如权利要求13所述的方法，其中，确定查询包括：
从多个查询中确定查询；
确定核的总数量；
为多个查询的每一个设计与查询执行时间的减少相关联的有益长度，该时间的减少是由给每个查询分配总数量的核中的至少一个核以便通过所述核进行处理而引起的；
根据该设计给查询分配核总数的至少一个核；
根据该分配为多个查询的每一个重新设计有益长度；以及
根据该重新设计给查询分配总数量的核中的至少第二个核，总数量的核中的第一个核和第二个核由此形成查询的可用核。
CN200910159572.3A 2009-06-05 2009-06-05 并行化查询的多核调度 Active CN101908003B (zh)

Priority Applications (4)

Application Number Priority Date Filing Date Title
CN200910159572.3A CN101908003B (zh) 2009-06-05 2009-06-05 并行化查询的多核调度
US12/758,604 US8219546B2 (en) 2009-06-05 2010-04-12 Multi-core scheduling for parallel queries
AT10005824T ATE543137T1 (de) 2009-06-05 2010-06-04 Mehrkernplanung für parallele abfragen
EP10005824A EP2259184B1 (en) 2009-06-05 2010-06-04 Multi-core scheduling for parallel queries

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN200910159572.3A CN101908003B (zh) 2009-06-05 2009-06-05 并行化查询的多核调度

Publications (2)

Publication Number Publication Date
CN101908003A CN101908003A (zh) 2010-12-08
CN101908003B true CN101908003B (zh) 2014-10-22

Family

ID=42790862

Family Applications (1)

Application Number Title Priority Date Filing Date
CN200910159572.3A Active CN101908003B (zh) 2009-06-05 2009-06-05 并行化查询的多核调度

Country Status (4)

Country Link
US (1) US8219546B2 (zh)
EP (1) EP2259184B1 (zh)
CN (1) CN101908003B (zh)
AT (1) ATE543137T1 (zh)

Families Citing this family (37)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102043673B (zh) * 2009-10-21 2015-06-03 Sap欧洲公司 并行处理中执行任务的节点数量的优化选择系统及方法
US8612989B1 (en) * 2010-10-04 2013-12-17 Teradata Us, Inc. Assigning resources among multiple groups of workloads in a database system
US9307048B2 (en) 2010-12-28 2016-04-05 Microsoft Technology Licensing, Llc System and method for proactive task scheduling of a copy of outlier task in a computing environment
JP5678691B2 (ja) * 2011-01-28 2015-03-04 富士通株式会社 検索制御装置、検索制御プログラムおよび検索制御方法
US8381224B2 (en) * 2011-06-16 2013-02-19 uCIRRUS Software virtual machine for data ingestion
US9208197B2 (en) 2011-10-21 2015-12-08 International Business Machines Corporation Dynamic SMT in parallel database systems
US9262216B2 (en) * 2012-02-14 2016-02-16 Microsoft Technologies Licensing, LLC Computing cluster with latency control
US9639575B2 (en) * 2012-03-30 2017-05-02 Khalifa University Of Science, Technology And Research Method and system for processing data queries
US8954419B2 (en) * 2012-05-22 2015-02-10 Oracle International Corporation Method for serial and condition-based execution of operators by parallel processes
US9753778B2 (en) * 2012-07-20 2017-09-05 Microsoft Technology Licensing, Llc Domain-agnostic resource allocation framework
US20140067601A1 (en) * 2012-09-06 2014-03-06 Sap Ag Supply chain finance planning
US9811938B2 (en) * 2013-03-14 2017-11-07 Business Objects Software Ltd. Methods, apparatus and system for analytics replay utilizing random sampling
US9329899B2 (en) 2013-06-24 2016-05-03 Sap Se Parallel execution of parsed query based on a concurrency level corresponding to an average number of available worker threads
US9606840B2 (en) 2013-06-27 2017-03-28 Sap Se Enterprise data-driven system for predictive resource provisioning in cloud environments
CN104376013A (zh) * 2013-08-12 2015-02-25 北京千橡网景科技发展有限公司 用于检索与用户相关联的数据的方法和设备
CN104516635B (zh) 2013-09-26 2022-03-08 Sap欧洲公司 一种管理内容显示的方法、系统及存储介质
CN104516910B (zh) 2013-09-26 2018-01-12 Sap欧洲公司 在客户端服务器环境中推荐内容
TWI533211B (zh) * 2013-11-14 2016-05-11 財團法人資訊工業策進會 用於任務排程之電腦系統，方法及電腦可讀取記錄媒體
US9767151B2 (en) * 2013-11-18 2017-09-19 Sap Se Optimizing database queries having hierarchy filters
US9875279B2 (en) 2013-12-17 2018-01-23 Huawei Technologies Co., Ltd. Data scanning method and apparatus
CN103729417B (zh) * 2013-12-17 2017-11-03 华为技术有限公司 一种数据扫描的方法及装置
US10909117B2 (en) 2013-12-20 2021-02-02 Micro Focus Llc Multiple measurements aggregated at multiple levels of execution of a workload
WO2015094319A1 (en) 2013-12-20 2015-06-25 Hewlett-Packard Development Company, L.P. Generating a visualization of a metric at a level of execution
US9953074B2 (en) 2014-01-31 2018-04-24 Sap Se Safe synchronization of parallel data operator trees
US11294900B2 (en) * 2014-03-28 2022-04-05 Micro Focus Llc Real-time monitoring and analysis of query execution
US10410150B2 (en) 2014-11-04 2019-09-10 Sap Se Efficient computerized calculation of resource reallocation scheduling schemes
CN107193813B (zh) 2016-03-14 2021-05-14 阿里巴巴集团控股有限公司 数据表连接方式处理方法及装置
CN107479963A (zh) * 2016-06-08 2017-12-15 国家计算机网络与信息安全管理中心 一种任务分配方法及系统
US10637964B2 (en) 2016-11-23 2020-04-28 Sap Se Mutual reinforcement of edge devices with dynamic triggering conditions
CN108197255B (zh) * 2017-12-29 2021-01-15 上海瑞家信息技术有限公司 一种设置查询树的方法、设备及计算机可读存储介质
CN108108473B (zh) * 2018-01-02 2023-06-27 联想(北京)有限公司 数据查询方法以及服务器
US10841020B2 (en) 2018-01-31 2020-11-17 Sap Se Online self-correction on multiple data streams in sensor networks
US10891271B2 (en) * 2018-05-25 2021-01-12 Oracle International Corporation Optimized execution of queries involving early terminable database operators
US11176129B2 (en) * 2018-09-30 2021-11-16 Microsoft Technology Licensing, Llc Methods for automatic selection of degrees of parallelism for efficient execution of queries in a database system
US11620510B2 (en) * 2019-01-23 2023-04-04 Samsung Electronics Co., Ltd. Platform for concurrent execution of GPU operations
US11561886B2 (en) * 2019-09-19 2023-01-24 Sap Se Open data protocol performance test automation intelligence (OPT-AI)
US11269879B2 (en) * 2020-01-13 2022-03-08 Google Llc Optimal query scheduling according to data freshness requirements

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7509646B1 (en) * 2003-09-23 2009-03-24 Unisys Corporation Method of managing workloads in a distributed processing system
US7426522B2 (en) * 2003-09-23 2008-09-16 International Business Machines Corporation Object oriented query path expression to relational outer join translator method, system, article of manufacture, and computer program product
US20080010642A1 (en) * 2006-06-30 2008-01-10 Maclellan Scot Method, system and computer program for scheduling execution of work units with monitoring of progress thereof
US7769938B2 (en) * 2007-09-06 2010-08-03 Intel Corporation Processor selection for an interrupt identifying a processor cluster
US8161035B2 (en) * 2009-06-04 2012-04-17 Oracle International Corporation Query optimization by specifying path-based predicate evaluation in a path-based query operator

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
US 7,509,646 B1,2009.03.24,全文.

Also Published As

Publication number Publication date
EP2259184B1 (en) 2012-01-25
EP2259184A2 (en) 2010-12-08
US8219546B2 (en) 2012-07-10
ATE543137T1 (de) 2012-02-15
EP2259184A3 (en) 2010-12-29
US20100312762A1 (en) 2010-12-09
CN101908003A (zh) 2010-12-08

Similar Documents

Publication Publication Date Title
CN101908003B (zh) 并行化查询的多核调度
CN109783237B (zh) 一种资源配置方法及装置
Chohan et al. See spot run: Using spot instances for {MapReduce} workflows
Dong et al. Scheduling algorithms for grid computing: State of the art and open problems
US8752059B2 (en) Computer data processing capacity planning using dependency relationships from a configuration management database
US20130290972A1 (en) Workload manager for mapreduce environments
US20140019987A1 (en) Scheduling map and reduce tasks for jobs execution according to performance goals
CN101719931A (zh) 一种基于多智能主体的层次式云端计算模型构建方法
US20060195336A1 (en) Methods and systems for dynamic parallel processing
He et al. QoS-aware service selection for customisable multi-tenant service-based systems: Maturity and approaches
Rauchecker et al. Using high performance computing for unrelated parallel machine scheduling with sequence-dependent setup times: Development and computational evaluation of a parallel branch-and-price algorithm
CN111459622A (zh) 调度虚拟cpu的方法、装置、计算机设备和存储介质
US20120059938A1 (en) Dimension-ordered application placement in a multiprocessor computer
EP2840513B1 (en) Dynamic task prioritization for in-memory databases
Davidović et al. Parallel local search to schedule communicating tasks on identical processors
Kandi et al. An integer linear-programming based resource allocation method for SQL-like queries in the cloud
Toporkov Job and application-level scheduling in distributed computing
Anta et al. Online parallel scheduling of non-uniform tasks: Trading failures for energy
Rumi et al. Optimization techniques within the hadoop eco-system: A survey
Capannini et al. A job scheduling framework for large computing farms
Yahyapour Design and evaluation of job scheduling strategies for grid computing
Li et al. Workflow scheduling algorithm based on control structure reduction in cloud environment
CN102063289B (zh) 串行程序线程级推测执行能力评估方法和评估器
Tiwari Scheduling and energy efficiency improvement techniques for Hadoop Map-reduce: State of art and directions for future research
Liu et al. FreeTrain: A Framework to Utilize Unused Supercomputer Nodes for Training Neural Networks

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C14 Grant of patent or utility model
GR01 Patent grant