CN107113341B - 用于数据划分的分布式关系数据库管理系统中事务的高吞吐量处理的系统 - Google Patents

Abstract

在分布式面向数据的OLTP环境中使用一种基于主题的消息架构(包括模式、协议、命名规则等)。所述基于主题的消息架构实施为一种发布‑订阅(publication‑subscription，pub‑sub)消息模式。在所述基于主题的系统的一项或多项实施例中，消息被发布到“主题”或命名为逻辑信道。基于主题的系统中的订户将收到发布到他们所订阅的主题的所有消息，一个主题的所有订户将收到相同的消息。发布方负责定义订户可以订阅的消息类别。基于主题的消息接口提高了分布式数据库管理系统的可扩展性，并且为消息递送提供了一种稳健的机制。

Description

用于数据划分的分布式关系数据库管理系统中事务的高吞吐 量处理的系统

相关申请案交叉申请

本申请要求2015年1月16日递交的发明名称为“用于数据划分的分布式关系数据库管理系统中事务的高吞吐量处理的系统(SYSTEM FOR HIGH-THROUGHPUT HANDLING OFTRANSACTIONS IN A DATA-PARTITIONED,DISTRIBUTED,RELATIONAL DATABASE MANAGEMENTSYSTEM)”的第14/599,043号美国非临时专利申请案的在先申请优先权，该在先申请的全部内容以引用的方式并入本文本中。

背景技术

硬件技术的发展，具体是计算机处理和存储能力的发展，促使电子数据库和数据库管理系统(database management systems，DBMS)在几乎每种商业和产业中激增。数据库对于存储、操作和处理信息集合来说已变得必不可少。通常，数据库中收集的一个或多个数据单元通过一个事务访问。访问通过一个或多个进程执行，这些进程可以是专用事务处理线程。当数据必须由若干线程同时访问时会产生各种问题。

在传统的数据库管理系统中，各个事务的访问模式是任意的且不协调的，因此各个线程的访问模式也是如此。为了确保数据完整性，每个线程进入其执行的每个事务的生命周期中的一个或多个部分。为了防止数据损坏，在线程访问一个部分时，将逻辑锁应用到该部分，以便在当前线程在进行处理时不允许其它线程访问该部分。然而关键部分会引起锁获取和释放，获取和释放的开销随着并行线程数量的增加而增加。但是，在竞争激烈的关键部分会发生延迟，对性能产生不利影响。竞争的主要原因是数据访问不协调，即传统事务处理系统的特性。因为这些系统(通常)将每个事务分配给一个单独的线程，所以在共享数据访问期间，线程经常相互竞争。

为了减轻将逻辑锁应用到整个数据区的影响，可以将数据区划分为较小的部分。每个“锁”仅应用到线程正在操作的特定分区，从而使其它分区由执行其它事务的其它线程自由访问。锁管理器负责保持并发执行事务之间的隔离，从而提供接口供事务请求、升级、和释放锁。但是，当并发执行事务的数量由于处理能力的提高而增长时，在典型的事务处理系统中，集中式锁管理器经常是第一竞争组件和可扩展性瓶颈。

根据最近提议的针对竞争问题的替代方案(面向数据的架构)，一种方案是将每个线程与数据库的一个不同子集耦合，而不是将每个线程与一个事务耦合。事务在访问不同的数据时从一个线程流向另一个线程。事务根据它们访问的数据分解为较小的动作，并路由到对应的线程来执行。在这一方案下，数据对象跨同一事务的多个动作进行共享，以便控制事务的分布式执行并且在有数据依赖关系的动作之间传输数据。这些共享对象称为“集合点”或“RVP”。如果两个动作之间存在数据依赖关系，则在它们之间放置一个RVP。RVP将事务执行分为不同的阶段。系统无法并发执行同一事务中的不同阶段的动作。

然而，虽然所提议的替代方案针对竞争相关的延迟提供了一种方案，但是这一方案是针对处理器紧密耦合并构成单个数据库系统的数据存储实施方式，对分布式数据库来说不适用于和/或是次优的。在分布式数据库中，存储设备并非全部附接到CPU等常见处理单元，而可以存储在分散在互联计算机网络上的多个计算机中。

发明内容

本发明内容以简化的方式介绍了下文在具体实施方式中进一步描述的概念的选择。本发明内容并不旨在识别请求保护的主题的关键特征或基本特征，也不旨在用于限制请求保护的主题的范围。

