万字带你走过数据库的这激荡的三年_clickhouse与timescaledb

本文收集了卡内基梅隆大学计算机科学系数据库学副教授 Andy Pavlo 从 2021 到 2023 连续三年对数据库领域的回顾，希望通过连续三年的回顾让你对数据库领域的技术发展有所了解。

关于 Andy Pavlo：卡内基梅隆大学计算机科学系数据库学副教授，数据库调优公司 OtterTune 的 CEO 兼联合创始人。

为了聚焦于数据库技术趋势演变，本文未对原文“寒暄式”开头和注释性语句作翻译。此外，为了节约部分读者的时间，本文分为“观点简述”及“历年回顾”两部分：在“观点简述”部分，你将了解到 Andy 这 3 年对数据库的看法、见解；在“历年回顾”部分，你将了解到该年具体的数据库领域发生的事件，以及 Andy 对该事件的看法。

本文目录：

• 观点简述
• 历年回顾
  • 2023 年数据库回顾：向量数据库虽然大火，但没有技术壁垒
    • 向量数据库的崛起
      • Andy 说：向量数据库没有技术护城河
    • SQL 持续变好
      • 属性图查询（SQL/PGQ）
      • 多维数组（SQL/MDA）
      • Andy 说：SQL:2023 是个里程碑
    • MariaDB 的困境
      • Andy 说：数据库的声誉比以往任何时候都重要
    • 美国航空因政府数据库崩溃而停飞
      • Andy 说：历史悠久的核心数据系统，是每个数据库从业者最大的噩梦
    • 数据库的融资情况
      • Andy 说：无论初创公司，还是高估值的公司日子都不好过
    • 史上最贵的密码重置
      • Andy 说：意料之外的大人物生活
  • 2022 年数据库回顾：江山代有新人出，区块链数据库还是那个傻主意
    • 放缓的大规模数据库融资
      • Andy 说：不只是 OLAP 领域，OLTP 领域前景也一样严峻
    • 区块链数据库还是那个蠢点子
      • Andy 说：有让人信服的用例才是合格的新技术
    • 新的数据系统
      • Andy 说：欣然看到数据库领域的勃勃生机
    • 数据库先驱的逝世
      • Andy 说：这是一个让人难过的消息
    • 数据库的巨额财富和民主
      • Andy 说：Larry 干得漂亮
  • 2021 年数据库回顾：性能之争烽烟起，不如低调搞大钱
    • PostgreSQL 的主导地位
      • Andy 说：PostgreSQL 只会在未来几年变得更好
    • 基准测试之争
      • Databricks vs Snowflake
      • Rockset vs Apache Druid vs ClickHouse
      • ClickHouse vs TimescaleDB
      • Andy 说：性能之争不值当
    • 大数据搞大钱
      • Andy 说：我们正处在数据库的黄金时代
    • 消逝的数据库们
      • ServiceNow 收购了 Swarm64
      • Splice Machine 破产了
      • 私募公司收购了 Cloudera
      • Andy 说：2022 年可能会有更多的数据库公司倒闭
    • 坚持的回报
      • Andy 说：为 Larry 高兴

观点简述

从 2021 年兴起的数据库性能之争，似乎经过 2 年时间的洗礼，热度有所降低，2022、2023 的数据库厂商们相对 Peace 并没有发起过多的性能战。枯木又逢春，尽管向量数据库存在已久，2023 年 vector database 又大火的一把。不过在 Andy 看来，向量数据库并没有技术壁垒：有多种现成的集成方式，可快速集成向量能力到现有的数据库，这些集成方式甚至还有开源的，更是大大降低数据库厂商的集成成本。SQL 新规范 SQL:2023 在对图数据的支持上，虽然目前只是做了读查询的适配，在 Oracle v23c 给出了 Oracle 的图查询示例。不过，目前跟进 SQL/PGQ 的 DBMS 不多，像是 DuckDB 的实验性分支；此外，Andy 觉得 SQL/PGQ 对现有的图数据库并不会造成威胁，毕竟还有查询的性能问题需要攻克。在多维数组的支持上，SQL 新规范强化了数组功能，支持了真正意义上的数组——任意维度的数组。

在融资方面，2021 年是融资大年，各类数据库无论是初创还是老牌数据库厂商都能融到八位数的融资；到了 2022 年，上半年依旧保持着“好融资，融资高”的劲头，但在下半年融资情况急转直下，大额度的融资变少了，资金缩紧。这个情况延续到了 2023 年，除了市场融资变冷清之外，更多的资金集中到了同向量相关的领域，虽然还是有一些数据库厂商“破局”成功融到了钱。

在数据库可持续发展方面，自 2021 年 Swarm64、Cloudera 被收购，Splice Machine 破产之后。随后的 2022、2023 年，MarkLogic、Ahana、EverSQL、Seafowl 也先后分别被 Progress Software、IBM、Aiven、EnterpriseD 收购，结束了他们的“独立”生涯。

这 3 年也发生了一些逸事，比如 Oracle 的联合创始人 Larry Ellison 虽然在 2018 年在亿万富翁排名中跌至第十位，但是在 2021 年重返第五位，甚至在 2023 年仅次于 Bernard Arnault、Elon Musk、Jeff Bezos 以 1,070 亿美元名列第四。此外，Larry Ellison 在 2023 年还花了 10 亿给 Elon Musk 来重置他的 Twitter 密码好继续他的推特之旅。习惯用子女名来命名数据库的 MySQL、MaxDB、MariaDB 之父 Monty Widenus 估计最近的日子不好过，因为 MariaDB 的公司和基金会发生了一些矛盾，不仅如此，它的市值还蒸发了 90%。

除了上面的一些事件，像是美国航空因政府数据库崩溃而停飞 11,000 多架飞机、区块链数据库是个蠢点子之类的指控，就得你翻阅历年回顾了。

历年回顾

2023 年数据库回顾：向量数据库虽然大火，但没有技术壁垒

英文原文：https://ottertune.com/blog/2023-databases-retrospective

向量数据库的崛起

毫无疑问，2023 年是向量数据库的一年。尽管几年前相关的某些系统早已存在，但去年人们对 LLM 及其上构建的服务（例如，ChatGPT）的广泛关注让向量数据库成为大家的视线焦点。向量数据库旨在基于语义，而不仅仅是数据内容来提供更深层的数据检索能力，特别是针对非结构化数据。也就是说，应用程序可以搜索与主题相关的文档（例如，“有 Slinging 相关歌曲的 hip-hop 团体”），而不是包含精准关键字（例如，“Wu-Tang Clan”）的文档。

这种主题搜索所依赖的“魔法”是 transformer，它将数据转换为一个固定长度的一维浮点数向量，称之为嵌入 Embedding。人类虽然不能直接理解这些嵌入的值，但嵌入的内容编码了参数和 transformer 训练语料库之间的某种关系。这些嵌入向量的大小从简单 transformer 的数百维到高端模型的数千维不等。

假如，我们使用 transformer 为数据库中的所有记录生成嵌入，就能通过查找与给定输入在高维空间中最相近的记录嵌入来搜索相似记录。然而，暴力比较所有向量以找到最相近的匹配结果是非常昂贵的。这种暴力搜索的复杂度是 O(N * d * k)，其中 N 是嵌入的数量，d 是每个向量的大小，k 是你想要的匹配数量——你可能不知道这个复杂度代表什么，反正很糟糕就是。

这也促成向量数据库的崛起。本质上，向量数据库只是一个带有特定索引数据结构的文档数据库，以加速对嵌入的相似性搜索。不同于对查询进行精准匹配来找到最相似的向量，向量数据库用近似搜索来生成结果，在速度和精度之间做了权衡，这种结果做出了“足够好”的折中。

