GoogleSpanner中文版.docx

《GoogleSpanner中文版.docx》由会员分享，可在线阅读，更多相关《GoogleSpanner中文版.docx（30页珍藏版）》请在课桌文档上搜索。

1、Goog1eSpanner（中文版）摘要：SPanner是谷歌公司研发的、nJ扩展的、多版本、全球分布式、同步复制数据库。它是第一个把数据分布在全球范围内的系统，并且支持外部一样性的分布式事务。本文描述了SPanner的架构、特性、不同设计决策的背后机理和一个新的时间API,这个APl可以暴露时钟的不确定性。这个APl及其实现，对于支持外部一样性和很多强大特性而言，是特别重要的，这些强大特性包括：非堵塞的读、不采纳锁机制的只读事务、原子模式变更。中文关键词：谷歌，分布式数据库英文关键词：Google.Spanner,Bigtable,DistributedDatabase全文书目结构1 .介绍

2、2 .实现2. 1Spanserver软件栈2.2书目和放置2. 3数据模型3. TrueTime4. 并发限制4 .1时间戳管理4.2细微环节5 .试验分析5.1 微测试基准5.2 可用性5 .3TrueTimc5.4Fl6 .相关工作7 .将来的工作8 .总结致谢参考文献1介绍Spanner是一个可扩展的、全球分布式的数据库，是在谷歌公司设计、开发和部箸的。在最高抽象层面，SPanner就是一个数据库，把数据分片存储在很多PaXoS21状态机上，这些机器位于遍布全球的数据中心内。复制技术可以用来服务于全球可用性和地理局部性。客户端会自动在副本之间进行失败复原。随着数据的改变和服务器的改变，

3、SPanner会自动把数据进行重新分片，从而有效应时负载改变和处理失败。Spanner被设计成可以扩展到几百万个机器节点，跨越成百上千个数据中心，具备几万亿数据库行的规模。应用可以借助于SPannCr来实现高可用性，通过在一个洲的内部和跨越不同的洲之间复制数据，保证即使面对大范围的自然灾难时数据依旧可用。我们最初的客户是Fl35,一个谷歌广告后台的市新编程实现。Fl运用了跨越美国的5个副本。绝大多数其他应用很可能会在属于同一个地理范围内的3-5个数据中心内放置数据副本，采纳相对独立的失败模式。也就是说，很多应用都会首先选择低延迟，而不是高可用性，只要系统能够从1-2个数据中心失败中熨原过来。S

4、Panner的主要工作，就是管理跨越多个数据中心的数据副本，但是，在我们的分布式系统体系架构之上设计和实现重耍的数据库特性方面，我们也花费了大量的时间。尽管有很多项目可以很好地运用BigTable9,我们也不断收到来自客户的埋怨，客户反映BigTable无法应用到一些特定类型的应用上面，比如具备困难可变的模式，或者对于在大范围内分布的多个副本数据具有较高的样性要求。其他探讨人员也提出了类似的埋怨37.谷歌的很多应用已经选择运用MegaStOre5,主要是因为它的半关系数据模型和对同步第制的支持，尽管MegaStore具备较差的写操作吞吐量。由于上述多个方面的因素，SPanner已经从一个类似B

5、igTabIe的单一版本的键值存储，演化成为一个具有时间属性的多版本的数据库。数据被存储到模式化的、半关系的表中，数据被版本化，每个版本都会自动以提交时间作为时间戳，IH版本的数据会更简洁被垃圾回收。应用可以读取旧版本的数据。SPanner支持通用的事务，供应了基于SQ1.的查询语言。作为一个全球分布式数据库，SPanner供应了几个好玩的特性：第一，在数据的副本配置方面，应用可以在一个很细的粒度上进行动态限制。应用可以具体规定，哪些数据中心包含哪些数据，数据距离用户有多远（限制用户读取数据的延迟），不同数据副本之间距离有多远（限制写操作的延迟），以及须要维护多少个副本（限制可用性和读操作性能

6、）。数据也可以被动态和透亮地在数据中心之间进行移动，从而平衡不同数据中心内资源的运用。其次，SPanner有两个重要的特性，很难在一个分布式数据库上实现，即Spanner供应了读和写操作的外部一样性，以及在一个时间戳下面的跨越数据库的全球一样性的读操作。这些特性使得Spanner可以支持一样的备份、一样的VaPRCdUCe执行12和原子模式变更，全部都是在全球范围内实现，即使存在正在处理中的事务也可以。之所以可以支持这些特性，是因为SPanner可以为事务安排全球范围内有意义的提交时间戳，即使事务可能是分布式的。这些时间戳反映了事务序列化的依次。除此以外，这些序列化的依次满意了外部一样性的要求

