2024 年数据库：年度回顾--Andy Pavlo

就像向你的穹顶 发射了一枪，我回来向你介绍数据库这场 激烈 竞争中发生的年度事件。是的，我曾经在 OtterTune 博客上写过这篇文章 ，但这家公司已经倒闭了（RIP）。我正在我的教授博客上写这篇文章。

过去的一年有很多事情值得报道，从十位数的收购，到街头疯狂更改许可证的供应商，再到最著名的数据库八十多岁的老人挥霍金钱招募一名大学四分卫来给他的新老板留下深刻印象。

我向我的第一任妻子承诺，今年我会写得更专业。我还听说，一些大学将我每年的博客文章列为数据库课程的必读内容。让我们看看情况如何。

先前的条目：

• 2023 年数据库：年度回顾

• 2022 年数据库：年度回顾

• 2021 年数据库：年度回顾

这是我的数据库，我将按照我想要的方式授权它！

我们生活在数据库的黄金时代。对于所有类型的应用领域，都有许多出色的（ 关系型 ）选择。尽管许多数据库是由由风险投资资金支持的营利性公司创建的，但它们都是开源的。

但风险投资公司想要收回这笔钱，并填补他们的 陷阱 ，因此这些公司在云上为他们的 DBMS 提供托管服务。但云使开源 DBMS 成为一项棘手的业务。如果一个系统变得太受欢迎，那么云供应商（如亚马逊）就会将其作为一项服务，从而比支付软件开发费用的公司赚得更多。这种威胁就是许多数据库公司改用更严格的源代码许可证的原因，以防止云供应商转售他们的产品。MongoDB 是第一批 在 2018 年 改用 服务器端公共许可证 (SSPL) 的公司之一。

过去的一年是许可证变更动荡的一年，其中最突出的两个是 Redis™ 和 Elasticsearch。

Redis：

Redis Ltd.（该公司）正积极推进 IPO。该公司最初于 2011 年以 Redis Labs 的名称成立， 2021 年从 Redis Labs 的创始人 Salvatore Sanfilippo 手中收购了 Redis 商标 ，并更名为 Redis Ltd.。过去几年，Redis Ltd. 一直试图巩固对 Redis 领域的控制。该公司还试图通过增加对向量和其他数据模型的支持来摆脱人们对该系统主要用作内存缓存的看法。

2024 年 3 月，Redis Ltd. 宣布将从 系统原始的（非常宽松的） BSD-3许可证 转换为由专有的 Redis 源可用许可证 和 MongoDB 的 SSPL组成的双重许可证 。该公司宣布这一变化的同一天，他们宣布收购 Speedb ，这是 RocksDB 的一个 开源分支 。

Redis 许可证变动很快 引发了强烈反对 。许可证变更的同一周， 基于原始 BSD-3 代码行的 两个分支发布： Valkey 和 Redict。Valkey 最初由亚马逊发起，但谷歌和甲骨文的工程师很快加入进来。仅仅一周后，Valkey 项目就 成为 Linux 基金会的一部分，遭到了 Redis Ltd. 的反击，几家大公司将开发工作转移到了该项目上。Redis Ltd. 对其心爱的商标采取了不怀好意的态度，并 开始接管开源 Redis 扩展 ，但这并没有消除人们对其不怀好意的印象 。

为了向布什维克比尔 (RIP)、疤面煞星和威利 D 在 2015 年重聚 致敬 ，Redis 的创始人 于 2024 年 12 月宣布 ，他已与 Redis Ltd. 管理层取得联系，并希望卷土重来，重新团结 Redis 社区。

Elasticsearch：

Elastic NV 是一家营利性公司，支持领先的文本搜索 Elasticsearch DBMS 的开发。2021 年，他们宣布 转向 Elastic 许可证 和 MongoDB 的 SSPL的双许可证模式。同样，这是对亚马逊 Elasticsearch 产品日益突出的回应，尽管该服务 自 2015 年就 已经推出 。亚马逊对这一转变并不友好，并宣布了他们的 OpenSearch 分叉。

