CN111868707A - 在关系数据库的主键中包括事务提交时间戳 - Google Patents

在关系数据库的主键中包括事务提交时间戳 Download PDF

Info

Publication number
CN111868707A
CN111868707A CN201880091104.4A CN201880091104A CN111868707A CN 111868707 A CN111868707 A CN 111868707A CN 201880091104 A CN201880091104 A CN 201880091104A CN 111868707 A CN111868707 A CN 111868707A
Authority
CN
China
Prior art keywords
transaction
commit
server
timestamp
participant
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.)
Pending
Application number
CN201880091104.4A
Other languages
English (en)
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.)
Google LLC
Original Assignee
Google LLC
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 Google LLC filed Critical Google LLC
Publication of CN111868707A publication Critical patent/CN111868707A/zh
Pending legal-status Critical Current

Links

Images

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
    • G06F16/2322—Optimistic concurrency control using timestamps
    • 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/22—Indexing; Data structures therefor; Storage structures
    • G06F16/221—Column-oriented storage; Management thereof
    • 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/2358—Change logging, detection, and notification
    • 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/2365—Ensuring data consistency and integrity
    • 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/28—Databases characterised by their database models, e.g. relational or object models
    • G06F16/284—Relational databases

Landscapes

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

Abstract

在分布式数据库中，将在第一协调器服务器和一个或多个参与者服务器处提交事务1210。第一协调器服务器被配置为接收在相应的准备时间戳处事务的每个参与者服务器已准备好的通知，该相应的准备时间戳在相应的参与者服务器获得至少一个锁的时间范围内被选择1220。第一协调器服务器计算等于或大于每个准备时间戳的用于事务的提交时间戳1230，并且限制提交时间戳使得在共享分片处共享用于一个或多个其他事务的至少一个参与者服务器的第二协调器服务器不能选择相同的提交时间戳用于任何其他事务1240。该事务在提交时间戳处被提交1250。

Description

