CN101256516B - 网格环境中的数据分布和任务实例 - Google Patents

Abstract

分区分析器可以被配置为在网格网络的数据库中指定数据分区，并执行将数据分区映射到应用的任务，该应用将要被至少部分地在所述网格网络中执行。供应管理器可以被配置为确定任务的任务实例，并基于所述映射确定数据分区，其中该数据分区可以被存储在网格网络的初始节点。可以确定具有执行任务实例所需的处理资源的网格网络的处理节点以及具有存储数据分区所需的存储资源的网格网络的数据节点。任务实例可以被部署到处理节点，并且基于比较，数据分区可以被从初始节点重新定位到数据节点。

Description

网格环境中的数据分布和任务实例

技术领域

本发明涉及网格计算(grid computing)。 

背景技术

网格计算环境一般涉及分布的、网络化计算模型，其中多个计算机被用来协作地解决一个或多个问题。通常，要解决的这些问题是计算密集型的(computationally intensive)，并且在传统计算界需要大量和昂贵的资源来完成。例如，诸如气象模式(weather pattern)或金融市场的建模问题可以利用网格计算来解决，其中这样的问题使用单个计算机来解决则是困难和昂贵的。因此，网格计算可以提供节省成本、可靠的方式来解决计算密集型问题。 

与这样的计算密集型软件应用相比，许多软件应用可以替代为(或者附加为)数据库密集型的。也就是，这样的应用会需要大量和/或频繁地调用(例如，查询)数据库。例如，在企业上下文(context)中，通常会出现这样一种情况，即企业维护大型的中心数据库，该数据库可以存储例如与客户、雇员相关的大量数据、过程、或者其它业务相关数据。因此，数据库密集型应用可以访问中心数据库以执行相关联的功能，比如生成客户报告、或处理企业的工资单。因而很难在网格计算环境中实现这样的数据库密集型应用，因为如在网格计算模型中那样，使用分布式计算资源的好处可能会被在那个上下文中访问所需数据而需要的时间和资源而减少或削弱(outweighed)。 

发明内容

根据一个总体方面，一种用于网格计算的系统包括：分区(partition)分析器，被配置为在网格网络的数据库中指定至少一个数据分区，其中，从有利于更少或不频繁使用的数据的角度，所述分区分析器权衡将所述数据包括在至少一个数据分区的每次转移中的成本，以便为供应管理器的使用而最优化所述数据库的数据分区，并且，该分区分析器进一步被配置为执行将数据分区映射到应用的至少一个任务，该应用将要被至少部分地在所述网格网络 中执行。该系统还包括供应(provisioning)管理器，被配置为：确定所述至少一个任务的任务实例；基于所述映射并且与所述任务实例的执行相关联地确定所述数据分区，以便预先得知数据分区包括该任务实例将最频繁和/或最可能调用的数据，该数据分区被存储在所述网格网络的初始节点；确定具有执行所述任务实例所需的处理资源的网格网络的处理节点以及具有存储所述数据分区所需的存储资源(memory resources)的网格网络的数据节点，该确定是基于处理节点和数据节点之间的等待时间(latency)而进行的；对于利用在数据节点的数据分区的任务实例的执行时间是否少于利用保留在初始节点的数据分区的任务实例的默认执行时间来进行比较；将所述任务实例部署(deploy)到所述处理节点；以及如果所述比较结果显示利用在数据节点的数据分区的任务实例的执行时间少于利用保留在初始节点的数据分区的任务实例的默认执行时间，则将所述数据分区从所述初始节点转移到所述数据节点。 

根据另一个总体方面，确定要执行的任务实例，并且可以确定与任务实例的执行相关联、并存储在网格网络的初始节点的数据分区。可以确定具有执行任务实例所需的处理资源的网格网络的处理节点以及具有存储数据分区所需的存储资源的网格网络的数据节点这两种节点，该确定是基于处理节点和数据节点之间的等待时间而进行的。对于利用数据节点的数据分区的任务实例的执行时间是否少于利用保留在初始节点的数据分区的任务实例的默认执行时间来进行比较。任务实例可以被部署到处理节点，并且基于所述比较将数据分区从初始节点重新定位到数据节点。 

根据另一个总体方面，计算机程序产品可以有形地体现在计算机可读介质上，并且可以包括可执行代码。所述可执行代码在被执行时可以被配置为使得数据处理装置接收要在网格网络上执行的任务实例，该任务实例从应用的任务来实例化(instantiate)。所述可执行代码在被执行时可以被配置为使得数据处理装置基于任务实例来从与应用相关联的数据库确定数据分区，该数据分区与所述任务相关联、并存储在网格网络的初始节点。所述可执行代码在被执行时可以被配置为使得数据处理装置确定具有足够处理资源来执行任务实例的网格网络的处理节点，并且确定具有足够存储资源来存储数据分区的网格网络的数据节点。所述可执行代码在被执行时可以被配置为使得数据处理装置确定在具有从初始节点转移到数据节点的数据分区的处理节点的任 务实例的执行时间少于在具有保留在初始节点的数据分区的处理节点的任务实例的执行时间。所述可执行代码在被执行时可以被配置为使得数据处理装置将任务实例部署到处理节点，并将数据分区从初始节点转移到数据节点。 

根据另一个总体方面，一种用于网格计算的方法包括：通过分区分析器在网格网络的数据库中指定至少一个数据分区，其中，从有利于更少或不频繁使用的数据的角度，所述分区分析器权衡将所述数据包括在至少一个数据分区的每次转移中的成本，以便为供应管理器的使用而最优化所述数据库的数据分区，并且，该分区分析器还被配置为执行将数据分区映射到应用的至少一个任务，该应用将要被至少部分地在所述网格网络中执行；通过所述供应管理器确定将要执行的任务实例；基于所述映射并且与所述任务实例的执行相关联地确定数据分区，以便预先得知数据分区包括该任务实例将最频繁和/或最可能调用的数据，该数据分区被存储在所述网格网络的初始节点；确定具有执行所述任务实例所需的处理资源的网格网络的处理节点和具有存储所述数据分区所需的存储资源的网格网络的数据节点，该确定是基于处理节点和数据节点之间的等待时间而进行的；对于利用在所述数据节点的数据分区的任务实例的执行时间是否少于利用保留在所述初始节点的数据分区的任务实例的默认执行时间来进行比较；将所述任务实例部署到所述处理节点；以及如果比较结果显示利用在所述数据节点的数据分区的任务实例的执行时间少于利用保留在所述初始节点的数据分区的任务实例的默认执行时间，则将所述数据分区从所述初始节点转移到所述数据节点。 

根据另一个总体方面，一种用于网格计算的装置包括：分区分析器，用于在网格网络的数据库中指定至少一个数据分区，其中，从有利于更少或不频繁使用的数据的角度，所述分区分析器权衡将所述数据包括在至少一个数据分区的每次转移中的成本，以便为供应管理器的使用而最优化所述数据库的数据分区，并且，该分区分析器还被配置为执行将数据分区映射到应用的至少一个任务，该应用将要被至少部分地在所述网格网络中执行；所述供应管理器，用于确定将要执行的任务实例；用于基于所述映射并且与所述任务实例的执行相关联地确定数据分区，以便预先得知数据分区包括该任务实例将最频繁和/或最可能调用的数据的装置，该数据分区被存储在所述网格网络的初始节点；用于确定具有执行所述任务实例所需的处理资源的网格网络的处理节点和具有存储所述数据分区所需的存储资源的网格网络的数据节点的装置，该确定是基于处理节点和数据节点之间的等待时间而进行的；用于对于利用在所述数据节点的数据分区的任务实例的执行时间是否少于利用保留在所述初始节点的数据分区的任务实例的默认执行时间来进行比较的装置；用于将所述任务实例部署到所述处理节点的装置；以及用于如果所述比较结果显示利用在所述数据节点的数据分区的任务实例的执行时间少于利用保留在所述初始节点的数据分区的任务实例的默认执行时间，则将所述数据分区从所述初始节点转移到所述数据节点的装置。 

在附图和以下描述中陈述了一个或多个实施方式的细节。其它特征从说明书、附图以及权利要求书中将变得更清楚。 

附图说明

图1是用于在网格环境中分布数据和任务实例的系统的框图。 

图2是说明图1的系统的示例实施方式的框图。 

图3是说明图1和图2的系统的示例操作的流程图。 

图4是图1和图2的系统的分区分析器的框图。 

图5是说明图4的分区分析器的示例操作的流程图。 

图6是图1和图2的供应管理器的框图。 

图7是示出图6的系统的示例操作的流程图。 

具体实施方式

