技术的轮回：数据库世界的前世今生

时任麻省理工学院兼职教授的Michael Stonebraker和Joseph M. Hellerstein[i] 联合发表了论文“What Goes Around Comes Around”，作为《Readings in Database Systems, Fourth Edition》的开篇文章。论文回顾了过去近40年数据模型的主要提案，并总结了这些提案的经验和教训。

此时距他发表论文“INGRES的设计与实现”已过去32年，另一篇论文“POSTGRES[ii] 的设计”也已发表19年。再过9年，凭借其在数据库领域的卓越贡献，Stonebraker将获得图灵奖，也就是“计算机界的诺贝尔奖”。

2024年，Stonebraker与Andy Pavlo[iii]联合发表了文章“What Goes Around Comes Around... And Around...”，作为2005年论文的后续，再次对过去20年的数据模型做了回顾和总结。

本文将回顾这两篇论文的主要内容并做简明解读。

2005年论文回顾

数据模型是数据库中数据的底层结构和组织方式。2005年的论文重点讨论了9个数据模型提案，并总结了每个提案的经验和教训。

前关系模型时代

第一个登场的模型是20世纪60年代的层次模型（IMS）。层次模型是一种树状结构，其主要的缺点为：

信息重复，可能导致数据不一致。
有限的物理数据独立性和逻辑数据独立性，导致应用难以维护。

来解释下第2点。无论在物理层面进行何种调优（如升级存储硬件，更改索引类型），数据库应用程序都能继续运行的能力被称为物理数据独立性。逻辑数据独立性类似，常见的逻辑变更包括增删字段，数据类型改变等。物理和逻辑数据独立性非常重要，因为“数据库应用程序的生命周期比其操作的数据要长得多。数据独立性允许数据更改，而无需进行昂贵的程序维护。”

紧接着来到网络模型（CODASYL）。简而言之，网络模型比层次模型更灵活，但也更复杂。不过关键是，物理和逻辑数据独立性的问题仍然存在。

关系模型的崛起

1970年，Ted Codd 提出了关系模型。关系模型的目标旨在提供更好的数据独立性，当应用程序发生逻辑或物理变化时，无需花费大量时间进行维护。同时关系模型足够灵活，几乎可以表示任何事物。

他的建议主要有三点：

将数据存储于简单的数据结构：表，因此可提供更好的逻辑数据独立性。
通过高层级的set-at-a-time[iv] DML 访问数据，可提供更好的物理数据独立性。
无需指定物理存储方案（而IMS 和 CODASYL需要指定）。

除了严谨的数学理论基础[v]，关系模型的成功也取决于一些非技术因素，作者补充了一些轶事。当时，IBM大型机主导市场，VAX小型机革命蓬勃兴起时，大型机上IMS和CODASYL数据系统的不可移植性为关系型系统创造了机会。更具决定性的事件是1984年IBM宣布即将发布DB/2，表示IBM从单一的IMS转向双数据库战略，IMS和DB/2都被视为战略性产品。DB/2是新技术，使用起来更加方便。同时，IBM当时拥有巨大的市场影响力，其态度的转变实际上宣布关系型系统终将胜出。事实也正是如此，自 20 世纪 80 年代以来，关系模型 + SQL 一直主导着数据库领域。这一节的末尾，作者不禁感叹道：“技术争论通常由市场中的巨头们来解决，而且往往是出于与技术无关的原因”。

新模型的挑战和融合

1970年代，Peter Chen[vi]提出了实体关系（E-R）数据模型。E-R模型在数据库模式设计领域取得了巨大成功。其简单性使得人们可以容易和直观的理解功能依赖关系。几乎所有的数据库设计工具都是以这种方式工作的。

后面的几个数据模型提案乏善可陈，没有一个获得市场的广泛关注。主要原因是这些建议未能提供实质性的优势来换取增加的复杂性。唯一值得注意的新概念包括数据库中的代码（存储过程，触发器）和用户定义的访问方式[vii]，这些都属于性能构造而非数据模型构造。

论文最后一章的标题是Full Circle，作者说到：“很明显，我们已经‘绕了一圈’”。换句话说，“我们很少看到新的数据模型理念。过去20年提出的大多数概念都是对25年前事物的重新发明”。当然，这并非说数据模型又回到了原点，关系模型虽没有脱胎换骨，却已在千磨万击中变得更加坚劲和全面。

