数据库是几乎每个应用程序的关键架构组件。设计应用程序时，始终需要持久地存储应用程序数据。如果没有持久化地向共享数据库存储数据，无论是应用程序可扩展性还是对底层硬件升级都无法实现。更加灾难性的是，一旦发生基础架构故障，任何数据都将立即丢失。
而借助可靠的数据库，您能够实现应用程序可扩展性，并确保数据的持久性和一致性以及服务可用性和更高的系统支持能力。数据库是几乎每个应用程序的关键架构组件。

Google Cloud 的 Spanner 数据库是为了满足 Google 以及我们许多云客户的产品的结构化数据存储需求而构建的。Spanner 是 Google 核心基础架构的组成部分，是对我们业务可信赖的保障，对您同样如此 —— 无论您所处行业或者应用场景如何。

在 Spanner 之前，对于需要事务的应用场景，我们的产品主要使用分片的的 MySQL。正如 Spanner 论文所述，开发工作的目标是为那些有复杂、不断演化的数据库表结构或者那些需要在跨不同区域复制时保持强一致性的应用程序创建数据存储服务。

当考虑 Spanner 时，首先出现的概念之一是其可伸缩至任意数据库大小的能力。Spanner 确实在支持为我们数十亿用户提供功能的 Google 应用（例如，Gmail 和 YouTube），因此，可伸缩性必须是一个一流的特性。

在本文中，我们将探讨 Spanner 如何被设计用于以任何规模运营的应用程序 —— 无论大小、涵盖各种应用场景；它如何为开发人员提供较低的门槛；以及它如何降低总拥有成本 (TCO)。以下是您需要了解的相关知识。

以任何规模为起点，随着业务增长而扩展

Spanner 能够处理大规模的数据量，因此，它对许多不同大小的应用程序都有用，而不仅仅是那些大的应用程序。而且，针对所有需要 RDBMS 的工作负载，基于一个数据库引擎实现标准化会让您的组织受益匪浅。通过将熟悉的关系数据库管理系统 (RDBMS) 的特性（例如，ANSI 2011 SQL、DML、外键）与一些独特特性（例如，通过 TrueTime 实现的外部强一致性以及通过原生同步复制实现的高可用性）相结合，Spanner 为各种应用提供了坚实的基础。

我们要花点时间来挑战一下人们对“小型”的可能认知：较小的应用程序并不重要，或者它们没有很高的可用性目标，也不需要事务性强化。这种分类并不表示一款应用程序的业务关键性比一款大型应用程序低。也不意味着一款特定应用程序最终将不需要比最初推出时更高的规模。尽管您的应用程序可能以小的用户群或者业务量为起点，但 Spanner 的这种可伸缩性优势不应当被忽视。采用 Spanner 后端设计的应用程序，如果成功，将不需要重新编写或者进行任何类型的数据库迁移，即可满足未来数据量或业务量增长需求。

例如，如果您的公司是一家正在开发下一款开创性的超酷游戏的公司，如果游戏一经发布即取得成功，您要准备好应对用户数量的不断增长。

无论您的应用程序规模如何，选择 Spanner 都会让您受益匪浅，包括事务支持、高可用性保证、只读副本以及轻松可伸缩性。

事务支持和外部强一致性

Spanner 通过 TrueTime 提供外部一致性保证。Spanner 使用这种完全冗余的原子钟系统从一个虚拟分布式全球时钟获得时间戳。由于一旦提交，Spanner 可以将来自全球一致同意的来源的时间戳应用于每个事务，因此，事务提交序列是明确的。外部一致性需要按顺序执行所有事务。Spanner 可确保这种强一致性。

许多应用类型需要强一致性，尤其是那些要维护大量货物或者货币的应用，对于这类应用，最终一致性可能完全不适合，包括但不仅限于供应链管理、零售定价和库存管理、银行业务、贸易以及分类账应用。

如果您的数据库不具备强一致性，事务必须被拆分为单独的操作。如果事务不是原子性的，则意味着该事务可能部分失败。设想一下您使用数字钱包来分摊费用的情况，例如，与朋友聚餐的成本。如果从您的钱包向他们的钱包转钱未在一个具备强一致性的事务中处理，您可能发现自己处在一半事务已经失败的境地：资金既不在您的钱包中也不在您的朋友的钱包里。

最终一致性的“不良特性”是名义上的：在数据库操作之后，整体数据库立即的状态不一致；只有到最后变更才会返回给所有请求者。在此期间，不同的客户端请求可能返回不同的结果。例如，如果您使用社交媒体服务，可能遇到过按下按钮发布图片与图像在您的时间线中显示之间出现时间延迟的情况。Niantic —— Pokemon GO 的创造者，专门选择 Spanner 来避免其社交应用中的这类不一致性。

