以下是对过去20年新数据库发明的评述：

1)MapReduce与Hadoop

MapReduce系统，尤其是Hadoop，曾是大数据系统实现中最引人注目且一度最成功的案例。然而，据斯通布拉克所言，它们已经过时，目前最多只能算作遗留技术。

MapReduce(MR)的缺陷是如此明显，以至于尽管开发者社区热情采用，但也难以挽救其命运。大约10年前，Hadoop 已经走到了尽头，留下了企业中的 HDFS 集群及一系列致力于从中获利的公司。目前，HDFS的吸引力逐渐减弱，企业已经意识到存在更好的分布式存储替代方案。同时，分布式关系数据库管理系统正蓬勃发展，尤其是在云环境中。

MR系统实现中的一些指标，如可扩展性、弹性和容错性，已被引入分布式 RDBMS中。此外，MR还推动了共享磁盘架构的复兴，伴随非紧耦合存储的兴起，进而催生了开源文件格式和数据湖。Hadoop的局限性为其他数据处理平台打开了大门，特别是Spark和Flink，是对 MR 的更好实现，提供过程性 API，但随后增加了对SQL的支持。

这种转变标志着数据处理技术的演变，显示出开发者和企业对于更灵活、可扩展的数据处理平台的需求，推动了现代数据架构的多样化。

2)键值存储

诸如Redis和RocksDB等键值存储系统，已经发展成熟，融入了关系模型(RM)系统的特性，或被专门用于解决特定问题。

键值存储(KV存储)为开发者提供了一种快速的“开箱即用”的数据存储方式，相比于在关系数据库管理系统中设置表所需的繁琐工作，使用KV存储要简单得多。

当然，在需要超出简单二元关系的复杂应用中使用KV存储是危险的。如果一个应用需要记录中的多个字段，那么KV存储可能不是一个好的选择。应用不仅必须解析记录字段，而且还没有辅助索引可以通过值检索其他字段。此外，开发者需要在应用中实现链接或多重获取操作。

3)文档存储

NoSQL数据库如:Transwarp DocStore、MongoDB和Couchbase，将数据存储为JSON文档，受益于开发者对非规范化数据结构、低级API以及牺牲ACID事务以换取水平可扩展性的需求。

但文档存储正与关系数据库管理系统的冲突正在加剧，因为RDBMS开始增加水平可伸缩性和对JSON的支持。两种系统之间的差异随着时间的推移而减小，未来几乎应该无法区分。

4)列式数据库

这个NoSQL数据库系列，包括BigTable、Cassandra和HBase，类似于文档存储，但只支持一个嵌套级别。作者指出，如果没有Google的支持，这一类别可能不会在论文中被提及，暗示它们已经过时。

列式数据库管理系统(Array DBMS)是一个细分市场，仅在特定垂直领域得到应用。商业应用程序很少使用专门的列式数据库管理系统，没有主要的云服务提供商提供托管的列式数据库服务，意味着他们并未看到这个市场的规模。

5)文本搜索引擎

搜索引擎技术已经存在了70年，而现代搜索引擎如Transwarp Scope、Elasticsearch和Solr依然流行。作者认为，它们可能会与关系数据库保持独立，因为在SQL中执行搜索操作通常既笨拙，又在不同的DBMS中表现不一致。

如果关系数据库管理系统能在搜索方面有更好的表现，这些系统就不必作为单独的产品存在。

6)数组数据库

科学界的数据库，如Rasdaman、kdb+和SciDB(由Stonebraker创造)，将数据存储为二维矩阵或更高维度的张量。作者指出，尽管RDBMS增加了对SQL/MDA的支持，但仍然无法有效存储和分析数组，因此这类数据库可能会继续流行。

7)向量数据库

专用向量数据库如星环Hippo、Pineone、Milvus和Weaviate，本质上是具有专门近似最近邻(ANN)索引的面向文档的DBMS。它们的优点在于与AI工具如LangChain的集成能力优于关系数据库。但作者对向量数据库的长期可行性持保留态度，因为RDBMS可能会吸收它们的功能，使得这种专门的数据库变得不必要。

关系数据库管理系统应该很快会通过其可扩展的类型系统提供对这些数据结构和搜索方法的原生支持，从而使得这样专门化的数据库变得不必要。

8)图形数据库