图1是系统100的框图，该系统100用于在网格环境中分布数据和任务实例，由此允许数据库密集型的应用得益于图1的网格环境，例如，得益于与网格环境相关联的增加的处理资源、增加的可靠性、以及降低的成本。更具体地讲，例如通过在网格环境中提供数据库密集型应用的任务实例和相应数据这两者，这样的数据库密集型应用可以获得上述的益处，其中在本上下文中相应数据是指已经被指定为对相关任务非常有用的数据。这样的任务实例和相应数据可以在网格环境中提供，从而最小化任务实例对相应数据的数据调用的等待时间(以及所调用数据回到任务实例的相应返回)。通过最小化该等待时间，可以最优化和/或改善数据库密集型应用的总体执行时间，同时还能够获得图1的网格环境的上面所述的益处。 

在图1的系统100中，网格环境或网格网络包括中心节点102和多个节 点104a、104b。在这点上，应当认为中心节点102和/或节点104a、104b是指网格网络的设备的硬件和/或软件(例如，虚拟(virtual))实施方式。例如，中心节点102可以指存储大量数据的计算设备，比如，当一个全球化企业将一个或多个大型数据库存储在企业的公司总部。同时，节点104a、104b代表可以连接到中心节点102的任意数量的节点，并且例如可以指实际上具有足够处理和/或存储能力来执行这里描述的操作的任何计算设备。例如，中心节点102和/或节点104a、104b可以包括膝上型计算机或其它个人计算机，或者可以包括企业服务器或其它潜在的资源充足的计算设备(或与这些服务器或计算设备相关联)，这将会很清楚。 

在图1的示例中，网格中间件106被示出为指代帮助图1的系统100的网格环境的实施和操作的软件。例如，网格中间件106可以被用来在网格环境中部署(deploy)/转移(transfer)任务实例，并且一般来讲，可以被用来帮助和适应各种不同的应用、协议、平台、操作系统、体系结构、或涉及图1的网格环境的其它参数的使用。类似地，网格中间件106可以被用来同步或协调节点104a、104b(以及图1中未示出的其它节点)的操作。因此，网格计算的一个特征在于从潜在的异类(heterogeneous)环境中获得基本同类的(homogeneous)结果，并且该网格中间件106可以是获得这个结果的工具。 

另外在图1中，上述数据库密集型应用的示例被示出为业务应用108。在这一点上，术语业务应用应当被宽泛地解释为事实上包括可以用在一些类别的利润生成中的任何应用，尽管业务应用108还指非营利的机构努力，例如包括学校、政府、教会、慈善团体、医院、或者事实上任何其它组织。而且，业务应用108仅仅是一个示例，其它的应用也可以被使用，比如为个人使用的应用。 

如这里所述的，业务应用108可以执行访问相关数据的所需要的各种功能，以便完成所讨论的功能的执行。仅仅作为示例，然后，业务应用108被示出为包括查询生成器110和报告管理器112。例如，在工资单示例中，企业可以使用查询生成器110查询相关数据以确定由于一个或多个雇员的当前工资或薪水。作为另一个示例，报告管理器112可以被用来生成关于各种业务方面的报告，例如包括，当前库存量、或往来账户可付/可收信息。 

这种应用特定的功能可以被称为任务(task)，其可以被存储在任务储存库114中。一般而言，这样的任务可以代表可重复使用的、先前测试的组件 或对象，其实例可以被单独地或共同地用来获得期望的结果。例如，业务应用108可以提供事实上可以由应用通过网络提供的任何功能，例如包括，提供股票报价、提供航线或其它预约、提供购买/发票功能、或提供一些方面的供货链管理或库存控制。 

在一些示例中，任务储存库114的任务可以包括将要执行的任务，以及作为这些任务的一部分的可以被发送/接收的消息。这样的任务可以被结合和排序(ordered)以获得期望的结果，比如在处理模型中，其中，如已知的，为了容易地理解和操纵，这样的任务可以被图形化地表现在图形用户界面上。在这些上下文中，任务可以通过适当的边(edges)(箭头)和控制任务(例如，拆分和/或合并)来结合，以获得包括平行任务、迭代任务、嵌套循环、或其它已知任务进程的结构。 

可附加地，或者可替换地，使用应用服务(例如，作为面向服务的体系结构(SOA)的一部分)，业务应用108的任务可以至少部分地被执行。这样的应用服务可以指具有通常通过服务接口方式(其中，接口的操作和使用可以是已知的或按照需要来确定的)经网络(例如，因特网)暴露给(exposeto)其它应用的一个或多个特定功能的应用。如果这样的服务(和/或服务的接口)被通过万维网络(这里也称为WWW或web)暴露/可用，那么供应服务可以被称为web服务。 

例如，存在各种语言，比如说业务过程执行语言(Business Process Execution Language，BPEL)，其被设计来提供这种服务(例如，web服务)的组合，从而其可以为SOA提供自上而下的、面向过程的方案。相应地，BPEL或其它这样的语言(比如，网络服务流语言(WSFL)、可扩充语言(XLANG)、和/或业务流程建模语言(BPML))、或它们的修改/扩展可以被用来定义、协调、和/或部署任务储存库114的任务。 

因此，任务储存库114的任务代表具有特定功能的一般组件(generic components)，并且所述任务可以被实例化以执行业务应用108的特定实施方式。例如，业务应用108可以包括用于计算企业工资单的任务，其中这样的任务可以包括确定当前雇员、确定企业的当前薪资结构、以及确定各个雇员的各种情况(例如，工作小时数、或所用病假天数)的效果(如果有的话)。当然，这些仅仅是示例，应当理解，对于每月工资单处理来说，对于一年的每个月可以创建这些任务的不同实例，并且任务的“一月份”实例可以不同 于任务的“二月份”实例，因为月与月之间的各种参数会发生变化(例如，月份的天数或假日天数、在给定月份中应用的奖金数量(例如，年终奖金)、或其它工资单相关的变量)。 

然后，在操作中，业务应用108可以希望以分布方式来执行这样的工资单处理、或其它功能。例如，节点104a可以位于纽约，而节点104b可以位于伦敦，其中，节点位置可以对应于所讨论的企业的运作中心。在这种情况下，业务应用108可以使用网格中间件106和中心节点102来分布、部署、提供、或将任务实例116提供给节点104b，以由节点104b执行。当然，应当理解，可能需要将大量任务实例部署到多个节点，并且在图1中示出的单个任务实例116仅仅是为了说明而已。 

如上所述，通过杠杆调节(leveraging)节点104b的可用计算资源，这样的将任务实例116分布到节点104b可以作为整体改善任务实例116和应用108的总体可靠性和执行时间。但是，如上所述，由于任务实例116在执行期间会需要访问(例如，进行数据调用)中心节点102的中心数据库118这样的事实，上述的优点可能被削弱(也可能不被削弱)。 

例如，并且继续上面提供的工资单示例，中心数据库118可以包括企业的当前雇员列表，以及其它工资单相关的数据。因此，任务实例116可能需要对中心数据库118进行查询或其它数据调用，以便执行其相关联的工资单计算。但是，在例如节点104b位于远离中心节点102的情况下(比如当节点104b位于伦敦而中心节点102位于Walldorf(沃尔多夫)时)，会存在与任务实例116的每个这样的调用相关联的值得关注的(non-trivial)等待时间。根据例如等待时间的大小和/或数据调用的质量或频率，所导致的任务实例116的执行时间中的增加会削弱早先将任务实例116部署到节点104b的计算优势。 

在图1的示例中，中心节点102包括分布系统120，该分布系统120被配置为通过连同任务实例116部署数据分区122a来考虑到上述情况。更具体地讲，分布系统120可以被配置为将中心数据库118的数据划分为两个或多个这样的数据分区，其中这样的数据分区可以包括单独地联合、但是相互分离的连贯(coherent)数据组，所以不需要进行同步以保证它们之间的一致性。例如，数据分区122a可以包括与伦敦的雇员相关联的数据块，该数据块与和纽约的雇员相关联的类似数据分区(图1中未示出)相分离(这里，例如，在伦敦雇用雇员和对数据分区122a的相应更新不需要与纽约的雇员相关联的 相应数据分区进行同步)。 

如以下更详细地描述的，分布系统120可以基于任务实例116自身的任务从中心数据库118的数据内部划分或确定数据分区122a，因此能预先得知数据分区122a包括任务实例116最频繁和/或最可能被调用的数据。以此方式，来自任务实例116的大多数或全部数据调用将针对数据分区122a，以致例如如果任务实例116和数据分区122a两者被一起部署到节点104b，则与任务实例116的数据调用相关联的等待时间可以被显著地缩短或有效地消除，这可以导致任务实例116(和应用108作为一个整体)的总体执行时间的相应减少。 

