CN103116596B - 在分布式数据库中执行快照隔离的系统和方法 - Google Patents

在分布式数据库中执行快照隔离的系统和方法 Download PDF

Info

Publication number
CN103116596B
CN103116596B CN201210448601.XA CN201210448601A CN103116596B CN 103116596 B CN103116596 B CN 103116596B CN 201210448601 A CN201210448601 A CN 201210448601A CN 103116596 B CN103116596 B CN 103116596B
Authority
CN
China
Prior art keywords
node
distributed
nodal point
snapshot
transaction
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
CN201210448601.XA
Other languages
English (en)
Other versions
CN103116596A (zh
Inventor
S·希尔顿布兰德
C·宾尼格
F·费尔伯
D·科斯曼
J·李
N·梅
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.)
SAP SE
Original Assignee
SAP SE
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 SAP SE filed Critical SAP SE
Publication of CN103116596A publication Critical patent/CN103116596A/zh
Application granted granted Critical
Publication of CN103116596B publication Critical patent/CN103116596B/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/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating
    • G06F16/2308—Concurrency control
    • G06F16/2315—Optimistic concurrency control

Landscapes

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

Abstract

一种在分布式数据库中执行快照隔离的系统和方法。每个节点存储本地快照信息，其强制该节点的快照隔离。该方法包括：由第一节点部分地处理分布式事务；从协调器接收全局提交标识符；以及由第一节点和第二节点根据该全局提交标识符继续处理该分布式事务。

Description