在 2022 年区块链数据库神话崩盘之后，风投们嗅到了向量数据库的商机，再次变得兴奋。他们几乎投资了向量数据库领域的所有主流玩家（厂商）们。在 2023 年的种子轮融资中，Marqo 爆出了一个 520 万美元的种子轮，Qdrant 拿到了 750 万美元的种子轮，而 Chroma 则融到一个巨额的 1,800 万美元种子轮。同年 4 月，Weaviate 在 B 轮成功融到 5,000 万美元。最抢眼的还是 2023 年 Pinecone 在 B 轮融到让人羡慕的 1 亿美元。很显然，向量数据库公司在正确的时间点出现在了正确的赛道。

Andy 说：向量数据库没有技术护城河

自从 LLM 在 2022 年末随着 ChatGPT 变成热点，在不到一年的时间，多家 DBMS 厂商便添加了自己的向量搜索扩展，其中包括有 SingleStore、Oracle、Rockset 和 ClickHouse。同时，不少基于 PostgreSQL 的数据库产品也宣布支持向量搜索；有些使用 pgvector 扩展（像 Supabase、AlloyDB），而另外一些则使用其他的开源 ANN（近似最近邻算法，Approximate Nearest Neighbor）库，比如：Timescale、Neon。此外，领先的 NoSQL 数据库，像 MongoDB 和 Cassandra，也支持了向量索引。

我们将多个 DBMS 对向量的快速支持，和先前 JSON 数据类型的兴起做个有意思的对比。在 2000 年代后期，原生存储 JSON 的 NoSQL 系统变得流行（像 MongoDB 和 CouchDB）。但在之后几年时间里，关系型 DBMS 的老牌厂商才添加了对 JSON 的支持，像 PostgreSQL、Oracle 和 MySQL 分别是在 2012、2014 和 2015 年支持的该类型。SQL 标准虽在 SQL:2016 中添加了操作 JSON 数据的函数，但直到 SQL:2023 才添加了官方的 JSON 数据类型。尽管许多关系型 DBMS 已经支持了概念上相似的 XML，这种适配的拖延还是让人唏嘘。

向量搜索索引的快速支持有两个可能的解释。第一个是能通过嵌入进行的相似性搜索越发重要，以至于每个 DBMS 厂商都快速推出了自己的向量版本并第一时间宣布该消息。第二个是引入新的访问方法和索引数据结构所需的工程成本如此低，以至于 DBMS 厂家们添加向量搜索并不需要太多工作。大多数厂商甚至没有从头开始编写向量索引，而是直接集成了几个可用的高质量开源库之一，像是 Microsoft DiskANN、Meta Faiss。

DBMS 集成向量搜索能力的成本如此低，向量 DBMS 厂商根本没有足够深的护城河来抵抗现有 DBMS 的侵略，保持竞争优势。

我最近和两家公司 Pinecone 和 Weaviate （上面提到融资成功的向量数据库厂商）的联合创始人聊过，他们可以走两条路（详情参考 Andy 对话 Weaviate CTO 的采访视频）。第一条路是，客户开始用向量 DBMS 作为“记录数据库”，厂商将为操作型工作提供更好的支持。最终，向量数据库会看起来更像流行的文档 DBMS，比如：MongoDB。接着，在五年内，像之前的 NoSQL 一样增加对 SQL 的支持。另一条路是，向量 DBMS 作为次级数据库，通过上游操作型 DBMS 的变更进行更新。就像人们使用 Elastic 和 Vespa 这样的搜索引擎 DBMS 一样。在这种情况下，向量 DBMS 可以在不扩展它们的查询语言或拥有更结构化的数据模型的情况下生存。

旁注： 我最近录制了一个关于向量与关系数据库的问答节目。在里面我提到了，每个关系型 DBMS 在未来五年内都将拥有一个高性能的向量索引实现。

SQL 持续变好

今年 2024 年是 Don Chamberlain 和 Ray Boyce (RIP) 在 IBM 研究院创建 SQL 的五十周年。最初被称为 SEQUEL（Structured English QUEry Language，结构化英语查询语言）的 SQL，自 1980 年代以来，一直是与数据库交互的事实标准。尽管 SQL 已经很老了，但它的使用情况和功能一直在增加，尤其是过去的十年。

去年，ISO/IEC 9075 规范的最新版本 SQL:2023 面世。这次更新包括了不少用来处理各种 SQL 方言中的痛点和不一致性的“好用功能”，比如：ANY_VALUE）。值得一提的是，当中两个 SQL 增强功能，进一步削弱了对替代数据模型和查询语言的需求。不过需要注意一点，新的 SQL 规范包含这些内容，并不代表你喜欢的关系型 DBMS 会立即支持这些新特性。

属性图查询（SQL/PGQ）

目前，SQL 支持对图进行只读查询。这允许应用程序在现有表上声明一个属性图结构。下面这个 Oracle v23c 的图示例，它记录了哪些人在哪支乐队中：

CREATE TABLE PEOPLE (ID INT PRIMARY KEY, NAME VARCHAR(32) UNIQUE);
CREATE TABLE BANDS (ID INT PRIMARY KEY, NAME VARCHAR(32) UNIQUE);
CREATE TABLE MEMBEROF (PERSON_ID INT REFERENCES PEOPLE (ID), 
                       BAND_ID INT REFERENCES BANDS (ID), 
                       PRIMARY KEY (PERSON_ID, BAND_ID));

CREATE PROPERTY GRAPH BANDS_GRAPH
   VERTEX TABLES (
      PEOPLE KEY (ID) PROPERTIES (ID, NAME),
      BANDS KEY (ID) PROPERTIES (ID, NAME)
   )
   EDGE TABLES (
      MEMBEROF
      KEY (PERSON_ID, BAND_ID)
      SOURCE KEY (PERSON_ID) REFERENCES PEOPLE (ID)
      DESTINATION KEY (BAND_ID) REFERENCES BANDS (ID)
      PROPERTIES (PERSON_ID, BAND_ID)
   );
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

它由 DBMS 决定是为属性图创建辅助数据结构（例如，邻接矩阵）还是仅跟踪元数据。你可以用 MATCH 关键字在 SQL 中编写图遍历查询，这个语法建立在现有查询语言（像是 Neo4j 的 Cypher，Oracle 的 PGQL 和 TigerGraph 的 GSQL）的基础上，并且兼容了新兴的 GQL 标准。以下查询返回每支乐队的成员数：

SELECT band_id, COUNT(1) AS num_members
   FROM graph_table ( BANDS_GRAPH
      MATCH (src) - [IS MEMBEROF] -> (dst)
      COLUMNS ( dst.id AS band_id )
   ) GROUP BY band_id ORDER BY num_members DESC FETCH FIRST 10 ROWS ONLY;
1
2
3
4
5

截至 2024 年 1 月，我知道的唯一支持 SQL/PGQ 的 DBMS 是 Oracle。DuckDB 的实验性分支虽然也支持 SQL/PGQ，但上面示例不能运行，因为两个数据库支持的语法略有不同。你可以从 CWI/DuckDB 研究员 Gabor Szarnyas 整理的这个 SQL/PGQ 的优秀资源列表中了解更多关于 SQL/PGQ 的信息。

多维数组（SQL/MDA）

从 SQL:1999 引入有限的单维度、固定长度数组数据类型以来，SQL 就支持数组类型。而 SQL:2003 更是增强了该功能，支持嵌套数组，而无需预定义最大基数。在 SQL:2023 中，SQL/MDA 部分更新支持了使用整数坐标的真正的多维数组，这些数组可以是任意维度。此外，Rasdaman 的 RQL 大大地启发了 SQL/MDA 语法，SQL 可以提供与其兼容，并与集合语义正交的结构和操作数组构造。借此让应用程序只用在 SQL 中与多维数组交互和操作，而无需将它们导出，例如：到 Python Notebook。下表展示了在 CREATE TABLE 语句中使用 MDARRAY 数据类型的不同示例：

尽管 SQL/MDA 规范在 2019 年以技术报告的形式出现，但直到 SQL:2023 它才被正式纳入 SQL 标准。据我所知，除了 Rasdaman 之外，没有其他生产级别的 DBMS 支持 SQL/MDA 扩展。我能找到的唯一其他数据库是 ASQLDB，一个数据库 HSQLDB 的分支。

Andy 说：SQL:2023 是个里程碑