在从/对中心数据库118分割(partitioning)、部署、转移、和/或重新结合数据分区122a时，可以使用联合数据库管理系统(FDBMS)124a、124b、124c。如所示，FDBMS 124a、124b和124c可以分别在中心节点102、节点104a、以及节点104b的每一个上执行。这样的系统可以被用来从多个分布的数据库形成虚拟、联合的数据库，以便可以向访问联合数据的人员或机器用户展现单一、统一的接口。例如，传统存储网格可以被使用，所述传统存储网格可以实施这样的数据库的联合以利用分布的存储资源和要求，以便上述计算网格可以被用来利用分布的处理资源和要求。作为这样的传统存储网格的一部分，联合数据库管理系统可以被用来在节点之间转移单独的数据库，其原因在于比如给定节点的当前不可靠性或故障，或者因为其它已知原因。 

但是，在图1的示例中，FDBMS 124a、124b、124c可以被分布系统120使用，以帮助数据分区122a的分区和部署。也就是，虽然FDBMS 124a、124b、124c可以如上所述被用来为分布数据提供单一接口，但是从本说明中还应当理解，FDBMS 124a、124b和124c可以被附加地或替换地用作更大过程的一部分，用来在图1的网格环境中创建、分布、部署、转移或提供数据分区122a，例如，在分布系统120的方向。 

这样，任务实例116可以在服务器126b上执行(可以在节点104b以硬件或软件来实施)，而数据分区122a可以被存储在本地节点104b的本地数据库128b(例如，可以使用任何标准的存储技术来实施)。因此，如这里所述，任务实例116可以在与对数据分区122a的所需数据调用相关联的最小等待时间内执行(在本示例中是因为任务实例116和节点104b的数据分区122a处于同一地点)。 

如上所述，以及以下参考图4和图5所更详细地描述的，分布系统120可以包括分区分析器130。分区分析器130可以被配置为分析任务储存库114的任务、中心数据库118的内容和结构、以及各种其它相关因素，并且可以在其后划分中心数据库118的数据以包括数据分区122a(以及图1未示出的其它可能部分)。例如，使用上述工资单示例，分区分析器130可以被配置为分析任务，任务实例116从该任务实例化，该分区分析器130还被配置为确定所述任务高度专用于(highly-specific to)特定地理区域或地点(例如，可以与在指定区域/地点的雇员组的数据相关联)。因此，分区分析器130可以将中心数据库拆分成数据分区122a(与基于伦敦的工资单操作相关联)，以及拆分成与其它区域/地点相关联的其它数据分区。 

其后，映射数据库132可以被用来存储所确定的任务和数据分区之间的关系。例如，如图4所示，一个或多个任务可以被映射到单一的数据分区(例如，数据分区122a)。例如，如上所述，可以有与执行每月工资单处理相关联的多个工资单相关任务，并且多数或全部这些任务可以被映射到相应的、地理限定的数据分区。因此，会存在数据分区和任务实例之间的1∶n映射。 

在业务应用108的运行期间，例如，在当前月末工资单处理开始时，分布系统120的供应管理器134可以被配置为将任务实例116以及任务储存库114的任务的相关任务实例部署到网格环境的一个或多个节点104a、104b。如这里所述的，供应管理器134还可以被配置为确定是否以及如何在图1的网格环境中部署(例如，转移)数据分区122a。 

以下对于图6给出供应管理器135的更具体的示例，并对于图7给出供应管理器134的操作示例。但是，应当理解，通常来说供应管理器134被配置为确定许多因素以决定是否以及如何部署任务实例116和数据分区122a。例如，供应管理器134可以确定在网格环境的节点104a、104b的每一个节点的当前可用的计算和存储资源。而且，供应管理器134可以确定与一对或多对节点104a、104b(以及其它未示出的节点)相关联的等待时间。然后，供应管理器134可以对是否应当部署以及如何部署数据分区122a以便改善任务实例116的执行时间进行确定。 

例如，如以下对于图2所描述的，可能发生的情况是数据分区122a最初位于中心数据库118中的中心节点102。在这种情况下，供应管理器134可以确定将数据分区122a转移到节点104b所需的时间足够长，例如，相对于 任务实例116的处理时间或复杂性，因而将数据分区122a转移到节点104b将不会导致任务实例116的执行时间的净减少或可感知的减少。换句话说，供应管理器134可以确定通过将任务实例116部署到节点104b以用于随后从该节点到中心数据库118的调用、比通过花费时间将数据分区122a从中心数据库118转移和部署到节点104b的本地数据库128b可以更快地完成任务实例116。 

虽然如此，但在这种情形，可能发生的情况是，如数据分区122a的虚线所示，供应管理器134可以确定数据分区122a可以被部署到节点104a的本地数据库128a。换句话说，与将数据分区122a留在中心数据库118以便用于从所部署的任务实例116调用到其中相比，将任务实例116和数据分区122a两者均部署到网格环境会更有利，即使任务实例116和数据分区122a没有被部署到网格环境的同一节点上。例如，可能发生的情况是，节点104a(与上述纽约示例形成对比)还可以被定位在伦敦，所以与节点104a、104b中的任何一个和中心数据库118(例如，在Walldorf)之间的等待时间相比，在节点104a、104b之间的等待时间相对较短。 

在最后示例的情形中，对其也在以下对于图2更详细示出和讨论，在开始部署任务实例116时可能发生的情况是，数据分区122可能已经位于节点104b的本地数据库128b。在这种情况下，供应管理器134可以确定最好将数据分区122a留在节点104b，以及可以将任务实例116部署到节点104b，以便得到在这种情形下任务实例116的数据调用所经历的最小等待时间的优点。 

这里提供了各种其它示例，应当理解也可以实施没有被具体讨论或示出的许多修改。例如，虽然示出为业务应用108与中心节点102相分离，业务应用108可以被部署到中心节点102上。在其它示例中，应当理解不同的技术术语可以与这里所描述的相同或相似的概念相关联。例如，术语“任务实例”可以用术语“工作”来替代，或实际上是可互换的。其它变化和修改也可以很清楚。 

图2是示出图1的系统的示例实施方式的框图。在图2中，假设在部署或分布处理的开始时，中心节点102与要部署的任务实例116a、116b以及数据分区122a相关联。在第一种情形下，然后可能发生的情况是，基于例如由分布系统120作出的节点104c包括足够处理资源以执行任务实例的确定，任 务实例116a将被部署到节点104c。为了示出在这个示例中节点104c基于其处理能力被选择来处理任务实例116a，该节点104c在图2中被称为“处理”节点。 

类似地，可以确定节点104d可以被分布系统120确定为具有足够存储资源来存储数据分区122a。为了示出在这个示例中节点104d基于其存储能力被选择来存储数据分区122a，该节点104d在图2中被称为“数据”节点。有些类似地，中心节点102可以被称为“初始节点”，因为数据分区122a最初位于该中心节点102。 

而且，如这里详细描述的，与数据分区122a简单地保留在中心数据库118的基线情况相比，可以确定将数据分区122a转移到数据节点104d可以减少任务实例116a的总体执行时间。换句话说，可以对以下两种情形进行比较，在第一种情形中，任务实例116a被部署到处理节点104c并通过调用中心数据库118中的数据分区122a来执行，在第二种情形中，任务实例116a被部署到处理节点104c并通过调用数据节点104d中的数据分区122a来执行。第一种情形和第二种情形中无论哪一个能够减少执行时间，则可以被选择和执行。 

以下将更详细地讨论用于在这两个情形、以及其它情形之间进行决定的各种示例算法和参数。但是，一般应当理解，通过将数据分区节点122a部署到数据节点104d，在处理节点104c和数据节点104d之间的较低的等待时间可以导致会降低任务实例116a的执行时间的更大可能性。当任务实例116a和数据分区122a两者均被部署到同一节点时，可以得到最小量的等待时间，以致实际等待时间可以接近于零。因此，应当认识到有关“处理节点”和“数据节点”的命名仅仅是为了如这里(例如，在图1中)所详细描述的那样示出不同节点104c、104d的可能的功能，也会出现单一节点(例如，节点104b)被操作作为处理节点和数据节点这两者，这样，如刚刚所述的，从任务实例116a到数据分区122a的调用的有效等待时间可以接近于零。 

继续图2中数据分区122a被部署到数据节点104d的示例，稍后可能会发生任务实例116b被从中心节点102部署/通过中心节点102部署。在图2的示例中，示出了任务实例116b被部署到节点104f。例如，任务实例116b可能需要比当前在节点104c可用的处理资源更大的处理资源，所以节点104c不适于接收任务实例116b。 

在这种情况下，分布系统120再次对如何达成任务实例116b的最小执行时间进行确定。例如，任务实例116b可以简单地从节点104f向数据节点104d中的数据分区122a进行数据调用。当然，会有与每一次这样的调用相关联的相关等待时间，但是尽管如此，通过将接收任务实例116b的节点选择到尽量接近数据节点104d可以最小化任务实例116b的总体执行时间(或者在对数据节点104d的调用中体验最小化的等待时间)。 