本发明针对将在分布式面向数据的OLTP环境中使用的一种新颖的、基于主题的消息架构(包括模式、协议、命名规则等)。根据请求保护的主题的一个方面，所述基于主题的消息架构可以实施为一种发布-订阅(publication-subscription，pub-sub)消息模式。

在所述基于主题的系统的一项或多项实施例中，消息被发布到“主题”或命名为逻辑信道。基于主题的系统中的订户将收到发布到他们所订阅的主题的所有消息，一个主题的所有订户将收到相同的消息。发布方负责定义订户可以订阅的消息类别。基于主题的消息接口提高了分布式数据库管理系统的可扩展性，并且为消息递送提供了一种稳健的机制。通过在分布式面向数据的架构上使用基于主题的消息，两个主要因素促进了系统吞吐量的增长，即，消除了锁竞争以及将通信消息委托给一个单独的消息系统。这两个因素都能够显著减轻CPU工作负载，使得数据库节点中的CPU能够专注于执行有用的数据库工作。这就是说，分布式面向数据的事务处理系统的吞吐量因此显著提高，并且系统能够执行更大的分布式规模的事务。

根据请求保护的主题的一个方面，提供了一种用于在联机分布式数据库系统中执行数据库事务的方法。在一实施例中，可通过以下操作执行数据库事务：从客户端设备接收面向数据的事务，在协调器中为所述事务生成提交信道和事务计划，从现有多个逻辑信道中识别对应的逻辑信道，以及为映射到所述逻辑信道的处理线程订阅所述提交信道。然后，将指令和通知从所述协调器发布到所述提交信道，并转发给订阅线程。所述线程根据所述发布的指令执行数据库动作，所述动作的完成被发布到所述协调器和所述提交信道(然后发布到所述提交信道的订户)。

在一项或多项实施例中，事务计划包括分布在多个阶段的多个数据库动作，一个阶段的所述动作的完成在各个序列化点处跟踪，所述序列化点分隔所述多个阶段并传达当前阶段的完成。在同一个阶段中执行的数据库动作可并行执行或大致并行执行，一个事务中的所有阶段都完成后，所述事务结束。在一项或多项其它实施例中，所有阶段的完成提示所述协调器执行两阶段提交协议，其可包括向所述处理线程发送查询以进行提交或回滚投票。如果所有处理线程都返回提交选票，则将所述数据库动作的执行结果提交给所述数据库节点，所述事务完成。

根据本文描述的请求保护的主题的实施例，实现了一种具有高性能、吞吐量、审计、调试和监控属性的高吞吐量、分布式、多分区事务系统。另外，可实现处理单元的一种松散耦合的分布式系统，所述系统已经具有内部的、面向数据的事务管理机制。结合下文的描述，本发明的附加优势和特征将变得显而易见，并且可通过随附权利要求书中特别指出的工具和组合来实现。

附图说明

附图包含在并且构成本说明书的一部分，示出了本发明的各种实施例，并且与描述内容一起用于解释本发明的原则：

图1描绘了根据本发明实施例的分布式数据库系统中的示例性基于主题的消息架构的方框图。

图2描绘了根据本发明实施例的分布式数据库系统中的示例性发布/订阅数据流程图的方框图。

图3描绘了根据本发明实施例的跨多个阶段分布的示例性事务执行计划的方框图。

图4描绘了根据本发明实施例的表示主题概要的示例性数据结构。

图5描绘了根据本发明实施例的跨多个阶段分布的示例性事务的时序图。

图6描绘了根据本发明实施例的用于执行联机分布式数据库系统中的数据库事务的过程的示例性流程图。

图7描绘了本发明实施例可在其上执行的示例性通用计算环境。

具体实施方式

现将详细地对请求保护的主题的优选实施例、用于射线成像系统的方法和系统做出参考，其示例在附图中示出。虽然结合优选实施例描述该请求保护的主题，但应该理解它们不是旨在将请求保护的主题限制于这些实施例。相反，请求保护的主题旨在覆盖可以包括在由附加的权利要求书的精神和范围内的替代物、修改和等同物。

此外，在本请求保护的主题的实施例的以下具体描述中，阐述许多具体细节以便提供对本请求保护的主题的透彻理解。然而，所属领域的普通技术人员将认识到，可以在没有这些具体细节的情况下实践本请求保护的主题。在其它实例中没有详细描述众所周知的方法、流程、部件和电路，以免对本请求保护的主题的各方面造成不必要地模糊。

