使用 Apache Cassandra 创建对开发人员友好的数据服务

所有应用程序都依赖于数据，但应用程序开发人员不喜欢考虑数据库。学习特定数据库的内部结构和查询语言会增加认知负担，并且需要进行上下文切换，这会降低生产力。尽管如此，成功的应用程序必须具有响应性、弹性和可扩展性——所有这些特性都将由数据库的选择决定。

那么，应用程序开发人员应该如何平衡这些考虑因素呢？

如果我们可以改变平衡，以对开发人员友好的习惯用法提供数据服务，而不是期望开发人员学习特定于数据库的习惯用法，会怎样？

在 Stargate 项目（旨在与Apache Cassandra配合使用的开源 API 数据网关）中，我们很高兴开始公开谈论我们即将推出的JSON API ，它可以满足面向 JSON 的开发人员的要求。这不仅对面向 JSON 的开发人员来说是个好消息，而且我们所遵循的技术构成了一种新的设计模式，可以利用数据 API 和高级数据建模来生成数据服务。

在本文中，我将讨论如何结合使用 Cassandra 和 Stargate 来提供对开发人员友好的习语，以及我们如何努力为JSON做到这一点。

数据模型：互操作性与成语

早期，Cassandra 有时被描述为“制作索引的机器”。这证明了 Cassandra 与生俱来的弹性和灵活性，一种粘土，可以用它塑造更坚固的结构。今天的 Cassandra 是一种更丰富的粘土，具有更大的可能性。

它不仅是一个很棒的数据库，而且还是制作数据库的很棒的机器。在 Stargate 项目中，我们使用 JSON API 来证明这是数据库开发新范例的第一个例子。

从一个数据库构建另一个数据库的情况并不少见。甚至 MongoDB 也是建立在WiredTiger之上的，如果你挖掘得够深的话。 AWS 以其在幕后广泛使用 MySQL 而闻名，包括为 DynamoDB 使用 MySQL 存储引擎。因此，使用具有内在可扩展性和性能的 Cassandra 作为其他数据系统的构建块的想法是有意义的。

然而，应用程序开发人员并不真正与数据库交互。即使您的组织管理自己的数据库基础设施并针对该基础设施构建应用程序，第一步通常也是定义和实施您的应用程序所需的数据模型。

这些数据模型在应用程序和数据库之间进行调解。从某种意义上说，数据建模限制了数据库；它采用未成型的、因此是通用的粘土，并将其塑造成为特定应用程序惯用语专门构建的东西。我们为了一些惯用的东西牺牲了互操作性。

换取一些惯用的东西并放弃一些可互操作的东西是个好主意吗？如果您想击败平均水平，那么答案是肯定的“是”。我们在选择数据库的时候不怎么这么想，但是在选择编程语言的时候我们早就这么想了。

几十年前，保罗·格雷厄姆 (Paul Graham) 很好地表达了这个想法，当时他解释了 Viaweb 如何赢得早期的互联网竞赛，从而创建了第一个广泛成功的基于 Web 的电子商务平台。

Viaweb 不一定是最快或最具扩展性的电子商务平台。用格雷厄姆的话来说，它“相当有效”。相反，格雷厄姆认为，对于编程语言，在机器可读到人类可读的范围内，人类可读性更强（因此更高级别）的语言更强大，因为它们提高了开发人员的生产力。而在 Viaweb 的时候，Graham 认为最强大的语言是Lisp 。格雷厄姆论点的关键在于：

“我们的假设是，如果我们用 Lisp 编写我们的软件，我们就能比我们的竞争对手更快地完成功能，并且还能在我们的软件中做他们做不到的事情。而且因为 Lisp 的水平很高，我们不需要庞大的开发团队，所以我们的成本会更低。如果真是这样，我们就可以用更少的钱提供更好的产品，同时还能盈利。我们最终会获得所有用户，而我们的竞争对手将一无所获，最终倒闭。”

释放开发人员的生产力

格雷厄姆 20 年前写下了这些话，开发人员的生产力仍然是引导技术创新的北极星。在 Graham 谈论高级语言的力量时，我们表达了相同的概念，即为开发人员提供更符合他们软件开发经验的工具。