三年后，Elastic NV 于 2024 年 8 月宣布 撤销许可证变更 并改用 AGPL 。他们宣布这一变化的博客文章引用了 Kendrick Lamar 的歌曲（例如 Not Like Us ）。亚马逊不喜欢被称为 数据库的德雷克 ，并于次月宣布他们将把 OpenSearch 项目的所有权转让给 Linux 基金会 。

Andy 的看法：

这场骚乱似乎只是因为许可证问题，但请记住，数据库行业利润丰厚。而且这只是两个系统！我甚至没有提到 Greenplum在九年后 悄悄关闭 了他们的开源存储库并转向专有。但人们没有注意到，因为没有人愿意再使用 Greenplum。据我所知，唯一做出同样开源逆转的 DBMS 是 2023 年的 Altibase 。

坦白说，我不喜欢 Redis。它很慢，有虚假 交易 ，查询语法也很乱。我们在 CMU 的实验发现， Dragonfly 的 性能数据要令人印象深刻得多（即使使用单个 CPU 核心）。在我的数据库课程中，我使用 Redis 查询语言作为 不该做的事情 的例子。尽管如此，我还是同情 Redis Ltd. 被亚马逊占领的困境。但是，该公司高估了构建像 Redis 这样的简单系统的进入门槛；它比构建功能齐全的 DBMS（例如 Postgres）要低得多，因此 OG Redis 有几种替代方案。他们并不处于强势地位，社区不会容忍这种姿态。

Elasticsearch 的故事与 Redis 的故事相同，只是情节发展更进一步：该公司宣布更改许可证，竞争对手创建了一个开源分支，最后该公司在低调中恢复了开源许可证。

请注意，与做出类似举动的其他系统相比，Redis 和 Elasticsearch 受到的反对更多。当 MongoDB、 Neo4j 、 Kafka 或 CockroachDB 宣布更改许可证时，并没有做出重大努力来分叉它们。CockroachDB 甚至 在 2024 年再次更改了其许可证 ，以让大型企业开始付费。这不可能是因为 Redis 和 Elasticsearch 的安装基数比其他系统大得多，因此，对这一变化感到不满的人更多，因为当他们切换许可证时，MongoDB 和 Kafka 的安装数量同样多。就 Redis 而言，我只能认为人们认为 Redis Ltd. 不公平地从他人的劳动中获利，因为该公司的创始人并不是该系统的原始创建者。对 Redis 源代码存储库的分析还表明，对该DBMS 的贡献 中有相当大一部分来自公司外部（例如腾讯、阿里巴巴）。这种“窃取的勇气”是 HashiCorp 在 2023 年 更改 Terraform 许可证 时遭到愤怒的原因 。

这些许可证变动中最重要的问题是 开源独立软件供应商 (ISV) 在数据库市场的长期生存能力。云供应商是拥有无限资金的庞然大物。如果开源 DBMS 起飞，他们将开始托管它并赚取比 ISV 更多的钱。 或者他们会将你的 DBMS 的有线协议作为前端添加到现有的 DBMS，就像 AWS 在 2024 年 3 月为其 Timestream DBMS添加了 InfluxDB v2 协议支持 一样。然后他们可以成为前面提到的布什维克比尔的女朋友并 射中你的眼睛 ，就像当 AWS 宣布他们的新 Valkey 兼容服务 比他们的 Redis 兼容服务 便宜 30%时一样。

更新 2025-01-01： 我之前曾说过，AWS 在其现有的 Timestream DBMS 之上添加了 InfluxDB v2 协议。AWS 不仅复制了该协议，还与 Influx Data 合作提供了 InfluxDB v2 DBMS 的托管服务。 [来源]

更新 2025-01-01：我错过了 ScyllaDB 于 2024 年 12 月宣布 他们将停止其 DBMS 的开源 (AGPL) 版本 ，并使企业版本“源代码可用” 的消息。 [来源]

Databricks 与 Snowflake 的帮派战争仍在继续

Databricks 和 Snowflake 之间依然没有和平。这场斗争是一场经典的数据库战争，已经蔓延到街头。这两家公司之前 在查询性能方面的争执 已经扩展到数据管理的其他领域，并且变得更加昂贵。

