Cloud Spanner是Google Megastore系统的继承者，Spanner表现出远超前辈的能力。Spanner首次是在Google内部数据中心中出现，而在2017年才对外发布测试版并加入了SQL能力。如今已经在Google云平台上架并拥有大量各个行业的用户。Cloud Spanner数据库是全球范围分布式的关系型/事务数据库，并且Google承诺Cloud Spanner拥有高吞吐量、低延迟和99.999%的高可用性。
接触Cloud Spanner
第一次接触到Google Cloud Spanner是因为客户对于新技术的追求与尝试，将我们基本完成的APIs从原先的Google Cloud Sql迁移到Cloud Spanner数据库上。在做这个决定的时候，客户考虑到当时公司用户数量处于激增的阶段，业务也在不断进行更改，所以需要对表结构也进行更改来满足业务的需求。于是便决定使用Google Cloud Spanner来保证数据的ACID（原子性、一致性、隔离性和持久性）的前提下仍然可以对数据库进行水平拓展和分布式操作。
选择Cloud Spanner
和主流的云服务关系数据库相比，例如AWS的Aurora、GCP的Cloud SQL和Azure的SQLDB，这些数据库并没有实现在多节点上进行扩展的功能，只能在单个节点上进行垂直扩容（增加RAM或CPU数量）。
如果想要实现水平扩容，可以使用NoSQL数据库，例如HBase、MongoDB、DynamoDB或BigTable。但是这些数据库很难做到事务的特性，并且不能支持关系型数据库所支持的功能，例如连表等。并且因为NoSQL的查询语句和关系型数据库的语句区别很大，会导致应用中大量的查询语句和表结构需要重写。
而Cloud Spanner区别于这些数据库服务，是一种独特的数据库。它将事务，SQL查询和关系结构与NoSQL数据库的可伸缩性相结合。因此Cloud Spanner同时具备SQL和NoSQL数据库结构的优点。在最初的时候，Cloud Spanner是被设计为NoSQL的键值对的方式存储，但随着其对关系模型的需求被添加后，Cloud Spanner逐渐打破了NoSQL和SQL数据库之间的壁垒。
特性
作为分布式数据库
每一个Spanner的实例都是在不同数量的节点上运行的，每一个节点都是由Google云平台服务去自动管理的。因此，Cloud Spanner拥有很高的可扩展性，并且可根据请求负载和数据的大小进行自动分片（splits），为系统提供了更多的弹性空间。
作为关系型数据库
Cloud Spanner支持关系型数据库所有的功能，但Cloud Spanner不完全是关系型数据库，尽管Spanner的数据模型与任何其他关系数据库的数据模型基本相似，有预定义的数据元组，可以存储在关系(表)中并进行查询，但它缺乏约束。
Cloud Spanner拥有主键概念，并且必须为每个表定义主键，而且该主键是强制唯一性的。然而它没有foreign key的概念，取而代之的是interleave。在关系型数据库中，我们期望数据的强完整性，以确保能满足预定义的约束。Cloud Spanner在该方面的能力有所限制。
事务支持（ACID）
Cloud Spanner在事务上提供了最严格的并发控制，实现全球事务对外强一致性。在外部一致性的保证下，即使Cloud Spanner的实例位于多个数据中心上运行，事务也能在高性能和高可用性的前提下按顺序执行。Cloud Spanner能够实现外部一致性得益于TrueTime的功能特性。TureTime是Google为所有Google服务提供的高可用分布式的时钟。该时钟为应用提供单调递增的时间戳。Cloud Spanner 使用 TrueTime 的这一特性为事务分配时间戳。具体而言，每个事务都分配有一个时间戳，它为Cloud Spanner提供事务发生的时间。
其他特性
Cloud Spanner还有很多其他的特性，包括单区域和多区域配置、多语言支持等。
数据结构
Cloud Spanner和传统RDBMS的数据模型基本一致，都是由行、列和值组成，并且含有主键。Cloud Spanner中的数据是强类型，每个表需要定义一个架构，并且每一列的数据都需要制定数据类型。
其中，主键（PRIMARY KEY）被定义在表架构外。
数据的分布是通过主键实现的，因此在选择主键的时候需要尽量防止Cloud Spanner服务的热点（Hotspots），时间戳或者自增的序列数字都会造成热点问题出现，Cloud Spanner推荐使用随机（用户名等）的信息或者UUIDs作为主键。
交错表（Interleaved tables）
在Cloud Spanner中，是没有办法去定义两表之间外键（FOREIGN KEY）关系的。但是Cloud Spanner引入了一个类似的概念--交错表。
以上架构中表示为customers表创建accounts子表或“交错”表。其中需要注意的事项：
(1) customer_id是子表accounts的主键之一，也是父表的customers的主键。在accounts声明为customers子表时，该主键是必须添加的，并且要保证命名、类型、限制等都必须一致。
(2) 当插入子表时需要确保父表有对应的行（即以相同父表主键开头的行）。
(3) 删除父表行需要满足其中两点之一：
- 在子表中没有对应的行。
- 声明ON DELETE CASCADE。
(4) ON DELETE CASCADE 声明表示，当父表中的某一行被删除时，子表中对应的行也会被自动删除。如果没有该声明，或声明为ON DELETE NO ACTION，则必须先删除子行，才能删除父行。
(5) 交错行首先按父表的行进行排序，然后在父表共享主键的基础上，对子表进行再排序。
(6) 在对数据库进行分片操作的时候，只要父表行以及子表行的大小在8GB以内，并且在子表行中没有热点，则每个父表以及子表的数据的存放区域关系会一同保留下来。
交错表的主要目的是为了加快某些查询操作，尤其是包含JOIN的操作。因为交错表直接改变了数据在云上的布局方式，确保在执行JOIN操作的时候不会访问集群的每个节点（Nodes）。
二级索引（Secondary indexes）
在Cloud Spanner中，主键会被自动设置为表的索引，Cloud Spanner也同时支持将其他非主键字段设置为二级索引。
其中UNIQUE INDEX关键字表示，该索引会强制该字段在插入时需要不重复。并且在极少情况下，Cloud Spanner可能会自动选择让查询延迟增加的索引，此时可以使用FORCE_INDEX关键字提供指定索引进行查询操作。
数据库分片（split）
在表之间，Cloud Spanner支持最多7层的父子关系，也就是可以将7个逻辑独立的表的行物理地存储在一起。当相关表数据不断增长，达到单个Cloud Spanner服务器的资源限制时，作为分布式数据库的Cloud Spanner会将数据划分为各个“split”区块，每个分片都可以被独立移动并分配给不同物理位置的多个服务器。
分片包含一系列连续的行，这些行的开始和结束键称为“分片边界”（split boundaries）。Cloud Spanner 会根据大小和/或负载自动添加和移除分片边界，这样做会改变数据库中的分片数量。
基于负载进行分片
当数据库中的一个表上的10行数据的读取频率高于表中所有其他的行，Cloud Spanner就会为这10行中的每一行添加分片边界，以便于每一行是由不同的服务器处理，以此来避免这10行数据的读写操作只消耗单台服务器的资源（避免热点）。
表结构的更新
Cloud spanner支持对现有的数据库架构执行以下更新操作：
- 新建表。新表格中的列可以为 NOT NULL。
- 删除一个表，前提是该表内没有交错其他表，并且没有二级索引。
- 将一个非主键列添加到任何表，新的非主键列不能为 NOT NULL。
- 将 NOT NULL 添加到非主键列，不包括 ARRAY 列。
- 从非主键列中移除 NOT NULL。
- 从任何表中删除非主键列，前提是二级索引未在使用该列。
- 将 STRING 列更改为 BYTES 列，或将 BYTES 列更改为 STRING 列。
- 增加或减少 STRING 或 BYTES 类型的长度限制，前提是它不是由一个或多个子表继承的主键列。
- 在值和主键列中启用或停用提交时间戳。
- 添加或移除任何二级索引。
未来的趋势
基于Cloud Spanner独特的结构，它能确保客户在以较小的用户群和业务量为起点时，不必过多担心在未来数据量和业务量增长后需要对数据库进行迁移或重新编写的问题。Cloud Spanner在保证关系型数据库管理系统的特性前提下，同时提供数据库的超强延展性，并且可以在特定情况下对已存在的表的表结构进行结构更新。
因此，无论应用程序规模如何，Cloud Spanner都会是不错的选择，它能为应用提供包括事务支持、高可用性保证、只读副本以及轻松可伸缩性。
在《Google Cloud Spanner经济性分析》的文章中介绍到，Cloud Spanner的总花费比本地数据库服务花费低78%，比其他云平台数据库服务价格低37%。这得益于Cloud Spanner不需要用户为额外副本服务支出费用，就能确保数据库的高可用性。并且因为Cloud Spanner支持用户在不停机的情况下对数据库进行水平或垂直的缩放（由Cloud Spanner自动管理数据切片和数据复制）或对表结构进行更新例如添加索引等操作。
同时说明Cloud Spanner在使用经济上也提供了比自己维护的数据库服务更低的成本。