7、：假如一个事务Tl在另一个事务T2起先之前就已经提交了,那么，Tl的时间戳就要比T2的时间戳小。Spanner是第一个可以在全球范围内供应这种保证的系统。实现这种特性的关键技术就是一个新的TrueTimeAPl及其实现。这个APl可以干脆暴露时钟不确定性，SPanner时间戳的保证就此取决于这个APl实现的界限。假如这个不确定性很大，Spanner就降低速度来等待这个大的不确定性结束。谷歌的簇管理器软件供应了一个TrUeTimeAPI的实现。这种实现可以保持较小的不确定性（通常小于IOms）,主要是借助于现代时钟参考值（比如GPS和原子钟）。第2部分描述了Spanner实现的结构、特性集和工程

8、方面的决策：第3部分介绍我们的新的TrUeTimeAPl,并且描述了它的实现;第4部分描述TSpanner如何运用TrueTime来实现外部一样性的分布式事务、不用锁机制的只读事务和原子模式更新。第5部分供应JZ测试Spanner性能和TrueTime行为的测试基准，并探讨了Fl的阅历。第6、7和8部分探讨了相关工作，并给出总结。2实现本部分内容描述ZSpanner的结构和背后的实现机理，然后描述了书目抽象，它被用来管理副本和局部性，并介绍了数据的转移单位。最终，将探讨我们的数据模型，从而说明，为什么SPanner看起来更加像一个关系数据库，而不是一个键值数据库：还会探讨应用如何可以限制数据的

9、局部性。-个Spanner部署称为一个UniVerSeo假设SPanner在全球范围内管理数据，那么，将会只有可数的、运行中的universe,我们当前正在运行一个测试用的UniVerse,一个部署/线上用的UniVerSe和一个只用于线上应用的UniVerSeoSpanner被组织成很多个zone的集合，每个zone都也许像一个BigTable服务器的部署:zone是管理部署的基本单元。zone的集合也是数据可以被复制到的位置的集合。当新的数据中心加入服务，或者老的数据中心被关闭时，zone可以被加入到一个运行的系统中，或者从中移除。ZOne也是物理隔离的单元，在一个数据中心中，可能有一个或

10、者多个Zone,例如，属于不同应用的数据可能必需被分区存储到同一个数据中心的不同服务器集合中。图1显示了在一个SPanner的UniVerSe中的服务器。一个zone包括一个zonemaster,和*百至几千个SPanSerVeroZonemaster把数据安排给spanserver,spanserver把数据供应应客户端。客户端运用每个ZOne上面的IOCatiOnProXy来定位可以为自己供应数据的spanserverUniversemaster和placementdriver,当前都只有一个。UniVerSemaSter主要是一个限制台，它显示了关于zone的各种状态信息，可以用于相互之

11、间的调试。Placementdriver会周期性地及spanserver进行交互，来发觉那些须要被转移的数据，或者是为了满意新的副本约束条件，或者是为了进行负载均衡。2.1 Spanserver软件栈本部分内容主要关注spanserver实现，来说明复制和分布式事务是如何被架构到我们的基于BigTable的实现之上的。图2显示了软件栈。在底部，每个spanserver负载管理100TOOO个称为tablet的数据结构的实例。一个tablet就类似于BigTable中的tablet,也实现了下面的映射：(key:SIring,timestamp:int64)-string及BigTable不同的

12、是，Spanner会把时间世安排给数据，这种特别重要的方式，使得SPanner更像一个多版本数据库，而不是一个健值存储。一个tablet的状态是存储在类似于B-树的文件集合和写前(Write-ahead)的口志中，全部这些都会被保存到一个分布式的文件系统中，这个分布式文件系统被称为Colossus,它继承自GoogleFileSystemo为了支持复制，每个spanserver会在每个tablet上面实现一个单个的PaXoS状态的机器。一个之前实现的SPanner可以支持在每个tablet上面实现多个Paxos状态机，它可以允许更加敏捷的复制配置，但是，这种设计过于困难，被我们舍弃了。每个状态