SQL:2023 修订版是 SQL 这种通用查询语言持续进化和改进的下一个阶段。当然，SQL 并不完美，也不具备真正的可移植性，因为每个 DBMS 都有自己的特点、专有特性和非标准扩展。就像我个人就非常喜欢 PostgreSQL 的 :: 转换操作符快捷方式。

虽然 SQL/PGQ（SQL 对图的支持）是个大事，但我不觉得它会立即对图数据库造成威胁，因为已经有多种方法将面向图的查询转换为 SQL。包括 SQL Server 和 Oracle 在内的 DBMS 都提供了内置的 SQL 扩展，可以容易地存储和查询图数据。Amazon Neptune 则是在 Aurora MySQL 之上的图数据服务层。Apache AGE 在 PostgreSQL 之上提供了一个 openCypher 接口。我预测其他主流 OLAP 数据系统，例如：Snowflake，Redshift，BigQuery，都会在不久的将来支持 SQL/PGQ。

但在一个 DBMS 中添加 SQL/PGQ 并不像添加新语法那样简单。要确保图查询性能良好，需要考虑几个工程上的问题。例如，图查询执行多路连接来遍历图。但当这些连接的中间结果比基础表还大时，问题就来了。一个 DBMS 必须使用最坏情况下最优连接（WCOJ，Worst-case optimal join）算法来更有效地执行两表联合查询，而不是通常用来连接两个表的 hash join。另一个技术要点是使用因式分解来避免在连接过程中物化冗余的中间结果。这种类型的压缩让 DBMS 规避了一遍又一遍地用相同的连接记录导致内存耗尽的问题。

上面我提到的优化点，并不是说现有的图数据库都做到了。据我所知，像是 Neo4j、TigerGraph 等图数据库都没有实现。我唯一知道的实现了优化的是滑铁卢大学的嵌入式图数据库 Kuzu。大多数关系型数据库也没有实现它们，至少我知道的那些开源数据库没有。上面提到的 DuckDB 实验分支实现了 WCOJ 和因式分解优化，并在 2023 年的论文中显示，在一个行业标准的图基准测试中，其性能比 Neo4j 高出多达 10 倍。

我很久之前说过，SQL 可能在你出生之前就存在，到你去世它依然会存在。对于那些声称自然语言查询将完全取代 SQL 的说法，我依旧嗤之以鼻。

旁注：从上次我公开说到 2030 年图数据库都不会在数据库市场上超过关系型数据库以来，已经两年过去了。到目前为止，我还是对的。

MariaDB 的困境

过去的一年，MariaDB 频频出现在新闻报道中，而且大多数都不是什么好消息。独立于 MariaDB 基金会的 MariaDB 公司显然是一个混乱的公司。在 2022 年，这家公司试图借壳 SPAC 上市，但是股票（$MRDB）在 IPO 后的三天内立即跌了 40%。而为了加速在纽交所上市进度的借壳操作也被公诸于世。到 2023 年底，MariaDB 公司股价自开盘以来跌了 90% 以上。

因为这些糟糕的财务问题，MariaDb 公司宣布了两轮裁员。第一轮在 2023 年 4 月，但同年 10 月他们进行了另一轮更大规模的裁员。公司还宣布他们将关停两款产品：Xpand 和 SkySQL。前者是 MariaDB 公司在 2018 年收购的产品，当时它还被称为 Clustrix；我在 2014 年还参观了 Clustrix 的旧金山办公室，当时我觉得那里像个阴森的鬼城（办公室里一半的灯都熄灭了）。后者 SkySQL 的历史更加复杂。最初它只是一个提供 MariaDB 服务的独立公司，在 2013 年与 Monty Program AB 合并。在 2014 年，合并后的 Monty Program AB + SkySQL 公司变成了今天的 MariaDB 公司。但在 2023 年 12 月，公司又宣布 SkySQL 没有“死去”，而是作为一个独立公司重新回到了市场！

MariaDB 公司的情况如此糟糕，以至于 MariaDB 基金会的 CEO 专门写文章，抱怨自从 MariaDB 公司上市以来基金会与公司的关系是如何恶化，他希望能够重新审视彼此关系。雪上加霜的是，微软在 2023 年 9 月宣布，未来不再提供作为托管 Azure 服务的 MariaDB，而是改为采用 MySQL。可能有人不知道，MariaDB 本身就是 MySQL 的一个分支，是 MySQL 的原创始人 Monty Widenus 在 2009 年 Oracle 宣布收购 Sun Microsystems 后创建的。回忆下，Oracle 在 2005 年买了 InnoDB 的制造商 InnoBase，Sun 在 2008 年买了 MySQL AB。现在 MySQL 运行良好，MariaDB 却遇到了问题。戏剧来源于现实，多看看数据库市场你能吃到各种瓜！

Andy 说：数据库的声誉比以往任何时候都重要

过去的十年，数据库客户的精明程度有了大幅度的提升。各家公司也不再能仅凭华而不实的性能数字、取代 SQL 的新查询语言，或是名人效应来“扮成功直到真正成功”了。数据库的声誉比以往任何时候都更为重要，其背后的公司声誉也同样重要。也就是说，这意味着软件本身的稳定很重要，其公司也得有条不紊地运作。

开源数据库背后的公司如果倒闭了，很少数据库能继续发展和繁荣。不过，PostgreSQL 算一个例外，尽管今天我们用的开源版本是基于加州大学伯克利分校的源码，而不是 1996 年被 Informix 收购的商业版本 Illustra。另一个例子是，为 MySQL 构建 InfiniDB OLAP 引擎的公司在 2014 年破产后，其 GPLv2 源码被接手并作为 MariaDB 的 ColumnStore 持续发展。

相反，更多现实告诉我们，一旦支付最多开发费用的公司消失，对应的数据库就会逐渐衰落。唯二在某种程度上算是活下来数据库的例子是 Riak 和 RethinkDB。Basho 在 2017 年破产后，现在 Riak 由在 UK’s NHS 工作的一个人维护。RethinkDB 公司在 2017 年倒闭（鉴于创始人对女性在科技界的看法，这并不奇怪）后，数据库源码就被转移到了 Linux 基金会。尽管基金会接手了项目，RethinkDB 仍处于活着的状态：该项目在 2023 年发布了一个新版本，但它们只是热修复，来解决一些已知问题。有兴趣的话，你可以去 Apache 基金会档案室看看那些被遗弃的数据库项目。

只在云端提供数据库服务的 DBaaS，在稳定性上只会更糟糕。因为如果公司失败，或是开始面临财务压力，他们就会关闭托管你数据库的服务器。Xeround 在 2013 年关闭云服务时，给了他们的客户两周时间迁移数据。为了降低成本，InfluxDB 在 2023 年 7 月删除整个 region 前给了客户六个月的时间迁移，但大家还是大吃一惊。

MariaDB 比一般的数据库创业公司处于更好的位置，因为 Monty 和其他人成立了一个管理开源项目的非营利基金。但当你是一个以盈利为目的的开源数据库公司，而帮助你管理该 DBMS 运作的非营利组织公开表示你管理混乱的话，那就是一个坏兆头！与此同时，MySQL 在持续改善，Oracle 依旧是那个从工程角度看不错的企业级数据库选择。MariaDB 公司的混乱将进一步促进人们转向使用 PostgreSQL。

MariaDB 肯定不能失败，据我所知，Monty 没有更多的孩子可以用来给数据库命名了（例如：MaxDB、MySQL、MariaDB）。

小趣闻：MariaDB 取名自 Monty 的小女儿 Maria，MaxDB 取名自儿子 Max，MySQL 来自大女儿 My。

美国航空因政府数据库崩溃而停飞

在 2023 年 1 月 11 日，由于飞行通知 NOTAM 系统故障，联邦航空管理局 FAA 停飞了美国所有的航班。NOTAM 系统向飞行员提供以纯文本编码的消息，告诉他们可能在飞行路径上会遇到的意外和潜在危险。当 NOTAM 系统在 1 月 11 日早晨崩溃时，直接导致美国大约 11,000 架航班无法起飞。所幸的是，其他国家运行着独立的、不受美国 NOTAM 故障影响的 NOTAM 系统能正常起飞。

根据 FAA 官方说法，这次故障是由于一个数据库文件损坏导致的。一名来自第三方承包商的工程师尝试用备份文件替换它，但结果是备份文件也有问题。2008 年也发生了类似的事件。

关于 FAA 在 NOTAM 所用的 DBMS 并没有公开信息。有一些报道称，NOTAM 仍然在运行于 1988 年的两台 Philips DS714/81 大型机上。但这些 Philips DS714 机器没有我们今天所知的操作系统；它们是 1960 大型机年代的遗物。也就是说，在 1980 年代 FAA 无法为应用使用现有的数据库系统，即便是那些当时已经存在的数据库，像是 Oracle、Ingres 和 Informix 都支持当时的各种 Unix。我觉得比较合理的可能是，NOTAM 可能用 Flat File（比如：CSV）来自行管理数据。1980 年代由非数据库专家编写的应用程序代码负责从文件中读取/写入记录，复制到备用服务器，并在出现故障时维护数据的完整性。

Andy 说：历史悠久的核心数据系统，是每个数据库从业者最大的噩梦

在无法替代的传统硬件上运行关键任务系统，使用的还是由早就退休的内部开发人员编写的自定义数据库访问库，这是每个数据库从业者最大的噩梦。我很惊讶它竟然没崩溃得更早（除非 2008 年的故障是同一系统），我觉得我们应该给这个运行了 35 年的系统一些掌声。

有消息称，NOTAM 系统每秒只处理 20 条消息。按照现代数据标准，这个数据量真的很小，但别忘记，FAA 是在 1980 年代配置的这个系统。数据库传奇人物，1998 年图灵奖得主 Jim Gray 在 1985 年写到，“普通”的数据库管理系统可以执行大约每秒 50 次事务（txn/sec），而非常高端的系统可以达到每秒 200 次。作为参考，五年前，有人使用 1980 年代的基准测试（基于 TPC-A 的 TPC-B）在树莓派 3 上运行 PostgreSQL，大约达到了每秒 200 次事务。如果我们不考虑那些使用跨数据中心的强一致性复制（这会受到光速的限制）的系统，现代单节点在线事务处理（OLTP）DBMS 可以在某些工作负载下实现每秒数百万次事务的吞吐量。NOTAM 在 1980 年代的峰值每秒 20 条消息的吞吐量并没有推动当时的技术极限，而且显然今天也没有。

因为 NOTAM 没有将数据库与应用程序逻辑分离，所以独立升级这些组件是不可能的。考虑到在 1980 年代中期，关系模型的优点已经众所周知，NOTAM 这种设计是该批判的。当然，并不是说 SQL 就能防止这次确切的失败（这是一个人为错误），但独立性会让各个组件不那么笨重，更易于管理。

尽管如此，当时美国政府其实已经在用商用关系型 DBMS。例如，Stonebraker 的 RTI（Ingres 厂商）在 1988 年的 IPO 申报文件中提到，他们现有的客户包括国防部和内政部、军事分支和研究实验室。我相信当时美国政府的其他部门也在使用 IBM DB2 和 Oracle。因此，除非 NOTAM 有什么我不知道的特别之处，不然 FAA 本可以使用真正的数据库管理系统。

停飞事件发生的时候，我正在阿姆斯特丹的 CIDR 2023 会议的返程中。幸运的是，停飞没有影响入境的国际航班，我的飞机可以顺利地降落。但我还是被困在纽瓦克机场，因为美国所有国内航班都停飞了。熟悉纽瓦克机场的人都知道，在这里待着并不是什么好事。

延伸阅读：你可以阅读我之前的文章，了解下为什么如果 NOTAM 数据库运行在 Amazon RDS 上，不太可能发生数据库崩溃。

数据库的融资情况

除了上面提到的向量数据库是风投的“新宠”之外，其他类型的数据库在 2023 年也是有融资的。但总体而言，今年的数据库融资活动比往年要冷清得多。

自动调优初创公司 DBTune 在欧洲完成了 260 万美元的种子轮融资。PostgresML 获得了 450 万美元的种子轮融资，来打造一个通过自定义扩展来支持从 SQL 调用 ML 框架的 DBaaS。TileDB 在秋季宣布完成了 3,400 万美元的 B 轮融资，以此继续完善他们的阵列数据库管理系统。尽管有着 13 年的历史，SQReam 还是获得了 4,500 万美元的 C 轮融资，来继续开发他们的 GPU 加速数据库管理系统。Neon 在 2023 年 8 月完成了 4,600 万美元的 B 轮融资，以扩展无服务器 PostgreSQL 平台。当然，2023 年的融资赢家再次是 Databricks，他们在 2023 年 9 月完成了 5 亿美元的 I 轮融资。虽然这是一笔巨款，但并不如他们在 2021 年 H 轮的 16 亿美元来得多。

Peter Boncz 和 Tianzhou Chen 提醒我了，还有 MotherDuck（DuckDB 的商业版本）在 2023 年 9 月完成的 5,250 万美元的 B 轮融资。另一个数据库产品 DBeaver，完成了 500 万美元的种子轮融资，来继续研发受欢迎的 multi-DBMS 。

此外，2023 年数据库领域也发生了一些收购。最大的一笔交易在年初发生，MarkLogic 被 Progress Software 以 3.55 亿美元现金收购。MarkLogic 是最古老的 XML 数据库管理系统之一（约 2001 年），而 Progress 拥有 OpenEdge，一种更古老的数据库管理系统（约 1984 年）。IBM 收购了 Meta 的衍生公司 Ahana，该公司试图将 PrestoDB（它不同于已经更名为 Trino 的 PrestoSQL）商业化。多云数据库服务提供商 Aiven 收购了 AI 驱动的查询重写器初创公司 EverSQL。EnterpriseDB 用 Bain Capital（私募投资公司）的资金收购了基于 DataFusion 兼容 PostgreSQL 的 OLAP 引擎的 Seafowl 团队。Snowflake 收购了两家初创公司：（1）由前斯坦福教授 Peter Bailis 打造的 Sisu Data，以及（2）由伯克利教授 Aditya Parameswaran 基于 Modin 研发的 Ponder。

Andy 说：无论初创公司，还是高估值的公司日子都不好过

我的风投朋友们说，他们在 2023 年看到了更多新公司的推介，但比往年签发的支票更少。这个趋势贯穿所有初创领域，数据库市场也不例外。大部分的风投注意力都在那些和人工智能+大型语言模型（LLM）有一点点关系的项目，这也合理，毕竟这是计算领域的新篇章。

尽管美国 2023 年的宏观经济指标有些积极的迹象，但科技产业依旧紧张，每家企业都在削减成本。像 OtterTune（作者所在的公司）客户希望我们的数据库优化服务能在 2023 年帮助他们降低数据库基础设施成本。这与公司早些年人们主要来找 OtterTune 提高数据库管理系统的性能和稳定性不同。我们计划在 2024 年宣布新功能，以帮助降低数据库成本。回到大学，这个学期有比平常更多的学生请我帮他们找数据库开发的工作。这让我很吃惊，因为 CMU 的计算机科学学生一直不愁找工作，靠自己就拿到不错的实习和全职 offer，除了有次我最优秀的本科生重写了我们的查询优化器，但因为忘了问我，结果找不到暑期实习，最后在匹兹堡机场附近的迪克体育用品店做网页开发——他现在在 Vertica 工作得很开心。

如果美国的科技市场继续低迷不振，接下来的几年众多数据库初创公司都难有大发展。小型的数据库初创公司要么会被大型科技公司或私募股权收购，要么就直接倒闭。但是，那些融到大笔钱且估值很高的公司也不好过。正如我之前说的那样，有些公司可能无法 IPO，而且没有哪家大型科技公司会需要这些 DBMS，因为如今大家都有自己的数据库系统。因此，这些大数据库管理系统公司将面临三个选择：接受降低估值的融资以保持运营；通过私募股权获得支持，保持运营（比如：Cloudera）；被一家 IT 服务公司收购（比如：Rocket，Actian），这些公司将 DBMS 置于维护模式，但继续从那些被困的客户那里收取许可费，因为这些客户有他们无法轻易迁移的遗留应用程序。不过，这三条路对于数据库公司来说都不理想，应该会吓跑潜在的新客户。