2024 年 3 月，Databricks 率先出击，宣布斥资 1000 万美元构建 拥有 1320 亿个参数的 DBRX 开源 LLM。Mosaic 团队 领导了 DBRX 模型的开发，Databricks 于 2023 年以 13 亿美元收购了 该模型。一个月后，Snowflake 也来到同一个角落，用他们拥有 4800 亿个参数的 Arctic 开源 LLM 大放异彩。Snowflake 夸口说，他们只花了 200 万美元训练他们的模型 ，但在 SQL 生成等“企业”任务方面的表现优于 DBRX。你可以看出 Snowflake 最在乎的是向 Databricks 发起攻击，因为他们的公告显示其他 LLM 做得比他们更好（例如 Llama3），但他们强调他们比 DBRX 更好。一位 AI 研究人员对 Snowflake 为什么在他们的分析中如此关注 DBRX 而不是其他模型感到困惑；此人不知道这两个数据库竞争对手流了多少血。

在公开的 LLM 之战激烈进行的同时，Databricks 和 Snowflake 之间在目录问题上的另一场战争也在幕后展开。在 2010 年代的大部分时间里，Hive 的 HCatalog 一直是数据湖中事实上的目录系统。2010年代后期，Netflix 和 Uber 分别推出了 Iceberg 和 Hudi ，作为替代品，它们都成为了由风险投资资助的初创公司支持的顶级 Apache 项目。这些系统提供元数据服务来跟踪文件，并支持在对象存储（例如 S3）上以事务形式提取新数据。Databricks 拥有一个名为 Unity 的专有目录服务，可与其 DeltaLake 平台配合使用。Snowflake 于 2022 年宣布 首次集成 Iceberg 支持的表格。随后，他们在接下来的几年里 扩大了对 Iceberg 的支持 。然后，他们考虑收购 Iceberg 背后的主要公司 Tabular ，以使用 Unity 和 DeltaLake 与 Databricks 竞争。据说 Snowflake 即将 以 6 亿美元完成这笔交易 。但 Databricks 却趁机搅局，斥资 20 亿美元收购 Tabular。Databricks 在 Snowflake 首席执行官的会议主题演讲当天宣布了此次收购，当时 Snowflake 首席执行官宣布了他们将于 2024 年 6 月推出新的 开源 Polaris 目录服务。Databricks 继续打击 Snowflake，他们于 下周 宣布 将开源 Unity 目录。简直就是 谋杀 。

Andy 的看法：

这场数据库之争的有趣之处在于，它不仅仅是关于原始性能数字。它不像 20 世纪 90 年代的 Oracle 与 Informix 之争，当时双方主要吹嘘查询延迟更快。事实上，这场争斗也不仅仅是基准测试，当时 Informix 起诉 Oracle （后来不得不 撤诉 ），因为 Oracle 挖走了一些 Informix 高管。后来，全世界发现 Informix 首席执行官伪造了公司的账目， 夸大了收入数字， 以便在与 Oracle 的竞争中占据优势，并不得不 在联邦监狱里 待了两个月。

相反，Snowflake 与 Databricks 之争已经扩大到围绕数据库的生态系统。也就是说，它是关于人们用来将数据放入数据库的基础设施，以及他们处理这些数据的工具。用于分析查询的矢量化执行引擎现在是一种 商品 。Databricks 和所有其他 OLAP 供应商都遵循 Snowflake 2013 年的架构设计，该设计最初基于 Snowflake 联合创始人之一的 博士论文 。现在重要的是生活质量方面（很难货币化并与竞争对手进行比较）、与其他工具的兼容性以及 AI/LLM 魔力。

Snowflake 和 Databricks 之间的竞争至少对消费者有利。如此激烈的竞争意味着更好的数据产品和技术（例如，Snowflake 的 Polaris 现在是 Apache 项目），最终（希望）价格会更低。这不像之前 Oracle 和 SalesForce 首席执行官之间的较量，当时是两个有钱人在 昂贵的会议 上互相攻击 。

把鸭子塞进所有东西里

