本文为数据库 20 年发展与展望的下篇。

3 数据库系统架构

在过去二十年中，DBMS架构出现了重大的新思想，这些思想反映了应用和硬件特性的变化。这些想法从非常好的到值得怀疑的都有，我们将依次讨论它们。

3.1 列式系统

为了理解列式DBMS的吸引力，我们需要解释数据仓库（OLAP）市场的起源。从20世纪90年代中期开始，企业开始收集他们面向客户的（通常是销售）数据。实体零售商（例如，沃尔玛）在构建历史销售数据库方面处于前列。这些公司通常发现，销售数据仓库在六个月内通过更好的库存订购和轮换决策就能收回成本。这种面向客户的数据库现在在企业中无处不在。

数据仓库应用有一些与OLTP工作负载不同的共同属性：

1. 它们本质上是历史的（即，它们定期加载后就是只读的）。

2. 只要他们负担得起存储，组织就会保留一切 - 想想从TB到PB。

3. 查询通常只访问表中的一小部分属性，并且是即席性(ad-hoc)的。

Ralph Kimball是数据仓库的星型模式数据建模的早期支持者[148, 149]。这个想法是构建一个包含项目级交易数据的事实表。经典的例子是一个事实表，其中包含零售企业中每次购买的项目记录。然后，围绕事实表构建维度表，包含从事实表中提取的共同信息以节省空间。同样，在零售环境中，这些维度表将包括有关客户、产品、商店和时间的信息。

通过按列而不是按行组织DBMS的存储有多个好处[87]。首先，压缩列式数据比基于行的数据更有效，因为数据块中通常有单一的值类型，经常有许多重复的字节。其次，Volcano风格的引擎每行执行一次操作符。相比之下，列式引擎有一个内循环，使用向量化指令处理整个列[106, 147]。最后，行存储每个记录都有一个大的头部（例如，20字节）来跟踪空值和版本元数据，而列存储每个记录的存储开销很小。

讨论：在过去二十年中，所有在数据仓库市场活跃的供应商都已经将他们的产品从行存储转换为列存储。这种转变带来了DBMS设计上的显著变化。此外，在过去二十年中，有几家新的供应商进入了市场，提供了列存储产品，例如亚马逊的Redshift[94]和谷歌的BigQuery[162]，以及独立公司的提供（例如，Snowflake[121]）。

总结来说，列存储是新的DBMS实现，具有专门的优化器、执行器和存储格式。它们已经接管了数据仓库市场，因为它们具有卓越的性能。

3.2 云数据库

2000年代末云平台的兴起也极大地影响了DBMS的实现（和销售模式）。最初的云DBMS提供将本地系统重新打包到带有直接附加存储的托管虚拟机中。但是在过去二十年中，网络带宽的增长速度远远超过了磁盘带宽，使得网络附加存储（NAS）作为一种替代附加存储的方案变得具有吸引力。这导致了人们对云环境下的DBMS架构进行了深刻的反思。

所有主要的云供应商都通过对象存储提供NAS（例如，亚马逊S3），并带有一些DBMS功能（例如，复制、过滤）。除了与直接附加存储相比具有更好的经济性外，对象存储还有几个优势，可以弥补增加的网络链接的成本。首先，由于计算节点与存储节点分离，系统可以提供每个查询的弹性；DBMS可以动态添加新的计算节点而无需重新 reshuffler 数据。它还允许DBMS为其存储节点使用与计算节点不同的硬件。其次，如果DBMS未充分利用，系统可以将计算节点重新分配给其他任务。另一方面，在shared-nothing DBMS中，节点必须始终在线以处理传入的查询请求。最后，将计算下推到存储节点是可行的（通常也是有利的）。这种执行策略被称为“将查询下推到数据”，和“将数据拉到查询”是相对的，这在DBMS中被很好地理解。

通常，前两个想法被称为“serverless computing”，由Snowflake[121]为云原生DBMS引入。其他供应商已经或正在将其云产品转移到 serverless 环境中。有效利用这种模型需要一个托管的多节点环境，在该环境中，多个DBMS客户被分组到具有多租户执行方案的相同节点上。