在关系数据库的主键中包括事务提交时间戳
背景技术
在数据库系统中，并发控制是指用于解决由于允许同时访问数据库中的数据项而引起的冲突的技术(“并发”)。并发控制确保尽管允许同时访问，但数据库的行为始终如一。多版本并发控制技术存储给定数据片的多个版本(每次写入一个)，以实现更大的并发性。提供绝对时间全局概念的系统可以与分布式数据库中的多版本并发控制集成。生成的分布式数据库在语义上等效于单机数据库，因为可以跨整个数据库进行一致的读取。
发明内容
本公开提供了一种方法，包括：在分布式系统中的第一协调器服务器和一个或多个参与者服务器处接收提交事务的请求，从参与者服务器中的每个接收通知，所述通知包括相应的准备时间戳，该相应的准备时间戳在相应的参与者服务器获得至少一个锁的时间范围内被选择，计算等于或大于每个准备时间戳的用于事务的提交时间戳，限制提交时间戳使得在共享分片处共享用于一个或多个其他事务的至少一个参与者服务器的第二协调器服务器无法为任何其他事务选择相同的提交时间戳，以及在第一协调器服务器处和参与者服务器中的每个处在提交时间戳处提交事务。至少一个锁可以是写共享锁。提交事务的请求还可以包括突变以更新记录该事务的变更日志。可以将提交时间戳包括为变更日志的主键。变更日志的至少一部分可以被存储在参与者服务器中的一个处。提交事务的请求还可以包括突变以更新记录该事务的多个变更日志。该方法还可以包括在关系数据库中添加至少一个列以在关系数据库中将提交时间戳存储为主键。
该方法还可以包括计算事务的事务ID的哈希值，以及通过事务ID的哈希值进一步限制用于事务的提交时间戳。例如，进一步限制提交时间戳可以包括：将提交时间戳的预定数量的较低比特设置为等于事务ID的哈希值。
该方法还可以包括：确定第一协调器服务器接收到提交其他事务的一个或多个请求，以及计算用于在第一协调器服务器处接收到的其他事务中的每个的提交时间戳，使得提交时间戳之间的总间隔基本上被最小化。
该方法还可以包括：在共享参与者服务器处确定事务ID的哈希值等于其他事务中的至少一个的事务ID的哈希值；以及，在共享参与者服务器处防止具有相同的哈希值的至少一个其他事务获取锁直到事务提交。
该方法还可以包括：在一个或多个参与者服务器处确定要在参与者服务器处提交单站点事务，计算具有用于该单站点事务的预定模式的单站点提交时间戳，该预定模式是任何多站点事务都不能选择作为其提交时间戳的模式，以及在单站点提交时间戳处提交单站点事务。
该方法还可以包括：在一个或多个参与者服务器处确定要在参与者服务器处提交单站点事务；计算该单站点事务的事务ID的哈希值；以及，通过单站点事务的事务ID的哈希值来限制用于单站点事务的提交时间戳。例如，限制用于单站点事务的提交时间戳可以包括：将单站点事务的提交时间戳的预定数量的较低比特设置为等于单站点事务的事务ID的哈希值。
本公开还提供了一种方法，所述方法包括：在分布式系统中的协调器服务器和一个或多个参与者服务器处接收提交事务的请求，由参与者服务器中的每个在从本地选择的开始时间开始到预定上限的时间范围内获得至少一个排他锁，在协调器服务器处接收参与者服务器中的每个在该时间范围内的相应本地选择的准备时间戳处已准备好的通知，在协调器服务器处计算等于或大于准备时间戳中的每个的用于事务的提交时间戳，在协调器服务器处以及参与者服务器中的每个处在提交时间戳处提交该事务，以及在参与者服务器中的每个处释放至少一个排他锁。预定的上限可以是无穷大。提交事务的请求还可以包括突变以更新记录该事务的变更日志。该方法还可以包括在关系数据库中添加至少一个列以在关系数据库中将提交时间戳存储为主键。
本公开还提供了一种系统，其包括多个服务器中的第一协调器服务器，服务器中的每个适于在分布式计算环境中彼此通信以及与客户端通信，第一协调器服务器包括一个或多个处理器，一个或多个处理器被配置为：接收提交事务的请求；接收充当事务的参与者的其他服务器中的任何一个在相应的准备时间戳处已准备好的通知，该相应的准备时间戳在相应的参与者服务器获得至少一个锁的时间范围内被选择；计算等于或大于准备时间戳中的每个的用于该事务的提交时间戳，使得在共享分片处共享用于一个或多个其他事务的参与者服务器中的至少一个的第二协调器服务器不能为任何其他事务选择相同的提交时间戳；以及在提交时间戳处提交事务。一个或多个处理器还可以被配置为计算事务的事务ID的哈希值，以及通过事务ID的哈希值进一步限制用于事务的提交时间戳。一个或多个处理器还可以被配置为确定在第一协调器服务器处接收到提交其他事务的一个或多个请求，以及计算用于其他事务中的每个的提交时间戳，使得提交时间戳之间的总间隔基本上被最小化。分布式计算环境可以包括关系数据库，其中，一个或多个处理器可以还被配置为在关系数据库中添加至少一个列以在关系数据库中将提交时间戳存储为主键。
该系统可以还包括参与者服务器，该参与者服务器包括一个或多个处理器，该处理器被配置为：确定要在参与者服务器处提交单站点事务；计算具有用于单站点事务的预定模式的单站点提交时间戳，该预定模式是任何多站点事务都不能选择作为其提交时间戳的模式；以及在单站点提交时间戳处提交单站点事务。
附图说明
图1是图示根据本公开的方面的示例系统的框图。
图2是图示根据本公开的方面的数据库的分布的示意图。
图3是图示根据本公开的方面的分布式数据库中的服务器之间的层级关系的框图。
图4是图示根据本公开的方面的示例系统的框图。
图5是图示根据本公开的方面的示例系统的框图。
图6是图示根据本公开的方面的示例系统的框图。
图7是图示根据本公开的方面的示例系统的框图。
图8是图示根据本公开的方面的示例系统的框图。
图9是图示根据本公开的方面的示例系统的框图。
图10是图示根据本公开的方面的示例系统的框图。
图11是图示根据本公开的方面的示例系统的示意图。
图12是图示根据本公开的方面的示例方法的流程图。
具体实施方式
该技术通常涉及确定提交时间戳并且将提交时间戳提供给分布式数据库的用户的方法。例如，用户可以使用提交时间戳来查看在各个时间点处的数据库的快照，或者构建事务日志用于对数据库所做的变更。为了向用户提供有意义的提交时间戳，同一数据项的每个事务必须对应于唯一的提交时间戳。这样，用户可以使用这些提交时间戳在不同的特定时间戳处读取数据的不同版本，或者查看对数据项所做的所有变更。此外，提供了确定有意义的提交时间戳以确保不损害数据库的吞吐量的有效方法。
在分布式数据库中，将在第一协调器服务器和一个或多个参与者服务器处提交事务。第一协调器服务器被配置为接收通知：事务的每个参与者服务器是在相应准备时间戳处准备的，该相应准备时间戳是在相应参与者服务器获得至少一个锁的时间范围内选择的。第一协调器服务器计算等于或大于每个准备时间戳的事务的提交时间戳，并限制提交时间戳，以使在共享分片处共享用于一个或多个其他事务的至少一个参与者服务器的第二协调器服务器无法为任何其他事务选择相同的提交时间戳。
在分布式数据库中，在多个分片中读取和/或写入数据，这些分片分布在数据中心的分布式网络中的多个计算设备(例如服务器)上。在某些情况下，可以在多个服务器上复制相同的分片以防止数据丢失，以防其中一台服务器发生故障的情况。每个服务器可以存储和执行用于多个分片和/或分片副本的动作。单个分片的副本的全体形成一个组在读取和/或写入多个分片的多站点事务中，可以选择存储分片中的一个的服务器中的一个(或存储组中的一个的多个服务器)作为“协调器服务器”(或“协调器服务器组”)，而选择存储其他分片的所有其他服务器(或存储其他组的多个服务器)作为“参与者服务器”(或“参与者服务器组”)。尽管可以选择服务器(或服务器组)作为用于一个或多个事务的协调器服务器(或协调器服务器组)，但也可以同时将服务器(或服务器组)选择为用于一个或多个其他事务的参与者服务器(或参与者服务器组)。为简单起见，从此以后，可互换使用“分片”与“组”，可互换使用“协调器服务器”与“协调器服务器组”，可互换使用“参与者服务器”与“参与者服务器组”。
当在用于多站点事务的协调器服务器和参与者服务器处接收到事务的提交消息时，协调器服务器和参与者服务器每个可以在从获取锁的时间直到上限的范围内获取锁。每个参与者服务器都可以在本地选择一个准备时间戳，写入准备的记录，并通知协调器服务器其从准备时间戳起及其以后已准备好。一旦协调器服务器收到所有参与者服务器都已准备好的准备通知，则协调器服务器可以选择等于或大于任何准备时间戳以及它先前已指配给其他事务的任何提交时间戳的提交时间戳。然后，协调器服务器和参与者服务器中的每个在提交时间戳处执行事务。除了作为用于多站点事务的参与者服务器之外，存储分片的服务器还可以在分片处接收本地提交单站点事务的请求。
确保在共享分片处为各种多站点和/或单站点事务选择唯一提交时间戳的一种示例方法是仅允许分布式事务的参与者服务器在直到提交时间戳被选择的一定时间范围内在共享分片处获取排他锁。例如，每个参与者服务器可以从本地选择的开始时间到无穷大，或者从本地选择的开始时间到估计的上限中获取排他锁。
在另一示例方法中，参与者服务器可以在共享分片处获取共享锁，但是在某些情况下可以选择的提交时间戳受到限制。例如，协调器服务器可以限制用于多站点事务的提交时间戳，以使在共享分片处共享同一参与者服务器的其他任何协调器服务器都不能为另一个多站点事务选择相同的提交时间戳。例如，协调器服务器可以通过下述方式来如此进行：计算事务的事务ID的哈希值，然后通过查找下一个可用时间来计算提交时间戳，该下一个可用时间等于或大于其较低N比特(例如，较低的10比特)等于哈希值的任何准备时间戳。在其他示例中，用于单站点事务的提交时间戳也可能受到限制。例如，可以为单站点事务指配时间戳，这些时间戳可以从可以被选择用于多站点事务的时间戳中排除。在另一个示例中，接收到提交多个事务的请求的协调器服务器可以为每个事务选择提交时间戳，以使得所有提交时间戳之间的总间隔基本上被最小化。
为了防止两个协调器服务器选择相同的提交时间戳(“时间戳冲突”)，例如，在如果两个事务ID哈希到相同的值(“哈希冲突”)的事件中，参与者服务器可以获取排他锁用于事务中的一个。在另一示例中，可以允许参与者服务器仅对第一事务获取写共享限制锁，并且将第二事务放置在等待队列中，直到参与者服务器释放在第一事务上的写共享限制锁。
在另一示例方法中，具有共享的参与者服务器和共享的分片的协调器服务器可以彼此通信以确保选择唯一的提交时间戳。在另一示例方法中，全局管理器可以选择所有提交时间戳以确保提交时间戳是唯一的。
可以在表的一个或多个列中向用户提供提交时间戳。例如，可以在主键列中提供提交时间戳，这意味着提交时间戳必须是唯一的。一个特定示例涉及变更日志，用户可以维护该变更日志以跟踪在数据库中所做的所有变更，其中，可以在变更日志的一个或多个列中提供提交时间戳。例如，用户可以请求事务来修改某些数据项，并且还可以在该事务请求中包括变异，以将事务记录在变更日志中。对于另一个示例，用户可以请求跨越多个数据库的事务，并且在该事务请求中包括一个变异，以更新每个数据库的单独的变更日志。对于另一个示例，通常希望通过表行创建时间来查询关系数据库。例如，提供了具有用于将表行创建时间戳包括在关系数据库的主键中的机制的方法和系统。关系数据库可以是分布式数据库的一部分。将提交时间戳作为行创建时间戳包含在关系数据库的主键中是有利的，因为指定主键约束是查询关系数据库的非常有效的方法。根据本文描述的方法和系统，提供了用于数据库中的提交时间戳的模式(schema)，以通过允许模式向数据库添加列以将提交时间戳存储在数据库中来使提交时间戳在数据库查询和读取中可读。使用提交时间戳作为关系分布式数据库中的主键具有多个优点。一个优点是提交时间戳提供了简单的保证。如果事务A的提交时间戳比另一个事务B的提交时间戳低，则事务A在B之前被提交。因此，用户可以将分布式数据库视为单机数据库对待，并假定事务A发生的所有突变对事务B都是可见的。换句话说，本文描述的方法和系统提供了以与提交时间戳一致的串行顺序原子地执行事务的外观，并允许应用程序开发人员为分布式数据库系统中的所有事务建立全局的部分顺序。另一个优点是，如果提交时间戳基于全局同步时钟，这确保提交时间戳在全局范围内是准确且一致的，从而使用户不受运行数据库分片的不同服务器上的时钟偏移的影响。
该技术是有利的，因为它在不显著损害分布式数据库的吞吐量的情况下向用户提供了有意义的提交时间戳。尽管用户的数据库可能被高度分布，但是用户可以使用提交时间戳来查看对各种数据项所做的变更，就好像数据库被保存在单机上一样。该技术还例如通过下述方式提供了各种方法以提高效率：避免排他锁、最小化提交时间戳之间的间隔以及为多站点和单站点事务提供不同的处理方式。
示例系统
图1图示包括分布式数据库的示例系统。多个计算设备(例如服务器140、150、160)可以例如通过网络130彼此通信。服务器140、150、160还可以与多个客户端计算设备(例如客户端110、120)通信。服务器140-160可以控制一个或多个数据库中的数据存储。例如，如图所示，每个服务器140-160与数据中心142、152、162相关联。每个数据中心142、152、162可以包括用于存储数据的多个计算设备。在分布式数据库中，数据库的数据项可以被分片到多个不同的分片上，例如分片146、156、166，每个分片可以被复制到一个数据中心(例如数据中心142)上的多个计算设备(例如服务器)上，或跨多个数据中心(例如数据中心142、152和162)被复制。
每个服务器可以存储并执行针对多个分片和/或分片副本的动作。单个分片的副本的全体形成一个组，例如，组148包含一个分片的所有副本，组158包含另一个分片的所有副本，组168包含又一个分片的所有副本。分片副本可以通过使用共识协议(例如Paxos协议)进行同步。尽管某些分片可能是其他分片的副本，但某些分片可能在因果上依赖于其他分片。例如，写入数据中心142中(例如，写入分片146或组148中)的数据比特可能会影响存储在数据中心152中(例如，存储在分片156或组158中)的数据。分布式数据库可以实现协议(例如Paxos)来在整个系统中达成共识。在一些当前系统中，数据中心142、152、162之间的一致性由服务器140、150、160保持，它们在发布写事务之前等待一段时间(例如，提交等待)过去。在其他系统中，可以改为将等待时间强加于一个或多个其他设备上，及时移至服务器的不同动作，或移至试图读取写入数据的客户端设备。
尽管仅示出了具有几个服务器、客户端、分片和组的几个数据中心，但是分布式数据库中可以包括任意数量的数据中心，每个数据中心可以包含多个服务器(可以与多个客户端进行通信)、分片和组。类似地，尽管每个服务器140、150、160被示为与其自己的数据中心相关联，但是应当理解，在其他示例中，服务器可以与一个或多个较小的数据库相关联。例如，一个数据库可以包括多个服务器。
客户端110、120中的每一个被示为具有应用程序112、122和客户端库114、124，尽管应当理解，也可以存在客户端设备的附加特征。客户端110、120中的任何一个都可以通过经由网络130向服务器140、150、160中的一个发送数据来将数据写入分布式数据库。尽管仅示出了几个客户端，但是应当理解，大量客户端设备可以通过网络130与分布式数据库通信。
数据中心142、152、162可以被定位成彼此相距相当大的距离。例如，如结合图2进一步描述的，数据中心可以位于世界各地的各个国家。每个数据中心142、152、162可以包括多个存储设备，例如硬盘驱动器、随机存取存储器、磁盘、磁盘阵列、磁带驱动器或任何其他类型的存储设备。数据中心142、152、162可以实现许多体系结构和技术中的任何一种，包括但不限于直接附加存储(DAS)、网络附加存储(NAS)、存储区域网络(SAN)、光纤通道(FC)、以太网光纤通道(FCoE)或混合体系结构网络等。除了存储设备之外，数据中心还可以包括许多其他设备，例如电缆、路由器等。此外，在某些示例中，数据中心142、152、162可以是虚拟化环境。
每个服务器具有本地时钟144、154、164。每个本地时钟144、154、164可以从原子时间主控器190导出其时间。原子时间主控器190例如可以是与分布式数据库中的一个或多个服务器通信的参考时钟。如下面结合图3进一步描述的，原子时间主控器190可以从诸如GPS的另一源导出其时间。
图2是位于地球上各个位置处的数据中心210、220、230、240、250、260和270的地理示意图200。根据一些示例，每个数据中心可以包括原子时间主控器。每个原子时间主控器可以连接到诸如GPS接收器的接收器，以接收时间信号。GPS接收器可以包括例如屋顶安装的天线215、225、235、245、255、265和275，其可以位于数据中心210、220、230、240、250、260和270上方的屋顶上。主机服务器可以被安置在位于数据中心210、220、230、240、250、260和270的服务器机架中。这样，可以安装管线以将天线电缆从主机服务器路由到屋顶天线。跨多个接收器共享一个天线可以是可能的。例如，这可以通过天线分离器来实现。
图3示出了跨数据中心提供紧密同步的全局时钟的时间平台300的示例。在该示例中，时间平台300被构造为服务器的三级层次结构，每个服务器包括其自己的时钟，其中，子级服务器根据其父级时钟来校准其时钟。应用程序在主机360、370、380上运行。
箭头从校准其时钟的服务器指向具有更好时钟(从其校准它们)的众所周知的服务器。例如，如图所示，主机360基于原子主控器392来校准其时钟。原子主控器392基于GPS时间主控器302、304来校准其时钟。主机370基于原子主控器394和396来校准其时钟。原子主控器394基于GPS时间主控器304来校准其时钟。主机380基于原子主控器396来校准其时钟，原子主控器396基于GPS时间主控器306来校准其时钟。在一些示例中，子级服务器可以基于例如地理位置、信号强度或其他任何标记来确定要使用哪些父级服务器进行校准。在其他示例中，子/父配对可以是预定的。尽管图3示出了校准到原子主控器392、394、396的主机360、370、380，但应理解，在其他示例中，主机360、370、380可以额外地或替选地直接校准到GPS时间主控器302、304、306。
在层次结构的每个级别上，校准包括轮询服务器的父级，以及与从父级接收的一个或多个时间间隔相交，并通过来自所涉及主机的校准网络等待时间进行扩展。每个服务器可能具有关联的值(ε)，该值表示该服务器的本地时钟所反映的时间与数据库中其他服务器的时钟所反映的时间之间的最大时间差。每台服务器的ε值都导出自其父级的ε，具有对来自振荡器频率不确定性和有效校准间隔的乘积以及服务器到父级网络往返时间(RTT)的不确定性的调整。因此，在一些示例中，每个服务器处的本地时钟可能维持不同的ε值。在其他示例中，ε在系统中的各个设备之间可能是全局一致的。此外，在一些示例中，随着诸如振荡器频率不确定性、有效校准间隔和RTT之类的参数随时间变化，ε可以随时间变化。
可以将振荡器频率不确定性建模为包括频率不稳定性(例如，振荡器在短时间范围内漂移了多少)以及振荡器老化(例如振荡器漂移在长时间范围内改变了多少)等等。有效校准间隔可以由以下两个值中的较大者确定：校准间隔(例如服务器校准之间的时间段)以及服务器不得不与父级服务器断开连接的时间长度。
关于服务器到父级网络的RTT，主机离其父级越远，引入的相位不确定性就越大。该不确定性也可以建模为两个分量：校准相位不确定性和校准频率不确定性。校准相位不确定性可以对应于计算振荡器的相位对准时的不确定性水平。由于校准周期的持续时间中的不确定性，校准频率不确定性可以对应于频率不确定性的水平。
图4是用于向用户提供分布式数据库的提交时间戳的示例系统400的图。如图所示，系统400的示例可以包括耦合到网络450的多个服务器410和470。服务器410和470可以位于不同的数据中心，例如数据中心142和152。该系统还可以包括客户端460，其能够通过网络450与服务器410和470通信。
服务器410可以包含处理器420、存储器430、时钟435和通用计算机中通常存在的其他组件。存储器430可以存储处理器420可访问的信息，包括可以由处理器420执行的指令432。存储器还可以包括可以由处理器420检索、操纵或存储的数据434。存储器430可以是能够存储处理器420可访问的信息的一种类型的非暂时性计算机可读介质，例如硬盘驱动器、固态驱动器、磁带驱动器、光学存储、存储卡、ROM、RAM、DVD、CD-ROM、能够写入和只读存储器。处理器420可以是众所周知的处理器或其他鲜为人知的类型的处理器。替代地，处理器420可以是专用控制器，例如ASIC。
指令432可以是由处理器420直接执行的指令集，例如机器代码，或间接执行的指令集，例如脚本。就这一点而言，术语“指令”、“步骤”和“程序”可以在本文中可互换地使用。指令432可以以目标代码格式存储，以供处理器420直接处理，或者以其他类型的计算机语言存储，包括脚本或独立源代码模块的集合，这些脚本或独立源代码模块的集合按需进行解释或预先编译。指令的功能、方法和例程在上述示例和以下示例方法中进行了更详细的说明。
处理器420可以根据指令432检索、存储或修改数据434。例如，尽管系统和方法不受特定数据结构的限制，但是数据434可以被存储在计算机寄存器中、在关系数据库中，作为具有多个不同字段和记录的表或XML文件。数据434还可被格式化为计算机可读格式，例如但不限于二进制值、ASCII或Unicode。此外，数据434可以包括足以识别相关信息的信息，例如数字、描述性文本、专有代码、指针、对存储在其他存储器中的数据的引用，包括其他网络位置，或者功能用于计算相关数据的信息。例如，数据434可包括时间数据，该时间数据可基于指令432以用于描述时刻的时间格式(例如，协调世界时、Unix历元(epoch)和明确的国际原子时间历元)进行编码。
尽管图4在功能上将处理器420和存储器430示为在同一块内，但是处理器420和存储器430实际上可以包括可以或可以不存储在同一物理壳体内的多个处理器和存储器。例如，某些指令432和数据434可以被存储在可移动CD-ROM上，而其他指令可以被存储在只读计算机芯片中。一些或全部指令和数据可以被存储在物理上远离处理器420但仍可被处理器420访问的位置。类似地，处理器420实际上可以包括处理器的集合，该处理器的集合可以并行或可以不并行地操作。
服务器410和470可以位于网络450的一个节点上，并且能够与网络450的其他节点直接和间接通信。例如，服务器410和470可以包括能够经由网络450与客户端设备460通信使得其使用网络450将信息传输到客户端应用的Web服务器。服务器410和470还可以包括多个计算机，例如负载平衡服务器场，其与网络450的不同节点交换信息，以便接收、处理数据并将数据传输到客户端设备。在这种情况下，客户端计算机通常将与构成服务器410和470的计算机位于网络450的不同节点上。尽管在图4中仅示出了几个服务器410、470，但是应当理解，典型的系统可以包括大量连接的服务器，每个服务器位于网络450的不同节点上。
类似于服务器410和470，每个客户端460可以被配置有处理器462、存储器463、指令464和数据467。每个客户端460可以是个人计算机，旨在由人使用，具有通常在个人计算机中找到的全部内部组件，例如中央处理器(CPU)、CD-ROM、硬盘驱动器和显示设备465(例如，具有屏幕的监视器、投影仪、触摸屏、小LCD屏幕、电视或诸如可操作以显示由处理器462、扬声器、调制解调器和/或网络接口设备处理的信息的电子设备的其他设备)、用户输入组件466(例如，鼠标、键盘、触摸屏或麦克风)以及用于将这些元件相互连接的所有组件。此外，根据本文所述的系统和方法的计算机可以包括能够处理指令并且向人和其他计算机或从人或其他计算机传输数据的设备，包括通用计算机、PDA、平板电脑、移动电话、智能手表、缺乏本地存储功能的网络计算机、电视机的机顶盒和其他联网设备。
客户端460可以包括应用接口模块468。应用接口模块可以用于访问由服务器(例如服务器410和470)使得可用的服务。例如，应用接口模块可以包括子例程、数据结构、对象类和用于允许服务器和客户端相互通信的其他类型的软件组件。一方面，应用接口模块468可以是结合本领域中已知的几种类型的操作系统可操作的软件模块。例如，客户端460可以被连接到结构化查询语言(SQL)数据库服务器，该结构化查询语言(SQL)数据库服务器可以与应用接口模块468结合操作以保存和检索信息数据。耦合到客户端460的存储器463可以存储由应用接口模块468访问的数据467。数据467还可以存储在可以连接到客户端460的可移动介质上，例如磁盘、磁带、SD卡或CD-ROM。
服务器410和470与客户端460能够例如通过网络450进行直接和间接通信。例如，使用因特网套接字，客户端460可以通过因特网协议套件连接到在远程服务器410和470上运行的服务。服务器410和470可以设置侦听套接字，该侦听套接字可以接受用于发送和接收信息的发起连接。网络450和中间节点可以包括各种配置和协议，包括因特网、万维网、内联网、虚拟专用网、广域网、局域网、使用对一个或多个公司专有的通信协议的专用网、以太网、WiFi(例如802.81、802.81b、g、n或其他此类标准)和HTTP以及上述各项的各种组合。能够与其他计算机之间来回传输数据的设备可以促进这种通信，该设备例如是调制解调器(例如，拨号、电缆或光纤)和无线接口。
尽管图4将计算设备410和460示为单独的块，每个块都包含其自己的处理器和存储器，但是本文所述的操作可能涉及单个计算设备或多个计算设备，例如在“云”中。例如，本文描述为涉及单个计算设备(例如，单个服务器中的单个中央处理单元(CPU))的各种操作可以涉及多个计算设备(例如，负载平衡服务器场中的多个处理器)。类似地，位于不同位置的存储器组件可以存储指令432的不同部分，并共同形成用于存储指令的介质。在一些示例中，设备460可以用作瘦客户端，其中，设备410执行与经由用户输入组件466和显示器465从用户接收信息并向用户提供信息不直接相关的所有或几乎所有操作。本文描述为由计算设备执行的各种操作可以由虚拟机执行。举例来说，指令432可以特定于第一类型的服务器，但是相关的操作可以由运行模拟该第一类型的服务器的管理程序的第二类型的服务器执行。该操作还可以由容器执行，例如，不依赖于绑定到特定类型的硬件的操作系统的计算环境。
图5示出了处理多站点事务的示例分布式系统。客户端(例如客户端110)可以发送请求(例如请求1)以读取和/或写入其分区分布在不同数据中心处(例如，分别在数据中心142、152、162处的分片146、156、166处)的数据项。为了清楚起见，在该示例中，分片146、156、166被示为位于不同的数据中心，但是如上所述，各种分片也可以存储在同一数据中心的多个服务器中。客户端110可以选择存储分片中的一个的服务器中的一个作为“协调器服务器”，例如，在数据中心142处的存储分片146的服务器，而选择存储事务的其他分片的所有其他服务器作为“参与者服务器”，例如，数据中心152处的存储分片156的服务器和数据中心162处的存储分片166的服务器。在存储分片146的协调器服务器和存储分片156和166的参与者服务器处接收到用于多站点事务的提交消息时，存储分片146的协调器服务器和存储分片156和166的参与者服务器每个可以在一定时间范围内获取相应的锁。每个锁的时间范围可以是从获得相应的锁的时间直到无穷大或上限。参与者服务器每个可以在相应的锁的时间范围内本地选择准备时间戳(T1、T2)，写入准备的记录，并通知存储分片146的协调器服务器(如虚线箭头510和520所示)它们从其相应的准备时间戳(T1、T2)起及其以后已准备好。相应的准备时间戳可以被选择为已本地获取锁的时间，或者可替选地可以被选择为已将有关事务的信息记录在参与者服务器处的时间。代替获取一个锁，每个服务器可以获取多个锁，例如，如果事务请求变更到分片的多个单元，则存储分片的服务器可以为每个单元获取锁。一旦存储分片146的协调器服务器接收到准备好存储分片156、166的所有参与者服务器的准备通知，则存储分片146的协调器服务器可以选择等于或大于任何准备时间戳(T1、T2)以及它先前已指配给其他事务的任何提交时间戳的提交时间戳(Tc)，并且将提交时间戳(Tc)通知给存储分片156和166的参与者服务器中的每个(如虚线箭头550和552所示)。存储分片146的协调器服务器和存储分片156、166的参与者服务器中的每个然后在提交时间戳(Tc)处执行事务。
数据项或数据项的分区上的锁可以是排他锁或共享锁。排他锁不允许任何其他事务访问相同的数据项或分区，即使其他事务仅请求共享锁也是如此。因此，排他锁强制将事务序列化。数据项或分区上的共享锁允许其他事务也使用共享锁访问同一数据项或分区。因此，共享锁促进事务并行化，从而提高效率。共享锁可以是读共享锁或写共享锁。由于多个事务可以并行处理，因此写共享锁可用于提供有效的盲写(例如，在不先读取值的情况下修改值的写)。例如，如图5所示，可以配置存储分片146的协调器服务器，使得它不能选择相同的提交时间戳用于它对其也充当协调器的任何其他事务，因此，存储分片146的协调器服务器可以获取写共享锁。
尽管在该示例中，相对于分片146、156和166示出了系统的操作，但是上述相同的系统操作对于分片副本也同样适用，例如，分别存储组148、158和168的服务器组可以以与分别存储分片146、156和166的服务器相同的如图5所示的方式操作。
图6示出了示例分布式系统，该分布式系统处理两个多站点事务，其中，两个不同的协调器服务器在共享分片处共享同一参与者服务器。如上所述，客户端110可以发送请求1以读取和/或写入其分区分布在不同数据中心处(例如，分别在数据中心142、152、162的分片146、156、166处)的数据项。客户端110选择将数据中心142处的存储分片146的服务器作为第一协调器服务器，并将数据中心152处的存储分片156的服务器和数据中心162处的存储分片166的服务器选择为参与者服务器。一旦存储分片146的第一协调器服务器从存储分片156、166的所有参与者服务器接收到它们在其相应的时间戳(T1、T2)处已准备好的准备通知，如虚线箭头610和620所示，则存储分片146的第一协调器服务器可以根据请求1选择提交时间戳(Tc)来提交事务，并向存储分片156和166的参与者服务器中的每个通知提交时间戳(Tc)，如虚线箭头650和652所示。然而，在提交根据请求1的事务之前，另一个客户端(例如客户端120)也可以发送请求(例如请求2)以读取和/或写入其分区分布在不同数据中心处(例如，分别位于数据中心152、172、182处的分片156、176和186处)的数据项。客户端120可以选择将数据中心172处的存储分片176的服务器作为第二协调器服务器，以及将数据中心152处的存储分片156的服务器和数据中心182处的存储分片186的服务器作为参与者服务器。存储分片172的第二协调器服务器和存储分片156和186的参与者服务器每个可以在一个时间范围内获取锁。每个锁的时间范围可以是从获得相应的锁的时间直到无穷大或上限。存储分片156和186的参与者服务器每个可以在相应的时间范围内本地选择准备时间戳(T3、T4)，写入准备的记录，并通知存储分片176的第二协调器服务器(如虚线箭头630和640所示)它们从其相应的准备时间戳(T3、T4)起及其以后已准备好。相应的准备时间戳可以被选择为已本地获取锁的时间，或者可替选地可以被选择为已将有关事务的信息记录在参与者服务器处的时间。代替获取一个锁，每个服务器可以获取多个锁，例如，如果事务请求变更到分片的多个单元，则服务器可以为每个单元获取锁。一旦存储分片176的第二协调器服务器接收到存储分片156和186的参与者服务器都已准备好的准备通知，则存储分片176的第二协调器服务器可以选择等于或大于准备时间戳(T3、T4)以及它先前已指配给其他事务的任何提交时间戳的提交时间戳(Tc2)，并且将提交时间戳(Tc2)通知给存储分片156和186的参与者服务器中的每个(如虚线箭头660和662所示)。为清楚起见，分片146、156、166、176和186在该示例中被示为位于不同的数据中心，但是如上所述，各种分片也可以存储在同一数据中心的多个服务器中。尽管在此示例中，针对分片146、156、166、176和186示出了系统的操作，但上述系统操作同样适用于分片副本(组)。
然而，存在存储分片176的第二协调器服务器选择与由存储分片146的第一协调器服务器选择的Tc相同的Tc2的机会，从而在存储分片156的参与者服务器处引起“时间戳冲突”，存储分片156的参与者服务器由用于两个不同的多站点事务的第一协调器服务器和第二协调器服务器两者共享。在共享的参与者服务器处的共享分片处的这种时间戳冲突可能会导致问题。首先，如果在共享参与者服务器上的共享分片(例如分片156)处选择了相同的提交时间戳用于两个事务，则一个事务将覆盖另一个事务，使得在提交时间戳Tc处的读取将仅显示两个事务中的一个。另一个结果是，如果有多于一个的共享参与者服务器用于两个多站点事务，则共享参与者服务器中的每个可能选择以不同的顺序执行两个事务，从而产生不一致的结果。尽管示出请求1和请求2来自不同的客户端，但它们也可能来自同一客户端。
图7示出了处理多站点事务和单站点事务的示例分布式系统。如上所述，客户端110可以发送请求1以读取和/或写入其分区分布在不同数据中心处(例如，分别在数据中心142、152、162的分片146、156、166处)的数据项。为了清楚起见，在该示例中，分片146、156、166被示为位于不同的数据中心，但是如上所述，各种分片也可以存储在同一数据中心的多个服务器中。客户端110选择数据中心142处的存储分片146的服务器作为协调器服务器，并且选择数据中心152处的存储分片156的服务器和数据中心162处的存储分片166的服务器作为参与者服务器。一旦存储分片146的协调器服务器接收到所有存储分片156、166的参与者服务器在其相应的时间戳(T1、T2)处都已准备好的准备通知，如虚线箭头710和720所示，则存储分片146的协调器服务器可以根据请求1选择提交时间戳(Tc)来提交事务，并向存储分片156和166的参与者服务器中的每个通知该提交时间戳(Tc)，如虚线箭头750和752所示。然而，诸如客户端120的另一个客户端也可以发送请求，例如请求3，以读取和/或写入仅存储在数据中心152的分片156处的某些数据项。如果存储分片156的参与者服务器根据请求3选择提交时间戳(Tc3)用于单站点事务，该时间戳恰好与由存储分片146的协调器服务器选择的Tc相同，则在这种情况下也可能发生时间戳冲突。如上所述，这种时间戳冲突的一个负面结果是，一个事务将覆盖另一个事务，使得在提交时间戳Tc处的读取将仅显示两个事务中的一个。尽管示出请求1和请求3来自不同的客户端，但它们也可能来自同一客户端。
图8示出了示例分布式系统，该分布式系统被配置为通过仅允许参与者服务器获取排他锁来防止如图6所示的在共享参与者服务器处的两个多站点事务之间的时间戳冲突。为了清楚起见，仅示出了存储分片146的第一协调器服务器、存储分片176的第二协调器服务器以及它们的存储分片156的共享参与者服务器。从上到下按时间顺序描述了每个服务器处的事件顺序。中间的虚线将用于请求1的事件(左侧)与用于请求2的事件(右侧)分开。此外，中间的阴影区域示出了在存储分片156的共享参与者服务器处发生的事件，其中一些事件用于请求1(阴影区域中的左侧)，而其他事件用于请求2(阴影区域中的右侧)。阴影区域左侧的非阴影区域示出了在存储分片146的第一协调器服务器处的事件，并且阴影区域右侧的非阴影区域示出了在存储分片176的第二协调器服务器处的事件。从左侧开始，在时间1234μs处在存储分片146的第一协调器服务器处以及在时间1235μs处在存储分片156的共享参与者服务器处接收到请求1。存储分片146的第一协调器服务器以从时间1235μs至无穷大的时间范围获取用于请求1的锁。然后，存储分片156的共享参与者服务器以从时间1236μs至无穷大的时间范围获取用于请求1的排他锁。这是因为在这一点上，存储分片156的共享参与者服务器不知道存储分片146的第一协调器服务器最终将选择什么提交时间戳。存储分片156的共享参与者服务器将其准备时间戳(T1)1236μs发送到存储分片146的第一协调器服务器。存储分片146的第一协调器服务器还可以从其他参与者服务器接收其他准备时间戳，例如来自存储分片166的参与者服务器(此处未示出，图6中示出)的时间1245μs(T2)。然后，存储分片146的第一协调器服务器选择提交时间戳(Tc)，例如1248μs，该时间戳大于接收到的两个准备时间戳(T1、T2)和存储分片146的第一协调器服务器先前已指配给其他事务的任何提交时间戳。存储分片146的第一协调器服务器、存储分片156的共享参与者服务器和存储分片166的参与者服务器(此处未示出，图6中示出)均在提交时间戳1248μs处提交请求1的事务。之后，存储分片156的共享参与者服务器在1249μs处释放其用于请求1的排他锁。
向右移动，尽管在时间1235μs处在存储分片176的第二协调器服务器和在时间1236μs处在共享参与者服务器接收到请求2，并且存储分片176的第二协调器服务器以从时间1236μs到无穷大的时间范围获取用于请求2的锁，但是因为存储分片156的共享参与者服务器具有用于请求1的排他锁，并且直到时间1249μs处才释放它，因此在时间1249μs之前在分片156的共享参与者服务器处对于请求2什么也没有发生。因此，用于请求1的排他锁阻止存储分片156的共享参与者服务器选择小于或等于请求1的提交时间戳(Tc)的用于请求2的准备时间戳(T3)，并且由于存储分片176的第二协调器服务器必须选择等于或大于其接收的所有准备时间戳的提交时间戳(Tc2)，这确保存储分片176的第二协调器服务器将选择大于用于请求1的提交时间戳(Tc)的提交时间戳(Tc2)。仅仅当在时间1249μs处释放排他锁时，存储分片156的共享参与者服务器才以从1250μs至无穷大的时间范围获取用于请求2的排他锁，并将准备时间戳(T3)1250μs发送给存储分片176的第二协调器服务器。一旦存储分片176的第二协调器服务器接收到所有其他准备时间戳，例如来自存储分片186的参与者服务器(此处未示出，图6中示出)的1238μs的准备时间戳(T4)，则它选择(例如在时间1252μs处)大于接收到的准备时间戳(T3、T4)两者和存储分片176的第二协调器服务器先前已指配给其他事务的任何提交时间戳的提交时间戳(Tc2)。存储分片176的第二协调器服务器、存储分片156的共享参与者和存储分片186的参与者服务器每个均在1252μs在提交时间戳(Tc2)处提交请求2的事务。此后，存储分片156的共享参与者服务器在时间1253μs处释放其用于请求2的排他锁。如虚线箭头所示，在用于请求1的排他锁期间，无法在共享参与者分片156处对请求2进行并行处理。同样，在用于请求2的排他锁期间，在分片156的共享参与者服务器处不可能进行并行处理。第一协调器服务器和第二协调器服务器获得的锁可以是排他的或共享的。
代替获取具有直至无穷大的范围的排他锁，可以配置另一示例系统，使得参与者服务器获取直至预定的上限的排他锁。例如，客户端可以为事务指定最大提交时间戳。如果事务未在客户端指定的最大提交时间戳之前提交，则该事务可能会被中止。在这种情况下，前面提到的时间范围的上限可以是客户端指定的最大提交时间戳。
图9示出了另一示例分布式系统，该分布式系统被配置为通过在以下情况下对提交时间戳施加限制来防止如图6所示的两个多站点事务之间的时间戳冲突。为了清楚起见，仅示出了存储分片146的第一协调器服务器、存储分片176的第二协调器服务器和它们的存储分片156的共享参与者服务器。从上到下按时间顺序描述了每个服务器处的事件顺序。中间的虚线将用于请求1的事件(左侧)与用于请求2的事件(右侧)分开。此外，中间的阴影区域示出了在存储分片156的参与者服务器处发生的事件，其中一些事件用于请求1(阴影区域中的左侧)，而其他事件用于请求2(阴影区域中的右侧)。阴影区域左侧的非阴影区域示出了存储分片146的第一协调器服务器处的事件，并且阴影区域右侧的非阴影区域示出了存储分片176的第二协调器服务器处的事件。在左侧，在时间1234μs处在存储分片146的第一协调器服务器处以及在时间1235μs处在存储分片156的共享参与者服务器处接收请求1；在右侧，在1235μs处在存储分片176的第二协调器服务器处以及在1236μs处在存储分片156的参与者服务器处接收请求2。在左侧，存储分片146的第一协调器服务器以从时间1235μs至无穷大的时间范围获取用于请求1的锁；在右侧，存储分片176的第二协调器服务器以从时间1236μs至无穷大的时间范围获取用于请求2的锁。接下来，在左侧，存储分片156的共享参与者服务器以在时间1236μs处开始直到无穷大的时间范围获取用于请求1的共享锁，并将其准备时间戳(T1)1236μs发送到存储分片146的第一协调器服务器；在右侧，存储分片156的共享参与者服务器以在时间1237μs处开始直至无穷大的时间范围获取用于请求2的共享锁，并将其准备时间戳(T3)1236μs发送到存储分片176的第二协调器服务器。第一协调器服务器和第二协调器服务器中的每个也可以从其他参与者服务器接收其他准备时间戳，在左侧，存储分片146的第一协调器服务器还从存储分片166的参与者服务器(这里未示出，图6中示出)接收1245μs的准备时间戳(T2)；在右侧，存储分片176的第二协调器服务器还从存储分片186的参与者服务器(这里未示出，图6中示出)接收1238μs的准备时间戳(T4)。类似地，如以上关于图8所讨论的，代替获取直到无穷大的锁，可替选地，可以获取直到预定的上限的锁。第一协调器服务器和第二协调器服务器获取的锁可以是排他的或共享的。
为了防止时间戳冲突，第一协调器服务器和第二协调器服务器每个可以假定其相应的多站点事务中的参与者服务器中的至少一个与另一协调器服务器共享，并且在共享的参与者服务器上可以存在至少一个共享分片，并且选择受限的提交时间戳用于其相应的多站点事务。在当前示例中，存储分片156的参与者服务器是共享的参与者，而分片156是用于请求1和请求2的共享分片。然后，第一协调器服务器和第二协调器服务器分别选择受限的提交时间戳用于它们的相应的事务，使得共享存储分片156的参与者服务器的其他任何协调器不能为另一个事务选择相同的提交时间戳，即使被允许代表该事务获取共享锁。可选地，事务中的参与者服务器(例如在请求1中存储分片156的参与者服务器)可以被配置为在与在共享分片处用于另一个事务的另一个协调器服务器(例如，请求2的存储分片176的第二协调器服务器)共享的时候，通知该事务中的协调器服务器(例如在请求1中存储分片146的第一协调器服务器)，并且只有在被通知时，协调器服务器(例如，第一协调器服务器和第二协调器服务器)才可以选择受限的提交时间戳用于它们的各自的事务。通过限制协调器服务器可以选择的提交时间戳，参与者服务器可以获取共享锁而不是排他锁，这提高了系统效率。
在一个示例中，提交时间戳可以由事务ID的哈希值限制，其中，事务ID对事务是唯一的。例如，可以限制用于事务的提交时间戳，使得其较低的N比特(例如3比特、6比特、10比特、20比特等)必须等于事务ID的哈希值。再次参考图9，如果请求1的事务ID哈希为100000，并且提交时间戳(Tc)被限制使得其较低的6比特必须等于请求1的事务ID的哈希值，则将用于请求1的提交时间戳(Tc)被限制为1248μs(或10011100000)、1312μs(或10100100000)、1376μs(或10101100000)等。存储分片146的第一协调器服务器被配置为计算其从请求1的参与者服务器接收到的所有准备时间戳以及其先前已指配给其他事务的任何提交时间戳中的最大值，然后计算高于此最大值的下一个时间戳，该时间戳的较低的6比特也等于100000。类似地，如果请求2的事务ID哈希为010111，并且提交时间戳(Tc2)被限制使得其较低的6比特必须等于请求2的事务ID的哈希值，则用于请求2的提交时间戳(Tc2)被限制为1239μs(或10011010111)、1303μs(或10100010111)、1367μs(或10101010111)等。存储分片176的第二协调器服务器被配置为计算其从请求2的参与者服务器接收到的所有准备时间戳以及其先前指分配给其他事务的任何提交时间戳中的最大值，然后计算高于此最大值的下一个时间戳，该时间戳的较低的6比特也等于010111。在此，存储分片146的第一协调器服务器选择1248μs的提交时间戳(Tc)，并且存储分片176的第二协调器服务器选择在1239μs处的提交时间戳(Tc2)。然后在1248μs处在存储分片146的第一协调器服务器、在存储分片156的共享参与者服务器和存储分片166的参与者服务器处提交请求1。在1239μs处在存储分片176的第二协调器服务器、存储分片156的共享参与者服务器和存储分片186的参与者服务器处提交请求2。一旦提交了事务，则每个服务器然后释放它们各自的锁。因此，该示例系统被配置为确保根据请求1的事务和根据请求2的事务不能在相同的提交时间戳处提交。
然而，仍然有可能两个唯一的事务ID可能哈希为相同的值，引起“哈希冲突”，这又继而可能导致时间戳冲突，因为用于这两个事务的提交时间戳将受到相同的限制。冲突的可能性取决于N的值。例如，如果N＝0，其表示没有限制，那么如果两个协调器服务器选择同时提交，则对于两个事务在共享参与者服务器处会发生冲突；如果N＝6，则只有在两个事务ID的6比特哈希值相同并且两个协调器服务器同时提交的情况下，对于两个事务在共享参与者服务器处才会发生冲突；如果N＝10，则只有在两个事务ID的10比特哈希值相同并且两个协调器服务器同时提交的情况下，对于两个事务在共享参与者服务器处才会发生冲突；等等。因此，通过选择较大的N，将会降低冲突的可能性。但是，选择较大的N会有一个折中，当N变大时，协调器服务器可用的提交时间戳之间的间隔也会增加，因此，选择较大的N也意味着协调器服务器可能不得不等待更长的时间才能选择提交时间戳。例如，如果N＝0，则协调器服务器可以选择等于或大于准备时间戳的任何时间作为提交时间戳；如果N＝6，则协调器服务器必须等待以选择具有6比特哈希模式的下一个提交时间戳，该6比特哈希模式可能直至64μs；如果N＝10，则协调器服务器必须等待以选择具有10比特哈希模式的下一个提交时间戳，该10比特哈希模式可能直至1.024毫秒；等等。因此，可以根据分布式系统的细节，例如期望的系统等待时间和吞吐量，来最佳地选择N的值。为了实现较低的等待时间，可以降低N，以便协调器不必等待很长时间。为了获得更高的吞吐量，需要并行处理更多事务并允许共享锁，因此，可以增加N来防止在许多并行事务之间发生冲突。
一个示例系统被配置为通过使用排他锁来防止这种情况下的时间戳冲突。例如，如果用于请求1的事务ID和用于请求2的事务ID两者都哈希为相同的100000值，则共享参与者服务器可以在分片156处对请求1获取排他锁，如图8的左侧所示。然而，一旦在时间1249μs处释放了排他锁，这意味着导致哈希冲突的根据请求1的事务已经完成，则存储分片156的共享参与者服务器可以以图9右侧所示的相同方式使用共享锁继续进行请求2。
被配置为防止在哈希冲突情况下的时间戳冲突的另一示例系统通过仅允许共享的参与者服务器对一个事务获取写共享限制锁来这样做，并将另一个事务置于等待队列中，直到参与者服务器释放第一事务上的写共享限制锁。例如，参考图9，存储分片156的共享参与者服务器可以通过对请求1获取写共享限制锁来将请求1继续进行，如图9左侧所示，并将请求2置于等待队列中直到存储分片156的共享参与者服务器在时间1249μs处释放写共享限制锁。写共享限制锁可以防止其他具有相同哈希值(在此示例中，具有相同的受限提交时间戳比特模式)的事务在分片156处在共享参与者服务器处获取锁，但允许具有不同哈希值(在此示例中，具有不同的受限提交时间戳比特模式)的其他事务在分片156处在共享参与者服务器处获取写共享锁。这确保了存储分片156的共享参与者服务器将选择准备时间戳(T3)用于请求2，其大于请求1的提交时间戳(Tc)，这确保用于请求2的提交时间戳(Tc2)大于请求1的提交时间戳(Tc)。此外，在此示例中，由于使用写共享限制锁取代排他锁，因此因为允许并行处理具有不同哈希值的事务而提高了效率。
通过事务ID的哈希值来限制提交时间戳的该示例系统的另一方面与效率有关。例如，如果协调器服务器收到对于涉及共享参与者服务器的多站点事务的多个请求，则协调器服务器将不得不为这些多站点事务中的每一个选择受限制的提交时间戳。如图6和9中描述的示例所示，请求1选择了存储分片146的服务器作为协调器服务器，并且用于请求1的提交时间戳(Tc)被限制为1248μs(或10011100000)、1312μs(或10100100000)、1376μs(或10101100000)等，假设还有一个请求4，该请求4也选择了存储分片146的服务器作为具有提交时间戳(Tc4)的协调器服务器，该提交时间戳(Tc4)被限制为1281μs(或10100000001)、1345μs(或10101000001)、1473μs(或10111000001)等，假设存在另一个请求5，其也选择了存储分片146的服务器作为具有提交时间戳(Tc5)的协调器服务器，该提交时间戳(Tc5)被限制为1258μs(或10011101010)、1322μs(或10100101010)、1386μs(或10101101010)等，假设还有另一个请求6，其选择了存储分片146的服务器作为具有提交时间戳(Tc6)的协调器，该提交时间戳(Tc6)被限制为1280μs(或10100000000)、1344μs(或10101000000)、1472μs(或10111000000)等。因此，如果存储分片146的协调器服务器选择按照请求1-请求4-请求5-请求6的顺序提交事务，则提交时间戳将为1248μs、1281μs、1322μs、1344μs，总间隔为33μs+41μs+22μs＝964μs；但是如果存储分片146的协调器服务器选择按请求5-请求4-请求1-请求6的顺序提交事务，则提交时间戳将为1258μs、1281μs、1312μs、1344μs，总间隔为23μs+31μs+32μs＝86μs，依此类推。因此，选择时间戳的顺序会影响效率。
在一个示例中，接收请求以用受限的提交时间戳来提交多个事务的服务器并且对于此而言其充当协调器的服务器可以选择提交时间戳用于每个事务，使得所有提交时间戳之间的总间隔基本上最小化。例如，从上面的示例继续，存储分片146的协调器服务器可以首先确定对于请求1，它可以选择的用于所有要提交的事务的最小提交时间戳是1248μs。然后，存储分片146的协调器服务器按递增顺序安排用于其他事务(请求4、5、6)的较低6比特模式，其为000000(请求6)、000001(请求4)、101010(请求5)。然后，存储分片146的协调器服务器将第一6比特模式旋转到有序列表的末尾，直到列表中的第一6比特模式大于请求1的较低6比特模式。因此，在2次旋转后，该列表将变为101010(请求5)、000000(请求6)、000001(请求4)。然后，存储分片146的协调器服务器按照与该列表相对应的顺序(即请求5-请求6-请求4)选择下三个提交时间戳。这基本上最小化了在同一协调器服务器处的事务之间的等候时间，从而最小化了事务提交的等待时间，因此提高了整体效率。在上面的示例中，如果存储分片146的协调器服务器按照请求1-请求5-请求6-请求4的顺序选择时间戳，则提交时间戳将为1248μs、1258μs、1280μs、1281μs，总间隔为10μs+22μs+1＝33μs。上述排序方法不限于对多站点事务排序，如果协调器服务器还接收到提交单站点事务的请求，则协调器服务器可以将单站点事务与多站点事务一起排序，以基本上最小化所有提交时间戳之间的总间隔，因此还提高了整体效率。
在其他示例系统中，代替受事务ID的限制的提交时间戳，共享参与者服务器的协调器服务器在选择提交时间戳时可能会以其他方式受到限制，使得在共享分片处共享参与者的任何其他协调器服务器都不能为另一个事务选择相同的提交时间戳，即使允许代表该事务获取共享锁也是如此。例如，提交时间戳可以由协调器服务器ID来限制，该协调器服务器ID以与相对于事务ID上述相似的方式来识别协调器服务器。对于另一个示例，可以将具有共享参与者服务器的协调器服务器配置为彼此通信，以确保选择了唯一的提交时间戳。例如，共享参与者服务器的协调器服务器可以相互发送消息，以就其相应的事务的不同提交时间戳达成一致。在另一个示例系统中，全局管理员可以选择所有提交时间戳以确保提交时间戳是唯一的。
图10示出了示例分布式系统，该分布式系统被配置为通过在参与者处在以下情况下对提交时间戳施加限制来防止如图7所示的多站点事务与单站点事务之间的时间戳冲突。为了清楚起见，仅示出了一个存储分片146的协调器服务器和一个存储分片156的参与者服务器。从上到下按时间顺序描述了在每个服务器处的事件顺序。中间的虚线将用于请求1的事件(左侧)与用于请求2的事件(右侧)分开。此外，中间的阴影区域示出了在存储分片156的参与者服务器处发生的事件，其中一些事件用于请求1(阴影区域中的左侧)，而其他事件用于请求2(阴影区域中的右侧)。阴影区域左侧的非阴影区域示出了在存储分片146的协调器服务器处的事件。在左侧，在时间1234μs处在存储分片146的协调器服务器处以及在时间1235μs处在存储分片156的参与者服务器处接收了用于多站点事务的请求1；在右侧，在时间1235处在存储分片156的参与者服务器处接收了用于单站点事务的请求3。存储分片146的协调器服务器以从时间1235μs到无穷大的时间范围获取用于请求1的锁。接下来，在左侧，存储分片156的参与者服务器在从时间1236μs开始直到无限大的时间范围内获取用于请求1的共享锁，并且将1236μs的准备时间戳(T1)发送给存储分片146的协调器服务器；然后，在右侧，存储分片156的参与者服务器在从时间1237μs开始直到无限大的范围内获取用于请求3的共享锁。存储分片146的协调器服务器也可以从所有其他参与者服务器接收准备时间戳，例如来自存储分片166的参与者服务器(此处未示出，在图7中示出)的1245μs的准备时间戳(T2)。类似地，如以上关于图8所讨论的，代替获取锁直到无穷大，可替选地，可以从直至预定的上限获取锁。存储分片146的协调器服务器获取的锁可以是排他的或共享的。
存储分片146的协调器服务器可以选择提交时间戳(Tc)，例如1248μs，它大于或等于它接收到的准备时间戳(T1、T2)以及它先前已指配给其他事务的任何提交时间戳，并且具有较低的6比特模式100000。但是，在右侧，如上所述，如果存储分片156的参与者服务器根据请求3自由地选择任何提交时间戳(Tc3)用于单站点事务，则存储分片156的参与者服务器有可能选择与由存储分片146的协调器服务器选择的用于请求1的提交时间戳(Tc)相同的提交时间戳(Tc)。为了避免在参与者服务器处的多站点事务和单站点事务之间的这种时间戳冲突，参与者服务器可以被配置为选择受限制的提交时间戳用于单站点事务，在该参与者服务器处协调器服务器不会选择该受限制的提交时间戳用于多站点事务。
在一个示例中，可以通过单站点事务的事务ID的哈希值来限制用于单站点事务的提交时间戳。例如，存储分片156的参与者服务器可能要求用于单站点事务的提交时间戳(Tc3)的较低的N比特(例如3比特、6比特、10比特、20比特等)等于单站点事务的事务ID的哈希值。再次参考图10，如果请求3的事务ID哈希为010101，并且提交时间戳被限制使得其较低的6比特必须等于事务ID的哈希值，则用于请求3的提交时间戳被限制为1237μs(或10011010101)、1301μs(或10100010101)、1365μs(或10101010101)等。然后，将请求1在1248μs处在存储分片146的协调器服务器处和存储分片156的参与者服务器处提交。在1237μs处在存储分片156的参与者服务器处提交请求3。在提交事务后，每个服务器都释放它们相应的锁。如上所述，这样的示例系统确保根据请求1的事务和根据请求3的事务不会在与根据请求1的事务相同的提交时间戳处进行提交。
在替选示例中，分布式系统可以被配置为使得它与多站点事务不同地对待单站点事务，以完全消除多站点事务与单站点事务之间的时间戳冲突。例如，协调器服务器可能不仅要求具有共享的参与者服务器的多站点事务的提交时间戳具有等于事务ID的哈希值的较低的N比特，而且还要求用于这种多站点事务的提交时间戳必须具有较低的N比特＝hash(事务ID)％2N-1。这样，将永远不允许多站点事务选择具有等于2N-1的较低的N比特(例如3比特、6比特、10比特、20比特等)的提交时间戳，其可以排他地被保留用于单站点事务。再次参考图10，因为N＝6，所以根据请求3的单站点事务只能选择具有26-1(或111111)的较低6比特的提交时间戳，这意味着用于请求3的提交时间戳被限制为1279μs(或10011111111)、1535μs(或10111111111)、2047μs(或111111111111)等。在此示例中，由于要求单站点事务的提交时间戳遵循不同于所有多站点事务的排他模式，因此通过消除处理单站点事务和多站点事务之间可能的时间戳冲突的需求，这可以提高效率。
可以在用户可以查看的表的一个或多个列中向用户提供分布式数据库的提交时间戳。例如，当用户请求变更分布式数据库中保留的一个或多个主表中的数据项时，用户可能还希望将此变更记录在另一个表中，该表跟踪主表中进行的所有变更(“变更日志”)。例如，用户可以请求事务来修改主表中的某些数据项，并且还可以在该事务中包括突变以将事务记录在变更日志中。在这样的变更日志中，提交时间戳可能被包含在主键列中(这意味着提交时间戳必须是唯一的)或者被包含在某个其他列中。
图11示出了示例分布式系统。在这里，分布式数据库的用户是Big Bank(大银行)，其维护着分布在多个分片或组(例如分片146、156、166)处的多个表。Big Bank维护的一个表“Big Bank处的账户”是在Big Bank处的所有账户的汇总，其包括诸如账户持有人的姓名、账户ID、账户类型和当前余额的信息。Big Bank还为每个账户维护一个变更日志，以跟踪对该账户做出的所有存款和取款。例如，变更日志“Adam Smith(亚当·史密斯)的账户历史记录”记录了对Adam Smith(亚当·史密斯)账户进行的所有存款和取款的记录。BigBank维护的另一个表是“Big Bank资产”，其是对银行各种资产的汇总，包括资产类型和资产额。
图11中的示例还显示，Big Bank发送两个请求，即请求1和请求2，以变更其数据库中维护的某些数据。2018年2月8日下午12:29:30做出的请求1是向Adam Smith的账户存入$5,000；在当日下午12:30:00做出的请求2是从Adam Smith的账户中提取$2,000。请求1和请求2两者都需要更新“Big Bank处的账户”表中“Adam Smith的当前余额”。例如，如果AdamSmith(亚当·史密斯)在提交请求1之前的当前余额为$1,000，在请求1完成后的当前余额将为$6,000，并且在提交请求2之后的当前余额将为$4,000。请求1和请求2两者也都要求表Big Bank资产更新Big Bank处的支票账户的金额。例如，请求1将支票账户的金额增加$5,000，而请求2将支票账户金额减少$2,000。最后，请求1和请求2两者都要求更新表AdamSmith的账户历史记录添加这两项事务。对于Adam Smith的账户历史记录，请求1和请求2两者都还包括包含提交时间戳的指令，因此，Adam Smith的账户历史记录中的列将插入用于请求1和请求2的提交时间戳，这是所有三个表格(Big Bank的账户、Big Bank资产和AdamSmith的账户历史记录)已根据请求1和请求2进行了更新的时间。
如图11所示，在Adam Smith的账户历史记录的列中提供了每个事务的提交时间戳，例如，20180208123015123456是已根据请求1更新所有三个表(Big Bank的账户、BigBank资产和Adam Smith的账户历史记录)的提交时间戳，并且20180208123017098765是根据请求2更新所有三个表的提交时间戳。因为事务顺序对于银行事务特别重要(例如，在请求1之前处理请求2会导致Adam Smith的余额出现负数)，此处提供提交时间戳作为AdamSmith的账户历史记录的主键。在另一个示例中，可以在提出请求时将占位符放置在AdamSmith的账户历史记录的提交时间戳列中，并且一旦选择了提交时间戳，该值就会更新。
在分布式系统中，例如，如图5所示，Big Bank的账户可能位于分片146，AdamSmith的账户历史记录可能位于分片156，Big Bank资产可能位于分片166。对于请求1，BigBank可以选择将存储分片146的服务器作为第一协调器服务器，将存储分片156和166的服务器作为参与者服务器，而对于请求2，Big Bank可以选择存储分片166的服务器作为第二协调器服务器，并且将存储分片146和156的服务器作为参与者服务器。如果在存储分片156的共享参与者服务器处，存储分片146的第一协调器服务器选择与存储分片166的第二协调器服务器选择用于请求2的相同的用于请求1的提交时间戳，则将为请求1的事务以及请求2的事务输入相同的提交时间戳。由于提交时间戳是Adam Smith的账户历史记录的主键，因此不允许多行使用相同的提交时间戳，因此，一个事务将覆盖另一事务，而Adam Smith的账户历史记录将无法准确表示Adam Smith(亚当·史密斯)的账户的整个历史记录。
如上所述，可以通过以上讨论并在图8-10中示出的各种示例系统中的一个来实现唯一的提交时间戳。尽管在上面的示例中，变更日志位于一个分片上，但是变更日志也可以位于多个分片上，但是以上关于图8-10讨论的示例系统将同样适用。同样，在另一个示例中，用户可以请求跨多个数据库的事务，并且在该事务请求中包括突变以更新每个数据库的单独的变更日志，并且上面关于图8-10讨论的示例系统将同样适用。例如，从图11中的示例继续，从Adam Smith的账户到Bob Cat的账户的转账可能需要在分片156处更新AdamSmith的账户历史记录的变更日志，并在分片176处更新Bob Cat的账户历史记录的变更日志。
示例方法
图12示出了用于向用户提供唯一提交时间戳的示例方法1200。应当理解，以下操作不必以下面描述的精确顺序执行。而是，可以以不同顺序或同时处理各个步骤。除非另有说明，否则还可以添加或省略步骤。
在框1210中，在分布式系统中的第一协调器服务器和一个或多个参与者服务器处接收提交事务的请求。
在框1220中，在协调器服务器处接收来自每个参与者服务器的通知，该通知包括相应的准备时间戳，该相应的准备时间戳在相应的参与者服务器获得至少一个锁的时间范围内被选择。
在框1230中，计算等于或大于每个准备时间戳的用于事务的提交时间戳。
在框1240中，限制提交时间戳，使得在共享分片处共享用于一个或多个其他事务的至少一个参与者服务器的第二协调器服务器不能为任何其他事务选择相同的提交时间戳。
在框1250中，在第一协调器服务器和每个参与者服务器处在提交时间戳处提交事务。
该技术是有利的，因为它在不显著损害分布式数据库的吞吐量的情况下向用户提供了有意义的提交时间戳。虽然用户的数据库可能高度分布，但是用户可以使用提交时间戳来查看对各种数据项所做的变更，就好像数据库被保存在单机上一样。该技术还提供了各种提高效率的方法，例如，通过避免排他锁、最小化提交时间戳之间的间隔以及为多站点事务和单站点事务提供不同的处理方式。
除非另有说明，否则前述替代示例不是互相排斥的，而是可以以各种组合实现以实现独特的优点。由于可以在不背离权利要求所限定的主题的情况下利用以上讨论的特征的这些和其他变形以及组合，因此，对实施例的前述描述应通过说明的方式而不是通过限制权利要求限定的主题的方式进行。另外，本文描述的示例的提供以及用短语表达为“诸如”和“包括”等的用语不应被解释为将权利要求的主题限制于特定示例；相反，这些示例仅旨在说明许多可能的实施例之一。此外，不同附图中的相同附图标记可以标识相同或相似的元件。

