去年图灵奖得主 Michael Stonebraker 和 CMU 知名教授 Andrew Pavlo 写了一篇论文 What Goes Around Comes Around… And Around… 回顾了过去20年数据库领域的发展。
这篇论文的标题挺有意思的，我将这篇论文的标题理解为 数据库技术总归都周而复始的，螺旋上升，兜兜转转又回到过去的技术路线，以新的形式焕发生命力。
不过通读全文，我饿觉得还有另外一种理解是，“Make 关系型数据库 Great Again”。
论文中分析了数据库近 20 年的发展，分别从数据模型&查询语言（Data Models & Query Languages)，以及系统架构（System Architectures) 两部分入手进行分析。
数据模型&查询语言
MapReduce System
MapReduce 已死，被后来的系统 Spark/Flink 所替代 。HDFS 苟延残喘，企业逐渐意识到有很好的分布式存储的替代品，如 S3 这种对象存储。但是论文还是高度肯定了 MapReduce 的价值，MapReduce 推动了共享磁盘架构的复兴，开源文件格式和数据湖的涌现。
Key/Value 系统
KV 系统只适用于简单的应用，不适用于存储包含多个 field 的 record，因为需要解析 record，也没有对 value field 的二级索引。
已有的 RDBMS 可以很容易地模拟 KV store；另外一种架构是让 KV store 作为 DBMS 的底层存储引擎，基于 KV store 可以更快地实现一个 DBMS，比如 TIDB。
文档数据库
NoSQL文档存储一开始是因为它提供非规范化数据结构、低级API和水平可扩展性而受到开发者欢迎。虽然它们出现的时候宣称自己的事 NoSQL 数据库，但是它们正在与关系数据库管理系统（RDBMS）发生重合，为文档数据库添加 SQL 和ACID 的支持等；RDBMS与专门的文档数据库的区别也越来越小。
列族数据库
BigTable，Cassandra，HBase 等，但它们最终都提供对 SQL 的支持；已经过时，很小众的市场
文本搜索引擎
虽然有专门的文本搜索引擎（如Elasticsearch），但是现在 RDBMS 也可以进行文本搜索，这样就可以避免用户维护两套不同的系统，Elasticsearch 做文本搜索，RDBMS 处理业务数据，并且还有一条 ETL pipeline 将 RDBMS 的数据转到 Elasticsearch 中。
数组数据库
数组数据库（如Rasdaman、kdb+和SciDB）在科学界很受欢迎，因为关系数据库管理系统不能有效地存储和分析数组
向量数据库
向量数据库（如Pineone、Milvus 和 Weaviate）是专门用于存储向量的数据库；作者认为向量数据库最终也会添加对 SQL 的支持；
但是随着 LLM 的流行，几乎所有的 RDMS vendor 都提供了对向量的支持；
虽然向量数据库与AI工具的集成更好，但作者认为它们的长期可行性不佳，因为关系数据库可能会采用它们的所有特性。
图数据库
RDBMS 也可以用一堆表来模拟 graph，SQL:2023 也引入了图上的查询语法。这都使得图数据库和 RDBMS 之间的区分度也更小；而且最近也有工作表明，用 DuckDB 模拟图数据库，并且执行图上的 SQL，性能要10x好于专门的图数据库。
系统架构（System Architectures)
列存系统
压缩率更高
可以支持向量化执行
对于行存，每条 record 行存有很大的 header 的开销，比如 20bytes 来trace null 值，版本信息。每个 record 都会有，但是对于列存，每列一个 header 来进行记录，空间开销远小于行存。
由于它们的“卓越性能”，已经主导数据仓库/OLAP市场
云数据库
云数据库具有 per-query 的弹性，存算分离的架构。但是存算分离的架构其实也是之前 mutil node shared-disk 的 DBMS 的 idea，但是随着技术的变化，更快的网络和硬件，企业向云迁移的趋势，重新变得流行起来了。
从商业的角度看，开源 DBMS 也要警惕被云厂商白嫖
数据湖/ LakeHouse
数据湖对查询优化带来了挑战，因为数据湖对新 ingest 的数据缺少统计信息。
目前所有的主流云 vendor 都提供了 managed data lake service。由于数据湖基于对象存储，比传统的 OLAP 系统便宜，传统OLAP供应商（例如Teradata、Vertica）扩展其DBMS以支持从对象存储读取数据以应对这种竞争。
作者认为数据湖将是未来十年OLAP DBMS的原型。
NewSQL
NewSQL 数据库尝试在不放弃 ACID 保证的前提下，像 NoSQL 数据库一样水平扩展，即分布式关系型数据库，类似 TIDB；但是并没有像列存数据库和云数据库那样流行起来；
硬件加速
目前只有大型的云 vendor 会定制化硬件来进行加速；如 AWS Redshift 的 AQUA 等；但可以认为未来会有更多这样的尝试。
区块链数据库
对上层的应用来说，非常低效。已成为一种逐渐消退的数据库技术趋势。
结语
论文作者最后分享了几个对过去二十年数据库的分析有几个要点，不幸的是，部分要点只是对 20 年前论文给出的提醒的重复。
这也算是点题了吧
不要低估劣质数据库系统的营销
过去，劣质的数据库系统凭借自己过人的营销，取得了很大的成功，尽管当时有更好的选择。比如 1980 年代的 Oracle，2000 年代的 MySQL，2010 年代的 MongoDB。这些系统在早期获得了足够的生存空间，为他们赢得了时间来修复系统本身的缺陷。
我只负责翻译，上述观点仅代表作者本人意见。
警惕非专业数据库系统公司开发的数据库系统
过去二十年有个比较有趣的现象是，大型科技公司在内部构建自己的数据库系统，然后将其开源出来，通常是捐赠到 Apache 社区，希望获得外部贡献者的免费开发。比如 Meta 的 Hive，RocksDB，LinkIn 的 Kafka，
这种内部造轮子的趋势部分原因是很多公司的晋升机制更青睐那些创建新内部系统的工程师，即使已有现成工具足够好。然而，这种倾向导致很多缺乏 DBMS 工程经验的团队也去尝试开发新的系统。对于此类公司首次开源的系统，人们应保持谨慎，因为它们几乎总是尚不成熟的技术。
总之就是：别来沾边。
虽然我认同部分观点，但是感觉作者有点偏激了。
不要忽视开箱即用的体验
许多非关系型DBMS的一个突出卖点是比RDBMS更好的"开箱即用"体验。大多数SQL系统需要首先创建数据库，然后定义表，然后才能加载数据。这就是为什么数据科学家使用Python笔记本快速分析数据文件的原因。因此，每个DBMS都应该让本地和云存储文件的就地处理变得容易。DuckDB日益流行，部分原因是它在这方面做得很好。
开发者需要直接查询他们的数据库
虽然过去20年创建的大多数OLTP应用程序主要通过抽象层与数据库交互，例如端点API（如REST、GraphQL）或对象关系映射器（ORM）库。这些层将应用程序的高级请求转换为数据库查询。但是可以通过 SQL 直接查询数据库还是非常重要的。
AI/ML 对数据库系统的影响是非常大的
DBMS应该如何与现代AI/ML工具交互最近已成为一个关键问题。
LLM在将自然语言（NL）转换为查询代码（如SQL）方面有很大的进步，但是并不认为自然语言将取代 SQL，没有人会使用NL编写OLTP应用程序，因为大多数使用ORM生成查询。
对于OLAP数据库，NL在构建探索性分析的初始查询方面可能很有帮助。然而，这些查询应该暴露给类似仪表板的细化工具，因为英语和其他语言充满歧义和不精确性。
企业内部对依赖当前LLM技术进行决策存在不情愿，特别是涉及财务数据时。最大的问题是LLM的输出对人类来说是不可解释的，并且企业并不想把训练模型的数据直接给到非专业人员。由于这些原因，LLM 在企业数据中的采用将谨慎和缓慢。
虽然最近有大量关于使用AI/ML优化DBMS的研究，包括面向 ML 的查询优化器，尽管这种ML辅助优化是提高DBMS性能的强大工具，但它并不能消除对高质量系统工程的需求
总结
尽管关系模型和 SQL 可能面临新的挑战，但它们不太可能被新的数据模型所取代。
作者鼓励数据库社区“促进开源可重用组件和服务的发展”，有一些朝着这个目标的努力，包括文件格式（Iceberg, Hudi, Delta）、查询优化（例如 Calcite, Orca）和执行引擎（例如 ataFusion, Velox），数据库社区应该努力实现一个类似POSIX的标准，以加速互操作性。