最后，我要重述一句：不要问 Databricks 是不是会 IPO，而是它何时会 IPO。

史上最贵的密码重置

2023 年，数据库传奇大佬 Larry Ellison 春风得意。对于他原本杰出的职业生涯来说，2023 年也是一个标志性的一年。2023 年 6 月，他重返世界第四富有的位置。Oracle 公司的股价（$ORCL）在 2023 年上涨了 22%，略低于标准普尔 500 指数 24% 的回报率。此外，在 2023 年 9 月，Larry 第一次去了 Redmond，并与微软首席执行官 Satya Nadella 一起登台宣布，Oracle 可作为 Azure 云平台上托管服务使用。随后同年 11 月，股东们压倒性地投票支持 79 岁的 Larry 继续担任 Oracle 董事会主席。

但 2023 年真正的大新闻是，Elon Musk 在 Larry 对 Musk 收购社交媒体公司投资了 10 亿美元后，亲自帮 Larry 重置了 Twitter 密码。正是这笔价值 10 亿美元的密码重置，我们在 2023 年 10 月有幸看到了 Larry 的第二条推文，也是他十多年来的首条新推文。Larry 预告了他即将前往牛津大学的行程，后来他在那里宣布在牛津大学成立埃里森技术研究院（EIT）。

Andy 说：意料之外的大人物生活

其实 Larry 发了什么根本不重要，重要的是 Larry 回归推特发推文。我偷偷打听过，Larry 偶尔会看看推特，主要关注创业点子提案、祝福以及不经意冒出的奇思妙想。

Larry 的推文之所以出人意料，是因为人们一般会认为他总是忙于更宏伟的活动。毕竟，他拥有一架 MiG-29 战斗机和一个夏威夷岛屿。他有很多更伟大的事情可以做。所以，当他抽出时间在一个日益衰落的社交媒体上写推文，告诉我们他在做什么。这对我们所有人来说，都是一个重大的生活事件。为此，Larry 不得不请他那个世界上最富有的朋友来重置他的密码。虽然花费 10 亿美元，但当你拥有 1,030 亿美元时，这都不是什么事了。

2022 年数据库回顾：江山代有新人出，区块链数据库还是那个傻主意

英文原文：https://ottertune.com/blog/2022-databases-retrospective

放缓的大规模数据库融资

正如我去年说的那样，2021 年是数据库融资的大年。随着投资者继续寻找下一个 Snowflake，大量资金涌向了新的 DBMS 初创公司。2022 年初看起来像是要再过一次 2021 年，有非常多的大额融资消息。

融资狂欢在 2022 年的 2 月开始，Timescale 完成了 1.1 亿美元的 C 轮融资，Voltron Data 完成了 1.1 亿美元的种子轮 + A 轮融资，Dbt Labs 完成了 2.22 亿美元的 D 轮融资。Starburst 在 3 月宣布了他们 2.5 亿美元的 D 轮融资来继续提升他们的 Trino 产品。Imply 在 5 月拿出 1 亿美元的 D 轮融资用于开发他们的 Druid 商业版本。DataStax 在 6 月的 IPO 途中获得了 1.15 亿美元的资金。最后，SingleStore 在 7 月完成了 1.16 亿美元的 F 轮融资，然后在 10 月又融了 3,000 万美元。

2022 年上半年还有几家较小的公司完成了让人印象深刻的 A 轮融资，包括 Neon 的 3,000 万美元 A 轮用来研发无服务器 PostgreSQL 产品，ReadySet 2,900 万美元 A 轮融资来研发查询缓存层，Convex 的 2,600 万美元 A 轮来继续开发他们基于 PostgreSQL 的应用程序框架，以及 QuestDB 的 1,500 万美元 A 轮来开发时序数据库。尽管我们 OtterTune 没有新的 DBMS 或相关基础设施，但我们也在 4 月完成了 1,200 万美元的 A 轮融资。

但是，到了 2022 年下半年，大规模的融资轮停止了。尽管早期初创公司还是有较小额的融资进来，但更后面的公司再也没有九位数的美元融资了。

流处理引擎 RisingWave 在 10 月筹集了 3,600 万美元的 A 轮，Snowflake 查询加速器 Keebo 融到 1,050 万美元的 A 轮资金。在 11 月，我们看到了 MotherDuck 的 4,500 万美元种子轮 + A 轮融资的新闻来开发商业化 DuckDB 的云版本，以及 EdgeDB 在 11 月的 1,500 万美元 A 轮融资。最后，是 SurrealDB 完成了 600 万美元的种子轮融资。我可能漏掉了一些其他公司，这不是一个详尽的列表。

在数据库领域唯一其他值得注意的金融事件是，MariaDB 在 12 月的灾难性地通过 SPAC IPO，股价在首个交易日就下跌了 40%。

Andy 说：不只是 OLAP 领域，OLTP 领域前景也一样严峻

与 2021 年相比，在 2022 年大额融资轮减少的原因有两个。最明显的是整个科技行业在降温，部分原因是人们对通货膨胀、利率和加密经济崩溃的担忧。另一个原因是，有能力大额融资的公司在资金干涸之前就完成了融资。

例如，Starburst 在 2021 年完成了 1 亿美元的 C 轮融资后，在 2022 年进行了它的 D 轮融资。在过去两年完成巨额融资的数据库公司，很快就需要再次融资来保持增长势头。

坏消息是，除非科技行业有所改善，并且大型机构投资者开始再次将资金投入市场，否则这些公司们将面临困境。市场无法维持这么多独立软件供应商（ISVs）为数据库服务。这些拥有十亿美元估值的公司唯一继续前进的法子是，进行首次公开募股或破产。这些公司对于大多数公司来说太贵了，无法被收购（除非风投公司愿意大打折扣）。

此外，进行大型并购的大型科技公司（比如：亚马逊、谷歌、微软）都有了自己的云数据库产品。因此，不清楚谁会收购这些数据库初创公司。亚马逊没有理由在他们 Redshift 每年赚取数十亿美元时，去以 2021 年的 20 亿美元估值购买 ClickHouse。这个问题不仅限于 OLAP 数据库公司；OLTP 数据库公司很快也将面临同样的问题。

我并不是唯一一个对数据库初创公司的前景做出如此严峻预测的人。Gartner 分析师预测，到 2025 年，50% 的独立 DBMS 供应商将退出市场。显然我有自己的看法，我认为未来生存下来的公司是那些致力改善或者是强化 DBMS 的公司，而不是替换它们的公司（比如：dbt、ReadySet、Keebo 和 OtterTune）。

我无法判断 MariaDB 借壳 SPAC “快速上市”是否是个好主意。这种金融操作不在我的专业领域（数据库）内。但既然这和前美国总统用他的社交媒体公司做的事情一样，我就姑且认为它不是什么好主意。

区块链数据库还是那个蠢点子

关于 Web3 根本性转变了构建新应用程序方式这点，有很多夸张的说法。我有一个学生甚至因为我教授的是关系数据库而不是 Web3，愤然从我的课堂离席。Web3 运动的核心是在区块链数据库中存储状态。

区块链本质上是去中心化的分散的日志结构数据库（即，账本），它们通过使用某种 Merkle 树的变体和 BFT 共识协议来维护增量校验和，从而确定下一个要入库的更新。这些增量校验和是区块链确保数据库日志记录不变性的方式：客户端使用这些校验和来验证之前的数据库更新没有被更改。

区块链是之前想法的巧妙结合。但是，厂商们认为去中心化账本是每个人构建 OLTP 应用程序必须的，这点是一种误导。从数据库的角度，除了加密货币之外，区块链数据库和现有的 DBMS 没有任何差别。此外，任何区块链在数据库安全性和可审计性比现有 DBMS 表现更好的说法，都是胡说。

