Spanner数据库解读

      最近重读Spanner和F1的论文，涉及的实在太广。这篇文字从一些简单概念上说说这两者究竟是什么，实现上的一些创新，还有一些较常见的误读。以及对比当前的HBase和Phoenix区别

      Spanner最重要的设计点就是做全球数据库，要求可扩展性、多数据版本、多replica数据一致性和事务。是第一个款能实现全球数据分布而且还能实现分布式事务的数据库系统，从他的架构图来看底层也是基于Colossus(GFS二代)来存储文件，只不过上层的tablet还通过Paxos协议在做数据的replica。这点和HBase当前1.1版本引进的region高可用有点类似，但看起来又不全是。

     

在Spanner中，tablet的概念和Bigtable类似，都是B-tree的存储结构，和HBase的region对等关系。只不过在Spanner中创造了目录的概念，把不同表中相同rowkey前缀的数据放入到同一个directory中。这也是之所有能在几十TB数据量情况下做到多表关联的必要条件(而并非现在传说的遵循标准关系型数据库的schema模式可以随意来设计)

      同时，Spanner引入了Group概念，这个和HBase当前的Region Group类似，不同的Dir归属于不同的Group，数据以Group为单位进行逻辑上的存储。Group内数据被同一个Paxos管理起来，而不同的Group间Paxos不同。当然目录可以在Group之间来回移动，以达到负载均衡和容灾的目的。

  

      MVCC这个通过数据时间戳来实现，同一行数据内的原子性。读写事务不加锁(性能考虑)。这一点和HBase设计完全一致，只不过论文中提到数据有时间戳，而BigTable没有。多版本控制在HBase中也是标配，在BigTable里面也是用作淘汰旧数据的重要元数据，这点还不太理解。

      为了实现分布式事务，除了Paxos协议和两阶段提交。还有一个非常重要的前提，就是不同客户端提交的事务时间戳需要非常精确，因为这个决定了究竟哪个事务在前，哪个事务在后。这个时间戳的概念比较容易被误读成数据时间戳。在这里Spanner定义了读写事务、只读事务、快照读。读写事务对时间精确性要求较高，也许在10ms内会同时有客户端在读写同一条数据，谁先谁后对最终结果影响很大。只读事务和快照读目前还没分太清楚，大概是指定时间戳版本的读，读当前最新还是读一个历史版本

      论文中说道了原子钟实现的True API时间误差在10ms内，并且给出时间误差范围tt.earliest<t(e)<tt.latest。transaction manager通过事务提交时带的这个时间戳来管理所有事务的顺序和对结果进行处理。特别的读写事务，对性能一定会有所下降。

  

     Spanner通篇没有讲到他自己的sql如何强大，最多讲到了表结构以及存储方式上的创新(相对于BigTable而言)。以目录为最小存储单位，通过Group划分(资源隔离)，天生支持replica，跨数据中心同步，原子钟保障分布式事务。所以可以理解成对Bigtable的一种改进版本，Spanner论文中多次出现和BigTable的对比也说明了这一点。最终本质上依然是k-v的存储结构(要做到无限可扩展就避免不了核心数据结构只能是KV)，这里再补一张TiDB的架构图，TiDB其实是Spanner+F1实现的简化版本，底层用的KV Server

  

     所以Spanner依然可以划分到nosql数据库范畴内的，至于丰富的sql支持和索引等传统数据库的功能就放在上层的F1来实现了，下一篇讲讲F1