该具体实施方式的一些部分按照程序、步骤、逻辑块、处理、以及对计算机存储器中的数据位的操作的其它符号表示来呈现。这些描述和表示是数据处理领域技术人员向该领域其他技术人员有效传达工作实质内容使用的方法。将程序、计算机产生的步骤、逻辑块、过程等一般设想为首尾一致的步骤或指令序列，以产生期望的结果。这些步骤需要物理量的物理操控。通常，并不是完全必须的，这些量以电信号或磁信号的形式存在，可以被存储、转移、合并和比较，否则将在电脑系统中被操控。有时候这种方法被证明是行之有效的，主要出于常见用法的考虑，将这些信号作为比特位、数值、元素、符号、字符、术语、或数字等等。

然而，应牢记，所有这些和类似术语与适当物理量相关联，且仅为应用于这些量的方便标签。除非确切地陈述为从以下论述显而易见，否则应了解，在本请求保护的主题中，利用例如“存储”、“创建”、“保护”、“接收”、“加密”、“解密”、“破坏”等术语的论述是指将表示为计算机系统的寄存器和存储器内的物理(电子)量的数据操控和变换为类似地表示为计算机系统存储器或寄存器或其它此类信息储存、传输或显示设备内的物理量的其它数据的、包括内嵌系统的计算机系统或集成电路或类似电子计算设备的动作和进程。

相应地，所请求保护的主题的实施例提供了一种将在联机事务处理(onlinetransaction processing，OLTP)系统等分布式面向数据的环境中使用的基于主题的消息架构。根据一实施例，基于主题的消息架构可包括通过发布/订阅消息总线可通信地耦合到一个或多个分布式数据库的协调器。图1描绘了这种架构的示例性配置100。

如图1所示，在事务协调器103中接收事务101。在一项或多项实施例中，事务可实施为来自客户端设备的SQL请求。事务协调器可例如实施为计算设备，例如web主机和/或服务器。事务可通过存储在一个或多个数据库节点中的数据执行。这些节点可包括分布式(远程放置的)计算设备，每个计算设备存储数据的一个或多个部分(分区)。在替代性实施例中，这些节点可包括共置但不同的计算系统，或者远程和共置计算系统这两者的组合。

包含数据事务的动作通过面向数据的事务参与者(105)中执行，在一项或多项实施例中，面向数据的事务参与者可实施为处理线程，这些处理线程对应于一个或多个数据库节点且在一个或多个数据库节点中执行。在又一实施例中，每个处理线程专门负责对与该处理线程对应的数据分区执行动作。每个线程可实施为一个(动作)排队线程，其中待执行的新动作被附加到排队线程的末端，线程按接收顺序执行动作。

在一项或多项实施例中，架构100实施为基于主题的系统。在这一实施例下，协调器之间的通信(消息)通过消息系统(例如，总线107)发布到“主题”或命名为逻辑信道。逻辑信道可对应一个特定的类别。例如，一个类别可对应一个特定分区、数据实体或者与系统的其它关联或标识。面向数据的事务参与者可以订阅一个或多个逻辑信道，系统中的订户将收到发布到他们所订阅的主题的所有消息，一个主题的各个订户会收到相同的消息。发布方负责定义订户可以订阅的消息类别。

同样，当动作通过处理线程执行时，处理线程105可通过消息总线107将通知发布到协调器(以及其它订阅线程)。在一项或多项实施例中，一旦面向数据的事务参与者(105)执行了所有子动作，就执行完了事务，并且执行两阶段提交协议来验证事务的完成。

图2描绘了分布式数据库系统中的示例性发布/订阅数据流程图200。如图2所示，上文结合图1描述的基于主题的消息架构的协调器可实施为或者实施来包括发布/订阅服务器(201)。如图2所示，一个或多个消息发布方(例如，203a、203b、203c)发布消息，这些消息在发布/订阅服务器201中接收。这些消息可包括，例如，由事务中的处理线程(面向数据的事务参与者)执行的一个或多个动作的完成。

