回到原点再出发2

文章信息

原文标题：What Goes Around Comes Around... And Around...
原文地址：https://db.cs.cmu.edu/papers/2024/whatgoesaround-sigmodrec2024.pdf
原文作者：Michael Stonebraker & Andrew Pavlo

摘要

二十年前，本文的一位作者联合发表了一篇论文，评论了过去 40 年间数据模型的研究和发展，发现尽管人们不断尝试提出新方案，关系模型和 SQL 仍然是数据库主流技术。SQL 从新方法中吸取了最好的思想。

我们重新审视问题，发现从 2005 年以来，相同的演进仍在继续。人们仍在试图提供比 SQL 或关系模型更好的方案，而关系模型持续占据数据模型的主导地位，同时 SQL 也不断扩展，从其他数据模型中汲取思想。我们认为未来这样的情况仍然存在，SQL 和关系型数据库的持续演进。我们还讨论了数据库的实现，指出关系系统的重大改进主要由硬件特性变化所致。

简介

2005年，本文的一位作者参与撰写了名为《回到原点再出发》的红色小册子，回顾了 20 世纪 60 年代以来主要的数据模型进展：

层级型（IMS）：1960 年代到 1970 年代
网络（CODASYL）：1970 年代
关系型：1970 年代到 1980 年代早期
实体-关系：1970 年代
扩展关系型：1980 年代
语义型：1970 年代到 1980 年代
面向对象型：1980 年代到 1990 年代
对象-关系型：1980 年代到 1990 年代
半结构型（XML）：1990 年代后期和 2000 年代

我们的结论是：具有扩展类型系统（对象-关系）的关系模型已经占据了市场的主导地位，其他模型都没有取得成功。尽管在 2005 年的今天，许多非关系型数据库仍然存在，但厂商已经将它们降级成维护模式，也再没有人用它们开发新应用。这样的持续存在更多是数据"粘性"的遗嘱，而非因为系统仍然具备能力。换句话说，目前仍有许多IBM IMS数据库运行，因为切换到现代数据库成本高昂且充满风险。但已经没有新公司愿意在 IMS 上建立新应用。

自从我们 2005 年的调查以来，数据库领域发生了很多变化。此时数据库已经从最初的处理商业数据扩展到处理几乎所有的数据，导致了 2010 年代初的"大数据"时代，以及当前将机器学习与数据库结合的趋势。

本文分析了近 20 年来数据库领域数据模型和查询语言的进展。我们将评论分成以下几个方面： (1) MapReduce系统 (2) 键值存储 (3) 文档数据库 (4) 列族/宽列 (5) 文本搜索引擎 (6) 数组数据库 (7) 向量数据库 (8) 图数据库 。

我们认为大部分背离了 SQL 或关系模型的系统都不会占据主导地位，往往只能服务小众市场。许多一开始大张旗鼓拒绝关系模型的系统（比如 NoSQL），现在为关系型数据库开放了类 SQL 接口。这些系统正在走向与关系型数据库的融合之路。同时，SQL 吸收了最好的查询语言思想，扩展对现代应的支持，与时俱进。

虽然关系模型的基本原理没有太大变化，关系系统的实现方法出现了巨大改变。本文的第二部分讨论了处理现代应用和硬件的数据库架构改进： (1) 列式存储 (2) 云数据库 (3) 数据湖/湖仓 (4) NewSQL (5) 硬件加速 (6) 区块链数据库 。其中一些是数据库实现方式的深刻改变，另一些只是基于错误假设的发展趋势。

最后我们讨论了关于下一代数据库的重要思考，提出了我们对未来数据库研究和商业发展的预期和评论。

数据模型和查询语言

在下面的讨论里，我们将数据库的数据模型和查询语言方面的研究和发展分为八个类别。

MapReduce系统

Google 在 2003 年建立了 MapReduce 框架，作为处理周期性网络爬虫数据的"专属方案"。那时 Google 缺乏数据库方面的专业知识，他们建立了 MapReduce 来满足爬虫数据处理需求。在数据库领域中，Map 是一个自定义函数，用来执行计算和过滤。而 Reduce 是 GROUP BY 操作。粗略的说，MapReduce 执行了一个查询：

复制代码

SELECT map() FROM crawl_table GROUP BY reduce()

Google 的 MapReduce 方法没有限定数据模型或查询语言，一切由 Map 和 Reduce 函数决定。它们是过程式 MapReduce 程序的中函数，用来解析和理解数据文件内容。

在 2000 年代后期，很多公司对MapReduce系统感兴趣。雅虎在 2005 年开发了一个MapReduce的开源版本，叫做 Hadoop。它运行在分布式文件系统 HDFS 之上，HDFS 是 Google 文件系统的仿制品。市场上出现了几家新公司，为 Hadoop 提供商业支持。我们使用 MapReduce 表示 Google 开发的系统，用 Hadoop 表示开源版本，二者的功能相似。

与专门为 OLAP 负载设计的关系型数据库系统相比，Hadoop 的价值存在争议。2009 年的一项研究将争议推向高潮。这项研究表明数据仓库比 Hadoop 性能更好，引发了 Google 和数据库社区的文章交锋。Google 认为，通过精心的工程设计，MapReduce 系统可以战胜数据库，用户不需要在执行查询前加载具有模式的数据。MapReduce 更适合"一次性"任务，比如文本处理和 ETL 操作。数据库社区认为 MapReduce 设计存在性能问题，这在现有的并行数据库中已经解决。实践表明，使用高级语言（SQL）操作分区表的方法，是一种好的编程模型。

这两篇论文中有很多关于实现细节的讨论（例如，索引、解析、推拉查询处理、故障恢复）。通过阅读这两篇文章，可以得到一个合理的结论：两类系统都有自己的一席之地。然而科技界的两个变化让辩论失去意义。

第一件事，Hadoop 技术和服务市场在 2010 年代发生暴跌。很多企业在 Hadoop 集群上花了大钱，但发现功能效益有限。开发人员发现很难将应用硬塞进存在严格限制的 MapReduce/Hadoop 范式。人们进行了大量工作，在 Hadoop 上提供 SQL 和关系模型接口。做的最好的是 Meta 公司的 Hive。

另一件事发生在 CACM 文章发表的 8 个月之后，Google 宣布将爬虫处理过程从 MapReduce 迁移到 BigTable。因为 Google 需要实时交互更新爬虫数据库，而 MapReduce 只是一个批处理系统。谷歌最终在 2014 年宣布 MapReduce 已经丧失了在他们技术栈中的位置，终结了 MapReduce 系统。

