Cloud Spanner 完全托管式关系型数据库服务

作者：班博编程 2022-05-27 07:37:38数据库 其他数据库 Cloud Spanner 是完全务一项完全托管式用于关键任务的关系型数据库服务，可提供全球范围的托管事务一致性、自动同步复制功能以实现高可用性。式关数据

前沿

2012~2013年Google 相继发表了Spanner和F1两套系统的系型论文，让业界第一次看到了关系模型和NoSQL的库服扩展性在一个大规模生产系统上融合的可能性。Spanner 通过使用硬件设备(GPS时钟+原子钟)巧妙地解决时钟同步的完全务问题，而在分布式系统里，托管时钟正是式关数据最让人头痛的问题。Spanner的系型强大之处在于即使两个数据中心隔得非常远，也能保证通过TrueTime API获取的库服时间误差在一个很小的范围内(10ms)，并且不需要通讯。完全务Spanner的托管底层仍然基于分布式文件系统，不过论文里也说是式关数据可以未来优化的点。

Google的系型内部的数据库存储业务，大多是库服3~5副本，重要的数据需要7副本，且这些副本遍布全球各大洲的数据中心，由于普遍使用了Paxos，延迟是可以缩短到一个可以接受的范围(写入延迟100ms以上)，另外由Paxos带来的Auto-Failover能力，更是让整个集群即使数据中心瘫痪，业务层都是透明无感知的。F1是构建在Spanner之上，对外提供了SQL接口，F1是一个分布式MPP SQL层，其本身并不存储数据，而是将客户端的SQL翻译成对KV的操作，调用Spanner来完成请求。严格来说，是Spanner和F1一起开创了NewSQL风格。

简介

Cloud Spanner 是一项完全托管式用于关键任务的关系型数据库服务，可提供全球范围的事务一致性、自动同步复制功能以实现高可用性。它是第一个把数据分布在全球范围内的系统，并且支持外部一致性的分布式事务。Spanner的扩展性达到了令人咋舌的全球级，可以扩展到数百万的机器，数已百计的数据中心，上万亿的行。除了夸张的扩展性之外，他还能同时通过同步复制和多版本来满足外部一致性，可用性也是很好的。冲破CAP的枷锁，在三者之间完美平衡。它是BigTable的继任者。谷歌称Spanner不是一个纯粹的关系型系统，因为每个表必须有主键，以及对两种 SQL 方言的支持：Google 标准 SQL(ANSI 2011 及扩展程序)和 PostgreSQL。

优势

• 享受关系语义和 SQL 的所有优势，并且规模不受限制。
• 以任何规模起步，可随需求增长无限扩容。
• 享受零计划停机时间和在线架构变更带来的高可用性。
• 可跨区域和洲实现具有强一致性的高性能事务。
• 专注于创新，通过自动分片等功能消除人工作业。

特性

• 可灵活扩缩的关系型数据库：从架构、SQL 查询到 ACID 事务，关系型数据库应有的一切功能都具备，久经考验，且随时可以在全球范围内扩容。
• 99.999% 的可用性：Cloud Spanner 可为多区域实例提供业界领先的 99.999% 可用性;与 99.99% 的可用性相比，停机时间是其十分之一。它还可跨单区域和多区域配置提供透明的同步复制功能。
• 自动分片：Cloud Spanner 可根据请求负载和数据大小自动分片，从而提升性能。因此，您不必太担心如何对数据库进行扩容，从而可以专注于扩展业务。
• 全代管式：无论数据库规模如何，每个阶段均可实现轻松部署。内置自动同步复制和维护功能。
• 事务强一致性：专为实现行业领先的外部一致性而构建，同时不会影响可扩缩性或可用性。
• 单区域和多区域配置：无论用户位于哪里，由 Spanner 提供支持的应用都可以在全球范围内读取和写入最新的强一致性数据。此外，运行多区域实例时，您的数据库可以防范单区域故障，并提供业界领先的 99.999% 可用性。
• 使用 BigQuery 执行联合查询：在 BigQuery 中实时查询 Spanner 数据，而无需移动或复制数据，消除运营数据与分析之间的差异，打造统一的数据生命周期。
• 基于 Google Cloud 网络构建：Cloud Spanner 基于 Google 的专用网络构建，该网络提供低延迟、安全性和可靠性，可为全球用户提供服务。

场景

Spanner 是一种分布式的、全球可扩展的 SQL 数据库服务，该服务将计算与存储分离，使其可在存储之外单独扩缩处理资源。 Spanner 这种分布式扩缩特性使其成为不可预测的工作负载(如在线游戏)的理想解决方案。

事务