在一项实施例中，发布/订阅服务器接收发布方(例如，通过消息总线)发送的消息，并且确定(或提供有)消息对应的主题或逻辑信道。随后，发布/订阅服务器引用将逻辑信道映射到相关订户的表207来确定哪些订户订阅了该消息的逻辑信道。然后，通过将服务器201耦合到订户(205a、205b、205c)的消息总线将消息直接转发给确定的订户，避免了未订阅该消息信道的节点/线程。

根据一项或多项实施例，可将一个客户端请求或事务作为一系列“步骤”或阶段执行，每个步骤或阶段包含可以安排为并行运行的多个‘动作’，它们与前一阶段中的动作有依赖关系。图3描绘了事务的典型执行计划300。如图3所示，事务的执行计划可包括分布在一系列或一连串阶段(301、303)中的多个动作(p1、p2、p3、p4)。在一项或多项实施例中，分布在同一阶段中的动作(例如，301中的p1和p2，303中的p3和p4)可以通过对应的处理线程并行执行。

在两个或更多动作之间出现依赖关系的情况下，在两个阶段之间创建和执行序列化点(rvp1)。因此，例如如果动作p3依赖于动作p1的处理，动作p4依赖于p2的处理，则p3和p4在p1和p2完成后才开始，p1和p2的完成在序列化点rvp1处验证并传送(发布)。发布阶段1(301)中的动作在序列化点rvp1处完成后，阶段1结束；一旦通知被发布到处理p3和p4的线程，阶段2就开始。

根据一项或多项实施例，分布式环境中的动作排队通过向分别对应p1、p2和p3、p4的特定线程发送消息来完成。在最后一个序列化点(如图3描绘的rvp2)处，执行两阶段提交(two-phase commit，2PC)，因为涉及的线程可能位于不同节点中。根据一项或多项实施例，阶段的数量和序列化点的数量可以是任何任意数量，不限于本文中的描写。根据一项或多项其它实施例，事务计划可以对应在任意数量的任何分区中执行的数据库动作的组合，每个分区有其自己的阶段和序列化点的对应序列。

图4描绘了包括主题概要的示例性数据结构400。在一项或多项实施例中，主题概要可表示一个分区以及与该分区对应的实体。如图4所描绘，数据结构400可实施为描述数据库中的主题的特性和对应实体的表或图表。在一项或多项实施例中，数据结构400可自动生成(例如，通过客户端协调器，或与分区对应的节点)。在一项或多项实施例中，数据结构400根据各种类别组织分区中的数据。如图4所示，类别可包括：“主题类型”、“订户”、“发布方”、“消息内容”、“数量”和“命名”。

主题类型对数据事务的主题进行分类。如图4所描绘，主题类型可对应以下类型之一：(1)分区，对应于整个数据分区；(2)RVP主题，对应于事务的序列化点；(3)提交主题，对应于用于发布数据库动作执行完成的主题。

如图4所示，分区的订户就是分区所有者。根据图4的主题所有者是对特定主题有读写访问权的实体。在一项或多项实施例中，分区所有者是执行数据库动作的节点中的处理线程。在替代性实施例中，数据库管理系统自身可以是分区的所有者。分区主题的发布方包括动作排队线程(处理线程)，发布到分区的消息内容可包括动作描述、序列化的名称/标识和订阅分区主题的提交主题。根据一项或多项实施例，分区数量自然对应数据库中的节点数量，可在数据库系统内使用静态分区标识码对分区进行命名。

对于序列化点主题(也叫做RVP主题)，订户是序列化点的所有者，可包含分区的处理线程，在这些分区中对与该序列化点对应的给定事务的阶段执行数据库动作。线程的发布方是事务参与者——也是分区所有者。发布到序列化主题的消息包括来自分区所有者的、在与序列化点对应的阶段内在分区中执行的数据库动作的执行结果。每个事务可以有多个序列化点主题，取决于事务计划。序列化主题可在数据库管理系统内通过特定命名法确定，该命名法包含将主题作为序列化点的指示，以及事务ID和在与该序列化点对应的序列中的位置。

对于提交主题，订户是与该提交主题对应的序列化点的所有者，通常是执行线程。提交主题的发布方包括序列化点的所有者和分区所有者。在提交信道中发布的消息的消息内容可包括序列化点所有者发布的投票(例如，在提交动作开始时)请求。其它消息内容可包括来自分区所有者的、对投票请求的响应，以及来自序列化点所有者的、基于收到的响应进行的处置(例如，提交数据库动作结果或者中止所执行的动作)。每个事务有一个提交主题，提交主题可在数据库管理系统内通过提交前缀(带有事务ID)来标识。

