[译文II]Spanner:Google’s Globally-Distributed Database

原文

Spanner:Google’s Globally-Distributed Database

译文结构

实现

本章将介绍以下内容:

  • 介绍Spanner的架构及其实现的基本原理,
  • 然后,将介绍用于管理副本和位置的目录抽象,以及移动数据的单位。
  • 最后,将介绍我们的数据模型,为何Spanner看起来像关系型数据库而不是一个键值存储系统(key-value store),以及用户如何控制数据的位置。

一个Spanner的部署被称为一个universe。考虑到Spnner在全球范围内管理数据,其只有少量正在运行的universes。目前我们有个用于测试/实验(test/playground)的unverise,一个开发/产品(developing/production) unverise,和一个只服务生产环境的universe

Spanner由一个zone的集合组成,每个zone是一个Bigtable服务集群部署的粗糙模拟。zone是管理部署的单位。zone的集合也是可以复制数据位置的集合。随着新的数据中心投入服务,zone被添加到正在运行的服务中;当旧数据中心被关闭时,zone被从正在运行的服务中移除。zone也是物理隔离的单位:一个数据中心可以包含一个或多个zone;例如,多个应用在同一个数据中时,必须被分布到不同的服务集群(zone)中。

spanner_fig_1

[Figure 1]展示了一个Spanner universe的服务器,简要介绍如下:

  • 一个zone由一个zonemaster和100-上千台spanserver。zonemaster把数据分配给spanservers,spanserver为客户端提供数据。
  • location proxy用来帮助客户端定位为其提供数据的spanserver。
  • universe master和placement driver目前都只有一个
  • universe master主要为一个管理zone的控制台,它显示所有zone的状态信息,用于互动调试。
  • placement driver 用于处理zone之间分钟级别的数据自动移动。
  • placement driver 周期性地与spanserver交互,为满足被更新的副本限制或负载均衡,发现需要移动的数据

由于篇幅限制,我们将只介绍spanserver的相关细节。

2.1 Spanserver软件栈

本节将专注于spanserver的实现,描述基于Bigtable,Spanner如何实现复制和分布式事务。软件栈信息显示如[Figure 2]。

spanner_fig_1

Tablet

在底部,每个spannserver负责管理100-1000称为tablet的数据结构实例:

  • 一个tablet类似于Bigtable的tablet抽象,在spannerserver中,它实现了一系列如下映射关系:

      (key:string,timestamp:int64)=> string 
    

    不同于Bigtable的是,Spanner将时间戳关联到了数据--这是一个关键的实现方式,它让Spanner比起一个key-vaue的存储,更像一个多版本数据库。

  • 一个tablet的状态被存放于类B-tree文件集和一个write-ahead日志中,所有的这些又被存放于一个叫做Colossus(Google文件系统的继承者[15])的文件系统里。

Paxos

为支持复制,每个spanserver在每个tablet之上实现了一个Paxos状态机,每个状态机将其状态及日志存放在其对应的tablet中。(早期的一个Spanner实现为支持更灵活的副本配置,支持一个table对应多个Paxos状态机。其复杂性迫使我们放弃了它)。

  • 我们的Paxos实现支持常驻leaders(long-lived leaders),其基于时间leader租赁,长度一般在10秒。
  • 当前的Spanner实现中,对每个Paxos写操作记录两次日志:一次在tablet的日志中,一次在Paxos的日志中。该做法乃权宜之计,我们会在将来对其改进。
  • 我们的Paxos实现采用了管道式,因而提高了在广域网延时下的吞吐量,但paxos依旧会把写操作按顺序执行(事实上,我们将依赖于第四节--Concurrency Control)。

Paxos状态机用来对一系列复制映射的持久化。

  • 每个replica的key-value映射状态存放于其对应的tablet中
  • 写操作必需在replica leader上初始化paxos协议
  • 读操作可以直接从任意replica底层的tablet中访问状态信息,只要其足够新。
  • replica的集合被统一称为一个Paxos group–paxos集合

Lock TABLE

在每个作为leader的replica上,spanserver设计了一个lock table以实现并发控制。该锁表包含了两阶段锁的状态。(注意,存在常驻Paxos leader是有效管理lock table的关键)。在Bigtable和Spanner中,我们都设计了长事务(long-lived transaction)(例如,报表的生成,耗时可能达几分钟。),当冲突存在时,乐观并发控制表现出很差的性能。对于需要同步的操作,如读事务,需要获得lock table里面的lock;其它操作便可忽略lock table。

Transaction manager

在每个作为leader的replica上,每个spanserver也实现了一个事务管理员(transaction manager)来支持分布式事务。

  • 事务管理员用来实现一个participant leader(参与者领导),组里面的其它replica则被称为participant slave(参与者随从)。
  • 如果一个事务只包含了一个paxos组(大部分事务都是如此),由于lock table和paxos一起已经提供了事务性,所以可以忽略transaction manager。
  • 如果一个事务包含了多个paxos组,这些组的leader将协调执行两阶段提交。其中一个参与群会被选为coordinator leader:它的participant leader 被引用为coordinator leader,它的slaves则被称为coordinator slaves. 每个transaction manager的状态被存放于底层paxos组中(故被副本化了)

2.2 Directories and Placement(目录和放置)

在一系列key-value映射的上层,Spanner实现了被称为目录(directory)的bucket抽象,一个目录为拥有公共前缀的连续key集合(选择directory作为术语为历史偶然,实际上bucket可能更专业)。我们将在2.3节介绍前缀的由来。对目录的支持,使得应用可以通过对key的细分来控制数据的位置(locality)。

spanner_fig_3

一个目录是数据放置的基本单元。同一个目录下的所有数据,拥有相同的副本配置。如图3所示,当数据在Paxos集群间迁移时,是一个目录一个目录地移动的。Spanner可能在以下情况下移动目录:

  • 减轻一个paxos集群的压力
  • 将经常被一起访问的目录放在同一个集群里
  • 将目录移动到离它访问者最近的集群上

客户端在操作时,目录也可以移动(在线移动)。一个50MB的目录预计可在几秒内完成移动。