2024年论文回顾

对比2024年论文名“What Goes Around Comes Around... And Around...”与2005年论文名“What Goes Around Comes Around”，可以发现2024年论文实际是2005年论文工作的延续，涵盖了近20年数据模型的发展历史。这篇论文的正文部分只有12页，只有2005年论文的1/3；但参考文章数量为204篇，远超2005年论文的46篇。总的来讲，2024年论文更易读，更好理解，毕竟大家大多亲历过这些技术发展，因而更容易感同身受，引起共鸣。

论文分为三部分，分别是数据模型发展的研究，系统架构的演进和临别赠言。

数据模型与查询语言

作者从8个方面回顾了数据模型和查询语言的发展，如下图所示：

其中，列族数据库可以认为是文档数据库的简略形式；数组数据库需求小众，没有可观的市场。Graph数据库和文本搜索正迅速成为关系模型系统的一部分，例如2023年的SQL标准[viii]新增第 16 部分 SQL/PGQ，定义了 SQL 语言表示属性图以及与属性图交互的方式，使得关系型数据库与原生Graph数据库的功能差异越来越小。因此，我们将略过以上数据模型，着重介绍其余四个，即MapReduce系统，键/值存储，文档数据库和向量数据库。

MapReduce系统

MapReduce（MR）框架最初由Google在2003年提出，用于抓取互联网数据。MapReduce框架并没有规定具体的数据模型或查询语言，实际的数据操作是由Map和Reduce函数来实现的。2005年，雅虎开发了MapReduce的开源版本：Hadoop。后续大数据时代的来临使得Hadoop炙手可热，关系型数据库和Hadoop的技术之争持续了很长一段时间。

如今，Hadoop风光不再，“Hadoop 大约在十年前就消亡了，只留下企业中大量的 HDFS 集群，以及一批致力于从中获利的公司”。技术和服务市场的萎缩导致三大Hadoop供应商（Cloudera、Hortonworks和MapR）“没有可行的产品可卖”。2010年，基于实时数据更新的需要，Google在网页抓取系统中使用BigTable数据库取代了MapReduce，并于2014年彻底将MR剔除出技术栈。

不过，作者也谈到：“MR 系统实现中与可扩展性、弹性和容错性相关的一些方面被延续到了分布式关系数据库管理系统中。MR 还带来了基于分解存储的共享磁盘架构的复兴，随后催生了开源文件格式和数据湖”。

键/值存储

键/值 (KV) 数据模型将数据集合表示为关联数组。关联数组将键映射到值，而传统数组则使用数字索引来访问元素。KV数据库的好处是简单，建立一个数组比建表简单多了。但缺点也是简单，非常适合缓存数据，但功能有限不足以支撑复杂的业务场景。因此KV数据库开始转变，例如从最初仅支持不透明的二进制值，到后来支持半结构化的JSON值。不过，“重新设计键值存储以使其支持复杂的数据模型并非易事，而关系型数据库管理系统 (RDBMS) 可以轻松地模拟键值存储而无需任何更改”。实际上，全功能的关系型数据库融入KV存储要容易得多。例如，从架构层面将KV存储作为底层存储引擎已形成新的趋势，如MySQL的MyRocks存储引擎和MongoDB使用的WiredTiger存储引擎。

最后，作者总结道：“因此，即使对于简单的应用程序来说，关系型数据库可能是一个更好的选择，因为如果应用程序的复杂性增加，它们会提供前进的道路”。

文档数据库

文档数据模型中的文档是由字段/值对组成的层次结构，字段即名称标识，字段的值可以是标量，向量（数组）或其他字段。

文档数据库的兴起基于两点。首先，JSON取代XML成为数据交换标准。其次，文档数据库以No SQL为旗号，其中两个营销信息引起了开发人员的共鸣，即应使用“更快”的底层API替换很慢的SQL和Join[ix]，以及现代化应用不需要强一致性的ACID[x]，弱一致性的BASE[xi]就足够了。

不过，文档数据库与2005年论文中的面向对象数据库和XML数据库本质上是一样的。是否更快不好说，但数据一致性和数据独立性的问题依然存在。2005年的论文已经正确的预测XML数据库不会取代关系型数据库，那么这一次呢？

