CockroachDB with Jordan Lewis
48:53 Share

SQL 数据库的设计目标是数据一致性和垂直扩展性。在单体应用运行在专用单服务器环境的漫长时代里，它们做得非常好。然而，当范式转变为云中的分布式应用时，它们的设计就出现了一个问题。这种转变最终导致了分布式 SQL 数据库的兴起。CockroachDB 就是其中最突出的一个，它使用了受 Google Spanner 启发的分布式架构。

但是，是什么工程方法使得这种架构成为可能呢？Jordan Lewis 是 CockroachDB Cloud 的高级工程总监。他加入节目讨论 CockroachDB 的设计以及它的内部工作原理。本期节目由 Lee Atchison 主持。Lee Atchison 是一位软件架构师。

云计算和应用现代化的作者和思想领袖。他的畅销书《Architecting for Scale》是技术团队在寻求维护高可用性和管理云环境中的风险时的重要资源。

Lee 是他的播客《Modern Digital Business》的主持人，该播客面向希望借助为当今快节奏商业环境开发的现代应用和流程来构建和发展其数字业务的人们。收听地址为 mdb.fm。在 softwarearchitectureinsights.com 关注 Lee，并在 leeatcheson.com 查看他的所有内容。

Jordan Lewis 是 CockroachDB Cloud 的高级工程总监，他也是我今天的嘉宾。Jordan，欢迎来到软件工程日报。你好，很高兴能和你一起参加这个节目。感谢你的到来。那么，是什么让 CockroachDB 与众不同呢？为什么你们能够解决可扩展的分布式 SQL 问题呢？

你知道，不是简单地忽略 SQL。使 CockroachDB 与众不同的原因在于我们为数据库选择的架构，它允许我们采用熟悉的、普通的、传统的 SQL，或者像你说的那样，SQL，并将其分布在一个同构节点集群中。因此，我们可以以对那些可能习惯于使用 DynamoDB 而不是 Oracle 或 Postgres 的人来说更熟悉的方式水平扩展您的数据库。它是如何在幕后工作的呢？这个想法在概念上非常简单，那就是我们将您的数据分割成范围。所以

连续数据块。就像您可能习惯的那样，如果您习惯于使用分片 SQL 系统，您需要手动决定这些分片在数据中的位置，CockroachDB 会自动为您在幕后进行分片计算。并且

抽象掉您可能需要将数据分成分片的事实。它允许您像以前一样使用 SQL。数据库管理决定何时向特定分片请求少量数据或向特定范围请求少量数据，就像我们在 Cockroach 中所说的那样。它决定何时写入 Cockroach 中的特定数据范围，而无需向用户公开这种复杂性。这就是基本思想。

在接下来的过程中，我们将深入探讨它的工作原理。这很好。我想了解更多，但首先，西红柿和西红柿，我

我也经常遇到这场辩论。我相信你也是。它到底是 SQL 还是 SQL？你主要说 SQL。我两种说法都用，但我认为我通常用 SQL。但有时我们会争论一些令人惊奇的事情。没错，没错。我认为对于这一点，我只是在模仿我们创始人的做法。我于 2016 年加入公司，当时每个人都说 SQL，所以它就印在我的脑子里了。我现在就是这样说的。非常有道理，是的。

所以，正如你所知，并且向所有收听节目的听众充分披露，我个人专注于

可扩展性架构。我写了 O'Reilly Media 出版社的《Architecting for Scale》一书。事实上，CockroachDB 是这本书的赞助商。所以我们，我知道 Cockroach 经历的一些事情，你也知道我谈到的一些事情。所以我们的兴趣非常一致。我们都专注于可扩展的架构。但是让我们深入了解一些更重要的细节，了解它是如何工作的。你知道，所以

许多人都尝试过，或者有很多不同的方法，让我们这样说吧，来尝试扩展 SQL 数据库。但它们中的大多数都涉及到对访问数据的方式施加某种限制。您可能正在谈论将单一写入者、多个读取者作为扩展数据解决方案只读部分的一种方式。还有其他解决方案，但是……

您的方法是所有节点都可以同时以可扩展的解决方案服务读取和写入。所以，你知道，例如，您如何同步您的写入以确保您扩展，同时又保持 SQL 所要求的一致性？

这是一个很好的问题。最终，它回到了在架构中使用范围（我们称之为范围）的这个决定。所以分片或范围，它们是同一个概念。假设您是一个购物车应用程序，这是像 CockroachDB 这样的系统的真正优秀且经典的用例。您需要这种一致性。

因为，你知道，你有两个人试图同时结账同一件商品。这可能是一个经典的面试问题。而且你只想确保你只卖其中一件。你不想提交一个交易，说，好吧，用户 A 买到了小部件，用户 B 也买到了小部件，但只有一个小部件。

最终，关键在于您能够同时满足这些一致性要求，并允许该购物车应用程序扩展到数百万用户以及您的应用程序试图服务的每秒数千或数百万个交易。那么它是如何工作的呢？最终，如果您考虑一下作为数据库您可能必须做的事情，您有两个用户正在接触相同购物车数据，您将不得不作为数据库考虑，