第一次事让三大 Hadoop 厂商（Cloudera, Hortonworks, MapR）没有可用的产品进行销售。Cloudera 调整了品牌战略，用 Hadoop 代表整个堆栈（应用、Hadoop、HDFS）。Cloudera 耍了一个花招，在 HDFS 上建立了关系型数据库 Impala，但没有使用 Hadoop。他们意识到 Hadoop 无法作为 SQL 数据库的内部接口，他们将 Hadoop 移出技术栈，直接在 HDFS 上构建软件。类似地，MapR 在 HDFS 上建立了 Drill，Meta 创建了 Presto 取代 Hive。

讨论：MapReduce 的缺陷太明显了，即使开发社区的接纳和热情也无法挽救它的命运。Hadoop 十年前已经死了，留下的遗产包括企业中 HDFS 集群和一些试图从 MapReduce 中赚钱的公司。如今 HDFS 也失去了光彩，企业已经意识到存在更好的分布式存储系统。与此同时，分布式关系型数据库正在蓬勃发展，特别是在云计算领域。

MapReduce 系统实现中与可伸缩性、弹性和容错性相关技术被移植到分布式关系型数据库系统中。MapReduce 还带来了具有分离式存储的共享磁盘架构的复兴，并随即引发了开源文件格式和数据湖。Hadoop 的局限性为其他数据处理平台，比如 Spark 和 Flink，开了大门。它们最初都是使用过程式 API 的 MapReduce 系统实现，但随后都增加了 SQL 支持。

键值存储

键值数据模型是最简单的模型，它表示下列二元关系：

复制代码

（键，值）

键值数据库将一组数据表示成从键映射到值的关联数组。值通常是无类型的字节数组，比如 blob。数据库并不关心值的内容，用用负责维护数据模式和解析数据。大部分键值数据库值提供单个值的读、写、删除操作。

在 2000 年代，几家新互联网公司建立了自己的分布式无共享键值存储，用于特定应用，比如缓存和存储会话数据。对于缓存，Memcached 是最著名的例子。Redis 将自己定位成 Memcached 替代品，提供了更强大的查询 API 和检查点功能。对于存在一定持久性要求的数据，亚马逊在 2007 年创建了 Dynamo 键值存储。与关系型数据库相比，这样的系统提供了更好、更容易预测的性能表现，代价是功能受到限制。

第二类键值数据库是嵌入式存储管理器，与上层应用运行在同一个地址空间中。最早的独立嵌入式键值数据库之一是 1990 年代初的 BerkeleyDB。近期值得注意的有谷歌的 LevelDB。后来 Meta 在其基础建立了 RocksDB。

讨论：键值存储为开发者提供了便捷的"开箱即用"方式存储数据，不像关系型数据库那样需要设置表。

在需要多个二元关系的复杂应用中使用键值存储是危险的。如果应用需要记录包含多个域，键值存储大概是个糟糕的选择。不仅因为应用需要解析记录，而且缺少二级索引根据值对其他域进行检索。还有开发者必须在应用中实现连接或多记录读取操作。

为了解决这些问题，一些系统从键值存储开始，演变成功能丰富的记录存储。这些系统将二进制数据替换成半结构化值，比如 JSON 文档。亚马逊的 DynamoDB 和 Aerospike 就是例子。重新设计键值存储以支持复杂数据模型并非易事，而关系型数据库则无需任何改变就能轻松模拟键值存储。如果应用需要嵌入数据库，已经有了功能齐全的选择，包括 SQLite 和 DuckDB。即使对于简单应用，关系型系统数据库大概也是更好的选择，它们提供了应用向复杂系统发展的道路。

过去20年的架构趋势是使用嵌入式键值存储作为全功能数据库的底层存储管理器。以前，开发一个新的数据库首先要建立一个集成在数据库中的自定义存储管理器。MySQL是首个公开接口，允许开发者替换默认存储管理器的数据库。有了这些接口，Meta可以建立RocksDB，在其庞大的MySQL集群中取代InnoDB。同样的，MongoDB在2014年放弃了他们基于mmap的存储管理器，开始使用WiredTiger存储管理器。使用成熟的键值存储让开发者可以用更少的时间开发出新数据库。

文档数据库

文档数据模型将数据库表示为记录对象集合。文档包含具有层次结构的键值对。域由名字标识，值可以是标量类型、数组或文档。下面的JSON示例是关于一位客户的文档，包含内嵌的采购订单列表和相应的订单项。

复制代码

{ "name": "First Last",
  "orders": [ { "id": 123, "items": [...] },
              { "id": 456, "items": [...] }, ] }

近几十年来，文档数据模型一直是活跃领域，产生了像SGML和XML的数据格式。尽管1990年代末出现了XML数据库热潮，我们在2005年准确地预测出它们不会取代关系型数据库。JSON已经取代XML，成为Web应用数据交换标准。JavaScript在开发者中开始流行，JSON变得无处不在。一些公司在2000年代创建了面向文档系统，支持本地存储JSON。

在2000年代，由于OLTP数据库无法水平扩展，市场上出现了很多文档数据库，使用NoSQL作为宣传口号。它们提出的两个营销信息引起了开发者的共鸣。首先，SQL和连接速度缓慢，开发者使用快速的底层"逐记录"接口。其次，现代应用不需要ACID事务，数据库应该提供更宽松的约束（即BASE）。出于这两方面的推动，NoSQL成为一种代表，即使用JSON存储记录或文档，支持底层API，不支持事务或只提供微弱的事务支持。这样的系统有很多，最受欢迎的时MongoDB。

讨论：文档数据库在本质上和1980年代的面向对象数据库、1990年代末的XML数据库是相同的。文档数据库的支持者提出的观点与支持面向对象数据库、XML数据库的前辈相同：将数据存储为文档可以避免应用代码和关系型数据库交互时产生的对象失配问题。

他们还说：取消范式，将记录保存在嵌套结构中性能更好，因为避免了获取关联数据时的多次查询（即ORM中的N+1问题）。取消范式使用预先连接的方法，是一个古老的话题，可以追溯到1970年代：(1) 如果连接不是"一对多"的，将会存在重复数据；(2) 预先连接不一定比连接快；(3) 缺乏数据独立性。

虽然存在着"SQL很糟糕"的强烈抗议，在2010年代末，几乎所有的NoSQL数据库都添加了SQL接口。著名的例子包括DynamoDB PartiQL、Cassandra CQL、Aerospike AQL和Couchbase SQL++。最后的抵抗者是MongoDB，但在2021年，他们为自己的Atlas服务添加了SQL支持。NoSQL厂商声称他们从SQL派生出专有的查询语言，替代SQL标准中的DDL和DML操作。对于大多数应用，这种差异是没有意义的。SQL和NoSQL派生语言之间的差异主要在于JSON扩展和数据维护操作。