就像 Postgres 是任何开始使用新操作数据库的人的默认选择一样，DuckDB 已成为时代潮流，成为想要对其数据运行分析查询的人的默认选择。Pandas 之前占据着 DuckDB 的王者地位。鉴于 DuckDB 的极高可移植性，人们做出了多项努力将其嵌入现有的 DBMS 中，而这些 DBMS 对 OLAP 工作负载的支持并不好。今年，我们看到了四种不同的扩展版本发布，用于将 DuckDB 嵌入 Postgres 中。

第一次公告是在 2024 年 5 月，当时 Crunchy Data 发布了其 专有的桥接器 ，用于重新连接 Postgres 以将 OLAP 查询路由到 DuckDB。后来，他们宣布了其扩展的扩展版本，以利用 DuckDB 的 地理空间功能 来 加速 PostGIS 查询 。

2024 年 6 月，ParadeDB 宣布了 他们的开源扩展 ( pg_analytics )，该扩展使用 Postgres 的外部数据包装器 API 来调用 DuckDB；他们之前在早期版本 ( pg_lakehouse ) 中使用 DataFusion，但已切换到 Duck。

然后，在 2024 年 8 月，下一个 DuckDB-for-Postgres 扩展 ( pg_duck ) 问世了。此扩展的源代码托管在 DuckDB Labs GitHub 组织下。因此，这是官方认可的 Postgres 的 DuckDB 扩展。最初的 公告 称该项目是 MotherDuck 、 Hydra 、微软和 Neon 之间的合作。后两者（据称）因开发控制权争议而被踢出局，类似于 Arabian Prince 离开 NWA。该存储库现在仅将其列为 MotherDuck 和 Hydra 之间的联合努力。

最新的 DuckDB 扩展 于 2024 年 11 月 推出，名为 pg_mooncake 。Mooncake 与其他三个不同，因为它支持通过 Postgres 将数据写入 Iceberg 表，并具有完整的事务支持。

Andy 的看法：

大多数 OLAP 查询不会访问那么多数据。Fivetran 分析了 Snowflake 和 Redshift 的跟踪记录，显示 查询扫描的数据中位数仅为 100 MB 。如此小的数据量意味着单个 DuckDB 实例足以处理大多数查询。

DuckDB 的便利性和可移植性是其在 Postgres 社区中广泛传播的原因。尽管 ClickHouse 自 2016 年就已存在，但直到最近它才像 DuckDB 那样易于运行（请参阅这篇 博客文章 ，其中讨论了 2018 年部署 ClickHouse 的步骤）。这些 DuckDB 扩展是更广泛数据生态系统的单一入口点。用户不再需要安装单独的扩展来访问 Iceberg 中的数据，也不需要单独安装 S3 中的数据。DuckDB 可以为您处理所有这些。它允许组织获得高性能分析，而无需昂贵的数据仓库。

Postgres 对扩展和插件的支持令人印象深刻。自 20 世纪 80 年代以来，Postgres最初的设计目标 之一 就是可扩展。其目的是轻松支持新的访问方法和新的数据类型以及对这些数据类型的操作（即对象关系）。自 2006 年以来，Postgres 的“钩子”API。我们的 研究 表明，与其他所有 DBMS 相比，Postgres 拥有最广泛和最多样化的扩展生态系统。我们还发现，DBMS 缺乏护栏，这意味着扩展可能会 相互干扰并导致不正确的行为 。

早期将列式存储添加到 Postgres 的项目（例如 Citus、Timescale）只解决了部分问题。列式数据格式改进了从存储中检索数据。但是，如果 DBMS 仍然使用 面向行的查询处理模型 （例如 Postgres），则无法充分利用这些格式。使用 DuckDB 既提供列式存储，又提供矢量化查询处理。

这里可能有一个与大象有关的 火鸡鸭 笑话，但我不会这么做，因为我不想（再次）被大学 解雇 或留校察看。

随机事件

去年，数据库领域发生了许多你可能忽视的突发事件。下面是这些事件的简要总结：

版本：

• 亚马逊 Aurora DSQL

  目前，关于 AWS 如何实现其新的“类似 Spanner”的 DBMS 的公开信息并不多（请参阅 Mark Brooker 关于 DBMS 架构的讨论）。关键思想是分布式日志服务（有传言称它将基于现已停用的 QLDB）和通过 Time Sync 进行时间戳排序。但此公告向您展示了“Aurora”这个名称在数据库世界中具有多大的品牌知名度，因为 AWS 将它用于这个新的 DBMS，而这个 DBMS 似乎与其旗舰产品 Aurora Postgres RDS 产品没有任何代码共享。