在分布式数据库中执行快照隔离的系统和方法
技术领域
本发明涉及数据库，并且具体地，涉及分布式数据库中的快照隔离。
背景技术
除非这里指出，本部分中描述的方法不是本申请中权利要求的现有技术并且不因为包含在本部分中而被认为是现有技术。
快照隔离正成为大多数现代数据库系统中用于并行操作控制的事实标准。几乎所有的商业数据库都支持它。许多开源数据库系统也使用它。快照隔离允许某些不可串行化调度，但是这种警示对于多数应用程序而言是可以容忍的。在正面的方面，可以高效地实现快照隔离以使能高事务吞吐量。此外，快照隔离允许以无阻塞方式执行只读事务，它对于涉及对事务数据的长期决策支持查询的所谓的操作BI工作负载是重要的。
虽然快照隔离对于集中式数据库系统是好理解的，但是对于其中事务可以从多个节点读取并更新数据项目的分布式数据库系统还没有较多的探索。显然，随着正在呈现的在云端部署数据库并将所有数据保留在主存储器中的趋势，这样的分布式数据系统变得越来越重要。例如，对于存储器内数据库系统，分布式快照隔离是有用的，因为数据库可能无法装入单个机器的主存储器中，但是很可能可以装入由机器群簇提供的聚集主存储器中。
一种支持分布式快照隔离的商业数据库系统是Oracle(例如，Oracle数据库11gRelease2)。令人遗憾的是，Oracle没有发布实现和隔离性质的细节。在学术界，分布式快照隔离已经在R.Schenkel，G.Weikum，N.Weissenberg，以及X.Wu，“Federated TransactionManagement with Snapshot Isolation，inSelected papers from the EightInternational Wokrshop on Foundations of Modelsand Languages for Data andObjects，Transactions and Database Dynamics”，第1-25页(2000)[以下称为“Schenkel”]中讨论过(主要是在关联数据库的环境中)。在Schenkel中，将数据库作为黑匣子处理并且不考虑本地事务。
分布式快照隔离的三种一般方法是全局(global)法、悲观(pessimistic)法、和乐观(optimistic)法。下面对其作简要描述，细节可以在Schenkel中找到。
为了提供那些访问多于一个节点的事务的一致的快照，当前系统(例如，我们使用的商业数据库)需要协调所有事务。我们称该方法为全局法，因为使用发布全局有效的快照的(概念上)集中的协调器来实行协调。这是如下工作的：新的事务x在它的事务开始(begin-of-transaction)从中央协调器请求全局有效的快照。协调器是列举快照的仅有的一个，从而它可以发布这样的快照而无需联系本地节点。利用来自协调器的信息，事务x可以访问不发布它们自己的快照而是直接使用来自协调器的信息的本地节点。为了提交，系统与包括协调器的所有参与节点运行原子提交协议(例如，两阶段提交)。这样，协调器知晓所有提交并可以向新的事务提供正确的快照信息。全局法的优点是其简单性以及在所有场景中的生存力。
悲观法不同于全局法的一个重要方面是：中央协调器不是自己产生全局有效的快照，而是联系本地节点以协调分布式快照的建立。这意味着，只有分布式事务需要联系中央协调器，但是开始分布式事务的开销增加。该方法需要系统预先知晓哪些事务是分布式的、以及事务将要访问哪些节点。这是因为协调器为性能的原因而仅仅联系节点的最小集合以建立分布式快照。我们称该需求为完整先验知识(full a-priori knowledge)。如果访问的节点的集合未知，则不得不使用保守的候选集合，其限制性能。所有分布式事务的开始(begin)和提交(commit)操作由中央协调器同步。于是，在协调器准备用于事务x的分布式快照的同时，没有其他的分布式事务可以开始或提交。协调器通过在每个本地节点上发布事务开始操作来构建分布式快照。事务可以接着利用已准备的事务环境访问节点。为了提交，系统运行由协调器同步的原子提交协议。悲观法的优点在于，本地事务不与中央协调器交互作用，如果大部分事务是本地的则其改善性能。悲观法的示例构建部分数据库复制协议，即，在事务开始时，通知所有可能涉及的节点。参照J.E.Armendariz-Inigo，A.Mauch-Goya，J.R.Gonzalez de Mendivil，以及F.D.Munoz Escoi，SIPRe：“a partial databasereplication protocol with SI replicas，in Proceedings of the2008ACM symposiumon Applied Computing”，第2181-2185页(2008)。
为了去除对完整先验知识的需求，可以采用被称为乐观法的方法。基本思路在于，除了同步分布式事务提交的原子提交协议之外，事务运行无需协调器。在提交时刻，系统检测是否发生潜在异常。这可以通过在中央协调器上跟踪分布式事务的开始和提交操作的相对次序来实现。利用该方法，不需要确切的先验知识。然而，如果系统预先知晓哪些事务将成为分布式，从而可以将簿记限制于分布式事务，则可以改善性能。如果存在没有被两个事务访问的节点，则该算法拒绝任何两个并发事务中的一个。乐观法的优点在于，其不需要完整先验知识，但是仍然允许本地事务仅仅与它们的本地节点交互作用。此外，仅为想要提交的事务付出强制分布式快照隔离的开销。
在广义的快照隔离中，事务开始(即快照)与第一个实际操作分离。参看W.Elnikety，W.Zwaenepoel，以及F.Pedone，“Database Replication UsingGeneralizedSnapshot Isolation，in Proceedings of the 24th IEEE Symposium onReliableDistributed Systems”，第73-84页(2005)[以下称为“Elnikety”]。该开始仅可以早于第一个实际操作。
如果相同客户端的连续事务(即，相同会话)了解之前的事务写了什么以及快照隔离持有什么，则系统确保会话快照隔离。参照K.Daudjee和K.Salem，Lazy databasereplication with snapshot isolation，in VLDB，第715-726页(2006)[以下称为“Daudjee”]。该定义是有用的，因为普通快照隔离不需要客户得到最新快照。如果每个事务得到最新快照，则Daudjee称之为强快照隔离。
快照隔离已经在列存储数据库中执行。参照C.Zhang和H.de Sterck，Supportingmulti-row distributed transactions with global snapshot isolationusing bare-bones HBase，in GRID，第177-184页(2010年10月)[以下称为“Zhang1”]；以及C.Zhang和H.de Sterck，HBase SI：Multi-Row DistributedTransactions with Global StringSnapshot Isolation on Clouds，in ScalableComputing：Practice and Experience，12(2011)[以下称为“Zhang 2]”。该方式类似于全局法，因为关于事务的所有信息被保存在一束(概念上的)集中式表中。
系统在每个提交后打开虚拟事务，其可以随后用于处理来自需要较早快照的其他节点的请求。参照D.Serrano，M.Patino Martinez，R.Jimenez-Peris，以及B.Kemme，Boosting Database Replication Scalability through PartialReplication and 1-Copy-Snapshot-Isolation，in Proceedings of the 13th PacificRim InterationalSymposium on Dependable Computing，第290-297页(2007)。在该系统中，为了保持节点同步，他们使用群组通信来提交所有节点上的所有事务。
发明内容
鉴于上述背景，需要关于分布式数据库中的快照的改进。本发明的实施例针对用于分布式数据库的递增式快照隔离。
这里描述被称为递增法的一种用于分布式数据库中的快照隔离的方法。与现有方法相比，递增法需要较少的关于工作负载知识，同时提供比现有方法相同或较好的一致性保证。此外，性能试验显示递增法利用节点的数量提供可伸缩性。
递增式技术在两种情形下特别吸引人。第一种，如果多数事务仅涉及单个节点。如果数据库可以被合理地分割(即分区)，则出现该情形。例如，TPC-C基准程序(benchmark)模拟其中客户订购存货在不同仓库中的产品的应用程序。TPC-C基准程序的许多事务仅涉及存货在单个仓库中的产品。所以，如果每个节点代表一个仓库，则许多事务仅命中一个单独节点，并且只有很少事务涉及多于一个节点。递增式技术的优点在于，这样的局部事务如同在传统集中式数据库系统中一样高效地执行。只有实际访问来自多个节点的数据的事务需要支付用于全局同步的成本。
递增式技术的第二个优点在于，其不需要关于事务访问哪些节点的先验知识。为了保持分布式数据库系统中的透明度和数据独立，该性质至关重要。相比之下，不难理解，Schenkel中讨论的技术仅当其先验地知晓事务将要访问哪些节点时才显示出良好性能。
一个实施例是一种在分布式数据库中执行快照隔离的方法。该方法包括在硬件设备上实现节点，所述节点实现分布式数据库。该方法进一步包括由节点存储本地快照信息，其中对于特定节点，相应的本地快照信息强制该特定节点的快照隔离。该方法进一步包括由第一节点部分地处理分布式事务。该方法进一步包括由第一节点向硬件协调器发送访问第二节点的请求。该方法进一步包括由第一节点从该硬件协调器接收全局提交标识符。该方法进一步包括由第一节点和第二节点根据该全局提交标识符继续处理该分布式事务。以该方式，选择适当的快照用于执行事务。
所述硬件设备之一可以被配置为实现所述节点的至少两个。所述硬件设备之一可以被配置为实现所述节点之一。每个节点可以存储该分布式数据库的不同部分。
该全局提交标识符可以是多个全局提交标识符之一。每个全局提交标识符可以标识多个分布式事务的每一个的提交。该硬件协调器可以产生该全局提交标识符。该硬件协调器可以在多个分布式事务之一成功提交时产生该全局提交标识符。该硬件协调器可以在多个分布式事务成功提交时产生多个全局提交标识符。
第一节点可以在发送该请求之前检查另一个分布式事务还没有提交。
第一节点可以在继续处理该分布式事务之前检查另一个分布式事务还没有提交。
继续处理该分布式事务可以包括：由第一节点检查另一个分布式事务还没有提交；从第一节点向第二节点发送该局提交标识符；以及由第二节点根据在该全局提交标识符之前产生的第二节点上的本地快照信息的快照来处理该分布式事务。
该本地快照信息可以对应于所述节点上的分布式数据库的多个快照。
该本地快照信息可以对应于所述节点上递增地创建的分布式数据库的多个快照。
一种计算机系统可以操作以实现上述方法。该计算机系统可以存储、执行控制该计算机系统实现上述方法的一个或多个计算机程序，或者由该一个或多个计算机程序控制。
一种非暂时性计算机可读介质可以存储用于控制计算机系统执行上述方法的指令。所述指令包括分布式数据库组件和协调器组件。该分布式数据库组件和该协调器组件可以控制硬件设备和硬件协调器以实现上述方法。
以下详细说明和附图提供本发明本质和优点的更好理解。
附图说明
图1是用于递增式快照隔离的系统的框图；
图2示出串行并发模式异常的示例；
图3示出交叉异常的示例；
图4示出递增式快照的选择的示例；
图5A-5D示出第一选择方法的示例；
图6是用于递增式快照隔离的示例系统的框图；
图7是在分布式数据库中执行快照隔离方法的流程图；以及
图8是用于实现本发明实施例的示例计算机系统和网络2400的框图。
具体实施方式
1.介绍
这里描述用于分布式数据库中的快照隔离的技术。在下面的说明中，出于解释的目的，阐述许多示例和具体细节以便提供本发明的彻底理解。然而，本领域技术人员显然可知，如权利要求定义的本发明可以单独地、或与下面描述的其他特征结合地包括这些示例中的一些或所有特征，并且可以进一步包括这里描述的特征和概念的修改和等价物。
在本文件中，具体介绍了多种方法、处理和过程。虽然具体步骤可能以特定次序描述，但这样的次序主要是为了方便和清楚。特定步骤可以重复多于一次，可以在其他步骤之前或之后发生(即使那些步骤在另一个序列中描述)，并且可以与其他步骤并行发生。仅当第一步骤必须在第二步骤开始之前完成时，才要求第二步骤跟随第一步骤。当上下文不清楚时，这样的情况将被特别指出。个别步骤可以被忽略；仅当其省略将实质性地影响另一个步骤时才需要该个别步骤。
在本文件中，使用术语“和”、“或”以及“和/或”。这样的术语应当被理解为具有相同的意思；即，包含地。例如，“A和B”可以意味着至少以下：“既A又B”、“仅A”、“仅B”、“至少既A又B”。作为另一个示例，“A或B”可以意味着至少以下：“仅A”、“仅B”、“既A又B”、“至少既A又B”。当意指排他的或时，将特别指出(例如，“要么A要么B”，“A和B的最多一个”)。
在本文件中，描述多种计算机实现方法、处理和过程。应当理解，动作操作(接收、存储、发送、通信、显示等)由硬件设备来执行，即使该动作可以由用户授权、发起或触发，或者即使硬件设备由计算机程序、软件、固件等控制。进一步，应当理解，硬件设备在数据上操作，即使数据可以表示概念或现实世界对象，因而省略明确的标签如“数据”。例如，当硬件设备被描述为“存储记录”是，应当理解，硬件设备存储代表记录的数据。
2.问题声明
该部分给出用于我们的系统的客户端-服务器架构。此外，我们介绍必需的基础并给出可以在分布式快照隔离中发生的异常，之后是避免给出的异常的足够用于强制调度的一组正确性准则。
2.1架构
一般系统架构是实现快照隔离的分布式数据库。图1示出系统100的架构。几个客户端102访问系统100。系统100包括数据库104和中央协调器106。(该系统100还包括其他组件(未示出)，其执行下文中进一步讨论的诸如事务处理、事务管理、事务协调等功能；这些组件可以与中央协调器106由一个或多个硬件计算机来实现。)分布式意味着数据库104可以建立在虚拟地或物理地分离的多个节点108上。系统100具有对所有节点的完全控制并能够在那些节点内实现新的协议。这与其中节点自治地操作且不能被改变的联合(federated)系统(例如，如理解的在Schenkel中使用的)形成对比。网络110连接各种组件。
可以以这样的方式分割数据，以使得多数事务仅访问来自单个节点的数据。这是在多租用场景中的情况，其中在许多客户端(租户)之间共享一个数据库系统，并且他们的数据通常装在一个节点中。另外，一些系统数据在节点之间共享。因而，少量事务需要一致访问多于一个节点或者甚至整个数据库，例如，为了对提及的系统数据的更新。这样的可分割工作负载的另一示例是TPC-C基准程序。在该基准程序中，数据可以被仓库分割(即，分区)，并且多数事务仅访问来自一个仓库(即，一个节点)的数据。仅少量事务需要来自多于一个节点的数据。
为了实现访问来自多个节点数据的那些分布式事务的一致性，系统100提供分布式快照隔离。快照隔离的基本思路在于，每个事务获得其自己的(虚拟的)数据库“拷贝”用于工作，并且因此原则上不会被并发事务阻塞。(快照隔离的一些实施方式使用锁定，该情况下写入事务可能被阻塞)。在事务结尾，数据库仅当其写集合与其他并发事务没有冲突时才允许事务提交。
系统100可以支持数据的同步(eager)复制。其他实施例中可以支持异步(1azy)复制。
实施例使用中央协调器106用于特定任务。这样的中央协调器106可以被看作单个故障点。为了改善容错性，可以应用多种技术(例如，复制)，因为协调器106仅保持有限数量的状态。此外，中央协调器106也是潜在的瓶颈。实施例被设计为减少与协调器106的通信以便改善性能。
2.2预备
我们使用以下术语来指代不同种类的事务：分布式事务是访问(读或写)来自多于一个节点的数据的事务。这样的分布式事务被分割为在相同节点上执行的操作的子集。这些子集不是独立的，因而事务的语义(semantics)应用于整个操作集合(例如，如果事务被中止(abort)，则其在所有节点上的操作必须被复原)。本地事务是仅访问(读或写)来自单个节点的数据的事务。分布式快照是分布式数据库的多个节点上而不必是所有节点上的快照。
在记号方面，我们用x、y、z表示当前讨论的事务；用s、t表示用于完成进度所需、但是不被关注的事务；并用i、j表示节点。bx表示事务x的开始，同时cx表示事务x的提交。wx(a)和rx(b)表示事务x对对象a、b的写(或读)。操作的上标意味着给定操作在指定节点上发生，例如，是事务x在节点i上开始。N(x)包含由事务x访问的所有节点，即，x已经在其上访问对象的所有节点。SN(x，y)包含由x和y二者访问的(共享的)所有节点，即SN(x，y)＝N(x)∩N(y)。
系统100在每个节点108的实现本地快照隔离，即，由本地节点产生的调度在快照隔离下正确。集中式单节点系统中快照隔离的实现在过去已经被大量研究，并且所有主要数据库产品已经支持它。此外我们注意到，被中止的事务不改变调度或快照隔离方案的正确性，因而系统可以忽略由用户或应用程序引起的中止。
2.3分布式SI的定义
下面，我们将现有的本地快照隔离的定义扩展到分布式设置。访问该节点上的数据的本地事务以及分布式事务的操作子集形成本地调度。该调度的正确性被本地节点强制(即，本地快照隔离成立)。
定义1(分布式SI)。当且仅当存在组合所有本地调度的等效的单个调度、并且该单个调度根据本地快照隔离是正确的时，一组多个本地正确的调度在分布式快照隔离下正确。
该定义类似于所谓的1副本快照隔离，但是不限于复制的数据库。注意到，文章中的其他定义可以仅指代在复制的数据库环境中的操作。
注意到，定义1中的等效的单个调度从理论角度来看很有意思。在一些情况下，本地调度中的某些操作的次序可以被改变，例如，如果事务x不读或写由事务y写的任何对象，则事务x的开始可以要么早于要么晚于y的提交，因而对于一组本地调度可以有多于一个等效的全局调度。从实践角度来看，该“自由度”没有很大帮助，因为它总是需要检查读取关系(read-fromrelationship)，即，事务x是否读或写由事务y读或写的一些东西。监视该关系开销巨大，尤其是在分布式设置中。因而，第2.5小节中的正确性准则以及第3节中给出的方法不使用该自由度，并且仅仅允许或构建其中操作的本地次序不改变的调度。
2.4分布式设置中的异常
当将快照隔离应用于分布式数据库时发生的一种异常是串行并发模式(serial-concurrent-pattern)。如图2所示，如果事务x在节点1上与另一事务y并发运行并且在节点2上与其串行运行时，发生异常。因此，x不读取y在节点1上写入的东西，但是读取y在节点2上写入的东西。如果在节点2上事务y在事务x开始之前提交则发生上述情况。这可以导致在不同节点上相同的分布式事务读取的不一致的快照。第3节中给出的方法将提供用于避免这样的情形的机制。
在分布式设置中可以发生的另一种异常被称为交叉异常。在图3所示的示例中，分布式事务x在节点1上忽略本地事务s，并且在节点2上从本地事务t读取。同时，分布式事务y在节点1上从事务s读取，并且在节点2上忽略事务t。如果我们组合两个本地调度以使得用于事务x的快照是一致的，则事务t在s之前提交，因为x从t而不是从s读取。这意味着不存在用于从事务s读取而不是从事务t读取的事务y的一致的快照，因为如果y从s读取，则其必须从在s之前提交的所有事务(即，同样从t)读取。如果我们组合本地调度以使得用于事务y的快照是正确的，则反之亦然。
该异常仅当事务x、y实际读取事务s、t写入的东西时发生。但是如之前所述，监控读取关系开销巨大。因而，如果我们希望避免交叉异常，则系统必须确保分布式事务的开始事务次序在所有涉及的节点上是相同的。在第3节给出的方法当中，只有乐观法和多快照法允许该异常，而悲观法避免它。
2.5正确性准则
下面四个规则允许检查一组本地正确的调度根据分布式快照隔离(定义1)是否是正确的：
规则1：
规则2：
规则3：
规则4：
SN(x，y)是事务x和y二者访问的节点集合。
换句话说，分布式事务的所有开始(begin)和提交(commit)操作需要有总的次序，简而言之：如果一个操作(开始或提交)对于一个节点上的另一个操作是处于某一次序(即，之前或之后)，则另一个节点上的相应操作必须处于相同的次序。(除非，如果两个开始操作在一个节点上为特定次序，则它们还可以在其他节点上为同时，或为相同的次序。)
如果这四个条件对于系统中的所有事务x、y成立，则根据本地快照隔离是正确的本地调度集合根据分布式快照隔离是正确的。注意，所述规则由于忽略了来自读取关系的自由度而是充分的而非必要的，即，存在不满足这些规则的正确的调度(尤其是规则4产生许多不必要的拒绝)。如试验所示，这不限制吞吐量。替换的解决方案考虑读取关系，其监视开销巨大。
规则1确保我们可以使用提交ID来指代快照，并且快照包括所有之前提交的事务。规则2和3(与规则1一起)确保串行并发模式不会发生。规则4避免交叉异常。如图3所示，规则1-3本身不足以保证分布式快照隔离(定义1)，所以将规则4包括在内。
证明：我们现在简述四个规则足以保证分布式快照隔离的证明。基本思路在于，分布式事务的开始和提交操作在统一的调度中担当固定点。由于将它们一总排序(四个规则隐含了分布式事务的所有开始和提交操作之间的总次序)，总是可以将它们组合为单个调度而无需重新排序。接着可以在这些定点之间调度仅本地的操作。由于本地调度根据本地快照隔离是正确的，所以构建的调度因为数据的分割而同样是正确的。可以调度仅本地的操作而不改变来自相同节点的操作之间的次序，并且与其他节点上的操作独立，因为它们不会与来自另一个节点的本地事务共享共同的对象(读或写)。
3.递增式快照隔离
递增法是用于分布式快照隔离的新技术。递增法被设计用于其中多数事务是本地的、并且预先不知晓事务是本地的还是分布式的情形。递增法克服了其他方法的许多缺点，如下所述。
全局法的缺点在于，本地和分布式事务均必须联系中央协调器以获得全局有效快照，如果事务仅访问来自单个节点的数据则这构成开销。如果多数事务仅仅是本地的，则该开销限制整个系统的性能。
悲观法的缺点是需要额外的关于事务的先验知识。因而，必须改变协议以使得应用程序能提供额外的知识。这样的改变在现有系统中是不可能的。
乐观法的缺点在于，其不能防止交叉异常，即，其不提供与其他方法一样的一致性保障。
总的来说，递增法弥补了乐观法的缺点，即，交叉异常的潜在发生。同时，我们希望实现类似的性能而无需任何先验知识(即，无需预先知晓哪些事务将成为分布式的)。在递增法中，每个节点保存用于在本地强制快照隔离所需的本地信息。主要思路在于，事务在本地开始并且可以递增地请求访问其他节点上的数据。注意到，对另一个节点上的数据的访问并不立即向事务提供数据库的所有节点上的全局快照。它只是触发收集用于将快照扩展到其他节点所需的信息。
本地事务可以在相应的节点上处理而无需联系协调器106。对于分布式事务，递增法使用原子提交协议(例如，两阶段提交)来协调提交。更具体地，协调器106产生全局提交标识符以标识每个分布式事务的提交。GCID指代作为整个事务，而不只是提交本身。更具体地，GCID是所有分布式提交的枚举——每个提交的分布式事务获取下一个可用GCID。这意味着GCID总是在增加并且没有间隔(除了在提交协议失败时的非常奇特的情况下)。
另外，原子提交协议担当递增法中的第二个目的。重要的观点在于，事务x的分布式快照由其事务开始(begin-of-transaction)在其他分布式事务的(排序的)提交内的位置来定义。这类似于本地快照隔离在一些系统中(例如，Oracle Database11g Release2)的实现。本质上，在事务x开始之前提交的最后一个分布式事务的提交ID(CID；或Oracle中的系统更改编号SCN)捕获所有需要的信息。从另一个角度来看，事务x从x开始之前最后提交的事务y读取，并且忽略紧接着y之后提交的事务z。这定义了可以在其他节点上考虑的潜在的本地快照的时间间隔[y，z)。哪些事务被忽略的信息对我们来说更重要，因为在我们的方案中，不是所有事务在所有节点上提交。为了得到更近的快照，我们使用关于忽略什么而不是读取什么的信息。因而，如果事务需要访问来自另一个节点的数据，则其执行图4中给出的以下步骤(GCID代表全局提交ID，LCID代表本地提交ID)。
1.事务x请求访问来自节点2的数据。
2.系统100通过在本地检查从事务x开始以来是否有其他分布式事务被提交来计算事务x可以在其他节点上读取的快照的时间间隔[y，z)。
3.如果系统中尚未有稍后的提交，则系统询问中央协调器106其将要分配的下一个全局提交ID。问题在于，当事务希望访问来自另一个节点的数据时，关于时间间隔的上端点的信息通常在本地不可用，因为可能不存在其他分布式事务同时在该节点上提交。因此而，系统需要特别的关注以找出被x忽略的事务。
4.中央协调器106以其将要分配的下一个全局CID回应。协调器106分配的最后一个GCID是6(GCID2-5在图中被省略；它们与在其他节点上提交的事务关联)，使得协调器106分配GCID7.
5.系统100与协调器106通信期间再次在节点1上本地检查是否从系统100继续常规工作以来仍然没有其他提交的分布式事务。
6.如果没有稍后的提交，则x访问节点2，忽略协调器106返回的下一个分布式事务ID。如果另一个分布式事务z同时提交，则x忽略该分布式事务。在示例中，计算的时间间隔是[1，7)，因为x从事务1读取并且从此没有其他的分布式事务提交，于是其使用来自协调器106的响应。
7.系统100使用忽略事务7的最近快照作为节点2上用于事务x的快照，其在该情况下是本地事务9写入的内容。(注意到，GCID7本身没有示出，因为其与在另一个节点上提交的事务相关。)由于节点2将GCID12与LCID10关联，其使用早于LCID10的快照；与LCID9关联的快照是早于LCID10的最近的快照，所以使用该快照可以导致比选择与LCID7或8关联的快照更好的性能。下面是关于如何确切地选择本地快照的更具体的细节。
由于所有分布式事务的提交被集中协调(为了确保规则1成立)，产生全局有效CID不会有开销。使用上面描述的时间间隔[y，z)以及全局和本地事务标识符之间的映射，系统100可以通过构造用于事务x的本地快照(图4中的步骤6)来向给事务递增地添加更多节点。如果本地机制被适配为、或本地快照被构建为使得本地节点表现的好像事务真的在调度中计算的点开始，则系统100可以确保本地快照隔离。此外，系统100分配最近的快照给在时间间隔内的可能的事务以确保相同的快照在所有节点108上被选择。
如上所述，当分布式事务成功提交时(即，当所有节点同意提交并且协调器106决定提交时)，发布GCID。图4的示例省略了在其上其他分布式事务提交以递增GCID的其他节点。这说明系统100实现了递增法以选择使用合适的快照，因为如果仅涉及两个节点且没有其他的继续，则问题是平凡的。
取决于确切地选择本地快照，递增式技术可以实现为不同的变体。在下文中，我们详细描述被称为第一选择的一种变体。
3.1第一选择
第一选择法的主要思路在于，系统100允许分布式事务的两个提交之间的仅一个本地快照被其他分布式事务使用。因而，如果分布式事务x、y和z在相同节点i上执行，y从x读取且忽略z，其在所有其他节点上唯一地定义其本地快照。不需要用于这个的本地快照精确地是由x产生的快照。为此存在两个原因：a)分布式事务可能没有访问所有节点，因而分布式快照的本地部分对这些节点没有定义；以及b)只要我们可以确保分布式事务的开始在每个节点上是相同的次序，我们在快照中考虑仅本地的事务时就有一些自由，即，虽然快照在全局层面被唯一定义，但是本地实施可以递增地构建。
因而，如果事务y希望访问来自另一个节点的数据，则其执行如图5A-5D所示的下面的步骤：
图5A：事务y通过如上所述计算时间间隔[x，z)来计算其分布式快照，并且在节点3上指定其自己的快照为在x之后的一个。图中，圆圈502表示快照，并且*x代表指定的或标记的快照。
图5B：利用该信息，系统在节点2上构建事务y的快照如下：
-如果存在被指定为分布式快照z-1(在z之前提交的分布式事务)的本地部分的本地快照，则y使用该快照。
-如果没有这样的快照，则系统指定由在z之前提交的最晚本地事务产生的快照作为x之后的一个。图中，将区域504扩展到节点2，并且将数据库的相应状态标记为*x。
-如果节点2上没有事务z提交，则我们采用节点2上恰巧在下一个分布式事务提交之前的最晚本地快照，或者如果节点2上自此没有其他的分布式事务提交，则采用最近快照。这仍然是忽略z的快照，因为分布式提交被一总排序，因而系统知晓z没有访问节点2。
图5C：系统可以递增地添加更多节点到事务，例如，事务y可以在节点1上扩展其快照(图中较大的区域506和标签)。
图5D：注意到，如果其本地快照匹配其原始节点上指定的快照，或者如果其快照可以被提升为该指定的快照，则本地事务可以仅访问来自另一个节点的数据。因而，图5D中具有示出的快照的事务(圆圈508)不能访问来自另一个节点的数据，因为它不使用被标记为*x的指定快照。
正如本方法的名称，只有在两个分布式提交之间开始的第一次事务可以选择快照。如果这不可能，则操作失败(事务仍然可以在本地节点上继续，但是它不能访问其他节点)。为了理解该限制的理由，考虑下面的示例：如果我们允许具有与指定的快照不同的快照的来自节点i的事务x访问另一节点，则它的事务开始在节点i上与所有其他分布式事务的开始不同(为便于表述，假定它较早)，但是在所有其他节点上相同。如果现在另一个事务y被允许在不同节点j上进行相同操作，而且稍后x访问j(即)且y访问i(即)，则开始的顺序不相同。
当然这是非常约束性的，但是监视事务是否访问哪些节点的开销巨大。如果事务在其开始时通知系统它想要访问来自另一个节点的数据，则系统可以通过分配指定的快照给该事务来确保这是可能的。
第一选择法强制第2.5小节中建立的四个规则如下：通过集中协调所有分布式提交来强制规则1。通过在其访问的每个节点上的向事务x提供精确地包括x在任何其他节点上读取的全部分布式事务的快照来强制规则2和3(基于时间间隔以及总是选择时间间隔内最近的快照的规则)。通过为两个连续的分布式事务之间的每个时间间隔，将每个节点上快照的可能选择限定为单个快照，而强制规则4。因而，在相同的两个分布式提交之间开始的每个事务在所有节点上也采用相同快照。
第一选择法可以被视为对悲观法的改进。其具有相同的保证，但是偶尔提供更近的快照。递增地构建快照，而不是在事务开始时选择所有的快照。因而，我们可以考虑事务在其第一节点上工作的同时提交的其他节点上的一些本地事务。另外，该方法不需要任何先验知识，因为快照是递增地构建的。知晓事务是否最终访问来自其他节点的数据可以减少中止率但不是必需的。
递增(第一选择)法的值得注意的优点在于，仅仅需要协调分布式事务，并且之前不需要关于事务的知识，即，本地事务可以升级为分布式事务。递增法可以对应用程序透明地实现。缺点在于，该方法更复杂并且需要一些对底层数据库的改变。
3.2讨论以及比较
全局法、悲观法、乐观法以及递增法之间的主要区别是需要的关于事务的先验知识。悲观法需要关于事务开始之前访问的节点集合的精确的知识(或者必须假定安全的超集，或者如果不在初始节点集合中的节点被访问的话就中止该事务)。乐观法得益于事务是将要分布还是本地化的信息。递增法预先不需要关于事务的任何信息。
在保证方面，乐观法提供比其他方法更低等级的一致性，即，不防止交叉异常。
最后，这些方法在它们对时间点恢复的支持上不同。普通的恢复对所有方法是可能的，但是如果数据库的节点独立运行，则在特定时间点访问分布式数据库的状态更加困难。对于全局法，分配给所有事务的全局唯一的CID可以用于时间点恢复。在乐观法中，没有分布式数据库的一致视图，因此时间点恢复总是混乱的。在悲观法和递增法中，时间点恢复对分布式事务的提交是可能的。由于无论如何系统都发布全局CID用于分布式事务，这对于递增式几乎毫无开销。在任何情况下，仅为那些参与分布式事务的节点定义快照义。因而，完整的时间点恢复仅对涉及所有节点的分布式事务的提交是可能的。
系统100通过将事务的开始放在适合的位置而不是第一次操作发生的位置而使用类似于Elnikety的广义快照隔离的自由度。但是与其中开始仅可以较早的Elnikety的广义快照隔离相反，系统100还允许事务开始较晚(根据墙钟时间(wall clock time))以确保不超出限制的最近可能的快照。
系统100通过为每个事务提供仍然一致的最近快照而使用类似于Daudjee的对话快照隔离的实现。在一些情况下，这甚至可以是比Daudjee中的强快照隔离的定义允许的更近的快照，因为系统可以仅考虑本地事务，只要它们不破坏全局一致性。
系统100的实施例被组织为列存储。然而与使用全局法的Zhang1和Zhang2相比，系统100采用递增法。
与Schenkel相比，系统100的实施例考虑一个节点上的本地事务及多于一个节点上的分布式事务。用于本地事务的乐观法在某些实施例中很重要。
系统100的值得注意的区别是，尤其是与使用基于快照隔离的复制、但是在整个系统中实现较高的隔离等级的系统相比，我们最小化了在节点之间运送的关于事务的信息(例如，读-或写-集合)。这是我们的系统中值得注意的设计决策，因而我们无法实现比底层系统提供的更高的隔离水平。
4.示例配置
图6示出系统100的示例设置。系统100采用在两个服务器602a和602b上运行的数据库的8个实例(节点108)作为分布式数据库104，每个服务器具有32核以及256GB主存储器(即，4个实例共享一台机器)。每个实例彼此独立运行，在本地强制快照隔离。使用具有8核以及16GB主存储器的另一服务器作为驱动器(协调器)机器106，其包括所需的事务协调设施。事务的协调在该机器上集中并且使用普通OS锁来实现。数据库被组装成8个仓库并且通过仓库分割(即，每个实例一个仓库)。终端(客户端102)的数量被固定为32。更精确地，终端是客户端在其上输入它们的请求的系统，一次一个客户端。
更具体地，控制器106包括事务处理器610和事务协调器612。事务处理器610处理事务，例如作为用户与提供到使用分布式数据库104执行应用程序的应用程序服务器的接口的客户端机器交互作用的结果。事务可以因用户操作(创建指令、撤销指令等)、因系统请求(处理指令传递，新库存进入系统等)等而发生。事务处理器610将本地事务路由到各个节点，并将全局事务(访问多于一个节点)路由到事务协调器612。事务协调器612执行上述事务协调处理(产生GCID，图4和相关文本等)。
图7是在分布式数据库中执行快照隔离的方法700的流程图。方法700可以由系统100执行(参见图1、图6等)，例如由一个或多个计算机程序控制。
在702，多个硬件设备实现多个节点，该多个节点实现分布式数据库。例如，服务器602a和602b实现节点108，节点108实现分布式数据库104.
在704，节点存储本地快照信息。对于特定节点，对应的本地快照信息强制用于该特定节点的快照隔离。例如，每个节点108存储它们自己相应的本地快照新鲜。还参见图5A-5D。
在706，第一节点部分地处理事务。例如，在图4中节点1在LCID4正在部分地处理事务x。
在708，第一节点向硬件协调器发送访问第二节点的请求。例如，在图4中，节点1向协调器106发送访问节点2的请求。
在710，第一节点从硬件协调器接收全局提交标识符。例如，在图4中，节点1从协调器106接收GCID7。
在712，第一节点和第二节点根据全局提交标识符继续处理事务。例如，图4中，节点1使用GCID7来检查是否没有其他提交的分布式事务，而节点2使用GCID7来选择对应于LCID9的快照，用于处理事务x。
另外，注意到，不仅来自全局协调器106的信息，本地环境也可以影响用于在其他节点上恢复快照的GCID。例如，如果自x开始以来另一个事务已经在节点1上提交，则不必联系协调器106；使用该事务的GCID作为信息就够了。(相比于上面描述的用于联系协调器的情况，该情况较少发生。)
图8是用于实现本发明的实施例的示例计算机系统和网络2400的框图。计算机系统2410包括用于传递信息的总线2405或其他通信机制、以及耦接于总线2405用于处理信息的处理器2401。计算机系统2410还包括耦接于总线2405的存储器2402用于存储信息和将要由处理器2401执行的指令，包括用于执行上面描述的技术的信息和指令。该存储器还可以用于存储处理器2401执行的指令执行期间的临时变量或其他中间信息。该存储器的可能的实施方式可以是但不限于随机存取存储器(RAM)、只读存储器(ROM)(当不存储临时变量或其他中间信息时)、或两者。还提供存储设备2403用于存储信息和指令。存储设备的常见形式包括例如硬盘驱动器、磁盘、光盘、CD-ROM、DVD、闪存、USB存储卡、固态驱动器、或计算机可以读取的任何其他介质。例如，存储设备2403可以存储用于执行以上构建的技术或者具体表述的源代码、二进制代码、或软件文件。
计算机系统2410可以经由总线2405耦接到显示器2412，诸如阴极射线管(CRT)或液晶显示器(LCD)，用于显示信息给计算机用户。诸如键盘和/或鼠标的输入设备2411被耦接到总线2405用于将信息和指令选择从用户传递到处理器2401。这些组件的组合允许用户与系统通信。在一些系统中，总线2405可以被划分为多条专用总线。
计算机系统2410还包括耦接于总线2405的网络接口2404。网络接口2404可以在计算机系统2410与本地网络2420之间提供双向数据通信。例如，网络接口2404可以是数字用户线(DSL)或调制解调器，用于通过电话线提供数据通信连接。网络接口的另一个示例是局域网(LAN)卡，用于提供到兼容的LAN的数据通信连接。无线链路也可以是另一个示例。在任何这样的实施方式中，网络接口2404发送和接收携带表示各种类型信息的数字数据流的电子、电磁、或光信号。
计算机系统2410可以通过网络接口2404向内部网或互联网2430发送和接收包括消息或其他接口操作的信息。在互联网示例子中，软件组件或服务可以驻留在横跨网络的多个不同的计算机系统2410或服务器2431、2432、2433、2434和2435上。服务器2431可以通过互联网2430、本地网络2420、和网络接口2404从一个组件向计算机系统2410上的组件发送操作或消息。
计算机系统和网络2400可以以客户端服务器方式来配置。例如，计算机系统2410可以实现服务器。客户端2415可以包括类似于计算机系统2410的组件的组件。
更具体地，如上所述，计算机系统2410可以实现控制器106(参见图1)；服务器2431和2432可以实现分布式数据库；而客户端2415可以是客户端102之一。互联网2430可以是另一个本地网络。
以上说明描述了本发明的各种实施例以及如何实现本发明的各方面的示例。以上的示例和实施例不应当被认为是仅有的实施例，而是给出用于说明如所附权利要求限定的本发明的灵活性和优点。基于上述公开和所附权利要求，其他配置、实施例、实现以及等价物对于本领域技术人员而言是显而易见的，并且可以被采用而不背离如权利要求限定的本发明的精神和范围。