目前许多NoSQL数据库都添加了强一致性（ACID）事务。由此NoSQL的表示的含义已经从"不要SQL------它太慢了！"变成了"不只是SQL（SQL有时也不错）"。

在NoSQL数据库中增加SQL和ACID，拉近了它们和关系型数据库在功能上的距离。二者的主要区别变成了对JSON的支持，以及NoSQL厂商允许"模式后置"数据库。SQL标准在2016年增加了JSON数据类型和操作。随着关系型数据库不断改善开发者首次使用的体验，我们相信两类系统很快会变得完全相同。

高阶语言比"逐记录"操作更受欢迎。它们需要更少的代码，提供了更好的数据独立性。我们必须承认一开始SQL优化器缓慢低效，但在过去的50年里，已经得到极大改进。优化器是开发数据库工作中最困难的部分。我们猜测这个工程难题是NoSQL系统最初选择不支持SQL的原因之一。

列族数据库

还有一类NoSQL系统使用列族（也叫做宽列）数据模型。虽然名字包含"列"字，但它不是列式存储模型，而是文档数据模型的简化版。列族只支持一层嵌套，不支持多层嵌套；列族类似于二维表，记录可以拥有可选属性，一个单元格可以包含多个值。下面的例子展示了从用户标识到用户资料JSON文档的映射。

复制代码

User1000 -> { "name": "Alice",
              "accounts": [ 123, 456 ],
              "email": "xxx@xxx.edu" }
User1001 -> { "name": "Bob",
              "email": [ "yyy@yyy.org", "zzz@zzz.com" ] }

首个列族数据库是Google在2004年推出的BigTable。Google没有采用SQL和列式存储，而是通过过程式API访问数据模型。一些系统采用列族模式，试图复制Google的实现。最突出的是Cassandra和HBase。当然它们同样复制了BigTable的局限性：缺少连接和二级索引。

讨论：我们在2.3节中关于文档模型的评论也适用于列族数据库。在2010年代初，Google以BigTable为基础建立了关系型数据库，包括MegaStore和Spanner第一版。后来Google重写了Spanner，删除了BigTable。现在Spanner是许多Google内部应用的主数据库。一些NoSQL数据库放弃了专用API，转而使用SQL，同时保留了非关系型架构。Cassandra用一种类SQL语言------CQL取代了Thrift-API，HBase也推荐使用Phoenix SQL前端。Google仍然提供BigTable云服务。列族模型是一个特例，具有和NoSQL数据库一样的缺点。

文字搜索引擎

文本搜索引擎已经存在很长时间，1960年代，具有开创性的SMART系统出现。SMART是信息检索和向量空间模型技术的先驱，这两项技术在现代搜索引擎中普遍存在：将文档分切成"词汇包"，再利用词汇建立全文索引（也叫做反向索引），以支持查询文档内容。这个系统还能识别词汇噪音（如："那个"、"一个"）、同义词（如："大苹果"通常表示"纽约市"）、显著关键词和词汇位置距离（如："干旱"经常出现在"气候变化"附近）。

目前领先的文本搜索系统有Elasticsearch和Solr，它们都使用Lucene作为内部搜索库。这些系统为存储和索引文本数据提供了良好支持，但没有或只有少量事务能力。这样的限制意味着数据库从数据损坏中恢复时，必须从头开始重建文档索引，这将引发长时间停机。

所有领先的关系型数据库都支持全文检索索引，包括Oracle、Microsoft SQL Server、MySQL和PostgreSQL。它们的搜索功能得到了改进，与专用系统几乎不相上下。它们还具有内置事务支持的优势。但是它们在SQL中集成搜索操作的方法往往是笨拙的，并且每个数据库都不同。

讨论：文本数据本质上是非结构化的，即没有数据模型。数据库尝试从文本中提取结构（如：元数据、索引），避免"大海捞针"式的顺序搜索。在应用中有三种方法管理文本数据。第一，可以运行多个系统，例如使用Elasticsearch处理文本，使用关系型数据库处理操作型工作负载。这种方法可以使用同一类型中的最佳系统，但需要额外的ETL管道，将数据从操作型数据库推送到文本数据库，需要重写应用，根据需求将查询路由到正确的数据库。第二，可以运行具备文本搜索功能的关系型数据库，但在SQL中使用两套API。一些应用框架（如：Django Haystack）可以解决多套API带来的复杂度增加的问题。第三种选择是多态存储系统，通过中间件屏蔽系统差异，对外暴露统一接口。

基于SMART，以倒排索引为中心的搜索引擎用于精确匹配搜索。近年来，这种方法已被使用机器学习生成词嵌入的搜索所取代。

数组数据库

在很多计算领域中，数组是一种常用的数据表示方法。我们使用"数组"一词表示它的所有变种：向量（一维）、矩阵（二维）和张量（三维或多维）。例如，关于地理区域的科学调查通常将数据表示为多维数组，使用位置和时间坐标存储传感器测量数据。

复制代码

（纬度，经度，时间，[值向量]）

其他一些数据集也差不多，包括基因组测序和计算流体动力学。数组也是大多数机器学习数据集的核心。

尽管基于数组的编程语言从1960代就出现了（APL），但数组数据库的工作却是从1980年代开始的。PICDMS被认为是首个使用数组数据模型的数据库。目前仍然活跃的两个古老的数组数据库是Rasdaman和kdb+。新的数组数据库包括SciDB和TileDB。HDF5和NetCDF是科研数据常用的数组文件格式。

存储和查询现实世界中的数组数据集存在几个困难。最重要的是，数组数据并非总是对齐到规范下标。例如，地理空间数据数组通常被分割成不规则的形状。应用可以根据元数据将不规则下标映射到整数坐标。应用往往需要在单个数据库中同时维护数组和非数组数据。

与基于行或列的数据库不同，在任意维度查询数组数据带来了特有的难题。难点在于将多维数组数据存储在类似磁盘的线性物理存储介质上。要解决这个难题，数组数据库必须使用索引和数据结构支持高效的跨维度遍历。

讨论：数组数据库是一个小众市场，只在特定的垂直领域内使用（我们后面将讨论向量数据库）。它们在基因组领域有很大吸引力，HDF5在卫星图像和其他网格化科学数据中很受欢迎。但是业务处理应用很少使用专用数组数据库，而这正是数据库产品能够存活所必需的。没有哪个重要的云服务商提供托管数组数据库服务，表明他们认为这不是一个大市场。