讨论：云数据库的出现是“历史轮回”的另一个例子。多节点共享磁盘DBMS是一个古老的想法，历史上往往效果不佳。然而，随着技术变革（更快的网络）和向云的迁移，它又重新流行起来。此外，在20世纪70年代，当计算机庞大且昂贵时，分时服务很受欢迎。云平台是大型分时服务，所以这个概念在几十年后又回来了。由于企业正在将一切可能的东西迁移到云端，我们预计这种共享磁盘将主导DBMS架构。因此，我们不认为未来会出现shared-nothing架构。

云计算对DBMS产生了深远的影响，导致它们被彻底重新架构。计算从本地迁移到云端为企业提供了一个千载难逢的机会，可以重构代码库并消除过去糟糕的技术决策。云环境还为供应商提供了一些在本地部署中不可能实现的优点。他们可以为所有客户跟踪趋势：他们可以监控意外行为、性能下降和使用模式。此外，他们可以在不中断服务的情况下推送增量更新和代码补丁。从商业角度来看，开源DBMS面临着变得过于流行并被主要云提供商货币化的危险。亚马逊与MongoDB[153]和Elasticsearch[101]等ISV之间的公开争执就是显著的例子。

3.3 数据湖 / Lakehouses

云平台促进的另一个趋势是从单一的、专用的数据仓库转向由对象存储支持的数据湖。使用传统的数据仓库，组织将数据加载到DBMS中，系统将数据存储在具有专有格式的存储引擎中。供应商将他们的DBMS视为组织中与数据相关的所有事物的“守护者”。然而，这在过去的十年中，尤其是在科技公司中，并不是许多组织的模型。

采用数据湖架构，应用程序将文件上传到分布式对象存储，绕过了通过DBMS的传统途径[167]。然后，用户使用累积的文件执行查询和处理管道，使用lakehouse（湖仓一体，数据仓库和数据湖的混合词）执行引擎[93]。这些lakehouse系统提供了统一的基础设施，支持SQL和非SQL工作负载。这一点至关重要，因为过去十年表明，数据科学家和机器学习从业者通常使用基于Python的notebook，使用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]是一个类似的二进制格式，用于在系统之间交换内存中的数据。用于读取/写入这些格式的开源库允许不同的应用程序创建数据文件，然后由其他系统解析和使用，从而增强了服务和业务单位之间的数据共享。

讨论：数据湖是2010年代早期“大数据”运动的继承者，部分由MR系统（第2.1节）和列存储（第3.1节）的普及推动。乍一看，数据湖对于组织来说似乎是一个糟糕的主意：允许任何应用程序将任意文件写入中央存储库，而没有任何治理，这会导致完整性、发现和版本控制问题[167]。湖仓为这些环境提供了急需的控制，有助于缓解许多与元数据、缓存和索引服务相关的问题[93]。额外的中间件，如Delta Lake[92]、Iceberg[6]和Hudi[5]，可以跟踪新数据并支持事务更新，使湖仓看起来更像传统的数据仓库。

数据湖给查询优化带来了新的挑战。数据库管理系统（DBMS）在获取数据的精确统计信息方面一直存在困难，导致查询计划选择不佳[154]。然而，数据湖系统可能完全缺乏对新摄入数据文件的统计信息。因此，在云中采用自适应查询处理策略势在必行，以使DBMS能够根据观察到的数据特征在执行过程中动态修改查询计划[97, 105, 163]。

所有主要的云供应商现在都提供某种形式的管理数据湖服务。由于基于对象存储的数据湖系统每千兆字节的成本比专有数据仓库要低得多，传统的OLAP供应商（例如Teradata、Vertica）已经扩展了他们的DBMS，以支持从对象存储中读取数据，以应对这种定价压力。此外，还有一些独立的系统也在这个领域，包括Databricks[105]、Dremio[21]、PrestoDB[63]和Trino[77]。

