Appearance
周而复始，未有穷期... (What Goes Around Comes Around... And Around...)
- Michael Stonebraker - [email protected]
- Andrew Pavlo - [email protected]
TLDR;
摘要
二十年前，我们中的一位合著了一篇论文，回顾了过去四十年数据建模领域的研究与发展[188]。该论文指出，尽管业界屡次尝试取代关系模型（RM）与SQL，但它们依然是数据库管理系统（DBMS）的主流选择。反倒是SQL，通过不断扩展，吸收了这些替代方案的优点。
本文将重温这一主题，并论证自2005年以来，同样的演进仍在继续。新的尝试层出不穷，旨在取代SQL或RM，但关系模型至今仍是主导的数据模型，而SQL则通过功能扩展，博采众长，从而屹立不倒。我们预测这一趋势在未来仍将持续，即SQL和关系型数据库管理系统（RDBMS）将不断演进。我们还将探讨DBMS的实现，并指出其主要进步体现在关系模型系统中，这主要是由日新月异的硬件特性所驱动的。
1 引言
2005年，本文作者之一参与撰写了《红宝书》(Red Book) 中题为“What Goes Around Comes Around”的一章[188]。该文章回顾了自20世纪60年代以来的各大主要数据建模浪潮：
- 层次模型 (Hierarchical) (如 IMS): 20世纪60年代末至70年代
- 网状模型 (Network) (如 CODASYL): 20世纪70年代
- 关系模型 (Relational): 20世纪70年代至80年代初
- 实体-关系模型 (Entity-Relationship): 20世纪70年代
- 扩展关系模型 (Extended Relational): 20世纪80年代
- 语义模型 (Semantic): 20世纪70年代末至80年代
- 面向对象模型 (Object-Oriented): 20世纪80年代末至90年代初
- 对象-关系模型 (Object-Relational): 20世纪80年代末至90年代初
- 半结构化模型 (Semi-structured) (如 XML): 20世纪90年代末至21世纪初
我们的结论是：带有可扩展类型系统（即对象-关系模型）的关系模型，已在所有竞争者中脱颖而出，其他模型在商业上均未取得显著成功。尽管2005年论文中提及的许多非关系型DBMS至今仍在运行，但其供应商已将它们降级为遗留系统，仅提供维护支持，没有人会基于它们构建新的应用程序。这些系统的“长寿”更多地证明了数据的“粘性”，而非其技术本身的生命力。换言之，今天仍有大量IBM IMS数据库在运行，只是因为将其迁移到现代DBMS的成本高昂且风险巨大。但没有一家初创公司会选择在IMS上构建新应用。
自我们2005年的调研以来，数据库世界发生了翻天覆地的变化。在此期间，DBMS的应用范围已远超其商业数据处理的本源，如今几乎渗透到所有类型的数据管理中。这催生了2010年代初的“大数据”时代，以及当前将机器学习（ML）与DBMS技术相集成的热潮。
本文将分析过去二十年数据库在数据模型和查询语言方面的动态。我们将从以下几个方面展开评述：(1) MapReduce系统，(2) 键值存储，(3) 文档数据库，(4) 列族/宽列存储，(5) 文本搜索引擎，(6) 数组数据库，(7) 向量数据库，以及 (8) 图数据库。
我们认为，大多数背离SQL或RM的系统并未在DBMS领域占据主导，其应用场景通常较为小众。许多曾高调摒弃关系模型的系统（比如NoSQL），如今也纷纷提供了类SQL接口。这些系统正逐步向RDBMS靠拢和融合。与此同时，SQL则博采众长，吸收了各种查询语言的优秀思想，以支持现代应用并保持其重要地位。
尽管关系模型的基本原理未曾大变，其系统的实现层面却在发生着剧烈的变革。本文第二部分将探讨为应对现代应用和硬件而涌现的DBMS架构新进展：(1) 列式系统，(2) 云数据库，(3) 数据湖/湖仓一体，(4) NewSQL系统，(5) 硬件加速器，以及(6) 区块链数据库。其中一些是对DBMS实现的深刻变革，而另一些则不过是基于错误前提的短暂风潮。
最后，我们将探讨下一代DBMS的重要考量，并就数据库在研究和商业领域的未来，分享一些我们的临别赠言。
2 数据模型与查询语言
我们将数据模型和查询语言的研究与发展归纳为以下八大类进行讨论。
2.1 MapReduce 系统
谷歌在2003年构建其MapReduce（MR）框架，是作为处理其周期性网络爬取任务的“单点解决方案”[122]。当时谷歌在DBMS技术方面经验尚浅，他们构建MR纯粹是为了满足其爬取需求。用数据库的术语来解释，Map是一个执行计算和/或过滤的用户定义函数（UDF），而Reduce则是一个GROUP BY操作。粗略地讲，MR运行的是一个单一查询：
sql
SELECT map() FROM crawl_table GROUP BY reduce()谷歌的MR方法并未规定特定的数据模型或查询语言，而是依赖于开发者用过程化语言编写的Map和Reduce函数来解析和处理数据文件的内容。
在2000年代末，其他公司对基于MR的系统产生了浓厚兴趣。雅虎在2005年开发了Hadoop，一个MR的开源版本。它运行在分布式文件系统HDFS之上，而HDFS本身是谷歌文件系统[134]的克隆。随后，几家初创公司成立，旨在商业化支持Hadoop。下文中，我们将用MR指代谷歌的实现，用Hadoop指代开源版本，它们在功能上大同小异。
关于Hadoop与专为OLAP负载设计的RDBMS孰优孰劣的争论随之而起。这场争论在2009年的一项研究中达到顶峰，该研究表明数据仓库DBMS的性能优于Hadoop[172]。这引发了谷歌和DBMS社区之间激烈的隔空论战[123, 190]。谷歌认为，通过精心设计，MR系统可以击败DBMS，并且用户无需在运行查询前加载带模式的数据，因此MR更适合文本处理和ETL操作这类“一次性”任务。DBMS社区则反驳说，MR的设计本身就存在性能缺陷，而这些问题早已被现有的并行DBMS所解决。此外，在分区表上使用SQL这样的高级语言，早已被证明是一种优秀的编程模型[127]。
两篇论文的许多讨论都集中在实现细节上（如索引、解析、推拉式查询处理、故障恢复）。通读双方观点，一个公允的结论是，两种系统各有其用武之地。然而，技术世界的两大变化使这场辩论失去了意义。
第一个变化是Hadoop的技术和服务市场在2010年代崩盘。许多企业在Hadoop集群上投入巨资，却发现市场对这种能力的需求寥寥。开发者发现很难将应用硬塞进MR/Hadoop这种受限的范式中。业界曾付出巨大努力在Hadoop之上提供SQL和RM接口，其中最著名的就是Meta的Hive[30, 197]。
第二个变化发生在CACM文章发表八个月后：谷歌宣布将其爬取处理从MR迁移到BigTable[164]。原因是谷歌需要实时交互地更新其爬取数据库，而MR是一个批处理系统。最终，谷歌在2014年宣布，MR在其技术栈中已无立足之地，并将其彻底淘汰[194]。
第一个变化使得三大Hadoop供应商（Cloudera、Hortonworks、MapR）失去了可行的商业模式。Cloudera将Hadoop重新定义为整个技术栈（应用、Hadoop、HDFS）。在一系列巧妙的资本运作和产品包装后，Cloudera在HDFS之上构建了一个RDBMS，即Impala[150]，但它并未使用Hadoop。他们意识到Hadoop作为SQL DBMS的内部接口毫无价值，并用直接构建在HDFS上的软件将其从技术栈中剥离出去。同样，MapR直接在HDFS上构建了Drill[22]，而Meta则创建了Presto[185]来取代Hive。
讨论 (Discussion): MR的缺陷是如此致命，以至于尽管开发者社区曾热情拥抱，也无法挽救其颓势。Hadoop大约在十年前就已销声匿迹，只给企业留下了一堆HDFS集群的遗留资产，以及一群致力于从中榨取利润的公司。如今，HDFS也已光环不再，因为企业意识到有更好的分布式存储替代品[124]。与此同时，分布式RDBMS正蓬勃发展，尤其是在云端。
MR系统实现中与可伸缩性、弹性和容错性相关的一些理念，被后来的分布式RDBMS所借鉴。MR还带来了存储计算分离的共享磁盘架构的复兴，这进而催生了开源文件格式和数据湖（见3.3节）。Hadoop的局限性也为Spark[201]和Flink[109]等其他数据处理平台打开了大门。这两个系统最初都是作为MR的更优实现，提供过程式API，但后来都增加了对SQL的支持[105]。
2.2 键值存储
键值（KV）数据模型或许是所有模型中最简单的。它只表示一个二元关系：
(key, value)
KV DBMS将数据集合表示为一个将键映射到值的关联数组。值通常是一个无类型的字节数组（即blob），DBMS对其内容一无所知。应用程序需要自己维护模式，并将值解析成相应的部分。大多数KV DBMS只提供针对单个值的get/set/delete操作。
在2000年代，几家新兴的互联网公司为缓存、会话数据存储等狭窄的应用场景构建了自己的无共享、分布式KV存储。在缓存领域，Memcached[131]是这种方法最著名的例子。Redis[67]则将自己定位为Memcached的替代品，提供了更丰富的查询API和持久化支持。对于更持久的应用数据，亚马逊在2007年创建了Dynamo KV存储[125]。与RDBMS相比，这些系统以功能受限为代价，换取了更高且更可预测的性能。
第二类KV DBMS是嵌入式存储管理器，设计为与上层应用在同一个地址空间中运行。最早的独立嵌入式KV DBMS之一是1990年代初的BerkeleyDB[170]。近期的著名产品包括谷歌的LevelDB[37]，以及后来被Meta分叉出来的RocksDB[68]。
讨论 (Discussion): 与在RDBMS中建立表格所需的繁琐工作相比，键值存储为开发者提供了一种快速“开箱即用”的数据存储方式。当然，在需要处理复杂关系（而非简单的二元关系）的应用中使用KV存储是危险的。如果一条记录需要多个字段，KV存储可能就是个坏主意。这不仅意味着应用必须自己解析记录字段，而且没有二级索引来按值检索其他字段。同样，开发者必须在应用层实现连接或批量获取操作。
为了解决这些问题，一些最初的KV存储系统逐渐演变成了功能更丰富的记录存储。这类系统将不透明的值替换为半结构化的值，如JSON文档。亚马逊的DynamoDB[129]和Aerospike[9]就是这种转变的例子。重新设计一个KV存储以支持复杂数据模型并非易事，而RDBMS却可以毫不费力地模拟KV存储。如果应用需要一个嵌入式DBMS，如今也有功能完备的选择，如SQLite[71]和DuckDB[180]。因此，即使对于简单的应用，RDBMS也可能是更好的选择，因为它为未来应用复杂度的增加提供了一条平滑的演进路径。
过去二十年的一个新架构趋势，是使用嵌入式KV存储作为全功能DBMS的底层存储管理器。在此之前，构建一个新的DBMS需要工程师从头编写一个与DBMS原生集成的自定义存储管理器。MySQL是第一个提供API允许开发者替换其默认存储管理器的DBMS。这个API使得Meta能够构建RocksDB来替换其庞大的MySQL数据库集群中的InnoDB。同样，MongoDB在2014年也放弃了其失败的基于MMAP的存储管理器，转而采用WiredTiger KV存储[120, 138]。使用现有的KV存储，可以让开发者在更短的时间内构建一个新的DBMS。
2.3 文档数据库
文档数据模型将数据库表示为一个记录对象的集合。每个文档包含一个层次化的字段/值对结构，每个字段由一个名称标识，其值可以是标量类型、值数组或另一个嵌套文档。以下JSON示例是一个客户文档，其中包含一个嵌套的订单列表及其对应的订单项。
json
{ "name": "First Last",
"orders": [ { "id": 123, "items": [...]},
{ "id": 456, "items": [...] } ] }几十年来，文档数据模型一直是研究的热点，并催生了SGML[117]和XML[118]等数据格式。尽管在20世纪90年代末XML数据库备受瞩目，但我们在2005年就正确地预测了它们不会取代RDBMS[188]。此后，JSON已超越XML，成为Web应用数据交换的标准格式。JavaScript在开发者中的普及以及JSON的无处不在，促使几家公司在2000年代创建了原生存储JSON的面向文档的系统。
在2000年代，OLTP RDBMS的扩展能力不足，催生了数十个以“NoSQL”[110]为旗号进行营销的文档DBMS。这类系统有两个深得开发者共鸣的营销口号。第一，SQL和连接是缓慢的，应该使用一个“更快”的、更低级的、一次一记录的接口。第二，现代应用不需要ACID事务，因此DBMS只应提供一个较弱的概念（即BASE[179]）。
在这两大推力的作用下，NoSQL逐渐成为了一类存储JSON记录或文档、支持低级API且事务能力较弱或缺失的DBMS的代名词。这类系统有几十个，其中以MongoDB[41]最为流行。
讨论 (Discussion): 文档DBMS与1980年代的面向对象DBMS和1990年代末的XML DBMS本质上并无二致。文档DBMS的支持者提出的论点，与他们的OO/XML前辈如出一辙：将数据存储为文档，可以消除应用代码与关系数据库之间数据表示的“阻抗失配”。他们还声称，将数据反规范化为嵌套结构性能更好，因为它避免了为获取关联数据而发起多个查询的需要（即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]。NoSQL供应商声称他们支持的是自己专有的、源于或受SQL启发的查询语言，而不是完全兼容DDL和DML操作的SQL标准。但对大多数应用而言，这些区别并无实际意义。SQL与其NoSQL衍生物之间的语言差异，大多源于JSON扩展和维护操作。
许多幸存的NoSQL DBMS也增加了强一致性（ACID）事务（见3.4节）。因此，NoSQL的口号已从“别用SQL——它太慢了！”演变为“不止于SQL”（Not Only SQL），即承认SQL在某些情况下是好的。
向NoSQL DBMS添加SQL和ACID，大大缩小了它们与RDBMS在理念上的差距。它们之间的主要区别似乎在于对JSON的原生支持，以及NoSQL供应商允许“模式后置”（schema-on-read）的灵活性。但SQL标准早在2016年就增加了JSON数据类型和操作函数[165, 178]。随着RDBMS不断改善其“最初五分钟”的开发者体验，我们相信这两类系统很快将变得毫无差别。
高级语言几乎总是优于一次一记录的处理方式，因为它们代码量更少，并提供了更高的数据独立性。我们承认早期的SQL优化器确实缓慢且低效，但在过去50年里它们已取得了长足的进步。然而，优化器仍然是构建DBMS中最困难的部分。我们怀疑，这个工程上的巨大挑战，是NoSQL系统最初选择不支持SQL的一个重要原因。
2.4 列族数据库
还有一类NoSQL系统使用一种称为列族（也叫宽列）的数据模型。尽管名为“列”，但列族并非列式存储模型。相反，它是文档模型的一种简化版，只支持一级嵌套而非任意嵌套；它类似于关系表，但每条记录可以有不同的属性，且单元格可以包含一个值数组。以下示例展示了从用户ID到包含不同个人信息的JSON文档的映射：
json
User1000 -> { "name": "Alice",
"accounts": [ 123, 456 ],
"email": "[email protected]" }
User1001 -> { "name": "Bob",
"email": [ "[email protected]", "[email protected]" ] }第一个列族模型DBMS是谷歌在2004年推出的BigTable[111]。谷歌没有采用SQL和当时新兴的列式存储，而是使用了这种数据模型和过程式的客户端API。其他系统为了模仿谷歌的实现也采用了列族模型，最著名的是Cassandra[14]和HBase[28]。它们也复制了BigTable的局限性，包括缺少连接和二级索引。
讨论 (Discussion): 我们在2.3节中关于文档模型的评论在此同样适用。在2010年代初，谷歌在BigTable之上构建了RDBMS，包括MegaStore[99]和第一版Spanner。此后，谷歌重写了Spanner，移除了BigTable的痕迹[98]，如今Spanner已成为其许多内部应用的主力数据库。一些NoSQL DBMS放弃了其专有API，转而支持SQL，但仍保留其非关系型架构。Cassandra用一种名为CQL的类SQL语言替换了其Thrift API[15]，HBase现在则推荐使用Phoenix SQL前端[57]。谷歌仍然将BigTable作为一项云服务提供，但列族模型是一个独特的异类，与其它NoSQL DBMS有同样的缺点。
2.5 文本搜索引擎
文本搜索引擎历史悠久，可追溯到1960年代开创性的SMART系统[184]。SMART开创了信息检索和向量空间模型，这两种技术在现代搜索引擎中几乎无处不在。它通过将文档分词为“词袋”，然后为这些词元构建全文索引（即倒排索引）来支持内容查询。该系统还能识别停用词（如“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之间存在差异。
讨论 (Discussion): 文本数据本质上是非结构化的，这意味着它没有统一的数据模型。相反，DBMS试图从文本中提取结构（即元数据、索引），以避免“大海捞针”式的顺序扫描。在应用中管理文本数据有三种方式。第一，可以同时运行多个系统，例如用Elasticsearch处理文本，用RDBMS处理事务性工作负载。这种方法允许使用“同类最佳”的系统，但需要额外的ETL管道将数据从事务型DBMS推送到文本DBMS，并重写应用以按需将查询路由到正确的系统。第二，可以运行一个集成了良好文本搜索能力的RDBMS，但需要忍受其在SQL中各不相同的API。后一个问题通常由应用框架（如Django Haystack[20]）来隐藏其复杂性。第三个选项是使用一个多存储系统（polystore system）[187]，它通过中间件屏蔽底层系统的差异，提供统一的接口。
基于SMART的倒排索引主要用于精确匹配搜索。近年来，这些方法正逐渐被使用机器学习生成的嵌入向量进行相似性搜索所补充或取代（见2.7节）。
2.6 数组数据库
在许多计算领域，数组是一种天然的数据表示方式。我们用“数组”一词来指代其所有变体[182]：向量（一维，见2.7节）、矩阵（二维）和张量（三维或更多维）。例如，地理区域的科学调查通常将数据表示为一个多维数组，使用时空坐标存储传感器测量值：
(latitude, longitude, time, [vector-of-values])
其他数据集也类似，包括基因组测序和计算流体动力学。数组也是大多数机器学习数据集的核心。
尽管基于数组的编程语言自1960年代（APL[142]）就已存在，但关于数组DBMS的初步工作始于1980年代。PICDMS被认为是第一个使用数组数据模型的DBMS实现[114]。今天仍在开发的两个最古老的数组DBMS是Rasdaman[66, 103]和kdb+[34]。较新的数组DBMS包括SciDB[54, 191]和TileDB[76]。HDF5[29]和NetCDF[46]是科学数据中流行的数组文件格式。
存储和查询真实世界的数组数据集存在几个系统性挑战。最主要的是，数组数据并不总是与规整的整数网格对齐；例如，地理空间数据常被分割成不规则的形状。应用可以通过描述这种映射的元数据将这类网格映射到整数坐标[166]。因此，大多数应用在单个数据库中同时维护数组和非数组数据。
与基于行或列的DBMS不同，在任意维度上查询数组数据带来了独特的挑战。困难源于将多维数组数据存储在像磁盘这样的线性物理介质上。为了克服这些挑战，数组DBMS必须采用特殊的索引和数据结构来支持跨维度的有效遍历。
讨论 (Discussion): 数组DBMS是一个小众市场，仅在特定垂直领域得到应用（我们将在下文讨论向量DBMS）。例如，它们在基因组学领域有相当大的吸引力。HDF5在卫星图像和其他网格化科学数据中很受欢迎。但商业应用很少使用专用的数组DBMS，而商业应用是任何产品生存的命脉。没有主流云提供商提供托管的数组DBMS服务，这意味着他们没有看到一个可观的市场。
数组DBMS供应商一直面临的挑战是，SQL本身就包含了对有序数组作为一等数据类型的支持（尽管这违背了最初的关系模型思想[115]）。第一个将无序的、基于集合的关系模型扩展为有序栅格的提议出现在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 向量数据库
类似于列族模型是文档模型的简化版，向量数据模型可看作是数组数据模型简化到一维的形式。鉴于向量DBMS目前正吸引着开发者和投资者最多的关注（类似于当年的NoSQL热潮），有必要单独讨论它们。这种兴趣源于开发者使用它们来存储由AI工具生成的单维嵌入。这些工具使用学习到的变换将文本、图像等数据转换为表示其潜在语义的向量。例如，可以使用Google BERT将每篇维基百科文章转换为一个嵌入，并将其与文章元数据一同存储在向量数据库中：
(title, date, author, [embedding-vector])
这些嵌入向量的维度从几百（简单模型）到几千（高端模型）不等，并且随着更复杂模型的开发，这个数字显然会不断增长。
向量DBMS和数组DBMS的关键区别在于它们的查询模式。前者专为相似性搜索而设计，用于在高维空间中查找与给定输入向量距离最近的记录。输入向量是使用与填充数据库时相同的模型生成的另一个嵌入。与数组DBMS不同，应用不使用向量DBMS来搜索向量中特定偏移量的值，也不跨多个向量提取切片。相反，其主导用例就是相似性搜索。
为了避免为找到最相似记录而进行暴力扫描，向量DBMS会构建索引来加速近似最近邻（ANN）搜索。应用发出的查询通常同时包含对嵌入索引的搜索和对非嵌入属性（即元数据）的过滤。然后，DBMS需要决策是在向量搜索之前（预过滤）还是之后（后过滤）应用这些非嵌入谓词。
在这个新兴类别中，有数十个新的DBMS，其中Pinecone[58]、Milvus[40]和Weaviate[84]是领先者。文本搜索引擎，包括Elasticsearch[23]、Solr[70]和Vespa[79]，也扩展了其API以支持向量搜索。其他DBMS为了搭上这股潮流，也将自己重新包装为向量数据库，例如Kdb+[34]。
向量DBMS的一个引人注目的特性是，它们与ChatGPT[16]、LangChain[36]等AI工具的集成比RDBMS更好。这些系统原生支持在插入时将记录数据转换为嵌入，然后在查询时使用相同的变换将输入参数转换为嵌入以执行ANN搜索；而其他DBMS则要求应用在数据库外部执行这些转换。
讨论 (Discussion): 与需要定制存储管理器和执行引擎以高效处理多维数据的数组DBMS不同，向量DBMS本质上是带有专门ANN索引的文档DBMS。这类索引是一个特性，而不是新系统架构的基础。
在2022年末LLM随ChatGPT“出圈”后，不到一年时间，几家RDBMS就添加了自己的向量搜索扩展。2023年，许多主要的RDBMS都增加了向量索引，包括Oracle[7]、SingleStore[137]、Rockset[8]和Clickhouse[157]。这与RDBMS对JSON的支持形成了鲜明对比：像MongoDB和CouchDB这样的NoSQL系统在2000年代末开始流行，而RDBMS花了好几年才为其添加支持。
向量索引迅速普及的背后可能有两种解释。第一，通过嵌入进行相似性搜索是一个如此引人注目的用例，以至于每个DBMS供应商都立即推出了自己的版本并大肆宣传。第二，引入新索引数据结构的工程工作量足够小，DBMS供应商添加向量搜索并不费力。他们中的大多数并没有从头编写向量索引，而是集成了一个开源库（例如pgVector[145]、DiskANN[19]、FAISS[24]）。
我们预计，向量DBMS将经历与文档DBMS相同的演变：通过添加更多功能（如SQL、事务、可扩展性）来变得更像关系型系统。与此同时，关系型数据库的巨头们会把向量索引添加到其早已长长的功能列表中，然后转向下一个新兴趋势。
2.8 图数据库
在过去十年中，学术界和工业界对图数据库[183]产生了浓厚兴趣。许多应用使用知识图来建模半结构化信息。社交媒体应用天然就包含图关系（如“点赞”、“好友”）。关系型数据库的设计工具会为用户提供其数据库的实体-关系（ER）模型。ER图本身就是一个图；因此，这个范式有明确的用例。
表示图的两种最流行的方法是（1）资源描述框架（RDF）和（2）属性图[126]。对于属性图，DBMS维护一个支持节点和边上附加键值标签的有向多重图结构。RDF数据库（又称三元组存储）只对带标签的有向图进行建模。由于属性图更常见并且是RDF的超集，我们只讨论前者。我们考虑图数据库MS的两种用例，并讨论限制其应用的问题。
第一类系统用于事务性/OLTP工作负载：例如，一个应用通过（可能以事务方式）更新单个记录在数据库中添加一个好友链接。Neo4j[44]是用于OLTP应用的最流行的图数据库MS。它使用指针来表示边（类似于CODASYL），但它不将节点的“父”或“子”节点物理聚集在一起。这种架构在遍历长边链时有利，因为它通过指针追逐来实现，而RDBMS必须通过连接来完成。但其潜在的商业成功，取决于是否有足够多的“长链”场景，值得用户为此放弃RDBMS。
第二个用例是分析，旨在从图中洞察信息。例如，找出哪个30岁以下的用户拥有最多的朋友。Tigergraph[74]和JanusGraph[32]等著名产品专注于图查询语言和存储。其他系统，如Giraph[26]和Turi[78]（原Graphlab[27]），则提供一个计算框架，以支持图算法的并行执行，这些算法通常由用户编写。
与以连接链为特征的关系型分析查询不同，图分析的查询包含诸如最短路径、割集或团等操作。算法的选择和数据的表示将决定DBMS的性能。这催生了允许开发者使用抽象来编写自己的算法，而无需关心底层系统拓扑的计算框架。然而，先前的研究表明，由于通信成本，分布式图算法很少能胜过单节点实现[160]。一个更好的策略是将图压缩成一个空间高效的数据结构，使其能装入单个节点的内存中，然后对该数据结构运行查询。除了极少数超大规模的图数据库，大多数场景都最好用这种方式处理。
讨论 (Discussion): 无论图数据库MS是针对OLTP还是OLAP工作负载，这些系统都需要克服一个关键挑战：图可以被模拟为表的集合：
Node (node_id, node_data)Edge (node_id_1, node_id_2, edge_data)
这意味着RDBMS永远是支持图应用的一个选项。但是“原生”SQL对于图查询的表达能力不足，导致遍历操作需要多次客户端-服务器往返。
一些RDBMS，包括MSSQL[3]和Oracle[50]，提供了内置的SQL扩展，使存储和查询图数据更容易。其他DBMS则在关系模型之上使用一个转换层来支持图查询API。例如，Amazon Neptune[45]就是构建在Aurora MySQL之上的一个图接口层。Apache AGE则在PostgreSQL之上提供了一个OpenCypher接口[10]。
最近，SQL:2023引入了属性图查询（SQL/PGQ），用于在RDBMS中定义和遍历图[196]。该语法借鉴了现有语言（如Neo4j的Cypher[49]、Oracle的PGQL[51]和TigerGraph的GSQL[75]），并与新兴的GQL标准[126]有共通之处。因此，SQL/PGQ进一步缩小了RDBMS和原生图数据库MS之间的功能差距。
问题在于，图数据库MS供应商能否使其专用系统足够快，以克服上述缺点。已有多项性能研究表明，在RDBMS上的图模拟性能优于原生图数据库MS[130, 143]。最近的工作更表明，DuckDB中的SQL/PGQ性能比领先的图数据库MS高出10倍[196]。随着最坏情况最优连接[132, 168]和用于RDBMS中图查询的因式分解执行算法[100]的进一步改进，这一趋势还将继续。
2.9 总结
从以上各节可以得出一个公允的结论：非SQL、非关系型系统要么是服务于小众市场，要么正在迅速地向SQL/RM系统靠拢。具体来说：
- MapReduce 系统: 多年前就已销声匿迹，如今充其量是一种遗留技术。
- 键值存储: 许多已经演化为关系型系统，或者只用于非常特定的问题。它们通常可以被现代高性能RDBMS匹敌或超越。
- 文档数据库: 此类NoSQL系统正与RDBMS迎头相撞。两类系统之间的差异随着时间推移而减小，未来应该会变得几乎无法区分。
- 列族系统: 仍然是一个小众市场。如果不是因为谷歌，本文甚至不会讨论这个类别。
- 文本搜索引擎: 这些系统通常用于多存储架构中处理文本字段。如果RDBMS能为文本搜索提供更好的原生方案，使其不必成为一个独立的产品，那将极具价值。
- 数组数据库: 科学应用将继续绕过RDBMS，转而使用定制的数组系统。尽管有新的SQL/MDA增强功能，但RDBMS仍无法高效地存储和分析数组，因此数组数据库可能会变得更加重要。
- 向量数据库: 它们是带有特殊索引以加速最近邻搜索的单一用途DBMS。关系型DBMS应该很快就能利用其可扩展类型系统为这些数据结构和搜索方法提供原生支持，这将使这类专用数据库变得多余。
- 图数据库: OLTP图应用将主要由RDBMS提供服务。而分析型图应用有独特的需求，最好在主内存中使用专门的数据结构来处理。RDBMS将在SQL之上或通过扩展提供以图为中心的API。我们不认为专门的图数据库MS能成为一个大的市场。
除此之外，还有一些提议将过去的数据模型重新包装成新奇的概念。例如，图-关系模型[158]与语义数据模型[202]并无二致。同样，文档-关系模型就是带有外键的文档模型[199]。另一些则在RDBMS之上提供非SQL的接口层（例如PRQL[64]、Malloy[39]）。虽然这些语言解决了一些SQL的痛点，但它们还不足以撼动SQL根深蒂固的用户基础和生态系统。
3 系统架构
在过去二十年中，为适应应用和硬件特性的变化，DBMS架构涌现出许多重要的新思想。这些思想良莠不齐，我们依次进行探讨。
3.1 列式系统
要理解列式DBMS的吸引力，我们需要回顾一下数据仓库（OLAP）市场的起源。从1990年代中期开始，企业开始收集其面向客户的数据（通常是销售数据）。沃尔玛等实体零售商是构建历史销售数据库的先行者。这些公司普遍发现，一个销售数据仓库可以在六个月内通过优化库存订购和周转决策收回成本。此类面向客户的数据库如今在企业中已无处不在。
数据仓库应用具有区别于OLTP工作负载的共同属性：
- 历史性：数据定期加载，之后基本为只读。
- 海量性：组织会尽可能长时间地保留所有数据，规模从TB到PB不等。
- 查询特性：查询通常只访问表中的少数几列，并且多为即席查询。
Ralph Kimball是星型模式数据建模在数据仓库中应用的早期倡导者[148, 149]。其核心思想是构建一个包含商品级交易数据的事实表。一个经典的例子是包含零售企业中每个售出商品记录的事实表。然后，用维度表围绕事实表，这些维度表包含从事实表中分解出来的公共信息以节省空间。在零售场景中，这些维度表将包含有关客户、产品、商店和时间的信息。
按列而不是按行组织DBMS的存储有几个好处[87]。首先，压缩列式数据比行式数据更有效，因为一个数据块中只包含单一类型的值，通常有很多重复。其次，传统的Volcano风格引擎中，每个操作符一次处理一行；相比之下，列式引擎有一个内循环，可以使用向量化指令一次性处理整列数据[106, 147]。最后，行存储为每条记录都维护一个较大的头部（例如20字节）来跟踪空值和版本元数据，而列存储每条记录的存储开销则小得多。
讨论 (Discussion): 在过去二十年中，所有活跃在数据仓库市场的供应商都已将其产品从行存储转换为列存储。这一转变为DBMS设计带来了根本性的变化。此外，几家新供应商也带着列存产品进入市场，例如亚马逊的Redshift[94]和谷歌的BigQuery[162]，以及来自独立公司（如Snowflake[121]）的产品。
总而言之，列存储是具有专门优化器、执行引擎和存储格式的新型DBMS实现。它们凭借卓越的性能，已经占领了数据仓库市场。
3.2 云数据库
2000年代末云平台的兴起也极大地影响了DBMS的实现（和销售模式）。最初的云DBMS产品只是将本地系统重新打包到带有直连存储的托管虚拟机中。但在过去二十年里，网络带宽的增长速度远快于磁盘带宽，这使得网络附加存储（NAS）成为直连存储的一个极具吸引力的替代方案。这引发了对云上DBMS架构的深刻反思。
所有主流云供应商都通过对象存储（如Amazon S3）提供NAS，并附带一些DBMS功能（如复制、过滤）。除了比直连存储更经济外，对象存储还有几个优势，足以弥补增加的网络延迟成本。首先，由于计算节点与存储节点分离，系统可以实现按查询弹性伸缩；DBMS可以动态添加新的计算节点而无需重新组织数据。它还允许DBMS为其存储节点和计算节点使用不同的硬件。其次，如果DBMS利用率不足，系统可以将计算节点重新分配给其他任务。而在无共享（shared-nothing）DBMS中，一个节点必须始终在线以处理请求。最后，将计算下推到存储节点是可行的（并且通常是有利的）。这种执行策略被称为“将查询推向数据”而非“将数据拉向查询”，在DBMS中早已是成熟技术。
通常，前两个思想被称为“无服务器计算”（Serverless），并由云原生DBMS Snowflake[121]率先引入。其他供应商已经或正在转向为其云产品提供无服务器环境。要有效利用此模型，需要在托管的多节点环境中，将多个DBMS客户分组到同一物理节点上，并采用多租户执行方案。
讨论 (Discussion): 云数据库的出现是“周而复始”的又一个例子。多节点共享磁盘DBMS是一个古老的思想，历史上效果不佳。然而，随着技术变革（更快的网络）和向云的迁移，它又重新焕发生机。此外，分时服务在1970年代当计算机庞大而昂贵时曾风靡一时。云平台本质上就是大型分时服务，所以这个概念在几十年后又回来了。由于企业正将一切尽可能地迁移到云端，我们预计这种存储计算分离的共享磁盘架构将主导DBMS架构。因此，我们不认为无共享架构在未来会复苏。
云深刻地影响了DBMS，促使其被完全重新架构。计算从本地迁移到云端，为企业重构代码库、摆脱历史技术包袱提供了一生一次的机会。云环境还为供应商提供了几个在本地部署中不可能实现的优势。最重要的是，供应商可以追踪其所有客户的使用趋势：他们可以监控异常行为、性能下降和使用模式。此外，他们可以在不中断服务的情况下推送增量更新和代码补丁。
从商业角度看，开源DBMS面临着一个风险：一旦变得过于流行，就可能被主要云提供商“白嫖”和商业化。亚马逊与MongoDB[153]和Elasticsearch[101]等独立软件供应商（ISV）之间的公开争执就是显著的例子。
3.3 数据湖/湖仓一体
云平台推动的另一个趋势是从用于OLAP工作负载的单一、专用数据仓库，转向由对象存储支持的数据湖。在传统的数据仓库中，组织将数据加载到DBMS中，系统以专有格式将其存储在托管存储上。供应商将其DBMS视为组织中所有数据事务的“守门人”。然而，在过去十年里，这已不再是许多组织（尤其是科技公司）的模式。
在使用数据湖架构时，应用程序将文件直接上传到分布式对象存储，绕过了通过DBMS的传统路径[167]。然后，用户使用一个**湖仓（lakehouse）**执行引擎[93]在这些累积的文件上执行查询和处理。这些湖仓系统为SQL和非SQL工作负载提供统一的基础设施支持。后者至关重要，因为过去十年表明，数据科学家和ML从业者通常使用基于Python的笔记本，通过Pandas的DataFrame API[159]而非SQL来访问数据。有几个项目致力于用DBMS的方法来优化DataFrame处理，包括Dask[181]、Polars[61]、Modin[177]和Bodo[198]。
应用程序不再使用DBMS特定的专有文件格式或低效的文本文件（如CSV, JSON），而是使用开源的、面向磁盘的列式文件格式[203]将数据写入数据湖。两种最流行的格式是Twitter/Cloudera的Parquet[55]和Meta的ORC[53, 140]。它们都借鉴了早期列式存储研究的技术，如PAX[90]、压缩[87]和嵌套数据（JSON）切分[121, 161]。Apache Arrow[11]是一个用于在系统间交换内存中数据的类似二进制格式。用于读/写这些格式的开源库，使得不同应用创建的数据文件可以被其他系统解析和消费，从而促进了跨服务和业务单元的数据共享。
讨论 (Discussion): 数据湖是2010年代初“大数据”运动的继承者，其兴起部分归功于MR系统（2.1节）和列存储（3.1节）的普及。乍一看，数据湖对一个组织来说似乎是个糟糕的主意：允许任何应用将任意文件写入一个集中式存储库而没有任何治理，这无疑是导致数据完整性、可发现性和版本控制问题的温床[167]。湖仓为这些环境提供了急需的治理能力，通过元数据、缓存和索引服务来缓解许多问题[93]。用于跟踪新数据并支持事务性更新的额外中间件，如Delta Lake[92]、Iceberg[6]和Hudi[5]，使湖仓看起来更像传统的数据仓库。
数据湖给查询优化带来了新的挑战。DBMS获取精确的数据统计信息一直都很困难，这会导致查询计划选择不佳[154]。而在数据湖中，系统可能完全缺乏新摄入文件的统计信息。因此，在云中采用自适应查询处理策略至关重要，这使DBMS能够根据观察到的数据特性动态修改查询计划[97, 105, 163]。
所有主要的云供应商现在都提供某种形式的托管数据湖服务。由于基于对象存储的数据湖系统每GB成本远低于专有数据仓库，传统的OLAP供应商（如Teradata、Vertica）已扩展其DBMS以支持从对象存储读取数据，来应对这种价格压力。这个领域也有几个独立的系统，包括Databricks[105]、Dremio[21]、PrestoDB[63]和Trino[77]。
3.4 NewSQL 系统
在2000年代末，已有多种分布式NoSQL DBMS可用于水平扩展，以支持拥有海量并发用户的在线应用[110]。然而，许多组织无法使用这些NoSQL系统，因为他们的应用无法放弃对强事务性的要求。但当时现有的RDBMS（尤其是开源的）无法（原生）跨多台机器扩展。作为回应，NewSQL系统在2010年代初应运而生，旨在为OLTP工作负载提供NoSQL系统的可伸缩性，同时仍然支持SQL[95, 171]。换句话说，这些新系统试图实现2000年代NoSQL DBMS同样的可伸缩性，但保留1990年代传统DBMS的关系模型和ACID事务。
NewSQL系统主要有两类。第一类是内存DBMS，包括H-Store[144, 189]（商业化为VoltDB[83]）、SingleStore[69]、Microsoft Hekaton[128]和HyPer[146]。其他初创公司的产品包括面向磁盘的分布式DBMS，如NuoDB[47]和Clustrix[17]。
讨论 (Discussion): NewSQL DBMS的采用并未出现爆炸式增长[96]。这种不温不火的局面，原因在于当时现有的DBMS已经“足够好”，这意味着组织不愿意承担将现有应用迁移到新技术所带来的成本和风险。公司在更换OLTP DBMS方面比OLAP系统要谨慎得多。如果OLTP DBMS宕机，公司就无法执行产生收入的核心业务。相比之下，OLAP DBMS的故障可能只是给分析师或数据科学家带来暂时的不便。
NewSQL DBMS还有其他限制，例如只支持标准SQL的子集，或者在多节点事务上性能不佳。一些NewSQL产品，如微软的Hekaton，仅作为传统DBMS的扩展提供，要求更快的引擎必须通过更慢的DBMS接口进行交互。
NewSQL供应商还错误地预测了内存DBMS在过去十年的普及程度。闪存供应商在降低成本的同时，大幅提高了存储密度、带宽和I/O性能。而DRAM成本居高不下以及持久性内存（如Intel Optane）的失败，意味着SSD将继续在OLTP DBMS中占据主导地位。
NewSQL运动的余波是催生了一批新的分布式、事务性SQL RDBMS。这些包括TiDB[141]、CockroachDB[195]、PlanetScale[60]（基于Vitess分片中间件[80]）和YugabyteDB[86]。主要NoSQL供应商在过去十年中也为其系统增加了事务功能，尽管之前曾强烈声称事务是不必要的。做出这一转变的著名DBMS包括MongoDB、Cassandra和DynamoDB。这当然是由于客户要求事务所致——事务实际上是必需品。谷歌在2012年放弃最终一致性，转而在Spanner中支持强一致性事务时，雄辩地证明了这一点[119]。
3.5 硬件加速器
在过去50年里，人们一直在寻找一种经济高效的DBMS硬件加速器。其前景显而易见：为DBMS设计的专用硬件理应能轻松胜过通用CPU。
在1980年代，供应商制造了定制硬件来加速DBMS，并将其作为“数据库机”[107]进行营销。Britton-Lee在1981年发布了第一款商用加速器产品（IDM/500）[192]，其中包含一个传统CPU和一个硬件加速器，该加速器可以卸载一部分查询执行。这个加速器只针对执行路径的一小部分，并不划算。Teradata也推出了自己的数据库机，提供了用于对元组流进行排序的网络硬件（Y-net[1]），但后来为了一个纯软件解决方案而放弃了它[85]。1980年代所有其他定制硬件DBMS加速的尝试都失败了。
在过去二十年里，人们不再构建定制的DBMS硬件，而是致力于使用商用硬件（FPGA、GPU）来加速查询。这是一个诱人的想法：供应商可以在不承担制造硬件成本的情况下，获得DBMS加速器的好处。
Netezza是1990年代末从PostgreSQL分叉出来的首批基于FPGA的DBMS之一。它使用FPGA加速对磁盘页面的扫描，但最初无法扫描内存中的页面。Netezza在后来的版本中修正了这一限制[2]。Swarm64曾试图为PostgreSQL销售一款FPGA加速器，但在被收购前也转向了不带FPGA的纯软件架构[91]。Vitesse的Deepgreen DB[81]是ISV提供的唯一剩下的FPGA增强型DBMS。
GPU加速的DBMS市场则要热闹得多。著名的GPU DBMS包括Kinetica[35]、Sqream[35]、Brytlyt[13]和HeavyDB[48]。如果数据无法完全放入GPU内存，查询执行的瓶颈就在于将数据加载到设备中，这使得硬件的并行化优势荡然无存。
讨论 (Discussion): 从以上分析中，我们可以得出几个结论。首先，这些系统都专注于OLAP市场，并且只针对RDBMS；本节的讨论基本上与数据模型无关。其次，OLAP工作负载将继续积极地向云迁移，但专用硬件除非由云供应商自己构建，否则不太可能被市场接受。
仅为DBMS创建定制硬件对大多数公司来说并不划算。商用硬件避免了这个问题，但仍然存在将硬件集成到DBMS中的挑战。GPU DBMS比FPGA系统更多的原因在于，有现成的支持库可用于GPU（如Nvidia CUDA[169]）。但由于规模经济，基于CPU的云计算资源非常便宜。任何加速器的成功可能都将局限于本地部署的数据库，但这个市场的增长速度远不如云数据库。
即使能够将一款性能比现有技术有数量级提升的加速器推向市场，那也只解决了成功所需问题的一半。一个纯硬件公司必须找到人来为其加速器在DBMS中添加支持。如果加速器是DBMS的可选附加组件，那么采纳率会很低，DBMS供应商自然不愿意投入工程资源来支持它。如果加速器是DBMS的关键组件，那么没有哪个供应商会愿意将如此重要的部分外包给外部公司。
定制硬件加速器唯一能成功的地方是在大型云供应商内部。他们可以为其庞大的业务规模来分摊5000万至1亿美元的定制硬件研发成本。他们还控制着整个技术栈（硬件和软件），并能将硬件集成在最关键的位置。亚马逊已经通过其Redshift AQUA加速器[102]做到了这一点。谷歌BigQuery在内存数据混洗（shuffle）方面也有定制硬件组件[89]。
尽管困难重重，我们预测在未来二十年里，这个领域仍将有许多新的尝试。
3.6 区块链数据库
在撰写本文时，一个正在退潮的数据库技术热潮是区块链。这些是去中心化的、日志结构的数据库（即账本），使用某种Merkle树的变体来维护增量校验和。这些增量校验和是区块链确保数据库日志不可变的方式：应用程序使用这些校验和来验证以前的数据库更新没有被篡改。
区块链数据库的理想用例是任何人都无法相互信任的对等应用。没有中央权威来控制数据库更新的顺序。因此，区块链实现使用拜占庭容错（BFT）共识协议来确定下一个应用于数据库的事务。
目前，加密货币（比特币）是区块链唯一的实际用例。此外，有人尝试在区块链之上构建可用的DBMS，著名的有Fluree[25]、BigChainDB[12]和ResilientDB[136]。这些供应商（错误地）宣传区块链提供了以前DBMS无法提供的更强的安全性和可审计性。
讨论 (Discussion): 在当今社会，我们被要求信任多个实体。当一个人卖房子时，他们信任产权公司来管理交易。唯一没有现实世界信任的应用场景是暗网互动（如洗钱）。合法的企业不愿意为了使用区块链DBMS而付出巨大的性能代价（大约五个数量级）。如果组织之间可以相互信任，他们完全可以更高效地运行一个共享的分布式DBMS，而不必在区块链上浪费时间。据我们所知，所有主要的加密货币交易所都在传统的RDBMS上运行其业务，而不是区块链系统。
区块链的支持者还提出了更多关于通过在对等环境中复制来实现数据弹性的无稽之谈。没有理智的公司会依赖互联网上的随机参与者，来作为其关键任务数据库的备份方案。
私有区块链DBMS或许有一个（很小）的市场。亚马逊的量子账本数据库（QLDB）于2018年发布[65]，它提供了与区块链相同的不可变和可验证的更新保证，但它不是去中心化的（即没有BFT共识协议）。亚马逊在发现完全去中心化的区块链DBMS没有令人信服的用例后，才构建了QLDB[108]。
3.7 总结
数据库系统中主要技术趋势的关键要点如下：
- 列式系统: 向列式存储的转变彻底改变了OLAP DBMS架构。
- 云数据库: 云颠覆了关于如何构建可扩展DBMS的传统智慧。除了嵌入式DBMS，任何不以云产品为起点的产品都可能失败。
- 数据湖/湖仓一体: 使用开源格式的、基于云对象存储的湖仓架构，将是未来十年OLAP DBMS的主流形态。
- NewSQL系统: 它们带来了新思想，但尚未产生与列式和云DBMS同等的影响。它催生了支持更强ACID语义的新一代分布式DBMS，以对抗NoSQL较弱的BASE保证。
- 硬件加速器: 我们看不到在主要云供应商之外的专用硬件用例，尽管初创公司会继续尝试。
- 区块链数据库: 一种正在寻找应用场景的低效技术。历史表明，这是开发系统的错误方式。
4 临别赠言
我们对过去二十年数据库的分析，有几个核心观点。不幸的是，其中一些只是2005年论文中警告的重申。
永远不要低估“烂产品，好营销”的威力。 数据库市场竞争激烈且利润丰厚。这种竞争驱使供应商宣称他们的新技术将解决所有问题并改变开发者的生活。每个开发者都或多或少被数据库折腾过，所以他们特别容易接受这种营销。尽管当时有更好的选择，但一些劣质的DBMS产品通过强大的营销取得了成功：Oracle在1980年代做到了，MySQL在2000年代做到了，MongoDB在2010年代做到了。这些系统在早期获得了足够的市场关注，为自己赢得了宝贵的时间，来偿还早期积累下的技术债。
警惕源自大型“非数据库”公司的数据库产品。 过去十年数据库领域一个有趣的现象是，科技公司内部孵化DBMS，然后将其作为开源项目剥离出来的趋势。所有这些系统最初都是为某家科技公司的特定应用量身定制的。然后，公司将DBMS作为开源项目发布（通常推向Apache基金会托管），希望从外部用户那里获得“免费”的开发资源。
有时它们来自能够负担得起开发新系统的大公司。著名的例子包括Meta（Hive[197]、Presto[63]、Cassandra[14]、RocksDB[68]）和LinkedIn（Kafka[33]、Pinot[59]、Voldemort[82]）。其他系统则来自构建数据密集型产品的初创公司，他们觉得自己也需要顺便构建一个DBMS。最成功的例子是10gen（MongoDB）和PowerSet（HBase），但也有许多失败的尝试。
这种避免使用外部软件的趋势，部分源于许多公司的“非我发明”（Not Invented Here）综合征，以及其晋升机制更偏爱那些打造了新内部系统的工程师，即使现有工具已经足够。但这种偏见导致许多没有DBMS工程经验的团队承担了构建新系统的任务。当一家公司首次将这类系统开源时，我们应该保持警惕，因为它们几乎总是技术不成熟的。
不要忽视“开箱即用”的体验。 许多非关系型DBMS的一个显著卖点是比RDBMS更好的“开箱即用”体验。大多数SQL系统要求用户先创建一个数据库，再定义表，然后才能加载数据。这就是为什么数据科学家更喜欢使用Python笔记本快速分析数据文件的原因。因此，每个DBMS都应该能轻松地对本地和云存储中的文件进行原地查询。DuckDB[180]日益增长的普及，部分就归功于其在这方面的出色表现。
供应商还应考虑客户在使用数据库时不可避免会面临的其他挑战，包括物理设计、参数调优、模式设计和查询调优。我们中有一人称之为“自动驾驶”数据库（self-driving DBMSs）[173]，这方面存在着迫切的需求。
开发者需要直接查询他们的数据库。 过去二十年创建的大多数OLTP应用，主要通过抽象层与数据库交互，例如API端点（如REST、GraphQL）或对象-关系映射器（ORM）库。这些层将应用的高级请求转换为数据库查询。ORM还自动处理模式迁移等维护任务。有人可能会说，既然OLTP开发者从不写原生SQL，他们的DBMS使用什么数据模型并不重要，因为这些层已经屏蔽了底层细节。
ORM是快速原型开发的利器，但它们通常为了与多个DBMS兼容而牺牲了将复杂逻辑下推到数据库的能力。当自动生成的查询性能不佳时，开发者最终还是会回过头来手写SQL。这就是为什么使用支持SQL的RDBMS是更好的选择。
AI/ML 将对 DBMS 产生深远影响。 DBMS应如何与现代AI/ML工具交互，最近已成为一个关键问题，尤其是在LLM（如ChatGPT）出现之后。尽管这个领域发展迅速，我们还是提供一些初步的看法。
由于LLM在将自然语言（NL）转换为SQL等代码方面的进步[133]，使用自然语言查询数据库的兴趣再度兴起。有些人甚至认为，这类由AI驱动的查询接口将使SQL过时。自然语言接口是一个可以追溯到1970年代的古老研究课题[139]，但历史上成果不佳，应用不广[88]。我们承认LLM在这项任务上取得了令人印象深刻的成果，但仍要告诫那些认为NL将取代SQL的人。没有人会用NL编写OLTP应用，因为大多数应用使用ORM生成查询。对于OLAP数据库，NL可能有助于构建探索性分析的初始查询。然而，这些查询结果应被提交给一个类似仪表盘的精化工具，因为英语和其他自然语言充满了歧义和不确定性。
在企业内部，特别是在处理财务数据时，人们不愿意依赖当前的LLM技术进行决策。最大的问题是LLM的输出对人类来说是不可解释的。其次，LLM系统比“传统”ML系统（如随机森林、贝叶斯模型）需要更多的训练数据。公司通常无法将这些模型的训练数据创建外包给非专业人员。由于这些原因，LLM在企业数据上的采纳将会是谨慎而缓慢的。
最后，最近有大量关于使用AI/ML来优化DBMS自身的研究[174]。例子包括面向ML的查询优化器[152, 156]、配置调优器[200, 204]和访问方法[151, 193]。尽管这类ML辅助的优化是提高DBMS性能的强大工具，但它并不能替代高质量的系统工程本身。
5 结论
我们预测，数据库世界“周而复始”的现象将在未来几十年继续上演。总会有新一代的开发者宣称SQL和关系模型对于新兴应用领域来说已经不够用。然后人们会提出新的查询语言和数据模型来解决这些“问题”。探索DBMS的新思想和新概念本身极具价值（这正是SQL能够汲取养分、获得新功能的源泉），数据库研究社区和市场也因此而更加健壮。然而，我们不期望这些新的数据模型会取代关系模型。
另一个担忧是，新项目在重复造轮子上浪费了大量精力，去实现那些虽不新颖、但对一个生产级DBMS必不可少的组件（如配置处理器、解析器、缓冲池）。为了加速下一代DBMS的发展，社区应该促进开源可复用组件和服务的开发[112, 176]。在这方面已经有一些努力，包括文件格式（见3.3节）、查询优化（如Calcite[104]、Orca[186]）和执行引擎（如DataFusion[18]、Velox[175]）。我们认为，数据库社区应该努力争取一个类似POSIX的DBMS内部标准，以加速互操作性。
我们告诫开发者要从历史中学习。换句话说，要站在前人的肩膀上，而不是踩在他们的脚趾上。我们中的一位届时或许尚在人世，且刚保释出狱，所以我们完全有理由相信，届时会续写本文的2044版。
参考文献 (References)
[参考文献部分保持原文]