1 引言

2005年，Stonebraker参与撰写了红皮书的一章，标题为“What Goes Around and Comes Around”[188]。

那一篇论文检视了1960年代以来的主要数据建模运动：

• 层次结构（例如，IMS）：1960年代末和1970年代

• 网格结构（例如，CODASYL）：1970年代

• 关系型：1970年代和1980年代初

• 实体-关系：1970年代

• 扩展关系型：1980年代

• 语义：1970年代末和1980年代

• 面向对象：1980年代末和1990年代初

• 面向关系型：1980年代末和1990年代初

• 半结构化（例如，XML）：1990年代末和2000年代

我们的结论是，具有可扩展类型系统的关系模型（即，面向对象-关系型）已经统治了所有竞争者，在整个市场上再没有其它更成功的系统。

尽管2005年涵盖的许多非关系型DBMS今天仍然存在，但它们的提供商已经将其归为遗留维护模式，没有人在它们上面构建新的应用程序。这种持久性更多是数据“粘性”的证明，而不是这些系统的持久力量。

换句话说，今天仍有许多IBM IMS数据库在运行，因为转换为使用现代DBMS既昂贵又有风险。但是，没有一家初创公司会愿意选择在IMS上构建新应用程序了。

自从我们从 2005年调查以来，数据库领域发生了很多事情。在这段时间里，DBMS已经从它们在商业数据处理的根源扩展到几乎每种类型的数据。这导致了2010年代初的“大数据”时代，以及当前将机器学习与DBMS技术整合的趋势。

在本文中，我们分析了数据库中过去20年的数据模型和查询语言活动。我们将评论结构化表示为以下领域：

1. MapReduce系统
2. 键值存储
3. 文档数据库
4. 列族/宽列
5. 文本搜索引擎
6. 数组数据库
7. 向量数据库
8. 图形数据库

我们认为，大多数偏离SQL或RM(Relational-Model)的系统并没有主导DBMS格局，通常只服务于小众市场。

许多最初以很大声势拒绝RM的系统（比如NoSQL）现在为RM数据库公开了一个类似SQL的接口。这样的系统现在正走向与RDBMS的大融合。

在这样情况的同时，SQL也已经纳入了当今最好的查询语言思想，以扩大其对现代应用程序的支持并保持相关性。

尽管RM的基本原理没有太多变化，但在RM系统实现中发生了戏剧性的变化。

本文的第二部分讨论了DBMS架构的进步，这些进步解决了现代应用程序和硬件的问题：

• 列式系统

• 云数据库

• 数据湖/Lakehouses

• NewSQL系统

• 硬件加速器

• 区块链数据库

其中，一些是对DBMS实现的深刻变化，而另一些仅仅是基于错误前提的趋势。

我们对下一代DBMS的重要考虑因素的讨论作为结尾，附加上我们在科研和商业环境中对数据库未来希望的评论。

  2、数据模型和查询语言

我们将数据库中的数据模型与查询语言的研究与开发分为如下8个类别。

2.1 MapReduce 系统

Google在2003年构建了他们的MapReduce（MR）框架，作为处理其对互联网定期抓取的“关键解决方案”[122]。

当时，Google在DBMS技术方面几乎没有专业知识，他们构建MR以满足他们的抓取需求。

在数据库术语中，Map是一个用户定义的函数（UDF），执行计算或过滤，而Reduce是一个GROUP BY操作。

大体上说，MR运行的是一个单一查询：

SELECT map() FROM crawl_table GROUP BY reduce()

Google的MR方法并没有规定特定的数据模型或查询语言。相反，由在过程式MR程序中编写的Map和Reduce函数来解析数据文件的内容。

2000年代末，其他公司对基于MR的系统也非常感兴趣。

Yahoo!（雅虎） 在2005年开发了一个名为Hadoop的MR的开源版本[134]。它运行在一个分布式文件系统HDFS之上，这是Google文件系统的克隆[134]。

还有几家初创公司成立来支持Hadoop的商业市场。我们将使用MR来指代Google的实现，Hadoop来指代开源版本，它们在功能上是相似的。

Hadoop与为OLAP工作负载设计的RDBMS价值存在争议，并且在2009年的一项研究中达到高潮，该研究表明数据仓库DBMS的性能超过了Hadoop[172]。同时引发了Google和DBMS社区之间的辩论文章[123, 190]。

Google认为，通过专业工程，MR系统将击败DBMS，用户不必在运行查询之前用模式加载数据。因此，MR更适合“一次性”任务，如文本处理和ETL操作。

而DBMS社区认为，MR由于其设计而存在性能问题，现有的并行DBMS已经解决了这些问题。此外，使用高级语言（SQL）在分区表上运行已被证明是一个好的编程模型[127]。

两篇论文中的许多讨论都集中在实现的问题上（例如，索引，解析，查询处理，故障恢复）。从阅读这两篇论文可以得出一个合理的结论，即这两种系统都有其适用的地方。

但是，技术世界的两个变化让这场辩论变得无关紧要。

第一个事件是Hadoop技术与服务市场在2010年崩溃了。许多企业在Hadoop集群上花费了大量的资金，结果发现对这个功能几乎没有用处。开发者发现很难将他们的应用程序强行塞入受限的MR/Hadoop范式中。有相当大的努力在Hadoop之上提供SQL和RM接口，最值得注意的是Meta的Hive。

在CACM文章八个月后发生下一个事件，Google宣布他们正在将他们的抓取处理从MR转移到BigTable上[164]。其原因是Google需要实时交互式更新其抓取数据库，但MR是一个批处理系统。

Google 最终在2014年宣布MR在他们的技术栈中没有位置，并将其淘汰[194]。

第一个事件让三家领先的Hadoop供应商（Cloudera, Hortonworks, MapR）没有可行的产品可卖。Cloudera将Hadoop重新定义为一个堆栈体（Application、Hadoop、HDFS）。其进一步的手段为，Cloudera在HDFS之上构建了一个RDBMS，Impala[150]，但没有使用Hadoop。他们意识到Hadoop在SQL DBMS的内部接口中没有位置，并且他们用直接构建在HDFS上的软件将其从其堆栈中移除出去。同样，MapR在HDFS上直接构建了Drill[22]，Meta创建了Presto[185]来取代Hive。

MR的缺陷非常大，尽管开发者社区广泛采用并具有热情，最后也无法得救。Hadoop大约在十年前就死了，留下了企业中的HDFS集群遗产和一系列产品公司还想从它们那里赚一些钱。目前，HDFS已经失去了它的光彩，因为企业意识到有更好的分布式存储替代品[124]。

而在同样的时刻，分布式RDBMS正在蓬勃发展，特别是在云端。

MR系统实现的一些方面与分布式RDBMS的可扩展性，弹性和容错性有关。MR还带来了共享式磁盘架构的复兴，随后产生了开放源代码文件格式和数据湖（见第3.3节）。Hadoop的限制为其他数据处理平台打开了大门，即Spark[201]和Flink[109]。两个系统最初都是作为MR的更好实现，具有过程式API，但是后面已经增加了对SQL的支持[105]。

2.2 键/值存储（Key/Value Stores）

键/值（KV）数据模型是可能的最简单模型。它表示以下的二元关系：(key, value)

键/值型数据库管理系统（K/V DBMS）将数据集合表示为一个将键映射到值的关联数组。值通常是一个未标记的字节数组（如：一个blob），数据库系统并不知道其内容是什么。交由应用程序来维护模式，并解析值到其相应的部分。

大多数键/值型 DBMS只提供对单个值的GET/SET/DELETE操作。

在2000年代，几家新兴的互联网公司为专注于特定应用的场景构建了各自的无共享（shared-nothing）、分布式KV存储系统。

比如缓存会话数据。对于缓存，Memcached[131]是这种方法最著名的例子。Redis[67]自诩为Memcached替代品，提供了一个更强大的查询API，并支持检查点。对于持久化数据，亚马逊在2007年创建了Dynamo KV存储[125]。这些系统提供了比RDBMS更高和更可预测的性能，但功能却仍有限。

第二个KV DBMS类别是设计为在与高级应用程序相同的地址空间中运行的嵌入式存储引擎。最早的独立嵌入式KV DBMS之一是90年代初的BerkeleyDB[170]。近期值得注意的包括Google的LevelDB[37]，Meta后来将其派生为RocksDB[68]。

键/值存储引擎为开发者提供了一种快速的“开箱即用”的方式来存储数据，相比之下，配置RDBMS中的表却需要更多的工作。