您将如何解决该冲突？而您可能有两位用户正在接触两块完全不同的数据，购物车或商店中的不同商品。您不必担心让这两个事务相互通信。那么 CockroachDB 或通常水平可扩展的系统会做什么来允许系统只担心这些冲突呢？这是关于获取数据并

确保潜在冲突的位彼此靠近。因此，在 CockroachDB 的情况下，这意味着您已经选择了一种模式，该模式可能会说，您知道，购物车商品 ID 位于一个表中。您的主键按商品 ID 组织，诸如此类。如果两个人正在接触相同的商品 ID，它最终将由同一台机器在系统内处理。

一旦您进入同一台机器的世界，CockroachDB 实现一致性的方式是使用 Raft。因此，Raft 是最终的事务一致性算法。这是用于在同一范围的副本之间进行仲裁的共识协议。因此，如果您同时接触购物车中的同一商品，两个人同时接触，Raft 将处理仲裁这些冲突的事务。换句话说，您使用……

传统的分片。现在它是自动分片，因此对客户来说是不可见的。但是您使用传统的分片来显着限制范围。

因此，对于两个写入同时到达同一台机器并进行处理来说是合理的。没错。是的，这很好。这工作得很好，你知道，可能可以肯定地说，这可以解决您遇到的大约 99% 的问题。并且 99% 的所有同步问题都可以通过这样的事情来解决。但是有一些事情是无法解决的，你知道，如果你看看，

SQL 允许的完全事务感知。您不能像那样本地化数据并获得完全的事务感知。

那么您是如何处理的呢？您是否允许完全的 SQL 事务？如果是这样，您将如何确保，您知道，一个现在正在接触 40 台不同机器上的 50 个数据片段以及另一个用户在另一台 50 台机器上接触的另一个数据片段的完整事务，以及所有这些是如何协调在一起的？是的。

我喜欢您从微观层面放大到宏观层面的方式。微观层面是 raft 共识，没错。宏观层面是一种传统意义上的两阶段提交事务协议。因此，我们支持您可以向 SQL 抛出的任何类型的交易，这些交易都支持在 CockroachDB 中。如果最终该事务确实需要接触多个共识组或范围，则系统会注意到这一点，插入……

两阶段提交样式的事务记录在它们需要存在的位置，并协调跨越尽可能多的共识组以使事务完成。您写入执行两阶段提交所需的记录、日志记录，然后您最终会收到一个广播事件来执行实际提交。这就是

唯一需要在低于两阶段提交信号（表示提交）的较低级别具有事务性质的事情。是的，没错。我们对这些事务记录或日志事件（无论您称它们为什么）进行分类。我们称它们为事务记录。根据 CockroachDB 的说法，这些记录实际上只是与任何其他数据项一样的数据项。因此，您正在插入此事务记录。对于 CockroachDB 来说，它可能只是另一个用户记录。

但它有一个特殊的位，允许系统知道，您知道，这是我需要去解决两阶段提交或检查它是否已提交的东西。或者有很多有趣的边缘情况。你知道，如果写入者消失了或机器死了怎么办？你知道，所有这些东西是如何清理的？有一个协议。我认为这实际上是我们所做的一件很酷的事情，是系统的这一特定部分。我相信我们已经用一种（忘记它的名字了）协议验证语言进行了验证。是的，协议层，是的。没错。所以这是一件很酷的事情。

事情。酷，酷。所以您完全符合 ACID 规范，对吗？是的，是的，没错。在宏观层面。在宏观层面。我们确实支持一种可序列化级别的隔离，这是我们非常自豪的事情。我们认为，对于大多数开发人员来说，实际上，让所有事务都可序列化比使用较低级别的隔离（例如已提交读取）更容易理解。所以

实际上，多年来，这是 CockroachDB 支持的唯一隔离级别。我会说这是一个不寻常的选择。在早期，我们认为我们将通过确保每个人都使用可序列化的最佳一致性来彻底改变数据库。开发人员将更容易上手。

事实证明，我认为市场让我们意识到，对更松散的隔离级别也有需求。因此，我们将在即将发布的版本中引入已提交读取，我们对此也感到兴奋。酷，酷，很好。我很想知道它是如何工作的以及所有这些是如何组合在一起的。因为我记得我在 AWS 工作时，我没有

不记得那个家伙的名字，也不知道我该怎么说他的名字，但他是一位著名的数据库专家，一位碰巧在 AWS 工作的传统数据库专家。他也在微软和其他地方工作过。他说，可扩展性和 SQL 不兼容，句号。您无法使用符合 SQL 规范的数据库来解决可扩展性问题。他所说的符合 SQL 规范的数据库是指完整的资产，你知道，所有与之相关的一切。

我从不相信他们。因此，我很想看到像 Cockroach 这样的公司证明这实际上是可行的。那么，您对 SQL 或资产合规性做出了哪些妥协呢？有，资产合规性，这不是最好的例子，但是您必须做出哪些妥协才能使这实际上以分布式方式工作呢？

