CN111433764B - 全局一致分片式oltp系统的高吞吐量分布式事务管理及其实现方法 - Google Patents

全局一致分片式oltp系统的高吞吐量分布式事务管理及其实现方法 Download PDF

Info

Publication number
CN111433764B
CN111433764B CN201880078365.2A CN201880078365A CN111433764B CN 111433764 B CN111433764 B CN 111433764B CN 201880078365 A CN201880078365 A CN 201880078365A CN 111433764 B CN111433764 B CN 111433764B
Authority
CN
China
Prior art keywords
transaction
snapshot
slice
dxid
global
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
CN201880078365.2A
Other languages
English (en)
Other versions
CN111433764A (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.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
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 Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Publication of CN111433764A publication Critical patent/CN111433764A/zh
Application granted granted Critical
Publication of CN111433764B publication Critical patent/CN111433764B/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
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/951—Indexing; Web crawling techniques
    • 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/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G06F16/278—Data partitioning, e.g. horizontal or vertical partitioning
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1448—Management of the data involved in backup or backup restore
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1458—Management of the backup or restore process
    • G06F11/1464—Management of the backup or restore process for networked environments
    • 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/23—Updating
    • G06F16/2379—Updates performed during online database operations; commit processing

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • Quality & Reliability (AREA)
  • Computing Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本发明实施例提供了一种用于改进分片式数据库中的联机事务处理(online transaction processing，OLTP)的系统和方法，判断进入的查询是单分片事务还是多分片事务能够降低全局事务管理器相关开销，提高了可扩展性。对于多分片事务，向所述GTM请求分布式事务ID(distributed transaction ID，DXID)，然后将所述DXID和所述查询转发给一个或多个数据节点。对于单分片事务，将所述查询发送给数据节点，不需要向GTM请求DXID。

Description

全局一致分片式OLTP系统的高吞吐量分布式事务管理及其实 现方法
背景技术
分布式联机事务处理(online transaction processing，OLTP)系统通常利用分片式数据库来实现可扩展性。分片式数据库根据哈希值或分布列范围将数据划分为分片或分区。将数据分片分布到数据库节点(服务器)，每个节点独立管理各自的数据。由于数据重新分布使得每个数据库分片或节点包含的数据更少，并且能够处理的并发查询更多，所以添加服务器和节点会增加总吞吐量。如果应用程序只访问单独服务器中的数据，则这种无共享分片式系统的性能比较理想。然而，如果事务涉及多个节点，则联网和同步都会产生开销，从而降低可扩展性。
分片式OLTP系统中的分布式事务同步通常是通过二阶段提交(two-phasecommit，2PC)和集中式全局事务管理器(global transaction manager，GTM)来实现。2PC支持节点之间的一致性写操作，GTM提供全局一致性视图或快照。图1示出了分片式OLTP系统，例如Postgres-XC(PG-XC)。一般而言，应用程序将查询或语句102发送给分片式OLTP系统100中的协调器，从而与分片式OLTP系统100交互。协调器包括多个协调节点(coordinatornode，CN)104a、104b、104c、104d。CN解析这些语句并判断哪个数据库分片或数据节点(datanode，DN)106a至106e包含所查询的数据。将这些语句发送给特定DN以进行查询处理，包括对存储数据的实际访问。全局事务管理器(global transaction manager，GTM)108生成和维护带有写操作的事务的按升序排序的全局事务ID(global transaction ID，GXID)，以及仍然处于活动状态下的这些事务的列表。这个列表称为全局快照，用于支持多版本并发控制(multi-version concurrency control，MVCC)，这是一种实现高并发性的基本机制，从而实现读事务不阻塞写事务以及写事务不阻塞读事务。在MVCC中，当数据库记录被更新时，数据库记录不会被更新所替换。相反，该记录产生新版本。新旧版本在系统中共存，这样同一条记录的读事务和写事务互不冲突。读事务和写事务可以根据在事务或语句开始时获取的快照以及存储在记录的头部中的事务ID来访问正确版本，该记录表示正在更新的事务。当这些更新中的事务(包括插入、更新和删除)在获取快照之前提交时，这些事务的版本是可见的。
发明内容
根据本发明示例性实施例，克服了上述缺点并实现了其它优点。本发明示例性实施例描述了一种用于处理数据库事务的系统。所述系统包括接收事务查询的协调节点(coordinator node，CN)。所述CN判断所述事务是单分片事务还是多分片事务。当所述CN确定所述事务为多分片事务时，所述CN向全局事务管理器(global transaction manager，GTM)请求所述事务的分布式事务ID(distributed transaction ID，DXID)，接收所述事务的所述DXID，并且将所述查询和所述DXID发送给与所述事务关联的至少两个数据节点。然而，当确定所述事务为单分片事务时，所述CN将所述查询发送给与所述事务关联的单个数据节点，不需要先向所述GTM请求DXID。
本发明中描述的实施例也可以实施为一种用于处理数据库事务的计算机实现的方法。所述方法包括以下步骤：包含用于执行指令的一个或多个处理器的协调节点接收事务查询，并且判断所述事务是单分片事务还是多分片事务。当确定所述事务为多分片事务时，所述方法执行以下步骤：向包含用于执行指令的一个或多个处理器的全局事务管理器(global transaction manager，GTM)请求所述事务的分布式事务ID(distributedtransaction ID，DXID)，所述协调节点从所述GTM接收所述事务的所述DXID，并且将所述查询和所述DXID发送给与所述事务关联的至少两个数据节点。然而，当确定所述事务为单分片事务时，所述方法执行以下步骤：将所述查询发送给与所述事务关联的单个数据节点，不需要先向所述GTM请求DXID。
本发明中描述的实施例还可以实施为一种存储计算机指令的非瞬时性计算机可读介质。所述计算机指令在由一个或多个处理器执行时使得所述一个或多个处理器执行一系列步骤。所述步骤包括：协调节点接收事务查询，并且判断所述事务是单分片事务还是多分片事务。当确定所述事务是多分片事务时，所述步骤包括：向全局事务管理器(globaltransaction manager，GTM)请求所述事务的分布式事务ID(distributed transactionID，DXID)，接收所述事务的所述DXID，并且将所述查询和所述DXID发送给与所述事务关联的至少两个数据节点。然而，当确定所述事务为单分片事务时，所述步骤包括：将所述查询发送给与所述事务关联的单个数据节点，不需要先向所述GTM请求DXID。
附图说明
应结合所附附图描述本发明示例性实施例，其中：
图1示出了一种分片式OLTP系统；
图2A示出了一种包括全局事务管理器的系统；
图2B示出了示例性实施例提供的一种系统；
图3为示例性实施例提供的一种过程的流程图；
图4A至图4D为描述示例性实施例提供的几个事务的过程的时序图；
图5示出了示例性实施例的各种特征；
图6示出了示例性实施例提供的几个事务的通信流程；
图7示出了示例性实施例提供的一种全局和本地快照维护过程；
图8A至图8E示出了示例性实施例提供的一种用于检查单分片事务和多分片事务的可见性的过程；
图8F至图8K进一步示出了检查图8A至图8E的可见性的过程。
图9为本发明示例性实施例提供的一种过程的流程图；
图10为本发明示例性实施例提供的一种能够用作协调节点(coordinator node，CN)的设备的框图；
图11为本发明示例性实施例提供的另一种能够用作协调节点(coordinatornode，CN)的设备的框图。
在整个附图中，相似附图标记应理解为指代相似元件、特征和结构。
具体实施方式
由于每个事务在执行过程中都需要与GTM进行多次通信，所以在分片式OLTP系统中采用GTM的同步成本很高。许多此类通信和交互，例如，从GTM的活动事务列表中获取GXID并使GXID进出(enqueue/dequeue)该列表，都是连续的，可能会限制总吞吐量。因此，当系统中存在更多的数据库分片时，GTM往往会成为瓶颈。一些行业实践已经尝试解决这个问题。
VoltDB将数据库划分为多个分区。每个分区维护一个命令队列来执行终端用户的命令，包括临时SQL语句的执行计划、分布式SQL片段的执行计划和存储流程调用。在单独的分区中，一次运行一个命令，这样就不会重叠，从而实现了连续隔离。访问多个分区中的数据的查询通过多分区事务来处理。将这些事务的命令分发到各个分区，插入到它们的命令队列中，并通过单分区命令执行。来自多分区事务的命令需要全部(atomically)完成，也就是说，多分区事务的各个分区中的所有子任务需要全部完成或者全部不做。因此，当一个分区完成来自多分区事务的命令时，但该事务尚未提交，也就是说，所有分发的命令尚未完成，该分区停滞。VoltDB的一个缺点是每个队列(每个分区)中的所有任务都按顺序执行。当执行多分区事务的任务时，多个队列需要同步执行，因此导致停滞，直到所有任务完成，然后才能执行其它事务的任务。
Spanner支持数据库之间的全局一致性读取和外部一致性写入，这些可能在多个数据中心中都在进行。在Spanner中，使用Truetime方法来维护全局同步时间戳，各个服务器的实际时间因为各自使用的时钟而不确定。然而，这种方法是一种软硬件结合的方案，采用了GPS、原子钟等多个现代时钟参考。使用二阶段锁定(2-phase locking，2PL)可以用来保证全局数据访问连续进行，而单个分片上的数据写入则通过Paxos复制协议连续进行。
另一个方案是修改Postgres-XL，以消除GTM依赖关系。所有单分片事务都可以使用现有的本地事务处理设备。标识多分片写事务，并且只为这些事务生成分布式事务ID。这种方法降低了通信和管理开销，有助于提高不经常进行多节点操作所产生的工作负载的整体系统性能。
本发明实施例，即本文中的基于GTM-lite的分布式事务管理，有利于提高分片式OLTP的吞吐量和可扩展性。这优先通过避免单分片事务产生集中式并发管理开销、并且只有在GTM和DN的快照不同步发生数据冲突时暂停分布式事务来实现。通过这个策略，能够更快地解决大多数OLTP工作负载，即单分片查询，而且分片式OLTP系统能够扩展，而GTM不会成为瓶颈。如下面将进一步详细描述，这种方法还提供了一种权衡性能和隔离级别的灵活方法：如果需要快照隔离，则使用分布式事务；如果读取提交内容足够多，则使用单分片事务。
在本发明示例性实施例中，单分片事务的性能得到优化，多分片事务的一致性访问得到保持，如下文将进一步详细描述。单分片事务有利于保持GTM-free，而GTM只负责多分片事务一致性。换句话说，仅对于分布式事务，GTM的工作负载大大减少，因此GTM不会成为系统的瓶颈。大多数本地事务不需要与GTM进行多轮通信，从而大大提高了吞吐量。
图2A示出了一种传统系统200。系统200包括GTM 202、一组协调节点(coordinatornode，CN)204a、204b和一组数据节点206a至206c。在这种传统系统中，CN 204a接收所有查询。对于每个接收到的查询，CN向GTM 202请求TXID和全局快照。然后，CN 204a将全局快照、TXID和查询发送给数据节点DN 206a至206c中的一个或多个。因此，在传统系统中，每个查询都存在往返于GTM的数据流量。
图2B示出了本发明示例性实施例提供的一种系统。如图所示，CN 2004a接收分布式查询，即，涉及至少两个数据节点(data node，DN)的查询。CN 2004a识别出查询是分布式查询，因此，向GTM 2002请求DXID和DXID快照。然后，CN 2004a将DXID、DXID快照和查询发送给至少两个相关数据节点DN 2006a和2006b。接收DXID的数据节点2006a和2006b分别将DXID快照映射到本地TXID快照。另一方面，CN 2004b接收到的单分片查询使CN 2004b将查询发送给相单个相关数据节点DN 2006c，不需要向GTM 2002发出任何请求。数据节点DN2006c接收查询并生成TXID和本地快照。
现在将结合图3的流程图描述本发明示例性实施例提供的GTM-lite系统的整体工作流程300。在步骤302中，CN接收事务。CN判断事务是否为单分片事务。如果事务为单分片事务，则在步骤304中，CN将所述事务发送给数据节点。只有当事务为多分片事务时，在步骤306中，CN才向GTM请求分布式事务ID(distributed transaction ID，DXID)和分布式快照。在步骤308中，CN接着将DXID和分布式快照发送给相关数据节点。
现在将描述单分片事务工作流程的其余部分。在步骤304中，CN将单分片事务发送给指定的数据节点，之后，在步骤310中，目标数据节点DNi生成事务ID(transaction ID，TXID)和本地快照。在步骤312中，数据节点DNi执行事务。在步骤314中，CN提交事务；在步骤316中，数据节点DNi提交事务。显而易见地，单分片事务不存在与GTM交互，使得GTM可以同时处理其它任务。
现在将描述多分片事务工作流程的其余部分。在步骤308中，CN将DXID和分布式快照发送给多个目标DN，之后，在步骤318a至步骤318c中，目标数据节点DNj、DNk至DNn分别将DXID映射到本地TXID，并且将分布式快照和本地快照合并。在步骤320a至步骤320c中，目标数据节点DNj至DNn分别执行相应事务。在步骤322中，CN将准备(PREPARE)命令发送给目标数据节点DNj至DNn。在步骤324a至步骤324c中，目标数据节点DNj至DNn执行本地提交，进入“准备(prepared)”状态，并且将提交消息或中止消息发送给CN。在步骤326中，判断所有目标数据节点DNj至DNn是否都已准备好。如果是，则继续执行步骤328，即，CN将提交消息发送给GTM。在步骤330中，CN将提交消息发送数据节点DNj至DNn，并且标记数据节点DNj至DNn处于“提交(committed)”状态。如果在步骤326中，确定数据节点DNj至DNn没有全部准备好，则继续执行步骤332，即，CN将中止命令发送给GTM。在步骤334中，CN将中止发送给数据节点DNj至DNn，数据节点撤消前一事务，视为无效，并进入“中止”状态。
对于读提交隔离级别，在单分片事务开始时，只获取本地快照；而多分片事务不仅从GTM获取全局快照，而且还获取所有相关DN中的本地快照。为了提供快照隔离级别，单分片事务仍然获取本地快照，但在多分片事务开始时，不仅从GTM获取全局快照，而且还获取所有相关DN中的本地快照。另外，可以优先在其余数据节点上优先保留本地快照。
例如，现在将结合图4所示表格描述CN接受的三种不同事务。CN会话S1首先开始多分片事务MS_txn1，更新数据库表t0中的r1、r2和r5。CN发现MS_txn1涉及两个数据节点DN1和DN2，于是向GTM请求DXID。GTM生成DXID 1001和分布式快照{MS_txn1}。DN1将DXID转换为本地TXID 1201并将分布式快照和本地快照合并到{MS_txn1}。在DN1和DN2完成各自的任务后，CN会启动二阶段提交，并将准备(PREPARE)命令发送给DN。当DN1和DN2完成各自的本地提交后，DN1和DN2均进入“准备”状态(在clog中标记为“准备”)，然后将各自的响应发送给CN。当两个数据节点均使用提交(COMMIT)进行响应时，CN首先将提交消息发送给GTM，以将MS_txn1从布式活动分事务列表中移除，然后将提交确认消息分别发送给两个DN。
然而，提交消息先到达DN2，然后到达DN1，所以在某一时刻，DN1对于MS_txn1仍然处于“准备”状态，而DN2已经将MS_txn1标记为“提交”。此时，会话S2开始新事务SS_txn，在DN1上读取数据r1和r2并写入数据r3。由于新事务SS_txn是单分片事务，所以DN1会生成本地TXID 1202和本地快照{MS_txn1，SS_txn}。MS_txn1对r1和r2的更新是不可见的。因此，SS_txn读取r1和r2的旧版本，并保持对更新r3的锁定。
就在SS_txn在DN1上提交之前，CN会话S1接收另一个分布式事务MS_txn2，该事务打算在DN2上再次写入r3并读取一些数据。类似地，CN向GTM请求DXID和分布式快照{MS_txn2}，并接收DXID 1002。然而，在DN1中，本地快照为{MS_txn1，SS_txn}，与分布式快照合并时，MS_txn1上存在冲突：GTM认为MS_txn1已经提交，但是DN1还没有收到最终的提交消息，所以DN1仍然处于准备状态。在这种情况下，MS_txn2会将合并的快照作为{SS_txn，MS_txn2}，但会暂停(PAUSE)到MS_txn1完成提交。
最后，DN1接收MS_txn1的提交消息，并从准备状态切换到提交状态。因此，MS_txn2可以在MS_txn1改变后恢复并开始处理数据。但是，当MS_txn2试图写入r3时，r3仍然被SS_txn锁定，而SS_txn还没有提交。直到SS_txn完成提交并解除锁定。MS_txn2现在解除阻塞，能够完成事务执行。最终，MS_txn2通过二阶段提交，并在GTM和所有本地数据节点侧提交。
在上面的示例中，存在几种算法，现在将进一步说明。一种算法是，对包含来自GTM的本地快照和分布式快照的分布式事务进行可见性检查。以下示例性代码说明了用于确定分布式事务的可见性的算法。
bool VisibilityCheck(Snapshot*localSnapshot，Snapshot*distSnapshot){
如果数据来自在访问时提交的多分片事务(multi-shard transaction，MS-Tx)，则
1.1如果写事务MS-Tx的TXID在本地快照中，而其DXID在全局快照中，不可见
1.2如果写事务MS-Tx的DXID在全局快照中，而其TXID不在本地快照中(读事务在写事务之前到达DN)，不可见
1.3如果写事务MS-Tx的DXID不在全局快照中，而其TXID在本地快照中：读事务在写事务之后到达DN，但读事务在写事务之前开始于GTM侧(读事务的全局快照的最大DXID＜写事务的DXID)，不可见
1.4如果写事务MS-Tx的DXID不在全局快照中，而其TXID在本地快照中：读事务在写事务之后到达DN，但读事务在写事务之后开始于GTM侧(在读事务开始之前将写事务提交给GTM)，可见
1.5如果写事务MS-Tx既不在全局快照中也不在本地快照中，并且读事务在写事务之前开始于GTM侧(读事务的全局快照的最大DXID＜写事务的DXID)，不可见
1.6如果写事务MS-Tx既不在全局快照中也不在本地快照中，并且读事务在写事务之后开始于GTM侧(读事务的全局快照的最小DXID＞写事务的DXID)，可见
如果数据来自在访问时处于准备阶段的多分片事务(multi-shard transaction，MS-Tx)，则
2.1如果写事务MS-Tx在两个快照中，不可见
2.2如果写事务MS-Tx的DXID在全局快照中，而其TXID不在本地快照中，不可见
2.3如果写事务MS-Tx的DXID不在全局快照中，而其TXID在本地快照中，并且读事务在写事务之前到达GTM，不可见
2.4如果写事务MS-Tx的DXID不在全局快照中，而其TXID在本地快照中(写事务在GTM侧而不是DN侧提交或中止)，并且读事务在写事务之后开始，可见(提交)或不可见(中止)，需要等到写事务MS-Tx在DN中提交或中止
2.5如果写事务MS-Tx既不在全局快照中也不在本地快照中，并且读事务在写事务之前开始，不可见
}
ANSI/ISO SQL标准定义了隔离级别和每个隔离级别中可能发生的异常，如下表所示。
关于脏读，本发明实施例采用可见性规则来确保事务只能看到已提交数据，从而避免脏读。
关于不可重复读，根据本发明示例性实施例，在访问相关中DN的数据之前，事务首先根据GTM和本地DN记录的活动事务来计算快照。快照在事务的整个生存期内保持不变，因此，在事务执行过程中，如果多次检索某一行，则不可能显示不同的值。
关于幻读，根据本发明示例性实施例，在数据访问之前获取每个DN中的事务快照。通过DN快照和可见性规则，获取整个数据库的静态常量状态，因此对于任何范围/谓词，该状态也保持不变。因此，满足谓词但未通过快照和可见性规则获取的任何插入/更新/删除在事务执行过程中都是不可见的。
快照隔离已经用来评估ANSISQL/ISO标准中的隔离级别的定义，因为快照隔离没有表现出SQL标准禁止的、但不连续的异常。快照隔离允许的异常称为写偏斜。在写偏斜中，两个并发事务读取同一组数据，但修改不相交的数据集。例如，假设T1将x赋值给y(y＝x)，T2将y赋值给x(x＝y)，在初始情况下，x＝1∧y＝2。如果T1和T2以连续的方式执行，则最终状态应该是x＝2∧y＝2(T1在T2完成之后执行)或x＝1∧y＝1(T2在T1之后执行)。然而，在快照隔离时，T1和T2都会拍摄初始状态x＝1∧y＝2的快照，T1将y修改为1并提交，T2将x修改为2并提交。最终状态变成x＝2∧y＝1。
在本示例中，无论x和y是在同一个DN上还是在两个不同DN上，T1和T2都能够看见初始状态x＝1∧y＝2。由于T1修改了x，T2修改了y，因此不存在写-写冲突。T1和T2都提交，进入最终状态x＝2∧y＝1。
现在将描述各种已知的错误条件，以及本发明实施例如何处理或避免这些错误条件。
当按照任意顺序(w1[x]，w2[x]，c1或a1，c2或a2)，事务1写入[x]，事务2写入[x]，事务1提交或中止，事务2提交或中止时，会发生脏写(P0)。
由于T2看不见T1，T1看不见T2，所以本发明实施例避免了P0。T1和T2都更新x，在提交时，其中一个中止。
当按照任意顺序(w1[x]，r2[x]，任意顺序的a1和c2)，事务1写入[x]，事务2读取[x]，事务1中止，事务2提交时，会发生严格脏读(A1)。
由于在r2[x]发生时，T1未提交且T2看不见T1，所以本发明实施例避免了A1。在T2的整个生存期内，T2看不见T1。
当按照任意顺序(w1[x]，r2[x]，任意顺序的c1或a1和c2或a2)，事务1写入[x]，事务2读取[x]，事务1提交或中止，事务2提交或中止时，会发生脏读(P1)。
由于在r2[x]发生时，T1未提交且T2看不见T1，所以本发明实施例避免了P1。在T2的整个生存期内，T2看不见T1。
当事务1读取[x]，事务2写入[x]，事务2提交，事务1再次读取[x]，事务1提交(r1[x]，w2[x]，c2，r1[x]，c1)时，会发生不可重复读严格(A2)。
由于在T1的整个生存期内T1看不见T2，所以本发明实施例避免了A2。
当按照任意顺序(r1[x]，w2[x]，任意顺序的c1或a1和c2或a2)，事务1读取[x]，事务2写入[x]，事务1提交或中止，事务2提交或中止时，会发生不可重复读(P2)。
由于在T1的整个生存期内T1看不见T2，所以本发明实施例避免了P2。
当事务1读取一组记录P，事务2写入位于P中的[y]，事务2提交，事务1再次读取P并再次提交(r1[P]，w2[位于P中的y]，c2，r1[P]，c1)时，发生严格幻读(A3)。
由于在T1的整个生存期内T1看不见T2，所以本发明实施例避免了A3。
当按照任意顺序(r1[P]，w2[P]，任意顺序的c1或a1和c2或a2)，事务1读取一组记录P，事务2写入位于P中的[y]，事务1提交或中止，事务2提交或中止时，会发生幻读(P3)。
由于在T1的整个生存期内T1看不见T2，所以本发明实施例避免了P3。
当事务1读取[x]，事务2写入[x]，事务1写入[x]，事务1提交(r1[x]，w2[x]，w1[x]，c1)时，会发生更新丢失(P4)。
由于T1和T2彼此看不见并且都更新x，同时其中一个中止，本发明实施例避免了P4。
当事务1读取[x]，事务2写入[x]，事务2写入[y]，事务2提交，事务1读取[y]，事务1提交或中止(r1[x]，w2[x]，w2[y]，c2，r1[y]，c1或a1)时，会发生读偏斜(A5A)。
由于在T1的整个生存期内T1看不见T2，所以本发明实施例避免了A5A。
当事务1读取[x]，事务2读取[y]，事务2写入[y]，事务2写入[x]，事务1和事务2提交(r1[x]，r2[y]，w1[y]，w2[x]，c1和c2发生)时，会发生写偏斜(A5B)。
由于T1和T2写入不相交的数据集{x}和{y}并且都可以提交，所以本发明实施例可能会出现A5B。当单分片事务和多分片事务混合执行时，本发明实施例还可以出现其它异常。
单分片事务T1和T2来自同一个客户端会话，因此它们可以连续执行。在DN1上，T1将a从0修改为1并提交；在DN2上，T2将b从0修改为1并提交。多分片事务T3读取a和b。T3在T1开始之前到达DN1，T3在T2提交之后到达DN2。因此，尽管T1在T2开始之前提交，T3还是看不见T1(a仍然是0)，但能看见T2(b是1)。假设读操作一完成就释放读锁，在具有以下历史记录的读提交隔离级别中：r3(a)w1(a)c1(a)w2(b)c2(b)r3(b)c3，也可能发生这种问题。
单分片事务T1和T2来自同一个客户端会话，因此它们可以连续执行。多分片事务T3在DN1上写入a(从0到1)，在DN2上写入b(从0到1)，在DN1上准备，在DN2上提交。当T1在DN2上读取数据b时，T1在T3(b＝1)之后看到提交后的数据，但是后面的事务T2看不见T3提交(a＝0)。因此，对于具有多个单分片事务的应用程序，需要一个连续视图，必须将多个单分片事务放入单个多分片事务中。
本发明实施例不会出现脏读、不可重复读和幻读异常，但可以会产生上述写偏斜和其它异常。因此，本文描述的由本发明实施例维护的隔离级别在读提交和快照隔离之间。图5示出了与其它隔离级别相比的本发明示例性实施例的强度。
本发明示例性实施例与传统GTM之间的一个区别就是快照隔离(snapshotisolation，SI)。根据示例性实施例，单分片事务既不受GTM管理，也不获取分布式事务ID(distributed transaction ID，DXID)，而是将本地事务TXID维护在本地快照中以进行可见性检查。在分布式事务或单分片事务之中，可见性检查以相同的方式执行。分布式事务使用全局事务快照(包括所有分布式活动事务)，而单分片事务使用本地事务快照。当读事务是分布式事务，而写事务是单分片事务时，本发明实施例中的SI产生的结果与基于GTM的SI的结果不同。例如，记录a＝0和b＝0相应地位于DN1和DN2中。单分片事务T1更新a＝1并提交之后，另一单分片事务T2更新b＝1。分布式事务T3同时读取a和b。图6示出了应用程序能够以下发T3的三个可能时间。在[1]处，在T1和T2下发之后，但两者均未提交，并且在应用程序发送T1和T2的提交命令之前，下发T3。在[2]处，在T1已提交并且返回确认(ack)给应用程序之后，下发T3。在[3]处，在T1和T2都已提交并且都返回ack给应用程序之后，下发T3。
如果T3在时间[1]处下发，那么应用程序认为T3与T1和T2同时运行。应用程序会期望T3读取a和b的所有可能的组合值{(a＝0，b＝0)，(a＝1，b＝0)，(a＝0，b＝1)，(a＝1，b＝1)}。如果应用程序发送T1或T2的提交命令，但是没有收到确认，那么应用程序期望得到相同的结果。对于基于GTM的传统方案，T3将返回a＝0和b＝0；而根据本发明实施例，T3将得到{(a＝0，b＝0)，(a＝1，b＝0)，(a＝0，b＝1)，(a＝1，b＝1)}，具体取决于T3在DN2中的开始时间。
如果T3在时间[2]处下发，那么T1已经提交，而且应用程序已经得到确认。应用程序期望得到{(a＝1，b＝0)，(a＝1，b＝1)}。对于基于GTM的传统方案，T3将返回{(a＝1，b＝0)}；而对于基于本发明实施例的方案，T3将正确返回{(a＝1，b＝0)，(a＝1，b＝1)}。
如果T3在时间[3]处下发，那么T1和T2已经提交，而且应用程序已经收到两者的确认，应用程序期望得到{(a＝1，b＝1)}。对于基于GTM的传统方案，T3将返回{(a＝1，b＝1)}；而对于本发明实施例，T3也将返回{(a＝1，b＝1)}。
以上内容说明了，如果采用了快照隔离，应用程序应该预料到当前正在运行的事务的结果是不确定的。本发明实施例中的SI有利于在并发执行和连续执行中恰当地满足应用程序的预期。
如上所述，当一个DN中的一个分布式事务与另一个分布式事务存在写后读依赖关系(或数据冲突)时，如果写事务已经在该DN中完成准备阶段，则读事务会暂停。即使这种暂停不影响非分布式事务，但是可能会使分布式事务的执行速度严重减慢。以下会话描述解释了影响由于这种写后读延迟导致延迟的主要因素。
下表提供了符号及其定义：
为了简化，假设以下条件：
(1)只有在T时间窗内到达的事务才可能会发生冲突(写后读依赖关系)
(2)冲突(写后读)可能性与事务的执行时间无关
(3)所有分布式事务涉及x个DN(可以通过将分布式事务中的DN的数量建模为Zipf函数等增加这个数量)
(4)写后读暂停导致的平均延迟为λ/2
(5)工作负载均分到所有DN
在这些条件下，平均写后读延迟由以下公式给出：
((xRTβ/N)×Q×(λ/2))/RTβ＝(x×Q×λ)/2N
根据上述建模，平均写后读延迟与分布式事务涉及的DN数量、DN总数、一个DN中的并发分布式事务之间的冲突比例、准备和提交之间的延迟的长度有关联。如果一个分布式事务需要在更多的DN上运行，而DN总数下降，那么DN中就会存在更多的并发分布式事务，这会增加冲突及其相关的延迟。主要因素是Q，即，一个DN中的并发分布式事务之间的冲突比例。该因素受数据分布和应用程序访问数据的方式以及一个DN中并发分布式事务调度的影响。数据分布和应用程序访问数据的方式取决于应用程序及其数据。一个DN中并发分布式事务调度可以进行优化，以使发生冲突的分布式事务单独运行，减少潜在冲突和Q。这种优化可以包括两项操作：(1)使用不同DN调度分布式事务一起运行；(2)在不存在数据依赖关系的情况下调度分布式事务并发运行。
当分布式事务涉及多个数据库时，一些现有方案似乎强调一致性，所有参与方要么提交要么不提交，通常通过二阶段提交。在现有的商业文献中，鉴于分布式数据库元素在不同时间独立提交这一事实，很难找到关于实现分布式数据库元素上的一致性视图的信息。有关二阶段提交的许多文档在很大程度上假设：一个事务在异构环境中交互，异构环境中的其它事务可能完全来自其它供应商。如果是所有相关的数据库都来自相同的代码和二进制文件，那么就有可能采取其它措施，在面对并发性的情况下确保一致性。
Oracle使用系统变更号(System Change Number，SCN)作为实现数据一致性视图的基础，即使在单个Oracle数据库中，即，非分布式数据库中，也是如此。SCN充当一个时间戳，这样在数据库操作期间，SCN将具有数据的相同一致性视图，与其它正在执行的事务无关。也就是说，SCN可以看见从某个SCN开始提交的所有数据，但看不见之后提交的任何数据。
在分布式情况下，所有参与方都是Oracle数据库，管理所有节点协调的进程将从所有参与方收集SCN，选择最高的SCN，并在所有节点上使用相同的SCN。虽然使用同一个SCN有助于将这些节点关联在一起，但文档提到，要确保机器同步首先执行一个虚拟查询，例如“SELECT*FROM DUAL@REMOTE”，但是，如果在虚拟查询和预期查询之间执行更多的其它并发事务，这是不够的。
微软SQL服务器和SAP自适应服务器类似地在内部针对单个实例使用提交时间戳机制，但是文档只提到2PC在提交或不提交方面的一致性，并没有解决并发性。
对于其他RDBMS供应商，也很难找到有关解决这个问题的信息。NoSQL数据库通常只在一个“事务”中提供单个操作，并且可能允许读取过期数据。Clustrix和MemSQL等NewSQL供应商的文档中似乎没有太多关于如何处理并发性的信息。
PostgreSQL没有使用提交时间戳来获取数据一致性视图，而是使用快照，这些快照由正在运行的事务id组成，包括最小值和最大值，称为xmin和xmax。在xmin之前由事务写入的任何数据都是可查看的，在xmax之后的任何数据都是不可查看的，否则，如果事务在快照列表中，则不可查看。对于Postgres-XC、Postgres-XL和Gauss MPPDB，通过全局事务管理器(Global Transaction Manager，GTM)在集群范围内扩展该机制，使事务标识符和快照成为全局事务标识符和快照。
谷歌Spanner在数据变为可见之前使用提交等待机制来解决节点之间的时间不确定性。并发只读事务得到一致的但可能稍微过时的数据视图。
对于本发明示例性实施例，仅在必要时使用分布式事务标识符，并且根据需要修改本地快照。另外，还进行提交确认，以避免一致性异常。集中在GTM中跟踪所有分布式事务标识符(distributed transaction identifier，DXID)。从GTM获取所有分布式快照。在将提交消息发送给相关节点之前，将事务从GTM中移除。在节点上执行元组的可见性检查时，如果元组处于准备状态，系统将等待，直到对应的本地事务在本地提交和在全局确认后提交。这种新方法使并发事务的数据库视图更加新颖。
通常通过集中式全局事务管理器(global transaction manager，GTM)来实现分片式OLTP系统中的分布式事务同步，GTM提供全局一致性视图或快照。但是，由于每个事务在开始和提交时都需要与GTM通信，因此集中式GTM会成为系统的一个主要瓶颈。而且，这种复杂的机制延长了短单分片事务的延迟。
本发明实施例可以实现为网络计算环境中的一个或多个节点。每个节点包括能够执行指令或命令的一个或多个处理器、用于在节点之间通信的通信接口以及存储在计算机可读非瞬时性介质上的包含供一个或多个处理器执行的编程代码(软件)的一组指令。计算机可读非瞬时性介质包括所有类型的计算机可读介质，包括磁性存储介质、光学存储介质、闪存介质和固态存储介质。
图7示出本发明示例性实施例提供的一种全局和本地快照维护方法。系统700包括CN702、GTM 704和一组DN 706a至706c。如图所示，CN 702接收多分片事务查询708，CN确定事务是多分片事务。然后，CN向GTM 704请求DXID。GTM将DXID(103)分配给多分片事务，并将该事务记录在全局分布式快照表710中。全局分布式快照表存储和更新每个分布式活动事务的状态。GTM将DXID(103)和全局快照发回CN 702，CN 702将查询、快照和DXID转发给DN706a至706c中的至少两个DN。每个DN维护两种表格。本地分布式快照712a至712c记录DXID和本地TXID的映射关系，本地事务表714a至714c记录所有本地事务的状态：分布式事务和单分片事务。在提交时，CN 702首先提交到GTM 704，GTM704更新全局分布式快照710。接着，CN 702指示DN 706a至706c进行提交。然后，DN 706a至706c更新它们的本地快照714a至714c和本地分布式快照712a至712c。
现在将描述根据本发明示例性实施例的可见性检查。对于单分片事务，由于没有获取到DXID，所以每个DN的本地快照用于检查数据的可见性。对于多分片事务，根据本地快照和全局快照的状态判断数据是可见还是不可见。图8A至图8E示出了在访问时提交事务时的CN和DN之间的事务时序。如果数据来自多分片事务(multi-shard transaction，MS-Tx)。在图8A至图8E中，应理解以下符号具有以下含义：
w：写事务MS-Tx
r：读MS-Tx
c_w：在CN/GTM中提交写事务MS-Tx
p_w：在CN/GTM中准备写事务MS-Tx
a/c_w：在CN中止或提交写事务MS-Tx
p：在DN中准备
b：开始事务
c：在DN中提交
a：访问数据
如图8A所示，如果写事务MS-Tx的TXID在本地快照中，但其DXID在全局快照中，则数据是不可见的。如图8B所示，如果写事务MS-Tx的DXID在全局快照中，但其TXID在本地快照中，则数据是不可见的，因为读事务在写事务之前到达DN。如图8C所示，如果写事务MS-Tx的DXID不在全局快照中，但其TXID在本地快照中，则数据是不可见的。此处，读事务在写事务之后到达DN，但是读事务在写事务之前开始于GTM侧(读事务的全局快照的最大DXID小于写事务的DXID)。但是，如果写事务MS-Tx的DXID不在全局快照中，但其TXID在本地快照中，则数据是可见的。此处，读事务在写事务之后到达DN，而在读事务开始之前，写事务被提交到GTM。如图8D所示，如果写事务MS-Tx的DXID既不在全局快照中，也不在本地快照中，并且读事务在写事务之前开始于GTM侧(读事务的全局快照的最大DXID小于写事务的DXID)，则数据是不可见的。如图8E所示，如果写事务MS-Tx既不在全局快照中，也不在本地快照中，则数据是可见的。读事务在写事务之后开始于GTM侧(读事务的全局快照的最小DXID大于写事务的DXID).
图8F至图8K还示出了当数据来自在访问时处于准备阶段的多分片事务时检查数据可见性的过程。如图8F和图8G所示，如果写事务MS-Tx在两种快照中，则数据是不可见的。如图8H所示，如果写事务MS-Tx的DXID在全局快照中，但其TXID不在本地快照中，则数据是不可见的。如图8I所示，如果写事务MS-Tx的DXID不在全局快照中，但其TXID在本地快照中，则数据是不可见的。读事务在写事务之前到达GTM(读事务的全局快照的最大DXID或读事务的DXID小于写事务的DXID)。如图8J所示，如果写事务MS-Tx的DXID不在全局快照中，但其TXID在本地快照中，则数据在提交时是可见的，在中止时是不可见的。写事务在GTM侧而不是DN侧提交或中止。读事务在写事务之后开始，因此系统必须等到写事务MS-Tx在DN中提交或中止。如图8K所示，如果写事务MS-Tx既不在全局快照中，也不在本地快照中，并且读事务在写事务之前开始，也就是说，读事务的DXID小于写事务的DXID，则数据是不可见的。
图9为本发明示例性实施例的流程图。方法900开始于步骤902，即，CN接收事务查询。接着，在步骤904中，CN判断事务是单分片事务还是多分片事务。当事务是多分片事务时，方法前进到步骤906，即，CN向GTM请求DXID。在步骤908中，CN接收分配的DXID。最后，在步骤910中，CN将查询和DXID发送给与事务关联的至少两个数据节点。然而，当在步骤904中确定事务是单分片事务时，方法直接前进到步骤912，即，CN直接将查询发送给与事务关联的数据节点，不需要先与GTM通信。在任一情况下，方法接着返回到步骤902，因此CN可以接收和处理下一个事务。
图10本发明实施例提供的协调节点(coordinator node，CN)等网络设备1000的示意图。网络设备1000适于实施本文所述的公开实施例。网络设备1000包括：用于接收数据的入端口1009和接收单元(receiver unit，Rx)1008；用于处理数据的处理器、逻辑单元或中央处理器(central processing unit，CPU)1002；用于发送数据的发送单元(transmitterunit，Tx)1006和出端口1007；以及用于存储数据的存储器1004。网络设备1000还可以包括耦合到入端口1009、接收单元1008、发送单元1006和出端口1007的光电(optical-to-electrical，OE)组件和电光(electrical-to-optical，EO)组件，用于光信号或电信号的出口或入口。
处理器1002通过硬件和软件实现。处理器1002可以实现为一个或多个CPU芯片、核(例如，多核处理器)、现场可编程门阵列(field programmable gate array，FPGA)、专用集成电路(application specific integrated circuit，ASIC)和数字信号处理器(digitalsignal processor，DSP)。处理器1002与入端口1009、接收单元1008、发送单元1006、出端口1007和存储器1004通信。处理器1002包括编码模块1016。编码模块1016实施本文所述的公开实施例。例如，编码模块1016执行、处理、准备或提供各种编码操作。因此，包含编码模块1016实质性改进了网络设备的功能，并且影响了网络设备1000到不同状态的转换。或者，以存储在存储器1004中并由处理器1002执行的指令来实现编码模块1016。
存储器1004包括一个或多个磁盘、磁带机和固态硬盘，可以用作溢出数据存储设备，以在选择程序来执行时存储此类程序，并且存储在执行程序过程中读取的指令和数据。存储器1004可以是易失性和/或非易失性的，并且可以是只读存储器(read-only memory，ROM)、随机存取存储器(random access memory，RAM)、三态内容寻址存储器(ternarycontent-addressable memory，TCAM)和/或静态随机存取存储器(static random-accessmemory，SRAM)。
发射器1006和接收器1008通过各自的出端口和入端口与任何合适的通信网络1010进行信号发送和接收。如图所示，设备1000可以通过通信网络1010与GTM 1012或DN1014通信。如本文所述，接收器1008接收查询请求，发射器1006将查询发送给DN 1014或将DXID请求发送给GTM 1012。
图11本发明实施例提供的协调节点(coordinator node，CN)等网络设备1100的示意图。网络设备1100适于实施本文所述的公开实施例。网络设备1100包括：用于接收数据的入口单元1109和接收单元(receiver unit，Rx)1108；用于处理数据的处理单元、逻辑单元或中央处理器(central processing unit，CPU)1102；用于发送数据的发送单元(transmitter unit，Tx)1106和出口单元1107；用于存储数据的存储单元1104。网络设备1100还可以包括耦合到入口单元1109、接收单元1108、发送单元1106和出口单元1107的光电(optical-to-electrical，OE)组件和电光(electrical-to-optical，EO)组件，用于光信号或电信号的出口或入口。
处理单元1102通过硬件和软件实施。处理单元1102可以实现为一个或多个CPU芯片、核(例如，多核处理器)、现场可编程门阵列(field programmable gate array，FPGA)、专用集成电路(application specific integrated circuit，ASIC)和数字信号处理器(digital signal processor，DSP)。处理单元1102与入口单元1109、接收单元1108、发送单元1106、出口单元1107和存储单元1104通信。处理单元1102包括编码模块1116。编码模块1116实施本文所述的公开实施例。例如，编码模块1116执行、处理、准备或提供各种编码操作。因此，包含编码模块1116实质性改进了网络设备的功能，并且影响了网络设备1100到不同状态的转换。或者，以存储在存储单元1104中并由处理单元1102执行的指令来实现编码模块1116。
存储单元1104包括一个或多个磁盘、磁带机和固态硬盘，可以用作溢出数据存储设备，以在选择程序来执行时存储此类程序，并且存储在执行程序过程中读取的指令和数据。存储单元1104可以是易失性和/或非易失性的，并且可以是只读存储器(read-onlymemory，ROM)、随机存取存储器(random access memory，RAM)、三态内容寻址存储器(ternary content-addressable memory，TCAM)和/或静态随机存取存储器(staticrandom-access memory，SRAM)。
发送单元1106和接收单元1108通过各自的出口单元1107和入口单元1109与任何合适的通信网络1110进行信号发送和接收。如图所示，设备1100可以通过通信网络1110与GTM1012或DN 1014通信。如本文所述，接收单元1108接收查询请求，发送单元1006将查询发送给DN 1014或将DXID请求发送给GTM 1012。
应当理解的是，软件可以安装在上述一个或多个节点商并可以随上述一个或多个节点一同出售。或者，可以获取该软件并将其加载到一个或多个节点中，包括通过物理介质或分发系统获取软件，例如，从软件创建者拥有的服务器或从软件创建者未拥有却使用或授权使用的服务器获取该软件。例如，该软件存储在服务器上，以便通过因特网分发。
根据本发明一方面，提供了一种用于处理数据库事务的系统。所述系统包括接收事务查询的协调节点(coordinator node，CN)。所述CN判断所述事务是单分片事务还是多分片事务。当所述CN确定所述事务为多分片事务时，所述CN向全局事务管理器(globaltransaction manager，GTM)请求所述事务的分布式事务ID(distributed transactionID，DXID)，接收所述事务的所述DXID，并且将所述查询和所述DXID发送给与所述事务关联的至少两个数据节点。然而，当确定所述事务为单分片事务时，所述CN将所述查询发送给与所述事务关联的单个数据节点，不需要先向所述GTM请求DXID。本系统有利地减少了与所述GTM的通信，从而降低了通信开销，提高了分片式数据库中事务处理的效率。
可选地，在上述任一方面中，所述系统还包括：当所述CN确定所述事务为多分片事务时，所述CN用于向所述GTM请求全局快照，并将所述全局快照发送到与所述事务关联的所述至少两个数据节点。
可选地，在上述任一方面中，所述事务涉及联机事务处理(online transactionprocessing，OLTP)数据库。又可选地，在上述任一方面中，所述CN维护全局模式。又可选地，在所述系统的上述任一方面中，接收所述全局快照的所述至少两个数据节点将所述全局快照与本地快照合并。又可选地，在所述系统的上述任一方面中，所述数据节点维护本地活动事务列表；对于多分片事务，与所述事务关联的每个数据节点将所述DXID映射到本地事务ID(transaction ID，TXID)。又可选地，在所述系统的任一前述方面中，所述数据节点读取由多分片事务修改的数据，并且在以下情况下确定所述数据是可见的：所述多分片事务已提交，并且所述多分片事务不在所述全局快照而在所述本地快照中；或者，所述多分片事务已提交，所述DXID既不在所述全局快照也不在所述本地快照中，并且所述全局快照的最小DXID大于所述多分片事务的所述DXID；或者，所述多分片事务处于准备状态，然后提交，并且所述多分片事务不在所述全局快照而在所述本地快照中。又可选地，在所述系统的任一上述方面中，如果所述事务为单分片事务，则在所述数据节点执行所述事务之后，所述CN提交所述事务，并且所述单个数据节点提交所述事务，不需要与所述GTM交互。
根据本发明另一方面，提供了一种方法。所述方法包括：协调节点接收事务查询，以及判断所述事务是单分片事务还是多分片事务。当确定所述事务是多分片事务时，所述步骤包括：向全局事务管理器(global transaction manager，GTM)请求所述事务的分布式事务ID(distributed transaction ID，DXID)，接收所述事务的所述DXID，并且将所述查询和所述DXID发送给与所述事务关联的至少两个数据节点。然而，当确定所述事务为单分片事务时，所述步骤包括：将所述查询发送给与所述事务关联的单个数据节点，不需要先向所述GTM请求DXID。
可选地，在所述方法的任一上述方面中，当确定所述事务为多分片事务时，所述方法还包括以下步骤：从所述GTM请求全局快照，以及将所述全局快照发送给与所述事务关联的所述至少两个数据节点。
可选地，在所述方法的任一上述方面中，所述事务涉及联机事务处理(onlinetransaction processing，OLTP)数据库。又可选地，在所述方法的任一上述方面中，所述CN维护全局模式。又可选地，在所述方法的任一上述方面中，接收所述全局快照的所述至少两个数据节点将所述全局快照与本地快照合并。
可选地，在任一上述方面中，所述方法还包括：在数据节点中维护本地活动事务列表；对于多分片事务，与所述事务关联的每个数据节点将所述DXID映射到本地事务ID(transaction ID，TXID)。
可选地，在任一上述方面中，所述方法还包括：读取由多分片事务修改的数据，并且在以下情况下确定所述数据是可见的：所述多分片事务已提交，并且所述多分片事务不在所述全局快照而在所述本地快照中；或者，所述多分片事务已提交，所述DXID既不在所述全局快照也不在所述本地快照中，并且所述全局快照的最小DXID大于所述多分片事务的所述DXID；或者，所述多分片事务处于准备状态，然后提交，并且所述多分片事务不在所述全局快照而在所述本地快照中。
可选地，在所述方法的任一上述方面中，如果所述事务为单分片事务，则在所述数据节点执行所述事务之后，所述CN提交所述事务，并且所述单个数据节点提交所述事务，不需要不与所述GTM交互。

Claims (24)

1.一种用于处理数据库事务的系统，其特征在于，包括：
协调节点CN，接收对事务的查询，
其中，所述CN用于判断所述事务是单分片事务还是多分片事务；
当所述CN确定所述事务为多分片事务时，
所述CN用于：向全局事务管理器GTM请求所述事务的分布式事务ID DXID和分布式快照，
接收所述事务的所述DXID和所述分布式快照，
将所述查询和所述DXID、所述分布式快照发送给与所述事务关联的至少两个数据节点，以便所述至少两个数据节点分别将所述DXID映射到本地事务ID TXID，并且将所述分布式快照和本地快照合并；
当所述CN确定所述事务为单分片事务时，
所述CN用于将所述查询发送给与所述事务关联的单个数据节点，以便与所述事务关联的单个数据节点接收所述查询并生成TXID和本地快照，所述CN不需要先向所述GTM请求DXID。
2.根据权利要求1所述的系统，其特征在于，当所述CN确定所述事务为多分片事务时，所述CN用于向所述GTM请求全局快照，并且将所述全局快照发送给与所述事务关联的所述至少两个数据节点。
3.根据权利要求1所述的系统，其特征在于，所述事务涉及联机事务处理OLTP数据库。
4.根据权利要求1所述的系统，其特征在于，所述CN维护全局模式。
5.根据权利要求2所述的系统，其特征在于，接收所述全局快照的所述至少两个数据节点将所述全局快照与本地快照合并。
6.根据权利要求1所述的系统，其特征在于，所述数据节点维护本地活动事务列表；对于多分片事务，与所述事务关联的每个数据节点将所述DXID映射到本地事务ID TXID。
7.根据权利要求5所述的系统，其特征在于，所述至少两个数据节点读取由多分片事务修改的数据，并且在以下情况下确定所述数据是可见的：
所述多分片事务已提交，并且所述多分片事务不在所述全局快照而在所述本地快照中；或者
所述多分片事务已提交，所述DXID既不在所述全局快照也不在所述本地快照中，并且所述全局快照的最小DXID大于所述多分片事务的所述DXID；或者
所述多分片事务处于准备prepare状态，然后提交，并且所述多分片事务不在所述全局快照而在所述本地快照中。
8.根据权利要求1所述的系统，其特征在于，如果所述事务为单分片事务，则在所述单个数据节点执行所述事务之后，所述CN提交所述事务，并且所述单个数据节点提交所述事务，不需要与所述GTM交互。
9.一种用于处理数据库事务的计算机实现的方法，其特征在于，所述方法包括以下步骤：
包含用于执行指令的一个或多个处理器的协调节点CN接收对事务的查询；
判断所述事务是单分片事务还是多分片事务；
当确定所述事务为多分片事务时，
向包含用于执行指令的一个或多个处理器的全局事务管理器GTM请求所述事务的分布式事务ID DXID和分布式快照，
所述协调节点CN从所述GTM接收所述事务的所述DXID和所述分布式快照，
将所述查询和所述DXID、所述分布式快照发送给与所述事务关联的至少两个数据节点，以便所述至少两个数据节点分别将所述DXID映射到本地事务ID TXID，并且将所述分布式快照和本地快照合并；
当确定所述事务为单分片事务时，
将所述查询发送给与所述事务关联的单个数据节点，不需要先向所述GTM请求DXID，以便与所述事务关联的单个数据节点接收所述查询并生成TXID和本地快照。
10.根据权利要求9所述的计算机实现的方法，其特征在于，当确定所述事务为多分片事务时，所述方法还包括以下步骤：从所述GTM请求全局快照，并且将所述全局快照发送给与所述事务关联的所述至少两个数据节点。
11.根据权利要求9所述的计算机实现的方法，其特征在于，所述事务涉及联机事务处理OLTP数据库。
12.根据权利要求9所述的计算机实现的方法，其特征在于，所述CN维护全局模式。
13.根据权利要求10所述的计算机实现的方法，其特征在于，接收所述全局快照的所述至少两个数据节点将所述全局快照与本地快照合并。
14.根据权利要求9所述的计算机实现的方法，其特征在于，所述方法还包括在数据节点中维护本地活动事务列表；对于多分片事务，与所述事务关联的每个数据节点将所述DXID映射到本地事务ID TXID。
15.根据权利要求13所述的计算机实现的方法，其特征在于，所述方法还包括：读取由多分片事务修改的数据，并且在以下情况下确定所述数据是可见的：
所述多分片事务已提交，并且所述多分片事务不在所述全局快照而在所述本地快照中；或者
所述多分片事务已提交，所述DXID既不在所述全局快照也不在所述本地快照中，并且所述全局快照的最小DXID大于所述多分片事务的所述DXID；或者
所述多分片事务处于准备状态，然后提交，并且所述多分片事务不在所述全局快照而在所述本地快照中。
16.根据权利要求9所述的计算机实现的方法，其特征在于，所述方法还包括：如果所述事务为单分片事务，则在所述单个数据节点执行所述事务之后，所述CN提交所述事务，并且所述单个数据节点提交所述事务，不需要与所述GTM交互。
17.一种存储计算机指令的非瞬时性计算机可读介质，其特征在于，所述计算机指令在由一个或多个处理器执行时使得所述一个或多个处理器执行以下步骤：
协调节点CN接收对事务的查询；
判断所述事务是单分片事务还是多分片事务；
当确定所述事务为多分片事务时，
向全局事务管理器GTM请求所述事务的分布式事务ID DXID和分布式快照，
接收所述事务的所述DXID和所述分布式快照，
将所述查询和所述DXID、所述分布式快照发送给与所述事务关联的至少两个数据节点，以便所述至少两个数据节点分别将所述DXID映射到本地事务ID TXID，并且将所述分布式快照和本地快照合并；
当确定所述事务为单分片事务时，
将所述查询发送给与所述事务关联的单个数据节点，不需要先向所述GTM请求DXID，以便与所述事务关联的单个数据节点接收所述查询并生成TXID和本地快照。
18.根据权利要求17所述的非瞬时性计算机可读介质，其特征在于，当确定所述事务为多分片事务时，所述指令使得所述一个或多个处理器执行以下步骤：向所述GTM请求全局快照，并且将所述全局快照发送给与所述事务关联的所述至少两个数据节点。
19.根据权利要求17所述的非瞬时性计算机可读介质，其特征在于，所述事务涉及联机事务处理OLTP数据库。
20.根据权利要求17所述的非瞬时性计算机可读介质，其特征在于，所述CN维护全局模式。
21.根据权利要求18所述的非瞬时性计算机可读介质，其特征在于，接收所述全局快照的所述至少两个数据节点将所述全局快照与本地快照合并。
22.根据权利要求17所述的非瞬时性计算机可读介质，其特征在于，所述指令使得所述一个或多个处理器执行以下步骤：在数据节点中维护本地活动事务列表；对于多分片事务，与所述事务关联的每个数据节点将所述DXID映射到本地事务ID TXID。
23.根据权利要求21所述的非瞬时性计算机可读介质，其特征在于，所述指令使得所述一个或多个处理器执行以下步骤：读取由多分片事务修改的数据，并且在以下情况下确定所述数据是可见的：
所述多分片事务已提交，并且所述多分片事务不在所述全局快照而在所述本地快照中；或者
所述多分片事务已提交，所述DXID既不在所述全局快照也不在所述本地快照中，并且所述全局快照的最小DXID大于所述多分片事务的所述DXID；或者
所述多分片事务处于准备状态，然后提交，并且所述多分片事务不在所述全局快照而在所述本地快照中。
24.根据权利要求17所述的非瞬时性计算机可读介质，其特征在于，所述指令使得所述一个或多个处理器执行以下步骤：如果所述事务为单分片事务，则在所述单个数据节点执行所述事务之后，所述CN提交所述事务，并且所述单个数据节点提交所述事务，不需要与所述GTM交互。
CN201880078365.2A 2017-12-06 2018-11-29 全局一致分片式oltp系统的高吞吐量分布式事务管理及其实现方法 Active CN111433764B (zh)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US15/833,658 US10810268B2 (en) 2017-12-06 2017-12-06 High-throughput distributed transaction management for globally consistent sharded OLTP system and method of implementing
US15/833,658 2017-12-06
PCT/CN2018/118134 WO2019109853A1 (en) 2017-12-06 2018-11-29 High-throughput distributed transaction management for globally consistent sharded oltp system and method of implementing

Publications (2)

Publication Number Publication Date
CN111433764A CN111433764A (zh) 2020-07-17
CN111433764B true CN111433764B (zh) 2023-10-13

Family

ID=66657988

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201880078365.2A Active CN111433764B (zh) 2017-12-06 2018-11-29 全局一致分片式oltp系统的高吞吐量分布式事务管理及其实现方法

Country Status (4)

Country Link
US (1) US10810268B2 (zh)
EP (2) EP4270211A3 (zh)
CN (1) CN111433764B (zh)
WO (1) WO2019109853A1 (zh)

Families Citing this family (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10394818B2 (en) 2014-09-26 2019-08-27 Oracle International Corporation System and method for dynamic database split generation in a massively parallel or distributed database environment
US10387421B2 (en) 2014-09-26 2019-08-20 Oracle International Corporation System and method for generating size-based splits in a massively parallel or distributed database environment
US10528596B2 (en) * 2014-09-26 2020-01-07 Oracle International Corporation System and method for consistent reads between tasks in a massively parallel or distributed database environment
CN108140035B (zh) * 2016-04-22 2020-09-29 华为技术有限公司 分布式系统的数据库复制方法及装置
RU2718215C2 (ru) 2018-09-14 2020-03-31 Общество С Ограниченной Ответственностью "Яндекс" Система обработки данных и способ обнаружения затора в системе обработки данных
RU2731321C2 (ru) 2018-09-14 2020-09-01 Общество С Ограниченной Ответственностью "Яндекс" Способ определения потенциальной неисправности запоминающего устройства
RU2721235C2 (ru) * 2018-10-09 2020-05-18 Общество С Ограниченной Ответственностью "Яндекс" Способ и система для маршрутизации и выполнения транзакций
RU2711348C1 (ru) 2018-10-15 2020-01-16 Общество С Ограниченной Ответственностью "Яндекс" Способ и система для обработки запросов в распределенной базе данных
RU2714373C1 (ru) 2018-12-13 2020-02-14 Общество С Ограниченной Ответственностью "Яндекс" Способ и система для планирования выполнения операций ввода/вывода
RU2749649C2 (ru) 2018-12-21 2021-06-16 Общество С Ограниченной Ответственностью "Яндекс" Способ и система для планирования обработки операций ввода/вывода
RU2720951C1 (ru) 2018-12-29 2020-05-15 Общество С Ограниченной Ответственностью "Яндекс" Способ и распределенная компьютерная система для обработки данных
RU2746042C1 (ru) 2019-02-06 2021-04-06 Общество С Ограниченной Ответственностью "Яндекс" Способ и система для передачи сообщения
US11436218B2 (en) * 2019-08-02 2022-09-06 Alibaba Group Holding Limited Transaction processing for a database distributed across availability zones
US11567899B2 (en) 2019-12-03 2023-01-31 Western Digital Technologies, Inc. Managing dependent delete operations among data stores
US11409711B2 (en) * 2019-12-03 2022-08-09 Western Digital Technologies, Inc. Barriers for dependent operations among sharded data stores
CN112988883B (zh) * 2019-12-16 2023-03-10 金篆信科有限责任公司 数据库的数据同步方法、装置以及存储介质
CN113934737A (zh) * 2020-06-29 2022-01-14 华为技术有限公司 一种数据库系统、管理事务的方法及装置
CN112084267B (zh) * 2020-07-29 2024-06-07 北京思特奇信息技术股份有限公司 解决分布式数据库全局广播的方法
CN112286992B (zh) * 2020-10-29 2021-08-24 星环信息科技(上海)股份有限公司 一种查询方法、分布式系统、设备及存储介质
WO2022120313A1 (en) * 2020-12-04 2022-06-09 Futurewei Technologies, Inc. Methods for distributed key-value store
CN114661816B (zh) * 2020-12-24 2023-03-24 金篆信科有限责任公司 数据同步方法、装置、电子设备、存储介质
CN114254036A (zh) * 2021-11-12 2022-03-29 阿里巴巴（中国）有限公司 数据处理方法以及系统
US11669518B1 (en) * 2021-12-14 2023-06-06 Huawei Technologies Co., Ltd. Method and system for processing database transactions in a distributed online transaction processing (OLTP) database
US11514080B1 (en) * 2022-05-31 2022-11-29 Snowflake Inc. Cross domain transactions
CN115237576A (zh) * 2022-08-10 2022-10-25 中国建设银行股份有限公司 一种串并行混合处理方法、装置、设备及介质
CN117131060A (zh) * 2023-07-26 2023-11-28 泽拓科技(深圳)有限责任公司 分布式数据库并发控制方法、系统、计算机设备
CN116701544B (zh) * 2023-08-07 2023-11-24 金篆信科有限责任公司 分布式数据库日志处理方法和装置、电子设备和存储介质

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2972744A1 (en) * 2013-03-14 2016-01-20 DSSD Inc. Method and system for object-based transactions in a storage system
CN106033437A (zh) * 2015-03-13 2016-10-19 阿里巴巴集团控股有限公司 一种分布式事务处理方法及系统
CN106462594A (zh) * 2014-04-10 2017-02-22 华为技术有限公司 一种大规模并行处理数据库的系统和方法
WO2017049911A1 (zh) * 2015-09-21 2017-03-30 中兴通讯股份有限公司 一种实现分布式事务的方法、装置及数据库服务器
WO2017063520A1 (zh) * 2015-10-15 2017-04-20 中兴通讯股份有限公司 数据库的操作方法及装置
CN106802932A (zh) * 2016-12-28 2017-06-06 华为技术有限公司 一种数据库的路由方法、装置及数据库系统
EP3185142A1 (en) * 2015-12-21 2017-06-28 Sap Se Distributed database transaction protocol

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8650155B2 (en) * 2008-02-26 2014-02-11 Oracle International Corporation Apparatus and method for log based replication of distributed transactions using globally acknowledged commits
US8713046B2 (en) * 2011-11-08 2014-04-29 Sybase, Inc. Snapshot isolation support for distributed query processing in a shared disk database cluster
US8935205B2 (en) * 2011-11-16 2015-01-13 Sap Ag System and method of performing snapshot isolation in distributed databases
US9792320B2 (en) * 2012-07-06 2017-10-17 Box, Inc. System and method for performing shard migration to support functions of a cloud-based service
US9348641B2 (en) * 2013-03-13 2016-05-24 Futurewei Technologies, Inc. System and method for performing a transaction in a massively parallel processing database
US20150120645A1 (en) * 2013-10-31 2015-04-30 Futurewei Technologies, Inc. System and Method for Creating a Distributed Transaction Manager Supporting Repeatable Read Isolation level in a MPP Database
EP3286664B1 (en) * 2015-04-20 2021-10-13 Oracle International Corporation System and method for providing access to a sharded database using a cache and a shard topology
US11829349B2 (en) 2015-05-11 2023-11-28 Oracle International Corporation Direct-connect functionality in a distributed database grid
US10496614B2 (en) * 2015-10-07 2019-12-03 Oracle International Corporation DDL processing in shared databases

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2972744A1 (en) * 2013-03-14 2016-01-20 DSSD Inc. Method and system for object-based transactions in a storage system
CN106462594A (zh) * 2014-04-10 2017-02-22 华为技术有限公司 一种大规模并行处理数据库的系统和方法
CN106033437A (zh) * 2015-03-13 2016-10-19 阿里巴巴集团控股有限公司 一种分布式事务处理方法及系统
WO2017049911A1 (zh) * 2015-09-21 2017-03-30 中兴通讯股份有限公司 一种实现分布式事务的方法、装置及数据库服务器
WO2017063520A1 (zh) * 2015-10-15 2017-04-20 中兴通讯股份有限公司 数据库的操作方法及装置
CN106598992A (zh) * 2015-10-15 2017-04-26 中兴通讯股份有限公司 数据库的操作方法及装置
EP3185142A1 (en) * 2015-12-21 2017-06-28 Sap Se Distributed database transaction protocol
CN106802932A (zh) * 2016-12-28 2017-06-06 华为技术有限公司 一种数据库的路由方法、装置及数据库系统

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
张剑 ; 刘梦赤 ; .面向信息网模型的高可扩展性分布式事务处理机制.计算机工程.2017,(11),全文. *
许冲 ; 衡星辰 ; .基于Oracle的分布式数据库透明性问题的研究.漳州师范学院学报(自然科学版).2010,(02),全文. *
韩媛 ; 王占昌 ; 杨博 ; 伍锦程 ; .浅谈基于Postgres-XL的分布式地质大数据集群架构.中国矿业.2017,(S1),全文. *

Also Published As

Publication number Publication date
EP3718024A4 (en) 2020-10-07
EP3718024A1 (en) 2020-10-07
CN111433764A (zh) 2020-07-17
US20190171763A1 (en) 2019-06-06
EP4270211A2 (en) 2023-11-01
WO2019109853A1 (en) 2019-06-13
US10810268B2 (en) 2020-10-20
EP3718024B1 (en) 2024-02-14
EP4270211A3 (en) 2023-11-22

Similar Documents

Publication Publication Date Title
CN111433764B (zh) 全局一致分片式oltp系统的高吞吐量分布式事务管理及其实现方法
US11372890B2 (en) Distributed database transaction protocol
EP3185143B1 (en) Decentralized transaction commit protocol
US11003689B2 (en) Distributed database transaction protocol
CN111338766B (zh) 事务处理方法、装置、计算机设备及存储介质
EP3413215B1 (en) Dynamic snapshot isolation protocol selection
US20210209092A1 (en) Client-driven commit of distributed write transactions in a database environment
CN111597015B (zh) 事务处理方法、装置、计算机设备及存储介质
Lin et al. Towards a non-2pc transaction management in distributed database systems
US20130110767A1 (en) Online Transaction Processing
Lee et al. High-Performance Transaction Processing in SAP HANA.
CN111159252A (zh) 事务执行方法、装置、计算机设备及存储介质
US11436218B2 (en) Transaction processing for a database distributed across availability zones
Chairunnanda et al. ConfluxDB: Multi-master replication for partitioned snapshot isolation databases
US11940972B2 (en) Execution of operations on partitioned tables
Nguyen et al. Detock: High Performance Multi-region Transactions at Scale
WO2021022396A1 (en) Transaction processing for database distributed across regions
Xian et al. Method of metadata synchronization in parallel distributed databases
Thomasian et al. Distributed Databases

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant