谷歌揭开了它的神秘面纱，发布了新的云扳手数据库服务的公测版本。(图片:谷歌/ Usenix.org)

在过去的18个月里，谷歌已经从一个沉睡的巨人变成了AWS和Azure等云服务的长期挑战者。去年夏天，谷歌推出了其数据平台的关键部分，包括几个SQL和NoSQL数据库。

Hadoop大数据分析:SQL支持能让它走向大众吗?

Actian表示，对于希望在低成本Hadoop集群上运行分析的企业来说，完全兼容的SQL现在可以在大数据平台上运行。

现在，谷歌已经添加了最后一块拼图。值得注意的是，它还没有被AWS或Azure:谷歌云扳手复制。这是一个传奇的谷歌平台，公众只能通过发表的研究论文获得访问权限。它为F1关系数据库提供底层的分布式事务处理平台，为谷歌的收入机器AdWords提供核心支持。

有段时间一直有传言。本周，谷歌发布了新的云扳手数据库服务的公开测试版。它将提供一个全球分布式的基于云的事务数据库，支持SQL并具有很强的一致性，这将使目前市场上的任何其他数据库都具有巨大的规模。它与谷歌在研究论文中描述的扳手数据库相同，但是现在有了可以通过谷歌云平台(GCP)访问的API。虽然谷歌将其用于诸如全球数据库整合之类的用例，但我们认为，在短期内，它最适合被云中的数据打乱的新一代用例，例如全球供应链管理。

云扳手取代了云SQL为更温和的电子商务部署;云Bigtable作为大规模读写的key/value NoSQL数据库;云数据存储作为用户配置文件和在线游戏的文档数据库;数据仓库大查询;以及Hadoop和Spark的云数据处理。在很大程度上，谷歌的数据库组合与亚马逊的AWS和微软的Azure是一致的，但云Spanner是个例外。当然，云扳手的关键问题是它是否适用于不属于谷歌规模的公司。

难对付的人

分布式事务数据库的诀窍是在保持记录一致性(“ACID”的“C”)的同时保持数据库可用性，以平衡相互冲突的需求。通常，当您更新一条记录时，您必须锁定它，以避免同时出现两个(或多个)相互冲突的更新，从而相互抵消和/或破坏数据。

这意味着几件事。首先，分布式数据库最常见的用例涉及到两种操作场景(例如，更新用户配置文件、管理实时游戏交互)，其中ACID需求不是很苛刻，或者分析(分析不会有事务更新的问题)。

其次，事务型数据库平台的出现是为了应对分布式挑战。有Oracle RAC(真正的应用程序集群)，它依赖于涉及集群管理器的多层体系结构。然后出现了一波新sql数据库浪潮，提供了各种保持一致性的方法。最近，切分在NoSQL数据存储(如MongoDB)和SQL事务数据库(如Amazon Aurora和Oracle)中变得流行起来。使用切分，您不一定要将数据库本身分发，而是将表跨存储数组进行分区，以提高跨一个或多个实例的访问和性能。

大的和一致的

Spanner改变了我们对规模的假设，比如事务数据库不能像分析数据库那样增长。虽然我们可能已经厌倦了Hadoop集群运行数千个节点的想法，但Spanner的全球规模是令人难以置信的:它可以运行在数百个数据中心的数百万个节点上，处理数万亿行数据。顺便说一下，它的设计是24/7。

谷歌将Spanner定位为一个完全管理的、任务关键型的关系数据库服务，有5个9s可用性，将提供强大的一致性和全球规模。虽然谷歌在其研究论文中把Spanner称为半关系型数据库，使用类似SQL的查询语言，但其商业产品将主要兼容ANSI SQL 2011。还可以通过Java、Python、Go、Node等语言的客户端库进行访问。将会有一个与第三方BI和数据集成工具集成的JDBC驱动程序。

扳手的起源应该听起来很熟悉:谷歌在MySQL实现耗尽精力时开发了它。当达到数十兆兆字节时，谷歌的工程师不得不手动对数据库进行碎片处理——上一次这样的工作需要几年时间。虽然谷歌也有Bigtable，这是一个后来派生出HBase的NoSQL数据库，但它不是为全局ACID遵从性而设计的。

Spanner通过自动分片和复制来平衡全局数据存储，从而克服了这个障碍。虽然扳手自动放置数据，应用程序可以控制数据的物理位置。这对于数据主权法律要求将数据存储在国家边界内的全球数据库或希望控制数据位置以优化性能的场景非常重要。

与许多分布式事务数据库一样，它使用一种形式的Paxos机制，其中提交是由一个共识决定的，即由哪个节点来领导(有权提交更改的节点)。谷歌声称它的Paxos实现比大多数开源实现都要快。

扳手的秘密武器是谷歌的TrueTime API，这是一个全球挂钟，它的操作非常详细，在这里就不赘述了(扳手的研究论文会告诉你很多)。这就是保持扳手同步的原因。可以这样说，所有提交都加盖了时间戳，一旦系统验证了实际时间，就会应用时间戳。或者，用扳手研究论文的话来说，“API直接暴露了时钟的不确定性……如果不确定性很大，Spanner就会放慢速度等待不确定性的结束。”在这种情况下，慢下来意味着可能有10毫秒左右的延迟。

那么，谁需要所有这些可伸缩性呢?

分布式事务数据库的推动是由互联网推动的——在互联网上，交互是全球性的，客户的期望是持续的正常运行时间。典型的例子包括在线商务或游戏，客户不会容忍延迟，因为数据库需要更新他们的记录。谷歌正在为数据库整合等用例或需要更健壮的事务一致性的NoSQL应用程序推广云扩展器。

一个明显的利基是需要单一一致数据库的全球分布式应用程序。我想到了全球贸易体系;如今，这些系统通常被划分为多个区域实例，具有广域性，接近实时复制。这里还有一个潜在的数据库整合。

但请记住，在转换交易系统时，企业有很多惯性——而且是出于很好的理由。这些系统运行业务的核心，这是您最不想破坏的事情。与分析或操作用例不同，事务系统通常不会创造新的收入机会。事务处理非常复杂，像Oracle、SQL Server或DB2这样的家喻户晓的名称在健壮的引擎背后都有几十年的开发历史。除非被证明无罪，否则对旧秩序的挑战将被视为有罪。例如，在底层，Spanner的架构与SQL数据库稍有不同。谷歌将负责证明Spanner具有企业所期望的完全的SQL兼容性和支持。

作为挑战者，谷歌将在价格上展开竞争。但像甲骨文这样的老牌供应商不会在价格战面前退缩。谷歌带来的真正挑战不会在一夜之间出现。但是，谷歌已经做好了打持久战的准备，Spanner的体系结构非常独特，可以重新定义长期的全球化事务处理。

为了应对气候变化，谷歌完全是绿色的