如果说加密货币是区块链数据库的最佳实践，那么 2022 年加密市场的崩溃显然没有帮到它们，甚至是进一步阻碍了区块链数据库的发展。当然我会忽略 FTX 的崩盘（他们申请了破产保护），毕竟它就是彻头彻尾的诈骗，和数据库一点关系都没。不过，我要指出，FTX 和所有其他加密货币交易所一样，并没有在区块链数据库上运行业务，而是使用了 PostgreSQL。

此外，其他与加密货币无关的区块链数据库用例，如交易和游戏平台，都因为不切实际或诈骗没有落地。

Andy 说：有让人信服的用例才是合格的新技术

评估某项技术的原则之一是，一旦厂商开始制作它的媒体广告，它就不再是“新”技术了。简单来说，像是 IBM 之类的厂商在打广告的时还没有出来让人信服的用例，那么这个产品永远也不会有用例。

举个例子，IBM 在 2002 年在一则商业广告中吹捧 Linux 是一个热门的新事物，但那时已经有包括谷歌在内的成千上万的公司将 Linux 作为主要服务器操作系统使用了。所以，当 IBM 在 2018 年发布他们的区块链广告时，我就知道这项技术除了在加密货币领域有用，在其他领域毫无用处。因为其他领域没有一个问题是去中心化的区块链能解决，而中心化的 DBMS 不能解决的。

因此，2022 年 IBM 宣布将关闭与航运巨头 Maersk 合作的供应链 IT 基础设施改造项目，也就不奇怪了，毕竟这正是 IBM 在广告中炒作的场景。

相比任意一个可信权威管理、只允许受信任的客户端直连、用心编写的事务数据库，区块链数据库的效率低得可怕。除了加密货币（见上文）或者其他什么欺诈场景，现实数据世界的运行方式都是和其他数据库目前处理的那样。

信任是一个正常运转的社会的基石。例如，我授权托管 OtterTune 网站的公司向我的信用卡收费，他们又信任一个云提供商来托管他们的软件。没人会需要使用区块链数据库来进行这些“信任”交易。

从工作量证明（PoW：proof-of-work）转换到不那么费事的权益证明（PoS：proof-of-stake），共识机制确实提升了区块链数据库的性能。但这只影响数据库的吞吐量；区块链交易的延迟仍然以数十秒计算。如果解决这些长延迟的方法是使用参与者较少的 PoS 区块链，那么应用程序使用 PostgreSQL 来认证这些参与者会更好。

你可以读一读 Tim Bray（XML 之父）同 AWS 高层内部讨论是否有区块链可行用例的精彩文章。值得留意的是，Tim 说 AWS 在 2016 年就得出过区块链数据库是数据问题的解决方案的结论，这比 IBM 推出区块链数据库广告早了两年！虽然 AWS 最终在 2018 年发布了 QLDB 服务，但它不同于区块链；它是一个中心化的可验证账本，不使用 BFT 共识。与亚马逊极为成功的 Aurora 产品相比，QLDB 客户的采用率一直不太理想。

趣闻：在 FTX 崩盘（申请破产保护）前的三周，有人和我说 OtterTune 的全职工程师人数和 FTX 在巴哈马的团队一样。这个人还说，既然工程师人数一样，OtterTune 应该像 FTX 那样更有前景，而且现在应该有 10 亿美元的年度经常性收入（ARR）。真是有意思呀。

新的数据系统

今年有不少新的 DBMS 软件的重大新闻：

• Google AlloyDB：2022 年最让人震惊的消息是 5 月份谷歌云宣布了它们的新数据库服务。AlloyDB 不是基于 Spanner 构建的，而是一个修改版的 PostgreSQL，它分离了计算层和存储层，并且支持在存储中直接处理 WAL 记录。
• Snowflake Unistore：6 月份，Snowflake 宣布了他们的新 Unistore 引擎，用“混合表”来支持 DML 操作的低延迟交易。当查询要更新表时，变更会传到 Snowflake 的列式存储中。SingleStore 数据库的某个人有些激动，说 SingleStore 在这个领域有一些专利，虽然这个说法没啥实质性证据支撑。补充信息：SingleStore 和 Snowflake Unistore 有部分技术交集，你可以理解为他们存在一定的竞争关系。
• MySQL Heatwave：当 Oracle 发现 Amazon 从 MySQL 赚的钱比他们多后，终于在 2020 年决定为 MySQL 构建自己的云服务。但他们并没有仅仅做个 RDS（关系数据库服务）克隆版，而是用一个叫做 Heatwave 的内存向量化 OLAP 引擎扩展了 MySQL。2021 年 Oracle 还宣布他们的 MySQL 服务还支持自动化数据库优化（但与 OtterTune 提供的优化服务不同）。到了 2022 年，Oracle 终于发现他们不是领先的云供应商，并向 AWS “低头”在 AWS 上托管了 MySQL Heatwave。
• Velox：Meta 在 2020 年开始构建 Velox，作为 PrestoDB 的新执行引擎。两年后，他们宣布了这个项目并发表了一篇关于它的 VLDB 论文。Velox 并不是一个完整的 DBMS：它不带 SQL 解析器、目录、优化器或网络支持。相反，它是一个带有内存池和存储连接器的 C++ 可扩展执行引擎。人们可以基于 Velox 构建一个成熟的 DBMS。
• InfluxDB IOx：就像 Meta 的 Velox 一样，Influx 团队在过去两年一直在努力开发新 IOx 引擎。在 10 月，他们宣布新引擎正式上线（GA）。InfluxDB 从零开始基于 DataFusion 和 Apache Arrow 构建了 IOx。值得庆祝下的是，我在 2017 年和 Influx 的 CTO 说使用 MMAP 是个坏主意后，他们在新系统中抛弃了 MMAP。

Andy 说：欣然看到数据库领域的勃勃生机

很高兴见证了 2022 年数据库领域发生的这些事。我对 AlloyDB 的看法是，它是一个简洁的系统，当中投入了让人感叹的工程量，但我还是不知道它有什么创新点。AlloyDB 的架构类似于 Amazon 的 Aurora 和 Neon，在 DBMS 存储中有个额外的计算层，可以独立于计算节点处理 WAL 记录。尽管谷歌云已经拥有坚挺的数据库产品组合（比如：Spanner、BigQuery），但它们还是觉得有必要构建 AlloyDB 来尝试赶上亚马逊和微软。

需要关注的长期趋势是诸如 Velox、DataFusion 和 Polars 之类的框架的普及。结合像 Substrait 之类的项目，这些查询执行组件的商品化意味着未来的五年内，所有的 OLAP DBMS 将在性能上大致持平。

与其完全从头开始构建一个新的 DBMS，或者是 hard fork 一个现有系统（像 Firebolt fork ClickHouse），比如使用一个像 Velox 这样的可扩展框架。也就是说，每个 DBMS 都将具备同 Snowflake 十年前独有的相同向量化执行能力。尤其是在云上，存储层对每个人来说都是相同的（比如：亚马逊控制的 EBS/S3），那么区分 DBMS 产品的关键因素将会是那些难以量化的事物，如 UI/UX 设计和查询优化。

数据库先驱的逝世

在 2022 年 7 月有一个让人难过的消息，Martin Kersten 逝世了。Martin 是 CWI 的研究员，他是多个颇具影响力的数据库项目的引领者，包括 1990 年代最早的分布式内存 DBMS（PRISMA/DB）和 2000 年代最早的列式 OLAP DBMS（MonetDB）。因为他在数据库方面的贡献，Martin 在 2020 年因被荷兰政府授予皇家骑士称号。

MonetDB 的代码库还是其他几个 OLAP 系统项目的跳板。在 2000 年代末，Peter Boncz 和 Marcin Żukowski fork MonetDB 它开发 MonetDB/X100，后来商业化为 Vectorwise（现在叫 Actian Vector）。Marcin 后来离开，联合他人共同创立的 Snowflake，采用了原来他在 MonetDB 代码上开发的许多技术点。最近，Hannes Mühleisen 搞了个 MonetDB 的嵌入式版本 MonetDBLite，后来他又重写了项目，变成了现在的 DuckDB。

