随着时间的推移变得越来越复杂和越来越苛刻。Google的Spanner是有史以来最复杂，最灵活，最具扩展性的数据库之一，它催生了一个名为CockroachDB的克隆产品，后者也在企业中引起关注，并且正在公共云上与Google的Cloud Spanner服务竞争。目前还与基于Hadoop堆栈之上很多SQL数据库竞争。
在数据库世界中，这仍是一个激动人心的时刻。
回顾
Andrew Fikes：让我稍微回顾一下我们如何发展打破这一步。我已经在谷歌待了很长时间 - 现在差不多18年了 - 随着时间的推移，我已经能够观察到谷歌本身已经成长。当你看看谷歌创建的所有系统时，首先要注意的是加入公司的初始工程师是我称之为主要的分布式系统工程师。他们有系统工程背景，而不是数据库背景。
因此，当我们进入数据存储时，其中很多都是从系统角度出发的，而且总是在考虑特定目标的情况下完成。当我们出去构建BigTable时，我们的第一个用例是存储Web。这是在白板上绘制的一个非常简单的事情：URL是关键，对于每个URL，我们想要存储文档内容，我们希望能够使用PageRank等内容来注释这些文档内容。当时这些都是非常简单的事情，它推动了我们需要一些可以扩展的东西的想法。
当时有趣的是，大多数这些物品本身都是独立的，你可以想象一排机器。这是MapReduce出台处理这个大型数据集的时间。但随着时间的推移，谷歌本身已经改变。我们已经从搜索业务转变为广告业务，从地理业务转变为应用业务。在Spanner的背景下，当我们在意识到BigTable还不够之后首次开始研究问题时 ，这个时机通常是在人们试图构建应用程序的环境时发生的。
有几个不同的问题。您正在尝试解决水平分区 - 能够占用行空间的一部分并将它们放置在世界的不同部分。这是您今天在Cloud Spanner中使用此多区域功能所看到的功能之一。我们也开始发现构建在这些数据库和数据存储之上的应用程序逻辑比使用最终一致性合理化的程序要复杂得多。我们经历了这段时间，聪明的人们试图帮助应用程序人员在最终一致的系统BigTable之上构建东西，并意识到我们需要更多。
这帮助我们彻底解决了一大堆教条。那个时候，我非常相信最终的一致性。我非常相信事务不是我们在分布式系统中应该拥有的东西。当我们真正尝试使用这些系统时，我们开始意识到这种一致性是我们实际需要的力量。有趣的是，Spanner带领我们踏上了一个让我们的分布式系统越来越接近数据库的旅程。因此，我们开始对数据库文化以及知识和经验进行一些介绍。
例如，我们Google并不是强烈的SQL信徒。现在我很高兴有类型键，而SQL已成为Google内部用于访问数据的通用语言，我们看到它越来越多地渗透到我们的系统中。当我们向我们的兄弟们添加SQL时，我们在广告中添加了F1团队，我们将整个业务关键数据库（在MySQL中）移植到了Spanner，我们与他们合作构建了一个SQL引擎。您已经看到我们更进一步，重新检查堆栈的所有部分，以便更好地理解如何实现SQL。
SQL
当我们开始在Spanner中实现SQL时，我作为系统人员出现了，我想，有一个SQL标准，对吧？很明显我们应该做的是我们应该实现SQL标准，我们将能够来回沟通。这对我来说这是一个明确的学习时刻。我花了好几个小时在大型PDF文档面前，抓住了SQL的指定方式，然后启动了不同的数据库引擎来了解每个人的行为方式。
这是在Spanner和BigQuery中使用的SQL语言内部产生的。在Google中，我们现在拥有一种标准化的单一SQL语言，它具有通用的表达式评估，常见的代数，类型和类型的东西。因此，我们的第一个目标是使用这种通用语言整合Google中使用的所有不同的SQL方言，这就是我们能够为云带来的。
你知道所有语言都是某种意义上的环境的结果。这个人长大了，因为谷歌在内部使用 protocol buffers，这是我们外化的数据格式。因此，很多打字和其他类型的东西都可以与它结合得很好。您会发现类型集更类似于一组类型和协议缓冲区，您可以在BigQuery和Spanner中看到这些类型。但总的来说，我们非常努力地查看其他引擎，了解它们的行为，试图与当时谷歌中最常用的引擎 - 例如MySQL - 更兼容 - 并且真的让它变得如此没有任何惊喜。有一些事情，比如对阵列的更自然的支持。
为什么我们从最终的一致性到强烈的一致性做出了重大转变？为什么我们要从无类型数据转换为类型化数据？SQL在哪里发挥作用？这些更改是为了给开发人员提供更好的工具。让他们重新开始工作。我认为我们必须弄清楚如何将基础设施讨论带到现场位置，并弄清楚如何创建这些环境并使其运行良好。
最终的一致性是否已经死亡
我经过多年思考后得到的比喻，就是你编写代码时经常用最直线写的代码。你的目标是弄清楚如何从A到B.然后你运行该代码很多次，你发现一个特定的方法或特定的部分是值得优化的。这就是我认为最终一致性所属的地方，在那种优化阶段。
如果您有非常具体的用例，则可以实现最终的一致性。
高可用性集群就是这样。您可以执行异步或同步复制，有时它必须是同步的，有时异步很好。我会在一个数据中心或区域内本地使用同步复制，当跨越区域或地理位置时，使用异步。
我们构建了一个BigTable，我们没有事务。那里有一个分裂和合并协议。我们所有人 - 你知道我们所有的惊人背景 - 可能写了五次。我们写了五次，因为无论我们处理这些事务多少次，并且认为我们知道我们在做什么，实际上仍然会产生错误。我们已经完成了所有工作。但是，在Spanner中发生的事情之一是，通过构建一个强大的原语，即事务，然后构建事物，我们构建更复杂的应用程序和更复杂的分布式系统的能力增加了。因此，事务中的强一致性可以成为您产生更多有趣事物的能力的真正倍增。
Spanner不能运行的应用程序？
我们在OLTP和OLAP之间有这种混合，正如你所说，我们仍然在问：是否有一个数据库可以统治它们？我们就这样来回走动。我认为从效率的角度来看，纯OLAP工作负载在BigQuery这样的东西上做得更好，BigQuery已经为它们设计了更多功能。你确实看到外部数据库之类的东西，它们利用一些技巧来混合它们中的两个。但在谷歌内部，我们已经看到了对于Spanner的全面采用，从大到小，从昂贵到不贵到SQL，再到点查询。我们已经工作了很长一段时间，填补了不同工作负载中出现的所有差距。
BigTable和Spanner之间的容量，性能，延迟是否存在规模差异？
构建BigTable的人们开始构建Spanner，因此有些部分非常相似。BigTable在支持我与您交谈的状态索引工作负载方面有更长的记录，因此它对频谱中的大数据进行了一些优化。但在谷歌，随着Spanner的聚焦在内部使用开发，你知道差距继续缩小。
Google搜索引擎是运行在在BigTable和Spanner混合上
或Spanner只是运行搜索引擎的控制面板？ 更大的搜索引擎是一台大型机器，我曾经理解，但是现在已经无法理解其中的部分内容。且我认为正确的说法是，今天这台大机器的很多很多部分都是两者兼而有之。