您可以参阅有关强一致性的这篇博文了解更多详细信息。基本上，Google 了解到的是，当开发人员能够依靠基础数据存储来应对复杂事务处理并保持数据有序时，应用程序代码更简单，开发时间更短。我们在此引用原 Spanner 论文的观点，“我们认为最好让应用开发者处理由于过度使用事务而导致的性能瓶颈问题，而不是总是围绕缺少事务进行编码。”

高可用性保证

Spanner 提供高达 99.999% 的可用性，针对计划维护和数据库表结构变更的停机时间为零。Spanner 是一项完全托管的服务，这意味着您无需进行任何维护。自动软件更新和实例优化在后台完成。这种更新和优化是在没有任何维护时间窗的情况下实现的。而且，如果存在硬件故障，您的数据库将无缝恢复，无需停机。

Spanner 实例通过同步复制提供这种高可用性 —— 对于区域实例，在单一云区域内的独立可用区中的三个副本之间进行同步复制；对于多区域实例，在跨两个云区域的独立可用区中至少四个副本之间进行同步复制。Spanner 区域实例在亚太、美洲、欧洲、中东以及非洲地区的各个区域可用；多区域实例在全球以不同区域组合形式提供。
这可以保护您的应用避免针对区域实例配置的基础架构和可用区故障，以及针对多区域实例配置的区域故障。

只读副本

如果要处理可以容忍少量数据过时的读请求，您可以更好地利用这些副本所提供的计算能力并且以较低的平均读延迟接收结果。如果您使用多区域实例配置并且副本位于接近您的应用程序客户端的地理位置，这种延迟减少的效果会非常显著。

对于可以接受这种约束的查询，副本能够提供对您过时读取查询的直接响应，无需咨询读写副本 (split leader)。如果采用多区域实例配置，副本在地理位置上可能更接近应用程序客户端，这可以显著提升读取性能。

当使用异步读取副本部署传统 RDBMS 拓扑时，这种能力相当于所实现的水平伸缩。不过，不同于典型的关系数据库，Spanner 提供此特性且无需额外的操作或管理开销。

轻松水平扩容和缩容

Spanner 将计算资源与数据存储分离，这使得在不对基础存储进行任何变更的情况下增加、减少或者重新分配处理资源池成为可能。这对于传统的开源或基于云的关系数据库引擎是不可能的。

这意味着通过一次点击或者 API 调用即可实现水平扩容，因此，您可以根据应用需要，实现更高的每秒操作容量，即使数据吞吐量仍然很低。而且，添加的额外计算资源可以同时处理读取和写入。

缩容同样简便。Spanner 为您提供这种能力，只需按下按钮即可实现，可以随着您的需求变化轻松添加或者删除实例节点，并且这些变更几秒钟内即可生效。

在其他数据库（关系型和 NoSQL）中，要水平扩展集群以支持更多写入容量并非易事。此外，容量添加后要删除可能并不简单，甚至不可能。

Spanner 作为通用数据库脱颖而出

关系数据库以 1970年 E.F. Codd 撰写的一篇论文中论述的概念为基础，尽管是最古老的、仍在使用的数据库技术，RDBMS 依然保持着其作为大多数新项目首选数据库的地位。

关系数据库是值得信赖的技术，许多企业与我们分享了与其最初选择 MySQL 或 PostgreSQL 相关的成功案例。企业选择这一技术的原因在于开发人员了解 SQL，同时也是因为关系模型在产品开发过程中所具有的灵活性。（对于前述观点，值得一提的是，在很多情况下，这些起源故事继续讨论了一旦数据量超过不可管理的程度与关系数据库相关的极端管理工作。）

当然，利用 Spanner，涉及更多抽象概念。Spanner 是一个分布式数据库，稳健的系统为其提供了外部强一致性，具有位于服务器机架上的冗余本地和远程原子时钟，并且分别通过 GPS 信号可用。它仍然提供熟悉的、符合 ANSI-SQL 要求的关系数据库接口。因此，应用程序开发人员可以快速地熟练掌握。

在 Google，数据库技术已经证明了它对无数应用的价值 —— 无论内部和外部，也不论大和小。Spanner 保持着其作为一项基础技术的稳固地位，为开发人员提供了低门槛，因此，能够自由地尝试新的想法。

尽管对于一些产品应用程序，我们的用户群可能极其庞大并且业务量可能非常高，但也有其他服务小众人群的不太常用的应用程序。Spanner 是适用于两个应用程序类别的后端数据存储服务。

各种垂直行业中的 Google Cloud客户已经成功将 Spanner 用于众多核心业务应用场景：游戏 (Lucille Games)、金融科技 (Vodeno)、医疗保健 (Maxwell Plus)、零售 (L.L.Bean)、技术 (Optiva) 以及媒体娱乐 (Whisper)。以下是在不同行业如何使用 Spanner 的示例：

Spanner 带来更简单的体验、更低的 TCO

考虑总拥有成本 (TCO) 时，Spanner 的运营成本更低。而且，当您考虑机会成本时，投资回报率 (ROI) 甚至更高。在使用每小时价格对 Spanner 运营费用进行单独评估之前，通过全面对比替代选项的各种成本和 Spanner 所提供的价值，将 Spanner 与其他数据库选项进行比较。