数组数据库厂商一直面临的问题在于，SQL包含将有序数组作为基础数据类型的支持（尽管这与最初的关系模型存在冲突）。首个建议将基于无序集合的关系模型扩展到包含有序二维表的方案出现在1993年。早期的例子是Illustra的时序（一维）数据插件。SQL:1999引入了对一维定长数组数据类型的部分支持，SQL:2003扩展到无预设最大基数的嵌套数组。市场上的参与者包括Oracle Georaster和Teradata。数据立方体是特定用途数组，列式存储数据库因为更好的灵活性和更低的工程成本，让数据立方体在OLAP领域黯然失色。

最近SQL:2023标准包含了对多维数组（SQL/MDA）的支持，这在很大程度上受到Rasdaman的RQL的启发。新标准允许SQL使用基于整数的坐标表示任意维度数组。实际上，这让数据立方体可以出现在SQL框架中。目前数据立方体市场由列式存储数据库主导。

向量数据库

如同列族模型是文档模型的简化版，向量数据模型将数组数据模型简化为一维栅格。考虑到当前向量数据库受到了开发者和投资者最多的关注（类似于NoSQL热潮），有必要单独讨论它们。受关注原因在于开发者使用向量数据库存储AI工具生成的一维嵌入。这些工具使用经过训练的翻译方法，将原始数据（例如，文本、图像）转换成表示其潜在语义的向量。例如使用Google BERT将维基百科文章转换为嵌入，与文章的元数据一同存储在向量数据库中：

复制代码

（标题，日期，作者，[嵌入向量]）

嵌入向量的长度，从简单转换器架构的100维到高端模型的1000维不等。随着时间发展，更复杂的模型将会出现，嵌入向量维度也会随之增加。

向量数据库和数组数据库的核心区别在于查询模式不同。向量数据库的设计目标是在高维空间中搜索与输入向量距离最短的记录。输入向量是使用同一个转换器生成的另一个嵌入。和数组数据库不同，应用不会在向量数据库中从某个偏移量开始匹配向量，也不会从若干个多维向量中提取切片。向量数据库的主要用途是相似性搜索。

在搜索最接近记录时，为避免全表扫描，向量数据库建立索引加速近似最近邻居（ANN）搜索。应用在进行查询时会提交关于嵌入索引和非嵌入属性（即元数据）的谓词。数据库择机在向量搜索之前或之后，使用非嵌入属性谓词过滤记录。

这个新兴的类别中有许多新数据库，其中Pinecone、Milvus和Weaviate较为领先。Elasticsearch、Solr和Vespa等文本搜索引擎扩展了自己的API，支持向量搜索。也有些数据库将自己重新定位成向量数据库，跟随潮流。比如kdb+。

向量数据库有一个引人注目的特点：和关系型数据库相比，向量数据库和AI工具（如ChatGPT、LangChain）的集成更好。向量数据库允许在插入时将记录数据转换为嵌入，在查询时使用同一个转换器，将查询参数转换为嵌入，执行ANN搜索。其他数据库需要应用在数据库外部执行转换。

讨论：数组数据库需要自定义存储管理器和执行引擎来支持对多维数据的高效操作，而向量数据库本质上是带有专用ANN索引的面向文档数据库。ANN索引时一个特性，不是系统架构基础。

在llm在2022年末成为ChatGPT的"主流"之后，几个rdbms花了不到一年的时间添加了自己的向量搜索扩展。2023年，许多主要的rdbms都增加了矢量索引，包括Oracle[7]、SingleStore[137]、Rockset[8]和Clickhouse[157]。将此与rdbms中的JSON支持进行对比。像MongoDB和CouchDB这样的NoSQL系统在2000年代后期开始流行，rdbms花了几年时间才增加对它的支持。

自从2022年底，ChatGPT等大模型成为主流。不到一年之内，多个关系型数据库添加了向量搜索扩展。在2023年，大部分主要数据集增加了向量索引，包括Oracle、SingleStore、Rockset和Clickhouse。与关系型数据库对JSON的支持相比，2000年代末，MongoDB、CouchDB等NoSQL系统开始变得流行，但是关系型数据库花费了几年时间才支持JSON。

向量索引快速发展的原因大概有两个：首先，利用嵌入进行相似性搜索是非常引人注意的场景，数据库厂商迅速开发出新版本并立即宣布。第二个原因是引入新的索引数据结构，在工程上工作量很小。数据库厂商添加向量搜索特性并不需要太多工作。大部分厂商没有从头开始编写向量索引，而是集成开源库（如pgVector、DiskANN、FAISS）。

我们预测向量数据库将经历和文档数据库一样的演化道路，随着新特性的加入，变得越来越像关系型（如SQL、事务、可扩展性）。与此同时，关系型数据库在长长的特性清单中新增向量索引，然后转向下一个新兴趋势。

图数据库

过去十年图形数据库在学术界和工业界收到了大量关注。许多应用使用知识图谱对半结构化数据建模。社交媒体应用本身就包含面向图的关系（"喜欢"、"...的好友"）。关系设计工具为用户提供了数据库的实体关系（ER）模型。ER模型就是一个图，因此图数据库有着清晰的使用场景。

最流行的两种表示图的方法是：资源描述框架（RDF）和属性图。使用属性图的数据库维护一个有向的多图结构，节点和边都有键值标签。RDF数据库（也叫做三元存储）只支持边带有标签的有向图。属性图更常见，并且是RDF的超集，所以我们只讨论属性图。我们考虑了图数据库的两个使用场景，讨论了限制图数据库广泛应用的问题。

第一类系统用于操作型或OLTP工作负载：例如，应用更新单条记录（可能使用事务），向数据库中添加好友关系。Neo4j是OLTP应用中最流行的图数据库，它通过指针提供对边的支持（如同CODASYL），但没有将节点与父节点或子节点聚集在一起。这个架构对于遍历长边链条是有利的，可以使用指针跟踪。而关系型数据库则必须使用连接执行操作。这类系统能否在市场上取得成功，取决于是否有足够多的"长边链条"场景，值得放弃关系型数据库。

第二个场景是分析：尝试从图中搜索深层信息。此场景的一个例子是年龄在30岁以下的，拥有最多好友的用户。值得注意的数据库有Tigergraph和JanusGraph，它们专注于图数据库的查询语言和存储。其他系统，比如Giraph和Turi（以前叫做Graphlab）提供了一个计算结构，允许用户编写的面向图的程序并行执行。

