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原理

今天的文章spanner与bigtable分享到此就结束了，感谢您的阅读。