13、机器都会在相应的tablet中保存自己的元数据和H志。我们的PaXOS实现支持采纳基于时间的领导者租约的长寿命的领导者，时间通常在0到10秒之间。当前的Spanner实现中，会对每个PaXOS写操作进行两次记录：一次是写入到tablet日志中，一次是写入到Paxos日志中。这种做法只是权宜之计，我们以后会进行完善。我们在Paxos实现上采纳了管道化的方式，从而可以在存在广域网延迟时改进SPanner的吞吐量，但是，Paxos会把写操作依据依次的方式执行。PaXoS状态机是用来实现一系列被一样性复制的映射。每个副本的键值映射状态，都会被保存到相应的IabIet中。写操作必需在领导者上初始化Pax

14、os协议，读操作可以干脆从底层的任何副本的Iablel中访问状态信息，只要这个副本足够新。副本的集合被称为一个Paxosgroupo对于每个是领导者的副本而言，每个spanserver会实现一个锁表来实现并发限制。这个锁表包含了两阶段锁机制的状态:它把键的值域映射到锁状态上面。留意，采纳个长寿命的PaXOS领导者，对于有效管理领表而言是特别关键的。在BigTable和Spanner中，我们都特地为长事务做了设计，比如，对于报表操作，可能要持续几分钟，当存在冲突时，采纳乐观并发限制机制会表现出很差的性能。刻于那些须要同步的操作，比如事务型的读操作，须要获得锁表中的锁，而其他类型的操作则可以不理睬

15、锁表。对于每个扮演领导者角色的副木，每个SPanSerVer也会实施一个事务管理器来支持分布式事务。这个事务管理器被用来实现一个PartiCiPantleader,该组内的其他副本则是作为participantslaves假如一个事务只包含一个PaXoS组（对于很多事务而言都是如此），它就可以绕过事务管理器，因为锁表和PaXOS二者一起可以保证事务性。假如一个事务包含了多于一个PaXOS组，那些组的领导者之间会彼此协调合作完成两阶段提交。其中一个参及者组，会被选为协调者，该组的PartiCiPanIIeader被称为coordinatorleader,该组的PartiCiPantSlaVeS被

16、称为coordinatorSIaVeSo每个事务管理器的状态，会被保存完竟层的Paxos组。2.2 书目和放置在一系列键值映射的上层，SPHnner实现支持一个被称为“书目”的桶抽象，也就是包含公共前缀的连续键的集合。（选择“书目”作为名称，主要是由于历史沿袭的考虑，事实上更好的名称应当是“桶”）o我们会在第2.3节说明前缀的源头。对书目的支持，可以让应用通过选择合适的键来限制数据的局部性。一个书目是数据放置的基本单元。属于一个书目的全部数据，都具有相同的副本配置。当数据在不同的PaXoS组之间进行移动时，会一个书目一个书目地转移，如图3所示。SPanner可能会移动个书目从而减轻个PaXoS

17、组的负担，也可能会把那些被频繁地一起访问的书目都放置到同一个组中，或者会把一个书目转移到距离访问者更近的地方。当客户端操作正在进行时，也可以进行W目的转移。我们可以预期在几秒内转移50MB的书目0一个PaXOS组可以包含多个书目，这意味着一个Spannertablet是不同于一个BigTabIetablet的O一个SPannertablet没有必要是一个行空间内依据词典依次连续的分区，相反，它可以是行空间内的多个分区。我们做出这个确定，是因为这样做可以让多个被频繁一起访问的节目被整合到一起。Movedir是个后台任务，用来在不同的Baxos组之间转移书目140Movedir也用来为PaXoS组

18、增加和删除副本25,因为SPanner目前还不支持在个PaXoS内部进行配置的变更。Movedir并不是作为一个事务来实现，这样可以避开在一个块数据转移过程中堵塞正在进行的读操作和写操作。相反，MoVedir会注册-个事实（fact）,表明它要转移数据，然后在后台运行转移数据。当它几乎快要转移完指定数量的数据时.，就会启动一个事务来H动转移那部分数据，并且为两个PaXoS组更新元数据。一个书目也是一个应用可以指定的地理复制属性（即放置策略）的最小单元。我们的放置规范语言的设计，把管理复制的配置这个任务单独分别出来。管理员须要限制两个维度：副本的数量和类型，以及这些副本的地理放置属性。他们在这两