我们不得不做出几种妥协。当然，你提到了延迟。对于任何类型的分布式数据库来说，与单节点数据库延迟竞争都很困难。仅仅是额外的网络跳跃，一致性往返，这肯定会引入不可避免的额外延迟。我认为另一个小

对于我们来说，这是一个有趣的导航问题，它与模式更改有关。因此，许多老式 SQL 数据库除了它们对数据事务的普通 ACID 合规性之外，还提供完全事务性模式更改。

这对我们来说很难提供，因为我们还想提供这种在线模式更改，这是我们的客户非常喜欢的功能。如果您正在处理大规模数据，您有一个在线购物车或游戏应用程序或正在实时全天候运行的财务交易日志，您不希望您的系统因模式更改而中断。您不想让您的应用程序停机。显然，您不能这样做。

多年来，许多人已经为不同的系统提出了解决此问题的变通方法。我们决定将该在线模式更改功能直接构建到模式更改系统中，这很棒。问题是，如果您希望该系统也完全具有事务性，换句话说，您希望能够在编辑行或添加列的同时创建索引，或者同时添加列和编辑枚举。

我们目前无法原子地回滚它。这是一个限制。我们的客户已经向我们表明这可能会造成麻烦。但是

也许有一天我们会找到一种方法来解决这个限制，但就目前而言，这是一种让我想到的限制。这是一个很好的问题，因为我喜欢它的地方在于，你是对的，它确实是标准库存 SQL 的一个限制，它也是一个有价值的功能。另一方面，它也可能让我在这里与一些客户或一些客户发生冲突，但这对于要求这种限制来说是一个糟糕的协议。

在生产系统中。我的意思是，您应该以这样的方式设计模式更改，即影响是一个微小的逐步更改，

您不必事务性地回滚 10 个级别的模式更改和第一个故障迹象。您可以设计模式更改。在几乎所有情况下都可以做到这一点，因此您可以一次少量地非事务性地更改数据库，而无需担心停机时间。在大多数情况下都是可能的，但我知道这会让我与一些人发生冲突。但您对此有何看法？

没错。我认为你是对的。你知道，在 SQL 世界中有很多最佳实践，你真的希望所有客户都能遵循，我想我会这样说。在我加入 Cockroach Labs 的这段时间里，我学到的一件事，我想说的是我作为技术人员的成长，

很长一段时间以来，我一直认为我们可以说服客户正确地去做。也许这是使用正确的模式更改类型，始终使用可序列化，从不创建没有意义的外键。随着时间的推移，我意识到有很多原因

这几乎是一种切斯特顿的围栏式情况。人们使用 SQL 的方式有很多原因，而您没有想到。也许这就是您在 AWS 的朋友所说的，您永远无法使 SQL 扩展，因为人们使用 SQL 的方式有很多种。所有这些都有充分的理由。您可能还没有完全理解它们。

但是人们以非常有创意的方式使用 SQL。我认为作为一个服务提供商，如果您最终认为，啊，如果他们能停止使用存储过程就好了，如果他们只使用可序列化隔离级别就好了，诸如此类的事情，那么您将限制自己，并且无法完成解决客户问题的工作。我认为可以肯定地说，我不知道这是否是一个真实的陈述，但我认为它是。

SQL 可能是最古老的或其中一种仍然广泛使用的编程语言。

因此，它有着悠久的历史，这意味着人们在 SQL 首次出现时就将其用于截然不同的目的。这就是他们学习 SQL 的地方，也是 SQL 的限制和含义被确立的地方。因此，如果您回顾 50 年前 SQL 的使用方法与今天的使用方法，那么您就不会感到惊讶了。

并且有很多数据库的做法与我们今天从头开始构建的方式不同，但它们以非常重要的方式这样做，不仅是因为数据已经存在，必须以这种方式访问，而且还有几十年经验的程序员知道如何以这种方式编程。这就是他们习惯做的事情。并且

我认为 NoSQL 数据库普遍存在的一个问题是，是的，它们可能被引述为“更好”。它们只是与众不同，以至于我们思考构建应用程序的方式必须改变。这对许多公司来说很难做到。你就是做不到。这就是为什么像 Cockroach 这样的东西如此重要，以及为什么我认为完全符合 SQL 标准，这是

模糊的术语对您的业务非常重要。你不能做到 90%。你必须做到 100%。完全正确。千真万确。我们已经了解了关于这个词的很多知识。SQL 合规性到底意味着什么？哪家公司？这可能取决于你问谁而有所不同。

我们是在谈论 Postgres 吗？我们是在谈论 Oracle 吗？我们是在谈论 SQL Server 吗？我认为，作为一个行业，我们还没有找到人们可以遵循的单一标准。我认为我们还没有真正做到这一点。也许有一天。也许 Postgres 将成为标准。这对我个人来说将是一个梦想。是的，不幸的是，可能最终会出现几个标准，对吧？如果历史重演，是的，会有标准，但会有

