CockroachDB：权威指南

序言

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

为什么是蟑螂？

欢迎阅读《CockroachDB：权威指南》，感谢您的光临！通过本书，我们希望帮助你学会使用 CockroachDB（专为云计算而构建的分布式 SQL 数据库）构建和部署应用程序。

首先是大家都会问的问题：为什么叫 CockroachDB？

工程学有一个永恒不变的事实，那就是东西会坏。在足够大的范围内，故障无时无刻不在发生。在单台机器上可能一年发生一次的故障，在运行数百个分片时就会变成每天都会发生的故障。希望处理大规模问题的系统必须把容错作为核心责任。这也是谷歌 MapReduce 框架的关键见解之一。通过要求所有计算都在一个相对严格的框架内进行，系统就能在故障发生后自动重新运行必要的工作。

我们认为应该这样：从第一天起，高可用性复制就应该是数据库的默认状态，而不是艰苦配置工作的结果。展望第二天（或第二百天），数据库必须能够与应用程序一起成长，这样才能取得成功，而不是惊慌失措。

当我们从零开始构建关系数据库时，我们希望为现代云应用带来一致性、本地弹性、数据本地性和大规模。我们的愿景是建立一个能够在公共云上占用任何资源的系统，然后坚持不懈地进行自我优化。数据库将利用可用空间，在一组协调的全球分布式节点上达到平衡，这样它不仅可以整合新资源，而且如果一台机器或数据中心甚至整个区域瘫痪，数据库也能简单地平衡剩余的可用资源。

我们的目标是建立一个在全球无处不在、无法根除的数据库......就像periplaneta brunnea，一种讨厌的普通蟑螂。于是，CockroachDB 应运而生。

构建 CockroachDB

CockroachDB 的起源是一个必要的故事。确切地说，斯宾塞-金博尔、彼得-马蒂斯和我，本-达内尔，开始建立我们自己需要的关系数据库。

在 Go 共事之后，我们三人曾一度分道扬镳。最后，我们（还有斯宾塞的弟弟、微软 SQL Server 资深专家安迪）又一起回到了一家名为 Viewfinder 的初创公司，创建了一个用于照片整理和社交分享的应用程序。当然，我们希望它能取得成功，因此我们希望建立一个规模。毕竟，正如斯宾塞所说："有时会发生糟糕的事情。而在规模化的过程中，糟糕的事情总是会发生"。

事实证明，从该项目的历史来看，我们做得不够好，不需要大规模的可扩展性，但我们想从一开始就做好计划。我们也不想把自己锁定在单体数据库、MySQL 分片或类似的东西上。我们以前走过这条路，知道它不会通向我们想去的地方。因此，我们将 NoSQL 作为最佳选择，最终选定了 DynamoDB。

DynamoDB 符合很多条件：可扩展、速度快、可预测。它与 Bigtable 非常相似，我在谷歌工作时曾用 Bigtable 作为 Google Reader 的后台。因此，至少从纸面上看，我们非常喜欢这种模式。但随着使用经验的积累，我们意识到 NoSQL 存在一些基本问题。

最大的问题是，我们发现我们真的需要二级索引。Bigtable/DynamoDB 模型实际上只有主键，没有二级索引的概念。为了获得二级索引，我们不得不在 DynamoDB 的基础上构建自己的事务部分实现，但这是可行的。然而，一旦我们使用了这个系统，我们就发现了一个后续问题。DynamoDB 本身速度非常快、可预测、可扩展，但一旦你开始做结合多条记录的事情，就像我们使用二级索引所做的那样，事情就变得困难了。

最终，我们想出了一个行之有效的系统，但在 DynamoDB ...