3.4 NewSQL 系统

在2000年代末，有多个分布式NoSQL数据库管理系统（DBMS）可供使用，它们被设计为水平扩展，以支持大量并发用户的在线应用程序[110]。然而，许多组织无法使用这些NoSQL系统，因为他们的应用程序不能放弃强事务性需求。但现有的关系型数据库管理系统（RDBMS）（尤其是开源的）无法（原生）跨多台机器扩展。作为回应，NewSQL系统在21世纪10年代初出现，寻求为在线事务处理（OLTP）工作负载提供NoSQL系统的可扩展性，同时仍支持SQL[95, 171]。换句话说，这些新系统试图实现21世纪00年代NoSQL DBMS的相同可扩展性，但仍保留20世纪90年代传统DBMS的关系模型（RM）和ACID事务。

NewSQL系统主要分为两类。第一类是内存DBMS，包括H-Store[144, 189]（商业化为VoltDB[83]）、SingleStore[69]、Microsoft Hekaton[128]和HyPer[146]。其他初创公司提供的包括面向磁盘的分布式DBMS，如NuoDB[47]和Clustrix[17]。

讨论：NewSQL DBMS的采用尚未出现爆发式的增长[96]。这种兴趣不足的原因是现有的DBMS在当时已经足够好，这意味着组织不愿意承担将现有应用程序迁移到新技术的成本和风险。公司在更换OLTP DBMS时比OLAP更为担心风险。如果OLTP DBMS失败，公司将无法执行他们需要的交易来产生收入。相比之下，OLAP DBMS的故障可能仅限于暂时给分析师或数据科学家带来不便。

NewSQL DBMS还有其他限制，例如只支持标准SQL的子集或在多节点事务上表现不佳。一些NewSQL产品，如Microsoft的Hekaton，只能作为遗留DBMS的扩展使用，要求更快的引擎使用较慢DBMS的接口。

NewSQL供应商还错误地预判过去十年内存DBMS的采用会更大。Flash供应商降低了成本，同时提高了存储密度、带宽和延迟。更高的DRAM成本和持久性内存（例如，Intel Optane）的崩溃意味着SSD将保持为OLTP DBMS的主导地位。

NewSQL的余波是一批新的分布式、事务性SQL RDBMS的出现。这些包括TiDB[141]、CockroachDB[195]、PlanetScale[60]（基于Vitess分片中间件[80]）和YugabyteDB[86]。在过去的十年中，主要的NoSQL供应商也在他们的系统中增加了事务，尽管他们之前曾强烈声称事务是不必要的。值得注意的DBMS包括MongoDB、Cassandra和DynamoDB。这当然是由于客户的请求，事实证明事务确实是必要的。Google在2012年放弃最终一致性，转而使用Spanner进行真实事务时，就明智地说过这一点[119]。

3.5 硬件加速器

在过去的50年里，人们一直在寻找一种经济高效的硬件加速器来用于数据库管理系统（DBMS）。其前景显而易见：为DBMS设计的专用硬件应该能够轻松超越传统CPU的性能。

在1980年代，供应商制造了定制硬件来加速DBMS，并将它们作为数据库机器[107]进行市场推广。Britton-Lee在1981年发布了第一个商业加速器产品(IDM/500)[192]，其中包含一个传统CPU和一个硬件加速器，用于卸载查询执行的部分。这个加速器针对执行路径的一小部分，并且成本效益不高。Teradata推出了自己的数据库机器，提供了用于在in-flight元组中排序的网络硬件(Y-net[1])，但它被一个纯软件解决方案所取代[85]。1980年代所有其他的定制硬件DBMS加速都失败了。

过去20年的趋势不是为数据库管理系统（DBMS）构建定制硬件，而是使用通用硬件（如现场可编程门阵列（FPGA）、图形处理器（GPU））来加速查询。这是一个诱人的想法：供应商可以在不花费制造硬件成本的情况下获得DBMS加速器的好处。