你知道，这个或那个，而且它将大相径庭。兼容性不会完美。这就像浏览器大战一样。实际上，它已经开始了。我在说什么？好吧，我们谈到了事务，但使 SQL 扩展变得困难的另一件事是连接以及连接的工作方式。你知道，您可以以任何组合以高度复杂的方式（相对而言）有效地将任何东西连接到任何东西的事实，并且，

你是怎么做到的？Cockroach 的架构是如何帮助简化连接，或者使连接变得更难或更具挑战性，或者是什么？您是如何进行连接的呢？

我们借鉴了多年来开发的其他分布式 SQL 系统的许多最佳实践。其中有几个。我认为我花最多时间学习的是 Google 开发的一个名为 F1 的系统。您可以将 F1 系统视为分布式 SQL 数据库或您可以在其上实现连接的任何其他类型的数据库之上的分发层。

因此，在 CockroachDB 内部，SQL 系统具有类似的分层结构。有一个底层的某种

标准执行引擎类型的东西，您可以将其视为在拥有数据的节点上运行的部分。因此，假设我正在执行 distinct 操作、select 操作、过滤操作，甚至是同一系统上两个表之间的连接。您可以认为这些运算符只是在您请求数据的节点上运行。如果您请求执行需要从多个未共址的范围获取数据的连接会发生什么情况？

系统实际上会做什么？您可以想象，您可以发送其中一个运算符。假设它是一个连接运算符，它需要一点表 A 和一点表 B。表 A 位位于您正在运行连接的节点上。但是表 B 位在其他地方。因此，您可以想象该节点可以发送一个 RPC

并开始从另一个表中提取所有数据。节点流式传输所有数据，也许您进行了一点过滤器下推，也许您没有，但无论如何，这可能有点昂贵，因为您必须通过网络发送所有这些数据。因此，F1 的见解是，如果您愿意，您可以实际地在整个集群中分发这些处理运算符。因此，您可以创建一个

哈希连接或合并连接，它由许多小的子哈希连接或合并连接组成，或者是一个由许多小的 distinct 组成的 distinct，或者您知道您正在获取过滤器，并且您要求它们在不同的节点上运行，这实际上是我们的系统所做的，它

类似于这个 F1 的想法。我们称之为 distSQL。这只是一个内部名称。执行 SQL 规划的节点可以创建一个分布式计划，并要求远程节点运行该计划的这些子组件。因此，这与其他分布式 SQL 系统所做的可能不太一样，但这就是我们的系统的工作方式。

酷，酷。所以节点之间有很多聊天。对吗？绝对的。是的。那么，您如何处理如此多的聊天所带来的地理分布呢？或者对于地理分布式节点与本地节点，是否有不同的算法？或者您是如何做到这一点的呢？

那么地理分布，这到底是什么呢？从高层次来看，我认为地理分布的方式是说，我们可以拥有一个分布式 SQL 数据库，它存在于三个彼此之间只有几毫秒距离的数据中心内。或者我们可以决定说，我们需要拥有不仅存在于美国东部，而且存在于美国西部和欧洲的副本。当我们拥有这样的系统时，我们称之为地理分布部分启动。所以

那么我们该如何处理呢？在幕后，如果我们说，好吧，我是 CockroachDB 的用户，我将向您发送所有数据，我不会向您提供有关哪些数据应该存储在何处的太多说明，我认为我们会作为一个系统而苦苦挣扎。正如您所说，会有很多这样的聊天。很多这样的聊天都必须通过跨区域链接进行，这些链接既昂贵又缓慢，等等。

像 Cockroach 这样的系统允许您做的事情，我们选择允许您按区域组织数据的方式，您可以将表配置为按行进行区域划分，这就是我们所说的方式。这意味着

数据库可以查看行的组件，假设它是用户 ID 或区域代码，并且它可以根据您选择的算法来决定该数据是否应该存储在特定区域或另一个特定区域。不仅在该区域，因此它不像传统的分片系统那样，除非您希望它这样做，否则数据只存储在该区域，但默认情况下，它将存储在该系统中并在其他区域中进行复制以实现冗余。

因此，一旦您将所有这些作为基础，我是一个用户，我已经将我的系统配置为在正确的位置按行进行区域划分，那么系统甚至不需要跨区域访问，除非它必须这样做。为任何特定区域提供数据的节点也将在大多数情况下彼此相邻。

当您像这样组织数据时，您不必进行任何跨区域连接。如果您这样做，您会这样做，然后就会有一些聊天，正如您所说。但这就是高层次的想法。这很好。这实际上也有助于持久性，这将是我的其他问题之一，关于冗余节点等等。听起来答案是肯定的，至少在区域之间，也许在其他方面也是如此。

但这也会回到关于事务和事务完整性的问题，以及您是如何处理的呢？当您有两个事务时，一个在欧洲，一个在美国，接触所谓的相同数据，即使它不是相同的节点，因为它们是复制的，您是如何处理这些情况下的事务完整性的呢？是的。