但是，在其它示例的实施方式中，通过将数据分区122a从数据节点104d转移到节点104f可以减少任务实例116b的执行时间。在这样的示例中，然后，节点104b可以被认为是“初始节点”，因为数据分区122a为了(可能的)所讨论的转移的目的而首先位于那里。在这个示例中，然后，如图2所示，节点104f可以用作处理节点和数据节点两者。再一次，这样的结果可以最小化或消除与从任务实例116b到数据分区122a的调用相关联的等待时间。 

在最后的示例中，可能出现数据分区122a不转移到节点104f，比如在节点104f当前没有足够的存储资源以存储数据分区122a。在这个示例中，数据分区122a可以替代被转移到节点104e，于是节点104e被用作对“处理节点”104f的“数据节点”。再次，为了使这样的转移更理想，假设与当任务实例116b对数据/初始节点104d进行数据调用时相比较，当任务实例116b调用数据节点104e时，由任务实例116b所经历的等待时间(和/或执行时间)将减少/改善。 

图3是示出图1和图2的系统的示例操作的流程图300。在图3的示例中，可以确定将要执行的任务实例(302)。例如，供应管理器134可以从业务应用108接收通知，其通知任务储存库114的任务已经被实例化为用于执行的任务实例116a(或116b)。 

然后，确定与任务实例的执行相关联并存储在网格网络的初始节点的数据分区(304)。例如，供应管理器134可以访问映射数据库132以确定数据分区122a已经被映射到任务，从该任务实例化任务实例116a(和/或116b)。在本示例中，假设分区分析器130先前分割中心数据库118、如上所述映射数据分区122a、并将结果存储在映射数据库132用于被供应管理器134访问。从上述图2的讨论中可以理解，在这个上下文中初始节点可以指中心节点102，或节点104a-104f中的任何一个，在图3的流程图300的操作的开头，数据分区122a被存储在初始节点。 

可以确定具有执行任务实例所需的处理资源的网格网络的处理节点，并且类似地，还可以确定具有存储数据分区所需的存储资源的网格网络的数据节点，其中这样的确定可以基于处理节点和数据节点之间的等待时间来进行(306)。例如，供应管理器134可以确定具有当前可用来执行任务实例116a的足够的处理资源的第一多个节点，比如节点104b/104c，以潜在地接收任务实例116a。或者，在图2的其它示例中，供应管理器134可以确定节点104f具有用于执行任务实例116b的足够的处理资源。类似地，供应管理器134可以确定具有存储数据分区122a所需的足够的存储资源的第二多个节点。例如，供应管理器134可以如刚刚所述的根据所讨论的任务实例来选择数据节点104b、或104d-104f等中的任何一个。 

然后，如这里更详细描述的，可以检查第一多个节点和第二多个节点的节点的不同组合来确定节点之间的等待时间，并且基于所确定的等待时间中的最小等待时间来选择处理节点(例如，104b、104c、或104f之一)和数据节点(例如，104a、104b、或104d-104f之一)。例如，参考图2，如果供应管理器134确定第一多个潜在的处理节点包括节点104c和104f，然后确定第二多个潜在的数据节点包括节点104d和104f，则节点104f可以被选择作为处理节点和数据节点这两者(因为，在这个示例中，节点104f被包括在这两组节点中，并且因为用于在单一节点在任务实例和数据分区之间的通信的等待时间一般被假设为效果上(effectively)为零)。 

对利用数据节点的数据分区的任务实例的执行时间是否少于利用保留在初始节点的数据分区的任务实例的默认执行时间进行比较(308)。例如，在图1中，节点104b可以用作处理节点和数据节点这两者。然后，在初始节点是中心节点102的情况下，供应管理器134可以确定任务实例116在处理/数据节点104b的执行时间(该执行时间包括将数据分区122a从中心数据库118转移到本地数据库128b所需的转移时间)总体上少于简单地将数据分区122a留在中心数据库118中的默认执行时间(在这种情况下，例如，任务实例116可以被部署到处理/数据节点104b，并且根据需要任务实例116可以通过对中心节点102进行数据调用来执行)。当然，在其它示例中，初始节点可以是除了中心节点之外的其它节点，比如在上面图2的例子中，其中在一个示例中将节点104d用作初始节点。而且，例如以下对于公式(1-14)所讨论的，作为总体执行时间或总体默认执行时间的一部分，可以包括附加的或替换的 参数。 

然后，任务实例可以被部署到处理节点(310)，比如以上面刚刚所述的以及如在图1中示出的，当供应管理器134将任务实例116部署到节点104b时进行。在这里所描述的示例实施方式中，应当理解，假设中心节点102被用作用于部署任务实例到网格环境的中心部署点，并且典型地其自身并不执行任务实例。但是，在一些示例实施方式中，有可能用于部署任务实例的节点自身也能够在需要或期望时执行任务实例。 

数据分区可以基于比较而从初始节点重新定位到数据节点(312)。例如，继续上面所述的示例，如果供应管理器134对于其中将数据分区122a留在中心节点102的中心数据库118(并从节点104b的任务实例116接收调用)的默认执行时间与由执行将数据分区122a转移到节点104b的本地数据库128b所产生的执行时间之间进行比较。然后，例如，在所述执行时间少于默认执行时间的情况下，则供应管理器134可以使用联合数据库管理系统124a、124b将数据分区122a转移到节点104b。 

图4是图1和图2的系统的分区分析器130的框图。在图4的示例中，中心数据库118被示出为包含数据302-314。而且，任务316a、316b和316c被示出并应当理解为被存储在图1的任务储存库114中，并且被用来执行业务应用108。然后，在操作期间，分区分析器130可以设法分析任务316a、316b和316c以确定任务316a、316b和316c对数据302-314的访问特性，并因此分割中心数据库118。 

在图4的一般示例中，可能发生的情况是，任务316a独占地访问数据302、304、306，而任务316b可以访问数据302、304、306和308。同时，任务316c通常可以访问数据312和314。在该示例中，任务316a、316b、316c中没有一个被期望访问数据310。 

因此，分区分析器130可以将数据分区122a形成为包括数据302、304和306。因此，可以认为任务316a独占地访问数据分区122a。同时，可以认为任务316b主要地或频繁地访问数据分区122a(但是有时候或不频繁地访问数据308)。同时，分区分析器130可以确定任务316c独占地访问包括数据312和314的数据分区122b。 

因此，从上面图1到图3的描述中应当理解，任务316a的示例和数据分区122a可以被一起部署例如到节点104b。在这种情况下，任务316a的示例 可以访问执行所需的所有数据，并且在这个示例中，这样的访问的等待时间可以在效果上为零。因此，图1和图2的网格计算环境可以被有利地利用，而没有大量或频繁的对中心数据库118的数据调用的有害效果，以减慢任务316a的任务实例的执行时间。 

尽管在给定实施方式中最有利的情况是全部任务调用都针对单一数据分区(诸如任务316a对数据分区122a的调用以及任务316c对数据分区122b的调用的独占性质)，但是在只有任务的一部分数据调用是针对特定数据分区时，执行提供数据和任务实例也是有利的。例如，任务316b的数据调用318a和318b被示出为针对数据分区122a进行，而数据调用318c是针对数据308，该数据308没有被包括在任何数据分区中，因此可以不从中心数据库118中移出(或者如果发生移动的话，也可以独自移动)。 

因此，如果任务316b的任务实例与数据分区122a一起被部署到节点104b，则可以改善任务316的任务实例的总体执行时间。这是因为任务实例的数据调用中的大多数或许多是针对可本地访问的(本地数据库128b中的)数据分区122a进行的，尽管至少一些数据调用(例如，数据调用318c)可能必须针对中心数据库118进行。 

当然，在替代的示例实施方式中，分区分析器130可以定义数据分区122a包括全部数据302-308。但是，在这种情况下，无论何时当数据分区122a被存储在所讨论的网格网络的节点时，更多的数据将必须被转移。但是，如果对数据308的数据调用318c非常不频繁或非常少，则这样的附加的数据转移将是无保证的或有害的。换句话说，为了只是很少或不频繁的使用数据308的益处，将数据308包括在数据分区122a的每次转移中会带来成本问题。因此，分区分析器130可以负责权衡这些和其它成本和益处，以便为供应管理器134的使用而最优化中心数据库118的分区。 

一旦进行了分区或结合，分区分析器130可以在映射数据库132中存储作为结果的任务316a、316b和316c和数据分区122a和122b的关联或映射。如所示出的，由于多个任务(例如，任务316a和316b)可被映射到单一的数据分区(例如，数据分区122a)，这样的映射在任务：分区之间可以是n∶1的关系。 