关系型分析查询的特征由连接链条决定。图分析查询不一样，它的操作包含最短路径、割集或搜索团。算法和数据表示决定数据库性能。这一事实建议系统采用允许开发者在抽象层上编写算法的架构，抽象层要屏蔽底层系统拓扑结构。然而，根据以前的研究成果，分布式算法很少优于单节点算法，通信成本太高。更好的策略是将图压缩成适合单节点内存的空间优化结构，在这个结构上执行查询。除了超大规模图数据库外，这也许是图数据库的最佳处理方式。

讨论：无论图数据库的目标是OLTP还是OLAP工作负载，它们必须克服一个关键难题，即关系型数据库可以作为存储图的一个选项，因为图可以通过一组表来模拟：节点（节点标识，节点数据）、边（节点1标识，节点2标识，边数据）。但是"普通"的SQL不足以表达图查询，因此在遍历图时，需要进行多次客户端-服务端通信。

一些关系型数据库（如SQL Server和Oracle）提供了内置SQL扩展，让存储和查询图数据更方便。另一些数据库在关系操作之上添加一个转换层来支持图查询API。Amazon Neptune是Aurora MySQL上的图查询转换层。Apache AGE在PostgreSQL上提供了OpenCrypt接口。

最近SQL:2023引入了属性图查询特定（SQL/PGQ），用于定义和遍历关系型数据库中的图数据。这个语法基于现有语言（如Neo4j的Cypher，Oracle的PGQL和TigerGraph的GSQL）建立，吸收了新出现的GQL标准的一些内容。SQL/PGQ进一步缩小了关系型护具看和原生图数据库之间的功能差异。

图数据库厂商是否能够让他们的专用系统性能足够克服上述缺点？多项性能研究表明，在关系型数据库上的模拟图的方法比图数据库性能更好。最近的研究表明，DuckDB中SQL/PGQ的性能是某个领先的图数据库的10倍。随着关系型数据库图查询的最坏情况下最优连接和分解执行算法的持续改进，这种趋势将继续下去。

总结

从上一节可以得出一个合理的结论：非SQL、非关系型系统要么是一个小众市场，要么迅速发展成为SQL/关系型系统。具体地说:

MapReduce系统 它们在几年前已经过时了，目前最多算是一项遗留技术。
键值存储 一些发展成关系型系统，另一些仅用于特定问题。现代高性能关系型数据库可以替代键值存储，甚至做得更好。
文档数据库 这些NoSQL系统会和关系型数据库存在重叠。随着时间推移，两种系统间的差异逐渐减少，未来将会变得几乎没有区别。
列族：仍是一个小众市场。如果不是因为谷歌，本文不会讨论这个类别。
文本搜索引擎 这些系统用于多态存储架构中的文本字段。如果关系型数据库有更好的搜索方案，那么文本搜索引擎就不需要作为独立产品而存在了。
数组数据库 科学应用仍会继续忽略关系型数据库，倾向于使用定制的数组系统。数组数据库可能变得更加重要，尽管有新兴的SQL/MDA改进，关系型数据库仍然不能有效的存储和分析数组。
向量数据库 它们是单一用途数据库，带有快速最近邻居搜索索引。关系型数据库应该很快就会利用可扩展类型系统，提供对这类数据结构和搜索方法的原生支持。这将让这类专用系统变得不重要。
图数据库 OLTP图应用将主要由关系型数据库提供服务。分析型图应用存在特定需求，最好使用专用数据结构在主存中完成计算。关系型数据库将封装SQL，或通过扩展提供以图结构和中心的API。我们不认为专用图数据库会有很大的市场。

此外，一些方案把旧模型包装成新产品。例如图-关系模型和语义数据模型是一样的，文档-关系模型是带有外键的文档模型。其他方案则是在关系型数据库上增加了非SQL层（例如PRQL、Malloy）。尽管这些语言解决了SQL的一些缺点，但还不足以动摇SQL深厚的用户基础和生态。

系统架构

在过去的二十年里，数据库体系结构中出现了一些重要的新思想，反映出应用和硬件特性变化。有些思想妙极了，有些则存在疑问。我们将依次讨论这些思想。

列式存储

为了理解列式数据库的吸引力，我们需要解释数据仓库（OLAP）市场的起源。在1990年代中期，企业开始收集面向客户（销售）的数据。实体零售商（如沃尔玛）在构建历史销售数据库方面走在了前列。这些公司普遍发现，由于提供了更好的库存订购和轮换决策，销售数据仓库可以在六个月内收回成本。这种面向客户的数据库目前在企业中普遍存在。

数据仓库应用的共有特点与OLTP工作负载截然不同：

它们实质上是历史数据（即周期性加载只读数据）。
公司会保留全部数据，只要存储成本允许------数据可能达到TB或PB级。
查询通常只访问表的一小部分属性，并且查询是临时性的。

Ralph Kimball是数据仓库星型模式较早的支持者。星型模式的思想是构造事实表，保存商品级别的交易数据。典型的例子是用事实表保存零售企业销售的每一项商品的记录，然后用围绕在事实表周围的多个维度表，记录事实表中的公共信息，节省空间。在零售场景中，维度表将包括有关客户、产品、商店和时间的信息。

按照列而非行的方式组织数据库存储有许多好处。首先，压缩列数据比压缩行数据效率更高，数据块中只有单一值类型，通常会有许多重复字节。其次，火山风格引擎逐行执行操作符，相反，面向列的引擎使用内部循环，通过矢量化指令处理整个列。最后，行存储中每条记录都有很大的头部（例如20字节），记录空值和版本控制元数据，而列存储中每条记录的存储开销最小。

讨论：在过去的二十年中，所有活跃的数据仓库厂商都将的产品从行存储转换为列存储。这种变化给数据库设计带来了重大改变。此外，这二十年中有一些新厂商进入市场，提供列式存储产品，例如亚马逊的Redshift和谷歌的BigQuery，以及其他一些公司的产品（例如Snowflake）。

总之，列存储是具有专门的优化器、执行器和存储格式的新型数据库实现方式。以其卓越性能占领了数据仓库市场。

云数据库

2000年后期云平台的兴起极大地影响了数据库的实现方式（和销售模式）。最初云数据库产品将本地部署系统封装到具有直连存储的托管虚拟机中。但在过去的20年里，网络带宽的增长速度远远快于磁盘带宽，让网络附属存储（NAS）成为直连存储的一个有吸引力的备选方案。这引起了对云环境下数据库体系结构的深刻反思。