当然，在一个需要比简单的二元关系更复杂的应用程序中使用KV存储是“危险”的。如果应用程序需要记录多个字段，那么KV存储可能不是一个好方案。不仅应用程序必须解析记录字段，而且没有二级索引可以按值检索其它字段。同样地，开发者必须在他们的应用程序中实现联接或多次获取操作。

为了解决这些问题，一些系统起初是一个KV存储，然后演变成一个更丰富的记录存储。这样的系统用半结构化的值替换了不透明的值（类似blob），例如JSON文档。这种转变的例子是亚马逊的DynamoDB[129]和Aerospike[9]。重新设计一个KV存储以支持复杂数据模型并不简单，而RDBMS却可以轻松模拟KV存储而无需任何更改。如果应用程序需要一个嵌入式DBMS，今天已有全功能的选项可用，包括SQLite[71]和DuckDB[180]。因此即使是简单的应用程序，RDBMS也可能是更好的选择，因为如果应用程序的复杂性增加，RDBMS可以提供更好的扩展性。

过去20年的一种新架构趋势是使用嵌入式KV存储作为全功能DBMS的底层存储引擎。

在此之前，构建一个新的DBMS需要工程师构建一个定制的存储引擎，该引擎内置集成在DBMS中。

MySQL便是第一个公开API的DBMS，它允许开发者替换其默认的KV存储引擎（插件式存储引擎架构）。这个API使得Meta能够构建RocksDB来替换其大量MySQL数据库的InnoDB。类似地，MongoDB在2014年放弃了的MMAP存储管理器，转而使用WiredTiger的KV存储[120, 138]。

使用现有的KV存储可以让开发者用更少的时间编写新的DBMS应用。

2.3 文档数据库（Document）

文档数据模型将数据库表示为记录对象的集合。

每个文档包含字段/值对的层次结构，每个字段都由名称标识，字段的值可以是标量类型、值数组或另一个文档。以下JSON示例是一个包含嵌套的采购订单记录列表的客户文档，以及它们相应的订单项。

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

文档数据模型几十年来一直是一个活跃的研究领域。这促成了像SGML[117]和XML[118]这样的数据格式的出现。

尽管在1990年代末XML数据库备受关注，我们在2005年正确预测它们不会取代RDBMS[188]。JSON自那以后已经超越了XML，成为基于Web的应用程序数据交换的标准。随着JavaScript的普及和随之而来的JSON普及，在2000年代诞生了几家公司，创建了本地存储JSON的面向文档的系统。

由于OLTP RDBMS在2000年代无法扩展，出现了几十个文档DBMS，它们使用NoSQL的口号进行市场推广[110]。这些系统的两个市场宣传与开发者产生了共鸣。首先，SQL和连接操作很慢，应该使用更“快速”的底层、单记录处理的接口。其次，现代应用程序不需要ACID事务，因此DBMS应该只提供较弱的事务概念（即NoSQL比较推崇的BASE[179]）。

由于这两个产品的推动，NoSQL开始代表一个存储记录或文档为JSON的DBMS，支持低级API，并且支持较弱或不存在的事务。

