数据库泰斗Stonebraker ：“警惕数据库技术的过分炒作！”

我们如何存储和提供数据是决定我们能做什么的重要因素，而今天我们想做的事情太多了......

这个大数据需求是所有发明之母，在过去的20年里，它激发了大量的数据库创造力，从MapReduce和数组数据库到NoSQL和矢量数据库。这一切看起来都很有前途……然后迈克尔·斯通布雷克（Michael Stonbraker）出现了。

半个世纪以来，Stonebraker一直在疯狂地设计数据库。这位图灵奖得主早期以 Ingres 和 Postgres 闻名。然而，他显然不满足于创造出世界上最受欢迎的数据库（PostgreSQL），他还创造了Vertica、Tamr和VoltDB等。他最新的努力是通过数据库导向的操作系统（DBOS）颠覆整个计算范式。

Stonebraker 还以其对数据库和数据处理行业的直言不讳的评估而闻名。他曾经打破过一些泡沫，挑战过一些被奉为神圣的东西。2014年，当Hadoop处于人气巅峰时，Stonebraker就乐于指出，谷歌（这一技术的来源）已经从MapReduce转向了其他东西：BigTable。

这并不是说Stonebraker是NoSQL技术的坚定支持者。事实上，他多年来一直是关系数据模型和SQL这两个关系数据库管理系统核心原则的坚定拥护者。

早在2005年，Stonebraker和他的两位学生Peter Bailis和Joe Hellerstein（2021年Datanami People to Watch班成员）分析了过去40年的数据库设计，并在一篇名为《数据库系统阅读》的论文中分享了他们的发现。他们在其中得出结论，关系模型和SQL在与层次文件系统、面向对象数据库和XML数据库等其他想法的较量中脱颖而出，成为数据库管理系统的最佳选择。

在他的新论文《循环往复》中，这位传奇的麻省理工学院计算机科学家及其写作伙伴卡内基梅隆大学的Andrew Pavlo分析了过去20年的数据库设计。他们指出：“自2005年我们的调查以来，数据库世界发生了很多变化。”根据Stonebraker和Pavlo的观点，尽管自2005年以来发明的一些数据库技术是有用且好的，并且会持续一段时间，但许多新技术并不有用，也不好，只会存在于小众市场。

01

  20年的数据库发展

以下是这对搭档对过去20年新数据库发明的评价：

MapReduce：以Hadoop为最明显和一度最成功的实现的MapReduce系统已经死亡。

“它们多年前就已经死亡，现在充其量只是遗留技术。”

键值存储：这些系统（如Redis、RocksDB）要么“成熟为关系模型系统，要么仅用于特定问题。”

文档存储：像MongoDB和Couchbase这样的NoSQL数据库通过开发人员对非规范化数据结构、较低级别API和水平可扩展性的兴奋得到了好处，但以牺牲ACID事务为代价。

然而，文档存储“正与关系数据库管理系统发生冲突”，作者写道，因为它们已经采用了SQL，而关系数据库增加了水平可扩展性和JSON支持。

列式数据库：这一家族的NoSQL数据库（BigTable、Cassandra、HBase）类似于文档存储，但只有一个嵌套级别，而不是任意数量。

然而，作者指出，列存储家族已经过时。“没有谷歌，这篇论文就不会讨论这一类。”

文本搜索引擎：搜索引擎已经存在70年了，今天的搜索引擎（如Elasticsearch和Solr）仍然很受欢迎。它们可能会继续与关系数据库分开，因为在SQL中进行搜索操作，“往往很笨拙，并且在不同的DBMS之间有所不同。”

数组数据库：像Rasdaman、kdb+和SciDB（Stonebraker的创造）这样的数据库以二维矩阵或张量（三维或更多维）存储数据，在科学界很受欢迎，并可能继续保持这种状态。

“因为尽管有新的SQL/MDA增强功能，关系数据库管理系统无法有效地存储和分析数组。”

矢量数据库：作者写道，专用矢量数据库如Pineone、Milvus和Weaviate等“本质上是带有专用ANN（近似最近邻）索引的面向文档的数据库管理系统。”

一个优势是它们比关系数据库更好地与AI工具（如LangChain）集成。然而，矢量数据库的长期可行性不佳，因为关系数据库管理系统可能会采用它们的所有功能，从而“使这些专用数据库变得不必要。”