图5描绘了根据本发明实施例的跨多个阶段分布的示例性事务的时序图500。图5描绘了可在事务期间执行的事件的示例性时间表。如图5所描绘，在某个时间t₀可生成一个或多个逻辑信道或“主题”。例如，逻辑信道可由协调器生成。一个或多个处理/执行线程或“工作者”(例如，工作者w1、w2、w3和w4)可分别订阅对应主题，例如，w1订阅p1，w2订阅p2，w3订阅p3，w4订阅p4。

在时间t₁，从客户端发出事务请求。(例如，在协调器中)接收事务请求，协调器生成提交信道/主题。在一项或多项实施例中，可从已关闭(例如，由于停止使用)的预先存在的提交信道中重新分配一个提交信道。协调器确定相关逻辑信道以及针对事务的执行计划。根据一项或多项实施例，典型的执行计划可包括在一个或多个阶段内执行的一个或多个数据库动作，其中与另一数据库动作有依赖关系的数据库动作被分发到一个不同的(后续)阶段。当该阶段中的数据库动作已执行并且按在序列化点处执行的那样进行了验证时，该阶段结束。一旦确定了执行计划，协调器就在必要时生成序列化点。例如，如图5所描绘，事务包括两个阶段，针对每个阶段生成一个序列化点(RVP 1、RVP 2)。

一旦生成了第一个序列化点，就可执行数据库动作(编号为1-13)。协调器确定与提交信道对应的逻辑信道，并将对应关系的通知发布给特定逻辑信道。在图5中，发布通过虚线指示，订阅通过点虚线指示。在动作1处，例如，协调器发布提交信道到信道p1的关联关系，订阅信道p1的工作者(w1)接收该关联关系。之后，工作者w1被订阅该提交信道。类似地，在动作2处，协调器发布提交信道到信道p2的关联关系，订阅信道p2的工作者(w2)接收该关联关系。之后，工作者w2被订阅提交信道。

在一项或多项实施例中，执行数据库动作的指令可与发布的通知一起发送给工作者，或者分别/相继发送。一旦执行了数据库动作，处理线程就将其相应数据库动作的完成通知发布给协调器(分别在动作3和4进行)。中间结果在第一阶段的序列化点处收集。如图5所描绘，在序列化点处收到中间结果后，第一阶段结束，第二序列化点生成。

然后，协调器将提交信道的关联关系发布给与第二阶段对应的信道。如图5所描绘，发布在逻辑信道p3中接收，其在动作5处由订阅信道p3的工作者(w3)接收；并且，发布在逻辑信道p4中接收，其在动作6处由订阅信道p4的工作者(w4)接收。之后，工作者w3和w4被订阅提交信道。

同样，结合阶段1，执行数据库动作的指令可与已发布通知一起发送给与阶段2对应的工作者，或者分别/相继发送。数据库动作由对应的线程执行，处理线程将其相应数据库动作的完成通知发布给协调器(分别在动作7和8进行)。阶段2的中间结果在第二阶段的序列化点处收集。在阶段2的序列化点处收到中间结果后，第二阶段结束。

如果执行计划不包含额外的阶段，则执行两阶段提交来验证在事务期间执行的动作。在一项或多项实施例中，执行计划包括由协调器发起的投票(动作9)请求，投票请求被分发给提交信道的订户(在这种情况下，是事务中涉及的所有处理线程)。如果工作者/处理线程能够确认线程负责执行的数据库动作完成，则线程发布提交选票(分别来自工作者w3、w2、w4和w1的动作10、11、12、13)。如果协调器从每个处理线程收到提交选票，则提交(即，分发到每个数据节点和分区)在最后一个序列化点处收集的结果，事务完成。之后，提交信道可释放。在替代性实施例中，后续事务可重用提交信道。在替代性实施例中，如果处理线程尚未完成其数据库动作，或者发生错误，则可以收到回滚选票，其中在事务开始时，可使用数据库中的数据重新尝试该事务。