事实就是，2010年代末到20年代初，几乎所有的NoSQL数据库都增加了SQL接口，比较知名的包括DynamoDB，Cassandra，Couchbase和MongoDB。还有很多数据库增加了强一致性（ACID）事务的支持，例如MongoDB和Couchbase。NoSQL的含义从最初的“不要使用SQL”变成了“不仅要使用SQL”- Not Only SQL。另一方面，2016年的SQL标准[xii]也增加了对JSON数据类型和操作的支持，数据库厂商纷纷跟进，Oracle，MySQL和PostgreSQL数据库还可提供原生JSON支持。

最后，作者总结道：“高级语言[xiii]几乎普遍比‘面向记录’的表示法[xiv]更受欢迎，因为它们需要的代码更少，并且提供更高的数据独立性。尽管我们承认最初的 SQL 优化器速度慢且效率低下，但它们在过去 50 年里得到了巨大的改进。然而，优化器仍然是构建 DBMS 最难的部分。我们怀疑这种工程负担是 NoSQL 系统最初选择不支持 SQL 的一个因素”。

向量数据库

随着AI和大模型的爆火，向量数据库也获得了越来越多开发者的关注，因为开发者可以用向量数据库来存储数据的向量表示，这些向量表示即数据的潜在语义，在AI的术语中称为Embedding。向量的维度从几十到数千不等，较低的维度更高效、更快，但可能损失部分语义信息；较高的维度则训练、存储和计算的成本更高。

向量并非为AI而生，但AI却很需要向量。Embedding将非结构化的数据（如文本，图像）转换为具有语义的数值，这带来两方面的好处。数值化使得计算更方便，并可以利用GPU加速。语义化则可以在空间中表示意义，相似的意义彼此靠近，便于实现相似性搜索这一非常有吸引力的场景。

目前，向量数据库分为两类。一类是新兴的专用向量数据库，如Pinecone和Milvus；另一类则是在关系型数据库中新增对向量的支持，如Oracle，PostgreSQL。由于支持向量的工作量很小，一些关系型数据库厂商不到一年就支持了向量，这和之前花费数年支持JSON形成鲜明对比。

最后，作者总结道：“我们预计，向量数据库将经历与文档数据库相同的演变，通过添加功能使其更接近关系型数据库（例如 SQL、事务和可扩展性）。与此同时，关系型数据库将在其现有的众多功能中添加向量索引，并转向下一个新兴趋势”。

系统架构的演进

这一部分主要讨论“过去二十年，DBMS 架构中涌现出许多重要的新思想，这些思想反映了应用程序和硬件特性的变化”。作者从6个方面进行了阐述，他们是列存系统、云数据库、数据湖/湖仓，NewSQL系统、硬件加速和区块链数据库。

作者认为，“这些想法有的很棒，有的值得商榷”。 “很棒”的想法我们会着重讨论，他们是列存系统和云数据库。“值得商榷”的想法则会略过，他们是NewSQL系统、硬件加速和区块链数据库。因为作为NoSQL优化版的NewSQL“乏人问津”，硬件加速“机会渺茫”，而区块链数据库用例太少（加密货币是唯一用例）。至于数据湖/湖仓，作者的态度似乎模棱两可，不过基于其普遍关注度，我们也会加以阐述。

列存系统

行存（储）系统适合于交易，列存（储）系统则适合于分析。所以，“在过去的二十年里，所有活跃在数据仓库市场的供应商都已将其产品从行存储转换为列存储。这一转变带来了数据库管理系统（DBMS）设计的重大变革”。

作者列举的Amazon Redshift，Google BigQuery和Snowflake，都是专门用于OLAP的数仓系统。需要补充的是，还有一类可以兼顾OLTP和OLAP的HTAP系统，如Oracle数据库和SAP HANA。Oracle数据库本身就支持交易和分析，2014年发布的Database In-Memory选件更是将分析能力提升到新的高度。相对于单纯的OLAP系统，HTAP系统可以简化集成并提供更实时的信息。

云数据库

云计算对于数据库销售模式的影响是革命性的，在架构实现上也产生了深远的影响，主要体现在存储方面，也就是存算分离的架构。除了更经济的存储成本，存算分离的松耦合架构还可以更方便的实现存储和计算的单独按需扩展，计算任务的重新分配和计算下推到存储（将查询推送到数据，而非将数据拉到查询）。存算分离，各自横向扩展，计算下推，2008年推出的Oracle Exadata已具备这些能力，正是这种趋势的极佳注脚。

