数据库管理系统分案说明
本申请属于申请日为2011年3月18日的中国发明专利申请
201180014604.6的分案申请。
技术领域
本发明总体上涉及数据库管理系统。更具体地，本发明涉及一种
方法和设备，用于实现多用户、弹性的、按需的分布式关系数据库管
理系统，其特征在于原子性、性能和可扩展性。
背景技术
在过去这些年中，用于存储和检索消息的数据库的使用已经在大
量的商业应用中显现为重要的工具。初始，许多数据库系统在具有多
个用户的单个服务器装置上操作。然而，在过去这些年中，各种因素
已经产生，它们要求数据库架构的基本特性改变。作为第一因素，数
据库存储要求已经变得极大。其次，试图访问这样的数据库的用户的
数量也已经变大。第三，用于检索具有最小的更新的相对稳定的数据
的数据库的使用已经被替换为事务处理。
事务是必须整体完成的工作的单位。单个事务可以包括多个数据
操纵。例如，单个事务可以包括读取操作，随后是写入操作。近年来，
大量的努力已经针对使得关系数据库能够支持日益增长的事务处理的
速率。
现在通过限定ACID属性的标准来判断数据库，该ACID属性即
原子性、一致性、隔离性和持久性。原子性确保以其整体来完成所有
的事务任务。一致性保证仅有效的数据被写入数据库。隔离性保证其
他操作在事务期间不能访问或“观看”在中间状态中的数据。持久性
保证一旦已经成功地处理了事务，则它不能被复原。
一致性在多用户系统中特别重要，在多用户系统中，两个或更多
的用户可能寻求对于共享的易失性数据的同时访问。早期的多用户系
统使用锁定操作来保证一致性。锁定可以是排他的或写入的锁定或者
是非排他的或读取的锁定，并且可以被应用到单独的记录或被应用到
页面。然而，当数据库在大小上已经增大时并且当事务速率已经提高
时，用于管理锁定的开销已经变得显著，并且在一些情况下已经变为
禁止性的。
多版本并发控制(MVCC)是用于保证同时性的替代处理。对于
复杂数据库，MVCC可以比锁定更有效。MVCC使用时间戳或增加的
事务标识(ID)来串行化记录的不同版本。每一个版本允许事务读取
在时间戳或ID前的对象的最近版本。利用该控制方法，其他用户将看
不到例如对于记录的任何改变，直到提交了该改变。MVCC也消除了
具有其他附加的开销的锁定，并且建立了其中读取操作不能阻挡写入
操作的系统。
除了满足ACID测试之外，现在存在对于针对用户的连续可用性
的要求。一些数据库系统将一个计算机系统专用于事务处理，并且将
另一个专用于决定支持和其他报告处理。它们互连使得可以同时支持
其他功能。随着数据库在大小和复杂度上增大，现有的数据处理系统
被替换为更强大的数据处理系统。用于适应于增长的另一种手段涉及
复制系统，其中，一个机器被指定为“头”机器，其使所有的复制机
器保持同步。如果头机器故障，则处理将那个功能分配给另一个复制
机器。不同的复制机器可用于特定用户。该手段不是可扩展的，因为
所有的机器必须具有相同的能力。
作为另一种手段，可以将多个自治数据库系统整合为单个“联合”
数据库，该单个“联合”数据库具有计算机网络，该计算机网络互连
各个独立的数据库。联合数据库要求“中间件”来将构成的数据库保
持同步。这个“中间件”可以变得很复杂。当数据库大小增大时，操
作中间件所需要的资源可能施加足以使得整体系统性能变差的大的开
销。
“分区”是用于实现数据库的另一种手段，在该数据库中，逻辑
数据库或其构成元素被划分为不同的独立部分。在分布式数据库管理
系统中，每一个分区可以在多个节点上扩展。在给定节点的用户可以
对于该分区执行局部事务。也可以通过形成较小的数据库或通过分割
仅一个表格的选择的元素来实现分区。
对于分区存在两种一般的手段。在也被称为“分片”的水平分区
中，将不同的行置于不同的表格和不同的服务器中。一般，它们具有
特定的共性，诸如邮政编码的范围或按照范围划分为不同表格的姓。
例如，第一数据库可能包括用于在范围A至M中的姓的所有记录；第
二数据库针对在范围N至Z中。作为一种形式的水平分区的分片涉及
将数据库的行定位在分离的服务器上。分片不计算在每一个表格中的
行的数量，并且提高搜索性能。然而，分片在应用级使用散列码，这
使得其太难以实现。它也包含两阶段递交。分片的复杂性使得其适合
于特定应用，因为用于限定分片的基础被良好地限定。
垂直分区包含创建具有较少的列并且在表格上分割列的表格。象
联合数据库那样，垂直分区需要中间件来确定如何将对于特定字段的
任何请求路由到适当的分区。另外，这些系统使用实现起来复杂的两
阶段提交序列。
在被称为“无共享”架构的又一种手段中，每一个节点是独立的
和自给的。无共享架构对于web发展是普及的，因为它可以简单通过
以便宜的计算机的形式添加节点而向上扩展。该手段在数据仓库应用
中是普及的，在数据仓库应用中，更新趋向于比事务处理出现得不频
繁。然而，结合的处理在来自不同分区或机器的大数据集上很复杂。
一些数据库系统被称为“分布式”系统。分布式系统的一种实现
方式包含“簇”和两个通信路径。高速因特网路径在簇之间承载数据。
诸如锁定管理的各种控制功能需要高速专用通信路径。虽然该手段解
决了数据库的冗余和可用性问题，但是锁定管理如前所述可能限制系
统性能。
在“全共享”系统中，超高速的通信使系统保持同步。然而，锁
定管理可能要求大量的带宽资源。为了避免这一点，这样的系统包含
点到点的通信信道和很复杂的盘控制器。
共同地，那些现有技术系统满足对于数据库系统的已知要求的一
些而不是全部。所需的是一种数据库架构，其是可扩展的、满足ACID
属性原子性、一致性、隔离性和持久性。也需要的是一种数据库系统，
该数据库系统在因特网上操作而不需要专用高速通信路径，该数据库
系统提供事务处理并且在大的地理区域上可操作。
发明内容
因此，本发明的一个目的是提供一种弹性的、可扩展的、按需的、
分布式的数据处理系统。
本发明的另一个目的是提供一种弹性的、可扩展的、按需的、分
布式的数据处理系统，该数据处理系统是容错的。
本发明的又一个目的是提供一种弹性的、可扩展的、按需的、分
布式的数据处理系统，该数据处理系统具有高度的可用性。
本发明的再一个目的是提供一种弹性的、可扩展的、按需的、分
布式的数据处理系统，该数据处理系统是独立于平台的。
本发明的又一个目的是提供一种弹性的、可扩展的、按需的、分
布式的数据处理系统，该数据处理系统是原子的、一致的、隔离的和
持久的。
本发明的又一个目的是提供一种弹性的、可扩展的、按需的、分
布式的数据处理系统，该数据处理系统在因特网上操作而不需要专用
的高速通信路径。
本发明的再一个目的是提供一种弹性的、可扩展的、按需的、分
布式的数据处理系统，该数据处理系统提供事务处理，并且适于在大
的地理区域上实现。
根据本发明的一个方面，一种使得用户能够与由数据和元数据构
成的数据库交互的数据库管理系统，包括其间具有通信路径的多个节
点和永久存储器。每一个节点包括在用户级处的高级输入和输出命令
和在系统级处的输入和输出命令之间的接口，在系统级处的输入和输
出命令控制用于与所述数据库交互的操作序列，其中，响应于特定的
系统级命令，原子对象生成原子，每一个原子包含数据或元数据的指
定片断，据此，原子的所有实例集集体地限定在所述数据库中的所有
所述元数据和数据。每一个节点另外包括：用于在所述系统中与每一
个节点建立通信路径的通信控制；响应于来自所述接口的系统命令而
从选择的节点请求与查询相关但是不在那个节点中存在的原子的副本
的方法；响应于来自另一个节点的对于原子的请求而复制请求的原子
以传送到所述请求节点的方法，据此，仅完成查询所需的原子需要在
任何给定的时间位于任何事务节点中；以及，响应于在那个节点处的
原子中的改变而复制那个原子以传送到在那个原子所驻留的系统中的
每一个其他节点的方法。所述永久存储器包含集体地包含在所述数据
库中的所有所述数据和元数据的原子的集合。
根据本发明的另一个方面，一种使得用户能够与由数据和元数据
构成的数据库交互的数据库管理系统，所述系统包括向用户提供对于
所述数据库的访问的至少一个事务节点和维持所述整个数据库的档案
的至少一个档案节点。每一个事务节点包括数据库请求引擎，所述数
据库请求引擎提供在用户级处的高级输入和输出查询命令和在系统级
处的输入和输出命令之间的接口，在系统级处的输入和输出命令控制
用于与所述数据库交互的操作序列，响应于特定的系统级命令，原子
对象生成原子。每一个原子包含数据或元数据的指定片断，据此，原
子的所有实例集集体地限定在所述数据库中的所有所述元数据和数
据。数据库系统网络互连所有的所述节点。在所述节点的每一个中的
通信控制在所述系统中与每一个节点建立通信路径。在每一个事务节
点中的方法响应于来自所述数据库请求引擎的系统命令而请求与查询
建立相关但是不存在于那个节点中的原子的副本。在每一个节点中的
另一种方法响应于来自另一个节点的对于原子的请求而复制请求的原
子以传送到所述请求节点，据此，仅完成查询命令所需的原子需要在
任何给定的时间位于任何事务节点中。在每一个事务节点中的另一种
方法响应于在那个节点处的原子中的改变而将那个改变复制到在包含
那个节点的副本的系统中的每一个其他节点。
根据本发明的又一个方面，一种用于逻辑数据库的数据库管理系
统，所述逻辑数据库由数据记录构成，所述数据记录被组织为要从多
个事务节点访问的表格，所述多个事务节点处理与所述逻辑数据库相
关的事务，其中，所述数据库被解析为片断，其中，每一个片断存储
与所述逻辑数据库相关的所述元数据和/或数据的一部分，以在所述数
据库管理系统中作为串行消息传送，并且存储为非串行的消息。所述
系统包括至少一个档案节点，所述档案节点在永久存储器中以非串行
的形式存储所有的所述片断，由此构成用于所述整个数据库的单个储
藏库。每一个事务节点通过建立用于识别与所述查询相关的片断的低
级命令的序列来响应于来自用户的查询，并且通过获得与在其被处理
的所述查询相关的现有片断的那些副本来响应于所述低级命令，据此，
给定的片断可能位于某个其他节点处或仅位于档案节点处。每一个事
务节点向所述至少一个档案节点和任何改变的片断的副本所驻留的每
一个事务节点复制那个片断，据此，在对等的基础上对于在其他节点
中的片断进行改变，并且据此，任何事务节点仅包含与通过那个事务
节点访问所述数据库的用户作出的查询相关的那些片断。
附图说明
所附的权利要求特别指出和清楚地要求保护本发明的主题。通过
结合附图阅读下面的详细说明，本发明的各个目的、优点和新颖特征
将更充分清楚，在附图中，相似的附图标号指示相似的部分，并且在
附图中：
图1是弹性的、可扩展的、按需的、分布式的数据处理系统的一
个实施例的示意形式的图，该数据处理系统包含具有互连的事务和档
案节点的本发明；
图2描述了事务节点的组织；
图3描述了档案节点的组织；
图4A和4B描述了由在图2和3中所示的原子类生成的“原子”
对象的逻辑组织，所述“原子”对象对实现本发明有用，并且它们可
能在任何给定时间出现在事务节点中；
图5描述了在主目录原子中的信息；
图6描述了在事务管理器原子中的信息；
图7描述了在数据库原子中的信息；
图8描述了在图式原子中的信息；
图9描述了在表格原子中的信息；
图10描述了在表格目录原子中的信息；
图11描述了在索引原子中的信息；
图12描述了在记录状态原子中的信息；
图13描述了在数据原子中的信息；
图14描述了在大二进制对象(Blob)状态原子中的信息；
图15描述了在大二进制对象原子中的信息；
图16描述了在图1的数据库系统的事务和档案节点之间传送的示
例性异步消息的句法；
图17描述了通过其在图1的数据库系统的事务和档案节点之间传
送信息的各种消息类型；
图18是对理解通过其节点加入在图1中的数据库系统的方法有用
的流程图；
图19描述了在节点对象中的信息；
图20是根据本发明的、对理解通过其节点创建原子的方法有用的
流程图；
图21是对理解通过其在图20的方法期间分配唯一的原子标识的
方法有用的流程图；
图22是对理解通过其一个节点从另一个节点获得原子的副本的
方法有用的流程图；以及
图23是对理解通过其本发明提交事务的方法有用的流程图。
具体实施方式
图1描述了弹性的、可扩展的、按需的、分布式的数据库系统30
的一个实施例，该系统具有包含本发明的多个数据处理节点。节点N1
至N6是“事务节点”，它们向数据库提供用户应用访问；节点A1和
A2是“档案节点”，它们用于在每一个档案节点处维持整个数据库的
盘档案。虽然档案节点通常存储整个数据库，但是单个事务节点仅包
含确定支持在那时在那个节点执行的事务所需的数据库的那个部分。
在图1中的每一个节点可以通过数据库系统网络31与在系统中的
其他节点直接地进行通信。例如，节点N1可以与节点N2至N6、A1
和A2中的每一个建立通信路径。在任何两个节点之间的通信是借助于
序列化的消息。在一个优选实施例中，以异步的方式来执行消息传送，
以最大化由系统使用的带宽，由此以及时和迅速的方式来执行各种操
作。通常，数据库系统网络31将用高带宽的、低延迟路径(例如，以
太网)和高带宽的、高延迟的路径(例如，广域网)的组合来操作。
每一个节点具有用于将低延迟的路径的使用限制到时间关键的通信
(例如，获取原子)的能力。高延迟路径可以用于不关键的通信(例
如，请求更新表格的信息)。而且且优选的是，本发明的数据处理网
络包含诸如传输控制协议(TCP)的消息传送协议，并且保证每一个节
点以消息被其他节点发送到该每一个节点的相同顺序来处理消息。
图2描述了代表性的事务节点32，该代表性的事务节点32链接
到数据库系统网络31和各个最终用户33。事务节点32包括中央处理
系统(CP)34，CP 34通过网络接口35与数据库系统网络31进行通信，
并且通过用户网络接口37与各个用户进行通信。中央处理系统34也
与RAM存储器38交互，RAM存储器38包含实现本发明的优选实施
例的数据流管理程序的副本。该程序用于提供远程接口40、数据库请
求引擎41和类和对象的集42。
数据库请求引擎41仅位于事务节点上，并且是在用户级的高级输
入和输出命令和在系统级的系统级输入和输出命令之间的接口。一般
而言，其数据库请求引擎将诸如SQL查询的用户查询解析、编译和优
化为被在集42中的各个类或对象解译的命令。
为了解释本发明的目的，所设定的类/对象集42被划分为“原子
类”的子集43、“消息类”的子集44和“助手类”的子集45。下面
描述这些类的另外的细节。
如将变得显然且根据本发明，在任何给定的时间，事务节点仅包
含与活动的用户应用相关的总的数据库的那些部分。而且，本发明的
各个特征使得在使用中的数据库的所有部分能够驻留在随机存取存储
器38中。不必在这个系统的操作期间在事务节点处提供补充的存储器，
诸如盘存储器。
参见图3，诸如在图1中的档案节点A1或A2的每一个档案节点
50也连接到数据库系统网络31。然而，取代与在图2中的事务节点32
相关联的最终用户33，档案节点仅连接到永久存储器51，该永久存储
器51通常是基于盘的存储系统或键值储藏库。档案节点50包括中央
处理系统54，中央处理系统54通过I/O信道52与永久存储器51进行
通信，并且通过网络接口55与数据库系统网络31进行通信。中央处
理系统54也与RAM存储器57交互，RAM存储器57包含类或对象的
集62。与在图2中的事务节点32类似地，在图3中的类/对象集62包
括“原子类”的集63、“消息类”的集64和“助手类”的集65。
本发明的一个优选实施例使用面向对象的编程(OOP)，其中，
如本领域中已知，例如在图2和3中所示的类和子类限定了方法、数
据结构和进程，通过它们，可以生成那个类或子类的“实例”或对象。
可以使用“继承”和/或“多态变形”来生成“实例”。对于本领域内
的技术人员将变得显然，在具体公开的实施例中不使用面向对象的编
程或变化形式的实现方式是可能的。
现在将以几个阶段来描述本发明。“原子”部分限定了分别由在
图2和3中的原子类43和63产生的对象的等级和功能。“消息”部
分描述了消息集，该消息集在可能分别被在图2和3中的消息类44和
64产生的事务和档案节点之间提供通信。“方法”部分描述了相对于
数据库管理的基本操作。“示例”部分描述了原子、消息和方法的交
互，由此响应于对于数据库请求引擎41的特定数据库查询而实现本发
明的目标。
原子
如前所述，在图2中的原子类43和在图3中的63的每一个产生
“原子”。更具体地，原子类限定了一个或多个“原子类型”或“原
子对象”。每个“原子类型”或“原子对象”产生其本身，也就是“原
子”的“实例”。如在更详细地理解每个特定原子对象的目的的情况
下将变得清楚的，每一个“原子”包含数据库信息的特定片断。一些
原子包含数据库元数据的一部分；其他包含数据记录；其他用作创建
和跟踪其他原子类型的目录。一些“原子类型”可以仅例示复制到所
有节点的一个原子。其他“原子类型”可以例示在按需的基础上被复
制到其他节点的多个原子。
原子具有特定的特性。在事务节点中，原子仅存在于非永久存储
器中，并且具有非串行消息的形式，该非串行消息已经填充了特定的
原子类型以提供用于该原子的有效存储器驻留格式。每一个原子具有
用于将其内容编码为串行消息的装置和用于将串行消息解码以检索原
子的内容的装置。结合如后面将描述的多个操作，使用这样的串行消
息。
从用于复制原子的节点发送的每一个串行消息包括具有附加的节
点标识的那个原子的内容和用于那个节点的最近的事务提交序列号。
当档案节点接收到那个串行消息时，它在将消息(即，原子)的剩余
内容置于永久存储器中之前将该消息去串行化，去除节点列表和提交
序列号。
多个规则适用于根据本发明的原子。那些规则的原因和暗示将变
得更清楚。首先，每一个原子必须具有唯一标识，以在图1中的数据
库处理网络30中的任何位置提供那个原子的可靠标识。其次，任何原
子必须同时存在于两个节点中以维持冗余，除了单个原子在创建单个
原子后并且在档案节点已经请求副本之前可以存在。第三，事务节点
将仅按需来安装原子。第四，每次对于在一个节点中的原子进行改变
时，那个节点必须在“对等”的基础上复制那个改变的原子；即，向
所有的档案节点和仅包含那同一原子的那些事务节点复制那个改变的
原子。
可以在档案和事务节点上出现下面更详细地描述的“垃圾收集”
处理。该处理从事务和档案节点去除不活动的原子，结果，事务节点
可以在那个节点处的随机存取存储器中存储当前与用户应用相关的那
些原子。因此，数据库请求引擎41将整个数据库“看作”局部的，并
且不知道它在多节点环境中操作，并且没有在其节点处的数据库的完
整副本。档案节点具有在原子已经被串行化到盘后清除原子的内容的
选项，由此减小存储所需的存储器的大小。如果档案节点从这样的原
子接收复制消息，则档案节点必须从盘存储器获取内容，然后应用被
复制的来自原子的信息。
在该一般背景下，现在将在“逻辑”或功能级上描述每一个原子
类型。该信息与本发明的操作的进一步的讨论相结合地将使得本领域
内的普通技术人员能够以多种实现方式的任何一种来制造和使用本发
明，所述实现方式包括基于面向对象的编程的实现方式。
图4A和4B描述了数据库引擎41和在任何给定时间可以驻留在
事务节点32中的典型的原子集。在该示例中，事务节点托管主目录原
子70、事务管理器原子71、数据库原子72、图式原子73、表格原子
74和表格目录原子75。每一个数据库仅有一个主目录原子70、一个事
务管理器原子71和一个数据库原子72。当数据库请求引擎41创建新
的数据库时，创建事务管理器原子71、数据库原子72和图式原子73。
参见图4A，主目录原子70跟踪在图1的数据库系统30中的事务
和档案节点的状态。它也可以被看作活动索引，该活动索引创建和监
视事务管理器原子71、数据库原子72、每一个图式原子73、每一个对
应的集的表格原子74和表格目录原子75与序列ID管理器82。
表格目录原子75充当活动索引，并且创建和监视与单个表格相关
联的索引原子76、记录状态原子77、数据原子78、大二进制对象状态
原子80和大二进制对象原子81。也就是，每一个表格有一个表格目录
原子75。
图4B对理解不同的原子类型的交互和管理有用。在该上下文中，
主目录原子70和表格目录原子75都不执行任何管理功能。相对于剩
余的原子，主目录原子70管理每一个图式原子73。每一个图式原子
73管理每一个相关的表格原子74和序列ID管理器82。每一个表格原
子74管理其对应的表格目录原子75、索引原子76、记录状态原子77、
数据原子78、大二进制对象状态原子80和大二进制对象原子81。
仍然参见图4B，数据库请求引擎41与主目录原子70、事务管理
器原子71、数据库原子72、每一个图式原子73、每一个表格原子74
和序列ID管理器82进行通信。数据库请求引擎41充当用于诸如SQL
的高级语言的编译器。作为编译器，它解析、编译和优化查询，并且
从原子获得元数据和数据以形成数据库信息的各个片断。
每一个原子具有特定的公共元素和对于其类型特定的其他元素。
参见图5，主目录原子70包括公共元素70A至70I。元素70A是原子
的唯一标识。因为仅存在向所有节点复制的主目录原子的一个实例，
所以主目录原子ID 70A被给出固定编号，通常为“1”。作为一般规
则，指针70B和70C分别识别主目录原子和创建目录原子。对于主目
录原子，两个指针识别主目录原子本身。
每个原子必须具有主席。主席执行如下所述的功能。元素70D是
指向其中那个原子的主席所驻留的那个节点的指针。
每次在任何事务节点改变原子的副本时，它接收新的改变编号。
元素70E记录那个改变编号。
每当一个节点从另一个节点请求原子时，存在间隔，在该时间间
隔期间，请求的节点将不被其他事务节点知道。元素70F是所有节点
的列表，对于该所有节点，供应节点必须向请求的节点中继来自包含
那个原子的所有其他节点的消息，直到完成了请求。
数据库系统的操作也被划分为循环。循环参考元素70G提供对原
子的最后访问的循环数。元素70H是包含该原子的所有活动节点的列
表。元素70I包括几个状态指示符。
仍然参见图5，全局节点IDS条目70J包含ID管理器，用于对于
在系统中的每一个活动节点分配唯一的标识符。如所知，这样的标识
符是长的字符串。局部节点IDS条目70K包括多达可以附到系统的节
点的总数的数的范围。这些条目一起提供了在两种类型的标识之间的
对应性。局部节点IDS的使用提高了效率。
当事务节点加入在图1中的数据库系统30时，连接管理器70L实
行那个处理。下面描述用于使得事务节点能够加入数据库系统的特定
实现方式。加入节点使用待决节点状态条目70M来指示它没有用于响
应节点的全局地址，直到它从那个响应节点接收到进一步的通信。数
据库UUI条目70N包含数据库的通用唯一标识。
在70P处的条目是重要的，因为它们链接所有的原子，对于该所
有的原子，主目录原子70充当活动索引。如前所述，这些包括数据库
原子72与图式原子73、表格原子74和表格目录原子75中的每一个。
密码条目70Q表示用于认证向数据库内的连接的装置。实际和软
件版本条目70R和70S允许系统当安装软件的较新版本时以反向兼容
来操作。实际软件条目70R识别当时在使用中的软件版本；软件版本
条目70S，与最近安装的版本相对应的数。这允许各个节点被更新到较
新的版本，而不需要更新其他节点，并且不关闭由所有节点访问的数
据库。
仍然参见图5，主目录原子70也包括指向事务管理器原子71的
指针70T、指向配置对象的指针70U、指向垃圾收集线程的指针70V
和指向ping线程的指针70W。ping线程定期地并且独立于在节点处的
其他操作进行操作。它“ping”每一个节点，以提供可以在对应的路径
的通信效率的确定中使用的信息。例如，如果在图1中的节点N1具有
与节点N2或N5进行通信的选项，则节点N1可以在用于那个通信的
到节点N2和N5的通信路径的最有效的选择中使用ping信息。也可以
替代或添加其他选择处理。
参见图6，对于每一个数据库存在一个事务管理器原子71，并且
在创建主目录原子70的同一处理期间创建它。事务管理器原子71响
应于来自数据库请求引擎41的数据库命令来创建、跟踪和结束数据库
事务。事务管理器原子71包括与在主目录原子中的相似元素对应的元
素71A-71I。然而，元素71A是事务管理器原子71的标识。元素71B
和71C都指向主目录原子70。
ID管理器71J提供了唯一的事务序列标识，并且维持活动事务列
表71K、提交的事务列表71L和失败的事务列表71M。元素71N存储
提交序列信息。ID管理器71J在每一个事务的开始处分配事务ID。每
一个事务ID是唯一的，但是不必要的依序的。局部事务管理器原子当
事务提交时向元素71N分配提交序列号。序列号是依序的，并且每一
个特定于请求事务的节点。事务过渡事件计数器71P识别在每一个事
务期间出现的离散事件，诸如事务的开始和事务的成功提交。这样的
计数器当涉及同一信息的多个事务重叠时是有用的。
参见图7，在创建主目录原子70和事务管理器原子71的同时创
建数据库原子72。数据库原子72识别图式原子73中的每一个。数据
库原子72可以涉及当新的用户试图加入数据库时的认证处理。它也可
以包括关于授权级的其他数据。
一般，数据库原子72包括与在图5中的类似元素相对应的元素
72A-72I。元素72A是数据库原子标识。指针72B和72C中的每个识别
主目录原子70。图式名称-图式ID注册表72J将图式名称与图式原子
标识相关。
参见图8，图式原子73创建和跟踪用于那个图式的表格原子。数
据库原子72可以管理多个图式原子，并且每一个图式原子可以与多个
表格原子交互。图式原子73包括与在图5中的元素70A-70I相对应的
元素73A-73I。元素73A是唯一图式原子标识73A，并且元素73B和
73C是指向主目录原子70的指针。表格在图式中具有唯一名称。表格
名称-表格原子ID注册表73J提供了在每一个表格名称和对应的表格原
子之间的对应性。每一个图式序列具有名称。序列名称-序列ID管理器
注册表73K提供了在那些名称和诸如在图4A和4B中的序列ID管理
器82的、与每一个图式原子相关联的对应的序列ID管理器之间的关
系。
图9提供了包含与字段、格式、索引和类型相关的元数据并且管
理那个表格的索引原子76、记录状态原子77和大二进制对象状态原子
80中的每一个的表格原子74的逻辑视图。它也创建和跟踪在表格内的
数据。表格原子74包括与在图5中的元素70A-70I相对应的元素
74A-74I。元素74A包括唯一表格原子标识、元素74B和74C两者指向
主目录原子。指针74J识别对应的表格目录原子。元素74K包含表格
的所有字段的列表。
每一个表格原子具有几个ID管理器。指针74L指向ID管理器，
该管理器向每个字段提供了唯一的标识。指针74M、74N、74P和74Q
识别用于分别向索引原子、数据原子、大二进制对象原子和子类型分
配标识的独立的ID管理器。元素74R是现有子类型的列表。阵列74S
和74T分别提供了记录状态原子和大二进制对象状态的位置。
现在参见图10，对于每一个表格原子有一个表格目录原子。当创
建表格原子时创建每一个表格目录原子75。继而，表格目录原子创建
和跟踪特定于包括索引、记录状态、数据、大二进制对象状态和大二
进制对象原子的一个表格的原子。每一个表格目录原子75包括与在图
6中的元素70A-70I对应的元素75A-75I。元素75A是如由主目录原子
分配的唯一表格目录原子标识。两个元素75B和75C指向主目录原子
70。ID管理器75J提供用于索引、记录状态、数据、大二进制对象状
态和大二进制对象原子中的每一个的唯一原子标识。列表75K识别与
对应的表格原子相关联的所有原子。在元素75L中的指针识别与对应
的表格原子相关联的局部节点处的每一个原子的位置。一系列列表
75M对于每一个原子识别具有那个原子的复制的节点的列表。位图75N
提供了用于当原子在档案节点中时识别其他对象和目录的方便手段。
参见图11，在表格中的每一个索引有一个索引原子76，并且每个
表格可以有多个索引原子。每一个索引原子包括分别与在图5中的元
素70A-70I对应的元素76A-76I。元素76A是如由对应的表格目录原子
分配的唯一索引原子标识。指针76B和76C分别识别主目录原子和表
格目录原子。元素76J包含索引节点的二进制树，以提供传统的索引化
功能。元素76K包含索引级。这样的索引结构和操作是本领域内的技
术人员已知的。
返回图12，记录状态原子77管理用于在单个表格内的固定范围
的记录编号的记录版本和状态。因此，给定的表格原子可以管理多个
记录状态原子。每一个记录状态原子包括与在图5中的元素70A-70I
对应的元素77A-77I。元素77A包括创建表格目录原子分配的记录状态
原子ID。指针77B和77C分别识别主目录和表格目录原子。元素77J
是用于定位由记录状态原子77管理的所有数据原子的阵列。元素77K
包含用于“基本记录”的记录编号。也就是，每一个数据原子存储多
个记录。元素77是指向对应的表格原子的指针。
在本发明针对的数据库应用中，多个用户可以产生同一记录的多
个版本。本发明的优选实施例使用多版本并发控制(MVCC)以通过下
述方式来保证事务从不必须等待数据库：允许记录或其他对象的几个
版本同时存在于数据库中。结果，每一个记录状态原子77包括关于每
一个记录版本的元数据。条目77M是用于识别在垃圾收集中有用的每
一个有版本的记录的位置的位图。
记录状态原子77对于记录的每一个版本77N包括事务ID 77P，
以识别生成版本的事务。格式版本条目77Q识别当插入记录时存在的
表格子类型的版本编号。这个格式识别记录的物理顺序，并且识别在
创建记录版本时在使用中的数据库程序的、记录所属的子类型。元素
77R包括记录版本序列号；元素77S，记录的下一个更旧的或前一个版
本的位置。对于数据原子阵列77J的索引77T和基本记录标识77K一
起提供了在具有记录版本的数据原子中的实际时隙77U的地址。
图13描述了具有与在图5中的元素70A-70I对应的元素78A-78I
的数据原子78。在数据原子78中，元素78A是由表格目录原子分配
的数据原子标识78A。元素78B和78C分别是指向主目录原子和指向
对应的表格目录原子的指针。ID管理器78J对于在数据原子78中的每
一个记录分配记录时隙标识。元素78K对于在数据原子78中的每一个
记录识别那个记录的地址和长度。元素78C表示数据记录和其版本。
现在，参见图14，数据库也存储“大二进制对象记录”。“大二
进制对象记录”通常是在数据库中作为单个实体存储的二进制数据的
集合。大二进制对象记录在版本中不存在。大二进制对象状态原子包
括与在图5中的元素70A-70I对应的元素80A-80I。元素80A具有大二
进制对象状态原子唯一原子标识。元素80B和80C分别是指向主目录
和表格目录原子的指针。列表80J识别由单个大二进制对象状态原子
80管理的所有大二进制对象原子。条目80K提供了基本大二进制对象
记录的标识。元素80L指向对应的表格原子。对于每一个大二进制对
象记录，大二进制对象状态原子包括对于大二进制对象原子的索引
80M。元素80N识别在用于大二进制对象记录的大二进制对象原子中
的时隙。
图15描述了具有分别与在图5中的元素70A-70I对应的元素
81A-81I的大二进制对象原子81。元素81A是由表格目录原子分配的
原子标识。元素81B和81C分别是指向主目录原子和对应的表格目录
原子的指针。ID管理器81J向在大二进制对象原子81中的每一个大二
进制对象分配大二进制对象时隙标识。元素81K对于在大二进制对象
原子78中的每一个大二进制对象识别其地址和长度。元素81L表示向
大二进制对象原子分配的所有大二进制对象记录。
总之，每一个原子具有仅与数据库的片断的关系。例如，数据库
原子72包含识别用于数据库的图式的元数据。每一个图式原子73包
含识别与那个图式相关联的所有表格的元数据。对于每一个表格，表
格原子74和对应的表格目录原子75提供了关于包含诸如字段和它们
的属性的标识的信息的表格的元数据。记录状态原子包括关于一组记
录的元数据。数据原子包括关于每一个数据记录的信息，该每一个数
据记录具有指向包含这些记录和各个版本的时隙的指针。大二进制对
象状态和大二进制对象原子包含关于大二进制对象记录的类似的信
息。
消息
如前所述，在任何两个节点之间的通信是借助于串行化的消息，
该串行化的消息是使用TCP或具有用于维持消息传送序列的控制的另
一个协议来异步地发送的。图16描述了包括可变长度报头91和可变
长度主体92的典型消息90的基本句法。报头91包括指定消息和其功
能的消息标识符代码93。因为本发明设想不同的节点可以使用不同的
软件版本来操作的情况，所以报头91也包括创建该消息的软件版本的
标识94。在报头中剩余的元素包括发送者的局部标识95(即，来自在
图5中的主目录原子)和消息的目的地，即，目录原子的信息96(例
如，在图10中的表格目录ID 75A)和原子标识97(例如，在图12中
的记录状态ID 77A)。从这个信息，接收方节点可以去串行化、解码
和处理该消息。
图17描述了用于本发明的特定实施例的具有图16的句法的消息
集。每一个执行现在将描述的特定功能。
如前简述，当要发送消息时，存在到不同节点的不同通信路径。
例如，如果作为请求节点的一个节点需要获得原子，则那个原子的复
制可以位于多个其他节点中。在这个实施例中，“pinging”提供了对
选择最佳路径对应节点有用的选择信息。如已知，pinging包括确定
“ping”命令到达其目的地和接收到确认消息的时间。在本发明的这个
实施例中，每一个节点定期地使用助手类来向它连接到的其他节点的
每一个发送ping消息110。每个接收节点使用助手类来返回包含ping
时间的ping确认消息111。每个节点在相对于图8下述的节点对象中
累积关于发送和接收这些消息的时间的这个信息。当一个节点准备向
多个节点之一发送消息时，发送节点分析包括但是不限于所累积的ping
数据的因素，以将节点之一选择为用于那个消息的接收节点。
下一个消息集涉及将新的节点连接到在图1中的数据库系统30内
或将先前的不活动节点连接回在图1中的数据库系统30内。当例如事
务节点N2的这样的节点希望连接到数据库系统30时，它启动下面相
对于图19详细描述的连接处理。参见图17，一旦那个处理识别了用于
接收消息的活动节点，则加入节点向所选择的节点发送连接消息112。
所选择的节点向在数据库系统30中的所有其他连接的节点返回欢迎消
息113和新节点消息114。其他连接的节点中的每一个向加入节点发送
其本身的欢迎消息113。当这个消息序列完成时，加入的节点然后可以
进行进一步的步骤以获得各种原子。
档案节点可以当它们与另一个节点同步时在活动模式或同步模式
中操作。在档案节点中的助手类发送节点状态消息115，以向所有其他
节点警告在那个档案节点中的任何状态改变。
当作为请求节点的节点从另一个节点检索原子的副本时，涉及下
一个消息集。例如，在节点加入在图1中的数据库系统30后，它一般
请求主目录原子的副本。结合图20和21的解释更详细地描述了该处
理。
仍然参见图17，请求节点向选择的节点发出对象请求消息116，
该选择的节点通常返回具有请求的原子的对象消息117。所选择的节点
还向具有该原子的所有其他节点发送对象可用消息118。从所选择的节
点接收对象可用消息118的每一个节点向所选择的节点返回对象确认
消息119。在所选择的节点接收到所有的对象确认消息119后，所选择
的节点向请求节点发送对象完成消息120。
在一些情况下，所选择的节点发送对象不可用消息121以声明所
选择的节点已经丢弃了所请求的原子。来自所选择的节点的弹回对象
消息指示在主目录原子或表格目录原子之一中未找到所请求的原子。
这可能出现在当更新事务在进行中并且所选择的节点不响应于对象请
求消息116时，因为垃圾收集处理已经在接收到对象请求消息前收集
了那个原子。作为响应，请求的事务节点可以在具有该原子的数据库
系统中选择另一个节点。
在图1和图4A和4B中的数据库请求引擎41可以定期地生成注
册对象消息123或解除注册对象消息124。这些消息针对包括注册表的
原子，诸如数据库和图式原子。当在节点处的用户发出删除诸如表格
的某个项目的命令时，从那个节点发送对象删除消息125。
每当更新或修改局部节点时，其改变编号递增。每一个复制消息
包含那个原子的本地改变编号。每一个原子跟踪每一个节点的最新的
改变编号。当档案节点接收到修改的原子的副本时，它复制原子的改
变编号，清除改变编号，然后将原子串行化到盘。如果已经进行了改
变，则改变编号将不是零。档案节点发送具有向每一个节点写入的改
变编号的对象写入消息126。每一个接收节点将其自己的改变编号与该
消息中的改变编号进行比较。然后，该节点可以更新原子的状态以注
意原子已经被归档并且是垃圾收集的潜在候选者。
如前所示，每一个原子必须具有唯一的身份。当创建特定原子类
型的第一原子(例如，新的表格原子)时，将创建事务节点指定为那
个表格原子的主席。下面说明用于控制“主席身份”的规则。每当事
务节点需要创建新的原子类型时，如果它没有可用的标识，则它向主
席发送ID请求消息127。主席通常返回ID委托消息128，该消息包括
来自其自由标识值的分配的至少一个唯一标识的块。将相对于图20的
处理来更详细地描述这个处理。
参见图4A和4B，表格原子74可以发送多个消息的任何一个。如
果数据库请求引擎41启动用于添加新的字段的处理，则在那个对应的
事务节点的表格原子生成新的结构，并且发送表格字段添加消息129，
该表格字段添加消息129向包括那个表格原子的所有其他节点复制该
改变。如果事务节点更新了改变表格格式的字段、子类型或字段特性，
则那个节点发出表格格式消息130。每当节点需要创建新的记录状态或
大二进制对象状态原子时，生成表格请求记录消息131。仅主席可以创
建这个原子；并且，当这种情况出现时，主席广播表格记录对象消息
132。
每次事务节点在表格中插入新的记录时，它产生表格记录消息
133。每当变得需要创建新的索引时，如当向表格添加有索引的字段时
那样，创建表格原子复制新的表格原子。此时，将索引设置为仅写入
索引。在已经完成了所涉及的所有相关处理后，节点发送表格索引添
加消息134。
在表格原子创建用于大二进制对象的大二进制对象状态原子的任
何时间，表格原子生成表格大二进制对象对象消息135。表格大二进制
对象消息136指示已经创建了新的大二进制对象。
在利用类型和子类型的数据库中，在图1中的数据库请求引擎41
将生成用于使得表格原子分配新的表格类型标识的命令。当这种情况
出现时，向具有相似的表格原子的所有节点复制表格类型消息137。
表格记录擦除消息138提供了关于特定记录状态原子的记录编
号。当确定在那个表格内的记录包含反向版本或其他准则的异常地长
的链时，表格原子的主席生成表格垃圾收集消息139。结果是“未使用
的”原子被“清空”数据。
在图4A和4B中的记录状态原子77也产生了几个特殊的消息。
如果变得需要更新特定记录，则本发明的数据库管理系统创建那个记
录的新版本。向回参见图17，对应的记录状态原子生成记录更新请求
消息140，记录更新请求消息140被引导到那个原子的主席，以寻求更
新那个特定记录的许可。主席通过生成记录更新响应消息141来响应，
记录更新响应消息141准许或拒绝对于更新那个记录的许可。如果主
席准许许可，则请求记录状态原子执行更新，并且向具有那个原子的
副本的每一个节点发送具有该原子的新版本的记录更新消息142。
数据原子存储多达某个最大数量的记录和其版本。对应的记录状
态原子监视它管理的数据原子的大小。如果记录状态原子确定被管理
的数据原子已经超过那个大小，则它生成新的数据原子，并且借助于
记录数据对象消息143来复制该新的数据原子。
记录状态原子生成记录记录消息144，用于复制任何新的记录版
本。定期地，表格原子主席启动下述处理，通过该处理，记录状态原
子识别比最旧的活动事务更旧的记录版本。当这种情况出现时，主席
的记录状态原子发送记录删除消息145，记录删除消息145使得能够在
随后的垃圾收集处理期间删除那些更旧的记录版本。如果出现其中变
得需要恢复事务的情况，则记录状态原子生成更新撤消记录的撤消记
录消息146。
也存在索引特定的消息集。如所知，索引具有最佳的最大大小；
并且，如果索引超过那个大小，则索引应当被分割。根据本发明，仅
主席可以分割索引原子。主席可以单方面地或响应于来自那个原子的
另一个副本的索引分割请求消息147而如此进行。当主席引起该分割
时，主席生成包含分割索引的索引分割消息148。在该分割后，主席发
送索引删除消息149，以在分割后删截原始索引原子。每次向索引添加
索引节点时，它生成包含索引键、记录标识和新的索引的其他信息的
索引节点添加消息。当已经完全填充索引并且因此索引准备好在检索
操作期间使用时，生成表格索引就绪消息151。如前所示，添加表格索
引生成索引原子，它是仅写入索引并且是不可读的。表格索引就绪消
息151使得这样的仅写入索引是可读的。
大二进制对象状态原子通过生成大二进制对象大二进制对象消息
152来在大二进制对象原子中识别时隙。
数据记录消息153包含时隙编号和记录长度。它也包括数据记录。
当事务的状态改变时，用于给定的事务节点的事务管理器原子71
生成事务状态消息154。这些指示事务的当前状态是在活动状态、提交
前状态、提交状态还是恢复状态中。在特定的情况下，有可能与一个
事务相关的请求将被在另一个节点上的另一个事务阻挡。在那种情况
下，事务管理器原子接收事务阻挡消息155。如果事务被僵持并且必须
被恢复，则与引起僵持的节点相关联的事务管理器原子生成事务僵持
消息156，该消息使得事务恢复。
在档案节点上的主目录或任何表格目录原子可以请求最后写入原
子的时间。这出现在当请求节点发送请求写入时间消息158时。然后，
那个消息的接收方在写入时间消息159中返回那些请求的时间。
前述的消息构成一个集，通过该集，可以正确地处理用于维持包
含本公开的数据库管理系统所需的各种过程。如将显而易见的，每一
个消息具有在报头中的最小开销。每一个消息可以合理地短。当与TCP
或其他消息传送协议一起使用时，必须依序发送所述消息，并且在任
何给定的节点，在接收到时，必须以其中它们甚至被不同的节点发送
的相同顺序来处理它们。
方法
其将对进一步理解描述与本发明的操作的各个方面相关的一些基
本方法的本发明有用。相对于每一个的变化对于本领域内的普通技术
人员将是显而易见的。
图18是当节点加入网络时在图1的数据库系统30中的不同节点
中出现的操作的流程图。为了本说明的目的，假定在图1中的节点5
要加入数据库系统；它被指定为加入的事务节点170。作为第一处理，
加入的事务节点170使用步骤171来与选择的节点建立TPC连接。基
本上，加入的事务节点170向识别数据库的固定位置发送消息。未示
出但是在本领域中已知的连接代理通过拒绝或许可对于数据库系统的
访问来响应于这个请求。如果连接代理许可访问，则它选择诸如事务
节点N1的节点来作为选择的节点172。然后，连接代理向具有选择的
节点172的、作为端口编号的指定的加入的事务节点170发送消息。
图18也将在数据库系统中的所有其他活动事务和档案节点表示为组
173。
一旦在步骤171中建立了连接，则加入的事务节点170使用步骤
174来向所选择的节点172发送连接消息。所选择的节点172通过下述
方式来在步骤175响应于连接消息：使用其连接管理器来更新其主目
录原子，向加入的事务节点170分配局部节点ID，并且向在其节点对
象中的局部节点的阵列增加那个节点，在图19中示出一个示例。
图19描述了诸如结合图18的步骤175描述的节点对象。它包含
指向用于节点的套接字的指针400A和指向在该节点处的主目录原子
的指针400B和指向在主目录原子中的连接管理器的指针400C。指针
400D识别用于收听进入的消息的线程，并且指针400E识别用于接收
消息的套接字缓冲器。该消息收听者等待消息，确定消息类型，然后
处理该消息至完成。
节点对象400如所有的原子那样包括这个节点在收听的节点的全
局节点ID 400F和局部节点ID 400G。元素400H是指向等待要从节点
发送的消息的队列的指针。元素400I和400J包含局部端口和远程端口
的标识。元素400K包含用于在远程节点处操作的软件的版本编号。节
点类型元素400L指示远程节点是事务节点、进行同步处理的档案节点
还是在线的档案节点。
元素400M包含局部节点的名称；元素400N包含远程节点的名称。
元素400P是指向被处理的当前消息的指针。元素400Q和400R识别最
后ping操作的时间和ping时间。如前所示，每一个节点响应于用于在
那个节点处启动的事务的每一个提交操作来生成依序提交序列号。元
素400S包含这个编号。元素400T指示这个节点对象是否是用于这个
节点的节点对象。
向回参见图18，在步骤176处，所选择的节点172向包含全局节
点ID的加入的事务节点170发送欢迎消息。然后，所选择的节点在步
骤177中向所有其他事务和档案节点的组173广播新的节点消息。
在组173中的每一个节点在步骤180通过下述方式来响应于新的
节点消息：记录全局ID，并且分配加入的档案节点的局部ID，并且更
新在它们相应的主目录原子中的所有连接的节点的局部列表。每一个
然后使用步骤181来向加入的事务节点170发送欢迎消息。在完成这
个处理时，加入的事务节点170具有包括所选择的节点172和在组173
中的所有节点的所有活动节点的完全列表。
当加入的事务节点170在步骤182从所选择的节点接收欢迎消息
时，它向所选择的节点172发送对象请求消息(步骤183)，以请求主
目录原子的副本。在所选择的节点172已经更新了在其主目录原子中
的各个信息项后，所选择的节点实现步骤184，以串行化在被发送到加
入的事务节点170的对象消息中的其主目录原子，并且向在系统中的
所有其他节点广播对象可用消息。因此，更新和同步在每一个节点中
的主目录原子。
不用等待对象消息的接收，加入的事务节点也可以开始步骤185
的处理，用于从所选择的节点172检索数据库原子和事务管理器原子
的副本。
接收对象可用消息的每一个其他节点在步骤186中通过向所选择
的节点发回对象确认消息来响应。
在加入节点中的数据库请求引擎启动这个序列。因此，当已经完
成图18的方法时，加入的事务节点170连接到数据库系统，并且如图
4A和4B中所示，包括主目录原子70、事务管理器原子71和数据库原
子72的副本。加入的事务节点170其后将在按需的基础上创建或获得
其他原子的副本。
在一些操作期间，事务节点可能创建新的表格，使得新的表格原
子的创建成为必要。图20公开了处理190，其中，节点A是请求节点，
原子X是请求并且将管理新的原子Y的原子。为了创建新的表格原子
Y，原子X将是图式原子，并且局部目录Z将是主目录原子。步骤191
表示用于获得原子Y的实例的请求的准备功能。每次改变原子时，它
被分配改变编号；初始值通常是“0”。
在步骤192，局部目录Z创建没有内容的原子Y的实例，并且将
局部节点指定为原子Y的主席。然后，处理193允许本地目录Z向新
的原子Y分配对象ID。相对于图21示出和描述了这样的处理的细节。
接下来，局部目录Z设置排他锁定，以允许对于它的改变出现，
而没有来自外部自动化的任何影响。当该锁定在位时，局部目录Z将
新原子Y的状态设置为“肮脏”状态和“非开放”状态。“肮脏”状
态指示新的原子Y还没有被复制到档案。“非开放”状态指示新原子
Y对于其他节点还不可用。在步骤195处，局部目录Z更新其本身，
然后释放该排他锁定。在步骤196处，目录Z向在事务和档案节点中
的目录Z的所有其他实例广播用于识别原子Y的对象可用消息。
在步骤197，作为用于新的原子Y的管理原子的原子X填充原子
Y的实例，并且将原子Y的状态设置为“开放”，用于指示可以复制
该新的原子。其后的某个时间，档案节点将向永久存储器存储该新原
子的副本。也就是，档案节点将通过下述方式来响应于对象可用消息
的接收：请求原子Y的副本，由此提供冗余。当此完成时，来自档案
节点的对象确认消息的接收将使得“肮脏”状态改变，并且这个改变
然后被反映到具有原子Y的副本的所有其他节点。
在用于分配对象ID的本发明的操作的各个阶段中使用在图20中
的分配处理193和相似的分配处理。图21更详细地描述了这个分配处
理。具体地说，当目录原子想要分配对象ID时，在步骤200确定它是
否具有对于它可用的局部ID。如果它具有，则控制转到步骤201，该
步骤响应于请求而分配可用ID。如果局部ID不可用，则控制转到步骤
202，以确定在这个节点处的目录原子是否具有“主席”状态。如果是，
则主席具有用于直接地识别可用ID的授权，并且控制转到步骤201。
如将想起的，当对于特定原子存在至少一个其他节点时，每一个
原子包含包括正被请求的原子的副本的节点的列表。如果这是在已经
根据图20的处理而创建了原子后对于那个原子的第一请求，则在列表
上的第一节点中的对应的目录是主席。步骤203表示选择节点和识别
主席的处理。对于该选择处理，优选的是，首先与事务节点建立通信。
步骤204表示ID请求消息向主席的发送。
当主席在步骤205接收到ID请求消息时，它获得可用ID编号的
块(步骤206)。主席将作出该请求的事务节点识别为可用ID编号的
这个块的地点(步骤207)。然后，主席在步骤210向请求的节点发送
ID委托消息。当请求的节点在步骤211从主席接收到ID委托消息时，
它在步骤212存储ID编号的块，然后在步骤201中选择用于分配的第
一可用ID。向回参见图20，在该情况下，处理193从步骤200至步骤
202直接地转到步骤201，因为在图20的步骤192中指定了主席。
每当在图4A和4B中的数据库引擎41作出对于原子的请求时，
处理在图22中的响应220。例如，假定在请求节点221中的数据库请
求引擎41从具有其他节点223的数据库中的选择的节点222请求原子
Y(例如，表格原子)的副本。当数据库请求引擎41作出那个要求时，
步骤224确定是否在请求节点221中存在原子Y。如果是，则步骤225
结束该处理，因为存在被请求的原子。如果否，则控制转到步骤226，
据此，局部目录Z创建原子Y的空实例，并且将原子Y声明为“未填
充”。如果数据库引擎41正请求表格原子74，则主目录原子70将执
行这个步骤。步骤230然后使用前述的选择处理来识别选择的节点222。
偏好是在将最具响应性的档案节点选择为选择的节点222之前选择事
务节点中的任何一个。
在步骤231中，请求节点221向所选择的节点222发送用于原子
Y的对象请求消息。作为响应，所选择的节点222使用步骤232来以
具有节点和序列号的其串行化形式来发送具有被请求的原子Y的对象
消息。
同时，所选择的节点222向所有其他节点223广播对象可用消息。
它也对于具有原子Y的副本的所有其他节点创建中继器列表。在处理
中的该点处，其他节点不与在请求节点中的原子Y直接地进行通信，
因为它们不知道它们应当向请求节点发送用于那个原子的复制消息。
因此，当其他节点中的任何一个复制其原子Y时，所选择的节点222
将向请求节点221中继该消息。
当请求节点221从所选择的节点222接收到对象消息时，它在步
骤233进行消息的可访问性分析。如果消息包含当前的原子，则原子Y
在步骤236处理该消息，并且在步骤237向所选择的节点发送对象确
认消息。
所有其他节点223使用步骤240来通过向所选择的节点222发送
对象确认消息而响应于对象可用消息。所选择的节点222使用步骤241
来监视该对象确认消息。具体地说，它响应于每一个对象确认消息而
从其中继器列表去除其他节点中的每一个，并且停止向那个节点的中
继。当已经从列表去除了所有其他接收223时，所选择的节点停止所
有的中继，并且广播对象完成消息。
另一个节点有可能在图22中的步骤226和236之间的时间期间发
送到达请求节点221的复制消息。这可以中断消息处理。结果，当在
未填充原子Y的同时在请求节点处接收到在上面的实例中的用于原子
Y的复制消息时，它被置于作为每一个原子的一部分的待决消息列表
中，虽然在图5至13的任何一个中未示出。
如前所示，本发明特别适于与事务处理技术对接的数据库。就此
而论，应当包含用于“提交”消息的适当手段。图23描述了保证在这
样的环境中的数据的一致性的一种手段。具体地说，图23描述了四个
节点，即：事务节点A 250、事务节点B 251、事务节点C 252和档案
节点253。假定事务节点B251在步骤254发送具有由在那个节点的事
务管理器原子供应的事务ID的提交前消息。该消息在步骤255被路由
到档案节点。当已经完成用于提交那个事务的所有条件时，档案节点
255在步骤256发出提交事务消息，并且在步骤257，广播那个提交消
息。事务节点的每一个在步骤258作为响应来更新其对应的事务编号。
如先前相对于在图21中的用于请求原子的副本的处理所描述的，
请求的节点在步骤233对于任何接收到的消息执行访问性分析。这个
测试提供了任何事务节点总是用有效的信息来操作的保证，并且涉及
事务ID编号和提交序列号的分析。通过进一步理解事务ID和提交序
列号，通过分析事务的相对顺序以及通过理解“原子偏斜”，将便利
这个分析和本发明的其他特征的理解。
相对于事务ID和提交序列号，并且如前所述，每一个事务标识符
在图1的整个数据库系统上是唯一的。事务ID的目的是唯一的、永久
的、系统范围的标记，用于指示哪个事务创建了特定的记录版本。每
一个事务ID被事务管理器原子71的局部副本分配，并且一个这样的
事务管理器原子将是主席，该主席向在数据库系统中的每一个事务节
点上的事务管理器原子分配标识符编号的块。在给定的事务节点处的
事务管理器原子按顺序向那个接收开始的每一个事务分配在分配的块
中的未使用的编号。结果，在给定节点处开始的较新的事务的事务ID
可以比向在那同一节点上开始的更旧的事务分配的事务ID更高。然而，
在系统范围的基础上，事务ID不暗示关于不同事务的相对开始时间的
任何内容。
结果，必须提供某种方法来保证：只有在读取事务开始之前已经
提交了创建记录版本的事务时，事务才可以读取该记录版本。在本发
明中，用于确定要读取哪个记录版本的这样的方法是用于创建记录版
本的事务的事务提交时间，而不是开始时间。事务ID不包含其提交时
间，因此在每一个节点上的事务管理器原子基于实际提交操作来向每
一个事务分配提交序列号。每一个事务节点以增大的序列来生成其提
交序列号。如果来自给定节点的事务具有提交序列号467，则来自具有
较低的提交序列号的节点的所有事务确信已经被提交。所有节点生成
相同的提交序列号，因此解译该编号需要对应的节点的编号和标识。
当事务提交时，其事务管理器原子向包括对应的事务ID和提交序
列号的所有节点发送提交消息。当原子串行化其本身时，它包括它已
经从拥有那个原子的副本的每一个节点看到的最高的提交序列号。例
如，假定节点A、B和C包含原子Z的副本并且那个节点A生成用于
原子Z的对象消息。那个消息的串行化形式将包括节点A已经从其本
身看到的最高提交序列号和它已经从节点B和C看到的最高的提交序
列号。来自节点A的串行化的消息描述了当节点A看到共享原子Y的
副本的所有节点时在该所有节点上的事务的状态。有可能节点B或节
点C可以实际上已经发出了用于节点A还没有接收或处理的事务的较
高的提交序列号。
在每一个节点上的事务管理器在数据库系统中维持每一个节点的
事务对象。每一个事务对象反映在所有节点上的事务的状态，并且向
每一个对象分配局部的和连续的增大的两个或更多的编号。当事务管
理器原子开始事务或接收到指示另一个节点已经开始事务的事务过渡
消息时，事务管理器原子创建具有新的事务ID的局部事务对象，并且
向其分配开始编号。当局部事务提交时或当事务管理器原子接收到指
示已经提交了在另一个节点上的事务的事务过渡消息时，与提交序列
号一起向事务对象分配事务结束编号。开始和结束编号来自同一序列。
作为示例，如果事务123具有比事务453的结束编号高的开始编号，
则事务123可以从执行事务453的任何节点读取由事务453创建的记
录版本。
事务开始和结束编号是局部的；也就是，它们反映如在局部节点
上看到的事务的状态。不同的节点分配不同的值，并且看到在其他节
点上的事务的不同排序。如将显而易见的，可以在接收中和在处理事
务状态消息中存在延迟。每一个事务仅在其局部的事务节点上运行。
这个数据库系统防止一个事务节点“看到”如在事务在其局部事务节
点上提交之前提交的事务。例如，如果节点A在从用于事务453的事
务节点B接收和处理提交消息之后开始事务123，则事务123可以从事
务453读取改变，即使接收到事务的事务节点C以另一个顺序提交和
开始消息并且将两个事务看作同时期的。
当没有事务在事务节点C上运行时，信息不与事务节点C相关。
然而，在每一个单独事务节点的数据库系统的视图之间的差在特定情
况下可能引起问题。
相对于“原子偏斜”，根据本发明的一个方面，每一个节点必须
以另一个节点发送消息的顺序来处理来自该另一个节点的消息。然而，
所有节点独立地操作。因此，在任何给定的时间，一些节点将已经接
收和处理了其他节点还没有处理的消息。原子的一些副本将包括其他
副本没有的改变。那些差别不影响具有副本的任何节点，因为原子的
每一个副本处于那个节点的一致状态中。如前所述，每当事务节点改
变原子时，该节点向包含那个原子的副本的所有其他节点复制改变的
原子。如果事务节点B和C每一个包含那个原子的副本并且事务节点
B改变那个原子，则事务节点B向事务节点C发送复制消息。在事务
节点B正处理事务的同时，它向事务节点C发送事务状态消息，并且
复制事务节点B改变的任何原子。当事务节点B通过在图23中所示的
处理来提交事务时，事务节点C应当已经接收到用于指示已经提交了
事务的事务状态消息。事务节点C将处理与事务相关的所有消息，然
后它因为下述情况而接收提交消息：所有的消息将以它们被发送的顺
序被处理。在不同的事务节点上的原子的副本可以不同，但是由在任
何事务节点上的事务进行的所有改变将在每一个其他节点上，然后该
其他节点将该事务看作被提交。
当观看来自系统级的事务时，不同的事务节点不同步地行动。单
个消息正被不同节点处理的时间可以因为在通信路径的效率和每一个
事务节点需要处理的消息的数量上的差别而变化。必须考虑在不同节
点处的处理时间上的差别。考虑三个事务节点：节点A、节点B和节
点C。假定节点B执行改变原子X的事务768并且节点C具有原子X
的副本。假定在节点B处的原子X向节点C发送改变消息，并且在节
点C处理那些改变之前有一些时间过去。也假定节点B已经向事务768
分配了提交序列号47。在节点B上的事务管理器原子向在数据库系统
中的所有节点发送事务状态消息。也假定节点A在从节点B接收到提
交消息之后但是在节点C完成处理事务之前从节点C请求原子X的副
本。节点A从节点B接收和处理事务状态消息。从节点A的视角看，
事务768被提交，并且用于节点B的最高提交序列号是47。然而，对
于这个定时，从节点C返回的原子不反映由节点B处的事务作出的改
变。
根据本发明，当在节点C上的原子X串行化其本身以发送到节点
A时，它包括来自具有原子X的副本的每一个节点的最高提交序列号。
在该情况下，假定消息将包括用于节点C的提交序列号97和用于节点
B的提交序列号46。
参见图22，作为请求节点的节点A创建了原子X的空实例，然后
向节点C请求其内容。在图22中的访问性分析获得如节点A看到的每
一个节点的当前最高提交序列号。它也用原子X来扩展串行化的消息，
以获得如节点B看到的每一个节点的当前最高提交序列号。在这个比
较中，访问性分析将确定在消息中的串行化的提交序列号是46，而用
于B的其局部最高提交序列号是47。因此，节点B不能使用在其当前
状态中的原子X的串行化版本，并且必须等待在节点C上的原子X以
向其发送对象完成消息。如果提交序列号是相同或更大的，则节点A
可以继续处理原子。
如前所述，当节点C向节点A发送原子X的串行化副本时，它发
送针对原子X的其他副本的对象可用消息，在该情况下是针对节点B
上的副本的对象可用消息。在节点B上的原子X向在节点C上的原子
X发送对象确认消息，并且向其本身的副本列表添加在节点A上的副
本。其后，在节点B上的原子X将发送针对两个节点A和C上的其副
本的改变消息。同时，在节点C上的原子X处理来自节点B的消息，
将它们中继到节点A。在节点A上的原子X处理消息，使得其本身越
来越最新。当在节点C上的原子X处理来自在节点B上的原子X和在
其他节点上的原子X的所有其他副本的对象确认消息时，它发送针对
在节点A上的原子X的对象完成消息。
根据本发明，每一个事务节点应当操作而不必向盘或其他永久存
储器传送任何原子。这要求以迅速的方式从每一个事务节点去除不活
动的原子。未了实现这个目标，在每一个节点中的助手类定期地提供
由循环管理器调用的垃圾收集功能，以独立于其他操作而启动新的垃
圾收集循环。更具体地，循环管理器执行老化循环，据此，在前一个
循环中参考的任何原子被移动到在用于那个节点的主目录原子中的最
近最少使用(LRU)列表上的前面。循环管理器获得排他锁定，以保
证没有其他的线程相对于前一个循环是活动的。
循环管理器然后开始用于对于记录垃圾收集标记的表格原子的
记录垃圾收集线程。如果在节点处的存储器的当前量超过由在图5处
的指针70U识别的配置对象限定的指定量，则垃圾收集线程处理通过
主目录LRU从最近最少使用到最近最多使用的原子进行循环。如果那
个原子(1)不活动，(2)已经在当前的老化循环中被参考，(3)不
是“对象不完成”原子，(4)已经被局部改变并且还没有被写入档案
节点，并且(5)是没有存储器驻留原子的目录，则它将原子分类为垃
圾收集候选者的候选者。在档案节点中的原子另外必须还没有被串行
化到盘。
如果垃圾收集处理确定已经满足了所有前述的条件，则存在两个
选项。如果节点是档案节点并且存在在其他节点处的原子的其他实例，
则原子的内容被“清除”。否则，请求原子丢弃其本身，它通过首先
查看其创建的目录原子以进行最后测试来如此进行。如果通过那个测
试，则目录原子清除指向向包含候选原子的实例的其他节点广播对象
不可用消息的候选原子的其指针，然后删除其本身。这个循环逐个原
子地继续，直到工作存储器在可接受的限度内。
两种机制涉及这个处理。当请求目录原子找到用于分类的原子时，
目录原子将其循环参考条目设置为当前循环编号。另外，事务管理器、
数据库、图式、序列和表格原子在当前循环上获得共享锁定，使得在
那些原子中的方法可以持有原子指针，而不必递增原子使用计数，以
防止对象或原子被垃圾收集。
图19和20描述了“主席身份”。如图20中所示，当创建原子时，
将创建的节点指定为原子主席，并且建立用于该原子的节点的有序列
表。当节点创建原子时，它是在有序列表中的仅有的条目。在列表中
的第一节点是主席。
当另一个节点后来请求那个原子的副本时，所选择的节点将请求
节点的标识布置在该有序列表中刚好在其本身之后，而不论它是否是
主席。结果，如果被指定为用于任何原子的主席的节点因为任何原因
而变得不活动，则那个原子的每一个其他副本具有节点的有序列表。
通过该有序列表，下一个主席是在列表上的第一剩余事务节点。如果
在列表上没有事务节点，则指定第一非同步档案节点。
讨论简单的数据库查询现在可能对于帮助理解在不同节点和节点
内的原子之间的交互是有用的。假定在事务节点处的数据库请求引擎
接收到数据库查询以选择在具有邮政编码“01944”的表格“成员”中
的所有记录。假定事务管理器原子和表格原子位于局部节点处，已经
完成了所有的查询处理，并且对于在“成员”表格中的“邮政编码”
字段存在索引原子。
初始，在图2中的数据库请求引擎41向事务管理器发出命令以开
始新的事务，此时，事务管理器原子分配事务ID。接下来，数据库请
求引擎利用用于“成员”表格的表格原子来确定是否对于“邮政编码”
字段存在索引原子。如果这两个原子在局部节点处，则它们被处理。
如果它们不在局部节点处，则从其他节点获得这些原子的副本，然后
处理继续。
用于“成员”表格的表格原子利用来自对应的表格目录原子的信
息来扫描索引。这产生了位图，该位图识别在具有指定的邮政编码的
“成员”表格中的每一个“记录”。如将显而易见的，这个位图可以
限于特定字段或可以是来自多个字段的索引的逻辑组合的结果。
接下来，基于所得到的位图来建立循环。对于该循环的每一次迭
代，数据库请求引擎向表格原子发出调用，以处理用在记录中的事务
ID指定的获取记录方法。表格原子通过下述方式选择与记录原子相关
的适当的记录状态原子：将记录编号除以与记录状态原子管理的记录
ID的最大数对应的固定数。接下来，表格原子使用事务ID和识别的记
录编号来在所选择的记录状态原子中使用获取方法。对于多版本记录，
记录状态原子循环通过任何记录版本，以找到正确的版本和指向对应
的数据原子的适当指针。记录状态原子用指向记录的数据原子编号来
调用那个数据原子，并且允许其检索。当完成这个处理时，数据库请
求引擎向用户提供列出了具有指定的邮政编码的所有记录的记录集。
总之，对于本领域内的普通技术人员将显而易见的是，根据本发
明构造的数据库管理系统提供了弹性的、可扩展的按需分布的数据处
理系统。该系统是容错的，并且具有高度的可用性。它是独立于平台
的，并且操作成提供弹性的、一致的、隔离和耐久的数据库。而且，
它可以在因特网上操作，而不需要高速通信路径，并且适于可以在宽
的地理区域上实现的事务处理。
本发明通过实现下面的特征的一个或多个来实现所有这些目的。
本发明将数据库划分为在对等基础上复制的分布式对象。每一个事务
和档案节点确定哪些原子要在局部的基础上驻留在存储器上。目录原
子跟踪到各个原子的局部和远程副本的位置，并且识别它们是其成员
的目录。而且，每一个节点可以确定多个节点的最佳者，从该最佳者
请求启用地理上分散的系统的原子的副本。
已经以特定的实施例公开了本发明。将显而易见的是，在不偏离
本发明的情况下可以对于所公开的设备进行许多修改。因此，所附的
权利要求的意愿是覆盖在本发明的真实精神和范围内的所有这样的变
化和修改。