有几十种这样的系统，其中MongoDB[41是最受欢迎。

文档DBMS本质上与1980年代的面向对象DBMS和1990年代末的XML DBMS相同。文档DBMS的支持者与他们的OO/XML前辈们提出了相同的论点：以文档形式存储数据消除了应用程序OO代码与数据交互的方式和关系数据库存储它们之间的不匹配。他们还声称，将记录非规范化为嵌套结构对性能更好，因为它消除了分派多个查询以检索与给定对象相关的数据的需要（即，ORM中的“N+1问题”）。

非规范化/预连接的问题是一个古老的话题，可以追溯到1970年代[116]：

(1)如果联接不是一对多，那么就会有重复数据

(2)预连接并不一定比联接更快

(3)没有数据独立性。

尽管他们强烈抨击SQL很糟糕，但到2010年代末，几乎所有NoSQL DBMS都添加了SQL接口。直接的例子包括DynamoDB PartiQL[56]、Cassandra CQL[15]、Aerospike AQL[9]和Couchbase SQL++[72]。最后一个坚持的是MongoDB，但他们在2021年也为他们的Atlas服务添加了SQL[42]。

其支持SQL标准的DDL和DML操作，NoSQL供应商声称他们支持自己的专有查询语言，该语言源自或受SQL启发。对于大多数应用程序来说，这些区别是没有意义的。SQL和NoSQL衍生语言之间的任何语言差异主要是由于JSON扩展和维护操作。

许多剩余的NoSQL DBMS还添加了强一致性（ACID）事务（见第3.4节）。因此，NoSQL的提示信息已经从“Do not use SQL – it is too slow!”转变为“Not Only SQL”（SQL有时还是不错的）。

向NoSQL DBMS添加SQL和ACID降低了它们与RDBMS的功能差距。它们之间的主要区别似乎是JSON支持以及NoSQL供应商允许“schema later/Schemaless”数据库。但是，SQL标准在2016年添加了JSON数据类型和操作[165, 178]。并且随着RDBMS继续改善开发人员的“前五分钟”体验，我们相信这两种系统很快就会变得从实际场景中无法区分。

使用高级语言几乎普遍优于逐条记录操作的方法，因为它们可以更少的代码并提供更大的数据独立性。尽管我们承认最初的SQL优化器很慢且效果不佳，但在过去50年里它们已经有了很大的改进。但优化器仍然是构建DBMS中最困难的部分。我们怀疑这种工程负担是NoSQL系统最初选择不支持SQL的一个因素。

2.4 列族数据库（Column-Family）

存在另一类使用称为列族（又称宽列）的数据模型的NoSQL系统。尽管它的名字，列族并不是一个列式数据模型。相反，它是对文档数据模型的简化，只支持一级嵌套而不是任意嵌套；它和关系型记录有点像，但每条记录可以有可选属性，单元格可以包含值数组。

以下示例显示了从用户标识符键到包含每个用户不同配置文件信息的JSON文档的映射：

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

第一个列族模型DBMS是Google在2004年推出的BigTable[111]。与采用SQL和出现的列式存储不同，Google使用这种数据模型和过程性客户端API。

其他系统采用了列族模型，试图复制Google的定制实现。最值得注意的是Cassandra[14]和HBase[28]。它们也复制了BigTable的限制，包括缺乏联接和二级索引。

我们在第2.3节中关于文档模型的所有评论在这里也适用。

在2010年代初期，谷歌在BigTable之上构建了RDBMS，包括MegaStore[99]和Spanner的第一个版本。从那以后，谷歌重写了Spanner，去除了BigTable的残余部分[98]，现在它是许多内部应用的主要数据库。一些NoSQL DBMS放弃了它们的专有API，转而支持SQL，但仍然保留了它们的非关系型架构。

Cassandra用一种名为CQL[15]的类似SQL的语言替换了他们的Thrift-API，HBase现在推荐使用Phoenix SQL前端[57]。谷歌仍然提供BigTable作为云服务，但列族模型是一个独特的例外，具有与NoSQL DBMS相同的缺点。

2.5 文本搜索引擎

文本搜索引擎已经存在了很长时间，始于1960年代的开创性SMART系统[184]。SMART开创了信息检索和向量空间模型，在现代搜索引擎中几乎普遍使用，通过将文档标记化为“bag of words”，然后构建这些标记的全文索引（也称为倒排索引）来支持对它们内容的查询。该系统还意识到了噪音词（例如，“the”，“a”）、同义词（例如，“The Big Apple”是“New York City”的同义词）、关键词和距离（例如，“drought”经常出现在“climate change”附近）。

当今领先的文本搜索系统包括Elasticsearch[23]和Solr[70]，它们都使用Lucene[38]作为内部的搜索库。这些系统为存储和索引文本数据提供了良好的支持，但只提供有限的事务能力。这种限制意味着DBMS必须通过从头重建文档索引来从数据损坏中恢复，这导致显著的停机时间。

所有领先的RDBMS都支持全文搜索索引，包括Oracle[52]、Microsoft SQL Server[52]、MySQL[43]和PostgreSQL[62]。它们的搜索功能最近有所改进，通常与上述专用系统相当。它们还具有内置的事务支持的优势。但是，它们将搜索操作集成到SQL中通常很笨拙，并且在不同的DBMS之间有所不同。

讨论：文本数据本质上是无结构的，这意味着没有数据模型。相反，DBMS试图从文本中提取结构（即，元数据、索引），以避免“大海捞针”的顺序搜索。

2.6 数组数据库（Array Databases）

注：时序和空间数据库也可以理解为是数组数据库的一种场景

在许多计算领域，数组是显而易见的数据表示形式。我们使用术语“数组”来指代所有变体[182]：向量（一维 - 见第2.7节）、矩阵（二维）和张量（三维或更多维）。例如，针对地理区域的科学调查通常将数据表示为多维数组，存储使用基于位置/时间坐标的传感器测量

值：(纬度,经度,时间,[值向量])(纬度,经度,时间,[值向量])

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

尽管基于数组的编程语言自20世纪60年代以来就已经存在（APL[142]），最初的数组数据库管理系统（DBMS）的工作始于20世纪80年代。PICDMS被认为是第一个使用数组数据模型的DBMS实现[114]。今天仍在开发的最古老的两个数组DBMS是Rasdaman[66, 103]和kdb+[34]。较新的数组DBMS包括SciDB[54, 191]和TileDB[76]。HDF5[29]和NetCDF[46]是科学数据的流行数组文件格式。

存储和查询现实世界数组数据集存在几个系统挑战。首先是数组数据并不总是规则的；例如，地理空间数据通常被分割成不规则形状。应用程序可以通过描述此映射的元数据将这样的网格映射到整数坐标[166]。因此，大多数应用程序在单个数据库中同时维护数组和非数组数据。

与基于行或列的DBMS不同，在任意维度上查询数组数据提出了独特的挑战。困难来自于将多维数组数据存储在像磁盘这样的线性物理存储介质上。为了克服这些挑战，数组DBMS必须采用索引和数据结构来支持数组维度上的高效遍历。

讨论：数组DBMS是一个细分市场，只有在特定的垂直领域（我们在下一个部分讨论向量DBMS）看到了采用。例如，它们在基因组学领域有相当的吸引力。HDF5在卫星图像和其他网格科学数据中很受欢迎。但商业应用程序很少使用专用的数组DBMS，这对于任何产品的存活来说是必要的。没有主要的云服务提供商提供托管的数组DBMS服务，这意味着它们没有看到一个可观的市场。

数组DBMS供应商一直面临的挑战是，SQL包括对有序数组作为一等数据类型（尽管这违反了原始RM提议[115]）的支持。第一个提出将有序位图扩展到基于集合的无序RM的提议是在1993年[155]。早期的例子是Illustra的时间（一维）数据插件[31]。SQL:1999引入了对单维、固定长度数组数据类型的有限支持。SQL:2003扩展到支持没有预定义最大基数的嵌套数组。后来的加入者包括Oracle GeoRaster[4]和Teradata[73]。数据立方体是特殊用途的数组[135]，但由于它们的灵活性更好和工程成本更低，列式RDBMS已经取代了它们用于OLAP工作负载[113]。

最近，SQL:2023标准包括了对真正的多维数组（SQL/MDA）的支持，这在很大程度上受到了Rasdaman的RQL[166]的启发。这个更新允许SQL使用基于整数的坐标来表示具有任意维度的数组。实际上，这允许数据立方体存在于SQL框架中，但列式DBMS现在主导了这个市场。

2.7 向量数据库（Vector）

类似于列族模型是文档模型的简化，向量数据模型简化了数组数据模型为一维模型。鉴于向量DBMS目前从开发者和投资者那里吸引了最多的关注（类似于以前NoSQL的狂热），有必要单独讨论它们。引起这种兴趣的原因是开发者使用它们来存储由AI工具生成的单维度embedding。这些工具使用学习到的模型将记录的数据（例如，文本、图像）转换为表示其潜在语义的向量。例如，可以使用Google BERT将每篇维基百科文章转换为embedding，并将它们与额外的文章元数据一起存储在向量数据库中：

(标题,日期,作者,[嵌入向量])(标题,日期,作者,[嵌入向量])

这些嵌入向量的尺寸范围从简单变换器的几百维到高端模型的几千维；这些尺寸显然会随着更复杂的模型的发展而增长。

关键的区别在于向量和数组数据库的查询模式。向量用于相似性搜索，这些搜索找到的记录向量在高维空间中与给定输入向量距离最短。输入向量是使用相同的变换器生成的另一个embedding。与数组数据库不同，应用程序不使用向量数据库来搜索向量中的偏移，也不提取多个向量之间的切片。相反，主要用例是搜索相似性。

为了避免使用蛮力扫描来寻找最相似的记录，向量数据库构建索引以加速近似最近邻（ANN）搜索。应用程序发出查询，这些查询具有关于嵌入索引和非嵌入属性（即元数据）的谓词。然后，数据库管理系统选择是否在向量搜索之前（预过滤）或之后（后过滤）使用非嵌入谓词对记录进行过滤。

在这个新兴类别中有许多新的数据库管理系统，Pinecone [58]、Milvus [40] 和 Weaviate [84] 是领先的系统。文本搜索引擎，包括 Elasticsearch [23]、Solr [70] 和 Vespa [79]，扩展了它们的 API 以支持向量搜索。其他数据库管理系统重新品牌自己为向量数据库以加入这一潮流，例如 Kdb+ [34]。

向量数据库的一个引人注目的特点是，它们比关系数据库管理系统更好地与 AI 工具（例如 ChatGPT [16]、LangChain [36]）集成。这些系统在插入时本地支持将记录数据转换为embedding，使用这些工具，然后使用相同的转换将查询的输入参数转换为嵌入以执行 ANN 搜索；其他数据库管理系统要求应用程序在数据库外部执行这些转换。

讨论：与需要定制存储引擎和执行引擎以支持多维数据有效操作的数组数据库不同，向量数据库本质上是具有专门 ANN 索引的数据库管理系统。这些索引是一个特性，而不是一个新系统架构的基础。

在 2022 年底 ChatGPT 成为“主流”之后，不到一年，几个关系数据库管理系统就增加了自己的向量搜索扩展。在 2023 年，许多主要的关系数据库管理系统增加了向量索引，包括 Oracle [7]、SingleStore [137]、Rockset [8] 和 Clickhouse [157]。与此相比，RDBMS 中的 JSON 支持，NoSQL 系统如 MongoDB 和 CouchDB 在 2000 年代末变得流行，而 RDBMS 花了几年时间才增加对它的支持。

向量索引快速扩散有两个可能的解释。第一，通过嵌入进行相似性搜索是一个如此引人注目的用例，以至于每个数据库管理系统供应商都急忙推出了他们的版本并立即宣布。第二，引入一个新的索引数据结构的工程工作量足够小，以至于数据库管理系统供应商增加向量搜索并没有花费太多工作。他们中的大多数没有从头开始编写他们的向量索引，而是集成了一个开源库（例如，pgVector [145]、DiskANN [19]、FAISS [24]）。

我们预计，向量DBMS将经历与文档DBMS相同的演变过程，通过增加功能变得更像关系型数据库（例如，SQL、事务、可扩展性）。同时，现有的关系型数据库将在其已经很长的功能列表中添加向量索引，并继续关注下一个新兴趋势。

2.8 图数据库（Graph Databases）

在过去十年中，图数据库在学术界和工业界引起了很多兴趣[183]。许多应用程序使用知识图谱来模拟半结构化信息。社交媒体应用程序本质上包含面向图的关系（“点赞”，“朋友”）。关系设计工具为用户提供了他们数据库的实体关系（ER）模型。ER 图是一个图；因此，这个范式有明确的用例。

表示图的两种最普遍的方法是（1）资源描述框架（RDF）和（2）属性图[126]。使用属性图，数据库管理系统维护一个有向多图结构，支持节点和边缘的键/值标签。RDF 数据库（也称为 triplestores）只模拟一个有标签边的有向图。由于属性图更常见，并且是 RDF 的超集，我们将只讨论它们。我们考虑图数据库管理系统的两个用例，并讨论将限制它们被采用的问题。

第一类系统是用于操作性/OLTP 工作负载的：例如，应用程序通过以事务方式更新单个记录，在数据库中添加一个好友链接。Neo4j [44] 是最受欢迎的 OLTP 应用程序的图数据库管理系统。它使用指针支持边缘（就像 CODASYL 一样），但它不将节点与其“父”或“后代”聚集在一起。这种架构有利于遍历长的边缘链，因为它将进行指针追逐，而关系数据库管理系统必须通过联接来完成这一操作。但它们的潜在市场成功取决于是否有足够的“长链”场景，值得放弃关系数据库管理系统。

第二个用例是分析，它寻求从图中派生信息。一个例子是找出哪个用户在30岁以下有最多好友。值得注意的，如 Tigergraph [74] 和 JanusGraph [32]，专注于图数据库管理系统的查询语言和存储。其他系统，如 Giraph [26] 和 Turi [78]（前身为 Graphlab [27]），提供了一个计算框架，以支持面向图的程序的并行执行，通常由用户编写。

与关系分析中的查询不同，图分析查询包含如最短路径、cut set、clique determination等操作。算法选择和数据展示将决定DBMS的性能。这需要一个计算结构，允许开发者使用隐藏底层系统拓扑的抽象来编写自己的算法。然而，先前的研究表明，由于通信成本，分布式算法很少能胜过单节点实现[160]。一个更好的策略是将图压缩成一个空间高效的数据结构，使其适合单个节点的内存，然后针对这个数据结构运行查询。除了最大的图数据库外，所有图数据库可能最好都以这种方式处理。

讨论：无论图数据库管理系统针对 OLTP 还是 OLAP 工作负载，这些系统必须克服的关键挑战是，可以模拟图作为表的集合：

• 节点 (node_id, node_data)

• 边缘 (node_id_1, node_id_2, edge_data)

这意味着关系数据库管理系统始终是支持图的一个选项。但原生SQL 表达力不足以满足图查询，因此需要多个客户端-服务器往返来执行遍历操作。

一些关系数据库管理系统，包括 MsSQL [3] 和 Oracle [50]，提供了内置的 SQL 扩展，使存储和查询图数据更加容易。其他数据库管理系统使用关系之上的转换层来支持面向图的 API。Amazon Neptune [45] 是 Aurora MySQL 上的面向图的表层。Apache AGE 在 PostgreSQL [10] 之上提供了一个 OpenCypher 接口。

最近，SQL:2023 引入了属性图查询（SQL/PGQ），用于在关系数据库管理系统中定义和遍历图[196]。该语法建立在现有语言（例如，Neo4j 的 Cypher [49]、Oracle 的 PGQL [51] 和 TigerGraph 的 GSQL [75]）之上，并共享了新兴的 GQL 标准[126]的方面。因此，SQL/PGQ 进一步缩小了关系数据库管理系统和原生图数据库管理系统之间的功能差异。

问题是，图数据库管理系统供应商能否使他们的专业系统足够快，以克服上述缺点。已经有几项性能研究表明，关系数据库管理系统上的图模拟优于图数据库管理系统[130, 143]。最近的工作表明，DuckDB 中的 SQL/PGQ 比领先的图数据库管理系统性能高出多达 10 倍[196]。随着最坏情况优化连接[132, 168]和因子分解执行算法[100]在关系数据库管理系统中的图查询的进一步改进，这一趋势将继续。

2.9 总结

从上述部分可以合理地得出结论，非 SQL、非关系型系统要么是小众市场，要么正在迅速成为 SQL/RM 系统。具体来说：

• MapReduce 系统：它们在几年前就已经消亡，现在最多是遗留技术。

• 键值存储：许多已经成熟为 RM 系统，或者只用于特定问题。这些通常可以被现代高性能 RDBMS 相等或超越。

• 文档数据库：这些 NoSQL 系统正与 RDBMS 相撞。这两种系统之间的区别随着时间的推移而减少，将来应该几乎无法区分。

• 列族系统：这些仍然是小众市场。如果没有 Google，本文就不会讨论这个类别。

• 文本搜索引擎：这些系统在多个存储架构中用于文本字段。如果 RDBMS 对搜索有更好的支持，这些就不必是单独的产品。

• 数组数据库：科学应用将继续忽略 RDBMS，而倾向于专门的数组系统。尽管有新的 SQL/MDA 增强功能，RDBMS 仍然不能有效地存储和分析数组，它们可能会变得更重要。

• 向量数据库：它们是单一用途的 DBMS，具有加速最近邻搜索的索引。RM DBMS 应该很快提供对这些数据结构和搜索方法的原生支持，使用它们可扩展的类型系统，这将使这种专门的数据库变得不必要。

• 图数据库：OLTP 图应用将主要由 RDBMS 服务。此外，分析图应用有独特的需求，最好在主内存中使用专门的数据结构来完成。RDBMS 将提供基于 SQL 或通过扩展的图中心 API。我们预计专门的图 DBMS 不会是一个大市场。

• 除了上述内容，还有一些提议将以前的数据模型重新品牌为某种新颖的东西。例如，图关系[158]与语义数据模型[202]相同。同样，文档关系是带有外键的文档模型[199]。其他人在 RDBMS 上提供了一个非 SQL 的外观（例如，PRQL[64]，Malloy[39]）。尽管这些语言处理了 SQL 的一些缺点，但它们不足以克服其根深蒂固的用户群和生态系统。

  
  

  
  

作者：Michael Stonebraker 和 Andrew Pavlo