作者 | Tina、核子可乐

哪怕大牛也得承认，有时候单凭自己的成果不足以解决问题。如今，SQL 之父认为 NoSQL 才是出路。

1974 年 5 月，Donald Chamberlin 与 IBM 同事 Raymond Boyce 发表了一篇关于 SEQUEL 的论文，这是一种用于管理和排序数据的结构化查询语言。由于另一家公司拥有“SEQUEL”一词的版权，该语言更名为“结构化查询语言”（SQL）。随后在 70 年代后期，随着像 Oracle 这样的数据库公司推出新式关系型数据库产品，SQL 也被这些公司所采用。正如人们常说的那样，剩下的就是历史了。

SQL 现已有 50 岁了。2000 年左右入行的人，可能知道它的高光时刻，那时三层后端应用架构正盛行。当时的技术架构主要包括网络服务器（通常是 Apache）、应用服务器和数据库。由于掌握这些知识和经验的人较少，因此开发人员需要具备多方面的技能，包括 HTML、JavaScript（主要用于处理表单提交）、一种应用服务器层业务逻辑处理语言（当时通常是 Java），以及数据库操作语言 SQL。不同的人有不同的偏好和专长，但要成为一名高效的开发人员，就必须具备所有这些技术的的基本知识。

当时，整个开发工程师行业只关注“开发”（dev），“运维”（ops）则被忽视。 运维工作要么由开发人员兼顾（在小型组织中），要么由系统管理员负责（在大型组织中）。后来，小型组织逐渐发展出 DevOps 思维方式，而大型组织则开始采用 SRE 模式。当时的数据科学领域也尚未兴起。

数据库管理员（DBA）的主要职责是确保数据备份和维护数据库性能。他们会“惩罚”那些用写得糟糕的查询或定义错误的索引污染数据库的人。因此，他们有时也会兼任开发人员的 SQL 导师。

由于几乎每个人都是开发人员，并且开发人员需要具备多方面的技能，因此在面试中，工程师经常会被问到 SQL 问题。 面试通常会从简单的 join 开始，然后对于更高级的求职者会考察他们在索引和性能方面的知识。

但如今，你会发现一些非常聪明、知识渊博的年轻同事可能从未学习过 SQL。他们可能会通过将这些查询与他之前遇到过的其他基于 JSON 的 *QL（例如 PromQL、GraphQL 等）进行比较来理解它们。

Martin Fowler 指出，“NoSQL”实际上是“No DBA”。

因为随着运维 (ops) 的兴起，IT 行业的专业化分工也日益细化。虽然 DBA 已经存在了很长时间，但随着前端工程师、测试人员、数据科学家、DevOps 工程师、站点可靠性工程师 (SRE)、安全工程师等越来越多专精岗位的出现，“开发人员” (dev) 的角色逐渐被细分。因此，SQL 是否是一种偏“小众”的技能，逐渐成为了一个争议点。

Don Chamberlin 认为，SQL 早前能够兴起，有几个主要原因。首先关系模型既简单又强大、灵活而不失优雅，也因此让种种功能成为可能。其次，Ingress 项目等早期研究的公开发表也有很大帮助。第三，ANSI 标准在提供定义良好的语言规范的同时，也设定了正确的语言发展方式，能够切实满足新的需求。这使得 SQL 在数十年间始终跟得上新兴需求，从而保持住了良好活力。第四点是有大量高质量的开源 SQL 一直在免费供应。这几条，足够维持 SQL 的活力。

SQL 发展得比想象中更成功，但 Don Chamberlin 也表示他们必须得承认，SQL 语言只在一定程度上实现了他们当初定下的目标。

“毕竟 Ray 和我当初都把 SQL 看作一种低门槛的技术方案，应该面向那些非程序员的‘临时用户’群体。”

现在，“我们预想中的临时用户仍然存在，而他们却并不使用 SQL。他们更倾向于使用 Google 搜索，而且最近一段时间越来越多地使用像 ChatGPT 这样的 AI 系统。”

Chamberlin 认为半个世纪的数据库革命，其深层驱力源自经济。同时硬件正以指数速度变得更强大、更便宜。硬件层面的进步让三件事成为了可能。首先就是干净、优雅的数据模型，比如说 Codd 提出的关系模型。第二就是出现了高级的非过程化语言，也就是 SQL。第三就是经过优化的编译器能够将这一切整合起来，最终实现商业意义上的可行性。数据模型、查询语言和优化编译器这三者的相互协同，构成了鼎立般的稳固效应。

但如今，SQL 之父现已明确表示支持 NoSQL 数据库运动，为这场强调摆脱 RDBMS 表限制的技术趋势增添了新的光彩。

Chamberlin 在接受采访时解释称，NoSQL 数据库及其查询语言有助于执行关系系统在设计之初从未考虑过的各种任务。