Claims (20)

1.一种在分布式数据库中执行快照隔离的计算机实现方法，包括：
在多个硬件设备上实现多个节点，该多个节点实现分布式数据库；
由该多个节点存储多个本地快照信息，其中对于特定节点，相应的本地快照信息强制该特定节点的快照隔离；
由该多个节点的第一节点部分地处理分布式事务；
由第一节点向硬件协调器发送访问该多个节点的第二节点的请求；
由第一节点从该硬件协调器接收全局提交标识符；
由第一节点和第二节点根据该全局提交标识符继续处理该分布式事务。
2.如权利要求1所述的计算机实现方法，其中该多个硬件设备之一被配置为实现该多个节点的至少两个。
3.如权利要求1所述的计算机实现方法，其中该多个硬件设备之一被配置为实现该多个节点之一。
4.如权利要求1所述的计算机实现方法，其中该多个节点的每一个存储该分布式数据库的不同部分。
5.如权利要求1所述的计算机实现方法，其中该全局提交标识符是多个全局提交标识符之一，其中该多个全局提交标识符的每一个标识多个分布式事务的每一个的提交。
6.如权利要求1所述的计算机实现方法，进一步包括：
由该硬件协调器产生该全局提交标识符。
7.如权利要求1所述的计算机实现方法，进一步包括：
当多个分布式事务之一提交成功时，由该硬件协调器产生该全局提交标识符。
8.如权利要求1所述的计算机实现方法，其中该全局提交标识符是多个全局提交标识符之一，进一步包括：
当多个分布式事务提交成功时，由该硬件协调器产生该多个全局提交标识符。
9.如权利要求1所述的计算机实现方法，进一步包括：
在发送该请求之前，由第一节点检查另一个分布式事务还没有提交。
10.如权利要求1所述的计算机实现方法，进一步包括：
在继续处理该分布式事务之前，由第一节点检查另一个分布式事务还没有提交。
11.如权利要求1所述的计算机实现方法，其中继续处理该分布式事务包括：
由第一节点检查另一个分布式事务还没有提交；
从第一节点向第二节点发送该全局提交标识符；以及
由第二节点根据在该全局提交标识符之前产生的第二节点上的多个本地快照信息的快照来处理该分布式事务。
12.如权利要求1所述的计算机实现方法，其中该多个本地快照信息对应于该多个节点上的该分布式数据库的多个快照。
13.如权利要求1所述的计算机实现方法，其中该多个本地快照信息对应于在该多个节点上递增地创建的该分布式数据库的多个快照。
14.一种在分布式数据库中执行快照隔离的系统，包括：
多个硬件设备，被配置为实现多个节点，该多个节点实现分布式数据库；以及
硬件协调器，被配置为产生全局提交标识符，
其中，该多个节点被配置为存储多个本地快照信息，其中对于特定节点，相应的本地快照信息强制该特定节点的快照隔离，
其中，该多个节点的第一节点被配置为部分地处理分布式事务，
其中，第一节点被配置为向该硬件协调器发送访问该多个节点的第二节点的请求，
其中，第一节点被配置为从该硬件协调器接收该全局提交标识符，而且
其中，第一节点和第二节点被配置为根据该全局提交标识符继续处理该分布式事务。
15.如权利要求14所述的系统，其中该硬件协调器包括：
事务控制器，被配置为产生该全局提交标识符；以及
事务处理器，被配置为将本地事务路由到该多个节点之一，并将该分布式事务路由到该事务控制器。
16.如权利要求14所述的系统，其中该全局提交标识符是多个全局提交标识符之一，其中该多个全局提交标识符的每一个标识多个分布式事务的每一个的提交。
17.如权利要求14所述的系统，其中该多个本地快照信息对应于该多个节点上的该分布式数据库的多个快照。
18.如权利要求14所述的系统，其中第一节点被配置为检查另一个分布式事务还没有提交，
其中，第一节点被配置为向第二节点发送该全局提交标识符，而且
其中，第二节点被配置为根据在该全局提交标识符之前产生的第二节点上的多个本地快照信息的快照来处理该分布式事务。
19.一种用于控制在分布式数据库中执行快照隔离的计算机系统，包括：
分布式数据库组件，被配置为控制多个硬件设备在多个节点上实现分布式数据库；以及
协调器组件，被配置为控制硬件协调器产生全局提交标识符，
其中，该分布式数据库组件被配置为该控制多个节点存储多个本地快照信息，其中对于特定节点，相应的本地快照信息强制该特定节点的快照隔离，
其中，该分布式数据库组件被配置为控制该多个节点的第一节点部分地处理分布式事务，
其中，该分布式数据库组件被配置为控制第一节点向该硬件协调器发送访问该多个节点的第二节点的请求，
其中，该分布式数据库组件被配置为控制第一节点从该硬件协调器接收该全局提交标识符，而且
其中，该分布式数据库组件被配置为控制第一节点和第二节点根据该全局提交标识符继续处理该分布式事务。
20.如权利要求19所述的计算机系统，其中该协调器组件包括：
事务控制器组件，被配置为控制该硬件协调器产生该全局提交标识符；以及
事务处理器组件，被配置为控制该硬件协调器将本地事务路由到该多个节点之一，并将该分布式事务路由到该事务控制器。
CN201210448601.XA 2011-11-16 2012-09-28 在分布式数据库中执行快照隔离的系统和方法 Active CN103116596B (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US13/298,048 2011-11-16
US13/298,048 US8935205B2 (en) 2011-11-16 2011-11-16 System and method of performing snapshot isolation in distributed databases

Publications (2)

Publication Number Publication Date
CN103116596A CN103116596A (zh) 2013-05-22
CN103116596B true CN103116596B (zh) 2017-05-03

Family

ID=47010130

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201210448601.XA Active CN103116596B (zh) 2011-11-16 2012-09-28 在分布式数据库中执行快照隔离的系统和方法

Country Status (3)

Country Link
US (1) US8935205B2 (zh)
EP (1) EP2595068B1 (zh)
CN (1) CN103116596B (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108600012A (zh) * 2018-04-26 2018-09-28 深圳光华普惠科技有限公司 微服务架构监控系统
CN110168514A (zh) * 2017-06-05 2019-08-23 华为技术有限公司 一种事务处理方法、装置及设备

Families Citing this family (61)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
ES2584102T3 (es) * 2011-11-18 2016-09-23 Universidad Politécnica de Madrid Sistema y método para procesamiento transaccional de baja contención y descentralizado altamente escalable
US9769292B2 (en) 2012-01-19 2017-09-19 Miosoft Corporation Concurrent process execution
US8935207B2 (en) 2013-02-14 2015-01-13 Sap Se Inspecting replicated data
US9348641B2 (en) * 2013-03-13 2016-05-24 Futurewei Technologies, Inc. System and method for performing a transaction in a massively parallel processing database
US20140280398A1 (en) * 2013-03-15 2014-09-18 Miosoft Corporation Distributed database management
CN103294479A (zh) * 2013-06-19 2013-09-11 成都市欧冠信息技术有限责任公司 分布式事务处理方法与系统
US9317549B2 (en) 2013-06-25 2016-04-19 Optumsoft, Inc. Constraint-based consistency with snapshot isolation
US9563452B2 (en) 2013-06-28 2017-02-07 Sap Se Cloud-enabled, distributed and high-availability system with virtual machine checkpointing
US9659050B2 (en) 2013-08-06 2017-05-23 Sybase, Inc. Delta store giving row-level versioning semantics to a non-row-level versioning underlying store
CN103559245A (zh) * 2013-10-29 2014-02-05 华为技术有限公司 一种分布式事务提交故障的处理方法、装置和系统
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
US10191765B2 (en) 2013-11-22 2019-01-29 Sap Se Transaction commit operations with thread decoupling and grouping of I/O requests
US10331695B1 (en) * 2013-11-25 2019-06-25 Amazon Technologies, Inc. Replication coordination service for data transfers between distributed databases
US10049033B2 (en) 2014-06-03 2018-08-14 Sap Se Application gateway for cloud computing systems
CN104657483B (zh) * 2015-02-28 2018-06-15 华为技术有限公司 处理事务的方法、处理节点、中心节点和集群
US10282364B2 (en) 2015-04-28 2019-05-07 Microsoft Technology Licensing, Llc. Transactional replicator
US10268743B2 (en) 2015-06-19 2019-04-23 Sap Se Distributed database transaction protocol
US10169439B2 (en) 2015-06-19 2019-01-01 Sap Se Multi-source asynchronous table replication
AU2016292786B2 (en) * 2015-07-10 2019-05-23 Ab Initio Technology Llc Method and architecture for providing database access control in a network with a distributed database system
US10320702B2 (en) * 2015-09-30 2019-06-11 Veritas Technologies, LLC Input/output fencing optimization
EP3373148A4 (en) * 2015-11-05 2019-05-15 Murakumo Corporation DATABASE SYSTEM, TRANSACTION MANAGEMENT NODES, PROCEDURES AND PROGRAM
US10970311B2 (en) * 2015-12-07 2021-04-06 International Business Machines Corporation Scalable snapshot isolation on non-transactional NoSQL
US10795881B2 (en) 2015-12-18 2020-10-06 Sap Se Table replication in a database environment
US10235440B2 (en) 2015-12-21 2019-03-19 Sap Se Decentralized transaction commit protocol
US10572510B2 (en) 2015-12-21 2020-02-25 Sap Se Distributed database transaction protocol
US10394775B2 (en) * 2015-12-28 2019-08-27 International Business Machines Corporation Order constraint for transaction processing with snapshot isolation on non-transactional NoSQL servers
US10585876B2 (en) * 2016-04-07 2020-03-10 International Business Machines Corporation Providing snapshot isolation to a database management system
US10552413B2 (en) 2016-05-09 2020-02-04 Sap Se Database workload capture and replay
US10298702B2 (en) 2016-07-05 2019-05-21 Sap Se Parallelized replay of captured database workload
US10255237B2 (en) * 2016-07-06 2019-04-09 Sap Se Isolation level support in distributed database system
US10305861B2 (en) 2016-08-29 2019-05-28 Microsoft Technology Licensing, Llc. Cross-tenant data leakage isolation
US10503725B2 (en) * 2016-10-13 2019-12-10 Futurewei Technologies, Inc. Decentralized distributed database consistency
US10452636B2 (en) * 2016-11-28 2019-10-22 Sap Se Delayed snapshot isolation for read service at a database
US10761946B2 (en) 2017-02-10 2020-09-01 Sap Se Transaction commit protocol with recoverable commit identifier
US10592528B2 (en) 2017-02-27 2020-03-17 Sap Se Workload capture and replay for replicated database systems
US10423609B1 (en) * 2017-03-29 2019-09-24 Amazon Technologies, Inc. Consistent snapshot points in a distributed storage service
US10558641B2 (en) 2017-04-21 2020-02-11 Microsoft Technology Licensing, Llc Trigger system for databases using proxy
US10585873B2 (en) 2017-05-08 2020-03-10 Sap Se Atomic processing of compound database transactions that modify a metadata entity
US11573947B2 (en) 2017-05-08 2023-02-07 Sap Se Adaptive query routing in a replicated database environment
US10936578B2 (en) 2017-06-01 2021-03-02 Sap Se Client-driven commit of distributed write transactions in a database environment
US10977227B2 (en) 2017-06-06 2021-04-13 Sap Se Dynamic snapshot isolation protocol selection
CN109408201B (zh) * 2017-08-18 2022-07-12 中国银联股份有限公司 基于分布式数据库的事务管理方法
CN107609176B (zh) * 2017-09-29 2019-09-13 郑州云海信息技术有限公司 一种本地存储快照分布式存储的方法及系统
US10621167B2 (en) * 2017-10-26 2020-04-14 Sap Se Data separation and write redirection in multi-tenancy database systems
US10810268B2 (en) * 2017-12-06 2020-10-20 Futurewei Technologies, Inc. High-throughput distributed transaction management for globally consistent sharded OLTP system and method of implementing
WO2019178839A1 (zh) * 2018-03-23 2019-09-26 华为技术有限公司 为分布式应用创建一致性快照的方法、装置和分布式系统
US10698892B2 (en) 2018-04-10 2020-06-30 Sap Se Order-independent multi-record hash generation and data filtering
US11061777B2 (en) * 2018-07-30 2021-07-13 Nutanix, Inc. Method and product for implementing application consistent snapshots of a sharded relational database across two or more storage clusters
US11016952B2 (en) 2019-01-31 2021-05-25 Rubrik, Inc. Systems and methods to process a topology change in a clustered database
US10997130B2 (en) * 2019-01-31 2021-05-04 Rubrik, Inc. Systems and methods for node consistency in a clustered database
US11514024B2 (en) 2019-01-31 2022-11-29 Rubrik, Inc. Systems and methods for shard consistency in a clustered database
US11347705B2 (en) 2019-04-02 2022-05-31 Sap Se Supporting scalable distributed secondary index using replication engine for high-performance distributed database systems
US11874796B1 (en) * 2019-09-27 2024-01-16 Amazon Technologies, Inc. Efficient garbage collection in optimistic multi-writer database systems
US11693876B2 (en) 2020-01-10 2023-07-04 Sap Se Efficient shared bulk loading into optimized storage
US11709752B2 (en) 2020-04-02 2023-07-25 Sap Se Pause and resume in database system workload capture and replay
US11615012B2 (en) 2020-04-03 2023-03-28 Sap Se Preprocessing in database system workload capture and replay
US11550762B2 (en) 2021-02-24 2023-01-10 Sap Se Implementation of data access metrics for automated physical database design
CN113157699A (zh) * 2021-04-25 2021-07-23 上海淇玥信息技术有限公司 一种业务数据审核方法、装置和电子设备
CN116303754A (zh) * 2021-12-10 2023-06-23 中兴通讯股份有限公司 数据库的事务快照生成方法、装置、设备及存储介质
US11438224B1 (en) 2022-01-14 2022-09-06 Bank Of America Corporation Systems and methods for synchronizing configurations across multiple computing clusters
WO2023146653A1 (en) * 2022-01-31 2023-08-03 Discover Financial Services Trace context over file transfer communications

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6976074B2 (en) * 2001-10-16 2005-12-13 Microsoft Corporation Systems and methods for negotiating transactions between nodes
US7899822B2 (en) * 2006-09-08 2011-03-01 International Business Machines Corporation Automatically linking documents with relevant structured information
US8713046B2 (en) * 2011-11-08 2014-04-29 Sybase, Inc. Snapshot isolation support for distributed query processing in a shared disk database cluster

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
A Critique of ANSI SQL Isolation Levels;Hal Berenson 等;《SIGMOD’95 Proceedings of the 1995 ACM SIGMOD international conference on Management of data》;19950531;第24卷(第2期);1-12 *
强快照与强提交读隔离的多键云事务实现方法;杨义繁 等;《计算机科学与探索》;20110915(第9期);815-825 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110168514A (zh) * 2017-06-05 2019-08-23 华为技术有限公司 一种事务处理方法、装置及设备
CN108600012A (zh) * 2018-04-26 2018-09-28 深圳光华普惠科技有限公司 微服务架构监控系统

Also Published As

Publication number Publication date
EP2595068A3 (en) 2014-06-11
EP2595068B1 (en) 2019-01-02
CN103116596A (zh) 2013-05-22
US20130124475A1 (en) 2013-05-16
EP2595068A2 (en) 2013-05-22
US8935205B2 (en) 2015-01-13

Similar Documents

Publication Publication Date Title
CN103116596B (zh) 在分布式数据库中执行快照隔离的系统和方法
CN108804112B (zh) 一种区块链落账处理方法及系统
KR102437664B1 (ko) 멀티테넌트 어플리케이션 서버 환경에서 트랜잭션 복구를 위한 시스템 및 방법
US10031935B1 (en) Customer-requested partitioning of journal-based storage systems
Baker et al. Megastore: Providing scalable, highly available storage for interactive services.
US9582520B1 (en) Transaction model for data stores using distributed file systems
Bichsel et al. A simple algorithm for shape from shading
EP3120261B1 (en) Dependency-aware transaction batching for data replication
CN109656911A (zh) 分布式并行处理数据库系统及其数据处理方法
CN104216955B (zh) 一种操作数据及管理事务的方法、装置及分布式系统
US20130110873A1 (en) Method and system for data storage and management
Yan et al. Carousel: Low-latency transaction processing for globally-distributed data
US20080215586A1 (en) Simulating Multi-User Activity While Maintaining Original Linear Request Order for Asynchronous Transactional Events
CN112654978B (zh) 分布式异构存储系统中数据一致性实时检查的方法、设备和系统
US20060190460A1 (en) Method and mechanism of handling reporting transactions in database systems
US20100169289A1 (en) Two Phase Commit With Grid Elements
Waqas et al. Transaction management techniques and practices in current cloud computing environments: A survey
Srinivasan et al. Citrusleaf: A real-time nosql db which preserves acid
US10235407B1 (en) Distributed storage system journal forking
Kaur et al. Concurrency control in distributed database system
CN114375444A (zh) 用于文档数据库中的垃圾删除的方法和系统
Lwin et al. Non-redundant dynamic fragment allocation with horizontal partition in Distributed Database System
Yang From Google file system to omega: a decade of advancement in big data management at Google
Pankowski Consistency and availability of Data in replicated NoSQL databases
Li et al. Hadoop-Based University Ideological and Political Big Data Platform Design and Behavior Pattern Mining

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C53 Correction of patent for invention or patent application
CB02 Change of applicant information

Address after: German Waldo

Applicant after: SAP AG

Address before: German Waldo

Applicant before: SAP AG

COR Change of bibliographic data

Free format text: CORRECT: APPLICANT; FROM: SAP AG TO: SAP EUROPE AG

GR01 Patent grant
GR01 Patent grant