是的，在这些情况下，这将类似于我们之前讨论的内容。将会有两阶段提交。将会有事务记录。最终，如果您试图接触相同的数据位，跨美国、跨欧洲的购物车数据，我们都试图购买相同的商品。这会更慢。不幸的是，真的没有办法避免这种情况。光速，我们公司之前有一句口号，光速是 Cockroach TV 的基本限制。

这非常有道理。而且，你知道，这就是你处理的事情的优点。当您谈到添加诸如地理复制事务之类的功能时，您谈论的是从您永远无法做到这一点转变为您可以做到这一点。因此，您不会，这往往不会成为关于其性能的关键问题。可以理解的是，必须跨越四大洲的事务将比跨越两个事务花费更长的时间。

四毫米晶圆。你知道，这被认为很有道理，但你的选择是，你知道，在这些情况下，酸合规性比性能更重要。因此，您不会破坏完整性。您可能会破坏性能或遭受性能损失，但您不会破坏完整性。总的来说，这是一个好哲学吗？总的来说，我应该说这是 Cockroach DB 哲学的一个很好的描述吗？是的。

我认为这是一个很好的描述。我们将 CockroachDB 视为适合您零层系统记录事务工作负载的数据库。因此，我们谈论的是永远不会不一致的购物车或更多。更好的例子可能是财务系统分类账。这是一个你无法承受系统不一致的系统。所以这是优先级。你知道，如果你在考虑 CAP 定理，它并不完全是 CAP 定理，但是

它是一种类似的想法。如果您想处理某种事务性金融系统，例如，您希望优先考虑 CP，即一致性而不是可用性。因此，让我们回到我们之前简要讨论过的持久性方面，即地理分布。显然，地理分布为您提供了持久性。

您是否还在单个区域内提供持久性选项，您可以在其中复制数据并使其从持久性角度来看基本上看起来像多区域？这是您提供的功能吗？你在摇头，但对于音频来说，这是你做的事情吗？绝对的，是的。因此，我们确实提供了一种可配置的复制因子。

像您在 NoSQL 系统中习惯的那样。因此，您可以决定说，作为用户，我希望在任何地方都有三个副本。这可能是一个默认值。如果您使用的是单区域 CockroachDB，您可以说，啊，我的范围将在某个地方以三种方式复制。

或者您可以说，我希望它是五路复制，因为我对额外的或七路或其他任何东西感兴趣。如果您是多区域的，那么我描述的那些约束，按行区域的那种东西，您可以要求系统做任何事情。它非常可配置。我认为早期，我们发现这种级别的可配置性可能有点

对于大多数用户来说太多了。因此，我们确实提供了一些不错的默认值和一些合理的默认值以及类似的东西，以供大多数人使用。但是，如果您真的想，您可以说，我希望在欧洲有五个副本，在美国有三个副本，或者您对应用程序的需求感兴趣的任何其他组合。是的，这很有道理。很多人谈论数据库的持久性与备份以及持久性作为备份替代的重要性。而且

您对数据库备份与持久性数据库的总体理念是什么？

是的，这是一个深刻的问题。由于复制和跨数据中心复制、跨区域复制提供的额外持久性，我们认为 Cockroach 是一个比标准分布式数据库或标准单节点数据库让您更放心的系统。但对我来说，对我们来说，它根本不会消除灾难恢复、备份的需要

组织以许多不同的方式使用备份。他们将它们用作错误回滚机器。假设有人来删除您的整个数据库。您可以为此使用灾难恢复。

即使，你知道，你的系统已经将这个错误复制到所有数据副本中，或者你的组织可能出于合规性原因需要这个。即使您最终没有使用这些备份，也有很多充分的理由说明为什么法律要求组织进行这些备份，或者您的组织可能会将其用于年度

风险演练？如果您的组织内部存在内部攻击者，导致数据库瘫痪并删除所有副本或类似情况会发生什么？因此，额外的持久性和额外的复制绝不会消除对良好的传统标准备份灾难恢复的需求。或者就此而言，供应商问题。如果您意外删除了记录，无论是客户的错误还是您的错误，如果该记录是

完全且彻底地删除了，您对此无能为力，只有脱机且与系统分离的备份才能解决这个问题，是的，这正是深度防御，我的意思是，我应该提到，测试您的备份，这只是对所有听众的一般建议，请测试备份 1 2 3，是的，是的

那么，让我们更详细地讨论一下分片机制。您说您使用分片作为进行分布的技术，这是一种标准的古老方法，但正如您提到的那样，大多数分片解决方案都是客户管理的。因此，客户必须处理决定分片键，然后处理必须重新分片以及所有这些事情的后果。现在您会自动为客户完成所有这些操作，这太棒了，但是什么

你怎么做到的？您如何决定如何分片，按什么分片，您为客户提供了多少控制权，以及该机制到底是如何工作的？在引擎盖下，您可以考虑

CockroachDB 架构作为另一个分层架构。我一直在谈论 SQL 处理是如何分层的，存储也是如此。您可以将 SQL 系统视为位于类似 Dynamo 的底层巨大键值系统之上。因此，在引擎盖下，该键值系统是您所有数据的巨大有序映射。我们有