• CedarDB

  Umbra是世界上 最伟大的数据库系统研究员 ( Thomas Neumann )编写的最先进的 DBMS 之一 。但 Thomas 满足于留在大学里研究 Umbra，继续稳居 Clickbench 排行榜榜首，不用担心烦人的客户。这就是为什么他的顶尖博士生分叉了他的代码并将其商业化为 CedarDB。

• 谷歌Bigtable

  该声明唯一有趣的部分是，2000 年代后期 NoSQL 运动的先锋现在在 2024 年支持 SQL。

• 边缘

  Turso 一直在开发 SQLite 的 libSQL 分支，但他们在 2024 年全力以赴，宣布用 Rust 完全重写 SQLite。他们在公告中正确地指出，SQLite 的价值不仅来自其代码，还来自确保它在任何地方都能正确运行的 疯狂测试工程 。这就是为什么 Limbo 开发人员正在与由前 FoundationDB 人员创办的 确定性测试初创公司 合作。 有关此测试含义的更多信息， 请参阅 FoundationDB 的 2020 CMU-DB 演讲。

• 微软石榴石

  这个键值存储系统是微软研究院推出的令人印象深刻的 FASTER 系统的继承者。它与 Redis 兼容，并支持查询间并行、大于内存的数据库和真实事务。如今，Redis 不 应该成为任何人的首选。

• MySQL v9

  MySQL v8 正式发布六年后，团队推出了 v9。但人们很快发现，如果数据库包含 超过 8000 个表，它就会崩溃。我对这个新主要版本的 功能列表 感到失望 。Oracle 将所有时间和精力都投入到其专有的 MySQL Heatwave 服务中。MySQL 仍然被广泛使用，但不再那么令人兴奋了。每个人都转向了 Postgres。

• Prometheus v3

  Prometheus 最新主要版本发布至今已有七年。现在有如此多的 兼容替代方案 ，以至于 OG Prometheus 可能不是某些组织的最佳选择。

收购：

• Alteryx → 私募股权

  我从未见过使用 Alteryx 的人，而且我对他们没有任何看法。

• MariaDB → 私募股权

  希望收购 MariaDB Corporation 的 PE 人员能够收拾残局。请参阅我去年对 MariaDB 垃圾场火灾 的分析。

• OrioleDB → Supabase

  如果您是领先的 Postgres ISV 之一，那么这次购买是有意义的。Postgres 拥有出色的前端，但 存储架构过时了 。OrioleDB 解决了这个问题。

• PeerDB → ClickHouse

  更好的 ETL 工具，可将数据从 Postgres 导出并导入 ClickHouse。这是 ClickHouse, Inc. 的明智之举。

• PopSQL → 时间尺度

  他们给自己买了一个精美的 SQL 编辑器 UI。这是生活质量的提升。

• Speedb → Redis Ltd.

  请参阅上面的 讨论 。他们可能会使用 Speedb 来允许 Redis 将数据溢出到磁盘。Speedb 的开发人员从未解释过他们在 RocksDB 分支中做了哪些更改和改进（或者我找不到？）。请参阅 Mark Callaghan 最近对 Speedb 与 RocksDB 的比较。

• Rockset → OpenAI

  这对该公司来说是个大新闻，但不幸的是，他们不得不在 2024 年 9 月关闭 DBaaS。Rockset 拥有一支优秀的工程团队，其中包括一些来自 Facebook 的最好的数据库工程师。我只是不喜欢他们的 DBMS 在其索引中存储数据的三个副本。

• 表格 → Databricks

  再次参见 上面的讨论 。Iceberg 是标准（对不起 Hudi）；甚至 Amazon S3 现在也支持它 。Polaris 的采用将如何发展以及它们是否能够长期保持兼容性还有待观察。

• Verta.ai → Cloudera

  我猜 Cloudera 还活着？

• 曲速流 → 汇合