他指出，“世界绝不会一成不变，特别是在计算机科学领域。这是一个快速迭代、不断发展的行业。新的需求不断出现，技术当然也需要相应改变方可满足这些需求。我认为现状也的确如此。NoSQL 运动是由新型应用程序（特别是 Web 应用程序）所推动的，它们需要强大的可扩展性。与之对应，关系数据库的诞生时期较早，当时可扩展性与性能相对不那么重要。因此为了实现现代应用程序所需要的可扩展性和性能，诸多系统正在放宽对关系数据模型的种种限制。”

NoSQL 具有多种形式，每种形式旨在解决不同的挑战。目前流行的文档数据库基于开放 JSON 标准，主要尝试绕过 RDBMS 的架构约束。这类方案包括 MongoDB、Couchbase 以及亚马逊的 DynamoDB。而键值存储方案可以提供更好的灵活性和速度表现，具体包括 Aerospike、Memcached 和 Redis，它们常被作为互联网应用缓存，也是目前亚马逊云科技上最流行的数据库。图数据库强调将关系网络表示为边和节点，主要方案包括 Neo4j 和 TigerGraph 等系统。

数据库专家之间一直存在着激烈的争论，有些人认为 NoSQL 方法确有必要，但也有一些人认为可以把 NoSQL 系统的属性转化为关系系统中的功能。例如，大多数流行的关系系统现在都支持 JSON 文档，而 Oracle 和 PostgreSQL 则提供图式查询。

但在 Chamberlin 看来，NoSQL 的存在对于支持现代应用程序来说确有必要。

我都已经退休了，但还是会经常听到 NoSQL 这个词。我认为 NoSQL 运动的灵感，来自那些需要大规模可扩展数据库的 Web 应用程序。这类用例最需要的就是强大的可扩展性，同时愿意放松某些在传统关系数据库上比较严格的限制。

咱们举例说话。第一，关系数据库往往有着严格的模式，要求准确描述表的样式和所处系统。NoSQL 系统有时候会放宽这方面要求，比如可能提供压力模式，但也可能根本没有模式，所以会更加灵活。

第二，关系数据库只适用于关系数据模型，也就是由大量同质化表建立的数据结构。在每个表中，所有行看起来都大差不差。但 NoSQL 系统有时会放松这方面要求，允许使用不同的数据模型。其中有些会非常简单，比如键-值存储。NoSQL 可能还支持嵌套表，或者基于 XML 和 JSON 之类的特定文档格式。

至于第三点区别，就是关系数据库系统往往包含一些保证机制，比如通过 ACID 属性保持数据的一致状态。而 NoSQL 系统有时候会稍微放宽这种限制。

它们往往会跨多个节点复制数据，而且可能接受所谓“最终一致性”，也就是各节点间的数据要过一段时间才能实现同步。所以说 NoSQL 确实是个令人兴奋的新方向，我认为也可以用它来概括数据库研究领域最具前途的整体思路。

传统的关系系统需要为事务保留资产记录，从而提供即时一致性。对于一致性问题，他在采访中表示，“为了实现更高的性能，现在我们经常会把数据分布在机器集群上。也就是说能实现最终一致性就可以了，因此我们可以耐心等待，让所有机器在一段时间之后再达到一致。对于高度扩展的环境，这种用时间换性能的作法很有必要。”

Chamberlin 是一位长期效力于 IBM 的员工，目前已经处于半退休状态，但他仍抽出时间担任 NoSQL 厂商 Couchbase 的技术顾问。

在这个职位上，他成为一种新型查询语言的倡导者，这就是 SQL++。该语言旨在克服应用程序语言及数据库内数据结构之间的“摩擦阻力”。

SQL++是加州大学圣迭戈分校教授 Yannis Papakonstantinou 提出的解决方案，旨在消除基于对象的 JavaScript（Web 开发领域的核心语言）与 SQL 中嵌入的预设关系方法间的“摩擦阻力”。

与 C++一样，SQL++在设计上属于早期 SQL 语言的兼容扩展，但号称能够更好地处理 JavaScript 所固有的 JSON 文件格式。

Couchabse 与亚马逊云科技均已采用这种语言，只是云巨头将其称为 PartiQL。

Chamberlin 于 2019 年针对 Couchbase 发表的论文介绍了 SQL++与 SQL:2016，关注了这两种语言编写的部分示例查询并做出比较。

但他同时强调，SQL++只是 SQL 的有益补充、而非替代品。

“我认为 SQL 并不会消失。世界上很大一部分业务数据都是用 SQL 编码的，而且数据具有很强的粘性。只要掌握了数据库，就可以把数据驻留在其中。此外，关系系统在其自身功能定位之内表现极佳，MySQL、PostgreSQL 和 SQLite 中都是质量极高的开源关系数据库实现。”

“这些 SQL 实现非常强大、功能完备且可靠性出色，也都有着庞大的用户社区。如果您是一家想在网络上销售鞋子或者其他商品的初创公司，又需要一套数据库，那么这些 SQL 实现将帮您免费满足这些需求。我认为关系数据库和 SQL 语言仍将在久远的未来继续陪伴在大家身边。”

原文链接：