Spanner 系统中的分布式事务通过两阶段提交协议2PC实现。2PC是一类特殊的一致性协议，假设一个分布式事务涉及了多个数据节点，2PC可以保证在这些节点上的操作要么全部提交，要么全部失败，从而保证了整个分布式事务的原子性ACID里的A。协议中包含两个角色：协调者coordinator和参与者participant/cohort。协调者是分布式事务的发起者，而参与者是参与了事务的数据节点。在协议最基本的形式中，系统中有一个协调者和多个参与者。Cloud Spanner 中的事务是一组读写操作，它们跨数据库中的列、行和表，在单个逻辑时间点以原子方式执行。

Cloud Spanner 支持以下事务模式：

• 锁定读写：这种事务类型是唯一支持将数据写入 Cloud Spanner 的事务类型。这些事务依赖于悲观锁定和(如有必要)两阶段提交。锁定读写事务可能会中止，需要应用重试。
• 只读：这种事务类型可保证多次读取之间的一致性，但禁止写入。只读事务可以配置为在过去的时间戳处读取。只读事务不需要提交，也不会锁定。
• 分区 DML：此事务类型将数据操纵语言 (DML) 语句作为分区 DML 执行。分区 DML 专为批量更新和删除(尤其是定期清理和回填)而设计。

模型

一个 Cloud Spanner 数据库可以包含一个或多个表。这些表与关系型数据库表类似，它们也是由行、列和值构成的，并且包含主键。Cloud Spanner 中的数据是强类型的：必须为每个数据库定义一个架构，并且该架构必须指定每个表中每一列的数据类型。允许的数据类型包括标量和数组类型，也可以在表上定义一个或多个二级索引。

父子表

可以通过两种方式在 Cloud Spanner 中定义父子关系，表交错和外键。Cloud Spanner 的表交错是许多父子关系的理想选择，其中子表的主键包含父表的主键列。子行及其父行共用位置可以显著提高性能，外键是一种较通用的父子解决方案，并解决了其他用例。外键不限于主键列，而表可以具有多个外键关系，二者在某些关系中可以作为父键，而在其他关系中可以作为子键。但是，外键关系不隐含表在存储层中的共用位置关系。

主键

每个表都必须有一个主键，并且该主键可以由该表的零列或多列组成，如果将某个表声明为另一个表的子表，则父表的主键列必须是子表主键的前缀，Cloud Spanner 会按主键值得排序顺序存储行，并在父行之间插入共享相同主键前缀的子行，这意味着，如果父表的主键由 N 列组成，则其每个子表的主键也必须由相同的 N 列组成，顺序相同，并且以相同的列开始。这种沿着主键维度在父行之间插入子行的行为称为交错，而子表也称为交错表。

分片

表之间定义最多七层的父子关系层次结构，意味着可以将七个逻辑上独立的表的行存储在一起。如果表中的数据量比较少，那么您的数据库或许可以由单个 Cloud Spanner 服务器处理。然而，当相关表不断增长，开始达到单个服务器的资源限制时。Cloud Spanner 会将数据划分为称作“分片”的区块，各个分片可以彼此独立移动并被分配给不同物理位置的多个服务器。分片包含一系列连续的行。这一范围的开始和结束键称为“分片边界”。Cloud Spanner 会根据大小和/或负载自动添加和移除分片边界，这样做会改变数据库中的分片数量。

复制

Cloud Spanner 复制的优势包括以下几点：

• 数据可用性：对于希望读取数据的客户端而言，拥有更多数据副本可以使数据更具可用性。另外，即使某些副本不可用，Cloud Spanner 仍然可以支持写入操作，因为在提交写入时仅需大部分投票副本即可。
• 地理局部性：能够使用 Cloud Spanner 将数据存放到不同的区域和大洲，这意味着数据可以在地理上更接近需要它的用户和服务，因此访问速度也更快。
• 单一数据库体验：得益于同步复制和全局高度一致性，无论规模如何，Cloud Spanner 均可提供一致的表现以及单一数据库体验。
• 更轻松的应用开发：Cloud Spanner 的 ACID 事务具有全局高度一致性，这意味着开发者无需在应用中添加额外的逻辑来处理最终一致性，因此应用开发和后续维护变得更加轻松快捷。

总结

Spanner是第一个可以在全球范围内提供这种保证的系统，符合 ACID 标准的数据库，可自动进行副本、分片和事务处理，因此可以快速扩容以满足任何使用模式的要求，Cloud Spanner 基于 Google 的专用网络构建，在数十亿用户都在使用的 Google 服务中已久经考验。它可实现高达 99.999% 的可用性，在计划内维护和架构变更期间可以做到零停机。IT 管理员和数据库管理员往往忙于执行数据库运维工作。现在，借助 Cloud Spanner，只需点击几下鼠标即可创建或扩缩可在全球范围内复制的数据库，并降低数据库维护费用。

责任编辑：姜华 来源： 今日头条 关系型数据库Spanner

(责任编辑：娱乐)