最后，作者认为云数据库是“轮回”的极佳示例。一方面，上世纪70年代的大型机分时服务演变为云平台的大型分时服务；另一方面，随着“技术变革（更快的网络速度）和向云端迁移”，之前认为扩展性不佳的共享磁盘数据库又回归了。“由于企业正在将所有可能的东西迁移到云端，我们预计这种共享磁盘架构将主导 DBMS 架构。因此，我们预计未来不会再出现无共享架构。”

数据湖/湖仓

“云平台催生的另一个趋势是，从用于 OLAP 工作负载的单体式专用数据仓库，转向由对象存储支持的数据湖”。数据湖为关系型和非关系型数据提供了统一的基础架构，支持SQL和非SQL工作负载，这是理想的一面。另一方面，这种大一统的架构也带来了数据一致性，数据发现，版本控制和查询优化的挑战。

临别赠言

这一部分列举了过去二十年数据库分析得到的一些启示。我觉得不妨也算上第一篇论文的40年，因为作者也承认，“不幸的是，其中一些警告与 2005 年论文中的警告如出一辙”。

警惕来自大型非数据库供应商的数据库系统

作者提到了过去10年一个有趣的现象，科技公司倾向于自建数据库管理系统，然后作为开源系统发布，希望从外部用户那里获得“免费”的开发。这种现象的部分原因“归功”于许多公司的晋升路径偏向于开发新内部系统的工程师，即使现有工具已经足够。这种避免使用“非我发明”软件的趋势不禁让我想到《数字一点不老实》一书中提到的学术界的“不发表就淘汰”模式：一个科学家的价值取决于他发表了多少科学论文；而一个与之相关的惯例是，如果论文没有发现统计显著性，其被发表的可能性会大大降低，从而导致科学家们“揉捏”数据以使论文发表。

言归正传，作者想表达的是，“这种偏差导致许多缺乏数据库工程经验的团队承担了构建新系统的任务。当公司首次开源此类系统时，应该对其保持警惕，因为它们几乎总是不成熟的技术”。

不要忽视开箱即用的体验

功能性能非常重要，用户体验也不容忽视。例如开发人员和数据科学家无需先建表，即可快速地加载和分析数据。还有，数据库能否“自我驱动”，以简化数据库物理设计，模式设计和查询调优的负担。

以Oracle数据库为例，其支持一键式创建数据库，提供已更新补丁数据库容器（例如19.19），LiveLabs云上实验室，免费文档和丰富学习资源等。另外，Oracle自治数据库支持自动运行、自动保护、自动恢复，可以把运维人员从繁琐的管理任务中解放出来。

开发人员需要直接查询他们的数据库

ORM 是快速原型设计的重要工具，过去 20 年创建的大多数 OLTP 应用主要通过抽象层（ORM居多，其次是REST）与数据库交互。但它们通常会牺牲将逻辑推送到 DBMS 的能力，以换取与多个 DBMS 的互操作性。以上是作者的观点。

ORM是一个备受争议的领域，无论如何，iBatis、Hibernate这些开源框架使用非常普遍。我认为Martin Fowler在他的“ORM Hate”一文中的观点更加清晰和完整。

Martin Fowler认为，ORM 带来的许多挫败感都源于过高的期望。很多人把关系数据库视为“一个被关在阁楼里、无人问津的疯阿姨”，开发人员只想处理内存数据结构，数据库则交给 ORM 处理。Martin Fowler对于ORM的看法可以总结为3点：

ORM无法做到100%完美。存储数据的最佳方式永远不会与在代码中表示数据的最佳方式相同，这就是我们常听到的“对象关系阻抗不匹配”[xv]。
ORM 可以处理大约 80% 到 90% 的映射问题，一个可避免 80% 问题的框架是值得的。
必要时使用SQL。编写由关系数据库支持的应用程序就应该了解关系数据库的工作原理。这一点，Tom Kyte在其著作《Expert Oracle Database Architecture》中也提到过：不要将数据库视为你不需要理解的黑匣子，数据库是大多数应用程序中的关键部分。试图忽视它将是致命的。

AI/ML 对数据库的影响将是巨大的

