spanner与bigtable

今天看了一下关于spanner的文档,google都说它是下一代Bigtable,也是Megastore的继承者了,总得看下是个什么样的玩意儿。资料有限,以后看到了再更新。今天的整理如下:


关于bigtable:google-bigtable

Bigtable存在的主要问题:

1. 分布式事务:每个事务都应该遵循事务的ACID原则,但是big table无法支持,它只能执行单行事务,一行数据中包含多个列(column),一个事务中可以操作同一行中的多个列。

2.强一致性数据同步:比如A要求B和C分别对数据进行运算,则必须在B和C无异常时才可进行,要是有一个人拒绝,则整个事务没法进行,得不到结果也就是事务被取消,资源得不到更新。

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

注:ACID,指数据库事务正确执行的四个基本要素的缩写。包含:原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性(Durability)。一个支持事务(Transaction)的,必需要具有这四种特性。

参考:spanner的前世今生略有出入。


关于spnner的体系架构:



Universe。一个Spanner部署实例称之为一个Universe。目前全世界有3个。一个开发,一个测试,一个线上。因为一个Universe就能覆盖全球,不需要多个。

Zones. 每个Zone相当于一个数据中心,一个Zone内部物理上必须在一起。而一个数据中心可能有多个Zone。可以在运行时添加移除Zone。一个Zone可以理解为一个BigTable部署实例。

Universemaster: 监控这个universe里zone级别的状态信息


Placement driver:提供跨区数据迁移时管理功能


Zonemaster:相当于BigTable的Master。管理Spanserver上的数据。


Location proxy:存储数据的Location信息。客户端要先访问他才知道数据在那个Spanserver上。


Spanserver:相当于BigTable的ThunkServer。用于存储数据

在big table中,tablet只是行数据的容器,tablet内部的行都是一视同仁的;而spanner对tablet进行了进一步的结构划分,多了一层dictionary结构,用以区分那些PK前缀相同的行(比如,所有以Alice开头的行都在一个dictionary里面)。dictionary是数据复制和placement配置的基本单位。spanner中负载均衡的最小单位也是dictionary,同时提供方法MoveDir可以手动将一个dictionary移动到指定的zone。

关于数据模型:

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 数据库的原因。

TrueTime:

rueTime API 是一个非常有创意的东西,可以同步全球的时间。TT.now()可以获得一个绝对时间TTinterval,这个值和UnixTime是相同的,同时还能够得到一个误差e。TT.after(t)和TT.before(t)是基于TT.now()实现的。那这个TrueTime API实现靠的是GFS和原子钟。之所以要用两种技术来处理,是因为导致这两个技术的失败的原因是不同的。GPS会有一个天线,电波干扰会导致其失灵。原子钟很稳定。当GPS失灵的时候,原子钟仍然能保证在相当长的时间内,不会出现偏差。实际部署的时候。每个数据中心需要部署一些Master机器,其他机器上需要有一个slave进程来从Master同步。有的Master用GPS,有的Master用原子钟。

读写操作好像没有什么特别的。

再推荐一篇:google全球级分布式数据Spanner原理

相关文章
相关标签/搜索