Graham 赞扬 Lisp（正确），自互联网时代以来，我们看到了新的高级语言的激增：Ruby 和 Rust，仅举几例。我们还看到了移动设备开发人员语言和框架的诞生和激增，例如 Swift、Flutter 和 Dart。

那么为什么像 C 和C++这样的语言仍然很重要呢？关于 C 的老笑话有一个重要的真理：“将汇编语言的强大功能与汇编语言的易用性结合起来。”如果你想写一个编译器，那么你需要更接近机器语言的习惯用法，远离自然语言的习惯用法。

换句话说，除其他优点外，C 和 C++ 是构建新语言的机器。在格雷厄姆对 Lisp 的赞美中容易忽视的是，Lisp 也具有这种“构建语言的机器”的一些特征。

Lisp 是第一个广泛使用的引入宏概念的语言，而正是宏的概念让那些刚接触 Lisp 的人感到困惑。一旦你理解了宏，你就会明白 Lisp 与其说是一种语言，不如说是一种元语言，并且可以使用宏来为特定问题领域构建一种专用语言。

设计和创建一组初始宏是一项艰巨且具有智力挑战性的工作。但一旦 Graham 和 Viaweb 团队做到了这一点，实际上他们就有了一种可以使用的电子商务编程语言，这释放了开发人员的生产力，使他们能够超越竞争对手。

二十年后，所有这一切在编程语言的背景下似乎已经足够清楚了。那么，数据库世界发生了什么？简短的回答是数据库的发展速度更慢。

数据 API 革命

如果表格数据是数据库世界的汇编语言，那么 SQL 就是查询语言的 C/C++。我们在计算和存储昂贵的时代开发了表格数据结构和数据规范化的概念，并且适用于定义明确且架构更改相对不频繁的用例。在这种情况下，要在任何规模上高效运行，数据库都需要密切模仿计算机存储和访问信息的方式。

今天的世界恰恰相反，相比之下，早期的时间显得过时：计算和存储成本高度商品化，但在实时数据与机器学习和人工智能相结合的世界中，用例是开放式的，模式变化是频繁。

数据库技术的最新革命是 NoSQL 革命，这是对关系数据库世界的大祭司制定的表格规范化数据规范的直接回应。当我们说“NoSQL 革命”时，我们指的是从 2004 年谷歌发布其MapReduce 白皮书到 2007 年亚马逊发布其Dynamo 白皮书的时期。

这一时期出现了一系列数据库，它们通过放弃两个珍贵的关系原则实现了前所未有的速度、可扩展性和弹性：NoSQL 数据库偏爱非规范化数据而不是数据规范化，并且偏爱最终一致性而不是事务一致性。 2008 年首次发布的 Cassandra 就是从这场革命中脱颖而出的。

数据 API 将是数据库技术的下一次重大革命，而这场革命才刚刚开始。数据库世界的变化往往滞后于编程语言和应用程序开发的变化。因此，虽然 RESTful API 已经存在了一段时间，并帮助引入了面向分布式服务的应用程序的体系结构，但我们才刚刚开始看到数据 API 已成为应用程序基础架构的关键部分。

要了解这场革命的意义，以及在 Paul Graham 宣布 20 年后，数据库世界如何最终提高开发人员的生产力，让我们看看 Stargate 自己的故事。它首先回到互操作与惯用的主题。

星际之门：高保真、惯用的开发者体验

当我们决定 Cassandra 生态系统需要一个数据网关时，我们怀着紧迫感构建了最初的 Stargate API 集。这意味着一个单体架构；整体构建起来更快，但并不总是更好。我们推出了 Cassandra 查询语言 (CQL) API、REST API 和 RESTful 文档 API。我们很快将 GraphQL 添加为附加 API。迄今为止，Stargate 已经可以互操作； Stargate 的所有内容都使用本机 CQL 数据模型存储，因此原则上，您可以从任何 API 查询任何表。

我们了解到，在实践中，没有人真正做到这一点。开发人员坚持他们特定的习惯用法。通过支持互操作性，我们将 Cassandra 主义融入了开发人员体验，从而降低了开发人员的工作效率。因为 Stargate 的原始版本要求开发人员了解 Cassandra 的宽列表格数据结构，以了解键空间和分区，所以我们离机器习惯太近而离人类习惯太远。