首先，考虑运行生产级数据库的成本。有三个成本类别：资源、运营和机会。由于它基于已发布的定价，因此，资源成本计算相对简单。运营成本的计算有点难，因为这一成本相当于完成各种任务所需要的团队成员数量。机会成本计算不太具体，但不应被忽视。当您选择针对一个类别来花费组织预算（以货币或小时计算）时，可用于其他机会的预算将相应减少。

作为练习，我们将首先讨论资源成本 —— 通过将 Spanner 的定价与基于虚拟机运行的自己搭建的开源数据库进行对比。然后，我们将比较相同环境的运营负担和成本。最后，我们将探讨 Spanner 提供的一些机会价值。

当您考虑在小型虚拟机上运行的单一数据库引擎时，Spanner 可能看起来成本不菲。不过，不建议在单一计算节点上运行生产数据库。更有可能的是，您将基于一个具有足够内存和附加永久磁盘的中型虚拟机来运行，可为中短期增长提供足够的空间。

也可能您已经配置了高可用性数据库拓扑，包括一个在线数据库副本，与您的生产虚拟机具有相同的规格。此外，您还可能维护一个专门用于只读工作负载的额外副本数据库。

如果是这样，您拥有了与 Spanner 所提供的等同的计算和存储拓扑。您有三个数据副本和三个运行虚拟机：一个虚拟机管理写操作，第二个虚拟机作为高可用性副本，第三个虚拟机用于只读工作负载。这反映了 Spanner 所蕴含的核心理念：您应当运营至少三个副本以确保高可用性。

现在，让我们考虑一下与基于 Compute Engine 运行的数据库相比，Spanner 的相对定价。Spanner 数据库的定价约为可用区永久磁盘的两倍。不过，由于您已经拥有存储在永久磁盘中的三个数据副本，总成本将更高。

在此拓扑中，对于相同数量的应用数据，与传统数据库存储价格相比，Spanner 数据库存储成本大约低三分之一。此外，使用 Spanner，您只需按使用付费，由于不需要预先提供最初不用的空间，这有助于节省成本。不同于传统数据库，如果您要减少数据规模，无需迁移即可实现存储成本的降低。

计算资源的价格对比有点复杂，因为性能取决于您的工作负载。您可以将生产规模的虚拟机中的三路复制的传统 RDBMS 的价格与同等数量的 Spanner 节点进行对比，以了解相对价格。

不过，这种情况不会就此结束。正如您所知道的，管理您自己的数据库的运营成本不可小觑。每项运营任务还会给系统正常运营时间带来更多风险。Spanner 旨在以较低的运营开销提供高水平的服务。

在大多数情况下，Spanner 的运营成本接近零。从一开始，Spanner 便减少了获取和保留数据库备份所需要的运营工作量。Spanner 无需维护时间窗或者按计划的停机。使用 Spanner，根本不需要以人工方式修复损坏或者重建索引。也无需费力为您的数据库增加可用存储。（除非您认为点击按钮来增加实例节点数也算“费力”。）最重要的是：由于 Spanner 自动提供动态数据重新切片和数据复制，因此可以毫不费力（同上所述，除非您认为点击按钮也算“费力”）地实现水平或者垂直缩放。

Enterprise Strategy Group 在其报告 ——《Google Cloud Spanner 关系数据库服务经济效益分析》中对Spanner 的总拥有成本 (TCO) 节省进行了量化分析。他们的研究表明，由于灵活性和创新性增强所带来的 TCO 节省和优势，与其他数据库选项相比，接受调查的每个客户更青睐 Spanner。与本地环境的数据库相比，Spanner 的总拥有成本低 78%，比其他数据库云服务选项低 37%。这种运营工作量的减少使用户能够专注于会使其业务更加成功的其他事项。这是 Spanner 所提供的机会价值。

开始使用

Spanner 具备令人难以置信的强大功能和易操作性。Google 已对 Spanner 进行了“实战测试”，为客户提供这种技术令我们倍感自豪。无论工作负载范围或者规模如何，Spanner 都是您下个项目的理想之选，有充分的理由来支持这种选择。我们在 Google Cloud 内部选择使用 Spanner 来保证 Cloud Storage 中的对象列表，我们的客户（例如，Colopl）做出了相同的选择，选择 Spanner 来帮助其为玩家打造《Dragon Quest Walk》。Spanner 提供熟悉的关系语义和查询语言，并且具有使关系数据库成为数据存储首选的强大灵活性。无论您的应用规模如何，也不论您的业务目标是什么，都有很好的机会让 Spanner 也成为您的明智之选。

了解更多信息

要开始使用 Spanner，创建一个实例或者通过 Spanner Qwiklab 进行试用。

创作场景

为您的下一个项目考虑 Cloud Spanner 的三大原因