Martin 对现代数据库系统的贡献如此重大，以至于你如果使用任何现代分析型 DBMS（像是 Snowflake、Redshift、BigQuery、ClickHouse），你就是在享受 Martin 和他的学生在过去 30 年开发的众多进步成果。

Andy 说：这是一个让人难过的消息

我知道，相比 Mike Stonebraker（研究数据库的计算机科学家，2014 年图灵奖获得者）这样的人，数据库研究圈外人可能知晓 Martin 没那么多。我总把 Martin 看作是 Stonebraker 的欧洲版：他们都是多产的数据库研究者，高个子、瘦弱、戴眼镜，年龄相仿。但 Martin 并不是像 Nintendo Smitch 山寨 Nintendo Switch 那样的山寨货。

除了研究，在业余时间 Martin 也乐于同他人讨论数据库架构。我最后一次见 Martin 是在新冠爆发之前的 2019 年。我们就他为什么认为在 MonetDB 中使用 MMAP 是正确的选择争论了一个小时；他声称因为 MonetDB 专注只读的 OLAP 工作负载，所以 MMAP 就够好了。其实有件事很对不住 Martin，就是那些他应对过的在 YouTube 观看我的数据库课程后，给他发邮件询问为什么 MonetDB 做出了我声称的较差设计的学生。

我建议你看下 Martin 在 2021 年 CMU-DB 研讨会的压轴演讲。我和 Martin 承诺在他的演讲中，我不会用 MonetDB 采纳 MMAP 这点让他分心。为了表示诚意，在这个视频的前面 60 秒，我找了个荷兰人录制一个仿皇家的 Martin 短片介绍。

数据库的巨额财富和民主

2022 年 5 月，《华盛顿邮报》报道说，Oracle 创始人和帆船爱好者 Larry Ellison 参加了 2020 年 11 月刚结束的选举的电话会议，与会的有美国总统和其他保守派领袖。

电话会议集中讨论了总统的盟友和活动分子可能采取的、来推翻总统选举的结果的不同策略。正如《邮报》文中指出的那样，目前尚不清楚为什么政府要让 Larry 参与通话。一种猜测是，鉴于 Larry 显而易见的强大技术背景，他可能很适合评估外国势力利用某种方式来使用卫星技术来远程操控美国选举的说法是否可行。

Andy 说：Larry 干得漂亮

相信 Larry 和我都厌倦了人们对他支持美国右翼的离谱言论，甚至有人说这个电话是 Larry 做过的最糟糕的事。这不是真的，要知道这样的新闻和社交媒体言论会让 Larry 感到难过。

我向你保证，Larry 只是试图用他作为世界第七富有的人的巨额财富来帮助他的国家。他参与这次通话是值得钦佩的，应该受到赞扬。自由和公正的选举不是一件小事，不像划船比赛，有时候只要你能赢，搞点小动作也没关系。Larry 用他的钱做了一些被人忽视的伟大事情，比如：为了活得更久，在抗衰老研究上花费了 3.7 亿美元；投资了 10 亿美元帮助 Elon Musk 运营(?，那时候推特尚未被收购)推特。所以，我支持 Larry 这个行为。

2021 年数据库回顾：性能之争烽烟起，不如低调搞大钱

英文原文：https://ottertune.com/blog/2021-databases-retrospective

对数据库行业来说，2021 年是疯狂的一年，数据库的新人“超越”了老牌厂商，数据库厂商们为基准测试的数字争论不休，还有各种引人注目的融资轮次。好消息是不少，但是收购、破产或重组之类的不好消息，也让一些数据库消失在数据库市场。

PostgreSQL 的主导地位

开发者的认知已经发生转变：PostgreSQL 成为香饽饽，已是新应用程序的首选。它稳定可靠，功能丰富，且在不断增加新功能。2010 年，PostgreSQL 开发团队采取了更积极的发布计划，每年发布一个新的主要版本，这里要感谢下 Tomas Vondra。顺便提一嘴，PostgreSQL 是开源的。

如今，对很多系统来说，PostgreSQL 的兼容性是一个显著亮点。这种兼容性是通过支持 PostgreSQL 的 SQL 方言（如 DuckDB）、线协议（如 QuestDB、HyPer）或整个前端（如 Amazon Aurora、YugaByte、Yellowbrick）来实现的。大公司们也跟进了这个趋势。谷歌在 10 月宣布在 Cloud Spanner 中增加了 PostgreSQL 兼容性。还是在 10 月，亚马逊宣布了 Babelfish 功能，将 SQL Server 查询转换成 Aurora PostgreSQL 查询。

数据库受欢迎程度的一个衡量标准是 DB-Engine 排名。这个排名不是很客观，得分带有一点程度的主观性，但就排名前十的系统结果还是合理的。截至 2021 年 12 月，DB-Engine 排名显示，虽然 PostgreSQL 仍然是第四大流行数据库（仅次于 Oracle、MySQL 和 MSSQL），但它在过去的一年里缩小了与 MSSQL 的差距。

另一个值得考虑的趋势是 PostgreSQL 在线上社区的提及频率。它给我们提供了人们在数据库中讨论什么的信息。我下载了 Reddit 上 2021 年在数据库相关的所有评论，并计算了数据库名称的出现频率，自然 PostgreSQL 在其中。我又交叉参考数据库的列表，合并了缩写（例如，Postgres → PostgreSQL，Mongo → MongoDB，ES → Elasticsearch），最后整理出了前 10 个提及最多的 DBMS：

     dbms      | cnt 
---------------+-----
 PostgreSQL    | 656
 MySQL         | 317
 MongoDB       | 266
 Oracle        | 222
 SQLite        | 213
 Redis         |  88
 Elasticsearch |  70
 Snowflake     |  52
 DGraph        |  46
 Neo4j         |  42
1
2
3
4
5
6
7
8
9
10
11
12

自然，这个排名还是不科学，因为我没有对评论进行情感分析。但它清楚地显示了，在过去的一年里，人们提到 Postgres 的次数远超过其他数据系统。经常有开发者发帖询问新应用该用什么 DBMS，线上社区的回应几乎都是 Postgres。

Andy 说：PostgreSQL 只会在未来几年变得更好

首先，关系数据库系统成为新应用的首选肯定是一件好事。这表明 Ted Codd 在 1970 年代提出的关系模型的持久影响力。其次，PostgreSQL 是一个很棒的数据库系统。同所有 DBMS 一样，它有已知的问题和不足之处。但是有着如此高的关注，PostgreSQL 只会在未来几年变得更好。

基准测试之争

不同的数据库厂商之间在基准测试结果争议，今年并不少见。数据库厂商们试图证明他们的系统比竞争对手的更快，这种做法可以追溯到 1980 年代末。这也是为什么 TPC（交易处理性能委员会）成立的原因，希望能提供一个中立平台来监管性能比较。但是，随着 TPC 在过去十年的影响力和普及度的减弱，数据库们再次处于数据库基准测试战争的漩涡中。

让人印象深刻的有三场基准测试争论。

Databricks vs Snowflake

Databricks 宣布他们新的 Photon SQL 引擎在 100TB TPC-DS 测试中创造了新的世界纪录。Snowflake 回击说，他们的数据库速度是 Databricks 的两倍，并且 Databricks 运行 Snowflake 的方式不正确。Databricks 反驳道，他们的 SQL 引擎在执行和价格、性能方面都优于 Snowflake。

Rockset vs Apache Druid vs ClickHouse

ClickHouse 强势声明，与 Druid 和 Rockset 相比，CK 的成本效率方面更出色。但没那么简单：Imply 立即用 Druid 的新版本进行了测试，并声称 Druid 获得了性能胜利。Rockset 也加入了讨论，说它的性能在实时分析上比其他两个要好。

ClickHouse vs TimescaleDB

