从分布式到云端服务：Google Spanner 成长之路

《从分布式到云端服务：Google Spanner 成长之路》要点：
本文介绍了从分布式到云端服务：Google Spanner 成长之路，希望对您有用。如果有疑问，可以联系我们。

摘要：距离 Google 开始开发 Spanner 已经 10 年,5 年前 Google 发表了论文,在 Google 云平台上增加开放 Spanner 服务,意义不仅仅是服务于 AdWords 和 Google Play,而是希望在云端更有所为.在这 5 年时间里,正是由于其他厂商无法复制 Google 的想法,即不能解决大规模集群下高可用性、水平扩展能力、数据强一致性等.本文从 Spanner 技术着手,逐渐引出最近的特大消息：Google 开放 Spanner 云端能力(测试版).

Spanner 技术概括

简介

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 最早的客户是 F1,它是一个 Google 广告系统的后台程序.F1 在美国境内一共有 5 个副本.大多数应用程序在选择分布式数据库的时候,首选要求是低延时,然后才是高可用性,只要能够挺过 1-2 次数据中心故障就可以了.

Spanner 是从类似于 Bigtable 这样的键值对(Key-Value)存储演变过来的一种时态多版本数据库.数据被存储在半关系型数据模型里,数据通过版本管理,每一个版本自动创建提交时间作为时间戳,老版本的数据服从垃圾回收机制管理.

和 NoSQL 数据库不同,Spanner 属于 NewSQL 数据库.

与其他数据库对比

我们针对 Spanner、关系型数据库、NoSQL 数据库所能提供的功能进行对比,如图所示.

?Spanner Schema 设计

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 之间的定期通信进行负载均衡).

每一个 spanserver?大约有 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 之间的数据备份.

（编辑：ASP站长网）