虽然使用四个提交主题进行描绘，但是将理解，该描绘仅出于示例性目的，不应理解为限于这一(或任何)数量。实际上，本发明非常适用于针对任意数量的阶段中的任何数量的阶段而包含任意数量的主题中的任何数量的主题的替代性实施例，这些阶段通过任意数量的序列化点中的任何数量的序列化点进行分隔。此外，虽然图5描绘了包含一个分区的事务计划，但是本发明的一项或多项实施例非常适用于如图5描绘的以及本文描述的在多个分区中并行和/或依次执行的事务计划。

图6描绘了用于执行联机分布式数据库系统中的数据库事务的过程600。步骤601至615描述了根据本文所述各种实施例的包括图6描绘的过程600的示例性步骤。在一项实施例中，过程600作为存储在计算机可读介质中的、由计算设备中的处理器执行的计算机可执行指令完整地或部分地实施。

如图6所描绘，数据库事务通过在步骤601处从客户端设备接收面向数据的事务开始执行。在一项或多项实施例中，客户端设备包括计算设备，例如个人计算机或笔记本电脑，数据库事务可实施为或者可包括数据库请求，例如结构化查询语言(Structured QueryLanguage，SQL)请求。数据库请求可在协调器中接收，实施为在网络化计算设备中执行的模块或应用，该设备可远离客户端计算设备放置。

在步骤603处，协调器为事务生成提交信道和事务计划。在一项或多项实施例中，事务计划包括数据库动作以及网络化数据库节点(和对应处理线程)的标识，其中数据库动作将针对这些网络化数据库节点执行。在其它实施例中，事务计划包括一系列阶段，以及数据库动作在这一系列阶段中的分布。在步骤603处，还可生成收集阶段之间的中间结果的序列化点。

在步骤605处，协调器从现有多个逻辑信道中确定与提交信道对应的逻辑信道。在步骤607处，为映射到所确定的逻辑信道的处理线程订阅提交信道。在一项或多项实施例中，处理线程通过参考存储在协调器中的订阅的映射来确定。一旦处理线程被订阅提交信道，在步骤609处，指令和通知就从协调器发布到提交信道并转发给订阅线程。在一项或多项实施例中，消息(包括发布和订阅)在持久发布/订阅消息总线中执行，该消息总线将协调器与数据库节点(和处理线程)可通信地耦合。

在步骤611处，线程根据发布的指令执行数据库动作，一旦完成，在步骤613处就分别通过消息总线将动作的完成发布给协调器和提交信道(之后是提交信道的订户)。一个阶段中的所有数据库动作都完成后，该阶段结束(步骤613)。如果根据执行计划需要后续阶段，则重复步骤609至615，直到不再需要后续阶段。在一项或多项其它实施例中，所有阶段的完成提示协调器执行两阶段提交协议，其可包括向处理线程发送查询以进行提交或回滚投票。如果所有处理线程都返回提交选票，则将数据库动作的执行结果提交给数据库节点，事务完成。

在一项或多项实施例中，同一个阶段中的数据库动作可并行执行，而与一个或多个其它数据库动作有依赖关系的数据库动作分布在所依赖的数据库动作之后的阶段中。一个阶段中的动作的完成在分隔该阶段并传达当前阶段的完成的各序列化点处跟踪。在同一个阶段中执行的数据库动作可并行执行或大致并行执行，一个事务中的所有阶段都完成后，该事务结束。

如图7所示，描绘了根据本发明实施例的示例性计算环境700。在其一般配置中，计算环境700通常包括至少一个处理单元701和存储器，以及用于传送信息的地址/数据总线709(或其它接口)。根据计算环境的确切配置和类型，存储器可以是易失性的(例如，RAM702)、非易失性的(例如，ROM 703、闪存等)、易失性和非易失性存储器的某种组合，或者能够存储后续召回数据和/或可在处理单元701上执行的指令的其它合适设备。根据一项或多项实施例，处理单元701可执行存储在计算环境700的存储器中的已编程指令711，以便对分布在多个分区中的数据库中的面向数据的事务进行协调。

在一些实施例中，计算环境700还可包括可选的图形子系统705，用于例如通过将信息显示在附接的或集成的显示设备710上来向用户展示信息。另外，计算系统700还可具有其它特征/功能。例如，计算系统700还可包括其它(可移动和/或不可移动的)存储器，包括但不限于，磁盘或光盘或磁带。图7通过数据存储设备704示出这种其它存储器。计算机存储介质包括以任意方法或技术实现的用于存储计算机可读指令、数据结构、程序模块或其它数据等信息的易失性和非易失性、可移动和不可移动介质。RAM 702、ROM 703以及数据存储设备704均为计算机存储介质的示例。

