数据库是几乎所有应用程序的关键体系结构组件。在设计应用程序时，总是需要持久地存储应用程序数据。如果不将数据持久化到共享数据库中，则既没有应用程序可伸缩性选项，也没有底层硬件升级选项。更具灾难性的是，如果基础设施出现故障，任何数据都将立即丢失。

但是，有了可靠的数据库，您可以实现应用程序的可扩展性，并确保数据的持久性和一致性、服务可用性，以及改进的系统支持能力。数据库是几乎所有应用程序的关键架构组件。

Google Cloud的panner数据库是为了满足存储Google和我们许多云客户的产品结构化数据的需要而构建的。Panner是谷歌核心基础设施的一部分，值得信赖，哪个云服务器好，可以保护我们的业务，因此您也可以，无论您所在的行业或使用情况。

在Panner之前，我们的产品主要使用分片MySQL来处理需要事务的数据库使用情况。开发工作的目标，如扳手论文中所述，返现卡，是为那些具有复杂的、不断发展的模式的应用程序创建一个数据存储服务，或者那些希望在广域复制中保持强一致性的人。

在考虑panner时首先想到的概念之一是它能够扩展到任意大的数据库大小。Spaner确实支持谷歌应用程序（如Gmail和YouTube），为数十亿用户提供功能，因此可伸缩性必须是一流的功能。

在这篇文章中，我们将探讨Spaner是如何为各种用例中的任何规模（无论大小）的应用程序设计的；它是如何为用户提供低门槛的开发人员入门；以及它如何降低总体拥有成本（TCO）。以下是您需要了解的内容。

从任何地方开始，并随着您的增长而扩展

Panner可以处理大规模的数据量，因此它适用于多种规模的应用程序，而不仅仅是那些大型应用程序。此外，对于需要RDBMS的所有工作负载，在单个数据库引擎上进行标准化可以使您的组织受益。斯潘纳为各种应用提供了坚实的基础，结合了熟悉的关系数据库管理系统（RDBMS）的特点，如ANSI 2011 SQL，DML，商城建站系统，外键和独特功能，如通过TrueTime实现的强大外部一致性和通过本机同步复制实现的高可用性。

我们想花点时间来挑战"较小规模"可能被认为是什么：较小的应用程序并不重要，或者他们没有高远的可用性目标，也不需要事务性的坚忍。这种分类并不表示应用程序的业务关键性比大规模应用程序低。这也不意味着一个给定的应用程序最终不会需要比最初推出时更高的规模。虽然您的应用程序可能只有很小的用户群或事务量可启动，但不应忽视这种可扩展性优势。如果成功会导致未来的数据量或交易量增长，那么使用扳手后端设计的应用程序将不需要重写或任何形式的数据库迁移。

例如，如果你是一家开发下一款酷炫、开创性游戏的游戏公司，如果游戏在发布时获得了巨大成功，你就要做好迎接用户增长的准备无论应用程序的规模如何，大数据能做什么，选择Panner都有很大的好处，包括事务支持、高可用性保证、只读副本和轻松的可扩展性。

事务支持和强大的外部一致性Panner通过TrueTime提供外部一致性保证。扳手使用这个完全冗余的原子钟系统，从一个虚拟的、分布式的全局时钟中获取时间戳。由于在提交时，扳手可以将来自全局一致同意的源的时间戳应用于每个事务，云赚，因此事务提交序列是明确的。外部一致性要求所有事务都按顺序执行。扳手满足这种强一致性保证。

许多应用类型都需要强一致性，特别是那些保持货物或货币数量的应用类型，最终的一致性根本不适合。这包括但不限于供应链管理、零售定价和库存管理，以及银行、交易和分类帐应用程序。

如果您的数据库没有很强的一致性，则必须将交易拆分为单独的操作。如果事务不是原子事务，则意味着该事务可能会部分失败。想象一下，你用一个数字钱包与朋友分摊开支，比如晚餐的费用。如果从您的钱包到他们的钱包的转账没有在一个高度一致的交易中进行，你可能会发现自己的处境是，一半的交易失败了：资金既不在你的钱包里，也不在你朋友的钱包里。

最终一致性的不良特征在于：在数据库操作之后，整个数据库状态立即不一致；只有到最后，这些更改才会反馈给所有请求者。在此期间，不同的客户端请求可能会返回不同的结果。例如，如果你使用社交媒体服务，你可能经历了从按下按钮发布图片到图片显示在时间线上的一段时间。Pokemon GO的创建者Niantic特别选择了Panner，以避免在他们的社交应用程序中出现这种不一致性。