感受数据库市场的风向变化，采取老虎式行事风格的 Timescale 加入了性能战争。他们发布了自己的基准测试结果，并借此机会指出 ClickHouse 技术的弱点。在 Hacker News 上，第三方基准测试的相关讨论变得非常火爆。

Andy 说：性能之争不值当

在先前的数据库基准测试中，已经有太多血淋淋的故事（参考：https://www.percona.com/blog/is-voltdb-really-as-scalable-as-they-claim/ 、https://www.youtube.com/watch?v=-TIUGC4X2q8&t=418s），我也曾是其中一员。但在性能竞争的路上，我失去了太多：不只是朋友，还有女朋友。随着时间的流逝，现在我觉得性能之争不值得。

现如今客观地比较数据系统更加困难，因为云数据库管理系统有很多可移动的部件和可调选项，往往很难确定性能差异的真正原因。真实的应用程序也不仅仅是一遍又一遍地运行相同的查询。在提取、转换和清洗数据时的用户体验，和原始性能数字一样重要。正如我在这篇关于 Databricks 基准测试结果的文章中告诉记者的那样，只有老年人才关心官方的 TPC 数字。

大数据搞大钱

自 2020 年下半年以来，价值至少 1 亿美元的风险投资轮次数量一直在稳步增加。2020 年有 327 笔这样的大宗交易，几乎占总风险资本交易量的一半。截至 2021 年 1 月，价值 1 亿美元或以上的风险投资回合已经超过 100 轮。

2021 年，大量投资资金涌向数据库公司。在运营数据库方面，CockroachDB 以 1.6 亿美元的融资轮次领跑筹资排行榜，在 2021 年 12 月它再次融了 2.78 亿美元。Yugabyte 完成了 1.88 亿美元的 C 轮融资。PlanetScale 为他们的 Vitess 托管版融到了 2,000 万美元的 B 轮。相对较老的 NoSQL 簇拥者 DataStax 为他们的 Cassandra 实现了 3,760 万美元的风险融资。

尽管这些融资金额都很惊人，分析型数据库市场的竞争更为激烈。TileDB 在 2021 年 9 月筹集了一笔未披露金额的资金。Vectorized.io 为他们与 Kafka 兼容的流处理平台筹到 1,500 万美元。StarTree 不再低调，宣布了用来打造商业化 Apache Pinot 的 2,400 万美元融资。有着附加功能的物化视图的 DBMS Materialize 宣布他们在 C 轮获得了 6,000 万美元。Imply 为基于 Apache Druid 的数据库服务筹集了 7,000万美元。SingleStore 在 2021 年 9 月筹集了 8,000 万美元，使他们朝着 IPO 迈近了一大步。

2021 年年初，Starburst Data 为其 Trino 系统（前身为 PrestoSQL）筹集了 1 亿美元。Firebolt 是另一家不再低调 DBMS 初创公司，他们发布了基于 ClickHouse 分支的云数仓的 1.27 亿美元融资新闻。一家新公司，ClickHouse, Inc.，融了可怕的 2.5 亿美元，来以 ClickHouse 为主建立新公司，以及从 Yandex 获得使用 ClickHouse 名称的权利。

不过 2023 年数据库领域融资的最大赢家显然是 Databricks，他们在 2021 年 8 月筹集了高达 16 亿美元的资金，遥遥领先其他数据库。

Andy 说：我们正处在数据库的黄金时代

我们正处在数据库的黄金时代，有很多优秀的数据库可以选择。投资者们正在寻觅下一个像 Snowflake 一样可以 IPO 的数据库初创公司。2021 年的融资金额比以往数据库初创公司都要大。例如，Snowflake 直到成立五年后的 D 轮融资才有超过 1 亿美元的单轮融资。Starburst 在成立不到三年的时间内就完成了 1 亿美元的融资。现在融资涉及许多因素，比如：Starburst 团队从 TeraData 独立出来之前已经在 Presto 工作多年，我觉得如今数据库的投入资金更多了。

消逝的数据库们

遗憾的是，2021 年我们也“送别”了一些数据库。

ServiceNow 收购了 Swarm64

该公司最初是开发在 PostgreSQL 上运行分析工作负载的 FPGA 加速器。后来，他们转向仅使用扩展作为 PostgreSQL 的软件加速器。但他们未能获得关注，尤其是与其他资金充裕的云数仓相比。在 ServiceNow 收购之后，目前仍然没有消息表明 Swarm64 产品是否会继续维护。

Splice Machine 破产了

Splice 推出了一种混合型（HTAP）DBMS，它结合了 HBase 和 Spark SQL，前者用来处理操作性工作负载，后来用来分析数据。后来，他们推动提供一个用于操作性/实时机器学习应用的平台。但是，由于专业的 OLTP 和 OLAP 系统在市场的主导地位，all-in-one 的混合系统在市场并没有取得什么进展。

私募公司收购了 Cloudera

在 2010 年到 2020 年这十年的后期，技术重心从 MapReduce 和 Hadoop 技术转移之后，Cloudera 同这些技术一样在云数仓市场上失去了竞争力。尽管项目依旧在开发且在发布新版本，Impala 和 Kudu 的初创团队的大部分人都已经离职。股价也跌破了 2018 年 IPO 的初始价。新投资者能否扭转公司局面，还有待观察。

Andy 说：2022 年可能会有更多的数据库公司倒闭

看到数据库项目或公司倒闭的新闻，总是让人唏嘘，但这也是数据库行业的残酷现实。开源可能有利于 DBMS 比开发它的厂商活得更久，但事实并非总是如此。由于数据库的复杂性，它需要全职人员持续地修复 bug 和新增功能。将一个只有躯壳（defunct）的 DBMS 的源码权和控制权转移到像 Apache 或是 CNCF 这样的开源软件基金会，并不代表这个项目就会神奇般地复苏。

例如，RethinkDB 在公司破产后捐给了 Linux 基金会，从 GitHub 上的迹象来看，这个项目已经处于停滞状态（很少有提交，PR 也没有合并）。无独有偶，另一个例子是 DeepDB：公司失败后，他们为代码创建了自己的非营利基金会，但从来没有人在上面工作。我预测，2022 年将有更多无法与主流云厂商、上面提到的那些资金充足的初创公司竞争的数据库公司倒闭。

坚持的回报

近年来，Oracle 的联合创始人 Larry Ellison 运气不是很好。早在 2015 年，他还是世界上第五富有的人。但世事难料，在 2018 年的亿万富翁排名中他跌到了第十位。

但这一切在 2021 年 12 月发生了转变，当 Larry 超过谷歌的联合创始人 Larry Page 和 Sergey Brin，再次登上世界第五富有的位置。在 2021 年 12 月的某天，在宣布公司季度盈利超过预期时，Oracle 股票达到过去 20 年单日第二高涨幅，Larry 也在一天之内赚了 160 亿美元。新闻媒体认为，这归功于投资者对 Oracle 成功转向云服务十分有信心。

Andy 说：为 Larry 高兴

Larry 和我是旧相识，他重返财富榜第五位无疑是一个振奋人心的新闻。当他运气不好，仅仅是世界上第十富有的人时，他可能有些忧郁。但是我很高兴看到他能够从低谷中走出来，回到他应有的排位。

---

以上为 Andy 教授三年来的数据库 review。如果你对数据库的发展有自己的看法，记得留言哟~

参考资料

• 2023 年数据库回顾原文：https://ottertune.com/blog/2023-databases-retrospective
• 2022 年数据库回顾原文：https://ottertune.com/blog/2022-databases-retrospective
• 2021 年回顾：https://ottertune.com/blog/2021-databases-retrospective

翻译：GPT-4
校对：清蒸、木鸟

---

感谢你的阅读 (///▽///)

关于 NebulaGraph：它是一款开源的分布式图数据库，自 2019 年开源以来，先后被美团、京东、360 数科、快手、众安金融等多家企业采用，应用在智能推荐、金融风控、数据治理、知识图谱等等应用场景。(^з)-☆ GitHub 地址：https://github.com/vesoft-inc/nebula