19、个维度里面创建了一个命名选项的菜单。通过为每个数据库或单独的书目增加这些命名选项的组合，一个应用就可以限制数据的豆制。例如，一个应用可能会在自一的书目里存储每个终端用户的数据，这就有可能使得用户A的数据在欧洲有三个副本，用户B的数据在北美有5个副本。为了表达的清楚性，我们已经做了尽量简化。事实上，当一个书目变得太大时，SPanner会把它分片存储。每个分片可能会被保存到不同的PaXoS组上（因此就意味着来自不同的服务器）。1。Vedir在不同组之间转移的是分片，而不是转移整个书目。2 .3数据模型Spanner会把下面的数据特性集合暴露给应用：基于模式化的半关系表的数据模型，查询语言和通用事务

20、。支持这些特性的动机，是受到很多因素驱动的。须要支持模式化的半关系表是由MegaStOre5的普及来支持的。在谷歌内部至少有300个应用运用VegaSgre（尽管它具有相对低的性能），因为它的数据模型要比BigTabIe简洁，更易于管理，并且支持在跨数据中心层面进行同步复制。BigTable只可以支持跨数据中心的最终事务一样性。运用Megastore的闻名的谷歌应用是GnlaiI,Picasa,Calendar,AndroidMarket,AppEngineo在SPanner中须要支持SQ1.类型的查询语言，也很明显是特别必要的，因为DremeI28作为交互式分析工具已经特别普及。最终，在Bi

21、gTable中跨行事务的缺乏来导致了用户常见的埋怨；PCrCOlalor32的开发就是用来部分解决这个问题的。一些作者都在埋怨，通用的两阶段提交的代价过于昂贵，因为它会带来可用性问题和性能问题91019。我们认为，最好让应用程序开发人员来处理由于过度运用事务引起的性能问题，而不是总是围困着“缺少事务”进行编程。在Paxos上运行两阶段提交弱化了可用性问题。应用的数据模型是架构在被书目桶装的键值映射层之上。一个应用会在一个UniVerSe中创建一个或者多个数据库。每个数据库可以包含无限数量的模式化的发。每个表都和关系数据库表类似，具备行、列和版本值。我们不会具体介绍SPanner的查询语言,它看

22、起来很像SQ1.,只是做了一些扩展。SPanner的数据模型不是纯粹关系型的，它的行必需出名称。更精确地说，每个表都须要有包含一个或多个主键列的排序集合。这种需求，让SPanner看起来仍旧有点像键值存储：主键形成了一个行的名称，每个表都定义了从主键列到非主键列的映射。当一个行存在时，必须要求已经给行的一些键定义了一些值（即使是XU1.D采纳这种结构是很有用的，因为这可以让应用通过选择键来限制数据的局部性。图4包含r一个Spanner模式的实例，它是以每个用户和每个相册为基础存储图片元数据。这个模式语言和Megastore的类似，同时增加了额外的要求，即每个SPanner数据库必需被客户端分割

23、成一个或多个表的层次结构(hierarchy)。客户端应用会运用INTER1.EAVEIN语句在数据库模式中声明这个层次结构。这个层次结构上面的表，是一个书目表。书目表中的每行都具有键K,和子孙农中的全部以K起先(以字典依次排序)的行一起,构成了一个书目。ONDE1.ETECASCADE意味着,假如删除书目中的一个行,也会级联删除全部相关的子孙行。这个图也说明了这个实例数据库的交织层次(interleavedlayout),例如AIbUmS(2,1)代表了来自AIbUmS表的、对应于USejidh2和album_id=l的行。这种衣的交织层次形成书目，是特别重要的，因为它允许客户端来描述存在于

24、多个表之间的位置关系，这对于一个分片的分布式数据库的性能而言是很重要的。没有它的话，Spanner就无法知道最重要的位置关系.3 TrueTime本部分内容描述TrUeTimeAPI,并也许给出它的实现方法。我们把大量细微环节内容放在另一篇论文中，我们的目标是展示这种APl的力气。表1列出了APl的方法:TrueTime会显式地把时辰表达成TTinlerVa1,这是一个时间区间，具有有界限的时间不确定性(不像其他的标准时间接口，没有为客户端供应“不确定性”这种概念)。TTinterval区间的端点是TTStamP类型。TT.now()方法会返回一个TTinterVal,它可以保证包含TT.no