计算环境700还可包括物理(或虚拟)字符输入设备706、物理(或虚拟)光标控制或引导设备707。可选字符输入设备706可以将信息和命令选择传送给中央处理器701。可选光标控制或引导设备707耦合到总线709，用于将用户输入信息和命令选择传送给中央处理器701。如图7所示，计算环境700还包括一个或多个信号通信接口(输入/输出设备，例如网卡)707。信号通信接口可用于为计算环境700接收用户输入，和/或支持通过一个或多个可通信地耦合的计算环境发送和接收数据。

结合大量具体的可随实现变化而变化的细节，实施例已在上述说明书中描述。因此，判断何为本发明以及申请人旨在认为的本发明的唯一排他性指标是：本发明申请中包括的一组特定形式的权利要求，该申请公开了该权利要求，包括任何随后所做的校正。因此，任何在权利要求中没有表述清楚的局限性、要素、性质、特征、优点或属性不应该以任何方式限制该权利要求的范围。相应地，应认为本说明书和附图具有说明性意义而非限制性意义。

Claims (20)

1.一种用于在分布式、多分区数据管理系统中执行面向数据的事务的计算设备，其特征在于，所述计算设备包括：

存储器，可用于存储多个已编程指令；

处理器，用于执行所述多个已编程指令，以通过以下操作执行面向数据的事务：生成执行计划以执行跨多个远程计算设备中包括的多个分区而存储的数据库中的数据库动作，为数据库动作指令分配提交信道，以及确定与所述提交信道对应的逻辑信道，所述逻辑信道映射到所述多个远程计算设备中的至少一个远程计算设备；以及

消息总线，其将所述计算设备与所述多个远程计算设备可通信地耦合，

其中，所述处理器还用于基于所述逻辑信道确定用来执行数据库动作的指令并将所述指令分发给所述至少一个远程计算设备，

所述执行计划将通过多个同步点分隔的多个阶段中的所述数据库动作组织起来，以及

与所述多个阶段中的同一个阶段对应的数据库动作与在对应于所述阶段的所述多个同步点中的一个同步点处收集的所述多个阶段中的每个阶段的结果并行执行。

2.根据权利要求1所述的计算设备，其特征在于，所述处理器还用于：从客户端计算设备接收事务请求，基于所述事务请求生成新提交信道，确定与所述新提交信道对应的逻辑信道子集，以及将所执行的与所述提交信道对应的数据库动作的通知分发给所述多个远程计算设备中的与所述逻辑信道子集对应的远程计算设备。

3.根据权利要求1所述的计算设备，其特征在于，所述计算设备包括发布/订阅服务器。

4.根据权利要求1所述的计算设备，其特征在于，所述处理器还用于通过以下操作分发用来执行数据库动作的指令：将所述指令附加到与一个远程计算设备对应的动作排队线程。

5.根据权利要求1所述的计算设备，其特征在于，所述多个数据库动作中的一个数据库动作通过两阶段提交协议执行。

6.根据权利要求1所述的计算设备，其特征在于，生成所述提交信道包括从先前生成的提交信道的池中重分配一个先前生成的提交信道。

7.根据权利要求1所述的计算设备，其特征在于，所述多个同步点中的一个同步点包括先前生成的同步点的池中包括的一个先前生成的同步点。

8.根据权利要求1所述的计算设备，其特征在于，所述消息总线包括发布/订阅消息总线。

9.一种事务处理方法，其特征在于，应用于具有权利要求1-8任一所述的计算设备的设备特性的第一计算设备中，包括：

(a)在第一计算设备中从客户端计算设备接收面向数据的事务；

(b)为所述事务生成提交信道和执行计划，所述执行计划包括组织到通过多个同步点分隔的多个阶段中的多个数据库动作；

(c)从多个预先存在的信道中确定与所述提交信道对应的信道子集；

(d)为第一多个处理线程订阅所述提交信道，使得所述第一多个处理线程用于接收与所述提交信道对应的、将由所述第一多个处理线程执行的数据库动作的通知，所述第一多个处理线程与所述多个阶段中的第一阶段对应并映射到多个远程放置的计算设备；

(e)发布所述多个数据库动作中的将由所述第一多个处理线程执行的一组数据库动作；