Netezza是最早的基于FPGA的DBMS之一，它在1990年代末作为PostgreSQL的一个分支开始。它使用FPGA来加速磁盘上页面的搜索，但最初不能搜索内存页面。Netezza在后来的版本中纠正了这个限制[2]。Swarm64试图销售一个FPGA加速器用于PostgreSQL，但在被收购之前转而使用没有FPGA的纯软件架构[91]。Vitesse的Deepgreen DB[81]是唯一可用的由ISV提供的FPGA增强型DBMS。

在GPU加速的DBMS市场上有更多的活动。值得注意的GPU DBMS包括Kinetica[35]、Sqream[35]、Brytlyt[13]和HeavyDB[48]。如果数据不适合GPU内存，那么查询执行就会因加载数据到设备而受到瓶颈，从而使硬件的并行化优势失效。

讨论：我们可以从上述分析中得出几个结论。首先，这些系统都专注于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不可能实现的更好的安全性和可审计性。

讨论：在当今社会，我们需要信任多个实体。当一个人出售房屋时，他们信任产权公司来管理交易。唯一不需要现实世界信任的应用程序是暗网交易（例如洗钱）。合法企业不愿意支付性能代价（大约五个数量级）来使用区块链数据库管理系统（DBMS）。如果组织相互信任，他们可以更有效地运行共享的分布式DBMS，而无需浪费时间在区块链上。据我们所知，所有主要的加密货币交易所都是使用传统的RDBMS而不是区块链系统来运营他们的业务。

区块链支持者还提出了其他无意义的声明，称通过在对等网络环境中复制数据来实现数据弹性。没有理智的公司会依赖互联网上的随机参与者作为关键任务数据库的备份解决方案。

私人区块链数据库管理系统（DBMS）可能存在一个（较小的）市场。亚马逊在2018年发布的量子账本数据库（QLDB）[65]提供了与区块链相同的不可变和可验证的更新保证，但它不是去中心化的（即没有拜占庭容错提交协议）。亚马逊在发现完全去中心化的区块链DBMS没有令人信服的用例后构建了QLDB[108]。

3.7 总结

从数据库系统中的主要技术趋势中，我们可以得出以下要点：

• 列式系统：转向列式存储彻底改变了OLAP DBMS架构。

• 云数据库：云已经颠覆了构建可扩展DBMS的传统智慧。除了嵌入式数据库，任何不以云为基础创业的产品很可能会失败。

• 数据湖 / Lakehouses：基于云的对象存储使用开源格式将成为未来十年OLAP DBMS的原型。

• NewSQL系统：它们利用了新的思想，但还没有像列式和云DBMS那样产生同样的影响。它导致了新的分布式DBMS，支持更强的ACID语义，以对抗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]）。其他系统来自初创公司构建数据密集型产品，他们觉得也需要构建一个数据库。最成功的例子是10gen (MongoDB) 和 PowerSet (HBase)，但也有很多失败的尝试。

这种避免“not invented here”软件的趋势部分是因为许多公司的晋升路径倾向于奖励那些制作新内部系统的工程师，即使现有工具已经足够。但这种扭曲导致许多没有数据库管理系统（DBMS）工程经验的团队开始构建新系统。当一家公司首次将其开源时，我们应该警惕这样的系统，因为它们几乎总是不成熟的技术。

不要忽视开箱即用的体验。许多非关系型DBMS的一个显著卖点是比关系型DBMS更好的“开箱即用”体验。大多数SQL系统需要用户首先创建一个数据库，然后定义他们的表，之后才能加载数据。这就是为什么数据科学家使用Python notebook快速分析数据文件的原因。因此，每个DBMS都应该让本地和云存储文件的原位处理变得容易。DuckDB日益流行的部分原因是它能够很好地做到这一点。

供应商还应该考虑客户在使用数据库时不可避免会面临的额外挑战，包括物理设计、参数调优、模式设计和查询调优。这是一个至关重要，可称之为“自动驾驶”DBMS的需求[173]。