图5是示出图1和图4的分区分析器130的示例操作的流程图500。在图5的示例中，可以对中心数据库118进行与应用无关的 (application-independent)分区(502)。例如，分区分析器130可以执行中心数据库118的初始分区，该分区部分地或完全地无关于业务应用108(例如，其可以应用于多个这样的业务应用)。例如，如以上所述，节点104a和104b可以与所讨论的企业的纽约和伦敦办公区相关联。在这种情况下，对于许多业务应用，分区分析器130可以执行将中心数据库118初始分区到地点特定或办公区特定的分区是合理的。 

然后可以确定与应用相关联的任务(504)。例如，分区分析器130可以确定任务316a、316b和316c与所讨论的应用相关联，例如，应用108。 

然后可以确定与每个任务相关联的数据(506)。例如，分区分析器130可以确定任务316a与数据302-306相关联，任务316b与数据308相关联，而任务316c与数据312、314相关联。 

可以确定每个任务进行数据访问的频率、大小、和/或模式，或者任何其它相关访问特性(508)。例如，分区分析器130可以确定任务316a独占地访问图4中的数据分区122a，并且可以确定任务316b频繁地、但不是独占地访问数据分区122a(但也访问数据308)。如上所述的，在特征化任务的数据访问时，由特定任务调用的数据的平均大小可能超过数据调用的绝对数量的重要性。也就是，如果任务316访问数据308很少次数，但是每次访问都是对于大量数据的访问，则任务316对数据308的访问比任务316对数据分区122a的访问对于任务316的任务实例的执行时间会产生更大的影响。 

如上面刚刚所述的，例如根据数据访问的频率、大小、或访问模式，数据可以被划分为由任务所访问的分区(510)。例如，如以上针对图4所描述和示出的，分区分析器130可以将数据库118的数据划分为数据分区122a和122b。 

可以确定并存储每个任务对所访问数据分区的映射(512)。例如，分区分析器130可以确定任务316a应当被映射到数据分区122a，同时任务316c应当被映射到数据分区122b。 

应当理解，图4和图5的技术可以定标到很大尺寸的数据组(datasets)。例如，如果中心数据库118的数据组增加，和/或如果任意特定数据分区122a、122b增加，则分区分析器130可以简单地增加数据分区的数量(并相应减小每个数据分区的大小)，并且可以相应更新映射数据库132。 

图6是图1和图2的供应管理器的框图。在图6的示例中，供应管理器 134包括通过网格中间件106从应用108接收任务实例的队列602。例如，应用108可以实施在每个月末或适当时候实例化各种任务的工资单处理方案用于发送到队列602。 

各种任务示例可以被排队并最终通过分配模块604。分配模块604可以接收任务实例，例如任务实例116a的通知，并且可以查找映射数据库132以确定相关联的数据分区，例如，数据分区122a。 

然后，分配模块可以查询资源管理器606以确定用于执行任务实例的计算网格的现有可用资源。如这里所述的，这样的资源可以包括可用节点的处理和/或存储资源(例如，每个节点的本地数据库的当前利用性)，以及网络或环境资源，比如带宽、访问质量(例如，成本或安全性)、或等待时间。一般来说，例如通过网格中间件106查询网格计算环境的适当节点或其它设备，可以实时或以接近实时的方式确定这样的参数的值。 

在其它示例实施方式中，这样的值可以提前确定，一次性或周期性地确定，并进行存储以用于以后访问。例如，在图6中，接口608可以被用来确定在网格计算环境中每对节点之间的等待时间值。正如刚刚所述的，这样的等待时间值可以根据需要确定，或以等待时间矩阵610或其它格式来存储。接口608可以被用来确定何时新的节点被注册到网格计算环境，或者何时当前节点被去除。然后等待时间值可以被相应更新。 

分配模块604从资源管理器606接收资源信息，并使用由资源管理器606提供的资源信息(包括例如等待时间信息)基于将要部署的任务实例和数据分区的特性实施一个或多个算法。虽然许多不同的算法都是可能的，这里提供了示例算法用于比较如果任务实例将要转移到处理节点(与将相关联的数据分区转移到数据节点一起，该数据节点可以与处理节点相同或不同)时用于所讨论的任务实例的执行时间与在数据分区保留在初始节点(例如，保留在中心节点102)同时如果任务实例被转移/部署时用于任务实例的默认执行时间。 

最后，分配模块604可以确定将任务实例部署到所选择的处理节点，以及确定是否以及在哪里部署相关联的数据分区。然后，任务实例和数据分区可以被识别为部署模块612，该部署模块612可以被用来将任务实例和数据分区两者提供到网格网络中所期望的节点上。当这样做时，应当理解，部署模块612可以与联合数据库管理系统124和/或网格中间件106的传统功能合 作工作。 

供应管理器134可以具有各种其它的能力和功能。例如，接口614可以代表与网格中间件106的外部接口，这允许在节点例如由于外部原因(例如，管理人的意愿、资源的重新分配、或者退役节点的故障)节点将要退役并从计算网格释放时调用(invocation)分配模块604。然后，供应管理器134可以将受到影响的任务实例和相关数据分区迁移到另一个节点。 

在这样做时，分配模块604可以例如通过使用来自资源管理器606的信息检测在目的节点上可用的资源。然后，分配模块604可以请求具有足够资源的节点“i”至少接受(host)数据分区，并且如果可能的话，还有一些或全部受影响的任务实例。如果将全部受影响的任务实例转移到节点“i”不可行，则分配模块604可以请求资源管理器606提供一组节点“j”，所述节点“j”按照节点“i”与每个节点“j”之间的等待时间量来排序，并能够接受剩余的任务实例。 

一旦适当的节点被定位，则可以停止在与要迁移的数据分区相关联的计算网格上的所有任务实例，然后分配模块604可以调用部署模块612将数据分区从要退役的节点转移到新选择的节点以及将任务实例从要退役的节点迁移到新选择的节点。最后，分配模块604可以检查与接受现在暂停的任务实例的所有其它节点相关的等待时间是否因为上述操作而发生了实质的增加。如果是，则使用与刚刚描述的选择相对于每个节点“j”与节点“i”之间的等待时间排序的一组节点“j”相同的技术来迁移(重新部署)任务实例。 

在另一个示例中，如果没有与一个数据分区相关联的任务实例是激活的，并且也没有安排好的任务实例是用于该相关数据分区的，则该数据分区可以被转移回到中心数据库118。将数据分区转移回到中心数据库118的请求可以使用分配模块604的对应接口614来发送。 

图7是示出图6的供应管理器的示例操作的流程图700。在图7的示例中，可以在队列602接收任务实例(702)，之后队列602可以通知分配模块604有关任务实例的到达(704)。分配模块604因此可以访问映射数据库132以确定哪个数据分区(如果有的话)与之相关联(706)(例如，与父类任务相关联，所述任务实例从该父类任务实例化)。 

或许使用资源管理器134的分配模块604可以确定相关数据分区的当前位置(708)，即，可以确定从其转移数据分区的初始节点。如上所述的，数 据分区可以被存储在中心数据库118，或事实上网格环境的节点之一的任意本地数据库(例如，作为早前执行的数据分区转移的结果)。 

然后，分配模块604可以使得资源管理器608确定具有足够处理资源的节点(710)，并且确定具有足够存储资源的节点(712)。作为结果的节点列表可以基于相关网格参数被过滤(714)。例如，这样的网格参数可以包括服务质量特性，所以如果节点不具有一些规定的服务质量阈值，则这些不适合的节点(otherwise-suitable)将从列表中去除。 

资源管理器608可以使用发现的或可用的网格环境中的节点对的等待时间信息，并可以将此等待时间信息用于潜在处理节点列表和潜在数据节点列表中的各种成员的配对。在有利的实施方式中，可能会出现潜在处理节点列表和潜在数据节点列表具有至少一个共同或重叠的节点，因此这个节点的节点内(intra-node)通信的等待时间可以忽略不计。如果没有，则资源管理器608可以确定具有最低等待时间的一对潜在处理节点和潜在数据节点(例如，互相最接近)。因此，资源管理器608可以确定具有最低等待时间的处理和/或数据节点(716)。 

一般来说，假设资源管理器608可以确定具有全部所需处理、存储、以及等待时间特性的单一节点或节点对，并因此可以将这个节点或节点对转移到分配模块604。当然在实践中可能会出现资源管理器608返回多个节点，每个节点可以被用作处理和数据节点这两者(并因此会具有可忽略不计的等待时间)。在这种情况下，资源管理器608可以使用一些其它标准来在这些节点之间进行决定，例如，可以选择第一个可用节点，或者最接近的节点，或者具有最高服务质量特性的节点。 

然后，分配模块604可以确定将数据分区从初始节点转移到所选择的数据节点(随着将任务实例部署到处理节点，该处理节点可以与数据节点相同或不相同)是否将改善任务实例的总体执行时间(718)。以下详细提供了用于进行这个确定的示例算法和计算。 