决定将 SQL 行转换为键值对的谨慎方案。例如，如果您是一个表，可能是用户，并且您在他们的电子邮件地址上有一个辅助索引，例如，主键是他们的名字、姓氏或其他什么。而且

您有一个 ID，您有一个电子邮件，无论您实际上将拥有该巨大 kv 存储的三个底层键值部分，该存储具有第一个索引、名字姓氏的主索引（顺便说一句，这是一个糟糕的主索引）我刚从嘴里说出来，我的意思是，您有一个用于电子邮件的第二个索引，它们在该键空间中具有某种独立的空间，最终在分片策略方面，我们称它们为范围分片策略，无论默认情况下每个

每个表和每个索引都将在 CockroachDB 中获得自己的小分区。这些默认情况下将都是它们自己的复制组。当这些复制组变得足够大时，并且关于范围大小（以兆字节为单位）存在启发式方法，我现在忘记了数字是多少，

系统将自动将该范围拆分为多个范围。当我们谈论 QPS 时，也会出现类似的启发式方法。特定范围正在获得大量 QPS，正在获得大量流量。系统可能会决定，哦，我将把它拆分以确保系统能够真正维持我们一开始就谈到的那种水平可扩展性。如果您只有一个大型一致性组，那么系统就很难实际扩展它。

所以你实际上是根据定义的 SQL 索引做出分片决策？绝对的，是的。这是一个超级关键的属性。因此，根据您的观点，我认为说，哦，它是完全自动的，并且与用户决策无关，这有点误导。这并不完全正确。用户，您确实有很多能力来改变系统进行分片的方式。记住这些东西非常重要。

您不必太担心诸如，“好吧，我有 128 个分片，我必须将其拆分为 256 个，但我担心 X、Y、Z”。就像我在我的笔记本电脑上经历过那种生活一样。您仍然必须担心诸如您在升序键上有一个索引，例如，您正在执行递增 ID，只是 1、2、3、4、5，

像 Cockroach 这样的系统往往难以应对，因为您很可能一直在写入该索引的末尾。一个系统，除非您能够将该范围的热点区域改组到多个复制组，否则它将无法扩展。因此，您可以使用其他技术来避免这种情况，例如在开头添加哈希或使用 UUID 或任何情况。明白了。这很棒。所以……

让我们更多地谈谈 CockroachDB 的云方法。现在，您专门是 Cockroach Cloud 的工程总监。您既有 Cockroach 的本地版本，也有云版本。谈谈它们的区别。是的，是的，是的，当然。因此，我们目前以三种不同的配置提供 CockroachDB。我们将其作为自托管产品提供。因此，您可以在本地或您自己的云中运行它，并自行管理它。

您可以通过 Cockroach Cloud 购买它。因此，如果您访问 CockroachLabs.Cloud，您可以购买两种类型的 Cockroach 数据库，一种是专用的 Cockroach DB，它只是专用硬件。您可以这样认为。但它具有多区域功能。您可以让它在 Azure 中运行。您可以让它在 Google Cloud 中运行。您可以让它在 Amazon 中运行。

或者您可以将其作为无服务器部署购买。在无服务器中，您使用的是共享硬件，并且您购买的是请求单元，而不是购买诸如已配置容量之类的东西。这对于突发工作负载很有用。它非常适合入门。它也确实非常适合能够拥有您不太可预测的工作负载。我会这样说。因此，这些是我们目前提供 Cockroach 的三种方式。

因此，云中分布式数据库的整个类别一直在急剧增长，对吧？像 DynamoDB 这样的数据库越来越受欢迎。当您谈论 SQL 数据库时，Aurora，对吧？

显然，像 CockroachDB 这样的数据库确实是为云而设计的，因为可扩展性方面。您认为为什么会有如此大的增长？我想，这几乎是一个过于领先的问题，但我还是想问一下。您认为近年来云产品中分布式数据库的增长如此之大的原因是什么？为什么？

您是否认为像 CockroachDB 这样的数据库能够随着需求的增长而满足这些需求？

是的，我认为对分布式数据库需求增长的原因是互联网的增长。人们越来越希望构建互联网规模的应用程序。从我的角度来看，这几乎是默认值。如果您是一家初创公司，您不希望将目标瞄准仅服务于您当地城市的系统或类似系统。您希望它从一开始就是互联网规模的。因此，我认为正因为如此，人们真的期望他们的数据库将

将成为一个随着他们的用户群越来越多的系统而扩展的系统。我认为关于您应该从众所周知的简单技术开始有一些智慧。您应该从真正标准的东西开始。我认为这很好。我认为这确实很有道理

我对我们行业的梦想是，随着时间的推移，分布式系统数据库将成为您首先使用的标准组件，因为它是一个允许您根据最终目标进行扩展的系统，对吧？您可以保持较小的规模，也可以变得非常大，而无需担心在一切都在火上烧着并且您担心跟上需求时进行迁移。

