spanner 的前世今生-阿里云开发者社区

开发者社区> 阿里云存储服务> 正文

spanner 的前世今生

简介: spanner的前身是big table,让我们先来看看big table这个老子的方方面面,然后再来看看儿子spanner为啥一出世就吸引了全球技术人员的眼球。 2006年,google 发表了big table [1]的文章,为什么要做big table,下面有一个简短的总结[2]: 就

spanner的前身是big table,让我们先来看看big table这个老子的方方面面,然后再来看看儿子spanner为啥一出世就吸引了全球技术人员的眼球。

2006年,google 发表了big table [1]的文章,为什么要做big table,下面有一个简短的总结[2]:

fc878f190c27b7287cb989e70c1671451fca229a

就是一个问题:数据太多,访问量太大,规模问题出现。规模是问题的源泉,是后续故事的核心,在此基础上才碰到了动态schema(semi-structure带来的问题,比如big table支持的schema change),全局可用,数据一致读写等问题。

big table的数据模型是 <row, column, timestamp> -> cell content ,每个cell都是一个三维空间中的一个点,每个维度都是动态可配置的(行可以随意增加,列可以随意增加,时间序列可以随意增加),非常灵活自由。

big table 的系统架构,解决数据和访问在一个cluster内部如何分配:将数据分片,每台tablet server load 若干分片,有一个核心节点master来做全局信息同步。

29c22aa4bb938cac9b5a2b0466b35df2cc6c516e


在big table 论文发布之后,big table一直在改进,主要是致力于提供更好的scalability;加入了跨cluster(一般是跨机房的cluster)的数据异步复制以及Coprocessor(HBase的coprocess应该也是从这里引入)。

 

google 大哥在成长,工程师需要更好用的结构化存储,big table 看来在以下几个方面做的不够好:

1. 分布式transaction:比如A给B发送了一个消息,那么A的发件箱和B的收件箱应该同时有一封信件,这是一个完整的事务,应该遵循事务的ACID原则,但是big table无法支持,其只支持single-row-transactions。这也也好理解,在啥都没有的情况下,big table的出世就足以让人兴奋,谁会为分布式transaction伤脑筋呢?不过日子越过越好,人们的要求也越来越高,这件事情就逃避不掉了。

2. 强一致性数据同步:即使某些用户不要求分布式transaction,那么强一致性也是希望提供的,也就是说在数据没有同时主、备集群写入之前,不要返回client成功的消息。应用有此需求也容易理解,如果你主集群写完就返回,然后主集群挂了,我最新的数据不是丢了吗?

3. SQL语言支持:大家都很懒

4. 全球负载均衡:负载均衡是个很大的话题,包括存储负载(存储空间全球数据中心共享)、调度负载(在全球数据中心内平衡CPU/MEM利用)、网络负载(在全球数据中心内平衡网络流量)、距离负载(让数据紧贴应用进行全球移动)

 

不得不说,系统真的是一步步进步的,人们的需求真的是一步步提高的,如果不是big table做出来,这些问题估计没人敢想。也正是因为这些问题的存在,Spanner[3]横空出世。

看看spanner解决了哪些问题:

Spanner is Google’s scalable, multi-version, globally distributed, and synchronously-replicated database

Spanner’s main focus is managing cross-datacenter replicated data, providing externally consistent [16] reads and writes, and
globally-consistent reads across the database.

最核心的是两点:

1. 分布式transaction

2. 全球自动化负载均衡(细粒度切分和全球数据复制都是为这个目的服务的)

Spanner 体系架构:

A Spanner deployment is called a universe. 全球只有三个spanner,分别用于测试、开发/生产(VS dark launching from Facebook ?)和生产。

Spanner is organized as a set of zones, where each zone is the rough analog of a deployment of Bigtable. 全球big table 集群(类比)被统一管理,统一调度起来就是spanner。

The universe master is primarily a console that displays status information about all the zones for interactive debugging. universe master并不是用来服务系统的,更像是个管理工具。

 

 

 tablet和paxos state machine共存,多个互为replica的tablet和paxos state machine形成了paxos group,其中有一个是leader,也就是用于写的tablet,保管lock table等。该leader同时也是一个transaction manager,用于实现分布式transaction。当实现分布式transaction时候,有不止一个paxos group参与进来,这时候有一个group会被选作coordinator group,则该group的leader就是coordinator leader,该group的slave就是coordinator slave。(这部分跟Spanner没多少关系,是distributed transaction的经典内容)

在big table中,tablet只是行数据的容器,tablet内部的行都是一视同仁的;而spanner对tablet进行了进一步的结构划分,多了一层dictionary结构,用以区分那些PK前缀相同的行(比如,所有以Alice开头的行都在一个dictionary里面)。dictionary是数据复制和placement配置的基本单位,比如某个dictionary要分布在亚洲和美洲,共4份拷贝。

spanner中负载均衡的最小单位也是dictionary,同时提供方法MoveDir可以手动将一个dictionary移动到指定的zone。文中提到dictionary只是一层抽象目录,下面还有fragment才是真正的物理目录,有点诧异。细粒度当然可以更加优化负载均衡以及数据恢复,但是太细的粒度也意味着复杂度成倍增加,这是不是值得呢?可能的原因是某些用户的dictionary目录里面数据还是太多,而同时反正分布式transaction已经实现,不同fragment之间交互也顺便可以借点光,没有增加太多的实现负担,不过我仍然感觉到这点做的太复杂了。