互操作性陷阱是支持通用目的而不是特定目的的内置设计思维。我们已经转向以专用的方式思考，用一些通用的能力换取更具体的表达方式，使我们更接近人类的习语，远离机器的习语。因此我们开始思考：我们能否在保留 Cassandra NoSQL 基础（规模、可用性和性能）优点的同时提供高保真度惯用的开发人员体验？

关键在于数据建模。为了将 Cassandra 变成“数据库中的 Lisp”，我们需要一个可以实现类似于 Lisp 宏的目的的数据模型，以及一个 Stargate API，使开发人员能够以惯用的方式与该数据模型进行交互。我们从 JSON 开始，它是应用程序开发人员之间数据结构的最大共同点，因此开始为 Stargate 构建 JSON API。然后我们必须弄清楚如何最好地在 Cassandra 中对 JSON 进行建模。

Stargate 已经有一个文档 API，但在 Stargate 的原始文档 API 中，我们使用了一种我们称为“分解”的数据模型来将 JSON 文档呈现为 Cassandra 表。该模型将一个文档映射到单个 Cassandra 表中的多行并保留互操作性。如果您使用 CQL 查询结果表，您将得到有意义的结果。

这种原始的粉碎数据模型有缺点。它不保留有关文档的元数据。例如，对于任何包含数组的文档，一旦文档被写入，如果不完全检查文档，我们就不知道数组大小。更重要的是，我们已经偏离了 Cassandra 对索引的期望。 Cassandra 在行上建立索引，但我们现在将文档分布在多行中，使得文档的本机 Cassandra 索引变得不可能。

为了使 Cassandra 成为适合 JSON 的存储引擎，我们需要一种新的数据模型，一种优于分解的东西。我们称之为“超级粉碎”。您可以在 12 月 Aaron Morton 的Cassandra 峰会演讲中了解有关超级粉碎的更多信息，但这里有一些预告片：我们利用 Cassandra 的宽列特性每行存储一个文档，因为我们知道 Cassandra 行可以处理非常大的文档文件。

我们在该行中还有一组列，它们明确用于存储 JSON 文档的标准元数据特征。现在我们有了更容易索引的东西，以及保存和检索元数据的方法。

回馈 Cassandra

是的，为了让这一切大规模运作，我们需要对 Cassandra 进行一些根本性的改变。 Apple 为 Cassandra 5 贡献的 Accord 将帮助我们以更具事务性的方式处理数据更改。 DataStax 为 Cassandra 5 贡献的附加存储索引 (SAI) 和全局排序将帮助我们以更高效的方式处理针对 JSON 文档的范围查询。

Cassandra 不是一个静态的软件；这是一个充满活力和不断发展的开源项目。因此，我们还延续了 Cassandra 长期以来的传统，即使用客户端出现的需求来促进数据库端的变化。用户需求促使了 Accord、SAI 和 Global Sort 的提议。这些不仅会让 Stargate 的 JSON API 变得更好，而且会让 Cassandra 变得更好。这是一个很好的提醒，数据工程师和应用程序开发人员不是两个不同的社区，而是扩展的 Cassandra 社区的互补群体。

而 JSON 只是第一步。本质上，我们将构建一个文档数据库，您可以使用 Cassandra、Stargate 和相当高效的 Cassandra 数据模型通过 JSON API 与之交互。超级粉碎是我们的宏。这种方法将 Cassandra 变成了制造数据库的机器。

除了 Cassandra 之外，其他数据库能否采用这种方法？不容易，这就是原因。有一种热力学第二定律的数据库模拟对 Cassandra 有利。我们从快速、可扩展和有弹性的东西开始，但对开发人员来说不是很习惯。在合理效率的限制下，我们用一些速度、规模和弹性来换取更惯用的界面来呈现给开发人员。一个人不能轻易做到的是向相反的方向前进。从高度惯用的东西开始，然后试图弄清楚如何使其快速、可扩展和有弹性是一项艰巨的任务，甚至可能是不可能的。

这个热力学原理就是为什么数据 API 是新的数据库革命，以及为什么 Cassandra 是推动这场革命的数据库。

也发布在这里。