图数据库：属性图数据库（如Neo4j、TigerGraph）凭借其在某些类型的OLTP和OLAP工作负载上的效率（在连接数据上，在关系数据库中执行连接会导致计算资源的低效使用）为自己开辟了一个舒适的利基市场。

作者写道：“但它们的潜在市场成功取决于是否有足够的‘长链’场景值得放弃关系数据库管理系统。”

02

数据库架构的趋势

列式存储：存储数据为列（而不是行）的关系数据库（如Google Cloud BigQuery、AWS的Redshift和Snowflake）已经在数据仓库/OLAP市场中占据了主导地位。

“因为它们的性能优越。”

云数据库：过去20年数据库设计中最大的革命发生在云端，作者写道。由于网络带宽相对于磁盘带宽的大幅提升，通过网络附加存储（NAS）将数据存储在对象存储中变得非常有吸引力。这反过来推动了计算和存储的分离，以及无服务器计算的兴起。

向云的推动为企业提供了“重构代码库并消除不良历史技术决策的千载难逢的机会”，他们写道。“除了嵌入式数据库管理系统，任何不以云为起点的产品都可能失败。”

数据湖/湖仓：基于云对象存储的兴起（见上文），这些系统“是2010年代初‘大数据’运动的继承者”，作者写道。像Apache Iceberg、Apache Hudi和Databricks Delta Lake这样的表格式化技术使“让任何应用程序将任何任意数据写入集中存储”这一看起来“可怕的想法”得以实现，作者写道。

支持非SQL工作负载的能力（如数据科学家通过Pandas DataFrame API在笔记本中处理数据）是湖仓架构的另一个优势。这将“成为未来十年的OLAP数据库管理系统原型”，他们写道。

NewSQL系统：新的关系（或SQL）数据库的兴起，这些数据库像NoSQL数据库一样水平扩展，但没有放弃ACID保证，可能看起来是个好主意。但这种数据库类别，如SingleStore、NuoDB（现归Dassault Systems所有）和VoltDB（Stonebraker的创造），从未流行起来，主要是因为现有的数据库“足够好”且没有必要冒险迁移到新数据库。

硬件加速器：过去20年见证了一些用于OLAP工作负载的硬件加速器，包括使用FPGA，如Netezza、Swarm64和GPU，如Kinetica、Sqream、Brylyt和HeavyDB（前身为OmniSci）。除了云巨头外，几乎没有公司能证明为数据库构建定制硬件的费用是合理的，作者写道。但数据领域永远充满希望。“尽管几率很小，但我们预测在未来20年内会有许多尝试”，他们写道。

区块链数据库：曾经被吹捧为无信任社会的未来数据存储，区块链数据库现在“是一种消退的数据库技术潮流”，作者写道。并不是说技术不起作用，而是除了暗网之外没有任何应用。

“合法企业不愿意为使用区块链数据库管理系统支付性能代价（大约是五个数量级）”，他们写道。“一种寻找应用的低效技术。历史已经表明这是一种错误的系统开发方式。”

03

展望未来

一切都是相对的

在论文的结尾，读者留下的印象是“循环往复”的是关系模型和SQL。这两个实体的组合将很难被击败，但他们还是会尝试，Stonebraker和Pavlo写道。

“另一波开发者将声称SQL和关系模型不足以满足新兴应用领域的需求”，他们写道。“然后人们将提出新的查询语言和数据模型来克服这些问题。探索数据库管理系统的新想法和新概念具有巨大价值（它是我们获取SQL新功能的地方）。数据库研究社区和市场因此更加健全。然而，我们不认为这些新数据模型会取代关系模型。”

那么，未来的数据库开发将会是什么样子？两人鼓励数据库社区“促进开源可重用组件和服务的发展。包括文件格式（如Iceberg、Hudi、Delta）、查询优化（如Calcite、Orca）和执行引擎（如DataFusion、Velox）在内的一些努力正在朝这个目标迈进。我们主张数据库社区应努力实现类似POSIX的数据库管理系统内部标准，以加速互操作性。”

“我们提醒开发者从历史中学习。”，他们总结道。

“换句话说，我们要站在前人的肩膀上眺望远方，而非踟蹰于他们的足迹之间。我们中的一位很可能在二十年后依然健在，所以我们坚信，完全有望在2044年撰写这篇论文的续篇。”

//

原文链接：

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