事务定序的制作方法
【专利说明】事务定序
【背景技术】
[0001] 分布软件堆栈的各种组件在一些情况中能够提供（或支持）故障容忍（例如，通 过复制）、更高的持久性和更低成本的解决方案（例如，通过使用多个较小且成本较低的组 件，而不是较少的大且昂贵的组件）。但是，数据库从历史来看一直是软件堆栈的组件中最 不适于分布的。例如，分布数据库同时确保预期数据库所要提供的所谓的ACID属性（例如， 原子性、一致性、隔离性和持久性）可能是困难的。具体地来说，就一致性和隔离性属性而 言，分布式数据库系统的节点之间进行协调以维持节点间的逻辑关系已被证明对于现有系 统是非常困难的。
【附图说明】
[0002] 图1是图示根据一个实施方案的数据库软件堆栈的各种组件的框图。
[0003] 图2是图示根据一些实施方案的服务系统架构的框图，该服务系统架构可以被配 置来实施被配置来执行事务定序的基于Web服务的数据库服务。
[0004] 图3是图示根据一个实施方案的被配置来执行事务定序的数据库系统的各种组 件的框图。
[0005]图4是图示根据一个实施方案的被配置来执行事务定序的分布式数据库优化的 存储系统的框图。
[0006]图5是图示根据一个实施方案的被配置来执行事务定序的数据库系统中使用单 独的分布式数据库优化的存储系统的框图。
[0007] 图6是图示一种用于事务定序的方法的一个实施方案的流程图。
[0008] 图7A-C是图示根据各种实施方案的各种事务定序场景的时序图。
[0009]图8是图示根据各种实施方案的被配置来实施事务定序的计算机系统的框图。 [0010] 虽然本文通过若干实施方案和说明性附图的实例描述了实施方案，但是本领域技 术人员将认识到实施方案不限于所描述的实施方案或附图。应当理解附图以及对其进行的 详细描述并不旨在将实施方案限制于所公开的特定形式，而是相反，旨在涵盖落在如所附 权利要求所定义的精神和范围内的所有修改、等效物和替代物。本文使用的标题仅出于组 织的目的，而不意味着用于限制描述或权利要求的范围。如在本申请全文中所使用的，词汇 "可以"是在容许意义（即，意味着有可能）上来使用的，而非强制意义（即，意味着必须）。 词汇"包括（include,including,includes) "是指开放性关系且因此表示包括但不限于。 相似地，词汇"具有（have，having，has) "也是指开放性关系且因此表示具有但不限于。如 在本文中所使用的，术语"第一"、"第二"、"第三"等用作其在前的名词的标号，并且不暗示 任何类型的定序（例如，空间、时间、逻辑等），除非以其他方式明确地指示此类定序。
[0011] 各种组件可能被描述为"被配置来"执行一个或多个任务。在此语境中，"被配置 来"是一种广义的引述，一般性地表示在操作期间"具有执行该一个或多个任务的结构"。因 此，该组件能够被配置来执行任务，即使是该组件当前未在执行该任务（例如，即使在操作 当前未被执行时，计算机系统仍可被配置来执行该操作）。在一些语境中，"被配置来"可 以是一种结构的广义的引述，一般性地表示在操作期间"具有执行该一个或多个任务的电 路"。因此，该组件能够被配置来执行该任务，即使是该组件当前未导通。一般来说，形成"被 配置来"所对应的结构的电路可包括硬件电路。
[0012] 为了方便描述，各种组件可被描述为执行一个或多个任务。此类描述应解释为 包括短语"被配置来"。引述被配置来执行一个或多个任务的组件明确地无意援引35U. S.C. § 112第六段落对该组件的解释。
[0013] "基于"，如在本文中所使用的，此术语用于描述影响确定的一个或多个因素。此术 语不排斥可能影响确定的附加因素。即，确定可仅基于这些因素或至少部分地基于这些因 素。对于短语"基于B确定A"。虽然B可以是影响A的确定的因素，但是此类短语不排斥 A的确定还基于C。在其他实例中，可仅基于B来确定A。
[0014] 本公开的范围（明确地或隐含地）包括本文公开的任何特征或该特征的组合，或 其任何推广，无论其是否缓解了任何或所有本文解决的问题。因此，在本申请（或对其要求 优先权的申请）对任何此类特征组合诉求权利的过程中可构想出新的权利要求。特定来 说，参考所附权利要求，可将来自从属权利要求的特征与独立权利要求的特征进行组合，并 且可将来自各个独立权利要求的特征以任何适合的方式而不仅仅以所附权利要求中枚举 的具体组合来进行组合。
【具体实施方式】
[0015] 公开事务定序的各种实施方案。本实施方案中的各种实施方案可以包括接收执行 读存储的记录的读请求和执行对所述记录的事务（例如，写入等）的事务请求的节点（例 如，数据库服务的节点）。本实施方案中的各种实施方案还可以包括分别将第一和第二时间 指示与读和事务关联的节点。本实施方案中的各种实施方案还可以包括至少部分地基于所 述第一时间指示在所述第二时间指示的阈值内的确定来检测潜在的读异常（例如，不可重 复读（fuzzyread)、读偏斜（readskew)等）。注意，在一些实施方案中，检测还可以基于 所述第一和第二时间指示以外的时间指示。响应检测到所述潜在的读异常，可以在所述事 务请求指定的事务之后执行所述读，而无论所述第一时间指示是否指示比所述第二时间指 示早的时点。在一些实例中，可以重试所述读，以使对于所述重试不会出现潜在的读异常。
[0016] 说明书首先描述被配置来实施所公开的事务定序技术的示例性基于Web服务的 数据库服务。示例性基于Web服务的数据库服务的描述中包括的有，示例性基于Web服务 的数据库服务的多个方面，如数据库引擎和单独的分布式数据库存储服务（注意，在一些 实施方案中，存储服务可以不与数据库引擎分开）。说明书随后描述用于事务定序的方法的 各种实施方案的流程图。接下来，说明书描述可以实施所公开的技术的示例性系统。说明 书全文中提供了各种实例。注意所公开的事务定序技术可以用在图1-5的示例性数据库服 务以外的系统中，如可以用在可用于读、写和存储数据的其他系统中。例如，所公开的技术 可以用在可能出现如下情况的任何系统中：在这些更新对于读是可见的时点读数据并且对 数据进行一系列更新。
[0017] 在一些实施方案中，本文描述的系统可以实施使客户端（例如，订户）能够在云计 算环境中操作数据存储系统的Web服务。在一些实施方案中，所述数据存储系统可以是高 度可伸缩并且可扩充的企业级数据库系统。在一些实施方案中，可以将查询指向跨多个物 理资源分布的数据库存储，并且可以基于所需来扩大或缩小该数据库系统。在不同实施方 案中，该数据库系统可以有效地使用各种类型和/或组织的数据库方案。在一些实施方案 中，客户端/订户可以采用多种方式，例如经由SQL接口交互式地，将查询提交到该数据库 系统。在其他实施方案中，外部应用和程序可以使用开放数据库连接性（ODBC)和/或Java 数据库连接性（JDBC)驱动程序接口将查询提交到该数据库系统。
[0018] 更具体地来说，在一些实施方案中，本文描述的系统可以实施其中内在地分布单 个数据库系统的各种功能组件的面向服务的数据库架构。例如，这些系统可以将数据库的 基本操作（例如，查询处理、事务管理、缓存和存储）组织成可以个别且独立地缩放的层，而 不是将多个完整且庞大的数据库实例（其中的每一个可能包括无关的功能性，如应用服务 器、搜索功能性，或需要提供数据库核心功能以外的其他功能性）绑在一起。例如，在一些 实施方案中，本文描述的系统中的每一个数据库实例可以包括数据库层级（其可以包括单 个数据库引擎头节点和客户端存储系统驱动程序）以及单独的分布式存储系统（其可以包 括统一地执行现有技术系统的数据库层级中传统上执行的一些操作的多个存储节点）。正 如本文提到的，所描述的事务定序技术也可以等效地应用于其他系统。
[0019] 正如本文更详细描述的，在一个实施方案中，可以将一些最低级别的数据库操作 (例如，备份、复原、恢复、日志记录操作和/或各种空间管理操作）从数据库引擎转移到存 储层以及跨多个节点和存储设备来分布。例如，在一些实施方案中，应用对所存储的数据库 表（以及其数据页）的更改可以由存储层本身来负责，而不是数据库引擎应用对数据库表 (或其数据页）的更改并且随后将修改的数据页发送到存储层。在此类实施方案中，可以 将重做日志记录而非修改的数据页发送到存储层，此后，可以有所延迟地且以分布式方式 (例如，通过后台进程）执行重做处理（例如，应用重做日志记录）。在一些实施方案中，崩 溃恢复（例如，根据所存储的重做日志记录重构数据页）还可以由存储层来执行，并且还可 以由分布式（并且在一些情况中，延迟的）后台进程来执行。
[0020] 在一些实施方案中，因为仅重做日志（而非修改的数据页）被发送到存储层，所以 数据库层级与存储层之间的网络通信量与现有数据库系统中的网络通信量相比可极大地 减少。在一些实施方案中，每一个重做日志可以约为对其指定更改的对应数据页的大小的 十分之一。注意，从数据库层级和分布式存储系统发送的请求可以是异步的，并且一次可能 有多个此类请求处于传送中。
[0021] -般来说，在给出一个数据之后，数据库的初级要求是其可以最终归还相同的一 个数据。为此，数据库可以包括若干不同的组件（或层级），其中的每一个执行不同的功能。 例如，传统数据库可以视为具有三个层级：用于执行查询解析、优化和执行的第一层级；用 于提供事务性、恢复和持久性的第二层级；以及提供在本地连接的磁盘上或网络连接的存 储上的存储的第三层级。正如上文提到的，伸缩传统数据库的传统尝试通常涉及复制数据 库的所有三个层级并跨多个机器分布这些复制的数据库实例。
[0022] 在一些实施方案中，本文描述的系统可以与传统数据库不同的方式将数据库系统 的功能性分区，并且可以仅跨多个机器分布这些功能组件的子集（而非完整的数据库实 例）以便实施伸缩。例如，在一些实施方案中，面向客户层级可以被配置来接收指定要存储 或检索什么数据的请求，而非指定如何存储或检索该数据的请求。此层级可以执行请求解 析和/或优化（例如，SQL解析和优化），而另一个层级可以负责查询执行。在一些实施方案 中，第三层级可以负责提供事务性和结果的一致性。例如，此层级可以被配置来实施所谓的ACID属性中的一些，特定来说，以该数据库为目标的事务的原子性、维持该数据库内的一致 性以及确保以该数据库为目标的事务之间的隔离性。在一些实施方案中，第三层级可以实 施所公开的事务定序技术。在一些实施方案中，第四层级则可以负责在存在各种类型故障 的情况下提供所存储数据的持久性。例如，此层级可以负责更改日志、从数据库崩溃恢复、 管理对底层存储卷的访问和/或底层存储卷中的空间管理。
[0023] 现在转到附图，图1是图示根据一个实施方案的数据库软件堆栈的各种组件的框 图。正如此实例中图示的，数据库实例可以包括多个功能组件（或层），其中的每一个提供 数据库实例功能性的一部分。在此实例中，数据库实例1〇〇包括查询解析和查询优化层（示 出为110)、查询执行层（示出为120)、事务性和一致性管理层（示出为130)和持久性和空 间管理层（示出为140)。正如上文提到的，在一些现有数据库系统中，伸缩数据库实例可能 涉及一次或多次复制整个数据库实例（包括图1所示的所有层），并且随后添加胶合逻辑 (gluelogic)将其缝合在一起。在一些实施方案中，本文描述的系统可替代地将持久性和 空间管理层140的功能性从数据库层分担到单独的存储层，并且可以跨存储层中的多个存 储节点分布该功能性。注意所公开的事务定序技术还可以应用于持久性和空间管理层140 是数据库层级一部分的实施方案中。
[0024] 在各种实施方案中，本文描述的数据库可以支持用于各种数据库操作/事务的标 准或定制应用编程接口（API)。例如，该API可以支持用于创建数据库、创建表、更改表、创 建用户、删除用户（droppingauser)、在表中插入一个或多个行、复制值、从表内选择数据 (例如，查询表）、取消或中止查询的操作和/或其他操作。
[0025] 在一些实施方案中，数据库实例的数据库层级可以包括数据库引擎头节点服务器 (其还可称为主节点），数据库引擎头节点服务器从各种客户端程序（例如，应用）和/或 订户（用户）接收读和/或写请求（和/或其他事务请求），然后解析它们并设计执行计划 来执行关联数据库操作。例如，数据库引擎头节点可以开发获取复杂查询和连接结果所需 的一系列步骤。在一些实施方案中，数据库引擎头节点可以管理数据库系统的数据库层级 与客户/订户之间的通信，以及数据库层级与单独的分布式数据库优化的存储系统之间的 通信。在一些实施方案中，正如下文更详细描述的，该数据库引擎头节点可以被配置来执行 事务定序，这可以帮助维持特定的隔离级别（例如，读一致等）。<