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组的负担，也可能会把那些被频繁地一起访问的书目都放置到同一个组中，或者会把一个书目转移到距离访问者更近的地方。当客户端操作正在进行时，也可以进行