因此，您绝对直接击中了我想用一系列尴尬的问题去的地方。我无法说出来。这实际上是基于这样的概念，我构建了几个系统，你知道，这是基于 SaaS 的应用程序，做啦啦啦啦。我为一些非常成功的公司构建了系统，例如 New Relic 和 AWS 等成功的公司，以及我自己的公司和其他我做过的事情。每次你这样做时，你总是希望这将成长为巨大的东西，这

拯救世界。99% 的时间它不会，它保持较小的规模，一切都很顺利。当您在云中运行小型规模时，任何数据库都可以正常工作。使用什么并不重要，在 EC2 服务器上设置一个 Postgres，就可以了，您不需要比这更多的任何东西。但是，除了 CockroachDB 之外，如果您期望增长，那么问题就出现了，

也许我不应该从一开始就使用 SQL Postgres。也许我应该改用 DynamoDB 之类的东西，它与众不同，非常，你知道，新的学习曲线，所有这些东西，所有将您绑定到 AWS 云或 GCB 云与大表上的限制，无论如何。也许我现在应该这样做，这样当我扩展时，我可以处理扩展，即使现在构建它对我来说更难。是的。

但实际上，Cockroach 允许您做的是说，你知道，忘记规模。真的？你几乎可以说这通常不是一个好建议，但你几乎可以说，不要考虑规模来构建，像你平时一样使用 SQL，并且

因为当您需要扩展并升级到更好更大的东西时，Cockroach 会在那里。从 Postgres 到 Cockroach 的迁移比从 Postgres 到 DynamoDB 的迁移容易得多。是的，这是一个很好的表达方式。我们从小型使用 Cockroach 无服务器的企业中获得了一些不错的成功。而且

他们正在尝试一些事情。他们在开发和测试中。他们进入生产环境。这是一件缓慢的事情。但随后他们取得了一些病毒式传播。在当今的 AI 世界中，我认为这可能是病毒式传播的一个重要原因。你有一个小主意，它很酷。突然间，砰的一声，它登上了 Hacker News。当它出现在 Hacker News 上时，所有试图使用您的应用程序的人是谁？您的数据库会随着您一起扩展，还是会妨碍您？这就是我认为无服务器特别是 CockroachDB 的适用之处。

因此，您甚至可以看到这样的情况：与其从 Postgres 开始，不如从 CockroachDB 无服务器开始，这可能与 Postgres 实例的价格差不多，并在小型规模下这样做，这非常棒。然后，当您迁移到更大的规模时，您根本不必进行任何迁移。随着规模的扩大，您可以从那里发展壮大。您唯一想要继续前进的时候是，如果您需要出于成本原因或其他原因迁移到专用硬件或其他任何东西。是的。

那么，这是一个公平的陈述吗？您真的认为这是一个用例吗？完全正确。我认为这是我们拥有一个很棒的免费入门计划。在无服务器的较低规模下，它相当实惠。从我的角度来看，你知道，如果我预期一个系统，你知道，这就像你之前说的那样，对吧？无论你是谁，你都预期你的创业公司会发展壮大。所以如果是我，那么是的，我绝对希望从第一天开始就使用可扩展的系统，例如 CockroachDB。

您可以轻松地迁移到不同的级别，例如从无服务器平台迁移到基于服务器的平台吗？随着您的发展，您可以轻松地实现这种迁移路径吗？今天，这绝对是我们正在进行的工作中更多的一部分。这是我们团队目前正在努力做的事情。我们实际上刚刚在上周结束了我们的年度计划周，并且

我们明年的一大重点是统一这两种部署模型。你知道，我一直在谈论专用产品和无服务器产品作为不同的产品

真正尝试摘下技术帽，戴上消费者帽。您想要消费的是数据库，无论是无服务器部署还是专用部署，您都不在乎。您想要一个连接字符串。您想要一个控制台来显示哪些是慢速语句。您希望能够进行模式更改。您真的不想担心部署模型。因此，我们的重点将是统一这些部署模型，并为开发人员提供不同层级的 CockroachDB。

无论是零层、高规模生产部署，还是您刚刚开始使用的部署。这就是我们明年的目标。酷，好，好。因此，Cockroach Cloud，您显然拥有一个庞大的基础设施，我相信您和您的团队负责管理它。管理您的数据库即服务实际上就是如此。它是一个数据库即服务，多租户数据库，在一个规模上，在一个服务级别上。

系统应用程序。您在保持该基础设施运行方面面临的最大挑战是什么？

因此，今天，我们必须管理我们支持的所有云中的基础设施。对我个人而言，作为该部门的领导者，最大的挑战只是管理所有基础设施并了解它在哪里运行以及为什么它在花费以及为什么它要花费这么多？这更像是一种云 FinOps 问题，我们遇到了这个问题。

但随着我们成为越来越大的公司，我认为这是我们正在努力解决的问题。你知道，我们在 Azure 中使用了一种部署模型。我们在 AWS 中使用了另一种模型。我们在 GCP 中使用了另一种模型。最终，我的意思是，我了解到所有云都以略微不同的方式做事。有时这很好。有时这不太好。有时他们在某个部门有优势，而在另一个部门有劣势。但无论如何，最终，基础设施在每个云上都略有不同。