25、w。方法在调用时的肯定时间。这个时间和具备闰秒涂抹(Ieap-secondsmearing)的UNIX时间一样。把即时误差边界定义为J平均误差边界为(林子雨注：“E上边一个横杠”，表示平均值。11.after()和TT.before。方法是针对TT.now()的便捷的包装器。表示一个事务e的肯定时间，可以利用函数t0t(e)假如用更加形式化的术语，TrUeTime可以保证，对于一个调用tt=TT.now(),有tt.earliestWtds(当“)Wtt.latest,其中,是emt是调用的事务。在底层，TrueTime运用的时间是GPS和原子钟。TrUCTimC运用两种类型的时间，是因为它们

26、有不同的失败模式。GPS参考时间的弱点是天线和接收器失效、局部电磁干扰和相关失败(比如设计上的缺陷导致无法正确处理闰秒和电子欺瞒)，以及GPS系统运行中断。原子钟也会失效，不过失效的方式和GPS无关，不同原子钟之间的失效也没有彼此关联。由于存在频率误差，在经过很长的时间以后，原子钟都会产生明显误差。TrUeTinle是由每个数据中心上面的很多timemaster机器和每台机器上的一个timeslavedaemon来共同实现的。大多数master都有具备专用天线的GPS接收器，这些master在物理上是相互隔离的，这样可以削减天线失效、电磁干扰和电子欺瞒的影响。剩余的master(我们称为Ann

27、ageddOnmaSter)则配备/原F钟。一个原子钟并不是很昂贵：一个AnnagCddonmaster的花费和一个GPSmaster的花费是同一个数量级的。全部master的时间参考值都会进行彼此校对。每个master也会交叉检查时间参考值和本地时间的比值，假如二者差别太大，就会把Fl己驱除出去。在同步期间，Armageddonmaster会表现出一个渐渐增加的时间不确定性，这是由保守应用的最差时钟漂移引起的。GPSmaster表现出的时间不确定性几乎接近于0。每个daemon会从很多master29中收集投票，获得时间参考值，从而削减误差。被选中的master中，有些master是GPSm

28、aster,是从旁边的数据中心获得的，剩余的GPSnlaSter是从远处的数据中心获得的；还有一些是AnnageddOnmaSter。Daemon会运用一个MarZUUo算法27的变种，来探测和拒绝欺瞒，并且把本地时钟同步到非撒谎master的时间参考值。为免受较差的本地时钟的影响，我们会依据组件规范和运行环境确定一个界限，假如机器的本地时钟误差频繁超出这个界限，这个机器就会被驱除出去。在同步期间，一个daemon会表现出渐渐增加的时间不确定性是从保守应用的最差时钟漂移中得到的。也取决于timemaster的不确定性，以及及IimemaStCr之间的通讯延迟。在我们的线上应用环境中，通常是一个

29、关于时间的锯齿形函数。在每个投票间隔中，E会在1到7ms之间改变。因此，在大多数状况下，的平均值是4msDaenlon的投票间隔，在当前走30秒，当前运用的时钟漂移比率是200微秒/秒，二者一起意味着0到6ms的锯齿形边界。剩余的ImS主要来自到timemaster的通讯延迟。在失败的时候，超过这个锯齿形边界也是有可能的。例如，间或的timemaster不确定性，可能会引起整个数据中心范围内的值的增加。类似的，过载的机器或者网络连接，都会导致值间或地局部增大。4 .并发限制本部分内容描述TrUeTilTle如何可以用来保证并发限制的正确性，以及这些屈性如何用来实现一些关键特性，比如外部一样性的

30、事务、无锁机制的只读事务、针对历史数据的堵塞读。这些特性可以保证,在时间戳为t的时刻的数据库读操作，肯定只能看到在t时刻之前已经提交的事务。进一步说，把Spanner客户端的写操作和Paxos看到的写操作这二者进行区分，是特别重要的，我们把PaXoS看到的写操作称为PaXOS写操作。例如，两阶段提交会为打算提交阶段生成一个Baxos写操作，这时不会有相应的客户端写操作。4.1 时间裁管理表2列出了Spanner支持的操作的类型。SPanner可以支持读写事务、只读事务（预先声明的快照隔离事务）和快照读。独立写操作，会被当成读写事务来执行。非快照独立读操作，会被当成只读事务来执行。：者都是在内部

31、进行retry,客户端不用进行这种retry100p0一个只读事务具备快照隔离的性能优势6。一个只读事务必鑫事先被声明不会包含任何写操作，它并不是一个简洁的不包含写操作的读写事务。在一个只读事务中的读操作，在执行时会采纳一个系统选择的时间戮，不包含锁机制，因此，后而到达的写操作不会被堵塞。在一个只读事务中的读操作，可以到任何足够新的副本上去执行（见第节）。个快照读操作，是针时历史数据的读取，执行过程中，不须要锁机制。一个客户端可以为快照读确定一个时间戳，或者供应一个时间范围让SPanner来自动选择时间戳。不管是哪种状况,快照读操作都可以在任何具有足够新的副本上执行。对于只读事务和快照读而言,

32、一旦已经选定一个时间戳，那么，提交就是不行避开的，除非在那个时间点的数据已经被垃圾回收了。因此，客户端不必在retry1。P中缓存结果。当一个服务器失效的时候，客户端就可以运用同样的时间戳和当前的读位置，在另外一个服务器上接着执行读操作。4.2 细微环节林子雨注：上面是GoogleSPanner（中文版）的核心内容，第4节“并发限制”的剩余内容，没有在网页中给出，将会放在PDF文件中（目前还没有完成排版，完成后会上传，以后请到本网页的底部“附件”中下载PDF文件），因为，第4节“并发限制”的剩余内容，公式太多，无法放入网页。而且，依据本人的阅读，上述给出的内容已经可以帮助读者基本了解Googl

33、eSPanner的概貌，剩余的内容是一些琐碎的细微环节，个人感觉读起来比较晦涩，假如不是深化探讨须要，可以不用接着阅读第4节“并发限制”的剩余内容。5 .试验分析我们对SPanner性能进行了测试，包括复制、事务和可用性。然后，我们供应了一些关于TrUeTime的试验数据，并且供应了我们的第一个用例一FU5.1 微测试基准表3给出了一个用于Spanner的微测试基准(microbenchmark)。这些测试是在分时机器上实现的：每个SPanSerVer采纳4GB内存和四核CPU(AMDBarcelona2200MHz)客户端运行在单独的机器上。每个zone都包含一个Spanserver0客户端

34、和Zone都放在一个数据中心集合内，它们之间的网络距离不会超过1ms。(这种布局是很一般的，很多数据并不须要把数据分散存储到全球各地)。测试数据库具有50个PaXoS组和2500个书目。操作都是独立的4KB大小的读和写。AIIreadswereservedoutofmemoryafteracompaction,从而使得我们只须要衡量SPanner调用栈的开销。此外，还会进行一轮读操作，来预热任何位置的缓存。对于延迟试验而言，客户端会发起足够少量的操作,从而避开在服务器中发生排队。从1个副本的试验中，提交等待大约是5ms,Paxos延迟大约是9ms。随着副本数量的增加，延迟大约保持不变，只具有很

35、少的标准差，因为在一个组的副本内，PaXOS会并行执行。随着副本数量的增加，获得指定投票数量的延迟，对一个slave副本的慢速度不会很敏感。对于吞吐量的试验而言，客户端发起足够数量的操作，从而使得CPU处理实力达到饱和夬照读操作可以在任何足够新的副本上进行，因此，快照读的吞吐量会随着副本的数量增加而线性增加。单个读的只读事务，只会在领导者上执行，因为，时间戳安排必需发生在领导者上。只读事务吞吐量会随着副本数量的增加而增加，因为有效的spanserver的数量会增加：在这个试验的设置.中，spanserver的数量和副本的数量相同,领导者会被随机安排到不同的zone。写操作的吞吐量也会从这种试验

36、设置中获得收益（副本从3变到5时写操作吞吐量增加了，就能够说明这点），但是，随着副本数量的增加，每个写操作执行时须要完成的工作量也会线性增加，这就会抵消前面的收益。表4显示了两阶段提交可以扩展到合理数量的参及者:它是对一系列试验的总结，这些试验运行在3个ZOne上，每个Zone具有25个SPanSerV仃。扩展到50个参及者，无论在平均值还是第99个百分位方面，都是合理的。在100个参及者的情形下，延迟起先明显增加。5.2 可用性图5显示了在多个数据中心运行Spanner时的可用性方面的收益。它显示了三个吞吐量试验的结果，并且存在数据中心失败的情形，全部三个试验结果都被重存放置到一个时间轴上。

37、测试用的universe包含5个zoneZi,每个zone都拥有25个spanserver测试数据库被分片成1250个Paxos组，100个客户端不断地发送非快照读操作，累积速率是每秒50K个读操作。全部领导者都会被显式地放置到ZU每个测试进行5秒钟以后，一个zone中的全部服务器都会被杀死：nonTeader杀掉Z2,Ieader-hard杀掉Zl,Ieade1.Soft杀掉Zl,但是，它会首先通知全部服务器它们将要交出领导权。杀掉Z2时于读操作吞吐量没有影响.杀掉Zl,给领导者一些时间来把领导权交给另一个zone时，会产生一个小的影响：吞吐量会下降，不是很明显，也许下降3-蜴。另一方面，没

38、有预警就杀掉Zl有一个明显的影响：完成率几乎下降到0。随着领导者被重新选择，系统的吞吐量会增加到大约每秒100K个读操作，主要是由于我们的试验设置：系统中有额外的实力，当找不到领导者时操作会排队。由此导致的结果是，系统的吞吐量会增加直到到达系统恒定的速率。我们可以看看把PaXoS领导者相约设置为IomS的效果。当我们杀掉这个zone,对于这个组的领导者租约的过期时间，会匀称地分布到接下来的10秒钟内。来自一个死亡的领导者的每个租约一旦过期，就会选择一个新的领导者。大约在杀死时间过去10秒钟以后，全部的组都会有领导者，乔吐量就复原了。短的租约时间会降低服务器死亡对于可用性的影响，但是，须要更多的

39、更新租约的网络通讯开销。我们正在设计和实现一种机制，它可以在领导者失效的时候，让slave释放Paxos领导者租约。5.3 TrueTime关于TrUeTimC,必需回答两个问题：是否就是时钟不确定性的边界？会变得多糟糕？对于第一个问题，最严峻的问题就是，假如一个局部的时钟漂移大于200ussec,那就会破坏TrUeTime的假设。我们的机器统计数据显示，坏的CPU的出现概率要比坏的时钟出现概率大6倍。也就是说，及更加严峻的硬件问题相比，时钟问题是很少见的。由此，我们也信任,TrueTime的实现和SPanner其他软件组件一样，具有很好的牢靠性，值得信任。图6显示了TrueTime数据，是从

40、几千个SPanSerVer中收集的，这些SPanSever跨越/多个数据中心，距离2200公里以上。图中描述了的第90个、99个和99.9个百分位的状况，是在对timemaster进行投票后马上对timeslavedaemon进行样本抽样的。这些抽样数据没有考虑由于时钟不确定性带来的值的锯齿，因此测量的是timemaster不确定性（通常是0）再加上通讯延迟。图6中的数据显示了，在确定E的基本值方面的上述两个问题，通常都不会是个问题。但是，可能会存在明显的拖尾延迟问题，那会引起更高的值。图中，3月30日拖尾延迟的降低，是因为网络的改进，削减了瞬间网络连接的拥堵。在4月13口的值增加了，持续了大

41、约1个小时，主要是因为例行维护时关闭了两个timemastero我们会接着调研并且消退引起TrUeTime突变的因素。5.4 FlSpanncr在2019年早期起先进行在线负载测试，它是作为谷歌广告后价Fl35的重新实现的一部分。这个后台最起先是基于MySQ1.数据库，在很多方面都采纳手工数据分区。未经压缩的数据可以达到几十TB,虽然这对于很多NoSQ1.实例而言数据量是很小的，但是，对于采纳数据分区的VySQ1.而言，数据量是特别大的MySQ1.的数据分片机制，会把每个客户和全部相关的数据安排给一个固定的分区。这种布局方式，可以支持针对单个客户的索引构建和困难查询处理，但是，须要了解一些商业

42、学问来设计分区。随着客户数量的增长，对数据进行重新分区，代价是很大的。最近一次的重新分区，花费了两年的时间，为了降低风险，在多个团队之间进行了大量的合作和测试。这种操作太困难了，无法经常执行，由此导致的结果是，团队必需限制MySQ1.数据库的增长，方法是，把一些数据存储在外部的Bigtable中，这就会牺牲事务和杳询全部数据的实力。Fl团队选择运用SPanner有几个方面的缘由。首先，SPanner不须要手工分区。其次，SPanner供应了同步复制和自动失败复原。在采纳MySQ1.的master-slave复制方法时，很难进行失败复原，会有数据丢失和当机的风险。再次，Hl须要强壮的事务语义，这

43、使得运用其他NoSQ1.系统是不实际的。应用语义须要跨越随意数据的事务和一样性读oFl团队也须要在他们的数据上构建.级索引（因为SPanner没有供应对二级索引的自动支持），也有实力运用Spanner事务来实现他们臼己的一样性全球索引。全部应用写操作,现在都是默认从Fl发送到Spanner.而不是发送到基于MySQ1.的应用栈。Fl住美国的西岸有两个副本，在东岸有三个副本。这种副本位置的选择，是为了避开发生自然灾难时出现服务停止问题，也是出于前端应用的位置的考虑。事实上，SPanner的失败自动复原，几乎是不行见的。在过去的几个月中，尽管有不在安排内的机群失效，但是，Fl团队最须要做的工作仍I

44、H是更新他们的数据库模式，来告知Spanner在哪里放置Paxos领导者,从而使得它们尽量靠近应用前端。SPanner时间戳语义，使得它对于Fl而言，可以高效地维护从数据库状态计弊得到的、放在内存中的数据结构。Fl会为全部变更都维护一个逻辑历史口志，它会作为每个事务的一部分写入到SPanner。Fl会得到某个时间戳下的数据的完整快照，来初始化它的数据结构，然后依据数据的增量改变来更新这个数据结构。表5显示了El中每个书目的分片数量的分布状况。每个书目通常对应于Fl上的应用栈中的一个用户。绝大多数书目（同时意味着绝大多数用户）都只会包含一个分片，这就意味着，对于这些用户数据的读和写操作只会发生在

45、一个服务器上。多于100个分片的书目，是那些包含Fl:级索引的表：对这些表的多个分片进行写操作，是极其不寻常的。Fl团队也只是在以事务的方式进行未经优化的批量数据加载时，才会遇到这种情形。表6显示了从Fl服务器来测量的SPanner操作的延迟。在东海岸数据中心的副本，在选择PaXoS领导者方面会获得更高的优先级。表6中的数据是从这些数据中心的FI服务器上测量得到的。写操作延迟分俗上存在较大的标准差，是由于锁冲突引起的肥尾效应（fattail）在读操作延迟分布上存在更大的标准差，部分是因为Paxos领导者跨越了两个数据中心，只有其中的一个是采纳了固态盘的机器。此外，测试内容还包括系统中的每个针对

46、两个数据中心的读操作：字节读操作的平均值和标准差分别是1.6KB和119KB。6 .相关工作MCgaStore5和DynamoDB3已经供应了跨越多个数据中心的一样性复制。DynamoDB供应了键值存储接口，只能在一个region内部进行复制OSpanner和Mcgastore一样,都供应了半关系数据模型,甚至采纳了类似的模式语言。MegaStore无法获得高性能。Mcgastore是架构在Bigtable之上，这带来了很高的通讯代价。Megastore也不支持长寿命的领导者，多个副本可能会发起写操作。来自不同副本的写操作，在PaXOS协议下肯定会发生冲突，即使他们不会发生逻辑冲突：会严峻影响

47、吞吐量，在一个PaXoS组内每秒钟只能执行几个写操作。SPannCr供应了更高的性能，通用的事务和外部一样性。Pavlo等人31对数据库和MaPRedUCe12的性能进行了比较。他们指出了几个努力的方向，可以在分布式键值存储之上充分利用数据库的功能14741,:者可以实现充分的融合。我们比较赞同这个结论，并且认为集成多个层是具有优势的：把熨制和并发限制集成起来，可以削减SPanner中的提交等待代价。在个采纳了复制的存储上面实现事务，可以至少追述到Gifford的论文16J。SCaIter17是一个最近的基于DHT的键值存储，可以在一样性复制上面实现事务。SPanner则要比SCatter在更

48、高的层次上供应接口。Gray和1.amPort18描述了一个基于Baxos的非堵塞的提交协议，他们的协议会比两阶段提交协议带来更多的代价，而两阶段提交协议在大范围分布式的组中的代价会进一步恶化Uter36供应了一个快照隔离的变种，但是无法跨越数据中心。相反，我们的只读事务供应了一个更加自然的语义，因为，我们对于全部的操作都支持外部语义。最近，在削减或者消退锁开销方面已经有大量的探讨工作。CaIVin40消退了并发限制：它会重新安排时间戳，然后以时间戳的依次执行事务。HStore依9和GranolaIl1都支持自己的事务类型划分方法，有些事务类型可以避开锁机制。但是，这些系统都无法供应外部一样性。SPannCr通过供应快照隔离，解决了冲突问题。VohDB42是一个分片的内存数据库，可以支持在大范围区域内进行主从复制，支持灾难复原，但是没有供应通用的复制配置方法。它是一个被称为NewSQ1.的实例,这是实现可扩展的SQ1.38的强大的市场推动力。很多商业化的数据库都可以支持历史数据读取,比如MarkIogiC26和OraCIeTotalRecall301.omet1.i24对于这种时间数据库描述r-种实现策略。FareSile给出了及一个受信任的时钟参考值相关的、时钟不确定性