Spanner 是 Google 的可扩展、多版本支持、全球分布式的同步备份数据库，领军人物是 Eric Brewer，他是 CAP 理论的创造者、超级大牛。Spanner 是第一个支持全球规模的分布式数据库。当数据量或者服务器数量发生变化时，Spanner 在机器之间自动共享数据，并且 Spanner 在机器之间自动迁移数据（甚至在数据中心之间），用于负载均衡和响应失败。Spanner 被设计为可以在数百万台机器之上横向扩展，覆盖数百个数据中心、上亿条数据。五年前发表的论文《在 Google 云平台上增加开放 Spanner 服务》，描述了 Spanner 数据库的内部结构是怎么样的、包含哪些属性、各种设计决策的基本原理，也暴露了一种新的不确定性时钟时间 API。这些 API 和他们的实现对于支持外部一致性和几个重量级的特征来说极其重要，这些特征包括非阻塞式多版本读（nonblocking reads in the past）、无锁只读交易（lock-free read-only transactions）、原子模型变化（atomic schema changes），这些特征贯穿 Spanner 内部设计。
Spanner 是一个在遍布全球范围的数据中心内部穿过多套 Paxos 状态机器共享数据的数据库。复制被用于全局可用性和地理位置；客户在副本之间自动切换。当数据量或者服务器数量发生变化时，Spanner 在机器之间自动共享数据，并且 Spanner 在机器之间自动迁移数据（甚至在数据中心之间），用以负载均衡和响应失败。Spanner 被设计为在几百万台机器之上横向扩展，这些扩展穿过了数百个数据中心和万亿行数据。
应用程序可以使用 Spanner 实现高可用性，甚至面对大面积的自然灾害，通过地区内部、甚至跨洲的备份数据策略。Spanner 最早的客户是 F1，它是一个 Google 广告系统的后台程序。F1 在美国境内一共有 5 个副本。大多数应用程序在选择分布式数据库的时候，首选要求是低延时，然后才是高可用性，只要能够挺过 1-2 次数据中心故障就可以了。
Spanner 是从类似于 Bigtable 这样的键值对（Key-Value）存储演变过来的一种时态多版本数据库。数据被存储在半关系型数据模型里，数据通过版本管理，每一个版本自动创建提交时间作为时间戳，老版本的数据服从垃圾回收机制管理。
和 NoSQL 数据库不同，Spanner 属于 NewSQL 数据库。
我们针对 Spanner、关系型数据库、NoSQL 数据库所能提供的功能进行对比，如图所示。
Spanner 不需要每张表必须有一个主键列。由于 Bigtable 持续被投诉，所以 Google 在设计 Spanner 时把分布式交易集中化，因为过多的交易容易造成性能瓶颈出现。
在 Spanner 的模式定义语言里，你可以在表之间使用 INTERIAVE IN 申明表之间的层次关系。在层次关系的最顶层表示一张 Directory 表，其他的下级表示按照字典形式命名排序的。ON DELETE CASCADE 被用于当 Directory 表里的一行数据被删除时，相应地一并删除子表里的对应数据。创建 Spanner 数据表如图所示。
Spanner 提供三种类型的操作：读 / 写交易、读交易和快照读操作。单一的写操作是通过一个读 / 写交易执行的，然而一个单一的读操作，不是一个快照读，是通过一个读交易执行的。
一个写操作执行了一个读 / 写交易，在提交交易之前都是缓存在客户端。一个交易里面的读操作，不会被写操作的结果所影响。读 / 写交易当中的读操作使用了 Wound-Wait 方式避免死锁。客户端从协调节点获取读锁，然后读取最新的数据。
Spanner 最初的出现就是因为 Google 内部使用的 Bigtable 无法确保跨地区的数据中心强一致性。Spanner 的整体集合被称为 Universe。一个 Universe 又由几个 Zone 组成。一个 Zone 意味着一个单元，这个单元可以物理上独立运行。一个数据中心可能超过 1 个 Zone。如果你想要在不同的服务组内存储数据，你需要在一个数据中心内部建立两个或者以上的 Zone。
上面这张图显示了在一个 Universe 里面配置的服务器，一个 Zone 由一个 Zonemaster 和几千个 Spanserver 组成。Zonemaster 为 Spanserver 分配数据。同时，Spanserver 实际存储和处理数据。Location Proxy 通过客户端调用，显示目标数据被存储在哪个 Spanserver。Universemaster 提供了所有 Zone 的状态或者调试信息，并且 Placement Driver 实际上执行 Zone 之间的数据传输，决定是否数据被移除了（由于备份策略改变或者通过与 Spanserver 之间的定期通信进行负载均衡）。
每一个 spanner serve 大约有 10 到 1000 个被叫做 Tablet 的数据结构。Tablet 可以存储多个映射，字符串 (key:string, timestamp:int64) 形式。Spanner 里的 Tablet 和 BigTable 里的 Tablet 的差别是，Spanner 存储一个数据的同时带了时间戳。这意味着 Spanner 不仅仅是一个简单的键值对存储，而是带有多版本特性的数据库。
Table 的状态存储在 Colossus Distributed File System，基于二叉树文件形式和 write-ahead log（WAL）。
Spanner 使用 Paxos 状态机支持 spanservers 之间的数据备份。
一个 spanserver 有交易管理者，用于支持分布式事务。交易管理者在单一 Paxos 组内不会参与交易执行，但是当多个 Paxos 组之间进行交易时它会参与进去，参与人之一会被选举为协调组长，基于 phase-2 commit 协议执行协调。
目录是一组连续的键，这些键使用相同的前缀（你可以想象成一个桶）。Directory 是一个数据分配的基本单元。Directory 里面的所有数据有定义好的备份设置，并且 Paxos 组之间的数据传输也是指定的。
一个应用程序可以在一个 universe 内部创建 1 个或多个数据库，一个数据库有多张表（没有上限）。一张表有行和列，比关系型数据库表多的是有版本信息。在 Spanner 的模式定义语言里，你可以在表之间使用 INTERLEAVE IN 申明层次（hierachical）关系。在层次关系的最顶层表示一张 directory 表。根据 directory 表里定义的键，字表命名是根据字典排序的。ON DELETE CASCADE 被用于当 directory 表的一行数据被删除时，相应地一起删除子表里面的数据。
Spanner 的最早的客户是 F1，它是一个 Google 广告系统的后台程序。F1 在美国境内一共有 5 个副本。许多其他的应用程序最有可能的是在一个地理区间内在 3 到 5 个数据中心中间复制数据，但是它们具有相对独立的失效模式（failure mode）。也就是说，大多数应用程序会首选较低延迟，然后才是高可用性，只要能够挺过 1 到 2 次的数据中心故障。
Google F1 SQL 数据库管理系统构建在 Spanner 之上，用于替换 Google 的 MySQL 定制版本。
Spanner 使用 Paxos 算法作为操作的一部分，用于在数百个数据中心之间共享数据。
Spanner 提供了类似于关系型数据库的功能支持和操作方式，每张表都有主键、可以管理和删除级联表的数据。Spanner 支持 ACID 和 SQL 语句。由于 Spanner 会把上亿条数据存放在全球很多数据中心里，所以当你读取数据时，Spanner 把读取请求发到物理上最接近你的数据中心，当你写入数据时，你会存储到多个数据中心。如果数据中心整体停止服务，你也可以从副本数据中心环境读取数据。
Spanner 并不开源，但是有开源实现 CockroachDB，源码请访问这里。
2017 年 2 月 14 日（情人节），Google 宣布 Cloud Spanner 发布测试版本。这是一个基于云端的全球分布式关系数据库服务，支持包括 ACID 交易、SQL 语义，支持水平扩展和高可用性。当我们构建一个基于云端的应用程序时，数据库管理员和开发人员都需要去选择使用关系型数据库或者 NoSQL 数据库，关系型数据确保交易持久性，NoSQL 数据库提供了简单、水平扩展和数据分布式。Cloud Spanner 打破了这种非此即彼的选择方案，提供了集两个关键能力与一体的，完全管理的服务。
Cloud Spanner 与 Google 颇有渊源，早在 2012 年的一份文件中 Google 就记录了 Cloud Spanner，并且已在内部使用多年。目前谷歌的云数据库服务阵营包括 Google Bigtable(谷歌 2015 年发布的一个全面管理、高性能、可扩展的 NoSQL 数据库服务)、Google Container Engine(谷歌为解决企业管理大量容器技术编排的繁琐工作而推出的容器管理服务) 等。
Google 产品经理 Deepti Srivastava 曾在一篇博文中写道：
Cloud Spanner 通过在熟悉的关系数据库环境中支持标准工具和语言，简化了应用程序开发。它是传统关系数据库支持运行的工作负载的理想选择，如库存管理，金融交易和控制系统以及其它系统。
Cloud Spanner 同 GCP、Cloud SQL、Cloud Datastore、Cloud Bigtable 一起，丰富了我们数据库服务的能力。
作为一个可控的服务，Cloud Spanner 给 DBA 提供了下列重要福利：
-
让 DBA 把宝贵的精力专注于业务逻辑上，而不是用于处理各种软件或硬件问题；
-
使得 DBA 不用执行复杂的分片或者集群操作，就可以实现对 RDBMS 解决方案的扩展；
-
DBA 不用把关系数据库迁移到 NoSQL 数据中，也能获得数据的水平扩展能力；
-
DBA 无需复杂的数据备份或失效援备机制，即可维护数据的高可用性，以及具备对数据的灾备恢复能力；
-
将安全性与数据层加密，身份验证，接入管理，日志审核等功能进行整合。
Cloud Spanner 并没有违反 CAP 定理。这些年，我们已经让 Spanner 打赢了 Google 内部很多场战斗，数百个不同的应用程序，PB 级别的数据在全球的数据中心间转移。在 Google，Spanner 支持每秒数以百万计次的查询，运行的应用程序包括 AdWords 和 Google Play。
有了 Cloud Spanner，你可以对数据库的规模按照需求来扩展和缩小，然后你只需要按照使用规模来付费即可。Spanner Cloud 的特色之一就是提供了一个简洁的收费模式，可通过计算节点使用的小时数，实际存储消耗（而不是预估存储消耗）以及外部网络接入等指标来计算费用。
