Google Cloud Spanner的架构与模型

次接触到Google Cloud Spanner是因为客户对于新技术的追求与尝试，将我们基本完成的APIs从原先的Google Cloud Sql迁移到Spanner数据库上。并且因为客户在老服务商已有百万个客户数据，也需要进行迁移，数据id是Spanner不默认支持的序列id。客户想要保留序列id格式，这也为我们迁移到Cloud Spanner数据库造成了一定麻烦。

但在我们不断接触Cloud Spanner并深入（对于我来说的深入:-p）了解后发现，Cloud Spanner的使用并没有想象中那样会特别复杂。尤其是Google为Cloud Spanner提供了大量对已有依赖的封装库，如hibernate、JDBC等。

Google Cloud Spanner

Cloud Spanner数据库原先作为Google内部使用的数据库，在2017年对外发布测试版。如今已经在Google云平台上架并拥有大量各个行业的用户。Cloud Spanner数据库是全球范围分布式的关系型/事务数据库，并且Google承诺Cloud Spanner拥有高吞吐量、低延迟和99.999%的高可用性。

分布式数据库

每一个Spanner的实例都是在不同数量的节点上运行的，每一个节点都是由Google云平台服务去自动管理的。因此，Cloud Spanner拥有很高的可扩展性，并且可根据请求负载和数据的大小进行自动分片（splits），为系统提供了更多的弹性空间。

关系型数据库

Cloud Spanner支持关系型数据库所有的功能，但Cloud Spanner不完全是关系型数据库，尽管Spanner的数据模型与任何其他关系数据库的数据模型基本相似，有预定义的数据元组，可以存储在关系(表)中并进行查询，但它缺乏约束。

Cloud Spanner拥有主键概念，并且必须为每个表定义主键，而且该主键是强制性的。然而它没有foreign key的概念，取而代之的是interleave。在关系型数据库中，我们期望数据的强完整性，以确保能满足预定义的约束。Cloud Spanner在该方面的能力有所限制。

事务数据库（ACID）

Cloud Spanner在事务上提供了严格的并发控制，实现全球事务对外强一致性。在外部一致性^[1]的保证下，即使Cloud Spanner的实例位于多个数据中心上运行，事务也能在高性能和高可用性的前提下按顺序执行。Cloud Spanner能够实现外部一致性得益于TrueTime的功能特性。Cloud Spanner 使用 TrueTime 的这一特性为事务分配时间戳。具体而言，每个事务都分配有一个时间戳，它反映 Cloud Spanner 认为事务发生的时间。

其他特性

Cloud Spanner还有很多其他的特性，包括单区域和多区域配置、多语言支持等^[2]。

数据架构与模型

Cloud Spanner和传统RDBMS的数据模型基本一致，都是由行、列和值组成，并且含有主键。Cloud Spanner中的数据是强类型，每个表需要定义一个架构，并且每一列的数据都需要制定数据类型^[3]。

CREATE TABLE customers(
    customer_id   INT64  NOT NULL,
    first_name    STRING(16),
    last_name     STRING(16)
)PRIMARY KEY (customer_id)