1. Abstract & introduction

ref：http://static.googleusercontent.com/media/research.google.com/zh-CN//archive/spanner-osdi2012.pdf

Spanner是google为了弥补bigtable的不足而推出的新一代的数据库系统。首先，看看bigtable有哪些不足。
     看这篇文章前应该看看bigtable的文章http://www.cnblogs.com/zwCHAN/p/3698191.html

• 只支持row级别的事物，不支持跨行事物，更别提跨表和跨库，乃至跨数据中心的事务性；
• 很好地依赖GFS天然支持解决了其他数据库通过复杂的replication才能解决的容错、读写分离的并发性问题，但是在跨数据库的容灾问题上，GFS没有提出有效的解决方案，bigtable当然也不支持；
• 它有k-v模型在海量数据的优势，同时也有该模型的劣势：相比支持sql的关系数据库，极为有限的查询功能；

另外，对于Gmail、Calendar、Android market、AppEngine这几个我平时用的应用时在Megastore上运行的表示极为惊讶。。

所以，Spanner的设计目标是集传统关系数据库和k-v模型数据库的优势于一体，支持可扩展、多版本、全球分布式、全局同步复制的半关系话数据库。为了支持这些特性，它提出了TrueTime的概念，使用了paxos同步算法、只读事务无锁化处理等方法；设计了一套类似Megastore的sql语言；为了支持全球范围的分布式数据库（同步复制）功能，spanner有几个功能很有启发性，

• 由应用负责细化数据复制和分布的策略。这一点传统数据库如mysql都是对外透明的；这显然是鱼和熊掌不能兼得的表现：全球范围内理论延时都有超过100ms，即使g神也无法超越光速。所以让应用根据自己需要做出权衡；应用可以控制数据做几个备份（不同数据中心的备份，在一个数据中心是由GFS复杂冗余备份的，后面说到备份<replica>同），以及在哪些数据中心放置这些备份；而spanner负责在这些指定的数据中心之间做数据的replica。
• spanner支持居于时间戳的读写的全局一致性。这是一件非常困难的事情。。

2 Implementation:

2.1 spanner的逻辑结构：

• 最外层，universe，这是整个数据库架构上的最大集合，从这个名字就能看出gger有多狂妄。。
  • universemaster除了名字同样很华丽外只做些监控调试的功能；
  • placement driver;placement driver这样低调名字的才是真中干大事的：负责自动跨zone的数据复制；
  • zone：到了zone级别后，就基本相当于一个bigtable系统了。
    • zonemaster
    • location proxy
    • spanner server

上图是spanner实际应用中24h平局延时和偏差。（跨美国东西海岸）。可见结果也不容乐观。

note: Spanner: Google’s Globally-Distributed Database,布布扣,bubuko.com