图数据库如Transwarp StellarDB、Neo4j、TigerGraph已经找到了自己的市场定位，在处理连接数据的某些类型的OLTP和OLAP工作负载时，比关系数据库更高效。

作者提出，图形数据库的市场成功将取决于是否有足够的“长链”场景，使得放弃RDBMS成为合理的选择。

OLTP 图应用将在很大程度上由 RDBMS 提供支持。此外，分析图应用有独特的要求，最好在主内存中使用专门的数据结构来处理。RDBMS 将在 SQL 之上或通过扩展提供以图为中心的 API。“我们并不期待专门的图数据库管理系统会成为一个大型市场。”

从上述部分可以得出一个合理的结论，即非SQL、非关系型系统要么是小众市场，要么正在快速转变为SQL/关系模型(RM)系统。

Stonebraker和Pavlo不仅对“关系或非关系”的辩论提出了见解，还深入探讨了数据库架构的最新趋势。

1)列存储

列存储关系数据库，如Google Cloud BigQuery、AWS Redshift和Snowflake，由于其卓越的性能，已经成为数据仓库和OLAP市场的主导者。

在过去的20年里，所有活跃于数据仓库市场的供应商都将其产品从行存储转换为列存储。这一转变带来了数据库管理系统设计的重大变化。

此外，在过去的20年中，许多新的供应商进入市场，推出了列存储的产品，例如亚马逊的Redshift和谷歌的BigQuery，以及一些独立公司的产品(如 星环科技、Snowflake等)。

总之，列存储是具有专门优化器、执行器和存储格式的新型数据库管理系统实现。由于其卓越的性能，它们已在数据仓库市场中占据了主导地位。

Delta Lake是这个关系不严格的世界的亮点

2)云数据库

作者认为，过去20年数据库设计中最大的变革发生在云计算领域。网络带宽的显著提升使得通过网络附加存储(NAS)将数据存储在对象存储中变得十分有吸引力，促进了计算与存储的分离，以及无服务器计算的发展。

云服务的兴起为企业提供了一个难得的机会，重构代码库并摒弃不良的技术决策。他们警告说，任何不是从云产品开始的数据库产品都可能面临失败。

云数据库的出现是“因果循环”的另一个例子。多节点共享磁盘数据库管理系统是一个古老的理念，历史上往往未能取得良好的效果。然而，随着技术的变革(更快的网络)以及向云端的迁移，这一理念重新获得了关注。此外，1970年代，当计算机庞大且昂贵时，时间共享服务非常流行。云平台就是大型时间共享服务，因此这一概念在经历了几十年后又重新回归。

由于企业正在尽可能将所有东西迁移到云端，我们预计共享磁盘将在数据库管理系统架构中占主导地位。因此，我们认为共享无状态架构不会在未来重新出现。

云数据库，不得不接受的一个选择

云对数据库管理系统产生了深远的影响，导致它们被完全重新架构。从本地计算到云计算的迁移为企业提供了一个千载难逢的机会，可以重构代码库，消除糟糕的历史技术决策。云环境还为供应商提供了许多本地部署无法实现的好处。其中最重要的是，供应商可以跟踪所有客户的使用趋势：他们可以监控意外行为、性能下降和使用模式。此外，他们可以在不干扰服务的情况下推送增量更新和代码修补程序。

从商业角度来看，开源数据库管理系统面临着变得过于流行的风险，可能被主要云服务提供商进行货币化。亚马逊与独立软件供应商(ISV)如MongoDB、 Elasticsearch之间的公开争吵就是显著的例子。

3)数据湖/湖仓一体

建立在云对象存储的普及之上，数据湖和湖仓一体系统被视为2010年代初"大数据"运动的继承者。系统如Apache Iceberg、Apache Hudi和Databricks Delta Lake解决了将任意数据写入集中式存储的问题，曾被认为是一个糟糕的想法。

湖仓一体架构的另一个优势是支持非SQL工作负载，如数据科学家可以通过Pandas DataFrame API在笔记本中处理数据。作者预测，这将是未来十年OLAP 的原型。