Claims (23)

1.一种方法，包括：
在分布式系统中的第一协调器服务器和一个或多个参与者服务器处，接收提交事务的请求；
从所述参与者服务器中的每个接收通知，所述通知包括相应的准备时间戳，所述相应的准备时间戳是在相应的参与者服务器获得至少一个锁的时间范围内选择的；
计算等于或大于每个所述准备时间戳的用于所述事务的提交时间戳；
限制所述提交时间戳，使得第二协调器服务器不能为任何其他事务选择相同的提交时间戳，所述第二协调器服务器在共享分片处共享用于一个或多个其他事务的所述参与者服务器中的至少一个参与者服务器；以及
在所述第一协调器服务器处以及每个所述参与者服务器处，在所述提交时间戳处提交所述事务。
2.根据权利要求1所述的方法，其中，所述至少一个锁是写共享锁。
3.根据权利要求1所述的方法，还包括：
计算所述事务的事务ID的哈希值；以及
通过所述事务ID的所述哈希值进一步限制用于所述事务的所述提交时间戳。
4.根据权利要求3所述的方法，其中，进一步限制所述提交时间戳包括：将所述提交时间戳的预定数量的较低比特设置为等于所述事务ID的所述哈希值。
5.根据权利要求1所述的方法，还包括：
确定所述第一协调器服务器接收到提交其他事务的一个或多个请求；以及
计算用于在所述第一协调器服务器处接收到的所述其他事务中的每个的提交时间戳，使得所述提交时间戳之间的总间隔基本上被最小化。
6.根据权利要求3所述的方法，还包括：
在所述共享参与者服务器处，确定所述事务ID的所述哈希值等于所述其他事务中的至少一个的事务ID的哈希值；以及
在所述共享参与者服务器处，防止具有相同哈希值的其他事务中的至少一个获取锁直到所述事务提交。
7.根据权利要求1所述的方法，还包括：
在所述参与者服务器中的一个或多个处，确定要在所述参与者服务器处提交单站点事务；
计算具有用于所述单站点事务的预定模式的单站点提交时间戳，所述预定模式是任何多站点事务都不能选择作为其提交时间戳的模式；以及
在所述单站点提交时间戳处提交所述单站点事务。
8.根据权利要求1所述的方法，还包括：
在所述参与者服务器中的一个或多个处，确定要在所述参与者服务器处提交单站点事务；以及
计算所述单站点事务的事务ID的哈希值；以及
通过所述单站点事务的所述事务ID的所述哈希值来限制用于所述单站点事务的所述提交时间戳。
9.根据权利要求8所述的方法，还包括：
其中，限制用于所述单站点事务的所述提交时间戳包括：将所述单站点事务的所述提交时间戳的预定数目的较低比特设置为等于所述单站点事务的所述事务ID的所述哈希值。
10.根据权利要求1所述的方法，
其中，提交事务的所述请求还包括突变，以用于更新记录所述事务的变更日志。
11.根据权利要求10所述的方法，
其中，所述提交时间戳作为所述变更日志的主键被包括。
12.根据权利要求10所述的方法，
其中，所述变更日志的至少一部分被存储在所述参与者服务器中的一个处。
13.根据权利要求10所述的方法，
其中，所述提交事务的请求还包括突变，以用于更新记录所述事务的多个变更日志。
14.根据权利要求1所述的方法，其中，所述分布式系统包括关系数据库，并且所述方法还包括：在所述关系数据库中添加至少一个列，以在所述关系数据库中将所述提交时间戳存储为主键。
15.一种方法，包括：
在分布式系统中的协调器服务器和一个或多个参与者服务器处接收提交事务的请求；
由所述参与者服务器中的每个在从本地选择的开始时间开始到预定上限的时间范围内获得至少一个排他锁；
在所述协调器服务器处接收关于所述参与者服务器中的每个在相应准备时间戳处已准备好的通知，所述相应准备时间戳是在所述相应的时间范围内选择的；
在所述协调器服务器处计算等于或大于每个所述准备时间戳的用于所述事务的提交时间戳；
在所述协调器服务器处以及每个所述参与者服务器中处，在所述提交时间戳处提交所述事务；以及
在所述参与者服务器中的每个处释放所述至少一个排他锁。
16.根据权利要求15所述的方法，
其中，所述预定上限是无穷大。
17.根据权利要求15所述的方法，
其中，所述提交事务的请求还包括突变，以用于更新记录所述事务的变更日志。
18.根据权利要求15所述的方法，其中，所述分布式系统包括关系数据库，并且所述方法还包括：在所述关系数据库中添加至少一个列，以在所述关系数据库中将所述提交时间戳存储为主键。
19.一种系统，包括：
多个服务器中的第一协调器服务器，所述服务器中的每个适于在分布式计算环境中彼此通信以及与客户端通信，所述第一协调器服务器包括一个或多个处理器，所述一个或多个处理器被配置为：
接收提交事务的请求；
接收关于充当所述事务的参与者服务器的所述其他服务器中的任何一个在相应的准备时间戳处已准备好的通知，所述相应的准备时间戳是在所述相应的参与者服务器获得至少一个锁的时间范围内选择的；
计算等于或大于每个所述准备时间戳的用于所述事务的提交时间戳，使得第二协调器服务器不能为任何其他事务选择相同的提交时间戳，所述第二协调器服务器在共享分片处共享用于一个或多个其他事务的所述参与者服务器中的至少一个参与者服务器；以及
在所述提交时间戳处提交所述事务。
20.根据权利要求19所述的系统，其中，所述第一协调器服务器的所述一个或多个处理器还被配置为：
计算所述事务的事务ID的哈希值；以及
通过所述事务ID的所述哈希值进一步限制用于所述事务的所述提交时间戳。
21.根据权利要求19所述的系统，其中，所述第一协调器服务器的所述一个或多个处理器还被配置为：
确定在所述第一协调器服务器处接收到提交其他事务的一个或多个请求；以及
计算在所述第一协调器服务器处接收到的用于所述其他事务中的每个的提交时间戳，使得所述提交时间戳之间的总间隔基本上被最小化。
22.根据权利要求19所述的系统，还包括：
参与者服务器，所述参与者服务器包括一个或多个处理器，所述处理器被配置为：
确定要在所述参与者服务器处提交单站点事务；
计算具有用于所述单站点事务的预定模式的单站点提交时间戳，所述预定模式是任何多站点事务都不能选择作为其提交时间戳的模式；以及
在所述单站点提交时间戳处提交所述单站点事务。
23.根据权利要求19所述的系统，其中，所述分布式计算环境包括关系数据库，并且所述一个或多个处理器进一步被配置为：在所述关系数据库中添加至少一个列，以在所述关系数据库中将所述提交时间戳存储为主键。
CN201880091104.4A 2018-03-13 2018-03-13 在关系数据库的主键中包括事务提交时间戳 Pending CN111868707A (zh)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/US2018/022156 WO2019177591A1 (en) 2018-03-13 2018-03-13 Including transactional commit timestamps in the primary keys of relational databases