所有主要的云厂商都提供了带有对象存储（例如亚马逊S3）和一些管理功能（例如复制、过滤）的网络附属存储。与直连存储相比，除了有好的经济性外，对象存储还有其他优势可以弥补网络连接成本。首先，计算节点与存储节点分离，系统可以为单个查询提供弹性扩展；数据库可以动态添加新计算节点，不需要改动数据分布。它还允许数据库存储节点和计算节点使用不同的硬件。其次，数据库可以在空闲时为计算节点分配其他任务。而在无共享数据库中，节点必须保持在线，以处理查询请求。最后，可以将计算下推到存储节点（通常是有利的）。这种执行策略叫做"将查询推送到数据"而不是"将数据拉取到查询"，已经在数据库领域得到广泛理解。

前两种思想叫做"无服务器计算"，由Snowflake为云原生数据库引入的。其他厂商已经或正在将他们的云产品迁移到无服务器环境。要充分利用这个模型，需要一个托管的多节点环境，多个数据库客户被集中到具有多租户执行模式的同一组节点上。

讨论：云数据库的出现是"重回原点"的另一个例子。多节点共享磁盘数据库是一个古老的思想，从历史上这个思想效果不佳。然而随着技术革新（更快的网络）和迁移到云环境的趋势，它又重新流行起来。此外，分时服务在1970年代很流行，当时电脑又大又贵。云平台是一个大型分时服务，这个概念也在几十年后回归。由于企业正在将一切可能的东西迁移到云环境，我们预计这种共享磁盘模式将主导数据库体系结构。我们认为将来不会出现无共享架构。

云环境经深刻地影响了数据库，导致数据库架构被完全重组。计算从本地迁移到云端的过程，为企业提供了难得的机会来重构代码库，消除历史上的技术债务。云环境还为厂商提供了本地部署不支持的一些便利。最重要的是，厂商可以跟踪所有客户的使用趋势：监控意外行为、性能下降和使用模式。此外，他们推送增量更新和代码补丁，而不会中断服务。

从业务角度来看，开源数据库面临由于过于流行而被主要云提供商过度商业化的危险。亚马逊和MongoDB、Elasticsearch等独立软件开发商之间的公开争论就是典型的例子。

数据湖/湖仓

云平台引发的另一个趋势是企业从面向OLAP工作负载的单一专用数据仓库转向基于对象存储的数据湖。使用传统的数据仓库时，企业需要把数据加载到数据库中，系统将数据存储在专属格式托管存储中。厂商把数据库看作时企业全部数据的"看门人"。然而在过去的十年中，这并不是许多企业的运营模式，特别是技术公司。

使用数据湖架构，应用将文件上传到分布式对象存储，绕过数据库传统的访问路径。然后用户使用湖仓执行引擎，对累积的文件进行查询和流水线处理。湖仓系统提供了支持SQL和非SQL的统一基础设施。后一点非常重要，过去的十年表明，数据科学家和机器学习从业者通常使用基于Python的草稿本应用，通过Panda DataFrame接口（而非SQL）访问数据。一些项目利用数据库方法优化DataFrame处理，包括Dask、Polars、Modin和Bodo。

应用不再使用数据库专属文件格式或低效的文本文件（例如CSV、JSON），而是使用开源磁盘文件格式，将数据写入数据湖。最流行的两种是Twitter/Cloudera的Parquet和Meta的ORC。它们都借鉴了早前的列式存储技术，如PAX、压缩和嵌套数据（JSON）拆分。Apache Arrow是一个类似的二进制文件格式，用于在系统间交换内存数据。读写这些格式的开源库支持应用独立创建数据文件，再由其他系统解析和使用，加强了跨服务和业务单元的数据共享。

讨论：数据湖是2010年代早期"大数据"运动的继承者，MapReduce系统和列存储的广泛应用在一定程度上引领了数据湖。乍看起来，数据湖对企业来说是个糟糕的想法：允许任何应用程序在没有治理的情况下，将任意文件写入集中式数据仓库，这会引发完整性、数据发现和版本控制问题。湖仓为这些环境提供了必要控制，通过元数据、缓存和索引服务，缓解了许多问题。一些中间件可以跟踪新数据，提供事务性更新，如Delta Lake、Iceberg和Hudi，让湖仓看起来像是传统数据仓库。

数据湖给查询优化带来了新难题。数据库一直难以获取数据的精确统计信息，往往无法选择最佳查询计划。然而数据湖可能完全没有新数据文件的统计信息。为了让数据库可以根据已感知数据特征，在执行过程中动态修正查询计划，有必要在云环境中引入自适应查询处理策略。

所有主要的云服务商都提供某种形式的托管数据湖服务。基于对象存储的数据湖存储成本远低于专有数据仓库，传统的OLAP厂商（例如Teradata、Vertica）对现有的数据库进行扩展，支持从对象存储中读取数据，以此应对价格压力。此外还有几个独立系统也活跃在这个领域，包括Databricks、Dremio、PrestoDB和Trino。

NewSQL系统

2000 年代晚期，市场出现了多种分布式 NoSQL 数据库管理系统，它们的设计目标是能够横向扩展，支持拥有海量并发用户的在线应用 [110]。然而许多组织无法使用这些 NoSQL 系统，因为他们的应用不能放弃强事务需求。而当时的关系型数据库管理系统（特别是开源产品）无法（原生）实现跨机器的扩展。为此 NewSQL 系统在 2010 年代早期应运而生，尝试为 OLTP 工作负载提供与 NoSQL 同样的扩展性，同时继续支持 SQL [95, 171]。换言之，这些新系统试图实现 2000 年代 NoSQL 数据库的扩展能力，并保留 1990 年代传统数据库的关系型模型和 ACID 事务特性。

NewSQL 系统主要分为两大类别。第一类是内存数据库管理系统，包括 H-Store [144, 189]（其商业化版本为 VoltDB [83]）、SingleStore [69]、微软 Hekaton [128] 以及 HyPer [146]。其他初创企业的产品则包括面向磁盘的分布式数据库管理系统，如 NuoDB[47] 和 Clustrix[17]。

讨论：NewSQL 数据库管理系统至今尚未获得大规模普及 [96]。这种遇冷现象的主要原因是现有数据库已足够满足需求，这意味着各个组织不愿承担将现有应用迁移到新技术的成本与风险。企业在更换 OLTP 数据库时，会比更换 OLAP 数据库更加厌恶风险------如果 OLTP 数据库发生故障，公司将无法执行带来收入所需的事务处理；相比之下，OLAP 数据库故障可能只是给分析师或数据科学家带来暂时的不便。