如果通过转移，执行时间将被改善，则任务实例和数据分区可以被部署模块612部署到以上确定的节点(对)(720)。否则，部署模块612可以只将任务实例部署到处理节点，而将数据分区留在其当前位置，即留在初始节点(722)。 

如上所述，分配模块604可以使用许多算法和计算来确定是否将数据分 区从初始节点转移到所选择的数据节点、与将任务实例部署到处理节点一起，将改善任务实例的总体执行时间。在以下陈述的示例算法中，使用了以下变量和符号。首先，节点使用“i”或“j”来标注，因此例如，在两个节点“i”和“j”之间的等待时间“1”可以被标为“l_ij”。类似地，在节点之间的网络带宽“b”可以被标为“b_ii”。 

没有专用于任何特定任务实例的变量，比如等待时间和带宽，可以被称为环境变量，而其它变量可以专用于一个或多个特定任务实例的执行。例如，用于任务实例执行的时间“t”，不考虑数据库访问时间的要求，可以被写作“t_exe”。 

在这个上下文中的任务实例可以被认为是提供用于执行任务实例的规范的二进制文件“bin”。类似地，数据分区可以被标为“part”。如上所述，任务实例的二进制文件“bin”和数据分区“part”这两者可以经历在节点“i”和“j”之间的转移，其中节点“i”可以包括中心节点，这是可以被标为节点“0”的特殊情况。 

然后，使用以上符号，从中心节点102转移和部署任务实例的二进制文件“bin”到节点“i”的时间可被写为“t_Tbin-i”。类似地，从中心节点102转移和部署数据分区“part”到节点“j”的时间可被写为“t_Tpart-j”。 

此外关于符号，特定数据库调用可以被表示为调用“k”，而任务实例所需的对相应数据库的许多数据库调用可以被写作许多调用“c”。文件的大小，无论是任务实例的二进制文件“bin”或者数据分区“part”(这也可以是一个二年进制文件)的大小，可以使用变量“s”来表示大小。执行从节点“i”到节点“j”的数据库调用“k”所需的时间可以被写作“t_call-kij”。 

使用上述符号，可以假设为了这些示例的目的，在节点i和j之间的网络连接具有与节点j和i之间的连接相同的行为。而且，假设用于内部通信的等待时间效果上为零。这些假设允许用于各种节点的对称等待时间和时间矩阵，即l_ij＝l_ji并且t_call-kij＝t_call-kji，并且如果i＝j，则l_ij＝l_ji＝0。在用于这些示例的最后一个假设中，可以假设在计算网格中两个不同节点之间的带宽在整个网格中是基本恒定的，并且在一个节点上的内部带宽是可以忽略不计地为高(negligibly high)，因此如果i＝j，则b_ij＝∞，否则b_ij＝b。 

使用上述符号，包括在节点i上部署任务实例以及将所需要的数据分区转移到节点j的整体执行时间“t”可以用公式1表现为： 

$t_{\mathrm{ij}}=\max (t_{\mathrm{Tbin}-i},t_{\mathrm{Tpart}-j})+t_{\mathrm{exe}}+\underset{k=l}{\overset{c}{\mathrm{\Σ}}}{t}_{\mathrm{call}-\mathrm{kij}}$

公式(1) 

公式1提供了许多时间分量的总和，这些时间分量可用于部署到节点“i”的任务实例的总体执行、以及将相关联的数据分区转移到节点“j”。 

第一时间分量涉及执行转移任务实例二进制文件“bin”和数据分区“part”所需的时间。具体来讲，“max(t_Tbin-i，t_Tpart-j)”项所考虑的是，由于任务实例的部署与数据分区的转移是独立进行的，因此对于总体执行时间t_ij的影响就仅仅依赖于两个时间中较大的一个(即最大值)。 

第二时间分量，从以上符号描述中可以看出，仅仅是执行任务实例的二进制文件所需的时间t_exe，而不考虑数据库访问的要求。最后，第三时间分量包括用于在节点“i”和“j”之间的所有数据库调用所需的时间的总和。 

公式(1)在具体示例的上下文中将被更好的理解。例如，如果分区未被转移，而是仅仅维持在中心节点102即节点0中，则可以在公式(1)中看到随后的结果。具体来讲，根据在这个示例中的定义，用于转移数据分区的时间是零秒，所以第一项“max(t_Tbin-i，t_Tpart-j)”可以简化为仅仅为“t_Tbin-i”，如公式2所示： 

$t_{i0}=\max (t_{\mathrm{Tbin}-i},t_{\mathrm{Tpart}-0})+t_{\mathrm{exe}}+\underset{k=l}{\overset{c}{\mathrm{\Σ}}}{t}_{\mathrm{call}-\mathrm{ki}0}$

$=t_{\mathrm{Tbin}-i}+t_{\mathrm{exe}}+\underset{k=l}{\overset{c}{\mathrm{\Σ}}}{t}_{\mathrm{call}-\mathrm{ki}0}$

公式(2) 

在公式(2)中，数据调用仍然出现在部署的任务实例(即，在处理节点“i”上)和在节点“0”的中心数据库118之间，如公式(2)的第三项所示。 

在另一个示例中，数据分区可以被转移到工作所部署的同一个节点i，即j＝i≠0。在这个示例中，以上关于在节点内数据调用所需的时间可以忽略不计的假设意味着第三项变为零秒，如公式(3)所示： 

$t_{\mathrm{ii}}=\max (t_{\mathrm{Tbin}-i},t_{\mathrm{Tpart}-i})+t_{\mathrm{exe}}+\underset{k=l}{\overset{c}{\mathrm{\Σ}}}{t}_{\mathrm{call}-\mathrm{kii}}$

$=\max (t_{\mathrm{Tbin}-i},t_{\mathrm{Tpart}-i})+t_{\mathrm{exe}}$

公式(3) 

使用公式(2)和公式(3)，可以比较在任务实例和数据分区被转移到节点“i＝j”时是否可以改善整体执行时间。换句话说，如果t_ii≤t_i0，则可以把转移相关联的数据分区(结合任务实例的部署)看作减少总体任务实例执行时间。这个不等式(以及所带来的去除公共项“t_exe”的简化)得到了公式(4)： 

t_ii≤t_i0

$\max (t_{\mathrm{Tbin}-i},t_{\mathrm{Tpart}-i})+t_{\mathrm{exe}}\≤t_{\mathrm{Tbin}-i}+t_{\mathrm{exe}}+\underset{k=l}{\overset{c}{\mathrm{\Σ}}}{t}_{\mathrm{call}-\mathrm{ki}0}$

$\max (t_{\mathrm{Tbin}-i},t_{\mathrm{Tpart}-i})\≤t_{\mathrm{Tbin}-i}+\underset{k=l}{\overset{c}{\mathrm{\Σ}}}{t}_{\mathrm{call}-\mathrm{ki}0}$

公式(4) 

如果为了示例的目的进一步假设部署任务实例至少花费了与转移数据分区一样长的时间，即，t_Tbin-i≥t_Tpart-i，则“max(t_Tbin-i，t_Tpart-i)”项变为只剩“t_Tbin-i”，从而产生公式(5)： 

$t_{\mathrm{Tbin}-i}\≤t_{\mathrm{Tbin}-i}+\underset{k=l}{\overset{c}{\mathrm{\Σ}}}{t}_{\mathrm{call}-\mathrm{ki}0}$

$0\≤\underset{k=l}{\overset{c}{\mathrm{\Σ}}}{t}_{\mathrm{call}-\mathrm{ki}0}$

公式(5) 

因此，公式(5)指出了一点，即如果部署任务的实例将至少花费与转移数据分区一样长的时间，则将数据分区转移到节点“i”就可以被认为是对总体执行时间的改善。这可以从以下事实中看出：如果数据分区转移可以在任务实例部署所需的时间内发生，则这在本质上没有花费或没有影响总体执行时间t_ii，因此应当进行数据分区的转移以便获得减少对数据分区进行数据调用所需时间的益处(即，与向中心数据库进行数据调用相反，在节点本身内进行数据调用)。 

但是，在相反的情况下，即转移数据分区的时间比部署任务实例所需的时间长时，其结果如公式(6)所示： 

$t_{\mathrm{Tpart}-i}\≤t_{\mathrm{Tbin}-i}+\underset{k=l}{\overset{c}{\mathrm{\Σ}}}{t}_{\mathrm{call}-\mathrm{ki}0}$

公式(6) 

为了在运行时求解这个不等式，分配模块604可以将数值代入各个时间变量并计算结果。 

为此，各个时间变量可以用分配模块604所知和/或所计算的值和单位来表示。这样的表达式以下提供在公式(7)到公式(9)的示例中。 