对我来说，一个挑战就是，我如何实际管理所有这些成本，以及将成本分摊给使用它们的团队，并管理所有资金？真的，这最近对我来说是一个有趣的挑战。你知道，这引出了我喜欢谈论的魔术词，那就是复杂性，对吧？您如何管理这种复杂性并处理平台与平台之间微小的偏差，这些偏差至关重要，但很难跟踪，因为这里有很多这样的偏差。

那么，您如何处理基础设施中的漂移？显然，您知道，从非常简单的角度来看，您的基础设施是一系列在全球范围内分布的相同节点。这是一个非常简单的观点。

但我认为节点漂移，您可以根据需要定义“节点”一词。这可能是一台计算机。这可能是一个完整的网络。我不知道。这并不是真正重要的部分。但关键是该节点本身的配置。

您如何避免随着时间的推移和距离的增加，所有这些节点的不同部署之间的漂移？是的，我想我将在这里定义的单元，您正在谈论节点。我认为我们在管理我们自己的内部云时考虑的单元实际上是在集群级别。我们使用 Kubernetes 为 CockroachDB Cloud 部署 CockroachDB。因此，我们有各种不同的 Kubernetes 集群。我们拥有所有这些重要但

为了确保多个区域能够正确地相互通信，您需要设置一些棘手的网络内容，或者 VPC 对等互连。我们甚至为我们的客户这样做。因此，如果您希望您的 Cockroach 数据库安全地与您的基础设施通信，而不是通过公共互联网，您必须在 AWS 中设置 PrivateLink 或在 Google 中设置 Private Service Connect。有各种各样的棘手问题。棘手的是，根据客户想要做什么，

我们最终为该客户部署的配置是不同的。因此，在漂移方面，我们面临着这样一个问题，即如何确定每个客户、每个集群的理想状态与实际状态。我们处理这个问题的方法是使用一个名为 Pulumi 的系统，它是一个帮助管理某些内容的系统。我们从我们使用 Pulumi 的方式中获得了相当大的价值。我们有记录

应该部署的内容。我们可以将应该部署的内容的记录与实际部署的内容进行比较，最终得出，是的，某种程度上是一组漂移配置，并以各种不同的方式管理处理它们。我认为我们面临的一个挑战是，我们有时必须对客户进行某种程度的“雪花”处理，可以说是这样。你知道，你正在处理一个需要……

也许您正在为他们部署一些新的东西。例如，您正在为他们进行私人预览，一种不同类型的网络。您正在开发一项新功能。您如何实际告诉管理此漂移的系统，嗯，在这种情况下，它会有点不同？我们有方法可以做到这一点。但最终，正如您和听众所知，您获得的“雪花”集群越多，或者您获得的“雪花”情况越多，在您必须执行诸如升级整个系统或更改每个人的 Kubernetes 版本之类的操作时，您将承受的痛苦就越多。

所有这些都会带来一些有趣的挑战。顺便说一句，我不会说我们已经解决了所有这些问题。这只是我们目前正在经历的一些挑战。是的，我认为这是一个不断变化的目标挑战。是的。但有趣的是，客户这个词进入了对话。

这暗示着对我来说，您可能，特别是对于您的大型客户，即使在您的产品的云产品中，您也是单租户。租户在哪个领域？因此，在一个界面上运行一百个客户的应用程序，

如果为您的 100 个客户中的每一个部署该应用程序的单独实例，则该应用程序的实例是多租户的，在这种情况下是单租户，我们有一个混合，这取决于云，这取决于，我提到了专用和无服务器，当然，在专用中，我们为我们的客户提供单租户模型，他们可以获得专用硬件，而无服务器则可以获得共享硬件，并且

我们使用每种云的方式也影响了这一点。在其中一些云中，我们配置了更多多租户，保持硬件单租户，但基础设施更多是多租户。但这只是一些细节。我会说，总的来说，我们现在同时拥有两者。是的。所以答案是您有一些单租户客户，也有一些多租户客户。是的。

他们越大，您就越倾向于将他们设为单租户。没错。这完全说得通。好。好的，所以我对你的所有问题都问完了。您认为我们应该讨论但尚未讨论的其他任何内容吗？

好问题。可能很多。谈论数据库内容真是太有趣了。这是一个如此丰富而有趣的领域。您可以去一百万个地方。我们还没有全部涵盖。这是一个有效的观点。但我希望我们能做的也许是让您回来，在我们继续前进的过程中讨论一些后续主题。但我真的很喜欢，我只想说，我非常喜欢 CockroachDB 总体上正在

努力实现的目标以及他们正在实现的目标。因此，我非常高兴地关注您正在做的事情并与您保持联系。我很感谢您来到播客。因此，Jordan Lewis 是 CockroachDB Cloud 的高级工程总监，他今天是我的嘉宾。Jordan，非常感谢您与我交谈。这非常有信息量。感谢您来到软件工程日报。非常感谢您的邀请。这是一次非常愉快的谈话。我们今天进行了精彩的对话。

谢谢。