另外,文中虽然没写,根据之前的一些资料,dictionary应该也是权限控制的最小单元。

 

关于数据模型:

关于big table 不实现传统transaction的理由是:我们认为这些transaction太复杂,程序员会过度使用transaction从而导致性能太差,所以不实现。

而这里spanner实现传统的transaction的理由是:系统的职责是实现应该有的功能,如果程序员用错了,那么改正就行了;但是如果系统不实现,谁也没办法用。

上面应该是经典的需求实现问题,不同的人会有不同的理解。

spanner的行模型是 (key:string, timestamp:int64) -> row content,可以看到跟big table的模型最大的不同是这里强化了row的概念,不再突出column;这样spanner的timestamp是赋给整行数据的,是有物理意义的,这使得spanner更像一个实现多版本并发的数据库,而在big table中,timestamp仅仅用于保存多个版本的key-value,跟并发完全无关;我觉得这也是为什么spanner称自己为semi-relational 数据库,而big table只称自己是semi-structure 数据库的原因。

下面是spanner的数据表模式,其中user是一张父亲表,album一张子表(不存在没有user的album),这非常像一个树形结构,user树枝,blbum是树叶,多么清晰,好的东西都是易于理解的,大部分时候也是难于实现的。

 

关于TrueTime:只要知道两点就可以了:

1. 一堆机器投票来决定当前时间应该是多少,然后按人头计数,人多者胜。

2. 跟传统投票不同的是,每个人不是报来一个数字,而是根据一般误差报上一个范围来,比如A报[3-4], B 报[4-5], C报[3-5],结果就会变成4,因为每人都同意现在是4点。再详细的话请看原论文吧。

 

并发控制:

1. 对于什么是external consistency, 我理解不深,觉得就当成serializable transaction的一种实现协议,和基于lock的、基于MVCC啥的并列,就可以了。解释:provides the illusion that each operation applied by concurrent processes takes effect instantaneously at some point between its invocation and its response, implying that the meaning of a concurrent object's operations can be given by pre- and post-conditions. 

2. 一个paxos group内的leader通过投票选出来,通过不停的延长lease继续担当leader的角色,文中提到paxos group内任何两个paxos leader必须保证disjointness invariant,这是为什么呢?因为每个leader都要给自己这个group内执行的transaction分配一个timestamp, 如果两个leader的interval有重叠,那么就不能保证所有leader在分配timestamp时候全局单调递增。其实就是说,咱们俩一人一个时间段,这个时间段内的时间点随便我们分配,只要我们各自保证分配的时间单调递增,则咱俩都是单调递增的。

3. 文中一堆时间,简单抽象一下就是:spanner不依靠事件通信来保证transaction一致性,而是依靠严格的时间序列。

一个极端简单的例子:某个partition内部最新commit的一个transaction的完成时间是3点,当前还有两个transaction继续在执行,不知道什么时候结束,那么如果这时候有一个读请求过来,那么我们只能认让这个读的请求看到(visible)3点之前的数据,因为3点之后的数据可能只写了一半,是不允许读的。那么文中那么多的时间序列和假设就是为了保证读请求过来的时候,我们能准确的找到3点这个数字。很容易?如果是单机当然容易,如果有一堆机器参与了分布式transaction,找到3这个数字并不是轻而易举。

4. 几种操作

读写操作:最典型的操作,基于锁的并发控制,只不过使用乐观锁,如果出现冲突,某些低优先级的transaction先终止(系统会自动再重试),高优先级的先完成。在准备写之前,依然是决定timestamp,如果不是分布式transaction,则自己选一个时间就可以了;如果是分布式transaction,则同时收取所有participant的建议,选一个最大的,再跟cooperator自己的now比较选个大的,继续向下进行。

只读操作:跟上面举的例子类似,就是找个最近刚commit的transaction的时间点,然后返回该时间点之前写入的数据。值得注意的是,这时候,因为所有的replica都已经完成了写入,所以该时间点只要找到了之后,可以随便挑一个replica进行读。

SnapshotRead:这就不用说了,时间点都省的找了,client会提供;不过如果client提供的时间点还未到来呢?根据系统实现可以选择报错或者block,不过我想报错更合理吧,读取未来数据的业务没见过。

 

这部分transaction看起来复杂,因为主要是细节问题,宏观问题都是清楚明白的。

 

不得不说,Google的创新力很可怕,Spanner恐怕两年内不会有开源的实现,因为其不仅依靠软件、而且依靠硬件,更主要的是,开源界可能没有那么紧迫的需求推动。


逐步搬之前的文章过来:http://www.cnblogs.com/raymondshiquan/articles/2697956.html


[1] Bigtable: A Distributed Storage System for Structured Data

[2] jeff notes 2009

[3] Spanner

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:

阿里云存储基于飞天盘古2.0分布式存储系统,产品多种多样,充分满足用户数据存储和迁移上云需求。

官方博客
链接