这一部分，作者给出了三点意见。第一点，自然语言不会取代SQL。自然语言可能有助于构建探索性分析的初始查询，由于自然语言存在歧义和不精确性，这些查询应该暴露给类似仪表板的细化工具。

第二点，企业数据采用LLM（大语言模型）的速度将保持谨慎缓慢，其中主要的问题是LLM输出无法向人类解释。其次，LLM比传统机器学习需要更多的数据，企业通常无法将这些模型的训练数据（特别是财务数据）创建工作外包给不熟练的人员。

第三，AI/ML 辅助优化是提高数据库性能的有力工具，但它并不能消除对高质量系统工程的需求，也就是好的架构设计，好的代码实现，好的可观测性，大量测试与实战场景打磨等。

结语

两篇论文共涵盖了数据模型近60年的发展历史，而结论都是相同的：尽管有人一直试图取代关系模型和SQL，关系模型和SQL仍然是数据库管理系统的主流选择。同时，SQL 也得到扩展，吸收了其他模型的优秀思想。时光荏苒，尘埃也许尚未落定，但六十年的观察多少能提供一些借鉴，说明一些问题。

两篇文章的结尾，作者都提到了类似的话：“为了避免重蹈覆辙，我们应当从历史中汲取教训。站在前人的肩膀上，而不是站在他们的脚上，总是明智的”。这倒不是让我们否定一切新生事物，毕竟关系模型也是在不断地挑战中成熟和壮大的。我想作者的意思是，对于新的技术和观点，应该多从事实中寻找答案，而事实包括过去历史中的事实和当前深入研究得到的事实。观点是主观的，一时很难争论出谁对谁错；而事实是客观的，是可以证明真假的。

具体如何做，我想引用胡适先生在100多年前的文章《多研究些问题，少谈些“主义”》中的一段话：“凡是有价值的思想，都是从这个那个具体的问题下手的。先研究了问题的种种方面的种种的事实，看看究竟病在何处，这是思想的第一步工夫。然后根据于一生经验学问，提出种种解决的方法，提出种种医病的丹方，这是思想的第二步工夫。然后用一生的经验学问，加上想像的能力，推想每一种假定的解决法，该有什么样的效果，推想这种效果是否真能解决眼前这个困难问题。推想的结果，拣定一种假定的解决，认为我的主张，这是思想的第三步工夫。凡是有价值的主张，都是先经过这三步工夫来的”。

发表2024年论文时，Michael Stonebraker已81岁。老骥伏枥，志在千里，烈士暮年，壮心不已。文章的最后，作者说到：“我们中的一个人很可能在二十年后仍然活着，因此完全有理由相信自己会在2044年写出这篇论文的后续文章”。对此，我们坚信，并衷心的期待！

[i] 现为加州大学伯克利分校的计算机科学教授，研究数据库系统和计算机网络。

[ii]POSTGRES表示POST inGRES，表示基于Ingres进行提升。

[iii]卡内基梅隆大学计算机科学系数据库学副教授, 研究兴趣是数据库管理系统。

[iv]set-at-a-time是面向集合的；IMS和CODASYL都是record-at-a-time，即面向记录的。

[v]Codd最初是一位数学家

[vi]陈品山，华裔美籍计算机科学家和应用数学家。曾任卡内基梅隆大学教职。他因于1976年开发实体-关系模型而闻名

[vii]指schema last，传统的关系系统是schema first

[viii]ISO/IEC 9075-2:2023

[ix]联接，结构化查询语言 (SQL) 中的联接子句将一个或多个表中的列组合成一个新表

[x]Atomicity，Consistency，Isolation和Durability

[xi]Basically Available，Soft state，Eventually Consistent

[xii]ISO/IEC 9075-2:2016

[xiii]指SQL这样的声明式语言

[xiv]指Java、C、Python这样的过程式语言

[xv]Object–relational impedance mismatch

天启AI社区

GitCode 天启AI是一款由 GitCode 团队打造的智能助手，基于先进的LLM（大语言模型）与多智能体 Agent 技术构建，致力于为用户提供高效、智能、多模态的创作与开发支持。它不仅支持自然语言对话，还具备处理文件、生成 PPT、撰写分析报告、开发 Web 应用等多项能力，真正做到“一句话，让 Al帮你完成复杂任务”。

更多推荐