例如，在网格网络中转移数据的次数可以被描述为数据大小“s”(例如，以字节表示)、带宽“b”和等待时间“l”的函数。例如，公式(7)以被转移分区的大小、中心节点102和节点“i”之间的等待时间、以及相关带宽“b”这些项来表示用于将数据分区转移到节点“i”的时间： 

t_Tpart-i＝l_i0+s_Tpart-i/b 

公式(7) 

相关数据调用所需时间可以写作以下公式(8)，其包括两个等待时间项“l_i0”和“l_0i”来说明在数据调用的请求和响应时的等待时间： 

t_data-ki0＝l_i0+s_data-k/b+l_0i

公式(8) 

根据二进制的大小、带宽、中心节点和节点“i”之间的等待时间，以及根据实际将任务实例的二进制文件部署到节点“i”的本地服务器(例如，图1的服务器126b)所需的时间相关联的时间t_deploy，部署任务实例(例如，转移工作二进制)所需的时间可以被写作公式(9)，其类似公式(7)和公式(8)。 

t_Tbin-i＝l_0i+s_Tbin-i/b+t_deploy

公式(9) 

将公式(7)、公式(8)和公式(9)代入公式(6)的不等式可以得到公式(11)的结果： 

$l_{0i}+s_{\mathrm{Tpart}-i}/b\≤l_{0i}+s_{\mathrm{Tbin}-i}/b+t_{\mathrm{deploy}}+\underset{k=l}{\overset{c}{\mathrm{\Σ}}}(s_{\mathrm{data}-k}/b+2\·l_{i0})$

公式(11) 

由于t_depl0y≥0，如果公式(12)成立，则上述条件为真： 

$l_{0i}+s_{\mathrm{Tpart}-i}/b\≤l_{0i}+s_{\mathrm{Tbin}-i}/b+\underset{k=l}{\overset{c}{\mathrm{\Σ}}}(s_{\mathrm{data}-k}/b+2\·l_{i0})$

公式(12) 

因此，对是否执行数据分区的转移的决定可以被写作公式(13)，其中“2c”项说明了与相关数据调用相关联的通信的全双工性质： 

$s_{\mathrm{Tpart}-i}-s_{\mathrm{Tbin}-i}\≤2c\·l_{i0}\·b+\underset{k=l}{\overset{c}{\mathrm{\Σ}}}{s}_{\mathrm{data}-k}$

公式(13) 

可以看出，公式(13)意味着为了在所示例的环境中使转移数据分区有利，在数据分区的大小与任务实例二进制文件的大小之间的大小差别(即不等式左手侧部分)必须小于由数据调用的数量、相关等待时间和带宽、以及数据调用的大小所确定的量(即不等式右手侧部分)。这个条件更可能在出现高等待时间“l_i0”、大带宽“b”、大量数据库调用、和/或大量数据“s_data-k”要发送时发生。在这点上，应当理解，如上所讨论的，本说明是针对于将要网格增强的(grid-enhanced)(即网格相关的地理分散性增大了高等待时间“l_i0”的可能性)数据密集型的应用(即“c”和“s_data-k”可能会较大)。因此，上述条件中的许多或全部都可能在所描述的情形中成立，并且在其它类似的情形中成立，也可以获得由转移数据分区所带来的这些情况下的益处。 

在其它、类似的情形中可以执行类似的计算。例如，上述计算也可以对要从中心节点(即以中心节点为初始节点)部署数据分区的情况提供。但是，如果另一个节点“j”当前存储有数据分区(即将要用作初始节点)，并且发现另一个节点“i”能够接受相关的任务实例，并且具有至少与“l_ij”一样大的“l_i0”，则通过将任务实例部署到节点“i”可以得到性能的改善。当然，如果i＝j，则等待时间“l_ij”变为零，并且上述条件将成立。 

上述描述是为了示例的目的，而不是为了限制其它示例实施方式。例如，上述计算估计了当在单一任务实例的基础上转移数据分区时是否存在性能的改善。但是，在运行时，会存在同一任务的多于一个的实例。如果目的是作为一个整体改善任务的平均性能，则应当考虑所有相关任务实例的积累的性能。例如，供应管理器134可以在第一个任务实例进入队列602时确定实际上预计总共会有“m”个任务实例。 

在这个示例中，在以下公式(14)中给出了在单一任务要求“m”个实例时，支持转移数据分区的条件。在公式(14)中，应当理解，对于“m-1”个任务实例，只需要考虑二进制转移时间和部署时间(t’_ii)的总和。 

t_ii+(m-1)·t′_ii≤m·t_i0

$\max (t_{\mathrm{Tbin}-i},t_{\mathrm{Tpart}-i})+t_{\mathrm{exe}}+(m-1)\·(t_{\mathrm{Tbin}-i}+t_{\mathrm{exe}})\≤m\·(t_{\mathrm{Tbin}-i}+t_{\mathrm{exe}}+\underset{k=l}{\overset{c}{\mathrm{\Σ}}}{t}_{\mathrm{call}-\mathrm{ki}0})$

$\max (t_{\mathrm{Tbin}-i},t_{\mathrm{Tpart}-i})\≤t_{\mathrm{Tbin}-i}+m\·\underset{k=l}{\overset{c}{\mathrm{\Σ}}}{t}_{\mathrm{call}-\mathrm{ki}0}$

$s_{\mathrm{Tpart}-i}-s_{\mathrm{Tbin}-i}\≤m\·(2c\·l_{i0}\·b+\underset{k=l}{\overset{c}{\mathrm{\Σ}}}{s}_{\mathrm{data}-k})$

公式(14) 

各种这里所描述的技术的实施方式可以用数字电路、或计算机硬件、固件、软件、以及它们的组合来实施。实施方式可以实施为计算机程序产品，即，有形地体现在信息载体中的计算机程序，例如体现在机器可读存储设备中或体现在传播信号中，用于由数据处理装置执行或用于控制数据处理装置的操作，所述数据处理装置例如为可编程处理器、计算机、或多个计算机。计算机程序，诸如上述计算机程序，可以用包括编译语言或解释语言的任何形式的编程语言来编写，并能够以任何形式来运用，包括以独立程序形式或 作为模块、组件、子例程、或其它适于在计算环境中使用的单元来运用。计算机程序可以在一个地点的一台计算机或多台计算机上执行，或者在分布在多个地点并通过通信网络互连的多台计算机上执行。 

方法步骤可以被一个或更多个可编程处理器执行，所述可编程处理器执行计算机程序，通过对输入数据操作和产生输出来执行功能。方法步骤还可以被专用逻辑电路执行，或者装置可以被实施为专用逻辑电路，所述专用逻辑电路例如为FPGA(现场可编程门阵列)或ASIC(专用集成电路)。 

作为例子，适于执行计算机程序的处理器包括通用和专用微处理器，以及任何类型的数字计算机的任意一个或更多个处理器。一般来说，处理器将从只读存储器或随机访问存储器接收指令和数据，或者从两者都接收指令和数据。计算机的要素可以包括至少一个用于执行指令的处理器，和用于储存指令和数据的一个或更多个存储器设备。一般来说，计算机还可以包括，或者被可操作地连接，以从一个或更多个用于存储数据的海量储存设备接收数据，或把数据传送到海量储存设备，或者二者皆有，所述海量储存设备例如为磁盘、磁光盘或光盘。适于具体实施计算机程序指令和数据的信息载体包括所有形式的非易失性存储器，作为例子，包括半导体存储器器件，例如EPROM、EEPROM和快闪存储器设备、磁盘，例如内置硬盘或可移动磁盘、磁光盘和CD-ROM以及DVD-ROM盘。处理器和存储器可以被专用逻辑电路补充，或被包含在专用逻辑电路中。 

为了提供和用户的交互，实现方式可以在具有显示设备和键盘以及指示设备(pointing device)的计算机上实施，显示设备例如阴极射线管(CRT)或液晶显示器(LCD)监视器，用于向用户显示信息，键盘和指示设备例如鼠标或跟踪球，用户利用它们可以提供到计算机的输入。其他种类的设备也可以被用来提供和用户的交互；例如，提供给用户的反馈可以是任何形式的感觉反馈，例如视觉反馈、听觉反馈或触觉反馈，并且，来自用户的输入可以被以任何形式接收，包括声音、语音或触觉输入。 

实现方式可以被在包括后端组件或包括中间件组件或包括前端组件的计算系统中实施，或者在这些后端、中间件、前端组件的任意组合中实施，后端组件例如数据服务器，中间件组件例如应用服务器，前端组件例如具有图形用户接口，或Web浏览器的客户端计算机，通过图形用户界面或Web浏览器，用户可以和实现方式进行交互。可以利用数字数据通信的任何形式或介 质互连组件，数字数据通信介质例如为通信网络。通信网络的例子包括：局域网(LAN)和广域网(WAN)，例如因特网。 