(f)并行接收所述多个数据库动作中的与所述第一阶段对应的第一组数据库动作在多个数据分区中的第一数据分区上的执行通知；

(g)通过消息总线将第一组动作的完成发布给所述提交信道；以及

(h)在所述第一组动作完成后，终止所述第一阶段。

10.根据权利要求9所述的方法，其特征在于，还包括：

(i)接收所述第一组动作完成所产生的中间结果；

(j)为第二多个处理线程订阅所述提交信道，使得所述第二多个处理线程用于接收与所述提交信道对应的、将由所述第二多个处理线程执行的数据库动作的通知，所述第二多个处理线程与所述多个阶段中的第二阶段对应；

(k)通过将协调器与所述多个远程放置的计算设备可通信地耦合的消息总线，发布所述多个数据库动作中的将由所述第二多个处理线程执行的一组数据库动作；

(l)并行接收所述多个数据库动作中的与所述第二阶段对应的第二组数据库动作在所述多个数据分区中的第二组数据分区上的执行通知；

(m)通过所述消息总线将第二组动作的完成发布给所述提交信道；以及

(n)在所述第二组动作完成后，终止所述第二阶段。

11.根据权利要求10所述的方法，其特征在于，还包括：针对所述多个同步点中的任意数量的同步点、所述多个阶段中的与所述面向数据的事务对应的任意数量的阶段、所述多个分区中的任意数量的分区，执行步骤(i)至(n)。

12.根据权利要求10所述的方法，其特征在于，还包括：在发布所述第二组动作的所述完成后，执行所述多个数据库动作的两阶段提交。

13.根据权利要求12所述的方法，其特征在于，执行所述多个数据库动作的两阶段提交包括查询所述多个处理线程以确定所述多个数据库动作的所述完成。

14.根据权利要求9所述的方法，其特征在于，从客户端计算设备接收面向数据的事务包括在所述第一计算设备中生成执行计划，所述执行计划定义所述多个阶段和所述多个同步点。

15.根据权利要求14所述的方法，其特征在于，所述多个处理线程被预先订阅所述多个信道中的各自的对应信道。

16.根据权利要求15所述的方法，其特征在于，还包括所述多个处理线程与所述多个处理线程中的每一个处理线程预先订阅的所述对应多个信道的映射。

17.根据权利要求9所述的方法，其特征在于，生成所述提交信道包括从先前生成的提交信道的池中重分配一个先前生成的提交信道。

18.根据权利要求9所述的方法，其特征在于，所述多个同步点中的一个同步点包括先前生成的同步点的池中包括的一个先前生成的同步点。

19.一种包含归并在其中的已编程指令的非瞬时性计算机可读介质，其特征在于，所述已编程指令在由权利要求1-8任一所述的计算设备的处理器执行时，可用于执行数据库管理系统中的数据库指令，其中所述数据库管理系统包括分布在多个远程放置的计算设备中的多个数据分区，所述已编程指令包括：

从客户端计算设备接收面向数据的事务的指令；

为所述事务生成提交信道和执行计划的指令，所述执行计划包括组织到通过多个同步点分隔的多个阶段中的多个数据库动作；

从多个预先存在的信道中确定与所述提交信道对应的信道子集的指令；

为第一多个处理线程订阅所述提交信道的指令；

发布将由所述第一多个处理线程执行的数据库动作的指令；

并行接收所述多个数据库动作中的与第一阶段对应的第一组数据库动作在所述多个数据分区中的第一组数据分区上的执行通知的指令；

将第一组动作的完成发布给所述提交信道的指令；以及

在所述第一组动作完成后终止所述第一阶段的指令。

20.根据权利要求19所述的非瞬时性计算机可读介质，其特征在于，还包括：

接收所述第一组动作完成所产生的中间结果的指令；

为第二多个处理线程订阅所述提交信道的指令，使得所述第二多个处理线程用于接收与所述提交信道对应的、将由所述第二多个处理线程执行的数据库动作的通知，所述第二多个处理线程与所述多个连续阶段中的第二阶段对应；

发布将由所述第二多个处理线程执行的数据库动作的指令；

并行接收所述多个数据库动作中的与所述第二阶段对应的第二组数据库动作在所述多个数据分区中的第二组数据分区上的执行通知的指令；

将第二组动作的完成发布给所述提交信道的指令；以及

在所述第二组动作完成后终止所述第二阶段的指令。

Images