NewSQL 数据库还存在其他一些限制，例如仅支持标准 SQL 的子集，或在多节点事务上表现不佳。部分 NewSQL 产品（如微软的 Hekaton）仅作为传统数据库的扩展提供，导致快速引擎不得不通过较慢数据库的接口进行交互。

NewSQL 厂商曾错误地预测内存数据库在过去十年会获得广泛应用。实际上，闪存厂商正在不断提升存储密度和带宽、降低延迟的同时，也压低了成本。高昂的 DRAM 成本及持久内存（如英特尔傲腾）的没落，意味着 SSD 仍将在 OLTP 数据库领域保持主导地位。

NewSQL 的发展催生了一批新型分布式事务型 SQL 关系数据库，包括 TiDB [141]、CockroachDB [195]、PlanetScale [60]（基于 Vitess 分片中间件 [80] 开发）以及 YugabyteDB [86]。与此同时，主流 NoSQL 厂商在过去十年中也纷纷为自身系统添加了事务支持，尽管他们此前曾坚称事务功能并非必需。实现这一转型的知名数据库包括 MongoDB、Cassandra 和 DynamoDB。这显然是源于客户对事务功能的实际需求。谷歌在 2012 年通过 Spanner 放弃最终一致性、转向实时事务时，就清晰阐明了这一点 [119]。

硬件加速器

过去 50 年间，业界一直在寻找便宜的数据管理系统硬件加速方案。其前景显而易见：专为数据库系统设计的硬件理应轻松超越传统 CPU 性能。

在 1980 年代，厂商曾通过定制硬件加速数据库系统，并作为"数据库机器"推向市场 [107]。Britton-Lee 在 1981 年发布了首个商用加速器产品（IDM/500）[192]，该系统在传统 CPU 基础上搭载了执行查询任务的硬件加速器。但该加速器仅针对一小部分执行路径，且效益不佳。Teradata 推出的数据库机器提供用于实时元组排序的网络硬件（Y-net [1]），但最终仍被纯软件方案取代 [85]。整个 1980 年代，所有其他定制硬件加速方案均告失败。

近 20 年来，行业不再构建定制硬件，而是转向采用商用硬件（FPGA、GPU）加速查询。这个思路颇具吸引力：厂商无需承担硬件制造成本即可获得数据库加速收益。

Netezza 是首批基于 FPGA 的数据库系统之一，始于 1990 年代末，从 PostgreSQL 发展而来。该系统使用 FPGA 加速磁盘页搜索，但最初无法搜索内存页，后续版本才修复此缺陷 [2]。Swarm64 曾尝试销售 PostgreSQL 的 FPGA 加速器，但在被收购前已转向无 FPGA 的纯软件架构 [91]。目前 Vitesse 的 Deepgreen DB [81] 成为独立软件厂商中仅存的 FPGA 增强型数据库系统。

GPU 加速数据库市场更为活跃，代表性系统包括 Kinetica [35]、Sqream [35]、Brytlyt [13] 和 HeavyDB [48]。但若数据量超出 GPU 内存容量，查询执行就会受限于设备数据加载速度，使得硬件并行化优势无从发挥。

讨论：从以上发展历程可得出几条结论。首先，这些系统均聚焦 OLAP 市场且仅适用于关系型数据库，本节讨论基本不涉及数据模型影响。其次，虽然 OLAP 工作负载将持续向云端迁移，但除非由云厂商自行构建，否则专用硬件难以获得市场认可。

对多数企业而言，为数据库系统专门定制硬件并不省钱。商用硬件虽避免了此问题，但如何与数据库系统集成仍是挑战。GPU 数据库之所以比 FPGA 系统更普遍，是因为 GPU 拥有现成的支持库（如英伟达 CUDA [169]）。而基于规模经济效应，云端 CPU 计算资源已变得极为廉价。任何加速器的成功可能仅限于本地数据库市场，但该市场增速已远不及云端数据库。

即使某个加速器能实现数量级的性能突破，也仅解决了市场成功的一半的需求。纯硬件公司必须找到愿意在数据库系统中集成其加速器的合作伙伴。若加速器仅为数据库的可选组件，其采用率必然低迷，数据库厂商自然不愿投入工程资源进行支持。若加速器是数据库的核心组件，则不会有厂商愿将如此关键的部件外包开发。

定制硬件加速器唯一可能成功的领域在于大型云服务商。凭借其巨大规模，数千万美元的硬件研发成本可被合理分摊。这些巨头同时掌控软硬件全栈体系，能在关键环节深度集成专用硬件。亚马逊已通过 Redshift AQUA 加速器 [102] 实践此道，谷歌 BigQuery 也配备了内存混洗专用组件 [89]。

尽管成功概率渺茫，我们预测未来 20 年该领域仍将涌现诸多尝试。

区块链数据库

本文撰写时，区块链正作为一种逐渐式微的数据库技术热潮存在。这是一种去中心化的日志结构数据库（即账本），通过默克尔树的变体来维护增量校验和。这些增量校验和是区块链确保数据库日志记录不可篡改的关键：应用程序利用校验和来验证先前数据库更新的完整性。

区块链数据库的理想应用场景是点对点的、无法相信任何人的环境。由于不存在中心化机构来控制数据库更新顺序，区块链系统通过拜占庭容错提交协议来决定事务执行顺序。

目前加密货币（比特币）仍是区块链的唯一实际应用场景。此外，业界也曾尝试基于区块链构建可用数据库系统，代表性项目包括 Fluree [25]、BigChainDB [12] 和 ResilientDB [136]。这些厂商（错误地）宣称区块链能提供传统数据库无法实现的安全性和可审计性。

讨论：当今社会仍然依赖多方信任机制。例如房屋交易时，买卖双方信任产权公司来处理交易。只有暗网交易（如洗钱）不需要现实世界的信任。合法企业不愿意为使用区块链数据库支付（高达五个数量级的）性能代价。若组织间已建立信任，可以通过共享分布式数据库高效协作，无需在区块链上浪费时间。据我们所知，所有主流加密货币交易所实际都采用传统关系型数据库运行业务，而非区块链系统。

区块链支持者还提出通过点对点环境下的复制实现数据弹性，这种主张同样缺乏实质意义。没有理性企业会将关键业务数据库的备份方案寄托于互联网上的随机节点。

私有区块链数据库或许存在（有限的）市场空间。亚马逊 2018 年发布的量子账本数据库（QLDB）[65] 提供了与区块链相同的不可篡改、可验证更新保证，但采用中心化架构（即不依赖拜占庭容错提交协议）。亚马逊正是在发现完全去中心化的区块链数据库缺乏实际应用场景后，才决定开发 QLDB[108]。

总结

