CockroachDB 是一个分布式、事务性、关系型、云原生的 SQL 数据库系统。听起来很复杂吧！但简而言之，CockroachDB 结合了上一代关系型数据库系统的优点——强一致性、SQL 的强大功能以及关系数据模型——以及现代分布式云计算原则的优势。其结果是一个与其他基于 SQL 的事务性数据库高度兼容的数据库系统，同时提供了更高的可扩展性和可用性。
在本章中，我们将回顾数据库管理系统（DBMS）的历史，探讨 CockroachDB 如何利用过去几十年的技术进步，来实现其宏伟目标。
数据库简史
数据存储和数据处理是人类文明的“杀手级应用”。口头语言赋予了我们在群体合作中的巨大优势。然而，真正使每一代人能够在前人经验的基础上不断进步的，是我们发展出了数据存储技术——例如书面语言。
最早的书面记录——距今近10,000年——是农业账务记录。这些楔形文字记录，刻在泥板上（见图1-1），与现代会计系统中支持数据存储的数据库具有相同的功能。
几千年来，信息存储技术的进步是缓慢的。便宜、便于携带且相对耐用的纸质媒介的使用，并将其组织在图书馆和文件柜中，几乎代表了长达千年的最佳实践。
数字数据处理的出现真正引发了一场信息革命。在一个人的生命周期内，数字信息系统使信息存储的体量和速率呈指数级增长。今天，绝大多数人类信息以数字格式存储，其中大部分存储在数据库系统中。
关系型数据库之前的时代
最早的数字计算机存储能力微不足道，主要用于计算任务——例如生成弹道表、解密代码和执行科学计算。然而，随着磁带和磁盘在1950年代成为主流，计算机开始能够存储和处理大量信息，这些信息若通过其他方式处理则显得不堪重负。
早期的应用程序使用简单的平面文件进行数据存储。但很快就显现出，可靠且高效地处理大量数据的复杂性需要专门的、专用的软件平台——这些平台成为了最早的数据系统。
早期的数据库系统运行在单体的大型主机上，这些主机也负责应用程序代码的运行。应用程序与数据库系统紧密耦合，直接使用过程语言指令处理数据。到了1970年代，数据库系统的两种模型——网络模型和层次模型——开始争夺主导地位。这些模型分别由当时的主要数据库代表，IMS（信息管理系统）和IDMS（集成数据库管理系统）所体现。
这些系统在其前辈的基础上取得了重大进展，但也存在显著缺点。查询必须在实现之前就被预设，而且只支持逐条记录处理。即使是最简单的报告也需要程序员资源来实现，所有IT部门都面临着大量报告请求的积压。
关系模型
或许没有人比埃德加·科德（Edgar Codd）对数据库技术的影响更大（无论拉里·埃里森怎么看）。科德是一个“编程数学家”——今天我们可能称之为数据科学家——自1949年以来，他一直在IBM工作。1970年，科德写下了他的开创性论文《大型共享数据银行的关系数据模型》。这篇论文概述了科德所认为的现有数据库系统设计中的根本问题：
现有的数据库系统将数据的物理表示和逻辑表示混合在一起，这种做法常常使得数据请求变得复杂，并且导致无法满足那些在数据库设计时未被预见到的请求。 没有正式的数据表示标准——作为一名数学家，科德熟悉用于表示数据的理论模型——他认为这些原则应该应用于数据库系统。 现有的数据库系统太难使用。只有程序员才能从这些系统中检索数据，而且数据检索过程不必要地复杂。科德认为，应该有一种简便的方法来进行数据检索。 科德的关系模型描述了一种逻辑上表示数据的方式，独立于底层存储机制。它需要一种查询语言，用于回答任何可以通过数据满足的问题。
关系模型定义了关系数据库的基本构建块：
- 元组是一组属性值。属性是命名的标量（单维）值。元组可以被视为一个“记录”或“行”。
- 关系是一组相同形式的不同元组的集合。关系代表一个二维数据集，具有固定数量的属性和任意数量的元组——数据库中的表就是一个关系的例子。
- 约束强制一致性并定义元组之间的关系。
- 定义了各种操作，如连接、投影和并集。关系上的操作始终返回关系。例如，当你连接两个关系时，结果本身就是一个关系。
- 键由一个或多个属性组成，这些属性可以用来标识一个元组。一个关系可以有多个键，并且一个键可以由多个属性组成。
关系模型进一步定义了一系列“范式”，表示模型中冗余程度的降低。一个关系如果符合第三范式，意味着每个元组中的所有数据都依赖于该元组的整个主键，而不依赖于其他任何属性。我们通常通过一句话来记住这一点：“关键字，整个关键字，除了关键字什么都没有（愿科德保佑）。”
第三范式通常代表构建高效和高性能数据模型的起点。我们将在第五章回到第三范式。图1-2展示了第三范式中的数据。
实现关系模型
关系模型为今天所有关系数据库中熟悉的结构奠定了基础。元组被表示为行，关系被表示为表。
表是已给予物理存储的关系。底层存储可能采用不同的形式。除了数据的物理表示外，还引入了索引和聚簇存储方案，以促进高效的数据处理并实现约束。
索引和聚簇存储不是关系模型的一部分，但它们被纳入关系数据库中，旨在通过透明地增强查询性能，而不改变可以执行的查询类型。因此，呈现给应用程序的数据的逻辑表示是独立于底层物理模型的。
事实上，在某些关系型实现中，表可能由多个索引结构实现，允许通过不同的访问路径访问数据。
事务
事务是一个逻辑上的工作单元，必须作为一个整体成功或失败。事务早于关系模型出现，但在前关系型系统中，事务通常由应用层负责。在科德的关系模型中，数据库承担了事务处理的正式责任。在科德的定义中，关系型系统将提供明确的支持，用于启动一个事务，并对该事务进行提交或回滚。
使用事务来维护应用程序数据的一致性，也被用来在多个表示表的物理结构之间维护一致性。例如，当一个表由多个索引表示时，所有这些索引必须通过事务性方式保持同步。
科德的关系模型并未定义所有事务行为的方面，这些方面后来成为大多数关系数据库系统的常见特性。1981年，吉姆·格雷（Jim Gray）阐述了我们今天仍在使用的事务处理核心原则。这些原则后来被称为ACID——原子性、一致性、隔离性和持久性事务。
正如格雷所说：“事务是一个状态的转变，具有原子性（全有或全无）、持久性（效果在故障后仍然存在）和一致性（一个正确的转变）属性。” 隔离性原则——后来在修订版中加入——要求一个事务不能看到其他正在进行的事务的效果。
事务之间的完全隔离——可串行化隔离——对并发数据处理设置了一些限制。许多数据库采用了较低级别的隔离，或者允许应用程序从多种隔离级别中选择。关于这一点的更多讨论将在第二章中进行。
SQL语言
科德规定，关系型系统应支持一种“数据库子语言”，用于导航和修改关系数据。他在1971年提出了Alpha语言，这对Ingers的QUEL语言产生了影响——Ingres是一个早期的关系数据库系统，最初在加利福尼亚大学开发，后来对开源PostgreSQL数据库产生了影响。
与此同时，IBM的研究人员正在开发基于科德关系模型的原型数据库管理系统System R。他们为该项目开发了SEQUEL语言作为数据子语言。SEQUEL最终被重命名为SQL，并在IBM的商业数据库中使用，包括IBM DB2。
甲骨文（Oracle）选择SQL作为其开创性Oracle关系数据库管理系统（RDBMS）的查询语言，并且到了1970年代末，SQL战胜了QUEL成为关系查询语言，并于1986年成为ANSI（美国国家标准协会）标准语言。
SQL几乎不需要介绍。今天，它是全球最广泛使用的计算机语言之一。我们将在第四章专门讨论CockroachDB SQL的实现。然而，值得注意的是，SQL所提供的相对易用性显著扩大了数据库用户的受众。人们不再需要成为经验丰富的数据库程序员才能从数据库中检索数据——SQL可以教授给数据库的普通用户，如分析师和统计学家。可以公平地说，SQL使得数据库进入了业务用户的视野。
RDBMS的霸主地位
关系模型、SQL语言和ACID事务的结合成为1980年代初到2000年代初期新数据库系统的主导模型。这些系统通常被称为关系数据库管理系统（RDBMS）。
RDBMS的流行恰逢应用架构发生重大范式转变的时期。大型主机应用程序的世界正在让位于客户端/服务器模型。在客户端/服务器模型中，应用程序代码运行在微型计算机（个人计算机）上，而数据库运行在一台迷你计算机上，越来越多地使用Unix操作系统。在客户端/服务器迁移过程中，基于主机的前关系型数据库大多被遗弃，转而采用新的RDBMS。
到20世纪末，RDBMS已经占据了主导地位。当时领先的商业数据库——Oracle、Sybase、SQL Server、Informix和DB2——在性能、功能或价格上竞争，但它们几乎在采用关系模型、SQL和ACID事务方面完全相同。随着开源软件的普及，开源RDBMS如MySQL和PostgreSQL获得了显著并不断增长的市场份额。
互联网的到来
在21世纪初，应用架构发生了一个更为重要的转变。这个转变，当然就是互联网的出现。最初，互联网应用运行在一个与客户端/服务器应用类似的软件栈上。一个大型服务器托管着应用的数据库，而应用代码则运行在“中间层”服务器上，最终用户通过网页浏览器与应用交互。
在互联网初期，这种架构足够应付——尽管通常只是勉强够用。单体数据库服务器常常成为性能瓶颈，虽然通常会部署备用数据库，但数据库故障仍然是应用故障最常见的原因之一。
随着互联网的增长，集中式RDBMS的局限性变得不可持续。新兴的“Web 2.0”社交网络和电子商务网站有两个特征，越来越难以支持：
- 这些系统具有全球或近乎全球的规模。多个大洲的用户需要同时访问应用。
- 任何级别的停机都是不可接受的。“周末升级”这种旧模式不再可行。没有任何维护窗口不会造成显著的业务中断。
所有人都一致认为，如果要满足新型互联网应用的需求，单体单一数据库系统必须让位。人们认识到，存在一个非常重要且可能无法克服的障碍：CAP定理。CAP——或布鲁尔定理——表明，在分布式系统中，最多只能同时拥有以下三种期望特性中的两种（如图1-3所示）：
- 一致性
每个用户看到相同的数据库状态视图。 - 可用性
数据库保持可用，除非分布式系统的所有元素都失败。 - 分区容错性
系统运行在一个可能发生网络分区的环境中，如果网络中的两个节点无法通信，具有分区容错性的系统将继续运行，尽管在节点之间的网络消息可能会丢失（或延迟）。
例如，考虑一个拥有北美和欧洲用户的全球电子商务系统。如果两个大洲之间的网络发生故障（即网络分区），则必须选择以下其中一个结果：
- 欧洲和北美的用户可能会看到不同版本的数据库：牺牲一致性。
- 其中一个区域需要关闭（或变为只读模式）：牺牲可用性。
当时的集群式RDBMS通常会牺牲可用性。例如，在Oracle的Real Application Clusters (RAC)集群数据库中，节点之间的网络分区会导致某一分区中的所有节点关闭。
然而，像Amazon这样的互联网先驱认为，可用性比严格一致性更为重要。Amazon开发了一种名为Dynamo的数据库系统，实现了“最终一致性”。在发生分区时，所有区域仍然可以访问系统，但当分区解决后，不一致的情况将被调解——可能在此过程中会丢失数据。
NoSQL运动
2008年至2010年间，出现了数十种新数据库系统，所有这些系统都放弃了RDBMS的三大支柱：关系数据模型、SQL语言和ACID事务。例如，Cassandra、Riak、Project Voldemort和HBase等新系统，直接受到Amazon和Google开发的非关系技术的影响。
这些系统中的许多本质上是“无模式的”——支持甚至要求数据没有特定的结构。特别是在键值（KV）数据库中，一个任意的键提供了对任意结构“值”的程序化访问。数据库对于这个值的内容一无所知。在数据库的视角下，值仅仅是一组无结构的位。其他非关系系统将数据表示为半表格式或JSON（JavaScript对象表示法）文档。然而，这些新数据库并未实现关系模型的原则。
这些系统最初被称为分布式非关系数据库管理系统（DNRDBMSs），但由于它们不包含SQL语言，很快便被更有吸引力的术语“NoSQL”数据库所取代。
NoSQL一直是一个值得质疑的术语。它定义的是这些系统所丢弃的内容，而非它们的独特特征。尽管如此，“NoSQL”仍然被采用，在接下来的十年中，Cassandra、DynamoDB和MongoDB等NoSQL数据库逐渐成为数据库领域的一个独立且重要的部分。
分布式SQL的出现
实施分布式事务在网络规模上的挑战，导致了现代数据库管理系统的分裂。随着全球应用程序的崛起，以及对高可用性的极高要求，牺牲可用性以追求完美一致性变得不可想象。几乎在同一时间，Amazon、Google和Facebook等领先的Web 2.0公司推出了新的数据库服务，这些服务仅仅是“最终一致”或“弱一致”，但在全球范围内高度可用，开源社区也根据这些原则响应，开发了相关数据库。
然而，NoSQL数据库也有其严重的局限性。SQL语言被广泛理解，并且几乎是所有商业智能工具的基础。NoSQL数据库发现它们必须提供一定的SQL兼容性，因此许多加入了某种类似SQL的方言——这导致了NoSQL被重新定义为“不仅仅是SQL”。在许多情况下，这些SQL实现只是查询功能，旨在支持商业智能功能。在其他情况下，SQL类似语言支持事务处理，但仅提供SQL功能的最有限子集。
由于一致性较弱所带来的问题更难以忽视。数据的一致性和正确性在许多关键应用中是不可妥协的。例如，在社交媒体中，允许不同用户看到相同话题的略微不同的视图可能是可以接受的，但在物流等其他场景中，任何不一致都是不可接受的。高级的非关系数据库采用了可调一致性和复杂的冲突解决算法来缓解数据不一致问题。然而，任何放弃严格一致性的数据库都必须接受在网络分区的调解或竞争事务的模糊时序中丢失或损坏数据的场景。
Google在许多重要的开源NoSQL系统背后开发了许多技术。例如，Google文件系统和MapReduce技术直接导致了Apache Hadoop，而Google Bigtable则促成了Apache HBase。因此，Google深知这些新数据存储的局限性。
Spanner项目的启动
Spanner项目的启动旨在构建一个分布式数据库，类似于Google现有的Bigtable系统，但能够同时支持强一致性和高可用性。
Spanner得益于Google高度冗余的网络，这减少了基于网络的可用性问题的概率，但Spanner真正创新的特性是其TrueTime系统。TrueTime明确模拟了分布式系统中时间测量的不确定性，以便将其融入事务协议中。分布式数据库会费尽心思从系统中的副本中返回一致的信息。锁是防止在数据库中创建不一致信息的主要机制，而快照则是返回一致信息的主要机制。查询不会看到在执行期间发生的数据变化，因为它们读取的是一致的数据“快照”。在分布式数据库中维持快照可能会很棘手：通常需要大量的节点间通信，以达成事务和查询的排序一致性。TrueTime提供的时钟信息使得节点之间的通信最小化，从而可以使用快照。
Google Spanner进一步优化了快照机制，通过在每个数据中心安装GPS接收器和原子钟来实现。GPS提供了外部验证的时间戳，而原子钟则提供了在GPS“修正”之间的高精度时间。结果是，全球每个Spanner服务器几乎拥有相同的时钟时间。这使得Spanner能够精确地排序事务和查询，而无需过多的节点间通信或因时钟不确定性过大而导致的延迟。
注意
Spanner高度依赖Google的冗余网络和专用服务器硬件。Spanner无法独立于Google网络运行。
Spanner的初始版本推动了CAP定理的边界，尽可能在技术允许的范围内。它代表了一个分布式数据库系统，其中一致性得到保证，可用性最大化，网络分区尽量避免。随着时间的推移，Google向Spanner的数据模型中添加了关系特性，并且支持SQL语言。到2017年，Spanner已经发展为一个支持RDBMS三大支柱（SQL语言、关系数据模型和ACID事务）的分布式数据库。
CockroachDB的出现
通过Spanner，Google有力地展示了高度一致的分布式数据库的实用性。然而，Spanner紧密依赖于Google Cloud Platform（GCP），并且——至少最初——并未公开提供。
显然，Spanner所开创的技术需要更广泛地被使用。2015年，三位Google前员工——Spencer Kimball、Peter Mattis和Ben Darnell——成立了Cockroach Labs，旨在创建一个开源、地理可扩展、符合ACID规范的数据库。
Spencer、Peter和Ben选择了“CockroachDB”这个名字，向坚韧不拔的蟑螂致敬，因为据说蟑螂的生存能力如此强大，即便是核战争也难以摧毁它（如图1-4所示）。
CockroachDB设计目标
CockroachDB的设计旨在支持以下属性：
可扩展性
CockroachDB的分布式架构允许随着工作负载的增加或减少，集群无缝扩展。可以向集群中添加节点，而无需手动重新平衡，并且随着节点数量的增加，性能会按预测方式扩展。
高可用性
CockroachDB集群没有单点故障。即使节点、区域或地区发生故障，CockroachDB仍能继续运行，且不会影响可用性。
一致性
CockroachDB提供最高级别的事务隔离和一致性。事务独立操作，一旦提交，事务将保证持久性，并对所有会话可见。
性能
CockroachDB的架构旨在支持低延迟和高吞吐量的事务型工作负载。为了优化数据库性能，已尽一切努力采用数据库最佳实践，涉及索引、缓存及其他数据库优化策略。
地理分区
CockroachDB允许数据在特定的地理位置物理存储，以提升“本地化”应用的性能，并满足数据主权要求。
SQL兼容性
CockroachDB实现了ANSI标准的SQL，并且与PostgreSQL的网络协议兼容。这意味着大多数与PostgreSQL兼容的数据库驱动程序和框架也可以与CockroachDB一起使用。许多PostgreSQL应用程序可以迁移到CockroachDB，而不需要进行大量代码更改。
可移植性
CockroachDB提供完全托管的数据库服务，在许多情况下，这是最简单且最具成本效益的部署方式。但它也能够在几乎任何平台上运行，从开发者的笔记本电脑到大型云部署。CockroachDB架构与容器化部署选项（特别是与Kubernetes）高度兼容。CockroachDB提供了一个Kubernetes操作员，简化了Kubernetes部署的复杂性。
你可能会想，“这个东西什么都能做！”然而，值得指出的是，CockroachDB并不是为了满足所有人而设计的。特别是：
CockroachDB优先考虑一致性而非可用性。
我们之前看到，CAP定理表明，当遇到网络分区时，必须在一致性和可用性之间做出选择。与像DynamoDB或Cassandra这样的“最终一致”数据库不同，CockroachDB在任何情况下都保证一致性。这意味着，在某些情况下，如果CockroachDB节点与其他节点断开连接，它会拒绝服务请求。类似情况下，Cassandra节点可能会接受请求，即使数据请求中的数据最终可能需要被丢弃。
CockroachDB架构优先考虑事务型工作负载。
CockroachDB包括用于执行聚合的SQL构造以及SQL 2003中的分析“窗口”函数，并且CockroachDB当然可以与流行的商业智能工具（如Tableau）集成。没有具体的原因说明CockroachDB不能用于分析应用程序。然而，CockroachDB的独特功能更多地面向事务型工作负载。对于不需要事务的纯分析工作负载，其他数据库平台可能提供更好的性能。
重要的是要记住，虽然CockroachDB受到Spanner的启发，但它绝不是“Spanner克隆”。CockroachDB团队借鉴了Spanner团队的许多概念，但在多个重要方面与Spanner有所不同。
首先，Spanner是为运行在非常特定的硬件上而设计的。Spanner节点可以访问原子时钟和GPS设备，从而实现非常精确的时间戳。CockroachDB则被设计为能够在商品硬件和容器化环境（如Kubernetes）中良好运行，因此不能依赖原子时钟同步。正如我们在第2章中所见，CockroachDB确实依赖于节点之间良好的时钟同步，但对时钟偏移的容忍度远高于Spanner；因此，CockroachDB可以在任何地方运行，包括任何云提供商或本地数据中心（并且一个CockroachDB集群甚至可以跨多个云环境部署）。
其次，虽然CockroachDB的分布式存储引擎受到Spanner的启发，但其SQL引擎和API设计为与PostgreSQL兼容。PostgreSQL是目前最广泛实施的关系型数据库管理系统之一，并且得到了丰富的驱动程序和框架生态系统的支持。CockroachDB的“网络协议”与PostgreSQL完全兼容，这意味着任何与PostgreSQL兼容的驱动程序都能与CockroachDB一起使用。在SQL语言层面，由于底层存储和事务模型的差异，CockroachDB和PostgreSQL之间总会存在一些区别。然而，大多数常用的SQL语法在这两个数据库之间是共享的。
第三，CockroachDB已经发展成为满足其社区需求的数据库平台，并引入了许多Spanner项目未曾设想的功能。今天，CockroachDB是一个蓬勃发展的数据库平台，与Spanner的关系仅仅是历史上的兴趣。
CockroachDB 发布版本
CockroachDB 的第一个生产版本于 2017 年 5 月发布。这个版本引入了分布式事务 SQL 数据库的核心功能，尽管在性能和规模上存在一些限制。2018 年发布的 2.0 版本包括了面向地理分布式部署的新分区功能、对 JSON 数据的支持以及性能的大幅提升。
2019 年，CockroachDB 大胆地从 2 版本跳到了 19！这并不是因为在 2 和 19 之间有 17 个失败的版本，而是反映了一个版本编号策略的变化，即将每个版本与其发布年份关联，而不是将版本指定为“主要”或“次要”。
以下是过去发布版本的一些亮点：
- 版本 19.1（2019 年 4 月） 引入了加密静态数据和 LDAP（轻量级目录访问协议）集成等安全功能、第 7 章中描述的变更数据捕获功能，以及多区域优化。
- 版本 19.2（2019 年 11 月） 引入了并行提交事务协议和其他性能改进。
- 版本 20.1（2020 年 5 月） 引入了许多 SQL 功能，包括 ALTER PRIMARY KEY、SELECT FOR UPDATE、嵌套事务和临时表。
- 版本 20.2（2020 年 11 月） 添加了对空间数据类型的支持，DB 控制台中新增了事务详情页面，并将分布式备份和恢复功能提供给免费用户。
- 版本 21.1（2021 年 5 月） 简化了多区域功能的使用，并扩展了日志配置选项。
- 版本 21.2（2021 年 11 月） 引入了有界陈旧读取和众多稳定性与性能改进，包括一种防止集群过载的准入控制系统。
- 版本 22.1（2022 年 5 月） 增加了对超级区域、行级过期时间（TTL）和索引推荐的支持。
- 版本 22.2（2022 年 12 月） 引入了用户定义函数、MOLT（迁移遗留技术）架构转换工具、三元组索引和洞察页面。
- 版本 23.1（2023 年 5 月） 增加了对全文搜索的支持、用户定义复合类型、在 EXPLAIN 查询过程中对个人身份信息（PII）的屏蔽，并新增了具有自动补全的 shell 编辑器。
- 版本 23.2（2024 年 2 月） 引入了 READ COMMITTED 隔离级别、对 PL/pgSQL 的支持、列级加密功能，此外，还包括在 DB 控制台中可视化网络分区的能力、通过 Oracle GoldenGate 和 Debezium 迁移到 CockroachDB、使用 MOLT 实时迁移服务以及执行物理集群复制。
- 版本 24.1（2024 年 5 月） 达到了多区域托管服务集群的 99.999%（五个 9）的可用性目标。它还引入了将变更数据发出到 Azure Event Hub 的能力、将托管服务集群连接到 Google Private Service Connect，并包括 MOLT Fetch。
- 版本 24.2（2024 年 8 月） 引入了对 VECTOR 数据类型的支持，并对通过通用查询计划优化器的预处理语句进行了性能提升。
CockroachDB 实战
CockroachDB 在竞争激烈的数据库市场中获得了强大的吸引力和日益增长的用户群体。那些受到传统关系型数据库如 PostgreSQL 和 MySQL 可扩展性限制的用户被 CockroachDB 更大的可扩展性吸引。使用分布式 NoSQL 解决方案如 Cassandra 的用户则被 CockroachDB 提供的更高事务一致性和 SQL 兼容性所吸引。而那些向现代容器化和云原生架构转型的用户则欣赏该平台的云端和容器就绪能力。
如今，CockroachDB 可以自豪地展示它在多个行业中实现的大规模采用。让我们来看一些具体的案例研究。
CockroachDB 在 Netflix 的应用
Netflix 自 2020 年起开始在生产环境中使用 CockroachDB，并在这段时间内部署了超过 380 个大型 CockroachDB 集群（其中超过 160 个是生产集群，60 多个是多区域集群）。
他们的 CockroachDB 应用已经非常成熟，内部团队可以访问 CockroachDB 作为服务。这使得他们能够按需创建集群，提升开发速度和灵活性，并在最佳实践上实现标准化。
CockroachDB 在 Devsisters 的应用
Devsisters 是一家总部位于韩国的游戏开发公司，负责开发《Cookie Run: Kingdom》等手机游戏。最初，Devsisters 使用 Couchbase 作为其持久化层，但在事务完整性和可扩展性方面遇到了问题。寻找新的数据库解决方案时，Devsisters 的需求包括可扩展性、事务一致性以及对超高吞吐量的支持。
Devsisters 曾考虑过 Amazon Aurora 和 DynamoDB，但最终选择了 CockroachDB。Devsisters DevOps 团队的 Sungyoon Jeong 说：“如果是 MySQL 或 Aurora，我们根本无法扩展这个游戏。我们遇到了比预期多六倍的工作负载，而 CockroachDB 能够在这整个过程中与我们一同扩展。”
CockroachDB 在 DoorDash 的应用
DoorDash 是一个本地商务平台，连接美国、加拿大、澳大利亚、日本和德国的消费者与他们最喜爱的商家。今天，DoorDash 为其开发人员创建了超过 350 个 CockroachDB 集群，处理各种面向客户的工作负载、后台分析和内部工作负载。
DoorDash 团队喜欢 CockroachDB 可以横向扩展、支持 SQL 以及兼容 Postgres wire，并且能够在不影响性能的情况下处理大量的读写操作。CockroachDB 的弹性架构和实时架构变更也是团队的一个巨大优势。“DoorDash 已经能够使用 CockroachDB 进行升级迁移并扩展多个工作负载，而无需重写应用程序——只需进行少量的索引或架构变更。” DoorDash 核心基础设施团队的工程主管 Sean Chittenden 说。
CockroachDB 在 Bose 的应用
Bose 是全球领先的消费电子技术公司，特别以提供高保真音频设备而闻名。
Bose 的客户遍布全球，Bose 旨在为这些客户提供一流的云端支持解决方案。
Bose 已经拥抱了现代的基于微服务的软件架构。Bose 平台的骨干是 Kubernetes，它使得应用程序能够访问低级服务（容器化计算）以及高级服务，如 Elasticsearch、Kafka 和 Redis。CockroachDB 成为了这个容器化微服务平台的数据库基础。
除了 CockroachDB 的弹性和可扩展性，CockroachDB 能够在 Kubernetes 环境中托管这一特性也是决定性因素。
通过在 Kubernetes 环境中运行 CockroachDB，Bose 赋能开发人员，通过提供按需自服务数据库的能力。开发人员可以在 Kubernetes 环境中轻松快捷地启动 CockroachDB 集群用于开发或测试。在生产环境中，CockroachDB 与 Kubernetes 一起运行，提供了全栈的可扩展性、冗余和高可用性。
CockroachDB 在 Form3 的应用
Form3 正在革新支付行业。CockroachDB 为全球一些最大的金融机构提供了一个可靠的支撑，支撑着一个 Tier-0 的关键国家支付基础设施。
Form3 定期通过混沌工程测试 CockroachDB 的极限，让其内建的自愈能力从他们扔向它的任何挑战中恢复。CockroachDB 跨多个云区域甚至多个云服务提供商运行，使 Form3 成为全球最强大且最具韧性的支付提供商之一。
CockroachDB 在 Hard Rock Digital 的应用
根据美国《联邦电汇法案》（1961 年），Hard Rock Digital 运行着一个跨云区域和本地数据中心的 CockroachDB 集群。
《联邦电汇法案》要求所有关于投注的数据和处理都必须保持在投注所在的州内。为了到达超大规模提供商没有云区域的地方，Hard Rock Digital 在 AWS Outposts 上运行 CockroachDB——AWS 的一项服务，运行在他们自己的硬件上。这使得 Hard Rock Digital 能够在他们服务的每个州运行 CockroachDB，同时遵守相关规定。
CockroachDB 在 Spreedly 的应用
Spreedly 是一个全球支付编排平台，允许客户通过一个 API 访问 100 多个国家的支付服务。在采用 CockroachDB 后，他们通过以下方式大幅简化了架构：
- 移除了多个遗留数据库
- 消除了不必要的提取、转换和加载（ETL）管道组件
- 解决了复杂的脑裂场景，确保所有消费者看到一致的数据
CockroachDB 在 Route 的应用
Route 是一个领先的后购买平台，CockroachDB 是他们平台始终在线数据模型的核心——处理数十亿笔订单，为数百万客户服务。
考虑到他们所支持的电子商务业务的季节性特点，CockroachDB 提供的便捷横向扩展能力让他们能够高效服务客户——并且零停机。
CockroachDB 提供了我见过的最大投资回报率，在任何厂商的付费支持中都是如此。 ——Route 高级首席工程师 Brian Call
总结
在本章中，我们将CockroachDB置于历史背景中，介绍了CockroachDB数据库的目标和能力。
上世纪70年代和80年代出现的关系数据库管理系统（RDBMS）是软件工程的胜利，推动了从客户端/服务器到早期互联网的软件应用。但全球可扩展、始终可用的互联网应用的需求与当时单体、严格一致的RDBMS架构不兼容。因此，大约在2010年左右，一系列NoSQL分布式、“最终一致”系统应运而生，以支持新一代内部应用的需求。
尽管这些NoSQL解决方案有其优势，但对于许多应用来说，它们是倒退。无法保证数据正确性，以及失去了广泛熟悉和高效的SQL语言，在许多方面都是一种倒退。CockroachDB的设计目标是作为一个高一致性和高可用性的基于SQL的事务性数据库，在可用性和一致性之间提供更好的折衷——优先保证一致性，但同时提供非常高的可用性。
CockroachDB是一个高度可用、事务一致的SQL数据库，兼容现有的开发框架，并且越来越适应容器化部署模型和云架构。CockroachDB已经在广泛的垂直行业和不同环境下进行了大规模部署。
在下一章中，我们将深入探讨CockroachDB的架构，并了解它是如何实现其雄心勃勃的设计目标的。