虽然如这里所描述的那样已经示出了所描述的实现方式的某些特征，但是本领域普通技术人员现在将想到很多修改、替换，变化或等同物。因此要理解，所附权利要求旨在覆盖所有这些修改和变化。 

Claims (20)

1.一种用于网格计算的系统，包括：

分区分析器，被配置为在网格网络的数据库中指定至少一个数据分区，其中，从有利于更少或不频繁使用的数据的角度，所述分区分析器权衡将所述数据包括在至少一个数据分区的每次转移中的成本，以便为供应管理器的使用而最优化所述数据库的数据分区，并且，该分区分析器进一步被配置为执行将数据分区映射到应用的至少一个任务，该应用将要被至少部分地在所述网格网络中执行；以及

所述供应管理器，被配置为：

确定所述至少一个任务的任务实例，

基于所述映射并且与所述任务实例的执行相关联地确定所述数据分区，以便预先得知数据分区包括该任务实例将最频繁和/或最可能调用的数据，该数据分区被存储在所述网格网络的初始节点，

确定具有执行所述任务实例所需的处理资源的网格网络的处理节点以及具有存储所述数据分区所需的存储资源的网格网络的数据节点，该确定是基于处理节点和数据节点之间的等待时间而进行的，

对于利用在数据节点的数据分区的任务实例的执行时间是否少于利用保留在初始节点的数据分区的任务实例的默认执行时间来进行比较，

将所述任务实例部署到所述处理节点，以及

如果所述比较结果显示利用在数据节点的数据分区的任务实例的执行时间少于利用保留在初始节点的数据分区的任务实例的默认执行时间，则将所述数据分区从所述初始节点转移到所述数据节点。

2.如权利要求1所述的系统，其中所述分区分析器被配置为：基于所述任务相对于所述数据分区的访问特性来指定所述至少一个数据分区。

3.如权利要求2所述的系统，其中所述访问特性包括由一个或多个将来的任务实例访问所述数据分区的预期频率。

4.如权利要求1所述的系统，其中所述初始节点包括存储所述数据库的网格网络的中心节点。

5.如权利要求1所述的系统，其中所述初始节点包括所述至少一个数据分区先前部署到的先前数据节点，所述先前部署是所述供应管理器的先前提供操作的一部分。

6.如权利要求1所述的系统，其中所述供应管理器包括：

资源管理器，被配置为：

确定具有处理资源的网格网络的第一多个节点，所述第一多个节点包括所述处理节点，

确定具有存储资源的网格网络的第二多个节点，所述第二多个节点包括所述数据节点，以及

通过确定在所述第一多个节点的节点和所述第二多个节点的节点组合之间的等待时间来确定所述处理节点和所述数据节点。

7.如权利要求6所述的系统，其中所述资源管理器被配置为：通过确定所述处理节点和所述数据节点之间的等待时间少于所述节点组合的其它组合之间的等待时间来确定所述处理节点和数据节点。

8.如权利要求6所述的系统，其中所述第一多个节点和所述第二多个节点包括公共节点，并且其中所述供应管理器被配置为选择所述公共节点作为所述处理节点和所述数据节点这两种节点。

9.如权利要求6所述的系统，其中所述资源管理器还被配置为基于与所述网格网络相关联的网格传输特性，从所述第一多个节点和第二多个节点之一或全部中过滤一个或多个节点。

10.如权利要求1所述的系统，其中所述供应管理器包括：

分配模块，被配置为通过计算执行时间、以及通过计算默认执行时间来进行所述比较，其中，该执行时间包括部署任务实例的部署时间以及将数据分区从初始节点转移到数据节点的转移时间中较大者，并且该默认执行时间包括部署任务实例的部署时间。

11.如权利要求1所述的系统，其中所述供应管理器包括：

分配模块，被配置为通过计算包括所述任务实例的实例执行时间和由所述任务实例对所述数据分区进行数据调用所需的数据调用时间的执行时间和默认执行时间来进行所述比较。

12.如权利要求1所述的系统，其中所述供应管理器被配置为利用联合数据库管理系统，基于所述比较将数据分区从所述初始节点转移到所述数据节点。

13.一种用于网格计算的方法，包括：

通过分区分析器在网格网络的数据库中指定至少一个数据分区，其中，从有利于更少或不频繁使用的数据的角度，所述分区分析器权衡将所述数据包括在至少一个数据分区的每次转移中的成本，以便为供应管理器的使用而最优化所述数据库的数据分区，并且，该分区分析器还被配置为执行将数据分区映射到应用的至少一个任务，该应用将要被至少部分地在所述网格网络中执行；

通过所述供应管理器确定将要执行的任务实例；

基于所述映射并且与所述任务实例的执行相关联地确定数据分区，以便预先得知数据分区包括该任务实例将最频繁和/或最可能调用的数据，该数据分区被存储在所述网格网络的初始节点；

确定具有执行所述任务实例所需的处理资源的网格网络的处理节点和具有存储所述数据分区所需的存储资源的网格网络的数据节点，该确定是基于处理节点和数据节点之间的等待时间而进行的；

对于利用在所述数据节点的数据分区的任务实例的执行时间是否少于利用保留在所述初始节点的数据分区的任务实例的默认执行时间来进行比较；

将所述任务实例部署到所述处理节点；以及

如果比较结果显示利用在所述数据节点的数据分区的任务实例的执行时间少于利用保留在所述初始节点的数据分区的任务实例的默认执行时间，则将所述数据分区从所述初始节点转移到所述数据节点。

14.如权利要求13所述的方法，其中确定所述数据分区包括：

访问先前执行的应用的任务到所述数据分区的映射，所述任务实例从该应用的任务来实例化，所述映射与所述任务实例相对于所述数据分区的访问特性相关联。

15.如权利要求13所述的方法，其中确定所述等待时间包括：

确定具有处理资源的网格网络的第一多个节点，该第一多个包括所述处理节点；

确定具有存储资源的网格网络的第二多个节点，该第二多个包括所述数据节点；以及

通过计算在所述第一多个节点的节点和所述第二多个节点的节点之间的等待时间来确定所述处理节点和所述数据节点。

16.如权利要求13所述的方法，其中进行所述比较包括：

计算包括部署所述任务实例的部署时间和将所述数据分区从所述初始节点转移到所述数据节点的转移时间中较大者的执行时间。

17.一种用于网格计算的装置，包括：

分区分析器，用于在网格网络的数据库中指定至少一个数据分区，其中，从有利于更少或不频繁使用的数据的角度，所述分区分析器权衡将所述数据包括在至少一个数据分区的每次转移中的成本，以便为供应管理器的使用而最优化所述数据库的数据分区，并且，该分区分析器还被配置为执行将数据分区映射到应用的至少一个任务，该应用将要被至少部分地在所述网格网络中执行；

所述供应管理器，用于确定将要执行的任务实例；

用于基于所述映射并且与所述任务实例的执行相关联地确定数据分区，以便预先得知数据分区包括该任务实例将最频繁和/或最可能调用的数据的装置，该数据分区被存储在所述网格网络的初始节点；

用于确定具有执行所述任务实例所需的处理资源的网格网络的处理节点和具有存储所述数据分区所需的存储资源的网格网络的数据节点的装置，该确定是基于处理节点和数据节点之间的等待时间而进行的；

用于对于利用在所述数据节点的数据分区的任务实例的执行时间是否少于利用保留在所述初始节点的数据分区的任务实例的默认执行时间来进行比较的装置；

用于将所述任务实例部署到所述处理节点的装置；以及

用于如果所述比较结果显示利用在所述数据节点的数据分区的任务实例的执行时间少于利用保留在所述初始节点的数据分区的任务实例的默认执行时间，则将所述数据分区从所述初始节点转移到所述数据节点的装置。

18.如权利要求17所述的装置，其中用于确定数据分区的装置包括：

用于访问先前执行的应用的任务到所述数据分区的映射的装置，所述任务实例从该应用的任务来实例化，所述映射与所述任务实例相对于所述数据分区的访问特性相关联。

19.如权利要求17所述的装置，其中用于确定等待时间的装置包括：

用于确定具有处理资源的网格网络的第一多个节点的装置，该第一多个包括所述处理节点；

用于确定具有存储资源的网格网络的第二多个节点的装置，该第二多个包括所述数据节点；以及

用于通过计算在所述第一多个节点的节点和所述第二多个节点的节点之间的等待时间来确定所述处理节点和所述数据节点的装置。

20.如权利要求17所述的装置，其中用于进行所述比较的装置包括：

用于计算包括部署所述任务实例的部署时间和将所述数据分区从所述初始节点转移到所述数据节点的转移时间中较大者的执行时间的装置。

Images