数据库系统重大技术趋势的核心启示如下：

列式系统：列式存储彻底变革了 OLAP 数据库的架构设计。
云数据库：云计算颠覆了构建可扩展数据库系统的传统理念。除嵌入式数据库外，任何未以云服务为起点的产品都可能面临淘汰。
数据湖/湖仓一体：采用开源格式的云端对象存储将成为未来十年 OLAP 数据库的范式标准。
NewSQL 系统：虽然融合了创新理念，但尚未产生如列式与云数据库般的影响力。其推动形成了支持更强 ACID 语义的分布式数据库，以此制衡 NoSQL 较弱的 BASE 特性。
硬件加速器：除主要云服务商外，专用硬件尚未展现明确应用场景，尽管初创企业仍将持续尝试。
区块链数据库：一种低效且仍在寻求应用场景的技术。历史经验表明，这并非系统开发的正确路径。

总评

通过对过去二十年数据库发展的梳理，我们得出若干重要启示。遗憾的是，其中部分结论已经在 2005 年的论文中提出过。

切勿低估劣质产品的营销威力。数据库市场竞争激烈利润丰厚，驱使厂商不断宣称新技术能解决各类问题、改善开发者体验。由于每个开发者都曾受数据库问题困扰，尤其容易受到此类营销的影响。历史上多次出现劣质数据库产品凭借强势营销战胜同期更优选择的情况：甲骨文在 1980 年代、MySQL 在 2000 年代、MongoDB 在 2010 年代均采用此策略。这些系统通过早期市场立足赢得时间，最终逐步弥补了工程缺陷。

警惕非数据库巨头的数据库产品。近十年一个有趣现象是科技公司常将内部自研数据库开源发布。这些系统最初多为满足特定业务需求的定制化应用，后被作为开源项目发布（通常交由 Apache 基金会托管），以期获得外部用户的"免费"开发贡献。

此类系统可分为两类：一类来自资源雄厚的大型企业，如 Meta（Hive [197]、Presto [63]、Cassandra [14]、RocksDB [68]）和领英（Kafka [33]、Pinot [59]、Voldemort [82]）；另一类来自初创公司，它们在开发数据密集型产品时选择自建数据库。10gen（MongoDB）和 PowerSet（HBase）是成功典范，但更多尝试以失败告终。

排斥"非我发明"产品的趋势，部分源于许多企业的晋升机制更青睐构建新系统的工程师，即使现有工具已足够。这种风气导致缺乏数据库工程经验的团队盲目开发新系统。对于企业新开源的数据库，用户应保持警惕------它们几乎总是不成熟的技术产物。

不要忽视"开箱即用"体验。许多非关系型数据库的核心卖点是优于传统 RDBMS 的"开箱即用"体验。多数 SQL 系统需先创建数据库、定义表结构才能加载数据，这正是数据科学家偏爱 Python notebook 快速分析文件的原因。因此，所有数据库都应简化本地与云端文件的就地处理能力。DuckDB 的崛起部分归功于此。厂商还需关注用户必然面对的物理设计、参数调优、模式设计和查询优化等挑战，这正是我们提出的"自我驱动"数据库 [173] 的迫切需求。

开发者需要直接查询数据库。过去 20 年开发的 OLTP 应用大多通过抽象层（如 REST、GraphQL 等端点 API 或 ORM 库）与数据库交互。这些层将高级请求转换为数据库查询，ORM 还能自动处理模式迁移等维护任务。虽然 OLTP 开发者几乎不编写原始 SQL，数据库的数据模型看似被抽象层隐藏，但这恰凸显了问题所在。

ORM 虽是快速原型开发的利器，但常以牺牲逻辑下推能力为代价换取多数据库兼容性。开发者最终仍需编写显式查询来规避自动生成的劣质查询。因此，选择支持 SQL 的关系型数据库仍是更优方案。

AI/ML 对数据库的影响将极为深远。数据库如何与现代 AI/ML 工具交互已成为关键课题，特别是大语言模型（如 ChatGPT）出现后。尽管该领域发展迅猛，我们仍提供几点初步观察：

大语言模型在自然语言转查询代码（如 SQL）[133] 方面的突破，正推动自然语言查询数据库的复兴。甚至有人预言 AI 查询接口将取代 SQL。自然语言界面虽是 1970 年代 [139] 便开始的研究课题，但历史成效甚微 [88]。虽然大语言模型在此任务上表现惊艳，但我们需警示"自然语言将取代 SQL"的论调：无人会用自然语言编写 OLTP 应用，因其多通过 ORM 生成查询；对于 OLAP 场景，自然语言或许能辅助探索性分析的初始查询构建，但由于自然语言固有的模糊性，此类查询仍需通过看板式工具进行精炼。

企业（特别在处理财务数据时）对当前大语言模型的决策应用仍持谨慎态度。核心问题在于大语言模型的输出结果难以解释，且其训练数据需求远超传统机器学习系统（如随机森林、贝叶斯模型）。企业通常无法将训练数据创建外包给非专业人员。因此，大语言模型在企业数据领域的应用将缓慢推进。

最后，近期涌现大量利用 AI/ML 优化数据库的研究 [174]，包括面向 ML 的查询优化器 [152,156]、配置调优器 [200, 204] 及访问方法 [151,193]。尽管此类 ML 辅助优化是提升数据库性能的利器，但绝不能替代高质量的系统工程实践。

结论

我们预测数据库领域的发展循环在未来几十年仍将持续。新一代开发者声称 SQL 和关系模型无法应对新兴应用领域需求。人们将提出新的查询语言和数据模型解决这些问题。探索数据库管理系统的新思想和新概念具有巨大的价值（SQL的许多新功能正源于此）。数据库研究社区和市场也因此更具活力。然而，我们认为这些新数据模型不会取代关系模型。

还有一个问题值得关注。许多新项目重复实现那些缺乏创新，但在生产环境数据库管理系统必需的组件（如配置处理器、解析器、缓冲池），这造成了大量精力浪费。为加速下一代数据库管理系统的发展，社区应推动开源可复用组件与服务的开发 [112, 176]。目前已有一些相关成果，包括文件格式（第3.3节）、查询优化（如 Calcite [104]、Orca [186]）以及执行引擎（如 DataFusion [18]、Velox [175]）。我们认为数据库社区应致力于建立类似 POSIX 的数据库内部标准，提升系统间互操作性。

我们提醒开发者要以史为鉴。换言之，应该"站在前人的肩膀上，而不是脚尖上"。本文的作者中，有的可能二十年后仍在世，非常期待在 2044 年为本文续撰写续篇。