开发者需要直接查询他们的数据库。在过去20年里创建的大多数在线事务处理（OLTP）应用程序主要通过抽象层与数据库交互，例如客户端API（例如REST、GraphQL）或对象关系映射器（ORM）库。这些层将应用程序的高级请求转换为数据库查询。ORM还自动处理维护任务，例如模式迁移。有人可能会争辩说，由于OLTP开发人员从未在他们的应用程序中编写原始SQL，所以他们的DBMS使用什么数据模型并不重要，因为这些层隐藏了它。

ORM是快速原型设计的重要工具。但它们通常牺牲将逻辑推送到DBMS的能力，以换取与多个DBMS的互操作性（兼容性）。开发者转而编写显式的数据库查询，以覆盖自动生成的低效查询。这就是为什么使用支持SQL的关系型数据库管理系统（RDBMS）是更好的选择。

人工智能/机器学习（AI/ML）对DBMS的影响将是巨大的。DBMS应该如何与现代AI/ML工具互动最近成为一个关键问题，特别是随着大型语言模型（LLM）（例如ChatGPT）的出现。虽然这个领域发展迅速，但我们提供一些初步意见。

由于LLM在将自然语言（NL）转换为查询代码（例如SQL）方面的进步[133]，使用NL查询数据库正在复兴。一些人甚至建议，这种AI驱动的查询界面将使SQL过时。NL界面是一个可以追溯到1970年代的老研究课题[139]，但历史上结果不佳，因此几乎没有广泛使用[88]。我们承认LLM在这项任务上有令人印象深刻的结果，但警告那些认为NL将取代SQL的人。没有人会使用NL编写OLTP应用程序，因为大多数使用ORM生成查询。对于在线分析处理（OLAP）数据库，NL可能在构建探索性分析的初始查询时有所帮助。然而，这些查询应该暴露给类似仪表板的工具，因为英语和其他NL充满了歧义和不精确性。

在企业内部，尤其是在处理财务数据时，人们不愿意依赖当前的LLM技术进行决策。最大的问题是LLM的输出对人类来说是无法解释的。其次，LLM系统需要的训练数据比“传统”ML系统（例如随机森林、贝叶斯模型）更多。公司通常不能将这些模型的训练数据创建外包给非技术人员。由于这些原因，企业数据采用LLM的速度将会谨慎缓慢。

最后，最近有大量关于使用AI/ML优化DBMS的研究[174]。例子包括面向ML的查询优化器[152, 156]、配置调优[200, 204]和访问方法[151, 193]。虽然这种ML辅助优化是提高DBMS性能的强大工具，但它并不能消除对高质量系统工程的需求。

5 结论

我们预测，数据库的发展在未来几十年将继续循环往复。另一波开发者将声称SQL和关系模型（RM）已不足以应对新兴的应用领域。人们随后会提出新的查询语言和数据模型来解决这些问题。探索DBMS（数据库管理系统）的新思想和概念具有巨大的价值（这是我们为SQL获取新功能的地方）。正因为如此，数据库研究社区和市场变得更加健壮。然而，我们不认为这些新的数据模型会取代关系模型（RM）。

另一个担忧是很多新轮子在重新实现并且没有创新，在DBMS所必需的相同组件（例如，配置处理器、解析器、缓冲池）上的白白浪费。为了加速下一代DBMS的发展，社区应该促进开源可重用组件和服务的开发[112, 176]。有一些努力朝着这个目标前进，包括文件格式（见第3.3节）、查询优化（例如，Calcite [104]，Orca [186]）和执行引擎（例如，DataFusion [18]，Velox [175]）。我们认为数据库社区应该努力制定一个类似于POSIX的DBMS内部标准，以加速互操作性。

开发者要从历史中学习。换句话说，站在前人的肩膀上，而不是他们的脚趾上。我们中的一个很可能在二十年后仍然健在，因此非常期待您在2044年撰写这篇论文的后续文章。

编译：佚名

作者：Michael Stonebraker 和 Andrew Pavlo