Publications (1)

Publication Number Publication Date
CN111868707A true CN111868707A (zh) 2020-10-30

Family

ID=61873930

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201880091104.4A Pending CN111868707A (zh) 2018-03-13 2018-03-13 在关系数据库的主键中包括事务提交时间戳

Country Status (4)

Country Link
US (2) US11474991B2 (zh)
EP (1) EP3765968A1 (zh)
CN (1) CN111868707A (zh)
WO (1) WO2019177591A1 (zh)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112765275A (zh) * 2021-01-26 2021-05-07 成都佳发安泰教育科技股份有限公司 基于单一时间坐标系的数据同步交换方法、设备及介质
CN113687921A (zh) * 2021-10-25 2021-11-23 北京金山云网络技术有限公司 事务处理方法、装置、分布式数据库系统及电子设备
CN114362870A (zh) * 2021-12-23 2022-04-15 天津南大通用数据技术股份有限公司 一种用于分布式事务型数据库的片区逻辑时钟方法
CN115292419A (zh) * 2022-10-09 2022-11-04 深圳市明源云科技有限公司 基于poH共识的数据处理方法、装置、设备及存储介质

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11436218B2 (en) * 2019-08-02 2022-09-06 Alibaba Group Holding Limited Transaction processing for a database distributed across availability zones
US11194773B2 (en) * 2019-09-12 2021-12-07 Oracle International Corporation Integration of existing databases into a sharding environment
CN111581247B (zh) * 2019-10-01 2022-04-01 上海忆芯实业有限公司 数据管理器、时序数据库及信息处理系统
US11755558B2 (en) * 2021-06-25 2023-09-12 Microsoft Technology Licensing, Llc Transaction identifier locking with data row locks

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5212788A (en) * 1990-05-22 1993-05-18 Digital Equipment Corporation System and method for consistent timestamping in distributed computer databases
US5701480A (en) * 1991-10-17 1997-12-23 Digital Equipment Corporation Distributed multi-version commitment ordering protocols for guaranteeing serializability during transaction processing
CN102419764A (zh) * 2010-10-20 2012-04-18 微软公司 带有多版本化的数据库系统的分布式事务管理
US20130318146A1 (en) * 2012-05-11 2013-11-28 Google Inc. System and Method for Committing Transactions on Remote Servers
US20160147813A1 (en) * 2014-11-25 2016-05-26 Juchang Lee Distributed transaction commit protocol
US9569253B1 (en) * 2012-06-04 2017-02-14 Google Inc. Ensuring globally consistent transactions