数据湖是2010年代早期“基于大数据”运动的继任者，部分受到了MapReduce系统和列存储流行的推动。乍一看，数据湖似乎是一个糟糕的观点：允许任何应用将任意文件写入一个集中存储库，而没有任何治理措施，会导致完整性、发现和版本控制等问题。湖仓(Lakehouse)提供了对这些环境所需的环境，以帮助缓解许多与元数据、缓存和索引服务相关的问题。一些额外的中间件，如Delta Lake、Iceberg 和Hudi ，可以跟踪新数据并支持事务性更新，使湖仓看起来更像传统的数据仓库。

数据湖带来了新的查询优化挑战。数据库管理系统一直在获取数据的精确统计信息方面苦苦挣扎，导致查询计划选择不佳。然而，数据湖系统可能完全缺乏新进数据文件的统计信息。因此，采用自适应查询处理策略在云中变得至关重要，以使DBMS能够在执行期间根据观察到的数据特征动态修改查询计划。

所有主要的云供应商现在都提供某种变化版本的托管数据湖服务。由于以对象存储为基础的数据湖系统每GB的成本远低于专有的数据仓库，传统的在线分析处理(OLAP)供应商(如Teradata、Vertica)已经扩展其数据库管理系统，以支持从对象存储读取数据，以应对这一价格压力。一些独立系统也在这一领域，包括Databricks 、Dremio、PrestoDB和Trino 。

4)NewSQL系统

NewSQL数据库，即新型的关系或SQL数据库，能够像NoSQL数据库那样水平扩展而不放弃ACID保证。

然而，这类数据库，如SingleStore、NuoDB(现属于Dassault Systems)和VoltDB(由Stonebraker创造)，并未流行起来。主要原因是现有的数据库已经足够好，企业不愿意冒险迁移到新系统。

5)硬件加速器

过去20年中，出现了一些用于OLAP工作负载的硬件加速器，它们结合了FPGA(如Netezza、Swarm64)和GPU(如Kinetica、Sqream、Brylyt和HeavyDB，前身为OmniSci)。尽管目前除了云服务巨头外，很少有公司能够证明为数据库构建定制硬件的费用合理，但作者认为，未来20年在这个领域将有许多尝试。

由于Nvidia的CUDA的可用性，GPU是流行的数据库加速器

6)区块链数据库

区块链数据库曾被看作是无信任社会的未来数据存储解决方案，但现在已经成为一种正在衰退的数据库技术趋势。尽管技术本身是可行的，但在暗网之外几乎没有应用场景。

他们认为，合法企业不愿意为使用区块链数据库支付高昂的性能成本，这是一种低效的技术，寻找应用的方式是错误的。历史表明，这是系统开发的错误方法。

在对未来数据库发展的展望中，Stonebraker和Pavlo在他们的论文中提出了几个明确的发展趋势，并强调了关系模型和SQL的持久影响力。

关系模型与SQL的持久性：尽管新的数据模型和查询语言将不断涌现，试图满足新兴应用领域的需求，但关系模型和SQL的结合仍然难以被击败。尽管会有不断地尝试，但这些新的尝试不太可能取代现有的关系模型。

数据库研究的创新价值：探索数据库管理系统(DBMS)的新想法和概念具有重大价值，这正是SQL新功能得以发展的源泉。他们鼓励数据库研究社区和市场保持活力和创新。

开源组件和服务的发展：两人提倡数据库社区推动开源可重用组件和服务的开发，以促进技术进步和标准化。他们提到了一些已经做出的努力，包括文件格式(如Iceberg、Hudi、Delta)、查询优化(如Calcite、Orca)和执行引擎(如DataFusion、Velox)。

互操作性与内部标准：数据库社区应该努力实现类似POSIX的DBMS内部标准，以加速不同系统和组件之间的互操作性。

历史教训与前人经验：开发人员要从历史中吸取教训，利用前人的成果作为跳板，而不是重复他们的错误。

他们以幽默的方式总结，暗示即使到了2044年，他们中的一位可能仍然活跃在数据库领域，继续为这一领域的进步做出贡献。

通过这些观点，Stonebraker和Pavlo为数据库提供了一个清晰的发展方向，同时强调了持续创新和学习的重要性。

·https://www.datanami.com/2024/07/08/dont-believe-the-big-database-hype-stonebraker-warns/

·https://www.datanami.com/2023/02/23/the-future-of-databases-is-now/

·https://db.cs.cmu.edu/papers/2024/whatgoesaround-sigmodrec2024.pdf