Family Cites Families (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5530851A (en) * 1994-04-28 1996-06-25 The United States Of America As Represented By The Secretary Of The Navy Early commit timestamp computer database protocol
US6457016B1 (en) * 2000-01-04 2002-09-24 International Business Machines Corporation Timestamp commit
US7120762B2 (en) * 2001-10-19 2006-10-10 Wisconsin Alumni Research Foundation Concurrent execution of critical sections by eliding ownership of locks
US7076508B2 (en) * 2002-08-12 2006-07-11 International Business Machines Corporation Method, system, and program for merging log entries from multiple recovery log files
US20070050429A1 (en) 2005-08-26 2007-03-01 Centric Software, Inc. Time-range locking for temporal database and branched-and-temporal databases
WO2009027138A1 (en) * 2007-08-30 2009-03-05 International Business Machines Corporation Accessing data entities
JP5213077B2 (ja) * 2008-10-06 2013-06-19 インターナショナル・ビジネス・マシーンズ・コーポレーション 複数のアプリケーションサーバにより共有データをアクセスするシステム
US8301934B1 (en) * 2009-04-17 2012-10-30 Teradata Us, Inc. Commit-time timestamping of temporal rows
EP2323047B1 (en) * 2009-10-09 2020-02-19 Software AG Primary database system, replication database system and method for replicating data of a primary database system
US20110302143A1 (en) 2010-06-02 2011-12-08 Microsoft Corporation Multi-version concurrency with ordered timestamps
US9336262B2 (en) * 2010-10-05 2016-05-10 Sap Se Accelerated transactions with precommit-time early lock release
JP5652228B2 (ja) * 2011-01-25 2015-01-14 富士通株式会社 データベースサーバ装置、データベース更新方法及びデータベース更新プログラム
JP2013033345A (ja) * 2011-08-01 2013-02-14 Internatl Business Mach Corp <Ibm> トランザクション処理システム、方法及びプログラム
DE112012004099T5 (de) * 2011-09-30 2014-07-17 International Business Machines Corp. Transaktionsverarbeitungssystem, Verfahren und Programm
US9037558B2 (en) * 2012-05-25 2015-05-19 International Business Machines Corporation Management of long-running locks and transactions on database tables
GB2504109B (en) * 2012-07-18 2020-02-12 Open Cloud Nz Ltd Combining scalability across multiple resources in a transaction processing system having global serializability
US20140040208A1 (en) * 2012-07-31 2014-02-06 Goetz Graefe Early release of transaction locks based on tags
US10534538B2 (en) * 2015-02-23 2020-01-14 Oracle International Corporation Fine-grained hardware transactional lock elision
US9652168B2 (en) * 2015-04-10 2017-05-16 International Business Machines Corporation Adaptive concurrency control using hardware transactional memory and locking mechanism
US10235440B2 (en) * 2015-12-21 2019-03-19 Sap Se Decentralized transaction commit protocol
US11321299B2 (en) * 2016-02-01 2022-05-03 Verizon Patent And Licensing Inc. Scalable conflict detection in transaction management
US10248471B2 (en) * 2016-09-15 2019-04-02 Oracle International Corporation Lockless execution in read-mostly workloads for efficient concurrent process execution on shared resources
US10810165B2 (en) * 2016-10-07 2020-10-20 Electronics And Telecommunications Research Institute Distributed storage server, server device included therein, and method of operating server device
US10346386B2 (en) * 2016-11-04 2019-07-09 Salesforce.Com, Inc. Multiversion concurrency control of database records with uncommitted transactions
US11573947B2 (en) * 2017-05-08 2023-02-07 Sap Se Adaptive query routing in a replicated database environment
US10812560B2 (en) * 2017-05-09 2020-10-20 EMC IP Holding Company LLC System and method for packet transmission using segment routing
US10691484B2 (en) * 2017-05-15 2020-06-23 Google Llc Reducing commit wait in a distributed multiversion database by reading the clock earlier
US10803079B2 (en) * 2017-07-25 2020-10-13 International Business Machines Corporation Timing-based system-period temporal table in a database system
US10824612B2 (en) * 2017-08-21 2020-11-03 Western Digital Technologies, Inc. Key ticketing system with lock-free concurrency and versioning

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5212788A (en) * 1990-05-22 1993-05-18 Digital Equipment Corporation System and method for consistent timestamping in distributed computer databases
US5701480A (en) * 1991-10-17 1997-12-23 Digital Equipment Corporation Distributed multi-version commitment ordering protocols for guaranteeing serializability during transaction processing
CN102419764A (zh) * 2010-10-20 2012-04-18 微软公司 带有多版本化的数据库系统的分布式事务管理
US20130318146A1 (en) * 2012-05-11 2013-11-28 Google Inc. System and Method for Committing Transactions on Remote Servers
US9569253B1 (en) * 2012-06-04 2017-02-14 Google Inc. Ensuring globally consistent transactions
US20160147813A1 (en) * 2014-11-25 2016-05-26 Juchang Lee Distributed transaction commit protocol

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112765275A (zh) * 2021-01-26 2021-05-07 成都佳发安泰教育科技股份有限公司 基于单一时间坐标系的数据同步交换方法、设备及介质
CN113687921A (zh) * 2021-10-25 2021-11-23 北京金山云网络技术有限公司 事务处理方法、装置、分布式数据库系统及电子设备
CN114362870A (zh) * 2021-12-23 2022-04-15 天津南大通用数据技术股份有限公司 一种用于分布式事务型数据库的片区逻辑时钟方法
CN114362870B (zh) * 2021-12-23 2022-11-29 天津南大通用数据技术股份有限公司 一种用于分布式事务型数据库的片区逻辑时钟方法
CN115292419A (zh) * 2022-10-09 2022-11-04 深圳市明源云科技有限公司 基于poH共识的数据处理方法、装置、设备及存储介质
CN115292419B (zh) * 2022-10-09 2023-03-31 深圳市明源云科技有限公司 基于poH共识的数据处理方法、装置、设备及存储介质

Also Published As

Publication number Publication date
US20210042284A1 (en) 2021-02-11
EP3765968A1 (en) 2021-01-20
US11899649B2 (en) 2024-02-13
US20230004545A1 (en) 2023-01-05
US11474991B2 (en) 2022-10-18
WO2019177591A1 (en) 2019-09-19

Similar Documents

Publication Publication Date Title
US11899649B2 (en) Including transactional commit timestamps in the primary keys of relational databases
US10031935B1 (en) Customer-requested partitioning of journal-based storage systems
US11601501B2 (en) High-throughput algorithm for multiversion concurrency control with globally synchronized time
US10157108B2 (en) Multi-way, zero-copy, passive transaction log collection in distributed transaction systems
US11556375B2 (en) Reducing commit wait in a distributed multiversion database by reading the clock earlier
JP7263297B2 (ja) ハイブリッドクラウド弾性スケーリングおよび高性能データ仮想化のためのリアルタイムクロスシステムデータベースレプリケーション
US10037346B1 (en) Time reservations for ensuring consistent reads in a distributed database without logging
CN115668141A (zh) 使用时间戳对网络中的事务进行分布式处理
US10235407B1 (en) Distributed storage system journal forking
Nawab et al. The challenges of global-scale data management
US10089373B1 (en) Wide-scale replication of similarly structured data
CN114207600A (zh) 分布式跨区域的数据库事务处理
Islam Database consistency in cloud databases
Dey Cherry Garcia: Transactions across Heterogeneous Data Stores
US11403179B1 (en) Transactionally consistent point-in-time restore
Kraska Building database applications in the cloud
Gessert et al. Caching in Research and Industry
CN115422188A (zh) 表结构在线变更方法及装置、电子设备和存储介质
Elbushra et al. Non-blocking Algorithm for Eventual Consistent Replicated Database on Cloud

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